🚀 go-pugleaf

In article <1992Dec27.063724.15059@u.washington.edu>  
wiml@milton.u.washington.edu (William Lewis) writes:
> 
>    Recently I've been pondering the construction of an object-oriented
> GUI toolkit (particularly, using gcc-objc over X, but that detail is 
> irrelevant), trying to combine the best attributes of the X intrinsics
> and NeXTstep (the two OO GUI toolkits I'm familiar with).
> 
...
> 
>    So, what do you think? Too many objects? Already been tried
> and discarded? Penny-wise and pound foolish? 
>    Followups have been directed to comp.windows.misc and 
> comp.lang.objective-c. Edit as appropriate.
> 
>      

A few weeks ago I finally took the plunge, and began work on porting my beloved  
NeXTStep program to X. (As I'm sure you'll all understand) the thought of  
moving back to pure C was abhorrent, and so I set about writting a minimal set  
of objects which would allow me to port a program (or more specifically my  
program) between NS and X. I figure Obj-C will spread faster then NS (irritated  
comment about GNU's runtime development), so I should gain something from the  
port.

Problem #1 I know very little of X. This is not simply ignorance - this is a  
carfully cultivated scheme over the last four years to avoid X at every  
opportunity.

Solution - The Plan 9 compatability library! The Unix version of SAM (the plan9  
editor) includes a library to provide some very primitive operations on a basic  
window. I see no X :-). These are of the draw line, plot point level. This is a  
pain for normal programming but ideal for my purposes (except that it puts the  
origin at the top left!)

My initial ideas were to write something very close to NS. However I soon  
realised that I don't need anything as complex. Rather than having a complex  
scheme of heavyweight views, everything is light weight, and plots directly  
onto the screen bitmap (with suitable clipping operations), which is held by  
the XApp object (itself a subclass of XView). This of course means that every  
view object has to be able to redraw itself on request, but this is less of a  
problem using obj-c than it would be otherwise. The advantage is that the  
classes are very portable, as they make use of only very primative operations  
on a single bitmap.

Using this I've been able to build buttons, sliders, a primative text field, a  
responder heirachy, menus and modal panels. Within methods drawing is still  
done using plan9 primatives. This is something I may address in the future. I'm  
just in the process of considering the port of actual code. Details of the  
ported code will change, but at least the basic structure will remain.

My system is far more primative than the sort of thing you're talking about  
building, but it is sufficient for my purposes. Obj-c does make this sort of  
thing practical - I wouldn't have touched X previously, but I'd now be happy to  
develop code using a toolkit like this. A small amount of code goes a VERY long  
way.

Just some of my experiences, that I thought I'd offer.

Ian Stephenson
Adaptive systems Engineering
Dept of Electronics
Univeristy of York