News:

Use the "Forum Search"
It may help you to find anything in the forum ;).

[Project] GUI Theme

Started by Max-Max, May 31, 2013, 11:12:48 PM

Previous topic - Next topic

0 Members and 3 Guests are viewing this topic.

prissi

About indentation, the simple rule (as enforced by most editors anyway): Use tabs

Only two expections come to my mind:
if(  bla && bla &&  ... very lonw
    && bla && blac )  <--- this line has spaces for indent!
{
<- here tabs again!

The second one is for the definitions of stuff.
sint16  a;
sint8   b;
bool  c;
very_long structure c;
although tabs may work here too, and no indentation is fine too.

I tried some code refactoring. Almost any program has some issues. I think there is a GUI for uncrustify or so, which near gave nice results. Especially the double space around logic operators is almost impossible to enforce, and many brackets are sometimes close (trivial) or open important longer clauses, which a software fails to rectify obviously. If one could live with this limits, we can set a date to run these over standard and experimental at the same revision and keep then synchronised that way. (Same can be obviously done to the patches).

About the topic of DIRTY etc.
Quote from: Max-Max on June 24, 2013, 03:41:04 AM
But they have nothing to do with alignment. Especially not GUI bounding boxes against other GUI bounding boxes. Imho I think these flags has less to do with my alignment, than my alignment has to do with text alignment. My routines don't use them at all. I still think that text alignment should be in its own enum, together with these flags.
There is 2 bits left and I do have a plan to use these two bits further down the road. That is why they are reserved.
And I disagree. Those constant do alignment, it should not matter if the align text, images or whatever.

You can obvjously now have more than one display_proportional with different and default parameters without the ugly define, since simgraph16.cc is now C++ (since some time actually) and hence also get rid of these flags.

QuoteAlmost all button init() sets the size to koord( D_BUTTON_WIDTH, D_BUTTON_WIDTH ). I made it possible to exclude the size and have the Init() to set them to the default size for that control. You can still override this in the init() by setting the size parameter. If this isn't still enough you can set a new size after the init() call.
Quote
Well, I already said, I could imagine a init for every version. If needed for the init to have more parameters, would hiding it in the derived classes will make it inaccessible for the public caller or not? The situation which must be avoided, it init( pos, size ) called on something which needs init( pos, size, stuff ); One could then pass a static size (-1,-1) which would be the default size.

Also some buttons are doing something else, like the pos buttons. Maybe those needs to be an own class.

QuoteDo we have support for transparent images now?
1 bit transparency since ages; but there could be a parameter in the theme tab (which for instance would define menu positions, tool sizes and so on) to draw the the background with xx % transparency. Such routines exist.

About alignment, I think we should have two align functions, one with one control, and one with two controls. Since most time you need the vertical only, we shoudl consider passing NULL then for the first parameter.

EDIT:
I forgot, I could not download your zip file.

Max-Max

#106
Thank you Prissi for the clarification of tabs & spaces, lets move on...

QuoteI could not download your zip file.
Strange, the url is http://simutrans-germany.com/files/upload/SimutransTheme_r28.zip Maybe you can browse manually to get it? The link and zip archive works fine from here  ???
Does any one else have a problem to get the document?

Regarding my smaller patches, what is the plan in your end?
To receive ALL the patches before a trunk merge or to merge them one by one? I'm trying to create patches that will not break the current GUI, so we can merge them "silently". If your plan is to wait for all the patches, I will have quite difficult to keep my main trunk (your trunk) up to date with my patches.

QuoteYou can obvjously now have more than one display_proportional with different and default parameters without the ugly define, since simgraph16.cc is now C++ (since some time actually) and hence also get rid of these flags.
I do not know how these flags are used, but I will do my best to fix this. If the flags are to be removed, I have no objection at all to share alignment enum :)

For the hidden Init() function, it depends on the pointer type. If the pointer is of the base class type, all it knows is the init(pos,size) and that will be use. This makes sense because if you do use the base class you don't know what type of control it is, unless you do a dynamic cast that will give you the correct pointer. If you use a pointer of the correct type the Init(pos,size) will stay hidden and not be accessible. This makes sense because now you know the interface and how to use the extra params.

Quote
QuoteDo we have support for transparent images now?
1 bit transparency since ages; but there could be a parameter in the theme tab (which for instance would define menu positions, tool sizes and so on) to draw the the background with xx % transparency. Such routines exist.
Yes I know about the transparent mask (1bit) and I have seen some Alpha drawing stuff in the code. The themes could really benefit from drawing with an alpha plane (24bit png). This would make it possible to do overlays and hence keep down the number of images. The question is, would it be to slow to draw?

To make window backgrounds semi transparent sounds like an excellent idea! There could be one transparent level for inactive windows and another setting for active windows  :D

QuoteAbout alignment, I think we should have two align functions...
It might be very useful if I implement anchor points support further down the road. I think this would come naturally when needed. I will keep it in mind...

QuoteWhile you're rewriting the gui, do *not* use the koord class.
I was told to use it, but I think you are right. It feels a bit awkward to use the koord type.

I'm a bit used to Windows and they use a POINT type for x,y screen positions and a RECT type (x1,y1,x2,y2) to place a rectangle on screen.
I have seen a similar type for clipping regions in the code.

I might suggest a screen point class (SIMPOINT) similar to Win32 POINT and maybe a Rect class (SIMRECT) like (x1,y1,x2,y2) with helper functions like get/set width(), height().
Should a screen coordinate be of the type sint32 or sint64?

Quotechar* x; is a good declaration, char *x; is a hard-to-read muddle.
I totally agree with you.
- My code doesn't have bugs. It develops random features...

Max-Max

I'm trying to figure out how to remove the DT_CLIP and DT_DIRTY flags.

int display_text_proportional_len_clip(KOORD_VAL x, KOORD_VAL y, const char* txt, text_attribute_t flags, PLAYER_COLOR_VAL color_index, long len);
/* macro are for compatibility */
#define display_proportional(     x,  y, txt, align, color, dirty) display_text_proportional_len_clip(x, y, txt, align | (dirty ? DT_DIRTY : 0),           color,  -1)
#define display_proportional_clip(x,  y, txt, align, color, dirty) display_text_proportional_len_clip(x, y, txt, align | (dirty ? DT_DIRTY : 0) | DT_CLIP, color,  -1)


How would you propose we deal with it? Why where they moved into the enum in the first place?
- My code doesn't have bugs. It develops random features...

Max-Max

Regarding coordinate types.

After some thinking there are 3 kinds of coordinates:

1. Map coordinates x,y,z
2. Screen coordinates x,y
3. Client coordinates x,y

Map coordinates are a virtual system placing map objects in a 3D space.
Screen coordinates doesn't need to have a negative representation because they are mapped 1:1 to the screen device. These can be unsigned.
Client coordinates are relative to their parent client area or other GUI objects. These needs to be signed.

It might be a good idea to separate these 3 types, not only because of their range, but also for type checking and guide the programmer what type of coordinates are expected in a call.

What are your thoughts?
- My code doesn't have bugs. It develops random features...

kierongreen

The alpha image code that is in trunk does not support 32bit images. It takes the current 15bit images and plots using a 5bit alpha channel which is either the red, green or blue channel of another image.

Max-Max

#110
More alignment enums...

Found this one in gui_label_t

enum align_t {
  left,
  centered,
  right,
  money
};


It will be tricky to replace this with he now global alignment enum. Now MONEY, DT_CLIP and DT_DIRTY don't belong in there.

But again, this still looks like TEXT_ATTRIBUTES to me... What happen if we add Shadow (very likely since we need this in the gui_label_t), Bold and Italic?? They don't have to do anything with Aligning objects.
One way would be to distinguish text attributes such as; money, justified, shadow, bold, italic as a second parameter in the text draw call. Having one parameter for alignment and one for text attributes.
- My code doesn't have bugs. It develops random features...

Ters

Money can actually be a valid alignment, though I haven't checked if it's used that way. Numbers in general have special alignment rules, which may vary between locales. Some of it can be done when formatting the text, some can be done by splitting the label into different parts, but I can imagine having the label control itself do some trickery is easiest. Especially if there is no way to split the label so that it works for all languages.

Max-Max

I manage to get around the enums for now.
I will deal with the label stuff later when I get deeper into the GUI classes.
- My code doesn't have bugs. It develops random features...

prissi

Going backwards:

Labels should get a proper format parameter, if ever bold etc is added. As such, money could be also a formatting option.

Most of the simutrans code use "char *str" which I personally also prefer. Again something to do, when tweaking a beautifier.

Screen coordinates can be negative. You can move a window out to the left (and it is fully intended to allow this, especially on small screens).

I would keep only one screen koordinate class for points or rectangle size. Very often you only need to touch xy or size.

Btw, now the download works. In the end the interface should be kept as simple as possible. Otherwise we could just convert it to QT (or any other cross platform GUI) and then use these libaries instead. I am impressed, as this is the most visually appealing documentation simutrans ever had. It would be nice, if the interface at the very end is not more complex than now.

I will include patches, as soon as they are ready, or else they get bitrot too quickly.

Max-Max

Thank you Prissi. Well writing documentation was one of my many task at the office :)

I have managed to "solve" the enum "problem" ;) and order is restored. This goes also for Tabs and spaces...

Regarding coordinate systems, well you are right and that I believe is usually called world coordinates in game engine terms, while screen coordinates is the physical screen. However we shouldn't over complicate this, so I agree with you.

Screen coordinates as sint32?
typedef sint32 screen_coord_t;
or
typedef sint32 sc_coord_t;
or
typedef sint32 coord2d_t;
...

I have also considered QT or other GUI framework, but I think this GUI will be less complex when we get the classes sorted out a bit.

Since I have corrected all the issues, I will put up a new patch that obsoletes the previous. I just saw that the trunk got updated so I need to merge, test and generate new patch files.
- My code doesn't have bugs. It develops random features...

Max-Max

Okay, here is the new patch.

This implements the frame work changes needed for the dialogue patches.

welt.cc is temporarily modded to behave as usual. It will get its own patch later.
Don't forget to add gui_komponente.cc to the project.

After applying this patch right out of the box, it should look just as usual. Set the define THEME_TEST to 1 (in gui_frame.h) to test the new stuff. This patch would mess up all dialogs (in THEME_TEST)  but the title height should be working everywhere.

It would be great if you could get this into the trunk so I can create the dialogue patches from there... I have already done a few that I can prepare right away when this is in the trunk.

Time for some sleep :P
- My code doesn't have bugs. It develops random features...

Markohs

I just read all the above comments lightly (I'm sorry if I say something already discussed), but reading your patch:

gui_divider: Documentation is in german, translate it please.

+   enum divider_style_t {
+      kOut  = 0,  //@< 2px divider out
+      kLine = 1,  //@< 1px divider higlight line
+      kIn   = 2   //@< 2px divider in
+   };

kOut this hungarian notation it's not conformant to simutrans names. Not that I really care much (I really think we tend to focus too much in style and things like char *p vs char* p are equivalent and irrelevant to me), but pointing it.

About the screen coorditates, a sint32 type should be enough, and yes, screen coordinates should not be KOORD_VAL, agree with neroden and many others thgat expressed so before and after.


gui_komponente.h

align_to documentation names are not consistant with the code.

Max-Max

I don't speak German but I will do a try to translate...

The divider_style_t  and align_to() documentation must have slipped through. I was up all night, you can truly call this a night build :)
Prissi, I have made the changes, is it okay if you get them in the next patch (first dialogue)?
- My code doesn't have bugs. It develops random features...

Markohs

Quote from: Max-Max on June 25, 2013, 10:39:53 AM
I don't speak German but I will do a try to translate...

Do as I do, translate.google.com , zeichnen is "draw", "bild" is image, "besch" is "descriptor", "welt" "world", "wasser" "water", "mit" is "with", "groesse" is "width" or "dimension". Also germans like to use "k" instead of "c". Easy language! ;) (not at all, even it looks it was not so hard for Guardiola. ;) )

prissi

groesse is rather best translated as size ...

Since everything that draw on the screen is ultimatively a KOORD_VAL (in simgraph) I am for s_coord_t( KOORD_VAL, KOORD_VAL )

Markohs

why not extending it to 32-bit? 32.000 pixels wide can be achieved maybe some day, on multi monitor, and yound 32-bit aritmetics should be fast enough today.

Ters

At such resolutions, the lack of memory in a 32-bit process will likely be another limiting factor, not to mention trying to push all those pixels through the bus. I don't think switching KOORD_VAL to 32-bit will hurt, since I can't remember seeing enough of them for the memory savings to be significant, but I don't think Simutrans will gain much from a change either, unless 16-bit operations are becomming seriously slow on modern processors.

Max-Max

Well, a 16bit signed type would represent about +/-32 700 pixels and a 32bit signed around +/-4 147 000 000. I think we will do fine with 16bit even on multi display system. I have dual system and even if I where to use 3 of my hires monitors I would still only get up to 7680 pixels. So there is quite a bit to 32000.

However, I do strongly recommend to keep the two types apart. One type for map coordinates and one for screen coordinates. Not only to give any programmer a hint about what coordinate system he works with, but also to be able to change the type independently in the future.

If the code would run better on 16, 32 or 64 bit, it is very easy to select and adjust.

I made an s_coord_t, point_t and rect_t. s_coord_t is just a type while point_t and rect_t are structs with member functions and operators.
- My code doesn't have bugs. It develops random features...

Markohs

The other day a workmate of mine was testing a triple monitor configuration and he was at a around 6.000 pixel wide configuration, that's still far from 32.000 but who knows what will technology bring us in the future, being the cghhange so simple and carrying so little performance downsides, I'd just change to 32-bit and forget about the problem forever.

Yes, the bus can be a problem at 32.000 wide pixels, but when that time comes we maybe render that with OpenGL or the buses will be fast enough. Maybe.

Markohs

Quote from: Max-Max on June 25, 2013, 04:18:36 PM
I have dual system and even if I where to use 3 of my hires monitors I would still only get up to 7680 pixels. So there is quite a bit to 32000.

Yes, but for example multiplying or making mean of screen positions (fore example (2*x0 + 2*x1)/2 ) can get us closer to the overflow when we get closer to 16-bit limit. Why risking ourselves to get close to that limit when we can just use 32-bit that all modern CPU treat as a default size.

Max-Max

- My code doesn't have bugs. It develops random features...

Markohs

btw, Max-Max, I just opened your documentation and well, as you know we programmers don't read documentations much, because that's well, too boring. ;)

But I have to agree with prissi it's the best documentation related to simutrans code I've ever read.  Congratulations and good job.  I wish we all programmers whould document things like you, things whould be way easier. :)

Ters

Since multiplying 16-bit values yields a 32-bit value on x86, and a division with 16-bit result takes a 32-bit dividend, such calculation may actually be safe if the compiler is smart enough.

Markohs

you can also say that could be a unexpected behaviour and that the multiplication should overflow since you didn't explicitly cast to 32-bit. Well, I don't know, but you can't really depend on that, I guess.

prissi

IF any screen related coordnate is from the KOORD_VAL, then the size could be increase quite easily afterward or whenever needed by jsut changing KOORD_VAL.

I still have to look at the patch, I was too busy yesterday.

Markohs

But it we are talking about making screen coordinates differ from in-game coordinates, doesn't make more sense to name them differently? Maybe rename KOORD_VAL to SCREEN_COORD  (finally translating it ) and MAP_COORD (maybe not necesary since we have already koord and koord3d) when appropiate.

I don't understand why are we respecting this old code so much, with this attitude we'll never make significant progress in code translating and improving.

Max-Max

I have prepared a point_t and a rect_t (not included in this patch).

Should we translate KOORD_VAL to SCREEN_COORD_VAL and point_t (new type) to SCREEN_COORD.

The point_t have these members:

tag_point_t()
tag_point_t(s_coord_t x_par, s_coord_t y_par)
bool operator ==(const tag_point_t& point_par) const
bool operator !=(const tag_point_t& point_par) const
tag_point_t operator +(const tag_point_t& point_par) const
tag_point_t operator -(const tag_point_t& point_par) const
tag_point_t& operator +=(const tag_point_t& point_par)
tag_point_t& operator -=(const tag_point_t& point_par)
void add_offset(s_coord_t delta_x, s_coord_t delta_y)
void set(s_coord_t x_par, s_coord_t y_par)
void set(const tag_point_t& point_par)


s_coord_t would be the SCREEN_COORD_VAL and point_t would be SCREEN_COORD.

So KOORD_VAL would be refactored to SCREEN_COORD_VAL when used in Screen operations.
koord would be refactored to SCREEN_COORD (the new point_t) where appropriated.

Correct?
- My code doesn't have bugs. It develops random features...

prissi

#132
Actually, I thought that s_coord( KOORD_VAL, KOORD_VAL ) (or maybe renamed by search and replace throughout the code to SCREEN_COORD_VAL) should behave like you new point class. Actually, point_t is imho no a good name; we have koord. Thus it make sense to have screen_koord. I can like with scr_coord or even s_coord. By point brakes this logic completely.

Furthermore, I think it would make more sense to work on the gui component stuff first. If you want to try to make everything at the same time, nothing will be done.

About the patch: It certainly gets there.

+ /**
+ * Pre-defined divider line styles
+ * Values > 2 creates an inset bevel
+ * @author Max Kielland
+ */
+ enum divider_style_t {
+ kOut  = 0,  //@< 2px divider out
+ kLine = 1,  //@< 1px divider higlight line
+ kIn   = 2   //@< 2px divider in
+ };

is not explaining to me. What is an "inset bevel"? Also the diver style need to be addressed as gui_divider_t::xyz, so the should be meaningful names: LINE_DIVIDER=0, SHADED_LINE_DIVIDER=1, and INSET_BEVEL_DIVIDER=2 (whatever this is). The are only called a few time, and hence a meaningful lang name is useful there.

The code has still "fOffsetRemoval" a very non-simutransish variable name. Almost any name in simutrans is is lower case with "_" in it. (And secondly I though the prefix f is for float ??? ) Why anyway the offset removal of images? Those usually have an offset on purpose. Having it removed is against the intentions of the artist.

Why has the divider class a get_groesse? It set its size itself correctly and hence the base class could return the size?

Overall, mostly minor issues. If you want I can fix those.

TurfIt

#133
Quote from: prissi on June 26, 2013, 09:35:15 PM
Also the diver style need to be addressed as gui_divider_t::xyz,

That's a scoped enum which is not legal C++98 (which I pointed out before...).
Are we moving Simutrans to C++11?

EDIT:
clarification - it's the divider_style_t::kIn references within gui_divider_t that are the problem.

EDIT:
reading comprehension issues...  I think you're saying divider_style_t::kIn should be changed in the patch to gui_divider_t::kIn (but with better names) which solves the scoped enum. So forget this whole post...

Max-Max

QuoteActually, I thought that s_coord( KOORD_VAL, KOORD_VAL ) (or maybe renamed by search and replace throughout the code to SCREEN_COORD_VAL) should behave like you new point class.

I my previous post I asked what we should call them. I also suggested to call them SCREEN_COORD_VAL and SCREEN_COORD. So to make it even more clear. My suggestion is:

KOORD_VAL becomes SCREEN_COORD_VAL where appropriated.
koord becomes screen_coord where appropriated.
KOORD_VAL is renamed to MAP_COORD_VAL
koord is renamed to map_coord

This will give us in the end:

SCREEN_COORD_VAL
screen_coord( SCREEN_COORD_VAL,SCREEN_COORD_VAL )
MAP_COORD_VAL
map_coord( MAP_COORD_VAL,MAP_COORD_VAL )


The koord class do behave similar, but has a lot of map related functions, it's not a pure class for arbitrary coordinates.

Quote...is not explaining to me. What is an "inset bevel"?
A bevel is a graphical element in many GUI. A one line border bevel is also called a Panel in GUI terms.

A bevel with larger borders is usually used for buttons.
My intention was to have a bevel class because a divider is nothing else than a very thin bevel. I realised, as stated before, that the GUI needs to be overlooked and I will do this in a later stage.
The way the divider is drawn (originally), a height larger than 2, gives a lowered bevel. I will not do any further work to fix this one until later, but I at least made it a bit easier to work with than before...

QuoteFurthermore, I think it would make more sense to work on the gui component stuff first. If you want to try to make everything at the same time, nothing will be done.
I have not even started on the GUI yet :) I have my plan, but when I'm in every dialogue to fix the margin, height control spacing etc... I do use the divider and label class to replace the directly drawn directly element. This is why a few gui classes had some minor modifications.

QuoteWhy has the divider class a get_groesse?
The D_DIVIDER_HEIGHT is the double size of D_V_SPACE to give a more relaxed spacing. The normally 2 pixel graphical representation of the divider line is centred in the D_DIVIDER_HEIGHT space but the divider component's bounding box is either the divider pixel height or D_DIVIDER_HEIGHT, what ever is the largest of them.

QuoteThe code has still "fOffsetRemoval" a very...
As I stated earlier, I have already corrected these few things that slip through and asked if it was okay to include them in the next patch.

/**
* Pre-defined divider line styles
* Values > 2 creates an lowered bevel
* @author Max Kielland
*/
enum divider_style_t {
  DIVIDER_RAISED  = 0, //@< 2px divider raised etched
  DIVIDER_LINE    = 1, //@< 1px divider line (SYS_COL_HIGHLIGHT)
  DIVIDER_LOWERED = 2  //@< 2px divider lowered etched
};


So the bottom line is, again: Is it okay if you get these changes in the next patch? Or should I make a new one again?
- My code doesn't have bugs. It develops random features...

prissi

Two thing to clarify:

Why has the divider a virtual get_groesse() method? It should make sure that groesse is always correct, then get_groesse of the parent class shoudl work fine.

I would leave koord for the moment and just focus on screen koord and screen_coord or scr_coord() (as they are used at many places) and SCREEN_COORD_VAL.

And why do you need to display an image without an offset. Usually it is an artists decision to have a small element with an offset.

And as said, I can integrate this today evening.

Max-Max

#136
QuoteWhy has the divider a virtual get_groesse() method?
As I explained, I had in mind to divide this into more controls... You can remove the virtual since I will not do this rework now anyway. The overloaded  get_groesse() is not returning groesse, it is a calculated value. Trust me, it is needed to correctly draw and space the divider as I explained before.

QuoteAnd why do you need to display an image without an offset.
In the "old" skin system, the artist had to include left and top margins in the image. This was the only way to center an image inside a button because all buttons where of the same size. With this new system the buttons size can be of an arbitrary size and margins are defined in other ways. To properly display today's skin, the margin must be removed from the image. Other wise you can't centre an image inside a button properly. You will see this especially for a window's gadget buttons. By doing this you can still use the old skin files and the new theme files (without margins) and still show them correct.

This is what happend if you don't remove the image margin (look at window's the gadget icons).


This is how it looks when you do remove the image margin (look at window's the gadget icons).


Would be so kind and do the modifications for me:

gui_image.h
void enable_offset_removal(bool offset_removal_par) { set_image(id,offset_removal_par); }

gui_divider.h
class gui_divider_t : public gui_komponente_t
{
public:

/**
* Pre-defined divider line styles
* Values > 2 creates an lowered bevel
* @author Max Kielland
*/
enum divider_style_t {
DIVIDER_RAISED  = 0, //@< 2px divider raised etched
DIVIDER_LINE    = 1, //@< 1px divider line (SYS_COL_HIGHLIGHT)
DIVIDER_LOWERED = 2  //@< 2px divider lowered etched
};

gui_divider_t(void) { groesse.y = gui_divider_t::DIVIDER_LOWERED; }

void init( koord xy, KOORD_VAL width, KOORD_VAL height = gui_divider_t::DIVIDER_LOWERED ) {
set_pos( xy );
set_groesse( koord( width, height ) );
};

/**
* Set the divider's width
* @author Max Kielland
*/
void set_width(KOORD_VAL width) {

set_groesse(koord(width,groesse.y));
}

/**
* Get this component's bounding box size.
*/
virtual koord get_groesse() const {

return koord(groesse.x,max(groesse.y,D_DIVIDER_HEIGHT));
}

/**
* Paint method
* @author Markus Weber
*/
void zeichnen(koord offset) {

KOORD_VAL h = (groesse.y == DIVIDER_LINE) ? 1 : ( (groesse.y == DIVIDER_RAISED) ? 2 : groesse.y );
KOORD_VAL align_y = D_GET_CENTER_ALIGN_OFFSET(h,D_DIVIDER_HEIGHT);

display_ddd_box_clip(
pos.x + offset.x,
pos.y + offset.y + align_y,
groesse.x,
groesse.y,
SYS_COL_SHADOW,
SYS_COL_HIGHLIGHT
);
}

};


Thank you Prissi...
- My code doesn't have bugs. It develops random features...

Markohs

While doing this patch, that is deep enough to break any patch that was related to the gui.... Doesn't make sense to finally translate get_groesse to get_size and zeichnen to draw?

Max-Max

Yes it does, but should we not make this in small steps?

I really want to refactor the German names in the GUI. But I think we need to make it as a separate patch.
I'm planning to go deeper into the GUI, maybe the refactoring would be a good start.
- My code doesn't have bugs. It develops random features...

prissi

#139
Whole family had caught a bug. I will start now, so you are not forgotten.

EDIT:
- Should not the gadget size be taken from the actual gadget?
- Should not gui_image_t also get an alignment parameter; in this case even ALIGN_CENTER_V and ALIGN_CENTER_H makes sense? It would then align the element in the middle.
- editfield and normal button different height will almost certainly lead to ugly dialogues. Furthermore, if too small to be caught be finger for switching, it will be also too small for editing, or?