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/extracted
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, Kevin
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.
https
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's
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 helps with war
-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-class-name Glas
up 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 --cflags-only-I glib-
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-config
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 will take including
ry 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 ready for integratio
o 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/blob/main/wayland-test.
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 will take including
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
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 wayland use
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 I've been
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 jextract at
https
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
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 abr. de 2024 às 09:45, Luka
TK
> 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
832096
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
l 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 get
updated f
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
>
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
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 intrus
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 applied t
> 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:
>
>
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 m
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
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._ungrabFoc
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
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
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
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
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
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:
>>
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 *
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
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
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 to lo
> 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 expecte
TK
> 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 use wayland
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
On Fri
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've tried
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 painting
Hi,
I am investigating about prism on Wayland.
It looks like we could just replace the GLX calls on X11 backend to EGL and
it will work on both (maybe rename it).
It will need some work to pass the native display around - it assumes X11
Display everywhere and it could be a Display
Hi,
Update: It now works on wayland with -Dprism.order=sw
Em dom., 15 de out. de 2023 às 10:49, Thiago Milczarek Sayão <
thiago.sa...@gmail.com> escreveu:
> Hi,
>
> https://github.com/openjdk/jfx-sandbox/tree/tsayao_wayland
>
> I did some experiments here. So far, so good
over the whole window
size and allows to get rid of extents* calls - this cleans up a lot.
3) Unified the WindowContext to clean it up.
I also integrated the IME replacement proposed here:
https://github.com/openjdk/jfx/pull/1080
It almost runs with software rendering on Wayland, but something
77 matches
Mail list logo
