Auto-scroll support for NmapOutputViewer (changed from VPaned to HIGVBox)

[ignotus]

Initially I changed the superclass of NmapOutputViewer? to HIGVBox from gtk.VPaned, since I did not see any reason to use adjustable panes. I added support to auto-scroll to NmapOutputViewer? too. The auto-scroll works by default and when the adjustment is down. If the user places the adjustment at any other position the scroll is disabled. However, when the output is changed the adjustment stay on the same place instead jumping to the top (as work before). The patch is attached.

[luis]

it works properly in unix environment (GNU/Linux and Mac OS).

Someone can test it under windows?

[nopper]

I've attached a patch that shows a lesser intrusive scheme to obtain the same result. Works fine on win32.

[nopper]

This add checks that ignotus21 introduced to avoid scrolling to end if the user is seeing another region of scrooledwindow != en

[ignotus]

I tested on Linux (Slackware 12.2) with PyGTK 2.12.1. The patch "scroll-output-2.diff" did not work as expected. It seems that the standard use of marks does not have the right effects.

I talked to nopper and he did not like the "strip()" on the output. I think that there is no reason to show leading whitespaces, but I understand when he said: "the output should be presented as is".

Moreover, as nobody talked about the use of HIGVBox instead VPaned I assume this is ok. I don't know if nopper tested my patch on windows. I can't test it soon on this environment. So, I appreciate if someone else can test it.

[nopper]

Ok my patch seems broken on linux. Btw I rethought the whole structure of the class and I agree with ignotus21 about removing the gtk.VPaned as base class. We should use the gtk.HBox as base class like ignotus21 proposed.

So ignotus remove the .strip() from the patch and should be ok for me.

[gpolo]

Looks good.

Do you really need to do this ?

while (gtk.events_pending() or gtk.gdk.events_pending()): 
    gtk.main_iteration_do(True)

I mean, do you really need to check gtk.gdk.events_pending and block on main_iteration ? Shouldn't the following suffice:

while gtk.events_pending():
    gtk.main_iteration()

?

[ignotus]

The gpolo suggested changes are incorporated and removed the strip() which nopper talk about. Fixed by r4452.

[gpolo]

Reopening as it has been problematic at least under py2exed Windows XP (Umit freezes). I had to comment part of the code that was causing the problem and the auto-scroll no longer works.

[ignotus]

New version

[ignotus]

I attached a new version of the patch (NmapOutputViewer?.py.2.diff) that seems to solve the problem. Now I'm using gtk.Adjustment signals instead all hacks in previous solution. I tested the solution in Linux, Windows XP (both, directly and py2exed version).

I removed some part of code due to redundancy.

420                self.text_buffer.move_mark(self.mark, 
421                                           self.text_buffer.get_start_iter()) 

As self.update_output_colors() is called after, and this function already have this instruction, this quoted code is no longer necessary.

[luis]

Replying to ignotus:

I attached a new version of the patch (NmapOutputViewer?.py.2.diff) that seems to solve the problem. Now I'm using gtk.Adjustment signals instead all hacks in previous solution. I tested the solution in Linux, Windows XP (both, directly and py2exed version). I removed some part of code due to redundancy. {{{ #!python 420 self.text_buffer.move_mark(self.mark, 421 self.text_buffer.get_start_iter()) }}} As self.update_output_colors() is called after, and this function already have this instruction, this quoted code is no longer necessary.

Tested in Linux and Mac OS. It seems work fine

[gpolo]

While it "works fine", I'm feeling uncomfortable while using it. If you have something that generate a large output (something like target: google.com, profile: "quick and verbose scan") and then if you put the scroll somewhere in the middle it acts very weird. I don't know how to express this exactly, maybe you could try redoing these steps and verify.

Reverting this to enhancement.

[ignotus]

New patch (NmapOutputViewer?.py.3.diff) that claims to solve the problems gpolo reported. The scroll jumping caused by gtk.TextBuffer?.set_text() is solved using gtk.TextBuffer?.insert() instead. Now, is not need remember (and apply) the last position of gtk.Adjustment. This patch was tested in Linux and Windows XP (including py2exe version).

[gpolo]

This is getting good, ignotus.

There are two more problems remaining: after a scan finishes, there is a jump to top and then it scrolls down (if the scroll is supposed to go to bottom); the second one is about verifying for scroll at bottom when updating the nmap output, this is problematic because if you leave the scroll anywhere different than bottom, and resize the window (after the scan has finished), it will scroll back to bottom (supposing it was at bottom when scan finished).

I've solved the first problem mentioned simply by removing the go_to_host method, I didn't see how it is useful (but if it turns out to be, then it needs to be fixed).

[getxsick]

Replying to gpolo:

There are two more problems remaining: after a scan finishes, there is a jump to top and then it scrolls down (if the scroll is supposed to go to bottom); the second one is about verifying for scroll at bottom when updating the nmap output, this is problematic because if you leave the scroll anywhere different than bottom, and resize the window (after the scan has finished), it will scroll back to bottom (supposing it was at bottom when scan finished). I've solved the first problem mentioned simply by removing the go_to_host method, I didn't see how it is useful (but if it turns out to be, then it needs to be fixed).

There is still something wrong. I used a case with large output, during the scan set scroll somewhere in the middle. then it looks fine. no jumping. after it finished, when i resize window vertically it works fine. but when i resize window horizontally, there are some jumps of the scroll (a bit up, and down down to the correct position)

[getxsick]

Replying to getxsick:

There is still something wrong. I used a case with large output, during the scan set scroll somewhere in the middle. then it looks fine. no jumping. after it finished, when i resize window vertically it works fine. but when i resize window horizontally, there are some jumps of the scroll (a bit up, and down down to the correct position)

I forgot to add that it only happens if you resize horizontally and output doesn't fix (lines are splitted or unsplitted)

[gpolo]

Indeed getxsick, but as I see this is going to remain as is for the moment at least. At some point we would have to freeze the textview so it doesn't show display updates, and at some point thaw it to starting displaying changes again, but this looks problematic to me.

Regarding the "output doesn't fix", I don't know what you mean, textview already handles this for us automatically -- which is part of the problem but also solves several others that we would have.

[gpolo]

As discussed on IRC, we have entered in an agreement and now I have committed it on r4476.

Thanks for everyone that contributed, the nmap output viewer is in a much better state now. Closing.

[enuavunslug1979]

Is this really the way it suppose to work? By the what could mean error fatal error access to undeclared static property ?