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

Re: [java-gnome-hackers] Ugly deadlock with Dialog.run()

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

On Tue, 2010-08-10 at 15:46 +0200, Vreixo Formoso wrote:
> > 1. Take our own lock (which we could then manually unlock in special
> > cases)
> > 
> > 2. Just mess with a manual MonitorExit/MonitorEnter
> > 
> > 3. Seriously mess with the entire main loop process:
> > 

Or maybe

4. Write our own run()

Just a thought I had talking with Guillaume earlier today: we could
maybe just write a run() method in Dialog that does the workaround. ie,
rather than making the developer connect to Dialog.Response, do so
inside run() ourselves. As a convenience.

The trick would be getting that method to block. The only way I could
see to do that would be to nest a call to Gtk.main()... which might
bring us back to the same problem.

AfC
Sydney

Re: [java-gnome-hackers] Ugly deadlock with Dialog.run()

[Vreixo F. <met...@ya...>]

Hi,

> On Mon, 2010-08-09 at 21:42 +0200, Vreixo Formoso wrote:
> > I would like to discuss with you an ugly behavior related with the
> way
> > java-gnome automatically handles the Gtk thread-aware feature. I
> don't
> > really think this is a bug, but I would like to talk about it.
> 
> Yeah, I raised this on 13 Jan,

Ups, sorry! I didn't notice it.

> We could
> 
> 1. Take our own lock (which we could then manually unlock in special
> cases)
> 
> 2. Just mess with a manual MonitorExit/MonitorEnter
> 
> 3. Seriously mess with the entire main loop process:
> 
> [...]
> 
> All of these are invasive. #2 is probably easiest, but there's a
> bigger
> problem: what happens if you're not nested 2 deep, but nested 3 deep?
> Then it won't help.

ok, just a first sight opinion, I will review this in depth tomorrow:

First of all, I agree that 3) will be a pain in the ass. I don't think,
however, 2) would be a better solution: as you have noticed, you can be
nested 3 deep, or even 0 deep if you are not calling run() within a
signal handler (I wonder, however, if both cases could naturally arise
in a real application).

On the other hand, 1) could be a good solution and it seems not that
hard. We might just use java.util.concurrent.locks.ReentrantLock. I
think it is just a matter of changing the automatically generated
synchronized blocks in translation layer (plus any override that might
exist), and the C side bindings_java_threads_lock()/unlock() functions.
Then, we add an override for Dialog.run(), java-side, where, by means of
ReentrantLock.getHoldCount() and unlock() we release all locks but one,
then we call gtk_dialog_run(), and when it returns we finally acquire as
many locks as we originally hold.

I have not been working on this low-level stuff since some years, so
maybe I'm forgetting something... what do you think?

Anyway, I'm not really sure this bug deserves so much work at this
time...

Cheers,
Vreixo

> 
> > Note that in my opinion is it ok as it is now, you can always forget
> > about run() 
> 
> I don't have any hard opinions about it. It's a bug, and we need to
> either fix it if we can. I'd like to keep run(), though. It's nice to
> use inside signal handlers. Or it would be if it worked :)
> 
> AfC
> Sydney

Re: [java-gnome-hackers] Ugly deadlock with Dialog.run()

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

On Mon, 2010-08-09 at 21:42 +0200, Vreixo Formoso wrote:
> I would like to discuss with you an ugly behavior related with the way
> java-gnome automatically handles the Gtk thread-aware feature. I don't
> really think this is a bug, but I would like to talk about it.

Yeah, I raised this on 13 Jan,
http://article.gmane.org/gmane.comp.gnome.bindings.java.devel/1436
and
https://bugzilla.gnome.org/show_bug.cgi?id=606796

It is pretty ugly.

> I've working for several years with java-gnome 

Well, you ARE the #2 committer :)
http://www.ohloh.net/p/java-gnome/contributors


> There is, however, one ugly case. When you call "blocking" methods such
> as Gtk.main() or Dialog.run(), Gtk+ takes care of releasing the lock,
> which makes possible to invoke gtk functions from another thread while
> the main thread is waiting on Gtk.main(). It works very well, except in
> one case: calling Dialog.run() inside a signal handler. It is a common
> situation, when you have to temporally show a dialog in response to a
> user action (e.g. clicking a Button). 
> 
> In this case, when you call run(), the calling thread already holds the
> lock (it is running in a signal handler). Internally, java-gnome
> re-acquires the lock before calling native gtk_dialog_run(). It also
> does it with every other function, and it works ok because java lock are
> re-entrant. However, differently from other functions, gtk_dialog_run()
> will wait in an event loop until the user closes the dialog. As I said
> above, Gtk+ knows that, so it will release the lock, but the problem is
> that we have acquired the lock twice, so the lock keeps owned by the
> calling thread....

I agree with your analysis.

It's not so much "that we have acquired the lock twice" so much as it is
that the gtk_dialog_run() code assumes it can unlock once and be clear.

> What do you think about? Is this ok? Could we (maybe) add a
> runWithoutLock() function? 

[please read my other email]

We could

1. Take our own lock (which we could then manually unlock in special
cases)

2. Just mess with a manual MonitorExit/MonitorEnter

or

3. Seriously mess with the entire main loop process:

        If *we* were iterating the main loop manually, then we could
        control when it takes our lock and when it doesn't. The problem
        is replacing gtk_main() with gdk_events_pending() &
        gdk_main_iteration_do() is NOT really the right thing to do.


All of these are invasive. #2 is probably easiest, but there's a bigger
problem: what happens if you're not nested 2 deep, but nested 3 deep?
Then it won't help.

> Note that in my opinion is it ok as it is now, you can always forget
> about run() 

I don't have any hard opinions about it. It's a bug, and we need to
either fix it if we can. I'd like to keep run(), though. It's nice to
use inside signal handlers. Or it would be if it worked :)

AfC
Sydney

[java-gnome-hackers] Ugly deadlock with Dialog.run()

[Vreixo F. <met...@ya...>]

Hi,

I would like to discuss with you an ugly behavior related with the way
java-gnome automatically handles the Gtk thread-aware feature. I don't
really think this is a bug, but I would like to talk about it.

I've working for several years with java-gnome and I have to admit that
is the best GUI-framework I've ever known for working with multi-thread
applications. You just call java-gnome GUI functions from any thread and
it works!!! This is really a pleasure.

Of course, the reason for this is related with both the good
thread-aware design on Gtk+, plus the acquisition of the mutex lock
before invoking any gtk+ function that java-gnome does automatically.

There is, however, one ugly case. When you call "blocking" methods such
as Gtk.main() or Dialog.run(), Gtk+ takes care of releasing the lock,
which makes possible to invoke gtk functions from another thread while
the main thread is waiting on Gtk.main(). It works very well, except in
one case: calling Dialog.run() inside a signal handler. It is a common
situation, when you have to temporally show a dialog in response to a
user action (e.g. clicking a Button). 

In this case, when you call run(), the calling thread already holds the
lock (it is running in a signal handler). Internally, java-gnome
re-acquires the lock before calling native gtk_dialog_run(). It also
does it with every other function, and it works ok because java lock are
re-entrant. However, differently from other functions, gtk_dialog_run()
will wait in an event loop until the user closes the dialog. As I said
above, Gtk+ knows that, so it will release the lock, but the problem is
that we have acquired the lock twice, so the lock keeps owned by the
calling thread. Therefore, no other thread can access Gtk+ when
Dialog.run() is called inside a signal handler. 

In native Gtk+, I guess it is just a matter of calling gtk_dialog_run()
without acquiring the lock first when you're inside a signal handler,
but the java-gnome this is not possible as the lock is acquired
automatically. 

What do you think about? Is this ok? Could we (maybe) add a
runWithoutLock() function? 

Note that in my opinion is it ok as it is now, you can always forget
about run() and connect to the Response signal if you have this problem.
I'm writing this just because I found this problem this week and I
wanted to tell you about it.

Cheers
Vreixo

[java-gnome-hackers] GModule; GtkBuilder; Re: Java-gnome

[Tycho B. <tyc...@gm...>]

GtkBuilder doesn't use GIR introspection.
My question should have been:
Should opening the GModule representing the main program with with 
g_module_open() work?

GtkBuilder uses g_module_symbol() to get pointers to the constructor of 
an object only named in string.

Regards,
Tycho Bismeijer

Re: [java-gnome-hackers] Java-gnome

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

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

I'm working on a GIR based parser implementation but I don't think it
has anything related with GtkBuilder introspecting class constructors.
So what I suspect is you either don't link against gir or dont have the
typelibs
- -- 
Sincerely,
Serkan KABA
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.15 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkwyDJgACgkQRh6X64ivZaIOIQCfcsrAuRsFV2W2wuzIrREZaYyk
gu4AnR5IjSXXBquJSiY0TOLbMK7Mx1UD
=4sMv
-----END PGP SIGNATURE-----

[java-gnome-hackers] Java-gnome

[Tycho B. <tyc...@gm...>]

Hello,

I'm trying to implement the interface of GtkBuilder. GtkBuilder uses 
gobject introspection to find the constructors of classes if the class 
isn't registered yet in gtk. When using GtkBuilder from java-gnome that 
doesn't seem to work. Should I expect introspection to work for C code 
in java-gnome (of course it does'nt work for java code).

Thanks,

Tycho Bismeijer

Re: [java-gnome-hackers] libappindicator and libindicate support

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

I was thinking about that appindicator/libindicate support again. I
guess that the best way to cover these things in Java would be to create
a specific binding which would depend on java-gnome.

In this way, it would not add optional things to java-gnome (which is
something I'd like) but it would not benefit from the awesome
architecture of java-gnome.

Le lundi 31 mai 2010 à 09:14 +0300, Serkan Kaba a écrit :
> 2010/5/28 Guillaume Mazoyer <res...@gm...>:
> 
> > But they should absolutly not be required to build java-gnome or any
> > kinds of programs (in C people use #ifdef things to know if the code
> > should compile with appindicator/libindicate support).
> There's JEnable (http://www.sosnoski.com/opensrc/jenable/index.html)
> for Java and I've also seen an example of using cpp (c preprocessor)
> on Java files but is either of them an option?
> 
> Regards,
> Serkan
> 
> ------------------------------------------------------------------------------
> 
> _______________________________________________
> java-gnome-hackers mailing list
> jav...@li...
> https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers

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

[java-gnome-hackers] java-gnome 4.0.16 released

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

hack, coffee, hack, hack, WATCH WORLD CUP, drink heavily, hack, hack...

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

Cheers,

AfC
Sydney

Re: [java-gnome-hackers] Main loop crashes

[Jester <jsn...@gm...>]

Here's the code that will reproduce the crash (2 classes):

--- DrawingWin (main class)
import org.freedesktop.cairo.Pattern;
import org.gnome.gdk.Event;
import org.gnome.gdk.EventExpose;
import org.gnome.gdk.Rectangle;
import org.gnome.gtk.DrawingArea;
import org.gnome.gtk.Gtk;
import org.gnome.gtk.VBox;
import org.gnome.gtk.Widget;
import org.gnome.gtk.Window;
import org.gnome.gtk.WindowPosition;
import org.freedesktop.cairo.Context;
import org.freedesktop.cairo.Format;
import org.freedesktop.cairo.ImageSurface;
import org.gnome.gtk.PolicyType;
import org.gnome.gtk.ScrolledWindow;


public class DrawingWin extends Window {

    private ImageSurface surface;

    DrawingWin() {
        hide();

        setTitle("DrawingWin");

        VBox vbox = new VBox(false, 3);

        final DrawingArea d;

        d = new DrawingArea();
        d.setSizeRequest(800, 800 + 400);


        ScrolledWindow scroll = new ScrolledWindow();
        scroll.setPolicy(PolicyType.AUTOMATIC, PolicyType.AUTOMATIC);
        scroll.addWithViewport(d);

        vbox.add(scroll);

        add(vbox);

        setPosition(WindowPosition.CENTER);

        setSizeRequest(600, 400);

        connect(new Window.DeleteEvent() {

            public boolean onDeleteEvent(Widget source, Event event) {
                Gtk.mainQuit();
                return false;
            }
        });

        showAll();

        surface = new ImageSurface(Format.ARGB32, 800, 1200);
        Context im = new Context(surface);
        //im.setAntialias(Antialias.DEFAULT);
        im.setLineWidth(1.0);

        im.setSource(0.8, 0.8, 0.8);
        im.rectangle(0, 0, 800, 1200);
        im.fill();

        im.setSource(0.0, 0.0, 0.0);
        im.rectangle(10, 10, 600, 400);
        im.stroke();

        im.setSource(1.0, 1.0, 1.0);
        im.rectangle(10, 10, 600, 400);
        im.fill();

        im.setSource(0.0, 0.0, 1.0);
        im.moveTo(25.0, 25.0);
        im.lineTo(50.0, 100.0);
        im.stroke();


        d.connect(new Widget.ExposeEvent() {

            public boolean onExposeEvent(Widget source, EventExpose event) {
                System.out.println("expose action");

                final Context cr;
                final Rectangle rect;
                final Pattern linear, radial;

                rect = event.getArea();

                int canvasWidth = 800; 
                int canvasHeight = 1400; 

                System.out.println(rect);

                cr = new Context(source.getWindow());

                cr.setSource(0.0, 0.8, 0.95);
                cr.rectangle(0, 0, canvasWidth, canvasHeight);
                cr.fill();

                cr.setSource(surface, 0, 0);

                cr.paint();

                System.out.println("paint");

                return true;
            }
        });
    }

    public static void main(String[] args) {
        Gtk.init(args);

        new DrawingWin();
        new ThreadWin();
        
        Gtk.main();
    }
}


--- ThreadsWin

import java.io.BufferedReader;
import java.io.File;
import java.io.FileInputStream;
import java.io.FileNotFoundException;
import java.io.IOException;
import java.io.InputStreamReader;
import java.util.logging.Level;
import java.util.logging.Logger;
import org.gnome.gdk.Event;
import org.gnome.gtk.Button;
import org.gnome.gtk.VBox;
import org.gnome.gtk.Widget;
import org.gnome.gtk.Window;
import org.gnome.gtk.WindowPosition;

public class ThreadWin extends Window {
    DownloadTask t;
    
    ThreadWin() {
        hide();

        setTitle("ThreadWin");

        VBox vbox = new VBox(false, 3);

        Button start = new Button("Start");

        start.connect(new Button.Clicked() {

            @Override
            public void onClicked(Button source) {
                t = new DownloadTask();
                t.start();
            }
        });

        vbox.add(start);

        add(vbox);

        setPosition(WindowPosition.CENTER);

        setSizeRequest(140, 40);

        connect(new Window.DeleteEvent() {

            public boolean onDeleteEvent(Widget source, Event event) {
                t.cancelTask();
                return false;
            }
        });

        showAll();
    }

    private class DownloadTask extends Thread implements Runnable {
        boolean canceled = false;

        @Override
        public void run() {
            int idx = 0;

            while (!canceled) {
                System.out.println(idx);
                //loadDataFromFile("PWAV.q");

                File f = new File(System.getProperty("user.home"));

                File[] files = f.listFiles();

                for (int i = 0; i < files.length; i++) {
                    f = files[i];

                    if (f.isFile()) {
                        readFile(f);
                    }
                }

                synchronized (this) {
                    try {
                        wait(10);
                    } catch (InterruptedException ex) {
                       
Logger.getLogger(DrawingWin.class.getName()).log(Level.SEVERE, null, ex);
                    }
                }

                idx++;

            }
        }

        void cancelTask() {
            canceled = true;
        }
    }

    void readFile(File f) {
        try {
            FileInputStream fin = new FileInputStream(f);

            BufferedReader in = new BufferedReader(new InputStreamReader(fin));

            // do nothing here...
            in.close();
        } catch (FileNotFoundException ex) {
            System.out.println(ex);
        } catch (IOException ex) {
            System.err.println(ex);
        }
    }
}
---

Instructions:
1. Run DrawingWin which will open two windows, DrawingWin and ThreadsWin
2. Press start which launches a thread
3. You will notice that DrawingWin goes blank (the drawing disappears)
4. Close ThreadWin by pressing the close button on the window bar
5. Close DrawingWin
6. You will see the following crash log:

Exception in thread "main" org.gnome.glib.FatalError: Gdk-CRITICAL
gdk_window_get_position: assertion `GDK_IS_WINDOW (window)' failed
        at org.gnome.gtk.GtkMain.gtk_main(Native Method)
        at org.gnome.gtk.GtkMain.main(GtkMain.java:82)
        at org.gnome.gtk.Gtk.main(Gtk.java:119)
        at DrawingWin.main(DrawingWin.java:119)


My apologies for the slightly complicated example, but it requires two windows
to trigger the assertion problem from above.

Jester

Re: [java-gnome-hackers] Main loop crashes

[Jester <jsn...@gm...>]

Thanks for the reply. I don't see an attach button but will post a link to a
test case by tomorrow.

Re: [java-gnome-hackers] Main loop crashes

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

On Thu, 3 Jun 2010 02:02:18 +0000 (UTC)
Jester <jsn...@gm...> wrote:

> Jester <jsnow561@...> writes:
> 
> > [snip]

Perhaps you could attach a small test case that demonstrates this
problem?

Re: [java-gnome-hackers] Main loop crashes

[Jester <jsn...@gm...>]

Jester <jsnow561@...> writes:

> 
> I really like much of java-gnome but face a serious problem that may prevent me
> from porting a large-scale project from swing to gtk. When I run a background
> thread to retrieve some data widgets with a DrawingArea go blank. A subsequent
> close action on any window will crash the main loop in the following way:
> 
> Exception in thread "main" org.gnome.glib.FatalError: Gdk-CRITICAL
> gdk_window_get_position: assertion `GDK_IS_WINDOW (window)' failed
>         at org.gnome.gtk.GtkMain.gtk_main(Native Method)
>         at org.gnome.gtk.GtkMain.main(GtkMain.java:82)
>         at org.gnome.gtk.Gtk.main(Gtk.java:119)
>         at ubnz.gtk.ToolbarDemo.main(ToolbarDemo.java:326)
> 
> I've tried multiple potential workarounds, but the problem persists. Any idea
> how to resolve this?
> 
> Thanks a bunch!
> Jester
> 
> ------------------------------------------------------------------------------
> 


Wow, this place sure is quiet! I'm beginning to lose faith...

By the way, I've tested the issue with the release candidate for 4.0.16 which
was posted recently and it shows the same problem.

Would be great if somebody could shed some light on this.

Thanks again,
Jester

[java-gnome-hackers] Main loop crashes

[Jester <jsn...@gm...>]

I really like much of java-gnome but face a serious problem that may prevent me
from porting a large-scale project from swing to gtk. When I run a background
thread to retrieve some data widgets with a DrawingArea go blank. A subsequent
close action on any window will crash the main loop in the following way:

Exception in thread "main" org.gnome.glib.FatalError: Gdk-CRITICAL
gdk_window_get_position: assertion `GDK_IS_WINDOW (window)' failed
        at org.gnome.gtk.GtkMain.gtk_main(Native Method)
        at org.gnome.gtk.GtkMain.main(GtkMain.java:82)
        at org.gnome.gtk.Gtk.main(Gtk.java:119)
        at ubnz.gtk.ToolbarDemo.main(ToolbarDemo.java:326)

I've tried multiple potential workarounds, but the problem persists. Any idea
how to resolve this?

Thanks a bunch!
Jester

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

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

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

We had a planned meeting with Andrew on 30th of May, and it was a
fruitful meeting discussing the current state and the future direction
of GIR work. I'm pasting the IRC logs of the meeting (all timestamps are
UTC+3)


- -- 
Sincerely,
Serkan KABA
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkwEb5QACgkQRh6X64ivZaLtbACfcGKefla4X+TYfMPkpJyVl9wk
quIAn2z7dim0ER9I1thRpkgpAr+w/yGw
=3Rul
-----END PGP SIGNATURE-----

Re: [java-gnome-hackers] libappindicator and libindicate support

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

2010/5/28 Guillaume Mazoyer <res...@gm...>:

> But they should absolutly not be required to build java-gnome or any
> kinds of programs (in C people use #ifdef things to know if the code
> should compile with appindicator/libindicate support).
There's JEnable (http://www.sosnoski.com/opensrc/jenable/index.html)
for Java and I've also seen an example of using cpp (c preprocessor)
on Java files but is either of them an option?

Regards,
Serkan

Re: [java-gnome-hackers] libappindicator and libindicate support

[Francisco O. <fr...@pu...>]

Hi again.

Putting some code where my mouth is I am sending patch against mainline.
I modified configure and faster to support the libs, tested with Ubuntu 
10.04.
I added the defs and bindings for libappindicator and libindicate and an 
example for libindicate.

Comments, suggestions and patches are very welcome.

Regards,

Francisco

> Hello,
>
>    
>> In any case, even if the dependencies are not checked for other distros
>> it would be a problem in build stage because java-gnome currently
>> doesn't support optional dependencies. By the way is this library going
>> to stay being Ubuntu specific.
>>      
> No these libraries are not Ubuntu specific but they depend on the
> distros packagers of course.
>
> But they should absolutly not be required to build java-gnome or any
> kinds of programs (in C people use #ifdef things to know if the code
> should compile with appindicator/libindicate support).
>
> I thought about adding support for those libraries (well Francisco was
> faster than me :D) but I was stucking on "they should be optional not
> required".
>
>    
>
>
> ------------------------------------------------------------------------------
>
>    
>
>
> _______________________________________________
> java-gnome-hackers mailing list
> jav...@li...
> https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers
>    

Re: [java-gnome-hackers] optional dependencies (was Re: ...)

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

On Fri, 2010-05-28 at 15:03 +0200, Guillaume Mazoyer wrote:
> But they should absolutely not be required to build java-gnome or any
> kinds of programs (in C people use #ifdef things to know if the code
> should compile with appindicator/libindicate support).

Yeah. java-gnome isn't really very good at that right now, partly
because

a) Java the language isn't very good at that

        [and that's ok; no #ifdef is a feature, not a bug :). Actually,
        Java is very good at it - if you don't depend on it, you don't
        import it. But the code in scope needs to compile]

b) philosophically, I didn't want to maintain a project where people
wouldn't know whether what they needed would be there or not.

        [There's nothing worse than you installing something only to
        discover (eg) your Cairo doesn't have PDF support. "Like, what
        the fuck, man?" with my best 70s California surfer dude
        accent :). We just depend on Cairo, and expect it to work.
        People should be able to depend on java-gnome, and know what
        they're getting]
        
c) java-gnome depends on GNOME; so, if you've got a Desktop installed
you by definition have all the prerequisites.

        [Done. No fuss, no muss, and makes sense given the limited time
        we all have to spend on things like this. It's also why I've
        kept it 1 package and not 9]


> I was stuck on "they should be optional not
> required".

d) we haven't implemented out the infrastructure and mechanisms for
optionally depending on individual libraries.

This is where it gets interesting. This *IS* something we have been
thinking about for a long time and have a fairly good idea of what we
need to do to support it.

For example, I'd rather like to see us have a webkit-gtk binding, and
James even worked on one a bit, but (especially a few years ago) it was
completely unreasonable to expect a normal user of release or 'mainline'
would have it available.

But it's really hard. The build system assumes all the sources will
compile.

        [What an amazing thought!]

So if we put in code that depends on things $you don't have on your
system, then boom java-gnome won't build.

So we'd need to change that. Fair bit of work. Also, top level configure
would also have to be taught what to do when it looks for something and
doesn't find it. Another big piece of work, though that's more doable.

Then we need to build the library such that it only links against the
things you actually have (so it completes the build, hey). That's a bit
more engineering. Getting trickier.

The usual approach to these problems is to make many libraries instead
of one. In java-gnome it wouldn't be *too* hard to load a bunch of
lib{glib,gtk,webkitgtk,...}jni-4.0.so; presumably we'd just do it one
loadLibrary() per module in the Plumbing class. So we'd need to arrange
that, then arrange to link the individual .so files instead of one big
one. That is all doable, but it's a LOT of work.

++

My take on it as maintainer is that we're still better off having just
one top level .jar file (which for historical reasons is called gtk.jar)
because Java only loads what you import and it doesn't matter a whit if
*EVERYTHING* is in that .jar, and it's a pain in the ass having to add >
1 to your IDE, run scripts, etc.

If the library itself then quietly internally then loads 10 - 15 .so
files rather than the 1 .so file it's loading now, then I guess that'd
be ok.

        [purists would complain about the cost of all the extra dynamic
        libraries, but I'm not so sure that in a land of Java on top of
        GTK that # of .so files is our biggest worry. Still, right now
        we have 1 and that's acceptable in anyone's books]

Since supporting experimental or obscure (indicator is "obscure in the
sense that no one but Ubuntu users will ever have it) would be really
excellent, it'd be worth doing the work to implement it.

It'll take hacking on configure, the build system, the Plumbing classes,
and knowing a lot about how linking works ... essentially, everything
there is to know about java-gnome :)

Big piece of work, but if we want to go there, I'm happy to help.

AfC
Sydney

Re: [java-gnome-hackers] libappindicator and libindicate support

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

Hello,

> In any case, even if the dependencies are not checked for other distros
> it would be a problem in build stage because java-gnome currently
> doesn't support optional dependencies. By the way is this library going
> to stay being Ubuntu specific.
No these libraries are not Ubuntu specific but they depend on the
distros packagers of course.

But they should absolutly not be required to build java-gnome or any
kinds of programs (in C people use #ifdef things to know if the code
should compile with appindicator/libindicate support).

I thought about adding support for those libraries (well Francisco was
faster than me :D) but I was stucking on "they should be optional not
required".

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

[java-gnome-hackers] java-gnome 4.0.16 imminent

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

Thijs's 'accelerators' branch is merged, and that's what I was waiting
on before doing the next release. Kenneth's 'cairo-operator' work is
also in. Pretty rad.

I rolled a java-gnome 4.0.16-rc1 release candidate and uploaded it.

AfC
Sydney

Re: [java-gnome-hackers] libappindicator and libindicate support

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

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

On 28-05-2010 05:00, Francisco Ortiz wrote:
> As an Ubuntu user I want my app to support the new indicators
> (complementing the lack of 'actions' support for ubuntu notification
> system) based on the Ayatana umbrella project , so I read the docs get a
> copy of java-gnome src from the ubuntu repository (didn't use bzr way,
> but is the next step)  and started hacking the bindings. After 3 days of
> work I have working bindings for libindicate
> <https://wiki.ubuntu.com/MessagingMenu/> and libappindicator
> <https://wiki.ubuntu.com/DesktopExperienceTeam/ApplicationIndicators>.
> 
> I want to share with you what i did (i read the style, hacking, and docs
> and i am in process to document all the API) and i have a couple of
> questions:
Great, well done. Feel free to send a bundle against mainline.
> 
> In configure (and in build/faster) I added the package dependencies
> under debian OS (shared with Ubuntu) but i think is not the best
> solution. The previous dependencies are Ubuntu specific, but I dont want
> to break the code of the project if you are not using Ubuntu. Even in
> Ubuntu I don't know if the libs are required.
> 
> - How should I handle optional libraries for optional bindings? Or maybe
> I need to implement some kind of fallback implementation?
In any case, even if the dependencies are not checked for other distros
it would be a problem in build stage because java-gnome currently
doesn't support optional dependencies. By the way is this library going
to stay being Ubuntu specific.
> 
> - By default the generated code is under org.gnome.<libname> package but
> i dont know if its a valid package. I dont know the state I was
> inspecting the DBus messages and they are using org.ayatana or
> org.freedesktop namespaces, there is a ticket in the launchpad
> https://bugs.launchpad.net/libindicate/+bug/452165 regarding this.
> Suggestions?
This package name generation is java-gnome specific, you can leave it to
default. That bug is probably about exported dbus objects which we don't
care at bindings level.

- -- 
Sincerely,
Serkan KABA
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkv/MFUACgkQRh6X64ivZaKG0gCffL4cXz/I2f6oHy5rQFgi9UUm
zC4AmwTvypeCex8hCnBJPmFPnn2ILMrL
=zAg8
-----END PGP SIGNATURE-----

[java-gnome-hackers] libappindicator and libindicate support

[Francisco O. <fr...@pu...>]

Hi everybody,

First of all I want to thank for the huge effort you are doing 
delivering java bindings for gnome.

I am developing a little java app just for fun and I am using the 
binding for libnotify provided for java-gnome project.

As an Ubuntu user I want my app to support the new indicators 
(complementing the lack of 'actions' support for ubuntu notification 
system) based on the Ayatana umbrella project , so I read the docs get a 
copy of java-gnome src from the ubuntu repository (didn't use bzr way, 
but is the next step)  and started hacking the bindings. After 3 days of 
work I have working bindings for libindicate 
<https://wiki.ubuntu.com/MessagingMenu/> and libappindicator 
<https://wiki.ubuntu.com/DesktopExperienceTeam/ApplicationIndicators>.

I want to share with you what i did (i read the style, hacking, and docs 
and i am in process to document all the API) and i have a couple of 
questions:

In configure (and in build/faster) I added the package dependencies 
under debian OS (shared with Ubuntu) but i think is not the best 
solution. The previous dependencies are Ubuntu specific, but I dont want 
to break the code of the project if you are not using Ubuntu. Even in 
Ubuntu I don't know if the libs are required.

- How should I handle optional libraries for optional bindings? Or maybe 
I need to implement some kind of fallback implementation?

- By default the generated code is under org.gnome.<libname> package but 
i dont know if its a valid package. I dont know the state I was 
inspecting the DBus messages and they are using org.ayatana or 
org.freedesktop namespaces, there is a ticket in the launchpad 
https://bugs.launchpad.net/libindicate/+bug/452165 regarding this. 
Suggestions?

Thanks in advance for the answers,

Regards

Fran

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

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

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



On 10-05-2010 10:48, Serkan Kaba wrote:
> 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
> 
> ------------------------------------------------------------------------------
> 
> _______________________________________________
> java-gnome-hackers mailing list
> jav...@li...
> https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers
> 
I started the alternative implementation based on handwritten binding
around GIR and pushed it to
bzr://research.operationaldynamics.com/bzr/java-gnome/hackers/serkan/gir/ the
code is at tests/exploration/gir-java

- -- 
Sincerely,
Serkan KABA
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEUEARECAAYFAkv6sj0ACgkQRh6X64ivZaLuvwCXWzPGgJ251YcGOTVqJEx1yRBq
/wCeNLYZ510ulW6mYF3iS5z/LAJ7ryA=
=vhoB
-----END PGP SIGNATURE-----

[java-gnome-hackers] Problem compiling Java-gnome with Jdk7

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

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

I have a snapshot of java 7 (java -version output at the end) which fail
to compile java gnome with following error

src/bindings/org/gnome/gdk/Plumbing.java:68: 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 overrides the other
    protected static Boxed boxedFor(Class<? extends Boxed> type, long
pointer) {


java version "1.7.0-ea"
Java(TM) SE Runtime Environment (build 1.7.0-ea-b87)
Java HotSpot(TM) 64-Bit Server VM (build 18.0-b01, mixed mode)

The error seems something like to be fixed but I'm not quite sure.
Please examine.
- -- 
Sincerely,
Serkan KABA
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkv6rPwACgkQRh6X64ivZaK53wCaA+x/4FhVzgL4R4b81/QFpjeQ
mdMAnRrnEdPwzDf3UHoeCJJgsLONNagq
=OldY
-----END PGP SIGNATURE-----

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

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

On Thu, 2010-05-13 at 10:31 -0300, Douglaz wrote:
>    Please let me know if this one is correct.

It is indeed. Merged to 'mainline'. Thanks for your contribution!

We encourage people to add unit tests to the test suite. It's not always
obvious what sort of tests one could do. In this case I added a
round-trip tests for both the methods you added. Have a look at
tests/bindings/org/gnome/gtk/ValidateEntry.java. Should you wish to add
something again in the future, perhaps you can include a test case like
this too.

AfC
Sydney