Author Topic: GUI framework for cross-platform FRED  (Read 4202 times)

0 Members and 1 Guest are viewing this topic.

Offline m!m

  • 211
GUI framework for cross-platform FRED
After some discussion with z64555 on Discord we are not sure anymore if wxWidgets is the right solution for the cross platform version of FRED. In particular, I had very bad experience with its Linux support which has either a lot of bugs or requires a lot of special attention, both alternatives are obviously not a good property of a framework for cross-platform GUI development.

I proposed the switch to Qt which is pretty much the standard for cross-platform GUIs these days. It should have much better support for Linux platforms and is all around better integrated with various tools.

Are there any objections to this? I want to help with getting a FRED alternative running but IMHO wxWidgets it not the right solution for that problem.

 

Offline chief1983

  • Still lacks a custom title
  • Moderator
  • 212
  • ⬇️⬆️⬅️⬅️🅰➡️⬇️
    • Minecraft
    • Skype
    • Steam
    • Twitter
    • Fate of the Galaxy
Re: GUI framework for cross-platform FRED
How much of what has been done so far is scrapped?  Not suggesting that should prevent us from making the right decision, just wondering if it's actually not as bad a blow as it sounds.

Qt sounds good to me, it is also the toolkit used for Knossos now, via PyQt5.

PCS2 is still using wxWidgets though.  So we'll still need some wx expertise in the community for the foreseeable future.
Fate of the Galaxy - Now Hiring!  Apply within | Diaspora | SCP Home | Collada Importer for PCS2
Karajorma's 'How to report bugs' | Mantis
#freespace | #scp-swc | #diaspora | #SCP | #hard-light on EsperNet

"You may not sell or otherwise commercially exploit the source or things you created based on the source." -- Excerpt from FSO license, for reference

Nuclear1:  Jesus Christ zack you're a little too hamyurger for HLP right now...
iamzack:  i dont have hamynerge i just want ptatoc hips D:
redsniper:  Platonic hips?!
iamzack:  lays

 

Offline z64555

  • 210
  • Self-proclaimed controls expert
    • Minecraft
    • Steam
Re: GUI framework for cross-platform FRED
The form layout will have to be redone in Qt's format, since there's no known method of importing wxWidgets XRC's into a Qt editor.

On the coding side of things, the bulk of the .cpp files in the wxfred2 directory is barebones that should be salvagable with a regex replacement of terms. There was an idea that the GUI API could be abstracted (like what FSO does with OpenGL).
Secure the Source, Contain the Code, Protect the Project
chief1983

------------
funtapaz: Hunchon University biologists prove mankind is evolving to new, higher form of life, known as Homopithecus Juche.
z64555: s/J/Do
BotenAlfred: <funtapaz> Hunchon University biologists prove mankind is evolving to new, higher form of life, known as Homopithecus Douche.

 

Offline jg18

  • A very happy zod
  • 210
  • can do more than spellcheck
Re: GUI framework for cross-platform FRED
Switching to Qt for cross-platform FRED (QFRED?) gets a :yes: from me.

Is there any advantage to writing the front end using HTML/CSS/JS like Knossos does? Or would it be better to use Qt Designer?

 

Offline ngld

  • Administrator
  • 29
  • Knossos dev
Re: GUI framework for cross-platform FRED
I think it'd be better to use Qt Designer because it's easier and faster than coding the UI using HTML/CSS/JS. I've used HTML for Knossos' UI because it gives me more control over how the widgets (buttons, input fields, ...) look.

 

Offline chief1983

  • Still lacks a custom title
  • Moderator
  • 212
  • ⬇️⬆️⬅️⬅️🅰➡️⬇️
    • Minecraft
    • Skype
    • Steam
    • Twitter
    • Fate of the Galaxy
Re: GUI framework for cross-platform FRED
Yeah, I think CutieFred would benefit more from sticking with the native interface look compared to what Knossos was going for.
Fate of the Galaxy - Now Hiring!  Apply within | Diaspora | SCP Home | Collada Importer for PCS2
Karajorma's 'How to report bugs' | Mantis
#freespace | #scp-swc | #diaspora | #SCP | #hard-light on EsperNet

"You may not sell or otherwise commercially exploit the source or things you created based on the source." -- Excerpt from FSO license, for reference

Nuclear1:  Jesus Christ zack you're a little too hamyurger for HLP right now...
iamzack:  i dont have hamynerge i just want ptatoc hips D:
redsniper:  Platonic hips?!
iamzack:  lays

 

Offline The E

  • He's Ebeneezer Goode
  • Moderator
  • 213
  • Nothing personal, just tech support.
    • Steam
    • Twitter
Re: GUI framework for cross-platform FRED
I would agree. Changing the UI radically would invalidate all the nice little guides we have, and more importantly, it wouzld make all the experience people have worthless.
If I'm just aching this can't go on
I came from chasing dreams to feel alone
There must be changes, miss to feel strong
I really need lifе to touch me
--Evergrey, Where August Mourns

 

Offline Mongoose

  • Rikki-Tikki-Tavi
  • Global Moderator
  • 212
  • This brain for rent.
    • Minecraft
    • Steam
    • Something
Re: GUI framework for cross-platform FRED
Yeah, probably best to avoid pulling a Microsoft.

 

Offline m!m

  • 211
Re: GUI framework for cross-platform FRED
Since this thread exist we might as well use it to discuss some design decisions for the development of qtFRED.

Currently the small amount of code that exists is clearly divided into the mission editing and GUI related code and I would like to keep it that way, partly because it will make adding support for multiple viewports easier down the line.

However, Qt has some very nice features that could also be used in the mission editing code for making the code cleaner and easier to work with. Specifically, I would like to use the signal/slot system for managing event handling without introducing any hard dependencies. Since that system is designed for Qt it would require the usage of Qt classes and functions in the mission editing code. Do we want to avoid such a thing or would it be acceptable to use it for that? It would not use any GUI related functionality to keep the existing modular design intact but it would really help a lot in the future.

Also, in case you didn't see it, I created a qtfred2 branch in the repository and opened a PR with the initial source code for it: https://github.com/scp-fs2open/fs2open.github.com/pull/1356
Once CI is working properly again it could be merged and we would have a central place for developing qtFRED.

 

Offline AdmiralRalwood

  • 211
  • The Cthulhu programmer himself!
    • Skype
    • Steam
    • Twitter
Re: GUI framework for cross-platform FRED
It seems silly to me that a future alternate GUI would need to use Qt even if it had nothing to do with Qt.
Ph'nglui mglw'nafh Codethulhu GitHub wgah'nagl fhtagn.

schrödinbug (noun) - a bug that manifests itself in running software after a programmer notices that the code should never have worked in the first place.

When you gaze long into BMPMAN, BMPMAN also gazes into you.

"I am one of the best FREDders on Earth" -General Battuta

<Aesaar> literary criticism is vladimir putin

<MageKing17> "There's probably a reason the code is the way it is" is a very dangerous line of thought. :P
<MageKing17> Because the "reason" often turns out to be "nobody noticed it was wrong".
(the very next day)
<MageKing17> this ****ing code did it to me again
<MageKing17> "That doesn't really make sense to me, but I'll assume it was being done for a reason."
<MageKing17> **** ME
<MageKing17> THE REASON IS PEOPLE ARE STUPID
<MageKing17> ESPECIALLY ME

<MageKing17> God damn, I do not understand how this is breaking.
<MageKing17> Everything points to "this should work fine", and yet it's clearly not working.
<MjnMixael> 2 hours later... "God damn, how did this ever work at all?!"
(...)
<MageKing17> so
<MageKing17> more than two hours
<MageKing17> but once again we have reached the inevitable conclusion
<MageKing17> How did this code ever work in the first place!?

<@The_E> Welcome to OpenGL, where standards compliance is optional, and error reporting inconsistent

<MageKing17> It was all working perfectly until I actually tried it on an actual mission.

<IronWorks> I am useful for FSO stuff again. This is a red-letter day!
* z64555 erases "Thursday" and rewrites it in red ink

<MageKing17> TIL the entire homing code is held up by shoestrings and duct tape, basically.

 

Offline m!m

  • 211
Re: GUI framework for cross-platform FRED
If we do not want to use the event functionality provided by Qt then we will need to implement that ourself which seems like a big waste of time if we already have a system available that works perfectly well. A port to another GUI system is not a concern if we aren't even remotely done with the current port.

 

Offline z64555

  • 210
  • Self-proclaimed controls expert
    • Minecraft
    • Steam
Re: GUI framework for cross-platform FRED
I'd like to look over Qt's signaling/event handling system to see how much of a difference it is to WxWidgets.

I'd also like to try to keep as much API-specific features out of the mission editing code as we can, and in places that we must use them they should be abstracted (like what was done with OpenGL) so that the code can be used with a different UI lib.
Secure the Source, Contain the Code, Protect the Project
chief1983

------------
funtapaz: Hunchon University biologists prove mankind is evolving to new, higher form of life, known as Homopithecus Juche.
z64555: s/J/Do
BotenAlfred: <funtapaz> Hunchon University biologists prove mankind is evolving to new, higher form of life, known as Homopithecus Douche.

 

Offline m!m

  • 211
Re: GUI framework for cross-platform FRED
The signal-slot mechanism is completely separate from the GUI event handling. It's a separate feature that does not require pulling in any of the GUI related Qt code.

I will search for an alternate signal-slot library but I don't see the point in restricting use of that feature.

 

Offline z64555

  • 210
  • Self-proclaimed controls expert
    • Minecraft
    • Steam
Re: GUI framework for cross-platform FRED
We might not even need it, How where you intending to use the signal/slot mechanism in the editor code?
Secure the Source, Contain the Code, Protect the Project
chief1983

------------
funtapaz: Hunchon University biologists prove mankind is evolving to new, higher form of life, known as Homopithecus Juche.
z64555: s/J/Do
BotenAlfred: <funtapaz> Hunchon University biologists prove mankind is evolving to new, higher form of life, known as Homopithecus Douche.

 

Offline m!m

  • 211
Re: GUI framework for cross-platform FRED
I generally want to use it as a scalable and decoupled way of notifying the GUI code of changes from inside the editor without having to add a pointer to the main window to the editor (which would be an even worse breach of Editor/GUI separation).

I have implemented a small example of how that could be used by implementing a dynamically changing window title. When a mission is loaded the editor invokes its missionLoaded slot with the correct filename and the MainWindow receives this notification and changes the window title accordingly. As you can see, this is a very clean way of achieving a dynamic GUI without introducing any hard dependencies between the GUI and the editor objects.

 

Offline z64555

  • 210
  • Self-proclaimed controls expert
    • Minecraft
    • Steam
Re: GUI framework for cross-platform FRED
Hm, ok, I see.

I still recommend getting the event system abstracted whenever feasible, however.
Secure the Source, Contain the Code, Protect the Project
chief1983

------------
funtapaz: Hunchon University biologists prove mankind is evolving to new, higher form of life, known as Homopithecus Juche.
z64555: s/J/Do
BotenAlfred: <funtapaz> Hunchon University biologists prove mankind is evolving to new, higher form of life, known as Homopithecus Douche.

 

Offline m!m

  • 211
Re: GUI framework for cross-platform FRED
Well, the signal/slot mechanism is exactly what abstracts the event system away...

I'll go ahead and use the signal/slot implementation provided by Qt but I'll try to keep as much of the Qt related code behind some sort of abstraction layer. The signal/slot library should be easy to replace in case we migrate to another GUI framework.

 

Offline Tomo

  • 28
Re: GUI framework for cross-platform FRED
Generically, Signals/Slots are a thread-safe event and parameter marshalling system that can be connected and disconnected at runtime.

For reference, boost has an alternate signal/slot system. I've not used that one but I'm told it's similar to Qt's.

This is a different approach to the MFC and (I believe) wxWidgets approach of directly calling methods in the other objects, removing the need for both ends to know about the existence of the other.
Makes it a lot simpler to swap out or update the GUI.

In the case of Qt, the signals and slots make up part of Qt's "property" system, which allows some rather fun swapouts of GUI - eg web-based - .

Signals/Slots are slightly slower than direct function calls, but not much - and slots are functions that can be directly called anyway when there is a need for speed.

I would say that there is no need to make an abstraction layer of your own, as Qt's implementation is based on a few macros and the moc that could be swapped out later if required - the most important being the QObject::connect() methods.

I would however definitely suggest using the Q_SLOT and Q_SIGNAL macros instead of slots: and signals: markers, as this would make it a lot easier to transition if need be.

 

Offline WMCoolmon

  • Purveyor of space crack
  • 213
Re: GUI framework for cross-platform FRED
Hi,

I'm between jobs atm and happened to start reading HLP again.

I've worked a lot with Qt now and have a much higher opinion of it than wxwidgets. There's a language for Qt called QML that's pretty nifty to create interfaces in.

That being said, Unity 3D seems to have become the de facto standard for game development. If there's going to be a substantial rework of Freespace or FRED, I'd suggest looking into integrating with Unity's editor somehow - maybe a plugin to allow it to create missions for Freespace. Last I knew (and my knowledge is admittedly about seven years out of date) FRED only required the ability to render a subset of the total things the engine needs to - stationary ships, jump nodes, that sort of thing. But no weapons or particles, and nothing has to move, and nothing has to run the AI code in realtime. AFAIK the C# runtime can call C libraries (eg code.lib) through an FFI. It does look like extending the editor UI is possible too.

I think this is more future-proof than Qt. At least in the bay area, there seem to be way more web UI jobs than Qt UI jobs, and a lot of the discussion about AR/MR/VR tends to involve Unity 3D in some way. The places that are using Qt tend to be embedded-device companies - car manufacturers and such.

This would also get the foot in the door to port more of FS to Unity. But that's definitely another thread. :p
-C

 

Offline m!m

  • 211
Re: GUI framework for cross-platform FRED
The problem I see with Unity is that it is a complete game engine instead of just a UI library. For the purposes of a mission editor with a separate rendering engine it is just too much. Also, is it possible to create custom editor windows from C++ or does that have to be done in C#? The page you linked to only talks about C# so I'm not sure how easy it would be to port the FRED code to use the Unity editor. Should we ever do a complete engine rewrite (which probably will never happen anyway), Unity would be a very valid option but UnrealEngine may be a better solution here since it supports C++ directly.

Another issue I see with Unity is its Linux support. I haven't followed that situation closely but the last thing I heard was that there was an outdated beta for a Linux editor but not much else. Since cross-platform support is one of the main reasons for porting FRED to another UI library that pretty much rules out Unity (if my information about the Linux support is correct).

One of the great things about Qt is that it's similar enough to the old FRED code that most of the code can be ported without any major issues. Unity would make that pretty much impossible which would increase the amount of work required for porting the code immensely.