The KOffice team is pleased to announce the next version of the lightweight, integrated and complete office suite. With exciting highlights like two new components - Krita and Kexi - and support for the OASIS OpenDocument file format, the KOffice 1.4 release is a large step forward. Even a Live-CD featuring the latest release is available so you can try before actually installing anything. You can also take a look at screenshots at OSDir to get a first glance. Read the full announcement and the changelog for further details!
Kubuntu's packages are on download.kde.org, we also have a Live CD with KOffice 1.4 (and KDE 3.4.1).
Great job everybody! go KDE! ;)
Are these now the default file formats for KOffice? How much of the standard is supported? If I remember correctly, there need to be two independ implementations of the OASIS standard before it becomes real. OOo provides ones and KOffice the other. So, is the standard in effect now?
> Are these now the default file formats for KOffice?
No, and they also don't cover all applications contained within KOffice.
> So, is the standard in effect now?
OpenOffice.org 2.0 is not yet released.
How's Krita? Is it any good?
I saw a video of it somewhere, I was very impressed! I don't remember where they released the video but it was cool.
I made a couple of videos for krita. Two were made with the old preview release (probably the one you saw), but I made a new one for the current 1.4 release:
It's excellent of course! The proverbial bee's knees, the cat's nip, the ewe's lamb, when bought in the shop it would cost you a fortune, but we can offer you a download for the incredible price, and it's cuttin' me own throat, guv', the incredible price of, listen carefully and don't faint, zero gold dubloons. Get yer fresh software here, get yer fresh software here! Fresh and free! Free and fresh!
Er... Sorry, got a little carried away there. Won't happen again! Promise.
Krita is a young application (it may have been started six or so years ago, but that doesn't mean it's been in continuous development for all that time) and you will certainly find it lacking in features compared to Photoshop. But I think we've got KPaint licked, here, and there are compelling reasons to use it over and above XPaint. And since svn was branched, we've started adding new stuff again, so it can only get better.
Kolourpaint was the first usuable program. Krita now is usable too and I expect it now to grow very fast.
Great work on Krita! Looks like you guys did an AMAZING job with it. At this rate, we will at last have a professional-grade painting program on Linux in but a few releases!
I had a small question though -- couldn't find anything about it on the site: Does Krita support Kipi plugins? Will it? SHOULD it?
Thanks again for you excellent work!
No, we don't support Kipi, at the moment at least. Kipi didn't seem terribily relevant as the plugins are mostly concerned with organizing images and take 8-bit rgb QImages as their choice of image format. I'd be very much interesting in integration with Digikam -- e.g., using Digikam as the organizer and Krita as the image editor with full sharing of plugins. But since Gilles and Renchi are developing their own image editor (working on 16bits, too, I have heard) that seems unlikely. And while I have started working on a Krita plugin that loads all digikam plugins, I'm afraid that that would be a dead end -- again, because Krita supports a potentially infinite variety of image formats, and the digikam plugins presuppose 8-bit rgba.
Okay, I suspected something like this. Anyway, thank you for the clear answer, and thank you again for all the good work!
Thanks to Gentoo, instantly providing the new KOffice packages, I just tried out Krita. Resumé: while still suffering from minor usability problems, it's capable and cool enough to make me (as occasional user, no graphics pro) drop the Gimp.
Pros, at the first glance:
- Finally an advanced bitmap editor fitting in only one window
- Consistent and comfortable use of brushes everywhere
- Good color selection, I think that should be ported to the main KDE dialog
- The docking tool windows work perfectly
- It just feels right, don't know
Issues that I stumbled over:
- Didn't find the command to zoom back to 1:1, neither in the View menu nor in the General/Tools dock, where an appropriate tab is also missing (you know, containing various zoom choices and stuff).
- Selections are not quite as intuitive as in Paintshop Pro, but seem to have their strenghs too. How about deselecting with the RMB?
- I'd feel better if new text would be created as selection, not as new layer.
- The Rotate Layer submenu contains direct rotation entries (90°/180°, which I like) whereas the Image menu just contains the Rotate Image dialog. I'd propose using the submenu approach also in the Image menu and renaming the Rotate Image/Layer dialog to Custom Rotate.
- Why can the crop rectangle only be dragged at the grip points, but not from inside of the existing rectangle?
- Shapes can't be filled with gradients, can they?
- The Color Manager's current color display is too small.
That sounds like a lot of problems, but I think they are not too serious. Well, the first one, maybe. But apart from that, it seems I'll be quite happy with Krita, because the devs did many things right.
So, great work Boudewijn & Co.!
Okay, good points. Let's take them one by one:
* Zooming. I just didn't manage to finish the bird's eyeview panel in time, I'm afraid, and I never thought about adding a menu option to go back to 1:1 zoom.
* Deselecting with rmb: that's a good idea... Could you add that to bugzilla? That way it's less likely to be forgotten by us.
* Text: I won't do much work on text layers for now. I'm playing with the idea to have the other KOffice components do that work, by inserting their objects as layers.
* Rotate: see deselect...
* Crop rectangle: Because we didn't manage to code that in time...
* That's probably an oversight -- I cannot run Krita at this moment because an injudicious hack is giving me trouble and I need to recompile, but if there's no gradient option in the shape tool option widget combobox, then it should be added... Workaround: use the shape selection tools to select the right shape and fill that with the gradient.
* I'm not sure about the last point, I've never had a problem with seeing what the current color would be because I look at the selection widget, not the color button in the control frame.
Anyway, I've added some points to the TODO, but if you want to track progress, please take the time to add them to bugzilla, too.
Koffice components as layers? That would be insane. So I could have a bitmap, with a vector layer from Karbon14, and a text layer from Kword? Now that would be a killer feature.
While I am dreaming, it would be even cooler if there were fx layers I could apply to these layers so that I could have a something like a drop shadow or transformation dynamically applied to my Kword layer as I updated it.
It may be a dream, but not an impossible one. I fact I don't think it would be too long before we start working on it. The whole layer thing: adjustment layers, grouping of layers, and layers from other KOffice applications is all on our todo. Currently though, all of us developers are deep into other features, but with the rate we are progressing right now...who knows.
But if you like krita just a little bit today - you just wait - you ain't seen nothing yet. LOTS of cool things and behind the scene improvements are being done or are planned.
> Finally an advanced bitmap editor fitting in only one window
i consider this a big fat MINUS. i love to have all image tools and dialogs open on the left monitor and the image full-screen without border on the right. you just cant do that with a everything-stuffed-in-one-window approach. so gimp is still the way to go for me, although krita looks smth more ... kawai
You can detach all toolbars and dockers from the main window and move them to your second screen; however, I have this nasty suspicion that I didn't take care to ensure that if you open a second view window, you won't get all the dockers and toolbars again... But as long as you work with one image in one view, it'll work exactly like want.
Remember, this is KDE. Of course you have the option, just drag the toolwindows where you want them. You better give Krita a try:-)
I don't like the one-window solution either. The tool panels take a lot of screen space away.
Detaching the tool panels isn't a solution either. Having a lot of seperate tool windows floating around is a nightmare. I spend too much time dragging them out of my way.
I would like to have one single master toolwindow, one that you can add as few/many tools to as you like, in the form of tabs for instance. The seperate tool windows should stay as well, because some users seem to like them and they allow a highly customizable single-window layout. Adding a master tool-container window would make Krita attractive to GIMP-UI fans as well.
>I would like to have one single master toolwindow, one that you can add as few/many tools to as you like, in the form of tabs for instance.
I seccond that :-) Except i think it should be more like the kind of "tabs" you see in Konq or Amarok out on the left. Having just *one* narrow and tall window at the left, with one-click acces groups of tools, layers, colour chooser, plugins/script extentions, coffee machine etc, would realy make my day. It saves screen real estate, and would work in both "crammed" and "exploded" mode :-)
I'll go work on making a mock-up right away!
I'd like to see your mockup but I have to warn you... I have started coding a system of dockers where the user can drag & drop tabs between dockers, and where there are two kinds of tabs: the toolbox kind (as in Qt Designer, hope that class doesn't get axed for Qt 4) and the tab kind. So, if you want all the palettes in one big panel, you just drag all of 'em to a toolbox pannel, and bob's your uncle
Curiously enough, the all palettes in one big docker was the approach of Krita when I started hacking the semi-abandoned codebase, and I found it didn't work for me. We've had a lot of grief with developing the dockers. Qt's QDockWindow's have some nasty bugs, Kivio's sliding dockers have other bugs and a home-grown solution has the disadvantage that maintaining it takes precious time from real development. I notice that Bibble Pro (a really great image editor) uses Qt and has the same problems with their dockers as Krita has.
Anyway, about four floating palettes seems to be what Photoshop, Paintshop Pro, Corel Painter, Acrylic and Procreate Painter have standardized on, so I decided to stop fighting Qt, and just go with the flow.
>Anyway, about four floating palettes seems to be what Photoshop, Paintshop Pro, Corel Painter, Acrylic and Procreate Painter have standardized on, so I decided to stop fighting Qt, and just go with the flow.
Yes.. I've been surfing screenshots of that too. So far it looks just like that, except I keep all four in one window, with konq-sidebar-tabs ("dockers?") on the left.
What I'm doing right now, is that making some dummy-work and then try and imagine (clicking on the drawings of the UI) what I would have to do to get the same job done using my approach. However it became clear quite fast that this approach translates to [a lot] more mouse clicks in exchange for the extra screen space. I'm no coder myself [yet], so I don't know if Qt/KDE allows a window in focus to "send" the keyboard shortcuts it detects to another window.. but if this is the case it would be truely KDE-like-kick-arse to just bind the "side-tabs" to , ,  &  (except in text-layer-mode), to allow for maximum-screen-space-dual-hand-krita-hyper-productivity-operation ;-)
>but I have to warn you... I have started coding a system of dockers where the user can drag & drop tabs between dockers, and where there are two kinds of tabs: the toolbox kind (as in Qt Designer, hope that class doesn't get axed for Qt 4) and the tab kind.
Again.. I'm no hacker but this doesnt sound as if it contradicts with my idea (is it "generic", "selfcontained" and "re-usable"?). In fact it sounds like this kind of work is axactly what is needed to make it possible to extend and re-configure my idea to fit everyone. It would be truely awesome if Krita is to be the first 100% custamizable IMP.. as every one seem to have their own take on how theese programs should look. If it too was all D'N'D, with 3-click profile management.. well.. that would be kind of devastating to any competitior :-) (If this was on side-tab 5 it could be done in 2 clicks)
I will post on looky sometime next week.
Happy Midsummer everyone :-)
WOW! Amarok-SVN has *exactly* the kind of side-tabs im thinking of! In fact the entire left side of Amarok is pretty much like what I had in mind.. that will make the production of my mock-ups much easyer :-)
Don't forget to mail me -- I might miss it otherwise.
>- Finally an advanced bitmap editor fitting in only one window
I do not understand why this can be listed as a "Pro". It is just a personal preference of "look", like the colour of the window titlebar.
Could you elaborate on what it brings (apart from the look) compared to recent gimp ?
Just as a reminder for people who haven't used gimp since 1.x, recent Gimp can make use of "transient" windows (it is an option in the preferences). Thus you have different windows on the screen, but you can minimise them all by minimising the image window. The whole point on "one window to rule them all" is thus void.
(and decent taskbars such as KDE one can group all gimp windows in one too)
> I do not understand why this can be listed as a "Pro".
> It is just a personal preference of "look", like the
> colour of the window titlebar.
1. I know there are many people who prefer a single window for a single document. And unlike the Gimp, Krita lets you choose how you want it, so how could choice be not listed as "Pro" (especially if it defaults to something that I personally like)?
> (and decent taskbars such as KDE one can group all gimp windows in one too)
2. The taskbar handling is still not as comfortable as the "real thing". It requires at least one additional click, and when the list of grouped windows appears, I still have to grasp which of them I want. If there are few other windows around, chances are that the window buttons are not grouped and clutter the taskbar. And I can't stand it switching to another desktop just to keep my taskbar clean.
Of course it's possible, learnable, has its good points and whatever, but I instinctively feel better with a single window, that alone should be enough to favour it :-)
Please if possible remove ImageMagick dependency from Krita.
Why? Is there something unclean about ImageMagick? Of course, if you are content with loading and saving nothing but native files, you can use Krita without ImageMagick already -- but I lack the resources to create import/export filters for all the formats that ImageMagick supports, and Krita needs more than kimgio can deliver.
Agree. I don't see the point of removing the dependency on ImageMagick. ImageMagick is ubiquitous and does just about every image format conversion you can think of.
I think the proper solution would be to have a image framework for KDE or something like that.
Why reinvent the wheel?
ImageMagick works. Just do it the unix-way instead of reinventing the wheel all the time.
> Just do it the unix-way instead of reinventing the wheel all the time.
Or may this old-skool quote:
"Those who do not understand Unix are condemned to reinvent it, poorly." -- Henry Spencer, University of Toronto
I think both quotes are quite silly. If we argue why re-inventing the wheel then by now we all would still be using CDE. There is a problem we need to solve properly and this means a sane graphic layer library doing these kind of work. Right now we have different KDE applications using different versions of graphic libraries for doing exactly the same task. Some use libimlib, some use stuff from imagemagic, some other things use some other libraries and and and. We could get rid of a lot of dependency on 3rd party libraries and tools if there was a proper graphic library or something. All KDE apps that require such a library can use the one provided by KDE and not from any random 3rd party application. It's easier for bugtracking and easier to maintain too.
You know what I think KDE needs to standardize for all of us?
Datatypes. Small generic libraries dealing with specific media formats. Datatype-aware programs become forward compatible; compile a library for a new image type, and all programs dealing with images know how to use that file. Amiga OS 3.x did it, OS/2 Warp did it... what are we waiting for? I've been wanting datatypes for audio, 3D objects, image formats and more for a while! They show these MIME associations that Windows 95 somehow lowered our expectations to for the crude, inflexible constructs that they are.
And if a datatype has to call ImageMagick, big deal. It'd be a minimal chunk of code for the purists to revise later.
At least as standardized wrappers (in cases of ImageMagick and Xinelib etc.) this would be really a nice idea, possibly this could be done for KDE4. Did you suggest that at some central place already?
I have as of now. It looks as though the kfile and kimgio libraries certainly fill in the gap for images with a plugin architecture; at this point, I have a general interest in seeing whether this approach extends to other formats.
between gdkpixbuf and gstreamer gnome has effectively done this for images and video but it was largely incidental and unfortunately not part of some greater plan. no reason why kde couldn't do one better.
I have to admit that I have been wanting to upgrade to kde 3.4.1, but no luck so far. Just out of curiousity, how is Suse looking these days?
Free version looks like desktop agnostic, highly advanced alpha version of
something great yet to come.
A KOffice 1.4 rpm for SUSE 9.3 is on ftp.kde.org.
Hopefully, the merger with conectiva will bring up to date packages for
mandriva in the future. Conectiva has been offering the latest KDE rpms
with each KDE release.
The alternative I am considering is to potentially switck to kubuntu.
I tried the live CD and it is very, very nice. But I am still sticking
with Mandriva, at least for a while. It just works for me. The only complain
being that they decided to be always a few months behind. Of course, the
good thing this brings is more stability.
I always thought they should keep the free (beer) version up to date,
and release the commercial version later, after massive testing. Oh well.
> I always thought they should keep the free (beer) version up to date,
> and release the commercial version later, after massive testing. Oh well.
Yeah, I am looking at switching just due to that. It used to be that Mandrake did a great job of staying up on KDE (a bit flakey though), but now they are 6 months to a year out of date.
I do like your idea.
lots of usability issues plus you need a resolution bigger than the mostly standar 1024*768.
Go back to your GIMP already.
At least I an use it even with a resolution of 800*600
What about 320*200? ...didn't think so. Gimp sucks!
Then why are you still complaining?? Bored??
Well, well... That was very, er... helpful.
However, maybe I can help you... If you add the line "dockerStyle=0" to the General section in your .kde/share/config/kritarc, you will find that this version of Krita uses the same sliding dockers as Kivio. Place them against any border you want, resize or wriggle them a little (that's needed, it's the bug that forced me not to include the option in the gui), and they disappear only to re-appear on mouse-over. That way, you don't need to buy a bigger screen.
Or you could just close the dock windows you don't need -- or roll them up using the conveniently placed button.
Go here: http://openusability.org/projects/krita/