[Panel-devel] Desktop applet: remember icons positions

[Aaron J. Seigo]

On Friday 10 August 2007, Matt Broadstone wrote:
> > you'll find that in practice, it's not so similar at all.
>
> Well as far as I can see, given the current code which creates sub
> Icons, it could be changed to making them Applets with about 1 line of
> code (maybe 2 because we can't just load the applet with initial
> information).

... and then it would integrate with the rest of the system without hacking 
around things.

> > > bigger picture view if we made them all applets we have this huge mess
> > > of applets on the screen as opposed to a single one,
> >
> > one applet with a huge mess of icons versus a huge mess of applets each
> > of which is an icon. ;) i really don't see the difference, other than the
> > duplicated code that will innevitably follow...
>
> Not sure exactly what the duplicate code is here, maybe you mean
> layout stuff vs desktop organizers?

no ... i mean saving and loading of icon locations, dealing with context 
menus, and whatever other things we end up adding to applets and icons. 
*shrug*

> libplasma to layout widgets or applets) Maybe you're talking about the
> url applet versus our Launcher classes.

no, i wasn't thinking of those, but it is another good example.

> That's fine, except that the url applet sucks and is not maintained,

yep, it could be improved. it was originally written as a test applet, and 
some of the things in it were moved to Icon (and then a few things moved 
back) ... i really haven't seen much reason to hack on it given that people 
were working on various other launcher implementations ..

> though we could  improve it by moving the Launcher code in there.

that would probably make sense ... there's no point in having multiple 
implementations of things hanging around, each a little different and with 
their own bugs. 

the fileName helper method, for instance, is broken in Launcher; there's 
probably exactly 0 reason to have multiple classes with an inheritance 
hierarchy (just one that can represent a device, a file or a .desktop file 
should do); the search for the current view in launch() is silly (it may as 
well just do if (scene() && scene()->views().count() > 0) { 
view->scenes().first(); }) ... the double click setting check should probably 
be moved into icon ... *shrug* pushing this code into a common place would 
probably help get various issues addressed faster by having more eyes on it 
due to more people being likely to use it.

honestly, this is the first time i've looked at the launcher code because of 
where it currently is.

> on it and it personally really helps my workflow. It seems to me that
> your "pain" wrt the Desktop concept comes from a) KDesktop just

no, the pain is that the idea of listing the contents of a folder on disk 
competes directly with the idea of showing a collection of items not all of 
which can be accurately depicted as an item in the filesystem outside of 
plasma itself (which is pretty well all of the applets) ... the folder view 
concept is silly. actually showing icons on the desktop is a rather separate 
idea with i think can be done sensibly.

note that showing devices from Solid "on the desktop" in the "desktop is a 
folder" approach even breaks the concept right there as you are no longer 
showing items that are *in that folder*.

> We're providing ways to organize the desktop (the generic
> vertical/horizontal layout of items), but also new concepts that
> Matias has been working on for item grouping on the desktop - which I
> personally think could be pretty cool and useful.

... and if useful completely non-specific to showing a single folder's worth 
of crap.

> So let's not get into trashing the idea of a desktop off the bat,

i didn't. it was after a lot of thought and consideration.

> there's probably a good reason its been around since the mid 80's, and
> I don't really think that's because "nobody thought of anything
> better."

well, it's because very few projects have tried anything else. it's not 
because showing one folder of items on the desktop is a stroke of genius. 
it's a rediculously limiting idea given the reality of computing today: 1000s 
of files and folders, identity and networking in general, devices appearing 
and disappearing ... also realize that panels and full screen representations 
(e.g. media center) were all introduced far after the original mac which had 
a transient file system (whatever floppy was inserted at the moment) and 
extremeley limited use (single app at a time) and data access (even local 
area networking was still fairly exotic at the time).

fun to rehash this discussion 2 years later.

> > i think it is good to try your approach because it will either succeed or
> > it won't, and the latter would still be useful as an object lesson for
> > others.
>
> Agreed. I guess off the bat I can think of duplication if we start
> wanting to use anything other than launchers on the desktop (maybe
> Icon stacks/piles or something), that might want to be used in other
> applets. As I said with the current design switching to using applets
> is trivial, so we can cross that bridge when we come to it.

i'd rather cross it sooner rather than later as the idea of keeping most of 
this stuff inside a single applet is, to be honest, fairly obviously wrong.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/panel-devel/attachments/20070810/a85b54e6/attachment.pgp