openvsp UI/UX

[Joe Mumo]

Hello family I just wanted to ask if its possible with y'all permission if I could take on the project of redesigning the openvsp UI/UX and if anyone is intrested to join me, no payout just a fun project that can be done on a free weekend and patner to make the gui somewhat aesthetic for everyone and anyone

[Rob McDonald]

I'm really interested to hear your ideas about how to improve the GUI -- if you have some mockups or some examples you can point at, that would be great.

OpenVSP uses FLTK as a GUI Widget library -- FLTK handles all the windows, buttons, and sliders.  FLTK is kinda old and clunky, but it is quite flexible and can be very powerful.

If you're mostly interested in changing some of the purely aesthetic things (colors, borders, typeface, spacing, etc (dark mode anyone?)), then you can probably accomplish this relatively easily by adjusting some FLTK settings and/or applying 'themes'.  FLTK's support for things like themes is not awesome, but the FLTK team recently started working on v1.5 and improving things like themes is one of the themes of the next version.

If you're interested in changing how the UI works more fundamentally, that may also be possible.  For example, I have long considered adding a docking capability (where you can move windows around inside the main application, tabbing them, rearranging them, minimizing them, etc).  FLTK has never had a first-class docking framework.  There was an old partial attempt, but it wasn't worth getting deep into.  I am optimistic that the FLTK 1.5 dev cycle might add a docking capability that we could adopt in OpenVSP.

FLTK 1.5 will be getting improved multitouch gesture support.  So things like pinch to zoom and two-finger rotate (on the screen or a touchpad) will be a reality.  That alone probably isn't enough to make OpenVSP tablet friendly, but I think the combination of a docking framework and multitouch gestures will go a long way towards supporting things like tablets.

If you're interested in something fundamentally more expansive, then it is going to be very difficult.  I won't say it is impossible, but it would not be a small endeavour.

Most FLTK GUI's are developed in a GUI drawing program called Fluid.  You drag-n-drop, resize, and interact with a visual representation of the GUI.  This information is stored in a *.fl file and at compile time, Fluid converts that into C++ source to compile into your program.

OpenVSP doesn't actually do that.  Instead, we generate the entire GUI programmatically (i.e. with code).  We have some custom helper tools that wrap around FLTK Widgets -- they're in GuiDevice.cpp.  We handle the layout of GuiDevices with GroupLayout.cpp.  The great thing about this approach is that it improves consistency across our GUI.  You change things in one place and every place is updated.  Adding a new slider or button to a GUI is relatively straightforward (not like doing it in Fluid).  It also means that if you wanted to replace FLTK with something else, this is approximately where you would want to start.

However, I strongly recommend that you don't go down that path -- certainly not at the start.  I believe that if you can articulate what you want to improve in the GUI, then you can probably accomplish that using FLTK and the current frameworks.

You aren't the first person to observe that OpenVSP's GUI is not 'modern'.  So far, nobody who has levied that criticism has been able to articulate what they would do to improve the GUI -- other than "make it modern".

If you go to AI and ask it to "Make the OpenVSP GUI modern", I do not think it will give a helpful reply.  Instead of giving you advice of how to adjust the existing GUI to improve various aesthetic choices, it will instead recommend a bunch of fundamental software engineering technology stack choices.  It will say that OpenVSP needs to be a browser based application with remote rendering and XYZ API and all the latest 'modern' stuff.  I.e. its definition of 'Modern' is not likely to align with your definition.  Put another way, you can make an ugly GUI in a 'modern' framework just as easily as you can make an ugly GUI in FLTK.  I do not believe that FLTK is the part of the problem that needs to be solved.

I hope this helps start the conversation.  What do you have in mind?

Rob

[Rexus Gan]

Well I am currently creating a project integrates geometry modeling , analysis and simulation in just one app . It kinda looks like this. Its still not done though as I am trying to figure out how to integrate openvsp geometry modeler and VSPaero on it. From what I just researched FLTK uses opengl which is light and efficient. Meanwhile I use pyqt and pyvista as a viewer. Now this app currently lags so much and i am figuring out why probably the main culprit was my method of creating the fuselage and wing (WELL I just Vibe coded those so I have no Idea AHHAHAAAH I am still figuring out everything) That is the reason why I want to integrate openvsp.

[Brandon Litherland]

Given that you're using PyQT and PyVista, you may have some luck using the OpenVSP API and the newer Facade capabilities.  Feasibly, you could pull up the GUI as a separate process while your app runs things via the API. However, this may deviate from the desired behavior and end up being more effort than it's really worth.  Are there analyses or simulations that you're trying to integrate that aren't already in OpenVSP?

[Rexus Gan]

Well my project was mainly for improving the GUI. Particularly making it modern. Openvsp already has Great Tools (thank you for those). I actually integrated openfoam on the app since I wanted to visualize and analyze the behavior of the flow beyond stall, and also a JSBSIM export (which is still I am figuring out also). I also want to integrate geometry parameter sweeps for VSPaero other than the AoA sweep.

--
You received this message because you are subscribed to the Google Groups "OpenVSP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openvsp+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/openvsp/25965bd0-467e-43aa-9416-dc124cdd70c7n%40googlegroups.com.

[Rob McDonald]

Interesting project, I look forward to learning more about your work.

To clarify, FLTK doesn't really use OpenGL.  FLTK Widgets are generally 2D entities.  FLTK uses the operating system's native APIs to draw the widgets (buttons, sliders, etc).

FLTK will allow you to create an OpenGL context within a window.  FLTK will work with the operating system to handle moving / resizing that window -- but from FLTK's perspective, it is just a bare window.  Then, the application (OpenVSP in our case) can access that OpenGL context to do 3D rendering.  This is how OpenVSP works.

FLTK will also allow you to create 3D graphics contexts for other technologies (like Vulkan).  We have not gone down that path yet.

There may be some efforts in FLTK to either 1) draw Widgets inside an OpenGL context or 2) Use OpenGL as a drawing layer for Widgets instead of the operating system's API's.  I believe there have been experimental efforts in these directions in the past.  I am not sure if/how those will become a part of mainstream FLTK.  In any case, I don't think they are likely to be relevant.

Rob

[Rob McDonald]

When you say 'modern' here, what do you mean?  What is your goal?  What shortcomings of OpenVSP and other available tools are you trying to address?

Rob

[Rexus Gan]

From a user’s perspective, one feature that strongly contributes to a modern GUI is the availability of a dark theme. This might sound like a shallow reason, but when working across multiple applications that are already in dark mode, switching to a bright interface can be uncomfortable for the eyes especially during long work sessions.

In addition, it would be preferable if panels were integrated into the main interface rather than appearing as floating windows. Treating them as dockable panels embedded within the main window would create a more organized workspace, which as you said the FLTK has native dock widget.

[Rexus Gan]

Thank you for that information

--

You received this message because you are subscribed to the Google Groups "OpenVSP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openvsp+u...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/openvsp/c0566a83-a8f6-451a-b879-ad2a5f64d666n%40googlegroups.com.

[Rexus Gan]

I mean FLTK has no native dock widget but there may be development on it in the future

[Rob McDonald]

I don't think wanting a Dark Mode is inappropriate at all.  I also think it is within reasonable grasp -- it wouldn't be very difficult to do.

FLTK's theme support would do most of the work.

It would probably be possible to add a menu entry to select the theme -- not just light/dark, but from many themes provided by FLTK (or custom ones).

Then the OpenGL windows become the problem.  Right now, all the colors in those are hard coded, so if you change the background color (which you can already do) to something darker, some of the line colors might not show up very well.

So, each of the places one of these colors is set would need to be searched out and made configurable -- replaced with a call to return the desired color.  That call would return a different result for light / dark modes.  This is not difficult -- but there are a lot of them scattered all over the place.  So, it will take some work to track them all down and to make decisions about what colors should be used.

Fortunately, OpenVSP doesn't get complicated with color theory.  Most of our lines are pure R,G,B,C,Y,M,K -- so it shouldn't be too bad.

Here is a quick look with a dark background.  In this image, R,G,B,K are used and actually all look pretty good.

Rob