[Freeciv-Dev] [bug #18196] gtk2-client - gtk3-client settings migration
Update of bug #18196 (project freeciv): Status: Ready For Test = Fixed Open/Closed:Open = Closed ___ 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
[Freeciv-Dev] [bug #18196] gtk2-client - gtk3-client settings migration
Update of bug #18196 (project freeciv): Status:None = Ready For Test Assigned to:None = jtn Depends on: = bugs #19888 ___ Follow-up Comment #8: Options are either shared with all clients, or are specific to certain client. Oh yes, I missed that (in (struct client_option).specific). jtn? Do you find my solution acceptable despite the quite different solution you had in mind? Given the above complication, it seems a reasonable compromise. Attached slightly tweaked version (fiddled with some of the old backward compatibility code for the widget rearrangement options). I'm happy to apply it myself since it's got tangled with other patches. (file #15960) ___ Additional Item Attachment: File name: trunk-S2_4-Gtk3OptionsMigration-bis.diff Size:6 KB ___ 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
[Freeciv-Dev] [bug #18196] gtk2-client - gtk3-client settings migration
Follow-up Comment #7, bug #18196 (project freeciv): jtn? Do you find my solution acceptable despite the quite different solution you had in mind? ___ 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
[Freeciv-Dev] [bug #18196] gtk2-client - gtk3-client settings migration
Follow-up Comment #5, bug #18196 (project freeciv): So, stage is all yours. Ahem, then again, this is the only ticket with 2.4.0-beta1 target, so I'm checking it now, even risking duplicate work. Looking options.c I now remember why I choce to duplicate all the options for gtk3. Options are either shared with all clients, or are specific to certain client. I don't know how cleanly we could implement special case for this that some options are shared between gtk2 and gtk3, and only them. ___ 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
[Freeciv-Dev] [bug #18196] gtk2-client - gtk3-client settings migration
Follow-up Comment #6, bug #18196 (project freeciv): Patch. I consider this best compromise between cleanliness and functional correctness. We don't currently know if settings in effect are initial defaults, or if they are read from file (which can be identical to initial defaults, of course). This has no bad effects here, as migrating from gtk2 settings even if they are just initial defaults merely causes gtk3 client initial defaults to be replaced with identical values. For similar needs in the future we should add another internal setting settings_from_file that is FALSE unless loaded from conffile as TRUE ( secfile_lookup_bool_default(FALSE) ), and always saved as TRUE to conffile. (file #15925) ___ Additional Item Attachment: File name: Gtk3OptionsMigration.diff Size:4 KB ___ 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
[Freeciv-Dev] [bug #18196] gtk2-client - gtk3-client settings migration
Follow-up Comment #2, bug #18196 (project freeciv): I started looking at this... but it's surprisingly fiddly and I'm wondering, is it really worth proactively splitting the options the way we have? The set of options and their defaults are currently identical, and for many of them, I can't see Gtk3 client diverging sufficiently that different values become necessary (maybe I just lack imagination). Most of the checkbox options (e.g., map_scrollbars, chatline_autocompletion) seem safe to share indefinitely. Perhaps the default_theme_name does warrant splitting. I could also see a case for splitting sizes and maybe fonts if we were being conservative. You could argue that for most users, they will one day move from gtk3 to gtk2 and never move back (or move back immediately), so it doesn't matter if the settings diverge. But by the same token, the risk that a single setting has different optima for gtk2/3 and by sharing it we force someone to reset it every time they switch clients seems minimal. At some point the gtk3 client is likely to get new features that will not be backported (e.g., zoom). Any settings associated with them can be labeled gui_gtk3_*; there's no migration issue there. What do people think? (In the minimal implementation of my proposal, options would still be named gui_gtk2_* but not be gtk2-specific. If that really bothered us, we could arrange to rename them to gui_gtk_* when read in from a 2.3 rc. That would probably still be easier than handling this migration well.) (There wasn't much discussion in patch #2701, so that doesn't help me.) ___ 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
[Freeciv-Dev] [bug #18196] gtk2-client - gtk3-client settings migration
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
[Freeciv-Dev] [bug #18196] gtk2-client - gtk3-client settings migration
Follow-up Comment #4, bug #18196 (project freeciv): So, if we took absence of gui_gtk3_* options in the rc-file as the signal for migration FWIW I had a plan to add new internal option that would tell the state of the migration. Actually, the reason I never implemented this settings migration was that I had ambitious plan to first implement completely new framework for handling this kind of setting migrations (not only now, but also in future). I never found time for it, and I don't think I manage to do it before gtk2-gtk3 migration is needed. So, stage is all yours. I remember that one design problem with that internal option was to reliably detect if there's old (pre-2.4) gtk2 settings to migrate if gtk3-client is first 2.4 client to run, or if default gtk3 settings should be used. You have demonstrated that's almost theretical problem as migrating from gtk2 default settings would in 2.4 yield identical results. But then again, we probably don't want to touch migrating code again (for those people who start to use gtk3 only in freeciv 2.5). ___ 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
[Freeciv-Dev] [bug #18196] gtk2-client - gtk3-client settings migration
Update of bug #18196 (project freeciv): Severity: 3 - Normal = 4 - Important ___ Follow-up Comment #1: We had probably better fix this for 2.4, ideally for first beta (since this is a one-time migration). ___ 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
[Freeciv-Dev] [bug #18196] gtk2-client - gtk3-client settings migration
Update of bug #18196 (project freeciv): Planned Release: 2.4.0,2.5.0 = 2.4.0-beta1,2.5.0 ___ 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
[Freeciv-Dev] [bug #18196] gtk2-client - gtk3-client settings migration
Update of bug #18196 (project freeciv): Planned Release: = 2.4.0,2.5.0 ___ 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
[Freeciv-Dev] [bug #18196] gtk2-client - gtk3-client settings migration
URL: http://gna.org/bugs/?18196 Summary: gtk2-client - gtk3-client settings migration Project: Freeciv Submitted by: cazfi Submitted on: Fri 10 Jun 2011 12:22:33 PM EEST Category: client-gtk-3.0 Severity: 3 - Normal Priority: 5 - Normal Status: None Assigned to: None Originator Email: Open/Closed: Open Release: Discussion Lock: Any Operating System: None Planned Release: ___ Details: Client settings can either affect all clients, or one specific client, but not shared between only some clients. gtk2-client and gtk3-client will have similar, but separate settings. This means that user client settings will not follow when (s)he switches from gtk2-client to gtk3-client. We really should have at least one-time (when gtk3-client is run first time or something like that) settings migration for users - especially at that freeciv version where gtk3-client comes the default (so user playing with default client has been playing with gtk2-client earlier and then plays with gtk3-client) ___ 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
