Re: Re: ScreenSaver and KDE Plasma 4.8?
On Saturday 01 October 2011 04:46:29 Markus Slopianka wrote: Is anybody aware of empiric studies for what (if at all) people use screensavers these days? Personally I'd expect clock, news headlines, and photo slideshows to be the top answers. QML replacements should be available for the top uses once the xscreensaver code is dropped. (IMHO at least.) I don't have empirical studies but given the bug reports we get OpenGL screensavers seem to be quite common these days as well and I think that's the group which would be difficult. Those who really need the Matrix screensaver. On the other hand most screensavers are low quality and hardly updated. What could help is to get some data from the distros how many users have screensavers actually installed. Cheers Martin On Donnerstag 29 September 2011 22:14:59 Martin Gräßlin wrote: Hi all, the work on the new screen locker implementation is nearly done (I can unlock again :-) and that brings me to an issue where I wanted to have more opinions: screensaver. What's important to see: screen locker and screen saver are two different things mixed together for historic reasons. The screen locker implements the security aspect of preventing someone else to use the screen. The screen saver shows an animation so that the hardware is not damaged. For some reasons those two things come together and also the old implementation is together. The new implementation is about screen locking and not saving. My idea is to improve the screen locking experience which kind of looks like 1995. Let's reuse the background of the splash screen and show a nice QML-ified dialog for unlocking. Instead of showing the unlock dialog only when someone moves the mouse, it would always be present. If the screen has been locked for long time DPMS kicks in and disables the screen (yeah for energy saving). This means there is no more place for screen savers. It would just not be visible. This also means we don't have the Plasma Screensaver any more (this might be fixable by using a Plasma containment as the screen locker in the first place). But when compositing is turned off, you currently get the plain old implementation including screen savers. And I don't want to change that code. So there are some solutions: * drop screensaver support altogether, probably would create some troubles as evil KDE removed screensavers * add Plasma widget support to new screen locker implementation but drop screensaver support (same problems as first option) * add a fallback to legacy mode if a screen saver is configured. Means same security problems are present again which were the reason for moving the screen locker to KWin in the first place Personally I would prefer option 1 with a later implementation of option 2 (if time allows even for 4.8). Option 2 needs support from Plasma hackers who are all currently fixing up a tablet ;-) A possible solution for the user issue could be to clearly advertise that security reasons are responsible for removing screensaver support. Also an improved login process I have in my mind: with only one user configured do not stop at KDM but log in directly with screen locked. The unlock dialog would then be shown after the complete session has been loaded, so instant usage after typing in the password. So looking forward to your comments on the subject. Cheers Martin ___ 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: ScreenSaver and KDE Plasma 4.8?
- Ursprüngliche Mitteilung - Am Thu, 29 Sep 2011 22:14:59 +0200 schrieb Martin Gräßlin mgraess...@kde.org: But when compositing is turned off, you currently get the plain old implementation including screen savers. And I don't want to change that code. Seconding Marco: Why? it's such a hack around X that I fear it falls apart as soon as I touch it ;-) No really I prefer not to spend too much time on legacy code. So there are some solutions: * drop screensaver support altogether, probably would create some troubles as evil KDE removed screensavers +1 A possible solution for the user issue could be to clearly advertise that security reasons are responsible for removing screensaver support. gg:greenwashing Just stress that aspect and best back it with some facts about the last available CRTs and burn-in-with-lcd myths. Otherwise you'll have to explain a) why is compositing such shit? b) but it works with windows c) can't you implement screensavers as kwin effects then? (yeah, but i won't! why? i think it's retarded. you suck! KDE sucks!! FOSS sucks i'm gonna use window blabbbabb) Also an improved login process I have in my mind: with only one user configured kcmshell4 kdm, convenience, enable auto-login, lock session that's what I had in my mind :-) rather don't do this if only one user is configured as a) this is rather never the case (does kdm know that sauerbraten and mpd are no regular users? what about nobody, fetchmail b) breaks other session types (openbox, e17) - of course a kde user would never do, but kde should prevent it neither ;-) It would require support from distributions, properly even only possible during insallation. Cheers Martin Cheers, Thomas ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: ScreenSaver and KDE Plasma 4.8?
On Sunday 02 October 2011 09:26:34 Luca Beltrame wrote: In data domenica 02 ottobre 2011 02:47:49, Kevin Kofler ha scritto: without a custom Plasma init script enabling the folder view of ~/Desktop one way or the other (either as a widget as in 4.6 or in Fedora 16, or the KDE-3-style folder view as desktop mode), complaints will start popping in I would argue that that's exactly the role of distributions, i.e. adjusting settings and so on. But I wasn't referring to no folderview shown, but to the first time when the workspace abolished show the desktop by default. I rarely saw such a complaint in the forums. Nevertheless, asking for feedback and posting something in the forums would help judge the reactions. And that's also why we have forums there (aside from user support). good idea. What is the perfect sub-forum for such a question? Does the forum support something like a questionaire: What would you say if KDE Plasma would no longer support X Screensavers? * I would switch to another DE * I would complain * I would miss them but could live without them * Don't use screensavers, it doesn't affect me * Don't care Cheers Martin -- Luca Beltrame - KDE Forums team KDE Science supporter GPG key ID: 6E1A4E79 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: ScreenSaver and KDE Plasma 4.8?
On Sunday 02 October 2011 13:27:13 Luca Beltrame wrote: In data domenica 02 ottobre 2011 12:19:02, Martin Gräßlin ha scritto: Poll created: http://forum.kde.org/viewtopic.php?fft�102 I just blogged about this, so the poll gets more exposure. cool thanks - I plan to also blog about it tomorrow when I have the first screenshot with a QML-ified unlock dialog ;-) Cheers Martin -- Luca Beltrame - KDE Forums team KDE Science supporter GPG key ID: 6E1A4E79 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: ScreenSaver and KDE Plasma 4.8?
On Sunday 02 October 2011 14:15:01 Luca Beltrame wrote: In data domenica 02 ottobre 2011 10:43:43, Ivan Čukić ha scritto: It needs to specify that no X Screensavers doesn't mean no screensavers krop on IRC raised an interesting question: is this drop of support related to just support, or also library dependencies? This because some stuff such as KIdleTime might depend on these. This should not affect libraries at all. All D-Bus interfaces will be the same, just the visualization is changed. Cheers Martin -- Luca Beltrame - KDE Forums team KDE Science supporter GPG key ID: 6E1A4E79 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: The future of Power Management - together with Activities
On Saturday 01 October 2011 16:27:48 Dario Freddi wrote: Hello all, and sorry for cross-posting. Hopefully, this solution will please everyone and will make activities even more useful. Do you like it? More suggestions? Speak now or shut up forever! Hi all, I urge everyone to calm down about this subject. By now I think Dario and the other Solid hackers have explained quite good what they want to do and sorry to say so most comments on the thread are just triggered by being badly informed. I did not understand the idea from Dario's first mail either, but now I have got the idea and completely trust in the decision of the experts. I am reassured that the manual tweaking is still possible - and I personally only change screen brightness and turn off wifi to save power. Everything else is to do the opposite and there activities are a perfect solution. If I am in the activity watching video I do not want the screen to blank. Using activities for such advanced features is as good as using anything else. So please calmn down and lets focus on improving the user experience by not spending too much time on too long threads. Thanks all and keep hacking 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: The future of Power Management - together with Activities
On Sunday 02 October 2011 21:09:00 Andras Mantia wrote: On Sunday, October 02, 2011 14:45:58 Dario Freddi wrote: That was one example. Another example brought up is e.g switching of strigi or nepomuk indexing when switching to a power saving profile. These two are something that usually kick in when you are in idle mode, exactly when the battery power could be saved. Of course, with good default profiles this can be solved. Absolutely not. Where did you read that, and most of all, how can profiles help you here, since there is no way for configuring that? If they are using Solid's way for determining if they can consume resources (and they are), they turn off automagically when on battery. No way now, but why we shouldn't have such a configuration? This would exactly improve power saving by letting the cpu more in idle mode. If we look at the big picture of KDE and think about integration, this is exactly a case where it makes sense to control multiple pieces of the software stack from one single place without user intervention. The user asks to save power the the desktop will try to achieve this with all possible means. I know this is not really about what your original mail is about, but it is something that might belong into the power management profiles. I don't see a valid reason why you should make that configurable. When you are on battery solid has to tell Nepomuk co to be silent. I really don't see why that should be complex at all. What I said that I might manually need to switch to a different profile independent of what the battery power *currently* is and without switching my workflow/applications. Because I know in advance (before the software can find this out from the battery level dropping down) how much time I need the computer running. But apparently you don't know what it takes to save power. Do I have to really know? I just want to save power. And do that whenever I want, not when the computer decides. Thats the whole point. Do you really think that you are smarter than the Kernel? I also want to save power, but I trust the Kernel developers to understand more about it than I do and completely trust that they will do the best. Now this is clearly not about the governor but about more general powersaving. All the time I have heard that turning off Desktop Effects will save power. Anyone who knows the code and who knows what is happening when you do turn compositing off, will tell you that turning compositing off is more expensive than all the power saving which you could get later on. But 3D is evil, right? And that's now exactly the point: if you don't have any clue about what is happening your I want to save power and not let the computer decide might be much worse than what the computer would do. The software in question is always written by experts in their field and they care about power saving as much as you do. And they can do what is really the best and not just gueses. Cheers Martin I will quote myself from another mail: the main job for a policy daemon is to PREVENT power management when the user is working, and that's exactly the use case for activities: while you are doing something, you don't want to be interrupted by extreme powersaving, such as dimming the screen in 30 seconds. Sincerely, the preventing part is news to me and probably to most users. Anyway, there is no point of arguing more, what I wanted to say, I did, what you wanted to say, you did, you are the coder, draw the conclusion from the thread and implement the feature. Andras ___ 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: Re: Re: ScreenSaver and KDE Plasma 4.8?
On Monday 03 October 2011 21:31:19 Kevin Kofler wrote: Martin Gräßlin wrote: What would you say if KDE Plasma would no longer support X Screensavers? * I would switch to another DE * I would complain * I would miss them but could live without them * Don't use screensavers, it doesn't affect me * Don't care You forgot option 6: * Come up with some buggy hack to use xscreensaver directly (maybe even with a custom idle detector which runs it in test mode, you never know what creative hacks people come up with), advertise it loudly as THE solution to fix screen savers in KDE Plasma, then rush the forums together with all the followers using that fix to complain loudly about everything that breaks due to the hack, blaming Plasma for it. (because that's exactly what I expect to happen). Well if they do I promise to ship an update to kwin to ensure that xscreensaver is stacked underneath the desktop shell ;-) Kevin Kofler ___ 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: removing dependencies from kactivitymanagerd
On Tuesday 04 October 2011 16:33:03 Aaron J. Seigo wrote: hi all... i experimented a bit this morning with cutting the fat from kactivitymanagerd. in particular i focussed on the following. KUniqueApplication: this lives in kdeui ... just to provide a way to have only one instance of the app. ugh. in Frameworks there is libkdbus which has a KDBusService which provides the same capabilities. porting to that proved quite simple and straightforward and let ActivityManager become a QCoreApplication subclass. KWindowSystem: this one is more difficult. it is used only to track the comings and goings of windows. no other features are used. and it ends up causing a QWidget to be created, which KWindowSystem uses to filter x11 events. i don't have a great solution for this one .. but it would be very nice to have something that doesn't pull in such a heavy set of dependencies just to watch window states. i don't know if this would be general-purpose enough to end up in Frameworks (my gut says no) but writing a simple class that can have a window-system-specific implementation that alerts when the window focus changes and windows are closed would make a lot of sense for kactivitymanagerd. so, i have a patch for the former, but nothing for the latter. any takers? :) Well for Wayland we need to change KWindowSystem anyway and I don't want to low level protocols. So who wants to design a D-Bus interface for broadcasting such methods and add a nice wrapper around it? Adding support for it in KWin should be simple. What do you think? 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: removing dependencies from kactivitymanagerd
On Tuesday 04 October 2011 18:29:33 Ivan Cukic wrote: General question - do you want to create a fw5 branch or something like that? Aaron KUniqueApplication: this lives in kdeui ... just to provide a way to have only one instance of the app. ugh. in Frameworks there is libkdbus which has a KDBusService which provides the same capabilities. porting to that proved quite simple and straightforward and let ActivityManager become a QCoreApplication subclass. Do we even need KDBusService? Just a check of QDBusConnectionInterface::isServiceRegistered can be used for this. Martin Well for Wayland we need to change KWindowSystem anyway and I don't want to low level protocols. So who wants to Is that going to be kwin-only, or we have a hope it will be picked up by others? Given the low interest of other window managers to collaborate recently, I doubt that. But do we care, if not? And we still can just open our own watch service to use if KWin is not running. Cheers Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: Thoughts about statusbar
On Tuesday 11 October 2011 12:54:23 todd rme wrote: On Tue, Oct 11, 2011 at 12:16 PM, Alex Fiestas afies...@kde.org wrote: Taking a look at some apps, I've noticed that most of them have an almost unused statusbar (or totally not used in some cases) resulting in a big empty grey space. In the same way that bit a bit we're fixing the KStatusNotifeir behavior in our apps, should we fix the status bar by removing it and placing somewhere else the content (if they are really needed?) The easier thing though, and the very least we should do is hide it by default as some apps do. What do you think? is statusbar (as badly used right now) needed? What about the way rekonq does it? It just displays the information needed when it is needed in a box in the lower-right of the window. This could do with some better theming perhaps, but otherwise for these situations it seems to make sense. The rekonq one is quite good as it is context sensitive, but with my KWin dev hat on I could cry when I see how they did it. For rekonq it would be much better to just show the link as a tooltip as that would be the most context sensitive way. Why do I have to understand that the link is shown on the down left corner of the window? Yes Firefox does it the same way. For most applications I think just removing it is the right approach. E.g. if network is not working in kopete it is way better to have a proper in app warning than a small text in the statusbar saying no network. The real issue is probably that this is an per-application change. So we would have to define a project to go through all applications, extract the useful messages, put them into in-app warnings and remove the statusbar. After we have done that we could shange the KXmlGuiWindow (or however it's called - never done a KDE application) and deactivate the statusbar by default. Cheers Martin -Todd ___ 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: Plasma QtComponents IRC meeting: summary
On Thursday 13 October 2011 23:00:36 Marco Martin wrote: * API documentation: this will be badly needed: Giorgos volunteered to give an hand on it, problem is that doxygen can't understand QML: the first step is to have good comments anyways, a custom tool could be needed? could it be hooked to api.kde.org? let's do the documentation in doxygen style and let's try to get QML support into doxygen. 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: Left set of buttons in the title bar
On Wednesday 19 October 2011 16:21:52 Sebastian Kügler wrote: On Tuesday, October 18, 2011 20:14:34 Kevin Krammer wrote: On Tuesday, 2011-10-18, Alex Fiestas wrote: By default we have 2 buttons in the left side of the titlebar, and I'm wondering if we really need them. On all desktop: Our defaults set only one desktop so I guess that's what we want the average user to use. Do we need a button in all titlebars that does nothing in that context? When has this been changed? I am still on a 4.6.x workspace but here the button successfully makes the window appear on all desktops. It's a 4.7 change, and only affects the default settings. The button of course only has no effect when there is only one virtual desktop. I suppose it should autohide itself in that case. yes, I think that would be the proper solution. If anyone is interested: kcommondecoration.cpp in kde-workspace/kwin/libkdecoration is your friend :-) Cheers Martin -- 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 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: Left set of buttons in the title bar
On Wednesday 19 October 2011 22:26:08 todd rme wrote: On Tue, Oct 18, 2011 at 12:30 PM, Alex Fiestas afies...@kde.org wrote: By default we have 2 buttons in the left side of the titlebar, and I'm wondering if we really need them. On all desktop: Our defaults set only one desktop so I guess that's what we want the average user to use. Do we need a button in all titlebars that does nothing in that context? Currently right-click on the maximize button maximizes horizontally, middle-click maximizes vertically. Could we do something like that with the button, assign one of these functions to each of the three mouse buttons: not before KDE Frameworks 5 as it would break the ABI of the decoration library. 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: Need some general feedback
On Sunday 23 October 2011 11:14:33 Kevin Krammer wrote: Hi there, since it seems there are no Plasma developers available for team work [1] at the present time [2], I'd like to ask for some general advice. I would appreciate to know whether I failed to communicate the value of being able to control background services through workspace facilties, or I failed to communicate that in the context of email and related data. I don't think you failed to communicate your needs but just hit the same problems as everywhere. We just don't have the ressources to work on anything outside our normal scope :-( The only problem might be that you addressed a group and nobody felt responsible. Maybe just grab one developer and approach him/her directly. Cheers Martin Thanks, Kevin [1] http://mail.kde.org/pipermail/plasma-devel/2011-October/017251.html [2] I had hoped to get this into 4.8 but maybe for the 4.9 development cycle? -- 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: Re: Need some general feedback
On Sunday 23 October 2011 17:30:56 Kevin Krammer wrote: I am somewhat tempted to create a quick and dirty widget on my own and see if somebody is offended by its uglyness enough to fix it ;) Does not sound bad to me. If you provide a nice dataengine and an example QML based view, I'm sure we find someone to do a good UI. Maybe the UI task could end up in a few Google Code-In projects... 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: Re: Thoughts about statusbar
On Tuesday 25 October 2011 15:37:20 David Edmundson wrote: On Tue, Oct 25, 2011 at 3:35 PM, Alex Fiestas afies...@kde.org wrote: On Tuesday, October 25, 2011 11:57:33 AM Aaron J. Seigo wrote: yes; as well as sometimes just saying that information is not worth it. the kmail example is a great one. i do not care what column and line i am on and spell checking should be shown in the toolbar if at all. More conservative and globally-aplicable would be to add a toggle to show/hide statusbar per app/window in the same way almost app do with the menubar. By default this option will be set as hidden but if some user want to be able to see the column number, she/he will be able to set it as shown again. Is plasma-devel really the right mailing list for something that affects every app, and nothing in plasma? which other list do you think is appropriate for Workspace related discussions? And yes this is clearly Workspace and not application related. We as the workspace define how an application has to look like and how it has to behave. Cheers Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel 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: Thoughts about statusbar
On Tuesday 25 October 2011 20:41:23 David Edmundson wrote: KDE Usability is the mailing list I had in my mind when I wrote it. I didn't mean do distract from the focus of a thread I think is quite important. Interesting that two devs mentioned the usability mailing list. I hope this is an indication that it is useful again. My last interaction with this list was no reply to a very concrete question from the KWin team for usability guidance [1]. Since then I considered the list as just dead. Anyway, given I've decided I should pay more attention to plasma and get away from just hacking constantly on one project, to make up for it here is a breakdown of statusbars the most commonly used apps in KDE. This was made with a fresh account with no settings altered. snip I think the important thing to do is to make a list of the uses of the status bar; displaying the URL of links, showing download progress, showing errors, showing the filename etc. Then to analyse these on a use by use basis (not an app by app basis) where is the best place this piece of information (which could be nowhere, a KMessageBox, tooltips, menus, or even remaining in the status bar). If an app then ends up with nothing left in the status bar it's time to remove it. This matches with what I had in mind when I wrote that we need to extract the useful messages into some better fitting UI elements. For me the issue isn't so much wasted space as much as an inconsistency in where the same piece information is displayed between apps. +1 and that's not limited to the statusbar :-( (sorry for the essay) not at all, it was an interesting read Cheers Martin [1] http://lists.kde.org/?l=kde-usabilitym=130393074318976w=2 ___ 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: Re: Thoughts about statusbar
On Tuesday 25 October 2011 14:14:03 Aurélien Gâteau wrote: And yes this is clearly Workspace and not application related. We as the workspace define how an application has to look like and how it has to behave. The statusbar is inside the application window, so I disagree this is a workspace issue. My personal opinion is that the Workspace has to define how the windows have to behave and it is the task of the Workspace to enforce some consistancy on the applications if it has to be. (Compare global menu or Notify OSD at that comany in your mail address ;-) As we see that the application developers fail to improve the UI (exceptions are there as usual - e.g. Dolphin, Gwenview or rekonq) we could even go so far to say that it is the responsibility of the part of our workspace experience which works on having a consistant UI and a clear interaction concept. In fact with Plasma Active we are already doing a top-down approach on the app from the workspace. We just never did on the desktop, because we trust the application developers to do the best. So I'm all for more power to the workspace [1], but I don't want to play UI expert either ;-) Cheers Martin [1] http://blog.martin-graesslin.com/blog/2011/05/where-ends-the-workspace- and-where-begins-the-application/ Aurélien ___ 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: IconTasks taskmanager changes
Am 26.10.2011 13:30, schrieb Craig Drummond: For the last couple of months I've been working on an icon-only task bar called IconTasks. (I've just uploaded the latest, 0.8.1, to kde-look - http://kde-look.org/content/show.php/Icon+Tasks?content=144808) This contains a forked version of taskmanager, which I would like to fold back into the main taskmanager code. Seeing as soft feature freeze is on the 27th (tomorrow!), I thought I should ask if it is ok to add this to the feature plan. (Also, should I add IconTasks itself (say for plasma-addons) as well?) I think it's great that you want to bring back your changes :-) And given the positive feedback I have heard for your tasks implementation I would like to see this in 4.8, so yes please add it to the feature plan. The main changes to the taskmanager library aren't really that much; 1. I've changed the way launchers are stored - this is so that I can save the order, so that users may manually re-order them. This means code would need to be written to convert any existing config to this new scheme. You can do that with a KConfig Update script. There's some good documentation on techbase about it. 2. When 'pinning' an app to the taskbar where the taskmanager cannot determine the desktop file (as happens even for System Settings!), the existing taskmanager embeds a copy of the tasks icon, and other details, into the plasma config file. Icon Tasks instead will prompt the user to select the app from the list of installed applications. That sounds reasonable, though the best solution would be to fix the mapping, but that might be a frameworks task (what I have in mind is a _KDE_NET_WM_DESKTOP_FILE property which is set on the window automatically) 3. I've added more queries to attempt to automatically determine the desktop file for a window. If this fails, the user is prompted to manually set the launcher. 4. Option to have simple right-click menus for tasks 5. 'Start New Instance' right-click action. For both 4 and 5 it would be nice to redo the complete menu and structure it in a better way as well as to share it with KWin. We had a small discussion about it on the KWin list, but somehow nobody did something about it :-( 6. Allow applet to supply task actions to appear at top of right-click menu. This is where IconTasks will place DockManager/Unity supplied menus, and display the list of recent documents. nice ...and that's basically it for the taskmanager changes. There's a *lot* of debug code, #ifdef'ed out, that would need to be removed. The only sticking point, AFAIK, will be the reading of pre-existing launchers where these are not mapped to a .desktop file. As I said, IconTasks does not support this - and I don't think embedding the icon, etc, in the config file is a good idea anyway. So, should I add these changes to the feature plan? I wont actually do any merges without posting diffs for review first. Or is it just too late, in which case I can wait for 4.9 :-) We have two weeks for review and I am sure our users would appreciate it, so yes please add :-) Cheers Martin Craig. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: 4.8 communication
On Friday 04 November 2011 19:01:27 Aaron J. Seigo wrote: hi :) as you may or may not have noticed, i just blogged about some of the upcoming changes in 4.8. i will do a follow up pice in a few days covering more of the changes and improvements. if there is something you would like to see mentioned, please let me know and i'll be sure to include it. one correction as there was a change of plan during your vacation: the screen locker will become a daemon due to security constraints of X11 (when KWin crashes a different window could grab the keyboard and the restarted KWin would not be able to grab the keyboard and by that not lock the screen - yes X sucks). Apart from that everything is the same except that it puts me on time pressure to finish it before Friday. A few things which could be mentioned from KWin front: * Performance optimization in Effect Handling and Window Painting * Massive performance improvements in Blur effect by caching the generated blurred backgrounds (kudos to Philipp Knechtges) * Foundation for easier Effects through AnimationEffect class (kudos to Thomas Lübking) * New binary kwin_gles gets build if system has OpenGL ES - allows easy switching to GLES. 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: Introducing components, how to
On Wednesday 09 November 2011 20:05:00 Marco Martin wrote: On Wednesday 09 November 2011, Marco Martin wrote: When writing a widget, an application etc, just use import org.kde.plasma.components, the proper one is decided by the kdeclarativerc file, if it has [Components-platform] name=touch something Sune just noted to me.. maybe an environment variable would be better to chose this? opinions? ;) both would be nice. Global config file and an environment variable to overwrite. Should make testing touch stuff on desktop easier. In KWin we have some options with environment variables overwriting settings, so that works :-) Cheers Martin Cheers, Marco Martin ___ 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
Review Request: Screen Locker daemon
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103105/ --- Review request for kwin, Plasma, Aaron J. Seigo, and Oswald Buddenhagen. Description --- Yes I know it's late in the cycle :-) and yes not everything is implemented yet, but I am confident that I get these things finished today or at least till Beta tagging. This is the new screenlocker work as discussed on kcd some time ago. The screen locker is split into two parts: 1. A daemon (ksld) to just lock the screen and grab input 2. An unlock dialog (kscreenunlocker) which is executed as a separate process. In case the unlocker fails/crashes the screen is still locked by the lock daemon. In case kscreenunlocker crashes or does not succeed, it gets automatically restarted by the daemon. Things I still need to do: * D-Bus integration * Grace time * integration of existing screen savers into the QML * cleanup KRunner * several more things Diffs - CMakeLists.txt 9fa4c10 screenlocker/CMakeLists.txt PRE-CREATION screenlocker/kcfg/kscreensaversettings.kcfg PRE-CREATION screenlocker/kcfg/kscreensaversettings.kcfgc PRE-CREATION screenlocker/ksld.desktop PRE-CREATION screenlocker/ksldapp.h PRE-CREATION screenlocker/ksldapp.cpp PRE-CREATION screenlocker/lockwindow.h PRE-CREATION screenlocker/lockwindow.cpp PRE-CREATION screenlocker/main.cpp PRE-CREATION screenlocker/unlocker/CMakeLists.txt PRE-CREATION screenlocker/unlocker/main.cpp PRE-CREATION screenlocker/unlocker/qml/lockscreen.qml PRE-CREATION screenlocker/unlocker/unlockapp.h PRE-CREATION screenlocker/unlocker/unlockapp.cpp PRE-CREATION screenlocker/unlocker/unlocker.h PRE-CREATION screenlocker/unlocker/unlocker.cpp PRE-CREATION Diff: http://git.reviewboard.kde.org/r/103105/diff/diff Testing --- * Screen locks * Screen stays locked if unlocker crasher * unlocker gets restarted Thanks, Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Screen Locker daemon
On Nov. 10, 2011, 12:19 p.m., Aaron J. Seigo wrote: it looks like we're pretty much right back to the situation we had prior to the screenlocking being moved to kwin, except that now we have yet another daemon which also links to kdeui just so it can be a unique app. if we are going to go this route, i highly recommend that the daemon becomes a kded plugin. other than that - how does kwin handle a locked desktop with this new system? e.g. turning effects and other window painting off ... it looks like we're pretty much right back to the situation we had prior to the screenlocking being moved to kwin Unfortunately yes, but if we want to make it secure, so that the screen does not get unlocked if something unrelated to screen locking crashes (e.g. the lock window or the OpenGL driver used by KWin) it needs to be in it's own process. if we are going to go this route, i highly recommend that the daemon becomes a kded plugin. there was concern that kded is too unstable as everything links to it, so e.g. a crashing other kded plugin could unlock the screen other than that - how does kwin handle a locked desktop with this new system? e.g. turning effects and other window painting off ... It can use the property to recognize that there are screenlocker windows and disable painting of other windows and effects - Martin --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103105/#review8095 --- On Nov. 10, 2011, 12:16 p.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103105/ --- (Updated Nov. 10, 2011, 12:16 p.m.) Review request for kwin, Plasma and Oswald Buddenhagen. Description --- Yes I know it's late in the cycle :-) and yes not everything is implemented yet, but I am confident that I get these things finished today or at least till Beta tagging. This is the new screenlocker work as discussed on kcd some time ago. The screen locker is split into two parts: 1. A daemon (ksld) to just lock the screen and grab input 2. An unlock dialog (kscreenunlocker) which is executed as a separate process. In case the unlocker fails/crashes the screen is still locked by the lock daemon. In case kscreenunlocker crashes or does not succeed, it gets automatically restarted by the daemon. Things I still need to do: * D-Bus integration * Grace time * integration of existing screen savers into the QML * cleanup KRunner * several more things Diffs - CMakeLists.txt 9fa4c10 screenlocker/CMakeLists.txt PRE-CREATION screenlocker/kcfg/kscreensaversettings.kcfg PRE-CREATION screenlocker/kcfg/kscreensaversettings.kcfgc PRE-CREATION screenlocker/ksld.desktop PRE-CREATION screenlocker/ksldapp.h PRE-CREATION screenlocker/ksldapp.cpp PRE-CREATION screenlocker/lockwindow.h PRE-CREATION screenlocker/lockwindow.cpp PRE-CREATION screenlocker/main.cpp PRE-CREATION screenlocker/unlocker/CMakeLists.txt PRE-CREATION screenlocker/unlocker/main.cpp PRE-CREATION screenlocker/unlocker/qml/lockscreen.qml PRE-CREATION screenlocker/unlocker/unlockapp.h PRE-CREATION screenlocker/unlocker/unlockapp.cpp PRE-CREATION screenlocker/unlocker/unlocker.h PRE-CREATION screenlocker/unlocker/unlocker.cpp PRE-CREATION Diff: http://git.reviewboard.kde.org/r/103105/diff/diff Testing --- * Screen locks * Screen stays locked if unlocker crasher * unlocker gets restarted Thanks, Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: bug killing
On Monday 21 November 2011 11:01:47 Aaron J. Seigo wrote: On Sunday, November 20, 2011 21:37:16 Aaron J. Seigo wrote: so .. 1700+ bugs. fun, huh? :) awesome; we are now down by ~100 reports already, thanks to efforts of just the last 24 hours. i'll arrange for a workshop + bug squash days near the end of the month. please take a moment to fill in this doodle: http://www.doodle.com/3rx2m4vz92qcrhm5 if we get enough people for two dates I am willing to hold also a workshop. 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: refreshing the system tray icons
On Thursday 01 December 2011 21:11:30 Marco Martin wrote: (even tough i'm still not sure if is a good idea to give icon for the applications like say, amarok) no it's not, but reality is that it looks very inconsistant and it does not look like we would get the applications out of the systray in 4.8. So from me +1 to monochrome Cheers Martin -- Marco Martin ___ 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: Re: bug killing
On Saturday 03 December 2011 17:20:20 Aaron J. Seigo wrote: On Sunday, November 20, 2011 21:37:16 Aaron J. Seigo wrote: so .. 1700+ bugs. fun, huh? :) as an encouraging little update, thanks to everyone's combined efforts we are now down to ~1270 reports. that's ~500 fewer than when i sent the email 2 weeks ago. I want that, too. And it's only 410 bugs and kwin is down to 0. So please apply your magic to reduce the bugs :-) (We are 20 bugs more than half a year ago.) Btw kwin shows what is possible when constantly triaged. We are working on it with two people. So far Plasma you would need about ten people working on it. Seriously: awesome job all of you. Keep that going. I'm pretty sure we can get plasma down to around 300 to 500 real bugs and that makes it managable. 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
Review Request: [Patch 1/2] Fix Sliding Popups
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103366/ --- Review request for kwin and Plasma. Description --- When the offset was not explicitly specified, the actual distance of the window to the nearest screen edge should be used as offset. This was calculated incorrectly resulting in broken code in the kwin effect. With this change a new default is introduced as -1 which is interpreted by kwin as kwin has to calculate the correct offset. Now it would be possible to do this in the library and pass the correct offset, but the library would have to create a QDesktopWidget just to calculate the screen geometry. KWin on the other hand knows the screen size, so having the default is IMHO better. Adjustments to kwin come in next patch for kde-workspace This addresses bug 287602. http://bugs.kde.org/show_bug.cgi?id=287602 Diffs - plasma/windoweffects.cpp ce41176 Diff: http://git.reviewboard.kde.org/r/103366/diff/diff Testing --- Thanks, Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request: [Patch 2/2] Fix Sliding Popups
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103367/ --- Review request for kwin and Plasma. Description --- Rework of sliding popups effect based on change to use -1 as a default offset. The animation is now calculated correctly (wasn't the case before) and clipping is working again as the window quads are filtered out. As a side note: I think we can now even try to apply blur behind the window during the animation. I think that all tries before failed due to the fact that we just calculated everything in the wrong way. This addresses bug 288568. http://bugs.kde.org/show_bug.cgi?id=288568 Diffs - kwin/effects/slidingpopups/slidingpopups.cpp 1065bfc Diff: http://git.reviewboard.kde.org/r/103367/diff/diff Testing --- yes, works for a panel on all possible corners (including panel between screens). Nevertheless please all try this patch. Thanks, Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: [Patch 2/2] Fix Sliding Popups
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103367/ --- (Updated Dec. 9, 2011, 5:35 p.m.) Review request for kwin and Plasma. Changes --- fixed one additional artifact which happened at the end of the disappearing animation. Strange enough I could not trigger it with animation speed very slow, but with normal. Description --- Rework of sliding popups effect based on change to use -1 as a default offset. The animation is now calculated correctly (wasn't the case before) and clipping is working again as the window quads are filtered out. As a side note: I think we can now even try to apply blur behind the window during the animation. I think that all tries before failed due to the fact that we just calculated everything in the wrong way. This addresses bug 288568. http://bugs.kde.org/show_bug.cgi?id=288568 Diffs (updated) - kwin/effects/slidingpopups/slidingpopups.cpp 1065bfc Diff: http://git.reviewboard.kde.org/r/103367/diff/diff Testing --- yes, works for a panel on all possible corners (including panel between screens). Nevertheless please all try this patch. Thanks, Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: [Patch 2/2] Fix Sliding Popups
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103367/ --- (Updated Dec. 10, 2011, 11:39 a.m.) Review request for kwin and Plasma. Changes --- wrong bug number Description --- Rework of sliding popups effect based on change to use -1 as a default offset. The animation is now calculated correctly (wasn't the case before) and clipping is working again as the window quads are filtered out. As a side note: I think we can now even try to apply blur behind the window during the animation. I think that all tries before failed due to the fact that we just calculated everything in the wrong way. This addresses bug 287602. http://bugs.kde.org/show_bug.cgi?id=287602 Diffs - kwin/effects/slidingpopups/slidingpopups.cpp 1065bfc Diff: http://git.reviewboard.kde.org/r/103367/diff/diff Testing --- yes, works for a panel on all possible corners (including panel between screens). Nevertheless please all try this patch. Thanks, Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request: Blur behind animated sliding popups
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103375/ --- Review request for kwin and Plasma. Description --- Title says it all. This change allows to have the background of sliding popups blurred. Tested, no artifacts on panels, also not with hard cases such as Yakuake. Requires the other sliding popup related patches. As far as my system is concerned it has no impact on performance. Nevertheless I will try to make it work with the cached blur version. As it might impact performance, I'm not sure whether this is 4.8 material. I let Aaron decide :-) Diffs - kwin/effects/blur/blur.cpp c566e34 kwin/effects/slidingpopups/slidingpopups.cpp 1065bfc Diff: http://git.reviewboard.kde.org/r/103375/diff/diff Testing --- Screenshots --- Kickoff with blur during animation http://git.reviewboard.kde.org/r/103375/s/358/ Thanks, Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request: Fix Library name of dragdropplugin
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103384/ --- Review request for Plasma. Description --- library name is not matching what is specified in qmldir file. Diffs - plasma/declarativeimports/draganddrop/CMakeLists.txt 5450873 Diff: http://git.reviewboard.kde.org/r/103384/diff/diff Testing --- Yes Kickoff now finds the plugin. Thanks, Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: 4.8.0 Easy Jobs
Am 13.12.2011 09:51, schrieb Aaron J. Seigo: http://bugs.kde.org/287027 - update favorites when ksycoca changes due to the rather strong changes I already have in the models I would appreciate if nobody touches that code. It has been broken forever, let's fix it with a bunch of other things after my rework in 4.9. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Breadcrumbs in Kickoff
On Thursday 08 December 2011 16:01:33 Xavier Sythe wrote: Nearly two months ago, I contacted him, and asked him to reverse the controversial commit. He has yet to reply. Please understand that not each developer has the time to answer personal requests. You state yourself that it is controversial. Just imagine each user disliking the feature sending a mail to Kevin. That just doesn't scale. Asking to revert the feature is to be honest non-constructive criticism. Like all other decisions on the default user interface they are done with care. The breadcrumbs add high value to Kickoff. It makes navigation in a folder like structure like the application menu more convenient and much more consistant with other parts of KDE applications, e.g. Dolphin's breadcrumb navigation. Just because you (and others) dislike the new feature it does not justify to revert the commit. There are also users liking the feature, so how should we suit both groups? Now please don't state that we need an option for that. This is not possible as the code gets too complex and too difficult to maintain. When I asked the #KDE IRC channel about this, I was told to contact the members of this mailing list, to see if I could get the commit reversed. Reverting the commit is clearly not an option. But what would you say about improving the breadcrumbs in Kickoff? Getting them into a state that you want to use them and not the out-of-place back button? Have a look at my recent blog post [1] about the work on Kickoff for 4.9. It is easy to give this version a try, it installs alongside the existing Kickoff. I personally do not see any need for the back button any more. Kind Regards Martin Gräßlin New Kickoff Maintainer after branch merged into master [1] http://blog.martin-graesslin.com/blog/2011/12/experience-from-porting- kickoff-to-qml/ 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
Hi, given that I basically told you not to write developers personally, I do not understand why you sent the mail to me instead of the mailinglist. I forwared your mail to the mailinglist and please send further mails also to the list if you are really interested in discussing this. Please also don't tofu, it makes discussions difficult to read[1]. On Friday 16 December 2011 19:04:48 Xavier Sythe wrote: Actually, the breadcrumbs don't really need to be removed. I merely see the need to reinstate the back button. I personally do not see any need for the back button any more. It's mostly a user experience perspective. I quite agree it's all about user experience. I think we should not have redundant elements in our primary user interface. This is confusing. Also the back button does not exist in any other part of the Plasma desktop or any other KDE application. It's a simple fact that it requires less mouse movement, If you state facts you have to prove them. Where is your usability study showing that a movement to the left is better than a movement to the top? Would you support removing the back button from Dolphin, in favour of just breadcrumbs? I doubt that anyone would support that. I thought about it and I had to open Dolphin to verify that there is a back button at all. I doubt I have used the back button during the last few years. So yes I would support that. I've chatted briefly with the KDE Usability Team, and they actually seemed to agree with me. Sorry to say: but with whom have you talked? Not everybody who says he is in the KDE Usability Team is a usability expert but just a user who thinks he understands usability. That's quite a difference. And what do you mean with seemed? They either agree or don't agree. Well some users might stick to the breadcrumb navigation, the majority of users from previous versions of KDE are accustomed to the back button, and appreciate its use, both in Kickoff as well as in Dolphin. Including both types of navigation will ensure that nobody complains, and presumably, lead to a better overall user experience. Do you have any facts that this is actually the case? I don't have any statistics validating or disvalidating your statement. The only thing I can tell you is that there is a vocal minority requesting to add the feature back[2]. With less than ten users posting to the bug report, I am sorry to tell you that there seems no demand for this feature. (Btw. don't even try to rally now that users post to the bug report. If that is going to happen I will make sure that the bug gets made read only). Please understand that we have to develop software which suits most of our users. This means that we cannot make all users happy and we are not always able to add all the features users want. We have to care about more than just adding features. Kind Regards Martin Gräßlin [1] http://www.rfc1855.net/ [2] https://bugs.kde.org/show_bug.cgi?id'4489 Thanks, Xavier Sythe On Fri, Dec 16, 2011 at 2:12 PM, Martin Gräßlin mgraess...@kde.org wrote: On Thursday 08 December 2011 16:01:33 Xavier Sythe wrote: Nearly two months ago, I contacted him, and asked him to reverse the controversial commit. He has yet to reply. Please understand that not each developer has the time to answer personal requests. You state yourself that it is controversial. Just imagine each user disliking the feature sending a mail to Kevin. That just doesn't scale. Asking to revert the feature is to be honest non-constructive criticism. Like all other decisions on the default user interface they are done with care. The breadcrumbs add high value to Kickoff. It makes navigation in a folder like structure like the application menu more convenient and much more consistant with other parts of KDE applications, e.g. Dolphin's breadcrumb navigation. Just because you (and others) dislike the new feature it does not justify to revert the commit. There are also users liking the feature, so how should we suit both groups? Now please don't state that we need an option for that. This is not possible as the code gets too complex and too difficult to maintain. When I asked the #KDE IRC channel about this, I was told to contact the members of this mailing list, to see if I could get the commit reversed. Reverting the commit is clearly not an option. But what would you say about improving the breadcrumbs in Kickoff? Getting them into a state that you want to use them and not the out-of-place back button? Have a look at my recent blog post [1] about the work on Kickoff for 4.9. It is easy to give this version a try, it installs alongside the existing Kickoff. I personally do not see any need for the back button any more. Kind Regards Martin Gräßlin New Kickoff Maintainer after branch merged into master [1] http://blog.martin-graesslin.com/blog/2011/12/experience-from-porting- kickoff-to-qml
Re: Re: Re: Breadcrumbs in Kickoff
Hey Rick, On Sunday 18 December 2011 09:29:36 Rick Stockton wrote: On 01/-10/-28163 11:59 AM, Aaron J. Seigo wrote: Aaron, my words were unclear. If you and Martin are willing to put this into the 4.8.x Series, it CAN be done, but we _must_ use the name which already exists. 'Xbutton1' == the Back Button, the other two names will be synonyms for 'XButton1' in Qt5. 'XButton1' will still be present, and we can stay Source-compatible across both Qt Versions by using THAT name. the earliest point in time to ship it is 4.9 which will be based on my new QML based implementation. And there seems to be a problem... MouseArea does not know anything except the three standard buttons[1]. So seems like it's not possible with the back mouse button. Middle button might be an option but might be rather unexpected. I will try to improve the keyboard navigation, though. Cheers Martin [1] http://doc.qt.nokia.com/4.8-snapshot/qml-mousearea.html#acceptedButtons- prop 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
Small QML related questions...
Hi all, three small QML/Plasma related questions that came up while working on Kickoff and no notmart on IRC to ping ;-). All are related to changing layout based on location. 1. How to get the enum values LeftEdge, TopEdge and so on. I get plasmoid.location but that's just a number. No matter what I tried QML gave me an undefined value for the edge values. Documentation on techbase could be better there. I will add a note when I figured that out. 2. Is it possible to get a vertical TabBar with the PlasmaComponents? I would like to use that if Kickoff is placed on a left/right panel as with the current version. 3. Is it possible to somehow visually connect the selected TabButton with the tab content? That's one of the things the classic Kickoff is doing quite nicely and I think this could help in general to make it more clear that these are Tabs. 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: Small QML related questions...
On Sunday 18 December 2011 22:07:46 Aaron J. Seigo wrote: On Sunday, December 18, 2011 18:43:06 Martin =?ISO-8859-1?Q?Gr=E4=DFlin?= wrote: Hi all, three small QML/Plasma related questions that came up while working on Kickoff and no notmart on IRC to ping ;-). All are related to changing layout based on location. 1. How to get the enum values LeftEdge, TopEdge and so on. I get plasmoid.location but that's just a number. No matter what I tried QML gave me an undefined value for the edge values. should be just: LeftEdge. no, that did not work. 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: Small QML related questions...
Am 19.12.2011 11:02, schrieb Aaron J. Seigo: On Monday, December 19, 2011 06:32:17 Martin =?ISO-8859-1?Q?Gr=E4=DFlin?= wrote: On Sunday 18 December 2011 22:07:46 Aaron J. Seigo wrote: On Sunday, December 18, 2011 18:43:06 Martin =?ISO-8859-1?Q?Gr=E4=DFlin?= wrote: Hi all, three small QML/Plasma related questions that came up while working on Kickoff and no notmart on IRC to ping ;-). All are related to changing layout based on location. 1. How to get the enum values LeftEdge, TopEdge and so on. I get plasmoid.location but that's just a number. No matter what I tried QML gave me an undefined value for the edge values. should be just: LeftEdge. no, that did not work. hmm... that's in the JS bindings and i confirmed it existed before i replied; where in your QML are you trying to use it? I'll ping you this evening when I'm back home and give you my current patch on top of kickoff branch Cheers Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: Small QML related questions...
On Monday 19 December 2011 11:46:41 Martin =?ISO-8859-1?Q?Gr=E4=DFlin?= wrote: hmm... that's in the JS bindings and i confirmed it existed before i replied; where in your QML are you trying to use it? I'll ping you this evening when I'm back home and give you my current patch on top of kickoff branch I just tried together with Marco and it works. Seems like I had a typo yesterday... Sorry for the noise Cheers Martin P.S.: A kingdom, a kingdom for type checking while editing 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 Wednesday 21 December 2011 00:51:45 Alexey Chernov wrote: On 20 дек 2011 11:20:23 Aaron J. Seigo wrote: On Tuesday, December 20, 2011 00:33:20 4ernov wrote: unclear why you so against to approve such a work. i think it is perfectly fine if you wish to create a modified kickoff and ship it as a separate plasmoid. this is what we've done for a few different plasmoids, including the tasks plasmoid (and that's ended up turning out rather well for everyone i think :). No, I mean a contribution with config option or something which can return the Back button. I don't think it's perfect idea to fork kickoff because of one function. but that's the point. Now in a month someone else wants something completely different. Then it's still not the perfect idea to fork Kickoff because of one function. A month later the next config option creeps in and another one and another one. And a nice small applet becaume a Frankenstein. Either you decide that no non-valid config options go in or you have discussions about it each other day. i do not want plasma desktop to become a collection of everyone's pet features with a thousand configuration tweaks. Exactly. I agree. But as I remember Martin said that we're discussing only config option and reverting to Back button wasn't an option. I think, nobody also wants Plasma desktop to become a collection of wrong decisions, it's even worse. Yes, I said we can discuss the need of a config option. For that we require good arguments why such an option is required. That has not yet presented here. Neither we can do it, nor but it was there is a good argument. the back button was not serving everyone well (we got lots of feedback on it ...) I didn't say the Back button was ideal. I think a serious usability research should be performed to find the better solution instead of it. And I can't believe any usability expert could suggest breadcrumbs instead of back button as it's just against the basic things one could learn in usability. So you are a usability expert? I didn't know that. I am no usability expert, because of that I do not argue with usability. (Just look through my mails you will nowhere find that I say the breadcrumbs are better and the back button is worse from a usability point of view). If you have not studied usability, I would appreciate that you don't pull such arguments. It a serious field of research and we should not do like we know better. As to me, my solution is: keep both Back button and breadcrumbs. Here's my arguments: - no config and no tweaks required - users can use both ways - no redundancy or duplication as it's just two methods to reach the same result (there're thousands of examples with such implementations, e.g. same features in main menu, toolbar and context menus in one application) I'm sorry but all your examples are bad ones. Let's consider them: * main menu is normally dropped. Finding an option there is a complicated task. See for example Unity which basically removed the menu completely. * context menu you have to explicitly trigger, you have to know that the functionality is there. With Kickoff we are talking about two always visible and directly reachable UI elements. This is something completely different. We also have to consider how close these UI elements are. Given the new QML design they would border each other. That is one of my main concerns that it visually clutters the view, makes them inconsistent (only one of four views uses the back button) and confusing. I don't see why the average user would need this always there. To me this looks like you realized that you don't get your config option and now you try to adjust your argument ;-) - minimum of code required this is just not true. This would significantly increase the code size. See my other mail on that subject. As I wrote I expect an increase of code size for one QML file by at least 10 %. I don't mean that it's a bad code or something and I respect all the efforts of Martin and whole Plasma team to improve navigation, to find some better decisions. But I think such a things should be discussed especially given a significant number of critical comments. If something was wrong I don't see any problems to solve it. Which significant number of critical comments? How many users have commented here in the thread and reported bugs? 5? 10? 20? We are talking about a feature which will be used by millions of users. If we get to a thousand users complaining we can start to think about significant numbers. A small anectode: we had a recent event in the state where I live. In our state capital the German government and the Deutsche Bahn want to build a new station. It will take many years to build it and will cost several billions €. Over the last year there were many demonstrations in the captial with thousands of people protesting against the station. Since the last election the state is governed by a prime minister of the
Re: 4.8 branch
Am 21.12.2011 11:20, schrieb Aaron J. Seigo: hi :) some of you will have noticed that there is now a KDE/4.8 branch in the modules. i would like to request that all fixes happen in the KDE/4.8 branch and then: * if kde-workspace, cherry-pick into master * otherwise, merge origin/KDE/4.8 into master if the merge fails, then you can resort to cherry-picking ... as long as scripty is not active for master, I would suggest that we go for merging from origin/KDE/4.8 to master as well. Also I would suggest to never cherry-pick. If a merge fails it might be better to ping someone with more git experience to resolve it. Cherry-picking will just make it more difficult to merge in future. Cheers Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: 4.8 branch
Am 21.12.2011 12:12, schrieb Aaron J. Seigo: On Wednesday, December 21, 2011 11:45:16 Martin =?ISO-8859-1?Q?Gr=E4=DFlin?= wrote: Am 21.12.2011 11:20, schrieb Aaron J. Seigo: hi :) some of you will have noticed that there is now a KDE/4.8 branch in the modules. i would like to request that all fixes happen in the KDE/4.8 branch and then: * if kde-workspace, cherry-pick into master * otherwise, merge origin/KDE/4.8 into master if the merge fails, then you can resort to cherry-picking ... as long as scripty is not active for master, I would suggest that we go for merging from origin/KDE/4.8 to master as well. for kde-workspace? yes. I did that with 4.7 till scripty started to process in master again. Then it just became an unmergeable mess. So at least for the next few weeks it should work if everyone sticks to it. Cheers Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: Breadcrumbs in Kickoff
On Wednesday 21 December 2011 21:33:52 Martin Klapetek wrote: To play the devil's advocate here - as the main reason against bringing it back is mostly the increased code complexity, then if you add whole support for additional mouse buttons that actually trigger the back action, which is just a MouseArea set on the view which already has all the code to go up. Trivial, easy to maintain, doesn't influence any other code of Kickoff. isn't the back button then just like 10 lines of qml code? Ie. just hook the onClick: to the one-level-back action? Nope: it influences the layout. It is not trivial to add with my current design of Kickoff in QML. As a matter of fact we would also have to consider to put the button on the right when Kickoff is on the right edge. That requires strong adjustments on the layout as well as choosing a different arrow element. So no, this is clearly a non-trivial change with lots of potential impact for future development. Remember: if we add it we have to maintain it. It might hinder future changes, which would be bad. I wrote it in another mail in this thread: it increases the complexity of the code base. Nothing I like. 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: Kickoff-QML and classic launcher
On Wednesday 21 December 2011 18:25:51 Aaron J. Seigo wrote: On Tuesday, December 20, 2011 20:51:32 Martin Graesslin wrote: My personal favorite is option 3. 3 is a good solution imho ... except that it will break people's installations who have kde-workspace but not kdeplasma-addons installed. so we can break this into two applets, but i don't think we can move the classic menu out just yet. With a kconf update script it might be possible. If the user uses the classic menu and it's not available any more we transfer him to Kickoff. also, right now the switch to classic menu / switch to kickoff option in the context menu works by deleting the existing applet and creating a _new one_ of the new type. this pretty well sucks as it means settings get lost in what should be a setting-loss-less event. full ack. I thought about that before I wrote the mail and decided that iff I port the classic menu to QML it would not become an own applet but just a different QML frontend for the same applet. it's really a horrible hack and i'd suggest getting rid of it. people can add the classic menu from the widget explorer like all the rest. in fact, since we had a thread about the scripting stuff here already, we could easily add a Classic KDE panel script option that creates a panel just like in KDE 3. heck, it could even change the desktop use icons only. this would be rather trivial to make happen for 4.9 .. thoughts? What you want to destroy the use case for Trinity and Qt-Razor? ;-) Sure sounds like a good idea. 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: Kickoff-QML and classic launcher
On Thursday 22 December 2011 11:32:20 Nowardev-Team wrote: http://kde-apps.org/content/show.php/Plasma+Panels+Collection+?content=14758 9 http://www.youtube.com/watch?v=o_qR-7FQHxc very nice :-) 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
Review Request: Integrate Plasma Scripting Console with KWin scripting
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103518/ --- Review request for kwin and Plasma. Description --- * KWin scripting becomes partly controllable through D-Bus * Desktop Scripting Console can control KWin scripts. For that two new methods to PlasmaApp's D-Bus interface are added. If in KWin mode the script is passed to KWin through D-Bus * Plasma Desktop Runner gains new keyword wm console to start Desktop Scripting Console in KWin mode. Diffs - kwin/scripting/scripting.h b0d00f9 kwin/scripting/scripting.cpp 0a71849 plasma/desktop/runners/plasma-desktop/plasma-desktop-runner.h 227748d plasma/desktop/runners/plasma-desktop/plasma-desktop-runner.cpp 617bc69 plasma/desktop/shell/dbus/org.kde.plasma.App.xml e9b6482 plasma/desktop/shell/interactiveconsole.h f94b997 plasma/desktop/shell/interactiveconsole.cpp 6f2ff75 plasma/desktop/shell/plasmaapp.h 3c7289c plasma/desktop/shell/plasmaapp.cpp b630225 Diff: http://git.reviewboard.kde.org/r/103518/diff/diff Testing --- Screenshots --- Desktop Scripting console with KWin integration http://git.reviewboard.kde.org/r/103518/s/379/ Thanks, Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Integrate Plasma Scripting Console with KWin scripting
On Dec. 23, 2011, 5:40 p.m., Aaron J. Seigo wrote: looks quite straightforward. i'm not overly fond of having wm console and desktop console and not being able to switch between them in the UI. it would be very cool to have the ability to switch modes from the toolbar. what would be FANTASTIC is to be able to put blocks of plasma-desktop and kwin code in the same editor and have it run the JS in the right place, but i think that faces a number of limitations due to the nature of controlling an out of process app (kwin). either the kwin API would need to implemented in plasmagenericshell's scripting and in there forward calls on via DBus (or whatever) or limit it rather unnaturally to blocks of code that would get executed in their own context (e.g. no variables available from both a desktop block and a kwin block) so that seems like something for another day, as it would be quite a bit of work :) imho, for now this can go in as-is with the addition of a drop down in the toolbar to switch between modes easily it would be very cool to have the ability to switch modes from the toolbar. Yes, that's something I want to add. I thought about to Toggle Buttons in the toolbar Plasma, KWin which are mutual exclusive. I just didn't want to work on it any more today and wanted to push out the review request :-) Will implement that after Christmas break :-) The other idea sounds complicated. Not sure whether that would be possible at all without exposing complete KWin internals to D-Bus. - Martin --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103518/#review9210 --- On Dec. 23, 2011, 2:24 p.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103518/ --- (Updated Dec. 23, 2011, 2:24 p.m.) Review request for kwin and Plasma. Description --- * KWin scripting becomes partly controllable through D-Bus * Desktop Scripting Console can control KWin scripts. For that two new methods to PlasmaApp's D-Bus interface are added. If in KWin mode the script is passed to KWin through D-Bus * Plasma Desktop Runner gains new keyword wm console to start Desktop Scripting Console in KWin mode. Diffs - kwin/scripting/scripting.h b0d00f9 kwin/scripting/scripting.cpp 0a71849 plasma/desktop/runners/plasma-desktop/plasma-desktop-runner.h 227748d plasma/desktop/runners/plasma-desktop/plasma-desktop-runner.cpp 617bc69 plasma/desktop/shell/dbus/org.kde.plasma.App.xml e9b6482 plasma/desktop/shell/interactiveconsole.h f94b997 plasma/desktop/shell/interactiveconsole.cpp 6f2ff75 plasma/desktop/shell/plasmaapp.h 3c7289c plasma/desktop/shell/plasmaapp.cpp b630225 Diff: http://git.reviewboard.kde.org/r/103518/diff/diff Testing --- Screenshots --- Desktop Scripting console with KWin integration http://git.reviewboard.kde.org/r/103518/s/379/ Thanks, Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: Kickoff w/Breadcrumbs in QML
On Friday 23 December 2011 13:15:22 Xavier Sythe wrote: Just to confirm, does the QML Kickoff still have keyboard navigation? I think that it would be a good idea to not only add support for a mouse's back button, but also the standard backspace key on keyboards. This would enable full navigation of Kickoff solely with the keyboard, a feature which, until now, has been limited by the lack of a back button shortcut. It's something I still have to work on. Primitive navigation (up/down) in the list is working, everything else not yet. If placed in the panel it's not working at all. Adding these things is rather simple once I figured out where I have to add the keyboard handling, so that QML plays nice :-) As for the UI back button, Novell's usability team did determine that it was needed. Who are we, as non-UX professionals, to argue against this decision? Do you have a link to the study? I tried to find it, but could only find the presentations at Akademy and FOSDEM which did not contain the reasons for the design, but just the results compared to other launchers. And, as for the terminology used for the classic, KDE3-style panel, I believe that classic would be the best term, NOT KDE3. As well, I don't see much of a use case for the classic panel being included in Plasma by default. Available from KDE-Look, certainly, but KDE3's days were long ago. Even classic I find sub-optimal. It's like next generation just the other way around. Imagine we have a new launcher next year. Then we would have to rename Kickoff to classic, but how to call the classic one. Really classic, old classic? Nevertheless: still better than KDE 3 ;-) 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: Integrate Plasma Scripting Console with KWin scripting
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103518/ --- (Updated Dec. 26, 2011, 9:06 a.m.) Review request for kwin and Plasma. Changes --- Added toolbar buttons to switch between Plasma and KWin mode. Description --- * KWin scripting becomes partly controllable through D-Bus * Desktop Scripting Console can control KWin scripts. For that two new methods to PlasmaApp's D-Bus interface are added. If in KWin mode the script is passed to KWin through D-Bus * Plasma Desktop Runner gains new keyword wm console to start Desktop Scripting Console in KWin mode. Diffs (updated) - kwin/scripting/scripting.h b0d00f9 kwin/scripting/scripting.cpp 0a71849 plasma/desktop/runners/plasma-desktop/plasma-desktop-runner.h 227748d plasma/desktop/runners/plasma-desktop/plasma-desktop-runner.cpp 617bc69 plasma/desktop/shell/dbus/org.kde.plasma.App.xml e9b6482 plasma/desktop/shell/interactiveconsole.h f94b997 plasma/desktop/shell/interactiveconsole.cpp 6f2ff75 plasma/desktop/shell/plasmaapp.h 3c7289c plasma/desktop/shell/plasmaapp.cpp b630225 Diff: http://git.reviewboard.kde.org/r/103518/diff/diff Testing --- Screenshots --- Desktop Scripting console with KWin integration http://git.reviewboard.kde.org/r/103518/s/379/ Thanks, Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: Re: Breadcrumbs in Kickoff
On Tuesday 27 December 2011 20:16:48 Kevin Kofler wrote: Martin Gräßlin wrote: Which significant number of critical comments? How many users have commented here in the thread and reported bugs? 5? 10? 20? We are talking about a feature which will be used by millions of users. If we get to a thousand users complaining we can start to think about significant numbers. FYI, we've got a bunch of complaints on #fedora-kde about this. Not everyone affected goes post to plasma-devel. define a bunch. 20 people per day? 50 per day? One per month? Seriously we have millions of users and I doubt that Fedora KDE users on IRC is our primary target group for Kickoff. If a user knows the word IRC I would say he needs a different launcher: recommend them to use krunner, they will like it :-) 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: Re: Review Request: Change activity by rolling the mouse wheel over the showActivityManager widget.
On Tuesday 27 December 2011 21:49:24 Guillaume DE BURE wrote: I use the keyboard shortcut (meta + tab) quite often. However I remember once someone (maybe, marco ?) proposed an exposé like effect, with activities as rows, and desktop as columns. That could be extremely useful, especially for dragging windows between desktop / activities. Does that still sound like a good idea ? Would it be difficult to do ? There is one problem with that: when an activity is closed we do not know which windows are there. If an activity is suspended we most likely due not have a pixmap for this window as the driver discarded it for the long time unmapped window. So unless someone has a genious idea how to get thumbnails of non existing windows, it will be difficult to implement :-) (The genious idea might be as simple as storing screenshots from the window when it got closed, activity switched, whatever. 4.9 will hopefully see nice QML bindings in KWin, so that might be implementable. Help welcome) 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 Tuesday 27 December 2011 23:36:54 Matthew Dawson wrote: 1) The back button was a much larger button to hit. According to Fitt's Law[1], the smaller a target is to hit, the longer it takes. The breadcrumbs, being smaller, decreases the speed at which someone can hit the target. It is readily apparent to me, as I only recently got introduced to it. Fitt's Law is only a valid argument iff the back button is directly on the left screen edge. So it is fine for our default, for everything else the back button is in fact rather bad due to Fitt's Law. 2) The position of the breadcrumbs is on the upper right hand corner. People will first look for information to the upper left hand part of the screen. With the breadcrumbs positioned where they are, its first of all hard to find compared to the back button. I can't remember if people brought up with RTL languages see upper right hand first, but at least for LTR it is. Yes and that's why I moved it to the left in the new implementation. Thoughts? If these ideas sound useful, I'll try to cook up a patch to implment them. the current implementation will be thrown away soon. So don't waste your time on working with the C++ code. If you want to work on the QML based kickoff you need to checkout the branch kickoff-qml. In general the discussion seems to be at a mood point if people do not know the work which is going on. 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: flowout proposal
On Wednesday 28 December 2011 16:18:06 Mark wrote: Besides that this is pure eye candy, it does make the desktop just look more polished when the menu folds out like that and just seems to be nicely integrated in the panel. This idea should imho be extended to more elements: - System tray - Thumbnail preview - Menu bars Would it be possible to implement this idea in KDE? From what I see in the screenshots (I did not look at [3] due to the huge amount of advertisment on that page - maybe upload a video) there is nothing which is not possible right now with KWin. All the things are there. So Plasma is actually the wrong place for this :-) So what you need is: * a Qt widget theme to get the translucency (KWin 4.8 contains improvments to have windows always blurred) * a Plasma theme * a set of KWin effects (note: 4.9 will include JS bindings for effects and QML bindings for things like Present Windows) * a KWin window decoration which supports the translucency (note: since some releases the decoration can paint the background of the window. I hope to get QML bindings to window decorations for 4.9) * a set of Plasmoids Or let me ask it differently, what needs to happen in KDE to even be able to implement it in KDE? Please do let me know what you think of it. Whatever you do: do not even think about playing with the window system. Integrating windows into the desktop shell is a bad idea. Be aware of the limitations of the X window system. Be aware of the limitations of working with Qt, GTK and XUL. Your mockups show Firefox: you will never get it that way. Don't reinvent the wheel, use what is there. Remember that we are in the process to get rid of X, but some things will stay: we still have different rendering in Qt and GTK to make your live difficult and even with Wayland we still need to differentiate between windows and desktop shell. Cheers Martin Kind regards, Mark [1] http://mde.mageprojects.com/images/MDE%20-%20Marks-Desktop-Environment%20-%2 0menu_paths.png [2] http://mde.mageprojects.com/ [3] http://www.filefactory.com/file/c059a4b/n/AdaptivePanel.zip 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 Saturday 31 December 2011 09:30:25 Aaron J. Seigo wrote: On Wednesday, December 28, 2011 09:42:35 Martin =?ISO-8859-1?Q?Gr=E4=DFlin?= Yes and that's why I moved it to the left in the new implementation. note that this then puts it in a different location to all the other headers in the other tabs. so you switch from Favourites to Applications - header switches location. Applications to System - header swtiches location again. if the breadcrumbs are moved to the left and/or get a specialized visual treatment (neither of which are bad ideas imho) then the other headers should similarly be adjusted for consistency across the tabs. so far I synchronized the position with other Plasma elements and moved the headers into the center. Personally I would prefer to have a consistent UI throughout all Plasma elements (at least for the default shipped widgets). So the question is whether the breadcrumbs need to be moved from Left to Center. I will give that a try, but are not sure whether it is a good idea as it causes changes when traversing the menu. 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: OpenGL and Plasma::Wallpaper
On Thursday 29 December 2011 11:21:36 Justin L. Boss wrote: Is there a way to use opengl in a Plasma::Wallpaper. Maybe by passing a opengl surface to QPainter then having Plasma::Wallpaper display it or does the Plasma::Wallpaper except opengl calls? You could do the same as the GLApplet [1] does: paint to a PBO or FBO, convert it to QImage and render the image. But this looks like a memory intensive operation and probably not a good idea. My recommendation would be to wait till we have QML 2 where everything is done in OpenGL :-) Personally I am not a big fan of having animations which would require OpenGL in the background. Most of the time the background is not visible, it requires resources and puts load on the compositor which has to update the scene although nothing changes (full repaints are most expensive). May I ask why you want to use OpenGL? Cheers Martin [1] https://projects.kde.org/projects/kde/kdelibs/repository/revisions/master/entry/plasma/glapplet.cpp 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
XSLT to convert Doxygen to MediaWiki
Hi all, I faced the problem of how to get the scripting documentation generated and most important up to date without manually editing the Wiki pages. As I am lazy I wrote an XSL Template to convert Doxygen generated XML into MediaWiki syntax. The template processes: * read-only properties * read-write properties * public slots * Q_SCRIPTABLE public methods The generated MediaWiki code matches the style used by Plasma's JavaScript documentation. An example for docu generated by the template can be found in [1]. To convert xsltproc cannot be used as I use XSLT 2.0 functionality. Best use saxon [2]. To generate use the following command: java -cp saxon9he.jar net.sf.saxon.Transform -t -s:/path/to/doxygen- generated.xml -xsl:/path/to/mediawiki.xslt I hope this can be useful to keep the Plasma JavaScript docu up to date :-) Cheers Martin [1] http://techbase.kde.org/Development/Tutorials/KWin/Scripting/API_4.9 [2] http://saxon.sourceforge.net mediawiki.xslt Description: application/xslt 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: OpenGL and Plasma::Wallpaper
On Saturday 31 December 2011 12:10:37 Shaun Reich wrote: On Sat, Dec 31, 2011 at 5:17 AM, Martin Gräßlin mgraess...@kde.org wrote: On Thursday 29 December 2011 11:21:36 Justin L. Boss wrote: Personally I am not a big fan of having animations which would require OpenGL in the background. Most of the time the background is not visible, it requires resources and puts load on the compositor which has to update the scene although nothing changes (full repaints are most expensive). May I ask why you want to use OpenGL? Probably because QPainter is dog slow. using OpenGL doesn't make it faster if you need QPainter to render to the background ;-) Also, I don't think you should be against OGL wallpapers, considering some really sweet/impressive things could be done with them which could really make KDE stand out. e.g. a wallpaper playing a moving OGL scene, movies, virus wallpaper (which is currently a large CPU drain, and has no HW accel afik). Take Win 7 for instance, how they have Dreamscene™ or whatever. I divide the world into two categories: good for KWin, bad for KWin. An animated wallpaper is bad for KWin as it needs to update everything all the time. In that sense it does not matter whether the wallpaper uses OpenGL or something else. If it is animated than it is bad. This is of course orthogonal to what it provides: being awesome. KWin has also the being awesome things which are in fact bad for KWin. But what's the difference? Nobody tries to use the desktop while the cube is spinning. It just doesn't matter that KWin is using lots of resources. In case of a wallpaper covered by windows it does matter whether the background makes everything slow or not. So here I just think we should not give users the tool to make the desktop unbearable slow. Yes it looks awesome, yes new users might love it. Yes new users will switch back to whatever they used, because everything is extremely slow. So unless our wallpapers learn to not redraw the areas which are not visible anyway (which is probably impossible to know for the wallpaper), I am not a fan of animated wallpapers in general. Just for the record: using always animated wallpapers should perform better thanks to optimizations in 4.8. 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: Re: OpenGL and Plasma::Wallpaper
On Sunday 01 January 2012 13:37:45 Shaun Reich wrote: On Sun, Jan 1, 2012 at 12:54 PM, Martin Gräßlin mgraess...@kde.org wrote: On Saturday 31 December 2011 12:10:37 Shaun Reich wrote: On Sat, Dec 31, 2011 at 5:17 AM, Martin Gräßlin mgraess...@kde.org wrote: On Thursday 29 December 2011 11:21:36 Justin L. Boss wrote: Personally I am not a big fan of having animations which would require OpenGL in the background. Most of the time the background is not visible, it requires resources and puts load on the compositor which has to update the scene although nothing changes (full repaints are most expensive). May I ask why you want to use OpenGL? Probably because QPainter is dog slow. using OpenGL doesn't make it faster if you need QPainter to render to the background ;-) Aaw, I was hoping using OGL/qml and what not would remove the need to go through QPainter at all. If only... it will with QML2 and the OpenGL SceneGraph :-) 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: QML widget explorer
On Sunday 01 January 2012 20:51:34 Marco Martin wrote: On Saturday 31 December 2011, Marco Martin wrote: Hi all, After almost a year of stopped development, I think the qml rewrite of the widget explorer and activity manager are almost ready for merge :D Annuntio vobis gaudium magnum, meh my Latin is not even good enough any more to translate that without Wikipedia :-( the qml widget explorer and activity manager are merged, let the bitch fest begin :p a little bit of feedback * \o/ yeah opening the widget explorer and typing works \o/ * the bottom of the activity mager looks a little bit crowded. I would say margin is missing (see [1]). If I are first in widget explorer it looks correct. * clicking on Create Activity opens the window on the left screen corner. If you don't have that I blame Qt and update (I saw 4.8 is in Debian experimental) * If I am first in Activies with bad bottom and go to widgets the scrollbar is missing * There should be a margin between widget title and right corner - see [2] * Widget name might need a text elide - see [3] * Too much empty space in tooltips * Yeah scrolling would be nice :-) Also the missing flickable behavior surprised me, though it is clear that it cannot work when there is a drag area. great work :-) Cheers Martin [1] http://wstaw.org/m/2012/01/01/bottom-of-activity-manager.png [2] http://wstaw.org/m/2012/01/01/kmail2f26845.jpg [3] http://wstaw.org/m/2012/01/01/kmail2W26845.jpg 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: Fix Add to desktop from Kickoff when you have several virtual desktops and you enable Different widgets for each desktop
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103645/#review9628 --- I just consulted the documentation and checked the properties on my system: that looks like KWindowSystem is wrong. The first desktop is 0. And further studies show that the bug might be in KWin. Will investigate further... - Martin Gräßlin On Jan. 6, 2012, 9:11 p.m., Anne-Marie Mahfouf wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103645/ --- (Updated Jan. 6, 2012, 9:11 p.m.) Review request for Plasma and Aaron J. Seigo. Description --- From Kickoff using Add to desktop when you have several virtual desktops and you enable Different widgets for each desktop in the pager settings. KWindowSystem starts counting from 1 and Plasma from 0 Without this fix Add to desktop adds to the next desktop or does not add if you're on the last desktop. This addresses bug https://bugs.kde.org/show_bug.cgi?id=290368. http://bugs.kde.org/show_bug.cgi?id=https://bugs.kde.org/show_bug.cgi?id=290368 Diffs - plasma/desktop/applets/kickoff/ui/contextmenufactory.cpp cf12903 Diff: http://git.reviewboard.kde.org/r/103645/diff/diff Testing --- Local tests as thorough as I could do. Thanks, Anne-Marie Mahfouf ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Fix Add to desktop from Kickoff when you have several virtual desktops and you enable Different widgets for each desktop
On Jan. 6, 2012, 9:33 p.m., Martin Gräßlin wrote: I just consulted the documentation and checked the properties on my system: that looks like KWindowSystem is wrong. The first desktop is 0. And further studies show that the bug might be in KWin. Will investigate further... so just checked the relevant code in KWin and KWindowSystem: we start counting at 1 and just decrement/increment 1 when writing/reading the X property. Everything is fine with KWindowSystem reporting 1, the question is why Containment uses 0? - Martin --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103645/#review9628 --- On Jan. 6, 2012, 9:11 p.m., Anne-Marie Mahfouf wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103645/ --- (Updated Jan. 6, 2012, 9:11 p.m.) Review request for Plasma and Aaron J. Seigo. Description --- From Kickoff using Add to desktop when you have several virtual desktops and you enable Different widgets for each desktop in the pager settings. KWindowSystem starts counting from 1 and Plasma from 0 Without this fix Add to desktop adds to the next desktop or does not add if you're on the last desktop. This addresses bug https://bugs.kde.org/show_bug.cgi?id=290368. http://bugs.kde.org/show_bug.cgi?id=https://bugs.kde.org/show_bug.cgi?id=290368 Diffs - plasma/desktop/applets/kickoff/ui/contextmenufactory.cpp cf12903 Diff: http://git.reviewboard.kde.org/r/103645/diff/diff Testing --- Local tests as thorough as I could do. Thanks, Anne-Marie Mahfouf ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Fix Add to desktop from Kickoff when you have several virtual desktops and you enable Different widgets for each desktop
On Jan. 11, 2012, 1:29 p.m., Aaron J. Seigo wrote: tiny ws issue, but otherwise ok. and why containment starts from 0 - because that's where counting starts. that virtual desktops in KWindowSystem start at '1' is pretty silly, really. otherwise we end up with everything else being zeroth counted as per usual, except desktops which are counted from 1. i chose not to extend that oddity into plasma code. thanks for the info. Maybe we should put that on a TODO list for frameworks 5 to change it to start at 0 like it is with NETWM anyway. I guess that it started with 1 in KDE before NETWM had been introduced? - Martin --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103645/#review9744 --- On Jan. 6, 2012, 9:11 p.m., Anne-Marie Mahfouf wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103645/ --- (Updated Jan. 6, 2012, 9:11 p.m.) Review request for Plasma and Aaron J. Seigo. Description --- From Kickoff using Add to desktop when you have several virtual desktops and you enable Different widgets for each desktop in the pager settings. KWindowSystem starts counting from 1 and Plasma from 0 Without this fix Add to desktop adds to the next desktop or does not add if you're on the last desktop. This addresses bug https://bugs.kde.org/show_bug.cgi?id=290368. http://bugs.kde.org/show_bug.cgi?id=https://bugs.kde.org/show_bug.cgi?id=290368 Diffs - plasma/desktop/applets/kickoff/ui/contextmenufactory.cpp cf12903 Diff: http://git.reviewboard.kde.org/r/103645/diff/diff Testing --- Local tests as thorough as I could do. Thanks, Anne-Marie Mahfouf ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: plasma::wallpaper and pure opengl?
On Tuesday 17 January 2012 18:49:12 Shaun Reich wrote: i'm not knowledgeable in the OGL department, or the plasma::wallpaper area...but I thought it'd be kind of nice to tinker around with making absurdly useless but awesome wallpapers, and maybe learn a bit of OGL in the process. there was recently a thread about OGL wallpapers where I stated my opinion on it. problem is, isn't there an issue with using opengl on plasma::wallpapers? because you end up having to render it to an image, then use QPainter to display it, right? yes is there a good way around that? no :-) A possible solution might be to take advantage of KWin. Consider Plasma not rendering a wallpaper at all and KWin knowing about it. In that case we could have a special effect rendering the wallpaper. We already have functionality to render the background black if it becomes visible. This would just needed to be extended. But it would make mouse interaction and stuff like that impossible. 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: [RFC] Remove Xinerama related options
On Friday 20 January 2012 11:53:22 Alex Fiestas wrote: The only reason I can think of is to create video walls, meaning multiple monitors used as if they were 1. for that you do not even need these options. You can resize your window as big as you want. Quite independent from the options. 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: [RFC] Remove Xinerama related options
On Friday 20 January 2012 13:09:18 Xavier IZARD wrote:
Martin Gräßlin a écrit :
Hi workspace developers,
KWin provides the option to turn off multi screen aware window management.
This results in windows being maximized over both screens or fullscreen
windows being stretched over all screens. These options make the code much
more complex and add confusing configuration dialogs to our workspace (see
attached screenshot).
Example code:
int Workspace::numScreens() const
{
if (!options-xineramaEnabled)
return 1;
return Kephal::ScreenUtils::numScreens();
}
I personally fail to understand why the options are needed and why they
have been added in the first place. With git blame I was not able to go
back so far in the history to find when they were added. Note: the
xinerama code used also to be ifdefed, so I could imagine it being from a
time back when multi screens was a new feature.
From the userinterface the only useful option is Show unmanaged windows
on
which should be kept. All other options make in my opinion just no sense.
If nobody sees any good reason to keep these options I would prepare the
removal.
The reason is btw not to remove options, but to decrease the complexity of
the code as shown above and the fact that it is a break my system setting
which happened more than once that users complained about maximize not
working any more.
Cheers
Martin
Hi,
Could be more clear about the behaviour of kwin without these options ?
I suppose that the behaviour would be the same as when all these options
were checked ? (ie, maximize fullscreen work on each screen
independently, magnetic borders, ...)
yes, everything would be like the options are checked
What about persons who group monitors to do a huge monitor panel ?
(video wall).
What about people who use very large monitor needing dual video inputs ?
those can disable xinerama support through xorg.conf
My personal usage is (was) this one : I uncheck the option Enable
multiple monitor window fullscreen support (all other options are
checked). So that :
- When working on my computer, the maximized windows spawn only one
monitor at a time, I get magnetic borders, ...
- When watching movie (fullscreen mode), the display spawns all my
monitors thus doing a video wall.
so you would only need one of the options, the fullscreen one? And in fact you
only want that for vlc, right? You don't want the option for let's say
Firefox?
So e.g. a KWin script taking care of setting the fullscreen video player to
all screens would suit you better, right?
Sorry, but what I see here is a powerful feature of KDE that is going to
disappear ...
Regards,
Xavier
P.S. I am the author of the option Enable multiple monitor window
fullscreen support
Thanks for providing your feedback. This is appreciated and quite helpfull.
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: [RFC] Remove Xinerama related options
On Friday 20 January 2012 13:11:03 Alex Fiestas wrote: On Friday, January 20, 2012 11:32:13 AM Martin Gräßlin wrote: From the userinterface the only useful option is Show unmanaged windows on which should be kept. Well imho as a heavy multi* everything user I don't see why a user would want to force Unmanaged windows in one screen since usually your attention is where your pointer is. there might be use cases for the other option. Think of a TV attached to the screen. You would never want windows to open there. On the other hand the mouse cursor won't be there either. So hmm maybe you're right ;-) 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: prep'ing the QML screenlocker for a merge into master
On Friday 20 January 2012 15:02:39 Aaron J. Seigo wrote: hi all ... i've spent some time today looking at the screenlocker branch in kde- workspace. i was hoping it might be a straight-forward merge after adding one or two little features and possibly merging the screenlocker daemon with ksmserver. seems it needs a bit more work than that, so i figured i'd compile a short list here of TODOs. if others have input, please provide it now before i start working on things. those who would like to help out are more than welcome to! * screensaver kcm needs to be replaced with a screen locker kcm that lists available themes and manage the widgets on locker feature (more on that below) yes, that one is still missing * the lock screen qml is currently stored in share/apps/kscreenlocker/ .. this seems ripe for file collisions in the case of multiple entries and doesn't give us the possibility of making a nice KCM to select themes. better would probably be to use Plasma::Package (or if we wish to not link against libplasma, use Plasma::Package in the kcm and just directly open the files in the appropriate directories beneath kscreenlocker; however the QML brings in libplasma so i don't see any benefit to not just using Plasma::Package directly) * there is, understandably, a lot of X-isms in the code. in particular, some calls to XScreenSaver and then much of the code in LockWindow. in preperation for a move to Wayland, this should be encapsulated in a file that can be built conditionally on the window system target. For Wayland we need a different architecture. I doubt it makes much sense to share anything except the QML files. So I would defer this to when we actually have Wayland as the underlying windowing system. * widgets on screensaver feature is broken. while the plasma-overlay screen does come up, you can not unlock the screen due to its tight integration with the previous locker. What? That worked quite fine when I last touched the branch. Actually I removed all the integration bits for the old screenlocker. You are working on branch screenlocker and not on farhad_hf/lockscreen? so ... that needs some work too. in particular, it should probably be integrated with kscreenlocker itself and the plasmoids placed directly on the same QML layer as the screenlocker itself. whether this is available or not could be a feature of the theme? I thought about it, too. But just starting the plasma-overlay takes quite some time. On my high end system it often takes so long that the system suspended before the screen locker becomes visible. * there are a large number of issues in the default locker QML. a rewrite is probably in order. (issues include: the frame which contains the greater is the wrong size, the keyboard layout selection button is in an odd place, uses things like QGraphicsLinearLayouts, the password line edit does not get focus on first start, when selecting start a new session, the text and widgets are completely misplaced (not kept within the greeter frame)) it uses QGraphicsLayouts because we need to embed QWidgets. Unfortunately we do not get to the underlying system. If we don't want anymore the QWidgets we would have to rewrite the complete authentication system :-( * related to the above, blanking the screen is now left up to powermanagement. fair enough. however, the defaults for powermanagement for systems that are plugged in tends to mean it won't happen for quite some time on most systems. it feels rather innelegant to have the lock screen just always showing. in the default theme, fading out at least the greater UI when there is no user interaction and back in when user interaction happens (independent of power management) might feel nicer. I would prefer to get this right and turn off the screen. Blanking the screen by painting black feels wrong to me. In fact I always thought that my screen turns off till I used the new locker * the default wallpaper of the desktop theme is used when locking the screen. this doesn't feel right; looking at that default paper, i expect the wallpaper shown on my desktop that i've configured. This would require to pull in the complete Plasma Wallpaper stuff. And this becomes really difficult for things like multi screen. yet on Plasma Active we do show a default hard-coded image and there this feels right. i had to ask myself: why? i think because the image used looks sufficiently different, has few colours, etc. (it's also imagery used in the start up sequence, but that's overly relevant). i'd like to see something similar for the default theme for screen locking. the theme paper is just too ... wallpapery :) * the daemon (though not the locker itself, of course) should be integrated into ksmserver, giving us one long-running daemon for all things session management related so a fair amount of work left to be done here and what i thought would be a one-day job turned into
Re: Re: [RFC] Remove Xinerama related options
On Friday 20 January 2012 14:13:17 XI wrote:
so you would only need one of the options, the fullscreen one? And in
fact you only want that for vlc, right? You don't want the option for
let's say Firefox?
So e.g. a KWin script taking care of setting the fullscreen video player
to all screens would suit you better, right?
You are right, the only option I used is the fullscreen one. I used it
with xine, but the same apply for vlc, Could also be useful for
picture viewer, but you are right, I wouldn't want it for other
applications.
I don't know what's your idea behind the script taking care of setting
the fullscreen ? Do you want to use Special Window Settings... menu
for movie players ? If it works for setting a fullscreen spawning all
monitors, that sounds a reasonable option for me.
Or maybe you are thinking about something else ?
I'm talking about the scripting interface for KWin. I just wrote a script for
that:
workspace.clientFullScreenSet.connect(function(client, set) {
if (client.resourceName == vlc set) {
client.geometry = {x: 0, y: 0, width: 1280+1920, height: 1024};
}
});
works like a charm. Vlc spans both screens when going to fullscreen. For 4.9
GHNS support for KWin scripts is scheduled. For more information about KWin
scripting see [1] (Be aware that the API changes with 4.9)
Anyway, no need to say that if there is new feature to play fullscreen
movies on several monitors, user should have the choice to enable or
disable this feature (I don't think all xinerama users want to watch
their movie across all their monitors ;-))
yes the script would have to be installed manually. But that's the general
idea behind the scripting. Allowing users to do much much more with the window
manager than what has been possible before.
Cheers
Martin
[1] http://techbase.kde.org/Development/Tutorials/KWin/Scripting
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: Re: Re: [RFC] Remove Xinerama related options
On Friday 20 January 2012 20:04:12 Hans Chen wrote: While we're talking about confusing options in System Settings, I've always wondered why there are two Xinerama options in Window Behavior (Focus tab) - Separate screen focus and Active screen follows mouse. In particular, how does the latter work together with Show unmanaged windows on? Honest answer: I have no clue what these options are about. Thought it could be worth taking into consideration when cleaning up the multiple monitor options. Yes that is needed. With best regards, Hans On Fri, Jan 20, 2012 at 19:08, Shaun Reich shaun.re...@kdemail.net wrote: On Fri, Jan 20, 2012 at 11:32 AM, Thomas Lübking thomas.luebk...@gmail.com wrote: a) cool - wasn't aware that there's lxr.kde.org (just typed that into the browser just after reading ;-) b) how? - afaik lxr only handles definitions, not use random strings in some function and while 'Unmanaged' leads to the kwin Unmanged and some other, 'Unmanaged' leads nowhere - lxr has both C++ understanding (which is that default textbox you see, identifier searching), as well as a more hidden feature under 'general search' wherein you can search arbitrary strings in arbitrary files, arbitrarily (like grep) ;-) supports regexp as well that's the one i tend to need the most honestly. though you need to be careful when searching strings, as remember some may be like 'unmanaged window', which would just screw your whole search over ;) -- Shaun Reich, KDE Software Developer (kde.org) ___ 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
Review Request: Drop Xinerama related options in KWin
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103756/ --- Review request for kwin and Plasma. Description --- As discussed on the mailinglist: drop of the xinerama related options and the kcm. Given that the show unmanaged windows on option is in fact not used, I dropped the complete KCM. Diffs - kcontrol/CMakeLists.txt 8cd9a46 kcontrol/xinerama/CMakeLists.txt fe332e5 kcontrol/xinerama/Messages.sh f4aa134 kcontrol/xinerama/interface_util.h 8a4fcd1 kcontrol/xinerama/kcmxinerama.h 18b9241 kcontrol/xinerama/kcmxinerama.cpp a456b2c kcontrol/xinerama/test_kcm_xinerama.cpp a358a2c kcontrol/xinerama/xinerama.desktop e8ce525 kcontrol/xinerama/xineramawidget.h 2c446a2 kcontrol/xinerama/xineramawidget.cpp df9cb2f kcontrol/xinerama/xineramawidget.ui 90ec4d4 kwin/geometry.cpp a414e26 kwin/manage.cpp c551eac kwin/options.h 9dc29cf kwin/options.cpp d496569 kwin/tabbox/tabbox.cpp 3051316 kwin/toplevel.cpp ffe7f0c kwin/workspace.cpp 69b4ecb Diff: http://git.reviewboard.kde.org/r/103756/diff/diff Testing --- Fullscreen: works Maximize: works Movment: works Placement: works Thanks, Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: prep'ing the QML screenlocker for a merge into master
On Saturday 21 January 2012 15:32:10 Aaron J. Seigo wrote: it uses QGraphicsLayouts because we need to embed QWidgets. Unfortunately we do not get to the underlying system. If we don't want anymore the QWidgets we would have to rewrite the complete authentication system :-( yes, i know. however, there are some things used in the QML that are probably not needed / should be replaced with the components work. right, I didn't like to have the keyboard switcher embedded as a QWidget for example. * related to the above, blanking the screen is now left up to powermanagement. fair enough. however, the defaults for powermanagement for systems that are plugged in tends to mean it won't happen for quite some time on most systems. it feels rather innelegant to have the lock screen just always showing. in the default theme, fading out at least the greater UI when there is no user interaction and back in when user interaction happens (independent of power management) might feel nicer. I would prefer to get this right and turn off the screen. Blanking the screen by painting black feels wrong to me. In fact I always thought that my screen turns off till I used the new locker ah, yes, i would like to do it with turning off the screen (rather than just painting black) good * the default wallpaper of the desktop theme is used when locking the screen. this doesn't feel right; looking at that default paper, i expect the wallpaper shown on my desktop that i've configured. This would require to pull in the complete Plasma Wallpaper stuff. And this becomes really difficult for things like multi screen. nah, it's pretty easy for multiscreen. still, i do prefer the idea of a lock- screen specific thing (perhaps something that is coordinated with the QML log in screen too?) I would like to have it coordinated with the log in screen. I think this would give a very pleasant experience especially if we go for not stopping at KDM but logging in the user directly (as done on PA). 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: Drop Xinerama related options in KWin
On Jan. 22, 2012, 7:54 p.m., Thomas Lübking wrote: kwin/geometry.cpp, line 250 http://git.reviewboard.kde.org/r/103756/diff/1/?file=47685#file47685line250 should possibly be if (is_multihead) screen = screen_number; else if (screen == -1) ?? is screen_number part of the make kwin work on real multihead thing? looks like it's statically assigned to DefaultScreen(dpy) in main.cpp what does not cover the case when one head has multiple (randr) screens?! I'm not sure why it is that way. Last commit which changed it: Replace -1 with active screen in clientArea() if needed. So no idea whether this is related to multi head at all. -1 means active screen, I think. does not cover the case when one head has multiple (randr) screens?! I think it is a save assumption to say that someone using multi head won't use xrandr as well. Even if not I think we can make that a limitation. If someone wants multi head he has to live with it. On Jan. 22, 2012, 7:54 p.m., Thomas Lübking wrote: kwin/geometry.cpp, line 255 http://git.reviewboard.kde.org/r/103756/diff/1/?file=47685#file47685line255 not your change, but looks like senseless code duplication. esp: why does the is_multihead block test screen screenarea[desktop].size() but uses screenarea[desktop][screen_number]? Otherwise the blocks are equal but for screen/screen_number will keep that for now as well and probably have a more close look on why we do all these calculations in the first place. Seems all a bit redundant. On Jan. 22, 2012, 7:54 p.m., Thomas Lübking wrote: kwin/geometry.cpp, line 283 http://git.reviewboard.kde.org/r/103756/diff/1/?file=47685#file47685line283 since we acquire sarea/warea above (including some sanity check), can't we just return it here? Otherwise it maybe shouldn't be calculated / fetched against screenarea[desktop] unconditionally but just for MaximizeArea resp. WorkArea will keep it for now as well. On Jan. 22, 2012, 7:54 p.m., Thomas Lübking wrote: kwin/manage.cpp, line 229 http://git.reviewboard.kde.org/r/103756/diff/1/?file=47686#file47686line229 afaics this option is dead. I've that key nowhere in no config and it wasn't provided by the xinerama kcm either yes, you are right, it's nowhere set and I dropped it. - Martin --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103756/#review10006 --- On Jan. 22, 2012, 10:21 a.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103756/ --- (Updated Jan. 22, 2012, 10:21 a.m.) Review request for kwin and Plasma. Description --- As discussed on the mailinglist: drop of the xinerama related options and the kcm. Given that the show unmanaged windows on option is in fact not used, I dropped the complete KCM. Diffs - kcontrol/CMakeLists.txt 8cd9a46 kcontrol/xinerama/CMakeLists.txt fe332e5 kcontrol/xinerama/Messages.sh f4aa134 kcontrol/xinerama/interface_util.h 8a4fcd1 kcontrol/xinerama/kcmxinerama.h 18b9241 kcontrol/xinerama/kcmxinerama.cpp a456b2c kcontrol/xinerama/test_kcm_xinerama.cpp a358a2c kcontrol/xinerama/xinerama.desktop e8ce525 kcontrol/xinerama/xineramawidget.h 2c446a2 kcontrol/xinerama/xineramawidget.cpp df9cb2f kcontrol/xinerama/xineramawidget.ui 90ec4d4 kwin/geometry.cpp a414e26 kwin/manage.cpp c551eac kwin/options.h 9dc29cf kwin/options.cpp d496569 kwin/tabbox/tabbox.cpp 3051316 kwin/toplevel.cpp ffe7f0c kwin/workspace.cpp 69b4ecb Diff: http://git.reviewboard.kde.org/r/103756/diff/diff Testing --- Fullscreen: works Maximize: works Movment: works Placement: works Thanks, Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Drop Xinerama related options in KWin
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103756/ --- (Updated Jan. 26, 2012, 6:47 a.m.) Review request for kwin and Plasma. Changes --- * dropped one more option * simplified the clientArea() method by merging the parts returning the same values. Description --- As discussed on the mailinglist: drop of the xinerama related options and the kcm. Given that the show unmanaged windows on option is in fact not used, I dropped the complete KCM. Diffs (updated) - kcontrol/CMakeLists.txt 8cd9a46 kcontrol/xinerama/CMakeLists.txt fe332e5 kcontrol/xinerama/Messages.sh f4aa134 kcontrol/xinerama/interface_util.h 8a4fcd1 kcontrol/xinerama/kcmxinerama.h 18b9241 kcontrol/xinerama/kcmxinerama.cpp a456b2c kcontrol/xinerama/test_kcm_xinerama.cpp a358a2c kcontrol/xinerama/xinerama.desktop e8ce525 kcontrol/xinerama/xineramawidget.h 2c446a2 kcontrol/xinerama/xineramawidget.cpp df9cb2f kcontrol/xinerama/xineramawidget.ui 90ec4d4 kwin/geometry.cpp a414e26 kwin/manage.cpp c551eac kwin/options.h 9dc29cf kwin/options.cpp d496569 kwin/tabbox/tabbox.cpp 3051316 kwin/toplevel.cpp ffe7f0c kwin/workspace.cpp 69b4ecb Diff: http://git.reviewboard.kde.org/r/103756/diff/diff Testing --- Fullscreen: works Maximize: works Movment: works Placement: works Thanks, Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: Fwd: Forward porting policy
On Thursday 26 January 2012 17:02:14 Aaron J. Seigo wrote: i suppose we could set up someone as the merge dude who does this once a week, though. you know that you just volunteered :-P 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
[RFC] File ending for packaged KWin effects and where to put them
Hi workspace developers, my JavaScript bindings for KWin effects are nearly in place and that results in a few questions I wanted to discuss with the greater team. The scripted effects follow the Plasma Packages structure and I plan to have also normal KWin scripts use Plasma Package structure as well as window decorations and window switcher layouts. Should such files use the file ending plasmoid or should we introduce new names like kwineffect, kwinswitcher, kwinscript, kwindecoration? Could using plasmoid result in problems like the widgets explorer trying to install the kwineffect when dropped on the desktop? The second question I have is about the additional effects. Now that we have the scripted bindings I want to rewrite a few pure eye-candy effects with the bindings and move them out of the KWin source tree. Where should they go? I tend to plasma-addons. Last but not least: how does this synchrotron work and does it offer something which would be very useful to distribute our effects, scripts, etc? 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: [RFC] File ending for packaged KWin effects and where to put them
On Thursday 09 February 2012 17:45:03 Weng Xuetian wrote: On Thu, Feb 9, 2012 at 4:57 PM, Martin Gräßlin mgraess...@kde.org wrote: Hi workspace developers, my JavaScript bindings for KWin effects are nearly in place and that results in a few questions I wanted to discuss with the greater team. The scripted effects follow the Plasma Packages structure and I plan to have also normal KWin scripts use Plasma Package structure as well as window decorations and window switcher layouts. Should such files use the file ending plasmoid or should we introduce new names like kwineffect, kwinswitcher, kwinscript, kwindecoration? Could using plasmoid result in problems like the widgets explorer trying to install the kwineffect when dropped on the desktop? plasmoid is just a zip rename into .plasmoid, and if .kwineffect will be used, you should add something similar to /usr/share/mime/application/x-plasma.xml. Add new mime-type for kwin effects have a benefit that they can be assigned to different installer easily, if user want to have a feature that double click on .kwineffect file and can have it installed. The second question I have is about the additional effects. Now that we have the scripted bindings I want to rewrite a few pure eye-candy effects with the bindings and move them out of the KWin source tree. Where should they go? I tend to plasma-addons. Last but not least: how does this synchrotron work and does it offer something which would be very useful to distribute our effects, scripts, etc? I think you can request a new category for kwin effect on kde-look.org, currently there is no separate kwin effect category and all existing third-party effect are seems to be in KDE Improvement. Something like KWin Effects Binary and KWin Effects Scripts should be added. yes of course, but this does not make sense before the code is written. In fact I want to have the new categories on kde-look hidden till our first 4.9 beta is released :-) 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: Integrate AppMenu into Workspace 4.9
On Thursday 09 February 2012 16:07:13 Alex Fiestas wrote: Hey there! It seems that people really likes AppMenu, we have fans of everything we have done with it so far: -oxygen-appmenu -plasmoid -runner So it seems clear to me that we should integrate this technology into Workspace 4.9, but before we do it would be good to hear opinions about these questions: -Is there any way of integrating oxygen-appmenu without breaking api-abi? Maybe a second version of the API? If that refers to KWin decoration API: no problem as we are going to break deco API in 4.9 anyway :-) -How the KDED works? -Is there any plans to extend libdbusmenu-qt to make it export the menu as a model? -Do we need something else to complete our support? documentation maybe? -What is the status of it being merged into GTK ? Personally I think that AppMenu is a powerful technology that will allow us to decide how and when show the menubars which sure will be handy in the future. So, what do you think of AppMenu? I'm all for it and would even say we go for default menu in windeco. 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: Integrate AppMenu into Workspace 4.9
On Thursday 09 February 2012 16:31:27 Alex Fiestas wrote: On Thu, Feb 9, 2012 at 4:24 PM, Martin Gräßlin mgraess...@kde.org wrote: If that refers to KWin decoration API: no problem as we are going to break deco API in 4.9 anyway :-) Oh didn't know that, because the QML decoration thing? no, because window tabbing is broken beyond any repair and Thomas is currently rewriting it and because of that we need adjustments to the API. We use this as an excuse to clean up a little bit and given that there are no 3rd party decorations except for skulpture, dekorator, bespin and QtCurve which are all developed by developers close to us it's not a big issue. I'm all for it and would even say we go for default menu in windeco. In that case I would really love to see something like this: http://www.afiestas.org/improving-kde-applications-help-menu-actions-lookup/ But in this case I'd put the textbox at the bottom, what do you think? I can take some time today to try to do a PoC if you like the idea. sounds like an awesome idea. I had seen this today for the first time in your linked video and really liked it. BTW remember to reply to all, I'm not sure if gnumdk is in plasma-devel. ups, but even in your mail only agateau was included... 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: Integrate AppMenu into Workspace 4.9
On Thursday 09 February 2012 23:40:07 Weng Xuetian wrote: On Thu, Feb 9, 2012 at 11:24 PM, Martin Gräßlin mgraess...@kde.org wrote: On Thursday 09 February 2012 16:07:13 Alex Fiestas wrote: Hey there! It seems that people really likes AppMenu, we have fans of everything we have done with it so far: -oxygen-appmenu -plasmoid -runner So it seems clear to me that we should integrate this technology into Workspace 4.9, but before we do it would be good to hear opinions about these questions: -Is there any way of integrating oxygen-appmenu without breaking api-abi? Maybe a second version of the API? If that refers to KWin decoration API: no problem as we are going to break deco API in 4.9 anyway :-) -How the KDED works? -Is there any plans to extend libdbusmenu-qt to make it export the menu as a model? -Do we need something else to complete our support? documentation maybe? -What is the status of it being merged into GTK ? Personally I think that AppMenu is a powerful technology that will allow us to decide how and when show the menubars which sure will be handy in the future. So, what do you think of AppMenu? I'm all for it and would even say we go for default menu in windeco. Cheers Martin I would say give it a blacklist for some special application, such as gimp / inkscape. Current win deco menu button is not a good solution for those. For other menu-is-rarely-used-application (Maybe that's the most case), my two cents for putting it in windeco. By the way, is there anyway for people to implement some special appmenu only case like compact menu of firefox? I currently don't see it is possible with dbus menu. No I think this is not yet possible. But it is something we should do in Frameworks 5. Just turning the menu from horizontal to vertical is not a perfect solution and I really like what Dolphin did to the collapsed menu. Firefox btw did a bad implementation: just try to navigate with keyboard only :-) 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: Re: Integrate AppMenu into Workspace 4.9
On Friday 10 February 2012 00:22:21 Weng Xuetian wrote: By the way, is it possible to make win deco use another menu right now? For example, can dolphin use its collapsed menu if windeco menu is used, or if it's not possible automatically, can dolphin manually do it? yes, that's what I meant with needs support in Frameworks 5. We need to add an API to allow applications to export a specific menu. By the way GNOME is also doing something similar, though not knowing the implementation detail. http://live.gnome.org/ThreePointThree/Features/ApplicationMenu Seems they try to give application a global hint via a daemon for what kind of menu they can make use of, in order to choose different kinds of menu to meet the specific environment. Traditional menu is not a good idea for all application, but putting existing traditional menu directly into windeco is also not a good idea for me (this can be done later, but if windeco is pushed by default, might break some sort of user experience for specific application). interesting, that sounds like a good opportunity to collaborate. 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
Review Request: Support KWin packages in plasmapkg
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104000/ --- Review request for Plasma. Description --- Makes plasmapkg aware of the KWin packages currently present in master or in the pipeline to be shortly supported. That is: * window switcher (present in master) * kwin effect (exists as review request) * kwin script (exists on my hard disk) Missing is decoration which I have not yet implemented. Will be added as another request. Diffs - plasma/tools/plasmapkg/main.cpp f699eec Diff: http://git.reviewboard.kde.org/r/104000/diff/ Testing --- Tried to install a window switcher Thanks, Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: Re: [RFC] Remove Xinerama related options
Anyway, no need to say that if there is new feature to play fullscreen movies on several monitors, user should have the choice to enable or disable this feature (I don't think all xinerama users want to watch their movie across all their monitors ;-)) yes the script would have to be installed manually. But that's the general idea behind the scripting. Allowing users to do much much more with the window manager than what has been possible before. Just for the record: https://git.reviewboard.kde.org/r/104014/ The script will be installed, the user just has to enable it. I think this is a quite nice solution to such problems. 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: Regression: Keyboard shortcuts in Plasma Netbook
Hi Mogliii, we understand that this regression is a serious issue for you. Unfortunately sending bug reports to the mailing list doesn't fix problems. To track and manage bugs we have a bugzilla installation. At the moment we have more than 1000 open bug reports for plasma. You can know imagine the problems if each of the bug reports would be sent to the mailinglist :-) The best way to help the KDE team to get such bugs fixed is by helping the bug triaging team to better manage the bugs so that the developers can concentrate on fixing the bugs. Please see http://techbase.kde.org/Contribute/Bugsquad for more information. Kind Regards Martin Gräßlin Am 07.03.2012 13:55, schrieb mogliii: Dear Plasma-developer, i want to point your attention to the following bug report: https://bugs.kde.org/show_bug.cgi?id=295424 There are currently not keyboard shortcuts in Plasma Netbook to reach the entry field on the Search launch view, no shortcut to open the system monitor (to view/kill processes) and session locking does not work. It seems that shortcuts are currently not implemented, although they were in earlier KDE SC versions. Many thanks, Mogliii ___ 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: Workflow Idea for 4.10
On Friday 09 March 2012 07:52:37 Luca Beltrame wrote: In data venerdì 09 marzo 2012 00:27:51, Alex Fiestas ha scritto: - Move to a review based workflow before hard freeze (we need gerrit). Do you mean for the Workspace, or for the entirety of KDE? For both cases, what does sysadmin think? only for workspace. Sysadmin have not yet been contacted about it, but in general sysadmins are very open to requests from the community :-) 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
March Iteration of Frameworks epic
Hi all, the March Iteration of splitting kdelibs [1] involves KWindowSystem. As I was appointed to be responsible for that I will concentrate my work on this epic starting from next week. Any help is more than appreciated. What I plan to achieve: * getting kwindowsystem as a Tier 1 library (currently it's planned as a Tier 2) * moving Plasma::WindowEffects into this library * reaching a test coverage of 90 % * removing all deprecated atom hints/legacy functionality etc. * clean up coding style ;-) * where it makes sense introduce Q_PROPERTIES A few things I will have to discuss with the KDE Frameworks maintainers. E.g. I think we should drop the Windows and MacOS X implementations of KWindowSystem as it is too close to our X world. I plan to do a review request for each change and include the kwin group, for things needing discussions I will start an RFC thread first (e.g. should we change desktop with number 0 to be the first desktop as it is in NETWM spec). Cheers Martin [1] http://community.kde.org/Frameworks/Epics/Splitting_kdelibs#March_Iteration 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: March Iteration of Frameworks epic
On Friday 09 March 2012 18:11:53 Kevin Ottens wrote: On Friday 09 March 2012 17:58:35 Martin Gräßlin wrote: A few things I will have to discuss with the KDE Frameworks maintainers. E.g. I think we should drop the Windows and MacOS X implementations of KWindowSystem as it is too close to our X world. Disclaimer: I'm close to clueless about KWindowSystem and friends, mainly shuffling options here. I'm wondering if that's a wise choice or if it would be better to make the API of KWindowSystem less X oriented. Especially if it lands in Tier 1 I would see a strong value in the possibility of using KWindowSystem API on non-X systems. I count at least Wayland based systems which will appear at some point, we'd better be ready for them if possible. Also the Windows and MacOS X support are an interesting asset for the library reusability. The library is mostly a wrapper for the Extended Window Manger Hints freedesktop spec. It contains things like setting a window to be kept above other windows. Features not at all available on any system except X (and later on KWin+Wayland). I just had a look at the implementations on Windows [1] and Mac [2]. Both are mostly stubs around isn't yet implemented debug messages. So personally I question the usefulness of this API for non X (or KWin+Wayland) systems. I just did a short lxr.kde.org search and it seems that applications using it do not have the calls in an ifdef block. So this might be problematic. Supporting Wayland will btw require quite some work as that will be a change of how the API is designed. The API currently assumes that there is just one windowing system compiled (usage of ifdef). But that won't be the case with Wayland. On the same platform we will have either Wayland or X or most likely both. I have some ideas how to handle that but it will require more thinking. Cheers Martin [1]: http://api.kde.org/4.x-api/kdelibs- apidocs/kdeui/html/kwindowsystem__win_8cpp_source.html [2]: http://api.kde.org/4.x-api/kdelibs- apidocs/kdeui/html/kwindowsystem__mac_8cpp_source.html 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
RFC: Removing of decorations
Hi all, I was considering to clean up the window decorations in KWin. Currently we ship: * Oxygen (default) * Aurorae (theme engine) * b2 * laptop * Plastik At least for Plastik we know that it is currently broken with Compositing and nobody is going to fix that. All decorations except Oxygen and Aurorae have not seen any (real) commits since 2009. I consider them as bitrotting. In the past we did one decoration removal where we moved the decorations to kde-artwork. I don't think that kde-artwork should be the dumping ground for visually outdated decorations. And with git that would not be possible anyway. Another solution of the past had been to move the code to tag/unsupported which also does no longer work. So what to do? So I propose the following changes: 1. git rm b2 laptop plastik 2. move Oxygen out of the KWin source tree to have all of Oxygen in one place 3. rename clients to decoration as I personally find the name confusing due to the fact that there is also a Client class in KWin Deleting the old decorations will mean removing the only decorations which work well for thin clients or X forwarding. But I don't consider this an important enough use case to keep visually outdated decorations around. Any comments? 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: RFC: Removing of decorations
On Sunday 11 March 2012 09:23:46 Luca Beltrame wrote: In data sabato 10 marzo 2012 07:51:37, Martin Gräßlin ha scritto: Deleting the old decorations will mean removing the only decorations which work well for thin clients or X forwarding. But I don't consider this an The question then is: does Oxygen work realiably for thin clients / X forwarding? If not, then IMO at least one of the two need to stay, as thin clients are still used in setups of a certain relevance (think school labs or something of the sort). Do we have to include by default a visually outdated theme (Laptop) or an even broken theme (Plastik) just for thin clients? Is this the primary target group of our user base? Is it acceptable to ship by default an additional theme which puts KDE into a bad light by most users just for a minor use case? We have to remember that Thin-Clients need major adjustments to the default settings. E.g. running compositing is completely unsuited for a network transparent solution. Also the Qt graphics system backend has to be changed to native. I think it is acceptable to install another window decoration from kde-artwork to get something for thin clients. Personally I would prefer to see a proper thin client solution consisting of a lightweight window decoration, a light weight widget style. At the moment the default KDE Plasma theme is everywhere completely unsuited for the use in thin client setups. 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: RFC: Removing of decorations
On Monday 12 March 2012 10:54:52 Hugo Pereira Da Costa wrote: 1. I'm all for removing the unmaintained decoration. 2. I'm not sure about the rationale for moving oxygen's (deco) out of kwin tree. It is a decoration client, and therefore would best stay is in kwin/clients. (especially since it has to be build on top of kwin, unlike oxygen's libs and oxygen's style). As for the argument having all oxygen's code in one place. Well, that would also require to have oxygen's widget style and oxygen's lib at the same place. (which one ?). And you would still need a liboxygen.so anyway, I think, for the code that is shared by the widget style and the decoration. This to say, what would the moving actually address, solve ? (you do need to build kwin anyway in order to build oxygen's client). I thought that Oxygen would have wanted to have all code in one place and that this has never been possible because the deco has to be inside kwin. 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: RFC: Removing of decorations
On Wednesday 14 March 2012 13:22:40 Aaron J. Seigo wrote: On Sunday, March 11, 2012 11:01:11 Martin Gräßlin wrote: Do we have to include by default a visually outdated theme (Laptop) or an even broken theme (Plastik) just for thin clients? given that i don't want to have to answer all the problems and complaints from our large user base of thin client installs: imho, yes. at the very least, pick one, clean it up a little bit if needed and drop the rest. but not having something for thin clients at this point would be a disasterous mistake in terms of user relations and existing user base support. I take this as a veto from the workspace coordinator ;-) In that case I propose to only drop b2 and Plastik and keep laptop under a new name (maybe just lightweight or thin client). I would drop Plastik due to the fact that it is broken with compositing and I don't see anybody starting to fix it. For 4.10 I would like to see a new modern style for thin clients being implemented. I'll talk to Nuno. 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
Review Request: Drop Decorations B2 and Plastik
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104281/ --- Review request for kwin and Plasma. Description --- As discussed on mailinglist: http://lists.kde.org/?l=kwinm=133136239707091w=2 Diffs - kwin/clients/CMakeLists.txt 6019a9e kwin/clients/b2/CMakeLists.txt 9295cbe kwin/clients/b2/b2.desktop 2846e39 kwin/clients/b2/b2client.h c9e9b57 kwin/clients/b2/b2client.cpp 6b52996 kwin/clients/b2/bitmaps.h 00c4552 kwin/clients/b2/config/CMakeLists.txt 1aaf8da kwin/clients/b2/config/config.h c5bc33c kwin/clients/b2/config/config.cpp fc9c7b9 kwin/clients/plastik/CMakeLists.txt fce0829 kwin/clients/plastik/config/CMakeLists.txt e48955d kwin/clients/plastik/config/config.h b037efe kwin/clients/plastik/config/config.cpp a4ddfe0 kwin/clients/plastik/config/configdialog.ui fe9f53a kwin/clients/plastik/plastik.h ae7a46e kwin/clients/plastik/plastik.cpp ff9825f kwin/clients/plastik/plastik.desktop 30550c6 kwin/clients/plastik/plastikbutton.h 395f628 kwin/clients/plastik/plastikbutton.cpp db29d76 kwin/clients/plastik/plastikclient.h 4c5b0d9 kwin/clients/plastik/plastikclient.cpp 58f8324 Diff: http://git.reviewboard.kde.org/r/104281/diff/ Testing --- it compiles Thanks, Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request: Rename window deocration Laptop to Minimal
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104282/ --- Review request for kwin and Plasma. Description --- The window decoration Laptop is kept for legacy or thin client setups. To make this more clear the decoration is renamed. In order to make the transition easier only the name is changed, while library name is untouched. Additionally a comment is added which should be shown in the user interface (requires bug #296041 to be implemented). Diffs - kwin/clients/laptop/laptop.desktop ccc9d54 kwin/clients/laptop/laptopclient.cpp 52efcd1 Diff: http://git.reviewboard.kde.org/r/104282/diff/ Testing --- Screenshots --- Renamed decoration http://git.reviewboard.kde.org/r/104282/s/465/ Thanks, Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
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/ --- 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: [RFC]: Rename Configure Window Behavior to Configure Window Management
On March 15, 2012, 12:19 p.m., Thomas Lübking wrote: Configure behavior of windows..:? In general the current string is bad, but i don't know whether joe windows user can make anything out of window management (the concept of a window manager and titlebars not being part of the actual window is usually confusing when you're first confronted with it - i do recall that from my very own past) When reordering the menu, I want to move the entry into the advanced section. That makes it hopefully better, but a better wording would be nice of course nevertheless :-) - Martin --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104284/#review11430 --- 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: Rename window deocration Laptop to Minimal
On March 15, 2012, 12:16 p.m., Thomas Lübking wrote: Leightweight? - Minimal is generic and could just as well read minimal functionality or stuff. About the comment: why not paint it directly into the preview? If you write a tldr; novel into a tooltip, that's not gonna help either. Thomas Lübking wrote: I'm the ultimate typoking, even beyond nuno - Lightweight Lightweight had already been discarded as possible name by Aaron (only replied to plasma-devel) as it places Oxygen in a bad light (opposite of lightweight is heavyweight, right ;-). - Martin --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104282/#review11428 --- On March 15, 2012, 7:28 a.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104282/ --- (Updated March 15, 2012, 7:28 a.m.) Review request for kwin and Plasma. Description --- The window decoration Laptop is kept for legacy or thin client setups. To make this more clear the decoration is renamed. In order to make the transition easier only the name is changed, while library name is untouched. Additionally a comment is added which should be shown in the user interface (requires bug #296041 to be implemented). Diffs - kwin/clients/laptop/laptop.desktop ccc9d54 kwin/clients/laptop/laptopclient.cpp 52efcd1 Diff: http://git.reviewboard.kde.org/r/104282/diff/ Testing --- Screenshots --- Renamed decoration http://git.reviewboard.kde.org/r/104282/s/465/ Thanks, Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Rename window deocration Laptop to Minimal
On March 15, 2012, 12:16 p.m., Thomas Lübking wrote: Leightweight? - Minimal is generic and could just as well read minimal functionality or stuff. About the comment: why not paint it directly into the preview? If you write a tldr; novel into a tooltip, that's not gonna help either. Thomas Lübking wrote: I'm the ultimate typoking, even beyond nuno - Lightweight Martin Gräßlin wrote: Lightweight had already been discarded as possible name by Aaron (only replied to plasma-devel) as it places Oxygen in a bad light (opposite of lightweight is heavyweight, right ;-). Thomas Lübking wrote: - thin - slim - unfancy - network transparent ;-) - plain - modest - artless - unpretentious - simple - legacy - failsafe - low end - oldschool - traditional created a doodle for it :-) http://www.doodle.com/e9se6zuz8ufepxke - Martin --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104282/#review11428 --- On March 15, 2012, 7:28 a.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104282/ --- (Updated March 15, 2012, 7:28 a.m.) Review request for kwin and Plasma. Description --- The window decoration Laptop is kept for legacy or thin client setups. To make this more clear the decoration is renamed. In order to make the transition easier only the name is changed, while library name is untouched. Additionally a comment is added which should be shown in the user interface (requires bug #296041 to be implemented). Diffs - kwin/clients/laptop/laptop.desktop ccc9d54 kwin/clients/laptop/laptopclient.cpp 52efcd1 Diff: http://git.reviewboard.kde.org/r/104282/diff/ Testing --- Screenshots --- Renamed decoration http://git.reviewboard.kde.org/r/104282/s/465/ Thanks, Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Help us finding the new name for Laptop window decoration
Hi all, in order to find a better name for the window decoration Laptop I created a doodle with possible names: http://www.doodle.com/e9se6zuz8ufepxke More info: https://git.reviewboard.kde.org/r/104282/ Please vote for your preferred name and don't make the fun out of it that everybody votes for a different name ;-) 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
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
