What GUI libraries should be used?

[DanHughes]

We are wanting to determine how important it is to be cross platform capable.

[Clay Martin MWI]

I think that being cross platform(CP) is very important for the long term viability of ME. Using a code base that is designed to be CP means that it is likely that if a new platform comes along it will be quickly added.

Having said that, I have no familiarity with either QT lib or wxWidgets. I looked over some of the online doc/tutorials/reviews. Seems like it is a toss up or there is some vital issue I am not seeing. Sort of blueray / HDDVD. One thing I did not see for either is references to how quickly they will adapt to the next effort of MS to dramatically change its OS. DocX indicates how little they care for backward compatibility.

On the (possibly frivolous) reasons of more projects using Qt and Qt draws its own widgets on each platform (possible less CP bugs) I guess I throw in behind Qt, but it is a barely informed opinion.

[AndyColson]

Writing in delphi and using the QT library? Is that even possible? Same with wxWidgets... its not possible to even use from delphi is it?

And, even if it is, that wont make the program cross platform, because delphi cant create linux or macos executable.

Unless your thinking about switching compilers/languages? Or am I way off base here?

-Andy

[daantje]

Maybe the .NET option is missing (maybe even in a portable form through code that compiles and runs for both Windows and Linux (through Mono).

In general, would a switch to .NET not solve a great lot of the Unicode issues?

Daniël

[arjan]

It doesn't really matter to me which GUI library is used, but performance and memory usage does matter. (That's why I've banned .NET frameworks from my computer )

Unfortunately I've seen other projects switch from native Windows to a cross-platform library, resulting in a bigger, slower app. For instance the new Perforce GUI client. They've switched from native Windows to, I think, QT. And their new app is a nightmare to work with, partly because of the poorer performance, partly because it doesn't behave as one would expect from a Windows app.
Or compare the .NET-based Delphi IDE's with the latest 'normal' version 7. Not surprising that a lot of developers stick with version 7.

For MultiEdit I think it's important to stay lean and mean. If you want to edit a text file quickly, ME should startup in a second or so, like it does at the moment.
Of course it's great if ME would run on multiple platforms (Linux, Mac), but it should not result in a Windows version that's a step back from the current version.

Well, that's my opinion anyway

[samej71]

I would think moving to a non-custom library might be good. That way you can skip the pain of trying to add Unicode support to GUI yourself and can instead concentrate on other aspects of ME (no use reinventing the wheel).

I don't know about performance differences between the different GUIs.

I've recently started playing with Lazarus again (an open source Delphi built on top of FreePascal). It can cross-compile Linux/Mac/Windows, and even has support for cross-compiling to Windows Mobile (a special project type is needed for that). It not as polished as Delphi, but it's really coming along nicely and I've used it for several projects (I can't afford Delphi's prices anymore).

I personally haven't tried the cross compiling, but the Windows Mobile has my eye since I now have a WM cellphone.

I don't know how it accomplishes the native GUI look and feel, but here are some screenshots from Linux, Windows, and Mac OS X Tiger (respectively):
http://wiki.lazarus.freepascal.org/Imag ... E_GTK2.png
http://wiki.lazarus.freepascal.org/Imag ... ows_XP.PNG
http://wiki.lazarus.freepascal.org/Imag ... 0.9.25.jpg

Some information on the GUI support in Lazarus from http://en.wikipedia.org/wiki/Lazarus_(software) :
==========
The current status of Widget toolkit Interface is roughly like this:
Win32 GDI support (win32 native) is in mainstream use.
GTK+ 1.2.x is in mainstream use (Unix derivatives including Mac OS X)
GTK+ 2.6+ is fully working and in mainstream use.
Qt 4.2+ has headers translated, and the interface is fully implemented.
for Cocoa (Mac OS X native toolkit, Objective C) there are bindings and a initial interface.
for Carbon (Mac OS X native toolkit, C) is in mainstream use.
wince (Windows CE native) is almost fully working.
fpGUI (Free Pascal GUI toolkit) has a initial interface.
==========

No changes are required in the program when compiling for a new platform, the actual interfacing to native GUI controls is handled within Lazarus itself.

Anyhow, I don't know if this info will help or hurt your decision making process.

If most of the controls are custom (versus Delphi VCLs, etc), have you tried compiling the ME source in the latest build of Lazarus to see what happens? I've never migrated a Delphi app to Lazarus before, but supposedly it can be done with only minor tweaking.

--James

[Jonathan]

Having just bought a Mac mini, I'd love to be able to use use ME on it.

[Michal Vodicka]

It is hard to write a portable GUI app. It is possible but the result has a lot of limitations. In MEW case it would be especially hard as a big part of code is written in CMAC and Win32 calls are often used there. It is very flexible but almost non-portable. It'd be possible to disallow it but the flexibility would be lost.

What seems more important for me is to rewrite GUI using modern Windows libraries. MEW GUI looks very old now and I'm really missing some standard functionality. Also, writing dialogs in CMAC is tedious manual work. The best would be if MEW core accept resources created by 3rd party tools (as Visual Studio for example) and if it offers everything necessary to create modern looking GUI without any need to call OS directly. Then it would be possible to make MEW portable -- for every supported OS there could be a separate core and its GUI part wouldn't necessarily use the same underlying library.

[David Morris]

I agree that unless Delphi is abandoned entirely for a more modern, practical, future-proof development platform, there probably isn't much reason to consider anything other than VCL. Why shoe-horn a cross-platform widget set into Delphi, which is inherently NOT cross-platform? However it must be said that MEW has grown long in the tooth -- where it used to have little competition, today it has quite a bit. If it's going to distinguish itself in the market and thrive among that competition, then it needs to open up its market base and move into modern development times. Delphi ain't it.

OTOH if MESI is considering starting from scratch with open standards and cross-platform support in mind from the start, then you have a chance to propel ME forward. I tentatively disagree with Michael's statement that its necessarily hard to write a cross-platform GUI. You just have to be able to set aside preconceived notions that are often misguided or misinformed, and make it happen.

Some suggestions based on my own experience:

1. At the risk of being branded a heretic, Java is the ultimate cross-platform choice. And before people trot out the usual old saw about performance, you need to check out some quality Java applications: Eclipse, IDEA, Borland JBuilder's IDE from years ago, etc. Even jEdit is pretty fast if not a bit klunky. Memory intensive, sure, but what isn't (.NET certainly is) and memory is cheap and plentiful these days. Writing fast Java is certainly not impossible, and you'll have cross-platform capability out of the box. Put it this way: I was an ASM/C/C++ snob for 20 years. I was dragged into the Java world virtually kicking and screaming, only to fall in love with it. The only C/C++ I write these days is by strict necessity (drivers, JNI wrappers, etc.). Java is always my first choice now unless there is a compelling reason otherwise, which is a rare occurrence. In fact we're now writing Java apps to interface with industrial control systems, historically an exclusive realm of C/C++. And I've taken my Java GUI's that were developed entirely on one platform, dropped them on another (like Linux), and they Just Work(tm). Realistically there might be a small amount of platform-specific tweaking required, but generally nothing to speaking of.
   
2. Barring Java, I'd like to see ME rewritten in cross-platform C++, i.e. not MSVC but perhaps a gcc derivative like MinGW, which is what I use these days when I must code in C/C++ (Eclipse CDT is my preferred IDE today, with the MinGW gcc port for Windows, or standard gcc on *nix). Combining this with a cross-platform toolkit like either wxWidgets or Qt, and avoiding platform-specific code as much as possible, would break down most of the barriers to Mac and Linux ports as well.

Between the two, Java would seem to me to be the more productive option in terms of development time, unless the developers involved already have a firm grounding in C++ and wxWidgets/Qt. Java IDE's and tools are also more plentiful than cross-platform C++ tools. My personal choice is Eclipse for the IDE and either Swing or SWT for the GUI library. Netbeans is another popular and powerful choice. And not that it matters as much for a commercial software development shop, but these tools are also free with a huge community support base, which means a less expensive startup for your developers and contractors and a nearly infinite if less-organized base of support.

[samej71]

Hello,

I don't have anything against Java, but the few java apps I have (or have used) are significantly slower than their native counterparts and can have other issues (of course, an app written in any lang can have issues, but I think the issues are in part from the JRE, which I've kept up-to-date).

I've used a free editor for awhile (jEdit, I think). The launching performance (in part, because it had to load java) was really bad. I've also had garbage collection (memory) and redraw issues in a Java SQL app. Overall, I haven't been that impressed with desktop apps written in java.

If I had a vote, I'd like to vote for staying with native binaries just based on personal experience (which I will concede does not translate to everyone's experiences).

--James

[Michal Vodicka]

I have similar experience with Java apps and even worse, I hate Java apps and applets. They're exceptionally slow and ugly. Java idea itself isn't bad, anyway MEW uses a form of p-code since DOS times, but I never saw good implementation of Java. I addition, there are incompatibilities between JREs so some app needs some exact version and the other app other but also exact version.

My overall bad experience caused I'm really biased but I'm affraid it is common feeling about Java a many programmers would refuse MEW without trying just because it is written in Java. Including me, I have to say.

[David Morris]

Unfortunately these are still prevailing attitudes among many regarding Java. I myself held it until I got more involved with Java development. However these days this perception is not grounded in reality. I can assure you that properly written Java is more than up to the task and the user would not suffer for it. In fact you might be surprised to find that some apps you've run were written in Java and you never knew it. Sure, there are horrible Java apps just like there are horrible VB and Delphi apps. Done right, however, you hardly notice a difference if at all, and you gain an immense amount of cross-platform and industry support out of the box.

To address some of your comments:

• Regarding Java performance, I've seen Java computation benchmarks that rival C++. Usually when Java gets blamed for poor desktop application performance, it's due to GUI issues. Swing has long been a bit of a dog, but in recent 1.5 and 1.6 Java builds has improved greatly. But I'm not necessarily married to Swing -- SWT uses native code and controls when available, and is as fast a GUI as any native one. It's also available for all major platforms, down to Windows Mobile/CE (which we develop SWT apps for too). Have any of you worked with Eclipse? It's hard to believe it's a Java platform sometimes, when you consider everything it does while you edit code (code completion, background building and other tasks, code outlining, etc.)
  
• The "issue" with deploying the JRE is a totally non-issue as well, because you can bundle whichever version you want with the application -- unlike as required with .NET runtime, you don't need to install a system-wide JRE that interferes with the customer's other Java apps. In fact that's highly discouraged. Nor do you require the user to download and install a JRE themselves. Those approaches might work fine for an open-source download app, but not for a commercial turnkey application. In fact there is no installation at all, the JRE resides in another folder underneath your application folder structure, totally invisible and isolated from anything else, and only used by your app. Trust me, I've done this plenty of times and it's seamless and completely non-intrusive for end users. OTOH if you want to allow the user to run your app on their JRE of choice, that's a fairly easy configuration option too, provided their chosen JRE is up to the proper level and has the minimum dependencies. So this is really a non-issue.
  
• The one drawback to Java compared to native GUI apps that I will concede is startup time, but it is getting better and there are ways to mitigate it. One rather drastic step would be compiling Java to native code, but I wouldn't consider even that to be necessary. In most cases, the increase in startup time is slight and quite affordable given the other benefits. For instance, as I type this I just started jEdit -- from icon click until opening with the last 3 files I was editing (including loading several plugins I added after initial install) took 6 seconds. Starting MEW 2008 took 4 seconds. Neither had been started in the last few days and the PC has been rebooted several times since, so neither benefited from caching. And I'm not holding jEdit up as a model Java app either, as I said before it has some rough edges, but it's still pretty slick and quite similar in function to ME, so I think it's a fair comparison anyway.
  
• Applets are a different animal entirely and cannot be compared to true client Java code. I hate them too, so you're not alone. Don't throw the baby out with the bathwater, though, by letting applet quirkiness define your opinion of Java.

Entirely anecdotal story: A couple of years ago we "forced" a die-hard .NET developer into the Java GUI world. He badmouthed it the whole way (talk about kicking and screaming!) and continuously argued against it, citing many of the same old reasons as mentioned here, but was essentially made aware that it wasn't an option if he wanted to keep his job. Now you can't keep him away from Java, he's a total convert. Talking to him the other day and ribbing him about his initial reluctance, he just says he's glad we made him switch. That's pretty much been the experience of each and every real life developer I've personally seen make the transition, myself included.

But it's really a moot debate at this point because I doubt MESI has given Java much serious consideration, but I wanted to voice my support for it as an option nonetheless, primarily because it never fails that in discussions such as this, much misinformation about Java will be dusted off and reused, and it pains me to see that.

[DanHughes]

I'm personally not crazy about C++ nor Java as I've used Delphi/Pascal for most of my professional programming so it seems easier to get things done with it. I also like many of the scripting languages such as Python, Lua, and Ruby but don't care for Perl. Other languages such as Modula-2, Oberon and Ada are interesting as well but not mainstream enough to consider.

One of the main reasons I don't like C++ and Java to a lesser extent is the difficulty I have is setting up projects in those languages. I like to be able to compile from an IDE or command prompt with the same ease. I compile Multi-Edit from a zsh shell using a script for "want" an Ant (Java) type program but written in Pascal. With Delphi it is easy to compile from the IDE or the command line and I don't have to deal with dependencies and all of the compiler switches as much as I do with C++. I can build, from scratch, a full version of Multi-Edit, Multi-Edit Lite, Multi-Edit Lite for SAS and mobileME in under 2 minutes. This includes all of the Delphi code, some C++ code and all of our macros being compiled. I doubt very much I could do it that quickly if it were all C++ or Java. I know incremental compiling would help but I tend to make small changes, compile and test frequently so compile time is very important.

Another reason Java probably won't be the language used for a future version of Multi-Edit is Eclipse. Why would anyone want to purchase and use a Jave based Multi-Edit when they could just get Eclipse for free? I'm not wanting to try to compete with Eclipse as Borland/CodeGear has learned. The only possible way to do it would be to build "on top of" and add value to Eclipse but I'm not sure there is a big market there as of yet.

At this time, I suppose we will continue to use Delphi and our current code base but rewrite what is needed to support Unicode for the next version of Multi-Edit. In the future we might consider starting a new version from scratch to get us the cross platform capability and probably have to select a different language than Delphi unless it becomes cross platform at some point.

[David Morris]

I'm personally not crazy about C++ nor Java as I've used Delphi/Pascal for most of my professional programming so it seems easier to get things done with it.

Dan, completely understandable -- most developers are going to prefer what they're used too. There's a long legacy of Pascal behind ME and it served well I think. I just think that cross-platform support alone is such a worthwhile goal these days that it warrants consideration of another development platform that is more suited to that goal, be that C++, Java, or whatever.

I also like many of the scripting languages such as Python, Lua, and Ruby but don't care for Perl. Other languages such as Modula-2, Oberon and Ada are interesting as well but not mainstream enough to consider.

Fully agree, I would never consider developing something like ME in a script-based language.

One of the main reasons I don't like C++ and Java to a lesser extent is the difficulty I have is setting up projects in those languages. I like to be able to compile from an IDE or command prompt with the same ease. I compile Multi-Edit from a zsh shell using a script for "want" an Ant (Java) type program but written in Pascal. With Delphi it is easy to compile from the IDE or the command line and I don't have to deal with dependencies and all of the compiler switches as much as I do with C++. I can build, from scratch, a full version of Multi-Edit, Multi-Edit Lite, Multi-Edit Lite for SAS and mobileME in under 2 minutes. This includes all of the Delphi code, some C++ code and all of our macros being compiled. I doubt very much I could do it that quickly if it were all C++ or Java. I know incremental compiling would help but I tend to make small changes, compile and test frequently so compile time is very important.

Here I guess is where we diverge in our opinion. I find Java and C++ inherently easy to setup projects for, and to build either from IDE or command-line. Maybe that's because I've been deeply involved with C/C++ for 20+ years, and nearly 10 years with Java, so it has become second nature to me. As you are already somewhat familiar with Ant since you use an Ant-derivative, you could use it for both Java and C++ builds. Or for C++, good old make which could be supported from both a command line and say Eclipse CDT. I build my C++ apps both in the IDE and at the command-line as needed, they both use the same project/make files. Likewise, I build my Java apps with Ant using the same scripts, whether from within Eclipse or at the command-line.

One thing Delphi/Pascal excelled at though is quick compile times compared to most other compiled languages. But to me that's a trade-off I'm willing to accept given the other benefits of the non-Pascal languages. Frankly C/C++/Java build-times are a non-issue with me, even less so with incremental building enabled, but then again I never used Delphi/Pascal enough to be "spoiled" by it.

Another reason Java probably won't be the language used for a future version of Multi-Edit is Eclipse. Why would anyone want to purchase and use a Jave based Multi-Edit when they could just get Eclipse for free? I'm not wanting to try to compete with Eclipse as Borland/CodeGear has learned. The only possible way to do it would be to build "on top of" and add value to Eclipse but I'm not sure there is a big market there as of yet.

Not sure I follow how writing ME in Java implies a direct competition with Eclipse any more than another language -- you're somewhat competing with Eclipse regardless of what language you use. Some developers hate Eclipse and would never want it, and I don't see how being developed in Java makes a difference to end-users looking for the best editor, it should be transparent to them. Again, consider Intelli-J's IDEA editor, or jEdit. ME and Eclipse are two completely different tools, Eclipse being a platform for building a variety of applicatoins, not only an editor or IDE. My current Lotus Notes v8 client, for example, is an Eclipse app. ME is a dedicated text editor with an emphasis on source code but not limited to that. While I love Eclipse as a Java/C++ IDE, it sucks at editing pretty much anything else that there isn't a specific plug-in developed for. It devolves into just a basic editor, and this is where ME can easily beat it.

As you're probably aware, one of your main competitors for years -- SlickEdit -- produces an Eclipse plug-in version of their editor. That would be a big selling point to me and probably other Eclipse users if it were an option with ME. Due to our corporate development environment I have to work in Eclipse (not to mention I really like it anyway) so being able to leverage my favorite ME functionality within Eclipse would be a huge win. If the editor core were designed with that in mind, in Java, then a large portion of the ME codebase would be shared between them. The standalone would wrap a GUI shell around the core, while the Eclipse plug-in would hook the Eclipse GUI.

But I'm just rambling (and dreaming) at this point. As I mentioned earlier I didn't expect Java to be given much consideration anyway, so I'm not pressing the issue, just addressing what I consider to be misconceptions. I would be more inclined, however, to press for a C++ approach over another Pascal approach, if for nothing other than cross-platform ability. I just don't get why you'd consider a cross-platform GUI toolkit (the original point of this thread) if you were going with Delphi again.

[Michal Vodicka]

A comment about C++: I wouldn't go this way although I write almost everything in C/C++ last 13 years. C was originally created for low level tasks and it is good for it although one needs a lot of discipline to create safe code. C++ has almost all its drawback and new ones. Creating a big project needs a lot of experience with language and very good rules for writing code. It has to be decided on the beginning what language features to use or not and how to design the code. I'm almost sure the first version of MEW written in it (at lest year of work) would have to be thrown out and started again from the beginning. We went this way. Our app team started with MFC, then converted to WTL and finally they rewrite all the GUI part to .NET.

The only reasonable possibility how to write MEW in C/C++ would be a small core and the rest of MEW written in CMAC or other similar language using the core functionality. However, this can be done as well in Pascal/Delphi and I believe it can be better for this purposes. Pascal is inherently much safer language than C++. It is a bit limited but for editor purposes it is quite sufficient. It is very easy to write unmanageable code in C++, in Pascal, it is harder.

The only real problem I see with Delphi is than MEW is already written in it. It is tempting to reuse old code then. I'm affraid MEW would deserve total rewrite but it'd be a lot of work...