[bug #3836] As Root, upon Exit, MC chmods /dev/null 600 !

2007-01-03 Thread Roland Illig

Additional Item Attachment, bug #3836 (project mc):

File name: widget.c.patch Size:0 KB


___

Reply to this item at:

  http://savannah.gnu.org/bugs/?3836

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/

___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel


Please, do not post to savannah bug database

2007-01-03 Thread Pavel Tsekov
Hello,

The savannah bug database is currently experiencing some problems and
bug comments are lost. Please, do not post until further notice.

Thanks!

___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel


[PATCH] Help Viewer - mouse issues

2007-01-03 Thread Grigory Trenin

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

2007-01-03 Thread Pavel Tsekov
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

2007-01-03 Thread Pavel Tsekov
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

2007-01-03 Thread Grigory Trenin
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

2007-01-03 Thread Pavel Tsekov
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

2007-01-03 Thread Grigory Trenin
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

2007-01-03 Thread Grigory Trenin
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