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

Re: [java-gnome-hackers] Should Pixbuf constructor propegate unchecked excpetion for unknown format?

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

On Mon, 2008-06-16 at 10:01 +0000, Vreixo Formoso Lopes wrote:
> However, I wonder if somebody may be using Pixbuf for load images
> supplied by user, For example, an image viewer or picture catalog
> image may use Pixbuf for that. In those case checked is better.

Yes, that is the case I am presently encountering.

While I agree that images being loaded are under the control of the
programmer is a common scenario, loading foreign images would have to
be as common if not more so.

> Yes, that's a thing I've planned. The error code needs to be exposed,
> together with [at least] the most common error codes, as enums.

It's not even a matter of "common" so much as it is "encountered".

[Also, keep in mind that the Constants need to be registered, but there
is nothing that says they need to be public. The typed Exception being
thrown takes care of that]

AfC
Sydney

Re: [java-gnome-hackers] Should Pixbuf constructor propegate unchecked excpetion for unknown format?

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

Hi!

--- Em seg, 16/6/08, Andrew Cowie <an...@op...> escreveu:


> These crop up when, for one example, there is an
> "Unrecognized image
> file format". That certainly shouldn't be so vague
> as a
> RuntimeException, and now that I'm running into them
> I'm not entirely
> convinced it should be unchecked.
> 
> So, checked or unchecked? And, which particular exception
> for this case?
> If checked, IOException? If unchecked, the ever-trusty
> IllegalArgumentException?

Good question. The fast answer: if only programmer errors can lead to that exception, then unchecked, On the other side, if the user interaction can cause such exception, then checked, to forced programmers to catch it and report it to the user. 

The problem is that, in my apps, I always use Pixbuf for UI images that are packaged together with the application. Thus, this fits in the first case (programmer errors, maybe configuration errors in this case), and thus unchecked seems better. However, I wonder if somebody may be using Pixbuf for load images supplied by user, For example, an image viewer or picture catalog image may use Pixbuf for that. In those case checked is better.

> 
> [This is another instance where the lack of specificity of
> our wrapping
> GError is turning up. I have a feeling we need to start
> passing some
> identifiers or Constants through with error domain and the
> specific
> error enum so that the Java side code can, when the error
> is
> understandable, raise something a bit more appropriate]

Yes, that's a thing I've planned. The error code needs to be exposed, together with [at least] the most common error codes, as enums. Maybe just as static fields of GlibException. I can take care of this next days (I'm a bit busy, as always, but...).

Cheers
Vreixo



      Abra sua conta no Yahoo! Mail, o único sem limite de espaço para armazenamento!
http://br.mail.yahoo.com/

[java-gnome-hackers] Should Pixbuf constructor propegate unchecked excpetion for unknown format?

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

The checkPixbuf*() methods used by the Pixbuf constructors take the
GError and wrap it in an unchecked RuntimeException.

These crop up when, for one example, there is an "Unrecognized image
file format". That certainly shouldn't be so vague as a
RuntimeException, and now that I'm running into them I'm not entirely
convinced it should be unchecked.

So, checked or unchecked? And, which particular exception for this case?
If checked, IOException? If unchecked, the ever-trusty
IllegalArgumentException?

[This is another instance where the lack of specificity of our wrapping
GError is turning up. I have a feeling we need to start passing some
identifiers or Constants through with error domain and the specific
error enum so that the Java side code can, when the error is
understandable, raise something a bit more appropriate]

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. We actively
carry out research and development in these areas on behalf of our
clients, and enable successful use of open source in their mission
critical enterprises, worldwide.

http://www.operationaldynamics.com/

Sydney   New York   Toronto   London

Re: [java-gnome-hackers] Xlib: unexpected async reply

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

On Fri, 2008-06-13 at 22:13 +0200, Stefan Prelle wrote:
> I have a fairly complex java-gnome application which produces the
> following exception after some time:
>   Xlib: unexpected async reply (sequence 0x316e)!

I haven't seen one of those in ages.

We go to *considerable* effort to lock GDK properly and to thereby make
java-gnome transparently thread safe. See
http://research.operationaldynamics.com/blogs/andrew/software/gnome-desktop/gtk-thread-awareness.html
and
http://research.operationaldynamics.com/blogs/andrew/software/java-gnome/thread-safety-for-java.html

It is possible that we missed synchronizing in some piece of Override
code, though I tend to be careful about looking for such things.

There was previously a separate problem where a native thread not
spawned by Java would not be attached, but that was fixed in revno 486.
Vreixo pointed out that we'll also need to synchronize access to the
knownProxies collections at some point, but that probably is not your
problem either.

Another possibility is that you've hit some part of GTK that is not
properly coded to be thread aware. That would be a bug, but finding it
may prove tricky. [FileChooser was rife with them at once point, but my
understanding is that most of that was cleaned up]

... if you grep the GTK source files you're code is going through for
add_timeout or add_idle and don't see it as gdk_threads_add_timeout() or
gdk_threads_add_idle() then that's probably a concern.


> I did not add Java threads to my application, so all I did was relying
> on the threads provided by the underlying GTK+ library.

That does tend to point to the sort of problem that GtkFileChooser
[once] caused.

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. We actively
carry out research and development in these areas on behalf of our
clients, and enable successful use of open source in their mission
critical enterprises, worldwide.

http://www.operationaldynamics.com/

Sydney   New York   Toronto   London

Re: [java-gnome-hackers] Xlib: unexpected async reply

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

On Fri, 2008-06-13 at 22:34 +0200, Stefan Prelle wrote:
> Perhaps related, perhaps not, but the same application causes crashes in
> the JVM, resp. in the native GTK code.

The only thing that stands out is that you've got nested Dialogs going
on.

I didn't really expect to see someone doing that, but it shouldn't
matter in the slightest.

AfC
Sydney

Re: [java-gnome-hackers] Xlib: unexpected async reply

[Stefan P. <st...@pr...>]

Perhaps related, perhaps not, but the same application causes crashes in
the JVM, resp. in the native GTK code.

You find the logs attached. Perhaps it helps.

Stefan

[java-gnome-hackers] Xlib: unexpected async reply

[Stefan P. <st...@pr...>]

Hi all,

I have a fairly complex java-gnome application which produces the
following exception after some time:
  Xlib: unexpected async reply (sequence 0x316e)!

Before this happens I use several signal handlers (MenuItem.ACTIVATE,
TreeView.ROW_ACTIVATE, Button.CLICKED) to open dialogs, modify data and
close them again. The error usually occurs after the last dialog is
closed and only the main application window is visible.

I failed writing a stripped down application that produces the same kind
of error.

Searching around I found a posting [1] which explains that manipulating
widgets from another thread might cause this problem, unless proper care
is taken (which I don't if java-gnome does yet).  

I did not add Java threads to my application, so all I did was relying
on the threads provided by the underlying GTK+/java-gnome library.

Has anyone of you experienced something similiar before and can advise
me what might cause this issue?

Cheers,
  Stefan

[1] http://osdir.com/ml/gnome.lib.gtk+.devel.apps/2002-04/msg00203.html

Re: [java-gnome-hackers] Boxed types

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

On Thu, 2008-06-12 at 12:56 +0200, Gyetvan Andras wrote:
> Hello !
> 
> It seems to me that there is no framework implemented in java-gnome API 
> to manage boxed types.

Boxeds are used in quite a number of places already, so "no framework to
manage" is certainly incorrect.

However, there is not any infrastructure in place to allow generation of
the code to instantiate arbitrary Boxed types. That's still a bit of a
kludge.

See note 2 to
http://article.gmane.org/gmane.comp.gnome.bindings.java.devel/1090

As I said then, I'm not entirely convinced it needs more just now. There
aren't that many. If someone wants to invest the energy in changing this
part of things, then they can certainly propose their ideas to this
list.

> for example gdk_window_invalidate_rect(), 
> what I need to use, but I am unable to create a Rectangle instance.

Rectangle and Window's invalidate() have already done on the branch
where Stefan and I have been doing some TextView work. [Rectangle was
already partially done for EventExpose, but as it happens I took it all
the way to a first class object not too long ago]

I have just taken the time to cherry pick the relevant revisions off of
'textivew', most of 526 and 527. Bit of a pain in the ass, but it should
work for you. See revno 510 on 'mainline'. That should get you going and
the patch should be instructive.

AfC
Sydney

-- 
Andrew Frederick Cowie
Managing Director
Operational Dynamics Consulting, Pty Ltd

Re: [java-gnome-hackers] TextView frustrations

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

On Wed, 2008-06-11 at 21:42 -0400, Gerald Butler wrote:

> Change position of cursor within the text without regard to view, use
> the "TextBuffer" method. Place it with respect to a particular view,
> use the "TextView" method. Seems Right! No?

What it is is a pain in the ass to use.


> Do you want to move forward a logical line of text or a displayed line
> of text?

Once you know that's the way things are, this makes "sense". The problem
is one of discoverability. While we can (and will) heavily cross
reference our documentation, it is a right royal pain to have to jump
from one object to another to manipulate what is, in essence, the same
thing.

In TreeView, complex as it is, there is a clear progression; you set
things up and use one set of methods. You manipulate the view on that
data with a second set which you reach after a few hops from the first.
Yes, learning the hops is tricky (which is why I went to so much trouble
to document it) but as I look at the code I have using the TextView
stuff so far it is a right bloody mess, bouncing around all over the
place. Not intuitive, not discoverable [ie, code completion won't help
you a damn because 50% change what you're looking for isn't there. So
you've got to check both, what a pain]

That's what's bugging me.

++

The fact that it is so hard to force the cursor and the viewport to show
the end of the TextBuffer is, apparently, partially a bug in GTK, but
the java-gnome code for this was *hideous*:

TextBuffer buffer;
TextView view;
ScrolledWindow scroll;
TextIter start, end;
TextMark mark;

// populate
...

start = buffer.getIterStart();
end = buffer.getIterEnd();

// attempt to force TextView to calculate heights
buffer.placeCursor(start);

// now attempt to scroll the TextView. It may or may not work.
mark = buffer.createMark(end, false);
view.scrollToMark(mark, 0.0, 0.0, 0.0);

// now move the cursor to the end of the TextView.
buffer.placeCursor(end);


Even with the scrollTo() methods having collapsed to a series of
overrides, it's still back and forth and back and forth.
And if you're lucky, the thing will have scrolled. Working with the
Scrollbars/Ranges, Adjustments, and ScrolledWindow doesn't help either.

++

Just for comparison, I'll give you another example: I've just found out
that IconView does *not* use TreeSelection, having the selection related
methods and signals directly on IconView and not on a helper class like
TreeView has.

Either both should use a helper class, or neither. Consistency.

[So, yes, I am now vaguely considering that TreeSelection could go away.
It is, after all, "something that could have been on GtkTreeView" to
paraphrase the GTK documentation. In all likelihood we will just leave
this alone, but I *really* hate it when things aren't symmetrical and
have worked extraordinarily hard to preserve that quality in the
underlying plumbing, in the code generator, and in our public API. I
suppose there is a point where one just gives up and acknowledges that
the underlying GNOME library doesn't have the desired characteristic.
Alas.]

AfC
Sydney

[java-gnome-hackers] Boxed types

[Gyetvan A. <gye...@gm...>]

Hello !

It seems to me that there is no framework implemented in java-gnome API 
to manage boxed types.

I am using java-gnome for my hobby project and currently I stuck because 
of the lack of boxed type management. There are plenty GDK functions 
which get boxed parameter, for example gdk_window_invalidate_rect(), 
what I need to use, but I am unable to create a Rectangle instance.

Is it true that there is no way to create new boxed instance or I miss 
something ? Is there any plan, idea about this ?

Thanks,
Andras

Re: [java-gnome-hackers] TextView frustrations

[Gerald B. <ger...@gm...>]

Hi There. Just saw this. Thought I'd chime in. Here are some thoughts.....

On Wed, Jun 11, 2008 at 7:34 PM, Andrew Cowie <
an...@op...> wrote:

> Well, maybe a quarter of the way into figuring out TextView, I have to
> note that I am vastly dissatisfied.
>
> It's an ugly API. I mean, sure TreeView/TreeModel were complex, but
> powerful and you could, once you'd wrapped your mind around it, deal
> with that complexity.
>
> TextView/TextBuffer on the other hand, are underwhelming. Whether the
> cursor is visible or not is a method on TextView, but placeCursor() is a
> method on TextBuffer. Oh, except for placeCursorOnscreen(), which is
> back on TextView.
>

I've never used this API before, but, this feels and sounds correct to me.
Change position of cursor within the text without regard to view, use the
"TextBuffer" method. Place it with respect to a particular view, use the
"TextView" method. Seems Right! No?


> If you want to move a pointer forward you use TextIter's forwardLine().
> Unless you want to move it forward a line in the Widget, in which case
> it's TextView's forwardDisplayLine(). And so on.


Again, seems right. Do you want to move forward a logical line of text or a
displayed line of text? Display -> View, Logical -> Buffer. Sounds right to
me. No?


>
> Oh yeah - don't even try to make scrolling work sensibly.
>

Can't comment on this. What seems not sensible? Just curious.


>
> It's all pretty discouraging. With TreeViewColumn/CellRenderer we made a
> fairly significant API style change but one which introduced some real
> sanity to the family as a whole. I'm pretty pleased with how that worked
> out. With TextView/TextBuffer, however, I am at a bit of a loss. It
> doesn't feel right. Every time I try to use it to do something it is
> either not where I expect it to be or not there at all.
>
> So obviously I am feeling the temptation to "do something about it" but
> unlike before it is really not obvious what unifying vision would drive
> such a divergence.
>
> Even more  obviously I must be missing something, but without someone
> who *knows* GtkTextView *really* well working on this it's been a bit
> tough.
>

Wish I could be of more help here. Never really used this API.
Unfortunately, don't have any spare time right now any-who (so feel free to
tell me to pound salt ;) )


>        [I already have more than enough to drive what I wrote 4-5 years
>        ago, but then I was just displaying text, not manipulating it]
>
> To this point Stefan Prelle has been contributing boat loads, and has
> done much of the grunt work. So we're getting there. What's missing is
> the big picture
>
> Anyone who has an interest in seeing TextView coverage in java-gnome
> would probably be of great help.
>
> There has been a bit of tinkering; changing scroll_to_mark and
> scroll_to_iter into a family of scrollTo() overrides seemed to make
> sense. It didn't help that it turns out that the real
> gtk_text_view_scroll_to_iter() is *busted* and doesn't work for shit.
>
> My work is available on the branch at 'hackers/andrew/textview' branch;
> and most of Stefan's contributions are included in there. That branch is
> *NOT* anywhere near merge ready, but you can at least tinker with it.
> This isn't 'mainline'; API subject to change, etc etc.
>
> 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. We actively
> carry out research and development in these areas on behalf of our
> clients, and enable successful use of open source in their mission
> critical enterprises, worldwide.
>
> http://www.operationaldynamics.com/
>
> Sydney   New York   Toronto   London
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> java-gnome-hackers mailing list
> jav...@li...
> https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers
>
>

[java-gnome-hackers] TextView frustrations

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

Well, maybe a quarter of the way into figuring out TextView, I have to
note that I am vastly dissatisfied. 

It's an ugly API. I mean, sure TreeView/TreeModel were complex, but
powerful and you could, once you'd wrapped your mind around it, deal
with that complexity.

TextView/TextBuffer on the other hand, are underwhelming. Whether the
cursor is visible or not is a method on TextView, but placeCursor() is a
method on TextBuffer. Oh, except for placeCursorOnscreen(), which is
back on TextView.

If you want to move a pointer forward you use TextIter's forwardLine().
Unless you want to move it forward a line in the Widget, in which case
it's TextView's forwardDisplayLine(). And so on.

Oh yeah - don't even try to make scrolling work sensibly.

It's all pretty discouraging. With TreeViewColumn/CellRenderer we made a
fairly significant API style change but one which introduced some real
sanity to the family as a whole. I'm pretty pleased with how that worked
out. With TextView/TextBuffer, however, I am at a bit of a loss. It
doesn't feel right. Every time I try to use it to do something it is
either not where I expect it to be or not there at all.

So obviously I am feeling the temptation to "do something about it" but
unlike before it is really not obvious what unifying vision would drive
such a divergence.

Even more  obviously I must be missing something, but without someone
who *knows* GtkTextView *really* well working on this it's been a bit
tough.

        [I already have more than enough to drive what I wrote 4-5 years
        ago, but then I was just displaying text, not manipulating it]

To this point Stefan Prelle has been contributing boat loads, and has
done much of the grunt work. So we're getting there. What's missing is
the big picture

Anyone who has an interest in seeing TextView coverage in java-gnome
would probably be of great help.

There has been a bit of tinkering; changing scroll_to_mark and
scroll_to_iter into a family of scrollTo() overrides seemed to make
sense. It didn't help that it turns out that the real
gtk_text_view_scroll_to_iter() is *busted* and doesn't work for shit.

My work is available on the branch at 'hackers/andrew/textview' branch;
and most of Stefan's contributions are included in there. That branch is
*NOT* anywhere near merge ready, but you can at least tinker with it.
This isn't 'mainline'; API subject to change, etc etc.

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. We actively
carry out research and development in these areas on behalf of our
clients, and enable successful use of open source in their mission
critical enterprises, worldwide.

http://www.operationaldynamics.com/

Sydney   New York   Toronto   London

Re: [java-gnome-hackers] [Java-gnome-developer] missing cairo bits?

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

Hi!

--- Em sáb, 31/5/08, Andrew Cowie <an...@op...> escreveu:

> (I know that Vreixo worked a little bit on the Pango
> rendering of text
> glyphs; not sure where that got to or if it is anywhere
> near merge
> ready)

it needs still some work before merging, but it will be a pity to start again from scratch, so I will try to push my work online.

Cheers
Vreixo

PS: I'm a bit busy these days, so don't expect more work on that branch next two weeks. I hope to work on that again around 15th...


> 
> AfC
> Sydney-------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/_______________________________________________
> java-gnome-hackers mailing list
> jav...@li...
> https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers


      Abra sua conta no Yahoo! Mail, o único sem limite de espaço para armazenamento!
http://br.mail.yahoo.com/

Re: [java-gnome-hackers] [Java-gnome-developer] missing cairo bits?

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

On Fri, 2008-05-30 at 20:57 +1000, Zak Fenton wrote:
> If not, I'm happy to fill in the gaps.

Go right ahead.

If you know what you need and figure you can describe it well, then you
ought to do well.

(I know that Vreixo worked a little bit on the Pango rendering of text
glyphs; not sure where that got to or if it is anywhere near merge
ready)

AfC
Sydney

Re: [java-gnome-hackers] Problem with bindings generator

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

On Wed, 2008-05-28 at 22:48 +0200, Stefan Prelle wrote:
> 	// translate return value to JNI type
> 	_result = (jintArray) NULL;

Hm. That's interesting (and doesn't look quite the way I'm used to
writing that comment).

The code that outputs that is in FunctionGenerator. If you run:

$ bzr gannotate src/generator/com/operationaldynamics/codegen/FunctionGenerator.java

and look around line 592, you'll see where that came from. Looks to be
some that Vreixo added to when doing work that changed our memory
cleanup.

Anyway, the relevant line is 597; if I had to guess I'd say that the
jniReturnEncode() function for whatever type is actually being processed
[you said int[], right? If so, that'd be something *Array*] either
hasn't been overridden or has been overridden incorrectly.

AfC
Sydney

-- 
Andrew Frederick Cowie
Managing Director
Operational Dynamics Consulting, Pty Ltd

Sydney    +61 2 9949 1885
New York  +1 646 472 5054
Toronto   +1 647 477 5603
London    +44 207 1019201

We are an operations engineering consultancy focusing on strategy,
organizational architecture, systems review, and change management
procedures: enabling successful use of open source in mission
critical enterprises, worldwide.

http://www.operationaldynamics.com/

Re: [java-gnome-hackers] contribute

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

On Wed, 2008-05-28 at 19:43 +0200, Gyetvan Andras wrote:
> My wife and I are hobby photographers, so I have a lot of digital 
> images. What I did not find in GNOME is a good Photo Album Manager, 
> which can handle thousands of pictures and has an intuitive UI, good 
> features

User Interface is a difficult topic. The base GUI code isn't that hard
to write, but developing something that has a discoverable interface can
be very demanding indeed.

The issue is complicated by the fact that what is a sound UI for one
person is completely unintuitive for another.

Most of all, however, is that there is a big difference between writing
something that supports your own workflow amazingly well, and trying to
write a generic program that attempts to satisfy everyone and pleases no
one in the process.

> I am using 
> JAVA to implement "business logic" and Gtk+ for the UI. This is why I 
> use java-gnome.

Yup.

> I found that there is a lot of "placeholder" classes in bindings where a 
> lot of methods are missing. It is easy to add them and I already 
> extended a few. So far I finished/extended the following classes :

Well. That sounds promising.

Since you expressed an interest in contributing, I can mention some of
the things you'll have to do if you want to get branches merged into
java-gnome.

By design, accessing the native libraries care of the generated
translation, native and JNI layers is very straight forward. As long as
you clearly understand the architecture behind things, you generally
don't need to worry about it. This allows us to focus on the important
part: the design of our public API and the documentation thereof.

The bottom line is that, like most projects, there is a very clearly
established style in place. This applies to cosmetic factors like coding
style, source formatting, documentation formatting and *especially*
documentation content.

In particular *DO NOT* cut and paste API documentation from the GTK or
Cairo or etc manuals. The GTK documentation is frequently ...
incomplete. It discusses things that do not apply to someone developing
in a memory managed language, and most of it is written in a reference
style, assuming that you more or less know what you're talking about.
And to quote Carl, "the API documentation for Cairo is not accurate".
The archives of last 3-5 years of mailing lists like gtk-list are
excellent sources of information, as people often drop behavioural
tidbits that everyone should be aware of - just the sort of thing that
should be in java-gnome's JavaDoc.

> Probably it is obvious that I touching classes in order as I need them 
> in my project.

(That's good - I never understand people who want to contribute things
that they aren't actually using or know anything about)

> Finally, I have to tell that I have never ever joined to this kind of 
> community, so I do not know the rules.

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. We actively
carry out research and development in these areas on behalf of our
clients, and enable successful use of technology in their mission
critical enterprises, worldwide.

http://www.operationaldynamics.com/

Sydney   New York   Toronto   London

[java-gnome-hackers] Problem with bindings generator

[Stefan P. <st...@pr...>]

Hi all,

I just stumbled over something in the generated source code for
GtkTreePath.c

1. GtkTreePath.getIndices(TreePath) always returns null
========================================================
The method 

JNIEXPORT jintArray JNICALL
Java_org_gnome_gtk_GtkTreePath_gtk_1tree_1path_1get_1indices

is supposed to return an integer array. Calling it from GtkTreePath.java
only returned a NullPointer. Inspecting the code I found
	// translate return value to JNI type
	_result = (jintArray) NULL;
which I think explains my problems :)
So, question number 1: Why was the line generated that way?

2. Modified GtkTreePath.getIndices(TreePath) succeeds,
   but later int array usage emits NullPointerException
========================================================
When I change the line to
	_result = (jintArray) result;
the application crashes. JUnit tests for TreePath.getIndices() fail
in the third line of the following code:
        int[] ind = path.getIndices();
        if (ind==null) System.out.println("Indices are null");
        System.out.println(ind);
with the following message:
  Encoutered an error at ValidateTreeStore.java:430
  The following exception was thrown:

     java.lang.NullPointerException

  Normally exceptions in unit tests are trapped and reported as
  failures;
  this was unexpected. It could be a bug or something deeper with your
  environment or setup.

Running the test in Eclipse gives a stacktrace that reveals that the
NullPointer originates in java.lang.String.valueOf(Object) in the one
and only line
    public static String valueOf(Object obj) {
	return (obj == null) ? "null" : obj.toString();
    }

The only chance that this can produce a NullPointerException is
Object.toString() failing on the int array.

My only idea is that the int[] returned from get_indices has been
cleaned up in the meantime.

So question 2. is simply for ideas on this

[java-gnome-hackers] contribute

[Gyetvan A. <gye...@gm...>]

Hello All !

Let me introduce myself : my name is Andras Gyetvan, I am from Hungary.

I would like to contribute to java-gnome. My payed job is to be R&D VP, 
I am a leader of development team which makes software for PM and ASC 
systems. Our project is written in pure JAVA, using Swing for UI. Our 
main target OS is Windows.

Yes, you can ask, why I interested in java-gnome ? It is because I use 
Linux/GNOME at home and at work.

My wife and I are hobby photographers, so I have a lot of digital 
images. What I did not find in GNOME is a good Photo Album Manager, 
which can handle thousands of pictures and has an intuitive UI, good 
features - similar to PicaJet on Windows. (I do not like to use KDE, Qt, 
etc. on my GNOME system)

So I started to develop this application as my hobby project. I am using 
JAVA to implement "business logic" and Gtk+ for the UI. This is why I 
use java-gnome.

I found that there is a lot of "placeholder" classes in bindings where a 
lot of methods are missing. It is easy to add them and I already 
extended a few. So far I finished/extended the following classes :
- org.gnome.gdk : Drawable, Pixbuf, PixbufRotation.
- org.gnome.gtk : Container, DrawingArea, IconView, Image, Layout, 
Paned, Widget

(Yes, it is not too impressive list, but please keep in  mind that I 
started to work on it a week ago.)

Probably it is obvious that I touching classes in order as I need them 
in my project. Currently I am focusing on DrawingArea and drawing.

I do not know if this kind of contribution will fit in your development 
scenario, anyway I would be happy to share them with you.

Finally, I have to tell that I have never ever joined to this kind of 
community, so I do not know the rules.

Andras

[java-gnome-hackers] Voodoo in TextView

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

Just FYI, I've been hammering away on a fringe part of the TextView API,
see http://bugzilla.gnome.org/show_bug.cgi?id=534308
and http://article.gmane.org/gmane.comp.gnome.gtk%2B.general/18960

It's pretty crazy stuff. Mostly I've just been flailing about, but I
made some progress. I'll see about getting some of the more useful bits
polished up and committed in the next few days.

One things I'm totally clueless on, though, are the meanings of
GtkScrollType as used by some of the Scrolling things:
http://library.gnome.org/devel/gtk/stable/gtk-Standard-Enumerations.html#GtkScrollType 

and then how that all relates to the GtkMovementStep constants
http://library.gnome.org/devel/gtk/stable/gtk-Standard-Enumerations.html#GtkMovementStep

those show up in the MOVE_CURSOR signal on TextView. Then there is the
MOVE_VIEWPORT signal, which doesn't seem to do anything at all. It's all
fairly confusing.

Like I said, I'll commit what of this I can; there will be a lot of
TODOs (not something I normally like to leave in when committing things)
and more to the point there's a fair bit of stuff that I'm not sure we
need. If anyone is interested in helping get in touch and we can see if
we can figure it out.

AfC
Sydney

Re: [java-gnome-hackers] GTK, DisplayManager and multihead X

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

--- Em qua, 21/5/08, Andrew Cowie <an...@op...> escreveu:

> Vreixo suggested something like "UnknownSurface"

Not really! My approach is to use as proxy the nearest parent we have a proxy for. For example, if in GStreamer we don't have a proxy for a given plugin that provides, for example, a XXXElement, we just proxy it as a GstElement.

While not so good solution as having the concrete type proxied, it makes our bindings work properly, and at the same time it hides implementation details we actually don't need to expose. 

>  I'd
> rather just see
> the bindings improve when people need them to.

This is not a good idea for things like GStreamer, where users can install 3rd party plugins. While it may be (it is) a good idea to add coverage for common plugins, it would be really bad to have a bindings architechture that doesn't work for "all" plugins...

The "use parent proxy if actual type is unknown" approach works ok, and it is type safe, it just hides implementation details. In cases where those implementation details need to be exposed, then adding the missing coverage is the only solution, but it works ok as a general purpose approach.

Cheers
Vreixo



      Abra sua conta no Yahoo! Mail, o único sem limite de espaço para armazenamento!
http://br.mail.yahoo.com/

Re: [java-gnome-hackers] Back to life.

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

On Sat, 2008-05-17 at 18:13 +0200, Mauro Galli wrote:
> Hi out there,
> 	after a a long year I come back from death (literally) 

Well, far more important than anything else is to give thanks that
you're feeling better, and to welcome you back to our humble little
community.

> and I start to
> look around to understand what's happened around me in the last eleven
> months. I don't want to read all the mail from java-gnome

No, it's not really the sort of mailing list you catch up on. I do tend
to refer people to specific messages from time to time, but much of the
traffic is problem solving, and, of course, we often switch to IRC and
or direct email.

Certainly, though, do have a read of the NEWS file. Based on the last
email you sent along, it really has been a year. So that puts you at
roughly release 4.0.3, which you can read here:

http://java-gnome.sourceforge.net/4.0/NEWS.html#4.0.3

then on with:

http://java-gnome.sourceforge.net/4.0/NEWS.html#4.0.4
http://java-gnome.sourceforge.net/4.0/NEWS.html#4.0.5
http://java-gnome.sourceforge.net/4.0/NEWS.html#4.0.6
http://java-gnome.sourceforge.net/4.0/NEWS.html#4.0.7

that should bring you up to date with what has been going on broadly.
And just as importantly, check out the AUTHORS file: we really have had
awesome growth in people interested in the project:
http://java-gnome.sourceforge.net/4.0/AUTHORS.html

You might also have a glance at the code at:
http://java-gnome.sourceforge.net/4.0/doc/examples/START.html


> Have someone looked to the equivalence system in the last year?

I have been working on it quietly, though I keep getting distracted by
more important things - like trying to find someone to fund my work on
all this great and wonderful stuff.

[Frankly, I need to do a conference presentation on the topic of Java
launching - it is getting to be too much material to write in a single
email.

It's also somewhat off-topic for this list, as java-gnome is but one
user of the thing. But we can discuss it here if others are also
interested in the problem of configuring Java programs to run on Linux
and Unix systems]

++

Again, it's great to hear from you.

AfC
Sydney

Re: [java-gnome-hackers] GTK, DisplayManager and multihead X

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

Hey Stefan,

On Sun, 2008-05-18 at 14:25 +0200, Stefan Prelle wrote:
> 1. When requesting a list of displays from the DisplayManager
>    I got the message that there is no mapping for 'GdkDisplayX11'

The workaround is the same as for GdkScreenX11; see
org.gnome.gdk.Plumbing and add a registerType() call there for the case
you're running up against.

In the medium term, I'm not in a huge rush to see this class of problem
go away. An error that results from us not having coverage of something
means that someone should probably write coverage of it if they need it.
Certainly this has driven a lot of activity to date.

        (oh, you want a signal that uses something called
        GtkMovementStep that has no constants registered for it yet?
        Hey! Guess what? Maybe it's time you researched it and wrote up
        some coverage for it. I dealt with that one today)

Over all, the real issue is preserving strong typedness. This applies
both to the "what do I do if I don't have a concrete subtype for this
yet" and also applies to plugins. If we know a give type of capability
will be built in or is likely to be built in, then create a concrete
subclass for it already. org.freedesktop.cairo.Surface and
org.gnome.gdk.PixbufFormat come to mind.

Anyway, yes, long term we'll want to "do" something about the case where
an instance shows up that we don't have a concrete Proxy type for. It's
not really that clear to me what shape that should take.

Vreixo suggested something like "UnknownSurface" and what not. That
might work, but I'm not really in a rush to create an Unknown concrete
subclass of bloody everything, especially when roughly the same effort
would just see the necessary public coverage added. I'd rather just see
the bindings improve when people need them to.

AfC
Sydney

Re: [java-gnome-hackers] GTK, DisplayManager and multihead X

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

> I was experimenting with multiheaded display support for
> java-gnome.
> For this purpose I wrote coverage for
> org.gnome.gdk.DisplayManager and
> org.gnome.gdk.Display.
> 
> I ran into two problems. One may be missing understanding
> on the
> java-gnome internals, the other may be X/GTK related.
> 
> 1. When requesting a list of displays from the
> DisplayManager
>    I got the message that there is no mapping for
> 'GdkDisplayX11'
>    in the typeMapping.properties. So just for testing I
> changed
>      GdkDisplay=org.gnome.gdk.Display
>    to
>      GdkDisplayX11=org.gnome.gdk.Display
>    which seemed to work.
>    What would be the correct way to add this mapping?

mmm, this seems to be the same problem I get with GStreamer. One thing is the API object we map (GdkDisplay) and another the concrete implementation in a given environment (GdkDisplayX11). My solution was to modify our mapping code to find a proxy of parent type if a direct mapping can't be found. But it is still experimental code, so I cannot recommend it to you.

Cheers,
Vreixo


      Abra sua conta no Yahoo! Mail, o único sem limite de espaço para armazenamento!
http://br.mail.yahoo.com/

[java-gnome-hackers] GTK, DisplayManager and multihead X

[Stefan P. <st...@pr...>]

Hi all,

I was experimenting with multiheaded display support for java-gnome.
For this purpose I wrote coverage for org.gnome.gdk.DisplayManager and
org.gnome.gdk.Display.

I ran into two problems. One may be missing understanding on the
java-gnome internals, the other may be X/GTK related.

1. When requesting a list of displays from the DisplayManager
   I got the message that there is no mapping for 'GdkDisplayX11'
   in the typeMapping.properties. So just for testing I changed
     GdkDisplay=org.gnome.gdk.Display
   to
     GdkDisplayX11=org.gnome.gdk.Display
   which seemed to work.
   What would be the correct way to add this mapping?

2. I have a dual headed workstation with Xinerama. GTK identifies
   this as 1 display with 1 screen ":0.1" (2560x1024).
   When I use the Java Swings GraphicsEnvironment/GraphicsConfiguration
   this is identified as 2 screens ":0.0" and ":0.1" (1280x1024).

   When testing to open applications on a specific screen, it looks
   like I really do have one screen when it comes to X.
   "xterm -display :0.0" works, "xterm -display :0.1" doesn't.

   I hoped I would get java-gnome to behave like Swing, which allows me
   (in my setup) to decide on which monitor a window shows up.
   Any idea what I can do? How can I tell X/GTK that I do have multiple
   screens on my display?

If you want to try it out, I attached a patch against the mainline and
an additional test program.

Regards,
  Stefan

[java-gnome-hackers] Back to life.

[Mauro G. <ma...@lo...>]

Hi out there,
	after a a long year I come back from death (litterally) and I start to
look around to understand what's happend around me in the last eleven
months.

I don't want to read all the mail from java-gnome, I don't want to loose
onther year doing this, so I have a question:
Have someone looked to the equivalence system in the last year? I can
start again to give an hand, if it is necessary, where can I find
everything?
Mauro