PRIMER 22.1

Panel Behaviour: Controlling Panel Placement Menu Expansion and Action when Picking

Panel Behaviour: Controlling Panel Placement, Menu Expansion and Action when Picking


Selecting [Options] Panel Behaviour maps the Menu Panel Configuration panel, which controls the following:

Panel Placement The placement of "floating" menu boxes on the display
Existing Panel Action The action to be taken for existing floating menus when a new one is mapped
Auto Minimise Whether to minimise floating panels when a picking operation is in force
Expand Menus Whether to expand menu lists, the delay before doing this and their expansion speed
Floating menu priority Whether floating menus are kept in front of the graphics window and/or the docked right hand side area.
Keyword Editor settings The initial state of keyword editor panels when first mapped
Scaling editor panels Automatic horizontal scaling of editor panels when large labels are used.
Duplicate editor panel behaviour
Behaviour when a 2nd or subsequent editor panel is opened on the same entity.

These options are described in more detail below.

All these settings can be saved for future PRIMER sessions in your home oa_pref file by using Save settings to oa_pref file .


 


Panel Placement

Controlling the placement of "floating" menu boxes on the display

By default "floating" menu panels, such as those which edit items (eg [Keyword], Part, Modify), will be placed somewhere in the middle of the graphics window in a location chosen automatically by PRIMER , referred to as "free" placement. Although new panels will be shifted to try to ensure that they don't overlay existing ones the default placement strategy can be annoying because it tends to put panels in front of the current graphics.

If you wish you can locate panels in a more convenient position that suits your screen size and method of working by choosing one of the Left, Right, etc options above. To see where panels will be placed click on the options in the radio button set, and the display on the right will change to show where new panels will be created.

You may also need to experiment a bit to see what method suits you best.

Existing panel action

What, if anything, to do with existing floating menu panels when new ones are mapped.

There are three options

No action (default) By default existing floating panels are left as they are when new panels are mapped, and the new panel is positioned so that it overlaps existing ones in a sensible way
Iconise in situ Existing floating panels are iconised in their existing locations, the equivalent of clicking on their top right [-] button, and the new panel is positioned to just below or alongside the icon.
Iconise & Tidy Existing floating panels are iconised and "tidied" to a neat stack at the top left of the display, then the new panel is mapped in the appropriate location.
Auto-minimise

Whether, and in what circumstances, to minimise floating panels automatically.

There are three options

Off (no auto min) (default) Auto-minimisation is not active.
When picking When cursor picking (other than the global "quick pick" operation) is active then a panel will automatically minimise itself when you move the cursor out of it into the graphics window. The panel will be restored automatically if you move the mouse back over its icon, or when the picking operation has been completed.
Always Floating panels are always iconised when the cursor moves into the graphics window, whether picking is active or not.
Expand menus

Whether or not to expand lists of items in menus automatically, and parameters for this.

Many of the menus in PRIMER are too narrow when first mapped to show all the columns of their data, so by default "auto expansion" is enabled. This causes the menus to widen themselves, typically to 90% of the enclosing width available, when you move the cursor into them. They will revert to their original width when the cursor moves out of them again. This behaviour can be controlled by turning Expand menus Off or On .

You can also control:

DELAY the time interval between the mouse entering a window, and the window starting to expand.

The delay time is controlled as a factor on the default behaviour.

The actual delay time will vary from system to system depending upon the Window system and underlying speed, but a typical delay will be approximately 0.5 seconds.

SPEED (Not shown here) is the rate at which the menu expands and contracts.

As above it is controlled as a factor on the default speed.


Floating menu priority

"Floating" panels are the editor and other panels that are free to "float" in the PRIMER window, or the desktop, and which can moved, resized raised and lowered by the user.

These windows can sometimes get "lost" when they are moved behind (underneath) the graphics window, or behind the docked right hand side (RHS) area, and restoring them can be difficult.

RHS top lowered Will keep the top half of the docked RHS area, containing Tools and Keywords, at the bottom of the window stacking order.

The default is to keep this top half lowered.

RHS bottom lowered Will keep the bottom half of the docked RHS area, containing "tabbed" panels, lowered.

Using this can have side-effects. When a new Tools or Keyword operation is started the bottom RHS area will not be brought to the front, and as a result any floating panels currently lying over the RHS area may obscure the new panel. It is easy enough to move any such floating panels out of the way, but if you find this a nuisance you may wish not to use this setting.

For this reason the default is not to keep this bottom half lowered.

Graphics lowered Will keep the graphics window at the bottom of the window stacking order.

This is not unconditional. The user may wish to bring the graphics window to the front in order to obtain an unimpeded view of the model, and this can still be done by clicking on its top bar, or by maximising it with the top right [] button. It will remain in front during any dyanmic viewing operation using shift/control + mouse.

However if Graphics Lowered is active the graphics window will be lowered again as soon as any button clicks take place anywhere in the user interface.

Reset Layout When the master PRIMER window is resized, or goes through an Iconise / Restore cycle, then by default the window layout is reset to the default. This means that the graphics window is resized to fit into its proper "slot" on the screen, the RHS docked area is reset to its default position, and the dialogue box is also returned to its standard size and shape.

If this option is deselected then the layout of all of the above will be unaffected by master window size and shape changes.

The default is for both of these options to be set but, as with the other settings on this panel, you can capture your current settings in the oa_pref file for use in future PRIMER sessions.


Note: There is an alternative, more direct way of restoring "lost" floating windows using the "lower" button at the top right of the graphics box. Regardless of the two settings above this will forcibly lower both graphics window and docked RHS area to the bottom of the window stacking order, and any floating panels "lost" behind them will become visible again.
Keyword editor settings
Controlling the initial appearance of the generic keyword editor.


When the Keyword editor is first mapped you can control the following attributes of its panel to limit its initial size:

Initial #definitions shown The maximum number of actual items that will be displayed.
Initial #rows displayed

The maximum number of rows of data that will be displayed.

If the items being shown span several rows of data then this may limit the number of items actually shown. However there will never be less than one item shown, regardless of how many rows of data it has.

Practical considerations may also limit the size of the panel: if there is not enough space available on the screen to display the requested data then the number of rows and/or items may be limited further.



Scaling editor panels for large labels
Controlling whether or not editor panels are scaled horizontally to show "large" labels.


In order to minimise the screen space used by editing panels the buttons are sized to show "small" labels in the range 1 to 99,999,999. When "large" labels are used this can result in the labels being truncated and difficult to read, so PRIMER can scale these panels horizontally in order to allow the full labels to be shown. The default is for panels to be scaled.

This process is robust but quite crude: PRIMER finds the largest label of any item in the model, computes its width, and then scales the panel to accomodate this. If the panel does not in fact include any items with large labels this can result in quite a lot of wasted space, so this behaviour is switchable, and can also be saved using the preferences below.

Option Description Preference
Scale edit panels for large labels Controls whether or not "scalar" editing panels for single items are scaled. primer*scale_edit_panels: true | false
Scale KW editor for large labels Controls whether or not Keyword Editor panels are scaled. primer*scale_kw_editor: true | false      



Duplicate editor panel behaviour

How PRIMER deals with the 2nd and subsequent editor panels on the same item


Each editing panel makes a scratch copy of the entity being edited and works entirely within that until the user presses "Update" to replace the permanent definition in the database with the edited version. When two or more editing panels are opened on the same entity each has its own scratch definition, so there is no interference or connection between the panels when editing.

Prior to PRIMER 21.0
Each panel has full editing access so if two panels A and B are open on the same entity then saving changes in panel A and then saving different changes in panel B will result in the changes made in panel A being overwritten and lost.
From PRIMER 21.0 onwards
The first panel has full editing access as normal, 2nd and subsequent panels are opened in "Browse" mode giving read-only access.  This means changes can only be made in the first panel removing the possibility of confusion or accidental over-writing of changes.


This is a change of behaviour so an option and its associated preference are provided to permit reversion to the old behaviour

Option Description Preference
Permit duplicate editing panels
 How 2nd and subsequent editing panels on an item are handled.
 primer*permit_duplicate_edit: true | false


Previous | Next