Hi, On 22.05.2013 10:54, Simon Taylor wrote:
On 22/05/2013 08:43, Stephan Aßmus wrote:I am completely with Axel on everything he said. But why don't we focus on the fact that the proposal would accomodate the use-case where people want to organize their deskbar menu themselves, and it would also accomodate the use-case where people couldn't care less about having to do that. Since obviously the first group has no problem tweaking options, they will surely find the option to disable the automatic menu generation and how to place links themselves, while it's a good idea to make the automatism the default for those users who don't want to spend time configuring.Yup, I agree that getting customisation right is really the key thing. The ideal solution would allow users to customise the menu placement of package-provided symlinks, whilst still being cleaned up nicely on uninstall and retained across upgrades. It's not clear to me the current proposal would provide those elements.
It works very simple: A package provides symlinks in config/data/deskbar-menu (or whatever it was Ingo mentioned in his mail). These symlinks are virtual and fixed (since packages are read-only). And they create sub-categories, I presume because packagefs will take care of creating the necessary folder structure if a symlink is to be placed in a non-existent folder. This structure is what the Deskbar would display by default in its application menu.
Additionally, you can have a custom menu just like it works right now. Consider it an arbitrarily structured "favorites" menu. You would simply link the packagefs generated links into another, persistent deskbar menu folder structure that lives in your normal file system.
Then you have a settings toggle in Deskbar, where you can turn off displaying the automatic application menu and only have your favorites.
And the last bit is that Deskbar would not display broken symlinks from your custom menu. So when you uninstall a package, there will remain a broken symlink in your favorites, but it automatically disappears from the menu. And when you re-install it, it automatically appears at it's previous location, since the symlink works again.
If the above could be done cleanly (I don't have any implementation ideas I'm afraid!) then it's a fairly moot point whether the default positioning is categorized or not. On iOS, adding a new app just goes to a blank space but it's easy to drag it straight into a categorised folder if you want.
Yes, but in iOS there are no other layers visible ot the user. An app is the icon on the home screen and nothing more. In Haiku, we have the file system layer, the application menu layer and a favorites layer in the form of LaunchBox or the custom Deskbar menu and/or links on the Desktop. I think that is enough layering and customization. We don't need the option to specifically hide applications from the automatically generated Deskbar application menu (which was one of the points brought up, by Adrien, I think). An option to turn it off entirely should be enough.
Best regards, -Stephan
