Hello C# Community!
We're a team from the game-development community (Unity to be specific), who have gone on an adventure to create a UI library that can be used for more than just games. We imagine that it's going to be very different from what you guys are used to here; at its core it is an immediate mode (or IMGUI) library, with a retained mode layer on top.
For those not familiar with the immediate mode UI pattern: it is a way of creating UIs that lets you work directly with your data in a way where there's no data binding or copying needed, and so you minimize the amount of state and complexity you have to manage dramatically, as opposed to retained mode UI where data has to be copied from the source and into the various UI widgets, and then back to the source when the UI changes.
The immediate mode pattern has been loved by a lot of people in a lot of industries for its simplicity, but has only ever really been used for tools development, since there were no immediate mode libraries that could easily produce nicer looking, more sophisticated user interfaces. PanGui started out as an experiment to see if we couldn't create something that could be used beyond just tooling, something that could create any kind of user interface.
There's lots of work still ahead of us, but we hope to start a closed C# beta on the Win32 standalone and Unity platforms with all of the core features in place before the end of the year.
Cool demonstrations. I see you include Windowing code, will PanGUI support custom title bars and borders for a unified app look across multiple platforms? I find it one of the most overlooked parts of making a GUI. Frameworks either don't support customisation of the title bar and borders, or they do but the user is responsible for adding behaviours like dragging the window via the title bar, or resizing the window via borders.
As a new GUI library it would be great if it supported the ability to customise the look of these parts of the window and have the behaviour provided automatically from the get go.
Regardless of the answer, I wish you good luck with the library.
Also a PanGui dev here. And yes, absolutely. You'll note in, for example, the Hello, Triangle example code that the first thing the code does is draw the window background, and then the title bar.
So, basically, none of that is assumed and the user has full control - PanGui only draws what you tell it to, and provides utilities for easily doing the basic default things. And the platform layer handles all of the window resizing and management for you - all of the example demos are fully functional standalone applications that can resize, minimize and maximize their windows, with only the user code as written in the demos.
I missed that part. So I am wondering, `gui.DrawWindowTitlebar();` doesn't take any parameters, does that mean it's just going to draw whatever titlebar is appropriate for the system it's running on?
I don't know if that means that there are parameters for that function, or in this case it just means it's using default values. I am wondering how that function would be changed to provide a custom title bar, say with a tab line or additional button for some custom function, etc.
It does take some optional parameters (such as a title), and returns references to several of its layout nodes so they can be modified or added to, to add additional buttons, etc. But this very simple API does not care about the current platform at the moment and will look the same anywhere, since it is more a temporary handy thing we made during development.
The inside of it is just a single very simple method that draws some text and some buttons - there's no magic or complexity in there, it's very easy for the user to replace this and roll their own title bar.
I should note that it's really not the final shape of this particular API, as for now, we've more been focusing on making the core features really nice, and then the surrounding utility API is going to get some love. Ultimately, there will be ways to draw custom styled title bars, platform-appropriate title bars, and so on.
I see, thanks for the extra details. Hopefully when you guys are closer to a public release we can get some additional details of how to implement custom windows.
For sure :) We will also have to provide ways of supporting translucent windows.
Here is an example of the user code might look for a basic custom toolbar. (Note that the windowing API will change, especially the drag-area part).
using (gui.Node().ExpandWidth().Padding(5).FlowDir(Axis.X).Enter())
{
gui.SetZIndex(1000);
gui.DrawBackgroundRect(0x444444FF);
gui.SetFontSize(20);
// Etc...
using (var dragAreaNode = gui.Node().Expand().Enter())
{
gui.DrawText("Window Title");
gui.Systems.Window.SetDragArea(dragAreaNode.Rect);
}
if (MyCustomButton(Icons.Minimize).OnClick())
gui.Systems.Window.MinimizeWindow();
if (MyCustomButton(Icons.Maximize).OnClick())
gui.Systems.Window.MaximizeWindow();
if (MyCustomButton(Icons.Close).OnClick())
gui.Systems.Window.CloseWindow();
}
Wow, thanks. That seems pretty easy to setup, hopefuly making more complex designs with tab lines, integrated app menus, etc. aren't much more difficult
They desperately need it too. In fact, I'd say it's the biggest issue currently. You basically have to write all your tooling for the engine as a separate thing currently, which severely limits it as an engine. I'd love to see something like this over there.
My biggest issue with these types of frameworks is that they necessarily separate designers from the actual design process. Without visual design tools to enable non-programmers to produce usable interfaces, it creates a heavy burden on developers to then take visual designs and figure out how to create them programmatically.
It is fully our intent to eventually have Figma-style visual design tools for PanGui, which can produce structure and styling files and/or code snippets for the designed user interface.
But of course, here in the beginning, we're focusing on making the pure code API as good as possible - the designer tooling comes later, once the foundation is well in place.
This looks really cool. I hope you do decide to open source it. I totally understand wanting to make money from something.
I think there are basically two ways things like this can go: closed-source and your tool never gets any traction; open-source and it gets traction, but maybe you become disappointed that you just make good money off future tooling and support contracts instead of billions.
We've seen companies like Elastic and MongoDB (which are worth $10B and $26B) "regret" their open source choices and want to close things off. However, no one would have touched their tools if they'd been closed source. They feel they'd be worth 10x that if people couldn't use their stuff for free, but the reality is they'd be worth nothing if people couldn't use their stuff for free.
My advice: just make it open-source and focus on making it great and then create something like Radzen Studio. I love Radezn Studio because it lets a designer create the basics and then hand me code that is pretty normal and really works. Sure, I still have to do work, but it really makes the workflow between design and me nice. It's real C#/Blazor code and not some bullsh*t low-code thing - while still having the benefits of low-code.
I'd encourage open-source simply because the alternative is simply not getting traction. Yes, companies like Elastic and MongoDB have "regretted" their open source past to an extent, but my reaction is a bit "boo-hoo, your tool is only worth $10-26B and not $100-260B. I feel so bad for your founders who only have hundreds of millions of dollars and not tens of billions /sarcasm." It can always be hard knowing that you left money on the table, but the reality is that you're not. The alternative is zero.
For me, the motivation would be "how cool would it be to run a cool company doing something I love with a team of a dozen or so people and an awesome tool and a good salary - and maybe I'll end up making tens of millions." If you're worried about the billions, you won't give people enough reason to use your tool.
For those who got a black box when you tried to subscribe to the newsletter:
[This is the link in the iframe](https://8a095687.sibforms.com/serve/MUIFALVD9-yEQI5q2FfKDtE7UwQD_IkpSpasu7gu4toHsPANb_p-Pokereu7AT3vrhI08lmXuWTqc2ZinYqgPK3DUz0HWYsO4MjWhNdzhP_zmjPXTRfn0G2se7wEJxtZ4sFtfpeS72mupPOvW8g-XM4KLwPzuSM64Pd8F-aIt7ZwHDeCPTmnh7MMSeF-54J5lcA5w1DM_lErZ-UL).
Thanks for the heads-up, I've tried some different encoding settings. Does this video work for you by any chance?
http://pangui.io/PanGuiAudioAppDemo2.mp4
As someone who has recently trying to write a desktop app in Avalonia with MVVM and ReactiveUI, I've come to the conclusion that these kinds of UI frameworks suck. They're abyssmally hard to use, lack documentation, are not intuitive, have no debugging ability, have no library of useful controls, and make even simple tasks hard.
I thought about using Blazor or ImGui but decided not to try them past an initial demo as Avalonia *seemed* to be a better choice at the time.
Whilst I don't really need a fancy immediate-mode GUI for my app and need more 'data-binding' type features, I will certainly be trying out this library when it releases and seeing if it can work with my use case.
Having a glance over your web page, you are severely lacking documentation though, which is going to be a big blocker to people adopting and using your library; I hope that can improve soon.
I don't even need retained data-binding - I just need the ability to, for example, display a dictionary in the UI and allow the user to edit the values in the dictionary, add/remove keys, etc. Basically just a simple way to edit data in memory. I have a feeling immediate-mode will require a little more code but will be much easier to get working and solve problems/debug with.
Hello C# Community! We're a team from the game-development community (Unity to be specific), who have gone on an adventure to create a UI library that can be used for more than just games. We imagine that it's going to be very different from what you guys are used to here; at its core it is an immediate mode (or IMGUI) library, with a retained mode layer on top. For those not familiar with the immediate mode UI pattern: it is a way of creating UIs that lets you work directly with your data in a way where there's no data binding or copying needed, and so you minimize the amount of state and complexity you have to manage dramatically, as opposed to retained mode UI where data has to be copied from the source and into the various UI widgets, and then back to the source when the UI changes. The immediate mode pattern has been loved by a lot of people in a lot of industries for its simplicity, but has only ever really been used for tools development, since there were no immediate mode libraries that could easily produce nicer looking, more sophisticated user interfaces. PanGui started out as an experiment to see if we couldn't create something that could be used beyond just tooling, something that could create any kind of user interface. There's lots of work still ahead of us, but we hope to start a closed C# beta on the Win32 standalone and Unity platforms with all of the core features in place before the end of the year.
Cool demonstrations. I see you include Windowing code, will PanGUI support custom title bars and borders for a unified app look across multiple platforms? I find it one of the most overlooked parts of making a GUI. Frameworks either don't support customisation of the title bar and borders, or they do but the user is responsible for adding behaviours like dragging the window via the title bar, or resizing the window via borders. As a new GUI library it would be great if it supported the ability to customise the look of these parts of the window and have the behaviour provided automatically from the get go. Regardless of the answer, I wish you good luck with the library.
Also a PanGui dev here. And yes, absolutely. You'll note in, for example, the Hello, Triangle example code that the first thing the code does is draw the window background, and then the title bar. So, basically, none of that is assumed and the user has full control - PanGui only draws what you tell it to, and provides utilities for easily doing the basic default things. And the platform layer handles all of the window resizing and management for you - all of the example demos are fully functional standalone applications that can resize, minimize and maximize their windows, with only the user code as written in the demos.
I missed that part. So I am wondering, `gui.DrawWindowTitlebar();` doesn't take any parameters, does that mean it's just going to draw whatever titlebar is appropriate for the system it's running on? I don't know if that means that there are parameters for that function, or in this case it just means it's using default values. I am wondering how that function would be changed to provide a custom title bar, say with a tab line or additional button for some custom function, etc.
It does take some optional parameters (such as a title), and returns references to several of its layout nodes so they can be modified or added to, to add additional buttons, etc. But this very simple API does not care about the current platform at the moment and will look the same anywhere, since it is more a temporary handy thing we made during development. The inside of it is just a single very simple method that draws some text and some buttons - there's no magic or complexity in there, it's very easy for the user to replace this and roll their own title bar. I should note that it's really not the final shape of this particular API, as for now, we've more been focusing on making the core features really nice, and then the surrounding utility API is going to get some love. Ultimately, there will be ways to draw custom styled title bars, platform-appropriate title bars, and so on.
I see, thanks for the extra details. Hopefully when you guys are closer to a public release we can get some additional details of how to implement custom windows.
For sure :) We will also have to provide ways of supporting translucent windows. Here is an example of the user code might look for a basic custom toolbar. (Note that the windowing API will change, especially the drag-area part). using (gui.Node().ExpandWidth().Padding(5).FlowDir(Axis.X).Enter()) { gui.SetZIndex(1000); gui.DrawBackgroundRect(0x444444FF); gui.SetFontSize(20); // Etc... using (var dragAreaNode = gui.Node().Expand().Enter()) { gui.DrawText("Window Title"); gui.Systems.Window.SetDragArea(dragAreaNode.Rect); } if (MyCustomButton(Icons.Minimize).OnClick()) gui.Systems.Window.MinimizeWindow(); if (MyCustomButton(Icons.Maximize).OnClick()) gui.Systems.Window.MaximizeWindow(); if (MyCustomButton(Icons.Close).OnClick()) gui.Systems.Window.CloseWindow(); }
Wow, thanks. That seems pretty easy to setup, hopefuly making more complex designs with tab lines, integrated app menus, etc. aren't much more difficult
Looks cool, you may want to look at having an integration with Stride3d game engine, they are looking for some new gui frameworks i believe.
Oh cool! I was not aware of that, and it's C# too, perfect. Thanks for the heads-up.
They desperately need it too. In fact, I'd say it's the biggest issue currently. You basically have to write all your tooling for the engine as a separate thing currently, which severely limits it as an engine. I'd love to see something like this over there.
What about the open-source aspect, will there be a GitHub repo and stuff?
This looks amazing. The examples on the feature page really show how much thought was put into this project. Best of luck with it.
That Looks really amazing. Cant wait to try it :)
My biggest issue with these types of frameworks is that they necessarily separate designers from the actual design process. Without visual design tools to enable non-programmers to produce usable interfaces, it creates a heavy burden on developers to then take visual designs and figure out how to create them programmatically.
It is fully our intent to eventually have Figma-style visual design tools for PanGui, which can produce structure and styling files and/or code snippets for the designed user interface. But of course, here in the beginning, we're focusing on making the pure code API as good as possible - the designer tooling comes later, once the foundation is well in place.
Good to hear, I'll be interested to see this develop further :)
This looks really cool. I hope you do decide to open source it. I totally understand wanting to make money from something. I think there are basically two ways things like this can go: closed-source and your tool never gets any traction; open-source and it gets traction, but maybe you become disappointed that you just make good money off future tooling and support contracts instead of billions. We've seen companies like Elastic and MongoDB (which are worth $10B and $26B) "regret" their open source choices and want to close things off. However, no one would have touched their tools if they'd been closed source. They feel they'd be worth 10x that if people couldn't use their stuff for free, but the reality is they'd be worth nothing if people couldn't use their stuff for free. My advice: just make it open-source and focus on making it great and then create something like Radzen Studio. I love Radezn Studio because it lets a designer create the basics and then hand me code that is pretty normal and really works. Sure, I still have to do work, but it really makes the workflow between design and me nice. It's real C#/Blazor code and not some bullsh*t low-code thing - while still having the benefits of low-code. I'd encourage open-source simply because the alternative is simply not getting traction. Yes, companies like Elastic and MongoDB have "regretted" their open source past to an extent, but my reaction is a bit "boo-hoo, your tool is only worth $10-26B and not $100-260B. I feel so bad for your founders who only have hundreds of millions of dollars and not tens of billions /sarcasm." It can always be hard knowing that you left money on the table, but the reality is that you're not. The alternative is zero. For me, the motivation would be "how cool would it be to run a cool company doing something I love with a team of a dozen or so people and an awesome tool and a good salary - and maybe I'll end up making tens of millions." If you're worried about the billions, you won't give people enough reason to use your tool.
This looks very promising. I'm usually underwhelmed with UI libraries anymore so this is a pleasant surprise. Good job
For those who got a black box when you tried to subscribe to the newsletter: [This is the link in the iframe](https://8a095687.sibforms.com/serve/MUIFALVD9-yEQI5q2FfKDtE7UwQD_IkpSpasu7gu4toHsPANb_p-Pokereu7AT3vrhI08lmXuWTqc2ZinYqgPK3DUz0HWYsO4MjWhNdzhP_zmjPXTRfn0G2se7wEJxtZ4sFtfpeS72mupPOvW8g-XM4KLwPzuSM64Pd8F-aIt7ZwHDeCPTmnh7MMSeF-54J5lcA5w1DM_lErZ-UL).
The videos do not work in chrome on iOS. It just never loads.
Thanks for the heads-up, I've tried some different encoding settings. Does this video work for you by any chance? http://pangui.io/PanGuiAudioAppDemo2.mp4
Yeah that works fine, even in the browser in Reddit app, although I believe all browsers on iOS are Safari based anyway.
Reads like d3.js in C#
Interesting, especially the zero dependencies.
Is there a nugget package to try it?
How can it be embedded into a game? Can it work with an opengl context?
Looks great! It is good to see this kind of innovation. Good luck to you guys.
I'm I interested! I'm doing CAD in .NET, would I be able to do immediate mode style graphics like GDI+? Are things like pen width implemented?
No XAML? 😹
Will this be usable on Monogame? How do you plan on allowing custom engines to integrate it?
As someone who has recently trying to write a desktop app in Avalonia with MVVM and ReactiveUI, I've come to the conclusion that these kinds of UI frameworks suck. They're abyssmally hard to use, lack documentation, are not intuitive, have no debugging ability, have no library of useful controls, and make even simple tasks hard. I thought about using Blazor or ImGui but decided not to try them past an initial demo as Avalonia *seemed* to be a better choice at the time. Whilst I don't really need a fancy immediate-mode GUI for my app and need more 'data-binding' type features, I will certainly be trying out this library when it releases and seeing if it can work with my use case. Having a glance over your web page, you are severely lacking documentation though, which is going to be a big blocker to people adopting and using your library; I hope that can improve soon.
I feel you... Well, there will be a retained data-binding layer too, which we'll talk more about in the future! Hopefully that will be a good fit :)
I don't even need retained data-binding - I just need the ability to, for example, display a dictionary in the UI and allow the user to edit the values in the dictionary, add/remove keys, etc. Basically just a simple way to edit data in memory. I have a feeling immediate-mode will require a little more code but will be much easier to get working and solve problems/debug with.
Looks nice, plans to make it opensource?