That Time I Recreated Photoshop in C++

Furthermore, the OS can pick up the extensions, services, etc the app carries within its app bundle and offer them to the user to enable this way. No need to copy files to obscure directories (be it manually or with an installer), and when you trash the app bundle they’re all gone.

This is why merely having a copy of an app is enough to make QuickLook able to preview the filetypes the app is capable of opening. The system picks up the QuickLook extension in the app bundle and enables it.

It’s not perfect since small .plist config files get left behind, but it’s a whole lot more clean by default compared to the Windows approach.

> which is to stick this information in the executable

This is neat, shame they went completely the other way with file metadata. It forces a hidden .ds_store file in every single folder a mac touches just to store info like access time. Every other system stores this in the file itself.

I mean…that’s just the same thing right?

I cannot stand AppData, specifically the way it's often used to store files that should be in Documents.

Is there a book or site documenting these best practices somewhere? I'm getting into windows dev and am curious about them.

It would be annoying. If the use-case is as a portable application, but the application would want to let the user know (in a sufficiently loud manner) that it can install itself, then either the user would be forced to pay attention at that aspect every time it opens the application, or that "portable" application will have to somehow pollute the environment with (at least) a note for itself of the fact that user was offered but chose not to install anything. That note is usually just a first change in the system and, for a non trivial application, is way too easily followed by many other kind of saved changes, which in itself looks like a creeping install. Then, if the user would actually choose to install, the app will have to do what, make shortcuts to its current location, which may be a thumb-drive, or another less ideal placement for a program (because how many of us take time to think about file management anyway)? Or, if the application makes a copy of itself to a conventional place (for an application) in the system, then now the useless standalone executable either gets forgotten about or becomes a burden for the user (who has to decide what to do with it).

The most appropriate behavior for a portable application is for it to stay clean by default and only offer the user to explicitly enable persistency-dependent functionality. When the application starts, it checks if there's any previous trace of itself and depending on that it either keeps its portable-like clean behavior or switches to installed-like one.

I remember a game that did this in like 2006 (it was a small GUI program called drug baron or something like that - you bought and sold drugs and weapons with your sales and purchases affecting the market - like a text-based game without having to use the command line).

It didn't work so well (probably not programmed that well I guess).

I can’t target msvc or aarch-64-apple-* and compile a binary on Linux, without resorting to significant amounts of rectal dentistry.

It's not quite as seamless as in Go to be fair. But it does mean you can write Rust instead of Go.

And .NET

You can in fact also do it in C

I sure don’t. You nailed it.

They might be referring to *GPL libraries not allowing proprietary / permissive exes to static-link them. e.g. I think Qt requires its DLLs to be separate on disk as part of the LGPL, unless you buy the commercial license.

GIMP definitely suffers from programmer UI design, but Photoshop isn't much better. Menus nested in menus nested in dialogue boxes, keyboard shortcuts that conflict with every other shortcut on any system still in use today, and of course the assumption that everyone already knows what every button does. It's not quite Blender levels of unintuitive, but there's a reason people take courses just to use the damn program. If it weren't for the branding popularity and the fact Photoshop was one of the first programs of its kind, I don't think it'd ever gain popularity with that terrible kludge of a UI, and that's without the ridiculous price.

Ever since GIMP docked toolbars and windows by default (which also took a few versions in Photoshop) I don't think the interface is that bad anymore, at least not compared to Photoshop.

Photoshop had a pretty steep learning curve. "Users" had to spend some time getting to know the workflow.

GIMP also has a steep learning curve. But these same "users" turn their noses at spending some time getting to know the workflow.

As someone who is proficient in both, it is not hard to hit similar levels of productivity with GIMP as it is in Photoshop.

I hate this attitude that people have with open source being "user hostile". Stop acting like spoiled children. Why must the software always come to you? Why cant you come to the software?

Last time I checked ( a few months back) there was a little package of configurations + plugins / skins that were geared towards tweaking GIMP to be more accessible to people who were familiar with Photoshop -

And it wasn’t perfect, but give credit where credit is due, it was better than it’s ever been, it definitely got me close enough to complete a little photo collage project.

People say it because it's true for them. User experience is after all highly subjective. I think that the open-source world largely ignores this fact and pretends that if any one person says "good enough for me" then it's done.

As someone who has used a bunch of different image editing tools to make stuff (mainly for games, though i'm not an artist - i just need to make art :-P), Krita is fine. It has a bunch of weirdnesses (e.g. 2983942 commands to paste an image and all of them are kinda weird or missing in some way) and doesn't have as much features as GIMP but overall it is fine. Then again i found GIMP fine for a long time.

Though my favorite UX (and features) of all time is Paint Shop Pro 7 which i find superior to Krita (i have it installed alongside Krita, GIMP and Kolourpaint -used for minor edits since it starts instantly- on my Linux setup via Wine). I used it since Win3.x days in the 90s until PSP8 was released and they screwed up the UI. I moved to GIMP some time later when i started using Linux and used that for years. Some years ago i found a boxed copy of PSP7 anniversary edition, reinstalled it and despite not using it for more than a decade i found it much easier than GIMP and i'm using that since, until i wanted to make a plugin to assist me with texture painting for 3D models. Making plugins for PSP7 was very cumbersome so i thought to try Krita instead (Krita has an MDI mode which i like when working with images) and ended up sticking with it since making the plugin was relatively easy[0].

I'll download Krita's source code and try to build it and add the features i miss from PSP7 at some point, KDE people do not seem very allergic to having options so i might be able to recreate the stuff and behavior i miss from PSP7 in Krita.

In order of preference:

1. PSP7

2. Krita

3. Pixelmator (only under macOS of course and i only used an old version before App Store with the only alternative being GIMP running under XQuartz - i think GIMP got a native version later but i never used it)

4. GIMP (i found older versions easier to use, but every time they introduce a new major UI change i find it more awkward than before and now they're switching away from Gtk2 to Gtk3 -which i dislike the feel of- i decided to stick with Krita)

5?. Photoshop, maybe (i only used it a little in the past, always found it more cumbersome than GIMP or PSP, but it'll do if nothing else is available)

[0] http://runtimeterror.com/tools/kritaview3d/