Opinions on this project.
I decided it might be worthwhile to ask here for some opinions on a project I've been working on for a bit.
Something that I've ran into on multiple occasions is frustrations with GUI libraries for applications that still need low level access to rendering. Don't get me wrong, I'll use libraries like Qt or Gtk when I can, but in some cases they become very frustrating to work with.
These libraries do anticipate the need for things like "glWidgets". They seem to tend to come with frustrating intermediary rendering APIs and other annoying quirks. Also, you find cases like this (http://www.shamusyoung.com/twentysidedtale/?p=15904) where the GUI library is greedier than you'd like, but there's nothing you can do to help it so long as you use that GUI library.
If you want to use a library with rendering capabilities like SDL/SFML or Irrlicht/Ogre, have fun with that. It seems people have figured it out with Ogre before.
(http://www.ogre3d.org/tikiwiki/tiki-index.php?page=Integrating+Ogre+into+QT5)
Yeah, that looks really fun having to go through hell to create a whole new structure to get the two libs to cooperate.
In a nutshell, my problem is sometimes you want to actually keep a good level of control over the lower level aspects of your app, and the mainstream GUI libraries get in your way when trying to do that. For many cases they're fine, but not always.
After a while of getting more and more tired of stepping around egg shells with libs like Qt/Gtk for some of the work I do, I decided screw it, there's gotta be a way to make something better for this.
For a bit now I've been working on a GUI library that is designed to handle purely logic. It doesn't make any assumptions about how input and rendering are to be handled. It's designed so that those things are to be wired to the users implementation.
You could say it's similar to the goal of IMGui except it doesn't give any form of rendering output at all, and is intended to be more flexible.
The things provided right now are:
- Gui structure for managing widgets
- Very exposed interface for creating custom widgets
- Signal/Function binding system for having widgets react to input
- Properties system to add properties to widgets and guis
- General functionality for very common GUI logic
- Small collection of pre-built widgets
I get that the majority of people would never need a library like this, and hence it's quite niche usage. Pretending you were going to use a library like this however, what things about it would you want. Just general feedback would be nice to hear.
Something that I've ran into on multiple occasions is frustrations with GUI libraries for applications that still need low level access to rendering. Don't get me wrong, I'll use libraries like Qt or Gtk when I can, but in some cases they become very frustrating to work with.
These libraries do anticipate the need for things like "glWidgets". They seem to tend to come with frustrating intermediary rendering APIs and other annoying quirks. Also, you find cases like this (http://www.shamusyoung.com/twentysidedtale/?p=15904) where the GUI library is greedier than you'd like, but there's nothing you can do to help it so long as you use that GUI library.
If you want to use a library with rendering capabilities like SDL/SFML or Irrlicht/Ogre, have fun with that. It seems people have figured it out with Ogre before.
(http://www.ogre3d.org/tikiwiki/tiki-index.php?page=Integrating+Ogre+into+QT5)
Yeah, that looks really fun having to go through hell to create a whole new structure to get the two libs to cooperate.
In a nutshell, my problem is sometimes you want to actually keep a good level of control over the lower level aspects of your app, and the mainstream GUI libraries get in your way when trying to do that. For many cases they're fine, but not always.
After a while of getting more and more tired of stepping around egg shells with libs like Qt/Gtk for some of the work I do, I decided screw it, there's gotta be a way to make something better for this.
For a bit now I've been working on a GUI library that is designed to handle purely logic. It doesn't make any assumptions about how input and rendering are to be handled. It's designed so that those things are to be wired to the users implementation.
You could say it's similar to the goal of IMGui except it doesn't give any form of rendering output at all, and is intended to be more flexible.
The things provided right now are:
- Gui structure for managing widgets
- Very exposed interface for creating custom widgets
- Signal/Function binding system for having widgets react to input
- Properties system to add properties to widgets and guis
- General functionality for very common GUI logic
- Small collection of pre-built widgets
I get that the majority of people would never need a library like this, and hence it's quite niche usage. Pretending you were going to use a library like this however, what things about it would you want. Just general feedback would be nice to hear.
My wishlist for something like this:
* Arbitrary creation of threaded event handlers, so that different tasks could be handled on different threads, all separate from the main UI.
* An animation infrastructure that's programmer-friendly. End users can be incredibly superficial.
* UI elements that scale very nicely with canvas resolution.
-Albatross
* Arbitrary creation of threaded event handlers, so that different tasks could be handled on different threads, all separate from the main UI.
* An animation infrastructure that's programmer-friendly. End users can be incredibly superficial.
* UI elements that scale very nicely with canvas resolution.
-Albatross
The threading is an interesting idea. I feel that if that was going to be added, implementing it now would be the best time to avoid having to make major changes later. It's something I'll be sure to look into.
An animation infrastructure is something I've thought about. Currently I've felt something that resembles something kind of like this https://tgui.eu/tutorials/v0.7/show-hide-animations/ could make for a decent start. It could be made more advanced in the future but one step at a time as they say.
The scaling I'm already going to implement, I just haven't gotten to it yet. There will be the "lazy" method, where you can just pack your widgets into special containers like horizontal/vertical layouts and grids. If the programmer wants more control however they can handle it when they bind their process function to the gui and read a "resize" event.
An animation infrastructure is something I've thought about. Currently I've felt something that resembles something kind of like this https://tgui.eu/tutorials/v0.7/show-hide-animations/ could make for a decent start. It could be made more advanced in the future but one step at a time as they say.
The scaling I'm already going to implement, I just haven't gotten to it yet. There will be the "lazy" method, where you can just pack your widgets into special containers like horizontal/vertical layouts and grids. If the programmer wants more control however they can handle it when they bind their process function to the gui and read a "resize" event.
+1 Albatross
Especially the multithreaded aspect, having easy multithreaded support would make your project super valuable.
Especially the multithreaded aspect, having easy multithreaded support would make your project super valuable.
Topic archived. No new replies allowed.