java-gnome-developer — For people using the bindings to write their own applications

Re: [Java-gnome-developer] More detailed input handling

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

On Wed, 2010-02-10 at 08:39 -0200, Douglaz wrote:
> Hello!
> 
>     I just got my hands in the java-gnome v.4.0.14 'News' file

You mean http://java-gnome.sourceforge.net/4.0/NEWS.html#4.0.14 :)


>  and found something really interesting for me, regarding the GTK
> Input Handling.

Sure. So that's
http://java-gnome.sourceforge.net/4.0/doc/api/org/gnome/gtk/InputMethod.html
for people who haven't seen it. Which is to say, there's not much there,
sorry. Perhaps someone can improve it. 


>  However I could not find a good tutorial about how to use this as
> intended.

Did you see: 
http://java-gnome.sourceforge.net/4.0/doc/api/org/gnome/gtk/InputMethod.html#filterKeypress(org.gnome.gdk.EventKey)

Failing that, I can show you the code I happen to be working that needed
this and led me to add coverage for it to java-gnome. But in brief, for
DrawingArea d and InputMethod im,


        im = new SimpleInputMethod();
       ...

        d.connect(new Widget.KeyPressEvent() {
            public boolean onKeyPressEvent(Widget source, EventKey event) {
                if (im.filterKeypress(event)) {
                    return true;
                }
                return false;
            }
        });

        d.connect(new Widget.KeyReleaseEvent() {
            public boolean onKeyReleaseEvent(Widget source, EventKey event) {
                if (im.filterKeypress(event)) {
                    return true;
                }
                return false;
            }
        });

        im.connect(new InputMethod.Commit() {
            public void onCommit(InputMethod source, String str) {
                doSomethingWith(str);
            }
        });



which is from tests/prototype/ManualInput.java, where I first
experimented with all this.

Incidentally, even mere westerners like me we can still see some of the
fancy pre-edit stuff [in normal text entry, say in gedit] by hitting
Crtl+Shift+U and then typing a 2-5 digit Unicode codepoint number. I
think there are a few more signals needed if we want to emulate that
ourselves (it still works, but to display pre-edit we have to draw your
own pre-edit strings apparently. Reading the code in GTK's
gtk/gtktextview.c is illuminating if you can manage it). I tried to get
a real input method (Japanese, say) on board but was a bit lost so can't
say 100% if that's working right [but if they draw their own preedits,
then I hope so].

AfC
Sydney


-- 
Andrew Frederick Cowie
http://www.andrewcowie.com/

[Java-gnome-developer] More detailed input handling

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

Hello!

    I just got my hands in the java-gnome v.4.0.14 'News' file and found
something really interesting for me, regarding the GTK Input Handling.
However I could not find a good tutorial about how to use this as intended.
Can someone tell me where can I find such resource?

Thanks in advance!
Douglas

Re: [Java-gnome-developer] Cairo - embedding images in pdfs

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

On Tue, 2010-02-09 at 10:38 +0000, William Temperley wrote:

> Thanks Andrew. Glad it's a simple fix - apologies for the noise.

Not at all.

I looked into it; if the first thing you'd done had been

        b = new Button();
        
it would have bailed out with the Exception I mentioned. Alas. We'll
come up with something deeper, I imagine.

AfC
Sydney

Re: [Java-gnome-developer] Cairo - embedding images in pdfs

[William T. <wil...@gm...>]

On 9 February 2010 05:01, Andrew Cowie <an...@op...> wrote:
> On Sat, 2010-02-06 at 10:52 +0000, William Temperley wrote:
>
>> I've posted the VM crash dump here:
>> http://pastebin.com/m7587cc22
>
> The relevant part is:
>
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> C  [libpixbufloader-gif.so+0x1b76]
>
> Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
> j  org.gnome.gdk.GdkPixbuf.gdk_pixbuf_new_from_file(Ljava/lang/String;)J+0
> j  org.gnome.gdk.GdkPixbuf.createPixbufFromFile(Ljava/lang/String;)J+21
> j  org.gnome.gdk.Pixbuf.checkPixbufFromFile(Ljava/lang/String;)J+44
> j  org.gnome.gdk.Pixbuf.<init>(Ljava/lang/String;)V+2
> j  uk.ac.ox.map.carto.canvas.CairoTest.main([Ljava/lang/String;)V+69
> v  ~StubRoutines::call_stub
>
> which is nothing unusual at all.
>
>
>> I'm on a fairly standard Ubuntu Karmic AMD64 install - using Java-gnome-4.0.14.
>
> Sure, that's fine.
>
> (java-gnome from the PPA, I assume?)
>

No - built from source.

>> It just crashed when creating a pixbuf from a file. I was just doing a
>> very simple trial of a few features:
>
>
>> public class CairoTest {
>>       public static void main(String[] args) throws IOException {
>
> You didn't call Gtk.init() first. That's obligatory.
> http://java-gnome.sourceforge.net/4.0/doc/api/org/gnome/gtk/Gtk.html#init(java.lang.String[])
>
> Annoyingly, not having done so should have resulted in an Exception
> being thrown when you tried to use anything else in java-gnome.
>
> We used to have some great code that would check you'd initialized
> properly. Apparently we messed that up when we changed the
> initialization last cycle to deal with the GLib g_set_prgname() bug.
> http://article.gmane.org/gmane.comp.gnome.bindings.java.devel/1425
> refers. Not sure why we aren't getting an Exception anymore. Someone
> will need to fix that.
>
> Anyway, call Gtk.init() and you're on your way.
>
> AfC
> Sydney
>

Thanks Andrew. Glad it's a simple fix - apologies for the noise.

Will

Re: [Java-gnome-developer] Cairo - embedding images in pdfs

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

On Sat, 2010-02-06 at 10:52 +0000, William Temperley wrote:

> I've posted the VM crash dump here:
> http://pastebin.com/m7587cc22

The relevant part is:

Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [libpixbufloader-gif.so+0x1b76]

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  org.gnome.gdk.GdkPixbuf.gdk_pixbuf_new_from_file(Ljava/lang/String;)J+0
j  org.gnome.gdk.GdkPixbuf.createPixbufFromFile(Ljava/lang/String;)J+21
j  org.gnome.gdk.Pixbuf.checkPixbufFromFile(Ljava/lang/String;)J+44
j  org.gnome.gdk.Pixbuf.<init>(Ljava/lang/String;)V+2
j  uk.ac.ox.map.carto.canvas.CairoTest.main([Ljava/lang/String;)V+69
v  ~StubRoutines::call_stub

which is nothing unusual at all.


> I'm on a fairly standard Ubuntu Karmic AMD64 install - using Java-gnome-4.0.14.

Sure, that's fine.

(java-gnome from the PPA, I assume?)

> It just crashed when creating a pixbuf from a file. I was just doing a
> very simple trial of a few features:


> public class CairoTest {
> 	public static void main(String[] args) throws IOException {

You didn't call Gtk.init() first. That's obligatory.
http://java-gnome.sourceforge.net/4.0/doc/api/org/gnome/gtk/Gtk.html#init(java.lang.String[])

Annoyingly, not having done so should have resulted in an Exception
being thrown when you tried to use anything else in java-gnome.

We used to have some great code that would check you'd initialized
properly. Apparently we messed that up when we changed the
initialization last cycle to deal with the GLib g_set_prgname() bug.
http://article.gmane.org/gmane.comp.gnome.bindings.java.devel/1425
refers. Not sure why we aren't getting an Exception anymore. Someone
will need to fix that.

Anyway, call Gtk.init() and you're on your way.

AfC
Sydney

Re: [Java-gnome-developer] Keeping GUI responsive with java-gnome

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

Sorry I couldn't give you a longer response before, but I wanted to get
the one-liner out in the brief moment I had an available network
connection. If you're an experienced Java programmer and know about
workers then you'll get it fine, but for anyone who is new in this space
I wanted to write a longer explanation, follows:

On Mon, 2010-02-08 at 17:49 +0100, Björn Hurling wrote:
> I am having trouble keeping my GUI responsive while doing a lengthy 
> operation.

So, as is common in GTK land, we have to take care of not blocking the
main loop. Sounds like you're across that, as you say:

> At least that's the way how I could do it in C. 

:)

>  This is what I found on a code writing guide for Rhythmbox: 
> "Many times when some code has to perform a long computation or task, it 
> is actually a small task which is repeated many times."

Indeed.

So, the thing is this: in old world GTK programs written-in-C, the
technique was to use an "idle callback". This runs when the main loop is
"idle", which is not precisely true; it runs *blocking* the mainloop
after the current set of X events are processed. But it's all in the
same (single) process thread.

That was fine in single CPU, single core days, but anyone who has been
using multiple CPUs noticed that your typical GTK app (be it C or
especially Python) would be really really good at maxing out 1 CPU while
the other 3 sat there idle. That's single process single thread
computing for you.

Of course, the miracle of multiple cores per CPU means that just about
everyone has an SMP system these days.

[Which is why I'm a big fan of threads (if used carefully and properly
of course; programming is still programming and has to be done well)]

So the Rhythmbox code noting about small tasks is highlighting the
notion that you can, between small tasks, block your real work and let
GTK spin a bit, before blocking GTK and getting back to your real work.
Which beats the hell out of blocking GTK for a long time (and hence
losing responsiveness) but isn't making terribly good use of available
resources.


> Unfortunately these equivalents no longer 
> exist in version 4. Can anyone tell me why these methods were removed 

Well they never existed in java-gnome 4.0, so they weren't "removed".

++

We transparently do the work to use GTK's thread-safety mechanism
correctly.

Actually, GTK's thread awareness mechanism is just a big global lock,
which isn't ideal but that's the way it has to be to keep GDK and X in
sync, so that's the way it is. It's not an issue if all your work is
(say) network heavy and happily running in another thread. It is
discussed here:
http://java-gnome.sourceforge.net/4.0/doc/api/org/gnome/gdk/Gdk.html
and was originally implemented as described here and here:
http://blogs.operationaldynamics.com/andrew/software/gnome-desktop/gtk-thread-awareness.html
http://blogs.operationaldynamics.com/andrew/software/java-gnome/thread-safety-for-java.html
if you're interested in the background.

So, the answer to your question is "use a worker thread". This applies
both for quick one-off validations in Button handlers, but more
generally you have one (or maybe more) threads doing the heavy lifting
[I/O, whatever] while occasionally making GTK calls to update selected
minor elements of the GUI. Meanwhile the main thread can otherwise do
it's thing happily and you have a responsive app.

The important consideration remains not blocking the GDK lock, be it in
a [main thread] signal callback, or in a GTK call from some other
thread . If you do that, you'll block the main loop from iterating, and
you'll stall your user interface. So in that regard, it's no different
than C. GTK is GTK.

Indeed, all of this applies if using GTK multithreaded from C or C++.
It's just a lot easier to do in Java.

Hope that helps,

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

Re: [Java-gnome-developer] Keeping GUI responsive with java-gnome

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

On Mon, 2010-02-08 at 17:49 +0100, Björn Hurling wrote:
> I am having trouble keeping my GUI responsive while doing a lengthy 
> operation.

Use a worker thread for computationally intensive tasks.

AfC
Sydney

[Java-gnome-developer] Keeping GUI responsive with java-gnome

[Björn H. <hu...@sr...>]

Hello,

I am having trouble keeping my GUI responsive while doing a lengthy 
operation. This is what I found on a code writing guide for Rhythmbox: 
"Many times when some code has to perform a long computation or task, it 
is actually a small task which is repeated many times." Well, this is 
exactly the way my lengthy operation works. An idea is to insert a small 
loop that checks for pending events each time the innermost loop is 
entered (rather than using threads):

while (gtk_events_pending()) {
            gtk_main_iteration();
}

At least that's the way how I could do it in C. And in fact, there have 
been equivalents for these methods in java-gnome (Gtk.eventsPending() 
and Gtk.mainIteration()). Unfortunately these equivalents no longer 
exist in version 4. Can anyone tell me why these methods were removed 
and what's the best way to do what I want?

Björn Hurling

Re: [Java-gnome-developer] Cairo - embedding images in pdfs

[William T. <wil...@gm...>]

On 5 February 2010 23:34, Andrew Cowie <an...@op...> wrote:
> On Fri, 2010-02-05 at 22:57 +0000, William Temperley wrote:
><snip>
>
>
>> The following crashes the JVM:
>
> But regardless, THAT shouldn't happen. Especially not her
>> pb = new Pixbuf("/tmp/logo.png");
>
>> Could anyone give me some pointers please?
>
> So, if you could post on a server or pastebin somewhere the VM crash
> dump you get from the JVM, that might help.
>
> It might help people on the list if they could see some code, too. Hard
> to imagine what context you have that led to a crash there.

I've posted the VM crash dump here:
http://pastebin.com/m7587cc22

I'm on a fairly standard Ubuntu Karmic AMD64 install - using Java-gnome-4.0.14.
It just crashed when creating a pixbuf from a file. I was just doing a
very simple trial of a few features:

public class CairoTest {
	static PdfSurface pdf;
	
	public static void main(String[] args) throws IOException {
		pdf = new PdfSurface("/tmp/javacairo.pdf", 500, 707);
		
        final Pattern linear, radial;
        Context cr = new Context(pdf);
        cr.setSource(1.0, 0.1, 0.0, 1.0);
        cr.moveTo(10, 40);
        cr.lineTo(120, 145);
        cr.stroke();

//Crashes here
        Pixbuf pb = new Pixbuf("/tmp/logo.gif");
        cr.setSource(pb, 10, 10);
        cr.paint();


Cheers

Will

Re: [Java-gnome-developer] Cairo - embedding images in pdfs

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

On Fri, 2010-02-05 at 22:57 +0000, William Temperley wrote:
> Thanks for the great libraries. They're absolutely the best way of
> producing PDFs I've found.

Well, there are glitches :) notably the fact that Cairo itself doesn't
quite do everything we need it to. Adrian Johnson wants to create a PDF
specific library that uses Cairo for its drawing but that knows about
the rest of the PDF spec (as there are a number of PDF want-to-haves
that just don't belong in Cairo, and won't get there, unfortunately).
Needless to say that's a year+ away, but I'm hoping to support him as he
goes.

That said, Cairo 1.9 is a *significant* improvement over 1.8 in a lotof
areas we touch using PdfSurface.

> I've got what I expect is quite a simple problem, but I've spent hours
> trawling apis and I can't figure it out.  I'd just like to embed a
> large image in a pdf.
> 

So that's actually one of the problems; right now Cairo converts it to a
bitmap or so, rather than just embedding the damn (ie) jpg. That's fixed
in 1.10 by the addition of a setMimeType() API. But we don't have that
yet.


> The following crashes the JVM:

But regardless, THAT shouldn't happen. Especially not her
> pb = new Pixbuf("/tmp/logo.png");

> Could anyone give me some pointers please?

So, if you could post on a server or pastebin somewhere the VM crash
dump you get from the JVM, that might help. 

It might help people on the list if they could see some code, too. Hard
to imagine what context you have that led to a crash there.

AfC
Sydney

[Java-gnome-developer] Cairo - embedding images in pdfs

[William T. <wil...@gm...>]

Dear all

Thanks for the great libraries. They're absolutely the best way of
producing PDFs I've found.
I've got what I expect is quite a simple problem, but I've spent hours
trawling apis and I can't figure it out.  I'd just like to embed a
large image in a pdf.

The following crashes the JVM:
Pixbuf pb = new Pixbuf("/tmp/logo.png");

Could anyone give me some pointers please?
I'm hoping to produce PDFs like these:
http://www.map.ox.ac.uk/data/
Which I created with some hacky Python scripts + ArcGIS, The
Gnome / Cairo Java bindings would be a much cleaner solution.

Thanks and regards,

Will Temperley

Malaria Atlas Project
University of Oxford
http://www.map.ox.ac.uk/

Re: [Java-gnome-developer] Reading Quickly glade files

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

On Wed, 2010-02-03 at 10:41 -0800, Andres Almiray wrote:

> However attempts to read a glade file that was created by using Ubuntu
> Quickly resulted in some manual mangling of the xml before java-gnome
> was happy with it.

That's odd. A standard .glade file should just work. Maybe you didn't
save it in glade format as Carlos suggested?

++

As for GtkBuilder features [as opposed to the original LibGlade], so far
no one has wanted GtkBuilder support badly enough to want to contribute
support for it. Adding the basics shouldn't be that hard.

If you're interested in pursuing it, maybe start a thread on the
-hackers list and we can figure out some ways to do
it. In short, though, it shouldn't be too hard [mostly just need to
implement a class similar to what Glade.parse() does, rather than having
to create 10s or 100s of new classes]. It wouldn't be a bad way to get
involved in contributing to java-gnome, actually.


> I noticed while working with java-gnome: it expect resources to be
> defined as files that can be read from the native side.

That's very common in GNOME programs. Supporting application resources
(translations, images, meta files, documentation, etc) have to be installed at the
intersection of where the system will see them (/bin, /man, etc) and
where a distro's policies require them to be.

> This hinders the ability to place resources on the classpath (inside
> jars for example) and let the library picke them up.

Yeah, I used to think that was important, but you're going to have to
install things like translations and .desktop files and images to the
appropriate place in the filesystem anyway. You can't bundle
translations in a .jar file, so I wouldn't waste time trying to stuff
non-code things into .jars

[if you want an example of how you can do that, I can point you to one]

> Would it be possible to have the Java wrappers expose Java friendly
> InputStream methods?

Why? Is there something wrong with java.io.InputStream?

If you're really desperately in need of a GInputStream somewhere, you
might look at what Martin Garton did for the Pixbuf() constructor taking
data. That is a case where we exposed a Java appropriate type byte[], in
that case, and then did the heavy lifting to turn that into the
appropriate wrapped gio objects purely on the C side.

That's actually a pretty good example; we were able to avoid exposing a
lots of unnecessary intermediate stuff which we have no need of in our
public API.

But as I've come across this in various areas, there are a fairly large
number of ways that different libraries handle this. Most of them only
offer a single method, and that's loading off (or saving to) disk [one
that comes to mind is PdfSurface; it'd be nice to use that without
needing a file backing it. Oh well; there are various ways to create
temporary files in . or /tmp, so it's not a show stopper]

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

Re: [Java-gnome-developer] Reading Quickly glade files

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

On Wed, 2010-02-03 at 14:25 -0500, Jacek Furmankiewicz wrote:
> I did at one point try to start working on GtkBuilder support in
> Java-GNOME

You won't need JNA (and trying to use it will make disastrous mess, so
you really don't want to try it). java-gnome is *already* a binding
library. The _whole point_  of java-gnome is enabling people to add
coverage they need.

[this was fairly obvious when we re-engineered the library as java-gnome
4.0 back ~2006, but it seems to be missing from people's conceptual
understanding of what the project is about these days, so perhaps we
need to do some work to highlight that. On the website, maybe?]

++

Carlos suggested that maybe Andres saved in the new "builder" format
rather than the original glade one? That's possible; Tristan et al want
people to migrate to builder. Fair enough.

So, like everything else in any library ever, someone will have to write
it. In our case, that means adding a bit of coverage. Personally I
haven't needed it (I don't use glade anymore; I find it a hindrance, but
that's just my own experience) so I haven't written builder coverage
myself. But that's ok, because someone else can :)

If you want to have GtkBuilder support in java-gnome, then you simply need to add a
complement of the present Glade.parse() code paths, and then implement
GtkBuildable everywhere. Shouldn't be too hard, actually. What will take
a little bit of doing is working out what our public API should be like.
At first glance the libglade API would be a roadmap, but we'll see.
Let's talk about it on java-gnome-hackers.

AfC
Sydney

Re: [Java-gnome-developer] Reading Quickly glade files

[Andres A. <aal...@gm...>]

Thanks for the pointers guys. I suspected different glade versions were to
blame.

So what about adding InputStream methods for resource handling? Would love
to have those.

Cheers,
Andres

On Wed, Feb 3, 2010 at 11:25 AM, Jacek Furmankiewicz <ja...@gm...>wrote:

> I did at one point try to start working on GtkBuilder support in Java-GNOME
> (although using JNA static mapping instead of JNI to do the low-level
> binding)
> https://jna.dev.java.net/#direct
>
> but unfortunately due to lack of time never got it to any workable state
> (although I was able to actually load a file and instantiate it).
> So this is something on the todo list for the future.
>
> Jacek
>
>
> On Wed, Feb 3, 2010 at 2:19 PM, Carlos Jenkins <
> car...@gm...> wrote:
>
>> I think that s the problem too. java-gnome support only libglade files.
>>
>> On Glade, you can choose to save files on libglade format.
>>
>> Cheers
>>
>
>

Re: [Java-gnome-developer] Reading Quickly glade files

[Jacek F. <ja...@gm...>]

I did at one point try to start working on GtkBuilder support in Java-GNOME
(although using JNA static mapping instead of JNI to do the low-level
binding)
https://jna.dev.java.net/#direct

but unfortunately due to lack of time never got it to any workable state
(although I was able to actually load a file and instantiate it).
So this is something on the todo list for the future.

Jacek

On Wed, Feb 3, 2010 at 2:19 PM, Carlos Jenkins <
car...@gm...> wrote:

> I think that s the problem too. java-gnome support only libglade files.
>
> On Glade, you can choose to save files on libglade format.
>
> Cheers
>

Re: [Java-gnome-developer] Reading Quickly glade files

[Carlos J. <car...@gm...>]

I think that s the problem too. java-gnome support only libglade files.

On Glade, you can choose to save files on libglade format.

Cheers

Re: [Java-gnome-developer] Reading Quickly glade files

[Jacek F. <ja...@gm...>]

Hi Andres, nice to see you here :-)

I may be wrong, but I believe quickly is using the new GtkBuilder format
(which now ships as part of GTK+)
http://library.gnome.org/devel/gtk/unstable/GtkBuilder.html

while Java-GNOME I think still supports only the old Glade format (which
used to be a stand-alone library).

More (hopefully useful) info here:
http://www.micahcarrick.com/05-30-2008/gtk-builder-libglade-faq.html

Anyone correct me if I am leading Andres into the wrong direction.

Cheers,
Jacek

On Wed, Feb 3, 2010 at 1:41 PM, Andres Almiray <aal...@gm...> wrote:

> Hello devs!
>
> I'm working on a Gtk plugin for the Griffon framework that relies on
> java-gnome to do its thing (great work you guys!).
> However attempts to read a glade file that was created by using Ubuntu
> Quickly resulted in some manual mangling of the xml before java-gnome was
> happy with it. Thought I should share what I did to get it to run
>
> http://www.jroller.com/aalmiray/entry/griffon_the_quickly_connection
>
> Basically I had to follow these steps:
>
>    1. change <interface> to <glade-interface>
>    2. comment out <requires lib="gtk+" version="2.16"/>
>    3. change all <object> elements to <widget>
>    4. remove type="submenu" from every menu widget
>
> Also had to remove an image widget definition as the image filename was
> translated (erroneously) as '/tmp/background.png' instead of
> 'background.png'. Which brings me to the next point I noticed while working
> with java-gnome: it expect resources to be defined as files that can be read
> from the native side. This hinders the ability to place resources on the
> classpath (inside jars for example) and let the library picke them up.
>
> Would it be possible to have the Java wrappers expose Java friendly
> InputStream methods? Internally they can read a stream and feed the contents
> to a temporal file, then feed the file to the native code; no changes needed
> on the gtk side :-) This is actually a 'hack' I put in place on the
> griffon-gtk plugin but if won't work while reading glade files.
>
> Cheers,
> Andres
>
>
>
> ------------------------------------------------------------------------------
> The Planet: dedicated and managed hosting, cloud storage, colocation
> Stay online with enterprise data centers and the best network in the
> business
> Choose flexible plans and management services without long-term contracts
> Personal 24x7 support from experience hosting pros just a phone call away.
> http://p.sf.net/sfu/theplanet-com
> _______________________________________________
> java-gnome-developer mailing list
> jav...@li...
> https://lists.sourceforge.net/lists/listinfo/java-gnome-developer
>
>

[Java-gnome-developer] Reading Quickly glade files

[Andres A. <aal...@gm...>]

Hello devs!

I'm working on a Gtk plugin for the Griffon framework that relies on
java-gnome to do its thing (great work you guys!).
However attempts to read a glade file that was created by using Ubuntu
Quickly resulted in some manual mangling of the xml before java-gnome was
happy with it. Thought I should share what I did to get it to run

http://www.jroller.com/aalmiray/entry/griffon_the_quickly_connection

Basically I had to follow these steps:

   1. change <interface> to <glade-interface>
   2. comment out <requires lib="gtk+" version="2.16"/>
   3. change all <object> elements to <widget>
   4. remove type="submenu" from every menu widget

Also had to remove an image widget definition as the image filename was
translated (erroneously) as '/tmp/background.png' instead of
'background.png'. Which brings me to the next point I noticed while working
with java-gnome: it expect resources to be defined as files that can be read
from the native side. This hinders the ability to place resources on the
classpath (inside jars for example) and let the library picke them up.

Would it be possible to have the Java wrappers expose Java friendly
InputStream methods? Internally they can read a stream and feed the contents
to a temporal file, then feed the file to the native code; no changes needed
on the gtk side :-) This is actually a 'hack' I put in place on the
griffon-gtk plugin but if won't work while reading glade files.

Cheers,
Andres

Re: [Java-gnome-developer] Worker thread blocks on GTK methods until after inner GTK main loop quits

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

On Wed, 2010-02-03 at 22:11 +1100, Thomas Koster wrote:
> I'm having problems with worker threads blocking on
> calls to GTK methods when they are started from dialogs

Guillaume hit this a few weeks ago. See 
http://thread.gmane.org/gmane.comp.gnome.bindings.java.devel/1436
on the java-gnome-hackers list, and
https://bugzilla.gnome.org/show_bug.cgi?id=606796
There's a workaround mentioned there.

> My best guess is...

You've made some good comments; I'll have a look at the rest of your
message in the morning. We've probably got some engineering to do.

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-developer] Worker thread blocks on GTK methods until after inner GTK main loop quits

[Thomas K. <tk...@gm...>]

Greetings list,

It seems the implicit synchronization done by java-gnome has
back-fired on me.  I'm having problems with worker threads blocking on
calls to GTK methods when they are started from dialogs that run in
inner GTK main loops.  Not until the dialog is closed (and its inner
GTK main loop quits) does the worker thread resume.

My best guess is that the GDK lock is held the entire the time dialog
is running by the currently-executing button listener that shows it.
The nested call to gtk_main is used to process the result of the
dialog 'in line' in the method that invoked it, rather than resorting
to callbacks, listeners/observers or some other continuation
technique.  As you know, gtk_dialog_run works exactly like this, and
exhibits the same problem (although the worker thread would have to be
started by some other thread in this case).

For example, pseudo-code for a button that greets the user after
asking for their name follows:
    In 'Greet' button Clicked event listener:
      - show name prompt dialog
      - wait until user closes it (using nested call to Gtk.main):
resume when the dialog calls Gtk.mainQuit as it closes
      - display greeting with the given name
Note that the GDK lock is held the entire time the dialog is running.
Any other thread (in my case a worker thread started by the dialog
itself) will block on any GTK call because the lock is not released
until after the dialog closes and the button handler returns.

The question is, how do I get around this?  Without the ability to set
GTK idle callbacks in java-gnome, I am forced to access GTK objects
directly from the worker threads themselves and accept java-gnome's
synchronization scheme, which is inadequate in this scenario.  The
button handler would have to return immediately after showing the
dialog in order to release the lock, that is to *show* the dialog
rather than *run* it in GTK-speak, and the dialog would have to invoke
a callback when it is closed to effectively 'resume' whatever the
button listener was doing.  I'd rather avoid this possible - things
would start to look too much like swing again...

Thanks in advance,
Thomas

[Java-gnome-developer] UNSUBSCRIBE

[Smith, N. E C. <nic...@na...>]

UNSUBSCRIBE 

Re: [Java-gnome-developer] Adding COPYING file to the tarball

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

On Thu, 2009-12-31 at 14:20 +0100, Alexander Boström wrote:
> https://bugzilla.redhat.com/show_bug.cgi?id=551587

Packaging discussion can best be done on the -hackers list

But PLEASE don't screw around with the gtk.jar name. It doesn't matter
what the name is, but it does matter that anyone else's applications
will be expecting the library by that name.

++

> COPYING

yeah yeah :)

As it happens, I've just redone the copyright headers for another
project of mine so that Ohloh will recognize it as GPL v2. I'll be doing
the same thing over the next few days to java-gnome, presumably with the
classpath exception text
http://www.gnu.org/software/classpath/faq/faq.html#faq2_1 as well for
the distributed part of the library.

And yes, I'll include a COPYING file. :)

AfC
Sydney

Re: [Java-gnome-developer] glib fatal error using a FileChooserButton

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

On Mon, 2010-01-04 at 17:03 +0100, Guillaume Mazoyer wrote:

> today, one person reported me a bug. An exception occurred when a dialog
> which contains a FileChooserDialog is built. Here is the stacktrace:
> 
> org.gnome.glib.FatalError: GLib-CRITICAL
> g_bookmark_file_load_from_data: assertion `length != 0’ failed
> at
> org.gnome.gtk.GtkFileChooserButton.gtk_file_chooser_button_new(NativeMethod) 
> at
> org.gnome.gtk.GtkFileChooserButton.createFileChooserButton(GtkFileChooserButton.java:41)
> at org.gnome.gtk.FileChooserButton.<init>(FileChooserButton.java:57)

> I can't figure out why, this person had this error.

Guillaume and I chatted about this briefly earlier today; the crash
doesn't occur for either of us, so it's hard to say what this is.
Searching around a bit, the only other mentions of this problem seem to
be from a few years ago relating to something the Compiz specific
gtk-window-decorations helper was doing. No idea if that's relevant.

Maybe the user has a old version of GTK or GLib installed?

AfC
Sydney

[Java-gnome-developer] glib fatal error using a FileChooserButton

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

Hello (and happy new year),

I developed an application that is working great for people and me. But
today, one person reported me a bug. An exception occurred when a dialog
which contains a FileChooserDialog is built. Here is the stacktrace:

org.gnome.glib.FatalError: GLib-CRITICAL
g_bookmark_file_load_from_data: assertion `length != 0’ failed
at
org.gnome.gtk.GtkFileChooserButton.gtk_file_chooser_button_new(NativeMethod) 
at
org.gnome.gtk.GtkFileChooserButton.createFileChooserButton(GtkFileChooserButton.java:41)
at org.gnome.gtk.FileChooserButton.<init>(FileChooserButton.java:57)
at
org.gnome.split.gtk.dialog.PreferencesDialog.createSplitPage(PreferencesDialog.java:336)
at
org.gnome.split.gtk.dialog.PreferencesDialog.<init>(PreferencesDialog.java:124)
at org.gnome.split.gtk.MainWindow.<init>(MainWindow.java:122)
at org.gnome.split.GnomeSplit.<init>(GnomeSplit.java:141)
at org.gnome.split.GnomeSplit.main(GnomeSplit.java:211)

I can't figure out why, this person had this error.
Does someone know why this exception occurs?

Thank you for your help.
Cheers.

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

[Java-gnome-developer] Adding COPYING file to the tarball

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

Hello,

I'm trying to package java-gnome for Fedora. On my todo list there's a
SHOULD item about asking upstream to add the standard GPL COPYING file
to the tarball. Consider it done!

It felt off-topic on both mailing lists, really, but wth...

https://bugzilla.redhat.com/show_bug.cgi?id=551587
https://fedoraproject.org/wiki/Packaging:LicensingGuidelines#License_Text