Re: [PATCH] Help Viewer - mouse issues
Hello, On Wed, 2007-01-03 at 23:03, Pavel Tsekov wrote: Hmm. I don't really understand why the '\n' is necessary - and since the code is quite old perhaps noone remebers anymore. I'll play with the code a bit and see if I be able to determine whether the newline is of any importance. I'll see if the changelogs will be of any help too. Ok. I now understand why the newline after the header is necessary. It is there to faciliate the editor of the template file (xnc.hlp). Other than that the newline is really unnecessary. So, I'll keep it there, I'll document it in the node header format and apply a patch to make all help.c functions deal consistently with it. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] Help Viewer - mouse issues
On Tue, 2007-01-09 at 19:08, Grigory Trenin wrote: Pavel Tsekov wrote: Well, we can go with the simple solution for now - but it should be documented somewhere to prevent further confusion. As to whether it is worth the effort - think about this: Me and you together spent a considerable amount of time on a simple issue - was it worth it ? I think making the things right will allow the developer to spend his time on more pressing issues. I am not quite satisfied with that simple solution too. What do you think if I convert xnc.hlp to mandoc format and patch man2hlp respectively? I think it will be sufficient to add to man2hlp support of these two troff commands: 1) '.ce' (to center lines) 2) '.ti' (temporary indent - to support right indention of the first line of the paragraph). Sound nice. Do you have a patch already ? :) Btw. after those changes do you think that xnc.hlp will still be necessary ? P.S. Your help is much appreciated! ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] Help Viewer - mouse issues
Pavel Tsekov wrote: On Tue, 2007-01-09 at 19:08, Grigory Trenin wrote: Pavel Tsekov wrote: I am not quite satisfied with that simple solution too. What do you think if I convert xnc.hlp to mandoc format and patch man2hlp respectively? I think it will be sufficient to add to man2hlp support of these two troff commands: 1) '.ce' (to center lines) 2) '.ti' (temporary indent - to support right indention of the first line of the paragraph). Sound nice. Do you have a patch already ? :) Not yet :) I'm about to make it. Btw. after those changes do you think that xnc.hlp will still be necessary ? xnc.hlp contains information that is not included in the manual page (help's welcome screen, GNU GPL). If we merge xnc.hlp with mc.1.in, that information will be there. This is probably not what desired, so we need some means to exclude it from the manual page. We could put troff's .ex command in the appropriate place of mc.1.in, it will tell troff to stop processing. But it sometimes emits a broken pipe message. Or we could put some magic comment, and at a build time, when mc.1 is generated from mc.1.in, rip everything that follows that magic comment. P.S. Your help is much appreciated Thanks! Wish my help is useful. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] Help Viewer - mouse issues
Pavel Tsekov wrote: Well, we can go with the simple solution for now - but it should be documented somewhere to prevent further confusion. As to whether it is worth the effort - think about this: Me and you together spent a considerable amount of time on a simple issue - was it worth it ? I think making the things right will allow the developer to spend his time on more pressing issues. I am not quite satisfied with that simple solution too. What do you think if I convert xnc.hlp to mandoc format and patch man2hlp respectively? I think it will be sufficient to add to man2hlp support of these two troff commands: 1) '.ce' (to center lines) 2) '.ti' (temporary indent - to support right indention of the first line of the paragraph). Regards, Grigory ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] Help Viewer - mouse issues
On Sat, 6 Jan 2007, Grigory Trenin wrote: Pavel Tsekov wrote: Implementing either solution would not remove the necessity of this: [...] need to revise the help files for all languages, to check if they fit in the window, and fix them if necessary. [...] To fix this there should be no preformatted pages involved, IMO. But I may be wrong. Well, sometimes preformatting is useful. Of course, it shouldn't be used for regular text, as it is used now. But in some nodes config files samples (like mc.menu) are given, and it is necessary to preserve indents and avoid line wraping for them. Besides, man2hlp handles a limited number of groff commands, it doesn't handle .ce command for example, so it is not possible to center lines with man2hlp. It is done by preformatting now. If we decide to eliminate all preformatting, it is necessary to patch man2hlp to center lines. I don't know whether the result will cover the efforts. May be it is easier just to leave that space on the right as is, and make it mouse-clickable? Well, we can go with the simple solution for now - but it should be documented somewhere to prevent further confusion. As to whether it is worth the effort - think about this: Me and you together spent a considerable amount of time on a simple issue - was it worth it ? I think making the things right will allow the developer to spend his time on more pressing issues. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] Help Viewer - mouse issues
On Wed, 2007-01-03 at 23:03, Pavel Tsekov wrote: On Wed, 2007-01-03 at 22:43, Grigory Trenin wrote: Pavel Tsekov wrote: How about fixing help_follow_link() instead ? IMO, this would be a proper fix if we agree that the leading '\n' is not desired. Good point! Certainly, this would be better. The help format documentation says: The hypertext file is a file that may have one or more nodes. Each node ends with a ^D character and starts with a bracket, then the name of the node and then a closing bracket. I don't see anything about the newline being part of the node header and that it needs to be stripped. However, as you noted above if the keyboard is used to follow a link the newline is stripped. So, IMO, either the documentation is buggy and we have to fix it and fix help_follow_link() too or the key handling code is wrong to assume that it has to move beyond the newline. Any thoughts ? It is man2hlp.c who always puts newline after the node header: fprintf (f_out, \004[Contents]\n); ... fprintf (f_out, %c[%s], CHAR_NODE_END, buffer); col++; newline (); Yep. Besides, newlines are also present in the template - xnc.hlp file. It is interesting, however, that move_backward2(), which is called when the up key is pressed, assumes '\n' as a part of the node header, but move_to_top(), which is called when the home key is pressed - doesn't. As for me, I don't like that leading '\n', but it is probably a matter of taste. IMHO it is better to fix help_follow_link(), move_to_top(), and documentation... I don't like it either :) But I'd like to hear from the other people on this list, if possible, before doing anything. If anyone has something to add to this issue it's about time. Otherwise I'll move to fixing this issue one way or the other. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] Help Viewer - mouse issues
On Fri, 2007-01-05 at 02:32, Grigory Trenin wrote: Pavel Tsekov wrote: On Wed, 2007-01-03 at 19:19, Grigory Trenin wrote: This is patch is OK, but there are still problems. See this: create_dlg (0, 0, help_lines + 4, HELP_WINDOW_WIDTH + 4, ^^ HELP_WINDOW_WIDTH already is large enough to hold the dialog frame. As a resylt if you try to click on the right hand side of the dialog you dont get any movement. I'd like to fix this before applying your patch so I can commit both fixes. Unfortunately removing the + 4 part is not enough to properly fix the problem. It seems like man2hlp is producing output with line lengths larget than HELP_TEXT_WIDTH which is incorrect IMO. I'll investigate and let you know what have I found. In the meantime if you want to help me - you are welcome :) So, there are two ways to get rid of that empty space on the right: 1) Shrink the window from 63 chars to HELP_TEXT_WIDTH (58 chars). This will cause some difficulties due to the usage of preformatted text - need to revise the help files for all languages, to check if they fit in the window, and fix them if necessary. 2) Expand HELP_TEXT_WIDTH to the effective window width (63 chars). IMHO this is better. Besides, I think it would be nice to leave a margin in one column between a text and a frame. Should I try and do it? What do you think? Implementing either solution would not remove the necessity of this: [...] need to revise the help files for all languages, to check if they fit in the window, and fix them if necessary. [...] To fix this there should be no preformatted pages involved, IMO. But I may be wrong. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] Help Viewer - mouse issues
Pavel Tsekov wrote: Implementing either solution would not remove the necessity of this: [...] need to revise the help files for all languages, to check if they fit in the window, and fix them if necessary. [...] To fix this there should be no preformatted pages involved, IMO. But I may be wrong. Well, sometimes preformatting is useful. Of course, it shouldn't be used for regular text, as it is used now. But in some nodes config files samples (like mc.menu) are given, and it is necessary to preserve indents and avoid line wraping for them. Besides, man2hlp handles a limited number of groff commands, it doesn't handle .ce command for example, so it is not possible to center lines with man2hlp. It is done by preformatting now. If we decide to eliminate all preformatting, it is necessary to patch man2hlp to center lines. I don't know whether the result will cover the efforts. May be it is easier just to leave that space on the right as is, and make it mouse-clickable? ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] Help Viewer - mouse issues
On Wed, 2007-01-03 at 19:19, Grigory Trenin wrote: 1) mouse-rightbutton.patch Returning to a previous node by pressing right mouse button doesn't work in xterm. It works only in Linux console with GPM. The problem is that help_event() catches only GPM_UP event, and it seems that xterm doesn't report which mouse button was released. Handling GPM_DOWN instead of GPM_UP will fix it. I had this idea now. How about fixing the code that captures mouse events from xterm instead ? I.e. when it receives a mouse down event it will record which key was pressed and it will copy this information to the mouse up event ? I'm CC-ing to the xterm developer just in case he can give some insight. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] Help Viewer - mouse issues
Pavel Tsekov wrote: I had this idea now. How about fixing the code that captures mouse events from xterm instead ? I.e. when it receives a mouse down event it will record which key was pressed and it will copy this information to the mouse up event ? This will be not always reliable. Suppose such situation: a user presses left mouse button, then (without releasing it) presses right mouse button, and finally, he releases one of these buttons. How do we know which button (left or right) was released? ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] Help Viewer - mouse issues
On Thu, 2007-01-04 at 22:33, Grigory Trenin wrote: Pavel Tsekov wrote: I had this idea now. How about fixing the code that captures mouse events from xterm instead ? I.e. when it receives a mouse down event it will record which key was pressed and it will copy this information to the mouse up event ? This will be not always reliable. Suppose such situation: a user presses left mouse button, then (without releasing it) presses right mouse button, and finally, he releases one of these buttons. How do we know which button (left or right) was released? Well, we don't :) But who will do this anyway ? I mean it's pointless :) ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] Help Viewer - mouse issues
Pavel Tsekov wrote: On Wed, 2007-01-03 at 19:19, Grigory Trenin wrote: This is patch is OK, but there are still problems. See this: create_dlg (0, 0, help_lines + 4, HELP_WINDOW_WIDTH + 4, ^^ HELP_WINDOW_WIDTH already is large enough to hold the dialog frame. As a resylt if you try to click on the right hand side of the dialog you dont get any movement. I'd like to fix this before applying your patch so I can commit both fixes. Unfortunately removing the + 4 part is not enough to properly fix the problem. It seems like man2hlp is producing output with line lengths larget than HELP_TEXT_WIDTH which is incorrect IMO. I'll investigate and let you know what have I found. In the meantime if you want to help me - you are welcome :) So, there are two ways to get rid of that empty space on the right: 1) Shrink the window from 63 chars to HELP_TEXT_WIDTH (58 chars). This will cause some difficulties due to the usage of preformatted text - need to revise the help files for all languages, to check if they fit in the window, and fix them if necessary. 2) Expand HELP_TEXT_WIDTH to the effective window width (63 chars). IMHO this is better. Besides, I think it would be nice to leave a margin in one column between a text and a frame. Should I try and do it? What do you think? Regards, Grigory ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[PATCH] Help Viewer - mouse issues
Hello,
Here are 3 patches to the mouse issues in the Help Viewer.
1) mouse-rightbutton.patch
Returning to a previous node by pressing right mouse button
doesn't work in xterm. It works only in Linux console with GPM.
The problem is that help_event() catches only GPM_UP event,
and it seems that xterm doesn't report which mouse button
was released. Handling GPM_DOWN instead of GPM_UP will fix it.
2) mouse-offbytwo.patch
Last two lines of the help window (the bottom line and a frame)
are not mouse-clickable. So the user will not be able to follow
a link with a mouse, if it is situated at the bottom line.
And the frame needs to be clickable because it serves a special
purpose - page scrolling.
3) mouse-linkfollow.patch
When following a link with a mouse, an extra '\n' is insterted
at the top of the window (just follow any link with a keyboard,
then return back, and follow the same link with a mouse,
and you should see the difference).
P.S.
And finally, it would be nice to add mouse auto-repeating and
wheel-scrolling. I don't provide such a patch because I think
it's better to do it after dealing with above issues.
Regards,
Grigory
--- help.c.orig 2006-12-31 02:03:48.0 +0300
+++ help.c 2007-01-03 18:38:51.0 +0300
@@ -474,7 +474,7 @@ help_event (Gpm_Event *event, void *vp)
Widget *w = vp;
Link_Area *current_area;
-if (! (event-type GPM_UP))
+if (! (event-type GPM_DOWN))
return 0;
/* The event is relative to the dialog window, adjust it: */
--- help.c.orig 2006-12-31 02:03:48.0 +0300
+++ help.c 2007-01-03 18:47:50.0 +0300
@@ -840,7 +840,7 @@ interactive_display (const char *filenam
((Widget *) help_bar)-y -= whelp-y;
((Widget *) help_bar)-x -= whelp-x;
-md = mousedispatch_new (1, 1, help_lines, HELP_WINDOW_WIDTH - 2);
+md = mousedispatch_new (1, 1, help_lines + 2, HELP_WINDOW_WIDTH - 2);
add_widget (whelp, md);
add_widget (whelp, help_bar);
--- help.c.orig 2006-12-31 02:03:48.0 +0300
+++ help.c 2007-01-03 18:55:56.0 +0300
@@ -520,7 +520,7 @@ help_event (Gpm_Event *event, void *vp)
history_ptr = (history_ptr+1) % HISTORY_SIZE;
history [history_ptr].page = currentpoint;
history [history_ptr].link = current_area-link_name;
- currentpoint = help_follow_link (currentpoint, current_area-link_name);
+ currentpoint = help_follow_link (currentpoint, current_area-link_name)
+ 1;
selected_item = NULL;
} else{
if (event-y 0)
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] Help Viewer - mouse issues
Hello Grigory, On Wed, 2007-01-03 at 19:19, Grigory Trenin wrote: Here are 3 patches to the mouse issues in the Help Viewer. [...] 3) mouse-linkfollow.patch When following a link with a mouse, an extra '\n' is insterted at the top of the window (just follow any link with a keyboard, then return back, and follow the same link with a mouse, and you should see the difference). [...] How about fixing help_follow_link() instead ? IMO, this would be a proper fix if we agree that the leading '\n' is not desired. The help format documentation says: The hypertext file is a file that may have one or more nodes. Each node ends with a ^D character and starts with a bracket, then the name of the node and then a closing bracket. I don't see anything about the newline being part of the node header and that it needs to be stripped. However, as you noted above if the keyboard is used to follow a link the newline is stripped. So, IMO, either the documentation is buggy and we have to fix it and fix help_follow_link() too or the key handling code is wrong to assume that it has to move beyond the newline. Any thoughts ? ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] Help Viewer - mouse issues
On Wed, 2007-01-03 at 19:19, Grigory Trenin wrote: 2) mouse-offbytwo.patch Last two lines of the help window (the bottom line and a frame) are not mouse-clickable. So the user will not be able to follow a link with a mouse, if it is situated at the bottom line. And the frame needs to be clickable because it serves a special purpose - page scrolling. This is patch is OK, but there are still problems. See this: create_dlg (0, 0, help_lines + 4, HELP_WINDOW_WIDTH + 4, ^^ HELP_WINDOW_WIDTH already is large enough to hold the dialog frame. As a resylt if you try to click on the right hand side of the dialog you dont get any movement. I'd like to fix this before applying your patch so I can commit both fixes. Unfortunately removing the + 4 part is not enough to properly fix the problem. It seems like man2hlp is producing output with line lengths larget than HELP_TEXT_WIDTH which is incorrect IMO. I'll investigate and let you know what have I found. In the meantime if you want to help me - you are welcome :) ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] Help Viewer - mouse issues
Pavel Tsekov wrote: How about fixing help_follow_link() instead ? IMO, this would be a proper fix if we agree that the leading '\n' is not desired. Good point! Certainly, this would be better. The help format documentation says: The hypertext file is a file that may have one or more nodes. Each node ends with a ^D character and starts with a bracket, then the name of the node and then a closing bracket. I don't see anything about the newline being part of the node header and that it needs to be stripped. However, as you noted above if the keyboard is used to follow a link the newline is stripped. So, IMO, either the documentation is buggy and we have to fix it and fix help_follow_link() too or the key handling code is wrong to assume that it has to move beyond the newline. Any thoughts ? It is man2hlp.c who always puts newline after the node header: fprintf (f_out, \004[Contents]\n); ... fprintf (f_out, %c[%s], CHAR_NODE_END, buffer); col++; newline (); Besides, newlines are also present in the template - xnc.hlp file. It is interesting, however, that move_backward2(), which is called when the up key is pressed, assumes '\n' as a part of the node header, but move_to_top(), which is called when the home key is pressed - doesn't. As for me, I don't like that leading '\n', but it is probably a matter of taste. IMHO it is better to fix help_follow_link(), move_to_top(), and documentation... But I remember (it was 2 months ago, I guess) you suggested to rip line wrapping code out of man2hlp and to put it in the Help Viewer... If you still plan to do it, may be it would be better to patch man2hlp.c also not to insert '\n' after the node header... ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] Help Viewer - mouse issues
On Wed, 2007-01-03 at 22:43, Grigory Trenin wrote: Pavel Tsekov wrote: How about fixing help_follow_link() instead ? IMO, this would be a proper fix if we agree that the leading '\n' is not desired. Good point! Certainly, this would be better. The help format documentation says: The hypertext file is a file that may have one or more nodes. Each node ends with a ^D character and starts with a bracket, then the name of the node and then a closing bracket. I don't see anything about the newline being part of the node header and that it needs to be stripped. However, as you noted above if the keyboard is used to follow a link the newline is stripped. So, IMO, either the documentation is buggy and we have to fix it and fix help_follow_link() too or the key handling code is wrong to assume that it has to move beyond the newline. Any thoughts ? It is man2hlp.c who always puts newline after the node header: fprintf (f_out, \004[Contents]\n); ... fprintf (f_out, %c[%s], CHAR_NODE_END, buffer); col++; newline (); Yep. Besides, newlines are also present in the template - xnc.hlp file. It is interesting, however, that move_backward2(), which is called when the up key is pressed, assumes '\n' as a part of the node header, but move_to_top(), which is called when the home key is pressed - doesn't. As for me, I don't like that leading '\n', but it is probably a matter of taste. IMHO it is better to fix help_follow_link(), move_to_top(), and documentation... I don't like it either :) But I'd like to hear from the other people on this list, if possible, before doing anything. But I remember (it was 2 months ago, I guess) you suggested to rip line wrapping code out of man2hlp and to put it in the Help Viewer... If you still plan to do it, may be it would be better to patch man2hlp.c also not to insert '\n' after the node header... Hmm. I don't really understand why the '\n' is necessary - and since the code is quite old perhaps noone remebers anymore. I'll play with the code a bit and see if I be able to determine whether the newline is of any importance. I'll see if the changelogs will be of any help too. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] Help Viewer - mouse issues
Pavel Tsekov wrote: This is patch is OK, but there are still problems. See this: create_dlg (0, 0, help_lines + 4, HELP_WINDOW_WIDTH + 4, ^^ HELP_WINDOW_WIDTH already is large enough to hold the dialog frame. As a resylt if you try to click on the right hand side of the dialog you dont get any movement. I'd like to fix this before applying your patch so I can commit both fixes. Unfortunately removing the + 4 part is not enough to properly fix the problem. It seems like man2hlp is producing output with line lengths larget than HELP_TEXT_WIDTH which is incorrect IMO. I'll investigate and let you know what have I found. In the meantime if you want to help me - you are welcome :) There is some preformatted stuff that is not generated by man2hlp - nodes GNU GENERAL PUBLIC LICENSE, How to use help... I guess that is the problem - it doesn't fit after removing that + 4 part. However, that problem can be solved if we increase the mouse area: -md = mousedispatch_new (1, 1, help_lines, HELP_WINDOW_WIDTH - 2); +md = mousedispatch_new (1, 1, help_lines + 2, HELP_WINDOW_WIDTH + 1); ^^ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: [PATCH] Help Viewer - mouse issues
Pavel Tsekov wrote: It seems like man2hlp is producing output with line lengths larget than HELP_TEXT_WIDTH which is incorrect IMO. In some nodes (eg, Menu File Edit) preformatted text is used (it is marked by .nf tag). In that case man2hlp will output the text as is, without trying to wrap lines, even if it exceeds HELP_TEXT_WIDTH. I think it would be nice for man2hlp to issue a warning if that happens. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
