[HN Gopher] GNUstep: Open-source, Object-oriented, Cross-platfor...
___________________________________________________________________
GNUstep: Open-source, Object-oriented, Cross-platform Development
Environment
Author : ecliptik
Score : 304 points
Date : 2021-12-13 06:11 UTC (16 hours ago)
(HTM) web link (gnustep.org)
(TXT) w3m dump (gnustep.org)
| oefrha wrote:
| The last time I evaluated a small, supposedly cross-platform
| framework which uses GNUstep for macOS, I quickly realized
| there's no obvious or even documented way to install the
| development libraries on macOS: there's no Homebrew formula, a
| broken MacPorts port that was last updated ages ago (I'm not sure
| if it includes the development libraries or just a desktop
| suite), and some ancient, partial instructions on the wiki. I
| guess the only way to install it is to grab the source and try to
| get it to build, but everything about it screams "don't use".
| soraminazuki wrote:
| WINE doesn't seem to be packaged in Scoop, MSYS2, or
| Chocolatey. Yet none of that would be a dealbreaker when using
| WINE.
|
| A quick search reveals that GNUStep is packaged in Debian,
| Fedora, NixOS, OpenSUSE, Arch, Gentoo, Void, FreeBSD, OpenBSD,
| and more [1]. I think that should be enough to cover most
| platforms that people would actually want to use GNUStep on.
|
| [1]: https://repology.org/project/gnustep-base/versions
| bogwog wrote:
| GNUstep is not WINE for Mac/NEXTstep (Darling is tho:
| https://www.darlinghq.org/)
|
| Why would you want to use GNUstep on Mac? Because it lets you
| write native software using Foundation/Cocoa/etc that you can
| actually port to other platforms.
| soraminazuki wrote:
| The analogy still holds because people wouldn't use GNUStep
| on macOS for the same reason people wouldn't use WINE on
| Windows. That GNUStep doesn't run macOS binaries makes no
| difference here.
| bogwog wrote:
| They _would_ use it though, that's my point. A developer
| that wants to create a portable Cocoa-based GUI, or a
| Foundation-based Objective-C CLI can use GNUstep to do
| so. If they just use Apple's frameworks directly, they'll
| have a hard time porting it anywhere.
| spijdar wrote:
| The one cross-platform app I know that uses GNUstep to
| run on Linux is Hopper, which just uses Apple's libraries
| on Mac. Not sure how hard the porting effort was, but I
| thought I'd throw that anecdote in there.
|
| As for wine, it's worth pointing out that wine consists
| of both the plumbing to get win32 apps running on Linux
| as well as a recreation of the win32 userland libraries.
| Darling is similar, and it uses GNUstep for some of its
| userland recreation.
|
| Ideally, GNUstep should be a drop in, source compatible
| framework to compile code written for the native ones on
| MacOS, similar to how Wine _can_ be a source compatible
| framework for Windows. There are actually Wine ports to
| CPU architectures like 64 bit PowerPC that never had
| native windows versions, and Wine lets you recompile and
| run win32 software on ppc64le.
|
| (Of course, the practical caveat is GNUstep isn't
| implementing OS X's API, but OpenSTEP, which OS X/MacOS
| still mostly (?) implements as a subset of its current
| API. So, if you wanted to be cross platform and use
| GNUstep, you'd either need to develop on Linux, link
| against GNUstep on MacOS, or be super familiar with MacOS
| to know what APIs are available on both)
| soraminazuki wrote:
| I think it's more common practice to use Apple's
| frameworks on macOS and GNUStep on Linux. At least,
| that's what unar [1] and the Hopper Disassembler [2][3]
| does. That's probably the reason why GNUStep is absent in
| Homebrew.
|
| [1]: https://github.com/NixOS/nixpkgs/blob/1cfd83e859002d
| 1f053bb3...
|
| [2]: https://github.com/NixOS/nixpkgs/blob/a0dbe47318bbab
| 7559ffbf...
|
| [3]: https://github.com/NixOS/nixpkgs/blob/a0dbe47318bbab
| 7559ffbf...
| accountofme wrote:
| I am _not_ a mac developer, but if GNUstep is trying to keep to
| being source compatible with cocoa as possible, do you need to?
| Shouldn 't the Apple provided dev libraries work too?
|
| I could be missing something, and most probably am, but I
| looked into rust bindings for this library and they had build
| options to use gnustep/libobjc with macos and linux.
|
| Hope that helps.
|
| edit: here is the crate I am talking about:
| https://crates.io/crates/objc-sys
| oefrha wrote:
| You're certainly not going to be able to -lgnustep-base
| -lgnustep-gui on macOS without installing libgnustep-base and
| libgnustep-gui. You should be able to link against libobjc
| without GNUstep.
|
| I'm not sure if Cocoa has diverged enough to be incompatible.
| swiley wrote:
| Las I checked some of Apple's open source compile and run
| on OpenStep.
| einpoklum wrote:
| I remember seeing GNUstep on Linux distributions 20 years ago,
| along with early KDE and other options. I appreciated the
| aesthetics of it at the time, but - can someone explain its
| benefits today, and why one would prefer using it?
|
| Actually, I'm not even clear what I would replace with GNUstep,
| exactly.
| touggourt wrote:
| GNUStep is not a desktop. Try NextSpace (see above) if you want
| a GNUStep based desktop. NextSpace is a clone of NextStep
| desktop.
|
| Like its ancestor, NextSpace is fast, light and very
| consistent. I like the vertical menus that I can move were I
| need them, the dock in the file manager, the file manager
| itself, ... It is an advanced desktop that hide the
| difficulties: you don't need to learn, it is logical. It is
| like macOS, without targeting beginners. I am a long time KDE
| user, I know how it works, it is my desktop of choice. But
| there is still some glitches, and it is a different user
| experience than NextSpace.
| rbanffy wrote:
| I imagine you can compile some programs designed to run under
| macOS to run on it, with a NeXTSTEP look and feel.
|
| Apart from that, it's mostly for historical interest.
| jenifer027 wrote:
| https://cricbull.com/cricket-news/who-was-the-first-captain-...
| phkahler wrote:
| Can it be used as a GUI for C++ programs?
|
| Does it support OpenGL ES?
| gcasa wrote:
| Yes, it can and yes it does.
|
| -- Gregory Casamento GNUstep Lead Maintainer
| pakl wrote:
| A few of us maintain scripts for building the latest GNUstep from
| source under Linux (desktop, PinePhone, and Raspberry Pi) here:
| https://github.com/plaurent/gnustep-build
| major505 wrote:
| So, is like windowmaker?I kind feel like when I was in college in
| the early 2000`s and used Windowmaker as my main window manager.
| lproven wrote:
| I tried to answer this above:
|
| https://news.ycombinator.com/item?id=29544763
| badsectoracula wrote:
| GNUstep is a framework (and some applications that use that
| framework), it is closer to Gtk+ and Qt than to KDE or GNOME.
| Most importantly it does not provide any window manager and
| instead rely on an existing one (you can use it with KWin/KDE,
| Mutter/Gnome, XFWM/XFCE or any other window manager).
|
| Window Maker is a window manager with a NeXTSTEP/OpenStep
| style, though it has nothing to do with GNUstep aside from
| looking very similar and thus being a good choice for when
| using GNUstep programs with the classic NeXTSTEP/OpenStep
| theme.
| bluedino wrote:
| 25 years ago I was excited to learn that the Quake editor (and
| Doom before that) was written on NeXT. I figured with my
| rudimentary Linux and C skills I could get it working, but of
| course it was a little harder than installing everything and
| running _make_
|
| From JohnC:
|
| _" This is a NEXTSTEP application, so hardly anyone is going to
| be able to use the code as is. This is not an OPENSTEP
| application. It doesn't even use the foundation kit, so porting
| to gnustep or openstep-solaris/mach/nt would not be trivial."
|
| "This application was really not a very good fit for NEXTSTEP.
| The display postscript model fundamentally doesn't fit very well
| with what we need here -- if you run in an 8 bit color mode, the
| line drawing runs at an ok speed, but the texture view goes half
| the speed it should as it dithers from 24 bit color down to 8
| bit. If you run in 24 bit color mode, you get less screen real
| estate and significantly slower line drawing as a 3 megabyte XY
| view is flushed. Sigh. If anyone does actually run this on
| NEXTSTEP be advised that you want a fast machine."
|
| "QuakeEd is written for NEXTSTEP 3.3, while GnuStep is an
| implementation of the OPENSTEP spec. I haven't had time to port
| it to openstep yet, but it looks like it will take a little
| effort. NeXT has tools in NS 4.0 to help, but it still isn't
| automatic."_
| lizknope wrote:
| I'm pretty sure that Carmack was running NeXTSTEP 3.3 on an HP
| PA-RISC machine.
|
| NeXTSTEP ran on m68, x86, SPARC, and PA-RISC. Then it was
| ported to PowerPC and renamed.
|
| https://wiki.c2.com/?NextStep
| bluedino wrote:
| Yup - from another .plan file:
|
| _We hadn't really used them for much of anything in the past
| year, so it was just easier to turn them off than to continue
| to administer them. Most of the intel systems had already
| been converted to NT or 95, and Onethumb gets all of our old
| black NeXT hardware, but we have four nice HP 712 /80
| workstations that can't be used for much of anything. If
| someone can put these systems to good use (a dallas area unix
| hacker), you can have them for free. As soon as they are
| spoken for, I will update my .plan, so check immediately
| before sending me email.
|
| You have to come by our office (in Mesquite) and do a fresh
| OS install here before you can take one. There may still be
| junk on the HD, and I can't spend the time to clean them
| myself. You can run either NEXTSTEP 3.3 or HP/UX. These are
| NOT intel machines, so you can't run dos or windows. I have
| NS CD's here, but I can't find the original HP/UX CDs. Bring
| your own if that's what you want.
|
| I'm a bit nostalgic about the NeXT systems - the story in the
| Id Anthology is absolutely true: I walked through a mile of
| snow to the bank to pay for our first workstation. For
| several years, I considered it the best development
| environment around. It still has advantages today, but you
| can't do any accelerated 3D work on it._
| unixhero wrote:
| An ultimate Hacker News comment here; John Carmack, Quake/Doom
| anecdotes, relevant ties to NeXT.
|
| Just saying, greatly enjoyed it.
| bitwize wrote:
| Still missing Rust, blockchain, and gut bacteria but it's not
| bad!
| isx726552 wrote:
| If he rewrites it to include those things then it'll be
| like the Mearle Haggard "perfect country and western song"
| thing.
|
| "I was drunk the day my mom got out of prison..."
| gcasa wrote:
| LOL
| grouphugs wrote:
| whenever i hear the word GNU i think: racist, pedophile, nazi
| pjmlp wrote:
| It was nice endevour to port NeXTSTEP development stack.
|
| Nowadays with it being several releases behind macOS tooling, and
| the whole issue of what from Objective-C v-latest is actually
| supported, it is more of a curiosity and nostalgic experience.
| linguae wrote:
| Since roughly 2004 (that's when I first learned about Mac OS X,
| NeXT, and GNUstep as a high school student), I've been
| periodically keeping track of the state of GNUstep since I
| believe there's value in having a FOSS alternative to macOS and
| its technology. GNUstep could have been the primary GUI
| development toolkit for the Linux desktop. Unfortunately,
| GNUstep never caught lightning in the way other FOSS desktop
| projects did, and I attribute this to bad timing.
|
| My understanding is that when the KDE project started in 1996,
| GNUstep wasn't ready yet (remember that the OpenStep
| specification that the original GNUstep was based on was
| released in 1994), and GTK+ was not separate from GIMP. My
| understanding is that options for FOSS GUI toolkits were sparse
| in 1996. What did not help GNUstep's case in 1996 was the fact
| that NeXT appeared to be dying; nobody in early 1996 would have
| guessed the outcome of NeXT. Thus, the creator of KDE decided
| on Qt, which had licensing terms that were not-quite FOSS. This
| caused consternation among some people in the FOSS community,
| which lead to the founding of the GNOME desktop. GNOME ended up
| adopting the now-separated-from-GIMP GTK+ toolkit around 1998.
| Meanwhile work continued on GNUstep, but by the time 2000
| rolled around much of the Linux desktop community rallied
| behind KDE and GNOME.
|
| Ever since Mac OS X was released, every now and then somebody
| with Mac OS X and Cocoa experience would look at GNUstep and
| say, "Wow! I saw what Apple could achieve with NeXT technology;
| what if we used GNUstep to build something similar for Linux?!"
| and then get started on a project, only for that person or team
| to lose momentum and eventually give up. One such promising
| project that is now dead is Etoile (http://etoileos.com), which
| was based on GNUstep and inspired by Mac OS X, yet had ideas of
| its own, such as versioned objects and support for a dialect of
| Smalltalk called Pragmatic Smalltalk that leveraged GNUstep's
| Objective-C APIs. Etoile would have been a fresh, new Linux
| desktop experience that would have brought us closer to the
| dream of a modern "Smalltalk operating system," but
| unfortunately that project lost momentum, like so many open
| source projects that don't have corporate backing or massive
| community support.
|
| There is a really interesting project called helloSystem
| (https://hellosystem.github.io/docs/) that is a fork of FreeBSD
| that aims to re-create the Mac OS X Tiger user experience and
| conventions. However, this project is built on the Qt toolkit
| instead of GNUstep.
|
| Will GNUstep ever gain momentum? I don't know; on one hand
| there is a vocal minority of long-time macOS users who are
| disappointed with Apple's software direction and would like to
| have an alternative to macOS that involves the least amount of
| friction as possible. However, different macOS users like macOS
| for different reasons. For those who like macOS due to its user
| interface guidelines and consistency, helloSystem may look
| promising to them, especially if it gains traction. For those
| who like macOS due to its object-oriented APIs, they may be
| interested in taking a look at the .NET ecosystem and the
| languages it supports.
|
| Personally, I'm dreaming of a Common Lisp desktop heavily
| influenced by Smalltalk, the Mac, and OpenDoc (Apple's
| commercially unsuccessful component-based software technology).
| I remember coming to the realization a few years ago that
| NEXTSTEP is essentially a pragmatic Smalltalk desktop
| environment, except instead of running a Smalltalk VM it ran
| Objective-C and Display PostScript on top of Unix. I'm
| thinking, why not go all the way with a programmable object-
| oriented environment and build a desktop environment from the
| Common Lisp Object System and its meta-programming facilities.
| It would have a standard set of UI guidelines for user-facing
| applications, but for power users, because everything is an
| object, it is possible to combine objects using scripts. If
| only I had more free time....this would be the ultimate
| realization of a desktop environment for power users based on
| taking Xerox PARC's technology to its limits.
| MayeulC wrote:
| Well, I guess you can still run Emacs on top of Guix :)
|
| I'm being tongue-in-cheek, but Emacs could be considered a
| graphics toolkit in its own right.
| laumars wrote:
| I was a developer in the 90s and 00s and frankly I thought
| peoples dislike of Qt was pretty superficial. The problems
| being that GTK sucked. I'd have forgiven NIH (not invented
| here) syndrome if GTK was at least as good as Qt but it
| wasn't. Frankly I even preferred oldskool Tk over GTK.
|
| In the time frames we are talking about, I also cared very
| little for NeXT. It did have its fans and deservedly too. But
| I was banking on BeOS becoming the POSIX workstation of
| choice. I even preferred that over Linux. But 90s Linux
| wasn't exactly a smooth experience like it is today.
|
| These days little has changed my mind about GTK vs Qt.
| pjmlp wrote:
| My graduation project was porting my supervisor thesis of a
| particle engine originally developed on a NeXT Cube in
| Objective-C/OpenGL into Windows/MFC/OpenGL, because it was
| clear it was going nowhere (OS X wasn't yet announced).
|
| So I actually lived through those events, and also think most
| modern environments fail short of what desktop computing
| could have been, and in a twisted way Windows is the closest
| of them all with COM and .NET, yet the whole WinDev vs DevDiv
| politics messed even that one, most likely beyond repair in
| the presence of current UI stack chaos.
| linguae wrote:
| Thanks for commenting. I've been reading your posts for
| quite some time and I enjoy your commentary about how
| Windows, from a developer's point of view, is the closest
| living thing we have to the types of Smalltalk and Lisp
| environments people at Xerox PARC and other places enjoyed
| in the 1980s and early 1990s. Windows has the
| infrastructure to make a truly great operating system; I've
| been reading a lot more about the .NET ecosystem this year,
| including multi-language interoperability through the
| Common Language Infrastructure and PowerShell scripting.
| What's unfortunate about Windows are the ads, the
| telemetry, the aggressive attempts to make people use Edge,
| and the strange UI choices that Microsoft made starting
| with Windows 8 (and, arguably, since Windows XP's Luna
| interface). I think of Windows as a gem that's
| unfortunately encrusted with layers of dirt.
|
| Another project I pay periodic attention to is ReactOS. If
| ReactOS matures to the point it can run on modern hardware
| and can run modern Windows software, then I'd make ReactOS
| my daily driver. A daily driver version of ReactOS combined
| with .NET would make quite a compelling platform for me.
| csdvrx wrote:
| I fully agree. When you know what to take from Windows,
| it's a great OS. The hackability of the UI with AHK is
| way above what Gnome or even KDE can offer.
|
| Yet in a funny way, when I explain to seasoned Linux
| hackers that my OS of choice is Windows, they look at me
| in a funny way :)
| heresie-dabord wrote:
| > helloSystem ... fork of FreeBSD ... re-create the Mac OS X
| Tiger user experience and conventions
|
| There are also a few GNU/Linux distros in this UX category,
| e.g. Zorin, Elementary, Budgie ... They are listed on
| https://distrowatch.com/. (I have no association with these
| distros.) Maybe helloSystem should be added to Distrowatch?
|
| In general, the spirit of Gnome was/is to improve UX (user
| experience). There have been _misadventures_ shall we say. At
| this point, I have come to want just a terminal, an editor,
| and a Web browser. ^_^
|
| [1] https://elementary.io/
|
| [2] https://zorin.com/os/
|
| [3] https://ubuntubudgie.org/
| nerdponx wrote:
| I think it's worth mentioning that a lot of MacOS design
| language has been absorbed into Gnome itself:
| grayish/metallic windows, the app launcher, the top menu
| bar, et alia.
| deaddodo wrote:
| It is even more of a shame, since Etoile was the project to
| bring frontend WM and library synchronicity to Linux / macOS
| (then OS X). But it died and hasn't been updated in ages, as
| the last great hurrah in that effort.
| inDigiNeous wrote:
| Yeah this was a really interesting project when it got started,
| like in the late 90s ? Now, realistically, even though I like
| the idea, who is going to use this ?
|
| Maybe like a compatibility setup for old NeXTStep applications
| ? Or porting some old macOS applications to Linux environments
| ?
|
| Working on top of the X11 implementation also doesn't really
| provoke trust to look into the project.
| selfhoster11 wrote:
| Linux desperately needs a good DE. We might as well dumpster
| dive for something reusable from the past.
|
| NeXTStep actually really reminds me of Windows 7 and other
| things. I wouldn't mind trialling it for a week as long as I
| could get my usual tasks done.
| anthk wrote:
| Once you switch to Fluxbox/Rox/Urxvt and custom keys, you
| won't need anything else. BT? Blueman. Network?
| NetworkManager/Connman plus the applet. Done.
| selfhoster11 wrote:
| The Unix philosophy doesn't work as well when it's
| mandatory to enable building a GUI. I specified that we
| need a good DE because we don't have a good story for
| integrating all of those things you mentioned within a UI
| that I consider usable (and GNOME isn't it, and KDE is
| not quite it either).
| eadmund wrote:
| > Now, realistically, even though I like the idea, who is
| going to use this ?
|
| Someone who thinks that OpenStep is a good way to build end-
| user applications, I imagine. I've never used it myself, but
| I know that it had an excellent reputation once upon a time.
| I wouldn't be surprised if it's better than Qt or gtk+.
|
| > Working on top of the X11 implementation also doesn't
| really provoke trust to look into the project.
|
| X11 is the standard display technology for Unix and Unix-like
| systems. _Not_ working atop X11 would provoke distrust. I
| imagine that you are actually advocating for Wayland. Wayland
| _may_ actually be the future, although I am still unconvinced
| that its design is sound (I worry that it throws out the baby
| with the bathwater).
|
| edit: I did not realise that there _is_ a Wayland backend for
| GNUStep.
| gcasa wrote:
| > Someone who thinks that OpenStep is a good way to build
| end-user applications, > I imagine. I've never used it
| myself, but I know that it had an excellent > reputation
| once upon a time. I wouldn't be surprised if it's better
| than Qt > or gtk+.
|
| GNUstep is Cocoa now and, apparently, a lot of people
| thought building apps this way was a good way to build end-
| user apps... macOS and iOS. ;) -- Gregory Casamento GNUstep
| Lead Maintainer
| inDigiNeous wrote:
| I'm generally speaking about the state of X11 vs macOS or
| Windows. Like configuring multiple monitors, getting your
| mouse working just right or other tasks that sometimes can
| just be freaking difficult with X11. But not wanting to go
| into that flamewar now.
|
| I would be surprised if it's better than Qt, in fact I know
| it's not. GTK+ also has had a lot of work during the years,
| but they have dropped the balls many times over major
| revisions, so in that sense it might be a better framework
| than GTK.
|
| But then again, it all comes down to who uses these. Qt is
| widely used beyond Linux in application development, and
| modern QT is actually a very nice development environment.
|
| Wayland is also in a state of not-complete. What I'm trying
| to say here is that the display technologies behind most
| Linux environments are not in a good state. They work, yes,
| but some things just don't work or are impossible to setup
| compared to eg. macOS or Windows.
|
| This is mostly due to open source fragmentation and legacy
| code in my view, and the fact that everybody and their
| brother would rather fork out their own desktop
| environments than decide to make couple of good ones, but
| hey that's Open Source. Also missing commercial support of
| course.
| donatj wrote:
| > Working on top of the X11 implementation also doesn't
| really provoke trust to look into the project.
|
| Vs Wayland? I'd have way more doubts about anything that ran
| exclusively on Wayland than on X11.
|
| Wayland isn't ready, I have serious doubts it's ever going to
| be ready.
|
| X11 is old, but so is vim, emacs, grep, everything I want to
| actually rely on.
| inDigiNeous wrote:
| Yeah well Wayland doesn't provoke trust either..
| wildfire wrote:
| > Wayland isn't ready, I have serious doubts it's ever
| going to be ready.
|
| I don't know enough to have opinion about Wayland - could
| you share more details about why you do not think it is
| ready?
| pjmlp wrote:
| Yeah, I explicitly mentioned Objective-C v-latest, because
| not only the users have to figure out the whole runtime
| support in GCC vs clang in regards to Objective-C 2.0 and
| GNUStep, to further improve interoperability with Swift, many
| aren't aware that Objective-C still has a life and gets
| updates even if in tiny portions.
|
| Finally the whole way how makefiles work (classical NeXTSTEP
| style) isn't any longer like that.
| jabl wrote:
| > Working on top of the X11 implementation also doesn't
| really provoke trust to look into the project.
|
| Well, back when this project started X was really the only
| game in town. If they had started out rewriting the low level
| display server and graphics drivers they would never have
| gotten anywhere (to the extent the current state of the
| project can be considered "anywhere").
| grahamlee wrote:
| There is a wayland backend for GNUstep.
| grahamlee wrote:
| I co-host a GNUstep developer stream at
| https://twitch.tv/objcretain (replays at https://replay.objc-
| retain.com). The motivation my co-host and I have for using
| GNUstep in 2021 and beyond is to provide a familiar
| environment for macOS developers and users who are not happy
| with Apple's direction and would benefit from a free software
| alternative. To that end we mostly work on the basic desktop
| tools like calendar, mail, and addresses, and fix
| framework/dev tools bugs and missing parts as we find them.
| inDigiNeous wrote:
| Sounds like a cool hobby. But solving basic desktop tools,
| sounds like bikeshedding to me :) Not to disrespect the
| project, I find Objective-C and the Cocoa model nice, but
| realistically looking at it almost nobody uses GNUStep, so
| why write apps for it ?
| gcasa wrote:
| That is precisely why... it's new ground. It's fun. It's
| interesting. Why write applications (or, in your words
| "bikeshedding" -- an interesting term, I had to look it
| up. :))... because it's a chance to create something
| totally new. The mission is two fold:
|
| 1) Bring the elegance of easy development to every other
| operating system... and 2) Give Apple developers
| someplace else to deploy their applications.
|
| GNUstep is meant to be a drop in replacement for Cocoa.
| By Cocoa I mean Foundation and AppKit, not all of the
| Core this and Core that libraries. We have those, but
| they are less mature than Foundation and AppKit. GNUstep
| is also themable, as I have pointed out in other
| responses.
|
| GC
| apple4ever wrote:
| Which of course it doesn't have to be, but the current
| developers are very hostile to changing anything about the UI,
| which of course no one today really wants. Providing the old UI
| as theme for those who want it is fine, but not updating it to
| something modern and useful is not.
|
| I really wanted to contribute and help out with GNUstep, but
| that put me off from attempting anything.
| gcasa wrote:
| Do I know you? We really are pretty nice. GNUstep can be
| themed very easily. You are more than welcome to help,
| ESPECIALLY to make more themes.
|
| See the link below... This is GNUstep using the rik theme...
| Just one of the many ways the project can look:
|
| https://user-
| images.githubusercontent.com/12986802/33520300-...
|
| Gregory Casamento GNUstep Maintainer
| Lammy wrote:
| I love that FinderSTEP mash-up icon :)
| gcasa wrote:
| NeXTSTEP? That's how it started, but not where it currently is.
| GNUstep is currently pushing for 10.15 compatibility at least.
| GNUstep supports the current release of clang which is fully
| ObjC2 compliant. GCC is also still supported. There is also a
| tool called buildtool and a library which can read and build
| xcodeproj files fairly seamlessly.
| pjmlp wrote:
| Objective-C moved on, nowadays is it more 2.x than 2.0, and
| those small changes are not there as far as I am aware.
| aklemm wrote:
| Is it strictly necessary that it be ugly?
| lproven wrote:
| You know that NeXTstep is the only GUI that was pretty enough
| to feature in a music video?
|
| It's in Madonna's _Rain_ (1993 I think).
| https://www.youtube.com/watch?v=15kWlTrpt5k
|
| The NeXT cube also featured in _Flatliners_.
| http://www.starringthecomputer.com/feature.html?f=398
| pelagicAustral wrote:
| I think it looks amazing. I wish I could work on an UI like
| that all the time... Not long ago I was working at an office
| (non-IT stuff) and they had these very old computers, still
| running Windows 7, and I remember being able to enable the Win
| 98 theme, I was so happy about that... at home I was running
| Windows 10, where you can no longer give your desktop that
| ancient feel...
|
| I'd say Windows 95/98 was peak UI design. This UI feels even
| better...
| aklemm wrote:
| Ok, if there are enough people sharing that opinion, then I
| certainly get it.
| codehalo wrote:
| Honestly, it is the singular reason why it failed. They had
| no intention of evolving with the times.
| apple4ever wrote:
| Bingo. Had they made a better more modern UI, I think it
| would gain some traction. But they are entirely resistant
| to updating anything with the UI.
| occoder wrote:
| Doesn't GNUstep have a theming engine now? Do you think
| the current maintainers would accept a new theme if we
| were to make a more modern one?
| lproven wrote:
| It does have a theme engine. There are multiple
| alternative themes out there.
|
| For me, and IMHO, every single one of them that I've seen
| is uglier than the original. For me, NeXTstep was the
| pinnacle of desktop UI design and everything else since
| has been less attractive.
|
| Mac OS X was quite pleasing, if inconsistent, for a while
| around 10.4-10.6 or so, but now it's a mess. (I am typing
| on 10.14 right now.)
|
| Win11 is a big less ugly than Win10, but the desktop is
| so crippled I find it hard to use, and there are ribbons
| everywhere. I hate the ribbon.
|
| Win10 is kinda ugly but at least it's mostly black.
|
| Win7 was and is a bit garish but it was the sweet spot.
|
| XP was fugly.
|
| Win2K was the high point for Windows, and everything
| before and after were worse.
| pulse7 wrote:
| Who remembers the Smalltalk browser?
| shp0ngle wrote:
| Last time I looked, GNUStep was really, really, really buggy
| reimplementation of 2000-era macOS... sorry, Mac OS X back
| then... toolkit.
|
| I say really 3 times, because I really tried to port a MacOS-only
| terminal app (don't ask) to Linux, and I failed miserably on very
| basic functions.
|
| I guess I should have tried more, make minimal examples and
| report that, but I never bothered. It's what I would do now,
| anyway.
| zwaps wrote:
| "GNUstep is a free, object-oriented, cross-platform development
| environment that strives for [...] elegance"
|
| Well personally, I gotta say, I dig the 1995 optics of this.
| gcasa wrote:
| https://user-images.githubusercontent.com/12986802/33520300-...
|
| Yeah, I know, right? ;) </sarcasm> It is fully capable of
| looking like macosx using any number of themes.
|
| Gregory Casamento -- GNUstep Lead
| xyproto wrote:
| What are the advantages over FPC/Lazarus?
| gattilorenz wrote:
| - First and foremost, it's not Pascal, but the more elegant
| Objective-C.
|
| - You can in theory compile sources for NeXT/OpenSTEP or early
| OS X applications with minimal changes[1], while FPC would
| require you to rewrite them completely.
|
| - Different GUI components, inspired/based on the *STEP design.
|
| Realistically, I guess you're better off using Lazarus for
| anything new, nowadays.
|
| [1] The original DOOM editor was developed for NeXT machines,
| and the sources surfaced a few years ago. Here it is running
| under Ubuntu with Window Maker and GNUStep:
| https://www.doomworld.com/forum/topic/111229-redoomed-maclin...
| badsectoracula wrote:
| > First and foremost, it's not Pascal, but the more elegant
| Objective-C.
|
| That depends on the beholder and their eye :-P.
| gattilorenz wrote:
| Absolutely :)
| tored wrote:
| I like the procedural version of Pascal, with records,
| procedures and units, however the more modern Pascal that
| you can find in FreePascal where you have to either inherit
| or implement a class for any advanced container is
| cumbersome.
| badsectoracula wrote:
| The language had support for dynamic arrays for ages and
| the intrinsic functions like insert, etc have been
| extended to work with them in latest version (i'm not
| 100% sure if this is available in the latest relase, but
| it is available in the trunk). So for simple stuff that
| should work.
|
| But yeah the containers that FPC provides are indeed
| cumbersome and i blame Delphi for that and FPC's
| insistence on copying all those bad features (ok, i
| understand the need to remain compatible so people can
| switch to FPC, but they can always provide better tools
| too - perhaps they're burned from when they implemented
| generics first and then Delphi implemented theirs in an
| incompatible way and now they have to support both).
|
| On the other hand, you can make your own and i have mine
| which can use any old data structure, be it primitives,
| records or classes.
| Koshkin wrote:
| Well, no doubt the curly braces look... curlier!
| [deleted]
| mucholove wrote:
| So I use GNUstep and I really like it.
|
| It is not an Apple emulator--it is an OPENstep emulator and so it
| implements the amazing Cocoa API and many mac/iOS frameworks can
| be used server side with minimal porting.
|
| This makes it easy for what I intend to keep as a one person
| project forever or as long as Apple continues to support
| Objective-C.
|
| You want to know an unpopular opinion?? I love Objective-C and I
| think it is better--way better than Swift. And--if you have
| discipline, the preprocessor is excellent.
|
| So while many might say GNUstep is buggy, it is working for
| several of us--and happily so.
|
| I do agree that the homepage is terrible and that what should be
| done is put some installer scripts so you can start using it
| immediately. An Ubuntu installation following the corresponding
| script here is foolproof: https://github.com/plaurent/gnustep-
| build
|
| Check it out!!
| apple4ever wrote:
| > I love Objective-C and I think it is better--way better than
| Swift.
|
| You are not the only one. This is exactly how I feel.
|
| But GNUstep is ... not great. I want it to be! But it needs a
| lot of work on the interface side.
| occoder wrote:
| Judging by your comments, you seemed to have talked to the
| GNUstep maintainers, but they haven't been receptive to your
| ideas.
|
| May I propose a fork? How about SiDESTEP (r) for the project
| name?
| gcasa wrote:
| No one ever spoke to me and I am the lead. Also SIDESTEP
| has been taken by another project. :)
| gcasa wrote:
| Email me... anyone is free to join at any time. The whole
| project would appreciate the help.
| gcasa wrote:
| Well, for one thing it's not an emulator... AT ALL. And for
| another thing the idea behind GNUstep since about 2000 has been
| to implement Cocoa. I do appreciate your enthusiasm. :)
|
| Greg C. GNUstep Maintainer
| anonymouse008 wrote:
| > You want to know an unpopular opinion?? I love Objective-C
| and I think it is better--way better than Swift. And--if you
| have discipline, the preprocessor is excellent.
|
| Very curious to the reasoning here. If you can get to the
| pointer level of Swift, you basically have obj-c without all
| the unnecessary syntax?
|
| In my view, excessive syntax is a crutch to make the language
| parser's job easier, not making the thought to code job easier.
| Obj-C seems to suffer from the excessive syntax?
| pianoben wrote:
| > In my view, excessive syntax is a crutch to make the
| language parser's job easier, not making the thought to code
| job easier. Obj-C seems to suffer from the excessive syntax?
|
| Another perspective is that the syntax of Obj-C exposes and
| supports the core model of the language, which is objects
| sending messages to each other. That it happens to be fast to
| parse seems secondary, and certainly further developments
| since version 2.0 have made parsing slower, not faster.
|
| In my experience people complain about Obj-C syntax when what
| they actually dislike are verbose Cocoa/Foundation/etc APIs.
| Try their C Core* equivalents and you'll find you probably
| dislike those, too.
| setpatchaddress wrote:
| > In my experience people complain about Obj-C syntax when
| what they actually dislike are verbose Cocoa/Foundation/etc
| APIs
|
| If so, that's a real shame. Foundation may be the single
| best-designed standard library for a (non-functional)
| language ever.
| pianoben wrote:
| I agree, Foundation is a gem! The method naming is one of
| the assets - the names are clear, regular, and usually
| fairly obvious. The downside to that regularity and
| clarity is that the names are _long_.
|
| One CoreFoundation example at random:
| CFURLRef
| CFURLCreateCopyDeletingLastPathComponent(CFAllocatorRef
| allocator, CFURLRef ref);
|
| I think nearly everyone who reads that prototype will
| immediately understand what it does, but there's no
| denying it's a mouthful.
|
| Tack on some unfamilar square-brackets and intersperse
| argument names, and it's understandable that people will
| conflate the syntax with the APIs.
| gcasa wrote:
| CoreFoundation is not written in ObjC, it's C only
| (although toll-free bridged).
| OnlyMortal wrote:
| To be fair, the syntax has changed since the days of NeXT.
| Accessing object variables been more C like (dot notation).
|
| Personally, I never had any difficulties understanding the
| old syntax.
| pianoben wrote:
| If anything, the old syntax was _pure_ and consistent with
| what actually happens - message sending. Dot notation
| muddies the waters, IMO, but certainly is convenient. Ditto
| the collection literals.
| bitwize wrote:
| I still say they did properties wrong. If you have a
| property prop, it should synthesize methods prop and
| prop: and expose them to the user. Then, to get you say
| [obj prop] and to set you say [obj prop: newVal]. This is
| a convention widely used in Smalltalk, and is nearly as
| convenient to use as dot notation. Dot notation in
| Objective-C makes the dot operator mean two different
| things; and in one case it takes a bare struct and in the
| other case it takes a _pointer_. Utterly weird. But it 's
| a belt onion: done because it was the style at the time.
| b3morales wrote:
| This is in fact how @property works; the declaration is
| sugar for a pair of accessor methods. The dot syntax is
| sugar for calling those methods.
| #include <Foundation/Foundation.h>
| @interface Foo : NSObject @property (copy)
| NSString *bar; @end @implementation
| Foo @end int main(int argc, char
| *argv[]) { Foo *foo = [Foo new];
| [foo setBar:@"Hello, world!"]; NSLog(@"%@",
| [foo bar]); return 0; }
| mucholove wrote:
| The dot syntax makes it difficult to parse whether you
| are dealing with a C struct or an Objective-C object.
|
| Objective-C was grafted onto C with very clear
| demarcation lines.
|
| We don't mind being able to declare a property with
| `@property`. We do mind that they introduced dot syntax
| xkriva11 wrote:
| t.rotate (a, v); // Original
|
| t rotate (a, v); // Who needs dot?
|
| t rotate a, v; // Who needs brackets?
|
| t rotate by: a around: v; // Who needs ambiguity?
|
| t rotateBy: a around: v // This is Smalltalk
| anonymouse008 wrote:
| I'm rolling -- this is perfect.
|
| Civilization has used dot notation in basically all
| thought, as evidenced by pretty much any nation's laws /
| code
| b3morales wrote:
| Same here, I was never a proponent of the dot syntax. As
| we know, compiler development at Apple got taken over at
| some point by C++ people, and we can all see the results:
| https://blog.metaobject.com/2014/06/remove-features-for-
| grea...
| apple4ever wrote:
| I love the expressiveness of Obj-C, I love the brackets, and
| I love how easy it is to write.
|
| I hate Swifts boiler plate words (var, let [why not
| const???], func), I hate the obtuseness of it (eg question
| marks everywhere), and I hate how hard it is to read because
| it makes it very easy to be so "clever".
| KronisLV wrote:
| Typo in the banner: http://gnustep.org/information/banner.pdf
|
| > GNUstep uses the same _langauge_ and API as Cocoa on Mac OS X.
|
| That small nitpick aside, that seems like and interesting
| project! I don't think i have seen many (if any) other attempts
| at creating a set of portable tools like that, entire workspaces
| that can work over a variety of OSes, unless i'm reading this
| wrong. Sure, we have portable editors and so on, but this seems
| like a step well above that.
| jksmith wrote:
| Freepascal/Lazarus
| KronisLV wrote:
| Lazarus and the modern versions of Pascal are lovely for
| desktop development!
|
| For anyone curious, here's a nice writeup: https://castle-
| engine.io/modern_pascal_introduction.html
|
| And here's Lazarus, the actual IDE: https://www.lazarus-
| ide.org/
|
| Though they're more along the lines of cross platform
| language/framework (their approach to GUI frameworks across
| platforms is great https://en.wikipedia.org/wiki/Lazarus_Comp
| onent_Library#/med...), as opposed to a set of utilities to
| develop inside of.
|
| Edit: for example, see
| http://www.gnustep.org/softwareindex/index.php?count=100
|
| Either way, it's a shame that Lazarus and Pascal never really
| caught on, since they feel like an older and more mature Go
| or something, except with actual GUI tools out of the box and
| a variety of useful drivers (think along the lines of Swing
| in Java, but less rude to the underlying platforms), which
| mostly makes them dead nowadays and not the best option for
| new projects.
|
| Also, their web dev scene is lacking, there's nothing like
| Spring/Django/Express.net/ASP.NET in Lazarus. At least not
| "one true framework" to do webdev in.
| mhoad wrote:
| I'd say that Flutter[1] probably meets that same definition
| today of cross platform development and tooling in a much
| slicker way.
|
| [1] https://flutter.dev/
| KronisLV wrote:
| I'm afraid that i can't agree there, because of how it was
| implemented.
|
| Flutter is plain hostile from certain standpoints: in the
| browser, it does use canvas for rendering and therefore
| denies any ability to learn about how a particular site was
| developed (how many of today's devs have benefited from
| "Inspect Element"?). Not only that, but it also breaks much
| of browser functionality, such as right clicking, selecting
| text, using plugins that manipulate the DOM, user styles, and
| historically even screen readers (though they're getting
| better at that last bit recently).
|
| Just have a look here: https://gallery.flutter.dev
|
| Open the Reply app, open a message, try copying the contents.
| Try seeing how the block with the sender information has been
| formatted. Pretend that Taxes folder is spam instead (e.g. an
| ad, or a flashing element that could cause you seizures), try
| blocking it with uBlock Origin or a similar plugin.
|
| I agree that technically it fits the criteria that you're
| describing, but it fails on certain platforms (the web) in my
| eyes due to all of the shortcomings and how badly it
| implements this platform support. Use it for native apps?
| Sure, i guess...
| pjmlp wrote:
| Fire dances of celebration where thrown around the lands
| with the demise of Flash, ActiveX, Silverlight, Java
| Applets and all others that followed the same cursed path,
| yet the powers of be down at the druid dungeons came up
| with WebGL/WebAssembly, thus the natural order was
| eventually restored and everything old was new again.
| KronisLV wrote:
| > WebGL/WebAssembly
|
| You know, it's kind of unfortunate, because the actual
| tech is nice and has lots of potential. I mean, WebGL is
| great for online games (even if many will suggest that
| it's not quite as easy to work with as Flash was) and
| other interactive content, like visualizations etc.
|
| Whereas WASM has the potential to make high performance
| code in the browser a reality, especially for the
| aforementioned physics simulations, or curious usecases
| of tech such as having access to Python or .NET in the
| browser environment, which remain sandboxed at the same
| time. The ability to do this feels really interesting, as
| do Web Workers being a thing (even though maybe JS should
| have had proper threading support and support for joining
| threads from day one instead).
|
| It's just that the way these technologies are used can
| end up a bit misdirected or sometimes outright malicious,
| something that we'd possibly get in other forms without
| this (just look at how evil ad industry sometimes is and
| how unethical many of the ads have historically been).
| pjmlp wrote:
| Too late, the train has departed already,
| https://workspaceupdates.googleblog.com/2021/05/Google-
| Docs-...
| rektide wrote:
| Watching Google leading the transition, of the web from a
| hypertextual, common, extension-able user-agency-embue-
| ing medium, into an unmalleable, hard, pushing-pixels-in-
| our-faces application is one of the most evil malignant
| acts I can imagine being perpetrated against good
| upstanding tech society has. This is such a huge step
| into the dark, out of the sun, for the world wide web.
| pjmlp wrote:
| It is called ChromeOS nowadays, thanks to everyone that
| helped Chrome achieve its hegemony (Electron also
| counts).
| mhoad wrote:
| I think to be fair to Flutter their entire concept of web
| support is literally months old at this point outside of
| beta, it obviously has a long road ahead of it to become
| more web native.
|
| At the same time, I think that we need to start thinking
| about what web apps can and should look like strictly
| outside the context of just the DOM. It's not clear that it
| is really going to be the right tool for the job moving
| forward for more complicated applications. For example
| Google Docs is moving (has moved?) entirely to canvas based
| rendering for performance and flexibility reasons.
|
| Technologies like WASM, canvas, WebGPU and HTTP3 means that
| the list of available options is about to change rather
| dramatically in the next few years I think.
|
| These new approaches are going to require new solutions not
| just for the use cases you outlined but also things like
| just general accessibility. I've had a chance to look at
| what the Flutter team are doing on that front and I think
| it would be safe to say that they aren't in anyway unaware
| of where things fall short currently but have public plans
| already in various stages of implementation to address
| them.
|
| Not asking anyone to drink to kool-aid just yet but I feel
| good about their plans to play catch up over the next
| couple of years. I could easily see it becoming a very
| sensible default option for app development before too
| long.
| skinkestek wrote:
| I have no interest of being fair to Flutter.
|
| Flutter is just another proof that for Google _as an
| organization_ [1] being nice, open and friendly was just
| a trick that lasted as long as it was useful for Google.
|
| [1]: I think the majority of people there are nice, there
| is just some dynamic that drives them to become dumb[2],
| manipulative[3] and destructive[4] when they operate
| together ;-)
|
| [2]: still haven't managed to fix search a decade after
| they broke it.
|
| [3]: censorship etc
|
| [4]: destroying their own products, companies they buy,
| and even entire markets (like web browsers)
|
| Edit: I don't hate Google, neither as an organization and
| definitely not as individuals but I really really really
| wish Googlers could get their act together and start
| being Google again because they behave as a small child
| with super powers or something :-/
| ternaryoperator wrote:
| > I really really really wish Googlers could get their
| act together and start being Google again
|
| Google has always abandoned projects suddenly--even in
| the era you're describing.
| skinkestek wrote:
| Yep.
|
| But search used to be rock solid and Google used to be a
| driving force behind the open web.
| KronisLV wrote:
| > At the same time, I think that we need to start
| thinking about what web apps can and should look like
| strictly outside the context of just the DOM.
|
| In my eyes, the DOM is an inseparable part of how web
| apps should work - the web being composed primarily of
| documents, even if more dynamic ones nowadays thanks to
| SPAs and intermediate technologies like virtual DOM
| implementations.
|
| Throwing away the entire model while chasing performance
| gains due to overcomplicating what websites should be in
| the first place is not good, in my eyes.
|
| That view may change some day, however, but for now i'm
| happy with creating and consuming primarily lightweight
| websites (HN is a good example of this, as is the old
| Reddit layout) and using specialized software for the
| things that the web doesn't always do good in my eyes,
| such as Thunderbird for e-mail and Libre Office for
| documents.
|
| Should people have the choice to use different
| architectures and approaches for the cases where it's
| necessary (e.g. educational physics simulations with WASM
| in the browser)? Sure. But should we push those
| approaches as the new normal and usurp decades of
| progress? I don't think so.
| mhoad wrote:
| I guess that's the part where we differ. I can't help but
| see an inevitable merging between the idea of a native
| app and a web app until they are possible to be one and
| the same.
|
| So for me the browser is more of a rendering pipeline
| that can deliver DOM for pages and apps or something like
| canvas for "native apps".
|
| As I was saying above I totally share that fear of
| sending these opaque blobs of binary data down the wire
| that paint arbitrary pixels that I have no control over.
| That isn't how "the web" works.
|
| So you are going to need to find a way to think about
| accessibility APIs for example that aren't tightly
| coupled to the DOM. Those things are already happening.
| Source maps are another important tool to maintain that
| slick view source experience.
|
| But I think there is a reasonable case to be made that
| the browser should 100% be capable of running native apps
| so long as they are able to play nice with the web as a
| platform.
|
| Note: I have to just explicitly make that distinction
| between pages and apps here. I don't ever want to see
| this try and become the new normal for anything that
| would reasonably be considered "document based". I think
| they can comfortably coexist each with their own
| specialities.
| KronisLV wrote:
| While we are in disagreement, this is a really nice
| point:
|
| > But I think there is a reasonable case to be made that
| the browser should 100% be capable of running native apps
| so long as they are able to play nice with the web as a
| platform.
|
| In my eyes, the problem is that DOM seems to be what
| makes up the current "platform" of the web, since that's
| what most of the pages out there are based on, what most
| of the development effort is centered around and what
| most of the browsers work best with.
|
| That's not to say that it couldn't feasibly change in the
| future, or that trying to do so isn't worth the effort,
| but i'd definitely posit that it's extremely tricky to
| get that right. Flutter might not be the right tool for
| that job, but maybe in a decade or two someone will have
| borrowed some of its good ideas and built something
| better.
|
| Though to me it feels like any such development would
| need new standards to describe what could actually be in
| such a platform, how all of it would work and would also
| need to be included in all of the browsers - a true
| Herculean effort. Approaching the problem from the other
| end, by working with canvas/WASM/whatever is probably
| easier, since it doesn't require changes to the browser
| code, but in my eyes that's a bit like trying to create a
| 3D renderer in Excel or something, maybe going one layer
| of abstraction too deep (platform in platform).
|
| I might be wrong though and it all could work out yet
| somehow. Hopefully when it happens, it won't be a case of
| one large org pushing a new standard and being like:
| "This is how we'll approach the web now, get with the
| times and the APIs that we've developed."
| sadfev wrote:
| It's dead and has been for a decade
| gcasa wrote:
| Not dead at all. I have been working with a number of companies
| to help them use it. Surprising definition of dead. ;) Join us,
| be part of the solution!
|
| GC -- GNUstep Lead
| selfhoster11 wrote:
| Software dies with its last user or curious historian. Open
| step is quite far from that.
| mpweiher wrote:
| That turns out not to be the case. It is in both active
| development and use.
| lproven wrote:
| There is slow but active development. Occasionally new releases
| appear. There is a new, active distro under development.
|
| I don't think this fits the definition of "dead". Not very
| lively, but not dead.
| gcasa wrote:
| Then join us. Help us get it the last mile. Don't just say
| "it looks like it's dead".. be part of the solution. :) You
| are more than welcome to join!
|
| -- Gregory Casamento GNUstep Lead Maintainer
| lproven wrote:
| Hi Greg. :-)
|
| I think you meant to reply to @safdev, to whom I was also
| replying.
| gcasa wrote:
| Oh, yeah, i did. Thanks. :)
| lproven wrote:
| :-D
| mukundesh wrote:
| Wondering how Steve Jobs would have reacted to GNUstep...
| necovek wrote:
| He wouldn't react at all: GNUstep was already an established
| project before his death, so he already had an opportunity to
| react and, unsurprisingly, he didn't care much.
| shp0ngle wrote:
| Apple didn't really like OpenDarwin or whatever was the name,
| right. But more on trademark concerns, if I'm not wrong.
| lizknope wrote:
| GNUstep started in 1995 back when Jobs was still at NeXT before
| Apple bought the company. He didn't try to stop it back then.
| manbart wrote:
| How does it compare to Window Maker?
| badsectoracula wrote:
| GNUstep is really a framework and closer to something like Gtk+
| or Qt. Window Maker is a window manager, it has its own GUI
| toolkit (WINGs) but it is really only meant for use with Window
| Maker and perhaps some dockapps (though some dockapps use other
| toolkits anyway).
| lproven wrote:
| It doesn't. They're different types of tools. GNUstep commonly
| runs under and uses Window Maker.
|
| Window Maker is a window manager.
|
| GNUstep is a large set of libraries and foundation classes, and
| almost as a byproduct, they happen to implemented most of a
| desktop environment: a file manager and actual desktop, a dock,
| plain and rich text editors, a pretty good email client, a chat
| client, a terminal emulator, image viewer, etc. etc.
|
| But like any other xNix desktop, it needs a window manager. KDE
| uses kwm, GNOME uses mutter, Xfce uses xfwm, LXDE uses OpenBox,
| etc. GNUstep can use whatever you want, but Window Maker is the
| recommended choice because it matches the look-and-feel nicely.
| Lammy wrote:
| "The GNUstep project does not provide a window manager; you can
| use any window manager you want, although we recommend that you
| use WindowMaker for a better experience."
| http://gnustep.org/information/aboutGNUstep.html :)
| HerrMonnezza wrote:
| Window Maker is an X11 window manager with a NeXTStep look.
|
| GNUStep is an attempt at creating a Free/Libre NeXTStep-like
| environment, including all the apps.
| shrubble wrote:
| The most recent development (updated a month ago) is 'NEXTSPACE'
| which is designed to sit on top of a minimal CentOS 7 install.
|
| See: github.com/trunkmaster/nextspace
|
| I have used it in a VM under Windows and it was pretty nice.
|
| It felt very NeXT-ish.
|
| Of course you could install and run regular X windows programs as
| well.
| lloydatkinson wrote:
| It looks like it's straight out of 1995. Ultra dark gray and ugly
| aesthetics, despite what some people say, will not attract
| developers or users. This seems to be a meme, Linux desktops and
| apps with zero thought given to UX and UI. In some cases it
| almost seems like the approach of "how can we make this as
| cluttered, messy, and ugly as possible" to look at.
| selfhoster11 wrote:
| 1995 GUIs have far more usability left in them them modern UIs.
| Just the fact that MS thought it's acceptable to dumb down the
| right click menu (!), aka the most prominent symbol of a power
| user, is telling.
|
| We need to step back to 1990s/early 2000s, steal a few modern
| UI innovations that make sense while retreating, and take a
| long and hard look at the kind of GUIs we want to see built
| around ourselves.
| lloydatkinson wrote:
| A GUI can follow 1995 principles _without_ being an
| oppressive grey and ugly icons and either too much or too
| little spacing.
| selfhoster11 wrote:
| Colour was on offer since at least Widows 98. In fact,
| desktop themes were a thing, with custom wallpaper,
| colours, icons - precisely so the computer looks less
| dreary. If GNUStep was impossible to theme (or if theming
| was hard to implement there), I'd be surprised.
|
| Information density the one thing 1995 interfaces got right
| for power users. Modern applications fit 10 items per
| screen, and most don't bother to make this adjustable. My
| desktop computer or laptop could outcompute a Cray twice
| over, and yet I'm made to feel like I'm stripped of all
| that power.
| anthk wrote:
| I think modern folks see w9x themes in the same way as we
| do with the Amiga UI ones.
| lloydatkinson wrote:
| No, I grew up with Windows 98. Compare the quality and
| thought given to Windows 98 dialogs and windows compared
| to this GNU software in 2021.
|
| https://www.ross-tech.com/vag-com/usb/usb-config-98.htm
|
| http://gnustep.org/
| anthk wrote:
| I grew up with Windows 98 (and before, DOS), so I knew
| pretty well both w9x and GNUStep under Debian Woody. Both
| look equally well.
| occoder wrote:
| > Ultra dark gray and ugly aesthetics
|
| > A GUI can follow 1995 principles without being an
| oppressive grey and ugly icons
|
| > Compare the quality and thought given to Windows 98
| dialogs and windows compared to this GNU software in
| 2021.
|
| The NeXTSEP/GNUstep look is a little older than Windows
| 98, and I agree is a little less clean looking than
| Windows 98, but it's in no way ugly or oppressive. In
| fact it was a refreshing and highly acclaimed design at
| the time, and IMHO it still holds up pretty well three
| decades later.
| [deleted]
| udbhavs wrote:
| Yes, I'm no fan of the modern Metro UI either (Settings is the
| worse offender) but I personally believe Explorer in Win10 is
| peak windows design. Minimalist but with vibrant colorful
| icons, neatly organized but still information dense and no
| abuse of whitespace. It's a shame the entire Windows UI can't
| be based around it.
| naves wrote:
| For a while, GNUSTEP Live CD was the best option to try and test
| GNUstep. Latest version is even available for Raspberry Pi:
| http://www.aiei.ch/gnustep/
| mongol wrote:
| I remember GNUstep since the 90s. It existed even before Gnome.
| It had a (for the time) pretty home page, but very little
| information and very little outward progress. What happened
| behind the scenes I have no idea about.
| gcasa wrote:
| Still going. ;) -- Gregory Casamento GNUstep Lead Maintainer
| ChrisMarshallNY wrote:
| As an Apple dev since '86, I've used (in order of appearance):
| MPW THINK Pascal THINK C
| CodeWarrior Xcode
|
| I never warmed to other IDEs (like AppCode), but find IDEs to be
| more productive (for me) than CLI tools. Yeah, I know some fairly
| awesome CLI people, but that has never been the case for me.
|
| I write in native Swift, so it's really important that what I use
| be right on the "cutting edge."
|
| Right now, that's Xcode.
|
| Xcode is a bug farm. It's also frikkin' _huge_. I have to
| sometimes force-restart when the code parser goes walkabout.
|
| But it does give me what I need. I'd certainly be open to viable
| alternatives, but nothing has come up that has enticed me.
| ternaryoperator wrote:
| > Xcode is a bug farm. It's also frikkin' huge. I have to
| sometimes force-restart when the code parser goes walkabout.
|
| Have a look at JetBrains CLion with the Swift plugin. It has
| served me well.
| ChrisMarshallNY wrote:
| _> Have a look at JetBrains CLion with the Swift plugin. It
| has served me well._
|
| Thanks.
___________________________________________________________________
(page generated 2021-12-13 23:02 UTC)