Re: kdereview: adjustable clock
On Friday, August 27, 2010, Aaron J. Seigo wrote: On Thursday, August 26, 2010, Marco Martin wrote: On Wednesday 25 August 2010, Aaron J. Seigo wrote: On Wednesday, August 25, 2010, Emdek wrote: /me thinkssome policies about that should be written down somewhere... Yeah, good idea, but where? community.kde.org/Plasma is a good place to start them. here it is a first rough skeleton: http://community.kde.org/Plasma/Guidelines great start. we should merge this with: http://community.kde.org/Plasma/PlasmoidGuidelines done, btw. :) -- 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: Start Present windows by ctrl+left click on a pager indicator
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/5035/ --- (Updated 2010-08-28 07:49:57.821419) Review request for Plasma, Aaron Seigo and Marco Martin. Changes --- Adding Aaron and Marco in the hope to get feedback :-) Summary --- This patch adds support to pager to trigger the present windows effect for the desktop the user clicks on when holding ctrl. This is similar to what we have when clicking on a tasks group when ctrl is hold. I'm not sure if this is a too hidden feature, but I consider it as could be useful and consistent with the tasks applet. Diffs - trunk/KDE/kdebase/workspace/plasma/desktop/applets/pager/pager.cpp 1163977 Diff: http://reviewboard.kde.org/r/5035/diff Testing --- Thanks, Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: New Applet handle system
On 2010-08-27 15:57:53, Marco Martin wrote: doesn't seem to apply correctly it is svn diff that has some problems, it seems. try applying the patch with -p0 - Giulio --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/5155/#review7243 --- On 2010-08-26 10:30:18, Giulio Camuffo wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/5155/ --- (Updated 2010-08-26 10:30:18) Review request for Plasma and Aaron Seigo. Summary --- This is a rewamp of the Applet handle system. Through its modular architecture it easily allows modifications and reuse of code. It features a base Handle class, AbstractHandle, and a base class for the control elements, ControlElement. I developed an handle based on the actual AppletHandle, DesktopHandle, and the control elements for the usual operations. Diffs - trunk/KDE/kdelibs/plasma/CMakeLists.txt 1168271 trunk/KDE/kdelibs/plasma/applet.h 1168271 trunk/KDE/kdelibs/plasma/applet.cpp 1168271 trunk/KDE/kdelibs/plasma/containment.h 1168271 trunk/KDE/kdelibs/plasma/containment.cpp 1168271 trunk/KDE/kdelibs/plasma/extenders/extender.cpp 1168271 trunk/KDE/kdelibs/plasma/extenders/extenderitem.cpp 1168271 trunk/KDE/kdelibs/plasma/private/abstracthandle.h PRE-CREATION trunk/KDE/kdelibs/plasma/private/abstracthandle.cpp PRE-CREATION trunk/KDE/kdelibs/plasma/private/applet_p.h 1168271 trunk/KDE/kdelibs/plasma/private/applethandle.cpp 1168271 trunk/KDE/kdelibs/plasma/private/applethandle_p.h 1168271 trunk/KDE/kdelibs/plasma/private/configurecontrol.h PRE-CREATION trunk/KDE/kdelibs/plasma/private/configurecontrol.cpp PRE-CREATION trunk/KDE/kdelibs/plasma/private/containment_p.h 1168271 trunk/KDE/kdelibs/plasma/private/controlelement.h PRE-CREATION trunk/KDE/kdelibs/plasma/private/controlelement.cpp PRE-CREATION trunk/KDE/kdelibs/plasma/private/controlelement_p.h PRE-CREATION trunk/KDE/kdelibs/plasma/private/desktophandle.h PRE-CREATION trunk/KDE/kdelibs/plasma/private/desktophandle.cpp PRE-CREATION trunk/KDE/kdelibs/plasma/private/maximizecontrol.h PRE-CREATION trunk/KDE/kdelibs/plasma/private/maximizecontrol.cpp PRE-CREATION trunk/KDE/kdelibs/plasma/private/movecontrol.h PRE-CREATION trunk/KDE/kdelibs/plasma/private/movecontrol.cpp PRE-CREATION trunk/KDE/kdelibs/plasma/private/removecontrol.h PRE-CREATION trunk/KDE/kdelibs/plasma/private/removecontrol.cpp PRE-CREATION trunk/KDE/kdelibs/plasma/private/resizecontrol.h PRE-CREATION trunk/KDE/kdelibs/plasma/private/resizecontrol.cpp PRE-CREATION trunk/KDE/kdelibs/plasma/private/rotatecontrol.h PRE-CREATION trunk/KDE/kdelibs/plasma/private/rotatecontrol.cpp PRE-CREATION Diff: http://reviewboard.kde.org/r/5155/diff Testing --- It isn't finished. It's missing the touch events management (which, however, it's hard to me to do, 'cause i don't have any touch screen device) and a better drag and drop system between containments. I'd like, however, to know what you think about what i've done, especially about the architecture. What's here works, though. Thanks, Giulio ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Start Present windows by ctrl+left click on a pager indicator
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/5035/#review7249 --- Besides being a hidden feature it seems nice. I'm not sure how would be our policy for hidden features but from my point of view seems to be a nice feature. Just to do an analogy: imho it's as hidden as the effects on the corner of the screen feature, but with the advantage that it's in a place that already takes care of virtual desktops. - Artur On 2010-08-28 07:49:57, Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/5035/ --- (Updated 2010-08-28 07:49:57) Review request for Plasma, Aaron Seigo and Marco Martin. Summary --- This patch adds support to pager to trigger the present windows effect for the desktop the user clicks on when holding ctrl. This is similar to what we have when clicking on a tasks group when ctrl is hold. I'm not sure if this is a too hidden feature, but I consider it as could be useful and consistent with the tasks applet. Diffs - trunk/KDE/kdebase/workspace/plasma/desktop/applets/pager/pager.cpp 1163977 Diff: http://reviewboard.kde.org/r/5035/diff Testing --- Thanks, Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Removal of pastebin dataengine
On Sat, Aug 28, 2010 at 4:34 AM, Aaron J. Seigo ase...@kde.org wrote: as it was in addons, it's fine for it to be removed. Ah, great then. So just removed. Thanks! Cheers, ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Start Present windows by ctrl+left click on a pager indicator
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/5035/#review7250 --- Would it be possible to also do it with middle-click? This is unused for that widget as far as I can tell, and would avoid needing to use the keyboard entirely. - Todd On 2010-08-28 07:49:57, Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/5035/ --- (Updated 2010-08-28 07:49:57) Review request for Plasma, Aaron Seigo and Marco Martin. Summary --- This patch adds support to pager to trigger the present windows effect for the desktop the user clicks on when holding ctrl. This is similar to what we have when clicking on a tasks group when ctrl is hold. I'm not sure if this is a too hidden feature, but I consider it as could be useful and consistent with the tasks applet. Diffs - trunk/KDE/kdebase/workspace/plasma/desktop/applets/pager/pager.cpp 1163977 Diff: http://reviewboard.kde.org/r/5035/diff Testing --- Thanks, Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Start Present windows by ctrl+left click on a pager indicator
---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/5035/#review7253
---
i really dislike such 'magic' features for the reason of trustability. a person
will learn patterns of behaviour in the software and expect it to remain within
those patterns. whenever the software deviates, the user learns to expect
surprises and trust it less. this results in the user being more careful and
paying more attention to what they click on, etc. rather than just forgetting
about the environment and using it with as little conscious processing as
possible. like an experience driver behind the wheel of a car. (which is why
the idea of cars that accelerate on their own was so disruptive of an idea even
outside of the idea of possible harm and injury.)
unfortunately, we apparently have this feature in the tasks widget already. :/
in fact, it seems to have been part of another commit, probably by accident:
http://websvn.kde.org/?view=revisionrevision=997990
that commit message says, add a configuration ui for adding plasmoids into the
systray: only ones marked X-Plasma-NotificationArea=true in their desktop file
will show up in the list. it looks like the commit to taskgroup was an
accident.
in fact, that it only applies to groups and not to individual windows, that it
doesn't check for it being the root group, etc. makes me wonder about the
general quality of the feature. those things could be improved in the tasks
widget, of course, but personally i don't think this feature actually meets
what we're trying to achieve in terms of magic behaviours are bad.
it's been in there for a year, however, so i'm hesitant to yank it out at this
point. and if we leave it in the tasks widget, we should make it consistent
with the pager as well.
i'll leave it up to Marco since he was the one who made the original commit to
the tasks widget.
trunk/KDE/kdebase/workspace/plasma/desktop/applets/pager/pager.cpp
http://reviewboard.kde.org/r/5035/#comment7364
view() isn't guaranteed; to be on the (probably overly) safe side, it
should be:
QGraphicsView *v = view();
if (v) {
Plasma::WindowEffect::...
}
same below
- Aaron
On 2010-08-28 07:49:57, Martin Gräßlin wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/5035/
---
(Updated 2010-08-28 07:49:57)
Review request for Plasma, Aaron Seigo and Marco Martin.
Summary
---
This patch adds support to pager to trigger the present windows effect for
the desktop the user clicks on when holding ctrl. This is similar to what we
have when clicking on a tasks group when ctrl is hold.
I'm not sure if this is a too hidden feature, but I consider it as could be
useful and consistent with the tasks applet.
Diffs
-
trunk/KDE/kdebase/workspace/plasma/desktop/applets/pager/pager.cpp 1163977
Diff: http://reviewboard.kde.org/r/5035/diff
Testing
---
Thanks,
Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Start Present windows by ctrl+left click on a pager indicator
On 2010-08-28 14:56:56, Todd wrote: Would it be possible to also do it with middle-click? This is unused for that widget as far as I can tell, and would avoid needing to use the keyboard entirely. that would be even more easy to trigger accidentally and raise the possibility of this being found not on purpose. imagine what someone who accidentally middle clicks and triggers this behaviour is going to think? most people won't connect I just middle clicked on the representation of a window with the present windows effect being triggered, and if they do it will likely come across as slightly odd. middle clicking doesn't have a bring forward and show semantic anywhere else afaik, ergo the unexpectedness. so, no. :) (tangentially, the same reason i don't like this feature is the same reason i veto'd the concept of scroll wheel over the battery plasmoid adjusting backlight brightness.) - Aaron --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/5035/#review7250 --- On 2010-08-28 07:49:57, Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/5035/ --- (Updated 2010-08-28 07:49:57) Review request for Plasma, Aaron Seigo and Marco Martin. Summary --- This patch adds support to pager to trigger the present windows effect for the desktop the user clicks on when holding ctrl. This is similar to what we have when clicking on a tasks group when ctrl is hold. I'm not sure if this is a too hidden feature, but I consider it as could be useful and consistent with the tasks applet. Diffs - trunk/KDE/kdebase/workspace/plasma/desktop/applets/pager/pager.cpp 1163977 Diff: http://reviewboard.kde.org/r/5035/diff Testing --- Thanks, Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
custom animations in plasma
i want to make plasma theme with custom animations for example i want the busy widget to move linear or change colors instead of spin, and the notification i to display progress in linear bar instead of pie chart. the svg files i found are made to spin only, and the animation itself seems to be coded somewhere in plasma. where can i find the animation part in the code ? thanks, ash ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: kdreview: dictionary runner; changes needed to Plasma::RunnerManager?
On Tue, Aug 24, 2010 at 16:59, Aaron J. Seigo ase...@kde.org wrote: * when the teardown() signal is emitted, the runner should disconnect from the DataEngine Fixed with r1169251. * a thread can wait indefinitely on m_wait.wait(m_mutex); But isn't dataUpdated guaranteed to be run at /some point/ ? Or should we not rely on this. * if the user types more than $THREAD_POOL_COUNT letters before the dict engine returns, the thread pool will be filled with dictionary runner threads and therefore be exhausted looking at it further, it's evident that this runner is really working around the fact that it is multithreaded; Exactly -- the runner is a gigantic hack. it would be far easier in this case to simply make match() re-entrant and have just one thread of it around. It'd be nice to be able to access match()'s RunnerContext argument in a slot, so that match could parse the input, call a method of object A, and then return, and then a signal coming from A would call a slot that populates the RunnerContext with matches. But in such a design what about keeping track of multiple match calls and multiple RunnerContexts? Always populate the most recent one? a currentContext() accessor method? for such runners, i think it would make sense to allow for them to mark themselves as re-entrant and then give them their own thread outside the shared threadpool. This would be helpful. the nice thing about the current design is that match() methods do not need to be made re-entrant, and this makes it simpler for many of the runners. but it assumes that the runners exit quickly (freeing up the thread pool) and don't rely on any resources that have a single-thread restriction on them (as is the case with the dictionary plasmoid, among one or two others). Could we have both designs avaiable controlled by the aforementioned setReentrant(true) flag? once we sort this part out, the i'd like to see the dictonary runner moved to kdeplasma-addons/runners/ Hurray! ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: kdreview: dictionary runner; changes needed to Plasma::RunnerManager?
On Saturday, August 28, 2010, Jason A. Donenfeld wrote: On Tue, Aug 24, 2010 at 16:59, Aaron J. Seigo ase...@kde.org wrote: * when the teardown() signal is emitted, the runner should disconnect from the DataEngine Fixed with r1169251. :) * a thread can wait indefinitely on m_wait.wait(m_mutex); But isn't dataUpdated guaranteed to be run at /some point/ ? Or should we not rely on this. can't rely on it, no. it probably happens in this case, but there is no actual guarantee in the DataEngine system that it does. * if the user types more than $THREAD_POOL_COUNT letters before the dict engine returns, the thread pool will be filled with dictionary runner threads and therefore be exhausted looking at it further, it's evident that this runner is really working around the fact that it is multithreaded; Exactly -- the runner is a gigantic hack. well, we can fix that. if nothing else, this was a great exercise in discovering what needs to be improved exactly, and how :) it would be far easier in this case to simply make match() re-entrant and have just one thread of it around. It'd be nice to be able to access match()'s RunnerContext argument in a slot, so that match could parse the input, call a method of object A, and then return, and then a signal coming from A would call a slot that populates the RunnerContext with matches. match is given the RunnerContext on each invocation. that RunnerContext may become invalid at any time, though, so there is no current or the RunnerContext in this sense. a runner could create a separate QObject subclass for each call that holds onto the RunnerContext passed it as a member variable, and that object could do exactly as you describe (and then delete itself when finished). But in such a design what about keeping track of multiple match calls and multiple RunnerContexts? Always populate the most recent one? a currentContext() accessor method? no, that's handled internal to RunnerContext: if it isn't valid (isn't the current one in the main thread), any matches passed are just silently discarded. the nice thing about the current design is that match() methods do not need to be made re-entrant, and this makes it simpler for many of the runners. but it assumes that the runners exit quickly (freeing up the thread pool) and don't rely on any resources that have a single-thread restriction on them (as is the case with the dictionary plasmoid, among one or two others). Could we have both designs avaiable controlled by the aforementioned setReentrant(true) flag? yes, that's exactly what i'm thinking :) -- 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
