Preferrably it wouls not slow down for you, ofc, but they may well deem it out of scope of their project to fix issues for asystem, that they do not have the code for to look at where it is going wrong, or simply do not have the time and resources to deal with that. Add to that, that any day MS could destroy the fruit of that work again.
I can understand, that they don't want to invest resources into that.
I used Inkscape on Win10 recently, and also on Kubuntu (21.04 a and 21.10, I think) and the experience was comparable.
I do not like the icon themes now, they're very low contrast and difficult to decipher for me so use the old, colourful icons I'm familiar with. Apart from that and one problem with a dialog not appearing until I selected the option a second time (the XML dialog), all worked well.
I think it's difficult, a x.0 might not be snappy, might even have serious issues, but there's not enough manpower resource to address everything at once, it's going to be incremental. Holding things back would negatively impact the momentum of the project IMO, but yes may benefit an individual.
But I couldn’t even properly switch back to the Win32 theme because of severe bugs that rendered it very problematic on all displays and basically completely unusable after a bit on any comparatively small high-DPI displays like my Surface Book’s. I don’t know if any of these issues have been fixed; I did try Inkscape 1.0 final briefly but decided it was still just too bad compared to 0.92. And now I’m back on Linux and so, like the Inkscape developers, don’t care all that much about Windows any more.
(https://gitlab.com/inkscape/inbox/-/issues/879 was my initial report, including explanation of some of the major Win32 theme regressions. Given the adjacent topic in this thread of GTK 4, the mention of overlay scrollbars in that thread points to a mess too; https://wiki.archlinux.org/title/GTK#Disable_overlay_scrollb... says: “as of GTK 4, the overlay nature of the scrollbars is part of the toolkit.” Ugh, GTK is obviously not interested in being a native look-and-feel toolkit if they deliberately remove the ability to control scrollbar overlayedness at the system level or in the theme. If you require the app to switch it on, it might as well not exist. Sounds like they’re continuing with the sabotage.)
I can't agree with excluding all GNOME users from using an application, since it's not the fault of GNOME users in general that it's difficult to transition between major GTK versions.
Of course, other options in a similar space like Qt aren’t entirely better in that they don’t behave fully like GNOME on GNOME platforms. The best cross-platform native-feel apps, like Firefox, tend to use GTK on Linux (or possibly KDE/Qt in KDE?) and other things on other platforms.
As a Linux user I inevitably use quite a bit of GTK software (though barely any GNOME stuff, if you savvy the distinction I’m drawing), but I dislike almost all of the directions it’s headed in since GNOME 3. Decent scaling is one of the few redeeming features.
sprash is describing a very—ahh—ideologically pure position, but I do deeply sympathise with a desire for a return to the GTK+ 2 ways. My ideal would probably be to scrap GTK+ 3 and 4 and create 5 derived mostly from GTK+ 2’s philosophies, just including the good technical parts of 3 and 4, but determinedly not a full style unto itself. Also I’m fed up with client-side decorations matter and want better support for server-side decorations, as was done traditionally and as is still generally preferable on Windows and in most Linux window managers, or even platform-matching client-side decorations, which would be good for macOS and Windows and frankly GNOME.
GNOME has basically sabotaged GTK as a cross-platform library—even as a Linux-wide thing (apart from KDE). They’ve taken it over to serve their own purposes and vision. Their vision does improve and unify some parts of GNOME desktops, but as a user of something other than GNOME (Sway), I don’t like most of what they’ve done to GTK.
- decouples GNOME and GTK. They've created a new library, called libadwaita, that hosts the GNOME stuff.
- brings big performance improvements (it has GL and Vulkan backends)
- is much better on macOS and Windows.
Anyway, I agree with you on your points. One of the issues of opensource graphic programs is that the toolkits that are available are quite problematic/don't care about this use case. This is not just about GTK, as QT has also been causing a lot of headaches to the Krita developers. It is not by chance that Blender, which draws the UI using its own toolkit, is not affected by these issues and has a fantastic, fast UI.
• They severely damaged text rendering and initially didn’t even acknowledge it as a defect, dismissing the report: https://gitlab.gnome.org/GNOME/gtk/-/issues/3787. More recently there’s some movement on the issue, but the initial reaction was not a good look, at least.
• Someone said various bad things about libadwaita here on HN a couple of weeks ago: https://news.ycombinator.com/item?id=30027002.
• Of accessibility, they’ve completely redesigned it, in a way that is very convincingly better, or will be once it’s all finished including supporting tooling, but the impression I’ve received from a couple of communities where it’s come up a bit at times is that at least when they released GTK 4 and told people “start adopting it!”, GTK 4 apps were opaque to screen readers, because half the plumbing was missing. This impression could be false, and if there was any lack, hopefully it’s addressed by now.
I’m curious what the state of affairs is for approximating native look and feel on Windows. GTK+ 2 had a once-fairly-decent win32 theme that became fairly significantly out of date after Windows XP, but there were also some more recent themes that did parts better (and other parts worse). I’ve never seen a Windows theme for GTK+ 3 that is even halfway decent for look, and feel is a dead loss (e.g. menu keyboard behaviour and list box popup positioning and behaviour are both just painfully wrong).
If they’re serious about cross-platform, attempting to match Windows and macOS look and feel (and completely ignoring Linux, for a while) is where effort should be placed. I don’t know if they are.
On the other topics, I'm not informed enough, but at least it's good some work on the accessibility front is happening, compared to the dire situation of the last decade... I hope that eventually the situation improves. Accessibility improvements really benefit everyone.
Regarding the matching of the look and feel... in the last few years, this mindset has become very common, where each app is an island and no effort should be made to look native, because, in fact, there is no native look anymore. Windows has always been like this, and Linux desktops have started embracing that. From the app developer perspective, it's understandable. For the user, it means giving up decades of usability studies and the pleasantness of coherence. Given this direction, I expect GTK apps to look like GTK apps wherever they run, unfortunately. On the bright side, the default look of GTK4/adwaita apps is kinda similar to what macOS and Windows 11 are going for, so at least it won't look too alien over there.
But I very much like what I’m seeing in the draft release notes for 1.2: as well as some really nice-looking functionality improvements, they mention various performance improvements in approximately the areas that had the worst regressions in 1.0 (such as zooming and panning), and UI adjustments to reduce space consumed. I haven’t tried 1.2 alpha 1 out just yet, but I probably will in the next few days and I’m really looking forward to it. (Incidentally, I’ve been back on Linux for the last ten months, and using the latest releases, since it works better under Linux, though Adwaita is still horrifically wasteful of space given Inkscape’s habit of stacking many buttons side-by-side, so I installed Minwaita which reduces that problem a lot.)