Re: Review Request 117822: Add safety checks to XCB functions in WindowThumbnail
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117822/ --- (Updated May 5, 2014, 6:06 a.m.) Status -- This change has been marked as submitted. Review request for Plasma. Repository: plasma-framework Description --- Add safety checks to XCB functions in WindowThumbnail Prevents XCB warnings about BadWindow when a tooltip is shown for the first time. Diffs - src/declarativeimports/core/windowthumbnail.cpp d1a7fef1fc5fd119592710d80274d2abe0c8b3b1 Diff: https://git.reviewboard.kde.org/r/117822/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 117822: Add safety checks to XCB functions in WindowThumbnail
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117822/#review57280 --- This review has been submitted with commit 491befb8508095da3579409a5b81b0d96bb18a06 by Martin Gräßlin to branch master. - Commit Hook On April 28, 2014, 8:20 a.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117822/ --- (Updated April 28, 2014, 8:20 a.m.) Review request for Plasma. Repository: plasma-framework Description --- Add safety checks to XCB functions in WindowThumbnail Prevents XCB warnings about BadWindow when a tooltip is shown for the first time. Diffs - src/declarativeimports/core/windowthumbnail.cpp d1a7fef1fc5fd119592710d80274d2abe0c8b3b1 Diff: https://git.reviewboard.kde.org/r/117822/diff/ Testing --- Thanks, Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Fwd: [kconfig] src/core: Store app config file in ~/.config/domain/apprc
On Monday 05 May 2014 07:25:37 Martin Gräßlin wrote: On Sunday 04 May 2014 23:53:40 David Faure wrote: Hello, please note this change in KConfig. I would recommend making sure your applications call app.setOrganizationDomain(kde.org) so that the config files go into the right subdir right now. Otherwise you'll face migration issues later when setting that. How does that affect setting configuration from a kcm? E.g. if loaded through systemsettings one could assume that setOrganizationDomain is set to kde.org which could break any kcm needing another organization domain. Or if a KCM sets this to foo.bar than any kcm not resetting to kde.org would break, wouldn't it? I doubt KCMs use KSharedConfig::openConfig() or KConfig() without arguments. That would lead to kcmshell5rc or systemsettingsrc right now. Instead they surely name the config file they want to edit. If that config file happens to be for a specific application (rather than shared), then the KCM will need to open e.g. kde.org/konquerorrc instead of konquerorrc, indeed. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: Fwd: [kconfig] src/core: Store app config file in ~/.config/domain/apprc
On Monday 05 May 2014 08:17:49 David Faure wrote: On Monday 05 May 2014 07:25:37 Martin Gräßlin wrote: On Sunday 04 May 2014 23:53:40 David Faure wrote: Hello, please note this change in KConfig. I would recommend making sure your applications call app.setOrganizationDomain(kde.org) so that the config files go into the right subdir right now. Otherwise you'll face migration issues later when setting that. How does that affect setting configuration from a kcm? E.g. if loaded through systemsettings one could assume that setOrganizationDomain is set to kde.org which could break any kcm needing another organization domain. Or if a KCM sets this to foo.bar than any kcm not resetting to kde.org would break, wouldn't it? I doubt KCMs use KSharedConfig::openConfig() or KConfig() without arguments. That would lead to kcmshell5rc or systemsettingsrc right now. Instead they surely name the config file they want to edit. If that config file happens to be for a specific application (rather than shared), then the KCM will need to open e.g. kde.org/konquerorrc instead of konquerorrc, indeed. Yes, that's what I mean. E.g. in KWin our kcms do: KSharedConfig::openConfig(kwin); while in KWin it might be possible that we do: KSharedConfig::openConfig(); (though I think most use KSharedConfig::openConfig()) which would result in breakage if we forget to adjust one. Thus it looks to me that we need to verify each and every KConfig and KSharedConfig::openConfig call and also kcfg files, 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: Breeze QML window decoration
On Sunday 04 May 2014 22:28:23 Andrew Lake wrote: Based on the design we came up with in the VDG forum, I completed a first go at doing up a Aurorae QML window decoration. I added it to the 'working' branch of the Breeze repo. As far as I can tell it works about as well as the Plastik QML decoration. Quick screenshot: http://wstaw.org/m/2014/05/05/QMLsnapshot.png I'll give it a try with my KWin maintainer hat on :-) FYI: I just pushed some important bug fixes for Aurorae - the mouse interaction is fixed \o/ 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 117900: Cleanup of screenlocker
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117900/ --- (Updated May 5, 2014, 9 a.m.) Review request for Plasma and David Edmundson. Changes --- changed the grabKeyboard and grabMouse to not be a lambda. Repository: plasma-workspace Description --- [screenlocker] Remove saverLockReady from org.kde.screensaver interface Wasn't implemented. [screenlocker] Remove setupPlasma from org.kde.screensaver interface We don't have the plasma-overlay anymore, so let's remove it. [screenlocker] Remove boolean trap in ::lock Use an enum value to indicate whether there's an immediate or a delayed lock. At the same time lock is no longer a slot. [screenlocker] Remove lock slot without argument Replace by lambda slot which delegates to lock(true). [screenlocker] Turn idleTimeout slot into lambda slot Code is only and should only be executed after the timeoutReached signal from KIdleTime. Using a lambda slot enforces that as well as adding compile time checking for connect syntax. [screenlocker] Turn lockProcessReady slot into a lambda slot Code should only be executed in reply to signal QProcess::readyReadStandardOutput. From anywhere else it would have been wrong. By using a lambda slot this gets enforces and the connection gets compile time checked. [screenlocker] Turn lockProcessFinished slot into a lambda slot LockProcessFinished should only be invoked when the QProcess::finished signal fired. Right now it was possible to invoke that from other code paths. By turning it into a lambda slot this becomes more clear and we get compile time checking for the connection. [screenlocker] Turn KSldApp::grabKeyboard and ::grabMouse into lambdas It's only used by ::establishGrab and shouldn't be used from anywhere else. To make this more clear the code is moved into lambda functions in ::establishGrab. [screenlocker] Move sanity checks for lockGrace to kcfg Kcfg provides min/max values, so we don't need the qBound in source code side. [screenlocker] Remove not needed includes Instead of using QDesktopWidget to get the id of the X11 rootWindow we just ask QX11Info. Diffs (updated) - ksmserver/screenlocker/dbus/org.kde.screensaver.xml e700b88215973f11b2601e5d164371874d262580 ksmserver/screenlocker/interface.h 97a60737632e1cd799c0a1b09cc73ab4b580d757 ksmserver/screenlocker/interface.cpp 0ce68c0d0d8aaf41588d5b5e73e66aa1b6320d15 ksmserver/screenlocker/kcfg/kscreensaversettings.kcfg 6a1cbb0935461c8045dd847a63e31e72fb6ca007 ksmserver/screenlocker/ksldapp.h 958b55c1ff83e21d57e3c1dfb812016f325046be ksmserver/screenlocker/ksldapp.cpp c678cfc33f82509776047894e46c4fbe15563d49 Diff: https://git.reviewboard.kde.org/r/117900/diff/ Testing --- Thanks, Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Fwd: [kconfig] src/core: Store app config file in ~/.config/domain/apprc
On Monday 05 May 2014 08:29:07 Martin Gräßlin wrote: On Monday 05 May 2014 08:17:49 David Faure wrote: On Monday 05 May 2014 07:25:37 Martin Gräßlin wrote: On Sunday 04 May 2014 23:53:40 David Faure wrote: Hello, please note this change in KConfig. I would recommend making sure your applications call app.setOrganizationDomain(kde.org) so that the config files go into the right subdir right now. Otherwise you'll face migration issues later when setting that. How does that affect setting configuration from a kcm? E.g. if loaded through systemsettings one could assume that setOrganizationDomain is set to kde.org which could break any kcm needing another organization domain. Or if a KCM sets this to foo.bar than any kcm not resetting to kde.org would break, wouldn't it? I doubt KCMs use KSharedConfig::openConfig() or KConfig() without arguments. That would lead to kcmshell5rc or systemsettingsrc right now. Instead they surely name the config file they want to edit. If that config file happens to be for a specific application (rather than shared), then the KCM will need to open e.g. kde.org/konquerorrc instead of konquerorrc, indeed. Yes, that's what I mean. E.g. in KWin our kcms do: KSharedConfig::openConfig(kwin); while in KWin it might be possible that we do: KSharedConfig::openConfig(); (though I think most use KSharedConfig::openConfig()) which would result in breakage if we forget to adjust one. Thus it looks to me that we need to verify each and every KConfig and KSharedConfig::openConfig call and also kcfg files, right? Right. I just thought about an alternative: KConfig defaults to organizationdomain/ for all config files including the named ones, but gains a flag NoOrganizationDomain which we'd have to use for files that are shared between applications, such as kdeglobals, kdebugrc, trashrc, servicetype_profilerc, kbookmarkrc, emaildefaults, kwalletrc, etc. Anything that is opened by a framework or other general-purpose libraries needs that flag, otherwise apps with a different org domain wouldn't find them. At best, for cleanliness, libs can hardcode a prefix such as kde.org, but they can't rely on the value of organizationDomain. Maybe this way around is less work indeed. I'm not sure. The risk for undetected breakages is higher (since we'd only notice it when running an app with a different org domain). Kate will end up being the perfect test app for this, with its kate-editor.org domain :-) -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 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: Breeze repo
On Monday 05 May 2014, Andrew Lake wrote: I went ahead and added a 'working' branch and added the following: later i'll check and see to make everything built and installed -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Breeze QML window decoration
On Monday 05 May 2014, Martin Gräßlin wrote: On Sunday 04 May 2014 22:28:23 Andrew Lake wrote: Based on the design we came up with in the VDG forum, I completed a first go at doing up a Aurorae QML window decoration. I added it to the 'working' branch of the Breeze repo. As far as I can tell it works about as well as the Plastik QML decoration. Quick screenshot: http://wstaw.org/m/2014/05/05/QMLsnapshot.png I'll give it a try with my KWin maintainer hat on :-) FYI: I just pushed some important bug fixes for Aurorae - the mouse interaction is fixed \o/ btw, if you can push in a branch a very basic c++ one, me and hopefully others can finish it. (i am not sure what is the minimum amount of stuff to reimplement, can also be tried to start from oxygen, but there may be too much stuff to dismantle) -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: Breeze QML window decoration
On Monday 05 May 2014 10:33:33 Marco Martin wrote: On Monday 05 May 2014, Martin Gräßlin wrote: On Sunday 04 May 2014 22:28:23 Andrew Lake wrote: Based on the design we came up with in the VDG forum, I completed a first go at doing up a Aurorae QML window decoration. I added it to the 'working' branch of the Breeze repo. As far as I can tell it works about as well as the Plastik QML decoration. Quick screenshot: http://wstaw.org/m/2014/05/05/QMLsnapshot.png I'll give it a try with my KWin maintainer hat on :-) FYI: I just pushed some important bug fixes for Aurorae - the mouse interaction is fixed \o/ btw, if you can push in a branch a very basic c++ one, me and hopefully others can finish it. (i am not sure what is the minimum amount of stuff to reimplement, can also be tried to start from oxygen, but there may be too much stuff to dismantle) Oxygen is probably a bad place to start, it's doing too much. I can try to schedule some time to look at the QML base and try to come up with a good C++ design for it. Probably not this week as I want to spend time on the screenlocker. 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: Fwd: [kconfig] src/core: Store app config file in ~/.config/domain/apprc
On Sunday 04 May 2014, David Faure wrote: Hello, please note this change in KConfig. I would recommend making sure your applications call app.setOrganizationDomain(kde.org) so that the config files go into the right subdir right now. Otherwise you'll face migration issues later when setting that. In plasma 3 config files are used, plasmarc, plasma_shellrc, plasma-shellname- appletsrc (like plasma-org.kde.desktop-appletsrc) so i guess all 3 files should go under kde.org subdirectory. configuration files are now open from different places in different ways, so i guess it will take a bit of doublechecking to see it always searches for the correct ones. does KSharedConfig::openConfig(confignamerc) now tries in ~/.config or in ~/.config/kde.org ? (supposing the domain is set) -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Fwd: [kconfig] src/core: Store app config file in ~/.config/domain/apprc
On Monday 05 May 2014 11:13:31 Marco Martin wrote: On Sunday 04 May 2014, David Faure wrote: Hello, please note this change in KConfig. I would recommend making sure your applications call app.setOrganizationDomain(kde.org) so that the config files go into the right subdir right now. Otherwise you'll face migration issues later when setting that. In plasma 3 config files are used, plasmarc, plasma_shellrc, plasma-shellname- appletsrc (like plasma-org.kde.desktop-appletsrc) so i guess all 3 files should go under kde.org subdirectory. configuration files are now open from different places in different ways, so i guess it will take a bit of doublechecking to see it always searches for the correct ones. does KSharedConfig::openConfig(confignamerc) now tries in ~/.config or in ~/.config/kde.org ? (supposing the domain is set) I reverted the change for now. Let's discuss whether the alternative is better :) -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 117946: Track screen changes in the containment when the containment is inside an applet
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117946/ --- (Updated May 5, 2014, 9:39 a.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and Plasma. Repository: plasma-framework Description --- Track screen changes in the containment when the containment is inside an applet Make the system tray containment update which screen it is on when the system tray applet is moved. This fixes notifications if the panel is moved between screens. Diffs - src/plasma/private/containment_p.h 24049c7 src/plasma/private/containment_p.cpp 9e67382 Diff: https://git.reviewboard.kde.org/r/117946/diff/ Testing --- Thanks, David Edmundson ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 117946: Track screen changes in the containment when the containment is inside an applet
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117946/#review57294 --- This review has been submitted with commit 873106a7ca4ff8f15e823b1019b4f5b66332867a by David Edmundson to branch master. - Commit Hook On May 2, 2014, 2:42 p.m., David Edmundson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117946/ --- (Updated May 2, 2014, 2:42 p.m.) Review request for KDE Frameworks and Plasma. Repository: plasma-framework Description --- Track screen changes in the containment when the containment is inside an applet Make the system tray containment update which screen it is on when the system tray applet is moved. This fixes notifications if the panel is moved between screens. Diffs - src/plasma/private/containment_p.h 24049c7 src/plasma/private/containment_p.cpp 9e67382 Diff: https://git.reviewboard.kde.org/r/117946/diff/ Testing --- Thanks, David Edmundson ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Fwd: [kconfig] src/core: Store app config file in ~/.config/domain/apprc
On Monday 05 May 2014, David Faure wrote: does KSharedConfig::openConfig(confignamerc) now tries in ~/.config or in ~/.config/kde.org ? (supposing the domain is set) I reverted the change for now. ok, so i will delay any local change in plasma Let's discuss whether the alternative is better so, the choice if i understood correctly is basically between: defaulting to use the domain in KSharedConfig::openConfig(confignamerc) that would probably be faster porting, *but* risking to break all uses of kdeglobals and the like, or not use the domain in this case, *but* risks to break all openconfig of a filename (that is not intended to be a global one) right? i don't see much painless ways.. almost seems to call for another method like openGlobalConfig() or something like that, like the flag but even more explicit. would perhaps be less confusing, but a bit late to be any painless never the less... -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 117813: Make the system tray faster
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117813/#review57296 --- Ship it! applets/systemtray/package/contents/ui/StatusNotifierItem.qml https://git.reviewboard.kde.org/r/117813/#comment39914 This could be removed, sebas said applets/systemtray/package/contents/ui/TaskDelegate.qml https://git.reviewboard.kde.org/r/117813/#comment39915 This is used (remove the fixme) applets/systemtray/plugin/host.cpp https://git.reviewboard.kde.org/r/117813/#comment39916 Remove this please, it adds nothing useful to the output - Martin Klapetek On May 2, 2014, 6:10 p.m., David Edmundson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117813/ --- (Updated May 2, 2014, 6:10 p.m.) Review request for Plasma. Repository: plasma-workspace Description --- Port QQmlListProperty to QAbstractListModel. QQmlListProperty only has a signal that the list has changed.This means when used in a ListView every delegate has to be redone whenever a single item is inserted or removed rather than just moved. Given TaskDelegate is not the simplest of things this has a performance gain, most noticeably on startup. Also rather than sorting all items after an insert items are inserted in the right place using qLowerBound. Now we have the correct signals we can remove the compression, they won't add anything. Other commits: Avoid constructing a QString for comparing, use QLatin1String for == operators. Remove useless include Do not construct a map inside a lessThan function lessThan functions have to be fast. Also Map - Hash as we're not using order here. Diffs - applets/systemtray/package/contents/ui/CompactRepresentation.qml 01308e7 applets/systemtray/package/contents/ui/ExpandedRepresentation.qml 646b908 applets/systemtray/package/contents/ui/PlasmoidItem.qml 0eb1687 applets/systemtray/package/contents/ui/StatusNotifierItem.qml fc889a8 applets/systemtray/package/contents/ui/TaskDelegate.qml 913d8f1 applets/systemtray/package/contents/ui/TaskListDelegate.qml 5501e02 applets/systemtray/package/contents/ui/main.qml d1a6851 applets/systemtray/plugin/CMakeLists.txt f6e23b4 applets/systemtray/plugin/host.h 02c5bbe applets/systemtray/plugin/host.cpp eafd0b6 applets/systemtray/plugin/task.h 68dcd12 applets/systemtray/plugin/task.cpp 1f8e3ca applets/systemtray/plugin/tasklistmodel.h PRE-CREATION applets/systemtray/plugin/tasklistmodel.cpp PRE-CREATION Diff: https://git.reviewboard.kde.org/r/117813/diff/ Testing --- Seems to work :) see branch davidedmundson/faster_systray to test Thanks, David Edmundson ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Minutes Monday Plasma hangout
Ivan: - Resource linking is almost back. A few kinks to work out. Will be merged after the first release of kf5. Cheerio, Ivan p.s. I'm not properly online to join in the hangout :/ ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 117839: [kglobalaccel] Update X11 appTime from key press events
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117839/#review57298 --- maybe add kdeframeworks group? - Marco Martin On April 28, 2014, 1:47 p.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117839/ --- (Updated April 28, 2014, 1:47 p.m.) Review request for Plasma. Repository: plasma-workspace Description --- [kglobalaccel] Update X11 appTime from key press events KGlobalAccelD sends the current appTime through DBus to the application and KF5::GlobalAccel updates the appTime from the timestamp. This is needed for following actions to succeed. E.g. KWin needs the updated appTime for grabbing the keyboard following the kill window shortcut. To get the current timestamp we just use the timestamp of the key press event delivered to kglobalacceld. Diffs - kglobalaccel/kglobalaccel_x11.cpp 454c62e17ac0fb188bbbf2bcefcf42241d7f4ec1 Diff: https://git.reviewboard.kde.org/r/117839/diff/ Testing --- Tested with ctrl+alt+esc Thanks, Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Minutes Monday Plasma hangout
On Monday, May 05, 2014 12:30:15 Ivan Čukić wrote: Ivan: - Resource linking is almost back. A few kinks to work out. Will be merged after the first release of kf5. Cheerio, Ivan p.s. I'm not properly online to join in the hangout :/ Thanks for prenatal and proactive hijacking of this thread! Here goes the rest: Plasma Meeting 05-05-2015 Present: David, Jens, Marco, Martin G., Martin K., Sebastian, Aleix, Alex, Jens: - The mythical Andrew has done mythical work on windecos, in a branch in kde:breeze - Work on icon theme starts, we'd like it packaged so it can be tested easily - Some communication strategy around branding and user feedback - Worked on OSD icons together with Martin Klapetek Marco: - Breeze repo is up, receiving artwork-related work (cursor theme already in there, QML style coming up, Arorae style coming up) - New splash screen is merged - Working on bugfixes - More work on Plasma::Dialog improvements Aleix: - Started working on port of libkscreen patches for Plasma (Qt API is lacking for screen management) Alex: - Ported libkscreen to XCB, to continue this week - Works on Solid::PowerManagement (release blocker for frameworks) - Tracking down crash in favicon kded Martin Grässlin: - Mouse interaction with Arorae theme is fixed - XCB porting in kwin - Audited screenlocker code, worked on some simplification and unit tests - Fixed crasher in windowthumbnails - Discovered problems in Kwin and Plasma localization (to be discussed on mailinglist) - Important fix to kglobalaccel needs review: https://git.reviewboard.kde.org/r/117839/ Martin Klapetek: - Finished notifications patch for memory usage improvement - investigated bug with new panels overlapping - Panel struts patch coming up David: - Worked on various bugfixes and SDDM improvements - Working on SDDM - work on not running too much stuff as root - SDDM and lockscreen theme - QtQuickControls layout improvements Sebastian: - Fixed up fontinst KCM, font installation and deinstallation now worked in my tests (port was incomplete) - Worked on resizing Plasma panel popups: basically works, few bugs (also uncovers bad minimum- vs. preferred sizes, fixing those as well - Will also work on Kickoff bugs -- 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
Re: Fwd: [kconfig] src/core: Store app config file in ~/.config/domain/apprc
On Monday, May 05, 2014 11:13:31 Marco Martin wrote: On Sunday 04 May 2014, David Faure wrote: please note this change in KConfig. I would recommend making sure your applications call app.setOrganizationDomain(kde.org) so that the config files go into the right subdir right now. Otherwise you'll face migration issues later when setting that. In plasma 3 config files are used, plasmarc, plasma_shellrc, plasma-shellname- appletsrc (like plasma-org.kde.desktop-appletsrc) And kickoffrc. This is fairly isolated in the codebase, though. if David's patch goes in, I'll put it on my list to change. -- 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
Re: Review Request 117839: [kglobalaccel] Update X11 appTime from key press events
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117839/#review57299 --- Ship it! Code looks good. - Àlex Fiestas On April 28, 2014, 1:47 p.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117839/ --- (Updated April 28, 2014, 1:47 p.m.) Review request for Plasma. Repository: plasma-workspace Description --- [kglobalaccel] Update X11 appTime from key press events KGlobalAccelD sends the current appTime through DBus to the application and KF5::GlobalAccel updates the appTime from the timestamp. This is needed for following actions to succeed. E.g. KWin needs the updated appTime for grabbing the keyboard following the kill window shortcut. To get the current timestamp we just use the timestamp of the key press event delivered to kglobalacceld. Diffs - kglobalaccel/kglobalaccel_x11.cpp 454c62e17ac0fb188bbbf2bcefcf42241d7f4ec1 Diff: https://git.reviewboard.kde.org/r/117839/diff/ Testing --- Tested with ctrl+alt+esc Thanks, Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Breeze repo
On Monday 05 May 2014, Andrew Lake wrote: - Window Decoration: I added the newly implemented Aurorae QML window decoration and the current Aurorae SVG theme (which has a some buttons missing for now). I am seeing a qml folder with the actual aurorae decoration and an svg folder with graphics, but no cmake to install it. shouldn't be in the same package as the qml files? -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request 117995: [screenlocker] Add a unit test for KSldApp
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117995/ --- Review request for Plasma and David Edmundson. Repository: plasma-workspace Description --- [screenlocker] Add a unit test for KSldApp The unit test so far only tests establishGrab. This is a little bit tricky as we need a different X Client which grabs pointer or keyboard to make establishGrab fail. For that two small helper applications are included which do nothing else than connecting to X and the one grabbing keyboard the other grabbing pointer. The applications are started from the test to get the keyboard/pointer grabbed which results in ::establishGrab to return false. What this test is not yet able to test is handling the sleep between two grab attemps. Diffs - ksmserver/screenlocker/autotests/CMakeLists.txt ff95d9d031cdac32085e358e30b95a9e9a6fb7dc ksmserver/screenlocker/autotests/keyboardgrabber.cpp PRE-CREATION ksmserver/screenlocker/autotests/ksldtest.cpp PRE-CREATION ksmserver/screenlocker/autotests/pointergrabber.cpp PRE-CREATION ksmserver/screenlocker/ksldapp.h 958b55c1ff83e21d57e3c1dfb812016f325046be Diff: https://git.reviewboard.kde.org/r/117995/diff/ Testing --- Thanks, Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Breeze repo
On May 5, 2014 4:32 AM, Marco Martin wrote: On Monday 05 May 2014, Andrew Lake wrote: - Window Decoration: I added the newly implemented Aurorae QML window decoration and the current Aurorae SVG theme (which has a some buttons missing for now). I am seeing a qml folder with the actual aurorae decoration and an svg folder with graphics, but no cmake to install it. shouldn't be in the same package as the qml files? No, actually those are two separate Auroras themes. One is the new QML-based theme - no svg, no C++. One is the old-style svg based theme we've been using on Plasma Current for quick validation. For Plasma Next the QML-based one is the target and is the most complete one right now. Hope this helps, Andrew ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 112208: KMix qml applet
On March 22, 2014, 11:09 p.m., Mark Gaiser wrote: Is there still an intention on getting this in KDE 4.xx? Just wondering since it seems to be much better then the current kmix popup. Christian Esken wrote: I also haven't heard about further development here. Diego as original submitter or somebody else would have to push this. I added this as a topic for the KDE Multimedia Sprint. It takes place in about 4 months (August 2014): https://sprints.kde.org/sprint/212 Diego Casella wrote: My bad, sorry guys but I'm still in a busy period of my life :/ I'll try to fix the remaining issues pointed out in this review request, and then submit the changes here. There is still an ongoing (and BIG imho) issue anyway: we really really really need a Plasma QML callback to capture mouse scroll events. AFAIK there still isn't in both Plasma 4.13 and also Plasma Next. And talking about kmix applet, one feature everyone is using is the ability to adjust volume level with just few mouse scrolls over the applet icon. I think we need to fix this problem as well, what do you think? Christian Esken wrote: Yes, most definitely we should have mouse scroll events. I guess everybody is using it on the tray icon and in the main window, and so it should also be there for the applet. But if users can choose the plasmoid as an optional, then this is not a showstopper. It is probably better to get it started as is. We could mark it early-access, so interested people can start playing around with it and using it. Mark Gaiser wrote: Quote: There is still an ongoing (and BIG imho) issue anyway: we really really really need a Plasma QML callback to capture mouse scroll events Seriously? I never ever used the scrolling on the tray icon itself. I didn't even know it was possible till you said it in this post. But please don't let such a minor issue block your progress :) Clicking the icon or using the media keys on most keyboards is probably enough possibilities for people change the volume. Scrolling on the icon is imho just bonus stuff. Martin Klapetek wrote: Clicking the icon or using the media keys on most keyboards is probably enough possibilities for people change the volume. Scrolling on the icon is imho just bonus stuff. I use it extensively and every new user I put on Plasma, that's one of the first things I teach them. It's much more convenient because ~80% of the time you're holding your mouse in your hand and ~95% of the time you have your eyes on the screen. Going for keyboard button means in many cases taking your eyes off the screen and looking at the exact button position, often you even have to let the mouse go and move your hand to keyboard (for example YouTube video/any other media being too loud). Mark Gaiser wrote: But you can do it all with your mouse. 1. Click the icon 2. move your cursor to the stream (or master channel). 3. scroll... Just to be sure, scrolling (as i described in the steps above) works in this proposed component, right? All that's not working is scrolling on the tray icon, correct? Note: I happen to have a keyboard without media keys. I always click the icon and scroll on the stream where i want to change the sound level. Martin Klapetek wrote: Sure you can, it's just way easier to simply scroll on an icon than opening this - http://i.imgur.com/LcyFzq6.png and identifying the channel you need to change (the assumption being that you want to change only the main volume, not per stream controls). That way you're doing the visual identification twice - first locating the systray icon, click, now locating the proper handle. So doing it that way is mentally harder task than simply scroll the icon, which also saves you a click ;) Diego Casella wrote: @Mark Gaiser: volume change on scroll is a very, very, handy and smart feature (Martin's answer sums up everything nicely): it would be a pity if we lose it because of a lack in the Plasma QML bindings. By the way, an other plasma applet which uses such feature is, for example, the clock applet: it uses mouse scrolls to loop between timezones (if selected by the user), which is handy for example to check the UTC time before an IRC meeting ;) Besides, you're the first person who _wasn't_ aware of that feature :P As last resort, if we can't come up with a proper solution to whether add this feature back or not, I could blog about it and open a poll to planetkde readers, in order to collect as much feedbacks as possible, what do you think? Mark Gaiser wrote: Quote: By the way, an other plasma applet which uses such feature is, for example, the clock applet: it uses mouse scrolls to loop between timezones (if selected by the user), which is handy for example to check the UTC time before
i18n in Plasma [Was Re: Minutes Monday Plasma hangout]
On Monday 05 May 2014 13:10:44 Sebastian Kügler wrote: - Discovered problems in Kwin and Plasma localization (to be discussed on mailinglist) ok, so with frameworks i18n changed a bit. I highly recommend to read the documentation in [1]. Things to be done are: * set KLocalizedString::setApplicationDomain [2] in the application, never in libs * for libraries (this includes plugins!) set in CMakeLists.txt: add_definitions(-DTRANSLATION_DOMAIN=\nameofcatalog\) for an example see [3] * for ui files one needs to use ki18n_wrap_ui - for an example also see [3] * ensure that every component has Messages.sh Things I do not know yet: * how to handle qml, this also needs the translation domain, but no idea how to set it. * how to handle ui files which are loaded at runtime * how to test an application with translations After adjusting KWin I have a bad feeling that we have to audit all components for i18n usage. Everything will need adjustments, especially the plugins. Though this should be said: it's way simpler and more intuitive than it used to be in kde4. Cheers Martin [1] http://api.kde.org/frameworks-api/frameworks5-apidocs/ki18n/html/prg_guide.html [2] http://api.kde.org/frameworks-api/frameworks5-apidocs/ki18n/html/classKLocalizedString.html#ad866b11bf396b9d93b7dc313a1930b7b [3] http://commits.kde.org/kwin/1c2f27945c8c50612a75cec6cb773a710b6fad15 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 117839: [kglobalaccel] Update X11 appTime from key press events
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117839/#review57310 --- This review has been submitted with commit 54287c8e37679d21a4b1ac34f51e0f9627f9834f by Martin Gräßlin to branch master. - Commit Hook On April 28, 2014, 1:47 p.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117839/ --- (Updated April 28, 2014, 1:47 p.m.) Review request for Plasma. Repository: plasma-workspace Description --- [kglobalaccel] Update X11 appTime from key press events KGlobalAccelD sends the current appTime through DBus to the application and KF5::GlobalAccel updates the appTime from the timestamp. This is needed for following actions to succeed. E.g. KWin needs the updated appTime for grabbing the keyboard following the kill window shortcut. To get the current timestamp we just use the timestamp of the key press event delivered to kglobalacceld. Diffs - kglobalaccel/kglobalaccel_x11.cpp 454c62e17ac0fb188bbbf2bcefcf42241d7f4ec1 Diff: https://git.reviewboard.kde.org/r/117839/diff/ Testing --- Tested with ctrl+alt+esc Thanks, Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Breeze repo
On Monday 05 May 2014, Andrew Lake wrote: On May 5, 2014 4:32 AM, Marco Martin wrote: On Monday 05 May 2014, Andrew Lake wrote: - Window Decoration: I added the newly implemented Aurorae QML window decoration and the current Aurorae SVG theme (which has a some buttons missing for now). I am seeing a qml folder with the actual aurorae decoration and an svg folder with graphics, but no cmake to install it. shouldn't be in the same package as the qml files? No, actually those are two separate Auroras themes. One is the new QML-based theme - no svg, no C++. One is the old-style svg based theme we've been using on Plasma Current for quick validation. For Plasma Next the QML-based one is the target and is the most complete one right now. Hope this helps, Andrew ok, so now everything is installed by the toplevel cmake, hopefully in the proper place. one thing i see, the qt5 version of qtcurve doesn't have the configuration ui ported, so there is no obvious way to load the breeze preset (kde4 systemsettings has to be used) also i see even in the qt5 port there are still quite some kde4-isms -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 117894: Add a kscreenlocker_test test application
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117894/#review57311 --- Ship it! Ship It! - David Edmundson On April 30, 2014, 9:44 a.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117894/ --- (Updated April 30, 2014, 9:44 a.m.) Review request for Plasma, David Edmundson and Wolfgang Bauer. Repository: plasma-workspace Description --- Add a kscreenlocker_test test application The idea is to have a small test application for the screenlocker part to test without having to restart ksmserver. Diffs - ksmserver/screenlocker/CMakeLists.txt 700cdff95f46125952ab2503bb125c5b6cd3ce67 ksmserver/screenlocker/tests/CMakeLists.txt PRE-CREATION ksmserver/screenlocker/tests/kscreenlocker_main.cpp PRE-CREATION Diff: https://git.reviewboard.kde.org/r/117894/diff/ Testing --- Thanks, Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Breeze repo
On May 5, 2014 5:55 AM, Marco Martin wrote: ok, so now everything is installed by the toplevel cmake, hopefully in the proper place. Yay, thanks! One thing I noticed, does the top level cmake include the Breeze color scheme? Both the controls style and the QML windec use the system color scheme, so the visuals won't be quite complete without it. Thanks again Marco! Andrew ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Breeze repo
On Monday 05 May 2014, Andrew Lake wrote: Yay, thanks! One thing I noticed, does the top level cmake include the Breeze color scheme? Both the controls style and the QML windec use the system color gah, forgot it. now should be ok :) -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 117894: Add a kscreenlocker_test test application
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117894/#review57312 --- This review has been submitted with commit b762c3732bccc265fe24c57f6bda41b237324635 by Martin Gräßlin to branch master. - Commit Hook On April 30, 2014, 9:44 a.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117894/ --- (Updated April 30, 2014, 9:44 a.m.) Review request for Plasma, David Edmundson and Wolfgang Bauer. Repository: plasma-workspace Description --- Add a kscreenlocker_test test application The idea is to have a small test application for the screenlocker part to test without having to restart ksmserver. Diffs - ksmserver/screenlocker/CMakeLists.txt 700cdff95f46125952ab2503bb125c5b6cd3ce67 ksmserver/screenlocker/tests/CMakeLists.txt PRE-CREATION ksmserver/screenlocker/tests/kscreenlocker_main.cpp PRE-CREATION Diff: https://git.reviewboard.kde.org/r/117894/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 117894: Add a kscreenlocker_test test application
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117894/ --- (Updated May 5, 2014, 1:19 p.m.) Status -- This change has been marked as submitted. Review request for Plasma, David Edmundson and Wolfgang Bauer. Repository: plasma-workspace Description --- Add a kscreenlocker_test test application The idea is to have a small test application for the screenlocker part to test without having to restart ksmserver. Diffs - ksmserver/screenlocker/CMakeLists.txt 700cdff95f46125952ab2503bb125c5b6cd3ce67 ksmserver/screenlocker/tests/CMakeLists.txt PRE-CREATION ksmserver/screenlocker/tests/kscreenlocker_main.cpp PRE-CREATION Diff: https://git.reviewboard.kde.org/r/117894/diff/ Testing --- Thanks, Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Breeze repo
On Mon, May 5, 2014 at 7:43 AM, Andrew Lake jamboar...@gmail.com wrote: I went ahead and added a 'working' branch and added the following: - Colors: This is the Breeze color scheme that has the both the style and the window decoration colors. I think this is releasable, so if there are no objections I'd like to move this over 'master' so it can ship in the june release, hopefully as the default color scheme. - Widget Style: I added the QtQuickControlsStyle that we recently completed and the QtCurve settings file. - Window Decoration: I added the newly implemented Aurorae QML window decoration and the current Aurorae SVG theme (which has a some buttons missing for now). My cmake foo is weak, so I may need some help to get some of these installed in the right locations. I might also need a little help getting a measure of goodenough(tm) that's appropriate for shipping in June as *optional*. i.e. installed but not default. I think the widget styles and the QML windec *might* be goodenough(tm) in that sense but I'm a little uncertain what I might not be thinking of. :-) Hope this helps, Andrew On Tue, Apr 29, 2014 at 3:32 AM, Marco Martin notm...@gmail.com wrote: On Monday 28 April 2014 16:16:03 you wrote: So, following the discussion last week, i made a scratch called breeze here: http://quickgit.kde.org/?p=scratch%2Fmart%2Fbreeze.git that at the moment has only the cursor theme. and opened a sysadmin ticket for the final repository location at kde/workspace/breeze.git Aaaan, is done https://projects.kde.org/projects/kde/workspace/breeze right now it just contains the cursor theme (i would put also the temporary wallpaper we have in it) Andrew: I've put you as admin of the repo as well. People are encouraged to move in things that are in topic with it. only thing to pay attention, (I'm thinking about the kwin theme and possibly the qml style) since we are so near to the release, only things that we are sure that end up releasable for june should go in master. what is still not sure, please put it in a branch, eventually merging it in master when goodenough (tm) ;) -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel Wouldn't it be better to have a branch for each? Otherwise you'll have to merge them to master all at once. Also, I wanted to test it and so it's missing some CMake to get things installed. Do you need help with this? Aleix ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Plasma 5?
Hi all, I am not happy with the 2014.6 name and naming scheme. There I said it. The reasons for this are multi-fold. First, and to me most importantly: It feels awkward. Now that might be because it's new, but it also feels like no one else is going to understand it. My thinking goes towards an option that we had briefly discussed, and I think dismissed too quickly, and for the wrong reasons. So, I'd like to get some feedback on the proposal to call the new Plasma release Plasma 5.0, and use the old version numbering scheme going forwards. That means after 5.0 comes 5.1, 5.2, and so on, same for minor releases (however that is going to end up being decided). This feedback can then be taken up with the promo and marketing department, I think that we should first make up our own minds (for that reason, no cross-post to kde-promo at this point). The baseline, to use Plasma as the brand, and only refer to the version as a technicality should of course stay the same. Why do I think 5 is better than 2014.6, or year.month of release? - It communicates continuity: Plasma Next really is the continuation of 15+ years of doing a desktop. It has our DNA all over it, and it's not a disconnected today's thing. Especially to our existing userbase, and those just outside of it (other people known to Free desktops), this has a real meaning. It's something people love, and sometimes hate, and it's not a completely new thing. This is well in line with what we've been talking about all along for Plasma Next. - It's trusted and proven: it works and will cause no problems with packaging, and comparing version number - It solves a bunch of technical inconsistencies (plasmapkg2 vs kcmshell5 -- why has one the 2 appended, the other 5?), library sonames are 5 as well. - It indicates (like we did traditionally) that this is the 5th major version, building on a new Qt5, and Frameworks 5, we get to re-use that kind of consistency. - To me, it feels just right. I know many others feel that 2014.6 is bad, and I've yet to hear somebody that really likes it (might be my limitation of course). Now one of the reasons to not go for Plasma 5 was that people would say that's KDE5, and we don't want that. To be honest, I stopped caring about that, if people want to call it KDE5, so be it, we'll call it Plasma 5 and do that consistently, as long as people understand what's talked about -- cool. We won't convince people to stop calling it KDE 5 by introducing an awkward versioning scheme, but we can do that by properly adjusting our communication towards that. The distinction between Platform, Workspaces and Applications is more clear with our separated release cycles anyway, and perception of that will just make this topic easier. Take to kde-promo for further discussion -- 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
Re: Breeze QML window decoration
On Sunday 04 May 2014 22:28:23 Andrew Lake wrote: Based on the design we came up with in the VDG forum, I completed a first go at doing up a Aurorae QML window decoration. I added it to the 'working' branch of the Breeze repo. As far as I can tell it works about as well as the Plastik QML decoration. some feedback after running the deco for most of today: * in maximized state there is still a round corner in top left and top right * I experience a slight flicker when mouse over buttons * there's a config dialog (which looks like forked from Plastik) which is not updated in the deco? Maybe remove? * Changing button sizes has no effect - this is important for accessibility 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: Plasma 5?
On Monday, May 05, 2014 15:55:27 Sebastian Kügler wrote: Hi all, I am not happy with the 2014.6 name and naming scheme. There I said it. The reasons for this are multi-fold. First, and to me most importantly: It feels awkward. Now that might be because it's new, but it also feels like no one else is going to understand it. My thinking goes towards an option that we had briefly discussed, and I think dismissed too quickly, and for the wrong reasons. So, I'd like to get some feedback on the proposal to call the new Plasma release Plasma 5.0, and use the old version numbering scheme going forwards. That means after 5.0 comes 5.1, 5.2, and so on, same for minor releases (however that is going to end up being decided). This feedback can then be taken up with the promo and marketing department, I think that we should first make up our own minds (for that reason, no cross-post to kde-promo at this point). The baseline, to use Plasma as the brand, and only refer to the version as a technicality should of course stay the same. Why do I think 5 is better than 2014.6, or year.month of release? - It communicates continuity: Plasma Next really is the continuation of 15+ years of doing a desktop. It has our DNA all over it, and it's not a disconnected today's thing. Especially to our existing userbase, and those just outside of it (other people known to Free desktops), this has a real meaning. It's something people love, and sometimes hate, and it's not a completely new thing. This is well in line with what we've been talking about all along for Plasma Next. - It's trusted and proven: it works and will cause no problems with packaging, and comparing version number - It solves a bunch of technical inconsistencies (plasmapkg2 vs kcmshell5 -- why has one the 2 appended, the other 5?), library sonames are 5 as well. - It indicates (like we did traditionally) that this is the 5th major version, building on a new Qt5, and Frameworks 5, we get to re-use that kind of consistency. - To me, it feels just right. I know many others feel that 2014.6 is bad, and I've yet to hear somebody that really likes it (might be my limitation of course). Now one of the reasons to not go for Plasma 5 was that people would say that's KDE5, and we don't want that. To be honest, I stopped caring about that, if people want to call it KDE5, so be it, we'll call it Plasma 5 and do that consistently, as long as people understand what's talked about -- cool. We won't convince people to stop calling it KDE 5 by introducing an awkward versioning scheme, but we can do that by properly adjusting our communication towards that. The distinction between Platform, Workspaces and Applications is more clear with our separated release cycles anyway, and perception of that will just make this topic easier. Take to kde-promo for further discussion A big +1 to all of the above. To me going with 2014.6 always felt like a compromise that few (if any) really like... IMO year.month doesn't add anything valuable in terms of branding, and it suggests a loss of continuity at a time where we should be comunicating that this is not a revolutionary change like KDE3-4. Cheers, -- Teo Mrnjavac http://teom.org | t...@kde.org ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [plasma-devel] Plasma 5?
Plasma 5 certainly makes it a lot easier to name betas. It also means if the release date slips there's no need for a quick reversion. Frameworks want an extra beta so it may well slip. Jonathan ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma 5?
On Mon, May 5, 2014 at 4:59 PM, Mark Gaiser mark...@gmail.com wrote: I do wonder though, why didn't you folks decide this on the plasma sprint earlier this year? We did. That's where the original proposal came from. Cheers -- Martin Klapetek | KDE Developer ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma 5?
On Monday 05 May 2014, Sebastian Kügler wrote: The baseline, to use Plasma as the brand, and only refer to the version as a technicality should of course stay the same. Why do I think 5 is better than 2014.6, or year.month of release? After trying (with not much success) to use publicly the next/2014.06 scheme, I have to agree that I would feel more confortable with either Plasma 5 or Plasma 2 To me either of which wouldn't make much difference, it's true tough that looks less confusing if it has the same number as frameworks and Qt -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma 5?
+1 And, its easier to say as well :) On Mon, May 5, 2014 at 8:51 PM, Marco Martin notm...@gmail.com wrote: On Monday 05 May 2014, Sebastian Kügler wrote: The baseline, to use Plasma as the brand, and only refer to the version as a technicality should of course stay the same. Why do I think 5 is better than 2014.6, or year.month of release? After trying (with not much success) to use publicly the next/2014.06 scheme, I have to agree that I would feel more confortable with either Plasma 5 or Plasma 2 To me either of which wouldn't make much difference, it's true tough that looks less confusing if it has the same number as frameworks and Qt -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel -- Shantanu Tushar(UTC +0530) http://www.shantanutushar.com ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma 5?
Personally (and I've said this before) from my point of view a name is either a) a technical definition b) a form of promotion As for technical reasoning behind either name - I have little or no opinion. This is not my field to piss in as it where. BUT for the usage of promo work the best option is to simply go with Plasma by KDE (which opens the wonderful opportunity to do a spoof of the by Calvin Klein perfume ads (but with devs on a beach)) Then if the proper answer to the question So what version am I running? is Plasma 2, Plasma 5, Plasma Current or Plasma 2014.06 is less relevant as long as there is one. With a 5 we can do some things too, the two as well... actually from a communicative standpoint I think we can do something with all ... Anyway I am all thumbs and a smile to whatever you guys decide as long as using Plasma is ok. (oh and lets remember that confused user isn't always bad. If its an annoying thing, something that makes you angry - then yes its bad. If its something that makes you ask in a public forum Oh so thats like what Plasma 5? Or Next? its good since it will make more of a splash - as long as the answer is accessible we're fine) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma 5?
Jens: the best option is to simply go with Plasma by KDE and So what version am I running? is Plasma 2, Plasma 5, +1 I don't mind the version 5.x (though, I didn't mind any of the proposals) Wondering what is Martin's stance on this since the year.month was his child. Cheers ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Breeze QML window decoration
On Mon, May 5, 2014 at 6:54 AM, Martin Gräßlin wrote: some feedback after running the deco for most of today: * in maximized state there is still a round corner in top left and top right * I experience a slight flicker when mouse over buttons * there's a config dialog (which looks like forked from Plastik) which is not updated in the deco? Maybe remove? * Changing button sizes has no effect - this is important for accessibility Awesome, thanks for the feedback Martin. Hope it's working mostly ok otherwise. I'll be sure to take a look at this stuff over the next day or two. Obviously, if anyone else finds solutions before I get to them feel free to share them. Much respect, Andrew ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Multi-screen on Plasma Shell
Hi, As some of you know, I've been trying to polish the plasma shell usage on two screens. It's a use-case I hit a lot given that I have 2 screens both in the office and at home and I think it's really important to be on par with Plasma 1 on this area, at least, especially if we want to be appealing in the desktop world. When I started to work on it, I got stuck when I wanted to figure out the primary screens management [1]. It works well, but then there's important API missing, so I decided to give a try to libkscreen. The reason behind it is that I do believe that Qt's API should be fixed, but then I would like Plasma Next to start shipping with an acceptable support of multiple screens. My first approach can be found in the plasmashell+libkscreen branch. I've been testing it locally and it works quite well, it seems to do what we want it to do and I'm committing to the approach. Since it's a rather big change and it involves a new dependency, I decided to send this e-mail first and ask for comments. If nobody is against it I will merge it to master in a couple of days. Cheers! Aleix [1] https://bugreports.qt-project.org/browse/QTBUG-38404 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma 5?
Well to be honest the same can be said of Plasma 2014.5 - I mean as long as that name is kept as a form of technical definer and never ever near marketing and promo work. (So Ivan, no dancing on a beach in black and white while a voice whispers between beauty and desire, between 1337 and n00b lies ... Plasma... by KDE in my ...by Calvin Kline spoof? ;) ) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma 5?
I meant +1 for Plasma by KDE, and when someone wants the version, he can say KDE^WPlasma 5 :) On 5 May 2014 19:04, Jens Reuterberg j...@ohyran.se wrote: Well to be honest the same can be said of Plasma 2014.5 - I mean as long as that name is kept as a form of technical definer and never ever near marketing and promo work. (So Ivan, no dancing on a beach in black and white while a voice whispers between beauty and desire, between 1337 and n00b lies ... Plasma... by KDE in my ...by Calvin Kline spoof? ;) ) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel -- Cheerio, Ivan -- While you were hanging yourself on someone else's words Dying to believe in what you heard I was staring straight into the shining sun ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Multi-screen on Plasma Shell
I wanted to test it out a bit as I have a multi-screen setup too, but plasma-shell crashes on startup for me - backtrace - http://paste.kde.org/pscwpjjnp Also as I mentioned earlier, please run astyle on it before merging to have a consistent coding style in the files. Please don't ignore that. Cheers -- Martin Klapetek | KDE Developer ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma 5?
On Mon, May 5, 2014 at 7:25 PM, Martin Graesslin mgraess...@kde.org wrote: On Monday 05 May 2014 17:56:04 Ivan Čukić wrote: Jens: the best option is to simply go with Plasma by KDE and So what version am I running? is Plasma 2, Plasma 5, +1 I don't mind the version 5.x (though, I didn't mind any of the proposals) Wondering what is Martin's stance on this since the year.month was his child. oh well, as I'm addressed I'm going to answer. As it's well known I dislike the 5 for two reasons: 1. It will end in Plasma == KDE. sebas's point to that is that he doesn't care, I understand that, but on the other hand I think it's a lost opportunity. 2. I'm afraid of people discarding the version because of fear of repeating 4.0. If the version number is turned into a pure technical thing and never ever mentioned any where in the promo, I think it can work. But that also requires that media is informed why we don't want to have the technical version to be prominent. Otherwise we will have KDE 5.0 released - which I just don't want to see happen. Now what about the year.month scheme: in my opinion version numbers don't carry any information but people try to interpret information into it, which can only fail. Thus I would like to move away from a version number scheme which allows to interpret. The year.month scheme carries one explicit information: the age the software has. In a year it's not possible to know how old 5.3 or 5.0 is. With 2015.04 and 2014.06 this is obvious. Why do I think it is important to have this information? Because we see quite often that distros ship outdated versions and that users get upset when we tell them that what they use is outdated. With such a version number they would be able to see this themselves and maybe even start to look for a newer version, kick the distros a** or whatever ;-) In the end I don't care what will be decided. This has been brought up too often for me to care about. I don't want to see a 5 in any public communication, also not in our blog posts. If it's internal, it's fine, but please no 5 in public communication. I would be way happier with 2 which I think is the logical successor to Plasma 1, but I understand sebas's argumentation for the 5. Cheers Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel Regarding 1), put it as you wish, but in the end it's KDE 5 without applications. Aleix ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 108992: Simple optimizations in SignalPlotter
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/108992/ --- (Updated May 5, 2014, 10:54 p.m.) Status -- This change has been discarded. Review request for Plasma. Repository: kdelibs Description --- - create variables and classes outside the loops - reserve space in QList if we know already how many items will be added (avoid unnecessary reallocations) - use const_iterator when possible - remove a useless call (p-setPen(Qt::NoPen) - it will be set latter before be used) - avoid multiplications (x3, x2, x1 and x0) Diffs - plasma/widgets/signalplotter.cpp 8e9e294 Diff: https://git.reviewboard.kde.org/r/108992/diff/ Testing --- I have tested with KDE 4.10 with no problems. I have seen a improvement of about 5% in drawPlots() function, the most expensive function in painting. Thanks, Raul Fernandes ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
