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
Comments
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. |
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. |
Thanks for the explanation. |
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. 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? |
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? |
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. |
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. |
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. |
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 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. |
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. |
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... |
@petrasovaa Yes, I understand what you mean. But the output of any command is always below my input. |
@micha-silver Below interactive prompt or the typed text? Here is my terminal emulator and the GUI Console: The order is the same in both in the screenshots: old executed command, its output, new currently typed command. |
Thanks @wenzeslaus for further clarifying. |
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. |
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:
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:
Other ideas:
The text was updated successfully, but these errors were encountered: