Streamlining Inkscape for the masses (Libre Arts) [LWN.net]

Streamlining Inkscape for the masses (Libre Arts)

Posted Jan 15, 2022 7:10 UTC (Sat) by rsidd (subscriber, #2582) [Link] (1 responses)

Inkscape is my most-used graphics program, ahead of Gimp. It's invaluable for scientific figures. I don't know what Adobe Illustrator offers but Inkscape seems to have everything I could possibly need. Thanks, devs!

Streamlining Inkscape for the masses (Libre Arts)

Posted Jan 15, 2022 9:41 UTC (Sat) by atnot (subscriber, #124910) [Link]

It's less the features but the user experience and integration with the rest of adobe's tools. But Inkscape has definitely made great progress in those areas too.

Streamlining Inkscape for the masses (Libre Arts)

Posted Jan 15, 2022 22:07 UTC (Sat) by ccchips (subscriber, #3222) [Link] (13 responses)

I use a dark theme on Linux Mint, and the toolbar icons are barely visible. An immediate turnoff because I want to try out the software.

I've run into almost exactly the same problem with Libreoffice Base.

Streamlining Inkscape for the masses (Libre Arts)

Posted Jan 16, 2022 8:53 UTC (Sun) by tuna (guest, #44480) [Link] (11 responses)

You have (unfortunately) hit the problems described here: https://stopthemingmy.app/

The only real solution would be for Mint to patch Inkscape (and LibreOffice) so the programs work with their themes, or for Mint to use the standard themes.

Streamlining Inkscape for the masses (Libre Arts)

Posted Jan 16, 2022 11:19 UTC (Sun) by falkTX (guest, #117916) [Link] (3 responses)

I have the same problem and dont use any themes, it just doesnt pick the right icons (it uses white on white).
Somehow for my KDE options being dark, some gnome/gtk tools assume I want light-theme icons, but still draw the whole UI in light-theme stuff instead of dark.
The result is mostly-invisible icons :(

Streamlining Inkscape for the masses (Libre Arts)

Posted Jan 16, 2022 16:18 UTC (Sun) by atnot (subscriber, #124910) [Link] (2 responses)

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.

Streamlining Inkscape for the masses (Libre Arts)

Posted Jan 17, 2022 0:30 UTC (Mon) by HelloWorld (guest, #56129) [Link] (6 responses)

That letter is just completely weird.

First they literally say “Please don't theme our apps”. Later they say that if you want to “tinker”, which in this context context could only mean messing around with the theming, then “that’s fine with us”. And a bit after that, they say “Just because our apps use GTK that does not mean we’re ok with them being changed from under us”. Come on guys, which one is it: are you OK with it or not?

They also point out that they could just disable theming in their apps, but reject that idea because according to them this is somehow “not a technical problem” (I don't see how it isn't). And then just a few lines later, it says that “GTK should stop forcing a single stylesheet on all apps by default”, which makes no sense because GTK doesn't do that (you don't get to say that something is “forced” upon your app if you can disable), and because they're really just asking for GTK to do the technical fix that they themselves refuse to do.

It also says that “You are not doing this to Blender, Atom, Telegram, or other third party apps”. Well duh, those apps don't use GTK. And overall, I just don't see their point. If your app doesn't work with custom themes and you don't want to support that, then stop complaining and just disable theming. This isn't that complicated…

Streamlining Inkscape for the masses (Libre Arts)

Posted Jan 17, 2022 0:56 UTC (Mon) by NYKevin (subscriber, #129325) [Link] (5 responses)

> Later they say that if you want to “tinker”, which in this context context could only mean messing around with the theming, then “that’s fine with us”.

In this context, they are obviously referring to individual end users doing clearly unsupported things such as recompiling the app or modifying its config files, which is an entirely different kettle of fish to distro-wide theming support.

> Come on guys, which one is it: are you OK with it or not?

My interpretation: They are OK with it (theming) if and only if nobody ever files a bug report about it breaking. They don't want to support it and they don't want to deal with the noise it generates when other people try to support it. But if some individual user opens up the app and screws around with its internals, then that user gets to keep both pieces when it breaks.

Furthermore, as far as the app icons are concerned, they are completely correct. You cannot re-draw somebody else's trademarked icon in a different style and just use it as if it were their official icon. That's a violation of trademark law, if the app's icon is trademarked (e.g. Firefox, which they show in their screenshot), and a great way to get sued.

Streamlining Inkscape for the masses (Libre Arts)

Posted Jan 17, 2022 3:08 UTC (Mon) by HelloWorld (guest, #56129) [Link] (4 responses)

> In this context, they are obviously referring to individual end users doing clearly unsupported things such as recompiling the app or modifying its config files

That makes it even weirder. It’s not like I need their permission to muck around on my computer. They shouldn't be opining on that sort of thing at all, whether they approve of it or not.

Anyway, I still think they should just stop whining, disable theming and be done with it. And honestly, if you're going to sue somebody because they made a version of your icon in a different style that they like better, then maybe this whole open source thing just isn't for you.

Streamlining Inkscape for the masses (Libre Arts)

Posted Jan 17, 2022 8:21 UTC (Mon) by Wol (subscriber, #4433) [Link]

As I read it, it's quite simple.

InkScape permits theming, great.

Distros apply their own distro theme, WITHOUT QA.

Users blame InkScape.

So as someone else put it, if you break it, you keep both pieces. But the distros are breaking it, and the bits are being sent to InkScape.

Cheers,
Wol

Streamlining Inkscape for the masses (Libre Arts)

Posted Jan 17, 2022 19:22 UTC (Mon) by NYKevin (subscriber, #129325) [Link] (2 responses)

> And honestly, if you're going to sue somebody because they made a version of your icon in a different style that they like better, then maybe this whole open source thing just isn't for you.

You don't have a choice. Trademark law says you enforce your trademark or you (potentially) lose it.

Streamlining Inkscape for the masses (Libre Arts)

Posted Jan 20, 2022 19:27 UTC (Thu) by flussence (guest, #85566) [Link] (1 responses)

No it doesn't, and that would fall under nominative use anyway.

Streamlining Inkscape for the masses (Libre Arts)

Posted Jan 21, 2022 9:18 UTC (Fri) by NYKevin (subscriber, #129325) [Link]

> No it doesn't

Please elaborate. Trademark abandonment is a well-established area of law.

> and that would fall under nominative use anyway.

Nominative use means you can refer to Firefox as Firefox and (probably) use its logo verbatim to refer to the unmodified software. It does not mean you get to play graphic designer and make your own fake Firefox logo. That's an open and shut case of dilution.

Streamlining Inkscape for the masses (Libre Arts)

Posted Jan 17, 2022 6:54 UTC (Mon) by prokoudine (guest, #41788) [Link]

Inkscape has pretty advanced theming capabilities for a GTK application.

https://i.imgur.com/0XwwpR0.png

Maybe you want tweaking things a bit?

Qt

Posted Jan 19, 2022 15:50 UTC (Wed) by swilmet (subscriber, #98424) [Link] (7 responses)

Not to troll, but Qt provides (as much as possible if I understood correctly) compatibility layers to ease the transition to new major versions.

Qt Group is a company with actual clients/customers, so it's normal that Qt wants to please their clients, not to make them too angry (and they have much more resources and developers).

Although with their LTS stuff for KDE or other free software projects, Qt is less attractive nowadays.

Qt

Posted Jan 24, 2022 10:36 UTC (Mon) by swilmet (subscriber, #98424) [Link] (6 responses)

Oh, and now Qt is "investing" in advertising, argh:
https://www.qt.io/press/the-qt-company-launches-digital-a...

Qt

Posted Jan 24, 2022 12:27 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link] (5 responses)

> Oh, and now Qt is "investing" in advertising, argh:

Can you explain why this is a problem? The recent Qt moves apparently aimed at increased revenue generation (ex: making LTS commercial only) can potentially be a problem for distros (RHEL no longer ships with Qt/KDE, although EPEL has it) or large open source ecosystems (KDE seems to be maintaining its own patchset - https://invent.kde.org/qt/qt/qtbase). In contrast to all that, this recent announcement seems neutral to people who don't care about advertising as a revenue source.

Qt

Posted Jan 24, 2022 19:21 UTC (Mon) by Wol (subscriber, #4433) [Link] (1 responses)

Qt always had a commercial poison pill, what's happened to that? Something along the lines of "If TT stop releasing Qt as Free Software, the stuff that has been released goes BSD licence" ...

So long as that's in play, and recent versions of Qt are GPL (as I think they've always been), what's the problem?

Cheers,
Wol

Qt

Posted Jan 24, 2022 20:14 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link]

> So long as that's in play, and recent versions of Qt are GPL (as I think they've always been), what's the problem?

https://ev.kde.org/2020/04/06/changes-in-qt-and-the-kde-f...

"Even though the new policies might be legitimate for a for-profit enterprise, they have the unfortunate secondary effect of putting at risk benefits historically enjoyed by users of the non-commercial branch of Qt, in addition to the privacy and security concerns that are raised."

Qt

Posted Jan 25, 2022 11:29 UTC (Tue) by swilmet (subscriber, #98424) [Link] (2 responses)

> Can you explain why this is a problem?

I haven't followed closely Qt in the past, so if the new advertising business seems normal for the Qt company, then that's ~fine.

But I hate ads, also the fact that e.g. Google is primarily financed by ads. I prefer a company that focuses on providing technical solutions, for the benefits of the end users (and the clients/developers).

That's why I strongly prefer a Linux desktop, avoiding ads as much as possible, etc.

Qt

Posted Jan 25, 2022 12:41 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link] (1 responses)

> But I hate ads, also the fact that e.g. Google is primarily financed by ads. I prefer a company that focuses on providing technical solutions, for the benefits of the end users (and the clients/developers).

I share your disdain for ads but what makes Qt successful as a toolkit is the commercialization of it, which does allow for the company to reinvest back into that ecosystem. The flipside of it is that they will occasionally engage in behavior that won't quite match up to what is ideal for the free and open source side of things. The alternatives may not have this particular problem but they come with other baggages. That is evidently the bargain at this point.

Qt

Posted Jan 25, 2022 16:16 UTC (Tue) by swilmet (subscriber, #98424) [Link]

It seems to work for Qt, they hire a lot:
https://www.qt.io/careers

So yes, there is no perfect solution. Maybe KDE / free software developers who know well C++ and Qt could have a good chance to be hired, improving the situation (at least technically, most probably not for the licenses and legal matters).

I've developed with GTK during many years (versions 2 and 3), even contributed a little to GTK and GLib. Unfortunately they lack resources/developers, so the core devs decided to break some of the APIs (especially the low-level ones: GDK, the addition of GSK (scene graph), and how to implement widgets, and to leverage the GPU).

Thankfully most GTK-provided widgets still have mostly the same API. But still, I think it's hard to port to new major versions, especially a large codebase of course (and from my experience it's not linear with the project size; so perhaps a good idea is to implement the Adapter design pattern, providing at least internal compatibility layers, or if they are only related to GTK, provide them to the rest of the community to ease the 3 -> 4 transition).

I've heard the GTK drawing is better than the Qt counterpart. And with GTK 4 even more so, probably (but don't know well if it's still the case compared to the new Qt 6).