[Panel-devel] The ALI: do we really need or want it?

[Rafael Fernández López]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Janne Ojaniemi wrote:
> 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.
> _______________________________________________
> Panel-devel mailing list
> Panel-devel at kde.org
> https://mail.kde.org/mailman/listinfo/panel-devel
> 

Well, I agree too much with Janne since your home directory is
/home/foo, and user "foo" DOESN'T WANT TO KNOW what /etc, /dev is.

When "foo" creates an OpenOffice document, "foo" will save it under
his/her home tree, and that's CONTENT.

Always that "foo" would want to edit /etc/X11/xorg.conf for example
would need to run "su" or "sudo" and will access to administrative tasks.

For administrative tasks I agree, "root" should have something like
konqueror, but for accessing files, not content.

Maybe is right the supposition of making "foo"'s <world> her/his home
directory.

Bye,
Rafael Fernández López.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFDyofx9RRlaicc3IERAoEzAJ0XBPOv1FwCPR8en6WGNk2qbcZd7gCffp8I
j/3BlvRM/fNScqnPNW7d3DI=
=udux
-----END PGP SIGNATURE-----