Behaviour of toolbar placement and commandline

Wiebe van der Worp

Some actions when placing toolbars do not proceed as expected. In Lisp I have a workspace switcher that does not quite do what is desired in V19. Hopefully there are things that I overlook, before I submit a support request.

The following is pasted on the command-line:

-toolbar arcs s -toolbar arcs r 0,0 -toolbar circles s -toolbar circles r 0,1 -toolbar lines s -toolbar lines r 0,2

Pixel coordinates have 0,0 left-top with x to the right and y to the bottom. The expectation is that the toolbars will be placed under each other (0,0 - 0,1 - 0,2). However, placement in V19 is from left to right (0,0 - 1,0 - 2,0).

More specifically, x,y positions are processed correctly for "top" and "bottom". However, "left" and "right" go wrong.

Workaround: convert x,y coordinates to y,x for toolbars left and right.

Is this desirable new behaviour? Or a quirk?

At the bottom of the screen the position of the command-line is interpreted as a floating panel, just like the toolbars. The command-line behaves in terms of position as a toolbar, but I am not familiar with an instruction to change the location (except COMMANDLINE and COMMANDLINEHIDE) or to make "floating" "fixed".

-toolbar arcs s -toolbar arcs b 100,0 -toolbar circles s -toolbar circles b 101,0 -toolbar lines s -toolbar lines b 102,0

provides a different position for the command-line than:

-toolbar arcs s -toolbar arcs b 0,0 -toolbar circles s -toolbar circles b 1,0 -toolbar lines s -toolbar lines b 2,0

This monologue (so far) could be expanded to other panels (i.e. Ctrl-1,...).

Playing with variations, negative values ​​and sizes yields many results, but the position of the command line remains unpredictable.

Owen Wengerd

For docked toolbars (and panels), the position is horizontal,vertical grid position inside the dock site. For floating bars, the position is display coordinates in DIP (device independent pixels). Before V19 there was a bug in that the values were reversed for top and bottom dock sites (or maybe it was the other way around, that they were reversed for left and right dock sites, I no longer recall).

Wiebe van der Worp

Thanks Owen, I think that bug laid eggs.

-toolbar arcs r 0,0 -toolbar circles r 0,1 -toolbar lines r 0,2

In V19, top and bottom are okay, left and right x&y are reversed.

Remains: panel behaviour.

Wiebe van der Worp

And to illustrate the panel, command line issue, I've added another screen-dump where V19 behaves identical to V18...

No workaround so far.

-toolbar arcs b 0,0 -toolbar circles b 0,1 -toolbar lines b 0,2

Owen Wengerd

Maybe I'm misremembering. Have you compared behavior to Acad? V19 behavior is supposed to be compatible to Acad. If different, you had better submit a support request.

Wiebe van der Worp

I already created two support requests, one for the reversed x and y values, which is specific to V19 and one for the unpredictable panel locations, which is a known problem for a longer time.

In the other CAD program, display coordinates were always x values increasing to the right and y values increasing to the bottom. The panel location is not a problem there but toolbar placement can be a pain, with workarounds like first make them float, then positioning and repeating toolbar commands. BricsCAD lacks those problems, but mentioned panel location problem seems hard to solve and reversing x and y makes it incompatible.

Thanks so far!

Wiebe van der Worp

The underlying idea of filling a free space with toolbars and panels is excellent and works better than with AutoCAD. Toolbars can be fixed with display coordinates. Decent and in just one action. However, the behaviour of panels is not scriptable. It appears that it is not possible to give the command line its own place by using Lisp.

At the lower area, the command line is on row 0 by default. So it is pushed away by toolbars on the same row. Putting toolbars at row -1 is impossible and putting them on row 1 - under the command line - is not user friendly. I seem to remember that this was never a problem with AutoCAD (which has its own problems with toolbars).

This is written with programming in mind. If you have access to default.cui, where workspaces contain the panel positions, simply change the row from 0 to a value like 10. Then automated placement of toolbars on row 0-9 is flawless.

It would be great to see the command panel(s) on row 10 in a next release (feature request, low hanging fruit). Thanks Owen for clarifying.

Wiebe van der Worp

And it turns out that the version used, 19.1.06, was affected by the reversing x and y values. I can confirm that the current version, 19.1.11, is not affected. Apparently I missed a release note:

CUI
Prior to V19, it was declared that rows were vertical and columns were horizontal for toolbars and panels, as one might expect. Unfortunately, prior to V19.1.07, this behaviour could change depending on where said toolbars or panels were docked. We've done our best to correct this situation in V19. In V19, rows are always horizontal and columns are always vertical. Like all good things, this change requires migration of older .cui files to update their file version. We do this when a pre-V19.1.07 .cui file is opened. So, as of V19.1.07, all "old" .cui files are automatically migrated and the errant behaviour corrected.

Reading on the following got my attention, too funny not to bring under the attention:

MULTISLICE
The SLICE command has been extended with a new multi-slice option, strongly enhancing your slicing experience. If only your kitchen knives worked this well!

So I was asking myself when we can expect the BLENDER command.

Thanks for helping Owen