Do any developers use JavaFX alone over an FXML?
The benefits are obvious and of course knowing what the layout does is helpful. So I am wondering if there is any reason to learn about how the placement works and how everything works together behind the scenes of an FXML, as if I were to hard code it all?
I am trying to self teach myself somethings and I don't want to "half-ass" it. I coded very little in JavaFX, and used an FXML once, but if no one codes in JavaFX alone (or if there is any point to), maybe I'll just skip the process of learning about the code itself and jump right into the FXML
Sure it is possible to use JavaFX without FMXL!
But if you want to use FXML you could take a look at the Scene-Builder. Could be very useful and save you some time because you don't have to write all the FMXL yourself.
This thread should kind of answer your question too:
Java FX: declarative vs procedural
Hope this helps!
Related
I have started working on javafx . I wanted to know the difference between javafx and Tornadofx . How they are inter-related and different from each other.
Also when to use what.
Are there any cases where javafx is more useful/advised to use than Tornadofx or vice-versa?
JavaFX is more like a toolkit (it has all the foundation needed for building a GUI). It is a feature-complete "toolkit", but it is very verbose, and the syntax contains boilerplate code, which makes it hard to maintain. That's where TornadoFX comes in. TornadoFX is like a framework based on that toolkit, which does away with all the boilerplate code, and makes the GUI building declarative, to the point that it resembles HTML.
Also, even though TornadoFX can be used from Java, it is meant to be used from Kotlin (JavaFX can be used from Kotlin also, without any issues).
TornadoFX simplifies and streamlines the GUI building process (makes the code cleaner), but it uses JavaFX "under the hood", and as such, is interoperable with JavaFX.
For example, you can create a widget in pure JavaFX code, and then use it within TornadoFX, or, for example, create a whole window in TornadoFX, and then call it from JavaFX.
The main takeaway here is that TornadoFX doesn't restrict JavaFX in any way, and you can still reach low-level JavaFX stuff from TornadoFX.
Besides just the GUI builders, TornadoFX also contains useful tools like the ViewModel classes, which separate the GUI and logic (which is available, but not mandatory in any way), and some other useful tools.
Personally, I'd always use TornadoFX, because it makes the code very concise and easily-maintainable, while, at the same time, no features of JavaFX are lost.
Currently accepted answer didn't answer this part
Are there any cases where javafx is more useful/advised to use than
Tornadofx
The point of the accepted answer is that for standard simple GUIs Kotlin combined with TornadoFX will get you up an running quick. This is true.
Some examples where straight JavaFX is better:
JavaFX 3D subscenes
interops with Swing (I'm not sure how you would even use Kotlin here, but maybe TornadoFX by itself would work)
Canvas based renders
High Performance custom Event processing
Clearly these are scenarios that do not represent the majority of GUI apps, rather high performance and custom render type applications. So generally speaking if you are starting from scratch... ie... you aren't already well versed in JavaFX, then using TornadoFX is a good starting point.
On that note opting to use Kotlin as a starting point is interesting as well. I personally don't find it that advantageous over just writing in JavaFX, but I have a lot of experience with JavaFX so I might be biased. Also while you are not forced to do so... it is painful to develop in kotlin without intelliJ which is all part of that company's plan for making Kotlin in the first place.
All that said:
and the syntax contains boilerplate code
This is true to an extent and Tornado does reduce the boilerplate a bit by forcing you to go through a standardized set of APIs.
But...
which makes it hard to maintain.
I disagree. It is not "hard" to maintain. It's code you copy/paste one time and likely never changed again. We should not be rushing so fast to obscure and encapsulate every last ASCII character from our code bases in the name of "maintainability" while shooting a torpedo into the side of our performance.
Im just pondering best practice with an application I'm developing. Its a simple one window application using qt creator. It's just going to start a QProcess and show the output in a QTextEdit box. To do this there needs to be a bit of processing between the output of the QProcess and the QTextEdit but i dont know where i should do this, should i create a new class to do that or add member functions and extra signals and slots to my main window? I dont want mainwindow to become bloated and hard to read but equally i dont want to have more source files than really I need.
Any thoughts?
The main window class can very easily get bloated with all kinds of functionality. I've dealt with that myself, so it's a very real trouble.
Really, though, this is not so much of QT question as it is an object-oriented design question. The key is that your output window does not need to be a part of QMainWindow, so it probably shouldn't be. Make the display a widget, and insert it onto the main window. That is much more flexible, as if you ever need to move that output pane for any reason, it won't be coupled to a specific part of the program.
The logic that feeds data into that output pane should also get its own class, separating the responsibility for displaying the output from the responsibility for acquiring the output.
For reference on the concepts behind my suggestion, see the Single Responsibility Principle and the separation of concerns.
Also - you may wish to have a read at this link to model view delegate information which is how I tend to develop in Qt. Like the person above says - this is more a question of good OO design.
Guys i have struggling with flex since a day or two.I havent found a nice short tutorials.Actually i also have been struggling with FLEX IDE too.Please indicate a nice good tutorials for this
I basically have questions like
Cannot use Alert in AS
Including a AS file in mxml file
org.com.structure and the as file in it.Why do we need to say pacakage org.com inside the as file
You can use flex Alert class. In pure AS, unlike JavaScript, there is no alert().
<mx:Script source="script.as"/>. But script.as will not know about MXML file, it's better to use class defined in as file as a control in MXML.
Because packages are compiler-enforced design decision, and who we are to discuss it.
Flex in a week!
http://www.adobe.com/devnet/flex/videotraining.html
This video series helped me a lot..
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 always thought that separating the UI from the logic is the way to go like the use of class files in Flash CS3/CS4 or MVC in web frameworks but recently there are plenty of examples and posts using ActionScript embedded in MXML.
Is there a benefit to doing this? Am I missing something.
Don't get too caught up on the "rules" of MVC and the like. Ultimately you want your code to be setup in such a way that it will minimize the impact/churn of future changes. It's less important "where" the code is and more important what and how it's interacting with other code. I see far to many people take a simple component like a login screen and make models, view, controllers, view helpers, service facades, etc. It ends up being like 75+ lines of code for something that should have been about 20. It also spreads the code amoungst a bunch of files rather than one. So in the end, you've made maintenace hard, not easy. I'm not arguing for ignoring design patterns, but rather being practical about it. Hope this helps.
In my experience, there's not much of a difference whether you write a component in ActionScript + MXML, or solely in Actionscript. Personally, if I'm writing something that's layout heavy with a little logic, I'll do it in MXML. Conversely, if it's code heavy and has little layout, I'll write it in Actionscript.
I suppose you could always separate the view and model, but then you have more files to maintain. Sometimes it makes sense, but I have yet to see a compelling reason to do it all the time.
I go by a few simple rules:
If a bit of code is just a single short line and it isn't something you can reuse elsewhere -- mere glue code -- put it directly in the MXML tag.
If it's too long to fit comfortably in the MXML tag or it is something multiple components in that MXML file can use, put it in a function in a Script tag within the same file, and call the function from the MXML tag(s).
Everything else -- full classes, large functions, things used by multiple MXML files -- goes in a separate .as file. This includes single-LOC methods that are part of a larger class, as opposed to the standalone functions the other rules cover.
I agree with Erich Douglass, to a point. Generally, if I can do the layout with MXML it's just easier to maintain. I mean, who wants to write all that crap in a createChildren override if you don't have to? Besides, the MXML is easier to read.
Whatever you do, though, remember that if you are merely calling a separate script file for an MXML component (Foo.mxml calls Foo.as for its ActionScript) you are losing the code highlighting feature that helps you work between the MXML and the ActionScript. I like to keep them both in the same place, so when I click on an ID in an MXML element I can see at a glance where it's being referenced in the AS.