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