Slashdot Mirror
Software Engineering of GUI Programming?
cucucu asks: "After ten years of programming for the network, I started programming a GUI Desktop application. My problem is most GUI tutorials out there are nothing more than a taxonomy of buttons, dialogs, and check-boxes. So as I checked GUI toolkits, I found that I can easily learn all the widgets, layouts, callbacks, and the like, and start coding a GUI application. However, very soon I found myself repeating code all over the place. Is there a good guide (online or off) for the Software Engineering aspects of GUI programming, so that I can learn how to reuse code, and build my class hierarchies over the one provided by the toolkit?"
In recent years the well-understood trade-off between gratuitous code repetition and gratuitous function/class creation has become one-sided in favor of the latter. One should avoid unnecessary code repetition but a few lines of code repeated in several places is not necessarily a class waiting to emerge.
There is no need to code your GUI with todays environments. Simply design it, "draw it", in an editor. If youre doing .NET, Cocoa, or Java it should be a breeze. Doing it all in code will basicly just take time, time you could spend on something better.
Is there a good guide (online or off) for the Software Engineering aspects of GUI programming, so that I can learn how to reuse code, and build my class hierarchies over the one provided by the toolkit?
Not sure if it is exactly what you are looking for, but I think a good starting place would be Designing Interfaces by Jenifer Tidwell from the O'Reilly collection. It helps if you are already familiar with design patterns, as the book casts its concepts in terms of patterns.
I would think that if you are an experienced Software Engineer and programmer, you would be much better served by something targetting the fundamentals of interface design. You can apply what you learn to any language or toolkit you know now or learn in the future. If you target a particular language or toolkit from the beginning you will limit yourself and make it harder to apply language-specific or toolkit-specific things to a different language or toolkit.
I designed a new web browser, it uses a professional interface, here is the code:
10 INPUT "Enter the URL: "; U$
20 PRINT "Finding "; U$
30 PRINT "Opening "; U$
30 PRINT "Slashdot. News for nerds, stuff thats happening"
40 PRINT "1. Ask Slashdot: Software Engineering of GUI Programming?"
50 PRINT "2. Ask Slashdot: Can a Manager Be a Techie and Survive?"
60 PRINT "3. Your Rights Online: China Jails Porn Site Leader For Life"
60 PRINT "4. Close"
70 REM
80 INPUT "Select your destination: "; I
liqbase
Most people don't seem to think about refactoring their GUIs; already there's one post here telling you not to code your GUIs but use the pathetic drawing tools to create them, even though GUI builders are evil, and one of the very reasons they are evil is they preclude even the simplest refactorings. The bulk of programmers seem to be happy about that.
My experience is that there really isn't anything special about GUI refactoring vs. any other kind of refactoring, at least in the languages I use. That may be a factor; dynamic languages like Python or Ruby seem to be a lot easier to implement "Don't Repeat Yourself" in. You may find you'd be better off switching to one of them, especially if you're trying to work in Java, with seems to elevate repeating yourself to a moral imperative.
But beyond that, I don't really see what's special about GUIs.
The other thing is that when you are first learning an environment, you need to cut yourself some slack. No matter what you do, your first few cuts will suck as you are getting your bearings. I'm all about refactoring and testing, but when I recently picked up Django, I didn't worry about either at all in the first week. Now I have to go back and re-examine everything I did and get the testing going for it, but I don't see any practical way to avoid it; testing my initial garbage would just increase the investment into code that I'm basically throwing away anyhow. (As I have a lot of web experience, that's probably faster than usual; any other framework type would probably take me longer.) You may find that you have built "one to throw away"; consider actually doing so.
Alright, I'm a little busy right now so I won't go into as much detail as I'd like, but here are the basics as far as I understand them.
:) Hopefully other people will have more details to give you.
1) Design patterns still apply. More than ever, actually. If you've not read the GoF, it features a pretty advanced example centered on the design of a rich text editor. You will probably want to dive deeply into the workings of the Model-View-Controller pattern and the related design constructs. The MVC pattern is not the be all and end all of GUI design, and there are many cases where the articulation between View and Controller
2) You may not now it yet, but you want loose coupling. Loose coupling means that, essentially, when a widget's state change, it will report on that change, and some interested party will be notified about it, and neither will have to know anything about the other. Many toolkit nowadays come with good signal and slot mechanisms to implement loose coupling. Understand them, and use them. If you find the sender of a signal and the receiving slot need to know about each other, you may want to go back to the drawing board as suggested in point #1 above; it is usually not necessary.
Conceiving GUIs is not all about the underlying software architecture, though; a good chunk of the work of making great interfaces is in the designing of the GUIs themselves (which is why you want loose coupling -- you WILL have to be flexible against changes as you experiment). I will let others fill you in about that. Quickly: read usability guidelines and get a feel for why they suggest what they suggest. Align your widgets! NetBeans is good for this, IIRC. Use GUI designer tools, experiment more.
That's all I can think of off the top of my head, but there's already a lot for you to chew in there.
All in all, it boils down to the usual rules of engineering: the second rule is to know what works, and the first rule is to know why it works.
-- B.
This sig does in fact not have the property it claims not to have.
Don't forget Mono and Gtk# too!
How are Gnomedevelop/KDevelop at simply "painting" instead of "coding"? Anyone know?
Here's to the crazy ones
You want code re-use?
Object oriented design techniques work equally well for all areas of software engineering. Don't think there is some "special" technique for GUIs.
There are all kinds of User Interfaces out there, and the simple elements such as buttons and boxes are popular mostly because they constitute the huge majority of "conventional" expectations. Tcl/Tk will give your a little more control over offbeat interactive elements, and early game books for C/C++ programmers will give you even more. What you learn from a book like Charles Petzold's, "Windows Programming" 5th Ed. will give you even more control over what happens on the screen. Petzold wrote some great books, and his books on C# and VB.Net are also terrific. That will cover the basics of controlling what is seen on your screen very elegantly.
IMO, design considerations fall into two categories; Visual design and Usability design. Check out some of the features of Croquet and Project Looking glass. Neither of them is totally up to speed visually, but they are creating new usability. A flight simulator or game requires a different approach to make it usable. You might find some ideas there. Here's a question: How come managers are still reading reports to manage their business rather than simulating the business operations through a game interface? How come reports are still 2-Dimensional? Back in the early 80's I remember seeing an accounting program that allowed you to drill down in layers from the final reports to the details. Wish I could remember the name.
Last guideline: Never let your Visual Design (or bad taste) detract from your usability.
"The mind works quicker than you think!"
I don't have any links to provide, but these few tips might be useful:
1) Don't duplicate code. The second time some functionality is used, create a library function. Try to think of the variations required and maybe add extra parameters to the function to cater for them.
2) Be consistent in your approach (similar wording on dialogues, standardized placement of objects, consistent use of terminology).
3) Think of your user. Determine your minimum resolution (eg 800x600). Will some users want keyboard navigation/use of your application?
Sorry if this is stating the obvious, but these 3 are rather important on my product (ASP.NET/C#/JS).
Large-Scale C++ Software Design by John Lakos
The book does not specifically address GUI design issues; however, it will help focus your efforts even if you're already fairly familiar with modular design principles.
---
Book recommendations aside, I'd like to add my own two cents about GUI architecture problems. In my experience GUI toolkits tend to offer the appearance of component-level modularity, but the underlying GUI primitives allow end-runs around that modularity (e.g. the Win32 API allows you to query or modify parent-child relationships). This is compounded by user expectations for GUI elements do not fit the direct parent/child model.
Consider a button (e.g. "back") or slider control (e.g. zoom level) on a floating toolbar that interacts with a certain type of view in the client area. Sure it's "easy enough" to make a special-case for a limited set of controls and views, but things quickly get muddy as the number of controls and/or views explodes, or if you want to implement the view in a DLL/shared object and ship it separately. Thus the "proper" solution in this case is to design a special interface for the toolbar elements and the view; however, sometimes it's unclear which (if any) toolbar elements actually belong in the interface. In fact, it's probably most appropriate to let each view class define its own toolbar to be activated by the framework when the view becomes active (note the emphasis against allowing the class to perform such activation by itself).
Here's a basic pseudo-layout of what I'm talking about:
(your-app-main-window
(non-client-area (toolbar-manager (toolbar (various-buttons-and-controls))))
(client-area (MDI-frame-window/view-manager(MDI-client-window (abstract-view)))
)
And here's how you'd design the class interaction:
(dll/shared-object
(private (manager-class
(toolbar-class)
(view-class)
))
(public (onload-function
(register-manager-class)
))
)
Let the abstract view define its preferred toolbar. When the active view changes, framework notifies the toolbar manager to perform the necessary adjustments to disable the previous toolbar and if necessary create/display the current view's toolbar. This also lets the implementor of the toolbar/view create the necessary callbacks from the toolbar to the view.
GUI's used to be simple in the VB/Delphi days: drag and drop widgets, and then set attributes and fill in methods (on-click, etc.). One used to spend a only few days building GUI's, now they take weeks and months to get how the customer expects them.
Some argue that such tools do not scale for different screen sizes. However, it is possible to build a "stretch zone" so that key widgets can stretch. But even if nested-based GUI's (like HTML) are used, it should not significantly change the nature of the method/attributes setting approach.
People seem to attack the VB/Delphi approach with elistist-sounding rhetoric, but none of it stands up to scrutiny. I think they are just defending their high-cost feifdom. The VB/Delphi style was near the pinnicle of GUI development (minus the stretch zones) and we went backward instead. Java, Smalltalk, and Web approaches ruined a good thing. MVC is a mess only a mother could love.
I think VB/Delphi-style will return one of these days because it was K.I.S.S. done right. GUI's are inharently visual, and thus visual design tools result in the most effeciency and closest match to the domain at hand (Visual GUIs).
Table-ized A.I.
Languages like C, Java, C# and C++ just don't offer the language features necessary for truly effective GUI programming.
What you need is a language like Smalltalk or Common Lisp. Smalltalk is exceptionally good for GUI development, but the performance and integration with existing platforms has often been somewhat problematic.
Common Lisp gives you what you need to minimize code duplication. Macros allow you to extend the language in amazing ways, for instance. But again, the main problem with using Common Lisp is the lack of solid integration with existing platforms.
It sounds as if you are looking for tricks to make GUI programming easier rather than software engineering practices to build GUI interfaces. It's my opinion that as you program you can come up with your own methods to do that; however, you might want to check out the book "Professional Java user Interfaces" by Mauro Marinilli, Wiley Publishing. It doesn't seem to have many tricks, but does seem to focus on the software engineering aspect of GUI programming.
Make sure to look through the book before purchasing though as I am not certain that this is what you are looking for.
Lando
/* TODO: Spawn child process, interest child in technology, have child write a new sig */
Ask yourself what design pattern will best meet the needs of the application. Model-View-Controller is very popular. The GUI is the view portion.
As a software engineer turned UI designer, it seems to me that when the UI gets re-done, it is either trivial (change this word, so you change a properties file), or a complete overhaul. UI layers don't get maintenance the same way other layers do. Lots of people see them, so they change dramatically when there are problems.
So I think it's best to take as much as possible out of the UI code and make it a really simple, almost disposable, client of really good APIs to the rest of the system. Simple is not necessarily elegant or clever. Simple might just be straightforward. If you have to add 100 countries to a list, it's OK to do that in 200 lines of code if those 200 lines of code are obvious in what they do.
If someone knows the GUI toolkit, it shouldn't be hard to look at a screen and match it up to the relevant code. Just because you don't know it yet and could just as easily understand something you write yourself doesn't mean you shouldn't consider that there are more people out there who know the toolkit and its tendency to cause code to be repeated. They probably look at those sequences and read them without a second thought.
Some resources:
Apple's User Interface Guidelines; adapted from the NeXT/OpenStep Interface Guidelines (PDF).
There's also the Classic "Macintosh Human Interface Guidelines" for System 1 through OS 9 (have to hunt it down yourself), GNOME's HIG,KDE's, and Tog's.
Without reading through them all, I can't point out where they address BPs for reuse, management, etc., but I know it is touched on somewhat (although from a NeXT slant) in Apple and NeXT's guidelines.
I'd like to know what kind of repetition you are seeing. Some of the posts here point out you will need controllers that are specific to your application. If you are seeing repetition there, then it may be an issue of wanting to reactor the UI itself and not the code. If you are copying the same draw(getIcon(MY_COOL_ICON)) then maybe you do need to subclass some pane to hold your icon. Also, at this point, most GUIs can be built nicely with the GUI Editors. Naturally you can make your UI better if you put more work into it. And some things still have to be done fully custom, e.g. you want a hexagonal window instead of the default rectangular or some such. I think what you may find, is that smooth, well designed interfaces that look good visually take a fair amount of effort.
The really difficult part is to make your GUI usable - particularily if your GUI contains any autonomous information (eg. alarms); information from disparate sources/applications and/or your underlying application is complex (eg. a combat system)
At that point you really need to workshop with your stakeholders on use cases;
How many clicks are needed to get to any function?
How well trained/tired/busy/stressed are your human operators?
How many modes of operation are there?
How are you going to manage "status" and "alarm" displays across the suite of screens?
What happens when some application starts struggling/crashing/spewing data?
Training and documentation (user manuals, trainer manuals, debugging manuals) also need to be considered - it's all part of the experience.
At the pointy end of the business, various layouts/schemas are compared by measuring operator hand and eye movement loads!
Ps - For any reasonably complicated GUI you will want an API between your text/visual _specification_ and your code
-- Butlerian Jihad NOW!
Something I've learned the hard way: Never modify any GUI stuff outside the main event loop thread. Well, in Win32 it is possible to get away with it (but you must know what you're doing - i.e. painting to a back buffer is OK, but not drawing into a window). In Swing/AWT you can use SwingUtilities.invokeLater(Runnable) (don't pass anything that extends Thread to it or you will make uncollectible garbage). There must be something similar in the other GUI frameworks out there.
Ive come across this problem many times over the years. I can give you some advice in Windows, which is where I have the most experience: To reuse UI code easily, use a library that exposes the Win32 GUI API as a class hierarchy, like MFC. You can derive from classes to specialize a control, and reuse the base class handlers and such. To reuse the UI itelf, use a "sub-control", to do that easily in windows create a dialog without caption, put the controls you want in the dialog, and in properties make sure to set "control" and "control parent". Then put the code as you would normally do with a modless dialog (there are a few gotchas but once you get them all in a base class you dont need to worry about those anymore). This is like a cheap version of an activex control. Also, In MFC and other libraries there is a mechanism added to the win32 api called message refleccion, which allows a message that is normally received by a parent window, to reflect back to the control itself. This allows you to have a windows control handle itself, and thus you can reuse it.
I wholeheartedly recommend this Martin Fowler's article to start with.
When I had to learn good techniques for building swing apps I looked at other projects. Luckily someone I worked with at the time 'got it' so I was able to see a project that used Actions, applied MVC and interacted with the event thread correctly.
so that I can learn how to reuse code, and build my class hierarchies over the one provided by the toolkit?
Believe me, desiging a class hierarchy is NOT a problem, it's much more difficult to learn to design good GUIs, after all they are the 'contact point' with the user, so clarity, simplicity, predictability, etc are the real challenge, it takes a lot of imagination and experience to design GUIs that doesnt get noticed!
What's in a sig?
This looks really interesting: Adam and Eve
Has Anyone tried it out ?
It looks like they take the approach of using a domain specific language for building the GUI.
Simon.
I'm not sure what you're doing in your gui, but here's my own $.02. (Note: this is Java related more than anything else, though my thoughts could be extended to C# I'm sure)
If you're going to have several smaller windows in your app (dialog boxes and such), I would suggest possibly creating some wrapper classes that have the the basic dimensions and alignments for the template you're trying to follow, so that you're not repeating code like assigning sizes and buttons and such.
As far as design goes, you could try a factory setup and have several wrapper classes (as mentioned before) that are allocated in some static class somewhere and make calls for different parts of the GUI using reflection. This would cut down on memory usage but thread safety could become an issue.
Code repetition can be a tricky thing to assuage depending on the scope of it. As others have said, that's not always an indication that you should go write another class to handle it, but if you're calling several methods of GUI objects and they happen to be the same methods, wrapper classes may be a good fit for you.
I remember that, but that isn't what I ws thinking of. I think the product may have been called something like, "NewView Accounting", but I'm not sure.
"The mind works quicker than you think!"
As the book predates the widespread use of OO, it has a kind of proto-OO or proto-object in the form of "communicational" modules -- collections of functions that operate on some common data organized in a data structure or a name space. The communicational-strength module, of which there is a lot of support in Modula-2 and pre-OO Ada, is kind of like a static or perhaps a singleton object, and the reason for this kind of programming is that back in the day dynamic memory allocation was regarded as being fraught with peril -- either too expensive or too risky in terms of heap fragmentation. Remember also the computer speeds and amount of memory that we had compared to today. Classes and their objects are really the communicational module applied to where you have good heap management algorithms and perhaps even GC as well so you dynamically allocate an allow multiple instances of things and don't worry.
I wish there was a latter edition of "Reliable Software through Composite Design" that addressed OO in some ways, but Martin Fowler's works on refactoring comes close. What I also like about Fowler is that all of his refactorings are reversable so if you find that you have too many code snippets in functions, inlining the code snippets and eliminating the functions is an "allowed" process instead of something you are scolded into never doing.
As to cut-and-paste, whenever you see yourself using the text editor to copy any block of code to replicate the same functionality, you are asking for some kind of trouble at some level. The whole problem with cut-and-paste is that your code is littered with multiple copies of the same function, perhaps with some minor variations, and if you have a bug in that sequence or need to revise that common functionality, it is a lot of work to search it all out in your code and fix it.
On the other hand, many times that repeated sequence of code doesn't lend itself to a proper kind of function and you have so many customizations of that function or flag parameters to that function (Glenford Meyers really lays into flags as function inputs and explains why -- I guess Microsoft didn't read his book when doing the Windows API).
A lot of the idioms of programming languages -- loops, functions, objects, macros, anonymous functions, etc -- are efforts to avoid cut-and-paste, and if you are programming in a weak programming language (dunno, like .bat or perhaps VB), you end up with cut-and-paste to do the job rather than wrestle with the language. At some level, some degree of repeating yourself in code is unavoidable and introducing higher-level languages (closures? functional programming?) to avoid this may be unavailable or perhaps in itself introduce obfuscation if these features are generally not known to your maintenance programmers. So if you are left with some cut and paste, don't sweat it.
ActiveX is a remarkably powerful system for visual component software -- restricted to Windows, yes, but supported by many programming languages ranging from VB through Delphi to Matlab. It is also remarkably crufty so to either develop for it or to use it you end up using some form of "wizards" and automatic code generation. And yes, the use of ActiveX on Web sites, especially malicious Web sites is evil, but such things like Flash and some of the free anti-virus sites are delivered through ActiveX. You could also disable all Internet ActiveX and still be able to use client apps on your computer using ActiveX -- there is hardly a major Windows app that doesn't use ActiveX at some level anyway, so if you are to dismiss ActiveX, there is little you can run under Windows.
Delphi is a remarkably powerful tool for developing ActiveX controls as well, and I like it better than the VS/VC++ approach because I find it to be more flexible in tinkering with COM interfaces until you are ready to publish the control. Delphi ActiveX development requires some faith in wizard-generated code (actually, GUI development in Delphi is remarkably free of wizards and auto-generated code because the VCL base classes have so much of the functionality in them, but ActiveX in Delphi requires it). You will also have to become friends with the Type Library Editor -- the Delphi way of writing and maintaining the IDL code that is the plumbing of COM and ActiveX. The Type Library Editor is buggy and has its quirks, but I find it much more powerful for inspecting and modifying COM interfaces than any of the MS tools.
You could do a lot worse than to check out SWT / JFace / Eclipse RCP Framework.
m -Applications/dp/0321334612/sr=1-1/qid=1164595827/ ref=pd_bbs_1/103-2317093-7394243?ie=UTF8&s=books
...
t form
If you haven't heard of these things:
* SWT is a relatively low-level cross-platform widget toolkit. It is at around the same level as Qt, GTK+, and the GUI bits of MFC.
* JFace adds a layer of abstraction on top of and is built to work with SWT...helping you effectively split your widgets and the data feeding them in nice ways. It also provides a whole lot of convenience classes for doing common things more easily.
* Eclipse RCP (Rich Client Platform) ties all the above together in a huge framework for building any sort of GUI application. This is where you will learn the most about design pattern applications to GUI projects. Eclipse itself is built using this framework.
The learning curve can be a bit steep if just starting, but I haven't come across anything so well put together before. It's full of lots of good ideas.
Even if you choose not to use it (or can't use for good reasons) you will learn a great deal about how to put together a GUI application and how to apply certain patterns and techniques effectively. A few well known "gurus" have been involved in the design and you can be sure that a lot of effort has been put into the architecture and deciding what works and what doesn't in terms of patterns and techniques.
This book is a really great way to get into it all:
http://www.amazon.com/Eclipse-Rich-Client-Platfor
And for more info
http://wiki.eclipse.org/index.php/Rich_Client_Pla
I agree with all those points, including the hurdles in getting resources going such as icons - could be lot easier. Also, talking to legacy stuff via COM interop is really well done. As has been mentioned it takes almost no effort to do it. Building forms and dialogs is real easy and the IDE remarkably stable. I got sick of doing all the plumbing and myriad datatypes for COM in C++ but I can really get some work done in C#!
I would highly recommend that you try and use the VCL (Visual Component Library) components which comes with Delphi and C++Builder. C++ Builder or the Delphi Turbo tools are now available free (the professional versions costs money though - approx $340).
VCL is exceptionally simple but yet very robust and customizable. Search for "Delphi Super Pages" for additional VCL components, sample code, and all sorts of other goodies.
I didn't see this mentioned in other posts, but I think it's very important:
Decouple your GUI from the code that does the work.
I really don't have a lot of experience with GUI programming, but I do know that there are many different toolkits on different platforms, each comes with its own guidelines, and these guidelines are subject to change over time. At some point down the line, you or someone else is going to want to change the GUI, while keeping the functionality. Moreover, you or someone else may want to drive the application from a script, or from the command line (some platforms may even require one or the other for applications that are considered good citizens). In other words, your application _is_ going to have more than one interface - make sure that is easy to accomplish.
Please correct me if I got my facts wrong.
I've built a lot of web pages, and this has made me realize that it's incredibly quick and easy to whip up GUIs with HTML. The experience was much better than with the GUI builders I had used, and certainly beat coding GUIs by hand.
Of course, HTML is not intended as a language for describing native GUIs, so it has some limitations there. Fortunately, there is a variety of XML formats for describing real GUIs.
What makes XML so great for describing GUIs is that it's so good at describing nested objects. If you think about it, that's exactly what GUIs are: you've got your windows, with a bunch of widgets in it, one of which is a scrollable area with more widgets in it, etc. This is naturally described by an XML tree that contains all these widgets, with some attributes used for connecting them to the application; e.g. ids to allow the application to reference widgets, and embedded code to let the GUI respond to events (e.g. HTML's onclick).
Where many XML GUI languages fall short is in that they don't provide methods for building new abstractions. If you have a lot of subtrees that are all very similar (say, a frame, a title, a content window, and a hide and a show button), you'll completely have to code each of them in full. Any programming language worth its salt will provide a way to abstract over this (functions!), but I think the realization that XML GUI descriptions (and HTML documents!) are programs hasn't fully set in yet.
Next time I'm coding a GUI, I'll be generating the XML from a proper programming language. I've had good results with Lisp before...
Please correct me if I got my facts wrong.
``If only Microsoft had fixed it to allow distributing C# applications with their own stripped-down runtime included, instead of requiring administrative install of the full 20+ MB .NET Framework including ASP.NET and who all knows what crap you don't need, it probably would have replaced C++ for many applications already. Something like perl2exe for C# is what I want. Just bundle the runtime and the JIT and your code up in one nice tidy ready-to-run executable. That would do wonders for the adoption of C#.''
.NET is a runtime with a bunch of libraries, split it up accordingly, and have everything depend on just the pieces it needs. This would (1) make keeping Windows machines up to date a lot easier, and (2) solve the problem you complain about. Of course, they don't have to actually do the packaging themselves (like Debian does), as long as they provide clear and easy steps to enter a package into the system.
Maybe they should do like Debian and (1) have a proper package manager that tracks updates and dependencies, and (2) realize that
Please correct me if I got my facts wrong.
I have been using JFormDesigner for Java for about a year now. I think it is quite decent.
I have previously used the Qt designer, up to version 3.3.4, and it was OK. I still found I needed to tweak code and layouts specifically for the target OS. Perhaps that was due to lack of familiarity with the tool.
I simply expect a GUI designer to relieve some of the tedium of hand coding a layout, especially those with obtuse interfaces, like grid bag. If the designer also can provide a way of hooking UI elements to the code, without generating code that is a pig's ear, then that is a bonus.
If a GUI designer could generate dialogs and other elements that looked perfect on each platform from a single specification, then that would be the holy grail for me.
There are ways other than just signals/slots and MVC to architect a GUI. Anyone interested in being able to test an app with an interface (not just graphical) should look at Presenter First design. It's a simple design pattern that helps guide you in decoupling your view from your presentation logic and it's data model. Combined with Mock Objects and Dependency Injection, esp. constructor injection, MVP can provide a strong backbone for any GUI application.
evolution IS god.
As an alternative to ActiveX, I am looking at Java Swing. But it will be a while before I get my stuff rewritten, so I have still have an interest in the Windows API and in ActiveX.
The original discussion was that Delphi was good for arranging pretty widgets but if you wanted to develop new widgets you had to drill down to C++. My suggestion was that in some regards Delphi may be a better development environment for ActiveX than the MS C++ tools. I am not saying that Delphi makes ActiveX a breeze, but it makes implementing ActiveX controls tolerable.
The thing is that if you have an underlying operating system, it is helpful to have a language that incorporates the idioms of that operating system into the language itself. C++ is not that language, at least not for Windows, largely because C++ is a platform-independent standard where you can't just stuff features in the language just because they are convenient for Windows, although Microsoft has tried mightily to sneak them in.
Just as the Java language has built in support for the features of the underlying JRE, the two languages that have Windows support built-in are VB and Delphi. Everything from message maps to BSTR's to Variants to Dispatch interfaces are just plain painful mixes of #defines, classes, templates, and wizards in C++ while they are language features in VB and Delphi. I am not saying the C++ is deficient, but the way Microsoft decided to use C++ to use their OS-specific features is painful. The C-language and the raw Windows API are a little verbose, but you can pretty much figure out message loops and giant case statements to see what is going on, but once Microsoft went to COM/ActiveX and threw C++ into the mix, the result was an OS-specific extension to C++ using legal C++ extension mechanisms but done badly. What MS did with VB and what Borland did with Delphi was to add OS-specific features into those respective languages so all of the cruftiness of COM was hidden away.
OK, if we are talking ActiveX and the task at hand is to develop ActiveX controls, what tool does one use? There may be a VB way that is every bit as capable of the Delphi way, but I never looked into it. I have implemented ActiveX controls in Delphi and I have dabbled at implementing ActiveX controls in VC++, and there are things to recommend about Delphi. Look, C++ is a great language, and people tell me that C++ is a great GUI programming language (the parent post topic) if you are using Qt, but there is a certain impedance mismatch between the way MS went about using the C++ extension mechanisms to handle their own COM and ActiveX features and low-level data types. You really think MFC is an example of a good C++ class library? ATL for all that matters?
The Microsoft C++ solution of macros, classes, templates, and wizards is so painful that even Microsoft abandoned it and went with C# and Windows.Forms. Case in point -- C Windows API guru Charles Petzold who stated he could never grasp the MS C++ solutions in the form of MFC and ATL but found himself once again at home with C# Windows.Forms and wrote his next book. C# by the way is OS-specific -- the CLR-specific string type for example is a primitive type in C# rather than something synthesized from classes and templates.
I am not saying Delphi rocks, Delphi rules, blah, blah. All I am saying is that there are reasons for developing and maintaining ActiveX controls because so much in the Windows world supports it, that Delphi makes ActiveX implementation tolerable, and the Delphi Type Library Editor allows extending as well as trimming COM interfaces during the development phase before the COM object is published and the interface set in stone.