On 05/22/2013 02:01 PM, Ryan Leavengood wrote:
I'm coming in kind of late to this discussion, but sometimes that is useful when the discussion gets this long. In general I support the original automated approach to managing the Deskbar menu. I also think reasonable categories are fine. Though given that so far John, Simon and Jessica would prefer not to have categories, I think adding an option for that is also reasonable. I know we don't like excessive options (cue Matt) but given that 3 out of about 11 people (27%) who have participated in this thread would prefer not to have categories, I think it should be an option. So that makes the choice a simple 3-option radio button: How should the Deskbar menu be organized? (*) Automatically, with applications in categories ( ) Automatically, with applications in a flat list ( ) Not at all, let me organize it
Yeah, I came to the same conclusion.
To ease the switching between the first two options, each package could create two symlinks, one in an "All" category/folder, and then in whatever category/folder the application is in (which could also be under a "Categorized" folder.) Then the Deskbar's "view" could quickly change between the two options by just looking at whichever top-level folder the user wanted (All or Categorized.)
The additional symlink in "All" is an interesting idea. I was thinking of Deskbar simply reading in the contents of all categories and presenting it as a flat list, if requested. That would be a bit more flexible (e.g. one could start with two-level categories and have two flattening levels), but it's probably overkill and a bit more work to implement.
In fact the package manager could always create the symlinks this way and the above option really is what the Deskbar "looks at" to create the menu. For the last option the Deskbar ignores the package manager symlinks and just looks at the user's folder. But the package manager symlinks should still be there (with an easy way to find that folder in the Deskbar options) so that the user could copy that list as a starting point for their custom menu.
You lost me there. In the solution I originally proposed the package manager wouldn't have to do anything. In fact, it is completely independent of package management and could as well be implemented in the master right now.
The packager (the person creating the package) would be responsible for adding a symlink in the data/deskbar/menu hierarchy to the package. When the packages are extracted (physically in case of the current zip files, virtually with packagefs), depending on their installation locations, the three directory hierarchies /boot/{system,common,home/config}/data/deskbar/menu would be created. They would be merged virtually by Deskbar and comprise the auto-generated part of the menu. Depending on the Deskbar organization settings this auto-generated part would either be omitted completely, flattened (respectively, following your suggestion, reduced to the "All" subdirectory), or used verbatim to be merged with the user-defined menu entries from ~/config/settings/deskbar/menu.
I'm not a big fan of the package manager actually creating symlinks in ~/config/settings/deskbar/menu. As written in an earlier mail this is bound to cause issues on package removal or update.
CU, Ingo