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
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.
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
The desired functionality is already present.
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
Not quite
> 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" ?
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.
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...
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.
Could be still open in Kst 1.