> > I think the QT example offers a slightly more fruitful starting point, > > since the GTK+ mechanism is wed to the X Windows system, > > which I believe to be unnecessarily complicated w/r/t selections. > > The X system looks like the simplest thing to implement in picogui- it's the >application's job to do all conversions, and X's atoms are a lot like picogui's >handles. But it has the problem of your clipboard disappearing when you close an app. >It's types are pretty weak too.
Yeah, I guess the X selections are fine, but there's a lot of cruft and confusion about selections vs. clipboards vs. cut buffers. C.f. http://www.jwz.org/doc/x-cut-and-paste.html Just to voice my $0.02 (which agrees with much of what has been said, so is partly redundant): - When an app copies to the clipboard, it "raises its hand" to tell the server that it has data, and the type. - The data blob is, ideally, something portable like XML - The app is responsible for managing events like: - Another app did a copy; rid thyself of thy blob - Send blob - It is generally the server's responsiblity to translate between data types. This is reasonable for an embedded context. - If an app supplies a weird format type, it must either offer its own translation methods or the server will simply not translate it. - When an app quits, it can choose to give its data to the server or let the data be unavailable. (This is what MacOS used to do, and may still do). Most apps with small bits of text data will choose to hand it off to the server, but I think no one policy will properly deal with larger data types. Another option is to require that apps with large data types on the clipboard must save out their XML blob on quite and, if necessary, PicoGUI can launch the app just to the translate the blob if needed. But this gets complicated. I'm curious to know how pastes are sent between apps. A pipe? (Perhaps the handle mechanisms do this already, so forgive me if this is a silly question). I don't think we should do like X and support both clipboards and selection buffers. This creates user confusion. I agree that explicit copy is the way to go, since it agrees with most users' mental models. I think it would be great for drag-n-drop to operate in a similiar way, using the same data type translation facilities, but not be embedded in the clipboard mechanism. -Chuck ------------------------------------------------------- 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
