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
