Hi David,
Please review this simple fix to the build logic for the openZip task.
https://bugs.openjdk.java.net/browse/JDK-8134725
http://cr.openjdk.java.net/~kcr/8134725/webrev.00/
-- Kevin
Hi Mark
All the best, Mark.
Keep your chin up.
On 2 September 2015 at 20:38, Mark Heckler wrote:
> All,
>
>
>
> It has been a pleasure and honor to have worked with you. I am among those
> whose positions were eliminated suddenly (today!), so I'll be exploring
> On Sep 2, 2015, at 9:05 AM, jo...@msli.com wrote:
>
> Please respond with only methods that do swing, awt, or eawt, as I have
> not seen this published anywhere.
Not easy to find doc these days. But fwiw…
http://www.docjar.org/docs/api/com/apple/eawt/Application.html
Michael Hall
Is there no javafx method to hook the Quit application menu item to call
my method? This is the really dangerous one.
Is there no javafx method to just hide the entire application menu on
OSX?
Some of com.apple.eawt (Apple Java Extentions Api) must have been
implemented in Javafx? No?
I
Let me comment on the examples you picked.
The 1st and 2nd rely on the default skin being used (they lookup a node
based on style class and then cast it to the expected type). This code
would not work with a custom skin.
The 3rd and 5th actually don't need skin implementations to be public,
Hi Jonathan,
regarding skins, while I don't see anything immediately wrong with the
published API, I have trouble seeing how making skin implementations public
is going to be useful. In particular, the JEP states that one of the
success metrics is
Projects that depend on JavaFX internal APIs, in
Tomas,
The webrev has a few examples of how skins being public will help. There
are many more of such cases when you take into account the large number
of projects I surveyed, but I just picked out the first few from this
webrev for Scene Builder. The short answer is: if skins aren't public,
I am trying to mentally digest the CSS API, but I am having trouble
answering the question of whether or not the following scenario is now
possible (using only public APIs). Imagine one wanted to create a new class
that was analogous to DeriveColorConverter.java, and that it worked "all
the way
This is not in the spec for this jep. It is additional API that we can discuss
and target for a release however. I highly recommend filling an issue in jbs
for this, if one doesn't anyway exist. Thanks!
-- Jonathan
Sent from a touch device. Please excuse my brevity.
On 4 September 2015
For what it's worth, I think enabling this is a really good idea. The starting
point is StyleConverter.java - it currently just hard codes all available
converters. Making that pluggable won't be too difficult. If you (or anyone
else) is interested in looking into this, we can discuss further.
Hi folks.
For those of you interested in JEP 253 we've got some light weekend
reading lined up for you. We are at a point where the JEP is basically
ready to merge back into a mainline (public) repo, and out of its
sandbox. Before we do that, we want any additional feedback from the
11 matches
Mail list logo