Conference bulova::decw_jan-89_to_nov-90

    V2 does not save icon placement with other "settings".
    
    You still need to "hack".
    
    Where do you place your icons (and how many of them) that
    is preferable to the window manager placement?

The problem is that the windows (and icons) come up in "random" order; it makes
the icon box less easily usable.

I like to have my session manager first, for example. However, I start several
applications both from sm autostart and DECW$LOGIN. Both Banner and VAX Notes
get up their icons before sm. My local terminal fits nicely on the first line
with sm, whereas my remote cluster terminal, along with Banner and Notes, brings
the second line of icons to nearly the same length.

I use large icons for both Mail and Calendar, since they like 2-line icon
titles... so it looks best if they share a line in the box. However, Calendar
starts much more slowly, so FileView beats it out.  The CMS icon originally fits
on the end of the Mail/Calendar line, assuming I log in before 10:00 in the
morning, and there aren't many unread messages.  But both applications expand
their icon titles as necessary, and end up squeezing CMS out the end.  I hate to
have scroll bars on my icon box, so I want CMS on the "next line" with FileView,
from the beginning.

It's not like this requires a fantastic amount of effort; nor do I need to log
in all that often, since I usually just pause the session when I go home.  But
it IS manual effort, every time I log in.  Since the resources exist, and the
whole purpose of a windowing system is that *I* should be in control, it's
really quite absurd that the manual effort is necessary.  I've thought of just
putting all my .iconBoxX/.iconBoxY resources back into my setup files... but
it's a lot harder with V2, since you have to guess at the offsets and fiddle
to get the right place, instead of just counting grid slots.  Anyway, why the
hell should I need to manually guess at pixel offsets when the window manager
already KNOWS where the blasted things are?

There's just really no excuse for NOT allowing easy control over this kind of
stuff!

	/dave

Hi Nancy;

I am using the default icon box geometry.  Under V1, my experience has been that
the window manager tends to add icons across the top of the box (at first, at
least) more or less ignoring the 2nd row (if, when using small icons, you think
of the icon box as having two rows).  By reducing the size of some of my icons
and optimizing their placement across both rows, I was able to leave
considerable room in the box and avoid scroll bars when a lot of short lifetime
icons were present.  The other good effect from this was that the majority of
my icons were always in the same place in the box.

No doubt, the V2 window manager and the change from the "tiled" icon box will
result in more efficiently placed icons.  It may be that my style of icon usage
is not consistent with the way in which they were intended to be used.  Perhaps,
I should try a different geometry and/or experiment more with the V2 behaviour
without any fixed icon placements.

In any case, I now know that V2 is not supposed to do it (i.e., I am not
overlooking something).  Thanks for your response.

Scott

RE: .2 

	Dave, if you copy SMAUG::DAVES_BITSHOP:TRACK.EXE and run that, it'll
	give you the x/y positions that you need to place your stuff. BTW, I
	agree that something better should be done in a future version. I'm
	a wee bit tired with having to re-sort my icon box. I wish there
	was a interface to "edit" the contents and placement..

							mike

    re: .2,.3,.4
    
     noted.
      
    Just a side note, this issue becomes complicated when
    considering multiple DECterms (for instance) - which is only one
    of the reasons why there isn't some real quick simple change
    to support this. 
    
    re: .2
    Incidentally, V1 didnt save the icon positions either.
    Even though we dont *support* editing resource files,
    there is this hack you can do:
    Multiply your old resource settings for iconboxX and iconboxY by 32.
    (Err... the grid units didn't change size on a per unit
    basis.)   Icon pixmaps are either 32x32 or 17x17 so you
    can judge by that too when positioning an icon.

.2

>Anyway, why the hell should I need to manually guess at pixel offsets 
>when the window manager already KNOWS where the blasted things are?

The Motif window manager has nifty things including a real-time dispaly
of window pixels and offsets, that can be turned on or off by the user.

Folks should politely request DECwindows product management to release 
Motif, at least, for internal use.

A few field people and some Motif hackers are in the process of opening
up a conference to discuss Motif.  Stay tuned for details.

Kris..

	Try SMAUG::DAVES_BITSHOP:LOCATOR.*.  

						mike

	And many thanks to Dave Porter who wrote this..

	I am running 5.2 with v2 decw. Am I missing something?

	
%TRACE-W-TRACEBACK, symbolic stack dump follows
module name     routine name                     line       rel PC    abs PC

                                                           000019E1  000019E1
LOCATOR         GRID                                       00000150  0000045C
LOCATOR         LOCATOR                                    00000019  00000287
%SYSTEM-W-PRODNOTINS, optional software product "uVMS Workstation Software" not
installed

	Try copying VMSKIT::SYS$TRANSFER:TRACK.EXE. Sorry, I can't seem
	to find the sources right now..

							mike

re: .5

Thanks for the magic number for conversion from V1 to V2 co-ordinates.

I have changed my icon box geometry to be 168 x 453 (according to
decw$winmgrsave.dat) which, in English, is a rectangle a couple of inches wide
by 5-6 inches in length (sorry, no metric today).  After several hours of using
this set-up, it seems like the small style icons tend to fit together better
with a considerable amount of available space for additional icons.  If I
continue to like this, then my need for fixed placement might be lessened
somewhat.  I still like to have the icons in the same place each time I login
and that is not possible without fixing the position.

(Now I notice that DECterm isn't even saving its screen position properly, so
I'm off to investigate that one...)

re:  last few

I took a quick look at LOCATOR.MAR.  From what I could see using TYPE and HOLD
SCREEN (arrrggh!), it looks like that program was written for VWS.

Scott

    re .8
    

       >  Try SMAUG::DAVES_BITSHOP:LOCATOR.*.  
    
    	And when you've converted it from VWS to DECwindows, please
    	let me have the sources back!
    
    		:-)
                   

YALP   (Yet Another Locator Program)..  JUNO""::POINT.EXE

TRACK.EXE is a "step in the right direction"... although it'd be nice to get the
offset WITHIN THE ICON BOX directly.  Sigh.

As for the comments on Motif... yeah, that'd be nice.  I used the HPWM for a
while, and the popup location window was one of the many really nice features.

As for multiple DECterms... that wouldn't be any problem if CREAT/TERM supported
placing icons!  All it needs is "ICON_X" "ICON_Y" keywords under the /WINDOW
qualifier.

And finally... unfortunately, I can't just convert my old iconBoxX and iconBoxY
resources, since I also shifted around my list of autostart applications when I
brought up V2, and some of the icon names (and therefore sizes) have been
changed to protect the guilty (since I mix icon sizes, the fixed grid always had
some problems anyway, so I could do better manually).  As a result, I need to
lay everything out from scratch.  Tedious, and so far I've managed to convince
myself I've better uses for my time (though we'll see how long that lasts).

	/dave

Actually, *I* am the author of TRACK (my first XLIB program), and I've
since added an icon and an exit mechanism as well.  The source/exe is
available on

doobie""::sys$public:track.*

Directory DOOBIE""::PERFLAB8:[PUBLIC]

TRACK.BIT;2               2  10-APR-1989 11:52:37.00  (RWED,RWED,RE,RE)
TRACK.C;44               10  10-APR-1989 12:32:21.00  (RWED,RWED,RE,RE)
TRACK.EXE;11              9  10-APR-1989 12:32:55.00  (RWED,RWED,RE,RE)
TRACK.EXE;10              9  10-APR-1989 12:32:55.00  (RWED,RWED,RE,RE)
TRACK.LIS;13            749  10-APR-1989 12:32:22.00  (RWED,RWED,RE,RE)
TRACK.OBJ;10              7  10-APR-1989 12:32:22.00  (RWED,RWED,RE,RE)

Total of 6 files, 786 blocks.

Regards,

              == ken miller ==