On Feb 25, 2008, at 3:18 PM, Abdelrazak Younes wrote:
Bennett Helm wrote:On Feb 25, 2008, at 2:32 AM, Abdelrazak Younes wrote:I'm not sure I follow you here, but let me take a shot. By "support multi-view of the same document" you mean being able to view a single document in more than one windowBennett Helm wrote:Perhaps the biggest UI problem on Mac concerns the recent addition of a button on the left of the tab bar to hide a document within that window. I don't know how it is on other platforms, but on Mac clicking that button simply makes the document disappear without a trace ... unless you know to look in the View menu. I'm sure many Mac users will think that they have closed the document and, because there is no chance to save it before it disappears, will likely panic thinking they have lost some work.I thought about this when I added it. I understanding it can be confusing but this is really needed IMHO. The main reason is to support correctly multipart document. I would like to make LyX open automatically all child documents in the background (i.e. without having a work area affected to them). The other reason is that I want to arrange the tabs in each window independently. Taking this last argument into account, the only way we can avoid the user panic described above is to disable support of multi- view of a same document.Yes.(as opposed to a split view within the same window.Well, not as opposed to that. From the programming POV, two tab groups inside a same window or in two different windows are the same. The difference is of course that you can see immediately what documents are still left open if it you "unsplit" the view.
(I only meant that *you* meant the one rather than the other. Of course the two features aren't mutually exclusive.)
On Mac, at least, that's a highly unusual feature; I've seen it only on a few text editors aimed at programmers (such as Smultron). With being able to split the view horizontally and then maximize the window (to fullscreen, even), the usefulness of multi- view as a separate feature IMO is greatly diminished and so not worth the potential for confusion it engenders.Depends, I personally have a lot of documents opened and I gather them by subject per window. The same as I do with Firefox FWIW.
OK -- I don't want to eliminate useful features, and certainly not on the grounds that they are highly unusual on Mac.
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.
That would seem to bea much more natural UI to get what you want (at least if I understand you correctly). Concerning support for child documents, I'm not sure what all the issues are. What comes to mind is the need to load child documents for the purposes of typesetting the master and making available cross references between documents.Right.For that, I agree that we should "load" child documents in the background, without displaying them in a window unless the user explicitly asks for them. If after having explicitly opened a particular child document a user doesn't want to see it anymore, then that document should simply be closed (with a prompt to save if needed) and should appear to the user as if it is closed, even if it is still loaded in the background for the purposes of typesetting and cross references. (Thus, for example, it should not appear in the View menu, it should not reappear via the sessions file when LyX is relaunched -- as currently happens --, and so on.) Hence I don't see any reason to allow a user to explicitly make an open document invisible (but still open).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.
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.)
(An aside: with background loading of child documents, it might be nice to have a list of child documents appear in the Document menu for the master document, such that selecting a child would open it as a tab in the same window as the master document. If we did this, it might also be useful to have a menu option to open all child documents.)Good idea yes.No: I think that would be bad UI design -- an attempt to mitigate without solving the underlying problem. What is needed is a UI feature that communicates clearly and directly to the user what it means; a red light (even with tooltip help) doesn't do this, and I can't think of anything that would. Hence I think the risk of confusion (and even panic) remains quite high with this hiding feature.It is also possible to then close all visible documents, attempt to quit LyX, and have a hidden document (that you thought had been lost) pop up, asking for you to save it. Such surprises shouldn't be allowed to happen: there needs to be a visual indication of which documents are open.I agree this can be disturbing if you are not used to it (I am obviously :-)) I've thought about a red light somewhere in the status bar (or just next to the close button) that would pop up a combo for hidden documents. Do you reckon it will be enough?I see your point but I am not so sure it is that terrible.
We can at least agree that UI features that potentially induce panic should be avoided if at all possible. The question is how to enable features useful to advanced users without creating problems for novices. (See below.)
Fair enough (especially since you're coding and I'm not!), but I hope a solution is possible that would enhance the experience for all. (Do my suggestions above do this?)On Mac, hiding a document is typically done by minimizing the window containing it to the Dock, something which is already possible. Of course, I realize the intent of the new feature is different than this, but I don't see any way to implement this new feature without confusion.Me neither. So I guess we will need some user options because I don't want to degrade _my_ user experience :-)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.
Anyway, I don't have much time right now so I hope others will come and handle these issues pro-actively.MS Word always creates a new document when you launch it maybe we should do this also when there is no sessions file?Yes -- that is standard behavior for almost all programs on MacPavel, are you taking that item? (I am just passing the hot potato :-))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?
F11 has special meaning on Macs by default, so that can't be the right key to use. What does F11 do on Linux/Windows?A related -- and even pickier -- issue is that the whole document area seems to be set in a frame (again, see screenshot), which on Mac at least normally is absent. (Thus, on Mac the white area for text normally extends all the way to the edge of the window, with no border at all.)If you hit F11 and F11 again the frame disappears right? If yes, we can get rid of it. Possibly for all platforms.That's the current shortcut for fullscreen mode toggling.Is there an alternative way to do whatever that is?ui-toggle fullscreen :-)
Ah -- that gets rid of 1/2 of it, but not all. I'm attaching before and after screenshots; notice the thin gray band to the right of the text area that remains in the "after" shot.
Bennett
<<inline: before.jpg>>
<<inline: after.jpg>>
