Changeset: 964e022be8dc
Author:Martin Sladecek
Date: 2014-03-06 08:12 +0100
URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/964e022be8dc
RT-36100 [Layout] Ensemble8 ChoiceBox control starts out at smaller size
Reviewed by: dgrieve
!
modules/controls/src/main/java/com/sun/ja
1. It doesn't appear to be related with that issue but than again, it
might..
3. Thank you very much! I'll try out those settings to see how it looks.
I'm not very familinar with the internals of how windows renders fonts but
IMHO I would think that such poor results should be possible to avoid ev
Changeset: e605558a26a6
Author:leifs
Date: 2014-03-05 15:28 -0800
URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/e605558a26a6
RT-34099: ColorPicker needs localization support
!
modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ColorPalette.java
!
modules/con
The question the is why fairly all other toolkits use point in their APIs.
Some examples:
* Qt: http://qt-project.org/doc/qt-5/qfont.html#QFont-2
* Cocoa:
https://developer.apple.com/library/mac/documentation/Cocoa/Reference/ApplicationKit/Classes/NSFont_Class/Reference/Reference.html#//apple_ref/
Everyone should just accept that there is no such thing as a 'point' in
JavaFX. Work in pixels and you will achieve nirvana.
On 3/5/14, 5:49 PM, Pedro Duque Vieira wrote:
Here is the definition of point:
http://www.w3schools.com/cssref/css_units.asp
As Jeff is saying it should be 1/72 inch.
I
Here is the definition of point:
http://www.w3schools.com/cssref/css_units.asp
As Jeff is saying it should be 1/72 inch.
I think this should be the default. Isn't the introduction of modena
potentially going to break more apps than changing the definition of point?
Aren't breaking apps making use
Hi all,
To change the Java API now would break the universe. All you can do is
add new API. This can be in the form of new methods on Font, however
things like Font.getSize() must always return pixels. A new method can
be added getPoints() and new constructors that take points added, or
pe
To set the record straight, everything in JavaFX is pixels, including
Font size.
The W3C CSS spec (http://www.w3.org/TR/css3-values/#absolute-lengths)
defines 1px to be 1/96th of 1in and 1pt to be 1/72 of 1in. Therefore,
one px is 3/4ths of a pt (1px = 0.75pt) and this is the conversion
facto
Has anyone else noticed that Drag and Drop doesn't work with JFXPanel on MacOSX
(unless I'm doing something stupid)?
I filed a bug: https://javafx-jira.kenai.com/browse/RT-36127
There is a very simple test case in the comment.
jeff
jira: https://javafx-jira.kenai.com/browse/RT-35978
webrev: http://cr.openjdk.java.net/~ddhill/RT-35978
The change is for Embedded Arm font fallback, simplifying the determination of
where the jre/lib/fonts will be found.
I switched to using the java.home property as it provides the desir
I don't think we can do what you suggest about the warning, since there
are cases where CSS could be initialized prior to calling into the
application (e.g., the default preloader, deploy dialogs), but I think
it might make sense to add a property to control the scale. Can you file
a JIRA reque
From my tests the font size generated by CSS is what one gets with the same
point size and font using native apps and Qt - my complaint was the font size
when using the Java API.
Tom
Von meinem iPhone gesendet
> Am 05.03.2014 um 23:03 schrieb Felipe Heidrich :
>
>
> The problem is that point
The thing is, point size is a fixed size - 1pt==1/72 in, regardless of the DPI.
It is simply incorrect and confusing, arbitrarily deciding that a point is
1/96in.
How about implementing the fix based on a global static variable somewhere? And
perhaps printing a warning to the console when the f
The problem is that point size used by Node and point size used by CSS are not
the same.
One uses a 72 DPI and the other 96. Thus the final pixel sizes are different.
I don’t see how to change one or the other without breaking a ton of people.
Maybe adding a global font DPI so that Node can be
I’m not a CSS guy, but I never seen an alternative as you suggest.
I suppose there is recommend way to handle this problem.
Looking at modena.css it always uses “em” to define font size (instead of pt or
px).
Wouldn’t that work for you ?
Felipe
On Mar 5, 2014, at 9:51 AM, Jeff Martin wrote
Changeset: 143b27648d96
Author:hudson
Date: 2014-03-05 09:01 -0800
URL: http://hg.openjdk.java.net/openjfx/2u/dev/rt/rev/143b27648d96
Added tag 2.2.60-b09 for changeset 53d0f8119d8c
! .hgtags
Changeset: dc63b991dc39
Author:snorthov
Date: 2014-03-05 15:39 -0500
URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/dc63b991dc39
ECLIPSE ONLY: fix .classpath
! modules/media/.classpath
.. of course I mean the media component, not base. I just change the
template to say "your component" ...
Steve
On 2014-03-05 3:41 PM, Stephen F Northover wrote:
Hi Kirill,
Please review the lambdification of the base component. You are
welcome to apply the patch, but there are numerous ch
Hi Kirill,
Please review the lambdification of the base component. You are welcome
to apply the patch, but there are numerous changes and they are all
automatic. If you have outstanding changes, please commit them and I
will lambdify once more,
Jira: https://javafx-jira.kenai.com/browse/RT
Hi Tom, Jeff, Felipe...
Having bugs stay in to maintain backwards compatibility sounds very weird
to me IMHO.
If we go down that road aren't we creating a library that will some day
have too many glitches and as such less appeal to programmers looking for
UI libraries?
Thanks,
> Hi
> On Mar 4,
1.
Maybe https://javafx-jira.kenai.com/browse/RT-35402
2.
Sure. The above bug is in my TODO list as a matter of fact,
3. Things to try:
a) Text#setFontSmoothingType(LCD) ?
b) -Dprism.text=t2k (in the command line)
c) if the font size is bigger than 80 JavaFX renders text using paths, try
font
Changeset: cbb89489baea
Author:ddhill
Date: 2014-03-05 14:13 -0500
URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/cbb89489baea
[TOYS] HelloFonts, correcting table cell handling to get rid of bogus error msg
! apps/toys/Hello/src/main/java/hello/HelloFonts.java
Changeset: a080ea040a9c
Author:kcr
Date: 2014-03-05 10:36 -0800
URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/a080ea040a9c
[TEST-ONLY] change TestBase to initialize toolkit in @BeforeClass method
Summary: This change matches what we do elsewhere and avoids waiting in the
st
So what is the best approach to dealing with pt sizes in CSS? Do I multiply
every pt size by 3/4 in CSS? Will this always result in Node Fonts that are 4/3
times the specified CSS value?
I assume I can't just use px and expect Node Fonts to have the identical value,
only in points, regardless o
Hi Pedro,
Font rendering in FX8 is using the native rasterizer so the glyphs
should be identical to what the operating system is rendering. That
said, we may have a bug. Please enter a JIRA with sample code and a
screen shot of the bad rendering. That will give us something concrete
to work
Hi,
As evidenced by the screenshots in http://pixelduke.wordpress.com/ blog
posts about JMetro, javafx as noticeably poor font rendering visuals. The
most recent screenshots were taken on a windows 8.1 machine and the older
ones on windows 7, using Segoe UI (windows 7 & 8 system font).
1- As this
Hi
On Mar 4, 2014, at 4:42 PM, Jeff Martin wrote:
> Thanks Tom! I assume the thread was this one:
>
> Font.font() says it is point size but it looks like it are pixels
>
> http://mail.openjdk.java.net/pipermail/openjfx-dev/2014-January/012398.html
>
> I guess the final word is tha
Oops. I didn't read Lisa's and Rafi's follow-on messages about the bug
ID being wrong. Sorry about that.
-- Kevin
Kevin Rushforth wrote:
As a reminder (and not to pick on Rafi) this is the second time in as
many days that an 8-update review has been sent out for a bug that is
targeted for FX
As a reminder (and not to pick on Rafi) this is the second time in as
many days that an 8-update review has been sent out for a bug that is
targeted for FX 9. In order to help us better track which bugs are going
into which release, please set the release target as appropriate before
starting t
Right, it should be https://javafx-jira.kenai.com/browse/RT-35619
Thanks,
Rafi
From: Lisa Selle
Sent: Wednesday, March 05, 2014 5:23 PM
To: Rafi Tayar; Daniel Blaukopf
Cc: openjfx-dev@openjdk.java.net List
Subject: Re: [8u6] Review request : RT-35619 IMX6-SDP / Yocto hard float :
cra
Can you check the bug number? This doesn't look right...
I guess it should be https://javafx-jira.kenai.com/browse/RT-35619
On 3/5/2014 10:19 AM, Rafi Tayar wrote:
Hi Daniel, Lisa,
Please review the patch in the Jira :
https://javafx-jira.kenai.com/browse/RT-35616
Thanks,
Rafi
Hi Daniel, Lisa,
Please review the patch in the Jira :
https://javafx-jira.kenai.com/browse/RT-35616
Thanks,
Rafi
Hi,
JIRA: https://javafx-jira.kenai.com/browse/RT-36105
webrev: http://cr.openjdk.java.net/~msladecek/rt-36105/webrev.00/
there's a missing property for PieChart.Data.getNode().
Thanks,
-Martin
Changeset: b9b901417181
Author:Martin Sladecek
Date: 2014-03-05 10:04 +0100
URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/b9b901417181
RT-36088 [Popup] PopupWindow.show(Window): Wrong popup positioning on
subsequent calls
! modules/graphics/src/main/java/javafx/stage/Popu
Changeset: b6f62f8bd8e6
Author:vadim
Date: 2014-03-05 12:48 +0400
URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/b6f62f8bd8e6
RT-16923: Toolkit addListener methods should ignore null listeners
Reviewed-by: anthony, kcr, fheidric
! modules/graphics/src/main/java/com/sun/javaf
35 matches
Mail list logo
