Hi, Morris.
Just curiously, does it mean that after the fix, there is no way to
maximize the window on two monitors in multi-monitors configuration?
Does this issue affects an applets? Seems that on Windows the clipping
on the screen bounds is a default native behavior.
27.03.15 22:39,
I think openjfx-dev@openjdk.java.net (cc) is correct place to ask this
question.
On 16.11.15 23:10, Ondřej Kvasnovský wrote:
Hi,
We are facing to an issue with latest Java updates when we try to
release apps into Apple app store. I have described the issue here, with
all my findings:
Note that in jdk9 the same data can be obtained via
GraphicsConfiguration.getDefaultTransform();
On 17.02.16 2:53, Jim Graham wrote:
I added a comment on the bug about BC, but it sounds like you already
considered it. I'm fine with this as is, but would push for moving to
JDK9 ASAP...
Hi Jim.
Do you plan to implement the new HiDPI API for the Robot class?
On 13.05.16 0:43, Jim Graham wrote:
bug: https://bugs.openjdk.java.net/browse/JDK-8137050
webrev: http://cr.openjdk.java.net/~flar/JDK-8137050/webrev-00/
The order of taking scaling parameters in order of higher to lower
Just FYI.
Sometimes the size is matter:
https://youtrack.jetbrains.com/issue/IDEA-74599
On 03.05.16 0:47, Kevin Rushforth wrote:
That sounds like a good idea. I like the idea of keeping the reduced
scope (private where possible) for clarity if there isn't a noticeable
performance penalty for
Probably the logging should be enabled only if we pass the upper case
"True" to "-Dsun.javafx.marlin=True". I do not know is it correct to
write to the system output unconditionally, can this affect application?
And instead of "sun." can we use something different like "jdk." I guess
the same
> There is no API for the "alwaysOnTop" AWT property for the print dialogs.
> I actually don't think it can be implemented for the windows native print
> controls.
> There is an internal way to make an AWT window owner for the Swing print
> dialog
> but nothing public and it doesn't help here
Hi, Phil.
I have only two questions:
- Does it mean that we do not support "ontop" property via public API in idk?
- Probably the name should contain «owner» instead of «parent»?, But since
this is not a public API I guess it is not an issue.
>
>
> This has an FX bug + webrev :
>
ed.singleThread"
On 9/13/17 03:11, Prasanta Sadhukhan wrote:
Hi Sergey,
I have modified the fix to not use SecondaryLoop and not to create one
thread per dispatch
http://cr.openjdk.java.net/~psadhukhan/8088132/webrev.03/
Regards
Prasanta
On 8/30/2017 11:41 AM, Sergey Bylokhov wrote:
H
s
Prasanta
On 9/13/17 03:11, Prasanta Sadhukhan wrote:
Hi Sergey,
I have modified the fix to not use SecondaryLoop and not to create
one thread per dispatch
http://cr.openjdk.java.net/~psadhukhan/8088132/webrev.03/
Regards
Prasanta
On 8/30/2017 11:41 AM, Sergey Bylokhov wrote:
Hi, Pras
Hi, Alexander.
How can we be sure that the parent frame will not be disposed while we
use a pointer?
long ownerWindowPtr = peer.getOverridenWindowHandle();
< Dispose the peer
if (ownerWindowPtr != 0) {
//Place window above JavaFX stage
CWrapper.NSWindow.addChildWindow(
dispatch look inefficient.
>
> Modified webrev
> http://cr.openjdk.java.net/~psadhukhan/fx/8088132/webrev.02/
>
> Regards
> Prasanta
> On 8/23/2017 9:31 PM, Sergey Bylokhov wrote:
> > Hi, Prasanta.
> >
> > On 16.08.2017 3:33, Prasanta Sadhukhan
From the AWT point of view the fix looks fine.
On 9/23/17 00:03, Prasanta Sadhukhan wrote:
Hi Sergey,
Please find modified webrev catering to DefaultKeyboardFocusManager also
http://cr.openjdk.java.net/~psadhukhan/8088132/webrev.05/
Regards
Prasanta
On 9/23/2017 7:52 AM, Sergey Bylokhov wrote
but dispatch() for each were called in other order then the
sequenced will not be preserved?
I have tested with couple of singleThread testcase without any issue.
Regards
Prasanta
On 8/14/2017 10:07 PM, Sergey Bylokhov wrote:
Hi, Prasanta, Kevin.
I have two notes.
- Does this option
://cr.openjdk.java.net/~azvegint/jdk/10/8185634/02/
Now we are postponing actual window closing, it happens only after we
ensure that native window pointer is valid on Swing side.
Thanks,
Alexander.
On 23/09/2017 08:01, Sergey Bylokhov wrote:
Hi, Alexander.
How can we be sure that the parent frame
et/browse/JDK-8088395>
Test added:
http://cr.openjdk.java.net/~azvegint/jdk/10/8185634/05/
Thanks,
Alexander.
On 13/10/2017 01:14, Sergey Bylokhov wrote:
Looks fine.
I am not sure but it looks like the fix has an assumption that the
CPlatformWindow.setVisible() code will be executed o
Just curious what attribute caused the first request to fail.
Is it related to kCGLPFAAccelerated or XXXSize?
87 kCGLPFAAccelerated,
88 kCGLPFAColorSize, 32,
89 kCGLPFAAlphaSize, 8,
90 kCGLPFADepthSize, depth,
91
On Tue, 29 Oct 2019 23:05:46 GMT, Kevin Rushforth wrote:
> On Tue, 29 Oct 2019 23:05:44 GMT, Kevin Rushforth wrote:
>
>> This PR updates the header files we use the build the OpenGL ES2 pipeline to
>> Mesa 19.2.1. See [this review
>>
On 4/22/20 6:39 am, Sebastian Stenzel wrote:
Judging from the comments in the aforementioned issues it doesn't seem like we
can expect anything to change on AWT side. This is why it has often been
requested to create an alternative using JavaFX. [2] That said, it has always
been postponed.
19 matches
Mail list logo
