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
Re: dropped URL handling in containment, was: Re: How to get Akonadi notes onto Plasma?
On Wednesday 28 October 2009 19:47:13 Aaron J. Seigo wrote: > On October 28, 2009, Sebastian Kügler wrote: > > 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: > > > > > > QHash 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 > > the same thing could be achieved by calling the method that fetches the > matching plugins in each place that needs it (including the error path) > rather than caching those values. that would mean calling it twice on > success, or twice on error or three times on error-that-isn't-an-error. > > it's not a hot path and finding the matching plasmoids shouldn't be very > slow at all. i'd prefer to keep the bookkeeping for drops simple as long > as it isn't a performance problem. I've removed the private member, and found that we can actually do with calling listAppletInfoForUrl() only once. We simply don't cop out on job->error() in dropResult() and call the slot anyway, the counting and stuff now happens only there, looks a bit cleaner as well. :) I've also changed the other bits, cleaned up a bit and sent it to reviewboard. Thanks for the feedback! -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 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: 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
Re: About releasing a new plasmoid
On Wednesday 28 October 2009 19:02:28 Sebastian Kügler wrote: > 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 Is my assumption correct that the procedure is the same for a KDE Weather Ion? I'd like to get one I developed into 4.4 (it's been in playground already for a while). Thanks, Thilo ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Reply - Retweet features for Microblog applet
On Wednesday 28 October 2009, Thelwyn wrote: > Hi list ! > > Sometimes ago I decided to learn a bit of Qt and C++, and after following > some tutorial I looked for more practical stuff to practice on. So I looked > into the microblog applet code since I use it and tried to code a "reply" > and "retweet" features/buttons , (well explained on this wish: > https://bugs.kde.org/show_bug.cgi?id=177906), that you find in most > microblog client. > > It has not been as easy as I expected, but I guess that being totally > unexperienced wasn't helping :) > > Anyway here is the result I got (small animated GIF): > http://tinyurl.com/yjk4oze > I must add that the buttons are not displayed in my own twees/dents > > Now I have questions: > > - I did it at first to start to understand how applets were working, and > learn a bit of Qt/C++, but now I wonder: is this something you think is > worth to be integrated in the microblog applet? yes, i was planning adding them, so it would save me work, yay! > As I said above there is a wish about it on b.k.o, and this is a common > feature, but maybe the applet is intended to remain simple? or someone > would have already started to work on it another way?.. or, or , or any > reason? > > - A part from the above consideration what do you think of the 'design', > the location of the buttons and the way it works? Also I'd like to show probably under the user icon, that is now empty space would be better, but let's get the code in and figure out layouting after (i wanted to clean that mess a bit porting to anchorlayout btw) > the code I wrote to you so that you can criticize it (being a total > beginner, i probably wrote an horrible piece of code :) don't hit me) Is > this the good place to share the code? Or can i post it to the review > board? reviewboard is the best place > Thanks in advance for your answers/advices, please remind I'm totally new > to this, so pardon me if I didn't post the good place the good way. > > Best regards, > > Bou > -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Moved kill runner to kdereview
Am Mittwoch 28 Oktober 2009 19:30:07 schrieb Aaron J. Seigo: > > 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 > The move is done, I moved it to /kdebase/workspace/plasma/generic/runners/. I added it as folder kill. It is added to the CMakeLists.txt like this: if (NOT WIN32) add_subdirectory(kill) endif(NOT WIN32) I hope that is ok. Aaron Seigo: thanks a lot for the help with that runner :) Jan ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Reply - Retweet features for Microblog applet
Hi list ! Sometimes ago I decided to learn a bit of Qt and C++, and after following some tutorial I looked for more practical stuff to practice on. So I looked into the microblog applet code since I use it and tried to code a "reply" and "retweet" features/buttons , (well explained on this wish: https://bugs.kde.org/show_bug.cgi?id=177906), that you find in most microblog client. It has not been as easy as I expected, but I guess that being totally unexperienced wasn't helping :) Anyway here is the result I got (small animated GIF): http://tinyurl.com/yjk4oze I must add that the buttons are not displayed in my own twees/dents Now I have questions: - I did it at first to start to understand how applets were working, and learn a bit of Qt/C++, but now I wonder: is this something you think is worth to be integrated in the microblog applet? As I said above there is a wish about it on b.k.o, and this is a common feature, but maybe the applet is intended to remain simple? or someone would have already started to work on it another way?.. or, or , or any reason? - A part from the above consideration what do you think of the 'design', the location of the buttons and the way it works? Also I'd like to show the code I wrote to you so that you can criticize it (being a total beginner, i probably wrote an horrible piece of code :) don't hit me) Is this the good place to share the code? Or can i post it to the review board? Thanks in advance for your answers/advices, please remind I'm totally new to this, so pardon me if I didn't post the good place the good way. Best regards, Bou ___ 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 28, 2009, Sebastian Kügler wrote: > 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: > > > > QHash 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 the same thing could be achieved by calling the method that fetches the matching plugins in each place that needs it (including the error path) rather than caching those values. that would mean calling it twice on success, or twice on error or three times on error-that-isn't-an-error. it's not a hot path and finding the matching plasmoids shouldn't be very slow at all. i'd prefer to keep the bookkeeping for drops simple as long as it isn't a performance problem. -- 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: 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
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: 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: > > QHash 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: 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
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: 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
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: QHash 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: some thoughts on virtual desktops
On Wed, Oct 28, 2009 at 1:31 PM, Chani 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: Review Request: WallpaperScript
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1984/ --- (Updated 2009-10-28 08:49:03.341028) Review request for Plasma. Changes --- * ScriptEngine and Wallpaper are both QObjects so WallpaperScript cannot inherit both. Added a small helper class for this (not a best name perhaps). Or should WallpaperScript not inherit ScriptEngine? * I have done some work with python but currently it just paints wallpaper with single color. * plasmapkg modifications are on the way too. Summary --- Adds WallpaperScript for scripted wallpaper plugins. Diffs (updated) - /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
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
