Re: [Fresco-devel] What is a graphic?

Tobias Hunger wrote:

>So to me a HTML-Renderer would be some client library, that creates lots of
>small graphics in the server underneath some root graphic the client
>developer chooses.
>  
>
More or less. Just that the choice of the root graphic is done by doing 
root_graphic->append_graphic(html_renderer_view), not 
create_html_renderer(root_graphic, ...) (see below). And that the 
"library" may live anywhere, not necessarily in the client.

Compare with my tree widget. It's supposed to be an in-server Kit and 
return a Graphic. The prototype is implemented as client library 
(composing only server Graphics), and it still returns a Graphic. The 
main reasons for implementing it in the server would be

    * speed
    * server doesn't offer needed functionality yet, e.g. reaction to
      key presses
    * |Choice| (which is a model) inherits from |Controller| and that
      inherits from |Graphic|

All of that are implementation details of the library, not interesting 
to the app.

My point is that the line between in-server Kits and client libraries is 
blurry.

BTW: For that reason, I'd advocate for e.g. Choice to not inherit from 
Graphic.

>Your suggestion seemed to be to have a HTML-Kit that is a factory
>for HTML-Renderer graphics which get added into the scenegraph and then acts
>as a factory there by producing it's children.
>
Not necessarily, although I'd leave that open.

There could be 3 processes: (1) the app, (2) the HTML renderer and (3) 
the server. The app somehow acquires a reference to the HTML renderer 
component (process 2), which acts as a factory for and implements HTML 
renderers. The app asks the component to create a new HTML renderer 
instance. That renderer constructs a view of the HTML page, probably by 
composing other Graphics implemented in the server by standard Kits. 
That view is returned to the app as Graphic, i.e. a reference to an 
object in the server, e.g. a vbox. The app can then insert the Graphic 
anywhere where it could add a textfield. In this scenario, all Graphics 
are implemented by code other than the HTML renderer, but the HTML 
renderer still returns a Graphic reference to the app, representing the 
HTML renderer view.

This just seems to me to be the natural thing to do. You can see the 
HTML renderer as just a fancy textbox, it does generally the same 
(display text, just formatted) and should act the same.

Note that the HTML component could just as well be implemented as 
in-server Kit and/or implement Graphics itself and the app wouldn't 
notice a difference. I don't think that would be a good idea for HTML 
renderers, but it may be for other components for various reasons 
(speed, limited exported server functionality etc.).


There is no inherent difference between a Kit (living in the server 
process), a near-server library (e.g. a different process on the display 
machine) and a client library, so they should look the same to the app. 
The app doesn't need to know, if e.g. TasketKit lives in the server or 
if it's implemented as a different process, only composing Graphics from 
WidgetKit.