[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-panel-devel
Subject:    Re: [Panel-devel] The ALI: do we really need or want it?
From:       Rafael Fernández López <info () maestroprogramador ! com>
Date:       2006-01-15 17:35:45
Message-ID: 43CA87F1.3040509 () maestroprogramador ! com
[Download RAW message or body]

-----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@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 underhis/her home tree, and that's CONTENT. Always that \
"foo" would want to edit /etc/X11/xorg.conf for examplewould need to run "su" or \
"sudo" and will access to administrative tasks. For administrative tasks I agree, \
"root" should have something likekonqueror, but for accessing files, not content. \
Maybe is right the supposition of making "foo"'s <world> her/his homedirectory. \
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 \
iD8DBQFDyofx9RRlaicc3IERAoEzAJ0XBPOv1FwCPR8en6WGNk2qbcZd7gCffp8Ij/3BlvRM/fNScqnPNW7d3DI==udux-----END \
PGP SIGNATURE-----_______________________________________________Panel-devel mailing \
listPanel-devel@kde.orghttps://mail.kde.org/mailman/listinfo/panel-devel


[prev in list] [next in list] [prev in thread] [next in thread]