Slashdot Mirror
Cross-Platform GUI Toolkits (Again)?
Futurepower(R) queries: "It has been 2 1/2 years since the previous Ask
Slashdot about GUI Toolkits. There were many helpful comments then, such
as this
one. Since then, Slashdot has discussed wxWindows vs. MFC and considered the book, Creating Applications with Mozilla. The best comparison table is
apparently still the GUI Toolkit,
Framework Page. Which is the best cross-platform GUI toolkit that provides
native look and feel? Which is the best overall? What IDEs and other tools do
you use? What are the problems?" Slashdot also had a match-up between GTK+ and Qt, but some of you might have missed that one. How have recent changes in this ballpark changed your feelings on the issue?
Ha! Just kidding. Put the torches out, please.
The Fast Lightning Tool Kit is very nice. I've used it on Sun OS, Linux and Windows. Compiles between platforms without much change to the source at all...mostly its the system calls that needs to be changed, nothing related to the GUI.
Actually, it's been much less than 2 1/2 months since this question was asked.
Well, until Microsoft took it over, the Web was a very good multi-platform development environment....
From the article: The best comparison table is apparently still the GUI Toolkit, Framework Page. Which is the best cross-platform GUI toolkit that provides native look and feel? Which is the best overall? What IDEs and other tools do you use? What are the problems?
GUI toolkits and IDEs could be exploited if widely used.
Ken Thompson who we all know and love from UNIX lore has written Reflections on Trusting Trust which describes just this problem.
Imagine that you insert a backdoor into a compiler, so that everything the compiler compiles is trojaned. If the compiler detects that it is recompiling itself, it quietly reinserts the trojan code. The actual source code to the trojan might be wiped out, but as long as you are running infected binaries, it will keep popping up again and again.
From the paper: "First we compile the modified source with the normal C compiler to produce a bugged binary. We install this binary as the official C. We can now remove the bugs from the source of the compiler and the new binary will reinsert the bugs whenever it is compiled. Of course, the login command will remain bugged with no trace in source anywhere."
A very interesting read.
Seriously, the question wasn't limited to C/C++, which brings lots of other baggage besides teh GUI.
HTML 2.0 is still the best cross-platform GUI out there.
Kinda ironic that I'm seeing a .NET ad on this page
Skiers and Riders -- http://www.snowjournal.com
I personally think that Cocoa and GNUstep deserve to be mentioned among the best-designed toolkits around. Both follow the OpenStep guidelines rather closely, and the OpenStep guidelines are very well-documented on Apple's site.
GNUstep is also quite portable -- I have used it on three or four platforms, and have no doubt that others work great. My only complaint about GNUstep is its idiosyncratic build system, but I believe that's a left-over from NeXTSTEP, the precursor to OpenStep.
If you're interested in learning more about Cocoa and other OpenStep-compliant toolkits, check Apple's developer site and the Hillegass book, published by AW.
unixkb.com -- articles on practical Unix issues.
You forgot to mention that BSD is dying.
Swing is functional and cross-platform, free-beer, and widely understood.
I have discovered a wonderful
The SWT engine in Eclipse seems pretty cool - rather than using Java's standard slow SWING engine you get a toolkit that passes through to the native UI, which results in a much more responsive application.
OK - so this is a dupe, posted last month, we all know this by now. Now, if this happened at the BBC website, or the NY Times website (and this happens from time to time) - what would happen? Answer: they pull the story. That's right, yank it off the page.
/. editors do that? I have no idea. Maybe b/c they're all fg8s? Who knows.
Why don't
Nice and portable and reasonably consistent feel and appearance.
And for those who like to use it in a scripting environment, use it as is. Use it with Perl, C, C++, etc...
I stick to walls...
If your looking to Java for cross-platform development and cli is not your thing, Eclipse is a nice IDE that works nicely on windows and linux. Its also open source.
I'm not the original poster, but farking?
Better not let teacher catch you reading slashdot, son.
--
the strongest word is still the word "free"
I keep hearing about how .NET speeds up development work--how exactly? (Sorry, I'm a perl/c/db/vi programmer and haven't touched .NET's GUI toolkit, yet).
-- @rjamestaylor on Ello
If you're talking about true cross-platform compatibility, combined with ease of development and deployment, then Tcl can't be beat. It's always been good, but recent developments, such as the Starkitpackaging and runtime system, make it a hands-down winner.
You is brain dead!
This might be a little too obvious, but how about Java - a cross-platform language, API and GUI framework.
And, if the speed of Swing bothers you, you can try IBM's SWT toolkit. I'm very impressed with it so far.
Jason.
I'm sure Microsoft will provide GUI toolkits for the X-Box themselves. They don't need a bunch of geeks working on some kind of open source solution. Everybody knows that open source is just a fad. Microsoft said so.
;-)
Irene KHAAAAAAN!
numbnuts.
The biggest difficulty in creating cross platform toolkits is resolving the different paradigms inherent in each platform.
X is based on a networking concept where anyone can access anyone else's screen as a network resource. This leads to multi-threading issues as it is possible for two people to use the same desktop, even same application, simultaneously. As a result, toolkits that have their origins in that environment like GTK and wxwindows have strong multi-threading support not to mention strong networking support.
OTOH, Windows was built around a single user concept, which from a networking perspective is more secure because a person's desktop isn't a networking resource (but that's neither here nor there). This results in the base windowing subsystem's reliance on processes as the fundamental object of execution (as opposed to threads). So toolkits built upon Windows (MFC, OWL, QT) are able to harness Windows's windowing support in a way that more easily and effectively takes advantage of the features of the subsystem.
Attempting to port one toolkit from its home platform to a foreign platform leads to problems of "look and feel". AWT and Swing are prime examples of toolkits that look strange whereever they are used. Likewise, wxwindows feels funny running on Windows and GTK looks funny. Hell, MFC doesn't even run on X.
What this all boils down to is that cross-platform development is always going to have limitations because the roots of each toolkit will decide its look and feel as opposed to the platform itself deciding the look and feel according to the platform's native interface.
I have been pwned because my
MFC is ugly, and is even more apparent when compared to Qt and GTK.
;)
Although a 'net' by definition is full of holes, VB.NET is a good way to do things under Windows (it isn't any faster/slower than C#).
There's always Java...
It is hard to admit it, but when the mono team gets windows forms working correctly, C# and .NET are going to pick up a great deal of momentum, specially in the cross-platform GUI development area.
Okay, I'll bring it up now: IBM's SWT is great. I've been using Eclipse lately under gnome2 and it's wonderful. Nice native look and feel (great anti-aliased fonts) and very responsive.
If you don't know, Standard Widget Toolkit (SWT) is a java GUI framework that uses JNI to call the native OS windowing API. It's an excellent example of how java can successfully be used for client desktop applications. IBM developed it for the open source Eclipse IDE.
Who said Freedom was Fair?
freebees getting better: Eclipse is sweet. Ant is insectuous. xDoclet cuts the learning curve
pay: TogetherSoft over XDE (for now)
IBM WSAD over TogetherSoft, and IBM WSAD over TogetherSoft.
Built-in Object/Relational Mapping a must.
Danger Will Robinson!!!
Kindness is the language which the deaf can hear and the blind can see. - Mark Twain
I like wxWindows and especially it's a child project wxPython. wxPython is my favorite way to develop GUI apps because it is easy, flexible, cross-platform, and looks great. My only major wish for it is a Java port so Python/wxPython programs could be made portable to Jython. :)
At what price learning? At what cost wisdom? The price is a man's peace of mind, and the cost is his life.
http://www.puma.dpg.devry.edu/~markvd/index.html
You bet!
If you don't like the RIAA/MPAA just open the url, and minimize the window...
l
http://www.puma.dpg.devry.edu/~markvd/index.htm
This is my sig, there are many like it but this one is mine...
I like wxWindows but it's not nearly as well and copiously documented as Qt. Also, being able to build code in Linux, FreeBSD, OSX and Windows (at work) is very, very, very cool.
Qt all the way!
The heat from below can burn your eyes out
At my new employment I had a project that needed to be cross platform. I was itching to use Kylix, however it wasn't due to be finished for another 8 months. Looking into the details I saw that they built the corss platform support on QT.
After checking out the QT tutorials I was immediatly hooked. QT is intuitive; I can't think of many other APIs I would grace with this description. In addition to being well thought out it has a superb implementation. I've been using it happily for 2 years.
The only thing I miss is the strong third party component community that Delphi/Kylix has. I'm a huge fan of "buy don't build". You can really put quality touches on your app by finding the right component someone else has already made.
-R
available with Eiffel Software's EiffelStudio development suite. It's called Vision2 and provides platform independent look and feel by using a bridge pattern to separate an interface layer from the underlying implementation layer (which uses the Win32 API and Gtk+ for the platform dependent stuff).
You can download the full EiffelStudio suite for linux (and Windows) and use it free for non-commercial software, Vision2 is included and is available here, it's free!
-- You see what happens when you have fun with a stranger in the Alps?
Here's the link with more info: Borland Kylix Open Edition
-My Karma ran over your Dogma
What about Mozilla's XML based GUI - XUL?
What has been your experience with WxWindows? The web site says that WxWindows provides a native look and feel on Windows, Unix, or Mac. There are IDEs and other tools.
For the kind of GUI-I-Wanna-Slap-Atop-A-Database, I like to use Tcl/Tk. Works great for programs where you just want to have something quick, rapidly prototyped AND cross platform.
If you really want a well orchestrated OO GUI toolkit (with the exception of some nasty hacks), QT is a great thing to couple with C++. I know there are many out there that cry foul at the MOC. For the uninitiated, QT uses a macro processor to add a few keywords to C++ for their Observer(or Publish/Subscribe) pattern. I feel that these extensions are minor, and do not significantly detriment the portability of the code. That is, unless you are insane and derive EVERYTHING from QObject - then you are going to be heavily dependent on QT. In a well abstracted interface, your main code tree shouldn't contain much, if any, GUI code.
I have a lot of respect for GTK+, but it just isn't for *me*. GTK programs do generally feel a little more responsive on slower hardware, and are generally lighter weight (being mostly pure C), but the question seems to revolve more around cross platform programs, and GTK doesn't seem to integrate very naturally with the other platforms - at least not the programs that I have seen.
The author has spent a lot of time looking at existing UI libraries and tried to learn from them before writing his own.
See the website for more info.
Swing and AWT often provide poor GUIs. Java is often slow. Sun involvement makes Java a proprietary technology. Is Java dying?
Eclipse does have a few glitches in the Linux version.
For those that don't know, Eclipse is based on a unique IBM GUI toolkit called SWT. It has a Java API, but the underlying code is native. The supposed advantage of this is that it can be used by any Java programmer as an alternative to Swing, but it's faster. The problem is that it's only available for Windows and Linux, and since the underlying code is native, it has to be separately developed and maintained. Since more GUI apps are run on Windows, there's more pressure to make the Windows code work right, and the Linux code is always a little behind.
I don't think there's any advantage to SWT these days, with Swing programming coming along so well. For anyone who doubts this, have a look at IntelliJ Idea, a really nice Java IDE that's Swing-based, and super fast. Frankly, I think Eclipse and SWT was a move to establish an IBM-centric Java community, with lots of vendor lock-in. Hijacking Java from Sun, if you will.
Eclipse *is* a really nice application, but I don't think IBM's motives in creating it were at all community-minded. And I don't have high regard, or high hopes, for SWT.
Someone forgot to tell Apple.
For Windows and linux (x86) cross-platform programming, the CLX library from borland (ships with kylix and delphi/cbuilder) is pretty good.
In my experience with many GUI toolkits. There just isn't any one that works well accross all platforms. Those that come close are just lacking of features.
If you have the time and knowledge, the best thing is to use each OS's standard toolkit. Whether it be MFC, QT/GTK, Cocoa/Carbon, or whatever, if you want it to look good and feel good, you can't really have cross platform.
Despite this, I do not discourage using cross-platform toolkits. On appliactions that the GUI isn't really that important, or it is placed elsewhere (OpenGL, etc), cross-platform toolkits work great.
Just my 2 cents
---Baseball is not right, a man can not walk with four balls. mike9010
Hi. I believe the word you're searching for is "fucking".
HTH
HAND
mstyne: real name, no gimmicks
Man, you're right. The RFC for HTML had one thing that MFC, QT, GTK+, Cocoa, etc. will never have:
<BLINK>
I know I'll get beaten up for this, but how about Java / Swing? One project I wrote had to work on W2K, Solaris, HPUX, and SCO. Plus, I had to use a C library to boot. Had to develop a client with tabbed pages, trees and grid controls with drop down lists within cells. What did I use? Java with the Swing GUI library. Although it had some limitations, I was able to successfully port the app across all machines with virtually no code change! I liked the Swing architecture much more than other libraries I've used.
Is SWT JCK-certifiable?
but it really did help me get started in programming oh so many years ago.
:) bosses.
If you really do use BASIC, I recommend RealBASIC for Mac OS X. I could never stand it for serious development, but it's a lot better than VB with features like syntax formatting to make lame code easier to read.
I used it to throw together a custom client for my Fortune page for all the lame OSes in a few minutes. BASIC is still easy to look down upon and all implementations are seriously lacking in vital(at least to me) areas. RB doesn't have UDP support, and VB doesn't have syntax formatting.
Back to the serious topic and away from replying to a joke: Java's SWING toolkit is my favorite multiplatform toolkit. A single binary works for most platforms, and "advanced" features that we don't consider necessary in disagreement with our respective (former
For quickly drafting small projects, PHP and other server-side scripting languages are a great option. I would love to be able "throw togethor" something like this as well as package it into self contained binaries for winshit and OS X.
You can't judge a book by the way it wears its hair.
It seems that a fancy name for user interface design is "Information Architecture".
Usability Links
More Usability Links
Site Critiques
make xconfig doesn't look very gnome2-like, but I still use it.
Users will judge a product based on how it performs, and (hopefully) not how it looks.
You can't judge a book by the way it wears its hair.
My company has been using wxWindows for a year now. Our simulation software runs in gui and console modes. We use wxWindows because it offers cross platform (win32, linux is all we use) GUI, sockets, threads, file system stuff, 64 bit integers, "registry", OpenGl. You can build wx libraries without the gui stuff and still get the other cross platform functionality.
I use a (commercial) gui "wizard" - wxDesigner - to layout our dialogs. Others do it by hand. The open source version wxWorkshop wasn't up to speed the last time I checked (6 months or so ago), but could be there now.
The only think wxWindows isn't able to do for our company right now is display multiple children in an MDI at the same time under GTK (they're drawn as seperate tabs).
Omnis Studio
;^)
Check out on the web at:
www.omnis.net and download an evaulation copy.
Once a programmer is up to speed, they can easily outperform a team of 3 - 4 java developers. The tool creates interpreted cross-platform libraries (Windoze, Mac OS, and Linux/Solaris) that can connect to many different database backends.
Unique web client is a small downloadable footprint, making applications much faster to develop, deploy and execute than java/swing applets.
Oh, wait...its not open source. Nevermind.
Can't someone write an API that translates directly to native widgets on OS X, Gtk+, and MFC? Native will always win out over non-native (Apple's Safari being a recent example).
Or would the LCD of these three platform's toolkits not be usable in any way? Are they that inherently different?
My impression is that wxwindows is is a bit different than the other tool kits mentioned because it tries to provide a wrapper to the underlining gui system rather than creating its own. That may limit its functionality and portablility a little, but it means that you really will get native look and feel across platforms. I would imagine that it also cuts down on memory and speed overhead.
"Why so many fans? You're generally either funny or have something interesting to say, and the freak sheldonb hates you as well."
/. celebrity of some sort. I checked, though, he does have me on his foes list. Ha!
Thanks man, though I'm stunned you got a +1 instead of an off-topic for that, heh.
Question: Who's Sheldonb? Assume that's either you or a
*posted with no bonus because I'm off-topic.*
For example, the way that Kuro5hin has dynamic threads. They keep a stub of each comment id, and then run javascript to dynamically load the comment's contents when requested.
I'm not sure whether it would have worked for you... real time graphical information -- so you needed to reload an image? How often?
It's not suitable when you want to change an image ten times a second, but if your application would suit 2 or 3 second updates then there's a lot you can do with Jabbascript.
Ahh Jabbascript.. the world doesn't know what you can do.
Trolltech's QT costs $1550 each, per developer, for commercial use on Windows and Mac.
QT versus Java (PDF file)
QT versus MFC, in English (See the French below.)
QT versus MFC, in French (MFC contre Qt)
pyGTK with Glade is the EASIEST GUI toolkit. It may not be the "best" but I've built a commercial, cross platform application using it (here is a screenshot) and I am a complete retard at GUIs. It took a total of 2 weeks - from complete scratch. Porting it to Windows for my customers is just a matter of installing a few simple .exe's - they are used to that anyways. Because the GUI is actually a .glade XML file, I don't have to write any code at all every time I change it. It just makes more sense than having to worry about integrating your entire IDE into a GUI builder!
The parent post is so full of errors, I don't know where to begin.
by your argument than what is Aapche Software Foundation which alos contibutes to Jav through the JCP process
Don't Tread on OpenSource
GCJ [1] makes SWT [2] *truly* cross platform. You are not even tied to the Java VM at runtime.
For example I'm creating windows GUI's under MinGW with GCJ and SWT [3]. But it should work anywhere that GCC and SWT work and you can develop in C++ (or any GCC language?) as well as Java.
If you like Java and refactoring you can develop in Eclipse under a full java platform but deliver native executables.
[1] http://gcc.gnu.org/java/
[2] http://www.eclipse.org/
[3] http://gcc.gnu.org/ml/java/2002-12/msg00105.html
I don't understand the value added in having everything cross-platform. I know, you can run the app on multiple platforms, not everyone runs Windows, blah, blah, blah. But, in reality, very few corporate apps are going to be run on multiple platforms. Most are used in one department/group which is standardized on one platform, and doesn't jump around willy-nilly. It doesn't happen. And, considering the averate life span of most apps, I think that today it's even *less* necessary to make sure that one app is multi-platform. Use the tools that work based on where and how the app is gonna be used. By the time new platform support is necessary, chances are a new app is gonna be needed anyway.
But, that being said, my vote is for Oracle Forms. Build a GUI with a VB-like interface, and click the button that makes it all a Java app. Slickest thing out there that's not being used.
The V Toolkit for C++ had a lot of promise, but sadly it doesn't seem to have been maintained in a while...
...is not valid C - maybe you were trying for another language?
XML causes global warming.
I'm confused.
What the hell's wrong with printf and fgets?
Eloi, Eloi, lema sabachtani?
www.fogbound.net
For a very different (but interesting!) approach to x-platform dev, a company called Laszlo Systems has a "presenation server" that delivers full-fledged apps with real, desktop-style UIs into just about any browser. They have an XML- based application description language, combined with a JavaScript library -- all of this gets compiled by the server into SWF files (Macromedia Flash, version 5).
http://www.laszlosystems.com/
bottom line is it sounds like you get the benefits of things like SVG and XUL (standards-based, textual authoring) combined with the cross-browser, cross-OS/device compatibility and visual dynamism of Flash. No Flash authoring needed... XML only. Not a bad approach... and both the client (browser) as well as their server will run on Linux, Windows, Mac... etc.
Has anyone worked with this?
For the majority of the time I create GUI's in Java's Swing API. Despite what the purists say, my experience has shown that with a little bit of fore thought and not having Swing developers rely on GUI builder tools that create some pretty bad code, a.k.a JBuilder which is a good example of this. I personally like the SWT approach via IBM Eclipse project, yet purist will most likely say that this toolkit suffere or will suffer the same quasi-proprietary baggage that people claim Swing suffers from with Sun's involvement with Java.
However with the subject at hand, why are GUI toolkits such an issue anyways. This seems like a senseless battle that tends to reflect a typical male chauvinism of mine is bigger and better then yours so NAH !.
I have no experience with most of the *nix toolkits as they honestly gave me no reason to start since I could never figure out which one was the most sensible to use. This is something I am sure alot of *nix developers face as they decide things like "Do we want GNOME support, KDE support, both ?" Working with MFC some they are all right of course there is not the smorgasboard of choices present in the windows world as *nix worlds. I think in Win32 for native Toolkits you are limited to MFC and QT, I could be wrong.
So now the question is not really what toolkit is the best to use, but which toolkits can simply go away. Realistically how many different usable ways can you create a window and manipulate a window component. I ask this becuase i have managed to create very nice platform independant GUI's that work damn near identical on linux, mac, and windows and with the exception of win32 and linux since the Java Look and feels don't emulate the environment 100%. However disregarding certain things they pretty much look native.
So if Java API's are good enough to create an abstraction layer to the native look and feel. Whats to say that idea can't be taken a step further and take the java factor out, this is similar to SWT approach. I mean seriously lets show some innovation here, instead of trying to declare on toolkit over another based on the premise that something as silly as showing a round button with gradients versus a flat rectangular one with no gradient colors.
On a final note of this rant, a simple standard toolkit for platforms to could encourage developers to work with simpler toolkits that give them the benifit of working on multiple platforms with confidence, this way more developers more applications that are available to more people then just select few for whatever platform the choose. For those purist or XXX toolkit zealots out always remember if you have special needs that a standard toolkit doesn't provide you can always go one step further and do it yourself, i mean there is always assembly right ?
Everyone knows a good developer uses just a ;) Just kidding of course.
simple text editor.
For me, I see the many aforementioned GUI kits
as great tools but it all comes down to what
the job demands/dictates. I find myself being cross-trained
instead of cross-platform developing. Every contract we take on,
we are asked to perform it in the company's chosen dev environment.
Anyone else in this predicament?
Does anyone know of a site that tracks various
IDEs that are currently in use?
If your company requires multiple IDEs as mine does,
who supplies you with the training to effectively
use the tools as well as the languages themselves?
Yes, but doesn't it make a difference that WxWindows is:
Wookie LOVE!!
Who wouldn't want to make love to Chewbacca?
Sun controls Java. No one controls Unix work-alikes.
-
http://zoolib.sourceforge.net/
It draws its own widgets, but uses switchable renderers so it maintains the platform look and feel. It uses the Appearance Manager if it is available on the Mac OS. It put the menu bar in the windows on Windows and across the top of the screen on the Mac.It supports Mac OS (68k, PowerPC, classic and Carbon), Win32, BeOS x86 and Linux. It would not be hard to bring it to a totally new platform.
It is in C++, is multithreaded, and provides a complete solution - not just GUI but TCP networking, file I/O, streams and persistent storagge.
If you use it, I suggest you use the version in CVS as a lot of work has been done since the last release. A new release is planned soon.
I have started writing a tutorial called The ZooLib Cookbook.
ZooLib is under the MIT License and the Cookbook is under the GNU Free Documentation License.
ZooLib has actually been around longer than even wxWindows, but it was only placed into open source in the fall of 2000. Among the applications written with it is Knowledge Forum.
Request your free CD of my piano music.
Omnis Studio (www.omnis.net) is a multi-platform application development environment that allow you to build business centric applications. It allows you to develop an application on one platform and deploy to all other platfroms with little or no code changes. The deployed applications have a native look and feel. Currently Studio supports Linux, Windows, Mac OS 9 and X, and Solaris.
From what I hear, there is even support for Windows CE (or whatever it's called) planned in the future.
Studio also has a client that allows to embed a fully gui application in a web browser too.
It's pretty amazing stuff; especially since the technology has been around sice the Apple II!
A handy resource:
/ guitool.html
http://www.geocities.com/SiliconValley/Vista/7184
I'll be able about cross-platform GUI toolkits when they make one that looks as good in windows as mfc does. Its easy enough to make a toolkit thats easier to use and understand than mfc, but its awful hard to make one that produces an end result that looks and feels like a native windows app. Linux users are used to apps that don't behave in predictable manners, or don't look the same (mozilla is awful popular among linux users for instance), but windows users are less accepting of programs that look and behave 'wrong'.
One person's analysis and comparison of GUI toolkits: Why this GPL programmer didn't choose
If this is a dupe, post a link to the previous story.
I would check out VisualWorks from www.cincom.com
It is free for non-commercial use. I signed up as a VAR with Cincom a few months ago, and I have been very impressed with VisualWorks.
On this topic: it is easy to build native-looking applications
for Windows, Linux, Mac OS X, etc.
-Mark
Mono and GTK can be compiled to native binary, eliminating the possibility that exists with Java of easily seeing the underlying coding.
As usual, this thread has wandered pretty far from the original topic, which is a shame considering that this is a fairly important issue for a lot of people. I do actually have a little experience in this area, so here's what I know that might help: wxWindows: If you're going to stick to a C++ cross-platform application framework, I honestly believe this is the best option. Most people don't seem to pay much attention to it, and many of those who have were burned by bugs in earlier versions, but it's really starting to come together in terms of both stability and functionality. I ported early code for a pretty complex program from MFC to wxWindows within 2 months, which impressed me considering that I wasn't familiar with either toolkit and that was my first real use of C++. I'm now doing a bit of work with wxPython, which is also going pretty well. The Mac port development tends to lag a bit behind the others, but it has been (and is being) used to deliver several commercial products, so it seems to be in usable condition; I haven't had a chance to test it myself yet. By all means, please carefully consider this option; it seems to be the most capable framework of it's type currently out there, has a respectable number of users and developers, and will get even better with more support. CPLAT: Afraid I can't say anything as positive about this one; the MFC project I mentioned above was itself a port from CPLAT. After 2 months of development with CPLAT (ending January 2000), the developers unanimously agreed that the framework was so buggy that it would be faster to write separate versions of the program for MFC and PowerPlant. I believe there is only one developer on the project; that simply isn't enough resources to properly handle a framework of this magnitude. Whisper: We looked at this one also, but it didn't have enough of the features we were looking for to be worth trying. It also looked to be, like CPLAT, a one-man effort. YAAF: Another one we passed over after a brief glance. The web site didn't have much information, and I don't see any indication that it's being used much. I may have short-changed it, but I just don't see enough activity around it to indicate a really good product. GLUI: I haven't used this or looked too closely at it yet. The lack of native widgets bothers me, though... Carbonless Copies: Hadn't heard of this before. The web site given above hasn't been updated in a while, I haven't heard of many people using it, and it's a proprietary program; I'd be inclined to avoid it. Regarding some of the other options people have suggested: Java: While useful for some purposes, cross-platform GUIs arguably isn't one of them. It's relatively easy to get a Java GUI program to work cross-platform, but practically impossible to get it to work well. AWT lacks major functionality. Swing is buggy and a *massive* memory hog; don't even think about running Swing apps on computers with 32 MB of RAM, and they're not terribly happy even with 64 MB. And Java in general is lagging far behind on the Mac. Finally, it is a proprietary platform complete with all of the problems that entails. I used to really like Java, but not much progress has been made at solving some of it's critical deficiencies. I'm now hoping Python can take it's place... Mozilla: Mozilla is useful, but it's deficiencies have been noted above; lack of native widgets, slow response time to user input, etc. I look forward to using this for some projects, but it isn't going to replace the need for a cross-platform C++ application framework. GTK+: Doesn't work on the Mac, and won't for some time to come. Doesn't use native widgets on Windows, either (to my admittedly limited knowledge.) I agree with the wxWindows approach; use GTK+ on Windows, use the Windows API on Windows, and use the MacOS API on the Mac. Qt: Again, doesn't work on the Mac and doesn't use native widgets on Windows. Tk: Doesn't have native look and feel, and last I checked has some issues on MacOS. I've also gotten the impression that the widget selection isn't as rich as that of wxWindows, although I haven't looked at it closely enough to judge for myself. On the topic of RAD tools; wxWindows does not yet have a usable RAD tool, although the wxStudio IDE is under development and there is a working dialog and panel editor. wxPython has the Boa Constructor IDE which seems to be almost in usable condition; it could also be argued that compared to using C++, even manually writing Python code practically *is* a RAD environment. Hope this successfully addresses some of the issues, and hope it isn't buried so far down in the responses that it never gets noticed...
on PyQT:
http://www.opendocspublishing.com/pyqt/
Python: cross platform
QT: cross platform, native-working widgets.
QT, however, isn't free for commercial use.
S
cause when it comes to comparing Qt to Java Swing/AWT there is simply no comparison. I'll put it to you straight: code one more graphical application in that dog slow language and I will personally ensure that you eat every word you utter about "java performance not really mattering". A gui should respond to a user request in less than 100ms, anything slower and you have written a dog slow application. I submit to you that EVERYTHING written in Java/Swing that has a graphical user interface element does not meet this requirement. Now, can anyone vouch for SWT?
How we know is more important than what we know.
I've spent a lot of time developing commercial apps on multiple platforms, and I haven't found any perfect solution.
.... (fill in blank with your choice of the day, could be XP themed menus, integration with MS Outlook or a hundred other things) like that latest version of Office/some other app.
...If on the other-hand you rely purely on the app-wizard generating the code, and filing out empty functions, you're probably in trouble anyway. Possibly more trouble with MFC than some other toolkits, but still in trouble whatever toolkit you use.
The trouble is users (especially Windows users) nearly always (eventually) want some platform specific functions: "Why doesn't this app have
So I would suggest the best answer for many problems:
1. Separate the underlying logic from the UI with a well-defined interface.
2. If you need to be cross platform, try to use a toolkit which lets you drop down to the native API where necessary. Otherwise you can really suffer if you later need to do something that the toolkit doesn't support - unless you are absolutely sure such requirements do not apply now, and never will.
3. Be absolutely sure you need to be cross platform, before embarking on the extra work.
4. Every toolkit/API involves some compromises or design choices by the people who made it. Before choosing one, make sure you are aware of the choices the designers made.
Changing subject... For MFC, I think the original choice was "thin wrapper round Windows API". Some later choices involved backward compatibility
Regarding MFC. People bash it. It's not really cross platform. It includes a bunch of IMHO hopeless utility classes. It has quirks. But I would say:
1. It lets you mix with native Windows API easy.
2. It works way better if you truly understand the Windows API. Most of the quirks in MFC are because of Windows quirks.
3. The older utility classes (example: non-template collections) are IMO mostly hopeless, but are there for backward compatibility. At the time they were introduced Microsoft's compiler didn't support templates and STL was still in its infancy if extent at all. CMap, CArray and CString are pretty much the only good ones.
4. There are lots of samples/help at codeproject.com codeguru.com and Microsoft's sites
5. MS do give you the source code to MFC. You could modify it and recompile (although I never found the need), or alternatively you can use this to hack around or better understand a limitation/bug/quirk.
6. Rumors of its death are much exaggerated. As long as Windows supports the Win32 API, MFC apps are still going to work. Whether Microsoft keep enhancing it is another question, but if they don't there are plenty of people rolling their own add-on class toolkits
I've worked with Qt on large projects with ports to both Win32 and various Un*x flavors. I'm really happy with QT (other than stupid reinventing of STL stuff). Qt is clean, well-documented, easy to use and subclass. Gtkmm is very good for a veneer on top of C language OO, but isn't remotely as clean or consistent.
Try a non trivial specialization of a Gtkmm widget - then try the same thing in Qt. IMO, it's not a close call - even if you have the time to figure out what to do in Gtkmm (compare the documentation with Qt's docs).
flash mx/actionscript using it's native xml stuff to talk to web services. for distributed data access type apps especially ones that require visualization, this could well be the future.
it's just too bad its proprietary
No, I'm not sheldonb...I meant to hit "no karma" on my last post and hit "post anon" instead. He is a foe of mine as well. He doesn't post, no friends, just collects foes. Anyone he hates must be ok in my book :)
I never noticed anything "funny" about wxWindows either....'cept the "now for something completely different" splash screen in wxPython, but I imagine this is just as funny on any platform. Actually now that I come to think of it wxBasic was pretty funny too (in a good way).
I reformatted the parent post. No other changes:
As usual, this thread has wandered pretty far from the original topic, which is a shame considering that this is a fairly important issue for a lot of people. I do actually have a little experience in this area, so here's what I know that might help:
wxWindows: If you're going to stick to a C++ cross-platform application framework, I honestly believe this is the best option. Most people don't seem to pay much attention to it, and many of those who have were burned by bugs in earlier versions, but it's really starting to come together in terms of both stability and functionality. I ported early code for a pretty complex program from MFC to wxWindows within 2 months, which impressed me considering that I wasn't familiar with either toolkit and that was my first real use of C++.
I'm now doing a bit of work with wxPython, which is also going pretty well.
The Mac port development tends to lag a bit behind the others, but it has been (and is being) used to deliver several commercial products, so it seems to be in usable condition; I haven't had a chance to test it myself yet. By all means, please carefully consider this option; it seems to be the most capable framework of it's type currently out there, has a respectable number of users and developers, and will get even better with more support.
CPLAT: Afraid I can't say anything as positive about this one; the MFC project I mentioned above was itself a port from CPLAT. After 2 months of development with CPLAT (ending January 2000), the developers unanimously agreed that the framework was so buggy that it would be faster to write separate versions of the program for MFC and PowerPlant. I believe there is only one developer on the project; that simply isn't enough resources to properly handle a framework of this magnitude. Whisper: We looked at this one also, but it didn't have enough of the features we were looking for to be worth trying. It also looked to be, like CPLAT, a one-man effort.
YAAF: Another one we passed over after a brief glance. The web site didn't have much information, and I don't see any indication that it's being used much. I may have short-changed it, but I just don't see enough activity around it to indicate a really good product.
GLUI: I haven't used this or looked too closely at it yet. The lack of native widgets bothers me, though...
Carbonless Copies: Hadn't heard of this before. The web site given above hasn't been updated in a while, I haven't heard of many people using it, and it's a proprietary program; I'd be inclined to avoid it.
Regarding some of the other options people have suggested:
Java: While useful for some purposes, cross-platform GUIs arguably isn't one of them. It's relatively easy to get a Java GUI program to work cross-platform, but practically impossible to get it to work well. AWT lacks major functionality. Swing is buggy and a *massive* memory hog; don't even think about running Swing apps on computers with 32 MB of RAM, and they're not terribly happy even with 64 MB. And Java in general is lagging far behind on the Mac. Finally, it is a proprietary platform complete with all of the problems that entails. I used to really like Java, but not much progress has been made at solving some of it's critical deficiencies. I'm now hoping Python can take it's place...
Mozilla: Mozilla is useful, but it's deficiencies have been noted above; lack of native widgets, slow response time to user input, etc. I look forward to using this for some projects, but it isn't going to replace the need for a cross-platform C++ application framework.
GTK+: Doesn't work on the Mac, and won't for some time to come. Doesn't use native widgets on Windows, either (to my admittedly limited knowledge.) I agree with the wxWindows approach; use GTK+ on Windows, use the Windows API on Windows, and use the MacOS API on the Mac.
Qt: Again, doesn't work on the Mac and doesn't use native widgets on Windows.
Tk: Doesn't have native look and feel, and last I checked has some issues on MacOS. I've also gotten the impression that the widget selection isn't as rich as that of wxWindows, although I haven't looked at it closely enough to judge for myself.
On the topic of RAD tools; wxWindows does not yet have a usable RAD tool, although the wxStudio IDE is under development and there is a working dialog and panel editor.
wxPython has the Boa Constructor IDE which seems to be almost in usable condition; it could also be argued that compared to using C++, even manually writing Python code practically *is* a RAD environment. Hope this successfully addresses some of the issues, and hope it isn't buried so far down in the responses that it never gets noticed...
And these are just my biggest objectsions. The Tk widget set is not bad. It is quite ugly and limited, but good enough for a small GUI app. The underlying language though is absolute crap.
The only good thing about Tcl is that it provides a (relatively) easy way of interfacing with C code: you can expose C functions as Tcl commands (e.g. you could map Tcl command foobar to C function MyFooBar()). This is, in fact, what Tool Control Language was designed for: exposing C functions to a high-level script to facilitate easy automated testing. However, trying to write a real application in Tcl is an excercise in futility. There are much better alternatives available. But, if all you have is a hammer, everyting looks like a nail -- that is why Tcl is the "past and future king".
___
If you think big enough, you'll never have to do it.
"No, I'm not sheldonb...I meant to hit "no karma" on my last post and hit "post anon" instead. He is a foe of mine as well. He doesn't post, no friends, just collects foes. Anyone he hates must be ok in my book :)"
:)
Ha! I noticed he never posted heh. Makes you wonder what that guy's up to.
Cheers man.
Re: "Swing programming coming along so well" Until not so long ago I had to use Celeron 400 w/ 128 MB at work. And, you know, Swing DID NOT really swing in there...
I'm not a developer, but a [free software] user. I've thought about this issue a bit, and though I'm ignorant of many things I believe I have a few points to make.
gtk+ is a large project, widely used under linux at least. This leads to applications that all look the same. This is huge. It may not make complete sense, but I've come to dislike alternate toolkits just because they don't look the same. Consistancy is a great thing especially when dealing with themes, keyboard input/shortcuts, etc. (unfortunately, wxwindows apps do not look the same as gtk apps, it's very close, but the file dialog is different for example, and audacity's toolbar does not theme (yes, gtk's file dialog sucks, but that's a different issue))
Some say gtk is ugly; well, it's themeable. It's annoying to find a pretty theme and then have a tk window pop up, making you wonder why you even bothered.
The largeness of the project also leads to things such as atk and pango. I think these are a good thing, and I just don't see the smaller toolkits having things like this (though, as I understand, pango and atk are not gtk specific...).
I am in midst of rewriting a Motif application that used a plotting library ( XRTgraph ) for displaying data. In all the cross-platform gui environments which one has a decent plotting library?
FD 20
RT 90
FD 20
RT 90
FD 20
RT 90
FD 20
will always produce a square.
I know people won't be into this, considering the crowd here, but all the same:
I use Squeak Smalltalk as my cross-platform toolkit of choice. Squeak includes a cross-platform GUI toolkit, as well as a cross-platform language, IDE, runtime and configurable world of libraries. Once you get out of the rut of Tk, GTK+, etc and get used to the programming style, it makes so much sense, it's almost scary. I was doing Python+(Tkinter or wxPython) before Squeak.
What most people here will gripe about is that Squeak's GUI system, Morphic can't be called from C, C++ or Perl at this point. It's possible, but so far our users have been happy enough with Smalltalk not to move away from it. Squeak also has it's own UI look and feel- it's not Windows, Mac OS, or GTK+ in appearance. I may be in the minority, but I prefer a clean look to poorly emulated widgets. By default, the look and colors are a bit kidsy, but like everything in a Smalltalk system (ala emacs, but easier!), it's very configurable.
Squeak supports a lot more platforms that most of the combos mentioned here. Right now, Squeak supports: Mac OS X, Mac OS Classic (System 7 - OS 9; m68k and PPC), Windows >= 95, DOS, WinCE (StrongARM, XScale, MIPS, SH4), X11 on any modern Unix-like, Linux framebuffer (Linux PDAs and kiosks), SDL (lending support to PicoGUI and others), OS/2, and the Acorn RiscOS. It also runs on bare hardware on stock x86 machines, complete with drivers written in Smalltalk. There might be more, but that's should be most of them.
No, I would reccoment it to people who are wanting to create a business app for a homogonized work environment, but it has many uses.
Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
Can you post a link to a non-commercial license for Qt? I can't find it.
Sure, Qt can be used on Unix, Windows or Mac, but how does it achieve the native platform Look-and-feel? From the screenshots, it appears that there is are Windows and Mac themes, but how does it achieve this theme?
Does it:
Swing, and the "redmond" theme of GTK+ do (1); even these well maintained toolkits miss minor details in their rendering of system native widgets, so they end up just looking wrong. In addition, the interactions with menus, buttons, etc differ in subtle ways from genuine system native, making applications built using them respond in an unexpected manner.
From what I can make out, the nativeWin theme for GTK+ does (2), so it should look right, but it will still feel alien.
The only toolkit I can think of that does (3) is wxWindows. IMHO, this is the best solution, as it ends up with a genuinely platform native look and feel. However, I haven't ever programmed with wxWindows, so I can't comment on it as a toolkit in practice.
Under unix (1) doesn't really matter, because there IS no "system native"; as long as all your apps use the same toolkit, (vis, Gnome or KDE), you don't end with apps that feel wrong.
So - Which category does Qt fall into? Does anyone know of any other multiplatform toolkits that fall into category 3?
Russ %-)
... and never, ever play leapfrog with a unicorn.
It's not a troll. I've seen some slow and quirky Java applications. People are beginning to rebel against Sun domination. C# seems to answer some of the problems. The excitement over Java is beginning to cool.
What about Borland Kylix/Delphi/KLX? I have not used it, but it looks promising? Do any Slashdotters have experience with these?
I would be only too happy to!
Qt/X11 Free Edition (Unix)
Qt/Embedded Free Edition
Qt/Windows Non-Commercial Edition
We're going down, in a spiral to the ground
It's quite apparent that you are completely oblivious as to the true value of a scripting language. Your rant seems most specifically against scripting in general, but I'll address all the points:
1. Tcl is a scripting language, but it does compile on-the-fly for speed. It is true that it doesn't compile everything statically, but that is because Tcl is one of the most dynamic of languages. You can redefine any command you want at runtime, so what appears "wrong" may be correct by the time the code reaches it. Numerous tools exist to validate large bodies of Tcl code.
2. Weak typing can be a big boon to software development. Why is the need to call strtol() or some equivalent of value in large projects? It only makes large projects larger. Some statistics put bugs in software at 1/20LOC written. Of course, with scripting you need 1 LOC to a systems language's 5-10, but the bug rate doesn't increase. So which one is really better for large projects?
3. I think you are thinking about perl. You cannot refer to a var (like $var) without having set it first, although you can in perl (when not strict). You can of course set a misspelled varname, but that's true of all scripting languages. Tests are the only way to ensure that anything you create does what you expected.
The core Tk widget set may be some 15 widgets, but there exist 100s more for users to choose from, from simple comboboxes to complex graphing widgets. Furthermore, it uses native elements on Mac and Windows.
I wrote a white paper about this on new years day. The mingw project has made native Win32 binary development using Java and the SWT API possible. In my opinion this is the only true write once, compile anywhere solution.
Choose your compiler at your own risk.
int main(int argc, char **argv)
{
printf("Hello I compile under ANSI C\r\n");
return(0);
}
Seriously,
Give me a break. If you have to ask this question then you haven't coded for multiple platforms. Ever!
A UI is just a UI. As a developer, decide how the user will interact with your program. Abstract the lower layers and then create your Win32/Gnome/KDE UI. Jeesh, this isn't rocket science. If your design is right, it's not hard to maintain separate UI's for your target platform. This is my build process....
make kde
make gnome
make win32
Enjoy,
It's just the normal noises in here.
Qt: Again, doesn't work on the Mac
Qt does work on Mac OS X, and it does not require
an X server running to display, although it is not 'native' in the sense that quartz is native on OSX.
Trolltech's site
lists it, and I saw a demo once of a graphing app that was using Qt on Linux, Windows, OSX, and Windows CE, all with 2 lines of code changed across the platforms. Not too terrible.
In order to achieve the cross-platform compatability between gnustep and cocoa, you have to code on the gnustep platform. Apple has added much to make cocoa differ from the original openstep specification. So taking gnustep and compiling it on cocoa works fine... but not so the other way around!
Brought to you by Frobozz Magic Penguin Fodder.
I wrote GUI foundation classes and async communcation routines in Director for the mac and pc. Samples of part of the functionality can be found here:
a ries/
Downloadable mac projector is here:
http://www.zavatone.com/director/UI%20Libr
Features in demos:
Automated asset creation
Named Button/Control registry
Messageable Buttons and Toggles
Command keys assigned to items
Command key display (hold down command or control key)
Arrow navigable controls (press space or return to activate)
Async animation manager
This GUI is completely abstractable from whatever back end needs it. Communication between front and back end is managed through my async messaging routines.
All content ©Alex Zavatone.
- Zav - Imagine a Beowulf cluster of insensitive clods...
Dude, that guy is like one of the editors in disguise. I posted about it on the user-generated comments a few days ago. He seems to collect foes that score +5 by saying anything that isn't "LINUX R0X0RZZZ". I bet he's collecting names to just bitchslap in one big go. In the mean time it's cool to look up his foes and see what they're contributing, because it's usually pretty cool.
I got a sig so you would remember me.
If you want a simple answer and you are asking for a C++ toolkit, your best bet is C++. But you have to realize that there are intrinsic tradeoffs in choosing any toolkit.
HAND
XPCE is an excellent cross-platform alternative, at
http://www.swi-prolog.org/". Most discussion is about Prolog, but see http://www.swi-prolog.org/packages/xpce/ for info about C, C++, LISP bindings.
The low-level Windows API solution is the each object has a window handle and the interface that goes with that -- a WinProc. That means every window object has to expose the same, complex interface with a zillion Windows messages to every other window object it can come in contact with. This leads to (what some people) consider ugly -- the Giant Switch Statement in C implementations or those even uglier message map macros for C++ MFC (I believe wxWindows uses message maps too).
The Grand Quest is some simple mechanism for making direct signalling connections between objects without breaking encapsulation -- exposing the inner workings of every object to every other object: kind of like how to be on the Internet and disclosing your e-mail address without losing your privacy or worse.
The solution is to create some bridge class -- a courier with a personal knowledge of the recipient but a courier which publishes only a very generic interface to those seeking to contact the recipient. In Delphi that courier is an event type, in Java, it is an inner class with an ActionListener interface, in C# it is a delegate.
Qt has this mechanism called signals and slots, and to pull it off they had to extend the C++ language with this macro processor called MOC, and this has the BVDs bunched of C++ purists because they are in effect extending the language.
On Windows, Qt uses native Win32 widgets and is fully integrated into drag/drop, clipboard, keyboard shortcuts, standard dialogs etc. Applications built with Qt, such as Psi, the excellent cross-platform Jabber client, feel perfectly native.
On Mac OS X, Qt uses the Carbon APIs and therefore looks and feels native. However, the Mac GUI is different from Windows and Linux in several ways, most by convention, such as the placement of the menus, window resizing icon, button placement, icon look etc. Psi, for example, looks okay on OS X, but its default theme's choice of colours and icons makes it stand out like an eyesore among the slicker Aqua apps. However, it's definitely possible to create a Qt app that follows the Mac design guidelines and therefore looks and feels perfectly native.
On Linux, Qt is the native widget provider.
Swing still really falls short compared to other cross-platform offerings. In particular, performance and correctness of Swing on X11 and Macintosh are iffy: for example, window management is broken on X11, antialiasing makes lines disappear on Macintosh, and graphics can crawl to a halt in the presence of transparency on both X11 and Macintosh.
Another problem is that Swing is, as you point out, only "free as in beer": it's not open source and there is no open source implementation. Sun could, at least in principle, pull the rug out from under you at any time, for example, by starting to charge for commercial applications. And I recommend that you read the JRE license very carefully--it already comes with many strings attached (e.g., Sun reserves the right to install software on your machine).
If you need to write cross-platform prototyping code, Swing is OK. However, something like wxPython is probably both a bit easier to use for prototyping still and works somewhat better across platforms.
If you want to write professional-looking, robust, and efficient cross-platform applications, Swing is not the answer, at least for now. Programming in something like wxWindows or Qt may be a lot more work, but at least you can get the job done.
SWT doesn't use Swing it uses a JNI layer to hook into the native GUI stuff. Very fast and looks like Windows on Windows, gtk on linux etc. Only wish it had a UI builder. I guess that will come one day.
Bitter and proud of it.
E.g. Qt supports more platforms than shown, and RealBasic, Director, Flash, and QuickTime are not shown.
RealBasic is a very effective cross-platform (windows / mac -- no *nix sadly) development tool that does a good job of native appearance and behavior from a single code base.
http://www.realbasic.com/
Director and Flash are multimedia development tools. They are also, incidently, both capable of creating cross-platform double-clickable or web applications from a single code base. Indeed, Flash code is probably one of the MOST portable and cross-platform GUI toolkits there is (it runs inside QuickTime and on quite a few embedded systems and both Palm and PocketPC).
QuickTime is -- aside from being a very nice digital video architecture -- a cross-platform GUI toolkit with an embedded bytecode-executing virtual machine.
Composition is association; Layout is just containment of views.
Don't forget eiffel.net for the .NET platform
It the best programming language, PERIOD
Is excellent. I am using just wine, without winshit to grab libs from, and have yet to encounter a problem.
Stability in OS X is another issue, RB crashes frequently.
My first "awesome" computer is a 286 lappie w/ 4mb of ram and 20mb of hd space. I started on a comodore vic 20 when I was 8. Then again, all my friends had parents with Winshit 95 at the time......
Damn I was ahead of the times!
You can't judge a book by the way it wears its hair.
" In the mean time it's cool to look up his foes and see what they're contributing, because it's usually pretty cool."
/. is fun. Know of anybody else like that?
Ha! Hehe I think I see what you mean. Experimenting on
I've been using the Win/Linux CLX libs from Borland and they rock. A decent IDE in Delphi, plenty of support, and Interbase/Firebird is solid.
my $.02
Not at the moment, but it just occurred to me it'd be really cool if a couple of "organized accounts" were set up and managed some friends/foes lists that people could use as resources. For instance "REAL_TROLLS" could list all the interesting/clever trolls as its friends, "CRAPFLOOD_TROLLS" could list all the crapflooders/goatse posters as its friends etc... "FOES_OF_TROLLS" could list people like sheldonb whose only contribution is another list of "real" trolls... Hell, we could get totally recursive here. It would rock.
I got a sig so you would remember me.
Did anyone notice that the informative reply, "this one" got a score of 1?
Heh. I wanted to register a bunch of Dilbert names so I could have each of the characters respond based on their own.. uh.. defectiveness. Problem is I could dedicate my day hours to that.
Judging by your posting frequency dude i think you already do :)
It would be cool, though. Were you around when the whole spork thing went on? Ten zillion sporks. That was funny as hell. I got caught in the loops too, with the sigs that teleported back to the middle of the thread which was already 50 answers deep. Clever trolls rock the kasbah.
I got a sig so you would remember me.
"Ten zillion sporks. That was funny as hell. I got caught in the loops too, with the sigs that teleported back to the middle of the thread which was already 50 answers deep. Clever trolls rock the kasbah."
lol!! No. Missed that! Shit, Slashdot needs a hall of fame. I also wanna know how many funny points I've earned.
Don't like it? Start coding!
eiffel is a truely great programming language, in fact when programming in c++ or java I often find myself thinking "why can't this be as easy as Eiffel". The only problem with Eiffel in the past was the lack of library code, there simply wasn't enough of it. Now with the .Net framework making components from any other CLI language available this is solved, I think I may find myself going back to Eiffel programming in the near future. Besides Eiffel is the only language I know where correctness can be guarenteed.
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
Yeah, a Slash hall of fame would be cool. I'm going to ask about the spork issue at http://www.sporks-r-us.com/. The sporks were cool.
I got a sig so you would remember me.
First, a shameless plug: I'm working on a couple of C++ applications that are currently using FOX for the GUI (and other parts). The first one is a front end to the open source stats language R and it is called Obversive. This is the most active project, but it is still real tiny. The second project is a little chat client I'm writing called Bombyx which will work on the SILC and hopefully IRC. In addition to Bombyx, I've also developed a little GUI generator with Lua that makes FOX widgets pretty quickly. It's called GIG and you can get it from the Bombyx site mentioned previously. The intention with GIG is to make it work for any toolkit, but right now it does FOX only.
When I was working on these projects, I went through a huge number of toolkits and actually tried developing fast "mock-ups". My test was to see if I could get the first window I wanted in each project using available resources. If that worked, then I would try a couple of other windows. I also reviewed the designs of each and then went with what worked best at the time.
Here's my review of each of the toolkits I used. These are just my opinions, but they are based on actually using them in various platforms (or trying to).
FOX After all of this evaluation, I found that FOX was pretty much the best at the moment for clean, simple GUI building. It has pretty good docs (way better than wxWindows), and is fairly natural for coding. It also has some nice language bindings for various languages like Python, Ruby, and Eiffel. It doesn't have quite as many controls as wxWindows, and it doesn't work natively on as many platforms, but it is much easier to build and work with and much smaller. If you are porting a Windows application to another platform, you will probably be better off with wxWindows since they try to mimick the API design as much as possible (and of course, all it's problems too). Also, if you hate macros then you'll have a problem with FOX (and wxWindows too). A testimony to how easy FOX is comes from Obversive, where one developer had no C++ or FOX experience and has already created several complicated controls. Another developer has good C++ skills, but only worked with KDE previously. He not only developed an excellent Twin Table control, but also added lots of great features to it and in very little time.
FLTK I did the original work on Bombyx with FLTK. FLTK is a nice library, but it was just missing too many widgets to be useful. It was also rather buggy and it was a real pain to do delegation. There are, however, two really nice things about FLTK: no macros, excellent GUI builder. One of huge problems with ALL other toolkits I've ran into is that, when the developers start to make their GUI builder, the decide they need an entire IDE. I already have one thank you. I doubt some OSS project is really going to out-do my tool chain right now, especially if it's also working on the widgets. Just give me a simple builder please. FLTK got it right with FLUID--their GUI builder. It's real easy to use, super fast, and does one thing well: build interfaces. It was a little weird at times, but I checked out the latest and it worked great. Also, FLTK does not use macros for messaging which is nice for the C++ purists.
Cocoa I love Cocoa, but, Apple made a huge mistake by making it a MacOSX only beast. I think Apple could rule the world if I could spend my time writing my apps with a nice UI, great tools, and an easy language (Objective-C), and then click a button and have a Windows, Linux, HP-UX, and Solaris binary. You could do this with the original NeXT stuff, but Apple crippled Cocoa and friends. So, I reserve Cocoa for other useless programming that I only do on my MacOSX. There is GNUstep, but I couldn't get anything to work with it, and half the fun of Cocoa development is using Interface Builder (IB). BTW, IB is another GUI builder that is excellent, and also does just GUI building. Let's hope the wxWindows guys figure out this pattern and write a small GUI builder rather than their entire IDE which nobody seems to be able to compile but three dudes inside the cabal (sorry, it really burns me).
wxWindows I must say that wxWindows has a ton of nice widgets (I may steal their HTML widget) and works on a huge number of platforms. But, I kept getting burned in three areas: docs, dependencies, and bugs. Their docs are horrible. You have to hunt around the net looking for tutorials which are not very good anyway. Half the example applications in the distro don't even work so you can't rely on them, and it's just really hard to figure out what to do. I also hated having to add a billion other libraries to my build just to get wxWindows to work. I found it a problem when linking my application took longer than compiling all the files from scratch. Finally, just about everytime I went to use some widget, I found some bug or limitation that made it unusable. They have improved quite a lot from what I have heard, and people really rave about it, so I think everyone should give it a try. One thing also that annoyed me about wxWindows is that it does not support delegation very well. All the other toolkits I used either support delegation easily or practically require it. In wxWindows, I spent the better part of a week just trying to get one simple delegation design working and couldn't do it despite lots of help from people on various IRC channels. To me, things are broken if I have to subclass every time I want a widget. The wxWindows XML based resource files are supposed to fix this, but I won't hold my breath.
JFC/Swing The original version of Obversive was done in Swing with lots of other goodies. Java is my primary work language, and I really wanted to use it on the Obversive project, but we just kept running into performance problems. Frankly, Swing is just a P.I.G. and is really hard to code. None of the GUI builders available we tried proved to be that useful, and eventually we dropped it becuase it was just too huge. Ironically, we were able to prototype an almost complete GUI using FOX which runs on Linux, *BSD, Windows, and MacOSX (through the XDarwin or Apple X ports) in about 3 weeks time. This was mainly in part due to the slick design of FOX and simplicity, and partly in part because of the GIG code generator I put together. Oh, and we looked at SWT, but balked at the Linux or Windows only (and the fact that the flagship, Eclipse, ALWAYS crashes on Linux does not make me happy).
So, that's my experiences with these toolkits. I hope that helps answer the question, and I hope the reply wasn't too long. To summarize: Use FOX if you need C++ and good design. Use wxWindows if porting from MFC or if native controls are important. Use Swing if speed is not a problem, but cross platform really is. Use Cocoa if you only care about MacOSX and need to get something out quick. I actually prototype some UIs in Interface Builder on MacOSX, which says a lot.
Heh. I'll chekc out sporks r us.
Cheers man.
It would seem to me that the whole reason for .Net was to port vendor lock-in to new platforms in case Windows died and also to try to compete with Java. Now that Microsoft is being forced to stop distributing a sabotaged variant of Java and to instead distribute Java as specified in the original contract, Java is even more useful.
Beta is broken and the link to classic doesn't work. Stop wasting our time or there won't be anybody left here.
How do you tell if the typing is weak if there's only one type?
I am the lying goatse redirect warning troll, who posts goatse redirect warnings under legitimate posts. I can assure you that the parent warner is not me, and he is not a lying goatse redirect troll. That eliminates some of the possibilities, and while it does not determine whether or not he is a hall monitor, it does prove that the link you follow by clicking on the words "hall monitor" in the parent post leads to goatsex! be warned! DO NOT CLICK
With such a control over the hardware, you are allowed to bypass the XWindows system, which kills the performance in such desktop environments as KDE and Gnome. Painting directly to the hardware buffer, buttons and other widgets can be responsive in a unique way.
The only common manner across all major platforms, BSD, Linux, yes, even windows that you can do this is via DirectX. Compiled binaries can be ported cross platform due to the quality of the cross platform implementations.
Not only this, but the breadth of the system allows realtime multimedia eventing systems, such as audio responses to important system events. Platforms such as NT incur an inherent delay, but not when using directX.
dominionrd.blogspot.com - Restaurants on
Hey !!!!
l
Wake up
-make 1.5x
-base 1.5x
-gui 0.8x
-backend 0.8x
Supported Platforms:
http://gnustep.org/information/machines_toc.htm
And you don't need X or whatever on non-*nix.
It is also mostly Cocoa (MacosX) source-code compatible
...I believe this is the first time
*ducks*
CAn'T CompreHend SARcaSm?
I have been using Qt for the last 1.5 years to develop an application for post-processing of segmented (medical) image data as part of my master thesis. The application is available under the GPL at sourceforge
:-)
During development one major disadvantage of Qt has surfaced, and I think it shows that the Trolltech has choosen a terribly wrong solution to a complex problem.
In order to support their signals-and-slots mechanism (which is an elegant concept, and allows for easy implementation of both the model-observer pattern and the mediator pattern) they have added two new keywords to the language, namely signals and slots. In order to support these you _HAVE_ to run a preprocessor called moc (Meta Object Compiler) for your program to link. But moc does not support templates.
Mostly we have managed to work around this limitation by having a non-template superclass which declares the signals and slots (luckily slots can be virtual) and then have the template parts in a subclass, but this leads to unnatural class hierarchies.
Other libraries have managed to support a signals-and-slots mechanism without such an ugly hack. Both Boost.signals and libsic++ implement them. However their syntax is not as nice as Qt's. If C++ really need even more syntax is of course another question
While not all applications rely upon templates, they have some interesting uses, and if an applications first starts to use them, most classes easily ends up as template classes. See the book Modern C++ Design for "new-school" uses of templates. This could easily be the direction C++ development is headed, and it's a shame Qt will not be able to be a part of it.
Remember Pascal? At one time, Pascal was the major development language. Pascal was taught at all the universities. But, an amazing thing happened. In a period of about 4 years, Pascal died. Hundreds of thousands of people had spent millions of hours learning the particular quirks of Pascal and of Pascal compilers. All of that time was lost.
If you have never lived through the loss of a major direction in your life, you may not even realize it can happen. The people saying I'm a troll in this thread probably haven't seen technology die.
Remember Powerbuilder? At one time there were about 1.5 million active Powerbuilder programmers.
No really, is Java dying? Now, I'm seeing, or think I'm seeing, the same thing with Java. The expected energy and support and standards have not appeared. Or have they? If I'm wrong, prove me wrong; I would like Java to be a success, that would simplify my choices. We bet part of our lives on our choices of specialization.
What frightens me is that there is so little support for GUIs in Java. When programmers don't work to improve their tools, they are consciously or unconsciously deciding that the technology does not warrant improvement.
I've seen Java programs that are unacceptably slow.
Sun mismanagement of Java makes people look elsewhere. The world is beginning to realize more fully that proprietary means, "I'm a dog on a leash; I'll bark whenever you yank my chain; please abuse me."
When you use Java, or any language in a way that is not fully compiled to native instructions, you give away your source code. Sure, what you give away is without comments or variable names, but nevertheless you may give away important routines. That's fine if you intend to make a gift of your work to the world; you should have the option not to do so. There has been surprisingly little work on full Java compilers; until Java has acceptable compilers, it hasn't proven itself. Is GCJ mature?
Visual Basic and Perl are written in C. Should it bother me about other languages that they are written in C or C++? Why not eliminate the middleman? Can an acceptable result for application development be achieved using something like Boundschecker and avoiding pointers and using automatic garbage collection where appropriate?
Slashdot has a moderation problem. You can't comment on and moderate the same story. So, moderators by definition moderate stories that don't interest them much.
Bet wrong and go back to being a novice. As I write this, the parent post has been moderated Flamebait=1, Insightful=1, Overrated=1, Total=3. The question is a real and important one, not a troll. When you pick a technology, you lose part of your quality of life if you are wrong; you go back to being a novice at something else.
If you know better, educate me. If I'm wrong, and you know better, educate me. That's the entire purpose of Ask Slashdot.
The mailinglists are, though high-traffic, very informative and the atmosphere is friendly (hardly any flames, 'dumb' questions are usually anwered with 'check the docs at ....' instead of 'RTFM, you dumbass').
Though the bulk of the wxWindows code is written by a small group of core developers, the development process is very 'open': decisions are often made based on discussion on the mailinglists, and patches usually well-appreciated.
As with QT, wxWindows is also very much worth considering when developing single-platform or even non-GUI applications (check out the wxBase port).
The article seems to be C/C++ oriented.
What about really portable cross-platform languages such as Python? Or is that too easy? Do we really WANT to suffer with C in this day and age?
A cool cross-platform RAG GUI IDE builder:
http://boa-constructor.sourceforge.net/
You surely have no idea what DHTML is, its like flash but in JS/html
Search the web for examples. you can do a lot.
Liberty freedom are no1, not dicks in suits.
Dude visits story in which hundreds of people feel motivated to comment. Dude says that the story shouldn't exist. Who is making a mistake, the hundreds of people who find the story relevant, or the one who enters a story in which he has no interest and makes a negative comment?
You said, "I hope the reply wasn't too long."
I'd be happy to read 50 more pages like you wrote.
I can't believe some other people finally beat me to the obligatory Eiffel plug here. That's quite refreshing actually. I've used Vision2 for some smaller test projects and found it to be an extremely well-written, abstracted library...pretty much like all the other Eiffel libraries.
To be fair, though, it only works on Unix/Windows...leaving Mac OS X out of the discussion when talking about cross-platform is problematic because most people kind of assume that's included in a cross-platform package (witness Mozilla or Opera, for example). Judging by Opera's results, I'd have to say QT does a great job as well.
Here comes the plug....if more people actually found out which features the Eiffel language and libraries offer, there would be a *lot* more people developing in Eiffel....or wishing they could.
I'm working in a small software development company. We have a lot of software (written in Informix 4GL) for console applications. It's more and more getting time to switch over to graphical user interfaces. To make this transition as smooth and easy as possible, we'd like to have a toolkit with which we can write applications that support console mode (curses) and X11 (maybe Windows) mode.
SuSEs YaST2, as an example, does this, but I think they use their own toolkit and their own (strange) scripting language for this.
It is really, really nice. You can have abstract definitions of your GUI in terms of "commands", but you can control every pixel if you want to.
It was a joke.
Laugh.
P.S. - No one said ANYWHERE the story shouldn't exist. It's a follow-up from a story two years ago, it SHOULD exist. All I said this was the first time
The only thing that makes my humor worse than it already is: having to explain myself to hungover AC trolls at 5AM.
And just to be on topic: I have never used any of the mentioned libraries because I never had the need to make my code cross-platform. If I did, I'd probably choose QT or Tk, as I have heard lots about them, and KDE 3.0, which, I'm told, is based around QT, and I find it quite impressive.
CAn'T CompreHend SARcaSm?
As I read the question, it was about a cross-platform toolkit with native look-and-feel. I definately interpret this as being native to the platform where it's run, not native to the toolkit! Otherwise the statement would be meaningless.
The discussion has, as usual, talked a lot about Tk, which has it's own look-and-feel and therefore certainly not is native. Qt is cross-platform, with applications that look native, but necessarily aren't.
There's more to a platform's look-and-feel than how the buttons look. The location of the menu-bar is one example. The placement of OK/Cancel buttons another, and standard quick-keys a third. Mac OS X has GUI guidelines which specify how far apart different controls should be, and they are almost guaranteed to not match KDE's guidelines.
Mac OS X/Cocoa also has the concept of sheets, which are basically modal dialogs attached to one certain document window in an application. There's no similar concept in e.g. Gnome, and a toolkit would therefore be hard pressed to find a replacement within the native look-and-feel. In fact multi-document applications in their entirety are differently handled on Windows, Linux and Mac. And I don't even think Gnome and KDE agree on all details of look-and-feel.
Cross-platform with native look-and-feel is therefore a lot more complex than just using Qt or Tk. What would really be needed is actually a way of abstracting away the GUI part of an application entirely, basically making the entire presentation into a Stylesheet of sorts, somtehing like what you do to strings and numbers for i18n/l10n.
But I haven't seen any real efforts to do this. It might work without it for Linux vs. Windows, because neither have very strongly enforced standards on look-and-feel, and you can therefore get away with doing things almost right (or even doing them wrong).
For anyone starting a new project from scratch I would advise not to use MFC as this product is being discontinued. Bug fixes will still be released, but no new features. The product manager of Visual.NET has stated that fact here (if you read between the lines): http://www.codeproject.com/interview/nickhodapp140 22002.asp
For a new project it's much better to choose a library that is seeing real improvement in each release, like QT from Trolltech.
I would just like to point out my experience from using QT for the past two days. It was very nice and straightforward to learn. I am trying to port my old motif-based application to QT and so far I have made some real progress after a day of reading the documentation and tutorials. In the field of widget interaction, QT's signal and slots model really rocks compared to callbacks (GTK still has callbacks). No more trying to double check your callback's parameters to see if it matched the calling widget and get screwed in the process.
Creating custom widgets too is a pure pleasure - subclassing really is a gift!
...Just some of the nice things you get with QT not to mention you get a free excellent GUI desinger plus excellent documentation.
I've have been using QT for the earlier stages of my Master's Degree project. This article got me thinking about the licence, which suggests I must make the source available with any binary distribution.
This maybe problematic seeing how the copyright would be shared with the college. I think I'll give wxWindows a try since it has no such requirement.
"Ceilean Súil an ní ná feiceann..."
1. Is it possible to implement SWT in Qt? 2. If it is, I think Eclipse could easily be ported to more platforms. 3. ???? 4. Profit!
>> The problem is that it's only available for Windows and Linux, and since the underlying code is native, it has to be separately developed and maintained. Which version are you talking about? I am running Eclipse 2.0 right now, and it works fine.
Since HyperCard died and C++ didn't make life any easier, java is still so ugly duck, i turned to MetaCard for all my coding needs. It's HyperCard's next evolution - fast, easy, light and I know very few limits whether in number of platforms supported, compatibility, range of applicability, or even depth of project structure... You're limited only by your imagination with this product! Since the IDE is made out of itself, you can customize it to the gut like RunRevolution did.
I don't understand why so many people even mention MFC.
.NET frameworks (or whatever it's called). And finally, it's just a piece of shit.
First of all, we are supposed to talk about cross-platform GUI tools here, how does MFC fit the bill? Secondly, even MS has given up MFC and moved on to the
I'm developing an in-house project on the Windows platform but currently having Max OS PRE-X (9.x) target. I'm learning the hardway that swing simply doesn't work well, and SWT isn't and won't be available.
I do not have a development Mac, so I chose Java. I like Java a lot, but it's also giving me a lot of headaches right now.
Stupid sexy Flanders.
Rendering the GUI afterwards strikes me as a good idea - if you have a good infrastructure.
see http://www.seagullsw.com/products/jwalk.html
x-platform gui client --> best-of-class-server
might be too obvious.
shame no mac os x support...
Not my favorite platform, but what I'm stuck developing for: Mac OS 9.x. There are a lot more of these around than Mac OS X boxes, and unfortunately our upgrade plans here do not include OS X, even on new boxes, because of older software requirements.
To make matters worse, I don't even have a Mac to develop on, so I'm relying on the write once, run anywhere philosophy. I'd really love to use eclipse and SWT, but as long as one of my target platforms is Mac OS 9, I'm SOL.
I don't think it's that uncommon for Java programmers to have only one platform to develop on, even if they have multiple target platforms. That was supposed to be the promise of Java. I don't know who to blame, Apple or Sun, for abandoning Mac OS 9, but it's done and I'm stuck.
Stupid sexy Flanders.
Isn't that like a bar that plays both types of music: country and western?
We've been using QT for Mac & Windows for a while now, and it rocks!
D eptID=PROD
Also, if you're looking for a job doing QT development, we're hiring!
check out
http://www.tomsnyder.com/about/au_work_depts.asp?
Don't forgot that Chimera is native Cocoa. Notibly Chimera was the fastest OSX browser before Safari, but in this case native (proprietary) beat native (public).
w2^8me out.
w2^7me out.
I've seen alot of people joke or laugh about VB style GUI creation, and I can't help but think thats wrong. Actually if you look closely at winForms (.NET GUI), its actually fairly well architected. If ximian gets mono working on linux (and im pretty sure they will) its a really impressive piece of tech. Keep in mind, it becomes not only multitarget, but language neutral, so any language that hits the CLR can make use of the WinForms UI... no need to write custom bindings, etc... As of now, in terms of targets, I believe that winForms can run on all windows flavors, WinCE, SmartPhone2002 and the web (ASP target). If mono suceeds, you can add Linux to that target list, plus shortly after probrably Mac and Solaris... once its supported on linux, it should be a no brainer to port to any other platform. Granted, its not the be all end all user interface... but... the fact its code driven, unlike that black box magic crap VB (7) used! I think in time you will find WinForms becoming more and more popular. Another interesting point, is the newest VisualStudio.NET allows C++ to use WinForms as VB and C# do! Also, I think you will see that MFC is as good as dead. If you look at the most recent update, and the number of advancements and changes they made to MFC... well, theres something like 5! Im guessing MS just wants MFC to roll into a corner somewhere and die. Not such a bad idea in my opinion!!! Ive always hated MFC
In a previous article...one ignorant due wrote: > Qt: Again, doesn't work on the Mac and doesn't > use native widgets on Windows. He was soooo wrong. Here's the comment from QT Norway....in rebuttle to this... On Wednesday, 22. Jan 2003 07:59 Marshall wrote: > > > FYI: How others rate QT...I think he is bias however...I luv QT...and > what is the big > deal about native widgets on windows....windows sux... > http://ask.slashdot.org/comments.pl?cid=1011628&si d=5809&tid=156
>
Hi Marshall,
thanks for the link; apart from being biased he is also wrong - Qt does
support Mac OS-X, and using native windows is indeed of no practical
importance as long as the toolkit is good enough in emulating the look.
In the end emulating scales much better and allows a lot of things that
are simply impossible when you are restricted to the native widget's
capabilities.
Best Regards,
Volker
--
Volker Hilsheimer, Support Manager
Trolltech AS, Waldemar Thranes gt. 98, N-0175 Oslo, Norway
Finding the best cross-platform solution is certainly always depending on the sort of projekt you are doing. So i have a very specific question.
I am currently working on a game-like private projekt which does use Mesa and Glut. It's now reaching a point where i need a GUI (so far i was just using keyboard commands and put some messages on the screen). At the moment it does run only on linux but could still be ported easily to other platforms.
Which API would you recomment for this task? The API should make it easy to implement some custom widgets. For example, like those popup-menues which you can use in The Sims which surround an object. Also the form of buttons should be customizable with bitmaps (so they can take any form and look as nice as my artistic possibilities do allow me).
or www.fark.com
The main reason it isn't is that the developer kits come out after it does for the other platforms, if it comes out at all- for example, are we EVER going to see java3D on Macs?
What swing text editor do you use? some suck, some are great (both in terms of quality and performance). if a text editor is slow on that class machine in swing, it's not a well programmed piece of code, or something's wrong with your box.
I was looking at this problem a while ago myself. I wanted to use SDL as my base though, so that limited my choices of GUI libraries to either ParaGUI or LibUTA. After playing a bit with LibUTA (which could really use some more documentation), I decided that what I needed was just different enough from what was out there that I should make my own.
While the project is nothing spectacular, I'd like to think that it's become something quite usable in a relatively short time (for having only 2 developers).
For those of you curious enough to take a look at it: http://wgui.sourceforge.net
If nothing else, it's been an incredible learning experience and a lot of fun.
I posted the original question about cross-platform GUI toolkits, for whatever that's worth.
After much investigation, I've concluded that they all suck a little bit in different ways, and that there is no absolutely "right" answer. Since each has strengths and weaknesses, you have to look at the platforms you are trying to hit, and choose accordingly.
That said, I have to say that Qt is very nice in terms of its polish, documentation, user community, and support of Mac OS X, Windows, and X. The only downside I see there is that they emulate the look/feel on the target platforms, rather than using native widgets, and they don't support Mac OS 9.x and earlier.
For my project, my choice is wxWindows, which uses native widgets and supports Mac OS 9.x as of the latest wxWindows stable release. wxWindows has a great user community, has reasonably okay docs, and is pretty simple to get up to speed with.
Oh-- one other option that I have not investigated for a long time is CPLAT. It also looks quite nice for all the same reasons as wxWindows, though CPLAT is far less well known.
Omnis has been around a long time, and it is a fantastic cross platform development tool. Studio is the current product and is extremely object oriented. I have not seen any other product that is as mature and full featured as Omnis for producing cross platform Mac/Windows apps. There is support for Linux as well, and the web client is good and improving.
Anyone wanting a good 4GL Cross Platform tool would be wise to look at this product. The only down side is the company is practically invisible when it comes to marketing. On the plus side, it's been around for years, and hopefully this will be the case for a long time to come. I've been working with it for over 15 years.
Regards,
Lee Snover
lsnover@tplus.com
Look at Studio, works on Windowz, Mac, Linux and Solaris. http://www.omnis.net
I like ParaGUI.
It works on top of SDL, so it is more useful for game development, which is what I'm looking for.
I found it to be simple enough that I can make changes whenever it's lacking something I need.
http://savannah.nongnu.org/projects/paragui/
ANT, (Another Nice Tool) also runs anywhere Java runs. It replaces make files with an XML based build tool. I've written scripts that can check out code from cvs (or PVCS) compile, build jar files, build EJBs, deploy EJBs, stop and restart servers, and email me the results.
ANT can be found here It is also free and open source. Although each of these tools are written in Java they can be used to edit, compile and build programs written in other languages.
Hmm. That's odd, all of the documentation is available via HTML, PDF, and PS. The HTML docs are available online and mirrored all over the place. Dependency issues? WTF? Every distro I've compiled wx on, had everything installed already. This includes Windows. Bugs? You must of tried this 5-years ago or been trying to use unstable-dev versions.
Their docs are horrible.
Hmm. Not really sure what you expect. The docs seem to explain everything rather plainly and clearly. The vast majority of minor gaps are filled in via the samples and demos. Which is to say, unless you're trying to do something really obtuse, you have pretty much everything you need.
Finally, just about everytime I went to use some widget, I found some bug or limitation that made it unusable.
Hmm. Sounds like a design or user issue. Chances are you used a VERY old version (5+ years old, or older) or, for whatever reason, decided that a development version was what you needed to use. The stable releases tend to be just that, very stable and usually bug free.
In wxWindows, I spent the better part of a week just trying to get one simple delegation design working and couldn't do it despite lots of help from people on various IRC channels.
This does seem to support the notion that perhaps there is a bit of a user-issue here.
You also forgot that the Python (wxPython: http://www.wxpython.org) bindings are excellent (getting better all the time) and that there are also Perl bindings to boot.
Some quotes from the wxPython site:
Plus, many other wxPython users truely enjoy using it. If wxWindows were anywhere as bad as you seem to imply it is, it's doubtful that wxPython would be anywhere near as well received. Not to mention the army of happy wxWindows users.
I would highly recommend you check it out again or simply not comment on wxWindows as I don't think your comments are accurate or truly reflective of wxWindows or a typical developer's experience that may seek to try it.
Interesting that you pointed to the "Good Response" that so thrashed Java. None of those claims are valid anymore, any many weren't then. I can't honestly see someone writing a cross-platform anything in C++, since at the very least it requires recompiling on each platform you support.
I still believe (and have since the early 90s) that Java is currently the best (yes, it still has its problems) solution for anything cross-platform. I compile it on Windows, and it works on my BSD and my friends MAC. My Handspring has Java3D on it, and places like javagaming.org show what can truly be done. Hell, I have Java running on my TINI, which is basically a computer on a SIMM.
I think that, until we have true object oriented software (which requires object oriented hardware, which we don't have), Java is probably going to remain the best option for anything cross-platform.
http://www.google.com/profiles/malachid
The reason Abiword acts, looks and feels native on Windows is because it is. It does NOT use gtk on windows. Rather, it uses the win32api through the Abisource Application Framework, a lightweight and crossplatform wrapper created alongside abiword.
It's actually pretty neat.. the source is in (abiword_source_root/src/af). It provides a level of nativeness that can't ever be acheived through something like gtk+, which is (still) quite half-assed on windows.
Is there a GUI toolkit that doesn't dictate design? I want to take an existing procedurally designed program and slap a GUI onto it without totally shredding the existing program to make a bunch of callbacks and plugins for a GUI framework. Is there a GUI toolkit that doesn't expect to dominate the function call tree?
Basically, I want to replace the standard GUI design of "GUI sends message to callback function, gets callback function output and continues processing" with "program calls GUI routine to get data and continues processing". Is there GUI toolkit that will let me do this?
Yeah, sporks: yeah.
Just wondering why, when the topic of browsers as "cross platform platforms" is introduced, people immediately jump to the conclusion that the user would have to be running the one you targeted -- or that you have to be cross-browser?
In the context of this discussion that doesn't make sense to me. If you're building an app with Java, or C++, or any of the other technologies mentioned here you'd ship a complete package. If the user didn't have the libs/jars/etc. you required you'd include them in your installer.
Why not do the same with Mozilla? Just include it in your installer. It's your "XMLVM", providing portable cross-platform XML-programmable application support. It runs practically everywhere, its native programming model is XML-based. It has XSTL, SOAP, XML-RPC, etc. built in, all scriptable as needed using JS and XPCOM.
Within the context of "what can I put in my installer package that costs me nothing but gives me access to the most platforms with a single codebase" I think Mozilla wins hands down.
zefnd,
I said that I would like to read 50 more pages of the kind of analysis you wrote, and a moderator called that a troll. I want you to know that I am completely sincere. I feel I need the guidance. I'm not always sure I am picking the best tool for the job, and the cost of making a mistake can be very high.
It does most of what wxWindows doesm but takes a little more consistant look and feel approach by avoiding the native widgets and having it's own. This makes for very consistant feel on different platforms. Something which I certainly appreciate in my flagship spplication: Scribe (an email client).
need a BSDd crossplatform gui?
then check this one
http://vcf.sourceforge.net/
very mature oss project which i enjoed mutch
Actually, I'm very familiar with Javascript and DHTML; however, you still CANNOT push with javascript. HTTP is a "pull" based technology. The browser sends a request and the server responds. The server cannot initiate a "push" of data to the client browser. This is why there are some things that are very hard to do within a browser, even with Javascript. Flash has the same problem.
Who said Freedom was Fair?
Thats if and only if God is a fool... VB is a tool written by the fools for the fools and to fool the fools even more.
xwt.org - amazing project that is cross-platform and remote as well... worth checking out.
Most companies are _TIED_ to java. Java will not die because most of their applications run on java - applications which are running millions if not billions of dollars of transactions a year. Heck, java will almost be like cobol; you think its going to die, but it just doesn't....
Java is in a different league than pascal, powerbuild, et. al. It works, IMHO, and many others' very well for enterprise server side business CRITICAL applications.... where the money is being created to ultimately pay for programmers salaries... nuff said
-eleison
XWT is a web based GUI engine for creating remote applications - ie native GUI client side and functionality serverside.
I can honestly say it's absolutely amazing. It's responsive and versatile.
It's a proper use of java, a GUI engine that uses an appropriate syntax rather than some crap hack like Swing.
We started with Omnis5 and upgraded to Omnis7, all on Macs. Then the client (major bank) went to NT and we just rolled out the same code on that platform. For a while, we supported both Mac and NT platforms with common code, until the Macs had all been retired. With several years invested in two major applications, they must have saved about a million dollars in rewrite costs. Both applications are solid and reliable and are supported and continually enhanced by a team with a budget of of 1.1 persons per year. Hence very low running costs. From a techy point of view, I love coding Omnis, especially Omnis Studio - it just performs anything I want it to do. But from a businessman's point of view, the long term cost of ownership is superbly competitive.