"point_t" and "dimension_t" instead of "koord" for UI?

[Spike]

Neroden has once brought up the idea to introduce a new type which is used for UI component sizes and positions. During my restructuring work, I was reminded and it seemed to be a good idea, but also a big task.

I think we should introduce a two value container, to keep UI element dimensions and positions, and is not to be mistaken with koord's for map positions.

Java has "point" (x,y) and "dimension" (width, height) but I feel uncertain if we'll want two distinct types. The benefit is that there are good member names which distinguish positions from sizes. Having no better idea, I'd propose a move to point_t and dimension_t if there should be a redesign of the UI classes coming.

Nothing urgent. Just a cleanup, separation of UI and map classes and an improvement in code readability maybe. A question actually if it's wanted and what the other developers think about it.

[prissi]

As we currently have get_pos() and get_groesse() it would rather make sende to have a pos_t (also nivce and short) and change the second to get_size() and return a pos_t() (and not a size_t).

Making them different types (pos_t and size_t) would require a lot of type conversions. I do not see the advantage of it. Maybe I am overlooking something?

[Spike]

Making them different types (pos_t and size_t) would require a lot of type conversions. I do not see the advantage of it. Maybe I am overlooking something?

The only advantage is the name of the members: var.x, var.y and var.width, var.height
The semantics of the fields are more clear this way, even if the variable name itself is unclear.

Type conversions are not needed this much. You can still have

next.x = pos.x + element.width or

pos_t next = pos_t(pos.x + element.width + SPACE_X, pos.y);

[Markohs]

If current UI code is redesigned I'd like to know how do you plan to do it, to know how can affect the CEGUI project, and move in the same direction if possible.

[TurfIt]

Separation of screen coordinates from game map coords ala Nerodens proposal would be good IMHO. I'd asked if anyone still had a copy of his patch a while ago so I could see how badly out of date it was, but alas no response...

If the benefit is clearer names, no extra conversions required, what's the downside?

And while separating/redesigning, how about decoupling element sizes/positions from screen pixels? High DPI displays and fixed pixel sizing don't get along very well...

[Ters]

I can't remember ever having to convert between size and position in any API having different types for them, like Win32 and Java. The only downside is having to actually write two functionally very similar classes, but that's a one-time cost.

[Spike]

And while separating/redesigning, how about decoupling element sizes/positions from screen pixels? High DPI displays and fixed pixel sizing don't get along very well...

The old GEM system from Atari had an abstract coordinate system of 15 bit range IIRC. The problem was that lines nearby sometimes touched on screen and sometimes not - it was very hard to make two lines with a one pixel distance between them this way. (It also had a pixel-precise API and I doubt that the other system was really used much).

I'd think that such a system needs some anti-aliasing and sub-pixel rendering options to work well. The OpenGL backend could be a testbed foir this I think, but my own experiences from days back were not good (common screen resolutions were 320x200 and 640x400 back then, though ...) I don't know, maybe someone has more recent experiences with such systems?

[prissi]

I woudl rather go for the apporach we discussed in programming section on real pixels but with DPI dependent constants (as did GEM for Dialog rendering on the Atari ST ... )