Ultimate++ 0.98.7 was released. Ultimate++ (U++) is an attempt to provide the optimal Windows/Linux development platform based on C++. By utilizing of new ideas in C++ development, Ultimate++ achieves significant reduction of source code complexity for most applications when compared to other development platforms. To get a clue how development using U++ looks like, see this example.
Please take off the ending full stop. It messes up the link.
The correct one is:
http://upp.sourceforge.net/www$quick$en-us.html
without the dot.
While the comparisons of Ultimate++ vs. other C++ libs are not in-depth, they do show a marked decrease in lines of code using Ultimate++ vs. the other libs, including Qt.
It would be interesting to see a comparison to JUCE:
http://www.rawmaterialsoftware.com/juce/
The other Ultimate++ libs also show a general low line count.
Decreasing the lines of code to do something is a huge step forward. And an impressive accomplishment in the C++ world.
I hope Ultimate++ keeps evolving and fills in the missing functionality it is missing. Bravo to the developers on a job well done for what they’ve accomplished so far.
How does Ultimate++ reduce source code complexity?
Is it a library?
Is it an IDE?
Is it some other sort of tool?
If you are writing applications that do not use a GUI does it help?
> Is it a library?
Yes.
> Is it an IDE?
Yes.
> If you are writing applications that do not use a GUI does it help?
Yes.
Can you elaborate?
I can:
> Is it a library?
Yes. It is fine-grained set of libraries for GUI, Drawing, DB stuff and STL-like containers.
> Is it an IDE?
Yes. IDE is actually pretty cool and contains GUI and icon designer. Multiple projects (called “packages”) and it’s dependencies are also supported. As compiler you can use gcc (mingw on win) or MS (Free as in beer Toolkit). Integrated debugger support both toolchains. You can also easily switch among toolchains (“build methods”).
> If you are writing applications that do not use a GUI does it help?
Yes, you can write console app from scratch and use upp containers or integrated source documentation tool “topic++”. Many will appreciate fact that IDE has *MUCH* faster (own) linker than any other free tool I saw.
there’s no comparison with the new Qt4, which is amazing.
I can make the Qt example a lot shorter. I guess it’s a bit “expanded” because it is used as an example and to make things clear.
But this looks very nice.
Or it has its own?
it uses own widgets on both linux and windows.
Seems to be a nice environment for educational purposes, since it’s an “all-in-one” package but at the same time not overloaded with features that could be distracting.
After all, most toolkits allow declarative UI stuff these days, or at least tools exist to churn out the code for it. There’s Glade with GTK+, NetBeans IDE for Java Swing, etc.
Apart from that, this looks like simply a library designed for code efficiency, which I’d pass up for graceful design any day. I tend to prefer gtkmm, which could well be the opposite of this (although it’s not always that wordy.) Anyway, it depends on what you’re trying to do of course, but you can be fairly sure that gtkmm won’t get harder to deal with just because you go beyond what it’s designers envisaged when they created the API.)
“Ultimate++” I hope they are trying to be funny otherwise it’s a pathological case of megalomania.
And even if they are trying to be funny: serious software shouldn’t use silly names IMO.
“serious software shouldn’t use silly names”
Niether should frisbie! Damnit people like to abuse perfectly good words! But if anyone messes with Skittlebrau… *makes menacing gestures* ;^)
And you think that know-it-alls complain when one recommends Objective-C. LOL.
underwhelming. Looking at the code it wasn’t all that much more readable.
Not to mention, “pure” C++ is no more a feature than impure, all that matters is usability, from a programmers perspective of course.
I like U++. Shorter code is gooood. Thumbs up.
this site is for Gnome so GTFO!!!!
Looking at the code comparisons, the Java comparison is completely unfair and taken out of context… It would be much easier to provide a Java example that does the exact same thing, functionally, in a fraction of the size – Plus, as people have mentioned, there are various apps that make UI layout ‘automatic’.
I can’t comment on the others, because I’ve never used Qt and its been a long time since I used WxWidgets – Can anyone else provide some insight as to whether the other examples are fair or not?
I guess that U++ openly admits that this is not the best example to be compared in introduction. It should serve just to get the first hint. OTOH, U++ version is quite educational as well, there are no tricks used to reduce size of sources.
Comparisons like that can never be absolutely fair. But they can give you a first look and also can serve as introduction to U++ for those familiar with platforms used for comparison.
To really evaluate abilities of U++, you have dozens of examples and sources available to do that. Another good way is to study TheIDE sources – you get them with any U++ release.
I don’t think it’s about tricks in the code. And while, perhaps, “functionality”-wise both codes offer pretty the same, the Java code is really designed as a tutorial to Java/OO/Swing concepts — as you can see that it introduces things like Unit (to show a class concept) or DecimalField (to show how to create a customized widget), and that’s why it has many (“unnecessary”) lines.
I’m not going to say that Java/Swing is better than Ultimate++ (I myself never tried Ultimate++, and I admit that Java/Swing is many be too bloated for small apps <– in which those nice layers/abstractions and fine-grained modularity are just too overkilled/distracted). But just to point out that the example is not just “not the best thing” .. but it’s actually a bad example.
After checking the examples, this system seems to be OK. But Borland C++ Builder (BCB) is maybe better:
– uses a huge and well designed component library
– uses a feature-rich and visually graphical designer for forms. The form data is kept in resource, and not in code like here. Oh man, why do you use _code_ for this?
– Number of BCB’s lines compared to U++ may be even smaller. It is possible to write a rich GUI application with 5-10 lines typed by hand, and the whole code may be under 50 lines /e.g. displaying content of dependent database tables in a grid, with recordset navigators/
BUT Borland C++ Builder has its own shortcomings:
– $$$, not open source
– buggy /but usable/ IDE
– slow release cycles from Borland
– not really multi-platform
– uses non-standard c++ language features e.g. for class member callbacks
So U++ or other stuff?
I am waiting for a really elegant open-sourced c++ system. This language is incredibly powerful – but it usually requires a good programmer to safely and nicely use it.
> uses a feature-rich and visually graphical designer for forms. The form data is kept in resource, and not in code like here. Oh man, why do you use _code_ for this?
U++ does not ‘use code for forms’. It has ‘feature-rich and visually graphical designer’. Only difference is that it is not using .rc files, but .lay files that are included into C++ (as opposed to .rc being separately compiled and included by linker). This way all widgets of visually designed forms are accessible as C++ member variables – that is one of things that makes U++ development easy.
Out of curiosity. Is the U++ IDE written with U++? I did not find any info.
Sure it is. You can recompile TheIDE with a couple of mouse clicks. Download, install, start TheIDE, choose ‘uppsrc’ assembly, choose ‘ide’ package and ‘OK’. Now you should have all ‘theide’ sources loaded. To compile it and run, hit F5.
Their QT example is a touch unfair, for the following:
– They include .h files for QT but not for Ultimate++ (are these required for Ultimate++?)
– Regardless, QT designer will write the .h files for you
– Most of the QT code quoted is built for you by QT Designer, such as the majority of the window, menu and widget setup and basic connections.
– Signals and Slots, where present can be readily set up using QT Designer, too, so code length and complexity is not an issue for programmers.
– A fair amount of the QT code is basic prototypes revealed so that the programmer can modify them later e.g.
void ABMainWindow::closeWindow()
{
close();
}
It’s just a basic prototype, but makes it a lot easier to find and add if I want to add some custom shutdown code.
In other words, it’s much of a muchness between Ultimate++ and QT, in general.
***IMPORTANT***
The value of a development platform and toolkit is not in the number of lines something takes to do. If that were the case, we’d all be using Perl for everything (don’t get me wrong, I love Perl to bits). It’s a question of intuitiveness and ability in the type of programming a person wants to undertake.
Personally, I find that using QT, the strength of it is not in the IDE or clarity of code, but in:
– Intuitiveness of class definitions
– Completeness of functionality
– Clear naming principles and appropriate class objectives
The brilliance of QT is that it lets me do everything that I want to, in a way that I expect to be able to do it, with classes acting as I think they should, and named appropriately so that I can guess “A class to do this ought to be called … and it ought to have a method called … which should act in exactly this way …”.
That’s what QT is good for, and appreciation of that only really comes through using it. Java, for example, is functionally complete, but the JFC is not intuitive in that way. The test for Ultimate++ is to try it, use it for a few weeks and decide whether it is working as yout *expect* it to, and speeding up your work and the quality of your work.
There’s nothing worse than finding that the functionality that you expect in one class is strewn across three classes with odd input/output data types, so you have to cobble them together, do all sorts of casts to convert the data types and then debug when they don’t work as expected, or the casting rejects some of your input set.
talking for myself, problem with QT is that doesn’t provide multi-platform IDE (so I have to setup one for each platform and synchronize projects somehow) and licence.
Which is why you’ll love Qt4. there is a Free License on Windows now as well.
I’m not sure why you need a different project however for each. it’s quite multi-platform ready. Can even use the same License. it’s just the license for the Qt Libraries are different between windows and the rest.
A project that I use to help out with had 1 project and supported everything that Qt supported. Mac, Linux, Unix, and Windows. For our license I believe we used GPL. Only downside was that whoever did the windows build had to have bought the Qt Developers stuff. If i’m not mistaken tho I think he used the ones included on a tutorial cd
> – They include .h files for QT but not for Ultimate++ (are these required for Ultimate++?)
Actually, U++ version could / should be split into .h / .cpp. Anyway, all necessary includes are performed.
> – Regardless, QT designer will write the .h files for you
> – Most of the QT code quoted is built for you by QT Designer, such as the majority of the window, menu and widget setup and basic connections.
> – Signals and Slots, where present can be readily set up using QT Designer, too, so code length and complexity is not an issue for programmers.
Well, perhaps you have not seen the bottom of page, but we tried to carefully separate that code of example we expected to be generated by QT designer. Might not be perfect, but we tried.
> – A fair amount of the QT code is basic prototypes revealed so that the programmer can modify them later e.g.
Hm, this is something to consider, but there are just 3 methods like that
ABMainWindow::~ABMainWindow
ABMainWindow::fileNew
ABMainWindow::closeWindow (but there is equivalent Quit in U++ version)
Note also that U++ version actually implements print, something thas was “omitted” in Qt version.
All of that said, those comparisons can not and are not 100% fair. You are also absolutely right claiming that number of lines does not matter too much.
I believe that framework virtues that you seem to praise are close to “design goals” of U++. When we speak about ‘code complexity’, we are NOT speaking about total number of lines. That is just a nice secondary effect.
>problem with QT is that doesn’t provide multi-platform IDE
———–
I agree. But KDevelop is on it’s way to windows, I understand. And frankly, I’d rather use QT4 without an IDE than most toolkits with one.
As for Borland CppBuilder, which someone mentioned, the upgrade cycle is not slow, it’s almost non-existant since the inept corporate management there declared it dead, and then changed their mind. QT is much more alive and continually evolving in a good direction.
Looks verypromising, Im going to try it right away.
Btw, I didn’t see any Linux screenshots.
I dont realy see it having much of a chance against QT4. The only thing lacking in qt4 is a proper IDE for windows that can be used with the open source version. And dont say dev-c++ cause its crap.
Even if ultimate++ has a better GUI library, QT has so much more in it, that its the obvious choise. Threads, serialisation, sockets, sql, etc.
As to kdevelop being ported to windows, dont expect that to happen within a year…
> Threads, serialisation, sockets, sql, etc.
All present.
I dont see anything in the documentation about threads or sockets.
Documentation of 0.98.7 is far incomplete (actually, main drawback). Anyway, you can always find most of info in sources, e.g.:
http://cvs.sourceforge.net/viewcvs.py/upp/uppsrc/Web/socket.h?view=…
gtkmm, ultimate++, juce, vcf, fltk, wxWidgets, fox …
Maybe if all these half assed open source C++ toolkits worked together they could produce something to challenge Qt, but it ain’t looking likely.
But your Qt is a simple stupid toy if you compared it to .NET and Visual Studio. If you want to create a big application with many data-driven forms, repots, etc the Qt is not challange to VS (but the Borland C++ Builder is also better solution IMHO). And the .NET is a full toolkit: you can create both web or rich client applications, multi-tier applications, etc. Qt is a simple widget set with some database access and printing support. It is very nice, but not a complex solution (no IDE/RAD, no web client support, etc). And IMHO too expensive if you compared the price and the productivity to other tools. If you want a C++ application with minimal GUI the Qt can be a good solution (but IMHO the wxWidgets also not a bad thing for this purpose), but if you want to create a bigger, form-intensive application the Visual Studio (with C#) or the Borland C++ Builder (or Delphi), or any Java developer tool (Eclipse, Oracle JDeveloper, Borland JBuilder, Netbeans) far more productive and cheaper (except if you want to create GPL-ed applications, but the developing of big GPL business application is the fastest way to perishing by hunger ;-)).
Calling Qt a “simple stupid toy” is the single dumbest thing anyone has posted about it ever. You are either a troll or an idiot. You wildly underestimate Qt capabilities. Not surprising, coming from someone who compares it to wxWidgets.
Thats a shame. You cant expect people to use a platform without documentation. I came across ultimate++ quite a few times but never gave it any serius thought because I thought it lacked to many things.
Thats a shame. You cant expect people to use a platform without documentation. <br/>
I think you people are too much focused on upp libs. Multiplatform/multi-toolchain IDE is really cool thing. Maybe it would be helpful if TheIDE supported other frameworks too (Qt, GTK+ being 2 most important). It would be enough to create project templates and integrate both GUI designers. I think such “swiss-knife-IDE” would be really “ultimate” 🙂
> Maybe it would be helpful if TheIDE supported other frameworks too (Qt, GTK+ being 2 most important).
> It would be enough to create project templates and integrate both GUI designers.
We have nothing against that other than time and knowledge constraints. If you are willing to constribute your knowledge and/or effort here, you are welcome.
Well, for anyone interested, here is my list of the current FREE C++ cross-platform choices (Qt is commercial, no matter how you slice it, so it is ruled out).
GCC/wxWidgets – Can be used to create apps for Windows/Mac/Linux/Unix.
GCC/Ultimate++ – Can be used to create apps for Windows/Linux/Unix.
GCC/SDL – Can be used to create apps for Windows/Mac/Linux/Unix.
GCC/XUL/GRE – Can be used to create apps Windows/Mac/Linux/Unix.
GCC/YAAF – Can be used to create apps for Windows/Mac/Linux/Unix.
GCC/JUCE – Can be used to create apps for Windows/Mac/Linux.
Qt is as commercial as the kernel is. GPL is GPL, no matter how you slice it!
Oh, here are two excellent FREE C++ IDEs:
Dev-C++
http://www.bloodshed.net/devcpp.html
Code::Blocks
http://www.codeblocks.org/
Durng the past few weeks I’ve been looking for a good C++ GUI toolkit. After a lot of research I’ve finally narrowed my search to two: Ultimate++ and VCF.
Unfortunately, both projects seem to be mostly clueless about each other efforts. A comparison of these two toolkits would be greatly appreciated.
These two are the only ones that can play in the same league as Qt.
My ideal toolkit:
Rich, well designed, API
Uses modern C++
BSD/MIT license
Unix/X11 and Windows
Well documented
So far Ultimate++ looks very good. There are, however, some things I don’t like about it:
Forces you to use its own IDE instead of my favorite editor/IDE. (Note VCF doesn’t force you to use any particular IDE but has optional Visual Studio integration). I’d love to use it from vi.
U++ programs are very slow to compile and build. The resulting binaries are huge.
No documentation, and source code has no comments at all!
Small set of widgets and classes.
> U++ programs are very slow to compile and build. The resulting binaries are huge.
Well, there was bug in pre 0.98.7 release that caused linux builds to slow down. Generally, U++ builds are faster than anything else thanks to blitz-build technology, but first builds e.g. after download might be slower – U++ does not ship with prebuild libraries, so that first build has to build everything.
As for footprint it is true that minimal application is about 500KB on win32 and 1MB on linux – but then it tends to grow very slowly. TheIDE Win32 binary has 4.5MB and its memory footprint is about 8MB. Compare it with KDevelop….
> Small set of widgets and classes.
Well, the basic set (CtrlLib) contains about 100 different widgets. That is just a small step from “being bloated”….
Well, there was bug in pre 0.98.7 release that caused linux builds to slow down.
I’ll try the new release. But I tried it under Windows.
Generally, U++ builds are faster than anything else thanks to blitz-build technology, but first builds e.g. after download might be slower – U++ does not ship with prebuild libraries, so that first build has to build everything.
They were not fast in my experience. I’ll try again. Any common misconfiguration I should be aware of?
Any reason not to include prebuilt libraries?
Well, the basic set (CtrlLib) contains about 100 different widgets.
Those accesible from the all menu in the GUI are only 26. I can mention at least a dozen commonly used GUI elements that do not appear in the demos.
Also:
How well does it play with alternative (read better than make) build systems. scons? jam?
> I’ll try the new release. But I tried it under Windows.
> They were not fast in my experience. I’ll try again. Any common misconfiguration I should be aware of?
Well, I think that subscribing U++ mailing list is the best option here.
> Any reason not to include prebuilt libraries?
Because that is not how U++ works. You are actually at any time working with complete sources of U++ + your app. Existence of .lib (.a, .so) files is just an implementation detail of build process.
> Those accesible from the all menu in the GUI are only 26.
Only most often used are there now. Also, some often used widgets, like Splitter, are not typically used in layouts (that is why it is missign as well).
That said, I do not say that there are missing widgets. OTOH, implementation of widgets is usually quite easy (one of primary U++ design goals). E.g. Button implementation has about 40 lines….
> How well does it play with alternative (read better than make) build systems. scons? jam?
You are on your own. Anyway, the original purpose of TheIDE is to be THE alternative build / project management system. Try to learn something about packages, dependencies, building and blitz, you might (or might not…) like it.
You are actually at any time working with complete sources of U++ + your app. Existence of .lib (.a, .so) files is just an implementation detail of build process.
I’d like to link against a dinamic library without having to rebuild the whole U++ every time. Is there a upp.dll or something?
Only most often used are there now.
This fact should be documented somewhere.
I don’t like the way U++ ties you to a particular development environment. While TheIDE seems ok, having more choice is good. In particular, I want to be able to use my editor and my build system (vi and scons). But this doesn’t seem to be very easy. I took a look at the generated Makefile, it is 300KB! Any chance U++ developers dump the aging make in favor of a more modern alternative? It seems to me that you are pushing make to its limits. I recomend jam or scons.
There’s another thing that is bugging me: This Esc language that comes with the library. I don’t think we need yet another scripting language. A more sensible alternative would be to provide the required hooks to embed a language and let the people do it. There are more than enought python/tcl/perl/javascript/etc zealots out there who would do this even if they don’t plan to use U++.
Otherwise this seems like a very good library. I’m eager to give it a try.
> I’d like to link against a dinamic library without having to rebuild the whole U++ every time.
You do not rebuild every time. Just first time….
TheIDE debug rebuild takes 50s on my machine using VC++ and 3 minutes with GCC. That is a good tradeoff IMHO.
> Is there a upp.dll or something?
Well, you can instruct TheIDE to use .dll/.so instead of .lib/.a, but I guess that it is not what you are asking for
> I don’t like the way U++ ties you to a particular development environment.
Then do not use it. In the end, it is regular C++ without any language extensions (over using macros). Anyway at the moment we have better things to do than providing libraries.
> I took a look at the generated Makefile, it is 300KB! Any chance U++ developers dump the aging make in favor of a more modern alternative?
TheIDE is not using make. It has its own system (that means, calls compiler directly, checks all header dependencies etc….) Makefile generator is there to provide a compatibility, it is usually used only to build TheIDE on platform where it does not exist yet. Once you have TheIDE, you do not need makefiles anymore.
> This Esc language that comes with the library.
Ehm, I think I got you confused here a little bit. Esc is not very important, that is just scripting language of some parts of TheIDE (e.g. those widgets in layout designer are painted using Esc). Well, you can use it in your apps, we do because Esc is specifically designed to have trivial interfacing with C++/U++.
Perhaps the real confusion here is that Esc is not scripting language with the ability to use U++ frameword (like pyGtk etc). It is more like VBA or QT scripting language, intended to be possibly used BY U++ application. One advantage is that interpreter is rather small (about 2200 lines) so it easily fits with any application. Other advantage is that binding it with your app is very easy. And it is quite complete language.
Calling Qt a “simple stupid toy” is the single dumbest thing anyone has posted about it ever. You are either a troll or an idiot. You wildly underestimate Qt capabilities. Not surprising, coming from someone who compares it to wxWidgets.
And you are:
A) Adoctrinated for Qt
B) Get pay for Trolltech
C) Hard core KDE user
D) You have no life.
E) All above.
First, this is a thread about Ultimate++, not Qt.
Second, I’m neither a KDE user, nor paid by Trolltech, nor adoctrinated for Qt, and I do have a life.
The difference between you and me is that I happen to be a C++ expert, and I recognize a good toolkit when I see it. Had you read the comment I made earlier (U++ vs VCF), you’ll realize I’m not a Qt entusiast.
¿How many Qt apps have YOU developed? I’ve been paid big money to write commercial software with it. It is a damn impresive toolkit. Far ahead of the competition. Only an idiot will call it a “simple stupid toy”.
But it is costly.
Now I’m looking for another GUI toolkit. Ultimate++ and VCF are the only worthy candidates.
VCF is more promising than Qt 4, too bad, it’s development is going slowly, as few people have heard of it. Anyway, it seems like a great choice for Windows developers. http://vcf-online.org/
Ultimate++ is interesting. Too small to threat Qt, but has an original design that may, or may not, give great results. Pretty innovative in many ways. I have to investigate it further.
I’ll start development with either VCF of U++ (not decided yet) next week. Meanwhile I’m evaluating them.
> The difference between you and me is that I happen to
> be a C++ expert, and I recognize a good toolkit when I
> see it. Had you read the comment I made earlier (U++
> vs VCF), you’ll realize I’m not a Qt entusiast.
Out of curiosity, why not wxWidgets?
Out of curiosity, why not wxWidgets?
Prehistoric API, that’s bad enough.
Low productivity compared to more modern toolkits, roughly similar to MFC.
Verbose.
Heavyweight, adds another layer of complexity and bloat to your code.
Not thread safe.
Slow.
Ugly.
Obnoxious license (LGPL).
I’ve been using wxWidgets för some projects and I find it easy and quick to use. wxglade a layout an throw it into VC, do the callbacks and your’re “done”.
Threadsafety I usually solve with guards, if that would be a problem => ~1 row extra per function.
Slow?
Ugly? Whatever your native widgets look like.
What is it you’re missing?
I’m not trying to argue with you — I’m really curious. Usually I’m not doing GUI:s and wxw got me going quite easily.
Thanks,
Marcus
wxglade a layout an throw it into VC, do the callbacks and your’re “done”
This works only if your app uses nothing more than the common controls. Any non trivial application requires subclassing widgets, implementing new funtionality, etc. That’s done by hand, no gui builder can help you. Then you face all of wxWidgets API ugliness.
Doing that is a nightmare in wxWidgets. Why do you think it has never really caught? wxWidgets have been around for ages (first version was for Windows 3.1). Why do you think many others have created other toolkits? Its API is ugly and it is very difficult to extend (due to the way it is designed, as a layer on top of other toolkits). To add a new widget to wxWidgets I need to be a WIN32/MFC programmer, a gtk+ programmer and a Cocoa programmer (which, incidentally, means I should know C++, C, and Objective-C) and then maintain 3 codebases. Not nice.
With any modern toolkit those hacks you suggest to reach threadsafety are not required. This is an example of what I said before: wxWidgets is a low productivity environment. You need to implement every time things that should be a part of the library.
That’s also the reason there are not third party widgets to wxWidgets. Compare with what is available for Java/Swing, MFC or even Qt.
WxWidgets is slower than MFC or gtkmm (which are comparable libraries). U++ or Qt are not, because they are not wrappers, they are implemented using a low level API. Granted, this is not such a big issue these days of multi-Ghz machimes and GBs of RAM, but it may still be noticeable in a complex interface.
Incidentally, this also means I can create a new widget with U++, Qt or Swing with ease. I don’t need to know any other API besides what each one of them provides. Compare this with wxWidgets or SWT.
The ugly comment was about the design of the library, not its look and feel. Although its look and feel isn’t entirely native, as it needs to play with the geometry of widgets to achieve its cross-plattform compatibility goal.
The license does not allow those of us who can contribute to such a library to reuse the code. If you are only interested in using the library that is not an issue, but if you are going to examine its internals, to study the code, and to contribute to the library it would be nice that you could copy and paste any snippet of code you found there for your own projects. The LGPL (with or without static linking extensions) thwarths reusability. If I’m going to put the effort that it takes to familiarize myself with the internals of a library I’d rather work with BSD-licensed code that I can reuse without problems.
Thanks for the reply, rover. You have some valid points about wxWidgets (re: very old, MFC-like design, hard to extend). That said, there are two things I’d like to point out:
1: It’s not BSD, but it’s basically MPL (read the exception!); what’s wrong with that? If you change the library ITSELF you have to publish the changes, but if you add another layer on top, you’re free to link wx to it with absolutely no strings attached; license it with whatever license you want. Heck, if you want to make a proprietary extention, all you have to do is publish the hooks, and the extension (which could be a custom control) is yours to sell and restrict as you please.
To be fair, you might not be able to copy and paste snippets from quasi-MPL’ed wx to your program without MPL’ing your program (an issue I hadn’t considered), but for small snippits, it shouldn’t be a problem to just rewrite that small section. Either that or make it an island upon itself and staticly link it to your program, hence only having to reveal what you cut and paste in the first place.
2. One man’s minus is another man’s plus. One of the main reasons I’m using wxWidgets on my small/medium-ish program (15000 lines so far, and it’s still in beta) is precisely because it uses native widgets on each platform. I’ll take slightly slower native widgets than faster non-native widgets any day. The only toolkit I’ve seen that looks good non-native is Qt (and of course, it *is* native on KDE
), and that has tons more licensing problems for an independent developer like me than wxWidgets.
It really does do its best to look good on each platform. Make an “Fire/Exit” menu item, and wx *automatically* moves it to the correct place on OS X. Ditto with “Help/About”; heck, it deleted the “Help” top-level menu when it saw it was empty after moving “About” to its OS X location. And it subtly alters spacing and such on each platform to make it look more native. My only complaint so far is how it handles tabs and sliders.
(Not to start any flame wars or anything, but albeit a couple of years ago, the toolkit that looked the absolute worst to me was FLTK
, and it drew its own widgets. One of the prime reasons I chose wxWidgets this time around was the memory of how bad non-native can look!)
I won’t discuss licenses anymore, at it leads nowhere. I’ll just state that BSD is much more developer friendly that LGPL no matter how many exceptions you add to it as I don’t need to use “creative copying of code” (in the sense of “creative accounting”) to reuse some little piece of code, as you suggest. And no “it shouldn’t be a problem to just rewrite that small section.” is not good enought, I want to reuse code, not reimplement stuff that is already implemented, debugged and tested.
…is precisely because it uses native widgets on each platform. I’ll take slightly slower native widgets than faster non-native widgets any day.
But this is also the source of wxWidgets hard-to-extend problem. I can live with slower widgets, I cannot live with such horrid inflexibility when it comes to improving the toolkit. From my point of view easy to modify and extend is preferable to native looks any day.
The only toolkit I’ve seen that looks good non-native is Qt
Ultimate++ looks pretty good to me. And Swing has also made huge improvements in this area.
wxWidgets is written in 1990’s C++. Heck, look what they put in their features page: “Even the 16-bit versions of Visual C++ and Borland C++ can be used. On Windows, makefiles are provided, with project files for VC++ 5 and above.”
There have been huge improvements in C++ and in the colective knowledge about GUIs (just compare the looks of any Windows 95 program with a recent app) that justify new toolkits.
MFC, wxWidgets, OWL and gtkmm belong (in design) to the 1990’s. They were a great improvement over the previous design generation of Motif, gtk+, etc. but the gap between them and modern GUI toolkits (read Qt, U++, VCF, Swing, .NET, Aqua) is as big as the difference between them and Motif/gtk. Today you can be 2-3 times more productive than before thanks to better designs and the features of modern C++.
Check the source of, for example, Ultimate++. It uses lots of modern features, templates, exceptions, etc. This allow to write a much more elegant API without sacrificing anything. Check the U++ vs wxWidgets example, the U++ version is about one third of the code, and IMHO more readable.
Unfortunately, the only production quality contemporary toolkit for C++ is Qt. That’s the reason it commands such a high price.
With U++ and VCF this is changing. But they are still pre-1.0 beta quality.
I think there are two main reasons to choose a GUI toolkit: 1. Niceness of the API (which leads to productivity) and 2. Flexibility of the toolkit.
wxWidgets API is not nice, it never was, and as of 2005 it feels dated.
wxWidgets is not flexible enought (i.e. improving, modifying, debugging and extending the toolkit is hard)
Qt (especially Qt 4), Ultimate++ and VCF have nice contemporary APIs.
Qt (especially Qt 4), Ultimate++ and VCF are flexible, modifying them, adding a widget, extending them, etc. is easy.
I’m not saying that MFC, gtkmm or wxWidgets totally suck and that nobody can get work done with them. They can be used, and they have been used for a long time. But there are better alternatives now, alternatives that provide a more pleasant programming experience, higher productivity and that avoid the pitfalls of previous generation toolkits.
As of 2005 I think it is a mistake to implement a GUI using any previous generation toolkit, except for licensing/price reasons or dependency with legacy code.
Where it says Aqua should be Cocoa… sorry, I’m mostly Mac-illiterate. So consider anything I said about the Mac as hearsay.
Out of curiosity, why not wxWidgets?
(…) Obnoxious license (LGPL).
Nah, LGPL + special exception:
http://www.wxwidgets.org/newlicen.htm
What new advances are these ? Went to the website and saw
a “reduction in code”, but I don’t get what new advances in C++ coding there is ? Somebody please explain, because it just looks like another widget/ide toolkit to me, having no “<italics>long-term<italices>” advantages over the ones already available….
i wish there was an article to this post … having the project page there leaves us peacing it together and coming back with wildly idffering impressions of what it
intends to be…. my 2.penece … 🙂
U++ is built on top of it’s own libs.
The ability to compile itself clearly shows the maturity of the tool.
U++ is interesting but the “Days” tutorial has been compiled to a 995k executable (in Release mode) with ms compiler. This is dissapointing. Also it lacks an autocompletion and refactoring tools. Eclipse rule!
995k – yes, it’s quite a big size, but remeber this is the only file you need to run it!
Autocompletion is in plan and will be added ASAP.
I mean, even QT runs on the Mac, why not U++. This way cannot consider U++ multi-plattform without support for the Mac.
U++ will be ported to MAC platform as well
undogs wrote”U++ will be ported to MAC platform as well”
Well this sounds good. I hope it does not take forever.