Submitted by Anonymous on Fri, 11/24/2000 - 13:55. Developers
Well, the sliding menu idea flew like a stone, only 1 comment. So what do people out there consider is missing from Motif that would make it better?? The only suggestion that I can remember seeing is to be able to build with autoconf. Well, that is done and in CVS. Again very little, if any, feedback on this.
One recurring theme I keep hearing about is tool tips. There are many implementations of this around the net, some better than others. Most look and act different. What about implementing this directly into Motif??
Here`s my idea...
Add a few resources to VendorShell to control the tips. Add a resource to Primitive and Gadget to hold the XmNtoolTipString. The default for this resource will be NULL, giving behaviour just like it is now. The actual tip would consist of an overrideShell with an XmLabel in it. There is a delay before the tip is initially displayed, if I know what I`m doing I don`t want to have to see them. However if the tip is currently displayed, which implies that I`m going pretty slow and need some help, if the pointer moves to another position that has a different tip, that tip should be displayed immediately. I don`t want to have to wait to see the help. This implies control somewhere above the individual widget level, and since an application can consist of many VendorShells on different displays I think VendorShell is a good place for the control. This would allow tool tips to be added to any application by adding an XmNtoolTipString resource to any Primitive or Gadget.
What do you think????
I like the idea of ToolTips, and agree with the way you suggest it should be done.
Noting to add on this one.
But!
You ask what is missing from Motif that could make it better?
Surely many things, but one of them is really a dead givaway that Motif has
not been developed for ages
FileSelectionBox
Is it really necessary that I say anything about what FileSelection Boxes on
competitive toolkits can do, and what Motif can not?
I think not.
Just out of amusement - did you notice that it is possible to rename files
in Windows FileSelectionBox, while you are saving a file?
Should anyone want to improve Motif in that direction, I am ready to
help within my time limits and competence.
Dusan
The interface you describe has a small flaw -- once the user starts moving the cursor slowly enough for the first tip to pop up, then tips will continue to pop up as long as the user moves the cursor, no matter how quickly, across other widgets which have your XmNtoolTipString resource. I think the implementations which currently exist, based on timing, work well. Perhaps they could be augmented to check on a particular modifier key; that is, the timeout is reduced to 0, and the tooltip pops up immediately, if the user is pressing e.g. the Alt key while moving across widgets with help information.
Your other comments deal with the implementation of tooltips. It would be better to have the help resource as part of the Primitive/Gadget/Manager resources. (I wonder, though, if that`s enough; the help architecture could use more work.) The real problem in the implementation is handling the events and in turning tooltips on and off. Right now, the supplemental code adds event handlers. If tooltips are integrated into Xm, the widget set can make these calls into Xt. There still needs to be some level of application control, which is simple with the current interfaces but somewhat more difficult with an integrated model; I see storage requirements and the number of function call escalating.
One possible solution which incorporates your idea of having tooltips in the toolkit while keeping the data separate is to embed the notion of toolips into an object. I don`t know that any of the implementations work this way. In short, an object stores the information on the toolTipString. It is created and associated with the widget which should have the tooltip associated with it (resources XmNtoolTipString and XmNtoolTipEnabled, e.g.). That object then becomes the interface for application control of the tooltip; and it handles the events on the target widget.
The solutions that are out there are probably good enough, though, that I`m not sure that the work either of us describes is justified.
I concur. We have a multi-platform librairy that needed tooltip. The windows implementation was fairly easy but the motif one was harder to create. Keeping track of parent widgets, time delay and enter-leave events proved tricky. I am sure that if implemented in motif, it would be a plus.
Have I mentioned yet how much I hate this web interface stuff. I vote we dump this forum crap and start using the OSF developer mailing list!!!!! My last attempt at this apparently got sent to a bit bucket somewhere, so I`ll try again, one more time. It would be _sooooo_ much simpler to hit reply, but no we have to start up a browser........logon........get to the forum.......pick the message......save it to a file.......edit it......paste it back into this stupid little text box......Post Comment.....hope it makes it this time......
Sorry for taking so long to respond, but I`ve been wireless for the
past few days, and since we lack an email interface to these forum
things I haven`t been able to respond. So to avoid the web interface as
much as possible I will respond to all 3 at once.....
Good to see a bit of discussion about this.
> I like the idea of ToolTips, and agree with the way you suggest it
> should be done. Noting to add on this one.
Thanks, I sense a but coming.....
> But!
> You ask what is missing from Motif that could make it better?
> Surely many things, but one of them is really a dead givaway that Motif has
> not been developed for ages
Very true, but we now have the ability to fix that, instead of just
complaining.
> FileSelectionBox
> Is it really necessary that I say anything about what FileSelection Boxes on
> competitive toolkits can do, and what Motif can not?
> I think not.
It is for me ) Maybe I`m an exception, but I kinda like the FSB.
> Just out of amusement - did you notice that it is possible to rename files
> in Windows FileSelectionBox, while you are saving a file?
And you can`t do this with Motif?? If the application pops up a file save
dialog, the FSB returns a name. Nothing in Motif says that the name must
exist. FSB returns a pathname, it is up to the application to know what to
do with it.
> Should anyone want to improve Motif in that direction, I am ready to
> help within my time limits and competence.
>
> Dusan
>
> The interface you describe has a small flaw -- once the user starts
> moving the cursor slowly enough for the first tip to pop up, then tips
> will continue to pop up as long as the user moves the cursor, no matter
> how quickly, across other widgets which have your XmNtoolTipString
This is true. However I consider this a feature, not a flaw. If I have to
wait for tips in order to figure out what those cute little pictures mean
I don`t want to have to wait around for the tip to appear every time I
move.
> resource. I think the implementations which currently exist, based
> on timing, work well. Perhaps they could be augmented to check on a
> particular modifier key; that is, the timeout is reduced to 0, and the
> tooltip pops up immediately, if the user is pressing e.g. the Alt key
> while moving across widgets with help information.
>
> Your other comments deal with the implementation of tooltips. It would be
> better to have the help resource as part of the Primitive/Gadget/Manager
Which is what I described, I think. The actual tip message is part of
Primitive or Gadget, the glue that actually controls it is part of
VendorShell.
> resources. (I wonder, though, if that`s enough; the help architecture
> could use more work.) The real problem in the implementation is handling
> the events and in turning tooltips on and off. Right now, the supplemental
> code adds event handlers. If tooltips are integrated into Xm, the widget
> set can make these calls into Xt. There still needs to be some level
> of application control, which is simple with the current interfaces
> but somewhat more difficult with an integrated model; I see storage
> requirements and the number of function call escalating.
XtVaSetValues(widget, XmNtoolTipString, NULL, NULL);
or simply don`t set the resource in the first place. A Boolean in the Vendor
could be used to globaly turn them on and off. If you are going to store
more information, sotrage space is going up, no matter how you implement it.
The more control you want, the more function calls are needed. Which is
not really true because XtVaSetValues would be the only necessary one.
>
> One possible solution which incorporates your idea of having tooltips in
> the toolkit while keeping the data separate is to embed the notion of
> toolips into an object. I don`t know that any of the implementations
Right, I called that object VendorShell. It contains the smarts to display
a piece of information that a Primitive/Gadget has. Much the same way that
RowColumn controls how Primitives act in a menu.
> work this way. In short, an object stores the information on the
> toolTipString. It is created and associated with the widget which should
> have the tooltip associated with it (resources XmNtoolTipString and
> XmNtoolTipEnabled, e.g.). That object then becomes the interface for
> application control of the tooltip; and it handles the events on the
> target widget.
That sounds very much like I said, only in a different way.
>
> The solutions that are out there are probably good enough, though,
> that I`m not sure that the work either of us describes is justified.
>
> I concur. We have a multi-platform librairy that needed tooltip. The
> windows implementation was fairly easy but the motif one was harder to
> create. Keeping track of parent widgets, time delay and enter-leave events
> proved tricky. I am sure that if implemented in motif, it would be a plus.
That`s the idea...