I'm planning a gui toolkit, and can't decide on whether I should use int, int32 or float32 types for controls coordinates, sizes, 2d graphics operations etc.
This toolkit should be as minimalistic as possible, while hitting the goals:
If one needs a perfect 2d screen/svg/pdf cross-platform and cross-device graphics, then there's great Cairo library for this (i don't plan to implement a full-featured perfect 2d interface for platform-specific graphics), which uses double precision type for coordinates. But if you target win32 or Xlib you use int32 for coords, and if you target iOS/Mac or OpenGL you use float for coords.
Now I think, using an abstract TUICoord which maps to int32 or float32 is a good idea, however if I use Cairo for drawing operations then there will be many conversions from float to double or if I use float32 there will be many conversions float -> int when interacting with windowing functions...
Any ideas?
int, int32 or float32 types for controls coordinates, sizes, 2d graphics operations
Most existing GUI toolkits seem to use native integer type, so int would be perfect. I suggest to avoid floating point at all if possible as it's slower than integer.
You can peek at how fpGUI and mseGUI (or maybe LCL) implements their custom drawn interface.
@Araq, type "natural" (0..high(int)) is not suitable because some docking or panel-hiding can demand a negative/offscreen origin.
Probably, I should go with an abstract type which maps to int32 or float32 depending on the rendering backend -- iOS and Mac use float32 for coords, window sizes etc and canvas graphics api, Windows Direct2D also uses float32, Win32 GDI uses ints, Xlib uses ints, Cairo uses 64-bit doubles, SDL uses ints...
@gradha, I want minimum dependency, but it's very hard to start from scratch (i.e. write Xlib, Win32, Mac backends), probably I start with OpenGL-based Allegro graphics library as a backend -- it has decent message-driven API which GLFW is lacking, and so I'll be able to compile the app for all the platforms or look at Claro, just don't know which way is easier -- to write bindings for huge Allegro library, or to port some platform-specific code from claro...
Knowing nothing about win32 I guess they have hidpi modes scaling pixel values like Android. So you end up having logical coordinate * screen dpi all over the place. If you go for OpenGL and floats you could abstract this for the user, so switching between normal and hidpi modes doesn't require different code paths.
Doubles are really overkill for simple widget coordinates, though I've been on projects were designers were hell bent on putting widgets on 0.5 coordinates because those were integer coordinates on retina screens. Who knows what the future will bring us with 4K and hidpi displays, maybe coordinates like 2.25 will become usual in order to support backwards compatibility for older programs which weren't designed with 4K in mind?
So I'd say ditch integers.
So the type is only for internal use... that's intriguing, how will users specify how much space they want for buttons? Are you going for really high level like HTML tables were you write percentages?
EDIT: ah, indeed, didn't catch the "MiG" keyword, and looking now through http://www.miglayout.com/QuickStart.pdf it seems like html-like layouting with scales based on font size.