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

[java-gnome-hackers] Bug tracking

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

Hi,
  Could you please give me more user (howama) rights for the java-gnome bug
tracking so I can set priorities and assign bugs.

Also, it would be great if you would set up sourceforge to send out
emails to the mailing lists when things are added to the bug tracking
system.


thanks

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

[java-gnome-hackers] FAQ on website

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

Hi, 
  I've just been reading the FAQ on the website and have a few comments:

Q: Which version of GTK and GNOME do you use?
Please add a note saying that it is also commonly used with gtk 2.2

Q: Does Java-GNOME work for Vendor X's JDK/JRE version Y?
Have these been tested recently?

If you want to add some, I use java-gnome with:
Blackdown-1.4.1-01
gcj 3.2 
gcj 3.3

Q: Can Java-GNOME read glade files like libglade?
Point out that these must be the new style glade xml files for gtk/gnome
2


new entry:
Q: cannot open shared object file: No such file or directory
This may occur when you have correctly compiled and installed java-gnome
and are trying to run some java-gnome applications. It means that the
system cannot find the java-gnome library. You must tell it where it is
by setting the appropriate environment variable, possibly by adding the
following to your .bash_profile file:
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/lib/jni

is that the default install dir? (It is for Debian)


Now time to look through the tutorial.
-- 
  .''`. Mark Howard
 : :' :
 `. `'  http://www.tildemh.com 
   `-   mh...@de... | mh...@ti... | mh...@ca... 

[java-gnome-hackers] FW: [Java-gnome-developer] RE: new release

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

I meant for forward this to the hackers list.

-----Original Message-----
From: Jeffrey Morgan [mailto:Jef...@Br...]
Sent: Sunday, July 06, 2003 11:32 AM
To: 'Alberto Gimeno'
Cc: 'jav...@li...'
Subject: [Java-gnome-developer] RE: new release


How about:

After much hard work and a complete rewrite we are pleased
to announce release 0.8 of the Java-GNOME bindings.  This
is the first release to support GTK-2 and GNOME-2.

Also, we should all agree on an update to the Roadmap.  I
would like to see several quick releases over the next
couple of months.  Perhaps something like:

0.8.1 - bug fix
0.8.2 - GConf and bug fixes
0.8.3 - gnome-print and bug fixes
0.9 - Bonobo and bug fixes

Alberto, please feel free to announce the new release
wherever you wish.

-Jeff

> -----Original Message-----
> From: Alberto Gimeno [mailto:alb...@te...]
> Sent: Sunday, July 06, 2003 11:01 AM
> To: Jeffrey Morgan
> Subject: Re: new release
> 
> 
> Hello.
> 
> I have updated the web, the GNOME-Tutorial and the javadoc
> documentation.
> I need the text announcing the new release to put ition the news page.
> Tomorrow, if you are agree, I will announce the new release in
> GNOME-Hispano <http://noticias.es.gnome.org> and javaHispano
> <http://www.javahispano.org>.
> 


-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01
_______________________________________________
java-gnome-developer mailing list
jav...@li...
https://lists.sourceforge.net/lists/listinfo/java-gnome-developer

[java-gnome-hackers] [VAC] July 3 - {July 14 | October 4}

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

Hi,
  I'm going away tomorrow for a week an a half. After that, I'll be
moving to Bristol, UK for the summer (work). I'm staying at Bristol uni
so hope to have internet access, but there's a chance I might have none
- assume this is the case if you don't hear from me.

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

RE: [java-gnome-hackers] Bugzilla

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

There already is the Sourceforge bug tracking at
http://sourceforge.net/tracker/?group_id=1522&atid=101522.

> -----Original Message-----
> From: Mark Howard [mailto:mh...@ti...]
> Sent: Monday, June 30, 2003 4:46 AM
> To: jav...@li...
> Subject: [java-gnome-hackers] Bugzilla
> 
> 
> Hi,
>   Is there any chance we can get a bugzilla system set up for 
> java-gnome
> (bugzilla.gnome.org?). A few issues have been reported on
> java-gnome-developer ML; it would be a shame to lose track of these.
> We'll probably be getting lots more too as more people find out about
> java-gnome
> 
> -- 
>   .''`. Mark Howard
>  : :' :
>  `. `'  http://www.tildemh.com 
>    `-   mh...@de... | mh...@ti... | mh...@ca... 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_06
> 1203_01/01
> _______________________________________________
> java-gnome-hackers mailing list
> jav...@li...
> https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers
> 

[java-gnome-hackers] Bugzilla

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

Hi,
  Is there any chance we can get a bugzilla system set up for java-gnome
(bugzilla.gnome.org?). A few issues have been reported on
java-gnome-developer ML; it would be a shame to lose track of these.
We'll probably be getting lots more too as more people find out about
java-gnome

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

RE: [java-gnome-hackers] Website - applications page

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

This looks great.  I will make sure this is on the web site
shortly.

-Jeff

-----Original Message-----
From: Mark Howard [mailto:mh...@ti...]
Sent: Tuesday, June 24, 2003 1:39 PM
To: jav...@li...
Subject: [java-gnome-hackers] Website - applications page


Hi,
  I've put some screenshots of my debbuggtk applications on the web, so
you might want to add something like the following to the applications
page of the website:

<h4><a href="http://debbuggtk.alioth.debian.org">DebbugGtk</a></h4>
<p>debbuggtk is a set of programs for viewing, searching and
manipulating the Debian GNU/Linux bug database. The main program,
bugwatcher, is similar to an email or news client. The complexity of the
interface can be seen in the <a
href="http://debbuggtk.alioth.debian.org/screenshots">screenshots</a>,
or the program source can be <a
href="http://packages.debian.org/debbuggtk">downloaded</a> (follow the
tar.gz link) and  tried out (Debian system not required).
<p>This is the first large program to be written using the java-gnome
gtk+2 implementation


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



-------------------------------------------------------
This SF.Net email is sponsored by: INetU
Attention Web Developers & Consultants: Become An INetU Hosting Partner.
Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
_______________________________________________
java-gnome-hackers mailing list
jav...@li...
https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers

Re: [java-gnome-hackers] jni/org_gnu_glade_LibGlade.c needs a #include <stdio>

[Jeffrey M. <ku...@zo...>]

This was not a problem on my system.  As I looked into it
I discovered it was due to the fact that the jni.h header
(which is included in the file) includes stdio.  I guess
it would be safest to include it in the file directly. 
Go ahead and commit your changes.

On Tue, 2003-06-24 at 13:34, Mark Howard wrote:
> Hi,
>  I'm finding jni/org_gnu_glade_LibGlade.c needs a #include <stdio> line
> adding to comile (stderr undefined).
> 
> I've not committed it to cvs yet simply because nobody else has - Is
> this file compiling for other people? Is it just my system setup?
-- 
Jeffrey Morgan <ku...@zo...>

[java-gnome-hackers] Website - applications page

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

Hi,
  I've put some screenshots of my debbuggtk applications on the web, so
you might want to add something like the following to the applications
page of the website:

<h4><a href="http://debbuggtk.alioth.debian.org">DebbugGtk</a></h4>
<p>debbuggtk is a set of programs for viewing, searching and
manipulating the Debian GNU/Linux bug database. The main program,
bugwatcher, is similar to an email or news client. The complexity of the
interface can be seen in the <a
href="http://debbuggtk.alioth.debian.org/screenshots">screenshots</a>,
or the program source can be <a
href="http://packages.debian.org/debbuggtk">downloaded</a> (follow the
tar.gz link) and  tried out (Debian system not required).
<p>This is the first large program to be written using the java-gnome
gtk+2 implementation


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

[java-gnome-hackers] LifeCycleEvent delete/Destroy

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

Hi,
  The handling of Delete and destroy GtkWidget signals seems odd at the
moment. They both should return boolean values for whether to propagate
the signal further.

At the moment, destroy always returns true and delete always returns
false. 
This seems odd to me, but I am not a Gtk expert. Could somebody please
explain why we do this? What do the events mean to a java application.

One thing I've noticed is that most of the example applications have 
window.addListener(new LifeCycleListener() {
  public void lifeCycleEvent(LifeCycleEvent event) {
    if (event.isOfType(LifeCycleEvent.Type.DESTROY))
      Gtk.mainQuit();
    }
});

When the window is closed (by pressing the close button), the window
disapears, but Gtk.mainQuit is not called, so the application does not
terminate. This can be fixed by looking for the DELETE event also.

Also, how can we write an application so that when the close button is
pressed, a method can be called (e.g. pop up a window asking if changes
should be saved) before the window disappears, and the disappearance of
the window can be determined by the results of that method?
-- 
  .''`. Mark Howard
 : :' :
 `. `'  http://www.tildemh.com 
   `-   mh...@de... | mh...@ti... | mh...@ca... 

[java-gnome-hackers] jni/org_gnu_glade_LibGlade.c needs a #include <stdio>

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

Hi,
 I'm finding jni/org_gnu_glade_LibGlade.c needs a #include <stdio> line
adding to comile (stderr undefined).

I've not committed it to cvs yet simply because nobody else has - Is
this file compiling for other people? Is it just my system setup?

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

RE: [java-gnome-hackers] g_object_ref

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

I do not like the unref() approach so I would vote for the
finalise() approach.  Since this could be a sizable change
I vote to make this a post 0.8 item.

-Jeff

-----Original Message-----
From: Mark Howard [mailto:mh...@ti...]
Sent: Tuesday, June 24, 2003 11:20 AM
To: jav...@li...
Subject: [java-gnome-hackers] g_object_ref


Hi,
  Looking back at my old program, I'm finding an old problem again. 

When GtkContainer.remove( widget ) is called, Gtk will destroy the
widget if it was the last item to own a reference to it. However, the
java object for the widget will still exist and can be passed to (say)
add methods.  In some cases, it is desirable to remove widgets
temporarily and then readd the,

The native solution to this problem is to call g_object_ref() to create
a reference to the object and then call g_object_unref()  when it is no
longer required. We could add these methods, but it is not very
Java-like - It would certainly allow memory leaks to be added to
programs and also would cause confusion. Instead, I think we should call
g_object_ref() whenever a Java object is constructed pointing to native
GObjects. Then we need to call g_object_unref when the user has finished
with the Java object; The only way I can think of doing this is either
have a finaliser and an explicit unref() method, or use
PhantomReferences 

Are there any better ways to do this?
-- 
  .''`. Mark Howard
 : :' :
 `. `'  http://www.tildemh.com 
   `-   mh...@de... | mh...@ti... | mh...@ca... 



-------------------------------------------------------
This SF.Net email is sponsored by: INetU
Attention Web Developers & Consultants: Become An INetU Hosting Partner.
Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
_______________________________________________
java-gnome-hackers mailing list
jav...@li...
https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers

[java-gnome-hackers] g_object_ref

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

Hi,
  Looking back at my old program, I'm finding an old problem again. 

When GtkContainer.remove( widget ) is called, Gtk will destroy the
widget if it was the last item to own a reference to it. However, the
java object for the widget will still exist and can be passed to (say)
add methods.  In some cases, it is desirable to remove widgets
temporarily and then readd the,

The native solution to this problem is to call g_object_ref() to create
a reference to the object and then call g_object_unref()  when it is no
longer required. We could add these methods, but it is not very
Java-like - It would certainly allow memory leaks to be added to
programs and also would cause confusion. Instead, I think we should call
g_object_ref() whenever a Java object is constructed pointing to native
GObjects. Then we need to call g_object_unref when the user has finished
with the Java object; The only way I can think of doing this is either
have a finaliser and an explicit unref() method, or use
PhantomReferences 

Are there any better ways to do this?
-- 
  .''`. Mark Howard
 : :' :
 `. `'  http://www.tildemh.com 
   `-   mh...@de... | mh...@ti... | mh...@ca... 

RE: [java-gnome-hackers] TODO list?

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

Mark,

Nice to hear from you.  I would really like to see a 0.8
release very soon (possibly as early as next week).  I
would suggest we only focus on three items prior to this
release.  They are:

1) Update the tutorial
2) Do a quick once over on the examples
3) Fix any glaring bugs in the bindings

I have already started to update the tutorial.  Please let
me know if you think there are other items to be completed
for the release.

-Jeff

-----Original Message-----
From: Mark Howard [mailto:mh...@ti...]
Sent: Tuesday, June 24, 2003 8:11 AM
To: jav...@li...
Subject: [java-gnome-hackers] TODO list?


Hi,
  I've now finally finished uni so hopefully have more time to work on
my projects. For the next 2 weeks, I will certainly be working on them
publicly. I will then have a week off followed by a move to Bristol. If
all goes well, I will then continue my work; if it doesn't, I may have
no internet access.

A couple of months ago, I sent an email asking for 0.8 release. This was
followed by a call for 0.8 release critical issues (with no response)
and little action (as far as I can see). I'd once again like to stress
that I think a release would be a major boost for the project but also
ask: what still needs to be done?

I plan to work on fixing gnome druids soon and any other bugs I find -
Having other people write applications and so find bugs would be useful;
I fear they are unwilling to do this as no releases have been made. 

I may also look into drag and drop features of treeviews. Is there
anything else I should be looking at.

I am quite interested in having my application support other gnome
libraries such as gconf and possibly bonobo. Are there any plans for
these? Can they be included with the main java-gnome source, or should
we split off subprojects for them? libvte seems to have beein included
with everything else. IMHO, not having separate sub-projects might make
this project too large to handle well.

In case anyone's interested, my java-gnome application, bugwatcher, is
now a substantial program. It now works reliably and is hopefully proof
that java-gnome is very useful in it's current state. I am continuing
work on this at present and will soon start converting an older program
to java-gnome.

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



-------------------------------------------------------
This SF.Net email is sponsored by: INetU
Attention Web Developers & Consultants: Become An INetU Hosting Partner.
Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
_______________________________________________
java-gnome-hackers mailing list
jav...@li...
https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers

[java-gnome-hackers] TODO list?

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

Hi,
  I've now finally finished uni so hopefully have more time to work on
my projects. For the next 2 weeks, I will certainly be working on them
publicly. I will then have a week off followed by a move to Bristol. If
all goes well, I will then continue my work; if it doesn't, I may have
no internet access.

A couple of months ago, I sent an email asking for 0.8 release. This was
followed by a call for 0.8 release critical issues (with no response)
and little action (as far as I can see). I'd once again like to stress
that I think a release would be a major boost for the project but also
ask: what still needs to be done?

I plan to work on fixing gnome druids soon and any other bugs I find -
Having other people write applications and so find bugs would be useful;
I fear they are unwilling to do this as no releases have been made. 

I may also look into drag and drop features of treeviews. Is there
anything else I should be looking at.

I am quite interested in having my application support other gnome
libraries such as gconf and possibly bonobo. Are there any plans for
these? Can they be included with the main java-gnome source, or should
we split off subprojects for them? libvte seems to have beein included
with everything else. IMHO, not having separate sub-projects might make
this project too large to handle well.

In case anyone's interested, my java-gnome application, bugwatcher, is
now a substantial program. It now works reliably and is hopefully proof
that java-gnome is very useful in it's current state. I am continuing
work on this at present and will soon start converting an older program
to java-gnome.

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

Re: [java-gnome-hackers] java-gnome future

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

On Tue, 2003-04-22 at 21:30, Jeffrey Morgan wrote:
> I could not agree more.  I would like to see a release out soon
> followed by several quick releases addressing bugs, stability
> and api enhancements.

great

> I would like to get everybody's input on what should be completed
> prior to a release.  Also, let's place a time frame for the
> completion of these tasks.

Personally, I don't think there's anything pressing which could not wait
for a 0.9 release.

Testing the install scripts a little would be useful though.
-- 
  .''`. Mark Howard
 : :' :
 `. `'  http://www.tildemh.com 
   `-   mh...@de... | mh...@ti... | mh...@ca... 

Re: [java-gnome-hackers] java-gnome future

[Jeffrey M. <ku...@zo...>]

I could not agree more.  I would like to see a release out soon
followed by several quick releases addressing bugs, stability
and api enhancements.

I would like to get everybody's input on what should be completed
prior to a release.  Also, let's place a time frame for the
completion of these tasks.

On Fri, 2003-04-18 at 13:16, Mark Howard wrote:
> Hi,
>   I've been thinking this for a while, but have kept quiet so far.
> 
> Java-gnome is a good system. It is the only way of making gnome
> applications with java and so could be very useful for open source linux
> applications. There are many people developing these things. 
> 
> I am concerned that java-gnome is not getting the attention it needs. As
> a result, not enough people are contributing bug reports and patches (to
> both java-gnome and free JVMs). From this, we are in the situation where
> we haven't had a release supporting gtk2.0 despite gtk2.2 being released
> at the start of the year.
> I think the cause of this is the java-gnome release strategy. At the
> moment it seems to be that releases should be made only when we have a
> stable system and that developers can check out cvs - this rarely
> happens.
> 
> java-gnome seems to be going against the general open source tradition
> of releasing early and often. I personally feel that we should have many
> more releases - for example fixing the uiinfo code would warrant a
> release, as would the String handling changes and treemodel api changes.
> This means releasing code (as a development release - with adequate
> warnings) which is known to be broken in places and will have (possibly
> major) api changes between revisions. We would then probably get to 0.76
> before releasing version 1.0 - I have no problems with that. 
> 
> When these releases are made, people would see the announcements and so
> more people would hear about the project. More importantly, people who
> already know about the project will see that it's getting better and
> might feel like giving it a try. 
> 
> The release early and often strategy is proven to work - almost all open
> source projects do this for their development versions.
> 
> Why doesn't java-gnome follow this strategy?
> What does everyone else think about this?
-- 
Jeffrey Morgan <ku...@zo...>

[java-gnome-hackers] java-gnome future

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

Hi,
  I've been thinking this for a while, but have kept quiet so far.

Java-gnome is a good system. It is the only way of making gnome
applications with java and so could be very useful for open source linux
applications. There are many people developing these things. 

I am concerned that java-gnome is not getting the attention it needs. As
a result, not enough people are contributing bug reports and patches (to
both java-gnome and free JVMs). From this, we are in the situation where
we haven't had a release supporting gtk2.0 despite gtk2.2 being released
at the start of the year.
I think the cause of this is the java-gnome release strategy. At the
moment it seems to be that releases should be made only when we have a
stable system and that developers can check out cvs - this rarely
happens.

java-gnome seems to be going against the general open source tradition
of releasing early and often. I personally feel that we should have many
more releases - for example fixing the uiinfo code would warrant a
release, as would the String handling changes and treemodel api changes.
This means releasing code (as a development release - with adequate
warnings) which is known to be broken in places and will have (possibly
major) api changes between revisions. We would then probably get to 0.76
before releasing version 1.0 - I have no problems with that. 

When these releases are made, people would see the announcements and so
more people would hear about the project. More importantly, people who
already know about the project will see that it's getting better and
might feel like giving it a try. 

The release early and often strategy is proven to work - almost all open
source projects do this for their development versions.

Why doesn't java-gnome follow this strategy?
What does everyone else think about this?
-- 
  .''`. Mark Howard
 : :' :
 `. `'  http://www.tildemh.com
   `-   mh...@de... | mh...@ti... | mh...@ca... 

Re: [java-gnome-hackers] gnome UIInfo problems

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

Hi,
  I've committed some changes which fix these problems. UIInfo arrays
are now made into native arrays before the create_toolbar _menus
function calls. Other methods should only be called after create_ calls,
so there should be no problems with this. I've tested it and it works
great.
-- 
  .''`. Mark Howard
 : :' :
 `. `'  http://www.tildemh.com 
   `-   mh...@de... | mh...@ti... | mh...@ca... 

[java-gnome-hackers] Gnome druid page

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

Hi,
  I've been trying to create a gnome druid and noticed that the
DruidPage signals have been done wrong.
There are five signals
boolean back 
boolean cancel 
boolean next 
void finish 
void prepare

At present, the implementations think that they are all void functions
and ignore the druid widget parameter.

The boolean return values are to say whether the handler has handled the
event (i.e. changed the page manually). If false, the druid will change
the page where it can.

Finish and prepare are to allow pages to be constructed and destroyed
(or set up, etc.) just before/after coming into use. 

As there are two different groups of events, I would like to split this
event system:
DruidPageChangeEvent, 
   public boolean changePage(  Types BACK, NEXT and CANCEL 
DruidPagePreparationEvent
   public void preparePage( Types PREPARE, FINISH

I will also make sure that the parameters and return values are done
correctly.

Does this sound ok?
-- 
  .''`. Mark Howard
 : :' :
 `. `'  http://www.tildemh.com 
   `-   mh...@de... | mh...@ti... | mh...@ca... 

Re: [java-gnome-hackers] gnome UIInfo problems

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

On Fri, 2003-04-11 at 20:02, Jeffrey Morgan wrote:
> I will take a look at this over the weekend but I want to 
> look into the GtkEntry/GnomeEntry problem first.

Great, thanks.

I've thought of another, probably better solution.
Have a javaToNativeUIInfoArray function which takes a java array of
UIInfo, copies the native resources and updates the handle fields. This
would use a native method which takes an array of handles and returns an
array of handles.

This could be called in the Java methods for createMenu, etc. and then
create_menu, etc could then be modified to take the single handle of the
first item in the array.

We'd need some way of making sure that this is only done once for an
array though - otherwise it will mess up previous function calls. 
-- 
  .''`. Mark Howard
 : :' :
 `. `'  http://www.tildemh.com 
   `-   mh...@de... | mh...@ti... | mh...@ca... 

Re: [java-gnome-hackers] gnome UIInfo problems

[Jeffrey M. <ku...@zo...>]

I will take a look at this over the weekend but I want to 
look into the GtkEntry/GnomeEntry problem first.


On Fri, 2003-04-11 at 15:32, Mark Howard wrote:
> Hi,
>   When using gnome menus and toolbars, App.createToolbars does not seem
> to fill in the widget part of the UIInfos. As such, exceptions are
> raised on events from these widgets as the handler cannot construct a
> new Widget (using the handle -1).
> 
> Please can somebody more familiar with gnome and the UIInfo code take a
> look at this.
> 
> thanks
-- 
Jeffrey Morgan <ku...@zo...>

Re: [java-gnome-hackers] big TreeModel API change

[Jeffrey M. <ku...@zo...>]

Sounds good to me.  

On Fri, 2003-04-11 at 11:27, Mark Howard wrote:
> On Sat, 2003-03-22 at 13:18, Mark Howard wrote:
> > Hi, [...]
> > Abstract class dataBlock;
> > dataBlockInt extends dataBlock
> 
> I'd like to start work on this this weekend, unless there are any
> objections.
-- 
Jeffrey Morgan <ku...@zo...>

[java-gnome-hackers] Re: gnome UIInfo problems

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

Hi,
  I've now figured out what the problem is, but don't know how to fix
it.
This is all in org_gnu_gnome_App.c

Many methods require an array of GnomeUIInfo's (not an array of pointers
to them). app_getUIInfoArray creates such an array and fills it with
copies of the supplied UIInfos (supplied a a jintArray of handles)

Methods such as create_toolbar modify the uiinfos in the array (e.g.
setting the widget field). 
This is lost as Java only knows of the original uiinfos. 
(hmm. we also have a memory leak here -the copies are not freed)

So, how do we fix this?

One possibility would be to copy everything back to the original uiinfo
after calling the gnome method. It is only a few pointers, but seems
like an ugly hack.

I think UIInfo.setsubMenuInfo might also suffer from these problems. If
so, then the above solution would not work - instead we would have to
find some way of modifying the handles in the java objects to point to
these new copies of UIInfo.

Perhaps a better way to look at this would be to have a new object for
UIInfoArrays, which would actually be a native array of UIInfo and pass
this to the create_menu, etc. methods 

Any ideas? Have I missed anything?

On Fri, 2003-04-11 at 20:32, Mark Howard wrote:
> Hi,
>   When using gnome menus and toolbars, App.createToolbars does not seem
> to fill in the widget part of the UIInfos. As such, exceptions are
> raised on events from these widgets as the handler cannot construct a
> new Widget (using the handle -1).
> 
> Please can somebody more familiar with gnome and the UIInfo code take a
> look at this.
> 
> thanks
-- 
  .''`. Mark Howard
 : :' :
 `. `'  http://www.tildemh.com 
   `-   mh...@de... | mh...@ti... | mh...@ca... 

Re: [java-gnome-hackers] gnome conflicts with gtkentry

[Tom B. <Tom...@Su...>]

I'm fairly confident that the handle is bogus.  Not calling getString
may "fix" the problem, but only in that you aren't asking GTK to use a
bad handle, rather than fixing the cause of the bad handle.  One thing
I've learned over the years is how consistently I can be wrong, however.

Try using using memset to initialize the alloca buffer in jg_signal_cb
(0xca is a good value if you use a debugger, as pointers with that value
can't be dereferenced).  Using memset is an old trick for finding used
by not initialized memory -- a related trick is to memset freed memory
with a different but equally undereferencable value such as 0xba.  If
you want to be more sophisticated, paint the memory with words such as
"dead", "face", etc.  If possible, use a Unix-based system since Windows
allows dereferencing of non-aligned pointers, so you are more likely to
get a bad memory area that survives this test.

Tom

On Fri, 2003-04-11 at 12:21, Mark Howard wrote:
> On Tue, 2003-04-08 at 23:51, Tom Ball wrote:
> > it fails in EventKey.getString with a bogus eventkey handle.
> Are you sure it's bogus. The location certainly seems as vaild as the
> others. Commenting out the call to the native getString (in
> gdk.EventKey.getString) "fixes" the problems for me. 
> 
> The following is printed in the docs for the string field of GdkEventKey
> - perhaps we shouldn't be using GdkEventKey.string:
> 
> a string containing the an approximation of the text that would result
> from this keypress. The only correct way to handle text input of text is
> using input methods (see GtkIMContext), so this field is deprecated and
> should never be used. (gdk_unicode_to_keyval() provides a non-deprecated
> way of getting an approximate translation for a key.) The string is
> encoded in the encoding of the current locale (Note: this for backwards
> compatibility: strings in GTK+ and GDK are typically in UTF-8.) and
> NUL-terminated. In some cases, the translation of the key code will be a
> single NUL byte, in which case looking at length is necessary to
> distinguish it from the an empty translation.
-- 
Tom Ball <Tom...@Su...>