Re: GMedia ramblings... (corba!)

[Michael Zucchi <zucchi zedzone box net au>]

> > How about implementing it as an object/widget using gtk's object
> > structure?  The top class could be a 'media' class, with lower classes
> > to handle the different media types (e.g. for example, to implement
> > the different media 'playing' controls).
> 
> It is a gtk object, but I'd rather keep the "drivers" runtime loadable.
> An application should just use a gnome_media object and not worry
> whether it's an AVI or S3M.

Of course, hide it from the application.  But it need not be hidden from
the 'loader', if you like.

For completely external 'viewers' it might not be worth it of course.
(perhaps an 'external viewer' could be one such sub-type?)

> > <little off topic>
> > Otherwise this sounds a *lot* like Amiga's 'datatypes' system.  Only
> > not as sophisticated.  I thought gnome was about re-inventing a better
> > wheel? :)
> > </i'll go quiet now>
> 
> Quoting me there ? ;-)

Was that you?  Oh good :)

> Please explain how Amiga datatypes work for us non-Amiga-using people.

Well since you asked ... (i'll try not to go on too much here, but i
tend to ramble at times).

They are based on a system called 'BOOPSI' (Basic Object Oriented
Programming System for Intiution).  Intuition is the GUI toolkit if
you like.  BOOPSI is just an object oriented metaphor implemented in C
(or assembly :).  It has *many* similarities to gtk including the
class/subclass model, registering classes, etc., but uses run-time
binding for all methods on objects (no callback routines, just a
dispatch routine which handles the methods it knows about, others can
be passed to the 'superclass' dispatcher).  Other details like
per-class data in each instance is basically the same as gtk.  Methods
on objects are invoked by passing messages around (apparently the idea
was based on a small-talk-like implementation, but I know nothing of
small-talk), which are processed by each class's 'dispatch' handler,
and then by the super-class's dispatch handler if desired, and so on,
upto the root class - Object.  Each method can thus be overloaded, or
inherited, or complemented by each subclass along the way.  There is
no need to type-cast objects because each subclass gets to its local
data by asking the super class where it is ... and sets super-class
attributes by calling the standard API Get/Set functions on it.  And
each application doesn't need to know what object it has, as it must
use function calls to query its details.

A common set of (operating system level) functions are provided for
operating on objects.  e.g. to 'new' an object of a given /type/
(which can be determined at run-time), to change an object's
parameters, to call an objects methods etc.  Finally, BOOPSI objects
generally represent 'gadgets' which are functionally equivalent to
(but lighter weight - and hence faster than) widgets.

Data-types are just a BOOPSI class heirarchy specifically designed to
implement different types of, well (basically read-only), 'data'
(last I saw it covered all basic pic formats including poscript, text
formats, animation formats, and many sound formats - most of which were
written by freeware/shareware authors).  There were other BOOPSI
classes more aimed at GUI's (like buttons, scroll-bars, etc.  On a
side note - can someone *PLEASE*PLEASE* make scrollbars with the
up/down left/right buttons next to each other and in the bottom/right
of windows?  Or have it theme-able!? :).  On another side note, a
shareware author wrote a complete GUI toolkit replacement based on
BOOPSI and it had themable qualities like this (slow as a dog though).

Anyway, how it works.

e.g. the top level 'picture' datatype has all the basic structure and
data that all 'picture' types need.  For example, a way to render the
picture into a window (of any depth or palette), recieve input events,
a place hold and method return its size, depth, etc.  It understands a
few basic picture formats, basically the native Amiga BitMap format
(which is only an in-memory one-step-away from the hardware thing, and
not a disk based format).

However, it has no actual code for loading pictures ... which is where
the sub-classes come in.  A sub-class is installed into the OS and
registers itself with a 'file typer' system which can be used to
identify which sub-class is needed to load a file, and to which class
the file belongs.  This is then used to recognise when to instantiate
the subclass (usually by invoking the 'read' method).  The sub-class
(non-arbitrarily I shall say 'gif' - i wrote one of these in Assembly
language about 4 years ago) will load the gif picture, and
convert it into the format the picture class knows about, returning
bitmap info, colour info, depth info, etc.  Thats the
only method it really needs to implement - rendering of the class,
including any colour scaling (and everything else) may be handled by
the 'super class' - in this case 'picture'.  Of course, the gif class
may want to know when certain other methods are invoked, and it can if
it wants, or completely over-ride any or all of them (just by adding a
new case to its dispatch loop).  It just processes the message types
it knows about, and passes everything else to the superclass.  Great
if the the super-class suddenly implements a new method because 1. the
gif class *DOESNT* have to be recompiled, and 2. will *automatically*
inherit this function!

However, to the application, its just a 'picture', or even, just an
'object', which can be put on a window ...  Basically a 'black box'
which may be used as a gui element.


Rambling a bit here, so i'll wind up quick ...

One last thing that was nice about this system is the call-API would
never need to change, and could be expanded indefinetly in a
_completely_ backward-compatible manner.  With no real dependencies
even between objects (of the same class!) within the system (unless
features demanded it).  Just by adding a new message type and
implementing it at one of the class levels - other class levels will
just ignore it as unknown and still function, even *without*
re-compilation.  Can you say ... real code re-use?

e.g.

type = DtFileType("mypic.gif");
object = DtObjectNew(type, "mypic.gif");
width = DtObjectGet(object, DTA_WIDTH);
height = DtObjectGet(object, DTA_HEIGHT);
MyWindow = OpenWindowTags(0, WA_WIDTH, width, WA_HEIGHT, height, 0);
return = DtMethod(object, DTA_RENDER, DTA_LEFT, 0, DTA_TOP, 0,
			DTA_WINDOW, MyWindow, 0);

(or whatever, i can't remember exactly the syntax/calls, i've got a
manual here somewhere though :).

Oh one last thing (yes another last thing :) .. for operations that
might take a while to run (e.g. a render of an AmigaGuide (early
text-mode html-like thing) 'datatype') you could simply add a
"DTA_FLAGS, DTFLG_ASYNC" or similar which would render it using a
separate Amiga process (== thread) ... can you say, responsive gui?

(Unlike X in which everything is rendered by the application,
Intuition rendered most gadgets and all windows under its own
context (and by render, i mean call the code directly which writes to
the actual graphics memory).  Very fast, but not particularly secure
(BOOPSI gadgets provided their own rendering code).)



I'm not saying it was the be-all n end-all, and it had its problems,
and it might not be that applicable to your project, but
then it might.

Maybe some of these ideas are applicable to Gnome in other areas
anyway.

 Michael

PS And next week, a lengthy monologue of what commodities and the commodity
exhange broker is (another neat Amiga system-thing).
PPS Only kidding :)

-- 
     ///   `... thinking is an exercise to which all too few brains
    ///     are accustomed.' - First Lensman, E.E. `Doc' Smith
\\\///  
 \\\/   Michael Zucchi, B.E.                 zucchi@zedzone.box.net.au