Wireshark-dev: Re: [Wireshark-dev] [Wireshark-commits] rev 28794: /trunk/gtk/ /trunk/gtk/: Make
From: Ulf Lamping <ulf.lamping@xxxxxxxxxxxxxx>
Date: Mon, 22 Jun 2009 10:41:35 +0200
Guy Harris schrieb:
On Jun 21, 2009, at 11:53 PM, Ulf Lamping wrote:

But what are you trying to achieve?

Being able to find files that implement more than "main" things, whether it's the main menu or the main window.

What I've tried to point out is that having less prefixes makes it harder to find stuff (even if the prefixes are not 100% correct), giving the pletora of files in that dir.

Even if the file names are 100% correct, searching for specific stuff in a few hundred of "arbitrary named" files can be pretty hard.

Adding a name prefix was an attempt to bring some order into the chaos. Afterwards it helped (at least me) *a lot* to find stuff.


Now you're telling me that file name in question is not 100% correct so you're changing it back into the chaos we once had - ignoring the benefits we could get from the name prefixes.


I'm getting your point that the prefix main_ might be misleading for stuff that's also used elsewhere. But in the current situation it's probably a lot better to have a very slightly misleading order than none at all.

Before I introduced the main_ prefix, I remember several times seaching
for the code displaying the hex dump - searching in a few hundred
variously named files in the gtk dir (proto_draw isn't very intuitive
here). If you guess that it might be somewhere in the main window,
looking for main_ and getting the right file is a matter of seconds.

Protocol trees and hex dumps appear in more than the main window.

They also appear in the "show packet in a new window" which is basically a kind of "mirror" of the main window. Where else?

The problem with the hex dump pane code is that, for better or worse, hex dump panes (plural) are somewhat tied to protocol tree panes (plural), so the code to implement hex dump panes is in the same file as the code that implements protocol tree panes. Perhaps the fix is to have separate files for them.

Having a pletora of unsorted files with conglomerates of stuff in it makes it either way hard to find anything - even finding a nice name for the file :-)


Anyway, if you're going to split up stuff so the file name better reflects what's in it - I'm all for it (that's what I've done with e.g. main_filter_toolbar.c). Having files with more than 3000 lines of code is often a good indicator of chaos IMHO ;-)

Regards, ULFL