Announcement

Collapse
No announcement yet.

Red Hat Developing New xwayland-run & wlheadless-run Utilities

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • anda_skoa
    replied
    Originally posted by fitzie View Post
    you take him for some crank and his post as some sort of any-wayland screed?
    No, the exact opposite!

    I was pointing out that if one doesn't read the article carefully it will give that impression.
    This misinterpretation might even have been the intent, but this is just my personal speculation.

    If one pays attention it clearly spells out how limited the X11 approach was and how much more sensible and inline with other platform this can be handled with Wayland.

    The author mentions the difficulty on X11 of holding a grab on all inputs, to ensure that unlocked content is no longer show and the pain of implementing the unlocking in the screensaver which should not be involved with that at all.

    With Wayland input blocking and output blanking, locking and unlocking is no longer the concern of the screensaver which can full concentrate on its main purpose.
    The article mentions macOS as another system handling it that way and I think one of the comments says that Windows also handles these tasks in the system rather than burdening every screensaver with it.

    The author is way to knowledgeable to have written an ignorant "screensavers won't work on Wayland" rant that many seem to interpret it to be.

    It is rather an acknowledgment of how Wayland enables a separation of concerns that weren't possible with X11.

    Letting the system handle the locking/unlocking and letting the screensaver handle the dynamic content while the lock is active.
    Letting the screensaver developer handle the artistic and fun bits without even having to think about the gnarly bits as they have been taken care of by the system developers.

    Cheers,
    _

    Leave a comment:


  • spicfoo
    replied
    Originally posted by cj.wijtmans View Post

    You have no idea what closed source software does on top of open source software, completely defeating the purpose of something being open source.
    This is why we have plenty of projects including GNOME Web, Konqueror, ungoogled Chromium and Iridium using WebKit/Blink that enabled us to address that concern. Multiple open source engines provides us more choice .

    Leave a comment:


  • cj.wijtmans
    replied
    Originally posted by spicfoo View Post

    The engine itself is open source. I like that better. If you don't, so be it.
    you make zero sense dude. Are you that dumb ass poetering? You have no idea what closed source software does on top of open source software, completely defeating the purpose of something being open source.

    Leave a comment:


  • fitzie
    replied
    Originally posted by anda_skoa View Post

    On a quick glance it does look as if the article claims a limitation of Wayland, when it actually does the opposite.
    It is more or less trolling people who buy into the "Wayland is more limited than X11" trope.

    The article is quite clear that providing a working screen lock is a nightmare on X11.

    On Wayland the compositor is control of both input and output and can easily transition between its normal mode of operation to locked screen.
    The content of the lock screen can obviously be as dynamic as any other surface, e.g. classic screensaver rendering, notifications, media player controls, or just blank.

    The article then goes on to acknowledges that macOS does the very same thing.
    "Under macOS, how that works is, the system instantiates a configured subclass of a ScreenSaverView window sized for each monitor and tells each of them to start animating"

    I am sure you are not the only reader who fell for that flame bait.
    It is expertly written to sound like a complaint about Wayland.
    A lot art still practiced by those few who learned it during the usenet era

    Cheers,
    _
    that guy tirelessly ports his code to every possible platform, yet it doesn't work on wayland, he explains it clearly and gives his suggestions, and you take him for some crank and his post as some sort of any-wayland screed?

    i understand that screensavers are somewhat anachronistic but it is just one more thing we're not allowed to have anymore in wayland without some per-compositor specific development. it's really impressive how awful wayland attitude is.
    I waylandmeme.jpg

    Leave a comment:


  • spicfoo
    replied
    Originally posted by ssokolow View Post

    They wrote Phonon because, at the time, none of MPlayer, Xine, VLC, and GStreamer was good enough to serve all needs
    Sure. Like I said I support their decision to use abstraction layers. Later Qt depending on Gstreamer wasn't KDE's decision. If you want to convince me that KDE seriously considered Mutter or even Wlroots, show me the direct evidence.

    Leave a comment:


  • ssokolow
    replied
    Originally posted by spicfoo View Post
    I know what happened. They wrote an entirely abstraction layer to avoid depending on Gstreamer directly.
    I was there. They wrote Phonon because, at the time, none of MPlayer, Xine, VLC, and GStreamer was good enough to serve all needs, so they punted to the individual users on which codecs they wanted to sacrifice to make which other ones work.

    It got integrated into Qt for a while and, guess what... Phonon in Qt got deprecated in favour of QtMultimedia, which now depends on GStreamer directly because GStreamer+ffmpeg matured into a combo that beats the alternatives soundly enough.

    It was a lot of work but helped with portability and ABI. In any case, you might as well as claim they share things like systemd or glibc. Those are much more low level than a window manager. KDE wasn't ever going to use Mutter and there is no evidence to show otherwise. The evidence we do have shows you can't even get them to consider KWinFT and that's ok. They should maintain their own independence. Even is GNOME has perfectly fine window manager, my position on this remains the same.
    Have you seen how insanely much KDE depends on IPC? When DCOP broke, everything broke. Hell, D-Bus hiccups cause all sorts of weird breakages in things you'd expect to be done in-process these days, such as deleting files in K3b.

    ...and yet they collaborated with GNOME to migrate to a shared solution.

    Leave a comment:


  • spicfoo
    replied
    Originally posted by ssokolow View Post

    What do you think happened with KDE using things like GStreamer?
    I know what happened. They wrote an entirely abstraction layer to avoid depending on Gstreamer directly. It was a lot of work but helped with portability and ABI. In any case, you might as well as claim they share things like systemd or glibc. Those are much more low level than a window manager. KDE wasn't ever going to use Mutter and there is no evidence to show otherwise. The evidence we do have shows you can't even get them to consider KWinFT and that's ok. They should maintain their own independence. Even is GNOME has perfectly fine window manager, my position on this remains the same.

    Leave a comment:


  • spicfoo
    replied
    Originally posted by cj.wijtmans View Post

    and? They are still closed source.
    The engine itself is open source. I like that better. If you don't, so be it.

    Leave a comment:


  • ssokolow
    replied
    Originally posted by spicfoo View Post
    Speaking of well known facts, we all know that Mutter was never going to be used by KDE regardless of any architectural or performance concerns anymore than EFL was going to use KWin. One of the KWin developers even forked KWin to be based on wlroots and was funded by Valve for two years. That developer was booted off KDE Planet while other developers repeatedly criticized him for doing this work. He lost funding and continues to maintain the fork even now but noone is going to adopt it. Reality is that desktop environments are their own fiercely independent ecosystems and they take pride in that. They will never allow other desktop environments to control key parts of their stack and hey if KDE didn't do its own thing with KHTML, we wouldn't have WebKit, Blink and all that. The hand wringing on multiple implementations of anything in the free software world is entirely bogus. If you don't have centralized top down control which you don't, you are always going to have people doing their own thing
    What do you think happened with KDE using things like GStreamer? What do you think happened with KDE working with GNOME to sunset both DCOP (KDE's homegrown IPC solution) and CORBA (A very 90s IPC standard that GNOME used) and replace both with D-Bus?

    Generally, when KDE doesn't use GNOME tech, it's because it's a buggy knock-off of something KDE already had that GNOME refused the offer of KDE-written-and-maintained C bindings for because of an ideological aversion to having dependencies written in C++. (eg. For a long time, GnomeVFS was the buggy knock-off of KDE's KIOSlaves and I seem to remember KDE offering to provide C bindings for DCOP before everyone settled on D-Bus. Heck, GtkWebKit and QWebEngine are both descended from KHTML.)

    When the GNOME ecosystem has something that actually is good and isn't one of those "pulling in Qt will pull in an implementation of this whether or not we use it" things, KDE uses it.

    Leave a comment:


  • cj.wijtmans
    replied
    Originally posted by spicfoo View Post

    That's not all what anyone is saying. Before WebKit, we had one mainstream browser (Firefox) using an open source engine. Now all mainstream browsers are using an open source engine.
    and? They are still closed source. That they build upon open source proejct to build their spyware adware machine is irrelevant.
    Starting to think you are just a M$ troll.

    Leave a comment:

Working...
X