Re: Severe behavioural change regressions in release branch
> Earlier this year, I was working on lots of performance metrics of CMake > and this was part of it. There ended up being more than a dozen branches > resulting from that work (some of them still unmerged). Doing some > digging shows that this is where the commit finally hit master: > > commit bd20dd6b8a925a421167602027fff9b904fd0822 > Merge: b041fc1 e17a69b > Author: Brad King > Date: Thu Jun 12 11:28:44 2014 -0400 Yep, I can verify that I had to use on OSX/CI the version from June 3rd for quite a while, since that was the only one which would give me the desired builds. Greets, Marko
Re: Detect window manager using KWindowSystem
Sorry, I've had some problems with my email and the list. Well,
checking the window manager's name is much more reliable, I tested
with many window managers and it worked with all. That's how I'm
doing:
bool LxQtModuleManager::nativeEvent
Filter(const QByteArray & eventType, void * message, long * result)
{
// a new window manager is started
if (!mWmStarted && mWaitLoop)
{
if (!QString(NETRootInfo(QX11Info::connection(),
NET::SupportingWMCheck).wmName()).isEmpty)
{
qDebug() << "Window Manager started";
mWmStarted = true;
if (mWaitLoop->isRunning())
mWaitLoop->exit();
}
}
if (!mTrayStarted && QSystemTrayIcon::isSystemTrayAvailable() && mWaitLoop)
{
qDebug() << "System Tray started";
mTrayStarted = true;
if (mWaitLoop->isRunning())
mWaitLoop->exit();
qApp->removeNativeEventFilter(this);
}
return false;
}
The reason for this is that lxqt-session only open the autostart
progams after the window manager is active (and the programs that ask
for a system tray after the system tray is active as well). There
probably is a better way, but that's our solution for now. Thanks for
your help!
Paulo Lieuthier
On Sun, Oct 19, 2014 at 10:15 AM, Thomas Lübking
wrote:
> On Sonntag, 19. Oktober 2014 15:08:51 CEST, Martin Gräßlin wrote:
>
>> Might be worth adding it:
>> bool NETRootInfo::isCompliantWindowManagerRunning() const?
>
>
> It certainly won't harm, but the question is: who actually needs such?
>
> WM's operate on the WM selection - and right now, i cannot imagine why any
> client should check for that (optional client side window management? ;-)
>
> -> @Paulo, why do you need to check for this? (And do you want a bashlet?
> ;-)
>
> Cheers,
> Thomas
--
Paulo Lieuthier
Porque ainda um pouquinho de tempo, E o que há de vir virá, e não tardará.
-- Hebreus 10:37
Re: [Kde-cvs-announce] KDE Applications 14.12 release
Also there's https://community.kde.org/Frameworks/Application-release-status-December-2014 that you should consider updating. Cheers, Albert El Diumenge, 26 d'octubre de 2014, a les 23:21:26, Albert Astals Cid va escriure: > Two things: > * Freeze is in 3 days, please make sure everything is ready for Beta 1 > release in 10 days > > * As you all know KDE Applications 14.12 will be a release composed of > Applications based on both kdelibs4 and kdeframeworks5. Please make sure > you coordinate with all the libraries/plugin you use or use you so that it > all works fine. > > Please check that > > http://quickgit.kde.org/?p=sysadmin%2Frelease-tools.git&a=blob&h=64c42731d3 > 7c0dc769b78b924d09822c23e6bbe1&hb=5f08b630b9422f90b96f804da29cba5c9b7117e6&f > =modules.git contains all the modules it needs to. The branches are the ones > from where Applications 14.12 will be forked and then released. > > Cheers, > Albert > ___ > > == This is a read-only list. Do not reply to this message. == > > == Unsubscribing is only possible by disabling your KDE commit account == > == To do so, enter KDE Sysadmin Ticket at https://sysadmin.kde.org/tickets/ > ==
Re: Severe behavioural change regressions in release branch
On Mon, Oct 27, 2014 at 6:24 AM, Albert Astals Cid wrote: > Hi guys, what's the status of this? Hi Albert, I'm waiting for the fixes for this issue, in particular http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=5f414cefb6524d26329484b296004e3c2d97ec4f to land in 'release'. Once that happens i'll rebuild CMake on the CI system and rebuild all Frameworks to get the system back into working order. > > As far as i can see it's still unresolved since kcoreaddons is installing much > fewer headers than it used to > > http://build.kde.org/job/kcoreaddons_master_qt5/153/console > vs > http://build.kde.org/job/kcoreaddons_master_qt5/152/console > > Do you think it's a valid case to autotest? I believe tests have now been added to CMake to test for this issue. > > Cheers, > Albert Thanks, Ben > > El Divendres, 24 d'octubre de 2014, a les 19:23:42, Ben Boeckel va escriure: >> On Sat, Oct 25, 2014 at 08:50:12 +1300, Ben Cooksley wrote: >> > On Sat, Oct 25, 2014 at 5:44 AM, Stephen Kelly wrote: >> > > Is build.kde.org now using the release branch of cmake.git instead of >> > > the >> > > next branch? When/why did that change? >> > >> > This was changed around about >> > http://mail.kde.org/pipermail/kde-frameworks-devel/2014-June/016670.html >> > The motivation behind the change was to get the CI system to have the >> > same setup as developers I think, and to avoid regressions in 3.1 >> > which had been causing some build problems at the time. Those same >> > regressions are the ones causing us issues now. >> > >> > Interestingly, the commit which was identified as causing the issue >> > occurred back in March, yet this thread was in June. So perhaps there >> > may be other commits interacting here (or that was the time when the >> > commit previously identified was merged into the next branch). >> >> Earlier this year, I was working on lots of performance metrics of CMake >> and this was part of it. There ended up being more than a dozen branches >> resulting from that work (some of them still unmerged). Doing some >> digging shows that this is where the commit finally hit master: >> >> commit bd20dd6b8a925a421167602027fff9b904fd0822 >> Merge: b041fc1 e17a69b >> Author: Brad King >> Date: Thu Jun 12 11:28:44 2014 -0400 >> >> so June looks right. >> >> --Ben >> ___ >> Kde-frameworks-devel mailing list >> kde-frameworks-de...@kde.org >> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel > > ___ > Kde-buildsystem mailing list > kde-buildsys...@kde.org > https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Severe behavioural change regressions in release branch
Hi guys, what's the status of this? As far as i can see it's still unresolved since kcoreaddons is installing much fewer headers than it used to http://build.kde.org/job/kcoreaddons_master_qt5/153/console vs http://build.kde.org/job/kcoreaddons_master_qt5/152/console Do you think it's a valid case to autotest? Cheers, Albert El Divendres, 24 d'octubre de 2014, a les 19:23:42, Ben Boeckel va escriure: > On Sat, Oct 25, 2014 at 08:50:12 +1300, Ben Cooksley wrote: > > On Sat, Oct 25, 2014 at 5:44 AM, Stephen Kelly wrote: > > > Is build.kde.org now using the release branch of cmake.git instead of > > > the > > > next branch? When/why did that change? > > > > This was changed around about > > http://mail.kde.org/pipermail/kde-frameworks-devel/2014-June/016670.html > > The motivation behind the change was to get the CI system to have the > > same setup as developers I think, and to avoid regressions in 3.1 > > which had been causing some build problems at the time. Those same > > regressions are the ones causing us issues now. > > > > Interestingly, the commit which was identified as causing the issue > > occurred back in March, yet this thread was in June. So perhaps there > > may be other commits interacting here (or that was the time when the > > commit previously identified was merged into the next branch). > > Earlier this year, I was working on lots of performance metrics of CMake > and this was part of it. There ended up being more than a dozen branches > resulting from that work (some of them still unmerged). Doing some > digging shows that this is where the commit finally hit master: > > commit bd20dd6b8a925a421167602027fff9b904fd0822 > Merge: b041fc1 e17a69b > Author: Brad King > Date: Thu Jun 12 11:28:44 2014 -0400 > > so June looks right. > > --Ben > ___ > Kde-frameworks-devel mailing list > kde-frameworks-de...@kde.org > https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
