Rename files to something more sane. about akros HOT 9 CLOSED

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.

from akros.

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?

from akros.

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

from akros.

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.

from akros.

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

from akros.

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.

from akros.

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.

from akros.

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
}

from akros.

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

from akros.