[Panel-devel] The ALI: do we really need or want it?
Janne Ojaniemi
janne.ojaniemi at nbl.fi
Sun Jan 15 14:38:26 CET 2006
On Saturday 14 January 2006 19:53, Chris wrote:
> Janne Ojaniemi wrote:
> >But I don't really see any reason why we should limit ourselves to only a
> > portion of the files.
>
> If you think it would be possible to show an entire /home directory in a
> single context menu that is easy to navigate I would love to see a
> design. However I have over 9000 music files alone and that would
> require a lot of visual space on the desktop. As well, with many
> expanding menus, if you make one wrong move you could collapse two or
> three layers. I just think it would be difficult to design and/or hard
> to navigate.
It's merely a question of implementation and design. I have thousands of songs
as well, and I don't really see any reason why they couldn't be navigated in
C-menu just fine. I mean, I can navigate those songs in Amarok just fine, why
couldn't I navigate them in C-menu as well?
>
> >The Content-menu I proposed would not contain all files in the SYSTEM. It
> >would contain the files in the users home-directory.
>
> What about root? He needs access to those files? And if you don't
> include them in the C-menu then you /will/ need a file browser. As well
> sometimes users need access to these directories.
Where exactly have I said that we should get rid of filemanager? Root-user is
used to configure the system, and he could use filemanager for that task.
filemanager is a tool to access files, the C-menu is not about accessing
files, it's about accessing CONTENT. There is a clear difference between the
two. Root's C-menu would contain the content in his home-directory, like it
does with every users. For more advanced tasks, there's always the
filemanager. But I honestly can't think of any reason why the user needs to
have access to /etc for example, and why the user should have to rely on the
filemanager. Filemanagers are about files. In the end, users don't want to
use files, they want to use their CONTENT.
Normal users don't really have any need to access root-menu. Their files are
in their home-directories. Only reason he could want to access the root-menu
is to access memorysticks and the like that are mounted somewhere in /. But
those cases could be handled in such way that filemanager is not really
needed.
> Why dictate to the user where he can put his files and where he can not
> put them? Isn't it about user choice? I really don't think we need a
> system wide My Music or My Pictures.
Where exactly am I "dictating" anything? I said that the user could have a
directory for his media somewhere in root-menu. As in, he decided to create
such a setup. I did NOT say that "we should have this kind of directory!", I
meant that the user _could_ have set up his system so that there is one
system-wide "My Music" and "My Pictures". If the user wants to have something
like that, do you want to deny him that possibility?
Besides, if you have several users using the computer, it would make more
sense to have the shared content somewhere where every user can access it,
instead of copying that 5 gigs of music to everyones home-directory.
> So far there have been several mock ups posted. Of these I haven't seen
> one that would be suitable to displaying ALL of the files in my /home
> directory. The one posted from OpenUsability.org takes up the entire
> screen and might as well be a file browser (albeit one with an
> interesting new twist on the whole category). Several of the mock ups
> from the blogs look like they would be great for displaying limited
> information. You talk of a proper categorization. I would therefor
> like to see either your candidate for "best display of proper
> categorization" or your own personal mock up.
I'm not an artists, so I lack the skills to create such mockups, sorry. And
you keep on talking about accessing files. This is not about files, this is
about content.
More information about the Panel-devel
mailing list