On Mar 26, 4:28 pm, "Marco Pesenti Gritti" wrote: > Mozilla 1.9 is looking pretty good but we have been hitting several > bugs specific to gtkmozembed. We had to apply several patches to > comment out the new code and that's not a good sign.
:(, sorry to hear that. > We are interested in contributing bug reports and patches but we are > deeply concerned about the direction the gtkmozembed development has > taken on the trunk: the main direction to be taken from the work is that you'll be able to (re)build gtkmozembed w/o building mozilla. > * A lot of new code has been committed in big chunks, without any > apparent review process. i'm trying, it's hard, it's not a process i like at all. the direction it's taking is not the direction i want. > * The API is growing without control. The additions doesn't appear to > be well thought and the result is really messy. it is. > * We are duplicating a lot of code. Global history for example or text > selection. yep. > * We are breaking working features, for example file pickers and text > selection. i see the bug report about text selection, i don't see one about file pickers. > * Bug reports about the new code are assigned to nobody and ignored. i'm sorry, i'm doing quite a few things poorly at the moment. i'm trying, the process isn't as i would like it, certainly. > * The approach seem to wrap most of the embedding API in C. > I think we should rather keep gtkmozembed a simple widget exposing > the basic functionality and allow embedders to use the full xpcom API > in C++, pyxpcom or whatever. unfortunately, the embedder in question has foolishly chosen to use C as its embedding story. and i don't have enough influence over it to change this at this time. > Can we revert to 1.8 state, discuss the direction and restore the > review process for patches that goes in? the current process is basically bad patches get written, i try to get them cleaned up, i land them. it's not the process i want, but basically the 1.9 branch is a playpen, if you have proposals for what you want to see in an API, I'd be glad to hear them, and I know that roc and bsmedberg and the others trying to figure out the 2.0 embedding story would as well. What I told bsmedberg, and roc and the others is that I want to treat the 1.9 cycle as just a playpen and not as a basis for a 2.0 API. > I don't want to sound blunt but... that's the only way I see to restore > sanity. the only way i see to restore sanity is to implement gconnect a glib<=>xpcom bridge. this would mean that all the ugly hacks that have invaded gtkmozembed could be deported. i'd like to work on it, but i don't have resources. it takes me a couple of months to review code, and in that time, even more code accumulates. as gtkmozembed has moved to be buildable outside xulrunner, it is possible for any embedder to remove the extra junk and build their own gtkmozembed (yes, this isn't really the direction i want either, but it's now possible). _______________________________________________ dev-embedding mailing list [email protected] https://lists.mozilla.org/listinfo/dev-embedding
