FilterManager

[Hakan Ardo <hakan@debian.org>]

Hi,
I've look closer into filtering and display stuff, and I think I've come up
with a solution to the gtkDisplayFilter problem. It would require quite hevy
chnages so I say we save this untill after the modularisation and for now
simply most of the filter headder files public, and we'll be able to compile
mnemonic again!

OK, here we go:

The filterstacks built will look something like this:

Today the output of the filterstack is an gtkWidget for images and a dtree
for html pages. The dtree is then converted into a gtkWidget by the display.
I'd say that we should consider the display an dtree2gtk filter and thereby
handled by the filternamanger. And thereby maby move some of its functions
to the client. (I haven't gotten that deep into the display just yet).

From the outside there will be a mBuildFilterStack(int id, char *desttype).
Sending this message will load a set of filters and connect them together
into an objects that listens to the mkeyStatus and mkeyData messages the
netmanager sends out with the specified id and convert them into an object
of type desttype. Where desttype in this case would be "GTK".

When this object is created (not necessery finised) the filterstack will
send a mkeyGtkObjectReady message with the same id containing a pointer to
the object so the client can get hold of in and display it.

We then have to split up the filters conserning there input type, and we
create one message for each group, eg mkeyGetDataFilter(char *key),
mkeyGetDtreeFilter(char *key), .. Where mkeyGetDataFilter would return a
filter that takes char * as input, while mkeyGetDtreeFilter would return
afilter that takes a dtree as input.

The key used would be the content-type or such string to indicate with
filter.

The first filter in a chain would always be a Data filter, so if we start
building the chain form the bottom by a mkeyGetDataFilter message. Then this
filter knows it's output type and thereby what kind of messages it shall
send to get the right kind there. So we use a method in the created filter
to generate the next filter in the chain.

For example if we want to download and show the url http://www.mnemonic.org
which we pretend is a gziped html page. Then the gtkBrowser would:

- Send a mNewID message to get hold of a new id.
- Make an Interst in mkeyGtkObjectReady(id), which will conatain the gtk
                                           object to be displayed.
- Send a mBuildFilterStack(id, "GTK") message.
- Send a mFetchURL(id, "http://www.mnemonic.org") to start the download.

When the FilterStack has recieved the mBuildFilterStack messages and enough
mStatus messages to know that it is a gzip html page it builds the stack:

a = mkeyGetDataFilter("ungzip");
b = a->NextFilter("text/html");
c = b->NextFilter("GTK");

When the dtree2gtk filter has ben created (which will be what we call the
display now) it will send the mkeyGtkObjectReady(id) to give the object
pointer to the client!

This way both images and html pages and all kinds of potential other kinds
of objects will be handled the same whay by the client!

What do you think?


-- 
---------------------------------------------------------------
 Name:        Hakan Ardo
 E-Mail:      hakan@debian.org
 WWW:         http://www.ub2.lu.se/~hakan/sig.html
 Public Key:  Try "finger hakan@master.debian.org"
 Fingerprint: E9 81 FD 90 53 5C E9 3E  3D ED 57 15 1B 7E 29 F3
 Interests:   WWW, Programming, 3D graphics

 Thought for the day: As long as one understands, the
 spelling does not matter :-)
---------------------------------------------------------------

PGP signature