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.
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 minimal efforts? I would create the following design (in MVC design pattern terms):
- Model (notes storage) with something cross-platform with ability to use it from other languages/UI toolkits (C, C++);
- View and Controller: UIKit for MacOS and iOS, Qt for Windows, Linux and Android(?)
Have I missed something?
It's sad, but it's true: I see only one place for GNUstep in this scenario - move Linux code into MacOS/iOS camp. If it's correct, then GNUstep should adopt MacOS/iOS/GNOME UI/UX style (look and feel) completely.
>> 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.
The answer is: yes (that's why I'm here). But... If Qt or GTK+ usage give me more seamless integration into desktop environment I would use Qt or GTK+.
As an example: in NEXTSPACE's SystemKit there's a part that deals with UDisks to handle volumes events. Actually it's a wrap around UDisks C code. SoundKit is a warp around PulseAudio libs.
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.
P.S.: no matter if NEXTSPACE will have users - I've wrote a code that, I hope, will make integration of GNUstep applications easier to the modern Linux DE.
David