Bug 86993

Summary:	Statusbar element placement is awkward
Product:	[Applications] kst	Reporter:	Rick Chern <rchern>
Component:	general	Assignee:	kst
Status:	RESOLVED FIXED
Severity:	wishlist
Priority:	NOR
Version:	1.x
Target Milestone:	---
Platform:	RedHat Enterprise Linux
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description Rick Chern 2004-08-11 21:19:43 UTC

Version:           0.99-devel (using KDE KDE 3.2.1)
Installed from:    RedHat RPMs
OS:                Linux

The placement of statusbar elements is a bit awkward.  The data coordinate section continually expands and contracts, pushing adjacent sections around all the time.  Perhaps the data coordinate section could be put on a seperate side from everything else (on the left, and everything else on the right).  Putting the data coordinate section on the left would have the additional benefit of the curve name not moving around when in data mode.

(this is wishlist only, probably best left until after 0.99)

Comment 1 George Staikos 2004-08-11 21:57:16 UTC

Fixed in CVS, however I think we may need something even more complicated than the statusbar progress bar.  We have such a design already and it should be considered as a replacement.  Also there is a problem with reentering the event loop now.

Comment 2 Netterfield 2004-08-11 22:04:22 UTC

will what we have now impact stability of 0.99?

cbn

On August 11, 2004 03:57 pm, George Staikos wrote:
> ------- You are receiving this mail because: -------
> You are the assignee for the bug, or are watching the assignee.
>
> http://bugs.kde.org/show_bug.cgi?id=86993
> staikos kde org changed:
>
>            What    |Removed                     |Added
> ---------------------------------------------------------------------------
>- Status|NEW                         |RESOLVED
>          Resolution|                            |FIXED
>
>
>
> ------- Additional Comments From staikos kde org  2004-08-11 21:57 -------
> Fixed in CVS, however I think we may need something even more complicated
> than the statusbar progress bar.  We have such a design already and it
> should be considered as a replacement.  Also there is a problem with
> reentering the event loop now.
> _______________________________________________
> Kst mailing list
> Kst@kde.org
> https://mail.kde.org/mailman/listinfo/kst

Comment 3 George Staikos 2004-08-11 22:33:19 UTC

On Wednesday 11 August 2004 16:07, Barth Netterfield wrote:
> will what we have now impact stability of 0.99?

  I'm not entirely sure.  We did have problems with this before where events 
would come through that we weren't prepared to handle.  I've been tracing 
through all the code that uses it and it doesn't seem like any locking is 
used at this time besides the global list lock for vectors.  That's a bug in 
and of itself that needs to be fixed.  Meanwhile once these locks are in 
place, we need to make sure that all locks are released around areas that 
call out to the progress bar, then reobtained immediately after (and hope 
that we don't deadlock then, which I think is a safe bet).  One of my big 
concerns is for realtime updates.  What happens if the  Xvector changes while 
the data is being loaded?  We can't hold the read lock, so we would have to 
keep it outside the global list.  Then we have curves pointing to vectors not 
in the global list, so we have to keep the curves out of the global list (etc 
etc).  The code in the data wizard is not prepared to deal with this.  If we 
hold the read lock all the way through, we can definitely deadlock.

   This is just one possible conceptual problem with processing events.  I did 
spend quite some time trying to produce a deadlock or crash and haven't been 
able to yet, but that doesn't mean we aren't introducing one by any means.

   All in all, I'm worried about this, which is why I didn't have this fixed a 
long time ago.