Streamlining Inkscape for the masses (Libre Arts)

Posted Jan 16, 2022 16:18 UTC (Sun) by atnot (guest, #124910)
In reply to: Streamlining Inkscape for the masses (Libre Arts) by falkTX
Parent article: Streamlining Inkscape for the masses (Libre Arts)

Afaik this is because until recently it was not really possible to detect that without hacks like checking whether the theme name had "dark" in it. There's a proper way to do it now but it will probably take a while for all of the applications to respect it.

Streamlining Inkscape for the masses (Libre Arts)

Posted Jan 16, 2022 20:49 UTC (Sun) by nedrichards (subscriber, #23295) [Link] (1 responses)

And in fact a lot of that will be the work referred to fairly dismissively in the article about moving to newer versions of your base platform. User expectations are constantly changing and you can either spend your time meeting them by reusing other peoples work (e.g. moving to a newer GTK to get access to magical dark mode support, or HiDPI which users want) or by working on the things that are unique to your app that users also want. There's always going to be a balance of both of these things in any kind of application.

As an aside - the general collaboration and standardization around the 'dark mode' work is very pleasing and means that this seems to be getting out more easily with less effort and faster. Long may that continue!

Streamlining Inkscape for the masses (Libre Arts)

Posted Jan 18, 2022 1:45 UTC (Tue) by HelloWorld (guest, #56129) [Link]

> User expectations are constantly changing and you can either spend your time meeting them by reusing other peoples work (e.g. moving to a newer GTK to get access to magical dark mode support, or HiDPI which users want) or by working on the things that are unique to your app that users also want.

That is not a tradeoff, or at least not the kind of tradeoff you’re implying. Upgrading libraries and such is something that you’ll need to do anyway in the long run. To put it off doesn’t mean you have more time to work on features, it just means that you’re going to spend more time porting later on because you’ll have more code to port.

There are exceptions of course. Newer releases of the library may add new features to help with porting, in which case waiting for another release could save time. Or you might be working on a feature that is so important that getting it out of the door a bit earlier is of more value to you than the time you lose because you now need to port more code to the new library version. Or it might be a legacy project that you’re planning to replace entirely. But generally speaking, one should think twice before deciding that one doesn't have time to keep the tech stack up to date, because usually it’s the other way around: if you’re short on time, the last thing you want to do is wasting it by writing new code to APIs that are already obsolete.