Re: widget snap
On Saturday 02 January 2010 10:56:37 Marco Martin wrote: On Saturday 02 January 2010, Roman Shtylman wrote: I was sitting around trying to organize some of my plasmoids... and realized that you can't easily make a stack of plasmoids all exactly aligned ... at least not that I could figure out. I thought it would be really cool to be able to snap plasmoids to other plasmoids as well as to virtual guidelines created by the bounding boxes of the plasmoids. I spent a few hours and finally got the effect I was looking for. Should work for both moves and resizes. Attached is the patch against kdelibs head. Right now the snap strength is hard coded to 3 pixels. ~Roman wonder if it's something more for the layout manager of DesktopContainment or if should really be generic in applethandle.. well custom containments implement their own handle so it's fine i guess. anyways is a good feature. Could still make in for 4.4 or perhaps it has to wait? I'd really like to see this in ASAP, it feels like this was missing for some time already, but I couldn't really pin it down. -- sebas (not the release-team hat on) 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
Re: widget snap
On Saturday 02 January 2010, Sebastian Kügler wrote: On Saturday 02 January 2010 10:56:37 Marco Martin wrote: On Saturday 02 January 2010, Roman Shtylman wrote: I was sitting around trying to organize some of my plasmoids... and realized that you can't easily make a stack of plasmoids all exactly aligned ... at least not that I could figure out. I thought it would be really cool to be able to snap plasmoids to other plasmoids as well as to virtual guidelines created by the bounding boxes of the plasmoids. I spent a few hours and finally got the effect I was looking for. Should work for both moves and resizes. Attached is the patch against kdelibs head. Right now the snap strength is hard coded to 3 pixels. ~Roman wonder if it's something more for the layout manager of DesktopContainment or if should really be generic in applethandle.. well custom containments implement their own handle so it's fine i guess. anyways is a good feature. Could still make in for 4.4 or perhaps it has to wait? I'd really like to see this in ASAP, it feels like this was missing for some time already, but I couldn't really pin it down. Sebas, Roman, soo, let's put it in NOW? (before 5th, plz :p) -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Weather plasmoids ...
On Saturday 02 January 2010 02:13:14 Aaron J. Seigo wrote: On January 1, 2010, Hans Chen wrote: Also, due to a change in the BBC feeds (as far as I know), the search in some weather widgets are broken. This is fixed in 4.4, but since yawp etc. have their own release cycle they're likely already fixed. the URLs for these probably should be in scripts or some other downloadable data file so they can be changed at runtime. having a way to check for updates would also be a reasonable idea. Actually, the extraction of data from websites should be scripted and thus updatable via GHNS... -- 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
Re: widget snap
The downside I saw with putting it into the DestopContainment was that handling things like snap on resize become much harder because the resize event has already happened for the plasmoid. To snap on resize, you have to adjust the new size during the resize event. Also, the information about what is happening to the plasmoid (moving or resizing ...etc) would all have to be propagated to the DesktopContainment layout manager and I didn't see an easy or clear way to do that... but I might have overlooked something. My first thoughts were to do it in the desktop containment but the information wasn't there so I moved over to the handle. ~Roman On Sat, Jan 2, 2010 at 10:21 AM, Marco Martin notm...@gmail.com wrote: On Saturday 02 January 2010, Sebastian Kügler wrote: On Saturday 02 January 2010 10:56:37 Marco Martin wrote: On Saturday 02 January 2010, Roman Shtylman wrote: I was sitting around trying to organize some of my plasmoids... and realized that you can't easily make a stack of plasmoids all exactly aligned ... at least not that I could figure out. I thought it would be really cool to be able to snap plasmoids to other plasmoids as well as to virtual guidelines created by the bounding boxes of the plasmoids. I spent a few hours and finally got the effect I was looking for. Should work for both moves and resizes. Attached is the patch against kdelibs head. Right now the snap strength is hard coded to 3 pixels. ~Roman wonder if it's something more for the layout manager of DesktopContainment or if should really be generic in applethandle.. well custom containments implement their own handle so it's fine i guess. anyways is a good feature. Could still make in for 4.4 or perhaps it has to wait? I'd really like to see this in ASAP, it feels like this was missing for some time already, but I couldn't really pin it down. Sebas, Roman, soo, let's put it in NOW? (before 5th, plz :p) -- Marco Martin ___ 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: Review Request: Show the currently selected sensor in bubblemon applet settings
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/2464/#review3558 --- Ship it! Ok, seems to be good. Can be committed after feature freeze is over. - Shantanu On 2009-12-30 16:24:41, sudhendu kumar wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/2464/ --- (Updated 2009-12-30 16:24:41) Review request for Plasma. Summary --- The patch shows the currently selected sensor in bubblemon applet settings dialog. Previously it was difficult for the user to make out which sensor was selected.The patch scrolls to the currently selected sensor. Hope this is fine, it's my first patch. Diffs - trunk/KDE/kdeplasma-addons/applets/bubblemon/src/bubble.cpp 1067555 Diff: http://reviewboard.kde.org/r/2464/diff Testing --- Tested on trunk.The patch works correctly. Thanks, sudhendu ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Show the currently selected sensor in bubblemon applet settings
On 2010-01-02 18:04:46, Shantanu Tushar Jha wrote: Ok, seems to be good. Can be committed after feature freeze is over. i would say that this is a bugfix and can be committed now, hopefully before rc1 is tagged - Beat --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/2464/#review3558 --- On 2009-12-30 16:24:41, sudhendu kumar wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/2464/ --- (Updated 2009-12-30 16:24:41) Review request for Plasma. Summary --- The patch shows the currently selected sensor in bubblemon applet settings dialog. Previously it was difficult for the user to make out which sensor was selected.The patch scrolls to the currently selected sensor. Hope this is fine, it's my first patch. Diffs - trunk/KDE/kdeplasma-addons/applets/bubblemon/src/bubble.cpp 1067555 Diff: http://reviewboard.kde.org/r/2464/diff Testing --- Tested on trunk.The patch works correctly. Thanks, sudhendu ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: widget snap
On Saturday 02 January 2010, Roman Shtylman wrote: The downside I saw with putting it into the DestopContainment was that handling things like snap on resize become much harder because the resize event has already happened for the plasmoid. To snap on resize, you have to adjust the new size during the resize event. Also, the information about what is happening to the plasmoid (moving or resizing ...etc) would all have to be propagated to the DesktopContainment layout manager and I didn't see an easy or clear way to do that... but I might have overlooked something. My first thoughts were to do it in the desktop containment but the information wasn't there so I moved over to the handle. yeah, let's go for the handle, can you commit it? Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: how can I access DataEngines from JavaScript in the Web Plasmoids?
On Fri, Jan 1, 2010 at 8:56 PM, Aaron J. Seigo ase...@kde.org wrote: requires today's trunk for everything to work perfectly enjoy. thanks, today's trunk is what will become kde 4.4 right? Or has that moved to a branch already? ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Show the currently selected sensor in bubblemon applet settings
On 2010-01-02 18:04:46, Shantanu Tushar Jha wrote: Ok, seems to be good. Can be committed after feature freeze is over. Beat Wolf wrote: i would say that this is a bugfix and can be committed now, hopefully before rc1 is tagged Committed revision 1069074. Close the review as submitted. - Shantanu --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/2464/#review3558 --- On 2009-12-30 16:24:41, sudhendu kumar wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/2464/ --- (Updated 2009-12-30 16:24:41) Review request for Plasma. Summary --- The patch shows the currently selected sensor in bubblemon applet settings dialog. Previously it was difficult for the user to make out which sensor was selected.The patch scrolls to the currently selected sensor. Hope this is fine, it's my first patch. Diffs - trunk/KDE/kdeplasma-addons/applets/bubblemon/src/bubble.cpp 1067555 Diff: http://reviewboard.kde.org/r/2464/diff Testing --- Tested on trunk.The patch works correctly. Thanks, sudhendu ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: how can I access DataEngines from JavaScript in the Web Plasmoids?
On Saturday 02 January 2010 03:56:48 Aaron J. Seigo wrote: On January 1, 2010, Patrick Aljord wrote: I just read a comment by Aaron saying that DataEngines can be accesed from JavaScript in the Web Plasmoids. I tried to figured how it can be done but couldn't so far. Any clue? :) kdeexamples/plasma/webkit/plasmoids/ requires today's trunk for everything to work perfectly I think dataengines in webkit plasmoids have worked since KDE 4.3. Webkit applet using dataengines, config dialog etc.: http://www.gitorious.org/pdamsten/plasmoids/blobs/master/scriptedimage/contents/code/main.html Petri 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: KDE/kdebase/workspace/plasma/generic/scriptengines/webkit
On January 2, 2010, Petri Damstén wrote: On Saturday 02 January 2010 03:55:40 Aaron J. Seigo wrote: SVN commit 1068805 by aseigo: make DataEngines work again For webkit pasmoids dataEngine, config and globalConfig are already exposed in plasmawebapplet.h. Is this for some other use? right now the webkit plasmoid API is a litte schizo. it's also pretty much unlike the other script engines which expose a plasmoid object (not an applet object...). taking a step back and looking at it (instead of just trying to make things that used to work do so again), i think what should be done is pretty straightforward: the plasma object should just be removed, knownDataEngines moved into PlasmaWebApplet and the applet object should be renamed plasmoid. also, in my experience, it's pretty likely that if the PlasmaWebApplet object gets any sot of sophistication to it that the C++ class behind the plasmoid JS object will want to be split out, otherwise we end up with things leaking into the JS by accident and the code in PlasmaWebApplet will get more and more of a complex combination of both the ScriptEngine and the JS stuff. for now it's probably fine, though. the rest of the things should be fixed for 4.4, as we really can't screw around with the API after that as it seems ;) people are actually using it to do things now. i'm just about done doing the above and will commit in a bit. this API also needs to be documented under here: http://techbase.kde.org/Development/Tutorials/Plasma#Plasma_Programming_with_Web_Technologies_.28HTML.2FJS.2FCSS_etc.29 probably an API page as we did with the JavaScript and another tutorial showing the use of dataengines and configuration -- 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 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: how can I access DataEngines from JavaScript in the Web Plasmoids?
On January 2, 2010, Petri Damstén wrote: On Saturday 02 January 2010 03:56:48 Aaron J. Seigo wrote: On January 1, 2010, Patrick Aljord wrote: I just read a comment by Aaron saying that DataEngines can be accesed from JavaScript in the Web Plasmoids. I tried to figured how it can be done but couldn't so far. Any clue? :) kdeexamples/plasma/webkit/plasmoids/ requires today's trunk for everything to work perfectly I think dataengines in webkit plasmoids have worked since KDE 4.3. ugh, yes, indeed. (been looking through the svn history this morning, though the moving of things around in trunk, e.g. the scriptengines from workspace/plasma/scriptengines to workspace/plasma/generic/scriptengines, has made that a lot more difficult). the problem is that the API is utterly unlike the other scriptengines and the tests that were in the webkit/tests/ directory since day 1 of this script engine's existence were completely ignored by subsequent work and they stopped functioning. funny and sad :) (i've since moved the data engine test to kdeexamples and spified it up a bit more) right now there are two objects in the JS of the webkit plasmoids: plasma and applet. plasma contains one method: knownDataEngines. this is the old style API from 4.2, even, and should be listAllDataEngines. besides that, it really doesn't make sense to have two different objects, one which has exactly one function in it. confusing++, when one will do just fine. moreover, we are calling the object plasmoid in the QScript-driven JavaScript ScriptEngine, and applet in the WebKit one. the lack of consistency isn't good. it sucks to change the API at this point, but it doesn't look like this API was very well groomed to start with. we've changed some of the API in the JavaScript API as well in 4.4, so i'd like to get this all right for 4.4 (as much as we can do such a thing) and commit to API stability from 4.4 on for both JavaScript and WebKit driven plasmoids. i will commit shortly. sorry for breaking your plasmoids with this, but the fixes are easy and should never have been necessary if we'd been watching over this script engine with more diligence and care. -- 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 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: widget snap
On January 1, 2010, Roman Shtylman wrote:
I was sitting around trying to organize some of my plasmoids... and
realized that you can't easily make a stack of plasmoids all exactly
aligned ... at least not that I could figure out. I thought it would
snapping is a nice idea. putting it in the handle is pretty much the only
way to do it right now, but it's not a great solution: it means that click-
dragging on applets that support that, which is many/most of them, will work
differently than when dragging on the handle. i have already observed people
not figuring out how to drag widgets from the desktop to the panel because of
this handles are magical behaviour.
it's also going to break / do unhappy things for any containment that doesn't
(for whatever reason) want such behavior.
this really does belong to the Containment, but it needs support in the
handle. adding to this mess is that the handle is in libplasma at all: it
isn't used by all Containments (think of panels, for instance, or amarok).
so, what are the handles for then? well, they do two things:
* provide quick and discoverable access to features like resize, remove and
configuration
* guarantee that we have a click-and-drag surface for applets that may not
provide one
the handle can't simply be moved into, e.g., DesktopContainment as really all
plasma-desktop desktop containments should have them. to me, it sounds like
we need to think about how handles are done and do them better. they need to
be:
* sharable between Containments (for consistency and code sharing)
* allowed to be specific to the application or the Containment
* be able to coordinate with the Containment on layout issues
* have logic for things like moving to another Containment moved outside the
handle to API that is available to the handle but which is actually native
to the Applet class so that we get rid of the when you use the handle, it
behaves this way; when you click on the applet it behaves that way behaviour
as for the patch as posted, here are my thoughts/comments/questions:
* instead of 'srect' how about 'snapRect' or 'snapToBoundingRect' or something
that actually says what it is? cryptic names for variables make code harder to
read and therefore maintain
* why is the background FrameSvg's _mask_ being used to generate the rect?
that's going to be a lot more pixmap allocation and disk cache hitting since i
don't think the masks are created for Applet backgrounds otherwise. looks
incorrect, and could be significant from a performance perspective
* we use the KDE Libs coding style. please conform to that:
http://techbase.kde.org/Policies/Kdelibs_Coding_Style
in particular things like:
+if (qAbs(y1) snapDist)
+moveBy.setY(y1);
+else if (qAbs(y2) snapDist)
+moveBy.setY(y2);
should be:
+if (qAbs(y1) snapDist) {
+moveBy.setY(y1);
+} else if (qAbs(y2) snapDist) {
+moveBy.setY(y2);
* there is a lot of pre-calculation of values which are only used once later
on, e.g. const qreal x1 = drect.right() - srect.right(); which is used 14
lines later. this means that when i want to see what x1 is to understand
what is going on, i have to backtrack 14 lines. why not just:
+if (qAbs(x1) snapDist) {
+moveBy.setX(otherSnapRect.right() -
snapRect.right());
seems much more readable?
* finally, i wouldn't bother with the moveBy QPointF; it doesn't match with
the QGraphicsItem API very well and is just another object to allocate. i'd
just define two qreals (dx and dy?) and do sth like:
+if (dx != 0 || dy != 0) {
+m_applet-moveBy(dx, dy);
+break;
+}
that's just a minor point really, though :)
the big issue is doing this correctly. as such, my feeling is that we should
hold on to this patch and do it right for 4.5. there's no rush it in imho,
even though it is very nice to have.
Roman, would you be interested in working on this further and using it as an
excuse to improve the whole how handles work thing? it shouldn't be a very
big project, but one that would definitely have some nice benefits for all
users of Plasma.
--
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
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: widget snap
On Saturday 02 January 2010, Aaron J. Seigo wrote: On January 1, 2010, Roman Shtylman wrote: I was sitting around trying to organize some of my plasmoids... and realized that you can't easily make a stack of plasmoids all exactly aligned ... at least not that I could figure out. I thought it would snapping is a nice idea. putting it in the handle is pretty much the only way to do it right now, but it's not a great solution: it means that click- dragging on applets that support that, which is many/most of them, will work differently than when dragging on the handle. i have already observed people not figuring out how to drag widgets from the desktop to the panel because of this handles are magical behaviour. it's also going to break / do unhappy things for any containment that doesn't (for whatever reason) want such behavior. this really does belong to the Containment, but it needs support in the handle. adding to this mess is that the handle is in libplasma at all: it isn't used by all Containments (think of panels, for instance, or amarok). so, what are the handles for then? well, they do two things: * provide quick and discoverable access to features like resize, remove and configuration * guarantee that we have a click-and-drag surface for applets that may not provide one the handle can't simply be moved into, e.g., DesktopContainment as really all plasma-desktop desktop containments should have them. to me, it sounds like we need to think about how handles are done and do them better. they need to be: * sharable between Containments (for consistency and code sharing) * allowed to be specific to the application or the Containment sick idea: how about making handles plugins? the base is really minimal, so most of the implementation could be shipped alongside the workspace.. * be able to coordinate with the Containment on layout issues i don't know if something could be shared in really different situations (free layout vs panel, could it be any code sharing at all?) * have logic for things like moving to another Containment moved outside the handle to API that is available to the handle but which is actually native to the Applet class so that we get rid of the when you use the handle, it behaves this way; when you click on the applet it behaves that way behaviour that also reminds me how bad at the moment Applet::registerAsDragHandle() works.. now if there is for instance the analog clock in the newspaper is possible to drag the whole page around out of the supposed boudaries by dragging the clock around, ir really ugly but didn't find a way at all to prevent it Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: widget snap
Aaron: I will make those style changes (was not aware of the coding style page and tried to make it match as much as possible to what I saw). The reason for the x1...y4 is to avoid doing the calculation twice (in your example to fix it you still had the x1 there and that calculation would have to be done twice). I make it const so that if anything the compiler sees it won't change and might optimize something away. I will change the usage of QPointF to just two qreal as that seems perfectly reasonable considering how the QGraphicsItem api is. The use of the 'mask' was the way I was able to get the plasmoids to snap to the visible border. Just using the bounding rectangles includes the frame which includes the frame shadow. I might have missed it but there was no method to get the side for the part of the frame without the shadow. I did look at the svg image and saw an item called hint-stretch-borders that looked to be around the right size, but was unsure. I could add that to the FrameSvg api to provide that metric and then just use that. I am aware of the performance implications of making those cached masks but without knowing more about the hint-stretch-border item was hesitant to use it for sizing and thus had to rely on the mask for the true visual coordinates to snap to. I would be happy to look at the handles further and see how they can be improved/changed in their behavior and existence in the codebase. I can't commit cause I don't have an svn account (thus I send the patches :) In general I like the handles and I think that they could be used to make the plasmoids more interactive for those that want it. ~Roman On Sat, Jan 2, 2010 at 4:08 PM, Marco Martin notm...@gmail.com wrote: On Saturday 02 January 2010, Aaron J. Seigo wrote: On January 1, 2010, Roman Shtylman wrote: I was sitting around trying to organize some of my plasmoids... and realized that you can't easily make a stack of plasmoids all exactly aligned ... at least not that I could figure out. I thought it would snapping is a nice idea. putting it in the handle is pretty much the only way to do it right now, but it's not a great solution: it means that click- dragging on applets that support that, which is many/most of them, will work differently than when dragging on the handle. i have already observed people not figuring out how to drag widgets from the desktop to the panel because of this handles are magical behaviour. it's also going to break / do unhappy things for any containment that doesn't (for whatever reason) want such behavior. this really does belong to the Containment, but it needs support in the handle. adding to this mess is that the handle is in libplasma at all: it isn't used by all Containments (think of panels, for instance, or amarok). so, what are the handles for then? well, they do two things: * provide quick and discoverable access to features like resize, remove and configuration * guarantee that we have a click-and-drag surface for applets that may not provide one the handle can't simply be moved into, e.g., DesktopContainment as really all plasma-desktop desktop containments should have them. to me, it sounds like we need to think about how handles are done and do them better. they need to be: * sharable between Containments (for consistency and code sharing) * allowed to be specific to the application or the Containment sick idea: how about making handles plugins? the base is really minimal, so most of the implementation could be shipped alongside the workspace.. * be able to coordinate with the Containment on layout issues i don't know if something could be shared in really different situations (free layout vs panel, could it be any code sharing at all?) * have logic for things like moving to another Containment moved outside the handle to API that is available to the handle but which is actually native to the Applet class so that we get rid of the when you use the handle, it behaves this way; when you click on the applet it behaves that way behaviour that also reminds me how bad at the moment Applet::registerAsDragHandle() works.. now if there is for instance the analog clock in the newspaper is possible to drag the whole page around out of the supposed boudaries by dragging the clock around, ir really ugly but didn't find a way at all to prevent it Cheers, Marco Martin ___ 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
