Re: NSPasteboard on X, what to do?

[Richard Frith-Macdonald]

On Tuesday, January 8, 2002, at 10:04 PM, Willem Rein Oudshoorn wrote:

> Probably NeXTStep and OpenStep did not have any of these problems, I 
> guess
> that for those systems the following was true:
>
> - Use narrow definition of application.

Yes, I think that 'App' corresponds to 'process'.

> - Every computer had ONE dedicated screen all for itself.

No. A single application could have windows displayed on multiple 
screens on
one machine.  It could also display on another machine (though I'm not 
sure
about using multiple displays on different machines).

> On X this IS an issue.  So in order to give some meaningfull
> interpretation to the class description let's examine the
> kind of NSPasteboards that are documented.
>
> The different NSPasteboards
> ---------------------------
>
> * General Pasteboard  (ordinary cut, copy paste operations)
> * Font Pasteboard  (support copy font, paste font)
> * Ruler Pasteboard (support copy ruler, paste ruler)
> * Find Pasteboard (active applications find panel)
> * Drag Pasteboard (well, DnD of course)
>
>
> So this clearly suggusts that the *all* is grouped by Screen.

Not to me.  I see dragging and cut-and paste as inter-screen operations -
I want them to take effect wherever the mouse pointer is.

In MacOS-X (essentially OpenStep) I routinely perform a cut on one 
screen,
move the mouse to an app on my other screen, and paste into the second 
app.
Similarly, I drag stuff from an app on one screen to an app on the other.


> Grouping by Screen
> ------------------
>
> * Advantages:
>   1. DnD is naturally associated to a single Screen.
Actually a disadvantage ... how do you drag from one screen to another?
>   2. Most copy and paste operations are performed on a single screen.
Most copy and paste operations are performed on a single machine ... I'd 
venture
to say that this should be listed in the next section.
>   3. AppKit/GUI at the moment only supports a single display
>
> * Disadvantage:
>   1. Harder to implement than Computer based grouping

2. Unfriendly ... can't cut on one screen and paste into another.

> Grouping By Computer
> --------------------
>
> * Advantages:
>   1. Easier to implement
>   2. Current implementation does this
>
> * Disadvantages
>   1. No DnD and copy/paste between different applications
>      running on different computers but on the same screen,
>      thereby going against the X philosophy.

Not sure what you mean by this ... if you are receiving a drop from
an app on another machine, the -draggingPasteboard method provided by
the dragging info would return a pasteboard object connected to the
pasteboard server on which the drag originated.
I'm sure it doesn't do this at present, but that's because the appkit
generally doesn't handle multiple screens at present.

> So I hope that someone can explain to me how we are going to
> interprete the concepts `Application' and `all' in GNUstep.

I'm pretty sure that the term 'application' is generally meant to
describe a process which uses the AppKit.

The aspect of this I've never been so happy about is the 'all'
What about a multi-screened, multi-keyboarded machine with more than
one user.  Do both users share the same pasteboard server?
I think ideally not.  Each user would get their own server (to which
they save data)

> I think
> for the Pasteboard we can should settle on Grouping by Screen

I completely disagree ... I hope I have shown above that the advantages
you list for doing this do not actually exist, while the disadvantage
you supply for grouping by computer does not exist.

>  The
> pasteboard is part of AppKit/GUI so any application trying to use the
> NSPasteBoard should have some concept of Screens.  At the moment
> AppKit only supports one screen, so multiple screens is no problem.
> If GUI is going to support multiple screens per Application, we need
> an extension of the NSPasteboard.

We don't need any changes to support multiple screens ... where we will
start to need to work on things is when we get multiple machines sharing
the same screen.  When that happens we need only ensure that the 
internals
of the DnD system supply a pasteboard to the app which is connected to 
the
correct pasteboard server.  How we cope with a cut and paste operation
between two apps on different machines (either on the same screen or on
two screens of one machine) I don't know.  I think this is the tricky 
case
but it may be rare enough to ignore.

Caveat ... I wrote the pasteboard code so of course I'm biased.
On the other hand, it was long enough ago that I can't really remember 
it,
and I'd probably write it better if I tried again now :-)