On 9 December 2013 16:10, Scott Palmer swpal...@gmail.com wrote:
On Dec 8, 2013, at 9:18 PM, Felix Bembrick felix.bembr...@gmail.com
wrote:
snip
Firstly, it will *never* be possible to completely emulate the native
look
and feel.
Sure it is. Though it may never be practical, for
Spoiler: This is something I have become intensely passionate about so this
is likely to be a long post...
OK, so this (hijacked) thread started out as a discussion of options in
JavaFX for implementing Look and Feel. I think everyone agrees that even
with CSS and skins, JavaFX lacks the
Changeset: d0bca0f6ab5a
Author:Alexander Kouznetsov
Date: 2013-12-09 01:29 -0800
URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/d0bca0f6ab5a
Ensemble8: Fix for RT-34712 Ensemble8: Bouncing Balls View source link
doesn't work
!
BTW, I was wanting to refer to a comment on this topic made my Pedro DV on
Twitter today. Pedro has been doing stunningly good work on a Metro Look
and Feel for JavaFX and, when questioned by me, stated that while he may
attempt such a Look and Feel for Android, he wouldn't try to do one for iOS
Hi,
when talking about mobile LFs like iOS and Android a lot more stuff need to be
done. All the mobile UIs have different layout contains and a lot of default
animations. When creating a Look and Feel for mobile systems a set of additinal
panes / layout containers need to be created.
Hendrik
By the way, platform order of dialog buttons is implemented by the
ButtonBar control in ControlsFX. It is of course Java8 only but can
easily be brought back to FX2.
Werner
On 09.12.2013 10:45, Hendrik Ebbers wrote:
Next to the skinning of controls additional features are needed. One
example
All I know, as a 3rd party control developer, is that I want to be able to
setup the CSS of my controls in such a way that as much of a new skin is
automatically adopted; borders, colors, focus rendering, etc.
Tom
That's correct Hendrik and this only adds weight to my argument. Clearly
the mobile platforms (Android and especially iOS) are even harder-to-hit
targets than desktop platforms.
And if you are not able to develop a viable native Look and Feel for every
platform then the paradigm of deploying
On 9 Dec 2013, at 03:18, Felix Bembrick felix.bembr...@gmail.com wrote:
@Stephen, you are absolutely right about this. But such an approach (and
pretty much *any* approach) to emulated native look and feels is fraught
with difficulties and complexities.
Firstly, it will *never* be
Hello, OpenJFX.
Please review the fix for the issue:
https://javafx-jira.kenai.com/browse/RT-34770
The details are in the bug comments.
With best regards. Petr.
I agree that perfect sync with native look and feels is not what is required
and not worth the effort. I do think though that major concepts in the
platform's look and feel should (must!) be followed or the user experience is
ruined.
The example of the order of the ok and cancel buttons has
Here are my thoughts on the matter. Give people the choice of whether
to use native or non-native components. In some applications,
everything will be non-native. In others, only the main content area
will be non-native and the rest will be native. In some mobile
applications, perhaps the
Stephen, I thoroughly agree that JavaFX is by far the best choice for
non-native apps/widgets which is precisely my point. They are the kind of apps
perfect for using JavaFX.
But you refer to giving people the choice to go native where appropriate. How
can I exercise that choice? Where is the
Agreed that Quaqua did a great job and lets not lose sight of the fact that I
am totally praising the efforts of everyone who has worked in this frustrating
and tedious area of UI development/support. I just think the obvious talents of
those people could be utilised for a purpose less likely
There are a few critical elements that must conform to
platform-specific look and feel:
- app installer
- management of app icons
- system dialogs: file open, save and save, print
- os x system menu bar
Apart from these elements, native look and feel should be optional.
On Mon, Dec 9, 2013 at
I would go further by saying that those things you have mentioned should be
truly native, not just native look and feel. Consider the Swing file chooser
using Windows look and feel for example. That just never worked or looked right.
On 10 Dec 2013, at 4:47, Rick Walker
Today, you can only exercise the choice by writing native code and you
face heavyweight / lightweight issues depending on the platform and API.
Steve
On 2013-12-09 12:31 PM, Felix Bembrick wrote:
Stephen, I thoroughly agree that JavaFX is by far the best choice for
non-native apps/widgets
What can we expect from the JavaFX team in this regard in the future? I know we
have talked about mixing lightweight and heavyweight controls in the same
context but is it going to happen? Is this planned for JFX9 perhaps? Is it
*really* even feasible?
On 10 Dec 2013, at 4:55, Stephen F
Doesn’t this also imply that you are using AWT/Swing? JavaFX has no way to be
hosted in anything other than a JFXPanel or a JavaFX Stage. Only the JFXPanel
can be hosted in a windows that allows heavy weight (native) controls, or even
allows JNI code to get the window handle so you can
Just to take a completely different tack: I have a sneaking suspicion that the
whole approach to UI design is wrong. Aside from the platform abstraction
thing, I wonder whether we shouldn’t be approaching UIs from a design pattern
perspective. The application programmer is the wrong person to
Changeset: d337fbc19887
Author:Alexander Kouznetsov
Date: 2013-12-09 12:37 -0800
URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/d337fbc19887
Ensemble8: Fix for RT-34710 Ensemble8: Gesture Events sample name and
description is confusing
!
I see the point of he higher-level abstraction, but I think we need more
control over the user experience than that for most cases. If not simply for
aesthetics, there are times when I know I want a combobox vs. a spinner vs. a
list with a single selection model.
What we need are more of what
I am with you on the design pattern approach you refer to which is
basically a higher level of abstraction than say one which actually specifies
which widget types to use.
But who is this someone who loves the target platform and how and when do
they get to hook-in the actual widgets?
Changeset: 3bdcd01853bf
Author:Alexander Kouznetsov
Date: 2013-12-09 12:52 -0800
URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/3bdcd01853bf
Ensemble8: Fix for RT-34713 Ensemble8: TreeTableView sample is bad in editing:
edited values disappear
+
@Felix: Thank you for the kind words (although I don't consider myself a
rock star :-) ). As you mentioned I said I didn't want to make a iOS 7
native look and feel, I said it because I consider it broken as well as
many other influential designers do. Broken in the sense that it has
various wrong
Scott, I think the take-away here is that there simply aren't the features
out of the box in JavaFX/Java (even with CSS, skins, FXML) to implement
the best platform/UI abstraction and, given the various and vastly
differing opinions of how this layer should work or look, I doubt that any
official
Changeset: a5d957304de7
Author:Alexander Kouznetsov
Date: 2013-12-09 13:18 -0800
URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/a5d957304de7
Ensemble8: Fix for RT-34769 Ensemble8: TableCellFactoryApp sample needs cleanup
!
Changeset: 2883ec7be017
Author:Alexander Kouznetsov
Date: 2013-12-09 13:36 -0800
URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/2883ec7be017
Ensemble8: Fix for RT-34448 HTML Editor in Ensemble8 is not completely visible
!
Changeset: 53cb68c02d07
Author:John Yoon john.y...@oracle.com
Date: 2013-12-09 12:38 -0800
URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/53cb68c02d07
[Samples Only][RT-33754] Ensemble Icons
!
Changeset: bee5e52e68ae
Author:John Yoon john.y...@oracle.com
Date: 2013-12-09 14:28 -0800
URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/bee5e52e68ae
[Samples Only][RT-33754] Ensemble Icons
!
Changeset: 57153bcef81f
Author:kcr
Date: 2013-12-09 15:15 -0800
URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/57153bcef81f
RT-34389: [doc] cssref.html copyright is incorrect
Contributed-by: Tom Schindl
! apps/samples/Ensemble8/build.xml
!
Please review the following javadoc change (post-commit).
https://javafx-jira.kenai.com/browse/RT-19968
-- Kevin
This is my preferred approach. There is no need for the vast bulk of the
work to be initiated within OpenJFX, and a third party project for touch
/ mobile devices, much like there are for JavaFX on the desktop, is the
natural starting place to explore ideas.
If I had unlimited time and resources,
The comments around application runtime initialization seem like they belong
more properly in the application lifecycle javadoc for the Application class
rather than on the Platform.runLater method specifically, though I do see how
the runtime initialization cuts across multiple classes
(note that review comments should go into the JIRA)
Hi John,
You raise a good point about possibly moving the runtime initialization
section. Perhaps it's worth a follow-up JIRA for FX 8u20 or 9 to address
this. One possibility is to have most of the documentation in the
Application class,
Mong,
Please review the following (in the JIRA).
https://javafx-jira.kenai.com/browse/RT-32512
Thanks.
-- Kevin
Kevin,
Looks great. Approved.
Thanks,
Mong
On 12/9/2013 5:58 PM, Kevin Rushforth wrote:
Mong,
Please review the following (in the JIRA).
https://javafx-jira.kenai.com/browse/RT-32512
Thanks.
-- Kevin
Changeset: c818e4054cc7
Author:kcr
Date: 2013-12-09 18:29 -0800
URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/c818e4054cc7
RT-32512: Fix URL for JavaFX API docs license terms link
Reviewed-by: mtvo
! apps/samples/Ensemble8/build.xml
! build.properties
!
Please review the following:
https://javafx-jira.kenai.com/browse/RT-21569
-- Kevin
Changeset: a09aab639ad0
Author:kcr
Date: 2013-12-09 18:52 -0800
URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/a09aab639ad0
RT-34522: Update javafxpackager man pages for JDK/FX 8
Contributed-by: Nancy Hildebrandt
-
Changeset: 58f12825ecac
Author:John Yoon john.y...@oracle.com
Date: 2013-12-09 19:57 -0800
URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/58f12825ecac
[Samples Only][RT-33754] Ensemble Icons
!
Changeset: 8f0a6f77ec8f
Author:Alexander Kouznetsov
Date: 2013-12-09 20:19 -0800
URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/8f0a6f77ec8f
Ensemble8: Fix for RT-34006 Simplify Ensemble8 categories
!
Changeset: 0d24fac99293
Author:Alexander Kouznetsov
Date: 2013-12-09 20:36 -0800
URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/0d24fac99293
Ensemble8: Part #2 of fix for RT-34006 Simplify Ensemble8 categories
!
Changeset: 9bbe05e11f94
Author:Alexander Kouznetsov
Date: 2013-12-09 21:17 -0800
URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/9bbe05e11f94
Ensemble8: Fix for RT-33532 Ensemble8: alternative column and row fill visible
options doesn't work
!
Changeset: 5fc3e61b4f21
Author:Alexander Kouznetsov
Date: 2013-12-09 21:04 -0800
URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/5fc3e61b4f21
Ensemble8: Fix for RT-34714 Ensemble8: WebView sample limits its size
!
Changeset: 6dfa55f03e62
Author:Yves Joan yves.j...@oracle.com
Date: 2013-12-10 08:36 +0100
URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/6dfa55f03e62
Sync up SceneBuilder changes
+
46 matches
Mail list logo