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

RE: [Java-gnome-developer] Development Status

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

> Tks for your answers. 
> I'm happy to read that there's a lot of synergy between Java-Gnome and
> SWT as I was fearing that too many similar-but-not-really-compatible
> projects were being developped. 
> 
> I have several remarks and questions divided below in remarks 
> regarding
> strategy and remarks concering technical points. 
> 
> 1) Strategy 
> 
> Is it so much useful to maintain Windows+Motif support ? Gnome on the
> desktop is making huge progress, whereas Windows doesn't innovate much
> and is therefore liable, in my opinion, to disappear in the 
> mid-term (5
> years?), because the system itself is conceptually too poor to compete
> with the various OS that the open-source community + 
> companies like IBM
> or Sun have coded in the last 20 years. 

It is not necessary to support Windows and Motif.  I believe it would be
useful to do so.  If SWT becomes a popular GUI toolkit many companies will
use it to develop applications that target Win32.  These applications will
be able to run immediately on GTK platforms.  Also, this makes it much
easier
for open-source applications to provide Windows ports.  In this way, the
Windows users will begin to be exposed to the great work that is taking
place in the open-source community.


> 2) Conception/technical points 
> 
> >A higher-level object-oriented API is needed in order to make
> >java-gnome really viable. 
> I think that's a very good idea to build a high-level OO GUI-API
> gathering the best features of Swing, Gtk, Qt, MFC + more (I actually
> thought at first it was already part of the Eclipse project). The key
> point probably relies on the community such a project is able 
> to gather;

I couldn't agree more.

> I believe many engineering schools (such as http://www.emn.fr/ in
> France, which works closely with OTI) would be interested in 
> joining the
> project both at a research level and at a coding effort 
> level; hopefully
> OTI team would also participate strongly, making the "high-level API"
> more quickly available for commercial-apps use. I guess the industry
> will need more and more advanced widgets, such as hyperbolic trees
> (http://treebolic.sortilege.net), smart tables like those in Gnumeric,
> advanced visualition tools etc., hence the availability of such an API
> could help the industry working better. 

I will be talking to OTI about this proposal very soon.  I am sure
they will be prohibited from direct involvement in the project but
they very likely would be interested in providing moral support 8-)
I am also going to float some of this idea to the core GTK/GNOME
developers at this weeks GNOME Summit.  I'll post my results on
this list.  Anybody interested in helping with some of the initial
planning is welcome.
 
> Which language in the mid-term for OO programming: Java, Python, C++ ?
> Is there any reason to keep using so many very close languages instead
> of focusing on theorical problems related to OO programming?

This is a very interesting topic.  I think solving the problems related
to providing a good OO programming paradigm for GUI development should
be the first step.  That is why I proposed first working on design related
issues.  Beyond this initial design effort, the structure of SWT would make
it
very easy/possible to provide the interface via additional languages.
SWT is structured as follows (if you can excuse the crude drawing):

  +------------+
  |   SWT API  |  - Written in Java
  +------------+
  |  PEER GLUE |  - Written in Java
  +------------+
  |    JNI     |  - Written in C
  +------------+
  | NATIVE PEER|
  +------------+

It is not a stretch to envision the following:

      +-------------------+
  C++ |      SWT API      |  Java - Same public API for both languages
      +-------------------+
      | C++  |  PEER GLUE |  Java
  C++ | GLUE +------------+
      | CODE |    JNI     |  C
      |      |------------+
      |      | NATIVE PEER|
      +------+------------+

The public C++ API could be almost identical to the public
Java API and could leverage the work already completed in
providing the native peer interface.  I am not proposing this
as part of the proposed project but it is an interesting idea.

> I'd be
> happy to know what Ximian developpers think about the OO language
> question, as they're making very good apps based on C/Gtk and Bonobo.

Ximian will be using C# once their C# compiler/environment is mature.

> Java is a cool language but I'm wondering sometimes if these guys are
> not going to produce a new LGPL Java-like language. I believe Java
> should now be released in true open-source, so that designers and
> developers from all companies could focus on a cooperative effort,
> without developing so many language-gateways (of course diversity is
> very important but here it looks like there is no real conceptual
> difference between Java, C++, Python, etc., or is there?). 
> 
> One last remark: Gnu/Linux is still missing the game in the games
> software area; it's obvious that encouraging the development 
> of games on
> Linux could help creating collectively advanced high-level generic
> OO-APIs for open-source graphical environnements 
> ("intelligent" games as
> far as possible of course). 
> 
> Regards 
> 
> Almo 
> 
> 

Re: [Java-gnome-developer] Development Status

[Clemens E. <Lin...@we...>]

Hi again!

>Which language in the mid-term for OO programming: Java, Python, C++ ?
>Is there any reason to keep using so many very close languages instead
>of focusing on theorical problems related to OO programming?
>(meta-objects protocols, automatic components assembling etc.). I'd be
>happy to know what Ximian developpers think about the OO language
>question, as they're making very good apps based on C/Gtk and Bonobo.
>Java is a cool language but I'm wondering sometimes if these guys are
>not going to produce a new LGPL Java-like language. I believe Java
>should now be released in true open-source, so that designers and
>developers from all companies could focus on a cooperative effort,
>without developing so many language-gateways (of course diversity is
>very important but here it looks like there is no real conceptual
>difference between Java, C++, Python, etc., or is there?).
>
Yes, this is probably a problem with openSource. But its nice for the 
developers. Each developer has his favourite language, and wants to 
develop with it. This is not so good for users (Look in /usr/lib :-( )
Yeah, there are some OpenSource Java-vm's. The most popular one is kaffe 
www.kaffe.org , but it isnt fully java2-compatible (Althought my fancy 
code runs on it). The biggest problem is that swing isnt supported at 
all . Java-GTK is supported, JIT  is not the fastest.
The second one is gcj. Its a native java-frontend to the famous gcc. It 
compiles java-code to natve binaries, wich are about 2x faster than 
interpreted code (First run of a loop) but much slower compared to code 
in jit (the loop looped some iterations). This is, because gcj does all 
heap-allocations with the os, not with its own memory-managemens (like sun).
The most importat project is the GNU-Classpath-Project. It tries to make 
a clean-room (without sun-code) Implementation of sun`s classes that can 
be used by all the GPLd VMs.

The biggest problem of those opensource-solutions is, that SWING isnt 
supported at all. Thats why I'm using Java-GTK. Of cource, its hard to 
port existing code to such opensource-vm's, but any code developed on an 
Opensource-vm should also run under the Sun-Vm. I developed my 
wine-configurator with those opensource-tools and I used the 
JDK1.2.2-Apidoks from sun. Except from the swing-packages I didn't miss 
any class or method.

> 
>
>One last remark: Gnu/Linux is still missing the game in the games
>software area; it's obvious that encouraging the development of games on
>Linux could help creating collectively advanced high-level generic
>OO-APIs for open-source graphical environnements ("intelligent" games as
>far as possible of course). 
>
Yeah, and I think that will never come. Too many people think that their 
stuff is the best (Look at java-gtk, it isn't very common and some 
people use it althought the user will have o compile libs...)
Trolltechs QT is very near to such a game of the games, but it stands 
under GPL and if you want to code a commercial app, you'll have to pay 
royalities. GTK's C interface is really terrible, and you'll need much 
libs to do all the stuff which is included in QT.

But I think this should be discussed in a development-forum.

cu Linuxhippy

>
>Regards 
>
>Almo 
>
>
>
>
>
>Le lun 15/07/2002 à 16:54, Jeffrey Morgan a écrit : 
>  
>
>>>Is there a possible synergy between Java/Gnome and IBM-SWT library
>>>(eclipse.org)? What's Java-Gnome position (technically and
>>>strategically) regarding IBM-SWT/JFace, which seems to run well on
>>>Gnome2.0 ? 
>>>      
>>>
>>There is a lot of synergy between these projects.  In fact, I am
>>currently working on the SWT project at the same time as working
>>on java-gnome.  There are a few problems with SWT that are being 
>>addressed.  They are:
>>
>>* SWT uses the GTK 1.x tree and list widgets (SWT team is working on this)
>>* SWT uses the GTK 1.x text widget (I am working on this)
>>* SWT/GTK does not have a consistent approach for NLS (SWT team is working
>>  on this)
>>* SWT relies on being able to utilize z-order.  GTK doesn't support z-order.
>>  The fix that was put in place is probably contributing to poor
>>performance.
>>  (This is an issue that I intend to bring up at this week's GNOME Summit)
>>* The SWT and GTK model for Composite/Child (SWT) and Container/Child (GTK)
>>  are very different.  As a result, SWT/GTK was forced to introduce hacks
>>  to handle widget sizing and positioning.  This is contributing to the poor
>>  performance.  (I also hope to bring this up at the GNOME Summit)
>>* SWT doesn't have close to full coverage of the APIs that are provided by
>>  GTK.  SWT also doesn't provide any coverage for the GNOME APIs. (See my
>>  proposed solution below)
>>
>>I intended to wait until my next release to put a proposal out to the
>>community but since you have touch on this topic I think I will do it now.
>>SWT will continue to mature at a rate that is much faster than java-gnome
>>due to the fact that IBM/OTI has full-time resources working on it.
>>Also, due to the fact that SWT runs natively on several platforms it will
>>gather much greater industry support.  At a low level, the way SWT is
>>accessing
>>the native peers is superior to the approach taken by java-gnome.  It would 
>>appear that SWT would be an ideal choice for somebody wanting to write a 
>>java application that will run on GTK.  You would also have the added
>>ability 
>>to support Motif, Win32, OSX Carbon, and other platforms.
>>
>>The primary problem with SWT is that it is not currently intended to be
>>a complete/robust GUI framework.  Not all widgets supported on the host
>>operating systems are supported on SWT.  Also, although JFace does provide
>>some higher-level facilities it is primary focused on providing a framework
>>for the eclipse platform.  At the same time, java-gnome attempts to map
>>directly to the underlying APIs provided by GTK and GNOME.  This makes
>>the java-gnome class library huge and very complex to use. A higher-level 
>>object-oriented API is needed in order to make java-gnome really viable.
>>
>>My proposal is for a new project (or a significant morph of java-gnome).
>>This new project would use SWT as it's foundation and would address the 
>>above mentioned issues.  This new project would not only focus on GTK.  
>>It would also provide support for Motif and Win32 (possibly others).  
>>Perhaps over time some of the code produced by this new project could 
>>be incorporated into SWT and some of it would stay independent of SWT.  
>>
>>A proposed task list to start the project follows:
>>
>>1) Identify lead developer for each of the platforms:
>>   GTK - Jeff Morgan
>>   Motif - ??
>>   Win32 - ??
>>
>>2) Define the new API and create an object model to be presented to the
>>   community:
>>   -I have spent a lot of time this year studying various GUI frameworks
>>(QT, 
>>    GTK, Motif, MFC).  I would like to begin a discussion with the
>>developers 
>>    on this new project to decide what functions should be included in this
>>    new GUI framework.  Perhaps it would be a combination of the best
>>features 
>>    of several of the mentioned frameworks.  The result of this discussion 
>>    would be an object model and a plan for development.  These artifacts
>>    would then be presented to the community at large for comments and 
>>    suggestions.
>>3) Once the design and plan are finalized create begin the effort.
>>
>>    
>>
>>>Do you know what Sun strategy is regarding Java integration into Gnome
>>>(Solaris will use Gnome as Desktop Environnement, but then which
>>>language will Sun recommend to build GUIs - as far as Swing 
>>>is obviously
>>>not fast enough to build advanced smooth GUIs ?
>>>      
>>>
>>Sun would have to answer this question.  At one time there was
>>much discussion about providing GTK peers for AWT.  I don't know
>>where this discussion went.
>>
>>
>>I would be very interested in hearing from the users of java-gnome
>>about the proposal put forth above.  Although it is a significant
>>departure from the current direction of this project I would be
>>interested in your views if it is the correct direction.
>>
>>-Jeff
>>    
>>
>
>
>
>-------------------------------------------------------
>This sf.net email is sponsored by:ThinkGeek
>Welcome to geek heaven.
>http://thinkgeek.com/sf
>_______________________________________________
>java-gnome-developer mailing list
>jav...@li...
>https://lists.sourceforge.net/lists/listinfo/java-gnome-developer
>
>  
>

RE: [Java-gnome-developer] Development Status

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

> I dont understand the sence of such a project. Its like "Hey,let us 
> build an MFC-Clone on the top of MFC".

That is one way to look at it.  Another view is that there will be 
more applications developed using SWT that will target Win32.  With
this approach, all of those applications will immediately run on
GTK platforms.

> But it would be a good idea , in that case we would have a strong 
> "partner" (IBM).
> 
> This things are very important for this project:
> 
> 1. A good gui-builder. (Maybe we could use a modifies 
> glade/libglade). I 
> love the way that java-gtk does!

There are already discussions going on about providing a GUI
builder for SWT that uses XML formats.  If SWT becomes as popular
as I think it might there will be several GUI builders available.
Again, we would be able to leverage the work done by IBM and others.

> 2. Garbage-Collection! The SWT-strategy is against java-standards.

This is an issue.  SWT does cause the developer to clean up some
of their own resources.  I don't see this changing anytime soon.

> 3. Clean, clear Interface. (Like Java-GTK)
> 
> I'm not good at coding but I would be able to produce some german and 
> english doks.
> 
> > I would be very interested in hearing from the users of java-gnome
> > about the proposal put forth above.  Although it is a significant
> > departure from the current direction of this project I would be
> > interested in your views if it is the correct direction.
> >
> Jeff, you are such a good coder, i think everything you start will be 
> such good as java-gtk.
> Good luck!
> 
> Mfg Linuxhippy
> 
> > -Jeff
> >
> 
> 
> 

RE: [Java-gnome-developer] Development Status

[Almotasim <alm...@no...>]

Tks for your answers.=20
I'm happy to read that there's a lot of synergy between Java-Gnome and
SWT as I was fearing that too many similar-but-not-really-compatible
projects were being developped.=20

I have several remarks and questions divided below in remarks regarding
strategy and remarks concering technical points.=20

1) Strategy=20

Is it so much useful to maintain Windows+Motif support ? Gnome on the
desktop is making huge progress, whereas Windows doesn't innovate much
and is therefore liable, in my opinion, to disappear in the mid-term (5
years?), because the system itself is conceptually too poor to compete
with the various OS that the open-source community + companies like IBM
or Sun have coded in the last 20 years.=20

2) Conception/technical points=20

>A higher-level object-oriented API is needed in order to make
>java-gnome really viable.=20
I think that's a very good idea to build a high-level OO GUI-API
gathering the best features of Swing, Gtk, Qt, MFC + more (I actually
thought at first it was already part of the Eclipse project). The key
point probably relies on the community such a project is able to gather;
I believe many engineering schools (such as http://www.emn.fr/ in
France, which works closely with OTI) would be interested in joining the
project both at a research level and at a coding effort level; hopefully
OTI team would also participate strongly, making the "high-level API"
more quickly available for commercial-apps use. I guess the industry
will need more and more advanced widgets, such as hyperbolic trees
(http://treebolic.sortilege.net), smart tables like those in Gnumeric,
advanced visualition tools etc., hence the availability of such an API
could help the industry working better.=20

Which language in the mid-term for OO programming: Java, Python, C++ ?
Is there any reason to keep using so many very close languages instead
of focusing on theorical problems related to OO programming?
(meta-objects protocols, automatic components assembling etc.). I'd be
happy to know what Ximian developpers think about the OO language
question, as they're making very good apps based on C/Gtk and Bonobo.
Java is a cool language but I'm wondering sometimes if these guys are
not going to produce a new LGPL Java-like language. I believe Java
should now be released in true open-source, so that designers and
developers from all companies could focus on a cooperative effort,
without developing so many language-gateways (of course diversity is
very important but here it looks like there is no real conceptual
difference between Java, C++, Python, etc., or is there?).=20

One last remark: Gnu/Linux is still missing the game in the games
software area; it's obvious that encouraging the development of games on
Linux could help creating collectively advanced high-level generic
OO-APIs for open-source graphical environnements ("intelligent" games as
far as possible of course).=20

Regards=20

Almo=20





Le lun 15/07/2002 =E0 16:54, Jeffrey Morgan a =E9crit :=20
> > Is there a possible synergy between Java/Gnome and IBM-SWT library
> > (eclipse.org)? What's Java-Gnome position (technically and
> > strategically) regarding IBM-SWT/JFace, which seems to run well on
> > Gnome2.0 ?=20
>=20
> There is a lot of synergy between these projects.  In fact, I am
> currently working on the SWT project at the same time as working
> on java-gnome.  There are a few problems with SWT that are being=20
> addressed.  They are:
>=20
> * SWT uses the GTK 1.x tree and list widgets (SWT team is working on this=
)
> * SWT uses the GTK 1.x text widget (I am working on this)
> * SWT/GTK does not have a consistent approach for NLS (SWT team is workin=
g
>   on this)
> * SWT relies on being able to utilize z-order.  GTK doesn't support z-ord=
er.
>   The fix that was put in place is probably contributing to poor
> performance.
>   (This is an issue that I intend to bring up at this week's GNOME Summit=
)
> * The SWT and GTK model for Composite/Child (SWT) and Container/Child (GT=
K)
>   are very different.  As a result, SWT/GTK was forced to introduce hacks
>   to handle widget sizing and positioning.  This is contributing to the p=
oor
>   performance.  (I also hope to bring this up at the GNOME Summit)
> * SWT doesn't have close to full coverage of the APIs that are provided b=
y
>   GTK.  SWT also doesn't provide any coverage for the GNOME APIs. (See my
>   proposed solution below)
>=20
> I intended to wait until my next release to put a proposal out to the
> community but since you have touch on this topic I think I will do it now=
.
> SWT will continue to mature at a rate that is much faster than java-gnome
> due to the fact that IBM/OTI has full-time resources working on it.
> Also, due to the fact that SWT runs natively on several platforms it will
> gather much greater industry support.  At a low level, the way SWT is
> accessing
> the native peers is superior to the approach taken by java-gnome.  It wou=
ld=20
> appear that SWT would be an ideal choice for somebody wanting to write a=20
> java application that will run on GTK.  You would also have the added
> ability=20
> to support Motif, Win32, OSX Carbon, and other platforms.
>=20
> The primary problem with SWT is that it is not currently intended to be
> a complete/robust GUI framework.  Not all widgets supported on the host
> operating systems are supported on SWT.  Also, although JFace does provid=
e
> some higher-level facilities it is primary focused on providing a framewo=
rk
> for the eclipse platform.  At the same time, java-gnome attempts to map
> directly to the underlying APIs provided by GTK and GNOME.  This makes
> the java-gnome class library huge and very complex to use. A higher-level=
=20
> object-oriented API is needed in order to make java-gnome really viable.
>=20
> My proposal is for a new project (or a significant morph of java-gnome).
> This new project would use SWT as it's foundation and would address the=20
> above mentioned issues.  This new project would not only focus on GTK. =20
> It would also provide support for Motif and Win32 (possibly others). =20
> Perhaps over time some of the code produced by this new project could=20
> be incorporated into SWT and some of it would stay independent of SWT. =20
>=20
> A proposed task list to start the project follows:
>=20
> 1) Identify lead developer for each of the platforms:
>    GTK - Jeff Morgan
>    Motif - ??
>    Win32 - ??
>=20
> 2) Define the new API and create an object model to be presented to the
>    community:
>    -I have spent a lot of time this year studying various GUI frameworks
> (QT,=20
>     GTK, Motif, MFC).  I would like to begin a discussion with the
> developers=20
>     on this new project to decide what functions should be included in th=
is
>     new GUI framework.  Perhaps it would be a combination of the best
> features=20
>     of several of the mentioned frameworks.  The result of this discussio=
n=20
>     would be an object model and a plan for development.  These artifacts
>     would then be presented to the community at large for comments and=20
>     suggestions.
> 3) Once the design and plan are finalized create begin the effort.
>=20
> > Do you know what Sun strategy is regarding Java integration into Gnome
> > (Solaris will use Gnome as Desktop Environnement, but then which
> > language will Sun recommend to build GUIs - as far as Swing=20
> > is obviously
> > not fast enough to build advanced smooth GUIs ?
>=20
> Sun would have to answer this question.  At one time there was
> much discussion about providing GTK peers for AWT.  I don't know
> where this discussion went.
>=20
>=20
> I would be very interested in hearing from the users of java-gnome
> about the proposal put forth above.  Although it is a significant
> departure from the current direction of this project I would be
> interested in your views if it is the correct direction.
>=20
> -Jeff

RE: [Java-gnome-developer] Development Status

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

> Is there a possible synergy between Java/Gnome and IBM-SWT library
> (eclipse.org)? What's Java-Gnome position (technically and
> strategically) regarding IBM-SWT/JFace, which seems to run well on
> Gnome2.0 ? 

There is a lot of synergy between these projects.  In fact, I am
currently working on the SWT project at the same time as working
on java-gnome.  There are a few problems with SWT that are being 
addressed.  They are:

* SWT uses the GTK 1.x tree and list widgets (SWT team is working on this)
* SWT uses the GTK 1.x text widget (I am working on this)
* SWT/GTK does not have a consistent approach for NLS (SWT team is working
  on this)
* SWT relies on being able to utilize z-order.  GTK doesn't support z-order.
  The fix that was put in place is probably contributing to poor
performance.
  (This is an issue that I intend to bring up at this week's GNOME Summit)
* The SWT and GTK model for Composite/Child (SWT) and Container/Child (GTK)
  are very different.  As a result, SWT/GTK was forced to introduce hacks
  to handle widget sizing and positioning.  This is contributing to the poor
  performance.  (I also hope to bring this up at the GNOME Summit)
* SWT doesn't have close to full coverage of the APIs that are provided by
  GTK.  SWT also doesn't provide any coverage for the GNOME APIs. (See my
  proposed solution below)

I intended to wait until my next release to put a proposal out to the
community but since you have touch on this topic I think I will do it now.
SWT will continue to mature at a rate that is much faster than java-gnome
due to the fact that IBM/OTI has full-time resources working on it.
Also, due to the fact that SWT runs natively on several platforms it will
gather much greater industry support.  At a low level, the way SWT is
accessing
the native peers is superior to the approach taken by java-gnome.  It would 
appear that SWT would be an ideal choice for somebody wanting to write a 
java application that will run on GTK.  You would also have the added
ability 
to support Motif, Win32, OSX Carbon, and other platforms.

The primary problem with SWT is that it is not currently intended to be
a complete/robust GUI framework.  Not all widgets supported on the host
operating systems are supported on SWT.  Also, although JFace does provide
some higher-level facilities it is primary focused on providing a framework
for the eclipse platform.  At the same time, java-gnome attempts to map
directly to the underlying APIs provided by GTK and GNOME.  This makes
the java-gnome class library huge and very complex to use. A higher-level 
object-oriented API is needed in order to make java-gnome really viable.

My proposal is for a new project (or a significant morph of java-gnome).
This new project would use SWT as it's foundation and would address the 
above mentioned issues.  This new project would not only focus on GTK.  
It would also provide support for Motif and Win32 (possibly others).  
Perhaps over time some of the code produced by this new project could 
be incorporated into SWT and some of it would stay independent of SWT.  

A proposed task list to start the project follows:

1) Identify lead developer for each of the platforms:
   GTK - Jeff Morgan
   Motif - ??
   Win32 - ??

2) Define the new API and create an object model to be presented to the
   community:
   -I have spent a lot of time this year studying various GUI frameworks
(QT, 
    GTK, Motif, MFC).  I would like to begin a discussion with the
developers 
    on this new project to decide what functions should be included in this
    new GUI framework.  Perhaps it would be a combination of the best
features 
    of several of the mentioned frameworks.  The result of this discussion 
    would be an object model and a plan for development.  These artifacts
    would then be presented to the community at large for comments and 
    suggestions.
3) Once the design and plan are finalized create begin the effort.

> Do you know what Sun strategy is regarding Java integration into Gnome
> (Solaris will use Gnome as Desktop Environnement, but then which
> language will Sun recommend to build GUIs - as far as Swing 
> is obviously
> not fast enough to build advanced smooth GUIs ?

Sun would have to answer this question.  At one time there was
much discussion about providing GTK peers for AWT.  I don't know
where this discussion went.


I would be very interested in hearing from the users of java-gnome
about the proposal put forth above.  Although it is a significant
departure from the current direction of this project I would be
interested in your views if it is the correct direction.

-Jeff

RE: [Java-gnome-developer] Development Status

[Almotasim <alm...@no...>]

Is there a possible synergy between Java/Gnome and IBM-SWT library
(eclipse.org)? What's Java-Gnome position (technically and
strategically) regarding IBM-SWT/JFace, which seems to run well on
Gnome2.0 ?=20

Do you know what Sun strategy is regarding Java integration into Gnome
(Solaris will use Gnome as Desktop Environnement, but then which
language will Sun recommend to build GUIs - as far as Swing is obviously
not fast enough to build advanced smooth GUIs ?

Regards,

Almo



Le lun 15/07/2002 =E0 14:25, Jeffrey Morgan a =E9crit :
>=20
> > hi,=20
> >   I was just wondering about the current development status of
> > Java-Gnome - how many people are working on it at the moment,=20
> > are there
> > any areas which particularly need help, etc.
>=20
> I am the only one working on the bindings.  I could definitely
> use help on several areas of the project.
>=20
> >=20
> > From my dabbling with with code from CVS, most of the Gtk2 stuff seems
> > done, apart from the documentation. If this is simply a case of adding
> > things like (comment (GtkWidget is the base class of all widgets.)) to
> > the defs files; and the comments mostly being copied from Gtk
> > documentation; then I would like to volounteer to help.
>=20
> There are two areas that still need work on the bindings
> themselves.  They are the GtkTreeView/Model related classes
> and the new Gtk Stock objects.  I am currently working on
> the tree/model classes.  Also, as you have stated, the def
> files should be updated with useful comments, documentation
> needs to be updated and the examples also need updating.  I
> would welcome any help you might be able to provide.
>=20
> -Jeff

RE: [Java-gnome-developer] Development Status

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

> hi, 
>   I was just wondering about the current development status of
> Java-Gnome - how many people are working on it at the moment, 
> are there
> any areas which particularly need help, etc.

I am the only one working on the bindings.  I could definitely
use help on several areas of the project.

> 
> From my dabbling with with code from CVS, most of the Gtk2 stuff seems
> done, apart from the documentation. If this is simply a case of adding
> things like (comment (GtkWidget is the base class of all widgets.)) to
> the defs files; and the comments mostly being copied from Gtk
> documentation; then I would like to volounteer to help.

There are two areas that still need work on the bindings
themselves.  They are the GtkTreeView/Model related classes
and the new Gtk Stock objects.  I am currently working on
the tree/model classes.  Also, as you have stated, the def
files should be updated with useful comments, documentation
needs to be updated and the examples also need updating.  I
would welcome any help you might be able to provide.

-Jeff

Re: [Java-gnome-developer] Using the Parser for other libraries

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

On Sun, 2002-07-14 at 00:55, ian Holsman wrote:
> Hi.
> I'm interested in using the parser generator to generate java JNI 
> classes for another library
> (apr http://apr.apache.org). I'd be interested in knowing what would be 
> involved to get this going?

There are essentially three inputs into the code generation process.
The first is the defs files.  These files define what is to be
generated.  The second input is JNIProps.txt file.  This file describes
how to handle/convert the data that is passed from one layer to another.
This file is located in the src/tools directory.  The final input is
the source files located in the src/code/jni directory.  These files
are appended to the end of generated files by the process.  Their
purpose is to handle the situations that cannot be properly handled
by the code generator.

I would be able to offer assistance as you get started.

> 
> are these def files manually generated or do you the parser generate 
> this as well?

The def files were part of the gtk project.  They did not completely
suite our needs so I made changes to them over time.  They are now
manually maintained.


-Jeff

[Java-gnome-developer] Using the Parser for other libraries

[ian H. <li...@ho...>]

Hi.
I'm interested in using the parser generator to generate java JNI 
classes for another library
(apr http://apr.apache.org). I'd be interested in knowing what would be 
involved to get this going?

are these def files manually generated or do you the parser generate 
this as well?

Thanks
Ian Holsman

[Java-gnome-developer] Development Status

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

hi,=20
  I was just wondering about the current development status of
Java-Gnome - how many people are working on it at the moment, are there
any areas which particularly need help, etc.

From my dabbling with with code from CVS, most of the Gtk2 stuff seems
done, apart from the documentation. If this is simply a case of adding
things like (comment (GtkWidget is the base class of all widgets.)) to
the defs files; and the comments mostly being copied from Gtk
documentation; then I would like to volounteer to help.
--=20

+----------------------------------------------+
| Mark Howard               cam.ac.uk   mh344@ |
| http://www.tildemh.com    tildemh.com    mh@ |
+----------------------------------------------+

[Java-gnome-developer] RPM-Packages

[Clemens E. <Lin...@we...>]

Hi again!

>
> > Hi!
> >
> > Wow, that are really very good values! - Only the libGTKJar.so is a
> > little "heavyweight" , but all other files are so small that
> > this should
> > be no problem...
> >
> > Is it welcome that I want to create .rpms and .debs?
>
> It would be very welcome.
>
Fine, but that can take over a month because I first want to develop my 
java-gtk-app ;-)
I hope thats not too long for you..

> >
> > Only one last question: I still develop my apps with 0.7.1 - How
> > complete is the gtk2-port 0.8? Has it already reached an
> > useable status
> > or is it still quiet incoplete?
>
> All of the GTK 1.x widgets are reaching stability.  The new
> widgets are still a work-in-progress.  If you want to dabble
> please feel free to give it a try and let me know your results.
> If you are not quite that adventurous then I would recommending
> giving the 0.8 version a few more weeks.
>
Fine!
Hmm, I think I'll develop my app first under 0.7.1 and if all works 
fine(this means my app) I'll have a look to 0.8.
However, thanks for your response!

Regards Clemens

RE: [Java-gnome-developer] How to make Java-Gnome popular...

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

> Hi!
> 
> Wow, that are really very good values! - Only the libGTKJar.so is a 
> little "heavyweight" , but all other files are so small that 
> this should 
> be no problem...
> 
> Is it welcome that I want to create .rpms and .debs?

It would be very welcome.

> 
> Only one last question: I still develop my apps with 0.7.1 - How 
> complete is the gtk2-port 0.8? Has it already reached an 
> useable status 
> or is it still quiet incoplete?

All of the GTK 1.x widgets are reaching stability.  The new
widgets are still a work-in-progress.  If you want to dabble
please feel free to give it a try and let me know your results.
If you are not quite that adventurous then I would recommending
giving the 0.8 version a few more weeks.


-Jeff

Re: [Java-gnome-developer] How to make Java-Gnome popular...

[Clemens E. <Lin...@we...>]

Hi!

> I would recommend stripping the shared objects.  This will
> reduce the size by a significant amount.  On my system you
> this reduces them to a very acceptable size.  The following
> lines are the output from the size command on my system
> without any modifications to the build after stripping the
> shared objects:
>
>    text    data     bss     dec     hex filename
>  402270  195912    3044  601226   92c8a libGNOMEJar.so
>  178073    2912      28  181013   2c315 libGNOMEJava.so
> 1607282  809348   14132 2430762  25172a libGTKJar.so
>  574135    8960      52  583147   8e5eb libGTKJava.so
>
> The physical size of the shared objects are:
>
>  601020  - libGNOMEJar.so
>  183800  - libGNOMEJava.so
> 2424700  - libGTKJar.so
>  591056  - libGTKJava.so
>
Wow, that are really very good values! - Only the libGTKJar.so is a 
little "heavyweight" , but all other files are so small that this should 
be no problem...

Is it welcome that I want to create .rpms and .debs?

Only one last question: I still develop my apps with 0.7.1 - How 
complete is the gtk2-port 0.8? Has it already reached an useable status 
or is it still quiet incoplete?

Thx for answering my stupid questions ;-) and for developing such great 
software!

Clemens

> After recompiling with the -O3 options I yield the following
> results:
>
>    text    data     bss     dec     hex filename
>  402312  190292    3044  595648   916c0 libGNOMEJar.so
>  180801    2908      28  183737   2cdb9 libGNOMEJava.so
> 1612971  805828   14132 2432931  251fa3 libGTKJar.so
>  584479    8956      52  593487   90e4f libGTKJava.so
>
>  595432  - libGNOMEJar.so
>  186516  - libGNOMEJava.so
> 2426876  - libGTKJar.so
>  601420  - libGTKJava.so
>
> As you can see, the -O3 options actually increases the size
> of a few of the files.  This is due to the fact that O3 is
> optimizing for speed and not size.
>
> -Jeff
>
> > Hi everybody!
> >
> > I've now written a very first Version of my
> > wine-configurationprogramm
> > using gcj and java-gnome.
> > There are two problems contributing my app:
> >
> > 1. Java-GTK is very big!(~5megs (the java-jar, the gcj-so and
> > the c-part
> > of the bindings)
> > I think this problem isnt so easy to solve. But ist a little
> > problematic
> > that the java-bindings are much bigger than the library for which the
> > bindings were written, maybe we can optimeze the code a
> > little bit, so
> > that we can use the -O3 flag for the C-part. -O2 should work
> > everywhere
> > and the  size of libjavagtk.so should decrease 30-50%. Are there any
> > optimisations used for now? I thin only the C-part is the
> > problem, the
> > jar-archive already very small. The second problem is the
> > compiled part
> > for the gcj, which is about ~3.2 megs big. maybe with some
> > playarounds
> > it can be done with 2.5megs but not less ;-(
> >
> > 2. There are no user-ready packages avaible. (.deb, .rpm, .tar.gz)
> > Althougt this is a big problem it  should be very easy to solve. Were
> > included in no distribution, and users cat even download any
> > binary-packages.
> > I'll build some packages using esp in the next month - maybe we'll be
> > included  in UnitedLinux ;-)
>

RE: [Java-gnome-developer] How to make Java-Gnome popular...

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

I would recommend stripping the shared objects.  This will
reduce the size by a significant amount.  On my system you
this reduces them to a very acceptable size.  The following
lines are the output from the size command on my system
without any modifications to the build after stripping the 
shared objects:

   text    data     bss     dec     hex filename
 402270  195912    3044  601226   92c8a libGNOMEJar.so
 178073    2912      28  181013   2c315 libGNOMEJava.so
1607282  809348   14132 2430762  25172a libGTKJar.so
 574135    8960      52  583147   8e5eb libGTKJava.so

The physical size of the shared objects are:

 601020  - libGNOMEJar.so
 183800  - libGNOMEJava.so
2424700  - libGTKJar.so
 591056  - libGTKJava.so

After recompiling with the -O3 options I yield the following
results:

   text    data     bss     dec     hex filename
 402312  190292    3044  595648   916c0 libGNOMEJar.so
 180801    2908      28  183737   2cdb9 libGNOMEJava.so
1612971  805828   14132 2432931  251fa3 libGTKJar.so
 584479    8956      52  593487   90e4f libGTKJava.so

 595432  - libGNOMEJar.so
 186516  - libGNOMEJava.so
2426876  - libGTKJar.so
 601420  - libGTKJava.so

As you can see, the -O3 options actually increases the size
of a few of the files.  This is due to the fact that O3 is
optimizing for speed and not size.

-Jeff

> Hi everybody!
> 
> I've now written a very first Version of my 
> wine-configurationprogramm 
> using gcj and java-gnome.
> There are two problems contributing my app:
> 
> 1. Java-GTK is very big!(~5megs (the java-jar, the gcj-so and 
> the c-part 
> of the bindings)
> I think this problem isnt so easy to solve. But ist a little 
> problematic 
> that the java-bindings are much bigger than the library for which the 
> bindings were written, maybe we can optimeze the code a 
> little bit, so 
> that we can use the -O3 flag for the C-part. -O2 should work 
> everywhere 
> and the  size of libjavagtk.so should decrease 30-50%. Are there any 
> optimisations used for now? I thin only the C-part is the 
> problem, the 
> jar-archive already very small. The second problem is the 
> compiled part 
> for the gcj, which is about ~3.2 megs big. maybe with some 
> playarounds 
> it can be done with 2.5megs but not less ;-(
> 
> 2. There are no user-ready packages avaible. (.deb, .rpm, .tar.gz)
> Althougt this is a big problem it  should be very easy to solve. Were 
> included in no distribution, and users cat even download any 
> binary-packages.
> I'll build some packages using esp in the next month - maybe we'll be 
> included  in UnitedLinux ;-)

[Java-gnome-developer] How to make Java-Gnome popular...

[Clemens E. <Lin...@we...>]

Hi everybody!

I've now written a very first Version of my wine-configurationprogramm 
using gcj and java-gnome.
There are two problems contributing my app:

1. Java-GTK is very big!(~5megs (the java-jar, the gcj-so and the c-part 
of the bindings)
I think this problem isnt so easy to solve. But ist a little problematic 
that the java-bindings are much bigger than the library for which the 
bindings were written, maybe we can optimeze the code a little bit, so 
that we can use the -O3 flag for the C-part. -O2 should work everywhere 
and the  size of libjavagtk.so should decrease 30-50%. Are there any 
optimisations used for now? I thin only the C-part is the problem, the 
jar-archive already very small. The second problem is the compiled part 
for the gcj, which is about ~3.2 megs big. maybe with some playarounds 
it can be done with 2.5megs but not less ;-(

2. There are no user-ready packages avaible. (.deb, .rpm, .tar.gz)
Althougt this is a big problem it  should be very easy to solve. Were 
included in no distribution, and users cat even download any 
binary-packages.
I'll build some packages using esp in the next month - maybe we'll be 
included  in UnitedLinux ;-)

[Java-gnome-developer] table remove problems

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

hi,

I'm using java-gnome code from CVS.

  I've been having problems trying to reattach widgets to tables after
removing them with the remove method of the GtkContainer (GtkTable). The
widget seems to be nullified when it is removed, even though there is
clearly a reference directly to it in the program. When trying to
reattach, I get the following error:

(java-gnome:15594): Gtk-CRITICAL **: file gtktable.c: line 578
(gtk_table_attach): assertion `GTK_IS_WIDGET (child)' failed

Am I doing the wrong thing when trying to remove the widget? or is it a
bug in the bindings?

I have attached a simple example which demonstrates this behaviour,
using a button as the widget to remove attach (although it does the same
thing with any type - I was originally using GtkFrames)
-- 

+----------------------------------------------+
| Mark Howard               cam.ac.uk   mh344@ |
| http://www.tildemh.com    tildemh.com    mh@ |
+----------------------------------------------+

RE: [Java-gnome-developer] gtk bindings

[Christian F. K. S. <Ur...@li...>]

Not sure where we store the GTK+ homepages, but I will find out and
update the page.

Christian

On Fri, 2002-06-28 at 21:57, Jeffrey Morgan wrote:
> On at least two occasions I have notified the
> list of the java bindings.  We were not added
> to the list as you have stated.  
> 
> -Jeff
> 
> 
> 
> > hi,
> >   gtk.org has a page [1] listing gtk bindings for various programming 
> > languages (only four of which are marked as status Complete, 
> > and then only 
> > for gtk 1.2). It'd probably be a good idea for someone to 
> > email the gtk.org 
> > webmasters with details of java-gnome, so maybe more people would get 
> > interested in j-g and so produce more bug reports, patches and 
> > improvements.
> > 
> > [1] http://gtk.org/bindings.html
> > 
> > 
> > 
> > Mark Howard
> > 
> > 
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Caffeinated soap. No kidding.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > java-gnome-developer mailing list
> > jav...@li...
> > https://lists.sourceforge.net/lists/listinfo/java-gnome-developer
> > 

RE: [Java-gnome-developer] gtk bindings

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

On at least two occasions I have notified the
list of the java bindings.  We were not added
to the list as you have stated.  

-Jeff



> hi,
>   gtk.org has a page [1] listing gtk bindings for various programming 
> languages (only four of which are marked as status Complete, 
> and then only 
> for gtk 1.2). It'd probably be a good idea for someone to 
> email the gtk.org 
> webmasters with details of java-gnome, so maybe more people would get 
> interested in j-g and so produce more bug reports, patches and 
> improvements.
> 
> [1] http://gtk.org/bindings.html
> 
> 
> 
> Mark Howard
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Caffeinated soap. No kidding.
> http://thinkgeek.com/sf
> _______________________________________________
> java-gnome-developer mailing list
> jav...@li...
> https://lists.sourceforge.net/lists/listinfo/java-gnome-developer
> 

[Java-gnome-developer] gtk bindings

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

hi,
  gtk.org has a page [1] listing gtk bindings for various programming 
languages (only four of which are marked as status Complete, and then only 
for gtk 1.2). It'd probably be a good idea for someone to email the gtk.org 
webmasters with details of java-gnome, so maybe more people would get 
interested in j-g and so produce more bug reports, patches and 
improvements.

[1] http://gtk.org/bindings.html



Mark Howard

Re: [Java-gnome-developer] Java-GTK crashed...

[Clemens E. <cei...@ut...>]

Hi!

Thx for your answer!

> The code looks right to me, but I had some problems with class files
> built using jdk1.4 when running under a 1.3 jre.
Originally I built the .class-files with the jdk-1.3.1 that comes with
JBuilder6 and I also used it with that jdk. The same problem happens
with jdk-1.4. Seems to be a bug in the c-code...

>Try to compile
> java-gtk using the same jdk you are using for compiling and running
> your application and see if this worls.
Yeah, i did this...





 
> >When I tried to run the following code, java-gtk crashed. I think 
> its my 
> >fault, but wahts wrong:
> >
> >GListString gls = new GListSting();
> >GtkList gtklist = new GtkList();
> >
> >gtklist = (GtkList) glade.getWidget("list2");
> >
> >gls.append("Hello");
> >gtklist.appendItem(gls);
> >
> >
> >
> >I'm using Jdk1.3.1(Sun) which is shipped with JBuilder on an 
> >Mandrake-linux8.2.
> >My .jar file was originally compiled with Sun-Jdk-1.4.0
> >This fault happend with Java-gtk-0.7.1.
> >
> >I hope I could help!(Or you could help me ;-) )
> >
> >
> >
> >AL **: file gtkwidget.c: line 3356 (gtk_widget_set_parent): 
> assertion 
> >`GTK_IS_WIDGET (widget)' failed.
> >
> >Gtk-WARNING **: invalid cast from `(unknown)' to `GtkObject'
> >
> >Gtk-CRITICAL **: file gtksignal.c: line 725 (gtk_signal_connect): 
> >assertion `GTK_IS_OBJECT (object)' failed.
> >
> >Gtk-WARNING **: invalid cast from `(unknown)' to `GtkObject'
> >
> >Gtk-CRITICAL **: file gtksignal.c: line 725 (gtk_signal_connect): 
> >assertion `GTK_IS_OBJECT (object)' failed.
> >
> >Gtk-WARNING **: invalid cast from `(unknown)' to `GtkObject'
> >
> >Gtk-CRITICAL **: file gtksignal.c: line 725 (gtk_signal_connect): 
> >assertion `GTK_IS_OBJECT (object)' failed.
> >
> >Gtk-WARNING **: invalid cast from `(unknown)' to `GtkObject'
> >
> >Gtk-CRITICAL **: file gtksignal.c: line 725 (gtk_signal_connect): 
> >assertion `GTK_IS_OBJECT (object)' failed.
> >
> >Gtk-WARNING **: invalid cast from `(unknown)' to `GtkObject'
> >
> >Gtk-CRITICAL **: file gtksignal.c: line 725 (gtk_signal_connect): 
> >assertion `GTK_IS_OBJECT (object)' failed.
> >
> >Gtk-WARNING **: invalid cast from `(unknown)' to `GtkObject'
> >
> >Gtk-CRITICAL **: file gtksignal.c: line 725 (gtk_signal_connect): 
> >assertion `GTK_IS_OBJECT (object)' failed.
> >
> >Gtk-WARNING **: invalid cast from `(unknown)' to `GtkObject'
> >
> >Gtk-CRITICAL **: file gtksignal.c: line 725 (gtk_signal_connect): 
> >assertion `GTK_IS_OBJECT (object)' failed.
> >
> >Gtk-WARNING **: invalid cast from `(unknown)' to `GtkObject'
> >
> >Gtk-CRITICAL **: file gtksignal.c: line 725 (gtk_signal_connect): 
> >assertion `GTK_IS_OBJECT (object)' failed.
> >
> >Gtk-WARNING **: invalid cast from `(unknown)' to `GtkObject'
> >
> >Gtk-CRITICAL **: file gtksignal.c: line 725 (gtk_signal_connect): 
> >assertion `GTK_IS_OBJECT (object)' failed.
> >
> >Gtk-WARNING **: invalid cast from `(unknown)' to `GtkObject'
> >
> >Gtk-CRITICAL **: file gtksignal.c: line 725 (gtk_signal_connect): 
> >assertion `GTK_IS_OBJECT (object)' failed.
> >
> >Gtk-WARNING **: invalid cast from `(unknown)' to `GtkObject'
> >
> >Gtk-CRITICAL **: file gtksignal.c: line 725 (gtk_signal_connect): 
> >assertion `GTK_IS_OBJECT (object)' failed.
> >
> >Gtk-WARNING **: invalid cast from `(unknown)' to `GtkObject'
> >
> >Gtk-CRITICAL **: file gtksignal.c: line 725 (gtk_signal_connect): 
> >assertion `GTK_IS_OBJECT (object)' failed.
> >
> >Gtk-WARNING **: invalid cast from `(unknown)' to `GtkObject'
> >
> >Gtk-CRITICAL **: file gtksignal.c: line 725 (gtk_signal_connect): 
> >assertion `GTK_IS_OBJECT (object)' failed.
> >
> >Gtk-WARNING **: invalid cast from `(unknown)' to `GtkObject'
> >
> >Gtk-CRITICAL **: file gtksignal.c: line 725 (gtk_signal_connect): 
> >assertion `GTK_IS_OBJECT (object)' failed.
> >
> >An unexpected exception has been detected in native code outside 
> the VM.
> >Unexpected Signal : 11 occurred at PC=0x49924c49
> >Function name=gtk_list_insert_items
> >Library=/usr/lib/libgtk-1.2.so.0
> >
> >Current Java thread:
> >    at gnu.gtk.GtkList.appendItems(Native Method)
> >    at getwidgets.<init>(getwidgets.java:149)
> >    at gui.<init>(gui.java:15)
> >    at maingui.main(maingui.java:14)
> >
> >Dynamic libraries:
> >08048000-0804c000 r-xp 00000000 03:04 58825300   
> >/opt/JBuilder6/jdk1.3.1/bin/i386/native_threads/java
> >0804c000-0804d000 rw-p 00003000 03:04 58825300   
> >/opt/JBuilder6/jdk1.3.1/bin/i386/native_threads/java
> >40000000-40014000 r-xp 00000000 03:04 71303310   /lib/ld-2.2.4.so
> >40014000-40015000 rw-p 00013000 03:04 71303310   /lib/ld-2.2.4.so
> >40016000-40017000 r--p 00000000 03:04 159383804  
> >/usr/share/locale/de_AT/LC_IDENTIFICATION
> >40017000-40018000 r--p 00000000 03:04 88080532   
> >/usr/share/locale/de_AT/LC_MEASUREMENT
> >40018000-40019000 r--p 00000000 03:04 159383801  
> >/usr/share/locale/de_AT/LC_TELEPHONE
> >40019000-4001a000 r--p 00000000 03:04 88080529   
> >/usr/share/locale/de_AT/LC_ADDRESS
> >4001a000-4001b000 r--p 00000000 03:04 88080528   
> >/usr/share/locale/de_AT/LC_NAME
> >4001b000-4001c000 r--p 00000000 03:04 88080530   
> >/usr/share/locale/de_AT/LC_PAPER
> >4001c000-4001d000 r--p 00000000 03:04 117440660  
> >/usr/share/locale/de_AT/LC_MESSAGES/SYS_LC_MESSAGES
> >4001d000-4001e000 r--p 00000000 03:04 159383803  
> >/usr/share/locale/de_AT/LC_MONETARY
> >4001e000-40024000 r--p 00000000 03:04 41943176   
> >/usr/share/locale/ISO-8859-15/LC_COLLATE
> >40024000-40025000 r--p 00000000 03:04 159383800  
> >/usr/share/locale/de_AT/LC_TIME
> >40025000-40033000 r-xp 00000000 03:04 71303355   /lib/libpthread-
> 0.9.so>40033000-4003b000 rw-p 0000d000 03:04 71303355   
> /lib/libpthread-0.9.so
> >4003b000-40044000 r-xp 00000000 03:04 54594314   
> >/opt/JBuilder6/jdk1.3.1/jre/lib/i386/native_threads/libhpi.so
> >40044000-40045000 rw-p 00008000 03:04 54594314   
> >/opt/JBuilder6/jdk1.3.1/jre/lib/i386/native_threads/libhpi.so
> >40046000-402ad000 r-xp 00000000 03:04 58825296   
> >/opt/JBuilder6/jdk1.3.1/jre/lib/i386/client/libjvm.so
> >402ad000-40413000 rw-p 00266000 03:04 58825296   
> >/opt/JBuilder6/jdk1.3.1/jre/lib/i386/client/libjvm.so
> >4042a000-4042c000 r-xp 00000000 03:04 71303323   /lib/libdl-2.2.4.so
> >4042c000-4042d000 rw-p 00001000 03:04 71303323   /lib/libdl-2.2.4.so
> >4042d000-4055f000 r-xp 00000000 03:04 71303319   /lib/libc-2.2.4.so
> >4055f000-40565000 rw-p 00131000 03:04 71303319   /lib/libc-2.2.4.so
> >40569000-4057b000 r-xp 00000000 03:04 71303328   /lib/libnsl-2.2.4.so
> >4057b000-4057d000 rw-p 00011000 03:04 71303328   /lib/libnsl-2.2.4.so
> >4057f000-405a0000 r-xp 00000000 03:04 71303325   /lib/libm-2.2.4.so
> >405a0000-405a1000 rw-p 00020000 03:04 71303325   /lib/libm-2.2.4.so
> >405a1000-405da000 r-xp 00000000 03:04 109052195  
> >/usr/lib/libstdc++-3-libc6.2-2-2.10.0.so
> >405da000-405eb000 rw-p 00038000 03:04 109052195  
> >/usr/lib/libstdc++-3-libc6.2-2-2.10.0.so
> >405ef000-40600000 r-xp 00000000 03:04 50383490   
> >/opt/JBuilder6/jdk1.3.1/jre/lib/i386/libverify.so
> >40600000-40602000 rw-p 00010000 03:04 50383490   
> >/opt/JBuilder6/jdk1.3.1/jre/lib/i386/libverify.so
> >40602000-40623000 r-xp 00000000 03:04 50382204   
> >/opt/JBuilder6/jdk1.3.1/jre/lib/i386/libjava.so
> >40623000-40625000 rw-p 00020000 03:04 50382204   
> >/opt/JBuilder6/jdk1.3.1/jre/lib/i386/libjava.so
> >40626000-4063a000 r-xp 00000000 03:04 50383489   
> >/opt/JBuilder6/jdk1.3.1/jre/lib/i386/libzip.so
> >4063a000-4063d000 rw-p 00013000 03:04 50383489   
> >/opt/JBuilder6/jdk1.3.1/jre/lib/i386/libzip.so
> >4063d000-41356000 r--s 00000000 03:04 46140304   
> >/opt/JBuilder6/jdk1.3.1/jre/lib/rt.jar
> >41383000-41628000 r--s 00000000 03:04 46140306   
> >/opt/JBuilder6/jdk1.3.1/jre/lib/i18n.jar
> >41628000-4163e000 r--s 00000000 03:04 46140307   
> >/opt/JBuilder6/jdk1.3.1/jre/lib/sunrsasign.jar
> >436e6000-436e7000 r--p 00000000 03:04 159383802  
> >/usr/share/locale/de_AT/LC_NUMERIC
> >436e7000-436e9000 r-xp 00000000 03:04 109052070  
> >/usr/lib/libgmodule-1.2.so.0.0.10
> >436e9000-436ea000 rw-p 00001000 03:04 109052070  
> >/usr/lib/libgmodule-1.2.so.0.0.10
> >436ea000-436ec000 r-xp 00000000 03:04 121637322  
> >/usr/X11R6/lib/X11/locale/common/xlcDef.so.2
> >436ec000-436ed000 rw-p 00001000 03:04 121637322  
> >/usr/X11R6/lib/X11/locale/common/xlcDef.so.2
> >436ed000-436ef000 r-xp 00000000 03:04 134218021  
> >/usr/lib/gconv/ISO8859-15.so
> >436ef000-436f0000 rw-p 00001000 03:04 134218021  
> >/usr/lib/gconv/ISO8859-15.so
> >4974f000-49781000 r--p 00000000 03:04 125829264  
> >/usr/share/locale/de/LC_CTYPE
> >49781000-4978a000 r-xp 00000000 03:04 163680817  
> >/usr/lib/gtk/themes/engines/libpixmap.so
> >4978a000-4978c000 rw-p 00008000 03:04 163680817  
> >/usr/lib/gtk/themes/engines/libpixmap.so
> >4978c000-4978e000 r-xp 00000000 03:04 134218016 
> /usr/lib/gconv/ISO8859-1.so
> >4978e000-4978f000 rw-p 00001000 03:04 134218016 
> /usr/lib/gconv/ISO8859-1.so
> >49790000-49799000 r-xp 00000000 03:04 71303344  
> /lib/libnss_files-2.2.4.so
> >49799000-4979a000 rw-p 00008000 03:04 71303344  
> /lib/libnss_files-2.2.4.so
> >49806000-49838000 r--s 00000000 03:04 180474904  
> >/usr/local/share/java-gtk/gtk-0.7.1.jar
> >49838000-4988a000 r-xp 00000000 03:04 109225880  
> >/usr/local/lib/libGTKJava.so
> >4988a000-4988d000 rw-p 00051000 03:04 109225880  
> >/usr/local/lib/libGTKJava.so
> >4988d000-499c8000 r-xp 00000000 03:04 109052207  
> >/usr/lib/libgtk-1.2.so.0.9.1
> >499c8000-499cf000 rw-p 0013a000 03:04 109052207  
> >/usr/lib/libgtk-1.2.so.0.9.1
> >499d0000-49a07000 r-xp 00000000 03:04 109052205  
> >/usr/lib/libgdk-1.2.so.0.9.1
> >49a07000-49a09000 rw-p 00036000 03:04 109052205  
> >/usr/lib/libgdk-1.2.so.0.9.1
> >49a09000-49a2d000 r-xp 00000000 03:04 109052068  
> >/usr/lib/libglib-1.2.so.0.0.10
> >49a2d000-49a2f000 rw-p 00023000 03:04 109052068  
> >/usr/lib/libglib-1.2.so.0.0.10
> >49a2f000-49a36000 r-xp 00000000 03:04 117444173 
> /usr/X11R6/lib/libXi.so.6.0
> >49a36000-49a37000 rw-p 00006000 03:04 117444173 
> /usr/X11R6/lib/libXi.so.6.0
> >49a37000-49a45000 r-xp 00000000 03:04 117444167  
> >/usr/X11R6/lib/libXext.so.6.4
> >49a45000-49a46000 rw-p 0000d000 03:04 117444167  
> >/usr/X11R6/lib/libXext.so.6.4
> >49a46000-49b0a000 r-xp 00000000 03:04 117444159  
> >/usr/X11R6/lib/libX11.so.6.2
> >49b0a000-49b0d000 rw-p 000c3000 03:04 117444159  
> >/usr/X11R6/lib/libX11.so.6.2
> >49b0d000-49b24000 r-xp 00000000 03:04 109080847 
> /usr/lib/libglade.so.0.4.2
> >49b24000-49b26000 rw-p 00016000 03:04 109080847 
> /usr/lib/libglade.so.0.4.2
> >49b26000-49bad000 r-xp 00000000 03:04 109065742 
> /usr/lib/libxml.so.1.8.17
> >49bad000-49bb0000 rw-p 00086000 03:04 109065742 
> /usr/lib/libxml.so.1.8.17
> >49bb0000-49bbd000 r-xp 00000000 03:04 71367163   /lib/libz.so.1.1.3
> >49bbd000-49bbf000 rw-p 0000c000 03:04 71367163   /lib/libz.so.1.1.3
> >49bbf000-49bc5000 r-xp 00000000 03:04 71409070   /lib/libgcc_s-
> 3.0.4.so.1>49bc5000-49bc8000 rw-p 00005000 03:04 71409070   
> /lib/libgcc_s-3.0.4.so.1
> >49bc8000-49be2000 r-xp 00000000 03:04 121637321  
> >/usr/X11R6/lib/X11/locale/common/ximcp.so.2
> >49be2000-49be5000 rw-p 00019000 03:04 121637321  
> >/usr/X11R6/lib/X11/locale/common/ximcp.so.2
> >49be5000-49be7000 r--p 00000000 03:04 130027853  
> >/usr/share/locale/de/LC_MESSAGES/gtk+.mo
> >49be7000-49bf1000 r-xp 00000000 03:04 121637326  
> >/usr/X11R6/lib/X11/locale/common/xomGeneric.so.2
> >49bf1000-49bf2000 rw-p 00009000 03:04 121637326  
> >/usr/X11R6/lib/X11/locale/common/xomGeneric.so.2
> >49bf4000-49c19000 r-xp 00000000 03:04 109065746  
> >/usr/lib/libgdk_imlib.so.1.9.11
> >49c19000-49c1b000 rw-p 00024000 03:04 109065746  
> >/usr/lib/libgdk_imlib.so.1.9.11
> >49c1b000-49c32000 r--p 00000000 03:04 130023553  
> >/usr/share/locale/de/LC_MESSAGES/libc.mo
> >49c32000-49c62000 rw-s 00000000 00:05 105971720  /SYSV00000000 
> (deleted)>49c62000-49c65000 r-xp 00000000 03:04 109065750  
> /usr/lib/libimlib-png.so
> >49c65000-49c66000 rw-p 00002000 03:04 109065750  
> /usr/lib/libimlib-png.so
> >49c75000-49c9b000 r-xp 00000000 03:04 109052203 
> /usr/lib/libpng.so.3.1.2.1
> >49c9b000-49c9c000 rw-p 00025000 03:04 109052203 
> /usr/lib/libpng.so.3.1.2.1
> >
> >Local Time = Thu Jun 13 23:56:48 2002
> >Elapsed Time = 1
> >#
> ># The exception above was detected in native code outside the VM
> >#
> ># Java VM: Java HotSpot(TM) Client VM (1.3.1-b24 mixed mode)
> >#
> ># An error report file has been saved as hs_err_pid3162.log.
> ># Please refer to the file for further information.
> >#)
> >
> >
> >_______________________________________________________________
> >
> >Don't miss the 2002 Sprint PCS Application Developer's Conference
> >August 25-28 in Las Vegas -
> http://devcon.sprintpcs.co
> >
> >_______________________________________________
> >java-gnome-developer mailing list
> >jav...@li...
> >https://lists.sourceforge.net/lists/listinfo/java-gnome-developer
> >
> 
> 

[Java-gnome-developer] Java-GTK crashed...

[Clemens E. <cei...@ut...>]

Hello!

When I tried to run the following code, java-gtk crashed. I think its my 
fault, but wahts wrong:

GListString gls = new GListSting();
GtkList gtklist = new GtkList();

gtklist = (GtkList) glade.getWidget("list2");

gls.append("Hello");
gtklist.appendItem(gls);



I'm using Jdk1.3.1(Sun) which is shipped with JBuilder on an 
Mandrake-linux8.2.
My .jar file was originally compiled with Sun-Jdk-1.4.0
This fault happend with Java-gtk-0.7.1.

I hope I could help!(Or you could help me ;-) )



AL **: file gtkwidget.c: line 3356 (gtk_widget_set_parent): assertion 
`GTK_IS_WIDGET (widget)' failed.

Gtk-WARNING **: invalid cast from `(unknown)' to `GtkObject'

Gtk-CRITICAL **: file gtksignal.c: line 725 (gtk_signal_connect): 
assertion `GTK_IS_OBJECT (object)' failed.

Gtk-WARNING **: invalid cast from `(unknown)' to `GtkObject'

Gtk-CRITICAL **: file gtksignal.c: line 725 (gtk_signal_connect): 
assertion `GTK_IS_OBJECT (object)' failed.

Gtk-WARNING **: invalid cast from `(unknown)' to `GtkObject'

Gtk-CRITICAL **: file gtksignal.c: line 725 (gtk_signal_connect): 
assertion `GTK_IS_OBJECT (object)' failed.

Gtk-WARNING **: invalid cast from `(unknown)' to `GtkObject'

Gtk-CRITICAL **: file gtksignal.c: line 725 (gtk_signal_connect): 
assertion `GTK_IS_OBJECT (object)' failed.

Gtk-WARNING **: invalid cast from `(unknown)' to `GtkObject'

Gtk-CRITICAL **: file gtksignal.c: line 725 (gtk_signal_connect): 
assertion `GTK_IS_OBJECT (object)' failed.

Gtk-WARNING **: invalid cast from `(unknown)' to `GtkObject'

Gtk-CRITICAL **: file gtksignal.c: line 725 (gtk_signal_connect): 
assertion `GTK_IS_OBJECT (object)' failed.

Gtk-WARNING **: invalid cast from `(unknown)' to `GtkObject'

Gtk-CRITICAL **: file gtksignal.c: line 725 (gtk_signal_connect): 
assertion `GTK_IS_OBJECT (object)' failed.

Gtk-WARNING **: invalid cast from `(unknown)' to `GtkObject'

Gtk-CRITICAL **: file gtksignal.c: line 725 (gtk_signal_connect): 
assertion `GTK_IS_OBJECT (object)' failed.

Gtk-WARNING **: invalid cast from `(unknown)' to `GtkObject'

Gtk-CRITICAL **: file gtksignal.c: line 725 (gtk_signal_connect): 
assertion `GTK_IS_OBJECT (object)' failed.

Gtk-WARNING **: invalid cast from `(unknown)' to `GtkObject'

Gtk-CRITICAL **: file gtksignal.c: line 725 (gtk_signal_connect): 
assertion `GTK_IS_OBJECT (object)' failed.

Gtk-WARNING **: invalid cast from `(unknown)' to `GtkObject'

Gtk-CRITICAL **: file gtksignal.c: line 725 (gtk_signal_connect): 
assertion `GTK_IS_OBJECT (object)' failed.

Gtk-WARNING **: invalid cast from `(unknown)' to `GtkObject'

Gtk-CRITICAL **: file gtksignal.c: line 725 (gtk_signal_connect): 
assertion `GTK_IS_OBJECT (object)' failed.

Gtk-WARNING **: invalid cast from `(unknown)' to `GtkObject'

Gtk-CRITICAL **: file gtksignal.c: line 725 (gtk_signal_connect): 
assertion `GTK_IS_OBJECT (object)' failed.

Gtk-WARNING **: invalid cast from `(unknown)' to `GtkObject'

Gtk-CRITICAL **: file gtksignal.c: line 725 (gtk_signal_connect): 
assertion `GTK_IS_OBJECT (object)' failed.

An unexpected exception has been detected in native code outside the VM.
Unexpected Signal : 11 occurred at PC=0x49924c49
Function name=gtk_list_insert_items
Library=/usr/lib/libgtk-1.2.so.0

Current Java thread:
    at gnu.gtk.GtkList.appendItems(Native Method)
    at getwidgets.<init>(getwidgets.java:149)
    at gui.<init>(gui.java:15)
    at maingui.main(maingui.java:14)

Dynamic libraries:
08048000-0804c000 r-xp 00000000 03:04 58825300   
/opt/JBuilder6/jdk1.3.1/bin/i386/native_threads/java
0804c000-0804d000 rw-p 00003000 03:04 58825300   
/opt/JBuilder6/jdk1.3.1/bin/i386/native_threads/java
40000000-40014000 r-xp 00000000 03:04 71303310   /lib/ld-2.2.4.so
40014000-40015000 rw-p 00013000 03:04 71303310   /lib/ld-2.2.4.so
40016000-40017000 r--p 00000000 03:04 159383804  
/usr/share/locale/de_AT/LC_IDENTIFICATION
40017000-40018000 r--p 00000000 03:04 88080532   
/usr/share/locale/de_AT/LC_MEASUREMENT
40018000-40019000 r--p 00000000 03:04 159383801  
/usr/share/locale/de_AT/LC_TELEPHONE
40019000-4001a000 r--p 00000000 03:04 88080529   
/usr/share/locale/de_AT/LC_ADDRESS
4001a000-4001b000 r--p 00000000 03:04 88080528   
/usr/share/locale/de_AT/LC_NAME
4001b000-4001c000 r--p 00000000 03:04 88080530   
/usr/share/locale/de_AT/LC_PAPER
4001c000-4001d000 r--p 00000000 03:04 117440660  
/usr/share/locale/de_AT/LC_MESSAGES/SYS_LC_MESSAGES
4001d000-4001e000 r--p 00000000 03:04 159383803  
/usr/share/locale/de_AT/LC_MONETARY
4001e000-40024000 r--p 00000000 03:04 41943176   
/usr/share/locale/ISO-8859-15/LC_COLLATE
40024000-40025000 r--p 00000000 03:04 159383800  
/usr/share/locale/de_AT/LC_TIME
40025000-40033000 r-xp 00000000 03:04 71303355   /lib/libpthread-0.9.so
40033000-4003b000 rw-p 0000d000 03:04 71303355   /lib/libpthread-0.9.so
4003b000-40044000 r-xp 00000000 03:04 54594314   
/opt/JBuilder6/jdk1.3.1/jre/lib/i386/native_threads/libhpi.so
40044000-40045000 rw-p 00008000 03:04 54594314   
/opt/JBuilder6/jdk1.3.1/jre/lib/i386/native_threads/libhpi.so
40046000-402ad000 r-xp 00000000 03:04 58825296   
/opt/JBuilder6/jdk1.3.1/jre/lib/i386/client/libjvm.so
402ad000-40413000 rw-p 00266000 03:04 58825296   
/opt/JBuilder6/jdk1.3.1/jre/lib/i386/client/libjvm.so
4042a000-4042c000 r-xp 00000000 03:04 71303323   /lib/libdl-2.2.4.so
4042c000-4042d000 rw-p 00001000 03:04 71303323   /lib/libdl-2.2.4.so
4042d000-4055f000 r-xp 00000000 03:04 71303319   /lib/libc-2.2.4.so
4055f000-40565000 rw-p 00131000 03:04 71303319   /lib/libc-2.2.4.so
40569000-4057b000 r-xp 00000000 03:04 71303328   /lib/libnsl-2.2.4.so
4057b000-4057d000 rw-p 00011000 03:04 71303328   /lib/libnsl-2.2.4.so
4057f000-405a0000 r-xp 00000000 03:04 71303325   /lib/libm-2.2.4.so
405a0000-405a1000 rw-p 00020000 03:04 71303325   /lib/libm-2.2.4.so
405a1000-405da000 r-xp 00000000 03:04 109052195  
/usr/lib/libstdc++-3-libc6.2-2-2.10.0.so
405da000-405eb000 rw-p 00038000 03:04 109052195  
/usr/lib/libstdc++-3-libc6.2-2-2.10.0.so
405ef000-40600000 r-xp 00000000 03:04 50383490   
/opt/JBuilder6/jdk1.3.1/jre/lib/i386/libverify.so
40600000-40602000 rw-p 00010000 03:04 50383490   
/opt/JBuilder6/jdk1.3.1/jre/lib/i386/libverify.so
40602000-40623000 r-xp 00000000 03:04 50382204   
/opt/JBuilder6/jdk1.3.1/jre/lib/i386/libjava.so
40623000-40625000 rw-p 00020000 03:04 50382204   
/opt/JBuilder6/jdk1.3.1/jre/lib/i386/libjava.so
40626000-4063a000 r-xp 00000000 03:04 50383489   
/opt/JBuilder6/jdk1.3.1/jre/lib/i386/libzip.so
4063a000-4063d000 rw-p 00013000 03:04 50383489   
/opt/JBuilder6/jdk1.3.1/jre/lib/i386/libzip.so
4063d000-41356000 r--s 00000000 03:04 46140304   
/opt/JBuilder6/jdk1.3.1/jre/lib/rt.jar
41383000-41628000 r--s 00000000 03:04 46140306   
/opt/JBuilder6/jdk1.3.1/jre/lib/i18n.jar
41628000-4163e000 r--s 00000000 03:04 46140307   
/opt/JBuilder6/jdk1.3.1/jre/lib/sunrsasign.jar
436e6000-436e7000 r--p 00000000 03:04 159383802  
/usr/share/locale/de_AT/LC_NUMERIC
436e7000-436e9000 r-xp 00000000 03:04 109052070  
/usr/lib/libgmodule-1.2.so.0.0.10
436e9000-436ea000 rw-p 00001000 03:04 109052070  
/usr/lib/libgmodule-1.2.so.0.0.10
436ea000-436ec000 r-xp 00000000 03:04 121637322  
/usr/X11R6/lib/X11/locale/common/xlcDef.so.2
436ec000-436ed000 rw-p 00001000 03:04 121637322  
/usr/X11R6/lib/X11/locale/common/xlcDef.so.2
436ed000-436ef000 r-xp 00000000 03:04 134218021  
/usr/lib/gconv/ISO8859-15.so
436ef000-436f0000 rw-p 00001000 03:04 134218021  
/usr/lib/gconv/ISO8859-15.so
4974f000-49781000 r--p 00000000 03:04 125829264  
/usr/share/locale/de/LC_CTYPE
49781000-4978a000 r-xp 00000000 03:04 163680817  
/usr/lib/gtk/themes/engines/libpixmap.so
4978a000-4978c000 rw-p 00008000 03:04 163680817  
/usr/lib/gtk/themes/engines/libpixmap.so
4978c000-4978e000 r-xp 00000000 03:04 134218016  /usr/lib/gconv/ISO8859-1.so
4978e000-4978f000 rw-p 00001000 03:04 134218016  /usr/lib/gconv/ISO8859-1.so
49790000-49799000 r-xp 00000000 03:04 71303344   /lib/libnss_files-2.2.4.so
49799000-4979a000 rw-p 00008000 03:04 71303344   /lib/libnss_files-2.2.4.so
49806000-49838000 r--s 00000000 03:04 180474904  
/usr/local/share/java-gtk/gtk-0.7.1.jar
49838000-4988a000 r-xp 00000000 03:04 109225880  
/usr/local/lib/libGTKJava.so
4988a000-4988d000 rw-p 00051000 03:04 109225880  
/usr/local/lib/libGTKJava.so
4988d000-499c8000 r-xp 00000000 03:04 109052207  
/usr/lib/libgtk-1.2.so.0.9.1
499c8000-499cf000 rw-p 0013a000 03:04 109052207  
/usr/lib/libgtk-1.2.so.0.9.1
499d0000-49a07000 r-xp 00000000 03:04 109052205  
/usr/lib/libgdk-1.2.so.0.9.1
49a07000-49a09000 rw-p 00036000 03:04 109052205  
/usr/lib/libgdk-1.2.so.0.9.1
49a09000-49a2d000 r-xp 00000000 03:04 109052068  
/usr/lib/libglib-1.2.so.0.0.10
49a2d000-49a2f000 rw-p 00023000 03:04 109052068  
/usr/lib/libglib-1.2.so.0.0.10
49a2f000-49a36000 r-xp 00000000 03:04 117444173  /usr/X11R6/lib/libXi.so.6.0
49a36000-49a37000 rw-p 00006000 03:04 117444173  /usr/X11R6/lib/libXi.so.6.0
49a37000-49a45000 r-xp 00000000 03:04 117444167  
/usr/X11R6/lib/libXext.so.6.4
49a45000-49a46000 rw-p 0000d000 03:04 117444167  
/usr/X11R6/lib/libXext.so.6.4
49a46000-49b0a000 r-xp 00000000 03:04 117444159  
/usr/X11R6/lib/libX11.so.6.2
49b0a000-49b0d000 rw-p 000c3000 03:04 117444159  
/usr/X11R6/lib/libX11.so.6.2
49b0d000-49b24000 r-xp 00000000 03:04 109080847  /usr/lib/libglade.so.0.4.2
49b24000-49b26000 rw-p 00016000 03:04 109080847  /usr/lib/libglade.so.0.4.2
49b26000-49bad000 r-xp 00000000 03:04 109065742  /usr/lib/libxml.so.1.8.17
49bad000-49bb0000 rw-p 00086000 03:04 109065742  /usr/lib/libxml.so.1.8.17
49bb0000-49bbd000 r-xp 00000000 03:04 71367163   /lib/libz.so.1.1.3
49bbd000-49bbf000 rw-p 0000c000 03:04 71367163   /lib/libz.so.1.1.3
49bbf000-49bc5000 r-xp 00000000 03:04 71409070   /lib/libgcc_s-3.0.4.so.1
49bc5000-49bc8000 rw-p 00005000 03:04 71409070   /lib/libgcc_s-3.0.4.so.1
49bc8000-49be2000 r-xp 00000000 03:04 121637321  
/usr/X11R6/lib/X11/locale/common/ximcp.so.2
49be2000-49be5000 rw-p 00019000 03:04 121637321  
/usr/X11R6/lib/X11/locale/common/ximcp.so.2
49be5000-49be7000 r--p 00000000 03:04 130027853  
/usr/share/locale/de/LC_MESSAGES/gtk+.mo
49be7000-49bf1000 r-xp 00000000 03:04 121637326  
/usr/X11R6/lib/X11/locale/common/xomGeneric.so.2
49bf1000-49bf2000 rw-p 00009000 03:04 121637326  
/usr/X11R6/lib/X11/locale/common/xomGeneric.so.2
49bf4000-49c19000 r-xp 00000000 03:04 109065746  
/usr/lib/libgdk_imlib.so.1.9.11
49c19000-49c1b000 rw-p 00024000 03:04 109065746  
/usr/lib/libgdk_imlib.so.1.9.11
49c1b000-49c32000 r--p 00000000 03:04 130023553  
/usr/share/locale/de/LC_MESSAGES/libc.mo
49c32000-49c62000 rw-s 00000000 00:05 105971720  /SYSV00000000 (deleted)
49c62000-49c65000 r-xp 00000000 03:04 109065750  /usr/lib/libimlib-png.so
49c65000-49c66000 rw-p 00002000 03:04 109065750  /usr/lib/libimlib-png.so
49c75000-49c9b000 r-xp 00000000 03:04 109052203  /usr/lib/libpng.so.3.1.2.1
49c9b000-49c9c000 rw-p 00025000 03:04 109052203  /usr/lib/libpng.so.3.1.2.1

Local Time = Thu Jun 13 23:56:48 2002
Elapsed Time = 1
#
# The exception above was detected in native code outside the VM
#
# Java VM: Java HotSpot(TM) Client VM (1.3.1-b24 mixed mode)
#
# An error report file has been saved as hs_err_pid3162.log.
# Please refer to the file for further information.
#)

[Java-gnome-developer] updated GtkTreeView

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

I have just checked in the updated code for GtkTreeView,
GtkTreeModel, GtkTreeStore, and GtkListStore.  Beware!!!
This code is untested.  For those of you that have been
waiting for this widget any testing or example code you
might be able to provide would be greatly appreciated.

-Jeff

RE: [Java-gnome-developer] Problems Compiling

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

> Thanks. I have updated my environment settings and now it works. I am
> now going through the example programs and documentation. 

I am glad you are now working.  Just a note - the documentation is
not up-to-date with cvs.  If you are using the code from cvs you
are pretty much on your own.  I have gradually updated several of
the examples but not the documentation.  I hope to update all
documentation prior to the next release.

> 
> I've noticed you have src.rpm and some rpm packages in 
> sourceforge. As a
> Debian user, I can say that official Debian packages would be *really*
> useful. If you like, I could submit an item to the debian 
> "Work-Needing
> and Prospective Packages" system, in the "requested packages" section.
> Then, if there is a debian developer who is interested in the project
> and has some free time in the future, they would be able to 
> easily find
> about java-gnome from this system, and take a look at packaging it. I
> would be glad to submit an item for this, but would prefer 
> your approval
> first. 

You have my approval.

> 
> Thanks for all your work. After quickly looking at the examples, I am
> impressed, and look forward to seeing more of the GTK+2 code added.
> 

Please let me know about any bugs you find as you work 
with the project.  Any help is appreciated.

> 
> +----------------------------------------------+
> | Mark Howard                  mh...@ca... |
> | http://www.tildemh.com        mh...@ti... |
> +----------------------------------------------+
> 

RE: [Java-gnome-developer] Problems Compiling

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

On Mon, 2002-06-10 at 18:55, Jeffrey Morgan wrote:
> The problem has nothing to do with PangoColor.  The
> problem is that the compiler cannot find jni.h in
...

Thanks. I have updated my environment settings and now it works. I am
now going through the example programs and documentation. 

I've noticed you have src.rpm and some rpm packages in sourceforge. As a
Debian user, I can say that official Debian packages would be *really*
useful. If you like, I could submit an item to the debian "Work-Needing
and Prospective Packages" system, in the "requested packages" section.
Then, if there is a debian developer who is interested in the project
and has some free time in the future, they would be able to easily find
about java-gnome from this system, and take a look at packaging it. I
would be glad to submit an item for this, but would prefer your approval
first. 

Thanks for all your work. After quickly looking at the examples, I am
impressed, and look forward to seeing more of the GTK+2 code added.


+----------------------------------------------+
| Mark Howard                  mh...@ca... |
| http://www.tildemh.com        mh...@ti... |
+----------------------------------------------+

Re: [Java-gnome-developer] APIdoc packaged -Sorry...

[Clemens E. <Lin...@we...>]

Sorry for wasting traffic....

> Along the same note, you can generate javadocs by
> typing "make doc" in the src directory.
>