Re: Package building

[Riccardo Mottola]

Hi Sergii,


sorry for the long time to reply, I lost this mail


On 11/23/19 11:38 PM, Sergii Stoian wrote:



I'm working exactly on that, since day one with GNUstep and it has been a very 
long time now.


We can discuss how to join our efforts privately. What do you think?



Of course! I don't mind writing in public either, but in separate 
threads and in the appropriate mailing list (here, or maybe GAP, 
depending on the topic!)




Actually, given the latest developments of macOS and Windows 10 which are 
transforming a Desktop in a horrible sort of mega-tablet UI with eye-hurting 
graphics, GNUstep DE would be kind a shelter, sadly still incomplete and 
patchy... and not completely useful, although it did improve in the many years.


What do you mean by “incomplete and patchy”?
What do you means by “not completely useful”? NEXTSPACE quite useful for me 
even from development master branch. Or do you mean GNUstep libraries?



I don't mean NEXTSPACE, but the Environment I get when sticking together 
GNUstep, GAP and a couple of more things. "My" GNUstep Desktop, but the 
same that could be available in any Distribution, if it were complete.


Some are GNUstep library bugs, but most are shortcomings or bugs in the 
respective applications, which make the whole usage less pleasant.


Some random thoughts:

- GWorkspace is roughly acceptable

- GNUMail is still buggy... I worked hard, but some stuff is left out. 
Sometimes it hangs in network. sometimes it does not format things 
correctly, etc. Then it has also "limitations": way of handling 
addresses, address books. I'd like a more flexible way of handling 
attachments too (not just inline, but more traditional)


- ProjectCenter is quite stable now, although it has bugs when adding 
and removing files sometimes, I fixed it crashing in many situations. 
Albeit improved in warnings and error parsing from the compiler, it 
still misses proper parsing! The Editor is still limited. My next work 
will making the detached window editor useful, for example.


- GORM misses undo and positioning and editing of objects is more 
cumbersome even compared to old Interface Builder versions of XCode 2 and 3.


- SystemPreferences misses some OS dependent panels (e.g.xrender and 
wireless configuration) which are hard to write given the plethora of 
Linux and BSD setups


- GSPdf has some bugs with zooming and panning... I wonder if it 
handling correctly caching too, I need to investigate


- Terminal still has some subtle bugs in selection and scrolling

- Zipper could use a better integration with Finder/GWorkspace, the 
creation of archives is very rough!



and so on nothing of this looks terrible, but if you add these 
things together, not just Mac or Windows are more useful, but we fall 
behind XFCE. Maybe you are much better in NEXTSPACE, I did not check.


Since I use "vintage" Macs, I use many of these apps on Mac too: they 
are a way of getting "current" stuff on an old OS: that is the nice of 
Open Source! But even there they show most of these shortcomings. I try 
to fix them there too, so that I can discern between an App limitation 
and a specific GNUstep bug.


Riccardo

Re: Package building

[Riccardo Mottola]

Hi Bertrand,

Bertrand Dekoninck wrote:

I’m happy to see how such a sensitive topic (compilers…)  does progress these 
days. And I’d really be very happy if the gnustep runtime could run on ppc 
(both 32 and 64).

Last time I tried (on debian 8 ppc32, 1 year ago or even more ?) it failed, and 
I was alone with my questions. The problem was not only the assembly bits (as 
David said, there is a slower alternative) but some problem with clang (I don’t 
remember…). I’d be happy to help here and test again. I can’t code any 
assembly, but I can test on PPC32 and PPC64. I fear I need to install debian 
sid on  my machines, which is a pain for now. I know you (Ricardo) did install 
it on a powerbook. Can we have a decent X11 session there, and a decent 
compiler ? If we can build libobjc on this system, then it’ll be assembly 
coding time.

Which is the oldest version of Clang mandatory to build the gnustep runtime 
(1.9 and 2.0) ? Do we need a specific linker ? I would like to avoid clang’s 
build and use the distro’s one.


I have progress here, since in the past year I spent again quite some 
time on PPC, given my affiliation with the Power Progress Community 
("PPC" :-) )

- G3 iBook Clamshell (yaboot)
- G4 iBook (yaboot)
- G4 PowerBook (GRUB)

I use GCC only and the GCC runtime there. I did not even attempt 
something else. I am experimenting with gcc 6.5 (which is now not 
present in latest Debian versions, I keep the old .deb ) as well testing 
gcc7 and gcc8. I use cairo as backend on all of them.


The only big annoyance is the breakage of the bootloader (yaboot being 
obsolescent, but works well on my iBook) and GRUB of which the 
installation is broken and needs to be manually tweaked in a painful 
way, but then works on several macs (more modern ones).
Alsop the wireless setup needs some manual work, but can be done (old 
packages need to be retrieved, no longer available)


GNUstep works very well with GCC on PPC hardware currently. I don't 
noticed any "bugs" differing from a comparable x86 or amd64 setup! Our 
code is still quite good in this regard. Other applications suck more (tm).


I have a working setup with working X11. Both iBook work nicely in this 
regard. The PowerBook instead has a strange mouse issue, but with an 
external mouse it works.


GWorkspace, GNUMail, PRICE.. LaternaMagica.. everything works decently. 
I use WindowMaker.


For Browser, on "powerful" enough machines, you can use ArcticFox! But 
there are currently no available packages for it. And it is off-topic 
for the GNUstep world.


Riccardo

Re: Package building

[James Carthew]

What's the issue with clang on MIPS?

On Mon, 25 Nov 2019 at 06:15, Umberto Cerrato 
wrote:

> Please join the Discord. I’m interested in your experience with ppc and
> ppc64. One day I’ll need some help in installing GS in ppc64be (and el)
> Debian.
> Cheers,
> Umberto
>
> > Il giorno 24 nov 2019, alle ore 19:50, Bertrand Dekoninck <
> bertrand.dekoni...@gmail.com> ha scritto:
> >
> >
> >> Le 23 nov. 2019 à 15:48, Riccardo Mottola 
> a écrit :
> >>
> >> Hi,
> >>
> >>
> >>> On 11/20/19 12:28 PM, David Chisnall wrote:
> >>>
> >>> I'm happy to take contributions for the assembly paths for other
> architectures.  We currently have:
> >>>
> >>> - x86-32
> >>> - x86-64
> >>> - AArch32
> >>> - AArch64
> >>> - MIPS (at least n64 works, I think o32 and n32 are there but
> untested).
> >>>
> >>> I passionately hate PowerPC assembly, so will definitely not write
> that myself, but anyone who wants to add it is very welcome to do so.  I
> will probably get around to adding RISC-V support at some point.
> >>
> >>
> >> this list only lacks in my interest:
> >>
> >> - MIPS LittleEndian (as soon as I get the small project with Nikolaus
> actually do something useful) or is your implementation already
> endian-independent?
> >>
> >> - PPC32 (the only thing I have access to) and PPC64 to be accepted by
> the mainstream users today
> >>
> >> - SPARC32 and SPARC64
> >>
> >>
> >> sadly, it has been ages I touched PPC  (which as much as I love CPU
> concept, always hated when working in assembly) and SPARC code, but it
> would be a nice addition.
> >>
> >> On both PPC and SPARC I only use GCC, but... if that works, I'd be
> tickled to work lower level again.
> >>
> >> Riccardo
> >>
> >>
> >
> > I’m happy to see how such a sensitive topic (compilers…)  does progress
> these days. And I’d really be very happy if the gnustep runtime could run
> on ppc (both 32 and 64).
> >
> > Last time I tried (on debian 8 ppc32, 1 year ago or even more ?) it
> failed, and I was alone with my questions. The problem was not only the
> assembly bits (as David said, there is a slower alternative) but some
> problem with clang (I don’t remember…). I’d be happy to help here and test
> again. I can’t code any assembly, but I can test on PPC32 and PPC64. I fear
> I need to install debian sid on  my machines, which is a pain for now. I
> know you (Ricardo) did install it on a powerbook. Can we have a decent X11
> session there, and a decent compiler ? If we can build libobjc on this
> system, then it’ll be assembly coding time.
> >
> > Which is the oldest version of Clang mandatory to build the gnustep
> runtime (1.9 and 2.0) ? Do we need a specific linker ? I would like to
> avoid clang’s build and use the distro’s one.
> >
> > Bertrand
> >
> >
> >
> >
>

Re: Package building

[Umberto Cerrato]

Please join the Discord. I’m interested in your experience with ppc and ppc64. 
One day I’ll need some help in installing GS in ppc64be (and el) Debian.
Cheers,
Umberto 

> Il giorno 24 nov 2019, alle ore 19:50, Bertrand Dekoninck 
>  ha scritto:
> 
> 
>> Le 23 nov. 2019 à 15:48, Riccardo Mottola  a 
>> écrit :
>> 
>> Hi,
>> 
>> 
>>> On 11/20/19 12:28 PM, David Chisnall wrote:
>>> 
>>> I'm happy to take contributions for the assembly paths for other 
>>> architectures.  We currently have:
>>> 
>>> - x86-32
>>> - x86-64
>>> - AArch32
>>> - AArch64
>>> - MIPS (at least n64 works, I think o32 and n32 are there but untested).
>>> 
>>> I passionately hate PowerPC assembly, so will definitely not write that 
>>> myself, but anyone who wants to add it is very welcome to do so.  I will 
>>> probably get around to adding RISC-V support at some point.
>> 
>> 
>> this list only lacks in my interest:
>> 
>> - MIPS LittleEndian (as soon as I get the small project with Nikolaus 
>> actually do something useful) or is your implementation already 
>> endian-independent?
>> 
>> - PPC32 (the only thing I have access to) and PPC64 to be accepted by the 
>> mainstream users today
>> 
>> - SPARC32 and SPARC64
>> 
>> 
>> sadly, it has been ages I touched PPC  (which as much as I love CPU concept, 
>> always hated when working in assembly) and SPARC code, but it would be a 
>> nice addition.
>> 
>> On both PPC and SPARC I only use GCC, but... if that works, I'd be tickled 
>> to work lower level again.
>> 
>> Riccardo
>> 
>> 
> 
> I’m happy to see how such a sensitive topic (compilers…)  does progress these 
> days. And I’d really be very happy if the gnustep runtime could run on ppc 
> (both 32 and 64).
> 
> Last time I tried (on debian 8 ppc32, 1 year ago or even more ?) it failed, 
> and I was alone with my questions. The problem was not only the assembly bits 
> (as David said, there is a slower alternative) but some problem with clang (I 
> don’t remember…). I’d be happy to help here and test again. I can’t code any 
> assembly, but I can test on PPC32 and PPC64. I fear I need to install debian 
> sid on  my machines, which is a pain for now. I know you (Ricardo) did 
> install it on a powerbook. Can we have a decent X11 session there, and a 
> decent compiler ? If we can build libobjc on this system, then it’ll be 
> assembly coding time.
> 
> Which is the oldest version of Clang mandatory to build the gnustep runtime 
> (1.9 and 2.0) ? Do we need a specific linker ? I would like to avoid clang’s 
> build and use the distro’s one.
> 
> Bertrand
> 
> 
> 
> 

Re: Package building

[Bertrand Dekoninck]

> Le 23 nov. 2019 à 15:48, Riccardo Mottola  a 
> écrit :
> 
> Hi,
> 
> 
> On 11/20/19 12:28 PM, David Chisnall wrote:
>> 
>> I'm happy to take contributions for the assembly paths for other 
>> architectures.  We currently have:
>> 
>> - x86-32
>> - x86-64
>> - AArch32
>> - AArch64
>> - MIPS (at least n64 works, I think o32 and n32 are there but untested).
>> 
>> I passionately hate PowerPC assembly, so will definitely not write that 
>> myself, but anyone who wants to add it is very welcome to do so.  I will 
>> probably get around to adding RISC-V support at some point.
> 
> 
> this list only lacks in my interest:
> 
> - MIPS LittleEndian (as soon as I get the small project with Nikolaus 
> actually do something useful) or is your implementation already 
> endian-independent?
> 
> - PPC32 (the only thing I have access to) and PPC64 to be accepted by the 
> mainstream users today
> 
> - SPARC32 and SPARC64
> 
> 
> sadly, it has been ages I touched PPC  (which as much as I love CPU concept, 
> always hated when working in assembly) and SPARC code, but it would be a nice 
> addition.
> 
> On both PPC and SPARC I only use GCC, but... if that works, I'd be tickled to 
> work lower level again.
> 
> Riccardo
> 
> 

I’m happy to see how such a sensitive topic (compilers…)  does progress these 
days. And I’d really be very happy if the gnustep runtime could run on ppc 
(both 32 and 64).

Last time I tried (on debian 8 ppc32, 1 year ago or even more ?) it failed, and 
I was alone with my questions. The problem was not only the assembly bits (as 
David said, there is a slower alternative) but some problem with clang (I don’t 
remember…). I’d be happy to help here and test again. I can’t code any 
assembly, but I can test on PPC32 and PPC64. I fear I need to install debian 
sid on  my machines, which is a pain for now. I know you (Ricardo) did install 
it on a powerbook. Can we have a decent X11 session there, and a decent 
compiler ? If we can build libobjc on this system, then it’ll be assembly 
coding time.

Which is the oldest version of Clang mandatory to build the gnustep runtime 
(1.9 and 2.0) ? Do we need a specific linker ? I would like to avoid clang’s 
build and use the distro’s one.

Bertrand

Re: Package building

[Sergii Stoian]

Hi,

On Nov 23, 2019, at 16:58, Riccardo Mottola  wrote:

> Hi,
> 
> On 11/20/19 1:48 AM, cobjective wrote:
>> My initial idea was to make my dream come true - have NeXTSTEP for my own 
>> use: fast, reliable and consistent.
> 
> 
> I'm working exactly on that, since day one with GNUstep and it has been a 
> very long time now.
> 
We can discuss how to join our efforts privately. What do you think?

>> I would be glad if other people share my taste. If you like macOS/KDE/GNOME 
>> - why should you use GNUstep-based DE?
> 
> 
> Actually, given the latest developments of macOS and Windows 10 which are 
> transforming a Desktop in a horrible sort of mega-tablet UI with eye-hurting 
> graphics, GNUstep DE would be kind a shelter, sadly still incomplete and 
> patchy... and not completely useful, although it did improve in the many 
> years.
> 
What do you mean by “incomplete and patchy”?
What do you means by “not completely useful”? NEXTSPACE quite useful for me 
even from development master branch. Or do you mean GNUstep libraries?

> Riccardo
> 
Sergii

Re: Package building

[Sergii Stoian]

Hi,

On Nov 23, 2019, at 16:25, Riccardo Mottola  wrote:
> Hi Sergii,
> 
> 
> On 11/19/19 12:39 AM, Sergii Stoian wrote:
>> Some patches already went upstream, some others not yet. It’s planned 
>> anyway. I use ART backend and it stopped working after 0.25.0 release. I 
>> need to fix ART first before I can return to master branch...
> 
> 
> it is a lttle off-topic, but the ART backend still works for me. I now use it 
> only on two setups, dropping either to xlib or going standard cairo where it 
> does work. Although on one little system ART is the only one which actually 
> draws fonts :-P
> 
Hmm… Interesting...

> I havent tried in the last weeks/months, but the last release worked. Of 
> course, it has all specific "issues" of art which where never solved. But it 
> is faster for certain operations and curves and anti-aliasing are exquisite. 
> Using Graphos on art is a delight.
> 
What do you mean by “worked”? I observed incomplete words in menus and popup 
buttons. Incorrect alignment of items in popup buttons - I suppose it’s due to 
incorrect lengthOfString results. Also I suppose I’ve found cause of a problem 
- NSStringDrawing caching methods rewrite by Fred. But I can’t understand what 
changes must be applied to ART backend to adopt new caching algorithm.
> 
> Riccardo

Sergii

Re: Package building

[Riccardo Mottola]

Hi,


On 11/20/19 1:48 AM, cobjective wrote:

My initial idea was to make my dream come true - have NeXTSTEP for my own use: 
fast, reliable and consistent.



I'm working exactly on that, since day one with GNUstep and it has been 
a very long time now.




I would be glad if other people share my taste. If you like macOS/KDE/GNOME - 
why should you use GNUstep-based DE?



Actually, given the latest developments of macOS and Windows 10 which 
are transforming a Desktop in a horrible sort of mega-tablet UI with 
eye-hurting graphics, GNUstep DE would be kind a shelter, sadly still 
incomplete and patchy... and not completely useful, although it did 
improve in the many years.



Riccardo

Re: Package building

[David Chisnall]

On 23 Nov 2019, at 14:48, Riccardo Mottola  wrote:
> 
> Hi,
> 
> 
> On 11/20/19 12:28 PM, David Chisnall wrote:
>> 
>> I'm happy to take contributions for the assembly paths for other 
>> architectures.  We currently have:
>> 
>> - x86-32
>> - x86-64
>> - AArch32
>> - AArch64
>> - MIPS (at least n64 works, I think o32 and n32 are there but untested).
>> 
>> I passionately hate PowerPC assembly, so will definitely not write that 
>> myself, but anyone who wants to add it is very welcome to do so.  I will 
>> probably get around to adding RISC-V support at some point.
> 
> 
> this list only lacks in my interest:
> 
> - MIPS LittleEndian (as soon as I get the small project with Nikolaus 
> actually do something useful) or is your implementation already 
> endian-independent?

I’ve only tested it on BE, I think the logic that pulls bytes out of the 
selector index will need tweaking for LE, but that should be about it.

SPARC and POWER are completely missing, but I don’t see any fundamental problem 
with someone adding them.  POWER may be fun because of the function descriptor 
model.  I’m not sure how well LLVM’s SPARC back end works.  ESA did some work 
on it for LEON, so SPARC32 may be stable.

There’s also System/Z, which is supported by LLVM, if someone wants to run 
Objective-C on a mainframe...

My somewhat biased view is that if there aren’t enough engaged users for a 
platform that we can get around 100 lines of assembly written for that 
platform, then it’s hard to justify the investment in that platform.

David

Re: Package building

[Riccardo Mottola]

Hi,


On 11/20/19 12:28 PM, David Chisnall wrote:


I'm happy to take contributions for the assembly paths for other 
architectures.  We currently have:


- x86-32
- x86-64
- AArch32
- AArch64
- MIPS (at least n64 works, I think o32 and n32 are there but untested).

I passionately hate PowerPC assembly, so will definitely not write 
that myself, but anyone who wants to add it is very welcome to do so.  
I will probably get around to adding RISC-V support at some point.



this list only lacks in my interest:

- MIPS LittleEndian (as soon as I get the small project with Nikolaus 
actually do something useful) or is your implementation already 
endian-independent?


- PPC32 (the only thing I have access to) and PPC64 to be accepted by 
the mainstream users today


- SPARC32 and SPARC64


sadly, it has been ages I touched PPC  (which as much as I love CPU 
concept, always hated when working in assembly) and SPARC code, but it 
would be a nice addition.


On both PPC and SPARC I only use GCC, but... if that works, I'd be 
tickled to work lower level again.


Riccardo

Re: Package building

[Riccardo Mottola]

Hi,


On 11/20/19 12:08 PM, Ivan Vučica wrote:
Clearly yes — but Debian packages also use the GCC runtime, or they 
did last time I checked.



does building the new runtime with GCC even works currently? I had 
tremendous issues (and failed) the last time I tried. I was able to do 
it only a long time ago, at the time when "normal" makefiles were hacked 
by Richard.



Riccardo

Re: Package building

[Riccardo Mottola]

Hi Sergii,


On 11/19/19 12:39 AM, Sergii Stoian wrote:

Some patches already went upstream, some others not yet. It’s planned anyway. I 
use ART backend and it stopped working after 0.25.0 release. I need to fix ART 
first before I can return to master branch...



it is a lttle off-topic, but the ART backend still works for me. I now 
use it only on two setups, dropping either to xlib or going standard 
cairo where it does work. Although on one little system ART is the only 
one which actually draws fonts :-P


I havent tried in the last weeks/months, but the last release worked. Of 
course, it has all specific "issues" of art which where never solved. 
But it is faster for certain operations and curves and anti-aliasing are 
exquisite. Using Graphos on art is a delight.



Riccardo

Re: Package building

[Sergii Stoian]

On Nov 21, 2019, at 19:13, Fred Kiefer  wrote:
> 
> 
>> Am 21.11.2019 um 12:43 schrieb Sergii Stoian :
>> 
>> UDisks and PulseAudion is all about D-Bus (communication, events), GLib (run 
>> loop, types, data structures). The harderst part for me was to adopt GLib 
>> run loop into NSRunLoop runnig application code.
>> If I was using GTK+ - there will be no problem, it's already there and looks 
>> natual. 
>> 
> 
> Just wanted to remind you that there is DBusKit in GNUstep 
> (https://github.com/gnustep/libs-dbuskit). Like the rest of GNUstep it is 
> getting a bit old now, but should still be a working Objective-C integration 
> level for D-Bus. I still think this was the best Google Summer of Code 
> project we ever had.

Yes, thanks. I know about DBusKit. I’ve already played with DBusKit to 
communicate with NetworkManager for network preferences module. It’s usable and 
has a very interesting implementation.

Re: Package building

[Fred Kiefer]

> Am 21.11.2019 um 12:43 schrieb Sergii Stoian :
> 
> UDisks and PulseAudion is all about D-Bus (communication, events), GLib (run 
> loop, types, data structures). The harderst part for me was to adopt GLib run 
> loop into NSRunLoop runnig application code.
> If I was using GTK+ - there will be no problem, it's already there and looks 
> natual. 
> 

Just wanted to remind you that there is DBusKit in GNUstep 
(https://github.com/gnustep/libs-dbuskit). Like the rest of GNUstep it is 
getting a bit old now, but should still be a working Objective-C integration 
level for D-Bus. I still think this was the best Google Summer of Code project 
we ever had.

Re: Package building

[Sergii Stoian]

On Thu, Nov 21, 2019 at 10:47 AM David Chisnall 
wrote:

> On 20 Nov 2019, at 23:13, cobjective  wrote:
> >
> > On 19 Nov 2019, at 13:42, David Chisnall 
> wrote:
> >>
> >> On 19/11/2019 09:40, Johannes Brakensiek wrote:
>  I understand that the initial idea was to attract more
> users/developers, but… It’s not working.
> >>> Hm, yes. I think developers don’t need a nice UI at first place (and I
> think most of what developers need luckily is already provided by Apple as
> of today). But developers need happy users (if you’re not developing only
> for yourself) and I think happy users need a stable, solid and consistent
> UX. That would be provided by a NextStep based UI guideline. But they also
> need a pretty UI (which is not what you’d call that NextStep look nowadays,
> imho).
> >>
> >> I would add to that: most users will not be using a GNUstep DE.  This
> was one of the biggest mistakes that we made with Etoile: we did not have
> an incremental adoption story.
> >>
> > How do you know about users? I tried Etoile some time ago.
>
> By looking at current DE usage.
>
> > My thoughts were: “Cool thing. Not ready for everyday usage yet”.
> > NEXTSPACE is. And it looks and feels familiar to Window Maker users.
>
> And if you pick a random desktop Linux or *BSD user, there’s approximately
> a 0% chance that they are using NEXTSPACE.  If I write an application
> targeting NEXTSPACE users, I have a far smaller reach than if I write an
> application that integrates well with a GNOME, KDE, or even Windows
> desktop.
>
> You're right. Moreover you are probably will select Python/C/C++ and
native toolkit for targeted environment, right? I hope there are some
people which want to write applications for NeXTSTEP-like environment. If
not - it will be a nice try to create reference DE as a show case what
GNUstep-base DE should look like around 2005 or so.


> I have first-hand experience of this from a couple of years ago, when I
> wrote an application in Objective-C++ for inspecting the (huge - 100GB+)
> traces that our processor generates.  Our group was roughly split between
> Mac and Ubuntu users.  The Mac users loved it, the Ubuntu users hated it.
> Even after doing a load of theming to get the menu bar in the window and so
> on, they just about tolerated it.
>
> If I were doing it again, I’d probably keep the core in C++ and use
> Electron for the GUI.
>
> It's sad to know for me. But it's a real life.

>> If you want GNUstep to be attractive to developers, you need to make it
> easy for them to ship apps that integrate with an existing *NIX DE and with
> Windows.  One of the biggest things that RedHat did for Linux desktop
> usability was teach the GTK+ and Qt theme engines to understand a shared
> format and unify shortcut keys between the two.  After that, it didn't
> matter (much) if you needed a mix of GNOME and KDE apps, your desktop still
> felt (approximately) cohesive.
> >
> > Indeed. But keep in mind that GNOME and KDE apps share (with some minor
> differences) the same style for desktop and applications (icons on desktop,
> sys tray, in-window menus, scrollbars on the right and so on). That’s why
> it was quite natural to make look of Qt/GTK+ apps consistent (cohesive).
> GNUstep roots are in NeXT's OS (OpenStep specification appeared around
> 1997, NeXT and Apple started merging these days). This legacy has it’s own
> charm not because of look but mostly because of “feel” (style of doing
> things). That’s why I like GNUstep.
>
> You seem to be forgetting some of the heritage of the OpenStep
> specification (which was released in 1993, not 1997).  It was originally
> designed by NeXT and Sun (hence the NS prefix) to allow applications to be
> written once and then easily ported between Sun’s CDE desktop environment
> and NeXT’s NeXTSTEP / OPENSTEP environment.  CDE had a lot of the UI
> abstractions that KDE and GNOME share.
>
> Uh, yes, you're right.

NeXT also released a version of OpenStep for Windows and Apple demoed an
> improved version that removed the DPS abstraction and used native drawing
> APIs (though they never shipped it).
>
> The OpenStep specification is specifically written to abstract away a lot
> of the details.  It doesn’t say whether menus are in window, at the top of
> the screen, or floating.  It doesn’t say where scroll bars go.  It doesn’t
> say whether you have a dock or a task bar.
>
> Correct.


> Now, for a great cross-platform app, you may want to have different NIBs
> that completely reflect each platform’s HIGs, but you can have something
> that feels close without that and separate the platform porting effort from
> the rest.
>
> Let's broaden our vision to cross-platform app. Let's get some virtual
note taking application. And let's suppose it should run on Linux, MacOS,
Windows, iOS and Android. It's a usual case I think: MacOS or Linux at
home, Windows at work, iPhone for personal usage and Android for spouse.
What is the best architecture for this with 

Re: Package building

[David Chisnall]

On 20 Nov 2019, at 23:13, cobjective  wrote:
> 
> On 19 Nov 2019, at 13:42, David Chisnall  wrote:
>> 
>> On 19/11/2019 09:40, Johannes Brakensiek wrote:
 I understand that the initial idea was to attract more users/developers, 
 but… It’s not working.
>>> Hm, yes. I think developers don’t need a nice UI at first place (and I 
>>> think most of what developers need luckily is already provided by Apple as 
>>> of today). But developers need happy users (if you’re not developing only 
>>> for yourself) and I think happy users need a stable, solid and consistent 
>>> UX. That would be provided by a NextStep based UI guideline. But they also 
>>> need a pretty UI (which is not what you’d call that NextStep look nowadays, 
>>> imho).
>> 
>> I would add to that: most users will not be using a GNUstep DE.  This was 
>> one of the biggest mistakes that we made with Etoile: we did not have an 
>> incremental adoption story.
>> 
> How do you know about users? I tried Etoile some time ago. 

By looking at current DE usage.

> My thoughts were: “Cool thing. Not ready for everyday usage yet”.
> NEXTSPACE is. And it looks and feels familiar to Window Maker users.

And if you pick a random desktop Linux or *BSD user, there’s approximately a 0% 
chance that they are using NEXTSPACE.  If I write an application targeting 
NEXTSPACE users, I have a far smaller reach than if I write an application that 
integrates well with a GNOME, KDE, or even Windows desktop.  

I have first-hand experience of this from a couple of years ago, when I wrote 
an application in Objective-C++ for inspecting the (huge - 100GB+) traces that 
our processor generates.  Our group was roughly split between Mac and Ubuntu 
users.  The Mac users loved it, the Ubuntu users hated it.  Even after doing a 
load of theming to get the menu bar in the window and so on, they just about 
tolerated it.

If I were doing it again, I’d probably keep the core in C++ and use Electron 
for the GUI.

>> If you want GNUstep to be attractive to developers, you need to make it easy 
>> for them to ship apps that integrate with an existing *NIX DE and with 
>> Windows.  One of the biggest things that RedHat did for Linux desktop 
>> usability was teach the GTK+ and Qt theme engines to understand a shared 
>> format and unify shortcut keys between the two.  After that, it didn't 
>> matter (much) if you needed a mix of GNOME and KDE apps, your desktop still 
>> felt (approximately) cohesive.
> 
> Indeed. But keep in mind that GNOME and KDE apps share (with some minor 
> differences) the same style for desktop and applications (icons on desktop, 
> sys tray, in-window menus, scrollbars on the right and so on). That’s why it 
> was quite natural to make look of Qt/GTK+ apps consistent (cohesive). GNUstep 
> roots are in NeXT's OS (OpenStep specification appeared around 1997, NeXT and 
> Apple started merging these days). This legacy has it’s own charm not because 
> of look but mostly because of “feel” (style of doing things). That’s why I 
> like GNUstep.

You seem to be forgetting some of the heritage of the OpenStep specification 
(which was released in 1993, not 1997).  It was originally designed by NeXT and 
Sun (hence the NS prefix) to allow applications to be written once and then 
easily ported between Sun’s CDE desktop environment and NeXT’s NeXTSTEP / 
OPENSTEP environment.  CDE had a lot of the UI abstractions that KDE and GNOME 
share.

NeXT also released a version of OpenStep for Windows and Apple demoed an 
improved version that removed the DPS abstraction and used native drawing APIs 
(though they never shipped it).

The OpenStep specification is specifically written to abstract away a lot of 
the details.  It doesn’t say whether menus are in window, at the top of the 
screen, or floating.  It doesn’t say where scroll bars go.  It doesn’t say 
whether you have a dock or a task bar.  

Now, for a great cross-platform app, you may want to have different NIBs that 
completely reflect each platform’s HIGs, but you can have something that feels 
close without that and separate the platform porting effort from the rest.


>> 
>> At the moment, people with one GNUstep app feel that it sticks out and is 
>> difficult to use because it doesn't follow the same UI models as the rest of 
>> their system.  That means that they then don't want a second one.
> Sure. Let’s imagine that GNUstep application follows Qt/GTK+ UI model. I have 
> a question: Why average developer will want to write application using 
> GNUstep libraries instead of GNOME/KDE? What are the benefits?

Do you think that the OpenStep APIs are cleaner and easier to use than Qt or 
GTK+?  If so, then there’s your answer.  If not, then why not build your DE on 
a different framework?  WindowMaker doesn’t use GNUstep and shows that you can 
still get most of the same look and feel without using the same APIs.  
Personally, I like the OpenStep frameworks, though they are now feeling a bit 
dated and 

Re: Package building

[cobjective]

On 20 Nov 2019, at 04:16, Ivan Vučica  wrote:
> 
> On Wed 20 Nov 2019 at 00:48, cobjective  > wrote:
> 
> 
> My initial idea was to make my dream come true - have NeXTSTEP for my own 
> use: fast, reliable and consistent.
> I would be glad if other people share my taste. If you like macOS/KDE/GNOME - 
> why should you use GNUstep-based DE?
> 
> GNUstep is not GNOME or KDE; GNUstep is GTK or Qt. It’s not a DE, it’s a set 
> of libraries to support development of desktop apps, backend services and CLI 
> tools.
> 
> That’s where work that you’re doing on Nextspace comes in, I think? GNUstep 
> core doesn’t have to declare “there is one DE and it’s NeXT-like”, it can 
> serve for app development for other desktops. Further work can be built on 
> top of that.
> 
Agreed. ;)

> I have my own view of a GNUstep-based desktop — but I’m not feeling like 
> putting enough effort into it to make it come true :)

Sad to know… Just try, it’s not that hard. ;)

> -- 
> Sent from Gmail Mobile

Sergii

Re: Package building

[cobjective]

James,

Network settings section is in TODO of Preferences.app. Other things you've 
mentioned are not in my plan currently.

> On 19 Nov 2019, at 14:16, James Carthew  wrote:
> 
> I've been toying with NextSpace in a VM. From my experience, if this gains a 
> web browser and network settings panel (mostly for Wifi config), (and gets 
> Debian packages) it could easily replace Mate on my machines. Linux desktop 
> application development is terrible at the moment. GNUstep may not be the 
> right answer for me, but I'm open to at least exploring it. 
> NSMacintoshMenuStyle works in NextSpace, and I had Rik.theme built/working 
> properly. I was hoping to get Etoile WildMenus running as well but ran out of 
> time. NextSpace is definitely moving in the right direction. I think the 
> focus on System settings is definitely the way to go. As someone who would 
> like to get a mac-like desktop out of this eventually I'd like to see some of 
> the options ported into SystemPreferences.app just because it's a more 
> mac-like application. But I like how NextSpace has the look/feel of NextStep, 
> definitely keep it up. I know the ideal would be to port webkit to gnustep 
> but at this point I'd be happy to just throw firefox into a gnustep window 
> with an application menu.
> 
> On Tue, 19 Nov 2019 at 22:49, Ivan Vučica  > wrote:
> On Mon, Nov 18, 2019, 23:40 Sergii Stoian  > wrote:
> Plus themes support bloats the GNUstep codebase. I understand that the 
> initial idea was to attract more users/developers, but… It’s not working.
> 
> Have you guessed why it's not working?
> 
> Users who would be attracted by a different theme are not aware there are 
> different themes or how to set them up.
> 
> A solution is to ship a "gnustep-recommended-config" package as a Recommends 
> of the libgnustep-gui package. Speaking in Debian terms; same goes for other 
> OSes.
> 
> This package would pull in a theme and a systemwide plist configuring a 
> modernized theme etc.
> 
> Today, if a KDE user born in 2001 installs a GNUstep program (they may not 
> care about the rest of the environment), the UI is totally out of sync with 
> their expectations. And if they go through the effort to explore an entire 
> environment, they get greeted by the 90s — whether they want it or not.
> 
> Am I misreading expectations of a prospective user?
> 
> I mean, these are my expectations, and I'm born in the late 80s. I love e.g. 
> System 7 look. NEXT look is decent to me (but just decent). I'm personally 
> around for the programming language and the frameworks, not for the default 
> theme.
> 
> Nextspace seems cool and I should get around to trying it out.

Re: Package building

[cobjective]

On 19 Nov 2019, at 13:49, Ivan Vučica  wrote:
> 
> On Mon, Nov 18, 2019, 23:40 Sergii Stoian  > wrote:
> Plus themes support bloats the GNUstep codebase. I understand that the 
> initial idea was to attract more users/developers, but… It’s not working.
> 
> Have you guessed why it's not working?
> 
> Users who would be attracted by a different theme are not aware there are 
> different themes or how to set them up.
> 
I think we have to consider several types of users:
1. Developer - reads documentation and write code. They’re getting knowledge 
from documentation.
2. Technically-skilled user - sometimes ;) reads docs and tweaks 
configuration/icons/WM. System administrators, package maintainers.
3. User Vulgaris ;) - uses what their distribution provides as DE (Unity, 
GNOME, KDE, XFCE).
Obviously, type #3 is not our target audience. For type #1 and #2 should exist 
reference implementation. That is Linux/FreeBSD based OS preconfigured for 
everyday usage (development, sysadmin tasks, package building) with 
documentation in human readable format to make their experiments easy and 
valuable. That's what I’m trying to create with NEXTSPACE.

> A solution is to ship a "gnustep-recommended-config" package as a Recommends 
> of the libgnustep-gui package. Speaking in Debian terms; same goes for other 
> OSes.
> 
> This package would pull in a theme and a systemwide plist configuring a 
> modernized theme etc.
> 
That’s an option.

> Today, if a KDE user born in 2001 installs a GNUstep program (they may not 
> care about the rest of the environment), the UI is totally out of sync with 
> their expectations. And if they go through the effort to explore an entire 
> environment, they get greeted by the 90s — whether they want it or not.
> Am I misreading expectations of a prospective user?
> 
Personally I’ve decided to define such user as "not my target audience” (I’m 
talking about NEXTSPACE here). Because such user looks for something MacOS-like 
or Windows-like. He will find DE that meets his expectations - GNOME/KDE/XFCE.

> I mean, these are my expectations, and I'm born in the late 80s. I love e.g. 
> System 7 look. NEXT look is decent to me (but just decent). I'm personally 
> around for the programming language and the frameworks, not for the default 
> theme.
> 
> Nextspace seems cool and I should get around to trying it out.


You’re welcome. I’ll be glad to hear your impression/critics.

Sergii

Re: Package building

[cobjective]

On 19 Nov 2019, at 13:42, David Chisnall  wrote:
> 
> On 19/11/2019 09:40, Johannes Brakensiek wrote:
>>> I understand that the initial idea was to attract more users/developers, 
>>> but… It’s not working.
>> Hm, yes. I think developers don’t need a nice UI at first place (and I think 
>> most of what developers need luckily is already provided by Apple as of 
>> today). But developers need happy users (if you’re not developing only for 
>> yourself) and I think happy users need a stable, solid and consistent UX. 
>> That would be provided by a NextStep based UI guideline. But they also need 
>> a pretty UI (which is not what you’d call that NextStep look nowadays, imho).
> 
> I would add to that: most users will not be using a GNUstep DE.  This was one 
> of the biggest mistakes that we made with Etoile: we did not have an 
> incremental adoption story.
> 
How do you know about users? I tried Etoile some time ago. 
My thoughts were: “Cool thing. Not ready for everyday usage yet”.
NEXTSPACE is. And it looks and feels familiar to Window Maker users.

> If you want GNUstep to be attractive to developers, you need to make it easy 
> for them to ship apps that integrate with an existing *NIX DE and with 
> Windows.  One of the biggest things that RedHat did for Linux desktop 
> usability was teach the GTK+ and Qt theme engines to understand a shared 
> format and unify shortcut keys between the two.  After that, it didn't matter 
> (much) if you needed a mix of GNOME and KDE apps, your desktop still felt 
> (approximately) cohesive.

Indeed. But keep in mind that GNOME and KDE apps share (with some minor 
differences) the same style for desktop and applications (icons on desktop, sys 
tray, in-window menus, scrollbars on the right and so on). That’s why it was 
quite natural to make look of Qt/GTK+ apps consistent (cohesive). GNUstep roots 
are in NeXT's OS (OpenStep specification appeared around 1997, NeXT and Apple 
started merging these days). This legacy has it’s own charm not because of look 
but mostly because of “feel” (style of doing things). That’s why I like GNUstep.
> 
> At the moment, people with one GNUstep app feel that it sticks out and is 
> difficult to use because it doesn't follow the same UI models as the rest of 
> their system.  That means that they then don't want a second one.
Sure. Let’s imagine that GNUstep application follows Qt/GTK+ UI model. I have a 
question: Why average developer will want to write application using GNUstep 
libraries instead of GNOME/KDE? What are the benefits?
> 
> Qt on Mac has the same problem: the controls are all subtly different and it 
> took them years to even have the same shortcuts for navigation in a text 
> field, so everyone who ran a Qt application on Mac hated it and never wanted 
> to use another one.  This didn't matter so much for Qt, because they did have 
> good Windows and X11 support.
> 
And because MacOS often has good alternatives to Qt applications. Qt was 
created commercial company (it means: more testers, more time to make 
development, etc.).

> Currently, GNUstep apps look and feel like native apps on MacOS, when you 
> don't use GNUstep.  They look and feel alien everywhere else.
> 
I agree. Also a lot of GNUstep apps look like “templates” - unfinished, buggy, 
loose.
I define for myself a “corner stone” for NEXTSPACE development - existing 
features must be fully completed and tested (usable).

> David

Sergii

Re: Package building

[David Chisnall]

On 20/11/2019 11:07, Andreas Fink wrote:

is libobjc even supporting all these other platforms?


The GCC runtime is written in pure C and so should work everywhere that 
there's a C compiler.  The GNUstep runtime uses assembly to implement 
two features that can't be implemented in pure C:


objc_msgSend
imp_implementationWithBlock

Both of these need to modify the call frame and then pass all of the 
arguments unmodified, which C doesn't support.


In theory, you should be able to use the runtime without these features, 
but I'm not sure if it actually builds (happy to take patches to fix that).


KVO is *significantly* simpler to implement with 
imp_implementationWithBlock, so it would be nice if we could depend on 
that.  objc_msgSend is largely a performance optimisation (clang uses it 
only on platforms where it's supported).


I'm happy to take contributions for the assembly paths for other 
architectures.  We currently have:


- x86-32
- x86-64
- AArch32
- AArch64
- MIPS (at least n64 works, I think o32 and n32 are there but untested).

I passionately hate PowerPC assembly, so will definitely not write that 
myself, but anyone who wants to add it is very welcome to do so.  I will 
probably get around to adding RISC-V support at some point.


David

Re: Package building

[Johannes Brakensiek]

On 19 Nov 2019, at 13:16, James Carthew wrote:

I've been toying with NextSpace in a VM. From my experience, if this 
gains a web browser and network settings panel (mostly for Wifi 
config), (and gets Debian packages) it could easily replace Mate on my 
machines. Linux desktop application development is terrible at the 
moment.


+1

GNUstep may not be the right answer for me, but I'm open to at least 
exploring it. NSMacintoshMenuStyle works in NextSpace, and I had 
Rik.theme built/working properly.


That’s promising to hear. I’m very interested in trying this out on 
Debian/Ubuntu!


I was hoping to get Etoile WildMenus running as well but ran out of 
time.


Would be very interesting.

NextSpace is definitely moving in the right direction. I think the 
focus on System settings is definitely the way to go. As someone who 
would like to get a mac-like desktop out of this eventually I'd like 
to see some of the options ported into SystemPreferences.app just 
because it's a more mac-like application.


Full ack.

But I like how NextSpace has the look/feel of NextStep, definitely 
keep it up. I know the ideal would be to port webkit to gnustep but at 
this point I'd be happy to just throw firefox into a gnustep window 
with an application menu.


+1

So I’m very much supporting Sergii in his approach. If his 
developments are going to be compatible with GNUstep upstream, I’d 
love to have/get this packaged and installable for my distribution of 
choice (Debian/Ubuntu) to recommend it to regular users.


Johannes

Re: Package building

[Andreas Fink]

> On 20 Nov 2019, at 12:02, Johannes Brakensiek  
> wrote:
> 
> 
> 
> On 20 Nov 2019, at 11:56, Ivan Vučica wrote:
> 
>> I think that, when you say “you are doing this”, you also miss the part 
>> where I am not a Debian developer and do not build the Debian source+binary 
>> packages that are shipped in Debian :-)
> 
> Yes, I’m sorry. I’ve been in contact about this issue with Yavor Doganov, not 
> with you. :) He was the one who told me about sticking to GCC because of the 
> architectures Debian supports/wants to support.
> 

Which platforms are we exactly talking about?

Is clang not supporting all these additional platforms?
is libobjc even supporting all these other platforms?

Re: Package building

[Ivan Vučica]

On Wed 20 Nov 2019 at 11:07, Andreas Fink  wrote:

>
> Which platforms are we exactly talking about?
>
> Is clang not supporting all these additional platforms?
> is libobjc even supporting all these other platforms?


Clearly yes — but Debian packages also use the GCC runtime, or they did
last time I checked.
-- 
Sent from Gmail Mobile

Re: Package building

[Johannes Brakensiek]

On 20 Nov 2019, at 11:56, Ivan Vučica wrote:

I think that, when you say “you are doing this”, you also miss the 
part where I am not a Debian developer and do not build the Debian 
source+binary packages that are shipped in Debian :-)


Yes, I’m sorry. I’ve been in contact about this issue with Yavor 
Doganov, not with you. :) He was the one who told me about sticking to 
GCC because of the architectures Debian supports/wants to support.

Re: Package building

[Ivan Vučica]

On Wed 20 Nov 2019 at 08:00, Johannes Brakensiek 
wrote:

>  I understand
> you are doing this for compatibility with other processor platforms. But
> this leads to the problem that any app developer who wants to build a
> new app based upon the clang ABI has to build and ship everything on his
> own. I really think this is a show blocker for attracting new developers
> (or even users). Or did I miss anything here?


I think that, when you say “you are doing this”, you also miss the part
where I am not a Debian developer and do not build the Debian source+binary
packages that are shipped in Debian :-)

>
> --
Sent from Gmail Mobile

Re: Package building

[David Chisnall]

On 20/11/2019 09:55, Richard Frith-Macdonald wrote:

I have never used a mixed configuration, but from what David's said in the past 
(I expect he will correct me if I'm wrong),  for the libraries ARC should work 
whether or not GNUstep is built with clang.


ARC and non-ARC work well together, but ARC depends on the non-fragile 
ABI, so you can't mix ARC and GCC-compiled code reliably.


In theory, the GNUstep runtime 1.x ABI supports mixing GCC-compiled code 
and non-fragile ABI code and it should work as long as the older ABI 
classes are closer to the roots of the class hierarchy than the newer 
ones.  In practice, there's a bug in the Linux (glibc?) run-time linker 
that means that ivar offsets are sometime incorrect when you do this.


The GNUstep Runtime 2.0 ABI is not supported by GCC and is a backwards 
compatibility break.  In hindsight, I probably should have done this 
from the start because there's a lot of legacy in the GCC runtime ABI 
(which is a minor tweak to the NeXTSTEP runtime ABI) that makes 
supporting newer language features very difficult.


David

Re: Package building

[Andreas Fink]

> On 20 Nov 2019, at 10:55, Richard Frith-Macdonald 
>  wrote:
> 
> 
> 
>> On 20 Nov 2019, at 08:37, Andreas Fink  wrote:
>> 
>> 
>> 
>>> On 20 Nov 2019, at 08:59, Johannes Brakensiek  
>>> wrote:
>>> 
>>> Hey Ivan,
>>> 
>>> thank you for your work and your explanations!
>>> 
>>> On 20 Nov 2019, at 3:10, Ivan Vučica wrote:
>>> 
 Now... developers may need updated versions when developing their apps. I 
 remember Debian not shipping with NSViewController or NSWindowController 
 when I first came around -- but on the other hand, when I would cut a 
 release, an updated .deb would follow. (Not to mention our source code 
 became much more discoverable, so seeing if a class is missing is much 
 easier too.)
 
 So when a developer needs a newer version so they can prepare a source 
 tarball for Debian to integrate... they can talk to us. We cut our 
 release, a Debian maintainer (e.g. Yavor) picks it up, the app gets picked 
 up too, everyone happy.
 
 Yes, I would say developers are very welcome to advocate with maintainers 
 for a release if not cutting one blocks their app's release. :-)
 
 And at this time, I am still here to help component maintainers with a 
 release. I may not do it on a tight schedule, but eventually I’ll find an 
 evening or two to tackle this kind of request.
 
 Do you have a specific anecdote about something you wanted up to date, as 
 a binary, which wasn’t in your favorite distro?
>>> 
>>> The problem simply is that f.e. Debian ships libs that are build with GCC 
>>> and thus are missing any of the new language features. I understand you are 
>>> doing this for compatibility with other processor platforms. But this leads 
>>> to the problem that any app developer who wants to build a new app based 
>>> upon the clang ABI has to build and ship everything on his own. I really 
>>> think this is a show blocker for attracting new developers (or even users). 
>>> Or did I miss anything here?
>>> 
>>> Johannes
>>> 
>> 
>> 
>> I can completely agree on this statement. Due to modern code using ARC 
>> everywhere, the gnustep coming with Debian (which is  my main deployment 
>> platform) is usually a problem. I always have to make sure its not installed 
>> and install my own packaged version. On the other hand I have not seen 
>> anyone using ObjectiveC without ARC these days.. Its nice to have for 
>> nostalgia but ARC has solved a million problems for me in my code over the 
>> last decades. So today, I would not even think to do anything with gnustep 
>> without clang.
>> 
>> Having a gnustep which works with arc and without arc would be ok. but 
>> shipping packaged versions with libraries which can not work with ARC is a 
>> show stopper.
>> 
>> And when GNUStep wants to continue following the development of OSX's 
>> platform, ARC is there since more than a decade and everyone depends on it. 
>> So if anyone wants to port OS X code to Linux and considers GNUStep as a 
>> logica platform, then ARC support is a must.
> 
> I have never used a mixed configuration, but from what David's said in the 
> past (I expect he will correct me if I'm wrong),  for the libraries ARC 
> should work whether or not GNUstep is built with clang.
> The libraries do not need to use ARC internally in order to be used by 
> software that is built for ARC, as long as they are built for the same 
> runtime.

there's the catch..  the current distros all come with the old runtime and 
thats where everything falls apart miserably.

> But if a distribution provides gnustep-make configured to use gcc, you would 
> need to install/configure your own version to use clang.
> 

Re: Package building

[Richard Frith-Macdonald]

> On 20 Nov 2019, at 08:37, Andreas Fink  wrote:
> 
> 
> 
>> On 20 Nov 2019, at 08:59, Johannes Brakensiek  
>> wrote:
>> 
>> Hey Ivan,
>> 
>> thank you for your work and your explanations!
>> 
>> On 20 Nov 2019, at 3:10, Ivan Vučica wrote:
>> 
>>> Now... developers may need updated versions when developing their apps. I 
>>> remember Debian not shipping with NSViewController or NSWindowController 
>>> when I first came around -- but on the other hand, when I would cut a 
>>> release, an updated .deb would follow. (Not to mention our source code 
>>> became much more discoverable, so seeing if a class is missing is much 
>>> easier too.)
>>> 
>>> So when a developer needs a newer version so they can prepare a source 
>>> tarball for Debian to integrate... they can talk to us. We cut our release, 
>>> a Debian maintainer (e.g. Yavor) picks it up, the app gets picked up too, 
>>> everyone happy.
>>> 
>>> Yes, I would say developers are very welcome to advocate with maintainers 
>>> for a release if not cutting one blocks their app's release. :-)
>>> 
>>> And at this time, I am still here to help component maintainers with a 
>>> release. I may not do it on a tight schedule, but eventually I’ll find an 
>>> evening or two to tackle this kind of request.
>>> 
>>> Do you have a specific anecdote about something you wanted up to date, as a 
>>> binary, which wasn’t in your favorite distro?
>> 
>> The problem simply is that f.e. Debian ships libs that are build with GCC 
>> and thus are missing any of the new language features. I understand you are 
>> doing this for compatibility with other processor platforms. But this leads 
>> to the problem that any app developer who wants to build a new app based 
>> upon the clang ABI has to build and ship everything on his own. I really 
>> think this is a show blocker for attracting new developers (or even users). 
>> Or did I miss anything here?
>> 
>> Johannes
>> 
> 
> 
> I can completely agree on this statement. Due to modern code using ARC 
> everywhere, the gnustep coming with Debian (which is  my main deployment 
> platform) is usually a problem. I always have to make sure its not installed 
> and install my own packaged version. On the other hand I have not seen anyone 
> using ObjectiveC without ARC these days.. Its nice to have for nostalgia but 
> ARC has solved a million problems for me in my code over the last decades. So 
> today, I would not even think to do anything with gnustep without clang.
> 
> Having a gnustep which works with arc and without arc would be ok. but 
> shipping packaged versions with libraries which can not work with ARC is a 
> show stopper.
> 
> And when GNUStep wants to continue following the development of OSX's 
> platform, ARC is there since more than a decade and everyone depends on it. 
> So if anyone wants to port OS X code to Linux and considers GNUStep as a 
> logica platform, then ARC support is a must.

I have never used a mixed configuration, but from what David's said in the past 
(I expect he will correct me if I'm wrong),  for the libraries ARC should work 
whether or not GNUstep is built with clang.
The libraries do not need to use ARC internally in order to be used by software 
that is built for ARC, as long as they are built for the same runtime.
But if a distribution provides gnustep-make configured to use gcc, you would 
need to install/configure your own version to use clang.

Re: Package building

[Andreas Fink]

> On 20 Nov 2019, at 08:59, Johannes Brakensiek  
> wrote:
> 
> Hey Ivan,
> 
> thank you for your work and your explanations!
> 
> On 20 Nov 2019, at 3:10, Ivan Vučica wrote:
> 
>> Now... developers may need updated versions when developing their apps. I 
>> remember Debian not shipping with NSViewController or NSWindowController 
>> when I first came around -- but on the other hand, when I would cut a 
>> release, an updated .deb would follow. (Not to mention our source code 
>> became much more discoverable, so seeing if a class is missing is much 
>> easier too.)
>> 
>> So when a developer needs a newer version so they can prepare a source 
>> tarball for Debian to integrate... they can talk to us. We cut our release, 
>> a Debian maintainer (e.g. Yavor) picks it up, the app gets picked up too, 
>> everyone happy.
>> 
>> Yes, I would say developers are very welcome to advocate with maintainers 
>> for a release if not cutting one blocks their app's release. :-)
>> 
>> And at this time, I am still here to help component maintainers with a 
>> release. I may not do it on a tight schedule, but eventually I’ll find an 
>> evening or two to tackle this kind of request.
>> 
>> Do you have a specific anecdote about something you wanted up to date, as a 
>> binary, which wasn’t in your favorite distro?
> 
> The problem simply is that f.e. Debian ships libs that are build with GCC and 
> thus are missing any of the new language features. I understand you are doing 
> this for compatibility with other processor platforms. But this leads to the 
> problem that any app developer who wants to build a new app based upon the 
> clang ABI has to build and ship everything on his own. I really think this is 
> a show blocker for attracting new developers (or even users). Or did I miss 
> anything here?
> 
> Johannes
> 


I can completely agree on this statement. Due to modern code using ARC 
everywhere, the gnustep coming with Debian (which is  my main deployment 
platform) is usually a problem. I always have to make sure its not installed 
and install my own packaged version. On the other hand I have not seen anyone 
using ObjectiveC without ARC these days.. Its nice to have for nostalgia but 
ARC has solved a million problems for me in my code over the last decades. So 
today, I would not even think to do anything with gnustep without clang.

Having a gnustep which works with arc and without arc would be ok. but shipping 
packaged versions with libraries which can not work with ARC is a show stopper.

And when GNUStep wants to continue following the development of OSX's platform, 
ARC is there since more than a decade and everyone depends on it. So if anyone 
wants to port OS X code to Linux and considers GNUStep as a logica platform, 
then ARC support is a must.

Re: Package building

[Johannes Brakensiek]

Hey Ivan,

thank you for your work and your explanations!

On 20 Nov 2019, at 3:10, Ivan Vučica wrote:

Now... developers may need updated versions when developing their 
apps. I remember Debian not shipping with NSViewController or 
NSWindowController when I first came around -- but on the other hand, 
when I would cut a release, an updated .deb would follow. (Not to 
mention our source code became much more discoverable, so seeing if a 
class is missing is much easier too.)


So when a developer needs a newer version so they can prepare a source 
tarball for Debian to integrate... they can talk to us. We cut our 
release, a Debian maintainer (e.g. Yavor) picks it up, the app gets 
picked up too, everyone happy.


Yes, I would say developers are very welcome to advocate with 
maintainers for a release if not cutting one blocks their app's 
release. :-)


And at this time, I am still here to help component maintainers with a 
release. I may not do it on a tight schedule, but eventually I’ll 
find an evening or two to tackle this kind of request.


Do you have a specific anecdote about something you wanted up to date, 
as a binary, which wasn’t in your favorite distro?


The problem simply is that f.e. Debian ships libs that are build with 
GCC and thus are missing any of the new language features. I understand 
you are doing this for compatibility with other processor platforms. But 
this leads to the problem that any app developer who wants to build a 
new app based upon the clang ABI has to build and ship everything on his 
own. I really think this is a show blocker for attracting new developers 
(or even users). Or did I miss anything here?


Johannes

Re: Package building

[Ivan Vučica]

On Wed 20 Nov 2019 at 00:48, cobjective  wrote:

>
>
> My initial idea was to make my dream come true - have NeXTSTEP for my own
> use: fast, reliable and consistent.
> I would be glad if other people share my taste. If you like
> macOS/KDE/GNOME - why should you use GNUstep-based DE?


GNUstep is not GNOME or KDE; GNUstep is GTK or Qt. It’s not a DE, it’s a
set of libraries to support development of desktop apps, backend services
and CLI tools.

That’s where work that you’re doing on Nextspace comes in, I think? GNUstep
core doesn’t have to declare “there is one DE and it’s NeXT-like”, it can
serve for app development for other desktops. Further work can be built on
top of that.

I have my own view of a GNUstep-based desktop — but I’m not feeling like
putting enough effort into it to make it come true :)
-- 
Sent from Gmail Mobile

Re: Package building

[Ivan Vučica]

On Tue, Nov 19, 2019, 12:20 Liam Proven  wrote:

>
> IMHO one of the problems of Étoilé was that it violated the core FOSS
> principle of "release early, release often". GNUstep comes close to
> the same.
>
> Sticking some source code on a version control system somewhere is not
> releasing something.
>
> Offering a set of binaries users can install is releasing.


I disagree. In FOSS, releasing source tarball is releasing, not offering a
set of binaries. Offering binaries for a FOSS platform is a bonus; only on
Windows and Mac would I expect to get a binary.

Not to mention, we don’t stick it on a version control system (tagging is
there just to help a bit); it goes to FTP, which is how FOSS and especially
GNU software is properly released. GPG signed and all.

Binaries are a bonus.

I want to
> see _at a minimum_ a Zip file or tarball I can grab, open and just run
> on my distro, whatever that distro is so long as it is mainstream.
>

Tarball with binaries? Not going to happen with libraries, which is what
GNUstep is. On FOSS *nix platforms, installing with a "wizard" is also not
the expected way to go.

.debs can be reasonably doubleclicked on, but again, GNUstep is a bunch of
libraries; do you want to manually install "redistributables" like Windows
games often do / require you to do?

Oh, and running a library (which is what GNUstep’s components are) is...
unlikely.

Remember, GNUstep is not and does not have a proper DE. We discussed having
a reference one, but there isn’t one at this time. You can get an
approximation with WindowMaker+GWorkspace+SystemPreferences+more, but this
is not actually The GNUstep Environment (because there isn’t one).

Nextspace and Etoile and such are not part of GNUstep, but their releases
would be their releases.

(Examples: Rocket.chat, Waterfox, Franz.)
>

These sound like end user applications?


> Neither Étoilé nor GNUstep does this minimal effort.
>
> Ideally, I want to see a repo I can add to my distro with a single
> command, then I can install $product _and get updates from then on_.


What is the $product? Which updates? :)


> Ubuntu PPA and Fedora COPR repos make this easy; openSUSE hosts the
> OBS and software.opensuse.org to offer equivalent functionality.
>

Ubuntu PPAs don't make it easy for developers, because I tried it. You
provide it with a Debian-formatted source package, not a binary package or
a raw tarball. It's great for the users, but you really have to be
subservient to Ubuntu's build infrastructure to upload to PPA. Oh, and
while you're working on the packaging, you have to upload the package to
their systems waiting in a build queue only to see everything fail and try
again. When I worked on it, it was nontrivial to reproduce their build
environment locally.

I can’t remember, but think I even got it to build with clang (can't
recall), and I thought I'd manage to automate it enough to make regular
updates or even nightly uploads.

But no, it was enough effort that I dropped it. The build rules are still
in gnustep-make; you can choose to create a source tarball, create a Debian
source package (extra tarball plus metadata, iirc), GPG sign it and upload
it to your PPA.

Prepare for pain, though.


> GNUstep doesn't do this, but it is at least well-enough known that
> most major distros include dated versions and I can just cobble
> together something that kinda-sorta works, a bit, from my distro's
> repos. It is only when I joined this list that I discovered that the
> Debian and Ubuntu bundles of GNUstep were very dated and that I needed
> to add third-party repos to get something vaguely current.
>

Debian and Ubuntu usually update rather quickly once a release is made. I
know because I drove the last few releases, and I got feedback from Yavor
rather quickly.

If maintainers of individual packages ask me, I can help with cutting a
release again. It's just a few hours of work, nothing to fret about:
analyze changelogs (compare VCS history with actual ChangeLog files),
update news files, check everything in, find the GPG key which I last used
months/years ago, wrestle with the rather long passphrase, cut a release,
upload the tarball and .sig to GitHub and FTP, and repeat that for all
packages.

This is even without cutting the Windows release, which I never did and
have no idea how to do, especially without a running Windows environment. I
had a dream of building the NSIS installer on Linux (mingw32 to build, NSIS
to package), but I never got around to it. I also wanted to switch to MSI,
but msi-tools on Linux don't know how to generate the UI tables in .msi
databases, so I dropped that.

Oh, right, and bumping the version or not depends on whether binary
compatibility broke, which is what I don't have the tooling to check so I
depend on Yavor's kind feedback when I prep a prerelease.

As I said, I can cut a release, but let's not say this is easy. It would be
easier if news files were correctly kept up to date, but it would become
harder if 

Re: Package building

[cobjective]

On 19 Nov 2019, at 11:40, Johannes Brakensiek  wrote:
> 
> Hi Sergii,
> 
> thank you for your reply!
> 
> On 19 Nov 2019, at 0:39, Sergii Stoian wrote:
> 
>> Frankly speaking I don’t like themes idea almost totally. It’s hard to 
>> achieve desired look and feel with themes without coding (overriding some 
>> class methods). Plus themes support bloats the GNUstep codebase.
> 
> I’m not into the details of the theming implementation, but to me it looks a 
> GNUstep based DE would be far from being bloated compared to other current 
> DEs. ;)
> 
I hope. ;)

>> I understand that the initial idea was to attract more users/developers, 
>> but… It’s not working.
> 
> Hm, yes. I think developers don’t need a nice UI at first place (and I think 
> most of what developers need luckily is already provided by Apple as of 
> today). But developers need happy users (if you’re not developing only for 
> yourself) and I think happy users need a stable, solid and consistent UX. 
> That would be provided by a NextStep based UI guideline. But they also need a 
> pretty UI (which is not what you’d call that NextStep look nowadays, imho).
> 
My initial idea was to make my dream come true - have NeXTSTEP for my own use: 
fast, reliable and consistent.
I would be glad if other people share my taste. If you like macOS/KDE/GNOME - 
why should you use GNUstep-based DE?

>> So, I want to make ideal NEXTSTEP interface first. Who knows maybe some day 
>> I’ll want to change it to macOS-like… ;)
> 
> I think: Do it (some days earlier). From a users perspective my heart was 
> filled with joy and happiness when I saw what Bertrand had compiled here: 
> https://github.com/BertrandDekoninck/rik.theme/blob/master/newscreen.png ;)
> 

> If we’d have some more screenshots of well crafted software looking like 
> this, it would be a huge benefit regarding the public impression of GNUstep. 
> It doesn’t need to be macOS, but to have a free DE that’s getting close 
> regarding UX/UI would be a thing I’d really like to see and work with. 
> (Especially since Apple is currently driving the development of macOS to a 
> state where I won’t want to use it anymore…)
> 
Great - it’s your choice. Just do it. ;)

>> Etoile is great effort to create macOS-like DE with great fundamental 
>> frameworks inside. I wish to borrow some  of them someday… But its 
>> development stopped AFAIK.
> 
> Yes, sadly. Merge it, use it. Once I come to start writing a serious app I’ll 
> give CoreObject a try and see how it works. ;)
> 
> Keep up your good work
Thank you. I’ll do all my best.
> Johannes
> 

Sergii

Re: Package building

[cobjective]

On 19 Nov 2019, at 10:03, Fred Kiefer  wrote:
> 
>> Am 19.11.2019 um 00:42 schrieb Sergii Stoian :
>> 
>> On Nov 15, 2019, at 10:44, Fred Kiefer  wrote:
>>> 
 Am 15.11.2019 um 09:13 schrieb Johannes Brakensiek 
 :
 
 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

Re: Package building

[Matt Butch]

> On Nov 19, 2019, at 07:17, Liam Proven  wrote:
> 
> Ideally, I want to see a repo I can add to my distro with a single
> command, then I can install $product _and get updates from then on_.
> Ubuntu PPA and Fedora COPR repos make this easy; openSUSE hosts the
> OBS and software.opensuse.org to offer equivalent functionality.

I would love to get a GNUstep PPA.


--

Matthew Butch
President
Volitans Software
Developer of SMART Utility, the hard drive diagnostic application
http://www.volitans-software.com

Sent with Mac OS X High Sierra Mail 11.4 (3445.8.2)

Re: Package building

[H. Nikolaus Schaller]

> Am 19.11.2019 um 13:17 schrieb Liam Proven :
> 
> Ideally, I want to see a repo I can add to my distro with a single
> command, then I can install $product _and get updates from then on_.
> Ubuntu PPA and Fedora COPR repos make this easy; openSUSE hosts the
> OBS and software.opensuse.org to offer equivalent functionality.

You may take a look at how mySTEP / QuantumSTEP is doing this.
Just needs to add something to /etc/apt/source.list.d and then
apt-get update + apt-get install quantumstep.

But I must admit that it also fails in describing this step
at a well known place. It is hidden in a deep link [1].

And at the moment it is not supporting up-to-date base distros
(e.g. Stretch, Buster, Sid) due to library incompatibilities.

BR,
Nikolaus

[1]: http://projects.goldelico.com/p/quantumstep/page/Installation/

Re: Package building

[Johannes Brakensiek]

Hey everyone,

thank you, reads very well. :)

To sum it up, some whishful thinking:

1. Integrate apps on a short-term basis. (Updated) themes for Gtk, Qt, 
keyboard shortcuts, support for drag ’n drop per default (!). (It 
works, look at Josh’s PikoPixel.)
2. Release early, release often. Have package repos that are 
continuously updated and are installable.
3. Continue making a decent looking DE work for everyday tasks (I think 
it’s for the long run, but I’d still highly appreciate one).


I hope I’ll be able to have a try on 2 for Ubuntu/Debian, but not 
before the end of the year.


Johannes

Re: Package building

[Liam Proven]

On Tue, 19 Nov 2019 at 12:42, David Chisnall  wrote:
>
> I would add to that: most users will not be using a GNUstep DE.  This
> was one of the biggest mistakes that we made with Etoile: we did not
> have an incremental adoption story.

I am very hesitant to differ here, because I hugely respect your work
and your writing and often cite your ACM "C is not a low-level
language" article.

But I disagree here, and with some subsequent points.

> If you want GNUstep to be attractive to developers, you need to make it
> easy for them to ship apps that integrate with an existing *NIX DE and
> with Windows.

True.

> One of the biggest things that RedHat did for Linux
> desktop usability was teach the GTK+ and Qt theme engines to understand
> a shared format and unify shortcut keys between the two.

Interesting point. I loved the Bluecurve effort, myself, and I was sad
that it didn't catch on. I wanted to slap the many KDE users and devs
I saw complaining about it; in the KDE 3 timeframe, IMHO Bluecurve was
the _only_ theme that ever made KDE look anything less than horrible.
Bluecurve was actually attractive and professional-looking, something
no release of KDE since 1.x has ever been for me.

I confess I had missed the broader significance that you point out:
that KDE/GNOME/Cinnamon/Maté/Xfce/LX?? apps all look and work broadly
similarly enough now that they do not stick out too badly when run
under each others' desktops.

>  After that, it
> didn't matter (much) if you needed a mix of GNOME and KDE apps, your
> desktop still felt (approximately) cohesive.

True.

> At the moment, people with one GNUstep app feel that it sticks out and
> is difficult to use because it doesn't follow the same UI models as the
> rest of their system.  That means that they then don't want a second one.
>
> Qt on Mac has the same problem: the controls are all subtly different
> and it took them years to even have the same shortcuts for navigation in
> a text field, so everyone who ran a Qt application on Mac hated it and
> never wanted to use another one.  This didn't matter so much for Qt,
> because they did have good Windows and X11 support.
>
> Currently, GNUstep apps look and feel like native apps on MacOS, when
> you don't use GNUstep.  They look and feel alien everywhere else.

This also is true.

But if I may be so bold:

IMHO one of the problems of Étoilé was that it violated the core FOSS
principle of "release early, release often". GNUstep comes close to
the same.

Sticking some source code on a version control system somewhere is not
releasing something.

Offering a set of binaries users can install is releasing. I want to
see _at a minimum_ a Zip file or tarball I can grab, open and just run
on my distro, whatever that distro is so long as it is mainstream.

(Examples: Rocket.chat, Waterfox, Franz.)

Neither Étoilé nor GNUstep does this minimal effort.

Ideally, I want to see a repo I can add to my distro with a single
command, then I can install $product _and get updates from then on_.
Ubuntu PPA and Fedora COPR repos make this easy; openSUSE hosts the
OBS and software.opensuse.org to offer equivalent functionality.

GNUstep doesn't do this, but it is at least well-enough known that
most major distros include dated versions and I can just cobble
together something that kinda-sorta works, a bit, from my distro's
repos. It is only when I joined this list that I discovered that the
Debian and Ubuntu bundles of GNUstep were very dated and that I needed
to add third-party repos to get something vaguely current.

Periodically there have been all-in-one demo disks of GNUstep (GNUstep
Live, Simply GNUstep, etc.) to show off what it can do. AFAIK Étoilé
never even got this.

If the only way to try something out is to compile it yourself, then I
am probably never going to bother. That's too much work for me, and I
suspect this is true for 90% or more of Linux users.

-- 
Liam Proven - Profile: https://about.me/liamproven
Email: lpro...@cix.co.uk - Google Mail/Hangouts/Plus: lpro...@gmail.com
Twitter/Facebook/Flickr: lproven - Skype/LinkedIn: liamproven
UK: +44 7939-087884 - ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053

Re: Package building

[Umberto Cerrato]

This...

> Il giorno 19 nov 2019, alle ore 12:42, David Chisnall 
>  ha scritto:
> 
> On 19/11/2019 09:40, Johannes Brakensiek wrote:
>>> I understand that the initial idea was to attract more users/developers, 
>>> but… It’s not working.
>> Hm, yes. I think developers don’t need a nice UI at first place (and I think 
>> most of what developers need luckily is already provided by Apple as of 
>> today). But developers need happy users (if you’re not developing only for 
>> yourself) and I think happy users need a stable, solid and consistent UX. 
>> That would be provided by a NextStep based UI guideline. But they also need 
>> a pretty UI (which is not what you’d call that NextStep look nowadays, imho).
> 
> I would add to that: most users will not be using a GNUstep DE.  This was one 
> of the biggest mistakes that we made with Etoile: we did not have an 
> incremental adoption story.
> 
> If you want GNUstep to be attractive to developers, you need to make it easy 
> for them to ship apps that integrate with an existing *NIX DE and with 
> Windows.  One of the biggest things that RedHat did for Linux desktop 
> usability was teach the GTK+ and Qt theme engines to understand a shared 
> format and unify shortcut keys between the two.  After that, it didn't matter 
> (much) if you needed a mix of GNOME and KDE apps, your desktop still felt 
> (approximately) cohesive.
> 
> At the moment, people with one GNUstep app feel that it sticks out and is 
> difficult to use because it doesn't follow the same UI models as the rest of 
> their system.  That means that they then don't want a second one.
> 
> Qt on Mac has the same problem: the controls are all subtly different and it 
> took them years to even have the same shortcuts for navigation in a text 
> field, so everyone who ran a Qt application on Mac hated it and never wanted 
> to use another one.  This didn't matter so much for Qt, because they did have 
> good Windows and X11 support.
> 
> Currently, GNUstep apps look and feel like native apps on MacOS, when you 
> don't use GNUstep.  They look and feel alien everywhere else.
> 
> David
> 

Re: Package building

[Umberto Cerrato]

And this...

Agreed with both of you :)

Il giorno 19 nov 2019, alle ore 12:49, Ivan Vučica 
mailto:ivuc...@gmail.com>> ha scritto:

On Mon, Nov 18, 2019, 23:40 Sergii Stoian 
mailto:stoyan...@gmail.com>> wrote:
Plus themes support bloats the GNUstep codebase. I understand that the initial 
idea was to attract more users/developers, but… It’s not working.

Have you guessed why it's not working?

Users who would be attracted by a different theme are not aware there are 
different themes or how to set them up.

A solution is to ship a "gnustep-recommended-config" package as a Recommends of 
the libgnustep-gui package. Speaking in Debian terms; same goes for other OSes.

This package would pull in a theme and a systemwide plist configuring a 
modernized theme etc.

Today, if a KDE user born in 2001 installs a GNUstep program (they may not care 
about the rest of the environment), the UI is totally out of sync with their 
expectations. And if they go through the effort to explore an entire 
environment, they get greeted by the 90s — whether they want it or not.

Am I misreading expectations of a prospective user?

I mean, these are my expectations, and I'm born in the late 80s. I love e.g. 
System 7 look. NEXT look is decent to me (but just decent). I'm personally 
around for the programming language and the frameworks, not for the default 
theme.

Nextspace seems cool and I should get around to trying it out.

Re: Package building

[James Carthew]

I've been toying with NextSpace in a VM. From my experience, if this gains
a web browser and network settings panel (mostly for Wifi config), (and
gets Debian packages) it could easily replace Mate on my machines. Linux
desktop application development is terrible at the moment. GNUstep may not
be the right answer for me, but I'm open to at least exploring it.
NSMacintoshMenuStyle works in NextSpace, and I had Rik.theme built/working
properly. I was hoping to get Etoile WildMenus running as well but ran out
of time. NextSpace is definitely moving in the right direction. I think the
focus on System settings is definitely the way to go. As someone who would
like to get a mac-like desktop out of this eventually I'd like to see some
of the options ported into SystemPreferences.app just because it's a more
mac-like application. But I like how NextSpace has the look/feel of
NextStep, definitely keep it up. I know the ideal would be to port webkit
to gnustep but at this point I'd be happy to just throw firefox into a
gnustep window with an application menu.

On Tue, 19 Nov 2019 at 22:49, Ivan Vučica  wrote:

> On Mon, Nov 18, 2019, 23:40 Sergii Stoian  wrote:
>
>> Plus themes support bloats the GNUstep codebase. I understand that the
>> initial idea was to attract more users/developers, but… It’s not working.
>>
>
> Have you guessed why it's not working?
>
> Users who would be attracted by a different theme are not aware there are
> different themes or how to set them up.
>
> A solution is to ship a "gnustep-recommended-config" package as a
> Recommends of the libgnustep-gui package. Speaking in Debian terms; same
> goes for other OSes.
>
> This package would pull in a theme and a systemwide plist configuring a
> modernized theme etc.
>
> Today, if a KDE user born in 2001 installs a GNUstep program (they may not
> care about the rest of the environment), the UI is totally out of sync with
> their expectations. And if they go through the effort to explore an entire
> environment, they get greeted by the 90s — whether they want it or not.
>
> Am I misreading expectations of a prospective user?
>
> I mean, these are my expectations, and I'm born in the late 80s. I love
> e.g. System 7 look. NEXT look is decent to me (but just decent). I'm
> personally around for the programming language and the frameworks, not for
> the default theme.
>
> Nextspace seems cool and I should get around to trying it out.
>
>>

Re: Package building

[Gregory Casamento]

Ivan,

I think you're spot on with this assessment.

GC

[image: Mailtrack]

Sender
notified by
Mailtrack

11/19/19,
07:14:52 AM

On Tue, Nov 19, 2019 at 6:49 AM Ivan Vučica  wrote:

> On Mon, Nov 18, 2019, 23:40 Sergii Stoian  wrote:
>
>> Plus themes support bloats the GNUstep codebase. I understand that the
>> initial idea was to attract more users/developers, but… It’s not working.
>>
>
> Have you guessed why it's not working?
>
> Users who would be attracted by a different theme are not aware there are
> different themes or how to set them up.
>
> A solution is to ship a "gnustep-recommended-config" package as a
> Recommends of the libgnustep-gui package. Speaking in Debian terms; same
> goes for other OSes.
>
> This package would pull in a theme and a systemwide plist configuring a
> modernized theme etc.
>
> Today, if a KDE user born in 2001 installs a GNUstep program (they may not
> care about the rest of the environment), the UI is totally out of sync with
> their expectations. And if they go through the effort to explore an entire
> environment, they get greeted by the 90s — whether they want it or not.
>
> Am I misreading expectations of a prospective user?
>
> I mean, these are my expectations, and I'm born in the late 80s. I love
> e.g. System 7 look. NEXT look is decent to me (but just decent). I'm
> personally around for the programming language and the frameworks, not for
> the default theme.
>
> Nextspace seems cool and I should get around to trying it out.
>
>>

-- 
Gregory Casamento
GNUstep Lead Developer / OLC, Principal Consultant
http://www.gnustep.org - http://heronsperch.blogspot.com
http://ind.ie/phoenix/

Re: Package building

[Ivan Vučica]

On Mon, Nov 18, 2019, 23:40 Sergii Stoian  wrote:

> Plus themes support bloats the GNUstep codebase. I understand that the
> initial idea was to attract more users/developers, but… It’s not working.
>

Have you guessed why it's not working?

Users who would be attracted by a different theme are not aware there are
different themes or how to set them up.

A solution is to ship a "gnustep-recommended-config" package as a
Recommends of the libgnustep-gui package. Speaking in Debian terms; same
goes for other OSes.

This package would pull in a theme and a systemwide plist configuring a
modernized theme etc.

Today, if a KDE user born in 2001 installs a GNUstep program (they may not
care about the rest of the environment), the UI is totally out of sync with
their expectations. And if they go through the effort to explore an entire
environment, they get greeted by the 90s — whether they want it or not.

Am I misreading expectations of a prospective user?

I mean, these are my expectations, and I'm born in the late 80s. I love
e.g. System 7 look. NEXT look is decent to me (but just decent). I'm
personally around for the programming language and the frameworks, not for
the default theme.

Nextspace seems cool and I should get around to trying it out.

>

Re: Package building

[David Chisnall]

On 19/11/2019 09:40, Johannes Brakensiek wrote:
I understand that the initial idea was to attract more 
users/developers, but… It’s not working.


Hm, yes. I think developers don’t need a nice UI at first place (and I 
think most of what developers need luckily is already provided by Apple 
as of today). But developers need happy users (if you’re not developing 
only for yourself) and I think happy users need a stable, solid and 
consistent UX. That would be provided by a NextStep based UI guideline. 
But they also need a pretty UI (which is not what you’d call that 
NextStep look nowadays, imho).


I would add to that: most users will not be using a GNUstep DE.  This 
was one of the biggest mistakes that we made with Etoile: we did not 
have an incremental adoption story.


If you want GNUstep to be attractive to developers, you need to make it 
easy for them to ship apps that integrate with an existing *NIX DE and 
with Windows.  One of the biggest things that RedHat did for Linux 
desktop usability was teach the GTK+ and Qt theme engines to understand 
a shared format and unify shortcut keys between the two.  After that, it 
didn't matter (much) if you needed a mix of GNOME and KDE apps, your 
desktop still felt (approximately) cohesive.


At the moment, people with one GNUstep app feel that it sticks out and 
is difficult to use because it doesn't follow the same UI models as the 
rest of their system.  That means that they then don't want a second one.


Qt on Mac has the same problem: the controls are all subtly different 
and it took them years to even have the same shortcuts for navigation in 
a text field, so everyone who ran a Qt application on Mac hated it and 
never wanted to use another one.  This didn't matter so much for Qt, 
because they did have good Windows and X11 support.


Currently, GNUstep apps look and feel like native apps on MacOS, when 
you don't use GNUstep.  They look and feel alien everywhere else.


David

Re: Package building

[Liam Proven]

On Sat, 2 Nov 2019 at 23:49, cobjective  wrote:
>
> Could you please share some details on what exactly do you plan to do?
> The paragraph above sounds the same as what NEXTSPACE project is developed 
> for.

It may be, but I do not like and do not use RH-family Linuxes.

If I was to use a GNUstep-based distro, ideally, it would be based on
Ubuntu, or failing that, Debian/Devuan, and failing that, openSUSE, as
those are the distros with the packaging tools, driver/codec/etc
support and so on that I find the best.

-- 
Liam Proven - Profile: https://about.me/liamproven
Email: lpro...@cix.co.uk - Google Mail/Hangouts/Plus: lpro...@gmail.com
Twitter/Facebook/Flickr: lproven - Skype/LinkedIn: liamproven
UK: +44 7939-087884 - ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053

Re: Package building

[Liam Proven]

On Sat, 2 Nov 2019 at 15:37, Johannes Brakensiek
 wrote:

> I'd like to see this
> being done using https://openbuildservice.org/ f.e.

This has been a low-priority item on my to-do list for 2 years now,
ever since I came to work at SUSE. Unfortunately I've not had free
(work) time to look at it yet.

I welcome pointers or hints!

-- 
Liam Proven - Profile: https://about.me/liamproven
Email: lpro...@cix.co.uk - Google Mail/Hangouts/Plus: lpro...@gmail.com
Twitter/Facebook/Flickr: lproven - Skype/LinkedIn: liamproven
UK: +44 7939-087884 - ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053

Re: Package building

[Johannes Brakensiek]

Hi Sergii,

thank you for your reply!

On 19 Nov 2019, at 0:39, Sergii Stoian wrote:

Frankly speaking I don’t like themes idea almost totally. It’s 
hard to achieve desired look and feel with themes without coding 
(overriding some class methods). Plus themes support bloats the 
GNUstep codebase.


I’m not into the details of the theming implementation, but to me it 
looks a GNUstep based DE would be far from being bloated compared to 
other current DEs. ;)


I understand that the initial idea was to attract more 
users/developers, but… It’s not working.


Hm, yes. I think developers don’t need a nice UI at first place (and I 
think most of what developers need luckily is already provided by Apple 
as of today). But developers need happy users (if you’re not 
developing only for yourself) and I think happy users need a stable, 
solid and consistent UX. That would be provided by a NextStep based UI 
guideline. But they also need a pretty UI (which is not what you’d 
call that NextStep look nowadays, imho).


So, I want to make ideal NEXTSTEP interface first. Who knows maybe 
some day I’ll want to change it to macOS-like… ;)


I think: Do it (some days earlier). From a users perspective my heart 
was filled with joy and happiness when I saw what Bertrand had compiled 
here: 
https://github.com/BertrandDekoninck/rik.theme/blob/master/newscreen.png 
;)


If we’d have some more screenshots of well crafted software looking 
like this, it would be a huge benefit regarding the public impression of 
GNUstep. It doesn’t need to be macOS, but to have a free DE that’s 
getting close regarding UX/UI would be a thing I’d really like to see 
and work with. (Especially since Apple is currently driving the 
development of macOS to a state where I won’t want to use it 
anymore…)


Etoile is great effort to create macOS-like DE with great fundamental 
frameworks inside. I wish to borrow some  of them someday… But its 
development stopped AFAIK.


Yes, sadly. Merge it, use it. Once I come to start writing a serious app 
I’ll give CoreObject a try and see how it works. ;)


Keep up your good work
Johannes

Re: Package building

[Fred Kiefer]

> Am 19.11.2019 um 00:42 schrieb Sergii Stoian :
> 
> On Nov 15, 2019, at 10:44, Fred Kiefer  wrote:
>> 
>>> Am 15.11.2019 um 09:13 schrieb Johannes Brakensiek 
>>> :
>>> 
>>> 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.
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.

Fred

Re: Package building

[Sergii Stoian]

Hi Fred,

On Nov 15, 2019, at 10:44, Fred Kiefer  wrote:
> 
>> Am 15.11.2019 um 09:13 schrieb Johannes Brakensiek 
>> :
>> 
>> 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?

> 
> Fred

Re: Package building

[Sergii Stoian]

Hi Johannes,

On Nov 15, 2019, at 10:13, Johannes Brakensiek  wrote:

> Hi Sergii,
> 
> 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.

Interesting idea… I’ll look at it later.

> 
>>> If you would build your work for NEXTSPACE in a way like this, a big hurdle 
>>> regarding the basic libraries would be already achieved of course. 
>>> Providing an app would be easy and installing an app would be as simple as 
>>> „apt install my.app“ then.
>> Current state of the NEXTSPACE is somewhat special… I use particular (not 
>> cutting edge) versions of GNUstep libraries (gui and back) with custom 
>> patches. So build (or CI) process - along the NEXTSPACE part - should build 
>> custom GNUstep libraries. Is it fit to your goals?
> 
> Well, currently not. But as soon as you are able to use the upstream libs it 
> would be of great use of course.

Some patches already went upstream, some others not yet. It’s planned anyway. I 
use ART backend and it stopped working after 0.25.0 release. I need to fix ART 
first before I can return to master branch...

> 
>>> Once this is done I would like to build a package applying some nice icons 
>>> and styling like Bertrand has created and bundled in his repositories.
>> NEXTSPACE contains its own fonts, icons and mouse cursors with true NeXTSTEP 
>> look and feel. I’m afraid it is not what you want to do.
> 
> Yeah, it’s not as well. But did you obtain the ability of GNUstep for using 
> themes? That way one could use the software you wrote and create a friendly 
> fork providing a different look and feel. That would allow some merges with 
> the development of the Etoile project f.e. and would be a very nice thing, in 
> my opinion. It seems to me this community is too small for having multiple 
> desktop approaches, considering the aim one should be useful for everyday 
> tasks once.
> 
Frankly speaking I don’t like themes idea almost totally. It’s hard to achieve 
desired look and feel with themes without coding (overriding some class 
methods). Plus themes support bloats the GNUstep codebase. I understand that 
the initial idea was to attract more users/developers, but… It’s not working.
So, I want to make ideal NEXTSTEP interface first. Who knows maybe some day 
I’ll want to change it to macOS-like… ;)

Etoile is great effort to create macOS-like DE with great fundamental 
frameworks inside. I wish to borrow some  of them someday… But its development 
stopped AFAIK. 
> 
>>> (To test the libraries I have built I’m trying to make GWorkspace work. I’m 
>>> doing this to get known to the environment and to check out whether there 
>>> are bugs within GWorkspace, the libraries or my setup. When you have a new 
>>> Workspace working once I’d like to test it as well.)
>> NEXTSPACE has it’s own genuine Workspace, Window Manager, Preferences, 
>> Terminal and so on. It’s already working and functional - give it a try. :)
> 
> Sounds great. Regarding upstream compatibility see my question/thoughts above.
> 
> Johannes
> 

Re: Package building

[Fred Kiefer]

> Am 15.11.2019 um 09:13 schrieb Johannes Brakensiek :
> 
> 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.

Fred

Re: Package building

[Johannes Brakensiek]

Hi Sergii,

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.


If you would build your work for NEXTSPACE in a way like this, a big 
hurdle regarding the basic libraries would be already achieved of 
course. Providing an app would be easy and installing an app would be 
as simple as „apt install my.app“ then.
Current state of the NEXTSPACE is somewhat special… I use particular 
(not cutting edge) versions of GNUstep libraries (gui and back) with 
custom patches. So build (or CI) process - along the NEXTSPACE part - 
should build custom GNUstep libraries. Is it fit to your goals?


Well, currently not. But as soon as you are able to use the upstream 
libs it would be of great use of course.


Once this is done I would like to build a package applying some nice 
icons and styling like Bertrand has created and bundled in his 
repositories.
NEXTSPACE contains its own fonts, icons and mouse cursors with true 
NeXTSTEP look and feel. I’m afraid it is not what you want to do.


Yeah, it’s not as well. But did you obtain the ability of GNUstep for 
using themes? That way one could use the software you wrote and create a 
friendly fork providing a different look and feel. That would allow some 
merges with the development of the Etoile project f.e. and would be a 
very nice thing, in my opinion. It seems to me this community is too 
small for having multiple desktop approaches, considering the aim one 
should be useful for everyday tasks once.



(To test the libraries I have built I’m trying to make GWorkspace 
work. I’m doing this to get known to the environment and to check 
out whether there are bugs within GWorkspace, the libraries or my 
setup. When you have a new Workspace working once I’d like to test 
it as well.)
NEXTSPACE has it’s own genuine Workspace, Window Manager, 
Preferences, Terminal and so on. It’s already working and functional 
- give it a try. :)


Sounds great. Regarding upstream compatibility see my question/thoughts 
above.


Johannes

Re: Package building

[Sergii Stoian]

On Nov 3, 2019, at 22:02, Johannes Brakensiek  wrote:

> Hi Sergii,
> 
> thank you for your response!
> 
> On 2 Nov 2019, at 23:48, cobjective wrote:
> 
>> Could you please share some details on what exactly do you plan to do?
>> The paragraph above sounds the same as what NEXTSPACE project is developed 
>> for.
> 
> 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?).

> If you would build your work for NEXTSPACE in a way like this, a big hurdle 
> regarding the basic libraries would be already achieved of course. Providing 
> an app would be easy and installing an app would be as simple as „apt install 
> my.app“ then.
Current state of the NEXTSPACE is somewhat special… I use particular (not 
cutting edge) versions of GNUstep libraries (gui and back) with custom patches. 
So build (or CI) process - along the NEXTSPACE part - should build custom 
GNUstep libraries. Is it fit to your goals?

> 
> Once this is done I would like to build a package applying some nice icons 
> and styling like Bertrand has created and bundled in his repositories.
NEXTSPACE contains its own fonts, icons and mouse cursors with true NeXTSTEP 
look and feel. I’m afraid it is not what you want to do.

> 
> (To test the libraries I have built I’m trying to make GWorkspace work. I’m 
> doing this to get known to the environment and to check out whether there are 
> bugs within GWorkspace, the libraries or my setup. When you have a new 
> Workspace working once I’d like to test it as well.)
NEXTSPACE has it’s own genuine Workspace, Window Manager, Preferences, Terminal 
and so on. It’s already working and functional - give it a try. :)

> 
> Johannes
> 

Sergii

Re: Package building

[Riccardo Mottola]

Hi Johannes,


don't hijack threads :-P I almost missed your mail.

Johannes Brakensiek wrote:

Another topic that's quite important for me to get into developing a
serious app is a stable and decent clang build and run environment. I'm
considering this as important as providing some nice looking graphics
(which Bertrand is providing f.e.) to make GNUstep GUI a little more
convenient to use and more successful in numbers of users.


A convenient advice: that is why I love GCC. On *all* my systems except 
FreeBSD and OpenBSD, it is the most reliable way to install and get 
GNUstep running.



So I'm really missing some packages providing this for GNU/Linux x64
(and maybe armhf using the runtime version 1.9). I'd like to see this
being done usinghttps://openbuildservice.org/  f.e. Maybe I'll have some
time to look into this at the end of the year.


By using GCC, I run GNUstep reliably on Raspberry PI 1 with NetBSD and 
Raspbian, and on PI3 with, again, Raspbian.
Wonderful how data-extraction tools and visualization tools I use on 
other high-end systems with GNUstep run fine on the PI-3, to the point 
where I will probably make a demo-device of it as soon as I can.




I highly appreciate the hard work of commitment and love of the
community in the past to achieve what GNUstep currently is. But in my
point of view it needs some further work and some concentration on
delivering a convenient user and developer experience today.


Just checked that GWorkspace and PDFKit run fine on NetBSD/amd64 9.99 . 
Some minor fixes where needed.


Riccardo

Re: Package building

[Johannes Brakensiek]

Hi Sergii,

thank you for your response!

On 2 Nov 2019, at 23:48, cobjective wrote:


Could you please share some details on what exactly do you plan to do?
The paragraph above sounds the same as what NEXTSPACE project is 
developed for.


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/


If you would build your work for NEXTSPACE in a way like this, a big 
hurdle regarding the basic libraries would be already achieved of 
course. Providing an app would be easy and installing an app would be as 
simple as „apt install my.app“ then.


Once this is done I would like to build a package applying some nice 
icons and styling like Bertrand has created and bundled in his 
repositories.


(To test the libraries I have built I’m trying to make GWorkspace 
work. I’m doing this to get known to the environment and to check out 
whether there are bugs within GWorkspace, the libraries or my setup. 
When you have a new Workspace working once I’d like to test it as 
well.)


Johannes

Re: Package building

[cobjective]

> On Nov 2, 2019, at 16:37, Johannes Brakensiek  
> wrote:
> 
> Am 02.11.19 um 15:20 schrieb Johannes Brakensiek:
>> It can be used in conjunction of CI tools such as drone.io as well as
>> described here: https://thomas-leister.de/en/drone-ci-with-codeberg/
> 
> Another topic that's quite important for me to get into developing a
> serious app is a stable and decent clang build and run environment. I'm
> considering this as important as providing some nice looking graphics
> (which Bertrand is providing f.e.) to make GNUstep GUI a little more
> convenient to use and more successful in numbers of users.
> 
> So I'm really missing some packages providing this for GNU/Linux x64
> (and maybe armhf using the runtime version 1.9). I'd like to see this
> being done using https://openbuildservice.org/ f.e. Maybe I'll have some
> time to look into this at the end of the year.
> 
> I highly appreciate the hard work of commitment and love of the
> community in the past to achieve what GNUstep currently is. But in my
> point of view it needs some further work and some concentration on
> delivering a convenient user and developer experience today.

Could you please share some details on what exactly do you plan to do?
The paragraph above sounds the same as what NEXTSPACE project is developed for.

> 
> Johannes


Sergii Stoian
NEXTSPACE owner