Am Wednesday 26 September 2001 09:05 schrieb Guy Harris:
> On Tue, Sep 25, 2001 at 12:55:32AM +0200, Malte Starostik wrote:
> > But, as a matter of personal taste, I don't like GTK's look&feel too much
>
> GTK+ doesn't have *a* look and feel; it has a default one (which is very
> Motif-like, so I can see why you might not like it...), but GTK+ 1.2 and
> later are themable; see, for example:
>
> http://gtk.themes.org/
>
Right, there are many good looking themes out there, but anyway.
> > I'm wondering if it would be possible to add this (once it's a little
> > more stable and complete) to ethereal's CVS tree?
>
> ...one reason why there's a "gtk" subdirectory is to leave room to add
> support for other UI toolkits, such as Qt+KDE (a GNOMEified Ethereal
> might also be interesting - and a bit easier, as we already have the
> GTK+ support - and other possibilities include a native Windows version
> and a curses version).
That's what I thought. Actually, the KDE version is more like a real GNOME
version as it's more of a desktop integration than just a different UI
toolkit (as a plain Qt version would be).
> So I think it's a reasonable idea to add KDE support, although it
> shouldn't require that developers have the KDE development development
> toolkit installed unless they want to build the KDE version (and, for
> that matter, it shouldn't require that they have the GTK+ development
> toolkit installed unless they want to build the GTK+ version, although
> it'll require the GLib development environment in any case), and the
> configure script should allow you to specify whether you want the KDE or
> GTK+ version built (or perhaps let you build both).
Right, the current state is just that it can build the KDE GUI at all, of
course before anything could be officially included, a configure test and
options to specifiy which GUI(s) to build need to be written, it's on my
todo.
> Note also that the process of moving all UI toolkit calls into the "gtk"
> subdirectory is not complete, and that the packet list window
> implementation will probably change significantly at some point (which
> will involve Ethereal supplying a modified version of the GTK+ CList
> widget, which would allow columns to be added, deleted, and moved
> without destroying and re-creating the widget, and which would, instead
> of copying the strings for all the columns, call a callback routine to
> get the strings as they need to be displayed), which may, if QListView
> can't be subclassed to provide a similar list view widget, require the
> creation of a new widget (perhaps by copying the QListView widget, now
> that Qt is GPLed; QListView lets you add columns at the right end of the
> widget, but it doesn't let you add them at arbitrary locations, unless
> I've missed something - and it doesn't have any "virtual column" notion
> of the sort I mentioned. By the way, what do you do if you want more
> than 8 columns in a QListViewItem?).
In that case, you can call the item's setText() method after creating the
item, only the constructors limit the column count to 8. It's somehow
possible to have "virtual" columns, by reimplementing paintCell(), then one
can simply draw the text oneself, without storing it beforehand. I only use
QListView for the protocol tree anyway, for the packet list it proved too
slow (at least for realtime updates), I use a QTable there and already get
the texts on demand only. QTable also has no problem to insert/remove column
headings at runtime.
> I.e., be warned that the ground could conceivably shift out from under
> you while you're developing this.
I'm pretty used to that from using development versions and have no problem
with it really :-)
--
Malte Starostik
PGP: 1024D/D2F3C787 [C138 2121 FAF3 410A 1C2A 27CD 5431 7745 D2F3 C787]
