> "It followed a set of five rules to benefit the end user: no installers, no archives, no registry keys, no additional runtimes and a single executable file."
Reading this sentence made me feel warm and happy. I get why the registry exists and things work the way they do today around the Windows software ecosystem but... damn, I really miss the days when most desktop software was more like this. These days I try to use portable installs whenever they're available, I just wish it was more common. The time, inconvenience and uncertainty I'll be able to fully restore all my preferences makes me actively avoid reinstalling Windows.
There are lots of useful actions an installer does that (some, if not most) end users actually want, including but not limited to adding shortcuts to start menu so you can find it or search for it, associating file formats, registering to Windows' program list, etc.
I was a big fan of "portable" software, but nowadays if a software offers both ways, I actually prefer using installer. Otherwise I have to manually add them to Start Menu to be able to search for it, to begin with.
I do hate registry keys, simply for the fact they are often lost after reinstalling the OS. Please just keep all the settings in %appdata%!
I’m really fond of the way macOS does this, which is to stick this information in the executable.
Back in the day, this worked via a flag in the metadata for each file. When you got a new executable, the flag was unset. The OS would see a file with an unset flag, ask “Is this an executable? What files can it open?” and then add this information to a database called the desktop database.
This is why file associations work on a Mac without an installer, and without writing any code (you just have to write the code for “open file in response to OS request”).
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.
This is just not true, and hasn't been for decades. Many, if not most applications create subdirectories and store stuff in the Library/Application Support directories. Trashing the app bundle leaves all that stuff behind.
> 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.
First thing I used to install on macOS was Binaryage's superb asepsis utility, which intercepts the creation of .ds_store files and redirects them all to a local container folder, until SIP killed its development.
It always seemed suspicious to me that Apple, a company that is famously obsessed with UI/UX, would settle on such a ridiculous process for storing file metadata.
Not to be too annoying, but that file is how it supports the feature on non-posix-compliant file systems (usually FAT). On filesystems that support file-streams (or the original HFS), that metadata is stored on the file itself
Considering how pushy Apple normally are when it comes to forcing their customers to use new things so they can obselete old ones, I am very surprised where Apple have drawn the line in supporting older systems.
Windows does the same thing with 'Thumbs.db' files. They're just hidden from you on Windows systems, just as .DS_Store files are hidden on Unix-like systems; but you'll see them if you use a thumb drive with both types of machines.
So why are the smb shares on my linux file servers full of millions .ds_store files but zero thumbs.db files? I have to run automated scripts to remove them regularly, and try to run the commands on the macs to stop them writing ds_store files to network shares [0]. But still it seems to magically reenable itself every now and then. This is a problem I have never had with windows machines and 'thumbs.db' files.
Because Apple thinks nothing of spewing these turds all over every machine and directory you visit from a Mac, which is not just a dick move but also technically incompetent.
The next Mac visitor who comes along will overwrite the turd with his own, so that's a blunder.
Then there's the fact that they could have stored all the turds on the local machine, keyed by URI or path or network address. This would solve both the dickishness and the overwriting problem. And if a remote machine's path or address changed, whoop dee doo... you lost your Finder layout for that directory. Pretty low stakes.
I didn't think newer versions of Windows generated Thumbs.db either (well I think they do, but in some centralised location I thought rather than in every single individual directory).
Same thing as what? Same thing as having an installer modify HKEY_LOCAL_MACHINE\Software\Classes, and having the associations break if you move the program to a thumb drive?
If only everyone actually kept up with Windows development best practices, including Microsoft teams themselves[0].
Configuration via XML files, AppData, registry free COM activation, MSI installers, only to quote a few examples, are decades old by now, at very least since Windows XP.
[0] - To be fair, nowadays many young employees seem to only ever used Windows after joining Microsoft, so what else can we expect, if apparently they don't get the right mentoring.
I'd never heard of AppData until a few years ago when I went hunting for where some game config file was getting written to.
Seemed like a bunch of disparate things with the most common probably being a dumping ground for programming language library caches (Maven and NuGet and maybe another couple).
By backing up everything in important-looking folders (including My Documents, My Games, the Minecraft installation folder), and overlooking AppData as it is 99% download caches, tempfiles, and other garbage.
That should be covered by the part about "best practices".
That said, I keep finding more AppData files in my Documents folders than the other way around. Linux software (especially legacy software that doesn't respect the XDG spec) is the worst for that, somehow spreading files and directories across my user profile directory and my documents directory.
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.
Why would it have to let the user know via an obtrusive splash or anything? Could just be a very simple unobtrusive option on app launch or a menu item.
Same goes for post install - not too hard to arrange to auto delete the old copy.
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 suspect there were a few games like this, but I think the most popular one was called Drug Wars, in case anyone cares to go looking.
Yes, it was very poorly programmed. It always surprised me how popular it was. I think it was kind of a middle- to high-school meme game. I think the main popularity was that A) it was edgy, and B) kids could run it in school computers.
If I want to use a program once, I’ll just use a portable version. And I’ll be angry if it decides to add itself to the context menu of all Explorer files.
But I agree, for things I use more often, installers are the way to go, and I am not a fan of projects that just give you a zip and ask you to figure out where to put it.
After using Microsoft Intune I will never again complain about installers. At least installers mostly work, and when they don't you can run them again.
That is one of the reasons I like GO language. Single executable, which makes tooling easier for others to use. My alternative method is using single executable packaged with NSIS that extracts everything to a temp directory before running.
Sorry, Window Registry is a cornucopia of inconsistency and poor design. Gnome's Registry is well designed, comparatively. Key descriptions, value options with limitations and which is the default is a quality User Interface design. Just look at the Windows group policy to registry mappings, they are all over the place for the same logic layout with double negatives for keys.
Yeah, that's why Go is a solid win - single binary, no installer headaches, just build and run. Rust's powerful but comes with build complexity and dependency juggling. Go keeps it clean, fast, and dead simple to deploy.
I've built .exes for Windows just fine on Linux. I don't know about Apple stuff, though, I don't think there's any built-in Linux tooling to submit an executable for Apple's signature scheme.
The original purpose of the registry was to tell COM where to look for a DLL file given a GUID. Then COM could create instances of objects.
You still see that in there with HKEY_CLASSES_ROOT.
You can technically create objects without the registry, if you load up the DLL, then call the exported functions to create a Factory object, then use the factory object to create instances. It's what COM itself does.
That simplicity and lightness of design also resonated with me.
By the way, really cool read-off. The only thing I missed though was a deeper discussion of some of the challenges that the author alludes to in the beginning. But that’s just me being pedantic, the post is really nice and actually seems to be quite an impressive work.
AppImages still leave traces in your home directory. If you're luck it's just a dot file or folder that can easily be deleted but I've seen some that pollute a lot more.
I’m not sure what the best path forward is for making single-binary apps without static-compiling in of the libraries. Licensing usually makes that untenable.
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.
Please don’t spread misinformation, there’s a HUGE difference between GPL and LGPL, and you CAN statically link with LGPL you just must provide the object files to the user so they can re-link them with any version of Qt they want.
You could replace that year with any year since the start of the GIMP project and it would still be true. It's the epitome of an open source project run by people who care about technical features, not real world users.
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?
I think the biggest hurdle is that the shortcuts, ui, and workflows all feel different for the sake of being different. Why reinvent the wheel on it?
I also hate this idea that we aren't allowed to give feedback on open source software. I get it, it's an incredibly thankless thing to do, but feedback of "having to relearn all of this stuff is unpleasant" isn't a problematic thing
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.
Krita is very functional as a digial painting program. But I think the dev team took the "painting" part of digital painting too literal. They clearly spent a lot of time developing niche brush features (the only painting app has more detailed brush settings I know is Corel Painter), which is nice, but some other areas are neglected.
In comparison to Photosho, it's quite painful to add any text in Krita. The layer styles and filters are much less performant. But if you only do painting, Krita is totally fine.
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)
> But I didn’t promote it. A few months later, I landed a C++ job. So in the end all that effort paid off.
It's interesting how instinctively we know our hard work deserves to be paid off, but it's a shame how often open source developers put hard work into code that never really gets paid off, especially when it's widely used in production. I guess this explains why so often they look for reputation credits, or why NPM added the "maybe you should donate to the authors of these libs" feature, or why GitHub built in Patreon. There's got to be a better model than what we have now, that doesn't take advantage of naive but hard working young thinkers.
In my experience, when developing software the hard part is implementing the actual logic, not the UI.
In this case, replicating Photoshops UI seemed to be the hardest. Maybe using something like MFC, Qt, C++ Builder instead of straight Win API would have been easier.
I remember a long time ago when I was in high-school and tried to implement a paint program under DOS, that had windows using Borland C++ and BGI graphics library. How hard should it be to implement windows, buttons and dialogs, I thought? After all, with the power of OOP and C++, every problem is easy to solve, I thought.
I think most people will agree that ui is the hardest part for normal desktop software. Not getting any kind of ui going, but good ui. Consistency, how to group things, what goes where.
If your app needs two inputs and a button then this won't be so much of an issue, but I've wrestled with qt in the past for more complex layouts that I hate it with a passion.
There was a project called "pixel32" and later "Pixel Studio Pro" in the early 2000s. It looked really nice and was sold as early access. But became vaporware, people that paid became really pissed and the guy creating it turned from hero to villain quickly.
"Straight from my previous project named Fiew I added a massive image library viewer. It really could quickly and easily scroll through massive amounts of pictures."
Which is now infuriatingly lacking in the entire domain of image editors. Thumbnail browsers used to be an expected feature of image editors, even shareware ones. Now? Fat chance. Good luck even finding a stand-alone one.
Recently one called FlowVision surfaced for Mac, and it's pretty much the lightweight browser that many of us have been looking for for years. It has some rough spots, but the developer is responsive to issues. https://github.com/netdcy/FlowVision
Author of this article said he finished at Warsaw University of Technology - it was always considered to be one of the better ones here.
That being said, what also strikes me is how different the thesis were back in times. I did mine recently in another university of technology in some bigger city (without wanting to dox myself that much) and 90% of our engineering theses were of very subpar quality; mine included.
Is it any different nowadays? AFAIK the goal isn't to advance the field, but to prove to the people giving you the Bachelor/Master's degree that you're able to create a "paper". Some theses stand out, but most of them are probably quite boring.
It seems to me like their tasks were way heavier. For us, most of us did basic CRUDs with some implemention twist, and our papers were your standard: do a short theoretical introduction to the domain, make a few UML diagrams, explain how it works + some code examples, then testing.
I have used Photopea for so many of my projects. I make apps and I use it for every app icon and App Store screenshots I have built. Also used it to make memes. Not having to install it on my Mac and just easily accessing it from browser is immensely helpful.
Not complaining about downvotes but it seems a very odd thing for Hacker News to dislike. I would have imagined an internal story about a SW eng’s hack project would be interesting. Oh well.
I didn't downvote, but I fully understand if anyone would. Your comment shows some serious lack of understanding of the complexity of software like photoshop and the complexity of porting software. We may believe that's what your friend told you, but we have troubles believing he really did that. Maybe exaggerated (a lot)?
I assume by ported they mean compiled the C++ code to asm.js, now that as an Adobe employee they had access to the source code. Though this would still be a significant effort to get working.
It looks like you could have sold licenses to this or gone the startup route. Might have been slower and less glamorous than the gig you wound up getting, though.
The UX looks simple and reasonable. Frankly better than Gimp.
Only for people who think that things are good to the extent they "resemble Photoshop as much as possible." [direct quote] The Photoshop UI isn't ideal, it's fairly terrible (not as bad as Illustrator, but they're both just old), but people don't want to waste the huge effort it took to commit all of that to muscle memory.
Cloning Photoshop for a thesis is wild, though. From a comic book reader to most of Photoshop in one leap.
> "It followed a set of five rules to benefit the end user: no installers, no archives, no registry keys, no additional runtimes and a single executable file."
Reading this sentence made me feel warm and happy. I get why the registry exists and things work the way they do today around the Windows software ecosystem but... damn, I really miss the days when most desktop software was more like this. These days I try to use portable installs whenever they're available, I just wish it was more common. The time, inconvenience and uncertainty I'll be able to fully restore all my preferences makes me actively avoid reinstalling Windows.
There are lots of useful actions an installer does that (some, if not most) end users actually want, including but not limited to adding shortcuts to start menu so you can find it or search for it, associating file formats, registering to Windows' program list, etc.
I was a big fan of "portable" software, but nowadays if a software offers both ways, I actually prefer using installer. Otherwise I have to manually add them to Start Menu to be able to search for it, to begin with.
I do hate registry keys, simply for the fact they are often lost after reinstalling the OS. Please just keep all the settings in %appdata%!
I’m really fond of the way macOS does this, which is to stick this information in the executable.
Back in the day, this worked via a flag in the metadata for each file. When you got a new executable, the flag was unset. The OS would see a file with an unset flag, ask “Is this an executable? What files can it open?” and then add this information to a database called the desktop database.
This is why file associations work on a Mac without an installer, and without writing any code (you just have to write the code for “open file in response to OS request”).
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.
This is just not true, and hasn't been for decades. Many, if not most applications create subdirectories and store stuff in the Library/Application Support directories. Trashing the app bundle leaves all that stuff behind.
> 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.
First thing I used to install on macOS was Binaryage's superb asepsis utility, which intercepts the creation of .ds_store files and redirects them all to a local container folder, until SIP killed its development.
It always seemed suspicious to me that Apple, a company that is famously obsessed with UI/UX, would settle on such a ridiculous process for storing file metadata.
Not to be too annoying, but that file is how it supports the feature on non-posix-compliant file systems (usually FAT). On filesystems that support file-streams (or the original HFS), that metadata is stored on the file itself
You're thinking of resource forks. .DS_Store is stored as ".DS_Store" even on APFS.
Considering how pushy Apple normally are when it comes to forcing their customers to use new things so they can obselete old ones, I am very surprised where Apple have drawn the line in supporting older systems.
Windows does the same thing with 'Thumbs.db' files. They're just hidden from you on Windows systems, just as .DS_Store files are hidden on Unix-like systems; but you'll see them if you use a thumb drive with both types of machines.
So why are the smb shares on my linux file servers full of millions .ds_store files but zero thumbs.db files? I have to run automated scripts to remove them regularly, and try to run the commands on the macs to stop them writing ds_store files to network shares [0]. But still it seems to magically reenable itself every now and then. This is a problem I have never had with windows machines and 'thumbs.db' files.
[0] https://web.archive.org/web/20190714230437/https://support.a...
If I recall, Windows does not generate thumbs.db files, thus file icons-as-pictures, on any non-local device.
Because Apple thinks nothing of spewing these turds all over every machine and directory you visit from a Mac, which is not just a dick move but also technically incompetent.
The next Mac visitor who comes along will overwrite the turd with his own, so that's a blunder.
Then there's the fact that they could have stored all the turds on the local machine, keyed by URI or path or network address. This would solve both the dickishness and the overwriting problem. And if a remote machine's path or address changed, whoop dee doo... you lost your Finder layout for that directory. Pretty low stakes.
I didn't think newer versions of Windows generated Thumbs.db either (well I think they do, but in some centralised location I thought rather than in every single individual directory).
Relevant: “The Mac, Metadata, and you” (2001) https://arstechnica.com/gadgets/2001/08/metadata/
I mean…that’s just the same thing right?
Same thing as what? Same thing as having an installer modify HKEY_LOCAL_MACHINE\Software\Classes, and having the associations break if you move the program to a thumb drive?
If only everyone actually kept up with Windows development best practices, including Microsoft teams themselves[0].
Configuration via XML files, AppData, registry free COM activation, MSI installers, only to quote a few examples, are decades old by now, at very least since Windows XP.
[0] - To be fair, nowadays many young employees seem to only ever used Windows after joining Microsoft, so what else can we expect, if apparently they don't get the right mentoring.
I cannot stand AppData, specifically the way it's often used to store files that should be in Documents.
I'd never heard of AppData until a few years ago when I went hunting for where some game config file was getting written to.
Seemed like a bunch of disparate things with the most common probably being a dumping ground for programming language library caches (Maven and NuGet and maybe another couple).
I lost my kid's minecraft world because it stored everything under AppData/Local or some nonsense.
How did you lose it? That sounds super frustrating
By backing up everything in important-looking folders (including My Documents, My Games, the Minecraft installation folder), and overlooking AppData as it is 99% download caches, tempfiles, and other garbage.
That should be covered by the part about "best practices".
That said, I keep finding more AppData files in my Documents folders than the other way around. Linux software (especially legacy software that doesn't respect the XDG spec) is the worst for that, somehow spreading files and directories across my user profile directory and my documents directory.
It is not meant for that, rather blame the developers.
Is there a book or site documenting these best practices somewhere? I'm getting into windows dev and am curious about them.
https://learn.microsoft.com/windows/apps/get-started/best-pr...
What about a standalone executable that just offered the ability to install itself without having a dedicated separate installer?
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.
Why would it have to let the user know via an obtrusive splash or anything? Could just be a very simple unobtrusive option on app launch or a menu item.
Same goes for post install - not too hard to arrange to auto delete the old copy.
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 suspect there were a few games like this, but I think the most popular one was called Drug Wars, in case anyone cares to go looking.
Yes, it was very poorly programmed. It always surprised me how popular it was. I think it was kind of a middle- to high-school meme game. I think the main popularity was that A) it was edgy, and B) kids could run it in school computers.
If I want to use a program once, I’ll just use a portable version. And I’ll be angry if it decides to add itself to the context menu of all Explorer files.
But I agree, for things I use more often, installers are the way to go, and I am not a fan of projects that just give you a zip and ask you to figure out where to put it.
After using Microsoft Intune I will never again complain about installers. At least installers mostly work, and when they don't you can run them again.
That is one of the reasons I like GO language. Single executable, which makes tooling easier for others to use. My alternative method is using single executable packaged with NSIS that extracts everything to a temp directory before running.
Sorry, Window Registry is a cornucopia of inconsistency and poor design. Gnome's Registry is well designed, comparatively. Key descriptions, value options with limitations and which is the default is a quality User Interface design. Just look at the Windows group policy to registry mappings, they are all over the place for the same logic layout with double negatives for keys.
Yeah, that's why Go is a solid win - single binary, no installer headaches, just build and run. Rust's powerful but comes with build complexity and dependency juggling. Go keeps it clean, fast, and dead simple to deploy.
Obligatory comment saying you can do the same in Rust
I can’t target msvc or aarch-64-apple-* and compile a binary on Linux, without resorting to significant amounts of rectal dentistry.
I've built .exes for Windows just fine on Linux. I don't know about Apple stuff, though, I don't think there's any built-in Linux tooling to submit an executable for Apple's signature scheme.
Can’t you just replace the “cargo” command with “cross”
https://github.com/cross-rs/crossIt's not quite as seamless as in Go to be fair. But it does mean you can write Rust instead of Go.
You can in fact also do it in C
And .NET
The original purpose of the registry was to tell COM where to look for a DLL file given a GUID. Then COM could create instances of objects.
You still see that in there with HKEY_CLASSES_ROOT.
You can technically create objects without the registry, if you load up the DLL, then call the exported functions to create a Factory object, then use the factory object to create instances. It's what COM itself does.
That simplicity and lightness of design also resonated with me.
By the way, really cool read-off. The only thing I missed though was a deeper discussion of some of the challenges that the author alludes to in the beginning. But that’s just me being pedantic, the post is really nice and actually seems to be quite an impressive work.
> no installers, no archives, no registry keys, no additional runtimes and a single executable file.
This is exactly the experience nowadays with AppImages.
AppImages still leave traces in your home directory. If you're luck it's just a dot file or folder that can easily be deleted but I've seen some that pollute a lot more.
only works with hobby project with barebones feature
I’m not sure what the best path forward is for making single-binary apps without static-compiling in of the libraries. Licensing usually makes that untenable.
The license is one of many the tradeoffs you make when you choose whether or not to include third party libraries. You don't have to use them.
I sure don’t. You nailed it.
Pay for it, or open source your work (assuming you’re talking about QT).
The classic option is just a self extracting exe. I don’t really understand the fear of archives personally.
Which license forbids static linking?
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.
Please don’t spread misinformation, there’s a HUGE difference between GPL and LGPL, and you CAN statically link with LGPL you just must provide the object files to the user so they can re-link them with any version of Qt they want.
Photoshop has a million features though, a couple of image filters doesn't really count as recreating.
Nailing the UI though is both very difficult and very important.
In 2006, GIMP had a ton of features, but compared to Photoshop’s UI it was positively awful.
You could replace that year with any year since the start of the GIMP project and it would still be true. It's the epitome of an open source project run by people who care about technical features, not real world users.
Photoshop's UI is terrible as well (not defending GIMP). At least for digital painting.
- How to set 'C' key as to open color palette? Surprisingly, you can't do it in Photoshop.
- Photoshop is the only painting app that needs a completely new interface for liquifying, instead of just implementing it as a brush.
- Photoshop's 3D, vector path and animation feature are all abysmal. I guess it's to push you to buy other Adobe software.
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?
I think the biggest hurdle is that the shortcuts, ui, and workflows all feel different for the sake of being different. Why reinvent the wheel on it?
I also hate this idea that we aren't allowed to give feedback on open source software. I get it, it's an incredibly thankless thing to do, but feedback of "having to relearn all of this stuff is unpleasant" isn't a problematic thing
Gimp is an entirely different league of user hostile. There are intuitive GUIs, unintuitive GUIs, and then there is GIMP.
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 this, but I didnt have such issues using Gimp compared to PS. They are different, that's it.
The main thing I missed were stackable layers, but it was not a huge issue for me.
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.
What's your opinion on Krita?
(not the GP)
Krita is very functional as a digial painting program. But I think the dev team took the "painting" part of digital painting too literal. They clearly spent a lot of time developing niche brush features (the only painting app has more detailed brush settings I know is Corel Painter), which is nice, but some other areas are neglected.
In comparison to Photosho, it's quite painful to add any text in Krita. The layer styles and filters are much less performant. But if you only do painting, Krita is totally fine.
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/
Same as you... I don't use psp anymore because i'm on the lovely penguin for decades but psp was the finest paint i ever use, since, too, win3...
Exactly. I think Photopea is the closest replication attempt, but even it misses many features.
Still very, very impressive for undergraduate work.
I don't think we're meant to take "recreating" literally
If you say "I made basic image editor" it doesn't sound as impressive, of course. Not surprising given how it opens with:
>As I’m getting older I look back on all the things I’ve done as a creative developer, and I see so many cool projects!
Such modesty...
Let's get a direct link to this beauty in place:
https://github.com/f055/fedit-image-editor
> But I didn’t promote it. A few months later, I landed a C++ job. So in the end all that effort paid off.
It's interesting how instinctively we know our hard work deserves to be paid off, but it's a shame how often open source developers put hard work into code that never really gets paid off, especially when it's widely used in production. I guess this explains why so often they look for reputation credits, or why NPM added the "maybe you should donate to the authors of these libs" feature, or why GitHub built in Patreon. There's got to be a better model than what we have now, that doesn't take advantage of naive but hard working young thinkers.
In my experience, when developing software the hard part is implementing the actual logic, not the UI.
In this case, replicating Photoshops UI seemed to be the hardest. Maybe using something like MFC, Qt, C++ Builder instead of straight Win API would have been easier.
I remember a long time ago when I was in high-school and tried to implement a paint program under DOS, that had windows using Borland C++ and BGI graphics library. How hard should it be to implement windows, buttons and dialogs, I thought? After all, with the power of OOP and C++, every problem is easy to solve, I thought.
I think most people will agree that ui is the hardest part for normal desktop software. Not getting any kind of ui going, but good ui. Consistency, how to group things, what goes where.
If your app needs two inputs and a button then this won't be so much of an issue, but I've wrestled with qt in the past for more complex layouts that I hate it with a passion.
"How can network monitoring improve the reliability and cost-efficiency of telecom services
There was a project called "pixel32" and later "Pixel Studio Pro" in the early 2000s. It looked really nice and was sold as early access. But became vaporware, people that paid became really pissed and the guy creating it turned from hero to villain quickly.
https://discuss.haiku-os.org/t/pixel-studio-pro-in-past-call...
"Straight from my previous project named Fiew I added a massive image library viewer. It really could quickly and easily scroll through massive amounts of pictures."
Which is now infuriatingly lacking in the entire domain of image editors. Thumbnail browsers used to be an expected feature of image editors, even shareware ones. Now? Fat chance. Good luck even finding a stand-alone one.
Recently one called FlowVision surfaced for Mac, and it's pretty much the lightweight browser that many of us have been looking for for years. It has some rough spots, but the developer is responsive to issues. https://github.com/netdcy/FlowVision
The things people make and not tell the world about. Glad it’s on GitHub, this is so impressive.
Did it crash every 30 minutes?
If not, how much are you selling it for?
Author of this article said he finished at Warsaw University of Technology - it was always considered to be one of the better ones here.
That being said, what also strikes me is how different the thesis were back in times. I did mine recently in another university of technology in some bigger city (without wanting to dox myself that much) and 90% of our engineering theses were of very subpar quality; mine included.
Is it any different nowadays? AFAIK the goal isn't to advance the field, but to prove to the people giving you the Bachelor/Master's degree that you're able to create a "paper". Some theses stand out, but most of them are probably quite boring.
It seems to me like their tasks were way heavier. For us, most of us did basic CRUDs with some implemention twist, and our papers were your standard: do a short theoretical introduction to the domain, make a few UML diagrams, explain how it works + some code examples, then testing.
Check out https://photopea.com/
I use it daily.
bro who made it is a beast
Photopea is really nice. I was pleasantly surprise how many features they implemented to a free product. And even UI is not half bad. Kudos!
Yep. Have it as a desktop icon and use it like a native app.
The native keyboard shortcuts
I have used Photopea for so many of my projects. I make apps and I use it for every app icon and App Store screenshots I have built. Also used it to make memes. Not having to install it on my Mac and just easily accessing it from browser is immensely helpful.
Slick. Runs pretty well under Wine!
A friend from Phonegap got acquired by Adobe a decade ago and ported Photoshop to JavaScript for entertainment purposes immediately afterwards.
Not complaining about downvotes but it seems a very odd thing for Hacker News to dislike. I would have imagined an internal story about a SW eng’s hack project would be interesting. Oh well.
I didn't downvote, but I fully understand if anyone would. Your comment shows some serious lack of understanding of the complexity of software like photoshop and the complexity of porting software. We may believe that's what your friend told you, but we have troubles believing he really did that. Maybe exaggerated (a lot)?
I assume by ported they mean compiled the C++ code to asm.js, now that as an Adobe employee they had access to the source code. Though this would still be a significant effort to get working.
It looks like you could have sold licenses to this or gone the startup route. Might have been slower and less glamorous than the gig you wound up getting, though.
The UX looks simple and reasonable. Frankly better than Gimp.
Really cool work!
> It looks like you could have sold licenses to this
Doubt it. There are too many good free options on this level, e.g. Krita.
Today? Sure. Photopea blows any hobby project out of the water.
In the summer of 2006? This could've been a commercial product for sure.
Krita blows though. It looks and feels like a horse of an app. I'd pay for better UX.
> Frankly better than Gimp.
Only for people who think that things are good to the extent they "resemble Photoshop as much as possible." [direct quote] The Photoshop UI isn't ideal, it's fairly terrible (not as bad as Illustrator, but they're both just old), but people don't want to waste the huge effort it took to commit all of that to muscle memory.
Cloning Photoshop for a thesis is wild, though. From a comic book reader to most of Photoshop in one leap.