Do not hide "moving"-buttons
If dragdrop is not installed there are buttons to move a Content Element up and down as long as there are other CEs.
If dragdrop is installed they are not visible anymore.
I think this should not be the case as there are some users who prefer the buttons for fast reordering (one click is sometimes faster than one click plus moving plus drop) and drag and drop only for column changes or more complex reordering.
#2 Updated by Hauke Hain almost 8 years ago
Here is the second part of the patch.
I removed the cloning of the header. As a result the move-buttons are correctly shown. I do not understand why you cloned the header anyway.
Next: onComplete I reload the page, so that the move-buttons have correct links.
#3 Updated by Armin Vieweg almost 8 years ago
Hey, first thanks to your engagement!
I'll check your patches asap.
The reload of the page is a circumstance I would like to avoid very much!
The reason why I clone the links, is because they are not clickable in IE9 and also in Chrome appeared some flaws. The scriptaculous sortable seems to be very restrictive (in private: I like jQuery much more ;-)).
#4 Updated by Armin Vieweg almost 8 years ago
After I have slept on it, I'm not sure if it is really useful, showing the move-buttons. The only reason these buttons are existing is that at that time it was not so easy as today, making drag&drop possible. But the users are trained using drag and drop from the beginning of graphical user interfaces.
i.e. in Windows 95 there were no buttons to change the order of icons, you had to do it by drag and drop.
I think this should not be the case as there are some users who prefer the buttons for fast reordering (one click is sometimes faster than one click plus moving plus drop)
I'm not sure if this feature excuses the complexity.
The reload in your patch is not acceptable for me. If we implement this feature, then with an ajax request and update of the move buttons.
What's your opinion?
#5 Updated by Hauke Hain almost 8 years ago
Interesting. I use Iron instead of Google Chrome to test Chromium and with the patched solution I did not notice anything weird. However, IE9 does not work as described in #34761.
#6 Updated by Armin Vieweg almost 8 years ago
I'll check it. To reproduce the flaw in chrome (or iron), just go over a link (toggle visibility, i.e.) and press it, but don't release the mousebutton. If the opacity reduces, you'll see the flaw. Reducing the opacity is a feature when start dragging a sortable, but if I want to click on a link this is not the expected behavior.