Slashdot Mirror
Nokia Announces Qt 5 Plans
aloniv writes "Since Nokia announced its switch to Windows Phone 7, people have been worried about the future of Qt. Well, it turns out Nokia is still going full steam ahead with Qt, having just announced their plans for Qt 5. Some major changes are afoot code- and functionality-wise, but the biggest change is that Qt 5 will be developed out in the open from day one (unlike Qt 4). There will be no distinction between a Nokia developer or third-party developer."
At this point, Nokia is just tossing stuff out there as they think of it. "Oh man, we pissed off a massive chunk of our developer base. How do we make them less furious at us? ...besides scrapping the Windows Phone thing, I mean."
"There will be no distinction between a Nokia developer or third-party developer." becomes "Develop it yourselves you lazy bastards, but dont forget to put our name on it too"
I agree. I have looked at QML (I'm a part-time C++/Qt developer), and it looks to me like JS and CSS had a very unsightly baby. QML is also not nearly as efficient or compact as the C++-based widgets. The latter could use a bit of an overhaul to remove some redundancy, but that's another matter again.
:(
:D
Seems like Qt5 will be more buzzword-compliant, though
Anyone up for developing a Qt competitor?
Site & blog: http://www.mayaposch.com
As kde developers will start thinking about and switching to kde5. I see another wave of bugs and instability, the same that made me switch from kdev4.1 to xfce. These architects get excited by new technologies and loose the focus on stability and usability. Let's see what will happen.
Maybe Computers will never be as intelligent as Humans.
For sure they won't ever become so stupid. [VR-1988]
> There will be no distinction between a Nokia developer or third-party developer.
Or indeed not being a developer at all.
Hi.
I am a potential new linux user and my initial specialty/focus will be on the UI side. I have been considering looking into xfce as well. Do you think it's the new dark horse UI behind Gnome and KDE?
My first Journal Entry ever, in 8 years! http://slashdot.org/journal/365947/aphelion-scifi-fantasy-horror-poetry-webzine
The deal between Microsoft an Nokia has been a big topic with many opinions. The opinion that Microsoft actually needed a strong hardware platform for their OS more than Nokia needed Win Mobile for their phones is a strong contender for me. Maybe having a say in keeping Qt open is a clear signal that this is also truly the case. It could very well be that Nokia was keen for the partnering but is not ready to sell their soul and cut off all options for the future. ~
!
No kidding. I tried out Qt for the first time just before the MS deal was mentioned, and subsequently haven't bothered with it. If they're switching to a more open development model that will help to ensure it continues even if Nokia are savaged by MS, and if it's ported to more platforms, then that's enough reason to continue using it.
which is totally what she said
yes, but then you can intermix QML and traditional Qt forms together which is a seriously good thing as you keep the productivity gains for the 80% of common or boring old functionalty and get to work the last 20% in less-rpoductive but mroe functional QML.
Unlike XAML where you have a choice of all or nothing.
I've used xfce and it's pretty nice. The last time I did It was extremely bare bones, you added only what you wanted. I think that was their design philosophy or something so it's a safe bet, I think.
how is babby formed?
KDE5 will not break the world like KDE4 did. Just as Qt5 will not break the world.
http://aseigo.blogspot.com/2011/05/relax.html
http://aseigo.blogspot.com/2011/05/qt5-kde5.html
Climate Progress - Hell and High Water
Why exactly are these two things related? Qt is a completely different development line from WP 7, it's a windowing toolkit not a mobile OS. Show me some good news about MeeGo, and I might, just maybe, get a bit excited.
Sure, you could go on about how Qt is at the foundation of MeeGo, but it's at the foundation of lots of other things too, like KDE amongst others. Good news for Qt does not imply good news for MeeGo. In fact, possibly quite the opposite, as I can imagine a scenario where Nokia had left over contracts with outside vendors, and maybe a few Linux oriented staff that didn't get rid off, so they're just redirecting them at Qt and taking them off MeeGo.
Everyone is living in a personal delusion, just some are more delusional than others.
If you're writing software in C++ that's portable, which GUI library would you use at the present time?
When they bought trolltec they planned on using qt in their phones. What incentive is there to continue development of qt when they plan on using winmo on their upcoming models? do they plan on utilizing "third-party" developers to drop/reduce development costs on qt?
I enjoy xfce4 but am happy with KDE4. It's not a dark horse, just another alternative. On a standard PC I would recommend Kubuntu, but on a netbook it's a trade-off time vs speed. If you want something that just works then install Kubuntu, though it's a bit heavy and slow, but if you have time to tweak (make sure you install ROX) and want the extra horse-power out of it then install Xubuntu. It is not that one is better than the other, it's just a trade-off. They are both great.
Phillip.
Property for sale in Nice, France
I personally say Queue Tee. I would say Cute if it were spelt Qute.
how is babby formed?
I came from a Gtk+ background, but am using Qt Quick (QML) in one project. The widget set as of Qt 4.7.2 is woefully anemic, but other than that, it seems like a general improvement over using C++ for the entire UI. At least 90% of user interfaces (averaged over the world's applications; there are a few very graphics-intense apps that bring down the average) do not need the marginal speed improvement you can get by using C++ instead of QML. Qt does a pretty decent job at making it easy to go between native C++ widgets and QML code, so C++ developers get to focus on the parts of the GUI that need performance.
What is in using QML for me? I get to offload most of the GUI development to a UX designer who is better at that sort of thing (and costs my employer less per hour of work). Then I get to focus on the novel and application-specific parts of the interface. I also get cleaner separation between those application-specific bits and the overall skin.
I don't mean to rain on your parade, but we are developing a lot of QML/JS code and the development time is a fraction of doing the same thing in C++. In addition, we are finding that it is easier to train web graphic designers to use QML then to teach programmers graphic design. There are a lot more JS programmers out there than there programmers who know and use C++.
We are also doing Windows Mobile Phone 7 development and XAML is a really good model. You still have to write code behind in C#. The model works well in separating the design from the code, but you still have to hack XML and C#. I am using both, and QML/JS is a much easier to learn and use.
I read your statements, and they are very similar to what the COBOL programmers were saying to me in the 1980s "Oh this C and SQL stuff is fine for universities and researchers, but it will never catch on in the business world. I heard the same thing from the AS 400 developers in the early 1990s "real business wil run on mainframes, not this Sun server stuff."
Oh and about the comment for a Qt 5 competitor. O am not suret the open source community needs, another C++ framework to dilute resources and add confusion to the community. Maybe a better idea would be to give this a chance and see if it pans out.
The vast majority of user interfaces spend more time waiting for user input than they spend drawing to the screen. Of course, users notice redraw time more when they are the ones waiting. But I've used Qt on a small device (a several-year-old cell phone application processor), and the things that made that UI slow are the animations that were chosen for the UI -- animations that are drawn by the CPU and GPU using compiled code, but with durations that were a little bit too long for impatient users like me.
There is a (mostly overlapping) vast majority of user interfaces that are less responsive than possible because they block the UI during long-latency operations, but that has little to do with the language used to implement the UI, and more to do with how easy it is to kick off background tasks from the UI and push those results back to the UI. (QML has a benefit here because it makes that easier.)
Plus, JavaScript JITters are getting better every few months.
Maybe QML really is easier... I have been doing some Android development lately, and defining the UI in a separate XML file definitely has its advantages.
:)
As pointed out and as I have discovered during my own research into QML its feature set in 4.7 is pretty aenemic. If they can make it a carbon copy of the feature set of the Qt widgets, then it might be worth looking into
Site & blog: http://www.mayaposch.com
Qt already adheres to standards. MOC is just a boilerplate generator and the actual code is compiled with any standards-compliant C++ implementation.
Don't think it really can drop MOC or something like as still be a viable UI library.
Dynamic dispatch is pretty fundamental in event driven UIs, and not sure if C++ can really provide such a concept. Thats why we need more dynamic languages like JScript/Python/Objective-C/C# for this type of programming.
I'm sure there are things C++ is good for, but its not something as dynamic as UIs.
Then kill that performance with JS?
You surely save a lot of CPU cycles on laying out 100k times per minute all those views and dialogs painstakingly hand-coded in C++. Or wait... may I suggest to optimize what really needs to be optimized, and enjoy the productivity boost in creating the rest, not to mention separation of tasks between UI design and application logic programming?
My exception safety is -fno-exceptions.
Oh, I didn't mean to imply that Xfce is a dark horse, just that it itself is a safe bet. :)
how is babby formed?
As much as I'd like to believe that it's because they are good people doing good things, why are they putting money into this, and how long can we expect them to keep doing so?
I've written it off as more or less completely irrelevant
We as in who? The "template metaprogramming" weenies who could not understand for a decade why C++ is a train wreck?
Don't bother; "we" the practical developers creating real-world maintainable software don't need you on our projects.
My exception safety is -fno-exceptions.
may I suggest to optimize what really needs to be optimized, and enjoy the productivity boost in creating the rest, not to mention separation of tasks between UI design and application logic programming?
Of which you can already do now without the need of QML and its overhead. Plus the Qt people keep trying to skirt around the performance issues when people kept repeatedly asking about it and considering how many posts you get about poor performance with QML apps through simple Google searches I can see why. Factor in how many custom widgets people use in desktops apps now and I can't possibly see most people wasting the time and effort to rewrite in QML.
I'd rather having nothing. I'm using Qt to write C++ code not to be a Javascript monkey. Looks like the Qt are trying to make themselves irrelevant with statements like:
Actually QML is there to try to make it easier to develop apps by allowing people to declaratively define their UI and use minimal inline or external language for the binding. It's a perfectly sound practice, variants of which one can be found in various other GUIs, both in thick clients and web development. e.g. Flex,. XUL, XAML, JavaFX etc. For starters it means doing away with a vast amount of boilerplate, faster application prototyping, faster development build cycles, greater portability, less bugs caused by programmer error which ultimately leads to faster time to market and a higher quality product.
I realise if you're too set in your ways to adapt that it might be easier to denigrate such efforts than appreciate their uses, but that's your problem not the platform's.
Ow gawd. Styling of Qt quick resembles Symbian.
greater portability
Wrong, QML will actually be less portable especially when Qt5 will require at least OpenGL ES 2.0. Kiss goodbye any support for embedded systems without OpenGL support and yes there are many.
less bugs caused by programmer error
In what way?
I realise if you're too set in your ways to adapt that it might be easier to denigrate such efforts than appreciate their uses, but that's your problem not the platform's.
I realise that to you a bunch of buzzwords and bling bling might be important but for those of us writing real desktop and embedded apps where performance is critical, this change is mostly useless. Hell even the Qt Creator guys are admitting they will barely be using QML and mostly sticking to QWidgets. If they won't even eat their own dog food, I'm not buying into it. This isn't even taking into account the dearth of widgets equivalents for QML.
I think you didn't look at the code. First of all, QML is NOT Javascript. It is a declarative language that integrates seamlessly with Javascript. As for efficiency: I'd beg to differ. There's nothing inherent in the declarative framework that would make it less efficient than QWidget. QML has expressive power that makes legacy frameworks look almost silly. QML comes with a lot of demos. Try implementing some of them using out-of-the-box pre-QML APIs and you'll understand.
The QLayout system is a complete nightmare -- to get anything that's less-than-trivial, you have to relegate to spreasheet layouting: make lots of extra rows and columns, and then span your widgets across several of them. And good luck if your widget needs to have visible elements outside of its boundary -- and no, it's not only about particle effects, how about highlighting, drag-and-drop/drag-and-clone, etc.
I fully believe that legacy UI framework design decisions (ala GTK, Qt, WxWidgets) have seriously and negatively affected usability of common business applications (ERP systems, I'm talking about you). If you want to design clean, usable UIs using a legacy framework, you are pretty much back to using some sort of a hierarchical canvas (like QGraphicsScene) and laying out everything yourself. QML takes a lot of busywork out of that.
A successful API design takes a mixture of software design and pedagogy.
That's a silly argument. I don't think you're laying out all the widgets by hand all the time, right? You're probably using Designer to produce .UI files for most of your UI. Guess what: QML designer is pretty much the same thing, but gives you much more expressive power. The QWidget/QLayout systems has inherent constraints that cannot be worked around by simply expanding the API. They needed a brand-new paradigm, and they delivered.
All of the back-end functionality (models!) has to be done in C++ anyway, and you're free do develop custom visual elements in C++. In fact, you likely will end up developing custom visual stuff in C++ where you had complex QWidgets, but not for "silly" stuff.
So far in Qt you had to pretty much subclass controls or widgets and write C++ code for simple UI elements like toggle switches, gages, indicators, etc. With QML, you can get simple controls without writing any code at all and using QML Designer (a plugin in Qt Creator).
For complex views, like say a PCB layout, electrical schematic or a document editor, you'll still code it in good old C++.
At least QML somewhat forces you to do clean model-view separation -- of course seasoned developers who know their stuff will do it naturally, but there's plenty of code out there where data is intertwined with visuals. I applaud that QML promotes clean separation of concerns here.
A successful API design takes a mixture of software design and pedagogy.
Couldn't agree more. I will be getting our designer lady a QML/QMLDesigner tutorial in a week or so. That way I'll be getting ready-made user interfaces, with relevant functionality already built in, and I can focus on providing data models and state management for the application as a whole.
A successful API design takes a mixture of software design and pedagogy.
I came from a Gtk+ background, but am using Qt Quick (QML) in one project. The widget set as of Qt 4.7.2 is woefully anemic, but other than that, it seems like a general improvement over using C++ for the entire UI.
My impression is that Qt Quick is another one of those things that's going to come full circle. First you go from a huge set of widgets (QWidget & decendants) to html/css (Qt Quick) and eventually you'll want to build the exact same widgets on top of that again for convienience. Oh well..
Live today, because you never know what tomorrow brings
I think you didn't look at the code. First of all, QML is NOT Javascript. It is a declarative language that integrates seamlessly with Javascript.
More accurately, QML is Javascript with extensions.
As for efficiency: I'd beg to differ. There's nothing inherent in the declarative framework that would make it less efficient than QWidget.
And yet with a simple search of "QML slow" you can find all sorts of examples of QML running slow. All sorts of people are seeing lagginess, etc in QML apps. The best the Qt people have shown have been little toy examples where there may be no noticeable difference. Get back to me when they have a full blown app that has lots of intensive visualization and show me that it has no efficieny issues.
QML has expressive power that makes legacy frameworks look almost silly.
Examples? It really means little to hear people throw out buzzwords and provide no examples of how it is more this or that.
First of all, reimplementing most if not all Qt widgets in QML takes less code than original Qt widget implementations took, line-wise. And it's by a fairly large factor -- a reduction of 5-10 times. Just look at the Qt Quick Components for Desktop -- it's pretty amazing stuff when you realize that a table view is about 500 lines long. For your reference, src/gui/itemviews/qtableview.cpp is 3000 lines long, and it's not nearly as modular and tweakable as TableView QML element.
The beauty and power of QML is shown in the fact that the TableView component's source code is not only fairly easy to understand, but it's very easy to tweak. I had to add per-column delegates for my project and it was a dozen lines or so, took about an hour without any prior QML experience. Good luck with modifying qtableview.cpp. Now I of course realize that there's no full feature parity between the two just yet, but they are alarmingly close. And if you consider source tweakability to be a feature in itself, I think that QML already wins over native Qt views. Even little details make life easier: suppose you want to tweak QTableView and cannot simply derive from it, but you have to modify the source. If you want to copy it over to your own project, you have to at least do a search-and-replace to change the damned class name everywhere. In QML, you change the damn file name and you're done. Add enough of those "little" improvements, and you get something that beats expressibility of C++ by a lot.
Qt could have been much further ahead if they implemented the QML idea back in times of Qt 1.x... And no, I don't buy the argument that the platforms back then were too slow. They'd have had to spend more effort in optimizing things, but there's nothing inherent in QML that makes it slow. All the heavy lifting is done by C++ code or JIT-ed JavaScript anyway.
A successful API design takes a mixture of software design and pedagogy.
Porting a QWidget to QDeclarativeItem is so easy that it could be considered a janitorial task in many projects. Plenty of simple custom QWidgets can be reimplemented in QML with a significant drop in code size, so there's actually a good reason to do that. Especially if you have a designer on staff who got Qt Quick training and can provide you with an "endless stream" of custom, appealing widgetry.
There's nothing architecturally wrong with QML. The current implementation surely has performance corner-cases, just like early Qt 4.x series had, especially before 4.4. The performance issues will be worked out, there's no fundamental reason why QML should perform worse than a QWidget-based ui. Heck, I've found quite a few cases where QLayout-based UIs were stuttering when you resized the windows or dragged splitters -- the QLayout/QWidget infrastructure is seriously broken if you use native widgets, like you had to on OS X for example until very recently.
A successful API design takes a mixture of software design and pedagogy.
C++ simply does not provide the introspection needed for a major application development framework. If it did, you could drop MOC. The way it stands, moc basically generates introspection tables because the out-of-touch [expletive deleted] folks who design C++ couldn't be bothered. That's my take on it.
Every time you interface C++ code with any sort of an interpreted or JIT-ed language, you have to generate "bindings" using an external tool precisely because C++ lacks facilities for code to know about other code. Qt folks were nice enough to maintain such a tool themselves and to make it a core part of their process. I don't consider it a bad thing. QMetaObject system makes it fairly easy to expose QObjects to any other language that's either interpreted or JIT-ed.
A successful API design takes a mixture of software design and pedagogy.
It's not even about template metaprogramming. Template metaprogramming simply does not provide several facilities that are make-or-break for language binding generation. C++ does not have built-in facilities needed by binding generators, this has nothing to do with Troltech/Nokia's developers "ineptness". Guess why swig still exists? Hint: because whoever designs C++ lives on a little cloud-9 where you don't interface with anybody who doesn't use C++. It's a basic deficiency of current C++ spec, and there's no way around it other than running a code generator external to the compiler.
A successful API design takes a mixture of software design and pedagogy.
Porting a QWidget to QDeclarativeItem is so easy that it could be considered a janitorial task in many projects.
Well then why haven't you ported all the QWidgets over for us by now? It's so quick and easy, right?
Plenty of simple custom QWidgets can be reimplemented in QML with a significant drop in code size, so there's actually a good reason to do that.
That's great if all you ever used were "simple" QWidgets. Many people rely on much more than "simple" widgets for real apps.
The current implementation surely has performance corner-cases, just like early Qt 4.x series had, especially before 4.4.
Thus making it unusable for people who need high performing apps. Most people aren't going to rewrite things in QML just because they are promised that years down the line it will stop being laggier and slower than their current QWidget-based programs.
The performance issues will be worked out, there's no fundamental reason why QML should perform worse than a QWidget-based ui.
Sure, if we ignore the overhead over interpreted code.
Heck, I've found quite a few cases where QLayout-based UIs were stuttering when you resized the windows or dragged splitters
And you've reported these issues?
the QLayout/QWidget infrastructure is seriously broken if you use native widgets, like you had to on OS X for example until very recently.
In what way?
The performance issues will be worked out, there's no fundamental reason why QML should perform worse than a QWidget-based ui.
Sure, if we ignore the overhead over interpreted code.
There's no "interpreted code" anywhere in QML. Whatever parsing there is, is done only once. Javascript is executed by a decently performing JIT-ting runtime -- same one that powers WebKit. Instantiating a QML element does not AFAIK cause any textual source code to be parsed or JIT-ted more than once. Surely there will be some overhead due to parsing QML at application startup, but this can be tweaked by doing lazy instantiation via the Loader.
A successful API design takes a mixture of software design and pedagogy.
It's not about buzzwords. Declarative UIs with bindings are a pattern proven to work elsewhere and it will be proven to work in QT. It doesn't mean it is right for every application but it will do for a lot of apps either in full or partially.
Why, it can be done with some template classes, especially with variadic templates accepted into the standard this year. Except, the declaration syntax would be far more ugly, the compilation time would increase by orders of magnitude, and if you screw up, the error messages won't be much less arcane than what you get from moc-generated code.
My exception safety is -fno-exceptions.
QML has expressive power that makes legacy frameworks look almost silly.
Examples? It really means little to hear people throw out buzzwords and provide no examples of how it is more this or that.
Look at any of the demos that come with it. Say the corkboard. Then implement using "bare" Qt.
I have ported a database-driven application to QML, and I can't feel any speed difference between the declarative UI rendering the views and the QWidget views. There are perhaps problems when too many things are moving about at once, but I'm not trying to do that. The only motion is in following the mouse and doing flicks, and this performs as it should.
A successful API design takes a mixture of software design and pedagogy.
because whoever designs C++ lives on a little cloud-9
You could have put the period here. They are also oblivious about such bleeding edge innovations as shared libraries and standardized ABIs.
My exception safety is -fno-exceptions.
We as in guys who don't want a stupid non-standard moc-to-cplusplus-precompiler messing around our make scripts.
And if you say C++ is a train wreck, perhaps you should take a look at how C++0x has improved things.
Qt has forced this "our way or the highway" mentality on developers. Want signals and slots? No, you cannot use your custom template implementation that would make things much easier, you need to do it via the MOC. Properties? The same thing. And don't forget that if you read the code and do your own thing, it'll be rendered obsolete the next time we change the MOC version (you know, like every fucking update).
It's LGPL. It can be forked at any time.
Religion is regarded by the common people as true, by the wise as false, and by rulers as useful.
So if QML is so great why do the Qt Creator guys admit they will barely be using it in the Qt5 version of Qt Creator? The reason is is because it doesn't provide nearly the benefit that is claimed otherwise they'd be pressing full on into QML.
Look at any of the demos that come with it.
You mean all the little toy demos that aren't even remotely similar to the needs of a full blown desktop app? I'll believe it's so great when Qt Creator is implemented fully in QML. Oh wait, that's not going to happen as they admitted they will only be using it very sparingly. Since they don't eat their own dog food, I don't buy the hype.
Surely there will be some overhead due to parsing QML at application startup
So that doesn't explain why QML apps are also laggier while running. Also, I like how you ignored everything else I said. If porting all the QWidgets already written to QML is such an easy task then you have all of the ones that ship with Qt now ported over by next week, right?
First Before you make sweeping comments, you should do a little research, because you are completely wrong. Hence the cowardly anonymous posting. The apps we developing are huge and run on some fairly light hardware. Turns out that QML is f..king fast and the few thing that aren't can be implemented in C++ and bound to QML. I don't believe you have done any testing. I think you are making this up. The data driven part of data driven apps in QML are implement in C++ you twit. That includes the XMLModel. Any other data driven apps are using implement in QAbstractItemModel in C++.
Second, the QML Widgets are coming quickly. Qt components and MeeGo Ux Components are already here and they implement enough to do what you need. The features missing are easily implemented by adding to these components.
Umm, qmlcreator is implemented in QML. Qt Creator is such a simple thing when it comes to visual design that doing it in QML will not expose any performance issues. It'll still use the same editor widget etc. This actually gives me idea to try it out, I'd love to see the reduction in code size. It may turn out to be a quick job for the main window, too.
A successful API design takes a mixture of software design and pedagogy.
Direct porting to QML means that the code still stays in C++. One could start porting QWidgets by designing a small shim class that interfaces the exposed QWidget API to the underlying QDeclarativeItem APIs. Most of what the shim would do is just translating event data types. I've done it as a proof of concept, and there's nothing to it. You literally derive from a WidgetShim instead of QWidget, and it "just works". There's no difference in performance, since the widget code is exactly same, and the shim is mostly trivial data shuffling stuff. If the widget is referencing any other widgets directly (like view delegates), you have to manually intervene, but for most widgets it's not an issue and a shim class suffices. A cleaner port would mean that you manually or with a code rewriting script change QWidget API calls to QDeclarativeItem ones.
What Nokia wants to do instead is to reimplement all widgets in QML script (not C++), to make them less monolithic and more tweakable, and to interoperate better with rest of QML. This is precisely what the QML Components for Desktop project is all about. I'm sure that whatever bottlenecks or shortcomings are exposed by that project get to influence Qt Quick.
Is there a technological risk in jumping to Qt Quick right away? Sure, it's a new code base and it'd be foolish not to appreciate that mature QWidget code base is almost by definition safer. But with every risk there are rewards, and for my projects Qt Quick is the right choice.
I don't immediately see how typical business applications would suffer at all from Qt Quick: their interfaces are typically quite simple. I'm looking at Apple Mail's main window and it has a toolbar, a treeview sidebar showing the mail folders, another treeview for messages/conversations in the folder, a splitter handle, and the message viewer. There's also a sliding listview for mail activity, and three buttons to control that and a little popup menu.
If we assumed that Apple Mail was written in Qt, and it was done cleanly, then the only major task in porting the main window would be to implement TreeView -- this hasn't been tackled that by the Desktop project. The rest is essentially doing design work: setting up properties for the TreeViews and delegates, and just laying out a couple of widgets. The underlying data models would stay untouched -- again, assuming the work was done right in the first place.
A successful API design takes a mixture of software design and pedagogy.
You may as well demand Oracle write Netbeans in JavaFX, or Microsoft write DevStudio in XAML.