BACK UP your modules before editing them with the test builds.
Mostly I recommend you test on “throwaway” copies of your modules, albeit “the temptation will be great”.
Features/Branches to be tested:
(1) “Drag and Drop” for Editor items – look for the latest “DraggyDroppy” build at vassalengine.org/builds/ and install it. It should allow you to “drag and drop” items all around your module! It will also support Ctrl-Drag (that’s Cmd-Drag on Macs) to make copies of items in various places. The kind of testing needed is –
(a) That both “move” and “copy” modes basically work
(b) That it doesn’t let you drag something “where it doesn’t belong” (wrong kind of parent, or drag a parent to its own child, that kind of shenanigans)
(c) That it doesn’t make items disappear never to be seen again! (I don’t think it will, but remember, I did warn you…)
(d) No stupid stuff like throwing exceptions and eek-a-bugs
(2) Duplicate-in-Place and Insert-New-Below for Editor items – look for the latest “14372” build and install it. In this branch, right clicking on an item in the Editor window should give you new “Duplicate” and “Insert-new-item-below” options. The first makes a copy of the item you right clicked and inserts it below the item; the second makes a “brand new item of the same type” (but not a copy of the first) and inserts it below. This one’s less complicated than the one above, but still needs testing.
Thanks Brian! I’ve tried twice to answer here but neither post seems to have been successfully submitted. Briefly, on my MacBook Pro the first, “DraggyDroppy”, drags worked fine. Command-Drag did not work for me. Control-Drag did, but also displayed the contextual menu at the same time, which is obviously confusing.
The second Duplicate and Insert New Below functions both worked well for me.
Thanks so much! It’s fascinating that it needed Control-Drag, since this uses Java AWT’s built-in drag-and-drop support. I would have expected Cmd-Drag – but it’s very good to know what the real situation is, for creating the documentation.
I tested everything in various ways that you mentioned and everything appears to be working fine.
I found the Duplicate-in-Place command operated in an odd fashion but that could also just be my own sense of logic. When I used it, it duplicated an item and opened the item for editing. I didn’t want to edit anything so I just hit Cancel and it disappeared. What I was expecting was for it to just copy the item and then I would open if I wanted to edit it.
Like I said, maybe that’s just me. I don’t know what the general consensus would be on that.
Since adding a component the old way opens it automatically for editing, we have decided to keep it the same for consistency. Any new component generated by a menu selection will then open new component for editing. If you are Duplicating an item, you probably want to change at least its name anyway, or just hit Ok to save it as is.
You are also getting Drag and Drop with the Ctrl-key as an option to make a copy of a component and (at the moment), that doesn’t open the new component for editing. Not sure if that is good or bad.
Both of the above features are now (together) in all future 3.6 snapshot builds, in addition to ANOTHER feature that needs your testing:
(3) FOLDERS - you can add subfolders to your Module, your Maps, your Decks, and to the [Global Properties] and [Game Piece Prototype Definitions] folders. The folders can contain many/most of the items that their parents can contain (including additional levels of folder), and should be useful for organizing e.g. your At-Start Stacks, Global Key Commands, Prototypes, Properties, or whatever.
All the “master” snapshot builds from here forward (including 60bd15c made this morning) include all 3 of these features working side by side.
So far, only tested with folders in prototypes, but here’s a couple of early observations:
Request- for drag/drop in particular, it would be nice if the editor could support standard group select functions (on Mac; Shift+LeftClick for adjacent, Cmd+LeftClick to select/de-select individual items irrespective of adjacency)
Bug/Feature (Drag & Drop)… Great that folders open up after a short delay and that no-entry sign pops up when a drag is hovered over an incompatible location (plus you can’t drop into such a location, of course). However, should a “no entry” location open up ? Is that a useful/necessary thing ?
It’s not possible to Add a “Help Menu” or “Global Options” so is it right that the the Editor allows these types of container to be Duplicated ?
Replicate this observation for other containers in the same category, if any.
“Global Properties” is another example and in this case might have had a plausible justification (to replace another map’s Global Properties) but that opens up the possibilities of duplication… and, in fact, a GP container (top level) can not be pasted into another map. “Global Properties” folder should probably also not allow Duplication, is my guess.
When a component is dragged to an incompatible target, a diagonal line in a circle appears (I call this a “no-entry” sign for now).
If the incompatible area (folder) is allowed to auto-open, the contained targets do not give the no-entry sign, even though dropping the item will, as expected, terminate the action with no effect. On the other hand, if the incompatible folder is already open before the drag/drop, then no-entry sign will appear on all contained, incompatible targets.
Suggest
The “no-entry” icon should appear when component (folder) contains no valid targets, and that folder should not open up. Then if a folder/component opens up it can be taken to indicate that one or more valid targets exist within that container.
Whether or not a folder opens up during drag/drop or is already open, the no entry sign should appear on any of its incompatible contents in response to drag/hover
“Insert” should operate in the other direction (up) … at least that seems more intuitive to me.
More objectively, inserting below means that to insert at the top of a list will require two operations (insert and move); whereas insert above, still leaves a way to add a component to the bottom of a list in a single operation (e.g. Add Definition from the Prototypes folder, just as in earlier Vassal versions).
Did anything change since this post and the one that prompted it?
Cmd + Drag was working for me… I will re-test later to check.
So far, I have tested by creating several Global Property and Prototype folders at module level, then saving and refreshing a scenario. No errors except for one crash (reported on a separate thread). Game functions have continued to work fine so far. I am just doing a mass refresh and will continue testing with map level components.
Pushed a new PR that will make “insert” be before-the-item.
I suppose I need to come up with a list of items that should not be allowed to be duplicated.
Glad to hear Cmd+Drag worked right. That’s much more like what I would have expected the Mac experience to be.
The stuff with the auto-opening of items on hover seems to be a “built into Java AWT” thing. I suppose we could try to research it but presently it seems like “the black box of the java drag-and-dropper at work”.
So after reading the above note from marktb1961, I wondered if I was more hallucinatory than usual. So I pulled down the latest macOS version 3.6.0-SNAPSHOT-c867c45-DeeperDeckDooDoo, and opened my hobby vmod. I get the same results as before. Command-Drag did the same thing as click-and-drag, moving objects to different locations, but not duplicating. Control-Drag duplicated the items at the destination, but opened the context menu as well.
macOS Big Sur 11.3 Beta 20E5231a
MacBook Pro 16 inch, 2019
2.3GHz 8-ore i9
16 GB RAM
I did have a nagging doubt that I hadn’t tested Cmd+LeftDrag quite right. I hadn’t, I confused the expected operation with an ordinary drag. When I went back v3.6 builds, I found that Cmd+LeftDrag makes no difference (does same as a drag with no key press, so far as I can tell).
Sure enough, Control+LeftClick does what imikem observed and it is an example of why no app should be using Control+LeftClick on a Mac…it is the original MacOS “right-click” and there is nothing an ordinary Mac user can do to alter that.
One perhaps useful thing I did find out; Option+LeftClick also does there copy+drag.
It seems odd that Control+Drag is “working” and Cmd+Drag is not; even though Option+LeftClick works, Control+LeftClick should not be doing anything; the OS (I think) will treat it as a right-click anyway.
Well, I guess “Option+LeftClick” better be what we put in any documentation for the Mac version of this then! All the Mac support on this feature is down inside the “Java AWT” Black Box.
@ imikem, after some research and discussion with Brian, we’re convinced the Control+Click problem is a Java-related issue. The bug report I found (above) is in the same ballpark but I’ve logged another specifically on the issue that this part of Java does not understand the Control+Click is special on MacOS and, if I’m not mistaken, should not be used directly (the OS will present it as RightClick anyway).
Also, Option+Click seems to work, I hope you will find.
Thanks everyone. I can confirm that Option*-Drag creates a duplicate as described, and avoids the ugliness of showing the context menu while dragging the object.