Topics

Layer Groups #New


Adam Richards
 

New Video demo of the Layer Group features - 

- No Button
- Button Groups
- Current Layer Settings files

https://www.loom.com/share/d002fa44973c44009caa124a18a01fd9

Comments appreciated as I would like to know this is roughly right before adding it to main branch 

Adam


Jack Haverty.
 

Hi Adam,

Very nice!   I've been working lately on laying real track, but will get back to virtual track soon for the next "layer" of the layout design.

Some comments and suggestions:

1) It would help to put a link, or button, or menu item somewhere that tells the user that there is a wiki and how to get to it for more information.

2) Is there a way to make the "link layers" GUI use layer names instead of just numbers?  I was thinking about perhaps a pop-up scrollable window containing all the layers with their names, with currently linked layers highlighted, and you select/deselect multiple layers you want to be linked.

3) I'm not exactly sure how linked layers behave.  Can layers "overlap", i.e., can a layer be in more than one "linked set"?  I can envision using layers for multiple purposes, e.g., one set of layers contains all the layers for the "main line", while another set of layers contains all the layers for an area of the layout, e.g., "west peninsula".   A particular layer (track, benchwork, etc.) might be in one or multiple sets, depending on what you're doing at the time.   If I link a bunch of layers, configure all the settings, and write a .xset file, can I then link a different bunch of layers and write a second .xset file with different settings?

4) When you say that all of the settings are in the .xset, does that include things like the "stickiness" of commands and other such "behavioral" settings of the program itself?  I'm not sure if such settings are currently saved between sessions.  I'm still running 5.1.2a and don't see them in the .rc file.   Will they be saved in the .xset?  Perhaps this is answered in the wiki.

Thanks!
/Jack


On 9/20/20 1:38 AM, Adam Richards wrote:
New Video demo of the Layer Group features - 

- No Button
- Button Groups
- Current Layer Settings files

https://www.loom.com/share/d002fa44973c44009caa124a18a01fd9

Comments appreciated as I would like to know this is roughly right before adding it to main branch 

Adam


Adam Richards
 

In order -

  1.  I think I could add that helpful-text to a place when saving a setting file completes. Note that you could simply take the settings you want and make them into a .xset file as it is plain text.
  2. It might be possible to do the conversion in the UI only as a read-only message. The issue with doing it as an input method is that Layer Names do not have to be unique... Pop-up windows and lists all that have to wait for now - this is bare-bones slipping something into development late in the game. Once we have GTK3, we could envisage tree-structures and lists with tick-boxes, etc. Note that you can create the layer structures with a text editor and import it (or even simply replace that part of a layout file). The Layer Group list and the settings names are stored in the layout .xtc. 
  3. Yes there is no strict policing of what layer is in what other layer's group. They can overlap, and a grouped layer could have a totally different set, for example. The group (and the settings file, if any) is only used is when that particular layer is made current. So yes is the answer to your question.
  4. Sticky as a setting should be in there - it is a preference set from DialogItem->sticky-set. It's an integer bitmap. Admittedly you have to know what the bits mean and they are dynamically built in order of initial startup. So as you read down the Options->Sticky Menu the bits are in order from least (bit 1) to most (bit 27), I believe. However, although this power to set any aspects of the program's settings values is theoretically there, it is mediated by the fact that not all settings are actually used post startup - and so it is with Sticky whose value is only loaded in from preferences as the menus are being created today.  So a list of what would be most useful to have would be helpful beyond scale/gauge and the other aspects that are scale/gauge related (min radius, max slope, parallel separation, turntable diameter, tie data), or are within layers settings anyway, as they may need to be added to the settings file activation logic to ensure they take effect.
Once again, this is a little "rough-and-ready" power feature right now which was the way to slip it in - it will not be perfect in execution - I would look to document the known setable features in the wiki as we go as well.  

Adam
 


Jack Haverty.
 

Understood, it's good to get some experience with new functionality, so what you have done will be a big help.

My suggestion about layer names/numbers is not a big deal.  Grouping layers is the kind of thing you probably set up once and may never change again, so working with numbers is fine.

FYI, the other settings I would find most helpful are 1) the "stickiness" of individual commands; 2) the "command default" of "select" versus "change properties"; 3) which parameter files are in effect at the time (and appear in the toolbar); and 4) which tools are visible in the toolbar (I know that's not a setting now). 
The first two are things I find I keep changing a lot as I work.  The last two are motivated as a way to save screen real estate.

I'm still curious about how the layers will behave.  E.g., suppose I have 4 layers, and I set layer 1 to link to 2&3, and set layer 4 to link to 3.   When I select layer 1, I assume I get 1/2/3, and when I select 4, I get 3/4.  Not clear what happens when I select 2 or 3.   Feel free to say I should just try it...

Tnx,
/Jack


On 9/21/20 8:42 AM, Adam Richards wrote:

In order -

  1.  I think I could add that helpful-text to a place when saving a setting file completes. Note that you could simply take the settings you want and make them into a .xset file as it is plain text.
  2. It might be possible to do the conversion in the UI only as a read-only message. The issue with doing it as an input method is that Layer Names do not have to be unique... Pop-up windows and lists all that have to wait for now - this is bare-bones slipping something into development late in the game. Once we have GTK3, we could envisage tree-structures and lists with tick-boxes, etc. Note that you can create the layer structures with a text editor and import it (or even simply replace that part of a layout file). The Layer Group list and the settings names are stored in the layout .xtc. 
  3. Yes there is no strict policing of what layer is in what other layer's group. They can overlap, and a grouped layer could have a totally different set, for example. The group (and the settings file, if any) is only used is when that particular layer is made current. So yes is the answer to your question.
  4. Sticky as a setting should be in there - it is a preference set from DialogItem->sticky-set. It's an integer bitmap. Admittedly you have to know what the bits mean and they are dynamically built in order of initial startup. So as you read down the Options->Sticky Menu the bits are in order from least (bit 1) to most (bit 27), I believe. However, although this power to set any aspects of the program's settings values is theoretically there, it is mediated by the fact that not all settings are actually used post startup - and so it is with Sticky whose value is only loaded in from preferences as the menus are being created today.  So a list of what would be most useful to have would be helpful beyond scale/gauge and the other aspects that are scale/gauge related (min radius, max slope, parallel separation, turntable diameter, tie data), or are within layers settings anyway, as they may need to be added to the settings file activation logic to ensure they take effect.
Once again, this is a little "rough-and-ready" power feature right now which was the way to slip it in - it will not be perfect in execution - I would look to document the known setable features in the wiki as we go as well.  

Adam
 


Adam Richards
 

Jack,
Show 1 show 1,2,3. 
Hide 1 hide 1,2,3 (Note - 1 can't be the current layer when hiding and if either 2 or 3 are the current layer they will not be hidden).
Show 4 show 3,4.
Hide 4 hide 3,4. (To hide any layer 3 must not be current, to hide 4, it must not be current, ).

Show 2 show 2. 
Hide 2 hide 2 (2 must not be current)
Show 3 show 3. 
Hide 3 hide 3 (3 must not be current).

But this brings up an interesting point.

  • As it stood, if the layer I make "current" was already being shown, it wouldn't force show of the other linked layers.

I have changed it so that making the layer current will always show the all linked layers regardless of the current state of the layer. Once I have moved on a different current layer I can hide them all together using the single button, of course.  

There is the case of what happens if the layer is already current when I try to select it again as current in the drop list - and the answer for that is absolutely nothing - because the UI layer never tells us that it happened. 

-----
The parameter files shown in the Hot Bar are affected by what Gauge and Scale is in effect, of course. It's very complex to reset the loaded list after startup, though. So can't do that sensibly in this change. You know about right-click on the Toolbar to "jump" to the right file and the new auto-repeat left-right scrolling buttons, I suppose...

The toolbar showing setting is in the settings under DialogItem -> misc-toolbarset. It is another integer that is a bitmap reading down the list of entries you see in the UI. I can pick that up and re-apply it.

The Select/Properties is DialogItem->cmdopt->preselect.  I can do that.  I'll also pickup Right-Click, Select-Mode and Deselect.

I also added the Display->Display Labels setting as well in case you want to link display of labels to layer. 

Adam


Mark Schneider
 

Adam,   Outstanding implementation of some ideas just a few weeks ago. Both videos were great.    How do I get a chance to use these tools.   I understand 5.2 xtrack cads are not backwards compatible but 5.2 works well enough to continue working on your layout and work through any bugs that pop up.    I extracted the 5.2 beta2.1  zip file  but I can't fine an executable file to click on.  I also downloaded the setup.sh file.    Now what?     Thanks
 Mark


Adam Richards
 

Mark,
The zip file is source. (And the source at Beta2.1 level). But these changes are sitting at the branches in the SourceForge repository. 

So the choices are these - 

1) Use the Beta 2.1 by taking and installing the relevant built package for your platform (.exe, .dmg, .rpm, .deb) from SourceForge. This will be as of a few weeks ago and not include the latest level demonstrated.
2) Build the program yourself from source - instructions are on the wiki - http://xtrkcad-fork.sourceforge.net/Wikka/CMakeBuild
This is always available but requires reasonable work and will expose you to the current (BSF) level with more potential bugs as well as fixes.
3) Wait for a few more weeks before we build a new release that incorporates the progress to date.

Adam


Jack Haverty.
 

Hi Adam,

OK, that explains how layers will behave.  I had thought that "linking" several layers meant they were all linked bidirectionally.  So linking 1 to 2 would imply 2 was linked to 1.  But linking is actually a property of the selection of a layer, rather than of the layers themselves.   What you've done will be a nice addition.

Re the Hot Bar:

The problem I'm seeing is that the bar gets overpopulated with stuff that's irrelevant to my current task. 

For example, when I'm working on benchwork, I make up lots of polygons representing pieces of plywood, by drawing a bunch of lines and then "group"ing them so they can be manipulated as a single structure.  That puts each polygon up in the hot bar.   Then I do the same thing for structures, e.g., building up a passenger station with a bunch of filled rectangles and grouping it.  So the structures also appear in the hot bar.   The hot bar also contains all the various turnouts loaded from a parameter file.

What I'm seeking is some way to hide the irrelevant (at the time) items in the bar.  E.g., when working on track, I don't need to see plywood or structures, or when working on benchwork I don't need to see turnouts.

Perhaps I'm just not using the program in the best way.  It's not a big deal, just that it would be nice to be able to show/hide the tools and components that appear on the screen, depending on what you're working on at the time, as you can do now with Layers.  Just some thoughts for the future.

Tnx,
/Jack


On 9/23/20 1:38 AM, Adam Richards wrote:

Jack,
Show 1 show 1,2,3. 
Hide 1 hide 1,2,3 (Note - 1 can't be the current layer when hiding and if either 2 or 3 are the current layer they will not be hidden).
Show 4 show 3,4.
Hide 4 hide 3,4. (To hide any layer 3 must not be current, to hide 4, it must not be current, ).

Show 2 show 2. 
Hide 2 hide 2 (2 must not be current)
Show 3 show 3. 
Hide 3 hide 3 (3 must not be current).

But this brings up an interesting point.

  • As it stood, if the layer I make "current" was already being shown, it wouldn't force show of the other linked layers.

I have changed it so that making the layer current will always show the all linked layers regardless of the current state of the layer. Once I have moved on a different current layer I can hide them all together using the single button, of course.  

There is the case of what happens if the layer is already current when I try to select it again as current in the drop list - and the answer for that is absolutely nothing - because the UI layer never tells us that it happened. 

-----
The parameter files shown in the Hot Bar are affected by what Gauge and Scale is in effect, of course. It's very complex to reset the loaded list after startup, though. So can't do that sensibly in this change. You know about right-click on the Toolbar to "jump" to the right file and the new auto-repeat left-right scrolling buttons, I suppose...

The toolbar showing setting is in the settings under DialogItem -> misc-toolbarset. It is another integer that is a bitmap reading down the list of entries you see in the UI. I can pick that up and re-apply it.

The Select/Properties is DialogItem->cmdopt->preselect.  I can do that.  I'll also pickup Right-Click, Select-Mode and Deselect.

I also added the Display->Display Labels setting as well in case you want to link display of labels to layer. 

Adam



Adam Richards
 

Jack,

Yes - I get that would be desirable. If you need to trim down the intermediate Groups shown you can either name them identically (overwrite) or periodically Manage->Custom... and trim the excess. 

You may also find utility in placing all the parts of the plywood into one layer and then making it a Module Layer. This achieves a grouping without creating one... I have found that although you can't make the current layer a module the code doesn't stop you changing the current layer to one that is already a module and then adding items to it....  A bug, I think but possibly useful for you.  With a Module Layer, selecting one selects all (like a Select All in Current Layer but without needing to change Layers). 

-----

My overall GTK3 re-design idea for HotBar would really be to have it as a fly-out sub-window on the RHS - with tabs for each parmfile/and the custom objects on a different tab. One could imagine filters for some extra tabs and so on so you could have "Structures" or "Cars" or "Turnouts" as well.  It would support drag-and-drop at that point. That way it doesn't get in the way of getting to the top toolbar "ribbon" - where the buttons are grouped into tabs by task type and include the settings for those tasks.  Today we have basically two sets in our "ribbon" -> Design Mode and Train Mode.  And we have sub-selection by precise type - where those should be all be on one ribbon tab (Draw Curved Objects, for example, or even Draw Objects with both lines and curves) which all share settings for linetype, width, color, etc. 

It is most likely though that would have to be in a second release of a GTK3 because the initial compatibility release is planned to have both GTK3 and the traditional UIs as libraries first - to ensure we don't break anything and can fall back easily if we do.  The HotBar today is not its own component - it is part of an the screen laid out in a fixed manner with specialized parts (like the left/right buttons) so that change can't be done non-disruptively unless we add a new component entirely.

Adam


Jack Haverty.
 

That sounds like a good plan. 

One other suggestion for thinking about the GTK-based redesign - try to take advantage of vertical bars on the sides of the screen.  With today's wide-screen and possibly multiple monitors, there's often a lot more horizontal space than vertical.

I use some other programs (e.g., Digikam, LibreOffice, as well as Gnome itself) that have toolbars of some sort on all 4 edges, with similar tools grouped onto a particular edge.  I'm not sure how multi-platform constraints limit design choices, but it's nice to use the left/right edges too, and even be able to set different bars to, for example, only appear when you mouse over that edge, or change their contents depending on which "mode" (could be Layer) you're using at the time.

/Jack


On 9/24/20 11:44 AM, Adam Richards wrote:

Jack,

Yes - I get that would be desirable. If you need to trim down the intermediate Groups shown you can either name them identically (overwrite) or periodically Manage->Custom... and trim the excess. 

You may also find utility in placing all the parts of the plywood into one layer and then making it a Module Layer. This achieves a grouping without creating one... I have found that although you can't make the current layer a module the code doesn't stop you changing the current layer to one that is already a module and then adding items to it....  A bug, I think but possibly useful for you.  With a Module Layer, selecting one selects all (like a Select All in Current Layer but without needing to change Layers). 

-----

My overall GTK3 re-design idea for HotBar would really be to have it as a fly-out sub-window on the RHS - with tabs for each parmfile/and the custom objects on a different tab. One could imagine filters for some extra tabs and so on so you could have "Structures" or "Cars" or "Turnouts" as well.  It would support drag-and-drop at that point. That way it doesn't get in the way of getting to the top toolbar "ribbon" - where the buttons are grouped into tabs by task type and include the settings for those tasks.  Today we have basically two sets in our "ribbon" -> Design Mode and Train Mode.  And we have sub-selection by precise type - where those should be all be on one ribbon tab (Draw Curved Objects, for example, or even Draw Objects with both lines and curves) which all share settings for linetype, width, color, etc. 

It is most likely though that would have to be in a second release of a GTK3 because the initial compatibility release is planned to have both GTK3 and the traditional UIs as libraries first - to ensure we don't break anything and can fall back easily if we do.  The HotBar today is not its own component - it is part of an the screen laid out in a fixed manner with specialized parts (like the left/right buttons) so that change can't be done non-disruptively unless we add a new component entirely.

Adam



Adam Richards
 

Quite possibly the desired layers “tree” might be a sub window control on the right hand side to complement the tabbed hot bar replacement on the left. Along with a form of context help that shows all the actions available with animation and so forth.

All possible with enough effort - but all need us to get to a common UI layer first so we don’t end up hanging to do twice the work and be navigating two very different UI approaches.

Adam