some thoughts on virtual desktops
this email meandered from plasma to kwin, so I'm crossposting. remember to keep both lists in replies please :) so I was thinking a bit about virtual desktops and wallpaper n'stuff. it seems to me that the majority of people using the per-virtual-desktop feature are really only interested in the per-desktop wallpaper part of it. (do correct me if I'm wrong about that :) now, ignoring for a moment the people who do want activities tied to virtual desktops... the ones who want different walpaper, I only really see two reasons they want it: 1) to easily identify which desktop they're on or which desktop they want to be on (a big colourful picture requires *much* less thought than text. heck, just removing the colours from window icons in alt-tab has made me have to think a lot more) 2) pretty shiny desktop-cube effect I'm sure there's a few people who just want it because they got used to it in kde3, too, but let's ignore them for now :) now, me, being composite-less... if I still wanted this, I'd be happy with a wallpaper plugin that let me set per-desktop wallpaper. but most people seem to have composite, and given how much of a fuss there was about the taskbar showing the wrong tasks, having the desktop show the 'wrong' wallpaper would annoy them much more. and actually break the second part of (1) - a grid or cube of desktops all showing the same background does not help you to quickly identify the one you want. so, wah. :( my clever idea to write a magical wallpaper plugin would only help the non-composite users. but is there anything we can do about this? put aside thoughts of wallpaper for a moment. just think: what can remind me of what desktop I'm on, without making me think? what can distinguish my virtual desktops in an effect so that I don't have to think? hmm. guess what, I just had an idea of sorts. :) let's say the config page for virtual desktops lets you set a colour for that desktop. then have desktop effects that show 1 desktop highlight each desktop with its colour, draw a border around them, something... just give each desktop its own colour in some way. and the pager could use the colours too, so it looks less like a pile of tiny boxes all alike. :) and someday I might write a little plasmoid that just sits in my panel and reminds me of which desktop I'm on, because right now I see the panel more than the desktop, and the pager doesn't give me that information... I hope nuno won't hate this idea... I know letting the user define arbitrary colours makes it hard for things to be pretty, but using colour as a label is so *useful*. anyone else got other ideas? :) -- This message brought to you by eevil bananas and the number 3. www.chani3.com signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: some thoughts on virtual desktops
On Wed, Oct 28, 2009 at 1:31 PM, Chani chan...@gmail.com wrote: this email meandered from plasma to kwin, so I'm crossposting. remember to keep both lists in replies please :) so I was thinking a bit about virtual desktops and wallpaper n'stuff. it seems to me that the majority of people using the per-virtual-desktop feature are really only interested in the per-desktop wallpaper part of it. (do correct me if I'm wrong about that :) Not contributing any idea, just my views- Its not just the wallpaper, for example I'm one of those, and to me activities tied to virtual desktops means something like I have one activity for each work (e.g. school/personal/kde development). So, I'll have different applets on different activities and tie different windows to corresponding activities. Again, for example that means keeping Digikam on my personal activity and Wikipedia on school activity along with the dictionary applet. I remember Nuno doing a survey over K3B icons. Can we have some sort of survey to find what the majority of people want it to be? Or, do something that satisfies both (I still wonder what happened to the Window grouping idea?). now, ignoring for a moment the people who do want activities tied to virtual desktops... the ones who want different walpaper, I only really see two reasons they want it: 1) to easily identify which desktop they're on or which desktop they want to be on (a big colourful picture requires *much* less thought than text. heck, just removing the colours from window icons in alt-tab has made me have to think a lot more) 2) pretty shiny desktop-cube effect I'm sure there's a few people who just want it because they got used to it in kde3, too, but let's ignore them for now :) now, me, being composite-less... if I still wanted this, I'd be happy with a wallpaper plugin that let me set per-desktop wallpaper. but most people seem to have composite, and given how much of a fuss there was about the taskbar showing the wrong tasks, having the desktop show the 'wrong' wallpaper would annoy them much more. and actually break the second part of (1) - a grid or cube of desktops all showing the same background does not help you to quickly identify the one you want. so, wah. :( my clever idea to write a magical wallpaper plugin would only help the non-composite users. but is there anything we can do about this? put aside thoughts of wallpaper for a moment. just think: what can remind me of what desktop I'm on, without making me think? what can distinguish my virtual desktops in an effect so that I don't have to think? hmm. guess what, I just had an idea of sorts. :) let's say the config page for virtual desktops lets you set a colour for that desktop. then have desktop effects that show 1 desktop highlight each desktop with its colour, draw a border around them, something... just give each desktop its own colour in some way. and the pager could use the colours too, so it looks less like a pile of tiny boxes all alike. :) and someday I might write a little plasmoid that just sits in my panel and reminds me of which desktop I'm on, because right now I see the panel more than the desktop, and the pager doesn't give me that information... I hope nuno won't hate this idea... I know letting the user define arbitrary colours makes it hard for things to be pretty, but using colour as a label is so *useful*. anyone else got other ideas? :) Yep, color looks like a good idea. Seems quite natural to the mind. -- This message brought to you by eevil bananas and the number 3. www.chani3.com ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel -- Shantanu Tushar(UTC +0530) http://www.shantanutushar.com ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: dropped URL handling in containment, was: Re: How to get Akonadi notes onto Plasma?
On October 27, 2009, Sebastian Kügler wrote: On Tuesday 27 October 2009 17:19:24 Aaron J. Seigo wrote: On October 27, 2009, Sebastian Kügler wrote: Is this something I should pursue? It sounds simple enough ... sure; i don't see any downside to it and the results could be interesting; worst case is we'd have a failed experimnt on our hands and one more way not to do it (in the words of Edison ;) but i think this could work out very well.. The attached patch seems to work. I've not really tested it, just confirmed that it works at least in one case (emailmessage, added X-Plasma-DropUrlPatterns=akonadi:* to its desktop file) -- it's late and I should sleep. If it's conceptually OK, I'll clean it up and submit it to review board. doing: KPluginInfo::List allApplets = KPluginInfo::fromServices(offers, exist [X- Plasma-DropUrlPatterns]) should eliminate all the entries that don't have any DropUrlPatterns without having to create and then cycle through *all* the plasma applets installed. this shouldn't be needed: QHashKJob*, KPluginInfo::List dropPlugins; the URL can be retrieved in mimeTypeRetrieved with job-url() but in general it could be an interesting addition... -- 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 Qt Development Frameworks signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: WallpaperScript
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1984/#review2841 --- Ship it! - Aaron On 2009-10-28 08:49:03, Petri Damstén wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1984/ --- (Updated 2009-10-28 08:49:03) Review request for Plasma. Summary --- Adds WallpaperScript for scripted wallpaper plugins. Diffs - /trunk/KDE/kdelibs/plasma/wallpaper.h 1041546 /trunk/KDE/kdelibs/plasma/scripting/wallpaperscript.cpp PRE-CREATION /trunk/KDE/kdelibs/plasma/CMakeLists.txt 1041546 /trunk/KDE/kdelibs/plasma/packagestructure.cpp 1041546 /trunk/KDE/kdelibs/plasma/plasma.h 1041546 /trunk/KDE/kdelibs/plasma/private/wallpaper_p.h 1041546 /trunk/KDE/kdelibs/plasma/scripting/scriptengine.h 1041546 /trunk/KDE/kdelibs/plasma/scripting/scriptengine.cpp 1041546 /trunk/KDE/kdelibs/plasma/scripting/wallpaperscript.h PRE-CREATION /trunk/KDE/kdelibs/plasma/wallpaper.cpp 1041546 Diff: http://reviewboard.kde.org/r/1984/diff Testing --- Thanks, Petri ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
About releasing a new plasmoid
Hi everyone, I'm finishing a new plasmoid for visualizing KDE community activities and I would like to know how to proceed for a release. Can I have it in kdeplasma-addons ? Am I in time for having it in KDE 4.4 ? TIA, Sandro ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Moved kill runner to kdereview
Am Freitag 16 Oktober 2009 17:10:16 schrieb Aaron J. Seigo: it should be in kdereview for at least a week (some prefer two), but then, yes. As the two weeks are nearly over and I didn't get more feedback, I want to move it now, if that's ok. -- Jan Gerrit Marker (jangmarker) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: dropped URL handling in containment, was: Re: How to get Akonadi notes onto Plasma?
On Wednesday 28 October 2009 16:39:41 Aaron J. Seigo wrote: On October 27, 2009, Sebastian Kügler wrote: On Tuesday 27 October 2009 17:19:24 Aaron J. Seigo wrote: On October 27, 2009, Sebastian Kügler wrote: Is this something I should pursue? It sounds simple enough ... sure; i don't see any downside to it and the results could be interesting; worst case is we'd have a failed experimnt on our hands and one more way not to do it (in the words of Edison ;) but i think this could work out very well.. The attached patch seems to work. I've not really tested it, just confirmed that it works at least in one case (emailmessage, added X-Plasma-DropUrlPatterns=akonadi:* to its desktop file) -- it's late and I should sleep. If it's conceptually OK, I'll clean it up and submit it to review board. doing: KPluginInfo::List allApplets = KPluginInfo::fromServices(offers, exist [X- Plasma-DropUrlPatterns]) should eliminate all the entries that don't have any DropUrlPatterns without having to create and then cycle through all the plasma applets installed. Good, good. That part felt icky... this shouldn't be needed: QHashKJob*, KPluginInfo::List dropPlugins; the URL can be retrieved in mimeTypeRetrieved with job-url() We the list of plugins (not the URL, I'm retrieving that from the job indeed) for the following case: - a URL is dropped - applets matching DropUrlPatterns are found - the TransferJob returns an error I Didn't make it up, this happens for the akonadi case if you don't have the KIO akonadi slave. My solution is to check first if we have DropUrlPattern matches and then only clean up without showing a menu if - no applets are there for this mimetype - no DropUrlPattern matches So in the mechanism, I think we really need it. The overhead should be negligible, since the memory is cleaned up after the popupmenu exits (note: forget that cleanup bit in the patch). Does it make sense now? but in general it could be an interesting addition... I think so, too. -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: About releasing a new plasmoid
On Wednesday 28 October 2009 18:18:55 Sandro Andrade wrote: I'm finishing a new plasmoid for visualizing KDE community activities and I would like to know how to proceed for a release. Can I have it in kdeplasma-addons ? Am I in time for having it in KDE 4.4 ? You're in time. Please add the plasmoid to the KDE 4.4 Feature Plan, move it into kdereview/plasma, and then announce it for review on plasma-devel@ and kde-core- de...@. After two weeks of review (and of course if all serious issues that came up during review are fixed), you can move it into one of the released modules, kdeplasma-addons for example. http://techbase.kde.org/Schedules/KDE4/4.4_Feature_Plan -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Moved kill runner to kdereview
On October 28, 2009, Jan Gerrit Marker wrote: Am Freitag 16 Oktober 2009 17:10:16 schrieb Aaron J. Seigo: it should be in kdereview for at least a week (some prefer two), but then, yes. As the two weeks are nearly over and I didn't get more feedback, I want to move it now, if that's ok. +1 -- 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 Qt Development Frameworks signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: About releasing a new plasmoid
Sandro, On Wednesday 28 October 2009, 14:18 Sandro Andrade wrote: I'm finishing a new plasmoid for visualizing KDE community activities and I would like to know how to proceed for a release. Can I have it in kdeplasma-addons ? Am I in time for having it in KDE 4.4 ? If you need any help on this, just ping me on #kde-brasil. Cheers! -- Artur Duque de Souza openBossa INdT - Instituto Nokia de Tecnologia -- Blog: http://blog.morpheuz.cc PGP: 0xDBEEAAC3 @ wwwkeys.pgp.net -- signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: About releasing a new plasmoid
On October 28, 2009, Thilo-Alexander Ginkel wrote: http://techbase.kde.org/Schedules/KDE4/4.4_Feature_Plan Is my assumption correct that the procedure is the same for a KDE Weather Ion? correct... -- 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 Qt Development Frameworks signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request: Find applets based on the URL dropped
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/2005/ --- Review request for Plasma. Summary --- Add capability for Applets to specify X-Plasma-DropUrlPatterns, a QStringList of globs to match a URL dropped onto Plasma. This is orthogonal to the mimetype checking. It's implemented as an additional static method: KPluginInfo::List Plasm::Applet::listAppletInfoForUrl(const QUrl url); Diffs - /trunk/KDE/kdelibs/plasma/applet.h 1041978 /trunk/KDE/kdelibs/plasma/applet.cpp 1041978 /trunk/KDE/kdelibs/plasma/containment.cpp 1041978 /trunk/KDE/kdelibs/plasma/data/servicetypes/plasma-applet.desktop 1041978 Diff: http://reviewboard.kde.org/r/2005/diff Testing --- Tested dropping URLs from webservers, akonadi, images, no strange behaviour found. There seems to be a crash in the Previewer Widget, but it's unrelated to this patch. I'm investigating.. Thanks, Sebastian ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Find applets based on the URL dropped
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/2005/#review2848 --- Ship it! impressive what's possible with so little code - Aaron On 2009-10-29 00:12:31, Sebastian Kügler wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/2005/ --- (Updated 2009-10-29 00:12:31) Review request for Plasma. Summary --- Add capability for Applets to specify X-Plasma-DropUrlPatterns, a QStringList of globs to match a URL dropped onto Plasma. This is orthogonal to the mimetype checking. It's implemented as an additional static method: KPluginInfo::List Plasm::Applet::listAppletInfoForUrl(const QUrl url); Diffs - /trunk/KDE/kdelibs/plasma/applet.h 1041978 /trunk/KDE/kdelibs/plasma/applet.cpp 1041978 /trunk/KDE/kdelibs/plasma/containment.cpp 1041978 /trunk/KDE/kdelibs/plasma/data/servicetypes/plasma-applet.desktop 1041978 Diff: http://reviewboard.kde.org/r/2005/diff Testing --- Tested dropping URLs from webservers, akonadi, images, no strange behaviour found. There seems to be a crash in the Previewer Widget, but it's unrelated to this patch. I'm investigating.. Thanks, Sebastian ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
