This post originated from an RSS feed registered with Agile Buzz
by James Robertson.
Original Post: Past Pollock, Into The Future
Feed Title: Pollock
Feed URL: http://www.cincomsmalltalk.com/rssBlog/pollock-rss.xml
Feed Description: Pollock - the next VW GUI
So, let's say that Pollock is done, every widget you can think of has every feature you can think of. What's Next? We have two projects in the very early stages of being thought about and designed, and being the "I Like To Name My Projects" type, I have already named them... AND I have "Companion" Images for each. For instance, for Pollock, there is Lavender Mist
At various times, and maybe even in this Blog (as if I read what I write), I've talked about this project. This project is in simple terms, Native Widgets for Pollock. First, we need to define what that means. In the modern GUI world, there is pretty much a common cross section of widgets across platforms we support... if you ignore X11/XLib. There are comparable widgets between MacOSX and Windows. Another way of stating this is that all Pollock widgets (both present and future), are fully translatable as MacOSX or Windows native widgets.
So, ignoring X11/XLib for a moment, let's see how this would work. In Pollock, all Artists and Agents are dynamically changeable at runtime. Chagall takes advantage of that by using DLLCC (or other platform connect system, such as ObjectiveCConnect) to create and manage Native Artists and Native Agents for each widget. Where each Artist now has a #displayOn: method, it would forward all display to the Native Artist for that pane. Where each Agent now manages and forwards clicks and keypresses, they will be forwarded from and to the Native Agent for that pane.
There exists already an API between a specific Pollock pane and it's Agents and Artists. Chagall will simply build access to Native Widgets in the guts of these new Artists and Agents. A simple setter for each widget, such as maybe #bePlatformNative: <aBoolean>, will turn on or off the "Nativeness" of that pane. Also, a UserInterface wide setter, as well as a globally visible toggle will be available. Thus, you will be able to turn on or off native widgets on a widget by widget, window by window or application by application basis.
Now, back to the X11/XLib world. If you don't already know, at the level of XLib, there basically isn't any idea of a widget at all! Instead, there is just a Window. Windows have all kind of attributes and ways you can paint and communicate to them. When you see widgets when you are running an application that uses Motif or KDE (Qt) or Gnome (Gtk), what you are seeing are "toolkits" that take a window, and give it a widget like API for you, and do the drawing for you and so on. This is standard fare. In fact, even Windows(tm) widgets are just a bunch of windows, each with a special API that makes them act like widgets.
So, how would we do "Native Widgets" on X11? We could start by saying "Just Fake It All, Do Owner Draw". In this scenario, we simply create widget windows for each thing we want to see on the screen, and then do all the drawing from Smalltalk. This is in effect, just a touch above what we do today. In fact, what we do today with Emulated Widgets (on all platforms) is create a Native window, and then, draw on it. The "Owner Draw" gives us some advantage though. It allows us to get events directly from the "Owner Drawn" widget... although we will still have to figure out where in a widget those events are coming from, we no longer have to have Smalltalk search it's widgets for the "I'll Handle That" code. But there is really not much to leverage here at the XLib level. All of the drawing code for each widget will have to still be in Smalltalk. Not much gain here
The next level up are Toolkits. A Toolkit is an X11 library that provides a higher level API than just plain XLib, and makes it easier to do widget things. Well, the first option is to say "We'll just use the Simplest Toolkit That Can Possibly Work: XToolkit" which has a layer that builds on top of X11/XLib and allows you to create widgets from scratch, but with a bit of help to manage all of the details. This particular Toolkit is pretty much standard fare, and available on all of our supported systems. That's good. It is, however, only just a hair above the bare metal. That's bad. It gives us a better abstraction and control over how we draw, and what we draw and the who, what and when of events, but overall, we still have to do all of the drawing in Smalltalk. Not very much more gain here
Well, what's above the Simplest? To start with, there is Motif. Motif is a Toolkit which actually has widgets! Wow, it has the notion of being able to create a Dialog Window, with a real API! And it has selection dialogs, an prompting dialogs! It has Buttons, and CheckBoxes and RadioButtons. It has Menus and MenuButtons and PopupMenus! It has InputFields and TextEdits! It even has a Slider, and also the notion of layouts that it can manage! But that's just about where it ends. Want a ListBox with icons in it? Nope. TreeView? Nope. Grid? Nope. SpinButton? Nope. Oh, and if you want your Menus or Buttons to have graphics in them, you're on your own... Oh, you can, but you're basically taking a raw Motif Button, and doing Owner Draw on it. Been there, done that, got the T-Shirt. None the less, it is a pretty complete basic system, and we can do the rest easily enough (after all, we've done it ALL already). There's just one problem. Motif isn't standard on all systems. Sure, there's OpenMotif, which has additional widgets (including a Tree!), but that's not installed on all *nix systems. Our users would have to download it, install it... etc.
More powerful than Motif are the QT and GTk toolkits (used in KDE and Gnome respectively). Now these puppies have all the goods. There's barely a standard widget that Pollock supports that these don't directly support. And the to whatever extent they DON'T, well, it's fairly easy (in a horribly ugly C/C++ way) to make 'em do it all.
So, what's the solution? The solution is to punt at first, and then go whole hog later. We'll do the XToolkit thing first on the X11 platform, yes, with all it's ugliness. That, with the Windows and MacOSX native widgets, and we'll have a good thing. From there, we can expand to .NET (and later Longhorn) for Windows. And supply Motif, QT and GTK specific versions later. Whatever we do provide, the Native system will automatically (or in the case of .NET, or on *nix systems that have multiple toolkits available, manually override) use what ever it finds on the system.
This is a fairly new project idea. We've only been just talking about the ideas that compose it for less than a year. I've even gone through three names before I finally came up with the name Peaches. So, enough, what is it?
Move the GUI system out of the VirtualMachine into the Image.
What does that mean? Well, it means taking the various VM Event loops, and moving them to the Image. It means taking all of the window creation code from the various VMs and moving them into the Image. It means taking all of the printing code that is in the various VMs, and moving them into the image. It means taking all of the Font and text display code in the various VMs and moving it into the Image. It means taking all of the GraphicsContext and Display and Screen and Graphics code from all of the various VMs and moving it to the Image.
It means creating a whole new abstraction layer that allows the current system (Wrapper and/or Pollock) to run on top of it unchanged
It means creating an extended abstraction layer that allows Chagall to be more in charge of Native Widgets than it can be under the current situation
It means creating a new Font & Display abstraction layer that is more portable and at the same time allows a more modern manipulation of font systems and manager.. In Other Words, for Fonts.. They'll finally have a "Do It, Done" API.
Now, if you're following along, you might see a possible synergy between Chagall and Peaches. If Chagall is done first, and later Peaches, Chagall will produce some code that Peaches will have to re-do. Or adapt. Or "Just Live With." On the other hand, if Peaches were to be done first, well, surely Chagall would leverage all that "Native In The Image" code big time... but in giving Peaches the priority, it pushes Chagall just that farther into the future.
As of today, with our current level of resources, we believe that getting to Native Widgets are our higher priority. Just looking at a Longhorn GUI Demo video will show you we simply can't keep up with what's going on trying to emulate what exists, much less what is coming. So, we will get to Peaches but not next. And who knows, even parts of Peaches may show up in Chagall, just because it may be easier that way.
Oh, and if you're wondering where I came up with the name Peaches; Frank Zappa put out an album in 1969 named Hot Rats. On it, the most famous song (outside the Zappa fan base) was "Peaches En Regalia." One only has to look at the cover art, with the wild one (Miss Christine (Frka)) climbing out of the huge hole in the ground... just like the GUI climbing out of the VM.
Previous Topic
