gmane.comp.gnome.bindings.java.devel

GtkLicense coverage

Guillaume Mazoyer — 2012-02-06T00:05:12

Hello,

Here is a quickly made branch that add the coverage of GtkLicense.
The covered constants are used to specify the license of an
application with the related GtkAboutDialog method.

The branch covers the GtkLicense constants and the related
GtkAboutDialog methods.
It can be found at: hackers/guillaume/gtk-license/

Cheers,

Arrays in signal handlers

Andrew Cowie — 2012-02-02T05:19:15

Guillaume has hit an interesting engineering problem.

There is a signal which returns an array of GFile. That doesn't seem
like a problem, except that on the C side of the signal marshaling code
we don't have anything to handle arrays.

The situation is complicated by the fact that the actual signature in
the signal is "gpointer files". Last I checked that was a typedef for
void*, but that doesn't help us because we need to detect it and turn it
into an [] of org.gnome.glib.File.

We can't even special case it, because all we have to work from in the
signal marshaling code is the GType and it is G_TYPE_POINTER.

So I'm at a bit of a loss. The primary engineering question is "how do
we get arrays as arguments in signals. The secondary problem is "how can
we figure out what to do when all we have is G_TYPE_POINTER as a type."

My best guess is to write a custom handler C side that takes the
gpointer and turns it into a GList* of GFile. But we would still need
code to handle that in the signal marshaller.

Guillaume could give more detail, I'm sure.

AfC
Sydney

------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d_______________________________________________
java-gnome-hackers mailing list
java-gnome-hackers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f< at >public.gmane.org
https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers

Style schemes for GtkSourceview

cyber python — 2012-02-01T14:26:49

Hello,

I have just added coverage for style scheme use in GtkSourceView.

In the attachment, you will find the associated patch.

Best regards,
Georgios Migdos.
------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d_______________________________________________
java-gnome-hackers mailing list
java-gnome-hackers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f< at >public.gmane.org
https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers

Text in progress bars

Guillaume Mazoyer — 2011-12-18T21:18:32

Hello,

Since GTK+ 3, a new method has been added to the GtkProgressBar class to
tell if a progress bar should display text or not. So I added the
coverage for these methods.

In attachment, you will find the patch.

Regards,

--
Guillaume Mazoyer
------------------------------------------------------------------------------
Learn Windows Azure Live!  Tuesday, Dec 13, 2011
Microsoft is holding a special Learn Windows Azure training event for 
developers. It will provide a great way to learn Windows Azure and what it 
provides. You can attend the event by watching it streamed LIVE online.  
Learn more at http://p.sf.net/sfu/ms-windowsazure_______________________________________________
java-gnome-hackers mailing list
java-gnome-hackers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f< at >public.gmane.org
https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers

boxedFor() name clash - compiling java-gnome4.1.1 with OpenJDK 1.7

Alexander Boström — 2011-12-06T21:16:40

Hello,

Rebuilding java-gnome 4.1.1 with javac 1.7.0_b147 (on what will become
Fedora 17) fails with this error:

src/bindings/org/gnome/gdk/Plumbing.java:69: error: name clash:
 boxedFor(Class<? extends Boxed>,long) in org.gnome.gdk.Plumbing and
 boxedFor(Class<?>,long) in org.gnome.glib.Plumbing have the same erasure,
 yet neither hides the other
    protected static Boxed boxedFor(Class<? extends Boxed> type, long pointer) {
                           ^

Adding "extends Boxed" to glib.Plumbing.boxedFor() makes it break
elsewhere, but if I instead remove it from gdk it does compile. Is that
the right fix?

/Alexander



------------------------------------------------------------------------------
Cloud Services Checklist: Pricing and Packaging Optimization
This white paper is intended to serve as a reference, checklist and point of 
discussion for anyone considering optimizing the pricing and packaging model 
of a cloud services business. Read Now!
http://www.accelacomm.com/jaw/sfnl/114/51491232/

GApplication and GtkApplication coverage

Guillaume Mazoyer — 2011-12-05T23:08:13

Hi,

I'm currently working on the coverage of GApplication and GtkApplication
to fix one of the bug[1] in our Bugzilla.

You can find my work on a branch at
'hackers/guillaume/gtk-application/'.

Sadly, I'm hiting some problems:
  * Dbus error,
  * Command line handler,
  * Opened files handler.

Basically, it works (for now) only if we use the "NONE" ApplicationFlags
and if no arguments are passed when starting the application.

Moreover, everybody knows that in our lovely crafted bindings, we should
always call Gtk.init() first except for some rare cases (you know that
right?). But GtkApplication is supposed (and is calling it [the C
function]) automatically. Is it cool? I don't know, but it is a problem
for us because we cannot allow that. We must explictly call Gtk.init()
ourselves.

If anyone wants to give me a hand (by making some code, giving me more
details about how G[tk]Application works, etc..) I will thank you :)

And to finish this email, here is a quote from the IRC channels for
people who don't stay always on IRC or who are not using it (you
should!).

07:24 < AfC> Respawner: do you want me to hold off releasing 4.1.2?
07:24 < AfC> If you can figure it out it would give us a good feature to
include
07:26 < Respawner> AfC: hum I don't know it might take some time to me
to figure out the issues, and the issues make the application crash so...
07:27 < AfC> Respawner: Well, we can try and figure them out
07:27 < AfC> Respawner: there have been some threads & bugs about
GtkApplication lately, so perhaps that would help
07:27 < Respawner> AfC: hackers/guillaume/gtk-application/
07:28 < Respawner> AfC: some issues are commented in the code ;)
07:30 < Respawner> and there is a bug which appears when launching the
app with args like "java .... GtkApp blabla blibli blublu"
07:30 < Respawner> it says "this app cannot open files" then when you
start using the capp (eg clicking on a button) it crashes
07:31 < Respawner> I understand that I have to handle the "command-line"
and "open" signals from that error
07:33 < Respawner> the "command-line" signal is probably not a hard to
fix, but the "open" signal is a little more complex since it uses a
GFile array
07:34 < Respawner> but maybe we can use a String array containing the
path to each file instead?
07:35 < Respawner> I don't think that we need to cover GFile, the Java
API is capable enough to handle files :D

btw: It looks like some guys wants that we integrate the G[tk]Application
class before the GNOME 3.4 release.

[1] https://bugzilla.gnome.org/show_bug.cgi?id=658400

--
Guillaume Mazoyer
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d_______________________________________________
java-gnome-hackers mailing list
java-gnome-hackers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f< at >public.gmane.org
https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers

Invitation to connect on LinkedIn

Mike Emmel — 2011-11-03T08:25:09

I'd like to add you to my professional network on LinkedIn.

- Mike

Mike  Emmel
Engineer at Motorola
Orange County, California Area

Confirm that you know Mike  Emmel:
https://www.linkedin.com/e/wqyghb-gujhpscq-3o/isd/4785838612/9ps92y0H/?hs=false&tok=3iSXlFJbOpNkY1

--
You are receiving Invitation to Connect emails. Click to unsubscribe:
http://www.linkedin.com/e/wqyghb-gujhpscq-3o/GCrU14kl-iPNZXyYG222J4r9F1jDywjYA2CCEphBzBMDGPKy3VvC2Nfa8-r/goo/java-gnome-hackers%40lists%2Esourceforge%2Enet/20061/I1664122401_1/?hs=false&tok=37-50oJTCpNkY1

(c) 2011 LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, USA.
------------------------------------------------------------------------------
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1_______________________________________________
java-gnome-hackers mailing list
java-gnome-hackers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f< at >public.gmane.org
https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers

Invitation to connect on LinkedIn

Mike Emmel — 2011-11-03T08:24:42

I'd like to add you to my professional network on LinkedIn.

- Mike

Mike  Emmel
Engineer at Motorola
Orange County, California Area

Confirm that you know Mike  Emmel:
https://www.linkedin.com/e/wqyghb-gujhp77u-4i/isd/4785838612/9ps92y0H/?hs=false&tok=1YyYGeoiyoNkY1

--
You are receiving Invitation to Connect emails. Click to unsubscribe:
http://www.linkedin.com/e/wqyghb-gujhp77u-4i/GCrU14kl-iPNZXyYG222J4r9F1jDywjYA2CCEphBzBMDGPKy3VvC2Nfa8-r/goo/java-gnome-hackers%40lists%2Esourceforge%2Enet/20061/I1664120712_1/?hs=false&tok=1JufbpJ9moNkY1

(c) 2011 LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, USA.
------------------------------------------------------------------------------
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1_______________________________________________
java-gnome-hackers mailing list
java-gnome-hackers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f< at >public.gmane.org
https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers

Coverage of GtkStyleContext

Guillaume Mazoyer — 2011-10-26T00:12:18

Hi,

As said on IRC, I have a branch covering GtkStyleContext and some
related constants and flags I'd like to see merged for the next release
of the bindings. The branch can be found at:

    hackers/guillaume/gtk-style-context/

There is a certain amount of C code to review due to the use of some
functions that return GList* etc...

Any feedbacks are welcome.

Cheers,

--
Guillaume Mazoyer
------------------------------------------------------------------------------
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning< at >Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev_______________________________________________
java-gnome-hackers mailing list
java-gnome-hackers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f< at >public.gmane.org
https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers

Coverage of GtkSwitch

Guillaume Mazoyer — 2011-10-24T23:38:53

Hi,

Here is I propose another branch that I'd like to see merged for the
next java-gnome release. The branch is located at:

    hackers/guillaume/gtk-switch

From the branch location you probably understand that it covers the
GtkSwitch widget that was introduce with GTK+ 3. That's a pretty simple
branch, I just had to play with some C functions to be able to emit and
catch a signal when the user plays with the Switch.

Any feedbacks are welcome (as usual).

Cheers,

--
Guillaume Mazoyer
------------------------------------------------------------------------------
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning< at >Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev_______________________________________________
java-gnome-hackers mailing list
java-gnome-hackers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f< at >public.gmane.org
https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers

Check return vales

Andrew Cowie — 2011-10-24T01:42:14

When you're working in C, please check the return value of every JNI
function,


+_array = (*env)->NewObjectArray(env, size, stringCls, NULL);
+
+if ((*env)->ExceptionCheck(env)) {
+(*env)->ExceptionDescribe(env);
+g_printerr("Unable to create array?");
+}


and meanwhile, if there's an exception pending, just return from the
function; Java will do the right thing once control returns to the JVM.

AfC
Sydney


------------------------------------------------------------------------------
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning< at >Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev

Release needed?

Andrew Cowie — 2011-08-31T12:17:08

Anyone have anything they want merged before we do 4.1.2?

I know quite a few of the people who contribute to java-gnome are unable
to use it right now until they get a release of their distro with GTK 3
on their systems so they can build, but if anyone wants something in,
please let me know or send to list...

Vreixo, this means you :)

AfC
Tokyo

------------------------------------------------------------------------------
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better 
price-free! And you'll get a free "Love Thy Logs" t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev_______________________________________________
java-gnome-hackers mailing list
java-gnome-hackers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f< at >public.gmane.org
https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers

java-gnome 4.1.1 released

Andrew Cowie — 2011-07-18T22:39:00

I hope you heard that 4.1 has had its first release!

++

The 'mainline' branch now identifies itself as version 4.1.2-dev.

If you need the 4.0 series, I've explicitly put a 'release-4.0' branch
up on the server so it's there if someone needs it. You could of course
branch from tag:v4.0.20 too, though obviously any future work on the 4.0
series won't be in 'mainline'.

Cheers,

AfC
Sydney



------------------------------------------------------------------------------
Storage Efficiency Calculator
This modeling tool is based on patent-pending intellectual property that
has been used successfully in hundreds of IBM storage optimization engage-
ments, worldwide.  Store less, Store more with what you own, Move data to 
the right place. Try It Now! http://www.accelacomm.com/jaw/sfnl/114/51427378/_______________________________________________
java-gnome-hackers mailing list
java-gnome-hackers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f< at >public.gmane.org
https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers

GtkBuilder branch

Vreixo Formoso Lopes — 2011-06-18T13:58:12

Hi all!

I have created a branch with my approach to expose GtkBuilder, available at:

http://research.operationaldynamics.com/bzr/java-gnome/hackers/vreixo/gtkbuilder/



I plan to expose GtkBuilder as an annotation-based way of creating user 
interfaces, following the approach of Francho Bulgarelli to libglade, submitted 
several  years ago. In fact, my work is mainly an adaptation of Franco's 
implementation, although I also plan to make some changes. I don't want
to follow with my discussion without first thank Franco for his huge 
contribution.

The work in my branch is still in a preliminary stage, but you can already 
figure 

out the idea by looking at my code. Please download the branch and focus on

org.gnome.gtk.Builder

I have added a tiny demo application in doc/examples/builder, NotesDemo.java, 
that shows the possibilities of an annotation-based approach. Further work will 
address the signal connection by means of annotation, and many other things.

I'm aware of the problems of GtkBuilder and similar approaches (that build user
interfaces with an external program and then load them from an XML file),
mainly related with the lack of type-safety (and note, however, that the
annotation-based approach reduces its impact by detecting the possible 
problems at load time, without needing to execute all possible code paths).

Anyway, this method for creating UI is very common in the java world (they
come to my mind web-related frameworks such as JSP/JSTL, Tapestry,
GWT's UiBinder, or the mobile Android platform with his layouts). Many
java developers use to work this way and, indeed, it has several advantages
too. 

I thus think we should offer support for this way of working in java-gnome, and
the annotation-based approach is, in my opinion, the best one.
I hope you take a look at the code and tell me your opinions about it, and any
idea that could improve it. I'll try to provide a good implementation of
GtkBuilder, making it easy for developers by means of the powerful capabilities 
of the Java platform. But, at the same time, I'll try to reduce as much as 
possible the limitations of the approach. 

If any of you have experience with GtkBuilder (I have not), please tell me what
are the things you want support for in java-gnome, but also the main problems
you've found when working with it, so we can address them the best possible
way.

Thanks in advance,

Best regards
Vreixo Formoso

------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev

Patch for Cairo Filter constants andPattern.setFilter(Filter)

William Temperley — 2011-06-17T11:52:08

Hi -

I've attached a patch which adds The Pattern.setFilter(Filter) method
to the Cairo bindings, plus the requisite Filter constants.
I hope this will be good enough for inclusion. Please let me know if
there are any problems.

This patch makes it possible to specify the interpolation method used
when rendering embedded images in PDFs. This fixes the particular
issue I was having with low resolution PNGs being interpolated and
blurred.
see:
http://cairographics.org/manual/cairo-cairo-pattern-t.html#cairo-pattern-set-filter

Thanks to Andrew Cowie and Adrian Johnson for pointers here.

Best regards,

Will Temperley
------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev_______________________________________________
java-gnome-hackers mailing list
java-gnome-hackers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f< at >public.gmane.org
https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers

App Indicator

Philipp Heckel — 2011-05-31T16:41:27

Hello everyone,

I apologize if this has been asked before, but I was wondering if
java-gnome or any other library you know will support application
indicators in future versions?

I read a thread from the archive [1] in which Francisco and Guillaume
talked about this, but more or less came to the conclusion that this
functionality should be exported to a separate binding. I was
wondering if there has been any progress on this issue.

Francisco's patch still works very well. It could be added to
java-gnome or a separate package. If you don't like to have it in
java-gnome, why not create something like "libappindicator-java"?

Cheers,
Philipp

[1] https://sourceforge.net/mailarchive/message.php?msg_id=25397649

------------------------------------------------------------------------------
Simplify data backup and recovery for your virtual environment with vRanger. 
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today. 
http://p.sf.net/sfu/quest-sfdev2dev

Tests on the 4.1 branch

Andrew Cowie — 2011-05-08T04:24:34

I have a system that is now Ubuntu Natty (and therefore GTK 3 available)
+ GNOME 3 (from gnome 3 developers' PPA), and so I'm now able to finish
getting our 4.1 release ready.

Our test suite has two problems:

1. libnotify

Our test connects to Nautilus. This made the assumption that Nautilus is
always running, which it was on a GNOME 2 system since it draws the
Desktop. But for some time now the Ubuntu Netbook Edition users have
complained that they only have Nautilus running on-demand when they pull
up a file browser. And since Canonical's Netbook code became Unity, I
can only expect this to get worse. 

Meanwhile, it would seem based on my few days experience that GNOME 3
behaves the same way; Nautilus only available on demand.

So I'm going to have to deactivate

        ValidateUniqueApplications.testIsNautilusRunning()
        ValidateUniqueApplications.testSendToNautilus() 

2. Compose sequences

The test

        ValidateInputMethods.testNormalKeystrokes()

is failing.

This pisses me off; it works fine in GTK 2; and meanwhile, actual live
Compose key handling works fine in my large text editing application. So
it's not the java-gnome binding at fault, but rather something about our
test case and/or Xvfb that's not working.

So I'll have to deactivate this one too.

++

I'm sure most of you don't care about any of this; but removing tests to
make the test suite pass is not a very good approach to problem solving.

The methods have been renamed s/test/fails/ so that the test code is
still there but not run.

I hope that someday someone will try and make these tests work again.

AfC
Sydney

------------------------------------------------------------------------------
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network 
management toolset available today.  Delivers lowest initial 
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd_______________________________________________
java-gnome-hackers mailing list
java-gnome-hackers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f< at >public.gmane.org
https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers

Libraries vs Packaging (1): Linkage

Andrew Cowie — 2011-05-01T02:41:14

Something I have been musing about for a while is how we could implement
optional dependencies into java-gnome.

Right now you put gtk-4.0.jar on your classpath, and you're done. That's
a Good Thing™

That .jar magically loads libgtkjni-4.0.20-dev.so [the name does not
matter] which is linked against ... everything. :(

The big case that pushes this is WebKit. We'd like to include coverage
of WebKitGtk soon. But either you have it on your distro and can easily
build against it, or you don't, and it becomes a blocker against you're
being able to build java-gnome from source.

Another example is GtkSpell; at the moment I don't use it, and so seeing
it in the output of ldd tmp/libgtkjni-4.0.20-dev.so is a bit of a
surprise

Because Java only loads classes when required, it doesn't cost
developers anything to have a single .jar to include in their classpath,
and indeed that is MUCH better than having to include 14 .jar files in
some complex stack of dependencies that no one cares about.

The libraries, on the other hand, bother me a bit.

I've been wondering if we should have

tmp/libglibjni-4.0.20-dev.so
tmp/libgtkjni-4.0.20-dev.so
tmp/libgnomejni-4.0.20-dev.so
tmp/libwebkitjni-4.0.20-dev.so

etc that would be loaded by System.load() calls in the individual
package Plumbing classes.

The usual wisdom is that more shared libraries are bad. If that is true,
then our single .so is a good thing. On the other hand, if tighter
linkage in many .sos would perhaps reduce our virtual memory demand? Our
footprint appears huge in top(1), gnome-system-properties etc and while
I know those are not much of a measurement tool, I am conscious that
over time memory pressure adds up and I'd like to make sure we're doing
the right thing.

AfC
Phuket



------------------------------------------------------------------------------
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network 
management toolset available today.  Delivers lowest initial 
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
_______________________________________________
java-gnome-hackers mailing list
java-gnome-hackers< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers

Test failures on 4.1

Andrew Cowie — 2011-04-12T14:04:48

I've just finished porting the unit test suite and friends in tests/ to
here to use Widget.Draw and other new APIs.

ValidateProperties is failing, however; it looks like the clamping
behaviour has changed. Could someone have a try building and see a) if
they duplicate it, and b) if you can figure out what might be wrong?

Appreciate any help.

The '4.1' branch is at
http://research.operationaldynamics.com/bzr/java-gnome/4.1/

AfC
Sydney

------------------------------------------------------------------------------
Forrester Wave Report - Recovery time is now measured in hours and minutes
not days. Key insights are discussed in the 2010 Forrester Wave Report as
part of an in-depth evaluation of disaster recovery service providers.
Forrester found the best-in-class provider in terms of services and vision.
Read this report now!  http://p.sf.net/sfu/ibm-webcastpromo_______________________________________________
java-gnome-hackers mailing list
java-gnome-hackers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f< at >public.gmane.org
https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers

Backporting

Andrew Cowie — 2011-04-12T03:08:16

Over the past few days I have (for lack of a better word) backported a
number of APIs from java-gnome 4.1 to java-gnome 4.0

These are just simulations, but so far so good - where GTK 3 has hung us
out to dry I've been able to wrap the old GTK 2 calls in things that
look suspiciously like what the GTK 3 APIs.

Currently 'mainline' has, as 4.0.20-dev,

        Widget.Draw signal wraps Widget.ExposeEvent
        void overrideFont() wraps modifyFont()
        void overrideColor() wraps modifyText(), etc
        ComboBoxText wraps our TextComboBox
        StateFlags wraps StateType
        RGBA wraps Color

I have no idea if we can keep this up, but I'm trying. With any luck,
I'm hoping to reach the point where code that compiles against 4.0.20
can be recompiled against 4.1.1, which would make porting/upgrading a
hell of a lot easier.

There's no behaviour consistency guarantee, of course -
Widget.ExposeEvent and Widget.Draw are not the same thing. And since my
code worked with ExposeEvent before, of course it works with "Draw" now.
We'll see what happens when we all finally get desktops with a GTK 3
packages on them.

Simultaneously I've been merging the 4.0 'mainline' into the 4.1.1-dev
branch and reverting all the adaptor cruft that I'm introducing in
4.0.20-dev.

AfC
Sydney

------------------------------------------------------------------------------
Forrester Wave Report - Recovery time is now measured in hours and minutes
not days. Key insights are discussed in the 2010 Forrester Wave Report as
part of an in-depth evaluation of disaster recovery service providers.
Forrester found the best-in-class provider in terms of services and vision.
Read this report now!  http://p.sf.net/sfu/ibm-webcastpromo_______________________________________________
java-gnome-hackers mailing list
java-gnome-hackers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f< at >public.gmane.org
https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers

Symol issues with GtkBuilder

Andrew Cowie — 2011-04-08T03:46:35

I had a shot at implementing GtkBuilder support in java-gnome. The
public API was easy and was done in a flash. But it doesn't work.

Exception in thread "main" java.text.ParseException: Invalid object type `GtkLabel'
at org.gnome.gtk.Builder.addFromFile(Builder.java:107)
at Designer.setupUserInterface(Designer.java:46)
at Designer.main(Designer.java:80)

Invalid object type? huh?

++

I have copied in the logs of a long conversation I had on #gtk+ today
with Tristan van Berkom, Benjamin Otte, and Johan Dahlin. I'd ask you to
read through it. The end  result appears to be that because java-gnome
reaches GTK via a shared library and not by virtue of being an
executable itself, GtkBuilder won't work as is.

There are two options:
        
        1) implement a vFunc (by C side subclassing GtkBuilder, I think)
        to do ... something
        
        2) manually call dlopen() with RTLD_GLOBAL which does ...
        something

The fact that I was able to hack (2) to work is not interesting. What's
the cost of it? I assume switching it to global would mean an insane
growth in the runtime size of the symbol table. Is that bad? I assume
so. How do we measure it? No idea.

Also, if we did (2) then we'd have to manually list every system library
name in C code. That's fragile, to say the least.

On the other hand, it's not like our symbol table isn't huge already
care of JNIEXPORT [which is the reason to investigate JNI's
RegisterNatives, but that's another story]. But this wouldn't read-only
sharable data space in a .so, right? We want to shrink our memory
footprint, not grow it!

Johan said that the vFunc was just for this sort of occasion. Ok, so
presumably (1) is the better thing to do, but can anyone figure out from
this conversation what, exactly, we're supposed to do there?

My branch is at 'hackers/andrew/builder'. It's a 4.0 branch. With the
patch below it "works", but we can't use that patch as is.

Slightly edited IRC log follows. As you'll read, on quite a number of
occasions I point out that I really don't know enough about linking to
be able to properly assess what is (or isn't) going on. 

Thanks to Tristan, Benjamin, and Johan for their help getting us this
far! Now, my friendly little java-gnome hackers, I need yours...

AfC
Sydney


++

AfC: Hm. I wonder why GtkBuilder would emit "Invalid object type
`GtkLabel'" when parsing a .ui file?

Company: AfC: not yet called gtk_init() or so?
Company: AfC: the gtk_label_get_type() function must have been called
once for the type to be registered

AfC: Company: no, gtk_init() etc called already
AfC: Company: er
AfC: what?
AfC: you're kidding.

Company: no, i'm not
Company: but i'm pretty sure there is some function that does that

AfC: You mean someone has to manually call gtk_label_new() and
gtk_foobar_new() and gtk_everything_else_new() before they can use
GtkBuilder?

Company: AfC: no

tristan: AfC, you you doing this in C ?

Company: AfC: i mean someone has to call gtk_label_get_type()

tristan: AfC, there is a function that creates "gtk_label_get_type" from
"GtkLabel"

AfC: tristan: no, I'm finally getting around to porting our libglade
coverage in java-gnome to GtkBuilder instead. It was easy enough, except
that I've hit this

tristan: it's used along with g_module_symbol() to initialize types

Company: ahhh
Company: more magical than i'd have thought

tristan: AfC, I suspect... not sure... but suspect that the binding has
problems getting the type from name

AfC: bloody hell. Do you have any idea how much we have *not* exposed
the _get_type() functions? They're meaningless in a language binding. 

tristan: I think bindings are supposed to override that part of the
builder
tristan: I mean... do you want builder to create a raw GtkLabel ? or do
you want it to create some java-gnome wrapper object ?
tristan: I suspect that in gtkmm they have some derived code that
returns a wrapper
***tristan checks with builder how thats done for bindings... I dont
recall

Company: i'd expect you let the builder create the label

tristan: AfC, GtkBuilderClass.get_type_from_name()
Company: and then wrap it

AfC: tristan: the proxy object (to use Owen's terminology) is already
fully engineered, that works fine [and worked fine with libglade].
AfC: tristan: we're stuck at add_from_file

tristan: Company, you would expect that to be done where then ?

Company: tristan: in get_object()

AfC: Company: that's what I'd expect, and that's what we're doing

tristan: AfC, I dont know how it worked fine in the past and how it
worked with libglade.

AfC: Company: we're not even at get_object() yet. Given any pointer we
can ... call g_type_name() on ... we can construct our proxy, no problem

Company: AfC: as tristan says, that's not enough

AfC: Company: but I can't understand why gtk_builder_add_from_file()
can't hack it when glade_xml_parse() managed it

AfC: Well.

tristan: different languages seem to have totally different binding sets
tristan: for instance, I'm not sure that when you create a derived
widget with gtkmm, that it even registers a GType for the new class
tristan: when you create an object with python... it makes a GType
tristan: so they are bidirectional
tristan: in a sense

Company: AfC: glade called all gtk get_type() functions afair
Company: AfC: was always tricky when gtk added new widgets and libglade
hadn't been updated yet

tristan: Company, would it be enough to do it in get_object() ?
tristan: if I go and fetch a window or box... and then itterate it's
children

AfC: tristan: no we don't do anything like that. Never needed to. As far
as C is concerned it's just a GtkWhatever. If the developer has created
a Java side subclass that's their business. Things Just Work™. But
that's not the problem here
tristan: do I get widgets as children or wrappers ?

Company: tristan: you get wrappers

AfC: Company: ... called all gtk_get_type_ functions. Oh. Yes, well,
that'd do it

Company: AfC: so why does gtkbuilder not find the existing C function
gtk_label_get_type() when trying to g_module_symbol() it?

tristan: AfC, they *kindof* work then... if you cannot get the derived
class details in GType terms in C... then ... it's impossible for me to
make a useful java-gnome plugin for Glade

Company: AfC: in java-gnome i mean

AfC: Company: hm?

tristan: because I cannot read any properties or signals that the
java-gnome object may have added

AfC: Company: Code is like this:
AfC: Gtk.init()
AfC: builder = new Builder();
AfC: builder.addFromFile("simple.ui");
AfC: crash
AfC: (well, GError → Exception → terminate)

Company: AfC: yes, because java-gnome is doing bad things
Company: AfC: because g_module_symbol(null_module, "gtk_label_get_type")
fails
Company: AfC: and that's java-gnome's fault somehow

AfC: Company: sorry, what is that?

Company: AfC: that is C

AfC: Company: look I know you guys don't give a shit about language
bindings, but maybe we can leave off the "fault" stuff and assume that
the project means well, and has done what was asked of it over the
years?
AfC: So if there's a new initialization pattern that needs to be
supported, fine

Company: AfC: there isn't
Company: AfC: there's just a new way to look up class names
Company: AfC: and it's done by inspecting the running code for an
exported C function

AfC: Company: so you're saying we instantiated the GtkBuilder object
somehow wrong?

tristan: AfC, I do give a shit, and I also wish I could introspect more
from language-binding created classes... I dont see exactly what could
be going wrong

AfC: tristan: no, me neither;

tristan: if your code is running with libgtk+, then "gtk_label_get_type"
MUST be there
tristan: no reason for the C code calling g_module_symbol to fail.

AfC: tristan: what I wrote above is == to this C code, right?

Company: AfC: no, i'm saying that a java-gnome application looks
different to C code than a C application

AfC: gtk_init()
AfC: gtk_builder_new()
AfC: gtk_builder_add_from_file()

tristan: AfC, yes that should really definitely work

AfC: well, that's the sequence of C calls we're making. :(

Company: AfC: no, deep down it's not
Company: AfC: are you linking your java app with gcc?
Company: AfC: is it doing the equivalent of gcc -shared -lgtk-3 ?

AfC: Company: This is GTK 2, but yes
AfC: LINK=/usr/bin/gcc-4.4 -shared + pkg-config --libs

tristan: right, I suppose there could be low-level trickery, that some
obscure calls to ldd/nm might reveal

Company: AfC: so if you run ldd on the generated binary, it will list
libgtk just like when running it on /usr/bin/gtk-demo ?

AfC: Company: there's no binary. There's a shared library loaded at
runtime, but I will double check

Company: AfC: aha!

tristan: i.e. what is the actual symbol name... but if it's linking to a
real libgtk+ lib... I still dont see why there would be no "T
gtk_label_get_type" in there

Company: AfC: shared libraries loaded at runtime may be loaded with
hidden symbols
Company: AfC: so that g_module_symbol() would not find the symbol

AfC: Company: um, ok, that's interesting
AfC: notes that the rest of the GNOME stack works fine, and has for 9
years

Company: yes

tristan: if it obfuscates the symbol name or such, you can reverse the
process by implementing GtkBuilderClass.get_type_from_name()

Company: the rest of the gnome stack doesn't have to resolve C symbols
at runtime

AfC: if [what] obfuscates?
AfC: This is very interesting

tristan: whatever obscure linking method you might use

Company: tristan: it's dlopen()ing libgtk with RTLD_LOCAL

AfC: Um, well, it's doing whatever pkg-config tells it to do

tristan: Company, that means you can find nothing in the global
namespace ?

Company: tristan: actually, it's not dlopen()ing libgtk but
libjava-gnome-plugin.so
Company: tristan: yes

AfC: yes
AfC: (where it is the Java VM process, yes)

tristan: right, so "whoever" is dlopening it.. has access to those
symbols, there is a handle somewhere
tristan: that handle needs to be used in
GtkBuilder->get_type_from_name()
tristan: to get the actual type

AfC: tristan, Company: thanks for your help. I'll be honest and say I
don't really understand what needs to be done;
AfC: tristan, Company: sounds like its not a matter of a different
linker flag but I certainly don't have access to the dlopen call being
made by the VM [nor would any language binding, I imagine]
AfC: tristan, Company: unless it's $something I can do before calling
[say] gtk_init()

Company: AfC: i'd suspect python or other languages have the same
problem
Company: JS, whatever

tristan: AfC, short answer/explanation is that a language binding needs
to know how to get the actual GType from a type name before the type is
actually registered

Company: unless they don't use RTLD_LOCAL
Company: AfC: and as tristan says, you can overwrite the lookup function

AfC: [I don't know that the JVM is, fwiw]

tristan: python works find with GtkBuilder, they create real GObjects
afaik also

AfC: tristan: isn't that circular? g_type_from_name() only works after a
type has been registered, right?
AfC: Hey, if someone can point us at the call that eg Python is making
before they call gtk_init() that magically fixes the problem, then I'll
get it added right away.

tristan: AfC, no it's not circular, I said a binding needs to make that
association *before* the type is registered

AfC: tristan: ah
AfC: tristan: well as it happens we do have such a list

tristan: it's simple: GTK+ provides standard naming convention, and all
the _get_type() stubs are there
tristan: just have to mash up the string a bit and use the _get_type()
to create it

AfC: tristan: so you're saying we have to invoke every _get_type()
possible before attempting to use GtkBuilder.

tristan: GTK+ already does the string mashing part, you can copy that
code pretty easily
tristan: AfC, no... you have to call _get_type() as a result of
GtkBuilder->get_type_from_name()
tristan: in your language binding's wrapper of GtkBuilder... you
override the ->get_type_from_name() vfunc
tristan: and make it do something language binding custom

AfC: this is where I'm lost. There's nothing custom
AfC: we just have a GtkBuilder*

tristan: AfC, that was an ugly issue with libglade... you actually had
to register each type to use them
tristan: so a.) libglade needed updates for new types... and b.)
applications needed to provide modules to load their own custom types
tristan: AfC, you use GtkBuilder directly from java ??
tristan: or you have something in between, right ?
tristan: the in between should use CustomBuilder instead of GtkBuilder
directly
tristan: with ->get_type_from_name() overridden

AfC: We're verging off-topic for #gtk+ and I don't want to further
clutter up the channel when important bug fixing is going on.
AfC: tristan: I was hoping to have GtkBuilder coverage in our 4.1
release to replace the removed libglade, but it sounds like we'll have
to dig a bit harder.
AfC: appreciate your help

tristan: I'll be around, sorry to walk out on you

AfC: tristan: nah, that's cool


(12:19:43) 

jdahlin: AfC: libglade has a huge table which maps widget name to GType,
we wanted to avoid that when rewriting libglade into GtkBuilder

AfC: jdahlin: I see

jdahlin: and as Company pointed out, that caused problems when a new
widget was added in gtk+ but not in that table

AfC: jdahlin: sure, I grok that

jdahlin: so dlsym(NULL, "gtk_widget_get_type") needs to work, not sure
why that isn't working for java-gnome

AfC: jdahlin: yeah. I don't really understand why a shared linking to
GTK is different than an executable linking to GTK [with respect to
however this works in a normal C GTK program] (which is Company's
hypothesis)

jdahlin: AfC: executable linking is done at compile time, while
dlopen/dlsym is runtime
jdahlin: AfC: GtkBuilder creates a bit of problem for C programs as
well, it uses dlsym to find out callbacks specific in the .ui file
jdahlin: so for C programs you need to link with -rdynamic
jdahlin: is java-gnome using jna or jni?

AfC: jdahlin: JNI

tristan|afk: jdahlin, I think he means that... java-gnome being a shared
lib is linking to GTK+... I *think*... that the java-gnome lib is
dlopened by whatever is running this

AfC: tristan|afk: that's correct

jdahlin: AfC: the main executable is the jvm (/usr/bin/java or
whatever), it loads in libjava-gnome.so via dlopen

AfC: So if there's something I have to add to the linker invocation to
build the .so, no problem

jdahlin: for GtkBuilder to work you have to make all *_get_type symbols
accessible in the main namespace for jvm
jdahlin: that's usually accomplished by passing in RTLD_GLOBAL to dlopen

tristan|afk: if I'm guessing Company's hypothesis right... maybe what is
opening java-gnome is doing so without making the symbols global
tristan|afk: so when that code actually ends up running dlsym() with
NULL... it finds nothing

jdahlin: how is libjava-gnome.so linked against libgtk.so?

tristan|afk: jdahlin, or... it can be done by overriding
->get_type_from_name() inside java-gnome... I think, no ?

AfC: If so, that's going to be hard to beat, because I have zero control
over that. The only workaround would be to cause the VM process to load
a *separate* library first, and call dlopen() on libgtk-x11-2.0.so.0

jdahlin: tristan|afk: that would work as well

AfC: jdahlin: well, let's see

jdahlin: AfC: do you know how the VM loads JNI modules?

AfC: jdahlin: no
AfC: jdahlin: more to the point, I have zero influence over it.
AfC: I mean, it's gotta be dlopen() and dlsym(), but with what flags? No
idea
AfC: jdahlin: LINK=/usr/bin/gcc-4.4 -g -shared -Wall -fPIC
AfC: and
AfC: jdahlin: $LINK -o tmp/libgtkjni-4.0.20-dev.so $objects `pkg-config
--libs $modules`
AfC: [sic]

jdahlin: okay, you could fix it up yourself, either by overriding
get_type_from_name as tristan mentioned or just doing something like
dlopen("libgtk.so", RTLD_GLOBAL) in JNI's module initialization function

AfC: jdahlin: I can certainly do that.
AfC: That's what suggested to Company
AfC: though I wasn't sure if that would do anything if invoked from
a .so that is already linked against libgtk-x11-2.0.so.0

jdahlin: it's a bit ugly using RTLD_GLOBAL though, you're polluting the
namespaces
jdahlin: it'll hopefully do the right thing
jdahlin: the same needs to be done for all shared libraries with
*_get_type functions that java-gnome wants to support, it's not just gtk
jdahlin: but gtk+ is arguable the most important one

AfC: As for "a bit ugly", that's what I'm blown away by all this. I've
tried to follow this conversation, but fundamentally I just don't
understand why it works for a C program [without "polluting"] and not
a .so
AfC: anyway, trying my best

jdahlin: AfC: because of a number of reasons, a C program is linked at
compile time and all the functions its using are known
jdahlin: eg, it knows that gtk_label_get_type() is going to be used, but
not gtk_button_get_type() etc
jdahlin: you can check which functions are linked in by running ldd on
the executable
jdahlin: now, dynamic languages uses dlopen() which can specific, make
all functions available or none at all
jdahlin: the JNI authors decided the latter should be the default for
some reason, and it doesn't seem (by 2 minutes googling) that it's
possible to change that

AfC: [ldd + executable = functions? What option is that?]

jdahlin: or if it's objdump/nm, haven't looked at it for a while
jdahlin: objdump -T executable seems to do it here on my system

AfC: ah
AfC: Well
AfC: I added this before the call to gtk_init():

=== modified file 'src/bindings/org/gnome/gtk/GtkMain.c'
--- src/bindings/org/gnome/gtk/GtkMain.c2010-02-14 20:14:38 +0000
+++ src/bindings/org/gnome/gtk/GtkMain.c2011-04-08 02:51:05 +0000
< at >< at > -31,6 +31,7 < at >< at >
  * wish to do so, delete this exception statement from your version.
  */
 
+#include <dlfcn.h>
 #include <jni.h>
 #include <glib.h>
 #include <gdk/gdk.h>
< at >< at > -56,6 +57,7 < at >< at >
 jobjectArray _args
 )
 {
+void* handle;
 int argc;
 char** argv;
 gint i;
< at >< at > -90,6 +92,12 < at >< at >
 argv[0] = "";
 argc++;
 
+handle = dlopen("libgtk-x11-2.0.so", RTLD_NOW | RTLD_GLOBAL);
+if (handle == NULL) {
+bindings_java_throw(env, "dlopen() failed: %s", dlerror());
+return;
+}
+
 // call function
 gtk_init(&argc, &argv);
 


AfC: and now GtkBuilder works

jdahlin: great

AfC: yeah. But is it great? :)

jdahlin: great that it's working

AfC: Certainly lends strength to Company's hypothesis, that's for sure

jdahlin: is it inconvenient for you to override the GtkBuilder vfunc
get_type_from_name?

AfC: jdahlin: "no", but I'm not sure what I'd be overriding it with?

jdahlin: AfC: implementing it!
jdahlin: you need to subclass it and override it

AfC: "This is mainly used when implementing the GtkBuildable interface
on a type."

jdahlin: sure, but we're outside of "mainly" right now
jdahlin: I added it specifically for these kind of situations
jdahlin: s/added/made it overridable/
jdahlin: gtkmm uses it as well if iirc

AfC: Oh? Ok. I should go look at their code, then

jdahlin: not really
jdahlin: all gtkmm classes are subclasses, and they implement it to map
GtkLabel to their overridden GType
jdahlin: http://git.gnome.org/browse/gtkmm/tree/gtk/src/builder.ccg

AfC: jdahlin: yeah, I'm reading that right now
AfC: All they do is call g_type_from_name() ?

jdahlin: gtkmm is considerably different from a dynamic binding, so you
shouldn't worry too much

AfC: um generally we're mostly the same; Java is a static language too

jdahlin: no, it's not really static

AfC: [except for this business of getting to GTK through a .so rather
than a linked executable]

jdahlin: in the sense that language bindings are loaded via dynamically

AfC: Sure. I means static as in static language API, not a dynamic
language API
AfC: So I assume that GtkBuilder just calls g_type_from_name() itself
internally.

jdahlin: not really no
jdahlin: but it works fine for gtkmm which calls all get_type functions
when the library loads

AfC: Ah
AfC: No, we definitely don't do that. :)
AfC: We could, I guess. Sounds expensive.

jdahlin: maybe it doesn't, but their impl. requires you to call the
_get_type function of a class before using it in gtkbuilder

AfC: which is why g_type_from_name() works
AfC: right
AfC: hm
AfC: Embedding system library names in the source code to pass to
dlopen() is going to be fragile.
AfC: I wondered if -rdynamic to the linker would have the same effect,
but no

jdahlin: kind of fragile yes, but the alternatives are wors
jdahlin: e

AfC: jdahlin: that seems pretty nuts of GTKmm; if I do get_object() on
something I think is be a GtkButton and it turns out to be a
GtkCheckButton (say) it'll crash
AfC: [actually, it won't get past add_from_file() which is my problem
right now]
jdahlin: dunno about the details, you need to check with the gtkmm
authors if you really want to know
AfC: jdahlin: yeah, I'll talk to Murray next time I see him
***jdahlin -> zzz
AfC: jdahlin: do you have an opinion about the "expense" of dlopen(... ,
| RTLD_GLOBAL)?
AfC: jdahlin: ah, g'night. Thanks for your help




------------------------------------------------------------------------------
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
_______________________________________________
java-gnome-hackers mailing list
java-gnome-hackers< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers