Gtk3 and Gtk4 have been ...well, gimped, and don't have many features. They've been removed in Gtk3/4 by GNOME developers because their DE does not prioritize things like keyboard entry (as compared to mouse use, see gtkfilechooserwidget.c in gtk3/4 not supporting keyboard based pasting of file paths without errors, https://gitlab.gnome.org/GNOME/gtk/-/issues/5872). Gtk2 hasn't fallen victim to this slow erosion of functionality.
I doubt breakages like the one you linked are deliberate, there's just a severe lack of manpower.
My firsthand knowledge of such things is quite stale nowadays, but I get the impression the RH desktop group is barely on life support at this point. That GTK4 happened at all strikes me as surprising, but could be interesting long-term in terms of modernized GPU support for the toolkit attracting new usage/developers.
The real question is do enough people even care about GTK anymore to make use of it in the future. I'm inclined to believe the current crop of devs want $hipster-language-native GUI packages. Not awkward quasi-"idiomatic" bindings and FFI wrapping an archaic C library like GTK/glib.
Right. The example I gave, gtkfilechooserwidget.c, is such a mess of spaghetti code that the remaining Gtk developers don't want to touch it. Despite me bringing it up with them once per year and even providing a partial patch to work off of. But of course that didn't stop them from messing with it in 2014 and breaking it and leaving it in a broken state. The developer that broke it, mclassen, is still there and still explicitly says not having keyboard filepath paste is not a bug. Despite it giving an error message.
There's no mention of the issue being keyboard-specific nor patches or comments from mclassen in the issue you linked. Maybe you linked the wrong one?
Looks like a canonical file path (as opposed to dir path) paste handling bug in general, which seems like something worth fixing regardless of one's stance on keyboard paste.
I talked to them myself on #gtk on IRC (both on gimpnet in the old days and libera in modern times). Most previous issues with this bug have been removed from the bug tracker(s). This is just the latest one submitted by a helpful dev in channel who discovered it applied to Gtk4 too when I brought up the Gtk3 version this year. Now that they know it's in Gtk4 too they might do something.
To understand how it's keyboard specific you have to know about what features were removed. In the past you could set the file chooser dialog to have either a text entry field or the path-bar mouse buttons as the default. This was through org.gtk.Settings.FileChooser location-mode. While this gsetting still remains gtkfilechooserwidget.c was changed so it no longer respects those settings and always forces only the mouse based path-bar input mode. This means now when a file path is pasted with ctrl-v (or middle mouse click paste?) the entirely wrong function tries to handle it and this function errors out because it's not expecting file path input.
"Lack of manpower" is not a valid excuse when it comes to Gnome/GTK. If you redesign your entire codebase every other year, break everyone's workflow you cannot cry about lack of manpower. Writing software is one of the most expensive human endeavors in the world right now and FOSS community treats it like they have unlimited supply of it. If you have limited supply of software engineers then you cannot afford to redesign your UI and you have to stick to your existing code.
I would estimate that would be a 3 person-year project, and the result will contain precisely zero improvements for any user (even if theoretically it might be easier to bring various improvements after that is done).
However, what people do not realize about these "toolkit ports", whether within a family (GTK 3->4) or across them (Qt -> GTK), is that the reason they take so long is that it is almost impossible, when having to go through the vast majority of the codebase and change stuff everywhere, to avoid the realization and/or temptation that there are better (or at least different) ways to do things.
If you could suppress that inclination (and its not clear that doing so is a good idea), and simply do as close to a 1:1 replacement where required (which for cross-family ports is everywhere), the port could be a lot faster. But it is extremely hard to resist that, because the non 1:1 replacement stuff just appears so right.
But, haven't the gimp team been working on refactoring/modularization of all of the tools? I think this is part of an effort to modernize. I haven't been keeping up with it but I think I read this several years ago. They stated in 2018 "GIMP 3.0 will be relying on GTK3, a much newer version of the toolkit." not sure if that ever happened?
Seems they are very close though in the latest release candidate for Gimp 3.x
"GTK+3 port officially done
GIMP 3.0 has been known as the GTK+3 port version, so you will be happy to read that this port is finally over. To be fair, we still have a few minor deprecation warnings here and there, but nothing like the hundreds we used to have."
If Blender could radically update their UI and UX after 25 years of the initial conception, I feel like any (FOSS) project could do it too, no matter how many options and technical details the software has.
Did the money come first? Or the redesign? I remember using Blender back in the day and it was really confusing. It seems amazing that anyone would have poured so much money into it back then.
Good question.
Blender lead and community created a huge innertia with projects and conquest to raise funding.
So having a vision comes first, then the funding, and after that a redesign.
Yeah a few studios started picking it up prior to the redesign because it was free and a lot of new animators/designers knew it because it was a free tool they could learn. That was all pre-redesign.
Their support got the ball rolling and then eventually Amazon and a bunch of big studios threw their weight in but I'm not sure how many of them were involved in the redesign.
4 sources of income: one-off donations and recurring donations (from individuals and businesses), subsidies and co-development funds from businesses, and subscriptions to their cloud service.
The fundamental difference between Blender and Gimp is that Blender started life as a commercial product, designed by 3D professionals for other pros. Yes, the interface was different and the learning curve hardcore, but it had an internal logic that enabled fast workflows when you’d mastered it.
Gimp was designed by open source hackers with no input from professional designers, or seemingly even any interest in their input. It never gathered any kind of momentum as a credible Photoshop replacement for professionals.
And that’s why Blender is getting donations: it’s become a serious part of workflows for all kinds of companies who have a 3D content pipeline. Meanwhile Gimp is still the awkward collection of hackers’ image processing pet projects piled into a clunky GUI that does nothing to enable the things that designers actually use Photoshop for.
I'm not convinced. The UI in early Blender was as arcane as any I have ever seen, worse than GIMP's by a mile. Contemporary commercial 3D software did not have the same quantity or quality of weirdness. (Remember SoftImage?) The commercial version of Blender failed in the marketplace, and after it was open sourced, it was not taken seriously again for quite a few years.
Blender's dogfooding efforts were a powerful force in both proving that the software was good enough (to make movies) and demonstrating how it could be better (for the animators who made the movies). I'm not aware of any such efforts for GIMP. What I have seen is roadmaps of what improvements they know they need, and timelines of years to improve core infrastructure to the point that their actual goals are within reach. Meanwhile, other software projects (both FLOSS and commercial) race past them and move on to more exotic and exciting features.
> The UI in early Blender was as arcane as any I have ever seen, worse than GIMP's by a mile.
That's just not true at all. GIMP's UI has no redeeming workflow. Even if you master it, you must still constantly navigate it's clunky menu of features.
Blender 2.x had an intentional UX flow. When you mastered it - which really wasn't nearly as difficult as whatever work you were doing with it - you could be very productive.
Blender 3.x didn't really change that flow. It only added some optional visual interface for the people who don't already know the keybinds.
GIMP's UI is perfectly fine to me. I frequently use it for editing, design, and even drawing, and I have no desire to use other programs instead. What's so bad about it specifically?
Every time you want to do a thing with the GIMP, you have to go find the specific thing-doer. That's not a really big deal, so long as you can remember where it is or what it is called; but it's really not good tool design.
To contrast, Blender has neatly organized every feature contextually. There are specific modes for organizing objects, editing meshes, sculpting, UV painting, etc. that each present their own smaller tailored UX. Everything that is an option (something you would edit with a text box) is under the properties window, in a contextually-organized tab. The entire structure of Blender's UI/UX is organized to match the conceptual UX of the tools it provides.
There was a lot of completely esoteric design software for workstations in the 1990s. Softimage was a paragon of user-friendliness, so it’s a high bar for comparison. (I still miss Softimage XSI and resent Autodesk for buying and then killing it.)
The Blender dogfooding effort is a reflection of the team’s background in actual 3D production and their commitment to a long-term dialogue with this userbase. Gimp never had that.
Blender is also really careful to NOT needlessly break existing workflows and also doog-foods their own software through having their own studio.
This is in stark contrast to the vast majority of UI-redesigns which tend to break existing workflows, remove features and are just ego-driven projects. You need to be a user of your own software.
I found that Inkscape mostly has everything where I expect them, but maybe I just got used to it. I wish the "filters" and "extensions" menus would be better organized since they appear to be just dumping grounds for all advanced features, but I thought the core functionality of drawing shapes and curves were reasonable.
Inkscape has a lot to work on as a "content creation" app, while in terms of being true to SVG, it's done a lot of things the way you'd expect.
And I think that's most of the disconnect in the UI, which the devs have gradually gotten over by adding shadow XML data in the SVG to support Inkscape features while always presenting a rendered result.
Still, the drawing tools aren't consistent about the units they use yet. There is a lot of stuff there, and some of it is just papercuts.
I had the same experience, and searching for answers using keywords was not very effective. There are so many features that the terms I guessed were often a different concept in GIMP, leading to a bunch of irrelevant results.
I have found that ChatGPT solves this problem very well, so I don't even try searching first anymore. I can verbosely explain what I am trying to accomplish, and it tells me "that is called X in GIMP, and here is how to use it: ...".
A recent example is that the Bucket Fill tool was filling in adjacent pixels that were a slightly different color than the one I clicked on. ChatGPT told me this is called the "threshold" and how to change it to 0 so it only filled exact matches. I would have searched for something like "gimp bucket fill sensitivity" or "gimp bucket fill precision", then had to read through a forum answer or the GIMP documentation to see that term.
> I would have searched for something like "gimp bucket fill sensitivity"
And you would have seen the correct answer if you searched this instead of trying to explain it to ChatGPT.
The first result of my Kagi search for that exact query is the official GIMP documentation. It provides the answer in the snippet.
> The Threshold slider sets the level at which color weights are measured for fill boundaries. A higher setting will fill more of a multi colored image and conversely, a lower setting will fill less area.
The second result is from graphicdesign.stackexchange.com and the snippet tells you that you might want to check the anti-alias setting if you want non-softened filling. That seems relevant if you want exact color areas to be filled with the exact color you picked as well.
Overall pretty happy with the first two results, I feel that they answered the question without even clicking away from the results page or trying to explain things to ChatGPT.
Excuses abound. "There are too many features" So? Do the work. Organize them. "GTK doesn't have xxx, doesn't allow yyy, we have to wait until GTK 5 comes out..." No? Just do the work. Add those features to GTK itself or find a workaround.
Open-source is built one patch at a time, so a big rewrite can never happen. But what's worse, to me, is that people build up this cognitive dissonance that it's some framework's fault that it doesn't have the right dropdown widget yet.
That's too simplistic of a view, there are way too many gatekeepers with poor UI design sensibilities which won't just merge your "just done the work to improve UI" contribution, which in turn leads to lower chances getting people to contribute such improvements
I didn't see the GIMP project speaking up when Glimpse was accused of being "woke". And also, there's zero chance that the GIMP project would ever switch to the Glimpse codebase. Forking things usually results in the original thing persisting forever out of spite for those who dared to fork it.
"Nobody is stopping you from contributing" is such a classic deflection. I don't know why people still rely on this old copy-pasta. First of all, who says I want to contribute? Maybe I'm perfectly happy using Photoshop. Is my opinion invalidated simply because I'm not a GIMP user? That's illogical. Secondly, actually, a lot of people would stop me from contributing. I just made the case that only a full rewrite would fix this situation. Do you think that the GIMP maintainers are going to be happy if I drop a full rewrite on them? Or do you disagree that only a full rewrite can fix GIMP? Make some claim, don't just fall back on your list of FOSS fanboy deflections.
Exactly this. They just only recently found the time to migrate to GTK3.
The last thing they need is people who have no wish to use their program or contribute to yell at clouds and insult their work without moving a finger themselves.
I think there's value is stating the truth, even if it hurts someone's feelings. It's not intended as an insult, but if people feel that way, maybe that's their problem, not mine.
The one worst thing in the universe that you can do to piss off the GIMP developers is to tell them it should be more like Photoshop. It's like telling RMS that he should develop Open Software for Linux, instead of Free Software for GNU/Linux.
Not at all, it's much simpler and much worse than that:
The GIMP developers have heard both kinds of arguments MANY times before, as well all the arguments for using pie menus based on usability and scientific measurements of controlled experiments and decades of experience developing and using user interface toolkits and applications, from me and many other people, and at this point they are just cutting off noses to spite their face, not listening to any arguments about usability or anything else, because they have decided that somebody else once hurt their feelings by asking for the exact same thing for the wrong reasons (or as you literally say, simply without extensive justification), so they got permanently huffy with their panties in a twist, and always say no to everyone who ever asks the same question ever again no matter what their arguments about usability or experience with user interface design.
Pie Menus: A 30 Year Retrospective.
By Don Hopkins, Ground Up Software, May 15, 2018.
That's even what your tone policing argument literally says, so you've just made my point for me! They've been asked in both ways many times before, yet they reject all the reasonable well justified requests, because they once had an unreasonable request (or simply brief requests missing pages of explanations and citations I like to provide, that they don't even bother reading anyway).
Not every user has studied human computer interaction and written many papers and articles about it like I have, and can articulate (or cares to take the time to articulate) exactly what their reasons are. They just love Photoshop or pie menus because it works well for them, and they can't explain why, or just don't have the time. And that's no excuse for not listening to their users.
The GIMP developers are TERRIBLE at listening to their users, which is a fatal flaw and mortal sin for user interface designers, and that's a hard cold fact. If they were competent empathic UI designers, they would have already pro-actively researched Photoshop and pie menus and many other competing designs, already know what the issues and trade-offs were, and make conscious informed decisions. But they're not, and they don't.
But fortunately the Blender developer are the exact opposite. For example, they've adopted the standard right mouse button click conventions and pie menus and other features that their users demanded, and they think deeply about the trade-offs and issues of making it more like competing products like Maya and 3dsmax, and they have very good reasons for doing things the way they do, and articulate those reasons clearly and calmly and maturely, instead of simply throwing temper tantrums and stubbornly inflicting revenge for people occasionally asking them for features impolitely or without sufficient explanation years ago, like the GIMP developers always do.
The GIMP developer's behavior is exactly the same line of argument I so often hear from racist Trump supporters, who claim they aren't actually racist, but somebody forced them to be racist because they were once impolite to them about their support of Trump (which they deserve for being racist and purposefully impolite to other people), so they got offended and doubled down, trying to blame their acknowledged racism on somebody else not being nice to them (i.e. tone policing), instead of taking responsibility for their own decision to be racist.
You don't get to be absolved of making stupid decisions on your own by being stubborn and not listening, just because you want to punish people for asking you not nicely enough once. Nobody forced Trump supporters to b...
If you really think that providing substance to argumentation is about tone rather than useful information, then we must be coming from two different planets, and this conversation has no way forward. So I'm sorry, I'll just back out. Seems safer that way. Good luck.
I think you're missing the point. There are two ways to interpret "GIMP should be more like Photoshop". One is to assume that the person saying it is out to get your goat. The other is to assume that they're making an allusion to the well-trodden field of people saying "Photoshop has better UI in <particular area>, let's do it that way". The fact that you chose the first one is, I think, what the above reply was getting at.
Between 2007 and 2021, I did a lot of technical support for GIMP users. So when I say that I know what people mean when they say things like "Stop inventing stuff and just copy Photoshop" or "Make the same menu items" or anything to the same effect, this isn't a bunch of hot air. I really do know what they mean, because I've had long discussions with people about all those things. A lot of those discussions involved angry people shouting at me at the top of their lungs that everybody needs free Photoshop and nobody needs GIMP, so the team should just copy Photoshop. Very few people were willing to discuss workflows and usability.
But seems like you didn't measure the one thing we're actually debating: Is Photoshop actually just a better UI than GIMP, or do users simply want what they're accustomed to. And you know what? It's an academic distinction, one that people who were actually interested in making something to enhance software freedom wouldn't care about.
This is extremely wrong. FOSS would be better if things weren't redesigned every other year from scratch. KDE, Gnome, MuseScore to name a few. I was a master of MuseScore 3 and the year I finally became 100%, they dropped support shipped the absolute shitshow that is MuseScore 4, broke every single one of my workflows and finally forced me to use lilypond full time. FOSS is a redesign-after-redesign shitshow just like big name software are. I just want my software to work today exactly the same way it worked yesterday and it seems impossible to achieve that.
I will forever be against weird “hidden” menus and even more against the idiotic replacing of clear, obvious text based menuing with bullshit, stupid, mentally handicapped “just memorize what our developers decided these images mean lol Hurr durr”.
Absolutely hate this redesign.
The correct response to a “too small viewport” for anyone serious is to buy a better monitor with a larger resolution, not to redesign menus in to bullshit obscurity.
A sufficiently complex menu is not really that discoverable, either - you end up having to memorize what category the devs have decided to file a particular function under.
Gimp menu system is reasonably logical (except perhaps some minor exceptions like having options under edit menu (but this is also problem with most of the programs)).
Menus used to have at least some consistency across programs. If you knew where an option was in one program, it was usually in the same place in another, or at least similar options were in similar places. The UI designers of the past understood that convention trumps invention. You shouldn't need to "discover" something in 10 different ways when you use 10 different programs. Now everyone wants to "innovate in UI design" and there’s no consistency between the programs you use.
It was probably Apple that led the "minimalist UI" trend, but at least Apple have consistency across their applications. The GNOMEs started trying to copy Apple's design cues with Gkt3/GNOME3 but completely missed the mark.
My problem with UX discussions as such is that there is no user context.
Removing "clear obvious text menu" might make it less friendly for casual users or first time users but makes space for stuff that experienced users have use of.
Sufficiently experienced user needs to have menu organized the same way between versions if they use it for years they already and know what they want, probably just use keyboard shortcuts anyway.
Discoverable menu items in complex menu IMO is not some holy grail.
I think people read too much in "Apple design" and expect everything "should be easy". If you are first time user of CAD or advanced graphics manipulation application you are going to have to put time to find out tools and where they are.
For example I like foldable left-hand menu on web apps where if I know the icons meaning I can fold it but for first time use of application I get text+icon.
The one thing I can say is that fuzzy search like IntelliJ is a really good interface for experienced workflow. Maybe an AI fuzzy search would help with discoverability.
I was thinking this would be a good use case for AI. Perhaps you could have a Gimp co-pilot that makes suggestions about what you could do with the image after uploading it to a server somewhere.
Then we would know if the AI is more or less intelligent based on whether it can actually figure out how to find that specific blur function within all of the various dropdowns and sub-menus.
UX affordances are different when the price is zero. I learned GIMP the hard way, first because of Photoshop's pricing, and second because Photoshop's UX wasn't that much cleaner when it came to doing anything outside of trivial layer operations.
GIMP has one of the best user interfaces of all community driven open source software. I frankly can't think of any that are better, now that Firefox followed Chrome in hiding all its most important features.
The UI to Photoshop is horrific (and unbelievably old and crufty, though not as bad as Illustrator.) I used to be convinced that the reason people think it's reasonable is Stockholm Syndrome. Now I'm convinced it's because most Photoshop users only ever use Photoshop/Illustrator/InDesign, and simply aren't familiar with other software.
It's bizarre that a search bar that unfolds a vertical menubar when highlighted but unfilled is supposed to be a great advance. It's so unimpressive that I 1) don't mind it at all, and 2) think the menu aspect is useless. It's just a menu command search bar; a good UI library could construct one automatically. Stick it in a corner, or automatically open it when people start typing with no obvious object. It's a triviality.
What bugs people about the GIMP is that it's not Photoshop. All of the GIMPs menu options are placed in eminently logical places. although it's a grammar that probably makes sense over time. Photoshop options are mostly placed randomly, and some of them turn out to be ads. That's not a huge dig at Photoshop, because it's pretty amazing that they ever fix or move anything with so much industry adoption, and adding things has to be a nightmare.
But the GIMP puts things in places because they make sense there. They don't have the base that would get enraged if they moved things. It's extremely telling that when put to specify improvements that could be made, the suggestions are either trivial, like
1) a search bar, or
2) an extra statusbar above the statusbar (in case they want instructions over their instructions), or
3) to make it single-window (because just not moving things is not enough, they have to be prevented from moving things),
or they're just:
4) "Make it more like Photoshop! When I use Photoshop I know where things are, and when I use GIMP, I don't!"
The GIMP is wonderful and its problems are technical: it has lacked some of the ability of Photoshop, but that gap slowly but surely continues to close.
edit: I can't believe I forgot the worst one: "Why when I click Save does it save my project, but when I want to export a file based on my project, I have to pick Export?"
I'll admit I'm a novice with Photoshop, I've never used it for more than a moderately complex task. Usually simple cuts and meme making type stuff. I also once designed a poster that required me to make a vector background and arrange some ripped svg elements from a old swf file.
Every time I try GIMP it's a nightmare. Even the simplest thing usually makes me find a video to explain where to find it. Cutting, pasting and layer management is a pain. For super simple stuff I use Pinta and anything marginally complex I use photoshop and it's always felt easy.
I know that's hardly scientific but I've always seen photoshops interface as good.
i used to have a lot of trouble finding things as well until i discovered the command pallette (the / key opens it). now i do nearly most things just by fuzzy searching for them
Will a web page be discoverable if its server blocks all search-related robots?
Now if search were the only means of discovery, that would be bad. Imagine if no two pages linked together: everything had to be found in an index. That's a strawman though.
Search complements other modes of discovery.
How about REdiscoverability. You remember some feature in the program and some words related to it, but ... where the heck was it? Search can help.
If we are not talking about issues (that don't apply to UI search) like pages being low-ranked out of existence, I would say all pages are discoverable through search.
In the sense that, for instance, if I find a great Greek restaurant I didn't know existed, that counts as discovery, even though I already know Greek food and was searching for that.
That's the sentence I thought you meant, but you're just reading it wrong. This doesn't support your radical statement. "General knowledge of what you wantl is perfectly fine and doesn't block discoverability, that's also how you discover a lot of things on the web
It's also wrong, for example, you can discover all the file operations by typing in "file" in the search box even if it's your first rodeo
Also, search box can list all the commands as some commands palettes do in other apps, so you can just scroll to discover 100% of listed commands. It can also show categories, that's, for example, how I discover 100% of commands for some plugin by typing its name and reading the list of commands in the search results
Btw, this problem doesn't go away with the menu (like mentioned in another thread): it's hard to discover by looking through a huge nested list, especially when this list is poorly organized like in Gimp, and incomplete, and not context dependent
So no, search is on the same side of discoverability, and the op doesn't claim otherwise, that's your mistaken interpretation
Dishonesty is not acceptable behavior, nor is being coy and snarky.
If that's the sentence you thought I meant, then pretending you didn't know what I was talking about was a lie and you should find somewhere other than HN to hang out.
So why were you being coy in your reference then? And it's rather dishonest to conflate knowledge with a guess (by the way, I still don't know which part of "this thread" you meant, I didn't find another statement like yours)
So you mean that I should loop through [a-zA-Z0-9]* to search which name is defined so that I can use that function? What pills do you take, I want them.
Take a sugar pill and use the rush to use at least one modern app with a command palette, you should hopefully understand the nonsense of your a-z claim before the effects wear off
Discoverability is the measure of how well an application presents features to you that you didn't necessarily know were there.
A menu may be a list of features, when you open the menu you discover those features.
A search box is a box. It shows no features. Search results might show features but those features might also not relate at all to the task you're doing, which means they're out of context. That's extremely poor discoverability. You can find all the features, you can't discover them.
GIMP does have search, just hit / and you can find any action.
The problem with search and discoverability is that search requires input from me, whereas discoverability means that the program explicitly offers its features to me. With search, I would never discover some handy new feature I wouldn't think of myself, or something that is named differently than I expect.
Hunting through a menu, while not optimal, allows me to view a 'catalog' of all the features.
The menu doesn't resolve these issues: if you don't know that yank is copy, seeing it in the catalogue won't help much, especially if instead of the usual cut/yank/paste that could give you a hint, you have cut/paste is in some "destructive edits" menu, and yank is elsewhere
And you can very well not have a command in the menu, after all, coding to have a command automatically dumped in a global list is easier that remembering to add it manually to some menu category
And the input to search can be blank: you'll get the same catalogue with the same categories like in the menu (watch the video, the popup search has all the menu categories), so there is almost no difference, so there is nothing magical 1000% discoverability in this menu design
Universal search in UI is cool, and I’m all for it, but it shouldn’t be the only/primary way of accessing tools as tool discoverability is very low. The author tries to deal with this by putting the a menu next to a search bar and putting hints in the bottom menu (which I don’t think would really work here, as raster tools are less selection-specific than 3D tools). Search fixes the speed-of-access issue, but doesn’t help discoverability very much, as users still have to hunt through highly nested menus.
Looking at the screenshots here, I don’t think you actually need search to make those menus more manageable. One screenshot of current GIMP shows a menu tree that looks like “filter->render->noise->solid noise…”. I think you could probably combine the entire noise submenu from that tree, and make it instead a segmented control on the actual “noise” dialog that chooses your type of noise. I suspect dropping the “render” level as well would also be good. “Render” is a bit of a jargon-y term in the context of graphics editing, and I don’t think it means much to most people using it. Furthermore, the top “filter” menu isn’t actually all that long, and people generally prefer wide flatter trees to narrower deeper trees. So, I’d pitch for a simpler menu that would just be “filter->noise…”. By flattening and combining, I think that menu could be made much more usable and discoverable.
How do you support discoverability, sleek work areas with minimal interfaces such as search, and power users at the same time? What does that look like?
Menus with lots of options, properly labelled and organized, and displaying keyboard shortcuts next to them, like pretty much any software written in the 90s. Tooltips when you hover over things. Actual documentation built into the software rather than tucked away in a man page or only found in a forum you discovered by searching for your problem.
I don't think it's power users these designers are trying to cater for. They make things more difficult for power users by hiding useful options in some tab in a modal settings dialog, which is a PITA to find and click if you need to change it often. Often they remove something completely from the UI and you need to go find the config file and manually edit some text and restart the program to get functionality back.
They're trying to cater for novices - they think too many controls on display is going to confuse or overwhelm them. I blame Barry Schwartz[1]
If they were trying to cater for power users they would let power users configure their interfaces to suit them. Modern interfaces are "fixed" in the image of the designer, and screw you, the user.
> If they were trying to cater for power users they would let power users configure their interfaces to suit them.
Exactly, and both in the immediate UI (like, ctrl-right click on a menu and enter the new shortcuts right there) and in config files to allow for batch search&replace editing
Old school autocad back when I had access you could configure menu's yourself. I see no reason that you couldn't do that with a modern application.
One thing I did with GUI I wrote for a customer was added a notes item to the right click menu on every control. Click it an editable text box shows up. With an option to mail me the notes data so I could incorporate it in the next release.
Universal UI search is great, and at this point it should be present in all but the simplest applications. I first saw it introduced in Google Docs, and it's precisely for things you suspect exist, but it's not even remotely clear which menu, submenu, or dialog it's in. (Apple OS Settings is another great example of it.)
E.g., you want to apply a hanging indent in Docs? Just type "hanging" into the menu search, and it shows "Indentation options". It's smart enough to know that hanging indentation is an option within the dialog that shows up there. And the menu search seems to have a large range of synonyms, so typing "picture" brings up lots of "insert image" choices.
But it bothers me that even in Docs, almost nobody knows about menu search because it's hidden under the "Help" menu, rather than being a nice prominent rounded search box in the upper-right corner like you'd expect.
Menus are great for discoverability (so do not get rid of them), but frequently you know what an application can or cannot do (e.g. you assume a word processor can do hanging indents or watermarks), but you don't know where exactly it lurks in the menus or which tab of the settings dialog, and don't want to waste two minutes hunting for it.
It's time for a universal search box to exist in every major desktop application. Apple and Microsoft really need to take the lead here to provide standard API's and UX components for this, and it saddens me that they haven't, and continue to show no signs of interest.
macOS has had the ability to search menus for what seems like a decade. It should be a feature of the toolkit, not something apps need to implement themselves. This doesn’t extend to other UI elements (like System Prefs/Settings), but I agree that it should (and again, should be a toolkit feature).
> macOS has had the ability to search menus for what seems like a decade.
Wow, TIL. Talk about a hidden feature.
So it turns out it's under the "Help" menu, and it just says "Search". I had always assumed that this searched help topics, not menus.
But it's also pretty miminal, seemingly without support for synonyms or features inside of dialog boxes -- e.g. if you type "pref" it won't find "Settings". It also doesn't have a keyboard shortcut to trigger it (like Docs).
So I think there's still a long way to go to make it a central UX feature.
Why on earth isn't that keyboard shortcut shown in the search box, the way every other menu item with a keyboard shortcut has it displayed?
It boggles my mind how hidden this all is.
All these years, I could be picking menu items with my keyboard instead of my trackpad? What the hell, Apple.
First Apple hides the feature behind a search box that you don't usually ever see and then wouldn't ever guess that it searches the menus, then it goes even further to suggest there's no keyboard shortcut for it, when there is one. What a complete and utter UX fail.
Mac OS is chock full of undiscoverable keybinds that perform functionality that would be useful for people of all skill levels. Moreso then Windows or popular Linux Distros, in my opinion.
What is frustrating to me, as a long time user, is that OS X used to come with books that would cover what was new.theblast oneni can remember was from 2008 or so and by that time they became leaflets with the major new features.
I’m sure I miss dozen of things with each yearly release now if I didn’t catch it during a keynote or stumble across it somewhere on the web.
Apple not doing their homework here, definitely. What I do to substitute is to read the in-depth review of every new Apple OS (not just macOS, but also the others) on Ars Technica. They are usually published a few days after the x.0.0 release, and they cover pretty much everything that’s new or changed.
In their partial defense, I don't think putting the search bar in the Help menu is either particularly crazy or particularly hidden. Putting it in some dropdown menu is probably the correct UI option, and out of the menus that (nearly) all applications have, "Help" is a pretty reasonable choice. Is it super obvious? No, but I mean, "File", "Edit," and "View" are objectively worse, so that only really leaves the "[Name of Application]" as a possibility. Which would also be defensible, but I'm not sure it would be better.
(Now, the complaint that I've seen elsewhere -- that using that same search field to search actual documentation is basically useless -- is an entirely different kettle of fish...)
>The whole point of pie menus is to be "self revealing", supporting discoverability and browsing and prompting and gently training users to quickly use the gestures without looking, through rehearsal. They solve the problem of gestures being invisible and impossible to discover and learn.
>>Pie menus are a self-revealing gestural interface: they display multiple options to a user and direct them to select one.
>>Users operate the menu by observing the labels or icons present as options, moving the pointer in the desired direction, then clicking to make a selection. This action is called a "mark ahead" ("mouse ahead" in the case of a mouse, "wave ahead" in the case of a dataglove).
>>Repetition of actions and memorization of the interface further simplify the user experience. Pie menus take advantage of the body's ability to remember muscle motion and direction, even when the mind has forgotten the corresponding symbolic labels.[1]
>However Apple has never adopted pie menus, Steve Jobs thought they sucked, and Donald Norman has never been a big fan, and he totally missed the point when I tried to explain it to him at Ted Selker's NPUC workshop.
>I had the honor of meeting Steve Jobs at EduCom on October 25 1988, when he released the NeXT machine. Sun had lent me a workstation to demonstrate NeWS software in their booth, right across from the NeXT booth, and Ben Shneideman brought him over for a demo of the stuff we'd developed at HCIL.
>So I gave Jobs a whirlwind tour of pie menus, the NeWS window system, UniPress Emacs and HyperTIES for about half an hour. Jobs was jumping up and down, pointing at the screen, and yelling "That sucks! That sucks! Wow, that's neat! That sucks!"
>When I explained to him how flexible NeWS was, he replied "I don't need flexibility -- I got my window system right the first time!" But I gave him a NeRD button, anyway (which I'd made for NeWS window system NeRDs, but he liked because it had a lowercase "e" like NeXT).
[...]
The GIMP developers are even more stubborn and insular-minded than Steve Jobs, but with absolutely none of the design skills, visionary creativity, empathy for users, or obsession with usability.
Glad you asked! ;) The comparison is with gestures, which are not self revealing. Linear menus don't support gestures, selecting without looking at the screen, mouse ahead, display pre-emption, or rehearsal, the way pie menus naturally do. Pure gestures don't support browsing, reselection, or error correction, and they don't make efficient use of "gesture space".
Pure gestures alone (like swiping in different directions on an iPad or phone, or the more complex unistroke gestures for writing letters, numbers, and symbols in Palm Graffiti) don't have a natural way to reveal themselves or prompt the user which gestures are available and what they mean, or a way to train users how to use them quickly with gestures.
Pie menus also support "reselection" and "browsing", so if you make a mistake or change your mind, you can always correct your gesture in-flight, and you can browse around pie menus to reveal feedback about each item (i.e. text in the item or menu center, or immediately applying the currently selected item to the visual state of the application, previewing the effect of the selection without committing it yet, so you can still change or cancel it).
Users learn to use pie menus in three stages: pie menus lead, follow, then get out of the way. This is called "rehearsal", because each stage naturally and transparently trains you to move on to the next stage of expertise. So the novice's time using pie menus in the "leading" mode is not wasted, but trains them on to the "following" and "getting out of the way" modes.
At first, a novice user clicks the button or presses and holds to pop up a menu, then looks at the items, decides which one they want, moves the mouse in that direction, then clicks again or releases the button. That's leading, and it's self revealing.
Then a more experienced user who remembers the direction of the item they want clicks or presses then moves in that direction (mousing ahead but waiting for feedback before confirming). They wait for the menu to pop up, look at the screen to make sure they're selecting the right item, then if it is they click or releases the button to confirm, or else make a correction. That's following, where pie menus reveal themselves showing the selected gesture, then let you confirm the selection if it's right, or or change it if it's wrong, giving you more confidence to move on to the next stage.
Finally an expert user remembers the direction with confidence, then smoothly clicks or presses, moves, and clicks or releases, in one quick continuous gesture, to select the desired item without even needing to look at the screen. That's getting out of the way. That's where "mouse ahead display pre-emption" is useful.
Compare that with linear menu keyboard shortcuts that are a totally different physical action than selecting from menus with a mouse, so selecting an item from a linear menu with the mouse (novice) is not rehearsal for using its shortcut with the keyboard (expert), and that does not train your muscle memory by rehearsal to smoothly move from novice to expert, the way pie menus do.
Pie menus should support "mouse ahead display pre-emption" so that when users select from them by gesturing quickly without hesitating, they don't even bother to pop up the menu, just provide some lightweight unobtrusive feedback like showing the item label next to the cursor in a tooltip, instead of popping up the whole menu and covering up other windows.
The mouse-ahead stage doesn't require a high-cognitive-load attention-grabbing hand-eye feedback loop, so you can "mouse ahead" the same way you "type ahead" without hesitating between every keystroke and looking at the screen and waiting for the character you typed to draw to make sure you typed the right character, before typing another one.
Imagine how slow it would be to type, if none of the keys had "self revealing&quo...
> e.g. if you type "pref" it won't find "Settings".
I find the OSX search feature close to useless as a "help" feature because of this.
I came to the realization that it's more like a power user shortcut tool than something to help new users. If you know exactly what you're looking for and exactly what the application calls it then you can skip navigating through nested menus.
Exactly. It requires a perfect match. No ambiguity. You need a more fuzzy search where you type in the concept and it gives you ideas of what to use. And if don’t even know the concept, well… ChatGPT?
> But it bothers me that even in Docs, almost nobody knows about menu search because it's hidden under the "Help" menu, rather than being a nice prominent rounded search box in the upper-right corner like you'd expect.
They changed it recently. Now it’s a nice prominent rounded search box in the upper-left corner.
Thanks -- I've never seen it, so I got curious. Just tried zooming way out in my browser, and it shows up once my browser zoom is down to 75%. It does appear, but only when there's already space for every other toolbar button already -- so only on larger screens, not 13" laptops.
But it does turn into a magnifying-glass icon even on smaller screens. I just never thought to click it -- I would have guessed it would bring up a zoom menu or something. (The ever-present confusion around when magnifying glasses mean search, find, or zoom...)
I started with rhino3d a while ago. I like that everything can be done by typing a command. By default your cursor is in a command field and everything you type instantly searches for a command. There are menu items as well. But once you get used to typing commands its so damn fast.
Yes! I also encountered this in Rhino 10+ years ago and instantly implemented in multiple online projects with great success.
What's crazy is that i'm pretty most times wasted on a computer is from "where is this setting, how do i do this" type stuff, in users ranging from experts to the elderly.
It's bizarre to me that this hasn't been implemented all over faster. Instead cloud interfaces have become even more esoteric in my opinion.
All functions on a computer should have a tiny descriptive string you can search for.
The GUI paradigm from the last 30 years in was a mistake with nested stuff just hiding in random places. CLI was a bit better when you could pipe / search etc. but for most people Universal Search is it.
My problem with GIMP is that there's too many ways to access controls and some controls only appear in certain menus. You've got the iconographic tool picker which has submenus on right-click for some tools. Then there's the classic menu ribbon at the top which has most things you expect. Then there's the right-click context menu inside the canvas that has a subset of all other menu items. And then you have inscrutable hotkeys. Some actions are reasonable, others are not. There's too many hotkey layers with modifier keys and some actions which should be on the same layer are not.
Then there's the escape key. Sometimes it does what you want, other times it just gives you an error ding with no other information.
The core problem with GIMP is that the interface is bad. No two ways about it, it's just bad. It needs a total redesign, but that would be unacceptable as it would alienate evryobe who has already learned it.
As an editing program, GIMP does everything you need and then some. It's fully featured and functional, just not usable.
That said, GIMP is still my only choice for photo editing. All the other options are worse in different and mostly worse ways.
I’d say it’s biggest core issue, even more that the UI, is that it’s basically harecoded to work with generic RGB. No native CMYK or good support for color management.
the way I used to crop photos they moved/broke, so now I have mypaint installed so I can use it for cropping. Then I switch back to gimp. It's used, but not usable, a bit like a used car.
Out of curiosity, what's that? Are you by any chance referring to the option that allows not removing cropped pixels? Well, it's an option. You can disable it.
There’s a huge amount of head room to improve search though. For each of the items we can add all sorts of synonyms and descriptions so that users at any level can find the tool they’re looking for.
And we can even add crude customization to the search. Gimp can easily remember the prefix-tool click pairs, so that you don’t even need to type “cropping tool”, if you type “cr” Gimp will remember which tool you clicked last time.
> So, I’d pitch for a simpler menu that would just be “filter->noise…”.
Noise being in the Filters menu never made sense to me. Noise is an input source. It's like classifying the paintbrush tool as a filter. I shouldn't be too hard on GIMP for that I guess, as Photoshop puts it under filters as well.
IIRC a bunch of them didn't even just go monochrome, they removed small hints to what it actually did (like little arrows that showed what the transformation actually was). Switching back to the old icons was also the first thing I did.
I'm curious how you use gimp. Do you use mathy/programming/terminal kinds of editing - stuff applied over the whole image with little mouse usage and mostly setting dialog parameters.
Or do you do little edits with the mouse, painting masks, selecting regions with the mouse, and generally using the mouse/pen a lot?
I have an old wacom tablet, so its painting masks mostly. back in the early days, I did all the things that photoshop 6 could do. Along with a brilliant plugin called resynthesiser[1] which I am horrified to find out is 23 years old.
I've never really used the scripting functions apart from applying global effects.
Nowadays I use it until I need illustrator hard enough to move to the mac downstairs. but most of my photo editing is now done in lightroom.
> And the same applies, for example, to moving selections, because in GIMP, you need to press Ctrl+Alt and then drag to move the contents of the selection, which is not how people expect this to work coming from many other applications. Again, the only way they can find this out is by watching a tutorial or reading the user manual.
This is a shortcut for Cut+Paste, which I always use anyway because I find it more intuitive.
It's better than what currently there is but why does open source software have to have such bad UI? what are those lock and checkboxes? a 5 year old could come up with better icons...
What's up with the thick lines around UI elements? it all looks so 2008.
It sometimes looks to me like absolutely 0 designers are actually involved in open source, at all
GIMP is a power user tool, like Photoshop, or Excel, or a Bloomberg terminal. If you don't need all that, Canva or the photo editor on your phone will offer a simpler UI.
I think that just shows how terribly non programmer friendly open source development is, designers and the like do not touch places like github, the whole model needs a redo to make it easier for non programmers to participate in open source development
LLMs on consumer grade hardware are a thing and will become more so. Something that only needs to understand the space of the application is certainly attainable.
Whoosh. That was the sound of you missing a hilarious joke. I guess you weren't around slashdot back then. Fortunately it's 2023, and I have at my disposal an LLM to explain the joke that doesn't necessarily require such an extensive computing setup.
User:
Explain the joke.
ChatGPT:
The joke here revolves around a classic internet meme that originated from discussions on Slashdot, an online community similar to Reddit or Hacker News but older and more focused on technology and science. The meme is about creating a "Beowulf Cluster," which refers to a network of computers configured to work together on complex tasks, effectively creating a powerful supercomputer from less powerful individual machines.
The original context for this meme was discussions where someone would invariably suggest, often irrelevantly, that a problem could be solved by creating a Beowulf Cluster. It became a running joke to propose a Beowulf Cluster as a solution to virtually any tech-related problem, regardless of whether it made sense or not.
In the conversation you're referring to, when "timbit42" mentions a Beowulf Cluster in response to the idea of integrating Large Language Models (LLMs) like GPT into applications like GIMP, Photoshop, or CAD, they are likely invoking this meme. The joke is in the overkill of suggesting a massively parallel computing solution (like a Beowulf Cluster) for integrating an LLM into a software application, which is a task that doesn't necessarily require such an extensive computing setup.
Universal search is great, as is the overall command pallette idea, every app should have it
Althout the usual menu navigation mechanism should also stick around since it provides consistent invocation of a command with a sequence of keybinds (like File, Open). Fuzzy search doesn't do that since you can match something else. Key combos require too much memorization
(though it doesn't have to be the typical horizontal menu at the top, you could have a "modal" navigation mode in the same command pallette)
And to answer the question: of course it's possible, just highly unlikely
Horizon EDA is really fantastic and the first usable open source EDA tool I've used. (I've not tried LibrePCB yet so that may be ok, but I've tried all the others; they all have awful UX including Kicad. A lot of the commercial tools have insane UX too - look up how you copy & paste in Eagle.)
Solvespace is the only usable open source CAD software I've found and I have tried all of them. Unfortunately it has some awkward limitations (no bevels or fillets is probably the biggest).
If he can take the excellent Solvespace constraint solver and make something usable that would be amazing!
Does this man ever worked with photoshop? What is he talking about? Of course there is a menu, just like in PS. Of course it is overwhelming at first. The biggest reasont most of the UI/UX sucks, because those who create the program never actually use it day by day. So easy. Use your own program and whenever you get frustrated it shows you that you have done something wrong or awkward and it needs adjustment. Another important thing is to drop the "this must look and feel different than photoshop" stance (more vs less) and it will be a-ok. And don't be afraid to borrow things from the bigheaded ones if that works well.
Krita and Gimp's biggest issue is that most of the tools are implemented in a non intuitive way. Everything is a disorganized mess. And since PS doesn't run under linux, this gets on my nerves.
For example in Krita you can't resize a crop rectangle with the mouse that holds its aspect ratio... WHYYY? And why does the crop tool forgets the previous size values? Little things like these show that the creators NEVER EVER use their own fucking program.
I think that’s right. Every time I go look at it I just marvel at how awful it is, like an alien designing photo editing software by looking at some screen shots and feature lists but never editing a single image.
Compare with Affinity’s software - they are more consistent than present day Adobe but copied all the good, same as Adobe did with Quantel.
> Krita and Gimp's biggest issue is that most of the tools are implemented in a non intuitive way. Everything is a disorganized mess. And since PS doesn't run under linux, this gets on my nerves.
Do you mean non intuitive or just not the same as PS. 99% of complaints I see about GUIs (most commonly OSS ones, because people are less likely to criticise choices where they invested money) are that they do not function like another piece of software.
> For example in Krita you can't resize a crop rectangle with the mouse that holds its aspect ratio... WHYYY? And why does the crop tool forgets the previous size values? Little things like these show that the creators NEVER EVER use their own fucking program.
Are you sure? IIRC you just hold down the ctrl key while dragging to preserve aspect. Do I remember wrong?
I started with “serious” image editors on Paintshop Pro, not Photoshop, and have used Gimp several times as much as I’ve used Photoshop.
Gun to my head, have to do some unknown-in-advance image editing task, I get to pick the software, but can’t look anything up, I die if it takes far too long? I’d pick Photoshop. I might survive with PS. Near-certainty I’m dead with the Gimp, hell I might be dead with Gimp even if the task is incredibly simple. It’s not that it isn’t like PS, it’s that it’s UI gibberish.
Try editing 10 images in a row with Krita and you'll see the issues right away. Layer handling, selection handling and tool placement is cumbersome, to put it mildly. Maybe invite someone who has extensive experience working with photoshop and watch how often he starts to curse or ask for help and whether he uses the gun to shoot himself in the head. Then change things accordingly, if the creators don't use their own program...
I worked with Gimp ~ 1 year ago, not touching that again until I feel the need to flagellate myself.
Not saying you are necessarily wrong about Gimp possibly being able to copy some of the good ideas from Photoshop. However, you basically confirmed what the GP said. If you suggest to put your usual Photoshop user in front of Gimp, without prior experience, then they are bound to walk into unexpected design decisions. Just like a Gimp user would, trying to find things in Photoshop.
Confirming what the GP said? This is all misdirection. Bottom line the GIMP UI/UX is garbage. There are extremely few people that have used a variety of image editing tools and claim GIMP is actually better. That’s all that matters really. This isn’t some rhetorical exercise.
The previous poster was talking about Krita (and the one before that Krita and Gimp) and while I agree with some of the criticism of gimps UI, I stand by my comment a lot of that criticism is based around "it is not like program X, that I'm used to".
I mentioned it in a different post, blender is the prime exhibit for this, its UI received even more criticism than gimps. Now that it has become the (or one of the) most popular 3d modelling tool, most of these voices disappeared, because it has become the first entry point and people are not used to some other way of working anymore.
Blender and Krita fit the different-but-not-bad workflow defense, but GIMP's is outright terrible. Instead of the specific buttons, compare how many steps it takes do something in GIMP vs PS. For almost anything, it's either >2x as long, or simply can't be done.
Blender underwent a huge UI overhaul that brought it closer in line with software like Maya. They even made left-click to select the default which was a huge turn off to newcomers.
If anything Blender proves that paying close attention to UI and making it mostly align with user expectations matters.
Wat? Blenders UI was revamped. Even so, prior to the rewrite it wasn’t such a sorry mess as Gimp, it already had some professional adoption.
And my point is, regardless of those claiming gimp sucks because it’s not what they’re used to: it absolutely does not matter an iota because there is near universal acceptance that it’s terrible for anything but toy work. UI aside, internally it isn’t fantastic either, a problem that blender didn’t have.
There are extremely few people who work in image editing who didn't learn on Photoshop, and aren't required to use it on a daily basis because of industry standards (or differences in capability.)
It's like people who speak English talking about how everything in Spanish is in the wrong place. It's the cheapest way to bikeshed: make it more like the thing I know already!
I don't do graphic design any more, but I started with GIMP - when I was first able to try Photoshop (pre GIMP redesign) it was awful, nothing made sense, nothing was where it should be. In contrast, when I first used Corel Draw it seemed intuitive.
Just like using a Mac after having been a PC user; or being forced back to MS Windows after using Linux/KDE for a couple of decades.
I used to use Inkscape heavily, but having not used it for a few years, I go back and the UI has changed, similar experience; I feel lost when I should feel capable.
Photoshop was one of the first applications that I noticed using the 'give it free to college students to capture the market' technique. That works so well because it takes a couple of years for for you to adopt the software as an extension of your way of thinking - changing application means a productivity loss, and a feeling of incompetence, and no professional wants that unless they can clearly see an ultimate gain.
> Just like a Gimp user would, trying to find things in Photoshop.
I'm double commenting in this conversation but I was a GIMP user in high school and college before switching to photoshop. I specifically remember thinking how much nicer it was that everything in photoshop was where I expected it and worked how I expected.
> Maybe invite someone who has extensive experience working with photoshop and watch how often he starts to curse or ask for help and whether he uses the gun to shoot himself in the head.
The extensive experience working with photoshop is a problem in itself, not a symptom. It sets expectations, and when they are not met, frustration ensues. But the photoshop UI is not the most intuitive one, just most familiar to this kind of person. Those are two very different things.
I understand the frustration, for the same reason I cannot work with Darktable. In some aspects and basic organization it is similar to Lightroom, and when I start using it as Lightroom, it leads to the same frustration. But that's not because the Darktable folks did something wrong, but because I cannot act on my habits from different software package and my expectations are not met. Someone, who doesn't have the same habits and doesn't have to unlearn won't have the same issues.
As somebody who has worked in prepress full time, almost nothing in Photoshop makes sense, I just memorized it. I can always find what I need in GIMP. Photoshop is a necessity because it does things that the GIMP can't do, not because its UI is in any way better.
I used GIMP for about 5 years before switching to photoshop. Even knowing GIMP inside and out, and knowing nothing about photoshop besides what I learned from GIMP, photoshop ended up being faster and more productive for me in under a week.
> For example in Krita you can't resize a crop rectangle with the mouse that holds its aspect ratio
I've never used Krita, but I was skeptical that it can't do this, so I just now installed it and gave it a try. It does have this feature! I made a crop rectangle, then right-clicked on it. A little menu popped up, titled "Crop Tool Actions". One of the things in the menu is a checkbox labeled "Lock Ratio", which was unchecked by default. I clicked the checkbox, and then I could resize the crop rectangle with the mouse without changing its aspect ratio.
Took me under a minute to figure out, having never used the software before or read any documentation. I'd say that's one sign of a decent UI.
NO RIGHT CLICKING! Nobody does a right click on a crop rectangle. Modifier key. Like you keep shift pressed and it preserves the aspect ratio. Nobody will do another click, then select a menu, then whatever. That's the issue. If you have to edit 100s of images these extra you go the menu, then the submenu, then click, then blablabla, then powpowpow, takes a lot of time. Streamline the user experience. You can only make it better if you use it daily and change the things that frustrate you. If these things doesn't frustate you, and do these over and over and over, then you are a robot and not fit for UI/UX design, so easy.
Alternatively it might be the fast that its budget is literally millions of times smaller and with a reasonable budget one would actually hire people instead of hoping random forum talk found its way to implementation via diffusion.
An analysis of a particular project includes its scope, existing code, existing developer resources, the time they have available, the things they themselves are familiar with/good at. Any analysis that involves purely looking at a competing project is probably not even wrong.
The gimp project has provided a decent and useful tool for about 28 years whereas most new projects started from scratch die shortly. A from scratch rewrite would be a massive undertaking which might exceed the available resources/skills and might simply kill a useful project rather than producing a better one.
I have used both and don't find the difference so huge. Besides photopea doesn't have a quarter of the functionaliti as Gimp, is afaik not controlable from the cli in batch mode. The scope is completely different.
Modifier keys were the first thing I tried (because that's how I learned to do it in GIMP and Inkscape when I was in high school). When that didn't work, right-clicking on the crop box was the next thing I thought to try. It's a total of 2 clicks: right click to open the menu, then move the mouse down 6 entries, then left-click on the checkbox.
But also, it's my understanding that Krita is not a photo editor, but rather a digital painting program; that any ability it has to edit photos is just because digital paintings are stored in the same file formats as digital photographs. Saying that Krita is unsuited for editing hundreds of photographs is analogous to saying that Visual Studio is unsuitable for creating ASCII art. There are other tools that you're supposed to use for those tasks. For editing hundreds of photographs, I understand Adobe's Lightroom or Bridge to be the intended tools, not Photoshop, nor any tools which are highly similar to Photoshop (GIMP, Krita, or otherwise).
> Does this man ever worked with photoshop? What is he talking about? Of course there is a menu, just like in PS.
I'm the OP and for the life of me I can't figure out what you are talking about. Seems like you are conflating GIMP and Photoshop and reading the post as if it suggested that either GIMP or Photoshop don't have a menu, which is absurd — there was no such claim.
> Another important thing is to drop the "this must look and feel different than photoshop" stance
There has never been such a stance in the first place. As far as I can recall (which is about 20 years back), the stance has always been "please explain why your proposed change is good, don't hide behind "because this is how Photoshop does it", it's lazy".
Just in case author happens to read comments:
There's this sudden brick wall of understandability in the "Interaction Hints" section. It's not clear what the visual hints are in the screenshot because there's a number of UI elements present. And "obviously" is carrying too much load, you'd have to be be familiar with Blender to know.
It's somewhat ironic that the author is essentially proposing a blender-like UI for gimp, considering that blenders UI is one of the most maligned UIs out there.
For the record I think the blender UI is pretty genius for an extremely complex graphics program and it could also work with gimp. Also the loud shouting around blenders UI have died down a lot in recent years, which I attribute to 2 things:
1. the great work done to make the UI more discoverable.
2. Blender having become almost a standard so there is lots of tutorials and it's now much more often the first 3d graphics program that people get exposed to (hence less it doesn't work like Maya,... complaints).
What does "blender's UI" even mean these days? It's been completely revamped since I last used it, which personally is annoying since I have no idea how to do anything in Blender any more, but objectively is great because the old UI was... challenging... and now it seems to align much better with other professional 3D software.
Unity 7 HUD could search the menubar of any application. I was quite good at guessing the name of the function I wanted, far better than I was at finding it in menus. It looks like MATE, XFCE and i3 still have this.
Since moving to 10-bit color, I've had to abandon GIMP because it doesn't support it. It's the only application that's giving me trouble so I've just switched over to Krita for occasional image manipulation.
The search tool for GIMP is Google. How do I draw a rectangle? Google brings you to https://docs.gimp.org/2.10/en/gimp-using-rectangular.html which starts with "GIMP is not designed to be used for drawing." and then goes on which "However, you may create shapes by either painting them using the technique described in Section 14.1, “Drawing a Straight Line” or by using the selection tools"
At that point you realize that what you really want is MS Paint from Windows 3.1
I don't know about the Mac version but I find the Linux version a bit on the slow side and the interface look and feel is a bit off to me but I chalk it up to "that's because I am not used to it and I have decades of light photoshop usage ingrained in my brain".
But don't get me wrong. Krita is awesome and it's a better substitution to Photoshop than Gimp is.
Krita is great for drawing, but it's no photo editor. It probably shouldn't be, either, that's more GIMP's space.
In my experience, Paint.NET walks a very fine line between "more complex than MS Paint" and "GIMP/Photoshop/Photopea levels of complexity". Great for altering screenshots and applying filters, but not as overwhelming as a dedicated artist's tool.
I'd say Pinta serves a purpose very similar to Paint.NET on Linux. It's it quite as polished as Paint.NET is, but it's still a good balance when KolourPaint is too simple and when GIMP is overkill.
Yes, and I've even purchased it as it seems to offer the best balance between feature-richness and usability. But its concept are still quite different from those of Paint.NET and I'm yet to dig into it – right now, I'm googling everything.
And yet they include a brush tool and a pencil tool - as far as I can recall, the brush tool responds to tablet pressure levels.
But _not even their own devs_ can't explain logically why a rectangle or a circle drawing tool is a no-no. And go forbid if you criticize that fact in front of them.
You can subscribe to one developer's patreon, or buy an animated movie by another pair of developers. That's it, no contingencies allowed. And direct donations to the foundation cannot be spent on development efforts.
> Donations through GNOME Foundation can only be used for community needs (conferences, developer meetings, material renewal…).
I still haven't seen a truly-adequate replacement for that. Every time someone tries to create one, they begin with good intentions and end up with a bad Photoshop clone.
The problems with Gimp have nothing to do with not having a sufficient UI paradigm to contain Gimp's oh-so-precious functionality; it's that the project leadership refuses to consider that tue esoteric universally-loathed UI paradigms they came up with might be worse than the prevailing conventions.
> the project leadership refuses to consider that tue esoteric universally-loathed UI paradigms they came up with might be worse than the prevailing conventions
Do they though? I've been in and around that project for many years and one common scenario that I've seen replaying over and over (and over) again is when people request something and then understand "please elaborate why this UI solution is better" or "can't right now, too many things to work on" response as a flat-out refusal.
305 comments
[ 3.1 ms ] story [ 218 ms ] threadMy firsthand knowledge of such things is quite stale nowadays, but I get the impression the RH desktop group is barely on life support at this point. That GTK4 happened at all strikes me as surprising, but could be interesting long-term in terms of modernized GPU support for the toolkit attracting new usage/developers.
The real question is do enough people even care about GTK anymore to make use of it in the future. I'm inclined to believe the current crop of devs want $hipster-language-native GUI packages. Not awkward quasi-"idiomatic" bindings and FFI wrapping an archaic C library like GTK/glib.
re: Gtk4, they're already moving on to Gkt5 (wayland only though https://www.phoronix.com/news/GTK5-Might-Drop-X11).
Looks like a canonical file path (as opposed to dir path) paste handling bug in general, which seems like something worth fixing regardless of one's stance on keyboard paste.
To understand how it's keyboard specific you have to know about what features were removed. In the past you could set the file chooser dialog to have either a text entry field or the path-bar mouse buttons as the default. This was through org.gtk.Settings.FileChooser location-mode. While this gsetting still remains gtkfilechooserwidget.c was changed so it no longer respects those settings and always forces only the mouse based path-bar input mode. This means now when a file path is pasted with ctrl-v (or middle mouse click paste?) the entirely wrong function tries to handle it and this function errors out because it's not expecting file path input.
That is a hell of an ask.
And would it be more work than the gtk2->gtk3 port?
However, what people do not realize about these "toolkit ports", whether within a family (GTK 3->4) or across them (Qt -> GTK), is that the reason they take so long is that it is almost impossible, when having to go through the vast majority of the codebase and change stuff everywhere, to avoid the realization and/or temptation that there are better (or at least different) ways to do things.
If you could suppress that inclination (and its not clear that doing so is a good idea), and simply do as close to a 1:1 replacement where required (which for cross-family ports is everywhere), the port could be a lot faster. But it is extremely hard to resist that, because the non 1:1 replacement stuff just appears so right.
https://www.gimp.org/news/2019/01/02/gimp-and-gegl-in-2018/
"GTK+3 port officially done
GIMP 3.0 has been known as the GTK+3 port version, so you will be happy to read that this port is finally over. To be fair, we still have a few minor deprecation warnings here and there, but nothing like the hundreds we used to have."
https://www.gimp.org/news/2023/07/09/gimp-2-99-16-released/#...
https://www.gimp.org/news/2023/07/09/gimp-2-99-16-released/#...
Their support got the ball rolling and then eventually Amazon and a bunch of big studios threw their weight in but I'm not sure how many of them were involved in the redesign.
https://www.blender.org/about/
4 sources of income: one-off donations and recurring donations (from individuals and businesses), subsidies and co-development funds from businesses, and subscriptions to their cloud service.
Gimp was designed by open source hackers with no input from professional designers, or seemingly even any interest in their input. It never gathered any kind of momentum as a credible Photoshop replacement for professionals.
And that’s why Blender is getting donations: it’s become a serious part of workflows for all kinds of companies who have a 3D content pipeline. Meanwhile Gimp is still the awkward collection of hackers’ image processing pet projects piled into a clunky GUI that does nothing to enable the things that designers actually use Photoshop for.
Blender's dogfooding efforts were a powerful force in both proving that the software was good enough (to make movies) and demonstrating how it could be better (for the animators who made the movies). I'm not aware of any such efforts for GIMP. What I have seen is roadmaps of what improvements they know they need, and timelines of years to improve core infrastructure to the point that their actual goals are within reach. Meanwhile, other software projects (both FLOSS and commercial) race past them and move on to more exotic and exciting features.
That's just not true at all. GIMP's UI has no redeeming workflow. Even if you master it, you must still constantly navigate it's clunky menu of features.
Blender 2.x had an intentional UX flow. When you mastered it - which really wasn't nearly as difficult as whatever work you were doing with it - you could be very productive.
Blender 3.x didn't really change that flow. It only added some optional visual interface for the people who don't already know the keybinds.
To contrast, Blender has neatly organized every feature contextually. There are specific modes for organizing objects, editing meshes, sculpting, UV painting, etc. that each present their own smaller tailored UX. Everything that is an option (something you would edit with a text box) is under the properties window, in a contextually-organized tab. The entire structure of Blender's UI/UX is organized to match the conceptual UX of the tools it provides.
The Blender dogfooding effort is a reflection of the team’s background in actual 3D production and their commitment to a long-term dialogue with this userbase. Gimp never had that.
I loved Softimage's look ! Flat and minimalist zen design way before ! Then I got the credits for that course and moved on to different pastures.
This is in stark contrast to the vast majority of UI-redesigns which tend to break existing workflows, remove features and are just ego-driven projects. You need to be a user of your own software.
I mean, that's how I feel using the GIMP menus. I never know where anything is, and my first guess is usually wrong.
And I think that's most of the disconnect in the UI, which the devs have gradually gotten over by adding shadow XML data in the SVG to support Inkscape features while always presenting a rendered result.
Still, the drawing tools aren't consistent about the units they use yet. There is a lot of stuff there, and some of it is just papercuts.
I had the same experience, and searching for answers using keywords was not very effective. There are so many features that the terms I guessed were often a different concept in GIMP, leading to a bunch of irrelevant results.
I have found that ChatGPT solves this problem very well, so I don't even try searching first anymore. I can verbosely explain what I am trying to accomplish, and it tells me "that is called X in GIMP, and here is how to use it: ...".
A recent example is that the Bucket Fill tool was filling in adjacent pixels that were a slightly different color than the one I clicked on. ChatGPT told me this is called the "threshold" and how to change it to 0 so it only filled exact matches. I would have searched for something like "gimp bucket fill sensitivity" or "gimp bucket fill precision", then had to read through a forum answer or the GIMP documentation to see that term.
ChatGPT didn't tell you. It scrapped an answer off a forum and regurgitated that to you after applying a language transform. It's second result on DDG for "gimp fill tool border" -- https://graphicdesign.stackexchange.com/questions/42621/hard....
And you would have seen the correct answer if you searched this instead of trying to explain it to ChatGPT.
The first result of my Kagi search for that exact query is the official GIMP documentation. It provides the answer in the snippet.
> The Threshold slider sets the level at which color weights are measured for fill boundaries. A higher setting will fill more of a multi colored image and conversely, a lower setting will fill less area.
The second result is from graphicdesign.stackexchange.com and the snippet tells you that you might want to check the anti-alias setting if you want non-softened filling. That seems relevant if you want exact color areas to be filled with the exact color you picked as well.
Overall pretty happy with the first two results, I feel that they answered the question without even clicking away from the results page or trying to explain things to ChatGPT.
In Google the results for that quote are rather useless.
Open-source is built one patch at a time, so a big rewrite can never happen. But what's worse, to me, is that people build up this cognitive dissonance that it's some framework's fault that it doesn't have the right dropdown widget yet.
A lot of FOSS projects could do a lot of amazing things if they had enough people who "just do the work".
Oh I dunno. Personally, I was vocally against the bullying of the Glimpse team.
My point exactly, that's why nobody "just does the work"
> Do you think that the GIMP maintainers are going to be happy if I drop a full rewrite on them?
I think they'd be impressed that you managed to rewrite the entire codebase that fast.
The last thing they need is people who have no wish to use their program or contribute to yell at clouds and insult their work without moving a finger themselves.
"Make it work like in Photoshop because Photoshop" is not appreciated.
It's really _that_ simple.
The GIMP developers have heard both kinds of arguments MANY times before, as well all the arguments for using pie menus based on usability and scientific measurements of controlled experiments and decades of experience developing and using user interface toolkits and applications, from me and many other people, and at this point they are just cutting off noses to spite their face, not listening to any arguments about usability or anything else, because they have decided that somebody else once hurt their feelings by asking for the exact same thing for the wrong reasons (or as you literally say, simply without extensive justification), so they got permanently huffy with their panties in a twist, and always say no to everyone who ever asks the same question ever again no matter what their arguments about usability or experience with user interface design.
Pie Menus: A 30 Year Retrospective. By Don Hopkins, Ground Up Software, May 15, 2018.
https://donhopkins.medium.com/pie-menus-936fed383ff1
That's even what your tone policing argument literally says, so you've just made my point for me! They've been asked in both ways many times before, yet they reject all the reasonable well justified requests, because they once had an unreasonable request (or simply brief requests missing pages of explanations and citations I like to provide, that they don't even bother reading anyway).
Not every user has studied human computer interaction and written many papers and articles about it like I have, and can articulate (or cares to take the time to articulate) exactly what their reasons are. They just love Photoshop or pie menus because it works well for them, and they can't explain why, or just don't have the time. And that's no excuse for not listening to their users.
The GIMP developers are TERRIBLE at listening to their users, which is a fatal flaw and mortal sin for user interface designers, and that's a hard cold fact. If they were competent empathic UI designers, they would have already pro-actively researched Photoshop and pie menus and many other competing designs, already know what the issues and trade-offs were, and make conscious informed decisions. But they're not, and they don't.
But fortunately the Blender developer are the exact opposite. For example, they've adopted the standard right mouse button click conventions and pie menus and other features that their users demanded, and they think deeply about the trade-offs and issues of making it more like competing products like Maya and 3dsmax, and they have very good reasons for doing things the way they do, and articulate those reasons clearly and calmly and maturely, instead of simply throwing temper tantrums and stubbornly inflicting revenge for people occasionally asking them for features impolitely or without sufficient explanation years ago, like the GIMP developers always do.
The GIMP developer's behavior is exactly the same line of argument I so often hear from racist Trump supporters, who claim they aren't actually racist, but somebody forced them to be racist because they were once impolite to them about their support of Trump (which they deserve for being racist and purposefully impolite to other people), so they got offended and doubled down, trying to blame their acknowledged racism on somebody else not being nice to them (i.e. tone policing), instead of taking responsibility for their own decision to be racist.
https://en.wikipedia.org/wiki/Tone_policing
You don't get to be absolved of making stupid decisions on your own by being stubborn and not listening, just because you want to punish people for asking you not nicely enough once. Nobody forced Trump supporters to b...
If you really think that providing substance to argumentation is about tone rather than useful information, then we must be coming from two different planets, and this conversation has no way forward. So I'm sorry, I'll just back out. Seems safer that way. Good luck.
This is extremely wrong. FOSS would be better if things weren't redesigned every other year from scratch. KDE, Gnome, MuseScore to name a few. I was a master of MuseScore 3 and the year I finally became 100%, they dropped support shipped the absolute shitshow that is MuseScore 4, broke every single one of my workflows and finally forced me to use lilypond full time. FOSS is a redesign-after-redesign shitshow just like big name software are. I just want my software to work today exactly the same way it worked yesterday and it seems impossible to achieve that.
Absolutely hate this redesign.
The correct response to a “too small viewport” for anyone serious is to buy a better monitor with a larger resolution, not to redesign menus in to bullshit obscurity.
It was probably Apple that led the "minimalist UI" trend, but at least Apple have consistency across their applications. The GNOMEs started trying to copy Apple's design cues with Gkt3/GNOME3 but completely missed the mark.
Removing "clear obvious text menu" might make it less friendly for casual users or first time users but makes space for stuff that experienced users have use of.
Sufficiently experienced user needs to have menu organized the same way between versions if they use it for years they already and know what they want, probably just use keyboard shortcuts anyway.
Discoverable menu items in complex menu IMO is not some holy grail.
I think people read too much in "Apple design" and expect everything "should be easy". If you are first time user of CAD or advanced graphics manipulation application you are going to have to put time to find out tools and where they are.
For example I like foldable left-hand menu on web apps where if I know the icons meaning I can fold it but for first time use of application I get text+icon.
Then we would know if the AI is more or less intelligent based on whether it can actually figure out how to find that specific blur function within all of the various dropdowns and sub-menus.
Anyone who wants to get rid of it is a bad developer and a bad person.
Please don't do this. You know that isn't true.
If someone wants menus in a pop up box, you can simply hide the menu bar until the user presses Alt (or F12 depending on your OS's convention).
Inventing an entire new weird system for pure novelty while saying "fuck you" to accessibility for disabled people... is just not okay behavior.
/s
It's bizarre that a search bar that unfolds a vertical menubar when highlighted but unfilled is supposed to be a great advance. It's so unimpressive that I 1) don't mind it at all, and 2) think the menu aspect is useless. It's just a menu command search bar; a good UI library could construct one automatically. Stick it in a corner, or automatically open it when people start typing with no obvious object. It's a triviality.
What bugs people about the GIMP is that it's not Photoshop. All of the GIMPs menu options are placed in eminently logical places. although it's a grammar that probably makes sense over time. Photoshop options are mostly placed randomly, and some of them turn out to be ads. That's not a huge dig at Photoshop, because it's pretty amazing that they ever fix or move anything with so much industry adoption, and adding things has to be a nightmare.
But the GIMP puts things in places because they make sense there. They don't have the base that would get enraged if they moved things. It's extremely telling that when put to specify improvements that could be made, the suggestions are either trivial, like
1) a search bar, or
2) an extra statusbar above the statusbar (in case they want instructions over their instructions), or
3) to make it single-window (because just not moving things is not enough, they have to be prevented from moving things),
or they're just:
4) "Make it more like Photoshop! When I use Photoshop I know where things are, and when I use GIMP, I don't!"
The GIMP is wonderful and its problems are technical: it has lacked some of the ability of Photoshop, but that gap slowly but surely continues to close.
edit: I can't believe I forgot the worst one: "Why when I click Save does it save my project, but when I want to export a file based on my project, I have to pick Export?"
Every time I try GIMP it's a nightmare. Even the simplest thing usually makes me find a video to explain where to find it. Cutting, pasting and layer management is a pain. For super simple stuff I use Pinta and anything marginally complex I use photoshop and it's always felt easy.
I know that's hardly scientific but I've always seen photoshops interface as good.
Six-year-old Reddit thread: https://www.reddit.com/r/GIMP/comments/7esx08/even_with_late...
I don't think it's fixed yet.
- can't search
- don't have 100% functionality
> [Search] kinda works when you generally know what you need or how a feature you want could be called. But really not when this is your first rodeo.
Now if search were the only means of discovery, that would be bad. Imagine if no two pages linked together: everything had to be found in an index. That's a strawman though. Search complements other modes of discovery.
How about REdiscoverability. You remember some feature in the program and some words related to it, but ... where the heck was it? Search can help.
(a) what percentage of web pages do you think can be found by a person using a search engine, without specific prior knowledge of the content?
(b) do you believe an application in which the same percentage of features are discoverable has acceptable discoverability?
In the sense that, for instance, if I find a great Greek restaurant I didn't know existed, that counts as discovery, even though I already know Greek food and was searching for that.
It's also wrong, for example, you can discover all the file operations by typing in "file" in the search box even if it's your first rodeo
Also, search box can list all the commands as some commands palettes do in other apps, so you can just scroll to discover 100% of listed commands. It can also show categories, that's, for example, how I discover 100% of commands for some plugin by typing its name and reading the list of commands in the search results
Btw, this problem doesn't go away with the menu (like mentioned in another thread): it's hard to discover by looking through a huge nested list, especially when this list is poorly organized like in Gimp, and incomplete, and not context dependent
So no, search is on the same side of discoverability, and the op doesn't claim otherwise, that's your mistaken interpretation
If that's the sentence you thought I meant, then pretending you didn't know what I was talking about was a lie and you should find somewhere other than HN to hang out.
So you mean that I should loop through [a-zA-Z0-9]* to search which name is defined so that I can use that function? What pills do you take, I want them.
Discoverability is the measure of how well an application presents features to you that you didn't necessarily know were there.
A menu may be a list of features, when you open the menu you discover those features.
A search box is a box. It shows no features. Search results might show features but those features might also not relate at all to the task you're doing, which means they're out of context. That's extremely poor discoverability. You can find all the features, you can't discover them.
The problem with search and discoverability is that search requires input from me, whereas discoverability means that the program explicitly offers its features to me. With search, I would never discover some handy new feature I wouldn't think of myself, or something that is named differently than I expect.
Hunting through a menu, while not optimal, allows me to view a 'catalog' of all the features.
The menu doesn't resolve these issues: if you don't know that yank is copy, seeing it in the catalogue won't help much, especially if instead of the usual cut/yank/paste that could give you a hint, you have cut/paste is in some "destructive edits" menu, and yank is elsewhere
And you can very well not have a command in the menu, after all, coding to have a command automatically dumped in a global list is easier that remembering to add it manually to some menu category
And the input to search can be blank: you'll get the same catalogue with the same categories like in the menu (watch the video, the popup search has all the menu categories), so there is almost no difference, so there is nothing magical 1000% discoverability in this menu design
A “menu”, if you will ;)
Looking at the screenshots here, I don’t think you actually need search to make those menus more manageable. One screenshot of current GIMP shows a menu tree that looks like “filter->render->noise->solid noise…”. I think you could probably combine the entire noise submenu from that tree, and make it instead a segmented control on the actual “noise” dialog that chooses your type of noise. I suspect dropping the “render” level as well would also be good. “Render” is a bit of a jargon-y term in the context of graphics editing, and I don’t think it means much to most people using it. Furthermore, the top “filter” menu isn’t actually all that long, and people generally prefer wide flatter trees to narrower deeper trees. So, I’d pitch for a simpler menu that would just be “filter->noise…”. By flattening and combining, I think that menu could be made much more usable and discoverable.
This is the core point made in the article.
I don't think it's power users these designers are trying to cater for. They make things more difficult for power users by hiding useful options in some tab in a modal settings dialog, which is a PITA to find and click if you need to change it often. Often they remove something completely from the UI and you need to go find the config file and manually edit some text and restart the program to get functionality back.
They're trying to cater for novices - they think too many controls on display is going to confuse or overwhelm them. I blame Barry Schwartz[1]
If they were trying to cater for power users they would let power users configure their interfaces to suit them. Modern interfaces are "fixed" in the image of the designer, and screw you, the user.
[1]:https://en.wikipedia.org/wiki/The_Paradox_of_Choice
Exactly, and both in the immediate UI (like, ctrl-right click on a menu and enter the new shortcuts right there) and in config files to allow for batch search&replace editing
One thing I did with GUI I wrote for a customer was added a notes item to the right click menu on every control. Click it an editable text box shows up. With an option to mail me the notes data so I could incorporate it in the next release.
Look at houdini's nodes interface. You hit tab and a huge list of nodes comes up. Start typing and it will filter the list as you type.
E.g., you want to apply a hanging indent in Docs? Just type "hanging" into the menu search, and it shows "Indentation options". It's smart enough to know that hanging indentation is an option within the dialog that shows up there. And the menu search seems to have a large range of synonyms, so typing "picture" brings up lots of "insert image" choices.
But it bothers me that even in Docs, almost nobody knows about menu search because it's hidden under the "Help" menu, rather than being a nice prominent rounded search box in the upper-right corner like you'd expect.
Menus are great for discoverability (so do not get rid of them), but frequently you know what an application can or cannot do (e.g. you assume a word processor can do hanging indents or watermarks), but you don't know where exactly it lurks in the menus or which tab of the settings dialog, and don't want to waste two minutes hunting for it.
It's time for a universal search box to exist in every major desktop application. Apple and Microsoft really need to take the lead here to provide standard API's and UX components for this, and it saddens me that they haven't, and continue to show no signs of interest.
Wow, TIL. Talk about a hidden feature.
So it turns out it's under the "Help" menu, and it just says "Search". I had always assumed that this searched help topics, not menus.
But it's also pretty miminal, seemingly without support for synonyms or features inside of dialog boxes -- e.g. if you type "pref" it won't find "Settings". It also doesn't have a keyboard shortcut to trigger it (like Docs).
So I think there's still a long way to go to make it a central UX feature.
Why on earth isn't that keyboard shortcut shown in the search box, the way every other menu item with a keyboard shortcut has it displayed?
It boggles my mind how hidden this all is.
All these years, I could be picking menu items with my keyboard instead of my trackpad? What the hell, Apple.
First Apple hides the feature behind a search box that you don't usually ever see and then wouldn't ever guess that it searches the menus, then it goes even further to suggest there's no keyboard shortcut for it, when there is one. What a complete and utter UX fail.
I’m sure I miss dozen of things with each yearly release now if I didn’t catch it during a keynote or stumble across it somewhere on the web.
(Now, the complaint that I've seen elsewhere -- that using that same search field to search actual documentation is basically useless -- is an entirely different kettle of fish...)
https://news.ycombinator.com/item?id=37907449
>The whole point of pie menus is to be "self revealing", supporting discoverability and browsing and prompting and gently training users to quickly use the gestures without looking, through rehearsal. They solve the problem of gestures being invisible and impossible to discover and learn.
https://en.wikipedia.org/wiki/Pie_menu
>>Pie menus are a self-revealing gestural interface: they display multiple options to a user and direct them to select one.
>>Users operate the menu by observing the labels or icons present as options, moving the pointer in the desired direction, then clicking to make a selection. This action is called a "mark ahead" ("mouse ahead" in the case of a mouse, "wave ahead" in the case of a dataglove).
>>Repetition of actions and memorization of the interface further simplify the user experience. Pie menus take advantage of the body's ability to remember muscle motion and direction, even when the mind has forgotten the corresponding symbolic labels.[1]
>However Apple has never adopted pie menus, Steve Jobs thought they sucked, and Donald Norman has never been a big fan, and he totally missed the point when I tried to explain it to him at Ted Selker's NPUC workshop.
>I had the honor of meeting Steve Jobs at EduCom on October 25 1988, when he released the NeXT machine. Sun had lent me a workstation to demonstrate NeWS software in their booth, right across from the NeXT booth, and Ben Shneideman brought him over for a demo of the stuff we'd developed at HCIL.
>So I gave Jobs a whirlwind tour of pie menus, the NeWS window system, UniPress Emacs and HyperTIES for about half an hour. Jobs was jumping up and down, pointing at the screen, and yelling "That sucks! That sucks! Wow, that's neat! That sucks!"
>When I explained to him how flexible NeWS was, he replied "I don't need flexibility -- I got my window system right the first time!" But I gave him a NeRD button, anyway (which I'd made for NeWS window system NeRDs, but he liked because it had a lowercase "e" like NeXT).
[...]
The GIMP developers are even more stubborn and insular-minded than Steve Jobs, but with absolutely none of the design skills, visionary creativity, empathy for users, or obsession with usability.
Pure gestures alone (like swiping in different directions on an iPad or phone, or the more complex unistroke gestures for writing letters, numbers, and symbols in Palm Graffiti) don't have a natural way to reveal themselves or prompt the user which gestures are available and what they mean, or a way to train users how to use them quickly with gestures.
Pie menus also support "reselection" and "browsing", so if you make a mistake or change your mind, you can always correct your gesture in-flight, and you can browse around pie menus to reveal feedback about each item (i.e. text in the item or menu center, or immediately applying the currently selected item to the visual state of the application, previewing the effect of the selection without committing it yet, so you can still change or cancel it).
Users learn to use pie menus in three stages: pie menus lead, follow, then get out of the way. This is called "rehearsal", because each stage naturally and transparently trains you to move on to the next stage of expertise. So the novice's time using pie menus in the "leading" mode is not wasted, but trains them on to the "following" and "getting out of the way" modes.
At first, a novice user clicks the button or presses and holds to pop up a menu, then looks at the items, decides which one they want, moves the mouse in that direction, then clicks again or releases the button. That's leading, and it's self revealing.
Then a more experienced user who remembers the direction of the item they want clicks or presses then moves in that direction (mousing ahead but waiting for feedback before confirming). They wait for the menu to pop up, look at the screen to make sure they're selecting the right item, then if it is they click or releases the button to confirm, or else make a correction. That's following, where pie menus reveal themselves showing the selected gesture, then let you confirm the selection if it's right, or or change it if it's wrong, giving you more confidence to move on to the next stage.
Finally an expert user remembers the direction with confidence, then smoothly clicks or presses, moves, and clicks or releases, in one quick continuous gesture, to select the desired item without even needing to look at the screen. That's getting out of the way. That's where "mouse ahead display pre-emption" is useful.
Compare that with linear menu keyboard shortcuts that are a totally different physical action than selecting from menus with a mouse, so selecting an item from a linear menu with the mouse (novice) is not rehearsal for using its shortcut with the keyboard (expert), and that does not train your muscle memory by rehearsal to smoothly move from novice to expert, the way pie menus do.
Pie menus should support "mouse ahead display pre-emption" so that when users select from them by gesturing quickly without hesitating, they don't even bother to pop up the menu, just provide some lightweight unobtrusive feedback like showing the item label next to the cursor in a tooltip, instead of popping up the whole menu and covering up other windows.
The mouse-ahead stage doesn't require a high-cognitive-load attention-grabbing hand-eye feedback loop, so you can "mouse ahead" the same way you "type ahead" without hesitating between every keystroke and looking at the screen and waiting for the character you typed to draw to make sure you typed the right character, before typing another one.
Imagine how slow it would be to type, if none of the keys had "self revealing&quo...
command + shift + ?
Raycast for example. It still wont find synonyms, but it works well enough that I frequently use it in Affinity and similar apps.
I find the OSX search feature close to useless as a "help" feature because of this.
I came to the realization that it's more like a power user shortcut tool than something to help new users. If you know exactly what you're looking for and exactly what the application calls it then you can skip navigating through nested menus.
Gnome turned out to be a poorly thought-out opinionated mess, learning all the wrong lessons from Apple's work.
They changed it recently. Now it’s a nice prominent rounded search box in the upper-left corner.
But it does turn into a magnifying-glass icon even on smaller screens. I just never thought to click it -- I would have guessed it would bring up a zoom menu or something. (The ever-present confusion around when magnifying glasses mean search, find, or zoom...)
It's progress!
Menus in Qt and GTK apps can be exported over D-Bus, allowing for desktop environments, or 3rd party HUDs, to implement menu search bars, as well.
What's crazy is that i'm pretty most times wasted on a computer is from "where is this setting, how do i do this" type stuff, in users ranging from experts to the elderly.
It's bizarre to me that this hasn't been implemented all over faster. Instead cloud interfaces have become even more esoteric in my opinion.
All functions on a computer should have a tiny descriptive string you can search for.
The GUI paradigm from the last 30 years in was a mistake with nested stuff just hiding in random places. CLI was a bit better when you could pipe / search etc. but for most people Universal Search is it.
Then there's the escape key. Sometimes it does what you want, other times it just gives you an error ding with no other information.
The core problem with GIMP is that the interface is bad. No two ways about it, it's just bad. It needs a total redesign, but that would be unacceptable as it would alienate evryobe who has already learned it.
As an editing program, GIMP does everything you need and then some. It's fully featured and functional, just not usable.
That said, GIMP is still my only choice for photo editing. All the other options are worse in different and mostly worse ways.
The days of that are numbered.
Out of curiosity, what's that? Are you by any chance referring to the option that allows not removing cropped pixels? Well, it's an option. You can disable it.
And we can even add crude customization to the search. Gimp can easily remember the prefix-tool click pairs, so that you don’t even need to type “cropping tool”, if you type “cr” Gimp will remember which tool you clicked last time.
Noise being in the Filters menu never made sense to me. Noise is an input source. It's like classifying the paintbrush tool as a filter. I shouldn't be too hard on GIMP for that I guess, as Photoshop puts it under filters as well.
Photoshop is an arse to use, just like the GIMP. I just happen to have learnt gimp first.
Or do you do little edits with the mouse, painting masks, selecting regions with the mouse, and generally using the mouse/pen a lot?
I've never really used the scripting functions apart from applying global effects.
Nowadays I use it until I need illustrator hard enough to move to the mac downstairs. but most of my photo editing is now done in lightroom.
[1]https://github.com/bootchk/resynthesizer
I like programs to work on an off-line computer.
This is a shortcut for Cut+Paste, which I always use anyway because I find it more intuitive.
What's up with the thick lines around UI elements? it all looks so 2008.
It sometimes looks to me like absolutely 0 designers are actually involved in open source, at all
Apparently none did.
- no ads
- no "runs best on Chrome"
- no network connectivity dependencies
User:
Explain the joke.
ChatGPT:
The joke here revolves around a classic internet meme that originated from discussions on Slashdot, an online community similar to Reddit or Hacker News but older and more focused on technology and science. The meme is about creating a "Beowulf Cluster," which refers to a network of computers configured to work together on complex tasks, effectively creating a powerful supercomputer from less powerful individual machines.
The original context for this meme was discussions where someone would invariably suggest, often irrelevantly, that a problem could be solved by creating a Beowulf Cluster. It became a running joke to propose a Beowulf Cluster as a solution to virtually any tech-related problem, regardless of whether it made sense or not.
In the conversation you're referring to, when "timbit42" mentions a Beowulf Cluster in response to the idea of integrating Large Language Models (LLMs) like GPT into applications like GIMP, Photoshop, or CAD, they are likely invoking this meme. The joke is in the overkill of suggesting a massively parallel computing solution (like a Beowulf Cluster) for integrating an LLM into a software application, which is a task that doesn't necessarily require such an extensive computing setup.
Althout the usual menu navigation mechanism should also stick around since it provides consistent invocation of a command with a sequence of keybinds (like File, Open). Fuzzy search doesn't do that since you can match something else. Key combos require too much memorization
(though it doesn't have to be the typical horizontal menu at the top, you could have a "modal" navigation mode in the same command pallette)
And to answer the question: of course it's possible, just highly unlikely
Solvespace is the only usable open source CAD software I've found and I have tried all of them. Unfortunately it has some awkward limitations (no bevels or fillets is probably the biggest).
If he can take the excellent Solvespace constraint solver and make something usable that would be amazing!
Krita and Gimp's biggest issue is that most of the tools are implemented in a non intuitive way. Everything is a disorganized mess. And since PS doesn't run under linux, this gets on my nerves.
For example in Krita you can't resize a crop rectangle with the mouse that holds its aspect ratio... WHYYY? And why does the crop tool forgets the previous size values? Little things like these show that the creators NEVER EVER use their own fucking program.
Compare with Affinity’s software - they are more consistent than present day Adobe but copied all the good, same as Adobe did with Quantel.
Do you mean non intuitive or just not the same as PS. 99% of complaints I see about GUIs (most commonly OSS ones, because people are less likely to criticise choices where they invested money) are that they do not function like another piece of software.
> For example in Krita you can't resize a crop rectangle with the mouse that holds its aspect ratio... WHYYY? And why does the crop tool forgets the previous size values? Little things like these show that the creators NEVER EVER use their own fucking program.
Are you sure? IIRC you just hold down the ctrl key while dragging to preserve aspect. Do I remember wrong?
Gun to my head, have to do some unknown-in-advance image editing task, I get to pick the software, but can’t look anything up, I die if it takes far too long? I’d pick Photoshop. I might survive with PS. Near-certainty I’m dead with the Gimp, hell I might be dead with Gimp even if the task is incredibly simple. It’s not that it isn’t like PS, it’s that it’s UI gibberish.
I worked with Gimp ~ 1 year ago, not touching that again until I feel the need to flagellate myself.
I mentioned it in a different post, blender is the prime exhibit for this, its UI received even more criticism than gimps. Now that it has become the (or one of the) most popular 3d modelling tool, most of these voices disappeared, because it has become the first entry point and people are not used to some other way of working anymore.
If anything Blender proves that paying close attention to UI and making it mostly align with user expectations matters.
And my point is, regardless of those claiming gimp sucks because it’s not what they’re used to: it absolutely does not matter an iota because there is near universal acceptance that it’s terrible for anything but toy work. UI aside, internally it isn’t fantastic either, a problem that blender didn’t have.
It's like people who speak English talking about how everything in Spanish is in the wrong place. It's the cheapest way to bikeshed: make it more like the thing I know already!
Just like using a Mac after having been a PC user; or being forced back to MS Windows after using Linux/KDE for a couple of decades.
I used to use Inkscape heavily, but having not used it for a few years, I go back and the UI has changed, similar experience; I feel lost when I should feel capable.
Photoshop was one of the first applications that I noticed using the 'give it free to college students to capture the market' technique. That works so well because it takes a couple of years for for you to adopt the software as an extension of your way of thinking - changing application means a productivity loss, and a feeling of incompetence, and no professional wants that unless they can clearly see an ultimate gain.
I'm double commenting in this conversation but I was a GIMP user in high school and college before switching to photoshop. I specifically remember thinking how much nicer it was that everything in photoshop was where I expected it and worked how I expected.
The extensive experience working with photoshop is a problem in itself, not a symptom. It sets expectations, and when they are not met, frustration ensues. But the photoshop UI is not the most intuitive one, just most familiar to this kind of person. Those are two very different things.
I understand the frustration, for the same reason I cannot work with Darktable. In some aspects and basic organization it is similar to Lightroom, and when I start using it as Lightroom, it leads to the same frustration. But that's not because the Darktable folks did something wrong, but because I cannot act on my habits from different software package and my expectations are not met. Someone, who doesn't have the same habits and doesn't have to unlearn won't have the same issues.
As a survivor of "let's have three different ways to apply a TRC curve at the start of the processing pipeline" — hard disagree.
I've never used Krita, but I was skeptical that it can't do this, so I just now installed it and gave it a try. It does have this feature! I made a crop rectangle, then right-clicked on it. A little menu popped up, titled "Crop Tool Actions". One of the things in the menu is a checkbox labeled "Lock Ratio", which was unchecked by default. I clicked the checkbox, and then I could resize the crop rectangle with the mouse without changing its aspect ratio.
Took me under a minute to figure out, having never used the software before or read any documentation. I'd say that's one sign of a decent UI.
Well, previous commenter just did it. So that just mean that your peremptory decrees are just that. Peremptory and not really universal.
The gimp project has provided a decent and useful tool for about 28 years whereas most new projects started from scratch die shortly. A from scratch rewrite would be a massive undertaking which might exceed the available resources/skills and might simply kill a useful project rather than producing a better one.
A glib well this guy did it is not an analysis.
But also, it's my understanding that Krita is not a photo editor, but rather a digital painting program; that any ability it has to edit photos is just because digital paintings are stored in the same file formats as digital photographs. Saying that Krita is unsuited for editing hundreds of photographs is analogous to saying that Visual Studio is unsuitable for creating ASCII art. There are other tools that you're supposed to use for those tasks. For editing hundreds of photographs, I understand Adobe's Lightroom or Bridge to be the intended tools, not Photoshop, nor any tools which are highly similar to Photoshop (GIMP, Krita, or otherwise).
Ok “2 clicks” is a misleading summary for moving down 6 menu items, and in the end this is an eternity compared to a modifier key.
I'm the OP and for the life of me I can't figure out what you are talking about. Seems like you are conflating GIMP and Photoshop and reading the post as if it suggested that either GIMP or Photoshop don't have a menu, which is absurd — there was no such claim.
> Another important thing is to drop the "this must look and feel different than photoshop" stance
There has never been such a stance in the first place. As far as I can recall (which is about 20 years back), the stance has always been "please explain why your proposed change is good, don't hide behind "because this is how Photoshop does it", it's lazy".
For the record I think the blender UI is pretty genius for an extremely complex graphics program and it could also work with gimp. Also the loud shouting around blenders UI have died down a lot in recent years, which I attribute to 2 things:
1. the great work done to make the UI more discoverable. 2. Blender having become almost a standard so there is lots of tutorials and it's now much more often the first 3d graphics program that people get exposed to (hence less it doesn't work like Maya,... complaints).
the bitching is mostly the disconnect from version to version.
https://github.com/ubuntu-mate/mate-hud
https://jamcnaughton.com/2015/10/19/hud-for-xubuntu/#jp-caro...
Here some more screenshots for the uninitiated (with search used on GIMP in the first two screenshots): https://imgur.com/a/5XlgTO3
And the official docs: https://wiki.ubuntu.com/Unity/HUD
At that point you realize that what you really want is MS Paint from Windows 3.1
Or a drawing program like Krita.
But don't get me wrong. Krita is awesome and it's a better substitution to Photoshop than Gimp is.
In my experience, Paint.NET walks a very fine line between "more complex than MS Paint" and "GIMP/Photoshop/Photopea levels of complexity". Great for altering screenshots and applying filters, but not as overwhelming as a dedicated artist's tool.
I'd say Pinta serves a purpose very similar to Paint.NET on Linux. It's it quite as polished as Paint.NET is, but it's still a good balance when KolourPaint is too simple and when GIMP is overkill.
And yet they include a brush tool and a pencil tool - as far as I can recall, the brush tool responds to tablet pressure levels.
But _not even their own devs_ can't explain logically why a rectangle or a circle drawing tool is a no-no. And go forbid if you criticize that fact in front of them.
Unless prefer to offer vague suggestions by way of insults to work donated for free.
You can't even do this, gimp doesn't take donations or money for development.
https://www.gimp.org/donating/
You can subscribe to one developer's patreon, or buy an animated movie by another pair of developers. That's it, no contingencies allowed. And direct donations to the foundation cannot be spent on development efforts.
> Donations through GNOME Foundation can only be used for community needs (conferences, developer meetings, material renewal…).
...while making shape-drawing tools an item in the roadmap? :)
> And go forbid if you criticize that fact in front of them.
Nothing will happen.
I still haven't seen a truly-adequate replacement for that. Every time someone tries to create one, they begin with good intentions and end up with a bad Photoshop clone.
Also, you can just use the selection tool.
Do they though? I've been in and around that project for many years and one common scenario that I've seen replaying over and over (and over) again is when people request something and then understand "please elaborate why this UI solution is better" or "can't right now, too many things to work on" response as a flat-out refusal.