Programming Question Beautiful User Interface

[fred18]

Hi all,

while away from Orbiter coding I've been involved quite deeply in web design coding and had quite a lot of fun in setting up user interfaces with custom controls there. Now I'm back to orbiter and when I have to deal with visual studio dialogs and commands... well they are really ugly...

So I studied a lot and went also through OrbConnect by Kamaz (which is an excellent addon), finally creating my "orbiter server" which broadcasts anything I want and I can manage through webpages from browsers.

Now, I have to finish the dialog of the Space Network Plugin and then I have many other projects in mind which involves use of windows and dialogs (i.e. I want to split the MS2015 developer mode dialog from the core module), and my options are:
1) just keep using the ugly windows defaults
2) try to make it better with winapis (but this seems quite a uphill way)
3) try to learn and use somehow the Chromium Embedded Framework (but I don't know if it's feasible in Orbiter)
4) Forget the dialog, just use web pages and my orbiter server, so users will be able (and have to...) use the plugin from the browser, not within the sim...

options 2 and 3 seems quite unrealistic, so it's basically 1 against 4. If I was sure that users will use the browser without any issue I'd chose that, but I am afraid that situations like for example the true full screen mode and the fact that the focused window will keep changing between browser and orbiter will keep users away from using it... what are your ideas about this topic?

thanks in advance
Fred

 

[Face]

Now, I have to finish the dialog of the Space Network Plugin and then I have many other projects in mind which involves use of windows and dialogs (i.e. I want to split the MS2015 developer mode dialog from the core module), and my options are:
1) just keep using the ugly windows defaults
2) try to make it better with winapis (but this seems quite a uphill way)
3) try to learn and use somehow the Chromium Embedded Framework (but I don't know if it's feasible in Orbiter)
4) Forget the dialog, just use web pages and my orbiter server, so users will be able (and have to...) use the plugin from the browser, not within the sim...

Perhaps there is a fifth option: try using mixed-mode assemblies and WPF. The former ties .Net to Orbiter, the later offers "modern" GUI design. Full disclosure: I am one of those finding the new "modern" designs in UIs complete and utter bollocks (and much prefer the "old" WinForms controls), but had to build up some know-how on WPF for work (hey, they pay for it :shrug, so perhaps I can help with getting started on it.
I have experimented with .Net-integration in Orbiter in various projects (OMP, Orbiter.Net, Orbiter GalaxyNavigator), so I can say that if you keep it to standard MVC or MVVM practices, it should be no big problem.

 

[fred18]

Thank you very much, I don't know WPF at all, from what I read it's not so easy to use it with c++ but will try to give a look.

To give the idea, I managed to have a look of my controls web page similar to this quite easily:

but I see it impossible or almost impossible to implement it in a c++ win32 dialog :shifty:

Maybe it could be enough to have the window always in front and focusable as the dialogs of orbiter, but I think that would be almost impossible as well

 

[Face]

Thank you very much, I don't know WPF at all, from what I read it's not so easy to use it with c++ but will try to give a look.

And using WPF with C++ was not what I proposed. With mixed-mode assemblies, you can create your WPF forms with XAML in .NET, then put them on screen with a small wrapper. Just google "WPF GUI design examples" to see what is possible with it.

 

[fred18]

Will it be possible to interact with the sim?
The idea is to build the dialog and then use it very actively in interaction with the sim. If I design the dialog separately then how will I link the c++ code for the functioning with the UI? sorry for the silly questions but it's a totally new land for me

 

[Face]

Will it be possible to interact with the sim?
The idea is to build the dialog and then use it very actively in interaction with the sim. If I design the dialog separately then how will I link the c++ code for the functioning with the UI? sorry for the silly questions but it's a totally new land for me

Of course it will, otherwise it wouldn't make sense. OMP is an example for a mixed-mode assembly that is loaded by Orbiter, gets all the Orbiter data and API, and interacts with a managed assembly written in .Net.

In essence, you would create your views according to some MVC or MVVM approach in such a way, that no business logic is intertwined with the pure view code. These views will reside in the managed assembly. You then write a standard Orbiter plugin, but not just in pure C++, but in C++/CLR mode (it is practically just a compiler switch), which will enable you to late-bind the managed assembly. You will have to write a thin wrapper for the Orbiter-native dialog API, but this is not that big of a deal.

Of course you can also go the classic embedded webpage route, with the Orbiter module implementing some ReST-based micro-service, that is used by a webpage running in a browser embedded in the very Orbiter module that is hosting the micro-service. It might be what all the hip boyz do in the hood now, but IMHO it sounds like severe over-engineering with a -load of overhead. I give it that the micro-service would make it open for other GUIs to use, but this comes at a cost.

 

[fred18]

In essence, you would create your views according to some MVC or MVVM approach in such a way, that no business logic is intertwined with the pure view code. These views will reside in the managed assembly. You then write a standard Orbiter plugin, but not just in pure C++, but in C++/CLR mode (it is practically just a compiler switch), which will enable you to late-bind the managed assembly. You will have to write a thin wrapper for the Orbiter-native dialog API, but this is not that big of a deal.

Oh boy, this seems much beyond my capabilities... I will start to read an see if I can come up with something...

Of course you can also go the classic embedded webpage route, with the Orbiter module implementing some ReST-based micro-service, that is used by a webpage running in a browser embedded in the very Orbiter module that is hosting the micro-service. It might be what all the hip boyz do in the hood now, but IMHO it sounds like severe over-engineering with a -load of overhead. I give it that the micro-service would make it open for other GUIs to use, but this comes at a cost.

Well I don't know if this is related to what you're saying, but for my OrbiterWebServer dll I used mongoose and it works really nice, I control the sim through the browser (even from other computers) very smoothly. The difficult point about this seems to me the embedding of a small browser inside an orbiter dialog...

 

[Xyon]

Oh boy, this seems much beyond my capabilities.

That's how you know you're doing it right.

 

[Face]

Well I don't know if this is related to what you're saying, but for my OrbiterWebServer dll I used mongoose and it works really nice, I control the sim through the browser (even from other computers) very smoothly. The difficult point about this seems to me the embedding of a small browser inside an orbiter dialog...

Well, if you have everything in place, that last bit should not be a big problem. I could try my hands on creating a simple dialog with an embedded web control.