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

CHDK - virtual keyboard - testers needed!

  • 150 Replies
  • 49129 Views
*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: CHDK - virtual keyboard - testers needed!
« Reply #120 on: 23 / January / 2012, 05:31:25 »
Advertisements
I've updated the tbox_test branch:
- changed the Lua function to accept all four parameters as suggested by outslider (update textbox_init signature to avoid warning from compiler)
- implemented the splitting of the charmap into separate strings without the '|' separator and removed the subgroups array.
- updated the test Lua script.

This doesn't include TobiMarg's layout change yet.

Phil.
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)

*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: CHDK - virtual keyboard - testers needed!
« Reply #121 on: 23 / January / 2012, 05:48:59 »

I only don't know, wheter is better to have tbox submenu, since it has only entry (charmap). However, who knows, wheter there will be other settings for this module (key layout? colors?).


Additional settings / menu options should give users the ability to configure the system for personal preference - keeping in mind that most users won't ever bother to change them. No point investing huge effort for little return (but if you enjoy the challenge go right ahead).

Color selection is probably worth adding to the settings / menu.
Other options to consider:
- allow the DISP button to switch rows in the charmap (instead of the shutter half press).
- configurable delay timeout before automatic simulation of the 'Set' button to lock the current character (like on mobile phone keypads).
- user selectable font (but this will probably be a lot of work).
- popup help page with brief instructions on use (could be a text file that opens in the text reader module)

Phil.
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)

Re: CHDK - virtual keyboard - testers needed!
« Reply #122 on: 23 / January / 2012, 09:38:39 »
One more benefit of in-module submenu for tbox for non-configurable by text implementation is that the core know nothing about of list supported by module charmaps

UPD:
 I make first look to the tbox changes. I will investigate more close later.

First comments:
1) In my version if no module or incompatible version of tbox module found "MPOPUP_MORE" menu is not visible. We shouldn't propose items which can't execute.

2)  In module_unloader (rev 1587)
text = 0;
is unnecessary. This callback is called right before real module unloading. So no case exists when this callback is called but module is not unloaded.

3) Purpose of removed in same revision
           tbox_on_select(0);    // notify callback about exit as cancel
is notify callback about enforced finalization of textbox (if you go to MODE_NONE by pressing ALT for example). Otherwise parent module could wait for answer from tbox forever.
« Last Edit: 23 / January / 2012, 10:52:51 by tsvstar »

*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: CHDK - virtual keyboard - testers needed!
« Reply #123 on: 23 / January / 2012, 17:04:51 »

1) In my version if no module or incompatible version of tbox module found "MPOPUP_MORE" menu is not visible. We shouldn't propose items which can't execute.


My preference is that the menu option(s) should always be visible; but should pop up an error if there is a problem with the module. This gives the user more clues as to the cause of the problem than just a vanishing menu. I just haven't got around to improving the error handling yet.

Quote
2)  In module_unloader (rev 1587)
text = 0;
is unnecessary. This callback is called right before real module unloading. So no case exists when this callback is called but module is not unloaded.

In the (unlikely) event the unloader got called twice this prevents the memory from being freed twice.

Quote
3) Purpose of removed in same revision
           tbox_on_select(0);    // notify callback about exit as cancel
is notify callback about enforced finalization of textbox (if you go to MODE_NONE by pressing ALT for example). Otherwise parent module could wait for answer from tbox forever.

Thanks, I've fixed up the callback in the latest revision, and also ensured that the 'text' variable is always released.

Phil.
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)

Re: CHDK - virtual keyboard - testers needed!
« Reply #124 on: 23 / January / 2012, 18:56:19 »
Just for feedback - everything works ok from user POV:)

In a few days I'll update my EDI with usage of tbox (mostly to create new file, in future maybe for searching of the string in the file). Then I'll have more experience in usage of th module and current implementation and maybe I'll have some notes.

Of course it'll be experimental release of EDI, that can't go to trunk before tbox will be moved there.
if (2*b || !2*b) {
    cout<<question
}

Compile error: poor Yorick

Re: CHDK - virtual keyboard - testers needed!
« Reply #125 on: 24 / January / 2012, 05:52:12 »
4. Look like you forget rename variable zebra_submenu_items :)

5. I think somewhere comment should be writed that argument of callback (result string) is temporary and will not exist after leaving callback function.

I was presume scheme "string owning is transfered to callback and callback side should care about resource unallocation" as slightly more safe (possible memory leak as cost as decrease chance to have pointer to unallocated space).
But looks like unallocation in tbox is more transparent (because personally I forget about it). :)

*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: CHDK - virtual keyboard - testers needed!
« Reply #126 on: 25 / January / 2012, 03:15:14 »
4. Look like you forget rename variable zebra_submenu_items :)

5. I think somewhere comment should be writed that argument of callback (result string) is temporary and will not exist after leaving callback function.

I was presume scheme "string owning is transfered to callback and callback side should care about resource unallocation" as slightly more safe (possible memory leak as cost as decrease chance to have pointer to unallocated space).
But looks like unallocation in tbox is more transparent (because personally I forget about it). :)

Thanks, I'll fix the menu variable name.

I'll add a comment on usage (probably in gui_tbox.h).

Do you think it might be better to have a fixed string for 'text' rather than malloc a new one each time?
It's probably unlikely that more than 100 character input would ever be needed.

The other option is for the caller to pass a string pointer in as a parameter where the user input is then stored.

Phil.

CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)

*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: CHDK - virtual keyboard - testers needed!
« Reply #127 on: 26 / January / 2012, 02:53:52 »
I've posted an update to the test version in the tbox_test branch.
- use a fixed size buffer in the module for user input, size set to a max of 100 chars.
- option final parameter to textbox_init allows the caller to supply the input buffer instead (can then be of any length)
- added some usage comments to gui_tbox.h

If this version is ok, then I will move it to the trunk over the weekend.

Phil.
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)

Re: CHDK - virtual keyboard - testers needed!
« Reply #128 on: 26 / January / 2012, 05:44:16 »
I do agree with changes. Previous ("malloc") architecture was designed for usage "free resource by caller".
This was allow to use string without copy/sprintf.

For current design implemented by you solution is better than malloc.

PS. I also see that in 1612 fix for directory delete applied. I thought that behaviour "clean directory content instead of directory itself removing" is premeditated. For example to prevent removing important/sensetive directories.
And so I add "Remove dir" item as separate item in "More" submenu of popup menu.

If indeed on different cameras "disp"/"erase" remove not only content but directory too, then this item should be removed. (For example when you will merge tbox branch to trunk)

*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: CHDK - virtual keyboard - testers needed!
« Reply #129 on: 26 / January / 2012, 05:58:58 »
PS. I also see that in 1612 fix for directory delete applied. I thought that behaviour "clean directory content instead of directory itself removing" is premeditated. For example to prevent removing important/sensetive directories.
And so I add "Remove dir" item as separate item in "More" submenu of popup menu.

If indeed on different cameras "disp"/"erase" remove not only content but directory too, then this item should be removed. (For example when you will merge tbox branch to trunk)

The file selector user interface probably needs work - the 'Disp' button currently acts as a shortcut delete action on the current item, if it detects a directory it prompts for confirmation and then deletes the directory and all contents.

In the main trunk, I left the 'remove directory' option in for people who hadn't figured out the 'Disp' shortcut yet; but just mapped it to do the same thing as the 'Disp' button (for directories).

Phil.
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)

 

Related Topics


SimplePortal © 2008-2014, SimplePortal