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.
>
> 1) Replaced GDK
Hi,
https://github.com/openjdk/jfx-sandbox/tree/tsayao_wayland
I did some experiments here. So far, so good.
1) Replaced GDK events for Gtk Signals - It's the way to go for newer gtk.
2) Replaced drawing directly in the window and added a GtkDrawingArea with
a GtkHeaderBar which allows control
On Sun, 15 Oct 2023 13:25:15 GMT, Thiago Milczarek Sayao
wrote:
>> The bug on the title happens because `gtk_widget_realize()` was called on
>> the constructor. It creates the internal underlying window `GdkWindow` and
>> `XWindow` messing the Gtk expected order. It actually it's probably a
> It looks like a condition between calls from `set_visible` to
> `request_focus`. When `request_focus` is called, the window is not yet mapped
> (map is requested on `set_visible`).
>
> 200x200 is the default gtk window size if none is specified. Since the window
> is presented at the
On Sun, 15 Oct 2023 00:32:47 GMT, Thiago Milczarek Sayao
wrote:
>> It looks like a condition between calls from `set_visible` to
>> `request_focus`. When `request_focus` is called, the window is not yet
>> mapped (map is requested on `set_visible`).
>>
>> 200x200 is the default gtk window
Hi Andy,
Sorry for the late reply but unfortunately I didn't have time to respond to
you earlier.
Yes, you're right, Swing did allow for easier extension of controls' themes
and you did see people coming up with new theme libraries that overwrote
Controls appearance/behavior through code.
I
Hi,
I reported a JVM crash in here
https://github.com/adoptium/adoptium-support/issues/919
It seems related to webkit. Can you help me with this ?
Thank you,
Rahman Usta
