Menu vs module improvements (split from patch thread) - page 3 - General Discussion and Assistance - CHDK Forum  
« previous next »
Pages: 1 2 [3] 4   Go Down

Menu vs module improvements (split from patch thread)

  • 36 Replies
  • 5537 Views
*

Offline philmoz

  • *****
  • 3124
    • Photos
Re: Menu vs module improvements (split from patch thread)
« Reply #20 on: 17 / June / 2017, 21:02:26 »
Advertisements
Quote from: dmitrys 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.


I'm not clear what you are trying to do.
The current system works, the user menu can include any item from the Miscellaneous menu and can include modules.
Modules can have their own sub-menus (see the eyefi module) which show in the CHDK menu; but can't be added to the user menu (doing this is a hard problem to solve).

The user menu already provides a dynamic menu system, why does the whole CHDK menu need to be customisable?

What exactly are you trying to fix? What menus do you think need to be moved into modules?

Even if you do this, the modules are still not self-contained. A much more difficult issue to solve is the module language strings being contained in the common language files.

Phil.
Logged
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)
*

Offline dmitrys

  • ****
  • 250
Re: Menu vs module improvements (split from patch thread)
« Reply #21 on: 17 / June / 2017, 22:55:02 »
Quote from: philmoz on 17 / June / 2017, 21:02:26
I'm not clear what you are trying to do.
The current system works, the user menu can include any item from the Miscellaneous menu and can include modules.

I believe the separate addition of modules is a hack. A proper solution would allow transparently adding items from Games and Tools submenus.

Quote
Modules can have their own sub-menus (see the eyefi module) which show in the CHDK menu; but can't be added to the user menu (doing this is a hard problem to solve).

I don't understand what's so hard about it. My latest patch should have solved that, but I probably missed something trivial.

Quote
The user menu already provides a dynamic menu system, why does the whole CHDK menu need to be customisable?

I'm not trying to make the menus customizable, only to hide the unused items.

Quote
What exactly are you trying to fix? What menus do you think need to be moved into modules?

Once again, the intention is to make CHDK easier to use. IMO the user menu doesn't solve the clutter issue.

Quote
Even if you do this, the modules are still not self-contained. A much more difficult issue to solve is the module language strings being contained in the common language files.

I only recently came across an old topic with a patch that was meant to solve that. The discussion there ended rather abruptly. I'll see if I can find it.

P.S Here it is.
« Last Edit: 17 / June / 2017, 22:59:34 by dmitrys »
Logged
Author of CHIMP, Canon Hack Installation and Management Platform
*

Offline philmoz

  • *****
  • 3124
    • Photos
Re: Menu vs module improvements (split from patch thread)
« Reply #22 on: 18 / June / 2017, 00:30:19 »
Quote from: dmitrys on 17 / June / 2017, 22:55:02
Quote from: philmoz on 17 / June / 2017, 21:02:26
I'm not clear what you are trying to do.
The current system works, the user menu can include any item from the Miscellaneous menu and can include modules.

I believe the separate addition of modules is a hack. A proper solution would allow transparently adding items from Games and Tools submenus.

Quote
Modules can have their own sub-menus (see the eyefi module) which show in the CHDK menu; but can't be added to the user menu (doing this is a hard problem to solve).

I don't understand what's so hard about it. My latest patch should have solved that, but I probably missed something trivial.

But by your own admission your patch doesn't work and also breaks the user menu?

Quote
Quote
The user menu already provides a dynamic menu system, why does the whole CHDK menu need to be customisable?

I'm not trying to make the menus customizable, only to hide the unused items.

Quote
What exactly are you trying to fix? What menus do you think need to be moved into modules?

Once again, the intention is to make CHDK easier to use. IMO the user menu doesn't solve the clutter issue.

What clutter issue? You seem to be the only person that has an issue here.
You started the discussion wanting to move module specific menus into the modules - is this no longer the case?
If you are still trying to do this, then again I ask, which menus do you think need moving (and why)?

Quote
Quote
Even if you do this, the modules are still not self-contained. A much more difficult issue to solve is the module language strings being contained in the common language files.

I only recently came across an old topic with a patch that was meant to solve that. The discussion there ended rather abruptly. I'll see if I can find it.

P.S Here it is.

If you want to try and finish this feel free; but I can assure you it is not going to be easy.

Phil.
Logged
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)
*

Offline dmitrys

  • ****
  • 250
Re: Menu vs module improvements (split from patch thread)
« Reply #23 on: 18 / June / 2017, 11:01:18 »
Quote from: philmoz on 18 / June / 2017, 00:30:19
But by your own admission your patch doesn't work and also breaks the user menu?

The patch works OK and breaks nothing. It just fails to add simple modules from their submenus, which is why I requested assistance from the audience.

Quote
You started the discussion wanting to move module specific menus into the modules - is this no longer the case?
If you are still trying to do this, then again I ask, which menus do you think need moving (and why)?

The intention was (and still is) to remove items specific to a module if it isn't there. From a quick look at the main menu the following could be cleaned up:
  • RAW - _raw_op.flt
  • Edge overlay - edgeovr.flt
  • Histogram - histo.flt
  • Zebra - zebra.flt
  • Script - ubasic.flt and lua.flt (this is a tricky one)
The initial idea was to hard-code everything, but that just looked ugly. This is how I came up with the idea of a modular menu system - not a very original one, as it turned out.

Quote
If you want to try and finish this feel free; but I can assure you it is not going to be easy.

Once again, I don't see what's so hard about that. I'll post a design proposal separately.

Edit: Posted.
« Last Edit: 18 / June / 2017, 15:56:47 by dmitrys »
Logged
Author of CHIMP, Canon Hack Installation and Management Platform
*

Offline dmitrys

  • ****
  • 250
Re: Menu vs module improvements (split from patch thread)
« Reply #24 on: 18 / June / 2017, 11:13:16 »
I have a proposal that should justify the patch as it is, namely User Menu Editor 2.0.

Advantages:
  • A (relatively) isolated change
  • Backwards-compatible with existing configuration
  • Vastly improved editor UX
Downsides:
  • reyalp's time applying and testing the patch

Edit 2017-06-19: Moved to wiki.
« Last Edit: 19 / June / 2017, 15:34:33 by dmitrys »
Logged
Author of CHIMP, Canon Hack Installation and Management Platform
*

Offline srsa_4c

  • ******
  • 4006
Re: Menu vs module improvements (split from patch thread)
« Reply #25 on: 18 / June / 2017, 11:22:25 »
Quote from: dmitrys on 18 / June / 2017, 11:01:18
The intention was (and still is) to remove items specific to a module if it isn't there. From a quick look at the main menu the following could be cleaned up:
  • RAW - _raw_op.flt
  • Edge overlay - edgeovr.flt
  • Histogram - histo.flt
  • Zebra - zebra.flt
  • Script - ubasic.flt and lua.flt (this is a tricky one)
CHDK and its default modules are meant to be used together. If (some of the) modules are missing, then the install is broken and needs to be fixed. There already is a warning that appears when the core has determined that modules are missing (the check is not really complete, of course).
I really don't think there's a reason to do anything else than showing the user that warning message. Also, there's more that can go 'broken', besides the modules (language files, lua libraries).
Logged
*

Online reyalp

  • ******
  • 12111
Re: Menu vs module improvements (split from patch thread)
« Reply #26 on: 18 / June / 2017, 14:46:44 »
Quote from: dmitrys on 18 / June / 2017, 11:01:18
The intention was (and still is) to remove items specific to a module if it isn't there. From a quick look at the main menu the following could be cleaned up:
  • RAW - _raw_op.flt
  • Edge overlay - edgeovr.flt
  • Histogram - histo.flt
  • Zebra - zebra.flt
  • Script - ubasic.flt and lua.flt (this is a tricky one)
As I've said a couple times before, I see no reason to support installations without these modules. I appreciate that you've spent a lot of time going through the CHDK code and would like to contribute. I'm sorry to be negative about this, but it just doesn't feel like a good idea.

Note that rawop is also available from Lua, so leaving that out would potentially cause breakage beyond the menu. It is also NOT connected to most of the stuff in the raw menu, but rather the raw stuff in the file browser popup.

Removing lua and ubasic would not really clean up the menus at all, so I don't understand how it fits in your proposal.

There's certainly lots of room to improve the CHDK UI, but the number of items on the menu doesn't strike me as major problem. People who want quick access to certain items can set up the user menu. Making the user menu simpler, more intuitive or more flexible is certainly a worthwhile goal.

If you want to improve the CHDK UI, I'd encourage you to start by identifying what the problems are from a users POV, then proposing solutions, and then proposing implementation.
Logged
Don't forget what the H stands for.
*

Offline dmitrys

  • ****
  • 250
Re: Menu vs module improvements (split from patch thread)
« Reply #27 on: 18 / June / 2017, 15:12:19 »
Quote from: reyalp on 18 / June / 2017, 14:46:44
As I've said a couple times before, I see no reason to support installations without these modules. I appreciate that you've spent a lot of time going through the CHDK code and would like to contribute. I'm sorry to be negative about this, but it just doesn't feel like a good idea.

I understand. However, the objections I've heard so far were:
  • that's not what we're used to, and
  • that would make the User's Guide obsolete
Forgive me if I stand unconvinced.

Quote from: reyalp
Making the user menu simpler, more intuitive or more flexible is certainly a worthwhile goal.

Care to comment on the proposal then?

Quote from: reyalp
If you want to improve the CHDK UI, I'd encourage you to start by identifying what the problems are from a users POV, then proposing solutions, and then proposing implementation.

But that's exactly what I did.

I'm a novice CHDK user, and I find the menu clutter utterly annoying.

I then proposed removing unused items as a solution, and making the menus modular as an optional implementation.

However, I recently discussed the issue with a fellow hacker, and he came up with a much simpler yet powerful design (he is very smart):
  • Assign each module a UID.
  • Keep Games and Tools (and possibly Scripts) reserved UIDs.
  • Add a module UID field in CMenuItem.
  • Show items based on module availability.
The UIDs could be reused in modular localization (that was my idea!) and/or modular menus, should they be implemented at a later stage.

Edit: Added link to modular localization proposal.
« Last Edit: 18 / June / 2017, 16:01:14 by dmitrys »
Logged
Author of CHIMP, Canon Hack Installation and Management Platform
*

Online reyalp

  • ******
  • 12111
Re: Menu vs module improvements (split from patch thread)
« Reply #28 on: 18 / June / 2017, 17:31:17 »
Quote from: dmitrys on 18 / June / 2017, 15:12:19
I understand. However, the objections I've heard so far were:
  • that's not what we're used to, and
  • that would make the User's Guide obsolete
Forgive me if I stand unconvinced.
#1 Isn't my objection.
My biggest objection is that I'm not convinced it solves any real problem, so it doesn't feel like a good use of my time. Ensuring this change causes no harm seems likely to take a lot of  my time.
My next objection is that it is likely to create problems, because now every part of the code has to gracefully handle the case where certain "standard" modules are missing.
Finally, as a person who answers a large fraction of the end user questions on the forum, #2 isn't a trivial issue for me.

Quote
I'm a novice CHDK user, and I find the menu clutter utterly annoying.
Aside from aesthetics, what specifically is the problem? How does having, say, histogram and zebra in the main menu interfere with your day to day photography or other use of CHDK?

If the argument is that it takes too long to scroll through the items, there is already a feature to address that: The user menu. Suggesting improvements for the user menu is welcome (and I'll try to give feedback on your last proposal later), but it shouldn't be tied to the presence of modules.

Quote
I then proposed removing unused items as a solution, and making the menus modular as an optional implementation.
What is or isn't a module in CHDK is arbitrary, and the impacts of having a particular module present or not is not all obvious to users, so using the presence of modules as a way to customize the menu at install time does not seem like a good solution.

If you want to let users customize every menu, then that should be the proposal, though I would argue that the user menu exists to address that need.

If the desire is to give people quicker access to photography related controls, re-working the controls and UI outside of the menu is probably a better direction. This is an area that has been widely recognized as needing improvement for a long time.
Logged
Don't forget what the H stands for.
*

Offline dmitrys

  • ****
  • 250
Re: Menu vs module improvements (split from patch thread)
« Reply #29 on: 19 / June / 2017, 14:56:55 »
Quote from: reyalp on 18 / June / 2017, 17:31:17
My biggest objection is that I'm not convinced it solves any real problem, so it doesn't feel like a good use of my time. Ensuring this change causes no harm seems likely to take a lot of  my time.
My next objection is that it is likely to create problems, because now every part of the code has to gracefully handle the case where certain "standard" modules are missing.
Finally, as a person who answers a large fraction of the end user questions on the forum, #2 isn't a trivial issue for me.

All valid arguments. I only wish you had taken the time to present those earlier; that would have saved a considerable amount of resources on the other end of this conversation.

Quote
What is or isn't a module in CHDK is arbitrary, and the impacts of having a particular module present or not is not all obvious to users, so using the presence of modules as a way to customize the menu at install time does not seem like a good solution.

I believe I can now see the full picture. I had been confused by the improper application of the term "module".

Only what the CHDK code refers to as "simple modules" could be considered true modules. Out of these, 3 are hard-coded into the menus (_osd_le, modinsp and useredit). That leaves us with exactly two types of modules: Games and Tools.

I'd suggest moving all script libraries into A/CHDK/SCRIPTS, all games into A/CHDK/GAMES, all tools into A/CHDK/TOOLS, and all the rest into A/CHDK/LIB, but that would probably be too much to ask for given reyalp's limited time. However, I do suggest using the appropriate terms (i.e., scripting libraries, games, tools, and other libraries, respectively) from now on.

Usability issues notwithstanding, I got the following request via PM today:

Quote from: anonymous
Can you modify the sequence to allow user's to only accept the license agreements they need / want?  So if someone doesn't accept an SDM or ML license, the installation sequence disables the ability to load those but still allows CHDK (assuming the necessary licenses for CHDK are selected).

That seemed very reasonable to me. However, as I started pondering a solution, it occurred to me that none would be complete unless Lua and uBASIC are also taken into account.

Suppose the user doesn't want uBASIC installed (and hence doesn't want to accept its license). Does that sound like too far-fetched a scenario?

I therefore suggest a compromise. Only the following changes are to be made:

1. Modules scanned at startup as implemented in menus3.diff.
2. Module ID field added to CMenuItem as proposed.
3. Menu item hiding implemented as proposed, but only in items that encompass entire "module" types (i.e., Script, Games and Tools).

I consider the above set of changes to be the absolute minimum required for proper modularity.

Should the user menu improvements proposal be accepted, menus3.diff shall be applied in its entirety.

What do you think?

Edit: Updated link.
« Last Edit: 19 / June / 2017, 15:35:41 by dmitrys »
Logged
Author of CHIMP, Canon Hack Installation and Management Platform
Pages: 1 2 [3] 4   Go Up
« previous next »
 

Related Topics