Bug 126758 - Easy way to set plot range as function of ctime
Summary: Easy way to set plot range as function of ctime
Status: REPORTED
Alias: None
Product: kst
Classification: Applications
Component: plotting (show other bugs)
Version: 1.10.0
Platform: Ubuntu Linux
: NOR wishlist
Target Milestone: ---
Assignee: kst
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-05-04 23:03 UTC by Dirk Eddelbuettel
Modified: 2010-08-14 14:13 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dirk Eddelbuettel 2006-05-04 23:03:05 UTC
Version:            (using KDE KDE 3.4.3)
Installed from:    Ubuntu Packages

Using and displaying ctime is a very nice feature. A further improvement would be to always
shows a fixed 'time slice' of data -- which may or may not be the same as a fixed number of
observations.  Displaying 'N' observations from the end is good, but as bursty data may have
very different arrival frequencies, it would be nice to also be able to select 'last M' time 
units, be that hours, minutes, seconds, ...    As added candy one could envision min() and
max() operators ('show 5000 frames, or 30 minutes, whichever is less more').  

Obviously a pure wishlist feature request. Feel free to nuke it if it seen to have little merit.

Dirk
Comment 1 Andrew Walker 2006-05-08 19:23:40 UTC
If you bring up the Plot Dialog and click on the Range tab you should then be able to check the Expression radio button in the "X Axis" group. Within the corresponding From and To edit fields you can then enter an expression to define the axis range. The expression syntax is fairly extensive and should be able to do what you are after.


Comment 2 Dirk Eddelbuettel 2006-05-08 20:16:05 UTC
On 8 May 2006 at 17:23, Andrew Walker wrote:
| ------- You are receiving this mail because: -------
| You reported the bug, or are watching the reporter.
|          
| http://bugs.kde.org/show_bug.cgi?id=126758         
| 
| 
| 
| 
| ------- Additional Comments From arwalker sumusltd com  2006-05-08 19:23 -------
| If you bring up the Plot Dialog and click on the Range tab you should then be able to check the Expression radio button in the "X Axis" group. Within the corresponding From and To edit fields you can then enter an expression to define the axis range. The expression syntax is fairly extensive and should be able to do what you are after.

Indeed -- as I call the ctime column 'ctime', so it is as simple as picking
>From and To via


	[ctime-max]
	[ctime-max] - 1200

and now I have a fixed 20 minute window.  So thanks for he follow-up.

Thanks, Dirk
Comment 3 Andrew Walker 2006-05-08 20:23:29 UTC
The desired functionality is already present.
Comment 4 Dirk Eddelbuettel 2006-05-08 21:00:46 UTC
On 8 May 2006 at 18:23, Andrew Walker wrote:
| ------- You are receiving this mail because: -------
| You reported the bug, or are watching the reporter.
|          
| http://bugs.kde.org/show_bug.cgi?id=126758         
| arwalker sumusltd com changed:
| 
|            What    |Removed                     |Added
| ----------------------------------------------------------------------------
|              Status|UNCONFIRMED                 |RESOLVED
|          Resolution|                            |INVALID
| 
| 
| 
| ------- Additional Comments From arwalker sumusltd com  2006-05-08 20:23 -------
| The desired functionality is already present.

In a somewhat narrow sense, yes.  

However, my bug report was a wishlist request for setting ctime-based x-axis
ranges as an alternative to the 'pure count' range.  That would suggest
bringing these menus which may not be easy. I'd argue that this wishlist bug
about access to such settings is still open.

Also, I am now running with a mix of 'count nb of samples from end' and the
x-axis range expression, and there seems to be an auto scaling bug in one of
the barcharts.  It looks like height is determined over more data than is
plotted. 

But if you're very eager to keep the number of open bugs down, I won't
nitpick. 

Thanks, Dirk
Comment 5 George Staikos 2006-05-09 13:47:58 UTC
Not quite
Comment 6 Nicolas Brisset 2006-05-10 11:37:01 UTC
> Also, I am now running with a mix of 'count nb of samples 
> from end' and the x-axis range expression, and there seems to 
> be an auto scaling bug in one of the barcharts.  It looks 
> like height is determined over more data than is plotted. 

That reminds me of something... Indeed, the default is to compute Y
autosale ranges for the whole data available (so that the ranges don't
jump continuously when scrolling through data), but I asked some time
ago for a "local Y" zoom mode, and it has been implemented. Maybe you
could use that to adjust the Y range "better" ?
Comment 7 Netterfield 2006-06-16 23:36:45 UTC
Rough implementation suggestion:
-datasources need to export a TIME field.  The data sources need to determine how to do this, though the default, added to the parent class, might be to allow the user to define ( in the datasource's configure dialog) a field, and offset, and a slope to use to generate time.

-RVectors need to learn how to store their starting and offsets in time, rather than frame.  They will use the TIME field to interpret them.  It has to happen in RVector, in case sample rates change or there are data dropouts, etc.

-The vector range widget and the command line need to learn to parse a variety of time formats.

-This can then simplify what is being done with piolib's time.

I think that the difference between this and the current implimentation for PIOlib is that the RVectors will now take care of time interpolation, etc, not the widgets.

I think that this gives all of the desired behavior.

Comment 8 Nicolas Brisset 2006-06-19 14:59:49 UTC
While I strongly support being able to set plot range as a function of time, I think it is wrong to impose to datasources to provide a TIME field, especially if that requires the users to configure extra things in the datasource config dialogs. The reason is related with the discussion aroung bug #123699, and asynchronous data (not to mention localization !): in the general case, there may be more than one time, or no time at all (after all, you could be using kst to plot (X,Y) coordinates of a moving object !).
Of the 3 points above, the last 3 seem OK, but we could probably find another way to implement 1) like a general-case plugin to generate a vector in ctime format, or something else...
Comment 9 Netterfield 2006-06-19 17:36:32 UTC
Clarification:
If a data source doesn't provide TIME then there will be no time, and time based inputs won't work.  But the base class will provide a default configuration to allow a scaled version of any field to be called TIME - eg, for ascii files. 
If there are multiple times, then the user has to pick one.
Comment 10 Peter Kümmel 2010-08-14 14:13:47 UTC
Could be still open in Kst 1.