Hey Markus,
Markus Elfring [Mon, Jan 05, 2009 at 09:40:27PM +0100]:
> > Maybe adding errno to gpm_report() as an additional argument
> > and strerror() it, if it's non-zero could do the job.
>
> Would you like to introduce this little improvement for better error explanations?
As usual, I'm busy, but I'm open for patches against gpm-2-dev.
> > I must confess that I would like to have gpm cleaned up much more,
> > before we add more dependencies on other projects.
>
> I am curious which refactorings will be acceptable for the current source files
> to complete the error handling.
Just give it a try and ask when you're unsure.
> > I personally see no advantage using try{} catch(),
>
> (C++) exceptions provide a means to support more powerful error reporting.
> Will all function implementations stick to a traditional C coding style forever?
Jep, it will stay C.
> > the ACC idea looks somehow nice, maybe something for the future.
>
> Are there any chances to integrate a tool like "AspectC++" into the software
> build process?
> http://aspectc.org/
I don't think this will happen soon. The big problem is that more development
takes place in other places (like linux-input) than in gpm.
> How do you think about to write filters for specific function interfaces?
I am not sure what you mean by that.
Sincerly,
Nico
--
Think about Free and Open Source Software (FOSS).
http://nico.schottelius.org/documentations/foss/the-term-foss/
PGP: BFE4 C736 ABE5 406F 8F42 F7CF B8BE F92A 9885 188C
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ gpm mailing list gpm@xxxxxxxxxxxxxx http://lists.linux.it/listinfo/gpm