GtkMozEmbed for 1.9
timeless
as some of you may now, I'm timeless.
i've been involved w/ the mozilla.org projects for a number of years
now, and i've always had an interest in embeddings (and ports, and
portability, and just about everything else...).
as it happens, I recently became the owner of GtkMozEmbed.
I also about the same time visited Mozilla Corporation to discuss plans
for the future (aka Mozilla2.0).
The basic idea of Mozilla2.0 is that just about all rules governing
Mozilla1.0 can be thrown out. This includes any and all API/ABI
promises. Note that CAN as defined in RFC 2119 is not the same as MUST
or SHALL or WILL or anything else remotely definite, it's just CAN.
Anyway, various topics were covered, among them was a conclusion that
linux distributions in general build all parts of their platform for
their release from source and thus don't care about ABI between
versions.
One thing that was most definitely not settled is whether each platform
will have its own embedding glue for Mozilla2.0 or whether there will
be a single glue. There are pros and cons to each. But the bottom line
is that any work done today is essentially temporary maintenance on a
dying branch whose end is very near.
Historically GtkMozEmbed, and gecko as a whole promised ABI compat for
anything that was frozen, and GtkMozEmbed being used outside of Gecko
was considered frozen, as such because of the Glib structure design
that it uses, it was not legal to increase the size of the structure to
add more methods or signals.
Because the consumers don't really seem to care about ABI compat and
are more worried about source compat, and because there's really no
good way to improve or change GtkMozEmbed without doing so, we've
decided to break the ABI promise and change the structure size.
The plans for doing so are currently available at
http://wiki.mozilla.org/Gtkmozembed (wikis are wikis, the content may
change or move randomly, possibly to http://developer.mozilla.org/ or
possibly somewhere else similarly unpredictable).
Anyway, I understand that most embedders are not comfortable with
adding more signals, and in fact, I'm probably even less comfortable
with it than any other embedder, but such is life. Today I will land
the current branch (which has been tested and is source compatible with
the major gtk embedders).
Vin
side?
timeless
> can gtkmozembed in used on windows?
there's a Gecko# project which theoretically would work on windows.
> any development happening on that side?
I hope to kill anything resembling such plans. It's an awful idea.
Please don't try building anything on windows based on gtkmozembed.
Thanks.
thompso...@gmail.com
output of a Web page into memory for graphics programs but I have been
able to use it in my regular Windows32 application. It works very well
for me. The site is found at http://www.ubrowser.com
[OT]
Ben Hutchings
<snip>
> The basic idea of Mozilla2.0 is that just about all rules governing
> Mozilla1.0 can be thrown out. This includes any and all API/ABI
> promises. Note that CAN as defined in RFC 2119 is not the same as MUST
> or SHALL or WILL or anything else remotely definite, it's just CAN.
>
> Anyway, various topics were covered, among them was a conclusion that
> linux distributions in general build all parts of their platform for
> their release from source and thus don't care about ABI between
> versions.
Speaking as a Debian developer who embeds Mozilla, I disagree with this.
Yes, we build everything from source. However do not want to have to
rebuild every package that uses Mozilla every time Mozilla changes, and
especially not for security fixes (since this will delay availability of
fixed packages).
Also I feel that Mozilla hasn't been entirely honest with itself about
which APIs are internal and which need to be frozen. I don't think it's
possible to write a non-trivial embedding application using only the
officially frozen interfaces. Perhaps there needs to be an intermediate
level of interface stability?
Please:
(1) Ceate a new name and GUID whenever you need to revise an XPCOM
interface that has ever been exposed. (This is a basic rule of COM.
Note that if you don't change the name, this silently changes other
interfaces that refer to the first changed interface by name.)
(2) Change ABIs infrequently. (GtkMozEmbed is clearly following this!)
(3) Define SONAME versions for shared objects you build which reflect
ABI changes.
I recognise (1) is largely outside your remit but please bear this in
mind.
Ben.
--
Ben Hutchings
This sentence contradicts itself - no actually it doesn't.
Boris Zbarsky
> Speaking as a Debian developer who embeds Mozilla, I disagree with this.
> Yes, we build everything from source. However do not want to have to
> rebuild every package that uses Mozilla every time Mozilla changes, and
> especially not for security fixes (since this will delay availability of
> fixed packages).
I might have misunderstood the point of the Mozilla 2.0 discussion, but as I
understood it the idea was that Gecko 2.0 might not be ABI-compatible with Gecko
1.x, including frozen Gecko 1.x interfaces. At that point there would be a new
ABI which I would certainly hope we would preserve to some extent and
_definitely_ preserve on stable branches.
> Also I feel that Mozilla hasn't been entirely honest with itself about
> which APIs are internal and which need to be frozen.
Oh, we've been honest with ourselves. We know the situation is in a crap state.
We just haven't had the manpower to make it better. More to the point,
designing freezing interfaces is not something people are likely to volunteer
for, and no one's been willing to pay people to do it.
> I don't think it's possible to write a non-trivial embedding application using only the
> officially frozen interfaces.
No thinking needed -- it's not possible. In fact, I doubt it's possible to
write a trivial one, given that nsIWebNavigation and nsIBaseWindow are not frozen.
> Perhaps there needs to be an intermediate level of interface stability?
There effectively has been... We've been treating nsIWebNavigation as
effectively frozen, even though the documentation is not good enough to actually
freeze it.
> (1) Ceate a new name and GUID whenever you need to revise an XPCOM
> interface that has ever been exposed.
Since all XPCOM interfaces are "exposed" the moment you check them into CVS and
allow instantiation of the object in any way, this basically amounts to the
requirement that any time an interface is changed its name change (and that the
old interface always be around). In other words, all interfaces are to start
frozen on initial checkin. That's not really feasible. We do change the GUID
every time the interface changes, to prevent issues with incorrect vtables.
There's also the question of what constitutes an "XPCOM interface". There are
some things that look a lot like "XPCOM interfaces" that really aren't
(nsIDocument comes to mind). We've been working on deCOMifying these as needed,
but the fact of the matter is that we have some need of Gecko modules to be able
to talk to each other. We use interfaces for this purpose. Often, no one by
Gecko internals should be using these interfaces, and we do not promise any sort
of compat for them. We're happy to mark these interfaces as private in the
interface documentation, if that would help. Of course public versions of these
should be available if needed (e.g. compare nsIWebNavigation and nsIDocShell).
> Note that if you don't change the name, this silently changes other
> interfaces that refer to the first changed interface by name.)
Yes, this is why we require that all interfaces referred to by nsIFoo be frozen
before nsIFoo can be frozen.
> (2) Change ABIs infrequently. (GtkMozEmbed is clearly following this!)
I'm not sure what exactly you lump under "ABI" here (the way an interface IDL
file is mapped into a vtable? Or particular vtables for particular interfaces?
The former doesn't change much at all, until now; the point is that with Gecko
2 it will change).
> (3) Define SONAME versions for shared objects you build which reflect
> ABI changes.
I'm not going to touch this one; you and bsmebderg should sort it out. ;)
-Boris
Boris Zbarsky
> interfaces for this purpose. Often, no one by Gecko internals should be
> using these interfaces
I meant "_but_ Gecko internals".
-Boris
timeless
> Yes, we build everything from source. However do not want to have to
> rebuild every package that uses Mozilla every time Mozilla changes, and
> especially not for security fixes (since this will delay availability of
> fixed packages).
APIs are generally not going to change on security releases. This has
been something that mozilla.org has /tried/ to do. Again, I'm not
making guarantees. I have better ways to mess things up (like crash
landings).
> Also I feel that Mozilla hasn't been entirely honest with itself about
> which APIs are internal
honest? i dunno. it's pretty clear which ones are internal by virtue of
the fact that they're namespaced or not frozen.
> and which need to be frozen.
that's a totally different question or statement. The fact is that core
developers (e.g. bz, biesi, and myself) have a pretty good idea which
interfaces that aren't frozen need to be frozen. But as bz mentioned,
we don't have the resources to deal with this correctly. Worse, because
we've already shipped a number of releases, we have all these
commitments from our previous mistakes -- As mentioned at the
beginning, the solution we see is Mozilla2 (this of course is hardly a
solution since the main problem is designing APIs and making sure
everyone who matters gives input in a reasonable way so that the APIs
are actually sufficient and not cumbersome). We also tend to mess up
the interfaces we do freeze (in terms of what we freeze in them, who we
talk to, and how we expect to use them. thankfully we don't generally
/change/ a frozen interface, we just live with bad consequences).
> I don't think it's
> possible to write a non-trivial embedding application using only the
> officially frozen interfaces.
bz covered this, it isn't possible at all.
> Perhaps there needs to be an intermediate level of interface stability?
no, we already have intermediate levels, they cause us more than enough
problems.
> (1) Ceate a new name and GUID whenever you need to revise an XPCOM
> interface that has ever been exposed.
My post which you ignored almost entirely. Is solely about GtkMozEmbed
which is *NOT* XPCOM.
And while i appreciate that you had some input which was relevant, I
really object to you and everyone else hijacking it to list your
complaints about the rest of the process. My post was *not* designed to
focus on the future of Gecko Embedding. It was just a heads up for a
lame duck 1.9 GtkMozEmbed.
> (This is a basic rule of COM.
> Note that if you don't change the name, this silently changes other
> interfaces that refer to the first changed interface by name.)
This is a disaster. And totally pointless. We /could/, /might/ and
probably /should/ bump the IID of all dependent interfaces. But that's
/hard/.
> (2) Change ABIs infrequently. (GtkMozEmbed is clearly following this!)
GtkMozEmbed is hosed because of this. Or rather, because it like
everything else was flash frozen because it used Glib's messed up
frozen structure system which involves embedders simply shaping their
structure as containing the gtkmozembed structure.
The result was that Gtkmozembed could not evolve at all and each
embedder was forced to try to use xpcom to get the same things that all
the other gtkmozembed embedders wanted which were basically whichever
features mozilla/firefox happened to have as special.
> (3) Define SONAME versions for shared objects you build which reflect
> ABI changes.
I too as bz did will defer this argument to bsmedberg.
> I recognise (1) is largely outside your remit but please bear this in
> mind.
I already flamed you above. Next time when you recognize something like
this, please use your own thread. Thanks in advance.
timeless
> Anyway, I understand that most embedders are not comfortable with
> adding more signals, and in fact, I'm probably even less comfortable
> with it than any other embedder, but such is life. Today I will land
> the current branch (which has been tested and is source compatible with
> the major gtk embedders).
Well, that's a laugh. the code was tested in a very narrow scope.
Unfortunately I really didn't like the code and I wanted to make some
changes before landing, because I discovered various things were
destroyed as the branch developed.
And of course, the branch didn't land very cleanly, but it did land,
and hopefully it won't be backed out.
I made a branch today for the first pass of post landing work, but I
think I'm going to close it tomorrow and replace it with a new branch
where additional work will go for the next month or so, and maybe next
time it'll land with fewer bumps. I'll update the wiki with their names
tomorrow.
Ben Hutchings
> Ben Hutchings wrote:
>> Speaking as a Debian developer who embeds Mozilla, I disagree with this.
>> Yes, we build everything from source. However do not want to have to
>> rebuild every package that uses Mozilla every time Mozilla changes, and
>> especially not for security fixes (since this will delay availability of
>> fixed packages).
>
> I might have misunderstood the point of the Mozilla 2.0 discussion, but as I
> understood it the idea was that Gecko 2.0 might not be ABI-compatible with Gecko
> 1.x, including frozen Gecko 1.x interfaces.
I understand that, and I would not find an ABI change in a new major
version surprising or problematic. Perhaps I'm kind of hijacking this
thread?
<snip>
>> Perhaps there needs to be an intermediate level of interface stability?
>
> There effectively has been... We've been treating nsIWebNavigation as
> effectively frozen, even though the documentation is not good enough to actually
> freeze it.
That semi-frozen (slushy?) state is not documented though, is it? Do
you think the state of the documentation simply makes the interface hard
to use, or that users are likely to have to rely on undocumented details
that are subject to change?
>> (1) Ceate a new name and GUID whenever you need to revise an XPCOM
>> interface that has ever been exposed.
>
> Since all XPCOM interfaces are "exposed" the moment you check them into CVS and
> allow instantiation of the object in any way, this basically amounts to the
> requirement that any time an interface is changed its name change (and that the
> old interface always be around). In other words, all interfaces are to start
> frozen on initial checkin. That's not really feasible.
I agree that's not feasible. I would only consider interfaces to be
"exposed" once they're in a numbered release. Those who live on the
bleeding edge (CVS) can expect some pain from unfinished interfaces.
> We do change the GUID every time the interface changes, to prevent
> issues with incorrect vtables.
Are the GUIDs of indirectly changed interfaces also changed?
> There's also the question of what constitutes an "XPCOM interface". There are
> some things that look a lot like "XPCOM interfaces" that really aren't
> (nsIDocument comes to mind). We've been working on deCOMifying these as needed,
> but the fact of the matter is that we have some need of Gecko modules to be able
> to talk to each other. We use interfaces for this purpose. Often, no one by
> Gecko internals should be using these interfaces, and we do not promise any sort
> of compat for them. We're happy to mark these interfaces as private in the
> interface documentation, if that would help.
That could be helpful, though I imagine those interfaces are
inaccessible to embedders anyway.
I don't remember exactly how the build process for Mozilla goes (I've
largely avoided this by using the Debian packages) but I believe that
the C++ header files for interfaces are more or less automatically
picked out for installation; in Debian they end up in a development
package which I build against. These ought to exclude any interfaces
that are intended for internal use only.
> Of course public versions of these should be available if needed (e.g.
> compare nsIWebNavigation and nsIDocShell).
Hmm. While I won't claim nsIDocShell is needed for any non-trivial
application, I certainly seem to need it for my application. However it
may be that what I'm doing really isn't supported.
>> Note that if you don't change the name, this silently changes other
>> interfaces that refer to the first changed interface by name.)
>
> Yes, this is why we require that all interfaces referred to by nsIFoo be frozen
> before nsIFoo can be frozen.
Good.
>> (2) Change ABIs infrequently. (GtkMozEmbed is clearly following this!)
>
> I'm not sure what exactly you lump under "ABI" here (the way an interface IDL
> file is mapped into a vtable? Or particular vtables for particular interfaces?
> The former doesn't change much at all, until now; the point is that with Gecko
> 2 it will change).
Both together.
>> (3) Define SONAME versions for shared objects you build which reflect
>> ABI changes.
>
> I'm not going to touch this one; you and bsmebderg should sort it out. ;)
Should I mention also how different compiler versions can affect this?
OK, pretend I didn't say that.
Ben.
--
Ben Hutchings
I haven't lost my mind; it's backed up on tape somewhere.
Boris Zbarsky
> That semi-frozen (slushy?) state is not documented though, is it?
No, it's not...
> Do you think the state of the documentation simply makes the interface hard
> to use, or that users are likely to have to rely on undocumented details
> that are subject to change?
More of the former, since we are basically trying hard to not change those
details, since callers _are_ relying on them. But until we've written decent
docs, we can't know whether we really will need to change some really broken
detail of how it works now and hence don't really want to declare it frozen. :(
> I agree that's not feasible. I would only consider interfaces to be
> "exposed" once they're in a numbered release.
The problem, historically, is that releases tend to happen without interfaces
getting into shape for them...
>> We do change the GUID every time the interface changes, to prevent
>> issues with incorrect vtables.
>
> Are the GUIDs of indirectly changed interfaces also changed?
Not as much as they should be. We've tried changing GUIDs of interfaces that
inherit from the interface being changed, but changing all interfaces that
reference the given one has indeed not happened. Ideally we would have an
automated tool to do this; doing it by hand is really not scalable.
> That could be helpful, though I imagine those interfaces are
> inaccessible to embedders anyway.
Everything is accessibly if one tries hard enough. ;)
> These ought to exclude any interfaces
> that are intended for internal use only.
That would be nice, yeah...
> Hmm. While I won't claim nsIDocShell is needed for any non-trivial
> application, I certainly seem to need it for my application. However it
> may be that what I'm doing really isn't supported.
I suspect that it may well be needed for nontrivial applications, yes. :(
-Boris
timeless
But of course, if they did that, nothing would build.
So obviously they don't.
Keep the sdk directory in mind, it's where frozen stuff goes.
john.stow...@gmail.com
> I made a branch today for the first pass of post landing work, but I
> think I'm going to close it tomorrow and replace it with a new branch
> where additional work will go for the next month or so, and maybe next
> time it'll land with fewer bumps. I'll update the wiki with their names
> tomorrow.
Ping. ;-)
I could not see any updates to the wiki and am interested in following
your progress with this.
Thanks
John
timeless
> Ping. ;-)
>
> I could not see any updates to the wiki and am interested in following
> your progress with this.
updating the wiki requires finding my password again. i hate wikis. too
many passwords, too many wikis. too many computers, too many browsers,
too many profiles.
leoz...@gmail.com
>
> I could not see any updates to the wiki and am interested in following
> your progress with this.
>
development.
Enjoy.
LeoZ.
Michael Hutchinson
> Vin wrote:
> > can gtkmozembed in used on windows?
>
> there's a Gecko# project which theoretically would work on windows.
Gecko# only wraps GtkMozEmbed. There's a version of GtkMozEmbed that
works on Windows, which is why Gecko# is able to work on Windows.
> > any development happening on that side?
>
> I hope to kill anything resembling such plans. It's an awful idea.
> Please don't try building anything on windows based on gtkmozembed.
> Thanks.
Sorry to come in late on this discussion, but is there any particular
reason for this? GTK and GTK# *are* cross-platform GUI toolkits, so if
you choose actively to discourage GtkMozEmbed on Windows then people
will have to develop other embedding solutions.
--
Michael Hutchinson
http://mjhutchinson.com
leoz...@gmail.com
On Jan 5, 6:18 pm, "Michael Hutchinson" <m.j.hutchin...@gmail.com>
wrote:
> On 27 Nov 2006 06:36:23 -0800, timeless <timel...@gmail.com> wrote:
> > I hope to kill anything resembling such plans. It's an awful idea.
> > Please don't try building anything on windows based on gtkmozembed.
> > Thanks.
I disagree with timeless on this matter.
If old GtkMozEmbed used to be supported on MS Windows than new
GtkMozEmbed MUST support it too.
Another thing is that at the current state of new GtkMozEmbed
development it is maybe too early to include WIN32 support since even
the Linux stuff is under heavy change almost every day.
Thou I would not mind if someone will start to experiment with WIN32
and new GtkMozEmbed already now.
> Sorry to come in late on this discussion, but is there any particular
> reason for this? GTK and GTK# *are* cross-platform GUI toolkits, so if
> you choose actively to discourage GtkMozEmbed on Windows then people
> will have to develop other embedding solutions.
>
This is misunderstanding.
No one is going to discourage GtkMozEmbed on MS Windows.
BTW, if someone is implementing something on plain GTK it is kinda
difficult to make it incompatible with MS Windows since GTK as you said
is cross-platform.
For this new GtkMozEmbed is more or less just to provide MSVC make
files and build instructions for WIN32, I think.
LeoZ.
Michael Hutchinson
> If old GtkMozEmbed used to be supported on MS Windows than new
> GtkMozEmbed MUST support it too.
That's the problem, GtkMozEmbed was not officially supported, but
there were a few unofficial versions around that had been hacked into
a usable state. I don't think many of the patches ever made it into
trunk though.
<snip>
> This is misunderstanding.
> No one is going to discourage GtkMozEmbed on MS Windows.
Well, timeless said "I hope to kill anything resembling such plans"
which seems pretty clear to me.
> BTW, if someone is implementing something on plain GTK it is kinda
> difficult to make it incompatible with MS Windows since GTK as you said
> is cross-platform.
> For this new GtkMozEmbed is more or less just to provide MSVC make
> files and build instructions for WIN32, I think.
Well, it depends. GTK itself is cross-platform, but it does allow
access to some of the underlying platform specifics, so it's perfectly
possible to make a non-cross-platform GTK application. AFAIK making
GtkMozEmbed work under Win32 was not easy, because although on Linux
Mozilla uses GTK, on Win32 it uses native Win32 APIs.
leoz...@gmail.com
On Jan 7, 4:00 pm, "Michael Hutchinson" <m.j.hutchin...@gmail.com>
wrote:
> On 7 Jan 2007 05:17:41 -0800, leoz.2...@gmail.com <leoz.2...@gmail.com> wrote:
>
> > If old GtkMozEmbed used to be supported on MS Windows than new
> > GtkMozEmbed MUST support it too.That's the problem, GtkMozEmbed was not officially supported, but
> there were a few unofficial versions around that had been hacked into
> a usable state. I don't think many of the patches ever made it into
> trunk though.
>
Sad.
> <snip>
>
> > This is misunderstanding.
> > No one is going to discourage GtkMozEmbed on MS Windows.
> Well, timeless said "I hope to kill anything resembling such plans"
> which seems pretty clear to me.
>
Well, I still have some hope that I'd be able to change his mind on
this topic. ;-)
However, if you wish to contribute to GtkMozEmbed WIN32 platform you
can do it now:
1. Make a patch containing your WIN32 related modifications against the
latest GtkMozEmbed branched named 'MICROB_XXX_BRANCH' (where 'XXX' is a
date).
Currently the latest one is: 'MICROB_20070103_BRANCH'.
2. Send this patch to 'romaxa at gmail dot com'.
Romaxa will try to apply your patch to the branch first and if it
does not break the Linux build it will be merged with the branch.
The branch will be merged with Mozilla trunk by timeless later
(practically, withing a month).
Regards,
Leonid.
Oleg Romashin
> However, if you wish to contribute to GtkMozEmbed WIN32 platform you
> can do it now:
>
>
> 1. Make a patch containing your WIN32 related modifications against the
> latest GtkMozEmbed branched named 'MICROB_XXX_BRANCH' (where 'XXX' is a
> date).
> Currently the latest one is: 'MICROB_20070103_BRANCH'.
> 2. Send this patch to 'romaxa at gmail dot com'.
> Romaxa will try to apply your patch to the branch first and if it
> does not break the Linux build it will be merged with the branch.
Also GTK ported to Win, and i hope this patches will be without such
ifdefs like WIN.... ;) ,
it should help to remove some "linux-only" code from current
GtkMozEmbed.