Yes, it would always be possible to acquire a commercial license if any of the open source licenses are unsuitable.

I don’t think it’s an issue, also would we be able to contact you and request a separate release with a different license if that was needed?

I'm thinking about changing the license with the 1.0 release. My current consideration is the LGPLv3 and I was wondering if this would help anyone, but also if this would be a problem for anyone?

Wow, that's aweseome! Thanks for working on this! I'll check it out!

There now is a first working state of the generator for CoreGTK ported to ObjFW that was renamed to ObjGTK over here.

The example app is working. For everything else (memory management, ARC) there still is some work to do.

I first want to get MRC memory management right and then try to make the generator more general so that it may work on more of the GTK classes and libs. Especially I'd like to generate wrappers for libgranite and libhandy which are important for modern desktop and mobile app development. But same applies to more of the GTK/GLib/GNOME libs probably.

Side note:

I only have zip snapshots because this project wasn't planned, I just wanted to have a play with some bare metal coding on a x86 machine (something I've not done before, my background is mostly with ARMs and as you can probably tell, the 68k in the distant past). The whole thing has been written with notepad/textEdit and i686-elf-gcc, all the source files are just compiled with a simple script and then linked into a single blob which GRUB can load. There is no proper build system or anything resembling a proper project structure.

I had never intended it to get this far, I just wanted to bring the machine up with a framebuffer and then just treat the PC like a massive microcontroller. But I just kept adding bits until I had rudimentary desktop OS, and I've never build a Desktop OS before (I've written kernels for microcontrollers, which is somewhat obvious from the architecture I have used), so I have just kept going.

I only added the project to GitHub because some friends wanted to play with the source. But, perhaps understandably given the state of the source, no one is particularly interested in contributing, so I've not really bothered to clean the sources up, use version control, and add a proper build system.

On topic:

This is great! Thanks for the information, it gives me a direction and lets me know what features I need to add next.

Currently (as of last night), I just managed to get the filesystem working (it can now read the boot disk) so I'll be adding POSIX compatible filesystem IO functions as required... Then I need to get my ELF loader working...

Interesting project! I like the themes 🙂. Side note, though: Why are there only ZIP files of the source checked into the Git repo?

On topic: ObjFW should be a perfect fit for this, given that it supports a large range of very different OSes already, some of them having what can barely qualify as an excuse for a libc 😉. As well as running on embedded.

To get started, I would recommend to run configure with something like this:

./configure --host=x86_64-pc-unknown-elf --disable-shared --disable-threads --disable-sockets --disable-files

(Replace --host=x86_64-pc-unknown-elf with whatever triple your cross-compiler uses)

This should give you an ObjFW that requires no functionality from the OS and only a somewhat working libc for memory allocation etc. If you run into any problems with basically all features disabled, please provide compilation logs / describe errors, and I can see to make ObjFW not use what you are currently missing. It's possible that it currently requires something that all platforms happened to have in common by pure chance, though I think that's quite unlikely.

The next step then is probably that you want files, as those also give you the standard input and outputs. ObjFW currently assumes that there is open(), read(), write() and close() for this, though if it's helpful, I could also let it fall back to fopen(), fread(), fwrite() and fclose(). But so far, I have not found a system that only has the f* variant, despite the f* ones being C99 and the ones without f only being POSIX.

I suppose sockets aren't supported by your OS, so that probably should be kept disabled. Threads either use an OS-specific API or, if it does not know about an OS-specific API, checks if the OS supports pthreads. Shared library support just requires your OS to support, well, shared libraries (it assumes you are on ELF and use .so files if it does not know the OS).

Hi all,

During COVID lockdown, I’ve been writing my own hobby operating system… It started out as nothing particularly serious, just some idle coding in the evening with a glass of wine or two. So I had no particular plan, goal or structure in place as to the design.

Anyway it’s now booting to a functional GUI, working multitasking, and FAT32 filesystem support. I’m currently adding file IO functions, and I have starting thinking about implementing an Application layer.

I have been wondering how easy/difficult it might be to do this in Objective-C using Obj-FW? Does my Kernel (such that it is), have enough feature to support Obj-FW?

My Hobby OS project (including some bootable hard disk images) can be found here: https://github.com/h5n1xp/CuriOS

To sum it up:

I want to try porting CoreGTK (the CoreGTK generator) over there: https://codeberg.org/Letterus/coregtkgen

This is mainly to get into it. If I succeed there at least would a thin wrapper for GTK3 (and maybe libhandy later). I could use what I've learnt to improve a new version for GTK4.

I am still thinking about the port. It seems Tyler Burton has implemented a solution for way number 1 (ObjC callbacks). I think way 2 (data binding) is missing at all. This is because CoreGTK is a wrapper around GTK only and thus provides no features of GLib as GObject binding. On the other hand we probably can't use ObjC binding (KVO) because CoreGTK still uses plain C GObject structs.

What do you think? How much is data binding needed? I know UIKit tries to avoid KVO mostly (compared to AppKit), but I'm not familiar with UIKit programming. Would you recommend to try a port of CoreGTK?

Hello Kyle,

thank you for your proposal containing option 6 which I have thought about a while.

First I think that your approach of saving work and getting things done the fast way should really be considered taking into account our very limited manpower. But I'd also like to add that I never considered writing a Gtk wrapper manually but rather to create a generator or use one of the existing ones to accomplish that goal. Nonetheless - that's still much work of course.

I'd also like to add that we should not model anything after AppKit, but rather look at UIKit from my point of view. Just because UIKit is the framework which is way newer and also way simpler than AppKit - at least afaik. I have to admit I've never developed an app using it.

Considering the MVC design pattern I agree with you that Gtk already provides the View part using C language elements (or utilizing GtkBuilder and ui files). So we do not need that part to create apps using ObjFW, which is a great feature of ObjC of course.

I think, what we actually need are the glue parts between the view layer (Gtk or maybe UIKit as a drop-in replacement) and the controller layer. As far as I understood that's the point where UIKit utilizes ViewControllers (VC). I think we also need

1. a way to set ObjC methods as callback functions for a Gtk view and
2. a way to do data binding / key-value coding.

As I do have too limited experience for both Gtk and UIKit I think I'm going to create a little app using Gtk and UIKit for the views at some point and try to figure out which parts are missing exactly. Once I managed to create the needed parts for a concrete example I think I'd be able to think about a more general solution.

Currently I'm quite confident that it won't be too complicated using ObjC. So even having a first small example app would be a "very nice to have" from my point of view.

As I really like the development going on for Gtk4 and libadwaita (former libhandy) I'd favour trying those.

Option 6:

Rather than wrap the entirety of an existing UI toolkit, or create a new one entirely from scratch, instead make a new ApplicationKit-like MVC framework that uses un-wrapped GTK+ calls to draw itself and handle input.

GTK+4 is now stable, and has been considerably simplified; it could be used for this purpose without bindings as it is already a C library.

We would begin by implementing two classes; here I will use the OF- prefix, as we are talking about an "official” UI framework for ObjFW. These classes are OFWindow and OFView.

OFWindow is by far the simpler of the two; it is essentially an Obj-C object which wraps the basic functionality of GtkApplicationWindow. It uses a GTK+ widget hierarchy to show an optional headerbar and a single main OFView, sized to fill the window's available area.

OFView, on the other hand, is both far more complex and the absolute core of the entire UI. It is the class which defines what a "view" in MVC is. It has the following capabilities:

• Draw arbitrary text and graphics to the area provided for it by its superview.
• Draw an arbitrary GTK+ widget hierarchy in its area, arranged using whatever GTK+ layout is appropriate.
• Position subviews within its alloted area, relative to its own borders, using GTK+'s now-stable constraints-based layout system. Subviews overlap the drawable surface.
• Recieve event messages generated by mouse and keyboard events, as translated by GTK+ callback functions attached to the relevant signals.
• Recieve target-action messages from other objects.

Further, OFApplication would recive enhancements to interface with the GtkApplication class, allowing it to manage menus and the like, as well as recieve and respond to UI event messages.

Event messages, as generated by widgets, would first go to the widget’s parent OFView; the default behaviour for all event messages is simply to forward the event message to the superview, or, if there is none, to the parent OFWindow, or if there is none, to the OFApplication instance.

It should be fairly easy to see how these two classes provide the basis for a complete set of views. Futher on, we can develop data source protocols for complex views, such as tables and columns and icon views, allowing essentially arbitrary model classes to be used with them.

Benefits:

• ObjFW applications will run wherever GTK+ runs.
• Familiar in general to AppKit devs, without being a clone.
• Able to address any flaws in AppKit's design.
• It will fit with the Objective-C way of doing things.
• It will be able to use the native menuing systems on all supported platforms.
• Development will be very much faster than wrapping every GTK+ class individually, not to mention faster than doing it all from scratch.
• We can use the GTK+ port of WebKit to make OFWebView.

Drawbacks:

• Everyone who helps code it needs to at least understand the basics of how GTK+ works. It's not terribly difficult, but it is a drawback.
• We have to design and build all our OFView subclasses. AppKit does provide a rough template to work from, though.
• It won't look native anywhere but Linux and the BSDs.
• Wrappers have an inherent risk of memory leaks if not written correctly.

So, now my 2 cents. I thought a while about it and I agree with your statements above. I'd like to add some differentiation and consider desktop and mobile target platforms.

Going for desktop only

Taking a conservative desktop approach would mean to use Qt I think. It's just the most used cross platform toolkit that works very well and still looks acceptable everywhere. (This does not differentiate the Linux desktop any further, taking into account the GNU/Linux desktop got only 2,35% or something of the desktop market share.)

But if it comes to mobile (targeting iOS, Android, Windows Mobile, Plasma Mobile or Ubuntu Touch/UBports) you will need to use QtQuick/QML and/or Kirigami as well. That would mean to not only handle C++, but go the JavaScript/QML path as well. If we consider our users (I mean developers wanting to have a cross platform GUI toolkit) then I assume there are very few ObjC developers (f.e. coming from iOS development) who want to ditch their xib files and storyboards and start mangling QML.

Going mobile first

If we take into account there already is a (incomplete) AppKit port by the GNUstep project I won't target the desktop as a first class citizen again, even though most of us probably like their desktops. But mobile marketshare is 59% vs 37% of the desktop with mobile still gaining space (https://www.netmarketshare.com/device-market-share).

That means most of the ObjC devs of the last years probably were iOS/UIKit developers and not developing for the desktop (AppKit), considering macOS was having 9.77% of the desktop market share in 2019 and iOS 28.23% of the mobile one (https://macdailynews.com/2019/06/03/apples-macos-and-ios-market-share-both-up-in-may-2/).

Targeting mobile first could lead to the usage of Gtk because with the efforts of the ongoing Phosh project apps are going to work mobile using the same C code basis afaik. Using Gtk themes these may even integrate into Android.

Conclusion

To be really appealing to UIKit devs that would mean to create a Gtk wrapper which is very close to UIKit. ObjC devs thus could provide a Gtk based frontend for Android/Gnome/Phosh/Windows (Mobile) with maybe little changes, but leave it unchanged for the Apple platforms. (UIKit apps sooner or later are going to work at every Mac, despite the ongoing development of SwiftUI of course, with Swift currently not providing ObjC bindings for Linux.)

As a free surplus of taking the Gtk way you will get that the Gnome/Elementary OS/Phosh communities probably are much more welcoming an approach that allows porting Cocoa (Touch) based software than the Qt/C++ communities.

Finally I like C over C++, but that's just personal preference.

Edit: Removed the reference to Android. There is no reasonable port of Gtk for Android yet.

For option 1 - 4, there needs to be a decision between Gtk and Qt. Here's some thought I have, but nothing is set in stone:

Pros for Gtk:

• gobject's object model is inspired by Objective-C, so pretty compatible
• Gtk apps look good on GNOME and KDE (KDE can make it look like a native app), it looks OK on Windows
• Gtk is written in pure C, so we would not need to make sure that our headers contain no C++ (even transitivly)
• There is gobject-introspection that should make it easier to create bindings

Cons for Gtk:

• It looks meh on Mac, but is still fully functional

Pros for Qt:

• It looks good on Windows, KDE, Mac

Cons for Qt:

• It is written in C++ and special care needs to be taken that the GUI framework does not end up with headers that need C++. That means redefining every enum as a C enum and wrapping absolutely every class. It also means often using void pointers and lose type safety.
• It uses multiple inheritance which does not work with the Objective-C object model, so this needs to be hacked around.
• Qt apps still look alien under GNOME, despite some attempts to make that better.

Open questions for Qt:

• Is there something like gobject-introspection that can make it easier to create bindings? Anything else I forgot?

No worries about limited experience / knowledge. I'm personally happy to help. I’m happy to teach and delegate - this is a project for multiple people after all, so any time invested to get someone up to speed will be well worth it in the long run.

On the chat, there is currently a preference for option 4 (the hybrid). I guess it makes sense, as it allows you to have a nice API and also break out of it if something is missing and hence might result in something usable quicker. But nothing is decided yet and you are the first one to commit to joining the effort 🙂. Let’s keep the discussion going and hope that more people are interested to help!

Ok, than is here my Reply on this Thread. :D

"Here, I'm interested!"

For me i can say that Option 3 is the way i would wanna go.

First of all my skill set in Objective-C is not so big(nearly null) but I'm very interested to learn it (learn to hack a toolkit and work with objfw/obj-c) with kind of this projects.

My second thoughts for Option 3 is that it will help and push ObjFW as project and i like to help in this kind of way.

I really use a lot of GTK-Applications(gnome and so on... :P ) but if there are more people to build the first steps with QT or something else, I'm fine with that and will jump on, to help the best way i can.

Side-Info: In the ObjFW-Matrix chat my display name is ka

tl;dr: ObjFW needs a GUI framework, there were several attempts in the past that failed, so we need to join forces. Please help, every little bit counts.

One of the things that always comes up over all these years is a GUI framework for ObjFW. There have been several attempts, usually done by a single person, that then quickly died down because the work is overwhelming. This leaves us with the current situation that there is no ready-to-use GUI framework for ObjFW, despite it being one of the most requested things and the lack of a GUI framework probably being what holds back ObjFW adoption the most. It isn't beneficial to have so many projects for a GUI framework (see below) that all ultimately fail - instead, I want us to join forces, and come to a decision which option is the best one to move forward. Please comment on this thread which option you prefer and why, and whether you would be willing to help. Every little bit counts, so even if you think you will only contribute very little, please volunteer and reply here!

Options

There are several approaches:

1. Write bindings for an existing GUI toolkit such as Gtk or Qt, mostly following the original API with slight adaptions for ObjC
2. Write a binding generator for an existing GUI tookit such as Gtk or Qt
3. Create a new API as wrappers for an existing GUI toolkit, so that it feels more like ObjC
4. A hybrid of 1/2 and 3
5. Create an entirely new GUI toolkit

Option 1

Option 1 is probably what has been attempted the most: There is adenosine with it's underlying atropine. There was GTKKit (it seems to have disappeared from GitHub, but luckily I forked it and that is still around). And there still is my own ObjQt. So there have been 3 attempts and none really got that far. Another problem they all share is that they currently need an extra thread or they block ObjFW's run loop. But that can be worked around by swizzling ObjFW's OFRunLoop to use the GUI toolkit's run loop.

Option 2

What all the attempts of option 1 have in common is that they were manually written bindings. I think this is what ultimately made them fail: The amount of work to create bindings manually is overwhelming and the toolkits grow at a faster pace than a single person can keep up with. Which brings us to option 2: Write a generator for an existing GUI toolkit. Gtk has gobject-introspection, Qt has something similar. There were brief looks into gobject-introspection, but that never went far. While it seems like a downside would be that this would have less adaptions for ObjC than option 1, this could be addressed by having tables that e.g. contain renames, manual overrides for certain methods/classes, etc.

Option 3

The downside of both of option 1 and 2 is that an existing GUI toolkit is not written around the dynamic nature of ObjC. Which brings us to option 3: Create a new, ObjC-native API, then implement it using one of the existing toolkits. The downside compared to option 1 and 2 is that it is a lot of work, and an additional downside to option 2 is that you can only use what has already been created and don't get a full GUI framework at once. This has been tried in ObjGUI, but I didn't do much on it.

Option 4

Which brings us to option 4, which is trying to get the best of both worlds: Follow option 1 or 2 to have bindings very close to the original toolkit, then write a wrapper that makes it more native (option 3) using the bindings from option 1 or 2. This allows breaking out of that more native wrapper to do things which aren't in the wrapper yet. As far as I know, this hasn't been tried yet.

Option 5

And finally, we have option 5, which is to create an entirely new GUI toolkit. The advantage is that you do not have to think about how to make an existing GUI toolkit play nice with ObjFW and that it is the most interesting option, as it allows you to create something new from scratch entirely instead of just creating a "boring" wrapper. Another advantage is of course that it could have very few dependencies, so that you can statically link it into your binary and get a single self-contained binary. And of course it will be more lightweight than both Gtk or Qt, so your static binary will not end up being gigantic. I did start this at some point (back then using Allegro as I did not want to create my own backend for every OS and since SDL2 was not a thing yet, and SDL1 can only handle one window), but never released anything. The huge disadvantage is of course that it will take time until you have all the things you need for an app and that it probably will not look native anywhere. I think this is more interesting for writing small utlility apps that you want to distribute easily rather than for apps that you want to use daily.

Next steps

So, first of all, since we already established that this is too much work for a single person, we need people who are interested in making a GUI framework for ObjFW a reality. So I would say that very first step would just be people shouting in this thread "Here, I'm interested!". Even if you can only contribute very little, please shout - every tiny bit helps! Once we have a group of interested people, we can discuss which of the options to pick and go from there, hopefully joining forces in the end fo make a single GUI framework succeed instead of having many single person projects that fail. And please feel free to hop into the chat at any time to discuss as well.