Welcome to KC KDE! This week's issue is momentous as it marks the growth of the editing team from one lonesome soul to a whopping two people! Rob Kaper joins the KC KDE effort this week with a summary of the kde-games list. He will also be following the konq-e list which tracks development of Konqueror for the frame buffer (non-XWindow) and the kde-promo list. This brings the total number of lists summarized each week up to an even dozen.
A warm welcome and a big thanks goes out to Rob and we all look forward to your contributions to KC KDE in the coming weeks! Speaking of contributions, here's what happened this past week in the world of KDE development discussion:
KOffice development has been going ahead at a terrific pace with people
such as David Faure, Thomas Zander, Laurent Montel, Toshitaka Fujioka,
TheKompany and many more focusing on the various applications included
in the application suite. Daniel Naber posted announcing an addition to KWord saying:
here's a very unfinished patch that adds a thesaurus to KWord. Several
things need to be decided before this can go in. Also I cannot do this all
alone, but I need quite some help. Anyway, I think it's such a nice
feature that people will surely support me :-) You need Wordnet to use this
Since this was Daniel's first attempt at KWord code he has several questions
regarding how to proceed with completing the patch. David Faure and Christian Tiberna
helped Daniel with several of his questions.
Of particular interest was a posting from David who said,
Yesterday I finished the KoDataTool support in KWord.
This means, it's now possible to write a separate service that provides entries
in the RMB popup, for replacing a word with another one, or the selection with any
replacement text. Currently the only available tool is the kspell tool, but this framework
can make it easy to add synonyms, antonyms, and whatever holonyms meronyms etc. are :)
without having to change anything in KWord itself.
I would personnally suggest to make a KoDataTool that uses either wordnet
or kdict, whichever is available (has to be same tool, otherwise we'd end up
with duplicate menu entries...).
Over the last several months a set of database abstraction and access classes
appeared in the KDE CVS tree. At the same time database components were being
added to the Qt toolkit. This caused Alex Zepeda to ask,
With the impending Qt3 release and all.. I'm left in a state of curiosity.
What's going to happen to KDEDB? Will it be dropped from KDE in favor of
Qt's SQL classes?
After a brief discussion verifying that the Free version of Qt3 will include the database functionalities, Alessandro Praduroux (the current maintained of kdedb) spoke up saying:
There are 2 things that must be considered IMHO
- KDEDB core libraries (kdbcore and kdbui)
- apps in kde using the actual KDEDB libraries
For the libs, probably the best bet is using the QT ones, provided that they have the same feature list ( one thing that comes to mind is the meta information about the database, that is in kdedb but I dunno if it's in QT)
the apps (actually only the ioslave, IIRC, and a small test app that is in kdenonbeta) can be rewritten if we go for the qt library, there's not a big installed base for now.
but Alex is right, NOW is the moment to decide to keep kdedb or to drop it and wait for QT3/KDE3.
One thing that must be considered in this discussion is that I have a very limited time now, and if we want to keep KDEDB we must find a new mantainer for it, 'cause if we put it in KDE2.2, we will get bug reports from programmers and someone must take care of it. I can help of course, but I don't think I can do it 'full time' now.
Further discussion resulted in a consensus that the kdedb library would
simply be a duplication of effort and should be
dropped in favour of waiting for the Qt3 database API to stabilize. Tantalizingly
Matthias Elter said, Just for the record, the plan is to port
KDE 2.x to Qt3. There wont be a KDE 3.0 for at least another year.
Maintaining the 2.x platform is critical for KDE now. So we might have a stable KDE 2.X
based on Qt3 in fall 2001.
This of course sparked much speculation and discussion
as to when this might be ready for release and what version numbering it would have.
Regardless of the details it is comforting to know we won't be waiting through another high
development period without stable releases as KDE experienced going from
KDE1/Qt1 to KDE2/Qt2.
Michael Goffioul first added a printing library to KDE2, then extended it to various printing backends and then added fax and PDF support. Now he has written a small fax application for KDE2 that can be used in conjunction with the printing facilities to complete the circle of necessary pieces to be able to print directly to fax from any KDE2 application. Michael announced this development saying:
This weekend I wrote a small fax sending application. Basically it is intended to be used with the KDE print system, as now it can send to fax, but there's no KDE fax sending application anymore (ksendfax not ported to KDE-2).
Main features are:
- supports EFax and Hylafax (use child processes "fax" or "sendfax" and the command line is configurable)
- use libkab for fax numbers, multiple fax numbers per entry supported
- simple GUI supporting DND, uses KIO::NetAccess to support remote files
- implement any-to-PS filter to convert any file type into PS before faxing. Filters are external programs (enscript, imagetops, ...), configurable and defined on a mime type basis. For example you can have this kind of entry "text/* enscript -E -p %out %in". With that filter machanism, you can drop any file on the fax main window.
- docked into the panel
Ferdinand Gassauer asked,
Does it support remote hylafax servers? IMHO necessary for office use where
only one hylafax server + modem is installed
Michael replied saying,
Wait, it hasn't been tested correctly as I don't have a fax. I will put it on
KDE-CVS (kdebase/kdeprint/kdeprintfax): either this morning (== before code
freeze) or at the end of the week (== after). Which is best? Maybe before, so
that it can be tested, even if the app is really not complicated...
For EFax, you can configure the device which the modem is connected to (default
to /dev/modem). For Hylafax, you can configure the fax server to use (default
to FAXSERVER env variable).
Ferdinand tested it once it was checked
into CVS and reported that it worked successfully for him. Ferdinand and Michael
then discussed improvements that could be made to it.
George Staikos has been working on improving encryption support in KDE and
is nearing completion of several key aspects of this technology. In light of this George
posted to list saying,
Should TLS be enabled or disabled by default in 2.2? I have removed TLS
support from HTTP for now until I see something concrete and not just a
single site that needs it. There is a new checkbox in it's place which
enables TLS support on all slaves which use TLS. Right now this is SMTP and
POP3. Soon it will be IMAP too. What the slave does is check the
capability of the server when it logs in, and checks the capabilities of KSSL
and the state of that checkbox. If all is good, it automatically enables TLS
before logging in. I have not yet finished the certificate checking code.
Stephan Kulow was the first to ask the question on many of our minds when he
replied saying,
George - how about using a bit less acronyms. They might be obvious for you,
but if you look at your upper case letter use you might find it's above the
usual english rate :) OK, let me put it this way: what's TLS?
George
replied quickly as usual and explained what TLS was this way:
Transport Level Security - it's a new release of the SSL protocol which gets enabled after the network connection occurs. For instance, with pop3:
You open a socket and get thebanner with a regular socket. Then you issue:
and you start TLS, something similar to SSL. Then you do your login and your mail transfer. It's much more transparent than SSL (but harder to "get right").STLS\n
Much discussion followed regarding the technical details of how to use the ioslaves that now have TLS support in them. The final result was that TLS should be enabled by default for some protocols, not for others and set by individual applications in still others.
IOSlaves are one of the core technologies that make KDE2 such an exciting desktop to use and develop for. It has been mentioned a few times on various KDE lists that the means to configure IOSlaves at runtime is going through improvements and maturation. Sergio Moretti posted some of his observations as to the current state of the IOSlave infrastructure, saying:
I hope to not come too late to put my review ;) on the new slave configuration framework. Here some points:
Lack of a per-slave configuration, I mean the possibility to have a different configuration for every currently active slave's instance. configNeeded signal not configurable, I think that this is a important point of extension, e.g. what if configuration is created dynamically when the host is hit, not before.
Don't handle persistence of configuration's entries, maybe in some cases this is not needed, but if it is, you have to duplicate your efforts to manage it.
Waldo Bastian gave the solution to most of Sergio's challenges saying,
You mean with slaves in connection-oriented mode? You can call
slave->setConfig() for those... does the slaveConfig stuf interfere badly
with that?
Sergio answered Waldo's question by asking how
to have two seperate IOSlaves of the same type running at the same time
in the same application, to which Waldo replied,
By running them in connection oriented mode. Otherwise having two slaves
configured differently makes no sense since you don't know which request will
end up with which slave. If you don't want to use connection oriented mode
for some reason, you will need to configure the slave for each request with
metadata.
Not everything that Sergio was looking for is handled perfectly by the
current IOSlave mechanism, however. Dawit Alemayehu commented on this
saying, on the specific issues you (Sergio) point out, I can say that it is
something that has already been discussed before and put on a TODO list for 3.0.
Specially, the issue of moving all the user-interaction stuff out to the application
level such that the kio does not have to deal with it. It is has been a big headache,
especially for David, to deal with KIO's ui_server :) However, such change is not
possible in 2.x series because it definitely would require API changes some of which
I am sure are not binary compatiable!
Ralf Nolden kicked off a huge, sprawling discussion which varied in quality and clarity from message to message by posting to the core-devel list saying:
one thing that' bugging me since weeks if not month, but after this weeks' show in Frankfurt and other complains I got, I'd say the following: either we move noatun out to kdenonbeta and take the kde 2.0 media player again, or it gets fixed by the ones who did it so it acutally *works*. I won't spend even an hour on another KDE booth with that buggy thing shipping as #1 quality work of KDE and I don't even want to *think* about the people bashing at us on LinuxTag for this crime on music loving people although the effects are great. I think it's not too late for the ones that wrote it to fix it up for 2.2 and increase the stability so this is your #1 chance to fix up things and produce something that is rock-solid - and has to be as most people use it or will say, hey, this is KDE, it has to work. It doesn't so KDE is trash :-)
This resulted in an immediate reply from Charles Samuels, one
of the primary authors of Noatun, who said:
Have you used noatun, by any chance on a release? Well _DUH_ it's going to
be busted, all the playing code has probably changed %200 on the aRts side (I
thought I physically toasted by sound card until I heard from the breaker of
the code (Nikolas Zimmermann :) told me it was busted.
In turn this
resulted in several people noting that they had run into problems with Noatun that
were not aRts related, most notably with some of the play lists.
A few days of frank discussion on the matter highlighted several points that are probably important for anyone grappling with Noatun to understand:
Nikolas Zimmermann wrote to kde-games-devel:
I'm planning "kbattle.net" at the moment
and explained:
kbattle.net should be a system where you can log-on, as kde user, to play kde-network-games via the internet. As you know it's hard to find another player, but on kbattle.net you can meet other players can communicate with them and choose a game to play.
Rob Kaper responded saying,
Check out GGZ, it is exactly what you are looking for:
http://ggz.sourceforge.net
, which started a long thread about disadvantages
of GGZ such as a dependency on GTK.
Josef Spillner clarified
It is _NOT_ Gtk, and I've said that a thousand times now. It is a system for online games, independent of frontends (be it Gtk, KDE, Win, SDL, ...), and I've already put a lot of work into the KDE port of it (which didn't exist when the current version (0.0.3) came out).
Nikolas remained skeptical about code not in KDE CVS, but Josef declared:
If you decide to go the GGZ way, I will sit down and try
to find a proper solution, which may also contain a partial move of sources from GGZ to
KDE.
, which sounded very reasonable.
Kevin Krammer joined the discussion and summarized the conversation to that point by saying:
AFAIK the GGZ project is primary a server framework but they do host clients for it as well. Please correct me if I'm wrong.
If the assumption above is close enough to reality our efforts should go into integrating a generic GGZ client into libkdegames, so that KDE game developers can easily make their games GGZ compatible.
Of course we could do something like GGZ ourselves but that is IMHO only waste of resources (mainly developer time). kdelibs doesn't include a ftp-server just because it provides a ftp-slave :P
Eventually Rob Kaper proposed to check out KGGZ before continuing the discussion which ended the thread for the time being.
As many pundits say (over and over again) interoperability is a key when it comes to office suites and their success. Kivio is a terrific flow charting application but without interoperability with other popular charting systems its viability arguably lessens. Especially challenging is creating bridges to closed-source commercial applications, in this case Visio. Kent Nguyen commented on his progress (or lack thereof) with Visio file support saying:
I was using "file" and "khexedit" to pierce into Visio stencil file format (.vss). I didn't get any where far. Has anyone here look at Visio stencils? If so, have anyone written a design how Visio stencils work?
This is what I'm interested in the Visio stencils:
- Extraction of the image
- Extraction of the connector points
- Dimension of the shape
- Extracting of the name of the image
Shawn Gorden replied saying,
Are you trying to build an import filter? We've looked and looked and
can't find a file format for Visio anywhere, it's just going to be a
painful process of reverse engineering the file as you add pieces to a drawing.
On a more positive note Nikolas Zimmermann commented:
i haven't finished it 100% yet, but i tihnk i get it ready within 3 to 4
hours. I made a Dia-Stencil Import Filter (not a koFilter, but direct kivio one, of
course) It's working good, but i haven't done polyline and polygon implementations
yet, will eat sth now let's see how fast i'll get it done
There was some discussion about asking Microsoft for details on the Visio
format and the resulting annoyance and dangers that may result. It was also
pointed out that Visio is moving to an XML based format in the near future which
could make things easier. However Dave Marotti noted one current limitation in
Kivio that will for the time being prevent Visio stencils from being usable in Kivio saying,
The problem with that is I don't have smart stencils in Kivio yet.
Many of Visio's stencils rely on formulas such as
drawLine( width-5.0, height-5.0, width, height) or something like that.
I haven't implemented that yet.