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.casame...@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 <onfl...@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 > > > > >