Menu vs module improvements (split from patch thread)

  • 36 Replies
  • 4056 Views
Menu vs module improvements (split from patch thread)
« on: 10 / June / 2017, 12:29:37 »
Advertisements
Here's a patch to display a warning rather than an empty Games or Modules submenu.

The message box is supposed to display "Empty" (but is actually empty).


See below for new patch.
« Last Edit: 11 / June / 2017, 19:45:24 by reyalp »
Author of CHIMP, Canon Hack Installation and Management Platform

Fixed menus.diff to menus2.diff, should apply cleanly now.
« Last Edit: 11 / June / 2017, 17:19:57 by dmitrys »
Author of CHIMP, Canon Hack Installation and Management Platform

*

Offline reyalp

  • ******
  • 11586
Fixed menus.diff to menus2.diff, should apply cleanly now.
I appreciate the effort you put into this, but is it really a situation we need to handle? CHDK at present always includes games and utility modules, so the only way you'd see these cases are a bad install or the user deliberately removing them.

Given that all the modules together are only a few hundred KB, I'm not convinced there's much reason to spend effort on this case. Unless it makes the code simpler or clearer or supports some other worthwhile improvement.
Don't forget what the H stands for.

*

Offline philmoz

  • *****
  • 3070
    • Photos
The next step should be to move module-specific menus into their respective modules.


I did this previously; but it was eventually reverted.
The problem is this prevents module menus from being added to the user menu.
It was decided this was more important than the small space saving.


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)


I appreciate the effort you put into this, but is it really a situation we need to handle? CHDK at present always includes games and utility modules, so the only way you'd see these cases are a bad install or the user deliberately removing them.

The problem is there is a lot of clutter in CHDK menus; I'm thinking of adding an option to select which CHDK modules to install.

Quote from: reyalp
Given that all the modules together are only a few hundred KB, I'm not convinced there's much reason to spend effort on this case. Unless it makes the code simpler or clearer or supports some other worthwhile improvement.

How about caching the module infos so they are not read twice? I'm almost done implementing that, so let's wait for a new patch.
Author of CHIMP, Canon Hack Installation and Management Platform

I did this previously; but it was eventually reverted.
The problem is this prevents module menus from being added to the user menu.
It was decided this was more important than the small space saving.

Interesting. Is there no way to solve that? IMHO space is of lesser concern than having a truly modular system.

P.S. My patch also seems to break the user menu >:(
« Last Edit: 11 / June / 2017, 19:41:20 by dmitrys »
Author of CHIMP, Canon Hack Installation and Management Platform

*

Offline reyalp

  • ******
  • 11586
Re: Menu vs module improvements (split from patch thread)
« Reply #6 on: 11 / June / 2017, 19:51:22 »
I split this into a new thread since it seems like warrants more than a couple of posts of discussion.

The problem is there is a lot of clutter in CHDK menus; I'm thinking of adding an option to select which CHDK modules to install.
As I think I mentioned in the CHIMP thread, I'm not in favor of this. The games and modules submenus are buried in the misc menu anyway, so they shouldn't inconvenience day to day use much.

For other functionality, I'd rather have everything that's described in the manual be present.

Quote
IMHO space is of lesser concern than having a truly modular system.
The main reason we have modules is the very limited RAM available to CHDK. It would be nice to have the code more structurally modular, but that's a secondary consideration.
Don't forget what the H stands for.

*

Offline philmoz

  • *****
  • 3070
    • Photos
I did this previously; but it was eventually reverted.
The problem is this prevents module menus from being added to the user menu.
It was decided this was more important than the small space saving.

Interesting. Is there no way to solve that? IMHO space is of lesser concern than having a truly modular system.


Only by making the module system even more complex than it already is.


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)


Re: Menu vs module improvements (split from patch thread)
« Reply #8 on: 11 / June / 2017, 21:05:45 »
This almost works:
Code: (modules/user_menu_edit.c) [Select]
// Call a function to process a menu item (may be a sub-menu loaded via a module)
static void select_proc()
{
    CMenu* submenu;
    if (curr_menu->menu[gui_menu_curr_item].value)
    {
        ((void(*)(CMenu** arg))(curr_menu->menu[gui_menu_curr_item].value))(&submenu);
        gui_activate_sub_menu(submenu);
    }
}
Code: (core/gui.c) [Select]
static void gui_submenu_proc(CMenu* submenu, int arg)
{
    if (!arg)
        gui_activate_sub_menu(submenu);
    else
        *((CMenu**)arg) = submenu;
}

static void gui_misc_submenu(int arg)
{
    if (misc_submenu.menu == 0)
        init_misc_submenu();
    gui_submenu_proc(&misc_submenu, arg);
}

The editor can now enter the Miscellaneous menu, but fails to save it as an item. Any ideas?

P. S. Since the root menu is also populated dynamically, the user menu is now always empty.
« Last Edit: 11 / June / 2017, 21:40:47 by dmitrys »
Author of CHIMP, Canon Hack Installation and Management Platform

Only by making the module system even more complex than it already is.

Please elaborate. It looks like the above hack would also work for modules, wouldn't it?
Author of CHIMP, Canon Hack Installation and Management Platform

 

Related Topics