On Thu, Nov 21, 2019 at 10:47 AM David Chisnall <[email protected]> wrote:
> On 20 Nov 2019, at 23:13, cobjective <[email protected]> wrote: > > > > On 19 Nov 2019, at 13:42, David Chisnall <[email protected]> > 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 > > Sergii
