Re: Package building

[cobjective]

On 19 Nov 2019, at 10:03, Fred Kiefer <fredkiefer@gmx.de> wrote:

Am 19.11.2019 um 00:42 schrieb Sergii Stoian <stoyan255@gmail.com>:

On Nov 15, 2019, at 10:44, Fred Kiefer <FredKiefer@gmx.de> wrote:

Am 15.11.2019 um 09:13 schrieb Johannes Brakensiek <johannes@brakensiek.info>:

On 5 Nov 2019, at 1:48, Sergii Stoian wrote:

I know NEXTSPACE and really like your project! My goals are somewhat lower currently: I’d be glad if I had some packages for GNU/Linux systems providing the new runtime/clang based libraries. Default Debian packages use gcc and I cannot ship a new app on this basis. I don’t like to be limited to one distribution type though, so I thought about using something like https://openbuildservice.org/ and/or https://launchpad.net/

Oh, now I understand what you’re talking about. I have plan to setup CI environment (Jenkins? Travis?).

yeah, that would be great. Maybe you would like to risk a look into openbuildservice? Having some installable packages built automatically would be great.

Great that somebody mentions OBS. I have been maintaining GNUstep packages there for years (https://build.opensuse.org/project/show/X11:GNUstep) and am willing to include NEXTSPACE as well, as soon as somebody provides a spec file for it.

OBS can compile packages for CentOS, right? NEXTSPACE repo contains specs for CentOS 7.
Did you mean specs for OpenSUSE?

OBS has a general spec format that gets used for all environments. Writing one for NEXTSPACE should not be too complicated. But if you rely on the art backend we are in trouble. A library that is required for this backend is not available on some systems and currently I only build the standard cairo backend.

You’re right. Actually libart absence is only part of a problem. I’ve had to compile LLVM/clang 7 for CentOS to use libobjc2 and modern Objective-C features. Now RedHat threw out libart from CentOS/RHEL 8. I suppose it’s not a problem for other distributions.

What is it that you are using from art that is not available in cairo? Maybe we could improve the implementation there to allow you to switch over.

This is not that simple question, but I’ll try to explain. Please be aware that my explanation is: subjective and hard to prove with numbers right now. Also my _current_ goal is to create NeXTSTEP-like desktop with minimal changes to GNUstep libraries.

There’re 2 main reasons for using art backend:

1. Speed. Terminal application “feels” faster with art versus cairo. I suppose it’s due to text rendering implementation (some tricks?). I can restore benchmark from original Terminal.app and send you a results. With art backend graphics exposures appear less often (no flickering). I guess art backend uses some buffering/caching for window portions. Remember I sent PR to fix flickering of appicon that is visible with cairo backend but not with art. To be fair, this is good attribute of cairo backend (we’ve optimised app icon drawing as a result) and image drawing with cairo looks better (for example, scrolling of NSImage much faster/smoother).

2. Font bundles(.nfont). As a font packager I can specify drawing properties (RenderingHints_hack), font name, other font properties (traits, weight, localised names, etc.). As a user I like the ability to drop font into Fonts directory have font available for applications and looking right (as package maintainer/creator think it should look). I know about fontconfig settings - I’m talking about separate GNUstep-only font packaging.

I guess, these to 2 things will be able to fix/implement. Unfortunately, I don’t have time to do it right now.

Fred