On Thu, Feb 20, 2020 at 01:01:27PM +0100, Enrico Forestieri wrote: > On Thu, Feb 20, 2020 at 03:09:56AM -0500, Richard Kimberly Heck wrote: > > On 2/20/20 2:24 AM, Enrico Forestieri wrote: > > > On Wed, Feb 19, 2020 at 10:33:45PM +0100, Stephan Witt wrote: > > > > > >> What I wonder: there are the Qt elements used. Why don???t we rely > > >> on the services of QFileInfo class? E.g. canonicalFilePath() and > > >> friends? Are there historical reasons only? > > > Yes, at the time it was not possible using Qt in src/support. > > > > Did we make an 'official' decision about this? If so, has it been > > recorded somewhere, like the development notes in the repo? If we're > > really prepared to allow Qt pretty much everywhere---i.e., after all > > these years, we're willing to admit that LyX is a Qt-based app---then > > there may well be a lot of simplifications we could make, maybe in the > > 2.5 cycle. Of course, that would make us more vulnerable to Qt bugs.... > > In a developers meeting at the end of 2008 it was decided that Qt could > be used if there were good reasons for it: > https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg160412.html
In my memory it was mainly Andre's push while others were either indiferent or reserved, but there was no one who would directly protest... Now we have another 10+ years of experience with Qt evolution. This is my personal opinion and others might see it differently but I am somewhat frustrated with appearing regressions that are not getting fixed even if properly reported to the bug tracker and the recent decision to hide LTS releases with stability fixes behind paywall will make things even worse. So I would say that if we have nightmarish piece of code (which might be the case here) then it make sense to Qt-fy it. But making general Qt-fication as a desired goal for next major release or similar does not strike me as a good idea from stability POV. Pavel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
