Why Qt?

[brunomaximom]

I have questions about design decisions:

Why did you choose Qt, specially PyQt5? AFAIK, PyQt is dual licensed under proprietary paid license and GPLv3, so we can't license a software under different license than GPLv3. Qt actually is facing trouble with open source support for LTS releases too.

For a project like this, would not make more sense choose a GUI library non-c++ dependent? Like GTK (yes, I know GTK people is BSD-unfriendly), EFL (BSD licensed) or LVGL (MIT)?

Why not use arcan display server? It's Wayland and X11 compatible.

[probonopd]

Hello @brunomaximom

• I tried to use GNUstep (I like many od its concepts) but the developer base seems too small nowadays, so there is little active development
• So I decided to implement the concepts with something that is in wide use today
• The only widely used GUI toolkits are Qt and Gtk these days
• Gtk is out of the question; in fact it is listed as one of the unwelcome technologies
• Most of the applications I use are written in Qt, so it provides the best native experience if we use the same toolkit for the system
• Python because the source code is always there, it is easy and fun to work with (no pointers, no memory management) and no compilation is required
• Wayland is entirely unwelcome

I am not a fan of C++ but calling into a GUI toolkit written in C++ from Python is working without too much trouble.

I have never heard about EFL, LVGL so they, like GNUstep, are probably "too exotic".

Regarding licensing: Qt is LGPL, so it is possible to do even closed source work with it if you ship the object fies (at least this is my understanding, IANAL). PyQt should be entirely unproblematic because by definition Python code is interpreted rather than compiled.

[ILoveGadgets]

Hello @probonopd

It is worth looking at EFL (Enlighenment Foundation Libraries) they are used by:

• Enlightenment window manager
• Samsung for consumer electronics
• Free.fr for set top boxes
• several GPS navigation projects

I always thought that Enlightenment was pretty fast and may fit better with your design philosophy than Qt & GTK which have a lot of design baggage from Gnome and KDE.

Info here: https://www.enlightenment.org/start

[probonopd]

hello @ILoveGadgets

Thanks for your suggestion, I keep hearing good things about it. But just like with GNUstep, I fear that it doesn't currently have the developer traction needed to have first-class productivity apps written in it. Or am I wrong? How many real-life cross platform applications are written in EFL?

[ILoveGadgets]

That is probably it's biggest problem, it is not a popular desktop, so you would still have to support other libraries to get the big name desktop apps that users want. It is a wonderful piece of engineering, but not widely supported.

There are plenty of examples of operating systems and user interfaces that have failed because end users don't care about the elegance of the engineering, they care about productivity and entertainment apps.

I think that you are right to run with Qt as it will get you a long way towards your goal without having to create everything yourself.

[brunomaximom]

The problem with EFL is the documentation. Seems like everytime is not documented enough.

About your statement @ILoveGadgets: "There are plenty of examples of operating systems and user interfaces that have failed because end users don't care about the elegance of the engineering, they care about productivity and entertainment apps."

I think there is no reason to not try. Writing a desktop suite (calculator, file manager, etc) to make the desktop environment usable is a great step trying to change how things are done nowadays. HelloSystem can be responsible for this change. Qt is a great framework, no problem regarding it, only license issues. But i think a C-based framework or GUI lib opens opportunities to write apps in any language. You cant write application in C using Qt, for example.

[ILoveGadgets]

Absolutely we should try. I look at computers from two points of view:

1. As a programmer I care about the engineering, too much of what has been developed in the last 15 years is garbage.
2. As an end user, I want to produce documents quickly and efficiently and to know that all of my files are seamlessly synced between my desktop and my laptop and backed up off site without me having to do anything or even think about it. (Microsoft have actually nailed this in Office/Win 10 it is well worth the annual subscription)

POV 2 is our customer base, 99.9999% of them neither know nor care how it works, just so long as it does. POV1 is us, and we should care about the end user's experience, if we want them to notice us.

The problem I see with FOSS and Linux in particular is a total lack of concern about the end user from many in the "community", almost like they are developing for their own personal needs and don't care about anyone but themselves, certainly non-programmers seem beneath their notice.

I fel that unless we are creating the product that ordinary people want to use, we are wasting our time.

That is why I like this project, it targets one of the best end user experiences - early MacOS and looks to bring it back to life; something that Apple won't do and Microsoft couldn't do.

Qt is a good starting point, it gets a working system quickly and access to a lot of productivity apps, but need to find or develop something that doesn't have the licence issues or language limitations. Even if it is replaced as the framework of choice, it can still be included for apps that need it.

[grahamperrin]

https://github.com/helloSystem/hello/wiki/Components#gui-toolkit

[darkstar]

Everyone suggesting EFL should give this a read: https://what.thedailywtf.com/topic/15001/enlightened Yes, he is probably exaggerating, but even if only half of it is valid, I'd stay as far away from EFL as possible :-)

[ILoveGadgets]

Interesting read, C's lack of a proper type system is it's greatest weakness and one that cannot be fixed easily. However EFL sounds like a particularly egregious example.

My complaint about Qt is the C++ dependancy which it brings. It would be nice to be rid of that language once and for all.

I see two viable routes one quick and dirty and one clean and slow:

Q&D - use Qt & GTk together to leverage as many Apps as possible, get a user base faster (but then why not use Linux). C&S - pick a language like GO or Swift and write a new framework in that language (the Apple approach).

The latter is a commitment to the future by saying even if it is harder and takes longer we reject the languages and frameworks of the past and build a new system based on clean modern designs.

[probonopd]

The way I see it:

• Most "real world" applications are cross-platform
• Most real-world cross-platform applications are written in Qt
• Hence, we are using Qt as the native toolkit

For helloSystem specific (small) utilities: When used from Python, you don't need to use any C++ to use the Qt toolkit.

Let's also keep an eye on https://github.com/mszoek/helium (ObjC/Swift) and https://fyne.io/ (Golang) as possible additional toolkits. Mac OS X used Carbon and Cocoa in parallel for quite some time.

[kettle-7]

Hmm, swift...

In all honesty, I think both Swift and Go are good, and I took a little look at Fyne and I like it, but as far as system integration/consistency across apps it has a fair bit left to go.

If possible I'd say to avoid using Objective-C for the utilities, but in bigger apps like Filer it would be fine.

https://github.com/mszoek/helium/blob/main/philosophy.md

Mmm, delicious!

[jhjacobs81]

Helium looks nice, why not see if you can work together? Why waste resources on two seperate projects, when all could be pooled together in one single project?

I imagine @probonopd would lead the OS part, while @mszoek would lead the macOS part (in therms of compatibility and frameworks etc)

[probonopd]

Yes, sounds like a plan :)

[mszoek]

Thanks for the compliment! It’s early still, but we are starting to find ways to work together. Helium is now built on top of helloSystem (which is mostly why it looks so nice!) and I’m currently working to add Cocoa support for DBus and the global menu bar in hello.

[kettle-7]

Is there any open source details about the Mach executable format ?

Also, does Helium use display PDF, X or wayland?

[kettle-7]

The new innovation:

helloHelium!

With helloSystem and Helium together, you can run Mac OS and Linux apps (and maybe even Windows if WINE is a welcome technology) on FreeBSD!

It sounds like a plan, and if we can get NeXTSTEP developer tools to work (I have a copy of those somewehere), it would be a great platform for developing and running apps alike. Build on one platform, test for three.

[mszoek]

Is there any open source details about the Mach executable format ?

Also, does Helium use display PDF, X or wayland?

It currently uses an X11 and OpenGL (on X) backend, and there is some support for PDFKit and basic QuartzCore APIs. I am likely going to move towards Qt for the UI widgets to have a more standard look and feel with the rest of the system.

[kettle-7]

I am likely going to move towards Qt for the UI widgets

Will that mean that the NeXTSTEP API implementation just calls the relative Qt functions, or that Qt is used directly?

Or would it be something like a fork or re-implementation of GNUstep, but it looks more modern? (Not that hard to make something more modern-looking than NeXTSTEP, it looks very out of date)

[mszoek]

Will that mean that the NeXTSTEP API implementation just calls the relative Qt functions, or that Qt is used directly?

The former. A major goal of Helium is to be source-compatible enough to macOS that applications can be built on it with no, or at least minimal, changes. Qt would be hidden by AppKit.framework just as libX11 etc is today.

Or would it be something like a fork or re-implementation of GNUstep, but it looks more modern? (Not that hard to make something more modern-looking than NeXTSTEP, it looks very out of date)

I looked at GS early on but decided it wasn't suitable. I am using their libobjc2 though - it was more modern than Cocotrom's, which is the original source of most of Helium's frameworks.

[jhjacobs81]

well, whatever is chosen, there's a lot to be done still :)

Are there any mac apps that can be tested already? or am i too far ahead? :)

The new innovation:

helloHelium!

With helloSystem and Helium together, you can run Mac OS and Linux apps (and maybe even Windows if WINE is a welcome technology) on FreeBSD!

It sounds like a plan, and if we can get NeXTSTEP developer tools to work (I have a copy of those somewehere), it would be a great platform for developing and running apps alike. Build on one platform, test for three.

AND.. with helloStore, we could even write our own apps, without the (sometimes completely crazy) demands Apple adds to their store..

But i'm slightly concerned that integrating too much of Apple might make them target us (hehe.. look at me, pretending im already part of this project) for legal actions. Has anyone considered this?

[mszoek]

@jhjacobs81 You're too far ahead :) Simple Cocoa apps can be built into .app bundles and run - there is a sample in the Helium repo. Help to flesh out missing APIs would be most welcome!

I have definitely thought about the legal angle. I think we're on pretty solid ground, but we have to be careful and I would totally welcome real legal advice here.

I worry more about patents than code copyright: a clean implementation of code written to a public API is not infringing, and there is a good history of similar projects like GNUstep, React OS, Wine, Darling, Open/Pure Darwin, Cocotron, etc. Patents are harder to avoid, but this is a risk in any software project :) We also can't use any Apple trademarks or brand elements. Those are fairly easy to avoid.

An app repository should be OK. Many Linux distros had package repos and software installers that pulled from them way before the App Store.

Finally, just for the record, I am in no way looking to harm Apple or even really compete with them. I've been an Apple user/customer/fan for a long time. My goals for Helium are really:

• provide an open-source Unix-like OS with a really good, familiar user experience
• encourage commercial & open-source developers to build their existing macOS apps for it so that users can have all their favorite things
• learn a ton and have fun

[kettle-7]

On the note of helloStore, I have something planned and underway...

It shall take care of updates, and let you browse .app bundles and download them to your computer in ~/Applications.

[jhjacobs81]

@linuxkettle That would be awesome. do you have anything to share? :P i think i mentioned somewhere that hellosystem.io is still available.. we should claim it before someone else does! Everyone would know that anything from store.hellosystem.io would be safe, it gives them a single point of access to the world of hellosystem, so to speak.

imagine if you could couple with with a helloYou account, (i know.. not everyone is pro accounts) that could sync my apps and settings across multiple devices, but without the pressure and the data grabbing the bigTech's put on this. I could use helloYou on my primary devices, and on my work device i would not use it. nothing synced, nothing pressured.

I know this is not the core idea of this project, but it would be a welcoming "addon" i am sure of this :)

@mszoek well.. thinking ahead is what i do ;-) especially if i think something is worth building a future for ;-)

[kettle-7]

This is looking great!

Unfortunately, I don't have enough of the store to share right now, but when I can I'll start a GitHub repo for the store itself, and another for the repository. The repository would have two branches, stable and testing, so that confident people can test the apps before I've determined that they work from an app bundle.

I might need to implement a chroot-like thing for stubborn apps that depend on being installed to /usr.

[jhjacobs81]

Whats looking great?

be nice to have an “advanched” settings pane where i could tick the “show unstable repo” and then add the instable repo :)

as a store manager, you should write down some form of “helloSystem compatible app guide” with some basics that apps should do to make it work? Like what directory’s they should go in to, maybe even some design guidelines. Create unity amongst the apps :) This would not work for already existing apps obviously, but for new apps this could make your life easier, as well as the dev who wants to write for hS (helloSystem)

I was also thinking, a lot of people have paypal or skrill or anything, could you somehow make that work with hSS (helloStore)? That way, dev’s could sell software? Get paid for their work?

[kettle-7]

Just the state of this project in general, I'm very excited.

be nice to have an “advanched” settings pane where i could tick the “show unstable repo” and then add the instable repo :)

That's the idea!

as a store manager, you should write down some form of “helloSystem compatible app guide” with some basics that apps should do to make it work? Like what directory’s they should go in to, maybe even some design guidelines. Create unity amongst the apps :) This would not work for already existing apps obviously, but for new apps this could make your life easier, as well as the dev who wants to write for hS (helloSystem)

That's a good idea, but for now you can consult the developer guide at https://helloSystem.github.io/docs/.

I was also thinking, a lot of people have paypal or skrill or anything, could you somehow make that work with hSS (helloStore)? That way, dev’s could sell software? Get paid for their work?

That would need a bit more work and some legal tightening. Also, I'm thinking 25% commission is good? :~)

[kettle-7]

imagine if you could couple with with a helloYou account, (i know.. not everyone is pro accounts) that could sync my apps and settings across multiple devices, but without the pressure and the data grabbing the bigTech's put on this. I could use helloYou on my primary devices, and on my work device i would not use it. nothing synced, nothing pressured.

So sort of like my Firefox account?

[jhjacobs81]

I’m not sure how FF handles things, but i suppose yes. Imagine if we could couple that with an app called helloServer which i could install on my own helloSystem, then i’d truely have my own privacy! Much like Apple’s server.app. We could even earn funding by making some kind of DDNS system for users who dont like to thinker around with router settings etc. (I could have jhjacobs81.server.hellosystem.io routed to my own dynamic IP) so i could always have access to my helloDrive.. true Apple syncronisation, and true privacy!

[jhjacobs81]

I too like the idea’s behind the project. I actually wrote a blog called “Apple is dead, long live Apple!” About how i dislike their current stonewalling trends. But at the same time, there’s truely nothing better so i’ll just swallow my principles and “just tollerate” it.

But an OSS counterpart.. well thats definatly something i want to invest time in :) unfortunatly i’m no good a programmer yet, but i have plenty of idea’s and i can help test things, and think things through :)

[kettle-7]

But an OSS counterpart.. well thats definatly something i want to invest time in :) unfortunatly i’m no good a programmer yet, but i have plenty of idea’s and i can help test things, and think things through :)

In a way, that's more important. Anyone can learn to program (if you're like me it'll be seven years before you get anywhere, but have patience) but it takes strong innovators and recklessly creative people to give those programmers something to do. And from your level of involvement in this project, you are both.

[probonopd]

On the note of helloStore

Please call it something else so as to not confuse people thinking it is something that has to do with helloSystem. A store is not in our plans.

a helloYou account

About the last thing we want. That you need an account in order to download software made me abandon the Apple platform.

[probonopd]

Let's stay on topic please, which is "Why Qt".

In a nutshell, because it is the most-used cross-platform UI toolkit used by real-world applications.

Cocoa/Helium might be preinstalled in helloSystem in the future if we can somehow make it look and feel as "native" as possble. Which would provide for a nice code-level migration path for existing Cocoa applications.

[louies0623]

How about Lumina or icevm.

[9gay]

@probonopd https://github.com/letoram#arcan

• not wayland and not x11, replaces both
• display engine
• can run x11 apps through Xarcan or arcan-wayland -xwl and wayland apps through arcan-wayland
• desktop environments are implemented in lua without breaking compatibility with apps
• natively supports every single bsd without depending on epoll, evdev, dbus and other linux crap because its author likes x11 and bsd and hates wayland and linux

back to the topic: how about tcl/tk?

• implemented in C
• cross-platform
• lightweight
• themeable
• write apps in tcl scripting language (or any other language through bindings, like tkinter in python or embedded in C, but tcl is best)
• backwards compatible so upgrade to 8.28 will not break apps and themes for 8.6
• much easier to use than both gtk and qt
• bsd-style license
• most notable user: Brian Kernighan
• shouldn't be hard to force all tk apps to use global menu by simply redefining menu command, on macos tk uses global menu:

[probonopd]

Yes, there are all sorts of interesting other toolkits, but there are usually no to very few "real world" applications written for them, whereas most applications I use are cross-platform and written in Qt, so they feel most "native" on a Qt based desktop.

So unless there is a very convincing reason, helloSystem will not be switching away from Qt 5. The move to Qt 6 is already more work than I have asked for ;-)