Guy Harris wrote:
Ulf Lamping said:
Well, on windows, a two stage dialog process is currently used.
Yes, but that's a bit of an unfriendly process.
Agreed, but as not very frequently used, no real problem with it IMHO.
We really shouldn't force
a user printing on Windows to go through an extra dialog box - and I have
the impression that, to print to a printer on Windows, there's not a good
way to do so without involving a Windows print dialog, so perhaps we
should see if we can do it all with the Windows print dialog (which we
wouldn't want to do with the "save dissection to a file as text" and "save
dissection to a file as PDML" functions being done as print functions, but
if they were moved to a "Save Dissection As" function, we could do all but
"print as PostScript" with the Windows print dialog - and, if there's a
"print as PostScript to file" printer/driver installed, we could probably
even do that, although we might want to use the Windows print functions so
that we get a "prettier" printout along the lines of what we get for
"print as PostScript" now).
Hmmm. 13 lines in one sentence! New record ;-) That's hard to reply to ...
So we might want to split the printing functionality into a printing and
an export section ("Save Dissection As" as you call it).
As far as you describe the native win32 print dialog, this would require
us to implement the packet range things in native win32 code,
to get a single printing dialog in windows. I'm not sure, if I like this
path to choose.
I think there's also some hack out there to use Windows file open/save
dialogs from GTK+ applications - I think somebody mentioned that a while
ago.
Long term, of course, we probably want to be able to offer an Ethereal
with a 100% native GUI on Windows - and on KDE, and on Mac OS X as well, I
think. (A GNOME version of Ethereal might also be a useful option, so you
have a GTK+-only version and a GNOME version offered.)
Please keep in mind, that this could become a maintenance nigthmare, as
no one has the deep knowledge to
maintain all platforms GUI at once. This could result in dialogs could
be carved in stone, as no knows to "change them all",
when going to implement new things...
As a lot of the win32 look and feel topics are solved with the GTK2 and
GTK-WIMP things,
that look and feel topics really have become a much lower priority in my
personal todo list than before.
Regards, ULFL
