Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Is this radical redesign of GIMP possible now?

librearts.org

Post reply on HN
Print view View original

201–210 of 306 posts

Re: Is this radical redesign of GIMP possible now?

#201

Post by garaetjjte »

IshKebab wrote: post #58

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 awk…

Solvespace is great but any slightly more complex model and its geometry kernel gives up :(

Re: Is this radical redesign of GIMP possible now?

#202

Post by squeaky-clean »

gkbrk wrote: post #132
mega_dean wrote: post #84

Earlier quoted context omitted.

> my first guess is usually wrong 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, an…

> 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 set…

Using a paid search engine is cheating, it's like using photoshop instead of gimp ;p

In Google the results for that quote are rather useless.

Re: Is this radical redesign of GIMP possible now?

#203

Post by squeaky-clean »

542458 wrote: post #14

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…

> 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.

Re: Is this radical redesign of GIMP possible now?

#204

Post by Hammershaft »

crazygringo wrote: post #159
cdcarter wrote: post #153

Earlier quoted context omitted.

Cmd-Shift-/ triggers the macOS help search in any normal app. Easy as pie.

Again, TIL. Thank you! 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…

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.

Re: Is this radical redesign of GIMP possible now?

#205

Post by chipotle_coyote »

crazygringo wrote: post #159
cdcarter wrote: post #153

Earlier quoted context omitted.

Cmd-Shift-/ triggers the macOS help search in any normal app. Easy as pie.

Again, TIL. Thank you! 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…

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...)

Re: Is this radical redesign of GIMP possible now?

#206

Post by shaggie76 »

I have a photography side-hustle and I use GIMP occasionally for advanced edits I can't do in my raw developer. In my semi-regular use over the last 3 years I've never found the UI/UX to be a problem but rather find myself coveting features GIMP either doesn't have or doesn't seem to do very well (smart subject masking, context-aware fill, etc). I'm getting what I pay for, so I don't feel I have any right to complain, but as it drifts farther behind the commercial offerings I suspect debates about the UX might not be what GIMP needs.

Re: Is this radical redesign of GIMP possible now?

#207

Post by squeaky-clean »

cycomanic wrote: post #70
lofaszvanitt wrote: post #62

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…

> 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 l…

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.

Re: Is this radical redesign of GIMP possible now?

#208

Post by TylerE »

calamari4065 wrote: post #155
542458 wrote: post #14

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…

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 inscrutab…

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.

Re: Is this radical redesign of GIMP possible now?

#209

Post by squeaky-clean »

zelphirkalt wrote: post #97
lofaszvanitt wrote: post #76

Earlier quoted context omitted.

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…

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.

> 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.

Re: Is this radical redesign of GIMP possible now?

#210

Post by bsder »

riotnrrd wrote: post #180
nabla9 wrote: post #123

All these programs like GIMP, Blender, Dune, should split into two. 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.

This is what we did at ILM, with our in-house software package Zeno. The lowest level of complete functionality was the "Sg" namespace (short for Scene Graph). Above that lived user-and-SDK-friendly commandline utilities layer (SgCmd) that was used for all scripting. Above that, finally, was the Oz layer -- the graphical UI. Oz actions called SgCmds, but never saw or touched the Sg layer. In theory, Oz was UI toolkit…

How did Python scripting work with that? It sounds like Python could only call the SgCmd layer but couldn't redfine anything at the Oz layer.

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.

Post reply on HN