http://blog.gmane.org/gmane.comp.kde.devel.core hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.comp.kde.devel.core/55986 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 ============================== Ralf Habacker 2008-12-01T11:32:08 http://comments.gmane.org/gmane.comp.kde.devel.core/55980 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) Jordi Polo 2008-12-01T04:05:19 http://comments.gmane.org/gmane.comp.kde.devel.core/55978 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 Louai Al-Khanji 2008-12-01T00:17:15 http://comments.gmane.org/gmane.comp.kde.devel.core/55965 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 Maciej Pilichowski 2008-11-26T14:00:23 http://comments.gmane.org/gmane.comp.kde.devel.core/55964 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 QUnixPrintWidgetP John Layt 2008-11-25T22:53:30 http://comments.gmane.org/gmane.comp.kde.devel.core/55963 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. Dotan Cohen 2008-11-22T12:53:09 http://comments.gmane.org/gmane.comp.kde.devel.core/55947 Dmitry Suzdalev 2008-11-27T14:26:47 http://comments.gmane.org/gmane.comp.kde.devel.core/55943 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 <freyther< at >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 <QTimer> #include <QVBoxLayout> #include <QWhatsThis> +#include <QtCore/QThread> #include <klocal Sebastian Trueg 2008-11-27T09:35:42 http://comments.gmane.org/gmane.comp.kde.devel.core/55935 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 Rafael Fernández López 2008-11-26T22:14:53 http://comments.gmane.org/gmane.comp.kde.devel.core/55932 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 Carlo 2008-11-26T17:44:27 http://comments.gmane.org/gmane.comp.kde.devel.core/55916 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 # Ralf Habacker 2008-11-25T10:02:21 http://comments.gmane.org/gmane.comp.kde.devel.core/55893 Sebastian Trüg 2008-11-22T22:00:45 http://comments.gmane.org/gmane.comp.kde.devel.core/55878 Hi all, long time no post from me, eh... During, and as a continuation of, my SOC project I did some work in KIO that didn't make it for 4.2 due to the vagarities of networking and the need for a large amount of testing and also bugfixing that I didn't put the necessary time into, really. The changes I'm going to describe not only expose but also create bugs in the sense that things that were maybe not nice are flat out broken with them. Most importantly KIO users can exhibit stalls or errors (no idea where the errors come from ATM) if the number of ioslaves is effectively limited. - HTTP pipelining for Konqueror, using a class called PipelineScheduler that is a KIO::SimpleJob and manages a list of jobs to be pipelined. After much debugging of the required functionality in the HTTP ioslave and in the PipelineScheduler class itself... it turns out that some servers are broken as hell. static.flickr.com is the worst example, it drops TCP packets without comment if there is more than one Andreas Hartmetz 2008-11-21T00:56:33 http://comments.gmane.org/gmane.comp.kde.devel.core/55877 Hi all, long time no post from me, eh... During, and as a continuation of, my SOC project I did some work in KIO that didn't make it for 4.2 due to the vagarities of networking and the need for a large amount of testing and also bugfixing that I didn't put the necessary time into, really. The changes I'm going to describe not only expose but also create bugs in the sense that things that were maybe not nice are flat out broken with them. Most importantly KIO users can exhibit stalls or errors (no idea where the errors come from ATM) if the number of ioslaves is effectively limited. - HTTP pipelining for Konqueror, using a class called PipelineScheduler that is a KIO::SimpleJob and manages a list of jobs to be pipelined. After much debugging of the required functionality in the HTTP ioslave and in the PipelineScheduler class itself... it turns out that some servers are broken as hell. static.flickr.com is the worst example, it drops TCP packets without comment if there is more than one Andreas Hartmetz 2008-11-21T00:52:24 http://comments.gmane.org/gmane.comp.kde.devel.core/55873 Hello, I have a patch for CMakeList.txt in kdelibs to solve my own wish (include the svn revision in the --version info) http://bugs.kde.org/show_bug.cgi?id=162179 --- CMakeLists.txt 2008-11-17 12:29:41.765625000 +0100 +++ CMakeLists.txt 2008-11-17 10:06:49.000000000 +0100 < at >< at > -8,9 +8,29 < at >< at > set (KDE_VERSION_MAJOR 4) set (KDE_VERSION_MINOR 1) set (KDE_VERSION_RELEASE 73) set (KDE_VERSION "${KDE_VERSION_MAJOR}.${KDE_VERSION_MINOR}.${KDE_VERSION_RELEASE}" ) -set (KDE_VERSION_STRING "${KDE_VERSION} (KDE 4.1.73 (KDE 4.2 >= 20081112))") + +execute_process(COMMAND svn info --xml WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR} + COMMAND grep -m 1 revision + COMMAND cut -f 2 -d \" + OUTPUT_VARIABLE SVN_REVISION ) +if (SVN_REVISION) + string(STRIP ${SVN_REVISION} SVN_REVISION) + set(SVN_REVISION "r${SVN_REVISION}") +else(SVN_REVISION) + set (SVN_REVISION "${KDE_VERSION}") +endif(SVN_REVISION) + +set (KDE_VERSION_STRI Jaime 2008-11-17T11:41:14 http://comments.gmane.org/gmane.comp.kde.devel.core/55871 hi, all. I find out that kcm_clock have some trivial problems out there. first is that kcmclockrc write to wrong place with bad attributes. and after you choose a timezone, the display zone doesn't change accordingly some times. another problem is that time server list shouldn't be i18n'd, because kcmdatetimehelper won't get correct tzone parameter. patch can be applied to trunk/KDE/kdebase/workspace/kcontrol/dateandtime. anyone please notify me if got better ideas. Index: helper.cpp =================================================================== --- helper.cpp(revision 884069) +++ helper.cpp(working copy) < at >< at > -52,10 +52,14 < at >< at > { int ret = 0; // write to the system config file - KConfig _config( KDE_CONFDIR "kcmclockrc", KConfig::SimpleConfig); + KConfig _config( KDE_CONFDIR "/kcmclockrc", KConfig::SimpleConfig ); KConfigGroup config(&_config, "NTP"); config.writeEntry("servers", ntpServers ); config.writeEntry("enabled", ntpEnabled ); + config.sync(); + if ( !QFile::setPermissions yinshuiboy 2008-11-16T18:38:45 http://comments.gmane.org/gmane.comp.kde.devel.core/55852 Heyya! After reading the following Debian bug report [0] Pino Toscano and me discovered the following: To be able to open links most KDE applications rely on an installed available kfmclient executable [1]. The problem is now: kfmclient is shipped with Konqueror. This means: If Konqueror is not installed a lot of applications are not able to open links even with another configured browser. For KDE user this isn't such a big problem, but a Gnome user e.g. doesn't want to install Konqueror just to be able to open external links. The question is now: How can we solve this problem? I guess in theory kfmclient should be a part of kdebase/runtime and not kdebase/apps, but I don't know if this is feasible in pratice. I didn't check yet how coupled kfmclient and Konqueror are and when distributed -runtime and -apps are two different tarballs. Anyway this problem really must be addressed somehow soon. Greetings, Armin [0] http://bugs.debian.org/506125 [1] See kdelibs/kdecore/kernel/ktoolinvocation.cpp for KDE 4 Armin Berres 2008-11-19T14:01:37 http://comments.gmane.org/gmane.comp.kde.devel.core/55851 -------- Forwarded Messages -------- From: "zhangqiang" <zhangqiang< at >redflag-linux.com> To: kde-devel< at >kde.org Hi : When I use kppp to dial up.I find that it does not support china.Finally I found it was lost of some profile about china. So I added it in the directory :/KDE/kdenetwork/kppp/DB/Provider.Then it goes well.The profile file are in the attachment .Thanks. The bug procedure is as following. kppp : configure->account->new->Wizard->next Here we don't find the china item in the list. Best regards. zhangqiang 2008-11-19T09:53:07 http://comments.gmane.org/gmane.comp.kde.devel.core/55844 Howdy, Today is the last day for any new visible i18n() strings in your code. Cutoff time is our traditional 23:59 UTC Allen Winter 2008-11-18T14:12:17 http://comments.gmane.org/gmane.comp.kde.devel.core/55843 Howdy, Please remember that the Documentation/Handbook Freeze is coming on 25 Nov. [1] [1] http://techbase.kde.org/Schedules/KDE4/4.2_Release_Schedule Allen Winter 2008-11-18T14:05:55 http://comments.gmane.org/gmane.comp.kde.devel.core/55828 Maciej has been pestering me about color kcm bugs :-). Is it still permissible to switch to a different preview widget for the set-specific configuration? I need to know *now* because this will introduce new strings (just simple ones, though, "neutral", "positive", etc., total new strings would be 10 or less, and all are single words). If not it will have to wait for 4.3 :-( (which also means I won't be able to work on it in trunk for several months). Matthew Woehlke 2008-11-17T19:06:31 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.kde.devel.core