Other Gershwin Desktop Environments

M

malco_2001

The Gershwin Desktop environment featuring the first iteration of the native window manager was presented today during the GNUstep monthly meeting. This was a huge milestone for us today with a wealth of information about the design and implementation which I believe will interest a lot FreeBSD enthusiasts like myself.

View: https://youtu.be/DDwLzy8map8


Also some quick info about it:

github.com

GitHub - gershwin-desktop/gershwin-desktop: Desktop Environment based on GNUstep welcoming to switchers

Desktop Environment based on GNUstep welcoming to switchers - gershwin-desktop/gershwin-desktop
github.com github.com

The build system here can install in just a few minutes on low spec hardware as other than login window which installs to /usr/local/etc/rc.d is entirely self contained in a 50mb installation at /System.

github.com

GitHub - gershwin-desktop/gershwin-build

Contribute to gershwin-desktop/gershwin-build development by creating an account on GitHub.
github.com github.com

To integrate non native apps run the appwrap command from a terminal.

Over the coming weeks we will be adding new features such as OSS, Virtual OSS sound backend integration. I believe the presentation speaks for itself but we want FreeBSD to be a first class citizen and not something that has to play catchup. We want to be offer an environment familiar to “switchers”. That also extends beyond Mac OS X in our roadmap as noted at the beginning of the presentation after the app image presentation and Wayland discussion.

I hope this was okay to post here. Happy new year!
 
malco_2001 said:
The Gershwin Desktop environment featuring the first iteration of the native window manager was presented today during the GNUstep monthly meeting. This was a huge milestone for us today with a wealth of information about the design and implementation which I believe will interest a lot FreeBSD enthusiasts like myself.

View: https://youtu.be/DDwLzy8map8


Also some quick info about it:

github.com

GitHub - gershwin-desktop/gershwin-desktop: Desktop Environment based on GNUstep welcoming to switchers

Desktop Environment based on GNUstep welcoming to switchers - gershwin-desktop/gershwin-desktop
github.com github.com

The build system here can install in just a few minutes on low spec hardware as other than login window which installs to /usr/local/etc/rc.d is entirely self contained in a 50mb installation at /System.

github.com

GitHub - gershwin-desktop/gershwin-build

Contribute to gershwin-desktop/gershwin-build development by creating an account on GitHub.
github.com github.com

To integrate non native apps run the appwrap command from a terminal.

Over the coming weeks we will be adding new features such as OSS, Virtual OSS sound backend integration. I believe the presentation speaks for itself but we want FreeBSD to be a first class citizen and not something that has to play catchup. We want to be offer an environment familiar to “switchers”. That also extends beyond Mac OS X in our roadmap as noted at the beginning of the presentation after the app image presentation and Wayland discussion.

I hope this was okay to post here. Happy new year!
Click to expand...
A Makefile make requires root ?. Are you kidding.
Never not even in my jail.
Typical gnustep
Makefile make requires nobody , ok :)
 
Alain De Vos said:
A Makefile make requires root ?. Are you kidding.
Never not even in my jail.
Typical gnustep
Makefile make requires nobody , ok :)
Click to expand...
The projects do not require root to build. If fact you can even install gnustep apps with
Code: 
gmake
and
Code: 
gmake install
in
Code: 
~/Applications
just by exporting
Code: 
GNUSTEP_INSTALLATION_DOMAIN="USER"
after it is installed. In fact GNUstep itself can even be built with the "STANDALONE" layout so it can be installed in any folder you want your user would have access to.

You can technically clone the many repos gershwin requires, and run gmake without root privileges. We wanted the build process to be easy for ourselves to be able to easily wipe the /System by running sudo make uninstall and reinstall the latest components after running ./checkout.sh quickly.

Anyway I understand it won't be for everyone but thought I should clarify the root access requirement in the script is just to make it work in a more automated fashion with less steps for myself, and other developers working on it. That is not because of GNUstep.
 
Also basic OSS support is already done:

1768111474465.png

github.com

Adding OSS support for FreeBSD by pkgdemon · Pull Request #24 · gershwin-desktop/gershwin-components

github.com github.com
 
I tried gershwin-on-debian-20260106180736-x86_64 in VirtualBox and like it!
  1. Is there a way to have a universal app launcher menu?
  2. Can .desktop launchers be right-clicked for other options? ( [Desktop Action X]) I have custom game launchers and right-click for updating or save backups
  3. Is screen lock possible? Maybe as easy as installing xscreensaver and using its GUI config?
  4. Can it be installed on FreeBSD for a similar presentation like Debian Live? Like instead of installing Xfce, I build/install Gershwin, then startx to the desktop?
 
Maybe,
pkg info | grep -i menu
Code: 
pkg info | grep -i menu
deskmenu-1.4.5_2               X11 application launcher
dmenu-5.1                      X11 menu application designed for the dwm window manager
garcon-4.20.0                  Freedesktop compliant menu library
gnome-menus-3.38.1             Implementation of the FreeDesktop Desktop Menu Spec
kf6-kxmlgui-6.18.0             Framework for managing menu and toolbar actions
libdbusmenu-16.04.0_8          GLib and Gtk Implementation of the DBusMenu protocol
libdbusmenu-qt5-0.9.3.160420160218_13 Qt5 implementation of the DBusMenu protocol
libxfce4menu-4.20.2            Widgets library for the Xfce desktop environment
lxqt-menu-data-2.2.0_1         Freedesktop.org compliant menu files for lxqt
mate-menus-1.28.0              Implementation of the FreeDesktop Desktop Menu Spec
menu-cache-1.1.0               Library used to read freedesktop.org menus
menumaker-0.99.14              Menu generator for X Window Managers and desktop environments
wmenu-0.1.9                    Efficient dynamic menu for Wayland
 
I repeat myself, make needing root. This means it install stuff. No problem. But i need "unmake". I don't want files installed i don't now where which i'm unable to know, or unable to uninstall.
That's why FreeBSD has pkg. Pkg allows to remove all files installed ...
 
Alain De Vos said:
I repeat myself, make needing root. This means it install stuff. No problem. But i need "unmake". I don't want files installed i don't now where which i'm unable to know, or unable to uninstall.
That's why FreeBSD has pkg. Pkg allows to remove all files installed ...
Click to expand...
Valid points. We do have packaging in ghostbsd. Eventually FreeBSD will have packaging as well. The gershwin-build is primarily targeted for devs working on it, or anyone who is comfortable knowing that everything it is installs lives in /System and can be removed with rm -rf /System or sudo make uninstall. The only single file installed outside of the prefix is /usr/local/etc/rc.d/logindow but that will change and it will be in /System as well. We want the entire thing to stay self contained in /System regardless of whether or not is is packaged, or built from sources.

We won't be installing things to /usr or /usr/local and things like that. It's designed to be 1 folder that contains the entire system. Anything the user builds for the local machine goes into /Local. Eventually the user will be able to grab app bundles and drop them into /Local/Applications with a password prompt, or ~/Applications no password prompt. Then there is also /Network for network computing. Think of /System as one entire bundle with just the things you need to start the desktop, and nothing non essential.

See the Domains info here:

github.com

GitHub - gershwin-desktop/gershwin-documentation

Contribute to gershwin-desktop/gershwin-documentation development by creating an account on GitHub.
github.com github.com
 
Espionage724 said:
I tried gershwin-on-debian-20260106180736-x86_64 in VirtualBox and like it!
  1. Is there a way to have a universal app launcher menu?
  2. Can .desktop launchers be right-clicked for other options? ( [Desktop Action X]) I have custom game launchers and right-click for updating or save backups
  3. Is screen lock possible? Maybe as easy as installing xscreensaver and using its GUI config?
  4. Can it be installed on FreeBSD for a similar presentation like Debian Live? Like instead of installing Xfce, I build/install Gershwin, then startx to the desktop?
Click to expand...
Yes we do not yet have an up to date livecd for GhostBSD but I am planning to work on that soon. It's a bit harder to do packaging and we wanted to get the window manager and other things in real shape to replace XFCE components that were used to demo for GhostBSD. I think we will probably have a stock FreeBSD based livecd in the near future as well. For now what I do is use gershwin-build to reinstall regularly on my FreeBSD desktop. It only takes a few minutes, not hours.
 
I should note that I had freebsd packaging early on. Then poudriere started having issues with 14.3 because and package fetch stopped working which might be fixed by now but I couldn't build and host the packages easily in cirrus CI with GitHub any longer because I couldn't fetch rust.

Lesson learned which is why I took many months to focus only on getting the native window manager in shape that I'd started working some years ago. Now it has some work to do but I think it's good enough to work on cirrus CI again soon for nightly packages. I've been using it daily for development.

What gershwin-build and live ISOs we do have pulls in no xfce, no rust, etc. It is all native components now under 50MB of storage. So it's just a matter of finding time this month or early next to make redo all that work to make a fresh set of ports that create hosted packages again. That will be the right foundation to make a new livecd in the future, that can easily be upgraded with pkg if installed.
 
Espionage724 said:
I tried gershwin-on-debian-20260106180736-x86_64 in VirtualBox and like it!
  1. Is there a way to have a universal app launcher menu?
  2. Can .desktop launchers be right-clicked for other options? ( [Desktop Action X]) I have custom game launchers and right-click for updating or save backups
  3. Is screen lock possible? Maybe as easy as installing xscreensaver and using its GUI config?
  4. Can it be installed on FreeBSD for a similar presentation like Debian Live? Like instead of installing Xfce, I build/install Gershwin, then startx to the desktop?
Click to expand...
1,2,3 not yet. 4 see gershwin-build as noted above until packages are built again. Technically 3 yes screensaver should work, but I had thought to add support for Innerspace.app at some point which is the native screensaver and integrate into system preferences, and other places. We only just added the context menu for NSMacintoshInterfaceStyle which did not yet exist in Workspace for that interface style, but I will have to give that some thought. I do know exactly what you mean having used game launchers myself.

We don't use .desktop launchers we have appwrap to create wrapped application bundles. Eventually we are envisioning all software can be bundled, including X11 software (no need for wrappers). If by universal app launcher menu you mean something that shows all the installed bundles in 1 place like a dashboard, yes I could see having something like that in the future. The design is still a bit early.

We have also talked about leveraging GNUstep theme engine to make additional themes for NSWindows95InterfaceStyle, or something completely new. WindowManager.app uses GSTheme natively to make NSWindow frames and draw NSTitleBar. What WindowManager.app does isn't a different theming mechanism like WindowMaker, nothing against WindowMaker but WindowManager.app is doing real AppKit decorations for X11 windows. This empowers us in the future to allow users to change the experience entirely with just a theme change. Changing themes using the existing APIs can change not only the look, but how it works. For now we have just been focusing on NSMacintoshInterfaceStyle since all other GNUstep based projects have historically focused on NSNextStepInterfaceStyle and we wanted to break the misconception that this was the only possible interface. I imagine soon over the next year or so we will be able to show the same again with other options.
 
Alain De Vos said:
I repeat myself, make needing root. This means it install stuff. No problem. But i need "unmake". I don't want files installed i don't now where which i'm unable to know, or unable to uninstall.
That's why FreeBSD has pkg. Pkg allows to remove all files installed ...
Click to expand...
make install has always required elevated privileges if the install target is outside the user's directories (or whatever his permissions/ACLs allow).
Even pkg install must be run with elevated privs.

So simple make on something? I've not seen it needing root. Heck if you have a local ports tree that your user has rw access to you can make all day long.
But you can't make install to /usr/local
 
mer said:
One of these days we are going to hit V1.0.0 which will probably break everything. :)
Click to expand...
Hahaha. I did use WindowMaker early on, and years before ever starting this project. One of the things that drove me to WIndowManager.app was seeing that GSDE a separate project had created gs-wmaker that could sync theme colors with GStheme. Then I found xcbkit by another project who was writing a window manager for UROS based on GNUstep that seemed to be unfinished but was a great start. I realized that was a path forward to a real native solution, that could integrate better. So I redesigned it to be an AppKit app over time. I've got a few things to fix up for logical button placement and app miniaturization handling for that mode and so on but in the future I could see this being a drop in replacement for that look and feel as well that integrates perfectly both ways.
 
  • Like
Reactions: mer
Where it could see it changing a bit more or evolving would be having actual live window previews when applications are minimized. UROSWM had this and I want to go back and finish it. For now I've turned off the mini window previews in the WIndowManager.app fork based in UROSWM until the feature can be worked on since it was just saving a hardcoded image which would break when multiple windows for the same app were minimized. So imagine the WindowMaker style, but with live previews when a window playing a YouTube video is minimized.
 
  • Like
Reactions: mer
My opinion:
This is good work, good concept. Original NextStep and MacOs had some very good UI/UX features/design rules that made things very useful
GnuStep (to me) is a logical extension of this and is really (simplified) just a set of libraries you can use to do things.
Not much different from GNOME/Qt/Whatever in concept.

So thanks for doing this.
 
Thank you. This is a good opportunity to say that we do aim to be different than GNOME/KDE not following the status quo in regards to locking into technologies like pulseaudio, pipewire, systemd that are kind of linux first, and expecting porters to do work to make shims for other systems. Having OSS support for FreeBSD is one small example of that and being more POSIX and agnostic by having multiple backends. For linux we can also support just ALSA for those that do not want pulseaudio, pipewire. The video explains more about XDG I will let that speak for itself but hopefully overtime we are able to show a real difference in our approach as well.
 
You must log in or register to reply here.
Back
Top