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 <fredkie...@gmx.de> 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) _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev