home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / os / os2 / misc / 41500 < prev    next >
Encoding:
Text File  |  1993-01-07  |  2.8 KB  |  58 lines
  1. Newsgroups: comp.os.os2.misc
  2. Path: sparky!uunet!caen!jwh
  3. From: jwh@citi.umich.edu (Jim Howe)
  4. Subject: Re: WORKPLACE SHELL INCONSISTENCY
  5. Message-ID: <Vdd=8-+@engin.umich.edu>
  6. Date: Thu, 07 Jan 93 09:18:42 EST
  7. Organization: IFS Project, University of Michigan
  8. References: <1993Jan5.134559.8611@email.tuwien.ac.at> <93005.164019ASI509@DJUKFA11.BITNET>
  9. Reply-To: jwh@citi.umich.edu
  10. Nntp-Posting-Host: tarkus.citi.umich.edu
  11. Lines: 45
  12.  
  13. In article <93005.164019ASI509@DJUKFA11.BITNET>, ASI509@DJUKFA11.BITNET writes:
  14. |> In article <1993Jan5.134559.8611@email.tuwien.ac.at>,
  15. |> peter@swwwnext.tuwien.ac.at (Peter Wansch) says:
  16. |> >
  17. |> >I recently found one inconsistency in the Workplace Shell concept that is
  18. |> >very confusing and I personally think that IBM should change that. Data
  19. |> >objects and folder objects have a physical representation on the hard
  20. |> >disk, while program objects and device objects are only references to
  21. |> >either an executable file or whatever. Deleting a data object by dragging
  22. |> 
  23. |> I wish program objects an device objects would also have a physical existence
  24. |> in the file system and not only within OS2.INI and/or OS2SYS.INI.
  25. |> Then I would be able to simply drag a bunch of customized program objects to
  26. |> a floppy or Sysquest and move them to another machine.
  27. |>
  28.  
  29. I agree completely.  I recently acquired a new machine and it was a pain
  30. to get the new machine configured like my old machine.  IBM likes to
  31. make the point that the WPS is 'object oriented' and that uses don't
  32. have to worry about where an object physically resides.  Unfortunately
  33. this isn't true.  A user shouldn't have to be aware that there are
  34. file system objects, and non-file system objects.  If a user wants to
  35. move an object from one machine to another, there should be a simple
  36. method to do so.  Ideally, dragging the object to a floppy would be
  37. the most intuitive.  The copying mechanism should be smart enough to
  38. properly reconstruct the object when it gets moved from one machine
  39. to another.  If paths don't exist on the target the system could do
  40. what it does when a path no longer exists on the primary machine, the
  41. object simply won't function.
  42.  
  43. |> This is a no-nonsense application. Consider a huge textmode app like TeX.
  44. |> With some WPS program objects you can build a fairly comfortable shell 
  45. |> within 15 minutes. But you can't transfer it to another machine :-(
  46. |> 
  47.  
  48. Exactly.  Modifications should be made to the standard backup/restore
  49. programs to properly save and recreate objects when they are saved/restored.
  50. The drag and copy operation should be modified to properly handle 
  51. non-file system objects.  The object-oriented nature of the WPS is
  52. great, but it still needs refinement.
  53.  
  54.  
  55. James W. Howe                  internet: jwh@citi.umich.edu
  56. University of Michigan             uucp: uunet!mailrus!citi.umich.edu!jwh
  57. Ann Arbor, MI   48103-4943         
  58.