Follow-up Comment #3, bug #18196 (project freeciv):
> it's surprisingly fiddly
To expand on this (in the hope that the horror will increase support for my
plan ;).
For a good user experience, we want to copy the settings from Gtk2 the first
time the user runs the Gtk3 client.
But the current arrangements in client/options.c are to read all known options
for all GUI types in any client -- this is necessary for one client not to
lose another's options. We then write *all* known options back out to the rc
file when the time comes.
Thus, my .freeciv-client-rc-2.4 already has values for all the gui_gtk3
options, even though I've never even compiled it.
So, if we took absence of gui_gtk3_* options in the rc-file as the signal for
migration, a user running the 2.4 Gtk2 client would cause the migration/fork
to occur at that point. If they later moved to the Gtk3 client, their options
would be old ones, from the time they upgraded to 2.4. (IME this is likely to
be perceived as regressions in the Gtk3 client, as users tend to forget that
they changed options...)
So, to make this work, we'd need to split handling of options-for-this-client
and other options in client/options.c -- we could keep the latter around in
specfile form ready to write out, or track whether each option originally
existed in the rc-file, perhaps in "struct option". The goal would be for the
Gtk2 client to only write out Gtk3 options if they existed in the rc file it
read.
_______________________________________________________
Reply to this item at:
<http://gna.org/bugs/?18196>
_______________________________________________
Message sent via/by Gna!
http://gna.org/
_______________________________________________
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
