Jump to content
  • Advertisement
Sign in to follow this  
  • entry
    1
  • comments
    7
  • views
    777

UI, for the love of God. UI..

Spool

976 views

A couple months ago I decided to delve into the dark arts that are seemingly only attempted by the bravest of programmers. UI Framework development. While honestly I didn't fully understand what designing and creating a UI Framework from scratch truly entailed, I had some notion that it was no easy feat. As such should be approached with caution if not entirely avoided as the amount of UI Frameworks available are as numerous and the reasons not to make one yourself. But, I decided to embark on the journey anyway..

 

I guess the first big question you would ask is, Why? Why would you want to do that. 

To be honest, I asked myself that very question. The answer I came up with may seem rather shallow and the hallmark of an inexperienced developer..

They all suck. 

In *my* personal opinion anyway. Yes, they all suck.  

But that seems to be the norm in software development, we work with things that we don't really like because the idea of making the utility they provide ourselves is just as miserable if not more so than using the framework or tool in the first place. Anyway back to why all UI Frameworks suck. From hours and hours of scanning through endless lines of Desktop UI Framework source code repositories, I have come to two major conclusions about most if not all of them. 

1: They all do WAY to much and try to handle every single feature, problem, platform, style, you name it. They end up bloated piles of code that seem to have no cohesive structure.

2: Everyone of them seem to have a ridiculous monolithic base Widget class that does EVERYTHING. So when you have a Screen full of Buttons you have all the infrastructure and memory requirements needed if you were to have a Screen full of Windows containing many other Widgets. Wasteful and unnecessary.

 

To be honest, I can see why these traits are common. UI is complex. It needs to be reusable and flexible enough to fit into any application that wants to utilize it. Doing so in a clean concise manner is no easy task. Its very easy to indulge in the temptation of easiest implementation is the best implementation. After all, people need their UI's in a timely fashion. But what if we didn't do that? What if we really sat down and looked at how a UI operates, what it *needs* to do. What type of general structure would work best for those needs. 

 

This is what I decided to do. I decided that if I was going to make this, I was going to do it right. By my standards anyway. 

Next post I intend to go into my thoughts on how UI *should* be. If anyone read this. Thanks, feel free to yell at me in the comments. 



7 Comments


Recommended Comments

"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?

 

 

Edited by Scouting Ninja

Share this comment


Link to comment

@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. 

Share this comment


Link to comment
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?

Share this comment


Link to comment
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. 

Share this comment


Link to comment
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. :)

Share this comment


Link to comment

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

 

Edited by DexterZ101

Share this comment


Link to comment
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! :) 

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!