Key KOffice Developers Talk About KOffice 2 and Open Standards
KOfficeSource: a KOffice Consultancy Company
The password to join has been made visible. See the top menu under 'members' for the page link. To forestall joining by bots, the procedure has been left a little complicated but is not difficult.
Português
Bem-Vindo aos usuários do KOffice
wikidot handbook being translated to Portuguese
Português handbook begun
introduction
new KOffice and new QT means new features
This is for users of KOffice which is emerging as one of the primary choices as office software. Initially, it contains a wiki, a forum, some links and feeds from the KOffice news page and KOffice mailing list.
The forum is now open for posting by non-members. If that becomes a problem, the initial setting (only the Guest Book and Page Discussions were open for posting by non-members) may have to be reinstated.
Non-members may create new Wiki pages and edit pages they have created.
Google tuxmachines for KOffice - (100 per page)
Raiden's Realm has a synopsis of KOffice applications, an article on screen-shot captures, a summary of complementary graphics tools and another of complementary development applications.
The following KOffice applications are mentioned favourably in an IT Management article:
Kexi - KOffice database
KPresenter - KOffice presentation
Krita - KOffice image editor compared favourably with The Gimp
KSpread - KOffice spreadsheet
KWord - KOffice word processor
Cross platform KOffice to challenge OpenOffice.org Rodney Gedda on computerworld.com
a summary on lxer.com You need to log in to the site to read the full story
a discussion by KOffice developers
interview with Mark Shuttleworth | ogg version
Review of kWord by Carla Schroder December 6, 2007
A quotation from this page :
There are two ways of constructing a software design: one way is to make it so simple that there are obviously no deficiencies; the other is to make it so complicated that there are no obvious deficiencies. — C. A. R. Hoare
contributing to KOffice
support KOffice
ways to get involved
chapters
community
community building
site design
support sites on the links page
create your own pages members may create pages over which they have exclusive authoring rights
extras
international
advanced processes
scripting with Python
compiling and developing
* comments
Comments are enabled on this page. If you do not have permission to use this feature or prefer a forum discussion, there is also a 'discuss' button in the options at the foot of the page for automatic posting to the "page discussions" category in the forum.
If you cannot see the 'discuss' button, post in the forum by using the top menu Forum > Page discussions. view this insert
KOffice news
KOffice 2.0 alpha7 released
1210896000|%e %b %Y, %H:%M %Z|agohover
Logos and more help for KOffice
1210896000|%e %b %Y, %H:%M %Z|agohover
SpaceNavigators for KOffice
1210896000|%e %b %Y, %H:%M %Z|agohover
KOffice 2.0 alpha6 released
1210896000|%e %b %Y, %H:%M %Z|agohover
KOffice 2.0 alpha5 released
1210896000|%e %b %Y, %H:%M %Z|agohover
KOffice 2.0 alpha4 released
1210896000|%e %b %Y, %H:%M %Z|agohover
User wiki for KOffice
1210896000|%e %b %Y, %H:%M %Z|agohover
KOffice in the news: LinuxWorld.au
1210896000|%e %b %Y, %H:%M %Z|agohover
First running version of KWord on Windows
1210896000|%e %b %Y, %H:%M %Z|agohover
KOffice 2.0 alpha released
1210896000|%e %b %Y, %H:%M %Z|agohover
Praise for Krita in Linux Journal
1210896000|%e %b %Y, %H:%M %Z|agohover
KOffice 1.6.3 released
1210896000|%e %b %Y, %H:%M %Z|agohover
Krita Graphics Tablet Donation Drive
1210896000|%e %b %Y, %H:%M %Z|agohover
KOffice 1.6.2 released
1210896000|%e %b %Y, %H:%M %Z|agohover
University Students to Enhance KPlato
1210896000|%e %b %Y, %H:%M %Z|agohover
OpenDocument is Now a Real ISO Standard
1210896000|%e %b %Y, %H:%M %Z|agohover
KOffice 1.6.1 released
1210896000|%e %b %Y, %H:%M %Z|agohover
Krita review
1210896000|%e %b %Y, %H:%M %Z|agohover
Read the full review
KOffice 1.6.0 Released
1210896000|%e %b %Y, %H:%M %Z|agohover
For more information, see the announcement , the technical release notes, and the complete list of changes.
Release Candidate of KOffice 1.6
1210896000|%e %b %Y, %H:%M %Z|agohover
As usual, you are invited to test it in depth and to report any bugs via KDE bug website.
For more information, see the press release, the announcement and the complete list of changes.
Testers needed! KOffice release beta for 1.6 Version
1210896000|%e %b %Y, %H:%M %Z|agohover
For more information, see the press release, the announcement and the complete list of changes.
KOffice release first technical preview of its upcoming 1.6 version
1210896000|%e %b %Y, %H:%M %Z|agohover
For more information, see the press release, the announcement and the complete list of changes.
KOffice releases bugfix version 1.5.2 of its office suite
1210896000|%e %b %Y, %H:%M %Z|agohover
For more information, See the press release, the announcement and the complete list of changes.
Sebastian Sauer talks about scripting with Kross - KOffice scripting technology
1210896000|%e %b %Y, %H:%M %Z|agohover
Official mailing list archives
Re: Will KOffice 2 have filters?
Will KOffice 2 have filters?
How to center the printing on kspread
Re: minimum requirements
minimum requirements
Re: Class name area resize
Class name area resize
[Bug 160278] New: [security] provide anonymous editing
Re: Freezing titles row or column
Freezing titles row or column
[Bug 159689] Zoom widget disappears even with focus
[Bug 159689] Zoom widget disappears even with focus
[Bug 159689] New: Zoom widget disappears even with focus
Re: Problem compiling in sarge koffice 1.6.3
Re: Problem compiling in sarge koffice 1.6.3 " failed to load external entity
Problem compiling in sarge koffice 1.6.3 " failed to load external entity
[Bug 132793] crash when saving after trying to save using smb
Listing OpenDocument as Supported by KOffice
Re: Kspread: switch between rows and columns
Kspread: switch between rows and columns
Re: how may i use Koffice
Re: how may i use Koffice
Re: Merge data from Kexi to KWord
how may i use Koffice
Many users of KOffice no doubt use the Kde desktop. The following is a recent article by Bruce Byfield: 12 Tips for KDE Users
Chilling in Prague
1210951606|%e %b %Y, %H:%M %Z|agohover
Today is day one of FOSSCamp. FOSSCamp is an unconference, which means there is no set program. The program consists of writing entries into the empty program grid. This is refreshing approach which seems to work rather well for one particular use case: recognizing and fixing problems.
I've attended two particularly useful sessions. The first was about Xesam and the second was about KDE/GNOME interaction. Now these sessions mainly consist of sitting around a table talking about a particular subject. Since there are many knowledgeable people around, you hear many interesting facts and suggestions. Here are a few that are relevant to Strigi in an unordered list.
-
- common index file format
- Distributions want to install preindexed files such as documentation. All programs that implement Xesam would ideally implent support for one common format. Such a format may be heavily optimized for reading only and there should be a mechanism to tell the indexer aboutthe presence of the index.
- standardizing uris
- Xesam specifies that hits are identified by their uri. This allows flexibility. It allows an indexer to have many different types of information. It can have mails behind imap:// or files on another computer with fish://. These custum uris are, however, not standardized at all and it is unclear how a Xesam client should deal with a hit containing such a file.
- ultra lightweight
- Gustavo Babieri wrote a lightweight indexer for indexing music files on the Nokia Internet Tablet. I should have a look at that code. He claims we need a c interface to Xesam to remove DBus overhead on embedded systems.
- management interface
- To make Xesam attractive for program authors, we need an API that the allows applications to ensure that particular files are indexed.
The simple Xesam API held up well under discussion which is a good sign.
By the way, my current employer, PANalytical, allows me to book one day of FOSSCamp as work even though I'm here for personal interest in Free Software.
Blue Numbers
1210916710|%e %b %Y, %H:%M %Z|agohover
KDE has always been a community that I saw myself very happy with. Open, friendly and cheerful to newcomers. To improve that, and not to diminish the quality of coding while doing so, #kde-devel is better used for coding only, and suggests #kde-cafe for a socialisation channel. I promoted the use of that channel in the past.
I can't anymore though. Blue Numbers is an op at that channel. Everyone knows her... errrm... sorry, She knows everyone. Whenever she sees a newcomer to that channel, rather than being happy about a new person, she feels the need to follow up an interrogation session. Who he/she is, how he/she found the channel, why is he/she not in #kde-devel (we don't welcome gnomees now, no collaboration supported), what are their real names... oh wait, wasn't Blue Numbers herself using her fake name even in the kde mailing lists? only recently she added the real one to the planet even. And yes, if the person doesn't answer, Blue will /op herself and yes... you know the rest.
So yes, the USA will be happy that a new FBI member is doing the customs check works, and soon we'll all need to use biometric IDs to be able to enter #kde-cafe. So great!
I had complained about it... and now each time somebody joins, Blue Numbers will accuse somebody else (me) of being responsible of that interrogation session. Great! So first she'll go paranoid, and then I'll be the one responsbible.
I live in a country (Spain) that used to be a Dictatorship, just barely 30 years ago. We welcomed democracy. I don't want the same for a kde socialization channel.
If there are two things I really hate are 1) dictators 2) lies
KMail and bikeways in Germany
1210880589|%e %b %Y, %H:%M %Z|agohover
So this blog title is "KMail and bikeways in Germany". You may wonder what they have in common. You may wonder whether there will be an eloquent Aaron-style nice little story behind that.
But sorry, no, I have to disappoint you. At least from my point of view kmail and bikeways in Germany have absolutely nothing in common, two completely unrelated things, no surprising lovely details they share.
So, to get to the point: what I wanted to say for a long time: congratulations to KMail ! I use it since years and it always just works. And one IMO huge achievement: I have thousands of emails in my mail folders, and it starts really really fast, basically immediately. Sorting or searching the mail folders - instantly. Greak work ! Not all applications manage to do that.
Now to the sad part, the german bikeways. No, I won't complain that there are no or too few bikeways in Germany. More the opposite. There are too many, or, too many unusable bikeways in Germany. I mean, bikeways could be a nice thing. Not so here in Germany. The trend here is to put bikeways on the sidewalk together with the pedestrians. Does that make sense ? Does it make sense to have me riding with let's say 25 to 35 km/h through the pedestrians ? I don't think so. I also don't think that would be especially safe, neither for me nor for the pedestrians. But, well, in these cases, one could just ignore the bikeways on the sidewalks.
But now the really annoying effect of that is, that car drivers have come to expect that bikers belong on the sidewalk to the pedestrians: "This is my street, get off !".
I mean, it's not enough for them to honk at you, some of them go so far they lower their window just to scream that at you as biker.
Even if there is no bikeway visible, just sidewalks.
How to put it, I'd suggest to split bikers into two groups: sporty bikers, i.e. faster than 20 km/h and comfy bikers, slower than that. Consider the sporty bikers like motor bikes, and the comfy bikers like pedestrians.
IMO this would make a lot of sense. If I'm going relatively fast, e.g. at 30, I much rather prefer to share the street with the cars at 50, than to mess around between pedestrians moving at 5 km/h. At 30 I also don't want to circle around trees on sidewalks, go up and down the sidewalks at each crossing and also drivers don't expect somebody almost as fast as them selves on the sidewalks on crossings. OTOH if I'm going slow all that is ok.
So my proposal: either split bikers into two groups, or much better build bikeways as part of the street, not as part of the sidewalk, so we get accepted again on streets.
(children biking on sidewalks is ok of course)
Alex
Network Management in KDE 4.1
1210717998|%e %b %Y, %H:%M %Z|agohover
Today I took the plunge and merged the Solid network management infrastructure into KDE SVN trunk, where it will soon be released as part of KDE 4.1. Here's a summary of what it includes. Since what follows is Long, Save Planet[KDE|OpenSUSE] and read more for details.
Network Management in KDE 4.1 consists of the following components:
- An abstraction of network status and networking system configuration methods
- (kdebase/workspace/libs/solid/control). With this apps can find out which network devices are present in the system (similar to HAL, but with more run-time information present), what their status is, are they connected, their IP details, hardware specifications. You can also control the system as a whole - go offline or into flight mode.
This is modelled closely on the NetworkManager apis but is abstracted from them so that different versions of NetworkManager can be used by the same tools on various distros, or other network instrastructure can be used on other platforms. The API is a lot more flexible and better structured than the previous version found in KDE 4.0, and Kevin Ottens has been sharing his API design wisdom during the process.
Network configuration, for example: setting up wireless network connections, is deliberately excluded from the abstracted Solid API. It's possible to activate or deactivate a connection using Solid, but connections are treated as opaque identifiers only. The reason for this is that realistically, configuration is best done by one app on the desktop, so developing a whole chunk of API for it to use is not worth it. The configuration app can set up connections, then expose their identifiers to Solid apps to use. - NetworkManager backends
- (kdebase/workspace/solid/networkmanager-*). I've been working on a NetworkManager 0.7 backend, accessed indirectly by the above API, as this is the default in the upcoming openSUSE 11.0. A couple of hours after I merged, Pino Toscano, all-round champion developer, jumped in and started porting the NetworkManager 0.6 backend from KDE 4.0 to work with the new infrastructure.
- Frontend apps
- Chris Blauvelt has been patiently (and occasionally kicking my arse) waiting for me to merge but hasn't been idle. He's developing a plasmoid to work as a control applet, replacing the KNetworkManager applet from KDE 3. We had a workshop on this at the KDE 4 release event, where we consulted Celeste to design an interface that meets the two goals (or maybe the Scylla and Charybdis) of UI design, power and intuitiveness.
The plasmoid will be backed up with a System Settings module where you can create and edit network connections. Since I haven't started this yet, it won't be in KDE 4.1 main modules but I hope to have it available and useful somewhere else when 4.1 comes out. I've been hacking on KNetworkManager 3 together with Helmut Schaa (a colleague at Novell) to get it ready for openSUSE 11.0 recently and gathering some ideas how to structure the KCM. - A network status service
- Since Solid::Control isn't tightly bound to NetworkManager, we don't know that there is always a daemon available for apps to query for network status so they can go to offline mode. A KDED module provides this information reliably to KDE apps and as a lightweight plugin to KDED, doesn't add much overhead.
- UI and application infrastructure
- (kdelibs/kio/kio and kdelibs/solid) KStatusBarOfflineIndicator makes it stupidly easy to have a smart widget in your app's status bar to indicate when it's in offline mode, and a bunch of other API in Solid::Networking in kdelibs enables more powerful ways to find out if an app should behave differently when the internet goes away. Apps can just use Solid::Networking's easy namespaced functions and never know about NetworkManager, DBus or any of that gunk. This was patched into KDE 3 in openSUSE, and also used by Pardus, but couldn't be added as it was feature frozen. Now it's there for everyone to use in KDE 4. Go for it, app developers!
So, that's my brain dumped for now. If you want to know more look for me on #solid (wstephenson). Apologies to Danny for not sending him this for the Commit Digest, and to kde-core-devel for not using it for its intended purpose.
LinuxTag 2008 Upcoming
1210542429|%e %b %Y, %H:%M %Z|agohover
In two and half weeks the likely biggest Linux Event kicks off: LinuxTag 2008 in Berlin. Four days of exhibition and more talks (the organizers say 240, German/English mixed) than ever before. I plan to be around all the time. 
On Wednesday everyone's darling, the multi-headed president of KDE e.V. and the galaxy, Aaron Seigo will give a keynote about KDE4. On Friday is a day-long track with KDE talks, on Saturday is openSUSE day and there are separate talks about Amarok and Kontact planned. Additionally there will be of course KDE and openSUSE booths all the time.
Special tip: one can travel for 59 Euro from everywhere in Germany with ICE to LinuxTag/IT Profits and back.
openSUSE 11.0: Qt Package Manager Improvements
1210508188|%e %b %Y, %H:%M %Z|agohover
Just want to point out four improvements of the YaST Qt package selector in the upcoming openSUSE 11.0 that were missing too long, much requested (at least by me) and now added :
The first screenshot shows the new special package groups "Suggested packages" and "Recommended packages" to list packages which enhance your installed packages. Also the strange "zzz All" package group of previous releases is renamed to "All packages" and visible without endless scrolling.
On the second screenshot you can see the new "@System" meta repository to list all installed packages only. And note the new secondary filter "Unmaintained packages" to detect which packages are not contained in your activated repositories (also a nice way to detect which old packages were wrongly not obsoleted by a distro upgrade).
Update: Let me add a fifth one. As you can see on the screenshots we have a yast2-theme-openSUSE-Oxygen package with Oxygen style like icons everywhere thanks to Martin Schlander.
gsoc: Improve OpenDocument in KWord
1210475847|%e %b %Y, %H:%M %Z|agohover
Just like last year the KDE-family did provide us again a gsoc-slot to work on Improve ISO OpenDocument support (in KOffice, particularly in KWord). Not only did the number of mentors drastically increased but personally I also had the feeling the number of very good proposals did. To be allowed to read all of them was such exciting that I found myself spending hours over hours on the huge list reading lots of proposals again and again just for fun. To be able to see such a pool of impressing ideas and developers was already reason enough for me to participate again as mentor rather then as student. Thanks to google for this unique opportunity!
One of the things I totally dislike about the mentor-role is the need to coordinate with all the other mentors on the try to "rank" those proposals somehow what is needed since we can't just select all of them or at least those who are very good but we are limited to a more or less fixed number. The fate of having so much good choices. I also remember my own frustration in 2005 and 2006 where none of my proposals got selected (though looking with my current experience at them they didn't matched into the "very good" category but at the best case in the "good" one). I guess part of that dislike is also the need to base such a decision only on the proposal itself which is text- rather then code-based and therefore, in my eyes, much more difficult to parse. One thing what helps here a lot is to see some kind of planing the student made. So, dates with milestones that allows to see what to expect next few months and probably even some details how the job should be technical achieved - but that may only my biased view on things. Another thing I dislike is that gsoc happens during the summertime which is not exactly the best time to be productive cause of all those sun out there. A gwoc (winter of code) would maybe match better
I guess it's quit usual that everything has two sides and once those ugly selection-burden got taken, the real work and with it the fun starts/continues. As mentor it's important to guide the student specially at the beginning. It may needed to help him to setup a developing-environment (up-to-date trunk, SVN-account, blog, etc.), to guide through the probably already existing code-base, to coordinate (align times, provide a path to start to walk on, offer co-mentors that can help if the mentor himself turns ill, has a hang-over or just needs his weekly sleep-phase to reboot), etc. Really a lot of initial work but it pays out if you see the commits rolling in. That's not only a thing of code but also of a great feeling to see that at least some of the experience collected within last years went "upstream" (probably a similar kind of feeling school-teachers have and what may drive them to continue there underpayed job?). Over the time it may turn from teaching over pair-programming like teamwork till being teached what is then another very great experience.
Back to the topic this blog started with; So, I'll mentor the improving OpenDocument-support and will try this time to blog a bit more about the progress we are doing there since there are rumours out that not everybody does monitor those thousands of commits KDE has each week 
After spending the last few days to discuss and plan what needs to be done to solve that rather complex task the most effective way, we did land a first series of commits for this years gsoc just yesterday and that even 2 weeks before the official gsoc-start. Thanks goes here to Pinaraf, the student that does mentor me (or was it the other way around? guess not since he did participate already at gsoc and KDE before and we where able to skip some of the inital steps and are atm already in the teamwork-mode), the KOffice-developers for providing again such a great environment to work in, the KDE-family for there trust in us and the believe in open and free documents and last but not least google for making all this possible. You all rock!
Double trouble...
1210440716|%e %b %Y, %H:%M %Z|agohover
...that's what my friends all call me.
Actually they don't but since I am a huge fan of Lynyrd Skynyrd and this blog entry is closely related to the previous one I am (ab-)using yet another of their song titles.
Earlier this week I got rid of the "org.kde" namespace in Akonadi's D-Bus names, e.g. org.kde.Akonadi.Resource is now called org.freedesktop.Akonadi.Resource, to emphasize that we are a cross-desktop project and that the real interaction point for interested parties are the interfaces (and the data transfer protocol), not some specific implementation like libakonad-kde.
Speaking of renaming: I am not yet quite satisfied with one of our D-Bus names, so if you have any suggestions I'd like to hear them.
To further facilitate contributions outside the KDE sphere we have requested project infrastructure on freedesktop.org
Since this will take a while, let all any interested contributors know that getting commit access to KDE's SVN is not an arcane procedure and anyone with a proven track record on another free software project will most likely get approved quickly (I am talking about the order of minutes here).
My 2 cents on releases...
1210412493|%e %b %Y, %H:%M %Z|agohover
Ok, we all know, blogs are the new mailing lists, so here just some quick comments from my side on all the release-cycle stuff.
About being in sync with releases of other projects: I am caring for our buildsystem which uses CMake, so the releases of CMake and KDE matter to me. I want to provide a stable (as in "not chanigng too often") build environment. If project A (KDE) depends on project B (CMake), it doesn't help project A anything if it's releases are in sync with project B. Why ?
Because, well, in order to have a stable environment I don't want to force developers to have to update their cmake from non-distro packages (the binary cmake packages provided by Kitware work flawlessly on all systems I tested so far, btw). This is frustrating ("damn, which package do I have to update today to make KDE build again ?") and takes away a lot of time (not for a single developer, but accumulated for all).
So, before we (KDE) require a new version of CMake, I personally want this not to happen before that version of cmake is shipped by the most common distros (i.e. a few months after its release).
So I see also a value in not depending on always the latest and greatest releases of other projects.
Regarding DVCS: I don't have much experiences with them, but when I tried git, it wasn't really easy. Mercurial is said to be much more user friendly, which for me would be a big advantage, lowering the entry barrier to KDE development etc.
But, what I wanted to say: I big part of the value cvs/svn provide is IMO that all code in development is visible to all developers immediately, not only once a while. Especially for KDE with its many many developers this means that current code will be tested (at least built, maybe also run) immediately by many developers, so problems should be found quickly. We don't have that many developers on "exotic" platforms like Windows, OSX, Solaris, *BSD. For keeping KDE working on these platforms it is IMO important not to create more work for them, by requiring them to deal with more repositories.
About "always summer in trunk": sounds really good, but I also see the risk that less people will be working on the stable branch as soon as it is created.
About the 6 months vs. 9 months vs. 3 weeks: I agree with Aaron that 6 months is quite short. It leaves 4 months for feature development. Which also means you should start with the features really soon after the release, otherwise you may have only 2 or 3 months left for that. At least for me it has always been the case that there are weeks where I just don't have the time to do anything significant on KDE. E.g. when I was student, there were the weeks with the exams, sometimes you go on vacation, real-world stuff like moving, visiting friends and relatives etc. add up from time to time. For me this also means a time span like proposed by Aaron of 3 to 4 days for a stabilizing period absolutely wouldn't work for me, since it will happen often that just during these days I won't have anytime at all.
So, this was probably not as nicely written as the other blogs on this topic, but I just wanted to share my view on this too.
Alex
Reworked scale dialog in Krita
1210273612|%e %b %Y, %H:%M %Z|agohover
I've worked a bit on the scale dialog for Krita. Neither the old one from the 1.x series nor the new one in current KOffice2 alpha releases were good enough. I've mailed a bit with Ellen which only confirmed that it is indeed a difficult dialog to get right.
In the end I reordered some items, so I hope it's a bit easier to figure out how to use it. I think it has become quite good, but judge for yourself. So much cool stuff coming in KOffice 2.0