Java SE (Java Platform, Standard Edition)

There are a couple of controls in the JavaFX API which extend from a Window object (Tooltip and ContextMenu), everything else just extends from Node. I'd be interested in knowing if the JavaFX team or others are happy with that approach or wish they had just extended those objects from Node as that might help give some cues as to a preferred strategy.

I tried creating a dialog based on PopupWindow for a project and it has a few properties which make it slightly alien to the rest of the app. The window itself must be created on the JavaFXApplication thread, unlike other nodes which can be created in an application init method. The documentation for PopupWindow talks about differing behaviour on mobile platforms where only a single popup window can show at a time (though that documentation might just be dated). When you minimize the PopupWindow on Windows 7 I got two minimize animations, one for the app, then subsequently one for the PopupWindow which looked strange. The co-ordinates of the PopupWindow are relative to the screen rather than the primary stage's scene, so to position the PopupWindow relative to a node in the scene you need to convert the scene node's co-ordinates to screen co-ordinates and position the PopupWindow relative to that. The PopupWindow does not implement the automatic resizing stuff you need for a dockable pane, so either you have to do that yourself or extend from PopupControl, but there is no API for adding children to a PopupControl. Because the PopupWindow is outside of the main application scene, you need to apply css to it seperately and if you do a node walk to dump, modify or search for a node in the main scene, you won't find nodes from the PopupWindow, because it's not in the scene. By default the PopupWindows can be placed anywhere on a screen and don't move around when you move the applications main window, so if you want to keep them inside the main app window bounds or make them move with the main window, you need to implement some listeners and respositioning logic for them. You need to implement a custom drag handler and resize handlers for the popup window, if you want the user to be able to move the window around with the mouse and you don't want to use the OS default chrome for window titles, dragging and resizing.

So, anyway a few things to keep in mind. Some of the issues are not such a big deal and the existence of things like Tooltip and ContextMenu shows that using PopupWindows is a viable approach for some things in JavaFX. It would be nice to see the source code for the Tooltip and ContextMenu to see the approach used for things like accurately positioning the PopupWindow in relation to a scene node.

As the PopupWindow just contains a Scene which contains nodes, transitioning a docked Node from the Applications main Scene into a PopupWindow is simple, you just remove the Node from the main scene add it to either a new PopupWindow, or a PopupWindow which you created earlier and hid, then show the PopupWindow. The viceversa case of transitioning the content from the PopupWindow back into the main scene is similar.

Earlier versions of JavaFX had the ability to draw to a scene outside the bounds of the scenes windows which allowed some interesting stuff like flying saucers launched from a JavaFX applet flying around a desktop outside of the browser window containing the applet - but this stuff was nixed sometime before JavaFX 2.0 was released and I don't know if there are any plans to bring that kind of functionality back.

FWIW, the original context that lead me to investigate the above was to add prompt and alert handlers to a WebView object. After my initial investigation, I will rethink the approach and try a lightweight approach, whereby I do something like create a function popup(webView, node) which replaces the webView in the current scene hierarchy with a StackPane containing the WebView on the bottom and the popped over node on top. This lightweight approach is better for the WebView alert scenario, however for you docking framework scenario, you could go either way (unless you really want the docked windows to be able to be moved outside the main window - in which case you will need to put the content into a PopupWindow subclass).

I'm still happy with it. At least, I haven't run into a problem yet. Previous to this we had Tooltip and so forth as just Nodes, but this presented a whole lot of API problems to us, where for example state on Node such as scaleX wasn't well defined in such a case. The Tooltip itself wasn't what you saw (that was hosted in a popup), so what did the scaleX mean? Did it apply to the nodes housed in the popup, or to the Node? There were a lot of such related issues and it wasn't clear how it should all act (I don't remember all the details but there were some things that simply made no sense in this context).

By breaking it out so that PopupControl was a window-skinnable control, and Control was a node-skinnable control, those issues just went away.
Good observations. The threading issue is a huge pain in the neck. If there isn't an issue yet filed please feel free to file and indicate I suggested it should be filed (so nobody gets an itchy trigger finger and says 'that is by design'). Because frankly, this shouldn't be so. The reason we don't allow you to create a Stage on a background thread is because, at some point, we have to create a native peer and when that happens, you must be on the right thread. But it happens auto-magically. So we need clear semantics on this.

For minimization animations, that sounds like a bug. I'd love to have that filed too.

The coordinate difference is a pain. We have some utils methods which position the popup relative to some node, on the top, bottom, right, and left such that when it bumps up against the screen it will optionally reposition the popup so as to stay within the screen. I think it is all private API at present, though an RFE that asks for this to be made public will be honored (our goal in the 3.0 time (Java 8 time, mid 2013) is to have all API we use to build controls public, so that we have an existence proof where "we know UI controls can be created by 3rd parties because our UI controls are completely built on public API). Although it will take a little while to get it all out there, I'm sure this utility can be prioritized for an earlier release. It seems like the sort of thing that ought to just go on PopupWindow or something.

CSS is interesting, I don't remember the specifics but we definitely had some means to treat, for example, a tool tip as if it were part of the scene from the CSS and event dispatch perspective. We "mind the gap" separating the two, if you will. I don't remember the specifics though.

As for the popup not moving when the window is moved, this seems like it should be some optional feature. Since a popup window is given the parent it is related too, it seems we should also have some way to indicate whether it should track its position relative to the parent window. You can file that RFE too if you like ;-)
With any luck, you'll get that in about 3 weeks ;-)
I think the flying saucer was actually just another top level window, but one that didn't draw the window decorations and was transparent. I thought we still offer that, don't we? I'd have to go back to that old sample and see how it was implemented, but I don't think the OS gives us any way to draw outside of the window. If it did, I'd have done lightweight popups!
Some docking systems (like PhotoShop) do allow for flowing palettes, though for me I rather like the typical IDE solution where palettes are securely docked. However during the drag, I'd want to create a copy or image of the palette and then drag that around in a popup window. However, that isn't quite perfect (since I'd also like to resize the thing dynamically in an animated fashion to show where and how it would fit into the new proposed location), so maybe I would actually rip the content out of the old scene, put it in a popup, and drag that guy around with live resize and everything. Mmmmm. Sounds cool.

Richard

I'm afraid that Dock pane is not high on my priority list. My GUIs really follow a 'web-style' these days (and now with JFX more of an iPad-style). The reason the web became so popular as an application framework (when it was only really intended to be a glorified document viewer), knocking desktop off its rightful thrown, is because web UI's are just so simple. By having a more limited toolkit (and to be fair, styling, never forget that "sexy sells"), the web guys ended up, almost by chance, creating a whole new UI paradigm around simple, easy to use GUIs.

I've been 'borrowing' this web style for my applications for a good few years now (even in Swing), creating simple, 'page' based GUIs with almost no popups, a focus on simplicity, whole page scroll bars and absolutely none of that desktop grey! I've even created my own back/forward/home/refresh buttons in my apps. Users just get it - even the senior-citizens and techno-phobes.

This approach has served me very well (happy users, which is what its all about) and I'd recommend anyone in the desktop space creating a new GUI, especially a business one, took a few moments to think "if this was a web-app (or an iPad app), how would I design the UI?", then think whether your users would prefer that or the super-powered, all-information-in-one-screen-with-lots-of-little-windows-that-can-float UI that your traditional desktop style would favour. It's only 'powerful' if the users can use it.

Ok. coming down from my little soap box now (sorry, I can't help a little rant every now and then): although I wouldn't use it often, a dock pane UI would be a great 'power user' feature, and it is definitely well suited for the more tech-heavy users (e.g. I wouldn't touch an IDE without dock-bars, or a paint tool, or 3D modelling tool, etc). I don't think this would be terribly difficult to implement. I just had a quick play to see what the issues would be and it looks do-able in principle. Maybe this rough code will give you some pointers:

public class TestApp extends Application
{
    public static void main(String[] args) throws Exception
    {
        launch(args);
    }

    public void start(final Stage stage) throws Exception
    {
        final SplitPane rootPane = new SplitPane();
        rootPane.setOrientation(Orientation.VERTICAL);

        final FlowPane dockedArea = new FlowPane();
        dockedArea.getChildren().add(new Label("Some docked content"));

        FlowPane centerArea = new FlowPane();
        Button undockButton = new Button("Undock");
        undockButton.setOnAction(new EventHandler<ActionEvent>()
        {
            public void handle(ActionEvent actionEvent)
            {
                rootPane.getItems().remove(dockedArea);

                Dialog dialog = new Dialog();
                dialog.setOnHidden(new EventHandler<WindowEvent>()
                {
                    public void handle(WindowEvent windowEvent)
                    {
                        rootPane.getItems().add(dockedArea);
                    }
                });
                dialog.setContent(dockedArea);
                dialog.show(stage);
            }
        });
        centerArea.getChildren().add(undockButton);

        rootPane.getItems().addAll(centerArea, dockedArea);


        Scene scene = new Scene(rootPane, 300, 300);
        stage.setScene(scene);
        stage.show();
    }

    //-------------------------------------------------------------------------

    private class Dialog extends Popup
    {
        private BorderPane root;

        private Dialog()
        {
            root = new BorderPane();
            root.setPrefWidth(200);
            root.setPrefHeight(200);
            root.setStyle("-fx-border-width: 1; -fx-border-color: gray");
            root.setTop(buildTitleBar());
            getContent().add(root);
        }

        public void setContent(Node content)
        {
            root.setCenter(content);
        }

        private Node buildTitleBar()
        {
            BorderPane pane = new BorderPane();
            pane.setStyle("-fx-background-color: #0000aa; -fx-text-fill: white; -fx-padding: 5");

            pane.setOnMouseDragged(new EventHandler<MouseEvent>()
            {
                public void handle(MouseEvent event)
                {
                    // not sure why getX and getY don't work
                    // double x = getX() + event.getX();
                    // double y = getY() + event.getY();

                    double x = event.getScreenX();
                    double y = event.getScreenY();
                    setX(x);
                    setY(y);
                }
            });

            Label title = new Label("My Dialog");
            pane.setLeft(title);

            Button closeButton = new Button("X");
            closeButton.setOnAction(new EventHandler<ActionEvent>()
            {
                public void handle(ActionEvent actionEvent)
                {
                    hide();
                }
            });
            pane.setRight(closeButton);

            return pane;
        }
    }
}

p.s. I was surprised when I discovered the popup dialog was transparent, even over native windows. Pretty cool!

Hi Daniel (aka Zonski),
I found your remarks about web- and iPad- (and may I add Android-) style very interesting. Could you elaborate on that a little bit more? Could you show some examples? Maybe this topic is even worth an articel in your blog :-)
Michael

Hey Michael (aka MiPa, or Dr Mick as you'd probably get called down here in Aus :) )

It's a topic I'm pretty big on, and the blog was/is actually heading there but it is such a big, meandering topic that I thought I better get a few of the big-ticket, crowd-pleasing topics out of the way first.

A lot of the apps I've had to build over the last 5-10 years have all had to be web apps. I really don't like coding web apps - you just feel so constrained with the whole web-container, and don't get me started on the whole JavaScript, CSS and cross-browser trio-of-evil. But user's love them, so I had to keep building them.

I used to think users wanted webapps because of the whole ease of deployment thing (that was always the official story), but the more I did, the more I realised it was just because they liked the look of them. They were simple and they looked good. Your default Swing app looked like a spaceship dashboard off a 1960's sci-fi movie - lots of flashing green and magenta buttons on a grey panel.

After a while I started thinking, this is dumb, I can do anything in Swing, it's just a canvas. So I started doing my UI designs as if they were web based (I'd actually prototype them in HTML for some clients) and then I'd work out how to build the same thing in Swing (including the browser buttons). It wasn't hard, and my users were happy - most of them probably still think they are using a 'webapp', especially since webstart meant it was all still web-deployed.

With JFX2, I've started doing the same thing (I can't really share any of my current project screens with you unfortunately but they are web-like with a very iPad-like tablet component and separate touch-screen component), but now we have animations and styling! It's even easier, and also we can start doing iPad (and yea android) stuff too. Funky (but subtle) animated page transitions and animated graphical swipe-lists and carousels have really added sex-appeal to the smart devices. I don't see why a more powerful desktop shouldn't be able to do the same or better.

I have, in fact, got a little framework that I am using and developing internally for my projects. I wouldn't mind open sourcing it (and am gradually starting to) so others can use it as well but it is still in very early stages of development and is being done in an add-hoc way based on whatever my current project needs most. There's a huge difference between a utility library I can use internally vs something suitable for general public consumption. If you're keen you are welcome to have a little look at the not-really-public site for it: http://www.zenjava.com/jfx-flow/

I'm reserving the right to massively mess with the API at this stage though (I am not happy with the current incarnation of the 'browser' and will likely gut this in the next week or two. I also am missing huge bits still (like locking the 'browser' when you're editing a form so you can't leave the current page, and also form validation in general, and currently animated page transitions is in the design but not implemented at all). If you're after tips and ideas on this topic though, feel free to have a browse through the code and/or the docco. And, of course, if you have any comments or input on it, I'm all ears.

Cheers,
Dan Zwolenski (but everyone calls me zonski - for some odd reason Australian's don't consider it a "real" name unless it's not your real name).

Very interesting reading. I'll come back to it as soon as I am through all that material.

Thanks - this is the general direction that makes most sense. Though, if I stick with lightweight (no external PopUpWindow) , animations can be applied to the node itself.

Thanks - regarding your sample code. Though, it wasn't that sexy :). I am worried about the transition, I will have to play with it to make sure it looks realistic. i.e. a user shouldn't be able to tell it is a separate entity. Depending on how it looks I may stick with a lightweight framework instead.

Regarding your thoughts on why the Web Rules, I can't really add anything either way.. I have always been an internal tool developer and the rapid start to finish scenarios (in hours, not days, and all-nighters are frequent) is usually the rule. No time for sexy (even though people want it) - just enough time to slap controls on a form, tie to a dataset, and maybe provide some data validation. Many times exposing a data grid with large amounts of data is what's needed - I have spent most of my time tweaking the JavaFX TableView for this purpose. I rarely use Java for interface purposes - only administrative and analytical purposes. I'm hoping to change that with JavaFX within the next year. Control creation, tooling, and a loose framework (with fxml) in place regarding the Domain (Law Firm electronic discovery) for which I work, I'm hoping to introduce JavaFX form creation vs what we currently use. I HATE to admit this, but the last decade in the industry I work has forced such a fast turn around time - that the majority of interfaces use Access (backed by SQL server, mainly). And yes - for some of the larger sets of data I work with - this causes mid and long term problems due to the nature of how Access works internally with data, and the limited ability of the Access developer to change its default behavior. Mainly resulting in deadlocks on the server, but there are other side affects as well I could write a book on. The largest side affect I have witnessed is the cultural shift that happens - over a decade - when a development shop drops true forward thinking development (and with it those technologies) in favor of serving internal clients (who bill by the hour, and having work to do, any work, is better then being out of work) with a "No is never an option" scenario.

Wait.. This is about Docking!!!!!

Yea, I definitely didn't make it look slick. If you go for lightweight, then they will be constrained to the window they are in. I would have thought one of the reasons to undock them would be to move them outside the window? I admit that, like Richard, I never undock my windows though (I often hide them though) so maybe I'm just not familiar with the intended usage.

When you say you want a smooth transition, what are you looking for? You could implement dragging on the docked version so it undocks in a smoother way - maintaining the size and position in the undocked window as when it was docked.

You probably couldn't do an animation though - what animation did you have in mind? Having worked out earlier in this post that popups can be transparent here's a little hack that may work: if it's just a quick transition (like when Mac closes a window into the trash and goes in like a jeanie back into its lamp) you could maybe popup a transparent window that is the size of your animation bounds and then use this to do your animation, and then get rid of it. You'd be flirting with danger a little here but I reckon it might just work.

I'm not sure what wavelength we're tuned in on, but it seems to be the same one. I've been working on some designs for extending the app framework in JavaFX to include a page-based metaphor which would be useful for desktop / mobile / embedded scenarios. Basically, the page metaphor is so deeply engrained (as well as being useful with navigation and such) that it seems the only reasonable route to take. I want to add some of this higher level framework support not only to make building applications easier, but to do a ton of the busy work for developers in the framework (such as tying it in to browser navigation history the way Ensemble does, and transitions between screens), and also to give the Scene Builder sufficient infrastructure on which it can provide overviews of every page in the app and how transitions go from one page to the next, etc.

There is a lot more cooking in my noodle too, I'm hoping to get it all polished up and on my blog by Devoxx, and start the process. Maybe it could even make 2.1 or 2.2 if I'm really happy with it and you guys show some enthusiasm ;-).

Richard

Given that I'm building a whole framework to do pretty much this, I am obviously interested in seeing what you've got in mind!

Some areas of special interest:

* Your strategy on who should own the page transition. I wanted little clean modules (i.e. each page is stand-alone, reusable instance) so I started off by each page doing it's own animation in and out (works well for "MS Power Point" style transitions, like fade-in and fade-out). A lot of the time though we want transitions that are covering both pages - like swipe left, where both pages move together - the old one swipes out to the left and the new one swipes in from the right.

* Your strategy for the 'URL', how do we tell the navigation system which 'page' to go, and the 'parameters' for that page. My current approach (I keep oscillating on this one) is to have a 'Place' class, similar to GWT's but with less of the fuss: http://code.google.com/webtoolkit/doc/latest/DevGuideMvpActivitiesAndPlaces.html#Places

* Your strategy for activating and deactivating pages. I had to make my whole framework 'controller' driven, rather than view driven. Controllers then have an 'activate' method when they are made the current page. The activate method takes the 'Place' which tells the page what to load and show (for example a PersonPlace would have a personId, which the PersonController would use to load the person details and show on the PersonView - although my person view is all FXML).

* Your strategy for blocking navigation. In particular how to intercept back/forward events when the screen is 'dirty' (e.g. a form has been edited) so that you can ask the user if they want to save before leaving the current page, etc.

* Your thoughts on the ScrollBar limitations currently. Lists, Tables, Trees all have their own scroll bars that you can't turn off. This makes it hard to use them in a 'page' that has a big scroll bar for the whole page. The big scroll bar doesn't get activated because the tree/table/list one scrolls before it grows.

Many other questions and areas of interest too. I eagerly await the blog.

zonski

The basics so far:

A Navigator interface (or abstract class) which has next, previous, and visit(String url) methods. Also some History which is exposed.
A PageView node (subclass of Region) which will host the pages. A PageView has a readonly page property and a read/write navigator property
A Page which is basically the controller. I think. This part is still a bit fuzzy. There is a View interface with a getRoot() method on it too. Still fuzzy.

The idea is that every page is accessed via url (like the rest of JavaFX this would be a String which, if missing a scheme, will end up being relative to the context class loader of the current thread, otherwise it is some absolute URL reference). The URL can either target an FXML file, HTTP file, or Java class. Well, I'm still working out the kinks and couldn't explain the fully glory of it without a massive essay (saving for a blog post ;-)), but that is the idea.
I would put the transition on the PageView I think (so it has some standard built in transition), but perhaps it can get some more specific transition when going from some url to some other url. I'm not settled on that yet.
I will have to detail this more with pics on my blog, but basically the idea would be to target the view, which can either be a Page itself, or it can have some controller which is the Page or whatnot. It is all still fuzzy but that is where I am leaning. At first I was going to target the controller, but that ended up being kind of awkward, but maybe that is still the right way to go. Needs more play time.
I have been thinking about that as well. My Page would probably have the API for indicating that it is becoming active or inactive.
Good question, I hadn't got that far. Seems that it would also be something to build into the Page.
I think you can turn it off if you setup the control so that its min size == its preferred size. In this way it doesn't have a scroll bar.
I'll try to get it out in a timely manner.

Richard

Related Jira's:
http://javafx-jira.kenai.com/browse/RT-17716
http://javafx-jira.kenai.com/browse/RT-17855