gmane.os.haiku.devel

Re: RFC: Packages and the Deskbar menu

Simon Taylor — 2013-05-25T09:49:20

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. 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.

In a mutli-user and packagefs future it may not be simple (or even 
possible) to use the same method for organising Deskbar entries. I 
suppose there could be a virtual filesystem that provides a merged view 
of all the sources of application symlinks. I'm still not quite clear on 
how the proposal would work, but I wouldn't want to have to copy an 
entire auto-generated hierarchy of links somewhere writeable in order 
just to move one entry into a different folder.

I'm not really for adding an option for flat or categorised list - 
par

Re: RFC: Packages and the Deskbar menu

Urias McCullough — 2013-05-24T23:40:57

FWIW, I ended up at a Gnome 3 desktop last night (after installing the
latest Debian), and noticed that the apps are definitely still
categorized - with an option to view them "all". The flat view was
quite irritating, but fortunately there's a Gnome Classic now (that's
how badly it went for them - they added back a classic mode to keep
people from forking).

In any case, I removed it promptly again :)

- Urias

Re: RFC: Packages and the Deskbar menu

John Scipione — 2013-05-24T23:34:46

On Wed, May 22, 2013 at 2:42 PM, Julian Harnath
<julian.harnath-vA1bhqPz9FBZXbeN9DUtxg< at >public.gmane.org> wrote:

31 not counting Demos, Deskbar Applets and Preferences.


There's a big difference between you organizing your apps into 8
categories of your own creation and the system organizing your apps
into categories on your behalf, in the same way that you organize your
files into folders of your choosing but you wouldn't want the system
to automatically organize your files putting them into folders for
you.

Hierarchical organization systems are complex and difficult to keep
track of, those that the system generates and moves items behind your
back doubly so, that's one of the big reasons many people have trouble
locating files on their file system.

I see nothing wrong with a 64 item list and I have already mentioned 3
ways to mitigate the problem of long lists: pagination, scrolling, and
search, there are some other filtering techniques that could be used
as well. Categories though make browsing through

Re: RFC: Packages and the Deskbar menu

Denis — 2013-05-23T21:10:47


Oh, now I see what you mean. I should have tried it before I suggested it. 

If the Internet category contained just Webpositive, we would have Webpositive before the Office category (wrong alphabetical order) or if order is adjusted, Webpositive would move somewhere entirely different when a messaging app is added or if folder name is preserved Webpositive would just be called "Internet" until the messaging app is added. 

:/

Only time it would make sense is a folder with just one subfolder, then that folder name should be used.

Re: RFC: Packages and the Deskbar menu

Denis — 2013-05-23T20:10:07

On 23 May 2013, at 19:26, Ingo Weinhold <ingo_weinhold-Mmb7MZpHnFY< at >public.gmane.org> wrote:


You are right, only translatable strings are required. 


By top level I mean Applications


To allow both automatic and manual organization 

It will be well-defined. 


To choose between automatic organization and manual for newly installed apps. 


Yes why not? Choice is good. Some people might like to make their own list of recently added apps by hand, too.

Re: RFC: Packages and the Deskbar menu

Ingo Weinhold — 2013-05-23T18:26:54

I don't see the connection. Nowhere else do we use MIME-type-like 
strings for translation. Why should it be necessary in this case?


I believe so far no one has suggested to list applications at the top 
level. It's either to use detailed categories or a catch-all 
"Applications" category (probably alongside "Preferences").


Why two methods of specifying categories?


IMO (a) that would just look weird and (b) the location of an app would 
no longer be well-defined.


What would be the purpose of this feature?

If this is about making recently installed applications (I suppose 
that's what you mean by "new applications") easier to find, then I would 
suggest a (virtual) category "Recently installed" which would be 
populated automatically by Deskbar with links to the recently installed 
applications (additional to their usual location in the menu) or, 
probably better, a Windows-style highlighting of the menu items leading 
to the recently installed applications.

CU, Ingo

Re: RFC: Packages and the Deskbar menu

Denis — 2013-05-23T17:51:46

On 23 May 2013, at 15:03, Ingo Weinhold <ingo_weinhold-Mmb7MZpHnFY< at >public.gmane.org> wrote:


This fixed set should be akin to mime-types so it can be properly localised, as already suggested. 

I think the menu should show items based on both their disk location and their predefined category.

- By default apps are added at the top level. 
- Apps at the top level which have a predefined category are listed in the appropriate submenu
- Apps in a subfolder are listed in a submenu named after the subfolder
- If a folder is empty it is not listed, and if a folder has a single entry the folder is replaced by that entry (app or subfolder). This is to prevent unnecessary navigation. 
- It is possible to change the destination folder of new apps. So if you want a flat list, create a subfolder and put all apps there. If you want known apps to go in their categories and new apps to be segregated in a special submenu, keep known apps at the top level and change the default destination to "New!" or whatever you want t

Re: RFC: Packages and the Deskbar menu

Alexander von Gluck IV — 2013-05-23T16:46:06

On Thu, 23 May 2013 10:36:54 +0200
Stephan Aßmus <superstippi-Mmb7MZpHnFY< at >public.gmane.org> wrote:
.
.

This sounds like the obvious answer to me.

I never really liked categories.
Is the terminal a "Utility" or an "Accessory"
Is email an "Internet" application, or an "Office" application.

I'm always left guessing.  Lets just stick to how BeOS did it.

http://www.jfedor.org/shots/beos.png

Thinking towards the future, has anyone mentioned using the application
attributes to make applications specify what kind of application
they are? For example, create a group of grouping guidelines, stick
all the symlinks in one place for now, and later let tracker sort it out.

"* Flat application menu"
"* Group applications by category"

 -- Alex

Re: RFC: Packages and the Deskbar menu

Ingo Weinhold — 2013-05-23T14:03:08

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.


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).


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 k

Re: RFC: Packages and the Deskbar menu

Stephan Aßmus — 2013-05-23T08:36:54

Hi,

On 23.05.2013 09:53, Alexander von Gluck IV wrote:

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).


As previously mentioned, this is not a problem, since the packagefs only 
creates virtual symlinks which are dynamically generated at boot time 
from the activated packages.


An easy solution is one where you don't have to be aware of or click a 
check box at all.

Best regards,
-Stephan

Re: RFC: Packages and the Deskbar menu

Alexander von Gluck IV — 2013-05-23T07:53:57

On Wed, 22 May 2013 20:50:40 -0400
David Rawson Couzelis <drcouzelis-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:

It was mentioned that someone "had 64 applications, how would that look?"

Do people really commonly access 64 applications on a given day?

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?

We also have to think about removing application icons when the application
is uninstalled.  Having applications scattered through a large number of
menu folders means the chance that icons won't be cleaned up on
uninstallation is quite strong. (meaning non-working symlinks)

If you want to have an easy solution.  Have one check box:
"Add a shortcut into the applications menu?"

My personal vote is keeping the plain applications menu for now as-is.

Plus.. who is going to design a bunch HVIF category icons?

 -- Alex

Re: RFC: Packages and the Deskbar menu

David Rawson Couzelis — 2013-05-23T00:50:40

The "Applications" menu in the Deskbar menu could represent either:

* the user's personal list of applications

   or

* every application that is installed

Which does it represent?

There already is a list of every application installed: in 
"/boot/common/apps" (or "/boot/system/apps")

If the "Applications" menu is just for the applications that the user 
wants easy access to, then it should be controlled completely by the user.

For example, when creating a Haiku package, the package maintainer can 
mark one or more files in the package as "Primary". When the package is 
installed, the package manager shows the user the list of the "Primary" 
files and asks if the user wants to add them to their "Applications" 
menu (as symlinks).

The biggest problem with the "Applications" menu is that organizing the 
list of applications is confusing. For example, how can the user know if 
the files in the "~/config/be/Applications" directory are actual files 
or just links? (Are they labeled in Tracker?) If the user

Re: RFC: Packages and the Deskbar menu

Sean Collins — 2013-05-23T00:41:37


 I think everyone can agree, a bike shed is going to be built, it will 
hold bikes, and very few people are going to make use of it. That said, 
how about trying a few competing solutions, out of trunk and letting 
everyone give feedback and or a up down vote on the various features 
after a bit of testing, and then moving on. Put a time on this, lets say 
give everyone 1 week to design and implement the basic features and then 
on june 1, a vote is held and that thus forward, this will be the design 
until such time it can no longer be considered.


Build the shed already,

Sean

Re: RFC: Packages and the Deskbar menu

Axel Dörfler — 2013-05-22T23:06:00

What I do not really like about this solution is the possibility to 
choose arbitrary directories for the links. Furthermore, having to 
create links for an additional "all" flat list, or whatever we'll come 
up with in the future, sounds rather annoying.

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.

Bye,
    Axel.

Re: RFC: Packages and the Deskbar menu

Ryan Leavengood — 2013-05-22T21:24:13

Sorry, I meant the package FS. My main point in the above paragraph is
that even if the Deskbar is ignoring the
/boot/{system/common}/data/deskbar/menu (which is "managed" by the
package FS), the user could copy those symlinks to the
~/config/settings/deskbar/menu directory as a base for the manually
managed Deskbar menu.


That's not what I was saying, and I agree.

--
Regards,
Ryan

Re: RFC: Packages and the Deskbar menu

Matt Madia — 2013-05-22T20:39:07

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.

+1.

Stephan's explanation shows how the autogenerated applications list would
work by default and how users who want more control can easily obtain it
via 1 setting and editing the deskbar's entries in the same fashion as it
is now (file management of symlinks).

--mmadia

Re: RFC: Packages and the Deskbar menu

Ingo Weinhold — 2013-05-22T20:30:35

This is really getting off topic, but I can't resist commenting: It is 
utterly beyond me why there seems to be a new trend of developers and 
product managers blindly transferring smart phone solutions to the 
desktop. Or maybe I misunderstand something and the Gnome 3 solution is 
actually for a phone/tablet. Because for the desktop is obviously 
unsuitable.

CU, Ingo

Re: RFC: Packages and the Deskbar menu

Ingo Weinhold — 2013-05-22T20:06:18

Yeah, I came to the same conclusion.


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.


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 create

Re: RFC: Packages and the Deskbar menu

Julian Harnath — 2013-05-22T18:42:52

John Scipione <jscipione-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> schrieb:

Quick question: how many applications do you have installed on Haiku?

I just counted, my Deskbar menu currently has 64 application links, 
sorted neatly by hand in 8 categories. Having a flat list of 64 
applications would be no fun!

Greetings
Julian

Re: RFC: Packages and the Deskbar menu

Julian Harnath — 2013-05-22T18:40:35

scottmc <scottmc2-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> schrieb:


To me, perfection in software is usually when simplicity and power are 
combined. With the way the deskbar menu is currently built, that is 
very well reached: the menu structure is a file system structure. By 
simply clicking on "Applications" in the Deskbar menu, it opens as a 
folder in Tracker and you can start customizing any way you like using 
the tools you know (don't remind me of the pain that is the various 
menu editors for Linux!). You can also create a symlink to the Deskbar 
Applications menu on your desktop and start Applications with that (I 
like to do that, makes it a bit more similar to Amiga Workbench).

Tossing everything into one directory and using attributes to determine 
categories would increase complexity (managing attributes) and decrease 
power (cannot simply sort into subfolders via Tracker anymore), which 
would mean degradation in both dimensions.

Greetings
Julian

Re: RFC: Packages and the Deskbar menu

Ryan Leavengood — 2013-05-22T18:13:06

The categories seem arbitrary in the Linux world since there are too
many desktop systems and every one of those seems to want to
categorize things differently. This is a Linux problem. I think it is
unfair to bring Linux problems to Haiku.

The Haiku categories will not be arbitrary. We will define a fixed
list. Not everyone will be happy with this list, but tough, that is
what it will be.

So your argument about categories being arbitrary doesn't really hold
for Haiku. Before too long you will learn what the categories are and
generally what will be in each of them.

Also I think it is trivial to provide both a flat list of applications
and a categorized list. Scott's idea is good too, and maybe better
than mine.

This is not a hard problem and I don't think we should waste too much
more time arguing over it since it is trivial to support both methods
of organizing.

--
Regards,
Ryan