Clipboard is for transferring data between applications (though it is possible to create other "Clipboard"s, and at least in Java they are used to implement Drag-and-Drop - but, what you do internally is ). It's sad that EVNEW only supports one item on the clipboard at once, I guess I wasn't thinking enough. But MC's clipboard format (which I think supports multiple), and RezEditor's if I use a different one, would be useful.
One idea: I could have a script command to avoid creating a temporary file:
... although, the clipboard is invalidated when process ends so I couldn't get it back.
In Java you can receive events when a new type of data is on the clipboard, but not when just new data is, so I can't keep updated that way... though I can also detect losing being the "clipboard owner", I guess. But even if I could, there's no saying there isn't lag such that the sending program exits before putting the stuff on the clipboard.
I guess --clipboard could have a contract, say, "write a byte to stdout when done editing stuff, then read a byte from stdin before exiting" since I expect you don't use those otherwise (stderr, of course, is not part of any contract). Or it could require special signatures if you need them otherwise. I guess your output could have a few op codes, CANCEL/UPDATE/EXIT
It's your call, worst case I can always create a temp file. You know, come to think of it, a temp file would be a much saner and simpler way to do things.
But, just having a clipboard to allow the user to manually "update from clipboard" / "send updates to clipboard".
We wouldn't have nearly as many points of discussion if you were writing in Java, since I could just load it into my VM.
But I know how much of a pain the Java GUI libraries are. Though, I was needing to dynamically generate things, or at least manually generate a lot, you could probably bear to get some basic buttons with listeners and then use Java2D to draw the map and a MouseListener and MouseMotionListener to do editing. (It still seems foreign to me to have an event pushing system instead of having to poll for them; you have to remember not to do anything expensive in the listeners so as not to freeze all of your other windows, which practically requires a good understanding of multithreaded programming)
But, again, your call. Whatever API you know, use. Though I don't recommend SDL for this type of thing; you probably will want something that can pop up new windows. Also, SDL without a C++ wrapper is a pain.
Also, that version of ResourceDataOffsets.java is out of date, though I haven't actually filled in the syst resource, but it's not hard now that I'm competent in C++ and passingly familiar with the EVNEW source, and besides, right now I really want resources in terms of streams instead of absolute offsets (I'm working on a script to do the conversion automatically, when that part is done the files will be easily editable so people can correct them); that file is meant to aid in creating GUIs manually, e.g.
import static ResourceDataOffsets.bööm;
Window wnd = new Window(data);
wnd.addNamedShortField("Frame Advance", bööm.FRAMEADVANCE);
Eh, I don't want to clutter your thread with these things. Write a program, and I should be ready to deal with it. If you want help understanding stuff or planning stuff that would be clutter to users, either PM me or ask me for my gmail to chat or, if applicable, post in my thread, which is plenty cluttered. One of these days I'll release something meaningful and declare RezEditor a beta, just so I can meaningfully make a new thread.