> On Sept. 7, 2015, 4:59 p.m., Thomas Lübking wrote:
> > Hold it.
> >
> > Implementationwise, this looks wonky - if it's possible to get unbalanced
> > input events (ie. releases w/o ever a press or vv.) from the system since
> > the counter will run out of sync.
> >
> > => Are such
> On Sept. 7, 2015, 2:59 nachm., Thomas Lübking wrote:
> > Hold it.
> >
> > Implementationwise, this looks wonky - if it's possible to get unbalanced
> > input events (ie. releases w/o ever a press or vv.) from the system since
> > the counter will run out of sync.
> >
> > => Are such
> On Sept. 7, 2015, 4:59 p.m., Thomas Lübking wrote:
> > Hold it.
> >
> > Implementationwise, this looks wonky - if it's possible to get unbalanced
> > input events (ie. releases w/o ever a press or vv.) from the system since
> > the counter will run out of sync.
> >
> > => Are such
> On Sept. 7, 2015, 4:59 p.m., Thomas Lübking wrote:
> > Hold it.
> >
> > Implementationwise, this looks wonky - if it's possible to get unbalanced
> > input events (ie. releases w/o ever a press or vv.) from the system since
> > the counter will run out of sync.
> >
> > => Are such
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/124954/
---
(Updated Sept. 9, 2015, 8:42 a.m.)
Status
--
This change has been
> On Sept. 7, 2015, 4:59 p.m., Thomas Lübking wrote:
> > Hold it.
> >
> > Implementationwise, this looks wonky - if it's possible to get unbalanced
> > input events (ie. releases w/o ever a press or vv.) from the system since
> > the counter will run out of sync.
> >
> > => Are such
> On Sept. 7, 2015, 2:59 nachm., Thomas Lübking wrote:
> > Hold it.
> >
> > Implementationwise, this looks wonky - if it's possible to get unbalanced
> > input events (ie. releases w/o ever a press or vv.) from the system since
> > the counter will run out of sync.
> >
> > => Are such
> On Sept. 7, 2015, 4:59 nachm., Thomas Lübking wrote:
> > Hold it.
> >
> > Implementationwise, this looks wonky - if it's possible to get unbalanced
> > input events (ie. releases w/o ever a press or vv.) from the system since
> > the counter will run out of sync.
> >
> > => Are such
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/124954/#review84959
---
Hold it.
Implementationwise, this looks wonky - if it's
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/124954/#review84957
---
Ship it!
Ship It!
- Sebastian Kügler
On Aug. 27, 2015,
> On Aug. 27, 2015, 7:04 p.m., Thomas Pfeiffer wrote:
> > Since this is indeed a very often required feature, why do we keep it
> > hidden? If it can have negative side-effects, it we should warn users about
> > them, not hide the whole feature from them.
>
> Thomas Lübking wrote:
> or
> On Aug. 27, 2015, 7:04 p.m., Thomas Pfeiffer wrote:
> > Since this is indeed a very often required feature, why do we keep it
> > hidden? If it can have negative side-effects, it we should warn users about
> > them, not hide the whole feature from them.
>
> Thomas Lübking wrote:
> or
> On Aug. 27, 2015, 9:04 p.m., Thomas Pfeiffer wrote:
> > Since this is indeed a very often required feature, why do we keep it
> > hidden? If it can have negative side-effects, it we should warn users about
> > them, not hide the whole feature from them.
>
> Thomas Lübking wrote:
> or
> On Aug. 27, 2015, 9:04 p.m., Thomas Pfeiffer wrote:
> > Since this is indeed a very often required feature, why do we keep it
> > hidden? If it can have negative side-effects, it we should warn users about
> > them, not hide the whole feature from them.
>
> Thomas Lübking wrote:
> or
> On Aug. 27, 2015, 7:04 p.m., Thomas Pfeiffer wrote:
> > Since this is indeed a very often required feature, why do we keep it
> > hidden? If it can have negative side-effects, it we should warn users about
> > them, not hide the whole feature from them.
>
> Thomas Lübking wrote:
> or
On Aug. 27, 2015, 7:04 p.m., Thomas Pfeiffer wrote:
Since this is indeed a very often required feature, why do we keep it
hidden? If it can have negative side-effects, it we should warn users about
them, not hide the whole feature from them.
Thomas Lübking wrote:
or restricte to
On Aug. 27, 2015, 7:04 nachm., Thomas Pfeiffer wrote:
Since this is indeed a very often required feature, why do we keep it
hidden? If it can have negative side-effects, it we should warn users about
them, not hide the whole feature from them.
Thomas Lübking wrote:
or restricte
On Aug. 27, 2015, 7:04 nachm., Thomas Pfeiffer wrote:
Since this is indeed a very often required feature, why do we keep it
hidden? If it can have negative side-effects, it we should warn users about
them, not hide the whole feature from them.
Thomas Lübking wrote:
or restricte
On Aug. 27, 2015, 9:04 p.m., Thomas Pfeiffer wrote:
Since this is indeed a very often required feature, why do we keep it
hidden? If it can have negative side-effects, it we should warn users about
them, not hide the whole feature from them.
Thomas Lübking wrote:
or restricte to
On Aug. 27, 2015, 9:04 p.m., Thomas Pfeiffer wrote:
Since this is indeed a very often required feature, why do we keep it
hidden? If it can have negative side-effects, it we should warn users about
them, not hide the whole feature from them.
Thomas Lübking wrote:
or restricte to
On Aug. 27, 2015, 7:04 nachm., Thomas Pfeiffer wrote:
Since this is indeed a very often required feature, why do we keep it
hidden? If it can have negative side-effects, it we should warn users about
them, not hide the whole feature from them.
Thomas Lübking wrote:
or restricte
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/124954/
---
Review request for kwin, Plasma and Hans Chen.
Repository: kwin
On Aug. 27, 2015, 7:04 nachm., Thomas Pfeiffer wrote:
Since this is indeed a very often required feature, why do we keep it
hidden? If it can have negative side-effects, it we should warn users about
them, not hide the whole feature from them.
or restricte to wayland? same process
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/124954/#review84486
---
Since this is indeed a very often required feature, why do we
24 matches
Mail list logo
