Slashdot Mirror

I thought the trademark was "Microsoft Windows", not "Windows"

Microsoft sued Lindows over being similar to "Windows". http://en.wikipedia.org/wiki/Microsoft_v._Lindows They ended up losing some early battles in court and then bought them out.

They've also bullied/bribed other projects like wxWindows (now wxWidgets). http://www.wxwindows.org/about/name.htm

Those are just the ones I know about off the top of my head.

WxPerl makes me happy and seems at this point to provide maximum power for minimum effort, and being sufficiently mature at this point in time. VisualBasic has made me very unhappy whenever I have used it in the past.

WxPerl is Perl bindings to wxwindows which itself is a cross-platform C++ based library that can be used from C, or from Python and Perl (and maybe some others). Depending on what you want to do maybe a lightweight language like Perl could make you very happy too.

If you use VisualBasic you may find it possible to get a simple job done relatively quickly but if it ever turns around, bites your butt and grinds your bones between its molars, don't say I didn't warn you. That said, it is certainly possible that it has gotten better than last time I used it some years ago, but to me it reeks. I am biased though, towards Perl and linux. You can look at the successful projects made with wxwindows at wxwindows.org.

GNUstep runs on X11, Cairo, Win32/GDI, and it can also be recompiled on MacOSX.

WxWindows might be able to target lots of platforms, it just does none of them well.

QT on the other hand, is written in a non-standard programming language ("moc C++") in an effort to add features available to Objective-C users for years. Better still: Programming Cocoa in Java or Python isn't anywhere near as unpleseant as writing WxWindows or QT applications in those languages. That's not subjective either.

So being as how GNUstep spans multiple platforms and languages, while WXWindows spans the lowest-common-denominator of multiple platforms and languages, and QT works on less platforms than GNUstep, and in less languages, I'd say that you're completely wrong and have no idea what you're talking about.

That said, I never knew anyone could actually say that this "looks better" than this, but you're welcome to be the first, and if that's how it is, at least I'm productive in the latter...

But I've been wondering what, given the right tools, I might be missing.

I personally like these (well established and well supported)
http://www.codeblocks.org/ // dev kit
http://www.wxwindows.org/ // 2d lib
http://irrlicht.sourceforge.net/ // 3d lib

If it's GUI you're after, you can use the wxWindows libraries (http://www.wxwindows.org./ GUI for: Windows, WindowsCE, GTK, Motif, Carbon, and Cocoa. It also supports C++, Java, python, and perl.

If wxWindows is not your style for the Mac, just use C++. Objective-C and C++ can be merged in a single binary (AKA Objective-C++). Write all your heavy lifting in C++. Write all your views (model-view-controller, anyone?) in Cocoa.

I'm speaking as/for a commercial developer which already has a working port on Linux of a very large and powerful app but can't release because of the license mess the linux GUI/OS is in.

Licence mess? Hmmm...

Have you looked at projects like FLTK, wxWindows, Tk from Tcl/Tk, TIX, the Adobe Source Libraries, or Mozilla's XUL and XPFE etc? It's definitely possible to develop closed-source GUI software on X11 with a range of widget sets without violating licences.

And really, if you're developing closed-source software and want the KDE look-and-feel, you can always purchase a Qt developer licence instead of opensourcing your code.

There is no one-true-widget-set which forces you to open-source your code. The closest thing to a "one-true-widget-set-for-X11", it would be Motif - and even that is free if you're developing for Linux - see OpenMotif...

wxWindows is a well-known very easy to use cross-platform UI API for Windows, among others.

wxWindows is a well-known very easy to use cross-platform UI API for Windows, among others.

future of cross-platform development

You know, after a while, ignorance isn't even amusing anymore. gcc, nasm, qt, gtk, wxwidgets, more, then even more perl, python, ruby, ... ... ...
 

Did I miss something? The OOo website clearly states that it will have native theme integration. All of the screenshots of the betas already show what appears to be full integration.

Apparently the KDE team already has OOo 2.0 native widget support ready.

Unless you can find a reference for that, I don't believe you.

Also cross platform GUI's definitely aren't easy, but they're not a complete nightmare. And just so you know I'm not talking out of my ass I've personally created a GUI abstraction layer that supported GTK, win32, and a custom OpenGL widget library. You just have to think about it before hand.

Yeah it's tough, and yeah you learn a lot along the way, but just ask the Mozilla folks, it's not an impossibility by any stretch of the imagination.

Also, especially now with toolkits like wxWidgets that suddenly becomes a whole lot easier!

And yeah a GTK port to Mac would definitely be cool.

Seeing as you're not a developer maybe you should leave the development talk to people who know better.

He's more likely to be talking of GCC, cross-compiling, and the Qt and WxWindows toolkits.

.Net (in the form of Mono )is making significant progress on non-Windows platforms as well.

try wxruby or wx* that way you can switch or combine languages and still use the same window tool kit.
wxw
wxruby

If you want to migrate a single application from VB use Gambas. The languages are quite similar which will make the transistion much quicker and doesn't need as much new knowledge.
OTOH if you want to migrate a business task from VB and are prepared to actually rewrite whole applications use wxWidgets (it's been called wxWidgets for some time already, read this document) with whatever language you want, binding for many common (and not so common) languages exist. Use C or C++, use Ruby or Python or Perl or even use JavaScript ;)

You don't need to pay anything to have access to a very broad spectrum of OS widgets when developing for Windows (or the Mac), no matter if you are developing in a traditional commercial sense or using any other financial model.

Under Linux XFree, you can use GTK+, fltk, wxWidgets, Java, C# w/Mono, or even straight xlib. Again, the only environment that has any type of stupid restrictions is KDE/QT, so stay away from KDE/QT if you don't want to pay a fee. Under Linux, GTK+ applications run just fine under any other desktop environment, including KDE/QT. I personally think the KDE team made a _huge_ mistake when they pick QT. To require a commercial license for native desktop tools is just stupid IMO. However, there are _plenty_ of other great toolkits like GTK+ that have none of those restrictions. With GTK+ you can develop OSS or closed, the choice is yours.

Under Windows, you also have the option of using an older, very much less expensive version of Visual Studio -- those are still 100% functional and produce fully functional applications under XP (and 95, 98, 2000, and NT) and I see no reason they won't remain so.

I think that if Linux ever matures enough to "come with" a standard, always-there, reasonably modern GUI-API such that software can be directly written to and for it

There is no single "utopia" OS or development environment. Trying to single out just Linux makes you sound naive, especially when the MS windows development environment has just as many quirks.

even slower than it's already glacial performance

Drop the apostrophe in "it's", unless you meant "slower than it is already glacial performance". That doesn't make any sense to me, but perhaps it does to you.

there aren't any CS departments that base their courses on Java, who cares about java

As horrible as the idea may be, there are a number of CS departments that made the Java switch during the big Java boom of the late 90s. My alma mater did the switch, though luckily I was always at least a semester ahead of Java changes.

Seriously, we really need a suite of JAVA tools, like word processors, spreadsheets, web browsers, etc... No more of this "well, it works on Windows, if you want it on Linux or Mac though we'll have to sit down and write it all over again, and probably introduce a ton of bugs....." stuff.

Just as soon as Java gets a good, cross-platform widget set, this can start happening. AWT and Swing aren't it. SWT is the right way to go, IMHO, but since it's not built into Java, it'll never have as much acceptance as AWT or Swing, and Java on the client will continue to be judged by those crappier toolkits.

What good is a program that depends on exact versions of 50 libraries (yeah, like I'll be able to reinstall that in 5 years and have even an outside shot at it working) and only works on a couple platforms, if you're lucky.

Java has the same problem. The Java base librraries are good, but there will always be something you want or need to do that the default set of libraries doesn't supply. What do you do? Well, just like a C programmer, you find a library that has already done what you need, and you use that. As for portability across platforms, you still have to worry about differences in the JRE for each environment and if you make any assumptions about a particular platform (paths, for instance). Java gives you the possibility of being portable, but it doesn't guarantee it.

when you make your own custom hacked windowing system to speed the process (Mozilla), it ends up being a slow RAM hog, even more so than it would be if it was written in JAVA, or another portable language to begin with.

The problem is not writing your own custom hacked windowing system (which XUL isn't -- it's a custom hacked widget set; the difference being that a widget set is the stuff inside the window, while a windowing system handles the windows themselves and doesn't much care what's inside), but writing your own custom hacked system stupidly. Mozilla's XUL is written stupidly, because it doesn't use native widgets (hey, sounds like Swing!). If the Mozilla developers would lose the ego, they would find that there are a number of good cross-platform widget sets (Qt, wxWindows (or wxWidgets, I guess they're calling it now), or even GTK+, though that would be my very last choice for a cross-platform widget set). Instead, the Mozilla team created Firefox when people complained about the weight of the Mozilla suite, yet they left XUL in place. At least there's Galeon, K-Meleon, and even Konqueror (since it can use Gecko as a rendering engine) available as native-widget web browsers.

Check out wxDesigner.

We already know that AOL has worked to integrate the IE engine into Netscape, has reworked the winamp core into a new AMP player using XUL for the interface, and implemented an AIM client in XUL. That appears to me to be a very consistent plan to integrate all their products / acquisitions into a new internet suite, based on Mozilla XUL.

No, the AMP is using wxWindows, not xul.
from Henrik Gemal's blog

I'd like to see more heavy-hitter funding and support for tools for writing cross-platform applications like the mono project (http://www.mono-project.com/) and wxWidgets (http://www.wxwindows.org/.

I'd also like to know how much and in which ways it differs from wxWidgets

There is another choice for native GUIs using C# on Windows, Linux, and OS X: wx.NET, bindings of the wxWindows library to Mono and Microsoft's .NET implementation.

wxWindows is great because it gives you a uniform API across different platforms and toolkits, while at the same time using native widgets and giving you access to platform-specific features if you like.

For UI stuff, check out WxWindows I am doing a project that I am coding the same functionality in various languages and it seems to work well. Ruby, Perl, Java (I think), C++ and the choice of the "there is exactly one right way to do things and we like it that way and you should too" crowd - Python.

As far as perl/python/ruby for UI, I am sure the performance can't be that much worse than many Java apps, its just that perl hasn't had a good xplatform tool like WxWindows before. Ruby feels a little more natural for the UI stuff I am doing because of concurrency being built in to the language.

I wonder if there are any forth GUI programs, I wonder how fast those run...

You don't ----neeeeeeeeed----- MFC, and in fact I would advise you to stay the hell away from it.

Use wxWidgets, or some other framework instead. For fun, why not try something like ClanLib...

MFC is godawful. Once you've tried a few of the other frameworks that allow you to write cross-platform GUI code for Windows, I doubt you'll disagree with me ...

I've used wxWidgets for 7 projects, and I can't say I've ever had problems with bugs that I couldn't just fix myself, and contribute back to the main source tree.

Try that with MFC ...

As for the docs, you must need a lot of hand-holding if you think the wxWidgets docs are incomplete. I'd sure like to know what you found lacking ...

And/Or some of the other interesting OSS API's ...

Your list will get bigger, though you might have to shuffle a few things around.

If you come from an MFC background, you should give wxWidgets (Formerly wxWindows) a try. It's quite similar, but lacks much of the insanity of MFC.

All they ask is that someone give them a first-class GUI toolkit at no cost, and with no strings attached! Is that so much to ask?

Sounds reasonable to me.

For those who use GUIs, Java is not cross-platform. Java requires Java to be installed, and it isn't installed on recent copies of Windows. "Cross-platform" is not completely true.

I haven't been doing (much) cross-platform programming, but I'm intense about finding an acceptable way. I predicted the downfall of Novell long before it happened, and now I'm predicting that Linux will eventually become the only commonly used desktop OS, due to the fact that Microsoft managers do not seem to be able to find a way to live in the world without being abusive. Now is not the time to write a lot of Microsoft-specific code.

C++ with WxWidgets (formerly WxWindows until they were threatened by Microsoft) seems the best way.

However, the real answer is for Java to become useful for those who need extensive GUIs and fast execution. It's obvious that Java is on the right track. Programmers of business applications don't want to worry about memory allocation.

Microsoft is forcing the 12-year-old wxWindows project to change its name as well, on account of claimed infringement on its Windows(R) trademark. Probably as a defensive maneuver in its ongoing suit against Lin---s.com.

This is exactly what MS will do. How freaking naive can MS weeines be? MS is all about dominating a market. Big deal if C# the language is a standard. The platform is what matters and MS controls their .Net platform. People/Companies will code to that MS .Net platform and leave all other platforms out of the game.

If you want a cross-platform framework, use Java. If you want a cross-platform application, use wxWindows or QT

In the most recent Linux Magazie or Linux Journal (I don't recall which since I get both), I just read that many analysts are predicting that Linux will have at a minimum 45% of the server market share by 2007, only three years away. If Linux gets that kind of market share within 3 years, don't you think MS will continue to do whatever they can to continue to lock customers into their platform? Why do you think MS ported their C# compiler to FreeBSD over Linux?

Again, C# the language is open and you or anyone else can create a compiler. Big deal, you can now compile your first Hello World! C# applications. The commercial C# applications will be built on .Net and limited to MS Only.

Is there anyone out there that actaully thinks MS would develop a true cross-platform solution? Can their be a human that is that naive?

...cross-platform GUI applications. (a good thing for Linux adoption by the masses) And Mono is way off for doing that.


And for cross-platform GUI development for those of you that realized the honeymoon with Java is over: wxWindows.

For wxWindows users, there is also wxMozilla.

At several times in my career I would have simply gone with Qt but for the price and my unwillingness to be forced into releasing my code for free (freedomn is important even for developers). I mailed them and they won't even allow you to develop with the free edition and deploy with the commercial edition. Good luck to Troltech, their bottom line probably matters most.

Why should they give you their software for free if you're not willing to subsequently give your software for free.

And of course their bottom line matters you dope, how else are they going to pay the 80 odd staff they have working on a toolkit for Windows, Mac and half a dozen Unices.

Grow up, and if you can't grow up, try wxWindows - coming soon to Borland C++ Builder X

When I tried QT for Windows last time, perhaps a year ago, it did not appear use the look and feel of the Windows platform, despite the company implying that QT adjusts to the native platform. If they would use actual native widgets, then not only would the user interface automatically change as the Windows controls are updated, but it would also at all times feel like a true Windows GUI -- because that is exactly would it would be! It's possible that QT's architecture is not well suited to mapping the controls to the native API, but I think that is a crucial feature for a lot of people. So far, VwWindows seems like a better choice IMHO.

On Linux, you would have to implement every one of those things yourself

In that case, I would recommend wxWindows. It is a great cross-platform C++ GUI toolkit. It uses the the native widgets under MS Windows and Mac and uses GTK+2 under Linux. I personally think it is better then QT and you can run it under non-Linux platfroms without having to pay a fee to TrollTech.

meanwhile ...

• wxPerl
• wxPython
• wxBasic
• wxLua
• wxJavaScript
• wxJava
• wx4j (alternative Java binding)
• wxRuby
• wxEiffel
• wxHaskell
• wx.NET (C#)

[for those who don't see it DAldredge mentioned what i forgot]
like DAldredge said - wxWindows doesn't cost you money, ever. And your comment about "maybe you get what you pay for" is absurd.

SciTech Display doctor was written using wxWindows - here is a screen shot: http://www.wxwindows.org/screen50.htm

Even AOh3ll uses wxWindows in their apps

It has backends for qt, gtk, ms-windows etc. Trouble with it is that it adds an extra layer of complexity for the programmer and dependency for the end user.

I want Mozilla and OpenOffice to use a widget set of my choice (no matter which one I choose - qt, gtk, gtk2 ....)

btw, it reminds me of wxWindows - a set of tools that allow you to compile your programs under different OSes using native widget sets of your choice. All widget sets are supported, but the widget set is chosen during compile time.

The API isn't quite as nice, clean consistent and well-documented as Qt, but it's definitely not bad, and I've written some fairly complex GUIs with it before. They look and feel truly native, though it may take some minor tweaking to get everything perfect on all the platforms you are targeting.

The OP wrote:

The commercial issue with QT is really a non-issue. It might even be possible companies and write inhouse software without paying a license fee (since the code is never redistributed.) If companies want to make money writing with QT they will. What do *companies* want, to pay a fee to QT and own their own code, or give it away with the GPL and Gnome?

I wrote:

I think you're confused here. Qt (pronounced "Cute" not to be confused with QT which is the abbreviation for QuickTime) is dual licensed under either the GPL or the Trolltech commercial license. Qt costs a lot of money to use commercially. IIRC, Trolltech wants like $1k a seat or something ridiculous like that. Your other option with Qt is to use the GPL. So, what do *companies want*: to pay a fee to Trolltech and own their own code or to avoid the fee and "give it away" with the GPL and the GPL-licensed Qt.

You wrote:

The original poster wrote about in-house. The GPL doesn't force you to make your application available to everyone in the world. It just says that if you do so, you also have to include the source. You can do contract-work using GPL'ed libraries, the only string is that you have to hand over the source-code to your client as well (something which every reasonable client should demand anyways).

So, as you can see, while the OP opened the paragraph talking about in-house software he closed it by talking about software for sale. I was responding to the latter part.

However, the fact still remains that the client who purchased the in-house software is clearly free to redistribute the source code to others which while unlikely may or may not be acceptable for those writing in-house software. For example, let's say I write an accounting package and charge the client a lot of money for it (since it was a lot of work). Let's say part of the contract is that the client has a copy of the source code (I agree, this is reasonable). If I don't use any GPL software I am free to tell the client that they may not redistribute the source. If I do use GPL software as part of my product I now have to distribute it to my client under the GPL. The client may now legally redistribute the software to a third party and neither of them will have to pay me a dime more. One way to get around this is to put a clause in the support contract stating that if the code is redistributed then the support contract will be terminated and money will not be refunded. This would not conflict with the GPL legally (as far as I can tell) though it certainly conflicts with the spirit of it.

There is also this other sticky issue of clause 3b which essentially means that if the developer doesn't do 3a (distribute source alongside the object code) then he must (emphasis added) "Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code[...]"

Ouch! That means that if I don't give my client source alongside the binary then I must give them a written offer that states they or anyone else in the world can request it directly from me.

The GPL makes a lot of sense for applications and I can see where it makes sense for libraries that you want to limit to free software use. However, for a GUI toolkit (of which there are plenty of alternatives) it really makes zero sense to release under the GPL and force commercial developers to choose a different toolkit or in the case of Qt pay for a commercial license. If you want it to be widely adopted, then using GPL licensed libraries is simply not an option. Stallman tells you this much in the text of the LGPL (it's the reason it exists).

Personally, I use and develop wxWindows wh

With wxWindows, there is no need for a commercial license fee to QT. wxWindows would be the perfect toolkit for UserLinux. One of the main points of UserLinux it to be FREE as in cost. Large IT industry corporations will all help fund the development efforts of UserLinux. Out of that funding they will get a FREE as in cost, Linux distro that they can develop their applicaitons for and offer their services on. QT takes away that whole FREE as in cost, situation. So those IT corporations that will be funding UserLinux will pay for UserLinux development and then have to turn around and have to pay to be able to develop on the platform that they funded. That doesn't make sense to me.

It appears that UserLinux will be targeted at corporations. Corporations use many, many closed source, proprietary applications. UserLinux NEEDS to make a way for those proprietary applications to get onto UserLinux without those proprietary vendors having to give up their source. I am all for Open Source, though it will take time for companies to realize that seeing their source code will not destroy their business. Until/if that happens, UserLinux need to provide a way for those vendors to deliver applications. Picking ONE desktop and GUI toolkit/API is an important step in that process. Allowing those vendors to not have to pay extra to just use that toolkit/API is another important step IMO. According to Bruce, he is working with IT companies who plan to support (read give money) to UserLinux to keep it going. They want to do that because it will be much cheaper to split the cost over many companies. The IT companies also want to be able to deliver their applications/services to the UserLinux platform. They are already paying for the development of UserLinux, it seems silly to turn around and tell them that they then have to go and pay TrollTech to use the native toolkit. Another issue is that UserLinux can customise the packages according to the supporting companies needs, including making changes to the native GUI toolkit. UserLinux will not be able to make those change to QT. IMO, UserLinux should use wxWindows as the native GUIL toolkit. Then you can have an excellent C++ toolkit that also works great under MS Windows and Mac. wxWindows also allows companies to develop Open Source or Closed source applications without the need for extra licensing fees.

> wxWindows ... looks awfully like Windows APIs.
> (I may be wrong, though)

Seems like I wasn't:
"Porting from MFC is particularly easy due to its similarity" wxWindows Intro.

So does wxWindows and it can be used to develop commercial or Open Source.

class templates cannot have signals or slots

Multiple inheritance requires QObject to be first

Function pointers cannot be arguments to signals or slots

Friend declarations cannot be placed in signals or slots sections

Signals and slots cannot be upgraded

Type macros Nested classes cannot be in the signals or slots sections nor have signals or slotsacros cannot be used for signal and slot parameters

Constructors cannot be used in signals or slots sections
www.wxwindows.org, IMO is better then QT and can be used to develop Open Source as well as closed source, propreitary applications. There is an impressive list of people using wxWindows including commercial companies such as AMD and Xerox who uses wxWindwos. The feature set is impressive as well.

class templates cannot have signals or slots

Multiple inheritance requires QObject to be first

Function pointers cannot be arguments to signals or slots

Friend declarations cannot be placed in signals or slots sections

Signals and slots cannot be upgraded

Type macros Nested classes cannot be in the signals or slots sections nor have signals or slotsacros cannot be used for signal and slot parameters

Constructors cannot be used in signals or slots sections
www.wxwindows.org, IMO is better then QT and can be used to develop Open Source as well as closed source, propreitary applications. There is an impressive list of people using wxWindows including commercial companies such as AMD and Xerox who uses wxWindwos. The feature set is impressive as well.

class templates cannot have signals or slots

Multiple inheritance requires QObject to be first

Function pointers cannot be arguments to signals or slots

Friend declarations cannot be placed in signals or slots sections

Signals and slots cannot be upgraded

Type macros Nested classes cannot be in the signals or slots sections nor have signals or slotsacros cannot be used for signal and slot parameters

Constructors cannot be used in signals or slots sections
www.wxwindows.org, IMO is better then QT and can be used to develop Open Source as well as closed source, propreitary applications. There is an impressive list of people using wxWindows including commercial companies such as AMD and Xerox who uses wxWindwos. The feature set is impressive as well.

Here.

I hear you can get a native, Trolltech-provided Qt 3.2 Windows free edition on the CD-ROM that comes with the upcoming re-edition of the Qt book, too, if you can't want for the above project to reach completion.

Otherwise, a decent alternative is wxWindows (not as clean and elegant as Qt, and thus requires a bit more code for a given task, but still very decent, don't worry).

Thank you.