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] 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
>
>

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...>]

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

[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

[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

[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