To: igor-group@cs.cmu.edu Subject: Re: Toolkit Design Date: Mon, 16 Aug 93 12:32:34 -0400 From: Michael_Garland@LISP-PMAX2.SLISP.CS.CMU.EDU 1. It is unclear to me how panes relate to views. Is there a 1:1 relationship? If so, what's the point of having both? If not, how do you move between views and the associated panes, and what sorts of operations are defined on panes? An example or two would help. Indeed, there is a 1:1 correspondance between views and panes. Panes are strictly an internal abstraction which the typical programmer will never see. Views are the interface components that everyone sees and all user code is constructed around. The reason for having both is this ... Code written around views is meant to be platform independent. In order to achieve this independence, all platform specific code is hidden under panes. Thus, a view can create a pane on whatever platform it is executing without any knowledge of that system. There is also a difference in usage between panes and views. A pane is essentially the same as an X window; it is a place to draw stuff and it is a site for receiving events. A view is slightly analagous to widgets, in terms of its level of abstraction. Every view provides a visual representation of an object, and uses lower-level panes to actually render its presentation. 3. I assume that an "object" (page 5) is the program's handle on something that has been (or could be) drawn on the screen, such as the Starship Enterprise. I don't understand how objects related to views. Many objects to one view? Or is each object a sub-view? The object/view protocol does not seem to provide a way to get all the views in which and object appears or all the objects in a view. An object is just some random chunk of data that has been introduced into the system. Maybe it was just created, or slurped in from a persistent database, or maybe even read in from a file (*gasp*). Since all data in a Dylan system is bundled into objects, pretty much everything is fair game for display. The deal is that every view has an associated object, and the view provides an interactive image of the object on your screen. While every view has exactly one object, any given object may be attached to multiple views. For instance, let's say I have an object which is a code fragment. I might have a view open which is a textual editor for that code fragment. I might also have a view open which presents some summary information of all the methods and classes defined in that fragment. These are both views of the same object. 4. ADD-VIEW and CREATE-VIEW are confusing. If both are needed, they should take their corresponding args in the same order. Well, add-view is what you are typically meant to be calling. The create-view methods are there to allow developers and/or users to control the kinds of views created for different objects. Simply calling create-view gives you a new view which has been connected to its parent. However, there is additional processing that is necessary before this view can be realized on the screen. This additional stuff is performed by add-view. 5. The screen management stuff seems interesting, but we should work out a screen-manager or two in order to see how much of this complexity we really need. We can always add more later. Well, what is important to me at this point in design is not necessarily a concise description of the exact features that we want, but rather an agreement on the general structure and philosophy of the layout management protocol. Essentially, I think that we need a mechanism which is general enough to allow for the construction of interesting layout managers without introducing unbearable overhead. 6. I'm not sure how to handle "graphical context" issues. You basically want to inherit a lot of cached default preferences, some of which might require significant pre-computing or fetching, but be able to override any slot easily in any call. We should kick this around a bit. Have you seen any other model that looks good to you, in Garnet, CLIM, or wherever? I don't have any idea how these things work in Garnet. I believe the CLIM model was you could either have a macro where you said something like: (with-graphics-context ( ... various options ...) ... code ...) or you could specify most preferences as keyword arguments in drawing functions. I'm not sure how thrilled I am about this model. I have to look into this some more. 7. On resources, I'd like to see us have our own portable resource language, with modules to translate into the others. Personally, I feel that this is likely to entail some significant work, but is a desirable goal. I think that the best thing to do is to initially concentrate on developing a portable means for loading resources out of (native) files, which we will need in any case. We can worry about resource compilers later. In fact, we might be able to find a portable resource compiler somewhere and avoid having to do it ourselves. 8. Name ideas: GUIDE Graphical User Interface, Dylan Environmnet GUIDO Graphical User Interface, Dylan Objects POX Pictorial Object eXtension GODIVA Graphics Oriented Dylan Interface, Views and Actions My favorite: Torch Not an acronym, but what Igor uses to see and show things. Torch is a pretty good name. I think it might be an acronym for: Toolkit Of Righteous Code Hackers. -Mike ----------------------------------------------------------------- To: Michael_Garland@LISP-PMAX2.SLISP.CS.CMU.EDU cc: igor-group@cs.cmu.edu Subject: Re: Toolkit Design Date: Mon, 16 Aug 93 13:49:44 -0400 From: Scott_Fahlman@SEF1.SLISP.CS.CMU.EDU Indeed, there is a 1:1 correspondance between views and panes. Panes are strictly an internal abstraction which the typical programmer will never see. Views are the interface components that everyone sees and all user code is constructed around. The reason for having both is this ... Code written around views is meant to be platform independent. In order to achieve this independence, all platform specific code is hidden under panes. Thus, a view can create a pane on whatever platform it is executing without any knowledge of that system. There is also a difference in usage between panes and views. A pane is essentially the same as an X window; it is a place to draw stuff and it is a site for receiving events. A view is slightly analagous to widgets, in terms of its level of abstraction. Every view provides a visual representation of an object, and uses lower-level panes to actually render its presentation. OK. It's important that you say this clearly in the document. Perhaps we don't need examples after all, since users need only be concerned with views. An object is just some random chunk of data that has been introduced into the system. Maybe it was just created, or slurped in from a persistent database, or maybe even read in from a file (*gasp*). Since all data in a Dylan system is bundled into objects, pretty much everything is fair game for display. The deal is that every view has an associated object, and the view provides an interactive image of the object on your screen. While every view has exactly one object, any given object may be attached to multiple views. For instance, let's say I have an object which is a code fragment. I might have a view open which is a textual editor for that code fragment. I might also have a view open which presents some summary information of all the methods and classes defined in that fragment. These are both views of the same object. OK, so it's views and sub-views all the way down. The smallest graphical item to which the system might want to refer, such as a movable control point in a diagram, is a view. I guess you can draw a bunch of lines and pixels in a given view, but as far as the system is concerned they are all one atomic object. Right? Again, say this clearly in the document, as you have above, and be sure there are primitives for getting the object for a given view and for getting all the views associated with a particular object. Well, add-view is what you are typically meant to be calling. The create-view methods are there to allow developers and/or users to control the kinds of views created for different objects. Simply calling create-view gives you a new view which has been connected to its parent. However, there is additional processing that is necessary before this view can be realized on the screen. This additional stuff is performed by add-view. OK, but there's still no reason that I can see to present the args in a different order. ... Essentially, I think that we need a mechanism which is general enough to allow for the construction of interesting layout managers without introducing unbearable overhead. Yes. Or to introduce the overhead only when you're using the added hair. Personally, I feel that this is likely to entail some significant work, but is a desirable goal... This resource database is just a big set of attribute-value pairs, no? Sounds straightforward to me, once we translate the raw external datatypes into Dylan objects, and we need some technology for that in any case. Torch Not an acronym, but what Igor uses to see and show things. Torch is a pretty good name. I think it might be an acronym for: Toolkit Of Righteous Code Hackers. OK, let's go with Torch unless someone both ojects and has a better idea. We ought to call the hypercode system "Cobweb". -- Scott ----------------------------------------------------------------- To: igor-group@cs.cmu.edu Subject: Re: Toolkit Design Date: Mon, 16 Aug 93 14:09:54 -0400 From: Michael_Garland@LISP-PMAX2.SLISP.CS.CMU.EDU OK, so it's views and sub-views all the way down. The smallest graphical item to which the system might want to refer, such as a movable control point in a diagram, is a view. I guess you can draw a bunch of lines and pixels in a given view, but as far as the system is concerned they are all one atomic object. Right? Yes, an interface is composed of a hierarchy of views. However, not everything is necessarily a view. For instance, if I have a drawing program (like MacDraw), I have one view rather a view per drawn object. So although I can select and interact with the circle that I've drawn, it isn't a view. However, my interaction with it is controlled by the view in which it is drawn. In spite of this, such a distinction is strictly a matter of internal concern for my , and really makes no difference to any of the rest of the system. This resource database is just a big set of attribute-value pairs, no? Sounds straightforward to me, once we translate the raw external datatypes into Dylan objects, and we need some technology for that in any case. In fact, no. This is an unfortunate confusion of terms on different platforms. Indeed, on an X machine, you have resource databases that are simple attribute-value pairs. Accessing it is easy, and its sole function is to store preferences. However, resource files on a Mac or Windows system are far more complex. They are much more akin to UIL files from the Motif world. In resource files, you have compiled descriptions of icons, bitmaps, menus, dialogs, windows, pointers, fonts, etc. In fact, resource files can contain pretty arbitrary stuff (particularly on Macintoshes). So I can say, "Fetch me the menu named 'MainMenu' defined in the following resource file". This will suck in the definition, create all the necessary stuff, and attach it to my application. The 'resource language' is the textual description of windows, dialogs, and menus which you feed into a resource compiler. Admittedly, my familiarity with these resource specification languages is limited, by I think that translating some portable resource specification into native ones is certainly non-trivial although not certainly not impossible. -Mike ----------------------------------------------------------------- To: Michael_Garland@LISP-PMAX2.SLISP.CS.CMU.EDU cc: igor-group@cs.cmu.edu Subject: Re: Toolkit Design Date: Mon, 16 Aug 93 15:01:14 -0400 From: Scott_Fahlman@SEF1.SLISP.CS.CMU.EDU Yes, an interface is composed of a hierarchy of views. However, not everything is necessarily a view. For instance, if I have a drawing program (like MacDraw), I have one view rather a view per drawn object. So although I can select and interact with the circle that I've drawn, it isn't a view. However, my interaction with it is controlled by the view in which it is drawn. In spite of this, such a distinction is strictly a matter of internal concern for my , and really makes no difference to any of the rest of the system. Hmmm... this issue is always confusing, so examples really would help. In this case, if you click within this atomic Draw view (don't say MacDraw unless you mean that actual program running in some encapsulated mode), all you get back is the big Draw view object, plus X,Y,time coordinates, right? The system will not associate the click with objects representing parts of the drawing, so you have to do any of that at user level. This resource database is just a big set of attribute-value pairs, no? In fact, no. This is an unfortunate confusion of terms on different platforms. Indeed, on an X machine, you have resource databases that are simple attribute-value pairs. Accessing it is easy, and its sole function is to store preferences. However, resource files on a Mac or Windows system are far more complex. Well, whatever these complex values are, either we can handle them in Dylan or not. And if we can handle them, we're still dealing with an attribute-value pair, are we not? So the issue is not how to handle resources, but how to handle any foreign values coming in. -- Scott ----------------------------------------------------------------- To: igor-group@cs.cmu.edu Subject: Re: Toolkit Design Date: Mon, 16 Aug 93 15:46:38 -0400 From: Michael_Garland@LISP-PMAX2.SLISP.CS.CMU.EDU In this case, if you click within this atomic Draw view (don't say MacDraw unless you mean that actual program running in some encapsulated mode), all you get back is the big Draw view object, plus X,Y,time coordinates, right? The system will not associate the click with objects representing parts of the drawing, so you have to do any of that at user level. Events are always dispatched to the views in which they occur. So, a click would be sent to the object. This event is dispatched via a call to HANDLE-EVENT, which sees that a mouse click has occurred. Bundled with this is specific information like (x,y) position. It is then up the view object to in some way dispatch this event to the object that you clicked on. Presumably, this may be handled for the programmer by some library of structured graphic routines. Now, it would also be possible to implement a Draw application where each graphical element was in fact a view. The problems with this approach are two: - Using a view per object would really introduce needless overhead - You have less control over views. In particular, views are always rectangular and are not opaque. These are not necessarily desirable attributes from the perspective of writing a Draw application. It's always easiest to give examples when there's something to draw on, but here's an attempt at another one: Let's say I want to create a text editor, with the ever so unique name of Hemlock NT. The objects which I would typically be dealing with are text buffers. Thus, I define a class of views that displays text buffers. For any given buffer, I can create as many views as I want and updating one will cause all the others to reflect my changes. When I actually write this class, I have to take care of whatever events I deem to be 'interesting'. In this case, basically mouse clicks, key presses, and expose events. If I receive a key press, I need to look at the current position of the point and insert the key that was pressed (disregarding the complexity of command keys for the moment). If an expose event is handed to me, I need to determine what part of the text which I display needs to be redrawn and draw that. Ultimately, all my drawing requests propagate down to the pane which is bound to my view. This pane object translates my portable text drawing calls into platform specific calls to the native rendering system. As with buffers, I could implement the Echo Area by creating some kind of and then defining a view for it. As this might be a needless hassle, I might also create an Echo Area view with no associated object, and simply talk directly to the view. Although this is not the standard way that things are suposed to be done, I could conceivably do this. As things stand, every object would be in it's own top-level window. So now I decide that I might like to stack multiple s into a single window (like what you get when you split a window in just plain Hemlock). Well, I accomplish this by putting selected s into a layout manager, call it , with a call to add-view. The view will take care of keeping all my s nicely lined up in a column, and if I kill off one of them, it will resize the rest to take up the newly freed up space. Well, whatever these complex values are, either we can handle them in Dylan or not. And if we can handle them, we're still dealing with an attribute-value pair, are we not? So the issue is not how to handle resources, but how to handle any foreign values coming in. Ah, but this is not really the problematic aspect of resource files. I agree, importing foreign things like this should be easy, since you typically load them by name and subsequently refer to them by handle. The real difficulty is in translating the textual description, of say, a dialog into the native binary format file where it is stored. In particular, let's say I have a (portable) description of a menu: MENU my-menu BEGIN ENTRY "Find String" .... ENTRY "Name User" .... END I need to translate this into the native textual definition for a menu which can then be compiled by the native resource compiler. I'm not particularly fluent in Windows or Mac resource languages, so I can't really say how different they are. -Mike -----------------------------------------------------------------