Submitted by And now we’re ready to start picking the fruits of Qt being available on Haiku. We reported on the completion of the Qt port to Haiku on January 1, 2010, and now we already have KOffice running on the open source recreation of the BeOS. A modern office suite for Haiku!
In total, the TiltOS for Haiku project has ported over 150 packages to Haiku, all thanks to the Qt port: kchmviewer, kdeaccessibility, kdeadmin, kdebase, kdeedu, kdegames, kdegraphics, kdelibs, kdelibs-experimental, kdemultimedia, kdenetwork, kdepim, kdepimlibs, kdepim-runtime, kdesdk, kdetoys, kdeutils, kdevplatform, kdewebdev, kdiff3, koffice and many others. That’s quite the list.
For these packages to work, you need either the GCC4 or GCC2-hybrid Haiku build. You need to install the TiltOS for Haiku package, and then you can use the box utility to install packages using the command line. Most of the ported applications are relatively stable, but there’s no guarantee, of course.
More details, and screenshots, are available at the TiltOS website.
Wow, man Haiku-OS is getting a lot of traction – it is amazing how many of these are cropping up over the last couple of months. I wonder by the same time next year we’ll be discussing whether Haiku-OS will finally bring an open source operating system to the mainstream where others have failed
I’m sure there are lots of people who would have preferred OpenOffice.org to be ported but having used KOffice instead of OpenOffice.org when running FreeBSD – it is the right move to make. Although it isn’t as massively feature rich, for the vast majority of end users out there I am sure it will be more than adequate for what is required.
I hope that they aim for full POSIX and UNIX 2003 compliance so that porting to Haiku-OS will be easier – I remember years ago to port Mozilla to BeOS was a horrible job due to features lacking in BeOS – has that since been addressed or has Mozilla been changed so it is no longer dependent on that absent feature?
Once again, congratulations to the developers – keep up the hard work, hopefully by this time next year Haiku-OS will be a viable operating system to be run full time on a future laptop – with Intel wireless working and all
Haiku’s POSIX support is considerably better than that of BeOS (and generally improving all the time). The major hurdles with respect to newer Mozilla/Firefox versions are the dependency on Cairo and a few other things that would need to be ported, which is why Haiku’s current unofficial FF build is still a 2.x version.
Hopefully when it stabilises it will become easier to port applications to Haiku-OS but with that being said it still needs more hardware support. With the improving software availability and head lines it’ll get the necessary developers involved to improve the hardware support although it will be limited to *BSD sources. Is there any talk about bringing more FreeBSD driver API’s across? it would definitely help in that area.
That’s somewhat less than trivial for other classes of drivers. Network drivers are fairly easy to do a glue layer around since they don’t do much more other than read, write and link state. Things like modern graphics drivers are orders of magnitude more complex and because of that the architecture of them is somewhat tied to the underlying architecture of whatever display server’s involved. That’s to say nothing of the problem of having devs with access to the necessary hardware (and enough driver-writing/debugging knowledge), since there are going to be various quirks to deal with due to OS architecture differences regardless. So at least at this point that’s somewhat up in the air.
This is what happened when they tried to port OpenOffice to Zeta. http://camendesign.com/writing/geos/dependencies.jpg
Yeah. That one is a true modern classic, and even now I want to utter a “WTF!?”
The problem wasn’t so much lacking features on BeOS, but Mozilla’s internal code structure.
There was one big problem that was in BeOS though, the fact that the addon-memory (where you loaded libs dynamically) was limited to 32MB. (It was solved by someone by creating stub-libs that needed the real libs and only loading the stubs.)
Haiku don’t have these problems, and have much better posix support.
I have been running a recent nightly build of Haiku about 60% of the time on my Aspire One netbook. It has wifi, sound, network, acceleration, etc., all working nicely. The few areas that could be improved are in applications, and online streaming media.
I was looking for a good office suite – I bought the download version of Gobe Productive years ago but can’t find where to get it now. KOffice, while not my first choice in Linux, answers that issue.
The next is a good multiprotocol IM client. I still don’t have that resolved other than to use Meebo online. The third is that streaming media from the internet should work better. It has been pretty hit and miss as to the sites I can use. Otherwise, I am pretty happy with this OS and find it a very high performance solution for netbooks.
I am looking forward to trying TiltOS with KOffice.
Thank you.
Here’s where you can buy it for $19.95:
http://store.purplus.net/gopr20forbe.html
After installing all the necessary ported dependencies, how big is the disk footprint for this?
Also, if someone has time, I’d like to see some basic memory-utilization metrics, and CPU utilization while using KDE apps…
While I believe having the option to port Qt and KDE apps to Haiku is pretty nice, and a useful temporary solution, I have to wonder how many advantages gained by using Haiku are once again diminished after choosing this path.
For example, Haiku has a lot of potential on resource-limited hardware in the future – especially in the low-powered device space. I absolutely love running Haiku on my Acer Aspire One because it is highly responsive and “lightweight” feeling.
Exactly the sort of details a BeOS or Amiga use would be paying attention to!
This is the most important question of them all. I agree, this is a nice tie me over, but nothing beats a native app that was written from the ground up with multi-threading and low resource use in mind.
Thankfully I still have a full copy of Gobe Productive, but I’ll probably install this just to see how it runs.
Keep up the good work, the OS needs quick and dirty ports until it gets on it’s feet…
…again.
I still have my SoundPlay license. Best music app ever. I also still have Gobe Productive. Atho’ a Haiku user I converse with from time to time said you cannot do a direct install of Productive for some reason. That might be old news and I could be wrong.
Agreed, using it right now to listen to Django Rheinhardt. I’ve found that the iPod Touch makes a nice little SoundPlay remote via wifi & the BeInYourStereo HTTP interface. And I finally found an iPod app that can receive live encoder streams (FStream), making it a convenient way to stream audio to a stereo on a different floor.
I suspect he/she means that the install application doesn’t work, but that it will work if you install it in BeOS and just copy the files over.
Yes, that is it exactly! Sorry. Should have worded it better.
My bad too – I wasn’t very clear in my post, by “he” I was referring to the Haiku user who you mentioned you correspond with. I had thought that you were repeating his description of the problem and weren’t sure what he meant.
Slightly OT, but if you enjoy listening to Django, you might want to check out Biréli Lagrène and Stochelo Rosenberg, two great contemporary gypsy jazz guitarists. Lost of material available on the tubes.
Thanks, I’ll have to look both of them up.
I haven’t tested this, but I’d like to point out that KOffice is being adapted (professionally) for the Maemo platform, so keeping the footprint down is a priority for KOffice and the KDE platform. First results are an MS Office doc viewer: http://www.kdedevelopers.org/node/4143 .
That’s good to hear – I hope someone will adapt it to Haiku’s native widget system…
These images make it look somewhat alien running on Haiku:
http://files.tiltos.com/website/kde/haiku-koffice-kword.png
http://files.tiltos.com/website/kde/haiku-koffice-kpresenter.png
A truly integrated port would be neat…
FWIW, I even see some potential answers to my questions here..
100% cpu utilization while KOffice is running? (unless the act of taking a screenshot caused that spike)..
Maybe somewhere between 50-100mb memory utilization to use KWord or KPresenter (Haiku with 512mb RAM consumes ~80mb by default after startup, some of which I assume is just file cache).
I’m still curious about the disk footprint.
IIRC the screenshot app usually use all the cpu while taking the screenshot.
I admit I haven’t tried Haiku but I keep hearing great thing and now Qt and KOffice have been ported.
Maybe Haiku will soon become a viable open-source desktop OS. As of now, it appears only Unix-like FOSS operating systems are viable to advanced users. I like *nix but obviously not everyone cares for the ageing Unix methodology and the un-unified and fragmented nature of distributions.
It is just a matter of time for me to switch!!!!
-2501
Qt is the best open source library being maintained and developed.
Qt is LGPL, free, a new release per 6 months…
Nokia now develop Qt faster.
Qt is being accelerated and optimized…
Huge quantity of Apps use Qt (KDE, …)
So for a system that doesn’t have apps (I mean today’s apps), the best way to fellow is to port Qt and use all the written apps.
I wonder applications are more responsive in Haiku.
In Linux, KDE is less responsive than Gnome, and the two are less responsive than some other systems.
Qt port to haiku should use many of the threads benefits and should make apps more responsive.
Errr, I think you are very much out of date with that observation.
KDE is faster and snappier than GNOME, and with every iteration of Qt and kdelibs, it gets even faster.
Thats great news, but that also makes me kinda worried.
Haiku team, PLEASE, keep things simple. One of the great things in haiku is that there is not 200 different ways to do the same thing. Like in linux, where we have 1000 different window managers, libs, etc. I’m not saying its a bad thing (I’m a linux and open solaris user) but if Haiku wants to hit the end user, I think it’s really important to keep it simple.
Porting QT might be a good thing, but then, we have two graphic libs. This should be agnostic to the end user, the UI must be consistent so that the end user can’t see the difference.
Also, I don’t like the idea of TiltOS. Is this a fork or what? Do you guys plan to merge with haiku? Haiku is not even finished and there is already a fork?..
What I’m trying to say is I really like Haiku, but I think they might be moving too close to a linux-like OS, and in these case, they will have no chance to survive. So, in my opinion, they should keep things simple. For instance, installing k-office should be as easy as installing any other system. Sure, they just released it, it’s not finished, so it’s ok to be a little hacky to install it, but I really hope they are working hard to integrate things.
And if they are moving to a package system (box) then everything should be there, and not only qt ported things.
Keep in mind I’m just saying this things because I really care about this project! Haiku is a great OS.
Here’s the thing, stanbr:
The porting of Qt to Haiku is a sufficient testament to the Haiku developers (of the OS, not separate apps) keeping things simple: any added complexity this brings is much like that of saying Microsoft Office complicates Windows by installing it, because it isn’t tied to the OS, and is a separate application and operating environment unto itself. Yes, I mean that in reference to Microsoft Office, which is actually far more powerful of a development environment (overall) than what I learned on in the 80’s on the Apple 2, because of a more advanced, complete BASIC along with the ability to call out to lower-level stuff of the OS for many things, along with being an office suite at the same time. A true testament to the complexity and power of Microsoft Office is, of course, somewhat dubious in the results: it had its power proven many years ago by the creation of cross-platform macro viruses :p
Qt is NOT a part of Haiku, and (I’m making an educated guess on this) will never be supported as part of any official base distro by Haiku, Inc. though there will be no effort to stop it from being shipped by third-party distro makers, if desired: isn’t that what users really want, to be able to get what they want, as they want, without being unduly restricted?
actually QT integration has been talked about on the mailing list…. probably as a feature for R2 or at least a large improvment of the current API (better layout handleing reduce hard coded sizes & positions etc…)
However, the context of that discussion was to provide a Qt API alongside the BeAPI for native apps to use – making it easier to write/port apps from Qt to native Haiku apps.
Currently, the Qt port for Haiku uses Qt widgets rather than native widgets, making it a “kludge” compared to what was discussed on the mailing list. In short: The current Qt port is *not* what was discussed on the mailing list, but it could be used as a first-step.
quite right I should have been more clear about that.
the Idea would have been that QT would have become part of the native widgets…. or that the native wigets would be extended duplicating a lot of things that QT already does whether or not that is a bad thing I don’t know
I think it is arguable that the using QT would be good for haiku similar to better wine integration in reactos but direct control over the direction the toolkit takes would be lost and that would be a big loss…. and a giant setback if QT becomes more bloated or somehow worse off…
I wouldn’t worry too much, then – one of the main characteristics that most BeOS/Haiku fans, users, developers, etc, share is an almost-obsessive commitment to minimalism (and I mean that in a good way).
things, can’t be always simple, and they also should not be simple. But I agree that the result must “look” simple. E.g., to hide the complexity.
Qt4 is not yet fully ported, but it already feels quite responsive, perhaps even more responsive than on linux. I tried the latest Arora browser on Haiku and it impressed my how hast and how good it already works. I think that it could be worth, to include qt in the haiku-base and to have Arora pre-installed, just because it works so nicely.
And I really hope, that LyX (www.lyx.org) will also be ported to haiku, and also QtOctave (octave already runs on haiku, so I think qtoctave could be ported with not too much pain).
many thanks to the devs that ported qt4 to haiku.
Looks like you haven’t used or saw a pure QT app before. QT adapts to its host OS, so when you for example, you run a QT app on Windows Vista, it has the Vista look in its controls, the same when running on Mac and Linux (under KDE).
Does it emulate the look, or actually use the native widgets?
I have seen it common to “fake” the look of cross-platform widgets for the platforms they are running on, but this is still not acceptable IMO. Firefox tries to do this and it’s often obnoxious when you run into differences in behavior that you didn’t expect as a result.
The Qt port for Haiku currently uses its own widgets, not the ones provided by Haiku.
I believe it emulates the look. I believe that most Qt widgets render themselves to a QCanvas (Qt’s abstract canvas) rather than using a native widget to draw themselves. So, a QPushButton won’t create a native Be button widget in a native Be window, but rather will render a theme-and-platform-appropriate image of a push-button to a QCanvas, whose contents will eventually get drawn in a window.
Well, normally. I think there’s also some facility to provide an alternate rendering engine, that does use native widgets: I think that’s what the GTK emulation theme does.
This is very good news. You might wonder what the difference is between linux and Haiku if Haiku ends up running a significant number of KDE/Qt apps, but I’d argue that having a desktop centric OS and a single target for developers (not multiple distros) will go a long way to creating a better experience for everyone. Touch wood, Haiku will grow up to be a serious player in the desktop space and the community will resist the urge to fork it. I’ve just started playing with it under VirtualBox (btw, you need the latest VirtualBox to make it run).
I use Haiku on one of my EeePCs at the moment and have used it for quite a while now.
There are some things Haiku is doing right. For once it is incredibly fast which feels so refreshing and is the main reason I use it.
There are however a few things I dislike. Not counting the bugs I have run into there are some features I would feel is missing. I’m not sure if they have been addressed since ALPHA-1 or not.
1, There is no official repository. I hate having to download stuff and manually install. It is so unsexy in this day and age.
2, The wifi is somewhat limited that it doesnt support encryption. Perhaps it has been addressed by now I’m not sure.
3, I wish they would support different window managers so I can pick one I like. I know they are aiming for the desktop market but I see no reason for a lock-in? Different people have different needs. Even desktop users.
– There is no official repository.
– I wish they would support different window managers so I can pick one I like
Then http://www.linux.com is what you want.
Keep Haiku-OS away from it please.
Edited 2010-01-19 11:08 UTC
You are probably right. But why would a repository be such a bad thing for Haiku?
In my opinion it adds too much complexity. An official website with “safe” software would be way better.
Edited 2010-01-19 13:07 UTC
haikuware.com kinda already does that.
I definitely prefer the old BeBits method of distributing additional software. Sorted and organized with descriptions, screenshots, user reviews…
The Windows comparable would be NoNags or similar.
Either of these is much better than the Linux suppository (repository) system, which are often little more than directory listings.
again: bebits are gone forever
haikuware.com is the main app repository now
I understand, just wanted to emphasize why Haiku should not use a Linux-like repository system.
I’ve been browsing Haikuware and think it’s just about right. Having the screenshots displayed alongside the description is a nice improvement over the old BeBits site, in which you had to follow a link to the image.
With a decent description, user reviews or ratings, and available screenshot I can almost always select suitable programs without having to install and run them firsthand.
—————
I also appreciate the ability to download the software applications as stand-alone files instead of having the OS automatically download and install. That way I can install/uninstall at my leisure, save the files to CD, and use on computers that don’t have internet access.
Edited 2010-01-19 18:08 UTC
I don’t really see package management/repositories being necessary on Haiku. Those tools generally exist to simplify processes that would be annoyingly-complex otherwise – but application installation on Haiku is already just about as simple as it could possibly be (download archive, extract files, double-click the binary, and away you go).
Wifi support is still a work-in-progress.
There is no lock-in. The source code is available, and the OS is quite modular – I can’t think of anything that would prevent someone from writing a replacement for the app_server.
but application installation on Haiku is already just about as simple as it could possibly be (download archive, extract files, double-click the binary, and away you go).
That shows you:
a) Have no idea what you write about
b) Have never used an installation process that’s really simple
For example, on Linux, you just select the application from a list. Much easier.
On an IPhone or similar “app store” solutions, you just select the application from a list. Much easier.
The Haiku “solution” is stright out of the 90s, old, dull, boring, and full of makework. Haiku/BeOS fanboys are always so defensive!
And you base those conclusions on…? Or are you just pulling random tactics out of the Guide to Conversational Terrorism ( http://www.vandruff.com/art_converse.html )?
So, to you, extracting an archive and drag-and-dropping a file is some sort of insurmountable hardship?
Sure, if you just blindly assume that the package management system will always work 100% correctly and your needs/understanding is sufficiently limited that you never have to get under the hood.
“Old, dull, buring” – congratulations, those are just about the least-useful terms you could possibly use to describe a software installation process. But it does make it clear that your only real objection is that Haiku software installation isn’t “fashionable” enough for you.
Yes, because your infantile “if you hold a different opinion than me, you must be ignorant” attitude doesn’t make you see defensive. Not a all. Really. Trust me, I’m not being sarcastic. In the least.
Well, if womeone started telling me using clogs for running is better than shoes, there are only so many explanations.
I don’t say it’s BAD, I say it’s WORSE.
Doesn’t seem to be hurting the iphone users. They are, last I checked, about a bazillion% more of them than Haiku users. Why not learn from what’s out there, and works?
[/q]
Well, since computers are supposed to not waste our time, avoiding boring makework processes is a big plus.
[/q]
Dude, this is the 21st century. Look around. Avoid the 3d sharks.
Haiku is a very good and rock solid OS. It’s improving well and fast and it is a posix compliant OS.
But remember that Haiku is enjoying the fruits of the fsf, opensource and linux in particular.
They can build a polished and well written OS because they are working in a world where a lot of infos, tech specs and hardware manufacturers support are available.
An example? Think about qt for example. They have a very mature qt ( linux had a bad qt that needed to evolve through years ).
Or think about graphics driver support. The Haiku team stated they won’t implement dri/dri2 and linux driver, they’ll wait for gallium. And they’ll have a lot of open drivers/spec to develop/port drivers for Haiku.
Linux has gone through a lot of troubles to convince the hardware manufacturers to make specs public.
So Haiku is good, but it is here at the right time in the right world.
There isn’t much to argue abouth there. I would say alot of projects have much to thank for – not only to Linux but all other open source projects in the world. Many project piggy-ride on eachother. Thats the point =)
Funny that you mention FSF and Linux in particular, while the BSDs get no mention even though AFAIR the core Haiku (kernel, etc.) is MIT/BSD only (thank god) and most of the drivers/stacks come from the BSDs.
I would agree with that statement if it were amended to “They can build a polished and well written OS for free because…”
Be Inc. was able to build a largely identical OS without using many open source components, but they also had to pay significant sums of money to license things like the bitstream font rendering engine.
When it was reported that Qt4 was successfully ported I predicted that it won’t take long for a load of Qt apps to get ported over and I was right
( http://www.osnews.com/permalink?402000 )
I am really glad to see Haiku starting to get traction now, broader selection of applications and whatnot. Kudos to all developers! Now I am starting to get tempted to try it myself, just gotta install one or another VM… *starts googling*
Using Haiku simply because it has ported apps from Qt and KDE is sad… I understand that those actually provide *useful* apps for Haiku, but they are not the reason to use Haiku.
As another example, which is often pointed out by Jorge Mare during conferences we attend, ported apps cannot use the awesome features of Haiku. They will not make use of the fantastic attribute/query support of BFS, they will not make use of the media kit or translation kit, they will not visually match the rest of the OS, nor will they behave like native Haiku apps.
By promoting ported software as the reason to use Haiku, you’re basically destroying much of what Haiku is and strives to be.
I disagree. Haiku reached a lot of people with Alpha1 release. So, what’s software is available? goBe? FireFox 2 (very bloated)? Instead, until Haiku gets Release status, It’s a smart solution using QtApps (Arora+KOffice). Because nobody is developing a Office app and for Webkit shows anything usable will took ages.
So, I’m confused – you use Haiku just because it has ported apps? Why not use Linux instead? Linux already has every app that has been ported to Haiku, AFAIK. Linux is available on a broader range of hardware. Linux is improving in performance every day… on many things, it’s much faster than Haiku already.
I’ll tell you why I don’t like Linux, because the applications for Linux are often bloated, horribly disjointed, and inconsistent. They often have so many dependencies, it’s mind-boggling. There are many libraries and subsystems that provide the same functionality, and different apps use different selections of these. After a while, you get tired of knowing your disk and memory full of this crap, wasting CPU resources to load and manage it all.
It’s funny because is the same reason that I don’t give any chance for Linuxes. But Qt is acceptable in my point of view.
Let me be clear – I think porting apps to Haiku as a *temporary* solution is a good idea, I just feel like doing so puts Haiku in the exact same position as Linux – no consistency, no identity of its own, no applications that make use of Haiku-specific features, etc.
You even mentioned Firefox earlier, and I *hate* Firefox now. I would love to have a native Haiku browser that used Haiku widgets, behaved like other native Haiku applications, and made use of Haiku’s image translators, and eventually the media kit for upcoming HTML5 video support.
One word: NetOptimist
I agree that using Haiku just because of ported software would be a bad idea…
However, some of us who love Haiku haven’t been able to start REALLY using it as our day-to-day system because of the lack of software.
Office software and wifi support are the two biggest things in my way. A working KOffice port, while not ideal, will do the job. That leaves me with only wifi support as a big stumbling block (and it’s being worked on, I know!). It’s almost to the point that I can become a real user, instead of just somebody who donates some money and watches with interest.
It’s very much like when I switched to Mac OS X. I still needed VirtualPC (at the time) to run Windows apps, and many apps ran in Classic mode…but these two tools (VPC and Classic) let me use the OS despite a lack of software, and I switched to native software bit-by-bit as it became available. Without VPC and/or Classic mode, I probably wouldn’t have made the plunge into Mac OS X.
I could see myself doing the same in Haiku… using a lot of qt4 apps initially, then switching to native apps one-by-one as the become available. And qt4 apps already seem to fit in better with the system than Classic apps did in the early Mac OS X days ;-).
You may find that Qt and KDE apps aren’t as rigid and alien as you think. Since they are not rigidly tied to Linux as the Be APIs are to BeOS, they have always been something of a changeling
.
The Nepomuk semantic desktop project is an interface to attribute/query systems, and could be given a backend which leverages BFS, the Media Kit could be provided to Qt apps via a Phonon backend, and it would be feasible to write a QInterfaceKitStyle that renders Qt UIs using the nativ widgets, as QGtkStyle does. I don’t know enough about the translation kit to comment, but I would expect that KFilePlugins provide equivalent functionality.
Things that would be harder to blend in would be BeOS native UI idioms: menu structures; linguistic conventions, and UI layouts. But interbreeding is generally healthy for a species.
(edited typo)
Edited 2010-01-19 19:24 UTC
Those are all excellent examples of “good porting” practices. If Qt has proper abstractions to allow usage of the native functionality present on the host OS, then I think a proper port of Qt to Haiku would use as much of that functionality as possible. This would reduce dependencies on duplicate libraries and subsystems, and reduce memory and disk consumption while Qt apps are running.
However, I think you’ll find that the existing state of these ports are… not doing this.
A pity I can’t mod your post up.
Using Haiku simply because it has ported apps from Qt and KDE is sad… I understand that those actually provide *useful* apps for Haiku, but they are not the reason to use Haiku.
I don’t quite think anyone would use Haiku for KDE and its apps per se, one would rather use Haiku because now it’s possible to actually do more useful day-to-day work with it. Just because ported apps happen to fulfill a need. That’s the whole point here; Haiku is lacking so much software at the moment that getting even ported apps will make a large impact on its userbase.
As another example, which is often pointed out by Jorge Mare during conferences we attend, ported apps cannot use the awesome features of Haiku. They will not make use of the fantastic attribute/query support of BFS, they will not make use of the media kit or translation kit, they will not visually match the rest of the OS, nor will they behave like native Haiku apps.
As someone already pointed out, all those features are already possible in KDE4,, it’s just a matter of porting the appropriate functionality to use BeOS/Haiku ones. Of course, it adds one (or several?) extra layer and such wholly native apps would be preferable. But again, as long as ported ones supply you with all the functionality you need then it’s still better than nothing.
By promoting ported software as the reason to use Haiku, you’re basically destroying much of what Haiku is and strives to be.
I am not promoting Haiku per se. Not for its native apps, nor for the ported apps. Besides, I don’t quite believe Haiku strives to be free of all ported software and always lack applications. Nah, you should just be glad those exist. I do personally believe that it’ll attract more people to Haiku, and those people will eventually either try to improve those ported apps even further, or use them as a base and create wholly native ones. It is only a personal opinion, but I can’t really see anything negative about it.
Hmm, I guess I read your opinion as: “Now that Haiku has all these apps, I’ll finally give it a try!”… as if those applications will somehow define the appropriate Haiku experience.
I only wanted to point out that trying Haiku for the sake of using KOffice on a non-Linux platform is… going to be a disappointing introduction to Haiku.
I would say it is more like reaching an acceptable level of proformace to some users
Though haiku seeks an optimal desktop experience and QT probably doesn’t quite achieve that… the BeAPI probably doesn’t at the moment either due to its lacking areas but it is more integrated into BeOS/haiku design ideas and as such is better in a lot of way
True… although is there anything fundamentally preventing someone from writing native Haiku apps that use Qt for the GUI? IIRC, there was some talk of using that approach to get updated version of VLC and Handbrake working on Haiku.
Edited 2010-01-19 20:56 UTC
As a long time Koffice supporter/user I am glad to hear it.
Does someone knows if (since Qt 4.6 is already ported and working in Maemo) KOffice, amarok, krusader and such KDE applications would be hard to port to Maemo platform too?
Does anyone know if QtCreator is fully able to run under Haiku and compile the various Qt apps?
Wow Haiku got a lot more usable now. Maybe they can port a VLC version to Haiku that uses QT now?
http://www.videolan.org/vlc/ Syllable is even listed but no entries for Haiku nor BeOS, just sad.
Edited 2010-01-20 16:06 UTC
There are a lot of posts here pimping for this feature or that feature for Haiku OS – we are all fond of our opinions – but has anyone installed this? Anyone get it working? If so, what build of HaikuOS were you using? The GCC4 build, or the Hybrid? Are the apps responsive?
I have tried to install it but get an error message from ‘box’.
Thank you.
Well, I got Koffice installed. The problem was apparently the network stack, which under heavy load wants to reset my IP address. I only ran Kword, but it does work, and once loaded seems fairly responsive. It did take a little while to load, some icons are missing, and it opens a bit big for my Aspire One netbook screen.
I had to remove a couple palettes from the toolbox on the right to get the window to allow me to resize it. I typed a couple words and saved them to odf format. It seemed to work OK, though I have not opened the doc in any other application and have not tried to insert an image, table, or use any other advanced features. I noticed that not all of the Koffice applications are ported. Curiously missing is Kspread. Kpresenter is there, but I have not tried it yet.
I would really like to see a NATIVE office suite on Haiku/BeOS, but this fills the gap nicely for now. Any chance of Gobe releasing the BeOS version of Productive as open source? I am sure the code base for Windows is significantly different.
If I could get a NATIVE reliable multi-protocol IM client, and NATIVE webkit-based browser with gnash/flash and HTML5 video support, I would be very happy indeed. Other than that and the slightly flaky network stack, Haiku-OS is shaping up to be a very nice operating system.