Two weeks ago, you read about several apps which keep KDE 3.5 alive. Today's issue of the mini-series provides even more reasons to love KDE. Covered applications include Krita, the image and painting application, Guidance, a configuration tool, frontends to Beagle and finally Scribus, the Qt-based DTP application.
Have you ever looked for a perfectly integrated, mature, good looking and feature-rich office-suite for KDE? Do you think OpenOffice is too slow? Then have a look a KOffice 1.5.
The most important improvement in version 1.5 is the support for OpenDocument. Instead of using its own file formats, KOffice now uses the same format as applications like OpenOffice. This means guaranteed interoperability with other Office suites and makes OpenDocument a real standard.
Despite having more components than any other office suite, things are improving very quickly. Version 1.5 features OpenDocument as the default file format, introduction of a unified scripting framework, enhanced accessibility for users with disabilities, the first major release of Kexi and a technology preview of KPlato, a new project management application. You can read more about it in the full announcement.
Even though the next big step is KOffice 2, scheduled for early 2007, Krita and Kexi, KOffice's database-frontend, (and maybe some more members of the KOffice family) will release feature-improved 1.6 versions.
Why do I mention Krita when it is part of KOffice? Krita improved so much in the last few month that it deserves its own chapter!
Now, Krita is a full-featured pixel-based image application with layer support, full colorspace independence including support for L*a*b and CMYK, a versatile plug-in based architecture. Furthermore, it share a scripting-engine named Kross with other KOffice-applications, which means you can write Ruby and Python scripts for it!
Guidance is a KDE-configuration tool written in Python. The day KDE 3.5.0 was released the Guidance-Team released version 0.5.0. Since then, they have released not less than six 0.6-releases, including hugely improved configuration tools for dual head setups and big improvements to the already known tools. Check out the latest screenshots!
Since SuperKaramba was released with KDE 3.5.0 for the first time, many new themes have been improved or added. For an overview about SuperKaramba's capabilities in the current KDE 3.5-version read this announcement.
If you are searching for new widgets to play with have a look on kde-look.org.
Sudoku is becoming more and more popular. With Su-per-Doku Superkaramba even provides you with a great-looking game to play on your desktop!
Twinkle -- Free VoiP
Twinkle is a free VoiP-software which enables you to talk to anyone using the SIP-Protokol. Twinkle is a KDE-application (screenshots) and for example integrates with your addressbook!
KSt is a real-time data viewing and plotting tool. In March 2006, the first bugfix release of KSt 1.2, version 1.2.1, was released. Version 1.3 is scheduled for May 2006. The list of features in KSt is huge: have a look at the homepage or at the screenshots to get an impression of this vivid project!
Kerry and yaBi
I bet you know Google Desktop. Well, for KDE you can now use Kerry, a KDE-frontend to Beagle, the desktop search engine. yaBi is Yet Another Beagle search Interface. It is written in Python and looks just great.
Scribus - DTP for Linux
For a long time there were no good DTP-applications available for Linux. Some years ago, Scribus started to be good enough for many usecases.
While Scribus 1.2 is already used by many professional designers and even offers commercial support, the current development series with its latest offspring 1.3.3 offers huge improvements:
The developers have put a lot of effort into restructuring the codebase, so you will notice a tremendous speedup: in certain situations even tenfold! The PDF and PS export is is now commercial grade, including full support for the new PDF X/3 format. Color is a top priority in many commercial settings; the authors of Scribus are aware of this and so have improved colour-management greatly. Also, last but not least, there are now native ports for both MacOS and Windows which should make a transition to Scribus even easier!
It's a really great app and it should deserve more visibility! It probably needs some enhancements on the UI side but it's by far the best KDE-aware SIP app!
An integration with Kopete would create a killer app for KDE.
I fully agree. Integration with e.g. kopete could be taken 1 level further
by creating a presence deamon http://wiki.kde.org/tiki-index.php?page=presence+deamon
> yaBi is Yet Another Beagle search Interface. It is written in Python and looks just great.
Honestly, it looks craptastic, with a typo in the title bar text, scary file URLs with three consecutive slashes, somewhat unorthodox use of the button widget and that tacky drop shadow effect for the text. This is supposed to be a reason to make me love KDE?
From a PR POV, minus points for the horrible compression ratio of that screenshot, and the color scheme (a consistent color scheme for all screenshots in the article would be the minimum; using the KDE default desirable).
Sorry for this harsh rant, but it's a honest one. Obviously both the author of yaBi and this article put a fair amount of time into both works and shared it freely to the benefit of others, and should be commended for that. But in a promotional feature, one should aim for a certain quality standard when it comes to appearance, and be selective enough not to highlight products that are not ready for prime time.
Perhaps I'm too tired, but what's the typo in the title bar? I can't find it. Is it the space before the '?'?
(By the way, if this program adds value to the KDE desktop, a few redundant '/''s sounds like something that's not worth to comment on. It'll get fixed in the next minor release).
Um, what's wrong with three slashes (except for the aesthetics)? file:// for the protocol and /whatever for the path.
not that I find it ugly, but removing something useless is always good.
I just try in konqueror and file: is the protocol and actually gets removed automatically. so path should simple be /home/user/file
nothing else IMHO.
Though as a GUI desinger I agree with many points, "craptastic" is really a bit too much for me and wont help anybody here. I hope your IMHO very harsh post doesnt overshadow some very valid points about GUI design (classic "geek" mistakes which sometimes can (I'm not saying it does here!) completely spoil an otherwise great open-source app):
1) It's generally not a good idea to use well-known widgets in "unothodox" (as the parent put it) ways. A button is a button. A drop-down list a drop-down list. It is *really* useful in terms of GUI design to think twice if you cant offer the same functionality with standard widgets.
2) Drop-shadows are bad. They belong to the childhood days of computer design where it was great achievement to put one text slightly shifted behind another. Now, we all can hopefully see a bit more clearly: This is just illegible nonsense. Don't do it please - it doesnt even look great.
3) Button labels. Generally, check all labels of buttons again. Do they contain words that your mum would understand (i.e. Control deamon, backend)? No? Is there really no chance to rephrase this? Think twice here ;-)
The URLs are also I problem I agree. Sth. like that just shouldn't be
exposed to the end-user. IMO it often helps to look at well-known interfaces
and ask if you cant get a bit more similarity to those.
In this case, I would propose some kind of e-mail interface. Split the
window in two parts. The top part contains just the list of search results
(like the subject lines of all found emails). If you click your way through
you see more content in the bottom part. The top part might contain
multiple columns depending on the type of search results. If you are looking
for e-mails it should have a from column, etc. The filenames are not
generally useful for everybody. They should be hidden for e-mails IMO.
BTW: Who the heck has invented those horrible +/- interfaces I'm seeing
increasingly more often? Adept (package manage of Kubuntu) uses this
too. This is bad, bad, bad! You click on an entry and suddenly all other
entries shift to the bottom to make space for additional data. Please
always use a seperate part of the screen to show this information and
dont shift items around all of a sudden. Imagine you are in a supermarket
and there are two bottles of wine next to each other. You want to take
both of them. First you reach for the first bottle. The moment you touch
it with your finger the other bottle slides away and makes room for
a sign "9.50 EUR, DRY, RED". Ridiculous and unusable, but sometimes such ideas seem to be normal in GUI design.
Hope my post isnt offensive but taken as a help to improve this app from a GUI point of view.
***...Adept (package manage of Kubuntu) uses this
too. This is bad, bad, bad! You click on an entry and suddenly all other
entries shift to the bottom to make space for additional data.***
Don't forget that this behaviour doesn't allow selecting more than one item, at least in adept. No way of selecting several packages, to perform same action in all of them...
Agreed, KDE may certainly excel in some areas over GNOME but this isn't one of them.
I mean have a look at the Beagle GNOME app: http://nat.org/best.png and tell me the KDE app compares...
Thankfully KDE has Kerry, which compares very well to Best.
To fix the '/' in paths, just use KURL.pathOrURL(). It does the right thing.
Thank's for all feedback.
Scribus links are b0rken (as well as dead!). Please fix!
We had some unplanned, but needed maintenance going on part of yesterday and today. All will be back up in a few hours.
How can we fix the broken server of the scribus project?
Anyway, they told us that it was down for unscheduled maintainance.
Once it's up again, the links will work just fine.
I do not think a link like 'http://www.scribus.net/index.php?name=News&file=article&sid=117%22' is valid, server down or not....
When I wrote that part of the article I tested the links and they worked.
I believe you. But someone introduced at least one typo in there when it was put online.
time will tell :o)
It is all back up and the links are valid :)
Yes, they are now all valid, because the invalid one from before:
has been changed to a valid one:
The minimum suppported KDE screen resolution is 800x600, and kerry's window is too big for the *supported* screen resolution. it should at least be resizeable.
I love kerry as much I love rlocate. it's fast and get's the information we need instantly. thanks Binner for kerry!
While I agree with you: Kerry is not official part of KDE, and only those need to adhere to the KDE-rules. Kerry is "just a KDE-app". If it will move to an official modules (like kdebase) it has to be modified.
There are Control Panel modules that do not adjust well to small resolutions. There should be more care put into this I think.
There are lots and lots of machines out there using 800 x 600.
Great app for sudoku is Ksudoku.
Could the Openusability.org people not take a look at guidance and help out a bit? I think the application would gain a great deal if it received some love from usability professionals.
I have a number of other questions on Guidance. It seems to be a replacement for Kcontrol. Is it? Does it work anywhere else outside Kubuntu?
What's the status of the kcontrol cleanup that was initiated a while ago? Has that now been left for KDE 4.0 as well?
Guidance is actually meant to somewhat be the opposite of KControl. Guidance is meant to configure the lower stuff in the system like Xorg, partitioning, etc (at least thats what I know, I've never used it)
Also I believe it will work outside of Kubuntu (they are just the first distro to include it).
> Could the Openusability.org people not take a look at guidance and help out a bit?
> It seems to be a replacement for Kcontrol. Is it?
No. Guidance is a collection of configuration/utility modules for handling mounts, partitions and drivers, users and groups, services/daemons and Xorg configuration. These modules run inside any container applications, like kcontrol, that supports KCModules.
> Does it work anywhere else outside Kubuntu?
It did run on Mandriva and Gentoo, but that was a while ago and I have not tried it since. Getting Guidance running on other distributions is usually a matter of making sure that any filesystem paths used are correct for the target distribution.
The kcontrol changes were never planned for 3, but for 4.
beagle is there....... but what happen with kat?
seems development has seriously slowed down. pity, i hope it gets up to speed again - until then, and until KDE 4 is out, beagle will be all we have. slow, heavy, crashy and eating memory.
KIOCLucene is equivalent of Beagle for KDE, not KAT, this is a littel bit different cathegory.
Sad thing KIOLucene is nearly unknown, contrary to Beagle, even in KDE world!
It definately needs more promotion.
KIOLucene is built upon the same library - Lucene - like Beagle. Just uses C++ port not Mono port like Beagle. It's more or less wrapper for KDE - like Beagle for Gnome/Mono. They can do the same things.
KIOLucene has no HTML result renderer, but apps like Kerry and yaBi should be adapted to KIOLucene very easily.
KAT and KIOCLucene promised to cooperate recently - but not much happened for a while. Metadata extracting is the right area for sharing the code, KIOClucene is here little bit hard to configure.
Go KIOLucene! ;) That looks great, mebbe the KDE promo people need to talk this one up, C++ is great compared to using Mono
from time to time I try to use Kspread for calculating my tables. I normally use Openoffice Calc with the OpenDocument format (since it's available).
So, I installed the new 1.5 version of kspread and saw the same strange behaviour as every time. When scrolling down and up again (by pulling the scrollbar...erm ...thing (don't know the name of the moving bar in scrollbar)) the grid disappears on some places. Every time I repeat it, some other borders are gone. Ok, that's a cosmetic issue, but annoying although.
Then I opened one of my OOo-OpenDocument-Spreadsheets and was wandering how badly the interoperability is actually working.
Some borders (not the grid but the borders I drew by myself) were missing, the width and height of the cells differed and finally the rounding of all numbers had been cut off.
I don't know which application did cause that trouble but my aqqaintance said he saw the disappearing grid while scrolling some versions before and he wondered why it is still there.
Well, it looks better than OOo and is faster as well but for me it is no alternative at all at the moment.
little time, short answer:
- the precision issue was fixed recently
- the grid painting issue was fixed 5 minutes ago by me
- I see the issue with the not saved borders (KSpread's issue).
I think, I know the code part which causes this. So, I'm confident
to also fix this before 1.5.1.
If you encounter more problems, file bug reports on bugs.kde.org, please. Going this way you'll help us a lot.
Thanks for reporting,
Well, that was really fast. :D
Because of the age of the disapearing-grid-behaviour I had never thought that it would be solvable that fast. Has nobody filed that as a bug before?
I usually write bugreports ... shame on me not doing it this time. :)
Thank you for fixing. I think 1.5.1 could be usable for me. :)
Well after that I decided for the first time I would file a bug report :)
I wonder if it will be fixed by 1.5.1..
SuperKaramba feels a bit slow, so it's a bit useless.
It's not that great apps that it looks like (on screenshots)