[Panel-devel] icons, files and the desktop
Chani
chanika at gmail.com
Thu Dec 20 14:55:50 CET 2007
a bugreport recently got sidetracked into talk about icon behaviour; that's
really something that should be discussed on panel-devel, so let's do so.
I can't remember if there have been discussions before, so I assume other
people are also ignorant in this respect, and I'd like to get it clear what
direction plasma's going with this instead of letting people randomly add
classic-desktop type features at will.
first of all: plasma should not be held back by traditional ideas about what a
desktop is supposed to be. of course the people who want a classic desktop
should be able to make it, but it should be done in a way that fits in with
the rest of plasma, and doesn't cause headaches in the future. I suppose it
should also be easy for someone to enable it all right away and have
something they're used to without much effort - but at the same time it
should be easy for me to not have *any* of that stuff on *my* desktop.
perhaps I'm stating the obvious - but it's better than making assumptions :)
so, what features make up a "classic" desktop experience? where should they be
implemented? what do we do about possible confusing areas (like how drag&drop
behaves)? which things seem like part of the 'classic' desktop that should
actually apply to plasma as a whole?
let's start with basic features:
-icons on the desktop, in general (got that)
-an icon for every file in ~/Desktop (I hear people talking about this but I'm
not seeing it myself)
-ability to align icons nicely
-right-click options like creating new files
then there's drag&drop:
-when a file is dragged onto plasma in general, make an icon
-when a file is dragged onto an icon, if the icon is a program launcher, run
the program with that file
-dragging icon from plasma to programs perhaps?
since I haven't used a classic desktop since... maybe kde 2? I've probably
missed some things here.
anyways, I see two general directions this could go here:
1) have the icons be individual applets, and put code in the existing desktop
containment for trying to keep them in sync with ~/Desktop
in this case, questions arise as to whether deleting an icon deletes the file.
also, how do you tell whether an icon is one of the desktop ones, or one
that's been dragged there?
one advantage is that any alignment code could apply to all plasmoids, not
just the icons.
right-click options would have to go in the desktop containment itself.
2) have a folder-display applet that handles all the classic desktop stuff.
this could possibly be a containment - then maybe someone could make it
possible to replace the default desktop containment with this classic one.
in this case, all desktop icons would be inside this applet (they wouldn't
have to be fully-fledged applets themselves). there would be a clear
distinction between icons being displayed because they're in ~/Desktop and
ones that have been dragged onto the desktop. the right-click menu could have
all the file-specific things you want. icon alignment would be handled by the
layout.
one advantage is that it could double as a generic folder display applet; you
could have several of them as applets, displaying the contents of several
folders. heck, even if you're using them as containments, you could have a
different folder for each plasma desktop.
it would keep all file-related code nicely contained in its own class.
a disadvantage would be that file-icon alignment and plasmoid alignment would
probably be separate things, and it might take a bit more work if you want to
avoid having plasmoids on top of your icons.
I'm really in favour of #2; it seems like a much cleaner approach in my mind,
and a more flexible one too.
so, discuss! :)
--
This message brought to you by evyl bananas, and the number 3.
www.chani3.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/panel-devel/attachments/20071220/b4424c96/attachment.pgp
More information about the Panel-devel
mailing list