Feasibility of using a high level API

[Firestryke31]

I've been thinking into the future for my OS, specifically with the GUI, and I was wondering how feasible it was to use a somewhat high level API like, say, wxWidgets natively. Doing so with wxWidgets would fit the object-oriented design of my OS as well as give me an idea as to what I need and how it should behave. Plus, existing wxWidgets based programs would be that much easier to port. If it is feasible for wxWidgets, how about other existing open source APIs?

Discuss!

[bewing]

If you use it natively, that makes it low-level.
All you need to do is make sure that it is flexible enough to be able to handle all imaginable programming tasks.
Because of that, and because wxWidgets is a pretty small subset of Win32 or GTK, I would think that Win32 or GTK (or qt, or carbon/cocoa) would be better starting points.

[paxcoder]

I say: go for it. I've been thinking of the same thing myself, Implementing wxWidgets natively, thus making user-space programs "completely" cross platform, and perhaps popularizing the thing, attracting even more developers. The upside is also the base of the already made progs (eg. VLC). But then, I don't know much about it, and GTK.
However, the down side is the "standard" itself, you are restrained by it (and its future specs perhaps), but then, that's the downside of using GTK as well. In any case, it's your call.

[Firestryke31]

I was just thinking wxWidgets because it was written in C++ for C++, and is already cross platform. Plus it being a small subset of another API would mean less work for me.

By using defined APIs I will have concrete goals to shoot for, plus I'll increase portability of programs.

I'll use wxWidgets for the GUI, File system stuff can just use the STL and Boost, which can also be used for all kinds of other stuff. What else should I use?

[paxcoder]

Plus it being a small subset of another API would mean less work for me.

Actually, it adheres to the platform, so it does support GUI-specific stuff, but yeah, you're better off just doing the basics at first, later on, if you really want to, you can implement the specific stuff, so that all variations can work on your OS (although, to be frank if someone was to use for eg. MacOS specific feature, he'll probably write MacOS specific code too... if there is such a thing)

[jal]

I was just thinking wxWidgets because it was written in C++ for C++, and is already cross platform.

wxWidgets is basically an API-converter. You can use it's API natively of course, but all the implementation will still have to be yours.


JAL

[jal]

I would think that Win32 or GTK (or qt, or carbon/cocoa) would be better starting points.

I would think that Win32 is about the worst starting point for a GUI API. Cocoa would be better, but it's still rather large. Personally, I wouldn't look at anyone's GUI, and make up my own, but if you wanna go WIMP, there's enough examples to go by.


JAL

[Firestryke31]

I was just thinking wxWidgets because it was written in C++ for C++, and is already cross platform.

wxWidgets is basically an API-converter. You can use it's API natively of course, but all the implementation will still have to be yours.


JAL

Well, since I'm writing my own operating system, the windowing system will have to be mine anyway, so why not bypass a translation layer and use the wxWidgets API natively. Same with the STL, Boost stuff, etc.

Of course, it would probably be a good idea to support the regular C library too for things like libPNG and whatnot, which I'll probably use at some point.