> Actually, it also worked a couple of days ago: #1121687.
example/cancel that was submitted with the fix for that
bug still works here. Do you have a specific scenario
under which it fails for you (I can actually imagine plenty.
The whole traversal buisness still needs more work,
maybe a whole new widget to decouple CellClip
translation from textChild translations).
Tobias.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> Actually, it also worked a couple of days ago: #1121687.
example/cancel that was submitted with the fix for that
bug still works here. Do you have a specific scenario
under which it fails for you (I can actually imagine plenty.
The whole traversal buisness still needs more work,
maybe a whole new widget to decouple CellClip
translation from textChild translations).
Tobias.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> example/cancel that was submitted with the fix for that
bug still works here.
Here, it works on one computer and doesn't on another one
(they're completely different archs/OS/...; but Xbae and
Motif are the same on both). The one where "cancel" doesn't
work exhibits all kind of funky behaviour: clicking on a
cell copies contents of another one to it etc - typical race
condition symptoms.
BTW, there is no make rule for this example.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK, so it enters the cell back via TraverseInTimeOut().
Zero-timeout, heh? No wonder it produces race conditions.
Notice this callback is added to ClipChild. On the other
hand, Clip has its own FocusIn() action/translation. To make
things even more funny, the primitive's translations field
is set to NULL, instead of XtInheritTranslations (why?). I
was able to solve the problem by setting
XtInheritTranslations (I recalled I did so some time ago
with my Xbae-4.7 copy; so the statement "work fine in 4.7"
is probably incorrect). And defaultTranslations could
probably include entries for pageup/down scrolling.
Overall, I got a strong feeling the traversal stuff may need
a serious cleanup.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I had a peak at the xbae that ships with grace 5.1.18.
Apparently XtInheritTranslations is also NULL there.
On the other hand the 0 timeout is ifdeffed out when
compiled against motif > 1.2. What version of motif
are you using?
Tobias.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
unmap(true) should work now. I also removed the
need for the timeout buisness. Can you tell me
how your racy box likes this version? (And
what ever else I broke)
Tobias.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks, unmap(true) seems to work fine now. The only
remaining problem is that, as a result, the clip child gets
traversal focus, but it hasn't some standard translations,
e.g. osfCancel has no effect (it should propogate it to the
Matrix's parent, I think). In general, Clips are bad
traversal citizens - for example, there is no way to
traverse to the scrollbars.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> The
> only remaining problem is that, as a result, the clip
> child gets traversal focus,
Nope, none of the clips take part in traversal
anymore, all have traversalOn set to false. After
canceledit(true), it's still the textChild that has
the focus, it's just hidden away. (That's how I got
rid of the timeout in the first place: if it's the
textchild (and not a clip) that gets the focus when
entering the matrix, there is no need to call
processtraversal through that mechanism.)
> but it hasn't some
> standard translations, e.g. osfCancel has no
> effect.
Given that it's the textchild that has the focus,
it's the translationIt's installed on it that take
effect. In particular osfCancel will invoke
CancelEdit(True) (unless the matrix is a
descendent of a dialog shell in which case
it's ManagerParentCancel() - undocumented
feature).
> (it should propogate it to the Matrix's
> parent, I think).
I think you're referring to bug #984323 "Xbae
overrides osfCancel key binding". This is
not too hard to solve, I'm just not sure what
the correct way is: Modifying osfCancelACT
to act differently when the matrix is a
descendent of a dialog or adding another
action that gets invoked instead of
ParentManagerCancel when the matrix
is a descendent of a dialogshell.
Also, it is not clear to me what behaviour the
'unmapping' of the textChild should have. There
seem to be contradicting requirements: on the
one hand it would make sense to surrender the
focus after cancel/commitEdit(true). On the
other hand an editCell callback that sets
unmap to true shouldn't surrender the focus
to support 'stelth' mode. I don't like the idea
of having two different kinds of unmapped
states, so right now when unmapped the
matrix enters stelth mode.
> In general, Clips are bad traversal
> citizens -
Well, that's why they are not anymore :)
> for example, there is no way to traverse
> to the scrollbars.
Different problem: the scrollbars are created
with traversalOn set to false (and a 0 highlight
thickness), change that and you can traverse
to them. An option would be to add it as a
resource (ala traverse_fixed).
Tobias.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> I'm just not sure what the correct way is: Modifying
osfCancelACT
> to act differently when the matrix is a descendent of a
dialog or adding
> another action that gets invoked instead of
ParentManagerCancel when
> the matrix is a descendent of a dialogshell.
Well, since XbaeMatrix emulates multiple cell widgets, there
probably should be different actions when the TextField is
in the "single cell" mode and when Matrix looks like a whole
(TextField unmapped). In the case of osfCancel, these should
be (as I see it) CancelEdit(True) and ParentManagerCancel(),
respectively. Similarly, osfDown would translate to
EditCell(Down) and PageDownOrRight(Down) of the scrollbar; etc.
As you see, I suggest that the "global" translations be
always the same as for any standard Motif widget inside a
ScrolledWindow. It's the "cell-gets-a-focus" mode where
alternative translations/actions are allowed.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Logged In: YES
user_id=27019
Actually, it also worked a couple of days ago: #1121687.
Logged In: YES
user_id=101470
> Actually, it also worked a couple of days ago: #1121687.
example/cancel that was submitted with the fix for that
bug still works here. Do you have a specific scenario
under which it fails for you (I can actually imagine plenty.
The whole traversal buisness still needs more work,
maybe a whole new widget to decouple CellClip
translation from textChild translations).
Tobias.
Logged In: YES
user_id=101470
> Actually, it also worked a couple of days ago: #1121687.
example/cancel that was submitted with the fix for that
bug still works here. Do you have a specific scenario
under which it fails for you (I can actually imagine plenty.
The whole traversal buisness still needs more work,
maybe a whole new widget to decouple CellClip
translation from textChild translations).
Tobias.
Logged In: YES
user_id=27019
> example/cancel that was submitted with the fix for that
bug still works here.
Here, it works on one computer and doesn't on another one
(they're completely different archs/OS/...; but Xbae and
Motif are the same on both). The one where "cancel" doesn't
work exhibits all kind of funky behaviour: clicking on a
cell copies contents of another one to it etc - typical race
condition symptoms.
BTW, there is no make rule for this example.
Logged In: YES
user_id=27019
OK, so it enters the cell back via TraverseInTimeOut().
Zero-timeout, heh? No wonder it produces race conditions.
Notice this callback is added to ClipChild. On the other
hand, Clip has its own FocusIn() action/translation. To make
things even more funny, the primitive's translations field
is set to NULL, instead of XtInheritTranslations (why?). I
was able to solve the problem by setting
XtInheritTranslations (I recalled I did so some time ago
with my Xbae-4.7 copy; so the statement "work fine in 4.7"
is probably incorrect). And defaultTranslations could
probably include entries for pageup/down scrolling.
Overall, I got a strong feeling the traversal stuff may need
a serious cleanup.
Logged In: NO
I had a peak at the xbae that ships with grace 5.1.18.
Apparently XtInheritTranslations is also NULL there.
On the other hand the 0 timeout is ifdeffed out when
compiled against motif > 1.2. What version of motif
are you using?
Tobias.
Logged In: YES
user_id=27019
> I had a peak at the xbae that ships with grace 5.1.18.
> Apparently XtInheritTranslations is also NULL there.
I didn't use this functionality in 5.1 (as I wrote earlier,
https://sourceforge.net/tracker/index.php?func=detail&aid=1121106&group_id=31337&atid=401980,
as far as 5.1 is concerned, Xbae is mostly ok now).
http://plasma-gate.weizmann.ac.il/cgi-bin/viewcvs.cgi/grace/Xbae/Xbae/Clip.c?r1=1.1&r2=1.2
> What version of motif are you using?
2.1.30
Logged In: YES
user_id=101470
unmap(true) should work now. I also removed the
need for the timeout buisness. Can you tell me
how your racy box likes this version? (And
what ever else I broke)
Tobias.
Logged In: YES
user_id=27019
Thanks, unmap(true) seems to work fine now. The only
remaining problem is that, as a result, the clip child gets
traversal focus, but it hasn't some standard translations,
e.g. osfCancel has no effect (it should propogate it to the
Matrix's parent, I think). In general, Clips are bad
traversal citizens - for example, there is no way to
traverse to the scrollbars.
Logged In: YES
user_id=101470
> Thanks, unmap(true) seems to work fine now.
Glad to see that works for you.
> The
> only remaining problem is that, as a result, the clip
> child gets traversal focus,
Nope, none of the clips take part in traversal
anymore, all have traversalOn set to false. After
canceledit(true), it's still the textChild that has
the focus, it's just hidden away. (That's how I got
rid of the timeout in the first place: if it's the
textchild (and not a clip) that gets the focus when
entering the matrix, there is no need to call
processtraversal through that mechanism.)
> but it hasn't some
> standard translations, e.g. osfCancel has no
> effect.
Given that it's the textchild that has the focus,
it's the translationIt's installed on it that take
effect. In particular osfCancel will invoke
CancelEdit(True) (unless the matrix is a
descendent of a dialog shell in which case
it's ManagerParentCancel() - undocumented
feature).
> (it should propogate it to the Matrix's
> parent, I think).
I think you're referring to bug #984323 "Xbae
overrides osfCancel key binding". This is
not too hard to solve, I'm just not sure what
the correct way is: Modifying osfCancelACT
to act differently when the matrix is a
descendent of a dialog or adding another
action that gets invoked instead of
ParentManagerCancel when the matrix
is a descendent of a dialogshell.
Also, it is not clear to me what behaviour the
'unmapping' of the textChild should have. There
seem to be contradicting requirements: on the
one hand it would make sense to surrender the
focus after cancel/commitEdit(true). On the
other hand an editCell callback that sets
unmap to true shouldn't surrender the focus
to support 'stelth' mode. I don't like the idea
of having two different kinds of unmapped
states, so right now when unmapped the
matrix enters stelth mode.
> In general, Clips are bad traversal
> citizens -
Well, that's why they are not anymore :)
> for example, there is no way to traverse
> to the scrollbars.
Different problem: the scrollbars are created
with traversalOn set to false (and a 0 highlight
thickness), change that and you can traverse
to them. An option would be to add it as a
resource (ala traverse_fixed).
Tobias.
Logged In: YES
user_id=27019
> I think you're referring to bug #984323
This is related, of course, but not the same.
> I'm just not sure what the correct way is: Modifying
osfCancelACT
> to act differently when the matrix is a descendent of a
dialog or adding
> another action that gets invoked instead of
ParentManagerCancel when
> the matrix is a descendent of a dialogshell.
Well, since XbaeMatrix emulates multiple cell widgets, there
probably should be different actions when the TextField is
in the "single cell" mode and when Matrix looks like a whole
(TextField unmapped). In the case of osfCancel, these should
be (as I see it) CancelEdit(True) and ParentManagerCancel(),
respectively. Similarly, osfDown would translate to
EditCell(Down) and PageDownOrRight(Down) of the scrollbar; etc.
As you see, I suggest that the "global" translations be
always the same as for any standard Motif widget inside a
ScrolledWindow. It's the "cell-gets-a-focus" mode where
alternative translations/actions are allowed.