[Breeze] [Bug 341762] When utilizing the Breeze theme for SDDM, it takes ages for SDDM to startup.
https://bugs.kde.org/show_bug.cgi?id=341762 --- Comment #10 from Raymond Wooninck <tittiatc...@gmail.com> --- Actually I haven't seen this for quite some time. Also with the changes that Plasma 5.8 will bring to the SDDM theme, the issue no longer occurs with me. -- You are receiving this mail because: You are the assignee for the bug.
[Differential] [Commented On] D2218: New logic for screen numbers in plasmashell
rwooninck added a comment. I have been using this patch for a couple of days now and I haven’t experienced issues anymore with the screens. Before the patch, I had the issue that despite the correct kscreen configuration, the panel would start on the wrong screen, etc. (This was then corrected by restarting plasmashell). Also from time to time I had the issue that one of the two screens would be completely black and no background or panel would be displayed. Both issues have no longer occurred, despite using three different setups (Single laptop screen, Home with external monitor as primary and laptop screen on the right, Work with external monitor as primary and laptop screen on the left). Everything works now as it should. REPOSITORY rPLASMAWORKSPACE Plasma Workspace REVISION DETAIL https://phabricator.kde.org/D2218 EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: mart, #plasma Cc: rwooninck, graesslin, plasma-devel, jensreuterberg, abetts, sebas ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Bluedevil frameworks merge?
On Tuesday, March 10, 2015 03:59:35 PM David Rosca wrote: Done. I have also updated branches in kde-build-metadata. David What about the libbluedevil framework branch ? Shouldn't this be merged as well into its master branch ? Regards Raymond ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 121710: Avoid risk of starting two kscreen_launchers at the same having race conditions
On Dec. 29, 2014, 1:55 a.m., Lukáš Tinkl wrote: Unfortunataly it doesn't fix it here, plasmashell starts with a blank screen. kquitapp5 plasmashell plasmashell brings it back Bhushan Shah wrote: Works for me.. :S which XRandr version you have? David Edmundson wrote: That's depressing to hear. I need some help on this; logs, traces, something as I can't reproduce here and this bug is super duper critical. Do you agree this change still makes sense though? Even if there is another problem it will be easier if there's one potential bug less. Unfortunately I seem to have hit a worse situation. kquitapp5 plasmashell does not work in my case as it just fails. Killing plasmashell and then starting it just delivers the same situation, a black screen with plasmashell running in the background and that is it. Starting plasmashell shows the following output: kscreen: launcherDataAvailable: org.kde.KScreen.Backend.XRandR kscreen: Launcher finished with exit code 1 , status 0 kscreen: Service for requested backend already running And yes I have a kscreen_backend_launcher process running, which is started by kded5. When I try to kill this one, kded5 is automatically restarting it. To be honest this patch makes things worse as that plasmashell is not starting at all. - Raymond --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121710/#review72655 --- On Dec. 28, 2014, 10:33 a.m., David Edmundson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121710/ --- (Updated Dec. 28, 2014, 10:33 a.m.) Review request for Plasma, Solid and Daniel Vrátil. Repository: libkscreen Description --- Avoid risk of starting two kscreen_launchers at the same having a race condition. There were three possible bugs: CheckIsAlreadyRunning tried to register a service and check if it worked. This could clash with another process checking at the same time. Causing them both to fail saying another is running Similarly, a daemon doing actual registering could clash with another daemon just checking if the name is free, and then it would fail saying we can't init() There was also a risk that two launchers pass the check that nothing is running, then both try to activate a session. DBus server handles this fine and one will gracefully fail. Without this patch the second launcher would just die without returning the path of the service that was activated causing the relevant app to do nothing. -- IMHO, you'd be better off having a fixed service name and using DBus activation for exactly these reasons. You could put the different backends at different object paths, and have a method on the root object that says which object path to use rather than using the stdout of a launcher. That's a discussion for another day though. Diffs - src/backendlauncher/backendloader.cpp e7da8cd src/backendlauncher/main.cpp f8bf323 Diff: https://git.reviewboard.kde.org/r/121710/diff/ Testing --- Send it to bshah. Plasmashell started for him. Previously it didn't. Thanks, David Edmundson ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 121710: Avoid risk of starting two kscreen_launchers at the same having race conditions
On Dec. 29, 2014, 1:55 a.m., Lukáš Tinkl wrote: Unfortunataly it doesn't fix it here, plasmashell starts with a blank screen. kquitapp5 plasmashell plasmashell brings it back Bhushan Shah wrote: Works for me.. :S which XRandr version you have? David Edmundson wrote: That's depressing to hear. I need some help on this; logs, traces, something as I can't reproduce here and this bug is super duper critical. Do you agree this change still makes sense though? Even if there is another problem it will be easier if there's one potential bug less. Raymond Wooninck wrote: Unfortunately I seem to have hit a worse situation. kquitapp5 plasmashell does not work in my case as it just fails. Killing plasmashell and then starting it just delivers the same situation, a black screen with plasmashell running in the background and that is it. Starting plasmashell shows the following output: kscreen: launcherDataAvailable: org.kde.KScreen.Backend.XRandR kscreen: Launcher finished with exit code 1 , status 0 kscreen: Service for requested backend already running And yes I have a kscreen_backend_launcher process running, which is started by kded5. When I try to kill this one, kded5 is automatically restarting it. To be honest this patch makes things worse as that plasmashell is not starting at all. Just forgot: raymond@HQVMT44011:~% xrandr --version xrandr program version 1.4.3 Server reports RandR version 1.4 - Raymond --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121710/#review72655 --- On Dec. 28, 2014, 10:33 a.m., David Edmundson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121710/ --- (Updated Dec. 28, 2014, 10:33 a.m.) Review request for Plasma, Solid and Daniel Vrátil. Repository: libkscreen Description --- Avoid risk of starting two kscreen_launchers at the same having a race condition. There were three possible bugs: CheckIsAlreadyRunning tried to register a service and check if it worked. This could clash with another process checking at the same time. Causing them both to fail saying another is running Similarly, a daemon doing actual registering could clash with another daemon just checking if the name is free, and then it would fail saying we can't init() There was also a risk that two launchers pass the check that nothing is running, then both try to activate a session. DBus server handles this fine and one will gracefully fail. Without this patch the second launcher would just die without returning the path of the service that was activated causing the relevant app to do nothing. -- IMHO, you'd be better off having a fixed service name and using DBus activation for exactly these reasons. You could put the different backends at different object paths, and have a method on the root object that says which object path to use rather than using the stdout of a launcher. That's a discussion for another day though. Diffs - src/backendlauncher/backendloader.cpp e7da8cd src/backendlauncher/main.cpp f8bf323 Diff: https://git.reviewboard.kde.org/r/121710/diff/ Testing --- Send it to bshah. Plasmashell started for him. Previously it didn't. Thanks, David Edmundson ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 121710: Avoid risk of starting two kscreen_launchers at the same having race conditions
On Dec. 29, 2014, 1:55 a.m., Lukáš Tinkl wrote: Unfortunataly it doesn't fix it here, plasmashell starts with a blank screen. kquitapp5 plasmashell plasmashell brings it back Bhushan Shah wrote: Works for me.. :S which XRandr version you have? David Edmundson wrote: That's depressing to hear. I need some help on this; logs, traces, something as I can't reproduce here and this bug is super duper critical. Do you agree this change still makes sense though? Even if there is another problem it will be easier if there's one potential bug less. Raymond Wooninck wrote: Unfortunately I seem to have hit a worse situation. kquitapp5 plasmashell does not work in my case as it just fails. Killing plasmashell and then starting it just delivers the same situation, a black screen with plasmashell running in the background and that is it. Starting plasmashell shows the following output: kscreen: launcherDataAvailable: org.kde.KScreen.Backend.XRandR kscreen: Launcher finished with exit code 1 , status 0 kscreen: Service for requested backend already running And yes I have a kscreen_backend_launcher process running, which is started by kded5. When I try to kill this one, kded5 is automatically restarting it. To be honest this patch makes things worse as that plasmashell is not starting at all. Raymond Wooninck wrote: Just forgot: raymond@HQVMT44011:~% xrandr --version xrandr program version 1.4.3 Server reports RandR version 1.4 Bhushan Shah wrote: kscreen: launcherDataAvailable: org.kde.KScreen.Backend.XRandR kscreen: Launcher finished with exit code 1 , status 0 kscreen: Service for requested backend already running I had same output but with this patch I am not getting that.. and plasmashell works for me fine. Ok. I dived a little deeper into the issues that I got (as that reverting the patch didn't help) and it appeared that I had to clean my config files. I deleted all the plasma* files/directories from .config and after this I was able to start plasmashell again. A new problem arose with the kcache files for the plasma theme, which caused plasma freezes. Deleting those made my installation happy and now I can boot normally and plasmashell is starting. Lukas, you might want to give this patch a try with a clean user, to see if it works. However it seems not to resolve the issue completely as that another person indicated that with a new user, he now gets the old issue despite that with his normal user everything works fine. - Raymond --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121710/#review72655 --- On Dec. 28, 2014, 10:33 a.m., David Edmundson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121710/ --- (Updated Dec. 28, 2014, 10:33 a.m.) Review request for Plasma, Solid and Daniel Vrátil. Repository: libkscreen Description --- Avoid risk of starting two kscreen_launchers at the same having a race condition. There were three possible bugs: CheckIsAlreadyRunning tried to register a service and check if it worked. This could clash with another process checking at the same time. Causing them both to fail saying another is running Similarly, a daemon doing actual registering could clash with another daemon just checking if the name is free, and then it would fail saying we can't init() There was also a risk that two launchers pass the check that nothing is running, then both try to activate a session. DBus server handles this fine and one will gracefully fail. Without this patch the second launcher would just die without returning the path of the service that was activated causing the relevant app to do nothing. -- IMHO, you'd be better off having a fixed service name and using DBus activation for exactly these reasons. You could put the different backends at different object paths, and have a method on the root object that says which object path to use rather than using the stdout of a launcher. That's a discussion for another day though. Diffs - src/backendlauncher/backendloader.cpp e7da8cd src/backendlauncher/main.cpp f8bf323 Diff: https://git.reviewboard.kde.org/r/121710/diff/ Testing --- Send it to bshah. Plasmashell started for him. Previously it didn't. Thanks, David Edmundson ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
[Breeze] [Bug 341762] When utilizing the Breeze theme for SDDM, it takes ages for SDDM to startup.
https://bugs.kde.org/show_bug.cgi?id=341762 Raymond Wooninck tittiatc...@gmail.com changed: What|Removed |Added Status|NEEDSINFO |UNCONFIRMED Resolution|WAITINGFORINFO |--- --- Comment #6 from Raymond Wooninck tittiatc...@gmail.com --- Hi Kai, I hope your didn't revert your patch because of this bug report. I am running the latest version from git, but still the same issue. So the revert didn't bring any relief in the startup time of SDDM -- 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
[Breeze] [Bug 341762] When utilizing the Breeze theme for SDDM, it takes ages for SDDM to startup.
https://bugs.kde.org/show_bug.cgi?id=341762 --- Comment #2 from Raymond Wooninck tittiatc...@gmail.com --- Created attachment 89915 -- https://bugs.kde.org/attachment.cgi?id=89915action=edit journalctl -b output with Breeze theme active for SDDM -- 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
[Breeze] [Bug 341762] When utilizing the Breeze theme for SDDM, it takes ages for SDDM to startup.
https://bugs.kde.org/show_bug.cgi?id=341762 Raymond Wooninck tittiatc...@gmail.com changed: What|Removed |Added Resolution|WAITINGFORINFO |--- Status|NEEDSINFO |UNCONFIRMED --- Comment #4 from Raymond Wooninck tittiatc...@gmail.com --- Hi David, The SDDM version that I am using is from git master and we are building it on openSUSE Build Service. I am part of the openSUSE KDE Community team and we are currently testing SDDM to see if we could make the same switch as Fedora from KDM to SDDM. I am using it in connection with a Frameworks/Plasma-next desktop. SDDM on openSUSE is started through the generic display-manager service. There are indications that we should switch to using separate services for each display-manager, but this has not yet done, so you might see display-manager in the journal logs. Running systemd-analyze blame delivers (top x lines) the following output: 1min 30.078s display-manager.service 560ms ModemManager.service 536ms systemd-tmpfiles-setup.service 500ms systemd-logind.service 499ms firewalld.service 447ms postfix.service 429ms plymouth-read-write.service 214ms mnt-windows.mount 159ms NetworkManager.service 67ms lvm2-activation-net.service 58ms systemd-fsck@dev-disk-by\x2duuid-a15e9da3\x2d0009\x2d4847\x2d978d\x2d34b3de059089.service 42ms alsa-restore.service 40ms avahi-daemon.service So I am not sure if the 1min 30secs is really the time required by SDDM or that it just indicates that a total boot time of 1 min is reached and that 30 secs is used for the display-manager. I have attached two journals (one with the maldives theme active and the other with the breeze theme). These are the full startup journals of the current session. I didn't filter them to prevent loosing information. -- 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
[Breeze] [Bug 341762] New: When utilizing the Breeze theme for SDDM, it takes ages for SDDM to startup.
https://bugs.kde.org/show_bug.cgi?id=341762 Bug ID: 341762 Summary: When utilizing the Breeze theme for SDDM, it takes ages for SDDM to startup. Product: Breeze Version: unspecified Platform: openSUSE RPMs OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: plasma-devel@kde.org Reporter: tittiatc...@gmail.com Due to the very nice integration with the rest of the desktop, I am using the Breeze theme for SDDM (created by David Edmundson). It looks way better than the default theme of SDDM, but it has one very big disadvantage. When the Breeze theme is active, it takes about 1,5 minute for SDDM to show its login screen. (Measured with systemd-analyze blame). Using the default theme for SDDM (Maui), then it only takes a fraction of a second and systemd-analyze blame doesn't even show a line for it. The only difference that I notice is that is feels that it takes longer for plasma to startup when using the Maui theme, then with the Breeze theme. However these few seconds still doesn't justify the 1,5 minutes startup for SDDM. Reproducible: Always -- 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
Re: bluedevil and bluez5
On Wednesday 05 November 2014 13:43:37 Sebastian Kügler wrote: On Wednesday 05 November 2014 12:34:32 Jonathan Riddell wrote: Ubuntu is wanting to move to bluez5, is bluedevil ready for this at all? Are there any plans for a KF5 release of bluedevil? Data point: I've been using bluedevil based on KF5 for a few weeks now, and other than one buildsystem issue ( https://git.reviewboard.kde.org/r/120974/ ) it seems to work just fine for me. But I guess the actual question is more if a real official release is planned for Bluedevil. The last release was only a RC that enabled bluez5 support, however we never saw any official release. As you indicate bluedevil works fine with Bluez5 and KF5, but it would be good if an official release could be either included in KDE Applications 14.12 or as a separate version (e.g. Bluedevil 2.0 ) ?? ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 118851: Kde-baseapps- KF5 replace generic soversion.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118851/#review60757 --- Hmm, now we seem to have a strange situation between KDE4 and KF5/PN. The latest version of libkonq with KDE4 is 5.14.0 (libkonq.so.5.14.0) with libkonq.so.5 pointing to it. With this change libkonq has a lower version (4.97.0; libkonq.so.4.97.0) with libkonq.so.5 pointing to it. This would mean that libkonq is no longer co-installable with its KDE4 version due to both using libkonq.so.5. Given that there must have been a reason in the past to use libkonq.so.5.14.0, I would suggest to move libkonq version to 5.97.0 and use libkonq.so.6. This would ensure co-instability and consistency in version numbering. - Raymond Wooninck On June 20, 2014, 8:14 p.m., Scarlett Clark wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118851/ --- (Updated June 20, 2014, 8:14 p.m.) Review request for Dolphin, KDE Base Apps, Plasma, and Jonathan Riddell. Repository: kde-baseapps Description --- I was ending up with so.SOVERSION when building this, so through some research I have come up with this patch to correct the issue. If there is a better way, please let me know. Diffs - CMakeLists.txt a5588ea dolphin/src/CMakeLists.txt ce629fb lib/konq/CMakeLists.txt 6857e19 Diff: https://git.reviewboard.kde.org/r/118851/diff/ Testing --- Builds fine on Kubuntu Utopic frameworks chroot. Results in the expected: libdolphinprivate.so libdolphinprivate.so.4.97.0 libdolphinprivate.so.5 libkdeinit5_dolphin.so libkonq.so libkonq.so.4.97.0 libkonq.so.5 Thanks, Scarlett Clark ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: reflecting on 4.10
On Saturday 12 January 2013 08:36:52 Martin Gräßlin wrote: OpenSUSE has KDE:Unstable:SC which is made up of (regularly) updated snapshots of current git master. yes, but you cannot install it into a different directory AFAIK. It overwrites your stable installation. Hi Martin, This is indeed correct. In the past we had different directories for KDE3 and KDE4, so that both could be installed without overwriting. Maybe we should do a similar thing again with the KDE:Unstable:SC repository. The only worry that I have is what to do if current git master requires a higher version of a non-KDE library than stable. But I guess we can sort this out. Regards Raymond ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
PopupApplet with Qml/JS broken
Hi, There is a new applet (based on QML) which shows a nice lancelot-a-like menu, however it has issues with being a PopupApplet. If it is defined as PopupApplet, according to the definitions, then it shows the menu itself in the taskbar. This seems to be the exact issue as also indicated earlier in : http://mail.kde.org/pipermail/plasma-devel/2011-April/015809.html Was there any progress on this issue ? Or was this resolved in kdelibs master, which will not be shipped with KDE 4.8 ? Thanks. Regards Raymond ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: PopupApplet with Qml/JS broken
On Thursday 20 October 2011 10:51:51 Marco Martin wrote: in the main item eproprt property int minimumWidth: 300 property int minimumHeight: 400 or any other number needed (if dynamically calculated even better) Thanks. This resolved the issue. I will indicated this to the author. Regards Raymond ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
