gtkmozembed development direction
Marco Pesenti Gritti
we are using gtkmozembed to develop the OLPC browser. We recently
upgraded to the trunk because the resolution independence features are
essential on a 200 dpi screen.
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.
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:
* A lot of new code has been committed in big chunks, without any
apparent review process.
* The API is growing without control. The additions doesn't appear to
be well thought and the result is really messy.
* We are duplicating a lot of code. Global history for example or text
selection.
* We are breaking working features, for example file pickers and text
selection.
* Bug reports about the new code are assigned to nobody and ignored.
* 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.
Can we revert to 1.8 state, discuss the direction and restore the
review process for patches that goes in? I don't want to sound blunt
but... that's the only way I see to restore sanity.
Marco
Zac Bowling
That was a concern I was having myself trying to maintain Gecko#, the gtkmozembed wrapper for Mono and gtk#, which is used in a bunch of apps like Beagle, Blam, MonoDevelop, MonoDoc, our ASP.NET Editor, and a bunch of others. The trunk is pretty buggy and pretty messy lately and I'm having to go back investigate recent bugs.
What I'm doing though is that I've started working on a port that can move us off at least off using GtkMozEmbed and to something that can be built externally from the Mozilla tree and linked dynmaically, but provide everything it does currently, as well as a bunch of other interfaces. I'm building it off the new Gecko SDK builds from XulRunner, now that they started that back up. I'm designing it be a simple wrapper that exports to basic C exports and can be built on any platform instead of depending on Gtk+ as the GFX toolkit and only working on Linux. Originally I started so we can use it to power the WebControl backend in our version of System.Windows.Forms on Linux, Mac, and Windows natively, but now I'm also investing how it can also power the backend to Gecko# in the future as well and then make it possible so that we interoperate with the Mono XPCOM bridge when its ready (also using a single Init_XPCOM call to start up Mozilla for both the bridge and WebControl)
I'm designing it to be simple while still being as veristal as I possibly can. My goal is to have an API that is expandable in the future without breaking API/ABI compatabilty. I'm not limiting it to just my use so that possibly if someone want to rewrite WxMozEmbed or anything against it in the future, they could. Things we need in Mono are things like DOM access, dialog and new window overriding, custom stream handling to pipe data in, progress notifcation callbacks, and various other things, some of which we can't do directly in GtkMozEmbed (without Uber hacking), but are going into my wrapper. Its similar to the Java embedding wrapper's design (which was a gtkmozembed fork) except it doesn't have to be built inline with Mozilla.
If you remember back a year or two, I was the last one to update the bug related to the Win32 hack to get GtkMozEmbed working on Windows. However after working with it more and understanding the nature of the hack better and how the focus model for gtkmozembed was taking for granite the fact that the controls in the window are also Gtk components down in the GFX layer, I decided to get away from trying to maintain that beast of a work around (Tor the "GTK+ Win32" guy did as well when looking at it for Novell for possibly using it to port Evolution to Win32).
If you need something more then it provides and if you have the time, I suggest avoiding gtkmozembed and writing your own embedding wrapper for exactly what you need (a little bit of a learning curve getting setup but its easy once you enviroment is setup). My library will not be ready for primetime for more then a few months, but you can check it out in the mono svn if you are curious in the "mozembed" module (oops, what is there is about 6 months old on the public svn today).
Hope that helps.
Zac Bowling
http://zbowling.com/
> _______________________________________________
> dev-embedding mailing list
> dev-em...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-embedding
timeless
> 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).
bre...@mozilla.org
> > * 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.
Who is module owner? If you don't like the direction and you're owner,
then change direction. If you are powerless before your paymaster and
less competent hidden patch-generating team-mates, put their work on a
branch and get them to realize they will never land if they don't
shape up.
I'm going to ask you to roll back the trunk changes to a private
branch based on what I've heard. I think blizzard, roc, and other
senior hackers would agree. Is there any reason why doing so is *not*
the right thing by Mozilla rules and customs?
/be
rocal...@gmail.com
> On Mar 26, 4:28 pm, "Marco Pesenti Gritti" wrote:
> > * 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.
It sounds like you should be keeping your stuff out of the trunk,
then.
> the current process is basically bad patches get written, i try to get
> them cleaned up, i land them.
Even more so.
> 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 recall this, but never mind ... you don't have a license to
break API for 1.9 and neither does anyone else. If you want to mess
with the APIs you're welcome to do so in your own tree. (Well, as long
as you don't expect other Gecko-using apps to run on your platform.)
> > 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.
How about we just deport them to your private branch right now?
> 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).
Can we keep that capability and revert all the other breaking changes?
If so that sounds like a good plan for 1.9.
Rob