Hi,

I have now tried for more than 30 minutes clicking around in the form editor trying to find out how the TSplitter is supposed to be used but it simply wont work (for me). Or is it simply not completely implemented yet?

I have tried giving it sub-panels but it doesn't seem to want anything contained into it. I have tried to change its siblings with the anchor editor but it doesn't seem to allow me changing the anchors either. It wont allow me to do anything with it and it is always glued to the left border and won't move a single millimeter.

How is the splitter supposed to be used? Can It be configured in the form editor at all? And if so, what steps are needed to configure a vertical splitter between two controls in the form editor?

Bernd Kreuss wrote

How is the splitter supposed to be used?

Found it: If I make any change to the property ResizeAnchor (switch it to something else and then switch it back to what it was) the anchor editor is no longer locked and I can remove the left anchor and move it to where I need it. Is this a bug? It should not be locked at all from the beginning on, a splitter that is anchored to the left side of the form and cannot be moved away from this position is pretty useless.

Bernd Kreuss wrote

How is the splitter supposed to be used? Can It be configured in the form editor at all? And if so, what steps are needed to configure a vertical splitter between two controls in the form editor?

1. set Align := alLeft for the first control,
2. set Align := alLeft for the splitter and move it after the first control
3. set Align := alClient for the second control

Best regards,
Paul Ishenin.

wow... that doesn't seem "intuitive" at all :?

Why not ?

I've been doing it for 12 years like this, never gave it a second thought. It's perfectly logical and no different from learning how to use a combobox.

Michael.

That's exactly how splitters are used in Delphi.

DoDi

Paul Ishenin wrote

1. set Align := alLeft for the first control, 2. set Align := alLeft for the splitter and move it after the first control 3. set Align := alClient for the second control

Two questions:

a) How can I then make the splitter always be in a fixed relative position to the window width? If I have dragged it to say 2/3 of the size from the left and then resize the window I want it to stay at 2/3 of the new size and not at the same fixed pixel distance from the left that it had before resizing?

b) Why does the following work and are there any objections against making the following the recommended procedure:

1. Set Align of the splitter to alNone (should be default)
2. Anchor the splitter only on top and bottom and move it freely
2. Anchor the two controls at the splitter

I have never used Delphi and I find steps b.2 and b.3 a hundred times more intuitive, the only problem is step b.1 which is not obvious.

Intuitively[1] the user tries to position the Splitter like any other control and use the anchor editor like with any other control. The funny thing is that it even seems to be able to work exactly the way I intuitively tried to do it (after finding out how to unblock the anchor editor). Is this only a coincidence? I tested on GTK and Windows and it works like a charm.

IMHO the default should be alNone so the Splitter can be immediately used like described above or the anchor editor should *tell* the user why it refuses to change the anchoring, either a message box should pop up telling the user exactly why a certain anchor side is blocked when he tries to uncheck the check box or it should be grayed out and a hint or a label should tell the reason.

______
[1] I am writing this from the perspective of somebody who's intuition is not contaminated by decades of Delphi usage. As long as I have not become too used to some of the few counterintuitive oddities to complain about them I will complain. You could utilize me as a living detector for these hidden pitfalls. The form editor is already really great and intuitive and almost works like one would expect it, the above problem is one of the few exceptions where usability suddenly drops to zero (or even below) and the user has a really bad experience.

Hans-Peter Diettrich wrote

> wow... that doesn't seem "intuitive" at all :? That's exactly how splitters are used in Delphi.

This doesn't make it a single bit more intuitive, you just don't notice it anymore. This is a common problem in software development.

I am a relatively new Lazarus user, I am completely unbiased and I am not contaminated with Delphi knowledge and I have some experience in rigorously testing user interfaces for ergonomics. The splitter usage and behavior is a textbook example of how it should *not* be done, at least not without the UI clearly communicating to the user *why* it is suddenly deviating from *anything* that could be considered "expected behavior" in such an extreme way.

This is not meant as a rant, this is meant as useful unbiased user feedback.

Bernd

Bernd Kreuss wrote

UI clearly communicating to the user

Here is an example: There are hints in the form editor that show amongst other information the positioning coordinates of a control in the form.

Position: 123, 456
Size: 23 x 42

When a control is set to anything else than alNone then some or all of these coordinates become meaningless. This should be communicated to the user. The movable coordinates that are now not longer movable but calculated should be replaced by what is *now* determining their values. These settings have now become the coordinates, not the calculated values, they have become meaningless.

  Position: Not movable (Align := alLeft)
  Size: Height not sizable (42 x client height)

or

  Position: Not movable (Align := alClient)
  Size: Not sizable (client width x client height)

Bernd

It is a valid point. The Object Inspector could give better feedback, without changing the actual layout logic.

Could you please make a feature request issue for it.

Juha

There is no such option. You have to do that yourself. See anchordocking for an example.

TSplitter can also work with anchors. Delphi's VCL does not have this feature.

I have never used Delphi and I find steps b.2 and b.3 a hundred times more intuitive, the only problem is step b.1 which is not obvious.

Several controls set the Align property by default. For example TStatusBar, TSplitter, TButtonPanel, TPage.
TSplitter uses alLeft by default for Delphi compatibility.

Maybe you just didn't know the Align property.

Many people find Align more intuitive than Anchors. Especially those coming from Delphi or other frameworks.

Mattias

Mattias Gaertner wrote

Several controls set the Align property by default. For example TStatusBar, TSplitter, TButtonPanel, TPage.

These are intuitively supposed to be positioned where the align property suggests and not moved to somewhere into the middle of a form

TSplitter uses alLeft by default for Delphi compatibility.

The splitter is *expected* to be positioned freely in the *middle* of the form *between* other controls. This is intuitive. Gluing it unmovable to one of the form borders by default until the user finds out how to make it movable (or how the alternative strange old Delphi usage is supposed to work) is not intuitve, IMHO.

Many people find Align more intuitive than Anchors. Especially those coming from Delphi or other frameworks.

You are confusing learned behavior with intuition and don't recognize it anymore. This is a common problem in software development. What the developer finds "intuitive" is in reality only what he knows how to do because he is trained to do it.

To find out what is intuitive and what is counterintuitive there is *no* way around *listening* to what unconditioned and unbiased users tell you about *their* experience and by observing *their* usage patterns when they are using it for the first time!

Bernd

Bernd-

There are often different interpretations of "intuitive" so it is far from the universal, objective attribute you seem to view it as.

The original designers of TSplitter found it more useful, and possibly more intuitive from the beginning, to have splitters always aligned to something else. Maybe that's not how you would have done it but that's the way it started and always has been and I think its too late to change now.

Maybe you can invent something called a TSpacer and have it start out aligned to nothing and have other controls then align to it rather than the other way around. If you can work around the inherent problems that produces (that you don't seem to have discovered yet) then I may switch to use TSpacers.

Richard Saunders wrote

that's the way it started and always has been and I think its too late to change now.

Interestingly the TSplitter actually *has* already the ability to be used with anchor docking in the way I (and many others) would have expected it from the beginning on. The only thing that is wrong in my eyes is the default still being set to the old delphi behavior instead of using the new (and more consistent and powerful) anchor docking behavior.

I don't see how changing the default for *new* forms would impact the compatibility for converted *old* delphi forms. These would still use the alignment property as it was set in the delphi form but when designing a new form it would be better to uniquely prefer the "visually positioning and anchoring" paradigm like all the other controls too.

Bernd

Well one target is Delphi compatibility (not at every price, but probably at this price).

That means:
a) the ability to set it via align
b) if any other ability is given, possibly the means to auto-adjust the align according to (derive the align from) the new method. (otherwise people now used to the align, will be confused, if the stumble upon splitters not using it)

Anchors to me are same as (if not even more) confusing as the align method. And I do remember 10 or 20 years back having taken some time to figure it out (as I have an aversion against reading docs; so strictly: my fault)

Anchors are more complex than (and can be seen as an extension of) align. If the simple align is not intuitive, the complex anchors can never be. (even if to a few people including you, they would have been, simply by random chance of the order in which you discovered things)

IMHO the most intuitive way (but it would break delphi compatibility, so it will not happen):
- remove align and anchor properties completly; and have a property for the left/right (or above/below) controls, that should be affected

Alternatively (I thing that once existed as TPairSplitter) a splitter, that is like a big panel, but with 2 child areas divided by the build in splitter. that way, you just drop the controls into the splitters child area.

Then again, there is documentation too, and there a bigger problems than that.

Martin

I didn't want to push any priority, I simply wanted to write it before I forget it again. Probably some clearly written and easily accessible documentation could prevented this in the future and I am glad that I can use the anchors and free positioning even with splitters and am not forced to use the Align property which would be diametrically opposing the visual GUI design paradigm.

Martin wrote

Anchors to me are same as (if not even more) confusing as the align method.

Can you remember what exactly it was that confused you?

I have seen a lot of approaches to GUI design and GUI designers with other toolkits, they all use either a set of sizers of varying complexity for certain purposes (box, grid, gridbag, etc) and you are supposed to study and learn all their advantages and disadvantages and detailed behavior and experiment a lot before you are able to make even the simplest hello world form with only a label and two buttons and usually most of the time you are more effective when doing it manually because they all inherently resist the usage of a visual GUI designer, most GUi designers that let you design with these sizers literally suck comets through drinking straws.

And then there is the gigantic do-it-all-sizer-that-fits-all-needs approach of for example netbeans that lets you easily design a form with a real visual designer that really deserves its name but the code it produces looks extremely complicated.

I don't know who exactly invented the way the form designer and the sizing with the anchors works like it is now in Lazarus but I must say that its invention was truly a masterstroke. I can hardly imagine any way to achieve more flexibility with less complexity. I don't see any can be placed and sized freely and each
side can additionally be anchored to something or left alone and thats already all there is to it. How can this be perceived as more complex than the usual two dozen different nested sizers hell that is used in many other toolkits?

I personally find the form designer and the anchoring is one of the best inventions since the invention of sliced bread.

Bernd

Bernd Kreuss wrote

On 21.08.2010 18:56, Martin wrote > Anchors to me are same as (if not even more) confusing as the align method. Can you remember what exactly it was that confused you?

I didn't mean to say I was confused. I meant to say that if align is confusing (in the context of being used for splitters), then anchors surely must be more confusing.

And of course the above statement, is not true for each and every individual (as from your statement, it doesn't apply to you at all). The above statement simply is, that I would expect that people who have *never* used any form of GUI development:
- 100 to be presented with a splitter that works with align
- 100 to be presented with a splitter that works with anchors The one with align would find it easier (since for the anchors, you must learn a lot about all the different kind of anchors; while align is a single value)

That may change, for experienced GUI developers, who already know anchors very well. (But then the overall step of learning a splitter is smaller too). In that case I might expect equal experiences from both groups.

Anyway, as I said my expectations, based on no particular background, other than my personal common sense. It might be wrong.

About my past experience: When I looked at a TSplitter the very first time in my life, it simply took a while till I found how the splitter works. Yet that can be said for a huge amount of components: Either read the docs (I didn't much) or play with each and every of the many properties.

Right, but it is as splitters (of that kind) work. The regular layout management for a container control allows for any number of fixed size components (of equal horizontal or vertical alignment), plus one auto-sized component (alClient). A splitter allows to change the extent (width or height) of its left (or top) neighbour, and adjusts the extent of the alClient component accordingly.

Lazarus allows for more irregular layouts, see AnchorDocking.

DoDi

The coordinates and sizes stay valid until the extent of the container control changes. When that happens, you have a choice of several built-in layouts, that affect the position and extent of the client controls.

This should be communicated to the user.

A form designer is not a tutorial for creating layouts.

DoDi

Hans-Peter Diettrich wrote

The coordinates and sizes stay valid until the extent of the container control changes.

But this is of no interest for the one designing the layout. The absolute coordinates have no meaning for the form design at this moment.

It should display what the user has set the coordinates to be and this is either a number through direct positioning or something like alLeft if the user has chosen to not use absolute positioning.

Likewise if the user has chosen to anchor it at a sibling for the left coordinate then it should display that instead of the unaffectable ent product of the calculation.

It should always display what is relevant in the current context and state of the control.

A form designer is not a tutorial for creating layouts.

Nobody demanded this. I suggested replacing some of the displayed information in the hints with more relevant one if the control is in a state that makes other information more relevant. Aside from that: Good software actually IS a tutorial for itself by simply being as intuitive as possible.

I don't understand why parts of the Lazarus community seem to be so rigorously against usability improvements and also try to keep this whole thing as "closed", hidden and unaccessible as possible. I keep hearing things like (analogous and slightly exaggerated to improve vividness): "I have practiced doing it [the old complicated delphi way] for 12 years and therefore it is [now] intuitive [for me [and anybody else]]" or "Everything that Delphi has done is intuitive by definition" or "500k Lines of undocumented code document themselves [if you have written them yourself]", "Documentation obfuscates", "A program should not give hints about its own usage [instead it must be so complicated and give misleading or meaningless hints that only its programmers can "intuitively" understand what it is doing and why]" etc.

So why should it be intuitive to add an splitter first, and to add the splitted components later - provided that you don't forget to do so?

Please write up your ideas about intuitive GUI layouts, and compare these to the established layout management procedures, as implemented in e.g. in the Java, gtk2 or other layout managers.

The simplest and most stable layout is based on zones of vertical or horizontal orientation. Every zone can be subdivided in zones (components) of the opposite (horizontal or vertical) orientation (see DockTree. Every zone can have one dynamically sized component (alClient), all others have fixed sizes.

DoDi

An anchor docking layout may be powerful, but certainly is not consistent nor easily manageable. That's why visual anchor *docking* never has been implemented - you'll have to use an anchor editor, for simple layouts, or do it all yourself in code.

DoDi

Warning: probably off-topic

Bernd,

it seems you are comparing Java with the pascal world. First off, the Delphi team didn't invent everything: the basis of it comes from the MS Windows API en WindowManager. That said, they did 'invent' some neat shortcuts. Add encapsulation in an OO framework (VCL) and you have the result that the lazarus-team tried to build upon and mimic.

As for java GUI and frameworks (netbeans, eclipse, ...; and your citation of layoutmanagers: gridbag, ... are my clues), they started with AWT (Abstract Windowing Toolkit) and later on Swing build on top of that, followed by SWT (eclipse's GUI component framework). The onset for them was a GUI that was definable in a portable way. Apparantly (as I was told), not all their intended devices had an underlying windowmanager/gui-framework that worked with a portable coordinate-system. They are "relative"-based and not "absolute". Think layouting of videomemory for instance: y(up->down) vs y(down->up). Some systems have no notion of a pixel, ...

that led them on to construing the "learn-to-use-before-actually-using" layoutmanagers of swing.

As for editors: Delphi was the first to do it right (MS largely copied the concept from it for VB). In the java world (where you seem to come from), Borland had a pretty decent swing-designer in JBuilder before. Eclipse, JDeveloper, Netbeans... all followed. In Java there is no concept of .dfm/.lfm, so it is all constructed in code. Ofcourse that makes it complex.

And a final note on those designers in java: you can and always had the ability to use a NULL-Layout to use absolute layouting. That is the closest to the way Delphi does it.

kind regards,
Dimitri Smits

Hans-Peter Diettrich wrote

So why should it be intuitive to add an splitter first, and to add the splitted components later - provided that you don't forget to do so?

No. It doesn't matter in what order you add them.

You add them all and then you connect them like components in a circuit diagram. You anchor each of the two controls at the [sibling control that ultimately determines the position, namely the] splitter.

Let me explain what was going on with the synaptic connections in my brain while understanding the anchors and the siblings:

(observation) there are anchors on each side of every control

(thinking process) they must have something to do with sizing the controls, lets see how they behave (some quick experimenting)

(new connection in my brain) Thy behave like what they already suggest with their naming: with the anchoring and the siblings I can force one side of the control be determined relative to the position of another control or the corresponding border of the client area itself.

[...]

(observation) there exists a splitter

(thinking process) a splitter is moved by the user and the surrounding controls determine their size from its position. (invoking previously learned wisdom) controls can be sized with anchors and siblings, translated to a splitter this would mean I anchor the right side of the left and the left side of the right control at the splitter. (some hypothesis testing) (some counterintuitive hurdles with the splitter default settings and Align which is a different concept) (success)

(new connection in my brain) anchoring works with splitters the *exact* same way it works with all other controls. No need for Align (for now).

* the sheer existence of anchors has made me completely ignore and forget and dislike the Align property which reminds me of antique and clumsy nesting of box sizers and the like.

Please write up your ideas about intuitive GUI layouts, and compare these to the established layout management procedures, as implemented in e.g. in the Java, gtk2 or other layout managers.

No need for that. Lazarus implemented them already the way I find them much more intuitive than I have ever seen in any of the above mentioned frameworks. The only thing that was counterintuitive was the anchoring default setting of Align for TSplitter, a control that is meant to be used for determining the sizes of other controls and not meant to be glued to a form border. A control that I would intuitively place in the middle between the two other controls. When set to alNone the Splitter behaves like i would have expected and one can freely position it and anchor other controls at it to let their sizing be determined by the splitter (see above brain-dump).

Everything works, only the default setting for Align was wrong for my understanding (in am environment where there exist the more adequate anchors).

Bernd

Dimitri Smits wrote

it seems you are comparing Java with the pascal world.

It was more about GUI design and layout managers in general. This is not a Java thing. I only mentioned the layoutmanager that comes with netbeans (it is not one of those that come with Swing out of the box, they have created their own) and the Form designer they created on top of it because it works quite well.

Actually I have spent most of my time with wxWidgets (formerly wxWindows) and wxPython and there the concepts of layout managers are basically same as they are in many other toolkits (Tk is another one I have used a few times).

I find the balance between strictly absolute positioning (the null layout in Java that you mentioned) and the possibility of automatic sizing while still having a decent visual designer that lets the user smoothly and intuitively interact with it even in the presence of size constraining mechanisms (anchors) extremely well thought out and implemented in Lazarus. But this does not mean that there isn't room for even more improvement.

you may be interested in:
http://wiki.lazarus.freepascal.org/Autosize_/_Layout#Precedence_rules

but aside from that, and in reply to your statement above. You made some suggestions during the discussions which may be worthwhile. And the affect the designer, not the components, so they would not be a problem for Delphi compatibility.

1) Anchor-Editor could indicate, if an anchor is not available due to align. Actually more dependencies in other properties may exist. I would recommend making that a feature request on the bug tracker. So it will not be forgotten. (there is a wiki page for ideas too, but I don't remember it's location)

2) Adding (not necessarily replacing the old info) extra info to the position hints. That could be valuable too
The position (top=200) may still be valuable, even if a result of anchors. But certainly in order to use this information, one would need the full info

Martin

On Sat, 21 Aug 2010 21:19:33 +0200 (CEST), Dimitri Smits

closest

to the way Delphi does it.

There is also the FormLayout in Swing and SWT, which is pretty close to

the anchors in Lazarus (don't know if recent Delphi version have them too,

Delphi 7 didn't). But it's still a PITA to use them. NetBeans has a pretty

sweet form designer, but nothing in the Java world I have used so far comes

close to what I could do with Delphi and Lazarus. I sometimes design UIs in

Lazarus just to port them to Java then, because it's much easier to play

around and actually *do* something in Lazarus than it is in any of the Java

IDEs. (That's actually even true for the code itself too. Java libraries

are so much split up into different kinds of abstraction layers, that

nearly no task can be done "just like that" ... there is not ".SaveToFile"

or something, you always have to create a whole tree of objects just to

pass through some data. Yeah, it's a very flexible design, but what the

hell?! I don't need flexibility in 95% of the cases, I need to get the job

done. Having flexibility as option? Sweet! Being forced to write the same

stuff over and over and over? Not so sweet ...)

</JavaRant>

Best Regards,

Andreas.

P.S.: Sorry for another off-topic mail

Hans-Peter Diettrich wrote

This looks to me like you never *constructed* a GUI, or a similar design. Instead you seem to prefer to get whatever seems useful, and connect everything later, somehow.

How do you arrive at this conclusion?

If I know I need a form with A B and C and a Close button and I know already exactly how it should be layed out because I am an exceptionally versioned UI designer who pays attention to even the smallest detail and can usually read the end user's mind already in advance during the ealy planning stages, does it matter If I put A, then B and then C onto the form in a certain order when I *know* I need them all?

How would you "construct" them? In the end you would add A and B and C and then connect them as needed. I don't need any special ceremony and add the controls to the form in a certain order. Instead I only need a plan. And then I simply implement it.

And I don like it when the form designer (without giving any explanations) suddenly refuses to let me place the controls to their only optimal places that have been previously determined by my wise decisions.

Or was your reply only meant as a joke and my humor detector is broken?

[...]

This looks to me like you never *constructed* a GUI, or a similar design. Instead you seem to prefer to get whatever seems useful, and connect everything later, somehow. Such approaches tend to settle down in an unmanageable state, with unpredictable, unexpected and unwanted behaviour, as soon as the first user will put his hands on it.

But this is how many programs are implemented... :-(

DoDi

well, i'm not sure why not... as a new user, i'd be confused about how to use it, that's for sure... i doubt that it would occur to me to use the above steps...

I've been doing it for 12 years like this, never gave it a second thought. It's perfectly logical and no different from learning how to use a combobox.

i've not had any problems with combo boxes that i'm aware of... i guess my point was that of if someone with no clue wanted to start coding, they'd have problems... but that's ok... they'll learn sooner or later :)

Devil's Advocate: What's Delphi and why should I care about it? ;)

Bernd Kreuss wrote

______ [1] I am writing this from the perspective of somebody who's intuition is not contaminated by decades of Delphi usage.

that's also where i was coming from... i think you've stated it much better than i ;)

From you text ;-)

If I know I need a form with A B and C and a Close button and I know already exactly how it should be layed out

Are you willing to share your thoughts about this layout?

DoDi

Hans-Peter Diettrich wrote

> If I know I need a form with A B and C and a Close button and I know > already exactly how it should be layed out Are you willing to share your thoughts about this layout?

Of course it depends on what A, B and C are, how they relate to each other and how they are supposed to be used. It was only an example.

My description about my thought process regarding the splitter was meant to illustrate how the associations were formed in my mind and why I see the similarity in a splitter with other controls at which one can (or should be able to) anchor something.

When I explore something like the Lazarus form designer or many of the LCL components in general to be prepared for when I need them (luckily I am currently in a position where I have time to do a lot of things I like and am not forced to spend all my time with doing what others demand from me) I do a lot of hypothetical what-if experiments: What If I had two lists and needed a splitter. What if I wanted to do this layout that I did last year in wxPython for this other application. What if I need an additional button panel. What if I had 3 lists. What if the text in the label becomes bigger, how does it size itself. What if I had this and that, etc. These experiments are indeed conducted without any real need but they tell me what I am interested to know.

And btw I am discovering a new bug every week by doing such things.