The role of app developers

1

It seems to me that although some progress is constantly being made, Haiku struggles to attract enough developers to gain some kind of “critical mass”. One reason for this might be that, like many other projects Haiku is underestimating the role of application developers and their needs.

I do develop software, professionally as well as in my free time and I had a look at Haiku multiple times. I occassionally download the newest nightlies and have a look at it but I completely gave up trying to develop for Haiku. This is mainly because there is no decent IDE available, the API is horribly outdated and incomplete when compared to other platforms, and for the lack of good documentation.

Now, I have read stuff like: “it’s open source, you can help out writing documentation or write an IDE or send patches for the OS!”. The thing is, the majority of app developers don’t want to do this kind of stuff. They don’t want to do systems programming, they don’t want to write other people’s documentation and they don’t want to develop tooling. They want to get started in a matter of minutes and implement their own ideas. I don’t care about occasional system crashes, bugs and other glitches. I am aware, that Haiku is alpha quality software. What I need is an IDE with at least good code browsing, refactoring support, code completion, semantic highlighting, API documentation integration, integrated debugger, and a build system that gets out of the way. Apple understood this as well as Google (Android) and Microsoft even called out an app developer competition when they launched Windows Phone, AFAIR. They are successful (more or less) because they attract developers. They have good tooling and APIs that are a pleasure to work with. Be Inc. also understood this to a certain point in time and that’s why they had their (short) moment, when big companies announced ports of successful software.

Why should you care? Users want applications. An OS without applications is useless. Apps need app developers. And app developers want the stuff I mentioned above. More users and more developers in general will in turn attract more people interested in system level programming. Obviously the Haiku developers can not develop an entire operating system and usable apps. So, IMHO, there needs to be a temporary shift of priorities if the project wants to succeed long term. Maybe I can at least stir up some constructive discussion on this topic, we’ll see.

PS: Rereading this, it reads a little ranty. It’s not ment as such, but rather as possitive criticism and a discussion ground. :slight_smile:

2

Well, of course we would all prefer to be working on apps. I personally don’t really need an IDE, I’m happy with Vim. We have some developers working on Pe from time to time, but this has been in development for years and still isn’t anywhere close to a full-blown IDE.

Do you know of any free-time project that managed to build one ? Eclipse is from IBM, NetBeans from Sun (IIRC), and Visual Studio obviously from Microsoft. We’re not going to build something as good in a matter of months, and, by working on it we would uncover bugs and limitations in the system, which we would have to fix anyway, and back to where we are now.

We have a port of llvm/clang in the run. This may help parsing C++ code and build the required info to feed an intelligent IDE.

On the API side, there were some new developments, including the Layout API, the current Service Kit stuff, and some more subtle changes like proper UTF-8 support in BString. I don’t know about the API being outdated, to me it looks quite clean and flexible and I manage to get it to do what I need. Anyway, with the current goal being to replicate BeOS R5, there is not that much time dedicated to building new APIs; this is something we will be doing after R1 gets released (should not take much more years, now).

As for the documentation, the problem is we have the Be Book but we are not allowed to modify it. So our documentation must start by redoing all the work for the classes from the original BeAPI. Writing docs is already a boring task, so when you write doc only because of license restrictions on the existing one, it quickly gets very annoying. This is why our documentation is only making slow progress.

That being said, we have dedicated mailing list and IRC channel for 3rd-party application developers, where we’ll do our best to get them up and running. The Qt port is soon to be released as a package for the new package system, and one way to solve the IDE problem may be to port Qt Creator.

3

It would be great to have qt5 and qt creator, but it seems it wont happen that soon. And yes, the time is better spend in a port of qtcreator, since it’s very popular. The only disadvantage is, that it doesn’t support jamfiles.

4

I think I had Qt Creator working at some point. I’ll look at that once the Qt4 recipe is finished.

As for Qt5, who knoww when that might happen for Haiku… I hope the qt-haiku guys will take a look at it in the upcoming months.

Regards,
arfonzo

5

" the API is horribly outdated and incomplete when compared to other platforms"

Can you give specific examples? Because that’s what people need in order to eventually solve the problem.

6

Have you tried Paladin? It might not be the best IDE, but it’s better than nothing.

7

I think Haiku would win a whole lot more by embracing C# and Mono than by going with Qt.

8

Look at the class libraries of Android, Java, Qt, or Cocoa and you’ll know what I mean. The Interface Kit alone is missing many basic widgets, toolbars and tables, just to name two. Existing ones like BListView and BTextView are a PITA to use. It’s also hard to subclass existing widgets to change some of their behaviour, because painting is done in all kinds of places throughout classes. I know that the developers are aware of (at least some of) these shortcomings, because I’ve also read on the mailing list now and then.

I see that someone is working on HTTP, which is good! But AFAIR the e-mail API is broken since “forever” and it also lacks features. The Media Kit is hardly usable for anything but a simple video player. AFAIK there are no APIs for accessing peripheral devices, like webcams or DVD recorders. (I know these are hard, but writing GUI wrappers around command line tools is not a solution)

Again, this is not meant as a rant and I know developer resources are scarce. But maybe it’s time to rethink focus, at least a bit. APIs don’t need to be perfect in the first throw (which some Haiku developers seem to think), but they need to be easily and publicly consumable and have up to date documentation. Otherwise 99 out of 100 app developers won’t bother and one will quickly give up and instead write lengthy forum posts.

9

In reply to Paladin:

Yes I’ve tried it and it’s basically nothing. Sorry, not trying to be insulting. But all it provides is a build system that I need to add all my files manually to. The two most substantial features (IMHO, obviuously) for sustainable development of non-trivial software are refactoring support and good code navigation. Without that you’re most probably hacking, not developing; or you’re spending a lot of time doing things, that the computer should do for you instead of concentrating on the interesting things. These features need good integration between project management and editor, not standalone tools.

10

I think it could do with both. Want to port Mono?

11

Hello PulkoMandy,

can you tell me, how the documentation must looks like? Perhaps, we guys from the BeSly Team can help you by writing documentation, but we need support for questions and need information about the license restrictions and so on.

Best Regards

Lorglas

12

[quote=foobear]Look at the class libraries of Android, Java, Qt, or Cocoa and you’ll know what I mean. The Interface Kit alone is missing many basic widgets, toolbars and tables, just to name two. Existing ones like BListView and BTextView are a PITA to use. It’s also hard to subclass existing widgets to change some of their behaviour, because painting is done in all kinds of places throughout classes. I know that the developers are aware of (at least some of) these shortcomings, because I’ve also read on the mailing list now and then.
[/quote]

For Haiku R1 our goal is to replicate BeOS R5. Unfortunately, this includes some of the most ugly things in the API such as BOutlineListView. We do have (several) better solutions to some of these. There’s a toolbar in WebPositive, a model-based column list view in Debugger, …

However, these were not turned into public classes yet. The plan was to put them in a lib called libwalter, developped outside Haiku. These new widgets don’t have to be developped as part of the system, app-developpers can also write and share them. Yes, it is as boring to them as it is to us, but someone has to do the work at some point, right ?

I don’t consider the mail API to be anything useful, it’s there just for compatibility. As for webcams, well, these are just media nodes (producers, to be precise) like any others and can be used in apps just like any other. No need for a specific API there. We have a limited set of working devices with our current drivers, and I think the USB support is a bit lacking. As for DVD recorders, well, I’m not sure what you would do with them in the Media Kit ? Not even having any optical drve on my computer, I don’t really care, anyway.

[quote]
Again, this is not meant as a rant and I know developer resources are scarce. But maybe it’s time to rethink focus, at least a bit. APIs don’t need to be perfect in the first throw (which some Haiku developers seem to think), but they need to be easily and publicly consumable and have up to date documentation. Otherwise 99 out of 100 app developers won’t bother and one will quickly give up and instead write lengthy forum posts.[/quote]

We don’t want our APIs to be perfect, but we have to live with the mess Be left for us. This make us developers try to be a bit more future proof and not call an API ‘done’ until we are sure we can keep it working for the 10 following years. Sure, making all these classes public would attract more developpers now, but what if the next nightly changes the API and breaks their apps again ? Angry frustrated devs will leave again. And we can’t reasonably keep 10 different versions of an API to keep all the old apps working.

At this point it’s simpler for everyone to let app developpers provide their own widgets. There is work we should do on that direction still, like making BControlLook a public class to make it much easier for these widgets to blend inthe current OS look and feel (and make everything themable, while we’re at it). There are also some classes that really should be made public like BAboutBox (I import this in all apps I write) and likely some toolbar and column list view. But then again, these could all live in libwalter or elsewhere. Our goal is to design an OS that allows such extensions, instead of going for an universal API.

13

[quote=lorglas]Hello PulkoMandy,

can you tell me, how the documentation must looks like? Perhaps, we guys from the BeSly Team can help you by writing documentation, but we need support for questions and need information about the license restrictions and so on.

Best Regards

Lorglas[/quote]

What we have written is available here: http://api.haiku-os.org

The sources used to generate this: http://cgit.haiku-os.org/haiku/tree/docs/user

There is a HOWTO file in the source tree linked above, and some extra info here: http://api.haiku-os.org/apidoc.html

14

Don’t underestimate my awesomeness :stuck_out_tongue:

MJZSDcr.jpg1920×1080 401 KB

15

Plan was or plan is? How can we access these widgets now?

I remember seeing a bunch of warnings about using IMAP with haiku and so have never set up my email under haiku, I just use webmail instead. Is there a mail app that works? It would be nice if that stuff was handled by the OS instead of every email app having to implement it themselves… why is that not useful?

Don’t underestimate my awesomeness :stuck_out_tongue:

http://i.imgur.com/MJZSDcr.png[/quote]

This is awesome, package please?

As to mono or qt, no mono please. Mono is slow. We already have one extra toolkit (qt) why add more disparate APIs? One of the things that is really nice in haiku is that is has a unified API rather than a bunch of different stuff melded together from different people, sure qt gives some extra apps for now, that’s great since we’re short on them, but no more toolkits please!

One thing that kind of annoys me with haiku is that cool projects get done and then never integrated with everything else. There are loads of gsoc projects that sort of disappeared… where are the virtualbox extensions, what happened to the JVM (this was in the old haikuports but didn’t work last time I tried it), etc etc. This seems to apply to the widgets stuff too. At some point is it not time to just say, ok it’s not 100% ready but lets make it available for people so they can try it without looking up a blog post, downloading a tarball hanging off of someones website and following a 2 year old guide that is somewhat broken (e.g. I have to do this every time I install latex). Even if its not in the default image having easy access to some of the more experimental stuff would be really good.

16

[quote=Munchausen][quote=PulkoMandy]
I remember seeing a bunch of warnings about using IMAP with haiku and so have never set up my email under haiku, I just use webmail instead. Is there a mail app that works? It would be nice if that stuff was handled by the OS instead of every email app having to implement it themselves… why is that not useful?[/quote]

IMAP is a fine example of a network application protocol that shouldn’t be the operating system’s problem. It’s rather complex and full of stuff that only some people, or applications, care about. Unfortunately that means that implementation is often poor, but tying it to the OS doesn’t make it any less likely to be poor, it just makes the problem worse because that poor implementation will be around for the lifetime of the OS.

All the applications really need is a good library - too bad that rarely works out for protocols like IMAP and HTTP, but if it were somehow possible, it could be useful on a variety of platforms, not just Haiku.

17

I successfully set up my Gmail account using “BeAM” via IMAP.

18

[quote=donn]
IMAP is a fine example of a network application protocol that shouldn’t be the operating system’s problem. It’s rather complex and full of stuff that only some people, or applications, care about. Unfortunately that means that implementation is often poor, but tying it to the OS doesn’t make it any less likely to be poor, it just makes the problem worse because that poor implementation will be around for the lifetime of the OS.

All the applications really need is a good library - too bad that rarely works out for protocols like IMAP and HTTP, but if it were somehow possible, it could be useful on a variety of platforms, not just Haiku.[/quote]

But wouldn’t it be nice if the OS provided that library and did it well? The fact that you don’t need an extra library and there is a single unified API to do stuff in haiku is a big plus. Otherwise you end up with the linux situation, where libraries are constantly deprecated and replaced instead of improving them beyond their limitations. Just look at audio (OSS, ALSA, Pulse…) or dev node handling (simple nodes and config files, devfs, udev…) - there’s always a fancy new way to do stuff on linux and it gets tiring to keep up with the constant changes. There’s always the issue of backwards compatibility, but I thought the haiku philosophy was do it once and do it right!?

19

Don’t underestimate my awesomeness :stuck_out_tongue:

http://i.imgur.com/MJZSDcr.png[/quote]

+1

you are the master of photoshop :slight_smile:

I’m kidding, it’s great to see it running on haiku. BUT it does crash… regulary?

20

Where “it” refers to the operating system. Time spent on perfecting IMAP support would be wasted in the long run. It isn’t platform dependent in any way, it’s the kind of thing where we just stock up on the standard open source support libraries. If there isn’t a good open source support library for IMAP, there should be, and the core developers for the world’s smallest OS probably aren’t the place to look for that. (I’m familiar with cclient, by the way.)