gnustep / libs-back

The GNUstep gui library is a library of graphical user interface classes written completely in the Objective-C language; the classes are based upon Apple's Cocoa framework (which came from the OpenStep specification). *** Larger patches require copyright assignment to FSF. please file bugs here. ***
http://www.gnustep.org
GNU General Public License v3.0
50 stars 34 forks source link

Add headless backend #39

Closed gcasa closed 2 weeks ago

gcasa commented 1 year ago

Add the headless backend implemented by keysight to simplify testing without a gui....

fredkiefer commented 1 year ago

Having the ability to start a GNUstep application in headless mode is a nice idea. B But this MR is in many regards not in a state in which it could be merged. In almost all files the author and copyright sections are wrong, sometimes even the file name. The code itself is a complete overkill. If you want something that cannot draw, maybe apart from producing a PDF file, it should be possible to get that with less code.

Please clean up and reduce and then it might get merged.

gcasa commented 1 year ago

Having the ability to start a GNUstep application in headless mode is a nice idea. B But this MR is in many regards not in a state in which it could be merged. In almost all files the author and copyright sections are wrong, sometimes even the file name. The code itself is a complete overkill. If you want something that cannot draw, maybe apart from producing a PDF file, it should be possible to get that with less code.

Please clean up and reduce and then it might get merged.

Yep, understood. I made it a draft for the reasons you mentioned. I just wanted to put it out there so that I can start working on it. It definitely needs some cleanup. This is part of the keysight merge that I had done last year, but I omitted this part originally.

gcasa commented 1 year ago

Having the ability to start a GNUstep application in headless mode is a nice idea. B But this MR is in many regards not in a state in which it could be merged. In almost all files the author and copyright sections are wrong, sometimes even the file name. The code itself is a complete overkill. If you want something that cannot draw, maybe apart from producing a PDF file, it should be possible to get that with less code.

Please clean up and reduce and then it might get merged.

I may need to restart this PR. I tried to do this as a "by hand" merge but I seem to be missing details.

[edit Aug 8] -- I have decided not to restart this PR, I was able to separate out JUST the headless backend. I renamed the classes to make sense and did some refactoring. I need to correct the copyright headers and authors. The main person who worked on this I believe was Marcian... so I will use his email as well as mine.

gcasa commented 1 year ago

I am going to start working on simplifying this in the next couple of days.

gcasa commented 1 year ago

@fredkiefer The parts that use cairo and such are there because it is necessary for this backend to be able to produce PDF files for testing, I believe. Can you think of any ways I can reduce this code?

gcasa commented 1 year ago

Having the ability to start a GNUstep application in headless mode is a nice idea. B But this MR is in many regards not in a state in which it could be merged. In almost all files the author and copyright sections are wrong, sometimes even the file name. The code itself is a complete overkill. If you want something that cannot draw, maybe apart from producing a PDF file, it should be possible to get that with less code.

Please clean up and reduce and then it might get merged.

I have corrected the copyright issues and renamed the files appropriately.

qmfrederik commented 1 year ago

@gcasa I believe the original implementation of the headless backend was heavily inspired by the Cairo and X backends, and written by pulling out bits and pieces of functionality. That makes the original implementation a bit hard to read -- there's references to X and Cairo which don't make an awful lot of sense in the context of a headless backend.

I've tried to re-implement the headless backend 'from scratch' -- i.e. by subclassing GSContext and GSDisplayServer and overriding 'just enough' functionality (essentially always returning the default value).

That seems to work; it allows Eggplant to run in batch mode in a container and execute a basic script.

Do you think there's some mileage in this approach?

gcasa commented 1 year ago

Yes. I do. I tried to follow Marcian's implementation only because I was told that we needed to be able to print a pdf at the end. I'm not sure if doing it the way you describe could do that or not, but it's worth a try.