Latest | Archives | People | Topics
Latest | Archives | People | Topics
Latest | Archives | People | Topics
|Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic|
Table Of Contents
|1.||30 Jun 2003 - 16 Jul 2003||(13 posts)||Patch for IMAP Calendar and Exchange|
|2.||9 Jul 2003 - 21 Jul 2003||(13 posts)||[Kde-pim] KPilot Developer's notes for July 9th|
|3.||10 Jul 2003 - 23 Jul 2003||(40 posts)||ClientInterface (was Re: Fwd: [PATCH] kernel / UI separation - DCOP example)|
|4.||13 Jul 2003 - 24 Jul 2003||(70 posts)||Konqueror Delete Unification|
|5.||15 Jul 2003 - 17 Jul 2003||(5 posts)||new kinfocenter firewire module|
|6.||16 Jul 2003 - 19 Jul 2003||(9 posts)||New action: move to next unread message or folder|
|7.||16 Jul 2003||(4 posts)||Take Addresses feature for kmail|
|8.||17 Jul 2003 - 19 Jul 2003||(8 posts)||KDE i18n HOWTO updated|
|9.||17 Jul 2003 - 22 Jul 2003||(53 posts)||new KDE Development book|
|10.||18 Jul 2003 - 23 Jul 2003||(53 posts)||KDE Man Page Generator|
Hi. This is, of course, this week's KDE Traffic. Last week there was quite a controversy. Even though most people seemed to appreciate last week's KDE Traffic, there were a few that didn't, and as much as I hate to admit it, they have valid points. I have created a FAQ that will shortly be posted to the kckde list. But there's something else I'd like to say.
Even though I do this for all of you, and I listen to you, please remember that I don't get paid to do this. I do it because I like to do it, and if I weren't doing it, chances are that it wouldn't get done, because it wasn't done before I came along. So please keep that in mind when you decide to snipe at me anonymously on the Dot or something else like that. To those of you that were civil during last week's fracas, thanks. To those who disagreed with me without getting personal, thanks. To those who were mean-spirited and ungrateful, I'd recommend seriously that you reconsider your notion of what the economies of open source and volunteer effort are.
Also, sorry this was so late. I got hit with a really bad cold last week, which wouldn't really be an excuse, except that I also had to perform all last week, which sapped every last bit of energy I had.
Anyway, that said, there seems to be a lot of stuff going on this week, so I'll get right to it.
Mailing List Stats For This Week
We looked at 953 posts in 4101K.
There were 247 different contributors. 137 posted more than once. 93 posted last week too.
The top posters of the week were:
1. Patch for IMAP Calendar and Exchange
30 Jun 2003 - 16 Jul 2003 (13 posts) Archive Link: "Patch for IMAP Calendar and Exchange"
People: Mark Taieb
Mark Taieb said:
I've created 2 patches for kmail. With them, you can consult with Korganizer your exchange calendar. Note that it only works with cachedimap.
The rest of the thread gave feedback, and resulted in Ingo committing the patch (Hand off to you, Derek :))
2. [Kde-pim] KPilot Developer's notes for July 9th
9 Jul 2003 - 21 Jul 2003 (13 posts) Archive Link: "[Kde-pim] KPilot Developer's notes for July 9th"
People: Adrian De Groot, Reinhold Kainhofer, Adriaan de Groot
Adriaan De Groot started off this thread with this lengthy missive:
[Hm, lots of entries from me, few from Reinhold. I know that he tends to hold stuff back until it's really done, and his conduit fixes tend to be heavier than my stuff anyway. He's been busy, I know. Let me carefully suggest that Derek B. is also coding some subtle improvements, and David G. has a homework assignment too.]
[Upgrading KPilot now will result in you having _fewer_ conduits than in 4.3.X, and it'll start with a bunch of warnings as well.]
2003-7-7 Adriaan de Groot
2003-7-6 Adriaan de Groot
2003-7-5 Adriaan de Groot
2003-7-5 Adriaan de Groot
2003-7-4 Adriaan de Groot
2003-6-29 Adriaan de Groot
2003-6-26 Adriaan de Groot
2003-6-25 Adriaan de Groot
2003-6-22 Adriaan de Groot
2003-6-21 Adriaan de Groot
2003-6-20 Adriaan de Groot
2003-6-20 Reinhold Kainhofer
2003-6-19 Reinhold Kainhofer
2003-6-16 Reinhold Kainhofer
2003-6-15 Reinhold Kainhofer
To which Reinhold Kainhofer responded:
Yes, I'm busy with a lot of stuff from KPIlot, none of which is actually in a
state where I can commit it. In particular, I'm working on
- -) Custom field sync of the addressbook conduit
- -) Make the conflict resolution of the abook conduit more intuitive (ask just once for each conflicting address)
- -) Finish up the todo editor
- -) Make the generic DB viewer an editor (more or less finished, but the KHexEdit widget is not yet publically available, so I can't commit that part, either)
- -) Implement the InternalEditorAction which syncs the changes done in the internal editors/viewers to the handheld
The rest of the discussion was simply on discussing autostart and the reader is directed to the thread if he/she wishes to know more.
3. ClientInterface (was Re: Fwd: [PATCH] kernel / UI separation - DCOP example)
10 Jul 2003 - 23 Jul 2003 (40 posts) Archive Link: "ClientInterface (was Re: Fwd: [PATCH] kernel / UI separation - DCOP example)"
People: Don Sanders, Ingo Klöcker, Andreas Gungl, Carsten Burghart, Marc Mutz, Martin Konold
This thread doesn't fit with my usual standards of what is interesting, not to mention it's quite out of context, but because it was so active and is actually a continuation of a thread that was covered in an earlier KDE Traffic I will attempt to cover it. To refresh your memory, this thread is the discussion of trying to separate KMail core from the UI, using DCOP.
This incarnation of the thread begins in response to a patch by Andreas Gungl by Don Sanders:
I've reviewed this patch. I like it, it's a big improvement. I have some comments:
Could you please add a note to clientIface.h stating:
"KMailClientInterface is subject to change without notice and not yet part of the standard KDE API."
This is to avoid the need to keep backwards compatibility with third parties, and make sure that we are free to change this API at will. Initially I would like to restrict the use of this interface to kde-pim.
I would prefer to keep such a notice until some time in the future when the interface has proven stable for a reasonably long period.
Regarding the comment.
+// TODO - this needs effort to separate kernel and GUI
This issue should be resolved before the patch is committed to cvs. Is it possible to use a SYNC dcop method to show a Yes/No messagebox and return the result? Eventually we might be able to architect KMail so that only ASYNC dcop methods are used, but I think it makes sense to have a transitional period where SYNC methods are used.
At some point the various methods in KMailIface need to be deprecated and replaced with equivalent/similar methods that take a KMailClientIface parameter. (So that clients other than KMail, such as KAddressBook/KOrganizer can take advantage of this work, and do so simultaneously).
Ok now onto the main issue with the patch, KMBroadcastStatus is used in client.cpp. I think that's a cool idea but I want to be sure that the implications of this decision are understood.
Code can only exist in client space (all of client.cpp is in client space) or in server space (kmkernel.cpp is in server space) but (except in exceptional cases) not in both.
As a general rule any code that deals with (Q)widgets belongs in client space and everything else belongs in server space.
KMBroadCastStatus deals with the status bar and little progress widget so let's say that KMBroadcastStatus belongs in client space. Then all usage of KMBroadcastStatus in server space has to be replace by calls to the current KMailClientIface. (Does the existence of slotSetStatusMsg, and slotSetStatusProgressPercent in KMailClientIface show that you already understand this?)
Examples of server space where such modifications are necessary include imapaccountbase.cpp, kmaccount.cpp kmacctcachedimap.cpp, kmacctexppop.cpp, kmacctimap.cpp, kmacctlocal.cpp, kmacctmaildir.cpp, kmacctmgr.cpp, and kmsender.cpp.
Examples of client space where such modifications are not necessary include kmail_part.cpp, kmheaders.cpp, kmmainwidget.cpp, kmmainwin.cpp. But these files contain classes with the opposite requirement, all usage of server space must eventually be replaced with usage of KMKernelIface.
Once (in happy future space) this is done then it should be possible to put all of the client space files into a separate library that only accesses the rest of KMail through KMKernelIface. Then KMail standalone will become a small program that links to this separate client library and in main() starts up the KMail Kernel/Server if it is not already running, and calls the KMKernelIface method that creates a KMMainWindow.
Other programs like KAddressBook will be able to link to this separate KMail client library, and do things like open a composer window in the KAddressBook process itself.
Oh one other thing, (before the client KMail library can be made) all the methods in kmailIface.h have to be deprecated and replaced by methods that take a KMailClientIface parameter.
And probably KMKernel should contain a KMailClientIface member variable and accessor method as there can be only one client using the kernel/server at any single time.
Such an accessor method would make it easier to migrate server space code from using client space code to using the KMailClientIface.
Did that make any sense?
To which Andreas essentially agreed. Ingo Klöcker responded, however:
I just returned from LinuxTag 2003 in Karlsruhe. During LinuxTag I talked with Cornelius, Tobias (tokoe) and Marc about the UI separation. No decisions where made but we definitely see the need to talk about this some more because this is a very serious decision which will have a very high impact on the future of KMail (So why Cornelius and Tobias? Because they would like to use some of KMail's functionality in KO resp. in KAB). Although I was at first quite enthusiastic about the DCOP approach, the others don't think that using DCOP is a good idea. So we really need to talk about this in a larger group. I would prefer to postpone any decision until Nove Hrady where we will have the unique opportunity to talk about this from face to face.
I'm very sorry, Andreas, for all the work that you put into this, but please understand that we mustn't rush such a radical change into KMail without giving it a lot of thought.
For KDE 3.2 we primarily have to concentrate on making Kontact a full-featured and rock-stable Kolab client because that's what the corporate users need. LinuxTag showed that a lot of people are waiting for Kontact because without a working Outlook/Exchange replacement it's impossible for them to even think about migrating from Windows to Linux.
And then... Don Sanders replied:
If you (Ingo) and Marc object to Andreas' patch, Zack and I support it and Carsten has no comment then effectively that's a deadlock according to the KMail decision making process.
In which case I'm ok with leaving the decision as to whether to commit the patch or not up to Andreas himself. Andreas has been contributing to KMail for a long time and I trust him to make changes without breaking things. I also doubt he has any intention to rush things.
Whether or not Andreas get to make the decision I think it's a good idea for people to voice any technical objections on the list. So far I'm not aware of any outstanding technical objections. I believe Andreas isn't scheduled to attend Nove Hrady so since he's the one doing the coding it does make sense to voice objections on the list, where he can read them.
To recap the basic idea of the patch is to work towards creating a KMail client library that can be used by other apps to create composer/message view/message list view/mail widgets in that apps process space. Other generally useful mail services could also be implemented in the client library.
Except when running KMail standalone, this client library would communicate with the KMail server/kernel via a KMail dcop interface. This interface would provide general mail services that other KDE applications could also use, but this interface would be subject to change without notice and hence would not initially be part of the standard KDE API.
When running KMail standalone the client library could directly call kernel methods rather than using the dcop interface this would avoid dcop complicating the KMail debugging process.
At least that's my understanding of the approach. Ultimately if Andreas is to be trusted with implementing this change then I believe he should also be trusted to make the final decision on how the code should be written.
To which Andreas replied (indirectly):
Okay, what have I done so far? I've provided two kind of prototypes realizing two very different approaches for the UI separation. Technical details can get read from my various posts to the list. Both approaches are possible in general, they can even get combined. However, they are bound to different aspects of what target should be reached. My first approach was about having two diffent UIs (text and current GUI). The DCOP approach came into play to allow 3rd party applications (in the style of e.g. KOrganizer) access to some interesting functions of the KMail kernel. The problem there is, that within the kernel you can find some GUI releated code (like KMessageBox calls), which are a problem when you work from a text UI. This is addressed by my second patch.
I recommend to think over the targets to be worked for before any further technical discussion continues. Is it to have different UIs? Is it to allow many other applications (perhaps still unknown today) to interact with KMail's core? Is it "only" a cleanup to separate core and UI code in the current codebase?
If I can convince somebody to sponsor my trip (I'm working on it, but the chances are low) then I would like to attend. (Is there any deadline to register?)
However, the developer meeting will be successfull anyway - with or without me. And I'm sure, that a good way will be found for the UI separation process. If that's done carefully, why shouldn't it begin even in KDE 3.2?
Carsten Burghart replied:
Probably all 3 of them should be considered. Personally speaking I think we should start cleaning up the codebase by cleaning up UI and processing code. This can be started in 3.2.
If you look at kontact the most important thing about this separation is probably that it makes an integration in other apps is easier. We regularly get bug reports (wishes) to support other guis for kmail but I consider this only a sideeffect.
I strongly vote for not mixing up things too badly for 3.2 as the risk for bugs is too high.
To which Don Sanders again replied:
I think this is possibly a way forward.
Regardless of whether DCOP is used or not there seems to be a common desire to partition KMail into processing and UI code spaces.
Assuming the processing code is basically the same as the kernel/server code space idea and the UI code is basically the same as the client code space idea, and that cleaning up includes separating the processing/UI code then I think this is sensible longer term goal.
Futhermore I think there is work towards this longer term goal that can be started now. Especially if Andreas has time available to contribute now then I think it makes sense to use this resource rather than telling him to delay for yet another month. (Last patch was sent on 20-June)
More specifically I'm thinking that Andreas' KMailClient class makes sense whether or not DCOP is used. Perhaps Andreas could consider creating a non DCOP version of his patch, and adding a global KMailClient *kmclient variable to KMail. This kmclient variable would act as the dual of kmkernel. kmclient would be used within kernel space (e.g. KMFolder*) whenever gui stuff needs to be done. There's the kmbroadcaststatus issue for instance that I mentioned, maybe this could just be solved by replacing direct calls to kmbroadcaststatus in the kernel with calls to kmclient->broadCastStatus()->method(args). So in general proxy UI class in kernel space through kmclient. (This would include stuff like creating a composer in kmkernel). Also later on further work could be done in investigating what else needs to be done in order to get kmkernel and kmclient running in separate processes.
Andreas' what do you think of this idea? Does it make any sense?
Ingo, Carsten, Zack, (I've given up on Marc) do you think a workable solution (submittable patch) could be found that initially doesn't use DCOP? Eventually to get the client and server classes running in different spaces we would have to use something like DCOP, and eventually KMClient could be put in a library. Once in a library KMClient functionality like creating a composer etc would be exposed to other Kontact/kdepim apps like KAddressBook and then when stable would be available for all KDE apps.
The reason why I would like to work on this now rather than waiting for Nove Hrady is that it's easy to sit around and discuss design in a committee. The hard part is actually trying to get the ideas implemented and working in code, that's the frustrating part when our mental model or the code collides with reality and the real problems become apparent. If Andreas is able to put time into doing this hard work now, then I think it makes sense to capitalize on this opportunity rather than squander it, and risk discouraging him.
But in another context, Marc Mutz (who apparently has found some time for doing something other than trying to convince his mother that Kroupware... oh forget it), said:
First of all: I'd very much welcome work from anyone to refactor KMail to have a decent MVC-like design and I wouldn't mind adding _some_ _general_ (_C++_) interfaces for that. In fact, I'd probably also start with making an interface for the status bar service that the main window provides, however, it would be KMail-internal, called StatusBar and KMMainWindow would implement it in terms of it's KStatusBar.
So I'm mainly opposing the split of KMail into a server and a client. That's opening a can of worms w.r.t.:
1. Compatibility of the on-the-wire format: who here can guarantee that you keep the protocol stable for at least three years, which is the minimum update interval for companies? Think back where KMail was three(!) years ago. Do you want to keep interfaces that old? Now that KMail slowly starts to get a decent internal design again? Do you want to maintain the forwards- and backwards compatibility layers that are necessary that KMail/Home can work with a two-years-old KMail/Work? If not, then I'd suggest we forget this idea again. Don knows this, which is why he wrote:
On Friday 11 July 2003 09:22, Don Sanders wrote:
> Could you please add a note to clientIface.h stating:
> "KMailClientInterface is subject to change without notice and
> not yet part of the standard KDE API."
> This is to avoid the need to keep backwards compatibility with third
> parties, and make sure that we are free to change this API at will.
> Initially I would like to restrict the use of this interface to
But that's not going to work out since the problem is not cross-module compatibility, but cross-version compat (see above). The "third party" here is KMail 1.8!
2. Distributed systems: I don't know about you, but I find debugging multi-threaded and otherwise concurrent or distributed applications a real horror. If neither you nor a decent percentage of other KMail developers have any real-world experience with this, I'd suggest we forget this idea again.
All this "kmail server" - sorry - nonsense is just trying to work around KMail's inability to have decent locking and new-mail-detection for ~/Mail and other stuff. But instead of fixing _that_, removing business logic from GUI classes and splitting off a libkmailcore.so that a KDE and a curses front-end could link against and instead of getting KMail's immense appetite for memory under control, the advocates of this proprietory IMAP replacement just try to fix the symptoms.</rant>
What I've heard as arguments of LT2k3 pro the client-server design was exactly that:
1. Multiple KMail instances'd take too much RAM. 2. KMail wouldn't like other instances accessing it's index files.
Are there more arguments for a client-server "design" than those? Funny thing is that everyone (correct me if I'm wrong) that I talked to there about this now seems to agree that this would just be a a masturbation in distributed computing.
Another thing: KMail interfaces don't help KDE as a whole a lot. Small, task-oriented interfaces such as those that David, Danimo, et al. came up with for Kontact do, since they stand a chance of being implemented by other KDE MUAs (you know that there are two others? ;-)). If a method's signature contains (..,Q_UINT32 sernum,...), then it's completely worthless.
OTOH, linking to a kmailcore.so is cheap on the resources, forces a business logic/UI separation just as well (if not better) and in addition forces us to make KMail robust w.r.t. "external" accesses in ~/Mail and memory usage. Furthermore, this allows programs such a KOrg to send emails (invitations) without a running KMail instance. KDE apps don't need a running instance of Konq to access http or ftp URLs, now do they? They don't need a running kaddressbook to access the addressbook, they don't need a running KOrg to parse iCal, they don't need a running Konq to display HTML pages. Why the heck should KMail be so special that all these examples don't hold for it?
 That's the common term for what Don calls "kernel code", something that is but a KMail-ism uncomprehensible to anyone but KMail developers.
To which Martin Konold replied:
> the advocates of > this proprietory IMAP replacement just try to fix the symptoms.
I think that this is the strongest argument against this c/s idea! if you want to seperate the storage from the GUI use IMAP but dont invent another protocol!
If you want different clients to concurrently access the mail storage use IMAP.....
IMHO the current proposal is completeley overengineered and reinventing the wheel.
To which Don Sanders again replied:
The problem with this suggestion is that even for IMAP KMail needs a local representation of what's on the server. eg. dimap uses a maildir representation.
We want to allow multiple clients to access this local representation. Thus we have a case of multiple processes (one for each client) accessing a shared resource (the local representation) and hence we need a mechanism to manage access to that resource.
I know of two approaches to solve this problem, the first is to use a single server process to manage access. The second is to make every client a server and create a peer-peer network.
The proponents of the serverless model don't seem to fully understand the complexities of managing shared access to a resource. I covered some of those overlooked complexities in my latest mail to Marc.
To which Martin replied:
No, this is not an issue at all. By definition dimap uses a _private_ local cache. No external program is under any circumstances allowed to make any use (reading or writing) of this cache. The fact that the current code uses the maildir format is completly irrelevant here. dimap could also have been implemented using some object serialization method. Maildir was simply chosen because it is a reliable and performant data structure to store mail data on disk.
4. Konqueror Delete Unification
13 Jul 2003 - 24 Jul 2003 (70 posts) Archive Link: "Konqueror Delete Unification"
People: David Hugh-Jones
David Hugh-Jones said:
For the user:
* removes "shred" entirelybb
* removes "trash" from the RMB
* creates a new delete action which is called by "delete" on the RMB and the default delete keyboard shortcut.
* alters konqueror's config dialog to let you configure delete to store files in the trash:
- only for local files
* konqueror automatically asks if you want to trash a remote file the first time you try to; if you opt just to delete it, and check "don't ask again", it alters your setting.
* retains "trash" and "really delete" as keyboard shortcuts. But see below for my problems with this!
Usability people: I would welcome feedback on this. It is mainly as discussed on the lists. However, there are some changes.
(1) Instead of having two "user visible actions", trash and delete, I decided only to talk about delete, and whether delete "stores a copy in the trash". This has some advantages:
* emphasis on deleting the file, rather than "moving it to the trash" - which chimes more with what users want to do.
* no need to find a description for the "default delete action which can be delete or trash"
It also has disadvantages (doesn't differentiate btw actions; how do you now describe "real delete"?) I considered adding code to change the icon (but not the "delete" text) dynamically depending on whether delete would store a copy in the trash. This would be a useful hint, but it adds to the complexity of an already very long file in konq_mainwindow.cc. So I've left it for the moment.
(2) I've also only got one "confirm delete" option, rather than separate ones for "trash" and "delete". Talking about one action not two sort of goes with this. If you force a real delete, you have to confirm. (If you don't want to confirm your real deletes, you can set them as the default and force trashes instead.)
kfm-devel people: help! I am new to C++. I have a problem: I want the konqueror browser extension defined in konq_dirpart to provide different actions from the kparts/browserextension, so that I can ditch shred without breaking kdelibs binary compatibility. So, I refactored kparts/browserextension to call a protected method called insertSlotsIntoMap(). Then I wrote a different implementation for konq_dirpart. BUT: this never seems to get called. The functions are static: am I misunderstanding how C++ inheritance works?
The end result is that you get a lot of "action doesn't exist" warnings from the browserextension and konq_mainwindow, and the "forcedel" and "forcetrash" actions don't work - unless, bizarrely, you change views a couple of times (from e.g. icon view to list view).
Help and solutions for this would be much appreciated.
There is one other tiny bug - at the moment the QWhatsThis for the delete action doesn't tell you the keyboard shortcuts for forcedel and forcetrash.
(There is also one other thing the patch does - removes the "go to weird ass places" options from the Go menu. See the XML usability report for why. This just sort of got bundled.)
This took longer than I naively expected. Right now I am locked out of CVS kde because kdm has stopped accepting my login - the final indignity :-) Apologies if the patch is not up to scratch.
There were many, many, many responses, and each one seemed to advocate a different idea, so the reader is encouraged to read the thread for him/her self. There are just too many opinions to summarize here. (Hence why kde-usability threads are a pain to cover :)
5. new kinfocenter firewire module
15 Jul 2003 - 17 Jul 2003 (5 posts) Archive Link: "Announce: new kinfocenter firewire module"
People: Alexander Neundorf
Alexander Neundorf asked:
since I didn't get much response on kde-devel, I ask here:
I wrote a small kinfocenter module, which shows some information about all connected firewire devices.
You can get the sources from http://www.neundorf.net/src/view1394.tar.bz2 It uses libraw1394, so it is linux-only. It consists of only approx. 250 lines of code, so that I don't think abstracting anything to make it portable to other platforms makes sense.
Is there a place for it in cvs ? kdebase, kdeaddons, the extragear ?
Are the any issues with using the word "firewire" ? Should I change it to "IEEE1394" ?
There was a little heming and hawing but from what I could see the eventual concensus was that it's not ideal to have an architecturally specific module but it'll do. And it was also pointed out that firewire is a trademark of Apple Computer, and thus should use IEEE1394.
6. New action: move to next unread message or folder
16 Jul 2003 - 19 Jul 2003 (9 posts) Archive Link: "New action: move to next unread message or folder"
People: David Smith
David Smith said:
I just started to use KMail and this is a feature I was missing. An action that sort of combines "Next unread message" and "Next unread text", that is, goes to the next unread message but continues to the next folder.
I called the action "Next unread message or folder" with default key SHIFT++. What do you think?
Responses stated that it would be better as a configurable option for next message. David provided an amended patch, which was committed.
7. Take Addresses feature for kmail
16 Jul 2003 (4 posts) Archive Link: "Implemented a new feature for KMail, please review"
People: Arnaud Burlet
Arnaud Burlet said:
I implemented in KMail a way to take multiple email addresses from multiple messages and add them to the address book with only few mouse clicks...
For an illustrated description please see http://www.realness.ch/~sts/kmail/
The code is not yet finished, but as a total C++, QT, KDE, KMail newbie I need advices from other people. So can someone please review my work ? And talk back to me either on the list or privatly (I prefer privately not to flood the list with my questions ...).
I will stop here for now, but of course I'll precise things when you ask it.
I attach an archive with a diff against the kdepim repository, and my 2 source files which should go in kmail sources directory.
The feedback suggested changes to the patch, and there was a lot of it.
8. KDE i18n HOWTO updated
17 Jul 2003 - 19 Jul 2003 (8 posts) Archive Link: "KDE i18n HOWTO updated"
People: Lukas Tinkl
Lukas Tinkl said:
based on feedback (and rants :) from several KDE people, I updated the KDE i18n HOWTO. Please take some time and read how to develop international KDE applications properly.
Some pieces are still missing, I'm looking forward to your feedback and comments.
9. new KDE Development book
17 Jul 2003 - 22 Jul 2003 (53 posts) Archive Link: "new KDE Development book"
People: Ralf Nolden, Andre Somers, Guillaume Laurent
The inevitable Ralf Nolden said:
I'll now proceed in writing a new KDE development book. Mainly because the old KDE 2 development book sucks in certain kind of ways and through the experience of participating on that book having to use DOC format and other things, I'll start basically from scratch. Any help in proof-reading and later in translation is very welcome. Example code is also nice to have :-)
As I haven't taken care of any publisher who'll do hard prints I guess that'll come over time. The License for the book will be the GNU Free Documentation License, which is because my manuals in KDevelop were GPL licensed and I had to buy myself a hard copy of my own work. Which sucked as well :-)
So, target is: FDL-licensed book that can be published on developer.kde.org, covering:
- C++ - Qt 3.2 - KDE 3.2 - KDE/Qt development tools, debugging - KDE/Qt translation tools - writing DocBook manuals
Specifically the book will cover KDevelop 3 as well as one big chunk of it so we can reuse the book for the KDevelop manuals and ship it with KDevelop directly (even though the debian package for the book will end up in non-free, see recent discussions about the FDL).
For the book to come forward, I'll use docbook myself and I would like to re-use Lauri's docbook manuals on how to write good documentation. The question is: where to put the docbook files so we have a buildsystem around it and can have anyone participate in writing it so we can use CVS plus when certain chapters are finished translators can translate it, and how we get it published directly during the process of writing it on developer.kde.org so anyone can review the book and send in patches ?
If you have any ideas, let me know.
One thread dealt with licencing issues. Then Andre Somers said:
And Guillaume Laurent said:
I was about the say the same. C++ is simply too large a language for it to be dealt with in a few pages. What might be useful, though, is to talk about Qt's C++ idioms : QTL in relation to STL, QObject's parent/child ownership, classes with value (QString, QList) and ptr based (QObject) semantics and how they're handled differently...
To which Ralf Nolden responded:
Exactly :-) As written earlier, I want to explain/teach C++ programming with Qt/KDE, so C++ is explained directly with what one needs - even if you have no programming knowledge about C++ at all. It's all about practical programming with background explanation.
To which Guillaume Laurent said:
I honestly don't think that can work. C++, even coated with Qt, is not suitable as a first language. I think you'd be safer assuming the reader has prior knowledge of C++ (even a basic one), and taking him from there.
Of course, then someone just HAD to suggest using python instead, which was (ed: thankfully) shot down.
10. KDE Man Page Generator
18 Jul 2003 - 23 Jul 2003 (53 posts) Archive Link: "KDE man page generator.."
People: Dominique Devriese
Dominique Devriese wrote:
In order to fix long-standing Debian bug #116485, I've written a script that takes a KDE app, and generates a nice man page.. It uses the app's "--author" and "--help-all" output, along with a description from Debian's control file to get the data. I think the script works great, the man pages look almost hand-written ;) I encourage you all to try this out, and very much welcome any feedback, especially as to how to integrate this into either the Debian KDE packaging system or the KDE build system..
The idea to do this with a script allows us to easily keep the man pages up to date, and is generally very low-trouble for the developer...
The script is attached at the bottom..
USAGE: Suppose you wanted to generate a man page for the KDE-Edu program kalzium.. Then you would
1 cd to /path/to/kde/srcs/kdeedu/debian ( necessary so the script finds the Debian control file.. )
2 run "/path/to/kdemangen.pl $(which kstars) > kstars.1"
3 run "cat kstars.1 | groff -man -Tascii | less" to check out the generated page..
1 Only works for full KDE applications that use KCmdLineArgs ( inherent to my approach, but most KDE apps fulfill this requirement )
2 I can't seem to find a way to make the applications *not* output translated stuff.. I've tried with "KDE_LANG=C $runapp ..", but to no avail.. I'm prolly just missing something stupid here..
FUTURE: I'm thinking about some way to integrate this into either the Debian KDE packaging system, the KDE build system. I might also upload it to kdesdk/scripts/.. I would very much appreciate feedback here !!
As for the dependency on the debian control file, I'm thinking about removing this, and letting the user provide the description as a command line option, so that the debian folks can still give the description from the control file if they would want that..
STYLE: Don't complain about my perl style, I know I suck at it ;)
Response (including the obligatory disclaimer that I wrote a thank-you) was very favorable.
Sharon And Joy
Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.