Hello, the idea to write our own set of controls on the base of HippoCanvas was a bad one. I still think that would have been the best approach from an architectural point of view. Also I think that's the way gtk should be going on the long term. But:
* We should be leading this change upstream rather than doing our own thing which will be incompatible with current gtk and also with gtk 3.0, whatever direction they actually choose. * The time is not mature for the switch. HippoCanvas miss a lot of features that will be necessary to replace gtk widgets. We don't have resources to add these features. * Writing controls is *hard*. It takes a lot of time to get all the behaviors and states right. * We need to be able to do the controls work on demand, so that we can keep our main focus on features. These are the main reasons of the direction change. I'm *sorry* to not have put more thinking into it before, I really screwed up there. I guess the lesson to learn here is that, even if we are doing innovative design, we should always try to do it extending our platform, rather then replacing. Going more in the concrete of the new approach. There are three main use cases our graphics API will have to cover: * Free form views (html/flash like). * Custom controls implementation. * Controls framework. The controls framework will be based on gtk. We will try hard to use gtk API and semantics where at all possible. We will extend it when it make sense. We will patch gtk where it's possible to get the changes upstream. We will use HippoCanvas for custom controls implementation where it's useful but we will not expose it in the API. We will use HippoCanvas to implement free form views (ex. the journal one). We can embed gtk widgets in it for the controls. I, Eben and Tomeu had three day meeting in Milan last week to go over the whole controls design specification and figure out the general API requirements and framework. The implementation work already started. I'm going to post a separate mail with more information for the activity authors. Marco _______________________________________________ Sugar mailing list [email protected] http://mailman.laptop.org/mailman/listinfo/sugar
