With custom controls and more complex GUIs, one usually ends up with a bunch of nested panes. Esp. with SceneBuilder its very easy to put together such a design. Are there any performance implications I should be aware of associated with this approach esp when some of these controls will be used in a TableView with a lot of rows (~1000) and lots of updates?
From my days working in Adobe Flex, this approach was frowned upon and could lead to sluggish GUIs.
No, there aren't. Java FX is better than Swing in that regard.
However, the first thing you should do - if you have concerns like that - is to invest a few hours and create a simple prototype. JavaFX is perfect for RAD. Then you'll see. Nobody can possibly guess what your goal is when you say "TableView with a lot of rows (~1000) and lots of updates".
Even though it is not a problem usually, it always makes sense to optimize your UI.
Proper use of JavaFX layout panes helps. Specifically, take a look at GridPane.
Related
I am making a game. And this time trying to implement menu (-->tutorial) -> game-> scoreboard -> game over
screens.
These screens themselves are quite different in terms of structure. So i am not sure if states is a 100% correct approach here (as I understand states are good for similar layouts) From the other hand many of them has back button to return to previous state, e.g. in tutorial I will have start game and back to menu buttons, etc.
I wonder if there is a clear solution for a problem like this? Maybe there is a special library to handle such cases?
State machines (not only for visual states) are a good solution to implement the behavior of encapsulated components, such as buttons or - in your case - menu items, perhaps even some of your game logic. They can be described independently for each component, and they help to keep your interactions organized, and thus to prevent errors.
State machines are difficult to maintain, however, when you are looking at an entire application: The interactions are usually multi-dimensional (i.e. not only one component is involved, but many, and at different levels in the hierarchy), and when all the different players are taken into account, the resulting state machine will soon become very complex.
From my experience, it is best to use an event-driven approach combined with Model-View-Controller architecture for your application logic, and use state machines at the component level. I would advise to look at some of the existing Model-View-Controller frameworks for this, most notably RobotLegs, PureMVC and Parsley (though to me, Parsley seems a little less complete than the other two).
I have a Spark list with a customItemRenderer that is taking a good 3 seconds to initialize with just 50 items.
I'm using Flex 4.5, my ItemRenderer is already very optimized, using as little nesting as possible, fxg and so on.
Is anyone having similar issues?
I've tried almost everything in the book bar going back to mx.
So the issue was due to the way that spark handles styling the issue is detailed here: http://bugs.adobe.com/jira/browse/SDK-29880 and can be sorted by monkey patching with: http://taytay.com/?p=169
Also removing global css selectors "*" helps.
Avoid HGroup and VGroup as much as possible, use absolute layout instead. I've had this same problem at that's fixed most of it for me.
1 hgroup + 1vgroup each three times = 6 automatic layouts PER ITEM. So in total you have 150 objects, WAY too much.
After applying the monkey patch mentioned by Pedro with only modest performance gains (I suppose we had fewer styles, or the performance was fixed in a more recent patch), I continued profiling the initialization of our List instances.
One thing I found is that Flex spends quite a lot of time in UIComponent's initializeAccessibility function, even though our application does not support accessibility in any way (whether applications ought to do that is an entirely different issue).
Merely adding -accessible=false to the compiler arguments cut time spent initializing a particularly heavy list by about a third! Not only that, the whole application in general feels snappier when windows are opened, controls are shown for the first time, etc. If you have no need of accessibility support, you might want to check this out - if you do, I'm sure something can be done to fix the abysmal performance of initializeAccessibility - simply through overriding it in your component implementations, or through even more monkey patching :-)
Are your item renderers checkboxes by any chance? A few folks have recently run into a bunch of performance issues with Spark in general.
http://blogs.adobe.com/aharui/2011/04/migratory-foul-performance-problems-migrating-from-flex-3-x-to-flex-4-x.html
Adobe has been notified, and apparently are working on it:
https://bugs.adobe.com/jira/browse/SDK-29451
Every time I start a project with some graphical toolkit, one of the first conflicts happen with the decision of how to deal with the visual design and the widget layout: A graphical tool or handcoding?
This is a quite tricky/subjective question because most people will decide based on personal preference. It also depends greatly on the quality of the graphical tool. In this case I would like to focus just on the latest version of the QT library. I do not intend to discuss which method is better. I am convinced that the best answer is: depends on the project.
What I want is a reference to a good non biased article, based on experience after several projects. The article should just describe the tradeoffs of both choices
I started with doing everything hand-coded, and of late have been switching to using Qt Designer for most forms. Here are some benefits for each position:
Using Qt Designer
The biggest time saver for me is managing complex layouts; it saves a lot of tedious coding. Simply (very roughly) arrange your widgets, select them, right-click, and put them in the correct type of layout. Especially as layouts become nested, this is so much easier.
It tends to keep your implementation files cleaner instead of filling them with all the boilerplate layout code. I'm type-A, so I like that.
If you are translating your application, it is possible to send your translators the .ui files so they can see on your GUI where the text they are translating will be. (Assuming they are using Qt Linguist.)
Hand-coding
Control. If you have a layout where you need to instantiate / initialize the controls in a very particular order, or dynamically create the controls based on other criteria (database lookup, etc.), this is the easiest way.
If you have custom widgets, you can kind-of-sort-of use the Designer, adding the closest built-in QWidget from which your class derived and then "upgrading" it. But you won't see a preview of your widget unless you make it a designer plugin in a separate project, which is way too much work for most use cases.
If you have custom widgets that take parameters in their constructor beyond the optional QWidget parent, Designer can't handle it. You have no choice but to add that control manually.
Miscellaneous
I don't use the auto-connect SLOTS and SIGNALS feature (based on naming convention such as "on_my_button_clicked".) I have found that I almost invariably have to set up this connection at a determinate time, not whenever Qt does it for me.
For QWizard forms, I have found that I need to use a different UI file for each page. You can do it all in one, but it becomes very awkward to communicate between pages in any kind of custom way.
In summary, I start with Qt Designer and let it take me as far as it can, then hand-code it from there. That's one nice thing about what Qt Designer generates--it is just another class that becomes a member of your class, and you can access it and manipulate it as you need.
My answer is based on two years developing biochemistry applications using PyQt4 (Python bindings to Qt 4) and OpenGL. I have not done C++ Qt, because we only used C++ for performance-critical algorithms. That said, the PyQt4 API greatly resembles Qt4, so much here still applies.
Qt Designer
Good
Exploration. Discover what widgets are available, the names for those widgets, what properties you can set for each, etc.
Enforces separation of UI logic from application logic.
Bad
If you need to add or remove widgets at run-time, you have to have that logic in code. I think it's a bad idea to put your UI logic in two places.
Making changes to nested layouts. When a layout has no widgets in it, it collapses, and it can be really hard to drag and drop a widget in to the location you want.
Hand coding
Good
Fast if you are very familiar with Qt.
Best choice if you need to add or remove widgets at run-time.
Easier than Qt Designer if you have your own custom widgets.
With discipline, you can still separate UI layout from behavior. Just put your code to create and layout widgets in one place, and your code to set signals and slots in another place.
Bad
Slow if you are new to Qt.
Does not enforce separation of layout from behavior.
Tips
Don't just jump into creating your windows. Start by quickly sketching several possible designs, either on paper or using a tool like Balsamiq Mockups. Though you could do this in Qt Designer, I think it is too tempting to spend a lot of time trying to get your windows to look just right before you've even decided if it is the best design.
If you use Qt Designer for PyQt, you have the extra step of running pyuic4 to compile your *.ui files to Python source files. I found it easy to forget this step and scratch my head for a second why my changes didn't work.
If you code your UI by hand, I suggest putting your layout code in one place and your signals and slots in another place. Doing this makes it easier to change the way your widgets are arranged on a window without affecting any of your application logic. Or you can change some behavior without having to wade through all the layout code.
Enjoy Qt! Now that I am using Java Swing for work, I miss it.
I tend to layout dialogs using the designer but I do all the event handling stuff in the main code. I also do all the main windows, toolbars, menus in direct code.
The designer is just frustrating - a pity since decent drag and drop sizer based designers have been around for more than a decade
It depends on the number of different windows/panels you need for your application. If the number is small, use a graphical tool. It is much faster to get a few windows designed perfectly. If the number is large, the graphical tool can (and should) only be used for prototypes. You need to code the layout to be able to make application-wide changes at acceptable cost.
That includes creating a model of how the UI of the application works and dynamically adding and removing widgets at runtime. For an excellent example of such a model (in a different environment), take a look at the glamour model for creating object browsers.
I object to the suggestion that it is tricky/subjective (at least more than other development choices). It is easy to come up with criteria to decide on. Personal experience and preference are important for that, as they decide when the number of different windows should be considered small. The same goes for tool quality.
My personal opinion (just personal), all GUI based development distracts me too much, my imagination or my mind works very bad when i'm seeing gui objects, i prefer to hand-coding most the time because my imagination works better, you know, is like you were reading a book with no images... when i see nothing else than code its looks like i finish faster...
Second reason, i like c++ so much, so I see the good side of hand-coding, is that I keep my c++ practice no matter if I'm writing something redundant... Coding skill is improved when you only use text... Indeed, i could use nano or vim, but that is too far slow for debuging.
Hand-coding here ++vote
I use a combination of both:
I find for x,y coordinates, Designer is the way to go.
A lot of the other UI properties etc can be set in your code.
I think trying to do UI completely by hand-coding would be a very time consuming project. It's not as simple as setting up HTML tables.
Yes version 4 is bad, but people at work who have used version 3 said it was REALLY bad. Lots of crashing.
I, along with my fellow QTers, are truly hoping that version 5 will be an improvement.
I know this is an old question, but I hope this helps! One man's experience.
I've just found out about View States in Flex (v3.0), but I am not really sure how widely this is used in real-world applications. Is it a good practice to use it? Are there any pitfalls such as maintainability for instance?
I also used states in an enterprise-level app. But very lightly.
States can be really useful to clean up your code for some cases. There is a performance down side, if a state adds a child, the child will not be removed from the list until you go back to that state and and add a new child.
I think states can be useful if you need to enable/disable make visible/invisible a bunch of components back and forth (depending on a state). This is the ideal use-case of states in Flex.
I've used states heavily and find them a far more elegant solution that lots of conditional code. Indeed, I initially avoided them for some of the reasons given above, but after the app became very complex, with multiple variant "states" I realized that I was fighting the framework.
Frankly, I'd make the same observation about bindings. If you don't understand some of the subtleties, they can be your undoing, it's true. However, writing your own code to achieve the same thing seems like duplication of effort. Take a look at the generated code sometime and also read some of the good deep-dives on bindings out there.
I started using states in my app (enterprise-level application) in various places, and have since refactored them all out. Most of my MXML has been replaced by pure AS3 components, and I'm skeptical of binding and the flex component lifecycle. There's a lot of convenience tricks advertised in the Flex framework that begin to feel cumbersome and slow once you really start using them.
Like anything, your own mileage will vary. They might be useful if you can avoid the "everything is a nail" syndrome. Maybe I couldn't.
I'm currently building an application that is presenting tabular (fetched from a webservice) data and have squirted it into a datagrid - seemed the most obvious way to present it on screen.
I've now come across a few limitations in the datagrid and wonder how I might move forward. As a relative newcomer to flex development I'm a little lost.
A few things I am wanting to do.
The data is logically split into groups and I would like to be able to have subheadings in the grid whenever I move to a new group.
I would like to be able to highligh individual cells based on their content relative to other values in the row - ie highlight the cell with the highest value in the row.
Is this possible with the standard datagrid?
I'm actually using the try-before-you-buy version of flex builder at the moment but I have ordered Flex Builder 3 Pro - which is on its way to me. I understand there is an 'advanced datagrid' control in this version - perhaps that will support some of what I wish to do?
Alternatively - is there another way of building custom tabular data?
stay the hell away from Adobe's AdvancedDataGrid. You will learn quickly it has many shortcomings, you will think you are better than it and override a few things here, tweak a few things there, but in the end the ADG will absolutely destroy you. Heed my call and avoid this at all costs. The ADG was outsourced by Adobe to their failed Indian team that has sense been disbanded, it alone counts for over %30 of the entire flex framework, and their are horrible deeply rooted issues that are better off starting over at this point. STAY AWAY FROM THE ADVANCDEDDATAGRID AT ALL COSTS!!!!!
The DataGrid is the best bet for that, but also check out the AdvancedDataGrid (here are some AdvancedDataGrid Demos with Source from FarataSystems).
(source: flexicious.com)
Both the DataGrid and AdvancedDataGrid are notoriously hard to customize, and everything you'd like to do is pretty advanced, so it will take a while to get going, but you can do it eventually.
There's no other way to build tabular data unless you start doing some advanced things with some of the data visualization libraries out there.
Good luck,
Lance