Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Handhelds Hardware

wxEmbedded Beta Released 158

Posted by CowboyNeal from the looks-like-gtk-but-smaller dept.
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."
This discussion has been archived. No new comments can be posted.

wxEmbedded Beta Released More

wxEmbedded Beta Released

Comments Filter:

  • WxWindows (Score:5, Insightful)

    by Pac ( 9516 ) <paulo...candido@@@gmail...com> on Thursday October 03, 2002 @11:21PM (#4385268)
    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 (Score:1, Insightful)

      by Anonymous Coward
      Yes there are pointers (scaring, isn't it, a type that holds a memory address)
      >>>>>

      It's not that they're scary; it's that you can't have them if you want to do garbage collection right.
      • You can't live with them, you can't live without them.

        Garbage collection is nothing more, nothing less than pointer manipulation. Even in Java. The fact that you can't see or manipulate them is just an insult to the intelligence of the average programmer (or, if I was to flame, a concession to the intelligence of that same average programmer - that guy they keep in a vault in the Paris Museum basement along with the meter bar and the kilo ball), not a indication they are not there.
        • Garbage collection is nothing more, nothing less than pointer manipulation.
          I beg to differ on this point, garbage collection is a bit more complex. In simpler languages (C) you will have to periodically perform a memory de-fragmentation step, while more complicated languages (Java, python) may have to figure out which parts of memory are no longer needed and THEN go through the de-fragmentation step. This can take a laaaaarge (unbounded) amount time.

          As far as hiding pointers being an insult to the intelligence of the "average" programmer, try doing a depth-first traversal of a B-tree without resorting to recursion. Many of the better programmers that I know have problems with this one. Hiding pointers behind a language supported interface (class, generic, etc.) is a Very Good Thing (tm).
          • Hiding pointers behind a language supported interface (class, generic, etc.) is a Very Good Thing (tm).

            Here is where we differ a little. I would say "Having the option of hiding pointers behind a language supported interface (class, generic, etc.) is a Very Good Thing (tm).". My main concern here is not that the pointers are abstracted for the sake of development sanity, my concern is that I can't de-abstract them when I want to and assume full intellectual responsability for my acts.

            By the way, my comment about garbage collection and pointer manipulation was not meant to be exclusive. Obviously I know there are tenths of other operations in a functional collector. I was just stressing the point in question, namely pointers.
        • >Garbage collection is nothing more, nothing less than pointer manipulation. This notion that memory is the only resource that needs management is pernicious and damaging. A running system uses many resources apart from memory. They all need management. And they're all susceptible to the same problems as memory -- dangling references, double disposal, difficulty in determining ownership and therefore responsibility over lifetime etc.

          A system which removes the burden of memory management is clearly very valuable, but if it simultaneously makes it harder to build infrastructure that can help with other resource types then I think one has to question the overall benefit.

          For the creation of reliable systems, I would claim that _destructors_ are the single biggest advantage C++ has over Java, C#, perl, python and the rest. A C++ destructor is reliably invoked at predictable times. This makes it, in conjunction with constructors of course, a key building block in the management of all kinds of resources.

          Speaking more plainly, my own experience is that memory management is a non-issue -- it is simply a special case of the more general management of any resource (network socket, dma channel, sound output etc) And we have problems with that management when the the ownership of a resource may change over time.

          And the solution? (Well, a solution): Reference Counting.

          Before you turn away in disgust, take a look through the linux kernel source. You'll see pervasive use of reference counting. It's had a bad rep since early smalltalk days, where it was used for the management of every single object. And that's very costly, when most of the time who owns what is obvious. But dismissing reference counting based on poor results when it's over-used is a mistake, just as claiming that Java et al solve the number one problem in software reliability by providing pervasive automatic garbage collection of objects.

          • I would claim that _destructors_ are the single biggest advantage C++ has over Java, C#, perl, python and the rest
            Absolutely. A function (destructor) that is guaranteed to be called at some point after another function (constructor) has been called, even if an exception is thrown in between, is incredibly useful. While there are a number of powerful resource managment techniques in c++ (see for example the smart pointer classes over at boost [boost.org], for me the approach of 'Resource Aquisition Is Initialisation' has proven to be very effective in avoiding headaches with with memory leaks (or database handle leaks, or file handle leaks, or ....)
      • In wxWindows the destructors of all objects are destroying their children. And as all objects in wx is a part of at least wxApp, the application object, all objects are destroyed when the application is finished.

        No need for garbage collection, the library does not leave any garbage...
    • I can only agree. I've worked with wxWindows and the thing is so logically laid out that you can get comfortable with it in a day. Good online documentation as well!

      Shame that it doesn't seem as popular as other toolkits, it's completely free, cross-platform and useful for getting things done.
      • You pointed to another important feature I forgot to mention. WxWindows is light years ahead of Win32 or GTK (I have no experience with the Mac port) in terms of code organisation, general API sanity and naming conventions.

        After I learned the structure (and here their documentation shines) of the library, I prefer to use Wx instead of native APIs everytime.
        • I have to agree on a basic point that wxWindows is better than plain Win32 api, or GTK. I tried using GTK before and found it difficult. I know the Win32 api however and find it great in general. But I now develop on the mac, and I don't think I would want to go back to C++ gui development.

    • Re:WxWindows (Score:3, Interesting)

      by bcrowell ( 177657 )
      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 (Score:2, Informative)

        by jhunsake ( 81920 )
        "Very seldom does ./configure, make, make install work without any fiddling around."

        Here's some anecdotal evidence to the contrary: it works all the time for me, and I do it *a lot*, on several different architectures.
      • Here we go again with the Java bashing. Geez, why must everything on here be so religous? All (well most!) languages have their strengths and weaknesses, things they are more or less suited too. Java is fantastic for server side OO apps, cross platform GUIs and so on. C++ is probably a better choice for OS code and games right now. If I was writing a text file parser, I'd use perl. If it was a rule engine I'd crack out the Prolog. If it was a low level hardware driver for an embedded device I might even be tempted to assmebler. As they say round here, it's horses for courses.

        Yes Java is a language, of course it is. Java is a fantastic language, very well designed and far more suited to OO than C/C++ (IMHO). If you don't believe in OO of course, then move along - nothing to see here.

        "Java is too big" - What? You can get a JVM for a palm pilot or a mobile phone - how is that "too big"? If you're referring to the class libraries which come as standard, you don't have to use them if you don't want. The fact is they provide a huge amount of useful code for free. Look at Linux - SUSE comes on 8 CDs! If I say that it's bloated people point out that includes lots of apps etc which are optional. The core is tiny. Exactly the same argument here.

        "Java and its libraries keep churning through versions" - The language itself has just had it's first major change in years with the addition of assertions. Old code still works fine in new JVMs. The libraries and JVMs are upgraded regularly, of course they are. They keep getting better. Isn't that what's supposed to happen with software? When it stops getting upgraded it's dead. Again look at Linux, I mean with all those new kernel versions it's soooo complicated to upgrade. Give me a break.

        "In practice, Java isn't as portable as it was supposed to be" - I keep hearing this and it's complete rubbish. I am a senior developer on a Java/J2EE project with over 2m lines of code and 20 (different) discreet distributed processes. We develop and unit test on a mixture of NT, 2000, XP, Linux and Solaris, we QA and deploy on to pure Solaris. In the 2 years I have been here I can think of exactly zero cases where a bug was due to incompatiabilties between platforms. I can remember in a previous job finding one situation where an NT and Solaris JVM behaved differently - it turns out the NT one wasn't adhering to the language spec and it was quickly fixed. That was many versions ago. Platform compatiability simply isn't a problem with server side Java, it just works, and it works everywhere. Rock on :)

    • Re:WxWindows (Score:4, Insightful)

      by Jason Earl ( 1894 ) on Friday October 04, 2002 @12:08AM (#4385390) Homepage Journal

      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.

    • Maybe refine your definitions a bit. (Score:5, Insightful)

      by Inoshiro ( 71693 ) on Friday October 04, 2002 @12:09AM (#4385392) Homepage
      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."
      • 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).
        • On behalf of Buddhist Martians everywhere, sir, I take offense!
        • Ah, yes, I remember my forth work. Don't knock it, just because you don't understand it. It is a strange language. On the other hand it teaches some useful concepts, sort of like using an old reverse polish HP calculator for a year. In Forth in order to get anything reasonable done you have to break your problem up into little tiny self contained pieces. I think the resultant mindset coupled with modern component OO development helps to generate more maintainable code. People stop writing these huge do everything classes in C++/Java/etc. Instead you get these small well defined mini components.
          • I remember Forth also, I first saw it as a very fast compiler for the Apple II. Besides Reverse Polish Notation, one also learns that a stack can work wonders beyond measure. But I wouldn't recomend it for everyone, the paradigm shift from "normal" languages is fairly great. Scarily so.

      • It's like writting off French or Japanese because, "English is good enough."

        I like this analogy. Like English vs. French/Japanese, C++ is understood by more people/platforms than Java or C#, and this in itself is a very good reason for writing it. At the same time, just like English, although it has lots of peculiar ways of getting it wrong and shooting yourself in the foot, it is, thanks to its bastardized nature and its myriad of influences, a richer language, with many more ways to express the same ideas and concepts than other competitive languages. Until you are fluent in it, you make more mistakes than you would with another language, but once you have a grasp of it you can express exactly what you mean in fewer words/LOC than anything else.

        Larry Wall understands this perfectly, which is why in Perl, There's More Than One Way To Do It, as opposed to the simplified elegance of, for instance, Python. This is also why Perl totally dominates over its competitor scripting languages.

        Sad but true.

      • 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 :)

        • Here's what I can think of off the top of my head. It's probably not complete, so I hope other people feel free to add to this list:

          One of the fellows I work with calls properties "syntactic sugar," but when dealing with classes, using properties in C# and managed C++ is great. If you've used Java at all, you know how much you use get/set functions. These make the notation for the common case (one arg set, void get) that much easier.

          Similarly, C# allows indexing into data structures based on a string (similar a PHP feature) where you have data = classinsntance["stringIndex"]).

          C# and Java all have a complete object hierachy. This guarantees certain methods are always available to every object, such as toString() and other basics which aid debugging.

          Java has (IMO) slightly better exception handling support than the other languages because you must either catch a specific possible exception, or declare it to be thrown. This allows compile time checking of your exception handling path, something not possible in C++ and C# (MS decided that it didn't scale well for large projects, nuts to that :)).

          And, of course, C# and Java are garbage collected (this is probably the most important one). It lets you get more out of OO when you don't try to think about the machine resources. You need a connection somewhere? Instantiate a connection class. Don't need it? Let it go out of scope. Need another one? Instantiate it. No create a class instance, then reuse it over and over again. It makes the design of the class simpler because you can throw any "I can't connect" exceptions in one place (the constructor), and otherwise assume you have a valid connection elsewehere (this assumes, that your network connections don't go away, but I've simplified this a bit to get the design point across).

          And, while I know that C++ has now a standard string class, Java and C# have both had one from the beginning, discouraging programmers from starting with character arrays and wrapping them in their own (incorrect) string class.

          The richness of the Java and C# object classes (not the specific Sun or Microsoft name spaces, the general ones) are enough to make any programmer happy.

          Java also will optionally enforce IEEE 754 on double/float operations, allowing you to have complex math code which works the same regardless of the quirks of the FPU on the local CPU.

          ---
          Thanks for reading this far.

          • Well, I don't like my exceptions that strict, and I'm not keen on the single object hierachy either :) That's pure opinion, so I won't try to start an argument..

            Similarly for garbage collection, although I should point out that there's nothing stopping you from doing garbage collection (Boost's [boost.org] shared_ptr is a commonly used implementation) within your own stuff. If you want a dynamically allocated (ie with new) object to be automatically deleted when it's scope vanishes, std::auto_ptr should take care of it.

            The std::map container will let you index on strings (or any other kind of object, for that matter) and look up with myData["key"].

            I think that a smaller standard library, with distinct functionalities farmer out to third party libraries, is a good thing. Although, as you've pointed out, many projects have insisted on inventing their own strings, instead of using the standard ones. This is a huge problem, but I get the feeling it's slowly going away.

            Property helpers are a big plus, I'll grant you that :P

            • I don't do much (any) C++, and it shows :) We do use Boost where I currently am doing my 9-5, but my interaction with it has been minimal (set it up so I can build the C++ sections of the project on my workstation).
      • I'm sorry but for certain things C is the best solutions ... I have trouble putting something writen in java into a mission critical role.

        And yes I have alot of hair on my chest.
        • I don't think I'll see Java for PIC work any time soon :)

          I'm all for using the best tool for the job, but in most cases a higher level language is a better tool because I reduce the amount of time I (the programmer) must work with some aspects of the code which the machine can do for me.

          I'm not sure about the "no mission critical" critical, though.
        • I am soory to let you know but Java is used for many mission critical role's. I have worked at 2 Differnet companys were java based apps were the core to admin systems that made our jobs imposible when dead. We had more problems with the Windows NT Workstations then those Java Apps.
      • If we weren't talking about wxEmbedded, your points would be more valid. Note that wxEmbedded is for embedded and small devices. In these environments "micromanaging bits of the machine" and "being mindful of things" is a way of life. In this case, C/C++ is the most appropriate tool for the job. Sure, C# and Java allow you to focus on higher-level structures and models, but the penalty is that they isolate you from the "metal", and in the embedded world, that sacrifice is too costly.
        • I was discussing the way the original author seemed to be suffering from a case of, "C++ is the very best ever, and only Real Programmers use it -- and they use in exclusively." He acknowledge it did sound a bit like that, and rather gracefully apologized (do read the thread, it is a good one).

          As for being mindful of the metal, I agree more with that if we are talking about a true embedded environment (or even just a lean environment, like a PalmIII). The iPaqs they have out ship with 3 times the horse power of my original DX4-100 486. I see no reason why those machines can't take advantage of J2ME and other great portable environments (there is even J2ME for PalmOS, but it's fairly slow).

    • Re:WxWindows (Score:3, Informative)

      by JudasBlue ( 409332 )
      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 [wxpython.org] 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 [sourceforge.net] a PalmOS Python implementation, and you have lots of Py goodness for Palm devices.
      • Doh, I missed that they don't appear to be porting this to PalmOS, but only shooting for WinCE after Linux devices.
        • I don't see any reason why they may not eventually port to PalmOS. POS 4.x and most of the platforms on which it runs are more or less jokes for something like this- Python+wxWin, a high-level language caling a pretty big, abstracted library. Maybe in POS 5 or some dot-rev we'll see non-trivial apps ported to POS.
      • Would be nice if wxPython was ported to PalmOS, and if Pippy was a bit more complete...

        wxPerl is good, and similar to wxPython as it should be. There are some good tutorials for wxPerl but the docs aren't as good as for wxPython - fortunately you can read the wxPython or C++ docs and just transliterate them into Perl.

    • 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' biggest acceptance problem is... Qt. Both occupy basically the same niche - a cross-platform C++ toolkit. There are obvious technical differences, particularly the reuse of native widgets (wxWindows) versus reimplementation of widgets (Qt) but the basic philosophy behind both toolkits is the same - create the be-all-and-end-all of application toolkits, cross-platform and written in the best language available for the job (C++). They are plainly in direct competition.

      There are couple of things that really set them apart - commercial support, where Qt, being a proprietary toolkit that has gone Open Source, has some advantages, particularly in terms of documentation and timely technical support - but, it has to be said, the number one reason is KDE. TrollTech's support of KDE right from the start, and their willingness to turn their business model almost on its head for it, has been one of the most successful strategies I've seen in the software industry, securing them forever the number one spot in C++ toolkits for Linux, and assuring them of major profits to come as Linux gradually achieves world domination.

      Those of you who'd like to make a buck or two out of Open Source software should take note of the way TrollTech does things - Qt is arguably no better technically than wxWindows, but through clever and Open Source-friendly strategy, TrollTech has assured themslelves of the upper hand. It's a funny world, isnt it, when an originally proprietary piece of software ends up being more successful in the Open Source world than something that was Open Source right from the start?

      • TrollTech has Win32 and MacOSX versions of Qt (natch), but both are available only under proprietary, GPL-incompatible-if-there's-no-exception-clause licenses. The licensing of wxWindows's various incarnations seems to be a significant plus in its favor, at least for GPL'ed cross-platform GUI apps.
      • TrollTech's support of KDE right from the start, and their willingness to turn their business model almost on its head for it, has been one of the most successful strategies I've seen in the software industry, securing them forever the number one spot in C++ toolkits for Linux, and assuring them of major profits to come as Linux gradually achieves world domination.

        I don't see Troll Tech as doing so spectacularly well. Yes, they have managed to attract commercial developers through dual licensing. But many commercial developers are wary of the commercial tie-in and the high licensing fees compared to other commercial and free systems.

        The commercial desktop UNIX world is pretty clearly moving towards Gnome and Gtk+--Sun, IBM, or HP have no interest in handing a market to a small company somewhere. And I think that pretty much decides the long-term fate of Qt--it will hang around, but it won't become the dominant toolkit on UNIX and Linux desktops.

        • > I don't see Troll Tech as doing so spectacularly well. Yes, they have managed to attract commercial developers through dual licensing. But many commercial developers are wary of the commercial tie-in and the high licensing fees compared to other commercial and free systems.

          You're looking at it from a UNIX-only standpoint. Most commercial Qt developers I know don't even use Qt on X11. Most of them are recent MFC converts who needed to port an app or two to OSX. Qt fit their needs perfectly. The thing is that with proprietary development of Qt in Windows, you'll never know what's a Qt app unless you disassemble the application with a commercial disassembler like IDA Pro. Even then, you'll need special FLIRT signatures (I made some for Qt+VS6).

          > The commercial desktop UNIX world is pretty clearly moving towards Gnome and Gtk+--Sun, IBM, or HP have no interest in handing a market to a small company somewhere.

          IBM seems to be pretty neutral between KDE and GNOME. The only program I can think of that uses GNOME by IBM is Eclipse. Of course, there is always intreast to have a Qt or KDE frontend to Eclipse/SWT as well.

          HP and Sun (especially Sun), seem to clearly lie to GNOME, but on the other hand, companies like Borland choose Qt in Kylix and Opera in Opera.

          > And I think that pretty much decides the long-term fate of Qt--it will hang around, but it won't become the dominant toolkit on UNIX and Linux desktops.

          I don't think it'll be dominant either. But the parent poster never said it was. There is room for both Qt and GTK. It looks like, especially from the last two years, that neither of them are going to go away.

          • This is an excellent example of the UNIX industry's support KDE. They are happy to say good things about KDE, but when it comes to write their own software, they invariably choose GTK due to licensing issues. The single exception to this rule that I can think of is Kylix.

            I certainly agree that QT is likely to go anywhere, but savvy developers have realized that in most cases there is a useable alternative to QT that is under a more friendly license than the GPL.

            • > They are happy to say good things about KDE, but when it comes to write their own software, they invariably choose GTK due to licensing issues. The single exception to this rule that I can think of is Kylix.

              Well, if the company is only in the UNIX industry and they don't care about releasing source, then the Qt/GPL fits their needs well.

              Note that companies like Borland and Opera are in neither of these catagories, and they picked Qt. They probably chose it for a greater support guarentee. It's like people buying commercial versions of Redhat.

              The Linux distros themselves tend to pick tookits based on licenses AND preferences. SuSE likely picked Qt for yast for #2. Redhat probably picked Gtk for #2. Mandrake probably picked Gtk for #1.

              > I certainly agree that QT is likely to go anywhere, but savvy developers have realized that in most cases there is a useable alternative to QT that is under a more friendly license than the GPL.

              Yeah, there is usually tookits that have more friendly licenses in most situations. However, strictly from anecdotal evidence, I've found that small companies who have made primarily Windows applications (especially in a contractual basis) in the past tend to find Qt first and buy/use it. On the other hand, people who have had experience with X11 tend to use an alternative toolkit, mostly wx/Windows. I've seen very few people use gtk for propreitary development in Windows, but maybe that's just me. I think perhaps this will change with gtk2, but then again, it might not.

              And I'm mostly talking about C/C++ developers. Java people will just use Java across the platforms. SWT is great for this, and I hope it gets adopted more. Delphi people would just use Kylix (duh).
      • You make some good points about Qt's adoption - definitely helps to get a major open source project to adopt a GUI toolkit. However, Qt is not viable for non-open-source developers or sysadmins who want to write cross-platform GUI-based scripts in Perl/Python. Its per-seat development cost is aimed at commercial C++ applications, so wxPerl/WxPython are ideal.

        GNOME/Gtk are nice but getting them working on a Windows box is painful - wxWindows provides a simpler approach. To use wxPerl, you just install the Wx module from CPAN, read the tutorials, and off you go - no license fees.

        Also, there's a GUI design tool for Wx, called wxDesigner - it's commercial but the cost is very reasonable, under $300 for 10 licenses, and it supports C++, Perl and Python.

        By the way, am I the only person who sees Perl and Python as more similar than different? Of course, each one has advantages, but perhaps it is the similarity that drives the language wars...
        • No, you aren't the only one. I personally use Python because it simply makes more sense to me and is more elegant and readable. However, the two are in the same space for all intents and purposes in the way that most people use them.

          However, the one thing I do think is slightly, note slightly, different is that for big jobs it becomes annoying to try to read perl or debug someone else's code, and it is much easer in Python. At least for me. So in Python I can produce apps, and in perl I would rather not.

          But while I prefer Python, there is nothing I have done in it so far that isn't trivial to port to Perl.
      • If you start doing anything too complex with wxWindows, the disparity between GTK, Win32 and MacOS becomes a real hindrance in creating an application with a uniform appearance and polished "feel".

        In my private projects, it's a real crisis trying to decide between Qt, which I feel is superior for cross-platform design, and Wx, which is Free and Open on all platforms, not just the open source ones. And yes, my projects really do require that I produce executables for the Mac and Windows crowd.

        There is one thing that both excel at, however. They both beat the living hell out of using MFC for me.
    • wxWindows actually doesn't use templates or exceptions. This is rather unfortunate, since resource management could be greatly improved with automated reference counting and exception handling. Taking advantage of more standard C++ features I think is the biggest issue for the next major release.

      As for "adult" language, I think C++ is "adult" in the same way that a Corvette is--it's fast and it's fun to drive, but it's mostly the choice of people who have only just become adults. Given the choice, most people would pick something more comfortable.

      Still, if circumstances force you to program in C++ (and for some applications, it is a good language), wxWindows is probably the best toolkit you can get right now.

      • I actually like this. My code actually works without ten million compiler faults when I try to integrate multiple source code bases together.

        I use wxWindows quite a bit and have to say it is a great toolkit...
        • Exceptions work on pretty much all compilers. And while template instantiation in general is tricky, it's easy to write template code that works reliably across all reasonable compilers.

          wxWindows really needs this because resource management and error handling in wxWindows is error-prone, just like in many big C++ libraries.

      • Exceptions and templates would be great for doing wxWin work only in C++, but for creating bindings to other languages (which typically look for C-like calling conventions) they'd add a lot of headaches.
    • Their main public relations problem seems to be the use of an adult language, C++.

      I thought wxWindows was the de facto standard for Python GUIs now, as well? Or do you mean the language they used to write wxWindows? You can use it without knowing C++, can't you?

      • > I thought wxWindows was the de facto standard for Python GUIs now, as well?

        No, pretty much tk still is. wx/Python is very good and IMHO much preferable to tk, but it's not the defacto standard.
    • > Their main public relations problem seems to be the use of an adult language, C++.

      It may be in C++, but there's all sorts of bindings for different languages, including perl, python, ruby, and lua. I'm really in love with wxPython myself, though the introductory material and documentation is really poor, deferring entirely to the C++ version for the API docs. Right now I'm trying to figure out how to unbind an event in wxPython, and have to go straight to the C++ docs for it and hope the concepts translate. I'd really love it that situation were improved.

    • wxWindows does not have any actual template class in it. They do however have some "pseudo-template" classes, involves macros. But this forms a very tiny part of wxWindows anyway, so it certainly shouldn't scare anyone off.

      I recently decided to use wxWindows for a project I'm working on, and I like it a lot. It has a nice, clean design, and even if you don't need cross-platfrom, it hides the pain of having to use Win32.

      I like the "native look and feel" feature of wxWindows, but I do think your argument that not having that is "ludicrous", is ludicrous. Your arguments in general are more religion-based (generally "this is just obviously the best for everything" type arguments) than technical-based (usually "different tools are better for different purposes, use the best for the job" type arguments). "far superior" to the Java approach? Please, lets be level-headed here, the different approaches have different pros and cons. We don't live in such a black-and-white world.

      On a side note, why does GTK have such a pathetic limit on the number of elements in a list box (2000)? For my application, I need a list box with lots of elements, typically around 20K to 50K elements. There is absolutely no reason why a list box control should not be able to handle this. I've already added over 700,000 elements to the Windows list box and it handles it quickly and with no problems whatsoever.

  • audacity uses it, very portable, very fast and a nice clean look. wxEmbedded is just another good product made by those smart developers.
  • 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).

    But their goal is to make it work on WinCE and Linux, so I guess that's great news. That will alow us to develop commercial applications with zero licensing cost for these PDAs

    The Raven

    • While I respect your opinion that X11 is bad for PDAs I have to say I think you are mistaken. It's along the lines of saying TCP/IP is overkill for this and that. Some years ago everyone had their own proprietary protocols. But now you see everything running over at least TCP. And more and more you see things running over XML over HTTP over TCP etc... etc. Seems like a lot of overkill but in ways it has its advantages.

      Aside from that, the simple fact is that wxWindows is in fact NOT limited to X11. The API is absolutely phenomenal. wxWindows can be made to run on anything that can display graphics without requiring changes to your application code. I really cannot say enough good things about wxWindows, but I plan to try anyway in a toplevel comment.

    • 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.

      • 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.

        That's an X server with no toolkit. Doing everything in raw xlib, are you?
  • From a coders point of view: this product looks really sw3333t. The future is mobile devices but to get there we have to start developing for products that can exist soon so that we will have the demand for more powerful mobile devices in the future.
    Having several starting points now (with all the different platforms) means that in the future there will be quite a few products as well since a particular language/product will appeal to certain people.
    Thus, implementation now means more devices to implement upon in the future.
  • http://www.brondsema.net/toolkits.html [brondsema.net]
    Here's a small spreadsheet I made a while ago. It lacks wxWindows and info about Palm support, but it does show several other cross-platform libraries and their capabilities.

  • 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 [truview.com]) 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: (Score:3, Insightful)

      by account_deleted ( 4530225 )
      Comment removed based on user account deletion
      • Well, you don't have to use C++. There are bindings to Python, Perl, Basic, Lua, JavaScript and Eiffel.
      • Since you are coming from VB, I would try Python, which is supported 'in-the-box' by wxWindows' wxPython piece. Personally, I prefer Perl, but Python has a much cleaner syntax and will be easier to get into. There is a huge array of third party modules for Python, and they are all free - however, if you are using commercial VB controls you may find some bits are missing.

        The one issue to beware of is speed - however, if you prototype your application in wxPython, you can then switch to wxWindows and C++ for any parts that are performance critical (in fact they may not even be GUI related). However, if you are using VB, I'd imagine that Python give similar performance.
        • Agreed, I have thrown together VERY complex GUI applications in about a month with wxPython. I recommend it highly. You can even package Python apps as executables (unless you use annoying things like some of the Python CORBA ORBs which seem to not work with the freeze/whatever tools).


          wxPython is definitely a superior language to VB for quick and dirty but powerful GUI development. Though I still find Python, like other weakly typed languages, gets REALLY unwieldy in large projects. You really start to MISS that all the parts of the system have a contract with each other (i.e. enforced typing in method calls). But hey, if you are in VB land right now, this won't bother you.

          • If you are making complex GUI apps quickly, then you must be using a decent dialog layout editor. Which one? The last time I looked (about a year ago), there was nothing that I really liked. Although I found PythonCard and liked it enough to use for some quick 'n dirty stuff (put a pretty interface on what is essentially a batch file).

            • Actually I use Robert Roebling's wxDesigner. Some people seem to think it's not that great, but I prefer it to tools I've used for other languages. Admittedly, there are a couple of strange widgets (wxNotebook comes to mind) that it refuses to show in WYSIWYG fashion as of a few versions ago, but pretty much everything I needed to do in a dialog layout tool, this does.


              I generally dont mind stringing together all the dialogs, menus, etc. of a GUI app manually, at least in Python/wxPython, since it's so damned easy to do.

      • C++ Builder is your friend.

        Unfortunately the visual builders for wxWindows have never matured much (IMHO) -- certainly they don't have the professional finish of VB or C++ Builder (which is far superior to VB for form design).

      • 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! :-)

      • Accually, you desperatly need to take a look at Kylix/Delphi/BCB from borland. Delphi is basically a cleaner VB. Right now there is a Linux port called Kylix which pretty much allows cross platform gui development. Of course it only runs on Linux/Windows, on the other hand I guarantee you will like it more than the assortment of other cross platform GUI toolkits like wxWindows & QT. Part of the VB advantage is the integrated enviroment with the way you just drop components, changes a couple properties, click on their events a write a couple lines of code and call the application complete. QT's designer is getting this way, but right now It doesn't have the component support the professional version of Delphi/BCB/Kylix have or the simple COM/ActiveX/etc target and use abilities that VB & Delphi have. I've got a small collection of 'demos' I show people from memory who have never seen what an eviroment like VB/Delphi can do. You know the kind, drop the database table component on a form, create a table with a key and a text field, tie the text field to a browser, add a couple lines a HTML into a few fields and demonstrate a couple cute tricks, or drop a scanner ActiveX (one of my development machines has a scanner) component on a form, tie it to a graphics box, write a couple lines of code tied to a button to run a RGB channel inversion filter or something simple like that.. It seems to amaze my C friends. Especially when I have one of those smooth days and do it all in under a minuite.
      • Check out this article [theregister.co.uk] and the link it has to DDJ about the reason why people use VB even though its really ugly. Hint it has to do with how productive the _TOOL_ is not the language or its libraries.
  • a new open source graphical windowing environment for small devices.

    This might not make sense, but I have been thinking about a windowing environment as a far larger concept. I thought the environment consist of all of these for example: X-Windows, Window Manager, and a GUI Toolkit (like wxembedded) --> wxembedded is NOT a windowing environment according to this description. I am asking this because it is about time for me to finally start using correct terms, if this is wrong :)

  • Screenshots (Score:3, Interesting)

    by Grip3n ( 470031 ) on Friday October 04, 2002 @01:51AM (#4385610) Homepage
    More screenshots of wxEmbedded (and specifically wxDesigner) are available here:

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

    There are images from it running under MacOS X, MacOS 9 as well as X11.
  • If you like wxWindows, you'll positively wet yourself over wxPython [wxpython.org]! (Ain't SWIG grand?) Can't wait for an embedded flavor of this!

    Yes, you can finally fling that VB reference manual into the river. There, it sits, until it's find by the most unlikely creature... "Precious.... precious!"... ooops. Sorry.

  • I was looking for a free cross-platform toolkit, and I came upon wxWindiows. It rocks! It's still in active development, and the developers give direct support on the mailing list. My latest project with it is at http://terraim.sourceforge.net.

  • wxWindows is pretty heavy weight compared to Qt, FLTK [fltk.org], FOX, etc., and the other toolkits (with the exception of Qt) are totally open-sourced with "designer" apps.

    We shied away from wxWindows several years ago because of binary compatibility issues (in the vendor GUI libraries, not in WxWindows) and because of the bloat. I'd be interested to see how wxEmbedded measures up...

    • The problem with FOX and FLTK is that they don't use native widgets, whereas wxWindows has wxWin, wxMotif, wxMac, wxGTK, and wxUniversal (the last renders its own widgets).

      FOX certainly looks a lot like windows ... which isn't so hot when you run it on Linux.

      FLTK looks like it combined the colors of CDE with the polish and smoothness of Windows 3.1. Hard to beat it for size though...
    • This is certainly true - there are quite a number of lighter toolkits. I haven't used wxEmbedded yet, but a normal wxWindows application isn't going to be that lightweight.

      The good news is that a maximal application isn't going to weigh in at much more than a minimal application.

      What sets wxWindows apart from most toolkits is that it's not just a widget toolkit - it portably supports file paths, configuration files and printing, to name a few classes.

      For many lightweight applications, these may not be appropriate. But as your application increases in functionality, wxWindows can keep up with it.

      Mind you, this is probably not appropriate for embedded applications.
  • I did a little playing around with wxWindows and QT about a year ago with an eye toward portint a Windows app to the Macintosh (yes, Linux would be nice, but try telling that to the bosses - and the app runs fine under wine already).

    Anyway, found that the QT signals/slots thing was really nice, but wxWindows was plenty easy to use, and its messaging system was more 'familiar' to somebody porting from Windows.

    But. The whole point was to get Mac support. WxMac was supposed to work under OS9 and OSX. So far, so good (QT3 is OSX only). But it seems to get very little attention. Strange for a project whose claims of portability are its main attraction.

    I've periodically checked out the wxWindows web site, and the Mac version is less and less prominent. Does anybody know if wxWindows' Mac support is coming along? Here to stay?
  • Here's a question. I'm a fairly competent Qt programmer, but I've never used WxWindows. What are the advantages and disadvantages of WxWindows over Qt? I'm not interested so much in cross-platform issues as I am being able to write good code that is easy to maintain.

Slashdot Top Deals

Algebraic symbols are used when you do not know what you are talking about. -- Philippe Schnoebelen

Close