akrasuski1 / akros Goto Github PK

Now that we have most of the work done, we could take care of code quality - it won't be much better than it is now, but it may be useful to add comments at strategic places and split main file into few smaller ones. Maybe some refactorization will be done too.

"back", "quit" and possibly "window manager" are not "programs"

Right now we have only draw_filled_window and draw_empty_window. The proposition is that I add another few:

draw_background - draws just the spaces inside - used when process finishes or wants to redraw everything, as current draw_empty_window would screw other windows' corners
draw_corners:

+   +

+   +

(this one would be called when redrawing windows after borders are drawn, in order to fix screwed corners)

I thought also about draw_outline drawing just the borders without background spaces, but I can't find any moment, when we want to draw borders, other than at the start of the program or after window division changes - and in those cases we want to redraw everything from scratch (i.e. with background). It might be needed if we add window focus with whole border effect though.

These functions could get character as a parameter.

I don't like to press 9 every time I want to access the main menu.

It's because when the screen is divided into, say, such a structure:

+=+=+
| | |
+=+ |
| | |
+=+=+

The left two windows are drawn first, and then the right window is drawing its border over the central plus. The fix would be to force pluses to be drawn after all the borders are. This would also make me redraw the whole screen whenever any process quits (its window is cleared then), unless I add a utility function drawing just the inside of the window (just the spaces) - clear_window perhaps? This seems like a better solution.

title

Or any widget, for that matter. I will add check in main process loop in place of killing processes: if it had focus, clear status bar now.

I don't think this one is needed, but I opened the issue for potential discussion. IMO it's widget-developer's and end-user's responsibility to ensure action groups don't collide.

This is a bit hard to do. My proposition is that we don't do it as a widget, because it's very close to the OS layer, and as such, it should be ran as child process of main menu.

Yeah, I thought of a simple interface like that:
AG0 - accept current window and go to next one.
AG9 - cycle vertical split, horizontal split, no split at all at current window.
AG7/8 - decrease/increase split ratio of the current window.
When window is accepted, if it was split, the new window go to the end of the to-do queue, otherwise, the window is accepted and no longer needs thought. When no more windows are in queue, accept new window configuration.
The currently editted window would be somehow marked as selected, I don't know how though yet. Perhaps the background of that window should be made of dots (".") instead of spaces?

I think that at the exact moment you click "window manager" option from program selection, the whole screen should turn into one window covering whole terminal. Inside this window there are instructions for window manager (and note on the bottom, saying: ag9 to start. Also ag1 should be able to abort window selection at any time and revert to old configuration). After clicking continue, I don't think any instructions should stay on screen (instructions should warn about that). And then window selection process starts. When you're done (provided you didn't abort), the main menu should show on window 0, and any processes that had previously been on windows that are curently still visible, should be still visible. Those, which had too big window index, go to background (e.g. you had windows 0,1,2, each of which had a process running, then you resize to just two windows, so only 0,1 stay. Process in window 2 goes to background and is reachable only via process manager).

When opened from main menu not in window 0 it moves focus to window 0:

• produces many fun pictures.

It began with names lib_x because it was supposed to be in library of KSLib. But now, seeing this as a bigger project (which can still be in KSLib, just in separate folder or something!), I should think of other names. Proposition: change every lib_window_x into widget_x or app_x. The reason for lib_x prefix was likely because it would be used by many people in their code and defining a library of useful functions, while this project reverses the roles: it's a framework which includes user-specific programs, which only use my API.
i.e. change:
lib_window_vessel_stats.ks -> app_vessel_stats.ks
I'm for app_x instead of widget_x because those user programs do not have to be gui programs, as name "widget" suggests, but can rather be jobs (oh, maybe job_x?) running in the background, such as seeking light with panels while in orbit.

At the same time, functions could be updated to keep up with new naming scheme:
open_window_akros_main_menu -> run_job_akros_main_menu (or app, whatever)

For a while I thought it was just my fat fingers, but now I'm pretty sure that when I press, say, ag9, the corresponding action is rarely, but sometimes, triggered twice (for example scrolling two menu entries instead of one). I guess it's some kind of race condition in the script, but don't take my word on it.

local child_process is process_state[3].
if process_needs_redraw(process_state){ // pass redraw event to child
    invalidate_process_window(child_process).
    set process_state[0][3] to false. // redraw no longer needed
}
update_process(child_process).

This code repeats a few times even in one file.

It would save current OS state so that it can be restored later.

Such as: get_process_needs_redraw.

Since it was not used in the example app (vessel stats) nor in the OS itself, I neglected updating it to keep up with changing OS system. When I'm fully finished, I should fix it of course.

Should be similar to ordinary menu, but should get list of printable objects (preferably strings) and return selected object's index. This is to ensure dynamic lists of objects that have no default useful print message can be still created in a useful way.

I think we can split it into two functions: draw_filled_window(wnd,char), which may draw such a window:

+==+
|..|
+==+

if given dot as a second character. The second, much more frequently used version, would be draw_empty_window, which calls the first version with space as argument.

1. It displays as "main menu" in the process manager
2. The process can't be moved to main menu window, only created there. It's confusing.
   Proposal: because we can now close or hide main menu without any problems we can disable an option "This Window".

Leave four or so lines of space at the botttom of the screen for the currently focused window to display its controls and what not.

Question 1: how many blank lines should be made available? There should be some balance between too cramped space for explanation and too much space wasted. The potential instructions should be concise and to point. Thus, I'd say three blank lines should be enough - with 60 characters wide, that gives 180 characters of message.

AG1 - go up, AG2 - go down, AG3 - select something
AG4 - make stuff explode, AG5 - extend solar panels
AG6 - make window go away, AG7 - do silly things

is a 150-character message and is quite verbose with 7 action groups - it could be easily shortened (e.g. AG1/2 - up/down). Since two action groups are reserved for focus change, I say 3 lines of 60 characters each is enough. In the worst case, one can make one action group a help button showing more help in main window.

Question 2: should we make the help static (defined at construction and not changed afterwards)? This would allow that help to be drawn during focus change by the OS, helping to reduce widget creator responsibility. But this has a problem - in case of complex widgets, controls change depending on context. For example, the main menu widget would show its own help (AG9 to continue) even if it has menu as a child. Thus, we will have to give functions such as get_status_bar, returning that window and allow widgets to draw there (ideally after checking their focus status).

Question 3: should we allow the amount of blank lines to change? I see no reason not to. So, this is likely an idea for another widget: "Change status bar"

EDIT: After actual testing, I am not going to make the status bar changeable. The user widgets are likely to seek unified experience - and common status bar width is exactly that. Sticking with width 3.

This and draw_focused_window_outline have almost the same code. Do a third function and make the other two wrappers.

First chapter is a quick overvew over capabilities - explain that status is always there, you can resize windows etc. Then, there is documentation.

To be as user-friendly as possible, it should have at least boilerplate code, and then at least two widgets explained. The first one should be as similar to boilerplate as possible, in order to show the easiness of use - Vessel stats widget would be perfect for that, because it doesn't use almost any action groups and thus doesn't have to remember almost anything. The other one should be more complex, ideally using menu or other form of input - I thought a simple 4-operation calculator is good for that - it will introduce a concept of run_modes and running other widgets as children.

The separate thing is documentation. For this, we should have a long document - firstly, giving a brief overview of the sstem as a whole, then description of most important structures (window, process, os_data) and finally, description of most of the functions, including their parameters.

It should be a widget. Initially it shows an ordinary menu (as child process), with options:

1. Kill process.
2. Change process window.
3. Show processes.
4. Quit.
   Whenever any option other than quit is selected, it changes child processs into another menu with list of processes (and maybe back button?). Upon selection, selected action is applied to that process - in case of window change, there is also another menu with actual window selection.

I mean, there should be a way to type something like:

launch_akros_with_programs("Vessel stats","Other stuff").

to make those two programs already there (if there are still some places left, the main menu would be still visible, otherwise first program is main menu's child). There might be also a second parameter, letting you state the window placement/division. Since that is quite verbose to type, there should be some global variables as preset windows configurations, i.e. preset_three_windows etc. with them being documented in separate file. Is that a good idea?

Like this:

local stuff is process[1].
local another is process[2].
//function body
set process[1] to stuff.
set process[2] to another.

There is no need to enumerate all the things if you are not going to use them all, but if you are going to use them at at least one place, pick a name for them like this.

I'd like to see what process I'm editing instead of generic "select action" in the process options menu.

Notice: window 2 has overlapping vessel stats and process manager.

Right now, you choose a window to run programs in, but you can't really make an educated guess about which window is labelled 1. Connected with lack of any sign of selected window for window manager, I think we should print some "metadata" at border of the window:

1===+
|   |
+===+

^ would show that this is window number one. When I add window focus in, I think the selection effect should be unified with window manager selection efect - thus I drop the idea of drawing currently selected window with dots in the background - it's dirty. I propose Using another border or another corners, for example:

1===#
|   |
#===#

or

1===*
|   |
*===*

or

1++++
+   +
+++++

or

1vvv+
>   <
+^^^+

or one of:

1###+ 1####
#   # #   #
+###+ #####

Which looks best? Why? Maybe even different?
In my opinion the last one looks the most distinguishable, and will likely not clutter screen (those v's in the previous one might look strange when near actual text)

Right now there is no way eventual process manager can identify processes, other than index of process and window on which it runs - this won't work for non-gui processes though. I think we should add another entry to process system struct for process name. For instance, for vesssel stat info, it would say "Vessel stats". Thanks to it, the process manager would be able to show a menu like this:

Select process:
[ ] Main menu @0
[ ] Vessel stats @1
[ ] Find targets @bg

I think it's better to explicitly import everything you are using in each file. Example: job_vessel_stats should contain the line run lib_os_data. because it uses it's function get_status_window. Without explicit imports it's impossible to find where a certain function is declared. Besides the current approach makes it possible to break one file while editing another seemingly unrelated to it.

I'm surprised but trying to access ghost items doesn't cause a crash and doesn't change other processes.

for the lazy guys not willing to install ;)

It is already used in main menu and process manager and is going to be in the routine checking whether focus is on free window to write info about opening main menu.