Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - texus

Pages: 1 [2] 3 4 ... 94
General Discussion / Re: Kitchen Sink
« on: 11 June 2019, 17:53:23 »
How would a texture of a label be displayed? Do you mean a BackgroundTexture property as alternative to the BackgroundColor?

General Discussion / Re: Kitchen Sink
« on: 10 June 2019, 15:03:29 »
I think it would definitely be useful.

General Discussion / Re: Buttons 0.9
« on: 08 June 2019, 11:52:31 »
Yesterday is saw default argument in "ignoreMouseEvents" (picture). Ok, why setEnabled or setVisible on the other hand don't have.
Because setEnabled and setVisible are equally likely to be called with true or false while you would only call ignoreMouseEvents with true (as false is the default and you typically don't toggle that property). That being said, I know that some function have default arguments while others don't where I can't make such a clear distinction. The problem is that I don't really like the default arguments as I feel like people might incorrectly see them as an indication of what the default is when the function isn't called and the default parameter value is usually the exact opposite of the default value used by the widget. So in more recent additions I didn't add a default argument at all.

Instead of rewriting the whole project why don't you add the missing widgets.
Because widgets and extra functions can always be contributed by others, nobody other than me is going to change the architecture of the entire gui.
I also tend to work in 2 phases, during development of a new version I can change the API so I try to change as much as possible at once while after the API gets more stable again I can focus on adding functionality that doesn't break the API (such as adding new widgets). By spending too much time in the unstable phase I always end up dividing the community in 2 versions (those using the older stable version and those using the newest unstable version), so I don't want this phase to last longer than 1-2 years. So things that can be done after tha API gets stable tend to get delayed during early development of a new version.

There are a lot of tiny improvements that can be done. Like having all those "signalNames" for all widgets in one place!
This is hard to do with the inheritance. I'm also planning on a system like using the onSignal objects directly instead of using the signal names so it might get even more difficult to get things in one place.

General Discussion / Re: Picture and OpacityDisabled
« on: 07 June 2019, 14:01:08 »
It seems to work for me. Could you share the code you are using (it may be related to the order things are executed)?

General Discussion / Re: showWithEffect and hideWithEffect
« on: 07 June 2019, 13:02:41 »
This should be fixed now.

General Discussion / Re: showWithEffect and hideWithEffect
« on: 06 June 2019, 20:15:51 »
You are right, the value is indeed incorrectly reset. The code actually does reset the value to 255 by immediately finishing the show animation, but this happens just after the hide animation had already looked at the current alpha value.

I'll see if I can fix this tomorrow.

General Discussion / Re: TGUI and Unicode
« on: 04 June 2019, 16:44:47 »
Based on what I can find, Arial itself doesn't support these characters. I just downloaded a font called "Arial Unicode MS" which is 22MB in size and the characters are being displayed correctly.

My code is as simple as this:
const char* buffer = "\x41\x42\xe6\x9d\xb1\xe4\xba\xac";
text->setText(sf::String::fromUtf8(&buffer[0], &buffer[8]));

Edit: for some reason that I haven't figured out yet, it only works when you use "m_labShipname->getRenderer()->setFont(font)" like you are doing. When using tgui::setGlobalFont I still get squares.
Edit 2: That seemed to be because I need to keep the font alive which is passed to setGlobalFont. Once I did that it also works when setting a global font.

General Discussion / Re: TGUI and Unicode
« on: 04 June 2019, 16:22:00 »
I don't see anything wrong with your steps.

Maybe storing the buffer in an std::string can be skipped if fromUtf8 supports a begin and end pointer (I'm not sure if it does), but it will work equally well when first stored in an std::string.

The type is Uint32 because it stores the string as UTF32. Two bytes wouldn't be enough to store ALL possible unicode characters.

If squares are displayed then it would mean that the chosen font (arial.ttf in this case) does not contain these japanese characters.

Themes / ===== Read before posting =====
« on: 04 June 2019, 12:50:02 »
In this forum section you can share themes that you created. For general help with themes, the help requests section would be a more suitable place.

When sharing a theme, please provide at least the following information:
  • A list of widgets supported by your theme
  • A screenshot showing some of the widgets with your theme

All themes shared here are freely usable and considered public domain unless explicitly stated otherwise!

General Discussion / Re: Buttons 0.9
« on: 02 June 2019, 14:30:31 »
What exactly do you want to me to look at with that gui?
FairyGUI looks great, and they focus completely on games, 2 things you can't say about TGUI :)

I'm currently unsure how TGUI should continue in 0.9. There are just too many customizations to implement to really have a tunable gui (and I don't have the time to implement them). So I want to provide some way that the user can write their own code to extend the widgets. That way they can still do complex things (as I can't provide code for every scenario) while it would also be possible for me to sometimes merge the code back into TGUI to provide the functionality for everyone.

I'm completely stuck on a design for this though. The current design doesn't make it easy to extend the widgets at all, you would have to inherit both the widget and the renderer and override multiple functions. I was thinking about moving the draw function to the renderer so that most of the time you only need to inherit from the renderer. The issues with splitting the code in 2 part still remain though: mouse event functions and draw functions need to be equivalent, mouse press needs to know about borders, padding and spaces between items, which would all depend on the custom draw function.

Merging the widget and renderer into a single class again would simplify things and probably make it easier to extend it, but it probably makes it more difficult to implement skins. I tried looking into the code of some other guis but they usually have a complex structure. That is probably good for the extendability but I want to keep TGUI easy to use as well. It don't want to e.g. make it more difficult to have a simple list box with some strings just because someone may want to create a list box with subwidgets.

So instead of thinking about all that, I'm currently just spending my spare time playing borderlands 2, which is why I haven't responded for a few days :)

General Discussion / Re: Buttons 0.9
« on: 30 May 2019, 15:30:21 »
I can't see why you bother about the space next to text or even in front of it or up or down if someone sets new relative position?
Because the space could potentially be implemented in the Text class itself instead of having to add the margin in practically every widget. But 0.9 probably won't even have a Text class anymore, so we'll see how it turns out.

I've decided to not implement the text positioning now and first work on rewriting the core of the gui before further looking into it. One of the goals in 0.9 is to figure out how to make it easier for the user to implement custom customizations on top of what TGUI provides and I feel like I should try to get that in a working state before looking at which extra customizations can be provided out of the box.
Figuring out how to best allow the user position the text makes me think about other changes as well. I have similar "issues" with e.g. the Tab widget: how do I allow users to control where they put the text. If there was an icon in the tab then the text could be next to it, or below it or above it. There should be a distance to the sides of the tab and another distance between the text and icon. Both the icons and text should be sizeable as well. There is a huge amount of minor tweaks that the user might want to make and it is a lot of work to provide them. Just thinking about all the different customizations that I would have to provide makes me want to stop working on it :).

General Discussion / Re: Buttons 0.9
« on: 30 May 2019, 11:55:31 »
maybe i misunderstand something here. I thought that you using setKeyRepeatEnabled with true parameter inside TGUI but that's is not happening. Correct?
TGUI doesn't call the function. I meant that the TGUI behavior would change if you called that function in your code and the button only works like described when key repeating is set to true (default).

You can add setHorizontalAlignment and setVerticalAlignment like label and half of the problem goes away.
I feel like for buttons these functions belong in the ButtonRenderer class because they are about how a button will be rendered (unlike in Label where they are about how to align the label with other widgets), but I'll probably have to put them in the Button class. Functions like these really make me question if I wouldn't be able to find a better design to split widgets and their renderers.

I'm also not sure what do with the distance from the side yet. This is an issue that affects many widgets. If you put the text on the left side, do you expect it to start at pixel 0? This is how it looked in 0.7 and it looked terrible (because the black text touched the black border on the left). In 0.8 I added a small fixed margin between the side and the text to improve it. In 0.9-dev I was planning on making the margin even larger because I'm still not happy on how it looks with small texts. If you were to set setRelativeTextPosition(0,0) there would still be some space next to the text. This might be good because you probably don't really want the text against the side, but it might be unexpected as you are specifying (0,0). In this case adding a padding would solve the issue (although a default padding that isn't 0 is weird too), but in other widgets like ListView the distance is needed to keep the texts away from the column separators and a padding property isn't appropriate there (since there already is a padding but it goes around the entire list).
This is of course a whole different discussion, but depending on what you want when setting setRelativeTextPosition(0,0), the current implementation that placed a small space next to every text might be an issue.

General Discussion / Re: Buttons 0.9
« on: 30 May 2019, 09:41:01 »
So the following will definately be in 0.9-dev when it gets released:
- Every state can have a text color and text style (already in 0.8)
- Button can have an outline thickness and outline color (same for all states)
- Batch for rendering

Things to look into for 0.9-dev:
- Toggle and switch buttons
- Way to disabling hover state
- "Continuality" option
- Way to handling space and return

For the "continuality", how about a "setPressRepeat(sf::Time duration)" function? If set to 0 (default) then the button triggers on mouse up, but when a duration is set it would trigger the pressed signal on mouse down and again after every "duration".

While I was thinking about adding an enablePressBySpaceOrReturn function to disable space and return keys, I'm not sure if that would be the best way. I've looked online for questions where people ask to disable the space key and found the following behaviors:
- For javascript, the solution would be to either intercept the key event or to unfocus the button when you receive the focus event.
- For windows apps / .Net, the solution was to either intercept the key event or set IsTabStop to false to prevent the button from gaining focus.
- For unity, "Navigation" has to be set to "None", which as far as I can tell on first sight means not allowing it to be focused.
- Other random results came up where it was impossible to change the behavior or where it was suggested to unfocus the button after it gains focus.

So I think it might be better to add a function that prevents the button from gaining focus, instead of adding a function that disables space and return.

Every text can have its own vertical and horizontal alignment on a given position inside the button. YES to position inside and YES to both alignments.
This is still the part that I find the most difficult to provide a generic solution for. I agree that the buttons you showed look great, but I'm not sure how to best give enough control to set the text position for buttons like that.

Maybe I shouldn't try to get the functionality in TGUI but to just make it easy enough to add it yourself? Imagine if you would be able to inherit from renderer classes and the ButtonRenderer would have a virtual function like this:
void ButtonRenderer::drawText(RenderTarget& target, const Button* button, const FloatRect& rect, const String& text) const
    const TextProperties& textProperties{getCurrentTextColor(button), getCurrentTextStyle(button), m_textOutlineThickness, m_textOutlineColor};
    const FloatRect& bounds = target.calcTextBounds(text, textProperties);
    target.drawText(text, textProperties, {rect.left + (rect.width - bounds.width) / 2.f, + (rect.height - bounds.height) / 2.f});

All you would have to do is inherit from ButtonRenderer, override just the drawText function with your own implementation and call button->setRenderer(...) with an instance of your custom renderer.

General Discussion / Re: Buttons 0.9
« on: 30 May 2019, 08:42:26 »
Perhaps this must be optional.
What should be optional exactly?

Like slot games or DJ programs for example.
Slot games and dj programs aren't the ones where I imagine people tabbing between buttons and using space to activate them, so you would only need mouse events. If you only need the mouse events (or touch events) then you can use the MousePressed signal to get a callback when the button is pressed down.

General Discussion / Re: Buttons 0.9
« on: 29 May 2019, 22:44:26 »
What happening if u call "mWindow.setKeyRepeatEnabled(false)". Still buttons trigering all the time via key down event?
Then it would only trigger once because the key press event would only be send once. It simply responds to the sf::Event::KeyPressed event that you get from SFML's pollEvent.

To clarify something. Space and enter do not have the same behaviour on buttons? if Yes how is this possible?
In TGUI they do have the same behavior, but I tested it on a simple HTML button with both firefox and chrome and it looks like they really do have different behavior for space and return. (I tested it via where I replaced the onclick event with "console.log('test')"). While looking into the onSelect event for edit box recently I saw really weird behavior with HTML as well so I wouldn't want to blindly copy their behavior, but it does raise questions about what the most common behavior is.

My linux system seems to repeat for both space and return key, so it seems to work exactly like TGUI works now (with setKeyRepeatEnabled set to true).

In my codes over the years i never used mouse up or key up events to fire an action on buttons.
As far as I can tell it is the most common way to fire on mouse up events, all buttons that I come in contact with seem to work that way.

Pages: 1 [2] 3 4 ... 94