Re: Review Request: Password character support in PlasmaComponents.TextField
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104726/#review12920 --- This review has been submitted with commit 02106d3d4cbaf3434b231cac6cfe444bcc26a688 by Aurélien Gâteau to branch master. - Commit Hook On April 25, 2012, 4:10 p.m., Aurélien Gâteau wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104726/ --- (Updated April 25, 2012, 4:10 p.m.) Review request for Plasma and David Edmundson. Description --- TextField password character defaults to the old '*' character. Attached patch sets it to unicode bullet, which is more common nowadays and also expose the property to the outside world (though I am not sure this is really needed, tell me if you'd rather drop it). Diffs - plasma/declarativeimports/plasmacomponents/qml/TextField.qml 10c4cee Diff: http://git.reviewboard.kde.org/r/104726/diff/ Testing --- Thanks, Aurélien Gâteau ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Add keyboard navigation support to PlasmaComponents.ToolButton
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104727/#review12921 --- This review has been submitted with commit b10e79a8db422e2d5a1f65149333e4f9f29f10dc by Aurélien Gâteau to branch master. - Commit Hook On April 25, 2012, 4:32 p.m., Aurélien Gâteau wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104727/ --- (Updated April 25, 2012, 4:32 p.m.) Review request for Plasma and David Edmundson. Description --- ToolButton does not support keyboard navigation. The attached patch fixes this by: - Using the surface item to indicate focus when the flat property is set to true - Not giving focus on click if keyboard navigation is not defined. This is a bit tricky, but I figured it would be odd to have a focus border around a button which is part of a toolbar. I could not think of a better way to figure out whether giving focus on click made sense or not. Diffs - plasma/declarativeimports/plasmacomponents/qml/ToolButton.qml 9e7e715 Diff: http://git.reviewboard.kde.org/r/104727/diff/ Testing --- Running attached test script without the patch, Focusable Button 1 starts focused (this can be seen by pressing space) but there is no indication that it is. With the patch, an hover frame appears around the focused button. Pressing tab moves the focus to Focusable Button 2 which gets the hover frame. Clicking one of the focusable buttons gives them focus as well, but clicking one of the toolbar buttons does not, since keyboard navigation is not defined for them. Thanks, Aurélien Gâteau ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request: Improve PlasmaComponents.ToolButton layout
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104735/ --- Review request for Plasma and David Edmundson. Description --- This patch fixes two issues in ToolButton layout: 1. Make sure there is some space between the button icon and its text 2. Do not enforce a minimum width The reason for #2 is that having a minimum width does not make much sense for a ToolButton: - It should aim at using the minimum amount of horizontal space when used in a ToolBar. - It looks unbalanced when used with an icon because the content is flushed to the left, leaving a large amount of white-space on the right. (See attached screenshots) Diffs - plasma/declarativeimports/plasmacomponents/qml/ToolButton.qml 0447a69 Diff: http://git.reviewboard.kde.org/r/104735/diff/ Testing --- Run attached test script, you should notice the differences in spacing between button icon and text, as well as in the white-space on the right of the button. Screenshots --- Before http://git.reviewboard.kde.org/r/104735/s/545/ After http://git.reviewboard.kde.org/r/104735/s/546/ Thanks, Aurélien Gâteau ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Files, config, and welcome (again)
On Sunday, April 15, 2012 10:14:13 Djuro Drljaca wrote: Hello, as far as I know it is very important to know where you tested it. If you only tested it in the plasmoidveiwer then this is probably the reason it doesn't work. .. which would mean the plasmoid has a bug and needs to implement configChanged. -- Aaron J. Seigo 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: Next Iteration Sprint, confirmed !
On Monday, April 23, 2012 17:42:42 Martin Gräßlin wrote: My expectation from the sprint is that we will figure out a new interaction of the shell and windowing system which is not possible at the moment. We have pretty much reached what's possible with Plasma tells KWin what to do. But turning it around (Plasma becomes a plugin to KWin) will give us complete new possibilities which I will start to explore as soon as we are in feature freeze. i am currently very, very sceptical about this approach. this is because it is a set of statements with no foundation. * what would be the potential improvements? * what are the realistic improvements? * why can't it be done with the current way it is done? * why is a whole new shell needed at all? * do we really want to weld everything together? (this is not zero cost) * and most importantly: why will the user care? * what is our end goal / motivation? anytime i see a new shell i get shivers running up and down all the wrong places of my body. i've yet to see the above laid out cleanly and until that happens, there's no way to make a good decision. if we simply state the result before the reasons are well understood then we may as well bring out the roulette table, spin it and let it decide what we do next. :) -- Aaron J. Seigo 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: Next Iteration Sprint, confirmed !
On Monday, April 23, 2012 12:21:17 Sebastian Kügler wrote: Those cannot be dismissed as technology before vision because we already have identified these things as crucial to move on with our vision. Now it's this is, imo, the crux of the matter: our vision many of the people who will be attending do not know what our vision is. and the intention of the meeting is to expand the definition of us to include more people so that there are more hands working on plasma with enthusiasm, and so that we can harmonize more of the individual components together. whenever more people are brought in, assuming it is not a top-down dictatorship (which is not what i want plasma to be :), then that vision will in some way shift. they will bring new creativity, new perspectives .. it's also hard to buy 100% into something that you have not had some say in. we need to be able to share control over the definition of what this is; this takes time and can not happen immediately. there is also a responsibility on the shoulders of those who come in fresh: to learn the existing thinking and appreciate how it was arrived at and why. they need to be respectful of the house they are entering, realizing that this is someone else's holy space, someone else's place of work .. so there's a give and take ballance here. so when we talk about creating a vision that's not quite perfectly accurate. what we need to do is generate a *shared vision*. that starts with what is already there. we need to share that vision so we can bring together the various individuals and communities under one banner and work effectively alongside each other. and yes, the vision will innevitably take on new colours and textures, reflecting those involved. so ... let's not worry too much about what the results will be quite yet. let's focus first on transmitting the history and vision of plasma to those who do not know it yet, and then work building from that foundation. -- Aaron J. Seigo 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: Next Iteration Sprint, confirmed !
On Monday, April 23, 2012 17:40:48 Alex Fiestas wrote: That doesn't mean that I won't work on libplasma2 and QML effort porting for the greater good, but they are not my responsability just right now, they will be int he future (I guess). i think some may have the concern that if the meeting goes off in some very new direction that it will make it even harder to draw resources towards what we already know needs to be done. one of the responsibilities of those entering will be to ensure the paths that are decided on enable what needs to be done. :) -- Aaron J. Seigo 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
Plasma Active Image
Hi all, I wanted to check if there is a recommendation for a Plasma Active based OS image for the tablet Intel handed out at last year's desktop summit. I am going to present KDE at a local FOSS event on Saturday and thought showing Plasma Active would be cool :) Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring 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: Plasma Active Image
On Thursday 26 April 2012, Kevin Krammer wrote: Hi all, I wanted to check if there is a recommendation for a Plasma Active based OS image for the tablet Intel handed out at last year's desktop summit. I am going to present KDE at a local FOSS event on Saturday and thought showing Plasma Active would be cool :) Hi Kevin, yeah, that would be cool indeed, let us know how it went ;) at the moment there are some issues in the last mer updates, so i think the safe side would be this: http://share.basyskom.com/contour/Deployment/MeeGo_x86_USB_Live_and_Install_Archive/2012-04-23-17-40- basyskom-plasma-active-devel-meego-usb-live.iso is quite well tested on the exopc Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma Active Image
On Thursday, 2012-04-26, Marco Martin wrote: On Thursday 26 April 2012, Kevin Krammer wrote: Hi all, I wanted to check if there is a recommendation for a Plasma Active based OS image for the tablet Intel handed out at last year's desktop summit. I am going to present KDE at a local FOSS event on Saturday and thought showing Plasma Active would be cool :) Hi Kevin, yeah, that would be cool indeed, let us know how it went ;) at the moment there are some issues in the last mer updates, so i think the safe side would be this: http://share.basyskom.com/contour/Deployment/MeeGo_x86_USB_Live_and_Install _Archive/2012-04-23-17-40- basyskom-plasma-active-devel-meego-usb-live.iso is quite well tested on the exopc I will try that one, thanks! Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring 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: Improve PlasmaComponents.ToolButton layout
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104735/#review12924 --- Ship it! Looks much better this way. - Sebastian Kügler On April 26, 2012, 8:27 a.m., Aurélien Gâteau wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104735/ --- (Updated April 26, 2012, 8:27 a.m.) Review request for Plasma and David Edmundson. Description --- This patch fixes two issues in ToolButton layout: 1. Make sure there is some space between the button icon and its text 2. Do not enforce a minimum width The reason for #2 is that having a minimum width does not make much sense for a ToolButton: - It should aim at using the minimum amount of horizontal space when used in a ToolBar. - It looks unbalanced when used with an icon because the content is flushed to the left, leaving a large amount of white-space on the right. (See attached screenshots) Diffs - plasma/declarativeimports/plasmacomponents/qml/ToolButton.qml 0447a69 Diff: http://git.reviewboard.kde.org/r/104735/diff/ Testing --- Run attached test script, you should notice the differences in spacing between button icon and text, as well as in the white-space on the right of the button. Screenshots --- Before http://git.reviewboard.kde.org/r/104735/s/545/ After http://git.reviewboard.kde.org/r/104735/s/546/ Thanks, Aurélien Gâteau ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Improve PlasmaComponents.ToolButton layout
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104735/#review12925 --- i agree that looks better here, but i would use thins only for the toolbutton (and not doing a similar thing for pushbuttons) the reason is in part aestetic (if they are stacked vertically they look better if they have the same width) and in part technical: plasma will try to share the rendered svgs both in memory and in disk cache, so the more elements with exactly the same size there are, the more memory is saved - Marco Martin On April 26, 2012, 8:27 a.m., Aurélien Gâteau wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104735/ --- (Updated April 26, 2012, 8:27 a.m.) Review request for Plasma and David Edmundson. Description --- This patch fixes two issues in ToolButton layout: 1. Make sure there is some space between the button icon and its text 2. Do not enforce a minimum width The reason for #2 is that having a minimum width does not make much sense for a ToolButton: - It should aim at using the minimum amount of horizontal space when used in a ToolBar. - It looks unbalanced when used with an icon because the content is flushed to the left, leaving a large amount of white-space on the right. (See attached screenshots) Diffs - plasma/declarativeimports/plasmacomponents/qml/ToolButton.qml 0447a69 Diff: http://git.reviewboard.kde.org/r/104735/diff/ Testing --- Run attached test script, you should notice the differences in spacing between button icon and text, as well as in the white-space on the right of the button. Screenshots --- Before http://git.reviewboard.kde.org/r/104735/s/545/ After http://git.reviewboard.kde.org/r/104735/s/546/ Thanks, Aurélien Gâteau ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Improve PlasmaComponents.ToolButton layout
On April 26, 2012, 12:15 p.m., Marco Martin wrote: i agree that looks better here, but i would use thins only for the toolbutton (and not doing a similar thing for pushbuttons) the reason is in part aestetic (if they are stacked vertically they look better if they have the same width) and in part technical: plasma will try to share the rendered svgs both in memory and in disk cache, so the more elements with exactly the same size there are, the more memory is saved I am not sure what you mean with only for the toolbutton: this patch only touches ToolButton. I agree a column of buttons look nicer if they have the same width, but defining a minimum width in ToolButton is not the correct way to go: if the text of some buttons is longer than the minimum width, those buttons won't be correctly aligned with the others (and you can't rely on the text staying short enough once translated). To ensure all widgets in a column to have the same width, you have to enforce it at the column level. Regarding the memory reason: I believe internal optimizations should not dictate the appearance of the UI, so I don't think this is a valid reason. - Aurélien --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104735/#review12925 --- On April 26, 2012, 8:27 a.m., Aurélien Gâteau wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104735/ --- (Updated April 26, 2012, 8:27 a.m.) Review request for Plasma and David Edmundson. Description --- This patch fixes two issues in ToolButton layout: 1. Make sure there is some space between the button icon and its text 2. Do not enforce a minimum width The reason for #2 is that having a minimum width does not make much sense for a ToolButton: - It should aim at using the minimum amount of horizontal space when used in a ToolBar. - It looks unbalanced when used with an icon because the content is flushed to the left, leaving a large amount of white-space on the right. (See attached screenshots) Diffs - plasma/declarativeimports/plasmacomponents/qml/ToolButton.qml 0447a69 Diff: http://git.reviewboard.kde.org/r/104735/diff/ Testing --- Run attached test script, you should notice the differences in spacing between button icon and text, as well as in the white-space on the right of the button. Screenshots --- Before http://git.reviewboard.kde.org/r/104735/s/545/ After http://git.reviewboard.kde.org/r/104735/s/546/ Thanks, Aurélien Gâteau ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Improve PlasmaComponents.ToolButton layout
On April 26, 2012, 12:15 p.m., Marco Martin wrote: i agree that looks better here, but i would use thins only for the toolbutton (and not doing a similar thing for pushbuttons) the reason is in part aestetic (if they are stacked vertically they look better if they have the same width) and in part technical: plasma will try to share the rendered svgs both in memory and in disk cache, so the more elements with exactly the same size there are, the more memory is saved Aurélien Gâteau wrote: I am not sure what you mean with only for the toolbutton: this patch only touches ToolButton. I agree a column of buttons look nicer if they have the same width, but defining a minimum width in ToolButton is not the correct way to go: if the text of some buttons is longer than the minimum width, those buttons won't be correctly aligned with the others (and you can't rely on the text staying short enough once translated). To ensure all widgets in a column to have the same width, you have to enforce it at the column level. Regarding the memory reason: I believe internal optimizations should not dictate the appearance of the UI, so I don't think this is a valid reason. what i said is that this patch is ok as is touches only toolbutton, i just wouldn't want a similar one for pushbutton. as for the memory, right now decreasing memory usage is my #1 priority, we simply can't forget that constraints do exist, sorry. - Marco --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104735/#review12925 --- On April 26, 2012, 8:27 a.m., Aurélien Gâteau wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104735/ --- (Updated April 26, 2012, 8:27 a.m.) Review request for Plasma and David Edmundson. Description --- This patch fixes two issues in ToolButton layout: 1. Make sure there is some space between the button icon and its text 2. Do not enforce a minimum width The reason for #2 is that having a minimum width does not make much sense for a ToolButton: - It should aim at using the minimum amount of horizontal space when used in a ToolBar. - It looks unbalanced when used with an icon because the content is flushed to the left, leaving a large amount of white-space on the right. (See attached screenshots) Diffs - plasma/declarativeimports/plasmacomponents/qml/ToolButton.qml 0447a69 Diff: http://git.reviewboard.kde.org/r/104735/diff/ Testing --- Run attached test script, you should notice the differences in spacing between button icon and text, as well as in the white-space on the right of the button. Screenshots --- Before http://git.reviewboard.kde.org/r/104735/s/545/ After http://git.reviewboard.kde.org/r/104735/s/546/ Thanks, Aurélien Gâteau ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: Next Iteration Sprint, confirmed !
On Thursday 26 April 2012 12:41:32 Aaron J. Seigo wrote: On Monday, April 23, 2012 17:42:42 Martin Gräßlin wrote: My expectation from the sprint is that we will figure out a new interaction of the shell and windowing system which is not possible at the moment. We have pretty much reached what's possible with Plasma tells KWin what to do. But turning it around (Plasma becomes a plugin to KWin) will give us complete new possibilities which I will start to explore as soon as we are in feature freeze. i am currently very, very sceptical about this approach. this is because it is a set of statements with no foundation. * what would be the potential improvements? * what are the realistic improvements? * why can't it be done with the current way it is done? * why is a whole new shell needed at all? * do we really want to weld everything together? (this is not zero cost) * and most importantly: why will the user care? * what is our end goal / motivation? Your questions are very valid and important. And I will try to provide some reasoning for it. If we look around we see that both GNOME Shell and Unity went for an approach to integrate the desktop shell into the compositor and did not follow KDE's working approach. At the time when we introduced Plasma we were the only Desktop Shell being able at all to integrate Compositor and Desktop Shell, so why did they invent a new wheel instead of following our approach? I evaluated that question and came to the conclusion that if we would start all over today we would do the same. Something like GNOME Shell could not be implemented with our current solution. I give now some examples of things which are just not possible with Plasma and KWin being two different applications. Please note that I consider those as examples and not as something I propose to do. * combine present windows with application launching (e.g. SAL, Kickoff or KRunner) * include running windows in search and launch * Tasks Applets showing live thumbnails instead of icons * Include window/desktop thumbnails in QML (showstopper for tooltips) * Include thumbnails of running windows in an application launcher and still having smooth scrolling We also see that our current solution has rough edges which we could not solve yet: * Panel tooltips movement not really synchronized/smooth * No crossfading between thumbnail tooltips when going from one item to another * Inability to identify windows of the desktop shell to give them special treatment * Dashboard conflicting with window management * Conflicting screen edges for auto-hiding panels * same context menu for KWin and Tasks Many of those issues seem to not exist on competitve (proprietary) platforms and it makes me really sad seeing our competitors having better solutions in that area given that our technology and our features are all there and in fact much better. At the same time we know from many projects we have worked on that the current solution is just hackish and does not scale. Just remember the window strip in PA 1/2. A complete nasty hack, which was extremely slow. This was solved by bringing Plasma technology into KWin: QML, Plasma Components and Plasma Packages. Our current solution to KWin/Plasma integration is adding more X atoms. Sorry but I don't want to see any more X atoms passed around. It's an extremely hacky and ugly solution requiring the synchronisation of three processes compared to having the same with QML in just one. anytime i see a new shell i get shivers running up and down all the wrong places of my body. i've yet to see the above laid out cleanly and until that happens, there's no way to make a good decision. if we simply state the result before the reasons are well understood then we may as well bring out the roulette table, spin it and let it decide what we do next. :) You are of course right with that and that's nothing I want to do. I was just afraid that we are in our thinking of what is possible and what not which would limit our ideas. If we would not even think about possibilities like what GNOME Shell is doing with the dash just because we think it's not possible, it could end up quite bad. That's why I just mentioned that I see a huge potential if we step aside from what we have, open our mind (even if it results in a shivering Aaron ;-) and start thinking and dreaming. I am sure that we can find technical solutions to quite some of our current problems if we open up our mind. That's why I also think it is important to open up to new contributors who could bring in a lot of manpower which is currently lacking in Plasma. If I see correctly there is a large amount of sponsored developers coming to the sprint. Which makes me quite happy :-) Cheers Martin 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: Improve PlasmaComponents.ToolButton layout
On April 26, 2012, 12:15 p.m., Marco Martin wrote: i agree that looks better here, but i would use thins only for the toolbutton (and not doing a similar thing for pushbuttons) the reason is in part aestetic (if they are stacked vertically they look better if they have the same width) and in part technical: plasma will try to share the rendered svgs both in memory and in disk cache, so the more elements with exactly the same size there are, the more memory is saved Aurélien Gâteau wrote: I am not sure what you mean with only for the toolbutton: this patch only touches ToolButton. I agree a column of buttons look nicer if they have the same width, but defining a minimum width in ToolButton is not the correct way to go: if the text of some buttons is longer than the minimum width, those buttons won't be correctly aligned with the others (and you can't rely on the text staying short enough once translated). To ensure all widgets in a column to have the same width, you have to enforce it at the column level. Regarding the memory reason: I believe internal optimizations should not dictate the appearance of the UI, so I don't think this is a valid reason. Marco Martin wrote: what i said is that this patch is ok as is touches only toolbutton, i just wouldn't want a similar one for pushbutton. as for the memory, right now decreasing memory usage is my #1 priority, we simply can't forget that constraints do exist, sorry. OK, thanks for the clarification, I am going to merge it then. - Aurélien --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104735/#review12925 --- On April 26, 2012, 8:27 a.m., Aurélien Gâteau wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104735/ --- (Updated April 26, 2012, 8:27 a.m.) Review request for Plasma and David Edmundson. Description --- This patch fixes two issues in ToolButton layout: 1. Make sure there is some space between the button icon and its text 2. Do not enforce a minimum width The reason for #2 is that having a minimum width does not make much sense for a ToolButton: - It should aim at using the minimum amount of horizontal space when used in a ToolBar. - It looks unbalanced when used with an icon because the content is flushed to the left, leaving a large amount of white-space on the right. (See attached screenshots) Diffs - plasma/declarativeimports/plasmacomponents/qml/ToolButton.qml 0447a69 Diff: http://git.reviewboard.kde.org/r/104735/diff/ Testing --- Run attached test script, you should notice the differences in spacing between button icon and text, as well as in the white-space on the right of the button. Screenshots --- Before http://git.reviewboard.kde.org/r/104735/s/545/ After http://git.reviewboard.kde.org/r/104735/s/546/ Thanks, Aurélien Gâteau ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Improve PlasmaComponents.ToolButton layout
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104735/#review12929 --- This review has been submitted with commit ecf7d5090c7e2abbe82e91ef11833885b1763041 by Aurélien Gâteau to branch master. - Commit Hook On April 26, 2012, 8:27 a.m., Aurélien Gâteau wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104735/ --- (Updated April 26, 2012, 8:27 a.m.) Review request for Plasma and David Edmundson. Description --- This patch fixes two issues in ToolButton layout: 1. Make sure there is some space between the button icon and its text 2. Do not enforce a minimum width The reason for #2 is that having a minimum width does not make much sense for a ToolButton: - It should aim at using the minimum amount of horizontal space when used in a ToolBar. - It looks unbalanced when used with an icon because the content is flushed to the left, leaving a large amount of white-space on the right. (See attached screenshots) Diffs - plasma/declarativeimports/plasmacomponents/qml/ToolButton.qml 0447a69 Diff: http://git.reviewboard.kde.org/r/104735/diff/ Testing --- Run attached test script, you should notice the differences in spacing between button icon and text, as well as in the white-space on the right of the button. Screenshots --- Before http://git.reviewboard.kde.org/r/104735/s/545/ After http://git.reviewboard.kde.org/r/104735/s/546/ Thanks, Aurélien Gâteau ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
microblog engine and app
Hi all, As you might know, I've been working on a microblog app, done in Plasma Quick. This app comes in different disguises, as tablet-app, as desktop app and as widget. It uses PlasmaComponents throughout and adapts itself to screen space available. http://simplest-image-hosting.net/png-0-y22117 I've taken the Microblog QML widget, and improved it in many places, mainly rewriting smaller components to be shared, and polishing those. I'm beginning to be quite happy about the UI side, although it's not completely done yet. In order to get the most out of the microblog dataengine, I ended up rewriting large parts of it, especially: (1) authorization: now done using QOAuth (2) avatar handling: now uses an imagecache to reduce network load and traffic (3) feed parsing: now uses JSON instead of XML: faster, less traffic, more features in feeds There's also a good deal of internal restructuring involved, authorization handling is now delegated to a helper class which is managed by the engine, sources use an appropriate helper where necessary. This makes user switching quite a bit easier, as the engine is now better able to deal with different accounts. The Microblog C++ Plasmoids still seems to work (gains from some, but not all of these changes), but as the QML Plasmoid is more than capable of everything the C++ widget does, I'd in fact like to replace that widget (recycling its plugin name for the QML Plasmoid). As to (1), authorization: This adds a new dependency on QOAuth, it seems it's packaged by most distros already, so I don't really expect huge problems there, however, it's still an additional dep, and non-optional (in the sense that you won't get the dataengine if QOAuth is not there). The app or engine does not save the password anymore, it rather saves the oauth accesstoken and -secret to a koauthrc config file. This could also go into kwallet, not 100% sure about that ... thoughts? As to (2), we use the same imagecache file as the previewengine, so these are in principle shared. This one greatly reduces network traffic, since images are loaded in one http request per tweet. Results in a pretty noticable speedup. As to (3), this brings another additional dependency in. The reason to use the JSON format instead of XML are: - the XML feeds do not contain all information, so we end up needing a lot of extra requests - the files are a lot smaller, I've measured about 40% smaller files for JSON feeds than for XML feeds - Code is smaller, JSON is a bit easier to parse (it basically puts everything into a map for you to pick from) - Twitter recommends JSON above XML The dataengine changes are in sebas/qoauth2 branch in kdeplasma-addons, in order to test the app, you need that branch. The applet and app are in declarative-plasmoids master, under microblog/. I'd like to merge especially the engine changes shortly, but as it's quite a huge branch, maybe someone could look over those changes? Thanks -- 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
