From bogus@does.not.exist.com  Tue Mar 18 03:57:02 2008
From: bogus@does.not.exist.com ()
Date: Tue, 18 Mar 2008 02:57:02 -0000
Subject: No subject
Message-ID: <mailman.0.1205809108.5180.kde-windows@kde.org>

> Ok, maybe you should have a look again into the directory
> %KDEROOT%\manifest. The files in there state which packages you have
> installed. If you remove all files there, then emerge should behave
> differently.
> Please have a look again that the 'installed' file is empty as well.
> and then instead of 'emerge kdesdk' you can run as well
> 'emerge -v -v kdesdk'. (That switches on debug output.)
>
> SE
>

------=_Part_2619_11998816.1199839789060
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hello,<br><br>The file C:\kderoot\etc\portage\installed is 0 bytes long.<br>I had deleted the &#39;manifest&#39; folder, so I recreated it, empty.&nbsp; Tried the build, still the same.&nbsp; <br>I ran &#39;emerge -v -v kdesdk&#39;.&nbsp; The only thing that looks suspicious to me in the output is that there are many lines that say
<br>emerge doExec called opts: []<br>In fact there is no &#39;emerge doExec called opts:&#39; line that has anything in the square brackets [].<br>Does this help?&nbsp; I can send the full output of the &#39;emerge -v -v kdesdk&#39; command, but it&#39;s very long...
<br><br>Thanks,<br>Clint<br><br>From Saro Engels:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Ok, maybe you should have a look again into the directory
<br>%KDEROOT%\manifest. The files in there state which packages you have<br>installed. If you remove all files there, then emerge should behave<br>differently.<br>Please have a look again that the &#39;installed&#39; file is empty as well.
<br>and then instead of &#39;emerge kdesdk&#39; you can run as well<br>&#39;emerge -v -v kdesdk&#39;. (That switches on debug output.)<br><br><font color="#888888">SE<br></font></blockquote></div><br>

------=_Part_2619_11998816.1199839789060--


From bogus@does.not.exist.com  Tue Mar 18 03:57:02 2008
From: bogus@does.not.exist.com ()
Date: Tue, 18 Mar 2008 02:57:02 -0000
Subject: No subject
Message-ID: <mailman.1.1205809123.5180.kde-windows@kde.org>

remains valid (i.e. the KUrl ctor has to be adapted too probably). But I
don't exactly know what the kde windows guys (jstaniek iirc?) have done
already...

I'd be very happy to do the legwork in the implementation of this
enhancement if no one else is on it or if no one has any objections in me
doing so.

I suppose that what I need at this point is an approver to whom I can
present any changes I make to the code in the area touched by the resolution
of this issue.

I'll be standing by until a consensus has emerged from the various players
involved.

Regards,

Michael

------=_Part_5021_27415200.1203808005057
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

People,<br><br>I have been looking into <a href="http://bugs.kde.org/show_bug.cgi?id=156159">http://bugs.kde.org/show_bug.cgi?id=156159</a> (Dolphin for Windows has path handling problems) along with Peter Penz.<br><br>We&#39;ve been seeking permission / approval by various stakeholders to make a patch to KUrl among other classes. This has led us to talk with David Faure and then Jaroslaw Staniek who recommended that we&nbsp; take it to the kde-windows mailing list.<br>
<br>David Faure&#39;s analysis of the issue is as follows : <br><blockquote>From a quick look at the mail it would seem to me that it can mostly be done inside KUrl::prettyUrl() as long as the KUrl( u.prettyUrl() ) == u principle remains valid (i.e. the KUrl ctor has to be adapted too probably). But I don&#39;t exactly know what the kde windows guys (jstaniek iirc?) have done already...<br>
</blockquote>I&#39;d be very happy to do the legwork in the implementation of this enhancement if no one else is on it or if no one has any objections in me doing so.<br><br>I suppose that what I need at this point is an approver to whom I can present any changes I make to the code in the area touched by the resolution of this issue.<br>
<br>I&#39;ll be standing by until a consensus has emerged from the various players involved.<br><br>Regards,<br><br>Michael<br>

------=_Part_5021_27415200.1203808005057--


From js at iidea.pl  Sun Mar  2 17:02:35 2008
From: js at iidea.pl (=?UTF-8?B?SmFyb3PFgmF3IFN0YW5pZWs=?=)
Date: Sun, 02 Mar 2008 17:02:35 +0100
Subject: [patch] a (temp?) fix for unexpected behaviour of
	KService::createInstance() on Windows
Message-ID: <47CACF9B.1030306@iidea.pl>


Attached a (temp?) patch for unexpected behaviour of 
KService::createInstance() on Windows.

The problem was that the lines:

  KPluginLoader pluginLoader(*this);
  KPluginFactory *factory = pluginLoader.factory();

resulted with factory==0 for the first call, while another call worked well.
People reported that on various windows (xp, vista) and builds (msvc, mingw).
It was also possible that you execute an app for the first time, and 
factory==0 (thus plugins, say, in KDE-PIM refused to load), then execute the 
app again and factory is !=0.

This is all I can have as a temporary solution for now. Feel free to improve - 
hopefully at KPluginLoader level itself. I wasn't able to fix at KPluginLoader 
inherits directly from QPluginLoader, so the ctor itself would have to be 
executed twice...

-- 
regards / pozdrawiam, Jaroslaw Staniek
  Sponsored by OpenOffice Polska (http://www.openoffice.com.pl/en) to work on
  Kexi & KOffice (http://www.kexi.pl/en, http://www.koffice.org/kexi)
  KDE Libraries for MS Windows (http://windows.kde.org)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: kservice.patch
Url: http://mail.kde.org/pipermail/kde-windows/attachments/20080302/dd750337/attachment.ksh 

From Ch.Ehrlicher at gmx.de  Sun Mar  2 18:35:35 2008
From: Ch.Ehrlicher at gmx.de (Christian Ehrlicher)
Date: Sun, 02 Mar 2008 18:35:35 +0100
Subject: qt-4.4.0.20080222 build problem
In-Reply-To: <47C3EE53.2010205@freenet.de>
References: <47C3EE53.2010205@freenet.de>
Message-ID: <47CAE567.2080700@gmx.de>

Ralf Habacker schrieb:
> Hi,
> 
> qt-4.4.0.20080222 has a doc packages problem. assistant does not find 
> any doc.
> 
> I used emerge to compile and install qt and saw that in 
> <emerge-root>tmp\qt-4.4.0.20080222\image-msvc2005/doc only the images 
> are located.
> To create the qt docs there this a special target 'docs' required. 
> Unfortunally it looks that there is no target for installing the doc 
> (subdirectory doc/pch).
> When I copy 
> <emerge-root>\tmp\qt-4.4.0.20080222\work\qt-win-opensource-src-msvc2005/doc/pch 
> into <emerge-root>\doc assistant is able to list the docs.
> 
I investigated a little bit and found out that doc generation changed in 
4.4.
The html documentation is now created on build-time. In current qt-copy 
this isn't enabled, but I saw it in the snapshot releases.

-> It'll be fixed when qt-copy is updated to 4.4.0 (or even 4.4.0beta)


Christian


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 258 bytes
Desc: OpenPGP digital signature
Url : http://mail.kde.org/pipermail/kde-windows/attachments/20080302/3cf92dc2/attachment.pgp 

From js at iidea.pl  Sun Mar  2 18:39:58 2008
From: js at iidea.pl (=?UTF-8?B?SmFyb3PFgmF3IFN0YW5pZWs=?=)
Date: Sun, 02 Mar 2008 18:39:58 +0100
Subject: [patch] KWindowSystem on Windows
Message-ID: <47CAE66E.60307@iidea.pl>


For review.
Addes some implementation of KWindowSystem::setState() 
KWindowSystem::clearState() and some notes on possible future improvements.

This makes KNotes nicely stay-on-top almost with no #ifdefs./

affected setState() behaviour:

NET::Max now shows the window with SW_SHOWMAXIMIZED flag,
NET::KeepAbove sets window pos with HWND_TOPMOST
NET::Hidden hides the window
NET::FullScreen resizes the window tothe size of the screen
NET::KeepBelow calls KWindowSystem::lowerWindow()
NET::DemandsAttention calls KWindowSystem::demandAttention()
  with 2nd arg==true

affected clearState() behaviour:

NET::Max shows the window using SW_SHOWNORMAL flag
NET::KeepAbove shows with HWND_NOTOPMOST flag
NET::KeepBelow calls KWindowSystem::raiseWindow()
NET::DemandsAttention calls KWindowSystem::demandAttention()
  with 2nd arg==false

-- 
regards / pozdrawiam, Jaroslaw Staniek
  Sponsored by OpenOffice Polska (http://www.openoffice.com.pl/en) to work on
  Kexi & KOffice (http://www.kexi.pl/en, http://www.koffice.org/kexi)
  KDE Libraries for MS Windows (http://windows.kde.org)


From js at iidea.pl  Sun Mar  2 19:08:47 2008
From: js at iidea.pl (=?UTF-8?B?SmFyb3PFgmF3IFN0YW5pZWs=?=)
Date: Sun, 02 Mar 2008 19:08:47 +0100
Subject: [patch] KWindowSystem on Windows
In-Reply-To: <47CAE66E.60307@iidea.pl>
References: <47CAE66E.60307@iidea.pl>
Message-ID: <47CAED2F.3040705@iidea.pl>


missing attachement

-- 
regards / pozdrawiam, Jaroslaw Staniek
  Sponsored by OpenOffice Polska (http://www.openoffice.com.pl/en) to work on
  Kexi & KOffice (http://www.kexi.pl/en, http://www.koffice.org/kexi)
  KDE Libraries for MS Windows (http://windows.kde.org)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: kwindowsystem_win.patch
Url: http://mail.kde.org/pipermail/kde-windows/attachments/20080302/9a292835/attachment.ksh 

From ralf.habacker at freenet.de  Sun Mar  2 20:32:30 2008
From: ralf.habacker at freenet.de (Ralf Habacker)
Date: Sun, 02 Mar 2008 20:32:30 +0100
Subject: [patch] KWindowSystem on Windows
In-Reply-To: <47CAE66E.60307@iidea.pl>
References: <47CAE66E.60307@iidea.pl>
Message-ID: <47CB00CE.7010008@freenet.de>

Jaros?aw Staniek schrieb:
>
> For review.
> Addes some implementation of KWindowSystem::setState() 
> KWindowSystem::clearState() and some notes on possible future 
> improvements.
>
how is this related with restoring windows position implemented in 
kdeui/widgets/kmainwindow.cpp - Restoring window position may override this

Ralf



From kevin.kofler at chello.at  Mon Mar  3 09:22:06 2008
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Mon, 3 Mar 2008 09:22:06 +0100
Subject: activateWindow, forceActiveWindow
Message-ID: <200803030922.06505.kevin.kofler@chello.at>

Hi,

I believe the current implementations of activateWindow and forceActiveWindow 
in kwindowsystem_win.cpp don't implement the same semantics as their X11 
versions. The issue is that SetActiveWindow only works within a thread (in 
particular, only in the same application), whereas on X11, 
KWindowSystem::activateWindow works just fine across applications. Moreover, 
forceActiveWindow doesn't really force the active window, i.e. bypass focus 
steal prevention, as it's supposed to.

I believe it would be more compliant to have activateWindow call 
SetForegroundWindow( win ); (is calling SetActiveWindow first really 
necessary?) and forceActiveWindow use some hack like 
http://vb.mvps.org/articles/ap199902.pdf (I've also seen some other hacks, 
like sending a fake user input event to the window to activate, but I can't 
find them now.)

I can't test this though (only running GNU/Linux these days).

        Kevin Kofler


From js at iidea.pl  Mon Mar  3 09:34:09 2008
From: js at iidea.pl (=?UTF-8?B?SmFyb3PFgmF3IFN0YW5pZWs=?=)
Date: Mon, 03 Mar 2008 09:34:09 +0100
Subject: activateWindow, forceActiveWindow
In-Reply-To: <200803030922.06505.kevin.kofler@chello.at>
References: <200803030922.06505.kevin.kofler@chello.at>
Message-ID: <47CBB801.8010008@iidea.pl>

Kevin Kofler said the following, On 2008-03-03 09:22:
> Hi,
> 
> I believe the current implementations of activateWindow and forceActiveWindow 
> in kwindowsystem_win.cpp don't implement the same semantics as their X11 
> versions. The issue is that SetActiveWindow only works within a thread (in 
> particular, only in the same application), whereas on X11, 
> KWindowSystem::activateWindow works just fine across applications. Moreover, 
> forceActiveWindow doesn't really force the active window, i.e. bypass focus 
> steal prevention, as it's supposed to.
> 
> I believe it would be more compliant to have activateWindow call 
> SetForegroundWindow( win ); (is calling SetActiveWindow first really 
> necessary?) and forceActiveWindow use some hack like 
> http://vb.mvps.org/articles/ap199902.pdf (I've also seen some other hacks, 
> like sending a fake user input event to the window to activate, but I can't 
> find them now.)
> 
> I can't test this though (only running GNU/Linux these days).

Thanks Kevin, I'll try to look at this once again. Feel free to send more 
ideas like these if you find something.

-- 
regards / pozdrawiam, Jaroslaw Staniek
  Sponsored by OpenOffice Polska (http://www.openoffice.com.pl/en) to work on
  Kexi & KOffice (http://www.kexi.pl/en, http://www.koffice.org/kexi)
  KDE Libraries for MS Windows (http://windows.kde.org)


From frank at kdab.net  Tue Mar  4 19:01:02 2008
From: frank at kdab.net (Frank Osterfeld)
Date: Tue, 4 Mar 2008 19:01:02 +0100
Subject: activateWindow, forceActiveWindow
In-Reply-To: <200803030922.06505.kevin.kofler@chello.at>
References: <200803030922.06505.kevin.kofler@chello.at>
Message-ID: <200803041901.02987.frank@kdab.net>

On Monday 03 March 2008 09:22:06 Kevin Kofler wrote:
> Hi,
>
> I believe the current implementations of activateWindow and
> forceActiveWindow in kwindowsystem_win.cpp don't implement the same
> semantics as their X11 versions. The issue is that SetActiveWindow only
> works within a thread (in particular, only in the same application),
> whereas on X11,
> KWindowSystem::activateWindow works just fine across applications.
> Moreover, forceActiveWindow doesn't really force the active window, i.e.
> bypass focus steal prevention, as it's supposed to.
>
> I believe it would be more compliant to have activateWindow call
> SetForegroundWindow( win ); (is calling SetActiveWindow first really
> necessary?) and forceActiveWindow use some hack like
> http://vb.mvps.org/articles/ap199902.pdf (I've also seen some other hacks,
> like sending a fake user input event to the window to activate, but I can't
> find them now.)

SetForegroundWindow() from an application in the background only works when 
AllowSetForeground() was called by the currently active application.
For Kleopatra, we have the problem that we must force a window to be in the 
foreground while another application is active (The client of kleopatra, 
Outlook or the Explorer in this case). We made the client plugins (which we 
control) call AllowSetForeground() before triggering the operation in 
kleopatra. The SetForegroundWindow() call in kleopatra works then (and only 
then). But that's a special case of course and doesn't help in general.

-- 
Frank Osterfeld -- frank at kdab.net
Klar?lvdalens Datakonsult AB, Platform-independent software solutions


From michael.a.oshea at gmail.com  Wed Mar  5 17:09:15 2008
From: michael.a.oshea at gmail.com (Michael O'Shea)
Date: Wed, 5 Mar 2008 17:09:15 +0100
Subject: Can't build a fully debug version of kurltest.exe
Message-ID: <d323dcfd0803050809k548da3e2j50ae9710bdccb1ae@mail.gmail.com>

Guys,

after doing a Debug build of kdelibs, I get a kurltest.exe which I then
analysed with Dependency Walker. What I saw is that it is linked against
QtCored4.dll (good) and various other Debug-built libraries *but* it links
against a non-Debug build of kdecore.dll (not good).

This causes problems when I try to debug kurltest.exe.

Can someone maybe help me produce a build of kurltest.exe that links against
kdecored.dll ?

Cheers !

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kde-windows/attachments/20080305/98624eea/attachment.html 

From Ch.Ehrlicher at gmx.de  Wed Mar  5 17:19:03 2008
From: Ch.Ehrlicher at gmx.de (Christian Ehrlicher)
Date: Wed, 05 Mar 2008 17:19:03 +0100
Subject: Can't build a fully debug version of kurltest.exe
In-Reply-To: <d323dcfd0803050809k548da3e2j50ae9710bdccb1ae@mail.gmail.com>
References: <d323dcfd0803050809k548da3e2j50ae9710bdccb1ae@mail.gmail.com>
Message-ID: <47CEC7F7.1080208@gmx.de>

Michael O'Shea schrieb:
> Guys,
> 
> after doing a Debug build of kdelibs, I get a kurltest.exe which I then
> analysed with Dependency Walker. What I saw is that it is linked against
> QtCored4.dll (good) and various other Debug-built libraries *but* it links
> against a non-Debug build of kdecore.dll (not good).
> 
> This causes problems when I try to debug kurltest.exe.
> 
> Can someone maybe help me produce a build of kurltest.exe that links against
> kdecored.dll ?
> 
We don't build a kdecored.dll at all. Just build your kdecore.dll/whole 
kdelibs with CMAKE_BUILD_TYPE=Debug
The same goes for all kdesupport libs needed for kdelibs.


Christian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 258 bytes
Desc: OpenPGP digital signature
Url : http://mail.kde.org/pipermail/kde-windows/attachments/20080305/d1e40871/attachment.pgp 

From ralf.habacker at freenet.de  Wed Mar  5 17:13:25 2008
From: ralf.habacker at freenet.de (Ralf Habacker)
Date: Wed, 05 Mar 2008 17:13:25 +0100
Subject: Can't build a fully debug version of kurltest.exe
In-Reply-To: <d323dcfd0803050809k548da3e2j50ae9710bdccb1ae@mail.gmail.com>
References: <d323dcfd0803050809k548da3e2j50ae9710bdccb1ae@mail.gmail.com>
Message-ID: <47CEC6A5.8080607@freenet.de>

Michael O'Shea schrieb:
> Guys,
>
> after doing a Debug build of kdelibs, I get a kurltest.exe which I 
> then analysed with Dependency Walker. What I saw is that it is linked 
> against QtCored4.dll (good) and various other Debug-built libraries 
> *but* it links against a non-Debug build of kdecore.dll (not good).
>
> This causes problems when I try to debug kurltest.exe.
>
> Can someone maybe help me produce a build of kurltest.exe that links 
> against kdecored.dll ?
kde does not use 'd' postfix for shared libraries yet.  If you are using 
emerge to build kdelibs then you should run
emerge --buildtype=Debug --update kdelibs
emerge --buildtype=Debug --qmerge kdelibs


Ralf


From ralf.habacker at freenet.de  Thu Mar  6 00:52:48 2008
From: ralf.habacker at freenet.de (Ralf Habacker)
Date: Thu, 06 Mar 2008 00:52:48 +0100
Subject: KFileDialog bug
Message-ID: <47CF3250.4070303@freenet.de>

Hi,

while testing quanta on windows I found a bug in KFileDialog using 
KFileDialog::getOpenUrls().

The bug is independend from quanta and could be reproduced with the 
appended testcase, which patches kio/kfile/tests/kfstest and requires an 
installed oxygen icon set.
After applying the path and relinking of kfstest the following command 
sequence triggers the bug:

kfstest openurls 

-> this should open a list of directories, (in my case 
c:/daten/kde/emerge-msvc-root/share/icons/oxygen/16x16)

Then enter the 'actions' directory, select an image and click open.

The selected file should be printed on the qDebug output (stderr on 
unix, DbgView on windows) In my case it returns
KUrl("file://c:/daten/kde/emerge-msvc-root/share/icons/oxygen/16x16/application-exit.png") 


which is wrong, it should contain the 'actions' directory as shown below:

KUrl("file://c:/daten/kde/emerge-msvc-root/share/icons/oxygen/16x16/actions/application-exit.png")

Ralf








-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: kio-kfile-bug.patch
Url: http://mail.kde.org/pipermail/kde-windows/attachments/20080306/1f8127d9/attachment.ksh 

From js at iidea.pl  Thu Mar  6 11:11:56 2008
From: js at iidea.pl (Jaroslaw Staniek)
Date: Thu, 06 Mar 2008 10:11:56 +0000
Subject: KDE/kdelibs/kdecore/localization [POSSIBLY UNSAFE]
Message-ID: <1204798316.186897.16905.nullmailer@svn.kde.org>

SVN commit 782853 by staniek:

Windows: fall back to system locale for l10n. 

Now it is enough to remove Country and Language from [Locale] group in kdeglobals, 
to be in sync with Windows registry settings.

Thanks to Frank for requesting this.

CCMAIL:kde-windows at kde.org
CCMAIL:frank at kdab.net




 M  +7 -1      klocale.cpp   [POSSIBLY UNSAFE: system]


--- trunk/KDE/kdelibs/kdecore/localization/klocale.cpp #782852:782853
@@ -43,6 +43,7 @@
 #include <QtGui/QPrinter>
 #include <QtCore/QFileInfo>
 #include <QtCore/QRegExp>
+#include <QtCore/QLocale>
 
 #include "kcatalog_p.h"
 #include "kglobal.h"
@@ -304,6 +305,7 @@
   list += cg.readEntry("Language", QString()).split(':');
 
   // Collect languages read from environment variables by gettext(3).
+  QStringList rawList;
   if (useEnv) {
     // Collect by same order of priority as for gettext(3).
 
@@ -317,7 +319,11 @@
     rawList += QFile::decodeName(getenv("LC_ALL"));
     rawList += QFile::decodeName(getenv("LC_MESSAGES"));
     rawList += QFile::decodeName(getenv("LANG"));
-
+  }
+#ifdef Q_WS_WIN // how about Mac?
+  rawList += QLocale::system().name(); // fall back to the system language
+#endif
+  if (useEnv) { // Collect languages  - continued...
     // Process the raw list to create possible combinations.
     foreach (const QString &ln, rawList) {
       QString lang, ctry, modf, cset;


From ralf.habacker at freenet.de  Thu Mar  6 13:42:08 2008
From: ralf.habacker at freenet.de (Ralf Habacker)
Date: Thu, 06 Mar 2008 13:42:08 +0100
Subject: 'lightweight' QDir::isAbsolutePath replacement ?
Message-ID: <47CFE6A0.1080603@freenet.de>

Hi,

there are several places in the kde code which needs a check if a path 
is absolute. On unix this is mainly done by using  
QString::startsWith('/'), which does not work as expected on windows.

The only static method Qt provides to handle this platform independent 
is QDir::isAbsolutePath(). Unfortunally this method seems to be very 
time expensive because it creates a temporary QDir instance.
A second Qt provided way is QFileInfo::isAbsolute(), although this 
method is non static and requires to create a QFileInfo instance before 
which blows up code unnecessarily.

the third option is to check this directly
    QString path = .... ;
    if ( (path.startsWith(QLatin1Char('/')) || (path[0].isLetter() && 
path[1] == QLatin1Char(':')) )
       // handle absolute Path

an additional imaginable way would be to add kde only static functions 
for this purpose in the KDE namespace. For example
    KDE::isAbsolutePath(const QString &path)
    KDE::isAbsolutePath(const QByteArray &path)
    KDE::isAbsolutePath(const KUrl &url)
    ....

with an implementation similar to:

    return (path.startsWith(QLatin1Char('/')) || (path.[0].isLetter() && 
path[1] == QLatin1Char(':')) ) ;


The question is which way the prefered is ?

Ralf






From michael.a.oshea at gmail.com  Thu Mar  6 14:02:37 2008
From: michael.a.oshea at gmail.com (Michael O'Shea)
Date: Thu, 6 Mar 2008 14:02:37 +0100
Subject: building debug version of kdecore.dll
Message-ID: <d323dcfd0803060502o1f452ef1sf071b002144849a1@mail.gmail.com>

[snip a couple of tips from other contributors]

kde does not use 'd' postfix for shared libraries yet.  If you are using
> emerge to build kdelibs then you should run
> emerge --buildtype=Debug --update kdelibs
> emerge --buildtype=Debug --qmerge kdelibs


Thanks for confirming the correct command sequence for doing a debug build
of kdelibs.

Should I conclude that getting a debug version of kdecore.dll is just not
going to happen ?

How do people debug kdecore.dll then ? Is there a procedure that I could
follow that would produce kdecored.dll ?

Any tips welcome.

Cheers,

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kde-windows/attachments/20080306/9852a67c/attachment.html 

From Ch.Ehrlicher at gmx.de  Thu Mar  6 14:10:09 2008
From: Ch.Ehrlicher at gmx.de (Christian Ehrlicher)
Date: Thu, 06 Mar 2008 14:10:09 +0100
Subject: building debug version of kdecore.dll
In-Reply-To: <d323dcfd0803060502o1f452ef1sf071b002144849a1@mail.gmail.com>
References: <d323dcfd0803060502o1f452ef1sf071b002144849a1@mail.gmail.com>
Message-ID: <20080306131009.198550@gmx.net>

> Von: "Michael O\'Shea"
> [snip a couple of tips from other contributors]
> 
> kde does not use 'd' postfix for shared libraries yet.  If you are using
> > emerge to build kdelibs then you should run
> > emerge --buildtype=Debug --update kdelibs
> > emerge --buildtype=Debug --qmerge kdelibs
> 
> 
> Thanks for confirming the correct command sequence for doing a debug build
> of kdelibs.
> 
> Should I conclude that getting a debug version of kdecore.dll is just not
> going to happen ?
> 
> How do people debug kdecore.dll then ? Is there a procedure that I could
> follow that would produce kdecored.dll ?
> 
> Any tips welcome.
> 
I don't understand your question. There *is*  a debug version of kdecore.dll when you do the above steps. It has just the same name like the release dll. So when you want to debug kde, you have to make a buildtree with --buildtype=Debug for every module.
You can also debug with the 'standard' RelWithDebInfo - it's just a little bit harder since a lot of things get optimized out (that's why I also don't like -g -O2 on linux)

Christian

-- 
Psst! Geheimtipp: Online Games kostenlos spielen bei den GMX Free Games! 
http://games.entertainment.web.de/de/entertainment/games/free


From js at iidea.pl  Thu Mar  6 15:51:09 2008
From: js at iidea.pl (=?UTF-8?B?SmFyb3PFgmF3IFN0YW5pZWs=?=)
Date: Thu, 06 Mar 2008 15:51:09 +0100
Subject: 'lightweight' QDir::isAbsolutePath replacement ?
In-Reply-To: <47CFE6A0.1080603@freenet.de>
References: <47CFE6A0.1080603@freenet.de>
Message-ID: <47D004DD.2090009@iidea.pl>

Ralf Habacker said the following, On 2008-03-06 13:42:
> Hi,
> 
> there are several places in the kde code which needs a check if a path 
> is absolute. On unix this is mainly done by using  
> QString::startsWith('/'), which does not work as expected on windows.
> 
> The only static method Qt provides to handle this platform independent 
> is QDir::isAbsolutePath(). Unfortunally this method seems to be very 
> time expensive because it creates a temporary QDir instance.
> A second Qt provided way is QFileInfo::isAbsolute(), although this 
> method is non static and requires to create a QFileInfo instance before 
> which blows up code unnecessarily.
> 
> the third option is to check this directly
>     QString path = .... ;
>     if ( (path.startsWith(QLatin1Char('/')) || (path[0].isLetter() && 
> path[1] == QLatin1Char(':')) )
>        // handle absolute Path
> 
> an additional imaginable way would be to add kde only static functions 
> for this purpose in the KDE namespace. For example
>     KDE::isAbsolutePath(const QString &path)
>     KDE::isAbsolutePath(const QByteArray &path)
>     KDE::isAbsolutePath(const KUrl &url)

I remember some stuff like that in KPath for KDE3.1/win32 :)
No idea why I cannot find one now :)

Anyway to avoid assers, the function should also have path.length() >= 2 check.

For QString I would even use code like this:

<code>
if ( path.length() < 1 )
	return false;

ushort first = path.constData()[0].unicode();

if ( first == ushort('/') )
	return true;

return path.length() >= 2
	&& path.constData()[1].unicode() == ushort(':')
	&&
	( ( first >= ushort('a') && first <= ushort('z') )
	|| ( first >= ushort('A') && first <= ushort('Z') )
	);

</code>

Re naming, the KDE:: functions look OK.

-- 
regards / pozdrawiam, Jaroslaw Staniek
  Sponsored by OpenOffice Polska (http://www.openoffice.com.pl/en) to work on
  Kexi & KOffice (http://www.kexi.pl/en, http://www.koffice.org/kexi)
  KDE Libraries for MS Windows (http://windows.kde.org)


From js at iidea.pl  Thu Mar  6 17:05:00 2008
From: js at iidea.pl (=?UTF-8?B?SmFyb3PFgmF3IFN0YW5pZWs=?=)
Date: Thu, 06 Mar 2008 17:05:00 +0100
Subject: [patch] (msvc) use more modern facilities for setenv() unsetenv()
 
Message-ID: <47D0162C.3060103@iidea.pl>

For review:

- setenv(): use secure _putenv_s() declared in msvc >= 2005 (recommended and 
apparently also used by Qt4/win); return -1 when name==0;

- unsetenv(): clear the variable using setenv(name, 0, 1) as environ is 
deprecated.

-- 
regards / pozdrawiam, Jaroslaw Staniek
  Sponsored by OpenOffice Polska (http://www.openoffice.com.pl/en) to work on
  Kexi & KOffice (http://www.kexi.pl/en, http://www.koffice.org/kexi)
  KDE Libraries for MS Windows (http://windows.kde.org)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: setenv_unsetenv.patch
Url: http://mail.kde.org/pipermail/kde-windows/attachments/20080306/b9746c8d/attachment.ksh 

From ralf.habacker at freenet.de  Thu Mar  6 19:54:41 2008
From: ralf.habacker at freenet.de (Ralf Habacker)
Date: Thu, 06 Mar 2008 19:54:41 +0100
Subject: 'lightweight' QDir::isAbsolutePath replacement ?
In-Reply-To: <47CFE6A0.1080603@freenet.de>
References: <47CFE6A0.1080603@freenet.de>
Message-ID: <47D03DF1.9050305@freenet.de>

Ralf Habacker schrieb:
> Hi,
>
> there are several places in the kde code which needs a check if a path 
> is absolute. On unix this is mainly done by using  
> QString::startsWith('/'), which does not work as expected on windows.
>
> The only static method Qt provides to handle this platform independent 
> is QDir::isAbsolutePath(). Unfortunally this method seems to be very 
> time expensive because it creates a temporary QDir instance.
One little correction: I fact QDir::isAbsolutePath() creates a QFileInfo 
instance instead of QDir but the problems still remains.

qdir.h
    static bool isRelativePath(const QString &path);
    inline static bool isAbsolutePath(const QString &path) { return 
!isRelativePath(path); }

qdir.cpp
bool QDir::isRelativePath(const QString &path)
{
    return QFileInfo(path).isRelative();
}

Ralf



From ralf.habacker at freenet.de  Thu Mar  6 21:12:54 2008
From: ralf.habacker at freenet.de (Ralf Habacker)
Date: Thu, 06 Mar 2008 21:12:54 +0100
Subject: 'lightweight' QDir::isAbsolutePath replacement ?
In-Reply-To: <47D03DF1.9050305@freenet.de>
References: <47CFE6A0.1080603@freenet.de> <47D03DF1.9050305@freenet.de>
Message-ID: <47D05046.2000305@freenet.de>

Ralf Habacker schrieb:
> Ralf Habacker schrieb:
>   
>> Hi,
>>
>> there are several places in the kde code which needs a check if a path 
>> is absolute. On unix this is mainly done by using  
>> QString::startsWith('/'), which does not work as expected on windows.
>>
>> The only static method Qt provides to handle this platform independent 
>> is QDir::isAbsolutePath(). Unfortunally this method seems to be very 
>> time expensive because it creates a temporary QDir instance.
>>     
> One little correction: I fact QDir::isAbsolutePath() creates a QFileInfo 
> instance instead of QDir but the problems still remains.
>
> qdir.h
>     static bool isRelativePath(const QString &path);
>     inline static bool isAbsolutePath(const QString &path) { return 
> !isRelativePath(path); }
>
> qdir.cpp
> bool QDir::isRelativePath(const QString &path)
> {
>     return QFileInfo(path).isRelative();
> }
>
>   
the real check is done in qt-copy/src/corelib/io/qfsfileengine_win.cpp 
(with the knowledge that isAbsolutePath() is !isRelativePath())

bool QFSFileEngine::isRelativePath() const
{
    Q_D(const QFSFileEngine);
    return !(d->filePath.startsWith(QLatin1Char('/'))
        || (d->filePath.length() >= 2
        && ((d->filePath.at(0).isLetter() && d->filePath.at(1) == 
QLatin1Char(':'))
        || (d->filePath.at(0) == QLatin1Char('/') && d->filePath.at(1) 
== QLatin1Char('/')))));                // drive, e.g. a:
}

which requires a QFSFileEnginePrivate and QFSFileEngine and QFileInfo 
object which explains the performance issue.

In the above mentioned file there is also a static function with the 
same result

static bool isRelativePath(const QString &path)
{
    return !(path.startsWith(QLatin1Char('/'))
           || (path.length() >= 2
           && ((path.at(0).isLetter() && path.at(1) == QLatin1Char(':'))
           || (path.at(0) == QLatin1Char('/') && path.at(1) == 
QLatin1Char('/'))))); // drive, e.g. a:
}

Would it be possible to add something like the following stuff  ?

---- qt-copy/src/corelib/io/qfsfileengine.h ----

static inline bool QFSFileEngine::isAbsolutePath(const QString &path) { 
return !QFSFileEngine::isRelativePath(path); }
static bool QFSFileEngine::isRelativePath(const QString &path);

---- qt-copy/src/corelib/io/qfsfileengine_unix.cpp ----

static bool QFSFileEngine::isRelativePath(const QString &path)
{
    if (path.size() == 0)
       return true;
    return path[0] != QLatin1Char('/');
}

---- in qt-copy/src/corelib/io/qfsfileengine_win.cpp

static bool QFSFileEngine::isRelativePath(const QString &path)
{
    return !(path.startsWith(QLatin1Char('/'))
           || path.startsWith(QLatin1Char('\\'))
           || (path.length() >= 2 &&
            ( (path.at(0).isLetter() && path.at(1) == QLatin1Char(':'))
           || (path.at(0) == QLatin1Char('/') && path.at(1) == 
QLatin1Char('/'))
           || (path.at(0) == QLatin1Char('\\') && path.at(1) == 
QLatin1Char('\\')) )) );
}

---- in qt-copy/src/corelib/io/qfileinfo.h ----
 
static inline bool QFileInfo::isAbsolutePath(const QString &path) { 
return !QFileInfo::isRelativePath(path); }
static bool QFileInfo::isRelativePath(const QString &path);

---- in qt-copy/src/corelib/io/qfileinfo.cpp -----

static bool QFileInfo::isRelativePath(const QString &path)
{
    return QFSFileEngine::isRelativePath(path);
}

Because QFSFileEngine is a public class it may be possible to implement 
only the QFSFileEngine static methods and to skip the QFileInfo stuff.

If this would be possible I can prepare a patch.

Ralf


From frank at kdab.net  Fri Mar  7 11:13:05 2008
From: frank at kdab.net (Frank Osterfeld)
Date: Fri, 7 Mar 2008 11:13:05 +0100
Subject: finding top-level dirs on windows
Message-ID: <200803071113.05632.frank@kdab.net>

Hi,

both Windbus and kdelibs find their installation directory by using the path 
to their binary (dbus-daemon.exe and libkdecore.dll respectively) and deduce 
the top-level installation directory from there. Both work with the 
assumption that the binaries are located in %INSTALLDIR%\bin.
In Gpg4win, we want to get rid of bin\ completely, as all other .exe and .dll  
files are already installed directly to %INSTALLDIR%. These two exceptions 
require several workarounds so all binaries and other resources are found 
correctly. 

I'd like to add the possibility to specify the windbus and KDE installation 
directory at installation time by adding an InstallLocation registry entry.
getKde4Prefix in kkernel_win.cpp and dbus_get_install_root can use that path 
then if it's present.
That  might also be useful for all of KDE on Windows later, when third parties 
want to ship software separate from the main KDE distribution and need to 
find an existing KDE installation.

What do you think of it? Is such a registry entry the way to go, are there 
alternatives? (maybe even implemented ones I haven't found yet)

Regards,

-- 
Frank Osterfeld -- frank at kdab.net
Klar?lvdalens Datakonsult AB, Platform-independent software solutions


From ralf.habacker at freenet.de  Fri Mar  7 19:39:12 2008
From: ralf.habacker at freenet.de (Ralf Habacker)
Date: Fri, 07 Mar 2008 19:39:12 +0100
Subject: Quanta Open File type problem
Message-ID: <47D18BD0.8070809@freenet.de>

Hi,

while playing with quanta in windows I found out that the project open 
dialog only contains "KDevelop 4 Project Files" type and not the 
required quanta file type.

The problem is caused by kdevplatform/shell/projectcontroller.cpp (see 
below) where the getOpenURL() call uses a hardcoded file types.

bool ProjectController::openProject( const KUrl &projectFile )
{
    KUrl url = projectFile;

    if ( url.isEmpty() )
    {
        KSharedConfig * config = KGlobal::config().data();
        KConfigGroup group = config->group( "General Options" );
        QString dir = group.readEntry( "DefaultProjectsDirectory",
                                             QDir::homePath() );

        url = KFileDialog::getOpenUrl( dir, i18n( "*.kdev4|KDevelop 4 
Project Files\n" ),


I think there should be additional methods in the Projectcontroller 
class to set/retrieve the used filetypes.

Ralf




From apaku at gmx.de  Fri Mar  7 21:50:35 2008
From: apaku at gmx.de (Andreas Pakulat)
Date: Fri, 7 Mar 2008 21:50:35 +0100
Subject: Quanta Open File type problem
In-Reply-To: <47D18BD0.8070809@freenet.de>
References: <47D18BD0.8070809@freenet.de>
Message-ID: <20080307205035.GA814@morpheus.apaku.dnsalias.org>

On 07.03.08 19:39:12, Ralf Habacker wrote:
> Hi,

No need to cc me :)

> while playing with quanta in windows I found out that the project open 
> dialog only contains "KDevelop 4 Project Files" type and not the required 
> quanta file type.

I'd ask how the quanta devs work with it. They must use some way to open
their projects. 

Apart from that, openProject() should already get a proper url, I'll
probably remove that code from openProject sooner or later.

Andreas

-- 
You will reach the highest possible point in your business or profession.


From ralf.habacker at freenet.de  Fri Mar  7 22:19:56 2008
From: ralf.habacker at freenet.de (Ralf Habacker)
Date: Fri, 07 Mar 2008 22:19:56 +0100
Subject: Quanta Open File type problem
In-Reply-To: <20080307205035.GA814@morpheus.apaku.dnsalias.org>
References: <47D18BD0.8070809@freenet.de>
	<20080307205035.GA814@morpheus.apaku.dnsalias.org>
Message-ID: <47D1B17C.2010005@freenet.de>

Andreas Pakulat schrieb:
> On 07.03.08 19:39:12, Ralf Habacker wrote:
>   
>> Hi,
>>     
>
> No need to cc me :)
>
>   
okay
>> while playing with quanta in windows I found out that the project open 
>> dialog only contains "KDevelop 4 Project Files" type and not the required 
>> quanta file type.
>>     
>
> I'd ask how the quanta devs work with it. They must use some way to open their projects. 
>
> Apart from that, openProject() should already get a proper url, I'll probably remove that code from openProject sooner or later.
>   
this require to call the open file dialog before calling openProject() 
in quanta :-)
Thanks for this info.

BTW: I'm preparing some patches to get quanta  partial running on 
windows. The main issue is that K3Process need to be ported to KProcess.

Ralf



From ralf.habacker at freenet.de  Fri Mar  7 23:01:47 2008
From: ralf.habacker at freenet.de (Ralf Habacker)
Date: Fri, 07 Mar 2008 23:01:47 +0100
Subject: Quanta Open File type problem
In-Reply-To: <47D1B17C.2010005@freenet.de>
References: <47D18BD0.8070809@freenet.de>	<20080307205035.GA814@morpheus.apaku.dnsalias.org>
	<47D1B17C.2010005@freenet.de>
Message-ID: <47D1BB4B.7090402@freenet.de>

Ralf Habacker schrieb:
> Andreas Pakulat schrieb:
>   
>> On 07.03.08 19:39:12, Ralf Habacker wrote:
>>   
>>     
>>> Hi,
>>>     
>>>       
>> No need to cc me :)
>>
>>   
>>     
> okay
>   
>>> while playing with quanta in windows I found out that the project open 
>>> dialog only contains "KDevelop 4 Project Files" type and not the required 
>>> quanta file type.
>>>     
>>>       
>> I'd ask how the quanta devs work with it. They must use some way to open their projects. 
>>
>> Apart from that, openProject() should already get a proper url, I'll probably remove that code from openProject sooner or later.
>>     
just a note: If you click on "Open Project" in the Project menu, the 
kdevplatformshell library is triggered directly with a call to 
openProject() using an empty url. This raises the open file dialog with 
the hardcoded "KDevelop 4 Project Files" type set. There is no quanta 
code between.

As far as I can see it looks that the only way to control the file types 
from quanta is to set it immediatly after creating the ProjectController 
instance  or to set a specific "quanta" mode in the Kdevelop::Core 
class, which could be used in the ProjectController class.


Ralf



From apaku at gmx.de  Fri Mar  7 23:13:10 2008
From: apaku at gmx.de (Andreas Pakulat)
Date: Fri, 7 Mar 2008 23:13:10 +0100
Subject: Quanta Open File type problem
In-Reply-To: <47D1B17C.2010005@freenet.de>
References: <47D18BD0.8070809@freenet.de>
	<20080307205035.GA814@morpheus.apaku.dnsalias.org>
	<47D1B17C.2010005@freenet.de>
Message-ID: <20080307221310.GA3151@morpheus.apaku.dnsalias.org>

On 07.03.08 22:19:56, Ralf Habacker wrote:
> Andreas Pakulat schrieb:
> > On 07.03.08 19:39:12, Ralf Habacker wrote:
> >> while playing with quanta in windows I found out that the project open 
> >> dialog only contains "KDevelop 4 Project Files" type and not the required 
> >> quanta file type.
> >>     
> >
> > I'd ask how the quanta devs work with it. They must use some way to open their projects. 
> >
> > Apart from that, openProject() should already get a proper url, I'll probably remove that code from openProject sooner or later.
> >   
> this require to call the open file dialog before calling openProject() 
> in quanta :-)
> Thanks for this info.

I guess I should've checked the code before :) This won't change
actually, as the action is simply connected to the openProject function.

I'll have to think about how to let platform allow to specify their own
file extension. 

Andreas

-- 
Be free and open and breezy!  Enjoy!  Things won't get any better so
get used to it.


From apaku at gmx.de  Sat Mar  8 10:21:08 2008
From: apaku at gmx.de (Andreas Pakulat)
Date: Sat, 8 Mar 2008 10:21:08 +0100
Subject: Quanta Open File type problem
In-Reply-To: <47D1BB4B.7090402@freenet.de>
References: <47D18BD0.8070809@freenet.de>
	<20080307205035.GA814@morpheus.apaku.dnsalias.org>
	<47D1B17C.2010005@freenet.de> <47D1BB4B.7090402@freenet.de>
Message-ID: <20080308092108.GC9824@morpheus.apaku.dnsalias.org>

On 07.03.08 23:01:47, Ralf Habacker wrote:
> Ralf Habacker schrieb:
> > Andreas Pakulat schrieb:
> >   
> >> On 07.03.08 19:39:12, Ralf Habacker wrote:
> >>   
> >>     
> >>> Hi,
> >>>     
> >>>       
> >> No need to cc me :)
> >>
> >>   
> >>     
> > okay
> >   
> >>> while playing with quanta in windows I found out that the project open 
> >>> dialog only contains "KDevelop 4 Project Files" type and not the required 
> >>> quanta file type.
> >>>     
> >>>       
> >> I'd ask how the quanta devs work with it. They must use some way to open their projects. 
> >>
> >> Apart from that, openProject() should already get a proper url, I'll probably remove that code from openProject sooner or later.
> >>     
> just a note: If you click on "Open Project" in the Project menu, the 
> kdevplatformshell library is triggered directly with a call to 
> openProject() using an empty url. This raises the open file dialog with 
> the hardcoded "KDevelop 4 Project Files" type set. There is no quanta 
> code between.
> 
> As far as I can see it looks that the only way to control the file types 
> from quanta is to set it immediatly after creating the ProjectController 
> instance  or to set a specific "quanta" mode in the Kdevelop::Core 
> class, which could be used in the ProjectController class.

In fact we already have a way to extend the shell for applications.
Check out ShellExtension. I'll add a method for projectFileType and
projectFileDescription later today. So quanta just needs to provide a
ShellExtension instance with those methods properly overwritten. Example
code will be in KDevelop as soon as I commit that.

Andreas

-- 
You never hesitate to tackle the most difficult problems.


From ralf.habacker at freenet.de  Sat Mar  8 10:29:01 2008
From: ralf.habacker at freenet.de (Ralf Habacker)
Date: Sat, 08 Mar 2008 10:29:01 +0100
Subject: Quanta Open File type problem
In-Reply-To: <20080308092108.GC9824@morpheus.apaku.dnsalias.org>
References: <47D18BD0.8070809@freenet.de>	<20080307205035.GA814@morpheus.apaku.dnsalias.org>	<47D1B17C.2010005@freenet.de>
	<47D1BB4B.7090402@freenet.de>
	<20080308092108.GC9824@morpheus.apaku.dnsalias.org>
Message-ID: <47D25C5D.5060103@freenet.de>

Andreas Pakulat schrieb:
> On 07.03.08 23:01:47, Ralf Habacker wrote:
>   
>> Ralf Habacker schrieb:
>>     
>>> Andreas Pakulat schrieb:
>>>   
>>>       
>>>> On 07.03.08 19:39:12, Ralf Habacker wrote:
>>>>   
>>>>     
>>>>         
>>>>> Hi,
>>>>>     
>>>>>       
>>>>>           
>>>> No need to cc me :)
>>>>
>>>>   
>>>>     
>>>>         
>>> okay
>>>   
>>>       
>>>>> while playing with quanta in windows I found out that the project open 
>>>>> dialog only contains "KDevelop 4 Project Files" type and not the required 
>>>>> quanta file type.
>>>>>     
>>>>>       
>>>>>           
>>>> I'd ask how the quanta devs work with it. They must use some way to open their projects. 
>>>>
>>>> Apart from that, openProject() should already get a proper url, I'll probably remove that code from openProject sooner or later.
>>>>     
>>>>         
>> just a note: If you click on "Open Project" in the Project menu, the 
>> kdevplatformshell library is triggered directly with a call to 
>> openProject() using an empty url. This raises the open file dialog with 
>> the hardcoded "KDevelop 4 Project Files" type set. There is no quanta 
>> code between.
>>
>> As far as I can see it looks that the only way to control the file types 
>> from quanta is to set it immediatly after creating the ProjectController 
>> instance  or to set a specific "quanta" mode in the Kdevelop::Core 
>> class, which could be used in the ProjectController class.
>>     
>
> In fact we already have a way to extend the shell for applications.
> Check out ShellExtension. I'll add a method for projectFileType and
> projectFileDescription later today. So quanta just needs to provide a
> ShellExtension instance with those methods properly overwritten. Example
> code will be in KDevelop as soon as I commit that.
>
>   
very nice - thanks

Ralf



From apaku at gmx.de  Sat Mar  8 10:34:48 2008
From: apaku at gmx.de (Andreas Pakulat)
Date: Sat, 8 Mar 2008 10:34:48 +0100
Subject: Quanta Open File type problem
In-Reply-To: <47D25C5D.5060103@freenet.de>
References: <47D18BD0.8070809@freenet.de>
	<20080307205035.GA814@morpheus.apaku.dnsalias.org>
	<47D1B17C.2010005@freenet.de> <47D1BB4B.7090402@freenet.de>
	<20080308092108.GC9824@morpheus.apaku.dnsalias.org>
	<47D25C5D.5060103@freenet.de>
Message-ID: <20080308093448.GD9824@morpheus.apaku.dnsalias.org>

On 08.03.08 10:29:01, Ralf Habacker wrote:
> > In fact we already have a way to extend the shell for applications.
> > Check out ShellExtension. I'll add a method for projectFileType and
> > projectFileDescription later today. So quanta just needs to provide a
> > ShellExtension instance with those methods properly overwritten. Example
> > code will be in KDevelop as soon as I commit that.
> >   
> very nice - thanks

Scratch that, just svn up and be happy. Was just too tempting to do
right away (and just a handful lines of code). I've also added it to
quanta (to not break their build) using the same values as kdevelop4.

Andreas

-- 
You will not be elected to public office this year.


From aacid at kde.org  Sun Mar  9 12:19:12 2008
From: aacid at kde.org (Albert Astals Cid)
Date: Sun, 9 Mar 2008 12:19:12 +0100
Subject: KFileDialog bug
In-Reply-To: <47CF3250.4070303@freenet.de>
References: <47CF3250.4070303@freenet.de>
Message-ID: <200803091219.14001.aacid@kde.org>

A Dijous 06 Mar? 2008, Ralf Habacker va escriure:
> Hi,
>
> while testing quanta on windows I found a bug in KFileDialog using
> KFileDialog::getOpenUrls().
>
> The bug is independend from quanta and could be reproduced with the
> appended testcase, which patches kio/kfile/tests/kfstest and requires an
> installed oxygen icon set.
> After applying the path and relinking of kfstest the following command
> sequence triggers the bug:
>
> kfstest openurls
>
> -> this should open a list of directories, (in my case
> c:/daten/kde/emerge-msvc-root/share/icons/oxygen/16x16)
>
> Then enter the 'actions' directory, select an image and click open.
>
> The selected file should be printed on the qDebug output (stderr on
> unix, DbgView on windows) In my case it returns
> KUrl("file://c:/daten/kde/emerge-msvc-root/share/icons/oxygen/16x16/applica
>tion-exit.png")
>
>
> which is wrong, it should contain the 'actions' directory as shown below:
>
> KUrl("file://c:/daten/kde/emerge-msvc-root/share/icons/oxygen/16x16/actions
>/application-exit.png")

Works here on linux.

Albert

>
> Ralf




From Ch.Ehrlicher at gmx.de  Sun Mar  9 15:05:06 2008
From: Ch.Ehrlicher at gmx.de (Christian Ehrlicher)
Date: Sun, 09 Mar 2008 15:05:06 +0100
Subject: [patch] (msvc) use more modern facilities for setenv() unsetenv()
In-Reply-To: <47D0162C.3060103@iidea.pl>
References: <47D0162C.3060103@iidea.pl>
Message-ID: <47D3EE92.6040501@gmx.de>

Jaros?aw Staniek schrieb:
> For review:
> 
> - setenv(): use secure _putenv_s() declared in msvc >= 2005 (recommended 
> and apparently also used by Qt4/win); return -1 when name==0;
> 
> - unsetenv(): clear the variable using setenv(name, 0, 1) as environ is 
> deprecated.
> 
-    if (!overwrite && getenv(name)) return 0;
+    if (!overwrite && GetEnvironmentVariableA(name, dummy, 0) > 0) 
return 0;


This doesn't work in some cases - see my latest (private) mail about 
problems mixing msvcrt and winapi functions... :(

The rest looks fine - plz checkin so I can fix setenv() for use with 
libxml2 :)


Christian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 258 bytes
Desc: OpenPGP digital signature
Url : http://mail.kde.org/pipermail/kde-windows/attachments/20080309/43435644/attachment.pgp 

From Ch.Ehrlicher at gmx.de  Sun Mar  9 15:08:22 2008
From: Ch.Ehrlicher at gmx.de (Christian Ehrlicher)
Date: Sun, 09 Mar 2008 15:08:22 +0100
Subject: finding top-level dirs on windows
In-Reply-To: <200803071113.05632.frank@kdab.net>
References: <200803071113.05632.frank@kdab.net>
Message-ID: <47D3EF56.3030100@gmx.de>

Frank Osterfeld schrieb:
> Hi,
> 
> both Windbus and kdelibs find their installation directory by using the path 
> to their binary (dbus-daemon.exe and libkdecore.dll respectively) and deduce 
> the top-level installation directory from there. Both work with the 
> assumption that the binaries are located in %INSTALLDIR%\bin.
> In Gpg4win, we want to get rid of bin\ completely, as all other .exe and .dll  
> files are already installed directly to %INSTALLDIR%. These two exceptions 
> require several workarounds so all binaries and other resources are found 
> correctly. 
> 
> I'd like to add the possibility to specify the windbus and KDE installation 
> directory at installation time by adding an InstallLocation registry entry.
> getKde4Prefix in kkernel_win.cpp and dbus_get_install_root can use that path 
> then if it's present.
> That  might also be useful for all of KDE on Windows later, when third parties 
> want to ship software separate from the main KDE distribution and need to 
> find an existing KDE installation.
> 
> What do you think of it? Is such a registry entry the way to go, are there 
> alternatives? (maybe even implemented ones I haven't found yet)
> 
With a hardcoded registry key we loose the possibility to ship kde on an 
usb stick. We maybe can update the registry key on runtime so it gets 
adjusted every time kdecore.dll is loaded.


Christian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 258 bytes
Desc: OpenPGP digital signature
Url : http://mail.kde.org/pipermail/kde-windows/attachments/20080309/e615fa70/attachment.pgp 

From matthias.pospiech at gmx.de  Sun Mar  9 15:14:04 2008
From: matthias.pospiech at gmx.de (Matthias Pospiech)
Date: Sun, 09 Mar 2008 15:14:04 +0100
Subject: finding top-level dirs on windows
In-Reply-To: <47D3EF56.3030100@gmx.de>
References: <200803071113.05632.frank@kdab.net> <47D3EF56.3030100@gmx.de>
Message-ID: <47D3F0AC.4000609@gmx.de>

Christian Ehrlicher schrieb:
> With a hardcoded registry key we loose the possibility to ship kde on 
> an usb stick. We maybe can update the registry key on runtime so it 
> gets adjusted every time kdecore.dll is loaded.
I just want to mention, that there are tools which check every registry 
access and pop up with a warning. Having a frequent registry access 
would be in that case very annoying.
A similar situtation exists already with tcp requests which make a 
firewall pop up with every kde application.

Matthias


From Ch.Ehrlicher at gmx.de  Sun Mar  9 15:18:04 2008
From: Ch.Ehrlicher at gmx.de (Christian Ehrlicher)
Date: Sun, 09 Mar 2008 15:18:04 +0100
Subject: finding top-level dirs on windows
In-Reply-To: <47D3F0AC.4000609@gmx.de>
References: <200803071113.05632.frank@kdab.net> <47D3EF56.3030100@gmx.de>
	<47D3F0AC.4000609@gmx.de>
Message-ID: <47D3F19C.1010803@gmx.de>

Matthias Pospiech schrieb:
> Christian Ehrlicher schrieb:
>> With a hardcoded registry key we loose the possibility to ship kde on 
>> an usb stick. We maybe can update the registry key on runtime so it 
>> gets adjusted every time kdecore.dll is loaded.
> I just want to mention, that there are tools which check every registry 
> access and pop up with a warning. Having a frequent registry access 
> would be in that case very annoying.
> A similar situtation exists already with tcp requests which make a 
> firewall pop up with every kde application.
> 
Use a better firewall - or use the checkbox to allow the process to 
modify this special registry key without asking every time.


Christian


From ralf.habacker at freenet.de  Sun Mar  9 16:13:11 2008
From: ralf.habacker at freenet.de (Ralf Habacker)
Date: Sun, 09 Mar 2008 16:13:11 +0100
Subject: finding top-level dirs on windows
In-Reply-To: <47D3EF56.3030100@gmx.de>
References: <200803071113.05632.frank@kdab.net> <47D3EF56.3030100@gmx.de>
Message-ID: <47D3FE87.9080307@freenet.de>

Christian Ehrlicher schrieb:
> Frank Osterfeld schrieb:
>> Hi,
>>
>> both Windbus and kdelibs find their installation directory by using 
>> the path to their binary (dbus-daemon.exe and libkdecore.dll 
>> respectively) and deduce the top-level installation directory from 
>> there. Both work with the assumption that the binaries are located in 
>> %INSTALLDIR%\bin.
>> In Gpg4win, we want to get rid of bin\ completely, as all other .exe 
>> and .dll  files are already installed directly to %INSTALLDIR%. These 
>> two exceptions require several workarounds so all binaries and other 
>> resources are found correctly.
It is simple to add a check to getKde4Prefix()  to set the install 
directory to the directory in where kdecore.dll is located, when kdecore 
is not located in a bin dir.  The same belongs to windbus.

The more important question is if this path layout change will affect 
the whole kde4 distribution on windows because *all* binary package uses 
the bin subdirectory for binaries and executables.

If gpg4win will be a requirement for kde on windows applications this 
will let into trouble.

Ralf



From frank at kdab.net  Sun Mar  9 18:53:40 2008
From: frank at kdab.net (Frank Osterfeld)
Date: Sun, 9 Mar 2008 18:53:40 +0100
Subject: finding top-level dirs on windows
In-Reply-To: <47D3FE87.9080307@freenet.de>
References: <200803071113.05632.frank@kdab.net> <47D3EF56.3030100@gmx.de>
	<47D3FE87.9080307@freenet.de>
Message-ID: <200803091853.43707.frank@kdab.net>

On Sunday 09 March 2008 16:13:11 Ralf Habacker wrote:
> Christian Ehrlicher schrieb:
> > Frank Osterfeld schrieb:
> >> Hi,
> >>
> >> both Windbus and kdelibs find their installation directory by using
> >> the path to their binary (dbus-daemon.exe and libkdecore.dll
> >> respectively) and deduce the top-level installation directory from
> >> there. Both work with the assumption that the binaries are located in
> >> %INSTALLDIR%\bin.
> >> In Gpg4win, we want to get rid of bin\ completely, as all other .exe
> >> and .dll  files are already installed directly to %INSTALLDIR%. These
> >> two exceptions require several workarounds so all binaries and other
> >> resources are found correctly.
>
> It is simple to add a check to getKde4Prefix()  to set the install
> directory to the directory in where kdecore.dll is located, when kdecore
> is not located in a bin dir.  The same belongs to windbus.

Yes, that's what I had in mind. it's simple to patch those two functions for 
this purpose, without changing behaviour with a layout that contains bin/. 
Especially for dbus it makes sense to me to have that upstream. The key can 
than also be used by other projects to find existing dbus installations and 
avoid having multiple dbus versions installed.
Would you accept such a patch to windbus in case it allows KDE on Windows to 
continue working as before? (An alternative, which I dislike though: Assume 
$INSTALLDIR/binary.exe/dll structure in case the $INSTALLDIR/bin/ check 
failed)

> The more important question is if this path layout change will affect
> the whole kde4 distribution on windows because *all* binary package uses
> the bin subdirectory for binaries and executables.
>
> If gpg4win will be a requirement for kde on windows applications this
> will let into trouble.

gpg4win won't depend on KDE on windows directly nor vice versa, from the KDE 
point of view gpg4win2 is rather an alternative, heavily stripped down KDE 
distribution (i..e. only Kleopatra, necessary parts of kdelibs, KDE icons, 
gnupg libraries and dependencies (Qt, dbus...)).

-- 
Frank Osterfeld -- frank at kdab.net
Klar?lvdalens Datakonsult AB, Platform-independent software solutions


From ralf.habacker at freenet.de  Mon Mar 10 10:37:38 2008
From: ralf.habacker at freenet.de (Ralf Habacker)
Date: Mon, 10 Mar 2008 10:37:38 +0100
Subject: finding top-level dirs on windows
In-Reply-To: <200803091853.43707.frank@kdab.net>
References: <200803071113.05632.frank@kdab.net>
	<47D3EF56.3030100@gmx.de>	<47D3FE87.9080307@freenet.de>
	<200803091853.43707.frank@kdab.net>
Message-ID: <47D50162.4070803@freenet.de>

Frank Osterfeld schrieb:
> On Sunday 09 March 2008 16:13:11 Ralf Habacker wrote:
>   
>> Christian Ehrlicher schrieb:
>>     
>>> Frank Osterfeld schrieb:
>>>       
>>>> Hi,
>>>>
>>>> both Windbus and kdelibs find their installation directory by using
>>>> the path to their binary (dbus-daemon.exe and libkdecore.dll
>>>> respectively) and deduce the top-level installation directory from
>>>> there. Both work with the assumption that the binaries are located in
>>>> %INSTALLDIR%\bin.
>>>> In Gpg4win, we want to get rid of bin\ completely, as all other .exe
>>>> and .dll  files are already installed directly to %INSTALLDIR%. These
>>>> two exceptions require several workarounds so all binaries and other
>>>> resources are found correctly.
>>>>         
>> It is simple to add a check to getKde4Prefix()  to set the install
>> directory to the directory in where kdecore.dll is located, when kdecore
>> is not located in a bin dir.  The same belongs to windbus.
>>     
>
> Yes, that's what I had in mind. it's simple to patch those two functions for 
> this purpose, without changing behaviour with a layout that contains bin/. 
> Especially for dbus it makes sense to me to have that upstream. 
>
> The key can than also be used by other projects to find existing dbus installations and 
> avoid having multiple dbus versions installed.
>   
> Would you accept such a patch to windbus in case it allows KDE on Windows to 
> continue working as before? 
>   
Your are mixing two task:

1. detecting kde installation root
2. storing this root into the registry.

while i see no problem for a patch for task 1, my questions if task2 is 
really needed for your project because it has some drawbacks as already 
stated.

> (An alternative, which I dislike though: Assume 
> $INSTALLDIR/binary.exe/dll structure in case the $INSTALLDIR/bin/ check 
> failed)
>> The more important question is if this path layout change will affect
>> the whole kde4 distribution on windows because *all* binary package uses
>> the bin subdirectory for binaries and executables.
>>
>> If gpg4win will be a requirement for kde on windows applications this
>> will let into trouble.
>>     
>
> gpg4win won't depend on KDE on windows directly nor vice versa, from the KDE 
> point of view gpg4win2 is rather an alternative, heavily stripped down KDE 
> distribution (i..e. only Kleopatra, necessary parts of kdelibs, KDE icons, 
> gnupg libraries and dependencies (Qt, dbus...)).
>   
You are aware, that you are forced to maintain all required packages by 
yourself  ?  In case you haven't noticed  there are already several 
binary package available - see for example 
http://ftp.gwdg.de/pub/x11/kde/unstable/4.0.63/win32/.


There is also a buildsystem available 
http://techbase.kde.org/index.php?title=Getting_Started/Build/KDE4/Windows/emerge 
to which your packages could be easily added and you have the 
possibility to build your packages and all requirements as a whole and 
for debug/release mode.


Ralf





From js at iidea.pl  Mon Mar 10 14:28:04 2008
From: js at iidea.pl (=?UTF-8?B?SmFyb3PFgmF3IFN0YW5pZWs=?=)
Date: Mon, 10 Mar 2008 14:28:04 +0100
Subject: New techbase page: Tools
Message-ID: <47D53764.8060103@iidea.pl>


http://techbase.kde.org/index.php?title=Projects/KDE_on_Windows/Tools

-- 
regards / pozdrawiam, Jaroslaw Staniek
  Sponsored by OpenOffice Polska (http://www.openoffice.com.pl/en) to work on
  Kexi & KOffice (http://www.kexi.pl/en, http://www.koffice.org/kexi)
  KDE Libraries for MS Windows (http://windows.kde.org)


From ralf.habacker at freenet.de  Mon Mar 10 14:46:11 2008
From: ralf.habacker at freenet.de (Ralf Habacker)
Date: Mon, 10 Mar 2008 14:46:11 +0100
Subject: New techbase page: Tools
In-Reply-To: <47D53764.8060103@iidea.pl>
References: <47D53764.8060103@iidea.pl>
Message-ID: <47D53BA3.3030902@freenet.de>

Jaros?aw Staniek schrieb:
> http://techbase.kde.org/index.php?title=Projects/KDE_on_Windows/Tools
>
>   
I've added a link to Process Monitor which is very nice to analyse file 
system activity.

Ralf




From kde-dev at emailgoeshere.com  Mon Mar 10 16:22:43 2008
From: kde-dev at emailgoeshere.com (Jeff Mitchell)
Date: Mon, 10 Mar 2008 11:22:43 -0400
Subject: emerge --update behavior
Message-ID: <47D55243.5030702@emailgoeshere.com>

If you run emerge with multiple targets:

emerge foo bar

it'll emerge foo, then bar, for an equivalent of
emerge foo
emerge bar

If you run emerge --update foo bar, it becomes the equivalent of:

emerge --update foo
emerge bar

Which leads to unexpected results...

--Jeff


From ps_ml at gmx.de  Mon Mar 10 18:22:57 2008
From: ps_ml at gmx.de (Patrick Spendrin)
Date: Mon, 10 Mar 2008 18:22:57 +0100
Subject: emerge --update behavior
In-Reply-To: <47D55243.5030702@emailgoeshere.com>
References: <47D55243.5030702@emailgoeshere.com>
Message-ID: <47D56E71.4060902@gmx.de>

Jeff Mitchell schrieb:
> If you run emerge with multiple targets:
> 
> emerge foo bar
> 
> it'll emerge foo, then bar, for an equivalent of
> emerge foo
> emerge bar
> 
> If you run emerge --update foo bar, it becomes the equivalent of:
> 
> emerge --update foo
> emerge bar
> 
> Which leads to unexpected results...
the correct thing would be:
emerge --update foo --update bar
There would be no way to simply update only one package.
To make it more usable I am planning an option -R which will then result in:
emerge -R --update foo bar
being equivalent to
emerge --update foo
emerge --update bar
> 
> --Jeff
regards
SE
> _______________________________________________
> Kde-windows mailing list
> Kde-windows at kde.org
> https://mail.kde.org/mailman/listinfo/kde-windows
> 


-- 
web:                 http://windows.kde.org
mailing list:        kde-windows at kde.org
irc:                 #kde-windows (irc.freenode.net)


From brandon.ml at gmail.com  Tue Mar 11 01:24:54 2008
From: brandon.ml at gmail.com (Carlo)
Date: Tue, 11 Mar 2008 01:24:54 +0100
Subject: Cross compiling page in techbase
Message-ID: <3262b6180803101724g4f454a71vc029d65f2d85df9d@mail.gmail.com>

Hi, i've added a page in techbase with instruction to crosscompile kde
for windows from linux
http://techbase.kde.org/index.php?title=Getting_Started/Build/KDE4/Windows/CrossCompiling
and i've linked it to
http://techbase.kde.org/index.php?title=Getting_Started/Build/KDE4/Windows

Carlo


From frank at kdab.net  Tue Mar 11 09:56:05 2008
From: frank at kdab.net (Frank Osterfeld)
Date: Tue, 11 Mar 2008 09:56:05 +0100
Subject: finding top-level dirs on windows
In-Reply-To: <47D50162.4070803@freenet.de>
References: <200803071113.05632.frank@kdab.net>
	<200803091853.43707.frank@kdab.net> <47D50162.4070803@freenet.de>
Message-ID: <200803110956.05729.frank@kdab.net>

On Monday 10 March 2008 10:37:38 Ralf Habacker wrote:

> Your are mixing two task:
>
> 1. detecting kde installation root
> 2. storing this root into the registry.
>
> while i see no problem for a patch for task 1, my questions if task2 is
> really needed for your project because it has some drawbacks as already
> stated.

I can patch kdelibs to our needs, my question is mostly about dbus (which I 
can also patch, but that'd require us to maintain our own dbus packages, see 
below). How would you solve 1. for dbus then, without registry key, at 
runtime from within dbus?

> > gpg4win won't depend on KDE on windows directly nor vice versa, from the
> > KDE point of view gpg4win2 is rather an alternative, heavily stripped
> > down KDE distribution (i..e. only Kleopatra, necessary parts of kdelibs,
> > KDE icons, gnupg libraries and dependencies (Qt, dbus...)).
>
> You are aware, that you are forced to maintain all required packages by
> yourself  ?  In case you haven't noticed  there are already several
> binary package available - see for example
> http://ftp.gwdg.de/pub/x11/kde/unstable/4.0.63/win32/.

Yeah, I'm aware of those. In fact, we use the existing binary packages for KDE 
dependencies (dbus, Qt, ...). One reasion why I'm interested in generic 
solutions.

> There is also a buildsystem available
> http://techbase.kde.org/index.php?title=Getting_Started/Build/KDE4/Windows/
>emerge to which your packages could be easily added and you have the
> possibility to build your packages and all requirements as a whole and
> for debug/release mode.

Building kdelibs, kdepimlibs and kdepim is not the problem. We can't reuse any 
of the existing KDE packages anyway, as we must strip everything  from 
kdelibs/kdepimlibs/kdepim we can to keep the gpg4win2 installer size minimal. 
The final version should be cross-compiled from Linux even.

-- 
Frank Osterfeld -- frank at kdab.net
Klar?lvdalens Datakonsult AB, Platform-independent software solutions


From ralf.habacker at freenet.de  Tue Mar 11 19:19:57 2008
From: ralf.habacker at freenet.de (Ralf Habacker)
Date: Tue, 11 Mar 2008 19:19:57 +0100
Subject: finding top-level dirs on windows
In-Reply-To: <200803110956.05729.frank@kdab.net>
References: <200803071113.05632.frank@kdab.net>	<200803091853.43707.frank@kdab.net>
	<47D50162.4070803@freenet.de> <200803110956.05729.frank@kdab.net>
Message-ID: <47D6CD4D.9090307@freenet.de>

Frank Osterfeld schrieb:
> On Monday 10 March 2008 10:37:38 Ralf Habacker wrote:
>
>   
>> Your are mixing two task:
>>
>> 1. detecting kde installation root
>> 2. storing this root into the registry.
>>
>> while i see no problem for a patch for task 1, my questions if task2 is
>> really needed for your project because it has some drawbacks as already
>> stated.
>>     
>
> I can patch kdelibs to our needs, my question is mostly about dbus (which I 
> can also patch, but that'd require us to maintain our own dbus packages, see 
> below). How would you solve 1. for dbus then, without registry key, at 
> runtime from within dbus?
>   
The dbus library contains already stuff to determine the dbus install 
directory in the way the kdecore library does - see 
_dbus_get_install_root(char *s, int len) in dbus/dbus-sysdeps-win.c.

If you have a patch there is no problem to apply this patch to the 
windbus code.
>   
>>> gpg4win won't depend on KDE on windows directly nor vice versa, from the
>>> KDE point of view gpg4win2 is rather an alternative, heavily stripped
>>> down KDE distribution (i..e. only Kleopatra, necessary parts of kdelibs,
>>> KDE icons, gnupg libraries and dependencies (Qt, dbus...)).
>>>       
>> You are aware, that you are forced to maintain all required packages by
>> yourself  ?  In case you haven't noticed  there are already several
>> binary package available - see for example
>> http://ftp.gwdg.de/pub/x11/kde/unstable/4.0.63/win32/.
>>     
>
> Yeah, I'm aware of those. In fact, we use the existing binary packages for KDE 
> dependencies (dbus, Qt, ...). One reasion why I'm interested in generic 
> solutions.
>   
i assume you have to repackage those binary package ?
>   
>> There is also a buildsystem available
>> http://techbase.kde.org/index.php?title=Getting_Started/Build/KDE4/Windows/
>> emerge to which your packages could be easily added and you have the
>> possibility to build your packages and all requirements as a whole and
>> for debug/release mode.
>>     
>
> Building kdelibs, kdepimlibs and kdepim is not the problem. We can't reuse any 
> of the existing KDE packages anyway, as we must strip everything  from 
> kdelibs/kdepimlibs/kdepim we can to keep the gpg4win2 installer size minimal. 
> The final version should be cross-compiled from Linux even.
I understand.

Ralf



From neundorf at kde.org  Tue Mar 11 19:45:28 2008
From: neundorf at kde.org (Alexander Neundorf)
Date: Tue, 11 Mar 2008 19:45:28 +0100
Subject: Cross compiling page in techbase
In-Reply-To: <3262b6180803101724g4f454a71vc029d65f2d85df9d@mail.gmail.com>
References: <3262b6180803101724g4f454a71vc029d65f2d85df9d@mail.gmail.com>
Message-ID: <200803111945.28725.neundorf@kde.org>

On Tuesday 11 March 2008, Carlo wrote:
> Hi, i've added a page in techbase with instruction to crosscompile kde
> for windows from linux
> http://techbase.kde.org/index.php?title=Getting_Started/Build/KDE4/Windows/
>CrossCompiling and i've linked it to

Wow, _very_ cool ! :-)

Some questions:

Why do you need to preset all the variables starting with KDE4_INSTALL_DIR, 
especially the KDE4_XXX_LIBRARY variables ?

Some comments:
> you have to make a link to your kde4automoc for linux in the bin directory

we should be able to fix that...

> since linux is case sensitive you have to make symbolic links for some
> headers

Can't this be corrected in the source files where the headers are included ?

> You will get a linker error on kjsembed so from the build directory cd into
> kjsembed/kjsembed and make VERBOSE=1 2>/dev/null

what's the problem here with linking ?
This shouldn't happen, we have to fix it.

> You will get another error in klauncher.moc about slotKDEInitData so go into
> kinit and do something like this(you need wine)

What's the exact problem here ?
Does the Windows moc have to be used ? Why ?

> Another error in kdewidgets because wine doesn't find some dll to run
> makekdewidgets.exe so either run the linux version manually like this

So you run the generated executables using wine ? Interesting. The idea was to 
use "native" executables if cross compiling. But if it works, ok.

Alex




From brandon.ml at gmail.com  Tue Mar 11 20:10:37 2008
From: brandon.ml at gmail.com (Carlo)
Date: Tue, 11 Mar 2008 20:10:37 +0100
Subject: Cross compiling page in techbase
In-Reply-To: <200803111945.28725.neundorf@kde.org>
References: <3262b6180803101724g4f454a71vc029d65f2d85df9d@mail.gmail.com>
	<200803111945.28725.neundorf@kde.org>
Message-ID: <3262b6180803111210ta39549eo8abed62601b00876@mail.gmail.com>

On Tue, Mar 11, 2008 at 7:45 PM, Alexander Neundorf <neundorf at kde.org> wrote:
> On Tuesday 11 March 2008, Carlo wrote:
>  > Hi, i've added a page in techbase with instruction to crosscompile kde
>  > for windows from linux
>  > http://techbase.kde.org/index.php?title=Getting_Started/Build/KDE4/Windows/
>  >CrossCompiling and i've linked it to
>
>  Wow, _very_ cool ! :-)
>
>  Some questions:
>
>  Why do you need to preset all the variables starting with KDE4_INSTALL_DIR,
>  especially the KDE4_XXX_LIBRARY variables ?
KDE4_INSTALL_DIR is just for convenience so you don't have to modify
the path for all set, I have to specify some kde/qt library because
cmake can't find them itself and i have disabled dnssd/avahi etc..
because cmake find the linux one and think that it's good
>  Some comments:
>  > you have to make a link to your kde4automoc for linux in the bin directory
>
>  we should be able to fix that...
>
>  > since linux is case sensitive you have to make symbolic links for some
>  > headers
>
>  Can't this be corrected in the source files where the headers are included ?
yeah this can be fixed in the source file too(maybe soprano would
require an ifdef since there are both soprano and Soprano on linux),
but link was easier to do
>  > You will get a linker error on kjsembed so from the build directory cd into
>  > kjsembed/kjsembed and make VERBOSE=1 2>/dev/null
>
>  what's the problem here with linking ?
>  This shouldn't happen, we have to fix it.
it's a long linker error about QtUiTools it can't find anything
related to qt(QString, QDataStream etc..)
>  > You will get another error in klauncher.moc about slotKDEInitData so go into
>  > kinit and do something like this(you need wine)
>
>  What's the exact problem here ?
>  Does the Windows moc have to be used ? Why ?
slotKDEInitData doesn't exist on windows
http://lxr.kde.org/source/KDE/kdelibs/kinit/klauncher.h#179 but
kde4automoc thinks that we are on linux maybe, so maybe we should use
the windows version for everything
>  > Another error in kdewidgets because wine doesn't find some dll to run
>  > makekdewidgets.exe so either run the linux version manually like this
>
>  So you run the generated executables using wine ? Interesting. The idea was to
>  use "native" executables if cross compiling. But if it works, ok.
>
>  Alex
for some strange reason for kde4automoc it calls ../bin/kde4automoc
instead of ../bin/kde4automoc.exe one that's why i made the link in
the bin dir, but for makekdewidgets it wants to use the exe one

Carlo


From neundorf at kde.org  Tue Mar 11 21:47:39 2008
From: neundorf at kde.org (Alexander Neundorf)
Date: Tue, 11 Mar 2008 21:47:39 +0100
Subject: Cross compiling page in techbase
In-Reply-To: <3262b6180803111210ta39549eo8abed62601b00876@mail.gmail.com>
References: <3262b6180803101724g4f454a71vc029d65f2d85df9d@mail.gmail.com>
	<200803111945.28725.neundorf@kde.org>
	<3262b6180803111210ta39549eo8abed62601b00876@mail.gmail.com>
Message-ID: <200803112147.40156.neundorf@kde.org>

On Tuesday 11 March 2008, Carlo wrote:
> On Tue, Mar 11, 2008 at 7:45 PM, Alexander Neundorf <neundorf at kde.org> 
wrote:
> > On Tuesday 11 March 2008, Carlo wrote:
> >  > Hi, i've added a page in techbase with instruction to crosscompile kde
> >  > for windows from linux
> >  > http://techbase.kde.org/index.php?title=Getting_Started/Build/KDE4/Win
> >  >dows/ CrossCompiling and i've linked it to
> >
> >  Wow, _very_ cool ! :-)
> >
> >  Some questions:
> >
> >  Why do you need to preset all the variables starting with
> > KDE4_INSTALL_DIR, especially the KDE4_XXX_LIBRARY variables ?
>
> KDE4_INSTALL_DIR is just for convenience so you don't have to modify

Why do you have to set CMAKE_MODULE_PATH ? This really shouldn't be necessary. 
It is set at the top of kdelibs/CMakeLists.txt. What doesn't work there ?

Why do you set the KDE4_xxx_LIBRARY variables ? They also really shouldn't be 
necessary. What are the errors ?

> the path for all set, I have to specify some kde/qt library because
> cmake can't find them itself and 
> i have disabled dnssd/avahi etc..

That's ok.

> because cmake find the linux one and think that it's good

This shouldn't happen.
For which packages does it find the wrong versions ?
Can you please post the complete list, with the location of the windows 
versions and what cmake found ?
(maybe these are packages where pkg-config is used...)

> >  Some comments:
> >  > you have to make a link to your kde4automoc for linux in the bin
> >  > directory
> >
> >  we should be able to fix that...
> >
> >  > since linux is case sensitive you have to make symbolic links for some
> >  > headers
> >
> >  Can't this be corrected in the source files where the headers are
> > included ?
>
> yeah this can be fixed in the source file too(maybe soprano would
> require an ifdef since there are both soprano and Soprano on linux),
> but link was easier to do

We should definitely fix it. 
Can you commit or do you have to create a patch ?

> >  > You will get a linker error on kjsembed so from the build directory cd
> >  > into kjsembed/kjsembed and make VERBOSE=1 2>/dev/null
> >
> >  what's the problem here with linking ?
> >  This shouldn't happen, we have to fix it.
>
> it's a long linker error about QtUiTools it can't find anything
> related to qt(QString, QDataStream etc..)

Can you please post the linker command and the complete error message ?

> >  > You will get another error in klauncher.moc about slotKDEInitData so
> >  > go into kinit and do something like this(you need wine)
> >
> >  What's the exact problem here ?
> >  Does the Windows moc have to be used ? Why ?
>
> slotKDEInitData doesn't exist on windows
> http://lxr.kde.org/source/KDE/kdelibs/kinit/klauncher.h#179 but
> kde4automoc thinks that we are on linux maybe, so maybe we should use
> the windows version for everything

Hmm, if we are cross compiling to Windows Q_WS_WIN should be defined.
Can you find out why it isn't ?

> >  > Another error in kdewidgets because wine doesn't find some dll to run
> >  > makekdewidgets.exe so either run the linux version manually like this
> >
> >  So you run the generated executables using wine ? Interesting. The idea
> > was to use "native" executables if cross compiling. But if it works, ok.
> >
> >  Alex
>
> for some strange reason for kde4automoc it calls ../bin/kde4automoc
> instead of ../bin/kde4automoc.exe one that's why i made the link in
> the bin dir, but for makekdewidgets it wants to use the exe one

Can you please have a look at FindKDE4Internal.cmake.
There you will find this code:

if (_kdeBootStrapping)
   set(KDE4_INCLUDE_DIR ${kdelibs_SOURCE_DIR})
   set(KDE4_KDECORE_LIBS ${QT_QTCORE_LIBRARY} kdecore)
   ...
   if (WIN32)
      set(LIBRARY_OUTPUT_PATH            ${EXECUTABLE_OUTPUT_PATH} )
      ...
   else (WIN32)
      set(LIBRARY_OUTPUT_PATH            ${CMAKE_BINARY_DIR}/lib )
      ...
   endif (WIN32)

which branch does it enter here ?
I assume it goes into the else() branch, which is wrong for cross compiling to 
Windows.
Does it change if you replace the
if(WIN32)
with 
if (CMAKE_SYSTEM MATCHES Windows) 
?

(when cross compiling CMAKE_SYSTEM is for the target system, CMAKE_HOST_SYSTEM 
is for the build host, WIN32, UNIX and APPLE are for the build host).

Alex


From kde-dev at emailgoeshere.com  Tue Mar 11 22:51:22 2008
From: kde-dev at emailgoeshere.com (Jeff Mitchell)
Date: Tue, 11 Mar 2008 17:51:22 -0400
Subject: Build error
Message-ID: <47D6FEDA.4050607@emailgoeshere.com>

Hey guys,

I've been getting this error for over a week.  I've tried doing 
everything, even up through removing the whole build tree and starting 
over, but to no avail.  Happens when building kdebase-apps, after 
kdelibs and kdepimlibs and kdebase-runtime have built successfully.  Any 
ideas?

Thanks,
Jeff

[ 52%] Building CXX object 
konqueror/src/tests/CMakeFiles/konqhtmltest.dir/konqhtmltest.obj
konqhtmltest.cpp
Linking CXX executable konqhtmltest.exe
   Creating library konqhtmltest.lib and object konqhtmltest.exp
konqhtmltest.obj : error LNK2001: unresolved external symbol "public: 
virtual void __thiscall KonqFrameContainerBase::re
placeChildFrame(class KonqFrameBase *,class KonqFrameBase *)" 
(?replaceChildFrame at KonqFrameContainerBase@@UAEXPAVKonqFra
meBase@@0 at Z)
konqhtmltest.exe : fatal error LNK1120: 1 unresolved externals
NMAKE : fatal error U1077: 'C:\PROGRA~1\MID05A~1\VC\bin\cl.exe' : return 
code '0x2'
Stop.
NMAKE : fatal error U1077: '"K:\Microsoft Platform SDK for Windows 
Server 2003 R2\bin\nmake.exe"' : return code '0x2'
Stop.
NMAKE : fatal error U1077: '"K:\Microsoft Platform SDK for Windows 
Server 2003 R2\bin\nmake.exe"' : return code '0x2'
Stop.
emerge fatal error: while Make'ing. cmd: nmake
emerge fatal error: running python 
k:\kderoot\emerge\portage\kde\kdebase-apps\kdebase-apps-20080202.py compile
emerge error: fatal error: package kde/kdebase-apps-20080202 all failed


From Ch.Ehrlicher at gmx.de  Tue Mar 11 23:20:21 2008
From: Ch.Ehrlicher at gmx.de (Christian Ehrlicher)
Date: Tue, 11 Mar 2008 23:20:21 +0100
Subject: Build error
In-Reply-To: <47D6FEDA.4050607@emailgoeshere.com>
References: <47D6FEDA.4050607@emailgoeshere.com>
Message-ID: <47D705A5.1080309@gmx.de>

Jeff Mitchell schrieb:
> Hey guys,
> 
> I've been getting this error for over a week.  I've tried doing 
> everything, even up through removing the whole build tree and starting 
> over, but to no avail.  Happens when building kdebase-apps, after 
> kdelibs and kdepimlibs and kdebase-runtime have built successfully.  Any 
> ideas?
> 
svn up

Christian


From ps_ml at gmx.de  Tue Mar 11 23:41:23 2008
From: ps_ml at gmx.de (Patrick Spendrin)
Date: Tue, 11 Mar 2008 23:41:23 +0100
Subject: Error with libpng from GnuPG / gpg4win
Message-ID: <47D70A93.2060301@gmx.de>

Hi all,

Currently KDE on Windows uses libpng12.
Today I found libpng13 is provided by gpg4win which puts itself into the 
path - obviously.
Since this definitely leads to problems, please be sure to remove 
gpg4win from the path for now.
We will probably have to find a better solution sooner or later.

regards
SE

-- 
web:                 http://windows.kde.org
mailing list:        kde-windows at kde.org
irc:                 #kde-windows (irc.freenode.net)


From brandon.ml at gmail.com  Wed Mar 12 01:49:23 2008
From: brandon.ml at gmail.com (Carlo)
Date: Wed, 12 Mar 2008 01:49:23 +0100
Subject: Cross compiling page in techbase
In-Reply-To: <200803112147.40156.neundorf@kde.org>
References: <3262b6180803101724g4f454a71vc029d65f2d85df9d@mail.gmail.com>
	<200803111945.28725.neundorf@kde.org>
	<3262b6180803111210ta39549eo8abed62601b00876@mail.gmail.com>
	<200803112147.40156.neundorf@kde.org>
Message-ID: <3262b6180803111749ge1db0acsbe1fac60395d45dc@mail.gmail.com>

On Tue, Mar 11, 2008 at 9:47 PM, Alexander Neundorf <neundorf at kde.org> wrote:
> On Tuesday 11 March 2008, Carlo wrote:
>  > On Tue, Mar 11, 2008 at 7:45 PM, Alexander Neundorf <neundorf at kde.org>
>  wrote:
>  > > On Tuesday 11 March 2008, Carlo wrote:
>  > >  > Hi, i've added a page in techbase with instruction to crosscompile kde
>  > >  > for windows from linux
>  > >  > http://techbase.kde.org/index.php?title=Getting_Started/Build/KDE4/Win
>  > >  >dows/ CrossCompiling and i've linked it to
>
> > >
>  > >  Wow, _very_ cool ! :-)
>  > >
>  > >  Some questions:
>  > >
>  > >  Why do you need to preset all the variables starting with
>  > > KDE4_INSTALL_DIR, especially the KDE4_XXX_LIBRARY variables ?
>  >
>  > KDE4_INSTALL_DIR is just for convenience so you don't have to modify
>
>  Why do you have to set CMAKE_MODULE_PATH ? This really shouldn't be necessary.
>  It is set at the top of kdelibs/CMakeLists.txt. What doesn't work there ?
>
>  Why do you set the KDE4_xxx_LIBRARY variables ? They also really shouldn't be
>  necessary. What are the errors ?
Yeah that's unnecessary, i set that because i've seen this line  when
running cmake
-- Adding /home/kdeuser/kde/share/apps/cmake/modules to CMAKE_MODULE_PATH
and that's the linux kde4 modules dir so i tought  that it could
conflict with the windows one and cant' automatically find
KDE4_xxx_LIBRARY for that reason but it adds that line anyway  in
FindQt4 iirc

if I don't set KDE4_KDECORE_LIBRARY cmake gives this error
CMake Error: ERROR: could NOT find everything required for compiling
KDE 4 programs

while for other libraries it says something like this
KDE4_PHONON_LIBRARY
   linked by target "knotify" in directory
/home/kdeuser/kde/src/KDE/kdebase/runtime/knotify
   linked by target "konq_sound" in directory
/home/kdeuser/kde/src/KDE/kdebase/apps/lib/konq
>  > the path for all set, I have to specify some kde/qt library because
>  > cmake can't find them itself and
>  > i have disabled dnssd/avahi etc..
>
>  That's ok.
>
>
>  > because cmake find the linux one and think that it's good
>
>  This shouldn't happen.
>  For which packages does it find the wrong versions ?
>  Can you please post the complete list, with the location of the windows
>  versions and what cmake found ?
>  (maybe these are packages where pkg-config is used...)
 the problem is GSSAPI, this is what cmake found
 GSSAPI_FLAVOR                    MIT
 GSSAPI_INCS
 GSSAPI_LIBS                      -L/usr/lib -lgssapi_krb5 -lkrb5
-lk5crypto -lcom_err

i don't have gssapi and the other libraries that i've disabled on
windows(and they don't exist in the kdewin installer either)
>  > >  Some comments:
>
> > >  > you have to make a link to your kde4automoc for linux in the bin
>  > >  > directory
>  > >
>  > >  we should be able to fix that...
>  > >
>  > >  > since linux is case sensitive you have to make symbolic links for some
>  > >  > headers
>  > >
>  > >  Can't this be corrected in the source files where the headers are
>  > > included ?
>  >
>  > yeah this can be fixed in the source file too(maybe soprano would
>  > require an ifdef since there are both soprano and Soprano on linux),
>  > but link was easier to do
>
>  We should definitely fix it.
>  Can you commit or do you have to create a patch ?
Yes i can commit i will change that includes later

>  > >  > You will get a linker error on kjsembed so from the build directory cd
>  > >  > into kjsembed/kjsembed and make VERBOSE=1 2>/dev/null
>  > >
>  > >  what's the problem here with linking ?
>  > >  This shouldn't happen, we have to fix it.
>  >
>  > it's a long linker error about QtUiTools it can't find anything
>  > related to qt(QString, QDataStream etc..)
>
>  Can you please post the linker command and the complete error message ?
this is the linker command:
Linking CXX shared library ../../bin/libkjsembed.dll
cd /home/kdeuser/kde/src/KDE/kdelibs/build/kjsembed/kjsembed &&
/usr/local/bin/cmake -E cmake_link_script
CMakeFiles/kjsembed.dir/link.txt --verbose=1
/usr/bin/i586-mingw32msvc-g++    -Wl,--export-all-symbols
-Wl,--disable-auto-import -shared -o ../../bin/libkjsembed.dll
-Wl,--out-implib,../../bin/libkjsembed.dll.a
-Wl,--major-image-version,4,--minor-image-version,1
CMakeFiles/kjsembed.dir/kjsembed_automoc.cpp.obj
CMakeFiles/kjsembed.dir/kjseglobal.cpp.obj
CMakeFiles/kjsembed.dir/binding_support.cpp.obj
CMakeFiles/kjsembed.dir/static_binding.cpp.obj
CMakeFiles/kjsembed.dir/variant_binding.cpp.obj
CMakeFiles/kjsembed.dir/object_binding.cpp.obj
CMakeFiles/kjsembed.dir/builtins.cpp.obj
CMakeFiles/kjsembed.dir/fileio.cpp.obj
CMakeFiles/kjsembed.dir/jseventmapper.cpp.obj
CMakeFiles/kjsembed.dir/eventproxy.cpp.obj
CMakeFiles/kjsembed.dir/slotproxy.cpp.obj
CMakeFiles/kjsembed.dir/jseventutils.cpp.obj
CMakeFiles/kjsembed.dir/qobject_binding.cpp.obj
CMakeFiles/kjsembed.dir/kjsembed.cpp.obj
CMakeFiles/kjsembed.dir/value_binding.cpp.obj
CMakeFiles/kjsembed.dir/iosupport.cpp.obj
CMakeFiles/kjsembed.dir/qwidget_binding.cpp.obj
CMakeFiles/kjsembed.dir/qaction_binding.cpp.obj
CMakeFiles/kjsembed.dir/qlayout_binding.cpp.obj
CMakeFiles/kjsembed.dir/qpainter_binding.cpp.obj
CMakeFiles/kjsembed.dir/settings.cpp.obj
CMakeFiles/kjsembed.dir/svg_binding.cpp.obj
CMakeFiles/kjsembed.dir/filedialog_binding.cpp.obj
CMakeFiles/kjsembed.dir/application.cpp.obj
CMakeFiles/kjsembed.dir/color.cpp.obj
CMakeFiles/kjsembed.dir/dom.cpp.obj
CMakeFiles/kjsembed.dir/font.cpp.obj
CMakeFiles/kjsembed.dir/image.cpp.obj
CMakeFiles/kjsembed.dir/pen.cpp.obj
CMakeFiles/kjsembed.dir/pixmap.cpp.obj
CMakeFiles/kjsembed.dir/point.cpp.obj
CMakeFiles/kjsembed.dir/rect.cpp.obj
CMakeFiles/kjsembed.dir/size.cpp.obj
CMakeFiles/kjsembed.dir/url.cpp.obj
CMakeFiles/kjsembed.dir/bind_qlcdnumber.cpp.obj
CMakeFiles/kjsembed.dir/bind_qtimer.cpp.obj
CMakeFiles/kjsembed.dir/brush.cpp.obj
CMakeFiles/kjsembed.dir/QBrush_bind.cpp.obj
CMakeFiles/kjsembed.dir/quiloader_binding.cpp.obj -L/windows/kde4/lib
../../bin/libkdecore.dll.a /windows/kde4/lib/libQtCore4.a
/windows/kde4/lib/libQtUiTools.a /windows/kde4/lib/libQtGui4.a
/windows/kde4/lib/libQtSvg4.a ../../bin/libkjs.dll.a
/windows/kde4/lib/libQtNetwork4.a /windows/kde4/lib/libQtDBus4.a
/windows/kde4/lib/libz.dll.a /windows/kde4/lib/libkdewin32.dll.a
-luser32 -lshell32 -lws2_32 -lnetapi32 -luserenv
/windows/kde4/lib/libQtXml4.a /windows/kde4/lib/libbzip2.dll.a
/windows/kde4/lib/libintl.dll.a /windows/kde4/lib/libpcre.dll.a
/windows/kde4/lib/libpcreposix.dll.a


and this is the long error message http://kde.pastebin.com/f3aa4d4f6

>
>  > >  > You will get another error in klauncher.moc about slotKDEInitData so
>  > >  > go into kinit and do something like this(you need wine)
>  > >
>  > >  What's the exact problem here ?
>  > >  Does the Windows moc have to be used ? Why ?
>  >
>  > slotKDEInitData doesn't exist on windows
>  > http://lxr.kde.org/source/KDE/kdelibs/kinit/klauncher.h#179 but
>  > kde4automoc thinks that we are on linux maybe, so maybe we should use
>  > the windows version for everything
>
>  Hmm, if we are cross compiling to Windows Q_WS_WIN should be defined.
>  Can you find out why it isn't ?
Q_WS_WIN is defined when compiling but not in moc, probably it has
hardcoded parameters from the platform where it was compiled

>  > >  > Another error in kdewidgets because wine doesn't find some dll to run
>  > >  > makekdewidgets.exe so either run the linux version manually like this
>  > >
>  > >  So you run the generated executables using wine ? Interesting. The idea
>  > > was to use "native" executables if cross compiling. But if it works, ok.
>  > >
>  > >  Alex
>  >
>  > for some strange reason for kde4automoc it calls ../bin/kde4automoc
>  > instead of ../bin/kde4automoc.exe one that's why i made the link in
>  > the bin dir, but for makekdewidgets it wants to use the exe one
>
>  Can you please have a look at FindKDE4Internal.cmake.
>  There you will find this code:
>
>  if (_kdeBootStrapping)
>    set(KDE4_INCLUDE_DIR ${kdelibs_SOURCE_DIR})
>    set(KDE4_KDECORE_LIBS ${QT_QTCORE_LIBRARY} kdecore)
>    ...
>    if (WIN32)
>       set(LIBRARY_OUTPUT_PATH            ${EXECUTABLE_OUTPUT_PATH} )
>       ...
>    else (WIN32)
>       set(LIBRARY_OUTPUT_PATH            ${CMAKE_BINARY_DIR}/lib )
>       ...
>    endif (WIN32)
>
>  which branch does it enter here ?
>  I assume it goes into the else() branch, which is wrong for cross compiling to
>  Windows.
>  Does it change if you replace the
>  if(WIN32)
>  with
>  if (CMAKE_SYSTEM MATCHES Windows)
>  ?
>
>  (when cross compiling CMAKE_SYSTEM is for the target system, CMAKE_HOST_SYSTEM
>  is for the build host, WIN32, UNIX and APPLE are for the build host).
>
>  Alex
>
it works either with WIN32 or with CMAKE_SYSTEM so the problem is not there


From Ch.Ehrlicher at gmx.de  Wed Mar 12 06:30:25 2008
From: Ch.Ehrlicher at gmx.de (Christian Ehrlicher)
Date: Wed, 12 Mar 2008 06:30:25 +0100
Subject: Error with libpng from GnuPG / gpg4win
In-Reply-To: <47D70A93.2060301@gmx.de>
References: <47D70A93.2060301@gmx.de>
Message-ID: <47D76A71.6050305@gmx.de>

Patrick Spendrin schrieb:
> Hi all,
> 
> Currently KDE on Windows uses libpng12.
> Today I found libpng13 is provided by gpg4win which puts itself into the 
> path - obviously.
> Since this definitely leads to problems, please be sure to remove 
> gpg4win from the path for now.
> We will probably have to find a better solution sooner or later.
> 
Don't understand the problem - do you link directly against the dll?


Christian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 258 bytes
Desc: OpenPGP digital signature
Url : http://mail.kde.org/pipermail/kde-windows/attachments/20080312/4dfe6c7b/attachment.pgp 

From ps_ml at gmx.de  Wed Mar 12 11:12:58 2008
From: ps_ml at gmx.de (Patrick Spendrin)
Date: Wed, 12 Mar 2008 11:12:58 +0100
Subject: Error with libpng from GnuPG / gpg4win
In-Reply-To: <47D76A71.6050305@gmx.de>
References: <47D70A93.2060301@gmx.de> <47D76A71.6050305@gmx.de>
Message-ID: <47D7ACAA.3040609@gmx.de>

Christian Ehrlicher schrieb:
> Patrick Spendrin schrieb:
>> Hi all,
>>
>> Currently KDE on Windows uses libpng12.
>> Today I found libpng13 is provided by gpg4win which puts itself into 
>> the path - obviously.
>> Since this definitely leads to problems, please be sure to remove 
>> gpg4win from the path for now.
>> We will probably have to find a better solution sooner or later.
>>
> Don't understand the problem - do you link directly against the dll?
I was rebuilding yesterday and just seconds before I wondered where this 
strange linker error might come from I saw that cmake found the wrong 
png dll. Thus I just wanted to put a warning here and a reminder that we 
need to fix this (e.g. for kgpg etc.)
> 
> 
> Christian
Patrick
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Kde-windows mailing list
> Kde-windows at kde.org
> https://mail.kde.org/mailman/listinfo/kde-windows


-- 
web:                 http://windows.kde.org
mailing list:        kde-windows at kde.org
irc:                 #kde-windows (irc.freenode.net)


From Ch.Ehrlicher at gmx.de  Wed Mar 12 12:13:05 2008
From: Ch.Ehrlicher at gmx.de (Christian Ehrlicher)
Date: Wed, 12 Mar 2008 12:13:05 +0100
Subject: Error with libpng from GnuPG / gpg4win
In-Reply-To: <47D7ACAA.3040609@gmx.de>
References: <47D70A93.2060301@gmx.de> <47D76A71.6050305@gmx.de>
	<47D7ACAA.3040609@gmx.de>
Message-ID: <20080312111305.100230@gmx.net>

> Von: Patrick Spendrin 
> Christian Ehrlicher schrieb:
> > Patrick Spendrin schrieb:
> >> Hi all,
> >>
> >> Currently KDE on Windows uses libpng12.
> >> Today I found libpng13 is provided by gpg4win which puts itself into 
> >> the path - obviously.
> >> Since this definitely leads to problems, please be sure to remove 
> >> gpg4win from the path for now.
> >> We will probably have to find a better solution sooner or later.
> >>
> > Don't understand the problem - do you link directly against the dll?
> I was rebuilding yesterday and just seconds before I wondered where this 
> strange linker error might come from I saw that cmake found the wrong 
> png dll. Thus I just wanted to put a warning here and a reminder that we 
> need to fix this (e.g. for kgpg etc.)
cmake picked up the .dll instead .a ? That's strange - can you plz send me a small testcase?

Thx,
Christian

-- 
GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen!
Jetzt dabei sein: http://www.shortview.de/?mc=sv_ext_mf at gmx


From neundorf at kde.org  Wed Mar 12 18:31:23 2008
From: neundorf at kde.org (Alexander Neundorf)
Date: Wed, 12 Mar 2008 18:31:23 +0100
Subject: Cross compiling page in techbase
In-Reply-To: <3262b6180803111749ge1db0acsbe1fac60395d45dc@mail.gmail.com>
References: <3262b6180803101724g4f454a71vc029d65f2d85df9d@mail.gmail.com>
	<200803112147.40156.neundorf@kde.org>
	<3262b6180803111749ge1db0acsbe1fac60395d45dc@mail.gmail.com>
Message-ID: <200803121831.23535.neundorf@kde.org>

Hi,

On Wednesday 12 March 2008, Carlo wrote:
> On Tue, Mar 11, 2008 at 9:47 PM, Alexander Neundorf <neundorf at kde.org> 
wrote:
> > On Tuesday 11 March 2008, Carlo wrote:
> >  > On Tue, Mar 11, 2008 at 7:45 PM, Alexander Neundorf <neundorf at kde.org>
> >
> >  wrote:
> >  > > On Tuesday 11 March 2008, Carlo wrote:
> >  > >  > Hi, i've added a page in techbase with instruction to
> >  > >  > crosscompile kde for windows from linux
> >  > >  > http://techbase.kde.org/index.php?title=Getting_Started/Build/KDE
> >  > >  >4/Win dows/ CrossCompiling and i've linked it to
> >  > >
> >  > >  Wow, _very_ cool ! :-)
> >  > >
> >  > >  Some questions:
> >  > >
> >  > >  Why do you need to preset all the variables starting with
> >  > > KDE4_INSTALL_DIR, especially the KDE4_XXX_LIBRARY variables ?
> >  >
> >  > KDE4_INSTALL_DIR is just for convenience so you don't have to modify
> >
> >  Why do you have to set CMAKE_MODULE_PATH ? This really shouldn't be
> > necessary. It is set at the top of kdelibs/CMakeLists.txt. What doesn't
> > work there ?
> >
> >  Why do you set the KDE4_xxx_LIBRARY variables ? They also really
> > shouldn't be necessary. What are the errors ?
>
> Yeah that's unnecessary, i set that because i've seen this line  when
> running cmake
> -- Adding /home/kdeuser/kde/share/apps/cmake/modules to CMAKE_MODULE_PATH
> and that's the linux kde4 modules dir so i tought  that it could
> conflict with the windows one and cant' automatically find
> KDE4_xxx_LIBRARY for that reason but it adds that line anyway  in
> FindQt4 iirc
>
> if I don't set KDE4_KDECORE_LIBRARY cmake gives this error
> CMake Error: ERROR: could NOT find everything required for compiling
> KDE 4 programs
>
> while for other libraries it says something like this
> KDE4_PHONON_LIBRARY
>    linked by target "knotify" in directory
> /home/kdeuser/kde/src/KDE/kdebase/runtime/knotify
>    linked by target "konq_sound" in directory
> /home/kdeuser/kde/src/KDE/kdebase/apps/lib/konq

Ahh, so this is already in kdebase.
I have split your file into two parts: 
Toolchain-mingw32.cmake which has to be used as toolchain file for every KDE 
module (i.e. also kdelibs) and mingw32-kdelibs.cmake which contains settings 
which should come from the installed kdelibs (i.e. it must not be used for 
kdelibs). 
The problem here was that FindKDE4.cmake runs kde4-config and checks what this 
returns.
I attached a modified FindKDE4.cmake file which only executes kde4-config if 
KDE4_DATA_DIR is not set. 
So by setting KDE4_DATA_DIR in mingw32-kdelibs.cmake this FindKDE4.cmake 
should work as expected for cross compiling.
I forgot, so you have to use Toolchain-mingw32.cmake 
with -DCMAKE_TOOLCHAIN_FILE=..., and the other file to preload the cmake 
cache, which is done using -C <filename>.
So for kdebase you would need something like:

cmake -DCMAKE_TOOLCHAIN_FILE=<path>/Toolchain-mingw32.cmake -C 
<path>/mingw32-kdelibs.cmake <src dir>

> >  > the path for all set, I have to specify some kde/qt library because
> >  > cmake can't find them itself and
> >  > i have disabled dnssd/avahi etc..
> >
> >  That's ok.
> >
> >  > because cmake find the linux one and think that it's good
> >
> >  This shouldn't happen.
> >  For which packages does it find the wrong versions ?
> >  Can you please post the complete list, with the location of the windows
> >  versions and what cmake found ?
> >  (maybe these are packages where pkg-config is used...)
>
>  the problem is GSSAPI, this is what cmake found
>  GSSAPI_FLAVOR                    MIT
>  GSSAPI_INCS
>  GSSAPI_LIBS                      -L/usr/lib -lgssapi_krb5 -lkrb5
> -lk5crypto -lcom_err
>
> i don't have gssapi and the other libraries that i've disabled on
> windows(and they don't exist in the kdewin installer either)

The problem here is that FindGSSAPI.cmake runs krb5-config and querys this for 
information. Problem is that when cross compiling in general the executables 
from the target cannot be executed. 
We'll care for this one later.

> >  > >  Some comments:
> > > >  > you have to make a link to your kde4automoc for linux in the bin
> > > >  >
> >  > >  > directory
> >  > >
> >  > >  we should be able to fix that...
> >  > >
> >  > >  > since linux is case sensitive you have to make symbolic links for
> >  > >  > some headers
> >  > >
> >  > >  Can't this be corrected in the source files where the headers are
> >  > > included ?
> >  >
> >  > yeah this can be fixed in the source file too(maybe soprano would
> >  > require an ifdef since there are both soprano and Soprano on linux),
> >  > but link was easier to do
> >
> >  We should definitely fix it.
> >  Can you commit or do you have to create a patch ?
>
> Yes i can commit i will change that includes later

Yes, please do :-)

> >  > >  > You will get a linker error on kjsembed so from the build
> >  > >  > directory cd into kjsembed/kjsembed and make VERBOSE=1
> >  > >  > 2>/dev/null
> >  > >
> >  > >  what's the problem here with linking ?
> >  > >  This shouldn't happen, we have to fix it.
> >  >
> >  > it's a long linker error about QtUiTools it can't find anything
> >  > related to qt(QString, QDataStream etc..)
> >
> >  Can you please post the linker command and the complete error message ?
>
> this is the linker command:
> Linking CXX shared library ../../bin/libkjsembed.dll
> cd /home/kdeuser/kde/src/KDE/kdelibs/build/kjsembed/kjsembed &&
> /usr/local/bin/cmake -E cmake_link_script
> CMakeFiles/kjsembed.dir/link.txt --verbose=1
> /usr/bin/i586-mingw32msvc-g++    -Wl,--export-all-symbols
> -Wl,--disable-auto-import -shared -o ../../bin/libkjsembed.dll
> -Wl,--out-implib,../../bin/libkjsembed.dll.a
> -Wl,--major-image-version,4,--minor-image-version,1
> CMakeFiles/kjsembed.dir/kjsembed_automoc.cpp.obj
> CMakeFiles/kjsembed.dir/kjseglobal.cpp.obj
> CMakeFiles/kjsembed.dir/binding_support.cpp.obj
...
> CMakeFiles/kjsembed.dir/quiloader_binding.cpp.obj -L/windows/kde4/lib
> ../../bin/libkdecore.dll.a /windows/kde4/lib/libQtCore4.a
> /windows/kde4/lib/libQtUiTools.a /windows/kde4/lib/libQtGui4.a
> /windows/kde4/lib/libQtSvg4.a ../../bin/libkjs.dll.a
> /windows/kde4/lib/libQtNetwork4.a /windows/kde4/lib/libQtDBus4.a
> /windows/kde4/lib/libz.dll.a /windows/kde4/lib/libkdewin32.dll.a
> -luser32 -lshell32 -lws2_32 -lnetapi32 -luserenv
> /windows/kde4/lib/libQtXml4.a /windows/kde4/lib/libbzip2.dll.a
> /windows/kde4/lib/libintl.dll.a /windows/kde4/lib/libpcre.dll.a
> /windows/kde4/lib/libpcreposix.dll.a
>
>
> and this is the long error message http://kde.pastebin.com/f3aa4d4f6

Ok. This is as far as I see always undefined references from QtUiTools to 
QtCore:
> /windows/kde4/lib/libQtUiTools.a(quiloader.o):quiloader.cpp:(.text+0x7fd):
> undefined reference to `__imp___ZNK7QString6toUtf8Ev'

Which value does QT_QTUITOOLS_LIBRARY have ?

> >  > >  > You will get another error in klauncher.moc about slotKDEInitData
> >  > >  > so go into kinit and do something like this(you need wine)
> >  > >
> >  > >  What's the exact problem here ?
> >  > >  Does the Windows moc have to be used ? Why ?
> >  >
> >  > slotKDEInitData doesn't exist on windows
> >  > http://lxr.kde.org/source/KDE/kdelibs/kinit/klauncher.h#179 but
> >  > kde4automoc thinks that we are on linux maybe, so maybe we should use
> >  > the windows version for everything
> >
> >  Hmm, if we are cross compiling to Windows Q_WS_WIN should be defined.
> >  Can you find out why it isn't ?
>
> Q_WS_WIN is defined when compiling but not in moc, probably it has
> hardcoded parameters from the platform where it was compiled

Hmm, that sounds bad. Let's care about this later.

> >  > >  > Another error in kdewidgets because wine doesn't find some dll to
> >  > >  > run makekdewidgets.exe so either run the linux version manually
> >  > >  > like this
> >  > >
> >  > >  So you run the generated executables using wine ? Interesting. The
> >  > > idea was to use "native" executables if cross compiling. But if it
> >  > > works, ok.
> >  > >
> >  > >  Alex
> >  >
> >  > for some strange reason for kde4automoc it calls ../bin/kde4automoc
> >  > instead of ../bin/kde4automoc.exe one that's why i made the link in

Is the .exe extension really required to run the executable ?
Under Windows it isn't. Is this a wine speciality ?

I'd really like to get this working cleanly, it's still time to fix things in 
cmake for cross compiling, 2.6.0 hasn't been released yet.

Alex
-------------- next part --------------
# Find KDE4 and provide all necessary variables and macros to compile software for it.
# It looks for KDE 4 in the following directories in the given order:
#  CMAKE_INSTALL_PREFIX
#  KDEDIRS
#  /opt/kde4
#
# Please look in FindKDE4Internal.cmake and KDE4Macros.cmake for more information.
# They are installed with the KDE 4 libraries in $KDEDIRS/share/apps/cmake/modules/.
#
# Author: Alexander Neundorf <neundorf at kde.org>

FILE(TO_CMAKE_PATH "$ENV{KDEDIRS}" _KDEDIRS)

# For KDE4 kde-config has been renamed to kde4-config
FIND_PROGRAM(KDE4_KDECONFIG_EXECUTABLE NAMES kde4-config
   PATH_SUFFIXES bin               # the suffix is for the paths coming from KDEDIRS
   PATHS
   ${CMAKE_INSTALL_PREFIX}/bin
   ${_KDEDIRS}
   /opt/kde4/bin
   NO_DEFAULT_PATH
   )

FIND_PROGRAM(KDE4_KDECONFIG_EXECUTABLE NAMES kde4-config )

IF (NOT KDE4_KDECONFIG_EXECUTABLE)
   IF (KDE4_FIND_REQUIRED)
      MESSAGE(FATAL_ERROR "ERROR: Could not find KDE4 kde4-config")
   ENDIF (KDE4_FIND_REQUIRED)
ENDIF (NOT KDE4_KDECONFIG_EXECUTABLE)


# when cross compiling, it may be already preset
IF(NOT KDE4_DATA_DIR)
   # then ask kde4-config for the kde data dirs
   EXECUTE_PROCESS(COMMAND "${KDE4_KDECONFIG_EXECUTABLE}" --path data OUTPUT_VARIABLE _data_DIR ERROR_QUIET OUTPUT_STRIP_TRAILING_WHITESPACE)
   FILE(TO_CMAKE_PATH "${_data_DIR}" _data_DIR)
   # then check the data dirs for FindKDE4Internal.cmake
   FIND_PATH(KDE4_DATA_DIR cmake/modules/FindKDE4Internal.cmake ${_data_DIR})
ENDIF(NOT KDE4_DATA_DIR)

# if it has been found...
IF (KDE4_DATA_DIR)

   SET(CMAKE_MODULE_PATH  ${CMAKE_MODULE_PATH} ${KDE4_DATA_DIR}/cmake/modules)

   IF (KDE4_FIND_QUIETLY)
      SET(_quiet QUIET)
   ENDIF (KDE4_FIND_QUIETLY)

   IF (KDE4_FIND_REQUIRED)
      SET(_req REQUIRED)
   ENDIF (KDE4_FIND_REQUIRED)

   # use FindKDE4Internal.cmake to do the rest
   FIND_PACKAGE(KDE4Internal ${_req} ${_quiet})
ELSE (KDE4_DATA_DIR)
   IF (KDE4_FIND_REQUIRED)
      MESSAGE(FATAL_ERROR "ERROR: cmake/modules/FindKDE4Internal.cmake not found in ${_data_DIR}")
   ENDIF (KDE4_FIND_REQUIRED)
ENDIF (KDE4_DATA_DIR)
-------------- next part --------------
# the name of the target operating system
SET(CMAKE_SYSTEM_NAME Windows)
 
# which compilers to use for C and C++
SET(CMAKE_C_COMPILER i586-mingw32msvc-gcc)
SET(CMAKE_CXX_COMPILER i586-mingw32msvc-g++)
 
# here is the target environment located
SET(CMAKE_FIND_ROOT_PATH  /usr/i586-mingw32msvc /windows/kde4 )
 
# adjust the default behaviour of the FIND_XXX() commands:
# search headers and libraries in the target environment, search 
# programs in the host environment
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
 
# FindQt4.cmake querys qmake to get information, this doesn't work when crosscompiling
set(QT_BINARY_DIR   /home/kdeuser/kde/src/qt-copy/bin)
set(QT_LIBRARY_DIR  ${KDE4_INSTALL_DIR}/lib)
set(QT_QTCORE_LIBRARY   ${KDE4_INSTALL_DIR}/lib/libQtCore4.a)
set(QT_QTCORE_INCLUDE_DIR ${KDE4_INSTALL_DIR}/include/QtCore)
set(QT_MKSPECS_DIR  ${KDE4_INSTALL_DIR}/mkspecs)
set(QT_MOC_EXECUTABLE  ${QT_BINARY_DIR}/moc)
set(QT_QMAKE_EXECUTABLE  ${QT_BINARY_DIR}/qmake)
set(QT_UIC_EXECUTABLE  ${QT_BINARY_DIR}/uic)

-------------- next part --------------
# this one is used by FindKDE4.cmake to load FindKDE4Internal.cmake:
set(KDE4_DATA_DIR    /windows/kde4/share/apps CACHE PATH "points to the apps directory of installed kdelibs")

# not sure about this one:
set(KDEWIN_DIR ${KDE4_INSTALL_DIR} CACHE PATH "what is it ?")


# disable some things:
set(WITH_AVAHI OFF   CACHE BOOL "Disabled")
set(WITH_DNSSD OFF   CACHE BOOL "Disabled")
set(WITH_ENCHANT OFF CACHE BOOL "Disabled")
set(WITH_FAM OFF     CACHE BOOL "Disabled")
set(WITH_GSSAPI OFF  CACHE BOOL "Disabled")
set(WITH_HSPELL OFF  CACHE BOOL "Disabled")
set(WITH_OpenEXR OFF CACHE BOOL "Disabled")


From brandon.ml at gmail.com  Wed Mar 12 23:18:30 2008
From: brandon.ml at gmail.com (Carlo)
Date: Wed, 12 Mar 2008 23:18:30 +0100
Subject: Cross compiling page in techbase
In-Reply-To: <200803121831.23535.neundorf@kde.org>
References: <3262b6180803101724g4f454a71vc029d65f2d85df9d@mail.gmail.com>
	<200803112147.40156.neundorf@kde.org>
	<3262b6180803111749ge1db0acsbe1fac60395d45dc@mail.gmail.com>
	<200803121831.23535.neundorf@kde.org>
Message-ID: <3262b6180803121518u7a8c5f73x2650ce4686d74a9c@mail.gmail.com>

On Wed, Mar 12, 2008 at 6:31 PM, Alexander Neundorf <neundorf at kde.org> wrote:
> Hi,
>
>
>
>  On Wednesday 12 March 2008, Carlo wrote:
>  > On Tue, Mar 11, 2008 at 9:47 PM, Alexander Neundorf <neundorf at kde.org>
>  wrote:
>  > > On Tuesday 11 March 2008, Carlo wrote:
>  > >  > On Tue, Mar 11, 2008 at 7:45 PM, Alexander Neundorf <neundorf at kde.org>
>  > >
>  > >  wrote:
>  > >  > > On Tuesday 11 March 2008, Carlo wrote:
>  > >  > >  > Hi, i've added a page in techbase with instruction to
>  > >  > >  > crosscompile kde for windows from linux
>  > >  > >  > http://techbase.kde.org/index.php?title=Getting_Started/Build/KDE
>  > >  > >  >4/Win dows/ CrossCompiling and i've linked it to
>  > >  > >
>  > >  > >  Wow, _very_ cool ! :-)
>  > >  > >
>  > >  > >  Some questions:
>  > >  > >
>  > >  > >  Why do you need to preset all the variables starting with
>  > >  > > KDE4_INSTALL_DIR, especially the KDE4_XXX_LIBRARY variables ?
>  > >  >
>  > >  > KDE4_INSTALL_DIR is just for convenience so you don't have to modify
>  > >
>  > >  Why do you have to set CMAKE_MODULE_PATH ? This really shouldn't be
>  > > necessary. It is set at the top of kdelibs/CMakeLists.txt. What doesn't
>  > > work there ?
>  > >
>  > >  Why do you set the KDE4_xxx_LIBRARY variables ? They also really
>  > > shouldn't be necessary. What are the errors ?
>  >
>  > Yeah that's unnecessary, i set that because i've seen this line  when
>  > running cmake
>  > -- Adding /home/kdeuser/kde/share/apps/cmake/modules to CMAKE_MODULE_PATH
>  > and that's the linux kde4 modules dir so i tought  that it could
>  > conflict with the windows one and cant' automatically find
>  > KDE4_xxx_LIBRARY for that reason but it adds that line anyway  in
>  > FindQt4 iirc
>  >
>  > if I don't set KDE4_KDECORE_LIBRARY cmake gives this error
>  > CMake Error: ERROR: could NOT find everything required for compiling
>  > KDE 4 programs
>  >
>  > while for other libraries it says something like this
>  > KDE4_PHONON_LIBRARY
>  >    linked by target "knotify" in directory
>  > /home/kdeuser/kde/src/KDE/kdebase/runtime/knotify
>  >    linked by target "konq_sound" in directory
>  > /home/kdeuser/kde/src/KDE/kdebase/apps/lib/konq
>
>  Ahh, so this is already in kdebase.
>  I have split your file into two parts:
>  Toolchain-mingw32.cmake which has to be used as toolchain file for every KDE
>  module (i.e. also kdelibs) and mingw32-kdelibs.cmake which contains settings
>  which should come from the installed kdelibs (i.e. it must not be used for
>  kdelibs).
>  The problem here was that FindKDE4.cmake runs kde4-config and checks what this
>  returns.
>  I attached a modified FindKDE4.cmake file which only executes kde4-config if
>  KDE4_DATA_DIR is not set.
>  So by setting KDE4_DATA_DIR in mingw32-kdelibs.cmake this FindKDE4.cmake
>  should work as expected for cross compiling.
>  I forgot, so you have to use Toolchain-mingw32.cmake
>  with -DCMAKE_TOOLCHAIN_FILE=..., and the other file to preload the cmake
>  cache, which is done using -C <filename>.
>  So for kdebase you would need something like:
>
>  cmake -DCMAKE_TOOLCHAIN_FILE=<path>/Toolchain-mingw32.cmake -C
>  <path>/mingw32-kdelibs.cmake <src dir>
you forgot set(KDE4_INSTALL_DIR    /windows/kde4) in the toolchain file
anyway it doesn't work, this is the erorr
-- ERROR: unable to find KDE 4 headers
-- ERROR: unable to find KDE 4 core library

in FindKDE4Internal.cmake
find_path(KDE4_INCLUDE_DIR kpassworddialog.h
${KDE4_INCLUDE_INSTALL_DIR} NO_DEFAULT_PATH )
and KDE4_INCLUDE_INSTALL_DIR is set to /home/kdeuser/kde/include but
that's the kde4 linux include not the windows one and btw
kpassworddialog.h exist in that dir
>
>  > >  > the path for all set, I have to specify some kde/qt library because
>  > >  > cmake can't find them itself and
>  > >  > i have disabled dnssd/avahi etc..
>  > >
>  > >  That's ok.
>  > >
>  > >  > because cmake find the linux one and think that it's good
>  > >
>  > >  This shouldn't happen.
>  > >  For which packages does it find the wrong versions ?
>  > >  Can you please post the complete list, with the location of the windows
>  > >  versions and what cmake found ?
>  > >  (maybe these are packages where pkg-config is used...)
>  >
>  >  the problem is GSSAPI, this is what cmake found
>  >  GSSAPI_FLAVOR                    MIT
>  >  GSSAPI_INCS
>  >  GSSAPI_LIBS                      -L/usr/lib -lgssapi_krb5 -lkrb5
>  > -lk5crypto -lcom_err
>  >
>  > i don't have gssapi and the other libraries that i've disabled on
>  > windows(and they don't exist in the kdewin installer either)
>
>  The problem here is that FindGSSAPI.cmake runs krb5-config and querys this for
>  information. Problem is that when cross compiling in general the executables
>  from the target cannot be executed.
>  We'll care for this one later.
>
>
>  > >  > >  Some comments:
>  > > > >  > you have to make a link to your kde4automoc for linux in the bin
>  > > > >  >
>  > >  > >  > directory
>  > >  > >
>  > >  > >  we should be able to fix that...
>  > >  > >
>  > >  > >  > since linux is case sensitive you have to make symbolic links for
>  > >  > >  > some headers
>  > >  > >
>  > >  > >  Can't this be corrected in the source files where the headers are
>  > >  > > included ?
>  > >  >
>  > >  > yeah this can be fixed in the source file too(maybe soprano would
>  > >  > require an ifdef since there are both soprano and Soprano on linux),
>  > >  > but link was easier to do
>  > >
>  > >  We should definitely fix it.
>  > >  Can you commit or do you have to create a patch ?
>  >
>  > Yes i can commit i will change that includes later
>
>  Yes, please do :-)
Ok i've commited, but for Soprano there are too many includes, it's
better to do a symbolic link rather then a lot of ifdefs
>
>  > >  > >  > You will get a linker error on kjsembed so from the build
>  > >  > >  > directory cd into kjsembed/kjsembed and make VERBOSE=1
>  > >  > >  > 2>/dev/null
>  > >  > >
>  > >  > >  what's the problem here with linking ?
>  > >  > >  This shouldn't happen, we have to fix it.
>  > >  >
>  > >  > it's a long linker error about QtUiTools it can't find anything
>  > >  > related to qt(QString, QDataStream etc..)
>  > >
>  > >  Can you please post the linker command and the complete error message ?
>  >
>  > this is the linker command:
>  > Linking CXX shared library ../../bin/libkjsembed.dll
>  > cd /home/kdeuser/kde/src/KDE/kdelibs/build/kjsembed/kjsembed &&
>  > /usr/local/bin/cmake -E cmake_link_script
>  > CMakeFiles/kjsembed.dir/link.txt --verbose=1
>  > /usr/bin/i586-mingw32msvc-g++    -Wl,--export-all-symbols
>  > -Wl,--disable-auto-import -shared -o ../../bin/libkjsembed.dll
>  > -Wl,--out-implib,../../bin/libkjsembed.dll.a
>  > -Wl,--major-image-version,4,--minor-image-version,1
>  > CMakeFiles/kjsembed.dir/kjsembed_automoc.cpp.obj
>  > CMakeFiles/kjsembed.dir/kjseglobal.cpp.obj
>  > CMakeFiles/kjsembed.dir/binding_support.cpp.obj
>  ...
>
> > CMakeFiles/kjsembed.dir/quiloader_binding.cpp.obj -L/windows/kde4/lib
>  > ../../bin/libkdecore.dll.a /windows/kde4/lib/libQtCore4.a
>  > /windows/kde4/lib/libQtUiTools.a /windows/kde4/lib/libQtGui4.a
>  > /windows/kde4/lib/libQtSvg4.a ../../bin/libkjs.dll.a
>  > /windows/kde4/lib/libQtNetwork4.a /windows/kde4/lib/libQtDBus4.a
>  > /windows/kde4/lib/libz.dll.a /windows/kde4/lib/libkdewin32.dll.a
>  > -luser32 -lshell32 -lws2_32 -lnetapi32 -luserenv
>  > /windows/kde4/lib/libQtXml4.a /windows/kde4/lib/libbzip2.dll.a
>  > /windows/kde4/lib/libintl.dll.a /windows/kde4/lib/libpcre.dll.a
>  > /windows/kde4/lib/libpcreposix.dll.a
>  >
>  >
>  > and this is the long error message http://kde.pastebin.com/f3aa4d4f6
>
>  Ok. This is as far as I see always undefined references from QtUiTools to
>  QtCore:
>  > /windows/kde4/lib/libQtUiTools.a(quiloader.o):quiloader.cpp:(.text+0x7fd):
>  > undefined reference to `__imp___ZNK7QString6toUtf8Ev'
>
>  Which value does QT_QTUITOOLS_LIBRARY have ?
/windows/kde4/lib/libQtUiTools.a
anyway I've find out that it could be fixed by just removing
/windows/kde4/lib/libQtCore4.a and adding -lQtCore4 instead of every
Qt lib
>  > >  > >  > You will get another error in klauncher.moc about slotKDEInitData
>  > >  > >  > so go into kinit and do something like this(you need wine)
>  > >  > >
>  > >  > >  What's the exact problem here ?
>  > >  > >  Does the Windows moc have to be used ? Why ?
>  > >  >
>  > >  > slotKDEInitData doesn't exist on windows
>  > >  > http://lxr.kde.org/source/KDE/kdelibs/kinit/klauncher.h#179 but
>  > >  > kde4automoc thinks that we are on linux maybe, so maybe we should use
>  > >  > the windows version for everything
>  > >
>  > >  Hmm, if we are cross compiling to Windows Q_WS_WIN should be defined.
>  > >  Can you find out why it isn't ?
>  >
>  > Q_WS_WIN is defined when compiling but not in moc, probably it has
>  > hardcoded parameters from the platform where it was compiled
>
>  Hmm, that sounds bad. Let's care about this later.
>
>
>  > >  > >  > Another error in kdewidgets because wine doesn't find some dll to
>  > >  > >  > run makekdewidgets.exe so either run the linux version manually
>  > >  > >  > like this
>  > >  > >
>  > >  > >  So you run the generated executables using wine ? Interesting. The
>  > >  > > idea was to use "native" executables if cross compiling. But if it
>  > >  > > works, ok.
>  > >  > >
>  > >  > >  Alex
>  > >  >
>  > >  > for some strange reason for kde4automoc it calls ../bin/kde4automoc
>  > >  > instead of ../bin/kde4automoc.exe one that's why i made the link in
>
>  Is the .exe extension really required to run the executable ?
>  Under Windows it isn't. Is this a wine speciality ?
no, the problem here is that cmake wants to run makekdewidgets.exe,
maybe it tries to run makekdewidgets.exe.bat while kde4automoc is
called directly
>  I'd really like to get this working cleanly, it's still time to fix things in
>  cmake for cross compiling, 2.6.0 hasn't been released yet.
>
>  Alex
>


From neundorf at kde.org  Wed Mar 12 23:31:48 2008
From: neundorf at kde.org (Alexander Neundorf)
Date: Wed, 12 Mar 2008 23:31:48 +0100
Subject: Cross compiling page in techbase
In-Reply-To: <3262b6180803121518u7a8c5f73x2650ce4686d74a9c@mail.gmail.com>
References: <3262b6180803101724g4f454a71vc029d65f2d85df9d@mail.gmail.com>
	<200803121831.23535.neundorf@kde.org>
	<3262b6180803121518u7a8c5f73x2650ce4686d74a9c@mail.gmail.com>
Message-ID: <200803122331.49075.neundorf@kde.org>

On Wednesday 12 March 2008, Carlo wrote:
...
> >  cmake -DCMAKE_TOOLCHAIN_FILE=<path>/Toolchain-mingw32.cmake -C
> >  <path>/mingw32-kdelibs.cmake <src dir>
>
> you forgot set(KDE4_INSTALL_DIR    /windows/kde4) in the toolchain file
> anyway it doesn't work, this is the erorr
> -- ERROR: unable to find KDE 4 headers
> -- ERROR: unable to find KDE 4 core library
>
> in FindKDE4Internal.cmake
> find_path(KDE4_INCLUDE_DIR kpassworddialog.h
> ${KDE4_INCLUDE_INSTALL_DIR} NO_DEFAULT_PATH )
> and KDE4_INCLUDE_INSTALL_DIR is set to /home/kdeuser/kde/include but
> that's the kde4 linux include not the windows one and btw
> kpassworddialog.h exist in that dir

Is that when building kdelibs or kdebase ?

Alex


From brandon.ml at gmail.com  Wed Mar 12 23:43:50 2008
From: brandon.ml at gmail.com (Carlo)
Date: Wed, 12 Mar 2008 23:43:50 +0100
Subject: Cross compiling page in techbase
In-Reply-To: <200803122331.49075.neundorf@kde.org>
References: <3262b6180803101724g4f454a71vc029d65f2d85df9d@mail.gmail.com>
	<200803121831.23535.neundorf@kde.org>
	<3262b6180803121518u7a8c5f73x2650ce4686d74a9c@mail.gmail.com>
	<200803122331.49075.neundorf@kde.org>
Message-ID: <3262b6180803121543g782a3a45vfc6ed7fbcb6a7dbf@mail.gmail.com>

On Wed, Mar 12, 2008 at 11:31 PM, Alexander Neundorf <neundorf at kde.org> wrote:
> On Wednesday 12 March 2008, Carlo wrote:
>  ...
>
> > >  cmake -DCMAKE_TOOLCHAIN_FILE=<path>/Toolchain-mingw32.cmake -C
>  > >  <path>/mingw32-kdelibs.cmake <src dir>
>  >
>  > you forgot set(KDE4_INSTALL_DIR    /windows/kde4) in the toolchain file
>  > anyway it doesn't work, this is the erorr
>  > -- ERROR: unable to find KDE 4 headers
>  > -- ERROR: unable to find KDE 4 core library
>  >
>  > in FindKDE4Internal.cmake
>  > find_path(KDE4_INCLUDE_DIR kpassworddialog.h
>  > ${KDE4_INCLUDE_INSTALL_DIR} NO_DEFAULT_PATH )
>  > and KDE4_INCLUDE_INSTALL_DIR is set to /home/kdeuser/kde/include but
>  > that's the kde4 linux include not the windows one and btw
>  > kpassworddialog.h exist in that dir
>
>  Is that when building kdelibs or kdebase ?
>
>  Alex
>
kdepimlibs, probably the same on kdebase


From neundorf at kde.org  Thu Mar 13 00:27:56 2008
From: neundorf at kde.org (Alexander Neundorf)
Date: Thu, 13 Mar 2008 00:27:56 +0100
Subject: Cross compiling page in techbase
In-Reply-To: <3262b6180803121543g782a3a45vfc6ed7fbcb6a7dbf@mail.gmail.com>
References: <3262b6180803101724g4f454a71vc029d65f2d85df9d@mail.gmail.com>
	<200803122331.49075.neundorf@kde.org>
	<3262b6180803121543g782a3a45vfc6ed7fbcb6a7dbf@mail.gmail.com>
Message-ID: <200803130027.57093.neundorf@kde.org>

On Wednesday 12 March 2008, Carlo wrote:
> On Wed, Mar 12, 2008 at 11:31 PM, Alexander Neundorf <neundorf at kde.org> 
wrote:
> > On Wednesday 12 March 2008, Carlo wrote:
> >  ...
> >
> > > >  cmake -DCMAKE_TOOLCHAIN_FILE=<path>/Toolchain-mingw32.cmake -C
> > > >
> >  > >  <path>/mingw32-kdelibs.cmake <src dir>
> >  >
> >  > you forgot set(KDE4_INSTALL_DIR    /windows/kde4) in the toolchain
> >  > file anyway it doesn't work, this is the erorr
> >  > -- ERROR: unable to find KDE 4 headers
> >  > -- ERROR: unable to find KDE 4 core library
> >  >
> >  > in FindKDE4Internal.cmake
> >  > find_path(KDE4_INCLUDE_DIR kpassworddialog.h
> >  > ${KDE4_INCLUDE_INSTALL_DIR} NO_DEFAULT_PATH )
> >  > and KDE4_INCLUDE_INSTALL_DIR is set to /home/kdeuser/kde/include but
> >  > that's the kde4 linux include not the windows one and btw
> >  > kpassworddialog.h exist in that dir
> >
> >  Is that when building kdelibs or kdebase ?
> >
> >  Alex
>
> kdepimlibs, probably the same on kdebase

Ok. Let's first get kdelibs working with this (almost) minimal toolchain file.
Does it ?

Alex


From brandon.ml at gmail.com  Thu Mar 13 00:30:07 2008
From: brandon.ml at gmail.com (Carlo)
Date: Thu, 13 Mar 2008 00:30:07 +0100
Subject: Cross compiling page in techbase
In-Reply-To: <200803130027.57093.neundorf@kde.org>
References: <3262b6180803101724g4f454a71vc029d65f2d85df9d@mail.gmail.com>
	<200803122331.49075.neundorf@kde.org>
	<3262b6180803121543g782a3a45vfc6ed7fbcb6a7dbf@mail.gmail.com>
	<200803130027.57093.neundorf@kde.org>
Message-ID: <3262b6180803121630o3fc7afe7od248c965bdd3401b@mail.gmail.com>

On Thu, Mar 13, 2008 at 12:27 AM, Alexander Neundorf <neundorf at kde.org> wrote:
>
> On Wednesday 12 March 2008, Carlo wrote:
>  > On Wed, Mar 12, 2008 at 11:31 PM, Alexander Neundorf <neundorf at kde.org>
>  wrote:
>  > > On Wednesday 12 March 2008, Carlo wrote:
>  > >  ...
>  > >
>  > > > >  cmake -DCMAKE_TOOLCHAIN_FILE=<path>/Toolchain-mingw32.cmake -C
>  > > > >
>  > >  > >  <path>/mingw32-kdelibs.cmake <src dir>
>  > >  >
>  > >  > you forgot set(KDE4_INSTALL_DIR    /windows/kde4) in the toolchain
>  > >  > file anyway it doesn't work, this is the erorr
>  > >  > -- ERROR: unable to find KDE 4 headers
>  > >  > -- ERROR: unable to find KDE 4 core library
>  > >  >
>  > >  > in FindKDE4Internal.cmake
>  > >  > find_path(KDE4_INCLUDE_DIR kpassworddialog.h
>  > >  > ${KDE4_INCLUDE_INSTALL_DIR} NO_DEFAULT_PATH )
>  > >  > and KDE4_INCLUDE_INSTALL_DIR is set to /home/kdeuser/kde/include but
>  > >  > that's the kde4 linux include not the windows one and btw
>  > >  > kpassworddialog.h exist in that dir
>  > >
>  > >  Is that when building kdelibs or kdebase ?
>  > >
>  > >  Alex
>  >
>  > kdepimlibs, probably the same on kdebase
>
>  Ok. Let's first get kdelibs working with this (almost) minimal toolchain file.
>  Does it ?
>
>  Alex
>
yeah no other problems with kdelibs using both the toolchain and the
cache file, just the usual ones


From neundorf at kde.org  Thu Mar 13 01:11:31 2008
From: neundorf at kde.org (Alexander Neundorf)
Date: Thu, 13 Mar 2008 01:11:31 +0100
Subject: Cross compiling page in techbase
In-Reply-To: <3262b6180803121630o3fc7afe7od248c965bdd3401b@mail.gmail.com>
References: <3262b6180803101724g4f454a71vc029d65f2d85df9d@mail.gmail.com>
	<200803130027.57093.neundorf@kde.org>
	<3262b6180803121630o3fc7afe7od248c965bdd3401b@mail.gmail.com>
Message-ID: <200803130111.31835.neundorf@kde.org>

On Thursday 13 March 2008, Carlo wrote:
> On Thu, Mar 13, 2008 at 12:27 AM, Alexander Neundorf <neundorf at kde.org> 
wrote:
> > On Wednesday 12 March 2008, Carlo wrote:
> >  > On Wed, Mar 12, 2008 at 11:31 PM, Alexander Neundorf
> >  > <neundorf at kde.org>
> >
> >  wrote:
> >  > > On Wednesday 12 March 2008, Carlo wrote:
> >  > >  ...
> >  > >
> >  > > > >  cmake -DCMAKE_TOOLCHAIN_FILE=<path>/Toolchain-mingw32.cmake -C
> >  > > > >
> >  > >  > >  <path>/mingw32-kdelibs.cmake <src dir>
> >  > >  >
> >  > >  > you forgot set(KDE4_INSTALL_DIR    /windows/kde4) in the
> >  > >  > toolchain file anyway it doesn't work, this is the erorr
> >  > >  > -- ERROR: unable to find KDE 4 headers
> >  > >  > -- ERROR: unable to find KDE 4 core library
> >  > >  >
> >  > >  > in FindKDE4Internal.cmake
> >  > >  > find_path(KDE4_INCLUDE_DIR kpassworddialog.h
> >  > >  > ${KDE4_INCLUDE_INSTALL_DIR} NO_DEFAULT_PATH )
> >  > >  > and KDE4_INCLUDE_INSTALL_DIR is set to /home/kdeuser/kde/include
> >  > >  > but that's the kde4 linux include not the windows one and btw
> >  > >  > kpassworddialog.h exist in that dir

Is that using the modified FindKDE4.cmake ?
mingw32-kdelibs.cmake sets KDE4_DATA_DIR, and if this is set, FindKDE4.cmake 
should use it to load FindKDE4Internal.cmake, which will load 
KDELibsDependencies.cmake, which contains all these settings from the 
installed kdelibs.

What is going wrong ?
How does the installed KDELibsDependencies.cmake look like, i.e. are the paths 
in that file the same as the real locations ?

...
> >  > kdepimlibs, probably the same on kdebase
> >
> >  Ok. Let's first get kdelibs working with this (almost) minimal toolchain
> > file. Does it ?
> >
> >  Alex
>
> yeah no other problems with kdelibs using both the toolchain and the
> cache file, just the usual ones

For kdelibs you should use _only_ the toolchain file.
Does it work then ?

Alex


From brandon.ml at gmail.com  Thu Mar 13 01:38:44 2008
From: brandon.ml at gmail.com (Carlo)
Date: Thu, 13 Mar 2008 01:38:44 +0100
Subject: Cross compiling page in techbase
In-Reply-To: <200803130111.31835.neundorf@kde.org>
References: <3262b6180803101724g4f454a71vc029d65f2d85df9d@mail.gmail.com>
	<200803130027.57093.neundorf@kde.org>
	<3262b6180803121630o3fc7afe7od248c965bdd3401b@mail.gmail.com>
	<200803130111.31835.neundorf@kde.org>
Message-ID: <3262b6180803121738w1f47da28na0ab328aebab5378@mail.gmail.com>

On Thu, Mar 13, 2008 at 1:11 AM, Alexander Neundorf <neundorf at kde.org> wrote:
> On Thursday 13 March 2008, Carlo wrote:
>  > On Thu, Mar 13, 2008 at 12:27 AM, Alexander Neundorf <neundorf at kde.org>
>  wrote:
>  > > On Wednesday 12 March 2008, Carlo wrote:
>  > >  > On Wed, Mar 12, 2008 at 11:31 PM, Alexander Neundorf
>  > >  > <neundorf at kde.org>
>  > >
>  > >  wrote:
>  > >  > > On Wednesday 12 March 2008, Carlo wrote:
>  > >  > >  ...
>  > >  > >
>  > >  > > > >  cmake -DCMAKE_TOOLCHAIN_FILE=<path>/Toolchain-mingw32.cmake -C
>  > >  > > > >
>  > >  > >  > >  <path>/mingw32-kdelibs.cmake <src dir>
>  > >  > >  >
>  > >  > >  > you forgot set(KDE4_INSTALL_DIR    /windows/kde4) in the
>  > >  > >  > toolchain file anyway it doesn't work, this is the erorr
>  > >  > >  > -- ERROR: unable to find KDE 4 headers
>  > >  > >  > -- ERROR: unable to find KDE 4 core library
>  > >  > >  >
>  > >  > >  > in FindKDE4Internal.cmake
>  > >  > >  > find_path(KDE4_INCLUDE_DIR kpassworddialog.h
>  > >  > >  > ${KDE4_INCLUDE_INSTALL_DIR} NO_DEFAULT_PATH )
>  > >  > >  > and KDE4_INCLUDE_INSTALL_DIR is set to /home/kdeuser/kde/include
>  > >  > >  > but that's the kde4 linux include not the windows one and btw
>  > >  > >  > kpassworddialog.h exist in that dir
>
>  Is that using the modified FindKDE4.cmake ?
>  mingw32-kdelibs.cmake sets KDE4_DATA_DIR, and if this is set, FindKDE4.cmake
>  should use it to load FindKDE4Internal.cmake, which will load
>  KDELibsDependencies.cmake, which contains all these settings from the
>  installed kdelibs.
>
>  What is going wrong ?
>  How does the installed KDELibsDependencies.cmake look like, i.e. are the paths
>  in that file the same as the real locations ?
Yes it uses the modified FindKDE4.cmake  and KDE4_DATA_DIR is set
the problem is that  KDELibsDependencies.cmake uses
${KDE4_INSTALL_DIR} that is retrieved from this code
get_filename_component(_DIR ${KDE4_KDECONFIG_EXECUTABLE} PATH )
get_filename_component(KDE4_INSTALL_DIR ${_DIR} PATH )
but KDE4_KDECONFIG_EXECUTABLE is setted to the linux one, if i set it
to the windows one it goes ahead and it find include and library dir
but it doesn't find kde4automoc and kconfig_compiler
-- Found KDE 4.1 include dir: /windows/kde4/include
-- Found KDE 4.1 library dir: /windows/kde4/lib
-- Didn't find the KDE4 kconfig_compiler preprocessor
-- Didn't find the KDE4 automoc

>
> > >  > kdepimlibs, probably the same on kdebase
>  > >
>  > >  Ok. Let's first get kdelibs working with this (almost) minimal toolchain
>  > > file. Does it ?
>  > >
>  > >  Alex
>  >
>  > yeah no other problems with kdelibs using both the toolchain and the
>  > cache file, just the usual ones
>
>  For kdelibs you should use _only_ the toolchain file.
>  Does it work then ?
Yes it works, I used the cache file just to disable gssapi


From js at iidea.pl  Thu Mar 13 13:49:23 2008
From: js at iidea.pl (=?UTF-8?B?SmFyb3PFgmF3IFN0YW5pZWs=?=)
Date: Thu, 13 Mar 2008 13:49:23 +0100
Subject: [patch] KUniqueApplication: dbus service cleanup for Windows
Message-ID: <47D922D3.5060501@iidea.pl>


For review.
As discussed before in the thread [1], there are problems
with running KUniqueApplications on Windows because previous dbus service has
not been unregistered, resulting in "KUniqueApplication: Can't setup D-Bus
service. Probably already running." and forced app quit.

Having it, e.g. KMail runs just fine every time I executed it, what was not 
the case before (when we needed to kill klauncher and/org dbus-daemon - rather 
not an option for end users we're starting to demo KDE apps on Windows to :)).

There are sane arguments that certain fixes should be performed at the dbus 
level, but for now we have another month after the initial discussion and 
there is nothing better that this KDElibs-level fix. Thus, consider the patch 
as temporary.

[1] http://lists.kde.org/?t=120294760700003&r=1&w=2

-- 
regards / pozdrawiam, Jaroslaw Staniek
   Sponsored by OpenOffice Polska (http://www.openoffice.com.pl/en) to work on
   Kexi & KOffice (http://www.kexi.pl/en, http://www.koffice.org/kexi)
   KDE Libraries for MS Windows (http://windows.kde.org)

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: kuniapp_dbus_cleanup.patch
Url: http://mail.kde.org/pipermail/kde-windows/attachments/20080313/9319a280/attachment.ksh 

From djarvie at kde.org  Thu Mar 13 14:59:38 2008
From: djarvie at kde.org (David Jarvie)
Date: Thu, 13 Mar 2008 13:59:38 -0000 (GMT)
Subject: [patch] KUniqueApplication: dbus service cleanup for Windows
In-Reply-To: <47D922D3.5060501@iidea.pl>
References: <47D922D3.5060501@iidea.pl>
Message-ID: <22279.134.146.0.41.1205416778.squirrel@www.sensical.net>

On Thu, March 13, 2008 12:49 pm, Jaros?aw Staniek wrote:
>
> For review.
> As discussed before in the thread [1], there are problems
> with running KUniqueApplications on Windows because previous dbus service
> has
> not been unregistered, resulting in "KUniqueApplication: Can't setup D-Bus
> service. Probably already running." and forced app quit.

I'm not in a position to comment on your approach, but to avoid the code
looking at first sight like '==' has accidentally been written as '=', it
would read better as:

+  if (QDBusConnection::sessionBus().isConnected()
+    && (dbusService = QDBusConnection::sessionBus().interface()) != 0)

-- 
David Jarvie.
KAlarm author & maintainer.
http://www.astrojar.org.uk/kalarm



From js at iidea.pl  Thu Mar 13 15:19:24 2008
From: js at iidea.pl (=?UTF-8?B?SmFyb3PFgmF3IFN0YW5pZWs=?=)
Date: Thu, 13 Mar 2008 15:19:24 +0100
Subject: [patch] KUniqueApplication: dbus service cleanup for Windows
In-Reply-To: <22279.134.146.0.41.1205416778.squirrel@www.sensical.net>
References: <47D922D3.5060501@iidea.pl>
	<22279.134.146.0.41.1205416778.squirrel@www.sensical.net>
Message-ID: <47D937EC.7060308@iidea.pl>

David Jarvie said the following, On 2008-03-13 14:59:
> On Thu, March 13, 2008 12:49 pm, Jaros?aw Staniek wrote:
>> For review.
>> As discussed before in the thread [1], there are problems
>> with running KUniqueApplications on Windows because previous dbus service
>> has
>> not been unregistered, resulting in "KUniqueApplication: Can't setup D-Bus
>> service. Probably already running." and forced app quit.
> 
> I'm not in a position to comment on your approach, but to avoid the code
> looking at first sight like '==' has accidentally been written as '=', it
> would read better as:
> 
> +  if (QDBusConnection::sessionBus().isConnected()
> +    && (dbusService = QDBusConnection::sessionBus().interface()) != 0)
> 

the ( ) are used to express that '=' is not a mistake... just like in many 
places around, including tryToInitDBusConnection()

-- 
regards / pozdrawiam, Jaroslaw Staniek
  Sponsored by OpenOffice Polska (http://www.openoffice.com.pl/en) to work on
  Kexi & KOffice (http://www.kexi.pl/en, http://www.koffice.org/kexi)
  KDE Libraries for MS Windows (http://windows.kde.org)


From ereslibre at kde.org  Thu Mar 13 15:50:51 2008
From: ereslibre at kde.org (Rafael =?utf-8?q?Fern=C3=A1ndez_L=C3=B3pez?=)
Date: Thu, 13 Mar 2008 15:50:51 +0100
Subject: [patch] KUniqueApplication: dbus service cleanup for Windows
In-Reply-To: <22279.134.146.0.41.1205416778.squirrel@www.sensical.net>
References: <47D922D3.5060501@iidea.pl>
	<22279.134.146.0.41.1205416778.squirrel@www.sensical.net>
Message-ID: <200803131550.54784.ereslibre@kde.org>

Hi,

> I'm not in a position to comment on your approach, but to avoid the code
> looking at first sight like '==' has accidentally been written as '=', it
> would read better as:
>
> +  if (QDBusConnection::sessionBus().isConnected()
> +    && (dbusService = QDBusConnection::sessionBus().interface()) != 0)

Nope, it is fine. It assigns to dbusService the address of the interface, and 
later checks if it was different to NULL. It is fine.

In other case (using ==), you would be generating a boolean expression. Is a 
different thing.

This is the same as writing:

if (QDBusConnection::sessionBus().isConnected()) {
    dbusService = QDBusConnection::sessionBus().interface();
    if (dbusService) {
        ...
    }
}


Bye,
Rafael Fern?ndez L?pez

GPG Fingerprint: B9F4 4730 43F8 FFDD CC5E BA8E 724E 406E 3F01 D070
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-windows/attachments/20080313/acd57ca0/attachment.pgp 

From neundorf at kde.org  Thu Mar 13 19:07:21 2008
From: neundorf at kde.org (Alexander Neundorf)
Date: Thu, 13 Mar 2008 19:07:21 +0100
Subject: Cross compiling page in techbase
In-Reply-To: <3262b6180803121738w1f47da28na0ab328aebab5378@mail.gmail.com>
References: <3262b6180803101724g4f454a71vc029d65f2d85df9d@mail.gmail.com>
	<200803130111.31835.neundorf@kde.org>
	<3262b6180803121738w1f47da28na0ab328aebab5378@mail.gmail.com>
Message-ID: <200803131907.21967.neundorf@kde.org>

On Thursday 13 March 2008, Carlo wrote:
> On Thu, Mar 13, 2008 at 1:11 AM, Alexander Neundorf <neundorf at kde.org> 
wrote:
...
> >  Is that using the modified FindKDE4.cmake ?
> >  mingw32-kdelibs.cmake sets KDE4_DATA_DIR, and if this is set,
> > FindKDE4.cmake should use it to load FindKDE4Internal.cmake, which will
> > load
> >  KDELibsDependencies.cmake, which contains all these settings from the
> >  installed kdelibs.
> >
> >  What is going wrong ?
> >  How does the installed KDELibsDependencies.cmake look like, i.e. are the
> > paths in that file the same as the real locations ?
>
> Yes it uses the modified FindKDE4.cmake  and KDE4_DATA_DIR is set
> the problem is that  KDELibsDependencies.cmake uses
> ${KDE4_INSTALL_DIR} that is retrieved from this code
> get_filename_component(_DIR ${KDE4_KDECONFIG_EXECUTABLE} PATH )
> get_filename_component(KDE4_INSTALL_DIR ${_DIR} PATH )
> but KDE4_KDECONFIG_EXECUTABLE is setted to the linux one, if i set it
> to the windows one it goes ahead and it find include and library dir
> but it doesn't find kde4automoc and kconfig_compiler
> -- Found KDE 4.1 include dir: /windows/kde4/include
> -- Found KDE 4.1 library dir: /windows/kde4/lib
> -- Didn't find the KDE4 kconfig_compiler preprocessor
> -- Didn't find the KDE4 automoc

Please update your FindKDE4Internal.cmake, I committed a change so that now 
KDE4_INSTALL_DIR is determined relative to the location of the installed 
FindKDE4Internal.cmake instead of kde4-config.exe. This should help for now 
for this problem.

> > > for some strange reason for kde4automoc it calls ../bin/kde4automoc 
> > > instead of ../bin/kde4automoc.exe one that's why i made the link in
> >
> >  Is the .exe extension really required to run the executable ?
> >  Under Windows it isn't. Is this a wine speciality ?
>
> no, the problem here is that cmake wants to run makekdewidgets.exe,
> maybe it tries to run makekdewidgets.exe.bat while kde4automoc is
> called directly

Ok, I lost track.
How does it call makekdewidgets, how does it call kde4automoc, and which of 
the two is the problem ?

> >  Ok. This is as far as I see always undefined references from QtUiTools to
> >  QtCore:
> > /windows/kde4/lib/libQtUiTools.a(quiloader.o):quiloader.cpp:(.text+0x7fd):
> > undefined reference to `__imp___ZNK7QString6toUtf8Ev'
> >
> >  Which value does QT_QTUITOOLS_LIBRARY have ?
> /windows/kde4/lib/libQtUiTools.a
> anyway I've find out that it could be fixed by just removing
> /windows/kde4/lib/libQtCore4.a and adding -lQtCore4 instead of every
> Qt lib

Is libQtUiTools.a a static or a shared library ? 
Don't they usually have the suffix .dll or .lib ?

Alex


From brandon.ml at gmail.com  Thu Mar 13 19:50:06 2008
From: brandon.ml at gmail.com (Carlo)
Date: Thu, 13 Mar 2008 19:50:06 +0100
Subject: Cross compiling page in techbase
In-Reply-To: <200803131907.21967.neundorf@kde.org>
References: <3262b6180803101724g4f454a71vc029d65f2d85df9d@mail.gmail.com>
	<200803130111.31835.neundorf@kde.org>
	<3262b6180803121738w1f47da28na0ab328aebab5378@mail.gmail.com>
	<200803131907.21967.neundorf@kde.org>
Message-ID: <3262b6180803131150l212182a8ve6f2e19756e4397d@mail.gmail.com>

On Thu, Mar 13, 2008 at 7:07 PM, Alexander Neundorf <neundorf at kde.org> wrote:
> On Thursday 13 March 2008, Carlo wrote:
>  > On Thu, Mar 13, 2008 at 1:11 AM, Alexander Neundorf <neundorf at kde.org>
>  wrote:
>  ...
>
> > >  Is that using the modified FindKDE4.cmake ?
>  > >  mingw32-kdelibs.cmake sets KDE4_DATA_DIR, and if this is set,
>  > > FindKDE4.cmake should use it to load FindKDE4Internal.cmake, which will
>  > > load
>  > >  KDELibsDependencies.cmake, which contains all these settings from the
>  > >  installed kdelibs.
>  > >
>  > >  What is going wrong ?
>  > >  How does the installed KDELibsDependencies.cmake look like, i.e. are the
>  > > paths in that file the same as the real locations ?
>  >
>  > Yes it uses the modified FindKDE4.cmake  and KDE4_DATA_DIR is set
>  > the problem is that  KDELibsDependencies.cmake uses
>  > ${KDE4_INSTALL_DIR} that is retrieved from this code
>  > get_filename_component(_DIR ${KDE4_KDECONFIG_EXECUTABLE} PATH )
>  > get_filename_component(KDE4_INSTALL_DIR ${_DIR} PATH )
>  > but KDE4_KDECONFIG_EXECUTABLE is setted to the linux one, if i set it
>  > to the windows one it goes ahead and it find include and library dir
>  > but it doesn't find kde4automoc and kconfig_compiler
>  > -- Found KDE 4.1 include dir: /windows/kde4/include
>  > -- Found KDE 4.1 library dir: /windows/kde4/lib
>  > -- Didn't find the KDE4 kconfig_compiler preprocessor
>  > -- Didn't find the KDE4 automoc
>
>  Please update your FindKDE4Internal.cmake, I committed a change so that now
>  KDE4_INSTALL_DIR is determined relative to the location of the installed
>  FindKDE4Internal.cmake instead of kde4-config.exe. This should help for now
>  for this problem.
>
>
>  > > > for some strange reason for kde4automoc it calls ../bin/kde4automoc
>  > > > instead of ../bin/kde4automoc.exe one that's why i made the link in
>  > >
>  > >  Is the .exe extension really required to run the executable ?
>  > >  Under Windows it isn't. Is this a wine speciality ?
>  >
>  > no, the problem here is that cmake wants to run makekdewidgets.exe,
>  > maybe it tries to run makekdewidgets.exe.bat while kde4automoc is
>  > called directly
>
>  Ok, I lost track.
>  How does it call makekdewidgets, how does it call kde4automoc, and which of
>  the two is the problem ?
kde4automoc is called in this way
cd /home/kdeuser/kde/src/KDE/kdelibs/build/kdewidgets &&
../bin/kde4automoc
/home/kdeuser/kde/src/KDE/kdelibs/build/kdewidgets/makekdewidgets_automoc.cpp
/home/kdeuser/kde/src/KDE/kdelibs/kdewidgets
/home/kdeuser/kde/src/KDE/kdelibs/build/kdewidgets
/home/kdeuser/kde/src/qt-copy/bin/moc

while makekdewidgets
cd /home/kdeuser/kde/src/KDE/kdelibs/build/kdewidgets &&
../bin/makekdewidgets.exe -o
/home/kdeuser/kde/src/KDE/kdelibs/build/kdewidgets/kdewidgets.cpp
/home/kdeuser/kde/src/KDE/kdelibs/kdewidgets/kde.widgets

so here the problem is that we should call makekdewidgets without the
.exe extension otherwise it's runned by wine
>  > >  Ok. This is as far as I see always undefined references from QtUiTools to
>  > >  QtCore:
>  > > /windows/kde4/lib/libQtUiTools.a(quiloader.o):quiloader.cpp:(.text+0x7fd):
>  > > undefined reference to `__imp___ZNK7QString6toUtf8Ev'
>  > >
>  > >  Which value does QT_QTUITOOLS_LIBRARY have ?
>  > /windows/kde4/lib/libQtUiTools.a
>  > anyway I've find out that it could be fixed by just removing
>  > /windows/kde4/lib/libQtCore4.a and adding -lQtCore4 instead of every
>  > Qt lib
>
>  Is libQtUiTools.a a static or a shared library ?
>  Don't they usually have the suffix .dll or .lib ?
it should be a shared library, i'm not sure but i think that .dll are
needed for runtime, while .a are just for linking and .lib are static
library compiled with visual c++, btw i get this error with both qt4
from the kdewin installer and the precompiled one from trolltech


From neundorf at kde.org  Fri Mar 14 01:15:56 2008
From: neundorf at kde.org (Alexander Neundorf)
Date: Fri, 14 Mar 2008 01:15:56 +0100
Subject: Cross compiling page in techbase
In-Reply-To: <3262b6180803131150l212182a8ve6f2e19756e4397d@mail.gmail.com>
References: <3262b6180803101724g4f454a71vc029d65f2d85df9d@mail.gmail.com>
	<200803131907.21967.neundorf@kde.org>
	<3262b6180803131150l212182a8ve6f2e19756e4397d@mail.gmail.com>
Message-ID: <200803140115.57090.neundorf@kde.org>

On Thursday 13 March 2008, Carlo wrote:
> On Thu, Mar 13, 2008 at 7:07 PM, Alexander Neundorf <neundorf at kde.org> 
wrote:
> > On Thursday 13 March 2008, Carlo wrote:
> >  > On Thu, Mar 13, 2008 at 1:11 AM, Alexander Neundorf <neundorf at kde.org>
> >
> >  wrote:
> >  ...
> >
> > > >  Is that using the modified FindKDE4.cmake ?
> > > >
> >  > >  mingw32-kdelibs.cmake sets KDE4_DATA_DIR, and if this is set,
> >  > > FindKDE4.cmake should use it to load FindKDE4Internal.cmake, which
> >  > > will load
> >  > >  KDELibsDependencies.cmake, which contains all these settings from
> >  > > the installed kdelibs.
> >  > >
> >  > >  What is going wrong ?
> >  > >  How does the installed KDELibsDependencies.cmake look like, i.e.
> >  > > are the paths in that file the same as the real locations ?
> >  >
> >  > Yes it uses the modified FindKDE4.cmake  and KDE4_DATA_DIR is set
> >  > the problem is that  KDELibsDependencies.cmake uses
> >  > ${KDE4_INSTALL_DIR} that is retrieved from this code
> >  > get_filename_component(_DIR ${KDE4_KDECONFIG_EXECUTABLE} PATH )
> >  > get_filename_component(KDE4_INSTALL_DIR ${_DIR} PATH )
> >  > but KDE4_KDECONFIG_EXECUTABLE is setted to the linux one, if i set it
> >  > to the windows one it goes ahead and it find include and library dir
> >  > but it doesn't find kde4automoc and kconfig_compiler
> >  > -- Found KDE 4.1 include dir: /windows/kde4/include
> >  > -- Found KDE 4.1 library dir: /windows/kde4/lib
> >  > -- Didn't find the KDE4 kconfig_compiler preprocessor
> >  > -- Didn't find the KDE4 automoc
> >
> >  Please update your FindKDE4Internal.cmake, I committed a change so that
> > now KDE4_INSTALL_DIR is determined relative to the location of the
> > installed FindKDE4Internal.cmake instead of kde4-config.exe. This should
> > help for now for this problem.
> >
> >  > > > for some strange reason for kde4automoc it calls
> >  > > > ../bin/kde4automoc instead of ../bin/kde4automoc.exe one that's
> >  > > > why i made the link in
> >  > >
> >  > >  Is the .exe extension really required to run the executable ?
> >  > >  Under Windows it isn't. Is this a wine speciality ?
> >  >
> >  > no, the problem here is that cmake wants to run makekdewidgets.exe,
> >  > maybe it tries to run makekdewidgets.exe.bat while kde4automoc is
> >  > called directly
> >
> >  Ok, I lost track.
> >  How does it call makekdewidgets, how does it call kde4automoc, and which
> > of the two is the problem ?
>
> kde4automoc is called in this way
> cd /home/kdeuser/kde/src/KDE/kdelibs/build/kdewidgets &&
> ../bin/kde4automoc
> /home/kdeuser/kde/src/KDE/kdelibs/build/kdewidgets/makekdewidgets_automoc.c
>pp /home/kdeuser/kde/src/KDE/kdelibs/kdewidgets
> /home/kdeuser/kde/src/KDE/kdelibs/build/kdewidgets
> /home/kdeuser/kde/src/qt-copy/bin/moc
>
> while makekdewidgets
> cd /home/kdeuser/kde/src/KDE/kdelibs/build/kdewidgets &&
> ../bin/makekdewidgets.exe -o
> /home/kdeuser/kde/src/KDE/kdelibs/build/kdewidgets/kdewidgets.cpp
> /home/kdeuser/kde/src/KDE/kdelibs/kdewidgets/kde.widgets
>
> so here the problem is that we should call makekdewidgets without the
> .exe extension otherwise it's runned by wine

Ah, ok.
I'll check why it behaves differently.
If we would require cmake 2.6 we would have full support for this problem, 
I'll see if we can get it to work with having cmake 2.6 only optionally.

> >  > >  Ok. This is as far as I see always undefined references from
> >  > > QtUiTools to QtCore:
> >  > > /windows/kde4/lib/libQtUiTools.a(quiloader.o):quiloader.cpp:(.text+0
> >  > >x7fd): undefined reference to `__imp___ZNK7QString6toUtf8Ev'
> >  > >
> >  > >  Which value does QT_QTUITOOLS_LIBRARY have ?
> >  >
> >  > /windows/kde4/lib/libQtUiTools.a
> >  > anyway I've find out that it could be fixed by just removing
> >  > /windows/kde4/lib/libQtCore4.a and adding -lQtCore4 instead of every
> >  > Qt lib
> >
> >  Is libQtUiTools.a a static or a shared library ?
> >  Don't they usually have the suffix .dll or .lib ?
>
> it should be a shared library, i'm not sure but i think that .dll are
> needed for runtime, while .a are just for linking and .lib are static
> library compiled with visual c++, btw i get this error with both qt4
> from the kdewin installer and the precompiled one from trolltech

Does it work if you set QT_QTUITOOLS_LIBRARY to the QtUiTools library followed 
by the QtCore library ? This should fix the undefined references.

Alex


From brandon.ml at gmail.com  Fri Mar 14 01:16:47 2008
From: brandon.ml at gmail.com (Carlo)
Date: Fri, 14 Mar 2008 01:16:47 +0100
Subject: Cross compiling page in techbase
In-Reply-To: <200803140115.57090.neundorf@kde.org>
References: <3262b6180803101724g4f454a71vc029d65f2d85df9d@mail.gmail.com>
	<200803131907.21967.neundorf@kde.org>
	<3262b6180803131150l212182a8ve6f2e19756e4397d@mail.gmail.com>
	<200803140115.57090.neundorf@kde.org>
Message-ID: <3262b6180803131716n4770fe6aieea0ec9265090606@mail.gmail.com>

On Fri, Mar 14, 2008 at 1:15 AM, Alexander Neundorf <neundorf at kde.org> wrote:
>
> On Thursday 13 March 2008, Carlo wrote:
>  > On Thu, Mar 13, 2008 at 7:07 PM, Alexander Neundorf <neundorf at kde.org>
>  wrote:
>  > > On Thursday 13 March 2008, Carlo wrote:
>  > >  > On Thu, Mar 13, 2008 at 1:11 AM, Alexander Neundorf <neundorf at kde.org>
>  > >
>  > >  wrote:
>  > >  ...
>  > >
>  > > > >  Is that using the modified FindKDE4.cmake ?
>  > > > >
>  > >  > >  mingw32-kdelibs.cmake sets KDE4_DATA_DIR, and if this is set,
>  > >  > > FindKDE4.cmake should use it to load FindKDE4Internal.cmake, which
>  > >  > > will load
>  > >  > >  KDELibsDependencies.cmake, which contains all these settings from
>  > >  > > the installed kdelibs.
>  > >  > >
>  > >  > >  What is going wrong ?
>  > >  > >  How does the installed KDELibsDependencies.cmake look like, i.e.
>  > >  > > are the paths in that file the same as the real locations ?
>  > >  >
>  > >  > Yes it uses the modified FindKDE4.cmake  and KDE4_DATA_DIR is set
>  > >  > the problem is that  KDELibsDependencies.cmake uses
>  > >  > ${KDE4_INSTALL_DIR} that is retrieved from this code
>  > >  > get_filename_component(_DIR ${KDE4_KDECONFIG_EXECUTABLE} PATH )
>  > >  > get_filename_component(KDE4_INSTALL_DIR ${_DIR} PATH )
>  > >  > but KDE4_KDECONFIG_EXECUTABLE is setted to the linux one, if i set it
>  > >  > to the windows one it goes ahead and it find include and library dir
>  > >  > but it doesn't find kde4automoc and kconfig_compiler
>  > >  > -- Found KDE 4.1 include dir: /windows/kde4/include
>  > >  > -- Found KDE 4.1 library dir: /windows/kde4/lib
>  > >  > -- Didn't find the KDE4 kconfig_compiler preprocessor
>  > >  > -- Didn't find the KDE4 automoc
>  > >
>  > >  Please update your FindKDE4Internal.cmake, I committed a change so that
>  > > now KDE4_INSTALL_DIR is determined relative to the location of the
>  > > installed FindKDE4Internal.cmake instead of kde4-config.exe. This should
>  > > help for now for this problem.
>  > >
>  > >  > > > for some strange reason for kde4automoc it calls
>  > >  > > > ../bin/kde4automoc instead of ../bin/kde4automoc.exe one that's
>  > >  > > > why i made the link in
>  > >  > >
>  > >  > >  Is the .exe extension really required to run the executable ?
>  > >  > >  Under Windows it isn't. Is this a wine speciality ?
>  > >  >
>  > >  > no, the problem here is that cmake wants to run makekdewidgets.exe,
>  > >  > maybe it tries to run makekdewidgets.exe.bat while kde4automoc is
>  > >  > called directly
>  > >
>  > >  Ok, I lost track.
>  > >  How does it call makekdewidgets, how does it call kde4automoc, and which
>  > > of the two is the problem ?
>  >
>  > kde4automoc is called in this way
>  > cd /home/kdeuser/kde/src/KDE/kdelibs/build/kdewidgets &&
>  > ../bin/kde4automoc
>  > /home/kdeuser/kde/src/KDE/kdelibs/build/kdewidgets/makekdewidgets_automoc.c
>  >pp /home/kdeuser/kde/src/KDE/kdelibs/kdewidgets
>
> > /home/kdeuser/kde/src/KDE/kdelibs/build/kdewidgets
>  > /home/kdeuser/kde/src/qt-copy/bin/moc
>  >
>  > while makekdewidgets
>  > cd /home/kdeuser/kde/src/KDE/kdelibs/build/kdewidgets &&
>  > ../bin/makekdewidgets.exe -o
>  > /home/kdeuser/kde/src/KDE/kdelibs/build/kdewidgets/kdewidgets.cpp
>  > /home/kdeuser/kde/src/KDE/kdelibs/kdewidgets/kde.widgets
>  >
>  > so here the problem is that we should call makekdewidgets without the
>  > .exe extension otherwise it's runned by wine
>
>  Ah, ok.
>  I'll check why it behaves differently.
>  If we would require cmake 2.6 we would have full support for this problem,
>  I'll see if we can get it to work with having cmake 2.6 only optionally.
>
>
>  > >  > >  Ok. This is as far as I see always undefined references from
>  > >  > > QtUiTools to QtCore:
>  > >  > > /windows/kde4/lib/libQtUiTools.a(quiloader.o):quiloader.cpp:(.text+0
>  > >  > >x7fd): undefined reference to `__imp___ZNK7QString6toUtf8Ev'
>
> > >  > >
>  > >  > >  Which value does QT_QTUITOOLS_LIBRARY have ?
>  > >  >
>  > >  > /windows/kde4/lib/libQtUiTools.a
>  > >  > anyway I've find out that it could be fixed by just removing
>  > >  > /windows/kde4/lib/libQtCore4.a and adding -lQtCore4 instead of every
>  > >  > Qt lib
>  > >
>  > >  Is libQtUiTools.a a static or a shared library ?
>  > >  Don't they usually have the suffix .dll or .lib ?
>  >
>  > it should be a shared library, i'm not sure but i think that .dll are
>  > needed for runtime, while .a are just for linking and .lib are static
>  > library compiled with visual c++, btw i get this error with both qt4
>  > from the kdewin installer and the precompiled one from trolltech
>
>  Does it work if you set QT_QTUITOOLS_LIBRARY to the QtUiTools library followed
>  by the QtCore library ? This should fix the undefined references.
do you mean something like this?
"/windows/kde4/lib/libQtUiTools.a  /windows/kde4/lib/libQtCore4.a"


From neundorf at kde.org  Fri Mar 14 01:41:01 2008
From: neundorf at kde.org (Alexander Neundorf)
Date: Fri, 14 Mar 2008 01:41:01 +0100
Subject: Cross compiling page in techbase
In-Reply-To: <3262b6180803131150l212182a8ve6f2e19756e4397d@mail.gmail.com>
References: <3262b6180803101724g4f454a71vc029d65f2d85df9d@mail.gmail.com>
	<200803131907.21967.neundorf@kde.org>
	<3262b6180803131150l212182a8ve6f2e19756e4397d@mail.gmail.com>
Message-ID: <200803140141.01990.neundorf@kde.org>

On Thursday 13 March 2008, Carlo wrote:
> On Thu, Mar 13, 2008 at 7:07 PM, Alexander Neundorf <neundorf at kde.org> 
wrote:
> > On Thursday 13 March 2008, Carlo wrote:
> >  > On Thu, Mar 13, 2008 at 1:11 AM, Alexander Neundorf <neundorf at kde.org>
> >
> >  wrote:
> >  ...
> >
> > > >  Is that using the modified FindKDE4.cmake ?
> > > >
> >  > >  mingw32-kdelibs.cmake sets KDE4_DATA_DIR, and if this is set,
> >  > > FindKDE4.cmake should use it to load FindKDE4Internal.cmake, which
> >  > > will load
> >  > >  KDELibsDependencies.cmake, which contains all these settings from
> >  > > the installed kdelibs.
> >  > >
> >  > >  What is going wrong ?
> >  > >  How does the installed KDELibsDependencies.cmake look like, i.e.
> >  > > are the paths in that file the same as the real locations ?
> >  >
> >  > Yes it uses the modified FindKDE4.cmake  and KDE4_DATA_DIR is set
> >  > the problem is that  KDELibsDependencies.cmake uses
> >  > ${KDE4_INSTALL_DIR} that is retrieved from this code
> >  > get_filename_component(_DIR ${KDE4_KDECONFIG_EXECUTABLE} PATH )
> >  > get_filename_component(KDE4_INSTALL_DIR ${_DIR} PATH )
> >  > but KDE4_KDECONFIG_EXECUTABLE is setted to the linux one, if i set it
> >  > to the windows one it goes ahead and it find include and library dir
> >  > but it doesn't find kde4automoc and kconfig_compiler
> >  > -- Found KDE 4.1 include dir: /windows/kde4/include
> >  > -- Found KDE 4.1 library dir: /windows/kde4/lib
> >  > -- Didn't find the KDE4 kconfig_compiler preprocessor
> >  > -- Didn't find the KDE4 automoc
> >
> >  Please update your FindKDE4Internal.cmake, I committed a change so that
> > now KDE4_INSTALL_DIR is determined relative to the location of the
> > installed FindKDE4Internal.cmake instead of kde4-config.exe. This should
> > help for now for this problem.

Please update FindKDE4Internal.cmake again, I reverted the change and modified 
FindKDE4.cmake from cmake instead.
Now you just have to make ure that kde4-config from the windows build is 
found. Then it should also find the rest.
This should work, your CMAKE_FIND_ROOT_PATH is set correctly.

Alex
-------------- next part --------------
# Find KDE4 and provide all necessary variables and macros to compile software for it.
# It looks for KDE 4 in the following directories in the given order:
#  CMAKE_INSTALL_PREFIX
#  KDEDIRS
#  /opt/kde4
#
# Please look in FindKDE4Internal.cmake and KDE4Macros.cmake for more information.
# They are installed with the KDE 4 libraries in $KDEDIRS/share/apps/cmake/modules/.
#
# Author: Alexander Neundorf <neundorf at kde.org>

FILE(TO_CMAKE_PATH "$ENV{KDEDIRS}" _KDEDIRS)

# when cross compiling, searching kde4-config in order to run it later on
# doesn't make a lot of sense. We'll have to do something about this. 
# Searching always in the target environment ? Then we get at least the correct one,
# still it can't be used to run it. Alex

# For KDE4 kde-config has been renamed to kde4-config
FIND_PROGRAM(KDE4_KDECONFIG_EXECUTABLE NAMES kde4-config
   PATH_SUFFIXES bin               # the suffix is for the paths coming from KDEDIRS
   PATHS
   ${CMAKE_INSTALL_PREFIX}
   ${_KDEDIRS}
   /opt/kde4
   NO_DEFAULT_PATH
   ONLY_CMAKE_FIND_ROOT_PATH
   )

FIND_PROGRAM(KDE4_KDECONFIG_EXECUTABLE NAMES kde4-config ONLY_CMAKE_FIND_ROOT_PATH)

IF (NOT KDE4_KDECONFIG_EXECUTABLE)
   IF (KDE4_FIND_REQUIRED)
      MESSAGE(FATAL_ERROR "ERROR: Could not find KDE4 kde4-config")
   ENDIF (KDE4_FIND_REQUIRED)
ENDIF (NOT KDE4_KDECONFIG_EXECUTABLE)


# when cross compiling, it may be already preset
IF(NOT KDE4_DATA_DIR)
   IF(CMAKE_CROSSCOMPILING)
      # when cross compiling, don't run kde4-config but use its location as install dir
      GET_FILENAME_COMPONENT(KDE4_DATA_DIR "${KDE4_KDECONFIG_EXECUTABLE}" PATH)
      GET_FILENAME_COMPONENT(KDE4_DATA_DIR "${KDE4_DATA_DIR}" PATH)
   ELSE(CMAKE_CROSSCOMPILING)

      # then ask kde4-config for the kde data dirs
      EXECUTE_PROCESS(COMMAND "${KDE4_KDECONFIG_EXECUTABLE}" --path data OUTPUT_VARIABLE _data_DIR ERROR_QUIET OUTPUT_STRIP_TRAILING_WHITESPACE)
      FILE(TO_CMAKE_PATH "${_data_DIR}" _data_DIR)
      # then check the data dirs for FindKDE4Internal.cmake
      FIND_PATH(KDE4_DATA_DIR cmake/modules/FindKDE4Internal.cmake ${_data_DIR})
   ENDIF(CMAKE_CROSSCOMPILING)
ENDIF(NOT KDE4_DATA_DIR)

# if it has been found...
IF (KDE4_DATA_DIR)

   SET(CMAKE_MODULE_PATH  ${CMAKE_MODULE_PATH} ${KDE4_DATA_DIR}/cmake/modules)

   IF (KDE4_FIND_QUIETLY)
      SET(_quiet QUIET)
   ENDIF (KDE4_FIND_QUIETLY)

   IF (KDE4_FIND_REQUIRED)
      SET(_req REQUIRED)
   ENDIF (KDE4_FIND_REQUIRED)

   # use FindKDE4Internal.cmake to do the rest
   FIND_PACKAGE(KDE4Internal ${_req} ${_quiet})
ELSE (KDE4_DATA_DIR)
   IF (KDE4_FIND_REQUIRED)
      MESSAGE(FATAL_ERROR "ERROR: cmake/modules/FindKDE4Internal.cmake not found in ${_data_DIR}")
   ENDIF (KDE4_FIND_REQUIRED)
ENDIF (KDE4_DATA_DIR)

From neundorf at kde.org  Fri Mar 14 01:42:27 2008
From: neundorf at kde.org (Alexander Neundorf)
Date: Fri, 14 Mar 2008 01:42:27 +0100
Subject: Cross compiling page in techbase
In-Reply-To: <3262b6180803131716n4770fe6aieea0ec9265090606@mail.gmail.com>
References: <3262b6180803101724g4f454a71vc029d65f2d85df9d@mail.gmail.com>
	<200803140115.57090.neundorf@kde.org>
	<3262b6180803131716n4770fe6aieea0ec9265090606@mail.gmail.com>
Message-ID: <200803140142.27584.neundorf@kde.org>

On Friday 14 March 2008, Carlo wrote:
> On Fri, Mar 14, 2008 at 1:15 AM, Alexander Neundorf <neundorf at kde.org> 
wrote:
...
> do you mean something like this?
> "/windows/kde4/lib/libQtUiTools.a  /windows/kde4/lib/libQtCore4.a"

Yes, but without the quotes, otherwise cmake will interpret it as one file 
name.

Alex


From brandon.ml at gmail.com  Fri Mar 14 01:58:14 2008
From: brandon.ml at gmail.com (Carlo)
Date: Fri, 14 Mar 2008 01:58:14 +0100
Subject: Cross compiling page in techbase
In-Reply-To: <200803140142.27584.neundorf@kde.org>
References: <3262b6180803101724g4f454a71vc029d65f2d85df9d@mail.gmail.com>
	<200803140115.57090.neundorf@kde.org>
	<3262b6180803131716n4770fe6aieea0ec9265090606@mail.gmail.com>
	<200803140142.27584.neundorf@kde.org>
Message-ID: <3262b6180803131758w6c919ff6l90b44d29977ae6fd@mail.gmail.com>

On Fri, Mar 14, 2008 at 1:42 AM, Alexander Neundorf <neundorf at kde.org> wrote:
> On Friday 14 March 2008, Carlo wrote:
>  > On Fri, Mar 14, 2008 at 1:15 AM, Alexander Neundorf <neundorf at kde.org>
>  wrote:
>  ...
>
> > do you mean something like this?
>  > "/windows/kde4/lib/libQtUiTools.a  /windows/kde4/lib/libQtCore4.a"
>
>  Yes, but without the quotes, otherwise cmake will interpret it as one file
>  name.
>
it doesn't work
*** No rule to make target `/windows/kde4/lib/libQtUiTools.a
/windows/kde4/lib/libQtCore4.a', needed by `bin/libkjsembed.dll'


From ralf.habacker at freenet.de  Fri Mar 14 10:07:06 2008
From: ralf.habacker at freenet.de (Ralf Habacker)
Date: Fri, 14 Mar 2008 10:07:06 +0100
Subject: [patch] KUniqueApplication: dbus service cleanup for Windows
In-Reply-To: <47D922D3.5060501@iidea.pl>
References: <47D922D3.5060501@iidea.pl>
Message-ID: <47DA403A.9020601@freenet.de>

Jaros?aw Staniek schrieb:
>
> For review.
> As discussed before in the thread [1], there are problems
> with running KUniqueApplications on Windows because previous dbus 
> service has
> not been unregistered, resulting in "KUniqueApplication: Can't setup 
> D-Bus
> service. Probably already running." and forced app quit.
>
> Having it, e.g. KMail runs just fine every time I executed it, what 
> was not the case before (when we needed to kill klauncher and/org 
> dbus-daemon - rather not an option for end users we're starting to 
> demo KDE apps on Windows to :)).
>
> There are sane arguments that certain fixes should be performed at the 
> dbus level, but for now we have another month after the initial 
> discussion and there is nothing better that this KDElibs-level fix. 
> Thus, consider the patch as temporary.
Seems that it is time to talk about the experiences people had with the 
dbus code and how to proceed with this stuff.  :-) 

Ralf





From ralf.habacker at freenet.de  Fri Mar 14 11:00:19 2008
From: ralf.habacker at freenet.de (Ralf Habacker)
Date: Fri, 14 Mar 2008 11:00:19 +0100
Subject: dbus state on windows 
Message-ID: <47DA4CB3.6060608@freenet.de>

Hi,

since dbus was ported to windows involved people had gotten several 
experiences with the dbus code. Is anyone here who will share his 
experience ?

Ralf



From neundorf at kde.org  Fri Mar 14 19:07:09 2008
From: neundorf at kde.org (Alexander Neundorf)
Date: Fri, 14 Mar 2008 19:07:09 +0100
Subject: Cross compiling page in techbase
In-Reply-To: <3262b6180803131758w6c919ff6l90b44d29977ae6fd@mail.gmail.com>
References: <3262b6180803101724g4f454a71vc029d65f2d85df9d@mail.gmail.com>
	<200803140142.27584.neundorf@kde.org>
	<3262b6180803131758w6c919ff6l90b44d29977ae6fd@mail.gmail.com>
Message-ID: <200803141907.09368.neundorf@kde.org>

On Friday 14 March 2008, Carlo wrote:
> On Fri, Mar 14, 2008 at 1:42 AM, Alexander Neundorf <neundorf at kde.org> 
wrote:
> > On Friday 14 March 2008, Carlo wrote:
> >  > On Fri, Mar 14, 2008 at 1:15 AM, Alexander Neundorf <neundorf at kde.org>
> >
> >  wrote:
> >  ...
> >
> > > do you mean something like this?
> > >
> >  > "/windows/kde4/lib/libQtUiTools.a  /windows/kde4/lib/libQtCore4.a"
> >
> >  Yes, but without the quotes, otherwise cmake will interpret it as one
> > file name.
>
> it doesn't work
> *** No rule to make target `/windows/kde4/lib/libQtUiTools.a
> /windows/kde4/lib/libQtCore4.a', needed by `bin/libkjsembed.dll'

Please put the attached file into kdelibs/kjsembed/kjsembed/. It adds 
QT_QTCORE_LIBRARY *after* QtUiTools. This should make it link. 
And please revert the QT_QTUITOOLS_LIBRARY variable to only contain QtUiTools 
again, sorry.

Alex
-------------- next part --------------
project(kjsembed-kjsembed)

if (NOT QTONLY_WEBKIT)
   include_directories(
       ${CMAKE_SOURCE_DIR}
       ${CMAKE_SOURCE_DIR}/kjsembed 
       ${KDE4_KJS_INCLUDES}
       ${KDE4_KDECORE_INCLUDES}
   )
else (NOT QTONLY_WEBKIT)
   include_directories(
       $(QTONLY_WEBKIT_DIR)/JavaScriptCore/kjs
       $(QTONLY_WEBKIT_DIR)/JavaScriptCore
       ${CMAKE_SOURCE_DIR}
       ${CMAKE_SOURCE_DIR}/kjsembed 
       ${KDE4_KDECORE_INCLUDES}
   )
endif (NOT QTONLY_WEBKIT)


########### next target ###############

set(kjsembed_LIB_SRCS
   kjseglobal.cpp
   binding_support.cpp
   static_binding.cpp
   variant_binding.cpp
   object_binding.cpp
   builtins.cpp
   fileio.cpp
   jseventmapper.cpp
   eventproxy.cpp
   slotproxy.cpp
   jseventutils.cpp
   qobject_binding.cpp
   kjsembed.cpp
   value_binding.cpp
   iosupport.cpp
   qwidget_binding.cpp
   qaction_binding.cpp
   qlayout_binding.cpp
   qpainter_binding.cpp
   settings.cpp
   svg_binding.cpp
   filedialog_binding.cpp
   application.cpp
   color.cpp dom.cpp font.cpp image.cpp pen.cpp
   pixmap.cpp point.cpp rect.cpp size.cpp url.cpp
   bind_qlcdnumber.cpp 
   bind_qtimer.cpp
   brush.cpp
   QBrush_bind.cpp
   quiloader_binding.cpp
   )

if (NOT DEFINED QT_ONLY)
   set(KJSLIBNAME kjs)
   set(KJSEMBEDLIBNAME kjsembed)
else (NOT DEFINED QT_ONLY)
   if (NOT QTONLY_WEBKIT)
      set(KJSLIBNAME qkjs)
      set(KJSEMBEDLIBNAME qkjsembed)
   else (NOT QTONLY_WEBKIT)
      set(KJSLIBNAME "${WEBKIT_KJS_LIBRARY}")
      set(KJSEMBEDLIBNAME qwkjsembed)
   endif (NOT QTONLY_WEBKIT)
endif (NOT DEFINED QT_ONLY)

kde4_add_library(${KJSEMBEDLIBNAME} SHARED ${kjsembed_LIB_SRCS})

target_link_libraries(${KJSEMBEDLIBNAME} ${KDE4_KDECORE_LIBS} ${QT_QTUITOOLS_LIBRARY} ${QT_QTGUI_LIBRARY} ${QT_QTSVG_LIBRARY} ${QT_QTXML_LIBRARY} ${QT_QTCORE_LIBRARY} ${KJSLIBNAME} )

set_target_properties(${KJSEMBEDLIBNAME} PROPERTIES VERSION ${GENERIC_LIB_VERSION} SOVERSION ${GENERIC_LIB_SOVERSION} )
install(TARGETS ${KJSEMBEDLIBNAME} ${INSTALL_TARGETS_DEFAULT_ARGS})








From brandon.ml at gmail.com  Sun Mar 16 03:13:52 2008
From: brandon.ml at gmail.com (Carlo)
Date: Sun, 16 Mar 2008 03:13:52 +0100
Subject: Cross compiling page in techbase
In-Reply-To: <200803141907.09368.neundorf@kde.org>
References: <3262b6180803101724g4f454a71vc029d65f2d85df9d@mail.gmail.com>
	<200803140142.27584.neundorf@kde.org>
	<3262b6180803131758w6c919ff6l90b44d29977ae6fd@mail.gmail.com>
	<200803141907.09368.neundorf@kde.org>
Message-ID: <3262b6180803151913j7f530bb0m32c50f2c319068b0@mail.gmail.com>

On Fri, Mar 14, 2008 at 7:07 PM, Alexander Neundorf <neundorf at kde.org> wrote:
> On Friday 14 March 2008, Carlo wrote:
>  > On Fri, Mar 14, 2008 at 1:42 AM, Alexander Neundorf <neundorf at kde.org>
>  wrote:
>  > > On Friday 14 March 2008, Carlo wrote:
>  > >  > On Fri, Mar 14, 2008 at 1:15 AM, Alexander Neundorf <neundorf at kde.org>
>  > >
>  > >  wrote:
>  > >  ...
>  > >
>  > > > do you mean something like this?
>  > > >
>  > >  > "/windows/kde4/lib/libQtUiTools.a  /windows/kde4/lib/libQtCore4.a"
>  > >
>  > >  Yes, but without the quotes, otherwise cmake will interpret it as one
>  > > file name.
>  >
>  > it doesn't work
>  > *** No rule to make target `/windows/kde4/lib/libQtUiTools.a
>  > /windows/kde4/lib/libQtCore4.a', needed by `bin/libkjsembed.dll'
>
>  Please put the attached file into kdelibs/kjsembed/kjsembed/. It adds
>  QT_QTCORE_LIBRARY *after* QtUiTools. This should make it link.
>  And please revert the QT_QTUITOOLS_LIBRARY variable to only contain QtUiTools
>  again, sorry.
It works


From raviratlami at gmail.com  Sun Mar 16 12:33:15 2008
From: raviratlami at gmail.com (Ravishankar Shrivastava)
Date: Sun, 16 Mar 2008 17:03:15 +0530
Subject: KDE windows Localized build
Message-ID: <47DD057B.4070808@gmail.com>

Hi,
I am new to this list so please forgive me for my ignorance. Can some 
one point to the links / resources / docs for installing KDE in Windows 
in languages other than Default English? For example, I want to install 
and run KDE in Hindi language environment, what should I do?

Regards,
Ravi


From michael.a.oshea at gmail.com  Sun Mar 16 13:02:46 2008
From: michael.a.oshea at gmail.com (Michael O'Shea)
Date: Sun, 16 Mar 2008 13:02:46 +0100
Subject: kdelibs doesn't build
Message-ID: <d323dcfd0803160502u3cd66100jd31021ca26ec214f@mail.gmail.com>

Hi chaps,

kdelibs fails to build due to makekdewidgets failing silently.

I have EMERGE_BUILDTYPE=Debug

The output of makekdewidgets is as follows :

'makekdewidgets.exe': Loaded
'D:\stuff\KDE4_win32\root\bin\makekdewidgets.exe', No symbols loaded.
'makekdewidgets.exe': Loaded 'C:\WINDOWS\system32\ntdll.dll', No symbols
loaded.
'makekdewidgets.exe': Loaded 'C:\WINDOWS\system32\kernel32.dll', No symbols
loaded.
'makekdewidgets.exe': Loaded 'D:\stuff\KDE4_win32\root\bin\QtCore4.dll',
Binary was not built with debug information.
'makekdewidgets.exe': Loaded 'C:\WINDOWS\system32\user32.dll', No symbols
loaded.
'makekdewidgets.exe': Loaded 'C:\WINDOWS\system32\gdi32.dll', No symbols
loaded.
'makekdewidgets.exe': Loaded 'C:\WINDOWS\system32\ole32.dll', No symbols
loaded.
'makekdewidgets.exe': Loaded 'C:\WINDOWS\system32\advapi32.dll', No symbols
loaded.
'makekdewidgets.exe': Loaded 'C:\WINDOWS\system32\rpcrt4.dll', No symbols
loaded.
'makekdewidgets.exe': Loaded 'C:\WINDOWS\system32\msvcrt.dll', No symbols
loaded.
'makekdewidgets.exe': Loaded 'C:\WINDOWS\system32\ws2_32.dll', No symbols
loaded.
'makekdewidgets.exe': Loaded 'C:\WINDOWS\system32\ws2help.dll', No symbols
loaded.
'makekdewidgets.exe': Loaded
'C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_6b128700\msvcp80.dll',
No symbols loaded.
'makekdewidgets.exe': Loaded
'C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_6b128700\msvcr80.dll',
No symbols loaded.
'makekdewidgets.exe': Loaded 'D:\stuff\KDE4_win32\root\bin\kdecore.dll', No
symbols loaded.
'makekdewidgets.exe': Loaded 'D:\stuff\KDE4_win32\root\bin\QtNetwork4.dll',
Binary was not built with debug information.
'makekdewidgets.exe': Loaded 'D:\stuff\KDE4_win32\root\bin\QtDBus4.dll',
Binary was not built with debug information.
'makekdewidgets.exe': Loaded 'D:\stuff\KDE4_win32\root\bin\dbus-1.dll',
Binary was not built with debug information.
'makekdewidgets.exe': Loaded 'D:\stuff\KDE4_win32\root\bin\QtXml4.dll',
Binary was not built with debug information.
'makekdewidgets.exe': Loaded 'D:\stuff\KDE4_win32\root\bin\kdewin32.dll',
Symbols loaded.
'makekdewidgets.exe': Loaded 'C:\WINDOWS\system32\shell32.dll', No symbols
loaded.
'makekdewidgets.exe': Loaded 'C:\WINDOWS\system32\shlwapi.dll', No symbols
loaded.
'makekdewidgets.exe': Loaded 'C:\WINDOWS\system32\netapi32.dll', No symbols
loaded.
'makekdewidgets.exe': Loaded 'C:\WINDOWS\system32\userenv.dll', No symbols
loaded.
'makekdewidgets.exe': Loaded 'D:\stuff\KDE4_win32\root\bin\bzip2.dll',
Binary was not built with debug information.
'makekdewidgets.exe': Loaded 'D:\stuff\KDE4_win32\root\bin\libintl3.dll',
Binary was not built with debug information.
'makekdewidgets.exe': Loaded 'D:\stuff\KDE4_win32\root\bin\libiconv2.dll',
Binary was not built with debug information.
'makekdewidgets.exe': Loaded
'C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.2982_x-ww_ac3f9c03\comctl32.dll',
No symbols loaded.
'makekdewidgets.exe': Loaded 'C:\WINDOWS\system32\comctl32.dll', No symbols
loaded.
'makekdewidgets.exe': Loaded 'C:\WINDOWS\system32\EntAPI.dll', No symbols
loaded.
'makekdewidgets.exe': Loaded 'C:\WINDOWS\system32\psapi.dll', No symbols
loaded.
'makekdewidgets.exe': Unloaded 'C:\WINDOWS\system32\EntAPI.dll'
'makekdewidgets.exe': Unloaded 'C:\WINDOWS\system32\psapi.dll'
'makekdewidgets.exe': Loaded 'C:\WINDOWS\system32\version.dll', No symbols
loaded.
'makekdewidgets.exe': Loaded 'C:\WINDOWS\system32\secur32.dll', No symbols
loaded.
The program '[4684] makekdewidgets.exe: Native' has exited with code 0
(0x0).

Does this say anything to anyone ?

But more to the point : I really need to be able to build kdelibs properly
and have not been able for close to a month now. Is this a generalised
problem or am I the only one with this problem ?

I'm considering wiping and starting again in order to get back on track.

Any help welcome.

Cheers,

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kde-windows/attachments/20080316/df51fe59/attachment.html 

From Ch.Ehrlicher at gmx.de  Sun Mar 16 13:07:28 2008
From: Ch.Ehrlicher at gmx.de (Christian Ehrlicher)
Date: Sun, 16 Mar 2008 13:07:28 +0100
Subject: KDE windows Localized build
In-Reply-To: <47DD057B.4070808@gmail.com>
References: <47DD057B.4070808@gmail.com>
Message-ID: <47DD0D80.2040908@gmx.de>

Ravishankar Shrivastava schrieb:
> Hi,
> I am new to this list so please forgive me for my ignorance. Can some 
> one point to the links / resources / docs for installing KDE in Windows 
> in languages other than Default English? For example, I want to install 
> and run KDE in Hindi language environment, what should I do?

This is not yet implemented.


Christian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 258 bytes
Desc: OpenPGP digital signature
Url : http://mail.kde.org/pipermail/kde-windows/attachments/20080316/4a19cada/attachment.pgp 

From Ch.Ehrlicher at gmx.de  Sun Mar 16 13:09:11 2008
From: Ch.Ehrlicher at gmx.de (Christian Ehrlicher)
Date: Sun, 16 Mar 2008 13:09:11 +0100
Subject: kdelibs doesn't build
In-Reply-To: <d323dcfd0803160502u3cd66100jd31021ca26ec214f@mail.gmail.com>
References: <d323dcfd0803160502u3cd66100jd31021ca26ec214f@mail.gmail.com>
Message-ID: <47DD0DE7.4070307@gmx.de>

Michael O'Shea schrieb:
> Hi chaps,
> 
> kdelibs fails to build due to makekdewidgets failing silently.
> 
> I have EMERGE_BUILDTYPE=Debug
> 
> The output of makekdewidgets is as follows :
> 
> 'makekdewidgets.exe': Loaded
> 'D:\stuff\KDE4_win32\root\bin\makekdewidgets.exe', No symbols loaded.
> 'makekdewidgets.exe': Loaded 'C:\WINDOWS\system32\ntdll.dll', No symbols
> loaded.
> 'makekdewidgets.exe': Loaded 'C:\WINDOWS\system32\kernel32.dll', No symbols
> loaded.
> 'makekdewidgets.exe': Loaded 'D:\stuff\KDE4_win32\root\bin\QtCore4.dll',
> Binary was not built with debug information.

once more - this can't work.
qt is build in release mode (and also the release libs are used), you 
build kdelibs in debug mode.


Make sure your apps get linked against qtcore4d.dll/.lib



Christian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 258 bytes
Desc: OpenPGP digital signature
Url : http://mail.kde.org/pipermail/kde-windows/attachments/20080316/72dd4d61/attachment.pgp 

From neundorf at kde.org  Sun Mar 16 13:15:37 2008
From: neundorf at kde.org (Alexander Neundorf)
Date: Sun, 16 Mar 2008 13:15:37 +0100
Subject: Cross compiling page in techbase
In-Reply-To: <3262b6180803151913j7f530bb0m32c50f2c319068b0@mail.gmail.com>
References: <3262b6180803101724g4f454a71vc029d65f2d85df9d@mail.gmail.com>
	<200803141907.09368.neundorf@kde.org>
	<3262b6180803151913j7f530bb0m32c50f2c319068b0@mail.gmail.com>
Message-ID: <200803161315.37812.neundorf@kde.org>

On Sunday 16 March 2008, Carlo wrote:
> On Fri, Mar 14, 2008 at 7:07 PM, Alexander Neundorf <neundorf at kde.org> 
wrote:
> > On Friday 14 March 2008, Carlo wrote:
> >  > On Fri, Mar 14, 2008 at 1:42 AM, Alexander Neundorf <neundorf at kde.org>
> >
> >  wrote:
> >  > > On Friday 14 March 2008, Carlo wrote:
> >  > >  > On Fri, Mar 14, 2008 at 1:15 AM, Alexander Neundorf
> >  > >  > <neundorf at kde.org>
> >  > >
> >  > >  wrote:
> >  > >  ...
> >  > >
> >  > > > do you mean something like this?
> >  > > >
> >  > >  > "/windows/kde4/lib/libQtUiTools.a 
> >  > >  > /windows/kde4/lib/libQtCore4.a"
> >  > >
> >  > >  Yes, but without the quotes, otherwise cmake will interpret it as
> >  > > one file name.
> >  >
> >  > it doesn't work
> >  > *** No rule to make target `/windows/kde4/lib/libQtUiTools.a
> >  > /windows/kde4/lib/libQtCore4.a', needed by `bin/libkjsembed.dll'
> >
> >  Please put the attached file into kdelibs/kjsembed/kjsembed/. It adds
> >  QT_QTCORE_LIBRARY *after* QtUiTools. This should make it link.
> >  And please revert the QT_QTUITOOLS_LIBRARY variable to only contain
> > QtUiTools again, sorry.
>
> It works

Can you please update the wiki page so it shows what you have to do with 
current kdelibs svn and current cmake cvs ?
(...and I get an overview over the current state myself :-)

Alex


From ralf.habacker at freenet.de  Sun Mar 16 14:10:15 2008
From: ralf.habacker at freenet.de (Ralf Habacker)
Date: Sun, 16 Mar 2008 14:10:15 +0100
Subject: KDE windows Localized build
In-Reply-To: <47DD057B.4070808@gmail.com>
References: <47DD057B.4070808@gmail.com>
Message-ID: <47DD1C37.8090808@freenet.de>

Ravishankar Shrivastava schrieb:
> Hi,
> I am new to this list so please forgive me for my ignorance. Can some 
> one point to the links / resources / docs for installing KDE in Windows 
> in languages other than Default English? For example, I want to install 
> and run KDE in Hindi language environment, what should I do?
>   
We are at the very early state of building language packages and your 
requested language is not available out of the box. You need to build 
the related language pack by yourself. You can use   
http://websvn.kde.org/trunk/l10n-kde4/README?revision=783885&view=markup 
as a starting point.

Regards
 Ralf



From brandon.ml at gmail.com  Mon Mar 17 03:48:04 2008
From: brandon.ml at gmail.com (Carlo)
Date: Mon, 17 Mar 2008 03:48:04 +0100
Subject: Cross compiling page in techbase
In-Reply-To: <200803161315.37812.neundorf@kde.org>
References: <3262b6180803101724g4f454a71vc029d65f2d85df9d@mail.gmail.com>
	<200803141907.09368.neundorf@kde.org>
	<3262b6180803151913j7f530bb0m32c50f2c319068b0@mail.gmail.com>
	<200803161315.37812.neundorf@kde.org>
Message-ID: <3262b6180803161948g628f67f9u7708fcaa1d6e43bc@mail.gmail.com>

On Sun, Mar 16, 2008 at 1:15 PM, Alexander Neundorf <neundorf at kde.org> wrote:
>
> On Sunday 16 March 2008, Carlo wrote:
>  > On Fri, Mar 14, 2008 at 7:07 PM, Alexander Neundorf <neundorf at kde.org>
>  wrote:
>  > > On Friday 14 March 2008, Carlo wrote:
>  > >  > On Fri, Mar 14, 2008 at 1:42 AM, Alexander Neundorf <neundorf at kde.org>
>  > >
>  > >  wrote:
>  > >  > > On Friday 14 March 2008, Carlo wrote:
>  > >  > >  > On Fri, Mar 14, 2008 at 1:15 AM, Alexander Neundorf
>  > >  > >  > <neundorf at kde.org>
>  > >  > >
>  > >  > >  wrote:
>  > >  > >  ...
>  > >  > >
>  > >  > > > do you mean something like this?
>  > >  > > >
>  > >  > >  > "/windows/kde4/lib/libQtUiTools.a
>  > >  > >  > /windows/kde4/lib/libQtCore4.a"
>  > >  > >
>  > >  > >  Yes, but without the quotes, otherwise cmake will interpret it as
>  > >  > > one file name.
>  > >  >
>  > >  > it doesn't work
>  > >  > *** No rule to make target `/windows/kde4/lib/libQtUiTools.a
>  > >  > /windows/kde4/lib/libQtCore4.a', needed by `bin/libkjsembed.dll'
>  > >
>  > >  Please put the attached file into kdelibs/kjsembed/kjsembed/. It adds
>  > >  QT_QTCORE_LIBRARY *after* QtUiTools. This should make it link.
>  > >  And please revert the QT_QTUITOOLS_LIBRARY variable to only contain
>  > > QtUiTools again, sorry.
>  >
>  > It works
>
>  Can you please update the wiki page so it shows what you have to do with
>  current kdelibs svn and current cmake cvs ?
>  (...and I get an overview over the current state myself :-)
>
>
>
>  Alex
>  _______________________________________________
>  Kde-windows mailing list
>  Kde-windows at kde.org
>  https://mail.kde.org/mailman/listinfo/kde-windows
>

Ok i've updated the wiki,
btw I've tried to cross-compile kdewin32 and there is another case
sensitive issue, in CmakeLists.txt there is find_package(WinScp) while
the file is called FindWinSCP.cmake so it should be fixed either in
cmakelists or renaming the file


From gueven.bay at googlemail.com  Mon Mar 17 08:22:14 2008
From: gueven.bay at googlemail.com (Gueven Bay)
Date: Mon, 17 Mar 2008 08:22:14 +0100
Subject: Emerge mingw fails...
Message-ID: <13413b8f0803170022j5dd0edbewd68e3392206b7081@mail.gmail.com>

Hello,

I checked out emerge and set my environment with kdeenv.bat. The
checkout gave me revision 786487 and my environment is defined as:
kdesettings.bat executed
KDEROOT     : H:\kderoot
KDECOMPILER : mingw
KDESVNDIR   : H:\kderoot\kdesvn
PYTHONPATH  : H:\Python25
DOWNLOADDIR : H:\kderoot\kdedownload

After emerge mingw I get follwing errors/output:

H:\kderoot>emerge mingw
H:\kderoot>echo emerge.bat executed
emerge.bat executed
H:\kderoot>python H:\kderoot\emerge\bin\emerge.py mingw
buildAction: all
doPretend: False
packageName: mingw
buildType: RelWithDebInfo
buildTests: None
verbose: 1
KDEROOT: H:\kderoot
emerge warning: installed db file does not exist
setdir category: gnuwin32, package: wget, version: 1.10.1
cmakeInstallPrefix: H:/kderoot
setdir category: gnuwin32, package: wget, version: 1.10.1
cmakeInstallPrefix: H:/kderoot
Traceback (most recent call last):
  File "H:\kderoot\emerge\portage\gnuwin32\wget\wget-1.10.1.py", line 20, in <mo
dule>
    subclass().execute()
  File "H:\kderoot\emerge\bin\base.py", line 145, in execute
    elif command == "unpack":      ok = self.unpack()
  File "H:\kderoot\emerge\bin\base.py", line 184, in unpack
    return utils.unpackFiles( self.downloaddir, self.filenames, self.workdir )
AttributeError: subclass instance has no attribute 'filenames'
emerge fatal error: running python H:\kderoot\emerge\portage\gnuwin32\wget\wget-
1.10.1.py unpack
emerge error: fatal error: package gnuwin32/wget-1.10.1 all failed
emerge warning: installed db file does not exist
setdir category: gnuwin32, package: patch, version: 2.5.9-7
cmakeInstallPrefix: H:/kderoot
setdir category: gnuwin32, package: patch, version: 2.5.9-7
cmakeInstallPrefix: H:/kderoot
Traceback (most recent call last):
  File "H:\kderoot\emerge\portage\gnuwin32\patch\patch-2.5.9-7.py", line 22, in
<module>
    subclass().execute()
  File "H:\kderoot\emerge\bin\base.py", line 145, in execute
    elif command == "unpack":      ok = self.unpack()
  File "H:\kderoot\emerge\bin\base.py", line 184, in unpack
    return utils.unpackFiles( self.downloaddir, self.filenames, self.workdir )
AttributeError: subclass instance has no attribute 'filenames'
emerge fatal error: running python H:\kderoot\emerge\portage\gnuwin32\patch\patc
h-2.5.9-7.py unpack
emerge error: fatal error: package gnuwin32/patch-2.5.9-7 all failed
emerge warning: installed db file does not exist
setdir category: dev-util, package: mingw, version: 3.4.5
cmakeInstallPrefix: H:/kderoot
setdir category: dev-util, package: mingw, version: 3.4.5
cmakeInstallPrefix: H:/kderoot
Traceback (most recent call last):
  File "H:\kderoot\emerge\portage\dev-util\mingw\mingw-3.4.5.py", line 62, in <m
odule>
    subclass().execute()
  File "H:\kderoot\emerge\bin\base.py", line 145, in execute
    elif command == "unpack":      ok = self.unpack()
  File "H:\kderoot\emerge\portage\dev-util\mingw\mingw-3.4.5.py", line 45, in un
pack
    base.baseclass.unpack( self )
  File "H:\kderoot\emerge\bin\base.py", line 184, in unpack
    return utils.unpackFiles( self.downloaddir, self.filenames, self.workdir )
AttributeError: subclass instance has no attribute 'filenames'
emerge fatal error: running python H:\kderoot\emerge\portage\dev-util\mingw\ming
w-3.4.5.py unpack
emerge error: fatal error: package dev-util/mingw-3.4.5 all failed


Can someone tel me, please, how to successfully emerge mingw?

Thank you


From js at iidea.pl  Mon Mar 17 09:54:21 2008
From: js at iidea.pl (=?UTF-8?B?SmFyb3PFgmF3IFN0YW5pZWs=?=)
Date: Mon, 17 Mar 2008 09:54:21 +0100
Subject: KDE windows Localized build
In-Reply-To: <47DD057B.4070808@gmail.com>
References: <47DD057B.4070808@gmail.com>
Message-ID: <47DE31BD.7030609@iidea.pl>

Ravishankar Shrivastava said the following, On 2008-03-16 12:33:
> Hi,
> I am new to this list so please forgive me for my ignorance. Can some 
> one point to the links / resources / docs for installing KDE in Windows 
> in languages other than Default English? For example, I want to install 
> and run KDE in Hindi language environment, what should I do?

In addition to what Christian and Ralf said: KDE apps/libs can now load proper 
translation data from .mo files located in KDEROOT/share/locale/ by default 
looking at your system settings, unless you have your Lanuguage

-- 
regards / pozdrawiam, Jaroslaw Staniek
  Sponsored by OpenOffice Polska (http://www.openoffice.com.pl/en) to work on
  Kexi & KOffice (http://www.kexi.pl/en, http://www.koffice.org/kexi)
  KDE Libraries for MS Windows (http://windows.kde.org)


From ralf.habacker at freenet.de  Mon Mar 17 12:01:41 2008
From: ralf.habacker at freenet.de (Ralf Habacker)
Date: Mon, 17 Mar 2008 12:01:41 +0100
Subject: [patch] KUniqueApplication: dbus service cleanup for Windows
In-Reply-To: <47D922D3.5060501@iidea.pl>
References: <47D922D3.5060501@iidea.pl>
Message-ID: <47DE4F95.7080005@freenet.de>

Jaros?aw Staniek schrieb:
>
> For review.
> As discussed before in the thread [1], there are problems
> with running KUniqueApplications on Windows because previous dbus 
> service has
> not been unregistered, resulting in "KUniqueApplication: Can't setup 
> D-Bus
> service. Probably already running." and forced app quit.
>
> Having it, e.g. KMail runs just fine every time I executed it, what 
> was not the case before (when we needed to kill klauncher and/org 
> dbus-daemon - rather not an option for end users we're starting to 
> demo KDE apps on Windows to :)).
>
> There are sane arguments that certain fixes should be performed at the 
> dbus level, but for now we have another month after the initial 
> discussion and there is nothing better that this KDElibs-level fix. 
> Thus, consider the patch as temporary.
>
> [1] http://lists.kde.org/?t=120294760700003&r=1&w=2
>
looks that there are no objectivies against a temporary solution

Ralf


From js at iidea.pl  Mon Mar 17 14:23:12 2008
From: js at iidea.pl (=?UTF-8?B?SmFyb3PFgmF3IFN0YW5pZWs=?=)
Date: Mon, 17 Mar 2008 14:23:12 +0100
Subject: Request: remove dummy readdir_r() until it's implemented
Message-ID: <47DE70C0.1020307@iidea.pl>


Hello
Let's note that code kio/kio/kurlcompletion.cpp like uses #ifdef HAVE_READDIR_R.

We have dummy readdir_r() so in windows build HAVE_READDIR_R is set.
This breaks kurlcompletion.

lxr.kde.org told me for now the only other place using readdir_r is 
kphotoalbum, and also provides apprpriate ifdef.

Any objections?


-- 
regards / pozdrawiam, Jaroslaw Staniek
  Sponsored by OpenOffice Polska (http://www.openoffice.com.pl/en) to work on
  Kexi & KOffice (http://www.kexi.pl/en, http://www.koffice.org/kexi)
  KDE Libraries for MS Windows (http://windows.kde.org)


From Ch.Ehrlicher at gmx.de  Mon Mar 17 15:15:42 2008
From: Ch.Ehrlicher at gmx.de (Christian Ehrlicher)
Date: Mon, 17 Mar 2008 15:15:42 +0100
Subject: Request: remove dummy readdir_r() until it's implemented
In-Reply-To: <47DE70C0.1020307@iidea.pl>
References: <47DE70C0.1020307@iidea.pl>
Message-ID: <20080317141542.153730@gmx.net>

> Von: "Jaros?aw Staniek"
> 
> Hello
> Let's note that code kio/kio/kurlcompletion.cpp like uses #ifdef
> HAVE_READDIR_R.
> 
> We have dummy readdir_r() so in windows build HAVE_READDIR_R is set.
> This breaks kurlcompletion.
> 
> lxr.kde.org told me for now the only other place using readdir_r is 
> kphotoalbum, and also provides apprpriate ifdef.
> 
> Any objections?
> 
Just remove non-working stuff so we get aware of this problems and can replace it (if possible) with Qt functions.


Christian
-- 
Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten 
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser


From gueven.bay at googlemail.com  Mon Mar 17 17:24:56 2008
From: gueven.bay at googlemail.com (Gueven Bay)
Date: Mon, 17 Mar 2008 17:24:56 +0100
Subject: Emerge mingw fails...
Message-ID: <13413b8f0803170924o75984943i41b25e3d5e5676c6@mail.gmail.com>

I have now updated emerge to the revision 786660.

Still the command "emerge mingw" fails.
For any chance that the failure is on my side I looked again at the
emerge howto on the Techbase and controlled checkout and settings and
commands. I also searched for the error message but got only links to
discussions with other Python modules not emerge on Windows.

I hope that someone can give me a tip how to continue. And/or that
someone can explain me the cause of the error.


The error message:

H:\kderoot>emerge mingw

H:\kderoot>echo emerge.bat executed
emerge.bat executed

H:\kderoot>python H:\kderoot\emerge\bin\emerge.py mingw
buildAction: all
doPretend: False
packageName: mingw
buildType: RelWithDebInfo
buildTests: None
verbose: 1
KDEROOT: H:\kderoot
emerge warning: installed db file does not exist
setdir category: gnuwin32, package: wget, version: 1.10.1
cmakeInstallPrefix: H:/kderoot
setdir category: gnuwin32, package: wget, version: 1.10.1
cmakeInstallPrefix: H:/kderoot
Traceback (most recent call last):
  File "H:\kderoot\emerge\portage\gnuwin32\wget\wget-1.10.1.py", line 20, in <mo
dule>
    subclass().execute()
  File "H:\kderoot\emerge\bin\base.py", line 154, in execute
    elif command == "unpack":      ok = self.unpack()
  File "H:\kderoot\emerge\bin\base.py", line 193, in unpack
    return utils.unpackFiles( self.downloaddir, self.filenames, self.workdir )
AttributeError: subclass instance has no attribute 'filenames'
emerge fatal error: running python H:\kderoot\emerge\portage\gnuwin32\wget\wget-
1.10.1.py unpack
emerge error: fatal error: package gnuwin32/wget-1.10.1 all failed
emerge warning: installed db file does not exist
setdir category: gnuwin32, package: patch, version: 2.5.9-7
cmakeInstallPrefix: H:/kderoot
setdir category: gnuwin32, package: patch, version: 2.5.9-7
cmakeInstallPrefix: H:/kderoot
Traceback (most recent call last):
  File "H:\kderoot\emerge\portage\gnuwin32\patch\patch-2.5.9-7.py", line 22, in
<module>
    subclass().execute()
  File "H:\kderoot\emerge\bin\base.py", line 154, in execute
    elif command == "unpack":      ok = self.unpack()
  File "H:\kderoot\emerge\bin\base.py", line 193, in unpack
    return utils.unpackFiles( self.downloaddir, self.filenames, self.workdir )
AttributeError: subclass instance has no attribute 'filenames'
emerge fatal error: running python H:\kderoot\emerge\portage\gnuwin32\patch\patc
h-2.5.9-7.py unpack
emerge error: fatal error: package gnuwin32/patch-2.5.9-7 all failed
emerge warning: installed db file does not exist
setdir category: dev-util, package: mingw, version: 3.4.5
cmakeInstallPrefix: H:/kderoot
setdir category: dev-util, package: mingw, version: 3.4.5
cmakeInstallPrefix: H:/kderoot
Traceback (most recent call last):
  File "H:\kderoot\emerge\portage\dev-util\mingw\mingw-3.4.5.py", line 62, in <m
odule>
    subclass().execute()
  File "H:\kderoot\emerge\bin\base.py", line 154, in execute
    elif command == "unpack":      ok = self.unpack()
  File "H:\kderoot\emerge\portage\dev-util\mingw\mingw-3.4.5.py", line 45, in un
pack
    base.baseclass.unpack( self )
  File "H:\kderoot\emerge\bin\base.py", line 193, in unpack
    return utils.unpackFiles( self.downloaddir, self.filenames, self.workdir )
AttributeError: subclass instance has no attribute 'filenames'
emerge fatal error: running python H:\kderoot\emerge\portage\dev-util\mingw\ming
w-3.4.5.py unpack
emerge error: fatal error: package dev-util/mingw-3.4.5 all failed


From neundorf at kde.org  Mon Mar 17 19:37:30 2008
From: neundorf at kde.org (Alexander Neundorf)
Date: Mon, 17 Mar 2008 19:37:30 +0100
Subject: Cross compiling page in techbase
In-Reply-To: <3262b6180803161948g628f67f9u7708fcaa1d6e43bc@mail.gmail.com>
References: <3262b6180803101724g4f454a71vc029d65f2d85df9d@mail.gmail.com>
	<200803161315.37812.neundorf@kde.org>
	<3262b6180803161948g628f67f9u7708fcaa1d6e43bc@mail.gmail.com>
Message-ID: <200803171937.31262.neundorf@kde.org>

On Monday 17 March 2008, Carlo wrote:
> On Sun, Mar 16, 2008 at 1:15 PM, Alexander Neundorf <neundorf at kde.org> 
...
> >  Can you please update the wiki page so it shows what you have to do with
> >  current kdelibs svn and current cmake cvs ?
> >  (...and I get an overview over the current state myself :-)
> >
>
> Ok i've updated the wiki,
> btw I've tried to cross-compile kdewin32 and there is another case
> sensitive issue, in CmakeLists.txt there is find_package(WinScp) while
> the file is called FindWinSCP.cmake so it should be fixed either in
> cmakelists or renaming the file

CMakeLists.txt is the right plae ti fix it.

Thanks
Alex


From brandon.ml at gmail.com  Mon Mar 17 19:35:21 2008
From: brandon.ml at gmail.com (Carlo)
Date: Mon, 17 Mar 2008 19:35:21 +0100
Subject: Cross compiling page in techbase
In-Reply-To: <200803171937.31262.neundorf@kde.org>
References: <3262b6180803101724g4f454a71vc029d65f2d85df9d@mail.gmail.com>
	<200803161315.37812.neundorf@kde.org>
	<3262b6180803161948g628f67f9u7708fcaa1d6e43bc@mail.gmail.com>
	<200803171937.31262.neundorf@kde.org>
Message-ID: <3262b6180803171135g11ac650cxf27912d5f7626610@mail.gmail.com>

On Mon, Mar 17, 2008 at 7:37 PM, Alexander Neundorf <neundorf at kde.org> wrote:
> On Monday 17 March 2008, Carlo wrote:
>  > On Sun, Mar 16, 2008 at 1:15 PM, Alexander Neundorf <neundorf at kde.org>
>  ...
>
> > >  Can you please update the wiki page so it shows what you have to do with
>  > >  current kdelibs svn and current cmake cvs ?
>  > >  (...and I get an overview over the current state myself :-)
>  > >
>  >
>
> > Ok i've updated the wiki,
>  > btw I've tried to cross-compile kdewin32 and there is another case
>  > sensitive issue, in CmakeLists.txt there is find_package(WinScp) while
>  > the file is called FindWinSCP.cmake so it should be fixed either in
>  > cmakelists or renaming the file
>
>  CMakeLists.txt is the right plae ti fix it.
>
>  Thanks
>  Alex
>

SaroEngels fixed it today


From neundorf at kde.org  Mon Mar 17 22:09:44 2008
From: neundorf at kde.org (Alexander Neundorf)
Date: Mon, 17 Mar 2008 22:09:44 +0100
Subject: Cross compiling page in techbase
In-Reply-To: <3262b6180803161948g628f67f9u7708fcaa1d6e43bc@mail.gmail.com>
References: <3262b6180803101724g4f454a71vc029d65f2d85df9d@mail.gmail.com>
	<200803161315.37812.neundorf@kde.org>
	<3262b6180803161948g628f67f9u7708fcaa1d6e43bc@mail.gmail.com>
Message-ID: <200803172209.45027.neundorf@kde.org>

On Monday 17 March 2008, Carlo wrote:
...
> Ok i've updated the wiki,

Thanks :-)
I made some more changes to it:
-I committed the fix for kjsembed, so this should now work out-of-the-svn ;-)
-the mingw32-kdelibs.cmake file should not be used when building kdelibs
-KDE4_INSTALL_DIR should now be correctly detected using FindKDE4.cmake from 
cmake cvs, so I removed this from the two files. Unfortunately the settings 
fro Qt in the toolchain file are broken by that, can you please fix this by 
making the Qt variables relative to some Qt base directory instead relative 
to KDE4_INSTALL_DIR ?

Alex


From brandon.ml at gmail.com  Tue Mar 18 19:12:38 2008
From: brandon.ml at gmail.com (Carlo)
Date: Tue, 18 Mar 2008 19:12:38 +0100
Subject: Cross compiling page in techbase
In-Reply-To: <200803172209.45027.neundorf@kde.org>
References: <3262b6180803101724g4f454a71vc029d65f2d85df9d@mail.gmail.com>
	<200803161315.37812.neundorf@kde.org>
	<3262b6180803161948g628f67f9u7708fcaa1d6e43bc@mail.gmail.com>
	<200803172209.45027.neundorf@kde.org>
Message-ID: <3262b6180803181112q2935977ew2083bc81c0a137d5@mail.gmail.com>

On Mon, Mar 17, 2008 at 10:09 PM, Alexander Neundorf <neundorf at kde.org> wrote:
> On Monday 17 March 2008, Carlo wrote:
>  ...
>
> > Ok i've updated the wiki,
>
>  Thanks :-)
>  I made some more changes to it:
>  -I committed the fix for kjsembed, so this should now work out-of-the-svn ;-)
>  -the mingw32-kdelibs.cmake file should not be used when building kdelibs
yeah but we need to disable gssapi when compiling kdelibs
>  -KDE4_INSTALL_DIR should now be correctly detected using FindKDE4.cmake from
>  cmake cvs, so I removed this from the two files. Unfortunately the settings
>  fro Qt in the toolchain file are broken by that, can you please fix this by
>  making the Qt variables relative to some Qt base directory instead relative
>  to KDE4_INSTALL_DIR ?
I changed the name to KDE_PREFIX but it should be setted by the user,
also KDE4_DATA_DIR is needed otherwise it doesn't find the cmake
modules

From ralf.habacker at freenet.de  Tue Mar 18 20:29:07 2008
From: ralf.habacker at freenet.de (Ralf Habacker)
Date: Tue, 18 Mar 2008 20:29:07 +0100
Subject: dbus state on windows
In-Reply-To: <200803162135.33136.till@kdab.net>
References: <47DA4CB3.6060608@freenet.de> <200803162135.33136.till@kdab.net>
Message-ID: <47E01803.6030106@freenet.de>

Till Adam schrieb:
> Ralf,
>
> On Friday 14 March 2008 11:00:19 Ralf Habacker wrote:
>
>   
>> since dbus was ported to windows involved people had gotten several
>> experiences with the dbus code. Is anyone here who will share his
>> experience ?
>>     
>
> I'm not sure I understand what you mean here. Can you please elaborate?
>   
There were several private discussions between windows people how to 
proceed with dbus because there are issues with the implementation.  
There are people who wished to drop the dbus implementation and to 
rewrite a new implementation for windows. A short time ago I was 
informed that unix kde developer had a similar discussion.

Because this rumors already some time in the background it may be good 
to make this public to get a better understanding about the best way to go.

I had gotten specific experience while working on the dbus code - in 
fact that the code isn't maintainable in spare time - but this is a 
personal meaning and it may be caused by my limited understanding of 
dbus internals.

Any comments ?

Ralf


From neundorf at kde.org  Tue Mar 18 22:15:42 2008
From: neundorf at kde.org (Alexander Neundorf)
Date: Tue, 18 Mar 2008 22:15:42 +0100
Subject: Cross compiling page in techbase
In-Reply-To: <3262b6180803181112q2935977ew2083bc81c0a137d5@mail.gmail.com>
References: <3262b6180803101724g4f454a71vc029d65f2d85df9d@mail.gmail.com>
	<200803172209.45027.neundorf@kde.org>
	<3262b6180803181112q2935977ew2083bc81c0a137d5@mail.gmail.com>
Message-ID: <200803182215.42520.neundorf@kde.org>

On Tuesday 18 March 2008, Carlo wrote:
> On Mon, Mar 17, 2008 at 10:09 PM, Alexander Neundorf <neundorf at kde.org> 
wrote:
> > On Monday 17 March 2008, Carlo wrote:
> >  ...
> >
> > > Ok i've updated the wiki,
> >
> >  Thanks :-)
> >  I made some more changes to it:
> >  -I committed the fix for kjsembed, so this should now work
> > out-of-the-svn ;-) -the mingw32-kdelibs.cmake file should not be used
> > when building kdelibs
>
> yeah but we need to disable gssapi when compiling kdelibs

Please update kdelibs/cmake/modules/FindGSSAPI.cmake, I committed a patch so 
that it shouldn't find the build host executable anymore.

> >  -KDE4_INSTALL_DIR should now be correctly detected using FindKDE4.cmake
> > from cmake cvs, so I removed this from the two files. Unfortunately the
> > settings fro Qt in the toolchain file are broken by that, can you please
> > fix this by making the Qt variables relative to some Qt base directory
> > instead relative to KDE4_INSTALL_DIR ?
>
> I changed the name to KDE_PREFIX but it should be setted by the user,
> also KDE4_DATA_DIR is needed otherwise it doesn't find the cmake
> modules

You should only need something like QT4_PREFIX, all the stuff for KDE should 
now be found correctly.

This should work now with current kdelibs and current cmake.
FindKDE4.cmake should now only find kde4-config from the target, not from the 
build host, and then simply reuse its location instead of querying it for the 
path.

Please try that again with a fresh buildtree, it should really work now.
If it doesn't, please post the detailed problems.

Alex

From michael.a.oshea at gmail.com  Wed Mar 19 08:29:37 2008
From: michael.a.oshea at gmail.com (Michael O'Shea)
Date: Wed, 19 Mar 2008 08:29:37 +0100
Subject: update - kdelibs doesn't build
Message-ID: <d323dcfd0803190029y6749a48i4738f5c2ade5e96e@mail.gmail.com>

I've rebuilt debug versions of both Qt and kdelibs (emerge --buildtype=Debug
--update qt then emerge --buildtype=Debug kdelibs) but makekdewidgets still
fails the same way.

The output obtained (as seen in MSVC) follows further down. The most notable
changes are :
1) all the KDE/Qt stuff has symbols
2) the apparition of => LDR: LdrpWalkImportDescriptor() failed to probe
D:\stuff\KDE4_win32\root\bin\dbus-1d.dll for its manifest, ntstatus
0xc0150002

I checked the build date of D:\stuff\KDE4_win32\root\bin\dbus-1d.dll and
found that it had not been built by my two emerge commands mentioned higher
up.

Questions :
1) how does dbus-1d.dll get built ? Saro made me do a emerge kdewin32lib
last week. Did that do it ?
2) will doing kdewin32lib fix the problem ? I could try doing that but I've
been blindly trying all sorts of things in a trial-and-error manner for the
last month and would rather not (each trial-and-error step taking hours of
build time before failing)
3) is there some problem with dbus-1d.dll on my machine ?

The output of MSVC for makekdewidgets.exe:

'makekdewidgets.exe': Loaded
'D:\stuff\KDE4_win32\root\tmp\kdelibs-20080202\work\msvc2005-Debug\bin\makekdewidgets.exe',
Symbols loaded.
'makekdewidgets.exe': Loaded 'C:\WINDOWS\system32\ntdll.dll', No symbols
loaded.
'makekdewidgets.exe': Loaded 'C:\WINDOWS\system32\kernel32.dll', No symbols
loaded.
'makekdewidgets.exe': Loaded 'D:\stuff\KDE4_win32\root\lib\QtCored4.dll',
Symbols loaded.
'makekdewidgets.exe': Loaded 'C:\WINDOWS\system32\user32.dll', No symbols
loaded.
'makekdewidgets.exe': Loaded 'C:\WINDOWS\system32\gdi32.dll', No symbols
loaded.
'makekdewidgets.exe': Loaded 'C:\WINDOWS\system32\ole32.dll', No symbols
loaded.
'makekdewidgets.exe': Loaded 'C:\WINDOWS\system32\advapi32.dll', No symbols
loaded.
'makekdewidgets.exe': Loaded 'C:\WINDOWS\system32\rpcrt4.dll', No symbols
loaded.
'makekdewidgets.exe': Loaded 'C:\WINDOWS\system32\msvcrt.dll', No symbols
loaded.
'makekdewidgets.exe': Loaded 'C:\WINDOWS\system32\ws2_32.dll', No symbols
loaded.
'makekdewidgets.exe': Loaded 'C:\WINDOWS\system32\ws2help.dll', No symbols
loaded.
'makekdewidgets.exe': Loaded
'C:\WINDOWS\WinSxS\x86_Microsoft.VC80.DebugCRT_1fc8b3b9a1e18e3b_8.0.50727.42_x-ww_f75eb16c\msvcp80d.dll',
No symbols loaded.
'makekdewidgets.exe': Loaded
'C:\WINDOWS\WinSxS\x86_Microsoft.VC80.DebugCRT_1fc8b3b9a1e18e3b_8.0.50727.42_x-ww_f75eb16c\msvcr80d.dll',
No symbols loaded.
'makekdewidgets.exe': Loaded
'D:\stuff\KDE4_win32\root\tmp\kdelibs-20080202\work\msvc2005-Debug\bin\kdecore.dll',
Symbols loaded.
'makekdewidgets.exe': Loaded 'D:\stuff\KDE4_win32\root\lib\QtNetworkd4.dll',
Symbols loaded.
'makekdewidgets.exe': Loaded 'D:\stuff\KDE4_win32\root\lib\QtDBusd4.dll',
Symbols loaded.
'makekdewidgets.exe': Loaded 'D:\stuff\KDE4_win32\root\bin\dbus-1d.dll', No
symbols loaded.
LDR: LdrpWalkImportDescriptor() failed to probe
D:\stuff\KDE4_win32\root\bin\dbus-1d.dll for its manifest, ntstatus
0xc0150002
'makekdewidgets.exe': Loaded 'C:\WINDOWS\system32\EntAPI.dll', No symbols
loaded.
'makekdewidgets.exe': Loaded 'C:\WINDOWS\system32\psapi.dll', No symbols
loaded.
'makekdewidgets.exe': Loaded 'C:\WINDOWS\system32\netapi32.dll', No symbols
loaded.
'makekdewidgets.exe': Unloaded 'C:\WINDOWS\system32\EntAPI.dll'
'makekdewidgets.exe': Unloaded 'C:\WINDOWS\system32\netapi32.dll'
'makekdewidgets.exe': Unloaded 'C:\WINDOWS\system32\psapi.dll'
Debugger:: An unhandled non-continuable exception was thrown during process
load
The program '[12008] makekdewidgets.exe: Native' has exited with code
-1072365566 (0xc0150002).

Thanks for having a look.

Cheers,

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kde-windows/attachments/20080319/03b46909/attachment.html 

From Ch.Ehrlicher at gmx.de  Wed Mar 19 08:33:20 2008
From: Ch.Ehrlicher at gmx.de (Christian Ehrlicher)
Date: Wed, 19 Mar 2008 08:33:20 +0100
Subject: update - kdelibs doesn't build
In-Reply-To: <d323dcfd0803190029y6749a48i4738f5c2ade5e96e@mail.gmail.com>
References: <d323dcfd0803190029y6749a48i4738f5c2ade5e96e@mail.gmail.com>
Message-ID: <20080319073320.39770@gmx.net>

> Von: "Michael O\'Shea"
> I've rebuilt debug versions of both Qt and kdelibs (emerge
> --buildtype=Debug
> --update qt then emerge --buildtype=Debug kdelibs) but makekdewidgets
> still
> fails the same way.
> 
> The output obtained (as seen in MSVC) follows further down. The most
> notable
> changes are :
> 1) all the KDE/Qt stuff has symbols
> 2) the apparition of => LDR: LdrpWalkImportDescriptor() failed to probe
> D:\stuff\KDE4_win32\root\bin\dbus-1d.dll for its manifest, ntstatus
> 0xc0150002
> 
You're probably using a wrong msvc version. You have to use msvc2005 sp1.


Christian
-- 
Psssst! Schon vom neuen GMX MultiMessenger geh?rt?
Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger

From michael.a.oshea at gmail.com  Wed Mar 19 22:10:39 2008
From: michael.a.oshea at gmail.com (Michael O'Shea)
Date: Wed, 19 Mar 2008 22:10:39 +0100
Subject: kdelibs builds OK now !!!
Message-ID: <d323dcfd0803191410l417b8cdch3c98557e83464a3b@mail.gmail.com>

Christian,

thanks for the tip. Installing SP1 for MSVC 2005 solved my problem.

Cheers,

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kde-windows/attachments/20080319/e28b031e/attachment.html 

From ralf.habacker at freenet.de  Fri Mar 21 12:23:59 2008
From: ralf.habacker at freenet.de (Ralf Habacker)
Date: Fri, 21 Mar 2008 12:23:59 +0100
Subject: KDE windows Localized build
In-Reply-To: <47DE31BD.7030609@iidea.pl>
References: <47DD057B.4070808@gmail.com> <47DE31BD.7030609@iidea.pl>
Message-ID: <47E39ACF.4010202@freenet.de>

Jaros?aw Staniek schrieb:
> Ravishankar Shrivastava said the following, On 2008-03-16 12:33:
>   
>> Hi,
>> I am new to this list so please forgive me for my ignorance. Can some 
>> one point to the links / resources / docs for installing KDE in Windows 
>> in languages other than Default English? For example, I want to install 
>> and run KDE in Hindi language environment, what should I do?
>>     
>
> In addition to what Christian and Ralf said: KDE apps/libs can now load proper 
> translation data from .mo files located in KDEROOT/share/locale/ by default 
> looking at your system settings, unless you have your Lanuguage
>
>   
There are a most complete set of language packages available for example 
on http://ftp.gtlib.cc.gatech.edu/pub/kde/unstable/4.0.66/win32/ or the 
sourceforge server 
http://sourceforge.net/project/showfiles.php?group_id=214730.

Also support for making language packages was added to the emerge build 
system by first updating emerge from svn and running

emerge --update l10n-kde4

Please note that this command will need a long time. To limit the number 
of languages for the build edit the file 
<svnroot>/trunk/l10n-kde4/subdirs. This is usefull for debugging or 
creating single language packages

To check intermediate build steps there is a specific preconfigure mode

emerge --preconfigure l10n-kde4 -> creates CMakeLists.txt for selected 
language

other supported modes are:

emerge --configure l10n-kde4 -> configure selected language
emerge --make l10n-kde4 -> make selected languages
emerge --install l10n-kde4 -> install selected languages
emerge --qmerge l10n-kde4 -> merge selected languages into live system
emerge --package l10n-kde4 -> create language packages

I have tested only msvc builds.

Ralf





From marktaff at comcast.net  Mon Mar 24 05:06:31 2008
From: marktaff at comcast.net (Mark A. Taff)
Date: Sun, 23 Mar 2008 21:06:31 -0700
Subject: Application icons in Explorer
Message-ID: <200803232106.32058.marktaff@comcast.net>

Hi everyone.

I just wanted to give you guys a heads up that I intend to install a 
development environment for KDE-Windows, and to fix all (or at least some) 
the missing application icons as noted by Christian [1].

I currently have the binary environment for an initial test drive, but I will 
swap that out for svn (I have a kde svn account).

If there is any reason for me *not* to fix the CMakeLists.txt as noted, please 
let me know. :-)

Thanks,

Mark

[1] http://mail.kde.org/pipermail/kde-windows/2008-February/002134.html

From marktaff at comcast.net  Mon Mar 24 13:44:01 2008
From: marktaff at comcast.net (Mark A. Taff)
Date: Mon, 24 Mar 2008 05:44:01 -0700
Subject: svn+puTTY:// tunnel for write access to KDE Subversion repository
Message-ID: <200803240544.01965.marktaff@comcast.net>

FYI,

I added a howto[1] on techbase for developers to create an puTTY tunnel so 
they can use their existing OpenSSH private keys to connect to the KDE svn 
repository.

I also linked to it from the emerge page.

Regards,

Mark

[1]http://techbase.kde.org/index.php?title=Getting_Started/Build/KDE4/Windows/subversion

From themaestroofemail at gmail.com  Tue Mar 25 00:09:15 2008
From: themaestroofemail at gmail.com (Lavacano Volblaster)
Date: Mon, 24 Mar 2008 16:09:15 -0700
Subject: I apologize ... (WAS: Emerge mingw fails...)
In-Reply-To: <13413b8f0803170150t50128e72i1a9f555daf9a7b14@mail.gmail.com>
References: <13413b8f0803170150t50128e72i1a9f555daf9a7b14@mail.gmail.com>
Message-ID: <47E8349B.4040208@gmail.com>

Could be something goofy on your end (or could be Thunderbird being 
nice), but I only received one copy of that e-mail.

Gueven Bay wrote:
> I see on http://lists.kde.org/?l=kde-windows&r=1&b=200803&w=2 that my
> last mail to this list
> is received three times, but I am sure that I sent it only one time -
> because there was no problem on my side where I had to try to send it
> more than one time -.
>
> But anyway, I want to apologize if it seems to someone out there that
> I want to spam this list.
> This is definitive not the case.
> I just wanted to report of an error case.
> _______________________________________________
> Kde-windows mailing list
> Kde-windows at kde.org
> https://mail.kde.org/mailman/listinfo/kde-windows
>
>   

-- 
Proposed Additions to the PDP-11 Instruction Set:

PI      Punch Invalid
POPI    Punch Operator Immediately
PVLC    Punch Variable Length Card
RASC    Read And Shred Card
RPM     Read Programmers Mind
RSSC    reduce speed, step carefully  (for improved accuracy)
RTAB    Rewind tape and break
RWDSK   rewind disk
RWOC    Read Writing On Card
SCRBL   scribble to disk  - faster than a write
SLC     Search for Lost Chord
SPSW    Scramble Program Status Word
SRSD    Seek Record and Scar Disk
STROM   Store in Read Only Memory
TDB     Transfer and Drop Bit
WBT     Water Binary Tree


From themaestroofemail at gmail.com  Tue Mar 25 00:10:47 2008
From: themaestroofemail at gmail.com (Lavacano Volblaster)
Date: Mon, 24 Mar 2008 16:10:47 -0700
Subject: Emerge mingw fails...
In-Reply-To: <13413b8f0803170924o75984943i41b25e3d5e5676c6@mail.gmail.com>
References: <13413b8f0803170924o75984943i41b25e3d5e5676c6@mail.gmail.com>
Message-ID: <47E834F7.3010802@gmail.com>

Wait, you can emerge MinGW?

Gueven Bay wrote:
> I have now updated emerge to the revision 786660.
>
> Still the command "emerge mingw" fails.
> For any chance that the failure is on my side I looked again at the
> emerge howto on the Techbase and controlled checkout and settings and
> commands. I also searched for the error message but got only links to
> discussions with other Python modules not emerge on Windows.
>
> I hope that someone can give me a tip how to continue. And/or that
> someone can explain me the cause of the error.
>
>
> The error message:
>
> H:\kderoot>emerge mingw
>
> H:\kderoot>echo emerge.bat executed
> emerge.bat executed
>
> H:\kderoot>python H:\kderoot\emerge\bin\emerge.py mingw
> buildAction: all
> doPretend: False
> packageName: mingw
> buildType: RelWithDebInfo
> buildTests: None
> verbose: 1
> KDEROOT: H:\kderoot
> emerge warning: installed db file does not exist
> setdir category: gnuwin32, package: wget, version: 1.10.1
> cmakeInstallPrefix: H:/kderoot
> setdir category: gnuwin32, package: wget, version: 1.10.1
> cmakeInstallPrefix: H:/kderoot
> Traceback (most recent call last):
>   File "H:\kderoot\emerge\portage\gnuwin32\wget\wget-1.10.1.py", line 20, in <mo
> dule>
>     subclass().execute()
>   File "H:\kderoot\emerge\bin\base.py", line 154, in execute
>     elif command == "unpack":      ok = self.unpack()
>   File "H:\kderoot\emerge\bin\base.py", line 193, in unpack
>     return utils.unpackFiles( self.downloaddir, self.filenames, self.workdir )
> AttributeError: subclass instance has no attribute 'filenames'
> emerge fatal error: running python H:\kderoot\emerge\portage\gnuwin32\wget\wget-
> 1.10.1.py unpack
> emerge error: fatal error: package gnuwin32/wget-1.10.1 all failed
> emerge warning: installed db file does not exist
> setdir category: gnuwin32, package: patch, version: 2.5.9-7
> cmakeInstallPrefix: H:/kderoot
> setdir category: gnuwin32, package: patch, version: 2.5.9-7
> cmakeInstallPrefix: H:/kderoot
> Traceback (most recent call last):
>   File "H:\kderoot\emerge\portage\gnuwin32\patch\patch-2.5.9-7.py", line 22, in
> <module>
>     subclass().execute()
>   File "H:\kderoot\emerge\bin\base.py", line 154, in execute
>     elif command == "unpack":      ok = self.unpack()
>   File "H:\kderoot\emerge\bin\base.py", line 193, in unpack
>     return utils.unpackFiles( self.downloaddir, self.filenames, self.workdir )
> AttributeError: subclass instance has no attribute 'filenames'
> emerge fatal error: running python H:\kderoot\emerge\portage\gnuwin32\patch\patc
> h-2.5.9-7.py unpack
> emerge error: fatal error: package gnuwin32/patch-2.5.9-7 all failed
> emerge warning: installed db file does not exist
> setdir category: dev-util, package: mingw, version: 3.4.5
> cmakeInstallPrefix: H:/kderoot
> setdir category: dev-util, package: mingw, version: 3.4.5
> cmakeInstallPrefix: H:/kderoot
> Traceback (most recent call last):
>   File "H:\kderoot\emerge\portage\dev-util\mingw\mingw-3.4.5.py", line 62, in <m
> odule>
>     subclass().execute()
>   File "H:\kderoot\emerge\bin\base.py", line 154, in execute
>     elif command == "unpack":      ok = self.unpack()
>   File "H:\kderoot\emerge\portage\dev-util\mingw\mingw-3.4.5.py", line 45, in un
> pack
>     base.baseclass.unpack( self )
>   File "H:\kderoot\emerge\bin\base.py", line 193, in unpack
>     return utils.unpackFiles( self.downloaddir, self.filenames, self.workdir )
> AttributeError: subclass instance has no attribute 'filenames'
> emerge fatal error: running python H:\kderoot\emerge\portage\dev-util\mingw\ming
> w-3.4.5.py unpack
> emerge error: fatal error: package dev-util/mingw-3.4.5 all failed
> _______________________________________________
> Kde-windows mailing list
> Kde-windows at kde.org
> https://mail.kde.org/mailman/listinfo/kde-windows
>
>   
-- 
Proposed Additions to the PDP-11 Instruction Set:

PI      Punch Invalid
POPI    Punch Operator Immediately
PVLC    Punch Variable Length Card
RASC    Read And Shred Card
RPM     Read Programmers Mind
RSSC    reduce speed, step carefully  (for improved accuracy)
RTAB    Rewind tape and break
RWDSK   rewind disk
RWOC    Read Writing On Card
SCRBL   scribble to disk  - faster than a write
SLC     Search for Lost Chord
SPSW    Scramble Program Status Word
SRSD    Seek Record and Scar Disk
STROM   Store in Read Only Memory
TDB     Transfer and Drop Bit
WBT     Water Binary Tree


From gueven.bay at googlemail.com  Tue Mar 25 06:40:12 2008
From: gueven.bay at googlemail.com (Gueven Bay)
Date: Tue, 25 Mar 2008 06:40:12 +0100
Subject: Emerge mingw fails...
In-Reply-To: <47E834F7.3010802@gmail.com>
References: <13413b8f0803170924o75984943i41b25e3d5e5676c6@mail.gmail.com>
	<47E834F7.3010802@gmail.com>
Message-ID: <13413b8f0803242240u55b06009ledd8876f96d66391@mail.gmail.com>

2008/3/25, Lavacano Volblaster <themaestroofemail at gmail.com>:
> Wait, you can emerge MinGW?
>

Yes, two days after reporting the "Mingw fails..." (my last post)
error I updated
the emerge directory and then I was able to emerge mingw, then qt,
then kdelibs, then kdepimlibs. [2]

But then I wanted to emerge kdebase : You guessed it, it fails
with a similar error as mingw failed for me.

Before I answered your posting I tried again to update emerge
(I have now "Updated to revision 789753" )
and emerge kdebase.

But it failed again. [1]

It is somewhat frustrating because in all the weeks that I try to
install KDE per emerge it never did run through :-(
But the most frustrating thing is that noone even tried to give me
an explanation why this error occurs and there is no document that
explains it.


*sigh*



[1]
H:\kderoot>emerge kdebase
H:\kderoot>echo emerge.bat executed
emerge.bat executed
H:\kderoot>python H:\kderoot\emerge\bin\emerge.py kdebase
buildAction: all
doPretend: False
packageName: kdebase
buildType: RelWithDebInfo
buildTests: None
verbose: 1
KDEROOT: H:\kderoot
setdir category: kde, package: kdebase, version: 20080202
cmakeInstallPrefix: H:/kderoot
setdir category: kde, package: kdebase, version: 20080202
cmakeInstallPrefix: H:/kderoot
Traceback (most recent call last):
  File "H:\kderoot\emerge\portage\kde\kdebase\kdebase-20080202.py", line 16, in
<module>
    subclass().execute()
  File "H:\kderoot\emerge\bin\base.py", line 174, in execute
    elif command == "unpack":       ok = self.unpack()
  File "H:\kderoot\emerge\bin\base.py", line 206, in unpack
    return utils.unpackFiles( self.downloaddir, self.filenames, self.workdir )
AttributeError: subclass instance has no attribute 'filenames'
emerge fatal error: running python H:\kderoot\emerge\portage\kde\kdebase\kdebase
-20080202.py unpack
emerge error: fatal error: package kde/kdebase-20080202 all failed


[2]
Category Package Version
-------- ------- -------
contributed gpgme-qt 20080115
dev-util cmake 2.4.8
dev-util mingw 3.4.5
dev-util perl 5.8.8.822
dev-util subversion 1.4.6.20080222
dev-util win32libs 20080129
gnuwin32 patch 2.5.9-7
gnuwin32 sed 4.1.4
gnuwin32 wget 1.10.1
kde kdebase-apps 20080202
kde kdebase-runtime 20080202
kde kdelibs 20080202
kde kdepimlibs 20080202
kdesupport clucene-core 0.9.16.1.20070930
kdesupport kdewin32      0.3.6.20080303
kdesupport qimageblitz   4.0.0.20071030
kdesupport  soprano       2.00.0.20080107
kdesupport  strigi            0.5.8.20080220
libs qt  4.4.0.20080222
virtual  base  0.2

From Ch.Ehrlicher at gmx.de  Tue Mar 25 06:58:32 2008
From: Ch.Ehrlicher at gmx.de (Christian Ehrlicher)
Date: Tue, 25 Mar 2008 06:58:32 +0100
Subject: Emerge mingw fails...
In-Reply-To: <13413b8f0803242240u55b06009ledd8876f96d66391@mail.gmail.com>
References: <13413b8f0803170924o75984943i41b25e3d5e5676c6@mail.gmail.com>	<47E834F7.3010802@gmail.com>
	<13413b8f0803242240u55b06009ledd8876f96d66391@mail.gmail.com>
Message-ID: <47E89488.8040709@gmx.de>

Gueven Bay schrieb:
> 2008/3/25, Lavacano Volblaster <themaestroofemail at gmail.com>:
>> Wait, you can emerge MinGW?
>>
> 
> Yes, two days after reporting the "Mingw fails..." (my last post)
> error I updated
> the emerge directory and then I was able to emerge mingw, then qt,
> then kdelibs, then kdepimlibs. [2]
> 
> But then I wanted to emerge kdebase : You guessed it, it fails
> with a similar error as mingw failed for me.
> 
> Before I answered your posting I tried again to update emerge
> (I have now "Updated to revision 789753" )
> and emerge kdebase.
> 
kdebase is outdated - it's just there for... don't know. I'll remove it 
today.


Christian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 258 bytes
Desc: OpenPGP digital signature
Url : http://mail.kde.org/pipermail/kde-windows/attachments/20080325/e3e07d5e/attachment.pgp 

From kde-dev at emailgoeshere.com  Tue Mar 25 15:32:58 2008
From: kde-dev at emailgoeshere.com (Jeff Mitchell)
Date: Tue, 25 Mar 2008 10:32:58 -0400
Subject: Downloads fail from sourceforge
Message-ID: <47E90D1A.2020608@emailgoeshere.com>

All downloads from gnuwin32 at sourceforge seem to be failing.  Not sure 
why.  Going to the link through Firefox, it downloads just fine.

Using the URI in the ebuilds, the downloaded file is the text of a 302 
message informing that there is a new URL (replace downloads.sf.net with 
downloads.sourceforge.net).  If I change the ebuild to point to that 
URI, the downloaded file is zero length.

I've seen this is happening for other users too (in #kde-windows).

--Jeff

From kde-dev at emailgoeshere.com  Tue Mar 25 21:28:06 2008
From: kde-dev at emailgoeshere.com (Jeff Mitchell)
Date: Tue, 25 Mar 2008 16:28:06 -0400
Subject: kdesupport/emerge/portage/gnuwin32
In-Reply-To: <1206465714.129405.27340.nullmailer@svn.kde.org>
References: <1206465714.129405.27340.nullmailer@svn.kde.org>
Message-ID: <47E96056.9000700@emailgoeshere.com>

It's a good first step, but as I said in my email to kde-windows, it 
doesn't fix the problem.  Instead of downloading 302 error messages, it 
now downloads zero-byte files.

I tried wiresharking it but apparently my wireless adapter doesn't 
support promiscuous mode.  Wireshark on another (linux) box with Firefox 
seemed to return appropriate headers (content-length for instance) and 
the zip file was valid.

--Jeff

Christian Ehrlicher wrote:
> SVN commit 789922 by chehrlic:
>
> sf.net -> sourceforge.net
>
>  M  +2 -2      diffutils/diffutils-2.8.7-1.py  
>  M  +2 -2      grep/grep-2.5.1a.py  
>  M  +2 -2      less/less-394.py  
>  M  +2 -2      openssl/openssl-0.9.7c.py  
>  D             sed/sed-4.1.4.py  
>  A             sed/sed-4.1.5.py   sed/sed-4.1.4.py#789759
>  M  +2 -2      wget/wget-1.10.1.py  
>
>
> --- trunk/kdesupport/emerge/portage/gnuwin32/diffutils/diffutils-2.8.7-1.py #789921:789922
> @@ -2,8 +2,8 @@
>  import info
>  
>  SRC_URI = """
> -http://downloads.sf.net/sourceforge/gnuwin32/diffutils-2.8.7-1-bin.zip
> -http://downloads.sf.net/sourceforge/gnuwin32/diffutils-2.8.7-1-dep.zip
> +http://downloads.sourceforge.net/sourceforge/gnuwin32/diffutils-2.8.7-1-bin.zip
> +http://downloads.sourceforge.net/sourceforge/gnuwin32/diffutils-2.8.7-1-dep.zip
>  """
>  
>  class subinfo(info.infoclass):
> --- trunk/kdesupport/emerge/portage/gnuwin32/grep/grep-2.5.1a.py #789921:789922
> @@ -2,8 +2,8 @@
>  import info
>  
>  SRC_URI = """
> -http://downloads.sf.net/sourceforge/gnuwin32/grep-2.5.1a-bin.zip
> -http://downloads.sf.net/sourceforge/gnuwin32/grep-2.5.1a-dep.zip
> +http://downloads.sourceforge.net/sourceforge/gnuwin32/grep-2.5.1a-bin.zip
> +http://downloads.sourceforge.net/sourceforge/gnuwin32/grep-2.5.1a-dep.zip
>  """
>  
>  class subinfo(info.infoclass):
> --- trunk/kdesupport/emerge/portage/gnuwin32/less/less-394.py #789921:789922
> @@ -2,8 +2,8 @@
>  import info
>  
>  SRC_URI = """
> -http://downloads.sf.net/sourceforge/gnuwin32/less-394-bin.zip
> -http://downloads.sf.net/sourceforge/gnuwin32/less-394-dep.zip
> +http://downloads.sourceforge.net/sourceforge/gnuwin32/less-394-bin.zip
> +http://downloads.sourceforge.net/sourceforge/gnuwin32/less-394-dep.zip
>  """
>  
>  class subinfo(info.infoclass):
> --- trunk/kdesupport/emerge/portage/gnuwin32/openssl/openssl-0.9.7c.py #789921:789922
> @@ -3,8 +3,8 @@
>  import info
>  
>  SRC_URI = """
> -http://downloads.sf.net/sourceforge/gnuwin32/openssl-0.9.7c-bin.zip
> -http://downloads.sf.net/sourceforge/gnuwin32/openssl-0.9.7c-lib.zip
> +http://downloads.sourceforge.net/sourceforge/gnuwin32/openssl-0.9.7c-bin.zip
> +http://downloads.sourceforge.net/sourceforge/gnuwin32/openssl-0.9.7c-lib.zip
>  """
>  
>  class subinfo(info.infoclass):
> --- trunk/kdesupport/emerge/portage/gnuwin32/wget/wget-1.10.1.py #789921:789922
> @@ -2,8 +2,8 @@
>  import info
>  
>  SRC_URI = """
> -http://downloads.sf.net/sourceforge/gnuwin32/wget-1.10.1-bin.zip
> -http://downloads.sf.net/sourceforge/gnuwin32/wget-1.10.1-dep.zip
> +http://downloads.sourceforge.net/sourceforge/gnuwin32/wget-1.10.1-bin.zip
> +http://downloads.sourceforge.net/sourceforge/gnuwin32/wget-1.10.1-dep.zip
>  """
>  
>  class subinfo(info.infoclass):
>   
   

From ralf.habacker at freenet.de  Tue Mar 25 21:57:05 2008
From: ralf.habacker at freenet.de (Ralf Habacker)
Date: Tue, 25 Mar 2008 21:57:05 +0100
Subject: kdesupport/emerge/portage/gnuwin32
In-Reply-To: <47E96056.9000700@emailgoeshere.com>
References: <1206465714.129405.27340.nullmailer@svn.kde.org>
	<47E96056.9000700@emailgoeshere.com>
Message-ID: <47E96721.4060202@freenet.de>

Jeff Mitchell schrieb:
> It's a good first step, but as I said in my email to kde-windows, it 
> doesn't fix the problem.  Instead of downloading 302 error messages, it 
> now downloads zero-byte files.
>
>   
the address http://downloads.sourceforge.net/sourceforge/gnuwin32/... 
will be redirected to a real mirror. In the last time there are two 
server I recognized which sometimes fails. These are 
garr.dl.sourceforge.net and puzzle.dl.sourceforge.net

I suggest to use http://heanet.dl.sourceforge.net/sourceforge/gnuwin32 or http://kent.dl.sourceforge.net/sourceforge/gnuwin32

May be we can use a generic url in emerge to not have to switch every 
ebuild file.

Ralf

From ralf.habacker at freenet.de  Tue Mar 25 21:58:02 2008
From: ralf.habacker at freenet.de (Ralf Habacker)
Date: Tue, 25 Mar 2008 21:58:02 +0100
Subject: kdesupport/emerge/portage/gnuwin32
In-Reply-To: <47E96721.4060202@freenet.de>
References: <1206465714.129405.27340.nullmailer@svn.kde.org>
	<47E96056.9000700@emailgoeshere.com> <47E96721.4060202@freenet.de>
Message-ID: <47E9675A.1030504@freenet.de>

Ralf Habacker schrieb:
> Jeff Mitchell schrieb:
>> It's a good first step, but as I said in my email to kde-windows, it 
>> doesn't fix the problem.  Instead of downloading 302 error messages, 
>> it now downloads zero-byte files.
>>
>>   
> the address http://downloads.sourceforge.net/sourceforge/gnuwin32/... 
> will be redirected to a real mirror. In the last time there are two 
> server I recognized which sometimes fails. These are 
> garr.dl.sourceforge.net and puzzle.dl.sourceforge.net
>
> I suggest to use http://heanet.dl.sourceforge.net/sourceforge/gnuwin32 
> or http://kent.dl.sourceforge.net/sourceforge/gnuwin32
>
> May be we can use a generic url in emerge to not have to switch every 
> ebuild file.
>
PS: forgot to say: If there are problems with sourceforge mirror i 
suggest to open a sourceforge bug request.
> Ralf
>


From kde-dev at emailgoeshere.com  Tue Mar 25 22:05:55 2008
From: kde-dev at emailgoeshere.com (Jeff Mitchell)
Date: Tue, 25 Mar 2008 17:05:55 -0400
Subject: kdesupport/emerge/portage/gnuwin32
In-Reply-To: <47E9675A.1030504@freenet.de>
References: <1206465714.129405.27340.nullmailer@svn.kde.org>	<47E96056.9000700@emailgoeshere.com>
	<47E96721.4060202@freenet.de> <47E9675A.1030504@freenet.de>
Message-ID: <47E96933.1020500@emailgoeshere.com>

Ralf Habacker wrote:
> Ralf Habacker schrieb:
>> Jeff Mitchell schrieb:
>>> It's a good first step, but as I said in my email to kde-windows, it 
>>> doesn't fix the problem.  Instead of downloading 302 error messages, 
>>> it now downloads zero-byte files.
>>>
>>>   
>> the address http://downloads.sourceforge.net/sourceforge/gnuwin32/... 
>> will be redirected to a real mirror. In the last time there are two 
>> server I recognized which sometimes fails. These are 
>> garr.dl.sourceforge.net and puzzle.dl.sourceforge.net
>>
>> I suggest to use 
>> http://heanet.dl.sourceforge.net/sourceforge/gnuwin32 or 
>> http://kent.dl.sourceforge.net/sourceforge/gnuwin32
>>
>> May be we can use a generic url in emerge to not have to switch every 
>> ebuild file.
Good idea.  Perhaps we can have it be set to the environment in 
kdesettings.bat so the user can choose a mirror near them (or default to 
kent).

--Jeff

From marktaff at comcast.net  Tue Mar 25 22:51:28 2008
From: marktaff at comcast.net (Mark A. Taff)
Date: Tue, 25 Mar 2008 14:51:28 -0700
Subject: kdesupport/emerge/portage/gnuwin32
In-Reply-To: <47E9675A.1030504@freenet.de>
References: <1206465714.129405.27340.nullmailer@svn.kde.org>
	<47E96721.4060202@freenet.de> <47E9675A.1030504@freenet.de>
Message-ID: <200803251451.29087.marktaff@comcast.net>

On Tuesday 25 March 2008 13:58:02 Ralf Habacker wrote:
> PS: forgot to say: If there are problems with sourceforge mirror i
> suggest to open a sourceforge bug request.

I'm not sure it is sourceforge's fault.  It seems like the emerge python 
script is either giving up too soon, or otherwise not following the 
redirects.  If Konqi & Firefox can get the files OK using the regular URL, 
why can't the emerge python script?

Also, the script accepts 326 bytes as a valid size for wget.  It didn't fail 
until it tried to unzip the file and choked.  Perhaps it should be 
downloading md5 sums and checking them?  Or some other method of reality 
checks?

Regards,

--Mark


From js at iidea.pl  Wed Mar 26 10:51:05 2008
From: js at iidea.pl (Jaroslaw Staniek)
Date: Wed, 26 Mar 2008 09:51:05 +0000
Subject: KDE/kdepim
Message-ID: <1206525065.433998.11586.nullmailer@svn.kde.org>

SVN commit 790258 by staniek:

Set icons for executables under Windows and Mac.

Now our apps look like this:
 http://kexi-project.org/pics/kde/kdepim/2008-03/kde-pim-icons.png

CCMAIL:kde-pim at kde.org
CCMAIL:kde-windows at kde.org



 M  +2 -0      CMakeLists.txt  
 M  +5 -1      akonadi/agents/nepomuk_email_feeder/CMakeLists.txt  
 M  +2 -0      akonadi/clients/akonamail/CMakeLists.txt  
 M  +5 -0      akonadi/clients/kabc/CMakeLists.txt  
 M  +4 -0      akonadi/kabc/kcontactmanager/CMakeLists.txt  
 M  +1 -0      akregator/src/CMakeLists.txt  
 M  +3 -0      console/kabcclient/src/CMakeLists.txt  
 M  +2 -0      console/konsolekalendar/CMakeLists.txt  
 M  +2 -0      kaddressbook/CMakeLists.txt  
 M  +3 -0      kitchensync/src/CMakeLists.txt  
 M  +5 -1      kleopatra/CMakeLists.txt  
 M  +7 -1      kleopatra/kgpgconf/CMakeLists.txt  
 M  +2 -0      kmail/CMakeLists.txt  
 M  +1 -0      kmailcvt/CMakeLists.txt  
 M  +2 -0      kmobiletools/kmobiletools/CMakeLists.txt  
 M  +3 -0      knode/CMakeLists.txt  
 M  +1 -0      knotes/CMakeLists.txt  
 M  +1 -0      kontact/src/CMakeLists.txt  
 M  +2 -0      korganizer/CMakeLists.txt  
 M  +2 -0      korganizer/korgac/CMakeLists.txt  
 M  +3 -0      korn/CMakeLists.txt  
 M  +6 -0      kpilot/kpilot/CMakeLists.txt  
 M  +2 -0      kresources/groupwise/soap/CMakeLists.txt  
 M  +3 -0      kresources/scalix/scalixadmin/CMakeLists.txt  
 M  +4 -0      ktimetracker/CMakeLists.txt  
 M  +3 -0      ktnef/CMakeLists.txt  
 M  +14 -0     libkdepim/kmeditor.cpp  
 M  +3 -0      libkdepim/kmeditor.h  
 M  +16 -0     wizards/CMakeLists.txt  


--- trunk/KDE/kdepim/CMakeLists.txt #790257:790258
@@ -20,6 +20,8 @@
                         ARCHIVE DESTINATION ${LIB_INSTALL_DIR} )
 endif(WIN32)
 
+set(KDE4_ICON_DIR ${KDE4_INSTALL_DIR}/share/icons)
+
 # this macro exists to work around a stupid Mac OS X linker bug
 # where it can't handle the same library being referenced multiple
 # times on the linker line
--- trunk/KDE/kdepim/akonadi/agents/nepomuk_email_feeder/CMakeLists.txt #790257:790258
@@ -5,8 +5,12 @@
 
 set( CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${KDE4_ENABLE_EXCEPTIONS}" )
 
-kde4_add_executable(akonadi_nepomuk_email_feeder RUN_UNINSTALLED nepomukemailfeeder.cpp)
+set(akonadi_nepomuk_email_feeder_SRCS nepomukemailfeeder.cpp)
 
+kde4_add_app_icon(akonadi_nepomuk_email_feeder_SRCS "${KDE4_ICON_DIR}/oxygen/*/apps/nepomuk.png")
+
+kde4_add_executable(akonadi_nepomuk_email_feeder RUN_UNINSTALLED ${akonadi_nepomuk_email_feeder_SRCS})
+
 target_link_libraries(akonadi_nepomuk_email_feeder
   ${AKONADI_LIBS}
   ${QT_QTCORE_LIBRARY}
--- trunk/KDE/kdepim/akonadi/clients/akonamail/CMakeLists.txt #790257:790258
@@ -11,6 +11,8 @@
   ../../server/interfaces/org.kde.Akonadi.TracerNotification.xml
 )
 
+kde4_add_app_icon(akonamail_bin_SRCS "${KDE4_ICON_DIR}/oxygen/*/apps/email.png")
+
 kde4_add_executable(akonamail_bin ${akonamail_bin_SRCS})
 set_target_properties(akonamail_bin PROPERTIES OUTPUT_NAME akonamail)
 
--- trunk/KDE/kdepim/akonadi/clients/kabc/CMakeLists.txt #790257:790258
@@ -6,6 +6,9 @@
 )
 
 
+# todo: more appropriate icon?
+kde4_add_app_icon(kabcviewer_bin_SRCS "${KDE4_ICON_DIR}/oxygen/*/apps/office-address-book.png")
+
 kde4_add_executable(kabcviewer_bin ${kabcviewer_bin_SRCS})
 set_target_properties(kabcviewer_bin PROPERTIES OUTPUT_NAME kabcviewer)
 
@@ -19,6 +22,8 @@
   kabceditor.cpp
 )
 
+# todo: more appropriate icon?
+kde4_add_app_icon(kabceditor_bin_SRCS "${KDE4_ICON_DIR}/oxygen/*/apps/office-address-book.png")
 
 kde4_add_executable(kabceditor_bin ${kabceditor_bin_SRCS})
 set_target_properties(kabceditor_bin PROPERTIES OUTPUT_NAME kabceditor)
--- trunk/KDE/kdepim/akonadi/kabc/kcontactmanager/CMakeLists.txt #790257:790258
@@ -17,6 +17,10 @@
   mainwindow.cpp
 )
 
+
+# todo: more appropriate icon?
+kde4_add_app_icon(kcontactmanager_SRCS "${KDE4_ICON_DIR}/oxygen/*/actions/view-pim-contacts.png")
+
 kde4_add_executable(kcontactmanager RUN_UNINSTALLED ${kcontactmanager_SRCS})
 
 target_link_libraries(kcontactmanager ${AKONADI_LIBS} akonadi-kabc ${KDE4_KDEUI_LIBRARY} )
--- trunk/KDE/kdepim/akregator/src/CMakeLists.txt #790257:790258
@@ -15,6 +15,7 @@
 
 set(akregator_SRCS main.cpp mainwindow.cpp )
 
+kde4_add_app_icon(akregator_SRCS "${KDE4_ICON_DIR}/oxygen/*/apps/akregator.png")
 
 kde4_add_executable(akregator ${akregator_SRCS})
 
--- trunk/KDE/kdepim/console/kabcclient/src/CMakeLists.txt #790257:790258
@@ -17,6 +17,9 @@
     outputformatimpls.cpp)
 
 
+# todo: more appropriate icon?
+kde4_add_app_icon(kabcclient_SRCS "${KDE4_ICON_DIR}/oxygen/*/apps/office-address-book.png")
+
 kde4_add_executable(kabcclient NOGUI ${kabcclient_SRCS})
 
 target_link_libraries(kabcclient ${KDE4_KABC_LIBS} ${KDE4_KDEUI_LIBS} )
--- trunk/KDE/kdepim/console/konsolekalendar/CMakeLists.txt #790257:790258
@@ -20,6 +20,8 @@
    main.cpp )
 
 
+kde4_add_app_icon(konsolekalendar_SRCS "${KDE4_ICON_DIR}/oxygen/*/apps/office-calendar.png")
+
 kde4_add_executable(konsolekalendar NOGUI ${konsolekalendar_SRCS})
 
 target_link_libraries(konsolekalendar  ${KDE4_KDECORE_LIBS} ${KDE4_KCAL_LIBS} kdepim)
--- trunk/KDE/kdepim/kaddressbook/CMakeLists.txt #790257:790258
@@ -69,6 +69,8 @@
 
 qt4_add_dbus_adaptor(kaddressbook_bin_SRCS org.kde.KAddressbook.Core.xml kaddressbookmain.h KAddressBookMain kaddressbookadaptor )
 
+# todo: move to Oxygen icon
+kde4_add_app_icon(kaddressbook_bin_SRCS "hi*-app-kaddressbook.png")
 kde4_add_executable(kaddressbook_bin ${kaddressbook_bin_SRCS})
 set_target_properties(kaddressbook_bin PROPERTIES OUTPUT_NAME kaddressbook)
 
--- trunk/KDE/kdepim/kitchensync/src/CMakeLists.txt #790257:790258
@@ -12,6 +12,9 @@
 )
 
 
+# todo: move to Oxygen icon
+kde4_add_app_icon(kitchensync_SRCS "pics/hi*-app-kitchensync.png")
+
 KDE4_ADD_EXECUTABLE(kitchensync ${kitchensync_SRCS})
 
 TARGET_LINK_LIBRARIES(kitchensync kitchensyncprivate ${QT_QTGUI_LIBRARY} ${KDE_KDEUI_LIBRARY} )
--- trunk/KDE/kdepim/kleopatra/CMakeLists.txt #790257:790258
@@ -17,8 +17,10 @@
 if (USABLE_ASSUAN_FOUND)
    include_directories(${ASSUAN_INCLUDES})
 endif(USABLE_ASSUAN_FOUND)
-add_definitions ( -DQT_STL -DQT3_SUPPORT -DQT3_SUPPORT_WARNINGS ${KDE4_ENABLE_EXCEPTIONS} -D_ASSUAN_ONLY_GPG_ERRORS -UQT_NO_STL )
+add_definitions ( -DQT_STL -DQT3_SUPPORT -DQT3_SUPPORT_WARNINGS -D_ASSUAN_ONLY_GPG_ERRORS -UQT_NO_STL )
 
+set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${KDE4_ENABLE_EXCEPTIONS}")
+
 add_subdirectory( pics )
 add_subdirectory( conf )
 add_subdirectory( kgpgconf )
@@ -178,6 +180,8 @@
 
 add_definitions ( -DKDE_DEFAULT_DEBUG_AREA=5151 )
 
+
+kde4_add_app_icon(_kleopatra_mainwindow_SRCS "ox*-app-kleopatra.png")
 kde4_add_executable(kleopatra_bin ${_kleopatra_common_SRCS} ${_kleopatra_mainwindow_SRCS} ${_kleopatra_uiserver_SRCS} )
 set_target_properties(kleopatra_bin  PROPERTIES OUTPUT_NAME kleopatra)
 
--- trunk/KDE/kdepim/kleopatra/kgpgconf/CMakeLists.txt #790257:790258
@@ -1,8 +1,10 @@
 project(kgpgconf)
 
 include_directories( ${CMAKE_SOURCE_DIR}/libkleo/backends/qgpgme )
-add_definitions ( ${KDE4_ENABLE_EXCEPTIONS} -D_ASSUAN_ONLY_GPG_ERRORS -UQT_NO_STL -DKDE_DEFAULT_DEBUG_AREA=5154 )
+add_definitions ( -D_ASSUAN_ONLY_GPG_ERRORS -UQT_NO_STL -DKDE_DEFAULT_DEBUG_AREA=5154 )
 
+set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${KDE4_ENABLE_EXCEPTIONS}")
+
 set(_kgpgconf_SRCS
     configreader.cpp
     configwriter.cpp
@@ -14,6 +16,10 @@
 
 kde4_add_ui_files( _kgpgconf_SRCS mainwidget.ui )
 
+
+# todo: more appropriate icon?
+kde4_add_app_icon(_kgpgconf_SRCS "${KDE4_ICON_DIR}/oxygen/*/apps/preferences-desktop-cryptography.png")
+
 kde4_add_executable(kgpgconf ${_kgpgconf_SRCS} )
 target_link_libraries(kgpgconf ${QGPGME_LIBRARIES} ${KDE4_KDEUI_LIBS} )
 
--- trunk/KDE/kdepim/kmail/CMakeLists.txt #790257:790258
@@ -320,6 +320,8 @@
 
 set(kmail_SRCS main.cpp )
 
+# todo: move to Oxygen icon
+kde4_add_app_icon(kmail_SRCS "hi*-app-kmail.png")
 
 kde4_add_executable(kmail ${kmail_SRCS})
 
--- trunk/KDE/kdepim/kmailcvt/CMakeLists.txt #790257:790258
@@ -31,6 +31,7 @@
 
 kde4_add_ui_files(kmailcvt_SRCS kselfilterpagedlg.ui kimportpagedlg.ui)
 
+kde4_add_app_icon(kmailcvt_SRCS "${KDE4_ICON_DIR}/oxygen/*/apps/kmailcvt.png")
 kde4_add_executable(kmailcvt ${kmailcvt_SRCS})
 add_dependencies(kmailcvt kmail_xml)
 
--- trunk/KDE/kdepim/kmobiletools/kmobiletools/CMakeLists.txt #790257:790258
@@ -20,6 +20,8 @@
 
 set(kmobiletools_SRCS main.cpp kmobiletools.cpp kmobiletools.h )
 
+# todo: move to Oxygen icon
+kde4_add_app_icon(kmobiletools_SRCS "libkmobiletools/icons/hi*-app-kmobiletools.png")
 
 kde4_add_executable(kmobiletools_bin ${kmobiletools_SRCS})
 set_target_properties(kmobiletools_bin PROPERTIES OUTPUT_NAME kmobiletools)
--- trunk/KDE/kdepim/knode/CMakeLists.txt #790257:790258
@@ -119,6 +119,9 @@
 set(knode_SRCS knode.cpp knapplication.cpp main.cpp )
 
 
+# todo: move to Oxygen icon
+kde4_add_app_icon(knode_SRCS "hi*-app-knode2.png")
+
 kde4_add_executable(knode ${knode_SRCS})
 
 kdepim4_link_unique_libraries(knode ${KDE4_KDECORE_LIBS} knodecommon )
--- trunk/KDE/kdepim/knotes/CMakeLists.txt #790257:790258
@@ -24,6 +24,7 @@
 
 kde4_add_kcfg_files(knotes_SRCS ${libknotesconfig_SRCS})
 
+kde4_add_app_icon(knotes_SRCS "${KDE4_ICON_DIR}/oxygen/*/apps/knotes.png")
 
 kde4_add_executable(knotes ${knotes_SRCS})
 
--- trunk/KDE/kdepim/kontact/src/CMakeLists.txt #790257:790258
@@ -27,6 +27,7 @@
 
 set(kontact_bin_SRCS main.cpp )
 
+kde4_add_app_icon(kontact_bin_SRCS "${KDE4_ICON_DIR}/oxygen/*/apps/kontact.png")
 
 kde4_add_executable(kontact_bin ${kontact_bin_SRCS})
 
--- trunk/KDE/kdepim/korganizer/CMakeLists.txt #790257:790258
@@ -31,6 +31,8 @@
    koapp.cpp
 )
 
+# todo: move to Oxygen icon
+kde4_add_app_icon(korganizer_SRCS "hi*-app-korganizer.png")
 
 kde4_add_executable(korganizer ${korganizer_SRCS})
 
--- trunk/KDE/kdepim/korganizer/korgac/CMakeLists.txt #790257:790258
@@ -23,6 +23,8 @@
 qt4_add_dbus_adaptor(korgac_SRCS org.kde.korganizer.KOrgac.xml koalarmclient.h KOAlarmClient )
 
 
+kde4_add_app_icon(korgac_SRCS "${KDE4_ICON_DIR}/oxygen/*/apps/preferences-desktop-notification-bell.png")
+
 kde4_add_executable(korgac ${korgac_SRCS})
 
 target_link_libraries(korgac  ${KDE4_KDEUI_LIBS} ${KDE4_PHONON_LIBS} korganizer_eventviewer)
--- trunk/KDE/kdepim/korn/CMakeLists.txt #790257:790258
@@ -63,6 +63,9 @@
 qt4_add_dbus_adaptor(korn_SRCS org.kde.korn.BoxContainerItem.xml boxcontaineritem.h BoxContainerItem )
 qt4_add_dbus_adaptor(korn_SRCS org.kde.korn.MailDrop.xml dbusdrop.h DBUSDrop )
 
+# todo: move to Oxygen icon
+kde4_add_app_icon(korn_SRCS "hi*-app-korn.png")
+
 kde4_add_executable(korn ${korn_SRCS})
 
 target_link_libraries(korn  ${KDE4_KIO_LIBS} ${KDE4_PHONON_LIBS} ${KDE4_KDE3SUPPORT_LIBRARY} ${QT_QT3SUPPORT_LIBRARY} ${KDE4_KMIME_LIBS})
--- trunk/KDE/kdepim/kpilot/kpilot/CMakeLists.txt #790257:790258
@@ -111,6 +111,9 @@
 	org.kde.kpilot.daemon.xml kpilot_daemon_interface
 )
 
+# todo: move to Oxygen icon
+kde4_add_app_icon(kpilotDaemon_SRCS "icons/hi*-app-kpilotDaemon.png")
+
 kde4_add_executable(kpilotDaemon ${kpilotDaemon_SRCS})
 
 target_link_libraries(kpilotDaemon
@@ -164,6 +167,9 @@
 	org.kde.kpilot.daemon.xml daemon_interface
 )
 
+# todo: move to Oxygen icon
+kde4_add_app_icon(kpilot_bin_SRCS "icons/hi*-app-kpilot.png")
+
 kde4_add_executable(kpilot_bin ${kpilot_bin_SRCS})
 
 target_link_libraries(kpilot_bin 
--- trunk/KDE/kdepim/kresources/groupwise/soap/CMakeLists.txt #790257:790258
@@ -7,6 +7,8 @@
 set(soapdebug_SRCS soapdebug.cpp )
 
 
+# todo: more appropriate icon?
+kde4_add_app_icon(soapdebug_SRCS "${KDE4_ICON_DIR}/oxygen/*/apps/kbugbuster.png")
 
 kde4_add_executable(soapdebug TEST ${soapdebug_SRCS})
 
--- trunk/KDE/kdepim/kresources/scalix/scalixadmin/CMakeLists.txt #790257:790258
@@ -22,6 +22,9 @@
   settings.cpp
 )
 
+# todo: more appropriate icon?
+kde4_add_app_icon(scalixadmin_SRCS "${KDE4_ICON_DIR}/oxygen/*/categories/preferences-system-network.png")
+
 kde4_add_executable(scalixadmin ${scalixadmin_SRCS})
 TARGET_LINK_LIBRARIES(scalixadmin ${KDE4_KDEUI_LIBS} ${KDE4_KIO_LIBS} ${KDE4_KLDAP_LIBS} kdepim )
 set_target_properties(scalixadmin PROPERTIES OUTPUT_NAME scalixadmin)
--- trunk/KDE/kdepim/ktimetracker/CMakeLists.txt #790257:790258
@@ -46,6 +46,10 @@
 
 
 kde4_add_executable(karm karm.cpp)
+
+# todo: move to Oxygen icon
+kde4_add_app_icon(karm_SRCS "hi*-app-ktimetracker.png")
+
 kde4_add_executable(ktimetracker ${karm_SRCS})
 
 
--- trunk/KDE/kdepim/ktnef/CMakeLists.txt #790257:790258
@@ -18,6 +18,9 @@
 
 kde4_add_ui_files(ktnef_bin_SRCS attachpropertydialogbase.ui )
 
+# todo: move to Oxygen icon
+kde4_add_app_icon(ktnef_bin_SRCS "pics/hi*-app-ktnef.png")
+
 kde4_add_executable(ktnef_bin ${ktnef_bin_SRCS})
 set_target_properties(ktnef_bin PROPERTIES OUTPUT_NAME ktnefviewer)
 
--- trunk/KDE/kdepim/libkdepim/kmeditor.cpp #790257:790258
@@ -63,6 +63,7 @@
 #include <QAction>
 #include <QProcess>
 #include <QTextLayout>
+#include <QTimer>
 
 //system includes
 #include <assert.h>
@@ -91,6 +92,7 @@
     //
     void addSuggestion( const QString&,const QStringList& );
 
+    void ensureCursorVisibleDelayed();
 
     //
     // Normal functions
@@ -239,6 +241,11 @@
   replacements[originalWord] = lst;
 }
 
+void KMeditorPrivate::ensureCursorVisibleDelayed()
+{
+  static_cast<KTextEdit*>( q )->ensureCursorVisible();
+}
+
 void KMeditorPrivate::mergeFormatOnWordOrSelection( const QTextCharFormat &format )
 {
   QTextCursor cursor = q->textCursor();
@@ -1169,4 +1176,11 @@
   return temp;
 }
 
+void KMeditor::ensureCursorVisible()
+{
+  QCoreApplication::processEvents();
+  // ugly hack because the layout changes afterwards, making the cursor hidden...
+  QTimer::singleShot(500, this, SLOT(ensureCursorVisibleDelayed()));
+}
+
 #include "kmeditor.moc"
--- trunk/KDE/kdepim/libkdepim/kmeditor.h #790257:790258
@@ -267,6 +267,8 @@
      */
     QString toWrappedPlainText() const;
 
+    void ensureCursorVisible();
+
   public Q_SLOTS:
 
     /**
@@ -380,6 +382,7 @@
     KMeditorPrivate *const d;
     friend class KMeditorPrivate;
     Q_PRIVATE_SLOT( d, void addSuggestion( const QString&, const QStringList& ) )
+    Q_PRIVATE_SLOT( d, void ensureCursorVisibleDelayed() )
 };
 
 }
--- trunk/KDE/kdepim/wizards/CMakeLists.txt #790257:790258
@@ -16,6 +16,10 @@
 
 kde4_add_kcfg_files(groupwarewizard_SRCS egroupwareconfig.kcfgc kolabconfig.kcfgc sloxconfig.kcfgc)
 
+
+# todo: more appropriate icon?
+kde4_add_app_icon(groupwarewizard_SRCS "${KDE4_ICON_DIR}/oxygen/*/actions/tools-wizard.png")
+
 kde4_add_executable(groupwarewizard ${groupwarewizard_SRCS})
 
 target_link_libraries(groupwarewizard  ${KDE4_KDECORE_LIBS} 
@@ -36,6 +40,9 @@
 
 kde4_add_kcfg_files(egroupwarewizard_SRCS egroupwareconfig.kcfgc)
 
+# todo: more appropriate icon?
+kde4_add_app_icon(egroupwarewizard_SRCS "${KDE4_ICON_DIR}/oxygen/*/actions/tools-wizard.png")
+
 kde4_add_executable(egroupwarewizard ${egroupwarewizard_SRCS})
 
 target_link_libraries(egroupwarewizard  ${KDE4_KDECORE_LIBS} kabc_xmlrpc kcal_xmlrpc knotes_xmlrpc ${KDE4_KCAL_LIBS} kdepim)
@@ -50,6 +57,9 @@
 
 kde4_add_kcfg_files(sloxwizard_SRCS sloxconfig.kcfgc)
 
+# todo: more appropriate icon?
+kde4_add_app_icon(sloxwizard_SRCS "${KDE4_ICON_DIR}/oxygen/*/actions/tools-wizard.png")
+
 kde4_add_executable(sloxwizard ${sloxwizard_SRCS})
 
 target_link_libraries(sloxwizard  ${KDE4_KDECORE_LIBS} kcal_slox kabc_slox ${KDE4_KCAL_LIBS} ${KDE4_KABC_LIBS} kdepim)
@@ -68,6 +78,9 @@
 
 kde4_add_kcfg_files(kolabwizard_SRCS kolabconfig.kcfgc)
 
+# todo: more appropriate icon?
+kde4_add_app_icon(kolabwizard_SRCS "${KDE4_ICON_DIR}/oxygen/*/actions/tools-wizard.png")
+
 kde4_add_executable(kolabwizard ${kolabwizard_SRCS})
 
 target_link_libraries(kolabwizard  ${KDE4_KCAL_LIBS} ${KDE4_KPIMIDENTITIES_LIBS} kabckolab knoteskolab kcalkolab kdepim)
@@ -85,6 +98,9 @@
 
 kde4_add_kcfg_files(scalixwizard_SRCS scalixconfig.kcfgc)
 
+# todo: more appropriate icon?
+kde4_add_app_icon(scalixwizard_SRCS "${KDE4_ICON_DIR}/oxygen/*/actions/tools-wizard.png")
+
 kde4_add_executable(scalixwizard ${scalixwizard_SRCS})
 
 target_link_libraries(scalixwizard  ${KDE4_KCAL_LIBS} ${KDE4_KPIMIDENTITIES_LIBS} kabcscalix knotesscalix kcalscalix kdepim)

From ps_ml at gmx.de  Wed Mar 26 14:06:31 2008
From: ps_ml at gmx.de (Patrick Spendrin)
Date: Wed, 26 Mar 2008 14:06:31 +0100
Subject: koffice/libs/pigment
In-Reply-To: <200803242237.51067.cberger@cberger.net>
References: <1206062422.398458.30434.nullmailer@svn.kde.org>
	<200803242237.51067.cberger@cberger.net>
Message-ID: <47EA4A57.6030503@gmx.de>

Cyrille Berger schrieb:
> You know what would make you happy and me at the same time ? If you look why 
> the add_definition in cmakelists.txt and fix that instead, it's probably less 
> time than changing the source and headers after  my commits.
No.
First such definitions shouldn't be in the build system scripts - the 
source code doesn't contain everything that is needed to build (even if 
it is only for platforms where you detest the platform itself and the 
people working on it) - you wouldn't put other source code into the 
cmakelists.txt files would you? So one other solution would be to define 
  and, or and not in some kind of header which is included where needed 
(one could use the *_export.h even if that is not really a clean solution).
Second the add_definition stuff doesn't seem to work for mingw - the 
preprocessor seems to have some problems with it and thus it doesn't 
seem to be possible to get it working this way. It works for msvc 
currently though but see my first point.
Even though there are some other solutions, I would like to convince you 
  to not use those keywords - they are non standard for KDE source code 
(there is no other place using them) and they add another source for 
errors even if they might be easier to read. If you have any problems in 
changing the style of the sources (e.g. they are sync'ed with external 
repositories) we can try to find a better solution.

regards,
Patrick Spendrin

> 
> On Friday 21 March 2008, you wrote:
>> SVN commit 788221 by sengels:
>>
>> Please keep the original C++ boolean operators &&, || and ! - other
>> operators will break build on mingw! CCMAIL: cberger at cberger.net
>>
>>  M  +14 -14    KoColorConversionSystem.cpp
> 
> 
> 


-- 
web:                 http://windows.kde.org
mailing list:        kde-windows at kde.org
irc:                 #kde-windows (irc.freenode.net)

From js at iidea.pl  Wed Mar 26 14:26:06 2008
From: js at iidea.pl (=?UTF-8?B?SmFyb3PFgmF3IFN0YW5pZWs=?=)
Date: Wed, 26 Mar 2008 14:26:06 +0100
Subject: koffice/libs/pigment
In-Reply-To: <47EA4A57.6030503@gmx.de>
References: <1206062422.398458.30434.nullmailer@svn.kde.org>	<200803242237.51067.cberger@cberger.net>
	<47EA4A57.6030503@gmx.de>
Message-ID: <47EA4EEE.8020707@iidea.pl>

Patrick Spendrin said the following, On 2008-03-26 14:06:

> Cyrille Berger schrieb:
>> You know what would make you happy and me at the same time ? If you look why 
>> the add_definition in cmakelists.txt and fix that instead, it's probably less 
>> time than changing the source and headers after  my commits.
> No.
> First such definitions shouldn't be in the build system scripts - the 
> source code doesn't contain everything that is needed to build (even if 
> it is only for platforms where you detest the platform itself and the 
> people working on it) - you wouldn't put other source code into the 
> cmakelists.txt files would you? So one other solution would be to define 
>   and, or and not in some kind of header which is included where needed 
> (one could use the *_export.h even if that is not really a clean solution).

What's wrong with the fix for Klingon grammar? Do we need more fixes?

if(MSVC)
   add_definitions(-Dand=&& -Dor=|| -Dnot=!)
   # avoid "cannot open file 'LIBC.lib'" error
   set(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} 
/NODEFAULTLIB:LIBC.LIB")
else(MSVC)
   add_definitions("-Dand=\\&\\& -Dor=\\|\\| -Dnot=\\!")
endif(MSVC)

That said, of course this is only for Cyrille's code (and nowhere else in 
KDE), who for unknown reasons adds a risk for conflicts with and/or/not/xor 
macros we may have in the future (think of parser constants as one example). 
But it's his code and he is the maintenaner.

-- 
regards / pozdrawiam, Jaroslaw Staniek
  Sponsored by OpenOffice Polska (http://www.openoffice.com.pl/en) to work on
  Kexi & KOffice (http://www.kexi.pl/en, http://www.koffice.org/kexi)
  KDE Libraries for MS Windows (http://windows.kde.org)

From Ch.Ehrlicher at gmx.de  Wed Mar 26 17:38:48 2008
From: Ch.Ehrlicher at gmx.de (Christian Ehrlicher)
Date: Wed, 26 Mar 2008 17:38:48 +0100
Subject: koffice/libs/pigment
In-Reply-To: <47EA4EEE.8020707@iidea.pl>
References: <1206062422.398458.30434.nullmailer@svn.kde.org>
	<200803242237.51067.cberger@cberger.net>	<47EA4A57.6030503@gmx.de>
	<47EA4EEE.8020707@iidea.pl>
Message-ID: <20080326163848.159270@gmx.net>

> Von: "Jaros?aw Staniek"
> Patrick Spendrin said the following, On 2008-03-26 14:06:
> 
> > Cyrille Berger schrieb:
> >> You know what would make you happy and me at the same time ? If you
> look why 
> >> the add_definition in cmakelists.txt and fix that instead, it's
> probably less 
> >> time than changing the source and headers after  my commits.
> > No.
> > First such definitions shouldn't be in the build system scripts - the 
> > source code doesn't contain everything that is needed to build (even if 
> > it is only for platforms where you detest the platform itself and the 
> > people working on it) - you wouldn't put other source code into the 
> > cmakelists.txt files would you? So one other solution would be to define
> >   and, or and not in some kind of header which is included where needed 
> > (one could use the *_export.h even if that is not really a clean
> solution).
> 
> What's wrong with the fix for Klingon grammar? Do we need more fixes?
> 
> if(MSVC)
>    add_definitions(-Dand=&& -Dor=|| -Dnot=!)
>    # avoid "cannot open file 'LIBC.lib'" error
>    set(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} 
> /NODEFAULTLIB:LIBC.LIB")
> else(MSVC)
>    add_definitions("-Dand=\\&\\& -Dor=\\|\\| -Dnot=\\!")
> endif(MSVC)
> 
> That said, of course this is only for Cyrille's code (and nowhere else in 
> KDE), who for unknown reasons adds a risk for conflicts with
> and/or/not/xor 
> macros we may have in the future (think of parser constants as one
> example). 
> But it's his code and he is the maintenaner.
> 
The maintainer has to decide if the code should run on windows or not. If it should run, he must accept the rules. If not - I don't care.

Christian
-- 
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! 
Ideal f?r Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

From js at iidea.pl  Wed Mar 26 20:18:28 2008
From: js at iidea.pl (=?UTF-8?B?SmFyb3PFgmF3IFN0YW5pZWs=?=)
Date: Wed, 26 Mar 2008 20:18:28 +0100
Subject: Windows registry utils in kdesupport/win32
Message-ID: <47EAA184.9060006@iidea.pl>


Hi,
Forgot to say that before but contents of kdecore/kernel/kernel_win.cpp is my 
code, which was originally in kdelibs/win/win32_utils2.cpp (KDE3).
But more important is what I propose - move it to kdesupport because we'll be 
accessing more and more windows registry in the future.

OK?

-- 
regards / pozdrawiam, Jaroslaw Staniek
  Sponsored by OpenOffice Polska (http://www.openoffice.com.pl/en) to work on
  Kexi & KOffice (http://www.kexi.pl/en, http://www.koffice.org/kexi)
  KDE Libraries for MS Windows (http://windows.kde.org)

From Ch.Ehrlicher at gmx.de  Wed Mar 26 20:29:30 2008
From: Ch.Ehrlicher at gmx.de (Christian Ehrlicher)
Date: Wed, 26 Mar 2008 20:29:30 +0100
Subject: Windows registry utils in kdesupport/win32
In-Reply-To: <47EAA184.9060006@iidea.pl>
References: <47EAA184.9060006@iidea.pl>
Message-ID: <47EAA41A.3040408@gmx.de>

Jaros?aw Staniek schrieb:
> Hi,
> Forgot to say that before but contents of kdecore/kernel/kernel_win.cpp is my 
> code, which was originally in kdelibs/win/win32_utils2.cpp (KDE3).
> But more important is what I propose - move it to kdesupport because we'll be 
> accessing more and more windows registry in the future.
> 
much better - remove it completly and replace it by QSettings :-)
http://doc.trolltech.com/4.3/qsettings.html#platform-specific-notes


Christian

From ralf.habacker at freenet.de  Wed Mar 26 20:51:15 2008
From: ralf.habacker at freenet.de (Ralf Habacker)
Date: Wed, 26 Mar 2008 20:51:15 +0100
Subject: Windows registry utils in kdesupport/win32
In-Reply-To: <47EAA184.9060006@iidea.pl>
References: <47EAA184.9060006@iidea.pl>
Message-ID: <47EAA933.4000605@freenet.de>

Jaros?aw Staniek schrieb:
> Hi,
> Forgot to say that before but contents of kdecore/kernel/kernel_win.cpp is my 
> code, which was originally in kdelibs/win/win32_utils2.cpp (KDE3).
> But more important is what I propose - move it to kdesupport because we'll be 
> accessing more and more windows registry in the future.
>   
read access only or write access too ? The latter has to be reconsidered 
very well

Ralf


From js at iidea.pl  Wed Mar 26 22:33:33 2008
From: js at iidea.pl (=?UTF-8?B?SmFyb3PFgmF3IFN0YW5pZWs=?=)
Date: Wed, 26 Mar 2008 22:33:33 +0100
Subject: Windows registry utils in kdesupport/win32
In-Reply-To: <47EAA933.4000605@freenet.de>
References: <47EAA184.9060006@iidea.pl> <47EAA933.4000605@freenet.de>
Message-ID: <47EAC12D.9020509@iidea.pl>

Ralf Habacker said the following, On 2008-03-26 20:51:
> Jaros?aw Staniek schrieb:
>> Hi,
>> Forgot to say that before but contents of kdecore/kernel/kernel_win.cpp is my 
>> code, which was originally in kdelibs/win/win32_utils2.cpp (KDE3).
>> But more important is what I propose - move it to kdesupport because we'll be 
>> accessing more and more windows registry in the future.
>>   
> read access only or write access too ? The latter has to be reconsidered 
> very well

could you please explain?

-- 
regards / pozdrawiam, Jaroslaw Staniek
  Sponsored by OpenOffice Polska (http://www.openoffice.com.pl/en) to work on
  Kexi & KOffice (http://www.kexi.pl/en, http://www.koffice.org/kexi)
  KDE Libraries for MS Windows (http://windows.kde.org)

From js at iidea.pl  Wed Mar 26 22:34:19 2008
From: js at iidea.pl (=?UTF-8?B?SmFyb3PFgmF3IFN0YW5pZWs=?=)
Date: Wed, 26 Mar 2008 22:34:19 +0100
Subject: Windows registry utils in kdesupport/win32
In-Reply-To: <47EAA41A.3040408@gmx.de>
References: <47EAA184.9060006@iidea.pl> <47EAA41A.3040408@gmx.de>
Message-ID: <47EAC15B.2030602@iidea.pl>

Christian Ehrlicher said the following, On 2008-03-26 20:29:
> Jaros?aw Staniek schrieb:
>> Hi,
>> Forgot to say that before but contents of kdecore/kernel/kernel_win.cpp is my 
>> code, which was originally in kdelibs/win/win32_utils2.cpp (KDE3).
>> But more important is what I propose - move it to kdesupport because we'll be 
>> accessing more and more windows registry in the future.
>>
> much better - remove it completly and replace it by QSettings :-)
> http://doc.trolltech.com/4.3/qsettings.html#platform-specific-notes
> 

Well, good idea (that's new in Qt4); so we'd have only things like 
showWin32FilePropertyDialog() in kdesupport.

-- 
regards / pozdrawiam, Jaroslaw Staniek
  Sponsored by OpenOffice Polska (http://www.openoffice.com.pl/en) to work on
  Kexi & KOffice (http://www.kexi.pl/en, http://www.koffice.org/kexi)
  KDE Libraries for MS Windows (http://windows.kde.org)

From js at iidea.pl  Thu Mar 27 00:51:29 2008
From: js at iidea.pl (=?UTF-8?B?SmFyb3PFgmF3IFN0YW5pZWs=?=)
Date: Thu, 27 Mar 2008 00:51:29 +0100
Subject: KToolInvocation
Message-ID: <47EAE181.7090004@iidea.pl>

Ralf, any idea why code like KToolInvocation::invokeMailer()  is comemntedout 
on Windows?

-- 
regards / pozdrawiam, Jaroslaw Staniek
  Sponsored by OpenOffice Polska (http://www.openoffice.com.pl/en) to work on
  Kexi & KOffice (http://www.kexi.pl/en, http://www.koffice.org/kexi)
  KDE Libraries for MS Windows (http://windows.kde.org)

From Ch.Ehrlicher at gmx.de  Thu Mar 27 06:29:55 2008
From: Ch.Ehrlicher at gmx.de (Christian Ehrlicher)
Date: Thu, 27 Mar 2008 06:29:55 +0100
Subject: Windows registry utils in kdesupport/win32
In-Reply-To: <47EAC15B.2030602@iidea.pl>
References: <47EAA184.9060006@iidea.pl> <47EAA41A.3040408@gmx.de>
	<47EAC15B.2030602@iidea.pl>
Message-ID: <47EB30D3.5080205@gmx.de>

Jaros?aw Staniek schrieb:
> Christian Ehrlicher said the following, On 2008-03-26 20:29:
>> Jaros?aw Staniek schrieb:
>>> Hi,
>>> Forgot to say that before but contents of kdecore/kernel/kernel_win.cpp is my 
>>> code, which was originally in kdelibs/win/win32_utils2.cpp (KDE3).
>>> But more important is what I propose - move it to kdesupport because we'll be 
>>> accessing more and more windows registry in the future.
>>>
>> much better - remove it completly and replace it by QSettings :-)
>> http://doc.trolltech.com/4.3/qsettings.html#platform-specific-notes
>>
> 
> Well, good idea (that's new in Qt4); so we'd have only things like 
> showWin32FilePropertyDialog() in kdesupport.
> 
So what do you want to move to kdesupport (and where?). Just this single 
Function?


Christian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 258 bytes
Desc: OpenPGP digital signature
Url : http://mail.kde.org/pipermail/kde-windows/attachments/20080327/3c306a0c/attachment.pgp 

From gueven.bay at googlemail.com  Thu Mar 27 07:00:42 2008
From: gueven.bay at googlemail.com (Gueven Bay)
Date: Thu, 27 Mar 2008 07:00:42 +0100
Subject: How to set up FREETYPE_LIBRARIES, X11_LIBRARY, XEXT_LIBRARY
Message-ID: <13413b8f0803262300s286d74e8x1208df1c234fc7ce@mail.gmail.com>

Hello,

I have now "Updated to revision 790649".

I have (still) a problem with emerging kdebase-workspace.

I get the error message
"CMake Error: This project requires some variables to be set,
and cmake can not find them.
Please set the following variables:
FONTCONFIG_INCLUDE_DIR (ADVANCED)
FONTCONFIG_LIBRARIES (ADVANCED)
FREETYPE_LIBRARIES
X11_LIBRARY
XEXT_LIBRARY

-- Configuring done
emerge fatal error: while CMake'ing. cmd: cmake -G "MinGW Makefiles" H:\kderoot\
kdesvn\trunk\KDE\kdebase\workspace -DCMAKE_INSTALL_PREFIX=H:/kderoot -DCMAKE_INC
LUDE_PATH=H:/kderoot/include -DCMAKE_LIBRARY_PATH=H:/kderoot/lib -DKDEWIN_DIR:PA
TH=H:/kderoot  -DCMAKE_BUILD_TYPE=RelWithDebInfo
emerge fatal error: running python
H:\kderoot\emerge\portage\kde\kdebase-workspace\kdebase-workspace-20080202.py
compile
emerge error: fatal error: package kde/kdebase-workspace-20080202 all failed"


I looked into kdesettings.bat and kdeenv.bat but there are no examples or
default values that I could set.
And there is no X11 directory under my kderoot, which is why I don't know
to which value to set up "X11_LIBRARY". Not under kderoot\lib, not under
kderoot\bin or kderoot\mingw ... (Maybe there is a package missing. I have
the packages under [1] successfully emerged.)

So my question is how to set up the requested variables (to which values) ?



Thank you
regards
Gueven




[1]
Category                 Package                  Version
--------                 -------                  -------
contributed              gpgme-qt                 20080115
dev-util                 cmake                    2.4.8
dev-util                 mingw                    3.4.5
dev-util                 perl                     5.8.8.822
dev-util                 subversion               1.4.6.20080222
dev-util                 win32libs                20080129
gnuwin32                 patch                    2.5.9-7
gnuwin32                 sed                      4.1.5
gnuwin32                 wget                     1.10.1
kde                      kdebase-apps             20080202
kde                      kdebase-runtime          20080202
kde                      kdelibs                  20080202
kde                      kdepimlibs               20080202
kdesupport               clucene-core             0.9.16.1.20070930
kdesupport               kdewin32                 0.3.6.20080303
kdesupport               qimageblitz              4.0.0.20071030
kdesupport               soprano                  2.00.0.20080107
kdesupport               strigi                   0.5.8.20080220
libs                     qt                       4.4.0.20080222
virtual                  base                     0.2

From Ch.Ehrlicher at gmx.de  Thu Mar 27 07:07:45 2008
From: Ch.Ehrlicher at gmx.de (Christian Ehrlicher)
Date: Thu, 27 Mar 2008 07:07:45 +0100
Subject: How to set up FREETYPE_LIBRARIES, X11_LIBRARY, XEXT_LIBRARY
In-Reply-To: <13413b8f0803262300s286d74e8x1208df1c234fc7ce@mail.gmail.com>
References: <13413b8f0803262300s286d74e8x1208df1c234fc7ce@mail.gmail.com>
Message-ID: <47EB39B1.9080400@gmx.de>

Gueven Bay schrieb:
> Hello,
> 
> I have now "Updated to revision 790649".
> 
> I have (still) a problem with emerging kdebase-workspace.
> 
kdebase-workspace is not compileable on windows. We don't have a kde 
workspace on windows. Only the apps.


Christian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 258 bytes
Desc: OpenPGP digital signature
Url : http://mail.kde.org/pipermail/kde-windows/attachments/20080327/2f4d5d61/attachment.pgp 

From ralf.habacker at freenet.de  Thu Mar 27 09:20:24 2008
From: ralf.habacker at freenet.de (Ralf Habacker)
Date: Thu, 27 Mar 2008 09:20:24 +0100
Subject: Windows registry utils in kdesupport/win32
In-Reply-To: <47EAC12D.9020509@iidea.pl>
References: <47EAA184.9060006@iidea.pl> <47EAA933.4000605@freenet.de>
	<47EAC12D.9020509@iidea.pl>
Message-ID: <47EB58C8.1070108@freenet.de>

Jaros?aw Staniek schrieb:
> Ralf Habacker said the following, On 2008-03-26 20:51:
>   
>> Jaros?aw Staniek schrieb:
>>     
>>> Hi,
>>> Forgot to say that before but contents of kdecore/kernel/kernel_win.cpp is my 
>>> code, which was originally in kdelibs/win/win32_utils2.cpp (KDE3).
>>> But more important is what I propose - move it to kdesupport because we'll be 
>>> accessing more and more windows registry in the future.
>>>   
>>>       
>> read access only or write access too ? The latter has to be reconsidered 
>> very well
>>     
>
> could you please explain?
>
>   
setting absolutes pathes of kde installations in registry will make it 
hard to place kde installations on an usb stick or removal disc because 
the drive letter may change.
Because of this kdecore and dbus contains code to determine the related 
install path on runtime. We discussed this a short time before with 
Frank Osterfeld.

Ralf











From ralf.habacker at freenet.de  Thu Mar 27 09:28:56 2008
From: ralf.habacker at freenet.de (Ralf Habacker)
Date: Thu, 27 Mar 2008 09:28:56 +0100
Subject: KToolInvocation
In-Reply-To: <47EAE181.7090004@iidea.pl>
References: <47EAE181.7090004@iidea.pl>
Message-ID: <47EB5AC8.4000707@freenet.de>

Jaros?aw Staniek schrieb:
> Ralf, any idea why code like KToolInvocation::invokeMailer()  is comemntedout 
> on Windows?
>
>   

It was commented out in Jun 2006 see 
http://websvn.kde.org/trunk/KDE/kdelibs/kdecore/kernel/ktoolinvocation_win.cpp?r1=544324&r2=548513 

and probably noone has taken the time to reenable this code.

Ralf


From js at iidea.pl  Thu Mar 27 09:56:33 2008
From: js at iidea.pl (=?UTF-8?B?SmFyb3PFgmF3IFN0YW5pZWs=?=)
Date: Thu, 27 Mar 2008 09:56:33 +0100
Subject: Windows registry utils in kdesupport/win32
In-Reply-To: <47EB30D3.5080205@gmx.de>
References: <47EAA184.9060006@iidea.pl>
	<47EAA41A.3040408@gmx.de>	<47EAC15B.2030602@iidea.pl>
	<47EB30D3.5080205@gmx.de>
Message-ID: <47EB6141.8060908@iidea.pl>

Christian Ehrlicher said the following, On 2008-03-27 06:29:
> Jaros?aw Staniek schrieb:
>> Christian Ehrlicher said the following, On 2008-03-26 20:29:
>>> Jaros?aw Staniek schrieb:
>>>> Hi,
>>>> Forgot to say that before but contents of 
>>>> kdecore/kernel/kernel_win.cpp is my code, which was originally in 
>>>> kdelibs/win/win32_utils2.cpp (KDE3).
>>>> But more important is what I propose - move it to kdesupport because 
>>>> we'll be accessing more and more windows registry in the future.
>>>>
>>> much better - remove it completly and replace it by QSettings :-)
>>> http://doc.trolltech.com/4.3/qsettings.html#platform-specific-notes
>>>
>>
>> Well, good idea (that's new in Qt4); so we'd have only things like 
>> showWin32FilePropertyDialog() in kdesupport.
>>
> So what do you want to move to kdesupport (and where?). Just this single 
> Function?

Remove getWin32RegistryValue registry function, we'll probably also have more 
functions like getWin32ShellFoldersPath() in kdesupport.

also what about kMessageOutput and kdecoreDllInstance and DllMain? Are these 
used (or is there a plan)?

I'd also like to use K_GLOBAL_STATIC for myGlobals.

-- 
regards / pozdrawiam, Jaroslaw Staniek
  Sponsored by OpenOffice Polska (http://www.openoffice.com.pl/en) to work on
  Kexi & KOffice (http://www.kexi.pl/en, http://www.koffice.org/kexi)
  KDE Libraries for MS Windows (http://windows.kde.org)

From js at iidea.pl  Thu Mar 27 09:58:41 2008
From: js at iidea.pl (=?UTF-8?B?SmFyb3PFgmF3IFN0YW5pZWs=?=)
Date: Thu, 27 Mar 2008 09:58:41 +0100
Subject: KToolInvocation
In-Reply-To: <47EB5AC8.4000707@freenet.de>
References: <47EAE181.7090004@iidea.pl> <47EB5AC8.4000707@freenet.de>
Message-ID: <47EB61C1.6000607@iidea.pl>

Ralf Habacker said the following, On 2008-03-27 09:28:
> Jaros?aw Staniek schrieb:
>> Ralf, any idea why code like KToolInvocation::invokeMailer()  is comemntedout 
>> on Windows?
>>
>>   
> 
> It was commented out in Jun 2006 see 
> http://websvn.kde.org/trunk/KDE/kdelibs/kdecore/kernel/ktoolinvocation_win.cpp?r1=544324&r2=548513 
> 
> and probably noone has taken the time to reenable this code.

OK, so I am looking at this stuff.

-- 
regards / pozdrawiam, Jaroslaw Staniek
  Sponsored by OpenOffice Polska (http://www.openoffice.com.pl/en) to work on
  Kexi & KOffice (http://www.kexi.pl/en, http://www.koffice.org/kexi)
  KDE Libraries for MS Windows (http://windows.kde.org)


From Ch.Ehrlicher at gmx.de  Thu Mar 27 10:18:35 2008
From: Ch.Ehrlicher at gmx.de (Christian Ehrlicher)
Date: Thu, 27 Mar 2008 10:18:35 +0100
Subject: Windows registry utils in kdesupport/win32
In-Reply-To: <47EB6141.8060908@iidea.pl>
References: <47EAA184.9060006@iidea.pl>	<47EAA41A.3040408@gmx.de>
	<47EAC15B.2030602@iidea.pl>	<47EB30D3.5080205@gmx.de>
	<47EB6141.8060908@iidea.pl>
Message-ID: <20080327091835.241300@gmx.net>

> Von: "Jaros?aw Staniek"
> Christian Ehrlicher said the following, On 2008-03-27 06:29:
> > Jaros?aw Staniek schrieb:
> >> Christian Ehrlicher said the following, On 2008-03-26 20:29:
> >>> Jaros?aw Staniek schrieb:
> >>>> Hi,
> >>>> Forgot to say that before but contents of 
> >>>> kdecore/kernel/kernel_win.cpp is my code, which was originally in 
> >>>> kdelibs/win/win32_utils2.cpp (KDE3).
> >>>> But more important is what I propose - move it to kdesupport because 
> >>>> we'll be accessing more and more windows registry in the future.
> >>>>
> >>> much better - remove it completly and replace it by QSettings :-)
> >>> http://doc.trolltech.com/4.3/qsettings.html#platform-specific-notes
> >>>
> >>
> >> Well, good idea (that's new in Qt4); so we'd have only things like 
> >> showWin32FilePropertyDialog() in kdesupport.
> >>
> > So what do you want to move to kdesupport (and where?). Just this single
> > Function?
> 
> Remove getWin32RegistryValue registry function, we'll probably also have
> more 
> functions like getWin32ShellFoldersPath() in kdesupport.
> 
As long as you only have two functions I don't see a need for an additional library in kdesupport.

> also what about kMessageOutput and kdecoreDllInstance and DllMain? Are
> these 
> used (or is there a plan)?
> 
They're used - just take a look in kkernel_win.cpp

> I'd also like to use K_GLOBAL_STATIC for myGlobals.
> 
ok


Christian
-- 
Psst! Geheimtipp: Online Games kostenlos spielen bei den GMX Free Games! 
http://games.entertainment.gmx.net/de/entertainment/games/free

From js at iidea.pl  Thu Mar 27 10:50:27 2008
From: js at iidea.pl (=?UTF-8?B?SmFyb3PFgmF3IFN0YW5pZWs=?=)
Date: Thu, 27 Mar 2008 10:50:27 +0100
Subject: Windows registry utils in kdesupport/win32
In-Reply-To: <47EB58C8.1070108@freenet.de>
References: <47EAA184.9060006@iidea.pl>
	<47EAA933.4000605@freenet.de>	<47EAC12D.9020509@iidea.pl>
	<47EB58C8.1070108@freenet.de>
Message-ID: <47EB6DE3.9040001@iidea.pl>

Ralf Habacker said the following, On 2008-03-27 09:20:
> Jaros?aw Staniek schrieb:
>> Ralf Habacker said the following, On 2008-03-26 20:51:
>>   
>>> Jaros?aw Staniek schrieb:
>>>     
>>>> Hi,
>>>> Forgot to say that before but contents of kdecore/kernel/kernel_win.cpp is my 
>>>> code, which was originally in kdelibs/win/win32_utils2.cpp (KDE3).
>>>> But more important is what I propose - move it to kdesupport because we'll be 
>>>> accessing more and more windows registry in the future.
>>>>   
>>>>       
>>> read access only or write access too ? The latter has to be reconsidered 
>>> very well
>>>     
>> could you please explain?
>>
>>   
> setting absolutes pathes of kde installations in registry will make it 
> hard to place kde installations on an usb stick or removal disc because 
> the drive letter may change.
> Because of this kdecore and dbus contains code to determine the related 
> install path on runtime. We discussed this a short time before with 
> Frank Osterfeld.

No, no - I do not mean writing these paths, but accessing the keys in general 
(probably will be rarely used anyway). It's available in QSettings.

-- 
regards / pozdrawiam, Jaroslaw Staniek
  Sponsored by OpenOffice Polska (http://www.openoffice.com.pl/en) to work on
  Kexi & KOffice (http://www.kexi.pl/en, http://www.koffice.org/kexi)
  KDE Libraries for MS Windows (http://windows.kde.org)

From js at iidea.pl  Thu Mar 27 13:55:05 2008
From: js at iidea.pl (=?UTF-8?B?SmFyb3PFgmF3IFN0YW5pZWs=?=)
Date: Thu, 27 Mar 2008 13:55:05 +0100
Subject: Windows registry utils in kdesupport/win32
In-Reply-To: <20080327091835.241300@gmx.net>
References: <47EAA184.9060006@iidea.pl>	<47EAA41A.3040408@gmx.de>	<47EAC15B.2030602@iidea.pl>	<47EB30D3.5080205@gmx.de>	<47EB6141.8060908@iidea.pl>
	<20080327091835.241300@gmx.net>
Message-ID: <47EB9929.9090207@iidea.pl>

Christian Ehrlicher said the following, On 2008-03-27 10:18:
>> Von: "Jaros?aw Staniek"
>> Christian Ehrlicher said the following, On 2008-03-27 06:29:
>>> Jaros?aw Staniek schrieb:
>>>> Christian Ehrlicher said the following, On 2008-03-26 20:29:
>>>>> Jaros?aw Staniek schrieb:
>>>>>> Hi,
>>>>>> Forgot to say that before but contents of 
>>>>>> kdecore/kernel/kernel_win.cpp is my code, which was originally in 
>>>>>> kdelibs/win/win32_utils2.cpp (KDE3).
>>>>>> But more important is what I propose - move it to kdesupport because 
>>>>>> we'll be accessing more and more windows registry in the future.
>>>>>>
>>>>> much better - remove it completly and replace it by QSettings :-)
>>>>> http://doc.trolltech.com/4.3/qsettings.html#platform-specific-notes
>>>>>
>>>> Well, good idea (that's new in Qt4); so we'd have only things like 
>>>> showWin32FilePropertyDialog() in kdesupport.
>>>>
>>> So what do you want to move to kdesupport (and where?). Just this single
>>> Function?
>> Remove getWin32RegistryValue registry function, we'll probably also have
>> more 
>> functions like getWin32ShellFoldersPath() in kdesupport.
>>
> As long as you only have two functions I don't see a need for an additional library in kdesupport.

We're talking about kdewin32 lib.

-- 
regards / pozdrawiam, Jaroslaw Staniek
  Sponsored by OpenOffice Polska (http://www.openoffice.com.pl/en) to work on
  Kexi & KOffice (http://www.kexi.pl/en, http://www.koffice.org/kexi)
  KDE Libraries for MS Windows (http://windows.kde.org)

From js at iidea.pl  Thu Mar 27 13:58:01 2008
From: js at iidea.pl (=?UTF-8?B?SmFyb3PFgmF3IFN0YW5pZWs=?=)
Date: Thu, 27 Mar 2008 13:58:01 +0100
Subject: Windows registry utils in kdesupport/win32
In-Reply-To: <47EB9929.9090207@iidea.pl>
References: <47EAA184.9060006@iidea.pl>	<47EAA41A.3040408@gmx.de>	<47EAC15B.2030602@iidea.pl>	<47EB30D3.5080205@gmx.de>	<47EB6141.8060908@iidea.pl>	<20080327091835.241300@gmx.net>
	<47EB9929.9090207@iidea.pl>
Message-ID: <47EB99D9.2000007@iidea.pl>

Jaros?aw Staniek said the following, On 2008-03-27 13:55:
> Christian Ehrlicher said the following, On 2008-03-27 10:18:
>>> Von: "Jaros?aw Staniek"
>>> Christian Ehrlicher said the following, On 2008-03-27 06:29:
>>>> Jaros?aw Staniek schrieb:
>>>>> Christian Ehrlicher said the following, On 2008-03-26 20:29:
>>>>>> Jaros?aw Staniek schrieb:
>>>>>>> Hi,
>>>>>>> Forgot to say that before but contents of 
>>>>>>> kdecore/kernel/kernel_win.cpp is my code, which was originally in 
>>>>>>> kdelibs/win/win32_utils2.cpp (KDE3).
>>>>>>> But more important is what I propose - move it to kdesupport because 
>>>>>>> we'll be accessing more and more windows registry in the future.
>>>>>>>
>>>>>> much better - remove it completly and replace it by QSettings :-)
>>>>>> http://doc.trolltech.com/4.3/qsettings.html#platform-specific-notes
>>>>>>
>>>>> Well, good idea (that's new in Qt4); so we'd have only things like 
>>>>> showWin32FilePropertyDialog() in kdesupport.
>>>>>
>>>> So what do you want to move to kdesupport (and where?). Just this single
>>>> Function?
>>> Remove getWin32RegistryValue registry function, we'll probably also have
>>> more 
>>> functions like getWin32ShellFoldersPath() in kdesupport.
>>>
>> As long as you only have two functions I don't see a need for an additional library in kdesupport.
> 
> We're talking about kdewin32 lib.

Hm ok but then we wouldnt have access to Qt...
So I am saying in kdecore (possibly with a namespace).

-- 
regards / pozdrawiam, Jaroslaw Staniek
  Sponsored by OpenOffice Polska (http://www.openoffice.com.pl/en) to work on
  Kexi & KOffice (http://www.kexi.pl/en, http://www.koffice.org/kexi)
  KDE Libraries for MS Windows (http://windows.kde.org)


From Ch.Ehrlicher at gmx.de  Thu Mar 27 14:06:18 2008
From: Ch.Ehrlicher at gmx.de (Christian Ehrlicher)
Date: Thu, 27 Mar 2008 14:06:18 +0100
Subject: Windows registry utils in kdesupport/win32
In-Reply-To: <47EB99D9.2000007@iidea.pl>
References: <47EAA184.9060006@iidea.pl>	<47EAA41A.3040408@gmx.de>
	<47EAC15B.2030602@iidea.pl>	<47EB30D3.5080205@gmx.de>
	<47EB6141.8060908@iidea.pl>	<20080327091835.241300@gmx.net>
	<47EB9929.9090207@iidea.pl> <47EB99D9.2000007@iidea.pl>
Message-ID: <20080327130618.98050@gmx.net>

> Von: "Jaros?aw Staniek"
> Jaros?aw Staniek said the following, On 2008-03-27 13:55:
> > Christian Ehrlicher said the following, On 2008-03-27 10:18:
> >>> Von: "Jaros?aw Staniek"
> >>> Christian Ehrlicher said the following, On 2008-03-27 06:29:
> >>>> Jaros?aw Staniek schrieb:
> >>>>> Christian Ehrlicher said the following, On 2008-03-26 20:29:
> >>>>>> Jaros?aw Staniek schrieb:
> >>>>>>> Hi,
> >>>>>>> Forgot to say that before but contents of 
> >>>>>>> kdecore/kernel/kernel_win.cpp is my code, which was originally in 
> >>>>>>> kdelibs/win/win32_utils2.cpp (KDE3).
> >>>>>>> But more important is what I propose - move it to kdesupport
> because 
> >>>>>>> we'll be accessing more and more windows registry in the future.
> >>>>>>>
> >>>>>> much better - remove it completly and replace it by QSettings :-)
> >>>>>> http://doc.trolltech.com/4.3/qsettings.html#platform-specific-notes
> >>>>>>
> >>>>> Well, good idea (that's new in Qt4); so we'd have only things like 
> >>>>> showWin32FilePropertyDialog() in kdesupport.
> >>>>>
> >>>> So what do you want to move to kdesupport (and where?). Just this
> single
> >>>> Function?
> >>> Remove getWin32RegistryValue registry function, we'll probably also
> have
> >>> more 
> >>> functions like getWin32ShellFoldersPath() in kdesupport.
> >>>
> >> As long as you only have two functions I don't see a need for an
> additional library in kdesupport.
> > 
> > We're talking about kdewin32 lib.
> 
> Hm ok but then we wouldnt have access to Qt...
> So I am saying in kdecore (possibly with a namespace).
> 
That was the point why I moved out all the c++ stuff from kdewin32 - we shouldn't have a qt dependency in kdewin32 lib :)

Christian
-- 
Psst! Geheimtipp: Online Games kostenlos spielen bei den GMX Free Games! 
http://games.entertainment.gmx.net/de/entertainment/games/free

From ps_ml at gmx.de  Thu Mar 27 16:51:37 2008
From: ps_ml at gmx.de (Patrick Spendrin)
Date: Thu, 27 Mar 2008 16:51:37 +0100
Subject: Windows registry utils in kdesupport/win32
In-Reply-To: <20080327130618.98050@gmx.net>
References: <47EAA184.9060006@iidea.pl>	<47EAA41A.3040408@gmx.de>	<47EAC15B.2030602@iidea.pl>	<47EB30D3.5080205@gmx.de>	<47EB6141.8060908@iidea.pl>	<20080327091835.241300@gmx.net>	<47EB9929.9090207@iidea.pl>
	<47EB99D9.2000007@iidea.pl> <20080327130618.98050@gmx.net>
Message-ID: <47EBC289.4070904@gmx.de>

Christian Ehrlicher schrieb:
>> Von: "Jaros?aw Staniek"
>> Jaros?aw Staniek said the following, On 2008-03-27 13:55:
>>> Christian Ehrlicher said the following, On 2008-03-27 10:18:
>>>>> Von: "Jaros?aw Staniek"
>>>>> Christian Ehrlicher said the following, On 2008-03-27 06:29:
>>>>>> Jaros?aw Staniek schrieb:
>>>>>>> Christian Ehrlicher said the following, On 2008-03-26 20:29:
>>>>>>>> Jaros?aw Staniek schrieb:
>>>>>>>>> Hi,
>>>>>>>>> Forgot to say that before but contents of 
>>>>>>>>> kdecore/kernel/kernel_win.cpp is my code, which was originally in 
>>>>>>>>> kdelibs/win/win32_utils2.cpp (KDE3).
>>>>>>>>> But more important is what I propose - move it to kdesupport
>> because 
>>>>>>>>> we'll be accessing more and more windows registry in the future.
>>>>>>>>>
>>>>>>>> much better - remove it completly and replace it by QSettings :-)
>>>>>>>> http://doc.trolltech.com/4.3/qsettings.html#platform-specific-notes
>>>>>>>>
>>>>>>> Well, good idea (that's new in Qt4); so we'd have only things like 
>>>>>>> showWin32FilePropertyDialog() in kdesupport.
>>>>>>>
>>>>>> So what do you want to move to kdesupport (and where?). Just this
>> single
>>>>>> Function?
>>>>> Remove getWin32RegistryValue registry function, we'll probably also
>> have
>>>>> more 
>>>>> functions like getWin32ShellFoldersPath() in kdesupport.
>>>>>
>>>> As long as you only have two functions I don't see a need for an
>> additional library in kdesupport.
>>> We're talking about kdewin32 lib.
>> Hm ok but then we wouldnt have access to Qt...
>> So I am saying in kdecore (possibly with a namespace).
>>
> That was the point why I moved out all the c++ stuff from kdewin32 - we shouldn't have a qt dependency in kdewin32 lib :)
Was that fixed already? afair there was a Qt dependency in kdewin32.
*duck and run*
> 
> Christian

Patrick


-- 
web:                 http://windows.kde.org
mailing list:        kde-windows at kde.org
irc:                 #kde-windows (irc.freenode.net)

From js at iidea.pl  Thu Mar 27 17:11:29 2008
From: js at iidea.pl (=?UTF-8?B?SmFyb3PFgmF3IFN0YW5pZWs=?=)
Date: Thu, 27 Mar 2008 17:11:29 +0100
Subject: Windows registry utils in kdesupport/win32
In-Reply-To: <47EBC289.4070904@gmx.de>
References: <47EAA184.9060006@iidea.pl>	<47EAA41A.3040408@gmx.de>	<47EAC15B.2030602@iidea.pl>	<47EB30D3.5080205@gmx.de>	<47EB6141.8060908@iidea.pl>	<20080327091835.241300@gmx.net>	<47EB9929.9090207@iidea.pl>	<47EB99D9.2000007@iidea.pl>
	<20080327130618.98050@gmx.net> <47EBC289.4070904@gmx.de>
Message-ID: <47EBC731.2000106@iidea.pl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Patrick Spendrin said the following, On 2008-03-27 16:51:
| Christian Ehrlicher schrieb:
|>> Von: "Jaros?aw Staniek"
|>> Jaros?aw Staniek said the following, On 2008-03-27 13:55:
|>>> Christian Ehrlicher said the following, On 2008-03-27 10:18:
|>>>>> Von: "Jaros?aw Staniek"
|>>>>> Christian Ehrlicher said the following, On 2008-03-27 06:29:
|>>>>>> Jaros?aw Staniek schrieb:
|>>>>>>> Christian Ehrlicher said the following, On 2008-03-26 20:29:
|>>>>>>>> Jaros?aw Staniek schrieb:
|>>>>>>>>> Hi,
|>>>>>>>>> Forgot to say that before but contents of
|>>>>>>>>> kdecore/kernel/kernel_win.cpp is my code, which was originally in
|>>>>>>>>> kdelibs/win/win32_utils2.cpp (KDE3).
|>>>>>>>>> But more important is what I propose - move it to kdesupport
|>> because
|>>>>>>>>> we'll be accessing more and more windows registry in the future.
|>>>>>>>>>
|>>>>>>>> much better - remove it completly and replace it by QSettings :-)
|>>>>>>>> http://doc.trolltech.com/4.3/qsettings.html#platform-specific-notes
|>>>>>>>>
|>>>>>>> Well, good idea (that's new in Qt4); so we'd have only things like
|>>>>>>> showWin32FilePropertyDialog() in kdesupport.
|>>>>>>>
|>>>>>> So what do you want to move to kdesupport (and where?). Just this
|>> single
|>>>>>> Function?
|>>>>> Remove getWin32RegistryValue registry function, we'll probably also
|>> have
|>>>>> more
|>>>>> functions like getWin32ShellFoldersPath() in kdesupport.
|>>>>>
|>>>> As long as you only have two functions I don't see a need for an
|>> additional library in kdesupport.
|>>> We're talking about kdewin32 lib.
|>> Hm ok but then we wouldnt have access to Qt...
|>> So I am saying in kdecore (possibly with a namespace).
|>>
|> That was the point why I moved out all the c++ stuff from kdewin32 - we
shouldn't have a qt dependency in kdewin32 lib :)
| Was that fixed already? afair there was a Qt dependency in kdewin32.

Only in kdewin32/tools/, right?

- --
regards / pozdrawiam, Jaroslaw Staniek
~ Sponsored by OpenOffice Polska (http://www.openoffice.com.pl/en) to work on
~ Kexi & KOffice (http://www.kexi.pl/en, http://www.koffice.org/kexi)
~ KDE Libraries for MS Windows (http://windows.kde.org)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFH68cxXwaWqa8ZHaQRAhYQAJoDxPWwloi71B14R0xvZJM4QGDflQCfRcM8
OpSmrBvBwUaalqLwlaUzyUQ=
=Ua+V
-----END PGP SIGNATURE-----

From js at iidea.pl  Thu Mar 27 17:13:11 2008
From: js at iidea.pl (=?UTF-8?B?SmFyb3PFgmF3IFN0YW5pZWs=?=)
Date: Thu, 27 Mar 2008 17:13:11 +0100
Subject: [rfc] Windows integration utilities - KDE::Windows namespace 
Message-ID: <47EBC797.8040708@iidea.pl>


Hello,
kdecore/kernel/kkernel_win.{h|cpp} already provides some utilities useful for 
Windows integration but even if the symbols are exported, the file is not 
installed, so the functions were internal so far.

I propose to create KDE::Windows namespace, used in kdewindows.{h|cpp}.
The functions would be used not only in kdelibs (and thus
e.g. showWin32FilePropertyDialog() could be replaced by 
KDE::Windows::showFilePropertyDialog()) but also shall be provided provided 
for finer integration with the OS at applications' level.

I am attaching kdewindows.h for now, the cpp is similar to kkernel_win.cpp.

If that's reasonable for you, before applying any changes we'd need to agree 
on the location of the files, currently named as kdewindows.{h|cpp}. I propose 
kdecore/utils/, which is apparently better than kdecore/kernel/. Other 
possible location could be a new dir like kdecore/integration/.

Why not in kdesupport? kdesupport/kdewin32 is non-Qt lib, while our utils 
operate on QString (and will probably use containers too) for convenience.

RFC.
PS: I can see there's KXUtils namespace used for X11-related utils in kdeui.

-- 
regards / pozdrawiam, Jaroslaw Staniek
  Sponsored by OpenOffice Polska (http://www.openoffice.com.pl/en) to work on
  Kexi & KOffice (http://www.kexi.pl/en, http://www.koffice.org/kexi)
  KDE Libraries for MS Windows (http://windows.kde.org)
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: kdewindows.h
Url: http://mail.kde.org/pipermail/kde-windows/attachments/20080327/736a3c32/attachment.h 

From Ch.Ehrlicher at gmx.de  Thu Mar 27 17:44:05 2008
From: Ch.Ehrlicher at gmx.de (Christian Ehrlicher)
Date: Thu, 27 Mar 2008 17:44:05 +0100
Subject: Windows registry utils in kdesupport/win32
In-Reply-To: <47EBC731.2000106@iidea.pl>
References: <47EAA184.9060006@iidea.pl>	<47EAA41A.3040408@gmx.de>	<47EAC15B.2030602@iidea.pl>	<47EB30D3.5080205@gmx.de>	<47EB6141.8060908@iidea.pl>	<20080327091835.241300@gmx.net>	<47EB9929.9090207@iidea.pl>	<47EB99D9.2000007@iidea.pl>	<20080327130618.98050@gmx.net>
	<47EBC289.4070904@gmx.de> <47EBC731.2000106@iidea.pl>
Message-ID: <47EBCED5.7080806@gmx.de>

Jaros?aw Staniek schrieb:
> Patrick Spendrin said the following, On 2008-03-27 16:51:
<snip>
> |> That was the point why I moved out all the c++ stuff from kdewin32 - we
> shouldn't have a qt dependency in kdewin32 lib :)
> | Was that fixed already? afair there was a Qt dependency in kdewin32.
> 
> Only in kdewin32/tools/, right?
> 
Yes - kdewin32/tools depend on qt, but those tools are just there 
because I don't know a better place for them. And they don't affect the 
kdewin32 library.


Christian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 258 bytes
Desc: OpenPGP digital signature
Url : http://mail.kde.org/pipermail/kde-windows/attachments/20080327/3f992805/attachment.pgp 

From js at iidea.pl  Thu Mar 27 17:49:58 2008
From: js at iidea.pl (=?UTF-8?B?SmFyb3PFgmF3IFN0YW5pZWs=?=)
Date: Thu, 27 Mar 2008 17:49:58 +0100
Subject: Windows registry utils in kdesupport/win32
In-Reply-To: <47EBCED5.7080806@gmx.de>
References: <47EAA184.9060006@iidea.pl>	<47EAA41A.3040408@gmx.de>	<47EAC15B.2030602@iidea.pl>	<47EB30D3.5080205@gmx.de>	<47EB6141.8060908@iidea.pl>	<20080327091835.241300@gmx.net>	<47EB9929.9090207@iidea.pl>	<47EB99D9.2000007@iidea.pl>	<20080327130618.98050@gmx.net>	<47EBC289.4070904@gmx.de>
	<47EBC731.2000106@iidea.pl> <47EBCED5.7080806@gmx.de>
Message-ID: <47EBD036.5040304@iidea.pl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Christian Ehrlicher said the following, On 2008-03-27 17:44:
~ Jaros?aw Staniek schrieb:
|> Patrick Spendrin said the following, On 2008-03-27 16:51:
| <snip>
|> |> That was the point why I moved out all the c++ stuff from kdewin32
|> - we
|> shouldn't have a qt dependency in kdewin32 lib :)
|> | Was that fixed already? afair there was a Qt dependency in kdewin32.
|>
|> Only in kdewin32/tools/, right?
|>
| Yes - kdewin32/tools depend on qt, but those tools are just there
| because I don't know a better place for them. And they don't affect the
| kdewin32 library.
|
Yep, that's what I mean.

- --
regards / pozdrawiam, Jaroslaw Staniek
~ Sponsored by OpenOffice Polska (http://www.openoffice.com.pl/en) to work on
~ Kexi & KOffice (http://www.kexi.pl/en, http://www.koffice.org/kexi)
~ KDE Libraries for MS Windows (http://windows.kde.org)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFH69A2XwaWqa8ZHaQRApOKAKDbNWjrAR8xPvsY+ja7rWYzHEilHACeLk3c
VW+XtXQUg7sOlut267vzcfE=
=q5my
-----END PGP SIGNATURE-----

From ralf.habacker at freenet.de  Fri Mar 28 11:47:59 2008
From: ralf.habacker at freenet.de (Ralf Habacker)
Date: Fri, 28 Mar 2008 11:47:59 +0100
Subject: specialized installers
Message-ID: <47ECCCDF.4080207@freenet.de>

Hi,

Christian informed me that the amarok team asked for the possibility for 
an application specific installer. Because in the future there may 
additional projects like koffice which may like to use such a 
specialized  installer i like to give some hints about this topic:

1.There is always the way to build application specific setups using 
nsis or inno setup. The advantage is that the application 
maintainer/packager has full control about what is in the package and 
what not. The disadvantage is that the application maintainer/package is 
on his own on building every required package. Packagers could reduces 
this expense by using the already available packages from the kde 
mirrors, but then they are bound on the package release cycle

2. The qt based installer was extended to be able to handle application 
specific themes containing different icons/images/pages like shown in 
the appended screenshot for a possible amarok installer. Technical it 
would use the public available binary packages. For specialized 
installers patches are welcome.

Any comments ?

Ralf


-------------- next part --------------
A non-text attachment was scrubbed...
Name: amarok-installer.jpg
Type: image/jpeg
Size: 29065 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-windows/attachments/20080328/4125bcea/attachment-0001.jpg 

From mail at nunobrito.eu  Fri Mar 28 12:22:30 2008
From: mail at nunobrito.eu (Nuno Brito)
Date: Fri, 28 Mar 2008 10:22:30 -0100
Subject: Kde-windows Digest, Vol 30, Issue 29
In-Reply-To: <mailman.253.1206701332.5348.kde-windows@kde.org>
References: <mailman.253.1206701332.5348.kde-windows@kde.org>
Message-ID: <c6aeeb1d0803280422y25f27b34o857dfeb354b312e@mail.gmail.com>

Innosetup is a very good installer.

But how will this apply to the context of KDE?

Shouldn't it be less dependent on the mechanisms of Windows?

Imagine the restrictions for running a installer on Vista machines where UAC
is enabled or under XP/2000 with no administrative permissions.

The main advantage of the KDE project for windows (on my humble opinion) is
the independence from the restrictions imposed by windows and let users
decide what to do next.

Would be good to see KDE as self contained as possible and handle their own
installs without resorting to Add/Remove program tab from the windows
control panel.

:)


2008/3/28, kde-windows-request at kde.org <kde-windows-request at kde.org>:
>
> Send Kde-windows mailing list submissions to
>         kde-windows at kde.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://mail.kde.org/mailman/listinfo/kde-windows
> or, via email, send a message with subject or body 'help' to
>         kde-windows-request at kde.org
>
> You can reach the person managing the list at
>         kde-windows-owner at kde.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Kde-windows digest..."
>
>
> Today's Topics:
>
>    1. specialized installers (Ralf Habacker)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 28 Mar 2008 11:47:59 +0100
> From: Ralf Habacker <ralf.habacker at freenet.de>
> Subject: specialized installers
> To: KDE on Windows <kde-windows at kde.org>
> Message-ID: <47ECCCDF.4080207 at freenet.de>
> Content-Type: text/plain; charset="iso-8859-15"
>
> Hi,
>
> Christian informed me that the amarok team asked for the possibility for
> an application specific installer. Because in the future there may
> additional projects like koffice which may like to use such a
> specialized  installer i like to give some hints about this topic:
>
> 1.There is always the way to build application specific setups using
> nsis or inno setup. The advantage is that the application
> maintainer/packager has full control about what is in the package and
> what not. The disadvantage is that the application maintainer/package is
> on his own on building every required package. Packagers could reduces
> this expense by using the already available packages from the kde
> mirrors, but then they are bound on the package release cycle
>
> 2. The qt based installer was extended to be able to handle application
> specific themes containing different icons/images/pages like shown in
> the appended screenshot for a possible amarok installer. Technical it
> would use the public available binary packages. For specialized
> installers patches are welcome.
>
> Any comments ?
>
> Ralf
>
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: amarok-installer.jpg
> Type: image/jpeg
> Size: 29065 bytes
> Desc: not available
> Url :
> http://mail.kde.org/pipermail/kde-windows/attachments/20080328/4125bcea/attachment.jpg
>
> ------------------------------
>
> _______________________________________________
> Kde-windows mailing list
> Kde-windows at kde.org
> https://mail.kde.org/mailman/listinfo/kde-windows
>
>
> End of Kde-windows Digest, Vol 30, Issue 29
> *******************************************
>



-- 
Nuno Brito
http://nunobrito.eu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kde-windows/attachments/20080328/c97a9fc7/attachment.html 

From js at iidea.pl  Fri Mar 28 12:44:29 2008
From: js at iidea.pl (=?ISO-8859-1?Q?Jaros=3Faw_Staniek?=)
Date: Fri, 28 Mar 2008 12:44:29 +0100
Subject: specialized installers
In-Reply-To: <c6aeeb1d0803280422y25f27b34o857dfeb354b312e@mail.gmail.com>
References: <mailman.253.1206701332.5348.kde-windows@kde.org>
	<c6aeeb1d0803280422y25f27b34o857dfeb354b312e@mail.gmail.com>
Message-ID: <47ECDA1D.7080103@iidea.pl>

Nuno Brito said the following, On 2008-03-28 12:22:
> Innosetup is a very good installer.
> 
> But how will this apply to the context of KDE?
> 
> Shouldn't it be less dependent on the mechanisms of Windows?
> 
> Imagine the restrictions for running a installer on Vista machines where UAC
> is enabled or under XP/2000 with no administrative permissions.
> 
> The main advantage of the KDE project for windows (on my humble opinion) is
> the independence from the restrictions imposed by windows and let users
> decide what to do next.

I consider NSIS and Innosetup (rather) only as temporary solution for anyone 
who wants to play with them. We indeed want and have more and more control 
over our installation processes and that is good.

That said, of course we won't have equally lightweight installers for 
particular apps as long as we use Qt, but we do value ease of maintenance and 
quality, right?
Moreover (that was probably already mentioned), what a problem with extra 2MB 
if a number of gfx card drivers' installers contain 20MB+ of additional 
garbage? ;)

As a side note: note however, that some enterprises have policy of only 
allowing .msi installers in their environments...

Again, Ralf and Christian, kudos for your work on the installer(s)!

> Would be good to see KDE as self contained as possible and handle their own
> installs without resorting to Add/Remove program tab from the windows
> control panel.

Yes, putting every application (or rather module like amarok or koffice) in 
the add/remove list would be indeed an overkill. Note how much this list is 
broken under Vista (every important KB fix is mentioned there), and I guess on 
XPSP2 too.
So we can have our subsystem and just keep "KDE icon" in the control panel.
Optionally we can have one add/remove entry called "K Desktop Environment - 
Add/remove programs" or so.

just my 2 cents

-- 
regards / pozdrawiam, Jaroslaw Staniek
  Sponsored by OpenOffice Polska (http://www.openoffice.com.pl/en) to work on
  Kexi & KOffice (http://www.kexi.pl/en, http://www.koffice.org/kexi)
  KDE Libraries for MS Windows (http://windows.kde.org)

From ralf.habacker at freenet.de  Fri Mar 28 13:14:56 2008
From: ralf.habacker at freenet.de (Ralf Habacker)
Date: Fri, 28 Mar 2008 13:14:56 +0100
Subject: specialized installers
In-Reply-To: <47ECDA1D.7080103@iidea.pl>
References: <mailman.253.1206701332.5348.kde-windows@kde.org>	<c6aeeb1d0803280422y25f27b34o857dfeb354b312e@mail.gmail.com>
	<47ECDA1D.7080103@iidea.pl>
Message-ID: <47ECE140.8070402@freenet.de>

Jaros?aw Staniek schrieb:
> Nuno Brito said the following, On 2008-03-28 12:22:
>   
>> Innosetup is a very good installer.
>>
>> But how will this apply to the context of KDE?
>>
>> Shouldn't it be less dependent on the mechanisms of Windows?
>>
>> Imagine the restrictions for running a installer on Vista machines where UAC
>> is enabled or under XP/2000 with no administrative permissions.
>>
>> The main advantage of the KDE project for windows (on my humble opinion) is
>> the independence from the restrictions imposed by windows and let users
>> decide what to do next.
>>     
>
> I consider NSIS and Innosetup (rather) only as temporary solution for anyone 
> who wants to play with them. We indeed want and have more and more control 
> over our installation processes and that is good.
>
> That said, of course we won't have equally lightweight installers for 
> particular apps as long as we use Qt, but we do value ease of maintenance and 
> quality, right?
> Moreover (that was probably already mentioned), what a problem with extra 2MB 
> if a number of gfx card drivers' installers contain 20MB+ of additional 
> garbage? ;)
>   
there is no problem i think additional compared to the size of the whole 
kde installation the 2MB of the installer are irrelevant ;)
> As a side note: note however, that some enterprises have policy of only 
> allowing .msi installers in their environments...
>   
Applications on windows more and more supports self contained 
updaters/installers like Acrobat Reader, Apple Quicktime and others 
independently from the Microsoft Windows Installer, they only use an 
initial msi package. To fit this need there could be one msi package 
which installs the kde installer and the software control panel entries 
you mentioned below.
> Again, Ralf and Christian, kudos for your work on the installer(s)!
>
>   
>> Would be good to see KDE as self contained as possible and handle their own
>> installs without resorting to Add/Remove program tab from the windows
>> control panel.
>>     
>
> Yes, putting every application (or rather module like amarok or koffice) in 
> the add/remove list would be indeed an overkill. Note how much this list is 
> broken under Vista (every important KB fix is mentioned there), and I guess on 
> XPSP2 too.
> So we can have our subsystem and just keep "KDE icon" in the control panel.
> Optionally we can have one add/remove entry called "K Desktop Environment - 
> Add/remove programs" or so.
>   
I add this to the installer todo list.

Thanks for this pointers.

Ralf

From js at iidea.pl  Fri Mar 28 19:16:21 2008
From: js at iidea.pl (=?UTF-8?B?SmFyb3PFgmF3IFN0YW5pZWs=?=)
Date: Fri, 28 Mar 2008 19:16:21 +0100
Subject: Hint: cs and cb commands on Windows
Message-ID: <47ED35F5.9010602@iidea.pl>


The command prompt is not as flexible but at least I have two batch commands 
(attached).

1. I use

cb kdelibs

to move to kdelibs bianary directory, e.g. to quickly type nmake install 
somewhere. In my case it moves to 
c:\kde4\tmp\kdelibs-20080202\work\msvc2005-Debug.

That's for msvc, and assuming your builddir is %KDEROOT%\tmp.
So you may want to alter this.


2. I use

cs kdelibs

to move to kdelibs source directory.


-- 
regards / pozdrawiam, Jaroslaw Staniek
  Sponsored by OpenOffice Polska (http://www.openoffice.com.pl/en) to work on
  Kexi & KOffice (http://www.kexi.pl/en, http://www.koffice.org/kexi)
  KDE Libraries for MS Windows (http://windows.kde.org)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cb_cs.zip
Type: application/zip
Size: 269 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-windows/attachments/20080328/0e23c443/attachment.zip 

From js at iidea.pl  Fri Mar 28 22:07:39 2008
From: js at iidea.pl (Jaroslaw Staniek)
Date: Fri, 28 Mar 2008 22:07:39 +0100
Subject: KProcess, KRun, KShell, KMacroExpander, their abuse, windows
	and   security holes
In-Reply-To: <20080316214030.GA12666@ugly.local>
References: <20080316214030.GA12666@ugly.local>
Message-ID: <47ED5E1B.9030407@iidea.pl>

Oswald Buddenhagen said the following, On 2008-03-16 22:40:

> first of all, a rant: i did a grep on KShell::quoteArg ... the number of
> hits is amazing. and 90+% indicate unnecessary use of a shell.
> the top three reasons *not* to go through a shell:
>   - it is not portable
>   - it is slow
>   - you risk security holes (if you get the argument quoting wrong) -
>     remember that delayed release some years ago?
> so if your code contains any of these:
>   - system()
>   - popen()
>   - KProcess::setShellCommand() or K3Process::setUseShell(true)
> you are likely to be doing something wrong. please review and fix any
> code that you maintain.
> on a related note, KMacroExpander::expandMacrosShellQuote() and
> KShell::splitArgs() are still under-used, leading to lots of duplicated
> (and usually not particularly robust) code. but see below.
> 
> 
> now to the broader topic ... starting subprocesses and supplying
> arguments to them. for now only unix ...
> 
> - the basic and usually only correct way to start a process is by using
>   KProcess (without resorting to setShellCommand). you can run processes
>   synchronously, asynchronously or completely detached, supply a working
>   dir, make redirections, chain processes and deal with their i/o.
> 
> - if you have the user supply file names, you might want to run them
>   through KShell::tildeExpand() prior to passing them to the process.
>   but KFileDialog already handles this internally, so usually there is
>   no need to bother with it (and expanding strings that are not meant to
>   be would be potentially harmful, anyway).
> 
> - then there is KShell::splitArgs() (used without AbortOnMeta). it
>   performs word-splitting according to somewhat simplified bash rules.
>   the result is usually fed into a KProcess.
>   meanwhile it is even somewhat popular.
>   but one has to wonder what it is actually used for - why would anyone
>   supply something that resembles a shell command, but is none?
> 
> - then exists the possibility to run a complete command through a shell
>   via KProcess::setShellCommand().
> 
>   - if you use KShell::quoteArg() or KShell::joinArgs() to construct a
>     command line, you should reconsider - see above.
> 
>   - a generally justified use of the shell are user-supplied command
>     lines. often such a command line is filtered through
>     KMacroExpander::expandMacrosShellQuote() prior to passing it to
>     KProcess to replace any expandos in the command.
> 
>   - a somewhat fancy way to execute a shell command is
>     KRun::runCommand()
> 
>   - a fairly efficient way to execute a shell command is using
>     KShell::splitArgs() with the AbortOnMeta flag - if it can be parsed
>     according to the simplified bash rules, it can be run directly,
>     otherwise it needs to be run through the shell.
>     KRun does that internally.
> 
> now comes into play this bloody braindead waste of time that is called
> windows. it pretty much screws us over with everything that actually
> requires using a shell. the gory details are explained in
> http://lists.kde.org/?l=kde-windows&m=119159232432366&w=2
> 
> as a consequence i suggest the following course of action:
> 
> - i would build the KShell::splitArgs() with AbortOnMeta magic from KRun
>   directly into KProcess::setShellCommand(). on unix, a flag to bypass
>   this automagic would exist. on windows, it would simply refuse to
>   run anything too complex - users can be expected to use batch files for
>   complex constructs anyway.
>   to KRun::runCommand() the same would apply.
> 
> - KShell::splitArgs() would disappear from the public api on windows. on
>   unix, its use should be limited. it would be mostly obsoleted by the
>   previous point anyway.
> 
> - any code that uses KShell::quoteArg() or KShell::joinArgs() is likely
>   to be either bogus or inherently platform-dependend. i think it
>   should be made unix-only again.
> 
> - KMacroExpander::expandMacrosShellQuote() would be safe only as far as
>   the improved KProcess::setShellCommand() goes.
> 
> anything i did not consider?

I can only say that the fact that bool 
KMacroExpanderBase::expandMacrosShellQuote( QString &str,
int &pos ) just fails on Windows makes KRun::processDesktopExec() failing too, 
what in turn breaks opening in my KMail :).

On windows it's true that 99.(9)% of use cases for symbol expanding is 
"<command> %f" call, what's indeed the pattern used so often in the windows 
registry.

-- 
regards / pozdrawiam, Jaroslaw Staniek
  Sponsored by OpenOffice Polska (http://www.openoffice.com.pl/en) to work on
  Kexi & KOffice (http://www.kexi.pl/en, http://www.koffice.org/kexi)
  KDE Libraries for MS Windows (http://windows.kde.org)

From mail at nunobrito.eu  Sat Mar 29 16:26:39 2008
From: mail at nunobrito.eu (Nuno Brito)
Date: Sat, 29 Mar 2008 14:26:39 -0100
Subject: Kde-windows Digest, Vol 30, Issue 30
In-Reply-To: <mailman.41.1206788421.25600.kde-windows@kde.org>
References: <mailman.41.1206788421.25600.kde-windows@kde.org>
Message-ID: <c6aeeb1d0803290826g5ef5d222gb197cce69b905711@mail.gmail.com>

Hi again,

A generic KDE installer to later organize all kde specific apps is a good
idea to keep things under control.

Regarding the KDE installer:
I've been trying to make a portable kde to carry around on my pendisk and
showcase to a few work friends but copying the binaries and running on
another machine won't work.

Do I need to install any Qt related service or add any registry keys to
carry the kde base folder to somewhere else?


------




2008/3/29, kde-windows-request at kde.org <kde-windows-request at kde.org>:
>
> Send Kde-windows mailing list submissions to
>         kde-windows at kde.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://mail.kde.org/mailman/listinfo/kde-windows
> or, via email, send a message with subject or body 'help' to
>         kde-windows-request at kde.org
>
> You can reach the person managing the list at
>         kde-windows-owner at kde.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Kde-windows digest..."
>
>
> Today's Topics:
>
>    1. Re: Kde-windows Digest, Vol 30, Issue 29 (Nuno Brito)
>    2. Re: specialized installers (Jaros?aw Staniek)
>    3. Re: specialized installers (Ralf Habacker)
>    4. Hint: cs and cb commands on Windows (Jaros?aw Staniek)
>    5. Re: KProcess, KRun, KShell, KMacroExpander, their abuse,
>       windows   and   security holes (Jaroslaw Staniek)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 28 Mar 2008 10:22:30 -0100
> From: "Nuno Brito" <mail at nunobrito.eu>
> Subject: Re: Kde-windows Digest, Vol 30, Issue 29
> To: kde-windows at kde.org
> Message-ID:
>         <c6aeeb1d0803280422y25f27b34o857dfeb354b312e at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Innosetup is a very good installer.
>
> But how will this apply to the context of KDE?
>
> Shouldn't it be less dependent on the mechanisms of Windows?
>
> Imagine the restrictions for running a installer on Vista machines where
> UAC
> is enabled or under XP/2000 with no administrative permissions.
>
> The main advantage of the KDE project for windows (on my humble opinion)
> is
> the independence from the restrictions imposed by windows and let users
> decide what to do next.
>
> Would be good to see KDE as self contained as possible and handle their
> own
> installs without resorting to Add/Remove program tab from the windows
> control panel.
>
> :)
>
>
> 2008/3/28, kde-windows-request at kde.org <kde-windows-request at kde.org>:
> >
> > Send Kde-windows mailing list submissions to
> >         kde-windows at kde.org
> >
> > To subscribe or unsubscribe via the World Wide Web, visit
> >         https://mail.kde.org/mailman/listinfo/kde-windows
> > or, via email, send a message with subject or body 'help' to
> >         kde-windows-request at kde.org
> >
> > You can reach the person managing the list at
> >         kde-windows-owner at kde.org
> >
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of Kde-windows digest..."
> >
> >
> > Today's Topics:
> >
> >    1. specialized installers (Ralf Habacker)
> >
> >
> > ----------------------------------------------------------------------
> >
> > Message: 1
> > Date: Fri, 28 Mar 2008 11:47:59 +0100
> > From: Ralf Habacker <ralf.habacker at freenet.de>
> > Subject: specialized installers
> > To: KDE on Windows <kde-windows at kde.org>
> > Message-ID: <47ECCCDF.4080207 at freenet.de>
> > Content-Type: text/plain; charset="iso-8859-15"
> >
> > Hi,
> >
> > Christian informed me that the amarok team asked for the possibility for
> > an application specific installer. Because in the future there may
> > additional projects like koffice which may like to use such a
> > specialized  installer i like to give some hints about this topic:
> >
> > 1.There is always the way to build application specific setups using
> > nsis or inno setup. The advantage is that the application
> > maintainer/packager has full control about what is in the package and
> > what not. The disadvantage is that the application maintainer/package is
> > on his own on building every required package. Packagers could reduces
> > this expense by using the already available packages from the kde
> > mirrors, but then they are bound on the package release cycle
> >
> > 2. The qt based installer was extended to be able to handle application
> > specific themes containing different icons/images/pages like shown in
> > the appended screenshot for a possible amarok installer. Technical it
> > would use the public available binary packages. For specialized
> > installers patches are welcome.
> >
> > Any comments ?
> >
> > Ralf
> >
> >
> > -------------- next part --------------
> > A non-text attachment was scrubbed...
> > Name: amarok-installer.jpg
> > Type: image/jpeg
> > Size: 29065 bytes
> > Desc: not available
> > Url :
> >
> http://mail.kde.org/pipermail/kde-windows/attachments/20080328/4125bcea/attachment.jpg
> >
> > ------------------------------
> >
> > _______________________________________________
> > Kde-windows mailing list
> > Kde-windows at kde.org
> > https://mail.kde.org/mailman/listinfo/kde-windows
> >
> >
> > End of Kde-windows Digest, Vol 30, Issue 29
> > *******************************************
> >
>
>
>
> --
> Nuno Brito
> http://nunobrito.eu
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://mail.kde.org/pipermail/kde-windows/attachments/20080328/c97a9fc7/attachment-0001.html
>
> ------------------------------
>
> Message: 2
> Date: Fri, 28 Mar 2008 12:44:29 +0100
> From: Jaros?aw Staniek <js at iidea.pl>
> Subject: Re: specialized installers
> To: KDE on Windows <kde-windows at kde.org>
> Message-ID: <47ECDA1D.7080103 at iidea.pl>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Nuno Brito said the following, On 2008-03-28 12:22:
> > Innosetup is a very good installer.
> >
> > But how will this apply to the context of KDE?
> >
> > Shouldn't it be less dependent on the mechanisms of Windows?
> >
> > Imagine the restrictions for running a installer on Vista machines where
> UAC
> > is enabled or under XP/2000 with no administrative permissions.
> >
> > The main advantage of the KDE project for windows (on my humble opinion)
> is
> > the independence from the restrictions imposed by windows and let users
> > decide what to do next.
>
> I consider NSIS and Innosetup (rather) only as temporary solution for
> anyone
> who wants to play with them. We indeed want and have more and more control
> over our installation processes and that is good.
>
> That said, of course we won't have equally lightweight installers for
> particular apps as long as we use Qt, but we do value ease of maintenance
> and
> quality, right?
> Moreover (that was probably already mentioned), what a problem with extra
> 2MB
> if a number of gfx card drivers' installers contain 20MB+ of additional
> garbage? ;)
>
> As a side note: note however, that some enterprises have policy of only
> allowing .msi installers in their environments...
>
> Again, Ralf and Christian, kudos for your work on the installer(s)!
>
> > Would be good to see KDE as self contained as possible and handle their
> own
> > installs without resorting to Add/Remove program tab from the windows
> > control panel.
>
> Yes, putting every application (or rather module like amarok or koffice)
> in
> the add/remove list would be indeed an overkill. Note how much this list
> is
> broken under Vista (every important KB fix is mentioned there), and I
> guess on
> XPSP2 too.
> So we can have our subsystem and just keep "KDE icon" in the control
> panel.
> Optionally we can have one add/remove entry called "K Desktop Environment
> -
> Add/remove programs" or so.
>
> just my 2 cents
>
> --
> regards / pozdrawiam, Jaroslaw Staniek
>   Sponsored by OpenOffice Polska (http://www.openoffice.com.pl/en) to work
> on
>   Kexi & KOffice (http://www.kexi.pl/en, http://www.koffice.org/kexi)
>   KDE Libraries for MS Windows (http://windows.kde.org)
>
>
> ------------------------------
>
> Message: 3
> Date: Fri, 28 Mar 2008 13:14:56 +0100
> From: Ralf Habacker <ralf.habacker at freenet.de>
> Subject: Re: specialized installers
> To: KDE on Windows <kde-windows at kde.org>
> Message-ID: <47ECE140.8070402 at freenet.de>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Jaros?aw Staniek schrieb:
> > Nuno Brito said the following, On 2008-03-28 12:22:
> >
> >> Innosetup is a very good installer.
> >>
> >> But how will this apply to the context of KDE?
> >>
> >> Shouldn't it be less dependent on the mechanisms of Windows?
> >>
> >> Imagine the restrictions for running a installer on Vista machines
> where UAC
> >> is enabled or under XP/2000 with no administrative permissions.
> >>
> >> The main advantage of the KDE project for windows (on my humble
> opinion) is
> >> the independence from the restrictions imposed by windows and let users
> >> decide what to do next.
> >>
> >
> > I consider NSIS and Innosetup (rather) only as temporary solution for
> anyone
> > who wants to play with them. We indeed want and have more and more
> control
> > over our installation processes and that is good.
> >
> > That said, of course we won't have equally lightweight installers for
> > particular apps as long as we use Qt, but we do value ease of
> maintenance and
> > quality, right?
> > Moreover (that was probably already mentioned), what a problem with
> extra 2MB
> > if a number of gfx card drivers' installers contain 20MB+ of additional
> > garbage? ;)
> >
> there is no problem i think additional compared to the size of the whole
> kde installation the 2MB of the installer are irrelevant ;)
> > As a side note: note however, that some enterprises have policy of only
> > allowing .msi installers in their environments...
> >
> Applications on windows more and more supports self contained
> updaters/installers like Acrobat Reader, Apple Quicktime and others
> independently from the Microsoft Windows Installer, they only use an
> initial msi package. To fit this need there could be one msi package
> which installs the kde installer and the software control panel entries
> you mentioned below.
> > Again, Ralf and Christian, kudos for your work on the installer(s)!
> >
> >
> >> Would be good to see KDE as self contained as possible and handle their
> own
> >> installs without resorting to Add/Remove program tab from the windows
> >> control panel.
> >>
> >
> > Yes, putting every application (or rather module like amarok or koffice)
> in
> > the add/remove list would be indeed an overkill. Note how much this list
> is
> > broken under Vista (every important KB fix is mentioned there), and I
> guess on
> > XPSP2 too.
> > So we can have our subsystem and just keep "KDE icon" in the control
> panel.
> > Optionally we can have one add/remove entry called "K Desktop
> Environment -
> > Add/remove programs" or so.
> >
> I add this to the installer todo list.
>
> Thanks for this pointers.
>
> Ralf
>
>
> ------------------------------
>
> Message: 4
> Date: Fri, 28 Mar 2008 19:16:21 +0100
> From: Jaros?aw Staniek <js at iidea.pl>
> Subject: Hint: cs and cb commands on Windows
> To: KDE on Windows <kde-windows at kde.org>
> Message-ID: <47ED35F5.9010602 at iidea.pl>
> Content-Type: text/plain; charset="utf-8"
>
>
> The command prompt is not as flexible but at least I have two batch
> commands
> (attached).
>
> 1. I use
>
> cb kdelibs
>
> to move to kdelibs bianary directory, e.g. to quickly type nmake install
> somewhere. In my case it moves to
> c:\kde4\tmp\kdelibs-20080202\work\msvc2005-Debug.
>
> That's for msvc, and assuming your builddir is %KDEROOT%\tmp.
> So you may want to alter this.
>
>
> 2. I use
>
> cs kdelibs
>
> to move to kdelibs source directory.
>
>
> --
> regards / pozdrawiam, Jaroslaw Staniek
>   Sponsored by OpenOffice Polska (http://www.openoffice.com.pl/en) to work
> on
>   Kexi & KOffice (http://www.kexi.pl/en, http://www.koffice.org/kexi)
>   KDE Libraries for MS Windows (http://windows.kde.org)
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: cb_cs.zip
> Type: application/zip
> Size: 269 bytes
> Desc: not available
> Url :
> http://mail.kde.org/pipermail/kde-windows/attachments/20080328/0e23c443/attachment-0001.zip
>
> ------------------------------
>
> Message: 5
> Date: Fri, 28 Mar 2008 22:07:39 +0100
> From: Jaroslaw Staniek <js at iidea.pl>
> Subject: Re: KProcess, KRun, KShell, KMacroExpander, their abuse,
>         windows and   security holes
> To: kde-core-devel at kde.org
> Cc: KDE on Windows <kde-windows at kde.org>
> Message-ID: <47ED5E1B.9030407 at iidea.pl>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Oswald Buddenhagen said the following, On 2008-03-16 22:40:
>
> > first of all, a rant: i did a grep on KShell::quoteArg ... the number of
> > hits is amazing. and 90+% indicate unnecessary use of a shell.
> > the top three reasons *not* to go through a shell:
> >   - it is not portable
> >   - it is slow
> >   - you risk security holes (if you get the argument quoting wrong) -
> >     remember that delayed release some years ago?
> > so if your code contains any of these:
> >   - system()
> >   - popen()
> >   - KProcess::setShellCommand() or K3Process::setUseShell(true)
> > you are likely to be doing something wrong. please review and fix any
> > code that you maintain.
> > on a related note, KMacroExpander::expandMacrosShellQuote() and
> > KShell::splitArgs() are still under-used, leading to lots of duplicated
> > (and usually not particularly robust) code. but see below.
> >
> >
> > now to the broader topic ... starting subprocesses and supplying
> > arguments to them. for now only unix ...
> >
> > - the basic and usually only correct way to start a process is by using
> >   KProcess (without resorting to setShellCommand). you can run processes
> >   synchronously, asynchronously or completely detached, supply a working
> >   dir, make redirections, chain processes and deal with their i/o.
> >
> > - if you have the user supply file names, you might want to run them
> >   through KShell::tildeExpand() prior to passing them to the process.
> >   but KFileDialog already handles this internally, so usually there is
> >   no need to bother with it (and expanding strings that are not meant to
> >   be would be potentially harmful, anyway).
> >
> > - then there is KShell::splitArgs() (used without AbortOnMeta). it
> >   performs word-splitting according to somewhat simplified bash rules.
> >   the result is usually fed into a KProcess.
> >   meanwhile it is even somewhat popular.
> >   but one has to wonder what it is actually used for - why would anyone
> >   supply something that resembles a shell command, but is none?
> >
> > - then exists the possibility to run a complete command through a shell
> >   via KProcess::setShellCommand().
> >
> >   - if you use KShell::quoteArg() or KShell::joinArgs() to construct a
> >     command line, you should reconsider - see above.
> >
> >   - a generally justified use of the shell are user-supplied command
> >     lines. often such a command line is filtered through
> >     KMacroExpander::expandMacrosShellQuote() prior to passing it to
> >     KProcess to replace any expandos in the command.
> >
> >   - a somewhat fancy way to execute a shell command is
> >     KRun::runCommand()
> >
> >   - a fairly efficient way to execute a shell command is using
> >     KShell::splitArgs() with the AbortOnMeta flag - if it can be parsed
> >     according to the simplified bash rules, it can be run directly,
> >     otherwise it needs to be run through the shell.
> >     KRun does that internally.
> >
> > now comes into play this bloody braindead waste of time that is called
> > windows. it pretty much screws us over with everything that actually
> > requires using a shell. the gory details are explained in
> > http://lists.kde.org/?l=kde-windows&m=119159232432366&w=2
> >
> > as a consequence i suggest the following course of action:
> >
> > - i would build the KShell::splitArgs() with AbortOnMeta magic from KRun
> >   directly into KProcess::setShellCommand(). on unix, a flag to bypass
> >   this automagic would exist. on windows, it would simply refuse to
> >   run anything too complex - users can be expected to use batch files
> for
> >   complex constructs anyway.
> >   to KRun::runCommand() the same would apply.
> >
> > - KShell::splitArgs() would disappear from the public api on windows. on
> >   unix, its use should be limited. it would be mostly obsoleted by the
> >   previous point anyway.
> >
> > - any code that uses KShell::quoteArg() or KShell::joinArgs() is likely
> >   to be either bogus or inherently platform-dependend. i think it
> >   should be made unix-only again.
> >
> > - KMacroExpander::expandMacrosShellQuote() would be safe only as far as
> >   the improved KProcess::setShellCommand() goes.
> >
> > anything i did not consider?
>
> I can only say that the fact that bool
> KMacroExpanderBase::expandMacrosShellQuote( QString &str,
> int &pos ) just fails on Windows makes KRun::processDesktopExec() failing
> too,
> what in turn breaks opening in my KMail :).
>
> On windows it's true that 99.(9)% of use cases for symbol expanding is
> "<command> %f" call, what's indeed the pattern used so often in the
> windows
> registry.
>
> --
> regards / pozdrawiam, Jaroslaw Staniek
>   Sponsored by OpenOffice Polska (http://www.openoffice.com.pl/en) to work
> on
>   Kexi & KOffice (http://www.kexi.pl/en, http://www.koffice.org/kexi)
>   KDE Libraries for MS Windows (http://windows.kde.org)
>
>
> ------------------------------
>
> _______________________________________________
> Kde-windows mailing list
> Kde-windows at kde.org
> https://mail.kde.org/mailman/listinfo/kde-windows
>
>
> End of Kde-windows Digest, Vol 30, Issue 30
> *******************************************
>



-- 
Nuno Brito
http://nunobrito.eu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kde-windows/attachments/20080329/3598b66b/attachment-0001.html 

From ralf.habacker at freenet.de  Sat Mar 29 18:58:43 2008
From: ralf.habacker at freenet.de (Ralf Habacker)
Date: Sat, 29 Mar 2008 18:58:43 +0100
Subject: Kde-windows Digest, Vol 30, Issue 30
In-Reply-To: <c6aeeb1d0803290826g5ef5d222gb197cce69b905711@mail.gmail.com>
References: <mailman.41.1206788421.25600.kde-windows@kde.org>
	<c6aeeb1d0803290826g5ef5d222gb197cce69b905711@mail.gmail.com>
Message-ID: <47EE8353.4090104@freenet.de>

Nuno Brito schrieb:
> Hi again,
>
> A generic KDE installer to later organize all kde specific apps is a 
> good idea to keep things under control.
>
> Regarding the KDE installer:
> I've been trying to make a portable kde to carry around on my pendisk 
> and showcase to a few work friends but copying the binaries and 
> running on another machine won't work.
>
> Do I need to install any Qt related service or add any registry keys 
> to carry the kde base folder to somewhere else?
no, we are trying hard to avoid such dependencies. You should run 
kbuildsycoca4 on the new machine.

Ralf


From js at iidea.pl  Sun Mar 30 01:06:34 2008
From: js at iidea.pl (Jaroslaw Staniek)
Date: Sun, 30 Mar 2008 01:06:34 +0100
Subject: Kde-windows Digest, Vol 30, Issue 30
In-Reply-To: <47EE8353.4090104@freenet.de>
References: <mailman.41.1206788421.25600.kde-windows@kde.org>	<c6aeeb1d0803290826g5ef5d222gb197cce69b905711@mail.gmail.com>
	<47EE8353.4090104@freenet.de>
Message-ID: <47EED98A.7050900@iidea.pl>

Ralf Habacker said the following, On 2008-03-29 18:58:

>> Do I need to install any Qt related service or add any registry keys 
>> to carry the kde base folder to somewhere else?

> no, we are trying hard to avoid such dependencies. You should run 
> kbuildsycoca4 on the new machine.

Ah Ralf: I've recently read kbuildsycoca.cpp code a bit (again) and there are 
magic stamps like one for language, another for creation time

    // Write KDEDIRS
    (*m_str) << KGlobal::dirs()->kfsstnd_prefixes();
    (*m_str) << newTimestamp;
    (*m_str) << KGlobal::locale()->language();
    (*m_str) << KGlobal::dirs()->calcResourceHash("services", "update_ksycoca",
                                                  KStandardDirs::Recursive );

So any idea why kbuildsycoca could not automatically re-run when we move our 
binaries from machine to machine (when e.g. drive letter changes)?

-- 
regards / pozdrawiam, Jaroslaw Staniek
  Sponsored by OpenOffice Polska (http://www.openoffice.com.pl/en) to work on
  Kexi & KOffice (http://www.kexi.pl/en, http://www.koffice.org/kexi)
  KDE Libraries for MS Windows (http://windows.kde.org)

From js at iidea.pl  Mon Mar 31 10:06:40 2008
From: js at iidea.pl (Jaroslaw Staniek)
Date: Mon, 31 Mar 2008 10:06:40 +0200
Subject: Lack of meaningful title
In-Reply-To: <c6aeeb1d0803290826g5ef5d222gb197cce69b905711@mail.gmail.com>
References: <mailman.41.1206788421.25600.kde-windows@kde.org>
	<c6aeeb1d0803290826g5ef5d222gb197cce69b905711@mail.gmail.com>
Message-ID: <47F09B90.40200@iidea.pl>


Nuno, could you please take a minute and use more meaningful message title 
than a "Digest"?

-- 
regards / pozdrawiam, Jaroslaw Staniek
  Sponsored by OpenOffice Polska (http://www.openoffice.com.pl/en) to work on
  Kexi & KOffice (http://www.kexi.pl/en, http://www.koffice.org/kexi)
  KDE Libraries for MS Windows (http://windows.kde.org)

From ralf.habacker at freenet.de  Mon Mar 31 12:20:22 2008
From: ralf.habacker at freenet.de (Ralf Habacker)
Date: Mon, 31 Mar 2008 12:20:22 +0200
Subject: Kde-windows Digest, Vol 30, Issue 30
In-Reply-To: <47EED98A.7050900@iidea.pl>
References: <mailman.41.1206788421.25600.kde-windows@kde.org>	<c6aeeb1d0803290826g5ef5d222gb197cce69b905711@mail.gmail.com>	<47EE8353.4090104@freenet.de>
	<47EED98A.7050900@iidea.pl>
Message-ID: <47F0BAE6.4030702@freenet.de>

Jaroslaw Staniek schrieb:
> Ralf Habacker said the following, On 2008-03-29 18:58:
>
>   
>>> Do I need to install any Qt related service or add any registry keys 
>>> to carry the kde base folder to somewhere else?
>>>       
>
>   
>> no, we are trying hard to avoid such dependencies. You should run 
>> kbuildsycoca4 on the new machine.
>>     
>
> Ah Ralf: I've recently read kbuildsycoca.cpp code a bit (again) and there are 
> magic stamps like one for language, another for creation time
>
>     // Write KDEDIRS
>     (*m_str) << KGlobal::dirs()->kfsstnd_prefixes();
>     (*m_str) << newTimestamp;
>     (*m_str) << KGlobal::locale()->language();
>     (*m_str) << KGlobal::dirs()->calcResourceHash("services", "update_ksycoca",
>                                                   KStandardDirs::Recursive );
>
> So any idea why kbuildsycoca could not automatically re-run when we move our 
> binaries from machine to machine (when e.g. drive letter changes)?
>   

let us take first the possible cases (assuming there are computer A and B):

1. installation is moved to computer B the first time -> ksycoca 
database is not present -> will be created

2. installation will be moved back to A mounted under the same drive 
letter as before -> kbuildsycoca will update database on kded start

3. installation will be replugged in to A mounted under a different 
drive letter as before -> kbuildsycoca will only update database on kded 
start

4. installation will be moved again to B mounted under the same drive 
letter as before -> kbuildsycoca will only update database on kded start

5. installation will be moved back to A and mounted under a different 
drive letter as before -> kbuildsycoca will only update database on kded 
start

6. installation will be moved again to B mounted under a different drive 
letter as before -> kbuildsycoca will only update database on kded start

-> The important question in case 3, 5. and 6. is: Will kbuildsycoca 
detect a changed drive letter ?

As far as I can see in the kbuildsycoca code this case isn't catched - 
the only cases which are catched are

1. changes in configuration files
2. language changes
3. the presence of a file share/kde4/services/update_ksycoca in the kde 
install or home dir

Fortunally in the database there is the result stored of 
KGlobal::dirs()->kfsstnd_prefixes() stored which is KDEDIRS.

Appended is a patch which checks if the used home and install 
directories has changed and triggers a complete recreated of the 
database.  Can anyone check this patch ?

Ralf




-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: kbuildsycoca-path-change-update.patch
Url: http://mail.kde.org/pipermail/kde-windows/attachments/20080331/d77ce03b/attachment.ksh 

From ralf.habacker at freenet.de  Mon Mar 31 12:44:50 2008
From: ralf.habacker at freenet.de (Ralf Habacker)
Date: Mon, 31 Mar 2008 12:44:50 +0200
Subject: Internationalization problem with application categories
Message-ID: <47F0C0A2.40108@freenet.de>

Hi,

the settings kioslave in the application mode provides a list of 
available applications in structured in multi level categories. This is 
used for example in konqueror when selecting the "application" link on 
the start page.  The start page and application entries are printed in 
the selected language, the categories does not have language support, 
they are displayed in english only.

As far as I can see comes the categories from the related desktop files 
for example does  kalgebra.desktop define the following

Categories=Qt;KDE;Education;Math;

Unfortunally I could not found any language definitions for this terms 
neither does the KService::Ptr class return translated categories as it 
does for the genericName() method. Do I have missed something ?

Ralf








From js at iidea.pl  Mon Mar 31 12:54:12 2008
From: js at iidea.pl (Jaroslaw Staniek)
Date: Mon, 31 Mar 2008 12:54:12 +0200
Subject: kbuildsycoca.cpp
In-Reply-To: <47F0BAE6.4030702@freenet.de>
References: <mailman.41.1206788421.25600.kde-windows@kde.org>	<c6aeeb1d0803290826g5ef5d222gb197cce69b905711@mail.gmail.com>	<47EE8353.4090104@freenet.de>	<47EED98A.7050900@iidea.pl>
	<47F0BAE6.4030702@freenet.de>
Message-ID: <47F0C2D4.2090302@iidea.pl>


Looks good to me! Please resend to kde-core-devel.

-- 
regards / pozdrawiam, Jaroslaw Staniek
  Sponsored by OpenOffice Polska (http://www.openoffice.com.pl/en) to work on
  Kexi & KOffice (http://www.kexi.pl/en, http://www.koffice.org/kexi)
  KDE Libraries for MS Windows (http://windows.kde.org)

From mail at nunobrito.eu  Mon Mar 31 13:04:14 2008
From: mail at nunobrito.eu (Nuno Brito)
Date: Mon, 31 Mar 2008 11:04:14 +0000
Subject: KDE4 - Lack of meaningful title on mailing list reply
Message-ID: <c6aeeb1d0803310404w56951f06yf2db89c8a80f046d@mail.gmail.com>

 Today's Topics:

   1. Lack of meaningful title (Jaroslaw Staniek)
   2. KDE for Windows dedicated forum (Nuno Brito)


1. Lack of meaningful title (Jaroslaw Staniek)

Sorry!

This is the first mailing list that I join, will do as you suggest.



2. KDE for Windows dedicated forum (Nuno Brito)

I'm mostly a forums member but I noticed that there is no specific forum for
KDE on windows and that was the reason why I joined the mailing list in the
first place.

My first impressions are that it is a bit more difficult to exchange ideas
across other interested people because it takes some time to read the
replies and organize the info that is being written.

I'm the administrator of a public forum where KDE for windowswas recently
mentioned:
http://boot-land.blogspot.com/2008/03/kde4-running-in-windows.html
http://www.boot-land.net/forums/?showtopic=4207
http://boot-land.blogspot.com/2008/03/newsletter-30th-march-2008.html

I would seriously like to support KDE by creating a new forum section
entirely dedicated to the windows version on the main page of this site that
has grown popular amongst other IT people interested in this sort of
developments.

We have very good work conditions, lots of experience with windows, don't
use any google ads and KDE for windows would surely reach a wider audience
of Win32 users and feedback.

Please visit this site and let me know your opinion:
http://boot-land.net/forums

Thanks.



2008/3/31, kde-windows-request at kde.org <kde-windows-request at kde.org>:
>
> Send Kde-windows mailing list submissions to
>         kde-windows at kde.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://mail.kde.org/mailman/listinfo/kde-windows
> or, via email, send a message with subject or body 'help' to
>         kde-windows-request at kde.org
>
> You can reach the person managing the list at
>         kde-windows-owner at kde.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Kde-windows digest..."
>
>
> Today's Topics:
>
>    1. Lack of meaningful title (Jaroslaw Staniek)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 31 Mar 2008 10:06:40 +0200
> From: Jaroslaw Staniek <js at iidea.pl>
> Subject: Lack of meaningful title
> To: KDE on Windows <kde-windows at kde.org>
> Message-ID: <47F09B90.40200 at iidea.pl>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
>
> Nuno, could you please take a minute and use more meaningful message title
> than a "Digest"?
>
> --
> regards / pozdrawiam, Jaroslaw Staniek
>   Sponsored by OpenOffice Polska (http://www.openoffice.com.pl/en) to work
> on
>   Kexi & KOffice (http://www.kexi.pl/en, http://www.koffice.org/kexi)
>   KDE Libraries for MS Windows (http://windows.kde.org)
>
>
> ------------------------------
>
> _______________________________________________
> Kde-windows mailing list
> Kde-windows at kde.org
> https://mail.kde.org/mailman/listinfo/kde-windows
>
>
> End of Kde-windows Digest, Vol 30, Issue 33
> *******************************************
>



-- 
Nuno Brito
http://nunobrito.eu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kde-windows/attachments/20080331/64030efc/attachment.html 

From js at iidea.pl  Mon Mar 31 13:36:32 2008
From: js at iidea.pl (Jaroslaw Staniek)
Date: Mon, 31 Mar 2008 13:36:32 +0200
Subject: KDE4 - Lack of meaningful title on mailing list reply
In-Reply-To: <c6aeeb1d0803310404w56951f06yf2db89c8a80f046d@mail.gmail.com>
References: <c6aeeb1d0803310404w56951f06yf2db89c8a80f046d@mail.gmail.com>
Message-ID: <47F0CCC0.8050007@iidea.pl>

Nuno Brito said the following, On 2008-03-31 13:04:
>  Today's Topics:
> 
>    1. Lack of meaningful title (Jaroslaw Staniek)
>    2. KDE for Windows dedicated forum (Nuno Brito)
> 
> 
> 1. Lack of meaningful title (Jaroslaw Staniek)
> 
> Sorry!
> 
> This is the first mailing list that I join, will do as you suggest.

You can just change "Mail delivery" on 
https://mail.kde.org/mailman/options/kde-windows to Enabled. and switch off 
the Difgest mode.

> 2. KDE for Windows dedicated forum (Nuno Brito)

I am rather against any official forum unless we have volunteer that wants to 
act as a proxy for out team. Feel free to set up and maintain any forum if you 
have the resources, especially for nontechnical users, but someone would 
resend their (meaningful) requests to the kde-windows list too.
For example I have already dozens of web pages where I need to visit.

There's additional overhead is a well know case where people use extra forums 
to report bugs - instead of using bugs.kde.org.

You can of course also consider setting up a readonly proxy to kde-windows, 
but look that there are already many of them. The original one is 
http://lists.kde.org/?l=kde-windows&r=1&w=2

Thanks for your proposal.
I am looking forward opinions of other members of the team.

-- 
regards / pozdrawiam, Jaroslaw Staniek
  Sponsored by OpenOffice Polska (http://www.openoffice.com.pl/en) to work on
  Kexi & KOffice (http://www.kexi.pl/en, http://www.koffice.org/kexi)
  KDE Libraries for MS Windows (http://windows.kde.org)

From apaku at gmx.de  Mon Mar 31 15:52:21 2008
From: apaku at gmx.de (Andreas Pakulat)
Date: Mon, 31 Mar 2008 15:52:21 +0200
Subject: KDE4 - Lack of meaningful title on mailing list reply
In-Reply-To: <47F0CCC0.8050007@iidea.pl>
References: <c6aeeb1d0803310404w56951f06yf2db89c8a80f046d@mail.gmail.com>
	<47F0CCC0.8050007@iidea.pl>
Message-ID: <20080331135221.GB18831@morpheus.apaku.dnsalias.org>

On 31.03.08 13:36:32, Jaroslaw Staniek wrote:
> Nuno Brito said the following, On 2008-03-31 13:04:
> >  Today's Topics:
> > 
> >    1. Lack of meaningful title (Jaroslaw Staniek)
> >    2. KDE for Windows dedicated forum (Nuno Brito)
> > 
> > 
> > 1. Lack of meaningful title (Jaroslaw Staniek)
> > 
> > Sorry!
> > 
> > This is the first mailing list that I join, will do as you suggest.
> 
> You can just change "Mail delivery" on 
> https://mail.kde.org/mailman/options/kde-windows to Enabled. and switch off 
> the Difgest mode.
> 
> > 2. KDE for Windows dedicated forum (Nuno Brito)
> 
> I am rather against any official forum unless we have volunteer that wants to 
> act as a proxy for out team. Feel free to set up and maintain any forum if you 
> have the resources, especially for nontechnical users, but someone would 
> resend their (meaningful) requests to the kde-windows list too.
> For example I have already dozens of web pages where I need to visit.

Not sure I still count as member of the team, however my 0.2 cent:

I find a web-based forum always harder to use than emails, especially
for technical discussions. Also I don't like the push-style of things in
forums, even if I watch a specific discussion, I'll have to open a
browser to actually reply something.

So I'm against having the main technical discussions anywhere except in
this mailinglist, but if anybody wants to setup a users-help-users forum
somewhere thats fine.

Andreas

-- 
It was all so different before everything changed.

From ralf.habacker at freenet.de  Mon Mar 31 16:26:12 2008
From: ralf.habacker at freenet.de (Ralf Habacker)
Date: Mon, 31 Mar 2008 16:26:12 +0200
Subject: automatic kbuildsycoca recreate when home dir and/or install dir
	changes
In-Reply-To: <47EED98A.7050900@iidea.pl>
References: <mailman.41.1206788421.25600.kde-windows@kde.org>	<c6aeeb1d0803290826g5ef5d222gb197cce69b905711@mail.gmail.com>	<47EE8353.4090104@freenet.de>	<47EED98A.7050900@iidea.pl>
Message-ID: <47F0F484.3020503@freenet.de>

Hi,

appended is a patch for kbuildsycoca which checks a changed home and/or 
install directory and triggers a complete recreate of the ksycoca 
database in those cases. This is required for KDE usb stick installations.

The patch is currently limited to windows, although it may also be 
usefull for unix os. In that case i would remove the conditionals. 
Please review.

Ralf





-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: kbuildsycoca-path-change-update.patch
Url: http://mail.kde.org/pipermail/kde-windows/attachments/20080331/3ea4c029/attachment-0001.ksh 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: file:///C:/DOKUME~1/HABACK~1.NIS/LOKALE~1/TEMP/nsmail-2.txt
Url: http://mail.kde.org/pipermail/kde-windows/attachments/20080331/3ea4c029/attachment-0001.txt 

From themaestroofemail at gmail.com  Mon Mar 31 18:22:51 2008
From: themaestroofemail at gmail.com (Lavacano Volblaster)
Date: Mon, 31 Mar 2008 09:22:51 -0700
Subject: Lack of meaningful title
In-Reply-To: <47F09B90.40200@iidea.pl>
References: <mailman.41.1206788421.25600.kde-windows@kde.org>	<c6aeeb1d0803290826g5ef5d222gb197cce69b905711@mail.gmail.com>
	<47F09B90.40200@iidea.pl>
Message-ID: <47F10FDB.1000905@gmail.com>

I agree with Jaroslaw.

Jaroslaw Staniek wrote:
> Nuno, could you please take a minute and use more meaningful message title 
> than a "Digest"?
>
>   
-- 
Proposed Additions to the PDP-11 Instruction Set:

PI      Punch Invalid
POPI    Punch Operator Immediately
PVLC    Punch Variable Length Card
RASC    Read And Shred Card
RPM     Read Programmers Mind
RSSC    reduce speed, step carefully  (for improved accuracy)
RTAB    Rewind tape and break
RWDSK   rewind disk
RWOC    Read Writing On Card
SCRBL   scribble to disk  - faster than a write
SLC     Search for Lost Chord
SPSW    Scramble Program Status Word
SRSD    Seek Record and Scar Disk
STROM   Store in Read Only Memory
TDB     Transfer and Drop Bit
WBT     Water Binary Tree


From ralf.habacker at freenet.de  Mon Mar 31 18:27:46 2008
From: ralf.habacker at freenet.de (Ralf Habacker)
Date: Mon, 31 Mar 2008 18:27:46 +0200
Subject: request for moving kdebase/workspace/menu to kdebase/runtime
Message-ID: <47F11102.4050308@freenet.de>

Hi,

to have full internationalisation support for kdebase-runtime ( 
khelpcenter) and kdebase-apps (konqueror) applications  it is required 
to have the desktopfiles from kdebase/workspace/menu installed.

This means that kdebase-runtime depends on kdebase-workspace which for 
opinion is not a very good solution and should be changed. I request to 
move kdebase/workspace/menu to kdebase/runtime/menu.

Any objectivities ?

Ralf





From ralf.habacker at freenet.de  Mon Mar 31 20:15:04 2008
From: ralf.habacker at freenet.de (Ralf Habacker)
Date: Mon, 31 Mar 2008 20:15:04 +0200
Subject: KDirWatch problem
Message-ID: <47F12A28.6060503@freenet.de>

Hi,

with recent svn qt and kdelibs I got the following QFileSystemWatcher 
related message in kded:

[4636] kded(4636)/kio (KDirWatch) void __thiscall 
KDirWatchPrivate::addEntry(class KDirWatch *,const class QString &,class 
KDirWatchPrivate::Entry *,bool,class QFlags<enum KDirWatch::WatchMode>): 
Added File 
"C:/daten/kde/emerge-msvc-root/share/apps/kconf_update/kcookiescfg.upd" 
for "" ["KDirWatch-2"]
[4636] QFileSystemWatcher: failed to add paths: 
C:/daten/kde/emerge-msvc-root/share/apps/kconf_update/kcookiescfg.upd

Is anyone there who can explain what's going wrong and how to fix this 
problem ?

Ralf


From Ch.Ehrlicher at gmx.de  Mon Mar 31 20:30:28 2008
From: Ch.Ehrlicher at gmx.de (Christian Ehrlicher)
Date: Mon, 31 Mar 2008 20:30:28 +0200
Subject: KDirWatch problem
In-Reply-To: <47F12A28.6060503@freenet.de>
References: <47F12A28.6060503@freenet.de>
Message-ID: <47F12DC4.60806@gmx.de>

Ralf Habacker schrieb:
> Hi,
> 
> with recent svn qt and kdelibs I got the following QFileSystemWatcher 
> related message in kded:
> 
> [4636] kded(4636)/kio (KDirWatch) void __thiscall 
> KDirWatchPrivate::addEntry(class KDirWatch *,const class QString &,class 
> KDirWatchPrivate::Entry *,bool,class QFlags<enum KDirWatch::WatchMode>): 
> Added File 
> "C:/daten/kde/emerge-msvc-root/share/apps/kconf_update/kcookiescfg.upd" 
> for "" ["KDirWatch-2"]
> [4636] QFileSystemWatcher: failed to add paths: 
> C:/daten/kde/emerge-msvc-root/share/apps/kconf_update/kcookiescfg.upd
> 
> Is anyone there who can explain what's going wrong and how to fix this 
> problem ?
> 
Does this file exist?


Christian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 258 bytes
Desc: OpenPGP digital signature
Url : http://mail.kde.org/pipermail/kde-windows/attachments/20080331/e6d61510/attachment.pgp