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

Re: [Java-gnome-developer] How do you fire an event on the main Gtk thread?

[Alexey T. <a_t...@ma...>]

> If I am processing some logic on a background thread and want to exec
> asynchronously some event on the main GTK+ thread, how can I do that in
> java-gnome?
> 
> In Swing, you use SwingUtilitilies.invokeLater(Runnable) for this.
> In SWT, it's Display.asyncExec(Runnable).
> 
> What is the equivalent API for Java-Gnome?
> 
> P.S. A typical usage is for propertyChange events in JavaBeans...if any UI
> element listens to them, it's logic should (usually) only be invoked on the
> main thread.
> 
Hello. I think this is very important feature. Can developers explain how to do this?

[Java-gnome-developer] How do you fire an event on the main Gtk thread?

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

If I am processing some logic on a background thread and want to exec
asynchronously some event on the main GTK+ thread, how can I do that in
java-gnome?

In Swing, you use SwingUtilitilies.invokeLater(Runnable) for this.
In SWT, it's Display.asyncExec(Runnable).

What is the equivalent API for Java-Gnome?

P.S. A typical usage is for propertyChange events in JavaBeans...if any UI
element listens to them, it's logic should (usually) only be invoked on the
main thread.

-- 
View this message in context: http://www.nabble.com/How-do-you-fire-an-event-on-the-main-Gtk-thread--tp21128584p21128584.html
Sent from the Gnome - Java Binding - General mailing list archive at Nabble.com.

[Java-gnome-developer] Custom layout management?

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

Could someone point me to some code samples of custom layout management (i.e.
overriding the base behavior of let's say VBox to do your own layout)? I
presume it can be done, but I'm not sure how to go about it.

Thanks in advance....
-- 
View this message in context: http://www.nabble.com/Custom-layout-management--tp21090358p21090358.html
Sent from the Gnome - Java Binding - General mailing list archive at Nabble.com.

Re: [Java-gnome-developer] Creating custom container

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

I was looking at the gtkmm docs on how they do custom containers and it
seems that they can do it:

http://www.gtkmm.org/docs/gtkmm-2.4/docs/tutorial/html/chapter-customwidgets.html#sec-custom-containers

So there is probably a way to accomplish this from the Java side as
well.....Jacek

Re: [Java-gnome-developer] Creating custom container

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

Andrew, thanks for your response.

If I subclass a different class than container, how do I override its
default layout management logic so that I can do it myself?

Let me maybe explain what I want to do: my end goal is to port the amazing
Swing/SWT MigLayout layout manager to run on GTK+ (java-gnome actually,
since it's a pure Java library). MigLayout is UI toolkit agnostic and needs
only 3 classes to implement the toolkit-specific logic.
http://www.miglayout.com

So, since GTK+ does not have the concept of a layout manager, but just
specialized containers with hardcoded layout management logic, I want to
create something like a MigLayoutContainer, e.g.

MigLayoutContainer c = new MigLayoutContainer("wrap 4","[pref] [grow] [pref]
[pref]");

c.add(new Button(), "sg 1");
c.add(new Button(), "sg 1");

This code above would create a container that automatically wraps to the
next row every 4 controls that are added. Columns 0, 2, 4 have the preffered
control width, while column 1 resizes as the window resizes. The two buttons
that were added would automatically have the same size (width/height)
because they belong to the same size group.

So, if I subclass a different GTK+ component, what do I need to do to
override its layout management logic and implement my own from scratch?

This is what I am trying to do.

Don't get me wrong, GTK+ is an impressive toolkit, but their approach to
layout management (Vbox. HBox, Table) is rather outdated compared to the
best alternatives in both the Java and .Net world.

Thanks, Jacek

P.S. Some more info about me: I am the creator of the Java SwingBuilder and
SWTBuilder, two libraries that aim to maximize Java UI development
productivity by allowing declarative UI building in YAML:
http://javabuilders.org

My end goal is to port my library to run on top of java-gnome as well to
bring the same productivity enhancements to creating native GTK+ apps in
Java (since I am an avid Linux user and am saddened by the lack of Java apps
on Linux...I think we're getting beaten badly in this area by Python and
even Mono these days).

Thanks for any assistance or guidance you may give me, much appreciated in
advance.

Re: [Java-gnome-developer] Creating custom container

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

On Wed, 2008-12-17 at 19:49 -0500, Jacek Furmankiewicz wrote:

> I've subclassed Container

So it's a fairly deliberate design decision that things that are
abstract in the underlying library are abstract in java-gnome (I mean,
duh, right?).

That said, even if they weren't, you'd still be saddled with all the
hassle of setting up the machinery to allocate resources and what not.
So, as it stands right now,

> , but the parent constructor expects a long pointer. How do I generate
> one?
> 
You don't.

        (Java desperately needs another visibility modifier: "library";
        the problem with protected is that while that's fine for our
        internal use going from org.freedesktop.bindings to
        org.gnome.glib and on to org.gnome.gtk, it's bloody horrible
        that a developer can in turn subclass and then see something
        that is library internal. I've long toyed with ways to get
        around this, but nothing non-absurd and non-creating a
        subordinate object has come to mind)

Anyway, the solution (or workaround, depending on your taste) is so
obvious that you'll kick yourself: just subclass Button, or HBox, or
Image or Label, or...

I grant you it's not the "perfect" solution, but in practice anything
I've found myself creating is actually a Button or "a bunch of stuff
laid out horizontally" or an Image or a Label, or ... so that's what
I've subclassed. Works out pretty well.

[An example of where I used HBox is here.
http://research.operationaldynamics.com/projects/objective/files/ForeignAmountEntryBox.png
Just a bunch of Entries that reacts to changes in each other,
recalculating as necessary. Packing all the Entries, Labels and the
Combo (which was itself a custom subclass wired up for the domain
specific purpose) into an HBox made the whole thing quite neat - and the
end result is (still) a Widget that was subsequently instantiated as
needed and added to other Containers doing such foreign currency work]

Very long term, the way to address this is a package visible factory
method somewhere that takes care of the allocation and setup issues
underneath creating such a generic Container parent. But I haven't
needed to do so in something like 50,000 lines of code using java-gnome,
so I respectfully submit that it isn't urgent. That said, if there is
some reason you really really need to do it directly, then I'm sure we
can figure something out. There is indeed an elegance violation in
subclassing HBox instead of Container, but on the other hand, the fact
that GtkTreeView subclasses GtkContainer and then doesn't actually work
as a GtkContainer is a bit rude, and GtkLabel extends GtkMisc, which is
quite possibly the stupidest name for an intermediate class I've ever
seen, especially given GtkMisc's actual role and the container /
non-container split in the GtkWidget hierarchy. Alas.

AfC
Sydney

[Java-gnome-developer] Creating custom container

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

Hi, I want to create a custom Container.

I've subclassed Container, but the parent constructor expects a long
pointer. How do I generate one?

I see the other Containers use a static .createWhateverType() method from
the base Gtk JNI classes, but I do not see the equivalent
GtkContainer.create... method.

Thanks for any help (I am new to GTK+ development, but very interested).

Jacek

Re: [Java-gnome-developer] Updating sorted TreeModel

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

On Thu, 2008-12-11 at 23:35 +0100, Przemyslaw Wesolek wrote:
> What I meant is that your solution (wrapping models) works smoothly, but
> it's not a straight-forward idea -- at least for me.

Well, that's what GTK provides as it's mechanism for doing these things,
so there's not a whole lot we can do about changing that. I personally
find the whole TreeModelSort thing a bit cumbersome, but that's what we
have to work with.

> unexpected behavior of iteration process when changing the model,

That, on the other hand, is something we can attempt to address.

If you can suggest what to say in the documentation instead of what is
there now, then we can certainly change it to prevent people like you
having such misconceptions in the future.

See HACKING for how to submit a patch with your proposed improvements.

Cheers!

AfC
Sydney

Re: [Java-gnome-developer] Updating sorted TreeModel

[Przemyslaw W. <pw...@o2...>]

Andrew Cowie wrote:
> I'm sorry,
> 
>> That's right, works smoothly.
> 
> and
> 
>> Hm, hard to say if it is a bug or not
> 
> don't go together.
> 
> What's the problem?

What I meant is that your solution (wrapping models) works smoothly, but
it's not a straight-forward idea -- at least for me.

For me the main problem -- call it a bug or a feature request :) -- was
the unexpected behavior of iteration process when changing the model,
not mentioned in java-gnome or GTK+ API. So if documentation
comprehensiveness is considered, it would be nice to mention such
iteration breakage possibility around TreeIter.

Przemek

Re: [Java-gnome-developer] Updating sorted TreeModel

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

I'm sorry,

> That's right, works smoothly.

and

> Hm, hard to say if it is a bug or not

don't go together.

What's the problem?

AfC
Sydney

Re: [Java-gnome-developer] Updating sorted TreeModel

[Przemyslaw W. <pw...@o2...>]

Andrew Cowie wrote:
> On Wed, 2008-12-10 at 16:03 +0100, Przemyslaw Wesolek wrote:
>> I'm having troubles updating TreeModel, which is sorted: whenever I
>> update a value in the column by which the model (view?) is sorted, the
>> re-ordering happens and I have no guarantee that all the rows will be
>> iterated over. Moreover, some rows may be iterated more than once.
> 
> So this might fall into the category of "putting the wrong TreeModel in
> the TreeView"?
> 
> If you're using a TreeModelSort to wrap a ListStore, you put the
> TreeModelSort into the TreeView.

That's right, works smoothly.

To summarize:
1) Create your model
2) Create TreeModelSort wrapping your model
3) Connect wrapping model to the view
4) Propagate your model changes on the underlying model

> [at least, I've had no problem with it; I did have a case once where the
> data displayed in the TreeView would wobble a bit as I was updating all
> the rows because the sorting values were not unique, and so it sometimes
> flip-flopped a bit when confronted with equal values]

This is not a big problem for me; my first idea was to synchronize on
Gdk.lock before changing the model, maybe this would help (if TreeView
is updated in main loop)?

> Anyway, if you're still stuck you'll need to show us your code (more to
> the point, to boil your problem down to code that someone can
> comprehend, or better yet, if it's really a bug, write a TestCase that
> can go into the test suite).

For sure it is the case you described.

Hm, hard to say if it is a bug or not... For me, it is API and reality
incompatibility (i.e. iterating over the model misses some rows).

Thanks a lot,
Przemek

Re: [Java-gnome-developer] Updating sorted TreeModel

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

On Wed, 2008-12-10 at 16:03 +0100, Przemyslaw Wesolek wrote:
> I'm having troubles updating TreeModel, which is sorted: whenever I
> update a value in the column by which the model (view?) is sorted, the
> re-ordering happens and I have no guarantee that all the rows will be
> iterated over. Moreover, some rows may be iterated more than once.

So this might fall into the category of "putting the wrong TreeModel in
the TreeView"?

If you're using a TreeModelSort to wrap a ListStore, you put the
TreeModelSort into the TreeView.

Iterating over the underlying ListStore should, however, remain fine;
changes to the sort discriminator won't affect your ability to finish
looping over the model.

[at least, I've had no problem with it; I did have a case once where the
data displayed in the TreeView would wobble a bit as I was updating all
the rows because the sorting values were not unique, and so it sometimes
flip-flopped a bit when confronted with equal values]

Anyway, if you're still stuck you'll need to show us your code (more to
the point, to boil your problem down to code that someone can
comprehend, or better yet, if it's really a bug, write a TestCase that
can go into the test suite).

AfC
Sydney

[If you can't publish your code, then there are other ways of
approaching the issue which we can deal with privately]

-- 
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] Updating sorted TreeModel

[Przemyslaw W. <pw...@o2...>]

Hi all,

I'm having troubles updating TreeModel, which is sorted: whenever I
update a value in the column by which the model (view?) is sorted, the
re-ordering happens and I have no guarantee that all the rows will be
iterated over. Moreover, some rows may be iterated more than once.

I found a message from Andrew on java-gnome-hackers, which points the
same bug
(http://article.gmane.org/gmane.comp.gnome.bindings.java.devel/1062):

=====
I'll wait to so see what Srichand thinks of this, but I really don't
think we should put this stuff on TreeIter. We moved one method only to
TreeIter and that was just to make cycling over a model work.*

The three methods you are proposing to add above are specialities of
TreeStore and really do belong there (actually, they are part of the
TreeModel interface, so the open question is whether you ever need the
hierarchy methods on a model that is not a TreeStore), and not on TreeIter.

[* and even that's sketchy: I am hitting a bug this week where a
TreeModel is failing to update because I am making changes to something
which affects the sort order while looping over a model's data. I should
know better]
=====

Any hints on how to achieve this? I'm using java-gnome 4.0.9 on Debian
Lenny.

Przemek

Re: [Java-gnome-developer] Hello ... and thank you !

[Charles-H. d'A. <cda...@gm...>]

Hi Andrew,

Thank you very much for your answer.

> ...
> So I'm actually developing again, and THAT has been great fun. I'm in
> the same boat as everyone else: lots of works-in-progress which may - or
> may not - ever see the light of day as popular public projects.
> ...

I hope you did not misunderstood my message. The main purpose was to
congratulate and thanks the developers of java-gnome, not to point out
that there are not many popular application using it.
I am totally aware that java-gnome 4.0 is a recent project and I have
no doubt, as mentioned, that in a short term there will be plenty of
great applications java-gnome based.


> java-gnome should build find on Mandriva...

Indeed it does and making a rpm spec file for it was really easy.


> If Mandriva actually have a reliable way to locate and identify an
> installed JVM and tool suite (ie, its location is a matter of Policy)
> feel free to make the changes and submit a branch (java-gnome-hackers
> will be a good list to discuss such things if you wish; patches can be
> sent there or to me direct). I *do* appolgize for the unweildy size
> of ./configure as it stands right now, but it does embody a great deal
> of knowledge and that's what matters for the moment. Oh yeah, and it
> works :)
>
> Until then, really, there's actually no harm in a distro package
> specifying jdk= to ./configure. Sure, it's nice when it's just picked up
> automatically, and that's what we aim for (makes developers' and
> hackers' lives better) but if not, well, that's what that the override
> is there for.

I will investigate and contact Mandriva's developers to have more
information about how to locate installed JVM and JDK.
Be sure I will submit a patch for this as soon as I found out more on
this subject.

Cheers,
Chicha.

Re: [Java-gnome-developer] Hello ... and thank you !

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

On Tue, 2008-11-25 at 10:31 +0100, Charles-Henri d'Adhémar wrote:
> I am Charles-Henri d'Adhemar from Nice

Salut Charles-Henri.

> I do not know of a
> single application made using java-gnome,

For various reasons, the Java bindings have long been used by people for
in-house projects. I have seen quite a number of non-trivial apps that
have been written using java-gnome.

The re-engineered java-gnome 4.0 is a young library that has only
recently reached maturity. It takes an equally long time to develop a
serious application to the point where it is complete and worthy of use
by end-users.

I do know of a number of people working on interesting projects, and so
perhaps in the next year or two we will see some significant works
gaining noteriety.

Until then, if people experiment, learn, and then decide to take what
they've learned and invest it in a new project without having "finished"
the old one, that's fine by me. I know their invested effort will pay
off for them - and for all of us - in due course.

I don't lose too much sleep comparing what we do here to other
languages. Some of those bindings have been around for well over a
decade; others have 10s of people being paid full time to work on them.
{shrug} good for them.

What matters is the quality of the work we do and then using that work
to accomplish things that are significant for us as individual
contributors. java-gnome as at 4.0.9 is something I'm very proud of.
There's almost nothing in the library that I, or people whom I've come
to trust, haven't actually *used* to develop *something* with, one way
or another. As I've said elsewhere, java-gnome now does almost
everything I could possibly want it to; there are a still many areas
that I'd like to see coverage for yet, but I have virtually everything I
need to get back to work on the things I put on hold two years ago.

So I'm actually developing again, and THAT has been great fun. I'm in
the same boat as everyone else: lots of works-in-progress which may - or
may not - ever see the light of day as popular public projects.

++

But since you asked, I can point you at one tiny app that I wrote:
http://research.operationaldynamics.com/projects/slashtime/

Barely above trivial it may be, but it has the virtue of a long history
and actually being "complete". [The only thing it's not is an applet,
but that's a topic for another day] It's packaged on Gentoo, and I've
seen it run fine on Debian and Ubuntu, among others.

Serkan Kaba and I recently did the work to internationalize the
Slashtime; it has fr_CA and tr_TR translations now.

I released that work as version 0.5.9 today, in fact. Maybe it's time I
blogged about it.

++

> ... home made build system, "Equivalence" ...  but I do not want to use
> autotools ...

I'll respond about that separately, but long story short, I
*desparately* want to get my attention back to working on Equivalence so
that it's nice and usable for everyone - including me! - for other
projects.

It actually started life for another codebase, back when it was *really*
hard to find Java on a Linux box; java-gnome 4.0 was about the 6th
project to use it. But copying and pasting it around is, of course,
rediculous. As I said, it's something I've been meaning to refactor for
a long time.

I've been a bit distracted by, well, working on java-gnome :)

++

> - I use Mandriva 2009.0 

java-gnome should build find on Mandriva... 

> only thing which is not right is that I have to hardcode the path to
> the jdk on the ./configure line because it is not detected.

If Mandriva actually have a reliable way to locate and identify an
installed JVM and tool suite (ie, its location is a matter of Policy)
feel free to make the changes and submit a branch (java-gnome-hackers
will be a good list to discuss such things if you wish; patches can be
sent there or to me direct). I *do* appolgize for the unweildy size
of ./configure as it stands right now, but it does embody a great deal
of knowledge and that's what matters for the moment. Oh yeah, and it
works :)

Until then, really, there's actually no harm in a distro package
specifying jdk= to ./configure. Sure, it's nice when it's just picked up
automatically, and that's what we aim for (makes developers' and
hackers' lives better) but if not, well, that's what that the override
is there for.

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] Hello ... and thank you !

[Charles-H. d'A. <cda...@gm...>]

Hello every body !

This a not so short mail to introduce myself on this mailing list and
to say thank you for your amazing work.

I am Charles-Henri d'Adhemar from France (Nice) but people often call me chicha.
I am a developer working in IT technologies in the travel industry.
I have been participating in some Free Software projects more or less
actively depending on my life evolution (student with lots of time to
family man with very few time).

I have been looking for a nice toolkit for hacking around at home when
time permit and I found GTK a really nice one as well as the wide GTK
community (Gnome, XFCE ...).

Then I have been looking for a nice and fun programming language. At
work we use a lot C/C++. I have to say that I do not like this
language : too much traps even for experienced developers, not enough
nice and homogeneous integrated libraries. Fortunately I had the
opportunity to discover and use Java at work and I love it.

However at the beginning I started to hack with GTK and Perl, then
C#/Mono, then Python ... until I read a message from one of you on the
gnome planet about java-gnome.
I liked Perl, C#/Mono and Python. There are all great Free Software
and open communities. But what you are doing here at java-gnome is
awesome !!!


What I like a lot :

- Your website : simple and useful.

- Your documentation and examples : Seeing developers taking the time
to write good api and examples is a sign that their work is really
good because they put their "clients" (application developers) at the
center of the development process. Wen you read the documentation you
feel like the developers really wanted to please their users instead
of taking some good time for themselves first.

- Your bindings : it really integrates well with Java. Also I am
always amazed by all the good GTK bindings around the world. I am not
enough experienced to say it is better than others but I just think
you succeeded in integrating well with Java.


What I do not like  :

- Your communication : Mono guys make a lot of buzz around various
planets (which I think is too much), and applications made using Mono
also make a lot of noise (banshee is one of them). We all know Novell
is behind this. But I think java-gnome deserves to be known more !
However I think that what is going on on the java side and the facts
it is becoming completely Open and Free software will bring you more
users and a great future, as well as the great quality of your work !

Here is an example to illustrate this point : I do not know of a
single application made using java-gnome, and I cannot find a list of
those on the website.


My questions :

- You are using a home made build system, "Equivalence" and you plan
to use a new one, "Fabricate" : it is hard to Google with such names
;-) Are those projects mature enough for usage outside java-gnome ? I
would like to make people build my software using ./configure make
install (to be independent from eclipse) but I do not want to use
autotools ...


- I use Mandriva 2009.0 as my GNU/Linux Distribution. Unfortunatly
they packaged the old and deprecated bindings.
I made a rpm spec file to build java-gnome and have it packaged. The
only thing which is not right is that I have to hardcode the path to
the jdk on the ./configure line because it is not detected.
I will be please to help and package the new java-gnome for Mandriva
:-) Any recommendation before I start looking at java-gnome's
configure script to support Mandriva and submit the patch ?

Congratulations, and thank you very much to all of you !
Chicha.

Re: [Java-gnome-developer] Deck

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

On Thu, 2008-11-13 at 16:46 +0100, Ben Bucksch wrote:
> How do I make a deck? Basically a |Notebook| without 
> tabs. I need it when I want to display two different kinds of UI, one at 
> a time, in the same UI space, because they are mutually exclusive or the 
> selection is triggered by something else, e.g. a tree node selection.
> 
> For now, I implemented it myself, by adding and removing children from a 
> HBox, and setting setSizeRequest(), calculated based on maxima of 
> getRequisition() of the children.

That's one way.

Another way I've heard of is to add both Widgets to the parent
container, and use hide() on one of them, toggling to the other "state"
by show()ing the second and hide()ing the first one.

A third way to do this would be to use a Notebook and call its
setShowTabs() to turn off the display of tab controls. Interestingly,
that method just turned up on 'mainline' while I was writing this
email. :)

AfC
Sydney

Re: [Java-gnome-developer] License Question and GCJ

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

On Fri, 2008-11-14 at 17:55 +0100, Claes Lilliesköld wrote:
> I thinking about using java-gnome ... for a commercial application.

java-gnome is licenced under the GPL + Classpath Exception. This means
that you can link to it freely, but you can only do so without
triggering the GPL if you don't change anything in java-gnome or
otherwise derive or copy something from it.

If you do change anything in the library as released (and that includes
adding new coverage, changing internal data, changing public API, fixing
bugs, taking text or documentation, anything) then your application
using it would have to be GPLv2.

If you want to avoid this, then you could instead choose to submit your
changes upstream. When such contributions are accepted, merged into the
upstream 'mainline', and finally published, then at that point they form
part of the library as released and you can again use it via the linking
exception.

> java-gnome will create JNI...

JNI hasn't anything to do with it, really.

In Java land, loading classes and invoking methods from a Java (a .class
or a .jar of them) *is* "linking".

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

[Java-gnome-developer] License Question and GCJ

[C. L. <cla...@gm...>]

Hello,
I thinking about using Java-Gnome in combination with GCJ (+ Classpath or
OpenJDK) for a commercial application.
Can I do that, or does it force my application to be GPL:ed, since
java-gnome is GPL?

Java-Gnome will create JNI, and my application will link to Java-Gnome using
the JNI.
Or does the JNI calls go through the Class Library where the Classpath
exception protects my application for being GPL:ed?

Thanks / Claes

Re: [Java-gnome-developer] Thank you - Great work

[Ben B. <lin...@bu...>]

On 13.11.2008 07:28, Andrew Cowie wrote:
> On Wed, 2008-11-12 at 20:00 +0100, Ben Bucksch wrote:
>    
>> I just want to thank you for this great API to GTK.
>>      
>
> Now that's just the sort of thing that really makes your day. People in
> the #java-gnome IRC channel were very happy this morning.
>    

Great! :-) You guys deserve it.

>> It feels entirely natural in Java, is very comfortable and very
>> approachable.
>>      
>
> That doesn't happen by accident. It is the result of the hard work
>    

As some scientist said: "Sorry for the long letter, but I had no time 
for a short one."
The time you guys spend is saved (usually many times) by all the people 
who use the API. :-)

It shows.

> All I can say to that is that the writing there is the result of 
> experience [...]
> That usually occurs as we're trying to _use_ something

That's pretty obvious. Including the hair-tearing and head-banging. I 
liked the notes about the TreeSelection.Changed signal emission 
<http://java-gnome.sourceforge.net/4.0/doc/api/org/gnome/gtk/TreeSelection.Changed.html>, 
not just because of the funny language, but because it shows your 
fundamental attitude to a proper, clean API.

> So hey. As you experiment and learn, I encourage you to note places
> where a question you had in your mind *wasn't* answered as you were
>    

OK, here's one: How do I make a deck? Basically a |Notebook| without 
tabs. I need it when I want to display two different kinds of UI, one at 
a time, in the same UI space, because they are mutually exclusive or the 
selection is triggered by something else, e.g. a tree node selection.

For now, I implemented it myself, by adding and removing children from a 
HBox, and setting setSizeRequest(), calculated based on maxima of 
getRequisition() of the children.

Ben

Re: [Java-gnome-developer] Thank you - Great work

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

On Wed, 2008-11-12 at 20:00 +0100, Ben Bucksch wrote:
> I just want to thank you for this great API to GTK.

Now that's just the sort of thing that really makes your day. People in
the #java-gnome IRC channel were very happy this morning.

> It feels entirely natural in Java, is very comfortable and very 
> approachable.

That doesn't happen by accident. It is the result of the hard work of
all the people who have bought into this project's goals [and who have
put up with the resultant demanding requirements set by the project's
maintainer :)]. It is to all who have contributed that credit is due.

> The [bindings] also *work* as expected (as least so far, I am still new).

Patience. I'm sure you'll find something to break. :)

> Also, the documentation is good. The API documentation for each class 
> has a nice prose introduction text, which is very helpful and saves most 
> "tutorials". I also appreciate that it points out just the right level 
> of footangles to be aware of.

All I can say to that is that the writing there is the result of
experience - and usually, that experience has come as people like me
have attempted to figure out just what, exactly, a given something in an
underlying library actually does.

That usually occurs as we're trying to _use_ something, and adding
coverage that we hope will expose the thing that will do the trick.
Along the way you quite often realize that the thing you're looking at
doesn't actually do what you thought it did, or isn't for what you
thought it was for. There's a lot of wisdom to be had there.

Another source of knowledge are the questions and answers in places like
gtk-list and gtk-app-devel-list; I for one see stuff there all the time
that I didn't know about; I try to keep such messages around so that
when if a day comes that I need to use something, I can benefit from the
explanations there. It's stuff that is *not* in the underlying (GTK or
whatever) API documentation, but is still very critical to using the
library well.

++

So hey. As you experiment and learn, I encourage you to note places
where a question you had in your mind *wasn't* answered as you were
browsing the completion spaces or reading the JavaDoc popups in your
IDE. If you think of something that needs improving based on *your*
experiences, then by all means.

Such contributions are as valuable as code. They *are* code.

AfC
Sydney

[Java-gnome-developer] Thank you - Great work

[Ben B. <lin...@bu...>]

Hey guys,

I just want to thank you for this great API to GTK.

It feels entirely natural in Java, is very comfortable and very 
approachable. The names and APIs are as you'd think them up when you'd 
draw a widget set API in your mind, thus they are easy to find, too. 
They also *work* as expected (as least so far, I am still new).

Also, the documentation is good. The API documentation for each class 
has a nice prosa introduction text, which is very helpful and saves most 
"tutorials". I also appreciate that it points out just the right level 
of footangles to be aware of.

All in all a really great piece of work. When you talked about "quality" 
on your website, I was suspect, as that's most of the time just words, 
but you really deliver quality. You show an good example of what quality 
means in the context of an API.

Sun should take a good example from you (*cough* Swing *cough*), and 
many in the open-source world, too. Such brightness and care is rare.

Thank you again for this masterpiece.
It's a joy to work with it.

Ben

Re: [Java-gnome-developer] java-gnome and glade

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

On Wed, 2008-11-12 at 09:19 +0200, Fatih Genç wrote:
> Is there any tutorial or any example application that uses glade

I assume you've read the API documentation for this already? If not, see
http://java-gnome.sourceforge.net/4.0/doc/api/org/gnome/glade/Glade.html

As you'd expect, the tiny program that was used to test things when
Glade support first added is still in the sources. See
tests/prototype/Designer.java

I haven't bothered to convert that into nice hand-holding Example form
yet, because, well, frankly, personally I don't use libglade much
anymore. You've got to write code anyway. So just write code.

But nevertheless libglade remains a cool feature in the GNOME libraries,
and we do of course support it - and have since 4.0.2.

As Davyd and I frequently discuss when we give our GTK tutorial, yes,
libglade can come in handy if you're doing *lots* of Labels. But that
said, there seems to be a meme around that you should _start_ your GTK
programming experience by starting with Glade, and I must admit I don't
really encourage people in this. In our experience it just confuses
matters. We learned that the hard way ourselves.

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

[Java-gnome-developer] java-gnome and glade

[F. G. <fat...@li...>]

Hi everybody
Is there any tutorial or any example application that uses glade user
interface file (ExampleApp.glade)?
How to use .glade file with java-gnome 4.0x can anyone explain this with an
example
Thanks

-- 
Fatih Genç
PublicKey:ssh-rsa
AAAAB3NzaC1yc2EAAAABIwAAAQEAyonAWUki8J8humlBlHmwj/yRroHq8KchqgyX/Ow3MrwBeMNVcEa8pc8J3RheptLwwN63ZFz4m9Hx2ubOp+mOR8WozRlGZVN1grLaNGV0M9Ev6hRAVE+zcdcVx2xV4/bGDApKX0aGPWRUvoRk66bqWp0YRTAfkuNGNAFFRbOd9IRbVSZS5IHKFhKOLTxdH2AQqb5FBY44B3fyzeTgux1t+1QSyU+PZkMTHL6JuXlK2lWc9odPlBP9yxJ2ma1jPV8qIwUf7sQfZUiS3XJmGWSFckx+XnpWvEEIdK/KJ8lnNIZozK6/jh2rmDg/1vzX0XIy7vSjFRrnf8ZDwf3edOtTdQ==
fatih@komuthan

Re: [Java-gnome-developer] compilation with 4.0.8

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

On Fri, 2008-10-17 at 10:38 +0200, Federico wrote:
> I have to be stupid!!!

No no. Nothing like that. You've been outstanding in your persistence.
We'll figure it out. Don't worry. We just need to find out what is
different about your computer compared to others.

... and while this may be just something weird to do with your machine,
it's always possible that lots of other people are being hit with this
too. So, it's excellent that we're working through this.

It really *would* be helpful to do this in real time (ie together
online), as there are many more questions we could ask.

> I tried to compile the 4.0.8 version.
> Problem: this does not compile at all!

Versions generally improve as they grow, so usually things that don't
work in previous version work in later ones. In particular, this
problem:

> GCC	generated/bindings/org/gnome/gtk/GtkToolbar.c
> 
> generated/bindings/org/gnome/gtk/GtkToolbar.c: In function
> ‘Java_org_gnome_gtk_GtkToolbar_gtk_1toolbar_1set_1tooltips’:
> generated/bindings/org/gnome/gtk/GtkToolbar.c:407: error: implicit
> declaration of function ‘gtk_toolbar_set_tooltips’

is due to a function that is no longer available in GTK 2.14. We fixed
this (and related problems) in java-gnome 4.0.9

        [to be specific, the part of the release note about "Build
        system improvements" is about this very issue. The Gentoo people
        backported the fix to their 4.0.8 package, but it's in 4.0.9 and
        'mainline' for those using newer versions]

> Please help me!

Not really sure what to say. Going back to 4.0.8 isn't really the
answer.

AfC
Sydney