On Fri, 28 Mar 2025 08:56:36 GMT, Jayathirth D V wrote:
> SwingNodePlatformExitCrashTest hangs while running on wayland, we need to
> skip this test on wayland until https://bugs.openjdk.org/browse/JDK-8350009
> is fixed.
This pull request has been closed without being i
On Fri, 28 Mar 2025 08:56:36 GMT, Jayathirth D V wrote:
> SwingNodePlatformExitCrashTest hangs while running on wayland, we need to
> skip this test on wayland until https://bugs.openjdk.org/browse/JDK-8350009
> is fixed.
I ran the test multiple times with wayland and JDK 24 on Ub
On Fri, 28 Mar 2025 08:56:36 GMT, Jayathirth D V wrote:
> SwingNodePlatformExitCrashTest hangs while running on wayland, we need to
> skip this test on wayland until https://bugs.openjdk.org/browse/JDK-8350009
> is fixed.
The hang we are seeing on Wayland Linux when running on some s
On Fri, 28 Mar 2025 08:56:36 GMT, Jayathirth D V wrote:
> SwingNodePlatformExitCrashTest hangs while running on wayland, we need to
> skip this test on wayland until https://bugs.openjdk.org/browse/JDK-8350009
> is fixed.
I'm a bit worried with disabling the test, as there is no
On Fri, 28 Mar 2025 08:56:36 GMT, Jayathirth D V wrote:
> SwingNodePlatformExitCrashTest hangs while running on wayland, we need to
> skip this test on wayland until https://bugs.openjdk.org/browse/JDK-8350009
> is fixed.
LGTM with one inline suggestion about adding the bug ID bein
On Fri, 28 Mar 2025 08:56:36 GMT, Jayathirth D V wrote:
> SwingNodePlatformExitCrashTest hangs while running on wayland, we need to
> skip this test on wayland until https://bugs.openjdk.org/browse/JDK-8350009
> is fixed.
Gradle Wrapper Validation step failed - could you re-start th
On Fri, 28 Mar 2025 08:56:36 GMT, Jayathirth D V wrote:
> SwingNodePlatformExitCrashTest hangs while running on wayland, we need to
> skip this test on wayland until https://bugs.openjdk.org/browse/JDK-8350009
> is fixed.
Marked as reviewed by angorya (Reviewer).
-
SwingNodePlatformExitCrashTest hangs while running on wayland, we need to skip
this test on wayland until https://bugs.openjdk.org/browse/JDK-8350009 is fixed.
-
Commit messages:
- 8353163: [XWayland] Disable SwingNodePlatformExitCrashTest on wayland
Changes: https
On Tue, 10 Dec 2024 14:10:23 GMT, Alexander Zvegintsev
wrote:
> This PR enables several previously disabled test cases for Wayland, as the
> required fixes are already in the promoted build.
> ([JDK-8335469](https://bugs.openjdk.org/browse/JDK-8335469),
> [JDK-83
On Tue, 10 Dec 2024 14:10:23 GMT, Alexander Zvegintsev
wrote:
> This PR enables several previously disabled test cases for Wayland, as the
> required fixes are already in the promoted build.
> ([JDK-8335469](https://bugs.openjdk.org/browse/JDK-8335469),
> [JDK-83
On Tue, 10 Dec 2024 14:49:34 GMT, Kevin Rushforth wrote:
>> This PR enables several previously disabled test cases for Wayland, as the
>> required fixes are already in the promoted build.
>> ([JDK-8335469](https://bugs.openjdk.org/browse/JDK-8335469),
>> [JDK-8335468](
On Tue, 10 Dec 2024 14:10:23 GMT, Alexander Zvegintsev
wrote:
> This PR enables several previously disabled test cases for Wayland, as the
> required fixes are already in the promoted build.
> ([JDK-8335469](https://bugs.openjdk.org/browse/JDK-8335469),
> [JDK-83
This PR enables several previously disabled test cases for Wayland, as the
required fixes are already in the promoted build.
([JDK-8335469](https://bugs.openjdk.org/browse/JDK-8335469),
[JDK-8335468](https://bugs.openjdk.org/browse/JDK-8335468))
-
Commit messages:
- check JDK
Hi Davide,
As both Thiago and Johan both mentioned, JavaFX is supported on Wayland
using XWayland. This is the same way that AWT in the core JDK is
supported on Wayland. Your JavaFX applications should run fine on
Wayland, and if they don't, it's a bug that we should fix.
Longer t
Hi,
I had this high on my list a couple of years ago, but because of XWayland I
didn't feel the urgent need to work on it, so it dropped a bit on my
priority list. Thiago did great experimental work in this area, and I
should raise Wayland higher on my list again. It's something I wou
allows X11 applications to run
on Wayland.
Creating a simple state-based display using the pure Wayland protocol is
relatively straightforward (specially with Java 22 and FFM). However,
implementing all the necessary details for a fully functional and
feature-complete Wayland backend is a substantial
As title.
It seems that JavaFX is not fully compliant with Linux Wayland.
Is there an ETA for the complete wayland support?
Thanks
l; 1 mod
8337827: [XWayland] Skip failing tests on Wayland
Reviewed-by: kcr
Backport-of: 0ee74e185673fba03d490122d0560a181ebd6fb2
-
PR: https://git.openjdk.org/jfx23u/pull/34
On Mon, 25 Nov 2024 15:50:40 GMT, Kevin Rushforth wrote:
> I presume you have run the tests? GHA builds aren't enabled for your repo, so
> I can't tell.
Only locally, the `SwingNodeJDialogTest` passes on X11, and skips on Wayland
-
PR Comment: https://git.openjdk
On Mon, 25 Nov 2024 14:29:50 GMT, Alexander Zvegintsev
wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [0ee74e18](https://github.com/openjdk/jfx/commit/0ee74e185673fba03d490122d0560a181ebd6fb2)
> from the [openjdk/jfx](https://git.openjdk.org/jfx) repository.
>
> The r
On Mon, 25 Nov 2024 14:29:50 GMT, Alexander Zvegintsev
wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [0ee74e18](https://github.com/openjdk/jfx/commit/0ee74e185673fba03d490122d0560a181ebd6fb2)
> from the [openjdk/jfx](https://git.openjdk.org/jfx) repository.
>
> The r
Wayland
Changes: https://git.openjdk.org/jfx23u/pull/34/files
Webrev: https://webrevs.openjdk.org/?repo=jfx23u&pr=34&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8337827
Stats: 29 lines in 3 files changed: 23 ins; 5 del; 1 mod
Patch: https://git.openjdk.org/jfx23u/pull
On Wed, 14 Aug 2024 06:21:58 GMT, Alexander Zvegintsev
wrote:
> This changeset introduces the `Util.isOnWayland()` method and skips failing
> tests on Wayland.
>
> After that, all tests run on Wayland without failures.
This pull request has now been integrated.
Changeset: 0ee
On Wed, 14 Aug 2024 06:21:58 GMT, Alexander Zvegintsev
wrote:
> This changeset introduces the `Util.isOnWayland()` method and skips failing
> tests on Wayland.
>
> After that, all tests run on Wayland without failures.
A single reviewer should be enough for this test fix.
-
On Wed, 14 Aug 2024 06:21:58 GMT, Alexander Zvegintsev
wrote:
> This changeset introduces the `Util.isOnWayland()` method and skips failing
> tests on Wayland.
>
> After that, all tests run on Wayland without failures.
Looks good. A full test on our headful Wayland system now
This changeset introduces the `Util.isOnWayland()` method and skips failing
tests on Wayland.
After that, all tests run on Wayland without failures.
-
Commit messages:
- add javadoc
- 8337827: [XWayland] Skip failing tests on Wayland
Changes: https://git.openjdk.org/jfx/pull
Thanks.
-- Kevin
On 4/30/2024 6:41 AM, Thiago Milczarek Sayão wrote:
Hi,
I rewrote the scanner, so it's all my own code now. No legal issues
since I signed the OCA.
Generated java code looks like this:
https://github.com/tsayao/glass-wayland/blob/main/src/com/sun/glass/wayland/extr
Hi,
I rewrote the scanner, so it's all my own code now. No legal issues since I
signed the OCA.
Generated java code looks like this:
https://github.com/tsayao/glass-wayland/blob/main/src/com/sun/glass/wayland/extracted/XdgToplevel.java
-- Thiago.
Em seg., 29 de abr. de 2024 às 19:57,
Thank you.
-- Kevin
On 4/29/2024 2:35 PM, Thiago Milczarek Sayão wrote:
I thought about possible legal conflicts.
The code is on my github - I'm exploring and testing before starting
the real work.
wayland-scanner generates code from the protocol specs, which are xml
files.
I thought about possible legal conflicts.
The code is on my github - I'm exploring and testing before starting the
real work.
wayland-scanner generates code from the protocol specs, which are xml files.
https://wayland.app/protocols/
I will write a new generator/scanner from scratch - it&
create a PR.
-- Kevin
On 4/28/2024 2:45 PM, Thiago Milczarek Sayão wrote:
Hi,
I managed to display a very basic wayland toplevel surface from java:
https://github.com/tsayao/glass-wayland
If you are using intellij, just run the "Test App" (with java 22).
generate.sh will jextract the
Hi,
I managed to display a very basic wayland toplevel surface from java:
https://github.com/tsayao/glass-wayland
If you are using intellij, just run the "Test App" (with java 22).
generate.sh will jextract the code from wayland-client.
I rushed to get the window displayed - so it do
I'm doing some work here:
https://github.com/tsayao/glass-wayland
So far it's been a good experience to use FFM / jextract.
The idea is to plug it as a glass wayland backend when it's good enough.
Em seg., 22 de abr. de 2024 às 16:16, Nir Lisker
escreveu:
> Not sure it
;
> -phil.
>
>
> On 4/22/24 11:45 AM, Thiago Milczarek Sayão wrote:
>
> I think the startup time might be related to all static symbol lookups.
> So I'm manually including just what is needed:
>
> jextract --output src -t com.sun.glass.wayland.extracted \
> --header-
the startup time might be related to all static symbol lookups.
So I'm manually including just what is needed:
jextract --output src -t com.sun.glass.wayland.extracted \
--header-class-name GlassWayland \
`pkg-config --libs glib-2.0 gio-2.0 libportal wayland-client` \
`pkg-config --cfla
I think the startup time might be related to all static symbol lookups.
So I'm manually including just what is needed:
jextract --output src -t com.sun.glass.wayland.extracted \
--header-class-name GlassWayland \
`pkg-config --libs glib-2.0 gio-2.0 libportal wayland-client` \
`pkg-c
we'll be able to bump to Java 25 in JavaFX 25, like
we did with 21. I suggested initially to bump to Java 22 exactly
for FFM as it's very useful for JavaFX, but was told we shouldn't
since it's not an LTS version.
I have no idea how long the work on Wayland will ta
;s
> very useful for JavaFX, but was told we shouldn't since it's not an LTS
> version.
>
> I have no idea how long the work on Wayland will take including the code
> review (a rather long process), but you should be able to request code
> reviews with FFM and have it
d a small test app to explore Wayland client and portals (for
> Robot and dialogs such as file open/save).
>
> https://github.com/tsayao/wayland-test/blob/main/wayland-test.c
<https://urldefense.com/v3/__https://github.com/tsayao/wayland-test/blo
I think that we'll be able to bump to Java 25 in JavaFX 25, like we did
with 21. I suggested initially to bump to Java 22 exactly for FFM as it's
very useful for JavaFX, but was told we shouldn't since it's not an LTS
version.
I have no idea how long the work on Wayland wil
t; On 4/21/2024 10:51 AM, Thiago Milczarek Sayão wrote:
> > Hi,
> >
> > I did a small test app to explore Wayland client and portals (for
> > Robot and dialogs such as file open/save).
> >
> > https://github.com/tsayao/wayland-test/blob/main/wayland-test.c
> >
Note also that we cannot use Panama in the JavaFX internals yet, since
the minimum version of the JDK is 21.
-- Kevin
On 4/21/2024 10:51 AM, Thiago Milczarek Sayão wrote:
Hi,
I did a small test app to explore Wayland client and portals (for
Robot and dialogs such as file open/save
mplex headers there.
Note that jextract generates Java 22 compatible code, which is unusable in
JavaFX for now (we comply with Java 21).
On Mon, Apr 22, 2024 at 1:36 AM Thiago Milczarek Sayão <
thiago.sa...@gmail.com> wrote:
> I mailed the jextract list and Jorn Vernee explained that waylan
I mailed the jextract list and Jorn Vernee explained that wayland use
opaque types, which are just defined as such:
struct wl_registry;
I guess you just pass it around and it's defined in the internal .c file.
Those are not supported by jextract.
I'll find a way to get around it.
But
Can you link to where all the headers are? I found some in
https://gitlab.freedesktop.org/wayland/wayland/-/tree/main/src, but I
couldn't see where wl_registry is defined. From what I see, wl_XYZ types
are structs, which are supported.
By the way, there's a new guide for jextrac
jextract --output src -t org.freedesktop.wayland.client --header-class-name
WlClient `pkg-config --cflags-only-I wayland-client` `pkg-config --libs
wayland-client` /usr/include/wayland-client.h
WARNING: Skipping wl_registry (type Declared(wl_registry) is not supported)
I would need this to hook
What are wl_ types? jextract only supports c headers.
On Sun, Apr 21, 2024 at 10:31 PM Thiago Milczarek Sayão <
thiago.sa...@gmail.com> wrote:
> Hi,
>
> I did a small test app to explore Wayland client and portals (for Robot
> and dialogs such as file open/save).
>
> h
Hi,
I did a small test app to explore Wayland client and portals (for Robot and
dialogs such as file open/save).
https://github.com/tsayao/wayland-test/blob/main/wayland-test.c
It seems it will work as a glass backend, but some walls will be hit on the
way :)
I have tried to use jextract (from
know if it fits the JavaFX
roadmap, or if there are any other efforts on doing it. It's a "step 1" for
wayland support.
This is the initial feedback I was looking for. I'm willing to invest time
on this, but not if it will never be accepted.
-- Thiago.
Em ter., 2 de ab
; 3.8+), and fixes the dragging issue on Wayland.
This pull request has now been integrated.
Changeset: df3707d7
Author:Jose Pereda
URL:
https://git.openjdk.org/jfx/commit/df3707d7444c542ba55a8e76a8ed7e8f0637e874
Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
8320965: Sc
n with GTK
>> 3.8+), and fixes the dragging issue on Wayland.
>
> Jose Pereda has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Revert changes and add touch mask to gdk pointer grab function
All ok.
-
Marked
still works on
> Xorg ?
>
> My tests looks all good (manual and system/robot).
@tsayao yes, I've double checked again. On Wayland and Xorg, I can scroll with
touch events on a touch screen with this fix.
The only issue I still see on Wayland: the mouse cursor location doesn't
On Tue, 20 Feb 2024 12:13:31 GMT, Jose Pereda wrote:
>> Jose Pereda has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Add compile-time checks to GdkSeat
>
> I've just reverted the previous changes, and just applied the touch mask to
> the
On Mon, 19 Feb 2024 11:45:04 GMT, Thiago Milczarek Sayao
wrote:
>> Jose Pereda has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Add compile-time checks to GdkSeat
>
> The rationale was:
>
> This tells which events get delivered to the w
n with GTK
>> 3.8+), and fixes the dragging issue on Wayland.
>
> Jose Pereda has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Revert changes and add touch mask to gdk pointer grab function
Marked as reviewed by kcr (
n with GTK
>> 3.8+), and fixes the dragging issue on Wayland.
>
> Jose Pereda has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Revert changes and add touch mask to gdk pointer grab function
This is a much less intrusive fix.
n with GTK
>> 3.8+), and fixes the dragging issue on Wayland.
>
> Jose Pereda has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Add compile-time checks to GdkSeat
I've just reverted the previous changes, and just appl
> This PR replaces the deprecated `gdk_pointer_grab` with `gdk_seat_grab`, and
> `gdk_pointer_ungrab ` with `gdk_seat_ungrab`, using runtime checks and
> wrapped functions for GTK 3.20+ (so systems without it still run with GTK
> 3.8+), and fixes the dragging issue on Wayland.
Jos
n with GTK
>> 3.8+), and fixes the dragging issue on Wayland.
>
> Jose Pereda has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Add compile-time checks to GdkSeat
I see... so removing all the changes from this PR, and usi
n with GTK
>> 3.8+), and fixes the dragging issue on Wayland.
>
> Jose Pereda has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Add compile-time checks to GdkSeat
The rationale was:
This tells which events get delivered
On Mon, 19 Feb 2024 00:35:48 GMT, Thiago Milczarek Sayao
wrote:
>> Jose Pereda has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Add compile-time checks to GdkSeat
>
> A shot in the dark since I don't own a touch enabled monitor:
>
> Tes
n with GTK
>> 3.8+), and fixes the dragging issue on Wayland.
>
> Jose Pereda has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Add compile-time checks to GdkSeat
A shot in the dark since I don't own a touch enabled moni
n with GTK
>> 3.8+), and fixes the dragging issue on Wayland.
>
> Jose Pereda has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Add compile-time checks to GdkSeat
Maybe this: https://docs.gtk.org/gdk3/enum.CrossingMode
n with GTK
>> 3.8+), and fixes the dragging issue on Wayland.
>
> Jose Pereda has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Add compile-time checks to GdkSeat
Yes, for some reason, after applying the changes from thi
n with GTK
>> 3.8+), and fixes the dragging issue on Wayland.
>
> Jose Pereda has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Add compile-time checks to GdkSeat
It seems when it fails, button press is reported, but bu
n with GTK
>> 3.8+), and fixes the dragging issue on Wayland.
>
> Jose Pereda has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Add compile-time checks to GdkSeat
It seems when it fails it's because `GtkWindow._ungr
n with GTK
>> 3.8+), and fixes the dragging issue on Wayland.
>
> Jose Pereda has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Add compile-time checks to GdkSeat
For me it passes on XWayland and fails on Xorg (with Ubuntu 22
n with GTK
>> 3.8+), and fixes the dragging issue on Wayland.
>
> Jose Pereda has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Add compile-time checks to GdkSeat
So it seems definitely related to the changes in this PR.
n with GTK
>> 3.8+), and fixes the dragging issue on Wayland.
>
> Jose Pereda has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Add compile-time checks to GdkSeat
I'm testing on my local Linux Intel machine (Ubuntu
n with GTK
>> 3.8+), and fixes the dragging issue on Wayland.
>
> Jose Pereda has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Add compile-time checks to GdkSeat
This dropped off my radar.
The only pending issue is the tes
On Mon, 18 Dec 2023 22:00:28 GMT, Kevin Rushforth wrote:
>> Jose Pereda has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Add compile-time checks to GdkSeat
>
> The addition of the compile-time flags looks OK.
>
> I did a build with GTK 3
n with GTK
>> 3.8+), and fixes the dragging issue on Wayland.
>
> Jose Pereda has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Add compile-time checks to GdkSeat
Looks good.
-
Marked as reviewed b
n with GTK
>> 3.8+), and fixes the dragging issue on Wayland.
>
> Jose Pereda has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Add compile-time checks to GdkSeat
I did compile (updating gcc) and test on Ubuntu 16.04 and Ubun
On Mon, 18 Dec 2023 22:00:28 GMT, Kevin Rushforth wrote:
> I did a build with GTK 3.22 (so it compiles the new code, does the dlsym, and
> does the runtime check) and verified that there are no regressions when
> running on an older system (Ubuntu 16.04).
That sounds good.
> If we decide that
On Mon, 18 Dec 2023 10:36:32 GMT, Jose Pereda wrote:
>> That's only if we want to keep building working on 16.04. I think it makes
>> easier to test on it.
>> But, it's already failing for Platform preferences API code.
>
> In any case, if `GdkSeat` is available only since 3.20, then we need to
> This PR replaces the deprecated `gdk_pointer_grab` with `gdk_seat_grab`, and
> `gdk_pointer_ungrab ` with `gdk_seat_ungrab`, using runtime checks and
> wrapped functions for GTK 3.20+ (so systems without it still run with GTK
> 3.8+), and fixes the dragging issue on Wayland.
Jos
On Mon, 18 Dec 2023 21:56:09 GMT, Thiago Milczarek Sayao
wrote:
>> As an FYI, we use GTK 3.22 on our CI build machines so I wouldn't want to
>> see the build-time dependency move any higher than it currently is.
>
> The suggestion was to allow building on 16.04 - so it's easier to test. But
>
On Mon, 18 Dec 2023 21:47:05 GMT, Kevin Rushforth wrote:
>> In any case, if `GdkSeat` is available only since 3.20, then we need to add
>> the compile-time checks anyway, since minimum supported is 3.8.
>
> It seems like this is the best we can do for now. What is means is that we
> won't be ab
On Mon, 18 Dec 2023 21:51:13 GMT, Kevin Rushforth wrote:
>> It seems like this is the best we can do for now. What is means is that we
>> won't be able to build on a system with 3.8 - 3.19 and distribute a library
>> that will use the new functionality when running on 3.20 or later. That's
>>
n with GTK
>> 3.8+), and fixes the dragging issue on Wayland.
>
> Jose Pereda has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Add compile-time checks to GdkSeat
The addition of the compile-time flags looks OK.
I did a buil
On Mon, 18 Dec 2023 10:29:00 GMT, Thiago Milczarek Sayao
wrote:
>> Okay, that is unfortunate (GTK docs inaccurate), but makes sense.
>>
>> I'll add the compile-time checks to `wrapped.c`. But then, using `dlsym`
>> seems redundant, as we can simply call the seat functions directly?
>
> The che
On Mon, 18 Dec 2023 10:34:02 GMT, Thiago Milczarek Sayao
wrote:
>> The check is to allow compilation and test on Ubuntu 16.04 - When shipping
>> the final build it should be built on gtk 3.20+, so both dlsym and the check
>> makes sense.
>>
>> So when running on Ubuntu 16.04:
>> - For testin
On Mon, 18 Dec 2023 10:20:35 GMT, Jose Pereda wrote:
>> I think the docs are wrong, I probably exists since 3.20, so maybe check for
>> `GTK_CHECK_VERSION(3, 20, 0);`.
>>
>>
>> This is the compilation error on Ubuntu 16.04:
>> `/home/tsayao/jose/jfx/modules/javafx.graphics/src/main/native-glas
On Mon, 18 Dec 2023 10:09:29 GMT, Thiago Milczarek Sayao
wrote:
>> I take `GdkSeat` is available since GTK 3.0?
>> https://docs.gtk.org/gdk3/class.Seat.html
>>
>> But don't we have a minimum set on 3.8.0?
>>
>> Would this work?
>>
>> #if GTK_CHECK_VERSION(3, 0, 0)
>> static GdkSeat * (*_gdk_
On Mon, 18 Dec 2023 09:46:23 GMT, Jose Pereda wrote:
>> modules/javafx.graphics/src/main/native-glass/gtk/wrapped.c line 197:
>>
>>> 195: return TRUE;
>>> 196: }
>>> 197: return FALSE;
>>
>> I did try to test on Ubuntu 16.04 and compilation failed (no surprise
>> because `GdkSe
On Mon, 18 Dec 2023 09:46:23 GMT, Jose Pereda wrote:
>> modules/javafx.graphics/src/main/native-glass/gtk/wrapped.c line 197:
>>
>>> 195: return TRUE;
>>> 196: }
>>> 197: return FALSE;
>>
>> I did try to test on Ubuntu 16.04 and compilation failed (no surprise
>> because `GdkSe
On Sat, 16 Dec 2023 22:21:55 GMT, Thiago Milczarek Sayao
wrote:
>> Jose Pereda has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> remove compile-time if checks
>
> modules/javafx.graphics/src/main/native-glass/gtk/wrapped.c line 197:
>
>>
n with GTK
>> 3.8+), and fixes the dragging issue on Wayland.
>
> Jose Pereda has updated the pull request incrementally with one additional
> commit since the last revision:
>
> remove compile-time if checks
modules/javafx.graphics/src/main/native-glass/gtk/wrapped.c line
On Thu, 14 Dec 2023 20:13:36 GMT, Jose Pereda wrote:
>> modules/javafx.graphics/src/main/native-glass/gtk/glass_general.cpp line 599:
>>
>>> 597: return TRUE;
>>> 598: }
>>> 599: #if GTK_CHECK_VERSION(3, 20, 0)
>>
>> I wouldn't have expected any compile-time `#if` checks as part of
n with GTK
>> 3.8+), and fixes the dragging issue on Wayland.
>
> Jose Pereda has updated the pull request incrementally with one additional
> commit since the last revision:
>
> remove compile-time if checks
This now looks like what I would expect. I'll test it, mainly
> This PR replaces the deprecated `gdk_pointer_grab` with `gdk_seat_grab`, and
> `gdk_pointer_ungrab ` with `gdk_seat_ungrab`, using runtime checks and
> wrapped functions for GTK 3.20+ (so systems without it still run with GTK
> 3.8+), and fixes the dragging issue on Wayland.
Jos
still run with GTK
>> 3.8+), and fixes the dragging issue on Wayland.
>
> modules/javafx.graphics/src/main/native-glass/gtk/glass_general.cpp line 599:
>
>> 597: return TRUE;
>> 598: }
>> 599: #if GTK_CHECK_VERSION(3, 20, 0)
>
> I wouldn't have ex
; 3.8+), and fixes the dragging issue on Wayland.
We want the ability to build this on a system that may or may not have GTK
3.20, and then to have the binary produced by the build be able to run on a
system that may or may not have GTK 3.20, using the new function if available.
This means that
This PR replaces the deprecated `gdk_pointer_grab` with `gdk_seat_grab`, and
`gdk_pointer_ungrab ` with `gdk_seat_ungrab`, using runtime checks and wrapped
functions for GTK 3.20+ (so systems without it still run with GTK 3.8+), and
fixes the dragging issue on Wayland.
-
Commit
Hi,
Been doing some experiments.
It should be possible (and the best way to go) to use wayland-client
without gtk.
Desktop iterations should be done with libportal (such as file dialogs):
https://libportal.org/
It is possible to implement the Robot with libportal "RemoteDesktop&quo
Hi,
It seems there are some opportunities to explore with Wayland:
For kiosks (Ubuntu frame):
https://mir-server.io/
https://wayland.app/protocols/
There are some interesting extensions such as Tizen (samsung OS) and
"In-vehicle infotainment": https://wayland.app/protocols/ivi-app
://docs.flatpak.org/pt-br/latest/portal-api-reference.html#gdbus-org.freedesktop.portal.Screenshot
Haven't tested anything yet.
I did some experiments on the jfx-sandbox (it displays the window on
wayland with software rendering), but the conclusion so far is that it's
better to ditch gtk and u
Hi Thiago,
Thanks for the work on Wayland. I spent some time on it in the past as
well, and I'll hope to find some time to look at your work soon.
The main worry I had in the past was how to deal with the robot, where we
need to get pixels from the screen -- did you tackle that?
- Johan
O
Hi,
About Wayland:
Porting es2 to use EGL instead of GLX is pretty straightforward, so
converting a X11GL* to WaylandGL* is easy (GLX is X11 only, so this is why
EGL is needed).
The problem is Gtk4 and/or Gtk3 with Wayland won't allow you to paint
directly to the window as es2 do.
I'v
EGL is the way to go for Linux on Wayland and X11.
I don't know how to do it yet, but it seems the solution is to use DMABUF
with EGL and share it with GTK (I suspect on a GtkGLArea widget, but not
sure yet).
Firefox and WebKit GTK uses the same technic.
Gtk4 does not allow application pai
1 - 100 of 103 matches
Mail list logo
