Re: A question on discardEventsMatchingMask:beforeEvent:

[Banlu Kemiyatorn]

No worry. anyway, the current design is broken because.

1) Filter X event like that is a broken approach, for example, it
would break the meaning of zig-zag movement. The filtering strategy
should rely on distance and time one a _fixed size buffer_ (As any
display server does to prevent frozen application client to cause
memory flood on the server side, but since gsdisplayserver is an
abstract one, it shouldn't have any queue at all beside relying on the
windowing system's discarding policy as the policies were maintained
by the driver maintainers) And you won't be able to do that if you
don't catch them as NSEvent or instead, use an array of struct or
union of parameters, if you don't want a real event or think they were
too expensive.

(My NSApp has this implementation, allowing it to store parameters
instead of real event on a fixed size loop queue which can migrate old
event out of the fast loop queue and collect leak events and
auto-scale the fast loop queue to serve dense event stream over time,
I still need to bench a special NSEvent pool zone's thread locking
deallocation against the traditional event generation, hopefully this
evening, that would define the actual implementation of the design)

2) That force advance event management into backend which is not a
suitable nor extensible place. An app may want to define some form of
custom gesture detection, or filtering event using specific strategy
but it won't be able to access the cached events as the server should
encapsulate it. ITOH, exposing the cache from server is breaking
encapsulation. You would endlessly need to support more and more ops
for that.

On Fri, Jan 28, 2011 at 5:30 AM, Fred Kiefer <address@hidden> wrote:
> Am 27.01.2011 07:13, schrieb Banlu Kemiyatorn:
>> I would like to apologize for the flame I didnt meant to. But I was
>> out of the line since I didnt try to flame in the first place and so
>> I didnot like it to be thought of that way. However, as I think it
>> was too hard to communicate, I've decided that for a while that my
>> future dev will rely on my own application class, my own input
>> system, skia display backend and possibly glib mainloop and gdk.
>> Thanks and sorry!
>
> I am sorry too. With your other mail on GIT I had the impression that
> you wanted to provoke any sort of useless discussion what so ever.

I want GIT as I just want a way to maintain my own patch since I don't
have svn write access but I don't want one because I don't have enough
time to manage stuffs.. like writing proper commit log or gnu coding
style. I was indeed looking for a way to work with gnustep trunk that
suite me best, a way I can track my own changes without bothering with
branch commands, etc. I don't know how to have my own branch on my
machine and can easily pull changes from trunk and track changes of my
own work with SVN. Not that I say it can or can't, just that I know
how to do that better with git. With that thread I was just trying to
summing up all interesting opinions to see if there are enough
supporters, that's all.

> As this wasn't your intention my reply was completely off. Sorry for that.
> I really appreciate your contributions to GNUstep in the past, but in
> the recent mail exchange it was hard for me to tell, whether your just
> insist on a specific implementation detail, which I still think is
> wrong. For both of us English isn't  our first language and some of your
> mails where rather hard to make sense of. I tried to reply to most of
> them but at the moment I only have very limited time for GNUstep. Sorry
> for that as well.
>
> Cheers
> Fred
>



-- 
    .----.     Banlu Kemiyatorn
  /.../\...\   漫画家
 |.../  \...|  http://qstx.blogspot.com (Free Software Advocacy & Development)
 |../    \..|  http://feedbat.blogspot.com (Studio Work For Hire)
  \/      \/   http://groundzerostudiocomplex.blogspot.com (Studio Research)