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.
_______________________________________________
Discuss-gnustep mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnustep
