KOffice Ported to Haiku!
Sunday, 17 January 2010 17:31
Thanks in a large part to the QT porting team, Kaliber informs us that many KDE applications and KOffice are immediately available to Haiku OS users (GCC4 or GCC2 Hybrid) using the Box application in TiltOS... Additionaly, these have been ported: kchmviewer, kdeaccessibility, kdeadmin, kdebase, kdeedu, kdegames, kdegraphics, kdelibs, kdelibs-experimental, kdemultimedia, kdenetwork, kdepim, kdepimlibs, kdepim-runtime, kdesdk, kdetoys, kdeutils, kdevplatform, kdewebdev, kdiff3, and many more.
Follow these instructions to install.
Top Downloads in 90 Days
ICH AC97 Driver
Arora
Gnash 0.8.7
BeOS R5 Sample Code
Programming the Be Operating System
Synthetic Package Manager
SDLGameLibraries GCC4
KOffice for Haiku - Stand Alone Installer
BeOS 5 PE Max EditionLatest Hardware
Search Files
Newest Files
Mar 12 |
ColorBalls |
| Mar 11 |
QuickLaunch |
| Mar 11 |
QuickLaunch(gcc2) |
| Mar 9 |
libuninstring |
| Mar 8 |
HaikuTwitter Alpha1 (rev. 63) |
| Mar 8 |
BeDock-Haiku |
| Mar 7 |
Boids Screensaver |
| Mar 7 |
smodels-2.33.zip |
| Mar 7 |
clasp-1.3.2.zip |
| Mar 7 |
lparse-1.1.1.zip |
| Mar 5 |
Jagged Alliance 2 - Stracciatella |
| Mar 1 |
SimCar |
| Feb 28 |
hosters |
| Feb 28 |
Jooleem |
| Feb 27 |
bynaryo |
| Feb 27 |
exestringz |
| Feb 25 |
Smash Battle |
| Feb 24 |
Free Heroes of Might and Magic II |
| Feb 21 |
Qt-App Installer - gcc2/gcc4 |
| Feb 16 |
Xerces C++ 3.1.0 |
Comments
K3b is not a part of KDE. It's developed outside KDE as I know. I h, but seems K3b uses some low level API to access SCSI and there is only linux implementation for now.
If you want, you can create a fat package (zip) with all dependencies or convert every box package to a zip format and post it to the haikuware. But remember that KOffice has many dependencies (42)! You cannot say to the user: please download and install all dependencies first. Both solutions are wrong in my opinion. Propose a better and user friendly packaging.
Why not, i could add it into Synthetic Package Manager, then
+1 ;)
Also, I tried installing KOffice as per instructions. When attempting to install, you get an error: 'Missing dependencies for KOffice: soname /boot/common/lib/libz.so
Went to HaikuPorts and installed libz package. After installing it and confirming libz.so is in the correct place, it still complains it's not there.
Installed with the --no-deps option. It installed.
Ran: eval `dbus-launch --auto-syntax`
then 'koffice':
'command not found'....
Please advise.
klines works btw.
Box is a tar archive, so try 'tar xf ...box'. You can also install a package into specified directory, e.g.: 'box -i mc --root /tmp/myroot --no-deps'
Try kword or kpresenter instead of koffice.
With only one command (box), you can install everything, it's very conveniant.
If a decent GUI package manager should be implemented for Haiku, it should be a front-end to a solid packaging system such as pkgsrc (already implemented for Haiku, and cross-platform) or "box" made for TiltOS (also cross-platform).
BTW. I also look forward to a comfortable and modern - that uses the characteristics of Haiku - PM for Haiku, but I try not to criticize people, who, instead of waiting prefer to do something themselves.
I tried both kword and kpresenter, seems to be a problem:
Code:
kdeinit4: preparing to launch /boot/common/lib/libkdeinit4_klauncher.so kdeinit4: Communication error with launcher. Exiting! kill threadYou are very close to run kword. Looks like you have forgotten about dbus session. Try again Code:
eval `dbus-launch --auto-syntax`and then run kword. Note that first run may be very slow, because kinit is creating caches. If it crashes, run it again. Good luck!Karl! the command 'box -i dbus' don't install all needed files because of folders permission errors!
Please install manually and run kword again!!
Run: Code:
dbus-launch --auto-syntaxand show the output.~> eval dbus-launch --auto-syntax
DBUS_SESSION_BUS_ADDRESS='unix:path=/tmp/dbus-cv8WC1fVGr,guid=cb9f3f1c7e27a7e7667295ce4b55b732';
export DBUS_SESSION_BUS_ADDRESS;
DBUS_SESSION_BUS_PID=212;
~> kword
Reimplemented: void QApplicationPrivate::createEventDispatcher
qt_init()
Reimp: HQApplication::HQApplication
Reimplemented: QApplicationPrivate::setDoubleClickInterval - 500
Unimplemented: QApplication::setEffectEnabled
Unimplemented: QApplication::setEffectEnabled
Unimplemented: QApplication::setEffectEnabled
Unimplemented: QApplication::setEffectEnabled
Unimplemented: QApplication::setEffectEnabled
Unimplemented: QApplication::setEffectEnabled
Unimplemented: QApplication::setEffectEnabled
Reimplemented: QApplicationPrivate::setDoubleClickInterval - 500
kdeinit4: preparing to launch /boot/common/lib/libkdeinit4_klauncher.so
kdeinit4: Communication error with launcher. Exiting!
qt_cleanup()
Code:
eval `dbus-launch --auto-syntax`instead of
Code:
eval dbus-launch --auto-syntaxCharacters "`" are important.
1. Dbus runs fine
2. It looks like a race condition between kinit and kword. If kinit is running (kdeinit4 in process list), try to run kword again from the same terminal.
Btw, MaxOS was right. Dbus doesn't appear to install correctly. See highlighted text in the terminal. Also see the messages in 'QDbusViewer':
Also, it would be nice if someone could package this all into a a .pkg, and make an executable script that would launch dbus + kword, and kpresenter, with links to the menu etc.
edit - scratch that. From the above, it seems when you launch kword, it auto launches dbus.
But I'm running KOffice by 24 hours now!
THanks *A lot* kaliber!
Karl, the following command
Code:
box -i shared-mime-infodoesn't run a line of post-install.sh
try do it manually too. maybe runs now.
Did you have an X11 package installed from TiltOS already?
I'll try your suggestion.
In my opinion dbus package installs correctly (except mailbox and chown error, please ignore it, it's required only for *system* session)
When you launch kword it tries to auto launch dbus, but it cannot because "Haiku autolaunching" is not implemented yet. Officially there is only X11 autolaunching which is disabled in this package. Message "Autolaunch requested, but X11 support not compiled in" is vague.
Because auto launching does not work, you must manually run 'eval `dbus-launch - auto-syntax`. It must work.
For MaxOS and I, it doesn't unfortunately. Michael also had problems with getting it running. At the least, it doesn't work out of the 'box'...
We'll let others chime in here.
box -i kdebase and then
>kword
box -i kdebase --no-deps
that is the error that I was talking about.
But now is running fine here!
Now saving and open odt files is a great thing to me.
www.haiku-os.it/?q=node/673
Thanks a lot Grzegorz !
donate is comming... ;)
http://www.qt-haiku.ru/index.php?option=com_rokdownloads&view=folder&Itemid=61&id=12:internet
unzip /boot
I did a simple launcher app with a text file
Code:
#!/bin/sh
progname={65c0a398fff7dafd92cccd1b999cfd95}
curdir=`dirname "$progname"`
cd "$curdir"
eval `dbus-launch --auto-syntax`
/boot/common/bin/kword
It's often messy, bloated, un-intuitive and the developers tend to choose to implement new features and change underlying technologies just because they can and just because it's "cool" from a technical point of view, not focusing on the needs and expectations of the users.
This is not the way software for Haiku should be developed. I think we should focus on the QT port and on giving QT software a completely native look and feel on Haiku, so that developers can start developing new, original software in sync with the Haiku-spirit of simplicity and usability.
What a way to contradict yourself
I did not say nor did I want to say "port no open source software" or "all open source software is messy" - what I wanted to make clear is that Haiku should try not to depend on a lot of ported software which is not following Haiku's style and simplicity but to create an ecosystem in which new and creative software can be developed.
Haiku already has a clean and stable UI natively. All that QT does is provide more bloat around a light and clean OS, which is only useful for providing a quick and dirty way of supporting extra software (dirty implying non-native). Supporting QT officially would only move developers onto only supporting QT, but would end up with Haiku becoming almost a YALD (Yet Another Linux Distro). QT might be lovely in the short term, to provide access to nice apps, but should never be used for writing native apps in.
The UI that Haiku/BeOS presents to the user is in deed quite beautiful. What I was referring to is the lack of a complete layout mechanism that allows developers to easily create this UI while staying independent from resolution and font size. There is a rudimentary layout mechanism for Haiku (http://www.haiku-os.org/documents/dev/laying_it_all_out_part_1) but it is, well, rudimentary.
It does not have to be quick and dirty. Just porting a bunch of existing QT applications certainly would be, but patching QT so that it looks and behaves absolutely native (=no difference from non-QT applications whatsoever for the user, only much easier to develop) could help developers create new and _native_ software. Just because software uses a ported framework, does not mean it is not native. Haiku, at it's core, uses libraries such as glibc and freetype, which also have been ported.
An extra layer of abstraction would, in a way, make the system a little more bloated. The question is: Is it acceptable to sacrifice a tiny bit of slimness to make developers lives easier and support the birth of new software for Haiku? I think it is.
RSS feed for comments to this post.