Reorganization of CelestiaCore interface and further internal changes

The place to discuss creating, porting and modifying Celestia's source code.
Topic author
pirogronian
Developer
Posts: 132
Joined: 05.01.2018
With us: 1 year 6 months
Location: Wrocław

Reorganization of CelestiaCore interface and further internal changes

Post #1by pirogronian » 01.05.2018, 17:51

Hi all (but especially developers (among them especially @Alexell, when he eventually will be back))

After short code lookup, I decided to change the way CelestiaCore is communicating with UI interfaces. Now it's done by simulating input events (for example, below is part of current Qt main window code):

Code: Select all

void CelestiaAppWindow::selectSun()
{
    m_appCore->charEntered("h");
}


void CelestiaAppWindow::centerSelection()
{
    m_appCore->charEntered("c");
}


void CelestiaAppWindow::gotoSelection()
{
    m_appCore->charEntered("g");
}


Main communication is done in CelestiaCore in one big switch (which is, by the way, very helpful in understand, how this communitation work). I found such a sollution as horrible design, so I started new branch, in which I begun to replace input event simulation by calls code corresponding to proper switch' entry, but encapsulated in new function. For example, cited above code is now as follows:

Code: Select all

void CelestiaAppWindow::selectSun()
{
    //m_appCore->charEntered("h");
    m_appCore->selectStar(0);
}


void CelestiaAppWindow::centerSelection()
{
    //m_appCore->charEntered("c");
    m_appCore->centerSelection();
}


void CelestiaAppWindow::gotoSelection()
{
    //m_appCore->charEntered("g");
    m_appCore->gotoSelection(0.5);
}


But I'm not sure, if such this will be proper way to go and will be accepted and merged with main branch. So I have a question to anybody interested in (especially Alexell, as main programmer): what do You think about current CelestiaCore communication "language"? Should it be maintained for some reasons, or should be mark as obsolete and eventually completely removed? I understand, that such a solution was done to keep input schema consistent independently of used UI. However, this is IMHO bad presumption, because input schema is what UI is about. Current solution will lost all sence when one try to add custom shortcuts, for example.

OK, in short: I propose to move away all input handling from CelestiaCore and move it to adequate UIs, because it's UI's job to handle user input after all.

Janus
Posts: 390
Joined: 13.08.2016
With us: 2 years 11 months

Post #2by Janus » 02.05.2018, 21:02

Speaking strictly for myself here.

I actually like the way it handles things.
I will freely state that it needs cleanup though.
Much of the code has outgrown the scale it was written for, and needs refactoring.

There also needs to be a way change key combinations via cfg for instance.
However, one of the big things I like about Celestia is that has multiple GUI styles that manage to work consistently.

At this time, to alter a behavior, all you need alter is celestiacore, which then passes the message on.
By keeping the key or code passing, then any customization on the end user's system can preserved.
If you call things directly, then custom fonts, or read alouds, or other alternative access methodology may also be bypassed.

I just really like the GUI agnostic way the core works.
Of course, I may be alone in this, who knows.
I also don't like changing things just to change them.

On the other hand, I admit that there may be reasons for it that are beyond my current skill levels.
As I have stated, I am not a real C/C++ programmer.

Alexell's desire to merge QT into the core of Celestia is large part of my decision to fork my code from his.
I personally dislike QT because of its support requirements, but even if I liked it, merging it into celstia directly would be a mistake in my opinion.
Irregardless of why why Celestia was designed with a core, and then differing GUIs, it is a decision I like.
If emulating keystrokes keeps the behavior identical on all platforms, then I say keep it until that behavior can be duplicated in another universal way.

Speaking just for me.


Janus.

Topic author
pirogronian
Developer
Posts: 132
Joined: 05.01.2018
With us: 1 year 6 months
Location: Wrocław

Post #3by pirogronian » 03.05.2018, 11:41

Hi Janus

Mhm, I think there is some right in Your opinion. I also want to make CelestiaCore as something like general library to use by different UIs or projects. So, I decided to make it also input-handling agnostic, however I'm now unsure about it. There is a fine search-by-name mechanism inside CelestiaCore, based on keyboard input. This mechanism would be hard to move into external UI. Moreover, there could be someone need to use CelestiaCore with very minimal UI, without custom keyboard handling. I'm thinking about complection of CelestiaCore API to make it as conveniet for developers as possible, with optional, fallback input handling based on this API.

So, I also think that merging Celestia internal with Qt could be bad idea. It could be convenient for Qt branch developers, however it's probably too big and unnecessary effort.

Janus
Posts: 390
Joined: 13.08.2016
With us: 2 years 11 months

Post #4by Janus » 03.05.2018, 15:09

@pirogronian

An example here.
The analogy is loose, but I view it a lot like this.

I see CelestiaCore and the GUI as being like OpenGl & a Game Engine.

The core keeps inventory without worrying about anything else.
The GUI asks where something is so it can display it.

This also decouples data manipulation from display very nicely.
Which makes way for multiple threads to manage data requests.
With other threads to handle display.

How about dynamic threads on multicore CPUs.
With the recent 97M stars, give it four threads on your quad core working in parallel.
After all, OpenGl doesn't care what order you give it stuff in.

That and my Kinect overlay also uses keyboard/mouse event injection, which worked just like I was at the keyboard.
Integrating new controllers like the kinect or motion sensing systems is a pain in traditional game engines.

There are also multiple projects trying to use the xboxone kinect, which is higher resolution, to read sign language.
Imagine being able to look up a star with sign language, lower case at waist height, upper case at your shoulders for instance, if case sensitivity is needed.
Then we get into voice recognition, think about two people speaking differing languages, calling up the same star, now they have a connection.

To me, keeping them separated keeps celestia future proof.
I know for instance that I am working on a wxwidgets version of it.
I have heard of a fox toolkit version in the works as well.
I even saw a demo several years ago with the GUI done in GLUT/GLUI by someone just because they could.
The latter wasn't feature complete, but it makes an interesting point.

You give CelestiaCore a date, and it gives you coordinates of everything.
Sounds like a temporal database to me.

I've wondered for some time if 'Celest' in Vernor Vinge's 'The peace war' is related to Celestia, anyone know?

Sorry if I am rambling, waiting on customer to deliver the actual unit that is not communicating, instead of the identical one off the shelf they brought first.


Janus.

Topic author
pirogronian
Developer
Posts: 132
Joined: 05.01.2018
With us: 1 year 6 months
Location: Wrocław

Post #5by pirogronian » 22.05.2018, 15:44

@Janus

Can You take a look on my recently accepted pull request in official Celestia github repository? I introduced subclass of CelestiaCore, called CelestiaCoreApplication, which I designed to have more elegant and flexible API to use by various programmers in various projects, than its legacy superclass. I wonder, what do You think about it? Despite official proclamations of making Celestia Qt-centric, I try to separate core and Qt as long as possible.

Janus
Posts: 390
Joined: 13.08.2016
With us: 2 years 11 months

Post #6by Janus » 22.05.2018, 17:32

@pirogronian

I have been looking at it.
I like the way it looks, and have also merged most of it it into my fork.
CelestiaCoreApplication:yes, the direct calls to stuff, not yet.

If you want to see what mine looks like right now.
download/file.php?id=2284&filename=Celestia_180520.zip
The archive has x86 & x64 both, static linked, no VC runtimes needed.
Files demarked to show they are my fork, not main line.

From what I can see you are trying to provide an agnostic way to call the database/render engine without breaking backward compatibility.
That is the proper way to refactor the code in my own opinion.
Provide an alternate that can mature to replace the old, without dropping the old which still works.
I am also happy not to see QT stuff creeping into the core, it appears to be staying in the QT section where it belongs.

I have to be careful since I am using VS2013/15 & QT Creator.
VS2017 breaks my current desktop setup. {W7 Pro x64 made as XP like as I can.}
I also do not like it, I have it in a VM, and it is so dark.
That is something I hate beyond words, the way so much stuff has dark backgrounds now, yech.
I have to have my monitor brightness set for weapons research to see everything.
I normally keep my brightness set for 50%, or less

As I have mentioned before, I am working on a WxWidgets UI version of celestia.
More than likely, I will be using the new core for calling internal functions if it covers everything I need.
My progress is slow, I am still learning wxwidgets itself.
My goal is to make a multiplatform completely statically linked standalone version, where all platforms use the same data.
Since wxwidgets supports IPC, I am hoping to be able to use that for passing text tokens to control it.

This will take time, but I am patient.
I am also close to being able to compile using QT creator and mingw.
After that will come using just mingw, leaving VS out of it.

Right now though, the most visible changes in my fork are I moved the OBS dist display, and I display RaDec for most everything.
I also added loading sorting.
So stuff in extras is loaded alphabetically, files first, then sub directories.
No more random load order.

Once I get some clean up done, I will be posting my current code.
Along with it will be VS2013 static linked versions, along with QT 5.6/8/10 bundles ready to run, all in x86 & x64 both.
Anyone who looks at my code should be fore warned, I am not an elegant C/C++ programmer, I can barely program in them at all.
So be prepared for messy code that just works, there are no elegant solutions.


Janus.

Topic author
pirogronian
Developer
Posts: 132
Joined: 05.01.2018
With us: 1 year 6 months
Location: Wrocław

Post #7by pirogronian » 22.05.2018, 18:40

@Janus

Can You provide source code? I use Linux and Your executables didn't run, even with Wine (BTW, as I use Linux, I don't even see Visual Studio...).

Janus
Posts: 390
Joined: 13.08.2016
With us: 2 years 11 months

Post #8by Janus » 22.05.2018, 22:38

@pirogronian

Okay, here is a stripped down version.
Warning, not well cleaned up yet.
It includes all the files I have altered.
I trimmed out the precompiled stuff since you are on linux.
But the sources are all present.

I have been trying to get wine going in ubuntu with lxde, and so far, no luck.
I can't use most of the desktops out there because of no pattern to where things are put.
Same reason I barely made the jump to W7, it's default desktop is useless to me.
I use patterns and logic exclusively, and if I can not find the pattern, then it is useless to me.
And W7's UI is structured about as logically as you would get if you used a party popper for UI design.
Same exact problem I have with gnome, and most of the rest with Linux.
I do not see W8 as windows, and W10 is simply a cloud account terminal with graphics.
Even lxde is horrid, but it fails less spectacularly than the rest.

If anything is unclear, please feel free to ask and I will try to explain my logic.


Janus.

Added after 1 hour 27 minutes:
@pirogronian

Took me about two hours, and I now have my VS x86 code running on lubuntu & wine inside a VBox VM.
Performance is slow, but it runs just fine.
I hope knowing it can work helps.


Janus.
Attachments
Simlestia_Messy_180522.7z
(31.36 MiB) Downloaded 22 times


Return to “Development”

Who is online

Users browsing this forum: 4 guests