Re: Review Request: Save scrollbar position on plasma exit
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104258/ --- (Updated March 16, 2012, 10:02 a.m.) Review request for Plasma, Aaron J. Seigo, Marco Martin, and Fredrik Höglund. Changes --- Discard the scrollbar position restore if the user has manually scrolled the view before the listing is finished. The patch is for IconView only. There is a big problem with doing the same in ListView, actuallly, it is unnecessary there at all. This is why: There is no multi-pass layout in ListView; moreover, when the user clicks the icon in the panel, and the listing starts, the popup won't open before the listing is finished. The user has no chance of scrolling the view before the listing is finished, so the problem doens't even exist there. What botheres me is the Plasma stall on loading a big dir. I think we should port the multiple-pass layout code to the ListView class to ensure responsiveness, but that will be a different review request. Fredrik, what do you think? This RR is finished now, I think it's ready to go. Please, do nitpick :) Description --- This patch implements scrolbar position saving on plasma exit. The change is fairly trivial, however, due to the fact that the view is not populated and layouted immediately simply scrolling to the desired position on creating the view does not work. Instead a signal is emitted on finishing the item layout, when the view has a valid size and the scrollbar has a valid range. The signal is connected to a slot which scrolls the view to the desired position and then disconnects the signal. For the user, a public function in AbstractItemView is introduced, which performs the connection. The only problem is that ListView turned out not to have any layout method. It just paints the items one by one, calculating their position on the fly, so I put the signal at the end of updateScrollbar to ensure the scrollbar range is valid. Maybe it should go into the if (max0) branch? This addresses bug 261139. http://bugs.kde.org/show_bug.cgi?id=261139 Diffs (updated) - plasma/applets/folderview/abstractitemview.h aa68b90 plasma/applets/folderview/abstractitemview.cpp 3debb70 plasma/applets/folderview/folderview.h 4e441eb plasma/applets/folderview/folderview.cpp a94ce87 plasma/applets/folderview/iconview.h 12e93b3 plasma/applets/folderview/iconview.cpp 5c4e086 plasma/applets/folderview/listview.cpp 94efe44 Diff: http://git.reviewboard.kde.org/r/104258/diff/ Testing --- Tested both the icon view and the list view, works fine. Thanks, Ignat Semenov ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Breadcrumbs in Kickoff
Hello, IMHO, when a user makes a request, he will not perform a market study on his demand. He knows his needs and he doesn't ask, nor speaks, for other users hand. I feel an important amount of stress from the developers part, regarding the code involved. From the user part this is unknown. As professional developer, the easy to use a feature is, the harder might be to implement in the code. When I became software developer, I've sworn to satisfy my customers, of course when possible and within the feasible limits. So, I would not reject a requested feature unless I have good technical reasons to prevent it, based on the argument of complexity of code. Of course, maintenance is a good reason to reject when not enough resources are present, in order to support that feature (is this the case?). So, as KDE user, I can't give any statistics, polls, whatever in favor or against this button. I just _feel_ it is better than breadcrumbs for _me_. It is _natural_ to _me_. Form _my_ point of view, breadcrumbs are also useful, as a shortcut, when I need to jump over some elements in the path. So, the back button and breadcrumbs, although seem redundant, they are not, _to me_. I would use the 'back' button in 90% of cases. It is the very same case with Dolphin (the 'Up' button vs the path breadcrumbs), again, _for me_. BTW, not all users that miss the button will complain. Some devs say that these messages are lose of time for them. I can say using the breadcrumbs in the KickOff menu make me losing time too, for the sole reason it is unnatural _to me_ to use it there. Also, user feedback is not a lose of time. Although not many users express their gratitude for the developers work, because, _it seems_, the human nature is to complain about things not working or things not done. Sometimes it should happen. I _need_ to tell you, all the KDE team, that I love your work, some may say _imperfect_, but _great_ I say, knowing the effort you put in keeping it as close as possible to our needs. KDE is, _in my opinion_, well designed, flexible to be extended, clean and visually appealing. And OPEN. Making Plasma and Plasmoids is a good move. It's in the spirit of Linux and its customizability. I hope you keep up this good work for long. Thank you, Mike. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Help us finding the new name for Laptop window decoration
On Thursday, March 15, 2012 02:59:17 PM Martin Gräßlin wrote: Hi all, in order to find a better name for the window decoration Laptop I created a doodle with possible names: Isn't ugly a possible name? :/ ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Remember current desktop when changing activity
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104261/ --- (Updated March 16, 2012, 7:40 a.m.) Review request for KDE Runtime and Plasma. Changes --- Added group Plasma to reviewers group as requested. Description --- Patches kactivitymanagerd to store (and restore back) the working current directory when switching activities. The activity-changing-behavior is as follows: 1. Say you have two (or more activities) A and B. 2. You are working on activity A on Desktop 4. 3. You switch to activity B (and by default to Desktop 4). 4. Change to Desktop 1. 5. Go back to activity A and (by default) to Desktop 1, while it should move you to Desktop 4 (this is where my patch kicks in). I hope it makes sense :-) This addresses bugs 241864 and 265015. http://bugs.kde.org/show_bug.cgi?id=241864 http://bugs.kde.org/show_bug.cgi?id=265015 Diffs - service/ActivityManager.cpp 7af2049 service/ActivityManager_p.h d054eb7 Diff: http://git.reviewboard.kde.org/r/104261/diff/ Testing --- Thanks, makis marimpis ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Breadcrumbs in Kickoff
Hi Mihai, there has already been a lengthy discussion about breadcrumbs in Kickoff back in December [1]. I don't think anyone is interested in having yet another discussion about that topic. Thanks. Martin Gräßlin [1] http://mail.kde.org/pipermail/plasma-devel/2011-December/018184.html On Thursday 15 March 2012 11:20:43 Mihai Dobrescu wrote: Hello, IMHO, when a user makes a request, he will not perform a market study on his demand. He knows his needs and he doesn't ask, nor speaks, for other users hand. I feel an important amount of stress from the developers part, regarding the code involved. From the user part this is unknown. As professional developer, the easy to use a feature is, the harder might be to implement in the code. When I became software developer, I've sworn to satisfy my customers, of course when possible and within the feasible limits. So, I would not reject a requested feature unless I have good technical reasons to prevent it, based on the argument of complexity of code. Of course, maintenance is a good reason to reject when not enough resources are present, in order to support that feature (is this the case?). So, as KDE user, I can't give any statistics, polls, whatever in favor or against this button. I just _feel_ it is better than breadcrumbs for _me_. It is _natural_ to _me_. Form _my_ point of view, breadcrumbs are also useful, as a shortcut, when I need to jump over some elements in the path. So, the back button and breadcrumbs, although seem redundant, they are not, _to me_. I would use the 'back' button in 90% of cases. It is the very same case with Dolphin (the 'Up' button vs the path breadcrumbs), again, _for me_. BTW, not all users that miss the button will complain. Some devs say that these messages are lose of time for them. I can say using the breadcrumbs in the KickOff menu make me losing time too, for the sole reason it is unnatural _to me_ to use it there. Also, user feedback is not a lose of time. Although not many users express their gratitude for the developers work, because, _it seems_, the human nature is to complain about things not working or things not done. Sometimes it should happen. I _need_ to tell you, all the KDE team, that I love your work, some may say _imperfect_, but _great_ I say, knowing the effort you put in keeping it as close as possible to our needs. KDE is, _in my opinion_, well designed, flexible to be extended, clean and visually appealing. And OPEN. Making Plasma and Plasmoids is a good move. It's in the spirit of Linux and its customizability. I hope you keep up this good work for long. Thank you, Mike. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel 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: Breadcrumbs in Kickoff
On Fri, Mar 16, 2012 at 11:47 AM, Martin Gräßlin mgraess...@kde.org wrote: Hi Mihai, there has already been a lengthy discussion about breadcrumbs in Kickoff back in December [1]. I don't think anyone is interested in having yet another discussion about that topic. Thanks. Martin Gräßlin [1] http://mail.kde.org/pipermail/plasma-devel/2011-December/018184.html On Thursday 15 March 2012 11:20:43 Mihai Dobrescu wrote: Hello, IMHO, when a user makes a request, he will not perform a market study on his demand. He knows his needs and he doesn't ask, nor speaks, for other users hand. I feel an important amount of stress from the developers part, regarding the code involved. From the user part this is unknown. As professional developer, the easy to use a feature is, the harder might be to implement in the code. When I became software developer, I've sworn to satisfy my customers, of course when possible and within the feasible limits. So, I would not reject a requested feature unless I have good technical reasons to prevent it, based on the argument of complexity of code. Of course, maintenance is a good reason to reject when not enough resources are present, in order to support that feature (is this the case?). So, as KDE user, I can't give any statistics, polls, whatever in favor or against this button. I just _feel_ it is better than breadcrumbs for _me_. It is _natural_ to _me_. Form _my_ point of view, breadcrumbs are also useful, as a shortcut, when I need to jump over some elements in the path. So, the back button and breadcrumbs, although seem redundant, they are not, _to me_. I would use the 'back' button in 90% of cases. It is the very same case with Dolphin (the 'Up' button vs the path breadcrumbs), again, _for me_. BTW, not all users that miss the button will complain. Some devs say that these messages are lose of time for them. I can say using the breadcrumbs in the KickOff menu make me losing time too, for the sole reason it is unnatural _to me_ to use it there. Also, user feedback is not a lose of time. Although not many users express their gratitude for the developers work, because, _it seems_, the human nature is to complain about things not working or things not done. Sometimes it should happen. I _need_ to tell you, all the KDE team, that I love your work, some may say _imperfect_, but _great_ I say, knowing the effort you put in keeping it as close as possible to our needs. KDE is, _in my opinion_, well designed, flexible to be extended, clean and visually appealing. And OPEN. Making Plasma and Plasmoids is a good move. It's in the spirit of Linux and its customizability. I hope you keep up this good work for long. Thank you, Mike. ___ 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 Martin, Things have changed quite a bit between the last discussion and now. Back then the KDE version had both the breadcrumbs and the back button. Right now we have a new KDE version that only has the breadcrumbs. So now is the time when users start noticing something is different and that they perhaps might miss something or not. Back in December i fully agreed with you that the back button is redundant and the breadcrumbs can be used just as well. However, right now since KDE 4.8 was released I'm slowly realizing i miss something in the menu. I miss an option to just go back. No, i'm not trying to convince you that we need the full vertical bar back to go back, that really seemed totally out of place anyway. But right now i do think that having a back button would be better. The breadcrumbbar does allow you to go back, but it's kinda making me thing when i press it where do i need to go back to, main menu or.. and i don't want to think about that in a menu! I just want to go back. Right now, to me, it even seems like the breadcrumbbar is out of place in a menu. It's nice but just not working intuitively in a menu. Perhaps we do need to have a new fresh discussion about it since the impact is just becoming clear to the kde users now and in the coming months when the next (K)Ubuntu and Fedora get released. Perhaps a topic on the kde forum should be created. You might think the back button is of no use, but others might think differently. The discussion in december has shown that, now it's boiling up again and it will boil up more once Kubuntu and Fedora have their next release. The old situation wasn't perfect, but the current situation is not perfect as well. We need something in between. Kind regards, Mark ___ Plasma-devel mailing list Plasma-devel@kde.org
Re: Review Request: [RFC]: Rename Configure Window Behavior to Configure Window Management
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104284/#review11460 --- personally, i'm unsure why this menu entry is even there. imho people should simply go into system settings. this just makes one more place we have to manage which panels and in which order they are shown. is there really so much benefit to having it in the right click menu? now, i say that as someone who uses that menu item fairly often. so for *me* it has value there as a shortcut, but i'm rarely using it as a *user* but as a *developer* and watching others use KWin it's not an often used entry either. personally, despite my own use of this menu item, i think it's something best left to system settings. - Aaron J. Seigo On March 15, 2012, 11:19 a.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104284/ --- (Updated March 15, 2012, 11:19 a.m.) Review request for kwin and Plasma. Description --- Adding Plasma to get general feedback on this idea. The context menu entry to Configure Window Behavior opens the configuration of the window manager and not about the window. In the past the shown configuration dialog only contained entries affecting the window behavior but that is no longer true for the complete KDE 4.x series since Desktop Effects had been added to the menu. This change in naming reflects the situation and should help to remove confusion. This addresses bug 249486. http://bugs.kde.org/show_bug.cgi?id=249486 Diffs - kwin/useractions.cpp dfb6fd4 Diff: http://git.reviewboard.kde.org/r/104284/diff/ Testing --- Thanks, Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Add tool tips to Mouse Actions tool buttons
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104295/#review11461 --- Ship it! Ship It! - Aaron J. Seigo On March 16, 2012, 12:42 a.m., Christoph Feck wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104295/ --- (Updated March 16, 2012, 12:42 a.m.) Review request for Plasma. Description --- The very nice Mouse Actions page in the Desktop Settings dialog shows Configure/About/Remove icons on QToolButtons, but there is no text on hover to tell the user what the buttons do. I suggest to add these simple tool tips. Diffs - libs/plasmagenericshell/mousepluginwidget.cpp be52fde Diff: http://git.reviewboard.kde.org/r/104295/diff/ Testing --- Thanks, Christoph Feck ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Remember current desktop when changing activity
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/104261/#review11462
---
generally looks good to me, save for one small issue.
service/ActivityManager.cpp
http://git.reviewboard.kde.org/r/104261/#comment9136
should also check for = 0. also, this statement needs {}s, we use them
even for single line conditionals :)
- Aaron J. Seigo
On March 16, 2012, 7:40 a.m., makis marimpis wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/104261/
---
(Updated March 16, 2012, 7:40 a.m.)
Review request for KDE Runtime and Plasma.
Description
---
Patches kactivitymanagerd to store (and restore back) the working current
directory when switching activities.
The activity-changing-behavior is as follows:
1. Say you have two (or more activities) A and B.
2. You are working on activity A on Desktop 4.
3. You switch to activity B (and by default to Desktop 4).
4. Change to Desktop 1.
5. Go back to activity A and (by default) to Desktop 1, while it should move
you to Desktop 4 (this is where my patch kicks in).
I hope it makes sense :-)
This addresses bugs 241864 and 265015.
http://bugs.kde.org/show_bug.cgi?id=241864
http://bugs.kde.org/show_bug.cgi?id=265015
Diffs
-
service/ActivityManager.cpp 7af2049
service/ActivityManager_p.h d054eb7
Diff: http://git.reviewboard.kde.org/r/104261/diff/
Testing
---
Thanks,
makis marimpis
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: GSOC 2012 project: Make plasmate ready for release
On Thursday, March 15, 2012 18:19:17 Giorgos Tsiapaliwkas wrote: I was thinking to add the scp feature into plasmapkg and then plasmate to take it from there. What do you think? that's a nice idea; that way any usage of plasmapkg could do this. neat. -- 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: Review Request: Remember current desktop when changing activity
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104261/ --- (Updated March 16, 2012, 11:55 a.m.) Review request for KDE Runtime and Plasma. Changes --- Update if condition. Description --- Patches kactivitymanagerd to store (and restore back) the working current directory when switching activities. The activity-changing-behavior is as follows: 1. Say you have two (or more activities) A and B. 2. You are working on activity A on Desktop 4. 3. You switch to activity B (and by default to Desktop 4). 4. Change to Desktop 1. 5. Go back to activity A and (by default) to Desktop 1, while it should move you to Desktop 4 (this is where my patch kicks in). I hope it makes sense :-) This addresses bugs 241864 and 265015. http://bugs.kde.org/show_bug.cgi?id=241864 http://bugs.kde.org/show_bug.cgi?id=265015 Diffs (updated) - service/ActivityManager.cpp 7af2049 service/ActivityManager_p.h d054eb7 Diff: http://git.reviewboard.kde.org/r/104261/diff/ Testing --- Thanks, makis marimpis ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Workflow Idea for 4.10
On Friday, March 16, 2012 00:08:04 Kevin Ottens wrote: I've been thinking about the git workflow to be used in KDE Frameworks in the future. Based on observations and discussions with current and future frameworks maintainer, I think that it would be a mistake to force a single workflow for all the frameworks. is this to make life better for the maintainer or the developers? one thing that git as used by kde has done so far for me is severely limit my occasional hacker pattern where i dive into a given app or library and do a bit of work to scratch an itch. this is because we now have a gajillion little repositories and as a result i rarely build them these days. this is in large part due to me having kdesrc-build around, but not really using it much. why? partly because it's a change in my workflow (that takes time) and in part because i now have two workflows: one for the KDE projects i work on a lot (where i do no use kdesrc-build, because it is not appropriate there) and those that i just track. with the let everyone pick a workflow approach we'll be making this absurdely worse for Frameworks. i won't even know what workflow to be using when i work on a library, so wave goodbye to my involvement. given that Frameworks really benefits from the occassional developers such as myself fixing things here and there, implementing missing functionality here and there, this should be taken seriously. i know when i said in the past that my involvement with other projects would disipate due to the choices being made around git nobody really cared :) well, it's happened, i'm sure nobody still cares .. and that makes me sad. because i'm one of many. and by being too focused on tools and maintainers rather than developers we are screwing ourselves over. please disabuse yourself of the notion of maintainer chooses and work on a single workflow that all of Frameworks will adhere to for the sanity of all future developers. seriously, this is the should we have a coding style? discussion all over again, isn't it? [1] And before any we should always branch zealot cringe (not blaming you, been there as well), please take a few minutes and read[2]: http://martinfowler.com/bliki/FeatureToggle.html i honestly can't imagine a worse idea for a library like libplasma. -- 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: Re: Breadcrumbs in Kickoff
notethis is my last mail to this thread/note On Friday 16 March 2012 12:29:45 Mark wrote: Things have changed quite a bit between the last discussion and now. Back then the KDE version had both the breadcrumbs and the back button. Right now we have a new KDE version that only has the breadcrumbs. So now is the time when users start noticing something is different and that they perhaps might miss something or not. I'm not sure what you mean with things have changed... First of all the behavior had been changed for version 4.7 which got released in July 2011. Furthermore for us developers back in December the current version was already 4.8. If you read the discussion you probably noticed that there is work going on to rewrite Kickoff for 4.9. Given that I do not understand why we should discuss a user interface whose code will be dropped. 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: Breadcrumbs in Kickoff
On Friday, March 16, 2012 12:29:45 Mark wrote: but others might think differently. here is the most useful bit of all three emails so far in the resurrected thread. there is going to be no right answer because no matter what the choice is someone will differ. if we have both ways? it's cluttered and hard to use. have one way? the other way is better. yes, it will be different people objecting, but it's stile someone. and i'm going to assume you don't believe you are more valuable and important than others here. ;) so here are our options: * create a better view which does not replicate the problems of cascading menus or any of the other things the current view does improve on * live with it in either case, trying to peruade people with words is not useful in this particular situation because it is not words that are needed. cheers .. -- 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: Help us finding the new name for Laptop window decoration
On Thursday, March 15, 2012 14:59:17 Martin Gräßlin wrote: http://www.doodle.com/e9se6zuz8ufepxke for those who voted for simple: in what way is it simple? -- 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: Help us finding the new name for Laptop window decoration
On Fri, Mar 16, 2012 at 5:06 AM, Aaron J. Seigo ase...@kde.org wrote: On Thursday, March 15, 2012 14:59:17 Martin Gräßlin wrote: http://www.doodle.com/e9se6zuz8ufepxke for those who voted for simple: in what way is it simple? No gradients, no shades, plain colors, flat. Simple 3. -- Aaron J. Seigo ___ 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: [RFC]: Rename Configure Window Behavior to Configure Window Management
On March 16, 2012, 11:45 a.m., Aaron J. Seigo wrote: personally, i'm unsure why this menu entry is even there. imho people should simply go into system settings. this just makes one more place we have to manage which panels and in which order they are shown. is there really so much benefit to having it in the right click menu? now, i say that as someone who uses that menu item fairly often. so for *me* it has value there as a shortcut, but i'm rarely using it as a *user* but as a *developer* and watching others use KWin it's not an often used entry either. personally, despite my own use of this menu item, i think it's something best left to system settings. A fair enough question. For me as a developer it is a must-have feature, though it does not need to be exposed that strongly (e.g. move to advanced submenu) or even adding a build option for it. What I am unsure about is how much do we screw over the documentation teams. A google search on Configure window behavior KDE gives 5000 results with references in books and so on. Search for the German translation gives another 700 results. It is a feature for advanced users and already quite hidden. But I think for providing user support it's quite a useful feature. - Martin --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104284/#review11460 --- On March 15, 2012, 11:19 a.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104284/ --- (Updated March 15, 2012, 11:19 a.m.) Review request for kwin and Plasma. Description --- Adding Plasma to get general feedback on this idea. The context menu entry to Configure Window Behavior opens the configuration of the window manager and not about the window. In the past the shown configuration dialog only contained entries affecting the window behavior but that is no longer true for the complete KDE 4.x series since Desktop Effects had been added to the menu. This change in naming reflects the situation and should help to remove confusion. This addresses bug 249486. http://bugs.kde.org/show_bug.cgi?id=249486 Diffs - kwin/useractions.cpp dfb6fd4 Diff: http://git.reviewboard.kde.org/r/104284/diff/ Testing --- Thanks, Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: Help us finding the new name for Laptop window decoration
On Friday 16 March 2012 05:13:56 Tomaz Canabrava wrote: On Fri, Mar 16, 2012 at 5:06 AM, Aaron J. Seigo ase...@kde.org wrote: On Thursday, March 15, 2012 14:59:17 Martin Gräßlin wrote: http://www.doodle.com/e9se6zuz8ufepxke for those who voted for simple: in what way is it simple? No gradients, no shades, plain colors, flat. Simple 3. FTR: Laptop uses gradients. I checked before I decided whether Plastik or Laptop should be kept for thin clients. 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: Re: Help us finding the new name for Laptop window decoration
On Fri, Mar 16, 2012 at 5:16 AM, Martin Gräßlin mgraess...@kde.org wrote: On Friday 16 March 2012 05:13:56 Tomaz Canabrava wrote: On Fri, Mar 16, 2012 at 5:06 AM, Aaron J. Seigo ase...@kde.org wrote: On Thursday, March 15, 2012 14:59:17 Martin Gräßlin wrote: http://www.doodle.com/e9se6zuz8ufepxke for those who voted for simple: in what way is it simple? No gradients, no shades, plain colors, flat. Simple 3. FTR: Laptop uses gradients. I checked before I decided whether Plastik or Laptop should be kept for thin clients. Sigh. I use it and never realized that. _ 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: Help us finding the new name for Laptop window decoration
On Friday, March 16, 2012 13:16:10 Martin Gräßlin wrote: FTR: Laptop uses gradients. there are gradients all over the laptop style, not to mention those grippy stipples. :) if one is looking for a gradient-free decoration i'd recommend web (only real issue i fnd with web: the rounded corners need to turn into square ones for maximized windows...). i don't know how thin client appropriate was selected for in this case, but i trust Martin enough not to worry about it and assume laptop's gradients, etc. are not a problem there. btw, is it just me or does it have drawing errors when there are spaces between buttons? -- 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: Review Request: Remember current desktop when changing activity
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104261/#review11467 --- service/ActivityManager.cpp http://git.reviewboard.kde.org/r/104261/#comment9139 Why do you want to keep these in memory? - Ivan Čukić On March 16, 2012, 11:55 a.m., makis marimpis wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104261/ --- (Updated March 16, 2012, 11:55 a.m.) Review request for KDE Runtime and Plasma. Description --- Patches kactivitymanagerd to store (and restore back) the working current directory when switching activities. The activity-changing-behavior is as follows: 1. Say you have two (or more activities) A and B. 2. You are working on activity A on Desktop 4. 3. You switch to activity B (and by default to Desktop 4). 4. Change to Desktop 1. 5. Go back to activity A and (by default) to Desktop 1, while it should move you to Desktop 4 (this is where my patch kicks in). I hope it makes sense :-) This addresses bugs 241864 and 265015. http://bugs.kde.org/show_bug.cgi?id=241864 http://bugs.kde.org/show_bug.cgi?id=265015 Diffs - service/ActivityManager.cpp 7af2049 service/ActivityManager_p.h d054eb7 Diff: http://git.reviewboard.kde.org/r/104261/diff/ Testing --- Thanks, makis marimpis ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: Help us finding the new name for Laptop window decoration
On Friday 16 March 2012 13:48:02 Aaron J. Seigo wrote: On Friday, March 16, 2012 13:16:10 Martin Gräßlin wrote: FTR: Laptop uses gradients. there are gradients all over the laptop style, not to mention those grippy stipples. :) if one is looking for a gradient-free decoration i'd recommend web (only real issue i fnd with web: the rounded corners need to turn into square ones for maximized windows...). i don't know how thin client appropriate was selected for in this case, but i trust Martin enough not to worry about it and assume laptop's gradients, etc. are not a problem there. btw, is it just me or does it have drawing errors when there are spaces between buttons? no, it's not just you. I just enabled it and it shows the same bug as we know from Plastik already. Ah bitrot is such a wonderful thing. Given that I think we have to rethink the plan. Keeping Laptop instead of Plastik is by that also no option :-( 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: Re: Breadcrumbs in Kickoff
On Fri, Mar 16, 2012 at 12:59 PM, Martin Gräßlin mgraess...@kde.org wrote: notethis is my last mail to this thread/note On Friday 16 March 2012 12:29:45 Mark wrote: Things have changed quite a bit between the last discussion and now. Back then the KDE version had both the breadcrumbs and the back button. Right now we have a new KDE version that only has the breadcrumbs. So now is the time when users start noticing something is different and that they perhaps might miss something or not. I'm not sure what you mean with things have changed... First of all the behavior had been changed for version 4.7 which got released in July 2011. Furthermore for us developers back in December the current version was already 4.8. If you read the discussion you probably noticed that there is work going on to rewrite Kickoff for 4.9. Given that I do not understand why we should discuss a user interface whose code will be dropped. Cheers Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel Jup, i'm mixing up versions again :) It's difficult for me to keep track of which thing changed where when i'm experimenting with the code, using git for some other parts and the distribution version for the remaining part. I know that there is going to be a QML version of kickoff that you're making and that rocks! As Aaron said, there is no right answer here and i honestly don't know what's the best way to go. The current situation isn't ideal, the future situation isn't ideal and it never was ideal, so i guess we should just live with it for the time being. Regards, Mark ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Remember current desktop when changing activity
On March 16, 2012, 12:49 p.m., Ivan Čukić wrote: Hm, i did that in order to restore the desktop ids from a previous run of kamd (let's say, in case of log out). - makis --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104261/#review11467 --- On March 16, 2012, 11:55 a.m., makis marimpis wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104261/ --- (Updated March 16, 2012, 11:55 a.m.) Review request for KDE Runtime and Plasma. Description --- Patches kactivitymanagerd to store (and restore back) the working current directory when switching activities. The activity-changing-behavior is as follows: 1. Say you have two (or more activities) A and B. 2. You are working on activity A on Desktop 4. 3. You switch to activity B (and by default to Desktop 4). 4. Change to Desktop 1. 5. Go back to activity A and (by default) to Desktop 1, while it should move you to Desktop 4 (this is where my patch kicks in). I hope it makes sense :-) This addresses bugs 241864 and 265015. http://bugs.kde.org/show_bug.cgi?id=241864 http://bugs.kde.org/show_bug.cgi?id=265015 Diffs - service/ActivityManager.cpp 7af2049 service/ActivityManager_p.h d054eb7 Diff: http://git.reviewboard.kde.org/r/104261/diff/ Testing --- Thanks, makis marimpis ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Help us finding the new name for Laptop window decoration
I guess simple suffers from the same problem of Lightweight, sending the
wrong message about oxygen: oxygen is complex, dificult? It isn't said
where the simplicity is, which is only about its graphics. Simple Graphics,
maybe?
IMHO, Thin says it better.
--
J (|´:¬{)»
-
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
-
Em 16 de março de 2012 09:06, Aaron J. Seigo ase...@kde.org escreveu:
On Thursday, March 15, 2012 14:59:17 Martin Gräßlin wrote:
http://www.doodle.com/e9se6zuz8ufepxke
for those who voted for simple: in what way is it simple?
--
Aaron J. Seigo
___
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: Re: Re: Help us finding the new name for Laptop window decoration
On Friday 16 March 2012 13:54:24 Martin Gräßlin wrote: On Friday 16 March 2012 13:48:02 Aaron J. Seigo wrote: On Friday, March 16, 2012 13:16:10 Martin Gräßlin wrote: FTR: Laptop uses gradients. there are gradients all over the laptop style, not to mention those grippy stipples. :) if one is looking for a gradient-free decoration i'd recommend web (only real issue i fnd with web: the rounded corners need to turn into square ones for maximized windows...). i don't know how thin client appropriate was selected for in this case, but i trust Martin enough not to worry about it and assume laptop's gradients, etc. are not a problem there. btw, is it just me or does it have drawing errors when there are spaces between buttons? no, it's not just you. I just enabled it and it shows the same bug as we know from Plastik already. Ah bitrot is such a wonderful thing. Given that I think we have to rethink the plan. Keeping Laptop instead of Plastik is by that also no option :-( I requested a mockup for a new deco from Nuno and will try to find someone to implement it. Will update the Review Request accordingly to also drop Laptop. 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: Workflow Idea for 4.10
On Friday 16 March 2012 12:58:56 Aaron J. Seigo wrote: On Friday, March 16, 2012 00:08:04 Kevin Ottens wrote: I've been thinking about the git workflow to be used in KDE Frameworks in the future. Based on observations and discussions with current and future frameworks maintainer, I think that it would be a mistake to force a single workflow for all the frameworks. is this to make life better for the maintainer or the developers? Both really... If I was still maintaining libsolid for instance (so putting virtual maintainer hat), the very nature of it would make me think that not going for feature branches followed by merges in an integration branch would be dangerous (and libplasma, akonadi, kio are in a similar corner I think) and harder for me to test and review. As a developer? Yes, maybe a bit more work than putting stuff into master, but comparatively to the complexity of the component it's understandable. Now, if I want to contribute a feature in karchive (or kdbusaddons, kplotting), as a developer it'd look silly to me to have to publish a branch, get it merged in an integration branch, push the result, wait for approval and then get that merged in master. Hmm, also probably makes it more work for the maintainer who'd need to test both the feature branch and the integration branch to be able to give a enlightened go/no-go. With the low complexity of something like karchive, everyone would be way better off with a private branch on the developer side and publishing on reviewboard or discussing on a pastebin over IRC. And we have such different products in frameworks. I don't feel like forcing inadequate workflows on them for the sake of it. one thing that git as used by kde has done so far for me is severely limit my occasional hacker pattern where i dive into a given app or library and do a bit of work to scratch an itch. this is because we now have a gajillion little repositories and as a result i rarely build them these days. this is in large part due to me having kdesrc-build around, but not really using it much. why? partly because it's a change in my workflow (that takes time) and in part because i now have two workflows: one for the KDE projects i work on a lot (where i do no use kdesrc-build, because it is not appropriate there) and those that i just track. Of course transition takes time. Now, I wonder what blocks you with kdesrc- build though. I personally manage to use it for everything just fine, it's just that when I jump on a module to work on it I trigger make as usual. Didn't find it disruptive, but I might be missing something. with the let everyone pick a workflow approach we'll be making this absurdely worse for Frameworks. i won't even know what workflow to be using when i work on a library, so wave goodbye to my involvement. Sure, but there's really no good answer here. It's either Meh, absurd workflow for this component I'm too lazy to comply to it, wave goodbye to my involvement or Meh, I've to look up the workflow used here I'm too lazy to do it, wave goodbye to my involvement. (Of course replace lazy, by overworked, overcommitted, overwhelmed as you see fit) Now if someone can point me to a workflow which will work on all the spectrum of components without creating absurd bureaucracy in more than 30% of the cases I'm all ears. Currently I don't have one. given that Frameworks really benefits from the occassional developers such as myself fixing things here and there, implementing missing functionality here and there, this should be taken seriously. And it is, but see above. i know when i said in the past that my involvement with other projects would disipate due to the choices being made around git nobody really cared :) well, it's happened, i'm sure nobody still cares .. and that makes me sad. because i'm one of many. and by being too focused on tools and maintainers rather than developers we are screwing ourselves over. I'm definitely not focused on tools, hoped my previous email made that clear. please disabuse yourself of the notion of maintainer chooses I'll just add a few more thoughts regarding that because of your first question in this email, which I think was a bait to make me claim that it's to allow the maintainer to make his life easier against the developer comfort (in case anyone still wonder: no it's not the motive). As I tried to make clear above, I think what's critical is to have for a given component the right workflow for it. The nature of the components varying greatly, their needs regarding the workflow vary as well. So a workflow will have to balance quality of the outcome vs level of bureaucracy. Now the component itself not being able to tell us what workflow fits best, we have to rely on someone ultimately making the choice. And here the assumption is that the maintainer is among the people with the best overview of the component hence relying on him to pick a solution out of the shortlist. Now of
Re: Re: Breadcrumbs in Kickoff
Hello, well if there is going to be a QML version ... then the solution is simple since you just have to change the QML file if you don't like the default solution. Regards, Djuro Drljaca On Fri, Mar 16, 2012 at 1:54 PM, Mark mark...@gmail.com wrote: On Fri, Mar 16, 2012 at 12:59 PM, Martin Gräßlin mgraess...@kde.orgwrote: notethis is my last mail to this thread/note On Friday 16 March 2012 12:29:45 Mark wrote: Things have changed quite a bit between the last discussion and now. Back then the KDE version had both the breadcrumbs and the back button. Right now we have a new KDE version that only has the breadcrumbs. So now is the time when users start noticing something is different and that they perhaps might miss something or not. I'm not sure what you mean with things have changed... First of all the behavior had been changed for version 4.7 which got released in July 2011. Furthermore for us developers back in December the current version was already 4.8. If you read the discussion you probably noticed that there is work going on to rewrite Kickoff for 4.9. Given that I do not understand why we should discuss a user interface whose code will be dropped. Cheers Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel Jup, i'm mixing up versions again :) It's difficult for me to keep track of which thing changed where when i'm experimenting with the code, using git for some other parts and the distribution version for the remaining part. I know that there is going to be a QML version of kickoff that you're making and that rocks! As Aaron said, there is no right answer here and i honestly don't know what's the best way to go. The current situation isn't ideal, the future situation isn't ideal and it never was ideal, so i guess we should just live with it for the time being. Regards, Mark ___ 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: [RFC]: Rename Configure Window Behavior to Configure Window Management
On March 16, 2012, 11:45 a.m., Aaron J. Seigo wrote: personally, i'm unsure why this menu entry is even there. imho people should simply go into system settings. this just makes one more place we have to manage which panels and in which order they are shown. is there really so much benefit to having it in the right click menu? now, i say that as someone who uses that menu item fairly often. so for *me* it has value there as a shortcut, but i'm rarely using it as a *user* but as a *developer* and watching others use KWin it's not an often used entry either. personally, despite my own use of this menu item, i think it's something best left to system settings. Martin Gräßlin wrote: A fair enough question. For me as a developer it is a must-have feature, though it does not need to be exposed that strongly (e.g. move to advanced submenu) or even adding a build option for it. What I am unsure about is how much do we screw over the documentation teams. A google search on Configure window behavior KDE gives 5000 results with references in books and so on. Search for the German translation gives another 700 results. It is a feature for advanced users and already quite hidden. But I think for providing user support it's quite a useful feature. i don't agree that providing support is any easier or harder than starting with start system settings (which is more consistent of an approach, but not as immediate as right clicking on a title bar), but i do agree that the documentation references are a killer. for that reason i withdraw my proposal. - Aaron J. --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104284/#review11460 --- On March 15, 2012, 11:19 a.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104284/ --- (Updated March 15, 2012, 11:19 a.m.) Review request for kwin and Plasma. Description --- Adding Plasma to get general feedback on this idea. The context menu entry to Configure Window Behavior opens the configuration of the window manager and not about the window. In the past the shown configuration dialog only contained entries affecting the window behavior but that is no longer true for the complete KDE 4.x series since Desktop Effects had been added to the menu. This change in naming reflects the situation and should help to remove confusion. This addresses bug 249486. http://bugs.kde.org/show_bug.cgi?id=249486 Diffs - kwin/useractions.cpp dfb6fd4 Diff: http://git.reviewboard.kde.org/r/104284/diff/ Testing --- Thanks, Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Misc Fixes in Plasma Components Gallery
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104296/#review11470 --- Ship it! Ship It! - Aaron J. Seigo On March 16, 2012, 1 a.m., David Edmundson wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104296/ --- (Updated March 16, 2012, 1 a.m.) Review request for Plasma. Description --- Add margin on edge of main page Set default gallery page to the first entry in the menu (Buttons) Don't overlap main page with scrollbars Add clipping on main page for nicer animation between pages so it doesn't overlap the sidebar Diffs - plasma/declarativeimports/test/gallery/Gallery.qml 8a74f96 Diff: http://git.reviewboard.kde.org/r/104296/diff/ Testing --- Thanks, David Edmundson ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Save scrollbar position on plasma exit
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104258/ --- (Updated March 16, 2012, 1:47 p.m.) Review request for Plasma, Aaron J. Seigo, Marco Martin, and Fredrik Höglund. Changes --- Call discardScrollbarRestore() directly from AbstractItemView::scrollBarActionTriggered(). Description --- This patch implements scrolbar position saving on plasma exit. The change is fairly trivial, however, due to the fact that the view is not populated and layouted immediately simply scrolling to the desired position on creating the view does not work. Instead a signal is emitted on finishing the item layout, when the view has a valid size and the scrollbar has a valid range. The signal is connected to a slot which scrolls the view to the desired position and then disconnects the signal. For the user, a public function in AbstractItemView is introduced, which performs the connection. The only problem is that ListView turned out not to have any layout method. It just paints the items one by one, calculating their position on the fly, so I put the signal at the end of updateScrollbar to ensure the scrollbar range is valid. Maybe it should go into the if (max0) branch? This addresses bug 261139. http://bugs.kde.org/show_bug.cgi?id=261139 Diffs (updated) - plasma/applets/folderview/abstractitemview.h aa68b90 plasma/applets/folderview/abstractitemview.cpp 3debb70 plasma/applets/folderview/folderview.h 4e441eb plasma/applets/folderview/folderview.cpp a94ce87 plasma/applets/folderview/iconview.h 12e93b3 plasma/applets/folderview/iconview.cpp 5c4e086 plasma/applets/folderview/listview.cpp 94efe44 Diff: http://git.reviewboard.kde.org/r/104258/diff/ Testing --- Tested both the icon view and the list view, works fine. Thanks, Ignat Semenov ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: Help us finding the new name for Laptop window decoration
Am 16.03.2012, 13:54 Uhr, schrieb Martin Gräßlin mgraess...@kde.org: btw, is it just me or does it have drawing errors when there are spaces between buttons? no, it's not just you. I just enabled it and it shows the same bug as we know from Plastik already. Ah bitrot is such a wonderful thing. Seems it simply assumes a prefilled background, I'll have a look and fix that in no minutes in case Nun has no supergreat idea for another deco ;-) The gradients should be no problem, from a rough look they're precached in factory pixmaps on init and thus there's little transfer (kwin isn't started /that/ often during a session. Of course that implies the native graphicssystem but if you use the raster graphicssystem on a remote session, you got other stuff to worry about. Semi OT and OL: Should we reactivate the phase style as complement (have a short look on it's pixmap transfer overhead) and suppress the Qt built-in styles in the style kcm? Cheers, Thomas ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Help us finding the new name for Laptop window decoration
On Friday 16 March 2012 16:42:35 Thomas Lübking wrote: The gradients should be no problem, from a rough look they're precached in factory pixmaps on init and thus there's little transfer The whole point of a net-friendly window decoration is to not transfer bitmaps, but simple fillRect/drawRect calls. As such, if it uses gradients at all, it should not cache them. Christoph Feck (kdepepo) KDE Quality Team ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: Help us finding the new name for Laptop window decoration
Am 16.03.2012, 16:42 Uhr, schrieb Thomas Lübking thomas.luebk...@gmail.com: Seems it simply assumes a prefilled background, I'll have a look and fix that in no minutes in case Nuno has no supergreat idea for another deco ;-) Mehhh ... it inherits KCommonDecoration - in case we still intend to drop that thing, we'll better write a new deco from scratch - so let Nuno flow his mind. Cheers, Thomas ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Help us finding the new name for Laptop window decoration
Am 16.03.2012, 16:51 Uhr, schrieb Christoph Feck christ...@maxiom.de: The whole point of a net-friendly window decoration is to not transfer bitmaps, but simple fillRect/drawRect calls. As such, if it uses gradients at all, it should not cache them. If QPixmap is not entirely stupid, the pixmap is stored on the server, yesno? Thus you get no overhead. QGradient however (still?, i think so) internally swaps to the raster engine (because some drivers still *STILL* cannot XRenderCreate*Gradient) ie. paints into an image and XPutImage's that to the server :-( Cheers, Thomas ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Help us finding the new name for Laptop window decoration
Am 16.03.2012, 16:51 Uhr, schrieb Christoph Feck christ...@maxiom.de: qpaintengine_x11.cpp has (even) linear gradients deactivated :-( http://qt.gitorious.org/qt/qt/blobs/4.8/src/gui/painting/qpaintengine_x11.cpp#line441 I know that this used to be an fglrx issue, maybe we should check for an update and in doubt *finally* enable the feature in Qt? Cheers, Thomas ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Save scrollbar position on plasma exit
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104258/ --- (Updated March 16, 2012, 4:31 p.m.) Review request for Plasma, Aaron J. Seigo, Marco Martin, and Fredrik Höglund. Changes --- Avoid race condition between layoutFinished() and restoreScrollBarPosition(). Connect restoreScrollBarPosition() and scrollToSavedPosition() in the AbstractItemView ctor. Introduce AbstractItemView::setSavedScrollbarPosition(int) and call that before setModel in teh view setup methods in FolderView. Description --- This patch implements scrolbar position saving on plasma exit. The change is fairly trivial, however, due to the fact that the view is not populated and layouted immediately simply scrolling to the desired position on creating the view does not work. Instead a signal is emitted on finishing the item layout, when the view has a valid size and the scrollbar has a valid range. The signal is connected to a slot which scrolls the view to the desired position and then disconnects the signal. For the user, a public function in AbstractItemView is introduced, which performs the connection. The only problem is that ListView turned out not to have any layout method. It just paints the items one by one, calculating their position on the fly, so I put the signal at the end of updateScrollbar to ensure the scrollbar range is valid. Maybe it should go into the if (max0) branch? This addresses bug 261139. http://bugs.kde.org/show_bug.cgi?id=261139 Diffs (updated) - plasma/applets/folderview/abstractitemview.h aa68b90 plasma/applets/folderview/abstractitemview.cpp 3debb70 plasma/applets/folderview/folderview.h 4e441eb plasma/applets/folderview/folderview.cpp a94ce87 plasma/applets/folderview/iconview.h 12e93b3 plasma/applets/folderview/iconview.cpp 5c4e086 plasma/applets/folderview/listview.cpp 94efe44 Diff: http://git.reviewboard.kde.org/r/104258/diff/ Testing --- Tested both the icon view and the list view, works fine. Thanks, Ignat Semenov ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
request for review
i recently merged some new runners into master kdeplasma-addons
without a review and i apologize for that (the motivation actually was
because i was having some difficulties making some packages and had a
few repos that needed it, but that's moot now).
either way, i've got the tar if you've got the feathers ;-)
i can file a formal review request if that makes things easier. i will
do so later for the non-merged duckduckgo runner, so as to not repeat
the same mistake.
but the only things of interest here are the youtube and bing runners.
the bing one is the same exact thing, except for bing obviously.
https://projects.kde.org/projects/kde/kdeplasma-addons/repository/revisions/master/entry/runners/youtube/youtube.cpp
https://projects.kde.org/projects/kde/kdeplasma-addons/repository/revisions/master/entry/runners/youtube/tubejob.cpp
the code's relatively straight forward, because json xml ;)
the reason why i had to use bing for image searching is because google
is evil and their api has some silly 1k queries/day/key limit, which
we could easily outcap. and ironically, bing doesn't have any limits
on their api. i'm probably going to work on a flickr runner as well,
because we need more integration with the internets.
i do have a question however, as to why matches get triggered (even
for the mediawiki engine which currently resides in there, afict),
even though it isn't in singlerunnermode, and the prefix isn't being
hit. e.g. user is typing in some query would trigger a match for
that runner, instead of it only being triggered by wiki some query.
any ideas on that?
seems like a waste of resources if it is in fact unnecessary.
there is an issue with the icon being installed though. i copied the
icons from some kipi plugin, because they also happened to have a
youtube icon set so that saved time.
however, it now means we have 2 sets of icons being installed. also,
i'm installing the icons simply by running: kde4_install_icons(
${ICON_INSTALL_DIR} )
is there a good fix for this?
--
Shaun Reich,
KDE Software Developer (kde.org)
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: request for review
On Friday, March 16, 2012 13:10:54 Shaun Reich wrote: i do have a question however, as to why matches get triggered (even for the mediawiki engine which currently resides in there, afict), even though it isn't in singlerunnermode, and the prefix isn't being hit. e.g. user is typing in some query would trigger a match for that runner, instead of it only being triggered by wiki some query. any ideas on that? because RunnerManager does not know anything about prefixes :) with the RunnerSyntax there is a step in a useful direction there, but then there still needs to be a way saying this runner only cares when the prefixes match (some do both prefix matching and free text search) in my testing (admitedly some time ago) there was very little benefit to doing this in RunnerManager however versus just letting the runners themselves figure it out. .. assuming i'm understanding what you're asking :) -- 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: request for review
.. assuming i'm understanding what you're asking :) yep, answers exactly that. -- Shaun Reich, KDE Software Developer (kde.org) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Misc Fixes in Plasma Components Gallery
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104296/#review11496 --- This review has been submitted with commit 608a60aeea4a5fdd8de346ec6b0ac0a66ae08d59 by David Edmundson to branch master. - Commit Hook On March 16, 2012, 1 a.m., David Edmundson wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104296/ --- (Updated March 16, 2012, 1 a.m.) Review request for Plasma. Description --- Add margin on edge of main page Set default gallery page to the first entry in the menu (Buttons) Don't overlap main page with scrollbars Add clipping on main page for nicer animation between pages so it doesn't overlap the sidebar Diffs - plasma/declarativeimports/test/gallery/Gallery.qml 8a74f96 Diff: http://git.reviewboard.kde.org/r/104296/diff/ Testing --- Thanks, David Edmundson ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
