As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Which is better, Qt4 or JavaFX?
I work for a startup. We built the first version using JavaFX. Now my superiors are suggesting a shift to Qt4.
Is it a good decision to shift?
The question like this is too broad to answer meaningfully.
Qt4 and JavaFX have different goals.
Qt4 is for writing cross-platform desktop applications
JavaFX is for writing rich Internet applications
Qt4 allows for better desktop integration (drag&drop, playing nice with the configuration systems of different platforms, native look & feel, ...), so if you want a nice desktop app, use Qt4.
OTOH, Qt4 cannot be used for an Internet application (web app), so if that's what you want, use JavaFX. JavaFX can also be used for desktop apps, but it requires more compromises than a dedicated desktop GUI toolkit like Qt4.
So what are your requirements?
Edit:
Based on your comments:
Standalone desktop apps are not JavaFX's main goal, but if it works for you, I see no reason to change it.
You can write great applications using JavaFX, especially because you have access to all the stuff the JDK offers. As to system integration: While QT4 is better in this respect, Java already offers a lot (such as Swing an JDK 6's new system integration features). So if you don't intend to write something highly integrated (such as a Windows shell extension), JavaFx will be fine.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
As seen on this thread, it seems that the missing part to be able to run DirectX on Linux natively are vendor drivers.
What exactly are vendor driver? Are they drivers interfacing a specific model of a component, or a family, or even any of them? What are they coded in? ASM and C most likely?
How would someone (or a team) create these drivers for Linux? How would it be integrated into Linux? Would the games or applications in general made for Windows and using DirectX need any tweak for Linux? Would companies making games build their games for Linux knowing they can be used without or with only a few tweaks needed?
How hard would it be to make these drivers? How long would it take? Would it require any specific knowledge?
I know this makes a lot of questions, but I'm very curious about that and why no big groups have ever worked on that seriously (even though there must be a good reason).
Thank you a lot in advance for your answers!
EDIT: This is by no means an incitation to a debate of, for example, OpenGL vs DirectX, or Windows vs Linux. By reading the FAQ, I can't really see why this thread isn't constructive as it asks for pretty well-aimed questions which should be answerable quickly.
IMHO the main reason no one really bothers into dealing with directX is based on the fact that there already is a graphics library (mesa in the special case of Linux) available that fully supports any desired graphics operation also available with DirectX.
In contrast to following DirectX, which is a specification based on so called intellectual property owned by a single corparation the API used by this library called openGL is an open standard agreed upon by a consortium of hardware manufacturers.
Different from the philosophy of constraining it's use to just one operating system possibly trying to shackle its users to the one and only platform openGL was intended as a platform independent API right from the beginning.
Following this principle in contrast to DirectX being available just on one single platform openGL is available on any computing platform ranging from android based systems, Mac and numerous other UNIXoid systems including Linux even to Windows machines.
Using any other API than openGL would break this platform independence, which probably wouldn't be received as a progress but rather as a regression.
To sum it up possibly the main reasons to favor openGL over DirectX are the following:
openGL is an open standard while DirectX is proprietary
openGL is available on any platform DirectX is only available on a single platform
any operation supported by DirectX is supported by openGL as well
if they are really needed DirectX calls can be provided by a wrapper library pushing operations down to openGL as for example done in WINE
Mere availablity of a DirectX library implementation alone wouldn't enable any binary code designed for the Windows platform to run at all as the whole set of system libraries and infrastructure still would not be available at all. As a matter of fact even the binary format in use PE/COFF on Windows ELF on Linux is different.
An effort to supply a whole compatibility layer including needed system libraries is already on the way. As already mentioned above it goes by the name of WINE. (see: http://www.winehq.org/)
I hope I gave you some good reasons why no one ever tried (or will try) as you requested.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
I have seen many people writing that Java ME (J2ME) is dying. Is it true? What is its future? Should I learn Java ME if I want to create apps for smartphones? If yes, where to start?
I've been developing for J2ME/Java-Me for several years and now I see based on download statistics of my applications, most of downloads (90%) comes from developing countries. So if your target users are not from Western countries - go ahead learn J2ME, otherwise learn Android and/or iPhone.
If I were you, I'd start learning to write apps for Android and iPhone.
Java ME may not be entirely dead, but you'll do much better with these. The potential market for your products is much bigger and keeps getting even bigger, and I bet it would be a lot more fun, too.
I used to develop for j2me . I think it all depends on demand. Right now, i mostly get demands for iphone apps. Android is also making its way but i'd say for every 10 iphone/ipad apps, I get about 2-3 android apps and maybe 1 j2me app. Oh and that's in the uK. It all depends on you. If you want to freelance, I'd say go and learn objective c . It is a very simple language and simpler than JAVA imo.
Nowadays many phones support J2ME.So it is very usefull.J2ME does not need hight cost configurations so many phones support it.Not only phones lot of small devices support J2ME.So J2ME is dying is wrong sentence.J2ME is growing.
If u think only in mobile circles then u get a view that J2ME is dying but if u think in the view of real world then u understand the need of J2ME.Today many devices such as set-top boxes,home applainces,wirless phones,etc uses/support J2ME.
J2ME also had many job oppurtunities.
At present in smart phone market the Android,Blackberry,IPhone are grows larger than J2ME.
But some of the points,libraries,concepts,etc in J2ME are used in Blackberry,Android,etc.
J2ME is very old and it will enable the ground for the modern Smart Phone technology such as Android,Blackberry,etc.
Thanks & Regards,
Sivakumar.J
Depends on which phones you want to target, as you have mentioned smartphones rather than feature phones, I would suggest Android, especially if you are already coming from a Java background, otherwise either iOS (iPhone, iPod Touch and iPad) or Android, as these are far more enjoyable for a developer and have far far better documentation and example open source applications available for them as well as being able to deploy and debug on device relatively painlessly
Don't forget that the expected UI polish of Android and iPhone apps is far higher than MIDlets. This takes a lot of time and effort to create.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Im planning to use Intel atom on a board for an embedded system. The embedded system will be running programs written in C for image processing. Since its an embedded system footprint is obviously a concern. I was thinking about using a modified version of the linux kernel. Any other options??
I've written my own O/S for embedded systems so I'm not too sure. But one project I've been wanting to try is uCLinux. Though that might not be enough for what you want to do. If you have more ressources you might want PuppyLinux or Damn Small Linux. They all should have a C compiler which will suit your need.
Hope this helps!
p.s. since I'm a new user, I can only post one hyperlink, you'll have to google the other two, sorry!
I don't know how much memory you have, but Windows CE might be another choice. Going this route lets you stay with Windows tools (if you like those) There is also a Micro edition of the .NET framework available for use on Windows CE
It depends what services you need form your OS. The smallest footprint will be achieved by using a simple RTOS kernel such as uC/OS-II or FreeRTOS; however support for devices and filesystems etc will be entirely down to you or third-party libraries with associated integration issues. Also the simpler kernels do not utilise the MMU to provide protection between tasks and the kernel - typically everything runs as a single multithreaded application.
Broader and more comprehensive hardware support can be provided by 'heavyweights' such as Linux or Windows Embedded.
A middle ground can probably be achieved with a more fully featured RTOS such eCOS, VxWorks, Neucleus, or QNX Neutrino. QNX is especially strong on MMU support.
"Image processing" in an embedded box almost always means real-time image processing. Your number one concerns are going to be maximizing data throughput and minimizing latency processing overhead.
My personal prejudice, from having done real-time image processing (staring focal plane array FLIR nonuniformity compensation and target tracking) for a living, is that using an Intel x86-ANYTHING for real-time embedded image processing is a horrible mistake.
However, assuming that your employer has crammed that board down your throat, and you aren't willing to quit over their insistence on screwing up, my first recommendation would be QNX, and my second choice would be VxWorks. I might consider uCOS.
Because of the low-overhead, low-latency requirements inherent in moving massive numbers of pixels through a system, I would not consider ANYTHING from Microsoft, and I would put any Linux at a distant third or fourth place, behind QNX, VxWorks, and uCOS.
If you are needing to do real-time image processing, then you will likely want to use a Real-Time Operating System. If that is the route you want to take, I would recommend trying out QNX. I (personally) find that QNX has a nice balance of available features and low overhead. I have not used VxWorks personally, but I have heard some good things about it as well.
If you do not need Real-Time capabilities, then I would suggest starting with a Linux platform. You will have much better luck stripping it down to meet your hardware limitations than you would a Windows OS.
The biggest factor you should consider is not your CPU, but the rest of the hardware on your board. You will want to make sure that whatever OS you choose has drivers available for all of your hardware (unless you are planning on writing your own drivers), and embedded boards can often have uncommon or specialized chipsets that don't yet have open-source drivers available. Driver availability alone might make your decision for you.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I have few years of exp on linux, mainly ubuntu (dual-boot). Now i am shifting to windows, and installing linux in VirtualBox (PUEL). I am looking for a light-weight distro for development machine setup. Thought of using debian-unstable-minimum, and installing build-essentials, openbox(or a little more feature light-WM, ps recommend), ssh-server, ethereal, iptables, nmap(maybe), vim, python3. That is all what i can think of now mainly.
Options I can think of --
Debian-unstable minimum, and then using apt-get to do the rest. Is there also recommended version of ubuntu-lite. I read Ulite is not good, some-others are also not that good.
ArchLinux, reading a great deal about it. Wikipedia says it is mainly a binary-based distro, but everywhere on net/community only talk about its source-based approach. If it is binary I think I can have a quick setup. (For guest-OS-ArchLinux guys in VBox ) is your guest-additions working fine in archLinux.
FreeBSD 8, is it possible for minimum install. And recommended.
Recommendations for other i686 optimized linux, if any, or lets say i386 is also fine, as will only use it for coding.
For system admins -
I would like to know if ArchLinux keeps the potential to penetrate companies for production systems, and replace redhat/debian/bsd in servers for hosting apps/portals.
Addition: Just a thought- is there any distro which helps you to be a better programmer/developer/analyst, in terms of the way things should be done. I dont know if I am over-generalizing it :).
some-others
Checked crunchbang? If you are not particular about needing the power of apt-get, you can also check-out zenWalk or Vector.
My work machine is a 3Ghz 4G Windows 7 box, on which I am running a 1G Debian VM under VirtualBox, it is a bit slower when accessing the HD but it is perfectly usable. I installed off the usual ISO image, and used apt-get to get the rest. Basically, I don't think on even semi-modern hardware you will need to go for a cut-down install to get a good user experience, (unless you particularly want to) to run just one VM. It runs the full GNOME desktop, Emacs, half a dozen terminals, Iceweasel web browser and the OCaml and Haskell compilers just fine. Make sure you install the VirtualBox extensions, they make a big difference to the interactive experience.
FWIW I have never gotten FreeBSD to work properly under VirtualBox, perhaps if you need that you would be better off with VMware, which does.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
Can someone suggest what's the best uses for those libraries today? Is it just GUI, or do they have database, XML, networking, threading, etc support too?
I was reading about them, and considered starting to learning/using one of them.
What is the most common one? What's the difference between them? Why would you choose one over the other?
As you seem to primarily target Linux, then the choice mostly depends on the programming language you want to use.
If you code in C, then obviously go for GTK+
If you code in C++, go for Qt, otherwise you will need Gtkmm (a C++ wrapper over GTK+)
If you code in Python, both GTK+ and Qt have bindings for the language: see PyGtk, PyQt and PySide (the one launched by Nokia themselves).
If you code in Java, Qt is no more a viable option imho as Nokia discontinued Qt Jambi (the Java bindings for Qt).
Also, Qt is more top-notch regarding its scenegraph QGraphicsScene API, its scripting engine built over Javascript Core (the engine powering WebKit), its state machine and animations framework, and the declarative UI.
GTK+ doesn't offer that much although you can use Clutter alongside with it.
If you're specifically looking into DB, XML (GTK+ has a parser for a subset of XML) and threading (GTK+ has GLib) features then Qt will offer all that in QtSql, QtXml and QtConcurrent.
All in all, I would say Qt is a sure choice. But GTK+ is very capable as well.
I'm not sure you will get a crystal clear answer for your question, which explains why some people keep preferring Gnome over KDE or vice-versa. Choose what works best for you.
PS: I you plan to also target Symbian, then go for Qt.
EDIT: Something that is also great with Qt is QtWebView: it brings Chromium into your Qt application to display web content. Others are embedding web content into their application using for instance Awesomium or Berkelium.
I've used GTK+, QT and wxWidgets before. Here's a brief summary:
For my first cross platform UI project I decided to go for wxWidgets mainly because at the time the license wasn't as restrictive as QT's (QT was GPL and only for Linux) and it had platform specific UI (unlike GTK). The project worked out well but there were quite a few glitches getting it to compile and run properly in other platforms - sometimes some events were fired up differently and such. Also GDI in wxWidgets was pretty slow.
Next I used GTK for a different project in python. For this I used the python bindings and everything worked out more or less smoothly. I didn't quite like the fact that the UI didn't look native on Windows and Mac and also when you launch a GTK+ app it always debug outputs loads of CRITICAL warnings which seem fine to ignore. :S
Finally, I did a very simple QT project now that Nokia has acquired it and was brilliant. The best of the three. First off, if you're not an old schooler who prefers VI or Emacs, QtCreator is brilliant. I really love VI and used it for years but I much prefer QtCreator for C++ QT projects. Regarding the library I also liked a lot the documentation and the APIs provided. QT has a concept of slots and signals which introduce new C++ keywords and a preprocessor. Basically, after reading a tutorial you'll get it easily and will start to love it. I'm now doing iPhone dev and it does feel a bit like Cocoa's/Interface Builder's UI paradigm.
Summary: I'd go for QT hands down. The license is pretty good and the SDK and documentation really nice.
I have never used GTK, but from my personal experience using Qt:
It is much more than a simple GUI. It's a whole application framework. I used to think of it as the Java libraries for C++. It provides all you mention -- database, XML, networking and threading, and more. It also provides things such as containers and iterators, and counterparts to a number of boost libraries.
The thing that impressed me most when starting to use Qt was the extremely extensive documentation. You get a program called Qt Assistant, which provides fully indexed and searchable API documentation on your desktop, as well as numerous code examples and tutorials. I found it made a big difference in searching the web each time for API info. Very quick access when you need to remember a method signature.
I am not sure which is most common; that's probably hard to measure accurately. They're certainly both popular. As Gnome is the default desktop of Ubuntu, and Gnome sits on top of GTK, it obviously has widespread usage. Of course, KDE is very popular as well. Nokia is heavily pushing Qt in the mobile space -- their Maemo OS, used on the new N900 for example, is soon to switch to Qt as the default toolkit (currently it is GTK.) I believe Qt will also soon become the default toolkit for Symbian OS.
I have not used Qt Creator, but I have heard many good things about it. It is a C++ IDE with obvious heavy integration with Qt. It also has fake vim emulation which is always nice if you like that kind of thing!
Qt uses qmake for build configuration. I found this much nicer than having to write your own makefiles. I do not know what GTK uses for building.
A couple of things I found a bit offputting with Qt at first was its big uses of preprocessor macros. The signal/slots system provides a nice mechanism for event/message passing in your application, but it does feel a bit like magic that may not be easily portable to another toolkit if you ever want to. Also, the moc (meta-object compiler), while I'm not entirely sure what it does, also feels a bit too much like magic going on behind the scenes.
All in all, though, I would recommend Qt, particularly if you are learning. It has really amazing documentation and a nice IDE, and busy forums. You'll be able to build C++ apps very rapidly with it, particularly with the QML coming in 4.7.
It probably depends on what you want to do. I would recommend Qt, because it's more than GUI, it has nice Python bindings (so does Gtk), and GUI libraries themselves are (subjectively speaking) more pleasant then Gtk.
Gtk is on the other hand more common in linux world, so you can probably get more help on the web. Reason for widespread of Gtk probably has more to do with Gnome and Ubuntu, rather then technical merits, but if you want you software to blend nicely with those two, you'll achieve that more easily with Gtk.
Qt for one sure has solid DB, network, threading support etc... It does a lot more then just cross-platform GUI (and it does most of it quite well).
I'd recommend it over GTK+.
Qt. It's not only object oriented, is "good" object oriented.
It's based on a "subset" of C++ that doesn't rely on the obscurity of C++ (but you are allowed to stick with them, if you fancy masochism ;) ).
It has a strong momentum now that Nokia bought it (actually Nokia did ~2/3 years ago). It's going to be in all Nokia AND Intel mobile devices (smartphones, netbooks, tablets).
It's the backbone of KDE, so it's very mature, but it's designed in a very flexible way, that makes it possible to support TODAY all the latest "cool stuff" that a more-then-just-GUI framework should have.
Go for it.
Just adding QT advantages to other answers.. QT has great documentation, its own IDE & GUI creator and enhances C++ with some new concepts like slots/signals (basically events).
I am not a GTK developer, so I can't compare those to the GTK world :(
It also looks like Nokia is about to use Qt everywhere, like on Maemo
If you want your app to run on iOS, Android, Blackberry, other mobile platforms, Windows, Mac OSX, and Linux, use Qt.
qt-project.org