java-gnome-hackers — Hacking on the bindings themselves: design issues and co-ordination

Re: [java-gnome-hackers] problem with compilation of java-gnome 4.0.9

[Federico <fe...@gm...>]

Hi Andrew,

do you remember of my problem with the compilation of java-gnome 4.0.9?

It compile fine with make, but make demo shows thi error:

...
JAVA	button.ExamplePressMe
Exception in thread "main" org.gnome.glib.FatalError: (null)-WARNING
	at org.gnome.gtk.GtkMain.gtk_init(Native Method)
	at org.gnome.gtk.GtkMain.init(GtkMain.java:31)
	at org.gnome.gtk.Gtk.init(Gtk.java:78)
	at button.ExamplePressMe.main(ExamplePressMe.java:49)

I was working at a project in Omnet++, and during a recompilation,
I got a number of errors. The problem: ubuntu 8.10 intrepid updated
gcc from 4.2 to 4.3 and this makes a lot of changes.
So I tried to edit my .config file of java-gnome changing gcc-4.3 with
gcc-4.2 and then the error *disappears*.

The window button test appears on my screen.

I want to tell you this, because I suppose that other people like me
would try your project in ubuntu 8.10.

Thanks for your help

Federico


Andrew Cowie wrote:
> On Fri, 2008-10-17 at 07:38 +0200, Federico wrote:
>> Irregular conf file line(1):
>> # this file contains quirks
> 
> Did you ever get anywhere with this? Perhaps a newer GTK or a newer X
> server, or a different theme, or...?
> 
> [Since no one else has reported this, I'm reluctant to think that it is
> something that java-gnome 4.0.9 is doing wrong]
> 
> AfC
> Sydney
> 
> 

Re: [java-gnome-hackers] Vte and sexy branches

[Andrew C. <an...@op...>]

On Tue, 2008-11-04 at 05:48 +0200, Serkan Kaba wrote:
> I recreated defs files with demuxer,redid my changes on them and pushed
> those 2 branches. I'm waiting to hear your comments on those.

Sure! This is terrific work, Serkan. I'll look tonight.

> Also I have a question. It seems to me that we have to add a Plumbing class for
> each module and I did that in those 2 branches. Is there a better way
> that I miss, currently?

No, what you did is fine. It's just something you take 10 seconds to
hand craft. Done once, that's it, done forever.

Having a Plumbing class in each package is just one of the many things
that we do machinery-wise as a part of engineering things so that
internals are not publicly visible.

Most of the time Java is sensible about this sort of thing, but it would
have been a hell of a lot easier if there was a "library" visibility
level. There isn't, but to ensure that package and protected visibility
can be leveraged to the max elsewhere, sometimes little funnies like
Plumbing in each package were necessary. Remember, it's actually all
about translation layer classes being able to see the protected
pointerOf() and numOf() from the top of the Plumbing hierarchy. That's
the real point. If I recall correctly, having the [often empty] package
one meant that the code generator was easier. It just kinda worked out
that way. Srichand or Vreixo could correct me, I'm sure.

(as it happens, it also came up that such classes were a great place to
put little package specific custom overrides; the Plumbing in
org.gnome.gdk has a boxedFor() that handles a challenging corner case.
Quite useful)

AfC
Sydney

Re: [java-gnome-hackers] Proposing Java-Gnome-4.x for GNOME

[Andrew C. <an...@op...>]

On Tue, 2008-11-04 at 05:51 +0200, Serkan Kaba wrote:
> Can we make a proposal (in this short time) or should be postpone it
> to next GNOME release cycle?

java-gnome, as a project, has been an "official" GNOME bindings since
sometime in 2004.

My personal feeling has always been that just because the java-gnome
community moved on by consolidating the project as it was at the state
of version 2.x to a new codebase at version 4.0, as a project nothing
essential has changed.

I've long been a bit annoyed that release-team hasn't got around to
updating the set of what they put out, but on the other hand it matters
little because what is important is that distros carry the software. And
most do. Thus if release-team changes its set, then we're done.

So I am *supremely* ambivalent about "proposing" java-gnome for GNOME
because java-gnome is already a part of GNOME.

I suppose I can get over that ambivalence. Frankly, what I really want
is someone else to lead the charge; I can't do all the work. People like
Serkan speaking up is a big step in the right direction, but others need
to as well.

Part of the problem in this community has long been that people that are
happily using the library tend not to speak up or talk to me one to one.
While all that positive feedback (in the case of people talking
privately) is wonderful, it doesn't help fight the usual Open Source
problem of people chiming in who have nothing to do with a project
thinking their opinion is more important than that of the people who
have been involved in it for years. I've learned that being an Open
Source maintainer is being tolerant of such, but seeing as how no one
pays me to work on this, I must admit that at the moment I don't have a
whole lot of patience for such nonsense. I'd rather spend my time on
people who contribute code and helping newcomers who turn up in
#java-gnome and on java-gnome-developer, so that's what I do.

Anyway, not my intent to sound arrogant or anything; this is still the
same project that I reluctantly took up leadership of 3 years ago, and I
still feel a huge debt to people like Jeffery Morgan and Andrew Overholt
- serious Open Source hackers who were also Java people and wise enough
to understand the trick was to find a way through the turbulent waters
that happen when massive communities like Java, Linux (remember, most of
Java developer-land knows nothing of the Linux, Open Source & Free
Software Way) and GNOME come together. Trying to serve all three, so as
to bring new Linux people to GNOME while doing the best job we can to
provide a faithful home for existing GTK developers has been an enormous
challenge.

We've done ok, and I appreciate the hard work of all the people who have
contributed over the last few years to make this project a reality. I
for one have just about everything I need now from java-gnome. The
applet mystery is really the only thing left on my wish list, and that
can wait. There's lots of work in progress software I want to get back
to, but personally I'm taking a bit of a pause to recharge my batteries
a bit so I can come back to hacking with it being fun; certainly
fighting email battles is the last thing I want to do.

++

So, on to concrete matters, the release guys want the library to be
frozen forever.

We're actually getting reasonably close to that. More to the point, we
still have 4.2 (and 4.4, and...) available as future API breaks as
necessary, and 4.0 has been [more or less] API stable since 4.0.3 or so.
I'm still sticking to the escape clause in the warning at the bottom of
http://java-gnome.sourceforge.net/4.0/ but in essence, things have been
pretty good. It's like all of Free Software: if your code is open then
you have no problem rebuilding if we change. And if your code isn't
open, too bad. Having had java-gnome packaged since 4.0.3 and having had
a [so what if it's little] application using the library packaged there
too have taken us through most of the issues. I think we're in good
shape in release management terms. I have some doubts about the Debian
package, but ultimately that's Debian's problem.

Anyway, taking 4 as epoch and {4.0, 4.2, 4.4, ...} as major release, and
{4.0.6, 4.0.7, 4.0.8, 4.0.9, ...} as minor releases (which has been my
intent) I think we're good. Demonstrated practise and demonstrable
history and all that. And since the GNOME rules provide that major
releases are allowed to API break, I think we're actually OK and have
been all along.

I've worked insanely hard to ensure our releases have been of good
quality. I'm proud of our track record. I think it's important, and I
think it's a good legacy to the person who takes over as maintainer
after me.

++

If people who have been serious hackers on and/or developers with
java-gnome over the past 2+ (or 6+) years want to make a fuss with
desktop-devel-list, then I understand that I as maintainer have to write
the original proposal. I will certainly do that, but I'm only going to
unearth that can of worms if there is a strong group of people here -
and on that list - that will fight off the inevitable, harmless, but
nevertheless very persistent people who always like to comment in such
debates.

On the other hand, if you just want to leave it be, that's fine too.

I agree that it's probably time we had it out with release-team; I'm not
really sure that we need to go to desktop-devel-list to do so, but I'll
leave that to others here to decide.

Either way, but I'm not going to do it alone. This project has for 10
years been one person carrying the torch with others dipping in and out
from time to time. That's fine - and not uncommon for small Open Source
projects like ours that are a labour of love, but if there's on time I'm
not going to walk by myself it's fighting battles on GNOME mailing
lists.

After all, *I* don't need a release to use java-gnome; *neither do you*.
That's something Rusty Russel taught me: doing releases at all is itself
a massive gesture and contribution to stability for other people - work
that doesn't do *you* nor *I* any good. Going one step further and
having debates in the broader GNOME community is a **huge** operation. I
will absolutely do my part as maintainer, but only if enough people are
going to be there to fight the battle with me.

So my friends, what's it to be?

AfC
Sydney

[java-gnome-hackers] Proposing Java-Gnome-4.x for GNOME

[Serkan K. <se...@ge...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I remember talking to Andrew about proposing the new bindings for GNOME.
Then I just noticed today is the new module prosal deadline? Can we make
a proposal (in this short time) or should be postpone it no next GNOME
release cycle?

- --
Sincerely,
Serkan KABA
Gentoo/Java

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkkPxt4ACgkQRh6X64ivZaKClgCfcgillK+jvEH4V95TzKetSDie
+pIAnRDJJwzcsta+w+hqx4M8QRNp5ukg
=Oq8h
-----END PGP SIGNATURE-----

[java-gnome-hackers] Vte and sexy branches

[Serkan K. <se...@ge...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I recreated defs files with demuxer,redid my changes on them and pushed
those 2 branches. I'm waiting to hear your comments on those. Also I
have a question. It seems to me that we have to add a Plumbing class for
each module and I did that in those 2 branches. Is there a better way
that I miss, currently?
- --
Sincerely,
Serkan KABA
Gentoo/Java

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkkPxiYACgkQRh6X64ivZaJ1cgCfc0ydFaH0eM1x/jfaQh0/X9nY
+pUAmwc9mKDKbkqFwRr0MEZyM3CztRcN
=e2nX
-----END PGP SIGNATURE-----

Re: [java-gnome-hackers] pkg-config weirdness for an Ubuntu developer

[Srichand P. <sri...@gm...>]

Coincidentally, I ran into this issue a while back. I think the issue  
here is that ubuntu's newest distribution uses gtk 2.19 while the  
configure script looks for something newer. I hacked the configure  
script to ignore the gtk version temporarily. I am sure there is a  
better fix, but this seemed to work for me.

If you are sure that you have updated your installation, then it may  
just work!

Srichand

-- 
Srichand Pendyala
Michigan Technological University

On Oct 16, 2008, at 11:02 PM, Andrew Cowie <an...@op... 
 > wrote:

> There as a thread on the java-gnome-developer mailing list recently
> where a fellow had a hard time building us because pkg-config was
> failing.
>
> Anyone else with Ubuntu [8.10?] run into this? We don't use that  
> distro
> ourselves, so I cannot duplicate...
>
> AfC
> Sydney
>
> -------- Forwarded Message --------
> From: Andrew Cowie <an...@op...>
> To: jav...@li...
> Subject: Re: [Java-gnome-developer] problem with compilation of
> java-gnome    4.0.9
> Date: Wed, 15 Oct 2008 19:05:43 +1100
>
> On Wed, 2008-10-15 at 09:38 +0200, federico tramarin wrote:
>> The problem was that the environment variable PKG_CONFIG_PATH was not
>> set.
>
> Wow. That's weird.
>
> I was of the understanding that /usr/lib/pkgconfig was the default  
> path
> that pkg-config had hardwired in at installation time and that it  
> should
> look there automatically.
>
> How strange.
>
> Anyone know what sort of circumstances would have led to this  
> situation
> for Federico?
>
> [ie, I don't have to set PKG_CONFIG_PATH for pkg-config to work, it  
> just
> does]
>
> AfC
> Sydney
>
>
>
>
> --- 
> ----------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's  
> challenge
> Build the coolest Linux based applications with Moblin SDK & win  
> great prizes
> Grand prize is a trip for two to an Open Source event anywhere in  
> the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> java-gnome-hackers mailing list
> jav...@li...
> https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers

[java-gnome-hackers] pkg-config weirdness for an Ubuntu developer

[Andrew C. <an...@op...>]

There as a thread on the java-gnome-developer mailing list recently
where a fellow had a hard time building us because pkg-config was
failing.

Anyone else with Ubuntu [8.10?] run into this? We don't use that distro
ourselves, so I cannot duplicate...

AfC
Sydney

-------- Forwarded Message --------
From: Andrew Cowie <an...@op...>
To: jav...@li...
Subject: Re: [Java-gnome-developer] problem with compilation of
java-gnome	4.0.9
Date: Wed, 15 Oct 2008 19:05:43 +1100

On Wed, 2008-10-15 at 09:38 +0200, federico tramarin wrote:
> The problem was that the environment variable PKG_CONFIG_PATH was not
> set.

Wow. That's weird.

I was of the understanding that /usr/lib/pkgconfig was the default path
that pkg-config had hardwired in at installation time and that it should
look there automatically.

How strange.

Anyone know what sort of circumstances would have led to this situation
for Federico?

[ie, I don't have to set PKG_CONFIG_PATH for pkg-config to work, it just
does]

AfC
Sydney

Re: [java-gnome-hackers] a possible merge strategy

[Andrew C. <an...@op...>]

On Thu, 2008-10-16 at 21:17 -0400, Colin Walters wrote:
> Boxed types should always be copied when you get them.

We did that all the time anyway; we just had infrastructure anticipating
for the times where that wouldn't be the case. Turned out to be
unnecessary. Remove that was one of the things that Vreixo's recent
memory management branch did, so it's all cleaned up as of 4.0.9 (though
it sounds like there's an errant comment here or there. Hm. Have to hunt
that down).

[Naked structs and GBoxeds were treated as the same thing by the pygtk
bindings, and that led to some confusion over the years as it became
clear that they weren't, quite]

People in #gnome-hackers and #gtk+ are usually kind enough to help with
this sort of thing, but it's always nice to get further confirmation we
were right about that. Good stuff.

AfC
Sydney

Re: [java-gnome-hackers] a possible merge strategy

[Colin W. <wa...@ve...>]

On Thu, Oct 16, 2008 at 6:13 PM, Stefan Prelle <st...@pr...> wrote:

> I can imagine that since you already adopted the gstreamer-java object
> layer you are not very happy about thinking about a different one.

The gstreamer-java one was/is pretty nice, but I am not wedded to it,
and am taking another look at the java-gnome layer now.  Some of the
underlying JNI code in jni/ would be relatively straightforward to
use, though this gives me a bit of pause:

	g_idle_add(bindings_java_memory_deref, object);

Granted most programs are going to use the mainloop, but it is valid
to not do so.

The dependency on GTK+ in various parts (e.g. call to gtk_main_quit()
in bindings_java_signal) should really be converted to just
GLib/GObject.

The higher level (bindings/), would be better off using a class (JGIR
uses JNA's Pointer class) instead of just 'long' for pointers.  There
are some things not handled at all - like "notify::" for properties
(JGIR generates signals for these).

The handling of boxed types is just wrong.  "The trick is to figure out
 * whether we are owner of the <code>GBoxed</code> or not...</i>".
Boxed types should always be copied when you get them.  See:
http://library.gnome.org/devel/gobject/unstable/gobject-Boxed-Types.html

I'll take a look in more detail later.

Re: [java-gnome-hackers] a possible merge strategy

[Stefan P. <st...@pr...>]

Hi Colin,

Am Donnerstag, den 16.10.2008, 12:14 -0400 schrieb Colin Walters:
> > Unless we find a way to build on the same code
> > generator and hopefully GObject foundations, both APIs would have
> > nothing in common.
> 
> The code generator and GObject foundations are related but can be
> separated.  I think if we shared a GObject layer it would be a huge
> win.  The only major difference is a dependency on JNA.  Would that be
> acceptable to java-gnome?

Honestly I don't know because I am not aware of the consequences to the
whole project. But from what I understand it is not using a bit of JNA
alongside with JNI in the GObject layer - it is either JNA or JNI. So I
guess we are not talking about merging but replacing the GObject layer.

I still don't understand our GObject layer and I avoid digging to deep
in there, so I am not sure what the consequences would be. But I imagine
that it really takes careful planning and a lot of testing, so this
might be a long time goal.

A short time goal could be to use GIR to replace the .def files we are
currently using and write a code generator that for startes builds code
suitable for our GObject layer.

I can imagine that since you already adopted the gstreamer-java object
layer you are not very happy about thinking about a different one.

So I see two ways how we could proceed here:
1. You could contribute by putting our GLib/GObject layer on a GIR
   foundation and provide a code generator that produces code like
   our current code generator would. This would be a help we all would
   appreciate.

2. You stick to the idea of your object layer in which case you would 
   need to find out what adjustments would need to be done to our 
   current GObject layer, generated code or public API. I am a bit
   reluctant here since this would render lots of effort from recent
   years obsolete without a real need, but perhaps the result would
   convince me. But until that I guess you would work mostly alone here
   (with help on your questions of course).

But these a only my 2 cents and since my focus is on public API and
coverage it would be good if the people knowing the GObject code and
code generator would comment here.

Stefan

Re: [java-gnome-hackers] a possible merge strategy

[Gerald B. <ger...@gm...>]

Yes, that is what I'm suggesting. Build on the same auto-generation (i.e.
deprecate the current auto-generation and replace with new Gtk/Gobject
introspection)

So, it would be something like this:

|---------------------------------------------------|
|                                                   |
|                 Application Code                  |
|                                                   |
|---------------------------------------------------|
|                                      |            |
|        Public/Java-Friendly API      |            |
|                                      |            |
|---------------------------------------            |
|                                                   |
|        Auto-Generated, Introspection API          |
|                                                   |
|---------------------------------------------------|
|                                                   |
|                     Gtk API's                     |
|                                                   |
|---------------------------------------------------|


The idea being that Java application should use the Public/Java-Friendly API
except where there is not appropriate coverage.



On Thu, Oct 16, 2008 at 11:56 AM, Stefan Prelle <st...@pr...> wrote:

>
> On Thu, 2008-10-16 at 11:42 -0400, Gerald Butler wrote:
> > Could a possible compromise be:
> >
> >     1. Auto-Generate a public, full-coverage API using the
> > introspection method
> >     2. Call this API, though public, not recommended for direct usage
> > and clearly document that it will change whenever the underlying Gtk
> > API's change
> >     3. Create the "Java Friendly", well reviewed, well JavaDoc
> > documented public API to wrap the above generated API
>
> Wouldn't that be basically the same as two competing projects combined
> in a container project? Unless we find a way to build on the same code
> generator and hopefully GObject foundations, both APIs would have
> nothing in common.
>
> Stefan
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> java-gnome-hackers mailing list
> jav...@li...
> https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers
>



-- 
Gerald E. Butler
http://bffoss.com
ger...@gm...

Re: [java-gnome-hackers] a possible merge strategy

[Colin W. <wa...@ve...>]

On Thu, Oct 16, 2008 at 11:56 AM, Stefan Prelle <st...@pr...> wrote:
>
> Wouldn't that be basically the same as two competing projects combined
> in a container project?

Yeah, in a sense, though I think it is where we want to go.

> Unless we find a way to build on the same code
> generator and hopefully GObject foundations, both APIs would have
> nothing in common.

The code generator and GObject foundations are related but can be
separated.  I think if we shared a GObject layer it would be a huge
win.  The only major difference is a dependency on JNA.  Would that be
acceptable to java-gnome?

Re: [java-gnome-hackers] a possible merge strategy

[Colin W. <wa...@ve...>]

On Wed, Oct 15, 2008 at 10:04 AM, Stefan Prelle <st...@pr...> wrote:

> You have a point when saying that providing an API by means of
> auto-generation is faster than hand-writing them.

It's not just that it's faster - there are other arguments as well.
For example, if one isn't an expert in the library domain, one could
easily break the library.  To pick a recent example, trying to change
some of the GTK+ double arguments to integers.

Even if one was an expert in all areas of GTK+ (and GTK+ is
*enormous*) - how much would such a binding author in general know
about web browsers (WebKit), or universal plug and play (GUPNP) or
OpenGL/canvas (Clutter) or multimedia (GStreamer)?  Personally I don't
- but I'm trying to learn Clutter right now, and using Eclipse+Java is
a nice way to do that.  There's no way I would feel qualified to try
to rewrite all the documentation and re-type all of the APIs.  Even if
I considered that a useful way to spend my time, which I definitely
don't.

> But just generating
> the code is not really helping. You need (as you already stated) review
> the code. Depending on what your goals are, there can be a lot to be
> done.

Depends on a few variables - for old code like GTK+ with some very
complex APIs, yes, some overrides are going to help a lot.  On the
other hand for smaller and newer libraries like say libnotify or
GUPNP, the existing API is going to be fine.

The GObject introspection work is going to make this even better going
forward, because we will have a --fail-unbindable option to
g-ir-scanner, so if a C library author adds an unbindable or "weird"
function while they're working, their build fails *right then* while
they're developing, rather than binding authors having to figure it
out 6 months to a year (or longer) later.

> This is of course unless the goal is to look more familiar to C
> developers than to Java developers.  But personally I don't see the
> point to tailor Java bindings for C developers

Just as an example, I think using something like JamVM+JGIR would have
been a good way to implement the new GDM.  Now of course the new GDM
is long since rewritten, but java-gnome's coverage of not even close
to all the necessary parts of GTK+, not to mention the non-coverage of
GConf would have completely ruled it out.

Personally, my sense is that a lot of the "Java people" are using
Windows or OS X if they even ever tried our platform, and as I said
before, who I think we need to concentrate on is providing a nice
environment for community developers who do know GTK+, but might not
know Java, looking for a nice IDE (Eclipse) with a working debugger
and a wide collection of usable libraries.  Or at least, that
describes me and a number of people I know.

Re: [java-gnome-hackers] a possible merge strategy

[Stefan P. <st...@pr...>]

On Thu, 2008-10-16 at 11:42 -0400, Gerald Butler wrote:
> Could a possible compromise be:
> 
>     1. Auto-Generate a public, full-coverage API using the
> introspection method
>     2. Call this API, though public, not recommended for direct usage
> and clearly document that it will change whenever the underlying Gtk
> API's change
>     3. Create the "Java Friendly", well reviewed, well JavaDoc
> documented public API to wrap the above generated API

Wouldn't that be basically the same as two competing projects combined
in a container project? Unless we find a way to build on the same code
generator and hopefully GObject foundations, both APIs would have
nothing in common.

Stefan

Re: [java-gnome-hackers] a possible merge strategy

[Gerald B. <ger...@gm...>]

As an outsider looking in it seems like this bioils down to the following:

    1. This project currently uses Auto-Generation of a private API from the
.defs files for Gtk etc.
    2. This is then wrapped with a public, hand-constructed,
hand-documented, and intimately reviewed API
    3. GObject/Gtk now provides an introspection/reflection API to make it
much easier for language binding to auto-generate their binding API
    4. Colin's project uses the new introspection API to do just that,
providing nearly complete coverage (caveat: not all Gtk libs are based off
GObject, e.g. Cairo, and so are not able to be thusly introspected)
    5. Colin (and his ilk) would like to see complete coverage more than
ideal public API
    6. Stefan (and his ilk) would prefer a "Java Friendly" and well reviewed
public API more so than immediate complete coverage

Could a possible compromise be:

    1. Auto-Generate a public, full-coverage API using the introspection
method
    2. Call this API, though public, not recommended for direct usage and
clearly document that it will change whenever the underlying Gtk API's
change
    3. Create the "Java Friendly", well reviewed, well JavaDoc documented
public API to wrap the above generated API

This provides a couple of advantages:

    1. Nice, Java-friendly, stable public API (though possibly incomplete
initially) for those who wish (like me) to use something Java-friendly
    2. Full-coverage, near immediate Semi-Public (for lack of a better term)
that closely tracks the underlying Gtk API's

This, to me, seems like the best of both worlds. Thoughts?

Kind Regards,

Gerry B.


On Thu, Oct 16, 2008 at 10:54 AM, Stefan Prelle <st...@pr...> wrote:

> Hi Colin,
>
> On Thu, 2008-10-16 at 10:34 -0400, Colin Walters wrote:
> > Anyways - so you are saying you want to continue on java-gnome's path
> > of being a hand-crafted API for some parts of GTK+ and below,
> > continuing to expect that at some point many new people will appear
> > and write/maintain bindings with custom documentation for every
> > GObject library out there?  You see no role for having a correct
> > generated API to fill in gaps in the wide variety of libraries
> > java-gnome hasn't even looked at?
>
> Provoking question :)
>
> I would put it differently. We already use autogenerated APIs but take a
> different approach then you do. This may be combined but it will be a
> tough piece of work. I'd like to see cooperation on that part.
>
> Regarding coverage: If we chose to go your way for the yet not covered
> APIs and provide an unreviewed public API, we can not change the API
> later on if we find it unsuitable since this would break compatibility.
> So we would need to review every covered API down to every method. This
> is in fact the same level of work we now have when we review and cover
> APIs provided from our code generator.
>
> Or let me put your provoking question the other way around: You prefer
> to risk having a crappy API which cannot be changed later just to have
> the API immediately?
>
> Cheers,
>  Stefan-who-hopes-this-won't-end-in-a-flame-war
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> java-gnome-hackers mailing list
> jav...@li...
> https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers
>



-- 
Gerald E. Butler
http://bffoss.com
ger...@gm...

Re: [java-gnome-hackers] a possible merge strategy

[Stefan P. <st...@pr...>]

Hi Colin,

On Thu, 2008-10-16 at 10:34 -0400, Colin Walters wrote:
> Anyways - so you are saying you want to continue on java-gnome's path
> of being a hand-crafted API for some parts of GTK+ and below,
> continuing to expect that at some point many new people will appear
> and write/maintain bindings with custom documentation for every
> GObject library out there?  You see no role for having a correct
> generated API to fill in gaps in the wide variety of libraries
> java-gnome hasn't even looked at?

Provoking question :)

I would put it differently. We already use autogenerated APIs but take a
different approach then you do. This may be combined but it will be a
tough piece of work. I'd like to see cooperation on that part.

Regarding coverage: If we chose to go your way for the yet not covered
APIs and provide an unreviewed public API, we can not change the API
later on if we find it unsuitable since this would break compatibility.
So we would need to review every covered API down to every method. This
is in fact the same level of work we now have when we review and cover
APIs provided from our code generator.

Or let me put your provoking question the other way around: You prefer
to risk having a crappy API which cannot be changed later just to have
the API immediately? 

Cheers,
  Stefan-who-hopes-this-won't-end-in-a-flame-war

Re: [java-gnome-hackers] a possible merge strategy

[Colin W. <wa...@ve...>]

On Wed, Oct 15, 2008 at 10:03 PM, Andrew Cowie
<an...@op...> wrote:

> Colin is exposing every last function in GNOME as raw public API.

No, I'm not.

> Goodness. Given that so many of those functions are  deprecated,

There's a gtk-doc Deprecated: flag, which shows up in the typelib, and
JGIR generates an @Deprecated annotation.

> unnecessary, unused, superseded,

Perhaps - but there aren't that many APIs like that.

> or is just C sugar,

We don't expose things like varargs; and the introspection system
supports hiding C sugar functions.

Anyways - so you are saying you want to continue on java-gnome's path
of being a hand-crafted API for some parts of GTK+ and below,
continuing to expect that at some point many new people will appear
and write/maintain bindings with custom documentation for every
GObject library out there?  You see no role for having a correct
generated API to fill in gaps in the wide variety of libraries
java-gnome hasn't even looked at?

Re: [java-gnome-hackers] a possible merge strategy

[Andrew C. <an...@op...>]

On Wed, 2008-10-15 at 16:04 +0200, Stefan Prelle wrote:
> E.g. we took considerable efforts to come up with an API for TreeView or
> TextView which we consider better than that a code generator would
> suggest.

Everyone please keep it straight in their minds that java-gnome 4.0 *is*
substantially generated.

It is only the outside layer that presents the public API that is hand
crafted. The rest, that it wraps, is all generated - and having been a
java-gnome 2.x hacker and later its maintainer, all I can say is Thank
God because writing all that stuff by hand was a nightmare.

So substantially our design goals for 4.0 have been achieved. This
architecture has been validated again and again as we have had to make
minor tweaks. There are of course still a number of TODOs and FIXMEs and
NOTDONEYETs here and there, but really those only need to be addressed
as people run into needing things that run afoul of such minor problems.

        [And I'd just like to put a huge shout out to Vreixo Formoso,
        who did the bulk of the grunt work during 2007 on the parts of
        the code generator that I was reluctant to get into. GLists,
        arrays and out-parameters come to mind. Thanks Vreio!]

Meanwhile, it means we can concentrate on making sure our public API is
sensible in Java terms and stable, protected from the the whims and
variations happening in the underlying libraries. 

Anyway, everything Stefan is saying is totally on point. I just wanted
to quibble on the "generation" issue. java-gnome is a generated binding.
We just have a thin wrapper layer to provide for an abstraction that
shields developers from things that simply do not (and never will)
concern them.

... not to mention the entire engineering design of not doing injection
into generated code; doing so is a HUGE anti-pattern. Ask anyone who has
been around enterprise Java over the last 3-8 years. We went to great
lengths to avoid it.

        [Not to mention it being the foundation of how we can properly
        document our public API. That doesn't seem to have come up.
        5a-Architecture discusses this in detail]

Colin is exposing every last function in GNOME as raw public API.
Goodness. Given that so many of those functions are  deprecated,
unnecessary, unused, superseded, or is just C sugar, this seems
misguided. Given further that the signatures of quite a number of the
functions that *are* desirable are inappropriate in Java makes it really
questionable indeed.

Anyway, the java-gnome code generator already does generate code for
everything it is fed data about - it just doesn't present it as public
API. It could have, and for about 5 minutes at first it was tempting to
do so. It didn't take very long 30 months ago when we were prototyping
things to realize that exposing everything willy-nilly was a terrible
idea. The shape of the public API of a library is for humans to decide.

Most of the time exposing a method in java-gnome is as simple as writing
a single line method - and, by design, code completion against the
package visible generated code makes this no effort whatsoever.

What does take thought is for people to ponder whether the public
signature being presented is indeed appropriate (as usually it is) and
to then invest a few moments into writing some documentation. It's
really not that much to ask... but when trying to explain how something
works quite often you realize that maybe this isn't something that
should be exposed after all.

Anyway, this is all an aside; I just wanted to encourage people to keep
their terminology straight. You know me - the guy who works hard to
point out the difference between users, developers, and hackers. :)

AfC
Sydney

-- 
Andrew Frederick Cowie

Operational Dynamics is an operations and engineering consultancy
focusing on IT strategy, organizational architecture, systems
review, and effective procedures for change management. We actively
carry out research and development in these areas on behalf of our
clients, and enable successful use of open source in their mission
critical enterprises, worldwide.

http://www.operationaldynamics.com/

Sydney   New York   Toronto   London

Re: [java-gnome-hackers] a possible merge strategy

[Stefan P. <st...@pr...>]

> > Personally I would like to keep the hand written API, because I see it
> > as a big plus.
> 
> Sure, until you want to use WebKit, Clutter, or GStreamer.

Don't mix things here. Just because there currently is no coverage for
those in java-gnome does not mean that there won't be any. Usually this
only means that no one was interested in these parts enough to have a
look at it. This might change as requests arise.

You have a point when saying that providing an API by means of
auto-generation is faster than hand-writing them. But just generating
the code is not really helping. You need (as you already stated) review
the code. Depending on what your goals are, there can be a lot to be
done.

E.g. we took considerable efforts to come up with an API for TreeView or
TextView which we consider better than that a code generator would
suggest. So even after a code generation there often is a lot of changes
to be made.

This is of course unless the goal is to look more familiar to C
developers than to Java developers.  But personally I don't see the
point to tailor Java bindings for C developers - attracting Java
developers with bindings that behave like they are used to seems to be a
better idea to me.
But as you already pointed out: It is a matter of goals.

> > This might go together with improvements on our GObject code, but that
> > must be discussed with people more familiar with the ugly binding
> > details than me.
> 
> Yes, I would like to discuss that.

Any other people on this list who like to comment here?

> > But I would not go so far to rely on automated
> > generated public APIs using JGIR.
> 
> You may not - but there are a lot of people who would.  Note both
> pygtk and Mono rely on public (after review) autogeneration - and
> there are *way* more pygtk and Mono apps shipped by vendors than
> java-gnome.

Mixing again: Coverage (not the fact if it was auto-generated) may be a
fact that explains that, but we don't know that for sure. It may well be
to other facts like Java programmers preferring Swing or SWT when
writing GUIs or cross plattform Mono applications being developed
because the app developer simply favored .NET instead of Java.

Stefan

Re: [java-gnome-hackers] a possible merge strategy

[Colin W. <wa...@ve...>]

On Wed, Oct 15, 2008 at 4:57 AM, Stefan Prelle <st...@pr...> wrote:
>
> What is different is our philosophy. We decided for a reason not to use
> the generated API as a public API, since often the usage of the
> generated APIs is not what a normal Java programmer usually would do.

I understand java-gnome's target audience is "Java programmer".  My
target audience is platform hackers and community developers who are
already familiar with the C API, who want a sane language and might be
willing to *learn* Java.  Personally I think java-gnome is in a tough
situation on this front because if what you need is "free
crossplatform GUI toolkit", SWT and Qt-Jambi have always been around,
and Swing is now Free.  On the other hand, SWT and Swing don't offer
GStreamer, WebKit, Clutter.

> So we have this handcrafted public API to smoothen the edges of
> underlying APIs and reduce the learning curve for developers coming from
> the Java world.

I understand the goal - note the tradeoff is this *increases* the
learning curve for people coming from the GNOME community who already
know the C APIs, because you're left guessing how things work.

> Personally I would like to keep the hand written API, because I see it
> as a big plus.

Sure, until you want to use WebKit, Clutter, or GStreamer.

> Another possibility would be to use JGIR to feed our code generator and
> replace our .def files. By that we would get a much better non-public
> binding to write the public binding for.

With a relatively small amount of work I could make the JGIR code
generator optionally output transformed class names, so instead of
org.gnome.gir.dynamic.Gtk.AboutDialog, it would output
org.gnome.gir.GtkAboutDialog.

> This might go together with improvements on our GObject code, but that
> must be discussed with people more familiar with the ugly binding
> details than me.

Yes, I would like to discuss that.

> JGIR is definetly an interesting aproach and it would be nice to have
> you onboard helping us with our code generation. You seem to have put a
> lot of effort on this, so it would be a shame if we could not both
> benefit from this. But I would not go so far to rely on automated
> generated public APIs using JGIR.

You may not - but there are a lot of people who would.  Note both
pygtk and Mono rely on public (after review) autogeneration - and
there are *way* more pygtk and Mono apps shipped by vendors than
java-gnome.

Re: [java-gnome-hackers] a possible merge strategy

[Stefan P. <st...@pr...>]

Hi Colin,

your approach of generating the API is definetly interesting. As you
might be aware we are also having autogenerated code in java-gnome (from
the .def-files), so although the way it is done is different a common
idea exists.

What is different is our philosophy. We decided for a reason not to use
the generated API as a public API, since often the usage of the
generated APIs is not what a normal Java programmer usually would do.
So we have this handcrafted public API to smoothen the edges of
underlying APIs and reduce the learning curve for developers coming from
the Java world.

A good example for that you gave yourself:
> TextIter iter = new TextIter();
> buf.getStartIter(iter);

A more Java-like approach would be
  TextIter iter = buf.getStartIter();

> Now,
> arguably this could be an <out> parameter, and getStartIter() could
> return it, but the current structure binding generalizes to multiple
> arguments well enough.  I might later do an optimization around this
> case, we'll see.

This is a question of philosophy. We prefer to make those optimizations 
before making an API public.

> The big picture here is that ideally, we can merge efforts and have
> the best of both worlds - an autogenerated complete API useful to
> platform hackers like me, and hand written custom bindings for tricky
> things like GtkTreeView on top, and share binding code for things like
> Cairo which aren't covered by introspection.

Personally I would like to keep the hand written API, because I see it
as a big plus. 

> But the first fundamental piece that would need to be merged is the
> GObject mapping layers.  In JGIR, GObject.java is actually written
> entirely in Java, using JNA.  You can see this code here:
> http://svn.gnome.org/svn/java-gobject-introspection/trunk/src/org/gnome/gir/gobject/GObject.java
> To merge this we'll have to figure out also how the Cairo library
> plugs in.  Should be relatively straightforward.

Another possibility would be to use JGIR to feed our code generator and
replace our .def files. By that we would get a much better non-public
binding to write the public binding for.
This might go together with improvements on our GObject code, but that
must be discussed with people more familiar with the ugly binding
details than me.

> And for the custom classes, it should be relatively straightforward to
> just rebase their internals on the JGIR if we can do the first part
> right.

JGIR is definetly an interesting aproach and it would be nice to have
you onboard helping us with our code generation. You seem to have put a
lot of effort on this, so it would be a shame if we could not both
benefit from this. But I would not go so far to rely on automated
generated public APIs using JGIR.

Regards,
  Stefan

[java-gnome-hackers] a possible merge strategy

[Colin W. <wa...@ve...>]

Hi,

The introspection project
(http://live.gnome.org/GObjectIntrospection/) is getting pretty far
along now, and I wanted to talk in particular about my prototype Java
bindings (http://live.gnome.org/JGIR).

These bindings, while they share in common the terms "GNOME" and
"Java", have radically different approaches and therefore tradeoffs.
JGIR in particular goes for *completeness*.  There are multiple
aspects to this - one is having a largely autogenerated *public* API.
Another aspect is using JNA (https://jna.dev.java.net/) which gives
access directly to C structures.  Here's an example:

TextView tv = new TextView();
TextBuffer buf = tv.getBuffer();

TextIter iter = new TextIter();
buf.getStartIter(iter);
iter.forwardChars(5);
buf.insert(iter, "hello world", -1);

Note that TextIter is actually a C structure - the getStartIter takes
it by reference and modifies it, just like how it works in C.  Now,
arguably this could be an <out> parameter, and getStartIter() could
return it, but the current structure binding generalizes to multiple
arguments well enough.  I might later do an optimization around this
case, we'll see.

Another aspect of this is having automatic, useful coverage of a wide
variety of libraries not covered by java-gnome, such as the Clutter
library (http://clutter-project.org/) which uses structures like
ClutterColor.   You can see more examples here:
http://live.gnome.org/JGIR/SampleCode

What are the downsides versus java-gnome?  The main ones are that
there's no javadoc on the autogenerated part of the API, and that
there are no Cairo bindings (because Cairo isn't a GObject library).

The big picture here is that ideally, we can merge efforts and have
the best of both worlds - an autogenerated complete API useful to
platform hackers like me, and hand written custom bindings for tricky
things like GtkTreeView on top, and share binding code for things like
Cairo which aren't covered by introspection.

But let's take things step by step.  At the very first, one thing we
can do is say that for GTK+ one can use java-gnome as is today if it
has coverage you need.  For other libraries like Clutter, GStreamer,
libnotify etc., one can use JGIR.  It *should* be possible to combine
GTK+-using java-gnome with JGIR in the same process.

But the first fundamental piece that would need to be merged is the
GObject mapping layers.  In JGIR, GObject.java is actually written
entirely in Java, using JNA.  You can see this code here:
http://svn.gnome.org/svn/java-gobject-introspection/trunk/src/org/gnome/gir/gobject/GObject.java
To merge this we'll have to figure out also how the Cairo library
plugs in.  Should be relatively straightforward.

After that, I see two types of classes in java-gnome:
* Very straightforward wrappers for the underlying API
(AboutDialog.java, HBox.java)
* Custom classes (DataColumn.java)

For the first category, I think what we should do is write a script
which compares the JGIR API to the java-gnome API, and for classes
which are likely merge candidates (i.e. they have *exactly* the same
API) extract the java-gnome javadoc and put it into a forthcoming JGIR
"overrides" mechanism.  My plan is to take a transformation of the C
gtk-doc for the default javadoc, but java-gnome's javadoc could
override that.  Somewhat harder is to merge in custom Java override
methods, we can talk about that when we get there.

And for the custom classes, it should be relatively straightforward to
just rebase their internals on the JGIR if we can do the first part
right.

[java-gnome-hackers] java-gnome 4.0.9 released

[Andrew C. <an...@op...>]

We've released version 4.0.9 of the java-gnome bindings of GTK and
GNOME!

Release notes
http://java-gnome.sourceforge.net/4.0/NEWS.html#4.0.9

Tarball
http://ftp.gnome.org/pub/gnome/sources/java-gnome/4.0/java-gnome-4.0.9.tar.bz2

People using java-gnome to develop applications would do well to
scrutinize the release notes... the real gem in this release is that you
no longer need to specify java.library.path when invoking a virtual
machine, which makes things soooo much easier.

AfC
Sydney

-- 
Andrew Frederick Cowie

Operational Dynamics is an operations and engineering consultancy
focusing on IT strategy, organizational architecture, systems
review, and effective procedures for change management. We actively
carry out research and development in these areas on behalf of our
clients, and enable successful use of open source in their mission
critical enterprises, worldwide.

http://www.operationaldynamics.com/

Sydney   New York   Toronto   London

[java-gnome-hackers] java-gnome 4.0.9-rc2 up

[Andrew C. <an...@op...>]

Thanks to Srichand, the double thing on EventButton is sorted.

Any last merge requests for 4.0.9? We'll put it out as soon as this
weekend if we don't hear from anyone else.

And, as always, contributions the website in general and the NEWS file
in particular are welcome.

AfC
Sydney

Re: [java-gnome-hackers] org.gnome.gdk.EventButton.getX()/getY(): double vs int

[Andrew C. <an...@op...>]

Informed participation, great!

On Wed, 2008-10-08 at 01:13 -0400, Srichand Pendyala wrote:

> There certainly are useful applications where doubles rather than ints
> would be useful...

The consensus is clearly to leave it as double. [Now that I think about
it, doubles line up with Cairo space, so hey.]

In any event, the bar to diverge from underlying API is high and clearly
not being met (anymore) in this case. So I don't object.

So which one of you who wants it double is going to fix it? :) Make sure
you add some casts to the example at TreeView's getPathAtPos() as well.
http://java-gnome.sourceforge.net/4.0/doc/api/org/gnome/gtk/TreeView.html#getPathAtPos(int,%20int)

AfC
Sydney