> On Mar 21, 2024, at 09:38, Geert Janssens <geert.gnuc...@kobaltwit.be> wrote:
>
> Op woensdag 20 maart 2024 21:10:07 CET schreef john:
> > Geert,
> >
> > That ship sailed a really long time ago: You originally added it in
> > https://github.com/Gnucash/gnucash/commit/a153412e5a8fca7519fadb62935bab797
> > 860fbcd for what became GnuCash 3.0. Meaning that the migration happens when
> > the user opens a 2.6 file with 3.0 or later. Nearly everybody has already
> > done the migration, plus we advise users who haven't to step through the
> > major releases. It seems pretty unlikely that anyone would ever see the
> > dialog if we were to put it back and wire it up. Still, IIUC it's only a
> > revert plus one line of code so if you really want to it won't take you
> > long.
> >
> > Regards,
> > John Ralls
>
> Hi John,
>
> Indeed *that* particular migration has been a long time ago. As I tried to
> explain, my idea was to generalize this to be able to message the user about
> important stuff that might happen at early startup. Migrating metadata was
> the initial example of such a thing. At the time I was imagining one day also
> it could be used to inform the user saved-reports-xyz be converted from the
> current scheme format to something else (json, xml, ...) or any other
> internal conversions we'd do on the metadata.
>
> However I don't really feel strongly about that nor about how I initially
> implemented it. I just mentioned it to check if there was common interest to
> have such a feature.
>
> And your remark also makes we wonder should we really keep the migration code
> itself as we are now firmly in the 5.x series which means we have already
> kept this around for 3 major release cycles ?
Geert,
A warnings and errors dialog that echoes some of the information that goes into
the log and is generally ignored isn't a bad idea. The other Gtk program that
I help with, the Gramps genealogy program, has such a dialog and puts a
clickable warning icon in the status bar to indicate that there's something
there for users to look at. Users seem to think that if anything does it
indicates a serious problem, so we'd need to be careful about how we use such a
thing.
For design I'd really rather that it has its own class with header and
implementation files and corresponding function names so that it's easy to find
the code when we want to work on it and to keep the gnucash.cpp as focused as
possible on launching the program.
As for the actual migration code, I agree it should be removed along with all
of the other migration code that we've accumulated over the years. We still
need the checks and to tell users trying to open old files that they need to
cycle through the old major releases to bring their book up to the current
format.
Regards,
John Ralls
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
