Celestia UI redesign

[Guckytos]

Hmmm,

I am probably reigning you enthusiastic guys on the parade, but I hope I don't disturb the development process too much.

But: Is there still development on the 1.5.0 pre6/final? Can it be expected sometime this spring? Or summer?

Because to me it looks like a lot of you guys are now off and exploring already the future enhencements of Celestia.

Just my impression of things.

Regards,

Guckytos

BTW: I really like the new look.

[chris]

Hmmm,

I am probably reigning you enthusiastic guys on the parade, but I hope I don't disturb the development process too much.

But: Is there still development on the 1.5.0 pre6/final? Can it be expected sometime this spring? Or summer?

Because to me it looks like a lot of you guys are now off and exploring already the future enhencements of Celestia.

Just my impression of things.

Regards,

Guckytos

BTW: I really like the new look.

Celestia 1.5.0 will be ready much sooner than this spring, and will look very much like 1.5.0pre5. Rest assured that work on 1.5.0 is continuing despite the UI diversions. At this point we're at the unglamorous and mostly unnewsworthy stage of fixing minor bugs. I'd like to keep this thread on topic though, so please resume your UI suggestions, criticisms, and rants.

--Chris

[cartrite]

After reading some of the comments about the time toolbar at sourceforge, maybe this toolbar should not only be used for time. There is plenty of room for some add ons like some less used keyboard features. Like "cntl w", fps, ect. Also more descriptive icons would help.

EDIT: Another approach could be a tool bar preference box listing all keyboard functions with activation check boxs so the user can customize the toolbar.

A nice tool "box" to create would be a spacecraft control tool with solid arrows in a diamond pattern for directional control. And the other controls, gas pedal, brake pedal, stop pedal, pitch and yaw pedals etc. And a speedometer, altimeter, etc.
cartrite

[dirkpitt]

A nice tool "box" to create would be a spacecraft control tool with solid arrows in a diamond pattern for directional control. And the other controls, gas pedal, brake pedal, stop pedal, pitch and yaw pedals etc. And a speedometer, altimeter, etc.

Perhaps some of these might be best left up to a user-created addon? (e.g., Lua edu tools)

[cartrite]

Chris,
FYI. I just built a new cvs and I can see the start time for spacecraft but not an end time. Not sure if this is intended.
Ignore the above. I was looking at Hubble. When I select Skylab, I can see an end time.
cartrite

[chris]

Regarding the time toolbar . . . I organized it like Vincent's time controller from the EDU tools.

I just tested it, and I have to say that I like it !
I agree that it could look prettier with these nice icons that Christophe (ElChristou) knows how to make...

Chris, what about rearranging the marker group as I suggested above ?

This looks like a decent arrangement. It's slightly nicer to have all the marker style options (which is how I think of the label checkbox) on a single line, but your layout makes the most of available space. I think we might be able to use stacked widgets for different tool panels, so it's possible that we may not have to economize quite so much. As for what the tools might be besides markers, I'm not sure. Perhaps an orbit plotting tool for solar system objects?

--Chris

[Vincent]

It's slightly nicer to have all the marker style options (which is how I think of the label checkbox) on a single line, but your layout makes the most of available space.

Chris,

I tried what you've suggested and it looks good to me:



It also offers more room for the "Mark Selected' and 'Clear Markers' buttons whose translation may be a longer string than in the english version, e.g., "Marquer la S?©lection" and "Effacer les Marqueurs" in French.

[Guckytos]

It's slightly nicer to have all the marker style options (which is how I think of the label checkbox) on a single line, but your layout makes the most of available space.

Chris,

I tried what you've suggested and it looks good to me:



It also offers more room for the "Mark Selected' and 'Clear Markers' buttons whose translation may be a longer string than in the english version, e.g., "Marquer la S?©lection" and "Effacer les Marqueurs" in French.

Looks good,

but I think the colour box could still be made smaller. Looks a bit too long and you would have more space to place the other options.

Regards,

Guckytos

[Guckytos]

And it's me again

This time I have some ideas about the UI for the Celestia HELP section.
I hopefully asume correctly that with the new UI it will be possible to display the same texts on different platforms.

1. So why not revamp the Help section and putting some of the basic stuff, that is often asked by beginners in there?
That means like some explanations on how to install an addon, what are the different file-extensions for, where to find what, how to use the script browser and definitly explaining that there is a configuration file in which a lot of things can be done. (If a full explanation of this file would be included, even better.)

2. Reorganise the descriptions for the keyboard shortcuts. By placing them in tabs that are organised according to functions. Then having tabs like:

Navigation
Time
Markers
View Options
...

Another point would probably be, to really look hard at the actual keyboard shortcuts and perhaps come up with a new one. If the new one is better in a logical style or grouping keys. One example would be that since the demo script will be gone soon to make navigation like this:

a: accelerate
s: stop
d: decelerate

Just my 2 cents.

Regards,

Guckytos

[ElChristou]

After some fix from DW to build on osX, I could test a yesterday Qt build. Lots of stuff have been implemented and functionalities seems to be very interesting but I have to say that from a design point of view the whole stuff is quite unpleasant.
As I understand you guys are now playing with Qt possibilities I won't point out what seems me wrong because I feel it's not the moment (would be a lost of time and I don't have it for the moment). I just want to point out that once you have played enough with Qt a deeper thinking on the design of Celestia wil be necessary again to achieve an UI that could match the level of the engine.

[t00fri]

...
Lots of stuff have been implemented and functionalities seems to be very interesting but I have to say that from a design point of view the whole stuff is quite unpleasant.
As I understand you guys are now playing with Qt possibilities I won't point out what seems me wrong because I feel it's not the moment (would be a lost of time and I don't have it for the moment). I just want to point out that once you have played enough with Qt a deeper thinking on the design of Celestia wil be necessary again to achieve an UI that could match the level of the engine.

See my repeated earlier statements about precisely the same point! But I shut up.

F.

[ElChristou]

See my repeated earlier statements about precisely the same point! But I shut up.

I suppose it's a bit normal to play a bit with a new toy...
Let's wait a moment till this phase is over. I see no reason to kill a wonderfull engine with a wonky/non neat UI...

[chris]

...
Lots of stuff have been implemented and functionalities seems to be very interesting but I have to say that from a design point of view the whole stuff is quite unpleasant.
As I understand you guys are now playing with Qt possibilities I won't point out what seems me wrong because I feel it's not the moment (would be a lost of time and I don't have it for the moment). I just want to point out that once you have played enough with Qt a deeper thinking on the design of Celestia wil be necessary again to achieve an UI that could match the level of the engine.

See my repeated earlier statements about precisely the same point! But I shut up.

F.

Why? The whole point of this thread is for people to give suggestions. The current Qt4 interface is nothing more than a starting point.

--Chris

[t00fri]

See my repeated earlier statements about precisely the same point! But I shut up.

F.

Why? The whole point of this thread is for people to give suggestions. The current Qt4 interface is nothing more than a starting point.

--Chris

Well, perhaps because I am trained to think "top down" rather than "bottom up" .

Celestia has a wealth of functionalities! So before getting involved in discussing ridiculous details such as e.g.

Chris,

I tried what you've suggested and it looks good to me:

throughout several forum pages (!), I would want to first sort out WHAT functionalities we want to be represented in GUI (dialog) form and which ones should be set via menues, toolbars, popups or key shortcuts.

We have a host of new features where a GUI setup would be most useful, since they might be difficult to grasp for newcomers: I am notably thinking of frames and the many possibilities of setting and switching frames and related features. We might EVEN think of including some intuitive diagrams to illustrate the respective frame definitions graphically on the respective dialog!

This is just a typical example of how I would want to approach this task.

I shut up, since the principle of "small steps" seems the prevailing and preferred way of Qt4-GUI design around here...

We MUST first discuss some hierarchical structure of what people want to be represented in GUI panels.

Next we should seriously contemplate how to avoid overloading the Celestia OGL canvas with typical database output. As we agreed earlier, of course, EVERY such info feature must be made optional. Still the relative importance of info displayed in various dialogs is important. Some things EVERYONE wants to see most of the time, others will rarely be used. Hence -- when a new dialog is opened (that necessarily takes space away from the display canvas) it's crucial NOT to have important and unimportant stuff MIXED. It takes careful consideration what entries belong on the same dialog window!

etc...

Last not least: By actually coding a functional QT4 GUI as is presently done in an unsystematic manner, prejudices tend to be "burned in" how such a GUI should look like, making it much harder to start over again from a VIRGIN design board.

Most GUI features can easily and most quickly be modelled with the Qt4 designer application and subsequently screen-dumped for discussion purposes, without actually coding them. Since the designer operation is "baby easy" (self-explanatory), many more users could contribute and make useful proposals by using the 'designer' to PRECISELY illustrate what they have in mind!

F.

[ElChristou]

I do agree with Fridger, specially with his last lines...

[chris]

I do agree with Fridger, specially with his last lines...

So start making some UI mock-ups, then.

--Chris

[rthorvald]

all the minor moons of Jupiter and Saturn clutter both the 3D view (when orbits are enabled) and the GUI, and it's only on rare occasions that you actually want to see them. My current plan is to add a new "minormoon" category and organize the UI so that they appear in a separate category from the more significant moons.

Why not use a slider (like the one for stars) that changes the prominence of the orbit lines?

For example, the smaller the moon, the more transparent is its orbit lines. Hook this up to a slider that defines how much transparency is allowed in general, and let everything else be a percentage of that...

If you also added a checkbox to invert it (so that the smaller the moon, the more prominent its orbit), then the user will have pretty good control over what he wants to see.

- rthorvald

[chris]

Celestia has a wealth of functionalities! So before getting involved in discussing ridiculous details such as e.g.

...throughout several forum pages (!), I would want to first sort out WHAT functionalities we want to be represented in GUI (dialog) form and which ones should be set via menues, toolbars, popups or key shortcuts.

Agreed, and the original purpose of this topic was a higher level discussion. I don't mind a little polish to the current Qt4 UI, but we should spend most of our time speaking in broader terms at this point.

We have a host of new features where a GUI setup would be most useful, since they might be difficult to grasp for newcomers: I am notably thinking of frames and the many possibilities of setting and switching frames and related features. We might EVEN think of including some intuitive diagrams to illustrate the respective frame definitions graphically on the respective dialog!

Indeed, this would be useful. With the new observer code, there are many more possibilities with frames. And when introducing an orbit plotting feature, it will be important to present the user a choice of frames in which to plot the orbit. As for how this should be done, I'm not certain and would welcome recommendations.

This is just a typical example of how I would want to approach this task.

We MUST first discuss some hierarchical structure of what people want to be represented in GUI panels.

Next we should seriously contemplate how to avoid overloading the Celestia OGL canvas with typical database output. As we agreed earlier, of course, EVERY such info feature must be made optional. Still the relative importance of info displayed in various dialogs is important. Some things EVERYONE wants to see most of the time, others will rarely be used. Hence -- when a new dialog is opened (that necessarily takes space away from the display canvas) it's crucial NOT to have important and unimportant stuff MIXED. It takes careful consideration what entries belong on the same dialog window!

A few topics to spur discussion . . .

What info should appear in the 3D view? I advocate the removal of day length and temperature, "planetary companions present" for stars. I think we came to a very satisfactory agreement on how coordinates should be displayed.

What tool panels should there be?
- Solar system browser
- Star browser
- Deep sky browser
- Event finder (Eclipse finder augmented with ability to find other events such as occultations.)
- Trajectory plotter
- What else?
- How should they be organized? All browsers in a single tabbed panel, as is currently done?
- ElChristou and I have been discussing whether the panels should be dockable. I feel very strongly that they should be, he disagrees. Other opinions on this?

Tool bars, for frequently used functions:
- Time control
- Guides - orbits, grids, labels
- Toolbars should only exist for very frequently used commands and settings--what other functions belong on a tool bar. How should they be organized?
- Should there be a find object toolbar?

Other features:
- Preferences dialog--related options should be grouped together. How?
- Integrated help
- What should the set time dialog look like?
- Coordinate settings dialog

etc...

I shut up, since the principle of "small steps" seems the prevailing and preferred way of Qt4-GUI design around here...

Last not least: By actually coding a functional QT4 GUI as is presently done, prejudices tend to be "burned in" how such a GUI should look like, making it much harder to start over again from a VIRGIN design board.

Perhaps, but it's also extremely valuable to have some sort of working UI to play around with. And the expertise gained from actually writing Qt4 widgets is invaluable. My experience has been that high-level discussions often benefit from having actual code demonstrations.

Most GUI features can easily and most quickly be modelled with the Qt4 designer application and subsequently screen-dumped for discussion purposes, without actually coding them. Since the designer operation is "baby easy" (self-explanatory), many more users could contribute and make useful proposals by using the 'designer' to PRECISELY illustrate what they have in mind!

Yes, I would like to see many such screenshots posted here.

--Chris

[selden]

A few topics to spur discussion . . .

What info should appear in the 3D view? I advocate the removal of day length and temperature, "planetary companions present" for stars.

Hopefully an "extended information" panel will be available which includes these items and possibly others. As much information as possible is essential when debugging Addons, for example.

What tool panels should there be?
- Solar system browser
- Star browser
- Deep sky browser
- Event finder (Eclipse finder augmented with ability to find other events such as occultations.)
- Trajectory plotter

These all seem reasonable to me. I presume "Trajectory plotter" would be an expanded version of the current "show orbits" render items.

- What else?
- How should they be organized? All browsers in a single tabbed panel, as is currently done?
- ElChristou and I have been discussing whether the panels should be dockable. I feel very strongly that they should be, he disagrees. Other opinions on this?

I'm in favor of "tear off" menus so long as their positions and visibility is remembered across invocations of Celestia. This would be particularly useful on systems with two or more displays: Celestia's 3D window could be on one or more screens and the menus on others.

At the moment I have no opinions on the other features. They'll require some thought.

[ElChristou]

- ElChristou and I have been discussing whether the panels should be dockable. I feel very strongly that they should be, he disagrees...

Chris, it's not I disagree (I send you a mail to explain my points) but to resume it's a question of general philospphy of the GL window. To me a major point is to preserve the integrety of this window. Dockable panels just interact too much with the GL view...