Announcement

Collapse
No announcement yet.

Valve Engineer Mike Blumenkrantz Hoping To Accelerate Wayland Protocol Development

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

  • qarium
    replied
    Originally posted by Doomer View Post
    Are you alright bro?
    no he is right they sell us DRM/Copy-protection as security in the meaning of benefit to the user.

    Leave a comment:


  • Artim
    replied
    Originally posted by fitzie View Post

    how so? exensions like dash-to-dock (a mac like dock) or openweather (little weather applet) should be perfectly capable of being in a separate process, and to be cross compositor quite frankly. i would think there'd be more "extensions" if they were allowed to be coding in whatever language you want, using a standardized interface to register with the taskbar/query window information.
    To my knowledge the whole shell is done with JS (at least the visual parts, other parts are done in C), thus the extensions are using JS, as they are pretty much just injecting code into the shell's JS code in order to modify it. So no, extensions can't just be written in any language. The question if extensions should - or even can - run in a dedicated process is something very different. And honestly I doubt that that is a smart idea, as that could easily break the extensions as you'd have to make sure that the extensions code is injected at the right time.

    Making such huge changes would inevitably break every single extension, making it much more difficult to port them all to the new model, and it would be questionable if every single extension could still be supported.

    Leave a comment:


  • Artim
    replied
    Originally posted by curfew View Post
    And how exactly? It should be easy to isolate extensions into a simple JS VM process that does nothing else, and preserves the old programming API, which then dispatches Wayland calls using the internal protocols.
    Then I don't really understand what you want to use Wayland protocols for...

    Leave a comment:


  • fitzie
    replied
    Originally posted by Artim View Post

    That would destroy the whole extension ecosystem, so it hopefully will never happen.
    how so? exensions like dash-to-dock (a mac like dock) or openweather (little weather applet) should be perfectly capable of being in a separate process, and to be cross compositor quite frankly. i would think there'd be more "extensions" if they were allowed to be coding in whatever language you want, using a standardized interface to register with the taskbar/query window information.

    Leave a comment:


  • anda_skoa
    replied
    Originally posted by Artim View Post
    Yes, that can be done inside Flatpak too, just have find tell you where exactly that file is located (should be ~/.var/app/us.zoom.Zoom/config/zoomus.conf)
    Indeed.
    I did that right after your previous hint and it worked nicely

    Looks a bit weird but I have reliable behavior back

    Leave a comment:


  • curfew
    replied
    Originally posted by Artim View Post
    That would destroy the whole extension ecosystem, so it hopefully will never happen.
    And how exactly? It should be easy to isolate extensions into a simple JS VM process that does nothing else, and preserves the old programming API, which then dispatches Wayland calls using the internal protocols.

    Leave a comment:


  • curfew
    replied
    Originally posted by anda_skoa View Post
    Visual consistency is a nice to have thing, people can be annoyed about difference but are usually able to cope.

    The important thing is behavioral consistency because differences in behavior breaks workflows.

    Since there is no single implementation for CSDs it is easy to encounter one that is broken in one way or another.

    Chrome defaults to CSD and has a quite nicely looking title bar.
    However, last time I tried it, it had a bug that makes its "maximize" buttons expand the window in both dimensions regardless of which mouse button clicks it.
    I.e. system configuration is to maximize vertically if the right mouse button is used but Chrome ignores that and fill the whole screen.

    Fortunately Chrome provides an easy way to fix this by having a "use system title bar" (or similar phrasing) option in its title bar's context menu.

    Zoom, which seem to have switched to exclusively CSD, lost the "on all desktops" button in the process.
    Sadly it does not offer an easy way to switch its broken title bar off, so I can only wait, hope and pray that they will eventually fix their bug
    Yeah, those aren't bugs.

    You can bring up the WM's window context menu usually via Alt-Space or maybe Alt-F10, I don't remember what the standard shortcut was. It should offer enough options for basic users.

    It's pretty pointless to expect that all widget-related hacks would be implemented on all apps, but even Gnome (Mutter) supports binding keyboard shorcuts for actions similar to what you described. (I use them too.)

    Power users should be comfortable with keyboard shortcuts. Everything else is nitpicking.

    Leave a comment:


  • Artim
    replied
    Originally posted by anda_skoa View Post
    Yes, that sounds like a likely equivalent.



    I've installed it as a Flatpak to have it update like every other piece of software but this should still be applicable in some form.
    Thanks a lot!
    Yes, that can be done inside Flatpak too, just have find tell you where exactly that file is located (should be ~/.var/app/us.zoom.Zoom/config/zoomus.conf)

    Leave a comment:


  • Artim
    replied
    Originally posted by fitzie View Post

    I wish they would create wayland protocols for all the internal stuff they are doing so that you don't need to run as javascript inside the shell pid to program your desktop.
    That would destroy the whole extension ecosystem, so it hopefully will never happen.

    I used to hope that gnome would start to leverage wlroots, but it's clear that wlroots really is a toy, and I'm convinced a dominant rust library is the only way forward for wayland compositors.
    I'd guess Theseus' Ship has much bigger chances to do that. Already exists, it is continuing the working he has already done with his previous KWin alternative and is probably modular enough that everyone could agree on it. Only thing it would probably need would be some bindings to e.g. Rust to better integrate with stuff like Cosmic.

    Leave a comment:


  • anda_skoa
    replied
    Originally posted by Artim View Post
    Ah. So I only know the options "Always on visible workspace" and "Move to Workspace right". The first one seems to do what you are looking for. And if it is, I know how you can fix you situation.
    Yes, that sounds like a likely equivalent.

    Originally posted by Artim View Post
    If you installed Zoom as a normal package (i.e. as a .deb or .rpm package), it keeps its settings in ~/.config/zoomus.conf. To bring back the title bar, you need
    Code:
    showSystemTitlebar=true
    in there.
    I've installed it as a Flatpak to have it update like every other piece of software but this should still be applicable in some form.
    Thanks a lot!

    Leave a comment:

Working...
X