I am about to release a library that provides the API for image manipulation. The library itself doesn’t need Qt, GTK, or anything like that. In short, it lets you load an image from file, modify it in many ways and save it. Or you can create images procedurally. Or apply effects. Or other similar things. Which made me wonder… what exactly is needed to call such a library “native”? I mean, for GUI applications it’s pretty much obvious what’s native and what’s not. But what about libraries, especially the ones that don’t provide/need any GUI?
All you need to build and use said library is GCC, GNU Make, and FreeImage, which is available virtually everywhere. Other than those requirements, which are as minimal as it gets, there is nothing OS-specific. In fact the library itself and example programs using it are built with the exact same Makefiles on Haiku, FreeBSD, and any GNU/Linux distros. The only thing that changes is very minor differences handled by the Makefiles (such as file system structure — basically where “include” and “lib” dirs are located). Working with the library is seamless no matter the OS, so that I often forget what OS I am using. Of course you need an image viewer to see the results of your work, but that’s not part of the library itself so it’s indifferent for what I am talking about here.
Now, the only dependency is FreeImage which, as far I can tell from its recipe, doesn’t require anything. Still, that doesn’t feel like “native” software to me. The way I see it, my library is neither native nor non-native. It’s just “OS agnostic”. But what do I know, I might be wrong here.
I think the answer is quite simple, but besides all of this : it is just my personal opinion. ;-))
This not a native library, but an easily portable one, as it does not use Haiku’s potencial :
it’s features.
As you stated the code had not required or use specialties from Haiku, and minimally differs in case several pathes that ones naturally elsewhere at other - simply I call them POSIX compatible - OSes : like some used source/header files and libraries you use in your development.
I think it’s not problematic at all. If some would find useful your SW, at least they can find it on other OSes they use - as it is quite normal these days for many people.
Thank you both for your answers. So, I guess the library itself is “OS-agnostc” (or “OS-neutral”, if you will). However an application implemented with Haiku API that uses such a library behind the scenes is native, I guess? For example, an application that provides a front-end Haiku GUI so that the user can set options and apply modifications or effects to an image is native, despite the fact the library used for such tasks is not?
Sure. That’s where I think the “native” designation matters to people. For applications with a graphic user interface that isn’t curses or something, we have native applications where the UI is implemented directly in the Interface kit, and we have ports that use foreign graphics libraries. If the native application uses a boatload of libraries that don’t ship with the Haiku release, that’s kind of to be expected; it’s still native.
Software with no graphic user interface (or curses) could be POSIX based.
Software without a GUI can be “native” too, if it uses a native functionality; the command-line app I wrote for controlling Workspaces uses the native messaging API, for example.
Is your library benefit from using Haiku’s inherited strenght that was present since BeOS first released : the multiprocessing ?
Is your library designed to work as object oriented ?
Is your library designed to be multithreaded ?
Does your library support Haiku native communication method ?
And so on … that is important from my perspective to be Haiku native software.
Of course a GUI can be important part of that nativeness, but I would like to know whether all apps developed for Haiku native was designed after the referring GUI proposals/offerings for style and other perspectives in BeBook and/or HaikuBook was followed.
It is not offense from me, I just would like to pinpoint that nativeness can have levels of more directions, and may what in the deep more important at functionality and fitting to available features that already developed earlier.
I admit - sometimes the old stuff should be tailored to the new developments : like it happens with Webpositive and its new engine WebKit2. Soon as Webkit2 added to Web+ the features that can set in Web+ must appear in the browser. For example handling passwords and other security related features (store? where to ?..etc.) which actually there’s no possibility to set at all or as you would like.
As you asked about a program library - specifically differentiated in the title from programs/applications - than it is more important to have the favors above - which not visible but fit/support better to a “native app” in the deep where it will be used primarily.
That’s my opinion about it - first I had not expressed thoroughly … as I thought it speaks for itself what I wrote, as Haiku’s important technical specifics should be known to decide on : native or not.
And yeah, once again it’s no offense from me -
It’s just a clarification what can mean as well : Haiku native – beyond the used GUI library,especially in case a program library released for Haiku* :))*
My library is not that important, it was just the reason I was wondering what exactly is native and what isn’t. However, since you asked, no, it is not object oriented. It could be, but there is no real reason for that. It’s one of those cases where OOP doesn’t really help (on the contrary, it could just complicate things without any benefit.) OOP can make things way better in many cases, but this is not one of them. It is, however, fully module-oriented, which does help in any case.
Initially, parts of the library were multithreaded (using OpenMP, which certainly doesn’t add any Haiku “nativeness” points.) However I quickly realized this wasn’t needed; Image operations are done by modifying a pointer to the pixel data, which makes such changes nearly instant. Well, unless the image itself is huge, I imagine. And I mean really huge.
Good point. Makes perfect sense to me. Also, I’m still learning the Haiku API, and I must admit in the beginning its way of implementing things looked weird to me (for example, you need to subclass a lot.) But as I started using the API in more complex programs, I realized it is very well structured and there is a reason it is implemented that way. So yes, there are levels of “nativeness”; it’s not just the GUI..
I didn’t see any kind of offense. Quite the opposite.
