Hi all,
First question first: Budeme psat do listu jen anglicky, nebo je cestina OK?
Before going to the individual ideas, I would like to ask you for your opinions and for help with refactoring the current code (including names), thinking about the people that will use the library, frequent use cases and "most-expected" behaviour.
**** I would like to propose few renames in GfxPrim, mostly to improve readability:
GP_Context: x_swap, y_swap -> flip_x, flip_y It is called "vertical/horizontal flip", meaningful-sentence-like identifiers are easier to remember and read (flip_x vs x_flip) GP_Context: axes_swap -> swap_axes Readability, consistency with flip_* GP_Context: clip_(w|h)_(min|max) -> clip_x_min etc. clipping coordinate, not width
The argument-modifying macros do not indicate which arguments are modified (even worse than C++ refs). I propose to at least consistently document this in macro defs and/or change the argument names from "x" to "x_mod" or similar (i.e. in GP_Transform.h". Is there a LKML convention for that?
****** While we are at it, we might unify GP_IS_CONTEXT_VALID and GP_CHECK_CONTEXT. Is the distinction intentional?
***** Please see GfxPrim dev wiki at http://atrey.karlin.mff.cuni.cz/~gavento/GfxPrimWiki/ (will be moved to gfxprim.ucw.cz) In particular http://atrey.karlin.mff.cuni.cz/~gavento/GfxPrimWiki/dev/naming with some sketches of naming scheme.
****** It definitely makes sense to have transforming+clipping versions of operations as well as "bare" unsafe variants. I would propose to remove the "T" prefix from transforming variants, as most users will want the transforming behavior and to modify the names of the "bare" functions. I would propose "GP_Line_" or "GP_Line_Bare". What do you think?
****** Next proposal/question is about declaring public vs. private APIs. Most of it is public by default, but then we have accessors for GP_Context and others. What is the goal there?
Do we want GP_Context to be (partially) public, or do we want to provide accessors for everything? I would propose to make it public (to simplify things) and to solve transformation problems by having different fields for "user" w/h and "real" w/h. We need to somehow fix the context behavior anyway, and the freedom we will retain by using accessors will be probably very small.
If we want to keep non-transforming functions public, then we have to provide access to GP_Context transformations (more accessors).
Tralala! Tomas