hello petr!
> Now, it would be nice to find some way, how to make this utility
> "cross-desktop". What do I mean? Consider this: many people will use GNOME
> / KDE / Corel-desktop (How is it called?) or bare X with wine (and
> possibly something like "wine-desktop" ... maybe).
>
> I absolutelly think, the "wine.conf graphical front-end" for GNOME
> _should_ be a GNOME application (written using Gtk+ and gnome-libs),
> similary the KDE one should be written using Qt and the "bare wine" by
> using winelib.
>
> Now it would be nice not to "invent the wheel" for each desktop
> separately, but rather to create some "skeleton" for the app, with desktop
> specific addons, that would be possible to compile then separately for
> each desktop.
i forgot to write in my previous mail, that i already started to develop
it using tcl/tk
with [incr tcl/itcr tk] extension. the final product will be distributed
as a
half-statically linked executable, which will not require tcl/tk
installed on target machine,
but will depend on libraries like libX11. i'm not sure if it will be
"cross-desktop" enough...
what do you think?
> We can maybe use some meta-configuration file, that would describe, what
> the wine.conf entries are (including help), that would be distributed with
> each wine version, making the configuration program up-to-date.
i'm not sure what exactly you meant.
if some new option will be added in future wine version, how should
program decide, where
to put them in graphical i-face and how to integrate them with
"nice-look" goal in mind?
it can work pretty well if (for example) new "window look" will be added
(like "Win 2k")...
did you mean something like that?
> And Yes, the "wine.conf configurator" is not the only program, that is
> desktop-dependant and would be nice to be developed somehow "centrally"
> for all wine-desktop combinations. Consider e.g. 1) help browser (or
> better: the possibility to view windows .hlp files using native
> help-browser of the current desktop); or 2) integrating the
> component-systems between wine & the desktops; or 3) integrating "start
> menu" and "the desktop" between wine and the desktops (so that freshly
> installed program's entry will appear somwhere in the GNOME/KDE/whatever
> "start menu".)
i absolutely agree. "wine.conf front-end" should be developed with these
goals in mind.
martin
