schaub@sugar.UUCP (Markus Schaub) (11/18/87)
No, not Modula-2 this time. I'm growing from CLI user to a Workbench user
and my programs start to produce icons for their output. I'm doing this
by creating a DiskObject structure, filling all the fields (BTW is there
some documentation except the few sentences from RKM II?) an then writing
this DiskObject to disk. Next time I open the drawer the icon appears.
BUT I'm doing this from floppy, and it is not the only file in the directory.
Is there any way to tell Workbench immediatly that there is a new icon around?
Sending a tiny little secret message to its port? protocol? structures?
Thanx for any help!
--
// Markus Schaub uunet!nuchat!sugar!schaub (713) 523 8422
// M2Amiga Developer trying to get back the money I paid for my
\\ // Amiga by selling a few M2Amiga.
\X/ c/o Interface Technologies Corp, 3336 Richmond #323, Houston Tx 77098carolyn@cbmvax.UUCP (11/19/87)
In article <1076@sugar.UUCP> schaub@sugar.UUCP (Markus Schaub) writes: >[] >Is there any way to tell Workbench immediatly that there is a new icon around? >Sending a tiny little secret message to its port? protocol? structures? >[] No. Workbench only knows immediately about the icons it creates itself. One probable future enhancement will be a way for other programs to tell Workbench to reread a directory and refresh the icons. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Carolyn Scheppner -- CATS >>Commodore Amiga Technical Support<< UUCP ...{allegra,ihnp4,rutgers}!cbmvax!carolyn PHONE 215-431-9180 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
schaub@sugar.UUCP (Markus Schaub) (11/23/87)
In article <2826@cbmvax.UUCP>, carolyn@cbmvax.UUCP (Carolyn Scheppner CATS): >>Is there any way to tell Workbench immediatly that there's a new icon around > One probable future enhancement will be a way for other programs to tell > Workbench to reread a directory and refresh the icons. > > Carolyn Scheppner -- CATS >>Commodore Amiga Technical Support<< Please offer also a faster way then just rereading the directory! To write the icon I have my DiskObject structure already set up, there is no need to wait until Dos found all .info files. Or at least let me tell Workbench to look for 'myicon.info' only. Thanx Carolyn and everybody at CATS for answering questions here! -- // Markus Schaub uunet!nuchat!sugar!schaub (713) 523 8422 // M2Amiga Developer trying to get back the money I paid for my \\ // Amiga by selling a few M2Amiga. \X/ c/o Interface Technologies Corp, 3336 Richmond #323, Houston Tx 77098
peter@sugar.UUCP (Peter da Silva) (11/23/87)
In article <1103@sugar.UUCP>, schaub@sugar.UUCP (Markus Schaub) writes: > In article <2826@cbmvax.UUCP>, carolyn@cbmvax.UUCP (Carolyn Scheppner CATS): > >>Is there any way to tell Workbench immediatly that there's a new icon around > > One probable future enhancement will be a way for other programs to tell > > Workbench to reread a directory and refresh the icons. > > Carolyn Scheppner -- CATS >>Commodore Amiga Technical Support<< > Please offer also a faster way then just rereading the directory! Ditto! Perhaps "PutDiskObject" should give Intuition the new Icon structure you're writing to the disk and the directory lock. It should be able to figure out what to do from there. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- Disclaimer: These U aren't mere opinions... these are *values*.
UH2@PSUVM.BITNET (Lee Sailer) (11/23/87)
About faster .icons.
Shouldn't it be pretty easy to write a *directory sorter* that moves
all the .icon files to the front of the list so that they'd be
the first files found and displayed? (Who me? It'd take me 6 months
just to decide which C compiler to buy.)
lee
cmcmanis%pepper@Sun.COM (Chuck McManis) (11/25/87)
In article <25883UH2@PSUVM> UH2@PSUVM.BITNET (Lee Sailer) writes: >About faster .icons. > >Shouldn't it be pretty easy to write a *directory sorter* that moves >all the .icon files to the front of the list so that they'd be >the first files found and displayed? (Who me? It'd take me 6 months >just to decide which C compiler to buy.) No, because the directorys are not 'sortable'. The directory entries are kept in a hash table for fast initial access. Finding a named file on the Amiga is a very fast operation, finding *all* files is slow because these tables have to be traversed. The only enhancement that I can think of that would be really possible would be to insure that the .icon fileheader was pointed to by the hash entry in the directory blocks hash table. When more than one file name hashes to the same value it stores them 'horizontally' in the hash table via a linked list. Making sure .icon was at the head of this list would insure a minimum number of reads to find it. --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you.
dillon@CORY.BERKELEY.EDU (Matt Dillon) (11/25/87)
>are kept in a hash table for fast initial access. Finding a named >file on the Amiga is a very fast operation, finding *all* files is >slow because these tables have to be traversed. The only enhancement Clarification: Traversing the hash table is fast, but all the directory knows about are file inodes. The file name, size, etc... are all kept in the inodes, which are spread about the disk. inode=header block (my unix background). -Matt
cunniff@hpfclq.HP.COM (Ross Cunniff) (11/25/87)
A better way to speed up the display of icons in a newly opened
directory would be to do one of the following:
1. Add a file called, oh, .info.dir, that contains a
list of the names of all of the .info files in
that directory. This would eliminate the search
through the directory's hash table, and consequently
speed up the workbench.
Or:
2. Completely restructure the Workbench and the info
library, such that .info files are all kept in one
(huge) file; this would eliminate *ALL* directory
searching, as well as potentially reducing the amount
of disk space required (objects with the same icon
image need not have separate copies of the image data;
there is far less 'unused portion of a block' overhead).
The first option has the advantage that it is more compatible with
the current set of tools (ie IconEd); and the documentation and user
habits don't have to be changed drastically. The second option is
*very* different; it could be made somewhat more compatible by
still having the tools, etc. use the .info files, but adding an
option to the Workbench menu to "merge icons".
Anybody up to hacking HackBench to do one of the above?
Ross Cunniff
Hewlett-Packard System Software Operation
...{hplabs,ucbvax}!hpda!cunniff
cunniff%hpda@hplabs.ARPAford@crash.cts.com (Michael Ditto) (11/28/87)
In article <1103@sugar.UUCP> schaub@sugar.UUCP (Markus Schaub) writes: >In article <2826@cbmvax.UUCP>, carolyn@cbmvax.UUCP (Carolyn Scheppner CATS): > >> One probable future enhancement will be a way for other programs to tell >> Workbench to reread a directory and refresh the icons. >> [ ... ] >Please offer also a faster way then just rereading the directory! To write the >icon I have my DiskObject structure already set up, there is no need to wait >until Dos found all .info files. Or at least let me tell Workbench to look >for 'myicon.info' only. While you're giving workbench the ability to communicate, here's an extremely powerful capability that could be added: Have workbench maintain other icons besides the ones read from ".info" files. These icons could be given to workbench be any program, and workbench would notify that program when anything interesting happened to that icon. This seems like something that the workbench's internal routines must already have support for, less the communication aspects. It should be pretty easy for workbench to check the type of an icon when it is double- clicked (or dropped on another one, etc.) and if it is not a ".info" icon, just send a message to a message port associated with that icon, rather than do the normal open/launch. The first application that comes to mind is an "iconify" command for programs that open their own windows. When the user selects "iconify", the program just closes its window, (saving away the bitmap if it wants to), sends a message to workbench, and waits for a reply. The user would see the window be replaced by a small icon that could be moved out of the way like normal workbench icons. When the icon is selected, the program wakes up, opens its window again, and restores its bitmap or refreshes it in the normal way. It sounds like a great user convenience that's consistent with the Amiga user interface, easy for programmers to implement, and doesn't require fundamental changes in workbench. In fact, most of the work involved will be in setting up the method of communication between random programs and workbench, and apparrently, that is happening already. Of course, as with all these "easy, backward compatible improvement" suggestions, SOMEONE will find something wrong with it, so let's hear it! -- Mike Ditto -=] Ford [=- P.O. Box 1721 ford%kenobi@crash.CTS.COM Bonita, CA 92002 ford@crash.CTS.COM
ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) (12/01/87)
In article <2051@crash.cts.com> ford%kenobi@crash.CTS.COM (Michael Ditto) writes: > >While you're giving workbench the ability to communicate, here's an >extremely powerful capability that could be added: Have workbench maintain >other icons besides the ones read from ".info" files. These icons could be >given to workbench be any program, and workbench would notify that program >when anything interesting happened to that icon. > This is called a Gadget. The only difference is that you can't drag gadgets around. However, all is not lost.... >The first application that comes to mind is an "iconify" command for >programs that open their own windows. When the user selects "iconify", >the program just closes its window, (saving away the bitmap if it wants to), >sends a message to workbench, and waits for a reply. [ ... ] Good Grief. I've seen this suggestion so many times, I'm sick of seeing it. Iconification is not Workbench's problem, nor should it be. If you want to iconify your window, then do so. It's possible using the existing system software. In fact, I think I'll put it on my virtual list of things to hack up, just to prove it can be done. Consider this: Suppose Workbench isn't loaded. Under your scheme, everything falls apart. In my view, depending on Workbench for something is not wise, since the probability is high that it won't be there for you. Forgive me; it's late, and I'm tired.... _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ Leo L. Schwab -- The Guy in The Cape ihnp4!ptsfa -\ \_ -_ Recumbent Bikes: dual ---> !{well,unicom}!ewhac O----^o The Only Way To Fly. hplabs / (pronounced "AE-wack") "Work FOR? I don't work FOR anybody! I'm just having fun." -- The Doctor
peter@sugar.UUCP (12/03/87)
Some other things you should be able to do: Drop an icon into any window. This would send an IDCMP message containing a WBMessage structure that would be recieved by shift clicking the icons dropped and double-clicking the application, IF the application has the appropriate IDCMP flags set. Window-ise the workbench. If you can't drag windows off-screen, you should be able to Window-ise the workbench so you can still get to your disk icons even if an unsizable MaxDisplayRows/MaxDisplayCols window was opened over it. This isn't as good as dragging the windows off-screen, though. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- Disclaimer: These U aren't mere opinions... these are *values*.
ford@crash.cts.com (Michael Ditto) (12/06/87)
In article <4593@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes: >In article <2051@crash.cts.com> ford%kenobi@crash.CTS.COM (Michael Ditto) writes: >>The first application that comes to mind is an "iconify" command [ ... ] > Good Grief. I've seen this suggestion so many times, I'm sick of >seeing it. Iconification is not Workbench's problem, nor should it be. If >you want to iconify your window, then do so. It's possible using the >existing system software. In fact, I think I'll put it on my virtual list >of things to hack up, just to prove it can be done. Go for it. I would be impressed. To be consistent with workbench, you should be able to double click it, or to single click it and select "Open" from the workbench menu. Workbench "Info" should work as well. By the way, does putting something on your virtual list of things to hack up prove that it can be done? 8-) 8-) 8-) 8-) > Consider this: Suppose Workbench isn't loaded. Under your scheme, >everything falls apart. In my view, depending on Workbench for something is >not wise, since the probability is high that it won't be there for you. This is a good point, but if workbench were generally useful, more people would use it. I would. > Forgive me; it's late, and I'm tired.... No problem. What would usenet be if people's comments didn't get thrashed about. Natrual selection works on O.S. improvement suggestions, too. -- Mike Ditto -=] Ford [=- P.O. Box 1721 ford%kenobi@crash.CTS.COM Bonita, CA 92002 ford@crash.CTS.COM