Bug 91675

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]