[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NSPasteboard on X, what to do?

From: Dennis Leeuw
Subject: Re: NSPasteboard on X, what to do?
Date: Wed, 09 Jan 2002 08:06:32 +0100

Hi Willem,

Reading your mail, I had the idea, and maybe this is a very stupid remark,
that this could be solved, like this:

Every App that corresponds to a single machine, on a single OS, uses the
machine/os pasteboard server. So the server is tied to the machine and OS.
Then DO makes sure that if there are more pasteboard servers around (Read
more GNUstep systems running) the NSPasteboards are interconnected.

In the complex case of a Client-Server app, the pasteboard server is the one
on the server, like when you are connecting a terminal to a system. Only
local apps use the local pasteboard server.

Like I said, maybe I am way off.



Willem Rein Oudshoorn wrote:

> I have been thinking about the NSDragPasteboard idea of Fred Kiefer in
> the last few weeks.  After a while I realized that I miss some
> fundamental insight in the NSPasteboard semantics.
> The problem I have I will try to explain in the this mail.
> It is rather long, but I have a hard time trying to making my
> confusion precise.
> The confusion is caused by documentation of the NSPasteboard class.
> Documentation copied from OpenStepSpec  (emphasize mine):
>   NSPasteboard objects transfer data to and from the pasteboard
>   server. The server is *shared* by *all* running applications. It
>   contains data that the user has *cut* or *copied* and may *paste*,
>   as well as *other* data that one application wants to *transfer* to
>   another. NSPasteboard objects are an application s sole interface to
>   the server and to all pasteboard operations.
> I have problems with the concept of *all* running applications, namely
> what is an application, and what is incorporated in the broad term
> *all*.
> So let me first give two definitions of the term application:
> Application
> -----------
> App (Narrow) - A `running application' correspond 1-1 to a process
>         running in ONE operational operating system.
> App (Broad) - A collection of processes that work together to provide
>         to the user the illusion of a single application.  (I know it
>         is vague, but think of client/server applications, DO
>         applications etc.)
> Now whatever type of application is meant, applications use system
> resources.  The boundary of the term *all* is probably defined in
> terms of these resources.
> Resources
> ---------
> Computer - Instance of a operational operating system.  (that is one
>            computer)
> Screen - A `monitor' used to display the output of
>          the application
> (Un)fortunately these resources are orthogonal to each other and an
> `application' can use multiple resources at the same time.
> The consequence is that there are a lot of combinations possible.
>           App Name,     running on Computer,    displaying on Screen
> Simple     App A          X                     S (attached to X)
> Distrib1   App B          X, Y                  S (attached to X)
> Mscreen    App C          X,                    S, T (both attached to X)
> screen2    App D          Y                     S (attached to X)
> screen3    App E          X                     U (attached to Y)
> Mscreen2   App F          Y                     S, U (attached to X and Y)
> and lots of other combinations.
> Of course GNUstep is not obliged to support all these combinations.
> And we can restrict the number of combinations in different ways:
> * Use narrow definition of App, this rules out the Distrib1 case.
> * Only allow one screen per App, this rules out Mscreen, Mscreen2
> * Use narrow definition of App
>   AND only allow the usage of ONE screen logically belongs to this
>   computer.
>   This forbids mixing Screen3 with Simple
>   or mixing Screen2 with Simple.
> 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.
> - Every computer had ONE dedicated screen all for itself.
> So in this case it does not matter if you group the applications
> with respect to Computer or Screen.  The result is the same.
> 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.
> Grouping by Screen
> ------------------
> * Advantages:
>   1. DnD is naturally associated to a single Screen.
>   2. Most copy and paste operations are performed on a single screen.
>   3. AppKit/GUI at the moment only supports a single display
> * Disadvantage:
>   1. Harder to implement than Computer based grouping
> 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.
> So I hope that someone can explain to me how we are going to
> interprete the concepts `Application' and `all' in GNUstep.  I think
> for the Pasteboard we can should settle on Grouping by Screen.  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.
> Wim Oudshoorn.
> _______________________________________________
> Discuss-gnustep mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/discuss-gnustep

reply via email to

[Prev in Thread] Current Thread [Next in Thread]