Re: Formal complaint concerning the use of the name System Settings by GNOME
On Monday, July 25, 2011 10:30:46 Lydia Pintscher wrote: This whole debate is way too heated and I'd like to take this out ofthe arena. Are there 2 or 3 people on the GNOME side that areavailable to talk this through and find a solution? Ideally whoevermaintains system settings on the GNOME side would be one of them.I'd like to work with them and Ben on finding a good solution. Has anyone stepped up for this yet? It's something that deserves resolution and Lydia is willing to help facilitate, now we just need the relevant people involved to participate. I don't foresee it being a long process, but one that ought to be taken on and gotten out of the way. Hopefully those involved in the relevant GNOME and the KDE projects can appreciate this on behalf of our users and, with Lydia's help in keeping things constructive and out of the bikeshed, we can quickly put this behind us and move on to bigger and better things. :) Cheers ... -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part.
Re: My Plans, Your Plans: Berlin Desktop Summit
Hi all On Thu, Jul 28, 2011 at 07:59, Martin Gräßlin mgraess...@kde.org wrote: On Wed, 27 Jul 2011 15:40:11 +0200, Aaron J. Seigo ase...@kde.org wrote: (and others wrote as well) ... Interestingly these plans all sound great for Akademy, but since it is a Desktop Summit I would love to hear what cross-desktop plans there are within our community. Or am I the only one missing something here? Regards, Myriam -- Protect your freedom and join the Fellowship of FSFE: http://www.fsfe.org Please don't send me proprietary file formats, use ISO standard ODF instead (ISO/IEC 26300)
Re: Formal complaint concerning the use of the name System Settings by GNOME
On Thu, Jul 28, 2011 at 10:07, Mark mark...@gmail.com wrote: Perhaps the involved people from KDE and Gnome should just sit down in an IRC chat room and talk about it. That is pretty much exactly what I'm trying to organize. But I need to know who that would be from the GNOME-side. note: congrats on the KDE 4.7 release! Thanks! Cheers Lydia -- Lydia Pintscher KDE Community Working Group member http://kde.org - http://about.me/lydia.pintscher
Re: Review Request: Use platform palette and fonts when running on other desktop environments
On July 2, 2011, 9:49 p.m., Oswald Buddenhagen wrote: hmm. but now things are still done twice in a kde session, no? what was wrong with the suggestion to notify qt that it should update stuff? Aurélien Gâteau wrote: createApplicationPalette() is indeed called twice when running on a KDE session, but it is not a regression introduced by this change so I think it is outside of the scope for now. I tried not doing anything in kdisplaySetPalette() and call qt_x11_apply_settings_in_all_apps() from the kcm as Olivier suggested, but that didn't work: the palette change was not propagated to the running application. What worries me right now is that the text area of KWrite does not get updated at runtime. I thought it was due to the widget being custom, but it correctly updates itself without the patch. Aurélien Gâteau wrote: Finally found time to do more testing. It turns out the behavior of KWrite text area is the same with or without the patch so it's not a regression. Therefore, I think the patch should go in. Thomas Lübking wrote: Sh*t - i forgot that I wanted to comment on that: kate keeps own color schemes for the text area, they're completely unrelated to he rest of the system. (since you need to configure syntax highlightning and don't want that to run into a conflict with the system palette de toujours) So yes, that's not a regression for sure, sorry. Dominik Haumann wrote: With regard to kwrite: It uses the system colors as long as they were never changed. Changed once, these system settings are overwritten. Hence, this is very likely a KatePart issue. Aurélien Gâteau wrote: Oh. Thanks Thomas and Dominik, it suddenly makes more sense! If there is no other objection I'd like to merge this patch this week. Anyone against that? Aurélien Gâteau wrote: I just merged the changes in. Unless I spot some obvious regressions, I plan to backport the patch in time for 4.7.1. Frank Reininghaus wrote: Could it be that your commit caused the recent kglobalsettingstest failures seen on CDash? http://my.cdash.org/testSummary.php?project=16name=kdeui-kglobalsettingstestdate=2011-07-25 On my machine (kongresszentrum), the kde-devel user runs the unit tests in a Konsole inside the regular user's KDE 4.6 session. That's quite possible indeed. Looking into it. - Aurélien --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101805/#review4333 --- On July 2, 2011, 9:19 p.m., Aurélien Gâteau wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101805/ --- (Updated July 2, 2011, 9:19 p.m.) Review request for kdelibs and Olivier Goffart. Summary --- When a KDE application is running on GNOME it looks odd right now because it does not use the GNOME palette and fonts, contrary to Qt-only applications. Attached patch fixes this by relying on the platform plugin to set the correct palette and fonts if we are not running in a full KDE session. Patch was suggested by Olivier Goffart. Diffs - kdeui/kernel/kglobalsettings.cpp 1a497c7 Diff: http://git.reviewboard.kde.org/r/101805/diff Testing --- # On KDE - Run kwrite on KDE = KDE palette and fonts - Change palette and fonts from System Settings = kwrite updates itself correctly # On GNOME - Run kwrite on GNOME = GNOME palette and fonts - Change palette and fonts from GNOME Tweak Tool = palette gets applied, font does not for now Thanks, Aurélien
Re: My Plans, Your Plans: Berlin Desktop Summit
On Thursday, July 28, 2011 00:54:50 Nicolas Alvarez wrote: Sebastian Kügler wrote: One of my goals is to take steps to make the release team more scalable, and reduce its bus numbers. Surely you mean increase :) A bus number of 1 means the team has a single point of failure. Ah, yes of course. Increase bus number, reduce risk. :) -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: My Plans, Your Plans: Berlin Desktop Summit
On Thursday, July 28, 2011 09:35:57 Myriam Schweingruber wrote: Hi all On Thu, Jul 28, 2011 at 07:59, Martin Gräßlin mgraess...@kde.org wrote: On Wed, 27 Jul 2011 15:40:11 +0200, Aaron J. Seigo ase...@kde.org wrote: (and others wrote as well)... Interestingly these plans all sound great for Akademy, but since it isa Desktop Summit I would love to hear what cross-desktop plans thereare within our community. Or am I the only one missing something here? i don't think you're missing anything; it's just that my near-term priorities are fairly KDE centric right now, which is a reflection of the current state of the projects i am most involved in right now. others will have x-desktop plans / hopes / aspirations for their time at BDS. the people working on telepathy, secret service, dconf, nepomuk/zeitgeist, etc. etc. spring to mind. and that's why i've asked for what people are planning / wanting to be doing at BDS so we can all get a reasonable feel for things like who should i hunt down for x-desktop topics because i also have interest in those topics... :) -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part.
Re: My Plans, Your Plans: Berlin Desktop Summit
My plans for BDS include: · Drink Northen German beer · Pay some beers to some KDE hackers and active community · Improve the communication between platform developers and us NetworkManager BlueZ UPower UDisk UNextThink etc... · Draft a plan for colord integration (next thing after krandr is fixed) · Draft a plan for systemd kde-workspace integration (there are a couple of things we can do I think) · Draft a plan for KDE-Workspace XRandR fixes including: How KWin will react on events How and WHEN plasma-* will react on events Fix KWin window sizeing/positioning bugs Agreed on how to clean geometry.cpp and workspace.cpp files · Spicy up plasma-desktop development by starting to define some common ground between the different views out there.
Re: Review Request: Fix KGlobalSettingsTest failure
On July 28, 2011, 10:26 a.m., Aurélien Gâteau wrote:
I don't think it is good for unit-tests to test different things depending
on environment variables (
@David, what is your opinion on the subject?)
I was actually about to commit a simpler fix:
@@ -26,11 +26,11 @@ QTEST_KDEMAIN( KGlobalSettingsTest, GUI )
#include kglobalsettings.h
#include kdebug.h
#include kprocess.h
#include QtCore/QEventLoop
#include QtDBus/QtDBus
-
+#include stdlib.h
/**
* The strategy of this test is:
* We install QSignalSpy instances on many signals from
KGlobalSettings::self(),
* and then we get another process (kglobalsettingsclient) to call
emitChange(),
* and we check that the corresponding signals are emitted, i.e. that our
process
@@ -39,10 +39,15 @@ QTEST_KDEMAIN( KGlobalSettingsTest, GUI )
* As a nice side-effect we automatically test a bit of KProcess as well :)
*/
void KGlobalSettingsTest::initTestCase()
{
+// Some signals are only emitted when we are running a full KDE
session. If
+// we are not then KDE applications follow the platform palette and
font
+// settings.
+setenv(KDE_FULL_SESSION, 1, 1);
+
QDBusConnectionInterface *bus = 0;
if (!QDBusConnection::sessionBus().isConnected() || !(bus =
QDBusConnection::sessionBus().interface())) {
QFAIL(Session bus not found);
}
}
I fully agree that the things that are tested should better not depend on
environment variables, and I can confirm that the test passes here with your
patch applied. I hadn't tried this myself earlier because I had assumed that
the variable has to be set *before* the test executable is run, but that's
obviously wrong ;-)
Maybe it would be even better to always test both things (i.e., that signals
are emitted when KDE_FULL_SESSION is set and that they aren't when it's not
set) if we find a good way to do it? That way, we would also test that the
things that your recent commit changed work as they should.
- Frank
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/102098/#review5166
---
On July 27, 2011, 4:31 p.m., Frank Reininghaus wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/102098/
---
(Updated July 27, 2011, 4:31 p.m.)
Review request for kdelibs, Aurélien Gâteau and David Faure.
Summary
---
Since commit b064749a754ec358170ecb7f19828e4216f6e965, KDE palette and font
settings are only used when running KDE apps in a full KDE session. This
makes KGlobalSettingsTest fail if the test is not run in a full KDE session,
see
http://my.cdash.org/testSummary.php?project=16name=kdeui-kglobalsettingstestdate=2011-07-27
This commit changes KGlobalSettings' unit test to reflect that change. My
first idea was to change the unit test such that it verifies the expected
behaviour for both situations, i.e., apps run in a full KDE session and apps
run in some other kind of session, but I could not figure out a way to do
this without changing the KDE_FULL_SESSION environment variable before the
unit test executable is run.
In the case that the signal is not expected, I reduced the kWaitForSignal
timeout to prevent wasting too much time each time the test is run.
Diffs
-
kdeui/tests/kglobalsettingstest.h 69ed5bf
kdeui/tests/kglobalsettingstest.cpp 464825d
Diff: http://git.reviewboard.kde.org/r/102098/diff
Testing
---
The test passes here (run by my kde-devel user in a Konsole inside the
regular user's KDE 4.6 session).
Thanks,
Frank
Re: Review Request: Fix KGlobalSettingsTest failure
void KGlobalSettingsTest::initTestCase()
{
+// Some signals are only emitted when we are running a full KDE
session. If
+// we are not then KDE applications follow the platform palette and
font
+// settings.
+setenv(KDE_FULL_SESSION, 1, 1);
+
qputenv()?
Eike
Re: Formal complaint concerning the use of the name System Settings by GNOME
On Thu, Jul 28, 2011 at 11:24, Olav Vitters o...@vitters.nl wrote: On Thu, Jul 28, 2011 at 10:11:32AM +0200, Lydia Pintscher wrote: On Thu, Jul 28, 2011 at 10:07, Mark mark...@gmail.com wrote: Perhaps the involved people from KDE and Gnome should just sit down in an IRC chat room and talk about it. That is pretty much exactly what I'm trying to organize. But I need to know who that would be from the GNOME-side. gnome-control-center maintainers are listed at: http://git.gnome.org/browse/gnome-control-center/tree/gnome-control-center.doap and to see who actually commits things: http://git.gnome.org/browse/gnome-control-center/log Thanks Olav. I'll send some emails. Cheers Lydia -- Lydia Pintscher KDE Community Working Group member http://kde.org - http://about.me/lydia.pintscher
Re: Review Request: Fix KGlobalSettingsTest failure
On July 28, 2011, 10:26 a.m., Aurélien Gâteau wrote:
I don't think it is good for unit-tests to test different things depending
on environment variables (
@David, what is your opinion on the subject?)
I was actually about to commit a simpler fix:
@@ -26,11 +26,11 @@ QTEST_KDEMAIN( KGlobalSettingsTest, GUI )
#include kglobalsettings.h
#include kdebug.h
#include kprocess.h
#include QtCore/QEventLoop
#include QtDBus/QtDBus
-
+#include stdlib.h
/**
* The strategy of this test is:
* We install QSignalSpy instances on many signals from
KGlobalSettings::self(),
* and then we get another process (kglobalsettingsclient) to call
emitChange(),
* and we check that the corresponding signals are emitted, i.e. that our
process
@@ -39,10 +39,15 @@ QTEST_KDEMAIN( KGlobalSettingsTest, GUI )
* As a nice side-effect we automatically test a bit of KProcess as well :)
*/
void KGlobalSettingsTest::initTestCase()
{
+// Some signals are only emitted when we are running a full KDE
session. If
+// we are not then KDE applications follow the platform palette and
font
+// settings.
+setenv(KDE_FULL_SESSION, 1, 1);
+
QDBusConnectionInterface *bus = 0;
if (!QDBusConnection::sessionBus().isConnected() || !(bus =
QDBusConnection::sessionBus().interface())) {
QFAIL(Session bus not found);
}
}
Frank Reininghaus wrote:
I fully agree that the things that are tested should better not depend on
environment variables, and I can confirm that the test passes here with your
patch applied. I hadn't tried this myself earlier because I had assumed that
the variable has to be set *before* the test executable is run, but that's
obviously wrong ;-)
Maybe it would be even better to always test both things (i.e., that
signals are emitted when KDE_FULL_SESSION is set and that they aren't when
it's not set) if we find a good way to do it? That way, we would also test
that the things that your recent commit changed work as they should.
I agree testing both would be even nicer. Maybe you can mix your patch with
mine to do it, calling setenv(KDE_FULL_SESSION, 1, 1) to fake the run in
KDE session situation and unsetenv(KDE_FULL_SESSION) to fake the 'run
outside KDE session' situation?
- Aurélien
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/102098/#review5166
---
On July 27, 2011, 4:31 p.m., Frank Reininghaus wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/102098/
---
(Updated July 27, 2011, 4:31 p.m.)
Review request for kdelibs, Aurélien Gâteau and David Faure.
Summary
---
Since commit b064749a754ec358170ecb7f19828e4216f6e965, KDE palette and font
settings are only used when running KDE apps in a full KDE session. This
makes KGlobalSettingsTest fail if the test is not run in a full KDE session,
see
http://my.cdash.org/testSummary.php?project=16name=kdeui-kglobalsettingstestdate=2011-07-27
This commit changes KGlobalSettings' unit test to reflect that change. My
first idea was to change the unit test such that it verifies the expected
behaviour for both situations, i.e., apps run in a full KDE session and apps
run in some other kind of session, but I could not figure out a way to do
this without changing the KDE_FULL_SESSION environment variable before the
unit test executable is run.
In the case that the signal is not expected, I reduced the kWaitForSignal
timeout to prevent wasting too much time each time the test is run.
Diffs
-
kdeui/tests/kglobalsettingstest.h 69ed5bf
kdeui/tests/kglobalsettingstest.cpp 464825d
Diff: http://git.reviewboard.kde.org/r/102098/diff
Testing
---
The test passes here (run by my kde-devel user in a Konsole inside the
regular user's KDE 4.6 session).
Thanks,
Frank
Re: Review Request: Fix logic with clear-button animation in klineedit (notably at first try) and address bug 268898.
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102095/#review5179 --- This review has been submitted with commit a456e8600b63300d520b074a6d71d74219df3058 by Hugo Pereira Da Costa to branch master. - Commit On July 26, 2011, 9:54 p.m., Hugo Pereira Da Costa wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102095/ --- (Updated July 26, 2011, 9:54 p.m.) Review request for kdelibs. Summary --- Details: - fixes the somewhat incorrect logic in KLineEditButton::animateVisible - simplifies KLineEdit::updateClearButtonIcon consequently. This addresses bug 268898. http://bugs.kde.org/show_bug.cgi?id=268898 Diffs - kdeui/widgets/klineedit.cpp 8f1c8a4 kdeui/widgets/klineedit_p.h 95016bd Diff: http://git.reviewboard.kde.org/r/102095/diff Testing --- tested with klineedittest found in kdelibs/kdeui/tests, this with and without the patch attached to comment #1 of bug 268898, used to actually trigger the mentionned bug. Also tested with other klineEdit implementation such as Dolphin's location bar. Thanks, Hugo
Re: Formal complaint concerning the use of the name System Settings by GNOME
On Thu, Jul 28, 2011 at 10:11:32AM +0200, Lydia Pintscher wrote: On Thu, Jul 28, 2011 at 10:07, Mark mark...@gmail.com wrote: Perhaps the involved people from KDE and Gnome should just sit down in an IRC chat room and talk about it. That is pretty much exactly what I'm trying to organize. But I need to know who that would be from the GNOME-side. gnome-control-center maintainers are listed at: http://git.gnome.org/browse/gnome-control-center/tree/gnome-control-center.doap and to see who actually commits things: http://git.gnome.org/browse/gnome-control-center/log -- Regards, Olav
Re: Formal complaint concerning the use of the name System Settings by GNOME
On 28 July 2011 08:51, Thomas Lübking thomas.luebk...@gmail.com wrote: I thought that was what the GenericName entry was supposed to be good for, so gnome-terminal.desktop would have Name=GNOME Terminal GenericName=Terminal Exec=gnome-terminal and the runner/menu could use the GenericName unless there's a clash (cause konsole's GenericName is Terminal as well) where it could fall back to the Name enties for disambiguation. So my question regarding all this flood in my inbox would be: Does gnome-control-center now use System Settings for the GenericName or the Name entry of gnome-control-center so whether there's a real issue with disambiguation (as long as you want to avoid invoking the Exec string) or just runner/menu xyz is too stupid to resolve ambiguities? Here's what the .desktop files look like: http://git.gnome.org/browse/gnome-control-center/tree/shell/gnome-control-center.desktop.in.in https://projects.kde.org/projects/kde/kdebase/kde-workspace/repository/revisions/master/annotate/systemsettings/app/systemsettings.desktop Jeremy Bicha
Re: KF5 Qt5 - QtCS Session
Hi, A draft list was made of some areas for focus with names drafted in against them: ... * KJob - Qt-Addon for 5.1 Is the lack of manpower the reason or something else it is not planned against 5.0 ? I have made some simple modifications in our project where it is now KDE dependency free. This is by no means complete yet so please suggest other areas and names. How about these classes ? http://api.kde.org/4.5-api/kdelibs-apidocs/kdecore/html/classKArchive.html There have been many times that I have experience the need for archiving operations inside Qt framework, in various pure Qt projects. This has also been the feedback from more friends about their projects. Here you can find an example in this thread: http://lists.kde.org/?l=kde-develm=130762214616848w=2. It currently requires more things to port prior to getting it work. It uses KSaveFile for atomic file operation and some dependencies from kde_file.h and kde_file_win.h. The subclasses of KArchive also use the KFilterDev class internally and KMimeType. As we can see, mimetypes are on the way, at least it is in your list. ;-) I have been trying to experiment with them in our pure Qt codebase for a while, and there is some progress. It might be that, it is a bit late. Unfortunately, I have just only now found the time to answer. I am not sure about the legal part of kde codebase reuse, but let me know if there is anything i can do to help. Thank you in advance! :) Best Regards, Laszlo Papp
Re: X11 expert help needed
On Monday 18 July 2011 22:43:20 Alexander Neundorf wrote: Hi, I'm currently comparing our FindX11.cmake with the one in current cmake. Our copy is in kdelibs/cmake/modules/, CMake's is in its Module/ directory. There are some things our version checks for, which the one from cmake doesn't, and vice versa. Also, we append more of the libs to the X11_LIBRARIES variable. Is this good ? Should the stuff we do just be merged into the cmake version ? Can somebody who knows more about X11 please have a look at these two files, one in kdelibs, the other one in cmake 2.8.5 or git HEAD ? http://cmake.org/gitweb?p=cmake.git;a=summary Helping hands are very appreciated :-) I just had a look at the diff. As far as I have seen the KDE version includes checks for * XSync * Xkbfile * SM For XSync I can find a #ifdef HAVE_XSYNC in kde-workspace/kwin/client.cpp No idea if it is really required, but at least it's used. Though I cannot find a check in either the toplevel or kwin's CMakeLists.txt. Xkbfile is used by the keyboard KCM and is checked in kde-workspace CMakeLists.txt if(NOT X11_Xkbfile_FOUND) macro_log_feature(X11_Xkbfile_FOUND libXkbfile X11 keyboard layout library http://xorg.freedesktop.org; TRUE Needed for keyboard modules.) endif(NOT X11_Xkbfile_FOUND) SM sounds like it would be needed by ksmserver. But at least in the CMakeLists.txt I could not find a usage. Maybe an idea would be to git blame the file and contact the devs why they added the checks. In the other direction it seems like only Xi is in CMake version which is missing in KDE's. I think it would make sense to update the KDE's one. Cheers Martin signature.asc Description: This is a digitally signed message part.
Re: KF5 Qt5 - QtCS Session
On Thu, Jul 28, 2011 at 4:25 PM, Laszlo Papp lp...@kde.org wrote: Hi, A draft list was made of some areas for focus with names drafted in against them: ... * KJob - Qt-Addon for 5.1 Is the lack of manpower the reason or something else it is not planned against 5.0 ? I have made some simple modifications in our project where it is now KDE dependency free. This is by no means complete yet so please suggest other areas and names. How about these classes ? http://api.kde.org/4.5-api/kdelibs-apidocs/kdecore/html/classKArchive.html There have been many times that I have experience the need for archiving operations inside Qt framework, in various pure Qt projects. This has also been the feedback from more friends about their projects. Here you can find an example in this thread: http://lists.kde.org/?l=kde-develm=130762214616848w=2. It currently requires more things to port prior to getting it work. It uses KSaveFile for atomic file operation and some dependencies from kde_file.h and kde_file_win.h. The subclasses of KArchive also use the KFilterDev class internally and KMimeType. As we can see, mimetypes are on the way, at least it is in your list. ;-) I have been trying to experiment with them in our pure Qt codebase for a while, and there is some progress. It might be that, it is a bit late. Unfortunately, I have just only now found the time to answer. I am not sure about the legal part of kde codebase reuse, but let me know if there is anything i can do to help. Thank you in advance! :) Best Regards, Laszlo Papp I second that! It is so painfull in Qt when you want to use archives that there is nearly nothing for it.. KArchive would be a real nice addition to Qt but i'm guessing that means KTar, KZip and KAr to also get in along with some framework to add other formats.. I'm not expecting this to happen, but it would be awesome to have it in! :)
