On Thursday 01 August 2013 00:38:51 Stephen Kelly wrote:
> Kevin Ottens wrote:
> >> So, if this target/variable task is deferred until CMake 2.8.13 can be
> >> used, the variables don't have to be used even in an intermediate state.
> >
> > I see, but when is 2.8.13 supposed to be released? I'd ra
On Thu, Aug 1, 2013 at 12:25 AM, Milian Wolff wrote:
> On Wednesday 31 July 2013 20:51:11 Mark wrote:
> > Hi,
> >
> > I'm horrible in clearly explaining issues and i'm going to explain a
> > lot in this mail. Please read it very carefully.
>
>
>
> > Subsequent signals (even create, delete or any
Kevin Ottens wrote:
>> So, if this target/variable task is deferred until CMake 2.8.13 can be
>> used, the variables don't have to be used even in an intermediate state.
>
> I see, but when is 2.8.13 supposed to be released? I'd rather have us move
> forward.
2.8.12 will be released in a few wee
On Wednesday 31 July 2013 20:51:11 Mark wrote:
> Hi,
>
> I'm horrible in clearly explaining issues and i'm going to explain a
> lot in this mail. Please read it very carefully.
> Subsequent signals (even create, delete or anything besides dirty) is
> following this same path where the emit is b
Hello,
On Wednesday 31 July 2013 12:37:52 Stephen Kelly wrote:
> Kevin Ottens wrote:
> > Once the splitting will be done I'm not so sure it's better than using
> > directly the namespaced target names. The reason being that variables are
> > really a pain with cmake... I mean if you mistakenly use
Hi,
I'm horrible in clearly explaining issues and i'm going to explain a
lot in this mail. Please read it very carefully.
= The symptoms =
When opening my massively huge test folder (500.000 0 byte files) for
a resorting test in dolphin (pressing the name Name column when in
details view) i notic
On Mittwoch, 31. Juli 2013 12:03:12 CEST, Kevin Krammer wrote:
My guess would be that it is up to the application. If the
applications does
not want MMB drag, e.g. because it wants to use MMB for
something else, then
it should be able to deactivate that.
I would object this from a HIG POV.
Kevin Ottens wrote:
> Once the splitting will be done I'm not so sure it's better than using
> directly the namespaced target names. The reason being that variables are
> really a pain with cmake... I mean if you mistakenly use a variable name
> which doesn't exist it's just expanded to nothing. Ta
On Tuesday, 2013-07-30, Hyperz wrote:
> The issue is that if the mouse moves even 1 pixel while the middle mouse
> button is being pressed/clicked to close a tab KTabBar doesn't
> emit mouseMiddleClick() and the tab doesn't get closed.
Hmm, shouldn't there be something like a minimum drag distanc
Hello,
There's and old compatibility feature in KTabBar for moving tabs using the
middle mouse button (see:
http://api.kde.org/4.10-api/kdelibs-apidocs/kdeui/html/ktabbar_8cpp_source.html#l00209
).
This compatibility feature can cause problems with applications that have
movable tabs and use the
On Tuesday 30 July 2013 23:18:35 Alexander Neundorf wrote:
> On Tuesday 30 July 2013, Kevin Ottens wrote:
> > * ben2367 is still looking in unifying our cmake files regarding
> > variables vs direct use of targets;
>
> Current conclusion (not yet merged into cmake, but will hopefully make it
> f
11 matches
Mail list logo
