BUG: Close All leaves last layout as active
The Close All command should clear the active layout indication from the title bar, but it does not. In this state Cmd-Opt-Control could overwrite the formerly active layout.
Comments
-
The current implementation does not provide that a 'Close all' command will close the active layout, so this is not a bug, per se.
I can create a case for Development to consider implementing this behavior.
0 -
It's an interesting issue. I doubt that I would update active and thus get a blank "active", but I thought to reload the latest local "Application Closed" layout as better representing the older layout bearing the name of the "active". It loaded OK but the name disappeared from the title bar, leaving me with another action or two to get back the active name.
So it would be better for Close ALL to close the active layout, discouraging me from doing what I just did.
Another situation is:-
- start with an active layout
- go to Home Page
- enter a passage and press GO
- the resulting layout bears the name of the original active layout!
Dave
===Windows 11 & Android 13
0 -
Tonya J Ross said:
The current implementation does not provide that a 'Close all' command will close the active layout, so this is not a bug, per se.
That does not make good sense. Logically, when all windows are closed, there is no active layout except Close All.
0 -
I agree with Jack.
0 -
Dave Hooton said:
Another situation is:-
- start with an active layout
- go to Home Page
- enter a passage and press GO
- the resulting layout bears the name of the original active layout!
I am able to reproduce this behavior, and will report it to Development.
0 -
Jack Caviness said:
The Close All command should clear the active layout indication from the title bar, but it does not. In this state Cmd-Opt-Control could overwrite the formerly active layout.
Dave Hooton said:Another situation is:-
- start with an active layout
- go to Home Page
- enter a passage and press GO
- the resulting layout bears the name of the original active layout!
This sounds very dangerous. Someone could very easily work a couple of hours and then unthinkingly update the current layout and unintentionally overwrite the old one. This needs to be fixed before the beta goes stable, or lots of people are going to lose layouts they may have worked hours on and may not even remember how to recreate.
Mac Pro (late 2013) OS 12.6.2
0 -
fgh said:
This sounds very dangerous. Someone could very easily work a couple of hours and then unthinkingly update the current layout and unintentionally overwrite the old one. This needs to be fixed before the beta goes stable, or lots of people are going to lose layouts they may have worked hours on and may not even remember how to recreate.
This is mostly a cosmetic bug; it's very easy to work around it by pressing Ctrl+Alt+X to close the current layout (before or after closing all panels). It will be fixed in a release after 5.0b.
0 -
Bradley Grainger (Logos) said:
pressing Ctrl+Alt+X to close the current layout
Cmd-Opt-Control-X on Mac
0 -
Bradley Grainger (Logos) said:
This is mostly a cosmetic bug;
I disagree, as described above.
And the situation (above) that gives the active layout name to a new Home Page layout...?
Dave
===Windows 11 & Android 13
0 -
Dave Hooton said:
What is the nature of your disagreement? As you stated in your post, "I doubt that I would update active and thus get a blank "active"". Likewise, I don't consider if very likely that this bug will cause any crashes or data loss, thus my categorisation of it as "mostly cosmetic".
Dave Hooton said:And the situation (above) that gives the active layout name to a new Home Page layout...?
As I posted, I currently consider it a cosmetic bug, but it will be fixed after 5.0b ships.
0 -
Bradley Grainger (Logos) said:
This is mostly a cosmetic bug; it's very easy to work around it
Maybe it is, but to work around it you first need to a) be aware of the need to work around it, and b) remember to work around it. Most people won't.
Bradley Grainger (Logos) said:As you stated in your post, "I doubt that I would update active and thus get a blank "active"".
Perhaps, but people will add new panels to that blank window, and then unthinkingly just update it, without realizing until it's too late that they just overwrote the very important and very complicated layout they closed earlier.
Bradley Grainger (Logos) said:Dave Hooton said:And the situation (above) that gives the active layout name to a new Home Page layout...?
As I posted, I currently consider it a cosmetic bug,
Again, people will start working in that default layout, update it, and lose their earlier layout.
Of course, I'm not on beta, so I haven't seen this in real life, and I may be missing something. But from what I can read here, this doesn't sound cosmetic at all. It sounds like a certain path to a lot of lost layouts.
Mac Pro (late 2013) OS 12.6.2
0 -
Bradley Grainger (Logos) said:
What is the nature of your disagreement? As you stated in your post, "I doubt that I would update active and thus get a blank "active"". Likewise, I don't consider if very likely that this bug will cause any crashes or data loss, thus my categorisation of it as "mostly cosmetic".
fgh states my case quite well. Any time a user is expected to anticipate a situation and perform a corrective action before doing so is certain to cause issues for their current layout e.g. the scenario I presented above that encouraged me to think an Application Closed layout, representing my current layout, would become the new "Active". Is it reasonable to expect a Home Page (or blank) layout to bear the same name as the layout originally loaded?
The "active" layout concept is not intuitive and the design should anticipate scenarios by not applying the active name to layouts that obviously do not represent the user's active one.
EDIT:
The scenario at http://community.logos.com/forums/t/65965.aspx did cause data loss but I'm asking only that it be considered. One other scenario caused data loss but I'm unable to reproduce it.
Dave
===Windows 11 & Android 13
0 -
Bradley Grainger (Logos) said:
It will be fixed in a release after 5.0b.
The fix will be in 5.0b SR-1 (unless there is an RC 3 first). If this bug will cause problems with your use of 5.0b, please do not update until 5.0b SR-1 is released.
0
