Im in the verge of starting a new RIA development. We've been using Flex/Flash for the last 2 years but we were considering using a more OS approach so we though giving JavaFX a try since it seams the only solid option available. However after a couple of days of research we found out that there is not such thing as a datagrid for it, at least not in the core API. For those unfamiliar with Flex, a Datagrid is a component that allows you to display a collection of data in column-row layout (much like a HTML Table on steroids). The beauty of it is that you only need to worry about the data itself as the component does pretty much the rest (sorting, column dragging, etc).
Im afraid to ask... but is there something slightly similar for JavaFX?
We require nothing as fancy as Flex Datagrids/AdvancedDatagrids, we only require a easy, straight forward way to display grids of data that are able to have a little of interaction like clicking, sorting and that are able to display images, buttons, etc. without having to download a ton of different jars.
If there isn´t something out there... This would be a shot in the back of the head to the idea of giving javaFx the chance to compete with flash on our project (which is sad).
I really cant believe the SUN people didnt include something like this on the core API...
There is currently no datagrid you can use JTable for that. Such a thing should be available in the next release of JavaFX I think. See my answer here for more information about available JTable implementations. You mentioned the JFXtras project with that you are able to embed those Swing components into JavaFX.
There are external companies selling such a component. E.g. do a web search or look here
For apache pivot you should ask them directly for the pros and cons; they are very responsive and honest.
Related
I've recently decided to create a web app to host some algorithms - I normally just create them without care for UI. However this time I need to dive deep into UI. I'm familiar with bootstrap, css, asp.net and have made a good start.
I'm finding it very difficult to deal with asp.net controls in the design view and having too much trouble trying to achieve simple tasks such as moving controls to different areas of the webpage. When I have two textboxes the design view forces one on top of the other leaving me so confused. Then when I try to move my bootstrap button it randomly creates paragraphs and refuses to move the button!
I'm looking for some genuine sincere advise on how I would deal with the design view on asp.net when moving controls and what the best techniques are. Also advice on how to make a modern UI, best techniques (perhaps bootstrap mentions) etc...
I am creating a fairly simple data display app in asp.net (visual studio 2015) - (most of the algorithm complexity is going to be behind the scenes and nothing to do with UI). Comprehensive and detailed advice would be really appreciated. Specifically modern good looking UI in relation to data grids, textboxes for user input (as parameters), dropdowns - you know the typical data app.
I'm sure this will be greatly helpful to many others as well!
Yeah, as I web designer who has had to work with asp.net in the past I completely feel your pain. It's not easy to get a modern look mostly because asp.net isn't a modern tool and kind of has a visual vocabulary all its own.
That said, I found I could get decent results by sticking as close to CSS based solutions as I possibly could. You can see some of those results in the following links:
http://www.design-experiments.com/
http://www.troyjnorris.com/shoppingcart/
I found that a minimalist approach tends to come with the best results.
A good process to follow:
- Build what you want to build.
- Add container divs to make selecting elements easier around your controls. This will greatly improve your ability to position elements the way you want.
- Use your browser inspector to figure out the auto generated element names as they appear on the screen. Getting good selectors is half the battle in CSS.
- Rip out the styling you don't like. Standard reset style sheets won't do here. You'll have to build your own to zero everything out on the elements you want to style so you're not fighting the out of the box look of the controls. Again you have to rely heavly on your inspector in a web browser to see what styles everything is inheriting.
- Use google fonts to define visual style of the page.
- Stick to mostly black or white backgrounds.
- Bootstrap is helpful for a responsive grid, but won't do much good attempting to style most of the elements on a page as they're not meant for that.
- As you might have noticed in the examples above the visual interest comes from elements that are unrelated to the asp.net structure and limitations. So have something like that, even a background image or some paralax so it feels like something is going on on the page.
Hope that helps.
I'm familiar with Actionscript and Flex. But when it comes to design the interface in Flex, I find myself that do not know where to start. I like to know what are the online resources/books to create the cool user interfaces like TweekDeck and Adobe Digital Edition.
UI like in the ones like TweetDeck are done by custom skins. You need to look into skinning of flex components. If you are using flex 4 i.e, the spark components, its more easier to skin them. Also you can use Flash Catalyst if you are finding it difficult to skin using Flash Builder.
You have to have design skills to make cool interfaces. #jase21 is correct that the spark components are easier to use (once you understand how to do it, which may mean unlearning a lot of Flex 3 habits you may have acquired). But just being able to skin components doesn't mean you will have great-looking interfaces. If you don't have those skills yourself, try to hook up with a designer who can make the comps in Photoshop or another graphics program, then you can implement them in Flex.
Look into Flex Catalyst. It is still green -- not nearly as capable as Expression Blend on the Silverlight side -- but it is a pretty good start. Catalyst is the tool that designers can use to apply their Illustrator/Photoshop art to the skins in your app.
Unfortunately a lot is not skinnable via Catalyst. It is also one-way at this time (the two-way beta is far from being useful IMO) which makes the Dev/Designer workflow cumbersome at best. That being said, I have an amazing looking app based on work my designer is doing in Catalyst. It takes some work to get it over into your app, but it can be done, and the results can be fantastic.
Flash Builder has a "design view" mode... although honestly ever since version 4 it has been a little picky and buggy.
Without that, you could try this, but I've no idea how it is:
http://flexible.riaforge.org/
Basically these are WYSIWYG gui editors, drag and drop components into a preview screen. They're nice when they work correctly, but it's tough to do.
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'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
I currently do a lot of work in ActionScript 3.0, I also love to program in Java. Is JavaFX perfect for me? What is the general feeling on JavaFX, will it become a power house, or go down the same path as Java Applets? Could the designers I work with become comfortable with JavaFX to the same extent they are comfortable with ActionScript and JavaScript?
Just wanted to add my $.02... I've been working in JavaFX for the last 4 days on my first little side-project using it. As some background, I've been programming professionally for about 9 years, starting with C, and have been doing Java and C#/.NET for the last 6 yrs.
IMO, JavaFX its way more frustrating that it should be. Here are some gripes:
The syntax is just odd at times. It could easily be more like Java, since its JavaFX. But the syntax isn't an easy transition from Java.
The order of items in a .fx file actually matters, which means you run into stupid circular reference errors, and "oh you can't use this variable yet because it hasn't been initialized" problems that the compiler should handle with ease, but doesn't.
Random things just don't work. Actions/events on Swing controls don't always work, for example SwingSliderBar's onKeyPressed/released don't seem to be called.
Error handling is just bad. If an exception occurs that isn't handled, there is no real way to tell other than the Java console, and UI elements start to react funny. For example, make a SwingText box and bind its value to a variable. Now trying to edit the value in the text box will throw an exception because you cant edit the bound variable. However in the UI, the text box just starts having funny things happen. some characters only 1/2 paint, sometimes backspace does nothing, sometimes it deletes a character, sometimes you can press 2 keys ont eh keyboard like "1" and "2" and the text box will end up having "21" entered in it instead of "12", etc...
Although my absolute #1 problem with JavaFX development right now is Netbeans. It is pathetically bad at JFX. Can't debug, errors display wrong in the IDE (I've had it flag comments as errors!), the intellisence only works like 40% of the time, event he code templates preprogrammed in the IDE for drag & dropping controls aren't correct. I forget which one, but one of them drops a "&" at the end of the inserted code that is never valid and always has to be manually deleted... its just plain awful, and is unacceptable for a company like Sun.
Another gripe is general documentation. Its just lacking. Somehow the JavaFX API doesn't even come up as the #1 search result on google when searching for methods/classes. Tons of "examples" out on the web don't work any more as every version has major refactoring changes, and classes removed or renamed.
Overall, I give JFX a 4 out of 10. I want to like it, but JFX 1.1 just doesn't cut it... its definitely not what I would consider "production ready".
A resounding "meh".
When I looked at it a year ago, they had a one-way SVG to JavaFx conversion tool. Great, so you can author your visual content once, mark it up with a lot of behaviour, and then the next time you want to make it look good, then what?
If you take a look at this tutorial you can see what I mean. We're drawing stuff by dragging shapes from a palette into source code. OMGWTF. I am not showing that to my graphics department.
I hope I'm wrong about JavaFx, but I don't think they get it. Please, won't somebody at Sun give us a presentation layer that doesn't have its tentacles inextricably intertwined with code?
I left my last job to move from Java to .NET development.
There were a number of reasons for making the move, but the single biggest reason was that I was sick and tired of trying to build 1st class UI software with Java & Swing. It has been six years and I'm so glad I moved on. I see no reason to believe that Sun finally understands UI development with JavaFX.
I am convinced that Microsoft is finally in the process of giving us a platform to build rich interactive applications in the browser. I say that after having built commercially available software which was delivered as a Netscape Plugin 13 years ago, followed by ActiveX controls and Java Applets, and seeing all of these platforms fail to become ubiquitous in the enterprise for one reason or another.
I realize that Silverlight 2 is still lacking in depth and maturity, but Microsoft has shown me enough commitment at this point that I believe it will be the dominant RIA platform in a few short years - at least for projects which require a "real" programming language. I am sure Flash et al. is not going away anytime soon, but Flash is not appropriate for the kinds of software my company builds.
The icing on the cake for me is the fact that I will still be able to use Visual Studio, C# and a large percentage of my current code base (the core engine which is entirely separate from the UI). Of course, if you are coming from ActionScript, this would not help you.
One more important point is the fact that Silverlight and WPF share so much in common. Our plan is to share a large amount of implementation between Silverlight and WPF versions of our software. It is only a matter of time before WPF is the standard for Windows applications – I don’t know whether that is a couple of years or ten years, but it will clearly happen over time. Being able to target the most popular browsers / OS’s with Silverlight and Windows from the same code base is a tremendous advantage IMO.
If you know Java then moving to C# is a piece of cake. And unless you are using one of the nice (not free) Java IDEs, then even the free versions of Visual Studio will be an improvement over what you are used to. The hurdle will be learning the new way of doing things with XAML – but it’s some pretty cool stuff so you might actually enjoy it.
Although it appears fairly powerful in terms of capabilities, I'm kinda blah about JavaFX because of its structure and implementation. It seems like a really half-hearted attempt at getting into the Flash/Silverlight market. Too scripty.
I would argue in favor of going the Silverlight 2 route, but I'm primarily a C# developer so I'm a little biased there. If you don't like that route for whatever reason but still want a richer UX for your users, I'd suggest Flex; it seems much better organized than JavaFX to me.
Just my two cents on the subject.
If you know Java but want to do the stuff you thought was only feasible in Flash - then yes JavaFX would be good for you.
Without a doubt it's going to be much more easier to merge your Java knowledge with the design stuff.
And I believe the tooling will only get better which will make it simpler to use.
Unless you’re working on an internal app I would stay away from it. Users generally don’t want to have to deal with another program that accomplishes the same thing as Flash. I don’t think its install base is large enough yet to make it convenient for end users.
I've been developing Flash Applications with Flex for about 2 years now and I decided to give a try to JavaFX because we are constantly getting user complains that they cant use the applications from their IPhones (and I love Java).
That's one strike for Flash (no wide mobile support).
To be honest I was quite impressed with JavaFX (in a very bad way).
The documentation is incomplete.
The script is simply awful; its this weird hybrid between JSON and R with a feeling of a Java-deja-vu.
I spent the first 3 days painting polygons and making gradients with CODE... WTF!!
I tried to convince my graphic department to try it and they simply don't seam to grasp how the production suite is supposed to work, they keep complaining that Flex skinning is way easy and looks better in the end (Which is absolutely true).
The "CSS support" is simply a bad joke.
It generally feels like a mediocre attempt to offer an option for RIA frontend.
I can only think of a couple of good things about it:
It can be run from an IPhone / IPad and almost all mobile devices.
You have access to all the Java code you want which is great considering the limitations that ActionScript has (no overloading, no private constructors, etc). This is a great thing for us the programmers, but lets remember for a second that this is a frontend/presentation technology... that means that users will have to actually see the thing, so if it doesn't look good and have cool animations / effects they wont dig it.
The Script is way less verbose that MXML files are (with the cost of being unintelligible).
Talking about performance... Flash Player is this huge green blob that keeps growing and growing until no RAM is left compared to how JavaFX runs (JVM rocks! unfortunately this has nothing to do with the actual JavaFX API its just that the JVM... well it rocks!).
It has this cool feature where you can drag the applet outside the Web Browser.
In the end, Im happy I have an option to go mobile but this is light years way of the matureness that Flex/Flash has accomplished regarding RIA applications. The future of Flex/Flash as a wide distributed web technology is not clear (it may end up being used only for annoying banners and online games), no one wants to depend in a close technology as the Flash Player is, that's why the whole Web community is striving to get Flash out of the picture (HTML5 video support, No Flash Player for Apple devices, etc). So an attempt to have an open one is always welcomed, it's just that JavaFX feels like this incomplete rushed beta version of something that Sun felt obligated to come up with in a weekend during a bad hangover.
I Hope this is useful to someone (and offensive to someone at Sun/Oracle =p ).
I've spent the weekend 'playing with it. I see nothing useful in it. It's a iteration of swing / awt. I guess it will be nice for mobile devices but beyond that its nothing useful.
Ideally I'd like to use flash but find it painful to intergrate with a backend of any type.
Well, the syntax of both ActionScript and JavaFX seem to share a lot of similarities, so maybe "Yes".
I'm learning JavaFX script at the moment and I actually like it. But what I don't like, and is maybe it's biggest drawback, is it's awful documentation, which is often not up to date or incomplete.
I've been working on a JavaFX application for several months now. Personally, I love the language. They seemed to me to have made some very smart decisions in choosing the syntax and language constructs (I can bore you with a list if you'd like). I've been programming in it for a few months now and it seems like a very efficient and even enjoyable language to program in.
I think its best use right now is for desktop applications and/or applications deployed through webstart. On the desktop it has a rich set of features and can still make use of the other features of Swing and the rest of Java. From what I hear applets are still slow on some systems, and without Android support the mobile capabilities are non-features. The applet/mobile/TV/web support seems to me more like a bonus for desktop developers then as key features that would get you to use the technology.
So it really all depends on what you plan to use it for. If you are building desktop applications that you want to run on the Java VM that can make use of easy multimedia and rich ui controls, then I think there are good reasons to look at the language. WebStart has improved quite a bit and makes for a nice deployment tool. If you are looking to build web applications, then it might be interesting, but for now I'd say HTML5/ajax are more relevant (you might want to look at ZK in this case). However even with HTML5 ajax has its limitations, and if you find yourself running into them then JavaFX may offer you options. For mobile platforms it won't be relevant until there is stable Android support - in that case I'd just stick with the Android platform itself for now.