headers
Aaron J. Seigo | 1 Jan 2007 02:37
Picon
Favicon
Gravatar

cmake projects and l10n

hi =)

writing some content for the devnew wiki recently i ran into a wall: what is 
the process for building pot files with our cmake system now?

it use to be:

	make -f admin/Makefile.common package-messages

there also used to be a ton of junk in Makefile.am for the messages target. 
what replaces that, if anything?

--

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)
Permalink | Reply | 2 comments |
headers
Matt Rogers | 1 Jan 2007 06:26
Picon
Favicon
Gravatar

Re: cmake projects and l10n


On Dec 31, 2006, at 7:37 PM, Aaron J. Seigo wrote:

> hi =)
>
> writing some content for the devnew wiki recently i ran into a  
> wall: what is
> the process for building pot files with our cmake system now?
>
> it use to be:
>
> 	make -f admin/Makefile.common package-messages
>
> there also used to be a ton of junk in Makefile.am for the messages  
> target.
> what replaces that, if anything?
>

AFAIK, there is a Messages.sh script that replaces the previous crap  
in the Makefile.am file
--
Matt
Permalink | Reply | 1 comment |
headers
Hamish Rodda | 1 Jan 2007 09:32
Picon
Favicon

Re: KSeparatorAction

Hi,

On Friday 29 December 2006 18:25, Simon Hausmann wrote:
> I'm not sure where the comment in KSeparatorAction comes from that one
> cannot re-use a separator action :)

Previously with the old KAction you could have an action in a menu or toolbar 
etc. as many times as you want.  With the new KAction (ie. QAction), you need 
to have multiple separator action instances if you want multiple separators.

Cheers,
Hamish.
Permalink | Reply | 0 comments |
headers
Frans Englich | 1 Jan 2007 13:45
Picon
Favicon

Re: KPasswordEdit and security

On Tuesday 26 December 2006 22:17, Albert Astals Cid wrote:
> Hi, KPasswordEdit is using a char * internally to store the password. There
> is a note in the header that says "I believe this is safer than a
> QString.". I'm not much into security but i would want some confirmation if
> it is safer to use a char* than a QString.
>
> I'm asking this because i want to fix bug 138997, a bug in KPasswordEdit
> (storing char * and some input method related things) makes it impossible
> to input passwords with non-ascii characters. One could fix that porting
> that internal char* to internal ushort*, but that's not trivial, and if
> there is no strong security reason i think we can just drop KPasswordEdit
> altogether for KDE4 and use QLineEdit.

Apart from the security discussions up til now("one can use QSecureArray or 
lock memory pages"), I think they step aside from what this thread brings up: 
that KPasswordEdit can't handle Unicode. I find that quite a severe bug.

So, perhaps a good start is to take Unicode support into account before 
looking at more sophisticated security measures(which I as well question 
whether it's doable globally in KDE and if it doesn't belong on the OS 
level).

Cheers,

		Frans
Permalink | Reply | 0 comments |
headers
Reinhold Kainhofer | 1 Jan 2007 13:51
Favicon
Gravatar

CMake problem with Qt4.2.1 from Distro packages and qt-copy for kdelibs


Hi all!

On my office machine I have Debian installed and Qt 4.2.1 from the debian 
packages (since other packages depend on Qt4). Now since kdelibs no longer 
works with Qt 4.2.1 (which has worked for quite a while until a week or two 
ago), I needed to install qt-copy, too.

So, I have Qt 4.2.1 installed in /usr and qt-copy 
in /data/kdetest/qt-unstable, the variables are all setup correctly as 
decribed on http://wiki.kde.org/tiki-index.php?page=KDE3To4:

kdetest <at> curie:~$ echo $QTDIR
/data/kdetest/qt-unstable
kdetest <at> curie:~$ echo $LD_LIBRARY_PATH
/data/kdetest/kde/lib:/data/kdetest/qt-unstable/lib:
kdetest <at> curie:~$ which qdbuscpp2xml
/data/kdetest/qt-unstable/bin/qdbuscpp2xml

However, when I use ccmake (cmake version 2.4-patch 5, installed from Debian 
packages) to configure kdelibs, some paths are taken from $QTDIR, while 
others are taken from /usr! In particular, all include paths are taken 
from /usr, the library paths are taken from /data/kdetest/qt-unstable, and 
the binaries are taken from /usr....

 QT_DBUSCPP2XML_EXECUTABLE       */usr/bin/qdbuscpp2cml
 QT_DBUSXML2CPP_EXECUTABLE       */usr/bin/qdbusxml2cpp
 QT_DOC_DIR                      */data/kdetest/qt-unstable/doc
 QT_INCLUDE_DIR                  */usr/include/qt4
 QT_LIBRARY_DIR                  */data/kdetest/qt-unstable/lib
(Continue reading)

Permalink | Reply | 2 comments |
headers
Frans Englich | 1 Jan 2007 14:01
Picon
Favicon

Re: dbus+Service name+error

On Tuesday 19 December 2006 23:15, Thiago Macieira wrote:
> Aaron J. Seigo wrote:
> >seems like we're abusing one namespace (web urls) to populate another
> > (dbus methods). there really isn't any meaningful correspondence
> > between the two as you've shown with the kmid example.
>
> I beg to differ.
>
> There is a relationship: the service names are globally unique and stem
> from the DNS hierarchy. So, the only way for KMyApplication to be allowed
> to use org.kde.kmyapplication is if and only if kmyapplication.kde.org is
> reserved to THAT application. (It doesn't have to have a webpage at that
> address or even resolve, but it must be reserved)

Yes, what makes domain names interesting, regardless of what they're used for, 
is that they give unique URIs. The usage doesn't have to be HTTP/web related, 
it's just that they provide unique identifiers.

If editing/updating the URI guidelines can be of any help here, feel free to 
ping me. http://developer.kde.org/policies/uri-guidelines.xhtml

Cheers,

		Frans
Permalink | Reply | 0 comments |
headers
Thiago Macieira | 1 Jan 2007 14:13
Picon
Favicon

Re: CMake problem with Qt4.2.1 from Distro packages and qt-copy for kdelibs

Reinhold Kainhofer wrote:
>kdetest <at> curie:~$ echo $QTDIR
>/data/kdetest/qt-unstable
>kdetest <at> curie:~$ echo $LD_LIBRARY_PATH
>/data/kdetest/kde/lib:/data/kdetest/qt-unstable/lib:
>kdetest <at> curie:~$ which qdbuscpp2xml
>/data/kdetest/qt-unstable/bin/qdbuscpp2xml

which qmake?

>How can I force ccmake to search for the includes and the binaries in
> the QTDIR first and not in /usr?

sed -i '/QT_/d' CMakeCache.txt
cmake $srcdir
cmake $srcdir

(run twice because the first one fixes the corrupt CMakeCache.txt file 
that sed created)
--

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
Permalink | Reply | 0 comments |
headers
Alexander Neundorf | 1 Jan 2007 14:56
Picon
Favicon

Re: CMake problem with Qt4.2.1 from Distro packages and qt-copy for kdelibs

On Monday 01 January 2007 13:51, Reinhold Kainhofer wrote:
> Hi all!
>
> On my office machine I have Debian installed and Qt 4.2.1 from the debian
> packages (since other packages depend on Qt4). Now since kdelibs no longer
> works with Qt 4.2.1 (which has worked for quite a while until a week or two
> ago), I needed to install qt-copy, too.
>
> So, I have Qt 4.2.1 installed in /usr and qt-copy
> in /data/kdetest/qt-unstable, the variables are all setup correctly as
> decribed on http://wiki.kde.org/tiki-index.php?page=KDE3To4:
>
> kdetest <at> curie:~$ echo $QTDIR
> /data/kdetest/qt-unstable

QTDIR is obsolete with Qt4, no need to set it.

> kdetest <at> curie:~$ echo $LD_LIBRARY_PATH
> /data/kdetest/kde/lib:/data/kdetest/qt-unstable/lib:
> kdetest <at> curie:~$ which qdbuscpp2xml
> /data/kdetest/qt-unstable/bin/qdbuscpp2xml

"which qmake" is the important one. Make sure the qt-copy qmake is the first 
qmake in the PATH, then everything should work correctly.

> However, when I use ccmake (cmake version 2.4-patch 5, installed from
> Debian packages) to configure kdelibs, some paths are taken from $QTDIR,
> while others are taken from /usr! In particular, all include paths are
> taken
(Continue reading)

Permalink | Reply | 0 comments |
headers
Martin Koller | 1 Jan 2007 20:13
X-Face
Picon
Favicon

Status of kcontrol/kcmshell ?

Hi,

I wanted to check my kcontrol module "joystick" in KDE4, but trying to launch 
it with
kcmshell joystick
gives me an error about KLibrary: QLibrary::resolve_sys: 
Symbol "create_kcm_joystick" undefined ...
Checking with nm, there is no such function, and what I see from klibloader in 
the macro K_EXPORT_COMPONENT_FACTORY still creates a "init_..." function.
Why is kcmshell trying to find a "create_..." function ?
What do I have to fix ?

--

-- 
Best regards/Schöne Grüße

Martin    ()  ascii ribbon campaign - against html mail 
          /\                        - against microsoft attachments

Computers and Internet gave you freedom.
TCPA would TAKE your FREEDOM!  http://www.againsttcpa.com
Permalink | Reply | 1 comment |
headers
Richard Moore | 1 Jan 2007 21:25
Picon

Re: (Re:) Next monday will be a tuesday (again)

On 12/29/06, Aaron J. Seigo <aseigo <at> kde.org> wrote:
> so they need to do exactly as they did in kde3: add the search dir to
> instance()->dirs() or use their own private iconloader. the only difference
> is that you don't get an iconloader simply by creating your own kinstance.

Does this imply that they should also remove it if the plugin is disabled later?

Rich.
Permalink | Reply | 3 comments |

Gmane