cmcmanis@stpeter.Sun.COM (Chuck McManis) (01/05/90)
In article UK4H@DKAUNI2.BITNET ("JAE") writes: > Now: what if two programs (independend ones) want to share, say, > a window. Both want to link some private information to the > window. > Unnecessary? Well, I can't think of an application right now, but > I'm almost sure there is one. More than unnecessary, a non-problem. If two independent programs want to share a single window then they damn well better know what the other program is doing to the window and putting in the UserData structure. Now if one independent program wants to "share" the window of another independent program, where that second independent program has no idea it is about to be raped ... well your screwed and for good reason. JAE may not have been thinking about the second case, but a lot of people seem to. My comment to you is KEEP YOUR SLIMY STRUCTURES OFF MY WINDOW. :-) If you can come up with some reasonable operations that should be done on windows, (beyond the currently well defined ones like "go to the front", "change size", and "change position.") I at least would be glad to here about them. Some people seem to want a "change your title" function. --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@Eng.Sun.COM These opinions are my own and no one elses, but you knew that didn't you. "If it didn't have bones in it, it wouldn't be crunchy now would it?!"
peter@cbmvax.commodore.com (Peter Cherna) (01/05/90)
In article <"90-01-04-21:33:00.95*UK4H"@DKAUNI2.BITNET> UK4H@DKAUNI2.BITNET ("JAE") writes: >Hi usenet! (this is my first time here, but who cares...) Welcome. >The recent discussion about mutualExclude striked a chord in me. >One thing that was said (I can't remeber who said it) was about >those 'user' fields in various (all?) intuition/exec etc. structures. >I agree with those who say that one should use these fileds for >one's own purposes instead of using ANY fields in a system struct. > >Now: what if two programs (independend ones) want to share, say, >a window. Both want to link some private information to the >window. >Unnecessary? Well, I can't think of an application right now, but >I'm almost sure there is one. >Anyway, what will happen. Both will user that 'userExt' field >(I don't know real name now). Both will write something to it. >Well, who's last is lucky in that case. The UserData field clearly belongs to the owner of the structure. Which program allocated the structure or opened the window, etc.? ONLY that program has the right to the UserData structure, and may well be using it. Any other independent program has no business using the UserData field. Counterexamples welcome (though I doubt any exist). This would be a good place to reiterate an important point: In general, programs which mess with things that don't belong with them suffer from several problems: 1) The "I hadn't thought of that" syndrome. With the number of Amigas out there, it's only a matter of time before someone has a set-up the author didn't consider. Guru. 2) The software upgrade blues. A user gets the new release of Workbench or some other product, and lo-and-behold, the neat utility stops working. What happened? Something the author of the utility was assuming ain't true anymore in the new version. Guru. Whose fault? Usually the author's. 3) Mix-and-match chaos. Ask a PC owner about combining TSR's (programs like SideKick that stay resident in their computer). Which ones work together? In what order must they be run? Guru. Guru. Guru. From the system end, we try to anticipate the kinds of needs programmers will have, and make those kinds of data and services available in a system-integrated way. If we came up short for your unique application, ask us. We can (and have in the past) provide more features and data in future releases of the OS. If you can't wait, perhaps we can provide a method that you can use today that will still work with the next release. >What I'm thinkin' of is some standard userExtension struct. Just like > > struct userExtension { > struct userExtension *nextExt; > LONG id; > } > >The id field must just be uniq. This would best be accomplished by >providing a (system) function 'AddExtension'. Oh, give a C func head: > > BOOL AddUserExtension(root,userExt); > struct userExtension **root; /*points to the field in struct*/ > struct userExtension *userExt; /*points to node to add*/ One clear problem here is we don't usually have a longword free in most of the structures that are already defined. Many of the structures can't be readily extended for a variety of reasons. We certainly can't change the meaning of any existing UserData fields, at least not without some kind of new flag in the structure which means that this structure's UserData field is the new extensible kind. So a given application could never count on (say) all the windows having this kind, as opposed to the old (keep your hands off) kind. >I'd really like to hear any comments from anyone... Interesting idea, all the same. > bye, JAE > >Juergen A. Erhard >eMail: uk4h@dkauni2.bitnet >phone: (GERMANY) 0721/591602 -- Peter Cherna, Software Engineer, Commodore-Amiga, Inc. {uunet|rutgers}!cbmvax!peter peter@cbmvax.cbm.commodore.com My opinions do not necessarily represent the opinions of my employer.
doug@xdos.UUCP (Doug Merritt) (01/05/90)
In article <129902@sun.Eng.Sun.COM> cmcmanis@sun.UUCP (Chuck McManis) writes: > My comment to you is KEEP YOUR SLIMY STRUCTURES OFF MY WINDOW. :-) > >If you can come up with some reasonable operations that should be done on >windows, (beyond the currently well defined ones like "go to the front", >"change size", and "change position.") I at least would be glad to here >about them. Some people seem to want a "change your title" function. I appreciate that you're taking the Zen position on this, Chuck, but wasn't the bottom line that there wasn't a Zen way to do "change title"??? And I would put it more strongly than "seem to want", I'd say some people "definitely *need*" a change-your-title function. I am very dependent on change-title on my Suns at work, and am about to start using it on my Amiga for consistency. A Zen way to do it would be nice, but I ain't waiting for 1.4 or 1.5...I'll use self modifying code if that's the only way to get what I need! Ah...fortunately that doesn't seem to be needed here. :-) "Pride, hell! Make it work!" "Now *that's* Zen!" :-) Doug -- Doug Merritt {pyramid,apple}!xdos!doug Member, Crusaders for a Better Tomorrow Professional Wildeyed Visionary
UK4H@DKAUNI2.BITNET ("JAE") (01/05/90)
Hi usenet! (this is my first time here, but who cares...)
The recent discussion about mutualExclude striked a chord in me.
One thing that was said (I can't remeber who said it) was about
those 'user' fields in various (all?) intuition/exec etc. structures.
I agree with those who say that one should use these fileds for
one's own purposes instead of using ANY fields in a system struct.
Now: what if two programs (independend ones) want to share, say,
a window. Both want to link some private information to the
window.
Unnecessary? Well, I can't think of an application right now, but
I'm almost sure there is one.
Anyway, what will happen. Both will user that 'userExt' field
(I don't know real name now). Both will write something to it.
Well, who's last is lucky in that case.
What I'm thinkin' of is some standard userExtension struct. Just like
struct userExtension {
struct userExtension *nextExt;
LONG id;
}
The id field must just be uniq. This would best be accomplished by
providing a (system) function 'AddExtension'. Oh, give a C func head:
BOOL AddUserExtension(root,userExt);
struct userExtension **root; /*points to the field in struct*/
struct userExtension *userExt; /*points to node to add*/
Anyone who'd like to use this would define his own extension as s.th.
like:
struct myExt {
struct userExtension extLink;
/*my fields*/
}
Hey, CBM (jim or anyone), are you listening? How about 1.5????
(Yeah, that version blues again...)
Of course this userExt stuff could be a Node (would probably be the
best...)
I'd really like to hear any comments from anyone...
bye, JAE
Juergen A. Erhard
eMail: uk4h@dkauni2.bitnet
phone: (GERMANY) 0721/591602
"You know that it's monday when you wake up and it's tuesday."
Garfieldpeter@sugar.hackercorp.com (Peter da Silva) (01/08/90)
Hey, hell with changing your title... I want to change window menus. Add keyboard shortcuts. Change text. -- Peter "Have you hugged your wolf today" da Silva <peter@sugar.hackercorp.com> `-_-' 'U` "I haven't lost my mind, it's backed up on tape somewhere"