Consider renaming "unix" and "darwin"

[kainjow]

To me, "unix" and "darwin" don't really make sense. "gtk" and "cocoa" seem more appropriate since that is what the code is wrapping.

Mentioned previously here by @billyquith

[andlabs]

I used darwin because that is the name of the OS X platform in Go, so code files that only work on OS X would be named file_darwin.go. That's the history behind that. By the same logic I could have used posix instead of unix (as that's what Go's own source code does) but I did prefer the latter over the former. That's also why windows is used instead of the more common win32.

Of course, the original intent was to tie the OS to the GUI toolkit used. If there's a good reason to allow any OS to use any GUI toolkit then I could rename these as suggested. The only reason I can think of is to add a qt target as so many people have asked for. Are there others? Would it make the build scripts more manageable?

[billyquith]

I used darwin because that is the name of the OS X platform in Go, so code files that only work on OS X would be named file_darwin.go.

Interesting. It might be because Go only uses the C BSD UNIX part of OSX (Darwin). The rest of OSX, sitting on top of that, is Objective-C, e.g. Cocoa. So you're using OSX, not Darwin.

By the same logic I could have used posix instead of unix (as that's what Go's own source code does) but I did prefer the latter over the former.

POSIX is a standard, so I guess they are saying they are using the POSIX standard. There are many small differences between Unices (BSD, Darwin, IRIX, etc).

That's also why windows is used instead of the more common win32.

Win32 is more specific to the GUI library library libui is using. Windows has multiple GUIs (MFC, AFC, WPF). Granted not all in C/C++ and perhaps practical to use here.

Of course, the original intent was to tie the OS to the GUI toolkit used.

It's a noble aim but you might have to buy a fireproof suit 😆, especially when you are aiming at Linux. Their community is deeply divided between GTK+ and Qt. On the one hand it fosters competition, which leads to innovation, but do wonder how far Linux would have come without all the factions. It's one of the reasons I use OSX, you get a nice solid UNIX platform with a single GUI on top. Anyway, I'm waffling.

If there's a good reason to allow any OS to use any GUI toolkit then I could rename these as suggested.

The aforementioned reasons.

The only reason I can think of is to add a qt target as so many people have asked for. Are there others? Would it make the build scripts more manageable?

I mentioned in the other thread a possible structure. I've had similar issues with my Gwork library re-platforms and rendering APIs.

Platforms:

• Windows
• OSX
• POSIX
• Qt - this is cross-platform

And your GUIs are:

• Cocoa
• Win32
• GTK+
• Qt5 - The 5 is important as Qt4 was around for quite a while. You want 5!

So the GUI supplies the windowing code and the platform supplies everything else, which can be shared between GUIs. Best to think of the abstraction rather than the OS. I.e. what does a platform provide, and the platforms just implement a driver, like the model you have. True cross platform libraries are a platform in their own right at this abstraction level. I'm not sure about GTK+, it is cross platform, but I've also read it is lacking as a platform.

[billyquith]

So a possible directory structure is:

libui/
    readme.md - what is it? build instructions. useful links.
    licence.md
    changes.md - change log
    src/
        libui/
            include/
            common/
            platform/
                osx/
                posix/
                qt5/
                windows/
            gui/
                cocoa/
                gtk/
                qt5/
                win32/
        test/
        examples/
    doc/

Would it make the build scripts more manageable?

I think this depends on how well you define the abstractions and the structure of the project. It's just an engineering problem. Abstractions allow you to hide the complexity behind an API of your choice. The more stuff is mashed up without structure, the more complexity there will be. Perhaps an example of this is how much simpler the cmake config looks when you split it up. The complexity becomes localised and easier to deal with.

It also allows other people to add platforms and GUIs at a later date using your abstraction. In the above model I'd say it is fairly easy to guess where a new platform (e.g. Haiku goes) and where its GUI(s?) will live and which functionality they need to provide.

[andlabs]

Whatever the case, this will not happen until after the next packaged release (likely to be called Alpha 4).