Bug 187895 - Konq should use Qt 4.5's movable tabs....and use CTRL + Drag to copy a tab... copying shouldn't be default..
Summary: Konq should use Qt 4.5's movable tabs....and use CTRL + Drag to copy a tab......
Status: CONFIRMED
Alias: None
Product: konqueror
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR wishlist
Target Milestone: ---
Assignee: Konqueror Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-03-23 02:01 UTC by Shaun Reich
Modified: 2010-01-31 02:56 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Shaun Reich 2009-03-23 02:01:04 UTC
Version:            (using Devel)
OS:                Linux
Installed from:    Compiled sources

Could you please make konqueror use Qt 4.5's QTabWidget::setMovable(true) property.... I am not sure how easy it is to intercept these calls (probably be difficult or not possible). But it should use this to drag tabs, instead of obsolete code in KTabWidget (or Bar can't remember totally). This way it looks very cool... and it will fit in with other KDE applications, it would also set dragging as default... who wants to copy tabs as the default? Or paste them into other tabs by default? That is a bad default setting I think, bad for usability...

Holding control should make this feature copy the tab also, like expected...
Comment 1 Shaun Reich 2009-03-23 02:52:27 UTC
I mistakenly used the word "usability", what I meant, I think, was standardization, at least with other applications, and the rest of the mouse-using KDE.

Let me explains this wish furthermore, since I kind of flew through it while trying to report other bugs before I would forget them...

Originally, before we had LMB dragging (which is what qt4.5's feature brings), we used Middle Mouse Button dragging. Not only was this buggy, it was very conflicting (especially since certain applications use MMB for closing tabs). It was buggy in the aspect that you could usually only drag it one tab over, then have to do the MMB click again...

This presents a few problems:

a.)Not many people have a middle mouse button
b.)If they do have a middle mouse button, it is usually difficult or unfun to use, and sometimes leads to unintended scrolling of tabs.
c.)Left-clicking = dragging is natural and native to most users.
d.)MMB clicking is, on iirc, most applications, to close the tab.

To support point C, do you drag folders and files, windows and scrollbars, icons and others with your middle mouse button? No, that's because it doesn't make any sense. So what is the reasoning behind having MMB dragging anyways?

The average user would probably expect to be able to drag tabs, by the left mouse button. Ok, so he drags the tab next all the way to the right.. "oh, well that's dumb, all it does is copy the tab" Most likely, what I am thinking, is how will the user ever figure out how to drag tabs. I for one, didn't know I -could- drag tabs until someone mentioned it on IRC, and I was like "you -can- drag tabs?!"

Let me know if I require a further explanation, this may not be sufficiently detailed...?.
Comment 2 Iñaki Baz Castillo 2009-06-06 19:04:55 UTC
I fully agree with you.
Comment 3 Grósz Dániel 2009-12-27 04:50:01 UTC
You are right in that users might expect lmb dnd to work but from KDE's perspective the current behavior is the logical and consistent one:
- dragging a tab means dragging an URL
- dropping an URL on a tab makes that tab open the URL.
Deviating from this behavior just because the source and the target application is the same would be an inconsistency.
Comment 4 Iñaki Baz Castillo 2010-01-30 18:36:37 UTC
(In reply to comment #3)
> - dragging a tab means dragging an URL

Really? Who does expect that? a common user??

> - dropping an URL on a tab makes that tab open the URL.
> Deviating from this behavior just because the source and the target application
> is the same would be an inconsistency.

IMHO nobody expects that dropping a URL on an existing tab should replace the tab content.

Your comment explains how KDE/Konqueror works until now. The report suggests to change the current behavior (unexpected behavior).
Comment 5 Grósz Dániel 2010-01-30 19:11:43 UTC
#4: What should then dragging a tab do? And what should dropping an URL on a tab do? In my opinion removing the described behaviors would be a loss of features without creating any new feature. Both features I described are present in other browsers (at least Firefox) too and they are useful for dragging URLs to other places and to load pages in a tab.

It is true that altough the middle click drag feature is present, users might not discover it. A dialog could clarify the difference between LMB and MMB drag when the user starts to drag a tab for the first time, of course with "Don't show this again" checked.
Comment 6 Iñaki Baz Castillo 2010-01-30 20:13:26 UTC
(In reply to comment #5)
> #4: What should then dragging a tab do?

Move it, as in any other web browser (Firefox, Opera, Chrome, IE).


> And what should dropping an URL on a tab do?

No one common user wants to "drop" an URL on a tab. The fact that KDE allows it doesn't mean that it's a useful feature for users. Again you are focusing on KDE features/capabilities rather than on real usability.
Do you think that a Mac (the most usable OS) user needs to "drop an URL on a tab"?
It's true that Firefox allows it, but dragging a tab with left mouse moves the tab.

> In my opinion removing the described behaviors would be a loss of
> features without creating any new feature.

IMHO it means replacing an unexpected behavior with an expected and common behavior (moving a tab).


> Both features I described are
> present in other browsers (at least Firefox) too and they are useful for
> dragging URLs to other places and to load pages in a tab.

In Firefox when you drag a tab with left button you are moving it. In Konqueror not, instead the destination tab becomes a copy (it loads the same URL) which is 100% unexpected (even for me after 5 years using KDE).


> It is true that altough the middle click drag feature is present, users might
> not discover it. A dialog could clarify the difference between LMB and MMB drag
> when the user starts to drag a tab for the first time, of course with "Don't
> show this again" checked.

I think that showing a dialog window is not the best solution for all the usability problems. Consistent and expected default behaviors are required in any decent system.

So, we have the following:

1) Dragging a Konqueror tab means dragging an URL.
2) Droping a URL on a tab makes it to load that URL.

IMHO point 1 is wrong. If I take *anything* with the left button I want to move it (this is valid for an icon in the desktop, a circle in a SVG picture, a song in Amarok playlist...).
So I suggest that dragging a tab in Konqueror means "moving it" as in any other browser.
Comment 7 Grósz Dániel 2010-01-30 21:50:55 UTC
(In reply to comment #6)
> > #4: What should then dragging a tab do?
> 
> Move it, as in any other web browser (Firefox, Opera, Chrome, IE).
> In Firefox when you drag a tab with left button you are moving it.

I mean what should dragging a tabn do generically, that is, when it is dragged to e. g. an other application? In other web browsers too when a tab is dragged to an other app, or inside an other tab, or into an other widget in the same application, or to anywhere other than to an other position on the same tab bar, the URL is dragged. This is an important feature which makes it possible to insert the address in text boxes and file dialogs and open the page in other apps (other web browser, editor, anything).
So if dragging it in the same tab bar does not work as if the URL was dragged, it is not a rule but an exception to the rule, which means that it is inconsistent.

> Mac (the most usable OS)

According to whom? And most usable to whom? If it is the most usable, why do we use KDE? I think because its UI is far superior.

> Do you think that a Mac (the most usable OS) user needs to "drop an URL on a
> tab"?

They don't need it ; we don't need it either because there are other ways to load an address in a tab. But the fact that it is not necessary to us does not mean that it does not make things sometimes easier.
Comment 8 Iñaki Baz Castillo 2010-01-30 22:12:44 UTC
(In reply to comment #7)
> I mean what should dragging a tabn do generically, that is, when it is dragged
> to e. g. an other application? In other web browsers too when a tab is dragged
> to an other app, or inside an other tab, or into an other widget in the same
> application, or to anywhere other than to an other position on the same tab
> bar, the URL is dragged. This is an important feature which makes it possible
> to insert the address in text boxes and file dialogs and open the page in other
> apps (other web browser, editor, anything).
> So if dragging it in the same tab bar does not work as if the URL was dragged,
> it is not a rule but an exception to the rule, which means that it is
> inconsistent.

I understand what you mean. However please clarify: do you mean that the current behavior in Firefox, IE, Opera and Chrome is inconsistent? are all those browsers and their users wrong?
Sometimes an exception could be the expected behavior.

 
> > Mac (the most usable OS)
> 
> According to whom? And most usable to whom? If it is the most usable, why do we
> use KDE? I think because its UI is far superior.
> 
> > Do you think that a Mac (the most usable OS) user needs to "drop an URL on a
> > tab"?
> 
> They don't need it ; we don't need it either because there are other ways to
> load an address in a tab. But the fact that it is not necessary to us does not
> mean that it does not make things sometimes easier.
Comment 9 Grósz Dániel 2010-01-30 22:35:35 UTC
> I understand what you mean. However please clarify: do you mean that the
> current behavior in Firefox, IE, Opera and Chrome is inconsistent? are all
> those browsers and their users wrong?

I'd rather say that these browsers are not part of a desktop environment in such a way as Konqueror is part of KDE where consistency both in the application and in the interaction between the applications is of much value.
Comment 10 Grósz Dániel 2010-01-30 22:40:37 UTC
An addition to #9:
Today's web pages are less compatible with Konqueror's rendering engine than with that of other browsers (I hope this will be solved by WebKitPart someday); it has much less extensions than Firefox. IMHO its only one, but very important value is the integration of KDE's technologies - consequently its users are mainly those KDE users to whom consistency is especially important.
Comment 11 Iñaki Baz Castillo 2010-01-31 01:08:50 UTC
(In reply to comment #9)
> I'd rather say that these browsers are not part of a desktop environment in
> such a way as Konqueror is part of KDE where consistency both in the
> application and in the interaction between the applications is of much value.

I've been user of KDE from 5-6 years ago. I use it at home and at work (both KDE3 and KDE4). I mostly use KDE applications (Konqueror as web browser, Kmail/Kontact, Kopete, Kate, Yakuake, Ktorrent, akregator...), I don't use Firefox, neither Thunderbird, Gaim or other non-KDE applications.

I really would like to know what you mean with "consistency". I can't understand how the current tab behavior of Konqueror (dragging a tab with left button clones the link rather than moving the tab) is "consistent". I've never expected it, never, even using most of the KDE applications implementing tabs somewhere (kopete, Yakuake/Konso

Could you please open Kmail (in KDE4), create some tabs in mail list view and drag a tab with left button? YES, you are moving the tab rather than cloning its content to the destination tab!!
Could you also open Konsole (in KDE4), create some tags and drag one of them with left button? YES, again you are moving it rather than clonning the current content of the tab!
Are Konsole and Kmail "not consistent" then? really? IMHO Konqueror is the "exception to the rule".

So, in my opinion:
- A tab is a tab, not a link.
- Dragging *anything* with the left button means *moving* it (in 99% of applications of any OS).
- So dragging a tab in Konqueror with left button should move it.
Comment 12 Grósz Dániel 2010-01-31 01:31:52 UTC
> I really would like to know what you mean with "consistency". I can't understand how the current tab behavior of Konqueror (dragging a tab with left
button clones the link rather than moving the tab) is "consistent".

It is consistent with the effect of dropping on a tab the thing which is dragged when we start to drag a tab.
Comment 13 Iñaki Baz Castillo 2010-01-31 01:44:51 UTC
(In reply to comment #12)
> It is consistent with the effect of dropping on a tab the thing which is
> dragged when we start to drag a tab.

Please, don't forget to explain how consistent or inconsistent are Kate and Kmail (in KDE4 where dragging a tab with left button moves it rather than cloning it content).
Comment 14 Grósz Dániel 2010-01-31 02:07:15 UTC
Actually I don't get how to have tabs imn KMail and movable tabs in Kate but unfortunately there are several inconsistencies between the tab management of different KDE applications. By the way I am not saying that changing the Konqueror tabs' LMB drag behavior to moving is evil or that it should be out of question, just that it is not really logical.
Comment 15 Iñaki Baz Castillo 2010-01-31 02:15:17 UTC
(In reply to comment #14)
> Actually I don't get how to have tabs imn KMail 

In Kmail 1.12.1 (and probably bprevious versions) you can adds tabs for the mails list window by clicking in the icon of "new tab" (same icon as in Konqueror).


> and movable tabs in Kate 

Ctr+Shift+N creates a new tab in Konsole. Then you can move them dragging with LMB.
Please try it with Kopete as the visual effect is really nice (even better than in Firefox).


> but
> unfortunately there are several inconsistencies between the tab management of
> different KDE applications.

Sure, there are apps in which tabs are not movable (Ktorrent, Kopete, Akregator...).


> By the way I am not saying that changing the
> Konqueror tabs' LMB drag behavior to moving is evil or that it should be out
> of question, just that it is not really logical.

I do consider it logical. Remember what the original reporter said:

------------------------------------
c.)Left-clicking = dragging is natural and native to most users.

To support point C, do you drag folders and files, windows and scrollbars,
icons and others with your middle mouse button? No, that's because it doesn't
make any sense. So what is the reasoning behind having MMB dragging anyways?
------------------------------------
Comment 16 Iñaki Baz Castillo 2010-01-31 02:16:56 UTC
(In reply to comment #15)

> Ctr+Shift+N creates a new tab in Konsole. Then you can move them dragging
> with LMB.
> Please try it with Kopete as the visual effect is really nice (even better
> than in Firefox).

Sorry, I mean "try it with Konsole".
Comment 17 Grósz Dániel 2010-01-31 02:35:03 UTC
> So what is the reasoning behind having MMB dragging anyways?

Most probably it was that LMB drag already has an other function. What I find illogical is not LMB to move tabs but LMB not to do what it currently does in this case.

Indeed, dragging tabs is moving in mist apps but in Konqueror it needs to be dragging the address because not being able to do so would be inconvenient.
Comment 18 Iñaki Baz Castillo 2010-01-31 02:49:09 UTC
(In reply to comment #17)

> Indeed, dragging tabs is moving in most apps but in Konqueror it needs to be
> dragging the address because not being able to do so would be inconvenient.

Why?? so is it also inconvenient in Firefox, Opera, IE, Chrome and any web browser? why should it be so different in Konqueror?

IMHO you are justifying the current behavior because "it's the behavior until now".
Comment 19 Grósz Dániel 2010-01-31 02:56:59 UTC
If you drag a tab to anywhere else except the tab bar, it drags the URL in other browsers too so it is not inconvenient. What would be inconvenient is dropping this behavior altogether; what would be illogical IMHO is changing it when and only when the target is the same tab bar (although this is not unheard of either: what came in my mind is that dragging a selected text moves it in the same text box and copies it when it is dragged out of the text box).