Re: Review Request 123836: Ensure KNotification can be used from a non-GUI thread
On May 18, 2015, 4:15 p.m., Aleix Pol Gonzalez wrote: This fixes my boot. I wasn't able to boot for the whole day because it was showing a QWidget from the wrong thread. On a related note, let's port away from QDesktopWidget, it has these things... Ok, QScreen then? - Martin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123836/#review80575 --- On May 18, 2015, 2:13 p.m., Martin Klapetek wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123836/ --- (Updated May 18, 2015, 2:13 p.m.) Review request for KDE Frameworks and Plasma. Repository: knotifications Description --- The NotifyByPopup plugin is accessing QApplication::desktop() in constructor which Qt does not like when that happens on non-GUI thread and asserts. So this moves that code only when actually needed plus it checks first if the code is run in non-GUI thread and does nothing if it's not. This is only for the popup fallback notifications, normal notifications work just fine. Diffs - src/notifybypopup.cpp 2f84ab0 Diff: https://git.reviewboard.kde.org/r/123836/diff/ Testing --- Tested with both multi-threaded and single-threaded codes. Thanks, Martin Klapetek ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 123836: Ensure KNotification can be used from a non-GUI thread
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123836/ --- (Updated May 18, 2015, 3:34 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and Plasma. Changes --- Submitted with commit bbf19c13ee61fe0f09263d2fdd40207a71dca6fd by Martin Klapetek to branch master. Repository: knotifications Description --- The NotifyByPopup plugin is accessing QApplication::desktop() in constructor which Qt does not like when that happens on non-GUI thread and asserts. So this moves that code only when actually needed plus it checks first if the code is run in non-GUI thread and does nothing if it's not. This is only for the popup fallback notifications, normal notifications work just fine. Diffs - src/notifybypopup.cpp 2f84ab0 Diff: https://git.reviewboard.kde.org/r/123836/diff/ Testing --- Tested with both multi-threaded and single-threaded codes. Thanks, Martin Klapetek ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 123836: Ensure KNotification can be used from a non-GUI thread
On May 18, 2015, 4:15 p.m., Aleix Pol Gonzalez wrote: This fixes my boot. I wasn't able to boot for the whole day because it was showing a QWidget from the wrong thread. On a related note, let's port away from QDesktopWidget, it has these things... Martin Klapetek wrote: Ok, QScreen then? That would work. You can do notification-widget()-screen()-geometry()-top(). - Aleix --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123836/#review80575 --- On May 18, 2015, 2:13 p.m., Martin Klapetek wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123836/ --- (Updated May 18, 2015, 2:13 p.m.) Review request for KDE Frameworks and Plasma. Repository: knotifications Description --- The NotifyByPopup plugin is accessing QApplication::desktop() in constructor which Qt does not like when that happens on non-GUI thread and asserts. So this moves that code only when actually needed plus it checks first if the code is run in non-GUI thread and does nothing if it's not. This is only for the popup fallback notifications, normal notifications work just fine. Diffs - src/notifybypopup.cpp 2f84ab0 Diff: https://git.reviewboard.kde.org/r/123836/diff/ Testing --- Tested with both multi-threaded and single-threaded codes. Thanks, Martin Klapetek ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 123836: Ensure KNotification can be used from a non-GUI thread
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123836/#review80575 --- Ship it! This fixes my boot. I wasn't able to boot for the whole day because it was showing a QWidget from the wrong thread. On a related note, let's port away from QDesktopWidget, it has these things... - Aleix Pol Gonzalez On May 18, 2015, 2:13 p.m., Martin Klapetek wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123836/ --- (Updated May 18, 2015, 2:13 p.m.) Review request for KDE Frameworks and Plasma. Repository: knotifications Description --- The NotifyByPopup plugin is accessing QApplication::desktop() in constructor which Qt does not like when that happens on non-GUI thread and asserts. So this moves that code only when actually needed plus it checks first if the code is run in non-GUI thread and does nothing if it's not. This is only for the popup fallback notifications, normal notifications work just fine. Diffs - src/notifybypopup.cpp 2f84ab0 Diff: https://git.reviewboard.kde.org/r/123836/diff/ Testing --- Tested with both multi-threaded and single-threaded codes. Thanks, Martin Klapetek ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request 123836: Ensure KNotification can be used from a non-GUI thread
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123836/ --- Review request for KDE Frameworks and Plasma. Repository: knotifications Description --- The NotifyByPopup plugin is accessing QApplication::desktop() in constructor which Qt does not like when that happens on non-GUI thread and asserts. So this moves that code only when actually needed plus it checks first if the code is run in non-GUI thread and does nothing if it's not. This is only for the popup fallback notifications, normal notifications work just fine. Diffs - src/notifybypopup.cpp 2f84ab0 Diff: https://git.reviewboard.kde.org/r/123836/diff/ Testing --- Tested with both multi-threaded and single-threaded codes. Thanks, Martin Klapetek ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 123381: Fallback to AttentionIcon for SNI when animations are disabled
On April 16, 2015, 1:43 p.m., Kai Uwe Broulik wrote: I think we should always pulse, and if available, use the needs attention icon (but don't cycle between normal and attention icon) Martin Klapetek wrote: If you don't cycle it's quite easy to miss, so I think there'd be very little point in just switching the icon (the purpose is to get your attention). Martin Klapetek wrote: Ah I misunderstood. The slight problem I see with always using the attention icon for the pulse animation is that they are not necessarily covered by the plasma theme, so when it starts pulsing with attention icon, the icon can look completely different while simply pulsing the normal icon seems more consistent. Dunno. So uhhany comments? - Martin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123381/#review79045 --- On April 16, 2015, 1:23 p.m., Martin Klapetek wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123381/ --- (Updated April 16, 2015, 1:23 p.m.) Review request for Plasma. Repository: plasma-workspace Description --- This returns the kde4 behavior of simply switching the icon for attention icon when animations are disabled. I don't think that always using the attention icon with the pulse animation looks good, it looks like there's too much going on. I believe it should be an either-or. So I did it only as a fallback. Diffs - applets/systemtray/package/contents/ui/StatusNotifierItem.qml 5380b09 applets/systemtray/package/contents/ui/TaskDelegate.qml f2738bd Diff: https://git.reviewboard.kde.org/r/123381/diff/ Testing --- I didn't test with animations off (I'm not sure how to set) so I just explicitly enabled the timer and disabled the PulseAnimation. Works just like in the old times. Thanks, Martin Klapetek ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 122648: Make notifications --reverse aware
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122648/ --- (Updated May 18, 2015, 12:54 p.m.) Status -- This change has been marked as submitted. Review request for Plasma. Changes --- Submitted with commit 7253c12a2b089176d0354c6a3a88b536befb5653 by Martin Klapetek to branch Plasma/5.3. Bugs: 343251 https://bugs.kde.org/show_bug.cgi?id=343251 Repository: plasma-workspace Description --- Now it works with plasmashell --reverse Diffs - applets/notifications/package/contents/ui/NotificationItem.qml 86b0b6e applets/notifications/package/contents/ui/NotificationPopup.qml 6902459 applets/notifications/package/contents/ui/main.qml 1e5efa3 applets/notifications/plugin/notificationshelper.h ca0b63b applets/notifications/plugin/notificationshelper.cpp e7c4e29 Diff: https://git.reviewboard.kde.org/r/122648/diff/ Testing --- Tested both --reverse and not --reverse and both look good. See screenshot. File Attachments --reverse https://git.reviewboard.kde.org/media/uploaded/files/2015/02/20/5058fe12-ecdd-4345-bcec-4392bbfa78f5__notifications-reverse.png Thanks, Martin Klapetek ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 123731: Cleanup handling of notifications closing
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123731/ --- (Updated May 18, 2015, 2:14 p.m.) Review request for KDE Frameworks and Plasma. Changes --- Add plasma Repository: knotifications Description --- While investigating the cause of crash of https://bugs.kde.org/show_bug.cgi?id=342752 I've come across some loose ends in how KNotifications is handling closing of notifications. As for the crash itself, I never managed to reproduce even with special written test cases, but what happens (or seem to) is this: * KNotification object gets deleted * The destructor calls close() on all plugins * The NotifyByPopup plugin does async dbus call to close the notification and returns * KNotification's dpointer is deleted * The DBus reply returns, calling NotifyByPopup::finished() * Now for some reason the KNotification object is still not null but its dpointer is gone, so the check if (!notification || d-notifications.contains(notification-id())) crashes on the notification-id() call So I've made it simply return -1 when dpointer is null, which should ideally prevent the crashes Diffs - src/knotification.cpp 01962b3 src/knotificationmanager.cpp 0d9b3b0 src/knotificationmanager_p.h f8e7df8 src/notifybypopup.cpp 2f84ab0 Diff: https://git.reviewboard.kde.org/r/123731/diff/ Testing --- Thanks, Martin Klapetek ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request 123834: Switch the login sound to Phonon directly...for now
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123834/ --- Review request for Plasma. Repository: plasma-workspace Description --- With its current architecture, KNotification can cause crashes on logout (and also cause asserts in certain situations, that will be another fix). So in the meantime, this replaces the KNotification-in-a-thread with Phonon directly. This is exactly what KNotification would do. This is for the time being until the crash on logout is sorted out. Additionally, this also fixes logout sound which was missing before. This uses normal KNotification as at that point we don't need to be threading or anything, so KNotification is just safe. Diffs - CMakeLists.txt 8ffccad ksmserver/CMakeLists.txt c0543e2 ksmserver/shutdown.cpp 7600c30 ksmserver/startup.cpp f79fd4f Diff: https://git.reviewboard.kde.org/r/123834/diff/ Testing --- Login sound works as expected, logout sound as well. Also tested by couple other people. Thanks, Martin Klapetek ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 123817: Device notifier: Refresh the space indicator every 5 seconds.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123817/#review80566 --- Fwiw, I think it would be much better if the dataengine actually signalled the disk space change rather than polling, then the applet could just handle the incoming changed signals - less polling around. - Martin Klapetek On May 17, 2015, 1:01 p.m., Yoann Laissus wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123817/ --- (Updated May 17, 2015, 1:01 p.m.) Review request for Plasma. Repository: plasma-workspace Description --- Previously, it was set to 0 so the space indicator was never refreshed. Diffs - applets/devicenotifier/package/contents/ui/devicenotifier.qml 1fb3d28736fc5effb7e6a6e5940a7bab28c19798 Diff: https://git.reviewboard.kde.org/r/123817/diff/ Testing --- Thanks, Yoann Laissus ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma 5 is awesome...and some help required with build instructions
Just setting up on a new machine and thought I'd try following these instructions exactly, the way a new developer would. I got stuck on something I don't know how to solve. Under Kubuntu because Qt is compiled with a hardcoded plugindir for some reason. This means setting QT_PLUGIN_PATH env variables does nothing, which means you'll always be loading any plugins from /usr/ rather than the ones we just built. How did you get round that? Any ideas? David ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 123836: Ensure KNotification can be used from a non-GUI thread
On May 18, 2015, 4:15 p.m., Aleix Pol Gonzalez wrote: This fixes my boot. I wasn't able to boot for the whole day because it was showing a QWidget from the wrong thread. On a related note, let's port away from QDesktopWidget, it has these things... Martin Klapetek wrote: Ok, QScreen then? Aleix Pol Gonzalez wrote: That would work. You can do notification-widget()-screen()-geometry()-top(). That wouldn't work because the widget() does not need to be set. So I'll use QScreen directly. - Martin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123836/#review80575 --- On May 18, 2015, 5:34 p.m., Martin Klapetek wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123836/ --- (Updated May 18, 2015, 5:34 p.m.) Review request for KDE Frameworks and Plasma. Repository: knotifications Description --- The NotifyByPopup plugin is accessing QApplication::desktop() in constructor which Qt does not like when that happens on non-GUI thread and asserts. So this moves that code only when actually needed plus it checks first if the code is run in non-GUI thread and does nothing if it's not. This is only for the popup fallback notifications, normal notifications work just fine. Diffs - src/notifybypopup.cpp 2f84ab0 Diff: https://git.reviewboard.kde.org/r/123836/diff/ Testing --- Tested with both multi-threaded and single-threaded codes. Thanks, Martin Klapetek ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 123807: Fix popup menu items getting stray highlighted
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123807/#review80582 --- Ship it! Ship It! - Lukáš Tinkl On Kvě. 16, 2015, 12:39 dop., Albert Astals Cid wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123807/ --- (Updated Kvě. 16, 2015, 12:39 dop.) Review request for Plasma, David Edmundson and Hugo Pereira Da Costa. Bugs: 332377 https://bugs.kde.org/show_bug.cgi?id=332377 Repository: oxygen Description --- Make sure we finish the animation before stopping it. Diffs - kstyle/animations/oxygenmenubardata_imp.h fcfe788 Diff: https://git.reviewboard.kde.org/r/123807/diff/ Testing --- Moved the mouse like crazy over the Help menu of konsole and can't get it to be wrong anymore. Thanks, Albert Astals Cid ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma 5 is awesome...and some help required with build instructions
On Mon, May 18, 2015 at 7:05 PM, Aleix Pol aleix...@kde.org wrote: On Mon, May 18, 2015 at 7:28 PM, David Edmundson da...@davidedmundson.co.uk wrote: Just setting up on a new machine and thought I'd try following these instructions exactly, the way a new developer would. I got stuck on something I don't know how to solve. Under Kubuntu because Qt is compiled with a hardcoded plugindir for some reason. This means setting QT_PLUGIN_PATH env variables does nothing, which means you'll always be loading any plugins from /usr/ rather than the ones we just built. How did you get round that? Any ideas? David ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel On Kubuntu, you probably want to enable KDE_INSTALL_USE_QT_SYS_PATHS cmake option. but that will install to /usr Aleix ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 123783: Adjust showing desktop behavior
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123783/#review80595 --- Ship it! Ship It! - Martin Gräßlin On May 14, 2015, 12:21 a.m., Thomas Lübking wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123783/ --- (Updated May 14, 2015, 12:21 a.m.) Review request for kwin, Plasma, Kai Uwe Broulik, David Edmundson, Martin Gräßlin, Marco Martin, Sebastian Kügler, and Thomas Pfeiffer. Bugs: 346837, 346933 and 347212 https://bugs.kde.org/show_bug.cgi?id=346837 https://bugs.kde.org/show_bug.cgi?id=346933 https://bugs.kde.org/show_bug.cgi?id=347212 Repository: kwin Description --- Errhe... while we're waiting for final comments of the HIG group ;-) Here's a patch that *mostly* restores the 5.2 behavior Notable differences: 1) The minimizability of windows is ignored. It's a cornercase, but the former behavior was a side-effect of the implementation. (At least I don't know a reason to keep them) 2) The state is broken with the *activation* of windows, not them becoming visible. Latter doesn't work for most cases (unminimizing) for obvious reasons (they're not minimized ;-) and when a new window is mapped, the focus stealing prevention seems a good filter (if it's not good enough to gain the focus, it's not good enough to break the state either ;-) 3) Keep above windows remain visible and do not break the state (as if they'd belong to the desktop) for a request by the HIG group. I'm frankly not sure about the background of this behavior (hopefully not krunner - that doesn't work) 4) Windows in the desktop group initially remain above the desktop and can be activated w/ breaking the state, but can also hide behind the desktop (notably when that is clicked/activated) Diffs - activation.cpp fe0a51f client.h 40d503c client.cpp a6fbf3e layers.cpp b6d5b75 manage.cpp 75af4e5 workspace.cpp 09ae9a2 Diff: https://git.reviewboard.kde.org/r/123783/diff/ Testing --- Thanks, Thomas Lübking ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 123783: Adjust showing desktop behavior
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123783/#review80594 --- Plasma workspace 5.3.1 is tagged *Thu 2015-05-21*, 3 days from now. Therefore I'd like to call for vetos until *Tue 2015-05-19*, then pass myself a ship it! to not have this move in in the very last seconds. - Thomas Lübking On Mai 13, 2015, 10:21 nachm., Thomas Lübking wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123783/ --- (Updated Mai 13, 2015, 10:21 nachm.) Review request for kwin, Plasma, Kai Uwe Broulik, David Edmundson, Martin Gräßlin, Marco Martin, Sebastian Kügler, and Thomas Pfeiffer. Bugs: 346837, 346933 and 347212 https://bugs.kde.org/show_bug.cgi?id=346837 https://bugs.kde.org/show_bug.cgi?id=346933 https://bugs.kde.org/show_bug.cgi?id=347212 Repository: kwin Description --- Errhe... while we're waiting for final comments of the HIG group ;-) Here's a patch that *mostly* restores the 5.2 behavior Notable differences: 1) The minimizability of windows is ignored. It's a cornercase, but the former behavior was a side-effect of the implementation. (At least I don't know a reason to keep them) 2) The state is broken with the *activation* of windows, not them becoming visible. Latter doesn't work for most cases (unminimizing) for obvious reasons (they're not minimized ;-) and when a new window is mapped, the focus stealing prevention seems a good filter (if it's not good enough to gain the focus, it's not good enough to break the state either ;-) 3) Keep above windows remain visible and do not break the state (as if they'd belong to the desktop) for a request by the HIG group. I'm frankly not sure about the background of this behavior (hopefully not krunner - that doesn't work) 4) Windows in the desktop group initially remain above the desktop and can be activated w/ breaking the state, but can also hide behind the desktop (notably when that is clicked/activated) Diffs - activation.cpp fe0a51f client.h 40d503c client.cpp a6fbf3e layers.cpp b6d5b75 manage.cpp 75af4e5 workspace.cpp 09ae9a2 Diff: https://git.reviewboard.kde.org/r/123783/diff/ Testing --- Thanks, Thomas Lübking ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma 5 is awesome...and some help required with build instructions
On Mon, May 18, 2015 at 7:28 PM, David Edmundson da...@davidedmundson.co.uk wrote: Just setting up on a new machine and thought I'd try following these instructions exactly, the way a new developer would. I got stuck on something I don't know how to solve. Under Kubuntu because Qt is compiled with a hardcoded plugindir for some reason. This means setting QT_PLUGIN_PATH env variables does nothing, which means you'll always be loading any plugins from /usr/ rather than the ones we just built. How did you get round that? Any ideas? David ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel On Kubuntu, you probably want to enable KDE_INSTALL_USE_QT_SYS_PATHS cmake option. Aleix ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 123735: version of QmlObject with a static engine
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123735/ --- (Updated May 18, 2015, 7:09 p.m.) Review request for KDE Frameworks and Plasma. Repository: kdeclarative Description (updated) --- to make easier doing applications like plasma that use a lot of qml to have a single engine make a subclass of QmlObject called QmlObjectSharedEngine that has a single, static QQmlEngine Adds a class called QuickViewSharedEngine that has the same behavior as QmlObjectSharedEngine(using it): static QQmlEngine, separed rootContexts() for each instance. This is used by desktopviews and panelviews to share their engine. Unfortunately it may not be possible to get the applet configuration dialogs to use this, since they still need a separed engine in order to have a different controls style (qstyle based) than the stuff in the desktop/panel Diffs - src/kdeclarative/CMakeLists.txt d73bff0 src/kdeclarative/kdeclarative.cpp b3906e2 src/kdeclarative/qmlobject.h f26b67d src/kdeclarative/qmlobject.cpp c483665 src/kdeclarative/qmlobjectsharedengine.h PRE-CREATION src/kdeclarative/qmlobjectsharedengine.cpp PRE-CREATION src/quickaddons/CMakeLists.txt 777d07c src/quickaddons/quickviewsharedengine.h PRE-CREATION src/quickaddons/quickviewsharedengine.cpp PRE-CREATION Diff: https://git.reviewboard.kde.org/r/123735/diff/ Testing --- Thanks, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 123735: version of QmlObject with a static engine
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123735/ --- (Updated May 18, 2015, 7:02 p.m.) Review request for KDE Frameworks and Plasma. Repository: kdeclarative Description --- to make easier doing applications like plasma that use a lot of qml to have a single engine make a subclass of QmlObject called QmlObjectSharedEngine that has a single, static QQmlEngine Diffs (updated) - src/kdeclarative/CMakeLists.txt d73bff0 src/kdeclarative/kdeclarative.cpp b3906e2 src/kdeclarative/qmlobject.h f26b67d src/kdeclarative/qmlobject.cpp c483665 src/kdeclarative/qmlobjectsharedengine.h PRE-CREATION src/kdeclarative/qmlobjectsharedengine.cpp PRE-CREATION src/quickaddons/CMakeLists.txt 777d07c src/quickaddons/quickviewsharedengine.h PRE-CREATION src/quickaddons/quickviewsharedengine.cpp PRE-CREATION Diff: https://git.reviewboard.kde.org/r/123735/diff/ Testing --- Thanks, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 123783: Adjust showing desktop behavior
On May 14, 2015, 11:23 p.m., Thomas Pfeiffer wrote: 1) The minimizability of windows is ignored. It's a cornercase, but the former behavior was a side-effect of the implementation. (At least I don't know a reason to keep them) Could you explain what minimizability of windows means, please? 2) The state is broken with the activation of windows, not them becoming visible. Latter doesn't work for most cases (unminimizing) for obvious reasons (they're not minimized ;-) and when a new window is mapped, the focus stealing prevention seems a good filter (if it's not good enough to gain the focus, it's not good enough to break the state either ;-) Sounds sensible 3) Keep above windows remain visible and do not break the state (as if they'd belong to the desktop) for a request by the HIG group. I'm frankly not sure about the background of this behavior (hopefully not krunner - that doesn't work) The reasoning behind that was the assumption that keepabove is used for windows that one always wants to see (e.g. because they contain some information one is monitoring). We have no data to back that assumption up, though, so please challenge it if you have reason to believe that keepabove is mostly used for windows which do not have to be always visible. Our words are not gospel, after all ;) 4) Windows in the desktop group initially remain above the desktop and can be activated w/ breaking the state, but can also hide behind the desktop (notably when that is clicked/activated) I'm not sure if I understood this correctly. My interpretation is this: * If I open a window that is related to the desktop and *then* activate Show Desktop, the window gets hidden * If I then activate the hidden window, it brakes the state * If I activate Show Desktop and *then* open a window that is related to the desktop, it gets shown without braking the state Is that correct? If so, sounds good to me! Thomas Lübking wrote: Could you explain what minimizability of windows means, please? Believe it or not, but windows can hint to be not minimizable (what KWin boldly ignores) and KWin has a rule to control that (you can specify that a particular window cannot be minimized) It's a corner case ;-) that one always wants to see In doubt, we'd meanwhile have an on screen display layer which is even above the fullscreen layer. The question is whether this context (showing desktop) is similar to eg. running a fullscreen game or video. Both would overlay even keep above windows. I'm not afraid of another field test, though -) I'm not sure if I understood this correctly. Second part: yes, first part: no. Basically they behave like keep above windows. They initially remain visible. If you click (activate/raise) the desktop, they'll go behind, if you then reactivate them (through the taskbar or eg. the desktop RMB menu), they'll show up WITHOUT breaking the state. I'm agnostic to whether they should be initially hidden, but would object having them break the state depending on whether they were visible while entering the state. 1st because it makes the code more complex ;-) 2nd because visible is relative in this context: they're neither keep above (so could have been behind a maximized window) nor on all virtual desktops (so could have been on such) They could even have randomly been occluded by three other windows. In return the assumed usecase show desktop - change wallpaper would randomly turn into show desktop - restore all windows - change wallpaper Sorry for not replying earlier :( Believe it or not, but windows can hint to be not minimizable (what KWin boldly ignores) and KWin has a rule to control that (you can specify that a particular window cannot be minimized) It's a corner case ;-) I assume non-minimizable windows are things like modal dialogs where someone at Microsoft (or Xerox or... I dunno) once had the bright idea that they should not have a minimize button. Those windows are not supposed to stay open for long anyway, so yes, corner case which does not deserve much attention (e.g. just treating them like any other window is fine). I'm not afraid of another field test, though -) Yeah, let's see what happens ;) Second part: yes, first part: no. Basically they behave like keep above windows. They initially remain visible. If you click (activate/raise) the desktop, they'll go behind, if you then reactivate them (through the taskbar or eg. the desktop RMB menu), they'll show up WITHOUT breaking the state. Ah okay. Yes, that is fine, too (better, probably). So yes, green light from my side as well! - Thomas --- This is an automatically generated e-mail. To reply, visit:
Planning merging the single qqml engine
Hi all, I think the branches for the single shared qqmlengine are pretty much ready (few cleanups upcoming days), seems pretty stable here.. did someone ran the branch for a while as well? In the end i managed to get a single engine for the whole session, views included (had to duplicate the View class in plasmaquick and kept the old one as deprecated for retrocompatibility unfortunately) the memory save seems pretty good, i *hope* stability improved as well :p what still uses separed engines are the applet configuration dialogs: this is necessary because they are supposed to use a different style for the qquickcontrols, and being the settings object that decides the style a qml singleton (qml singletons are unique by engine), the engine has to be different from the desktop/panel. The good thing is that config dialogs are instantiated relatively rarely, in most sessions not at all, so shouldn't touch too much a normal run For retrocompatibility the applets unfortunately have to specify explicitly they can share the engine in their metadata file (or eventual plasmapackage:/ urls break) at the moment it's using X-Plasma-RequiredExtensions=SharedEngine but I'm leaning more on the direction of something like X-Plasma-MinimumAPIVersion=5.11 I would like to have all set before frameworks 5.11 thoughts? -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 123735: version of QmlObject with a static engine
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123735/#review80600 --- src/quickaddons/quickviewsharedengine.cpp (lines 35 - 39) https://git.reviewboard.kde.org/r/123735/#comment55263 needed? src/quickaddons/quickviewsharedengine.cpp (line 63) https://git.reviewboard.kde.org/r/123735/#comment55267 initialise. src/quickaddons/quickviewsharedengine.cpp (line 228) https://git.reviewboard.kde.org/r/123735/#comment55269 syncWidth(); syncHeight(); here? Maybe move to a private method to share with executionFinished() src/quickaddons/quickviewsharedengine.cpp (line 252) https://git.reviewboard.kde.org/r/123735/#comment55266 why the cast? it's already a QQmlComponent::Status? - David Edmundson On May 18, 2015, 7:09 p.m., Marco Martin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123735/ --- (Updated May 18, 2015, 7:09 p.m.) Review request for KDE Frameworks and Plasma. Repository: kdeclarative Description --- to make easier doing applications like plasma that use a lot of qml to have a single engine make a subclass of QmlObject called QmlObjectSharedEngine that has a single, static QQmlEngine Adds a class called QuickViewSharedEngine that has the same behavior as QmlObjectSharedEngine(using it): static QQmlEngine, separed rootContexts() for each instance. This is used by desktopviews and panelviews to share their engine. Unfortunately it may not be possible to get the applet configuration dialogs to use this, since they still need a separed engine in order to have a different controls style (qstyle based) than the stuff in the desktop/panel Diffs - src/kdeclarative/CMakeLists.txt d73bff0 src/kdeclarative/kdeclarative.cpp b3906e2 src/kdeclarative/qmlobject.h f26b67d src/kdeclarative/qmlobject.cpp c483665 src/kdeclarative/qmlobjectsharedengine.h PRE-CREATION src/kdeclarative/qmlobjectsharedengine.cpp PRE-CREATION src/quickaddons/CMakeLists.txt 777d07c src/quickaddons/quickviewsharedengine.h PRE-CREATION src/quickaddons/quickviewsharedengine.cpp PRE-CREATION Diff: https://git.reviewboard.kde.org/r/123735/diff/ Testing --- Thanks, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 123738: Use column major in the taskbar when Force row settings is set
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123738/ --- (Updated maj 18, 2015, 7:40 e.m.) Review request for Plasma and Eike Hein. Changes --- Change to Always arrange tasks in columns of as many rows Repository: plasma-desktop Description --- When we have Force row settings and more than one row of items, the items start to jump around and it is had to keep track of where each item is. The atached patch changes the flow to TopToBottom, in stead of LeftToRight, when we have a horizontal layout and Force row settings, and similarly to LeftToRight in vertical layout. (In practice the vertical layout is always one column and this patch has no effect) Here are two videos that describe the problem First is the row major where taskbar items jump around: https://youtu.be/8udr2DJKobw And the second with a patched taskbar where the items jump around a lot less: https://youtu.be/bk17gnu1ETo Diffs (updated) - applets/taskmanager/package/contents/ui/ConfigGeneral.qml 36dd134 applets/taskmanager/package/contents/ui/main.qml 98ba7c3 Diff: https://git.reviewboard.kde.org/r/123738/diff/ Testing --- I have applied this patch to the system installed plasma 5.3 installation. Thanks, Kåre Särs ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Planning merging the single qqml engine
On Mon, May 18, 2015 at 9:28 PM, Marco Martin notm...@gmail.com wrote: Hi all, I think the branches for the single shared qqmlengine are pretty much ready (few cleanups upcoming days), seems pretty stable here.. did someone ran the branch for a while as well? In the end i managed to get a single engine for the whole session, views included (had to duplicate the View class in plasmaquick and kept the old one as deprecated for retrocompatibility unfortunately) the memory save seems pretty good, i *hope* stability improved as well :p what still uses separed engines are the applet configuration dialogs: this is necessary because they are supposed to use a different style for the qquickcontrols, and being the settings object that decides the style a qml singleton (qml singletons are unique by engine), the engine has to be different from the desktop/panel. The good thing is that config dialogs are instantiated relatively rarely, in most sessions not at all, so shouldn't touch too much a normal run For retrocompatibility the applets unfortunately have to specify explicitly they can share the engine in their metadata file (or eventual plasmapackage:/ urls break) at the moment it's using X-Plasma-RequiredExtensions=SharedEngine What does RequiredExtensions mean anyway? Is that a new attribute where you intent to add more extensions or does it already exist? It's name sounds slightly confusing to me. How can a SharedEngine be a extension? Anyway, with that attribute you let the applet developer OPT-IN in for shared engine. Setting that attribute can be easily forgotten. If anything, they should OPT-OUT thus by default use the shared engine. Perhaps a attribute like this is more appropriate?: X-Plasma-RequiresOwnQmlEngine=true or something alike. I'd definitely go for OPT-OUT (defaults = use shared engine). but I'm leaning more on the direction of something like X-Plasma-MinimumAPIVersion=5.11 I would like to have all set before frameworks 5.11 thoughts? -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Planning merging the single qqml engine
On Monday 18 May 2015, Mark Gaiser wrote: Anyway, with that attribute you let the applet developer OPT-IN in for shared engine. Setting that attribute can be easily forgotten. If anything, they should OPT-OUT thus by default use the shared engine. Perhaps a attribute like this is more appropriate?: X-Plasma-RequiresOwnQmlEngine=true or something alike. I'd definitely go for OPT-OUT (defaults = use shared engine). no, because the key here is retrocompatibility, old applets have to work as is. it's true that this makes it error prone, but that's the ugly need :/ otherwise there wouldn't be any reason for supporting both modes -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 123735: version of QmlObject with a static engine
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123735/ --- (Updated May 18, 2015, 8 p.m.) Review request for KDE Frameworks and Plasma. Repository: kdeclarative Description --- to make easier doing applications like plasma that use a lot of qml to have a single engine make a subclass of QmlObject called QmlObjectSharedEngine that has a single, static QQmlEngine Adds a class called QuickViewSharedEngine that has the same behavior as QmlObjectSharedEngine(using it): static QQmlEngine, separed rootContexts() for each instance. This is used by desktopviews and panelviews to share their engine. Unfortunately it may not be possible to get the applet configuration dialogs to use this, since they still need a separed engine in order to have a different controls style (qstyle based) than the stuff in the desktop/panel Diffs (updated) - src/kdeclarative/CMakeLists.txt d73bff0 src/kdeclarative/kdeclarative.cpp b3906e2 src/kdeclarative/qmlobject.h f26b67d src/kdeclarative/qmlobject.cpp c483665 src/kdeclarative/qmlobjectsharedengine.h PRE-CREATION src/kdeclarative/qmlobjectsharedengine.cpp PRE-CREATION src/quickaddons/CMakeLists.txt 777d07c src/quickaddons/quickviewsharedengine.h PRE-CREATION src/quickaddons/quickviewsharedengine.cpp PRE-CREATION Diff: https://git.reviewboard.kde.org/r/123735/diff/ Testing --- Thanks, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Planning merging the single qqml engine
Hi, That's running: kdeclarative - your branch plasma-framework - your branch plsama-workspace - master (which is pretty close to running latest frameworks with Plasma 5.3) Are there any significant changes in plasma-workspace and plasma-desktop, other than applet migration, since there's also a branch for them? Looking pretty nice though! Memory consumption for a freshly started Plasma session (no applets expanded so far) went from 215MiB to 145MiB on my laptop, startup also feels a little bit faster. What I found interesting that you changed import plasmapkg:/code/logic.js to import logic.js although the qml file is in a different folder, why does that work? Being a massively miserable grumpy git, I'd rather merge just after 5.11, giving us 4 weeks of testing. +1 for that Cheers, Kai Uwe ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Planning merging the single qqml engine
On Monday 18 May 2015, Kai Uwe Broulik wrote: What I found interesting that you changed import plasmapkg:/code/logic.js to import logic.js although the qml file is in a different folder, why does that work? since it can still figure out the package, the url interceptor takes js files from code/ and images from images/ on that the behavior didn't change, it was already rewriting paths like that -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Planning merging the single qqml engine
While I'm usually more conservative, I do think that something more decisive should be done in this case (and cases like these). While we do not want to break everything with each new release (wink wink ghm ghm nudge nudge), I don't think we want to support every not-still-preferred-approach-of-implementing-something we made before indefinitely. If there are important 3rd-party plasma 5 applets (are there?) that we really need to keep back-compatibility for, I'd propose this: - make it opt-in (as Marco says) - deprecate it - report notifications to the user 'this applet might make your desktop unstable' for all used applets that haven't opted-in - this would serve as a notification both to the users and the developers of said applets - schedule marking the support for these applets for the release after next, or something. Cheers, Ivan On 18 May 2015 at 21:53, Marco Martin notm...@gmail.com wrote: On Monday 18 May 2015, Mark Gaiser wrote: Anyway, with that attribute you let the applet developer OPT-IN in for shared engine. Setting that attribute can be easily forgotten. If anything, they should OPT-OUT thus by default use the shared engine. Perhaps a attribute like this is more appropriate?: X-Plasma-RequiresOwnQmlEngine=true or something alike. I'd definitely go for OPT-OUT (defaults = use shared engine). no, because the key here is retrocompatibility, old applets have to work as is. it's true that this makes it error prone, but that's the ugly need :/ otherwise there wouldn't be any reason for supporting both modes -- Marco Martin ___ 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: Plasma 5 is awesome...and some help required with build instructions
On Mon, May 18, 2015 at 8:07 PM, David Edmundson da...@davidedmundson.co.uk wrote: On Mon, May 18, 2015 at 7:05 PM, Aleix Pol aleix...@kde.org wrote: On Mon, May 18, 2015 at 7:28 PM, David Edmundson da...@davidedmundson.co.uk wrote: Just setting up on a new machine and thought I'd try following these instructions exactly, the way a new developer would. I got stuck on something I don't know how to solve. Under Kubuntu because Qt is compiled with a hardcoded plugindir for some reason. This means setting QT_PLUGIN_PATH env variables does nothing, which means you'll always be loading any plugins from /usr/ rather than the ones we just built. How did you get round that? Any ideas? David ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel On Kubuntu, you probably want to enable KDE_INSTALL_USE_QT_SYS_PATHS cmake option. but that will install to /usr Aleix ___ 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 That's the downside, yes. Aleix ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Planning merging the single qqml engine
The ironic thing here is that something would have to be introduced that will be deprecated Not really. It would deprecate the old qml engine per plasmoid. It is not about deprecating the opt-in thing. The ideal is to achieve 100% opt-in, that is, for all plugins to eventually get the SingleEngine requirement. Cheers, Ivan On 18 May 2015 at 22:51, Mark Gaiser mark...@gmail.com wrote: On Mon, May 18, 2015 at 9:53 PM, Marco Martin notm...@gmail.com wrote: On Monday 18 May 2015, Mark Gaiser wrote: Anyway, with that attribute you let the applet developer OPT-IN in for shared engine. Setting that attribute can be easily forgotten. If anything, they should OPT-OUT thus by default use the shared engine. Perhaps a attribute like this is more appropriate?: X-Plasma-RequiresOwnQmlEngine=true or something alike. I'd definitely go for OPT-OUT (defaults = use shared engine). no, because the key here is retrocompatibility, old applets have to work as is. it's true that this makes it error prone, but that's the ugly need :/ otherwise there wouldn't be any reason for supporting both modes While that - on it's own - is a very nice goal, sometimes you just have new developments that are clearly better and the way forward. This is one such case. Sure, you want to keep compatibility, but you should also strongly motivate those that develop applets to use the shared engine. Ivan's idea of deprecating it and clearly letting the user know might be a good compromise here. The ironic thing here is that something would have to be introduced that will be deprecated from the beginning. Something sounds wrong about that :) ___ 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: Planning merging the single qqml engine
On Mon, May 18, 2015 at 9:53 PM, Marco Martin notm...@gmail.com wrote: On Monday 18 May 2015, Mark Gaiser wrote: Anyway, with that attribute you let the applet developer OPT-IN in for shared engine. Setting that attribute can be easily forgotten. If anything, they should OPT-OUT thus by default use the shared engine. Perhaps a attribute like this is more appropriate?: X-Plasma-RequiresOwnQmlEngine=true or something alike. I'd definitely go for OPT-OUT (defaults = use shared engine). no, because the key here is retrocompatibility, old applets have to work as is. it's true that this makes it error prone, but that's the ugly need :/ otherwise there wouldn't be any reason for supporting both modes While that - on it's own - is a very nice goal, sometimes you just have new developments that are clearly better and the way forward. This is one such case. Sure, you want to keep compatibility, but you should also strongly motivate those that develop applets to use the shared engine. Ivan's idea of deprecating it and clearly letting the user know might be a good compromise here. The ironic thing here is that something would have to be introduced that will be deprecated from the beginning. Something sounds wrong about that :) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma 5 is awesome...and some help required with build instructions
On 18 May 2015 at 22:58, David Edmundson da...@davidedmundson.co.uk wrote: Just setting up on a new machine and thought I'd try following these instructions exactly, the way a new developer would. I got stuck on something I don't know how to solve. Under Kubuntu because Qt is compiled with a hardcoded plugindir for some reason. This means setting QT_PLUGIN_PATH env variables does nothing, which means you'll always be loading any plugins from /usr/ rather than the ones we just built. How did you get round that? Any ideas? By using Arch Linux? :P I did not do anything special in this regard, so I guess on my system QT_PLUGIN_PATH is being picked up properly. Btw, you commented out QTDIR in the wiki script, so a few of the later variables will have weird paths (QTDIR/plugins=/plugins) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 123846: Enable translations for devicenotifications dataengine
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123846/#review80611 --- Ship it! Thanks - Burkhard Lück On Mai 18, 2015, 11:21 nachm., Luigi Toscano wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123846/ --- (Updated Mai 18, 2015, 11:21 nachm.) Review request for Localization and Translation (l10n) and Plasma. Repository: plasma-workspace Description --- The patch should be quite straightforward, but see below. If correct, can I apply it to Plasma/5.3 as well? Allowing translations of previously untranslatable strings does not break the string freeze. Diffs - dataengines/devicenotifications/CMakeLists.txt 0b89b5e dataengines/devicenotifications/Messages.sh PRE-CREATION Diff: https://git.reviewboard.kde.org/r/123846/diff/ Testing --- I could not test it, sorry, but I had to report it before forgetting. Thanks, Luigi Toscano ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request 123846: Enable translations for devicenotifications dataengine
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123846/ --- Review request for Plasma. Repository: plasma-workspace Description --- The patch should be quite straightforward, but see below. If correct, can I apply it to Plasma/5.3 as well? Allowing translations of previously untranslatable strings does not break the string freeze. Diffs - dataengines/devicenotifications/CMakeLists.txt 0b89b5e dataengines/devicenotifications/Messages.sh PRE-CREATION Diff: https://git.reviewboard.kde.org/r/123846/diff/ Testing --- I could not test it, sorry, but I had to report it before forgetting. Thanks, Luigi Toscano ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Planning merging the single qqml engine
On Mon, May 18, 2015 at 8:28 PM, Marco Martin notm...@gmail.com wrote: Hi all, I think the branches for the single shared qqmlengine are pretty much ready (few cleanups upcoming days), seems pretty stable here.. did someone ran the branch for a while as well? Thanks for doing all that. Now to make you hate me. I have a crash, https://paste.kde.org/ppeqjl1c1 That's running: kdeclarative - your branch plasma-framework - your branch plsama-workspace - master (which is pretty close to running latest frameworks with Plasma 5.3) It's possibly unrelated, but I switched the top two back to master and it went away. Other than that, I think code-wise from me it's nearly good to go. Can I check it's these https://git.reviewboard.kde.org/r/123736/ and https://git.reviewboard.kde.org/r/123735/ and the branches in p-w, p-d, are just changing the metadata? in plasma-workspace TaskDelegate.qml has an import line removed, is that intended? In the end i managed to get a single engine for the whole session, views included (had to duplicate the View class in plasmaquick and kept the old one as deprecated for retrocompatibility unfortunately) the memory save seems pretty good, i *hope* stability improved as well :p what still uses separed engines are the applet configuration dialogs: this is necessary because they are supposed to use a different style for the qquickcontrols, and being the settings object that decides the style a qml singleton (qml singletons are unique by engine), the engine has to be different from the desktop/panel. The good thing is that config dialogs are instantiated relatively rarely, in most sessions not at all, so shouldn't touch too much a normal run Lets not worry about that for now, we've got from super many - just a few. Better to get this stuff merged, than worry about getting it down to 1. For retrocompatibility the applets unfortunately have to specify explicitly they can share the engine in their metadata file (or eventual plasmapackage:/ urls break) at the moment it's using X-Plasma-RequiredExtensions=SharedEngine but I'm leaning more on the direction of something like X-Plasma-MinimumAPIVersion=5.11 Out of curiosity, which plasmoids actually need their own engine? Were they all changed as a bulk find replace? I would like to have all set before frameworks 5.11 So that gives us roughly 2 weeks of testing. Without the plasma-workspace changes coming in 5.4 it doesn't really have any benefit to the user. Being a massively miserable grumpy git, I'd rather merge just after 5.11, giving us 4 weeks of testing. thoughts? -- 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
[Plasma Workspace Wallpapers] [Bug 347532] preferencias de escritorio no permite establecer fondo de pantalla ni individual ni en presentacion solo las del sistenma
https://bugs.kde.org/show_bug.cgi?id=347532 Sebastian Kügler se...@kde.org changed: What|Removed |Added CC||se...@kde.org Resolution|--- |WAITINGFORINFO Status|UNCONFIRMED |NEEDSINFO --- Comment #4 from Sebastian Kügler se...@kde.org --- I don't understand your problem. Could you perhaps try to phrase it in terms of actual and expected behaviour, and explain more clearly what exactly you are trying? -- You are receiving this mail because: You are the assignee for the bug. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Minutes Monday Plasma Hangout
Present: Antonis, Marco, Martin G., Sebastian, Kai Uwe, Vishesh, David Date: 18 May, 2015 Next week: no hangout on Monday, but on Tuesday due to public holiday in relevant regions Antonis: - Working on bugs in https://codereview.qt-project.org/#/c/112296/ - Will fix issues pointed out in https://git.reviewboard.kde.org/r/123682/ , then merge into ported kcm modules branch Kai Uwe: - Klipper now highlights trailing and leading whitespace https://git.reviewboard.kde.org/media/uploaded/files/2015/05/16/e31d060b-ab13-4f37-9ba3-26cb743ddee4__klippercolorcoded.png - visual fix for polkit kde dialog thingie - merged https://codereview.qt-project.org/#/c/111791/ so we now get proper scroll bars on desktops, starting qt 5.5 - devicepixelratio for icons https://codereview.qt-project.org/#/c/112435/ - notification countdown https://www.youtube.com/watch?v=k0KxRORAOng Marco: - working on branch of single, shared QML engine (huge memory savings) where possible - views (desktop, panel) can't share engine Martin: - Investigated why KWin's own windows don't work on Wayland Problem scope Alt+F3 popup: * QtWayland only creates popups if they have a parent QWindow * If there is no parent QtWindow it uses the last QWindow which got focus * Solution: create a dummy window and fake a mouse press * New problem: how to identify windows? QWindow::winId() is useless on wayland * New solution: KWayland interacts with QPA and can create a Client::Surface for a QWindow * New problem: QtWayland crashes if one sends mouse events without a keymap sent before * New solution: fix in Qt * New problem: popup not shown as QWindowSystemInterface::sendWindowSystemEvents is never called * Reason: KWin uses QEventDispatcherUNIX instead of QUnixEventDispatcherQPA * Cannot use QUnixEventDispatcherQPA as it's in QtPlatformSupport which doesn't have cmake support * New solution: implement a subclass for QEventDispatcherUNIX with same functionality * New problem: KWin dead locks when showing the popup * Reason: when starting painting Qt blocks main gui thread for last rendering being presented by compositor * New solution: fake frame rendered directly on damage events * doesn't work reliably * New solution: KWayland::Client can create a Client::ConnectionThread for the QPA connection. Whenever we process events we flush Qt's Client::ConnectionThread, then we dispatch the WaylandServer and ensure thus that the frameRendered is send before we start to process any events which could trigger a repaint * popups work now Problem scope QtQuick windows --- * QtWayland doesn't create windows with Qt::BypasssWindowManagerHint, but we use that on each of KWin's window... * Qt wants to add it's beautiful window decorations - disable in KWin through env variable * Mesa performs blocking waits for frame rendered - same problem scope as with Alt+F3 * changes for Alt+F3 seem to help also with QtQuick windows, but still the Outline can freeze KWin (needs more investigation). Vishesh: - Fixing bugs in Baloo's new backend - KRunner fixes (for example threading issue) - LMB needs patch to clean up locks when indexer crashes, being merged, hasn't arrived upstream yet David: - investigated crasher with statusnotifieritems - we may want API changes in libdbusmenu-qt, not too urgent, so let's sit down at Akademy to look at the grand scheme Sebastian: - Trying to get kwin_wayland running, problem loading drm backend - Chipping away at write support in kscreen wayland backend, making progres, but it's a lot of work -- 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
