TSimpleGraph Issues (and wish list)

kokkoras · Last edited by kokkoras on 08/08/06 02:15; edited 4 times in total

Well, finally I found some time to play with TSG 2.61. A list of "issues" follows with some suggestions/requests. I will keep on adding material to this post to have a to-do list to consider in the ...unknown future.

1. The node markers should be drawn in fixed size. The current size (at 100% zoom) is ok. The reason is that at high zoom values the markers occupy too much space on the canvas (not to mention that it is possible to be taken for nodes).
update: tested - impossible to produce consistent appearence

2. The double line used to draw objects when dragging them, makes exact positioning difficult, particularly when snap_to_grid is off. The old way was more precise.

3. Node creation by dragging on the canvas is problematic. First, it forces a NW to SE movement. If I try to violate this (say, by moving SE to NW beyond the top left corner of the node) the mouse moves but the node stays still. As a result the mouse "loses" the corner of the node.

4. The grid should not be drawn when GridSize*Zoom%<5 no matter what the showGrid flag is set to.
Update: Done! add "if (Zoom/100)*GridSize > 5 then" in TSimpleGraph.Paint, after "try".

5. A link "modification mode" will make life easier regarding the alt, ctrl, shift and mouse handling. We get into that mode somehow and then follow the current handling.

6. Some times the zoom behaviour is odd. Part of it is because of the fixed (0,0) of the canvas. This is understandable.
Update 1: We should consider the possibility of having (0,0) at the center of the canvas (like in ACAD), as long as the calculations do not become a nightmare.
Update 2: Zoom behaviour suggestion: Letting aside the effects caused by the (0,0) point, I will describe a zoom behaviour. The user somehow (toolbar button or Ctrl+Space comes into mind) gets into zoom mode, that is, SG accepts only zoom commands. In the following, I use the FixedPoint term to refer to the point of the canvas that remains still after zooming.

a) keypad + or -
increase or decrease zoom by a factor of 2
Fixed Point: center of canvas

b) mouse click or Shift + mouse click
increase or decrease zoom by a factor of 2
Fixed Point: pointer position

c) selection rect with mouse
WR:= CanvasWidth/RectWidth
HR:= CanvasHeight/RectHeight
Zoom:= Round(Zoom * min(Wr,HR))
Fixed Point: not applicable

d) wheel mouse zoom
increase or decrease zoom by 10 units (or better by WheelZoomStep units - see suggestion 7)
Fixed Point: pointer position

e) useful zoom states
1) Zoom 100%: directly set,
Fixed Point: center of canvas
2) Zoom Selection: like (c) based on
the bounds rect of the selected
3) zoom all: like (c) based on the
bounds rect of all objects

So, it seems that the TGraphZoomOrigin is not required. Also the scroll commands inside the ChangeZoom function should be reconsidered because they produce flicker.

Kambiz · Posted: 04/08/06 12:28 Post subject:

I'll consider these issues for the next release.

Thank you.

kokkoras · Posted: 04/08/06 13:04 Post subject:

Kambiz · Posted: 04/08/06 13:12 Post subject:

Thank you.

Changes will be available during run-time, but at design-time the old code will be active.

kokkoras · Posted: 04/08/06 13:28 Post subject:

Kambiz · Posted: 04/08/06 13:55 Post subject:

kokkoras · Posted: 08/08/06 02:03 Post subject:

7. I think the zoomStep property should be brought back. Considering my other suggestions regarding zoom behaviour, all zoom operations have a fixed zoom factor (x2 for click zoom, x1/2 for Shift+click zoom, calculated factor for selection window zoom, etc). The only zoom that, IMHO, requires a zoom step is the wheelMouse zoom. So, I suggest to bring it back and name it fWheelZoomStep

Question to Kambiz: Is the behaviour of TGraphObjectList class any similar to Borland's TList? Why don't you use TList? Does it have to do with persistency?

kokkoras · Posted: 08/08/06 02:54 Post subject:

8. Link labels require some special treatment. TSG will be used to visualize some reality and not just for drawing boxes and the like. So, nodes represent something and links, if they are not wires, have some meaning. So, having a label is fine. Having the ability to hide some labels is great. BUT, in my app, I have a situation with some link labels displayed and some not. Now, I want to temporarily hide all link labels and after some time bring them back as they were (some on, some off).
Bottom Line: A global DrawLinkLabels flag is required (TSG property). This will be checked prior to drawing the text of the link labels (TGraphLink.DrawText procedure). It will be like this:

Kambiz · Posted: 11/08/06 15:57 Post subject:

The notification event of TList was not as I needed, so I introduced TGraphObjectList.

Regardless of caption options, TextRegion is always caldulated.

kokkoras · Posted: 17/08/06 21:59 Post subject:

9. The Margin property of TGraphNode should be renamed to Padding.

10. It would be very convenient to have TSG reporting the common value of some property of the selected nodes (or links). This will be very helpful for building GUIs. I am curently building a TNodeProperties form to allow the user to change some properties. When only one node is selected the form works very much like the one in the demo. BUT when many nodes are selected I check (in form's onShow) to see if they all share a common value for, say, the Left property. If yes, I display this common value in some proper control (a spinEdit for example) otherwishe I leave the control's value empty.

UPDATE
We need a function like:

kokkoras · Posted: 19/08/06 12:00 Post subject:

11. In TGraphNode.Create, some properties are set again although they have default values in their declaration. For example, Margin is set to 8 but in TGraphNode.Create is set again to 8. The problem is that someone wanting different default values should change both. Same holds for Alignment, Layout, etc.

edit: It seems the default value does not work. Commenting out the margin set in the constructor, the new nodes have their margin set to 1 instead of my default 4. What's wrong here?

12. Wouldn't be better to use HorAlignment and VerAlignment istead of Alignment and Layout? "Layout" is a quite more general term for positioning of things and includes both Hor and Ver positioning. (ok, it's not big deal)

Kambiz · Posted: 19/08/06 16:50 Post subject:

11. The default value of a property, tells to Delphi do not store value in the resource. The actual value, is the value assigned in the constructor.

12. I thought maybe it's more convenient for users to use the terminology used in TLabel.

kokkoras · Posted: 19/08/06 20:40 Post subject:

Kambiz · Posted: 21/08/06 09:10 Post subject:

This is description from Delphi's help:

kokkoras · Posted: 24/08/06 20:49 Post subject:

Some update to topic 10, earlier in the thread.

Also, some issues regarding the "pan" mode (discussed also in the past):

13. After getting into "pan" mode only pan should be allowed. Pressing ESC should exiting "pan" mode. Since this is not very efficient I would like a quick way like holding down Ctrl+Space. An long as these are pressed, pan mode is active. Releasing the keys we are leaving pan mode.