7 ms·

Useful approach, given the troves of applications that cannot be ported to the native Wayland in years to come - all GTK2 apps, e.g. GIMP, all Java apps, and so

by xvilka 5y ago

Useful approach, given the troves of applications that cannot be ported to the native Wayland in years to come - all GTK2 apps, e.g. GIMP, all Java apps, and so on... Regarding HiDPI and XWayland, there is work-in-progress PR[1] that so far is being ignored by the Wayland developers. [1] https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/733 https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests...

CyberRabbi 5y ago
> Regarding HiDPI and XWayland, there is work-in-progress PR[1] that so far is being ignored by the Wayland developers. Just curious, what are the Wayland developers expected to do? This seems like an Xwayland and compositor implementation issue.
- deleted 5y ago
  [deleted]
pjmlp 5y ago
Java does not depend on Gtk 2, unless you're stuck with some pre-historic version. As for Wayland, https://wiki.openjdk.java.net/display/wakefield/OpenJDK+Project+Wakefield+-+Wayland+desktop+support+for+JDK+on+Linux https://wiki.openjdk.java.net/display/wakefield/OpenJDK+Proj...
- xvilka 5y ago
  I know, those were two separate categories. Regarding the Wayfield project, citing them: > It is very unlikely that distros will be ready to ship all the pieces we need in the next 12 months. So the "short term" goal may actually need to wait for somewhat longer than that. https://wiki.openjdk.java.net/display/wakefield/Meeting+Notes https://wiki.openjdk.java.net/display/wakefield/Meeting+Note...
  - pjmlp 5y ago
    Given the progress adopting Wayland I don't see that much of a problem that it will take some time to deliver a full working solution. The way you made your remark could be understood as if nothing was being done at all.
    - xvilka 5y ago
      It's indeed not a problem if the Wayland sessions wouldn't become the default in mainstream distributions and these pesky HiDPI displays didn't become more affordable and popular among users. Don't get me wrong, the blame is squarely on the Java ecosystem that is too slow to keep up with the progress, Wayland developers did great job. The problem is that we still use some of that Java software, or some of that GTK2 software (GIMP), so it's better to accomodate the needs of that software, even if just temporarily.
      - pjmlp 5y ago
        Other than ChromeOS and WSL, hardly any distribution is Wayland only, so one can't really blame the Java community to focus improving Swing on Wayland, specially with other more relevant areas still in need. If anything the whole GNU/Linux ecosystem is too slow adopting Wayland.
emersion 5y ago
> ignored by the Wayland developers Feel free to improve and/or review it. Maybe it's very important to you. But it may no be very important to other contributors, and said contributors are just volunteers.
- xvilka 5y ago
  To be honest, it's not very important to me - I need this particular case on the one machine where I use JetBrains IDE. On this machine I just switched to the Xorg. Everywhere else, I am quite happy with the pure Wayland as is, kudos to developers. It is important [1] for many JetBrains users, it seems though. [1] https://youtrack.jetbrains.com/issue/JBR-3206 https://youtrack.jetbrains.com/issue/JBR-3206
1_player 5y ago
> PR that so far is being ignored by the Wayland developers The reviewers have asked for some details about the changes and no response yet, it seems unfair to blame the maintainers here. But of course that goes against the narrative of "Wayland bad".
- xvilka 5y ago
  I never said "Wayland is bad". Some cases aren't handled properly before making it mainstream in Linux distributions. It should have been done before, not after.
  - shatteredgate 5y ago
    Open source doesn't really work like that, there is no top-down decision maker setting priorities for what should be done in any given distribution. Usually what happens is you wait until it becomes enough of a problem that some distribution fixes it, but this one is low priority given that distributions would probably prefer to focus on native Wayland ports for the software they have control over that is packaged in their distribution. And for the external software they don't have control over, it's much harder to find people to work on those.
    - chaosharmonic 5y ago
      ^ further, there's the fact that distributions (and the various parts therein) frequently duplicate one another's work in the name of taking different approaches at the same problem, and usually the solutions that become more mainstream are the ones that several of them have collectively settled on. Android has a similar, if more centralized feedback loop: AOSP drops, device makers build out customizations on top of it, Google adopts some of these features upstream (whether by building new implementations or merging contributions from vendors), and then those vendors go on to building the next differentiating thing now that they don't have to dedicate those resources to individually maintaining stylus support/multiwindow/notification badges/whatever.
kirbyfan64sos 5y ago
That's my MR and I haven't had time to complete it (particularly a compositor impl to go along with it), has nothing to do with being ignored.
- floatboth 5y ago
  > particularly a compositor impl to go along with it Well, there is a wlroots impl, so I've just added a couple lines to wlroots to invoke this support from an env variable without having to modify the actual compositor :D https://github.com/unrelentingtech/wlroots/commit/5b8308651cb6942ac3079cbdab7fcbc7a41bd577 https://github.com/unrelentingtech/wlroots/commit/5b8308651c... but the wlroots impl isn't merged either, so I think there's kind of a mutual dependency here. Either your MR or the wlroots MR should go in first!

by xvilka 5y ago

CyberRabbi 5y ago

> Regarding HiDPI and XWayland, there is work-in-progress PR[1] that so far is being ignored by the Wayland developers. Just curious, what are the Wayland developers expected to do? This seems like an Xwayland and compositor implementation issue.

deleted 5y ago
[deleted]

pjmlp 5y ago

Java does not depend on Gtk 2, unless you're stuck with some pre-historic version. As for Wayland, https://wiki.openjdk.java.net/display/wakefield/OpenJDK+Project+Wakefield+-+Wayland+desktop+support+for+JDK+on+Linux https://wiki.openjdk.java.net/display/wakefield/OpenJDK+Proj...

xvilka 5y ago
I know, those were two separate categories. Regarding the Wayfield project, citing them: > It is very unlikely that distros will be ready to ship all the pieces we need in the next 12 months. So the "short term" goal may actually need to wait for somewhat longer than that. https://wiki.openjdk.java.net/display/wakefield/Meeting+Notes https://wiki.openjdk.java.net/display/wakefield/Meeting+Note...
- pjmlp 5y ago
  Given the progress adopting Wayland I don't see that much of a problem that it will take some time to deliver a full working solution. The way you made your remark could be understood as if nothing was being done at all.
  - xvilka 5y ago
    It's indeed not a problem if the Wayland sessions wouldn't become the default in mainstream distributions and these pesky HiDPI displays didn't become more affordable and popular among users. Don't get me wrong, the blame is squarely on the Java ecosystem that is too slow to keep up with the progress, Wayland developers did great job. The problem is that we still use some of that Java software, or some of that GTK2 software (GIMP), so it's better to accomodate the needs of that software, even if just temporarily.
    - pjmlp 5y ago
      Other than ChromeOS and WSL, hardly any distribution is Wayland only, so one can't really blame the Java community to focus improving Swing on Wayland, specially with other more relevant areas still in need. If anything the whole GNU/Linux ecosystem is too slow adopting Wayland.

emersion 5y ago

> ignored by the Wayland developers Feel free to improve and/or review it. Maybe it's very important to you. But it may no be very important to other contributors, and said contributors are just volunteers.

xvilka 5y ago
To be honest, it's not very important to me - I need this particular case on the one machine where I use JetBrains IDE. On this machine I just switched to the Xorg. Everywhere else, I am quite happy with the pure Wayland as is, kudos to developers. It is important [1] for many JetBrains users, it seems though. [1] https://youtrack.jetbrains.com/issue/JBR-3206 https://youtrack.jetbrains.com/issue/JBR-3206

1_player 5y ago

> PR that so far is being ignored by the Wayland developers The reviewers have asked for some details about the changes and no response yet, it seems unfair to blame the maintainers here. But of course that goes against the narrative of "Wayland bad".

xvilka 5y ago
I never said "Wayland is bad". Some cases aren't handled properly before making it mainstream in Linux distributions. It should have been done before, not after.
- shatteredgate 5y ago
  Open source doesn't really work like that, there is no top-down decision maker setting priorities for what should be done in any given distribution. Usually what happens is you wait until it becomes enough of a problem that some distribution fixes it, but this one is low priority given that distributions would probably prefer to focus on native Wayland ports for the software they have control over that is packaged in their distribution. And for the external software they don't have control over, it's much harder to find people to work on those.
  - chaosharmonic 5y ago
    ^ further, there's the fact that distributions (and the various parts therein) frequently duplicate one another's work in the name of taking different approaches at the same problem, and usually the solutions that become more mainstream are the ones that several of them have collectively settled on. Android has a similar, if more centralized feedback loop: AOSP drops, device makers build out customizations on top of it, Google adopts some of these features upstream (whether by building new implementations or merging contributions from vendors), and then those vendors go on to building the next differentiating thing now that they don't have to dedicate those resources to individually maintaining stylus support/multiwindow/notification badges/whatever.

kirbyfan64sos 5y ago

That's my MR and I haven't had time to complete it (particularly a compositor impl to go along with it), has nothing to do with being ignored.

floatboth 5y ago
> particularly a compositor impl to go along with it Well, there is a wlroots impl, so I've just added a couple lines to wlroots to invoke this support from an env variable without having to modify the actual compositor :D https://github.com/unrelentingtech/wlroots/commit/5b8308651cb6942ac3079cbdab7fcbc7a41bd577 https://github.com/unrelentingtech/wlroots/commit/5b8308651c... but the wlroots impl isn't merged either, so I think there's kind of a mutual dependency here. Either your MR or the wlroots MR should go in first!