[Panel-devel] Desktop applet: remember icons positions

[Aaron J. Seigo]

On Friday 10 August 2007, Matt Broadstone wrote:
> On 8/10/07, Aaron J. Seigo <aseigo at kde.org> wrote:
> > 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.
>
> Oh come on, now you're going a little far.. an I suppose the tasks
> applet should contain applets instead of AbstractTask classes, and
> lancelot gets it all wrong with its sub BaseIcon's. This is not a
> hack, its just one way of solving the problem.

by "hacking around things" i meant things like: 

- being able to intersperse icons with widgets and have the geometry of them 
all handled properly
- propagating events back to the proper view (which sucks because if we change 
*which* events we want to react to we also have to change the desktop applet)
- draging icons from the desktop to panels (which otherwise would be already 
handled; think about how it will need to be done as it stands now)
- consistent drag and drop reactions when things are dragged to the desktop 
applet vs the actual desktop

as for AbstractTask, if the idea is keep the tasks listed together as a bar, 
then it makes great sense. if the idea is to allow the tasks to be moved all 
over the desktop individually then it's a piss poor idea.

as for BaseIcon, the point of Lancelot, as i understand it, is to list the 
contents of a folder in one place.

the desktop applet is there to show the icons across the whole, well, desktop. 
which is the point of corona. applets running full screen to spread things 
all around the desktop pretty much breaks most of the concepts here.

i'm fine with having a way to show the contents of ~/Desktop (or whatever) on 
the full screen as i know we need this for certain use cases (e.g. legacy 
user support, people who simply like this mechanism, etc), but it should be 
done _right_. done right isn't trying to reimplement what Corona is. done 
right isn't changing the semantics of the interface.

> > 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);
>
> Of course there is, its an easy way to handle different classes
> (different sense of the word) of desktop icons. When I want to

class hierarchies tend to get messy. just a bit of advice.

> organize my items on the desktop, I don't want to do it
> indiscriminately, I want to sort (for example) first by devices, then
> folders, then files and finally maybe a trash can, or something.
> Instead of putting all the work in the organization task for checking
> what type every single item is it was broken out into subclasses (fine
> you can argue that this could just be a type() method that returns an
> enum or something, but once again this is just another way of solving
> the problem that doesn't happen to be your first choice). Also the

yes, a type() method is probably what i'd do. yes, class hiearchies like this 
aren't my first choice. there's reason for that.

> launch task, device items are launched differently than file items,
> and folders as well.

which is easily handled by a switch(d->type) statement ... but whatever, if 
you like a cluster of classes, go for it. it is, as you note, just another 
way of doing it.

> > 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(); })
>
> This is also bogus, the parenting QGV needs to be found in the event
> that there are multiple QGV's. This is because KRun will launch 
> whatever the task to be run is and give it that QWidget as the parent.

a) all the views belong to the same process and are top level widgets, so 
which one you pick is almost academic here

b) read the code ;) it does view->items().contains(this).. now, items() 
returns all the items with the associated scene. which means that the *first* 
view returns by scene()->views() will cause that to be true. iow, that code 
is just a 'fancy' way of picking the first view ;)

btw, the applet will also crash if for some reason launch() gets called when 
it isn't associated with a view. since launch() should only be triggerable by 
user interaction, this is -probably- safe, but there is no real guarantee 
that scene() doesn't return 0 at some point. a check for scene() would be a 
good idea.

> >... the double click setting check should probably
> > be moved into icon
>
> Yeah I agree, this should probably be put in some sort of
> AbstractButton widget (emulating QAbstractButton in Qt API), as its
> needed for RadioButton, PushButton, and Icon.

it's only needed for icon. radio and push buttons don't differentiate between 
single and double click as there isn't a separation between selection and 
press. but otherwise.. yeah.

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

no, within the desktop applet.

> > 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*.
>
> Well of course, this is why this applet isn't called FolderViewer or
> something of that sort.

it really may as well be. folder + devices == desktop.

> The Desktop _is_ a special case folder 
> display, I'm sure that needs no explanation.

yes, i understand what "The Desktop" is. it's not that i don't get the 
concept, it's that the concept is fundamentally broken. it's based on the 
concept that the best we can do is show the contents of a location on disk. i 
agree it's a simple solution, but it's also one that is hugely limiting. (as 
i've explained both in this thread and in various presentations over the last 
2 years)

> > 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.
>
> Well I'm not exactly sure how you would handle the drag and drop
> situation with your approach.

any applet can register for a given mimetype. it would be fairly trivial to 
extend this to support type globs and/or protocol based handlers.

> Currently Corona just gives up if it 
> can't figure out what was dropped on it and create a url there. That
> is totally inappropriate, its not Corona's job

from the perspective that Corona manages the contents within it, it is 
precisely.

> and its quite frankly a 
> totally non obvious place for it (I mean Coroa isn't even the
> DesktopView, which is where one would naturally look for a dropEvent
> on the visible desktop element, not the scene that that view uses)

the assumtion that "drop" == "store it" is not the whole possible picture. 
that's why we have support for applet instantiation based on mimetype (which 
is, of course, a superset of "file").

-- 
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/bba9d26e/attachment.pgp