Forum unknown
· Amiga at Work
#WorkBench_Improvements
37 messages in this thread
Ben,
A solution to the scenario you described to Steve:
Make yourself some tiny disk icons (small square boxs) with dinky little
numbers or letters on them. (like the number 32 for instance) Place them
along the top of your workbench screen, just under the title bar. Then
snapshot them in place. Have your CLI open just under the icons, and you'll
always be able to see them.
I do it this way and have icons that are so short they don't even take up a
whole char row. (can almost make out the numbers on them):) Works great!
Especially in interlace where you can afford to give up a little room at the
top of the screen.
Dale
Well, yes and no. If I drag a tool into the workbench so's it becomes
convenient, actually on my "desktop" and out of it's drawer (I _love_ that
metaphor) Then I'm screwed, unless I want to ruin those icons too. Meantime,
I like my HD icons. I have different ones for my removable, my 140, and my
80. Then there are floppy icons. Who's mounted? Who's got a frozen lock? What
about floppies that are new, and so have No_Icon_Position? They line up on
the right, and I can't get at em without ruining my CLI. Microsoft windows
can do it, for Darwins sake, so why can't the Amiga? Bah CBM bug. –Ben–
Right! The "along the top icons" are really only useful for hard disk
icons.
As far as using the workbench as a place to store tool icons.(ick) Try a
drawer full of remote icons. Pop the remote window to the front and click
away! Again no need to resize the cli. You don't have to "reload" after
rebooting ether.
Well, ick to you is yum to me, you know? What do you mean, a drawer full of
remote icons? What's a remote icon? You mean keep em in a drawer on the basis
of high usage or something? That's no good at all. When you move an icon to
the desktop, it remains 'attached' to it's source drawer… that means when
you invoke the tool from the desktop, you _still_ get the subdirectories as
immediate children of the tool, which is an absolute must. If I make a drawer
that has all my common tools in it, then I'll have all the Word Perfect files
in it, my documents, PCB board and block files, telecomm scripts, data base
files (lots!) And a pile of utilities. The way it is now, I can drag what I
want to use, and nothing else, to the desk. I can use em, just like if they
were on a real desk. When I'm done, I can put em back (with NO disk access
time, btw), or, if I have to reboot (like, if I'm so unwise as to use word
perfect) they all appear back in their drawers, organized as I like it. It's
like haveing a manservant clean up your office – _exactly_ as you want it –
while _you_ sleep. No, all I need to be happy here is a CLI that isn't
forgetful. I'm minded to sink my claws into the NewCLI command and do it
myself. –Ben–
Ben,
A remote icon is a project icon which has it's default tool pointing to a
tool of the same name.
To make one: Just make a copy of any tool's .info file and using itype
change it's type to project. To make WB happy make up a 1 byte data file to
go with the icon. Set up the default tool with the WB info screen and you
will have a icon that can be moved almost anywhere and still work. (note I
said almost anywhere. You can't put it in the drawer with it's default tool
unless of course you want to erase the default tool.)
Remote icons don't work with some programs that require data files in the
current dir. But they do work for most things. Sometimes an assignment or two
is needed.
I have a very full drawer of these, whose window sits behind the cli screen
just waiting to be pulled to the front.
Dale
ps: itype.arc was written by Larry and is in lib9
Dale,
By putting all your ICONs in a separate drawer by themselves, you've
just lost the whole idea behind directories. Thou you may have the actual
files in different directories…by placing all the ICONs in a single
directory the user only sees that directory (drawer) when looking for a file.
Don
Don,
By putting all the tools in a single drawer (as Remote Icons) one has
created the visual-interface equivalent of a text-interface 'menu.' I want
to open a single drawer and pick from my TxED+, Flow, Maxiplan, Rolodex, etc.
With one drawer containing icons, I don't have to click and open all over the
place.
There's no reason that an icon has to be in the same 'drawer' as that which
it iconifies. An icon is just a visual handle; and the best location of a
handle is 'close by.'
Tom,
True, an ICON doesn't have to be in the same drawer as it's file, but
the whole idea behind drawers (directories) is to break up files and but the
whole idea behind drawers (directories) is to ogranize your files into
logical segments. For example, if you have 5 text editors/word processors
and 6 terminal programs and 4 BASIC programs and 9 games and 3 spreadsheets
and 8 other types of programs…you'd end up with 35 ICONs in one drawer and
would have to have a large window to see them all (if you can)…but if you
had a drawer named "Text Processing" you could move your 5 text editors (or
their ICONs…whatever) in there, another drawer named "TeleComm" and put the
6 terminal programs there and so on.
These could all be under a single drawer called "Programs", open that
and you'd be confronted with 6 ICONs only, open the one you're interested in
and you'd be confronted with a maximum (under the above setup) of 8 ICONs.
That's much easier to deal with, and much more logical. Do you keep
all your bills, household papers (insurance, etc), correspondence, notes, etc
in a single drawer at home (or at work)? Or do you at least break things
down a bit and keep some stuff one place, and some another so you can find it
easier? That's the whole idea behind directories…to organize your files
into logical sub-units. This applies to the file's ICONs also…they are,
for all intent and purposes, the same as the files themselves as far as the
user of the WB is concerned, because that's the only way the user has of
seeing the files.
If you are only dealing with a floppy with only a few programs, it's
no big deal…but if you are dealing with a HD…you'll quickly overfill a
window with ICONs if you put all of them in a single drawer.
Don
Tom,
True, an ICON doesn't have to be in the same drawer as it's file, but
the whole idea behind drawers (directories) is to break up files and but the
whole idea behind drawers (directories) is to ogranize your files into
logical segments. For example, if you have 5 text editors/word processors
and 6 terminal programs and 4 BASIC programs and 9 games and 3 spreadsheets
and 8 other types of programs…you'd end up with 35 ICONs in one drawer and
would have to have a large window to see them all (if you can)…but if you
had a drawer named "Text Processing" you could move your 5 text editors (or
their ICONs…whatever) in there, another drawer named "TeleComm" and put the
6 terminal programs there and so on.
These could all be under a single drawer called "Programs", open that
and you'd be confronted with 6 ICONs only, open the one you're interested in
and you'd be confronted with a maximum (under the above setup) of 8 ICONs.
That's much easier to deal with, and much more logical. Do you keep
all your bills, household papers (insurance, etc), correspondence, notes, etc
in a single drawer at home (or at work)? Or do you at least break things
down a bit and keep some stuff one place, and some another so you can find it
easier? That's the whole idea behind directories…to organize your files
into logical sub-units. This applies to the file's ICONs also…they are,
for all intent and purposes, the same as the files themselves as far as the
user of the WB is concerned, because that's the only way the user has of
seeing the files.
If you are only dealing with a floppy with only a few programs, it's
no big deal…but if you are dealing with a HD…you'll quickly overfill a
window with ICONs if you put all of them in a single drawer.
Don
Don,
By putting all the tools in a single drawer (as Remote Icons) one has
created the visual-interface equivalent of a text-interface 'menu.' I want
to open a single drawer and pick from my TxED+, Flow, Maxiplan, Rolodex, etc.
With one drawer containing icons, I don't have to click and open all over the
place.
There's no reason that an icon has to be in the same 'drawer' as that which
it iconifies. An icon is just a visual handle; and the best location of a
handle is 'close by.'
Don,
Not sure you understood what I was trying to say. I'm talking about WB
shortcuts, not improvements as the subject header states.
I don't remove the existing icons, just clone them as project icons.
Nothing changes with the exception of a added drawer called remotes. In that
drawer are icons for preferences, IconEd, and other programs that are needed
often.
Instead of opening up DH0: and waiting 10 seconds for WB to display the 20
or so drawers in the root. I keep the remote window hidden under the cli,
which gives me instant access to those common programs. It also helps reduce
the number of times you have to resize the cli to access disk icons hidden
under it. (which is what Ben & I are discussing)
Dale
Dale,
I guess you and I think differently….if you've got a CLI up, why
would you want to pop back to the WB (or a WB drawer) to activate a program?
You mentioned preferences….at a cli prompt it's much easier for me
to type PREFERENCES than it is to grab the mouse, pop the CLI to the back and
then double click on the Preferences ICON. Then when done, pop your remote
window back again and then go back to the CLI.
Don
Dale,
I guess you and I think differently….if you've got a CLI up, why
would you want to pop back to the WB (or a WB drawer) to activate a program?
You mentioned preferences….at a cli prompt it's much easier for me
to type PREFERENCES than it is to grab the mouse, pop the CLI to the back and
then double click on the Preferences ICON. Then when done, pop your remote
window back again and then go back to the CLI.
Don
Don,
Not sure you understood what I was trying to say. I'm talking about WB
shortcuts, not improvements as the subject header states.
I don't remove the existing icons, just clone them as project icons.
Nothing changes with the exception of a added drawer called remotes. In that
drawer are icons for preferences, IconEd, and other programs that are needed
often.
Instead of opening up DH0: and waiting 10 seconds for WB to display the 20
or so drawers in the root. I keep the remote window hidden under the cli,
which gives me instant access to those common programs. It also helps reduce
the number of times you have to resize the cli to access disk icons hidden
under it. (which is what Ben & I are discussing)
Dale
Dale,
By putting all your ICONs in a separate drawer by themselves, you've
just lost the whole idea behind directories. Thou you may have the actual
files in different directories…by placing all the ICONs in a single
directory the user only sees that directory (drawer) when looking for a file.
Don
I have itype – it's indispensabe for those of us who make icons. And the
remote ICON idea is clear to me now – The problem is, as you say, that
programs that expect or understand WB arguments will throw up in varying
shades of green when started that way. And for me, I try to only run programs
that run from WB, since I don't like the CLI particularly. I'm going to fix
the NewCLI command, and that will take care of it for me. When I figure out
the patch, I'll make it available here. –Ben–
Ben, what do you not care for in NewCLI? The hack may already be done.
IT's not in newcli, actually – it's in the window that is opened by newcli –
I want a superbitmap so that the window doesn't lose data when I shrink/grow
it. Gotta hack the kickstart, I think or possibly something on the boot
block, but I doubt it. –Ben–
Ben, what do you not care for in NewCLI? The hack may already be done.
Go for it! I don't mind losing a little chip ram for the refresh feature.
Remember that 1.3 is RSN (I hope) and it comes with the NewCon: device, if
that matters. (Probably not if newcli is the same.) Dale
Actually, newcon: will probably be easy to patch, where the _current_ con:
window code is buried I know not where in the system, at this point. I
dunno how much you'll be losing – the WB screen is only two planes deep,
_and_ it's a 200 line screen as well. That means that you have 16k/plane,
for a total of 32k of chip ram, just for starters to hold the superbitmap.
Then you can add the other window's buffer areas to that. Will be
interesting to see. Of course, the _best_ solution is an 80×24 memory for
the area, with refresh at appropriate times, but that's more than a "patch"
– that's another thing entirely. –Ben–
Actually, newcon: will probably be easy to patch, where the _current_ con:
window code is buried I know not where in the system, at this point. I
dunno how much you'll be losing – the WB screen is only two planes deep,
_and_ it's a 200 line screen as well. That means that you have 16k/plane,
for a total of 32k of chip ram, just for starters to hold the superbitmap.
Then you can add the other window's buffer areas to that. Will be
interesting to see. Of course, the _best_ solution is an 80×24 memory for
the area, with refresh at appropriate times, but that's more than a "patch"
– that's another thing entirely. –Ben–
Go for it! I don't mind losing a little chip ram for the refresh feature.
Remember that 1.3 is RSN (I hope) and it comes with the NewCon: device, if
that matters. (Probably not if newcli is the same.) Dale
I have itype – it's indispensabe for those of us who make icons. And the
remote ICON idea is clear to me now – The problem is, as you say, that
programs that expect or understand WB arguments will throw up in varying
shades of green when started that way. And for me, I try to only run programs
that run from WB, since I don't like the CLI particularly. I'm going to fix
the NewCLI command, and that will take care of it for me. When I figure out
the patch, I'll make it available here. –Ben–
One reason I've been interested in getting ARexx (or any other kind of)
script files selectable from Workbench is to be able to do 'remote' icons. A
tool that needs data files in the default directory could be started by
executing a script file which changes to the directory and then brings in the
program.
Thomas, the new plug program is posted, it now sends io to the little WB
window, like you wnated, automatically instead of having to do the open on
"*". In addition, the source is there. Enjoy. –Ben–
Thomas, the new plug program is posted, it now sends io to the little WB
window, like you wnated, automatically instead of having to do the open on
"*". In addition, the source is there. Enjoy. –Ben–
Yes. AREXX does sound good and I plan on purchasing it soon. Hope my dealer
will be able to order it. If it's available thru distributors there should be
no problem, not sure if they will order it directly from the author thou.
Remote icons are a great help and I use them all the time. Most programs
work with out problem. Even complex things like Access! run just fine from a
remote.
Another nice feature is that a remote can span disks. A person without a
hard drive can build up a collection of remote icons and be prompted with a
requester asking, by vol name, for the disk to insert. Something a very
unorganized friend of mine does.
Dale
Dale, ARexx is distributed by "Southern Technologies", a very large Amiga
distributor – there should be no problems getting it into your dealer, if
he's legit. –Ben–
Yes. AREXX does sound good and I plan on purchasing it soon. Hope my dealer
will be able to order it. If it's available thru distributors there should be
no problem, not sure if they will order it directly from the author thou.
Remote icons are a great help and I use them all the time. Most programs
work with out problem. Even complex things like Access! run just fine from a
remote.
Another nice feature is that a remote can span disks. A person without a
hard drive can build up a collection of remote icons and be prompted with a
requester asking, by vol name, for the disk to insert. Something a very
unorganized friend of mine does.
Dale
One reason I've been interested in getting ARexx (or any other kind of)
script files selectable from Workbench is to be able to do 'remote' icons. A
tool that needs data files in the default directory could be started by
executing a script file which changes to the directory and then brings in the
program.
Ben,
A remote icon is a project icon which has it's default tool pointing to a
tool of the same name.
To make one: Just make a copy of any tool's .info file and using itype
change it's type to project. To make WB happy make up a 1 byte data file to
go with the icon. Set up the default tool with the WB info screen and you
will have a icon that can be moved almost anywhere and still work. (note I
said almost anywhere. You can't put it in the drawer with it's default tool
unless of course you want to erase the default tool.)
Remote icons don't work with some programs that require data files in the
current dir. But they do work for most things. Sometimes an assignment or two
is needed.
I have a very full drawer of these, whose window sits behind the cli screen
just waiting to be pulled to the front.
Dale
ps: itype.arc was written by Larry and is in lib9
Well, ick to you is yum to me, you know? What do you mean, a drawer full of
remote icons? What's a remote icon? You mean keep em in a drawer on the basis
of high usage or something? That's no good at all. When you move an icon to
the desktop, it remains 'attached' to it's source drawer… that means when
you invoke the tool from the desktop, you _still_ get the subdirectories as
immediate children of the tool, which is an absolute must. If I make a drawer
that has all my common tools in it, then I'll have all the Word Perfect files
in it, my documents, PCB board and block files, telecomm scripts, data base
files (lots!) And a pile of utilities. The way it is now, I can drag what I
want to use, and nothing else, to the desk. I can use em, just like if they
were on a real desk. When I'm done, I can put em back (with NO disk access
time, btw), or, if I have to reboot (like, if I'm so unwise as to use word
perfect) they all appear back in their drawers, organized as I like it. It's
like haveing a manservant clean up your office – _exactly_ as you want it –
while _you_ sleep. No, all I need to be happy here is a CLI that isn't
forgetful. I'm minded to sink my claws into the NewCLI command and do it
myself. –Ben–
Right! The "along the top icons" are really only useful for hard disk
icons.
As far as using the workbench as a place to store tool icons.(ick) Try a
drawer full of remote icons. Pop the remote window to the front and click
away! Again no need to resize the cli. You don't have to "reload" after
rebooting ether.
Well, yes and no. If I drag a tool into the workbench so's it becomes
convenient, actually on my "desktop" and out of it's drawer (I _love_ that
metaphor) Then I'm screwed, unless I want to ruin those icons too. Meantime,
I like my HD icons. I have different ones for my removable, my 140, and my
80. Then there are floppy icons. Who's mounted? Who's got a frozen lock? What
about floppies that are new, and so have No_Icon_Position? They line up on
the right, and I can't get at em without ruining my CLI. Microsoft windows
can do it, for Darwins sake, so why can't the Amiga? Bah CBM bug. –Ben–