7:52 a.m.
This patch fixes a problem: focus disappears after pressing Done
in a customize buffer, and does not reappear until a click on
a buffer (focus lost: it was on a "Done" button, destroyed).
The rest, I made usage of tab stops consistent. XEmacs currently
does not make use of this flag, but I felt I had to make it
consistent.
The flag WS_EX_CONTROLPARENT applied to parents, not children.
It affects the behavior of GetNextDlgTabItem. Suppose A,B,C are
children of W, and B1, B2 and B3 are children of B. If all of
the windows are tab stops (WS_TABSTOP), GetNextDlgTabItem
will traverse A,B,C if B does not have the WS_EX_CONTROLPARENT
flag, and A,B1,B2,B3,C if it does.
In mswindows_subwindow_instantiate, this flag is not necessary
as long as its child is STATIC.
Andy (I suppose you wrote the code, did you?), why there are
sandwiches of two windows to represent each widget? If there
is a rationale behind this which I overlook, then it has to be
documented - the code looks quite cryptic now... :)
It is customary in Windows to make all controls accessible equally
using mouse and keyboard. Now, should I click on a widget, there
is no way to move focus away from it using keyboard (neither to
sibling widget nor back to the buffer). Symmetrically there is
no way to activate a widget from a buffer using only keyboard.
I have no idea how to make it better (it's midnight here, and I
haven't been xemacsing for a long time), but this should be
discussed.
Big K
2000-01-12 Kirill 'Big K' Katsnelson <kkm(a)dtmx.com>
* glyphs-msw.c (mswindows_unmap_subwindow): Set focus back to the
frame upon hiding a subwindow.
(mswindows_button_instantiate): Changed the push button style to
BS_PUSHBUTTON.
(mswindows_button_instantiate): Removed button BS_NOTIFY
style.
(mswindows_button_instantiate): Removed redundant check for
a disabled gui item.
(mswindows_button_instantiate): Made use of WS_TABSTOP
consistent: "operable" controls (edit, button, tree, scroll) have
this style, "display-only" ones (static, progress gauge) do
not. This style is currently ignored by XEmacs though. Also,
removed the WS_EX_CONTROLPARENT style - it is not for children,
it is for their parents!
(mswindows_edit_field_instantiate): Ditto.
(mswindows_progress_gauge_instantiate): Ditto.
(mswindows_tree_view_instantiate): Ditto.
(mswindows_tab_control_instantiate): Ditto.
(mswindows_scrollbar_instantiate): Ditto.
(mswindows_combo_box_instantiate): Ditto.
(mswindows_widget_instantiate): Added the WS_EX_CONTROLPARENT
style to the "clip" window.
(mswindows_button_instantiate): Removed compilation warning by
equally typing terms of the ?: operator.
Index: glyphs-msw.c
===================================================================
RCS file: /var/cvsroot/xemacs/src/glyphs-msw.c,v
retrieving revision 1.1.1.1
diff --unified=2 -r1.1.1.1 glyphs-msw.c
--- src/glyphs-msw.c 2000/01/12 07:54:49 1.1.1.1
+++ src/glyphs-msw.c 2000/01/13 07:29:31
＠＠ -2098,4 +2098,5 ＠＠
SWP_HIDEWINDOW | SWP_NOMOVE | SWP_NOSIZE
| SWP_NOSENDCHANGING);
+ SetFocus (GetParent (IMAGE_INSTANCE_MSWINDOWS_CLIPWINDOW (p)));
}
}
＠＠ -2356,5 +2357,5 ＠＠
if ((IMAGE_INSTANCE_MSWINDOWS_CLIPWINDOW (ii)
= CreateWindowEx(
- 0, /* EX flags */
+ WS_EX_CONTROLPARENT, /* EX flags */
XEMACS_CONTROL_CLASS,
0, /* text */
＠＠ -2418,5 +2419,7 ＠＠
struct Lisp_Image_Instance *ii = XIMAGE_INSTANCE (image_instance);
HWND wnd;
- int flags = BS_NOTIFY;
+ int flags = WS_TABSTOP;/* BS_NOTIFY #### is needed to get exotic feedback
+ only. Since we seem to want nothing beyond BN_CLICK,
+ the style is perhaps not necessary -- kkm */
Lisp_Object style;
Lisp_Object gui = IMAGE_INSTANCE_WIDGET_ITEM (ii);
＠＠ -2424,7 +2427,4 ＠＠
Lisp_Object glyph = find_keyword_in_vector (instantiator, Q_image);
- if (!gui_item_active_p (gui))
- flags |= WS_DISABLED;
-
if (!NILP (glyph))
{
＠＠ -2448,9 +2448,11 ＠＠
}
else
- flags |= BS_DEFPUSHBUTTON;
+ {
+ flags |= BS_PUSHBUTTON;
+ }
mswindows_widget_instantiate (image_instance, instantiator, pointer_fg,
- pointer_bg, dest_mask, domain, "BUTTON", flags,
- WS_EX_CONTROLPARENT);
+ pointer_bg, dest_mask, domain, "BUTTON",
+ flags, 0);
wnd = WIDGET_INSTANCE_MSWINDOWS_HANDLE (ii);
＠＠ -2466,7 +2468,7 ＠＠
(WPARAM) (XIMAGE_INSTANCE_MSWINDOWS_BITMAP (glyph) ?
IMAGE_BITMAP : IMAGE_ICON),
- (LPARAM) (XIMAGE_INSTANCE_MSWINDOWS_BITMAP (glyph) ?
- XIMAGE_INSTANCE_MSWINDOWS_BITMAP (glyph) :
- XIMAGE_INSTANCE_MSWINDOWS_ICON (glyph)));
+ (XIMAGE_INSTANCE_MSWINDOWS_BITMAP (glyph) ?
+ (LPARAM) XIMAGE_INSTANCE_MSWINDOWS_BITMAP (glyph) :
+ (LPARAM) XIMAGE_INSTANCE_MSWINDOWS_ICON (glyph)));
}
}
＠＠ -2481,6 +2483,5 ＠＠
pointer_bg, dest_mask, domain, "EDIT",
ES_LEFT | ES_AUTOHSCROLL | WS_TABSTOP
- | WS_BORDER,
- WS_EX_CLIENTEDGE | WS_EX_CONTROLPARENT);
+ | WS_BORDER, WS_EX_CLIENTEDGE);
}
＠＠ -2495,6 +2496,5 ＠＠
mswindows_widget_instantiate (image_instance, instantiator, pointer_fg,
pointer_bg, dest_mask, domain, PROGRESS_CLASS,
- WS_TABSTOP | WS_BORDER | PBS_SMOOTH,
- WS_EX_CLIENTEDGE | WS_EX_CONTROLPARENT);
+ WS_BORDER | PBS_SMOOTH, WS_EX_CLIENTEDGE);
wnd = WIDGET_INSTANCE_MSWINDOWS_HANDLE (ii);
/* set the colors */
＠＠ -2580,5 +2580,5 ＠＠
WS_TABSTOP | WS_BORDER | PBS_SMOOTH
| TVS_HASLINES | TVS_HASBUTTONS,
- WS_EX_CLIENTEDGE | WS_EX_CONTROLPARENT);
+ WS_EX_CLIENTEDGE);
wnd = WIDGET_INSTANCE_MSWINDOWS_HANDLE (ii);
＠＠ -2643,6 +2643,5 ＠＠
pointer_bg, dest_mask, domain, WC_TABCONTROL,
/* borders don't suit tabs so well */
- WS_TABSTOP,
- WS_EX_CONTROLPARENT);
+ WS_TABSTOP, 0);
wnd = WIDGET_INSTANCE_MSWINDOWS_HANDLE (ii);
＠＠ -2708,6 +2707,5 ＠＠
mswindows_widget_instantiate (image_instance, instantiator, pointer_fg,
pointer_bg, dest_mask, domain, "SCROLLBAR",
- 0,
- WS_EX_CLIENTEDGE );
+ WS_TABSTOP, WS_EX_CLIENTEDGE);
}
＠＠ -2740,5 +2738,5 ＠＠
| CBS_AUTOHSCROLL
| CBS_HASSTRINGS | WS_VSCROLL,
- WS_EX_CLIENTEDGE | WS_EX_CONTROLPARENT);
+ WS_EX_CLIENTEDGE);
/* reset the height */
widget_text_to_pixel_conversion (domain,
9:37 a.m.
At 11:52 PM 1/12/00 -0800, Kirill 'Big K' Katsnelson wrote:
This patch fixes a problem: focus disappears after pressing Done
in a customize buffer, and does not reappear until a click on
a buffer (focus lost: it was on a "Done" button, destroyed).
Kirill it is fantastic that someone who actually understands mswindows is
reviewing this code :)
The flag WS_EX_CONTROLPARENT applied to parents, not children.
It affects the behavior of GetNextDlgTabItem. Suppose A,B,C are
children of W, and B1, B2 and B3 are children of B. If all of
the windows are tab stops (WS_TABSTOP), GetNextDlgTabItem
will traverse A,B,C if B does not have the WS_EX_CONTROLPARENT
flag, and A,B1,B2,B3,C if it does.
Ok. I tended to just experiment with flags and leave them in if no problem
was found.
In mswindows_subwindow_instantiate, this flag is not necessary
as long as its child is STATIC.
Ok.
Andy (I suppose you wrote the code, did you?), why there are
sandwiches of two windows to represent each widget? If there
Because you want to be able to clip the widgets and I could find no way of
doing this unless the widget happened to be up against a GUI artifact.
So for instance without this I could not clip widgets that were obscured by
the modeline. I also found that letting the window system clip the widgets
led to some very bad lockups related to event / redisplay cycles.
is a rationale behind this which I overlook, then it has to be
documented - the code looks quite cryptic now... :)
Ok :)
It is customary in Windows to make all controls accessible equally
using mouse and keyboard. Now, should I click on a widget, there
is no way to move focus away from it using keyboard (neither to
sibling widget nor back to the buffer). Symmetrically there is
no way to activate a widget from a buffer using only keyboard.
I have no idea how to make it better (it's midnight here, and I
haven't been xemacsing for a long time), but this should be
discussed.
Right. I have no idea how to do this either.
andy
2000-01-12 Kirill 'Big K' Katsnelson <kkm(a)dtmx.com>
(mswindows_button_instantiate): Removed redundant check for
a disabled gui item.
Why is this redundant?
andy
--------------------------------------------------------------
Dr Andy Piper
Senior Consultant Architect, BEA Systems Ltd
10:14 p.m.
Some time ago, Andy Piper wrote...
>Andy (I suppose you wrote the code, did you?), why there are
>sandwiches of two windows to represent each widget? If there
Because you want to be able to clip the widgets and I could find no way of
doing this unless the widget happened to be up against a GUI artifact.
So for instance without this I could not clip widgets that were obscured by
the modeline. I also found that letting the window system clip the widgets
led to some very bad lockups related to event / redisplay cycles.
Oh, I see. If XEmacs was initially designed as a MSWindows-only program,
then (xemacs) window would be a (Windows) window, and the modeline would be
a separate window - this is why these clipping issues would never arise.
I think that your solution is right.
What I would change is the routing mechanism for WM_COMMAND. Currently,
the message is sent to the clip window, which blindly sends it to
the main window proc, which in turn checks if the message is from a
toolbar, or a menu, or a subwindow. I would instread handle WM_COMMANDs
from subwindows right in the window procedure form the clip window.
2000-01-12 Kirill 'Big K' Katsnelson <kkm(a)dtmx.com>
> (mswindows_button_instantiate): Removed redundant check for
> a disabled gui item.
Why is this redundant?
It calls mswindows_widget_instantiate() which performs the same
check itself.
Big K
8:11 a.m.
At 02:14 PM 1/13/00 -0800, Kirill 'Big K' Katsnelson wrote:
I think that your solution is right.
It was someone else's solution :)
What I would change is the routing mechanism for WM_COMMAND.
Currently,
the message is sent to the clip window, which blindly sends it to
the main window proc, which in turn checks if the message is from a
toolbar, or a menu, or a subwindow. I would instread handle WM_COMMANDs
from subwindows right in the window procedure form the clip window.
Can you expand on this?
andy
--------------------------------------------------------------
Dr Andy Piper
Senior Consultant Architect, BEA Systems Ltd
4:39 a.m.
New subject: keyboard traversal
It's great to see you back, Kirill.
I would really like to see proper keyboard traversal in widgets. (Being
hand-challenged, I sometimes only use the kbd.)
Why can't somebody (Andy or Kirill) implement Lisp functions to traverse to the next
widget in a particular buffer, or to a specified widget? Then we can define
keyboard commands to (a) switch between the last selected widget in a buffer and the
buffer's point; (b) to switch to the next widget; (c) between panes
("windows") in a
frame; and (d) between frames. (We might have to do a bit of work to allow defining
keystrokes in widgets, but probably not much more than passing keyboard events up to
the buffer. The obvious Lisp interface is through the existing glyph extent
keymap.)
We should consult existing Microsoft apps to figure out good bindings.
From Word, I would suggest TAB/Sh-TAB for (b), F6/Sh-F6 for (c), and
Ctrl-F6/Ctrl-Sh-F6 for (d). For (a), either Alt-F6 (undefined in Word), Ctrl-TAB
(and remove the existing binding), or maybe F11 ("go to the next field" in
Word).
Note also, both Front Page and Dev Studio use Ctrl-PgUp/PgDn to select different
tabs, and Dev Studio uses Alt-1/2/3 to select a specific pane. Dev Studio also uses
Ctrl-F6 and Ctrl-TAB interchangeably.
ben
Kirill 'Big K' Katsnelson wrote:
This patch fixes a problem: focus disappears after pressing Done
in a customize buffer, and does not reappear until a click on
a buffer (focus lost: it was on a "Done" button, destroyed).
The rest, I made usage of tab stops consistent. XEmacs currently
does not make use of this flag, but I felt I had to make it
consistent.
The flag WS_EX_CONTROLPARENT applied to parents, not children.
It affects the behavior of GetNextDlgTabItem. Suppose A,B,C are
children of W, and B1, B2 and B3 are children of B. If all of
the windows are tab stops (WS_TABSTOP), GetNextDlgTabItem
will traverse A,B,C if B does not have the WS_EX_CONTROLPARENT
flag, and A,B1,B2,B3,C if it does.
In mswindows_subwindow_instantiate, this flag is not necessary
as long as its child is STATIC.
Andy (I suppose you wrote the code, did you?), why there are
sandwiches of two windows to represent each widget? If there
is a rationale behind this which I overlook, then it has to be
documented - the code looks quite cryptic now... :)
It is customary in Windows to make all controls accessible equally
using mouse and keyboard. Now, should I click on a widget, there
is no way to move focus away from it using keyboard (neither to
sibling widget nor back to the buffer). Symmetrically there is
no way to activate a widget from a buffer using only keyboard.
I have no idea how to make it better (it's midnight here, and I
haven't been xemacsing for a long time), but this should be
discussed.
Big K
2000-01-12 Kirill 'Big K' Katsnelson <kkm(a)dtmx.com>
* glyphs-msw.c (mswindows_unmap_subwindow): Set focus back to the
frame upon hiding a subwindow.
(mswindows_button_instantiate): Changed the push button style to
BS_PUSHBUTTON.
(mswindows_button_instantiate): Removed button BS_NOTIFY
style.
(mswindows_button_instantiate): Removed redundant check for
a disabled gui item.
(mswindows_button_instantiate): Made use of WS_TABSTOP
consistent: "operable" controls (edit, button, tree, scroll) have
this style, "display-only" ones (static, progress gauge) do
not. This style is currently ignored by XEmacs though. Also,
removed the WS_EX_CONTROLPARENT style - it is not for children,
it is for their parents!
(mswindows_edit_field_instantiate): Ditto.
(mswindows_progress_gauge_instantiate): Ditto.
(mswindows_tree_view_instantiate): Ditto.
(mswindows_tab_control_instantiate): Ditto.
(mswindows_scrollbar_instantiate): Ditto.
(mswindows_combo_box_instantiate): Ditto.
(mswindows_widget_instantiate): Added the WS_EX_CONTROLPARENT
style to the "clip" window.
(mswindows_button_instantiate): Removed compilation warning by
equally typing terms of the ?: operator.
Index: glyphs-msw.c
===================================================================
RCS file: /var/cvsroot/xemacs/src/glyphs-msw.c,v
retrieving revision 1.1.1.1
diff --unified=2 -r1.1.1.1 glyphs-msw.c
--- src/glyphs-msw.c 2000/01/12 07:54:49 1.1.1.1
+++ src/glyphs-msw.c 2000/01/13 07:29:31
＠＠ -2098,4 +2098,5 ＠＠
SWP_HIDEWINDOW | SWP_NOMOVE | SWP_NOSIZE
| SWP_NOSENDCHANGING);
+ SetFocus (GetParent (IMAGE_INSTANCE_MSWINDOWS_CLIPWINDOW (p)));
}
}
＠＠ -2356,5 +2357,5 ＠＠
if ((IMAGE_INSTANCE_MSWINDOWS_CLIPWINDOW (ii)
= CreateWindowEx(
- 0, /* EX flags */
+ WS_EX_CONTROLPARENT, /* EX flags */
XEMACS_CONTROL_CLASS,
0, /* text */
＠＠ -2418,5 +2419,7 ＠＠
struct Lisp_Image_Instance *ii = XIMAGE_INSTANCE (image_instance);
HWND wnd;
- int flags = BS_NOTIFY;
+ int flags = WS_TABSTOP;/* BS_NOTIFY #### is needed to get exotic feedback
+ only. Since we seem to want nothing beyond BN_CLICK,
+ the style is perhaps not necessary -- kkm */
Lisp_Object style;
Lisp_Object gui = IMAGE_INSTANCE_WIDGET_ITEM (ii);
＠＠ -2424,7 +2427,4 ＠＠
Lisp_Object glyph = find_keyword_in_vector (instantiator, Q_image);
- if (!gui_item_active_p (gui))
- flags |= WS_DISABLED;
-
if (!NILP (glyph))
{
＠＠ -2448,9 +2448,11 ＠＠
}
else
- flags |= BS_DEFPUSHBUTTON;
+ {
+ flags |= BS_PUSHBUTTON;
+ }
mswindows_widget_instantiate (image_instance, instantiator, pointer_fg,
- pointer_bg, dest_mask, domain, "BUTTON",
flags,
- WS_EX_CONTROLPARENT);
+ pointer_bg, dest_mask, domain, "BUTTON",
+ flags, 0);
wnd = WIDGET_INSTANCE_MSWINDOWS_HANDLE (ii);
＠＠ -2466,7 +2468,7 ＠＠
(WPARAM) (XIMAGE_INSTANCE_MSWINDOWS_BITMAP (glyph) ?
IMAGE_BITMAP : IMAGE_ICON),
- (LPARAM) (XIMAGE_INSTANCE_MSWINDOWS_BITMAP (glyph) ?
- XIMAGE_INSTANCE_MSWINDOWS_BITMAP (glyph) :
- XIMAGE_INSTANCE_MSWINDOWS_ICON (glyph)));
+ (XIMAGE_INSTANCE_MSWINDOWS_BITMAP (glyph) ?
+ (LPARAM) XIMAGE_INSTANCE_MSWINDOWS_BITMAP (glyph) :
+ (LPARAM) XIMAGE_INSTANCE_MSWINDOWS_ICON (glyph)));
}
}
＠＠ -2481,6 +2483,5 ＠＠
pointer_bg, dest_mask, domain, "EDIT",
ES_LEFT | ES_AUTOHSCROLL | WS_TABSTOP
- | WS_BORDER,
- WS_EX_CLIENTEDGE | WS_EX_CONTROLPARENT);
+ | WS_BORDER, WS_EX_CLIENTEDGE);
}
＠＠ -2495,6 +2496,5 ＠＠
mswindows_widget_instantiate (image_instance, instantiator, pointer_fg,
pointer_bg, dest_mask, domain, PROGRESS_CLASS,
- WS_TABSTOP | WS_BORDER | PBS_SMOOTH,
- WS_EX_CLIENTEDGE | WS_EX_CONTROLPARENT);
+ WS_BORDER | PBS_SMOOTH, WS_EX_CLIENTEDGE);
wnd = WIDGET_INSTANCE_MSWINDOWS_HANDLE (ii);
/* set the colors */
＠＠ -2580,5 +2580,5 ＠＠
WS_TABSTOP | WS_BORDER | PBS_SMOOTH
| TVS_HASLINES | TVS_HASBUTTONS,
- WS_EX_CLIENTEDGE | WS_EX_CONTROLPARENT);
+ WS_EX_CLIENTEDGE);
wnd = WIDGET_INSTANCE_MSWINDOWS_HANDLE (ii);
＠＠ -2643,6 +2643,5 ＠＠
pointer_bg, dest_mask, domain, WC_TABCONTROL,
/* borders don't suit tabs so well */
- WS_TABSTOP,
- WS_EX_CONTROLPARENT);
+ WS_TABSTOP, 0);
wnd = WIDGET_INSTANCE_MSWINDOWS_HANDLE (ii);
＠＠ -2708,6 +2707,5 ＠＠
mswindows_widget_instantiate (image_instance, instantiator, pointer_fg,
pointer_bg, dest_mask, domain, "SCROLLBAR",
- 0,
- WS_EX_CLIENTEDGE );
+ WS_TABSTOP, WS_EX_CLIENTEDGE);
}
＠＠ -2740,5 +2738,5 ＠＠
| CBS_AUTOHSCROLL
| CBS_HASSTRINGS | WS_VSCROLL,
- WS_EX_CLIENTEDGE | WS_EX_CONTROLPARENT);
+ WS_EX_CLIENTEDGE);
/* reset the height */
widget_text_to_pixel_conversion (domain,
--
In order to save my hands, I am cutting back on my responses, especially
to XEmacs-related mail. You _will_ get a response, but please be patient.
If you need an immediate response and it is not apparent in your message,
please say so. Thanks for your understanding.
8:24 a.m.
New subject: keyboard traversal
Some time ago, Ben Wing wrote...
Why can't somebody (Andy or Kirill) implement Lisp functions to
traverse to the next
widget in a particular buffer, or to a specified widget? Then we can define
keyboard commands to
I would propose the following keystrokes:
(a) switch between the last selected widget in a buffer and the
buffer's point;
Widget -> Buffer point: ESC probably will do better.
Buffer -> Widget. I can find no analog in Microsoft products. Different hot
keys are used for different widgets. For example, in DevStudio I have 3
drop-downs on different toolbars. The Search for is activated by C-d,
Active project by M-C-p, and the third one does not have a shortcut at all.
I would suggest F4, which often performs actions which can be grouped under
"activate something else" category. For exmaple, in Explorer, F4 selects
Drives drop-down box on the toolbar.
Also, it might be a good idea to implement :hotkey property on widgets,
to get to the right destination in one keystroke.
(b) to switch to the next widget;
TAB next, Sh-TAB previous -- same as Ben proposed
(c) between panes ("windows") in a frame;
F6/Sh-F6 is what is used in MS products. When I used Borland C products some 10
years ago (TTY based), there was Alt (=Meta in Windows) + arrows switch between
panes. I loved it, it was much better that cycle when there are many panes.
and (d) between frames.
Do not know for this one. I would reserve C-F6 and C-Sh-F6 for cycling buffers
in windows. In Windows, they cycle through MDI windows in an application,
MDI is a kind of windows which are decorated like regular top level windows
but all live in another window, which contains nothing more, i.e. is effectively
a desktop-in-a-window for this application. When an MDI window is maximized, it
occupies the whole workspace window, and C-F6 and C-Sh-F6 in this case cycle
through open documents, not changing the appearance otherwise.
In MS Windows, switching between frames is a task of Window manager,Alt-TAB
and Alt-Shift-Tab cycle windows, C-Sh-ESC brings up a listbox to select a
window. I cannot speak for X, but window managers which I used did support
it, except maybe olwm. Do we really need a keystroke to switch between
XEmacs windows?
Big K
10:33 a.m.
New subject: keyboard traversal
OK, I propose:
-- F6 switches between panes.
-- CTRL-F6 switches buffers in a pane. (Equivalent, more or less to switching between
different MDI windows.)
-- ALT-F6 switches between different top-level windows associated with the program. (I
don't want to have
to use ALT-TAB, esp. if I have a lot of other programs active and lots of frames.
ALT-TAB also doesn't move linearly, but back-and-forth. It's also not portable
to
X-based systems.) ALT-F6 is standard in Netscape, Word, and many others.
Four suggestions:
(1) I don't like F4 to switch to widgets. We should try to avoid taking up too much
function-key space.
(2) We could use CTRL-ALT-F6. A bit annoying, but in the same F6 sequence as above.
(3) We could use Shift-TAB.
(4) Note first that CTRL-TAB generally has the meaning of "switch between different
groups of widgets". For example, if you're in the menubar, CTRL-TAB gets you to
the
first toolbar; another CTRL-TAB and you're at the second toolbar; etc. Why don't
we use
CTRL-TAB, then, to go to a widget from a buffer? It's possible a buffer might have
various groups of grouped-together widgets, and then TAB would go from one widget to the
next, while CTRL-TAB in that group goes to the next group. (For now, these groups
don't
seem to exist, and CTRL-TAB behaves like TAB inside a widget.)
-- And ESC to exit from a widget and go back to the buffer.
As to the widget hotkey property, this is a great idea too. First let's try to just
implement the framework to allow us to traverse from one place to another and to bind
keystrokes to widgets. Kirill? Andy?
ben
Kirill 'Big K' Katsnelson wrote:
Some time ago, Ben Wing wrote...
>Why can't somebody (Andy or Kirill) implement Lisp functions to traverse to the
next
>widget in a particular buffer, or to a specified widget? Then we can define
>keyboard commands to
I would propose the following keystrokes:
>(a) switch between the last selected widget in a buffer and the
>buffer's point;
Widget -> Buffer point: ESC probably will do better.
Buffer -> Widget. I can find no analog in Microsoft products. Different hot
keys are used for different widgets. For example, in DevStudio I have 3
drop-downs on different toolbars. The Search for is activated by C-d,
Active project by M-C-p, and the third one does not have a shortcut at all.
I would suggest F4, which often performs actions which can be grouped under
"activate something else" category. For exmaple, in Explorer, F4 selects
Drives drop-down box on the toolbar.
Also, it might be a good idea to implement :hotkey property on widgets,
to get to the right destination in one keystroke.
>(b) to switch to the next widget;
TAB next, Sh-TAB previous -- same as Ben proposed
> (c) between panes ("windows") in a frame;
F6/Sh-F6 is what is used in MS products. When I used Borland C products some 10
years ago (TTY based), there was Alt (=Meta in Windows) + arrows switch between
panes. I loved it, it was much better that cycle when there are many panes.
>and (d) between frames.
Do not know for this one. I would reserve C-F6 and C-Sh-F6 for cycling buffers
in windows. In Windows, they cycle through MDI windows in an application,
MDI is a kind of windows which are decorated like regular top level windows
but all live in another window, which contains nothing more, i.e. is effectively
a desktop-in-a-window for this application. When an MDI window is maximized, it
occupies the whole workspace window, and C-F6 and C-Sh-F6 in this case cycle
through open documents, not changing the appearance otherwise.
In MS Windows, switching between frames is a task of Window manager,Alt-TAB
and Alt-Shift-Tab cycle windows, C-Sh-ESC brings up a listbox to select a
window. I cannot speak for X, but window managers which I used did support
it, except maybe olwm. Do we really need a keystroke to switch between
XEmacs windows?
Big K
--
In order to save my hands, I am cutting back on my responses, especially
to XEmacs-related mail. You _will_ get a response, but please be patient.
If you need an immediate response and it is not apparent in your message,
please say so. Thanks for your understanding.
3:10 p.m.
New subject: keyboard traversal
At 03:33 AM 1/16/00 -0700, Ben Wing wrote:
As to the widget hotkey property, this is a great idea too. First
let's
try to just
implement the framework to allow us to traverse from one place to
another
and to bind
keystrokes to widgets. Kirill? Andy?
I agree this is desirable / necessary, but its going to take me awhile to
get round to it since it comes lower on my list of widget hacking projects.
I anyone else feels like carrying the flame, be my guest .....
andy
--------------------------------------------------------------
Dr Andy Piper
Senior Consultant Architect, BEA Systems Ltd
9023
days inactive
9026
days old
7 comments
3 participants
participants (3)
-
Andy Piper -
Ben Wing -
Kirill 'Big K' Katsnelson