Slashdot Mirror


OpenOffice.org: KDE Integration Project Launched

vfs writes "Someone at pclinuxonline.com noticed that a OpenOffice/KDE Integration Project has been started to "provide tight (but optional) integration of the OpenOffice.org to the KDE environment beginning with KDE look and feel and ending with KDE data sources." This could offer a great opportunity for enterprises to deploy an integrated, unified desktop." (Here's the dot.kde.org post on the project.)

16 of 47 comments (clear)

  1. Qt? by Otter · · Score: 4, Interesting
    Details are sketchy -- obviously, since no code has been written except for the cuckooo kpart -- but:

    I wonder if they're planning to do a pure Qt interface, as seems to be suggested in some places, or a KDE one? From the Mac point of view, pure Qt means a native OS X interface! The native Mac KDE seems to have stalled (nothing on their mailing list for weeks) and would require extra libs even if it were made to work.

    1. Re:Qt? by njchick · · Score: 2, Insightful
      But for Windows, Qt means no interface, as long as OOo remains free software and Qt for Windows doesn't become one.

      OOo has an abstraction layer to deal with different toolkits. Qt is not a replacement for it because its free version is not as portable as OOo itself. Qt would be just another layer. gtk or wxWindows could be a replacement from the whole GUI stack in OOo.

    2. Re:Qt? by Haeleth · · Score: 5, Interesting

      I don't think you quite understand the point. OOo on Windows already has a perfectly good interface that looks pretty close to the native look and feel, uses the native save/load dialogs, and so on. OOo on MacOS X is currently an X11 application, and as such doesn't integrate at all - it uses X11 save/load dialogs, uses X11 grey menus attached to the windows instead of the Mac's unified screen-top menubar, uses X11 widgets, and so on.

      A build of OOo with a Qt option would therefore mean a lot to MacOS X users, since it would provide them with something that looked like a MacOS X application. Meanwhile, Windows users could continue to use their Windows-like build. They would lose nothing, and Mac users would gain a lot. What's the problem with that?

    3. Re:Qt? by njchick · · Score: 2
      The problem is that the developers would spend time on something that increases complexity of the project as a whole instead of delegating all GUI to one toolkit for all platforms.

      It would be a quick fix for KDE and MacOS that may result in a nice interface, but I'm not sure it would be an optimal solution for the project.

      On the other hand, the developers are in short supply. If they happend to be KDE fans, it's better that they do what they want than nothing. There's no way to force a KDE fan to rewrite OOo for gtk for free.

  2. KOffice by Ianoo · · Score: 4, Insightful

    I, for one, am glad they're admitting that KOffice is simply not mature enough for prime-time. No offense to the KOffice developers, I'm sure they are all far better programmers than I am and I'm sure they work hard on their project - but every time I use the suite it seems to crash for various reasons, which is not a good thing if I'm trying to work on a document and haven't been saving it every five minutes.

    Maybe in a few years KOffice will be more mature and then all the KDE people can use it, but until then OpenOffice with tighter KDE integration seems like a fairly good idea. I don't care whether they recode the whole interface in QT or not, but maybe a Ximian-like tweaking to integrate the suite with KDE's VFS, printing system and open/save dialogs plus some KDE-ish toolbar buttons (it already can take on QT's colourscheme IIRC) would be more-or-less sufficent. If they want to take it further, of course, then that'd be even better.

  3. Native Mac OS X port by xyrw · · Score: 5, Informative

    This could accelerate a native Mac port, since Qt has been ported to Mac OS X.

  4. Look'n'feel by Nucleon500 · · Score: 4, Insightful
    Finally! OO.org's toolkit has always bugged me - it's kinda slow, never looks like anything else, and menus don't go away when you click on the titlebar. Besides, having yet another toolkit increases the load time and memory requirements. One of the goals seems to be a Qt backend for VCL, and eventually a new widget set might be used.

    Of course, the big question is, which one. What are your favorites, people? I like the idea of wxWindows, though I wish it had a Qt port. In the long run, I'd rather see something like X but with server-side widgets, and I think wxWindows might be easiest to adapt to this model. In the short term, Qt or GTK would be great.

  5. Yes, you are by Feztaa · · Score: 4, Insightful

    Integrating OOo into KDE will be awesome, it will provide for greater consistency between applications, and there will simply be one less reason for people to complain about all the inconsistent GUI toolkits on Linux.

    Now, all we need is a rewrite of Mozilla in Qt... :)

    1. Re:Yes, you are by vigilology · · Score: 2, Interesting

      Spot on. I'm trying to convince my father that Linux is the way to go for his work desktops, and it's rather hard when the OOo and Mozilla file dialogs do not contain that beautiful shortcut to the floppy disk. I've had to set up a link to /mnt/floppy in his home dir instead. Down with custom file dialogs! Hooray for KDE file dialogs!

    2. Re:Yes, you are by Feztaa · · Score: 2, Interesting

      Down with custom file dialogs! Hooray for KDE file dialogs!

      Yeah, I love the KDE file dialog, it's awesome. Way better than the GTK2 one...

      Also, KDE's choice of focus models verse GNOME make KDE awesome (GNOME's focus model just gets worse and worse with every version).

  6. Re:Am I the only one by pr0c · · Score: 4, Insightful

    "Kethinov: Am I the only one who sees this as a waste of time? KDE already works. OO.org already works. OO.org already works in KDE. All this time spent on making it look better could be used in giving Linux some real features that it really needs."

    Exactly the thinking that costs us linux users. Working isn't good enough, windows 'works'. We need shit that goes above and beyond if we want to grow.

  7. Re:Am I the only one by Chainsaw · · Score: 2, Insightful

    You're right, of course. Creating an intelligent installer system that abstracts the creation of icons, checking if an application is installed and even choice of UI (KDE/Gnome/Windowmaker/curses). The problem here is quite odd - if I were to write a wonderful system that could do everything that you could ever demand, people would STILL complain and duplicate my work because it was written in C++ and not C.

    However... The Qt/GTK+ non-workandlookalike crap can be solved in a pretty easy way. Make a small library that they BOTH use to draw widgets. That is - both 'new QButton("OK")' and 'gtk_new_button_with_label("OK")' would generate a component that looks, feels and IS the same. How come that neither of the two have proposed this and seen that it sucks considerable less than the current way?

    --
    War is one of the most horrible things a human can be exposed to. And one of the worlds largest industries.
  8. And the answer to the GNOME vs. KDE debate is... by MikeCapone · · Score: 2, Informative
  9. No K by fm6 · · Score: 2, Insightful

    You assume that KOffice has a serious reason to exist. It doesn't. Perhaps it made sense at one time for KDE to try to replicate every Microsoft desktop software. But now it's time for them to adjust their goals. They need to acknowledge that they don't have the resources to do everything they'd like to do. They especially don't need to duplicate the work of the OpenOffice team. If OO interoperability were as much an issue as it used to be, things might be different.

  10. Rewrite OOo in XUL by axxackall · · Score: 2, Funny
    Now, all we need is a rewrite of Mozilla in Qt.

    I have a better idea: how about to rewrite OOo into XUL/XPCOM/Gecko?

    Seriously, The composer in Mozilla is already a good document writer. Calendar, Bookmarks and History are good examples of tables. SVG graphics is on the way too. So, it *is* possible to rewrite OOo in XUL.

    Why?

    • Because OOo will be automatically ported to any platform where Mozilla is ported already.
    • Because the cost of further developement of OOo will be dropped as XUL applications are much easier to develop and support.
    • Because it will be easier to customize look-n-feel (chromes) of OOo.
    • Because OOo will be better integrated with the browser and mail application.
    --

    Less is more !
    1. Re:Rewrite OOo in XUL by Feztaa · · Score: 4, Funny

      rewrite OOo into XUL/XPCOM/Gecko?

      Brilliant!

      You know, I've always thought that OpenOffice wasn't slow enough, but I could never think of a decent way to make it slower. You've really hit the nail on the head, though: We can add another abstraction layer to the code!

      Seriously, though, I think OOo is already big and slow enough, it needs to become faster, not more bloated. The idea of rewriting OOo's interface in XUL (which is basically XML + javascript) makes me shudder.