Next idea.I'm thinking about enabling (simple) modules to draw on the screen while inactive.To accomplish this, I'm using a function pointer which has a setter function. The setter function is exported, a module can use it to set a callback function (and un-set it prior to unloading).The function pointer is checked and executed if not NULL in gui_draw_debug_vals_osd(). I'm using the existing gui_debug_display_modes[] array (core/gui.c) with an additional setting ("plugin") to enable/disable this display callback.Potential uses are- displaying special information about something the core doesn't support (example: my s1is port provides extra information about the movie frames while recording)- enabling background display for my memory browser mod, so I can watch it while using the Canon UI- I plan to port the EDMAC viewer from ML, it seems to be more useful when one can adjust camera settings while watching it- ... ?Proof of concept seems to work.
Quote from: srsa_4c on 14 / May / 2013, 17:53:13I'm also seeing menu glitches sometimes, it's not exclusive to user menu.Just to be clear, do you have the user menu enabled and you are seeing glitches in other menus? Or is it disabled and you are seeing glitches? (I only spent a little time looking at the code but I believe that what I saw is related to how the MENU key is handled in different menu modes)
I'm also seeing menu glitches sometimes, it's not exclusive to user menu.
What is the likelihood of multiple modules wanting to register? Do you need to allow more than one registration?
Is gui_draw_debug_vals_osd the best place to call it?
Your change might even allow the debug code to be moved to a module using this hook.
How do you control the module once its loaded and 'run' has been called? The other simple modules take over the gui and kbd while running; but it seems these types of modules would not be able to trap any button presses, so how do you shut down the module when your done with it?
QuoteYour change might even allow the debug code to be moved to a module using this hook.Yes, that was obvious, although the keyboard handling would need some thoughts.
Extending the idea to the kbd task by allowing the module to register a callback there as well might work.The module would then get a chance to intercept the buttons before the core code did - the return value could be used to tell the core not to continue with the normal button processing.
Another possibility would be to detect a long press of a button (e.g. MENU) to activate an interactive mode where you could alter module settings or force an exit. Not sure how this would work if multiple modules all wanted to do the same thing though.
Quote from: waterwingz on 14 / May / 2013, 18:47:15Quote from: srsa_4c on 14 / May / 2013, 17:53:13I'm also seeing menu glitches sometimes, it's not exclusive to user menu.Just to be clear, do you have the user menu enabled and you are seeing glitches in other menus? Or is it disabled and you are seeing glitches? (I only spent a little time looking at the code but I believe that what I saw is related to how the MENU key is handled in different menu modes)On a camera where the Miscellaneous -> SD card menu has only one entry, clicking "make card bootable" pops up a messagebox. Dismissing that box only makes the menu redraw, but nothing is redrawn outside the menu. Not related to user menu.
If the message box ends up larger than the underlying menu then it needs MBOX_FUNC_RESTORE added to the flags in gui_mbox_init. This will force a full screen erase & redraw rather than just a redraw of the menu.There seems to be some cases where this needs to be added - I'll take a look at some point, unless someone else wants to do it.
I've assumed that the redraw when using the user menu to enter the regular menus and then trying to exit by pressing MENU again (documented here several posts ago) is something similar.
Somewhat unrelated question / concern. Some of the 1.2.0 menu seems unbalanced (best word I could come up with). Some random thoughts (and at least one of these is my "fault") :1) Edge overlay, Zebra & Histogram are really just fancy OSD stuff. Is there a better way to roll them into the OSD menu? (like Grid, Misc values, state display, ... and colored icons)2) There seems to be a bit of cross over between CHDK settings and Miscellaneous Stuff? Should Console be in the Scripting menu ? And Games go to the main menu? Enable half-press shortcut keys should be in Misc rather than CHDK settings? As should "Enable Splash Screen on Load"?3) Remote Parameters is very buried in the middle of CHDK Settings (personal bias here ....). Thank goodness for the User Menu.You get the idea. Even I have to click for a while to find things I know are there. A newbie or casual user is definitely going to struggle. But how to go from here? Propose some new menu arrangements and vote? Say "to heck with it ... its a hack" and leave things where they lie?
I'm thinking it would be much better placed in the Enhanced Photo Operations section - right after the Override Tv entries.
Started by sheiksadique General Help and Assistance on using CHDK stable releases
Started by adcz General Chat
Started by vk2him Feature Requests
Started by jgdavidson « 1 2 » AllBest's Builds
Started by MorgothV8 « 1 2 » General Help and Assistance on using CHDK stable releases
