Re: Look and feel mechanism?

2013-12-09 Thread Felix Bembrick
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 many of the reasons you
 have given.

  My reasoning is: why bother?

 Because it matters. As computer literate developers, we often don't
 realize what trips other people up.  I get so frustrated with apps these
 days because they have become hard to use simply because the developers
 tried to define their own look and feel.  For example, Chrome and
 Firefox... Or Microsoft Office...
 Where did the title bar go in chrome?
 Where have all the menus gone in Chrome, Firefox andOffice?  I can find
 them, but when I have to play tech support over the phone to my parents
 these changes are massive problems. I ask my dad to move he window by
 dragging the title bar (please don't ask why he doesn't know to do this
 himself after decades of computer use) and he says there is no title
 bar... I the remember that yes, chrome did that... They got rid of a
 standard concept in the OS' windowing system and screed the end users.

 These apps became harder to use because of this innovation in the UI.

 Contrast this with applications on OS X where getting the UI right has
 always been an important priority for developers.  Because adhering to the
 system look and feel has always been strongly encouraged the system is much
 easier to use.

  These days, many apps do not look 100% native and may have their own
  controls or look and feel in general.

 Yes, but to what end? They are now more difficult to use.

   Why not channel all that massive
  effort in constructing an emulated native look and feel into simply
 making
  JavaFX better overall?

 But I agree here.  The general look isn't the main issue.. E.g. little
 variations in color and minor tweaks to a few pixels here and there don't
 really matter.  What does matter is when you change the order of buttons,
 like Okay  Cancel which have standard places that are different between
 Mac and Windows, or you move the About menu item from the Application menu
 on an OS X app to the help menu! because that is where you find it on
 Windows.  Those things matter.


 Scott

 
  Felix
 
 
 
  On 9 December 2013 12:35, Pedro Duque Vieira 
 pedro.duquevie...@gmail.comwrote:
 
  Thanks!
 
  @Jasper: Yes, that's very interesting! Forgot that was possible to do in
  CSS.
 
 
  On Mon, Dec 9, 2013 at 12:15 AM, Stephen Winnall st...@winnall.ch
 wrote:
 
  It may be possible to change the LOOK with CSS, but not the FEEL, which
  is
  where Java apps have traditionally failed big time.
 
  Some things that I don’t think can be changed with CSS:
 
  1) texts
  2) order of buttons
  3) escape characters for shortcuts
  4) menus
  5) system-level stuff (double-clicking on files, dropping files on
  applications, …)
  6) filesystem conventions
  7) ...
 
  I think FXML can fix some of these, but not all. So it seems to me
 that a
  LaF in JFX will consist of at least:
 
 - one or more CSS files
 - one or more FXML files
 - some plumbing at the system level
 
  It would be nice to have a set of proper LaFs for each major platform
  with
  an appropriate common API.
 
  Steve
 
  On 9 Dec 2013, at 00:20, Jasper Potts jasper.po...@oracle.com
 wrote:
 
  You can set skin classes from CSS so should be able to do everything
  you
  could with Swing and more. With just a CSS file and skins as and when
  needed.
 
  Jasper
 
  On Dec 8, 2013, at 3:00 PM, Jonathan Giles 
 jonathan.gi...@oracle.com
 
  wrote:
 
  At present there are no plans to introduce any further API or
  functionality in this area, but if there is something you are wanting
  then you should file feature requests in Jira.
 
  -- Jonathan
 
  On 9/12/2013 11:54 a.m., Pedro Duque Vieira wrote:
  Hi,
 
  Is there any Look and Feel mechanism in place, like the one in
 Swing?
  That
  doesn't appear to exist..
 
  Are there any plans to add one? You can only do so much with CSS...
 
  Thanks in advance, best regards,
 
 
  --
  Pedro Duque Vieira
 



Re: Look and feel mechanism?

2013-12-09 Thread Werner Lehmann
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 that was already mentioned is the order of cancel and ok
buttons. Actually there is no support in JavaFX. If basic dialogs
would support this features a definition of the order etc. is needed.
This can be done by using a plugin for the LF API, too.


Re: Look and feel mechanism?

2013-12-09 Thread Tom Eugelink


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



Re: Look and feel mechanism?

2013-12-09 Thread Stephen Winnall
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 possible to completely emulate the native look 
 and feel.  And, even if the differences are subtle, there is the very real 
 risk that the end user will have a very uneasy feeling using such a look and 
 feel.  At times it will even seem like an imposter.

Agreed, though Quaqua did quite a good (and unobtrusive) job for the look on 
Swing on Mac OS X.

 Secondly, you will be forever playing catchup as each new major release (and 
 also even each minor update) changes one or more of the behaviours that you 
 have so carefully emulated.  The result is that for a while at least, your 
 emulated look and feel is an even more obvious imposter with an even more 
 uneasy experience for the user.

Indeed. I’m not really a fan of reimplementing something that’s already there 
anyway. It should be possible to use the native facilities via appropriate APIs.

 Thirdly, building such emulated look and feels is a *lot* of work (much more 
 than you would think).

Tell me about it :-) I spent a long time trying to create a Platform 
abstraction for Swing which would allow applications to be moved from platform 
to platform and adopt the native look and feel. The along came JavaFX. But we 
missed out on the chance of developing a platform abstraction there too.

 My reasoning is: why bother?  Why not build a JavaFX look and feel (akin to 
 something like Nimubs in Swing) that simply doesn't even try to look native?  
 Then you know for sure your app looks and behaves identically on all devices 
 and there is no hint of imposter-ness”.

The answer to this question is relatively simple: Metal. Metal, you will 
recall, was the one-size-fits-all look for Swing. And it was expletive 
deleted and was a major reason for the failure of Swing (and thus Java) on the 
desktop.

Ultimately, all cross-platform looks suffer from the same problem: they don’t 
look right on any platform and often terrible on others. And ignoring the feel 
of the target platform is the ultimate sin: users don’t understand what the app 
is doing or why but often cannot articulate their feelings because there’s no 
*observable* problem, only a “feelable one. And so another Java desktop app 
dies the death...

 These days, many apps do not look 100% native and may have their own controls 
 or look and feel in general.  Why not channel all that massive effort in 
 constructing an emulated native look and feel into simply making JavaFX 
 better overall?

Agreed. Let’s define a platform abstraction…

Steve

Re: Look and feel mechanism?

2013-12-09 Thread Felix Bembrick
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 to drive them crazy!

Yes, Metal was an unabridged disaster but did you ever see Substance? I thought 
that looked great on all platforms. And today there is also Cezanne which isn't 
too shabby.

What's really needed is, as you say, some kind of platform abstraction that 
handles all the OS specific details and then you code to use it. Ideally this 
abstraction would result in the use of actual native widgets but how you would 
apply all the features that come with Node to those widgets I have no idea...

 On 9 Dec 2013, at 22:49, Stephen Winnall st...@winnall.ch wrote:
 
 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 possible to completely emulate the native look 
 and feel.  And, even if the differences are subtle, there is the very real 
 risk that the end user will have a very uneasy feeling using such a look and 
 feel.  At times it will even seem like an imposter.
 
 Agreed, though Quaqua did quite a good (and unobtrusive) job for the look on 
 Swing on Mac OS X.
 
 Secondly, you will be forever playing catchup as each new major release (and 
 also even each minor update) changes one or more of the behaviours that you 
 have so carefully emulated.  The result is that for a while at least, your 
 emulated look and feel is an even more obvious imposter with an even more 
 uneasy experience for the user.
 
 Indeed. I’m not really a fan of reimplementing something that’s already there 
 anyway. It should be possible to use the native facilities via appropriate 
 APIs.
 
 Thirdly, building such emulated look and feels is a *lot* of work (much more 
 than you would think).
 
 Tell me about it :-) I spent a long time trying to create a Platform 
 abstraction for Swing which would allow applications to be moved from 
 platform to platform and adopt the native look and feel. The along came 
 JavaFX. But we missed out on the chance of developing a platform abstraction 
 there too.
 
 My reasoning is: why bother?  Why not build a JavaFX look and feel (akin 
 to something like Nimubs in Swing) that simply doesn't even try to look 
 native?  Then you know for sure your app looks and behaves identically on 
 all devices and there is no hint of imposter-ness”.
 
 The answer to this question is relatively simple: Metal. Metal, you will 
 recall, was the one-size-fits-all look for Swing. And it was expletive 
 deleted and was a major reason for the failure of Swing (and thus Java) on 
 the desktop.
 
 Ultimately, all cross-platform looks suffer from the same problem: they don’t 
 look right on any platform and often terrible on others. And ignoring the 
 feel of the target platform is the ultimate sin: users don’t understand what 
 the app is doing or why but often cannot articulate their feelings because 
 there’s no *observable* problem, only a “feelable one. And so another Java 
 desktop app dies the death...
 
 These days, many apps do not look 100% native and may have their own 
 controls or look and feel in general.  Why not channel all that massive 
 effort in constructing an emulated native look and feel into simply making 
 JavaFX better overall?
 
 Agreed. Let’s define a platform abstraction…
 
 Steve


Re: Look and feel mechanism?

2013-12-09 Thread Stephen Winnall
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 decide whether 
to implement a pop-up menu, a combobox or a selection list: all the programmer 
needs to specify is “get me one or more elements from this list”, and someone 
who loves the target platform (even Windows ;-) ) should instantiate the 
appropriate widget for that platform.

JavaFX gives us the capability to do this.

I think we tend to think of ourselves as clones of Leonardo da Vinci, capable 
of programming and design, when the truth is somewhat different, the more so 
when we’re implementing stuff for platforms we secretly despise… But now I’m 
ranting, sorry.

To get back to cross-platform looks. People are used to them because of WWW and 
browser interfaces. But the desktop has no competitive advantage over the 
browser idiom if it doesn’t do the user experience better. It’s a question of 
quality as opposed to 80:20 in my view. It’s look AND feel.

Steve

On 9 Dec 2013, at 18:42, Felix Bembrick felix.bembr...@gmail.com wrote:

 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 
 to drive them crazy!
 
 Yes, Metal was an unabridged disaster but did you ever see Substance? I 
 thought that looked great on all platforms. And today there is also Cezanne 
 which isn't too shabby.
 
 What's really needed is, as you say, some kind of platform abstraction that 
 handles all the OS specific details and then you code to use it. Ideally this 
 abstraction would result in the use of actual native widgets but how you 
 would apply all the features that come with Node to those widgets I have no 
 idea...
 
 On 9 Dec 2013, at 22:49, Stephen Winnall st...@winnall.ch wrote:
 
 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 possible to completely emulate the native look 
 and feel.  And, even if the differences are subtle, there is the very real 
 risk that the end user will have a very uneasy feeling using such a look 
 and feel.  At times it will even seem like an imposter.
 
 Agreed, though Quaqua did quite a good (and unobtrusive) job for the look on 
 Swing on Mac OS X.
 
 Secondly, you will be forever playing catchup as each new major release 
 (and also even each minor update) changes one or more of the behaviours 
 that you have so carefully emulated.  The result is that for a while at 
 least, your emulated look and feel is an even more obvious imposter with an 
 even more uneasy experience for the user.
 
 Indeed. I’m not really a fan of reimplementing something that’s already 
 there anyway. It should be possible to use the native facilities via 
 appropriate APIs.
 
 Thirdly, building such emulated look and feels is a *lot* of work (much 
 more than you would think).
 
 Tell me about it :-) I spent a long time trying to create a Platform 
 abstraction for Swing which would allow applications to be moved from 
 platform to platform and adopt the native look and feel. The along came 
 JavaFX. But we missed out on the chance of developing a platform abstraction 
 there too.
 
 My reasoning is: why bother?  Why not build a JavaFX look and feel (akin 
 to something like Nimubs in Swing) that simply doesn't even try to look 
 native?  Then you know for sure your app looks and behaves identically on 
 all devices and there is no hint of imposter-ness”.
 
 The answer to this question is relatively simple: Metal. Metal, you will 
 recall, was the one-size-fits-all look for Swing. And it was expletive 
 deleted and was a major reason for the failure of Swing (and thus Java) on 
 the desktop.
 
 Ultimately, all cross-platform looks suffer from the same problem: they 
 don’t look right on any platform and often terrible on others. And ignoring 
 the feel of the target platform is the ultimate sin: users don’t understand 
 what the app is doing or why but often cannot articulate their feelings 
 because there’s no *observable* problem, only a “feelable one. And so 
 another Java desktop app dies the death...
 
 These days, many apps do not look 100% native and may have their own 
 controls or look and feel in general.  Why not channel all that massive 
 effort in constructing an emulated native look and feel into simply making 
 JavaFX better overall?
 
 Agreed. Let’s define a platform abstraction…
 
 Steve



Re: Look and feel mechanism?

2013-12-09 Thread Scott Palmer
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 we already have with things like:

MenuBar.useSystemMenuBarProperty()

or in Swing, MouseEvent.isPopupTrigger()

Consider for example the standard shortcut for Undo.  CTRL-Z on Windows, 
Command-Z o Mac.  That’s easy, Mac uses Command where Windows uses CTRL.  But 
what about Redo?  CTRL-Y on Windows,  Command-Shift-Z on Mac.

Developers have to know these things and code for them explicitly.  Where is 
the abstraction in the Java APIs?

Scott


On Dec 9, 2013, at 3:03 PM, Felix Bembrick felix.bembr...@gmail.com wrote:

 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?
 
 While I agree JavaFX certainly has the ability to implement the high-level
 abstraction layer (as does pretty much any programming language, how
 (physically speaking) is someone going to link this with an actual
 selection of widgets on each OS?  Isn't *that* the whole problem here?
 
 Felix
 
 
 
 On 10 December 2013 06:50, Stephen Winnall st...@winnall.ch wrote:
 
 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 decide whether to implement a pop-up menu, a combobox or a selection
 list: all the programmer needs to specify is “get me one or more elements
 from this list”, and someone who loves the target platform (even Windows
 ;-) ) should instantiate the appropriate widget for that platform.
 
 JavaFX gives us the capability to do this.
 
 I think we tend to think of ourselves as clones of Leonardo da Vinci,
 capable of programming and design, when the truth is somewhat different,
 the more so when we’re implementing stuff for platforms we secretly
 despise… But now I’m ranting, sorry.
 
 To get back to cross-platform looks. People are used to them because of
 WWW and browser interfaces. But the desktop has no competitive advantage
 over the browser idiom if it doesn’t do the user experience better. It’s a
 question of quality as opposed to 80:20 in my view. It’s look AND feel.
 
 Steve
 
 On 9 Dec 2013, at 18:42, Felix Bembrick felix.bembr...@gmail.com wrote:
 
 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
 to drive them crazy!
 
 Yes, Metal was an unabridged disaster but did you ever see Substance? I
 thought that looked great on all platforms. And today there is also Cezanne
 which isn't too shabby.
 
 What's really needed is, as you say, some kind of platform abstraction
 that handles all the OS specific details and then you code to use it.
 Ideally this abstraction would result in the use of actual native widgets
 but how you would apply all the features that come with Node to those
 widgets I have no idea...
 
 On 9 Dec 2013, at 22:49, Stephen Winnall st...@winnall.ch wrote:
 
 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 possible to completely emulate the native look
 and feel.  And, even if the differences are subtle, there is the very real
 risk that the end user will have a very uneasy feeling using such a look
 and feel.  At times it will even seem like an imposter.
 
 
 Agreed, though Quaqua did quite a good (and unobtrusive) job for the look
 on Swing on Mac OS X.
 
 Secondly, you will be forever playing catchup as each new major release
 (and also even each minor update) changes one or more of the behaviours
 that you have so carefully emulated.  The result is that for a while at
 least, your emulated look and feel is an even more obvious imposter with an
 even more uneasy experience for the user.
 
 
 Indeed. I’m not really a fan of reimplementing something that’s already
 there anyway. It should be possible to use the native facilities via
 appropriate APIs.
 
 Thirdly, building such emulated look and feels is a *lot* of work (much
 more than you would think).
 
 
 Tell me about it :-) I spent a long time trying to create a Platform
 abstraction for 

Re: Look and feel mechanism?

2013-12-09 Thread Stephen Winnall
 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?
 
 While I agree JavaFX certainly has the ability to implement the high-level 
 abstraction layer (as does pretty much any programming language, how 
 (physically speaking) is someone going to link this with an actual selection 
 of widgets on each OS?  Isn't *that* the whole problem here?

That’s JavaFX, CSS and FXML, with the native platform shining though thanks to 
the platform API.

Steve

Re: Look and feel mechanism?

2013-12-09 Thread Pedro Duque Vieira
@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 design decisions.

As for the discussion of native look and feels, I think a cross platform
look and feel that goes for the least common denominator and doesn't
violate any of the platforms look and feel guidelines is the best way to go.
As was already said having a native look and feel for each platform is a
ton of work, even if the framework does provide one (as Felix said, most
often is not even 80% identical) you still have to adapt the application
for each platform if you go this way. The real problem is the feel part,
each platform has a different standard set of controls, consider for
example windows 8 which for desktop app almost always substitutes menus for
a ribbon. If you go this way you better, as was already said, go with the
platforms set of tools to create apps, instead of using java/javafx.
Modena is an excellent cross platform look and feel that looks great,
something we never had in swing, at least not out of the box in the
framework. And I think this is the best way to go.
As for mobile, I think the same should be done: create a cross platform
look and feel. When developers choose java for this it often is because
they lake the necessary resources to build a native app for each system. A
good cross platform look and feel will speed up development and time of
delivery. I don't think you have to go native to have a great designed app,
there are various examples on mobile of great apps that don't use the
standard looking platform controls. There are even apps that go as far as
use almost only gestures with almost no controls.
  Checkout Clear, a critically acclaimed app for its design, that almost
doesn't use controls: http://realmacsoftware.com/clear/ or Paper also an
app that is recognized by many as having an excellent design that also
doesn't use standard native controls: http://www.fiftythree.com/




On Mon, Dec 9, 2013 at 8:03 PM, Felix Bembrick felix.bembr...@gmail.comwrote:

 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?

 While I agree JavaFX certainly has the ability to implement the high-level
 abstraction layer (as does pretty much any programming language, how
 (physically speaking) is someone going to link this with an actual
 selection of widgets on each OS?  Isn't *that* the whole problem here?

 Felix



 On 10 December 2013 06:50, Stephen Winnall st...@winnall.ch wrote:

 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 decide whether to implement a pop-up menu, a combobox or a selection
 list: all the programmer needs to specify is “get me one or more elements
 from this list”, and someone who loves the target platform (even Windows
 ;-) ) should instantiate the appropriate widget for that platform.

 JavaFX gives us the capability to do this.

 I think we tend to think of ourselves as clones of Leonardo da Vinci,
 capable of programming and design, when the truth is somewhat different,
 the more so when we’re implementing stuff for platforms we secretly
 despise… But now I’m ranting, sorry.

 To get back to cross-platform looks. People are used to them because of
 WWW and browser interfaces. But the desktop has no competitive advantage
 over the browser idiom if it doesn’t do the user experience better. It’s a
 question of quality as opposed to 80:20 in my view. It’s look AND feel.

 Steve

 On 9 Dec 2013, at 18:42, Felix Bembrick felix.bembr...@gmail.com wrote:

 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
 to drive them crazy!

 Yes, Metal was an unabridged disaster but did you ever see Substance? I
 thought that looked great on all platforms. And today there is also Cezanne
 which isn't too shabby.

 What's really needed is, as you say, some kind of platform abstraction
 that handles all the OS specific details and then you code to use it.
 Ideally this abstraction would result in the use of actual native widgets
 but how you would apply all the features that come with Node to those
 widgets I have no idea...

 On 9 Dec 2013, at 22:49, 

Re: Look and feel mechanism?

2013-12-09 Thread Felix Bembrick
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 solution will ever be provided by Oracle.

I guess that we all need to do what works for ourselves in this area which
is admittedly unfortunate and undesirable...


On 10 December 2013 07:49, Scott Palmer swpal...@gmail.com wrote:

 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 we already have with things like:

 MenuBar.useSystemMenuBarProperty()

 or in Swing, MouseEvent.isPopupTrigger()

 Consider for example the standard shortcut for Undo.  CTRL-Z on Windows,
 Command-Z o Mac.  That’s easy, Mac uses Command where Windows uses CTRL.
  But what about Redo?  CTRL-Y on Windows,  Command-Shift-Z on Mac.

 Developers have to know these things and code for them explicitly.  Where
 is the abstraction in the Java APIs?

 Scott


 On Dec 9, 2013, at 3:03 PM, Felix Bembrick felix.bembr...@gmail.com
 wrote:

  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?
 
  While I agree JavaFX certainly has the ability to implement the
 high-level
  abstraction layer (as does pretty much any programming language, how
  (physically speaking) is someone going to link this with an actual
  selection of widgets on each OS?  Isn't *that* the whole problem here?
 
  Felix
 
 
 
  On 10 December 2013 06:50, Stephen Winnall st...@winnall.ch wrote:
 
  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 decide whether to implement a pop-up menu, a combobox or a selection
  list: all the programmer needs to specify is “get me one or more
 elements
  from this list”, and someone who loves the target platform (even Windows
  ;-) ) should instantiate the appropriate widget for that platform.
 
  JavaFX gives us the capability to do this.
 
  I think we tend to think of ourselves as clones of Leonardo da Vinci,
  capable of programming and design, when the truth is somewhat different,
  the more so when we’re implementing stuff for platforms we secretly
  despise… But now I’m ranting, sorry.
 
  To get back to cross-platform looks. People are used to them because of
  WWW and browser interfaces. But the desktop has no competitive advantage
  over the browser idiom if it doesn’t do the user experience better.
 It’s a
  question of quality as opposed to 80:20 in my view. It’s look AND feel.
 
  Steve
 
  On 9 Dec 2013, at 18:42, Felix Bembrick felix.bembr...@gmail.com
 wrote:
 
  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
  to drive them crazy!
 
  Yes, Metal was an unabridged disaster but did you ever see Substance? I
  thought that looked great on all platforms. And today there is also
 Cezanne
  which isn't too shabby.
 
  What's really needed is, as you say, some kind of platform abstraction
  that handles all the OS specific details and then you code to use it.
  Ideally this abstraction would result in the use of actual native
 widgets
  but how you would apply all the features that come with Node to those
  widgets I have no idea...
 
  On 9 Dec 2013, at 22:49, Stephen Winnall st...@winnall.ch wrote:
 
  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 possible to completely emulate the native
 look
  and feel.  And, even if the differences are subtle, there is the very
 real
  risk that the end user will have a very uneasy feeling using such a look
  and feel.  At times it will even seem like an imposter.
 
 
  Agreed, though Quaqua did quite a good (and unobtrusive) job for the
 look
  on Swing on Mac OS X.
 
  Secondly, you will be forever playing catchup as each new major release
  (and also even 

Re: Look and feel mechanism?

2013-12-09 Thread Scott Palmer
Well there is the option of doing some sort of application support library
in an external project first. Much like the ControlsFX stuff.

If it works out, some aspects can be pulled into the JavaFX runtime at a
later date.

Scott
On Dec 9, 2013 4:14 PM, Felix Bembrick felix.bembr...@gmail.com wrote:

 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 solution will ever be provided by Oracle.

 I guess that we all need to do what works for ourselves in this area which
 is admittedly unfortunate and undesirable...


 On 10 December 2013 07:49, Scott Palmer swpal...@gmail.com wrote:

 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 we already have with things like:

 MenuBar.useSystemMenuBarProperty()

 or in Swing, MouseEvent.isPopupTrigger()

 Consider for example the standard shortcut for Undo.  CTRL-Z on Windows,
 Command-Z o Mac.  That’s easy, Mac uses Command where Windows uses CTRL.
  But what about Redo?  CTRL-Y on Windows,  Command-Shift-Z on Mac.

 Developers have to know these things and code for them explicitly.  Where
 is the abstraction in the Java APIs?

 Scott


 On Dec 9, 2013, at 3:03 PM, Felix Bembrick felix.bembr...@gmail.com
 wrote:

  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?
 
  While I agree JavaFX certainly has the ability to implement the
 high-level
  abstraction layer (as does pretty much any programming language, how
  (physically speaking) is someone going to link this with an actual
  selection of widgets on each OS?  Isn't *that* the whole problem here?
 
  Felix
 
 
 
  On 10 December 2013 06:50, Stephen Winnall st...@winnall.ch wrote:
 
  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 decide whether to implement a pop-up menu, a combobox or a selection
  list: all the programmer needs to specify is “get me one or more
 elements
  from this list”, and someone who loves the target platform (even
 Windows
  ;-) ) should instantiate the appropriate widget for that platform.
 
  JavaFX gives us the capability to do this.
 
  I think we tend to think of ourselves as clones of Leonardo da Vinci,
  capable of programming and design, when the truth is somewhat
 different,
  the more so when we’re implementing stuff for platforms we secretly
  despise… But now I’m ranting, sorry.
 
  To get back to cross-platform looks. People are used to them because of
  WWW and browser interfaces. But the desktop has no competitive
 advantage
  over the browser idiom if it doesn’t do the user experience better.
 It’s a
  question of quality as opposed to 80:20 in my view. It’s look AND feel.
 
  Steve
 
  On 9 Dec 2013, at 18:42, Felix Bembrick felix.bembr...@gmail.com
 wrote:
 
  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
  to drive them crazy!
 
  Yes, Metal was an unabridged disaster but did you ever see Substance? I
  thought that looked great on all platforms. And today there is also
 Cezanne
  which isn't too shabby.
 
  What's really needed is, as you say, some kind of platform abstraction
  that handles all the OS specific details and then you code to use it.
  Ideally this abstraction would result in the use of actual native
 widgets
  but how you would apply all the features that come with Node to those
  widgets I have no idea...
 
  On 9 Dec 2013, at 22:49, Stephen Winnall st...@winnall.ch wrote:
 
  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 possible to completely emulate the native
 look
  and feel.  And, even if the differences are subtle, there is the very
 real
  risk that the 

Re: Look and feel mechanism?

2013-12-09 Thread Felix Bembrick
Yes, I think that's the best approach.  I am working on some aspects of
this internally and hopefully next year I can contribute some parts of that
:-)

Felix



On 10 December 2013 10:49, Scott Palmer swpal...@gmail.com wrote:

 Well there is the option of doing some sort of application support library
 in an external project first. Much like the ControlsFX stuff.

 If it works out, some aspects can be pulled into the JavaFX runtime at a
 later date.

 Scott
 On Dec 9, 2013 4:14 PM, Felix Bembrick felix.bembr...@gmail.com wrote:

 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 solution will ever be provided by Oracle.

 I guess that we all need to do what works for ourselves in this area
 which is admittedly unfortunate and undesirable...


 On 10 December 2013 07:49, Scott Palmer swpal...@gmail.com wrote:

 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 we already have with things like:

 MenuBar.useSystemMenuBarProperty()

 or in Swing, MouseEvent.isPopupTrigger()

 Consider for example the standard shortcut for Undo.  CTRL-Z on Windows,
 Command-Z o Mac.  That’s easy, Mac uses Command where Windows uses CTRL.
  But what about Redo?  CTRL-Y on Windows,  Command-Shift-Z on Mac.

 Developers have to know these things and code for them explicitly.
  Where is the abstraction in the Java APIs?

 Scott


 On Dec 9, 2013, at 3:03 PM, Felix Bembrick felix.bembr...@gmail.com
 wrote:

  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?
 
  While I agree JavaFX certainly has the ability to implement the
 high-level
  abstraction layer (as does pretty much any programming language, how
  (physically speaking) is someone going to link this with an actual
  selection of widgets on each OS?  Isn't *that* the whole problem here?
 
  Felix
 
 
 
  On 10 December 2013 06:50, Stephen Winnall st...@winnall.ch wrote:
 
  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 decide whether to implement a pop-up menu, a combobox or a
 selection
  list: all the programmer needs to specify is “get me one or more
 elements
  from this list”, and someone who loves the target platform (even
 Windows
  ;-) ) should instantiate the appropriate widget for that platform.
 
  JavaFX gives us the capability to do this.
 
  I think we tend to think of ourselves as clones of Leonardo da Vinci,
  capable of programming and design, when the truth is somewhat
 different,
  the more so when we’re implementing stuff for platforms we secretly
  despise… But now I’m ranting, sorry.
 
  To get back to cross-platform looks. People are used to them because
 of
  WWW and browser interfaces. But the desktop has no competitive
 advantage
  over the browser idiom if it doesn’t do the user experience better.
 It’s a
  question of quality as opposed to 80:20 in my view. It’s look AND
 feel.
 
  Steve
 
  On 9 Dec 2013, at 18:42, Felix Bembrick felix.bembr...@gmail.com
 wrote:
 
  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
  to drive them crazy!
 
  Yes, Metal was an unabridged disaster but did you ever see Substance?
 I
  thought that looked great on all platforms. And today there is also
 Cezanne
  which isn't too shabby.
 
  What's really needed is, as you say, some kind of platform abstraction
  that handles all the OS specific details and then you code to use it.
  Ideally this abstraction would result in the use of actual native
 widgets
  but how you would apply all the features that come with Node to those
  widgets I have no idea...
 
  On 9 Dec 2013, at 22:49, Stephen Winnall st...@winnall.ch wrote:
 
  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 

Re: Look and feel mechanism?

2013-12-09 Thread Jonathan Giles
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, I would start up a ControlsFX
project for Android / iOS, but I just don't think I have the bandwidth
to do that along with everything else. Maybe that might change in the
future, but I encourage those with more time to consider a project (or
projects) of this nature.

-- Jonathan

On 10/12/2013 12:49 p.m., Scott Palmer wrote:
 Well there is the option of doing some sort of application support library
 in an external project first. Much like the ControlsFX stuff.

 If it works out, some aspects can be pulled into the JavaFX runtime at a
 later date.

 Scott




Re: Look and feel mechanism?

2013-12-08 Thread Jonathan Giles
At present there are no plans to introduce any further API or
functionality in this area, but if there is something you are wanting
then you should file feature requests in Jira.

-- Jonathan

On 9/12/2013 11:54 a.m., Pedro Duque Vieira wrote:
 Hi,

 Is there any Look and Feel mechanism in place, like the one in Swing? That
 doesn't appear to exist..

 Are there any plans to add one? You can only do so much with CSS...

 Thanks in advance, best regards,




Re: Look and feel mechanism?

2013-12-08 Thread Jasper Potts
You can set skin classes from CSS so should be able to do everything you could 
with Swing and more. With just a CSS file and skins as and when needed. 

Jasper

 On Dec 8, 2013, at 3:00 PM, Jonathan Giles jonathan.gi...@oracle.com wrote:
 
 At present there are no plans to introduce any further API or
 functionality in this area, but if there is something you are wanting
 then you should file feature requests in Jira.
 
 -- Jonathan
 
 On 9/12/2013 11:54 a.m., Pedro Duque Vieira wrote:
 Hi,
 
 Is there any Look and Feel mechanism in place, like the one in Swing? That
 doesn't appear to exist..
 
 Are there any plans to add one? You can only do so much with CSS...
 
 Thanks in advance, best regards,
 


Re: Look and feel mechanism?

2013-12-08 Thread Stephen Winnall
It may be possible to change the LOOK with CSS, but not the FEEL, which is 
where Java apps have traditionally failed big time.

Some things that I don’t think can be changed with CSS:

1) texts
2) order of buttons
3) escape characters for shortcuts
4) menus
5) system-level stuff (double-clicking on files, dropping files on 
applications, …)
6) filesystem conventions
7) ...

I think FXML can fix some of these, but not all. So it seems to me that a LaF 
in JFX will consist of at least:

- one or more CSS files
- one or more FXML files
- some plumbing at the system level

It would be nice to have a set of proper LaFs for each major platform with an 
appropriate common API.

Steve

On 9 Dec 2013, at 00:20, Jasper Potts jasper.po...@oracle.com wrote:

 You can set skin classes from CSS so should be able to do everything you 
 could with Swing and more. With just a CSS file and skins as and when needed. 
 
 Jasper
 
 On Dec 8, 2013, at 3:00 PM, Jonathan Giles jonathan.gi...@oracle.com wrote:
 
 At present there are no plans to introduce any further API or
 functionality in this area, but if there is something you are wanting
 then you should file feature requests in Jira.
 
 -- Jonathan
 
 On 9/12/2013 11:54 a.m., Pedro Duque Vieira wrote:
 Hi,
 
 Is there any Look and Feel mechanism in place, like the one in Swing? That
 doesn't appear to exist..
 
 Are there any plans to add one? You can only do so much with CSS...
 
 Thanks in advance, best regards,
 



Re: Look and feel mechanism?

2013-12-08 Thread Pedro Duque Vieira
Thanks!

@Jasper: Yes, that's very interesting! Forgot that was possible to do in
CSS.


On Mon, Dec 9, 2013 at 12:15 AM, Stephen Winnall st...@winnall.ch wrote:

 It may be possible to change the LOOK with CSS, but not the FEEL, which is
 where Java apps have traditionally failed big time.

 Some things that I don’t think can be changed with CSS:

 1) texts
 2) order of buttons
 3) escape characters for shortcuts
 4) menus
 5) system-level stuff (double-clicking on files, dropping files on
 applications, …)
 6) filesystem conventions
 7) ...

 I think FXML can fix some of these, but not all. So it seems to me that a
 LaF in JFX will consist of at least:

 - one or more CSS files
 - one or more FXML files
 - some plumbing at the system level

 It would be nice to have a set of proper LaFs for each major platform with
 an appropriate common API.

 Steve

 On 9 Dec 2013, at 00:20, Jasper Potts jasper.po...@oracle.com wrote:

  You can set skin classes from CSS so should be able to do everything you
 could with Swing and more. With just a CSS file and skins as and when
 needed.
 
  Jasper
 
  On Dec 8, 2013, at 3:00 PM, Jonathan Giles jonathan.gi...@oracle.com
 wrote:
 
  At present there are no plans to introduce any further API or
  functionality in this area, but if there is something you are wanting
  then you should file feature requests in Jira.
 
  -- Jonathan
 
  On 9/12/2013 11:54 a.m., Pedro Duque Vieira wrote:
  Hi,
 
  Is there any Look and Feel mechanism in place, like the one in Swing?
 That
  doesn't appear to exist..
 
  Are there any plans to add one? You can only do so much with CSS...
 
  Thanks in advance, best regards,
 




-- 
Pedro Duque Vieira


Re: Look and feel mechanism?

2013-12-08 Thread Felix Bembrick
@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 possible to completely emulate the native look
and feel.  And, even if the differences are subtle, there is the very real
risk that the end user will have a very uneasy feeling using such a look
and feel.  At times it will even seem like an imposter.

Secondly, you will be forever playing catchup as each new major release
(and also even each minor update) changes one or more of the behaviours
that you have so carefully emulated.  The result is that for a while at
least, your emulated look and feel is an even more obvious imposter with an
even more uneasy experience for the user.

Thirdly, building such emulated look and feels is a *lot* of work (much
more than you would think).

My reasoning is: why bother?  Why not build a JavaFX look and feel (akin
to something like Nimubs in Swing) that simply doesn't even try to look
native?  Then you know for sure your app looks and behaves identically on
all devices and there is no hint of imposter-ness.

These days, many apps do not look 100% native and may have their own
controls or look and feel in general.  Why not channel all that massive
effort in constructing an emulated native look and feel into simply making
JavaFX better overall?

Felix



On 9 December 2013 12:35, Pedro Duque Vieira pedro.duquevie...@gmail.comwrote:

 Thanks!

 @Jasper: Yes, that's very interesting! Forgot that was possible to do in
 CSS.


 On Mon, Dec 9, 2013 at 12:15 AM, Stephen Winnall st...@winnall.ch wrote:

  It may be possible to change the LOOK with CSS, but not the FEEL, which
 is
  where Java apps have traditionally failed big time.
 
  Some things that I don’t think can be changed with CSS:
 
  1) texts
  2) order of buttons
  3) escape characters for shortcuts
  4) menus
  5) system-level stuff (double-clicking on files, dropping files on
  applications, …)
  6) filesystem conventions
  7) ...
 
  I think FXML can fix some of these, but not all. So it seems to me that a
  LaF in JFX will consist of at least:
 
  - one or more CSS files
  - one or more FXML files
  - some plumbing at the system level
 
  It would be nice to have a set of proper LaFs for each major platform
 with
  an appropriate common API.
 
  Steve
 
  On 9 Dec 2013, at 00:20, Jasper Potts jasper.po...@oracle.com wrote:
 
   You can set skin classes from CSS so should be able to do everything
 you
  could with Swing and more. With just a CSS file and skins as and when
  needed.
  
   Jasper
  
   On Dec 8, 2013, at 3:00 PM, Jonathan Giles jonathan.gi...@oracle.com
 
  wrote:
  
   At present there are no plans to introduce any further API or
   functionality in this area, but if there is something you are wanting
   then you should file feature requests in Jira.
  
   -- Jonathan
  
   On 9/12/2013 11:54 a.m., Pedro Duque Vieira wrote:
   Hi,
  
   Is there any Look and Feel mechanism in place, like the one in Swing?
  That
   doesn't appear to exist..
  
   Are there any plans to add one? You can only do so much with CSS...
  
   Thanks in advance, best regards,
  
 
 


 --
 Pedro Duque Vieira