New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for migration from xchat configuration #1794

Closed
wants to merge 1 commit into
base: master
from

Conversation

Projects
None yet
3 participants
@scarabeusiv

scarabeusiv commented Aug 16, 2016

If user starts hexchat for the first time and yet he still has some
xchat2 configuration around we should reuse it thus saving the user
some time.

We in SUSE/openSUSE switched the default from xchat2 to hexchat and thus want the users to be able to use their irc right after the distribution update.

Add support for migration from xchat configuration
If user starts hexchat for the first time and yet he still has some
xchat2 configuration around we should reuse it thus saving the user
some time.
@Arnavion

This comment has been minimized.

Contributor

Arnavion commented Aug 16, 2016

#739 (comment)

and probably all sorts of incompat in the prefs themselves.

@TingPing

This comment has been minimized.

Member

TingPing commented Aug 16, 2016

  • servlist.conf: needs manual migrating and is worse than the new defaults (SASL/SSL on many networks and removing dead ones, adding new ones) (Also you saved it to the wrong file...)
  • pevents.conf are not necessarily a good idea to bring over, there are many new events so old themes are a mix of new and old.
  • addons: A lot of them are not needed any longer and could cause conflicts such as SASL scripts. (You actually failed to migrate these anyway?)
  • hexchat.conf: Similiar to servlist there are a lot of new saner defaults that we want users to have but also tons of settings have been added, renamed, removed. (You also didn't rename this one)
  • keybindings.conf: We have a lot of new keybindings users would want, also hexchat is now set up to where new keybindings are added to default configs and throwing old ones in there breaks this.

@TingPing TingPing added the needs-work label Aug 16, 2016

@TingPing

This comment has been minimized.

Member

TingPing commented Aug 16, 2016

Anyway, with that said I think there are only two good options for migration.

  • Don't migrate at all; It really isn't that hard to do a one time setup and it is impossible to have a complete full migration so why half-ass it.
  • Have a slightly more interactive migration process. Present a prompt showing users that you can migrate your addons and maybe a few specific configs but inform them that not everything can be migrated. That way the important bits are done and users didn't have to read docs about it but it didn't create a mess mass migrating things.
@scarabeusiv

This comment has been minimized.

scarabeusiv commented Jun 5, 2018

We luckily abandoned the migration in openSUSE :)

@scarabeusiv scarabeusiv closed this Jun 5, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment