nanogui: clipboard support?


Previous by date: 12 Aug 2000 06:57:45 -0000 header dependency of scrollbar thumb for 0.88pre11, 曾昭明
Next by date: 12 Aug 2000 06:57:45 -0000 Re: License issues, Alex Holden
Previous in thread: 12 Aug 2000 06:57:45 -0000 Re: clipboard support?, Greg Haerr
Next in thread:

Subject: Re: clipboard support?
From: Alex Holden ####@####.####
Date: 12 Aug 2000 06:57:45 -0000
Message-Id: <Pine.LNX.4.04.10008120738420.569-100000@hyperspace.linuxhacker.org>

On Fri, 11 Aug 2000, Greg Haerr wrote:
> My take is that this kind of thing should probably hit client-side
> libraries if possible for now, although I have to admit I haven't
> thought enough about it yet.  Another possibility would be to put
> it in the nanowm window manager.

I did look at it at one time, studying how various different windowing
systems implemented it. My conclusion was that the simplest and cleanest
way to go is to have something similar to X, where a window registers
itself as the current owner of the "selection", giving a list of possible
data types which it can supply the clipboard contents as. Another
application (or the same one even) can then request the ID of the window
which currently owns the selection and what data types the selection can 
be supplied as, then request the data from the window in the desired form.
The window which owns the selection gets an event informing it of the
request, and uses another call to send the data to the requesting window
(which receives the data in the form of a set of events). I also sketched
out a drag and drop API which used the same mechanism as the selection
support for data transfer. It's quite different to the way X does it as X
has no built-in drag and drop support, but is much cleaner and easier to
use.

Here is what I came up with:

/**
 * GrSetSelectionOwner:
 * @typelist: list of mime types selection data can be supplied as
 * @owner: the ID of the window to set the selection owner to
 *
 * Sets the current selection (otherwise known as the clipboard) ownership
 * to the specified window. The typelist argument is a list of mime types which
 * the window is able to supply the data as. At least one type must be
 * specified (typically text/plain for plain ASCII text or text/uri-list for
 * a filename). Specifying an owner of 0 disowns the selection.
 *
 * The window which owns the current selection must be prepared to handle
 * SELECTION_LOST events (received when another window takes ownership of the
 * selection) and CLIENT_DATA_REQ events (received when a client wishes to
 * retreive the selection data).
 */
void
GrSetSelectionOwner(GR_CHAR *typelist, GR_WINDOW_ID owner)
{
}

/**
 * GrGetSelectionOwner:
 * @typelist: pointer used to return the list of available mime types 
 * @Returns: the ID of the window which currently owns the selection, or 0
 *
 * Finds the window which currently owns the selection and returns its ID,
 * or 0 if no window currently owns the selection. A pointer to the list of
 * mime types the selection owner is capable of supplying is placed in the
 * pointer specified by the typelist argument. The typelist is null terminated,
 * and the fields are seperated by newline characters. It is the callers
 * responsibility to free the typelist string, as it is allocated dynamically.
 */
GR_WINDOW_ID
GrGetSelectionOwner(GR_CHAR **typelist)
{
}

/**
 * GrRequestClientData:
 * @wid: the ID of the window requesting the data
 * @rid: the ID of the window to request the data from
 * @mimetype: the desired mime type to request
 * @sid: the serial number of the request
 *
 * Sends a CLIENT_DATA_REQ event to the specified window. Used for requesting
 * both selection and "drag and drop" data. A single mime type (typically
 * text/plain for plain ASCII text) must be specified in the mimetype argument
 * as a null terminated ascii string. The server makes no guarantees as to
 * when, or even if, the client will reply to the request. If the client does
 * reply, the reply will take the form of one or more CLIENT_DATA events.
 * The request serial number is optional, and is typically a unique ID which
 * the client can assign to a request in order for it to be able to keep track
 * of transfers (CLIENT_DATA events contain the same number in the sid field).
 * Remember to free the data field of the CLIENT_DATA events as they are
 * dynamically allocated.
 */
void
GrRequestClientData(GR_WINDOW_ID wid, GR_WINDOW_ID rid, GR_CHAR *mimetype,
			GR_SERIALNO sid)
{
}

/**
 * GrSendClientData:
 * @wid: the ID of the window sending the data
 * @did: the ID of the destination window
 * @sid: the serial number of the request
 * @len: the number of bytes of data to transfer
 * @data: pointer to the data to transfer
 *
 * Used as the response to a CLIENT_DATA_REQ event. Sends the specified data
 * of the specified length to the specified window using the specified source
 * window ID and transfer serial number. Any fragmentation of the data into
 * multiple CLIENT_DATA events which is required is handled automatically.
 * The serial number should always be set to the value supplied by the
 * CLIENT_DATA_REQ event. Remember to free the mimetype field of the
 * CLIENT_DATA_REQ event as it is dynamically allocated.
 */
void
GrSendClientData(GR_WINDOW_ID wid, GR_WINDOW_ID did, GR_SERIALNO sid,
			GR_LENGTH len, void *data)
{
}

/**
 * GrRegisterDragAndDropWindow:
 * @wid: the ID of the window to use as the drag and drop source window
 * @iid: the ID of the pixmap to use as the drag and drop icon
 * @typelist: list of mime types the drag and drop data can be supplied as
 *
 * Enables the specified window to be used as a drag and drop source. The
 * specified pixmap will be used as the icon shown whilst dragging, and the
 * null terminated, newline seperated list of mime types which the data can
 * be supplied as is specified by the typelist argument. At least one type
 * (typically text/plain for plain ASCII or text/uri-list for a filename or
 * list of filenames) must be specified. When the icon is dropped,
 * the window which it is dropped on will receive a DROP event (providing it
 * has selected for DROP events), and if the client wishes to accept the data
 * and is able to handle one of the mime types in the type list, it should use
 * GrRequestClientData() to retrieve the data from the drag and drop source
 * window. Remember to free the typelist field of the DROP event as it is
 * dynamically allocated. It is possible for a client to select for DROP events
 * on the Root window if it is desired to allow dropping icons on the desktop.
 */
void
GrRegisterDragAndDropWindow(GR_WINDOW_ID wid, GR_WINDOW_ID iid,
				GR_CHAR *typelist)
{
}

-- 
--------------- Linux- the choice of a GNU generation. --------------
: Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham :
-------------------- http://www.linuxhacker.org/ --------------------


Previous by date: 12 Aug 2000 06:57:45 -0000 header dependency of scrollbar thumb for 0.88pre11, 曾昭明
Next by date: 12 Aug 2000 06:57:45 -0000 Re: License issues, Alex Holden
Previous in thread: 12 Aug 2000 06:57:45 -0000 Re: clipboard support?, Greg Haerr
Next in thread:


Powered by ezmlm-browse 0.20.