home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / sys / amiga / programm / 17642 < prev    next >
Encoding:
Internet Message Format  |  1992-12-21  |  2.6 KB
  1. Path: sparky!uunet!think.com!spool.mu.edu!uwm.edu!ee!bloc1469
  2. From: bloc1469@ee.ee.uwm.edu (Gregory R Block)
  3. Newsgroups: comp.sys.amiga.programmer
  4. Subject: Re: App(Icon|Window) and Style Guide.
  5. Date: 21 Dec 1992 05:33:17 GMT
  6. Organization: Electrical Engineering Dept. University of Wisconsin - Milwaukee
  7. Lines: 52
  8. Distribution: world
  9. Message-ID: <1h3kutINN55t@uwm.edu>
  10. References: <8777@orbit.cts.com> <71913@cup.portal.com> <EfAYvAu00WB_QsSQ1Q@andrew.cmu.edu>
  11. NNTP-Posting-Host: 129.89.2.33
  12.  
  13. In article <EfAYvAu00WB_QsSQ1Q@andrew.cmu.edu> "Edward D. Berger" <eb15+@andrew.cmu.edu> writes:
  14. >the program icon would be: Program
  15. >the AppIcon for program would be: Program.1 or Program_App or ...
  16.  
  17. I agree.  It _SHOULD_ be either a tooltype, or internal to the program.
  18.  
  19. >Having an AppIcon should be a user setting, as I may already have created one
  20. >with ToolManager, and not want to have 2 AppIcons for the same thing.
  21.  
  22. How's this:
  23.  
  24. (APPICON)        No AppIcon
  25. APPICON            Give me an AppIcon with the std. Icon as the image
  26. APPICON=        (The 1.3 version of the above)
  27. APPICON = Sys:Icons/Yow Give me an AppIcon with the image given.  If
  28.                 not found, use the std. icon as the image
  29.  
  30. That's how _I_ think it should work.
  31.  
  32. >I see no great reason to make AppIcons with different borders than standard
  33. >Icons, as I keep the 2 separate.  AppIcons are out in the workbench window,
  34. >while Tool/Project Icons are in their drawers.
  35.  
  36. However, this I disagree with.  And it's because people use the "Leave
  37. Out" option for directories, sometimes.  For instance, I've got
  38. "Prefs" sitting out on my workbench.  I'd like to have visual feedback
  39. that it's not an appicon.
  40.  
  41. The problems come in that without a different visual feedback, you're
  42. telling the user there's no difference between an AppIcon and a std.
  43. icon.  I agree, lets standardize the drop system by making AppIcons
  44. and AppWindows have the "lip".  More importantly, if, someday, C=
  45. decides to make an icon type (when .info files are no more, and
  46. everybody uses 2.0 std. functions for accessing them) that allows
  47. "dropping" onto them (The WB's copy function would simply examine the
  48. icon's type, and if it was of type STD_DropApp, do whatever), that
  49. icon could have a lip too.
  50.  
  51. "lipping" windows and icons should become the standard look for
  52. droppable stuff.  After all, aren't we trying to set a standard with a
  53. style guide?  Let's do it, then, and standardize your own standards.
  54. :)
  55.  
  56. Greg
  57.  
  58.  
  59.  
  60. --
  61. (: (: (: (: Have you overdosed on smileys today?  Why NOT!?! :) :) :) :)
  62. (:   "Commodore has never proven to me, to my satisfaction, that      :)
  63. (:    Marc Barrett is still alive."                   -Wubba :)
  64. (: (: (: (: (: (: (: (: (: (: (: (: () :) :) :) Wubba, the Dark Angel :)
  65.