gmane.comp.kde.devel.core

kcmodule and kcmoduleproxy

Sebastian Sauer — 2008-12-04T02:00:19

Hi * The KCMultiDialog class used for e.g. "Configure Konqueror" uses kcmodule for its configurable items and kcmoduleproxy which allows to delay loading the kcmodule plugins till they are requested. Current situation is, that the kcmodule's are just always loaded and not only if they are needed/displayed. That results here in a delay of around 10 seconds if I call "Configure Konqueror" till the dialog is displayed and does render the kcmoduleproxy's unneeded. The reason for that is, that on addPage() also KCModuleProxy::minimumSizeHint() got called and there the kcmodule is loaded. Attached patch does fix that. Ok to commit? Index: kcmoduleproxy.cpp =================================================================== --- kcmoduleproxy.cpp (revision 892245) +++ kcmoduleproxy.cpp (working copy) < at >< at > -343,7 +343,6 < at >< at > QSize KCModuleProxy::minimumSizeHint() const { - realModule(); return QWidget::minimumSizeHint(); }

[Patch] Fix drop to KTabWidget with zero tabs

Friedrich W. H. Kossebau — 2008-12-03T19:30:05

Hi, currently if a KTabWidget contains no tabs the drop support of KTabWidget falls flat on the face. Especially sad because the full widget space could now be considered as the dropping zone. The drop fails because with 0 tabs no tabbar is shown, so isEmptyTabbarSpace() returns false. Okay to commit the attached patch? Cheers Friedrich

Getting full path to a dynamic library?

Sebastian Trueg — 2008-12-03T12:37:10

As far as I can tell QLibrary only gives us the filename of a dynamically loaded library. However, I need to determine the full path for usage in ODBC. Does anyone know how to determine that in a platform independent manner? Thanks, Sebastian

New Interface

David Nolden — 2008-12-01T13:49:43

Hi fellow KDE developers! I've read the release plan on the wiki, and it says that only bugfixes are allowed in the currect cycle. Now we have a few shared bugs between kdevelop/kate that could either be fixed the wrong way on one of the sides by adding more hacks, or the right way by allowing better interaction between both sides. This is mainly about "simple" code-completion logic, eg. when is it triggered, when is it stopped, and when text is used for filtering. Currently these are hardcoded within kate, while actually that logic is specific for each kind of completion and language. So Niko Sams has come up with a patch to solve the problem. We have discussed, and came to the conclusion that while this could be solved with one single additional signal in KTextEditor::CodeCompletionModel, a new interface would be the much cleaner solution. However we also want KDevelop4 to be compatible with KDE 4.2, since that's hopefully what will be out when KDevelop 4.0 is released. So would it be ok adding the following interface in the current freeze state? A few points why this is not too dangerous: - All the affected code is, from what I know, currently _exclusively_ used by KDevelop, so the danger of breaking any other applications, even when problems should arise, is close to zero. - KDevelop is already now used as main editor/IDE by many developers, and we'll start using this interface right away should it be added. This means that it may get the testing it needs during the months until KDE 4.2 release. Greetings, David

Implementation of KToolInvocation::invokeFilemanager

Elias Probst — 2008-11-30T20:06:13

Hi, today we were discussing how to invoke the default filemanager from Plasma's 'Devices recently plugged in...' applet and as there's now the option to select the default filemanager in Systemsettings we thought this could be done using 'KToolInvocation::invokeFilemanager', but it seems this is still missing. A bug facing nearly the same problem came to my mind: [ #161384 Network/Add Network Folder doesn't add folders in Dolphin ] https://bugs.kde.org/show_bug.cgi?id=161384 As this could be really useful now and it looks it was anyways planned for KDE 4.2 (see comment #3 at the bug above) I wanted to ask how's the state of this implementation. Could anyone implement this? Davide 'WindowsUninstall' Bettio is going to fix bug#161384 as soon as there's the necessary stuff in kdelibs. Best regards, Elias P. Thanks a lot

[PATCH] fix KDialog to use platform native layout spacing and margins

Christoph Feck — 2008-11-29T19:21:14

Hello, this is my first post to this list, so please be gentle with my mistakes :) I noticed that KDialog uses its own hard coded sizes for spacing and margins, which I consider bad, because Qt styles can compute layouts depending on widget types and pairs, so even a configurable value would be wrong. This patch should "move" those fixed values to KStyle, meaning any style automatically inherits the KDE defaults (should they ever change). Additionally, KDialog no longer sets these attributes on it's TopLayout, so that it can respect the style's layoutSpacingImplementation() method, which results in better platform native appearance e.g. on QMacStyle. I already posted this to kde.bugs.org as bug #176473, since I was not subscribed to this list before, and am looking for someone who could review this patch. But I am adding it here, too, as I do not know if you prefer it here. Thanks, Christoph Feck (kdepepo on #kde-devel)

KDE Problems when running Qt Designer

Allen Winter — 2008-12-02T13:47:20

Howdy, When running designer, I see the following messages (some errors) in my konsole. Is this something we need to fix (not that I have any idea at all)? Or maybe something I'm doing wrong? -Allen % echo $QT_PLUGIN_PATH /usr/lib/kde4/plugins:/home/winterz/.kde/lib/kde4/plugins/:/data/kde/lib/kde4/plugins/ % designer QMetaProperty::read: Unable to handle unregistered datatype 'QList' for property 'KCharSelect::displayedChars' QMetaProperty::read: Unable to handle unregistered datatype 'QList' for property 'KColorCombo::colors' Error while reparenting! makekdewidgets(21672)/kdecore (KSycoca) KSycocaPrivate::openDatabase: Trying to open ksycoca from "/var/tmp/kdecache-winterz/ksycoca4" QMetaProperty::read: Unable to handle unregistered datatype 'ShortcutTypes' for property 'KKeySequenceWidget::checkForConflictsAgainst' QMetaProperty::read: Unable to handle unregistered datatype 'KUrl' for property 'KUrlRequester::url' QMetaProperty::read: Unable to handle unregistered datatype 'KFile::Modes' for property 'KUrlRequester::mode' QMetaProperty::read: Unable to handle unregistered datatype 'KUrl' for property 'KUrlRequester::url' QMetaProperty::read: Unable to handle unregistered datatype 'KFile::Modes' for property 'KUrlRequester::mode' QMetaProperty::read: Unable to handle unregistered datatype 'QList' for property 'KCharSelect::displayedChars' QMetaProperty::read: Unable to handle unregistered datatype 'QList' for property 'KColorCombo::colors' Error while reparenting!

[Patch] KDirModel fix for non-standard hierarchies

David Faure — 2008-12-02T10:46:44

After I tried convincing everyone that kioslaves should only produce predictable hierarchies (listing foo://bar/ should produce items with urls like foo://bar/blah and nothing else), I am finally convinced that this cannot always be done (for instance: smb:/ -> smb://workgroup -> smb://host -> smb://host/path) and I finally found a way to support that from KDirModel. In the very first iteration of KDirModel I had used a QHash and it was really slow so I redesigned it not to use that, but yesterday I found that QHash didn't have to be slow ;) I rewrote qHash(KUrl) and now it's 60 times faster than before... So, back to square one, rewriting KDirModel::nodeForUrl to use a QHash rather than navigating inside the hierarchy. The patch also includes a new KDirLister signal so that it emits the parent url together with the items, so that KDirModel doesn't have to guess what the parent url is anymore (and in case of non-standard hierarchies, it cannot guess correctly). All this started as a fix for bug 176555, but I know it will also help other kioslaves (hi nf2 and trueg ;). It also makes UDS_URL useful again (the fix for 176555 also includes s/UDS_TARGET_URL/UDS_URL/ in kio_smb) The reason I'm posting this here is... should I commit despite the freeze? On one hand it's a bugfix, on the other hand it's a redesign of the internals.... the unit tests make me quite confident about it, but of course they're never 100% complete. One thing to note is that non-standard hierarchies break the "Up" button in konq, though, when using an iconview rather than a treeview. From smb://host you cannot go up to smb://workgroup or smb:/. If we want that, then we can forget about this patch and hack KUrl instead :-) (the point being that if KUrl knows how to go up from there, then KDirModel can just ask KUrl like it currently does upon receiving new items...). But I guess we want support for non-standard hierarchies even if Up doesn't work for them.

qt-copy patch for QDesktopServices to allow path kcm to work

Anne-Marie Mahfouf — 2008-12-01T21:45:44

KProcess Line Mode Patch

Ralf Habacker — 2008-12-01T11:32:08

Hi, based on the work described on http://lists.kde.org/?l=kde-core-devel&m=120522889930459&w=2 there is a patch appended which implements a line buffering mode directly in KProcess. The advantage of this approach is that this feature is directly available from kdecore and therefore no additional class located somewhere in the related package source is required. How it works: 1.Line buffering mode ist enabled with the void setOutputLineMode(bool mode); 2.There are new KProcess signals available which indicates available lines. void readyReadLineStandardOutput(); void readyReadLineStandardError(); 3. The lines could be fetched with QStringList &readLinesStandardOutput(QStringList &out=QStringList()); QStringList &readLinesStandardError(QStringList &out=QStringList()); 4. non standard line delimiters could be set by void setOutputLineDelimiter(QString &delim=QString()); Any comments or objections ? Ralf Index: kdecore/io/kprocess.cpp =================================================================== --- kdecore/io/kprocess.cpp(revision 890832) +++ kdecore/io/kprocess.cpp(working copy) < at >< at > -41,6 +41,15 < at >< at > # define STD_ERROR_HANDLE 2 #endif +KProcessPrivate::KProcessPrivate() : openMode(QIODevice::ReadWrite), outputLineMode(false) +{ +#ifdef Q_OS_WIN32 + outputDelimiter = "\r\n"; +#else + outputDelimiter = "\n"; +#endif +} + void KProcessPrivate::writeAll(const QByteArray &buf, int fd) { #ifdef Q_OS_WIN < at >< at > -83,6 +92,67 < at >< at > forwardStd(KProcess::StandardError, STD_ERROR_HANDLE); } +void KProcessPrivate::_k_receivedStdout() +{ + if (!outputLineMode) + return; + + Q_Q(KProcess); + QByteArray ndata = q->readAllStandardOutput(); + int oldBufferSize = stdoutBuffer.size(); + stdoutBuffer.append(ndata); + if (newlineInStdout < 0) { + newlineInStdout = ndata.indexOf(outputDelimiter); + if (newlineInStdout >= 0) { + newlineInStdout += oldBufferSize; + emit q->readyReadLineStandardOutput(); + } + } +} + +void KProcessPrivate::_k_receivedStderr() +{ + if (!outputLineMode) + return; + + Q_Q(KProcess); + QByteArray ndata = q->readAllStandardError(); + int oldBufferSize = stderrBuffer.size(); + stderrBuffer.append(ndata); + if (newlineInStderr < 0) { + newlineInStderr = ndata.indexOf(outputDelimiter); + if (newlineInStderr >= 0) { + newlineInStderr += oldBufferSize; + emit q->readyReadLineStandardError(); + } + } +} + +void KProcessPrivate::_k_finished(int exitCode, QProcess::ExitStatus exitStatus) +{ + if (!outputLineMode) + return; + + // check if there is unprocessed data in output channel + Q_Q(KProcess); + + QByteArray ndata = q->readAllStandardOutput(); + stdoutBuffer.append(ndata); + if (stdoutBuffer.size() > 0) { + stdoutBuffer.append(outputDelimiter); + newlineInStdout = stdoutBuffer.indexOf(outputDelimiter); + emit q->readyReadLineStandardOutput(); + } + ndata = q->readAllStandardError(); + stderrBuffer.append(ndata); + if (stderrBuffer.size() > 0) { + stderrBuffer.append(outputDelimiter); + newlineInStderr = stderrBuffer.indexOf(outputDelimiter); + emit q->readyReadLineStandardError(); + } +} + + ///////////////////////////// // public member functions // ///////////////////////////// < at >< at > -115,18 +185,36 < at >< at > d->outputChannelMode = mode; disconnect(this, SIGNAL(readyReadStandardOutput())); disconnect(this, SIGNAL(readyReadStandardError())); + disconnect(this, SIGNAL(finished(int,QProcess::ExitStatus))); switch (mode) { case OnlyStdoutChannel: connect(this, SIGNAL(readyReadStandardError()), SLOT(_k_forwardStderr())); + QProcess::setProcessChannelMode(QProcess::SeparateChannels); break; case OnlyStderrChannel: connect(this, SIGNAL(readyReadStandardOutput()), SLOT(_k_forwardStdout())); + QProcess::setProcessChannelMode(QProcess::SeparateChannels); break; + case MergedChannels: + if (d->outputLineMode) { + connect(this, SIGNAL(readyReadStandardOutput()), SLOT(_k_receivedStdout())); + connect(this, SIGNAL(finished(int,QProcess::ExitStatus)),this,SLOT(_k_finished(int,QProcess::ExitStatus))); + } + QProcess::setProcessChannelMode(QProcess::MergedChannels); + break; + + case SeparateChannels: + if (d->outputLineMode) { + connect(this, SIGNAL(readyReadStandardOutput()), SLOT(_k_receivedStdout())); + connect(this, SIGNAL(readyReadStandardError()), SLOT(_k_receivedStderr())); + connect(this, SIGNAL(finished(int,QProcess::ExitStatus)),this,SLOT(_k_finished(int,QProcess::ExitStatus))); + } + QProcess::setProcessChannelMode(QProcess::SeparateChannels); + break; default: QProcess::setProcessChannelMode((ProcessChannelMode)mode); - return; + break; } - QProcess::setProcessChannelMode(QProcess::SeparateChannels); } KProcess::OutputChannelMode KProcess::outputChannelMode() const < at >< at > -136,6 +224,68 < at >< at > return d->outputChannelMode; } +void KProcess::setOutputLineMode(bool mode) +{ + Q_D(KProcess); + + d->outputLineMode = mode; + // make sure slots are setup right + setOutputChannelMode(d->outputChannelMode); +} + +bool KProcess::outputLineMode() const +{ + Q_D(const KProcess); + + return d->outputLineMode; +} + +void KProcess::setOutputLineDelimiter(QString &delim) +{ + Q_D(KProcess); + + d->outputDelimiter = delim.toAscii(); +} + +QString KProcess::outputLineDelimiter() const +{ + Q_D(const KProcess); + + return d->outputDelimiter; +} + +QStringList &KProcess::readLinesStandardOutput(QStringList &out) +{ + Q_D(KProcess); + + if (d->newlineInStdout < 0) + return out; + + while (d->newlineInStdout > -1) { + out << d->stdoutBuffer.left(d->newlineInStdout); + d->stdoutBuffer.remove(0, d->newlineInStdout + d->outputDelimiter.size()); + d->newlineInStdout = d->stdoutBuffer.indexOf(d->outputDelimiter); + } + + return out; +} + +QStringList &KProcess::readLinesStandardError(QStringList &out) +{ + Q_D(KProcess); + + if (d->newlineInStderr < 0) + return out; + + while (d->newlineInStderr > -1) { + out << d->stdoutBuffer.left(d->newlineInStderr); + d->stderrBuffer.remove(0, d->newlineInStderr + d->outputDelimiter.size()); + d->newlineInStderr = d->stderrBuffer.indexOf(d->outputDelimiter); + } + + return out; +} + void KProcess::setNextOpenMode(QIODevice::OpenMode mode) { Q_D(KProcess); Index: kdecore/io/kprocess.h =================================================================== --- kdecore/io/kprocess.h(revision 890832) +++ kdecore/io/kprocess.h(working copy) < at >< at > -97,6 +97,50 < at >< at > OutputChannelMode outputChannelMode() const; /** + * set the output line mode. When activated output data from the process is returned as complete + * lines. The line data can be retrieved by calling < at >ref readLinesStandardOutput() for stdout and + * < at >ref readLinesStandardError() for stderr. + * + * Available line data is indicated by the signal < at >ref readReadLineStandardOutput() for stdout + * and < at >ref readReadLineStandardError() for stderr . + * + * As line delimiter the operating systems default line delimiter is used (\\r\\n on win32, \\n on unix, ?? on mac). + * Non standard line delimiters could be set with < at >ref setOutputLineDelimiter(). + * + * The output line mode is disabled by default. + + * < at >note When using output line mode, the readAllStandardOutput() and readAllStandardError() methods should not + * be used, otherwise there will be no line output. + * + * < at >param mode of the output line mode + */ + void setOutputLineMode(bool mode); + + /** + * Query the state of the output line mode. See < at >ref setOutputLineMode() for more details for the output line mode. + * + * < at >return the state of the output line mode + */ + bool outputLineMode() const; + + /** + * Set non standard line delimiter for output data in case the default line delimiter (\\r\\n on win32, \\n on unix, ?? on mac) + * is not appliable. + * + * This function must be called before starting the process. + * + * < at >param string with line delimiter + */ + void setOutputLineDelimiter(QString &delim=QString()); + + /** + * Query the currently used output delimiter + * + * < at >return the output line delimiter + */ + QString outputLineDelimiter() const; + + /** * Set the QIODevice open mode the process will be opened in. * * This function must be called before starting the process, obviously. < at >< at > -315,6 +359,38 < at >< at > */ int pid() const; + /** + * When a line delimiter is set with setOutputLineDelimiter(), this function returns + * all data lines available from the standard output of the process as a QStringList, + * regardless of the current read channel, + * + * Available data lines are indicated by the readyReadLineStandardOutput() signal. + */ + QStringList &readLinesStandardOutput(QStringList &out=QStringList()); + + /** + * When a line delimiter is set with setOutputLineDelimiter(), this function returns + * all data lines available from the standard error of the process as a QStringList, + * regardless of the current read channel, + * + * Available data lines are indicated by the readyReadLineStandardOutput() signal. + */ + QStringList &readLinesStandardError(QStringList &out=QStringList()); + +signals: + /** + * This signal is emitted when an output delimiter is set with setOutputLineDelimiter() and + * the process has made new data lines available through its standard output channel (stdout). + * It is emitted regardless of the current read channel. + */ + void readyReadLineStandardOutput(); + /** + * This signal is emitted when an output delimiter is set with setOutputLineDelimiter() and + * the process has made new data lines available through its standard error channel (stderr). + * It is emitted regardless of the current read channel. + */ + void readyReadLineStandardError(); + protected: /** * < at >internal < at >< at > -335,6 +411,9 < at >< at > Q_PRIVATE_SLOT(d_func(), void _k_forwardStdout()) Q_PRIVATE_SLOT(d_func(), void _k_forwardStderr()) + Q_PRIVATE_SLOT(d_func(), void _k_receivedStdout()) + Q_PRIVATE_SLOT(d_func(), void _k_receivedStderr()) + Q_PRIVATE_SLOT(d_func(), void _k_finished(int, QProcess::ExitStatus)) }; #endif Index: kdecore/io/kprocess_p.h =================================================================== --- kdecore/io/kprocess_p.h(revision 890832) +++ kdecore/io/kprocess_p.h(working copy) < at >< at > -27,21 +27,28 < at >< at > class KProcessPrivate { Q_DECLARE_PUBLIC(KProcess) protected: - KProcessPrivate() : - openMode(QIODevice::ReadWrite) - { - } + KProcessPrivate(); void writeAll(const QByteArray &buf, int fd); void forwardStd(KProcess::ProcessChannel good, int fd); void _k_forwardStdout(); void _k_forwardStderr(); + void _k_receivedStdout(); + void _k_receivedStderr(); + void _k_finished(int, QProcess::ExitStatus); QString prog; QStringList args; KProcess::OutputChannelMode outputChannelMode; QIODevice::OpenMode openMode; + KProcess *q_ptr; - KProcess *q_ptr; + + bool outputLineMode; + QByteArray outputDelimiter; + QByteArray stdoutBuffer; + QByteArray stderrBuffer; + int newlineInStdout; + int newlineInStderr; }; Index: kdecore/tests/CMakeLists.txt =================================================================== --- kdecore/tests/CMakeLists.txt(revision 890832) +++ kdecore/tests/CMakeLists.txt(working copy) < at >< at > -105,3 +105,10 < at >< at > set_target_properties(klibloadertestmodule4 PROPERTIES SKIP_BUILD_RPATH FALSE BUILD_WITH_INSTALL_RPATH FALSE) endif (NOT WIN32) + +########### next target ############### + +kde4_add_executable(kprocesstesthelper NOGUI kprocesstesthelper.cpp) +target_link_libraries(kprocesstesthelper ${KDE4_KDECORE_LIBS}) + +add_dependencies(kprocesstest kprocesstesthelper) Index: kdecore/tests/kprocesstest.cpp =================================================================== --- kdecore/tests/kprocesstest.cpp(revision 890832) +++ kdecore/tests/kprocesstest.cpp(working copy) < at >< at > -2,6 +2,7 < at >< at > This file is part of the KDE libraries Copyright (C) 2007 Oswald Buddenhagen kde.org> + Copyright (C) 2008 Ralf Habacker freenet.de> This library is free software; you can redistribute it and/or modify it under the terms of the GNU Library General Public < at >< at > -26,12 +27,40 < at >< at > #include #include +#ifdef Q_OS_WIN32 +#define NL "\r\n" +#else +#ifdef Q_OS_UNIX +#define NL "\n" +#else +# warning define NL for this os +#endif +#endif + class KProcessTest : public QObject { Q_OBJECT +public: + KProcessTest(); + private Q_SLOTS: void test_channels(); void test_setShellCommand(); + void test_signals(); + void test_outputLineMode(); + + void slotPrintError(); + void slotPrintOutput(); + void slotFinished(int exitCode, QProcess::ExitStatus exitStatus); + + void slotOutputLines(); + void slotOutputLinesFinished(int exitCode, QProcess::ExitStatus exitStatus); + + void cleanup(); + +private: + QEventLoop loop; + QStringList outData; }; // IOCCC nomination pending < at >< at > -60,6 +89,11 < at >< at > a = "mode: " ms "\n" + recurse(KProcess::me); \ QCOMPARE(a, e) + +KProcessTest::KProcessTest() : loop( this ) +{ +} + void KProcessTest::test_channels() { #ifdef Q_OS_UNIX < at >< at > -89,6 +123,73 < at >< at > #endif } +void KProcessTest::slotPrintOutput() +{ + KProcess *p = static_cast(sender()); + outData << p->readAllStandardOutput(); +} + +void KProcessTest::slotPrintError() +{ + KProcess *p = static_cast(sender()); + qDebug() << p->readAllStandardError(); +} + +void KProcessTest::slotFinished (int exitCode, QProcess::ExitStatus exitStatus) +{ + loop.exit(); + QVERIFY(outData.size() == 1); + QString a = QLatin1String("line1" NL "line2" NL "line3"); + QCOMPARE(outData.at(0),a); +} + +void KProcessTest::test_signals() +{ + outData.clear(); + KProcess *p = new KProcess; + p->setOutputChannelMode(KProcess::SeparateChannels); + connect(p,SIGNAL(readyReadStandardOutput()),this,SLOT(slotPrintOutput())); + connect(p,SIGNAL(readyReadStandardError()),this,SLOT(slotPrintError())); + connect(p,SIGNAL(finished(int,QProcess::ExitStatus)),this,SLOT(slotFinished(int,QProcess::ExitStatus))); + p->setProgram("kprocesstesthelper", QStringList() << "--partial-line" << "--stdout"); + p->start(); + loop.exec(); +} + +void KProcessTest::slotOutputLines() +{ + KProcess *p = static_cast(sender()); + p->readLinesStandardOutput(outData); +} + +void KProcessTest::slotOutputLinesFinished (int exitCode, QProcess::ExitStatus exitStatus) +{ + loop.exit(); + QVERIFY(outData.size() == 3); + QCOMPARE(outData.at(0), QLatin1String("line1")); + QCOMPARE(outData.at(1), QLatin1String("line2")); + QCOMPARE(outData.at(2), QLatin1String("line3")); +} + +void KProcessTest::test_outputLineMode() +{ + outData.clear(); + KProcess *p = new KProcess; + p->setOutputLineMode(true); + p->setOutputChannelMode(KProcess::SeparateChannels); + connect(p,SIGNAL(readyReadLineStandardOutput()),this,SLOT(slotOutputLines())); + connect(p,SIGNAL(readyReadStandardError()),this,SLOT(slotPrintError())); + connect(p,SIGNAL(finished(int,QProcess::ExitStatus)),this,SLOT(slotOutputLinesFinished(int,QProcess::ExitStatus))); + p->setProgram("kprocesstesthelper", QStringList() << "--partial-line" << "--stdout"); + p->start(); + loop.exec(); +} + +void KProcessTest::cleanup() +{ + loop.exit(); +} + static void recursor(char **argv) { if (argv[1]) { Index: kdecore/tests/kprocesstesthelper.cpp =================================================================== --- kdecore/tests/kprocesstesthelper.cpp(revision 0) +++ kdecore/tests/kprocesstesthelper.cpp(revision 0) < at >< at > -0,0 +1,50 < at >< at > +/* + This file is part of the KDE libraries + + Copyright (C) 2008 Ralf Habacker freenet.de> + + This library is free software; you can redistribute it and/or + modify it under the terms of the GNU Library General Public + License as published by the Free Software Foundation; either + version 2 of the License, or (at your option) any later version. + + This library is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + Library General Public License for more details. + + You should have received a copy of the GNU Library General Public License + along with this library; see the file COPYING.LIB. If not, write to + the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, + Boston, MA 02110-1301, USA. +*/ + +#include +#include +#include + +int main( int argc, char **argv ) +{ + QCoreApplication app(argc, argv); + bool partialLine = false; + FILE *out = stderr; + + QStringList args = QCoreApplication::arguments(); + args.removeFirst(); + Q_FOREACH(QString arg, args) { + if (arg == "--partial-line") + partialLine = true; + else if (arg == "--stdout") + out = stdout; + else if (arg == "--stderr") + out = stderr; + } + if (partialLine) + fprintf(out, "line1\nline2\nline3"); + else + fprintf(out, "line1\nline2\nline3\n"); + + fflush(out); + + return 0; +}

closing bugs products

Jordi Polo — 2008-12-01T04:05:19

There are products on bugs.kde.org that I think should be closed for new bugs: configure: buildsystem can be used instead. No open bugs as this writting.. binaries: downstream bugs should not be reported. No open bugs as this writting. daap kioslave: 1 open bug. Why not move it to kioslaves? spreadkde.org: No open bugs. Looks unmaintained ... printer-applet: 3 open bugs, 5 bugs reported in its life, surely should merge with something. There are also a bunch of applications I am not sure they are maintained anymore (lilo-config for instance, or maybe I was don't use lilo)

Bug in icon kcm?

Louai Al-Khanji — 2008-12-01T00:17:15

Hey, I'm currently not running trunk or I would test this myself. I believe there is a bug in the icon kcm, specifically line 372 in kdebase/runtime/kcontrol/icons/icons.cpp. The value member variable is of float type, but gets cast to int. Because the range for value is 0..1.0, this is effectively always 0 in the config file. Am I right? If so, could someone please correct this? I don't want to do it blindly. Thanks, Louai

Multiple keyboard layouts: shared key-permanent shortcuts

Maciej Pilichowski — 2008-11-26T14:00:23

Hello, This mail is the effect of discussion on the usability ML (subject: "National default shortcuts set"). The purpose is that if user had several layouts no matter what layout is chosen she/he would still press the same keys (as shortcuts). No matter what layout is chosen when user defines new shortcut it is shared with other layouts, so after a switch, shortcut is still there. Proposed solution -- when adding layouts (sys.settings) the first layout would have special meaning as primary layout. This layout would be used to display shortcuts in menus, shortcut dialogs, etc. And for usage -- example from ML. DK keyboard layout for further reference. http://en.wikipedia.org/wiki/Image:Nederlandse_toetsenbordindeling_-_tekst_als_paden.svg User has US as primary layout and has to press US characters ctrl= (which in this example is the same as keys), after adding DK it is still US ctrl= (keys) despite the fact than in DK pressing US key = gives °. Another example: I have US keyboard, but not US layout in KDE. When I press ` (left, upper corner key) I get _ I set ctrl+_ as zoom in. This mean I have to press US KEYS ctrl and ` the KDE shows it as ctrl+_ (because I set this layout as primary). Now, I add DK layout and I switch to it. To zoom in, I still have to press US KEYS ctrl+` and still KDE shows this shortcut as ctrl+_. But in DK when I press US KEY ` alone I get < at >. So, in short -- shared key-permanent shorcuts: a) shortcuts KEYS are not moved during layout switch, you use the same KEYS b) it is up to user what layout KDE uses for displaying shortcuts (it does not have to be hardware keyboard layout) c) shortcuts always are displayed the same, no matter the layout is used d) shorcuts are shared The report for this on bugzilla: http://bugs.kde.org/show_bug.cgi?id=176113 Cheers, PS. Please keep Esben and me on CC when replying because we are not subscribed to this ML, thank you in advance.

qt-copy printing broken?

John Layt — 2008-11-25T22:53:30

Hi, I'm running qt-copy and trunk using the scripts from techbase and I'm getting a crash on a QAssert in qprintdialog whenever I try to print (log snippet below). Is anyone else seeing this, or is it just a problem with my system? Cheers! John. -------------------------------------------------------------------------- Thread 1 (Thread 0x7f1baf19d750 (LWP 19353)): [KCrash Handler] #4 0x00007f1bab264715 in raise () from /lib64/libc.so.6 #5 0x00007f1bab265d03 in abort () from /lib64/libc.so.6 #6 0x00007f1babf8a7fd in qt_message_output (msgType=QtFatalMsg, buf=0x7fffb71d9ce0 "ASSERT: \"index >= 0\" in file dialogs/qprintdialog_unix.cpp, line 731") at global/qglobal.cpp:2102 #7 0x00007f1babf8a90c in qFatal (msg=0x7f1bac0cf618 "ASSERT: \"%s\" in file %s, line %d") at global/qglobal.cpp:2303 #8 0x00007f1babf8ad19 in qt_assert (assertion=0x7f1bacb7a963 "index >= 0", file=0x7f1bacb7a945 "dialogs/qprintdialog_unix.cpp", line=731) at global/qglobal.cpp:1872 #9 0x00007f1bac9b7688 in QUnixPrintWidgetPrivate::_q_printerChanged (this=0xb33100, index=-1) at dialogs/qprintdialog_unix.cpp:731 #10 0x00007f1bac9b7ab9 in QUnixPrintWidgetPrivate::setOptionsPane (this=0xb33100, pane=0xb32d20) at dialogs/qprintdialog_unix.cpp:797 #11 0x00007f1bac9b8eba in QPrintDialogPrivate::init (this=0xb32d20) at dialogs/qprintdialog_unix.cpp:389 #12 0x00007f1bac9b9222 in QPrintDialog (this=0xb30320, printer=0x7fffb71dc560, parent=0x6e1b90) at dialogs/qprintdialog_unix.cpp:577 #13 0x00007f1bada41d23 in KdePrint::createPrintDialog (printer=0x7fffb71dc560, customTabs=< at >0x7fffb71dc550, parent=0x6e1b90) at /media/laptop/Programming/KDE/src/trunk/KDE/kdelibs/kdeui/dialogs/kdeprintdialog.cpp:40 #14 0x00007f1ba0e3a66c in KatePrinter::print (doc=0x7467a0) at /media/laptop/Programming/KDE/src/trunk/KDE/kdelibs/kate/utils/kateprinter.cpp:82

KDE Trunk: easy way out

Dotan Cohen — 2008-11-22T12:53:09

I would like to test a fairly recent KDE Trunk, but I would like to avoid building from source. I had gone to the KDE4Daily project but is no longer functioning. The only project that I see which is recent to within a few days seems to be the Suse "KDE Four Live" CD: http://home.kde.org/~binner/kde-four-live/ How well does this represent KDE Trunk for the time it was built? I know that Suse changes many KDE details for Open Suse releases, but I do not know if this KDE Four Live CD is changed such. If it is altered, what other options do I have for a recent Trunk build that is either a Live CD (preferable for composing support, which I would also like to test) or a Virtualbox / qemu image. Thanks.

[PATCH] Klipper port to KConfigXT - patch or a feature?

Dmitry Suzdalev — 2008-11-27T14:26:47

[PATCH] thread-safe KQueuedDialog episode 2

Sebastian Trueg — 2008-11-27T09:35:42

following my previous patches to make KDialogQueue thread-safe I figured that for it to work the KDialogQueue had to be created in the GUI thread. That is not always the case. Thus, in this new patch I move the queue to the main GUi thread if possible. I would like to have opinions on that. Is it completely over the top? Cheers, Sebastian Index: kdialog.cpp =================================================================== --- kdialog.cpp(revision 888795) +++ kdialog.cpp(working copy) < at >< at > -3,6 +3,7 < at >< at > * Additions 1999-2000 by Espen Sand (espen< at >kde.org) * by Holger Freyther kde.org> * 2005-2006 by Olivier Goffart (ogoffart at kde.org) + * 2008 by Sebastian Trueg (trueg at kde.org) * * This library is free software; you can redistribute it and/or * modify it under the terms of the GNU Library General Public < at >< at > -35,6 +36,7 < at >< at > #include #include #include +#include #include #include < at >< at > -1011,12 +1013,20 < at >< at > KDialogQueue *q; QList< QPointer > queue; bool busy; - }; KDialogQueue* KDialogQueue::self() { K_GLOBAL_STATIC(KDialogQueue, _self) + + // we want KDialogQueue to be thread-safe, i.e. it should be possible + // to queue dialogs from any thread, not only the GUI thread. For that + // to work, the KDialogQueue has to live in the GUI thread. Only then + // the queued connections used below will end up there. + if(_self->thread() != QApplication::instance()->thread() && + _self->thread() == QThread::currentThread()) + _self->moveToThread(QApplication::instance()->thread()); + return _self; } < at >< at > -1037,7 +1047,14 < at >< at > KDialogQueue *_this = self(); _this->d->queue.append( dialog ); - QTimer::singleShot( 0, _this, SLOT( slotShowQueuedDialog() ) ); + // move the dialog to the GUI thread + if(dialog->thread() != QApplication::instance()->thread() && + dialog->thread() == QThread::currentThread()) + dialog->moveToThread(QApplication::instance()->thread()); + + // We use a queued connection to be able to use queued dialogs + // from threads other than the GUI thread (example: KMessageBox) + QMetaObject::invokeMethod( _this, "slotShowQueuedDialog", Qt::QueuedConnection ); } void KDialogQueue::Private::slotShowQueuedDialog() < at >< at > -1058,8 +1075,11 < at >< at > busy = false; delete dialog; - if ( !queue.isEmpty() ) - QTimer::singleShot( 20, q, SLOT( slotShowQueuedDialog() ) ); + if ( !queue.isEmpty() ) { + // We use a queued connection to be able to use queued dialogs + // from threads other than the GUI thread (example: KMessageBox) + QMetaObject::invokeMethod( q, "slotShowQueuedDialog", Qt::QueuedConnection ); + } } #include "kdialog.moc"

Binary compatibility issues - code placement

Rafael Fernández López — 2008-11-26T22:14:53

Hi, I have been asked by Fredrik (I think he told me this) to do the "hover in shape" he did for FolderView plasmoid but in a more general shape: on a general itemview. The technical issue is really straight forward: reimplement itemAt from QListView. It works quite fine. The idea of "hover in shape" is to have items-of-same-size when hovering, but still being able to reach the viewport. This is managed by making the item only be hovered if we hover for instance, the icon or the text itself of that item. On the moment it it shown as hovered, the whole rect of the item is painted (well, look at folder view plasmoid to know about what I am talking here). The problem ? We would need KListView (reimplements itemAt virtual method) and KItemDelegate (adds a new method, returning the contents shape of the item). It would be nice if this list would be used by Dolphin (kdebase) and the open/save dialog (kdelibs). So, the issue is not technical, but "of order". Where could we place this, knowing that making this public on the API (exporting it on any library) is just crazy ? I was thinking that we could probably somehow create a library for KDE internal usage where we actually warning "do not link against this" as _p.h headers of Qt are "WE MEAN IT". Removing classes from there, would still be binary incompatible when removing classes that will be unused on the future ? What if we statically link this library ? ==== o ==== At other level, I have been planning to somehow rewrite KCategorizedView, since testing with Qt 4.5 it seems the layouting is broken, and basically also because I am not happy at all internally with it... If there was no chance of success with the previous proposals, maybe I could add a method to KCategorizedView which would only hover on shape. Dolphin already uses it, and it would be really trivial to make the open/save dialog using it. Regards, Rafael Fernández López.

fish kioslave windows patch

Carlo — 2008-11-26T17:44:27

like for the sftp kioslave, I've made a patch to port fish to windows too so if someone could test it on other platforms to check that I haven't broken anything

KStyle::defaultStyle() related

Ralf Habacker — 2008-11-25T10:02:21

Hi, in kdelibs/kdeui/kernel/kglobalsettings.cpp there is the following code snippet void KGlobalSettings::Private::applyGUIStyle() { const QLatin1String currentStyleName(qApp->style()->metaObject()->className()); if (kde_overrideStyle.isEmpty()) { #ifdef Q_WS_X11 const QString &defaultStyle = KStyle::defaultStyle(); #else const QString defaultStyle; // Mac, Windows: no change for style by default #endif const KConfigGroup pConfig(KGlobal::config(), "General"); const QString &styleStr = pConfig.readEntry("widgetStyle", defaultStyle); ... This code seems to me a special hack for non x11 platforms to be able to use a "native" default style, which is not supported by the recent implementation of KStyle:defaultStyle(), which is hardcoded to "oxygen". Would it not make the code clearer to extend KStyle::defaultStyle() with the platform related native style like shown below ? QString KStyle::defaultStyle() { #ifndef Q_WS_X11 return QString(""); // native #else return QString("oxygen"); #endif } Then the first code snippet above could be eased to void KGlobalSettings::Private::applyGUIStyle() { const QLatin1String currentStyleName(qApp->style()->metaObject()->className()); if (kde_overrideStyle.isEmpty()) { const QString &defaultStyle = KStyle::defaultStyle(); const KConfigGroup pConfig(KGlobal::config(), "General"); const QString &styleStr = pConfig.readEntry("widgetStyle", defaultStyle); ... I would apply the required changes to trunk and other branches if required if there are no objections Regards Ralf

[PATCH] thread-safe queued KDialogs

Sebastian Trüg — 2008-11-22T22:00:45