[HN Gopher] Is this radical redesign of GIMP possible now?
___________________________________________________________________
Is this radical redesign of GIMP possible now?
Author : sacrosanct
Score : 173 points
Date : 2023-11-11 17:27 UTC (5 hours ago)
(HTM) web link (librearts.org)
(TXT) w3m dump (librearts.org)
| superkuh wrote:
| GIMP is still a Gtk2 program.
| capableweb wrote:
| It's still ironic to me that the program that GTK was made for
| and that popularized the toolkit, haven't managed to move to
| its latest version yet.
| superkuh wrote:
| 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.
| pengaru wrote:
| 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.
| superkuh wrote:
| 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.
|
| re: Gtk4, they're already moving on to Gkt5 (wayland only
| though https://www.phoronix.com/news/GTK5-Might-
| Drop-X11).
| pengaru wrote:
| 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.
| superkuh wrote:
| 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.
| bitwize wrote:
| While GTK started off as the GIMP Toolkit, it has since
| become the GNOME Toolkit, so it doesn't really track GIMP's
| needs anymore.
| radium3d wrote:
| 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?
|
| https://www.gimp.org/news/2019/01/02/gimp-and-gegl-in-2018/
| superkuh wrote:
| They're trying. And I appreciate that. Unfortunately it's
| still on-going in 2023.
| radium3d wrote:
| 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."
|
| https://www.gimp.org/news/2023/07/09/gimp-2-99-16-released/
| #...
| cratermoon wrote:
| 2.99.16 is the latest build on the 3.0 path:
| https://www.gimp.org/news/2023/07/09/gimp-2-99-16-released/
| capableweb wrote:
| 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.
| bestouff wrote:
| Blender has something else. Loads of money compared to Gimp.
| chongli wrote:
| 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.
| n3storm wrote:
| 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.
| jacoblambda wrote:
| 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.
| vasili111 wrote:
| Where the money comes from?
| HankB99 wrote:
| https://apps.microsoft.com/detail/blender/9PP3C07GTVRH?hl=e
| n... (hopefully that link works for others.)
| avhon1 wrote:
| They have a basic diagram on this page:
|
| 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.
| pavlov wrote:
| 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.
| Hemospectrum wrote:
| 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.
| thomastjeffery wrote:
| > 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.
| jimmaswell wrote:
| 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?
| thomastjeffery wrote:
| 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.
| jimmaswell wrote:
| For me, I find that modality in Blender annoying and
| confusing.
| pavlov wrote:
| 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.
| johnchristopher wrote:
| > (Remember SoftImage?)
|
| 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.
| cardanome wrote:
| 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.
| IAmNotACellist wrote:
| GNOME devs shaking right now. In fact, they may remove a few
| features they don't care about out of spite.
| Tao3300 wrote:
| > [Search] kinda works when you generally know what you need or
| how a feature you want could be called
|
| I mean, that's how I feel using the GIMP menus. I never know
| where anything is, and my first guess is usually wrong.
| IshKebab wrote:
| The worst is Inkscape. They somehow manage to put every option
| in the last place I look.
| cozzyd wrote:
| I still haven't gotten used to Inkscape's newer UI.
| omoikane wrote:
| 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.
| mega_dean wrote:
| > 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, 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.
| theteapot wrote:
| > ChatGPT told me
|
| 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....
| hactually wrote:
| so, similar to another human telling you?
| gkbrk wrote:
| > 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.
| phendrenad2 wrote:
| 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.
| alpaca128 wrote:
| Nobody is stopping you from contributing.
|
| A lot of FOSS projects could do a lot of amazing things if they
| had enough people who "just do the work".
| eviks wrote:
| 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
| alpaca128 wrote:
| The linked article talks about a fork created to redesign
| Gimp's UI, so there were no gatekeepers.
| eviks wrote:
| My point was about merging a fork, not creating it.
| phendrenad2 wrote:
| 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.
| michaelmrose wrote:
| Wouldn't it be accurate to say that as far as GUI toolkits
| the gate keeping is really just GTK? Few seem to complain
| about QT being to minimalist.
| phendrenad2 wrote:
| "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.
| alpaca128 wrote:
| > who says I want to contribute? Maybe I'm perfectly happy
| using Photoshop
|
| 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.
| wredue wrote:
| 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.
| rebuilder wrote:
| 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.
| genman wrote:
| 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)).
| sparkie wrote:
| 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.
| ozim wrote:
| 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.
| tormeh wrote:
| As if most old GUIs don't also have hidden menus.
| renewiltord wrote:
| 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.
| evbogue wrote:
| 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.
| EspressoGPT wrote:
| Requiring a copilot is a proof for bad UI design.
| torstenvl wrote:
| This is a terrible idea. The menu bar works great, integrates
| with shortcuts, and gives 100% discoverability.
|
| Anyone who wants to get rid of it is a bad developer and a bad
| person.
| kennywinker wrote:
| Meanwhile gimp probably has lower % usage rate than it did 20
| years ago. Improvements are needed, and this is just menus in a
| popup box anyway
| torstenvl wrote:
| > _just menus in a popup box anyway_
|
| 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.
| gaganyaan wrote:
| How does that inhibit accessibility?
| ohdannyboy wrote:
| It would not shock me to learn that GIMP has been a multi
| decade study to find out how bad a UX has to be before the FOSS
| community starts to care.
| rchaud wrote:
| 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.
| torstenvl wrote:
| 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.
| EspressoGPT wrote:
| > GIMP has one of the best user interfaces of all community
| driven open source software.
|
| /s
| Clamchop wrote:
| Um... what? That would be terribly unfortunate for FOSS but
| thankfully it's not true.
| Euphorbium wrote:
| Ummm, have you used ANY software ever?
| eviks wrote:
| how is discoverability 100% if you
|
| - can't search
|
| - don't have 100% functionality
| torstenvl wrote:
| Search is the opposite of discoverability for all the reasons
| covered in this thread and in the OP.
| eviks wrote:
| The OP doesn't make this absurd claim (search is how you
| discover things, it can't be the opposite)
| torstenvl wrote:
| Forgive me, but you must have only skimmed the OP. It is
| quite explicit.
|
| > _[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._
| 542458 wrote:
| 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.
| skrebbel wrote:
| > 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.
|
| This is the core point made in the article.
| echelon wrote:
| 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?
| et1337 wrote:
| Look at the Blender UI. Every command is searchable via F3,
| available via menus, and sometimes also available via a
| keyboard shortcut.
| derefr wrote:
| It looks like having multiple selectable interface layouts
| for different types of user with different discoverability
| needs. Photoshop does this.
| sparkie wrote:
| 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.
|
| [1]:https://en.wikipedia.org/wiki/The_Paradox_of_Choice
| eviks wrote:
| > 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
| Gibbon1 wrote:
| 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.
| CyberDildonics wrote:
| It looks like most content creation programs where
| somewhere there is a big list of everything you can look
| through.
|
| 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.
| crazygringo wrote:
| 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.
| psd1 wrote:
| My first exposure to command search was in VSCode, so there's
| that
| jonhohle wrote:
| 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).
| crazygringo wrote:
| > _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.
| cdcarter wrote:
| Cmd-Shift-/ triggers the macOS help search in any normal
| app. Easy as pie.
| crazygringo wrote:
| 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 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.
| ruinthemagic wrote:
| > It also doesn't have a keyboard shortcut to trigger it
|
| command + shift + ?
| SebastianKra wrote:
| There are various apps that present this index in a more
| accessible way.
|
| Raycast for example. It still wont find synonyms, but it
| works well enough that I frequently use it in Affinity
| and similar apps.
| jrumbut wrote:
| > 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.
| maven29 wrote:
| Ubuntu Unity DE used to offer this for all GTK apps through
| the HUD. You could hit alt and type to get to the menu item
| you need.
|
| Gnome turned out to be a poorly thought-out opinionated mess,
| learning all the wrong lessons from Apple's work.
| stuaxo wrote:
| Someone added this to Gtk 2 and 3 apps, but the mechanism if
| used isn't there in Gtk 4.
| benhurmarcel wrote:
| > 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.
| crazygringo wrote:
| 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...)
|
| It's progress!
| holoduke wrote:
| 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.
| kossTKR wrote:
| 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.
| calamari4065 wrote:
| 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.
| janalsncm wrote:
| 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.
| KaiserPro wrote:
| changing the GUI for a good reason makes sense, making it look
| like photoshop doesn't seem like a good idea.
|
| Photoshop is an arse to use, just like the GIMP. I just happen to
| have learnt gimp first.
| layer8 wrote:
| GIMP lost me when they switched to flat monochrome icons. Well,
| I still use the old version.
| Izkata wrote:
| 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.
| hurryer wrote:
| 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?
| KaiserPro wrote:
| 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.
|
| [1]https://github.com/bootchk/resynthesizer
| DustinBrett wrote:
| Would be cool if GIMP could move to the web like Photoshop is
| doing.
| 1aqp wrote:
| NO! It would not be cool.
|
| I like programs to work on an off-line computer.
| gaudystead wrote:
| Just curious... What is your logic behind preferring a web
| based application?
| spandextwins wrote:
| It's open source, fork it and knock yourself out.
| Izkata wrote:
| > 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.
| darklycan51 wrote:
| 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
| rchaud wrote:
| 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.
| krapp wrote:
| No "power user" is touching GIMP with a ten foot pole.
| rco8786 wrote:
| Somewhat tangential but is there any compelling reason to use
| Gimp over Photopea in 2023?
| cozzyd wrote:
| Never heard of photopea but doesn't appear to be free software
| or to run locally.
| rchaud wrote:
| Sure:
|
| - no ads
|
| - no "runs best on Chrome"
|
| - no network connectivity dependencies
| Gualdrapo wrote:
| - No need for an account to unlock all features
| tantaman wrote:
| What about an integrated LLM assistant for GIMP? Seems like
| that's the future for any professional application (e.g.,
| PhotoShop, CAD, Reason)
| timbit42 wrote:
| Sure. Then we could have a Beowulf Cluster of them.
| tantaman wrote:
| 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.
| eviks wrote:
| 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
| IshKebab wrote:
| 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!
| garaetjjte wrote:
| Solvespace is great but any slightly more complex model and its
| geometry kernel gives up :(
| lofaszvanitt wrote:
| 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.
| foobiekr wrote:
| 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.
| cycomanic wrote:
| > 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?
| hotnfresh wrote:
| 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.
| lofaszvanitt wrote:
| 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.
| zelphirkalt wrote:
| 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.
| marcinreal wrote:
| I've never used PS and still think Gimp is probably the
| most unintuitive UI I've ever used.
| epcoa wrote:
| 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.
| cycomanic wrote:
| 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.
| Miraste wrote:
| 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.
| danem wrote:
| 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.
| epcoa wrote:
| 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.
| vetinari wrote:
| > 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.
| avhon1 wrote:
| > 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.
| lofaszvanitt wrote:
| 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.
| prmoustache wrote:
| > NO RIGHT CLICKING! Nobody does a right click on a crop
| rectangle.
|
| Well, previous commenter just did it. So that just mean
| that your peremptory decrees are just that. Peremptory and
| not really universal.
| Almondsetat wrote:
| And this is why you will never reach a decent audience
| for that program
| michaelmrose wrote:
| 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.
| Almondsetat wrote:
| Photopea was developed by a single programmer, runs on
| the web and it's leagues more usable than GIMP
| michaelmrose wrote:
| This isn't a good indication that gimp can do as well
| Almondsetat wrote:
| It actually is. In fact it mighty be the proof that
| throwing everything away and writing a new version from
| scratch might even be preferable
| michaelmrose wrote:
| 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.
|
| A glib well this guy did it is not an analysis.
| epcoa wrote:
| The comment you're replying to is pretty explanatory and
| insightful. Do you have anything worthwhile to add here?
| avhon1 wrote:
| 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).
| epcoa wrote:
| > 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.
|
| 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.
| refulgentis wrote:
| 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.
| cycomanic wrote:
| 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).
| cyanydeez wrote:
| I got hooked on the 2.78 UI And can't manage to do more than
| half of what I know blender can do
|
| the bitching is mostly the disconnect from version to version.
| taneq wrote:
| 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.
| corkybeta wrote:
| 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.
|
| https://github.com/ubuntu-mate/mate-hud
|
| https://jamcnaughton.com/2015/10/19/hud-for-xubuntu/#jp-caro...
| flas9sd wrote:
| The global menu top-bar and the HUD application search was what
| I missed most when I went with the flow and settled in GNOME
| >36ish.
|
| 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
| Jerry2 wrote:
| 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.
| pmontra wrote:
| 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
| Zambyte wrote:
| > At that point you realize that what you really want is MS
| Paint from Windows 3.1
|
| Or a drawing program like Krita.
| wruza wrote:
| Or Paint.NET, which does maintain aspect ratio on shift.
| EspressoGPT wrote:
| I switched to macOS several years ago and the only thing I
| still miss from Windows is something like Paint.NET.
| Zambyte wrote:
| What's wrong with Krita?
| johnchristopher wrote:
| 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.
| jeroenhd wrote:
| 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.
| rpgbr wrote:
| Have you tried Pixelmator Pro?
| 7speter wrote:
| Lots of great tutorials on Youtube
| Gualdrapo wrote:
| > GIMP is not designed to be used for drawing
|
| 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.
| michaelmrose wrote:
| Pony up some substantial money and make it contingent on
| meeting guidelines.
|
| Unless prefer to offer vague suggestions by way of insults to
| work donated for free.
| cypress66 wrote:
| It'd be better to fork it and hire a new dev, than throw
| money at the devs that don't understand their own product.
| CamperBob2 wrote:
| Or DeluxePaint II from the early 1990s.
|
| 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.
| jpavel2 wrote:
| If you're a DeluxePaint fan, then GrafX2 is the way to go
| these days.
| CamperBob2 wrote:
| Eh, maybe not looking for something _quite_ that faithful
| to the original. But good to know!
| asddubs wrote:
| If you want that, use kolourpaint
| Euphorbium wrote:
| The only tutorial gimp needs is how to uninstall it, and how to
| remove it from the distribution.
| InCityDreams wrote:
| Portable versions exist.
| thibran wrote:
| How difficult would it be to train an AI with all GIMP
| documentation and online Q&A's and ship an offline support-chat
| with GIMP?
| ghostly_s wrote:
| 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_.
| great_psy wrote:
| Slightly off topic, but for anybody looking to make the
| transition from photoshop to gimp, check out this extension:
| https://github.com/Diolinux/PhotoGIMP
|
| 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)
| agumonkey wrote:
| Go study Alias Maya, it was a solid timeless ergonomic base. Modo
| too (it was the equivalent of FP for UIs in 2000s, rare).
| Photoshop is probably still extremely efficient.
| wruza wrote:
| None of modern UIs are built the way I'd like to work with tool
| apps as an amateur, nonpro, jack of all trades master of none. I
| only use a small subset of functions. Old programs which had
| programmable toolbars in 98/2k+ era were the most useful in that
| regard. I just set these toolbars (and key bindings) up for
| frequent functions and was fine with it up until when it
| disappeared. It reappeared in windows start menu, but that's it.
| Configurable UIs are obsolete and over, so we have to explore
| various common denominators. So that new users could still
| struggle with finding menu items and power users could still
| struggle with quick access. Because setting up your workspace
| went out of fashion.
| luqtas wrote:
| NO! WE SHOULD USE RE-DO WITH PIE-MENUS ONLY :P
|
| 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...
| b5n wrote:
| Just to contrast the negativity here I'd like to say that GIMP is
| great software, and I really appreciate all the hard work that
| has been put into it over the years. It's powerful, easily
| scriptable, and I'm eternally grateful for everyone's
| contributions to the project.
|
| https://www.gimp.org/docs/
| EspressoGPT wrote:
| Have you actually been using it?
| smoldesu wrote:
| I use it regularly, but my use case doesn't really extend
| beyond compositing images. Works great for me though, my only
| complaint is the startup time.
| 123pie123 wrote:
| it is a great tool I've been using for over 3 years
|
| 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
| nabla9 wrote:
| 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.
| BHSPitMonkey wrote:
| Sounds like you are sort of describing GEGL in the context of
| GIMP, though it would be difficult to draw that abstraction in
| a way that makes implementing competing GUIs straightforward or
| DRY.
| thomastjeffery wrote:
| That's true for literally all software.
|
| We would be much better off if GUI was a replacement for the
| shell instead of a replacement for every individual shell
| utility.
| riotnrrd wrote:
| 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 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.)
| amelius wrote:
| I think they should focus on incorporating LLMs and stable
| diffusion and make them more easily accessible.
| wafriedemann wrote:
| GIMP was a horrible outdated experience for me >15 years ago and
| I assume it hasn't gotten any better.
| SebastianKra wrote:
| I'm surprised there's uncertainty about _how_ Gimp should be
| redesigned. Just copy Photoshop! Select tools on the left,
| configure the current tool at the top, global options on the
| right. Affinity does this and nobody complains. Thanks to MacOS
| help search, we even already have the command search that this
| video proposes. And it has interaction hints too.
|
| Gimp isn't more complex than Photoshop. We don't need it to
| reinvent drawing applications.
| e12e wrote:
| There's also photoGimp:
|
| 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.
___________________________________________________________________
(page generated 2023-11-11 23:00 UTC)