Re: Updating printers while application is running?
Hi, I use it through the javax.print API: ObservableList printServices = FXCollections.observableArrayList( PrintServiceLookup.lookupPrintServices(null, null)); Maybe it may help for now, but to me it seems it should not be static. Em ter., 7 de jun. de 2022 às 15:39, Tobias Oelgarte < tobias.oelga...@gmail.com> escreveu: > Is there some way to update the ObservableSet of Printers once the > Application is running? Calling Printer.getAllPrinters() always returns > the same OberservableSet and it does not change - ever. [1] > > We have an JavaFx based application running under Windows 10/11 that is > used to print on wireless printers, that are not always available. > Having to restart the the application every time a printer goes away or > comes available is a serious pain for the users. > > Is there any kind of workaround? > > I doubt it will be fixed in the near future, since this comment is from > 6 years ago [2]: > > // This is static. Eventually I want it to be dynamic, but first > // it needs to be enhanced to only create new instances where > // there really has been a change, which will be rare. > > [1] > > https://stackoverflow.com/questions/38470568/javafx-doesnt-detect-changes-of-available-printers > > [2] > > https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/com/sun/prism/j2d/PrismPrintPipeline.java#L99 >
Re: @font-face question
Hi,
After further investigation, I think there's a bug that font-family is not
working (defining a font family name).
Because regardless of the font-family I use, the font name within the font
is used.
It's openjfx 17.0.2
-- Thiago.
Em sex., 20 de mai. de 2022 às 18:06, Thiago Milczarek Sayão <
thiago.sa...@gmail.com> escreveu:
> Hi,
>
> I want to have one font that is "regular" and a variation of the same font
> as "bold", used when specified "-fx-font-weight: bold".
>
> @font-face {
> font-family: 'Gotham Condensed';
> src: url('../fonts/GothamCondensed-Book.otf');
> }
>
> @font-face {
> font-family: 'Gotham Condensed Bold';
> src: url('../fonts/GothamCondensed-Bold.otf');
> }
>
>
> .text {
> -fx-font-family: 'Gotham Condensed';
> }
>
> I have searched online and there are many variations such as:
>
> - @font-face "font-family" is ignored and you have to use the real font
> name;
> - If you use 'Bold' as a suffix, javafx will use it as bold;
> - you have to specify "font-weight: bold" on the @font-face
>
> The last one is what seems that the CSS specs says, but does not seem to
> work.
>
> Is it possible?
>
> Thanks.
>
>
@font-face question
Hi,
I want to have one font that is "regular" and a variation of the same font
as "bold", used when specified "-fx-font-weight: bold".
@font-face {
font-family: 'Gotham Condensed';
src: url('../fonts/GothamCondensed-Book.otf');
}
@font-face {
font-family: 'Gotham Condensed Bold';
src: url('../fonts/GothamCondensed-Bold.otf');
}
.text {
-fx-font-family: 'Gotham Condensed';
}
I have searched online and there are many variations such as:
- @font-face "font-family" is ignored and you have to use the real font
name;
- If you use 'Bold' as a suffix, javafx will use it as bold;
- you have to specify "font-weight: bold" on the @font-face
The last one is what seems that the CSS specs says, but does not seem to
work.
Is it possible?
Thanks.
Re: Xlib backend
Hi,
Did some improvements on my "pure x11" branch:
- Bitmaps are now handled by cairo which will use Xrender if available
(will be beneficial if there's an alpha channel).
- Configuration using Xsettings (such as double click time)
- Setting the app icon now works
- Custom cursor works
- Mouse button works
- Able to launch Ensemble8 (with random crashes).
Interesting thing is that there's no need to convert BGRA -> RGBA. Not sure
if it's a big performance improvement.
It seems the only thing that will be missing to completely ditch gtk are
the "common dialogs" such as file open, etc.
I'm also investigating Wayland. It's somewhat similar to Xorg when it comes
to events and the use of XDG specs. Probably will replace cairo with egl.
-- Thiago.
Em dom., 24 de abr. de 2022 às 17:40, Thiago Milczarek Sayão <
thiago.sa...@gmail.com> escreveu:
> Hi,
>
> Xlib port at:
> https://github.com/openjdk/jfx-sandbox/tree/tsayao_xlib
>
> Is able to very poorly run Ensemble8:
> java @build/run.args -jar apps/samples/Ensemble8/dist/Ensemble8.jar
>
> Keyboard events still do not work, mouse clicks are still buggy.
> There will be crashes, but it's progress.
> Window size & positioning is better now.
>
> I am painting directly like this:
>
> void WindowContextBase::paint(void* data, jint width, jint height) {
> Pixmap pixmap = XCreatePixmapFromBitmapData(display,
> DefaultRootWindow(display), (char *) data, width, height, 0, 0, depth);
> XCopyPlane(display, pixmap, xwindow, DefaultGC(display,
> DefaultScreen(display)), 0, 0, width, height, 0, 0, 1);
>
> XFlush(display);
> XFreePixmap(display, pixmap);
> }
>
> It does flicker a little, maybe it needs XSync extension to draw together
> with WM, maybe some kind of buffering.
> Using cairo is possible, but it's a final render, not sure if there will
> be advantages.
>
> I am accepting opinions.
>
>
> -- Thiago.
>
> Em ter., 12 de abr. de 2022 às 03:22, escreveu:
>
>>
>> Hi Thiago,
>>
>> I wholly agree.
>>
>> If gtk can be taken out of the equation it will reduce dependencies
>> significantly. Like we had with gtk2 vs. 3 in JavaFX/Swing
>> cross-embedding. Moving to gtk3 would start this all over again
>> whereas plain Xlib should remain fully compatible regardless of the
>> gtk version used by Swing (or SWT or whatever).
>>
>> I'll gladly help with testing - just ping me when you've got a
>> version that is reasonably stable.
>>
>> Best regards,
>> Greg
>>
>> Thiago Milczarek Sayão writes:
>>
>> > Kevin,
>> >
>> > Sure, I was hoping for the question.
>> >
>> > "The focus of GTK has moved away from being a “meta toolkit” that other
>> > toolkits can use as a “backend”."
>> >
>> > Quoted from
>> >
>> https://discourse.gnome.org/t/gtk4-migration-window-management-functions-gone/7542/4
>> >
>> > The first attempt I have made is the logical one, gtk4:
>> > https://github.com/openjdk/jfx-sandbox/tree/tsayao_gtk4_playground
>> >
>> > Then I have discovered it's not possible to use gtk4 without Xlib and
>> that
>> > many window management functions are gone (see the quotation link).
>> > In addition to this:
>> > - Gtk4 cannot draw directly on the window or set the background without
>> > gtk4 css;
>> > - It cannot even move the window, just tell the compositor it started a
>> > move.
>> >
>> > I also have played plenty with gtk3, it breaks a lot of things thru the
>> 3.x
>> > release cycle, such as DND.
>> >
>> > So, I see no reason to use Gtk if Xlib fits better as a glass backend
>> (has
>> > all the needed functions) and Gtk would use Xlib anyway and hide much
>> > needed functionality.
>> >
>> > Current glass Gtk backend already touches a lot of Xlib.
>> >
>> > Wayland is fully compatible with Xlib, so we can work on "both worlds"
>> with
>> > it. Someday on the future a pure Wayland backend would be nice.
>> >
>> > I'm happy to answer any further questions.
>> >
>> > -- Thiago.
>> >
>> >
>> >
>> >
>> > Em seg., 11 de abr. de 2022 às 12:41, Kevin Rushforth <
>> > kevin.rushfo...@oracle.com> escreveu:
>> >
>> >> Can you say more about the motivation for doing this? Given the
>> eventual
>> >> direction for Wayland support, even in X11 compatibility mode, I would
>> >> expect more use of gtk and less use of Xlib, not t
kenai closed
Hi, http://duke.kenai.com/misc/DrinkingBeer.jpg This is on HelloImage.java A quick search for "kenai.com" shows some entries, mostly commented. -- Thiago.
Re: Xlib backend
Hi,
Xlib port at:
https://github.com/openjdk/jfx-sandbox/tree/tsayao_xlib
Is able to very poorly run Ensemble8:
java @build/run.args -jar apps/samples/Ensemble8/dist/Ensemble8.jar
Keyboard events still do not work, mouse clicks are still buggy.
There will be crashes, but it's progress.
Window size & positioning is better now.
I am painting directly like this:
void WindowContextBase::paint(void* data, jint width, jint height) {
Pixmap pixmap = XCreatePixmapFromBitmapData(display,
DefaultRootWindow(display), (char *) data, width, height, 0, 0,
depth);
XCopyPlane(display, pixmap, xwindow, DefaultGC(display,
DefaultScreen(display)), 0, 0, width, height, 0, 0, 1);
XFlush(display);
XFreePixmap(display, pixmap);
}
It does flicker a little, maybe it needs XSync extension to draw together
with WM, maybe some kind of buffering.
Using cairo is possible, but it's a final render, not sure if there will be
advantages.
I am accepting opinions.
-- Thiago.
Em ter., 12 de abr. de 2022 às 03:22, escreveu:
>
> Hi Thiago,
>
> I wholly agree.
>
> If gtk can be taken out of the equation it will reduce dependencies
> significantly. Like we had with gtk2 vs. 3 in JavaFX/Swing
> cross-embedding. Moving to gtk3 would start this all over again
> whereas plain Xlib should remain fully compatible regardless of the
> gtk version used by Swing (or SWT or whatever).
>
> I'll gladly help with testing - just ping me when you've got a
> version that is reasonably stable.
>
> Best regards,
> Greg
>
> Thiago Milczarek Sayão writes:
>
> > Kevin,
> >
> > Sure, I was hoping for the question.
> >
> > "The focus of GTK has moved away from being a “meta toolkit” that other
> > toolkits can use as a “backend”."
> >
> > Quoted from
> >
> https://discourse.gnome.org/t/gtk4-migration-window-management-functions-gone/7542/4
> >
> > The first attempt I have made is the logical one, gtk4:
> > https://github.com/openjdk/jfx-sandbox/tree/tsayao_gtk4_playground
> >
> > Then I have discovered it's not possible to use gtk4 without Xlib and
> that
> > many window management functions are gone (see the quotation link).
> > In addition to this:
> > - Gtk4 cannot draw directly on the window or set the background without
> > gtk4 css;
> > - It cannot even move the window, just tell the compositor it started a
> > move.
> >
> > I also have played plenty with gtk3, it breaks a lot of things thru the
> 3.x
> > release cycle, such as DND.
> >
> > So, I see no reason to use Gtk if Xlib fits better as a glass backend
> (has
> > all the needed functions) and Gtk would use Xlib anyway and hide much
> > needed functionality.
> >
> > Current glass Gtk backend already touches a lot of Xlib.
> >
> > Wayland is fully compatible with Xlib, so we can work on "both worlds"
> with
> > it. Someday on the future a pure Wayland backend would be nice.
> >
> > I'm happy to answer any further questions.
> >
> > -- Thiago.
> >
> >
> >
> >
> > Em seg., 11 de abr. de 2022 às 12:41, Kevin Rushforth <
> > kevin.rushfo...@oracle.com> escreveu:
> >
> >> Can you say more about the motivation for doing this? Given the eventual
> >> direction for Wayland support, even in X11 compatibility mode, I would
> >> expect more use of gtk and less use of Xlib, not the other way around.
> >>
> >> -- Kevin
> >>
> >> On 4/10/2022 2:43 PM, Thiago Milczarek Sayão wrote:
> >> > Hi,
> >> >
> >> > I got simple samples running on the pure Xlib port of the Gtk backend.
> >> >
> >> > It still has gtk code, but mainly uses Xlib by now. Don't judge the
> code,
> >> > I'm porting it gradually.
> >> >
> >> > https://github.com/openjdk/jfx-sandbox/tree/tsayao_xlib
> >> >
> >> > java @build/run.args -cp apps/toys/Hello/dist/Hello.jar
> >> hello.HelloCursors
> >> >
> >> > Window coordinates and sizes are still off a bit, so you might have to
> >> > resize the window to redraw.
> >> >
> >> > -- Thiago.
> >>
> >>
>
> --
> Gregor Schmid
>
> E: gregor.sch...@qfs.de
> T: +49 8171 38648-11
> F: +49 8171 38648-16
>
> Quality First Software GmbH | www.qfs.de
> Bürgermeister-Graf-Ring 10 | 82538 Geretsried | Germany
> GF Gregor Schmid, Karlheinz Kellerer
> HRB München 140833
>
> The data protection information in accordance with the EU General Data
> Protection Regulation applies to authorized representatives /
> authorized representatives of "legal persons" in accordance with Art.
> 12 ff. DS-GVO
> https://www.qfs.de/fileadmin/Webdata/pdf/en/dsgvo.pdf
>
Re: Xlib backend
Kevin, Sure, I was hoping for the question. "The focus of GTK has moved away from being a “meta toolkit” that other toolkits can use as a “backend”." Quoted from https://discourse.gnome.org/t/gtk4-migration-window-management-functions-gone/7542/4 The first attempt I have made is the logical one, gtk4: https://github.com/openjdk/jfx-sandbox/tree/tsayao_gtk4_playground Then I have discovered it's not possible to use gtk4 without Xlib and that many window management functions are gone (see the quotation link). In addition to this: - Gtk4 cannot draw directly on the window or set the background without gtk4 css; - It cannot even move the window, just tell the compositor it started a move. I also have played plenty with gtk3, it breaks a lot of things thru the 3.x release cycle, such as DND. So, I see no reason to use Gtk if Xlib fits better as a glass backend (has all the needed functions) and Gtk would use Xlib anyway and hide much needed functionality. Current glass Gtk backend already touches a lot of Xlib. Wayland is fully compatible with Xlib, so we can work on "both worlds" with it. Someday on the future a pure Wayland backend would be nice. I'm happy to answer any further questions. -- Thiago. Em seg., 11 de abr. de 2022 às 12:41, Kevin Rushforth < kevin.rushfo...@oracle.com> escreveu: > Can you say more about the motivation for doing this? Given the eventual > direction for Wayland support, even in X11 compatibility mode, I would > expect more use of gtk and less use of Xlib, not the other way around. > > -- Kevin > > On 4/10/2022 2:43 PM, Thiago Milczarek Sayão wrote: > > Hi, > > > > I got simple samples running on the pure Xlib port of the Gtk backend. > > > > It still has gtk code, but mainly uses Xlib by now. Don't judge the code, > > I'm porting it gradually. > > > > https://github.com/openjdk/jfx-sandbox/tree/tsayao_xlib > > > > java @build/run.args -cp apps/toys/Hello/dist/Hello.jar > hello.HelloCursors > > > > Window coordinates and sizes are still off a bit, so you might have to > > resize the window to redraw. > > > > -- Thiago. > >
Xlib backend
Hi, I got simple samples running on the pure Xlib port of the Gtk backend. It still has gtk code, but mainly uses Xlib by now. Don't judge the code, I'm porting it gradually. https://github.com/openjdk/jfx-sandbox/tree/tsayao_xlib java @build/run.args -cp apps/toys/Hello/dist/Hello.jar hello.HelloCursors Window coordinates and sizes are still off a bit, so you might have to resize the window to redraw. -- Thiago.
Self built openjfx 17.0.2
Hi, Does the "jfx17" branch contain the latest javafx 17.0.2 code ? https://github.com/openjdk/jfx/tree/jfx17 Also, I have built jmods of this branch with "gradlew jmodLinux" and the resulting jmods are quite bigger comparing to the released ones. I guess it's some debug symbols or something. Should I add any argument? I want the 17.0.2 with one applied extra patch. Thanks. -- Thiago
Re: Use pure X11 backend for glass native
Hi, So far, it seems native Xlib is a good fit: https://github.com/openjdk/jfx-sandbox/tree/tsayao_xlib It's still a big mess since I'm porting gradually while learning X11. -- Thiago. Em ter., 25 de jan. de 2022 às 12:06, Thiago Milczarek Sayão < thiago.sa...@gmail.com> escreveu: > > I put some thoughts on Linux glass backend and I think a pure Xlib backend > would be the ideal choice. > > Why? > > 1. X11/Xlib is supported by Xwayland, so it will work for decades > (probably). Having two backends to support for one platform would not be > ideal, so sticking with X11 would be the most "compatible choice". I will > probably be forever supported, since many applications rely on it. > > 2. Gdk4 moved away from being a "general toolkit layer" to being a "gtk4 > platform abstraction layer", so many things are missing such as: > - Moving windows; > - Drawing directly on a window; > - Relative window positioning; > - Changing window stacking; > - Pointer warping; > > Glass needs it, so it would be required to use a Xlib call anyways, since > Xwayland currently does not support those operations as well (except > through the X11 compatibility layer). > > Newer gtk3 versions deprecate a lot of functions and make a path to gtk4, > so even gtk3 is hard to use. > > 3. It would be possible to migrate from gtk3 to Xlib progressively since > Gdk3 with X11 backend translates to Xlib calls; > > 4. It would drop the gtk dependency (except for webkit-gtk). OS-specific > dialogs such as file save would be a problem (but not too hard to solve I > think). > > > References: > https://www.x.org/releases/current/doc/libX11/libX11/libX11.html > > https://discourse.gnome.org/t/gtk4-migration-window-management-functions-gone/7542/9 > https://discourse.gnome.org/t/custom-drawing-with-gtk4/7737 > > >
Thank you for JavaFX
Hi, Just wanted to share, the software on this pharmacy store has all it's frontend on JavaFX, including the self checkout, that doesn't look like a traditional desktop app yet uses pure JavaFX (customized with css). https://ndmais.com.br/saude/joinville-ganha-uma-farmacia-do-futuro-entenda/ Thank you.
Gtk4 on openjfx-sandbox
Hi, I have done some porting to gtk4: https://github.com/openjdk/jfx-sandbox/tree/tsayao_gtk4_playground It currently compiles, but does not show any windows (I suspect of an threading issue). Some parts such as DND are commented out. To use it, pass: -Djdk.gtk.version=4 -Djdk.gtk.verbose=true -- Thiago.
Re: Gtk4 and Wayland
Hi, It seems it would be very hard to have gtk4 and/or Wayland on JavaFX, unless we stop doing window manager related things. Resizing the window would be possible, but not stacking or moving it around. Wayland simply does not have this functionality and gtk4 removed it as well, as pointed out here https://gnome.pages.gitlab.gnome.org/gtk/gtk4/migrating-3to4.html#adapt-to-gdkwindow-api-changes and here: https://discourse.gnome.org/t/gtk4-migration-window-management-functions-gone/7542/4 Even on gtk3 it's a hard thing to do (deal with stacking and positioning). So I agree with the Gtk developers position to simply not deal with window management at this level, but it's somehow unfortunate. On the "experimenting with gtk4" side, it seems like I hit a dead end because gtk4 does not provide the needed functionality nor Wayland (to deal with it directly). Sticking with X11 also seems like not optimal for the long term, it will be replaced eventually. Maybe JavaFX should move away from window management as well? -- Thiago. Em qua., 1 de set. de 2021 às 08:42, Kevin Rushforth < kevin.rushfo...@oracle.com> escreveu: > This seems reasonable to me as well, at least for JavaFX since we > already rely on Gtk for most of the windowing toolkit on Linux. > > -- Kevin > > On 9/1/2021 4:26 AM, Mario Torre wrote: > > On Wed, Sep 1, 2021 at 1:18 PM Johan Vos wrote: > >> Hi Thiago, > >> > >> I was thinking (and experimenting) in the same direction, and so far > that > >> is working good. I don't see disadvantages, but it would be good to find > >> out about it before we move forward. > >> Maybe the main issue to me is that GTK comes with lots of dependencies. > We > >> already have that situation today, so it is not going to be worse. But > if > >> we would use the Wayland protocol on a lower level (with a > Wayland-specific > >> glass platform, instead of GTK), we could probably reduce the > dependencies. > >> However, this comes at the price of creating *and maintaining* more > >> low-level code. > >> > >> I've been running GTK3 on Wayland and that works fine too. However, it > >> might be better to focus Wayland support for GTK4. I think there won't > be > >> many installs that have no X11, but only Wayland, and that have GTK3 > and no > >> GTK4. > > I tend to agree with you, I think we should consider this for Wakefield > too. > > > > Cheers, > > Mario > > > >> - Johan > >> - Johan > >> > >> On Tue, Aug 31, 2021 at 11:03 PM Thiago Milczarek Sayão < > >> thiago.sa...@gmail.com> wrote: > >> > >>> Hi, > >>> > >>> I did some investigation on gtk4 and wayland. > >>> > >>> After some research I ended up with the conclusion that the best way > is to > >>> do a separate gtk4 backend, that would support X11 and Wayland. > >>> > >>> This would be a good start: > >>> https://github.com/openjdk/jfx/pull/77/files > >>> > >>> Why? > >>> > >>> Gtk4 moves the decoration to the client side, which is GREAT since > knowing > >>> the window size with decoration was a real pain. > >>> > >>> We probably won't want to do all the decoration work, Gtk does that, > but on > >>> GtkWindow level, not GdkSurface (which replaces GdkWindow). > >>> > >>> Thus the move to use "more Gtk" (hence "less Gdk") which is exactly > what > >>> the PR does. It also removes Applet code > >>> > >>> This is also a good starting point: > >>> https://gnome.pages.gitlab.gnome.org/gtk/gtk4/migrating-3to4.html > >>> > >>> --Thiago. > >>> > > > >
Re: Announcing the new jfx-sandbox repo
I just started moving things around after reading the gtk docs (specially gtk3 to 4 porting). It does not compile yet. Will focus on windowing code first. - Thiago. Em seg., 13 de set. de 2021 às 06:11, Johan Vos escreveu: > I created a johanvos-gtk3-wayland branch and that worked. I will add a > commit soon with a diff for the Robot API. > I will have a look at Thiago's gtk4 branch as well. > > - Johan > > On Mon, Sep 13, 2021 at 12:52 AM Thiago Milczarek Sayão < > thiago.sa...@gmail.com> wrote: > >> Hi Kevin, >> >> https://github.com/tsayao/jfx-sandbox/tree/tsayao_gtk4_playground >> >> I have started this as an experiment to make a gtk4 version of the native >> lib. >> >> I did a fork because I don't have permission to branch on jfx-sandbox (or >> maybe I did something wrong). >> >> @Johan Vos has stated that he is experimenting >> too, maybe we can join forces. >> >> -- Cheers >> >> >> >> >> Em sex., 10 de set. de 2021 às 12:12, Kevin Rushforth < >> kevin.rushfo...@oracle.com> escreveu: >> >>> We have created a new jfx-sandbox repo: >>> >>> https://github.com/openjdk/jfx-sandbox >>> >>> This repository serves the same purpose as the jdk-sandbox: It allows >>> multiple OpenJFX Committers to collaborate on larger shared fixes, >>> prototypes, or projects. By way of example, it could be used for a macOS >>> Metal pipeline, a GTK 4 platform, or Wayland. >>> >>> All OpenJFX Committers have direct push access to the jfx-sandbox repo >>> (just like the JDK Committers do for jdk-sandbox). >>> >>> General rules and guidelines: >>> >>> There are only two hard-and-fast rules that must be observed: >>> >>> 1. Don't push any commits to the master branch and don't open a PR >>> against master. The master branch is continuously mirrored from the >>> jfx:master branch and should be considered read-only in jfx-sandbox. >>> >>> 2. Don't push to someone else's branch without talking to them first. >>> >>> And a couple general guidelines that will make this a more pleasant >>> place to play: >>> >>> 3. Unless this is intended to be a shared, semi-formal project (e.g., >>> metal, gtk4, wayland-x11, wayland-native), please prefix the name of >>> your branch with either a JBS bug ID or your openjdk username. >>> >>> 4. Don't force push to a branch without getting consensus among the >>> collaborators. >>> >>> Let me know if you have any questions. >>> >>> -- Kevin >>> >>>
Re: Announcing the new jfx-sandbox repo
Hi Kevin, https://github.com/tsayao/jfx-sandbox/tree/tsayao_gtk4_playground I have started this as an experiment to make a gtk4 version of the native lib. I did a fork because I don't have permission to branch on jfx-sandbox (or maybe I did something wrong). @Johan Vos has stated that he is experimenting too, maybe we can join forces. -- Cheers Em sex., 10 de set. de 2021 às 12:12, Kevin Rushforth < kevin.rushfo...@oracle.com> escreveu: > We have created a new jfx-sandbox repo: > > https://github.com/openjdk/jfx-sandbox > > This repository serves the same purpose as the jdk-sandbox: It allows > multiple OpenJFX Committers to collaborate on larger shared fixes, > prototypes, or projects. By way of example, it could be used for a macOS > Metal pipeline, a GTK 4 platform, or Wayland. > > All OpenJFX Committers have direct push access to the jfx-sandbox repo > (just like the JDK Committers do for jdk-sandbox). > > General rules and guidelines: > > There are only two hard-and-fast rules that must be observed: > > 1. Don't push any commits to the master branch and don't open a PR > against master. The master branch is continuously mirrored from the > jfx:master branch and should be considered read-only in jfx-sandbox. > > 2. Don't push to someone else's branch without talking to them first. > > And a couple general guidelines that will make this a more pleasant > place to play: > > 3. Unless this is intended to be a shared, semi-formal project (e.g., > metal, gtk4, wayland-x11, wayland-native), please prefix the name of > your branch with either a JBS bug ID or your openjdk username. > > 4. Don't force push to a branch without getting consensus among the > collaborators. > > Let me know if you have any questions. > > -- Kevin > >
Gtk4 and Wayland
Hi, I did some investigation on gtk4 and wayland. After some research I ended up with the conclusion that the best way is to do a separate gtk4 backend, that would support X11 and Wayland. This would be a good start: https://github.com/openjdk/jfx/pull/77/files Why? Gtk4 moves the decoration to the client side, which is GREAT since knowing the window size with decoration was a real pain. We probably won't want to do all the decoration work, Gtk does that, but on GtkWindow level, not GdkSurface (which replaces GdkWindow). Thus the move to use "more Gtk" (hence "less Gdk") which is exactly what the PR does. It also removes Applet code This is also a good starting point: https://gnome.pages.gitlab.gnome.org/gtk/gtk4/migrating-3to4.html --Thiago.
Re: Why GTK4 glass backend will not (probably) be an #IFDEF
Correction: * Gdk Surface would be used instead of *Gdk*Window. * GtkDrawingArea widget would be used to draw fx data. Also, after further investigation libwayland is a no, too much work, specially because client side decorations. So for wayland we should stick with Gtk (a greater gtk3 version than 3.8) or starting from Gtk4. -- Thiago. Em sáb., 14 de ago. de 2021 às 18:41, Thiago Milczarek Sayão escreveu: > > Gtk4 glass implementation will probably be a new glass implementation > based on the current one because there are too many "breaking" > changes. > > Changes are listed here: > https://docs.gtk.org/gtk4/migrating-3to4.html > > Specially note: > https://docs.gtk.org/gtk4/migrating-3to4.html#adapt-to-gtkwindow-api-changes > (*) > https://docs.gtk.org/gtk4/migrating-3to4.html#stop-using-gtk_widget_set_app_paintable > (*) > https://docs.gtk.org/gtk4/migrating-3to4.html#stop-using-grabs > https://docs.gtk.org/gtk4/migrating-3to4.html#stop-using-non-rgba-visuals > https://docs.gtk.org/gtk4/migrating-3to4.html#switch-to-the-new-drag-and-drop-api > > * Gdk Surface would be used instead of Gtk Window. > > Backend (Wayland/X11) specific functions will be needed: > https://docs.gtk.org/gtk4/migrating-3to4.html#adapt-to-monitor-api-changes > https://docs.gtk.org/gdk4/wayland.html > > Looking at the Gdk4 implementation, using libwayland* directly would > be nice, but simply too hard. So we could use Gtk4 to support wayland > and #ifdef GDK_WINDOWING_X11 / GDK_WINDOWING_WAYLAND where necessary. > > On another note, XTest equivalent (for Robot) is not available on > generic wayland compositors. > > -- Thiago.
Gtk3 minimum required version
Hi, Currently the minimum required version is 3.8. Beginning on 3.10 Gtk added support for client-side decorations and the GtkHeaderBar is the default widget to do that. https://docs.gtk.org/gtk3/ctor.HeaderBar.new.html Gtk 3.10 was released Sep/2013. Gtk4 and Gnome apps default to this behaviour. By using it we may be able to get rid of the window sizing problem on glass-gtk which is "decoration sizes" thru _NET_FRAME_EXTENTS which is very error prone (it depends on each window manager). Currently it does a lot of work-arounds to size the window properly because the server does the decoration so there is a problem getting it's size to size the window accordingly. It works, but it's far from pretty. More details here: https://discourse.gnome.org/t/understanding-window-sizing-and-decorations-on-gtk4/7290 By moving to this idea we might be more compatible with other apps and do a better job on the implementation of window sizing. If you put a pure gtk window and a javafx window on Ubuntu 20.04 there are some differences (shadow size and titlebar size). Also, if we want to support wayland we will have to require a greater gtk3 version. Or just support it on Gtk4 where I would follow the HeaderBar (client-side decorations) idea. -- Thiago.
Why GTK4 glass backend will not (probably) be an #IFDEF
Gtk4 glass implementation will probably be a new glass implementation based on the current one because there are too many "breaking" changes. Changes are listed here: https://docs.gtk.org/gtk4/migrating-3to4.html Specially note: https://docs.gtk.org/gtk4/migrating-3to4.html#adapt-to-gtkwindow-api-changes (*) https://docs.gtk.org/gtk4/migrating-3to4.html#stop-using-gtk_widget_set_app_paintable (*) https://docs.gtk.org/gtk4/migrating-3to4.html#stop-using-grabs https://docs.gtk.org/gtk4/migrating-3to4.html#stop-using-non-rgba-visuals https://docs.gtk.org/gtk4/migrating-3to4.html#switch-to-the-new-drag-and-drop-api * Gdk Surface would be used instead of Gtk Window. Backend (Wayland/X11) specific functions will be needed: https://docs.gtk.org/gtk4/migrating-3to4.html#adapt-to-monitor-api-changes https://docs.gtk.org/gdk4/wayland.html Looking at the Gdk4 implementation, using libwayland* directly would be nice, but simply too hard. So we could use Gtk4 to support wayland and #ifdef GDK_WINDOWING_X11 / GDK_WINDOWING_WAYLAND where necessary. On another note, XTest equivalent (for Robot) is not available on generic wayland compositors. -- Thiago.
Re: apps compilation fails on ubuntu 20.04
I confirm that gradlew apps works using ant from snap package (1.10.11). Em qui., 12 de ago. de 2021 às 16:53, Kevin Rushforth < kevin.rushfo...@oracle.com> escreveu: > I still need to catch up on my email, since I still have the original > question in my queue. > > The answer to the original query is that there is a known bug with ant > 1.10.7 [1] that will cause this error. You can either use ant 1.10.5 > (which is the one we specify in build.properties) or use ant 1.10.8. > > As for the gradle sdk problem, I've not seen any problems relating to > using gradle 7.0.1. Is your repo up to date? Specifically, you need the > following commit: > > > https://github.com/openjdk/jfx/commit/111bac4180a646662a81223bdbb56880789d5a90 > > -- Kevin > > [1] https://bz.apache.org/bugzilla/show_bug.cgi?id=63874 > > > > On 8/12/2021 12:33 PM, Abhinay Agarwal wrote: > > I am on Ubuntu 20.04. Using ANT 1.10.8, "gradlew apps" works for me. > > > > However, "gradlew sdk" fails for me since we upgraded to Gradle 7.0.1. I > always switch back to Gradle 6.9 to build a local sdk. > > > > From: openjfx-dev on behalf of > Thiago Milczarek Sayão > > Sent: Friday, August 6, 2021 8:05 AM > > To: openjfx-dev@openjdk.java.net > > Subject: apps compilation fails on ubuntu 20.04 > > > > Hi > > > > Does anyone knows how to get *gradlew apps* working on ubuntu 20.04? > > > > I have: > > Apache Ant(TM) version 1.10.7 compiled on October 24 2019 > > openjdk version "16.0.1" 2021-04-20 > > > > I want to run the test apps. > > > > -do-compile: > > [javac] Compiling 143 source files to > > /home/tsayao/IdeaProjects/jfx/apps/samples/3DViewer/build/classes > > [javac] error: invalid flag: > > @/home/tsayao/IdeaProjects/jfx/build/compile.args > > [javac] Usage: javac > > [javac] use --help for a list of possible options > > > > Thanks. > >
Re: Enhancements for JavaFX 18
Hi, For the long term solution I would ditch Gtk and use libwayland directly. Inspiration can come from: https://gitlab.gnome.org/GNOME/gtk/-/blob/master/gdk/wayland/gdksurface-wayland.c For the short term solution, maybe remove the usage of X11 specific functions and replace for existing Gdk ones and let it handle. By letting gdk handle it it would be necessary to bump up the min required version, so maybe bundle it with javafx. The long term solution is interesting because: * We have the full power of anything supported on wayland; * Gtk is a full toolkit. - Cheers Em ter., 10 de ago. de 2021 às 12:45, Kevin Rushforth < kevin.rushfo...@oracle.com> escreveu: > Johan can comment on the details, but I think that is a matter of > investigation. > > As with the AWT work which is under discussion, there are two related, > but different deliverables that should be looked at: > > 1. Running the existing JavaFX GTK port on Wayland in X11 compatibility > mode > 2. A native JavaFX Wayland port > > For both of them, we need a solution to the same "robot" problems that > AWT and other libraries face (there is no standard way to control the > mouse or to read pixels from the screen). > > The fact that we already use GTK for most things should make #2 easier, > and it might be able to share a lot of the code, but it very likely will > need to be its ow backend, since it can't use X11. > > In thinking out loud, one thing to consider might be to have a single > glass GTK platform with different native libraries for Wayland and X11, > since we already have that support to handle gtk2 and gtk3. Maybe > something like: > > gtk2 (legacy and only for X11) > gtk3-x11 > gtk3-wayland > gtk4-x11 > gtk4-wayland > > Not sure whether that makes sense or not. > > I imagine that 1 should be feasible in the JavaFX 18 time frame. A > native Wayland port will be a lot of work, but since JavaFX already uses > GTK for most things, it should be significantly less work than AWT will be. > > -- Kevin > > > On 8/10/2021 8:24 AM, Thiago Milczarek Sayão wrote: > > Hi Johan, > > > > Would you prefer a pure Wayland backend or support it with gdk/GTK on top > > of the current glass backend? > > > > Cheers > > > > Em ter, 10 de ago de 2021 07:52, Johan Vos > escreveu: > > > >> I think we (everyone committing/reviewing in openjdk/jfx) did a great > job > >> with the 17-work: an impressive amount of old and annoying bugs are > fixed. > >> For 18 and beyond, I believe we have to keep working on those old > issues -- > >> at least if they are still relevant. > >> Also, I am 100% ok with the list of issues Kevin mentioned that need to > be > >> moved forward now. > >> > >> Apart from that, I want to have support for Metal and Wayland in JavaFX > 18. > >> > >> - Johan > >> > >> On Fri, Jul 30, 2021 at 2:58 PM Kevin Rushforth < > >> kevin.rushfo...@oracle.com> > >> wrote: > >> > >>> Now that JavaFX 17 is in RDP2, we can turn more attention to bug fixes > >>> and enhancement requests for JavaFX 18. It's the summer, so there may > be > >>> delays as some people are out at various times (including me), but I > >>> would like to get some of the outstanding enhancement requests moving > >>> over the next few weeks. > >>> > >>> Specifically, I'd like to see the following proceed: > >>> > >>> * Transparent backgrounds in WebView > >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8090547 > >>> PR: https://github.com/openjdk/jfx/pull/563 > >>> > >>> * Add DirectionalLight > >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8234921 > >>> PR: https://github.com/openjdk/jfx/pull/548 > >>> > >>> * CSS pseudoclasses :focus-visible and :focus-within > >>> https://bugs.openjdk.java.net/browse/JDK-8268225 > >>> PR: https://github.com/openjdk/jfx/pull/475 > >>> > >>> * Improve property system to facilitate correct usage (minus the binary > >>> incompatible API change) > >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8268642 > >>> PR: https://github.com/openjdk/jfx/pull/590 (Draft) > >>> > >>> And maybe the following: > >>> > >>> * Add CSS themes as a first-class concept (need a consensus on how to > >>> proceed) > >>> > >>> * Undecorated interactive stage style (still in early discussion, but > >>> the concept looks interesting and useful) > >>> > >>> There are probably others I'm forgetting. > >>> > >>> Each of the above should be discussed in their own thread on > openjfx-dev > >>> rather than a reply to this thread. > >>> > >>> -- Kevin > >>> > >>> > >>> > >
Re: Enhancements for JavaFX 18
Hi, One feature I will probably submit is touch events on Linux. Cheers. Em sex., 30 de jul. de 2021 às 09:59, Kevin Rushforth < kevin.rushfo...@oracle.com> escreveu: > Now that JavaFX 17 is in RDP2, we can turn more attention to bug fixes > and enhancement requests for JavaFX 18. It's the summer, so there may be > delays as some people are out at various times (including me), but I > would like to get some of the outstanding enhancement requests moving > over the next few weeks. > > Specifically, I'd like to see the following proceed: > > * Transparent backgrounds in WebView > JBS: https://bugs.openjdk.java.net/browse/JDK-8090547 > PR: https://github.com/openjdk/jfx/pull/563 > > * Add DirectionalLight > JBS: https://bugs.openjdk.java.net/browse/JDK-8234921 > PR: https://github.com/openjdk/jfx/pull/548 > > * CSS pseudoclasses :focus-visible and :focus-within > https://bugs.openjdk.java.net/browse/JDK-8268225 > PR: https://github.com/openjdk/jfx/pull/475 > > * Improve property system to facilitate correct usage (minus the binary > incompatible API change) > JBS: https://bugs.openjdk.java.net/browse/JDK-8268642 > PR: https://github.com/openjdk/jfx/pull/590 (Draft) > > And maybe the following: > > * Add CSS themes as a first-class concept (need a consensus on how to > proceed) > > * Undecorated interactive stage style (still in early discussion, but > the concept looks interesting and useful) > > There are probably others I'm forgetting. > > Each of the above should be discussed in their own thread on openjfx-dev > rather than a reply to this thread. > > -- Kevin > > >
Re: Enhancements for JavaFX 18
Hi Johan, Would you prefer a pure Wayland backend or support it with gdk/GTK on top of the current glass backend? Cheers Em ter, 10 de ago de 2021 07:52, Johan Vos escreveu: > I think we (everyone committing/reviewing in openjdk/jfx) did a great job > with the 17-work: an impressive amount of old and annoying bugs are fixed. > For 18 and beyond, I believe we have to keep working on those old issues -- > at least if they are still relevant. > Also, I am 100% ok with the list of issues Kevin mentioned that need to be > moved forward now. > > Apart from that, I want to have support for Metal and Wayland in JavaFX 18. > > - Johan > > On Fri, Jul 30, 2021 at 2:58 PM Kevin Rushforth < > kevin.rushfo...@oracle.com> > wrote: > > > Now that JavaFX 17 is in RDP2, we can turn more attention to bug fixes > > and enhancement requests for JavaFX 18. It's the summer, so there may be > > delays as some people are out at various times (including me), but I > > would like to get some of the outstanding enhancement requests moving > > over the next few weeks. > > > > Specifically, I'd like to see the following proceed: > > > > * Transparent backgrounds in WebView > > JBS: https://bugs.openjdk.java.net/browse/JDK-8090547 > > PR: https://github.com/openjdk/jfx/pull/563 > > > > * Add DirectionalLight > > JBS: https://bugs.openjdk.java.net/browse/JDK-8234921 > > PR: https://github.com/openjdk/jfx/pull/548 > > > > * CSS pseudoclasses :focus-visible and :focus-within > > https://bugs.openjdk.java.net/browse/JDK-8268225 > > PR: https://github.com/openjdk/jfx/pull/475 > > > > * Improve property system to facilitate correct usage (minus the binary > > incompatible API change) > > JBS: https://bugs.openjdk.java.net/browse/JDK-8268642 > > PR: https://github.com/openjdk/jfx/pull/590 (Draft) > > > > And maybe the following: > > > > * Add CSS themes as a first-class concept (need a consensus on how to > > proceed) > > > > * Undecorated interactive stage style (still in early discussion, but > > the concept looks interesting and useful) > > > > There are probably others I'm forgetting. > > > > Each of the above should be discussed in their own thread on openjfx-dev > > rather than a reply to this thread. > > > > -- Kevin > > > > > > >
apps compilation fails on ubuntu 20.04
Hi Does anyone knows how to get *gradlew apps* working on ubuntu 20.04? I have: Apache Ant(TM) version 1.10.7 compiled on October 24 2019 openjdk version "16.0.1" 2021-04-20 I want to run the test apps. -do-compile: [javac] Compiling 143 source files to /home/tsayao/IdeaProjects/jfx/apps/samples/3DViewer/build/classes [javac] error: invalid flag: @/home/tsayao/IdeaProjects/jfx/build/compile.args [javac] Usage: javac [javac] use --help for a list of possible options Thanks.
Wayland glass backend
I've been superficially looking into this (wayland). Seems like we could bind libwayland to java and build a managed backend from there. This would be so cool. Looks like here is an easy way to create bindings: https://github.com/wayland-project/wayland/blob/master/protocol/wayland.xml It's too much to tackle alone, but would dig in if anyone else is interested. Cheers
Re: Glass backends - xGravity and yGravity
Thanks for the reply.
It does not change the initial window position or the centerOnScreen()
positioning.
> * Gravity values specify how to correct window location if only its size
> * changes (for example when stage decorations are added). User initiated
> * resizing should be ignored and must not influence window location
through
> * this mechanism.
This says "when stage decorations are added". Are there any scenarios where
decorations are added after the window is shown? I think it's not possible,
except fullscreen/unfullscren (but it does not apply).
Decoration sizes are up to the window manager, so there is no way the "java
side" would know about them.
Cheers.
Em qua., 23 de dez. de 2020 às 20:41, Kevin Rushforth <
kevin.rushfo...@oracle.com> escreveu:
> I missed seeing this earlier. I can confirm that xGravity and yGravity
> are not used at all on Mac or Windows. I don't know why the Linux glass
> backend uses it, but it may have something to do with the asynchronous
> nature of X11. If you ignore it, does it change anything relating to the
> initial positioning? The only place I see x/yGravity set to a non-zero
> value is in the centerOnScreen method.
>
> -- Kevin
>
>
> On 12/14/2020 2:26 PM, Thiago Milczarek Sayão wrote:
> > Hi,
> >
> > Question: Are the xGravity and yGravity still in use?
> >
> > Windows glass backend seems to ignore it, and I can't think of any
> scenario
> > where this would be used on Linux glass backend.
> >
> > package com.sun.glass.ui;
> >
> >
> > public abstract class Window {
> > ..
> >
> > /**
> > * Sets the window bounds to the specified values.
> > *
> > * Gravity values specify how to correct window location if only its
> size
> > * changes (for example when stage decorations are added). User
> initiated
> > * resizing should be ignored and must not influence window location
> through
> > * this mechanism.
> > *
> > * The corresponding correction formulas are:
> > *
> > * {@code x -= xGravity * deltaW}
> > * {@code y -= yGravity * deltaH}
> > *
> > * @param x the new window horizontal position, ignored if xSet is set
> to
> > * false
> > * @param y the new window vertical position, ignored if ySet is set to
> > * false
> > * @param xSet indicates whether the x parameter is valid
> > * @param ySet indicates whether the y parameter is valid
> > * @param w the new window width, ignored if set to -1
> > * @param h the new window height, ignored if set to -1
> > * @param cw the new window content width, ignored if set to -1
> > * @param ch the new window content height, ignored if set to -1
> > * @param xGravity the xGravity coefficient
> > * @param yGravity the yGravity coefficient
> > */
> > public void setBounds(float x, float y, boolean xSet, boolean ySet,
> >float w, float h, float cw, float ch,
> >float xGravity, float yGravity)
>
>
Glass backends - xGravity and yGravity
Hi,
Question: Are the xGravity and yGravity still in use?
Windows glass backend seems to ignore it, and I can't think of any scenario
where this would be used on Linux glass backend.
package com.sun.glass.ui;
public abstract class Window {
..
/**
* Sets the window bounds to the specified values.
*
* Gravity values specify how to correct window location if only its size
* changes (for example when stage decorations are added). User initiated
* resizing should be ignored and must not influence window location through
* this mechanism.
*
* The corresponding correction formulas are:
*
* {@code x -= xGravity * deltaW}
* {@code y -= yGravity * deltaH}
*
* @param x the new window horizontal position, ignored if xSet is set to
* false
* @param y the new window vertical position, ignored if ySet is set to
* false
* @param xSet indicates whether the x parameter is valid
* @param ySet indicates whether the y parameter is valid
* @param w the new window width, ignored if set to -1
* @param h the new window height, ignored if set to -1
* @param cw the new window content width, ignored if set to -1
* @param ch the new window content height, ignored if set to -1
* @param xGravity the xGravity coefficient
* @param yGravity the yGravity coefficient
*/
public void setBounds(float x, float y, boolean xSet, boolean ySet,
float w, float h, float cw, float ch,
float xGravity, float yGravity)
Re: Linux basic application not displaying correctly
Hi Chad, I did not get the issue, please send the screenshots to my e-mail as they don't get through the list. One possibility: The Gtk glass backend tries to follow Windows (as in the operating system) sizes. On Windows, window sizes are the whole window, including decorations. On X (Linux) window decorations are a window manager job, so they don't count to the window size (more logical to me, as decorations can vary). Gtk backend tries to mimic that by getting decoration sizes. Your window manager seems to be not sending those. Cheers. Em dom., 13 de dez. de 2020 às 16:58, Chad Preisler escreveu: > Hello, > I'm running elementaryOS and when I use gtk3 the main window does not > display correctly. When using gtk2, the main window does display correctly. > > Here is the command line to run with gtk2. > > java -Djdk.gtk.version=2 > --module-path="/home/chad/javafx/jfx/build/sdk/lib" --add-modules > javafx.controls,javafx.fxml -jar target/javafxElementaryOS-1.0-SNAPSHOT.jar > > Here is the command line to run with gtk3. > > java -Djdk.gtk.version=2 > --module-path="/home/chad/javafx/jfx/build/sdk/lib" --add-modules > javafx.controls,javafx.fxml -jar target/javafxElementaryOS-1.0-SNAPSHOT.jar > > I've added two screenshots. Please notice in the gtk3 one that the mouse > cursor changes inside the window. I can actually change the window size > from that spot. > > I modified glass_window.cpp and added some cout statements to print > messages. The major difference I see in method > WindowContextTop::process_configure the frame width and height returned > from gdk_window_get_frame_extents are bigger in the gtk3 run. > > Here is my output from the gtk2 run: > > chad@chad-Inspiron-5565:~/NetBeansProjects/javafxElementaryOS$ java > -Djdk.gtk.version=2 --module-path="/home/chad/javafx/jfx/build/sdk/lib" > --add-modules javafx.controls,javafx.fxml -jar > target/javafxElementaryOS-1.0-SNAPSHOT.jar > Gtk-Message: 13:49:22.237: Failed to load module "canberra-gtk-module" > Creating main window! POPUP2 > WindowType is not TITLED > set_bounds > Frame extents: top 0 left 0 bottom 0 right 0 > geometry_get_window_width 640 > geometry_get_content_width 640 > geometry_get_window_height 513 > geometry_get_content_width 480 > window_configure > window_configure newWidth 640 newHeight 480 > geometry_get_window_width 640 > geometry_get_window_height 513 > set_bounds > geometry_get_window_width 640 > geometry_get_window_height 513 > window_configure > process_configure > Window is decorated > frame.width 640 frame.height 480 > Frame x 640 frame y 209 > Frame extents: top 0 left 0 bottom 0 right 0 > geometry_get_window_width 640 > geometry_get_window_height 513 > process_configure > Window is decorated > frame.width 640 frame.height 513 > Frame x 640 frame y 209 > Frame extents: top 33 left 0 bottom 0 right 0 > geometry_get_window_width 640 > geometry_get_window_height 513 > process_configure > Window is decorated > frame.width 640 frame.height 513 > Frame x 640 frame y 209 > Frame extents: top 33 left 0 bottom 0 right 0 > geometry_get_window_width 640 > geometry_get_window_height 513 > process_configure > Window is decorated > frame.width 640 frame.height 513 > Frame x 640 frame y 283 > Frame extents: top 33 left 0 bottom 0 right 0 > geometry_get_window_width 640 > geometry_get_window_height 513 > > Here is my output from the gtk3 run: > > chad@chad-Inspiron-5565:~/NetBeansProjects/javafxElementaryOS$ java > -Djdk.gtk.version=3 --module-path="/home/chad/javafx/jfx/build/sdk/lib" > --add-modules javafx.controls,javafx.fxml -jar > target/javafxElementaryOS-1.0-SNAPSHOT.jar > Creating main window! POPUP2 > WindowType is not TITLED > set_bounds > Frame extents: top 0 left 0 bottom 0 right 0 > geometry_get_window_width 640 > geometry_get_content_width 640 > geometry_get_window_height 513 > geometry_get_content_width 480 > window_configure > window_configure newWidth 640 newHeight 480 > geometry_get_window_width 640 > geometry_get_window_height 513 > set_bounds > geometry_get_window_width 640 > geometry_get_window_height 513 > window_configure > process_configure > Window is decorated > frame.width 798 frame.height 671 > Frame x 561 frame y 144 > Frame extents: top 0 left 0 bottom 0 right 0 > geometry_get_window_width 640 > geometry_get_window_height 513 > > I'm pretty sure this is some issue with the Window manager that > elemenatryOS uses. Problem is I'm not sure where to go from here. Has > anyone else experienced this? Any ideas on how to further debug this? > > Thanks, > Chad > [image: javafx_gtk2.png] > [image: javafx_gtk3.png] >
Using awt calls within OpenJfx context
With JavaFx that shipped with Oracle Java 10 I was able to do: Toolkit.getDefaultToolkit().getLockingKeyState(KeyEvent.VK_CAPS_LOCK) This is used to get if caps lock key is On. With OpenJfx 11 this call produces: java.awt.HeadlessException: null Is there a way to get the caps lock key state with openjfx?
Window opening glitch on ubuntu 18.04
I have migrated our development environment from java-10 javafx to java-11 and openjfx-11. One thing I have noticed is that windows opens on the top left corner of the screen and than moves to a center location. The weird thing is that we can see the window moving. It appears to be a glitch. This also happened on java-10 with the bundled javafx when setting it to use gtk-3 instead of gtk-2. So it appears to be a gtk-3 bug/glitch. We use x.org (not wayland).
How to use OpenJFX Early-Access Builds?
Hi, I am trying to use the openjfx early-access builds with openjdk as described in http://jdk.java.net/openjfx/ (the page says to give feedback here). openjdk version "10.0.1" 2018-04-17 OpenJDK Runtime Environment (build 10.0.1+10-Ubuntu-3ubuntu1) OpenJDK 64-Bit Server VM (build 10.0.1+10-Ubuntu-3ubuntu1, mixed mode) I have downloaded the openjfx file and unzipped it to: /home/tsayao/javafx-sdk-11 I am running my jfx application with: -Djava.library.path=/home/tsayao/javafx-sdk-11/lib -classpath /home/tsayao/javafx-sdk-11/lib But i get: Error: JavaFX runtime components are missing, and are required to run this application This is probably known, but I only found answers to old java 8 jfx. Help is appreciated.
