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

Re: [java-gnome-hackers] Bundle

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

On Thu, 2010-05-13 at 11:14 +0200, Sarah Leibbrand wrote:

> Nice to see you hacking, but send this next time to the hacking list,
> for now forwarded it to that mailing list :)

So, can one of you check the bundle you sent? It doesn't contain any
revisions.

(hint: it's really short)

(hint: try merging it yourself, and see what happens!)

Douglas,

did you `bzr commit` before you wrote the `bzr bundle` command? :)

AfC
Sydney

[java-gnome-hackers] Patch to GtkEditable and GtkEntry

[Douglaz <do...@gm...>]

Hello everyone!

   Last night I was trying to send the code I wrote for the GtkEditable and
GtkEntry classes, but I did not commit the changes, so I believe the patch I
sent was blank.

   I'm attaching a new patch file on this mail.

   Please let me know if this one is correct.

Best regards,
Douglas

[java-gnome-hackers] Fwd: [Java-gnome-developer] Bundle

[Sarah L. <xa...@gm...>]

Heya,

Nice to see you hacking, but send this next time to the hacking list, for
now forwarded it to that mailing list :)

Kind regards,

---------- Forwarded message ----------
From: Douglaz <do...@gm...>
Date: Thu, May 13, 2010 at 12:46 AM
Subject: [Java-gnome-developer] Bundle
To: jav...@li...


Hello everyone!

   I'm attaching on this mail a bundle, with a couple function I wrote, so
you could check them.
   I'm short, I did add on GtkEditable and wrote the code on GtkEditable the
following:
      getPosition()
      getSelectionBoundsStart()
      getSelectionBoundsEnd()


Best regards,
Douglas

------------------------------------------------------------------------------


_______________________________________________
java-gnome-developer mailing list
jav...@li...
https://lists.sourceforge.net/lists/listinfo/java-gnome-developer

[java-gnome-hackers] Rewrite of Code generator using GIR

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

Currently we're using defs file from pygobject which is generated by
h2def, and manually adding new symbols along the way. We also generate
or handcraft some defs files ourselves and add them into the tree. And
the code generator parses them to generate user invisible class files
and JNI code. This causes out-of-date symbol metadata since the work
is done manually.

For a bit of time GNOME project is prividing a package called Gobject
introspection, which basically holds interface definitions of GObject
based libraries. They're still generated from scanning source code,
but done by the library providers themselves and kept up-to-date.
GNOME also provides a central GIR metadata in "gir-repository" package
for libraries that don't provide them (eventually libraries end up
supporting GIR)

I started rewrite of parser part of the code generator using .gir XML
files (parsing them was easier otherwise we would need to write JNI
code for GIRepository). The branch is at
bzr://research.operationaldynamics.com/bzr/java-gnome/hackers/serkan/introspection/
Please pull and investigate it because this branch is changing a core
part of Java-Gnome

Future considerations
* How to handle manualy fixes we do for .defs files
* How to provide unexisting GIR files (we may use the scanner to
generate them and get them included in "gir-repository")

Regards,
Serkan KABA

Re: [java-gnome-hackers] java-gnome in Fedora

[Alexander B. <ab...@ro...>]

fre 2010-05-07 klockan 21:05 +0200 skrev Alexander Boström:

> Packages are here, behind the "builds" link:

Err, or you could just
yum install --enablerepo=updates-testing 'java-gnome*'

/Alexander

[java-gnome-hackers] java-gnome in Fedora

[Alexander B. <ab...@ro...>]

Hi,

I've finally submitted java-gnome for inclusion in Fedora, though I
needlessly allowed it to go through the karma system (which is optional
for new packages) so they're not quite there yet...

Packages are here, behind the "builds" link:

https://admin.fedoraproject.org/updates/java-gnome-4.0.15-3.fc12
https://admin.fedoraproject.org/updates/java-gnome-4.0.15-3.fc13

If you're using Fedora then please install it, compile and run some app
with it and give it some feedback!

Thanks,
/Alexander

Re: [java-gnome-hackers] GLib 2.22 required

[Kenneth P. <ken...@gm...>]

On Sun, 25 Apr 2010 15:02:22 +1000
Andrew Cowie <an...@op...> wrote:

> The branch we merged a while back with coverage of the various XDG
> utility functions in GLib bumps our dependency to glib-2.0 > 2.22
> 
> I've updated our top level configure to check for this explicitly;
> people packaging 4.0.15 for various distros might want to note this
> as a dependency for their packages of java-gnome.

I've updated Gentoo's java-gnome-4.0.15 package to depend on glib
>=2.22

[java-gnome-hackers] GLib 2.22 required

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

The branch we merged a while back with coverage of the various XDG
utility functions in GLib bumps our dependency to glib-2.0 > 2.22

I've updated our top level configure to check for this explicitly;
people packaging 4.0.15 for various distros might want to note this as a
dependency for their packages of java-gnome.

[This addresses a problem that someone on Slackware had trying to build
java-gnome; they'll need to get GLib 2.22 in order to build java-gnome
>= 4.0.15]

AfC
Sydney


-- 
Andrew Frederick Cowie | Consulting Engineer | Operational Dynamics
☏ +61 4 1079 6725 | ✍ +1 646 472 5054 | ♖ http://www.operationaldynamics.com

Re: [java-gnome-hackers] GNOME dependencies

[Guillaume M. <res...@gm...>]

> Serkan said he had some nightmare crashers from 2.20, but I'm hoping
> that those will be resolved before too long.
I will upgrade my Ubuntu to Lucid Lynx (which uses GTK+ 2.20) Thursday,
maybe Friday. So I'll see if I get that too.
 
> Should we make the next release of java-gnome be gtk >- 2.18 or gtk >=
> 2.20?
I'd like 2.20 but if it is not stable enough I guess we should stay with
2.18.

> And, while we're at it, any other minimum versions that need to bump?
We may need to check some deprecated things and then bump minimum
versions according to this.

-- 
Guillaume Mazoyer - http://www.respawner.fr/

[java-gnome-hackers] GNOME dependencies

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

A recent branch from Guillaume bumped our dependency to GTK 2.18

Of course, GTK 2.20 is now out.

Serkan said he had some nightmare crashers from 2.20, but I'm hoping
that those will be resolved before too long.

Should we make the next release of java-gnome be gtk >- 2.18 or gtk >=
2.20?

And, while we're at it, any other minimum versions that need to bump?

[in general, the "policy" we've followed is that java-gnome depends on
released GNOME in it's entirety, with the caveat that we've tried to
wait for things to actually be out in the wild, ie packaged in a current
release of Gentoo, Ubuntu and Fedora].

AfC
Melbourne

Re: [java-gnome-hackers] Update to GTK+ 2.18

[Guillaume M. <res...@gm...>]

> Looks ok to me. If we find bugs later, we can fix 'em. :)
Sure :)

> I renamed the example to make it like the other examples.
> bzr://research.operationaldynamics.com/bzr/java-gnome/hackers/andrew/gtk-2.18/
Merged.

> One thing we could do is get a screenshot of an InfoBar, so that people
> would know what they are. If you were to create another Snapshot
> subclass in tests/screenshots/ and reference the resultant image from
> the InfoBar javadoc, that would be really cool. SnapshotButton would be
> an example.
That is what I did. The snapshot shows an InfoBar like a IM client will
do. I guess that can be a realistic "example".

-- 
Guillaume Mazoyer - http://www.respawner.fr/

Re: [java-gnome-hackers] Update to GTK+ 2.18

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

On Fri, 2010-04-09 at 01:40 +0200, Guillaume Mazoyer wrote:
> that is why I am not sure that
> I did not forget anything too.

Looks ok to me. If we find bugs later, we can fix 'em. :)

> The only thing that I am sure about is
> the InfoBar which works.

Yup.

I renamed the example to make it like the other examples.
bzr://research.operationaldynamics.com/bzr/java-gnome/hackers/andrew/gtk-2.18/

When possible, I've tried to encourage people to come up with examples
that are "realistic" and not "trivial". I'm not sure what to suggest in
this case, though.

One thing we could do is get a screenshot of an InfoBar, so that people
would know what they are. If you were to create another Snapshot
subclass in tests/screenshots/ and reference the resultant image from
the InfoBar javadoc, that would be really cool. SnapshotButton would be
an example.

AfC
Sydney

Re: [java-gnome-hackers] Update to GTK+ 2.18

[Guillaume M. <res...@gm...>]

> More recently people have just been appending in the
> pieces they're interested in. Either way is fine.
Well, that is what I did. And, actually, that is why I am not sure that
I did not forget anything too. The only thing that I am sure about is
the InfoBar which works.

-- 
Guillaume Mazoyer - http://www.respawner.fr/

Re: [java-gnome-hackers] Update to GTK+ 2.18

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

On Mon, 2010-04-05 at 18:49 +0200, Guillaume Mazoyer wrote:
> The branch can be found at 'hackers/guillaume/gtk-2.18'.

I just grabbed it; I'll have a look later today.

> (I'm not used to update .defs files, I may
> have forgot something[s])

It's rather voodoo.

Once upon a time we'd go back to the pygtk branch (see `bzr tags`),
import new files from upstream, and re-run the Makefile in
src/util/demux/. More recently people have just been appending in the
pieces they're interested in. Either way is fine.

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: enabling
successful deployment of mission critical information technology in
enterprises, worldwide.

http://www.operationaldynamics.com/

Sydney   New York   Toronto   London

[java-gnome-hackers] Update to GTK+ 2.18

[Guillaume M. <res...@gm...>]

Hi,

Many of you have probably seen that GNOME 2.30 is out. With this new
release, comes a new version of GTK+ which is GTK+ 2.20.

Before adding coverage for GTK+ 2.20, I tried to update the .defs files
to be able to use some new things from GTK+ 2.18. I used the .defs files
from pygtk to update ours.

I also added coverage for the GtkInfoBar widget (which is new in GTK+
2.18) and made an example so show how it works.

The branch can be found at 'hackers/guillaume/gtk-2.18'. Let me know if
something can be improved (I'm not used to update .defs files, I may
have forgot something[s]).

Cheers,

-- 
Guillaume Mazoyer - http://www.respawner.fr/

Re: [java-gnome-hackers] "First block in defs file didn't describe a type"

[Alexander B. <ab...@ro...>]

ons 2010-03-31 klockan 09:33 +1100 skrev Andrew Cowie:

> Sure, this is the right place if you're hacking on the library, and I'd
> say that messing around with the code generator is hacking on the
> library :)

> oooh running the code generator by hand. :) That's rare, unless you're
> working on the code generator itself. But yes:

Nah, I'm afraid I'm just compiling it (with V=1).

> >         Couldn't get sufficient information from src/defs/GtkRcScanner.defs:
> >         First block in defs file didn't describe a type
> >         [continuing next file]
> 
> etc
> 
> is entirely normal.

Ok.

> The goal would be to fix
> the .defs data (easy) and/or the code generator (hard) to the point
> where nothing generates such warnings. 
> 
> [it's hard because often the things that we don't handle require
> significant design and engineering work; the case of function pointers
> being a one example that we happily just avoided]

I see! Thanks for the explanation.

/Alexander

Re: [java-gnome-hackers] glib g_format_size_for_display()

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

On Wed, 2010-03-31 at 01:50 +0200, Guillaume Mazoyer wrote:

> Added, commited and pushed :)

Great!

It'll need some testing, of course. I'd suggest the
ValidateUtilityFunctions test case class would be a good place to add a
fixture or two...

AfC
Melbourne

Re: [java-gnome-hackers] glib g_format_size_for_display()

[Guillaume M. <res...@gm...>]

>  (define-function format_size_for_display
>    (of-object "GlibMisc")
>    (c-name "g_format_size_for_display")
> +  (caller-owns-return #t)
>    (return-type "char*")
>    (parameters
>      '("goffset" "size")
>    )
>  )
Added, commited and pushed :)

Thank you for the fix.

-- 
Guillaume Mazoyer - http://www.respawner.fr/

Re: [java-gnome-hackers] glib g_format_size_for_display()

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

On Tue, 2010-03-30 at 21:06 +0200, Guillaume Mazoyer wrote:
> Can anyone let me know if everything is right? (that's my first codegen
> hack).

Yes everything looks fine. :)

I'm wondering if you need to add

 (define-function format_size_for_display
   (of-object "GlibMisc")
   (c-name "g_format_size_for_display")
+  (caller-owns-return #t)
   (return-type "char*")
   (parameters
     '("goffset" "size")
   )
 )

... yes you do.

See FunctionBlock's getCallerOwnsReturn() for the default and
StringThing's jniReturnCleanup() for the code that's output.

AfC
Melbourne

Re: [java-gnome-hackers] "First block in defs file didn't describe a type"

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

On Tue, 2010-03-30 at 22:48 +0200, Alexander Boström wrote:
> Not sure if this should go to -developers, but anyway, my question:

Sure, this is the right place if you're hacking on the library, and I'd
say that messing around with the code generator is hacking on the
library :)

> What should I make of the following, when compiling java-gnome? Is it
> normal?
> 
>         /usr/bin/java -client -ea -Djava.awt.headless=true -classpath tmp/generator/ BindingsGenerator

oooh running the code generator by hand. :) That's rare, unless you're
working on the code generator itself. But yes:

>         Couldn't get sufficient information from src/defs/GtkRcScanner.defs:
>         First block in defs file didn't describe a type
>         [continuing next file]

etc

is entirely normal. You'll get the same output if you run

$ rm tmp/stamp/generator
$ V=1 make

for obvious reasons in the normal build we discard those warnings.

> It looks bad but the resulting library seems to work.

It's all the places where the input data wasn't correctly formed by the
narrow definition of what the code generator can parse and/or expects.

When we were writing the thing it was a case of teaching it to handle
more and more of the input set, so you can imagine why it is the way it
is. Ideally we don't want it to warn at all. The goal would be to fix
the .defs data (easy) and/or the code generator (hard) to the point
where nothing generates such warnings. 

[it's hard because often the things that we don't handle require
significant design and engineering work; the case of function pointers
being a one example that we happily just avoided]

AfC
Melbourne

-- 
Andrew Frederick Cowie | Consulting Engineer | Operational Dynamics
☏ +61 4 1079 6725 | ✍ +1 646 472 5054 | ♖ http://www.operationaldynamics.com

[java-gnome-hackers] "First block in defs file didn't describe a type"

[Alexander B. <ab...@ro...>]

Hello,

Not sure if this should go to -developers, but anyway, my question:

What should I make of the following, when compiling java-gnome? Is it
normal?

        /usr/bin/java -client -ea -Djava.awt.headless=true -classpath tmp/generator/ BindingsGenerator
        
        Couldn't get sufficient information from src/defs/GtkRcScanner.defs:
        First block in defs file didn't describe a type
        [continuing next file]
        
        Couldn't get sufficient information from src/defs/GdkStatus.defs:
        No data was parsed in this defs file
        [continuing next file]

        (...and so on)

It looks bad but the resulting library seems to work.

Thanks,
Alexander

[java-gnome-hackers] glib g_format_size_for_display()

[Guillaume M. <res...@gm...>]

Hello,

I did a quick hack to be able to use the g_format_size_for_display()
function from Glib.

The C function needs a goffset parameter so I had to add a new
FundamentalThing to the code generator.

goffset is a guint64 so here is how I add it: goffset => Native long
type => JNI jlong type => Java long type.

The branch can be found at:
bzr/java-gnome/hackers/guillaume/glib_format_size/

Can anyone let me know if everything is right? (that's my first codegen
hack).

Cheers,

-- 
Guillaume Mazoyer - http://www.respawner.fr/

[java-gnome-hackers] New application using Java-Gnome

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

As some of you (at least Andrew) know I started developing an 
application (actually it's a rewrite of an old one) to query inklevels 
of various printers supported by libinklevel 
(http://libinklevel.sf.net). It has finally reached a maturity for an 
initial 0.1 release along with the jni libraries supporting it. The 
project page is @ Googlecode (http://mso.googlecode.com) while source 
code and issue tracker is at Launchpad.

I'll try to add some screenshots, documentation , a Gentoo ebuild etc. 
in the weekend.

I'll be glad to hear feedback from anybody reading this post and willing 
to test it.
-- 
Sincerely,
Serkan KABA

[java-gnome-hackers] java-gnome 4.0.15 released

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

hack, hack, hack, drink heavily, hack, hack, RELEASE, drink heavily,
hack, hack...

The 'mainline' branch now identifies itself as 4.0.16-dev.

Cheers,

AfC
Sydney

Re: [java-gnome-hackers] Enchant RuntimeException

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

On Wed, 2010-03-10 at 21:31 +0200, Serkan Kaba wrote:
> > Our doc says "Returns null if no suitable dictionary was found."
> > so presumably we should do that.
> Following this path then. Attaching the bundle

Ok. I added a unit test, and merged to 'mainline',

AfC
Sydney