On 05/23/2013 01:06 AM, Axel Dörfler wrote:
On 05/22/2013 10:06 PM, Ingo Weinhold wrote: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.What I do not really like about this solution is the possibility to choose arbitrary directories for the links.
If you are concerned that creative application developers will invent new categories, we can define a fixed set and enforce it in Deskbar (by simply ignoring others) and/or in haikuporter as part of checking the packaging policy.
Furthermore, having to create links for an additional "all" flat list, or whatever we'll come up with in the future, sounds rather annoying.
haikuporter will probably provide a function to create the symlink(s) anyway, so it wouldn't make a difference in this case. For application developers not using haikuporter to create their package, they would indeed have to create two symlinks. I don't find it that annoying. Anyway, it would be possible for Deskbar to virtually flatten the categories instead of using a dedicated directory, as I originally thought. Advantages of the "All" symlink solution would be the simpler implementation and that there would actually be a physical representation of the list (well, actually one per installation location).
On a related topic, should it be allowed for applications to put links to documentation, etc. in there, too? Because those would further complicate flat lists, too.
I suppose that the flat list would still have the categories "Applications" and "Preferences", and a new "Documentation" category would be there, too. I don't know whether documentation should go in the Deskbar menu in the first place, though.
CU, Ingo
