Re: [ql-users] Directory Devices
Hi Dilwyn, What about 'HISTORY'? Dilwyn Jones wrote: I'm working on the 'MyQL' part of Launchpad and I'd like to ask for any additional information can offer on the following. I'd like to compile as complete a list of current directory devices on QL-style systems as possible so that I may provide icons for these devices as required. Obviously, 'default' icons will be available for any 'unknown' devices. The directory devices I am aware of at the moment are: MDV FLP/FDV/FDK (the 3 types of floppy systems over the years) RAM WIN ROM ATR - Atari/DOS disk device IIRC DOS - QPC2 CDR - Thierry's Atapi drivers. NUL - Nul device (+ BLACK_HOLE?) N, M and S - network devices (assuming these count) (DEV, SUB, PTH etc don't count as they could I suppose be anything) Any more known directory device driver names? -- Dilwyn Jones
Re: [ql-users] Directory Devices
On 25 Feb 2003 at 10:40, François Van Emelen wrote: Hi Dilwyn, What about 'HISTORY'? I'd be interested to know whether anybody uses that device at all. Wolfgang
Re: [ql-users] Directory Devices
When I used to have more than one QL networked to another, I arbitrarily referred to the networked drives as ndk_ (after fdk ... i.e., Network DisK) regardless of its actual physical type. Does that make sense? Is that what you wanted to know? Al On Mon, 24 Feb 2003 19:55:30 - Dilwyn Jones [EMAIL PROTECTED] writes: I'm working on the 'MyQL' part of Launchpad and I'd like to ask for any additional information can offer on the following. I'd like to compile as complete a list of current directory devices on QL-style systems as possible so that I may provide icons for these devices as required. Obviously, 'default' icons will be available for any 'unknown' devices. The directory devices I am aware of at the moment are: MDV FLP/FDV/FDK (the 3 types of floppy systems over the years) RAM WIN ROM ATR - Atari/DOS disk device IIRC DOS - QPC2 CDR - Thierry's Atapi drivers. NUL - Nul device (+ BLACK_HOLE?) N, M and S - network devices (assuming these count) (DEV, SUB, PTH etc don't count as they could I suppose be anything) Any more known directory device driver names? -- Dilwyn Jones Sign Up for Juno Platinum Internet Access Today Only $9.95 per month! Visit www.juno.com
Re: [ql-users] Directory Devices
} On Mon, 24 Feb 2003 19:55:30 - Dilwyn Jones } [EMAIL PROTECTED] writes: } } I'm working on the 'MyQL' part of Launchpad and I'd like to ask for } any additional information can offer on the following. } } I'd like to compile as complete a list of current directory devices } on } QL-style systems as possible so that I may provide icons for these } devices as required. Obviously, 'default' icons will be available } for } any 'unknown' devices. Because nobody has the same tastes, it might be wiser to simply provides the list of defined icons, and allow an unlimited list of association with any device. Also, being able to 'dynamically' (no recompile or heavy manipulation) add new icons to the list of possible value would be greater! For instance: each icon is a single file in a configurated directory (path set via config block). reference of the icon is made thru the relative filename (that is, really the filename, not the path+filename) each supported device (listed via system calls) has it own icons: - either there is another file with the device name somewhere, which contains the name of the icons to use (but default icons become strange to handle) - or there is a well-known text file which contains a line for each device, and for each device, the name of the icons file. The format of the file is such that the first line MUST be for the default... (unless default is hardcoded, which is bad!) [but does that file format allow comments ?] Of course, instead of filename, other things could be used... Just dreaming...
Re: [ql-users] Directory Devices
Like FDV and FDK there were some interfaces with HDK... Ah, I did not know about this. Although being a hard disk system it would use the same icon as WIN I guess. I think NUL is definitively not a directory device ! It is like CON, SCR, PIPE, NET, MEM, etc... OK. LBYTES EXT2_Marcel_pic,2^17,2^15 loads a picture of Marcel from subdir IMAGES of MDV2 on QL 8 Would we want to load a picture of Marcel from ANY device??? I guess it would have to be hidden quite well ;-) PS: On the QL-PD/CD-R you have a toolkit named TOOLHIT (incl. sources). The proc DIRLIST gives you a list of all installed (directory)device drivers on your QL... have a look :) This might be useful, although I currently use an extension in Norman Dunbar's DJToolkit to read the directory device drivers list. -- Dilwyn Jones
Re: [ql-users] Directory Devices
Hi Dilwyn, What about 'HISTORY'? History might be useful. I have actually never used it myself which is why I did not think of it. But I am not sure if it is a directory device driver as such? There are some devices I am not sure if they qualify as such, perhaps expert opinion on this list could add to this? -- Dilwyn Jones
Re: [ql-users] Directory Devices
I think I have seen it used in a program listing I looked at recently, either from Duncan Neithercutt or George Gwilt, though I can't remember what the program was, probably some kind of screen saver or pointer programming utility, as I was studying some routine or other at the time. -- Dilwyn Jones - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, February 25, 2003 11:15 AM Subject: Re: [ql-users] Directory Devices On 25 Feb 2003 at 10:40, François Van Emelen wrote: Hi Dilwyn, What about 'HISTORY'? I'd be interested to know whether anybody uses that device at all. Wolfgang
Re: [ql-users] Directory Devices
Because nobody has the same tastes, it might be wiser to simply provides the list of defined icons, and allow an unlimited list of association with any device. Also, being able to 'dynamically' (no recompile or heavy manipulation) add new icons to the list of possible value would be greater! This is a good point and will be considered. The way the program is written at the moment it would be major work to allow EACH icon to be specified by the user for each menu etc. Currently, you can specify an inbuilt (large choice) of icons for each program you put on a launchpad program icon, it might be possible to allow Easyptr sprites to be loaded from disk for any given program if none of the built-in ones is suitable. A snga here is that I am having problems with Easyptr when it comes to loading, assigning and displaying sprites, i.e. I can't get that to work at all, it only seems to work if the sprite is an appended one which can be referenced by address, though it should be possible to find the working address of the sprite defintiion and load it there I suppose (back to self-modifying code if the defintiions are built into a program). Current Easyptr extensions don't seem to allow you to refer to a sprite by filename and don't always work reliably with a name of an appended definition! Try (I think it was) MITEM to assign a sprite to a loose item or MINOB to assign an info object and you'll find that you can only reliably get it work with something like the SPRA function to locate the sprite in memory. I had a correspondence with Albin Hessler on the subject last year and all we really managed to confirm was that my original requirements were not possible (something to do with pointers being lost when attempts to refer to sprites by name were made), but using SPRA (i.e. referring to sprites by address) was perfectly reliable. For that reason, Launchpad refers to sprites using SPRA exclusively for now, making it impossible to load sprites unless either working definitions are overwritten or buffers allocated and addresses of sprite definitions passed like that. My memory of this, though, is a bit distant and I might be completely wrong other than to reiterate that there was some problem or other which prevented me dynamically loading sprites. For instance: each icon is a single file in a configurated directory (path set via config block). reference of the icon is made thru the relative filename (that is, really the filename, not the path+filename) I see what you mean, assuming such sprites could be loaded at all (see above) this might be a viable option. Another possibility is that the user can put all his/her personal sprites in a configured directory Windows-style and choose an icon as the desktop icon for that program is set up. Unlike QDT, Launchpad will not have a dedicated loader and will not recognise individual programs as such, you simply specify the executable, specify any DATA_USE, PROG_USE, DEV etc if required (back to KISS principles again). each supported device (listed via system calls) has it own icons: - either there is another file with the device name somewhere, which contains the name of the icons to use (but default icons become strange to handle) - or there is a well-known text file which contains a line for each device, and for each device, the name of the icons file. The format of the file is such that the first line MUST be for the default... (unless default is hardcoded, which is bad!) [but does that file format allow comments ?] Of course, instead of filename, other things could be used... Of course. My fear is of creating a monster I could not control if too many features are added. Keep It Simple Sir. Just dreaming... So am I (of finishing this program!) There are some good ideas in this mail, I will see what I can do, but as the program is already so late (I actually started on it quietly in 2001!) I don't want to do anything too drastic to release 1 to delay it too much. Thanks to you and to everyone else who's sent me so many good ideas for this program over the last few months. Although he hasn't yet seen many of his ideas put into practice because it's some time since I last produced a working version, Darren Branagh has contributed a lot of ideas, even if the Users and MyQL sections have caused me most work! Next thing I need is a good free graphic of a rocket on a Launchpad to use as a skin or BGIMAGE! -- Dilwyn Jones
RE: [ql-users] Directory Devices
For your information Wolfgang I do. I have written a screen mode/size button frame button that changes the screen size/mode on the Q40,Q60,Aurora and stores the current size in a public history device. This enables my screen saver program Nightfall to know the correct screen size/mode to return to when a screen saver animation module needs to be removed. This means that I can write screen saver animation modules that force a display size/mode that is best for their graphical display yet at the twitch of a mouse return to the display suitable for the program I was working on, ie on the Q60 I can be using Xchange on a 512x256 screen, walk away while a series of animations are run at 1024x256 in high colour and with the twitch of the mouse return to 512x256 suitable for Xchange. OR With QCDEZE package there is a stufferstore/GetStufferHistory package that retrieves the current stuffer buffer contents, storing them in a HISTORY device and using a hotkey combination to display the past contents of the stufferbuffer in a qmenu menu to enable mouse selection of items to restuff for alt/space stuffing into whatever one may be working on. Saves a lot of retyping. No doubt there are otherways of doing these things but the humble SMSQ/E history device makes it so easy. Duncan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of [EMAIL PROTECTED] Sent: 25 February 2003 11:16 To: [EMAIL PROTECTED] Subject: Re: [ql-users] Directory Devices On 25 Feb 2003 at 10:40, François Van Emelen wrote: Hi Dilwyn, What about 'HISTORY'? I'd be interested to know whether anybody uses that device at all. Wolfgang
Re: [ql-users] Directory Devices
At 12:15 PM 2/25/2003 +0100, you wrote: On 25 Feb 2003 at 10:40, François Van Emelen wrote: What about 'HISTORY'? I'd be interested to know whether anybody uses that device at all. Wolfgang I use the HISTORY device all the time. I learn about shell history using Unix. The QL History device is more like a DOS version of history (using arrow keys instead of a bang (!) ). I find it useful for repetitive commands that can easily be edited. I would hate to get buy without it. Tim Swenson
