CHDK - virtual keyboard - testers needed! - page 6 - General Discussion and Assistance - CHDK Forum

CHDK - virtual keyboard - testers needed!

  • 150 Replies
  • 31452 Views
Re: CHDK - typing / virtual keyboard / editor-style typing
« Reply #50 on: 05 / January / 2012, 03:01:04 »
Advertisements
Code: [Select]
[quote author=tsvstar link=topic=7272.msg79364#msg79364 date=1325744164]
outslider,
Previous version is better. In new version keymap is hardcoded and couldn't be replaced.

I haven't thought about in this way... So ok, previous keymap and typing code was better. However I believe that advantage of above code is conditional drawing of the kayboard/buttons (as indicators on the mode). I can play with gui and leave typing and moduling for you ;)

-- EDIT --

Thinking about this a little more I can suggest also:
- Loading keymap into an array such as presented above will simplify generating of gui. Also it is a little bit more easy to manipulate with it. You could use strlen() instead of searching for "|". Loadin from text to array is not very dificult and could be done at start. I don't know how does it look from memory usage POV.
- Separator between characters should be a spacebar or tab - these characters will be not used in character boxs, so they are good separators.
- Gui should be draw only from gui_tbox_draw(), not from kbd_process() directly. kbd_process() should only change an indicator - wheter redraw is needed (boolean need_redraw())
« Last Edit: 05 / January / 2012, 04:11:47 by outslider »
if (2*b || !2*b) {
    cout<<question
}

Compile error: poor Yorick

Re: CHDK - typing / virtual keyboard / editor-style typing
« Reply #51 on: 05 / January / 2012, 04:26:00 »
However I believe that advantage of above code is conditional drawing of the kayboard/buttons (as indicators on the mode).
I also think so. That's what I'm talking about in upd of reply#33.

Quote
I can play with gui and leave typing and moduling for you ;)
I'm not sure what do you mean in word "typing". I'm ok if you and TobiMarg make and stabilize whole GUI part. This is your project and moreover I have not enough time to rewrite and stabilize GUI part. :)
Once this will be reached, I will integrate it easily. Make correct infrastructure, bind module to simple call, reconcile api versions will be my part of job.
If this will make more comfortable to you debug and stabilize module, I could integrate into reyalp-flt branch its draft version once it will be adapted to the new API.

What is required to start final integration into trunk:
- Module should be stable enough. No strange symbols/strings, strange behaviour or redraw issues
- It should have universal, obvious and comfortable GUI (keys scheme, conditional output/obvious mode marker). I think we found acceptable one
- It should have simple but flexible API. I describe it partially. Below is more detailed vision of API, including requirement for loadable charmap.

What is my vision of internal module API:

const char **tbox_chars - dynamic list of charmap (for this input scheme good enough array of strings in format "aaa|bbb|ccc|ddd"). finalized with zero pointer.
This is very similar to previous version (only one difference is dynamic size), so key processing could be based from tobimarg (with changes regarded to key map and insert/backspace functionality)

tbox_charmap_init( char* buffer, int size) - initialize tbox_chars from loaded buffer (each line is zero terminated). buffer is permanent (exist and unchanged at least until tbox is loaded). Draft (not tested) implementation of this function is in the bottom of post to prevent discrepancy. :)

gui_tbox_init(int title, int msg, char* defaultvalue, unsigned int maxsize, void (*on_select)(char* newstr)) - popup tbox. on finish it call on_select with 0 if cancel selected (and free buffer by itself) or with pointer to buffer (and callback should care about free it). This exactly same call which will be used everywhere in the system to use tbox.

Draft implementation of tbox_charmap_init()
Code: [Select]
const char *tbox_chars_default[] = {"ABCDEF|GHIJKL|MNOPQRS|TUVWXYZ",
                            "abcdef|ghijkl|mnopqrs|tuvwxyz",
                            "123|456|789|0+-=",
                            ".:, |;/\\|'\"*|#%&",
                            0 };

const char **tbox_chars = tbox_chars_default;

void tbox_charmap_init( char* buffer, int buffer_size)
{
 int i, size;
 int count;

   if ( tbox_chars && tbox_chars != tbox_chars_default)
      free ( tbox_chars );

   tbox_chars = 0;

   count = 0;
   for ( i=0; i<buffer_size;)
  {
     size = strlen(buffer+i);
     if ( size > 0 ) count++;
     i+=size+1;
 }

  if ( count ) {
     size = (count+1)*sizeof(char*);
     tbox_chars = malloc ( size );
  }

  // no valuable string or alloc fail - use default charmap
  if ( tbox_chars==0 ) {
     tbox_chars = tbox_chars_default;
     return;
  }

  // count is non-zero and alloc ok
  memset(tbox_chars, 0, size);

  count=0;
  for ( i=0; i<buffer_size;)
  {
     size = strlen(buffer+i);
     if ( size > 0 )
         tbox_chars[count++]=(buffer+i);
     i+=size+1;
 }
   
}

I'm open to comments
« Last Edit: 05 / January / 2012, 04:47:14 by tsvstar »

Re: CHDK - typing / virtual keyboard / editor-style typing
« Reply #52 on: 05 / January / 2012, 13:18:14 »
Below is your last module with some modifications:

- Proposed API applied. No real use/integration in the core yet - just test it with hardcoded values on run
- No simple_module and gui_tbox.h required
- Informative test callback is added
- Modes are displayed obviously. Buttons are replace symbol string
- Keymap slightly improved in discussed way

I found no previous symbol line blinking now. I do not understand why it goes off. But this is surely good.

Require:
- Bug fixing. A lot of strange bugs -  strange symbols displayed in input string, sometime not display entered symbols, strange final of ">navigate cursor<", not always clear cursor, wrong cursor position(replaced different symbol), can't replace first sym, etc
- Visual improvement (better button y offset/take to account multiline probability [looking to code?]), bottom border.
- apply discussed keyboard scheme. insert mode instead of replace, backspace
- Init with default string
- Probably reorganize kbd handler (switch(Mode) which call corresponend process function).
- Simplify and unify redraw in common way: need_redraw=2 - full, =1 - text/keyb only instead of text_need_redraw, tbox_need_redraw

Re: CHDK - typing / virtual keyboard / editor-style typing
« Reply #53 on: 05 / January / 2012, 14:50:43 »
Yes, it goes in good direction:D

However, I think that we could redraw whole applet each key press. If this is not the case we lost almost whole gui, when camera is rotated. Redrawing whole gui by each key press is nothing bad - it's maybe 20-50 redraws for single text. I guess your batteries  will even not feel that. And this way we avoid multiple 'something_to_draw' variables, complicated code and more places for bugs. tbox_gui_draw() should just draw whole gui everytime that boolean gui_to_draw would be equal to 1.

I can change gui draw as above, but I like to know your opinion about it :)

I do not understand popup, that is displayed after using OK or CANCEL. Is this for confirmation? I think it's not good idea.

And in this implementation DISP and MENU keys are used for the same thing. Maybe one of them could be used as spacebar?

What does FUNC do? In my case it causes to repeat previous character and avoids usage of other keys...

Edit 1

Funny, but zeroing c[] array removes problems with strange symbols:

Code: [Select]
void gui_tbox_draw(int enforce_redraw) {
    if (tbox_to_draw) {
        char c[MAX_LINES][MAX_WIDTH+1];

int i, j;
for (i=0; i<MAX_LINES;i++) {
            for (j=0; j<MAX_WIDTH+1;j++) {
c[i][j]=0;
    }
}

... and rest of code as before;)

Edit 2

Also I noticed that currently buttons a little overlay entered text so I moved it 5px down in gui_tbox_draw():

Code: [Select]
tbox_buttons_y = text_offset_y+FONT_HEIGHT+5; // on place of symbol line

And one more thing - instead of '|' we can use \06 as separator - it's a vertical line but it's better visible. We could also use an arrows, but they should be different for each key.

Below is module compiled from your last code with above table zeroing, moved buttons and new separator. Please, test it for apperance of strange symbols. It looks like random bits from memory were the only reason of this behavior. It's compiled with source #1527.
I attached also a source.
« Last Edit: 05 / January / 2012, 18:48:06 by outslider »
if (2*b || !2*b) {
    cout<<question
}

Compile error: poor Yorick


Re: CHDK - typing / virtual keyboard / editor-style typing
« Reply #54 on: 06 / January / 2012, 05:18:41 »
I can change gui draw as above, but I like to know your opinion about it :)
Main reason of two mode of need_redraw everywhere is not battery saving but avoid blink on redraw. This is uncomfortable.
cursor_to_redraw is just state of cursor.

Quote
I do not understand popup, that is displayed after using OK or CANCEL. Is this for confirmation? I think it's not good idea.
Now tbox is standalone module with only one purpose - test and demo. This is test/demo of callback. That everything works ok. In real usage tbox will be hidden module which only code could run it.

Quote
And in this implementation DISP and MENU keys are used for the same thing. Maybe one of them could be used as spacebar?
This was just intermediary to say . I like your idea about space by 'DISP'

Quote
What does FUNC do? In my case it causes to repeat previous character and avoids usage of other keys...
Looks like so. I'm think we could give more valuable function to it. And it surely should break last enter sequence.

Quote
Funny, but zeroing c[] array removes problems with strange symbols
Yes. That help.

Quote
Also I noticed that currently buttons a little overlay entered text so I moved it 5px down in gui_tbox_draw()
You are right. But also vertical size of box should be fixed.

Quote
And one more thing - instead of '|' we can use \06 as separator - it's a vertical line but it's better visible. We could also use an arrows, but they should be different for each key.
Arrows will break direct correspondence visual index to tbox_chars. \06 is good.

Sometimes write code is faster way to say something than write full description of ideas. :)
In attachment updated version.

Improvements:
- strange symbols are fixed [you found reason, i fix in more simple way]
- better handling of keyscheme(disp,menu,jogdial). Note: "todo" entries should be implemented and rewrote FUNC/SET
- buttons and keyboard better aligned
- arrow keys use universal function to enter + better handling incomplete charmaps
- need_redraw refactored in common way
- special color case for space
- any visual separator could be added (\06 now)
- edited field is visually obvious.

opened issue:
- fix vertical size of tbox
- fix bugs with moving cursor, correspondence cursor, forget to clean i
- insert mode instead of replace mode
- implement "todo" entries of keyscheme and rewrites FUNC/SET
- better handling default value (only initial changes now)
- process large strings ( maxsize (> MAX_WIDTH) - horizontal scrollable.

Re: CHDK - typing / virtual keyboard / editor-style typing
« Reply #55 on: 06 / January / 2012, 06:26:58 »
Problem with clearing cursor was absence of gui_tbox_redraw = 1; in case KEY_ZOOM_OUT: (line 373). So simple but I have been looking for the reason for so long!

« Last Edit: 06 / January / 2012, 06:30:32 by outslider »
if (2*b || !2*b) {
    cout<<question
}

Compile error: poor Yorick

Re: CHDK - typing / virtual keyboard / editor-style typing
« Reply #56 on: 06 / January / 2012, 06:42:55 »
That usual thing to hunt long time for one small comma. :)
I hunt for crash reason whole workday when modularize dng. And similar small forgetted line was the reason. :)

This fix help to look better.
Still exists gui problems:
- cursor mostly displayed for different symbol then entered
- sometime after moving with zoom_in/zoom_out keyboard highlight works, cursor moved but no real symbols entered

Re: CHDK - typing / virtual keyboard / editor-style typing
« Reply #57 on: 06 / January / 2012, 09:11:26 »
Hi

You are too fast or I'm too slow, in the time I read your posts and code you make the next version.  :D

I have now changed greygrey to blackblack because if the cursor moves there were grey lines.
Also I have implemented space.

I don't know why that doesn't work: "if (cursor < (maxlen-1) && cursor+1 != '\0') {" (move cursor). It moves the cursor to the right also if there are no more chars (cursor+1 != '\0').

But I haven't tested it yet. I will test and attach it.


Re: CHDK - typing / virtual keyboard / editor-style typing
« Reply #58 on: 06 / January / 2012, 09:24:20 »
Most of changes are small improvements, fixes, etc. My main piece of code wait for stabilizing this one.

I have now changed greygrey to blackblack because if the cursor moves there were grey lines.

I'm not sure that I understand what do you mean here. Could you please write with more details. I like grey background

Please note that In last version one of improvement is visual difference of edit field. Whole box have grey background, but edit field have black background.

PS.
outslider, TobiMarg,
I catch one more area to improvement in addition to previous list. If I add national charset (~36 sym including separators) line, then keyboard line goes out of the box. Increasing MAX_WIDTH doesn't help :(.

Re: CHDK - typing / virtual keyboard / editor-style typing
« Reply #59 on: 06 / January / 2012, 09:30:41 »
Ok, I have a working space under DISP - is the same switch/case as ZOOM_IN.

I also moved cursor line one char right (it should be there!). Now it looks better and it seems like bad line position was confusing us, and caused that we were see errors that have been not there.

EDIT

we also don't need so many draw_line in the code.
« Last Edit: 06 / January / 2012, 09:53:53 by outslider »
if (2*b || !2*b) {
    cout<<question
}

Compile error: poor Yorick

 

Related Topics