11:13 p.m.
Is 40 really /expected/ to ship with 6.0 /and/ no Xorg, or is its presence in
Rawhide at this point really intended for attracting guinea pigs? Normally I do
upgrades from current to Rawhide on several PCs shortly before branch to be part
of the pre-release testing process, but I don't know if it's possible to be worth
the bother this cycle.
--
Evolution as taught in public schools is, like religion,
based on faith, not based on science.
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata
9:01 a.m.
On Sat, Jan 27, 2024 at 12:13 AM Felix Miata <mrmazda(a)earthlink.net> wrote:
Is 40 really /expected/ to ship with 6.0 /and/ no Xorg, or is its presence in
Rawhide at this point really intended for attracting guinea pigs? Normally I do
upgrades from current to Rawhide on several PCs shortly before branch to be part
of the pre-release testing process, but I don't know if it's possible to be
worth
the bother this cycle.
Yes, it is really expected to ship this way. KDE upstream is doing a
lot to ensure Plasma 6.0 is great for regular use. Unlike previous
major releases, we've had development snapshots in good shape since
September, and Fedora has had the stack since early November. We've
been dogfooding it and getting things fixed before even the first beta
release, and the extended test cycle with multiple betas and release
candidates are intended to ensure things are in the best shape
possible.
Nearly all of us in the KDE SIG are running it as secondaries or daily
drivers now, and the experience has been very promising!
We've also scheduled a test week next week:
https://fedoramagazine.org/contribute-at-the-kde-plasma-6-test-week/
--
真実はいつも一つ！/ Always, there's only one truth!
10:05 a.m.
On Sat, 2024-01-27 at 10:01 -0500, Neal Gompa wrote:
On Sat, Jan 27, 2024 at 12:13 AM Felix Miata
<mrmazda(a)earthlink.net>
wrote:
>
> Is 40 really /expected/ to ship with 6.0 /and/ no Xorg, or is its
> presence in
> Rawhide at this point really intended for attracting guinea pigs?
> Normally I do
> upgrades from current to Rawhide on several PCs shortly before
> branch to be part
> of the pre-release testing process, but I don't know if it's
> possible to be worth
> the bother this cycle.
Yes, it is really expected to ship this way. KDE upstream is doing a
lot to ensure Plasma 6.0 is great for regular use. Unlike previous
major releases, we've had development snapshots in good shape since
September, and Fedora has had the stack since early November. We've
been dogfooding it and getting things fixed before even the first
beta
release, and the extended test cycle with multiple betas and release
candidates are intended to ensure things are in the best shape
possible.
Nearly all of us in the KDE SIG are running it as secondaries or
daily
drivers now, and the experience has been very promising!
We've also scheduled a test week next week:
https://fedoramagazine.org/contribute-at-the-kde-plasma-6-test-week/
Well many people (included me ) requested to not drop xorg and you
don't listen , I use Fedora to work not to test new features , I hope
that I haven't to fork all Fedora to keep xorg alive until F39 EOL .
--
Sérgio M. B.
10:34 a.m.
On Sat, 2024-01-27 at 16:05 +0000, Sérgio Basto wrote:
use Fedora to work not to test new features , I hope
that I haven't to fork all Fedora to keep xorg alive until F39 EOL
I currently use Xorg but will try to adapt to Wayland, even though it
still doesn't properly support session save/restore.
However, saying you use Fedora for work and not for testing new
features seems to me to be in contradiction to what Fedora is about.
It's a distro *designed* for frequent updates and testing. If you want
stability, there are plenty of other options.
poc
3:54 p.m.
On 1/27/24 11:34, Patrick O'Callaghan wrote:
On Sat, 2024-01-27 at 16:05 +0000, Sérgio Basto wrote:
> use Fedora to work not to test new features , I hope
> that I haven't to fork all Fedora to keep xorg alive until F39 EOL
I currently use Xorg but will try to adapt to Wayland, even though it
still doesn't properly support session save/restore.
However, saying you use Fedora for work and not for testing new
features seems to me to be in contradiction to what Fedora is about.
It's a distro *designed* for frequent updates and testing.
I think the worry is that Fedora sometimes goes too far in that
direction. It's one thing to release cutting-edge but reasonably stable
software. It's another to release software that simply doesn't work
properly. What's the point of that? Not many people have the time to
'test' software *instead of* getting their work done. Surely Fedora
isn't targeted at that tiny minority.
If LyX 2.4.0 with, say, Qt 5 had the kinds of problems that KDE on
Wayland has had, you can be sure we wouldn't release it into the wild,
let alone make it work *only* with Qt 5.
Riki
5:16 p.m.
On 1/27/24 1:54 PM, Richard Kimberly Heck wrote:
On 1/27/24 11:34, Patrick O'Callaghan wrote:
> On Sat, 2024-01-27 at 16:05 +0000, Sérgio Basto wrote:
>> use Fedora to work not to test new features , I hope
>> that I haven't to fork all Fedora to keep xorg alive until F39 EOL
> I currently use Xorg but will try to adapt to Wayland, even though it
> still doesn't properly support session save/restore.
>
> However, saying you use Fedora for work and not for testing new
> features seems to me to be in contradiction to what Fedora is about.
> It's a distro *designed* for frequent updates and testing.
I think the worry is that Fedora sometimes goes too far in that direction. It's one
thing to release cutting-edge but reasonably stable software. It's another to release
software that simply doesn't work properly. What's the point of that? Not many
people have the time to 'test' software *instead of* getting their work done.
Surely Fedora isn't targeted at that tiny minority.
If LyX 2.4.0 with, say, Qt 5 had the kinds of problems that KDE on Wayland has had, you
can be sure we wouldn't release it into the wild, let alone make it work *only* with
Qt 5.
Riki
--
_______________________________________________
kde mailing list -- kde(a)lists.fedoraproject.org
To unsubscribe send an email to kde-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kde@lists.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Even with the latest upgrades to Fedora 39, I am still having issues with Zoom on
wayland. I cannot operate day to day without zoom working.
Unless and until that is resolved, eliminating wayland is a serious blocker.
Emmett
5:39 p.m.
On Sat, Jan 27, 2024 at 6:16 PM Emmett Culley
<lst_manage(a)webengineer.com> wrote:
Even with the latest upgrades to Fedora 39, I am still having issues with Zoom on
wayland. I cannot operate day to day without zoom working.
Unless and until that is resolved, eliminating wayland is a serious blocker.
This has been sort-of resolved in Zoom for well over two years.
The trick is to copy the Zoom desktop file from
/usr/share/applications to ~/.local/share/applications and edit the
new copy to change the Exec line to the following:
Exec=XDG_CURRENT_DESKTOP=GNOME /usr/bin/zoom %U
Once Plasma picks up the updated desktop file, it will let you
screenshare on Wayland just fine when you launch it.
You can also test this by simply doing this from the command line:
$ XDG_CURRENT_DESKTOP=GNOME zoom &
(I pushed Zoom to fix it to work with portals years ago, but I
couldn't get them to get rid of the artificial blocker...)
--
真実はいつも一つ！/ Always, there's only one truth!
9:56 a.m.
On 1/27/24 3:39 PM, Neal Gompa wrote:
On Sat, Jan 27, 2024 at 6:16 PM Emmett Culley
<lst_manage(a)webengineer.com> wrote:
>
> Even with the latest upgrades to Fedora 39, I am still having issues with Zoom on
wayland. I cannot operate day to day without zoom working.
>
> Unless and until that is resolved, eliminating wayland is a serious blocker.
This has been sort-of resolved in Zoom for well over two years.
The trick is to copy the Zoom desktop file from
/usr/share/applications to ~/.local/share/applications and edit the
new copy to change the Exec line to the following:
Exec=XDG_CURRENT_DESKTOP=GNOME /usr/bin/zoom %U
Once Plasma picks up the updated desktop file, it will let you
screenshare on Wayland just fine when you launch it.
You can also test this by simply doing this from the command line:
$ XDG_CURRENT_DESKTOP=GNOME zoom &
(I pushed Zoom to fix it to work with portals years ago, but I
couldn't get them to get rid of the artificial blocker...)
That seems to fix the issue. Thanks for that. Though I use KDE and so set it
=KDE.
Emmett
10:01 a.m.
On Sun, Jan 28, 2024 at 3:56 PM Emmett Culley
<lst_manage(a)webengineer.com> wrote:
On 1/27/24 3:39 PM, Neal Gompa wrote:
> On Sat, Jan 27, 2024 at 6:16 PM Emmett Culley
> <lst_manage(a)webengineer.com> wrote:
>>
>> Even with the latest upgrades to Fedora 39, I am still having issues with Zoom
on wayland. I cannot operate day to day without zoom working.
>>
>> Unless and until that is resolved, eliminating wayland is a serious blocker.
>
> This has been sort-of resolved in Zoom for well over two years.
>
> The trick is to copy the Zoom desktop file from
> /usr/share/applications to ~/.local/share/applications and edit the
> new copy to change the Exec line to the following:
>
> Exec=XDG_CURRENT_DESKTOP=GNOME /usr/bin/zoom %U
>
> Once Plasma picks up the updated desktop file, it will let you
> screenshare on Wayland just fine when you launch it.
>
> You can also test this by simply doing this from the command line:
>
> $ XDG_CURRENT_DESKTOP=GNOME zoom &
>
> (I pushed Zoom to fix it to work with portals years ago, but I
> couldn't get them to get rid of the artificial blocker...)
>
>
>
That seems to fix the issue. Thanks for that. Though I use KDE and so set it =KDE.
The point is that Zoom needs to be lied to about which desktop you are
using in order to access the desktop-agnostic API.
--
真実はいつも一つ！/ Always, there's only one truth!
12:12 p.m.
On 1/28/24 8:01 AM, Neal Gompa wrote:
On Sun, Jan 28, 2024 at 3:56 PM Emmett Culley
<lst_manage(a)webengineer.com> wrote:
>
> On 1/27/24 3:39 PM, Neal Gompa wrote:
>> On Sat, Jan 27, 2024 at 6:16 PM Emmett Culley
>> <lst_manage(a)webengineer.com> wrote:
>>>
>>> Even with the latest upgrades to Fedora 39, I am still having issues with
Zoom on wayland. I cannot operate day to day without zoom working.
>>>
>>> Unless and until that is resolved, eliminating wayland is a serious
blocker.
>>
>> This has been sort-of resolved in Zoom for well over two years.
>>
>> The trick is to copy the Zoom desktop file from
>> /usr/share/applications to ~/.local/share/applications and edit the
>> new copy to change the Exec line to the following:
>>
>> Exec=XDG_CURRENT_DESKTOP=GNOME /usr/bin/zoom %U
>>
>> Once Plasma picks up the updated desktop file, it will let you
>> screenshare on Wayland just fine when you launch it.
>>
>> You can also test this by simply doing this from the command line:
>>
>> $ XDG_CURRENT_DESKTOP=GNOME zoom &
>>
>> (I pushed Zoom to fix it to work with portals years ago, but I
>> couldn't get them to get rid of the artificial blocker...)
>>
>>
>>
> That seems to fix the issue. Thanks for that. Though I use KDE and so set it
=KDE.
>
The point is that Zoom needs to be lied to about which desktop you are
using in order to access the desktop-agnostic API.
I wonder how many others simply go back to xorg when their zoom doesn't work.
I did for quite a while, until it started to look like that wouldn't be a choice
pretty soon.
There will be a lot of complaints when only wayland is available. Maybe that'll get
zoom in gear to fix it.
Emmett
12:41 p.m.
On Sun, Jan 28, 2024 at 6:12 PM Emmett Culley
<lst_manage(a)webengineer.com> wrote:
On 1/28/24 8:01 AM, Neal Gompa wrote:
> On Sun, Jan 28, 2024 at 3:56 PM Emmett Culley
> <lst_manage(a)webengineer.com> wrote:
>>
>> On 1/27/24 3:39 PM, Neal Gompa wrote:
>>> On Sat, Jan 27, 2024 at 6:16 PM Emmett Culley
>>> <lst_manage(a)webengineer.com> wrote:
>>>>
>>>> Even with the latest upgrades to Fedora 39, I am still having issues
with Zoom on wayland. I cannot operate day to day without zoom working.
>>>>
>>>> Unless and until that is resolved, eliminating wayland is a serious
blocker.
>>>
>>> This has been sort-of resolved in Zoom for well over two years.
>>>
>>> The trick is to copy the Zoom desktop file from
>>> /usr/share/applications to ~/.local/share/applications and edit the
>>> new copy to change the Exec line to the following:
>>>
>>> Exec=XDG_CURRENT_DESKTOP=GNOME /usr/bin/zoom %U
>>>
>>> Once Plasma picks up the updated desktop file, it will let you
>>> screenshare on Wayland just fine when you launch it.
>>>
>>> You can also test this by simply doing this from the command line:
>>>
>>> $ XDG_CURRENT_DESKTOP=GNOME zoom &
>>>
>>> (I pushed Zoom to fix it to work with portals years ago, but I
>>> couldn't get them to get rid of the artificial blocker...)
>>>
>>>
>>>
>> That seems to fix the issue. Thanks for that. Though I use KDE and so set it
=KDE.
>>
>
> The point is that Zoom needs to be lied to about which desktop you are
> using in order to access the desktop-agnostic API.
>
>
>
I wonder how many others simply go back to xorg when their zoom doesn't work. I did
for quite a while, until it started to look like that wouldn't be a choice pretty
soon.
There will be a lot of complaints when only wayland is available. Maybe that'll get
zoom in gear to fix it.
I can only hope! I know that this change has motivated a lot of
applications to start figuring things out when they wouldn't before.
So, yeah. :)
--
真実はいつも一つ！/ Always, there's only one truth!
3:20 p.m.
I find the mouse response on wayland to be totally terrible. Lagging far
behind the movement.
Anyone else?
11:24 p.m.
On Sat, Jan 27, 2024 at 6:41 PM Neal Gompa <ngompa13(a)gmail.com> wrote:
On Sat, Jan 27, 2024 at 6:16 PM Emmett Culley
<lst_manage(a)webengineer.com> wrote:
>
> Even with the latest upgrades to Fedora 39, I am still having issues with Zoom on
wayland. I cannot operate day to day without zoom working.
>
> Unless and until that is resolved, eliminating wayland is a serious blocker.
This has been sort-of resolved in Zoom for well over two years.
The trick is to copy the Zoom desktop file from
/usr/share/applications to ~/.local/share/applications and edit the
new copy to change the Exec line to the following:
Exec=XDG_CURRENT_DESKTOP=GNOME /usr/bin/zoom %U
This does not appear to work. The share dialog comes up empty.
Running with QT_QPA_PLATFORM=xcb does work, and allows sharing.
I've been running Wayland full-time with KDE/Plasma for a little more
than 2 years now, and this is one of only three applications that
gives me trouble. Plus rofi that can't do windows switching (maybe
someday KDE will support wlr-foreign-toplevel-management, or some
other mechanism to query active windows and things like that?)
Fully patched F39, zoom-5.17.5
-Adam Batkin
11:35 p.m.
On Mon, Jan 29, 2024 at 5:24 AM Adam Batkin <adam(a)batkin.net> wrote:
On Sat, Jan 27, 2024 at 6:41 PM Neal Gompa <ngompa13(a)gmail.com> wrote:
>
> On Sat, Jan 27, 2024 at 6:16 PM Emmett Culley
> <lst_manage(a)webengineer.com> wrote:
> >
> > Even with the latest upgrades to Fedora 39, I am still having issues with Zoom
on wayland. I cannot operate day to day without zoom working.
> >
> > Unless and until that is resolved, eliminating wayland is a serious blocker.
>
> This has been sort-of resolved in Zoom for well over two years.
>
> The trick is to copy the Zoom desktop file from
> /usr/share/applications to ~/.local/share/applications and edit the
> new copy to change the Exec line to the following:
>
> Exec=XDG_CURRENT_DESKTOP=GNOME /usr/bin/zoom %U
This does not appear to work. The share dialog comes up empty.
Running with QT_QPA_PLATFORM=xcb does work, and allows sharing.
I've been running it this way since the support was added in Zoom
5.10. If you have enableWaylandShare=true in your zoom config, then it will
fail without the XDG_CURRENT_DESKTOP lie saying your environment is
not compatible. Sometimes you may also need to force PipeWire as a
backend.
All of these are kindly documented by the Arch folks:
https://wiki.archlinux.org/title/Zoom_Meetings#Wayland
I've been running Wayland full-time with KDE/Plasma for a little
more
than 2 years now, and this is one of only three applications that
gives me trouble. Plus rofi that can't do windows switching (maybe
someday KDE will support wlr-foreign-toplevel-management, or some
other mechanism to query active windows and things like that?)
Please file a bug to ask for support in KWin:
https://bugs.kde.org/enter_bug.cgi?product=kwin&component=wayland-gen...
--
真実はいつも一つ！/ Always, there's only one truth!
7:39 a.m.
Running Plasma 5.27.10 Wayland and just followed your directions and tested
the screenshare capability and had zero issues with it sharing the screen.
It works. Thanks for that.
John Pierce
On Sun, Jan 28, 2024 at 11:35 PM Neal Gompa <ngompa13(a)gmail.com> wrote:
On Mon, Jan 29, 2024 at 5:24 AM Adam Batkin <adam(a)batkin.net>
wrote:
>
> On Sat, Jan 27, 2024 at 6:41 PM Neal Gompa <ngompa13(a)gmail.com> wrote:
> >
> > On Sat, Jan 27, 2024 at 6:16 PM Emmett Culley
> > <lst_manage(a)webengineer.com> wrote:
> > >
> > > Even with the latest upgrades to Fedora 39, I am still having issues
with Zoom on wayland. I cannot operate day to day without zoom working.
> > >
> > > Unless and until that is resolved, eliminating wayland is a serious
blocker.
> >
> > This has been sort-of resolved in Zoom for well over two years.
> >
> > The trick is to copy the Zoom desktop file from
> > /usr/share/applications to ~/.local/share/applications and edit the
> > new copy to change the Exec line to the following:
> >
> > Exec=XDG_CURRENT_DESKTOP=GNOME /usr/bin/zoom %U
>
> This does not appear to work. The share dialog comes up empty.
>
> Running with QT_QPA_PLATFORM=xcb does work, and allows sharing.
>
I've been running it this way since the support was added in Zoom
5.10. If you have enableWaylandShare=true in your zoom config, then it will
fail without the XDG_CURRENT_DESKTOP lie saying your environment is
not compatible. Sometimes you may also need to force PipeWire as a
backend.
All of these are kindly documented by the Arch folks:
https://wiki.archlinux.org/title/Zoom_Meetings#Wayland
> I've been running Wayland full-time with KDE/Plasma for a little more
> than 2 years now, and this is one of only three applications that
> gives me trouble. Plus rofi that can't do windows switching (maybe
> someday KDE will support wlr-foreign-toplevel-management, or some
> other mechanism to query active windows and things like that?)
>
Please file a bug to ask for support in KWin:
https://bugs.kde.org/enter_bug.cgi?product=kwin&component=wayland-gen...
--
真実はいつも一つ！/ Always, there's only one truth!
--
_______________________________________________
kde mailing list -- kde(a)lists.fedoraproject.org
To unsubscribe send an email to kde-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kde@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
7:42 a.m.
On 1/29/24 00:35, Neal Gompa wrote:
I've been running it this way since the support was added in
Zoom
5.10. If you have enableWaylandShare=true in your zoom config, then it will
fail without the XDG_CURRENT_DESKTOP lie saying your environment is
not compatible. Sometimes you may also need to force PipeWire as a
backend.
All of these are kindly documented by the Arch folks:
https://wiki.archlinux.org/title/Zoom_Meetings#Wayland
That worked, thank you! I didn't know that I also needed to manually
edit zoomus.conf (and in my case, manually tell it to use Pipewire as
the screen capture mode).
For future reference, in early 2024, I was able to get screen sharing in
Zoom working on a fully-patched Fedora KDE/Plasma system by making the
following 3 changes:
* Run Zoom with an extra environment variable: XDG_CURRENT_DESKTOP=GNOME
* Edit ~/.config/zoomus.conf and set enableWaylandShare=true * Within
the application, Settings -> Screen share -> Advanced -> Screen capture
mode on Wayland to "Pipewire Mode"
> I've been running Wayland full-time with KDE/Plasma for a
little more
> than 2 years now, and this is one of only three applications that
> gives me trouble. Plus rofi that can't do windows switching (maybe
> someday KDE will support wlr-foreign-toplevel-management, or some
> other mechanism to query active windows and things like that?)
>
Please file a bug to ask for support in KWin:
https://bugs.kde.org/enter_bug.cgi?product=kwin&component=wayland-gen...
I may, though I'm very surprised no one else has already done so.
Meanwhile, in looking into the rofi Wayland fork, I somehow stumbled
upon this: https://wayland.app/protocols/kde-plasma-window-management,
which looks perfect, except for the caveat "Only one client can bind
this interface at a time." (which may make it completely useless).
Anyway, thank you for the Zoom tip, that's exactly what I needed,
-Adam Batkin
8:24 a.m.
On Mon, Jan 29, 2024 at 1:43 PM Adam Batkin <adam(a)batkin.net> wrote:
On 1/29/24 00:35, Neal Gompa wrote:
I've been running it this way since the support was added in Zoom
5.10. If you have enableWaylandShare=true in your zoom config, then it will
fail without the XDG_CURRENT_DESKTOP lie saying your environment is
not compatible. Sometimes you may also need to force PipeWire as a
backend.
All of these are kindly documented by the Arch folks:
https://wiki.archlinux.org/title/Zoom_Meetings#Wayland
That worked, thank you! I didn't know that I also needed to manually edit zoomus.conf
(and in my case, manually tell it to use Pipewire as the screen capture mode).
For future reference, in early 2024, I was able to get screen sharing in Zoom working on
a fully-patched Fedora KDE/Plasma system by making the following 3 changes:
* Run Zoom with an extra environment variable: XDG_CURRENT_DESKTOP=GNOME * Edit
~/.config/zoomus.conf and set enableWaylandShare=true * Within the application, Settings
-> Screen share -> Advanced -> Screen capture mode on Wayland to "Pipewire
Mode"
Maybe contribute a quick doc so everyone else can easily find it?
https://docs.fedoraproject.org/en-US/quick-docs/
I've been running Wayland full-time with KDE/Plasma for a little
more
than 2 years now, and this is one of only three applications that
gives me trouble. Plus rofi that can't do windows switching (maybe
someday KDE will support wlr-foreign-toplevel-management, or some
other mechanism to query active windows and things like that?)
Please file a bug to ask for support in KWin:
https://bugs.kde.org/enter_bug.cgi?product=kwin&component=wayland-gen...
I may, though I'm very surprised no one else has already done so. Meanwhile, in
looking into the rofi Wayland fork, I somehow stumbled upon this:
https://wayland.app/protocols/kde-plasma-window-management, which looks perfect, except
for the caveat "Only one client can bind this interface at a time." (which may
make it completely useless).
It seems everyone assumes someone else has already done it, so it
never gets filed. :P
Anyway, thank you for the Zoom tip, that's exactly what I
needed,
You're welcome! :)
--
真実はいつも一つ！/ Always, there's only one truth!
5:55 p.m.
On Sat, Jan 27, 2024 at 6:16 PM Emmett Culley <lst_manage(a)webengineer.com>
wrote:
On 1/27/24 1:54 PM, Richard Kimberly Heck wrote:
> On 1/27/24 11:34, Patrick O'Callaghan wrote:
>> On Sat, 2024-01-27 at 16:05 +0000, Sérgio Basto wrote:
>>> use Fedora to work not to test new features , I hope
>>> that I haven't to fork all Fedora to keep xorg alive until F39 EOL
>> I currently use Xorg but will try to adapt to Wayland, even though it
>> still doesn't properly support session save/restore.
>>
>> However, saying you use Fedora for work and not for testing new
>> features seems to me to be in contradiction to what Fedora is about.
>> It's a distro *designed* for frequent updates and testing.
>
> I think the worry is that Fedora sometimes goes too far in that
direction. It's one thing to release cutting-edge but reasonably stable
software. It's another to release software that simply doesn't work
properly. What's the point of that? Not many people have the time to 'test'
software *instead of* getting their work done. Surely Fedora isn't targeted
at that tiny minority.
Fedora is a cutting edge distro, specifically for testing and development
of upstream software. If you want a daily production OS then you should
change to Red Hat Enterprise Desktop, Debian or SUSE. There are many
production oriented distros available. I happen to prefer SUSE Linux
Enterprise Desktop! I do not care much for Red Hat Enterprise
Desktop's GUI. It is not GNOME 2 and it is not GNOME 3, what is it? SUSE
has KDE in addition to GNOME and I prefer KDE.
> If LyX 2.4.0 with, say, Qt 5 had the kinds of problems that KDE on
Wayland has had, you can be sure we wouldn't release it into the wild, let
alone make it work *only* with Qt 5.
>
> Riki
>
>
> --
> _______________________________________________
> kde mailing list -- kde(a)lists.fedoraproject.org
> To unsubscribe send an email to kde-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/kde@lists.fedoraproject.org
> Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Even with the latest upgrades to Fedora 39, I am still having issues with
Zoom on wayland. I cannot operate day to day without zoom working.
Unless and until that is resolved, eliminating wayland is a serious
blocker.
Emmett
--
_______________________________________________
kde mailing list -- kde(a)lists.fedoraproject.org
To unsubscribe send an email to kde-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kde@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
⠈⠳⣄⠀⠀
8:05 p.m.
On 1/27/24 15:55, Timothy M Butterworth wrote:
Fedora is a cutting edge distro, specifically for testing and
development of upstream software. If you want a daily production OS then
you should change to Red Hat Enterprise Desktop, Debian or SUSE. There
are many production oriented distros available. I happen to prefer SUSE
Linux Enterprise Desktop! I do not care much for Red Hat Enterprise
Desktop's GUI. It is not GNOME 2 and it is not GNOME 3, what is it? SUSE
has KDE in addition to GNOME and I prefer KDE.
Once upon a time, CentOS was that stable production-oriented system.
--
Michael Eager
3:25 p.m.
On 1/27/24 21:05, Michael Eager wrote:
On 1/27/24 15:55, Timothy M Butterworth wrote:
> Fedora is a cutting edge distro, specifically for testing and
> development of upstream software. If you want a daily production OS
> then you should change to Red Hat Enterprise Desktop, Debian or SUSE.
> There are many production oriented distros available. I happen to
> prefer SUSE Linux Enterprise Desktop! I do not care much for Red Hat
> Enterprise Desktop's GUI. It is not GNOME 2 and it is not GNOME 3,
> what is it? SUSE has KDE in addition to GNOME and I prefer KDE.
Once upon a time, CentOS was that stable production-oriented system.
CERN has decided to do their own LINUX after the change to
CENTOS-stream. After the adventures wit Scientific LINUX we will see how
that goes.
KDE is claiming that they are the only support for X11. What are the
others going to do?
10:06 a.m.
On 1/27/24 18:55, Timothy M Butterworth wrote:
On Sat, Jan 27, 2024 at 6:16 PM Emmett Culley
<lst_manage(a)webengineer.com> wrote:
On 1/27/24 1:54 PM, Richard Kimberly Heck wrote:
> On 1/27/24 11:34, Patrick O'Callaghan wrote:
>> On Sat, 2024-01-27 at 16:05 +0000, Sérgio Basto wrote:
>>> use Fedora to work not to test new features , I hope
>>> that I haven't to fork all Fedora to keep xorg alive until F39 EOL
>> I currently use Xorg but will try to adapt to Wayland, even
though it
>> still doesn't properly support session save/restore.
>>
>> However, saying you use Fedora for work and not for testing new
>> features seems to me to be in contradiction to what Fedora is
about.
>> It's a distro *designed* for frequent updates and testing.
>
> I think the worry is that Fedora sometimes goes too far in that
direction. It's one thing to release cutting-edge but reasonably
stable software. It's another to release software that simply
doesn't work properly. What's the point of that? Not many people
have the time to 'test' software *instead of* getting their work
done. Surely Fedora isn't targeted at that tiny minority.
Fedora is a cutting edge distro, specifically for testing and
development of upstream software. If you want a daily production OS
then you should change to Red Hat Enterprise Desktop, Debian or SUSE.
There are many production oriented distros available. I happen to
prefer SUSE Linux Enterprise Desktop! I do not care much for Red Hat
Enterprise Desktop's GUI. It is not GNOME 2 and it is not GNOME 3,
what is it? SUSE has KDE in addition to GNOME and I prefer KDE.
SUSE going to Wayland or are they forking KDE?
11:44 a.m.
Robert McBroom composed on 2024-02-01 11:06 (UTC-0500):
SUSE going to Wayland or are they forking KDE?
TW currently has X.Org v: 21.1.11 and KDE Plasma v: 5.27.10. Forcing Wayland has
not been announced that I'm aware of. Leap is still on 21.1.4 and 5.27.9.
--
Evolution as taught in public schools is, like religion,
based on faith, not based on science.
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata
5:20 p.m.
On Thu, 2024-02-01 at 11:06 -0500, Robert McBroom wrote:
On 1/27/24 18:55, Timothy M Butterworth wrote:
>
>
>
>
>
>
>
> On Sat, Jan 27, 2024 at 6:16 PM Emmett Culley
> <lst_manage(a)webengineer.com> wrote:
>
> > On 1/27/24 1:54 PM, Richard Kimberly Heck wrote:
> > > On 1/27/24 11:34, Patrick O'Callaghan wrote:
> > >> On Sat, 2024-01-27 at 16:05 +0000, Sérgio Basto wrote:
> > >>> use Fedora to work not to test new features , I hope
> > >>> that I haven't to fork all Fedora to keep xorg alive until
> > F39 EOL
> > >> I currently use Xorg but will try to adapt to Wayland, even
> > though it
> > >> still doesn't properly support session save/restore.
> > >>
> > >> However, saying you use Fedora for work and not for testing
> > new
> > >> features seems to me to be in contradiction to what Fedora is
> > about.
> > >> It's a distro *designed* for frequent updates and testing.
> > >
> > > I think the worry is that Fedora sometimes goes too far in that
> > direction. It's one thing to release cutting-edge but reasonably
> > stable software. It's another to release software that simply
> > doesn't work properly. What's the point of that? Not many people
> > have the time to 'test' software *instead of* getting their work
> > done. Surely Fedora isn't targeted at that tiny minority.
> >
>
>
>
>
> Fedora is a cutting edge distro, specifically for testing and
> development of upstream software. If you want a daily production OS
> then you should change to Red Hat Enterprise Desktop, Debian or
> SUSE. There are many production oriented distros available. I
> happen to prefer SUSE Linux Enterprise Desktop! I do not care much
> for Red Hat Enterprise Desktop's GUI. It is not GNOME 2 and it is
> not GNOME 3, what is it? SUSE has KDE in addition to GNOME and I
> prefer KDE.
>
>
>
>
>
>
>
>
> >
> >
>
>
>
SUSE going to Wayland or are they forking KDE?
To enable kwin-x11 on Fedora Rawhide is just set %bcond to 1 on
kwin.spec [1] and on plasma-workspace.spec [2] ,
KDE SIG for our own good, had the work of disable it. You can check by
yourself if you don't believe it .
[1]
https://src.fedoraproject.org/rpms/kwin/blob/rawhide/f/kwin.spec#_2
[2]
https://src.fedoraproject.org/rpms/plasma-workspace/blob/rawhide/f/plasma...
--
Sérgio M. B.
10:42 a.m.
On Sat, 2024-01-27 at 16:34 +0000, Patrick O'Callaghan wrote:
On Sat, 2024-01-27 at 16:05 +0000, Sérgio Basto wrote:
> use Fedora to work not to test new features , I hope
> that I haven't to fork all Fedora to keep xorg alive until F39 EOL
I currently use Xorg but will try to adapt to Wayland, even though it
still doesn't properly support session save/restore.
However, saying you use Fedora for work and not for testing new
features seems to me to be in contradiction to what Fedora is about.
It's a distro *designed* for frequent updates and testing. If you
want
stability, there are plenty of other options.
IMHO Fedora stable releases are stable enough to work , push things to
stable which is not guaranty that is stable is not a good police. The
disaster of kde 4.0 and 5.0 , are a thing that we should avoid
in this case is not just kde 6.0 is also removing Xorg , defaulting kde
to wayland is one thing, force people use wayland , when wayland still
a terrible experience , when wayland forgot about things like remote
servers (vnc) , clipboard etc and we don't have any good replacement .
it ok for who want test new features , while other can opt in by things
that are used to work
poc
--
_______________________________________________
kde mailing list -- kde(a)lists.fedoraproject.org
To unsubscribe send an email to kde-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kde@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
--
Sérgio M. B.
10:51 a.m.
On Sun, Jan 28, 2024 at 4:42 PM Sérgio Basto <sergio(a)serjux.com> wrote:
On Sat, 2024-01-27 at 16:34 +0000, Patrick O'Callaghan wrote:
> On Sat, 2024-01-27 at 16:05 +0000, Sérgio Basto wrote:
> > use Fedora to work not to test new features , I hope
> > that I haven't to fork all Fedora to keep xorg alive until F39 EOL
>
> I currently use Xorg but will try to adapt to Wayland, even though it
> still doesn't properly support session save/restore.
>
> However, saying you use Fedora for work and not for testing new
> features seems to me to be in contradiction to what Fedora is about.
> It's a distro *designed* for frequent updates and testing. If you
> want
> stability, there are plenty of other options.
IMHO Fedora stable releases are stable enough to work , push things to
stable which is not guaranty that is stable is not a good police. The
disaster of kde 4.0 and 5.0 , are a thing that we should avoid
in this case is not just kde 6.0 is also removing Xorg , defaulting kde
to wayland is one thing, force people use wayland , when wayland still
a terrible experience , when wayland forgot about things like remote
servers (vnc) , clipboard etc and we don't have any good replacement .
it ok for who want test new features , while other can opt in by things
that are used to work
None of those things were forgotten. We have krdp (RDP) and krfb (VNC)
for remote access to Plasma Wayland. Clipboard functionality is
supported through the portal and the wlroots protocol that lots of
toolkits and tools use. KRDP, in particular, is new with Plasma 6.
There's been a ton of work specifically around Plasma Wayland for 4
years now, and that work hasn't stopped. We're on the cusp of getting
multiple features that are only possible in Wayland with Plasma 6, as
well.
--
真実はいつも一つ！/ Always, there's only one truth!
11:06 a.m.
On Sun, 2024-01-28 at 16:51 +0000, Neal Gompa wrote:
On Sun, Jan 28, 2024 at 4:42 PM Sérgio Basto
<sergio(a)serjux.com>
wrote:
>
> On Sat, 2024-01-27 at 16:34 +0000, Patrick O'Callaghan wrote:
> > On Sat, 2024-01-27 at 16:05 +0000, Sérgio Basto wrote:
> > > use Fedora to work not to test new features , I hope
> > > that I haven't to fork all Fedora to keep xorg alive until F39
> > > EOL
> >
> > I currently use Xorg but will try to adapt to Wayland, even
> > though it
> > still doesn't properly support session save/restore.
> >
> > However, saying you use Fedora for work and not for testing new
> > features seems to me to be in contradiction to what Fedora is
> > about.
> > It's a distro *designed* for frequent updates and testing. If you
> > want
> > stability, there are plenty of other options.
>
> IMHO Fedora stable releases are stable enough to work , push things
> to
> stable which is not guaranty that is stable is not a good police.
> The
> disaster of kde 4.0 and 5.0 , are a thing that we should avoid
> in this case is not just kde 6.0 is also removing Xorg , defaulting
> kde
> to wayland is one thing, force people use wayland , when wayland
> still
> a terrible experience , when wayland forgot about things like
> remote
> servers (vnc) , clipboard etc and we don't have any good
> replacement .
> it ok for who want test new features , while other can opt in by
> things
> that are used to work
>
None of those things were forgotten. We have krdp (RDP) and krfb
(VNC)
for remote access to Plasma Wayland. Clipboard functionality is
supported through the portal and the wlroots protocol that lots of
toolkits and tools use. KRDP, in particular, is new with Plasma 6.
There's been a ton of work specifically around Plasma Wayland for 4
years now, and that work hasn't stopped. We're on the cusp of getting
multiple features that are only possible in Wayland with Plasma 6, as
well.
But why you want drop xorg ? that is my main question
--
Sérgio M. B.
11:25 a.m.
My solution for all teams, zoom, etc. is just use the Web app.
On Sun, Jan 28, 2024, 12:07 PM Sérgio Basto <sergio(a)serjux.com> wrote:
On Sun, 2024-01-28 at 16:51 +0000, Neal Gompa wrote:
> On Sun, Jan 28, 2024 at 4:42 PM Sérgio Basto <sergio(a)serjux.com>
> wrote:
> >
> > On Sat, 2024-01-27 at 16:34 +0000, Patrick O'Callaghan wrote:
> > > On Sat, 2024-01-27 at 16:05 +0000, Sérgio Basto wrote:
> > > > use Fedora to work not to test new features , I hope
> > > > that I haven't to fork all Fedora to keep xorg alive until F39
> > > > EOL
> > >
> > > I currently use Xorg but will try to adapt to Wayland, even
> > > though it
> > > still doesn't properly support session save/restore.
> > >
> > > However, saying you use Fedora for work and not for testing new
> > > features seems to me to be in contradiction to what Fedora is
> > > about.
> > > It's a distro *designed* for frequent updates and testing. If you
> > > want
> > > stability, there are plenty of other options.
> >
> > IMHO Fedora stable releases are stable enough to work , push things
> > to
> > stable which is not guaranty that is stable is not a good police.
> > The
> > disaster of kde 4.0 and 5.0 , are a thing that we should avoid
> > in this case is not just kde 6.0 is also removing Xorg , defaulting
> > kde
> > to wayland is one thing, force people use wayland , when wayland
> > still
> > a terrible experience , when wayland forgot about things like
> > remote
> > servers (vnc) , clipboard etc and we don't have any good
> > replacement .
> > it ok for who want test new features , while other can opt in by
> > things
> > that are used to work
> >
>
> None of those things were forgotten. We have krdp (RDP) and krfb
> (VNC)
> for remote access to Plasma Wayland. Clipboard functionality is
> supported through the portal and the wlroots protocol that lots of
> toolkits and tools use. KRDP, in particular, is new with Plasma 6.
>
> There's been a ton of work specifically around Plasma Wayland for 4
> years now, and that work hasn't stopped. We're on the cusp of getting
> multiple features that are only possible in Wayland with Plasma 6, as
> well.
But why you want drop xorg ? that is my main question
--
Sérgio M. B.
--
_______________________________________________
kde mailing list -- kde(a)lists.fedoraproject.org
To unsubscribe send an email to kde-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kde@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
11:43 a.m.
On Sun, Jan 28, 2024 at 5:07 PM Sérgio Basto <sergio(a)serjux.com> wrote:
On Sun, 2024-01-28 at 16:51 +0000, Neal Gompa wrote:
> On Sun, Jan 28, 2024 at 4:42 PM Sérgio Basto <sergio(a)serjux.com>
> wrote:
> >
> > On Sat, 2024-01-27 at 16:34 +0000, Patrick O'Callaghan wrote:
> > > On Sat, 2024-01-27 at 16:05 +0000, Sérgio Basto wrote:
> > > > use Fedora to work not to test new features , I hope
> > > > that I haven't to fork all Fedora to keep xorg alive until F39
> > > > EOL
> > >
> > > I currently use Xorg but will try to adapt to Wayland, even
> > > though it
> > > still doesn't properly support session save/restore.
> > >
> > > However, saying you use Fedora for work and not for testing new
> > > features seems to me to be in contradiction to what Fedora is
> > > about.
> > > It's a distro *designed* for frequent updates and testing. If you
> > > want
> > > stability, there are plenty of other options.
> >
> > IMHO Fedora stable releases are stable enough to work , push things
> > to
> > stable which is not guaranty that is stable is not a good police.
> > The
> > disaster of kde 4.0 and 5.0 , are a thing that we should avoid
> > in this case is not just kde 6.0 is also removing Xorg , defaulting
> > kde
> > to wayland is one thing, force people use wayland , when wayland
> > still
> > a terrible experience , when wayland forgot about things like
> > remote
> > servers (vnc) , clipboard etc and we don't have any good
> > replacement .
> > it ok for who want test new features , while other can opt in by
> > things
> > that are used to work
> >
>
> None of those things were forgotten. We have krdp (RDP) and krfb
> (VNC)
> for remote access to Plasma Wayland. Clipboard functionality is
> supported through the portal and the wlroots protocol that lots of
> toolkits and tools use. KRDP, in particular, is new with Plasma 6.
>
> There's been a ton of work specifically around Plasma Wayland for 4
> years now, and that work hasn't stopped. We're on the cusp of getting
> multiple features that are only possible in Wayland with Plasma 6, as
> well.
But why you want drop xorg ? that is my main question
Let me turn the question around: why should I or the KDE SIG put
ourselves into the position of having to maintain Xorg? We have been
aggressively working on eliminating Xorg as a dependency since Fedora
32. The first Change landed in Fedora 34[1]. The next one[2] was tried
in Fedora 36 and reattempted in Fedora 37, and then finally stuck in
Fedora 38. The KDE SIG has been absolutely clear about this for years.
We started giving talks in 2020 about it at Akademy, Flock, and
release parties. It should not have been a surprise that we're doing
it now[3].
We have been involved upstream in the KDE Wayland goal, as well as
participating in efforts around identifying and closing gaps for a
successful Plasma Wayland experience. Upstream development has been
focused on Wayland for years. Xorg has been at the end of the line for
a long time now. We didn't drop X11 application support and still
support Xwayland just fine. The ideal is that it should eventually
become a mostly transparent experience for people. It's not quite
there yet, but it's very close now.
[1]: https://fedoraproject.org/wiki/Changes/WaylandByDefaultForPlasma
[2]: https://fedoraproject.org/wiki/Changes/WaylandByDefaultForSDDM
[3]: https://fedoraproject.org/wiki/Changes/KDE_Plasma_6
--
真実はいつも一つ！/ Always, there's only one truth!
1:04 p.m.
On Sun, Jan 28, 2024 at 12:45 PM Neal Gompa <ngompa13(a)gmail.com> wrote:
The ideal is that [switching to Wayland] should eventually
become a mostly transparent experience for people. It's not quite
there yet, but it's very close now.
As a user, my concern is exactly this - will the things I have set-up
over the years continue to work with Wayland? If not, will there be a
direct replacement?
As an example, these are on my "must have" list before I can even
consider Wayland:
- remote *application*, not desktop. I.e X over a ssh tunnel. [As I
understand it, there is a tool to handle remote applications available
(or in development)]
- ability to control windows using tools such as xdotool, wmctrl, etc.
- change focus, send mouse clicks and keypresses [I saw something
recently that seemed to suggest that this can be done using dbus?]
And it should go without saying that existing X apps should "just
work"; the one time I tried Wayland (back on f36 or so) very little
seemed to work other than KDE itself. As an example, konsole worked,
but xsane did not. To be fair I should probably give it a try again
to see how things have progressed.
1:29 p.m.
On Sun, Jan 28, 2024 at 7:04 PM Go Canes <letsgonhlcanes0(a)gmail.com> wrote:
On Sun, Jan 28, 2024 at 12:45 PM Neal Gompa <ngompa13(a)gmail.com> wrote:
> The ideal is that [switching to Wayland] should eventually
> become a mostly transparent experience for people. It's not quite
> there yet, but it's very close now.
As a user, my concern is exactly this - will the things I have set-up
over the years continue to work with Wayland? If not, will there be a
direct replacement?
As an example, these are on my "must have" list before I can even
consider Wayland:
- remote *application*, not desktop. I.e X over a ssh tunnel. [As I
understand it, there is a tool to handle remote applications available
(or in development)]
This has worked for years, just nobody knew it existed.
$ waypipe ssh <user>@<host>
You need the package "waypipe" installed on both ends, but once you
have it, it'll handle the tunneling for you.
- ability to control windows using tools such as xdotool, wmctrl,
etc.
- change focus, send mouse clicks and keypresses [I saw something
recently that seemed to suggest that this can be done using dbus?]
KWin has its own APIs and tools for this, I am unfamiliar with them,
but I do know they exist as part of KWin itself.
There is also the package "ydotool" which can help replace xdotool.
And it should go without saying that existing X apps should
"just
work"; the one time I tried Wayland (back on f36 or so) very little
seemed to work other than KDE itself. As an example, konsole worked,
but xsane did not. To be fair I should probably give it a try again
to see how things have progressed.
KDE Plasma Wayland is constantly and continually improving! Plasma 6
is going to be the largest boost in the experience in a while, though,
because lots of work done by KDE in Qt is finally becoming available
to leverage in Plasma.
--
真実はいつも一つ！/ Always, there's only one truth!
7:25 a.m.
On Sun, Jan 28, 2024 at 2:31 PM Neal Gompa <ngompa13(a)gmail.com> wrote:
On Sun, Jan 28, 2024 at 7:04 PM Go Canes <letsgonhlcanes0(a)gmail.com> wrote:
[...]
> - remote *application*, not desktop. I.e X over a ssh tunnel.
[As I
> understand it, there is a tool to handle remote applications available
> (or in development)]
This has worked for years, just nobody knew it existed.
$ waypipe ssh <user>@<host>
Yes - that is what I have seen but couldn't remember.
> - ability to control windows using tools such as xdotool,
wmctrl, etc.
> - change focus, send mouse clicks and keypresses [I saw something
> recently that seemed to suggest that this can be done using dbus?]
>
KWin has its own APIs and tools for this, I am unfamiliar with them,
but I do know they exist as part of KWin itself.
The articles I see on KWin don't seem to show it as a command-line
tool. "dnf info" only says it is a window manager (and maybe my
terminology is out-of-date, but I always thought KDE was the window
manager).
There is also the package "ydotool" which can help replace
xdotool.
ydotool only appears to do part of what xdotool does.
As a generic example, I do the following today:
- identify a running application to gets its PID
- use the PID with xdotool to get the list of window IDs
- determine which window ID is the "main" window using xprop (this is
not always straightforward)
- with the proper window ID, use xdotool move the mouse to a
window-relative position
- use xdotool to send a mouse click, etc. to further interact with the
application - i.e. select from menus et.al.
Of the above, at a glance ydotool only appears to handle the mouse
movement, clicks, etc., and using absolute coordinates (which doesn't
help if I don't know where the window is located).
So similar to automated testing type of things, only in this case it
is day-to-day use (basically adding capability to programs).
I thank you for the suggestions anyway!
9:57 p.m.
On Sat, Jan 27, 2024 at 4:36 PM Patrick O'Callaghan
<pocallaghan(a)gmail.com> wrote:
On Sat, 2024-01-27 at 16:05 +0000, Sérgio Basto wrote:
> use Fedora to work not to test new features , I hope
> that I haven't to fork all Fedora to keep xorg alive until F39 EOL
I currently use Xorg but will try to adapt to Wayland, even though it
still doesn't properly support session save/restore.
While it didn't make it for 6.0, there are plans to get some
rudimentary support in 6.1 (due out in June):
https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/3523
Session restore stuff will be enhanced over time, I imagine.
We intend to ship 6.1 as an update for F40 and C10S users as we have
for Plasma 5.x releases in previous Fedora releases and EPEL 9.
However, saying you use Fedora for work and not for testing new
features seems to me to be in contradiction to what Fedora is about.
It's a distro *designed* for frequent updates and testing. If you want
stability, there are plenty of other options.
Fedora is not a "stale-stable" distribution, I agree. If you want
someone more like that, use CentOS Stream instead with KDE from EPEL.
--
真実はいつも一つ！/ Always, there's only one truth!
4:36 a.m.
On Mon, 2024-01-29 at 03:57 +0000, Neal Gompa wrote:
> I currently use Xorg but will try to adapt to Wayland, even
though
> it
> still doesn't properly support session save/restore.
>
While it didn't make it for 6.0, there are plans to get some
rudimentary support in 6.1 (due out in June):
https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/3523
That's disappointing. I was prepared to try the "rudimentary support"
but if even that isn't going to be available I'll probably have to hold
off updating to F40.
Session restore stuff will be enhanced over time, I imagine.
I cannot stress enough that this is *basic functionality* for a desktop
system. It's standard across Windows and MacOS systems and users expect
it to work (even if it doesn't work very well on Xorg). I simply do not
understand how people use desktops that don't implement this. Are they
really restarting every app *manually* every time they log in? I find
this astonishing.
poc
5:07 a.m.
Am 29.01.24 um 11:36 schrieb Patrick O'Callaghan:
> Session restore stuff will be enhanced over time, I imagine.
I cannot stress enough that this is*basic functionality* for a desktop
system. It's standard across Windows and MacOS systems and users expect
it to work (even if it doesn't work very well on Xorg). I simply do not
understand how people use desktops that don't implement this. Are they
really restarting every app*manually* every time they log in? I find
this astonishing.
Yes, I restart everything I need everytime. But tbf, I also slowly close
everything over the last about half an hour before turning it off, so it
wouldn't be all too useful.
Besides, the only program I really have ALWAYS open is my browser.
Everything else is sometimes open sometimes not, depending on what I am
doing.
Kilian Hanich
5:31 a.m.
On Mon, 2024-01-29 at 12:07 +0100, Kilian Hanich wrote:
Am 29.01.24 um 11:36 schrieb Patrick O'Callaghan:
> > Session restore stuff will be enhanced over time, I imagine.
> I cannot stress enough that this is*basic functionality* for a
> desktop
> system. It's standard across Windows and MacOS systems and users
> expect
> it to work (even if it doesn't work very well on Xorg). I simply do
> not
> understand how people use desktops that don't implement this. Are
> they
> really restarting every app*manually* every time they log in? I
> find
> this astonishing.
Yes, I restart everything I need everytime. But tbf, I also slowly
close
everything over the last about half an hour before turning it off, so
it
wouldn't be all too useful.
Besides, the only program I really have ALWAYS open is my browser.
Everything else is sometimes open sometimes not, depending on what I
am
doing.
My standard setup has 4 virtual desktops (plus two others for
occasional use). Of the 4:
* One has Konsole and a browser window with several tabs open.
* One has two browser windows, each with several tabs open.
* One has my email MUA (Evolution) at full screen.
* One has yet another browser window, with its tabs open, plus 3
Dolphin windows. One of these has the Terminal pane open. The other
two are split between different local and remote directories.
Having to re-establish all this manually would take a significant
amount of time, and in fact the Dolphin set-up still needs some manual
intervention even on Xorg because it doesn't remember window layout of
the Terminal open/closed state correctly.
poc
7 a.m.
On Mon, 2024-01-29 at 13:41 +0100, Kilian Hanich wrote:
Am 29.01.24 um 12:31 schrieb Patrick O'Callaghan:
> * One has Konsole and a browser window with several tabs open.
> * One has two browser windows, each with several tabs open.
Do you use the same browser or how do you ensure that each window has
the correct tabs?
It's the same browser (usually Firefox). I rely on the browser settings
to remember the various tabs and window positions, though generally it
doesn't remember the desktops each window is one. I set up a keyboard
shortcut to send each window to its proper desktop.
poc
5:38 a.m.
On Mon, Jan 29, 2024 at 10:37 AM Patrick O'Callaghan
<pocallaghan(a)gmail.com> wrote:
On Mon, 2024-01-29 at 03:57 +0000, Neal Gompa wrote:
> > I currently use Xorg but will try to adapt to Wayland, even though
> > it
> > still doesn't properly support session save/restore.
> >
>
> While it didn't make it for 6.0, there are plans to get some
> rudimentary support in 6.1 (due out in June):
> https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/3523
>
That's disappointing. I was prepared to try the "rudimentary support"
but if even that isn't going to be available I'll probably have to hold
off updating to F40.
Depending on what a backport could look like, we could try to
ship it sooner. But at this point, I'm confident in it shipping in
6.1.
> Session restore stuff will be enhanced over time, I imagine.
I cannot stress enough that this is *basic functionality* for a desktop
system. It's standard across Windows and MacOS systems and users expect
it to work (even if it doesn't work very well on Xorg). I simply do not
understand how people use desktops that don't implement this. Are they
really restarting every app *manually* every time they log in? I find
this astonishing.
This functionality does not exist in Windows or macOS. There is a
"relaunch all the things open at time of shutdown/restart" feature in
macOS, which is what that merge request implements. On Windows, some
applications will mark themselves to auto-launch on login in the
registry, which sort of emulates this capability on a per application
basis.
Session restore is a concept that has basically never existed in a
cross-platform way, and that's a big part of why it has never worked
well in most applications. It's just not important enough to deal with
when it only works for a subset of X11 desktops.
--
真実はいつも一つ！/ Always, there's only one truth!
6:11 a.m.
On Mon, 2024-01-29 at 11:38 +0000, Neal Gompa wrote:
On Mon, Jan 29, 2024 at 10:37 AM Patrick O'Callaghan
<pocallaghan(a)gmail.com> wrote:
> [...]
> I cannot stress enough that this is *basic functionality* for a
> desktop
> system. It's standard across Windows and MacOS systems and users
> expect
> it to work (even if it doesn't work very well on Xorg). I simply do
> not
> understand how people use desktops that don't implement this. Are
> they
> really restarting every app *manually* every time they log in? I
> find
> this astonishing.
>
This functionality does not exist in Windows or macOS. There is a
"relaunch all the things open at time of shutdown/restart" feature in
macOS, which is what that merge request implements.
That's close enough. I don't really see much practical difference (I
wouldn't expect processes to be frozen and continued), though I would
generally expect apps to have their current directory preserved across
sessions if it has changed from the default whenever possible (i.e. if
permissions or locations hadn't changed in the meantime). I don't know
how practical that is.
On Windows, some
applications will mark themselves to auto-launch on login in the
registry, which sort of emulates this capability on a per application
basis.
I use Windows so little that I probably mistook this for what it does.
Session restore is a concept that has basically never existed in a
cross-platform way, and that's a big part of why it has never worked
well in most applications. It's just not important enough to deal
with
when it only works for a subset of X11 desktops.
As I say, *restarting" is essentially what I mean by *restoring*. I've
always understood it in that sense.
poc
6:37 a.m.
On Mon, Jan 29, 2024 at 12:11 PM Patrick O'Callaghan
<pocallaghan(a)gmail.com> wrote:
On Mon, 2024-01-29 at 11:38 +0000, Neal Gompa wrote:
> On Mon, Jan 29, 2024 at 10:37 AM Patrick O'Callaghan
> <pocallaghan(a)gmail.com> wrote:
>
> > [...]
> > I cannot stress enough that this is *basic functionality* for a
> > desktop
> > system. It's standard across Windows and MacOS systems and users
> > expect
> > it to work (even if it doesn't work very well on Xorg). I simply do
> > not
> > understand how people use desktops that don't implement this. Are
> > they
> > really restarting every app *manually* every time they log in? I
> > find
> > this astonishing.
> >
>
> This functionality does not exist in Windows or macOS. There is a
> "relaunch all the things open at time of shutdown/restart" feature in
> macOS, which is what that merge request implements.
That's close enough. I don't really see much practical difference (I
wouldn't expect processes to be frozen and continued), though I would
generally expect apps to have their current directory preserved across
sessions if it has changed from the default whenever possible (i.e. if
permissions or locations hadn't changed in the meantime). I don't know
how practical that is.
> On Windows, some
> applications will mark themselves to auto-launch on login in the
> registry, which sort of emulates this capability on a per application
> basis.
>
I use Windows so little that I probably mistook this for what it does.
> Session restore is a concept that has basically never existed in a
> cross-platform way, and that's a big part of why it has never worked
> well in most applications. It's just not important enough to deal
> with
> when it only works for a subset of X11 desktops.
As I say, *restarting" is essentially what I mean by *restoring*. I've
always understood it in that sense.
Then we should be able to achieve it. I'm merely waiting for it to be
merged before deciding what to do next. If it happens soon enough, we
can prioritize figuring out a backport and land it for Fedora 40 GA.
--
真実はいつも一つ！/ Always, there's only one truth!
10:27 a.m.
On 1/29/24 05:36, Patrick O'Callaghan wrote:
On Mon, 2024-01-29 at 03:57 +0000, Neal Gompa wrote:
> Session restore stuff will be enhanced over time, I imagine.
I cannot stress enough that this is *basic functionality* for a desktop
system.
Indeed. It can't possibly be that hard, either. It's a matter of priorities.
Riki
10:25 p.m.
I am running rawhide on both my desktop and laptop. Runs awesomely! Does it
have bugs? Of course. But nothing gamebreaking. I am submitting bugs as i
see them 😊
On Sat, Jan 27, 2024 at 10:02 AM Neal Gompa <ngompa13(a)gmail.com> wrote:
On Sat, Jan 27, 2024 at 12:13 AM Felix Miata
<mrmazda(a)earthlink.net>
wrote:
>
> Is 40 really /expected/ to ship with 6.0 /and/ no Xorg, or is its
presence in
> Rawhide at this point really intended for attracting guinea pigs?
Normally I do
> upgrades from current to Rawhide on several PCs shortly before branch to
be part
> of the pre-release testing process, but I don't know if it's possible to
be worth
> the bother this cycle.
Yes, it is really expected to ship this way. KDE upstream is doing a
lot to ensure Plasma 6.0 is great for regular use. Unlike previous
major releases, we've had development snapshots in good shape since
September, and Fedora has had the stack since early November. We've
been dogfooding it and getting things fixed before even the first beta
release, and the extended test cycle with multiple betas and release
candidates are intended to ensure things are in the best shape
possible.
Nearly all of us in the KDE SIG are running it as secondaries or daily
drivers now, and the experience has been very promising!
We've also scheduled a test week next week:
https://fedoramagazine.org/contribute-at-the-kde-plasma-6-test-week/
--
真実はいつも一つ！/ Always, there's only one truth!
--
_______________________________________________
kde mailing list -- kde(a)lists.fedoraproject.org
To unsubscribe send an email to kde-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kde@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
103
days inactive
109
days old
42 comments
15 participants
participants (15)
-
Adam Batkin -
Emmett Culley -
Felix Miata -
Go Canes -
John P -
Kilian Hanich -
Michael Eager -
Neal Becker -
Neal Gompa -
Patrick O'Callaghan -
Richard Kimberly Heck -
Robert McBroom -
Steve Cossette -
Sérgio Basto -
Timothy M Butterworth