#141 Drag'n Drop BufferTabs

Todd Gerspacher
0 up votes | 0 down votes | 0%

Updated BufferTabs plugin so that tabs can be dragged and dropped.


<< < 1 2 3 (Page 3 of 3)
  • Alan Ezust
    Alan Ezust

    > Todd submitted a patch having a given functionality in mind.
    There was no new functionality at all introduced by the first version of this patch. DND on the same editpane already works and does the same thing before or after this patch - it just doesn't show you the nice icon while you are dragging.

    The second version of the patch does introduce new functionality and it's buggy - redefines what an "invalid drop area" means in drag and drop terminology, and confuses the user as to what to expect when the mouse button is released. Those two reasons are why I am rejecting it.

    If the patch actually did something useful, I'd accept it, but currently it does nothing useful (yet).

    When it does work, it should allow dnd for a single editpane only when buffersets are not sorted, and otherwise FORBID the drop.

    It should also allow dnd from one editpane to another, and move the buffertabs between them, but only if the bufferset scope is editpane.

    Matthieu's request is for drop outside a view, to create a new view. That would be nice too and it is not implemented in this patch yet.

    And my request for dnd between views (when non-global bufferset scope is in use) would be a nice thing to have too.

  • I think the idea to see the destination of the tab being moved is worth introducing. Although personally I don't like the big icon which obscures background. I vote for accepting the original patch, if the reviewer accepts all the coding style.

    Alan, that's the way we do things. Partially and with well separated pieces. Like that:
    1. introduce drag and drop using java.awt.dnd
    2. use glass pane to mark the insertion
    3. support dragging to another pane
    Todd joined 1,2. It's enough to merge 2 functionalities in one patch. I guess 3 is not possible without 1, so applying 1 seems necessary to achieve your goal.

    > I could have made separate classes for
    >them, but that would have been unnecessary and made the code even more
    >complex than what it already is.
    Function bodies should be no more than one screen long. That's one of the rules of readability. There are necessary exceptions, but in this case, it's not at all necessary to make the constructor 5 screens long.
    We may differ in the opinion on anonymous classes' readibility and complexity. But it's a fact, that they make code impossible to browse with sidekick.

    >I'm sorry, if I don't use the same indentation as you.
    Don't be. Just adjust to the rules that are in use in the file you edit.

    • status: open-rejected --> open
  • Alan Ezust
    Alan Ezust

    I just added a tabSize=4:indentSize=4:noTabs=false: to the top of each source file in buffertabs in svn.
    Jarek, if you want to accept a version of the first patch, that's ok with me. I'm sure you'll ensure it is cleaned up before you accept it.
    My original feature request is #2108386, in case anyone is interested.

  • Alan Ezust
    Alan Ezust

    • assigned_to: ezust --> jarekczek
    • assigned_to: jarekczek --> nobody
<< < 1 2 3 (Page 3 of 3)