Bennett Helm wrote:
On Feb 25, 2008, at 3:18 PM, Abdelrazak Younes wrote:
Concerning arranging tabs: can't this be done instead by dragging and
dropping the tabs -- both to change the order within a window and to
move a tab from one window to a different window?
Sure, every thing's possible and drag&drop would be nice. Maybe for
1.7 :-)
In the short term, then, perhaps an alternative would work for you: a
new lfun to open the last-closed document. Then you could close a
document in one window, switch to another window, and invoke this
function. (Perhaps there could be a stack of last-closed documents this
would apply to.) That I think is better from a UI model than invisible
yet still open documents.
Isn't that what we have already with the "File->Open recent" menu?
...
So you are advocating to not let the user able to effectively close a
child buffer if its master is still open? I don't say this is a bad
idea but we have to think a bit more about this. Especially since a
child document can have multiple master depending on which master is
current.
I'm not sure whether we're understanding each other here, so let me try
again. My thought is that *users* should understand documents to be
either open (and so visible in the UI) or closed (and so not visible).
That is, from the user's perspective there shouldn't be a 1/2-way state
of being open but invisible. From the *developer's* perspective,
however, documents can be in a third state -- "loaded" (as I called it)
into memory so that their labels are available for cross-references, etc.
Yes, that's exactly what I understood from you. But you are mixing two
things. This third "loaded" state is user oriented; from a developer's
perspective a document is opened or it is not. The user will notice that
this document is "loaded" because of label, toc, etc.
Now what's the difference between "loaded" and "open but invisible"? --
"Open but invisible" implies a certain status in relation to the user
experience. Thus, open but invisible documents can have changes that are
unsaved or can be saved in a sessions file; "loaded" documents as I
understand them cannot: the user should be completely unaware that a
document can be in such an intermediate state, and so its being in that
state should have no discernible effects on the user experience.
So, I think users should be able to *close* child documents even while
the master document is still open; they would remain "loaded" and so in
this sense would be available to even multiple master documents that are
still open. (This is not quite how you've described my proposal.)
But that's what I understood :-)
OK, I propose then that hidden document are *always* in a saved state.
Or at least that we ask the user if he wants to save the
about-to-be-hidden document (like a child document).
But imagine that a "loaded" document is changed by an external process,
what should we do? Ask the user if he wants to load a document?
...
Oh your suggestions make sense, I don't deny that. But I am not sure I
want to degrade the advanced user experience because newbies are
subject to panic :-)
I agree: we should not degrade user experience for anyone. If my
suggestions above wouldn't be satisfactory for advanced users, perhaps
it would be possible to have a (hidden?) preference to turn on the "hide
document" button. That would give you what you want but also make it
hard for novices to encounter a feature that could cause them problems.
Before going the preference way, let's see first if we can compromise on
a few items.
...
2. Closing the last window causes LyX to exit. This should not
happen on Mac.
This is related to a bugzilla entry about unique instance. How would
you exit LyX on Mac.
Only by direct user request: LyX > Quit or <Cmd>Q.
This is not too difficult to achieve but the implication are not
obvious for Windows and X11 platforms.
Can't this be done only on Mac?
I'd rather do it on all platforms and provide a setting to switch this
feature off. Maybe...
Abdel.
