Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

wxGUI: Reorganization of Console panel #2585

Closed
lindakladivova opened this issue Sep 19, 2022 · 17 comments · Fixed by #2746
Closed

wxGUI: Reorganization of Console panel #2585

lindakladivova opened this issue Sep 19, 2022 · 17 comments · Fixed by #2746
Labels
enhancement New feature or request GUI wxGUI related

Comments

@lindakladivova
Copy link
Contributor

lindakladivova commented Sep 19, 2022

Is your feature request related to a problem? Please describe.
The console deserves a better visual separation of Console output and Command prompt functionality. It is not clear which buttons belong to the Command prompt and which to the Output window.
Moreover, in the Single-Window GUI layout, the widget with buttons managing the Command prompt is partly hidden after the GRASS launch (a user has to manually stretch the Console panel)

How it currently looks like in Single-Window GUI:
console_old

Describe the solution you'd like
The suggestion copies @baharmon 's email feedback - thanks Brendan for it! :-) The specs of GUI implementation itself will be further iterated in this Issue.

The suggestion:

  • separating Console output and Command prompt functionality as shown below by putting the respective buttons below each widget
    brendans_idea

Other ideas:

  • add something like blinking "..." or ">>>" to the prompt to encourage users to type there
@lindakladivova lindakladivova added enhancement New feature or request GUI wxGUI related labels Sep 19, 2022
@micha-silver
Copy link

Maybe this comment is too late, but I would like to see the command prompt and output in the same window. Just like any regular terminal. (and the same way the GRASS python terminal works...). I never understood why command entry console was split from the output. I don't know of any other text-based scripting interface that works that way.

@wenzeslaus
Copy link
Member

...the command prompt and output in the same window. Just like any regular terminal. (and the same way the GRASS python terminal works...).

We are limited to the wxPython widgets available because we don't have a capacity to create our own widgets of this type. What is available is usually presented best in the wxPython demo, so you can search there for suitable candidates.

The reorganization here focuses on getting maximum from the available widgets because even the use of the current ones is not optimal.

Layout changes and improved button actions may go a long way with much smaller time investment comparing to migration to a completely different widget. There is no design reason not to have a proper terminal emulator there, so the future is open.

@micha-silver
Copy link

Thanks for the explanation.

@lindakladivova
Copy link
Contributor Author

lindakladivova commented Nov 30, 2022

I adapted a bit the @baharmon's idea. The idea is basically the same, we still have the wx.SplitterWindow widget which contains two inner wx.Panels - Output panel and Command prompt. However, I think that instead of two separate places with buttons, we could create a new toolbar - we use toolbar widgets quite often in panes and I think that they could be helpful even there.

I suggest removing buttons and assigning their events to the new toolbar buttons.
Something like this awful drawing (sorry for that I do not have a scanner with me):

navrh

Here we would have basically two toolbar parts - one related to the Command prompt and one related to the Output window.

I also thought that it might be a bit more intuitive to have the Console at the top (defaultly quite a small widget) and the Output window at the bottom (the bigger widget).

@petrasovaa , @wenzeslaus and others, any suggestions here?

@wenzeslaus
Copy link
Member

The "prompt at the top output at the bottom" solution is interesting because it concentrates all the interaction at the top, but the issue is that it goes against the "terminal" idea we are trying to mimic here (see e.g. @micha-silver's comment), so I don't know. Any opinions on that?

@petrasovaa
Copy link
Contributor

I am not sure either. Regarding the buttons, I don't think this solution quite addresses the problem, it will be still unclear which button is associated with prompt or output window.

@lindakladivova
Copy link
Contributor Author

The "prompt at the top output at the bottom" solution is interesting because it concentrates all the interaction at the top, but the issue is that it goes against the "terminal" idea we are trying to mimic here (see e.g. @micha-silver's comment), so I don't know. Any opinions on that?

Yes, you are probably like. If I look at it from this perspective, it is better to have a prompt at the bottom. My point was that for people who are not familiar with the prompt much, the prompt window is not significant enough. If I take it from my side, I would definitely notice the Prompt faster if it will be at the top. But the reason is maybe that I did not realize at the first glance that the output window should somehow mimic terminal. For me, the whole Console widget was just an output window - for a long time I did not realize that I can actually write there as well.

@lindakladivova
Copy link
Contributor Author

I am not sure either. Regarding the buttons, I don't think this solution quite addresses the problem, it will be still unclear which button is associated with prompt or output window.

I think it may be better than in the current solution where the buttons are in the middle. The problem with implementation of @baharmon idea is that the currently used wx.SplitterWindow cannot have the window caption (as for example wx.Frame or agw panes). Or at least I could not find how to do it. If we would like to have captions we would probably need to create two separate dockable panes.

@petrasovaa
Copy link
Contributor

We could remove the Clear (prompt) functionality completely, it's not terribly useful (you can always do Ctrl+A and Del) and it's confusing together with the Clear (output window) button. Then the 3 buttons could stay and be renamed to Clear output, Save output, and Export history (assuming the functionality is changed from logging to exporting current GUI history). They could be located at the very bottom.

@lindakladivova
Copy link
Contributor Author

We could remove the Clear (prompt) functionality completely, it's not terribly useful (you can always do Ctrl+A and Del) and it's confusing together with the Clear (output window) button. Then the 3 buttons could stay and be renamed to Clear output, Save output, and Export history (assuming the functionality is changed from logging to exporting current GUI history). They could be located at the very bottom.

I like that. So @petrasovaa do you agree to preserve the wx.SplitterWindow?
I am still not sure about buttons at the bottom though. They are actually related more to the Output window part which is the upper one. I still think that a new toolbar would be better than buttons because we also need more space in Single-Window GUI and buttons occupy quite lots of space. Not sure if three buttons in the row would fit nicely there.

@micha-silver
Copy link

I actually like the idea to put the command prompt window above as in @lindakladivova 's sketch. That is more similar to a regular terminal where you enter commands, and the results appear below. And this arrangement would clear up the confusion as to which window the buttons refer to. And as @petrasovaa mentioned, there's less use for a clear button in the command prompt window anyway. Then Buttons at the bottom displaying "Clear output", "Save output", "Export history" would be understood.

@petrasovaa
Copy link
Contributor

I still think that a new toolbar would be better than buttons because we also need more space in Single-Window GUI and buttons occupy quite lots of space. Not sure if three buttons in the row would fit nicely there.

I would first try the buttons, I am not yet convinced toolbar is the best solution here. Having the labels on the buttons will be more clear than icons and we don't expect additional functionality to be added. The problem with the width is not just about the buttons, tools like r.info print with certain width.

@petrasovaa
Copy link
Contributor

I actually like the idea to put the command prompt window above as in @lindakladivova 's sketch. That is more similar to a regular terminal where you enter commands, and the results appear below. And this arrangement would clear up the confusion as to which window the buttons refer to.

Isn't that the other way? If you start a terminal, then yes, but once you used it for some time, you keep typing at the bottom of the terminal and stuff gets printed above. Not sure if I am explaining it well...

@micha-silver
Copy link

@petrasovaa Yes, I understand what you mean. But the output of any command is always below my input.

@wenzeslaus
Copy link
Member

@micha-silver Below interactive prompt or the typed text?

Here is my terminal emulator and the GUI Console:

Screenshot from 2022-12-01 13-24-42
Screenshot from 2022-12-01 13-24-17

The order is the same in both in the screenshots: old executed command, its output, new currently typed command.

@micha-silver
Copy link

Thanks @wenzeslaus for further clarifying.

@ecodiv
Copy link
Contributor

ecodiv commented Dec 3, 2022

Just my 2 cents on having the output on the top vs bottom.. I initially liked the idea of having the console on the top, getting the place to type more at eye level (at least , with my screen setup). However, the clear advantage to follow the terminal approach is the input is close to the latest output (like writing a text). And I guess it is not possible to have the latest output printed above instead of below older output.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request GUI wxGUI related
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants