On Feb 26, 2008, at 2:24 AM, Abdelrazak Younes wrote:
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?
...
But it's not an lfun is it? So no quick keybinding (which might be
useful)? (I guess I'm forgetting that on Linux/Windows it's standard
to access menus with the keyboard. But an lfun bound to <shift>F4,
say, would be much faster to do repeatedly than <alt>F R 1 ... or
whatever it is, especially if you implemented a last-in first-out
stack.)
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.
I guess we're largely in agreement here, just using different
language. Nonetheless, I do think the language matters from the
user's perspective -- see below.
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).
Yes -- I think this is the important point: hidden docs should be
saved. (I'd also say: hidden docs shouldn't affect the sessions file
and so shouldn't be automatically opened on a relaunch.) Nonetheless,
as I said, I do think the language used in the UI is important here
-- and naturally I like my language better. ;)
One key question is: why should it be possible for a user to close a
document instead of hiding it? Is there ever going to be a case, for
example, when I'd want to close a child document and thereby make it
*unavailable* to a still open master document? If not, then I think
it makes better sense from the user's perspective not to confuse
matters with a distinction that doesn't make a difference, and so we
should stick with the language the user already knows: documents are
either opened or closed.
Of course, you think the distinction between open and hidden
documents makes a difference when it comes to manipulating the
arrangement of tabs in open windows. But -- to put it uncharitably --
I don't think we should expect all users to learn a new way to
interact with documents just to buy some time for developers to
implement a proper solution to the problem of arranging tabs. (I'm
putting that uncharitably hoping either to convince you (!) or to
demonstrate clearly what my misunderstanding of the usefulness of
hidden documents is.)
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?
Good question. I would say -- in line with my claims about how UI
language matters -- that if the user hasn't explicitly opened a
document, he or she shouldn't be pestered with questions of whether
it should be reloaded or not. Rather, in such a case LyX should
always use the most recent saved copy for typesetting and labels.
...
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.
How close are we to a compromise? Does the suggestion of an lfun for
a last-in first-out stack for opening recent files give you what you
want for organizing documents in windows? (Or what am I not
understanding?)
...
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...
That's fine by me.
Thanks, by the way, for your careful attention to this.
Bennett
