KDE 3.5 is a vivid platform. We looked at some reasons why three weeks ago and also last week. Today, we look at the photo-manager digiKam, the plotting application QtiPlot, the LaTeX-dreamteam Kile and KBibTeX and the upcoming KDE 3.5.3 release.

digiKam

If you have a digital SLR or other high-quality digital camera, you have probably noticed that the photos stored on it are not just simple JPEGs. High-end cameras offer the RAW file format, which stores the unmodified data from the cameras sensors. This means no quality is lost, and you can get 100% clarity out of your pictures. Many cameras also offer 12 bit and 16 bit colourspaces. Unfortunately, GIMP doesn't support these colourspaces and also cannot handle LCMS colour schemes.

Now, KDE provides not only Krita which supports both 16 bit colours and colour profiles, but also digiKam which fully supports these advanced features!

There is also now the possibility to geo-reference your pictures. Have a look. As you can see, you can mark where a picture was taken. For more pictures take a look at the new galleries of digiKam 0.9!

If you want to shorten the time until digiKam 0.9 is finished you can test 0.8.2 which includes some small improvements over 0.8.1 including CMYK colourspace for .jpg-pictures.

Kile

Kile is KDE's LaTeX-editor of choice. Version 1.9 was released on March 17 and makes Kile even better. The author not only fixed over 50 bugs, but also made Kile easier to use. The two most noteworthy changes are auto-completion of (La)TeX commands and compiling, converting and viewing your document with one click. Finally, KBibTex can now be used from within Kile.

QtiPlot

QtiPlot is a tool that is useful for everyone who needs scientific plots ready for publication. It supports error bars, value fitting, multi-peak fitting and many other advanced techniques for analysing your data. Since November 2005, the author has released no less then eight new versions, each providing you with even more features and of course many bugfixes.

KBibTeX

Apropros KBibTeX, a BibTeX editor for KDE which is now integrated in Kile. Last week, the author released version 0.1.4 which offers you an incredible list of changes. While the version 0.1.4 might sounds like experimental code I can promise you that KBibTeX is indeed very mature.
If you are looking for screenshots go here!

-->

KDE 3.5.x itself

Last not least, KDE itself is a reason why KDE 3.5 is alive! Until KDE 3.5, when a KDE-release was frozen in preparation to be released, new features and new user-visible text ("strings") were not allowed in later releases in the series in order to make sure that no new bugs were introduced and no translations were broken. For KDE 3.5 this is different.

Since the KDE 4.0 development cycle will take longer than typical due to the scope of the changes and improvements being undertaken, the developers want KDE 3.5.x to be the best possible KDE for users in the meantime. Therefore, KDE 3.5.1 and 3.5.2 not only fixed a lot of bugs (see 3.5.1-fixes3.5.2-fixes), but the developers were also allowed to change some strings in KDE so that many usability-improvements and updates in documentation found their way into KDE 3.5.x.

KDE 3.5.3 will even include some new features. When a new feature is already in the upcoming KDE 4-code, well-tested and known to work in KDE 3.5, the author of the code can ask for inclusion in KDE 3.5.3. If no other developer objects, the new feature can be added. Therefore, you will see some new stuff in KDE 3.5.3. (This list is constantly being updated and not yet complete.)

Stay tuned for KDE 3.5.3 at the end of the month!

Comments

To manage my bibliography, I use tellico that semms to offer more functionnality. For example I can link a pdf to an entry and add extra fields to entries. I've added a field keyword of type array, and then I can open a view that group entries by keyword (see snapshot).

Even if you do know a bit of LaTeX (like me), I find it so much more convenient to type in a WYSIWYM-Environment. You get a text display close (obviously and intentionally not identic) to the printed product, you get a nice formula editor (including AMS features), graphics and tables as already mentioned, and you get support for lots of addon packages available on CTAN. The power of LaTeX is not taken away (from references through ligatures everything is available in the GUI), and for those rare advanced cases you can use plain latex source as well, if you insist on it. With my LaTeX-knowledge, I usually only have the need to edit the preamble in order to customize the document to my needs, and the actual editing happens as comfortably as in a word processor -- with the remarkable distinction that the output happens in LaTeX-quality. In addition, I can "sell" LyX to non-techie average users who would (rightly so, given their experience) be frightened by LaTeX source code.

Well, i started with LyX myself. Now i use Kile.
And about "selling" a app to average users..: a friend started using LaTeX and Kile after watching me writing a document in Kile (we were preparying a lecture). And after a day he learned everything he needed to know about writing proper scientific documents. I only had to help him install Linux. So far about "selling" :)

I do miss a LyX-Style formula Editor in Kile, especially when dealing with big formulas, but for the rest i prefer Kile-Style editing.

I'd be wonderful if these two applications could work together to
achieve effects/plugin compatibility.
I don't know how hard would this be or if it is feasible at all,
but for sure it'd be a great asset for KDE as a graphics editing platform.
And seeing that both apps are now supporting the same advanced
features as 16 bits per channel, etc. makes one dream this could
eventually happen! :)

If both Digikam and Krita could use the same effects, perhaps, there could be a central place where they could reside so that the user would just need to install new effects to that location and the programs would automatically use them.
I know... I'm just dreaming... :)

I think perhaps you're talking about Kipi plugins.
The idea of Kipi was a great one, but without support for 16 bits, nor other color spaces than RGB, in the end it proved not much useful for professional editing (and painting, ...I know) programs, like Krita intends to be.

With respect to the concept you expose, that says if users need to place the plugins in "a location", its use could not be called "automatic"... well, I don't really understand it.
The idea is clear, a place for graphics editing plugins to reside, where any program (API compatible) could look for to find extensions to its native functions.
Sounds bad to you?
To me it sounds like something convenient that could save many man-hours of "reinventing the wheel" kind of work.
If it can be done starting from current digiKam ImageEditor plugins it's another story, of course.

DigiKam already split most of their image processing and utility tools out into 2 packages, kipi and digikam-plugins. A number of other programs such as Gwenview and Kimdaba use the kipi library, so those resources are very much shared. I understand that the Digikam-plugins rely a lot on the internal image model of digikam, and so krita may find them hard to reuse (and vice versa). However, many of the Digikam filters and the like are based on calling other projects like cimg, or adaptations of various gimp plugins, so there is some reuse there too.

More than digikam-esque, it is digikam! Or rather the photo-editor part of digikam as a standalone app for those who want the editing without the file managment. You got to admire the digikam guys for their architecture and focus on re-use :-)

I don't agree.
digiKam is implementing a lot of image editing functions as plugins, and these functions are also very common in everyday use of a program like Krita, Gimp or Photoshop. We're talking about such things as color correction, cropping and rotation of images, blur & sharpenning. This is the bread and butter of every image editing program.

With respect to Kipi plugins I know they exist, but for some reason they don't support 16 bit images and other advanced features, so I think there's not much future in them for professional use.

Well I've never used krita, but I can understand your point of view.
So a good way to proceed could be to implement in kipi-plugins the
16 bit images support and allow in suach a way all the kipi host
applications to use it - adding a new one krita :).
Kipi is trying to have a new life and going on with the developers
old and new that can help. New plugins and plugin maintainers and
new kipi features are more than welcome.
Could it be this the way to?

Well, showing off some of the more funky features of KRename, like its ability to handle TagLib supported meta information, would show it as one such - i generally use amaroK's functionality for the same, but it is a really powerful thing :)