Hey Fuckhead,

How long has this been the most requested feature? Get off your ass and get it done. And please refrain from sending ME your trifling criticisms.

I've created a new wiki document entitled "Adding KDevelop Projects to the KDE CVS Repository". View it here:

http://kde.ground.cz/tiki-index.php?page=Adding+KDevelop+Projects+to+the+KDE+CVS+Repository

Eventually, this document will be incorporated into the KDevelop/doc tree. Please take a look at it. You can either edit the wiki directly, or if you don't want to create a wiki account, e-mail me directly or post comments in this mailing list.

The following are known issues:

1. I haven't addressed application documentation yet. If someone wants to take a shot at that...

2. I'm not sure about configure.in.in. Commit to the CVS repository or not?

3. The article addresses applications created using KDevelop 3.x. I don't know if the technique would work for KDevelop 2.x applications. Since KDevelop 3.x will be the "standard" with the release of KDE 3.2...

4. Does anyone know if the inst-apps file works in modules other than kdenonbeta?

Thanks for your input,
Gary Cramblitt

If you are interested in programming KDE applications with something other than C++. Have a look at KJSEmbed. Its starting to get stable enough that we can build KDE components with it. As an example we have built a kicker applet that can be extended in pure ECMAScript. For more details see: http://www.kdedevelopers.org/node/view/240. Note that this is a big thing because these same techniques can be used to build KOffice, KDevelop, and Konqueror plugins in pure ECMAScript.

Now this is interesting because VS any other scripting engine, this one is native Qt/KDE all of the way down, so it is fast and very intimate with KDE. We support all widgets that you can get in Qt Designer, KParts, KIO and almost all the KImageEffect effects.

http://xmelegance.org/kjsembed/ is the main page for docs and developer information. So take it out, kick it around and see if you can find/fix a bug today.

Hi all,
Nicolas, I just built Quanta and had a quick look at Kafka. I still have to try playing with it and seeing how well it creates pages with paragraphs, headers and such. However just having a look I'm rather impressed. A few days ago it didn't seem usable. Today I noted on my first look...

1. Very fast and crisp loading a page
2. excellent rendering while showing PHP tags (using split VPL/text view)
3. PHP tag double click takes you to the PHP tag in text or highlights the area
4. double clicking successive abutted tags highlights the whole group (odd behavior)
5. clicking outside leaves the cursor
6. cursor following in text mode is very good

I have to say the last one is rather interesting even for those people who have little interest in visual design. To see something on the page that needs attention, click on it and have your cursor delivered is a very cool time saving feature. Of course we're shooting for more ;-) but it's no small victory.

I'll report back after more testing. If other people on the list would test it would be good too.

It is often quite difficult to use prelink with KDE because QT depends on libGL.so and libGL.so is often compiled as a non-PIC library for performance reasons.

The NVidia libraries are compiled this way, and I cannot recompile them in PIC mode for lack of source. Sigh.

This is frustrating because 95% of the KDE executables do not need libGL. Why not make QT load libGL when it needs it only?

The attached patch does this. It creates little stubs for all the openGL functions needed by QT. libGL.so is loaded with dlopen the first time one of these stubs is called. Otherwise the stub simply calls the required function.

Rough recipe:

• Get the qt-3.1.2 package for your distribution.
• Apply the distribution specific patches (e.g. redhat9 has a lot of them...)
• Apply the attached patch.
• Run the script 'configure' that comes with Qt with the appropriate options.
• Edit the file src/Makefile to remove -lGL from the command for linking qt.so.
• Make.

I did it on my redhat9 box by loading the fedora source rpm (qt-3.1.2-7.fdr.3.src.rpm) and modifying the spec file to apply the pactch and tweak the makefile.

Result:

	[leonb@humbert SPECS]$ LD_DEBUG=statistics konqueror
	     25895:
	     25895:     runtime linker statistics:
	     25895:       total startup time in dynamic loader: 7824120 clock cycles
	     25895:                 time needed for relocation: 2653360 clock cycles (33.9%)
	     25895:                      number of relocations: 0
	     25895:           number of relocations from cache: 1940
	     25895:                time needed to load objects: 4555144 clock cycles (58.2%)
	

P.S. --
I am talking about Jakub Jelinek's ELF prelinker, not about my old objprelink hack. It does not work with gcc-3 anyway.

Hi,
the 1.3 plan has just been changed at the usual location. Some of you probably know, I've delayed (for the last time I promise) the release due to many bugfixes made to KChart internally in KDAB. I'm just waiting now for Karl-Heinz Zimmer to merge these changes back into KOffice CVS.

It currently looks like this:
December 2, 2003
Tag KOffice 1.3 final version (KOFFICE_1_3_RELEASE), create binary packages, test the tarballs.

December 10, 2003
The source and binary packages are uploaded to ftp.kde.org to give some time for the mirrors to get them.

December 11, 2003
Create changelogs, update the website

December 12, 2003
Announce KOffice 1.3

I hope KOffice 1.3 will be a nice XMAS gift for many people. :-)

To work around bug#55657 (and its duplicate #59377), I propose to remove the file koffice/tools/thumbnail/otherofficethumbnail.desktop

The main problem of the "other office" thumbnails is that it is based on the filters. As our filters are far from bug-free, the problems of the filters are given here very raw, without having any chance not to do it. (When you know that a file crashes a filter, you do not load it, but the thumbnail will still be created. :-( )

Does that also fix the problem then when I have a .csv in my dir kspread opens a dialog asking me the table formatting? Very annoying when browsing a dir.

I think there are a couple of problems here, I doubt the buggy filters are to be blamed.

1. konqueror should do some load managing of thumbnail generation; I have seen postscrip thumbnail generation cause the same problems.
2. when a file fails to generate, for any reason at all, konq should register that and not retry the next time you enter the folder.
3. filters should by default be started in an environment that has no X connection so popups and dialogs _can_ not appear.

Disabling the .desktop file seems like a good idea; but it does not really solve the problem, it works around it.

David; I hope that if you think the above is new and worthy for the konqueror hackers that you can forward it to them :)

IMHO Some of the icons in KOffice could be prettier. Rohit Kaul has created some very attractive icons, published on KDE-Look, that I think would suit KOffice. Please see the screenshot:

http://www.kde-look.org/content/preview.php?file=7131-2.png

I'd like to propose replacing some of the existing icons with Rohit's versions, specifically the bold, italic, underlying, indent, justification, numbering and bulleted list icons.

Would anyone object if I did this? (Rohit has been BCC'd on this)

I'd consult kde-core-devel for icons that live in kdelibs.

The toolbars for the three applications in question have a magnification "thingy" but each one is different:

kdvi has [+][-][100%]
KPdf has [+][100%][-]
KGhostview has [-][100%][+]

Personally, I'd like the [-][+] icons grouped, both on one side of the combobox, but anything consistent would be ok with me. The [-] icon should be to the left of the [+] though. Should I file a bug, for this, or is this message enough?

As you might have noticed the behavior of KMail when using Reply has changed since KDE 3.1. The current KMail tries to address the reply to the original sender of the message if Reply is used even for mailing-lists which set the Reply-to header. Of course this only works if KMail can figure out the mailing-list address and therefore can ignore it in case it's present in the Reply-to header. Anyway, what I'd like to know is whether this change is usability-wise a good change or not.

The current behavior is:
Reply ('r') -> reply to the original sender
Reply to Mailing-list ('l') -> reply to the mailing-list

The old behavior was:
Reply ('r') -> reply to Reply-to address if present, else to From; in case of Reply-to mangling mailing-list (seems to be the majority nowadays) this resulted in a reply to the mailing-list
Reply to Mailing-list ('l') -> reply to the mailing-list

With the old behavior it was impossible to send a private reply without using the mouse to right-click on the sender's address (which means that's actually an accessibility problem). This is the main reason why the new behavior was introduced.

Things which should be improved after KDE 3.2:
a) Rephrase "Reply" to "Reply to Sender"
b) Replace the two Reply buttons in the toolbar with a KToolBarPopupAction which contains all three Reply actions (-> one button less on the toolbar ;-) ) similar to the Forward button. The standard behavior of this button could be Reply to Mailing-list for mailing-list messages and Reply (to Sender) for normal messages.

The question now is whether it's necessary to revert the behavior to the old behavior until the new behavior is improved like above. The only valid reason for this is that probably many users always used Reply in case they wanted to reply to a mailing-list and that this worked for them up to now. A few people complained about this on kmail@kde.org and kde-pim@kde.org and there were also already 1 or 2 bugs reports about this. Of course, only those people complain that don't like the change. Those who like the new much more logical behavior don't speak up. Therefore I'd like to know what the usability team thinks about this.