Re: Package building

[David Chisnall]

On 20 Nov 2019, at 23:13, cobjective <stoyan255@gmail.com> wrote:
> 
> On 19 Nov 2019, at 13:42, David Chisnall <gnustep@theravensnest.org> 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 some of the newer reactive UI frameworks feel like they need a lot 
less boilerplate.

David