mayer@hplabsz.HPL.HP.COM (Niels Mayer) (11/16/90)
The documentation I have says absolutely nothing about it. It has some intruiging-sounding resources, such as XmNextensionType with enumerated values XmCACHE_EXTENSION, XmDESKTOP_EXTENSION, XmSHELL_EXTENSION, XmPROTOCOL_EXTENSION, XmDEFAULT_EXTENSION... Things like XmDESKTOP_EXTENSION make me believe this is some kind of undocumented support for drag-n-drop in Motif 1.1 ?? ------------------------------------------------------------------------------- Niels Mayer -- hplabs!mayer -- mayer@hplabs.hp.com Human-Computer Interaction Department Hewlett-Packard Laboratories Palo Alto, CA. *
mayer@hplabsz.HPL.HP.COM (Niels Mayer) (11/16/90)
Further investigation has revealed that (1) I don't know how to spell: In article <6217@hplabsz.HPL.HP.COM> mayer@hplabs.hp.com (Niels Mayer) writes: >It has some intruiging-sounding resources, such as XmNextensionType ^^^^^^^^^^ (I meant intriguing) (2) More evidence to support the claim: >Things like XmDESKTOP_EXTENSION make me believe this is some kind of >undocumented support for drag-n-drop in Motif 1.1 ?? There's also references to the following classes in <Xm/VendorE.h>: xmDesktopObjectClass, xmDisplayObjectClass, xmScreenObjectClass, xmWorldObjectClass. And xmDesktopObjectClass declares a new resource XmNdesktopParent (file Xm/Desktop.c). Answers anybody? ------------------------------------------------------------------------------- Niels Mayer -- hplabs!mayer -- mayer@hplabs.hp.com Human-Computer Interaction Department Hewlett-Packard Laboratories Palo Alto, CA. *
gabe@hpcvlx.cv.hp.com (Gabe Begeddov) (11/22/90)
/ hpcvlx:comp.windows.x.motif / mayer@hplabsz.HPL.HP.COM (Niels Mayer) / 6:57 pm Nov 15, 1990 / Answers anybody? These internal objects were added to support gadget caching and "instance" data that couldn't be added to the instance record due to binary compatability requirements (mostly with VendorShell vs. Xt Shell subclasses). They were also used to thread together shells in terms of the desktop and the style guide. The latter requires that modality be enforced based on hierarchy. The desktop parent is used for this threading up to the level of screen and display. Motif1.1 does not have embedded dragNdrop support. Gabe Beged-Dov Interface Technology Operation Hewlett-Packard Corvallis, Oregon
nazgul@alphalpha.com (Kee Hinckley) (11/24/90)
> These internal objects were added to support gadget caching and "instance" > data that couldn't be added to the instance record due to binary compatability > requirements (mostly with VendorShell vs. Xt Shell subclasses). They were > also used to thread together shells in terms of the desktop and the style guide. > The latter requires that modality be enforced based on hierarchy. The desktop > parent is used for this threading up to the level of screen and display. Maybe I'm missing something. Wouldn't it have been easier to just subclass the Xt widgets and put the info in the subclass? Then hang all the Motif widgets off of the subclass? Now you've got these hidden widgets, you have to worry about when they get deleted (something which is done totally wrong at 1.1 with the result that these psuedo widgets are referenced after being freed). You've got widgets with multiple children when the programmer only expects one. It's really pretty messy, and supporting it has to be a pain. -kee