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

List:       kde-devel
Subject:    Re: Classic Menu in kde43 looks good, but still can't add folder from
From:       "A.J. Venter" <aj () outkastsolutions ! co ! za>
Date:       2009-06-14 8:23:46
Message-ID: 868cfe70906140123g722b8abmf7420b4d8e579bd9 () mail ! gmail ! com
[Download RAW message or body]

On Sat, Jun 13, 2009 at 6:10 PM, Aaron J. Seigo<aseigo@kde.org> wrote:
> On Saturday 13 June 2009, A.J. Venter wrote:
>> mailing before posting something) - but it doesn't handle .desktop
>> files nicely - it shows the filename rather than the description.
>
> it does when viewing the "Desktop" folder (for which it uses the desktop:/ kio
> slave)...
I looked now, - it does indeed, if you select the Desktop folder menu
entry, typing the path bypasses the ioslave.
>
>> Even on the desktop I think showing the description/Name entry from
>> the .desktop file rather than the filename makes sense. After all if
>> you have a folderview of your Desktop folder, it is likely full of
>> shortcuts from various apps - and the filename isn't the part you are
>> actually interested in - it's the program name you want to see.
>
> the trick would be in making renaming the file from the UI work properly;
> since it would actually be editing the file itself, not renaming the entry in
> the file system. moreover i think it would likely end up with "fun" situations
> where the user sees "Kontact" but if they create a new file called
> kontact.desktop in the same folder "Kontact" gets overwritten!
I see the logic here - though I don't think it's insurmountable.
Firstly the overwrite problem should just not happen - why can't the
UI show two files with identical displayed names and show the real
names in the detailed view ? Still I actually tend to agree that the
filemanager should focus on real filenames - it's primary purpose is
to manage files, launching programs is of secondary importance here.
>
> so i don't think this is really safe or even desirable in the file managers
> (konq, dolphin), though it might be defensible in folderview (while certainly
> adding more cpu cycles to various actions :)
In folderview it does make sense, but perhaps there is an easier
middle ground. As the Desktop ioslave handles things the way you want
when creating a custom menu - I tried setting a panel folderview to
show desktop://path/to/menufolder but this didn't work (it displays
empty [and yes, I used a real path :p ]) - but if the desktop ioslave
could take a path, this would be a simple and logical way a user could
say "View this folder as if it was the Desktop folder" - including
showing shortcut names rather than filenames ?
That way, the current approach is the default, but when your primary
purpose is application access rather than file-management, you can
fairly simply change it to work in this manner ?
I think it adds portability as well, we would be able to emulate a
"desktop" folder on platforms that have no concept of such (I don't
know if there are any in existence, or if we would ever try to port
KDE to such - but we'd be able to support them, and with a
still-useful-everywhere-else feature at that).

It should be a simple thing to code as well, the current desktop
ioslave uses it's platform based code to determine where the desktop
should be ~/Desktop on unix for example, we'd just give the user the
ability to overwrite this path in a given instance by using the
standard ioslave URI path convention (and since most other ioslaves
use paths on the URI - it's not like we don't know how to do it :p )

Thoughts ?

A.J.
-- 
A.J. Venter
Tel.: +27 21 554 5059
Fax: +27 11 252 9197
Outkast Solutions IT
www.outkastsolutions.co.za
A division of Global Pact Trading Pty Ltd.

www.silentcoder.co.za - Blog
scartoonz.silentcoder.co.za - ScarToonz webcomic
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]