Slashdot Mirror

WxWindows, now known as WxWidgets.

Other notable minor changes (yes, I noticed the oxymoron too):

-because it breaks the main font app when the app is running on XP (likely an MS bug).
+because it breaks the main font app when the app is running on XP.

They don't want MS to be associated with bugs?

- // The Windows API sometimes fails to indentify the file system correctly so we're using "raw" analysis too.
+ // The Windows API sometimes fails to indentify the file system correctly (observed under Windows XP) so we're using "raw" analysis below too.

Alright, maybe they're okay with XP taking some heat, as long as Win 7&8 are implied to be better.

-- Microsoft Visual C++ 1.52 (available from MSDN Subscriber Downloads)
+- Microsoft Visual C++ 1.52
...
- header files (available at ftp://ftp.rsasecurity.com/pub/...)
+ header files
...
- wxWidgets 2.8 library source code (available at http://www.wxwidgets.org/
-- FUSE library and header files (available at http://fuse.sourceforge.net/
- and http://code.google.com/p/macfu...)
+ wxWidgets 2.8 library source code
+- FUSE library and header files
- RSA Security Inc. PKCS #11 Cryptographic Token Interface (Cryptoki) 2.20
- header files (available at ftp://ftp.rsasecurity.com/pub/...)
- located in a standard include path or in a directory defined by the
- environment variable 'PKCS11_INC'.
+ header files located in a standard include path or in a directory
+ defined by the environment variable 'PKCS11_INC'

They're trying to make it harder to find what you need to build your own binaries?

Also, when did /. start auto-creating links? Yes, I used preview and actually edited my post before submitting. Although now since I said that, someone will point out a typo somewhere in my post.

You have options. Cross platform options (for Win, OSX, iOS & Android) that you can use...

- Mono C#

- Delphi Firemonkey (My personal preference.)

- wxWidgets

- other web related technologies that I've heard of but don't use.

Not that I can't get a joke but actually, there is wxQT (albeit in a pretty preliminary state AFAIK, but then I've never really looked at it myself).

Their website has a list of users. It's more than a few.

Good call... so in other words, something use something like http://www.wxwidgets.org/ for cross-platform development while still hooking into native widgets?

Windows, Mac & Linux with a similar UI

The first sign of a lousy port. Try instead: Windows, Mac & Linux versions, with UIs that fit each system's UI guidelines.

I hope you're not serious. If you are, wxWidgets does exactly what you say is the sign of a lousy port and fits each system's UI guidelines.

My fellow supporters of market-friendly free software licenses (as opposed to the commie GNU crap) will be happy to hear that BitcoinJ has an Apache license, and hopefully it will be able to run on the Apache Harmony JVM in addition to the restrictive GPL one from Oracle.

The original Bitcoin client also has a Copyfree license, but it has some restrictive dependencies (ex. wx) and it's a pain to install on *BSD.

About that empty link in the last sentence of the summary - did the author intend to link to a story about commie thuggery against the Liberty Dollar?

wxWindows is not a GUI element. It is a GUI framework/toolkit and a software product. The wxWindow widget never needed to be renamed.

That does not mean you cannot use "windows" to describe the GUI element

Microsoft is still trying to prevent exactly that. The wxWidgets GUI toolkit used to be named wxWindows. They did not use the courtrooms but I doubt the change was entirely voluntary, I suspect wanting to avoid potential legal problems was a large part of the decision. However, I have not read their mailing list archives so I might be wrong.

I second the suggestion about Qt.

There used to be some reservation about Qt in the community, but now its available under LGPL (and also commercially if you want).

There's a screen painter along with a free IDE (Qt Creator).

Qt is on mobile phones, car computers, Mac/Lin/Win, etc.

> I also would love if it had the ability to understand what platform it is on and adjust to have the "feel" of the native OS.
They claim "Native Aqua look and feel, with Aqua-style widgets" (Qt for Mac)

Btw, there's also another popular cross-platform graphics toolkit called WxWidgets. A lot of apps use that (with C++ and Python)

...on how to get your rendering context setup in Linux. Here are a few:

http://www.wxwidgets.org/docs/tutorials/opengl.htm
http://projects.gnome.org/gtkglext/

Beyond these, NeHe still applies. The exception are operating system specific APIs like playing sound, but those have nothing to do with OpenGL. After NeHe, you may want to consider using shaders, which are covered in the Orange Book:

http://www.3dshaders.com/home/

wxWidgets is rather dated, though, and that's by design, making for rather awkward API. I mean, have a look at this:

"wxWidgets does not use templates (except for some advanced features that are switched off by default) since it is a notoriously unportable feature."

In 2009! Notoriously unportable, seriously? Basic template stuff (enough for generic containers, for example) has been perfectly portable since late 90s! But no, they don't want templates, which is why you get to write gems like:

class Foo { ... };
 
WX_DEFINE_ARRAY(Foo, FooArray);
 
FooArray foos;

I'll take Qt any day, thanks. It doesn't look any worse than wxWidgets in terms of "native" (even if it achieves that differently), but it's much more powerful, and the API is better. Now that both are LGPL'd, I really don't see any advantage wxWidgets might have.

wxWidgets is rather dated, though, and that's by design, making for rather awkward API. I mean, have a look at this:

"wxWidgets does not use templates (except for some advanced features that are switched off by default) since it is a notoriously unportable feature."

In 2009! Notoriously unportable, seriously? Basic template stuff (enough for generic containers, for example) has been perfectly portable since late 90s! But no, they don't want templates, which is why you get to write gems like:

class Foo { ... };
 
WX_DEFINE_ARRAY(Foo, FooArray);
 
FooArray foos;

I'll take Qt any day, thanks. It doesn't look any worse than wxWidgets in terms of "native" (even if it achieves that differently), but it's much more powerful, and the API is better. Now that both are LGPL'd, I really don't see any advantage wxWidgets might have.

I've developed Windows programs on Linux using Python and WxWidgets. WXwidgets will use the underlying OS'es toolkit to actually render the GUI, so it uses Cocoa (Carbon in development) on OSX, GTK on windows and the native Windows toolkit (who'se name I don't know).

Has worked perfectly fine for me, both for developing solely for Windows from Linux, and for developing cross platform code that looks native on the three main OSes. Coupled with py2exe and py2dmg, binary distribution and installation is a breeze!

If you want "close to the metal" POSIX API compatibility then there's Cygwin which is easier to use IMO and more actively developed but doesn't support the *full* POSIX spec or there is UWIN which supports most of the POSIX spec.

Combine this with OpenGL, OpenAL, the SDL and Cygwin/X, QT, a Java layer using the SWT from Eclipse, *shudder* GLUT *shudder* ;) or IMNSHO preferably wxWindows/wxWidgets and you've got yourself a full cross-platform programming toolkit that can do just about anything.

jdb2

Show me their standardized network...

http://www.boost.org/doc/libs/1_40_0/doc/html/boost_asio.html

...threading...

http://www.boost.org/doc/libs/1_40_0/doc/html/thread.html

...GUI...

*shrug* There's not a *standard* GUI, but there are a few high-quality ones:
http://qt.nokia.com/
http://www.wxwidgets.org/
http://www.fltk.org/

(I should probably keep this in a text file on my desktop, it's a "batch of advice" which I frequently have to re-write, and it doesn't change much)

I mentioned the term "modern C++" above, though really it's better to call it "sane C++". By this I mean C++ that won't drive you nuts trying to figure out what went wrong, when something inevitably *will* go wrong. Practices that make programs more safe, and introspective.

If you already know C++ (the foundations, I mean), it'll be easier to shift to STL-dependent C++. If you're completely new to C++, these resources will still be very important, but you'll need to learn the lower-level stuff in parallel, so you can understand how STL containers/templates are built from the inside (which is important when you need to choose which ones to use).

A website that should very often sit in the background while you're coding/learning: C++ FAQ Lite. Following these rules will make it much easier to design and maintain your programs.
Another very useful website: cplusplus.com. It's a huge reference site, with a lot of examples.

The books I'd recommend:
Accelerated C++ -- higher-level to lower-level approach.
C++ Coding Standards -- similar to the C++ FAQ Lite in the nature of the advice, but covers more ground and is probably better organized.
C++ Common Knowledge -- This is for a few months down the line, delves into some nuances.

Software:
Windows: Visual Studio C++ Express -- You can force it to stick to ANSI C++. It's still the best IDE for C++ on windows (IMO).
Linux/Mac: Eclipse, probably Eclipse IDE for C/C++ Developers. Remember though that you can tweak Eclipse into just about anything.

If you're writing end-user applications, keep in mind two frameworks: Qt and wxWidgets.

Quick note about Boost: If you can create a structure using some combination of STL components, do that before resorting to Boost. Boost is highly abstracted, and you should only use the parts which would otherwise be extremely complicated to create from scratch (like regexp).

It is when used on GTK systems.

From wxwidgets.org:

wxWidgets lets developers create applications for Win32, Mac OS X, GTK+, X11, Motif, WinCE, and more using one codebase. It can be used from languages such as C++, Python, Perl, and C#/.NET. Unlike other cross-platform toolkits, wxWidgets applications look and feel native. This is because wxWidgets uses the platform's own native controls rather than emulating them.

When it's done, I expect it to run equally well in any environment (that supports Perl & Tk, which is A LOT). Try that with Visual Studio. I bet you can't, because V$ was deliberately engineered to make it as difficult as possible to develop for any non-Imperial target.

Not true. VS is just an IDE, although it is of course strongly geared toward Windows apps, you can do cross platform development in it if you use the right kit. I used to do a lot of Perl/Tk, but now I've completely switched to using the cross platform wxWidgets for all my apps needing a GUI. For using VC with it I highly recommend using wxPack to install (it bundles in the very awesome wxFormBuilder). Now the only time I use Perl/Tk is for those 5-liner type perl programs where I want to throw something into a messagebox.

Not vxWorks. WxWidgets, the former WxWindows, a cross-platform GUI toolkit.

Don't you mean wxWigdets, formerly wxWindows ?

... and stuff like wxWidgets, too. Multiple languages, multiple platforms, looks and acts like the running environment. No VM required. (Yes, I know, gcj exists ...)

If Connect() is so great, then why does the wxwidgets events doc hide it and practically discourage its use by stating that everything happens at run time with Connect()? Why do introductory tutorials rely on event tables rather than Connect()? In short, why does wxwidgets force developers to slog through event tables if you have Connect()?

Interesting point.

Nokia DOES presume to tell you what you can do with your LGPL code. Read this quote:

"Can I switch from using Qt under the LGPL to commercial afterwards?

"Users of the LGPL versions of Qt need to comply with the LGPL licensing terms and conditions. Qt's commercial license agreement contains a restriction that prohibits customers from initially beginning development with the LGPL licensed version of Qt and then transitioning to a commercial version of Qt."

Wow! How do they know how you "initially" began development?

It seems as though some lawyer or marketing guy with no technical understanding got involved.

How does this affect the open source cross-platform GUI toolkit WxWidgets?

Um, wxWidgets has been around for many years, and it can be used to write decent-looking GUIs for OS X, Windows, Linux, and many more operating systems.

While I think Qt's API is a bit nicer, it was already pretty easy to make cross-platform GUIs.

For most things, standard libraries are almost cross platform. You say you use C++, use the "standard" and you'll find everything that you are already used to.

Ah, but what about GUI ? Those are definitely not cross platform. Well, you can pick, there's GTK, there's GTK, etc... Or, go for a real cross platform toolkit such as wxWidgets. you apps will run on pretty much any platform after a recompile...

or if you use a cross platform language, say python (wxWidgets + python = wxPython), then you don't even need to recompile.

wxWidgets was originally created for C++ but it has binding to other languages, so what you learn with one language can be re-used with another language if you have a different need that dictates that.

Another, often overlooked, cross-platform UI framework is wxWidgets.

It's been a couple of years since I've worked full-time with it, but I've kept up with it and it's a wonderful framework that will allow you to develop C/C++ applications that run on a variety of platforms - Windows, Linux with a GNOME desktop, OS X etc.

You can also create UI's with wxPython and wxRuby as well...just something to consider.

It is good to know my first impression of Python is biased.

But I hope you (and other respondents) do understand my point of view - after fighting[1] with two Python programs both more-or-less failed (Mercurial works very well - except that you cannot say "hg pull http://my.server:8000/myproject", you must write http://1.2.3.4:8000/myproject). Both work nicely in Linux, btw.

[1] Try installing gtk to Windows, at least year ago it was nightmare. I think it never worked for me.

P.S. Last time, years ago, when I tried wxWindows, it was ugly as hell. Worse than e.g. http://www.wxwidgets.org/images/screens/kicad.jpg. Apparently it has moved a lot forward.

Fair enough, but wxWidgets will get the job done.

In fact, it uses wXwidgets for it's GUI, which aims to be cross platform between windows and the *nixes. Really, more of a testament to FLOSS, if not Linux.

I'm sure both are very capable libraries. All I want to see is wxWidgets being used for all GUI frontends so that they have a native feel whether you're in Gnome, KDE, Elightenment, XFCE, OS X, Windows, etc. That is, as soon as wxWidgets has KDE support.

Of course, while this might have had some sense in 1998, it's sheer idiocy in 2008, when all mainstream C++ compilers have been handling moderately complicated templates for several years already.

Of course, while this might have had some sense in 1998, it's sheer idiocy in 2008, when all mainstream C++ compilers have been handling moderately complicated templates for several years already.

If you have a point to make, make it. I have no idea what you mean with your negatives comment.

With WxWidgets you can go open source or close source. Read their license.
http://www.wxwidgets.org/about/newlicen.htm

Judging from some of the activity here, that's probably not a serious question. But let's pretend it is. However, a lot of little Bill fans will get their feelings hurt.

Bill's toy bag is just that, a toy bag, that what little it does is on and for Windows -- only. And it's near a few decades late in coming. A comprehensive answer could go on for pages if you start to include various languages like Java, Python, Perl, C, and Ada. or Tomcat, Lenya, Swish, and many others staples. That's not even counting PHP and PHP-based kit, CPAN and others.

However the press release does not say what the MS "tools" do or, more correctly, claim to do. Students would be more employable playing WoW. For those that have been living in a cave for the last 15 years here's a recap of the main professional tools you will find in industry. There are others, but they're mostly open source, too, except a few big items like Oracle and DB2. None are MS.

IDEs

• Netbeans
• Eclipse
• Emacs - it's underrated
• Kdevelop - it's also underrated

Databases

• MySQL (now Sun)
• Postgresql

GUI toolkits

• Qt (now Nokia)
• GTK+
• wxWidgets

MS has held back computing far too long. The sooner it gets out of the way, the sooner both business and research can get back on track. Bill and his anti-American movement can go take a hike, there's no place for either MS or MS boosters in today's economy.

Let's pretend that's a serious question. Well, the press release does not say what the "tools" do. However, for those that have been living in a cave for the last 15 years here's a recap of the main professional tools you will find in industry. There are others, but they're open source, too, except a few big items like Oracle and DB2.

IDEs

• Netbeans
• Eclipse
• Emacs - it's underrated

Databases

• MySQL
• Postgresql

GUI toolkits

• Qt
• GTK+
• wxWidgets

The list could go on for pages if you start to include various languages like Java, Python, Perl, C, and Ada. or Tomcat, Lenya, Swish, and many others staples. That's not even counting PHP and PHP-based kit. Bill's toy bag is just that, a toy bag, that what little it does is on and for Windows. And it's near a few decades late in coming.

MS has held back computing far too long. The sooner it gets out of the way, the sooner both business and research can get back on track. Bill and his anti-American movement can go take a hike, there's no place for them.

That's just it - the product is crap. Even wxWidgets is better - linux, mac, windows all supported. LGPL'd, with an exception allowing you to distribute your own closed-source binaries if you want. A bit of history.

That's just it - the product is crap. Even wxWidgets is better - linux, mac, windows all supported. LGPL'd, with an exception allowing you to distribute your own closed-source binaries if you want. A bit of history.

• Qt: Until being bought out by Nokia, their core business was licensing Qt commercially so it would have been a sound enough bet for closed source development (a little expensive maybe). For open source, it's GPL so no issue there. At this stage though, I'd be a little nervous if I had bet the company on Qt.
• GTK+: The toolkit that underlies Gnome is licensed under LGPL. This means it's permitted to create/distribute closed source apps which use GTK so the only question is whether you like the toolkit. GTK is written in C and not everyone like the approach that it has taken.
• GTKMM is a C++ wrapper for GTK+, also licensed under LGPL so it's good for commercial and open source

wxWidgets is native to all supported operating systems. GTK was originally designed for Unix-style X Windows. My understanding is that under Windows it still has X Windows quirks and limitations. There is also a difference in grief:

GTK -- Using Microsoft's Compiler:

It is possible to use these packages with Microsoft's compiler. However, these DLLs use the MSVCRT.DLL runtime library. This means that also applications that use these DLLs should use the MSVCRT.DLL runtime. Specifically, this means that you should not use newer versions of the Microsoft compiler than Visual C++ 6 without knowing exactly what you are doing.

wxWidgets Compiler support:

wxWidgets supports more compilers than probably any other framework. All popular Windows C++ compilers are supported with the exception of Symantec C++ (this is being worked on), and on Windows you can use the Cygwin or Mingw32 free compilers. Even the 16-bit versions of Visual C++ and Borland C++ can be used. On Windows, makefiles are provided, with project files for VC++ 5 and above.

Just about all known Unix C++ compilers are supported, for the Motif and GTK platforms. If you have a compiler that isn't supported, with help from the wxWidgets team we should be able to fix the problem quickly.

Just use WxWidgets and let the WxWidgets developers decide how to interface with whatever operating system and desktop you want to use?

Do you really believe that C# is more portable than C++?

The only thing that gives it even a hint of appearing to be cross platform is that you're writing using a standard library (the .net api). Such libraries already exist in C++ and have for some time.

C# does not run as well on any other platform as it does on Windows - just a fact. Winforms support is still heavily lacking, etc. I can guarantee it never will, either. .NET is said to be a move towards a cross-platform development stack because Microsoft badly needs to maintain the image of 'playing nice' so they won't get the legal smackdown again, but it never will be fully compatible. Microsoft wants it that way.

• GNOME http://library.gnome.org/devel/glib/stable/glib-Perl-compatible-regular-expressions.html
• Qt http://doc.trolltech.com/4.3/qregexp.html
• WxWindows http://www.wxwidgets.org/manuals/stable/wx_wxregex.html
• .Net http://msdn2.microsoft.com/en-us/library/system.text.regularexpressions.aspx
• Java http://java.sun.com/j2se/1.5.0/docs/api/java/util/regex/package-summary.html

Several years ago I tried making a linux to windows cross compiler and failed. I think I put a decent amount of effort into my attempts and I definitely knew how to produce a standard linux hosted linux targeted instance of GCC that would produce working binaries.

A while back, I needed to do that at work. This is what I ended up doing, which was derived somewhat from this. In case Multiply doesn't let you in without registration, I'll copy the message here. (Newer versions might also work; what's given here is just what was current at the time. These instructions also assume you're using Gentoo. Step 2 in the toolchain setup would be sufficient by itself for cross-compiling Windows command-line apps or (maybe) for writing directly to the Win32 API.)

toolchain setup

1. build KDevelop 3.4.0:
   emerge \>=kdevelop-3.4
2. build Windows cross-compile toolchain:
   echo sys-devel/crossdev ~amd64 >>/etc/portage/package.keywords
   emerge crossdev
   crossdev i586-mingw32msvc
3. download wxWidgets 2.8 from www.wxwidgets.org
4. revised again: build wxWidgets for Linux (assumes GTK2 and libgnomeprint are already installed):
   ./configure --prefix=/usr/local/x86_64-pc-linux-gnu --with-gnomeprint && make && make install
   echo LDPATH=/usr/local/x86_64-pc-linux-gnu/lib >/etc/env.d/80wxWidgets-2.8.0
   env-update
5. build wxWidgets for Windows:
   ./configure --prefix=/usr/local/i586-mingw32msvc --host=i586-mingw32msvc --target=i586-mingw32msvc --with-msw && make && make install

KDevelop build configuration (common)

1. create a new wxWidgets project
2. exit KDevelop
3. load foo.kdevelop into a text editor
4. copy "debug" configuration XML block to a new "debug-win32" config block (need to do this because the "add configuration" button is always grayed out...grr)

KDevelop build configuration (Linux)

• configure arguments:
  --enable-debug=full --host=x86_64-pc-linux-gnu
• build directory:
  debug
• linker flags:
  `/usr/local/x86_64-pc-linux-gnu/bin/wx-config --libs`
• environment variables:
  PATH=/usr/local/x86_64-pc-linux-gnu/bin:${PATH}
• CFLAGS:
  `/usr/local/x86_64-pc-linux-gnu/bin/wx-config --cflags`
• CXXFLAGS:
  `/usr/local/x86_64-pc-linux-gnu/bin/wx-config --cxxflags`

(The loader config that was previously given here is now taken care of during wxWidgets installation in a more Gentoo-compatible manner.)

KDevelop build configuration (Windows)

• configure arguments:
  --enable-debug=full --host=i586-mingw32msvc --target=i586-mingw32msvc --with-msw
• build directory:
  debug-win32
• linker flags:
  `/usr/local/i586-mingw32msvc/bin/wx-config --libs`
• environment variables:
  PATH=/usr/local/i586-mingw32msvc/bin:${PATH}
• CFLAGS:
  `/usr/local/i586-mingw32msvc/bin/wx-config --cflags`
• CXXFLAGS:
  `/usr/local/i586-mingw32msvc/bin/wx-config --cxxflags`

will need to copy DLLs from /usr/i586-mingw32msvc/usr/bin and/usr/local/i586-mingw32msvc/lib into same directory as foo.exe

When I went to try out the wxWidgets printing demo, the Linux build wouldn't print properly at first. Using libgnomeprint instead of direct PostScript fixed that problem. If your Linux box uses CUPS (and it probably does), libgnomeprint will enable users to tweak printer settings from within the app. Without it, wxWidgets will just (incorrectly) generate PostScript and hand it off to lpr. On Windows, I'm guessing wxWidgets just uses GDI calls, so that config is unaffected.

Just FYI:

wxWidgets for Mac OS X (wxMac) uses the Carbon API. (Carbon is the procedural Mac native application programming API for both Classic and OS X, Cocoa is object oriented and builds on Carbon, but is only for OS X.)

http://www.wxwidgets.org/manuals/stable/wx_wxmacport.html

The problem is that there are so many ways to do things wrong in C++. Writing proper code takes experience. It doesn't help either that monsters like MFC easily mess things up.

I was going to quit coding C++ when I discovered Boost and wxWidgets. Now I don't want use anything else.

So... how portable are your apps? They're not, you say?

Is wxWidgets portable enough for you? You can even set up Linux to cross-compile for Windows (maybe Mac OS X as well; I haven't tried yet) and create apps for both with native look & feel with a free-as-in-speech toolchain and desktop environment.

I don't know if the OP took that approach or if he's using native tools on each supported platform, but what he described isn't exactly outside the realm of possibility.

They renamed it WXWidgets.. and yes, it really is "super-cool". Especially with Code::Blocks and the new wxSmith stuff.

-metric

wxWidgets is a cross-platform API that is quite unique in that it uses the native UI widgets:
http://www.wxwidgets.org/ [wxwidgets.org]

As a Windows user, I'm also happy that I don't have to use some sort of "platform neutral" UI, that usually only do a compromise for limited UI functionality for all platforms instead. I've seen too much of that happen with Java and GTK apps. :-(