Re: using XDPS backend to display NextOpenStep apps remotely

[Ondrej Florian]

Thanks Gregory.

Communicating between GNUstep and Next is actually not that bad.
I managed to sync pasteboard by using simple TCP client/server and transferring 
strings, RTF or TIFF data as appropriate.

The Previous has NFS server built-in, so working with files is just matter of 
transforming local paths to network paths and then executing appropriate app 
(using the simple TCP client/server) in Next.

I mapped Previous into its own windowmaker workspace.
That works reasonably well but it is somewhat limiting for day to day usage.

I'll take a look at DSP server as you've suggested and see where it leads me 
;-).

On 2024-04-28 22:41:53 +0200 Gregory Casamento <greg.casamento@gmail.com> wrote:

> Hey,
> 
> I had given this some thought some years ago.   Let's go over what you said
> you need...
> 
> 1) running the next emulator headless...
> 
> I think this could be accomplished, no problem.   You could either use
> Previous or qemu (running the intel version of OPENSTEP).
> 
> 2) Communication via DPS...
> 
> You don't need XDPS for this.  The XDPS backend for GNUstep was an attempt
> to use the Display Postscript that was going to be integrated into X11, but
> this never happened because the people on the project determined that
> postscript was better done as a client/app side thing rather than in the X
> server itself.   Here is the discussion...
> 
> https://www.x.org/releases/X11R7.5/doc/graphics/dps.html#:~:text=Display%20Postscript%20
> (or%20DPS%20for,code%20from%20client%20to%20server.
> 
> One place you can get information is from the following website, he has
> done a fair bit of hacking on PS and DPS...
> 
> https://www.wizards.de/~frank/franksprojects.html
> 
> Of particular interest is project Akira.   It may be possible to connect to
> the DPS server over a port and communicate with it, but no one has done
> that and I am not sure the remote capability is present either in the
> DGS/DPS backend that X was planning.
> 
> 3) Pasteboard bridging...
> 
> The pasteboard on the NeXT likely uses the typedstream style of encoding
> that was common on the NeXT machine.   This encoding has never been reverse
> engineered... one possible resource for this is a python program I found
> recently that discovers, in part, the structure of typedstream archives...
> 
> https://github.com/dgelessus/python-typedstream.git
> 
> The tool doesn't get the data it just breaks down what data is there which
> could be instrumental in reverse engineering it.
> 
> CONCLUSION...
> 
> As you can see there is a fair amount of work here.   This is all of the
> information I have discovered over the years on this.  If I find anything
> else or dig up any other information that might be useful I will let you
> know.
> 
> Yours, GC
> 
> 
> 
> 
> On Sun, Apr 28, 2024 at 2:32 PM Ondrej Florian <onflapp@yahoo.com> wrote:
> 
>> Hi everyone,
> 
>> I am working on integrating the Next emulator
>> (http://previous.alternative-system.com/)
>> into the GSDE  (https://github.com/onflapp/gs-desktop).
> 
>> I understand the original Next/OpenStep could display apps remotely (I
>> guess that's where NXHost arg comes from).
>> Does anyone know how this actually worked?
>> Could it be possible to use XDPS backed for for that?
> 
>> My hope is that I could run the Next emulator "headless" and display
>> the original apps along side GNUstep apps in the same desktop (plus
>> bridging pasteboard etc. ;-).
>> Kind of like how the classic mode worked on OS X.
> 
>> Any ideas?
> 
>> Many thanks,
>> Ondrej
> 
> 
> 
> 
>