http://lists.kde.org/?l=kde-commits&m=128292705201885

Hum, I've just tested it and it is cool. I'm reopening it however as there is apparently only a small problem left, the plot seems to be "confused" between layout and zoom mode, as if the tab that gets activated were not in layout mode and then all of the plots would not be like the others. I don't know if the button toggles the mode for all plots in a given tab, or session-wide, but maybe that's a direction to investigate. I think it's very close :-)
Thanks!

Note that while trying to get zoom to work in a moved plot I somehow managed to crash kst. I haven't yet been able to reproduce, otherwise I'll tell you but I feel it's related to that.

Sorry, I had not realized that you opened bug #249253 for that. Re-closing...

Now, I'm really confused. The first try here was actually pretty good. The only "small" problems left were:
1) that after being moved the plots inherited the wrong mode (zoom or layout) from their old parent
2) that they lost keyboard control, which led to bug #249253 and should be fixed now
3) that it was possible to drag the plots in zoom mode, which as explained elsewhere is not really desired and led to confusion due to the plot dialog opening simultaneously

In the latest snapshot (revision 1171120) I can no longer drag the plots out of their view. The last commit message hinted at that, but what confuses me is that after the first commit here it almost worked. It feels that we were once closer to the proper solution than we are right now.

But I guess this is still being worked on...

> --- Comment #4 from Nicolas Brisset <nicolas brisset eurocopter com>  2010-09-02 21:57:52 ---
> Now, I'm really confused. The first try here was actually pretty good. The only
> "small" problems left were:
> 1) that after being moved the plots inherited the wrong mode (zoom or layout)
> from their old parent
> 2) that they lost keyboard control, which led to bug #249253 and should be
> fixed now
> 3) that it was possible to drag the plots in zoom mode, which as explained
> elsewhere is not really desired and led to confusion due to the plot dialog
> opening simultaneously
> 
> In the latest snapshot (revision 1171120) I can no longer drag the plots out of
> their view. The last commit message hinted at that, but what confuses me is
> that after the first commit here it almost worked. It feels that we were once
> closer to the proper solution than we are right now.
> 
> But I guess this is still being worked on...
> 

No problems here on Kubuntu and opensuse 11.2.
You still have to start dragging by clicking on the upper-right
button where tied zoom could be enabled.

Peter

I see... 
What I don't like is that there are still 2 *major* usability problems:
1) discoverability: *nobody* will have the idea of clicking on the upper right corner, which makes sense only in zoom mode (to activate tied zoom) and we are speaking here about an action that is only working in layout mode! Since we all know close to nobody reads docs, it has to be intuitive! The first idea one gets it to simply drag the plot as you would to move it, and put the mouse cursor above the new tab. I think that's how it should work. It's a sort of continuation of the natural layout mode drag event. Why should dragging within the view be different from dragging between views?
2) unintuitive restriction: after you wrote I have to click on the upper right corner, I tried it and thought it did not work. Why? Because I tried to drop the plot anywhere in the new tab, that is within the view. And the even only gets accepted if you drag the plot to the tab itself! I think it has to be possible to drop the plot anywhere in the new view, and that even has the benefit that it allows to pre-position it where it makes most sense.

Could you maybe update back to revision 1168869 and try it there? It was pretty close to what I want reg. point 1)

> --- Comment #6 from Nicolas Brisset <nicolas brisset eurocopter com>  2010-09-03 09:43:42 ---
> I see... 
> What I don't like is that there are still 2 *major* usability problems:
> 1) discoverability: *nobody* will have the idea of clicking on the upper right
> corner, which makes sense only in zoom mode (to activate tied zoom) and we are
> speaking here about an action that is only working in layout mode! Since we all
> know close to nobody reads docs, it has to be intuitive! The first idea one
> gets it to simply drag the plot as you would to move it, and put the mouse
> cursor above the new tab. I think that's how it should work. It's a sort of
> continuation of the natural layout mode drag event. Why should dragging within
> the view be different from dragging between views?
> 2) unintuitive restriction: after you wrote I have to click on the upper right
> corner, I tried it and thought it did not work. Why? Because I tried to drop
> the plot anywhere in the new tab, that is within the view. And the even only
> gets accepted if you drag the plot to the tab itself! I think it has to be
> possible to drop the plot anywhere in the new view, and that even has the
> benefit that it allows to pre-position it where it makes most sense.
> 
> Could you maybe update back to revision 1168869 and try it there? It was pretty
> close to what I want reg. point 1)
> 

The current state is like 1168869 without breaking existing functionality.
So I think we should disable d&d until it finished.

SVN commit 1171629 by kuemmel:

Add complete drag and drop between tabs.

CCBUG:248885 

 M  +46 -0     scene.cpp  
 M  +4 -0      scene.h  
 M  +10 -22    tabwidget.cpp  
 M  +2 -0      view.h  
 M  +30 -20    viewitem.cpp  
 M  +5 -1      viewitem.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1171629

So, I've tested it and it does the job. Thanks Peter!

Since you've surely noticed in the meantime I'm rather a perfectionist, so I do have a couple of minor things I'd still like to improve/add:
1) during the drag operation you can no longer see the tabs, we need a way to indicate to the user which tab he's going to be dropping onto. I see 2 possibilities: either a small popup notification above (in terms of z order) the plot pixmap each time the mouse reaches a different tab, or some text in the status bar ("Drop onto: [tab name]"). As a side comment, we don't use the status bar enough if you ask me (see inkscape for example, I discovered a lot of things just reading the status bar)
2) the area between the axes and the border of the plot (where axis labels are) is flickering a lot during the drag operation. There must be a way to avoid this as nothing else flickers. This is just nice-to-have (while the previous point is more important), but if it's easy...
3) for discoverability as well as users migrating from kst 1.x, I think adding the copy/paste or cut/paste options through the Edit menu + the RMB action in the context menu should be done. One point we should still clear is whether the context menu should be the same in zoom mode and layout mode. I'm for some common and some different entries, but I'll detail it in a different report... For now, both are the same and we can add the action to both.

I'm reopening the bug until everything is implemented so that we can better track the status in bugzilla.

Am Montag, den 06.09.2010, 08:06 +0200 schrieb Nicolas Brisset:
> https://bugs.kde.org/show_bug.cgi?id=248885
> 
> 
> Nicolas Brisset <nicolas.brisset@eurocopter.com> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>              Status|RESOLVED                    |REOPENED
>          Resolution|FIXED                       |
> 
> 
> 
> 
> --- Comment #9 from Nicolas Brisset <nicolas brisset eurocopter com>  2010-09-06 08:05:58 ---
> So, I've tested it and it does the job. Thanks Peter!
> 
> Since you've surely noticed in the meantime I'm rather a perfectionist, so I do
> have a couple of minor things I'd still like to improve/add:

But not a perfect perfectionist ;) ou've missed some things:
- legend is not shown while dragging
- a rotated plot is not shown rotated while dragging

> 1) during the drag operation you can no longer see the tabs, we need a way to
> indicate to the user which tab he's going to be dropping onto. I see 2

Yes, when you start dragging by clicking in the middle of the plot you
are lost. Start by clicking near the upper end of the plot. 

> possibilities: either a small popup notification above (in terms of z order)
> the plot pixmap each time the mouse reaches a different tab, or some text in
> the status bar ("Drop onto: [tab name]"). As a side comment, we don't use the
> status bar enough if you ask me (see inkscape for example, I discovered a lot
> of things just reading the status bar)
> 2) the area between the axes and the border of the plot (where axis labels are)
> is flickering a lot during the drag operation. There must be a way to avoid
> this as nothing else flickers. This is just nice-to-have (while the previous
> point is more important), but if it's easy...

Never saw it, on Linux only?

> 3) for discoverability as well as users migrating from kst 1.x, I think adding
> the copy/paste or cut/paste options through the Edit menu + the RMB action in
> the context menu should be done. One point we should still clear is whether the
> context menu should be the same in zoom mode and layout mode. I'm for some
> common and some different entries, but I'll detail it in a different report...
> For now, both are the same and we can add the action to both.

I also thought about disabling the layout specific entries when we are
in the data mode.
> 
> I'm reopening the bug until everything is implemented so that we can better
> track the status in bugzilla.
> 

Wasn't is still open?

- to some items not being visible during drag: OK, I admit I have tried it only with non-rotated plots, and without legend shown :-) As it seems from a few quick tests, if there are objects in the plot (not just the legend, but annotation objects as well) they are correctly moved with the plot but you don't see them while dragging. I don't know if it's easy to fix, otherwise I'd almost suggest drawing only the plot outline (only the rectangle border) while dragging. That would allow to see tab names the whole time, and avoid confusing the user as to what is moving along with the plot or not...

- to the flicker: yes, on Linux without OpenGL, which is broken - I only gets millions of lines like: "QPixmap::scaled: Pixmap is a null pixmap". I've just tested 2.0.1-beta2 on Windows without OpenGL (OpenGL even crashes here!) and it is indeed OK.

Flicker: Maybe because of using Qt 4.5. Recently I've installed the Qt SDK with 4.7 as non-root: http://qt.nokia.com/developer/qt-qtcreator-prerelease#download

This is really cool!  I agree that if you grab the plot near the top left (which is a perfectly fine place to grab), then there is no problem navigating the tabs.  So I don't think we need transparent plots while dragging.

I am a little worried about discoverability, but don't have any ideas on how to make it more discoverable.

I confirm flicker when dragging (it appears to be the default background grey) and un-drawn annotation objects.)   Linux Qt4.7, kde 4.5.1.  

So: I am going to open a new bug for the flicker, and consider this one closed.

This is really cool!  I agree that if you grab the plot near the top left (which is a perfectly fine place to grab), then there is no problem navigating the tabs.  So I don't think we need transparent plots while dragging.

I am a little worried about discoverability, but don't have any ideas on how to make it more discoverable.

I confirm flicker when dragging (it appears to be the default background grey) and un-drawn annotation objects.)   Linux Qt4.7, kde 4.5.1.  

So: I am going to open a new bug for the flicker, and consider this one closed.

About discoverability: I think it's not so bad. Going to layout mode seems natural, then the only thing which is not obvious is pointing on the destination tab (especially when the plot covers it!). We should show it in a tutorial (screencast) and then there is this public discussion and Google :-)

In any case, I think we'll need to add a "Move to" option in the plot context menu, at least in layout mode. I have some ideas for the context menu which I'm planning to report in a new bugzilla wishlist entry, but we already have the changes to the plot dialog under work and I don't want to have everything open in parallel. They're independent so I'd like to finish the revamp of the plot dialog first, before moving on to the plot context menu.

These bugs are solved with 2.0.0