Re: My Plans, Your Plans: Berlin Desktop Summit
Hi all On Thu, Jul 28, 2011 at 07:59, Martin Gräßlin wrote: > On Wed, 27 Jul 2011 15:40:11 +0200, "Aaron J. Seigo" 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 8:04 AM, Aaron J. Seigo wrote: > 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 > Perhaps the involved people from KDE and Gnome should just sit down in an IRC chat room and talk about it. note: congrats on the KDE 4.7 release!
Re: Formal complaint concerning the use of the name "System Settings" by GNOME
On Thu, Jul 28, 2011 at 10:07, Mark 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=16&name=kdeui-kglobalsettingstest&date=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 07/27/2011 03:40 PM, Aaron J. Seigo wrote: hi :) BDS is coming up rather quickly and i've been doing some personal planning for it today. i realized in one of those "i just realized the obvious, doh!" moments that i have very little idea of what others are planning and hoping for the event. it was a quick hop from there to realize that probably nobody knew what i planned and hoped for either. given that this is one of the most important events in KDE's annual calendar, this was a little shocking to me once i thought about it. i'd like to help make BDS a raging success this year for us (and i'm sure you all want and expect the same :) and it would help if i (and others) could arrive with some idea of what we're all arriving with in terms of expectations. so .. here are my primary goals: My plans for the desktop summit are * finally meet people behind some nicks * understand a bit better (and eventually organize) this "active browser" * try to organize a sort of meeting (annual?) for people interested in "web/network applications" (konquers, rekonquers, kdewebkitters & khtmlers, kioers, nice girls, etc..) and... * have an enjoyable time with everyone who shows up :) Cheers, -- Andrea Diamantini, adjam GPG Fingerprint: 57DE 8E32 7D1A 0E16 AA52 59D8 84F9 3ECD DBF9 730F rekonq project WEB: http://rekonq.kde.org IRC: rekonq@freenode
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 wrote: > > On Wed, 27 Jul 2011 15:40:11 +0200, "Aaron J. Seigo" 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
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/102098/#review5166
---
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
#include
#include
#include
#include
-
+#include
/**
* 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");
}
}
- Aurélien
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=16&name=kdeui-kglobalsettingstest&date=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
> 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
> > #include
> > #include
> > #include
> > #include
> > -
> > +#include
> > /**
> > * 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=16&name=kdeui-kglobalsettingstest&date=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 wrote: > On Thu, Jul 28, 2011 at 10:11:32AM +0200, Lydia Pintscher wrote: >> On Thu, Jul 28, 2011 at 10:07, Mark 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
> > #include
> > #include
> > #include
> > #include
> > -
> > +#include
> > /**
> > * 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=16&name=kdeui-kglobalsettingstest&date=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: Formal complaint concerning the use of the name "System Settings" by GNOME
Am Thu, 28 Jul 2011 01:15:46 +0200 schrieb Olav Vitters : > However, that is not our goal. We want something simple. For > everything part of GNOME Core we have say what it does instead of > putting the git module name in the menu. 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"? Cheers, Thomas
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 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 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-devel&m=130762214616848&w=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 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-devel&m=130762214616848&w=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! :)
