KDE/kdelibs/plasma
SVN commit 987462 by aseigo: clickable tooltips; plasma-devel@ people: please review API one more time CCMAIL:plasma-devel@kde.org M +77 -34private/tooltip.cpp M +12 -0 private/tooltip_p.h M +19 -1 private/windowpreview.cpp M +4 -0 private/windowpreview_p.h M +14 -2 tooltipcontent.cpp M +81 -25tooltipcontent.h M +55 -10tooltipmanager.cpp M +24 -1 tooltipmanager.h http://websvn.kde.org/?view=revrevision=987462 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: default plasma theme and fallback
On Friday 26 June 2009, Aaron J. Seigo wrote: On Thursday 25 June 2009, Marco Martin wrote: b)mantain oxygen as default and just load air instead of oxygen at kde startup and how will that work for krunner? kwin? put this in every application that should be using the global setting? that doesn't seem like a good idea. it also means we have to keep Oxygen up to date with all items we create (otherwise there will be no fallback). c)have a fallbackTo=foo entry in themes desktop files making possible for themes to fallback to a desired theme (maybe kinda overkill and what happens when a 3rd party theme falls back to another 3rd party theme? or what happens when a theme falls back to an incomplete theme?) this probably makes sense, but could be combined with: d) in Plasma::Theme, make the fallback separate from the default theme. this way Oxygen could be the fallback, Air the default. we could also cover our bases and have it a cascading list of fallbacks, with Oxygen as the first fallback and Air the last so if an element appears in Air (our default) that doesn't appear in Oxygen, then we're still good. this will also preserve things for widgets that put their widgets in default/ (aka Air) see attached patch. looks good, i wonder if we could limit this to themes shipped in runtime, specifying one looks quite overkill (would introduce the concept of dependency between themes, that could be bad or could be good, just to be tough carefully:) anyways to me looks good and is a thing to be backported, at least part of it soo, if we just make the default as air every time the default theme will change the same pain will repeat, if we keep oxygen as the fallback theme we are condemned to keep it complete for ever (that sounds sensible anyways) but will be less painful for old themes even if someday another new default theme will be provided... personally i think that themes that rely on a certain subset of elements in the fallback theme remaining consistent are operating on a delusion. in future, they can use FallbackTheme= if that's what they assume. and we need a techbase article on this :) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: air backgrounds - a little too translucent?
On Friday 26 June 2009, Aaron J. Seigo wrote: On Thursday 25 June 2009, Nuno Pinheiro wrote: A Friday 26 June 2009 01:05:16, Aaron J. Seigo escreveu: hi all ... is it just me or are the widget, dialog and panel backgrounds in Air just a little too translucent, making it hard to read text and see fine details? should it be made slightly more opaque? yeah a bit, its a trade off, general public see transparent as cool, but transparency comes with problems, low contrast being one of them, I guess we can make it less transparent, do remember the trade here less cool more usable... yes, that is indeed the trade-off; in this case at least it will still be somewhat translucent so it won't be completely uncool ;) yeah, it already comes from several iterations of being made more opaque :) if every one agrees we can make it more opaque by 25%??? +1 from me, but that was probably already evident :) will take care later today :) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: air backgrounds - a little too translucent?
Nuno++ On Friday 26 June 2009 02:17:46 Nuno Pinheiro wrote: A Friday 26 June 2009 01:05:16, Aaron J. Seigo escreveu: hi all ... is it just me or are the widget, dialog and panel backgrounds in Air just a little too translucent, making it hard to read text and see fine details? should it be made slightly more opaque? yeah a bit, its a trade off, general public see transparent as cool, but transparency comes with problems, low contrast being one of them, I guess we can make it less transparent, do remember the trade here less cool more usable... I know its a no brainier :) if every one agrees we can make it more opaque by 25%??? blurring would probably help a lot, but that isn't supported by all compositing setups and we simply can't (yet) do it properly on a QGrahpicsScene. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: default plasma theme and fallback
Just another thing. The problem mainly arose from the fact that we use the /name/ of the directory as an identifier which decides whether the theme is the default one. So, we would still have this problem after this patch (which still gets +1 from me even with this problem). How to make a theme that is based on Air? If you put FallbackTheme=default - you have done nothing. If the default theme changes (again), it will lead to breakage yet again. With icons, we use symbolic link default - oxygen (or default.kde4 - oxygen). What about using something similar here? Cheerio ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: default plasma theme and fallback
see attached patch. +1 personally i think that themes that rely on a certain subset of elements in the fallback theme remaining consistent are operating on a delusion. It is not just that. The biggest problem I've had was that I had (per your suggestion) trimmed down Lancelot's themes to share as much elements as possible, so to reduce the number of SVGZs. Since most shipping-with-plasma themes are dark, and the default one was too, I removed all the elements from the other dark themes relying on the fact that those from the oxygen will be used. The renaming default-oxygen and air-default screwed all that up. in future, they can use FallbackTheme= if that's what they assume. and we need a techbase article on this :) This would be a great solution for my case ;) As for limiting the fallbacks to shipping-with-plasma themes, I don't really thing it is necessary, but it should be mentioned in the techbase article that we provide no mechanism of ensuring that the fallback theme exists, and that only the s-w-p ones should be used. Cheerio. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: default plasma theme and fallback
On Friday 26 June 2009, Ivan Čukić wrote: With icons, we use symbolic link default - oxygen (or default.kde4 - oxygen). What about using something similar here? sure, a symlink would work fine here. -- 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 Software 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: air backgrounds - a little too translucent?
A Friday 26 June 2009 12:21:31, Marco Martin escreveu: On Friday 26 June 2009, Nuno Pinheiro wrote: A Friday 26 June 2009 01:05:16, Aaron J. Seigo escreveu: hi all ... is it just me or are the widget, dialog and panel backgrounds in Air just a little too translucent, making it hard to read text and see fine details? should it be made slightly more opaque? yeah a bit, its a trade off, general public see transparent as cool, but transparency comes with problems, low contrast being one of them, I guess we can make it less transparent, do remember the trade here less cool more usable... I know its a no brainier :) if every one agrees we can make it more opaque by 25%??? everybody please checkout the last revision (also backported) it's about that percentage more opaque, i think it's quite easy to read both on black and white backgrounds. on really noisy wallpapers is still a bit crappy, but the only way to avoid that would be to have a 95%-100% opacity.. and would be another theme :) aanyways, checks this and there is always time to correct it In a word, you fu...ing rock :) Now choose the word you like best :) blurring would probably help a lot, but that isn't supported by all compositing setups and we simply can't (yet) do it properly on a QGrahpicsScene. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel -- Oxygen coordinator ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: planning for 4.4
I'd like to keep with javascript plasmoid tutorials (specially if we manage
to have both full and simple API) but, meeting this sat, I can't make it.
Sunday would be better, and even better would be any time before 15:00 UTC
or at least 1 hour after it ;)
But, anyway, despite of the time or day (or me even being or not part of the
meeting), I'm in for js plasmoids tutorials (in your developer
documentation, website topic - and, btw, I'm a web developer and, depending
on what, could help with website, too).
But let's see about when this meeting's gonna be ...
Cheers,
--
JJ (|´:¬{)»
-
Eu sou a ressurreição e a vida. Quem crê em mim, ainda que morra, viverá; e
todo o que vive e crê em mim não morrerá, eternamente. Crês isto?
O Senhor, Jesus Cristo - Jo.11:25-26
-
2009/6/26 Aaron J. Seigo ase...@kde.org
hi all ...
i'd like to invite everyone to a planning for Plasma in 4.4 irc meeting.
it
would be great to do it this weekend, as Akademy is next week. i know some
of
our people are at linuxtag this weekend, but hopefully they can find an
hour
or so tomorrow to work it in.
it will be the usual what are our plans and goals for 4.4, and who'll be
doing what coordination meet up so we know where we are headed in the next
six months. with Akademy next week, it's a great opportunity to get
together
in person and work on these things even further. as you probably know, i
won't
be there this year, but i will be online 24x7 (P. will be out with his mom,
so
i should be relatively free, aside from packing up the house).
can those who can make it tomorrow at 15:00 UTC please rsvp to this email.
those can not, let me know if sunday works better.
as for possible agenda items, i have a decently healthy list of items
already:
* plasma mid
* notification queuing and logging
* full featured JavaScript API (binding Qt+KDE libs in full)
* further extension of the Simple JavaScript API
* kinetic
* remote widgets/engines/services
* context menus and mouse action plugins for containments
* add widget dialog
* improvements to ZUI (finally _nail_ that crap)[1]
* window slide in/out in KWin
* social desktop
* plasmate
* video driven welcome plasmoid
* the ARM CPU arch and plasma
* moving system tray from experimental to fd.o standard
* krunner magic - basics are in place, now lets take it to school!
* developer documentation, website
* kuiserver and plasma job display
* autoupdating / checking of plasmoids
[1] i've figured out a rather hackish way to draw shawdows around the
containments in DesktopView when zoomed out .. *grin* it's not pretty, but
it
will work and not degrade performance. which means we can replace the
checkerboard background.
--
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 Software
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: planning for 4.4
On Friday 26 June 2009 15:47:52 Aaron J. Seigo wrote: hi all ... i'd like to invite everyone to a planning for Plasma in 4.4 irc meeting. it would be great to do it this weekend, as Akademy is next week. i know some of our people are at linuxtag this weekend, but hopefully they can find an hour or so tomorrow to work it in. it will be the usual what are our plans and goals for 4.4, and who'll be doing what coordination meet up so we know where we are headed in the next six months. with Akademy next week, it's a great opportunity to get together in person and work on these things even further. as you probably know, i won't be there this year, but i will be online 24x7 (P. will be out with his mom, so i should be relatively free, aside from packing up the house). can those who can make it tomorrow at 15:00 UTC please rsvp to this email. those can not, let me know if sunday works better. as for possible agenda items, i have a decently healthy list of items already: * plasma mid * notification queuing and logging * full featured JavaScript API (binding Qt+KDE libs in full) * further extension of the Simple JavaScript API * kinetic * remote widgets/engines/services * context menus and mouse action plugins for containments * add widget dialog * improvements to ZUI (finally _nail_ that crap)[1] * window slide in/out in KWin * social desktop * plasmate * video driven welcome plasmoid * the ARM CPU arch and plasma * moving system tray from experimental to fd.o standard * krunner magic - basics are in place, now lets take it to school! * developer documentation, website * kuiserver and plasma job display * autoupdating / checking of plasmoids [1] i've figured out a rather hackish way to draw shawdows around the containments in DesktopView when zoomed out .. *grin* it's not pretty, but it will work and not degrade performance. which means we can replace the checkerboard background. I'll be around and will make myself available whenever. I'll probably get on around 6 or 7 am (12:00 or 13:00 UTC) and will stay on from then until not needed anymore =) Jeremy ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: planning for 4.4
On Friday 26 June 2009 23:47:52 Aaron J. Seigo wrote: can those who can make it tomorrow at 15:00 UTC please rsvp to this email. those can not, let me know if sunday works better. I'll most likely be there. Regards, Rob ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: planning for 4.4
can those who can make it tomorrow at 15:00 UTC please rsvp to this email. those can not, let me know if sunday works better. should be able to make it, not sure for how long. sunday I'll be on a plane :) I'll mention some stuff here just in case I don't make it to hte meeting. as for possible agenda items, i have a decently healthy list of items already: * plasma mid * notification queuing and logging * full featured JavaScript API (binding Qt+KDE libs in full) * further extension of the Simple JavaScript API yay js :) * kinetic * remote widgets/engines/services * context menus and mouse action plugins for containments yep. oh, I have an annoyance that I have to fix next week and it'd be good to discuss possible approaches. see, right now Containment has a contextmenuevent function that does both its own contextmenu and those of its applets. this has a few implications: *the function comes before mousereleaseevent, so it overrides my code. shouldn't be hard to fix, just stop using that function and put the code somewhere after mine. *when right-clicking an applet, the contextmenu currently contains the containment's contextactions too. continuing this behaviour would be... nontrivial. you'd have to find either a) the magic contextmenu plugin or b) whatever plugin is bound to rightclick (currently I favour b) and then somehow get a list of qactions or something from it, which is something they just don't provide ATM. ...although it's possible I could add it, and by default return an empty list, and have the contextmenu plugin implement it properly so the default settings look the same. hmmm. :) perhaps I've answered my own questions. * add widget dialog * improvements to ZUI (finally _nail_ that crap)[1] yay! I had a thought on this, but no time to consider implementing it: currently the second zoom-out level just draws things really small. iirc the original idea was to provide more of an abstract overview at that level. what about, once containment-saving is implemented, showing not just the running containments but the saved ones (thumbnails of them, that is - hey, better performance, right?) and having some kind of containment management stuff? this would mean not rendering itty-bitty fullyfunctional containments (they're not much use at that size anyways), maybe overlaying controls on them or something... or allowing them to be dragged around... also, some other stuff bugging me: *I'd like to be able to scroll a bit to the left or top of a containment, to get it out from under the corona-toolbox and my panels *autoscroll at the screen edges would be awesome *why do all my windows get minimized when I click the cashew? is there a faster way to unminimize them than activating each in turn? do we still have plans for zoomout-on-dashboard? I tend to work with several maximised windows on each desktop, so I end up keeping an extra virtual desktop dedicated to having hte cashew visible in case I need to zoom out. I'd much rather just ctrl-f12 and zoom out from there. *I've been hearing reports of zoomed-out-plasma eating the whole cpu on ati, and it happens to me on intel. iirc it was luca that was thinking maybe this isn't just a driver issue? maybe there's a bug? I *hope* it's just a bug... that means it could be fixed and I could zoom out without pain again. * window slide in/out in KWin * social desktop * plasmate * video driven welcome plasmoid * the ARM CPU arch and plasma * moving system tray from experimental to fd.o standard * krunner magic - basics are in place, now lets take it to school! * developer documentation, website * kuiserver and plasma job display * autoupdating / checking of plasmoids [1] i've figured out a rather hackish way to draw shawdows around the containments in DesktopView when zoomed out .. *grin* it's not pretty, but it will work and not degrade performance. which means we can replace the checkerboard background. :) -- 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: Review Request: Allow DataEngines to force update all sources, regardless of timers
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/892/#review1393 --- Yay! Excellent! Minor remark: don't forget the @since's - Jacopo On 2009-06-26 03:28:44, Aaron Seigo wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/892/ --- (Updated 2009-06-26 03:28:44) Review request for Plasma. Summary --- This patch introduces API to allow a DataEngine to force an update from sources out to all the connected visualizations regardless of their update intervals. The use cases for this are things like the time engine or when an engine goes from being offline to online and wants to prompt an immediate update. Diffs - /trunk/KDE/kdelibs/plasma/datacontainer.h 987537 /trunk/KDE/kdelibs/plasma/datacontainer.cpp 987537 /trunk/KDE/kdelibs/plasma/dataengine.h 987537 /trunk/KDE/kdelibs/plasma/dataengine.cpp 987537 /trunk/KDE/kdelibs/plasma/private/datacontainer_p.h 987537 /trunk/KDE/kdelibs/plasma/private/datacontainer_p.cpp 987537 Diff: http://reviewboard.kde.org/r/892/diff Testing --- Thanks, Aaron ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Allow DataEngines to force update all sources, regardless of timers
On 2009-06-26 18:05:58, Jacopo De Simoi wrote: Yay! Excellent! Minor remark: don't forget the @since's right, @since's. thanks :) committed with those in place. - Aaron --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/892/#review1393 --- On 2009-06-26 03:28:44, Aaron Seigo wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/892/ --- (Updated 2009-06-26 03:28:44) Review request for Plasma. Summary --- This patch introduces API to allow a DataEngine to force an update from sources out to all the connected visualizations regardless of their update intervals. The use cases for this are things like the time engine or when an engine goes from being offline to online and wants to prompt an immediate update. Diffs - /trunk/KDE/kdelibs/plasma/datacontainer.h 987537 /trunk/KDE/kdelibs/plasma/datacontainer.cpp 987537 /trunk/KDE/kdelibs/plasma/dataengine.h 987537 /trunk/KDE/kdelibs/plasma/dataengine.cpp 987537 /trunk/KDE/kdelibs/plasma/private/datacontainer_p.h 987537 /trunk/KDE/kdelibs/plasma/private/datacontainer_p.cpp 987537 Diff: http://reviewboard.kde.org/r/892/diff Testing --- Thanks, Aaron ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
