Recent Posts

Pages: 1 ... 7 8 [9] 10
81
General Discussion / Re: Buttons 0.9
« Last post by texus on 28 May 2019, 20:24:09 »
Quote
Every state (Normal, hover, etc) can have its own text color.
Quote
Every text can have its own style (regular, bold).
This is already possible in TGUI, so they don't need further discussion.

Quote
Outline can have a thickness value.
This will definitely be the case once I add support for outlines.

Quote
Every text for every state can have its own outline border.
Do you mean outline color or also thickness? Colors I can agree with, but I feel like nobody would ever change the thickness per state even if I made it possible.

Quote
Every text can have its own size.
Do you mean for every state? If yes then the text size would have to become part of the renderer. The problem with doing that is that the renderer would include a "size". My idea is to let the renderer contain stuff like colors and let the widget have any size that it wants (so e.g. item height and text size are part of the widget itself). Putting text sizes in the renderer means that a renderer is only suitable for widgets of certain sizes (e.g. a renderer with text size 12px is useless for a button of height 200px), which I want to avoid. So this might be a bit difficult to implement.

Quote
Buttons can blink, meaning that over a period of time can change background and text appearence. For instance can tongle between normal sprite and focused sprite. (global timer)
This doesn't look very easy to implement as it requires a "global" state which overrides other focus/hover states. It might be better to implement this in user code. Of course it would be easier if the gui supported it directly, but it looks like a very niche feature. Same goes for other points below where I mention it can be done in your own code, it doesn't mean that it shouldn't be in the gui at all, just that it would get rather low priority.

Quote
Every text can have its own vertical and horizontal alignment on a given position inside the button (i can show you some button images if that is not clear).
Could you show some examples of cases where not centering the text looks good?

Quote
A button can trigger (or not) from one or more keys. In my game i give the owner the ability to add any key he wants for every available button.
To me this sounds like something that should be done in user code. The user has full control over what keys are pressed and what he wants to do in these cases. I could make things easier by adding a function to Button that calls the connected signal handlers so that the user doesn't has to call them manually.
This probably can't even be implemented at the level of the button itself as key pressed are only passed when the widget is focused and I assume you also mean key presses when the button isn't focused. If you did mean only triggering on these keys when the button is focused then I would like to hear some examples of cases where you use other keys than space and return.

Quote
Having 9,there is no need of having "space" and "enter" as default keys out of the box.
I actually want these things to work out of the box. I want TGUI to be as easy to use a possible, so things that most people want should be the default behavior.
The big problem is that I don't have a specific target audience for TGUI which means that it is hard to predict what most people would want and people use TGUI in very different situations and will want different behaviors.
If triggering on space and return remains the default then I do agree that there should be some way to disable the behavior for those that don't want it.

Quote
Focusing in my opinion is over estimated but essential when you want to navigate with tab box. Bilinking over rules hovering and focusing.
Being able to tab between widgets is the main reason why focusing even exists in TGUI. That and figuring out which edit box should get the key presses.
If blinking overrules focusing, then basically you can't do anything while something is blinking (except for e.g. pressing the blinking button)?

Quote
Pressed time for "m_spriteDown" must be configurable. Action of triggering must be on the last frame. Zero value triggers the button at once showing one down frame.
Do you mean that the down state should automatically jump to normal state even when keeping the mouse button pressed? Can you give some examples where this is used?

Quote
Clicks or key presses can have "continuality" or not. Meaning that over pressing time, buttons can re-triggered as long as mouse or key is down.
This could be useful for implementing custom spin buttons where you have one button with a "-" and one button with a "+". Is that what you had in mind or did you know another use case for this?
Although for a spin button I feel like it should trigger immediately on mouse down, then after a "long" time trigger a second time and then each time after a "short" time trigger again. So that would be different from the "continuality", which wouldn't trigger immediately after mouse down? Or maybe it does trigger immediately on mouse down when this "continuality" setting is enabled?

Quote
A button can be tongle - switch button. (I saw you think for a different widget. It is not a bad idea having different widget. In my case is configurable (setTongle)).
I'm not sure how to best implement this, but this is the one thing on your list that I find the most important (which doesn't mean that it will be the first thing to be added though).

Quote
Hovering can be disabled in touch screens because it is unnecessary (for all widgets).
Touch screen support is something that needs further investigation. TGUI was written as a desktop gui and I've never really used it on a touch screen (except for some brief tests with android), so some there are probably some other improvements that could be made as well. So maybe there should be some global toggle to change touch screen friendliness which would disable hovering for all widgets. The main problem would be to figure out whether a touch screen is used or not, but that would be up to the user. If the user doesn't explicitly asks to disable the hover states then I don't think I should make that decision in TGUI because I can't be certain that the device will only be used as a touch screen.

Quote
Batch for rendering.
Currently TGUI 0.9-dev is being designed such that all rendering has to go through a minimal interface. Drawing to the screen is only possible through this interface so everything that gets rendered will be batchable together with other widgets.

Quote
Having different text position or and text size you can have very pretty pressed states. The text can grow or can be positioned a little downwards during the pressed event.
This would look nice but I fear that this is hard to do. The user would have to hardcode the text position in the renderer?

Quote
Having a simple enum for all button states, you can simplify the code so you can have one function for all states.
That would indeed simplify things.
Ideally I would just have some properties that you can set directly instead of needing setters and getters but that will probably never work (because the widget needs to be notified about some changes such as border thickness and because I would like to be able to cache rendering in 0.9-dev which is only possible if I can detect that changes were made).
Given the huge amount of tunable things in the renderer I even considered having the property, setter and getter (both declaration and definition) generated with a define. The big issue with that is that I wouldn't be able to document the properties.
82
General Discussion / Re: warnings building latest tgui
« Last post by texus on 28 May 2019, 19:04:32 »
Thanks, the warnings have been fixed.

The unreachable code warning also shows up in my AppVeyor builds, the others don't.
There still seems to be a signed/unsigned mismatch warning that I get in my VS2017 build that isn't showing up with VS2015, but I'll fix that later (as my VS2017 build is a unity build which makes it harder to find where the warning came from).
83
General Discussion / warnings building latest tgui
« Last post by billarhos on 28 May 2019, 14:17:08 »

Some warnings appeared building (32bit) latest tgui source code (github) with visual studio 2015.

nanosvg.h(807): warning C4702: unreachable code
GuiBuilder.cpp(1480): warning C4800: 'unsigned int': forcing value to bool 'true' or 'false' (performance warning)
GuiBuilder.cpp(1481): warning C4800: 'unsigned int': forcing value to bool 'true' or 'false' (performance warning)
GuiBuilder.cpp(1482): warning C4800: 'unsigned int': forcing value to bool 'true' or 'false' (performance warning)

84
General Discussion / Re: Buttons 0.9
« Last post by billarhos on 28 May 2019, 08:59:23 »
Do not worry. All those need time for a proper discussion.


Code: [Select]
enum button_States
{
Normal,
Hover,
Down,
Disabled,
Focused
};

Sprite m_sprite[5];
Color   m_borderColor[5];
Color   m_backgroundColor[5];
Color    m_TextColor[5];

void setBackgroundColor(button_States state, Color color);
void setTextColor(button_States state, Color color);

Having a simple enum for all button states, you can simplify the code so you can have one function for all states.

85
General Discussion / Re: Buttons 0.9
« Last post by texus on 28 May 2019, 08:20:26 »
Just wanted to let you know that I haven't forgotten about this yet, I just haven't had the time yet to go over the list in detail.
86
General Discussion / Re: Buttons 0.9
« Last post by billarhos on 26 May 2019, 09:29:43 »
Having different text position or and text size you can have very pretty pressed states. The text can grow or can be positioned a little downwards during the pressed event.
87
General Discussion / Buttons 0.9
« Last post by billarhos on 26 May 2019, 08:26:21 »
  • Buttons can blink, meaning that over a period of time can change background and text appearence. For instance can tongle between normal sprite and focused sprite. (global timer)
  • Every state (Normal, hover, etc) can have its own text color.
  • Every text for every state can have its own outline border.
  • Outline can have a thickness value.
  • Every text can have its own style (regular, bold).
  • Every text can have its own size.
  • Every text can have its own vertical and horizontal alignment on a given position inside the button (i can show you some button images if that is not clear).
  • A button can trigger (or not) from one or more keys. In my game i give the owner the ability to add any key he wants for every available button.
  • Having 9,there is no need of having "space" and "enter" as default keys out of the box.
  • Focusing in my opinion is over estimated but essential when you want to navigate with tab box. Bilinking over rules hovering and focusing.
  • Pressed time for "m_spriteDown" must be configurable. Action of triggering must be on the last frame. Zero value triggers the button at once showing one down frame.
  • Clicks or key presses can have "continuality" or not. Meaning that over pressing time, buttons can re-triggered as long as mouse or key is down.
  • A button can be tongle - switch button. (I saw you think for a different widget. It is not a bad idea having different widget. In my case is configurable (setTongle)).
  • Hovering can be disabled in touch screens because it is unnecessary (for all widgets).
  • Batch for rendering.

 Those are some stuff that i have implemented in my codes over the years. Buttons and lists are the more demanding widgets in my opinion.
88
General Discussion / Re: About TGUI 0.9-dev
« Last post by billarhos on 26 May 2019, 06:55:27 »
Perhaps i should used a better expression instead of absolute. I didn't have in my any vodka since i drink tequila. I meant more control in look and in functionality. I can't see how my prospective will affect them over the other widgets since all widgets have some default view. But let me open a new thread where i can explain in details.
89
General Discussion / Re: About TGUI 0.9-dev
« Last post by texus on 25 May 2019, 19:37:47 »
Quote
the absolute buttons
What did you mean with this part exactly?
Any help to improve TGUI is always welcome, although the look of only buttons isn't going to have much value if the rest of the gui looks completely different.
90
General Discussion / Re: About TGUI 0.9-dev
« Last post by billarhos on 25 May 2019, 17:00:06 »
If you really want the absolute buttons, do not hesitate to ask me.
I am creating game buttons (directX opengl) for more than 18 years,
having all kind of controls like keyboard, touch, mouse, external electronic devices (www.heber.co.uk)

But now i am going to play music as DJ in a Greek bar (Thessaloniki Greece). I know i am old (47) but what the fcuk, a hobby is a hobby.
I see you tomorrow.
Pages: 1 ... 7 8 [9] 10