IMHO the biggest decision to be made in implementing clipboard support is how
to allow applications to exchange clipboard data in different formats. This
will determine how the data is stored. I'm not very familiar with the
clipboard mechanisms in other GUIs, so please feel free to add extra ideas or
correct me :)
It would be easy for an app or widget to provide pgserver with a handle to
the data to be cut/copied in the most descriptive form possible, have pgserver
take ownership of that handle, then let other applications read it in whatever
format they want. This would present some problems:
- It would only support picogui's built-in data types, no application-
specific formats.
- Giving pgserver a copy of the data in the most descriptive format possible
only to have it converted to plain text isn't efficient
- PicoGUI's data types are very simple, and only designed for passing data
between clients, widgets, and the rendering engine. It would be better to
use something standard and extensible, like mime types. Mime types could
be defined for standard picogui data types. ("image/x-pghandle" :)
It would be a lot more flexible for an app to, on cut/copy:
- Keep a reference in the client to the clipboard contents
- Notify pgserver that your client is the clipboard owner
- Respond to a message that will allow other apps to retrieve the clipboard
contents in a specified format, if supported. Maybe supply a list of formats
in order of preference?
Still, that has some flaws: it's a lot of work for the app, and you can't
paste data that you copied in an app after you close that app.
What about a system where pgserver manages the clipboard data, but clients can
register user-defined data types? Some kind of plugin system for pgserver to
convert between these user-defined data types?
Suggestions are welcome.
On Thu, Sep 26, 2002 at 11:44:02AM +0200, Philippe Ney wrote:
> Hi all,
>
> As suggested by Micah, we have to discuss about clipboard management.
>
> A first clipboard implementation in PicoGUI is the one done by Chuck
> Groom in his textedit widget. Which could be used with the textedit_branch
> server and the apps/textedit/ application.
>
> It provide selected text through the PG_WP_SELECTION property of the
> widget. But the management have to be done client side which don't permit
> copy/paste support through applications.
>
> As each widget manages its own behavior, this implementation is the right
> one at the widget level. Each widget is in charge of filling the clipboard
> if it integrate select/copy support as of pasting the content of the
> clipboard on itself if supported.
>
> We have to think about a server level clipboard manager which will be in
> charge of memory management, clipboard type (text, image, ... ), ....
> This manager will provide a copy/paste api to the widgets that need one.
>
> Copy on select seems to be a normal behavior for linux users. But only for
> linux users... Then certainly a 'replace' (selection by clipboard content)
> support will be a must. Which means multiple copy levels in the clipboard
> manager.
>
> Discussion is open!
> -philippe
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Pgui-devel mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/pgui-devel
--
Only you can prevent creeping featurism!
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Pgui-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/pgui-devel
