Time to reimplement Vision2

by Finnian Reilly (modified: 2012 Jul 12)

I have been using Vision2 a lot over the past 5 years across a number of projects and have become aware of many idiosyncrasies in it's behavior between the GTK and Windows implementation, that make it difficult to have consistent behavior in your application. This is especially true if you want to develop any kind of customized component but even some quite basic things have inconsistent behavior.

Examples of custom components

  • Buttons based on SVG graphics with roll over highlighting and customizable click animations.
  • Boxes with auto-hiding on selected member widgets. When you roll the cursor over the box, various hidden widgets reappear, and disappear again when the cursor leaves.
  • Labels with a pixmap-able background based on drawing areas.
  • Hyper-link labels based on drawing areas.
  • Color selection buttons.
  • Drawing areas that can adapt their own size to an expanded parent cell.

Examples of basic inconsistencies

  • Pixmap have a different expansion status in Windows then under GTK necessitating an explicit set_minimum_size call.
  • Scrolling areas don't respond to the usual keyboard shortcuts in Windows. I made my own Windows implementation based on the standard one. It's ok, but not without side effects that have to be worked around. Recently I had a case of child buttons that wouldn't respond.
  • The web browser component in Windows prevents processing of keyboard accelerators.

The typical Vision2 cross platform development cycle consists of developing some new functionality on Linux and after recompiling your project in Windows, you find that a component is either: not visible, not aligned properly, has the wrong expansion status, is partially obscured, won't respond to the usual keyboard shortcut, breaks a contract, or even crashes the application. You then spend some time finding workarounds and then go back into Linux to see if your application still works the same there. In some cases I have spent days trying to get a custom component to work consistently on both platforms.

Vision2 has had a long history (15+ years) but it is still far from perfect. This I believe is a reflection of the fundamental difficulty of developing a totally consistent GUI interface based on incompatible toolkits.

However it doesn't have to be like that. For quite some time now, it has been possible to develop GTK+ applications that run on Windows, Mac OS and mobile devices. (Screen shots) And not just relatively simple apps like Gedit, but very complex ones like GIMP or InkScape.

Now that Eiffel Software have sanctioned the mingw as the default C compiler distributed with EiffelStudio, perhaps now is the time to jettison the Win API part of Vision2 and base it entirely on GTK+. (In fact you can still use the MS compiler for GTK+) The main advantages of an entirely GTK+ based toolkit are as follows:

  • Ensures completely consistent cross platform behavior.
  • Maintenance and bug fixing becomes much easier due to reduced complexity.
  • Addition of new GTK+ components is easier as you don't need to look for an Windows equivalent.
  • Reducing the complexity of creating custom components encourages more Eiffel developers to experiment and contribute new things. Making new widgets using only the top level interface is far easier than struggling with two very different C API's.
  • Reduces the likelihood of problems using mingw as the default C compiler.

What do people think?

Happy EiffelingFinnian

Comments
  • Manu (12 years ago 13/7/2012)

    There are 2 things to remember about EiffelVision:

    1. It is a platform specific behavior experience. Meaning that not everything looks or behave the same between the platforms. This model was chosen because at the time, we felt people were very attached to the look and feel of their platform. This explains some of the shortcuts/display differences between platforms.
    2. It can integrate well with platform specific programming. For example, we can easily integrate .NET windows components inside an EiffelVision application and conversely, or a third-party component for your favorite platforms.

    However I (talking for myself and not on behalf of anyone) and some others wants to also update EiffelVision but for different reasons (that have more or less the same effects as what you are looking):

    • event handling programming is often hard due to the platform specificity when you do tricky things (mostly keyboard events which generates other UI events update).
    • lack of control on the look and feel of widgets, aka as theming

    But standardizing on GTK is in my opinion not good. All GTK applications I've seen on Windows are not that great even if a few screenshots show that it is quite close to be a native application (e.g. I've been using Pidgin for messaging and it functions ok but doesn't look nice at all). Moreover getting GTK installed manually is a daunting task. On Unix and Mac, you have some packaging tool to help, on Windows I've never tried but I'm sure people who have ever tried to compile GTK from source code will know the pain that is.

    On the other hands, Qt a similar framework to GTK looks more appealing to me as a user interface. Last time I checked `Skype' was written using Qt and it looks very nice (http://en.wikipedia.org/wiki/Category:Software_that_uses_Qt). I'm not saying we should use Qt, actually 15 years ago we had that choice to make: Qt vs GTK. We chose GTK because of its C nature and true openess.

    What we are thinking at the moment is possibly rewrite EiffelVision without relying on any high level framework, just 2 low level ones:- event handling- graphicsand possibly perform all the drawing ourselves. This gives us the freedom to implement behaviors the way we want and not being imposed a windows or GTK specific behavior. It also allows users to easily write widgets/components (currently you have to write for one platform and then write it again for the other supported platforms), while still be able to use platform specific widgets made by third parties.

    • Finnian Reilly (12 years ago 16/7/2012)

      Vision2

      This model was chosen because at the time, we felt people were very attached to the look and feel of their platform. This explains some of the shortcuts/display differences between platforms.

      It seems to me that the only significant differences are between the standard dialogs, file, color choosers etc. The basic components, combo boxes, radio buttons etc, have very little difference in the look and feel. I agree it is desirable to keep the native standard dialogs because that is what users are used to. Perhaps that might be possible to do that using GTK using some tricks with the GtkPlug routine.

      1. It can integrate well with platform specific programming. For example, we can easily integrate .NET windows components inside an EiffelVision application and conversely, or a third-party component for your favorite platforms.

      GTK+ has the GtkPlug routine which allows external processes to be displayed. As of version 2.8 this also works on Windows. Do many EiffelStudio developers use .NET visual components? If not many than perhaps having a consistent toolkit is more desirable. I would be more interested in .NET if the Eiffel version worked on Mono.

      But standardizing on GTK is in my opinion not good. All GTK applications I've seen on Windows are not that great even if a few screenshots show that it is quite close to be a native application

      I tried out Gedit and GIMP and they seemed ok to me although Gedit had a few things missing like the external tools facility. But maybe the Windows versions are not as good because the developers haven't put as much effort into making them so. These ports are more like an after thought. Also this is free software. If it were commercial there would be a much greater motivation to make the Windows version as good. (sorry, hope I don't offend anyone saying that)

      (e.g. I've been using Pidgin for messaging and it functions ok but doesn't look nice at all). Moreover getting GTK installed manually is a daunting task. On Unix and Mac, you have some packaging tool to help, on Windows I've never tried but I'm sure people who have ever tried to compile GTK from source code will know the pain that is.

      I have some experience of using the GTK+ code base on Windows for my SVG rendering component and I discovered a great shortcut to this horrible task: use the prebuilt binaries downloadable from gnome.org (win32 and win64). I have a general purpose Eiffel scons building framework that knows how to download and extract selected components and build an installable package based on $ISE_PLATFORM. I had no trouble linking them with the MSC compiler.

      On the other hand, Qt a similar framework to GTK looks more appealing to me as a user interface. Last time I checked `Skype' was written using Qt and it looks very nice (http://en.wikipedia.org/wiki/Category:Software_that_uses_Qt external). I'm not saying we should use Qt, actually 15 years ago we had that choice to make: Qt vs GTK. We chose GTK because of its C nature and true openess.

      I agree Qt does look better and I am all for having a Qt framework in Eiffel if it doesn't take too long a time to make something reliably usable. Another possibility is the Mozilla development framework. It provides a standard interface to native components on a wide range of platforms using the XUL user interface language. It's very tried and tested being used on the Thunderbird email client and Firefox and some other apps. XUL allows you develop a UI using the XUL XML spec with JavaScript. Since it's already designed with a high level of abstraction in mind, it might lend itself well to an Eiffel port with an Eiffel interface replacing the XML/JavaScript.

      What we are thinking at the moment is possibly rewrite EiffelVision without relying on any high level framework, just 2 low level ones: - event handling - graphics and possibly perform all the drawing ourselves. This gives us the freedom to implement behaviors the way we want and not being imposed a windows or GTK specific behavior. It also allows users to easily write widgets/components (currently you have to write for one platform and then write it again for the other supported platforms), while still be able to use platform specific widgets made by third parties.

      That sounds like a good approach but would it take a long time to implement? You could also use selected libraries from GTK like the Cairo library for graphics. This the underlying library I use for rendering SVG as PNG. It works well on Windows and *nix.

      • Manu (12 years ago 1/8/2012)

        I'll try to answer some of the points you raised.

        • GtkPlug: it looks good but you indicate it only works with external processes. I was talking about one single process being able to incorporate various native components that you could buy off the shelf.
        • Packaging: We could do that but it means that even a very light Vision2 application would have to carry about 30MB or more of DLLs. Not too appealing for me. In addition, we have noticed that our users have always trouble when their code depends on a DLL, they never know where to put them.
        • XUL: It doesn't appeal to me at all, just hearing `javascript' is enough for me to stop. Maybe if at the end, this is completely transparent why not, but I'm sure we end up in the same troubled areas as GTK where we need to install some runtime libraries properly.
        • 2-layer approach: we do not know how long this would take, clearly this is not a quick thing to do as we have quite a few widgets to do, plus the theme engine to provide native look and feel. And this is a choice hard to justify when we already have something that works pretty well.
  • Peter Gummer (12 years ago 19/7/2012)

    No to GTK on Windows and Mac

    Interesting topic, Finnian.

    We develop with Vision2 the other way round: in Windows, and then from time to time we do a build on Linux and Mac OS X. We rarely run into any problems these days, although we don't use much in the way of fancy pixmaps: we have lots of icons, but that's about it. You can see some screenshots of it at http://wolandscat.net/2012/06/28/openehr-archetypes-visualised/#more-455 ... this is on Windows, but it looks almost exactly the same on Mac and Linux.

    For example, after about a year of being involved in other completely non-Eiffel projects, I've recently had time to port the ongoing work from Windows to Mac and Linux. Everything just worked. No problems with layout, etc. The only problem I found was that the text was not being displayed on some buttons (and even that was working in EiffelStudio 6.8 -- the problem only started happening when we subsequently upgraded to EiffelStudio 7.1). I worked around that easily by replacing the text on those buttons with pixmaps, which is what we had intended to do anyway.

    In the past, years ago, I do recall having various problems with text not fitting properly, but these problems all seem to have gone away.

    I certainly wouldn't want my Windows apps to look like GTK. When I'm working in an OS, I want the apps to look and behave according to the conventions of the OS. The Mac versions of our app and of EiffelStudio function well and everything looks okay, except that they look ugly. They don't have the standard look of Mac buttons, scroll bars, combo boxes, etc. This is something that I want to fix. I'm trying to get away from GTK on the Mac; I certainly don't want to be going there on Windows too.

    One big problem with GTK on the Mac is that deploying our application is a nightmare. You have to instruct users to install Xcode, the command-line tools, MacPorts and then they have to run a command in Terminal. If they make it that far, then at last they can install our app. After years of failed attempts, we finally had our first success a few weeks ago: an end user successfully installed our app on his Mac. This nightmare is all because of GTK. If we could just deploy a standard Cocoa application, then users would be able to install it painlessly and presumably it would look a lot better too.