Rename files to something more sane.

[akrasuski1]

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)

[abenkovskii]

In addition to apps that can be runned both from OS and form other processes we need other kinds of process too. For example I think that menu and number-input are widgets rather when apps.

[akrasuski1]

You are right - but on this architecture they are all treated in the same way, so I don't want to cause confusion, and make all of them called the same. But right now, I'm considering running away from the problem and doing it like this:

lib_window_vessel_stats.ks -> job_vessel_stats.ks
open_window_vessel_stats -> run_vessel_stats
draw_window_vessel_stats -> draw_vessel_stats
update_window_vessel_stats -> update_vesel_stats

Not only the names are shorter, but also the word job is used only in the name of file. What do you think?

[abenkovskii]

Fine. Though apps actually have a slightly different interface: their constructor should have the same signature (the number and type of parameters).

[akrasuski1]

Yeah, but since everything in menu is launched via the program_list.ks wrapper, even proper apps don't need to have exact same constructor. Closing issue after having applied changes.

[abenkovskii]

@akrasuski1 Wait. I thought that program_list is a placeholder.

[akrasuski1]

Hmm, no, not really. Why? Is this a bad design? User might want to "install" only some programs to his OS. And where such install should be specified? I thought a separate file, with list of programs is okay.

[akrasuski1]

Hmmm. Now you got me thinking - I actually can make users create a function named register_vessel_stats or so, and call it while running the library. Then it would add itself to the menu. Is that better? While the wrapper would still persist, it would be only used for system programs and such - "normal" apps would have to have a constructor consisting of only os_data, window_index.

[akrasuski1]

OK, I implemented what I've said above. Look at current version of program list. It's very edit-easy, having pretty much just the list of libraries to include. As a compromise, every widget library needs now to include these two lines on top (or bottom, doesn't matter):

parameter os_data.
register_program(os_data,"Vessel stats","run_vessel_stats",false).

This tells the OS to "install" the program - add its name to main menu and know which function to run afterwards. The last argument is almost always false - if true, it forces the program to be run in zeroth window (without user choice of window). Also, now menu-runnable programs need to follow the specific constructor:

function run_x{
    parameter
        os_data,
        window_index.
    //stuff
}

[abenkovskii]

Yes I was thinking about something similar. Self-registering applications (but not all jobs because there is not much use in opening dialog without parent) are the only approach I like. All other variants I thought about:

1. A show a menu where the user can run any program and hope that it will be a "job" - a recipe for disaster
2. Search for files with matching certain pattern and load them - I like it very much but there are no string operations in kOS just yet
3. Have a file that the user will edit manually - a bad idea because the user can misspell/damage something in that file