TSimpleGraph Issues (and wish list)

[kokkoras]

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]

I'll consider these issues for the next release.

Thank you.

[kokkoras]

I'll consider these issues for the next release.
Thank you.

Greetings! Nice to hear from you and see that you are around.

Question: Is it possible to alter the TSG code and use at the same time the component without having re-installing it?

Regards!

[Kambiz]

Thank you.

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

[kokkoras]

Thank you.

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

So, you mean that as long as I do not alter any code that affects what is visible in the object inspector, I can do it. Right?

[Kambiz]

Yes!

[kokkoras]

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]

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:

Code: Select all

 if Owner.ShowLinkLabels = true then    //new line
   if (TextRegion <> 0) then ....  //existing code

Question to Kambiz: Does this TextRegion condition includes checking of the individual flag for label drawing of each link? (goShowCaption in Options)

[Kambiz]

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

Regardless of caption options, TextRegion is always caldulated.

[kokkoras]

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:

Code: Select all

function GetCommonValueOfSelectedObjects(ObjectClass:TGraphObjectClass, property:string): Variant;

Candidate properties are: Left, Top, Width, Height, Pen related, Brush related, Font related, etc, etc. The value should be declared as Variant since the type depends on the property. Only the Font needs special treatment because it's a pointer (not supported by Variants). The ObjectType would be either TGraphNodes or TGraphLinks or nil (=all).

The code is simple but is quite lengthy if we decide to cover many parametrs. In my code I am dealing with 25 (!) of them but I am getting too much in detail (typeface, font size, fsBold/Italic/Underline, font Color, Pen color/line/weight, Brush color/style, etc, etc).

Similarly a SetCommonValueOfSelectedObjects might be also useful.

Of course someone could claim that this is an end-user issue and does not belong to the library.

[kokkoras]

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]

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]

... do not store value in the resource...

Could you please explain this. I think I am missing something.

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

Well, I had the same problem an hour ago for some GUI labels:I had to choose between "Brush Color" and "Fill Color". The former is OK for programmers but the later is more understandable for the average user. Many developers have in mind a user who is familiar with M$ apps like Word and Excel. Of course, the library is about programming but having consistency in code and GUI terminology is convenient. As I said before, it's not big deal.

[Kambiz]

This is description from Delphi's help:

When you declare a property, you can specify a default value for it. Delphi uses the default value to determine whether to store the property in a form file. If you do not specify a default value for a property, Delphi always stores the property.

To specify a default value for a property, append the default directive to the property’s declaration (or redeclaration), followed by the default value. For example,

property Cool Boolean read GetCool write SetCool default True;

Note: Declaring a default value does not set the property to that value. The component’s constructor method should initialize property values when appropriate. However, since objects always initialize their fields to 0, it is not strictly necessary for the constructor to set integer properties to 0, string properties to null, or Boolean properties to False.

[kokkoras]

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.