java-gnome-developer

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.

[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.

[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...>]

--- 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.

[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 <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.

[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