Closing of last tab

Alexander Kellett lypanov at kde.org
Sat Sep 20 09:19:11 BST 2003


umm...
why not just add a new dialog?
"are you sure you want to close the last tab?"
with a show again thingy of course.

mvg,
Alex

On Sat, Sep 20, 2003 at 04:03:57AM +0200, Leo Savernik wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Am Freitag, 19. September 2003 19:20 schrieb Thomas Zander:
> [...]
> >
> > I see you failed to read the document and the mailing list I pointed you
> > to. These issues were discussed and answers were given.
> > In short; they are called KDE guidelines instead of editor guidelines for a
> > reason.
> 
> I did look at the lists, but none of the postings deal with Konqueror issues 
> particularly (If there actually are such postings, I'd be grateful if you 
> point me to them).
> 
> Whatever, the user interface guidelines itself state that "[t]he guidelines in 
> this style guide are only suggestions. [...] Following rules will not do 
> that, but common sense will". This is exactly what konqueror does in many 
> places.
> 
> Ctrl+N: Unconditionally opens a new "application" (using the guide's 
> terminology). Concerning the guide, it should not do that if it is in its 
> initial state. But for konqueror, this makes more sense.
> 
> Ctrl+O: Unconditionally opens the given document into the same window, 
> regardless of it being out of initial state. Again, deviating makes more 
> sense.
> 
> Ctrl+S: Konqueror provides Save As like specified by the guidelines and sticks 
> to it to the point. This behaviour is perfectly sensible here.
> 
> Ctrl+P: Print, same as Ctrl+S
> 
> Ctrl+Q: Unconditionally closes the whole window, whichever state it is in, and 
> only the window, not the process -> perfect compliance.
> 
> Ctrl+W: Closes a tab. However, it's not working up to the guide. As long as 
> more than one tab is open, it will close documents. But on the last tab, this 
> stops working.
> 
> According to the guide, one of the following actions should take place:
> (1) Leave the application with an empty canvas.
> (2) Open an empty document in the main-window.
> (3) Open a dialog which allows the user to select a new or empty document in 
> the main-window.
> 
> (3) can be dismissed immediately. (1) doesn't prove useful because konq is no 
> MDI application (though with the advent of tabs, it's no longer a pristine 
> SDI either), yet it'd be possible, as KDE 2.0's konqueror started with an 
> empty canvas. Leaving (2) which essentially means returning to its initial 
> state, be it the homepage, the introductory page about:konqueror, or some 
> initial directory.
> 
> But konqueror does nothing of these three actions, leading to the perception 
> that (a) the pre-tab konqueror behaviour was retained without considering the 
> guide, or (b) the guide was considered, but deemed not suitable, and for lack 
> of something better, the pre-tab behaviour was retained.
> 
> Concludingly, konqueror does not follow the guidelines here, but the current 
> solution is not sensible enough as to be content with it. Otherwise no 
> attempt would have been made to improve it.
> 
> When the guide ends, the application is on its own to determine consistency 
> and usability. Being able to close the last tab the same way as all other tab 
> is undoubtedly more consistent than the current behaviour. That closing the 
> last tab will also close the whole window is no worse than the current 
> behaviour.
> 
> Any user making use of tabs, and getting accustomed to the close shortcut 
> Ctrl+W, will expect the document to be closed. It's more disrupting that the 
> last tab cannot be closed the usual way, as if the whole window were closed. 
> Or put it another way: The user simply expects the document to be closed on 
> Ctrl+W, regardless of the count of tabs. The current behaviour is 
> non-orthogonal.
> 
> So the only task left is to decide in which way the document is closed -- 
> whether konqueror follows the style guide, and provides one of (1), (2), (3), 
> or if konqueror deviates, and performs a window close. The current solution 
> is the least consistent one.
> 
> >
> [...]
> > Global version that are hidden for the user and for new developers are also
> > a nightmare to maintain; and thats ok for some reason?
> 
> You are right, you have made up my mind. It shouldn't be configurable, it 
> should be the default.
> >
> [...]
> > Your feeling of 'inproved usability' is setteled on just feelings and not
> > on any rationale that holds for anyone but a very select set of people.
> 
> My propositions are no more or less objective than any propositions that have 
> been made by other people throughout the mailing lists, and out of which the 
> kde ui guidelines have finally been compiled.
> 
> Btw, if you have access to any scientifically conducted tab-related usability 
> study, please share them. I'm really interested in its findings.
> 
> mfg
> 	Leo
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.6 (GNU/Linux)
> Comment: For info see http://www.gnupg.org
> 
> iD8DBQE/a7WOj5jssenUYTsRAl3tAJ0ajJbSskNrPsAgmYsM1j9Dm0ascQCgnGcT
> 3wpMIHt7yXgo1j9OI8uccbk=
> =CnxO
> -----END PGP SIGNATURE-----
> 

mvg,
Alex




More information about the kfm-devel mailing list