Inkscape is prime for having its Blender moment - the moment where freeing energy 10 years ago pays off and beats the closed source software.
I use Inkscape for laser cutting and vector graphics and it’s getting better every year. Still a tad of polish and I’ll be happy!
Inkscape needs to decide whether it wants to be just an SVG editor or a full vector editor.
It dumps tons of junk in the SVG and has pretty poor tools for managing the SVG hierarchy (resorting to text editing for some things), but at the same time they've used the excuse of being an SVG editor to avoid implementing things like path thickness and mesh gradients for years (yes, there's a path effect extension now but it's hugely buggy).
Not that it’s a particularly good workflow, but there is a series of advanced save options that can produce much better SVGs that are very clean without all the inkscape cruft. Might be worth checking out.
I wish they would copy-paste Blender's UI, shortcuts, and some of the logic. Things like edit mode in Blender versus node edit in Inkscape, so I don't accidentally click on another path. There are several operations that don't have hotkeys, like layer/path visibility... They've sorta moved in the UI direction with modifiers in the dev build.
As it's currently tooled it can't be set up to align with Blender, really at all, which is really annoying. The box zoom for example frequently trips me up, but that's inconveniently my muscle-memory for panning.
I wish they would copy-paste Illustrator’s ui and shortcuts, or have an Illustrator mode. This applies to Gimp v Photoshop too. Many people are coming from Adobe layouts and shortcuts. For example, I find using path tools much slower in Inkscape and gimp, and not just because the shortcuts are different.
I’m skeptical that shortcuts and button layouts are patentable. I understand that the underlying behavior may be. All major mechanical cad platforms basically have the same tool ribbons and sketching functionality.
Sounds like it would be ideal to implement as a plugin, that way third parties could maintain it and remain at an arm’s length from the main software entity
Please no, whilst Blender has gotten better recently...
A: It's still far from as intuitive as other 3d programs
B: Blender is a full featured 3d suite with animation,etc so modes makes sense, Inkscape is more of a single-use tool.
Been a while since I used Inkscape but from memory accidental selection does ring a bell, might be more focused ways to make usage smoother (many tools will go back to a selection via an undo, does Inkscape do this?).
I started on Blender so it's all very second nature. And given the FOSS domain Inkscape exists in it makes sense to me to bring some level of parity or at least a lower-level control mapping schema so people who use Blender can select a full-fledged keymap/profile that behaves as expected.
But I would disagree that Blender's nature is particularly distinct from Inkscape. More or less the workflow is transitioned from 3D-exclusive to 2.1D. Inkscape is still very much about dragging verts, modifiers, moving, scaling, flipping, rotating... There are obvious non-parallel features like animation but there are also a lot of parallels and I don't think that mapping exclusive edit mode to 'tab', translate to 'g', setting 'MW' to zoom (this is a very convoluted process but can be done)... or at least opening up all that stuff so the user can define it to the extent necessary to reach parity with their favored applications.
Over a decade ago (I think around ~2010) when I was in high school I had an English teacher who required Times New Roman for a paper. I got marked off because while I had installed Times New Roman, I had a word processor which had silently replaced another serif font as Times New Roman when I selected it. To be fair I think it was one of the Bitstream fonts that looked a bit larger than Times New Roman at the same size.
Usually it's done so that the teacher can tell how long the paper is without counting words. Times New Roman at x pt with 1 inch margins fits a well known average number of words per page. The assignment will usually be "write x number of pages on..."
Using a larger font size or a font that renders larger at the same font size means you can write less content in the same space.
… but you don’t need to count the physical printed pages, you can just look at the .doc file? Let the robot do the word count for you, it doesn’t make sense to not take advantage of the same tools the author is using to create the document.
Turnitin.com and digital submission in general are relatively new, I was in high school 10-15 years ago and no teacher would have accepted a digital submission. Now I believe they would refuse anything but digital.
Most teachers I know vastly prefer to grade on paper rather than digitally. Easier to just circle sections and write comments with a pen than deal with the review features in a document editor. I suppose they could print them out themselves? Or require submission in both digital and paper? But why bother when you can just have the students submit in paper.
I mean I actually agree, it’s way easier to markup a sheet of paper (unless you’ve got a computer setup you’re comfortable with for the task) - but in that case they can print their own copies, and use their own word processors to count the student’s words. It’s crazy to make up all these extra hoops for students to jump through just because teachers can’t figure their shit out technologically, like it’s a running joke how far out of their way instructors will go to avoid the easily accessible technological solution for some processes.
Sure, it might seem stupid over something trivial as schoolwork, but consider the same situation widely exists in the real world.
You won't say it's stupid when you need to send business documents and there's money on the line if there are incompatibility issues. Suddenly Windows, Office, and Adobe make a ton of practical, industrial sense.
ca 2000 when I was in HS, it was clear that the font & format limits were to also help get students used to submitting printed standardized manuscripts later in academia.
But also to save the teachers from all of the same empty formatting flourishes which people do in the corporate world too. Colored text, unrestrained use of bold, fonts which are harder to read ...
12 pt, double spaced, Times New Roman was honestly a standard which started to be taught as early as elementary school.
In uni, strict formatting rules weren't uncommon either! At my school, within the humanities, formatting was strict to get students used to APA/Chicago and more persnickety guides.
Even in Analytical chemistry, charts made in Excel were banned outright because the prof wanted to push students onto tools capable of generating publication-ready graphics.
Ok, got it! Then it's actually clever and basically prevents what I was doing as a 7th grade back in the 80's, increasing my handwriting size to fit less words in the same space when writing essays...
You could excuse not having adapted to, say, AI-assisted tools yet. The industry has to figure out best methods, then it has to trickle out so the younger instructors know about, and then it has to be propagated out to everybody, standardized, etc.
But word processors that could ignore fonts and provide word counts were pretty old tech by 2010! If you haven’t adapted your teaching to something that’s been widespread for decades… that seems like a willful ignorance.
Interesting, I wonder if something like that is happening to me. The TNR install seems to have worked, but some of the Sans fonts looks wonky, not sure if its Arial or something else. From what I gather, Inkscape takes the name of the font and then uses the font with the most similar name. But from what I can tell, many pdf files have partially embedded fonts with wonky names. If I had word available atm, I would check the pdfs against that --- I have to admit, word's pdf import function is pretty impressive at times --- just to see what fonts exactly come out looking funky.
I don't think it needs that much polish. I love that it's performant and doesn't crash all the time like Adobe Illustrator. I've been using it for just about 20 years now and I think they've stated true to the core capabilities without adding to much bloat.
If I were to define software quality as a combination of performance and stability, all Adobe products have been in steep decline over the past two decades. Inkscape is still missing a few key features for printing so I do my work in Inkscape then bring it into Illustrator before printing.
There's something about open source UI apps that just screams amateurs.
It's actually a fascinating topic, I wish I could put a finger on it and tell specifically what I don't like. Inkscape just feels and looks... slightly off.
The Senior Inkscape developer post seems to be one of those postings where a company already has someone in mind, and phrases the job listing to be specific only to that person. (But hey, good that an FOSS dev on the project finally gets paid!)
The GTK post seems more real, and I hope they find a good candidate
> But hey, good that an FOSS dev on the project finally gets paid!
It's a strategic choice whether your company wants to employ FOSS tools for your production, but if you do, or you base your company on consulting for other companies who use those tools, then it is of course in your interest to also influence the continued relevance of said tools. This is why FOSS isn't necessarily cheaper for companies, because if you want to defend your interest, you eventually have to hire software engineers to - at the very least - gain an overview, if not some measure of "ownership" or stabilizing influence over the code base.
I know this from the government, because they often have to officially open the position due to policies forcing them even when just renewing a contract. Is this the same for certain foundations?
Same in higher (university-level) education in the UK due to legislation. It forces institutions not to become closed shops. In many cases the institution has a preferred internal candidate, but forcing them to open it up at least gets external people a foot in the door. In many cases the internal candidate is the best for the job because they know the institution well so they don't need to be brought up to speed on many systems and are familiar with its pedagogical philosophy, although there are obvious downsides where a department can become stagnant if it's always the internal candidate, like a kind of academic inbreeding. But I know of at least two cases where the external candidate won despite there being a preferred internal candidate because the external people were so much more suited to the role.
Yeah I also had cases where we made the job so specific they had to do the interview with another candidate knowing they would not hire the candidate, if you ask me it's a puppet show. I understand it protects against certain things, but also make a lot of people dance around bureaucracy needlessly.
Im sure, like many of us, you've sighed about things being needlessly bureacratic at some point in your live, this is one of those things that cause good people to feel very frustrated.
It's also the same in at least some, maybe many or most, large private businesses, not because of any legal requirement or regulation but as part of their internal ethical standards.
Source: personal experience at the company where I work.
It is the same in many areas I think. You get in if you know someone, or have a prior established rapport. At the very least that is a way more pleasant way of finding a new job.
yeah but why you have to make an official job post? and not offer the job directly? In gov they are forced by policies, but most private orgs dont need to do such gymnastics.
I am probably going to lose some precious poinnnttts for this, but I sure wish they could instead target browsers instead, whether by using the canvas, WebGL, three.js, A-Frame, or something else. This would have the immediate benefit of making the software work on the Web or as a local webapp any device that supports a browser, and they would have a much larger pool to hire from. They could also come up with with great libraries.
It is not quite in the same league, but we already have SVGEdit[1] as an example. as well as diagrams.net, but taking a 2023 approach would be much more performant and open ended.
They could, but there are also many people that just prefer native applications. I'll take Inkscape on Linux or Affinity Designer on macOS any day over a web application. They have native widgets, standard shortcuts, I can easily script them with Automator or Shortcuts, they work with the native OS accessibility options, can have integration (like drawing with Apple Pencil on an iPad on a Mac), they are more performant (can directly use native Vulkan/Metal APIs), are generally more privacy-friendly, don't consume huge amounts of memory/CPU, etc.
Hmm, I don't think Inkscape on Mac supports Automator &c. And you can run it as a local server to mitigate privacy concerns. There are ways to support stylus features in browsers, though it's an area that could use more support.
That was about Affinity Designer. The main point is that with by using native APIs you get deep platform integration. I just gave Mac App examples because I am more familiar with that platform.
Graphical design can be fairly complex. Some vector might contain dozens or even hundreds of control points, and a vectorgraph might contain many of layers of vectors/groups. Rendering the graphic itself and the software UI element might be a challenge for browser engines which is not made for this kind of task, especially on slow computers.
I worked for an ad publishing firm many years back, it was common for us to receive vector graphic files that are hundreds of megabyte large. We used Adobe Illustrator and CorelDRAW to handle those files on some fairly fine computers, and yet some graph files from our clients still managed to crash the computer due to RAM exhausting etc.
I image it makes sense for an industrial capable software to want to run as native as possible.
Another thing is color management. Most graphic software supports RGBA, but for publishers, CMYK is also required. I'm not really sure if browser engines supports these color system well enough (not just color conversion between the two, but also color profile for the monitor), because if something is mess up there, it can be expensive to fix (for the ad publisher).
I'm currently working on WebKit support in Boxy SVG (https://boxy-svg.com/ideas/95) and SVG rendering performance seems to be actually better than in Inkscape - especially when transforming many objects simultaneously and when manipulating objects with filters applied.
Granted I've not checked recently, I want to say this was pre-Blink, but Safari (iOS and OSX) struggled massively with SVGs that Firefox and Chrome handled with ease – maps in my case. If we're at the point where Safari is finally faster than Inkscape that's great news, although I still don't want a browser based utility.
There's nothing that says a web app has to be sluggish. You don't need an entire chromium instance to run a single web app. Web views are usually more performant, but have the issues of compatibility (Chromium vs Firefox vs WebKit), but it still seems worth it to me.
There's nothing that says that of course, but my RAM says fooey to webapping a tool like Inkscape. I use it almost every day, I just finished using it to make a poster where I needed to print out a hi-res background with text that would be in juuuuust the right position for me to use my typewriter to type on it and have that text end up in exactly the right place, then scanned that at 1200dpi and used inkscape to crop and export the final piece.
I do not think my browser is ready for an 8000x8000 raster image with svg clipping etc. Not to mention the ungodly large bitmap traces, with hundreds of thousands of nodes...
A browser tool like Inkscape would be cool and useful. But no replacement.
Web apps have largely had terrible performance compared to native even on my development machine. Everything moving to the browser is a regression in isolation, increase of complexity, and a poor use of resources given that the application works fine without. Dependency management and packaging complexity become an issue to the point where projects refuse to package such applications.
Web Assembly might be a way to provide web app support in addition to native but it should never replace native.
Also, energy efficiency is starting to play a greater role here in the EU where hopefully it encourages less use of energy hungry frameworks and more native applications given their better resource use.
Inkscape is Inkscape to me because its native. If I want something on the web, there's Figma, which is closed source, and penpot.app, which has most of the basic features of Figma but is FOSS.
Porting gtk3 to gtk4 is relatively easy... And can be even automated in some parts.
Not to mention that all the algorithmic part is preserved as it is.
Writing something web from scratch is another world, and performances won't ever be close.
Out of the whole developer pool? Sure, that's a very small fraction.
Out of the pool of Gtk developers? That's basically saying "Have you done gtk and kept up to date?". It's not really the equivalent of the dreadful "5 years of experience in a JS framework that came out last October".
For a migration job, what else would you suggest as the initial requirements? Sounds okay, although they might have to go down if they find out that e.g. every gtk3 developer moved on to Qt, WinUI or Flutter...
(For generic, long-term positions I'm strictly against too specific requirements, by the way. Actual desktop UI experience would be great, though, even in our current sad state)
I feel like for GTK, there just aren't a lot of resources out there for it. And that links into the fact that GTK is only really used on GNU/Linux which represents an incredibly small share of all desktop users (even though it can be used cross-platform I believe). So its one of those cases where I think to learn it, you kinda have to look at samples, and source code from other projects.
Not entirely true. The resources devoted to making sure the backends for non-Linux platforms are correctly designed and implemented suffer a bit.
I say this as someone using GTK and who was forced to contribute quite a lot of fixes for the macOS backend (in GTK2), because I was one of the few people using it in the way we do on macOS.
Hmm. On my current system I have 32 packages installed that depend on libgtk2.0-0; 217 packages that depend on libgtk-3-0 and 62 that depend on libgtk-4-1.
Will I sound like too much of a grumpy user if I express dismay at yet another protracted migration?
"Cascade of Attention Deficit Teens" - it's a phrase coined by jwz (of Mozilla fame) to refer to how some some projects (he specifically targeted GNOME) tend to throw out mature-but-imperfect code and rewrite it from one version to the next rather than addressing bugs and problems in the existing software.
I think it's a little unfair of him to single out young developers, but I have seen the 1.x -> 2.x rewrite before too so he's not wrong overall. If you want to read the original article search for "The CADT Model" - I would link to the article but JWZ shows requests with referer "news.ycombinator.com" an image that you may not like if you're at work :)
edit: oh I just clicked the link someone posted (in a [Dead] comment), it seems he has removed the functionality I described
> I would link to the article but JWZ shows requests with referer "news.ycombinator.com" an image that you may not like if you're at work :)
IMO anyone who has not configured their browser not to send cross-domain Referer headers deserves whatever they get. There is no user benefit for this privacy leak and browsers should have trashed it decades ago.
Gregory Casamento needs to build a GNUStep PPA for Ubuntu based distros, it would work great on libre derivatives such as Trisquel. Parabola has badly maintained repos for it, lacking even Gorm and ProjectCenter.
We need a DE for legacy devices as XFCE's development is not a sure thing with further GTK+ releases tied to Gnome and Red Hat.
Sometimes it's easier to rewrite a module, given inputs and outputs and a good test suite, than to understand how it works. This is even more true if the original developer is no more available.
Rewriting a whole big library, not easy either way.
CADT would imply this kind of sabotage is not happening on purpose. There are certain parties that have keen interest in a severely dysfunctional FOSS desktop. It's more like GSAW (GNOME Saboteurs At Work).
I use an extension to always send the base domain of the target as the "Referer" and have not encountered any problems (or at least not any that I cared enough to investigate the cause for). It's absurd that Firefox still has this privacy leak by default considering how much they present themselves as privacy friendly.
Firefox some time recently cracked down on unnecessary referrers but they are still fairly conservative about it because it breaks some sites and if you are too aggressive about it then you end up with users assuming that's firefox not working properly.
Same. I tried Inkscape because Illustrator is abandonware at this point (and of course now part of Adobe's software-rental scam) and mostly liked it. Way back I even liked the fact that it put the menu where it belongs (on the application's main frame) even on the Mac.
But the UI performance is just too janky by modern standards, and I too bought Affinity Designer. But Affinity's UI suffers from some truly brain-dead design gaffes that they refuse to fix. I'd be psyched to see Inkscape become a real competitor.
I note the reference to OpenGL, but that has been dropped in Mac OS. I wonder if the Inkscape peeps have plans to address that.
> I note the reference to OpenGL, but that has been dropped in Mac OS. I wonder if the Inkscape peeps have plans to address that.
I'm not familiar with Inkscape internals so I don't know how it renders the main window canvas, but Gtk nowadays IIRC uses OpenGL for rendering widgets. So the OpenGL comment may have been wrt that. And for rendering buttons and menus, the OpenGL-on-top-of-Metal, or however the macOS OpenGL implementation nowadays works under the hood, is probably good enough.
Mad to me that this hasn't been resolved after _years_, despite it seeming (naïvely) to be quite a simple fix?
I worked around it once—I can't remember how now—and got Inkscape running without lag on my Mac, but it introduced another bug where it would crash when resizing a window. I got done what I needed to do then abandoned it. I doubt chasing down the fixes would take that long for someone with actual experience.
I bought Affinity Designer and Photo at -50% off _just a few months before they released 2.0_. I have to say, while it's performant and has professional features like CMYK and color management - there are many missing features like tiled clones or absence of any scripting whatsoever. With a plugin system, at least the community could fill the gaps.
For me, at least, v1.2 has been pretty solid and was a big step up from earlier versions. It's responsive (way better than e.g. GIMP 2.6 which is comically bad), and very stable (although it was never as bad as e.g. FreeCAD was for me). There are glitches (e.g. OpenType feature handling UI) but nothing that screams "this doesn't work because you're using a mac".
It struggles a little with this but I don't deal with 3d plots in Inkscape all that much:
I gave it a try 2 days ago on Linux and it crashed after a couple of minutes doing basic manipulations. Have I just been unlucky or is it really unreliable?
I won't say it never crashed on me, however I am surprised by the negative comments here as inkscape is super snappy, fast and reliable as long as I am occasionally using it which is 10+ years.
Imho probably unlucky. At least on Windows it is way more stable than a few years ago.
Then again it can be hard to tell. E.g. The converse is true for me for LibreOffice which used to be fine but crashes within a minute or two every time.
I use the command-line version a few times per year on Windows and it's always worked fine. Never used the GUI but just starting it, it seems to be just fine and speedy on a passively cooled laptop while throwing a lot of shapes around.
GTK4 got a massive macOS rewrite and is in the best position it has ever been. It has no big users yet and could use some contributions though to quickly catch regressions.
I hope this makes the GTK developers realize how detrimental API change can be. I get that some things need to change, but how many other open source projects are going to have some level of trouble keeping up?
API changes? They remove important user-facing features (like custom key themes[1]) without providing any real migration path. I wasted an afternoon trying to figure out how can I make Gnome apps use super+c/super+v/etc like cmd+c/cmd+v on macOS and... no, as of Gtk4 you can't, not anymore.
> I'm personally not sure that "user must have an ability to redefine every keyboard shortcut" [...].
Developers are users too. They are also arguably your most important users - they turn products into ecosystems, their involvement is a force multiplier for your platform. As Gnome is actively hostile towards their users, I'm not surprised they don't care much for third-party developers either (both inside and outside[2] of their ecosystem).
Sadly bigger projects like GIMP or Inkscape didn't learn their lesson. Since version 3.0 GTK serves only GNOME and their particular demands for their severely limited desktop environment. The correct action would be to go back to GTK 2.0. It is far easier to continue to maintain GTK 2.0 than porting your app to a moving target like GTK3/4 with regular severe user and developer hostile regressions.
That is nonsense, the toolkit is like a million lines of code, constantly falling further behind. GTK2 doesn’t support a modern Linux machine well (Wayland, hidpi, GPU rendering).
For a GUI toolkit, developers are the only users in one sense.
>> > I'm personally not sure that "user must have an ability to redefine every keyboard shortcut"
I'm not either, but I agree it sucks to just remove existing functionality. OTOH reading the thread it seems on MacOS you can define that outside the application, so integrating with that would be a requirement - did they do that before?
We get people wanting to redefine shortcuts sometimes and I'm just like "wow, can't people just accept the defaults? I'm not even sure how to go about implementing that, never mind on 3 platforms..."
My current UI complaint is corruption of the title bar. Gnome has allowed widgets up there now. Even if I accept the desire to use the space, some widgets can be used to drag the window while others can not. The primary purpose of clicking up there is to move a window and I can't tell if/where I can do that any more. BTW moving windows is important now with Wayland because Apps can't remember where they were and put themselves there on opening, and the Gnome guys haven't realized that's their job now. BTW I agree with the Wayland thinking on this, it's just that the DE hasn't caught up yet.
Also on Windows, MS has made some title bars white/grey and some blue. Same with toolbars. So now when I have multiple windows overlapping it's impossible to tell what is attached to what and what will move the window I want to move. It's like GUI designers think "oh I'd like this" but don't even consider the collateral damage the change will cause.
The window state is not the GTK devs problem but an app developer problem. One of the very first topics in the GNOME developer guide is how to use settings to save/restore window state on close/startup.
The window state is absolutely, partly GTK's problem, or at the very least _not_ the developer's problem. Storing window size yourself opens a whole can of worms, including but not limited to:
- Yay, one more half baked implementation of loading a file and reading it, with a bit of bad luck it'll be in C too. Surely this will not lead to problems!
- Yay, your app now probably has to bother with saving DPI info and restoring that properly when using a different screen with different DPI.
- Yay, your app now has to bother with not positioning the window out of bounds in case it was on another screen. Surely this will not lead to problems!
You have now added dependencies on displays, IO, parsing. To restore the window's position. Add in client side decorations in this mess to make it even better.
It is an OS/DE's responsibility to give me windows. I'll put whatever the hell I want in there, and it's my job to save that content, but pretending that saving window state is the job of the app is some peak clown shit. On a scale of how bad of a UI toolkit this puts you, you are now at "Win32". Congrats Gtk4.
I explained in other siblings already why the toolkit cannot make assumptions about storing and restoring the window size. The app knows about the content and requests one or more windows with a requested size depending on its contents, and it's the OS/DE/WM that has to place it somewhere.
> - Yay, one more half baked implementation of loading a file and reading it, with a bit of bad luck it'll be in C too. Surely this will not lead to problems!
The link I provided documents this exact process in 4 languages including C and JavaScript and all the saving/loading/parsing and even binding the managed settings to the properties of a window is handled for you by the toolkit. It is 1 function call to initialize the settings and 1 function call per setting to bind it to the window property you want to manage. Oh, and these settings can be configured externally with various tools or GUI's as well if you want to.
> - Yay, your app now probably has to bother with saving DPI info and restoring that properly when using a different screen with different DPI.
AFAIK this is not something the app developer has to do and is handled by the DE with maybe a little help from the toolkit.
> - Yay, your app now has to bother with not positioning the window out of bounds in case it was on another screen. Surely this will not lead to problems!
Nope, an app can only request windows with some requested size, and it's up to the DE/WM to place it. Take tiling window managers for example which might be configured to always open new application bottom right, or top left, or floating or whatever. Sure, an app might dig down into the lower levels to finetune behavior but then the app developer chooses to open this can of worms to make sure it still works with all flavors of DE's/WM's/X11/wayland/etc
> You have now added dependencies on displays, IO, parsing. To restore the window's position. Add in client side decorations in this mess to make it even better.
GTK already has these dependencies and abstracts them for you in higher level API's while still providing access to lower level API's if you choose to use them. (Gdk for displays, Gio for IO and parsing/saving/loading and binding to settings is in Gio as well). Client side decorations is a matter of choosing what base window type you use, so you can have default decorations or start with a blank slate.
I honestly don't know what you expect GTK to do more than it already does.
It has some logic to it though: An application developer is going to use the toolkit to open one or more windows on startup and the DE/WM has to place those somewhere. The first window opened by the app is not guaranteed to be the main window and it's not guaranteed to always be the same window (sometimes it can immediately open the main app window but other times it might have to show a smaller login window first, or immediately open multiple windows, etc).
- It is the responsibility of the application developer to determine for each window what size it should be depending on the content in the window which can be dynamic. It's also not a fixed thing, but more a hint to the DE. The relevant GTK method is called gtk_widget_set_size_request(width, height) with the focus on "request" (defined in widget but window inherits it). Saving/restoring window state is left to the developer because of the dynamic nature of windows as explained above.
- It is the responsibility of the toolkit to make sure the window gets created and then communicate the requested size to the DE so it can be placed on the screen.
- It is the responsibility of the DE/WM to place this window where the user expects it and depending on the type of DE/WM it might have different behavior. For example a tiling window manager might be configured to always open new windows in the bottom right, or top left, or have config overrides for specific applications to always open floating or maximized.
So yes, the size is the apps problem (because it knows what content is on a specific window and might know about the previous window size from last time), and the position is the DE's responsibility because that can depend on user configuration and the specific DE/WM used. The app cannot make any assumptions about that. It can only request windows with a specific size.
As explained in a sibling comment, the toolkit cannot make assumptions about restoring an apps window state to its previous size. Sure it might work for simple hello world apps that always open the main window, but that's not always the case. Sometimes applications have to open a different window or multiple windows on app startup. The only thing the toolkit can reliably do is translate the requested window size when an application opens a window to the DE so that the DE/WM can place it on the screen.
Because of the dynamic nature of opening windows, app developers should have control over storing/restoring the window size. Simple apps might always store the last window size and restore that exact size on startup. Other apps might have to run some logic first before they know how large the window should be, and then request the toolkit to create a window of that size.
> I'm not either, but I agree it sucks to just remove existing functionality. OTOH reading the thread it seems on MacOS you can define that outside the application, so integrating with that would be a requirement - did they do that before?
The way this works on macOS is every application defines the top bar menu actions (which can be referenced by their name, e.g. "New Tab", "Copy", etc), and any of these actions can then be referenced by specific keyboard shortcuts - either system default, as defined by the app, or as re-defined (app-specific, or system-wide) by the user. Any redefining can be done in the System Preferences (now Settings) app, so as long as your app uses the system menu, your users get arbitrary user-defined shortcuts for free, with zero extra effort on your side.
This applies to every keyboard shortcut - you can redefine Cmd-C to Ctrl-C if that's what you like. I just checked it and it works. It even does the most sensible thing in Terminal (copies text if something is selected, and sends interrupt otherwise).
I've also checked this right now in Gimp (Gtk2) and Inkscape (Gtk3), and both apps support this functionality on macOS, so I think what the developer referred to here was specifically user-defined shortcuts in Gtk CSS - which leaves Gtk4 on the open source desktop as THE platform that now doesn't support it in any way anymore.
I'm pretty disappointed as before switching to a Mac, I spent almost 15 years on Linux/BSD, and got used to being able to customise anything - with enough hackery, nothing was out of reach. All I actually want is not customisation, but consistent keyboard shortcuts between Linux and Mac. It's pretty disheartening that it's easier to make Mac shortcuts work like on Linux than vice versa.
> We get people wanting to redefine shortcuts sometimes and I'm just like "wow, can't people just accept the defaults? I'm not even sure how to go about implementing that, never mind on 3 platforms..."
On macOS, you have to actually go out of your way to NOT support that. I don't think I've ever seen anything like Mac's shortcut system on Windows or Linux, but this is why things like gtk-key-theme and key bind properties in Gtk CSS have always existed.
And this is precisely the value of a cross-platform toolkit, it is supposed to help you (the application developer) not think too hard about these platform specific details, and provide the user with an escape hatch when they have a case you didn't think about (I'm a big fan of stylish/custom CSS for this reason).
> Also on Windows [...]
I think the situation on Windows has already been steadily turning dire by the time of XP, and hit an inflection point with Vista. I don't even mind a new look sometimes, but for goodness sake, clean up your mess MS...
> How many other open source projects are going to have some level of trouble keeping up
As developer of another open source project that uses GTK2, I'd note that one of the beautiful things about open source is that for the most part, we do not have to keep up. Worst comes to worst, we dump GTK2 into our source tree ("vendoring") and keep using it.
I know that you have good reasons, but this (the clear message regarding staying with GTK+2 and thus no native Wayland) is what drove me away from Ardour.
What Wayland-using system does not run an X server?
There are hundreds to hundreds-of-thousands of applications that do not have a native Wayland version? Are you suggesting that you would not run any of them either?
GTK has had weird issues on Windows for years. For instance newly created windows don't go to the foreground, and may sit there entirely hidden behind other windows. It's amazing that hasn't been fixed; I can reproduce it with newer Gimp releases easily like I could two decades ago.
Maybe it is a wrong question or impolite but a genuinely curious question. Hiring a senior C++ developer with GTK experience is costlier than let's say a senior backend engineer (Python/Go) OR a senior frontend engineer?
There's complexity in each domain for sure but maybe it is more a matter of demand and supply that impacts this? There's less software being written in C++ with GTK than there are enterprise (or otherwise commerce etc) backend and frontend being written.
In general, people will use a cross-platform library to port such applications. While QT will likely never really stabilize (I'd flag it unsustainable), the https://www.wxwidgets.org/ is able to be statically linked into commercial and opensource projects at no cost without tripping GPL.
"Hiring a senior C++ developer with GTK experience is costlier"
I think you are confusing skill valuation, and operational productivity. Some have an erroneous notion talent is interchangeable. Likewise, applicants with identical base skill-sets on their CV often mistakenly believe they even have long-term employment options (outsourced, youth tax credit churn, and or senior wage suppression).
Most FOSS people are easier to train, as most already can mitigate utter chaos already. =)
What I have learned over the years is that there's no experience to shortcut. For example, a Django developer might learn GTK in two weeks but their code won't be as polished as someone writing GTK applications for a decade.
Conversely, I have seen Python code bases that are so much of a horror show that you'd question why someone would do such a stupid thing in first place?
The thing is - they didn't do a stupid thing. They didn't know any better.
I imagine they are looking for someone with 10-20 years of experience for this particular task. It’s less about the language, and more about how many large projects you’ve worked on.
If you just know one language, then you probably are pretty junior.
How come? Gtk1 is historic, Gtk2 has been obsolete for a decade, Gtk3 has been the thing since 2011 and Gtk4 is a brand-new thing, where they finally were able to make some changes that were on hold for a decade, since they would break the API. You know, semver, major version.
The fragmentation on Linux desktop causes a lot of churn, both in users looking for more cohesive desktop experiences, and on developers looking to not having to deal with all this mess.
In regards to major backwards-incompatible version changes, to me it's pretty clear that many developers simply don't give enough priority to maintaining backwards compatibility. Most cases i've seen of backward-breaking changes were unnecessary: the new features could've been added while maintaining the existing APIs (maybe deprecating them if needed). The decisions to not maintain the existing (and now deemed "old") APIs were not done on a technical ground, but more on an ideological/purist ground, where the "old" APIs were considered "bad" or too costly to maintain (both claims totally subjective and not supported by much evidence). And simply not enough thought was put in considering how users of the APIs may find it difficult to do a major version update, or might simply churn away and not do the update or look for an alternative.
Now, i don't have direct experience with GTK, so i might be totally bullshitting and maybe nothing that i said applies to GTK major version bumps. But the fact that so many projects find it hard to update and are stuck on older versions for long times, and that the desktop UI paradigm hasn't changed that much in the last 20 years (how much MUST the APIs for windows and UI controls change then?) makes me suspect that there is at least a bit of that backwards-compatibility disregard here too.
I didn't try to codify a few little ideas I had into Linux UI apps purely because all the drama with Gnome and whatnot. I don't have time for this bullshit. Terminal apps can be written once and just work(tm). Linux GUI development has always been for people that have no life.
> There was no real reason to rush the transition to GTK3, but it was done anyway.
If anything, Linux libraries move too slow. Meanwhile, while seeking perfection, the world around them uses the older releases, with all the downsides it entails, so they cannot wait until it is perfect.
> GTK3 with its half-assed support of CSS for theming is just just bad, and slow (especially on Macs)
Still much faster than Cocoa on Linux... What Cocoa on Linux? Exactly. Availability of Gtk on a Mac has 0 impact on how many Linux app will decide to use it.
> And they continued to change GTK3 API after 3.0, which did not exactly help
They added (and yes, deprecated APIs). Nothing that would affect existing applications. Themes were never part of the API and there was a warning, that it is going to change. If someone has to find the hard way, so be it.
>> Availability of Gtk on a Mac has 0 impact on how many Linux app will decide to use it.
I sometimes consider using GTK as a cross-platform GUI vs what we do today (a small wrapper over Windows, macOS, and GTK) so we can have some nice things - like resizable text and SVG icons. Not supporting macOS would mean not using GTK for that. At the moment, no static linking means no GTK for that too because we ship a single binary for Windows and I don't want to deal with an installer.
Eh, I don't know. I think that existence of crossword/todolist GTK apps is not nearly as much of a win as GIMP, Inkscape, Krita, KiCAD, FreeCAD and Scribd becoming actually competitive would have. It's indicative that biggest OSS app success, Blender, is not using OSS graphics library but rolls it's own UI. Rawtherapee, very highly regarded RAW file editor uses Qt. There's no decent looking mp3 player on Linux for heaven's sake! Every one that exists looks like shit or has zero functionality.
I am genuinely interested - is gtkmm like modern C++? It’s been around a long time (gtkmm) and I’m curious how it has kept up with C++ standard libraries.
gtkmm was basically the modern c++ competitor of Qt from 20 years ago. Back in the Qt2-3 era, where gtkmm relied on libsigc++ and templates, Qt relied on meta-object compiler for reflection and macros for connecting signals to slots. It also had threading and database interaction. It provided productivity at the cost of being butt-ugly and you had to be confined to their own editor and build system. Fast-forward 20 years, Qt5 got a big makeover and adapted to C++11. It deprecated hacks like QSignalMapper and provided more 3d and multimedia stuff. And Qt6 adapted to CMake. So Qt is pretty nice looking these days.
Inkscape has been unusable on mac for years now. After I pointed it out on my own twitter timeline the lead dev came on and started lambasting me for expecting any kind of usable performance. They are not interested in making it usable
It has always been slow for me, too, but 1.2 introduced some particularly bad performance regressions. The new version couldn't handle files that 1.1 handled okay.
I wanted to report this, but the project uses GitLab's issue tracker. I recall being unable to sign up for a GitLab account using a throwaway email address at the time, so I couldn't report the problem, or even add information later on to the bug reports that others eventually created.
The project really should make it easier for users to contribute bug reports.
What's the point of GTK4 and why does it have to be incompatible with GTK3? Is it really worth it to spend so much developer effort across so many projects to migrate them to GTK4?
The biggest changes are to rendering. GTK 1-3 used Cairo to do CPU rendering. It is slow and incapable of modern rendering features. GTK4 makes good use of the GPU with OpenGL (and kinda Vulkan). It has been a huge win for performance improving animations, shaders, multimedia, zero-copy integration with external projects like WebKit, etc.
Yeah, "good use", and also just happens to no longer support subpixel font antialiasing, so good luck if your screen isn't 4K. Which a lot of screens out there aren't. :-(
There was an attempt to have Cairo use OpenGL but it was mostly unsuccessful and abandoned. Even if that worked the paradigms used are very different and would fight performant GPU usage.
latest 2022-2023 inkscape in windows release totally ruined the text tool. Cannot paste or edit texts anymore, they just gets messed up all the time with spans in the object / layer tree :(
I don't have the expertise, but I too hope it works out for them. Would love to be able to adopt Inkscape as my go-to art program. Right now I wrestle with Sketch or Affinity Designer, neither of which is totally satisfactory.
