Re: Review Request 121162: Some ideas for the image wallpaper
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121162/#review70896 --- Ship it! Ship It! - Marco Martin On Nov. 24, 2014, 9:19 p.m., Kai Uwe Broulik wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121162/ --- (Updated Nov. 24, 2014, 9:19 p.m.) Review request for Plasma. Repository: plasma-workspace Description --- This is just a bunch of stuff I played around with I'd like to get comments on Diffs - wallpapers/image/imagepackage/contents/ui/main.qml d81bd29 Diff: https://git.reviewboard.kde.org/r/121162/diff/ Testing --- QSG_VISUALIZE=overdraw and a bit of playing around Thanks, Kai Uwe Broulik ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: OSD and Notification Window Type
On Tuesday 25 November 2014, Martin Gräßlin wrote: plasma tooltips are override redirect yes did that change recently? If yes, Kai Uwe could you please try again? Qt::BypassWindowManagerHint is set since 27th may, in tooltipdialog.cpp constructor (note that the first time it shows up there is the usual qt xcb problem in which the window is shown an instant before the flags can really be set) -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Muon and kde-gtk-config moved to kde/workspace - was - Re: Moving repositories in the module structure
2014-11-13 13:03 GMT-02:00 Aleix Pol aleix...@kde.org: On Thu, Nov 13, 2014 at 3:50 PM, Albert Astals Cid aa...@kde.org wrote: Aleix, can you please explain to us why Mion Discover and Apper are two different things in principle? Seems the Apper guys disagree. Cheers, Albert There's 2 main differences: 1. Muon Discover has historically used OS metadata to define what are applications an what's relevant to the users (AKA end-user applications). Although they claim it will be done eventually on Apper as well. In any case Muon Discover doesn't aim to manage packages, it aims to provide a library of resources for the user to enhance his KDE/Plasma experience. Apper uses metadata to define application for years now, it also provided Plasma integration for removing applictions directly from kickoff thanks to PackageKit session interface. However on the point of managing packages Apper doesn't tries to merge the two things in a way you don' t need to open another application to install a package... 2. Muon has different backends, so we're not solely relying on PackageKit which means it can act as a frontend to different technologies other than packagekit, currently bodega, KNS/OCS and Apt (the last one for historic and practical reasons). Support for different technologies could also be added to Apper but no one ever stepped up to give a hand, and I myself don't like much these others to do it... Aleix -- Daniel Nicoletti KDE Developer - http://dantti.wordpress.com ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Some issues with porting KDE4 plasmoid to Plasma5
Hello, Some time ago I've started a porting of my plasmoids and dataengines to the newest Plasma and found some problems with it. I've ported a DataEngine w\o any problem, but I have issues about a Plasmoid. I've read API reference and look at examples from plasma-next and didn't find solutions. First of all I want say that I don't plan to use QML/JS now and plan to develop of my plasmoids in pure C++. Firstly it is related to other project parts which is in C++/Qt and I don't want to use additional languages w\o any special necessity. Also as far as I understand the core plasmoid part (on which I have issue too) still shoul be written in C++. Also I try to avoid using deprecated functions. My questions are: 1. Is there any alternative to Plasma::PopupApplet? If there is not, is there a plan to implement it? 2. Is there a possibility to paint complex UI w\o using QML (in C++ code)? For example, I didn't find old Applet::setLayout() and PopupApplet::setWidget() methods. 3. How can I connect DataEngine to my Plasmoid? The old method which I used was dataEnigne(), some new applets use this method too, but it doesn't exist in the newest Plasma headers. Some new widgets such as nm-applet use Plasma::DataEngineManager::self()-engine() constuction, but Plasma::DataEngineManager class doesn't exist in the Plasma too =( If you need a reference to my plasmoid, example on which I'm working now may be found here [1] (it is more simple than the second one). 1. https://github.com/arcan1s/netctl-gui -- Sincerely yours, Evgeniy Alekseev e-mail: darkarca...@mail.ru ICQ: 407-398-235 Jabber: arca...@jabber.ru 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
Delay in Kickoff Application Launcher
Hi, I'd like to know how can I remove the delay in Kickoff Application Launcher I mean the delay for opening submenus when the mouse hovers over a folder item. There must be a config file where I can set the delay time to zero. Thanks, Sandor Harangozo ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request 121240: Port to new KScreen API
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121240/ --- Review request for Plasma. Repository: plasma-workspace Description --- This patch ports ShellCorona and PanelView to new KScreen API. The new API is completely asynchronous and is using shared pointers. The internals have also undergone some major changes, but they don't directly affect Plasma. Additionally to the port, this patch also changes the way ShellCorona reacts to primary screen changes: instead of listening to Output::isPrimaryChanged on each output, it listens now to Config::primaryOutputChanged. The reason is that when some output is set as primary, the signal is emitted right away. This can happen before the old primary is unset though, which then causes crashes in screenInvariants() in some situations/configurations. Listening to Config::primaryOutputChanges ensures that Plasma reacts only once, and only when the Config is consistent. The new KScreen API is available in dev/redesign branches in libkscreen.git. I'll merge the branch to frameworks branch once this review is approved in order not to break build. Diffs - shell/panelview.cpp 0dc5740 shell/shellcorona.h 5e97e02 shell/shellcorona.cpp 0da789f Diff: https://git.reviewboard.kde.org/r/121240/diff/ Testing --- Been using this patch and the new KScreen for couple weeks now, works better than the old one. Thanks, Daniel Vrátil ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Some issues with porting KDE4 plasmoid to Plasma5
On Sunday 16 November 2014, Evgeniy Alekseev wrote: Hello, Some time ago I've started a porting of my plasmoids and dataengines to the newest Plasma and found some problems with it. I've ported a DataEngine w\o any problem, but I have issues about a Plasmoid. I've read API reference and look at examples from plasma-next and didn't find solutions. First of all I want say that I don't plan to use QML/JS now and plan to develop of my plasmoids in pure C++. Firstly it is related to other project in Plasma5 pure C++ plasmoids are not possible anymore, the c++ api was for QGraphicsView (since plasma was based on top of it) plasma5 is based on top of scene graph, so the only way to write an UI is trough QML. You can still use C++ in a dataengine or a private QML import. parts which is in C++/Qt and I don't want to use additional languages w\o any special necessity. Also as far as I understand the core plasmoid part (on which I have issue too) still shoul be written in C++. Also I try to avoid using deprecated functions. My questions are: 1. Is there any alternative to Plasma::PopupApplet? If there is not, is there a plan to implement it? all applets are popupapplets now. see http://notmart.org/blog/2014/02/making-plasmoids-qml-api-better/ especially the section Compact and full representations 2. Is there a possibility to paint complex UI w\o using QML (in C++ code)? For example, I didn't find old Applet::setLayout() and PopupApplet::setWidget() methods. no, only QML is allowed, and subclassing Applet doesn't really work anymore. If you have a complex QWidget ui in theory you could still have it by implementing it in a QML import, then making ti show from a slot invoked by qml. 3. How can I connect DataEngine to my Plasmoid? The old method which I used was dataEnigne(), some new applets use this method too, but it doesn't exist in the newest Plasma headers. Some new widgets such as nm-applet use Plasma::DataEngineManager::self()-engine() constuction, but Plasma::DataEngineManager class doesn't exist in the Plasma too =( see the QML bindings: https://techbase.kde.org/Development/Tutorials/Plasma2/QML2/API#Data_Engines -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Delay in Kickoff Application Launcher
There must be a config file where I can set the delay time to zero. There isn't, sorry. See FullRepresentation.qml:72 for the relevant code. David ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 121162: Some ideas for the image wallpaper
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121162/ --- (Updated Nov. 25, 2014, 9:35 a.m.) Status -- This change has been marked as submitted. Review request for Plasma. Repository: plasma-workspace Description --- This is just a bunch of stuff I played around with I'd like to get comments on Diffs - wallpapers/image/imagepackage/contents/ui/main.qml d81bd29 Diff: https://git.reviewboard.kde.org/r/121162/diff/ Testing --- QSG_VISUALIZE=overdraw and a bit of playing around Thanks, Kai Uwe Broulik ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 121236: Minimize overdraw in Desktop view
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121236/ --- (Updated Nov. 25, 2014, 9:37 a.m.) Status -- This change has been marked as submitted. Review request for Plasma. Repository: plasma-desktop Description --- This changes the root item to be Item and only shows a black Rectangle when dashboard is shown. Together with Review 121162 there is only ever one full-sized root item (used to be three and more). Diffs - desktoppackage/contents/views/Desktop.qml 73698f6 Diff: https://git.reviewboard.kde.org/r/121236/diff/ Testing --- Should look like it did before, however, when the dashboard is shown ontop of a light maximized window (browser) the contrast is too low imho (don't remember if that was the case before that). Plasmoidviewer also looks normal (eg. no transparent spots when resizing the window) Also, when switching wallpaper plugins (like from image to color) the transparency in the dashboard is gone. Afaics this has been the case without this patch as well but I failed to fix it. Thanks, Kai Uwe Broulik ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Jenkins build is back to normal : plasma-workspace_master_qt5 #1095
See http://build.kde.org/job/plasma-workspace_master_qt5/1095/changes ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 121240: Port to new KScreen API
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121240/#review70904 --- Ship it! Ship It! - Marco Martin On Nov. 25, 2014, 9:18 a.m., Daniel Vrátil wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121240/ --- (Updated Nov. 25, 2014, 9:18 a.m.) Review request for Plasma. Repository: plasma-workspace Description --- This patch ports ShellCorona and PanelView to new KScreen API. The new API is completely asynchronous and is using shared pointers. The internals have also undergone some major changes, but they don't directly affect Plasma. Additionally to the port, this patch also changes the way ShellCorona reacts to primary screen changes: instead of listening to Output::isPrimaryChanged on each output, it listens now to Config::primaryOutputChanged. The reason is that when some output is set as primary, the signal is emitted right away. This can happen before the old primary is unset though, which then causes crashes in screenInvariants() in some situations/configurations. Listening to Config::primaryOutputChanges ensures that Plasma reacts only once, and only when the Config is consistent. The new KScreen API is available in dev/redesign branches in libkscreen.git. I'll merge the branch to frameworks branch once this review is approved in order not to break build. Diffs - shell/panelview.cpp 0dc5740 shell/shellcorona.h 5e97e02 shell/shellcorona.cpp 0da789f Diff: https://git.reviewboard.kde.org/r/121240/diff/ Testing --- Been using this patch and the new KScreen for couple weeks now, works better than the old one. Thanks, Daniel Vrátil ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: QtQuick Controls Calendar
On Mon, Nov 24, 2014 at 8:09 PM, Aleix Pol aleix...@kde.org wrote: On Sat, Nov 8, 2014 at 6:20 PM, Kai Uwe Broulik k...@privat.broulik.de wrote: Hi all, I was looking into migrating the Plasma Calendar to QtQuick Controls Calendar. However, we went through so much work making this thing efficient and fast using Canvas but the QtQuick Controls Calendar again uses one item per day (which potentially contains a Label and Rects for the borders). I do not know whether it re-uses the items when switching through months (which is a bit laggy with the Canvas calendar), though. One advantage is that it would give us week numbers for free. Suggestions? Cheers, Kai Uwe Would it maybe help with calendars l10n? https://bugs.kde.org/show_bug.cgi?id=340558 Most probably not, the multi-calendar support is still missing in Qt afaik (QCalendarSystem). Cheers -- Martin Klapetek | KDE Developer ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Different calendars in Plasma 5
On Tue, Nov 25, 2014 at 1:03 AM, Aleix Pol aleix...@kde.org wrote: Hi, I went through some bug reports earlier today and found this one, that looks quite important in principle: https://bugs.kde.org/show_bug.cgi?id=340558 Apparently it's not possible to change Plasma's calendar type anymore. Can somebody who has worked on the plasmoid shed some light? Martin, Sebas? We need a) KCalendarSystem OR b) QCalendarSystem Now a) would mean depending on kdelibs4support, which mayyy be fine for the moment (maybe we even do in all the places needed). As for b), this is supposed to be part of the Qt's ICU stuff and was originally targeted for Qt 5.4, but I don't see it there so I guess it didn't make it. I do not know what the current plan/status is, John might know. Perhaps it could get into Qt 5.5. Then the applet's backend (a model) would have to be rewritten on top of either of those. Then just a kcm with the setting and it should just work(tm). Cheers -- Martin Klapetek | KDE Developer ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: OSD and Notification Window Type
On Tuesday 25 November 2014 10:09:42 Marco Martin wrote: On Tuesday 25 November 2014, Martin Gräßlin wrote: plasma tooltips are override redirect yes did that change recently? If yes, Kai Uwe could you please try again? Qt::BypassWindowManagerHint is set since 27th may, in tooltipdialog.cpp constructor (note that the first time it shows up there is the usual qt xcb problem in which the window is shown an instant before the flags can really be set) aha, so the first time it's not an override redirect, because changing this flag is not possible after the window got created. Cheers Martin signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: Different calendars in Plasma 5
On Tuesday 25 November 2014 11:38:56 Martin Klapetek wrote: On Tue, Nov 25, 2014 at 1:03 AM, Aleix Pol aleix...@kde.org wrote: Hi, I went through some bug reports earlier today and found this one, that looks quite important in principle: https://bugs.kde.org/show_bug.cgi?id=340558 Apparently it's not possible to change Plasma's calendar type anymore. Can somebody who has worked on the plasmoid shed some light? Martin, Sebas? We need a) KCalendarSystem OR b) QCalendarSystem Now a) would mean depending on kdelibs4support, which mayyy be fine for the moment (maybe we even do in all the places needed). As for b), this is supposed to be part of the Qt's ICU stuff and was originally targeted for Qt 5.4, but I don't see it there so I guess it didn't make it. I do not know what the current plan/status is, John might know. Perhaps it could get into Qt 5.5. Then the applet's backend (a model) would have to be rewritten on top of either of those. Then just a kcm with the setting and it should just work(tm). so for the time being that sounds like option a. It's at least another half a year till we get Qt 5.5. I'd say that is reason enough to temporarily depend on kdelibs4 support. 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 121228: Fix minimum height in notifications
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121228/#review70905 --- Ship it! Ship It! - Martin Klapetek On Nov. 24, 2014, 4:29 p.m., Kai Uwe Broulik wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121228/ --- (Updated Nov. 24, 2014, 4:29 p.m.) Review request for Plasma, Martin Klapetek and Vishesh Handa. Bugs: 341218 https://bugs.kde.org/show_bug.cgi?id=341218 Repository: plasma-workspace Description --- This changes the bahavior from Math.max(icon, text + margins) to Math.max(icon, text) + margins which should fix the layout in case the notification has no bodytext. Diffs - applets/notifications/package/contents/ui/NotificationItem.qml 1074e63 Diff: https://git.reviewboard.kde.org/r/121228/diff/ Testing --- Nope, no 5 here, hence the RR :) Thanks, Kai Uwe Broulik ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 121228: Fix minimum height in notifications
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121228/ --- (Updated Nov. 25, 2014, 11:04 a.m.) Status -- This change has been marked as submitted. Review request for Plasma, Martin Klapetek and Vishesh Handa. Bugs: 341218 https://bugs.kde.org/show_bug.cgi?id=341218 Repository: plasma-workspace Description --- This changes the bahavior from Math.max(icon, text + margins) to Math.max(icon, text) + margins which should fix the layout in case the notification has no bodytext. Diffs - applets/notifications/package/contents/ui/NotificationItem.qml 1074e63 Diff: https://git.reviewboard.kde.org/r/121228/diff/ Testing --- Nope, no 5 here, hence the RR :) Thanks, Kai Uwe Broulik ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 121240: Port to new KScreen API
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121240/#review70906 --- shell/shellcorona.cpp https://git.reviewboard.kde.org/r/121240/#comment49562 remove debug? shell/shellcorona.cpp https://git.reviewboard.kde.org/r/121240/#comment49563 Are you sure this is not needed anymore? - Aleix Pol Gonzalez On Nov. 25, 2014, 9:18 a.m., Daniel Vrátil wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121240/ --- (Updated Nov. 25, 2014, 9:18 a.m.) Review request for Plasma. Repository: plasma-workspace Description --- This patch ports ShellCorona and PanelView to new KScreen API. The new API is completely asynchronous and is using shared pointers. The internals have also undergone some major changes, but they don't directly affect Plasma. Additionally to the port, this patch also changes the way ShellCorona reacts to primary screen changes: instead of listening to Output::isPrimaryChanged on each output, it listens now to Config::primaryOutputChanged. The reason is that when some output is set as primary, the signal is emitted right away. This can happen before the old primary is unset though, which then causes crashes in screenInvariants() in some situations/configurations. Listening to Config::primaryOutputChanges ensures that Plasma reacts only once, and only when the Config is consistent. The new KScreen API is available in dev/redesign branches in libkscreen.git. I'll merge the branch to frameworks branch once this review is approved in order not to break build. Diffs - shell/panelview.cpp 0dc5740 shell/shellcorona.h 5e97e02 shell/shellcorona.cpp 0da789f Diff: https://git.reviewboard.kde.org/r/121240/diff/ Testing --- Been using this patch and the new KScreen for couple weeks now, works better than the old one. Thanks, Daniel Vrátil ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 121240: Port to new KScreen API
On Nov. 25, 2014, 12:04 p.m., Aleix Pol Gonzalez wrote: shell/shellcorona.cpp, line 851 https://git.reviewboard.kde.org/r/121240/diff/1/?file=329712#file329712line851 Are you sure this is not needed anymore? ShellCorona is not a public class, so nothing outside plasma-workspace needs it, and the rest of plasma-workspace compiles just fine without it. - Daniel --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121240/#review70906 --- On Nov. 25, 2014, 10:18 a.m., Daniel Vrátil wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121240/ --- (Updated Nov. 25, 2014, 10:18 a.m.) Review request for Plasma. Repository: plasma-workspace Description --- This patch ports ShellCorona and PanelView to new KScreen API. The new API is completely asynchronous and is using shared pointers. The internals have also undergone some major changes, but they don't directly affect Plasma. Additionally to the port, this patch also changes the way ShellCorona reacts to primary screen changes: instead of listening to Output::isPrimaryChanged on each output, it listens now to Config::primaryOutputChanged. The reason is that when some output is set as primary, the signal is emitted right away. This can happen before the old primary is unset though, which then causes crashes in screenInvariants() in some situations/configurations. Listening to Config::primaryOutputChanges ensures that Plasma reacts only once, and only when the Config is consistent. The new KScreen API is available in dev/redesign branches in libkscreen.git. I'll merge the branch to frameworks branch once this review is approved in order not to break build. Diffs - shell/panelview.cpp 0dc5740 shell/shellcorona.h 5e97e02 shell/shellcorona.cpp 0da789f Diff: https://git.reviewboard.kde.org/r/121240/diff/ Testing --- Been using this patch and the new KScreen for couple weeks now, works better than the old one. Thanks, Daniel Vrátil ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 121240: Port to new KScreen API
On Nov. 25, 2014, 11:04 a.m., Aleix Pol Gonzalez wrote: shell/shellcorona.cpp, line 851 https://git.reviewboard.kde.org/r/121240/diff/1/?file=329712#file329712line851 Are you sure this is not needed anymore? Daniel Vrátil wrote: ShellCorona is not a public class, so nothing outside plasma-workspace needs it, and the rest of plasma-workspace compiles just fine without it. should be fine removing it, yes - Marco --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121240/#review70906 --- On Nov. 25, 2014, 9:18 a.m., Daniel Vrátil wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121240/ --- (Updated Nov. 25, 2014, 9:18 a.m.) Review request for Plasma. Repository: plasma-workspace Description --- This patch ports ShellCorona and PanelView to new KScreen API. The new API is completely asynchronous and is using shared pointers. The internals have also undergone some major changes, but they don't directly affect Plasma. Additionally to the port, this patch also changes the way ShellCorona reacts to primary screen changes: instead of listening to Output::isPrimaryChanged on each output, it listens now to Config::primaryOutputChanged. The reason is that when some output is set as primary, the signal is emitted right away. This can happen before the old primary is unset though, which then causes crashes in screenInvariants() in some situations/configurations. Listening to Config::primaryOutputChanges ensures that Plasma reacts only once, and only when the Config is consistent. The new KScreen API is available in dev/redesign branches in libkscreen.git. I'll merge the branch to frameworks branch once this review is approved in order not to break build. Diffs - shell/panelview.cpp 0dc5740 shell/shellcorona.h 5e97e02 shell/shellcorona.cpp 0da789f Diff: https://git.reviewboard.kde.org/r/121240/diff/ Testing --- Been using this patch and the new KScreen for couple weeks now, works better than the old one. Thanks, Daniel Vrátil ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Different calendars in Plasma 5
On 11/25/2014 11:49 AM, Martin Gräßlin wrote: so for the time being that sounds like option a. It's at least another half a year till we get Qt 5.5. I'd say that is reason enough to temporarily depend on kdelibs4 support. +1. At the risk of bringing emotion into a technical topic, KDE's super-impressive support for international calender systems (check out jlayt's blogs on this -- some of my favorite reads on Planet KDE) has rightfully been a point of pride for us and not exposing it any more would be really sad. Cheers, Eike ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Stress testing KWin's screen handling
Hi all, I spent some time on screen management in KWin today and got it to the point where it doesn't fail any more no matter what I try. So please everyone using multiple screens and especially dynamically plug in and out, please give a try to the patch set in [1]. Please ensure to have latest master as it contains a crash fix for a crash triggered by the patch set. Short summary of the changes in the patch set: * uses XRandR instead of QDesktopWidget * uses KWin internal information about overall screen geometry instead of relying on the information in the X11 screen structure. The second part is the code I added today. My testing showed that unplugging a screen gives us proper XRandR events so KWin's internal is up to date, but the X11 screen information is wrong. So when we partially used the one and partially the other the rendering was just horribly broken. Now it's all based on the KWin internal information and I couldn't get the rendering broken any more. When changing screens please be patient. It takes time to settle the changes. Especially plasmashell takes quite some time on my system to render correctly again. I hope that it doesn't fail for others and we can get the changes in to improve the situation. Cheers Martin [1] https://git.reviewboard.kde.org/r/117614/ 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 121229: Highlight first entry when searching
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121229/#review70913 --- Ship it! nice! - Sebastian Kügler On Nov. 24, 2014, 5:27 p.m., Kai Uwe Broulik wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121229/ --- (Updated Nov. 24, 2014, 5:27 p.m.) Review request for Plasma and Sebastian Kügler. Bugs: 340067 https://bugs.kde.org/show_bug.cgi?id=340067 Repository: plasma-desktop Description --- Since pressing enter invokes the first entry it should be highlighted. Diffs - applets/kickoff/package/contents/ui/SearchView.qml 9fc8d40 Diff: https://git.reviewboard.kde.org/r/121229/diff/ Testing --- Works as expected. Thanks, Kai Uwe Broulik ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Stress testing KWin's screen handling
On Tue, Nov 25, 2014 at 1:17 PM, Martin Gräßlin mgraess...@kde.org wrote: Hi all, I spent some time on screen management in KWin today and got it to the point where it doesn't fail any more no matter what I try. So please everyone using multiple screens and especially dynamically plug in and out, please give a try to the patch set in [1]. Please ensure to have latest master as it contains a crash fix for a crash triggered by the patch set. Short summary of the changes in the patch set: * uses XRandR instead of QDesktopWidget * uses KWin internal information about overall screen geometry instead of relying on the information in the X11 screen structure. The second part is the code I added today. My testing showed that unplugging a screen gives us proper XRandR events so KWin's internal is up to date, but the X11 screen information is wrong. So when we partially used the one and partially the other the rendering was just horribly broken. Now it's all based on the KWin internal information and I couldn't get the rendering broken any more. When changing screens please be patient. It takes time to settle the changes. Especially plasmashell takes quite some time on my system to render correctly again. I hope that it doesn't fail for others and we can get the changes in to improve the situation. Cheers Martin [1] https://git.reviewboard.kde.org/r/117614/ Hi Martin, I just applied your patch, seems to work so far. I'll tell you if it breaks :D. Aleix ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 121234: [Kickoff] Use latest X11 user time for creating StartupInfoId
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121234/#review70914 --- Ship it! Ship It! - Eike Hein On Nov. 24, 2014, 7:05 p.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121234/ --- (Updated Nov. 24, 2014, 7:05 p.m.) Review request for Plasma, Eike Hein and Vishesh Handa. Repository: plasma-desktop Description --- The StartupInfoId is supposed to contain information about the process and event which triggered the startup of the application. E.g. in the case of Kickoff it should be the last input event and the pid of Plasma. By creating the StartupInfoId directly in Kickoff and passing it to KRun we can ensure that this information is correct. The code so far lost this information and the launch information was not correct. The timestamp is set to a random timestamp after the event and the pid is set to the one of the klauncher process. Furthermore this saves a roundtrip to the X Server from klauncher. @Eike and Vishesh: I'd suggest to add the same change to Kicker and KRunner. Diffs - applets/kickoff/CMakeLists.txt 817c7e41f4454aab66db5ad84e4b494395e5484f applets/kickoff/core/urlitemlauncher.cpp 2ed074709c88ed10cdd72bae7d2b6bf2879183ae Diff: https://git.reviewboard.kde.org/r/121234/diff/ Testing --- started applications through plasmoidviewer and inspected the /proc/x/environ to check the DESKTOP_STARTUP_ID env variable. Thanks, Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 121229: Highlight first entry when searching
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121229/ --- (Updated Nov. 25, 2014, 12:50 p.m.) Status -- This change has been marked as submitted. Review request for Plasma and Sebastian Kügler. Bugs: 340067 https://bugs.kde.org/show_bug.cgi?id=340067 Repository: plasma-desktop Description --- Since pressing enter invokes the first entry it should be highlighted. Diffs - applets/kickoff/package/contents/ui/SearchView.qml 9fc8d40 Diff: https://git.reviewboard.kde.org/r/121229/diff/ Testing --- Works as expected. Thanks, Kai Uwe Broulik ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 121240: Port to new KScreen API
On Nov. 25, 2014, 12:56 p.m., Aleix Pol Gonzalez wrote: shell/shellcorona.cpp, line 328 https://git.reviewboard.kde.org/r/121240/diff/1/?file=329712#file329712line328 Are you sure this is correct? This was done because at some point Configuration::primaryOutput and Output::isPrimary were not consistent and this was a way to make it consistent. The behaviour has changed a little with the new API (mostly because the way Outputs are updated have changed). Now Configuration::primaryOutput is changed after all Outputs have been updated. That's why this patch also switches from listening to Output::isPrimaryChanged to Configuration::primaryOutputChanged. The problem with reacting to Output::isPrimaryChanged is, that you will get the signal always twice: once for the output that is set to be primary, and once for the output where primary flag is unset. If the order is first unset, then set, then everything is OK, but if the order happens to be that first you get signal from the output that was set a primary and then from the one that was unset from primary, stuff gets broken and you start hitting various asserts in the codepath. By reacting to Config::primaryOutputChanged, you are sure that all the changes have already been applied (including primary), and that calling Config::primaryOutput gives you what you expect. - Daniel --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121240/#review70911 --- On Nov. 25, 2014, 10:18 a.m., Daniel Vrátil wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121240/ --- (Updated Nov. 25, 2014, 10:18 a.m.) Review request for Plasma. Repository: plasma-workspace Description --- This patch ports ShellCorona and PanelView to new KScreen API. The new API is completely asynchronous and is using shared pointers. The internals have also undergone some major changes, but they don't directly affect Plasma. Additionally to the port, this patch also changes the way ShellCorona reacts to primary screen changes: instead of listening to Output::isPrimaryChanged on each output, it listens now to Config::primaryOutputChanged. The reason is that when some output is set as primary, the signal is emitted right away. This can happen before the old primary is unset though, which then causes crashes in screenInvariants() in some situations/configurations. Listening to Config::primaryOutputChanges ensures that Plasma reacts only once, and only when the Config is consistent. The new KScreen API is available in dev/redesign branches in libkscreen.git. I'll merge the branch to frameworks branch once this review is approved in order not to break build. Diffs - shell/panelview.cpp 0dc5740 shell/shellcorona.h 5e97e02 shell/shellcorona.cpp 0da789f Diff: https://git.reviewboard.kde.org/r/121240/diff/ Testing --- Been using this patch and the new KScreen for couple weeks now, works better than the old one. Thanks, Daniel Vrátil ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Jenkins build is still unstable: plasma-desktop_stable_qt5 #10
See http://build.kde.org/job/plasma-desktop_stable_qt5/changes ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Some issues with porting KDE4 plasmoid to Plasma5
At Tuesday 25 November 2014 10:23:37 Marco Martin wrote: On Sunday 16 November 2014, Evgeniy Alekseev wrote: Hello, Some time ago I've started a porting of my plasmoids and dataengines to the newest Plasma and found some problems with it. I've ported a DataEngine w\o any problem, but I have issues about a Plasmoid. I've read API reference and look at examples from plasma-next and didn't find solutions. First of all I want say that I don't plan to use QML/JS now and plan to develop of my plasmoids in pure C++. Firstly it is related to other project in Plasma5 pure C++ plasmoids are not possible anymore, the c++ api was for QGraphicsView (since plasma was based on top of it) plasma5 is based on top of scene graph, so the only way to write an UI is trough QML. You can still use C++ in a dataengine or a private QML import. parts which is in C++/Qt and I don't want to use additional languages w\o any special necessity. Also as far as I understand the core plasmoid part (on which I have issue too) still shoul be written in C++. Also I try to avoid using deprecated functions. My questions are: 1. Is there any alternative to Plasma::PopupApplet? If there is not, is there a plan to implement it? all applets are popupapplets now. see http://notmart.org/blog/2014/02/making-plasmoids-qml-api-better/ especially the section Compact and full representations 2. Is there a possibility to paint complex UI w\o using QML (in C++ code)? For example, I didn't find old Applet::setLayout() and PopupApplet::setWidget() methods. no, only QML is allowed, and subclassing Applet doesn't really work anymore. If you have a complex QWidget ui in theory you could still have it by implementing it in a QML import, then making ti show from a slot invoked by qml. 3. How can I connect DataEngine to my Plasmoid? The old method which I used was dataEnigne(), some new applets use this method too, but it doesn't exist in the newest Plasma headers. Some new widgets such as nm-applet use Plasma::DataEngineManager::self()-engine() constuction, but Plasma::DataEngineManager class doesn't exist in the Plasma too =( see the QML bindings: https://techbase.kde.org/Development/Tutorials/Plasma2/QML2/API#Data_Engines Thank you for the answer and the links! Seems all my questions are QML porting retaled, so I'll look on it and hope will port own KDE stuff successfully =) Thank you again. -- Sincerely yours, Evgeniy Alekseev email: darkarca...@mail.ru ICQ: 407-398-235 Jabber: arca...@jabber.ru 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 121240: Port to new KScreen API
On Nov. 25, 2014, 11:56 a.m., Aleix Pol Gonzalez wrote: shell/shellcorona.cpp, line 328 https://git.reviewboard.kde.org/r/121240/diff/1/?file=329712#file329712line328 Are you sure this is correct? This was done because at some point Configuration::primaryOutput and Output::isPrimary were not consistent and this was a way to make it consistent. Daniel Vrátil wrote: The behaviour has changed a little with the new API (mostly because the way Outputs are updated have changed). Now Configuration::primaryOutput is changed after all Outputs have been updated. That's why this patch also switches from listening to Output::isPrimaryChanged to Configuration::primaryOutputChanged. The problem with reacting to Output::isPrimaryChanged is, that you will get the signal always twice: once for the output that is set to be primary, and once for the output where primary flag is unset. If the order is first unset, then set, then everything is OK, but if the order happens to be that first you get signal from the output that was set a primary and then from the one that was unset from primary, stuff gets broken and you start hitting various asserts in the codepath. By reacting to Config::primaryOutputChanged, you are sure that all the changes have already been applied (including primary), and that calling Config::primaryOutput gives you what you expect. Ok, merge the patch, I'll keep an eye for regressions. - Aleix --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121240/#review70911 --- On Nov. 25, 2014, 9:18 a.m., Daniel Vrátil wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121240/ --- (Updated Nov. 25, 2014, 9:18 a.m.) Review request for Plasma. Repository: plasma-workspace Description --- This patch ports ShellCorona and PanelView to new KScreen API. The new API is completely asynchronous and is using shared pointers. The internals have also undergone some major changes, but they don't directly affect Plasma. Additionally to the port, this patch also changes the way ShellCorona reacts to primary screen changes: instead of listening to Output::isPrimaryChanged on each output, it listens now to Config::primaryOutputChanged. The reason is that when some output is set as primary, the signal is emitted right away. This can happen before the old primary is unset though, which then causes crashes in screenInvariants() in some situations/configurations. Listening to Config::primaryOutputChanges ensures that Plasma reacts only once, and only when the Config is consistent. The new KScreen API is available in dev/redesign branches in libkscreen.git. I'll merge the branch to frameworks branch once this review is approved in order not to break build. Diffs - shell/panelview.cpp 0dc5740 shell/shellcorona.h 5e97e02 shell/shellcorona.cpp 0da789f Diff: https://git.reviewboard.kde.org/r/121240/diff/ Testing --- Been using this patch and the new KScreen for couple weeks now, works better than the old one. Thanks, Daniel Vrátil ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 121234: [Kickoff] Use latest X11 user time for creating StartupInfoId
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121234/#review70918 --- Ship it! Ship It! - Sebastian Kügler On Nov. 24, 2014, 7:05 p.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121234/ --- (Updated Nov. 24, 2014, 7:05 p.m.) Review request for Plasma, Eike Hein and Vishesh Handa. Repository: plasma-desktop Description --- The StartupInfoId is supposed to contain information about the process and event which triggered the startup of the application. E.g. in the case of Kickoff it should be the last input event and the pid of Plasma. By creating the StartupInfoId directly in Kickoff and passing it to KRun we can ensure that this information is correct. The code so far lost this information and the launch information was not correct. The timestamp is set to a random timestamp after the event and the pid is set to the one of the klauncher process. Furthermore this saves a roundtrip to the X Server from klauncher. @Eike and Vishesh: I'd suggest to add the same change to Kicker and KRunner. Diffs - applets/kickoff/CMakeLists.txt 817c7e41f4454aab66db5ad84e4b494395e5484f applets/kickoff/core/urlitemlauncher.cpp 2ed074709c88ed10cdd72bae7d2b6bf2879183ae Diff: https://git.reviewboard.kde.org/r/121234/diff/ Testing --- started applications through plasmoidviewer and inspected the /proc/x/environ to check the DESKTOP_STARTUP_ID env variable. Thanks, Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 121240: Port to new KScreen API
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121240/ --- (Updated Nov. 25, 2014, 2:13 p.m.) Status -- This change has been marked as submitted. Review request for Plasma. Repository: plasma-workspace Description --- This patch ports ShellCorona and PanelView to new KScreen API. The new API is completely asynchronous and is using shared pointers. The internals have also undergone some major changes, but they don't directly affect Plasma. Additionally to the port, this patch also changes the way ShellCorona reacts to primary screen changes: instead of listening to Output::isPrimaryChanged on each output, it listens now to Config::primaryOutputChanged. The reason is that when some output is set as primary, the signal is emitted right away. This can happen before the old primary is unset though, which then causes crashes in screenInvariants() in some situations/configurations. Listening to Config::primaryOutputChanges ensures that Plasma reacts only once, and only when the Config is consistent. The new KScreen API is available in dev/redesign branches in libkscreen.git. I'll merge the branch to frameworks branch once this review is approved in order not to break build. Diffs - shell/panelview.cpp 0dc5740 shell/shellcorona.h 5e97e02 shell/shellcorona.cpp 0da789f Diff: https://git.reviewboard.kde.org/r/121240/diff/ Testing --- Been using this patch and the new KScreen for couple weeks now, works better than the old one. Thanks, Daniel Vrátil ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 120777: Plasma Active: Initial commit for Baloo Cloud Component
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120777/ --- (Updated Nov. 25, 2014, 3:11 p.m.) Review request for Plasma. Changes --- I have updated the review request. As it has been discussed, the timeline will get its data from the QueryResultsModel (which lives inside the Baloo repo.) and it will generate the timeline. Repository: plasma-mobile Description --- At the moment, Baloo doesn't provide a timeline, which is something that we need for the activefilebrowser. So this new component, is introducing support for the timeline. Notes === * Baloocloud component contains the org.kde.baloo component inside it.The reason behind that, is that the implementation for the timeline is kind of terible because of its perfomance. * I have put the new component inside the plasma-mobile repository, for the above reason. But if the Baloo team, wants it inside the baloo repo then i can move it. I am fine with both approaches (keep it here or in the baloo repository. * If someone has a better idea about the implementation, the pls shoot :) Diffs (updated) - components/CMakeLists.txt 536b60e components/timelinemodel/CMakeLists.txt PRE-CREATION components/timelinemodel/qmldir PRE-CREATION components/timelinemodel/timelinemodel.h PRE-CREATION components/timelinemodel/timelinemodel.cpp PRE-CREATION components/timelinemodel/timelineplugin.h PRE-CREATION components/timelinemodel/timelineplugin.cpp PRE-CREATION CMakeLists.txt 9466447 Diff: https://git.reviewboard.kde.org/r/120777/diff/ Testing --- Everything looks ok. The performance is not bad, except from the fact that the implementation is a bit of hackish... Thanks, Antonis Tsiapaliokas ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Stress testing KWin's screen handling
On Tuesday 25 of November 2014 13:17:28 Martin Gräßlin wrote: Hi all, I spent some time on screen management in KWin today and got it to the point where it doesn't fail any more no matter what I try. So please everyone using multiple screens and especially dynamically plug in and out, please give a try to the patch set in [1]. Please ensure to have latest master as it contains a crash fix for a crash triggered by the patch set. Short summary of the changes in the patch set: * uses XRandR instead of QDesktopWidget * uses KWin internal information about overall screen geometry instead of relying on the information in the X11 screen structure. The second part is the code I added today. My testing showed that unplugging a screen gives us proper XRandR events so KWin's internal is up to date, but the X11 screen information is wrong. So when we partially used the one and partially the other the rendering was just horribly broken. Now it's all based on the KWin internal information and I couldn't get the rendering broken any more. When changing screens please be patient. It takes time to settle the changes. Especially plasmashell takes quite some time on my system to render correctly again. Coincidentally, I just merged my KScreen redesign, which should make this faster. I hope that it doesn't fail for others and we can get the changes in to improve the situation. So far it's much better than before, but still it sometimes happens, that after screen reshuffle, window decorations get detached from the windows and moved elsewhere. It just happened to me, after plugging in the 3rd screen: http://pub.dvratil.cz/kwin-bug.ogv, but I'm not able to reliably reproduce this. Dan Cheers Martin [1] https://git.reviewboard.kde.org/r/117614/ -- Daniel Vrátil | dvra...@redhat.com | dvratil on #kde-devel, #kontact, #akonadi Software Engineer - KDE Desktop Team, Red Hat Inc. GPG Key: 0xC59D614F6F4AE348 Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348 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 120777: Plasma Active: Initial commit for Baloo Cloud Component
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120777/#review70926 --- components/timelinemodel/qmldir https://git.reviewboard.kde.org/r/120777/#comment49572 I would prefer the module not having the word baloo in it. components/timelinemodel/timelinemodel.cpp https://git.reviewboard.kde.org/r/120777/#comment49570 How about makinng generateTimeLine a SLOT as well. This way you can just hook it up directly? components/timelinemodel/timelinemodel.cpp https://git.reviewboard.kde.org/r/120777/#comment49573 I'm a little confused. Where is this value being used? components/timelinemodel/timelinemodel.cpp https://git.reviewboard.kde.org/r/120777/#comment49571 Just my opinion - An assert would be better since m_level is an enum and should NEVER be any other value apart from those 3. - Vishesh Handa On Nov. 25, 2014, 3:11 p.m., Antonis Tsiapaliokas wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120777/ --- (Updated Nov. 25, 2014, 3:11 p.m.) Review request for Plasma. Repository: plasma-mobile Description --- At the moment, Baloo doesn't provide a timeline, which is something that we need for the activefilebrowser. So this new component, is introducing support for the timeline. Notes === * Baloocloud component contains the org.kde.baloo component inside it.The reason behind that, is that the implementation for the timeline is kind of terible because of its perfomance. * I have put the new component inside the plasma-mobile repository, for the above reason. But if the Baloo team, wants it inside the baloo repo then i can move it. I am fine with both approaches (keep it here or in the baloo repository. * If someone has a better idea about the implementation, the pls shoot :) Diffs - components/CMakeLists.txt 536b60e components/timelinemodel/CMakeLists.txt PRE-CREATION components/timelinemodel/qmldir PRE-CREATION components/timelinemodel/timelinemodel.h PRE-CREATION components/timelinemodel/timelinemodel.cpp PRE-CREATION components/timelinemodel/timelineplugin.h PRE-CREATION components/timelinemodel/timelineplugin.cpp PRE-CREATION CMakeLists.txt 9466447 Diff: https://git.reviewboard.kde.org/r/120777/diff/ Testing --- Everything looks ok. The performance is not bad, except from the fact that the implementation is a bit of hackish... Thanks, Antonis Tsiapaliokas ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 120777: Plasma Active: Initial commit for Baloo Cloud Component
On Nov. 25, 2014, 3:39 p.m., Vishesh Handa wrote: components/timelinemodel/timelinemodel.cpp, line 144 https://git.reviewboard.kde.org/r/120777/diff/2/?file=330659#file330659line144 Just my opinion - An assert would be better since m_level is an enum and should NEVER be any other value apart from those 3. +1 On Nov. 25, 2014, 3:39 p.m., Vishesh Handa wrote: components/timelinemodel/timelinemodel.cpp, line 103 https://git.reviewboard.kde.org/r/120777/diff/2/?file=330659#file330659line103 I'm a little confused. Where is this value being used? yeah, this doesn't look right. the query should be constructed in a way that only results within dates between startDate and endDate are considered. right now those values don't seem used at all? - Marco --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120777/#review70926 --- On Nov. 25, 2014, 3:11 p.m., Antonis Tsiapaliokas wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120777/ --- (Updated Nov. 25, 2014, 3:11 p.m.) Review request for Plasma. Repository: plasma-mobile Description --- At the moment, Baloo doesn't provide a timeline, which is something that we need for the activefilebrowser. So this new component, is introducing support for the timeline. Notes === * Baloocloud component contains the org.kde.baloo component inside it.The reason behind that, is that the implementation for the timeline is kind of terible because of its perfomance. * I have put the new component inside the plasma-mobile repository, for the above reason. But if the Baloo team, wants it inside the baloo repo then i can move it. I am fine with both approaches (keep it here or in the baloo repository. * If someone has a better idea about the implementation, the pls shoot :) Diffs - components/CMakeLists.txt 536b60e components/timelinemodel/CMakeLists.txt PRE-CREATION components/timelinemodel/qmldir PRE-CREATION components/timelinemodel/timelinemodel.h PRE-CREATION components/timelinemodel/timelinemodel.cpp PRE-CREATION components/timelinemodel/timelineplugin.h PRE-CREATION components/timelinemodel/timelineplugin.cpp PRE-CREATION CMakeLists.txt 9466447 Diff: https://git.reviewboard.kde.org/r/120777/diff/ Testing --- Everything looks ok. The performance is not bad, except from the fact that the implementation is a bit of hackish... Thanks, Antonis Tsiapaliokas ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Change in plasma-framework[master]: use PlasmaCore.ColorScope when suitable
Marco Martin has uploaded a new change for review. https://gerrit.vesnicky.cesnet.cz/r/177 Change subject: use PlasmaCore.ColorScope when suitable .. use PlasmaCore.ColorScope when suitable It is possible to put a PlasmaCore.ColorScope element, to automatically change the colors: if for instance the complementary scope will be set, all labels descendent of such element would flip their color Change-Id: I2214aca522eb094cf067d8726c5bf2a7ecbf36b3 --- M src/declarativeimports/plasmacomponents/qml/Label.qml M src/declarativeimports/plasmacomponents/qml/styles/TextAreaStyle.qml M src/declarativeimports/plasmacomponents/qml/styles/ToolButtonStyle.qml 3 files changed, 5 insertions(+), 5 deletions(-) git pull ssh://gerrit.vesnicky.cesnet.cz:29418/plasma-framework refs/changes/77/177/1 diff --git a/src/declarativeimports/plasmacomponents/qml/Label.qml b/src/declarativeimports/plasmacomponents/qml/Label.qml index 1243ca6..a22efb6 100644 --- a/src/declarativeimports/plasmacomponents/qml/Label.qml +++ b/src/declarativeimports/plasmacomponents/qml/Label.qml @@ -50,7 +50,7 @@ font.underline: theme.defaultFont.underline font.weight: theme.defaultFont.weight font.wordSpacing: theme.defaultFont.wordSpacing -color: theme.textColor +color: PlasmaCore.ColorScope.textColor opacity: enabled? 1 : 0.6 diff --git a/src/declarativeimports/plasmacomponents/qml/styles/TextAreaStyle.qml b/src/declarativeimports/plasmacomponents/qml/styles/TextAreaStyle.qml index 68f1a8b..90af0c5 100644 --- a/src/declarativeimports/plasmacomponents/qml/styles/TextAreaStyle.qml +++ b/src/declarativeimports/plasmacomponents/qml/styles/TextAreaStyle.qml @@ -36,9 +36,9 @@ font: theme.defaultFont backgroundColor: transparent -textColor: theme.viewTextColor -selectionColor: theme.viewFocusColor -selectedTextColor: theme.viewBackgroundColor +textColor: control.backgroundVisible ? theme.viewTextColor : PlasmaCore.ColorScope.textColor +selectionColor: control.backgroundVisible ? theme.viewFocusColor : PlasmaCore.ColorScope.highlightColor +selectedTextColor: control.backgroundVisible ? theme.viewBackgroundColor : PlasmaCore.ColorScope.backgroundColor renderType: Text.NativeRendering diff --git a/src/declarativeimports/plasmacomponents/qml/styles/ToolButtonStyle.qml b/src/declarativeimports/plasmacomponents/qml/styles/ToolButtonStyle.qml index af04469..cf19524 100644 --- a/src/declarativeimports/plasmacomponents/qml/styles/ToolButtonStyle.qml +++ b/src/declarativeimports/plasmacomponents/qml/styles/ToolButtonStyle.qml @@ -87,7 +87,7 @@ visible: control.text != Layout.fillWidth: true height: parent.height -color: control.hovered || !control.flat ? theme.buttonTextColor : theme.textColor +color: control.hovered || !control.flat ? theme.buttonTextColor : PlasmaCore.ColorScope.textColor horizontalAlignment: icon.valid ? Text.AlignLeft : Text.AlignHCenter verticalAlignment: Text.AlignVCenter elide: Text.ElideRight -- To view, visit https://gerrit.vesnicky.cesnet.cz/r/177 To unsubscribe, visit https://gerrit.vesnicky.cesnet.cz/r/settings Gerrit-MessageType: newchange Gerrit-Change-Id: I2214aca522eb094cf067d8726c5bf2a7ecbf36b3 Gerrit-PatchSet: 1 Gerrit-Project: plasma-framework Gerrit-Branch: master Gerrit-Owner: Marco Martin notm...@gmail.com Gerrit-Reviewer: David Edmundson da...@davidedmundson.co.uk ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 121201: KRunner: Do not detect anything with a '.' as a NetworkLocation
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121201/#review70942 --- ping. It would be nice if someone could comment on this. I cannot use Qt 5.4 right now. - Vishesh Handa On Nov. 21, 2014, 6:10 p.m., Vishesh Handa wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121201/ --- (Updated Nov. 21, 2014, 6:10 p.m.) Review request for Plasma. Bugs: 340140 https://bugs.kde.org/show_bug.cgi?id=340140 Repository: krunner Description --- One can also uses a decimal point in a calculator. Diffs - autotests/runnercontexttest.cpp ba5f6a1 src/runnercontext.cpp 2d6177d Diff: https://git.reviewboard.kde.org/r/121201/diff/ Testing --- Thanks, Vishesh Handa ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request 121244: Remove workarounds we had for the nested event loops
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121244/ --- Review request for Plasma. Repository: plasma-workspace Description --- Instead of keeping the state, expect the code to follow the order it's expected from it. Needs to bump the KF5 requirement to current KDeclarative (master), or it can run in problems. Diffs - CMakeLists.txt 7856833 shell/shellcorona.h 37f8b0e shell/shellcorona.cpp fd8e9b7 Diff: https://git.reviewboard.kde.org/r/121244/diff/ Testing --- Been running it for the last week. Thanks, Aleix Pol Gonzalez ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 121244: Remove workarounds we had for the nested event loops
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121244/#review70944 --- Ship it! CMakeLists.txt https://git.reviewboard.kde.org/r/121244/#comment49579 unrelated commit? - Marco Martin On Nov. 25, 2014, 6:33 p.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121244/ --- (Updated Nov. 25, 2014, 6:33 p.m.) Review request for Plasma. Repository: plasma-workspace Description --- Instead of keeping the state, expect the code to follow the order it's expected from it. Needs to bump the KF5 requirement to current KDeclarative (master), or it can run in problems. Diffs - CMakeLists.txt 7856833 shell/shellcorona.h 37f8b0e shell/shellcorona.cpp fd8e9b7 Diff: https://git.reviewboard.kde.org/r/121244/diff/ Testing --- Been running it for the last week. Thanks, Aleix Pol Gonzalez ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 121240: Port to new KScreen API
In data martedì 25 novembre 2014 11:48:02, Daniel Vrátil ha scritto: ShellCorona is not a public class, so nothing outside plasma-workspace needs it, and the rest of plasma-workspace compiles just fine without it. Posting here for those who missed it in #plasma: this change makes plasmashell crash if kactivitymanagerd is running (because KScreen isn't done yet and yet kamd tries to access screenForContainment). The fault lies in kactivitymanagerd: I tried to look at the code but I couldn't find anything obvious. Can someone more knowledgeable have an insight of why this happens? This is the bt: Thread 1 (Thread 0x7f62be2477c0 (LWP 24141)): [KCrash Handler] #5 0x7f62bd0f1dc4 in KScreen::Config::outputs() const () at /usr/lib64/libKF5Screen.so.5 #6 0x0044e2a3 in ShellCorona::screenForContainment(Plasma::Containment const*) const () #7 0x7f62bc90a2df in Plasma::CoronaPrivate::importLayout(KConfigGroup const, bool) (this=0x2639b20, conf=..., mergeConfig=mergeConfig@entry=false) at /usr/src/debug/plasma-framework-5.5.0git/src/plasma/corona.cpp:566 #8 0x7f62bc90a485 in Plasma::Corona::loadLayout(QString const) (this=0x2664b80, configName=...) at /usr/src/debug/plasma- framework-5.5.0git/src/plasma/corona.cpp:161 #9 0x00455581 in () #10 0x00456b65 in () #11 0x7f62b883d3e1 in QMetaObject::activate(QObject*, int, int, void**) () at /usr/lib64/libQt5Core.so.5 #12 0x7f62bd3339b1 in KActivities::Consumer::serviceStatusChanged(KActivities::Consumer::ServiceStatus) () at /usr/lib64/libKF5Activities.so.5 #13 0x7f62b883d3e1 in QMetaObject::activate(QObject*, int, int, void**) () at /usr/lib64/libQt5Core.so.5 #14 0x7f62bd333921 in () at /usr/lib64/libKF5Activities.so.5 #15 0x7f62bd32e0b0 in () at /usr/lib64/libKF5Activities.so.5 #16 0x7f62bd32f827 in () at /usr/lib64/libKF5Activities.so.5 #17 0x7f62bd32d932 in () at /usr/lib64/libKF5Activities.so.5 #18 0x7f62bd3341a4 in () at /usr/lib64/libKF5Activities.so.5 #19 0x7f62b883d3e1 in QMetaObject::activate(QObject*, int, int, void**) () at /usr/lib64/libQt5Core.so.5 #20 0x7f62b95d1caf in QDBusPendingCallWatcher::finished(QDBusPendingCallWatcher*) () at /usr/lib64/libQt5DBus.so.5 #21 0x7f62b95d3337 in () at /usr/lib64/libQt5DBus.so.5 #22 0x7f62b883e1e6 in QObject::event(QEvent*) () at /usr/lib64/libQt5Core.so.5 #23 0x7f62b9b602ec in QApplicationPrivate::notify_helper(QObject*, QEvent*) () at /usr/lib64/libQt5Widgets.so.5 #24 0x7f62b9b65350 in QApplication::notify(QObject*, QEvent*) () at /usr/lib64/libQt5Widgets.so.5 #25 0x7f62b880db85 in QCoreApplication::notifyInternal(QObject*, QEvent*) () at /usr/lib64/libQt5Core.so.5 #26 0x7f62b880fa1f in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () at /usr/lib64/libQt5Core.so.5 #27 0x7f62b88659f3 in () at /usr/lib64/libQt5Core.so.5 #28 0x7f62b46e6a04 in g_main_context_dispatch () at /usr/lib64/libglib-2.0.so.0 #29 0x7f62b46e6c48 in () at /usr/lib64/libglib-2.0.so.0 #30 0x7f62b46e6cec in g_main_context_iteration () at /usr/lib64/libglib-2.0.so.0 #31 0x7f62b8864e6c in QEventDispatcherGlib::processEvents(QFlagsQEventLoop::ProcessEventsFlag) () at /usr/lib64/libQt5Core.so.5 #32 0x7f62b880baeb in QEventLoop::exec(QFlagsQEventLoop::ProcessEventsFlag) () at /usr/lib64/libQt5Core.so.5 #33 0x7f62b8813156 in QCoreApplication::exec() () at /usr/lib64/libQt5Core.so.5 #34 0x00432024 in main () -- Luca Beltrame - KDE Forums team KDE Science supporter GPG key ID: 6E1A4E79 signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [kde-promo] Plasma 5.1.1 announcement
El Dimecres, 19 de novembre de 2014, a les 10:50:55, Ben Cooksley va escriure: On Wed, Nov 19, 2014 at 8:14 AM, Albert Astals Cid aa...@kde.org wrote: El Dimarts, 11 de novembre de 2014, a les 22:53:58, Albert Astals Cid va escriure: Hi guys, is there any reason https://www.kde.org/announcements/plasma-5.1.1.php says Plasma 5 was released in July and links to https://www.kde.org/announcements/plasma5.0/index.php instead of saying Plasma 5.1 was released in October and link to https://www.kde.org/announcements/plasma-5.1/index.php ? Was the announcement written by a ghost? Or is the person that wrote the announcement for Plasma 5.1.1 not subscribed to neither kde-promo nor plasma-devel? Anyway, if noone oposes i'll fix it to refer Plasma 5.1 instead of Plasma 5.0. I would recommend going ahead and making the change, Done. Albert I already had to fix the download urls for 5.1.1 which were broken. Cheers, Albert Thanks, Ben Cheers, Albert ___ This message is from the kde-promo mailing list. Visit https://mail.kde.org/mailman/listinfo/kde-promo to unsubscribe, set digest on or temporarily stop your subscription. ___ This message is from the kde-promo mailing list. Visit https://mail.kde.org/mailman/listinfo/kde-promo to unsubscribe, set digest on or temporarily stop your subscription. ___ This message is from the kde-promo mailing list. Visit https://mail.kde.org/mailman/listinfo/kde-promo to unsubscribe, set digest on or temporarily stop your subscription. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request 121253: Fix password focus in lockscreen
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121253/ --- Review request for Plasma. Repository: plasma-workspace Description --- Fix password focus in lockscreen When navigating the listview with the keyboard, the focus of the password field can get lost as it moves to the button. This patch reclaims the focus whenever the password field becomes visible. Diffs - lookandfeel/contents/lockscreen/LockScreen.qml 8a495ea208325ba3b2ef09efaef49515cc99830d Diff: https://git.reviewboard.kde.org/r/121253/diff/ Testing --- Navigated lockscreen with keyboard and mouse. Focus is handled correctly. Thanks, Sebastian Kügler ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 121240: Port to new KScreen API
In data martedì 25 novembre 2014 21:13:07, Luca Beltrame ha scritto: plasmashell crash if kactivitymanagerd is running (because KScreen isn't done yet and yet kamd tries to access screenForContainment). The fault lies Follow up: I noticed that in the KCM the primary display was reset as not defined. When setting a primary display, the crash does not occur. -- Luca Beltrame - KDE Forums team KDE Science supporter GPG key ID: 6E1A4E79 signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 121240: Port to new KScreen API
On Tue, Nov 25, 2014 at 9:13 PM, Luca Beltrame lbeltr...@kde.org wrote: In data martedì 25 novembre 2014 11:48:02, Daniel Vrátil ha scritto: ShellCorona is not a public class, so nothing outside plasma-workspace needs it, and the rest of plasma-workspace compiles just fine without it. Posting here for those who missed it in #plasma: this change makes plasmashell crash if kactivitymanagerd is running (because KScreen isn't done yet and yet kamd tries to access screenForContainment). The fault lies in kactivitymanagerd: I tried to look at the code but I couldn't find anything obvious. Can someone more knowledgeable have an insight of why this happens? This is the bt: Thread 1 (Thread 0x7f62be2477c0 (LWP 24141)): [KCrash Handler] #5 0x7f62bd0f1dc4 in KScreen::Config::outputs() const () at /usr/lib64/libKF5Screen.so.5 #6 0x0044e2a3 in ShellCorona::screenForContainment(Plasma::Containment const*) const () #7 0x7f62bc90a2df in Plasma::CoronaPrivate::importLayout(KConfigGroup const, bool) (this=0x2639b20, conf=..., mergeConfig=mergeConfig@entry =false) at /usr/src/debug/plasma-framework-5.5.0git/src/plasma/corona.cpp:566 #8 0x7f62bc90a485 in Plasma::Corona::loadLayout(QString const) (this=0x2664b80, configName=...) at /usr/src/debug/plasma- framework-5.5.0git/src/plasma/corona.cpp:161 #9 0x00455581 in () #10 0x00456b65 in () #11 0x7f62b883d3e1 in QMetaObject::activate(QObject*, int, int, void**) () at /usr/lib64/libQt5Core.so.5 #12 0x7f62bd3339b1 in KActivities::Consumer::serviceStatusChanged(KActivities::Consumer::ServiceStatus) () at /usr/lib64/libKF5Activities.so.5 #13 0x7f62b883d3e1 in QMetaObject::activate(QObject*, int, int, void**) () at /usr/lib64/libQt5Core.so.5 #14 0x7f62bd333921 in () at /usr/lib64/libKF5Activities.so.5 #15 0x7f62bd32e0b0 in () at /usr/lib64/libKF5Activities.so.5 #16 0x7f62bd32f827 in () at /usr/lib64/libKF5Activities.so.5 #17 0x7f62bd32d932 in () at /usr/lib64/libKF5Activities.so.5 #18 0x7f62bd3341a4 in () at /usr/lib64/libKF5Activities.so.5 #19 0x7f62b883d3e1 in QMetaObject::activate(QObject*, int, int, void**) () at /usr/lib64/libQt5Core.so.5 #20 0x7f62b95d1caf in QDBusPendingCallWatcher::finished(QDBusPendingCallWatcher*) () at /usr/lib64/libQt5DBus.so.5 #21 0x7f62b95d3337 in () at /usr/lib64/libQt5DBus.so.5 #22 0x7f62b883e1e6 in QObject::event(QEvent*) () at /usr/lib64/libQt5Core.so.5 #23 0x7f62b9b602ec in QApplicationPrivate::notify_helper(QObject*, QEvent*) () at /usr/lib64/libQt5Widgets.so.5 #24 0x7f62b9b65350 in QApplication::notify(QObject*, QEvent*) () at /usr/lib64/libQt5Widgets.so.5 #25 0x7f62b880db85 in QCoreApplication::notifyInternal(QObject*, QEvent*) () at /usr/lib64/libQt5Core.so.5 #26 0x7f62b880fa1f in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () at /usr/lib64/libQt5Core.so.5 #27 0x7f62b88659f3 in () at /usr/lib64/libQt5Core.so.5 #28 0x7f62b46e6a04 in g_main_context_dispatch () at /usr/lib64/libglib-2.0.so.0 #29 0x7f62b46e6c48 in () at /usr/lib64/libglib-2.0.so.0 #30 0x7f62b46e6cec in g_main_context_iteration () at /usr/lib64/libglib-2.0.so.0 #31 0x7f62b8864e6c in QEventDispatcherGlib::processEvents(QFlagsQEventLoop::ProcessEventsFlag) () at /usr/lib64/libQt5Core.so.5 #32 0x7f62b880baeb in QEventLoop::exec(QFlagsQEventLoop::ProcessEventsFlag) () at /usr/lib64/libQt5Core.so.5 #33 0x7f62b8813156 in QCoreApplication::exec() () at /usr/lib64/libQt5Core.so.5 #34 0x00432024 in main () -- Luca Beltrame - KDE Forums team KDE Science supporter GPG key ID: 6E1A4E79 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel I'm getting crashes too, investigating Aleix ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 121240: Port to new KScreen API
On Tue, Nov 25, 2014 at 9:13 PM, Luca Beltrame lbeltr...@kde.org wrote: In data martedì 25 novembre 2014 11:48:02, Daniel Vrátil ha scritto: ShellCorona is not a public class, so nothing outside plasma-workspace needs it, and the rest of plasma-workspace compiles just fine without it. Posting here for those who missed it in #plasma: this change makes plasmashell crash if kactivitymanagerd is running (because KScreen isn't done yet and yet kamd tries to access screenForContainment). The fault lies in kactivitymanagerd: I tried to look at the code but I couldn't find anything obvious. Can someone more knowledgeable have an insight of why this happens? This is the bt: Thread 1 (Thread 0x7f62be2477c0 (LWP 24141)): [KCrash Handler] #5 0x7f62bd0f1dc4 in KScreen::Config::outputs() const () at /usr/lib64/libKF5Screen.so.5 #6 0x0044e2a3 in ShellCorona::screenForContainment(Plasma::Containment const*) const () #7 0x7f62bc90a2df in Plasma::CoronaPrivate::importLayout(KConfigGroup const, bool) (this=0x2639b20, conf=..., mergeConfig=mergeConfig@entry =false) at /usr/src/debug/plasma-framework-5.5.0git/src/plasma/corona.cpp:566 #8 0x7f62bc90a485 in Plasma::Corona::loadLayout(QString const) (this=0x2664b80, configName=...) at /usr/src/debug/plasma- framework-5.5.0git/src/plasma/corona.cpp:161 #9 0x00455581 in () #10 0x00456b65 in () #11 0x7f62b883d3e1 in QMetaObject::activate(QObject*, int, int, void**) () at /usr/lib64/libQt5Core.so.5 #12 0x7f62bd3339b1 in KActivities::Consumer::serviceStatusChanged(KActivities::Consumer::ServiceStatus) () at /usr/lib64/libKF5Activities.so.5 #13 0x7f62b883d3e1 in QMetaObject::activate(QObject*, int, int, void**) () at /usr/lib64/libQt5Core.so.5 #14 0x7f62bd333921 in () at /usr/lib64/libKF5Activities.so.5 #15 0x7f62bd32e0b0 in () at /usr/lib64/libKF5Activities.so.5 #16 0x7f62bd32f827 in () at /usr/lib64/libKF5Activities.so.5 #17 0x7f62bd32d932 in () at /usr/lib64/libKF5Activities.so.5 #18 0x7f62bd3341a4 in () at /usr/lib64/libKF5Activities.so.5 #19 0x7f62b883d3e1 in QMetaObject::activate(QObject*, int, int, void**) () at /usr/lib64/libQt5Core.so.5 #20 0x7f62b95d1caf in QDBusPendingCallWatcher::finished(QDBusPendingCallWatcher*) () at /usr/lib64/libQt5DBus.so.5 #21 0x7f62b95d3337 in () at /usr/lib64/libQt5DBus.so.5 #22 0x7f62b883e1e6 in QObject::event(QEvent*) () at /usr/lib64/libQt5Core.so.5 #23 0x7f62b9b602ec in QApplicationPrivate::notify_helper(QObject*, QEvent*) () at /usr/lib64/libQt5Widgets.so.5 #24 0x7f62b9b65350 in QApplication::notify(QObject*, QEvent*) () at /usr/lib64/libQt5Widgets.so.5 #25 0x7f62b880db85 in QCoreApplication::notifyInternal(QObject*, QEvent*) () at /usr/lib64/libQt5Core.so.5 #26 0x7f62b880fa1f in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () at /usr/lib64/libQt5Core.so.5 #27 0x7f62b88659f3 in () at /usr/lib64/libQt5Core.so.5 #28 0x7f62b46e6a04 in g_main_context_dispatch () at /usr/lib64/libglib-2.0.so.0 #29 0x7f62b46e6c48 in () at /usr/lib64/libglib-2.0.so.0 #30 0x7f62b46e6cec in g_main_context_iteration () at /usr/lib64/libglib-2.0.so.0 #31 0x7f62b8864e6c in QEventDispatcherGlib::processEvents(QFlagsQEventLoop::ProcessEventsFlag) () at /usr/lib64/libQt5Core.so.5 #32 0x7f62b880baeb in QEventLoop::exec(QFlagsQEventLoop::ProcessEventsFlag) () at /usr/lib64/libQt5Core.so.5 #33 0x7f62b8813156 in QCoreApplication::exec() () at /usr/lib64/libQt5Core.so.5 #34 0x00432024 in main () -- Luca Beltrame - KDE Forums team KDE Science supporter GPG key ID: 6E1A4E79 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel Can you check if you still get this crash now? http://commits.kde.org/plasma-workspace/55bb013376c8688b74b5401587289b662fc5315b Aleix ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 121244: Remove workarounds we had for the nested event loops
On Nov. 25, 2014, 6:43 p.m., Marco Martin wrote: CMakeLists.txt, line 16 https://git.reviewboard.kde.org/r/121244/diff/1/?file=330671#file330671line16 unrelated commit? No, I just can't enforce 5.4 if Baloo is 5.2, so I moved it into a separate find_package call. - Aleix --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121244/#review70944 --- On Nov. 25, 2014, 6:33 p.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121244/ --- (Updated Nov. 25, 2014, 6:33 p.m.) Review request for Plasma. Repository: plasma-workspace Description --- Instead of keeping the state, expect the code to follow the order it's expected from it. Needs to bump the KF5 requirement to current KDeclarative (master), or it can run in problems. Diffs - CMakeLists.txt 7856833 shell/shellcorona.h 37f8b0e shell/shellcorona.cpp fd8e9b7 Diff: https://git.reviewboard.kde.org/r/121244/diff/ Testing --- Been running it for the last week. Thanks, Aleix Pol Gonzalez ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 121244: Remove workarounds we had for the nested event loops
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121244/ --- (Updated Nov. 25, 2014, 11:58 p.m.) Status -- This change has been marked as submitted. Review request for Plasma. Repository: plasma-workspace Description --- Instead of keeping the state, expect the code to follow the order it's expected from it. Needs to bump the KF5 requirement to current KDeclarative (master), or it can run in problems. Diffs - CMakeLists.txt 7856833 shell/shellcorona.h 37f8b0e shell/shellcorona.cpp fd8e9b7 Diff: https://git.reviewboard.kde.org/r/121244/diff/ Testing --- Been running it for the last week. Thanks, Aleix Pol Gonzalez ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [kde-promo] Plasma 5.1.1 announcement
Link has a typo. Plasma 5.1 http://kde.org/announcements/plasma5.1/index.php link is showing to : http://kde.org/announcements/plasma5.1/index.php on the other hand it must be : http://kde.org/announcements/plasma-5.1/index.php (The - is missing between plasma and 5.1 ) [image: Ömer Fadıl Usta on about.me] Ömer Fadıl Usta about.me/omerusta http://about.me/omerusta 2014-11-25 23:49 GMT+02:00 Albert Astals Cid aa...@kde.org: El Dimecres, 19 de novembre de 2014, a les 10:50:55, Ben Cooksley va escriure: On Wed, Nov 19, 2014 at 8:14 AM, Albert Astals Cid aa...@kde.org wrote: El Dimarts, 11 de novembre de 2014, a les 22:53:58, Albert Astals Cid va escriure: Hi guys, is there any reason https://www.kde.org/announcements/plasma-5.1.1.php says Plasma 5 was released in July and links to https://www.kde.org/announcements/plasma5.0/index.php instead of saying Plasma 5.1 was released in October and link to https://www.kde.org/announcements/plasma-5.1/index.php ? Was the announcement written by a ghost? Or is the person that wrote the announcement for Plasma 5.1.1 not subscribed to neither kde-promo nor plasma-devel? Anyway, if noone oposes i'll fix it to refer Plasma 5.1 instead of Plasma 5.0. I would recommend going ahead and making the change, Done. Albert I already had to fix the download urls for 5.1.1 which were broken. Cheers, Albert Thanks, Ben Cheers, Albert ___ This message is from the kde-promo mailing list. Visit https://mail.kde.org/mailman/listinfo/kde-promo to unsubscribe, set digest on or temporarily stop your subscription. ___ This message is from the kde-promo mailing list. Visit https://mail.kde.org/mailman/listinfo/kde-promo to unsubscribe, set digest on or temporarily stop your subscription. ___ This message is from the kde-promo mailing list. Visit https://mail.kde.org/mailman/listinfo/kde-promo to unsubscribe, set digest on or temporarily stop your subscription. ___ 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 121253: Fix password focus in lockscreen
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121253/#review70957 --- Ship it! Ship It! - Martin Gräßlin On Nov. 25, 2014, 11:44 p.m., Sebastian Kügler wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121253/ --- (Updated Nov. 25, 2014, 11:44 p.m.) Review request for Plasma. Repository: plasma-workspace Description --- Fix password focus in lockscreen When navigating the listview with the keyboard, the focus of the password field can get lost as it moves to the button. This patch reclaims the focus whenever the password field becomes visible. Diffs - lookandfeel/contents/lockscreen/LockScreen.qml 8a495ea208325ba3b2ef09efaef49515cc99830d Diff: https://git.reviewboard.kde.org/r/121253/diff/ Testing --- Navigated lockscreen with keyboard and mouse. Focus is handled correctly. Thanks, Sebastian Kügler ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: Stress testing KWin's screen handling
On Tuesday 25 November 2014 16:28:16 Daniel Vrátil wrote: On Tuesday 25 of November 2014 13:17:28 Martin Gräßlin wrote: Hi all, I spent some time on screen management in KWin today and got it to the point where it doesn't fail any more no matter what I try. So please everyone using multiple screens and especially dynamically plug in and out, please give a try to the patch set in [1]. Please ensure to have latest master as it contains a crash fix for a crash triggered by the patch set. Short summary of the changes in the patch set: * uses XRandR instead of QDesktopWidget * uses KWin internal information about overall screen geometry instead of relying on the information in the X11 screen structure. The second part is the code I added today. My testing showed that unplugging a screen gives us proper XRandR events so KWin's internal is up to date, but the X11 screen information is wrong. So when we partially used the one and partially the other the rendering was just horribly broken. Now it's all based on the KWin internal information and I couldn't get the rendering broken any more. When changing screens please be patient. It takes time to settle the changes. Especially plasmashell takes quite some time on my system to render correctly again. Coincidentally, I just merged my KScreen redesign, which should make this faster. sounds like I need to trigger kdesrc-build ;-) I hope that it doesn't fail for others and we can get the changes in to improve the situation. So far it's much better than before, but still it sometimes happens, that after screen reshuffle, window decorations get detached from the windows and moved elsewhere. It just happened to me, after plugging in the 3rd screen: http://pub.dvratil.cz/kwin-bug.ogv, but I'm not able to reliably reproduce this. ok, that still sounds like a rendering error. A few questions: * does qdus.org.kde.KWin /KWin supportInformation report correct screen information? * does xrandr report correct screen information? * does restarting compositing fix it? For three screens I'm completely out of testing possibilities. I don't have three screens and even if I had I would not be able to connect them. A kingdom, a kingdom for unit testing xrandr. 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
