Dialogs should use native title bars

Issue #49 resolved
Stefan Saring created an issue

Currently all dialogs created by the Dialogs or Dialog class are using a custom dark title bar. So every application looks inconsistent, because the application itself always uses the title bar of the operatiing system. The attached screenshot shows an example.

Would it be possible to add at least an option to Dialogs for using the systems title bar?

I've tested it on Mac OS X 10.8 with ControlsFX 8.0.1 and JDK 1.8.0-ea-b91.

Comments (52)

  1. Jonathan Giles

    This shouldn't be too difficult to do. I'll take a look when I get a chance (unless you want to implement it and do a pull request).

  2. Jonathan Giles

    The work required is relatively simple:

    • change the FXDialog class not to draw the custom header (and instead draw the normal stage decoration). This is easy.
    • Update the Dialog and Dialogs API to include support for specifying the 'chrome' style: custom or native.

    I'm sure you could do a pull request for that? :-)

  3. Stefan Saring reporter

    What's the goal? Use native title bars only or configurable by the Dialogs builder API.

  4. Jonathan Giles

    Configurable. For now my preference would be the default should be the custom styling, but to have a 'nativeChrome()' method on Dialogs to switch to the native styling. Similarly, have a boolean in Dialog to specify which one to use.

    I should note that 'nativeChrome()' is a temporary name and a better one can be decided in the future :-)

  5. Jonathan Giles

    Proof of concept support for native chrome has just been added to the repo. Please test it out if you can and let me know how it looks on Mac OS - I've only tested on my Windows machine (see attached screenshot).

  6. Eugene Ryzhikov

    Tested on Mac.. Generally works, but we have to control the buttons on the native titlebar. On Mac specifically there is a "full screen" button which is definitely have to be hidden on most of the dialogs.

  7. Jonathan Giles

    Ok - could you dig into that further? My Mac is woefully out of date and it would take longer to get it working than it did to code up this feature :-)

  8. Eugene Ryzhikov

    I'll look into it, but not sure what is available from the API point of view to deal with this. Could you point me to some possible APIs? Also setting up Mac is not a big deal anymore. JDK u94 and Eclipse 4.3 with Mercurial plugin is all you need. No special setup - ControlsFX are compiling and running.

  9. Eugene Ryzhikov

    FYI. I also have VirtualBox VM with Win8 running on Mac. Works really well. Will probably add Ubuntu VM soon for testing. Will be able to test ControlsFX in all three.

  10. Stefan Saring reporter

    Wow, that's fast! I'll be test it today evening when I'm at home.

    On Mac OS X You can get rid of the fullscreen button in the titlebar when you use the StageStyle.UTILITY for the dialogs stage.

    Bye, Stefan

  11. Jonathan Giles

    If you take a look at the changeset you'll see I did indeed use StageStyle.UTILITY. Can you try to work out what needs to be done to get rid of that button?

  12. Stefan Saring reporter

    OK, you already using it. I'll try to check it this evening. Unfortunately I currently only have a Mac for testing.

  13. Stefan Saring reporter

    I've found the solution for removing the fullscreen button in the title bar:

    The fullscreen button is only visble when the owner of the dialog is not set. I've modified the confirmation example in the HelloDialog example class by just setting the owner window:

    Dialogs.create()
        .owner(((Button) e.getSource()).getScene().getWindow()) 
        .title("You do want dialogs right?")
        .masthead(isMastheadVisible() ? "Just Checkin'" : null)
        .message( "I was a bit worried that you might not want them, so I wanted to double check."))
        .showConfirm();
    

    You can see the result in the attached DialogsDemo.png screenshot.

  14. Stefan Saring reporter

    The question is: what is the best solution? IMHO it would be good, when the API always forces the user to specify the owner window. Dialogs always have owners and the windowing system should always know the dependencies to avoid such problems.

    The alternative is to let things as they are and add documentation that the user should always set the owner to avoid this problem on specific systems (e.g. Mac).

  15. Stefan Saring reporter

    Another minor problem when using native chrome on Mac: the font of the titlebar and the titlebar itself are very small, this is probably the result of the StageStyle.UTILITY (see my attached screenshot). Are there any ways to use normal sizes?

    This is not a blocker problem for the native chrome feature, I'm happy that it's available now and looking forward for the next release :-)

  16. Eugene Ryzhikov

    In my view the logic should take into account dialog "resizable" property, meaning that fullscreen button should be only available when dialog is resizable. otherwise it blows the whole concept of size constraints. Unless we find a good, cross-platform way to control native chrome on all major OSes, we'd have to probably stick with custom, but highly controllable chrome.

  17. Stefan Saring reporter

    +1 for Eugenes idea: show the fullscreen button only in resizable dialogs when using native chrome.

  18. Jonathan Giles

    Can someone on Mac OS post a screenshot where the normal StageStyle.DECORATED is used instead of StageStyle.UTILITY? If you could also clarify your preference that would be appreciated.

  19. Stefan Saring reporter

    Independent of Jonathans reply I've just tested the StageStyle.DECORATED instead utility. Then the title bar looks much better, it uses the proper font size and has rounded corners as all other windows and dialogs. When the owner of the dialog is set, then the fullscreen button is also not visible. You can see the result in the attached screenshot Dialog-Decorator.png.

    The only downside is that the yellow minimize button is enabled, I have no idea how to disable it. But this is a minor problem...

  20. Jonathan Giles

    It looks a little worse on Windows (there is a minimise button and the application icon) - see attached screenshot. We could always do different things on different OS's - DECORATED on Mac and UTILITY on Windows, for example.

  21. Stefan Saring reporter

    You're right, on Windows the UTILITY style looks better. Unfortunately JavaFX does not seem to provide methods to specify the buttons to show.

    @JonathanGiles: are you in contact with the JavaFX developers? Perhaps they can provide some helpful hints...

    Currently, as a compromise it would be best to use DECORATED on Mac and UTILITY on Windows. We'll see what Eugene reports on Linux...

  22. Jonathan Giles

    Yes, I am interested to hear Eugene's Linux preference.

    @ssaring I am a JavaFX developer! :-) Although I don't work on the Stage-related code. I will ask but my assumption is that it is not possible.

  23. Jonathan Giles

    I've just pushed a changeset to choose the StageStyle based on the OS. We'll see what Eugene has to say about Linux.

  24. Eugene Ryzhikov

    The Ubuntu native chrome looks fine to me. The is one problem though - it is resizable, but should not be.

  25. Stefan Saring reporter

    Cool, then (when using native chrome) StageStyle.DECORATED should be default and UTILITY is for Windows only.

  26. Stefan Saring reporter

    I've tested native chrome in ControlsFX 8.0.2-SNAPSHOT with my application, it works fine (on OS X). Thanks a lot!

  27. Jonathan Giles

    I'm keen to mark this issue resolved. Before I do, there are a few things to discuss:

    1. Currently the API is called nativeChrome, and I'm wondering if that should be renamed to nativeTitleBar instead. I think that is much more easily understood.
    2. We should file separate bugs related to the resizability and minimize issues. These can be handled separately, most probably in a future release (as there may be some dependency on changes to JavaFX itself). Do people agree, and can someone please file these bugs?
    3. We need to discuss whether native should be default or not? I have opinions both way, so I'm not sure. I think in general it would probably be better to not use native by default, as it would be confusing for lightweight dialogs. Thoughts?
    4. We need to update the javadoc to include details and screenshots of this. I can do this, but I think we should get a set of screenshots for a single dialog. Could someone please email me (or attach here) screenshots from an interesting looking dialog (probably with a masthead as that tends to look nicer imho).
  28. Stefan Saring reporter

    (1) +1 for nativeTitleBar. I see no relations between the term chrome and the title bar of a dialog.

    (2) I assume the changes for soon fixes in JavaFX are higher when someone of the team files the bugs. So the team can also directly discuss those issues.

    (3) IMHO native should be default for all dialogs, except for the lightweight ones. Every good UI app should use a consistent look&feel, the current custom title bar does not match with any application or operating system. For developers it should be as easy as possible to create nice applications, so the defaults should be appropriate. The custom titlebars make sense for lightweight dialogs.

    (4) The dialog sample application should provide all combinations of dialogs for your special requirements. If you need something special, I can help with OS X screenshots.

  29. Eugene Ryzhikov
    1. If the plan is to only control title bar with this, then I agree.
    2. Agree.
    3. I'm 50/50 here. "Modena" does not look native already. What is the point to default to "native"? I think we should leave it for third-party styles, like "AquaFX".
    4. Out of all dialogs I usually go with Confirmation one.
  30. Jonathan Giles

    Ok:

    1. If you feel compelled, go ahead and rename to nativeTitleBar, otherwise I will do it when I'm next working on it.
    2. Again, if you feel compelled, file bug reports on it or else I'll do it when I'm next available.
    3. This is also my feeling - we should have a cross-platform look by default with the option to go native. I imagine maybe more people will go native than cross-platform, but we should aim to integrate nicely with modena (which may mean we revise the styling somewhat in the future....)
    4. Again - if you want to take screenshots and update the repo with them (and / or the javadoc), go for it. If not I'll happily do it, but I'd at least appreciate if you could supply the images for the various platforms.

    Thanks!

  31. Eugene Ryzhikov
    • I'll rename to nativeTitleBar shortly
    • Let me know which dialog you want and I'll send you all 3 images.

    @ssaring, can you file the bug reports please.

  32. Jonathan Giles

    It's up to you....that would be best, but we could also just do one for each platform, as well as the cross-platform style on one of them?

  33. Stefan Saring reporter

    (2) If you think bugs of external reporters have the same chances, I can create them. Where can I find the appropriate bug repository?

    (3) Which title bar style does the default Modena L&F uses for main application window? A custom one (as the ControlsFX dialogs) or the native title bar of the OS? IMHO the default dialog title bar should match at least the Modena L&F.

    (4) I can create screenshots of the OS X dialogs too. @eryzhikov Could you attach your 6 screenshots here? Then I would create the same for OS X. Same images for all platforms would be better for the documentation.

  34. Jonathan Giles

    @ssaring 2) We mean file a bug in the ControlsFX bug tracker, not in the JavaFX bug tracker! 3) We've decided for now to use the cross platform look as the default one. 4) Screenshots have been created, so there is no need for that.

  35. Log in to comment