Is this radical redesign of GIMP possible now?
librearts.org
librearts.org
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.
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" labels, and after pressing each key you had to stare at the cursor and wait to see if each key you pressed was correct before pressing another key, instead of focusing your attention on something more important while touch typing.
That's exactly what linear menus force you to do, but pie menus don't. You need to look at the screen to make sure you're pointing at the right linear menu item before confirming (which unfortunately has an extremely small target area compared to the area of a pie menu slice, which extend out to the screen edge), but not with pie menus, because they're directional. And each pie menu item is also the same distance from the cursor, instead of each being further and further away.
The following article discusses "gesture space", and how pie menus are superior to gesture recognition systems like Graffiti, because every possible pie menu gesture has a distinct easily understandable valid meaning, clearly separated from every other possible gesture, with a uniform maximum possible target area.
It is not possible to make a syntax error with pie menus, while with a gesture recognition system like Graffiti or normal handwriting recognition, most gestures are syntax errors, many gestures are close to other gestures in "gesture space", and all gestures have a much smaller "area" in gesture space than pie menu gestures. (Because pie menu gestures saturate 100% of possible gesture space with meaningful gestures, while handwriting recognition squanders most of gesture space on syntax errors.)
https://donhopkins.medium.com/gesture-space-842e3cdc7102
>Gesture Space
>The space of all possible gestures, between touching the screen / pressing the button, moving along an arbitrary path (or not, in the case of a tap), and lifting your finger / releasing the button. It gets a lot more complex with multi touch gestures, but it’s the same basic idea, just multiple gestures in parallel.
>Excerpt About Gesture Space
>I think it’s important to trigger pie menus on a mouse click (and control them by the instantaneous direction between clicks, but NOT the path taken, in order to allow re-selection and browsing), and to center them on the exact position of the mouse click. The user should have a crisp consistent mental model of how pie menus work (which is NOT the case for gesture recognition). Pie menus should completely cover all possible “gesture space” with well defined behavior (by basing the selection on the angle between clicks, and not the path taken). In contrast, gesture recognition does NOT cover all gesture space (because most gestures are syntax errors, and gestures should be far apart and distinct in gesture space to prevent errors), and they do not allow in-flight re-selection, and they are not “self revealing” like pie menus.
>Pie menus are more predictable, reliable, forgiving, simpler and easier to learn than gesture recognition, because it’s impossible to make a syntax error, always possible to recover from a mistaken direction before releasing the button, they “self reveal” their directions by popping up a window with labels, and they “train” you to mouse ahead by “rehearsal”.
[...]
>Pie menus benefit from Fitts’ Law by minimizing the target distance to a small constant (the radius of the inactive region in the menu center where the cursor starts) and maximizing the target area of each item (a wedge shaped slice that extends to the edge of the screen).
>They also have the advantage that you don’t need to focus your visual attention on hitting the target (which linear menus require), because you can move in any direction into a big slice without looking at the screen (while parking the cursor in a little rectangle requires visual feedback), and you can learn to use them with muscle memory, with quick “mouse ahead” gestures.
[...]
>Swiping gestures are essentially like invisible pie menus, but actual pie menus have the advantage of being “Self Revealing” [5] because they have a way to prompt and show you what the possible gestures are, and give you feedback as you make the selection.
>They also provide the ability of “Reselection” [6], which means you as you’re making a gesture, you can change it in-flight, and browse around to any of the items, in case you need to correct a mistake or change your mind, or just want to preview the effect or see the description of each item as you browse around the menu.
>Compared to typical gesture recognition systems, like Palm’s graffiti for example, you can think of the gesture space of all possible gestures between touching the screen, moving around through any possible path, then releasing: most gestures are invalid syntax errors, and they only recognizes well formed gestures.
>There is no way to correct or abort a gesture once you start making it (other than scribbling, but that might be recognized as another undesired gesture!). Ideally each gesture should be as far away as possible from all other gestures in gesture space, to minimize the possibility of errors, but in practice they tend to be clumped (so “2” and “Z” are easily confused, while many other possible gestures are unused and wasted).
>But with pie menus, only the direction between the touch and the release matter, not the path. All gestures are valid and distinct: there are no possible syntax errors, so none of gesture space is wasted. There’s a simple intuitive mapping of direction to selection that the user can understand (unlike the mysterious fuzzy black box of a handwriting recognizer), that gives you the ability to refine your selection by moving out further (to get more leverage), return to the center to cancel, move around to correct and change the selection.
>Pie menus also support “Rehearsal” [7] — the way a novice uses them is actually practice for the way an expert uses them, so they have a smooth learning curve. Contrast this with keyboard shortcuts for linear menus: you pull down a linear menu with the mouse to learn the keyboard shortcuts, but using the keyboard shortcuts is a totally different action, so it’s not rehearsal.
>Pie menu users tend to learn them in three stages: 1) novice pops up an unfamiliar menu, looks at all the items, moves in the direction of the desired item, and selects it. 2) intermediate remembers the direction of the item they want, pop up the menu and moves in that direction without hesitating (mousing ahead but not selecting), looks at the screen to make sure the desired item is selected, then clicks to select the item. 3) expert knows which direction the item they want is, and has confidence that they can reliably select it, so they just flick in the appropriate direction without even looking at the screen.
https://web.archive.org/web/20150506123310/http://uxmag.com/...
>Self-revealing gestures are a philosophy for design of gestural interfaces that posits that the only way to see a behavior in your users is to induce it (afford it, for the Gibsonians among us). Users are presented with an interface to which their response is gestural input. This approach contradicts some designers’ apparent assumption that a gesture is some kind of “shortcut” that is performed in some ephemeral layer hovering above the user interface. In reality, a successful development of a gestural system requires the development of a gestural user interface. Objects are shown on the screen to which the user reacts, instead of somehow intuiting their performance. The trick, of course, is to not overload the user with UI “chrome” that overly complicates the UI, but rather to afford as many suitable gestures as possible with a minimum of extra on-screen graphics. To the user, she is simply operating your UI, when in reality, she is learning a gesture language.
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.
Gimp isn't more complex than Photoshop. We don't need it to reinvent drawing applications.
I mean, linux today is full of macos GUI ripoffs and people love it - because Apple did some great UI design. I was using windows 11 recently and so many common things are complex to the typical user - e.g. making an application run at startup, anyway I'm in boomer mode so I'd better stop writing
They used to have a Windows build that was like this called "Gimpshop":
except new users.
you're part of a self-selecting population.
Personally I think UI experimentation is awesome, because we might end up with an interface usable on modern hardware.
https://www.pugi.cafe/uploads/db4664/original/2X/3/3f7a5d40e...
The best from-the-ground-up interface for a graphics program imo is that of CorelDraw, which survives as the interface to Inkscape. Rather than a craptasm of random, physical-analogue tools, you have a small number of highly functional tools giving you a wide range of options at any one point.
And yes, I'm "confusing" vector-graphics editors and bit-map editors. But imo they should be the same, the form of the image should be secondary. High film editors produce a script of editing operations to be done on the raw film. Bit-maps should also produce a sequence of operation that can be edited afterwards.
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.
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 ;)
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
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
Universal Search? Like F3 in Blender? Sure! just do it...
i studied for a year advertising and marketing degree at an university and i was at the best grades on photograph and any other class that required some creative stuff. all done in Gimp... i don't know how the late game is but certainly some company wanting the proprietary .blob of your work in Photoshop lang binaries exists. but i also think that if you are highly creative, there's so much to-do with simple tools
edit: not that Gimp can't do complex stuff but i remember clear sizing the boobs of a woman once at Photoshop and having some trouble on how-to with Gimp at home...
I know you're joking about "ONLY", but actually, linear drop-down menus are just an edge case of pie menus with multiple items in only one direction: down. So you can also make drop-down, -up, -left, -right, and other direction menus with a decent pie menu editor, like the Blender pie menu editor add-on.
Pie menus are much more useful if users can edit and create their own, especially in feature-rich extensible configurable applications that different people use in different ways like Gimp and Blender.
Blender has great pie menu support, and there's a nice pie menu editor add-on, but it really needs a built-in WYSIWYG pie menu editor, supporting on-the-fly direct manipulation WYSIWYG drag-and-drop pie menu editing, like Simon Schneegans's brilliant Gnome-Pie and Fly-Pie.
By "direct manipulation WYSIWYG drag-and-drop" I mean that ideally you should be able to put any existing menu into edit mode on the fly, and edit the circular pie, linear, or hybrid layout directly by dragging items around to different slices, instead of with an indirect linear scrolling list or outline in a separate window.
You need to be able directly and immediately edit them as they will appear to the user, not as some abstract linear tree outline (or god forbid, raw xml).
Pie Menu Development for Blender:
https://devtalk.blender.org/t/pie-menu-development-for-blend...
Blender Pie Menu Editor:
https://blendermarket.com/products/pie-menu-editor
Gnome-Pie (wikipedia):
https://en.wikipedia.org/wiki/Gnome-Pie
Gnome-Pie (github):
https://schneegans.github.io/gnome-pie
Gnome-Pie 0.6.1:
Fly-Pie 7: GNOME Shell 40+ and a new WYSIWYG Menu Editor!
https://www.youtube.com/watch?v=sRT3O9-H5Xs
Fly-Pie 10: A new Clipboard Menu, proper touch support & much more!
https://www.youtube.com/watch?v=BGXtckqhEIk
And Simon's new project, Kando:
Kando - An Open Source, Cross-Platform Pie Menu:
https://www.youtube.com/watch?v=ZTdfnUDMO9k
Follow and support the project on Ko-Fi:
Kando on GitHub:
https://github.com/kando-menu/kando
I also love the beautiful Trace and Coral menus he designed for his Bachelor thesis 11 years ago:
https://schneegans.github.io/news/2012/10/10/bachelor-thesis
The Trace-Menu:
The Coral-Menu:
More of his great stuff:
A retrospective of my 35 years of work with pie menus:
Pie Menus: A 30 Year Retrospective (2018):
https://donhopkins.medium.com/pie-menus-936fed383ff1
>Steve Jobs Thought Pie Menus Sucked: “That sucks! That sucks! Wow, that’s neat! That sucks!”
>On October 25, 1988, I gave Steve Jobs a demo of pie menus, NeWS, UniPress Emacs and HyperTIES at the Educom conference in Washington DC. His reaction was to jump up and down, point at the screen, and yell “That sucks! That sucks! Wow, that’s neat! That sucks!”
>I tried explaining how we’d performed an experiment proving pie menus were faster than linear menus, but he insisted the liner menus in NeXT Step were the best possible menus ever.
>But who was I to rain on his parade, two weeks after the first release of NeXT Step 0.8? (Up to that time, it was the most hyped piece of vaporware ever, and doubters were wearing t-shirts saying “NeVR Step”!) Even after he went back to Apple, Steve Jobs never took a bite of Apple Pie Menus, the forbidden fruit. There’s no accounting for taste!
The ideas behind pie menus have actually been around for even longer than that, since at least 1969:
Flight of the PIXIE - Yuja Wang:
https://www.youtube.com/watch?v=jDrqR9XssJI
>Dedication and Thanks to: Neil E. Wiseman, Heinz U. Lemke, John O. Hiles, PIXIE: A New Approach to Graphical Man-Machine Communication, Proceedings of 1969 CAD Conference Southampton IEEE Conference Publication 51, pp. 463–471. David Chapman, Cambridge University Library. Remixing and Synchronization with AfterEffects by Don Hopkins.
>This film demonstrates an early graphical user interface in use. It was made in 1969 to accompany a paper entitled “PIXIE: a new approach to graphical man-machine communication” presented at the 1969 CAD Conference held in Southampton.
https://www.cl.cam.ac.uk/library/archives.html
PIXIE ran on a PDP-7 with a Type 340 CRT vector display with a light pen, networked with the Titan at Cambridge University, and was one of the earliest examples of a network distributed gui application, developed by Neil E. Wiseman, Heinz U. Lemke, and John O. Hiles.
https://www.cl.cam.ac.uk/research/rainbow/people/neilw.html
https://en.wikipedia.org/wiki/Titan_(1963_computer)
https://en.wikipedia.org/wiki/PDP-7
David S H Rosenthal: Kids Today Have No Idea:
i think there's so much potential to trackball gestures. have you thought about multiple commands at the same direction based on distance? (could be useful for setting the volume/brightness, for example)
But until such a day as Fly-Pie-like features and editors are built into every desktop and application and browser user interface toolkit, I do think Blender also requires its own specialized WYSIWYG pie menu editor that knows about Blender's command and input systems and user interface capabilities. But it should be inspired by Simon's work on Gnome-Pie, Fly-Pie, and Kando. Also drawing 3D pie menu items and animated feedback would be really cool and useful, so you can easily make pie menus of 3D Blender content, like a tree-structured clipboards or asset libraries, or live iconic previews of the effects of editing commands!
All of these ideas could be applied to Gimp too, of course, but I've found the Blender developers to be much more open to entertaining other people's ideas and contributions about user interface design than the Gimp developers, who have been historically NIH-limited and stubborn (especially about changing the name to something less offensive to the general public). At least Blender already supports pie menus well, and changed the default mouse bindings in response to user demand, and has made huge strides in usability lately. At this point I think it would be much easier to just add a great image editor to Blender, integrated with its video editor, than try to change the minds of the Gimp developers.
I love the capabilities of the current Blender pie menu editor add-on, since it supports linear menus and user interface dialogs as well (even embedding them in pie menus, to make hybrid layouts). But it doesn't support WYSIWYG editing, or on-the-fly editing of menus in place (like HyperCard) without using a dialog in another window and using a linear list or outline to represent radial layout, which is very confusing and hard to use.
The first approach I took to pie menus was to represent pie menus as containing items, and then lay the items out in a circle, starting at an initial angle (typically up), and in a particular direction (either clockwise or counter clockwise). But that has its problems, when it comes to editing, and supporting other than one item per direction.
So I've taken a different approach of pie menus containing slices, and slices containing items. So to create a pie menu, first you define how many slices you want, then you add zero or more items to each slice, by dragging and dropping them in. So the directions do not all change around when you add or remove an item, and you can leave empty slices, and you can also put multiple items in any slice.
Each slice can be configured with various layout and tracking and drawing policies.
One useful policy is a "pull-out" slice that dislays one item at once (like a font size), which changes as you pull out, switching between items by the distance. And the items can be discrete (like a linear menu of font faces) or continuous (like an exact floating point font size).
Another policy is show all the items in the slice layed out in the slice direction, like a linear menu. That lets you make a linear menu by simply using one slice that points down, and putting multiple items in it. Of course long text labels only work well in the up and down directions, but icons work nicely along the horizontal and diagonal directions, and you can display the selected text label in the menu center when its icon is selected, as feedback.
This shows several kinds of pull out pie menus, for selecting fonts and colors:
Just the Pie Menus from All the Widgets:
https://www.youtube.com/watch?v=mOLS9I_tdKE
This shows an experiment in exaggerating the increased precision of direction that you get by moving the cursor away from the menu center:
Precision Pie Demo:
https://www.youtube.com/watch?v=c0scs59va4c
>This is a demonstration of the precision pie menu under the NeWS window system. It's an experiment in exaggerating the extra precision that you get with distance as you move out further from the menu center of a pie menu. Normally the further you go from the center the more control you have over the angle, but if you want to input an exact number like an angle you might want to get it down to the a certain number. But you run out of screen space before you get enough leverage to change the number to what you want. Now what happens here is that when you poke out, it makes a flexible lever that the further out you go the more flexible it becomes, and you have much finer control over the number. So as I move around back in and out I'll poke it into a different place and just come out further to get a lot of leverage and dial exactly the number I want. So here's what happens when you go around to the other side. *POP* And as you get nearer it gets less and less flexible. Generally you kind of eyeball it and then get it exact like 93: well there's 93, or 273: there's 273.
first thing that pops is a phrase of some biologist regards why evolution made plants green and not blue (physically, blue can absorb way more energy from the sun)... SPOILER: because makes the plantae organisms way more stable rather than performant (which opens up less windows for failings regards evolution). i use Gimp for digital collages, dead simple pixel-art and even composing a poem book for my beloved one! and that tool if it isn't perfect for the job, is probably about adjusting expectations ¶ why society can't re-signify a offensive word?
we have Krita (i never used) too... Gimp with its core open (viva the GNU license)... who knows how a bunch of hackers doing stuff for free feel when some fancy hipster smelling proprietary apple juice appears suggesting UX re-write (just in case i didn't even read the blog) based on what the rotten industry ⟨most of the time, rot⟩ wants! --cheers to a more slow paced and thoughtful world, by the way
i think pie-menus also should add a keyboard navigation. for me they are more than just controlling stuff with the pointer (interesting mailing list read about what Apple came after a research around 30 million of USD on UX: https://www.asktog.com/TOI/toi06KeyboardVMouse1.html ※ SPOILER: the mouse wins), but, again, for me radial-menus are much more than using the pointer but rather a sweet visualization, too.
different keys on hold for different functions when selecting a pie-menu direction etc. the sky isn't the limit anymore - also some thoughtful consideration where the mouse should be transported (if at all) when opening certain menus?
If the GIMP developers really want to score an edgy rhetorical point about how society should get over its uptight wokeness and let them use any word they want whenever they want, and that's the hill they choose to die on, then how about they go all in, and try convincing society to re-signify the n-word by using it IN ALL UPPER CASE as the name of a hard-to-use paint program with an overly complex incomprehensible user interface for TempleOS, then come back to me after a few years and let me know how well that went.
Prejudice by Tim Minchin:
https://www.youtube.com/watch?v=KVN_0qvuhhw
At least the Blender developers finally listened to reason, admitted they made a mistake, and switched the left and right mouse button behavior, which wasn't nearly as offensive to as many people as "GIMP", whose name makes it kind of hard to evangelize around the school or office without coming off like a flaming MAGA asshole.
Donald Trump appears to mock a reporter's disability:
https://www.youtube.com/watch?v=mdLfkhxIH5Q
By stubbornly refusing to change the name, the Gimp developers have lost the right to whine and feel sorry for themselves about how unpopular it is and how nobody takes them seriously. Because in the intervening 25 years since 1998, 4chan and GamerGate and MAGA and Q-Anon and January 6 and Elon Musk have kind of spoiled the coolness and originality of that rebellious "edgelord" attitude.
If you have to explain to people, "I'm not really ableist, but I am simply participating in performance art to resignify a derogatory slang term for handicapped people or submissive S&M sex slaves as the name of a paint program!" you have already lost them.
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.
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.
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.
I don't like the GTK crowd's approach in regards trying to make everything work within the GNOME design paradigm. It doesn't look good on all platforms, and feels more hamfisted then anything else.
Sad to see some in the comments criticise GIMP so hard, I get it doesn't compete with professional proprietary software. But it's still a very useful image editing tool, that I use a lot.
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 be racist, and nobody forced GIMP developers to ignore all the perfectly valid arguments about Photoshop's and pie menu's usability, just because somebody wasn't sufficiently nice to them once.
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.
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".
This is a shortcut for Cut+Paste, which I always use anyway because I find it more intuitive.
There should be a library that has the functionality and data structures to manipulate data. The UI should be a separate project with different people.
There could be multiple GUI's for the same project or same GUI framework for multiple projects.
We would be much better off if GUI was a replacement for the shell instead of a replacement for every individual shell utility.
In theory, Oz was UI toolkit agnostic but, as anyone who's ever done UI work will understand, it rapidly became wedded to the toolkit we used (a heavily customized version of Tk). This made the eventual switching to Qt very, very difficult. So difficult it nearly destroyed the artists' faith in the R&D group. (Extremely late delivery, buggy, and coming at the manpower cost of not doing any improvements on the tool itself for a year and a half.)
And, how did Python call that SgCmd layer? If instead you wanted Tcl (or Ruby or ...) to call that SgCmd layer, how would that work?
Interested in this as I'm very much bumping into problems like this right now.
It looks to me like people are regularly fantasizing the size and structure of this project.
Couldashouldawoulda do not work when there aren't enough hands. We shouls be thanksful to have those powerful programs provided to us first and foremost.
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!
It adjusts shortcuts and a bit of the interface to feel a lot more familiar.
I’ve been using photoshop for a few years and just transitions to gimp a few months ago, and so far I did not miss any of the photoshop functionality.
(I only do personal photography manipulation, no design or any sort of drawing that might need a tablet)
https://github.com/Diolinux/PhotoGIMP
But it's interesting if we can get FOSS Gui toolkits that allow for different approaches to menu/toolbar/discovery where the user can easily adjust and select how things should work - like readline Emacs/vi selection on steroids for Gui.
Before that you should fix the names. Searching for Gaussian would't give me Gaussian blur because the script for that is in a different name.
And if you kill the menu, you are killing the whole project.
On the contrary, it's the first item in search results. The very first one.
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.
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.
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.
"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/#...
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.
>Another interesting thing here is that when you do something like drawing a line, for example, you get these nice visual hints here, just above the status bar:
>Interaction hints
>The idea is coming from Blender obviously, and it would make a lot of sense to use this in applications like GIMP and Inkscape. Here is a good reason why.
The first place I ever saw this feature was on the Lisp Machine. It was called the "mouse-documentation" line.
Operating the Lisp Machine:
http://bitsavers.informatik.uni-stuttgart.de/pdf/symbolics/L...
>1.3 The Mouse (pp. 3)
>The mouse is a pointing device that can be moved around on a flat surface. These motions are sensed by the Lisp Machine, which usually responds by moving the cursor around on the screen in a corresponding manner. The shape of the cursor varies, depending on context. See chapter 10, page 40.
>There are three buttons on the mouse, called Left, Middle and Right. They are used to specify operations to be performed. Typically the user points at something with the mouse and specifies an operatin by clicking the mouse buttons. Rapid double clicks are conventionally distinguished from single clicks. Thus, in any specific context, there are up to sex operations that can be performed with the mouse, invoked by Left, Left Double, Middle, Middle Double, Right, and Right Double. Some of these operations are local to particular programs such as the editor, and some are defined more widely across the system.
>Typically operations available by clicking the mouse button are listed at the bottom of the screen. This display changes as you move the mouse around or run different programs.
>Sometimes holding a mouse button down continuously for a period of time may also be defined to perform some operation, for example drawing a curve on the screen. This will be indicated by the word "Hold". For example, "Middle Hold" means to click the middle mouse button down and hold it down, releasing it only when the operation is complete. "Left Double Hold"means to click the left mouse button twice, holding it down the second time until the operation is complete.
>Occasionally a long click is distinguished from a short one, as a Morse Code dash is distinguished from a dot. In cases it doesn't matter exactly how long the button is held down, as long as it is perceptibly longer than the usual rapid sgtrike. Such a click will be described by the word "Long" as in "Right Long".
>The mouse is completely "soft", like the keyboard: The Lisp Machine can be programmed to interpret the mouse in any desired fashion. The protocol that has been chosen, however, is extremely general and should suffice for almost all needs.
[...]
>2.1 The Geography of the Display [...]
>2.1.2 The Who-Line and Run-Lights (pp. 5) [...]
>Above the who-line there is a line of mouse-documentation, which is displayed in inverse video to make it easy to move your eyes to it from someplace else on the screen. This line tells you what the buttons on the mouse would do if you clicked them with the mouse where it currently is. If the line is blank, it means the default mouse buttons are in effect; clicking Left will select the window pointed-to, and clicking Right will get you the system menu (these are explained later).
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.
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.
and soo many UI features are a pain - the main one for me is using text / fonts, it feels like it's designed to fight you
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.
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.
- no ads
- no "runs best on Chrome"
- no network connectivity dependencies
I like programs to work on an off-line computer.