Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!decwrl!ucbvax!ATHENA.MIT.EDU!njw From: njw@ATHENA.MIT.EDU (Nicholas John Williams) Newsgroups: comp.soft-sys.andrew Subject: Re: Lost styles when cutting&pasting Message-ID: Date: 26 Jul 90 21:58:28 GMT References: <9007261949.AA03459@cadre.dsl.pitt.edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 34 Excerpts from atk: 26-Jul-90 Re: Lost styles when cuttin.. "Maria G. Wadlow"@andrew (1257) > This was a design decision. The original goal of the templates was that > people could either use the default definitions for styles or create > their own definitions. We did not want the system to indiscriminately > override a definition that the user had explicitly put in place. Okay, so it's nice and won't override a user's definition of a style because it will not copy a definition across. However, if the user has not defined that style anyway, then they end up copying across styles which have no attributes defined and the normal user has no way of fixing this (messing with lookz is okay for some people, but the contortions neccessary to edit a style which does not appear on a menu is just too much hassle - users do not want to do this). When copying styles across, I believe the correct action would be to check to see if a style exists. If it does exist, then do nothing (so adhering to the design decision of not overwriting a user's definition), else it *should* add the definition. Excerpts from atk: 26-Jul-90 Re: Lost styles when cuttin.. Sean McLinden@dsl.pitt.e (1837) > This seems like a perfect place (one of many) where the user should be > able to specify a preference. I don't know the validity of this statement > but it seems more likely to me that the user would want to copy an object > with it's attributes *and* values than that they would want to copy an > object with the attributes but the values inherited from the new environment. I'm not sure that it should be a preference - If the code "did the right thing" as I see it above, then there is no need for another preference. Nick.