Version: 1.0.0_devel (using KDE 3.3.0, compiled sources) Compiler: gcc version 3.3.2 OS: SunOS (sun4u) release 5.8 When exporting plots for other people (read: who don't have kst and don't know what you're really looking at), it is often useful or even necessary to add comments, put a frame or circle around interesting areas and use text and arrows to point at some particularly important areas. I feel kst should really have more than just text labels for 1.0, even though I realize this may be difficult to implement. Sure enough, one option is to add these comments in another application like karbon or kpresenter, but experience shows it is better to do it in the original tool. I looked at koloourpaint, karbon and kpresenter, and found kpresenter to have the best set of drawing functions (arrows, text, basic shapes). Please tell me it can be reused :-) That would really be great !
Each line/shape should be configurable in terms of the absolute plot position or the x,y values of the axis. The same positioning options should also be extended to labels, as they will an integral part of annotation. The line, shape, and label should be drawn above all images and curves.
*** Bug 96246 has been marked as a duplicate of this bug. ***
I've been mucking around with this a bit and come to the following conclusions: Annotating a plot in fixed plot co-ordinates is likely a waste of time, as there are many programs that are far more capable at this than Kst will ever be. Annotating a plot in fixed data co-ordinates has the following issues: * the updating would have to be paused while annotating else whatever you're adding is liable to vanish from the plot while you're adding it (ditto for editing an already existing object) * data markers already provide very similar functionality with the added attraction that they are simple to use and can be quickly jumped to Are there any compelling reasons to address this bug?
This is driven by user demand and is a focus for the 1.2.0 release. The bigger issue is separating plot annotations (labels, graphics) from view/layout annotations (view labels, graphics). We need a clear focus on how we want this implemented and how it will integrate with scripting, user modes, etc. I purposely left out script bindings in this area (which could even be structured without the backing) until we have a clear design document on it.
On May 28, 2005 01:16 am, Andrew Walker wrote: > Annotating a plot in fixed plot co-ordinates is likely a waste of time, as > there are many programs that are far more capable at this than Kst will > ever be. In my opinion, we actually are pretty close to 'good enough' for a large number of types of plots. It seems that if we can go the last little way, we can keep users from having to open up their data again in a different app in order to make a publication quality version of exactly the same plot as they have already made in kst. This would be a good thing. The astro standard has been sm, and we are pretty close to sm's capabilities. > Annotating a plot in fixed data co-ordinates has the following issues: > * the updating would have to be paused while annotating else whatever > you're adding is liable to vanish from the plot while you're adding it > (ditto for editing an already existing object) * data markers already > provide very similar functionality with the added attraction that they are > simple to use and can be quickly jumped to I agree that the annotations should be in plot, not data space.
SVN commit 420389 by arwalker: Add icons for graphics objects. CCMAIL: 91675@bugs.kde.org AM kst_gfx_ellipse.png AM kst_gfx_line.png AM kst_gfx_polygon.png AM kst_gfx_polyline.png AM kst_gfx_rectangle.png AM kst_gfx_rounded_rectangle.png AM kst_graphics.png ** trunk/extragear/graphics/kst/kst/kst_gfx_ellipse.png #property changes Name: svn:mime-type + application/octet-stream ** trunk/extragear/graphics/kst/kst/kst_gfx_line.png #property changes Name: svn:mime-type + application/octet-stream ** trunk/extragear/graphics/kst/kst/kst_gfx_polygon.png #property changes Name: svn:mime-type + application/octet-stream ** trunk/extragear/graphics/kst/kst/kst_gfx_polyline.png #property changes Name: svn:mime-type + application/octet-stream ** trunk/extragear/graphics/kst/kst/kst_gfx_rectangle.png #property changes Name: svn:mime-type + application/octet-stream ** trunk/extragear/graphics/kst/kst/kst_gfx_rounded_rectangle.png #property changes Name: svn:mime-type + application/octet-stream ** trunk/extragear/graphics/kst/kst/kst_graphics.png #property changes Name: svn:mime-type + application/octet-stream
Can we discuss and get a design plan for this feature? There are specific requirements by various groups. I have a list of some objects that are needed and how they will look from the script side in the script bindings document.
It would have been helpful if this had already been documented. If you have requirements from either the script side or the UI side then please attach them to the bug report. At present I'm envisioning the graphic objects working in a manner similar to labels, with a new graphics mode (similar to label mode) and a new toolbar for selecting the desired graphic object. The user will be able to move individual points within an object, or the entire object (just as with labels). Drag and drop would also be supported as it is for labels. -----Original Message----- From: owner@bugs.kde.org [mailto:owner@bugs.kde.org]On Behalf Of George Staikos Sent: Wednesday, June 01, 2005 2:41 AM To: arwalker@sumusltd.com Subject: [Bug 91675] more objects to draw on canvas for adding comments ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. You are on the CC list for the bug, or are watching someone who is. http://bugs.kde.org/show_bug.cgi?id=91675 staikos kde org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kst kde org ------- Additional Comments From staikos kde org 2005-06-01 11:40 ------- Can we discuss and get a design plan for this feature? There are specific requirements by various groups. I have a list of some objects that are needed and how they will look from the script side in the script bindings document.
On Wednesday 01 June 2005 12:22, Andrew Walker wrote: > It would have been helpful if this had already been documented. I agree. This feature is still under development conceptually though - it's not time to code yet. I intended to start coding it once I had fully documented all the requirements. Right now I'm still developing the users of this, so it's quite premature. > If you have requirements from either the script side or the > UI side then please attach them to the bug report. I'm developing the scripting side in kst/kst/extensions/js right now. It's still in flux. > At present > I'm envisioning the graphic objects working in a manner similar to > labels, with a new graphics mode (similar to label mode) and > a new toolbar for selecting the desired graphic object. The user will > be able to move individual points within an object, or the entire object > (just as with labels). Drag and drop would also be supported as it is > for labels. That may be useful, but it's not the primary goal from my point of view yet. This bug report, at least from HFI perspective, from scripting perspective, and my perspective, is to add new ViewObjects. These work in layout mode and were the original basis for designing the view object infrastructure. We already have the manipulation (DnD etc) setup for it, and it is explicitly wanted outside of plot-space. Since we can compose objects, I personally think that it is even sufficient to replace our current labels assuming that the user interface issue can be solved. (Labels are "convenient" but inconsistent.) In addition, anything other than View Objects as designed now would be completely inconsistent from KstScript, and well, it would throw away a month of work. There has also been a request from HFI to add some annotation support on a curve level, which is to say, inside the contents of a plot, or in plot-axis space. This is something new and different and needs plenty of careful thinking and discussion before implementation. It might make sense to only allow these sorts of things programmatically to start. On a more global level, once KstScript is "done", I think we should consider reducing iterative UI items in favor of a cleaner interface and promoting the command-line as an alternative mechanism. The UI is starting to get very complex.
I think that the changes implemented supply the functionality wanted by Barth. At present the user needs to hit the 'e' key when a graphic object is selected to edit it (to change color, style, and width) and the 'i'/'d' to insert/delete a point to/from a polyline or polygon. Should we add a mouse/menu operation for these as well?
This gives us most of the capability that we will need I think. But there are some UI issues that should be addressed still (!) From a UI point of view, -Text should become a sub-mode of line drawing. -The selection hints from Text mode should apply to graphics objects as well. So: cursor from +/| to -> when an object is selected, and clicking rather than dragging should pop up the object edit dialog. -lines should get a move target their centers, to supplement the end points. -The edit points for circles are.... non-intuitive. Perhaps anywhere on the circle? -I can't figgure out poly line and polygon modes. But they are not very important and could be deleted. -The graphics Editor icon should become a dropdown menu icon. The other (less desirable) option is to just hide the graphics toolbar if the graphics editor is not selected. -The edit box entries should be sticky.
SVN commit 423798 by arwalker: BUG:91675 Make some modifications based on suggestions by Barth. Also move position of tied zoom in menu to reflect icon position. M +10 -10 kst.cpp M +2 -2 kst.h M +42 -44 kst2dplot.cpp M +3 -2 kst2dplot.h M +3 -3 kstui.rc
Didn't mean to mark as fixed.
Comments suggested by Barth have been implemented.
Nice improvements... but: On June 13, 2005 11:53 pm, Andrew Walker wrote: > ------- Comments suggested by Barth have been implemented. Pending comments from my previous email: -The graphics toolbar should not be visible unless graphics mode is selected. This can either be done via a pull down toolbar (best), or by just hiding the graphics tool bar if graphics mode is not selected. -I can't make sense of poly-line and polygon mode. Either make them comprehensable or just delete them. -add arrows heads for lines in the dialog box cbn
For polygon and polyline mode use just as you would for creating a line, but instead of releasing the mouse button hit the 'i' button. A new point is added every time the 'i' button is hit. When you're finished drawing release the mouse button. Points can be deleted by selecting them and hitting 'd', or added by pressing the left mouse button and hitting 'i' - then continue to insert points as when creating the object. -----Original Message----- From: netterfield@astro.utoronto.ca [mailto:netterfield@astro.utoronto.ca] Sent: Tuesday, June 14, 2005 4:59 AM To: kst@kde.org Subject: [Kst] [Bug 91675] more objects to draw on canvas for addingcomments ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. http://bugs.kde.org/show_bug.cgi?id=91675 ------- Additional Comments From netterfield astro utoronto ca 2005-06-14 13:59 ------- Nice improvements... but: On June 13, 2005 11:53 pm, Andrew Walker wrote: > ------- Comments suggested by Barth have been implemented. Pending comments from my previous email: -The graphics toolbar should not be visible unless graphics mode is selected. This can either be done via a pull down toolbar (best), or by just hiding the graphics tool bar if graphics mode is not selected. -I can't make sense of poly-line and polygon mode. Either make them comprehensable or just delete them. -add arrows heads for lines in the dialog box cbn _______________________________________________ Kst mailing list Kst@kde.org https://mail.kde.org/mailman/listinfo/kst
Hmmm.... How can we make it so that a user can figure this out (besides reverting to the documentation)? (ie, this is pretty non-intuitive and non standard) I think the standard approach is to click (or drag/release) at each point. A drag line to the previous point should always be shown to indicate you are still in the mode. To exit the shape, double click, hit <esc> or enter a different mode when you are done. At that point, for polylines, it just ends. For polygons, it inserts the last line. cbn On June 14, 2005 07:25 pm, Andrew Walker wrote: [bugs.kde.org quoted mail]