Amiga.org
Operating System Specific Discussions => Amiga OS => Amiga OS -- Development => Topic started by: kolla on September 23, 2015, 11:05:53 PM
-
The last year I have been away backpacking, and only touched Amiga through UAE on various hostels around in latin America. I finally came back home and at the same time I got my MIST which I have been playing with lots lately. I have it running OS3.9 with one of many custom 3.9 kickstarts I have assembled (including the awesome new layers.library), and it is running very smoothly :)
Anyways, there are many little quirks with OS3.9 still, and I would like to point out some of them, and knowing that certain people are on this site, maybe something can be done to improve, or simply just clarify things.
-
First up - C:List
C:List could really need a flag to drop "human readable" terms for days. There are times I want to use output from ´List file LFORMAT "%T"´ as variable in scripts for example, and then having words like "Today", "Friday", "Yesterday" - and even localized - is not at all useful. Pretty please, an update to C:List with a "code readable" option.
(if there are other ways to get timestamp from a file, I'm eager to know)
-
I think its great that your starting a list that could potentially lead to boingbag5. Others currently running 3.9 with with boingbags1-4 should chime in too with ideas for improvements. I hope to join those ranks soon! :laugh1:
-
The icon of Ram Disk:
This is ThoR realm - Ram-Handler has been updated and improved, but still we need tricks and fiddling to make sure the icon - RAM:Disk.info - somehow ends up being saved on disk when we update it (change icon, snap shot). Since one of the updates done by ThoR involves soft links working on RAM:, I have a line in Startup-sequence that says "MakeLink RAM:Disk.info ENVARC:Sys/def_RAM.info", and this works nicely (softlinks are default too with C:MakeLink).
But - would it not be so much better if Ram-Handler also handled the Disk.info issue by itself, using ENVARC:Sys/def_RAM.info by default, updating it when user changes RAM:Disk.info?
-
I continue with time/date/clock related issues. Since neither of my current main Amiga systems (the Minimig and the MIST) have RTC, I resort to dirty tricks to keep the clocks fairly correct on them.
It would be great if C:Date could take a given file as argument, and use the timestamp of that file to set the time.
(I found a great piece of software on Aminet that is truly useful, "Timekeeper", which updates a timestamp in resident RAM, and on reboot sets the time from that (plus a given number of seconds to compensate for the few seconds of reboot), and when the timestamp in RAM is messing, executes a command that can set the system time using a different method, for example letting user set time).
-
When AmigaOS boots and no RTC is found, it sets the system time to what creation time of the filesystem it boots from is (at least as long as FFS is used - no idea about PFS and SFS). Does the structures of FFS perhaps contain a "last changed" timestamp too? If so, it would make sense to use that instead. And if not - can I suggest that C:SetDate is updated to not just change the timestamp of a file or directory, but also filesystems? :)
-
First up - C:List
C:List could really need a flag to drop "human readable" terms for days. There are times I want to use output from ´List file LFORMAT "%T"´ as variable in scripts for example, and then having words like "Today", "Friday", "Yesterday" - and even localized - is not at all useful. Pretty please, an update to C:List with a "code readable" option.
(if there are other ways to get timestamp from a file, I'm eager to know)
Just add the "dates" switch. It works with or without LFORMAT for dates but doesn't do anything for your "%T" (time) example.
>List dates LFORMAT "%D"
The icon of Ram Disk:
This is ThoR realm - Ram-Handler has been updated and improved, but still we need tricks and fiddling to make sure the icon - RAM:Disk.info - somehow ends up being saved on disk when we update it (change icon, snap shot). Since one of the updates done by ThoR involves soft links working on RAM:, I have a line in Startup-sequence that says "MakeLink RAM:Disk.info ENVARC:Sys/def_RAM.info", and this works nicely (softlinks are default too with C:MakeLink).
But - would it not be so much better if Ram-Handler also handled the Disk.info issue by itself, using ENVARC:Sys/def_RAM.info by default, updating it when user changes RAM:Disk.info?
Peter K's icon.library will use the ENVARC:Sys/def_RAM.info for ram disk by default and without using MakeLink. In more recent versions of his library, the ram disk icon will be ghosted as there is no real icon in the ram disk but he added a "NoGhost" ToolType which will keep any icon from being ghosted.
http://eab.abime.net/showthread.php?t=64079&page=69
The other option is to copy the ram disk icon to the ram disk on bootup but that uses memory.
-
Just add the "dates" switch. It works with or without LFORMAT for dates but doesn't do anything for your "%T" (time) example.
>List dates LFORMAT "%D"
%&$#?@!%&$#?@!%&$#?@!778;
Huh - I was 99% sure I tried using "dates" option, and only saw it display dates or not on listings. But you are right, it turns those localized strings to standardized dates. And yes, I meant %D, not %T *facepalm* - Thanks :)
Peter K's icon.library will use the ENVARC:Sys/def_RAM.info for ram disk by default and without using MakeLink. In more recent versions of his library, the ram disk icon will be ghosted as there is no real icon in the ram disk but he added a "NoGhost" ToolType which will keep any icon from being ghosted.
http://eab.abime.net/showthread.php?t=64079&page=69
The other option is to copy the ram disk icon to the ram disk on bootup but that uses memory.
I see - I am using Peter K's icon.library, but it does not save back up ENVARC:Sys/def_RAM.info, for example if I move RAM Disk on Workbench, snapshot it, it will just create RAM:Disk.info, but ENVARC:Sys/def_RAM.info is untouched, and on next reboot RAM Disk will be back on it's original location.
With a soft link from RAM:Disk.info to ENVARC:Sys/def_RAM.info, when I do changes to RAM:Disk.info, the soft link will save those changes to ENVARC:Sys/def_RAM.info - which is what I think pretty much everyone wants.
I am not sure which part of the system that should have the task of maintaining ENVARC:Sys/def_RAM.info, but feel ram-handler is an obvious candidate.
-
Next up - a tip regarding s:startup-sequence
First of all, too much >NIL: in there, hehe :)
Secondly, Assign and Execute are made resident manually, they could however be made resident simply by making sure they have the "hold" bit set, with which they will go resident the first time they are run.
So, I typically set the H bit on them and remove those lines :)
-
Speaking of icons - once upon a time, I had drawers that were projects, their Icons were of type project with an associated default tool, there are programs that take drawers as argument - THIS WAS PRETTY DARN NEAT! :)
For example - I could turn a drawer full of pictures into a project, give it an appropriate icon and set a picture viewer as default tool, on opening that icon, the image viewer would launch and show slideshow of all the pics in the drawer.
More useful example - I had a rexx script that would take a drawer as argument, and build a GUI based on resources found in that drawer, very much like how !Apps work on RISCOS (I was inspired by RISCOS on this), or OSX.
Today, all drawers are treated as drawers, regardless what the icon type says, I _really_ would love to have project drawers back. I guess it is PeterK's icon.library I can blame for this.
EDIT: I just asked PeterK on that EAB thread.
-
Next up - a tip regarding s:startup-sequence
First of all, too much >NIL: in there, hehe :)
Secondly, Assign and Execute are made resident manually, they could however be made resident simply by making sure they have the "hold" bit set, with which they will go resident the first time they are run.
So, I typically set the H bit on them and remove those lines :)
Hold bit is not supported by SFS (where it has different purpose) and it is often lost when copying files around.
-
Speaking of icons - once upon a time, I had drawers that were projects, their Icons were of type project with an associated default tool, there are programs that take drawers as argument - THIS WAS PRETTY DARN NEAT! :)
For example - I could turn a drawer full of pictures into a project, give it an appropriate icon and set a picture viewer as default tool, on opening that icon, the image viewer would launch and show slideshow of all the pics in the drawer.
More useful example - I had a rexx script that would take a drawer as argument, and build a GUI based on resources found in that drawer, very much like how !Apps work on RISCOS (I was inspired by RISCOS on this), or OSX.
Today, all drawers are treated as drawers, regardless what the icon type says, I _really_ would love to have project drawers back. I guess it is PeterK's icon.library I can blame for this.
Are you using 3.1 or 3.9? If 3.9, I think it is related to Workbench. Icon.library does not care about icon type, really.
-
I see - I am using Peter K's icon.library, but it does not save back up ENVARC:Sys/def_RAM.info, for example if I move RAM Disk on Workbench, snapshot it, it will just create RAM:Disk.info, but ENVARC:Sys/def_RAM.info is untouched, and on next reboot RAM Disk will be back on it's original location.
With a soft link from RAM:Disk.info to ENVARC:Sys/def_RAM.info, when I do changes to RAM:Disk.info, the soft link will save those changes to ENVARC:Sys/def_RAM.info - which is what I think pretty much everyone wants.
I am not sure which part of the system that should have the task of maintaining ENVARC:Sys/def_RAM.info, but feel ram-handler is an obvious candidate.
If using Peter K's icon library, I suppose it's the responsibility of the end user to snapshot his or her ram disk icon and then copy the resultant amended disk.info file from RAM: to ENVARC:Sys/def_RAM.info. It only has to be done once so I personally don't see it as an inconvenience.
-
Hold bit is not supported by SFS (where it has different purpose) and it is often lost when copying files around.
As does the P flag that still needs to be set, so ...
Really, SFS uses it for what?
-
If using Peter K's icon library, I suppose it's the responsibility of the end user to snapshot his or her ram disk icon and then copy the resultant amended disk.info file from RAM: to ENVARC:Sys/def_RAM.info. It only has to be done once so I personally don't see it as an inconvenience.
Every time you change icon.
Every time you move the icon to somewhere and snapshot it.
Every time you tell Workbench to remember the position and view of open RAM Disk window.
It is not at all obvious that all this information is stored in RAM:Disk.info and that users are expected to copy Disk.info to ENVARC:Sys/def_RAM.info manually.
It could just automatically be saved in ENVARC:Sys/def_RAM.info by ram-handler, in fact RAM:Disk.info would not even need to exist at all.
-
Are you using 3.1 or 3.9? If 3.9, I think it is related to Workbench. Icon.library does not care about icon type, really.
I just did a test - it works perfectly as I want in OS 3.1.
* I booted from Workbench3.1 in DF0: and have Extras3.1 in DF1:
* I copy WBStartup from Workbench3.1 to RAM Disk by pulling it over
* I rename WBStartup in RAM Disk to "Project"
* I open IconEdit from Extras3.1:Tools, I open RAM:Project.info
* I go to "Type" menu and set it to "Project", I save the icon and exit IconEdit
* I double click the Project icon in RAM Disk
- Screen flashes and the screen bar says "The icon(s) have no default tool"
* I click "Project", and open Information, sets "Default Tool:" to "Multiview".
* Again I double click the Project icon in RAM Disk
- Multiview opens and shows content of "RAM Disk:Project" - as I expected.
At some point on the way from OS3.1 to 3.9 this behavior vanished.
EDIT: Correction - it works by doing a work-around suggested by Peter K - rename the drawer from shell, set type of icon (that now lacks a corresponding drawer) to project, give it a default tool, rename the drawer back in the shell. Presto, it works!
-
It is not at all obvious that all this information is stored in RAM:Disk.info and that users are expected to copy Disk.info to ENVARC:Sys/def_RAM.info manually.
It could just automatically be saved in ENVARC:Sys/def_RAM.info by ram-handler, in fact RAM:Disk.info would not even need to exist at all.
It is also inconsistent with the way default icons work and requires special handling for one exception to save the ENVARC:Sys/def_RAM.info every time the ram disk icon changes. These default icons in ENVARC:Sys can apply to many icons. It should be possible to have other units of ram disk which would use the same default icon. Maybe it would be possible to allow ENVARC:Sys/RAM.info to represent a particular icon device but it would still require some special handling to save and snapshot to it. It might end up being the OS performing MakeLink functionality for the icon. This could work for other icons like iconified application icons and perhaps FTPMount's active icon but I see little advantage for the work needed, larger code size and likely slow down needed (probably in workbench.library). If you want to snapshot your ram disk icon often or in different places and want it to survive reboots, MakeLink is simple and probably a good option for you.
-
Well, before MakeLink can work, the underlying filesystem must support it. I do not know ThoR's background for suddenly supporting soft links on RAM: with newer ram-handler, but I sure knew what to do with it.
My main point is that changes to RAM Disk icon should survive reboots - one way would be for the handler to take care of it. Wether it uses ENVARC:Sys/def_RAM.info or something else is not important.
-
Funny legacy feature that maybe not everyone is aware of - even OS3.9 kickstart respects DEVS:system-configuration from back in 1.x days. If you have the Preferences programs from WB1.3 for example, you can configure crazy colors, interlaced modus, funny mouse pointer etc and have all that configured long before IPrefs, even when booting without startup-sequence.
Sadly, OS 1.3 Preferences easily crash on newer systems, so I booted back to 1.3.4 and with 1.3 kickstart to create the prefs, then switched back to my 3.9 setup, inserted the WB 1.3.4 WB floppy, copied over df0:devs/system-configuration to DEVS:, removed floppy and booted without startup-sequence. :laughing:
-
I just did a test - it works perfectly as I want in OS 3.1.
* I booted from Workbench3.1 in DF0: and have Extras3.1 in DF1:
* I copy WBStartup from Workbench3.1 to RAM Disk by pulling it over
* I rename WBStartup in RAM Disk to "Project"
* I open IconEdit from Extras3.1:Tools, I open RAM:Project.info
* I go to "Type" menu and set it to "Project", I save the icon and exit IconEdit
* I double click the Project icon in RAM Disk
- Screen flashes and the screen bar says "The icon(s) have no default tool"
* I click "Project", and open Information, sets "Default Tool:" to "Multiview".
* Again I double click the Project icon in RAM Disk
- Multiview opens and shows content of "RAM Disk:Project" - as I expected.
At some point on the way from OS3.1 to 3.9 this behavior vanished.
This turns out to be not true - it works just as well with 3.9BB2 as with 3.1.
I just tried with last official icon.library from BB1 (45.1, 8.Feb.2001), and with that installed it behaves just like in OS3.1 - yay! :)
The problem is solely due to PeterK's icon.library which I must have started using at some point very early on. I also noticed this does not work in MorphOS.
Also, PeterK admits on EAB that it is a feature in his icon.library, or as I see it, a compatibility blunder that has has had me confused for years!
MIST is great for having a whole load of setup to test this stuff with, hehe :D
-
Every time you change icon.
Every time you move the icon to somewhere and snapshot it.
Every time you tell Workbench to remember the position and view of open RAM Disk window.
It is not at all obvious that all this information is stored in RAM:Disk.info and that users are expected to copy Disk.info to ENVARC:Sys/def_RAM.info manually.
It could just automatically be saved in ENVARC:Sys/def_RAM.info by ram-handler, in fact RAM:Disk.info would not even need to exist at all.
I use 3.1 with MultiCX, and IIRC the WINREMEMBER tooltype or similar remembers the position of windows within the session. So obviously this doesn't survive reboots, but still a nice feature.
Instead of the link for the ram disk icon, I suppose it would be possible to write a script that automatically copies over the disk.info if it changes, either from referring to datestamp or a file change, or even easier just make it copy every so often, or just write the script to copy it and have it executable from the tools menu or something.
-
The icon of Ram Disk:
This is ThoR realm - Ram-Handler has been updated and improved, ...
Unfortunately, no. The Ram-Handler of 3.9 was done by Heinz, not me.
-
Well, before MakeLink can work, the underlying filesystem must support it. I do not know ThoR's background for suddenly supporting soft links on RAM: with newer ram-handler, but I sure knew what to do with it.
My main point is that changes to RAM Disk icon should survive reboots - one way would be for the handler to take care of it. Wether it uses ENVARC:Sys/def_RAM.info or something else is not important.
It is important. What if you have read-only media and you want to change its icon position permanently? Or a volume without icon?
RAM disk solution would be one shot fix for one case but what about other cases?
-
I use 3.1 with MultiCX, and IIRC the WINREMEMBER tooltype or similar remembers the position of windows within the session. So obviously this doesn't survive reboots, but still a nice feature.
Instead of the link for the ram disk icon, I suppose it would be possible to write a script that automatically copies over the disk.info if it changes, either from referring to datestamp or a file change, or even easier just make it copy every so often, or just write the script to copy it and have it executable from the tools menu or something.
There are background daemons on Aminet that does this, people waist CPU cycles on running dedicated process to monitor RAM:Disk.info to copy it back to envarc: or S: or wherever. There are scripts that run in loops, there are all kinds of work-arounds - but that is all they are - work-arounds. RAM Disk is part of the OS, dealing with the icon is also part of the OS - RAM Disk is special, it is different, it should be dealt with by the OS without the need for third party work-arounds.
As for surviving the "session" until next boot - isn't that default behavior?
-
Unfortunately, no. The Ram-Handler of 3.9 was done by Heinz, not me.
Aha, ok, I see. http://se.aminet.net/util/boot/PatchRAM.readme looks very much like you, Heinz is not even mentioned.
-
It is important. What if you have read-only media and you want to change its icon position permanently? Or a volume without icon?
RAM disk solution would be one shot fix for one case but what about other cases?
What about them? RAM Disk is the obvious one, since it affects everyone. You could have Deficons itself take care of everything, storing meta data normally stored in Disk.info files somewhere else for all kinds of volumes and devices, keeping def_icons.info files clean for all meta data - but you would still need somewhere to write that information down for it to survive reboots. You could have ENVARC: in nonvolatile RAM if you want to. I really don't understand your argument - because fixing icon handling for RAM Disk would not be a general solution also working for CD drives, it is better to not fix it at all?
-
My wishlist add? Transparent background option for Amidock. :biglaugh:
-
I really don't understand your argument - because fixing icon handling for RAM Disk would not be a general solution also working for CD drives, it is better to not fix it at all?
Because in the software industry you don't do shortsighted "fixes" and workarounds. You have to look at a bigger picture.
Developer should find a solution that fixes RAM disk and CD drives and other RO/temp drives in general.
-
Because in the software industry you don't do shortsighted "fixes" and workarounds. You have to look at a bigger picture.
Developer should find a solution that fixes RAM disk and CD drives and other RO/temp drives in general.
:roflmao::roflmao::roflmao:
Software industry? :)
-
:roflmao::roflmao::roflmao:
Software industry? :)
Of course it is a joke in Amiga land.
-
Of course it is a joke in Amiga land.
Yes - that is the bigger picture here!
-
Anyways, having the soft link RAM:Disk.info is way more elegant than any other solution I have seen, any changes done to ram disk icon are instantly saved to envarc:sys/def_RAM.info without any background process or silly script running, no special interaction on my part, and it of course survives reboots.
-
My wishlist add? Transparent background option for Amidock. :biglaugh:
Yes, that would be nice and easy. But actually you can fake it: see AKReal:
http://hostthenpost.org/uploads/d69352e09b704011eb28cfb559b4e36e.png
And also you can see in the screenshot at the bottom WBDock by Thomas that has an emulated transparent background included.
-
More annoying quirks - c:date again, and locale - how do I tell c:date to accept English input even when my locates are Norwegian? And how lame is it, that it insists on "local" language input, when the error message it spits out, is always in english? It is kinda hopeless to use c:date in scripts, since what it spits out and accept as input, depends on locale settings. I have tried to set both local and global variable "language", but it doesn't care.
-
More annoying quirks - c:date again, and locale - how do I tell c:date to accept English input even when my locates are Norwegian? And how lame is it, that it insists on "local" language input, when the error message it spits out, is always in english? It is kinda hopeless to use c:date in scripts, since what it spits out and accept as input, depends on locale settings. I have tried to set both local and global variable "language", but it doesn't care.
It is probably using dos.library/StrToDate() with FORMAT_DEF to parse input. With that option it is always using localized parsing. Other options are international format (whaaat...), Canadian (eh?), American (USA) and AmigaDOS format.
There is something missing in the API and it is consistency...
-
I think its great that your starting a list that could potentially lead to boingbag5. Others currently running 3.9 with with boingbags1-4 should chime in too with ideas for improvements. I hope to join those ranks soon! :laugh1:
Errrm - did I miss something?
I only know the official BoingBags I & II from Haage&Partner, as well as their Euro-Update.
I also seem to remember having heard about an unofficial, buggy BoingBag III.
But BoingBag IV or even V? Never heard of it...
Care to explain?
-
It is probably using dos.library/StrToDate() with FORMAT_DEF to parse input. With that option it is always using localized parsing. Other options are international format (whaaat...), Canadian (eh?), American (USA) and AmigaDOS format.
Yes, and C:Date should have option flags to support more formats, and it should very well be localized itself too.
There is something missing in the API and it is consistency...
Indeed.
-
Errrm - did I miss something?
I only know the official BoingBags I & II from Haage&Partner, as well as their Euro-Update.
I also seem to remember having heard about an unofficial, buggy BoingBag III.
But BoingBag IV or even V? Never heard of it...
Care to explain?
The readme for the latest "Unofficial" BB3 & BB4 is available here:
http://amigan.1emu.net/releases/BoingBags3&4.readme
Use this link to download:
http://amigan.1emu.net/releases
Note: BB3 was finished years ago but BB4 is still WIP. ;)
-
I have ended up reverting a lot of the BB3+4 package, it goes a bit beyond just getting in the latest updates.
-
I have ended up reverting a lot of the BB3+4 package, it goes a bit beyond just getting in the latest updates.
(http://f.tqn.com/y/netforbeginners/1/W/-/V/haters.jpg)
Did you also revert to Windows 95 because Windows 7 "went a bit beyond just getting in the latest updates"? :lol: :lol:
-
Did you also revert to Windows 95 because Windows 7 "went a bit beyond just getting in the latest updates"? :lol: :lol:
No, I would revert to Windows 98SE.
My point is just that BB3+4 pulls in third party libraries and things that sometimes are incompatible with original software, and that can be annoying - for example PeterK's icon.library, for example latest KingCON, for example THE which I don't even want in the first place, and much more. Also, it did not check if I had Genesis installed or not before it "updated" my non-existing installation, creating an Internet folder without any icon, and with some useless binaries in it. And yeah, I hate it when installer scripts mess around.
-
@kolla:
BB3&4 V1.1 has been released and addresses these issues.
http://amigan.1emu.net/releases/