laptop
laptop copied to clipboard
Multiple USB ports availability
I believe that once you put in the first USB you should be given an option for a second one so you can transfer files from one USB to another. That's also why we need the #file-manager
I know, the older computers did have A: and B:
At the time the count 1 is hard-coded. To enhance them the whole removable disk framework needs to be enhanced:
- [ ] count of slots per hardware
- [ ] Capabilities for each slot (USB or floppy) in hardware
- [ ] File selection dialog to check all slots
- [ ] ???
For printer I needed 3x slots but I decided to use a workaround (swap the content) because it is not trivial
So you say the entire framework needs redone (Which makes sense). In the registration of the computer the ports need defined, as of now your media types are floppy and usb although we need to keep in mind future types such as adding dvd support. We register the hardware Here so hwdef needs modified to tell us this. Maybe we could add a table of ports to hwdef that gets added to the node meta? So you would do
hwdef = {}
--all of your other stuff
hwdef.ports = {}
hwdef.ports[port1] = floppy
hwdef.ports[port1] = usb
hwdef.ports[port3] = usb
When that gets passed we take those ports and store them in the node meta
Yes, we need a change for hardware registration. At the time we have the hwdef.hw_capabilities = { "hdd", "floppy", "usb", "net", "liveboot" }
that needs to be replaced by on other definition. My idea was to do it in the way
hwdef.hw_capabilities = { hdd = 1, floppy = 2, usb = 1, net = true, liveboot = { "floppy", "usb", "hdd" } }
`
That statement saying that there is 1 hdd, 2 floppy ports, and 1 usb port? I assume net=true means network drives are allowed but what is live boot for?
live boot is to start the laptop from media. That means the removable floppy is used as system storage. Already implemented, see the codiak that does have no hdd, and cube that supports the liveboot too. Since the system storage is used to store the selected theme, you can see the difference. Later the "installed apps list" will be stored in system storage too. The proposed new list is the "liveboot allowed from", like boot order in BIOS. Maybe we need a BIOS-storage too ;-)
Makes sense, that part should be easy to implement then unless I am missing something. The next thing that needs figured out is the framework for the file system. Have you thought of how to do that yet?
edit: I am reading through the api, if nothing is set it states that default is all, if you go to counting ports would default be just the HDD then?
edit2: Do you need a bios storage or should the bios be hard coded and you need an OS storage.
After the setting is implemented the block_device layer needs to be enhanced to use different inventory slots sized to the supported size. At the time only 1 slot is implemtened that is used for all compatible removables. Then the removable app needs to be enhanced to reflect the block_device changes, then CS-BOS commands and load/save dialog (that will be the file manager at the end). And I asume I forgot anytihng. :-/, yes, printer firmware needs to be rewritten to use multiple slots.
Since you are talking about a storage framework why not build the framework entirely outside of the apps and use functions to work with it. Maybe for the physical inserting the drives (storing the drive item in the computer) Don't use an app but pull up an inventory form spec another way. Add a permanent button below the "Screen" that you can click to bring up the computer inventory and your inventory. When you hit that button again you return to the computer screen. You interact with the drives via functions, the HDD would not show up on that separate form spec.
The framework is build outside the apps, in block_device. And the removable does work as storing the media item in nodemeta's "main" inventory. Idea is to split them to different inventories for each media type.
It is possible to insert the items by punching the computer with the item. (Usefull for CS-BOS). Ejecting does work using CS-BOS EJECT command. THe "removable" app is just an UI to administre the remvable.
that you can click to bring up the computer inventory and your inventory
that is the function of removable app ;-) Permanent button, maybe, at the time it is called from launcher as "app" and as "mount" button in file dialog. Pressing button "back" you are back in the previous app, like the file dialog. That does work already.
So what you need to do is modify bdev:get_removable_disk(removable_type) to accept a port identifier as an argument? Or do you want to rework it so there is one function and the port identifier determines which drive you are accessing?
The basic change is to replace
data.inv:set_size("main", 1) -- 1 disk supported
to all hardware-supported
data.inv:set_size(removable_type, max_slots)
Then adress the right slot by index
bdev:get_removable_disk(removable_type, index)
stack = stack or data.inv:get_stack("main", index)
Take sure the multi-slot and is supported at all places.
The function bdev:sync() needs enhanced in this context.
The self.removable_disk
in block_device cannot be used anymore because of multiple removable_disk's possible
@apachano , if you have any progress, please push them to github. May I can do already some tests and code reviews, or take some additional changes if I find time
I will upload what I have when I get home from work tonight. It is slow as I learn the code.
To be completely honest my code is a mess, not functional in the least. I am still figuring out how your mod works and frankly it introduces a few new programming things I have not encountered which I have to research. The commit with what I have done is there in my branch, I pulled to make sure the rest is up to date.
That's the Reason I asked. I know the difficulties to start work on foreign code, so I would like to support you to understand existing code. Now I am AFK till Monday, we got snow yesterday in Germany
Right now the computers all require you do a live boot
The message is depending on sysdata was get in os_get()
self.sysdata = self.bdev:get_app_storage('system', 'os')
That is the first usage the block device needs to work properly ;-)