Wireshark · Ethereal-dev: Re: Re: [Ethereal-dev] usability extensions: 2nd "recent" patch

[Ulf Lamping <ulf.lamping@xxxxxx>]

"Ronnie Sahlberg" <sahlberg@xxxxxxxxxxxxxxxx> schrieb am 10.09.02 11:56:07:
> ----- Original Message -----
> From: "Ulf Lamping"
> Sent: Tuesday, September 10, 2002 12:11 AM
> Subject: [Ethereal-dev] usability extensions: 2nd "recent" patch
> 
> Seriously, there are two thing I dont think I like with the patch.
> It does mess with file.c which I am not conviced is nessecary.
> Second, it is a very complex implementation of what I think is a simple
> concept.
> (see my previous mail with a proposal for a very naive but simple design)
> 
> Lets give it a few days to see if there are any other comments and if not it
> goes in
> on Friday. Ok?
> 
Ok!

I understand your complains about my implementation, 
but I currently don't see a better way of implementing this with the described features :-(

If I find some time, I will look at the code again, to see if I can improve it even more ;-)

I am also thinking of separating the file handling of the code into separate recent.c / recent.h files.

> 
> ===
> Would you have time and interest in looking at improving the display filter
> dialog

Interest: yes
Time: I currently really don't know

> you get by pressing the "Filter:" button?   That one is a real nightmare and
> i still have problems whenever i try to demonstrate it because it just
> doesnt make sense.

I agree with that (and a lot others on the list also do) :-(

> 
> This job would consist of three parts:
> * come up with a completely new but working GUI design that perhaps people
> actually understands how it works. I guess your hands are free, it cant
> really get worse.
> perhaps create a mockup design to discuss on the dev list?

As a first (and maybe more simple) step in the right direction,  the filter dialog could be
extended only a little bit, using the same GUI mechanisms (not implementation) as the colorization dialog, which is better for the user to work with.

> * I would really like disdplay filters to be stored each in their own file,
> one filter
> per file. This would make it MUCH easier to transfer filters to other users.
> It would allow a central repository of useful filters, something we could
> have on the webpage: an annotated list of useful displayfilters?
> What to do with people already having a milion filters in the current
> single-file for all filters implementation? Perhaps just a warning if the
> single-file thing is detected with pointers to a shellscript or something
> that could convert it to one-file-per-filter?
> I am totally for this change.

Well, in the ideal world, this should have nothing to do with the GUI implementation ;-)
I think, this would also apply to the other filters as well (capture and color).

As we do a lot of conversions from old style things already in the code, I don't think we need a shellscript to change this, but could implement it "in code".

> 
> imho display filters are extremely powerful and the most important feature
> of them all
> in ethereal. it is a shame that the gui for newbies for displayfilters is so
> crappy.
> 
> if you make the display filter dialog work you will be a hero.
> 

In general, the whole implementation of manipulating the filters should be revised. There should be a better separation of the GUI and the data handling.  This is currently closely tied together, making it difficult to change, and even more difficult to write a different GUI for it.

BTW: I really don't like, that we have different file formats for the different preferences files (dfilter, cfilter, colorfilter, ...). I think the preference file has the file format we should use for ALL the preferences files, this would allow us to add things without interfere with the old file format.
Example: It would be hard to add a user comment to a display filter (which I think, could be useful) to the current file format.
This also could be easily invented, if we put the filters in separate files.

I could think of a lot other features in this area, some examples:
-display filter wizard
-using capture filters by display filter syntax
-adding trigger filters
-...

Summary:
I see a lot of work here, which could improve Ethereals usability a lot.

I don't know, what the right start to solving this knot would be. Starting with changing the file handling to use separate dirs, changing the gui to be better usable, ...

Keep in mind, that other kinds of filters could be useful in the future. For example I'm thinking of a trigger filter, which would trigger an event like starting another program or such at capture time.
So I don't want to change it all again, to implement this. 

I am currently thinking of a more generalized storing of the filters.

My current direction is: storing all information of ONE filter into a single file, and storing other things, e.g. ordering sequence of the colorizing filters in another (not in the preferences, to be able to use profiles). This of course would lead to a HUGE rewrite of the code storing filters and the GUI of it.
I am still thinking of it, I will send a suggestion to the list, when I got the whole idea ready.

Regards, ULFL
______________________________________________________________________________
Die clevere Geldreserve: der DiBa-Privatkredit. Funktioniert wie ein Dispo, 
ist aber viel günstiger! Alle Infos: http://diba.web.de/?mc=021104