Re: gui 'slow' with remote X ?

[Fred Kiefer]

Richard Frith-Macdonald wrote:
> 
> On 8 Dec 2008, at 16:27, Nicolas Roard wrote:
>>
>> Irrespective of the scroll issue, exposing the view hierarchy to the
>> backend
>> would still be quite interesting:
>> - we could have specialised backends using native widgets when available,
>> for better integration with the host platform
>> - we could have faster remote display as well (see NX) by being able to
>> use local widgets and thus save on many round-trips
> 
> My feeling is that the frontend should know nothing about the backend
> beyond the stable API we define for gui to use, so that we can easily
> switch the backends we are using without having to have code changes in
> the gui to support it.
> 
> The issue really does not apply the other way round ... we are not
> expecting a backend to have to deal with more than one implementation of
> the gui, so it's OK for the backend to know a lot about the gui,
> certainly for it to know all about the published AppKit API and make use
> of any feature it likes.
> 
> Are you suggesting going beyond that and implementing specific features
> in the gui for the backend to use?  That doesn't seem terribly
> unreasonable as long as such things can be clearly specified and
> documented and become part of the public gui api ... but I think we'd
> want to keep that sort of thing to a minimum and try to avoid limiting
> our options about how we implement things in the gui.
> 

My feeling is that Nicolas request goes beyond that. What he wants looks
like a mixture of gui/backend/theme to me. Currently gui is responsible
for the general appearance of a gui control, by moving that into back we
would duplicate what themes are supposed to do. We could well have a
theme that uses native drawing functionality, but I don't see much of a
chance to use native widget, neither in themes nor in a backend. Perhaps
somebody could state more clearly what "exposing the view hierarchy" is
supposed to mean. To me the important part of gui is to handle that
hierarchy and it makes backends much simpler to implement that they only
need to worry about simple drawing operations on a flat surface structure.
When we break up this clear structure it should be inside of themes,
something that is experimental and not to closely related to the rest of
the code.