[joaomacp]

I use Gimp from time to time, and often get frustrated with its... unique UI. It's nice to see they're hearing feedback and working on it :D

A tip for others that feel the same: if you've used Photoshop before and are used to its UI, try the free Photopea website. It's a Photoshop "clone" that works really well in web (I believe it's a solo dev doing it too). It's replaced Gimp for me lately.

[0points]

I would recommend Krita instead of a website.

Websites are not automatically free or opensource, they also require internet access and can sneakily copy the files you are working with.

If photopea is free today, it may cost money tomorrow.

Krita exists for Windows and macOS too nowadays.

https://krita.org/en/

[cxr]

> Websites[...] can sneakily copy the files you are working with

You have made one of the most baffling logical errors that commonly crop up when people criticize browser-based apps.

Browser-based apps execute in a sandbox. They are more constrained in what they can do in comparison to a traditional program running on your machine. Any nefarious thing a browser-based app can do, a local program can do, too, and not just that, but they can do it in a way that's much harder to detect and/or counteract.

There are good reasons available if you want to criticize browser-based apps. This is not one of them.

[em-bee]

i can remove network access capabilities from a desktop app after it is installed. i can't easily do that with an app running in a browser.

likewise monitoring and detecting network access per application is easy. tracking down which browser tab is making which network connection is a lot harder.

[mardifoufs]

Go to the network tab of your browser's dev tools. It's literally easier than with a desktop app.

[em-bee]

i am using that already. at least in firefox the network tab only shows which destinations generate traffic. it does not show which tab the traffic comes from. since any page can connect to multiple destinations, not just the one where the page is loaded from, this is not enough to identify the culprit.

[cxr]

You are either confused about something, or you're simply refusing to engage with reality.

> Any nefarious thing a browser-based app can do, a local program can do, too, [or worse!]

[em-bee]

you are not wrong on the comparison but you miss the tools available to contain a desktop application that are not available for a browser application. by default a browser application is more limited than a desktop application, but those limitations also reduce the possible functionality of a browser application, and they are locked in place as far as i am aware of.

for a desktop application, at least on linux there are tools available to further constrain its access to the system by monitoring its activity, removing capabilities or placing the app in a container or even a VM. (VM are available on windows and mac too, but i don't know about other features)

to contain a browser app in this way i would have to run a contained copy of the browser as a whole, and i still can't easily limit network access.

further, almost all desktop applications on linux come from a trusted source or a trusted intermediary and have undergone at least some kind of review, whereas browser applications can be reviewed but it is non-trivial to ascertain that i am running the exact same version that was reviewed.

it is possible, and it is my hope for all this to change. i actually believe browser applications are a good idea, but the ability to audit, and constrain browser applications needs to improve a lot for that to happen.

[0points]

I am not sure about your level of computer literacy, so sorry in advance if I give a a overly detailed response.

Certainly a website is allowed to process files you upload to it and the javascript are allowed to XMLHttpRequest in that sandbox.

This is outside the control of the user. While had it been an app running locally, I could restrict network access or other resources.

Of course the web developer can chose to process the file client side only, but generally when you upload a file to a website, it gets uploaded and processed by their servers.

Surely you can verify this yourself while using the website, but I am confident that most users of a website wouldn't do that and be none the wiser how their data is being processed.

TLDR: I don't believe the average web user is capable of distinguishing a webapp that works in offline-only mode from a ordinary website.

[cxr]

> I am not sure about your level of computer literacy, so sorry in advance if I give a a overly detailed response

In technical discussions, this is what I call "The Move". It comes from a desire to position the person making The Move as more knowledgeable and experienced and therefore correct and the other person as relatively new, inexperienced, lacking in wisdom, and naive. It's extremely sophomoric and perversely favored by those who lack the attributes they're trying to project. Don't do it.

I know how browsers and web apps work. I'm a former Mozillian, and among other things, I wrote, edited, and maintained the JS docs on developer.mozilla.org.

Even aside from The Move, nothing else that you wrote out here is especially relevant. The central observation I made is that users have more reason to be circumspect of non-browser based programs that they download and run than they do of browser-based programs because any nefarious thing a browser-based app can do, a native executable can do, too—or worse.

Anyone who has a gut feeling to the contrary is doing exactly that: operating on vibes and intuition and trying to reason with their gut instead of using actual reason to do what is ultimately a straightforward calculation.

(And the thing is, you and everyone else in your camp already knows the truths I've written out here. If you disagree, then we'll set aside one day a year that we'll call Native App Day. For Native App Day, browsers will refuse to execute browser-based apps. Instead everyone who publishes a web app will agree to publish programs packaged in the native executable format for Mac, Windows, and Linux, and everyone who typically uses the web app will run these executables with the same alacrity they apply when they undertake to use the web app. This will be strictly enforced, and there will be no cheating by folks who just refuse to use the computer on Native App Day.)

[0points]

>> I am not sure about your level of computer literacy, so sorry in advance if I give a a overly detailed response

> In technical discussions, this is what I call "The Move". It comes from a desire to position the person making The Move as more knowledgeable and experienced and therefore correct and the other person as relatively new, inexperienced, lacking in wisdom, and naive. It's extremely sophomoric and perversely favored by those who lack the attributes they're trying to project. Don't do it.

Nonsense. Judging from your previous post it is apparent you are speaking outside of your expertise. Smearing labels all over rather than factually responding only makes it more so.

You claimed sandboxed browser apps was "more secure" than a traditional app.

Nobody suggested otherwise. In fact, we weren't discussing brower sandbox security model up to that point, but the differences between a online-only closed source web app and a traditional FOSS app.

> I know how browsers and web apps work.

So do the lot of us here, yet you don't seem to share a common understanding of the domain.

You do have a skewed understanding of the web app and seem to fail to understand why people would want a traditional app they could inspect and lock down as they please.

This suggest to me you are junior and/or suffering from a bit of Dunning Kruger because you might be skilled in other areas (in this case skilled in web dev and unskilled in traditional app dev), hence my previous comment about your skill level.

You responded to a lengthy post I made, and yet you fail to address any of the points raised.

> The central observation I made

.. was questioned by me and others and you just ignore what was said.

> And the thing is, you and everyone else in your camp already knows the truths I've written out here.

Get off your high horse.

You haven't shared shared any truths, you haven't addressed the issues we raised and you have a rather rude tone saying things like:

> You have made one of the most baffling logical errors that commonly crop up when people criticize browser-based apps.

And then continuing to fabricate intent.

(My point still stands).

[cxr]

K.

[porridgeraisin]

> require internet access It's a PWA and works offline perfectly.

[EasyMark]

Krita works well for me on linux, but I get a lot of random crashes and weird graphics issues on Mac, It’s not worth it there for me. Not idea about windows.

[burrish]

Krita is more geared toward digital drawing than image processing, I recommend Affinity Photo

[sam_lowry_]

> frustrated with its... unique UI

It's a matter of habits. For me, Gimp is the primary image editing tool and all others feel alien.

[James_K]

There's habits sure, but GIMP also just has a lot of bad UI. For instance if you insert text, you have to click exactly on the black region of the character to select the text. This is really awkward because it means when you click on a letter to try and move some text, sometimes your click will go through the hole in the middle of the letter and select the thing behind the text. Also worth noting that this update is the one allowing people to edit rotated text and it took 20+ years. This is really bad UI/UX.

[agumonkey]

That's interesting. I have used and enjoyed a ton of software in different domains (from nothingreal shake to gnu ed) and so far gimp still wins the gold medals of triggering me. A rare feat.

[idoubtit]

Many years ago, I lost my work because of this "unique UI" and pledge never to use Gimp again, unless its behavior changed.

When you open a non-Gimp file, for instance a PNG, and you want to update the source file, you need to "export" to PNG. And if you close the tab, Gimp warns you that your work isn't saved, because it hasn't been saved in its native xcf format. There is no way to know if the work has been saved to the original file. At least, that was the behavior at the time.

So I had opened a dozen of (versioned) PNG files, modified them, then overwritten the PNG files. On closing, Gimp warned me that none of the images was saved. I ignored the warning since I didn't want to track the changes in xcf files. It turned out one the files had not been "exported" to PNG.

[flufluflufluffy]

This is standard behavior in pretty much any kind of art/content creation app. You have a project file which can be saved and reopened in the app, saving the state of the layers/effects/etc to be edited later, and can “export” a final render to a specific format for your medium. Image/video editing, digital audio workstations, 3D-modeling programs, they all behave like this, for good reason since it usually takes a long time to export to a specific format, and when you do, you lose the ability to change anything.

Think of it like source code, and each exportable file type is like a compilation target.

[inferiorhuman]

Think of it more like GIMP chasing non-existent users while ignoring the workflow of its actual users.

[nineteen999]

This is one of the weirder design changes that Gimp made, and it wasn't always that way. IIRC, the "save" option worked as you described in 2.0 but changed to the newer behaviour in either 2.2 or 2.4. Baffling because it really does change the workflow and coupled with the GTK+ load/save dialog boxes, it really has become much less intuitive than it used to be.

[prmoustache]

There is literally an "overwrite file" command in the file menu.

You didn't lose data because of bad UI but because you are illiterate. You just said it, it warns you. If you can't understand what "none of the images was saved" means, there is no UI that can save you except autosave. But autosave is something you clearly don't want in a photo/image editor, even smartphone apps do not autosave photo edits.

[init2null]

That's a rude and somewhat inaccurate response.

Photoshop has autosave that works well, even for files with hundreds of layers, so it can be done. That being said, I can see that it's less useful when someone chooses not to save.

As for export, a single-layer file should be considered saved when one exports to lossless. A multi-layer file needs a different prompt, and I note Gimp has that now. It flags the file as "Exported to xxxxxx.png" in the Quit dialog.

[prmoustache]

autosave is useful for a file format of working files, like psd if non destructive changes are supported. But it would be stupid for exported end result format like jpeg, png, webp or pdf where changes cannot be recorded.

[Mashimo]

Yes, even though I never use photoshop and used Gimp for over 15 years it's a frustrating UI. I dislike it. Non destructive editing is a big upgrade though.

I also use Photopea from time to time. Can recommend.

[GaggiX]

If only a mad man would make a Photopea/Photoshop clone open source, then everyone (who has the skills) would be able to not only use a decent open source image editor, but one that can be fully customized to your needs.

[prmoustache]

I've loaded photopea, krita and gimp side by side and really there are absolutely no major differences in UI.

This is the kind of dismissive posts thrown by people who haven't used gimp since 1999 and keep repeating the same lies every gimp release.

[cranberryturkey]

Have you tried Krita yet?

[mfld]

I like using pinta for the "easy" cases.

[Sloowms]

I don't use any photo editing tool but I know there is photogimp which makes gimp look like photoshop.