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

[Java-gnome-developer] signal descriptions

[Khiraly <khi...@gm...>]

Hi!

There are many signals of which I cannot discover how they are created,
to which there is no explanation.

All available signals are listed in glade-2, without any explanation.

In the documentation of www.gtk.org one can find the specifications of
the signal (the prototypes of the functions), but unfortunately that
what causes a signal is not described. In case of some, it is clear, but
in many other cases, it is obscure.
http://www.gtk.org/api/2.6/gtk/GtkEntry.html

E.g.: I'd like to know this: 
GtkCellEditable signal: editing_done
What could generate this one? This can be found at a Text Entry.

Best regards, 
Khiraly

Re: [Java-gnome-developer] Project

[Joao V. <jvi...@ya...>]

I don't think there's any benchmark for that, but i guess they're equally fast, since both are
just bindings to native code; so in the end both are running native code.

Cheers,
J.V.



--- Rafael George <geo...@gm...> wrote:
> Hi guys, i have a long time just checking the list and stuff, right
> now im thinking in creating a new project Wireless based, but i have a
> doubt another person that will work with me want to do it using C# on
> Mono he saids that its faster to use GTK# instance of Java-Gtk, is
> there some benchmark out there and which are the pattern design better
> to follow to get a solid application.
> 
> Thanks in advance
> -- 
> Grimoire Guru
> SourceMage GNU/Linux



	
	
		
Yahoo! Acesso Grátis - Internet rápida e grátis. 
Instale o discador agora! http://br.acesso.yahoo.com/

Re: [Java-gnome-developer] Project

[Jeff M. <ku...@gm...>]

Sorry for the traffic but I am afraid my first reply has gotten lost
in the sourceforge email hell.  This is a copy of my earlier reply.

On 4/25/05, Rafael George <geo...@gm...> wrote:
> Hi guys, i have a long time just checking the list and stuff, right
> now im thinking in creating a new project Wireless based, but i have a
> doubt another person that will work with me want to do it using C# on
> Mono he saids that its faster to use GTK# instance of Java-Gtk, is
> there some benchmark out there and which are the pattern design better
> to follow to get a solid application.

I am not aware of existing benchmarks.  My view is that you would find
very little difference in the overall performance of the two frameworks.
If you do conduct a benchmark please report the results back to this list.

The strength of the Java-GNOME approach is in the combination of the
framework, the compiler (gcj supporting both bytecode and native) and
the development environment Eclipse.  Java-GNOME running natively
is quite fast and currently runs on numerous hardware platforms.
We even have Windows support now.

If I were developing a GUI application using Java-GNOME I would take
the following approach:

1) Use TDD to develop the domain model.  This should contain no visual
code and should be functional and complete before moving to the next step.

2) I would use a variation of the Model / View / Presenter design pattern
for the user interface. You can read about this patter here:

http://www.martinfowler.com/eaaDev/ModelViewPresenter.html
http://www.objectmentor.com/resources/articles/TheHumbleDialogBox.pdf

Details of my specific implementation are:

a) Use glade to create the user interface.  Do not write any code at this
point - just model the look and work flow of the application.

b) Use TDD to develop the View.  I would create a mock object to represent
the Presenter at this stage.  This effort will flush out the interaction be=
tween
the view and presenter and allow unit tests that do not require a GUI.  Onc=
e
this is complete move to the next step.

c) Create your Presenter using the glade file you created earlier.  Since y=
ou
used glade your presenter is much simpler than if you had coded it by hand.
You presenter is a very thin wrapper around events which are then delegated
to the view.  I would not suggest having your view register for the events =
- I
would instead have the events propagated to the presenter and then have the
presenter make a call to the view.  Once the view is finished it can make a=
 call
(via the interface) to the presenter.  This causes your presenter to be cou=
pled
with the view but it really simplifies the code over the other alternative.

If you have pop up dialogs I would recommend creating a separate presenter =
class
for each of these.  They should delegate all of their events into the prese=
nter
for your main view which in turn collaborates with your view.

If you take this approach to develop your application you will end up with =
a
GUI application that has unit tests covering all logic.  Also, you will hav=
e a
layered application that is easy to maintain.


--=20
Jeffrey Morgan

"The highest reward for a man's toil is not
what he gets for it, but what he becomes by it"
    - Jon Ruskin

Fwd: [Java-gnome-developer] Project

[Jeff M. <ku...@gm...>]

Forgot to copy the list.



---------- Forwarded message ----------
From: Jeff Morgan <ku...@gm...>
Date: Apr 25, 2005 10:31 AM
Subject: Re: [Java-gnome-developer] Project
To: Rafael George <geo...@gm...>


On 4/25/05, Rafael George <geo...@gm...> wrote:
> Hi guys, i have a long time just checking the list and stuff, right
> now im thinking in creating a new project Wireless based, but i have a
> doubt another person that will work with me want to do it using C# on
> Mono he saids that its faster to use GTK# instance of Java-Gtk, is
> there some benchmark out there and which are the pattern design better
> to follow to get a solid application.

I am not aware of existing benchmarks.  My view is that you would find
very little difference in the overall performance of the two frameworks.
If you do conduct a benchmark please report the results back to this list.

The strength of the Java-GNOME approach is in the combination of the
framework, the compiler (gcj supporting both bytecode and native) and
the development environment Eclipse.  Java-GNOME running natively
is quite fast and is currently confirmed running on 8 hardware platforms.
We even have Windows support now.

If I were developing a GUI application using Java-GNOME I would take
the following approach:

1) Use TDD to develop the domain model.  This should contain no visual
code and should be functional and complete before moving to the next step.

2) I would use a variation of the Model / View / Presenter design pattern
for the user interface. You can read about this patter here:

http://www.martinfowler.com/eaaDev/ModelViewPresenter.html
http://www.objectmentor.com/resources/articles/TheHumbleDialogBox.pdf

Details of my specific implementation are:

a) Use glade to create the user interface.  Do not write any code at this
point - just model the look and work flow of the application.

b) Use TDD to develop the View.  I would create a mock object to represent
the Presenter at this stage.  This effort will flush out the interaction be=
tween
the view and presenter and allow unit tests that do not require a GUI.  Onc=
e
this is complete move to the next step.

c) Create your Presenter using the glade file you created earlier.  Since y=
ou
used glade your presenter is much simpler than if you had coded it by hand.
You presenter is a very thin wrapper around events which are then delegated
to the view.  I would not suggest having your view register for the events =
- I
would instead have the events propagated to the presenter and then have the
presenter make a call to the view.  Once the view is finished it can make a=
 call
(via the interface) to the presenter.  This causes your presenter to be cou=
pled
with the view but it really simplifies the code over the other alternative.

If you have pop up dialogs I would recommend creating a separate presenter =
class
for each of these.  They should delegate all of their events into the prese=
nter
for your main view which in turn collaborates with your view.

If you take this approach to develop your application you will end up with =
a
GUI application that has unit tests covering all logic.  Also, you will hav=
e a
layered application that is easy to maintain.

--
Jeffrey Morgan

"The highest reward for a man's toil is not
what he gets for it, but what he becomes by it"
    - Jon Ruskin


--=20
Jeffrey Morgan

"The highest reward for a man's toil is not
what he gets for it, but what he becomes by it"
    - Jon Ruskin

[Java-gnome-developer] Project

[Rafael G. <geo...@gm...>]

Hi guys, i have a long time just checking the list and stuff, right
now im thinking in creating a new project Wireless based, but i have a
doubt another person that will work with me want to do it using C# on
Mono he saids that its faster to use GTK# instance of Java-Gtk, is
there some benchmark out there and which are the pattern design better
to follow to get a solid application.

Thanks in advance
--=20
Grimoire Guru
SourceMage GNU/Linux

Re: [Java-gnome-developer] Screenshot of JG on Windows

[Arx H. <ar...@gm...>]

Yes :)

On 4/21/05, Jeff Morgan <ku...@gm...> wrote:
> This looks great.  Do we have permission to place the image on our
> site?
>=20
> -Jeff
>=20
>=20
> On 4/20/05, Joao Victor <jvi...@ya...> wrote:
> > Hello all,
> >
> > ArxCruz, a folk who frequents our irc channel, has just sent me a neat =
screenshot of JG running on
> > Windows (themed like a Windows app and all), and i thought i had to sha=
re this with you all ;) So
> > here it is!
> >
> > Cheers,
> > J.V.
> >
> > Yahoo! Acesso Gr=E1tis - Internet r=E1pida e gr=E1tis.
> > Instale o discador agora! http://br.acesso.yahoo.com/
> >
> >
>=20
> --
> Jeffrey Morgan
>=20
> "The highest reward for a man's toil is not
> what he gets for it, but what he becomes by it"
>     - Jon Ruskin
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: New Crystal Reports XI.
> Version 11 adds new functionality designed to reduce time involved in
> creating, integrating, and deploying reporting solutions. Free runtime in=
fo,
> new features, or free trial, at: http://www.businessobjects.com/devxi/728
> _______________________________________________
> java-gnome-developer mailing list
> jav...@li...
> https://lists.sourceforge.net/lists/listinfo/java-gnome-developer
>=20


--=20
"A f=E9 remove montanas, mas eu prefiro a dinamite"

Re: [Java-gnome-developer] Screenshot of JG on Windows

[Jeff M. <ku...@gm...>]

This looks great.  Do we have permission to place the image on our
site?

-Jeff


On 4/20/05, Joao Victor <jvi...@ya...> wrote:
> Hello all,
>=20
> ArxCruz, a folk who frequents our irc channel, has just sent me a neat sc=
reenshot of JG running on
> Windows (themed like a Windows app and all), and i thought i had to share=
 this with you all ;) So
> here it is!
>=20
> Cheers,
> J.V.
>=20
> Yahoo! Acesso Gr=E1tis - Internet r=E1pida e gr=E1tis.
> Instale o discador agora! http://br.acesso.yahoo.com/
>=20
>=20


--=20
Jeffrey Morgan

"The highest reward for a man's toil is not
what he gets for it, but what he becomes by it"
    - Jon Ruskin

Re: [Java-gnome-developer] German translation needed...

[Remy S. <rem...@gm...>]

On Thu, 2005-04-21 at 17:01 +1000, Jonathon Love wrote:
> >
> > Mandelbrot - Line 20
> 
> Isn't that mandelbrot like the mandelbrot fractal? isn't that already in
> english?

Yup, my mistake there. I had thought thought that brot was a German word
that was being appended to the name Mandel.

------

Thanks for the help, Bastian Doetsch. I will edit those in as soon as
possible.

Regards,
Rem

[Java-gnome-developer] Re: java-gnome-developer digest, Vol 1 #702 - 3 msgs

[Jonathon L. <j...@co...>]

>
> Mandelbrot - Line 20

Isn't that mandelbrot like the mandelbrot fractal? isn't that already in
english?

J.

[Java-gnome-developer] Screenshot of JG on Windows

[Joao V. <jvi...@ya...>]

Hello all,

ArxCruz, a folk who frequents our irc channel, has just sent me a neat screenshot of JG running on
Windows (themed like a Windows app and all), and i thought i had to share this with you all ;) So
here it is!

Cheers,
J.V.


	
	
		
Yahoo! Acesso Grátis - Internet rápida e grátis. 
Instale o discador agora! http://br.acesso.yahoo.com/

Re: [Java-gnome-developer] German translation needed...

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

On Wed, 2005-20-04 at 12:46 -0400, Remy Suen wrote:
> The mandel.glade file that's
> currently within doc/examples within libglade-java cannot be opened by
> Glade 2. The following words need to be translated into proper English
> in order for me to finish cleaning up the XML file via libglade-convert.

Is the trouble here that the libglade-convert script (which, admittedly,
is like 3 years old) can't deal with UTF-8 characters (or whatever they
are) or is it something on the java-gnome side of the house?

AfC
Santa Clara

[Java-gnome-developer] Translation

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

Related to Hiro's recent posting are two broader issues:

1) are we treating international characters [sets] correctly? 

2) what sort of API should we use in java-gnome to provide for
translation?

*Personally*, I find the GNU/GNOME translation infrastructure somewhat
cumbersome, but there is no denying there is middling string momentum
there.

In C, they use _( "String in English" ) which the calls gettext and what
not to figure out what an appropriate localized translation would be.
I'm suspecting that specific construct won't work in Java [_ isn't a
valud function identifier, is it?; in any case, there are some Java
specific translation methodologies out there that seem to work pretty
well.

I invite comment about what direction we should go.

AfC
Santa Clara

-- 
Andrew Frederick Cowie
Management Consultant

Technology strategy, managing change, establishing procedures,
and executing successful upgrades to mission critical business
infrastructure.

http://www.operationaldynamics.com/

Sydney   New York   Toronto   London

[Java-gnome-developer] German translation needed...

[Remy S. <rem...@gm...>]

I'm pretty sure this is German anyway. The mandel.glade file that's
currently within doc/examples within libglade-java cannot be opened by
Glade 2. The following words need to be translated into proper English
in order for me to finish cleaning up the XML file via libglade-convert.

Mandelbrot - Line 20
Fraktal berechnen (averaging fractals?) - Line 83
Imagin=E4rabschnitt (nur f=FCr Juliamenge) - Line 298
Realabschnitt (nur f=FCr Juliamenge) - Line 325
Tiefe der Rekursion - Line 351
Minimum Imagin=E4rteil - Line 377
Maximum Imagin=E4rteil - Line 403
Minimum Realanteil - Line 429
Maximum Realanteil - Line 455
Bildauswahl - Line 648
rbtn_apfel - Line 666
Apfelm=E4nnchen ausw=E4hlen - Line 667
Apfelm=E4nnchen - Line 669
rbtn_julia - Line 682
Juliamenge ausw=E4hlen - Line 683
Juliamenge - Line 685

The original file can be referenced here:
http://cvs.gnome.org/viewcvs/*checkout*/libglade-java/doc/examples/mandel=
/mandel.glade?rev=3D1.1

If I missed any, please do translate those as well in addition to providi=
ng me with the line numbers.

Thanks!
Rem

Re: [Java-gnome-developer] updating GNomeAppBar.progressbar while running a long process.

[Joao V. <jvi...@ya...>]

--- Ismael Juma <ml...@ju...> wrote:
> The point is you don't know when the other thread will read the right
> value. For all you know, the thread could read its 'local' copy several
> times before it reads the updated one. Even though it might work fine in
> a certain implementation, it is really undefined behaviour and
> definitely not recommended. I understand that this is not
> mission-critical as it is only a progress bar, but I don't think we
> should recommend people to do that in a tutorial. All of this imho of
> course.

Well, putting it volatile won't do no harm, so i just updated it.... ;)

Cheers,
J.V.


__________________________________________________
Converse com seus amigos em tempo real com o Yahoo! Messenger 
http://br.download.yahoo.com/messenger/ 

Re: [Java-gnome-developer] updating GNomeAppBar.progressbar while running a long process.

[Ismael J. <ml...@ju...>]

On Tue, 2005-04-19 at 08:30 -0300, Joao Victor wrote:
[...]
> 
> I know about that... but i think in this situation it's not a problem, because there is only 1
> thread changing fraction, the other is just reading. IMHO, in the worst case, the thread that
> reads will read an old value... which is alright, since it'll read the right value anyway when the
> Timer ticks again. I might be wrong though.
[...]

The point is you don't know when the other thread will read the right
value. For all you know, the thread could read its 'local' copy several
times before it reads the updated one. Even though it might work fine in
a certain implementation, it is really undefined behaviour and
definitely not recommended. I understand that this is not
mission-critical as it is only a progress bar, but I don't think we
should recommend people to do that in a tutorial. All of this imho of
course.

Regards,
Ismael

Re: [Java-gnome-developer] updating GNomeAppBar.progressbar while running a long process.

[Joao V. <jvi...@ya...>]

--- Ismael Juma <is...@ju...> wrote:
> It's quite late here, so I might have missed something, but to me that
> code is not totally correct. You are accessing the field fraction from
> two different threads, but you do not take any measures to ensure that
> both threads see the correct value. I guess that since only one thread
> is changing the value, setting fraction to volatile should be enough.

I know about that... but i think in this situation it's not a problem, because there is only 1
thread changing fraction, the other is just reading. IMHO, in the worst case, the thread that
reads will read an old value... which is alright, since it'll read the right value anyway when the
Timer ticks again. I might be wrong though.

Cheers,
J.V.



	
	
		
Yahoo! Acesso Grátis - Internet rápida e grátis. 
Instale o discador agora! http://br.acesso.yahoo.com/

Re: [Java-gnome-developer] updating GNomeAppBar.progressbar while running a long process.

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

Just to clairfy this, are you creating a new java thread in an event handler,
doing some processing in this thread then calling CustomEvents to update the
interface? 
If you're just calling CustomEvents from the event handler this will not work,
since the event handler is being called from the Gtk thread. 
One thing to try would be to make the thread a class variable - we might be
doing something wrong with the event handler.
Is the rest of the gui still responsive when you are doing the processing? can
you still access menus?

On Sat, Apr 16, 2005 at 11:03:56PM -0400, Manuel Ledesma wrote:
> How can I update the progress bar from the GNomeAppBar while running a process
> in a dialog window. I have tried Implementing Fireable and a Time, Runable
> Using CustomEvents.addEvent and I'm getting always the same behavior. Progress
> bar don't get update it till the process is completed. Is there anyway of
> showing the progressbar updates while running a long process ?

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

Re: [Java-gnome-developer] updating GNomeAppBar.progressbar while running a long process.

[Ismael J. <ml...@ju...>]

On Mon, 2005-04-18 at 23:24 -0300, Joao Victor wrote:
[..]
> 
> I think you can still use a Timer on that. In fact, it seems when you use Swing's JProgressBar you
> actually use it with a Timer... so i think that's the common way of doing it, to put it this way.
> 
> I just wrote a tutorial about how to do it, hope it helps (if not, let me know):
> 
> http://java-gnome.sourceforge.net/cgi-bin/bin/view/Main/UsingProgressBars
> 
> (yup, we still are going to fix the CustomEvents... but anyway i think you should use a
> progressbar with a Timer, like that tutorial)
[..]

It's quite late here, so I might have missed something, but to me that
code is not totally correct. You are accessing the field fraction from
two different threads, but you do not take any measures to ensure that
both threads see the correct value. I guess that since only one thread
is changing the value, setting fraction to volatile should be enough.

Regards,
Ismael

Re: [Java-gnome-developer] updating GNomeAppBar.progressbar while running a long process.

[Joao V. <jvi...@ya...>]

--- Manuel Ledesma <man...@co...> wrote:
> There is an example already using timer and fireable from gnome library
> and it seems to work fine. My problem is that I'm opening a dialog to
> collect some user information and after user acceptance and doing some
> processing. So timer and fireable does not work for me either and I was
> expecting to use CustomEvents but unfortunately i got the same results.
> Something that I believe make things more difficult is that whenever I
> call Dialog.hide or hideAll and it does not seems to have any effect
> because the Dialog does not disappear until function is completely done.
> One thing that can help you to fix this problem is to hide the dialog
> right away (require a redraw) and set focus back to the call window.

I think you can still use a Timer on that. In fact, it seems when you use Swing's JProgressBar you
actually use it with a Timer... so i think that's the common way of doing it, to put it this way.

I just wrote a tutorial about how to do it, hope it helps (if not, let me know):

http://java-gnome.sourceforge.net/cgi-bin/bin/view/Main/UsingProgressBars

(yup, we still are going to fix the CustomEvents... but anyway i think you should use a
progressbar with a Timer, like that tutorial)

Cheers,
J.V.



__________________________________________________
Converse com seus amigos em tempo real com o Yahoo! Messenger 
http://br.download.yahoo.com/messenger/ 

Re: [Java-gnome-developer] updating GNomeAppBar.progressbar while running a long process.

[Manuel L. <man...@co...>]

There is an example already using timer and fireable from gnome library
and it seems to work fine. My problem is that I'm opening a dialog to
collect some user information and after user acceptance and doing some
processing. So timer and fireable does not work for me either and I was
expecting to use CustomEvents but unfortunately i got the same results.
Something that I believe make things more difficult is that whenever I
call Dialog.hide or hideAll and it does not seems to have any effect
because the Dialog does not disappear until function is completely done.
One thing that can help you to fix this problem is to hide the dialog
right away (require a redraw) and set focus back to the call window.
=20
On Mon, 2005-04-18 at 09:09 -0300, Joao Victor wrote:

> There seems to be a little problem when using progressbars. Is Manuel Led=
esma =3D=3D Lamex? Because
> Lamex was reporting something like this on irc this week.
>=20
> It _seems_ the problem happens when you use CustomEvents to create the th=
read that will update the
> progressbar. So yeah, not exactly a progressbar-problem, but a CustomEven=
ts-problem. It seems Jeff
> is planning to rewrite the CustomEvents, or something like that.
>=20
> Apparently, the progressbar works fine when you use a Timer to update the=
 progressbar. Maybe you
> could use that, Manuel, while we fix the CustomEvents (if that's what you=
're using). The way to
> use it is to store in some Class field the current progressbar fraction; =
and on every timeout of
> the Timer you update the progressbar with the current fraction. Hmmm we n=
eed a tutorial on this...
> well, if you didn't understand i could write some example code for you. S=
o let us know if you
> can't fix the problem.
>=20
> Cheers,
> J.V.
>=20
>=20
>=20
>=20
> --- Andrew Cowie <an...@op...> wrote:
> > On Sun, 2005-17-04 at 11:18 -0400, Manuel Ledesma wrote:
> > > I can not download your code.
> >=20
> > I just tested the commands listed there, and they appeared to work fine=
.
> > Andrew Overholt at Red Hat ran the instructions last week and they
> > worked. What seems to be the problem, precisely?
> >=20
> > > Could you send the a tar/zip  ?
> >=20
> > Preparing and posting such is the task I might do in the next week or s=
o
> > that I referred to ... but the arch commands should work fine.
> >=20
> > [Yes, tla Arch is a bit silly, and I've switched away from it to Darcs]
> >=20
> > AfC
> > San Francisco
>=20
>=20
>=20
> =09
> =09
> 	=09
> Yahoo! Acesso Gr=E1tis - Internet r=E1pida e gr=E1tis.=20
> Instale o discador agora! http://br.acesso.yahoo.com/
>=20
>=20
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick
> _______________________________________________
> java-gnome-developer mailing list
> jav...@li...
> https://lists.sourceforge.net/lists/listinfo/java-gnome-developer

[Java-gnome-developer] Native Segfault

[pancake <pa...@ph...>]

I'll be good to take a look on org.gnu.gtk.StatusBar.pop()... i'm using libgtk-java-2.6.0.

This error ocurred trying to acces a lot of times with push()/pop() on statusbar. it seems that something is not handled properly.

$--EOF--$

An unexpected exception has been detected in native code outside the VM.
Unexpected Signal : 11 occurred at PC=0xB7F06EA4
Function=(null)
Library=/lib/tls/libc.so.6

NOTE: We are unable to locate the function name symbol for the error
      just occurred. Please refer to release documentation for possible
      reason and solutions.


Current Java thread:
        at org.gnu.gtk.StatusBar.gtk_statusbar_pop(Native Method)
        at org.gnu.gtk.StatusBar.pop(StatusBar.java:87)
        at Mplayer.run(Mplayer.java:35)
Dynamic libraries:
08048000-08056000 r-xp 00000000 03:02 973593     /usr/pkg/java/sun-1.4/bin/java
08056000-08059000 rwxp 0000d000 03:02 973593     /usr/pkg/java/sun-1.4/bin/java
aae90000-aae96000 r-xp 00000000 03:02 1170146    /usr/pkg/lib/gtk-2.0/2.4.0/loaders/libpixbufloader-xpm.so
aae96000-aae98000 rwxp 00006000 03:02 1170146    /usr/pkg/lib/gtk-2.0/2.4.0/loaders/libpixbufloader-xpm.so
aae98000-aae9e000 r-xp 00000000 03:02 1205433    /usr/pkg/xorg/lib/X11/fonts/misc/clR6x12.pcf.gz
aae9e000-aaeaf000 r-xp 00000000 03:02 1153062    /usr/pkg/xorg/lib/X11/fonts/TTF/Vera.ttf
aaeaf000-aaeba000 r-xp 00000000 03:02 568794     /usr/pkg/lib/gtk-2.0/2.4.0/engines/libindustrial.so
aaeba000-aaebb000 rwxp 0000b000 03:02 568794     /usr/pkg/lib/gtk-2.0/2.4.0/engines/libindustrial.so
aaebb000-aaed8000 r-xp 00000000 03:02 941305     /usr/pkg/lib/libexpat.so.0.5.0
aaed8000-aaedb000 rwxp 0001d000 03:02 941305     /usr/pkg/lib/libexpat.so.0.5.0
aaedb000-aaf00000 r-xp 00000000 03:02 1185080    /usr/pkg/lib/libpangoft2-1.0.so.0.800.0
aaf00000-aaf01000 rwxp 00025000 03:02 1185080    /usr/pkg/lib/libpangoft2-1.0.so.0.800.0
aaf01000-aaf08000 r-xp 00000000 03:02 941564     /usr/pkg/lib/libXrender.so.1.2.2
aaf08000-aaf09000 rwxp 00006000 03:02 941564     /usr/pkg/lib/libXrender.so.1.2.2
aaf09000-aaf11000 r-xp 00000000 03:02 950327     /usr/pkg/lib/libXcursor.so.1.0.2
aaf11000-aaf12000 rwxp 00007000 03:02 950327     /usr/pkg/lib/libXcursor.so.1.0.2
aaf12000-aaf16000 r-xp 00000000 03:02 1158428    /usr/pkg/xorg/lib/libXfixes.so.3.0
aaf16000-aaf17000 rwxp 00003000 03:02 1158428    /usr/pkg/xorg/lib/libXfixes.so.3.0
aaf17000-aaf3d000 r-xp 00000000 03:02 941338     /usr/pkg/lib/libfontconfig.so.1.0.4
aaf3d000-aaf42000 rwxp 00025000 03:02 941338     /usr/pkg/lib/libfontconfig.so.1.0.4
aaf42000-aaf52000 r-xp 00000000 03:02 941534     /usr/pkg/lib/libz.so.1.0.2
aaf52000-aaf53000 rwxp 0000f000 03:02 941534     /usr/pkg/lib/libz.so.1.0.2
aaf53000-aafb6000 r-xp 00000000 03:02 941267     /usr/pkg/lib/libfreetype.so.6.3.7
aafb6000-aafbd000 rwxp 00063000 03:02 941267     /usr/pkg/lib/libfreetype.so.6.3.7
aafbd000-aafce000 r-xp 00000000 03:02 1192673    /usr/pkg/lib/libXft.so.2.1.2
aafce000-aafcf000 rwxp 00011000 03:02 1192673    /usr/pkg/lib/libXft.so.2.1.2
aafcf000-aafdc000 r-xp 00000000 03:02 1157577    /usr/pkg/xorg/lib/libXext.so.6.4
aafdc000-aafdd000 rwxp 0000c000 03:02 1157577    /usr/pkg/xorg/lib/libXext.so.6.4
aafdd000-aafe4000 r-xp 00000000 03:02 1157874    /usr/pkg/xorg/lib/libXi.so.6.0
aafe4000-aafe5000 rwxp 00006000 03:02 1157874    /usr/pkg/xorg/lib/libXi.so.6.0
aafe5000-aafe8000 r-xp 00000000 03:02 1192663    /usr/pkg/lib/libXrandr.so.2.0.1
aafe8000-aafe9000 rwxp 00002000 03:02 1192663    /usr/pkg/lib/libXrandr.so.2.0.1
aafe9000-aafee000 r-xp 00000000 03:02 389647     /lib/tls/librt-2.3.2.so
aafee000-aafef000 rwxp 00005000 03:02 389647     /lib/tls/librt-2.3.2.so
aaff7000-aaff9000 r-xp 00000000 03:02 600711     /usr/lib/gconv/ISO8859-1.so
aaff9000-aaffa000 rwxp 00001000 03:02 600711     /usr/lib/gconv/ISO8859-1.so
aaffa000-aaffc000 r-xp 00000000 03:02 1157520    /usr/pkg/xorg/lib/X11/locale/lib/common/xlcDef.so.2
aaffc000-aaffd000 rwxp 00001000 03:02 1157520    /usr/pkg/xorg/lib/X11/locale/lib/common/xlcDef.so.2
aaffd000-ab0c3000 r-xp 00000000 03:02 1157492    /usr/pkg/xorg/lib/libX11.so.6.2
ab0c3000-ab0c7000 rwxp 000c6000 03:02 1157492    /usr/pkg/xorg/lib/libX11.so.6.2
ab0c7000-ab146000 r-xp 00000000 03:02 1184377    /usr/pkg/lib/libglib-2.0.so.0.600.2
ab146000-ab147000 rwxp 0007e000 03:02 1184377    /usr/pkg/lib/libglib-2.0.so.0.600.2
ab147000-ab14a000 r-xp 00000000 03:02 207        /usr/pkg/lib/libgmodule-2.0.so.0.600.2
ab14a000-ab14b000 rwxp 00002000 03:02 207        /usr/pkg/lib/libgmodule-2.0.so.0.600.2
ab14b000-ab17d000 r-xp 00000000 03:02 1184737    /usr/pkg/lib/libgobject-2.0.so.0.600.2
ab17d000-ab17e000 rwxp 00032000 03:02 1184737    /usr/pkg/lib/libgobject-2.0.so.0.600.2
ab17e000-ab1b2000 r-xp 00000000 03:02 1184392    /usr/pkg/lib/libpango-1.0.so.0.800.0
ab1b2000-ab1b7000 rwxp 00033000 03:02 1184392    /usr/pkg/lib/libpango-1.0.so.0.800.0
ab1b7000-ab1c1000 r-xp 00000000 03:02 1185072    /usr/pkg/lib/libpangox-1.0.so.0.800.0
ab1c1000-ab1c2000 rwxp 0000a000 03:02 1185072    /usr/pkg/lib/libpangox-1.0.so.0.800.0
ab1c2000-ab1c8000 r-xp 00000000 03:02 1185086    /usr/pkg/lib/libpangoxft-1.0.so.0.800.0
ab1c8000-ab1c9000 rwxp 00005000 03:02 1185086    /usr/pkg/lib/libpangoxft-1.0.so.0.800.0
ab1c9000-ab1dd000 r-xp 00000000 03:02 944957     /usr/pkg/lib/libgdk_pixbuf-2.0.so.0.600.4
ab1dd000-ab1de000 rwxp 00014000 03:02 944957     /usr/pkg/lib/libgdk_pixbuf-2.0.so.0.600.4
ab1de000-ab1f5000 r-xp 00000000 03:02 943876     /usr/pkg/lib/libatk-1.0.so.0.900.0
ab1f5000-ab1f7000 rwxp 00016000 03:02 943876     /usr/pkg/lib/libatk-1.0.so.0.900.0
ab1f7000-ab270000 r-xp 00000000 03:02 950353     /usr/pkg/lib/libgdk-x11-2.0.so.0.600.4
ab270000-ab273000 rwxp 00079000 03:02 950353     /usr/pkg/lib/libgdk-x11-2.0.so.0.600.4
ab273000-ab537000 r-xp 00000000 03:02 950360     /usr/pkg/lib/libgtk-x11-2.0.so.0.600.4
ab537000-ab53f000 rwxp 002c3000 03:02 950360     /usr/pkg/lib/libgtk-x11-2.0.so.0.600.4
ab542000-ab5fd000 r-xp 00000000 03:02 942101     /usr/pkg/lib/libgtkjni-2.6.so
ab5fd000-ab601000 rwxp 000ba000 03:02 942101     /usr/pkg/lib/libgtkjni-2.6.so
ab601000-ab699000 r-xs 00000000 03:02 961685     /usr/pkg/share/java/gtk2.6-2.6.0.jar
ab699000-ab754000 r-xs 00000000 03:02 973758     /usr/pkg/java/sun-1.4/lib/ext/localedata.jar
ab754000-ab761000 r-xs 00000000 03:02 973757     /usr/pkg/java/sun-1.4/lib/ext/ldapsec.jar
ab761000-ab764000 r-xs 00000000 03:02 973749     /usr/pkg/java/sun-1.4/lib/ext/dnsns.jar
ab764000-ab780000 r-xs 00000000 03:02 973746     /usr/pkg/java/sun-1.4/lib/ext/sunjce_provider.jar
b3b89000-b3b8b000 r-xp 00000000 03:02 259767     /usr/pkg/lib/pango/1.4.0/modules/pango-basic-fc.so
b3b8b000-b3b8c000 rwxp 00001000 03:02 259767     /usr/pkg/lib/pango/1.4.0/modules/pango-basic-fc.so
b5c34000-b617d000 r-xs 00000000 03:02 975789     /usr/pkg/java/sun-1.4/lib/charsets.jar
b617d000-b618e000 r-xs 00000000 03:02 973761     /usr/pkg/java/sun-1.4/lib/jce.jar
b618e000-b6267000 r-xs 00000000 03:02 974009     /usr/pkg/java/sun-1.4/lib/jsse.jar
b6267000-b627d000 r-xs 00000000 03:02 973759     /usr/pkg/java/sun-1.4/lib/sunrsasign.jar
b62c7000-b79b1000 r-xs 00000000 03:02 975792     /usr/pkg/java/sun-1.4/lib/rt.jar
b79b1000-b79c5000 r-xp 00000000 03:02 973673     /usr/pkg/java/sun-1.4/lib/i386/libzip.so
b79c5000-b79c8000 rwxp 00013000 03:02 973673     /usr/pkg/java/sun-1.4/lib/i386/libzip.so
b79c8000-b79e8000 r-xp 00000000 03:02 973671     /usr/pkg/java/sun-1.4/lib/i386/libjava.so
b79e8000-b79ea000 rwxp 0001f000 03:02 973671     /usr/pkg/java/sun-1.4/lib/i386/libjava.so
b79ea000-b79fa000 r-xp 00000000 03:02 973670     /usr/pkg/java/sun-1.4/lib/i386/libverify.so
b79fa000-b79fc000 rwxp 0000f000 03:02 973670     /usr/pkg/java/sun-1.4/lib/i386/libverify.so
b79fc000-b7a05000 r-xp 00000000 03:02 389640     /lib/tls/libnss_files-2.3.2.so
b7a05000-b7a06000 rwxp 00008000 03:02 389640     /lib/tls/libnss_files-2.3.2.so
b7a06000-b7a0e000 r-xp 00000000 03:02 389642     /lib/tls/libnss_nis-2.3.2.so
b7a0e000-b7a0f000 rwxp 00007000 03:02 389642     /lib/tls/libnss_nis-2.3.2.so
b7a0f000-b7a16000 r-xp 00000000 03:02 389638     /lib/tls/libnss_compat-2.3.2.so
b7a16000-b7a17000 rwxp 00006000 03:02 389638     /lib/tls/libnss_compat-2.3.2.so
b7a21000-b7a25000 rwxs 00000000 03:02 947163     /tmp/hsperfdata_pancake/17980
b7a25000-b7a46000 r-xp 00000000 03:02 389635     /lib/tls/libm-2.3.2.so
b7a46000-b7a47000 rwxp 00020000 03:02 389635     /lib/tls/libm-2.3.2.so
b7a47000-b7a58000 r-xp 00000000 03:02 389637     /lib/tls/libnsl-2.3.2.so
b7a58000-b7a59000 rwxp 00011000 03:02 389637     /lib/tls/libnsl-2.3.2.so
b7a60000-b7a68000 r-xp 00000000 03:02 973637     /usr/pkg/java/sun-1.4/lib/i386/native_threads/libhpi.so
b7a68000-b7a69000 rwxp 00007000 03:02 973637     /usr/pkg/java/sun-1.4/lib/i386/native_threads/libhpi.so
b7a69000-b7e65000 r-xp 00000000 03:02 973662     /usr/pkg/java/sun-1.4/lib/i386/client/libjvm.so
b7e65000-b7e81000 rwxp 003fb000 03:02 973662     /usr/pkg/java/sun-1.4/lib/i386/client/libjvm.so
b7e94000-b7fbd000 r-xp 00000000 03:02 389631     /lib/tls/libc-2.3.2.so
b7fbd000-b7fc5000 rwxp 00129000 03:02 389631     /lib/tls/libc-2.3.2.so
b7fc8000-b7fca000 r-xp 00000000 03:02 389634     /lib/tls/libdl-2.3.2.so
b7fca000-b7fcb000 rwxp 00002000 03:02 389634     /lib/tls/libdl-2.3.2.so
b7fcc000-b7fd8000 r-xp 00000000 03:02 389645     /lib/tls/libpthread-0.60.so
b7fd8000-b7fd9000 rwxp 0000c000 03:02 389645     /lib/tls/libpthread-0.60.so
b7fea000-b8000000 r-xp 00000000 03:02 389549     /lib/ld-2.3.2.so
b8000000-b8001000 rwxp 00015000 03:02 389549     /lib/ld-2.3.2.so

Heap at VM Abort:
Heap
 def new generation   total 576K, used 475K [0xabb80000, 0xabc20000, 0xac060000)
  eden space 512K,  81% used [0xabb80000, 0xabbe7b20, 0xabc00000)
  from space 64K,  94% used [0xabc10000, 0xabc1f1c8, 0xabc20000)
  to   space 64K,   0% used [0xabc00000, 0xabc00000, 0xabc10000)
 tenured generation   total 1408K, used 183K [0xac060000, 0xac1c0000, 0xafb80000)
   the space 1408K,  13% used [0xac060000, 0xac08de48, 0xac08e000, 0xac1c0000)
 compacting perm gen  total 4096K, used 1601K [0xafb80000, 0xaff80000, 0xb3b80000)
   the space 4096K,  39% used [0xafb80000, 0xafd10770, 0xafd10800, 0xaff80000)

Local Time = Tue Apr 19 00:29:48 2005
Elapsed Time = 92
#
# The exception above was detected in native code outside the VM
#
# Java VM: Java HotSpot(TM) Client VM (1.4.2_06-b03 mixed mode)
#
# An error report file has been saved as hs_err_pid17980.log.
# Please refer to the file for further information.
#


$--EOF--$

Re: [Java-gnome-developer] updating GNomeAppBar.progressbar while running a long process.

[Joao V. <jvi...@ya...>]

There seems to be a little problem when using progressbars. Is Manuel Ledesma == Lamex? Because
Lamex was reporting something like this on irc this week.

It _seems_ the problem happens when you use CustomEvents to create the thread that will update the
progressbar. So yeah, not exactly a progressbar-problem, but a CustomEvents-problem. It seems Jeff
is planning to rewrite the CustomEvents, or something like that.

Apparently, the progressbar works fine when you use a Timer to update the progressbar. Maybe you
could use that, Manuel, while we fix the CustomEvents (if that's what you're using). The way to
use it is to store in some Class field the current progressbar fraction; and on every timeout of
the Timer you update the progressbar with the current fraction. Hmmm we need a tutorial on this...
well, if you didn't understand i could write some example code for you. So let us know if you
can't fix the problem.

Cheers,
J.V.




--- Andrew Cowie <an...@op...> wrote:
> On Sun, 2005-17-04 at 11:18 -0400, Manuel Ledesma wrote:
> > I can not download your code.
> 
> I just tested the commands listed there, and they appeared to work fine.
> Andrew Overholt at Red Hat ran the instructions last week and they
> worked. What seems to be the problem, precisely?
> 
> > Could you send the a tar/zip  ?
> 
> Preparing and posting such is the task I might do in the next week or so
> that I referred to ... but the arch commands should work fine.
> 
> [Yes, tla Arch is a bit silly, and I've switched away from it to Darcs]
> 
> AfC
> San Francisco



	
	
		
Yahoo! Acesso Grátis - Internet rápida e grátis. 
Instale o discador agora! http://br.acesso.yahoo.com/

Re: [Java-gnome-developer] updating GNomeAppBar.progressbar while running a long process.

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

On Sun, 2005-17-04 at 11:18 -0400, Manuel Ledesma wrote:
> I can not download your code.

I just tested the commands listed there, and they appeared to work fine.
Andrew Overholt at Red Hat ran the instructions last week and they
worked. What seems to be the problem, precisely?

> Could you send the a tar/zip  ?

Preparing and posting such is the task I might do in the next week or so
that I referred to ... but the arch commands should work fine.

[Yes, tla Arch is a bit silly, and I've switched away from it to Darcs]

AfC
San Francisco

Re: [Java-gnome-developer] updating GNomeAppBar.progressbar while running a long process.

[Manuel L. <man...@co...>]

I can not download your code. Could you send the a tar/zip through
e-mail ?

On Sun, 2005-04-17 at 01:08 -0700, Andrew Cowie wrote:

> On Sat, 2005-16-04 at 23:03 -0400, Manuel Ledesma wrote:
> > How can I update the progress bar from the GNomeAppBar while running a
> > process in a dialog window. I have tried Implementing Fireable and a
> > Time, Runable Using CustomEvents.addEvent and I'm getting always the
> > same behavior. Progress bar don't get update it till the process is
> > completed. Is there anyway of showing the progressbar updates while
> > running a long process ?
> 
> I have a piece of example code that shows that. See
> http://research.operationaldynamics.com/projects/scripts/geode/README-java
> 
> Some day soon I'll package that up a bit nicer and release it as a
> useful example of a piece of java-gnome code updating a UI from a worker
> thread, but for now you can at least look at some code by following the
> instructions in that file.
> 
> AfC
> Los Angeles
> 
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> java-gnome-developer mailing list
> jav...@li...
> https://lists.sourceforge.net/lists/listinfo/java-gnome-developer

Re: [Java-gnome-developer] updating GNomeAppBar.progressbar while running a long process.

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

On Sat, 2005-16-04 at 23:03 -0400, Manuel Ledesma wrote:
> How can I update the progress bar from the GNomeAppBar while running a
> process in a dialog window. I have tried Implementing Fireable and a
> Time, Runable Using CustomEvents.addEvent and I'm getting always the
> same behavior. Progress bar don't get update it till the process is
> completed. Is there anyway of showing the progressbar updates while
> running a long process ?

I have a piece of example code that shows that. See
http://research.operationaldynamics.com/projects/scripts/geode/README-java

Some day soon I'll package that up a bit nicer and release it as a
useful example of a piece of java-gnome code updating a UI from a worker
thread, but for now you can at least look at some code by following the
instructions in that file.

AfC
Los Angeles