NessusClient: Planned improvements

[Jan-Oliver Wagner]

Hello Nessus developers,

in order to prevent double work or uncoordinated work,
I though I drop a note on what I am currently (slowly!)
working on:

- Migrating monitor dialog to TreeView widget.
Why: Current widget are marked deprecated. Also,
it opens the opportunity to take advantage of the
tree structure in order to aggregate domains.
My current issues:
- Progressbar cell renderer is only introduced
in GTK+ 2.6. I can ifdef the code to have the
new monitor dialog appear only for GTK >= 2.6.
Alternatively it could be decided to raise minimum
version of GTK+ to 2.6.
- There is no cell renderer for button. Alternatives are:
- Toggle is used and once switch on, the host is stopped
and vanishes from the list
- Our own cell renderer for button is implemented.
- The "Stop" functionality is removed or realized
in a different way.

- Implementing a memory-side Plugin-Description cache.
Why: Memory consumption is currently high if you have
switched on all the caching. Same plugins are kept in memory
multiple times. Several strings are cached and some are zipped,
but I think a real cache would lower memory consumption
considerably.
Issues: none so far. I just proceed on implementing this.

Please let me know if you have any comments. Espcially
let me know if anyone is already planning changes in the same
areas or in a way that would influence my current work.

All the best

Jan

[Renaud Deraison]

Hello Jan-Olivier,

Post by Jan-Oliver Wagner
Hello Nessus developers,
in order to prevent double work or uncoordinated work,
I though I drop a note on what I am currently (slowly!)
- Migrating monitor dialog to TreeView widget.

[...]

I'd like to see a sample of what this would look like before you
commit anything in that regards. The current view is working properly
so I'm not convinced at all for a need to change this view.

Post by Jan-Oliver Wagner
- Implementing a memory-side Plugin-Description cache.

I think we can/should dramatically lower the memory consumption by
not storing the plugins descriptions at all. Of course, we need to
cache the plugins names / families / etc... but I'd do away with the
description entirely and remove the ability to click on a plugin name
to see what report it could produce (does anyone use this ?).

This could also be used to log into a Nessus server much more quickly.


Thanks,

-- Renaud

[Jan-Oliver Wagner]

Post by Renaud Deraison

Post by Jan-Oliver Wagner
in order to prevent double work or uncoordinated work,
I though I drop a note on what I am currently (slowly!)
- Migrating monitor dialog to TreeView widget.

[...]
I'd like to see a sample of what this would look like before you
commit anything in that regards. The current view is working properly
so I'm not convinced at all for a need to change this view.

Attached is monitor_dialog.c where I implemented the new TreeView.
It is a test version where it is integrated into the dialog additionally
to the old style.
The width is currently determined by the old style. The widths of
the columns could be adjusted.

Attached also is a sample screenshot.

I have not yet applied real tree structures for the hosts, but
it is possible in principle.
Additionally the consumption of vertical
space is much lower and there is a percentage information for
the progress bars.
For the time being I implemented the "Stop" funtionality using
a toggle cell renderer, because this was just really quick and
simple.

Best

Jan

[Jan-Oliver Wagner]

Hello,

no comment means OK to proceed?

Post by Jan-Oliver Wagner

Post by Renaud Deraison

Post by Jan-Oliver Wagner
in order to prevent double work or uncoordinated work,
I though I drop a note on what I am currently (slowly!)
- Migrating monitor dialog to TreeView widget.

[...]
I'd like to see a sample of what this would look like before you
commit anything in that regards. The current view is working properly
so I'm not convinced at all for a need to change this view.

Attached is monitor_dialog.c where I implemented the new TreeView.
It is a test version where it is integrated into the dialog additionally
to the old style.
The width is currently determined by the old style. The widths of
the columns could be adjusted.
Attached also is a sample screenshot.
I have not yet applied real tree structures for the hosts, but
it is possible in principle.
Additionally the consumption of vertical
space is much lower and there is a percentage information for
the progress bars.
For the time being I implemented the "Stop" funtionality using
a toggle cell renderer, because this was just really quick and
simple.

Best

Jan

[Renaud Deraison]

No. I'm not sure I understand the benefits of changing something
which is working fine today by something else whose design has not
even been finalized yet -- if it's not broken, don't fix it.

Post by Jan-Oliver Wagner
Hello,
no comment means OK to proceed?

Post by Jan-Oliver Wagner

Post by Renaud Deraison

Post by Jan-Oliver Wagner
in order to prevent double work or uncoordinated work,
I though I drop a note on what I am currently (slowly!)
- Migrating monitor dialog to TreeView widget.

[...]
I'd like to see a sample of what this would look like before you
commit anything in that regards. The current view is working
properly
so I'm not convinced at all for a need to change this view.

Attached is monitor_dialog.c where I implemented the new TreeView.
It is a test version where it is integrated into the dialog
additionally
to the old style.
The width is currently determined by the old style. The widths of
the columns could be adjusted.
Attached also is a sample screenshot.
I have not yet applied real tree structures for the hosts, but
it is possible in principle.
Additionally the consumption of vertical
space is much lower and there is a percentage information for
the progress bars.
For the time being I implemented the "Stop" funtionality using
a toggle cell renderer, because this was just really quick and
simple.

Best
Jan
_______________________________________________
Nessus-devel mailing list
http://mail.nessus.org/mailman/listinfo/nessus-devel

[Jan-Oliver Wagner]

Post by Renaud Deraison
No. I'm not sure I understand the benefits of changing something
which is working fine today by something else whose design has not
even been finalized yet -- if it's not broken, don't fix it.

it is not broken. But it can be improved (my patch it is not just a fix).

And it is not finalized because you asked for some details,
so I just send the current status (clearly marked as such)
of my work.

Post by Renaud Deraison

Post by Jan-Oliver Wagner
Hello,
no comment means OK to proceed?

Post by Jan-Oliver Wagner

Post by Renaud Deraison

Post by Jan-Oliver Wagner
in order to prevent double work or uncoordinated work,
I though I drop a note on what I am currently (slowly!)
- Migrating monitor dialog to TreeView widget.

[...]
I'd like to see a sample of what this would look like before you
commit anything in that regards. The current view is working properly
so I'm not convinced at all for a need to change this view.

Attached is monitor_dialog.c where I implemented the new TreeView.
It is a test version where it is integrated into the dialog
additionally
to the old style.
The width is currently determined by the old style. The widths of
the columns could be adjusted.
Attached also is a sample screenshot.
I have not yet applied real tree structures for the hosts, but
it is possible in principle.
Additionally the consumption of vertical
space is much lower and there is a percentage information for
the progress bars.
For the time being I implemented the "Stop" funtionality using
a toggle cell renderer, because this was just really quick and
simple.

[Renaud Deraison]

Post by Jan-Oliver Wagner

Post by Renaud Deraison
No. I'm not sure I understand the benefits of changing something
which is working fine today by something else whose design has not
even been finalized yet -- if it's not broken, don't fix it.

it is not broken. But it can be improved (my patch it is not just a fix).
And it is not finalized because you asked for some details,
so I just send the current status (clearly marked as such)
of my work.

I'm not opposed to it, but let's define a final design before
anything is done -- you talk about tree view and I don't see where
you want to fit them, etc...



-- Renaud

[Jan-Oliver Wagner]

Post by Renaud Deraison

Post by Jan-Oliver Wagner

Post by Renaud Deraison
No. I'm not sure I understand the benefits of changing something
which is working fine today by something else whose design has not
even been finalized yet -- if it's not broken, don't fix it.

it is not broken. But it can be improved (my patch it is not just a fix).
And it is not finalized because you asked for some details,
so I just send the current status (clearly marked as such)
of my work.

I'm not opposed to it, but let's define a final design before
anything is done -- you talk about tree view and I don't see where
you want to fit them, etc...

a GTK TreeView can have a list or a tree model.
For a first step I planned to use a list model for the monitor dialog.
Eventually a tree model could be used. But that's beyond the currently
implemented concept and I could imagine different ways how
this might work. Probably it is best to ask for some user feedback before
beginning to plan this.

However, even with a list model, the TreeView has some advantages over
the current implementation:

- not using deprecated methods anymore
- clearer code due to MVC
- progress bar additionally shows %tage
- vertical space consumption much lower
- personal opinion: looks nicer (more modern)
- sortable columns (not yet used in my code. Should I implement
that clicking on a head line makes this the sorted column,
a second click make it sorted reversed? This would be a pretty
common behaviour today in many GUIs.)

Except for the the sortable-question my sample already shows
the final (list) design. Some beautification remains of course
and the old widget needs to be removed, naturally.

I do not expect instability due to my changes because actually
the same hooks for communication with Nessus Server are
just called in a different way.

Best

Jan

[Jan-Oliver Wagner]

Hello,

I forgot one aspect: at least the progress bar is
only available since GTK+ 2.6.
So, I need to implement some ifdefs (or similar)
to apply the current style for GTK+ < 2.6 and
the new style for GTK+ >= 2.6.

At least unless we might increase the requirement
for GTK+ from 2.4 to 2.6 ;-)

Best

Jan

Post by Jan-Oliver Wagner

Post by Renaud Deraison

Post by Jan-Oliver Wagner

Post by Renaud Deraison
No. I'm not sure I understand the benefits of changing something
which is working fine today by something else whose design has not
even been finalized yet -- if it's not broken, don't fix it.

it is not broken. But it can be improved (my patch it is not just a fix).
And it is not finalized because you asked for some details,
so I just send the current status (clearly marked as such)
of my work.

I'm not opposed to it, but let's define a final design before
anything is done -- you talk about tree view and I don't see where
you want to fit them, etc...

a GTK TreeView can have a list or a tree model.
For a first step I planned to use a list model for the monitor dialog.
Eventually a tree model could be used. But that's beyond the currently
implemented concept and I could imagine different ways how
this might work. Probably it is best to ask for some user feedback before
beginning to plan this.
However, even with a list model, the TreeView has some advantages over
- not using deprecated methods anymore
- clearer code due to MVC
- progress bar additionally shows %tage
- vertical space consumption much lower
- personal opinion: looks nicer (more modern)
- sortable columns (not yet used in my code. Should I implement
that clicking on a head line makes this the sorted column,
a second click make it sorted reversed? This would be a pretty
common behaviour today in many GUIs.)
Except for the the sortable-question my sample already shows
the final (list) design. Some beautification remains of course
and the old widget needs to be removed, naturally.
I do not expect instability due to my changes because actually
the same hooks for communication with Nessus Server are
just called in a different way.

[Jan-Oliver Wagner]

Post by Jan-Oliver Wagner
I forgot one aspect: at least the progress bar is
only available since GTK+ 2.6.
So, I need to implement some ifdefs (or similar)
to apply the current style for GTK+ < 2.6 and
the new style for GTK+ >= 2.6.
At least unless we might increase the requirement
for GTK+ from 2.4 to 2.6 ;-)

Does anything speak against raising GTK+ from 2.4 to 2.6?

[Renaud Deraison]

Post by Jan-Oliver Wagner

Post by Jan-Oliver Wagner
I forgot one aspect: at least the progress bar is
only available since GTK+ 2.6.
So, I need to implement some ifdefs (or similar)
to apply the current style for GTK+ < 2.6 and
the new style for GTK+ >= 2.6.
At least unless we might increase the requirement
for GTK+ from 2.4 to 2.6 ;-)

Does anything speak against raising GTK+ from 2.4 to 2.6?

Maybe backward compatibility with non-bleeding-edge distributions ?
RHEL 4 uses GTK 2.4 (among many many many others).



-- Renaud

[Jan-Oliver Wagner]

Post by Renaud Deraison

Post by Jan-Oliver Wagner

Post by Jan-Oliver Wagner
I forgot one aspect: at least the progress bar is
only available since GTK+ 2.6.
So, I need to implement some ifdefs (or similar)
to apply the current style for GTK+ < 2.6 and
the new style for GTK+ >= 2.6.
At least unless we might increase the requirement
for GTK+ from 2.4 to 2.6 ;-)

Does anything speak against raising GTK+ from 2.4 to 2.6?

Maybe backward compatibility with non-bleeding-edge distributions ?
RHEL 4 uses GTK 2.4 (among many many many others).

OK, I will ifdef the code for GTK+ 2.6.

Best

Jan

[Jan-Oliver Wagner]

Post by Jan-Oliver Wagner

Post by Renaud Deraison
I'm not opposed to it, but let's define a final design before
anything is done -- you talk about tree view and I don't see where
you want to fit them, etc...

a GTK TreeView can have a list or a tree model.
For a first step I planned to use a list model for the monitor dialog.
Eventually a tree model could be used. But that's beyond the currently
implemented concept and I could imagine different ways how
this might work. Probably it is best to ask for some user feedback before
beginning to plan this.
However, even with a list model, the TreeView has some advantages over
- not using deprecated methods anymore
- clearer code due to MVC
- progress bar additionally shows %tage
- vertical space consumption much lower
- personal opinion: looks nicer (more modern)
- sortable columns (not yet used in my code. Should I implement
that clicking on a head line makes this the sorted column,
a second click make it sorted reversed? This would be a pretty
common behaviour today in many GUIs.)
Except for the the sortable-question my sample already shows
the final (list) design. Some beautification remains of course
and the old widget needs to be removed, naturally.
I do not expect instability due to my changes because actually
the same hooks for communication with Nessus Server are
just called in a different way.

OK to proceed based on these thoughts?

Best

Jan