[haiku-development] Re: RFC: Packages and the Deskbar menu

  • From: Ingo Weinhold <ingo_weinhold@xxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Tue, 28 May 2013 01:05:57 +0200

On 05/25/2013 11:49 AM, Simon Taylor wrote:> On 23/05/2013 09:36, Stephan Aßmus wrote:

>> On 23.05.2013 09:53, Alexander von Gluck IV wrote:
>>> As David said above, is the applications menu supposed to contain every
>>> application ever installed, or is it supposed to contain the ones you
>>> actually use?
>>
>> That is exactly the question. And I think the file system layer shows
>> too much other files. So I want an easy to access layer which shows
>> *all* installed applications, just one icon per app. This is what I have
>> always used the Applications menu in BeOS for. For access to frequently
>> used applications, I would be using LaunchBox or a new "Pin to Deskbar"
>> feature in Deskbar itself (replacing LaunchBox).
>
> This is perhaps the crux of the issue. I disagree that the "filesystem
> layer shows too many files" - the deskbar list on BeOS comes from a
> well-defined folder of symlinks, and the user is free to manage the
> files in that folders to completely control the number and position of
> those items.

Just clarifying that: Stephan was referring to David's statement: 'There already is a list of every application installed: in "/boot/common/apps" (or "/boot/system/apps")'. And for sake of completeness there are also "/boot/common/non-packaged/apps", "/boot/home/config/apps", and "/boot/home/config/non-packaged/apps". So even if you only install packaged applications, there will still be three different directories where applications can be found. And those directories will not only contain the application executables, but likely a directory per application with other stuff in it as well (I believe that is what Stephan meant with "too much [sic] other files").


On 05/25/2013 06:09 PM, Simon Taylor wrote:
On 25/05/2013 10:49, Simon Taylor wrote:
[...] This is much the same philosophy that is applied to emails
- for any problem involving arranging things in a hierarchy, Tracker is
a well-suited and well-understood way to do that.

Thinking more about how it works with emails - why not use queries for
this? Package symlinks could include a "category" attribute, and then
Deskbar's "category" menus would just be live queries. Users could
customise the queries to get custom views of their installed apps, all
without needing to actually move symlinks around. Of course they can
always put regular folders and symlinks directly in that folder too.

I'm not a fan of attributes for purposes like this. It isn't like the symlinks would be in completely random places (which is where queries excel). It also wouldn't help people who want to define their own categories, since they probably wouldn't just map one or two categories to another one, but rather move individual applications between or to new categories.

That being said, I think it would be nice to generalize Tracker's stored queries. Those wouldn't only be able to define queries, but also regular directories, which would simply be merged virtually. Additional name and attribute filtering would be possible as well. Besides generally being a nice feature it would also allow to implement the solution suggested by Stephan with discussed improvements with very little changes to Deskbar itself. Deskbar would just have to select the stored not-only-query to populate the menu depending on the user setting. An advantage would be that the (virtual) directories in the menu could actually be opened in Tracker.

CU, Ingo


Other related posts: