short w_putselection(char *type, char *data, long length, short lock);
Will send the 'data' data of 'length' length to clipboard under 'type'
identification. `Lock' should be set when another program asks for the
data. It will prevent other programs from (accidentally) `corrupting'
i.e. overwriting the data. Returns NULL for failure.
Will get clipboard data with 'type' identification. Returns the
acquired clip or NULL if requested failed. If `unlock' is set, will
free the write-lock on the clip. This should be used when reading
data that was requested from another program.
Frees the memory allocated for the clip by the w_getselection() call.
Will open a clip of type `type' and return handle to clip or NULL.
Will append data into earlier opened clip.
Closes and flushes an earlier opened clip.
Copies the specified image block into clipboard. Returns NULL for failure.
Pastes the image from clipboard into the specified place. Returns NULL
for failure.
Returns the clipboard image information (size and window pointer (for
w_getblock())) or NULL if clipboard is empty.
There could be `priorities' attached to clips so that clipboard server would notify other clients (through W messages, see below) about receiving clips above certain priorities.
Clipboard images (stored on W server so that using them is faster) need some additional code to the W server. They would be stored in a hidden window.
A separate clipboard server could also have a W interface so that user can manipulate the clips (show, copy, delete them).
Clipboard open, append and close functions would probably be implemented completely in the W library. W_SEL_TEXT would be the `default' clip type and should be used exclusively for visual text copy / paste operations. Clients which don't translate '\t' or '\n' should either ignore or convert to spaces values that are smaller than 32, not just `show' them (fonts might have null width chars on those positions and that will disrupt window offsets for fixed width font programs).
Client specific clip types should include a little identification string, for example: "Word.rtf", "Word.pbm". Client could also provide a more generic version of it's clip for pasting into other apps.
Messages will be given to clients as 'EVENT_MESSAGE' events. The WEVENT structure will be filled like this:
win: window (from w_msgwin()) type: EVENT_MESSAGE x: message ID y: optional message information key: sender ID (for w_toClient())
Except for broadcasts (which should be enough for starters), the messages will need a receiver. Therefore clients that can accept messages, will have to register themselves.
void w_register(char *name, char *category, long version);
Registers the client with given attributes. Usually done right after
w_init().
Sends the message to all the registered clients in 'category' category.
If 'category' is NULL, will send message to all registered clients.
Returns number of clients (or maybe just non-zero if there were clients)
to which message was sent.
Returns the ID for the first client registered with given name. Clients
whose version number is smaller than the given one, will be ignored. If
client wasn't found, returns zero.
Sends a 'msg' message to 'id' client. Returns zero if given client
wasn't registered.
Sends message to the client owning the window at position (x,y). This
function is vital for drag&drop implementation.
void w_register(char *name, char *category, long version);
Server should have some new CLIENT structure members for storing the
client name, category and version. The name strings could be limited to
16-32 characters and category to same length as the clipboard types.
The id is the CLIENT structure pointer/id.
Search the window that is visible at the SCREEN (x,y) co-ordinates and
then send it's owner a message WEVENT with this window id. Other
messages could use WROOT as their WEVENT 'win' member.
This would also need sub windows (icons) to be movable out of their parent window(s).
Changing the W Toolkit widgets to use a server clipboard instead of the toolkit one would be easy to fix, but handling the messages would need a bit more code. Maybe wt_top_class could be setopt() with application registration values and message handler callback? These would take effect immediately.
If there's a lot of data to move (continuously) between specific applications, they should use Wserver just for contacting each other for an exchange of socket addresses and further on do all their communications by direct contacts. All this could probably be handled transparently with a special W Toolkit widget?