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

RE: [Java-gnome-developer] handlers as ints?

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

> On Mon, Nov 17, 2003 at 01:33:56PM -0500, Jeffrey Morgan wrote:
> > This raises a question.  I currently do not have access to a 
> > 64 bit system so testing now and going forward will be difficult.  
> > How can we gain access to a 64 bit system for testing java-gnome.
> 
> Sourceforge compile farm has a couple of 64 bit machines

I have already posted a question to the support group at
Sourceforge asking is X and the gtk/gnome libraries are
available on the compile farm systems.  I will let you
know once I hear a response.

-Jeff

Re: [Java-gnome-developer] handlers as ints?

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

On Mon, Nov 17, 2003 at 01:33:56PM -0500, Jeffrey Morgan wrote:
> This raises a question.  I currently do not have access to a 
> 64 bit system so testing now and going forward will be difficult.  
> How can we gain access to a 64 bit system for testing java-gnome.

Sourceforge compile farm has a couple of 64 bit machines

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

RE: [Java-gnome-developer] handlers as ints?

[R. A. R. D. <riv...@ya...>]

--- Jeffrey Morgan <Jef...@Br...> wrote:
> > Yep, the code have to be changed. :-(
> > 
> > I have seen also a function to obtain a gtk object from the java
> > equivalent, I hope that updating this function makes most of the
> work.
> > If this is not the case or I misunderstand the code, then I suppose
> > every component native code need to be updated :-(.
> > 
> > I think that's the better aproach.
> > 
> > I volunteer to help on it and send the code changed to anyone 
> > available
> > to check my work, but first I prefer to check if the developers
> accept
> > the change.
> 
> This will be a fairly large undertaking.  Almost all native
> methods currently take an integer (the native handle) as the
> first parameter.  All of these would have to be changed.  Before
> we undertake such a large change I would like to perform a 
> little proof-of-concept.  Let's make a change to a couple of
> objects and then test on a 32 and 64 bit platform.  Rivas, could
> you structure such a test?
> 
> This raises a question.  I currently do not have access to a 
> 64 bit system so testing now and going forward will be difficult.  
> How can we gain access to a 64 bit system for testing java-gnome.
> 

I can try it, but only on 32 bits. I don't have an 64 bit computer to
test the other part.
It will also help me to familiarize with the library.

rivas.


__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree

RE: [Java-gnome-developer] handlers as ints?

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

> Yep, the code have to be changed. :-(
> 
> I have seen also a function to obtain a gtk object from the java
> equivalent, I hope that updating this function makes most of the work.
> If this is not the case or I misunderstand the code, then I suppose
> every component native code need to be updated :-(.
> 
> I think that's the better aproach.
> 
> I volunteer to help on it and send the code changed to anyone 
> available
> to check my work, but first I prefer to check if the developers accept
> the change.

This will be a fairly large undertaking.  Almost all native
methods currently take an integer (the native handle) as the
first parameter.  All of these would have to be changed.  Before
we undertake such a large change I would like to perform a 
little proof-of-concept.  Let's make a change to a couple of
objects and then test on a 32 and 64 bit platform.  Rivas, could
you structure such a test?

This raises a question.  I currently do not have access to a 
64 bit system so testing now and going forward will be difficult.  
How can we gain access to a 64 bit system for testing java-gnome.

-Jeff

[Java-gnome-developer] Java-Gnome 0.8.1

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

The Java-Gnome project is proud to announce the recent releases of
java-gnome 0.8 and 0.8.1 bringing full support for gtk/gnome 2, many bug
fixes and performance enhancements. These latest releases represent
major progress for the Java-Gnome project. Some reasonably large
applications have already been developed with Java-Gnome and there has
been much interest from new Java-Gnome developers.


Java-Gnome is a set of libraries for creating GTK and GNOME applications
in the Java programming language. This has two user bases:

- Java developers wanting an intuitive well designed API for creating
  Graphical applications, as well as robust automatic GUI building tools
  via the glade program (using libglade). 
- Gnome developers wanting a simpler API for writing graphical
  applications, taking advantage of the many java libraries and without
  having to worry about memory.

Java-Gnome supports the latest major releases of GNOME, GTK and Glade,
as well as a number of smaller libraries such as libvte. 

Performance is similar to that of native gnome applications. 
Java-Gnome builds and runs using entirely free software, however the
license does not impose on users wanting to create commercial products
with Java-Gnome. 


Java-Gnome is available from the website as source tarballs (for
compilation to Java bytecode, or compilation to Native libraries using
gcj so that applications will not require a JVM in order to run), rpm
packages. Java-Gnome is also available in the Debian sid distribution in
the packages libgnome0-java, libgtk0-java, libgnome0-java and
libjava-gnome-doc.

Please feel free to distribute this announcement to any groups you feel
might be interested. If you have any questions or comments, please
address them to jav...@li...

--
The Java-Gnome Team
http://java-gnome.sf.net
  
-- 
  .''`. Mark Howard
 : :' :
 `. `'  http://www.tildemh.com 
   `-   mh...@de... | mh...@ti... | mh...@ca... 

Re: [Java-gnome-developer] Why is UIInfo.end() required?

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

> what do you think?
I agree completely. 
The only reason I haven't made this change is that I feel there are also
many other changes needed in UIInfo to allow access to other
functionality. I posted a message here about this and later copied it to
a bug report on sourceforge asking for opinions about how UIInfo should
be structured. Please could you read this and add your opinions as
comments to the bug report.

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

RE: [Java-gnome-developer] TreeSelection doesn't allow MULTIPLE s elections

[Luca De R. <pie...@li...>]

Il lun, 2003-11-17 alle 18:27, Jeffrey Morgan ha scritto:
> There was a bug in SelectionMode that has been fixed and
> checked into cvs.
> 
> -Jeff
Il lun, 2003-11-17 alle 18:26, Mark Howard ha scritto: 
> Jeff committed a fix for this earlier today. Updating to latest cvs
> should fix it.
> 
Thanks, as usual I have to wait the cvs to synchronize... ;)

Luca.
-- 
Luca De Rugeriis <pie...@li...>

[Java-gnome-developer] Why is UIInfo.end() required?

[R. A. R. D. <riv...@ya...>]

Hello

Reading the tutorial in the section related to menus
(http://java-gnome.sourceforge.net/docs/GNOME-tutorial/x133.html)
I read that on every menu there is a need to add at the end of every
UIInfo[] one with the code UIInfo.end(). In C this is a necesity 'cause
we need to say where is the end one way or the other, but as we know,
in Java the length of the array is always obtained directly from the
array object.
I think that the native code that receives the array of UIInfo should
automatically put the termination field in the C structure
automatically based on the length of the array. That way the code is
more Java like and with the good extra of avoiding to create one extra
object in java.
Also compatibility can be maintained checking if the last object is an
UIInfo.end() result (haven't checked this function code but I suppose
is easy to check for it).
Maybe this was added to maintain as much similarity as possible with
the equivalent C code, but anyway gnome-java also has added some other
facilities, for example in the section of TreeView
(http://java-gnome.sourceforge.net/docs/GNOME-tutorial/x765.html)
the tutorial says that gnome-java has added simple classes to handle
the complex TreeView widget.
I think that removing this extra node in the java side can represent
that starters will never forget to put this node (will be no need! :-)
) and also maybe make the library easier.

what do you think?

Rivas


__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree

Re: [Java-gnome-developer] TreeSelection doesn't allow MULTIPLE selections

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

Jeff committed a fix for this earlier today. Updating to latest cvs
should fix it.

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

RE: [Java-gnome-developer] TreeSelection doesn't allow MULTIPLE s elections

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

There was a bug in SelectionMode that has been fixed and
checked into cvs.

-Jeff

> Hi,
> Have you experienced this too?
> It is clearly visible for me in the TreeStoreExample. It reads:
> 
> TreeSelection ts = tree.getSelection();
>         ts.setMode(SelectionMode.MULTIPLE);
> 
> but actually I can't select multiple rows.
> I really need this in the CroMagnon app, where I'm using similar code,
> so if no one sees this bug, it's time for me to update gtk;)
> 
> Thanks,
> Luca.
> -- 
> Luca De Rugeriis <pie...@li...>
> 
> 
> 
> -------------------------------------------------------
> This SF. Net email is sponsored by: GoToMyPC
> GoToMyPC is the fast, easy and secure way to access your computer from
> any Web browser or wireless device. Click here to Try it Free!
> https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/
g22lp.tmpl
_______________________________________________
java-gnome-developer mailing list
jav...@li...
https://lists.sourceforge.net/lists/listinfo/java-gnome-developer

[Java-gnome-developer] TreeSelection doesn't allow MULTIPLE selections

[Luca De R. <pie...@li...>]

Hi,
Have you experienced this too?
It is clearly visible for me in the TreeStoreExample. It reads:

TreeSelection ts = tree.getSelection();
        ts.setMode(SelectionMode.MULTIPLE);

but actually I can't select multiple rows.
I really need this in the CroMagnon app, where I'm using similar code,
so if no one sees this bug, it's time for me to update gtk;)

Thanks,
Luca.
-- 
Luca De Rugeriis <pie...@li...>

RE: [Java-gnome-developer] handlers as ints?

[R. A. R. D. <riv...@ya...>]

--- Jeffrey Morgan <Jef...@Br...> wrote:
> > Hello
> > 
> > Checking the docs I have found that handlers are treated as java
> ints.
> > As we know ints are fixed 32 bits in Java, I wonder what will 
> > happen in
> > 64bits OSes? As I see it, two solutions are posible: 1. Have a
> handler
> > table to make the conversion, 2. Change everything to long and
> > recompile.
> > None of this is a good solution.
> > I think using a java.awt Peer like solution works better. Hiding
> the
> > handler in an interface that can be implemented in every platform
> is a
> > way to work around this problem without the need to change the
> library
> > in every platform.
> > Something like:
> > 
> > public interface Handler {}
> > 
> > public class GObject {
> >     public GObject(Handler handler) {
> >       ...
> >     }
> >     ...
> > }
> > 
> > In native code, every platform have to implement a pair of
> functions
> > like the following:
> > 
> > int javaToNative(JObject * handler); // receives a Handler instance
> > JObject * nativeToJava(int handler); // returns a Handler instance
> > 
> > probably inline functions that should be used whenever is necesary
> to
> > access a handler.
> > 
> > Then you can have a OS32bitHandler with a java int field inside,
> and a
> > OS64bitHandler with a java long field inside, and the code in
> > javaToNative and nativeToJava will conditionally use one of those
> > implementations depending on the arch.
> > 
> > What do you think?
> 
> It seems like a reasonable solution but will we not
> have to change all code that passes the int handle
> to use jobject instead?
> 
> -Jeff
> 
Yep, the code have to be changed. :-(

I have seen also a function to obtain a gtk object from the java
equivalent, I hope that updating this function makes most of the work.
If this is not the case or I misunderstand the code, then I suppose
every component native code need to be updated :-(.

I think that's the better aproach.

I volunteer to help on it and send the code changed to anyone available
to check my work, but first I prefer to check if the developers accept
the change.

rivas.


__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree

Re: [Java-gnome-developer] cvs problems

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

On Mon, Nov 17, 2003 at 10:35:42AM -0500, Jeffrey Morgan wrote:
> in some code.  Mark, please take a look at the
> changes I just made to the TreeModel, etc.  I 
> think I fixed the problem reported earlier but
> hope I didn't break something else.

My large apps still work fine. The patches look valid too.

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

Re: [Java-gnome-developer] handlers as ints?

[R. A. R. D. <riv...@ya...>]

--- Mark Howard <mh...@ca...> wrote:
> On Mon, Nov 17, 2003 at 10:53:35AM -0500, Jeffrey Morgan wrote:
> > > 64bits OSes? As I see it, two solutions are posible: 1. Have a
> handler
> > > table to make the conversion, 2. Change everything to long and
> > > recompile.
> 
> Since we're using jni, some recompilation will have to be done for
> each
> architecture anyway. Why is it such a bad thing to use longs on 64
> bit
> architectures and ints on the others?
> 

Advantages
1. Only one code to handle all architectures. Only a tiny piece of C
code have to be conditionally compiled on every platform. The rest is
the same.

2. Java code can't play with handlers, they can just take it, not
operate it, thus avoiding possible bugs.

3. Once the gnome-java package is installed in a platform, the
applications on top of it are truly platform independent, so for final
users is easier to install: they don't need to download the sources and
compile, they only need to download the application and install it, it
will work on any architecture. That's one of the beauties of Java.

corollary: Commercial applications based only on gnome-java and other
java packages will be available on all architectures, not only in x86
as is the usual.

> I would expect your proposal to have unnecessary run-time performance
> hits.

Portability ussually have a cost, in this case one more indirection
when accessing a GTK/GNOME handler (Instead of get int handle field, it
should be get Handle field, then get int/long handle field).
In my case I vote for one more indirection with total arch
independence.

Rivas.


__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree

Re: [Java-gnome-developer] cvs problems

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

On Mon, Nov 17, 2003 at 10:35:42AM -0500, Jeffrey Morgan wrote:
> I have seen this problem over the past week.  It
> appears to be working now as I have just checked
> in some code.  
Re-exporting CVS_RSH=ssh seems to make it work every time now.

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

Re: [Java-gnome-developer] handlers as ints?

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

On Mon, Nov 17, 2003 at 10:53:35AM -0500, Jeffrey Morgan wrote:
> > 64bits OSes? As I see it, two solutions are posible: 1. Have a handler
> > table to make the conversion, 2. Change everything to long and
> > recompile.

Since we're using jni, some recompilation will have to be done for each
architecture anyway. Why is it such a bad thing to use longs on 64 bit
architectures and ints on the others?

I would expect your proposal to have unnecessary run-time performance
hits.

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

RE: [Java-gnome-developer] handlers as ints?

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

> Hello
> 
> Checking the docs I have found that handlers are treated as java ints.
> As we know ints are fixed 32 bits in Java, I wonder what will 
> happen in
> 64bits OSes? As I see it, two solutions are posible: 1. Have a handler
> table to make the conversion, 2. Change everything to long and
> recompile.
> None of this is a good solution.
> I think using a java.awt Peer like solution works better. Hiding the
> handler in an interface that can be implemented in every platform is a
> way to work around this problem without the need to change the library
> in every platform.
> Something like:
> 
> public interface Handler {}
> 
> public class GObject {
>     public GObject(Handler handler) {
>       ...
>     }
>     ...
> }
> 
> In native code, every platform have to implement a pair of functions
> like the following:
> 
> int javaToNative(JObject * handler); // receives a Handler instance
> JObject * nativeToJava(int handler); // returns a Handler instance
> 
> probably inline functions that should be used whenever is necesary to
> access a handler.
> 
> Then you can have a OS32bitHandler with a java int field inside, and a
> OS64bitHandler with a java long field inside, and the code in
> javaToNative and nativeToJava will conditionally use one of those
> implementations depending on the arch.
> 
> What do you think?

It seems like a reasonable solution but will we not
have to change all code that passes the int handle
to use jobject instead?

-Jeff

RE: [Java-gnome-developer] Problems with TreeView

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

I forgot to mention that there was an API change with
this fix.  I renamed the TreeStore method moveIterNext
to getNextIter and the method now returns a TreeIter
or null if at the end of the list.  This allows you
to do the following:

TreeIter anIter = listStore.getFirstIter();

	while (anIter != null) {
		// do something here
		anIter = listStore.getNextIter(anIter);
	}

-Jeff

> Please checkout the code in cvs.  I believe I have
> fixed the problem.  To see it work you can look
> at the updated TestGTK application.  Please let
> me know if you are still having problems.
> 
> -Jeff
> 
> > Apparently something got broken from 0.8 to 0.8.1 in what 
> > regards to the
> > TreeView component.
> > Considering the following defenitions:
> > DataBlockInt dataIndex = new DataBlockInt();
> > DataBlockString dataName = new DataBlockString();
> > DataBlockBoolean dataExtract = new DataBlockBoolean();
> > ListStore list = new ListStore(new DataBlock[]{dataIndex, 
> dataExtract,
> > dataName});
> > 
> > While this still does not work properly (without showing a warning):
> > // To get wheter or not the item is selected
> > TreeIter i = list.getIter(String.valueOf(index));
> > return list.getValue(i, dataExtract);
> > 
> > Now this does not work too:
> > // Now to get the name of the item
> > TreeIter iter = list.getIter(String.valueOf(index));
> > return list.getValue(iter, dataName);
> > 
> > This used to work before, now i feel obligated to have a 
> java copy of
> > the names in a List as i already do for the boolean field 
> (extract or
> > not), getting these fields from the treeview generates the following
> > error:
> > 
> > (java-gnome:29591): GLib-GObject-WARNING **: gvalue.c:86: cannot
> > initialize GValue with type `gchararray', the value has already been
> > initialized as `gchararray'
> > 
> > I am going to try to find out through the diffs what broke this and
> > maybe we can get the bolean value to work too.
> > 
> > Tiago Cogumbreiro
> > 
> > 
> > 
> > -------------------------------------------------------
> > This SF. Net email is sponsored by: GoToMyPC
> > GoToMyPC is the fast, easy and secure way to access your 
> computer from
> > any Web browser or wireless device. Click here to Try it Free!
> > https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/
> g22lp.tmpl
> _______________________________________________
> java-gnome-developer mailing list
> jav...@li...
> https://lists.sourceforge.net/lists/listinfo/java-gnome-developer
> 
> 
> -------------------------------------------------------
> This SF. Net email is sponsored by: GoToMyPC
> GoToMyPC is the fast, easy and secure way to access your computer from
> any Web browser or wireless device. Click here to Try it Free!
> https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/
g22lp.tmpl
_______________________________________________
java-gnome-developer mailing list
jav...@li...
https://lists.sourceforge.net/lists/listinfo/java-gnome-developer

RE: [Java-gnome-developer] Problems with TreeView

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

Please checkout the code in cvs.  I believe I have
fixed the problem.  To see it work you can look
at the updated TestGTK application.  Please let
me know if you are still having problems.

-Jeff

> Apparently something got broken from 0.8 to 0.8.1 in what 
> regards to the
> TreeView component.
> Considering the following defenitions:
> DataBlockInt dataIndex = new DataBlockInt();
> DataBlockString dataName = new DataBlockString();
> DataBlockBoolean dataExtract = new DataBlockBoolean();
> ListStore list = new ListStore(new DataBlock[]{dataIndex, dataExtract,
> dataName});
> 
> While this still does not work properly (without showing a warning):
> // To get wheter or not the item is selected
> TreeIter i = list.getIter(String.valueOf(index));
> return list.getValue(i, dataExtract);
> 
> Now this does not work too:
> // Now to get the name of the item
> TreeIter iter = list.getIter(String.valueOf(index));
> return list.getValue(iter, dataName);
> 
> This used to work before, now i feel obligated to have a java copy of
> the names in a List as i already do for the boolean field (extract or
> not), getting these fields from the treeview generates the following
> error:
> 
> (java-gnome:29591): GLib-GObject-WARNING **: gvalue.c:86: cannot
> initialize GValue with type `gchararray', the value has already been
> initialized as `gchararray'
> 
> I am going to try to find out through the diffs what broke this and
> maybe we can get the bolean value to work too.
> 
> Tiago Cogumbreiro
> 
> 
> 
> -------------------------------------------------------
> This SF. Net email is sponsored by: GoToMyPC
> GoToMyPC is the fast, easy and secure way to access your computer from
> any Web browser or wireless device. Click here to Try it Free!
> https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/
g22lp.tmpl
_______________________________________________
java-gnome-developer mailing list
jav...@li...
https://lists.sourceforge.net/lists/listinfo/java-gnome-developer

RE: [Java-gnome-developer] cvs problems

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

I have seen this problem over the past week.  It
appears to be working now as I have just checked
in some code.  Mark, please take a look at the
changes I just made to the TreeModel, etc.  I 
think I fixed the problem reported earlier but
hope I didn't break something else.

-Jeff

> Hi,
>   Has anyone else noticed problems with developer cvs access? I've not
> been able to connect for a few days (anonymous cvs works fine)
> 
> java-gnome$ cvs up
> rsh: connect(cvs.java-gnome.sourceforge.net [66.35.250.207]): 
> Connection timed out
> rsh: getaddrinfo: Servname not supported for ai_socktype
> cvs [update aborted]: end of file from server (consult above 
> messages if any)
> 
> -- 
>   .''`. Mark Howard
>  : :' :
>  `. `'  http://www.tildemh.com 
>    `-   mh...@de... | mh...@ti... | mh...@ca... 
> 
> 
> -------------------------------------------------------
> This SF. Net email is sponsored by: GoToMyPC
> GoToMyPC is the fast, easy and secure way to access your computer from
> any Web browser or wireless device. Click here to Try it Free!
> https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/
g22lp.tmpl
_______________________________________________
java-gnome-developer mailing list
jav...@li...
https://lists.sourceforge.net/lists/listinfo/java-gnome-developer

[Java-gnome-developer] cvs problems

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

Hi,
  Has anyone else noticed problems with developer cvs access? I've not
been able to connect for a few days (anonymous cvs works fine)

java-gnome$ cvs up
rsh: connect(cvs.java-gnome.sourceforge.net [66.35.250.207]): Connection timed out
rsh: getaddrinfo: Servname not supported for ai_socktype
cvs [update aborted]: end of file from server (consult above messages if any)

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

RE: [Java-gnome-developer] Re: Problems with TreeView

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

Please open a bug report on the java-gnome site for
this item.  I will try to look into it today.

-Jeff


> On Seg, 2003-11-17 at 09:14, Tiago Cogumbreiro wrote:
> > Apparently something got broken from 0.8 to 0.8.1 in what 
> regards to the
> > TreeView component.
> > Considering the following defenitions:
> > DataBlockInt dataIndex = new DataBlockInt();
> > DataBlockString dataName = new DataBlockString();
> > DataBlockBoolean dataExtract = new DataBlockBoolean();
> > ListStore list = new ListStore(new DataBlock[]{dataIndex, 
> dataExtract,
> > dataName});
> > 
> > While this still does not work properly (without showing a warning):
> > // To get wheter or not the item is selected
> > TreeIter i = list.getIter(String.valueOf(index));
> > return list.getValue(i, dataExtract);
> > 
> > Now this does not work too:
> > // Now to get the name of the item
> > TreeIter iter = list.getIter(String.valueOf(index));
> > return list.getValue(iter, dataName);
> > 
> > This used to work before, now i feel obligated to have a 
> java copy of
> > the names in a List as i already do for the boolean field 
> (extract or
> > not), getting these fields from the treeview generates the following
> > error:
> > 
> > (java-gnome:29591): GLib-GObject-WARNING **: gvalue.c:86: cannot
> > initialize GValue with type `gchararray', the value has already been
> > initialized as `gchararray'
> > 
> > I am going to try to find out through the diffs what broke this and
> > maybe we can get the bolean value to work too.
> > 
> > Tiago Cogumbreiro
> As you might've guessed the problems are with ListStore and not with
> TreeView, sry ;)
> 
> 
> 
> -------------------------------------------------------
> This SF. Net email is sponsored by: GoToMyPC
> GoToMyPC is the fast, easy and secure way to access your computer from
> any Web browser or wireless device. Click here to Try it Free!
> https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/
g22lp.tmpl
_______________________________________________
java-gnome-developer mailing list
jav...@li...
https://lists.sourceforge.net/lists/listinfo/java-gnome-developer

RE: [Java-gnome-developer] Widget Mappings

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

At this time there is not a document that maps the objects
but the typical approach was to remove the prefix (gtk, etc)
for the class name.  For example, the GtkTextView object in
gtk would be called TextView in java-gnome and GtkEntry would
be called Entry.

-Jeff

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi,
> Just wondering if there is a list of mappings from gtk widgets to what
> we would use in java code, for example a gtkText to an Entry field?
> 
> Thanks
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.3 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
> 
> iD8DBQE/uAUEyheqWpsy0vsRAmp0AJ40gLwyAh9C2GLX0O5ytiQ1cgOIIQCfe/kc
> k7fWeydZVu/x2S437fZbxkI=
> =SRHb
> -----END PGP SIGNATURE-----
> 
> 
> 
> -------------------------------------------------------
> This SF. Net email is sponsored by: GoToMyPC
> GoToMyPC is the fast, easy and secure way to access your computer from
> any Web browser or wireless device. Click here to Try it Free!
> https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/
g22lp.tmpl
_______________________________________________
java-gnome-developer mailing list
jav...@li...
https://lists.sourceforge.net/lists/listinfo/java-gnome-developer

RE: [Java-gnome-developer] naming and distribution issues

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

> Now we have:
> /usr/lib/libGNOMEJAR.so
> /usr/lib/libGNOMEJar.so.0.8.1
> /usr/lib/libGNOMEJava.so
> /usr/lib/libGNOMEJava.so.0.8.1
> /usr/lib/libGTKJAR.so
> /usr/lib/libGTKJar.so.0.8.1
> /usr/lib/libGTKJava.so
> /usr/lib/libGTKJava.so.0.8.1
> /usr/lib/libGladeJAR.so
> /usr/lib/libGladeJar.so.0.8.1
> /usr/lib/libGladeJava.so
> /usr/lib/libGladeJava.so.0.8.1
> 
> Why do we have JAR in capitals?
> I vote to put all the names like: libGnomeJava, libGnomeJar, 
> libGtkJava,
> libGtkJar, libGladeJava, libGladeJar so we'll avoid all this caps
> confusion. Also it doesn't seem correct to me to have 
> libGNOMEJava while
> on the other hand libGladeJava. Don't you see this as a discrepancy?

Good point.  I will make sure this happens prior to
the next release.

-Jeff

[Java-gnome-developer] Re: Problems with TreeView

[Tiago C. <cog...@li...>]

On Seg, 2003-11-17 at 09:14, Tiago Cogumbreiro wrote:
> Apparently something got broken from 0.8 to 0.8.1 in what regards to the
> TreeView component.
> Considering the following defenitions:
> DataBlockInt dataIndex = new DataBlockInt();
> DataBlockString dataName = new DataBlockString();
> DataBlockBoolean dataExtract = new DataBlockBoolean();
> ListStore list = new ListStore(new DataBlock[]{dataIndex, dataExtract,
> dataName});
> 
> While this still does not work properly (without showing a warning):
> // To get wheter or not the item is selected
> TreeIter i = list.getIter(String.valueOf(index));
> return list.getValue(i, dataExtract);
> 
> Now this does not work too:
> // Now to get the name of the item
> TreeIter iter = list.getIter(String.valueOf(index));
> return list.getValue(iter, dataName);
> 
> This used to work before, now i feel obligated to have a java copy of
> the names in a List as i already do for the boolean field (extract or
> not), getting these fields from the treeview generates the following
> error:
> 
> (java-gnome:29591): GLib-GObject-WARNING **: gvalue.c:86: cannot
> initialize GValue with type `gchararray', the value has already been
> initialized as `gchararray'
> 
> I am going to try to find out through the diffs what broke this and
> maybe we can get the bolean value to work too.
> 
> Tiago Cogumbreiro
As you might've guessed the problems are with ListStore and not with
TreeView, sry ;)