wxDesigner

wxWidgets is primarily[1] a portability layer on top of the platform's native GUI toolkit. If you're targeting a specific platform, I'm not sure that there's any advantage to using wxWidgets over using the underlying toolkit directly.

[1] There is an Xlib backend and a framebuffer backend, but these are both works-in-progress.

Exactly. I've been using tcl/tk and have been disappointed with the performance (as well as the "visual appeal" -- or lack thereof).

Can you comment on their overall stability? I have no desire to drag something as bloated and vulnerable as, e.g., GTK into the mix (layer upon layer upon layer... makes you wonder just how many different species of *turtles* there are!!).

Since what I am doing is rather "vanilla" (buttons, images, text, etc.) the demands on the package should be modest...

Thx!

Status: this port is 95% working, with a small number of areas that need attention, such as clipboard, text selection, tab navigation and speed optimization.

2.2 wxWidgets for DirectFB

Status: wxDFB is relatively new and is still work in progress but is already used on commercially available embedded devices.

But personally, I wouldn't trust even a mature GUI toolkit to run for weeks without error. Even if there aren't any memory /leaks/ per se, I'd be concerned about heap fragmentation; GUI toolkits tend to be quite malloc-intensive.

I'd suspect that GTK would be the least of the problems. It doesn't have the legacy baggage of Xt-based toolkits, and being written in C (as opposed to C++) helps to avoid gratuitous allocation (which C++ often hides within copy constructors, assignment operators, conversion operators, etc).

I'd be more concerned about Xlib and the X server. For at least the last decade, they've probably been adding new bugs faster than existing ones have been getting squashed.

Buttons and the like are straightforward enough that, for a kiosk, I'd be inclined to code the lot from scratch atop a framebuffer. Text, OTOH, ranges from ASCII with a single bitmap font to having to deal with encodings, scalable fonts, input methods, bidirectional layout, non-linear scripts, and so on.

Yeah, I dug through their site, wiki, etc. But, I don't expect an honest, IMPARTIAL assessment of something from the folks

*creating* it. So, hoped someone here could comment from *real* experience (not just compiling a demo, etc.)

In my experience, this depends a lot on how the interface is designed as well as its overall complexity.

This will be my third similar deployment. The first two have been running quite well. Though, perhaps this success has more to do with the appliances they are deployed on (contrasted with a *desktop* X server that gets tweaked every few months as well as the underlying OS).

Talking to a framebuffer isn't very portable :> And, decoding JPG's and other ornamentation is just extra "make work".

A font server is a wonderful thing...

Note - this newsgroup is probably not the best one for discussing Linux gui toolkits.

The three main reason for choosing any toolkit are compatibility, tools, and personal preference. If you only need to work with one platform, and are happy to lock yourself to it in the future, then by all means consider a platform-specific toolkit. But for many people, it is good to have a certain abstraction and flexibility, even if you have only one primary target platform.

Then there is the tools - before choosing the kit, you should look at the tools available. Form designers, integrated debuggers, ports to different programming languages, integration with editors, translation tools, etc., are all important considerations. This is, of course, what the OP is currently looking at.

Then there is personal preference. What does the code look like? Will it be easy for you to work with? Do you like the programming language used? These are certainly good reasons for /not/ choosing the low-level platform APIs - Xlib is hideous to work with (it's even worse than Win32).

Speed and size of the libraries may also be relevant, depending on the sort of program you are writing and its target platform.

These are both relatively new and specialised backends. The Xlib backend is aimed at very resource-limited X systems (normally the GTK backends are used on X), while the framebuffer backend is aimed at non-X systems. Unless you have good reason not to, just use the standard backend(s) for the platform(s) you want.

You've written a great deal of negative comments for a library that you have never used! Is there something you know that the huge numbers of wxWidgets users don't know? It is a very popular toolkit - there is a good chance that you use programs built on wxWidgets.

I haven't used C++ wxWidgets directly, but I have used wxPython for a number of projects. wxPython is a python wrapper for much of wxWidgets, along with a few extra python-specific modules.

I'll not claim that any library is perfect, but certainly wxWidgets is considered solid. Any instability is most likely to be in your application, not the library. The bugs I have found in my wxPython programs were all my own work.

GUI toolkits are malloc-intensive - but so is most software on PC's. If you are worried about heap fragmentation causing trouble then you can forget about running Linux, Windows, etc., for weeks at a time.

Heap fragmentation causes two problems. One is that allocations can take unexpectedly long times, and the other is that they can fail even when you have enough memory, because it is not contiguous. The unspecified delays are a problem for real-time systems - but not for a gui. And memory contiguity is not a problem when you are using a system with virtual memory and paging - the OS will re-arrange pages as necessary.

Memory leaks are always a problem. But using a higher-level toolkit rather than a lower-level one typically means that the toolkit will be doing more memory management, and your own code will be doing less. The toolkit code is tried and tested over many years, by a number of developers and a very large number of users and testers. Your own code, on the other hand, is worked on by only one or a few developers, and has much more limited testing - it's in the application code that the leaks occur.

Of course, since wxWidgets is open source, you can link it all together with something like valgrind to track memory issues.

You have GTK already - wxWidgets builds on top of GTK. wxWidgets is a higher level of abstraction than GTK, and also has cross-platform abstraction classes for all sorts of other functions as well (file access, threads, etc.) if you want to use them.

Software on big systems is /always/ a layer system. wxWidgets builds on GTK, which builds on Xlib, which builds on libc, etc.

GTK is quite substantial if you use it all, as is wxWidgets. But in the end they boil down to a few shared library modules that are not /that/ big.

And I don't see GTK as being "vulnerable".

I haven't looked at GTK code, but I'm guessing there will be plenty of memory allocations going on. It might be more explicit than with a C++ toolkit, but it is there nonetheless.

Agreed.

There are many other toolkits for gui programs. If you are looking at cross-platform toolkits that work on X (and Windows, if you like), then wxWidgets is one of the big three. The others are GTK and QT. wxWidgets is C++, GTK is C, and QT is modified C++ - but there are wrappers for all of them for different languages. My own preference is for the python bindings of wxWidgets.

There are also /many/ others that are simpler, and could be easier and faster for you to use.

Since you are talking about a kiosk, you should also consider avoiding X altogether, and using the Linux framebuffer. Two common choices of libraries on top of that are GTK+ and SDL.

If I were making such a system, I would certainly look at SDL, and probably pyGame (unless it was a very low resource system). Programming guis with Python is a lot easier than doing it with C++ - it's much higher level, so you get more done in less source code. Although pyGame is typically used for writing games, it can be used for all sorts of other software too.

No, I was planning on using the wxX11 port (hence the question regarding how stable/complete *that* port was)

Don't need any of that. Just a user interface.

Every piece of code you add is a vulnerability -- hence opting to cut GTK out of the mix. The (stated) "feature differences" between the GTK and X11 ports represent things that I don't need -- so why drag in a whole layer of software that doesn't make any practical difference at the API level that I am dealing with?

For your application, the main reason would be that wxX11 has to re-implementi a lot of the stuff that GTK already implements, but both GTK and wxGTK have had several orders of magnitude more testing than wxX11.

AFAIK, none of this stuff has undergone any kind of formal verification, so you're relying entirely upon testing if you want reliability.

Personally, I'd assume that no toolkit is going to meet your reliability requirements, so I'd focus on "containment", e.g. having the system automatically reboot daily, watchdogs, a reset button, etc.

I may just backport my tcl/tk to Inferno and try to figure out how to get a native port running. This one's for a charity so I'm not anxious to spend a lot of time on it :<

But they're both *big*. I.e., I can probably get the "system" plus application to reside in 1-2MB if I go the Inferno route (I suspect the smallest Linux kernels are bigger than that!)

Tk/limbo makes short work of (simple) GUI's -- though, admittedly, a different mindset is required for their use. :< They have the advantage of being easy to prototype (using wish(1?)). But, much of that comes as a result of being interpreted -- hence the downside on performance. :<

And, they aren't as "glitzy" -- focusing on function instead of appearance. :-/

Hmmm... maybe if I rewrite my packer and recode the database interface I can speed things up a bit...

But they also have lots more "unnecessary features". I was hoping to be able to prune just the features that I *need* from the library and eliminate all that "dead code".

This is the problem with *most* open source software. :< Folks seem more eager to hack a new feature (or, more specifically, the first *80%* of a new feature) into the code than to prove to themselves that the code they have written actually *works*. (and "documentation" seems to be one of the longest four-letter-words around! :< )

Well, the two other systems have fared well -- though the only thing in those that must run "continuously" is the main server (the user interfaces eventually end up rebooting when power is removed in the normal course of business). Fortunately, this "tolerance" is an unintended side-effect of the applications' design constraints. The application migrates freely among "terminals" so it naturally has to tolerate being "interrupted"/shut down/etc. at any point in time and resumed -- elsewhere. As a result, *not* resuming (or, resuming after a reboot) is also a likely possibility.

That's true - but it is also true of most non-open source software as well. There is only a very tiny proportion of software that ever has formal verification, and even then the verification is seldom complete. Different software has more or less formal testing (unit testing, independent test suites, regression tests, etc.), but you can be sure that almost all the software running on a PC - commercial software, open source software, free software, and absurdly expensive software - will have little more verification than usage testing.

Your complaints against documentation in open source software are equally valid - but also equally valid for closed source software. It's just that with open source software, you see more of the documentation (or lack thereof). Of course, in cases where the sales of closed source software depends somewhat on the quality of the documentation, then you get good documentation - but outside of such cases very little software of any sort is well documented.

In the particular case of wx, you'll find that most of the API documentation is accurate and up-to-date, though not as complete as you might hope, but a lot of the wiki pages and tutorials are written once and then not updated even though the years pass. (The page describing the X11 port of wxWindows as 95% working is many years old, as far as I can see.)

[8>> AFAIK, none of this stuff has undergone any kind of formal verification,

Yes. The point behind my statement is that you (I) always hear folks "explaining" that the reason their code isn't tested more thoroughly is that "The Boss" puts pressure on them to get it out the door. Fine. But The Boss isn't standing over your shoulder pushing you to get that OPEN SOURCE (typically using volunteered time!) software "out the door"... you could sit on it for weeks, months or even *years* "testing to your heart's content"!

I.e., code doesn't get tested because it's "no fun" to test code; more fun to move on to some new fangled feature -- that *also* "almost works" :<

I would be happy with even "informal" testing. How often do you see a test suite shipped with a piece of OSS? If this hasn't even been "formalized" to the INFORMAL level of "here are a list of inputs and expected outputs that illustrate proper behavior of the code/module/function/etc.", then what sort of confidence do you have that *new* additions to the code will be tested and won't also introduce bugs in "working" code?

Exactly. For exactly the same reasons (IMO). The Boss wants to move on to the next project. *And*, so does the developer! They never think they'll have to revisit the old software -- since they *know* it's "perfect"! ;-) The same in the case of OSS.

I routinely parse the sources to see what the *real* command line parameters, envars, etc. used by a program are. The documentation (man pages, info files, etc.) are often sorely lacking (even if they think they are "up to date)

I often have the opportunity to reuse old code. And, if not the code itself, at least the *design* of the code/system. Perhaps my memory isn't as good as the folks churning out all this other undocumented, untested stuff... :< I find it helps me immensely to formalize test suites and documentation (even if "formalize" is something very "informal looking" -- at least it is spelled out someplace)

I think that is more the case of "published APIs". Even then, the number of "little mistakes" is alarming.

When I prepare *formal* documentation, I cut and paste real examples into the documentation. I.e., "here is *the* piece of code that I

*ran* to illustrate how this function is used..." No opportunity for typos to creep into the documentation.

Yes, that was why I asked for first-hand experiences with it. Folks actively using something are more likely to know where all the "warts" are. As well as tricks to get around shortcomings, inefficiencies, etc.

Note I've still not heard anything re: wxDesigner... :<

[time to get back to scrubbing the roof]

One big example here is gcc, which ships with a fairly large test suite. As far as I know (I haven't studied it), much of it is regression tests - when a bug or poor good generation issue has been fixed, a test case is written to show the failure on previous versions and the success on fixed versions. The test is then included for future testing to help track any repeats of mistakes. I haven't looked at the details or even run the test suite myself - one of the reasons I recommend companies like CodeSourcery as a source of gcc is that I know testing is a very big part of the work they do, and it's worth paying for.

In general, I agree entirely with what you write (that's why I snipped most of it). I just wanted to point out that poor testing (and documentation) is not an open source issue - it is an issue with almost all software. The only difference with OSS is that it is often easier to see what's missing.

Unfortunately, I haven't used wxDesigner, so I can't comment! I /have/ used wxGlade (generating Python code, but it's much the same for C++ code). It's okay - not great, but okay. It is fine for most of my interface design, but for some parts I do it "manually" in the run-time code. I do that particularly for repetitive parts - loops in code are less effort than lots of copy-and-paste in a gui. I have also sometimes found it useful to manually edit the XML files that wxGlade uses - again, it is sometimes easier to do that by hand than through the gui.

What's the operating system? If it's Windows you might be better off buying Delphi or C++ Builder which are the king of RAD.

How many dialogs are there and how complicated are they? You might find the time to learn a new GUI toolkit outweighs any benefit from having an RAD designer. I played around with wxWidgets a long time ago but not very seriously. I think it had some problems with exceptions which Borland (yes Borland) were supposed to be fixing but I don't know if that happened. wxDesigner seems to have been around for a long time and the guy was charging money for it over ten years ago so I imagine it does something reasonable by now.

If you want to try a more modern GUI toolkit, you could check out Ultimate++.

It doesn't have a huge number of users but it's slowly growing and does have an RAD designer - probably not as good as wxDesigner though (just guessing). It's kind of radical but some people love it - especially C++ experts. You'll probably find the learning curve a bit high. It's a little bit database oriented with an emphasis on performance and rapid development - once you know it. The authors use it for serious commercial applications requiring high reliability but I don't know if that's 24/7. Unlike most GUI toolkits, objects are on the stack, not the heap.

Regarding crashing, maybe you could run a supervisory program that was as simple as possible but had the ability to monitor the application and restart it if it has malfunctioned. You might be able to set up a "cron job" to run the supervisory program every 5 minutes.

Not really answering your question but I'm sure the wxWidgets forums would have something to say. You would get an answer in the Ultimate+

• forum too.

[8> I would be happy with even "informal" testing. How often do

Exactly. It's presence tells you (me) that someone *has* tested the code (to "whatever" extent), gives *you* a template for injecting new test cases *and* ensures that all of the tests are run on subsequent releases.

gnuplot(1) also has a test suite. Unfortunately, since it's results are graphic, it relies on the user to visually inspect them (I suppose someone could have automated that as well?). For the most part, this works fine -- as long as the "user" knows what various functions *should* look like (I know of one release where the "packager" obviously did

*not* :< )

Yes! My point is the "excuse" so often given for the problem in commercial software doesn't "hold water". People just don't like testing/documenting software. Especially their own.

I had to document a piece of test equipment. Since I didn't know how things were *supposed* to work (because there was no good documentation), I had to derive all of that information empirically. The number of bugs I uncovered in the process (keep in mind, my goal was to figure out how it worked just well enough to be able to -- formally -- tell *others* how to use the device) was staggering! Some were so /blatant/ that I had to wonder if *any* testing had been done at all? (i.e., the equivalent of a 'scope not being able to trigger on "positive slope")

I think if you *know* you will have to test (certify) your code, you think about the types of things that can go wrong more actively while designing it. And, you think about how you will be able to test it once it is written. Sort of like designing an ASIC where all you'll have access to is "the pins" of the device once it is encapsulated: "How will I know if this is really working??"

I suspect I should look at just building some dialogs "by hand" and see how much I get wrong. If the errors and fixes are obvious enough, then why bother with yet another tool (that can have its own problems)...

As I say, I don't know about wxDesigner - but wxGlade is straightforward enough that you are unlikely to see many bugs with it (I haven't), and they easy to work around. It generates simple Python code that is easy to hand-check.

It might be a good idea to try out some of these tools with simple examples, and see if you like the code they make and the way the work. They can also give you some ideas for ways to structure your own code when doing it by hand, though people often have different styles for hand-coding guis.

If you /are/ hand-coding your guis, I'd recommend abstracting things a little. For example, rather than calling the standard API "makeNewButton" (or whatever it's called with the toolkit you end up with), make your own wrapper function around it that does things like set the font and padding. It makes it a lot easier to set or change these things in one place later, and is one of the advantages of hand-coding your forms.

I think the dynamic behaviors of some controls might cause a bit of head scratching. I.e., if I'm going to have to invest the time to learn how they behave IN DETAIL, then a RAD tool isn't likely to add much to the mix.

(this is where things like tk are nice as they, for the most part, have pretty simple bahaviors)

Yes. The layout tool (?) in wxWidgets seems funky/atypical. I need to play with it a bit to see how it behaves on resizing, etc.

Good point.

I am a huge fan of tables. So, typically, I would design a struct that embodies the characteristics of a "screen" ("dialog") and use that to drive the creation and placement of the controls. So, things like "default_font", "bold_font", etc. can be specified for a "screen" and inherited by any control that needs them (by specifying NULL for the control's font) or overridden, as needed.

Since it's "bad form" (visually) to have too many colors, typefaces, etc. coexisting, this tends to -- by default -- encourage you to have a common presentation (e.g., each screen can inherit from the "root screen" in the pathological case). I.e., it takes extra work to specify *exceptions* rather than just "going with the default(s)"

"Atypical" depends on what you are used to. Windows programmers are mostly used to absolute layouts - you put your widgets at specific x,y pixel positions on the form. Slightly more sophisticated systems (such as Delphi) also use anchors - your text box bottom-right corner is x,y pixels away from the form corner. But wxWidgets, like many other more flexible layout systems, normally uses sizers. The layout and arrangement changes depending on the size of the form, the size of the fonts used, the OS you are running on, etc. If that's new to you, it will certainly seem odd at first - but really it is the Windows standard style that is atypical for modern gui layout.

[snippety snip]

No more bizarre than I am in most other things (wait, what?). Maybe it just a long time preference for K&R over Jensen and Wirth from back in the dark ages (still have early copies of each around here, somewhere).

First I've heard that. Always imagined that it gave the tool developers a bit of a larger market.

BCB5 here, as the default for little PC-side interfaces and test drivers for the embedded projects. It has stayed useful through XP, at least. Haven't tried it on Win7 yet.

Tried Visual Studio 2005, I think it was. It was okay but it became a problem when it refused to take a routine MS patch and then refused to allow itself to be either uninstalled or repaired. Pfaugh!

...

Here, as well. Looks quite interesting.

--
Rich Webb     Norfolk, VA