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

Re: [Java-gnome-developer] Eclipse Plugins

[Matthew C. <mpc...@li...>]

>   Sure.. They'll be available shortly (with source, the usual), I need
> to take about 10 minutes and just put the site together.  I'll try and
> do it tonight.

Cool, I'll take a look.

>   I agree.  I'll look at GCJ in a bit.  I really like the idea of
> developing everything in Java then compiling it into an executable so
> anti-java people won't even know it was written in an better language. 
> ;)
>   I'd like to get some more features/configuration options in the
> wizards then I'll look into the GCJ stuff.

lol. Yes that's exactly what I thought. (see:
http://www.gridfire.com/twiki/bin/view/Main/EclipseGnome for some of my
other ideas)

I'll probably not have enough time to do much but I'll sure give your
plugins a try.

Maybe I could look at something smaller like setting up an eclipse
"feature" for gnome integration. This is what the JBoss group do to
install the set of JBoss plugins. You just type the url of the features
xml file and bingo it installs everything into eclipse and enables users
to perform updates when new plugins are released.

Matt.

Re: [Java-gnome-developer] Eclipse Plugins

[Dan P. <pi...@sl...>]

On Tue, 2003-09-30 at 09:25, Mark Howard wrote:
> Please report all issues you find in the bug tracking system.
> I've not used glade personally, so don't know much about this. Perhaps
> it's time to start :)
> 

  Ok.. will do.

> Are they available anywhere now?
> Once they're working, can I create Debian packages for them? they sound
> quite useful.

  They'll be up a.s.a.p.  I have a new site that will host the web page,
I just need to write the page.  I'll try and get them up tonight.  As
for deb packages, you're more than welcome to, but does Debian build
packages for eclipse?  The plugins are distributed like any other
eclipse plugin, just a zip file you unzip into the "eclipse" directory. 
Anyway, if you do decide to build debian packages and you'd like me to
put them on the site with the rest of the distribution, just yell. --
Dan

RE: [Java-gnome-developer] Eclipse Plugins

[Dan P. <pi...@sl...>]

On Tue, 2003-09-30 at 07:04, Jeffrey Morgan wrote:
> This is good news.  I look forward to trying the plugins.  java-gnome 
> is still under development although quite slow at the moment.  
> 

  It's pretty neat (the Java-Gnome stuff).  With the eclipse plugin you
make a couple of clicks to create a Gnome Glade Java project and click
"Run" and you have a working application in Java.
  One thing that's bugging me is I can't figure out how to get the app
to start without needing to pass the -Djava.library.path=/usr/lib
option.  Obviously /usr/lib is in my ld.so.conf, so why does it need to
be explicitly set?

> > I've reworked
> > the spec file some to build binary RPMs (now supports 
> > RPM_BUILD_ROOT and
> > a few other changes) and would like to release the eclipse 
> > plugin along
> > with the CVS version of JavaGnome.  Is there another JavaGnome release
> > coming shortly?  If not, would people object to me putting RPMs of the
> > current CVS on the site with the Eclipse plugin?
> 
> The goal of the next release was bug fixes.  We probably still have
> some more work ahead of us prior to the next release.  Please feel
> free to put the CVS snapshot on your site.
> 

> I just need your sourceforge userid to give you RW access.

  It's just 'pilone'.  Thanks! -- Dan

Re: [Java-gnome-developer] Eclipse Plugins

[Dan P. <pi...@sl...>]

On Tue, 2003-09-30 at 04:10, Matthew Cooke wrote:
> I started a similar thing myself, though never got it finished. So i'd 
> be interested in trying/testing these plugins.

  Sure.. They'll be available shortly (with source, the usual), I need
to take about 10 minutes and just put the site together.  I'll try and
do it tonight.

> I think maintaining a collection of plugins for eclipse/gnome is a great 
> idea. Hooks into GCJ for compilation is another plugin that would be useful.
> 

  I agree.  I'll look at GCJ in a bit.  I really like the idea of
developing everything in Java then compiling it into an executable so
anti-java people won't even know it was written in an better language. 
;)
  I'd like to get some more features/configuration options in the
wizards then I'll look into the GCJ stuff.

[Java-gnome-developer] GTK_WIDGET_xxxx macro access

[Jonas B. <jb...@ni...>]

(also posted as a bug at sf.net)

Is there a way to access the data available through the GTK_WIDGET_xxxx=20
macros? For my current project, I'd need to run the=20
GTK_WIDGET_SENSITIVE(widget) macro to find out if the widget is sensitive=
=20
or not. Of course I can keep the info somewhere until this gets fixed.

The C interface provides the gtk_widget_set_sensitive() for setting the=20
value, but for getting there's only the above macro (afaik).

The setSensitive() method is implemented in the Widget class, so maybe we=
=20
could take a java-like approach and add a getSensitive() method that then=
=20
somehow runs the macro (or something).

- xkr47

Re: [Java-gnome-developer] OptionMenu events etc..

[Jonas B. <jb...@ni...>]

On Thu, 2 Oct 2003 13:18:32 +0100, Mark Howard <mh...@de...> wrote:

> Hi,
>  Before you do anything, please add a bug entry for this to
> sourceforge.net - we seem to have lots of little unfinished bits like
> this, but aren't tracking them very well. Also, add reports for anythin=
g
> else you find :)

Ok did that, and will do in the future =3D)

> Copying code like this should be fairly straight forward (for simple
> widgets at least). We will of course review any patches to look out for
> problems.

Yes, it was pretty simple.. And I felt confident as soon as I figured out=
=20
that event initialization hassle I posted a patch to just an hour ago.. =3D=
)

>> I could then try to implement the stuff needed in OptionMenu (and mayb=
e
>> send a patch).. and maybe later other components as well.
> I look forward to seeing it.

> Note that many of the signals have not been implemented for a good
> reason; we are trying not to copy the deprecated or internal parts of
> gtk (option menu changing does not come into this category).

Well, I noticed later there is this other option to register an event=20
listener for each of the items in the pull-down menu (like can be done in=
=20
C as well), but I think it is a bit overkill for simple setups, and thus =
I=20
think implementing the "changed" event is motivated.

I named the event "CHANGE" in the java code, along the lines of (what I=20
thought was) the common practice.

The patch is here:

   http://xkr47.outerspace.dyndns.org/patches/java-gnome/cvs-031005-1-Opt=
ionMenuEvent.diff

I tried to make the code in the patch look the same way as other widgets=20
were implemented in the cvs checkout I did last night. This patch does no=
t=20
overlap with the patch I sent an hour ago regarding event registration=20
fixes. I continued following the same event registration model in this=20
patch.

I tested it and it worked beautifully. Thanks for posting the extensive=20
advice on how to implement event handlers.

- xkr47

Re: [Java-gnome-developer] OptionMenu events etc..

[Jonas B. <jb...@ni...>]

On Sun, 05 Oct 2003 02:04:19 +0300, Jonas Berlin <jb...@ni...>=
=20
wrote:

> Now I suggest the following:
>
> 1. make sure all initializeEventHandlers() call=20
> super.initializeEventHandlers(), with the only exception being Widget,=20
> which is the topmost widget class.
> 2. remove all <anywidgetclass>.addEvents() calls from the addEvents()=20
> methods of the various classes.
>
> This way, events should be registered only once, and as a bonus, the=20
> code will most likely be easier to read also =3D)
>
> I'll start working on a patch that will fix all widget classes accordin=
g=20
> to my suggestion. If you have some better solution for this then I can=20
> try that as well :)

Now I'm back a bit later with a patch according to the above suggestions,=
=20
and additionally:

3. make the addEvents() methods private so nobody else can call them by=20
accident

I tested the patch with the same Button & ToggleButton code I presented i=
n=20
my last mail, and both now yield only one LifeCycleEvent. I didn't test=20
the other classes, but it's pretty simple a modification and I tried to=20
make sure I fixed them all the same way.

Now then, the patch is here:

   http://xkr47.outerspace.dyndns.org/patches/java-gnome/cvs-031005-2-ini=
tializeEvent-addEvents.diff

The sourceforge cvs was inoperational, or at least I could not log in to=20
it and check out the project, so I did a dirty perl script that downloade=
d=20
the entire java-gnome cvs through the cvsweb interface, which was still=20
operational. Thus, the patch is against the cvs version that was present=20
in sourceforge yesterday evening.

Some final notes about the patch:

  - some classes had addEvents() methods that only called=20
<superclass>.addEvents(), which after my modification (2.) became empty,=20
so I removed those methods (and unnecessary EventMap imports that became=20
unnecessary) altogether.

  - some classes didn't have an addEvents() method at all, instead they d=
id=20
what addEvents() used to do directly in the static { ... } block. I=20
thought consistency is bliss, created new addEvents() methods and moved=20
the code there.

- xkr47

Re: [Java-gnome-developer] OptionMenu events etc..

[Jonas B. <jb...@ni...>]

On Fri, 03 Oct 2003 23:47:19 +0300, Jonas Berlin <jb...@ni...>=
=20
wrote:

> Hi.. I took a look at some of the classes and thought they had some=20
> weird initialization style:
>
> public class ToggleButton extends Button {
>      protected void initializeEventHandlers() {
> 	super.initializeEventHandlers();
> 	evtMap.initialize(this);
>      }
>
>      protected static void addEvents(EventMap evtMap) {
> 	Button.addEvents(evtMap);
> 	// .. add togglebutton-specific events
>      }
> }

I did some research, a bunch debug prints in the signal-related codes to=20
test & verify the behaviour.

I found out that my previous statements were at least partially correct.

The situation is like this:
  1. initializeEventHandlers() methods call super.initializeEventHandlers=
()=20
(except for some cases)
  2. most addEvents() methods call addEvents() of some superclass, usuall=
y=20
<superclass>.addEvents() or then Widget.addEvents.

The result from this duplicate behaviour is that some event handlers get=20
registered multiple times. One easy way to test this is to do:

   LifeCycleListener lcl =3D new LifeCycleListener() {
       public void lifeCycleEvent(LifeCycleEvent evt) {
         System.out.println(evt);
       }
     };

   Button b =3D new Button("foo");
   b.addListener(lcl);
   b.show();

This will display something like:

org.gnu.gtk.event.LifeCycleEvent[source=3Dorg.gnu.gtk.Button@18a992f,id=3D=
SHOW]
org.gnu.gtk.event.LifeCycleEvent[source=3Dorg.gnu.gtk.Button@18a992f,id=3D=
SHOW]

Now if you change Button to ToggleButton, it instead shows:

org.gnu.gtk.event.LifeCycleEvent[source=3Dorg.gnu.gtk.ToggleButton@f72617=
,id=3DSHOW]
org.gnu.gtk.event.LifeCycleEvent[source=3Dorg.gnu.gtk.ToggleButton@f72617=
,id=3DSHOW]
org.gnu.gtk.event.LifeCycleEvent[source=3Dorg.gnu.gtk.ToggleButton@f72617=
,id=3DSHOW]

-----------

Now I suggest the following:

1. make sure all initializeEventHandlers() call=20
super.initializeEventHandlers(), with the only exception being Widget,=20
which is the topmost widget class.
2. remove all <anywidgetclass>.addEvents() calls from the addEvents()=20
methods of the various classes.

This way, events should be registered only once, and as a bonus, the code=
=20
will most likely be easier to read also =3D)

I'll start working on a patch that will fix all widget classes according=20
to my suggestion. If you have some better solution for this then I can tr=
y=20
that as well :)

- xkr47

Re: [Java-gnome-developer] OptionMenu events etc..

[Jonas B. <jb...@ni...>]

On Thu, 2 Oct 2003 13:18:32 +0100, Mark Howard <mh...@de...> wrote:

> The next stage is to actually receive notification of the events from
> the native layer. This is done through the addEvents method. The jni
> code is done in other parts of java-gnome, so for things like Buttons
> and OptionMenus, it's just a case of adding:
> protected static void addEvents(EventMap anEvtMap) {
> 		Widget.addEvents(anEvtMap);
> 		anEvtMap.addEvent("clicked", "handleClick", ButtonEvent.Type.CLICK,=20
> ButtonListener.class);

Hi.. I took a look at some of the classes and thought they had some weird=
=20
initialization style:

public class ToggleButton extends Button {
     protected void initializeEventHandlers() {
	super.initializeEventHandlers();
	evtMap.initialize(this);
     }

     protected static void addEvents(EventMap evtMap) {
	Button.addEvents(evtMap);
	// .. add togglebutton-specific events
     }
}

public class Button extends Bin {
     protected void initializeEventHandlers() {
	super.initializeEventHandlers();
	evtMap.initialize(this);
     }

     protected static void addEvents(EventMap evtMap) {
	Widget.addEvents(evtMap);
	// .. add button-specific events
     }
}

public class Bin extends Container {
     // no initializeEventHandlers(), so it uses the one from Container

     protected static void addEvents(EventMap evtMap) {
	Container.addEvents(evtMap);
     }
}

public class Container extends Widget {
     protected void initializeEventHandlers() {
	evtMap.initialize(this);
     }

     protected static void addEvents(EventMap evtMap) {
	Widget.addEvents(evtMap);
	// .. add container-specific events
     }
}

public class HBox extends Box {
     // no initializeEventHandlers(), so it uses the one from Container

     protected static void addEvents(EventMap evtMap) {
	Box.addEvents(evtMap);
     }
}

public class Box extends Container {
     // no initializeEventHandlers(), so it uses the one from Container

     protected static void addEvents(EventMap evtMap) {
	Container.addEvents(evtMap);
     }
}

Now first off, ToggleButton.addEvents() calls Button.addEvents() i.e. the=
=20
superclass' addEvents(). But Button.addEvents() call Widget.addEvents()=20
while its superclass is Bin. Bin again calls its superclass' addEvents(),=
=20
and so does Container. As a first impression, one would think the=20
Widget.addEvents() in the Button class should be Bin.addEvents().

On the other hand, one can see that the initializeEventHandlers() always=20
also calls initializeEventHandlers() for it's superclass. And since all=20
implementations of initializeEventHandlers() call their superclasses'=20
initializeEventHandlers(), one would think that calling for example=20
Container.addEvents() from Bin.addEvents() wouldn't be necessary.

If I understood the code correctly however, this will just result in some=
=20
signals being registered twice. I didn't have time to figure out whether=20
there are some checks to avoid duplicate registration. But anyway, becaus=
e=20
of the subclass calling the superclass, all events seem to get registered=
=20
anyway.

As far as I understood, all calls to the parent's addEvents() method coul=
d=20
be removed, since the super.initializeEventHandlers() will call the=20
initializatieEventHandlers() for its superclasses as well, eventually=20
initializing all superclasses' signals for the object in question.

Now if I got something wrong, please correct me. If you give guidelines=20
for how these really should be, I can see if I could create a patch for=20
the javas too..

Anyway I'll try to implement the OptionMenu events according to=20
ToggleButton's example and see what I can do..

- xkr47

[Java-gnome-developer] TextView enhancements

['Mark H. <mh...@de...>]

Hi,
  I've just committed some changes to the text related gtk widgets and a
new example application - textbuffer. This is a clone of the gtk-demo
textbuffer example which shows off the widget. This hopefully
demonstrates how far we've come with java-gnome. The example is complete
apart from three areas:
- international text
- backgroud images (automatically generated)
- adding widgets
I'm not interested in the first two of these, but might work on the
final one when I get some time. 

In terms of generally demonstrating the completeness of java-gnome, I
think it would be a really good idea if we could get a complete Java
clone of the gtk-demo program working. Some of the example apps are
already taken from this, but there are still more to do. Is anybody
on the list interested in taking on one of these sections? Any
Java-Gnome newbies? If you do, I promise to review any patches sent to
this list, offer help where I can and fix bugs when I get time. 

-- 
  .''`. Mark Howard
 : :' :
 `. `'  http://www.tildemh.com 
   `-   mh...@de... | mh...@ti... | mh...@ca... 

Re: [Java-gnome-developer] Processing sgml Documentation

['Mark H. <mh...@de...>]

On Fri, Oct 03, 2003 at 07:35:09AM -0400, Jeffrey Morgan wrote:
> The format used is docbook.  You can easily convert the
> docbook format to html, postscript or pdf format with one
> of the utilities in the docbook package (example: db2pdf).

Thanks.

-- 
  .''`. Mark Howard
 : :' :
 `. `'  http://www.tildemh.com 
   `-   mh...@de... | mh...@ti... | mh...@ca... 

RE: [Java-gnome-developer] Processing sgml Documentation

[Jeffrey M. <Jef...@Br...>]

The format used is docbook.  You can easily convert the
docbook format to html, postscript or pdf format with one
of the utilities in the docbook package (example: db2pdf).

> -----Original Message-----
> From: Mark Howard [mailto:mh...@de...]
> Sent: Thursday, October 02, 2003 4:08 PM
> To: jav...@li...
> Subject: [Java-gnome-developer] Processing sgml Documentation
> 
> 
> Hi,
>   I've been updating the Debian packages of java-gnome and 
> realised that
> I hadn't been including the tutorial or FAQ (I'm assuming the other
> files in doc are now obsolete). There doesn't seem to be a makefile
> target for these and I don't know anything about the format used.
> 
> How can I generate user documentation from these? (possibly html
> format).
> 
> -- 
>   .''`. Mark Howard
>  : :' :
>  `. `'  http://www.tildemh.com 
>    `-   mh...@de... | mh...@ti... | mh...@ca... 
> 

[Java-gnome-developer] Processing sgml Documentation

[Mark H. <mh...@de...>]

Hi,
  I've been updating the Debian packages of java-gnome and realised that
I hadn't been including the tutorial or FAQ (I'm assuming the other
files in doc are now obsolete). There doesn't seem to be a makefile
target for these and I don't know anything about the format used.

How can I generate user documentation from these? (possibly html
format).

--=20
  .''`. Mark Howard
 : :' :
 `. `'  http://www.tildemh.com=20
   `-   mh...@de... | mh...@ti... | mh...@ca...=20

[Java-gnome-developer] gnome.UIInfo constructors

[Mark H. <mh...@de...>]

Hi,
  We need to work on gnome.UIInfo. The current class is quite ugly and
fails to satisfy many needs. e.g. it doesn't allow accelerator keys to
be set; doesn't allow pixmaps to be used from files (will anyone use xpm
byte arrays? I think they should be removed); doesn't allow pixmaps to
be used from stock items (with different text); and probably a few other
combinations I've not checked.

My first proposal was going to be: =20
  I'd like to make the UIInfo constructors public (and possibly remove
some of the static 'constructor' methods). This number of static
constructors makes the class overly difficult to use, IMHO. Also, it
fails to provide the full functionality.=20
But then I looked at it and this seemed a little too difficult.

A second alternative would be to continue with the current system, but
add the additional functionality:

Optional accel key setting - doubles the current number of methods
Optional pixmaps file - double again
Optional pixmaps from stock - double again
(doubles do not include stock item methods)

This seems very ugly and will just make the class even harder to use,
IMHO.

Third alternative:
 Have a simple set of constructors + methods for setting the other
 things
e.g. UIInfo myitem =3D UIInfo.item("test", "This tests Stuff");
	myitem.setListener( (MenuItemListener) this );
	myitem.setIconFile("/usr/share/pixmaps/myitem.png");
	myitem.setAccelerator( ???.CONTROL, "z" );

The first diffuculty is deciding how much to put in the 'constructor'
methods (and hence how many of these you have to read through in the
docs to get the right one). The main problem with the scheme however is
that you can no longer have a simple array:

createToolbar( new UIInfo[] {
	UIInfo.blah(a,b,c,d),
	...
});

instead, it requires:
UIInfo myuiinfoblah =3D UIInfo.blah(a,b);
myuiinfoblah.foo(c, d);
=2E..
createToolbar( new UIInfo[] {
	myuiinfoblah,
	...
});

I don't like any of these solutions.=20
Please can somebody suggest something better, or give preference for one
of the above (and suggest cut off points for what to include where).
--=20
  .''`. Mark Howard
 : :' :
 `. `'  http://www.tildemh.com=20
   `-   mh...@de... | mh...@ti... | mh...@ca...=20

Re: [Java-gnome-developer] OptionMenu events etc..

[Mark H. <mh...@de...>]

Hi,
 Before you do anything, please add a bug entry for this to
sourceforge.net - we seem to have lots of little unfinished bits like
this, but aren't tracking them very well. Also, add reports for anything
else you find :)
 
On Thu, Oct 02, 2003 at 02:41:42PM +0300, Jonas Berlin wrote:
>  - what is autogenerated and whatnot
Everyting was initially autogenerated. In the latest automatic
generation, some jni/c code was autogenerated and java files were
generated containing the native methods. Everything else has been added
by hand. This is basically almost everything in the java files apart
from the bottom few lines and either nothing in jni files, or a few
functions at the top of the files, or in some cases entire jni files.

Adding an event for an option menu will probably be possible without
changing any c code. (We try to do as little c work as possible since it
is far easier to debug java and it usually works better that way)

Three things are needed for an event:

events/eventnameEvent.java
e.g. ButtonEvent
Each event has a static nested Type class. This allows us to have
varients of an event handled by the same methods. This should extend
GtkEventType and the static final fields of it have a unique identifier
and a name. This part should be easy to construct. (Option menu will
probably only have one type - CHANGE)
The rest of the class can be basically copied

events/eventnameListener.java
This is the listener which the user's code must implement. Should be
kept as simple as possible. We tend to prefer a single method for a
group of related events rather than lots of methods which probably won't
all get implemented. 
Any objections to what events go in which methods can be discussed in
the mailing lists.

The widget. Take Button.java as an example:
We can have multiple objects listening for an event, so need:
private Vector buttonListeners = null;
We then have methods for adding and removing events:
public void addListener(ButtonListener listener) {
public void removeListener(ButtonListener listener) {

We then have a convenience function for calling the methods of the
objects which are listening:
protected void fireButtonEvent(ButtonEvent event) {

Everything so far can be more or less copied (changing the Event and
listener class names.

The next stage is to actually receive notification of the events from
the native layer. This is done through the addEvents method. The jni
code is done in other parts of java-gnome, so for things like Buttons
and OptionMenus, it's just a case of adding:
protected static void addEvents(EventMap anEvtMap) {
		Widget.addEvents(anEvtMap);
		anEvtMap.addEvent("clicked", "handleClick", ButtonEvent.Type.CLICK, ButtonListener.class);
activate is the name of the gtk signal. handleActivate is a method in
this class:		
private void handleClick() {
	fireButtonEvent(new ButtonEvent(this, ButtonEvent.Type.CLICK));
}

Copying code like this should be fairly straight forward (for simple
widgets at least). We will of course review any patches to look out for
problems.

> I could then try to implement the stuff needed in OptionMenu (and maybe 
> send a patch).. and maybe later other components as well.
I look forward to seeing it.
Note that many of the signals have not been implemented for a good
reason; we are trying not to copy the deprecated or internal parts of
gtk (option menu changing does not come into this category).

-- 
  .''`. Mark Howard
 : :' :
 `. `'  http://www.tildemh.com 
   `-   mh...@de... | mh...@ti... | mh...@ca... 

Re: [Java-gnome-developer] non-button widgets in toolbars

[Mark H. <mh...@de...>]

On Thu, Oct 02, 2003 at 03:33:07PM +0100, Mark Howard wrote:
> My tests doing your suggestion don't work - there is just an empty
> toobar (I populated it with some simple buttons) (using gnome
> App.setToolbar()).

Calling mytoolbar.showAll() fixed this one. doh.
Unfortunately, it no longer takes note of the gnome setting for
displaying just icons. There isn't a toolbarButton widget either;
buttons look very strange. Guess I'll have to keep looking for somebody
with more gtk knowledge to fix this one. Can anybody here help?

> Also, the TestGtk example crashes when clicking the toolbar example.
This example passes null for some strings, causing the crash. pssing
nulls will often fail in java-gnome at the moment. We should probably
overload the method in thei case, with the help tip omitted.

-- 
  .''`. Mark Howard
 : :' :
 `. `'  http://www.tildemh.com 
   `-   mh...@de... | mh...@ti... | mh...@ca... 

Re: [Java-gnome-developer] non-button widgets in toolbars

[Mark H. <mh...@de...>]

On Tue, Sep 02, 2003 at 11:24:39AM -0400, Jeffrey Morgan wrote:
> I am not sure if it is possible to do this with UIInfo.
> You might try to create the toobar yourself and add it
> with App.setToolBar(ToolBar).

Still trying to figure it out...

Not many gnome apps use gtk toolbars - gul, bonobo, all sorts of others.

It's a shame there isn't a app.getToolbar method, like there is a
getMenuBar().

My tests doing your suggestion don't work - there is just an empty
toobar (I populated it with some simple buttons) (using gnome
App.setToolbar()).

Also, the TestGtk example crashes when clicking the toolbar example.

Has anybody managed to get a ToolBar to work?

-- 
  .''`. Mark Howard
 : :' :
 `. `'  http://www.tildemh.com 
   `-   mh...@de... | mh...@ti... | mh...@ca... 

[Java-gnome-developer] OptionMenu events etc..

[Jonas B. <jb...@ni...>]

Hi..

I was adding a OptionMenu, but I noticed no event listener interface was=20
available for the class. I looked at the superclass Button and saw it was=
=20
mostly java code required, but that there were some native stuff involved=
=20
which seems to be autogenerated.

So, I was thinking, could someone maybe in short describe
  - the basics about adding event listener support for a widget
  - the pitfalls
  - what is autogenerated and whatnot
  - etc

I could then try to implement the stuff needed in OptionMenu (and maybe=20
send a patch).. and maybe later other components as well.

- xkr47

Re: [Java-gnome-developer] Eclipse Plugins

[Mark H. <mh...@de...>]

On Mon, Sep 29, 2003 at 09:26:31PM -0400, Dan Pilone wrote:
>   Unrelated, there are a few JavaGnome widgets that don't work with
> Glade due to naming issues.  In particular StatusBar and ToolBar.  The
> GTK versions are named GtkStatusbar and GtkToolbar so you can't retrieve
> them from LibGlade.
Please report all issues you find in the bug tracking system.
I've not used glade personally, so don't know much about this. Perhaps
it's time to start :)

>   Anyway, GREAT WORK on the JavaBindings.  I'm really excited about what
> they can do and that motivated me enough to put together these wizards. 
Are they available anywhere now?
Once they're working, can I create Debian packages for them? they sound
quite useful.

-- 
  .''`. Mark Howard
 : :' :
 `. `'  http://www.tildemh.com 
   `-   mh...@de... | mh...@ti... | mh...@ca... 

Re: [Java-gnome-developer] boolean equals(...)

[Mark H. <mh...@de...>]

On Mon, Sep 29, 2003 at 11:25:59PM +0300, Jonas Berlin wrote:
> I'll see if I have some time to look into this, maybe I'll post a patch 
> later on if I manage.

Sorry, these were just silly mistakes. If you don't have time to prepare
a patch, please open an entry in the bug tracking system noting the
problem classes.

-- 
  .''`. Mark Howard
 : :' :
 `. `'  http://www.tildemh.com 
   `-   mh...@de... | mh...@ti... | mh...@ca... 

RE: [Java-gnome-developer] Eclipse Plugins

[Jeffrey M. <Jef...@Br...>]

> All,
>   I've written two simple Wizard plugins for the Eclipse development
> environment.  They still need some work, but proof-of-concept 
> is working
> well.  I have one that creates a simple application that has 
> a menubar,
> and toolbar.  The other creates a Glade application.  Anyway, 
> the point
> of this is I'm wondering what the state of JavaGnome is.  

This is good news.  I look forward to trying the plugins.  java-gnome 
is still under development although quite slow at the moment.  

> I've reworked
> the spec file some to build binary RPMs (now supports 
> RPM_BUILD_ROOT and
> a few other changes) and would like to release the eclipse 
> plugin along
> with the CVS version of JavaGnome.  Is there another JavaGnome release
> coming shortly?  If not, would people object to me putting RPMs of the
> current CVS on the site with the Eclipse plugin?

The goal of the next release was bug fixes.  We probably still have
some more work ahead of us prior to the next release.  Please feel
free to put the CVS snapshot on your site.

>   Unrelated, there are a few JavaGnome widgets that don't work with
> Glade due to naming issues.  In particular StatusBar and ToolBar.  The
> GTK versions are named GtkStatusbar and GtkToolbar so you 
> can't retrieve
> them from LibGlade.
>   Anyway, GREAT WORK on the JavaBindings.  I'm really excited 
> about what
> they can do and that motivated me enough to put together 
> these wizards. 
> Finally, would it be possible for someone to give me RW 
> access to CVS? 

I just need your sourceforge userid to give you RW access.

[Java-gnome-developer] Eclipse Plugins

[Dan P. <pi...@sl...>]

All,
  I've written two simple Wizard plugins for the Eclipse development
environment.  They still need some work, but proof-of-concept is working
well.  I have one that creates a simple application that has a menubar,
and toolbar.  The other creates a Glade application.  Anyway, the point
of this is I'm wondering what the state of JavaGnome is.  I've reworked
the spec file some to build binary RPMs (now supports RPM_BUILD_ROOT and
a few other changes) and would like to release the eclipse plugin along
with the CVS version of JavaGnome.  Is there another JavaGnome release
coming shortly?  If not, would people object to me putting RPMs of the
current CVS on the site with the Eclipse plugin?
  Unrelated, there are a few JavaGnome widgets that don't work with
Glade due to naming issues.  In particular StatusBar and ToolBar.  The
GTK versions are named GtkStatusbar and GtkToolbar so you can't retrieve
them from LibGlade.
  Anyway, GREAT WORK on the JavaBindings.  I'm really excited about what
they can do and that motivated me enough to put together these wizards. 
Finally, would it be possible for someone to give me RW access to CVS? 
Phew.. Thanks again, and great job! -- Dan

[Java-gnome-developer] boolean equals(...)

[Jonas B. <jb...@ni...>]

Hi!

I found that there are an implementation of equals() in some classes that=
=20
don't take an Object as a parameter, instead they take for example=20
TextIter or such.

It is good practice to always override the equals(Object other) method in=
=20
the Object class instead of creating a parallell equals() method. It can=20
be confusing and error-prone to have several equals() methods.

Further, if one wants to use an object as a key for a HashMap, and one=20
overrides the equals(Object) method, it is also required of the object to=
=20
implement the hashCode() method. Even if the javadoc documentation for=20
Object.hashCode() is maybe a bit cryptic, it gives more information on th=
e=20
subject.

When scanning the java-gnome sources, I found these equals() not taking a=
n=20
Object parameter.

./java/org/gnu/gtk/event/ScaleEvent.java:
        public boolean equals(ScaleEvent event2){
./java/org/gnu/gtk/TextIter.java:
        public boolean equals(TextIter other){
./java/org/gnu/glib/Boxed.java:
        public boolean equals(Boxed other){

There were indeed also classes where both equals(Object) and hashCode()=20
were implemented.

I'll see if I have some time to look into this, maybe I'll post a patch=20
later on if I manage.

- xkr47

[Java-gnome-developer] Re: [Help] CustomEvents refresh problem

[Jonas B. <jb...@ni...>]

On Fri, 12 Sep 2003 07:18:33 +0100, Mark Howard <mh...@ti...> wrote:

> Unlike most gtk/gnome ports, we're not trying to clone its interface to
> java. We're trying to reproduce it in a nice Java style. For example in
> text views we pass data blocks around rather than integers and other
> things. The bits which will change are the bits which look ugly. For
> example at the moment you have to add UIInfo.end() to the end of all
> UIInfo arrays. That's something I want to fix.

Maybe that's something I could help out with, if I have time..

>> BTW, what's your role in java-gnome? Are you a main developer or?
> I'm just one of the developers. I did a lot of work on the graphical
> bits of the gtk widgets, before I knew much JNI. Then I moved on and
> sorted out the treeview and started the textview and wrote CustomEvents=
.
> I've written a very large application with java-gnome (bugwatcher - lik=
e
> an email client, but for bugs) - this has helped find bugs in java-gnom=
e.
> There are a few developers who contribute occasionally. Unfortunately
> none of us have lots of time.

I've used JNI a bit, and have some experience in passing stuff from/to=20
java, even streaming stuff (I made a buffering wrapper for InputStream fo=
r=20
example, that I then used directly for libjpeg, libpng and other librarie=
s=20
that parse data gradually). The data was streamed (in java) from the=20
internet directly, so the native libraries could start decoding jpegs=20
while still downloading, for example.

- xkr47

[Java-gnome-developer] Re: [Help] CustomEvents refresh problem

[Mark H. <mh...@ti...>]

On Fri, Sep 12, 2003 at 03:38:51AM +0300, Jonas Berlin wrote:
> I understand it's still not finalized and that 
> interfaces might change
Unlike most gtk/gnome ports, we're not trying to clone its interface to
java. We're trying to reproduce it in a nice Java style. For example in
text views we pass data blocks around rather than integers and other
things. The bits which will change are the bits which look ugly. For
example at the moment you have to add UIInfo.end() to the end of all
UIInfo arrays. That's something I want to fix. 

> Actually, when I looked at it again, I found that the read() call (in the 
ok.

> Anyway, the TextView was just a test arena for showing the incoming data, 
> so it's not a showstopper for me. I just hope the problem won't pop up 
> with other components :)
There are a few bugs in text view. One of my aims for this summer was to
fix these and get a copy of the gtk-demo text view example running.
Unfortunately I've not had any time to do this.

> BTW, what's your role in java-gnome? Are you a main developer or?
I'm just one of the developers. I did a lot of work on the graphical
bits of the gtk widgets, before I knew much JNI. Then I moved on and
sorted out the treeview and started the textview and wrote CustomEvents.
I've written a very large application with java-gnome (bugwatcher - like
an email client, but for bugs) - this has helped find bugs in java-gnome. 
There are a few developers who contribute occasionally. Unfortunately
none of us have lots of time. 

-- 
  .''`. Mark Howard
 : :' :
 `. `'  http://www.tildemh.com 
   `-   mh...@de... | mh...@ti... | mh...@ca...