SSU Development Thread (2.0 to 3.0)

[Face]

I've now remembered this however:
http://orbiter-forum.com/showthread.php?t=33132
I'm going to have a look at how he did it, maybe you can apply it to Qt.

As mentioned by jedidia there, I've worked with him on Orbiter Galaxy to bring another rendering thread into an Orbiter window. Around that time, I also helped Mindblast with Orbiter Navigator to bring .NET windows into Orbiter full-screen. I can assure you that it works in inline client in full-screen mode. It is a bit tricky, but doable.

However, this was .NET's WinForms that simply wraps WinAPI, so all I had to do was to SetParent() window handles and trick around with message queues a little. I doubt that the same would work with Qt.

If you are interested in the .NET route, just drop me a note.

 

[SiameseCat]

You should have permission to check in code now.

I've created a separate branch (branches/SSUToolbox) for SSU toolbox development. You should check the code into that branch. That way, we can try out different things without affecting SSU development.

---------- Post added at 09:47 AM ---------- Previous post was at 09:29 AM ----------

As mentioned by jedidia there, I've worked with him on Orbiter Galaxy to bring another rendering thread into an Orbiter window. Around that time, I also helped Mindblast with Orbiter Navigator to bring .NET windows into Orbiter full-screen. I can assure you that it works in inline client in full-screen mode. It is a bit tricky, but doable.

However, this was .NET's WinForms that simply wraps WinAPI, so all I had to do was to SetParent() window handles and trick around with message queues a little. I doubt that the same would work with Qt.

If you are interested in the .NET route, just drop me a note.

I don't mind .NET, but then we'll have a hard time reusing the C++ code we already have for SSU. We might be able to use wxWidgets, since that is supposed to be a WinAPI wrapper.

 

[Goth]

I don't mind .NET, but then we'll have a hard time reusing the C++ code we already have for SSU.

What code? I only see MECOTool which has very few lines of code that I've been already able to replicate in Qt. .NET will be only used for SSUToolbox, the rest of the sources will stay as they are. Or do I miss something?
I'll leave wxWidgets as the last (third) option, since I'm not quite liking its GUI editors so far and it seems it requires a complex workflow. Everyone is free to try it before me though

 

[Face]

I don't mind .NET, but then we'll have a hard time reusing the C++ code we already have for SSU. We might be able to use wxWidgets, since that is supposed to be a WinAPI wrapper.

You can use managed C++ (aka C++/CLR) for that. In fact this is how I got .NET things running in Orbiter first place.

 

[SiameseCat]

What code? I only see MECOTool which has very few lines of code that I've been already able to replicate in Qt. .NET will be only used for SSUToolbox, the rest of the sources will stay as they are. Or do I miss something?
I'll leave wxWidgets as the last (third) option, since I'm not quite liking its GUI editors so far and it seems it requires a complex workflow. Everyone is free to try it before me though

I'm thinking of the libUltra code, which includes some orbital mechanics stuff. At the moment, this is used in the SSU GPC code, but we can also use it in both the MCC and SSU Toolbox Flight Planner.

 

[Goth]

Face helped me setup a standalone .NET app which can be called from an Orbiter dialog.
I'll try to move what I've done from Qt (which I've ruled out for different reasons) to this new setup.

Anyway, if I try to commit something with Tortoise it says

Commit failed (details follow):
POST of '/p/shuttleultra/code/!svn/me': 403 Forbidden (http://svn.code.sf.net)

of course because it didn't ask me for username and password. I don't know how to make it ask me my sourceforge credentials.
I've tried clearing authentication data but there were none.

 

[DaveS]

Face helped me setup a standalone .NET app which can be called from an Orbiter dialog.
I'll try to move what I've done from Qt (which I've ruled out for different reasons) to this new setup.

Anyway, if I try to commit something with Tortoise it says

Commit failed (details follow):
POST of '/p/shuttleultra/code/!svn/me': 403 Forbidden (http://svn.code.sf.net)

of course because it didn't ask me for username and password. I don't know how to make it ask me my sourceforge credentials.
I've tried clearing authentication data but there were none.

Perform a checkout using this URL: svn+ssh://[email protected]/p/shuttleultra/code/trunk

Replace the "daves-ssu" part with your username.

 

[Goth]

Looks like it was without the "trunk" part.

---------- Post added at 21:41 ---------- Previous post was at 21:32 ----------

Is it normal that when updating it asks for my password 4 times (I type it correctly)?

 

[DaveS]

Looks like it was without the "trunk" part.

---------- Post added at 21:41 ---------- Previous post was at 21:32 ----------

Is it normal that when updating it asks for my password 4 times (I type it correctly)?

Yes that's normal. If you want to avoid it, right-click on the folder and go TortoiseSVN>Settings. Now click on Network and paste this into field for SSH client:

C:\Program Files\TortoiseSVN\bin\TortoisePlink.exe -l daves-ssu -pw *****

Once again, replace daves-ssu with your username and ***** after -pw with your password.

 

[Goth]

Working .NET prototypes of SSUToolbox and SSU Mission Control DLL dialog uploaded in the SSUToolbox SVN branch.
Next goal could be testing Orbiter API / libUltra functions with C++/CLR to see how it goes to confirm if the .NET route is "go / no go".

---------- Post added 18-03-14 at 20:45 ---------- Previous post was 17-03-14 at 23:14 ----------

I've tried wxWidgets too (it's on SVN) but it's not just a wrapper, it runs its own "main application" and its own "application loop" just as Qt. I managed putting a wxWidgets frame into an Orbiter dialog, but doing the events (click, etc) is a problem and I guess it requires doing a separate thread.
Still, it may be the best solution of the three.

Qt:

• very easy to use
• cannot do an Orbiter dialog

.NET (C# and Windows Forms):

• even easier to use
• using OrbiterSDK / libUltra would be a pain: http://stackoverflow.com/questions/18150396/import-a-c-lib-and-h-file-into-a-c-sharp-project

wxWidgets:

• wxFormBuilder is... ugly? And it requires you to copy paste the code in your project unless I miss something; together with Code::Blocks it may work better but Code::Blocks still doesn't support its v.3 AFAIK.
• doing an Orbiter dialog is still a pain but maybe possible (still working on it).

Hmmm... I'm starting to miss WINAPI and .rc manual editing lol.
If anything, I've learnt to use three different frameworks. :lol:

 

[Face]

.NET (C# and Windows Forms):

• even easier to use
• using OrbiterSDK / libUltra would be a pain: http://stackoverflow.com/questions/18150396/import-a-c-lib-and-h-file-into-a-c-sharp-project

"Pain" is probably a bit too much. It is not as easy as simply importing a lib and including a header function, because you have to cross the border between managed and unmanaged code. But it is far from being a painful mission.

For the OrbiterSDK part, there is already much in the form of Orbiter.NET . The libUltra part is dependent on what you really need from it in the .NET application.

The libUltra project itself is compilable with /clr support into a DLL (just checked), so you can reference it from a .NET assembly and load/execute managed types inside it. Of course you'd have to implement those managed types/functions there first as wrappers to unmanaged code, but this is essentially force times distance, nothing overly complex.

Alternatively, you could use PInvoke to call functions in the DLL directly, without having to implement wrappers first. This however is limited to simple call signatures.

Using libUltra as a static *.lib is not possible with C# projects, though. So if you need almost every single class of the library separately, that would be a no-go for .NET IMHO. If you can access the functionality via at most 10 (to draw a number) wrapper calls, it is worth the effort.

 

[SiameseCat]

"Pain" is probably a bit too much. It is not as easy as simply importing a lib and including a header function, because you have to cross the border between managed and unmanaged code. But it is far from being a painful mission.

For the OrbiterSDK part, there is already much in the form of Orbiter.NET . The libUltra part is dependent on what you really need from it in the .NET application.

The libUltra project itself is compilable with /clr support into a DLL (just checked), so you can reference it from a .NET assembly and load/execute managed types inside it. Of course you'd have to implement those managed types/functions there first as wrappers to unmanaged code, but this is essentially force times distance, nothing overly complex.

Alternatively, you could use PInvoke to call functions in the DLL directly, without having to implement wrappers first. This however is limited to simple call signatures.

Using libUltra as a static *.lib is not possible with C# projects, though. So if you need almost every single class of the library separately, that would be a no-go for .NET IMHO. If you can access the functionality via at most 10 (to draw a number) wrapper calls, it is worth the effort.

We'll probably be using a couple of classes from libUltra, so we'll have to create .NET wrapper classes. Which is annoying, but doable.

Unless there are strong objections, my inclination is to go with Qt and require users to select 'Full Screen Window' mode.

 

[Goth]

It's not only about the fullscreen, Qt isn't working fine together with Orbiter. It doesn't update its window. It could only be used for SSUToolbox but not for a Mission Control plugin. Unless someone magically answer me here:
http://qt-project.org/forums/viewthread/39690/
or is able to have a look at my code in SVN and solve the issue.

---------- Post added at 23:48 ---------- Previous post was at 23:33 ----------

Actually I didn't even uploaded the Qt's Mission Control test because indeed it didn't work; I'll upload it soon.

---------- Post added 19-03-14 at 00:05 ---------- Previous post was 18-03-14 at 23:48 ----------

Done.

 

[SiameseCat]

It's not only about the fullscreen, Qt isn't working fine together with Orbiter. It doesn't update its window. It could only be used for SSUToolbox but not for a Mission Control plugin. Unless someone magically answer me here:
http://qt-project.org/forums/viewthread/39690/
or is able to have a look at my code in SVN and solve the issue.

---------- Post added at 23:48 ---------- Previous post was at 23:33 ----------

Actually I didn't even uploaded the Qt's Mission Control test because indeed it didn't work; I'll upload it soon.

---------- Post added 19-03-14 at 00:05 ---------- Previous post was 18-03-14 at 23:48 ----------

Done.

The Mission Control can run as a separate executable, instead of as a dialog box within Orbiter. This will probably be easier for most cases, since a MCC dialog box will take up screen space within Orbiter and could be really annoying.

 

[DaveS]

The Mission Control can run as a separate executable, instead of as a dialog box within Orbiter. This will probably be easier for most cases, since a MCC dialog box will take up screen space within Orbiter and could be really annoying.

Yes. And what is the difference in appearance between a dialog and a stand-alone executable? The important objective here is something that can communicate 2-way with Orbiter. Right now the only use for MCC is FDO, for trajectory calculations.

 

[Face]

We'll probably be using a couple of classes from libUltra, so we'll have to create .NET wrapper classes. Which is annoying, but doable.

Unless there are strong objections, my inclination is to go with Qt and require users to select 'Full Screen Window' mode.

You can also go a different route: do the heavy lifting in the native MissionControl plugin, but do the visuals in the .NET dialog. This way, you'd enforce a kind of MVC concept. I.e.: for all the things needing 2-way Orbiter contact, do the view part in the .NET and propagate value changes to the native model and controller part, where it can take full use of libUltra and OrbiterAPI. The things NOT needing 2-way connection, the model and control parts could reside in the .NET application, if only to have a valuable stand-alone functionality.

What I can see from Goth's example - and speaking from experience from OMP project - .NET interaction in Orbiter is pretty smooth. IMHO, it is "MFC Done Right(TM)". A platform choice excluding functionality of the core system right from start leaves a bitter taste OTOH.

Just my :2cents:, of course.

 

[Goth]

The Mission Control can run as a separate executable, instead of as a dialog box within Orbiter.

In that case you can't use OrbiterAPI so you would need some way to connect to Orbiter, and there is no good way compared to direct C++ Orbiter API calls.

Right now the only use for MCC is FDO, for trajectory calculations.

If that's the case, we could do as Face is suggesting in the last post. That would be perfect for MCC; still, since SSUToolbox is 100% .NET there would stille be the "libUltra code problem" for SSUToolbox. Unless you go the same route with SSUToolbox too, having e.g. a .NET window where you click a button which calls C++ code...

BTW I've not yet completed the testing with wxWidgets, so I can't exclude that option either. However, taking into account how both Qt and wxWidgets work (requiring another thread to work inside Orbiter and communicating with the main thread), maybe the .NET approach still makes more sense. I just need (yet more ) help from Face to set up at least one example of this kind of communication and then I'll be ready to go on by myself.

 

[SiameseCat]

In that case you can't use OrbiterAPI so you would need some way to connect to Orbiter, and there is no good way compared to direct C++ Orbiter API calls.

I don't think we need direct communication between MCC and Orbiter. What I was thinking is that the SSU dll will send data (state vectors, etc.) directly to MCC, and MCC could potentially send commands back to SSU.

 

[Goth]

SSU dll doesn't send anything by its own since it is loaded by (or into) Orbiter; so if it needs to send something it has to do it through Orbiter, correct me if I'm wrong; the only way to send information to another program bypassing Orbiter is using some kind of protocol e.g. HTTP messages.
An external program (SSUToolbox) has no way to talk with that DLL apart from loading it, but it can't load it because it is loaded into Orbiter. And if it isn't, well, it has no clue about the ongoing simulation.

 

[Face]

Hm. Sounds like this is more about something like Orb:Connect, not about getting some neat GUI to work in Orbiter.

OrbiterNavigator also used sockets to do the Orbiter link, BTW.