wxEmbedded Beta Released

An anonymous reader writes "Robert Roebling has announced the first beta release of wxEmbedded, a new open source graphical windowing environment for small devices. Here is a brief overview from Roebling about wxEmbedded, along with some background on the wxWindows project from which wxEmbedded is derived."

Comments

WxWindows

[Pac]

WxWindows is one of the most magnificent development projects in existence and the fact we hear so little about it is shame upon the technological press in general and the open source information resources in particular.

WxWindows has for years fullfilled the Java promisse in C++: write once, compile and run anywhere, natively. Their approach to the cross-platform problem was always far superior than the Java approach. And I really don't care about recompilation, machines compile code, not me.

Their main public relations problem seems to be the use of an adult language, C++. Yes there are pointers (scaring, isn't it, a type that holds a memory address), there are templates (mostly scary, trully generic containers) and your program interface looks like everything else in the operating system it is running (ludicrous).

And yet, more than nine years later those guys are still there giving the community such a tool. Trully amazing.

Re:WxWindows

[bcrowell]

I agree that wxWindows is great, and I'm a happy user of Audacity, which uses wxWindows.

But...

And I really don't care about recompilation, machines compile code, not me.
The problem is that almost any time you compile something from source, you end up with hassles. Very seldom does ./configure, make, make install work without any fiddling around.

Their main public relations problem seems to be the use of an adult language, C++
wxWindows has interfaces to a lot of other languages, including Perl and Python.

IMHO, the real problems with Java are not even the ones you're referring to:

• Java is too big. wxWindows is less bloated.
• Java is not just a library but a language. The wxWindows approach seems more sensible: here's a library, which you can call from whichever language you prefer.
• Java and its libraries keep churning through versions, and implementations haven't kept up with all the changes.
• In practice, Java isn't as portable as it was supposed to be (write once, debug everywhere).

Re:WxWindows

[Jason Earl]

Their main public relations problem seems to be the use of an adult language, C++.

That's the beauty of wxPython. All the cross platform goodness of wxWindows, and the development speed and ease of Python.

Re:WxWindows

[JudasBlue]

Their main public relations problem seems to be the use of an adult language, C++

Actually, I might argue with you that C++ might more apppropriately be called a geriatric language in a general programming context, but that would start a holy war, now wouldn't it :)

However, for those of us who like to use slightly quicker to code languages for some of our projects, WxPython provides a Python wrapper around WxWindows. And there is a Perl wrapper out there as well, tho I have never used it.

Combine this with Pippy a PalmOS Python implementation, and you have lots of Py goodness for Palm devices.

Maybe refine your definitions a bit.

[Inoshiro]

You consider an adult language one that (potentially) requires that programmers be mindful of things. This may be an "adult" language, but overall I'm more motivated to work within a language like C# or Java, for the same reason I'd work in C++ or Scheme over C (or C over assembler): higher level constructs take away my micromanaging of bits of the machine, allowing me to focus more on the structure of the problem I'm modelling and working with.

Yes, it's great that pointers put hair on your chest, and that C++ is where Real Men get their rocks off, but don't write off other languages for this reason. It's like writting off French or Japanese because, "English is good enough."

Re:Maybe refine your definitions a bit.

[lpontiac]

I'm more motivated to work within a language like C# or Java [...] higher level constructs take away my micromanaging of bits of the machine

Please don't take this as a troll, I'm genuinely curious .. what higher level constructs do you have in C# and Java that aren't there in C++? (C# in particular, since I intend to sink my teeth into it soon :)

wxWindows: the toolkit everyone should be using

[Jimithing DMB]

I started using wxWindows about 10 months ago (January 2002). I was in the planning stages of a complete rewrite of an application (shameless plug) and had carte blanche to decide what toolkit and development environment I would be using.

After doing some fairly extensive research I came across wxWindows. I'll admit, I don't find the website too easy to navigate-- it seems too different from most other free software websites, but there is a lot of information there. One of the interesting things is that the documentation is GREAT. Normally you don't see detailed documentation like this in any open source or free software project, and many times not even in commercial products (think MFC). With that said, I'll admit that for some complex tasks the documentation is lacking. However, at that point you look at the code which is just absolutely beautiful.

You can tell that wxWindows was created by people who thoroughly understand OO programming, and more importantly understand the specifics of programming OO in C++. C++ is /not/ a toy language. Unlike some other toolkits or frameworks which attempt to hide "complexities" from the programmer, wxWindows exposes nearly everything. When using wxWindows you /WILL/ need to deal with pointers. However, every effort has been made to free memory when and how is appropriate. Some classes really are just reference counters (wxBitmap, wxImage, GDI Objects, etc.). Other classes have their own memory allocation/deallocation scheme. When dealing with window creation you simply use the new operator to allocate the window. Part of a window's constructor is a pointer to its parent. Parents will delete children.

There is no overall "garbage collector". Everything is done just as any reasonable programmer would expect it, and these behaviors are detailed in the documentation. wxWindows is the only toolkit I have seen designed with C++ in mind. Sure.. there is QT, but the Moc is a hack (/me ducks), and QT programming just doesn't hit the right nerve in my mind.

For those looking to get a quick start with wxWindows I'd say to first browse the documentation (especially the topic overviews) and get a feel for how wxWindows deals with things in general. Then grab wxWindows and do the standard configure business (might I suggest you install to its own prefix like /opt/wx). The main makefile does not build the samples. To build a sample, go into the build directory and run make from there. The samples are excellent. For one thing you will get a feel for how the general programming is done with wxWindows. You will be able to take a sample and use it as a starting point for your application. The samples are also great when you are having a problem that shows up in your app and you need a simple testcase. Just add some code to the appropriate sample and see what the behavior is.

I could go on and on, but the bottom line is that if you have not tried wxWindows, you need to. Don't be put off by C++. Just because you have tried foobar C++ toolkit and thought C++ sucked does not mean wxWindows is the same way. I would even say it's not too much of a stretch that even a Visual Basic programmer could get accustomed to it so long as they actually had at least some grasp of C++ in general. This is especially true for those people who use VB simply because it is "faster and easier than C++" when what they really mean is that it's faster and easier than MFC (which it is). Once you see wxWindows and get to know what a real toolkit should be, you'll not want to use anything else.

Re:wxWindows: the toolkit everyone should be using

[Jimithing DMB]

Hmm.. all good points and all good questions, I was starting to think Slashdot had completely lost its touch after posting in the comments with 40+ porn trolls. Anyway...

You're right, there is nothing really wrong with using VB for what it is, a quick way to get something pushed out the door. I was at an MS developer conference (read: .NET sales pitch) the other day. Normally when I think VB programmer I tend to think someone who hasn't bothered to learn anything except VB and thinks that Microsoft is just great for giving them this RAD tool.

What I found out is that there are a lot of people programming in VB simply because under the time and budget constraints it makes sense compared with other programming toolkits. Sad to say it, the majority was the stereotypical VB programmer, but there were at least some people there who were genuinely interested in a better way to program. Microsoft .net does not seem to be the answer though.

To get back to your question. Yes, I do think that someone who is an expert VB programmer with a grasp of C and C++ can rapidly develop with wxWindows. I was talking with some people there about wxWindows, just trying to get the word out there about this great toolkit. Nicely enough, wxWindows actually /has/ a cross platform data layer, though I personally have not used it, many other people have.

I would suggest that you try wxWindows on something that is not immediately urgent. Obviously with any new toolkit you are going to have to get up to speed a bit. I noticed that setting controls up on a frame, sized properly and all, is just dead simple to code (by hand). However, if you are into the drag-n-drop form creation then you're in luck because there is one free software project (a bit limited from what I hear) and a commercial product (that everyone raves about) for creating forms. Even if you don't use one of those tools you will still be amazed at how easy it is to just code the GUI by hand.

For a bit of background, my most recent project was a rewrite of an existing program. When I first saw it, I said "I could rewrite /that/ in 2 weeks". And indeed I did have something that very closely resembled the existing MFC app in just a bit over two weeks. The many many months that followed was all polish. I added real curves and levels dialogs, a real settings dialog for the image processing utils, a powerful and good looking batch processing mode, and many many more things. But as I look back, my original estimate of 2 weeks (although in some part a reference to the Money Pit) was not too far off.

So in short, stuff that should be easy is easy. Stuff that is a bit more advanced is not too hard. Generally if you are talking about simple data forms applications then you're not doing anything highly advanced anyway, so I would definitely say once you get up to speed on wxWindows you'll be able to knock out applications just as fast or even faster than with VB.

Oh, and the help system totally rocks too. The wxWindows system uses a zip file containing html pages and special contents and index pages. Each zip file is a book, and you can load multiple books. If you want a more native help system you can drop in a different help controller and you will be able to use the normal Microsoft stuff.

As I said in the previous mail, the best way to get up to speed is to look at the samples. Generally I have found that the the whole front-end of your program has already been written for you if you use the sample code for reference. The back-end is obviously a program specific thing, although if you are churning out many similar programs, I'm sure you'll start making your own reusable classes for the backend. wxWindows has an RTTI system built-in so you can actually do REAL OO programming, and not the pseudo-OO that stock C++ provides.

Seriously.. check it out! :-)

Point taken, minimal apology and other tidbits

[Pac]

I was not writing other languages off. As a matter of fact (and market) I am today a Java programmer.

I should perhaps apologise for being too vague. I consider Java a good language, too. I also consider Python a good language (and Zope is a pretty nice tool). I also like some other languages I will not mention to protect myself from a language flame war (both for quoting or failing to quote something).

My point was more addressed to all the criticism (some of it deserved, most just a nod from language developers and the tech press to mental lazyness) C++ received for being too complex, too big, too low level etc, during the recent years. Perhaps I am old fashioned but I still belive in Knuth's harsh words about the supposed difficulties of learning his book's fictional Assembler - I just don't think someone who calls him/herself a programmer have any excuse for being unable to learn and use any language (OK, except Forth - you have to be a Budhist Martian to like Forth).

X11 works very well on handhelds

[g4dget]

While X11 is staying alive on the Desktop, it has no place on PDAs - X11 is simply overkill for them (I know, there are X servers for PDAs, but they're < alpha quality).

A 200MHz ARM with 64Mbytes of RAM is many times as powerful as the workstations that X11 was originally developed for. In fact, even a few years ago, a 200MHz RISC machine was considered a high-end machine. Arguments that such a handheld is so limited that it needs a special window system are just laughable. The small screen on these devices actually means that any window system needs even fewer resources than a desktop.

Furthermore, the self-proclaimed "embedded" windowing systems for handhelds often do worse than X11. X servers running on the Agenda or Zaurus take 1.3Mbytes of memory. This is a fraction of what, for example, Qt/Embedded takes. Furthermore, applications written for X11 using an embedded or lightweight X11 toolkit also tend to be a fraction of the size of those written in Qt/Embedded. Drawing speed of the X11-based solution is usually faster as well in my experience.

There are certainly release-quality X servers available for Linux handhelds--why shouldn't they be? They are simply using the mature dumb frame buffer code from the desktop version, requiring almost no changes. On my Zaurus, on the other hand, I have already experienced GUI deadlocks a number of times that weren't fixable without rebooting the handheld--not really surprising for a toolkit that is so tightly integrated with the display system and also is comparatively new.

There is no technical reason whatsoever to develop new "embedded" window systems for today's PDAs.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Screenshots

[Grip3n]

More screenshots of wxEmbedded (and specifically wxDesigner) are available here:

http://www.roebling.de/sshots.html

There are images from it running under MacOS X, MacOS 9 as well as X11.