"Widget class that does EVERYTHING."

From my own experiences with UI is that the widget class often is just a abstract class or a very limited class. That is to say it does nothing or just keeps track of position and collision, it's function is to group object types into a single group.

How would you replace this?

@Scouting Ninja

My own experience with other Frameworks is the exact opposite. I don't want to name any specific ones as that seems rather rude given the context. 

I am not saying to replace this type of functionality. It makes perfect sense to have a base element with common data and very basic common logic. But that seems to get out of hand very quickly. 

6 minutes ago, Spool said:

But that seems to get out of hand very quickly. 

It could be as you say that a lot of these UI framework are made in a rush, so planing is skipped on a lot of them. However most of the UI framework I have used tend to be well optimized.

Maybe I just see the problem less because I keep using the same frameworks over and over and haven't tried one of the more up to date ones yet. These days I mostly use engines.

So what futures will be the focus of your framework?

1 minute ago, Scouting Ninja said:

So what futures will be the focus of your framework?

This is what I will go into in the next post

2 minutes ago, Scouting Ninja said:

It could be as you say that a lot of these UI framework are made in a rush, so planing is skipped on a lot of them. However most of the UI framework I have used tend to be well optimized.

Maybe I just see the problem less because I keep using the same frameworks over and over and haven't tried one of the more up to date ones yet. These days I mostly use engines.

I think that's a big part of it. On one hand most of the time you don't care about how a Framework is structured. As long as it works and works well for you who cares. Totally see that. On the other hand.. what if you need more than that? What if you need less than that? What if that Framework dies? What if it doesn't support the platform you want? I mean granted these are very general concerns. None but one of which where part of the reason that I decided to make my own. But still. They should be considered. 

Quote

The answer I came up with may seem rather shallow and the hallmark of an inexperienced developer..

They all suck.

Two things:

1. Firstly, as you admit here, one issue is that you as yet have little knowledge of the problem space, because you haven't explored it yet. So this makes it difficult for you to be able to appraise these systems (you may see them more as a user rather than a developer / maintainer). Some might be doing things in what you consider 'odd' ways, which may more sense when you understand the problem they are solving, and the constraints.
2. Secondly, some probably do suck somewhat. :) As with a lot of software engineering, authors might start down a path, and find that the early design determines the decisions available to them further down the line. Rather than throw out the whole thing, they end up tacking stuff on to 'make it work', and the result isn't so elegant, whereas ideally they would start again and create UI framework 2.0, or at least be prepared to do a lot of refactoring.

The reason why many UIs use inheritance or have some kind of base widget is because UIs are typically a tree structure (if you move a window you want all the child widgets to move with it).

If you want to deal with traversing the tree in multiple ways, arranging elements, etc, then you don't want to write different code to deal with different widgets, 95% of the time. Although inheritance is somewhat less in vogue these days (with DOD and entity component systems becoming more popular), this is a one example where inheritance can be used to make a viable solution (at least to start with, you may use something more esoteric later on).

Overall I personally found it very worthwhile writing at least a basic GUI system. It really isn't rocket science to get the basics working, is great for learning how they work, and you should be able to use yours in a game even if you don't get the time to scale it up to work in a fully blown app. :)

Most UI framework available in the wild are mostly targeted larger audience UI are mostly use in business application. I'm own the same boat to write your own specific UI engine  if you have the luxury of time and for learning experience why not... I want a UI framework specifically for games which is image base that leads me create my own.

https://youtu.be/AQ9w3g8UjOM

13 hours ago, lawnjelly said:

Two things:

1. Firstly, as you admit here, one issue is that you as yet have little knowledge of the problem space, because you haven't explored it yet. So this makes it difficult for you to be able to appraise these systems (you may see them more as a user rather than a developer / maintainer). Some might be doing things in what you consider 'odd' ways, which may more sense when you understand the problem they are solving, and the constraints.
2. Secondly, some probably do suck somewhat. As with a lot of software engineering, authors might start down a path, and find that the early design determines the decisions available to them further down the line. Rather than throw out the whole thing, they end up tacking stuff on to 'make it work', and the result isn't so elegant, whereas ideally they would start again and create UI framework 2.0, or at least be prepared to do a lot of refactoring.

The reason why many UIs use inheritance or have some kind of base widget is because UIs are typically a tree structure (if you move a window you want all the child widgets to move with it).

If you want to deal with traversing the tree in multiple ways, arranging elements, etc, then you don't want to write different code to deal with different widgets, 95% of the time. Although inheritance is somewhat less in vogue these days (with DOD and entity component systems becoming more popular), this is a one example where inheritance can be used to make a viable solution (at least to start with, you may use something more esoteric later on).

Overall I personally found it very worthwhile writing at least a basic GUI system. It really isn't rocket science to get the basics working, is great for learning how they work, and you should be able to use yours in a game even if you don't get the time to scale it up to work in a fully blown app.

1: Yes, generally speaking from a number of years experience viewpoint I am relatively inexperienced. But I have made multiple semi complex UI systems in the traditional way. So I wouldn't necessarily say that I have "little" knowledge of the problem space. But generally speak I am somewhat inexperienced.

2: Of course, I couldn't agree more. But I am advocating learning from those design "mistakes" < personal opinion, and using that to our advantage. Rather than just using the framework at all. 

I am not saying inheritance is bad. The functionality that it provides is useful, and given the context is very appropriate. I am saying the use of inheritance is what is bad in most of these frameworks. The tool isn't bad. Its the use of the tool that is bad. Bad isn't really a good word but I think you know what I mean. 

Yes, I agree. Making a basic UI system I think is very educational and personally has taught me a lot. I just happened to get sucked into the semi philosophical understanding of what seemingly is a common trend in these types of software and decided to give it a try and make it into something I thought was better. 

Thanks for the reply, and giving it a read. Cheers!