[Panel-devel] Desktop applet: remember icons positions

[Matt Broadstone]

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.

>
> > > > 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);
Of course there is, its an easy way to handle different classes
(different sense of the word) of desktop icons. When I want to
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
launch task, device items are launched differently than file items,
and folders as well.

> 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.

>... 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.

>... *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.
What, playground?

> > 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*.
Well of course, this is why this applet isn't called FolderViewer or
something of that sort. The Desktop _is_ a special case folder
display, I'm sure that needs no explanation.

> > 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.

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

> --
> 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
>
> _______________________________________________
> Panel-devel mailing list
> Panel-devel at kde.org
> https://mail.kde.org/mailman/listinfo/panel-devel
>
>
>