I started to write a simple but highly configurable image editor, to learn some C, GTK and shell scripting (I am a absolute beginner).
I think this program could be very interesting for people who want to make some simple image manipulations on there Linux Phone or who do not want to open Gimp every time they just want to change the dimensions of an image. Here is a video with the program on the L5 emulator
The idea is to have a GUI that displays an image and as many buttons and entries as the user wants. For every button and entry exists a shell script that does the image manipulation (I used ImageMagick in my scripts).
If there is not something similar already, I will publish the source code. Is GitLab a good website to publish the source code and should I use the GPL? Is there any interest in this project?
Nice job. If you add red-eye elimination, cropping, and lightening/darkening, a lot of people will use your app for editing their photos.
For the license, my suggestion is GPL 3.0+ if you donât expect anyone to reuse your code in larger projects or LGPL 3.0+ if you want people to reuse your code in larger projects.
I recommend strongly against the X+ licenses. If you allow the recipient to choose a later revision of a license, you depend on the license authority (FSF in this case) to not royally screw up some future version. You can always issue it under a dual GPL3/GPL4 at some point in the future if you like the V4, but going GPL3+ may well come back to bite you eventually.
The choice of the license depends on joedoeâs goals, so he will decide based on that.
All the changes that the FSF made in the GPL 3.0 looked very reasonable to me in order to protect usersâ right to share and modify the code. The FSF hasnât changed the GPL license since 2007, so I trust that the FSF will only change its license in the future when it sees some new industry practice (like Tivo) that arises to threaten the four freedoms.
Hereâs the short version of Torvaldâs thoughts on GPL2 vs GPL3:
âTo say that GPL version 3 is like GPL version 2, only better , is decidedly wrong as GPLv3 is very different from GPLv2.â â From a Q/A on GPLv3 in 2014.
Note that he isnât saying GPL3 is a bad license, just that it does not serve the same purpose as GPL v2, so calling it v3 is a misnomer. It is similar to the GPL vs LGPL divide. But even setting aside that the FSF changed the nature of the GPL from version 2 to version 3, if you open the door to all future versions, you rely on the FSF not changing its own nature at any point in the future. That is a gamble with what benefit? Saves you issuing a statement at some future date saying âall my software previously released under X license may, at the licenseeâs option, be licensed under the X+1 licenseâ. Meanwhile, if the FSF gets bought off, the V4 license could read âAll rights reserved, redistribution prohibitedâ and youâd be screwed.
The goal of the GPL was to protect the 4 freedoms. Every change that the FSF made in the GPL 3.0 was because industry came up with new practices to subvert the 4 freedoms in some way, so it was necessary to update the license. When you add the âor laterâ to the license, you have a way to prevent the next way that the industry attempts to subvert the 4 freedoms.
I trust the FSF to be a good steward of the license more than I trust the software industry, because history shows that it will think up ways to try to get around the license.
To be clear, the goal of the FSF in creating the GPL was to protect the end user freedom by encouraging use of a libre boilerplate license. The GPL is not a thing which can have a goal. This distinction matters, as the goals of the license authors may not perfectly align with the goals of the project authors choosing to use a license.
In the case of Linux, the goal in using the GPL2 is to get competitors who donât trust each other to collaborate on a project. The LF, and Torvalds, would prefer the drivers for some bit of hardware provided to the kernel, but the hardware device require signed kernel images, rather than have the hardware vendor use the BSD kernel. In neither case can the end user run unsigned kernel images. In the former case, someone can at least audit the kernel source to know what it is doing, or could even make a clone of the device without the signed firmware requirement.
As for trying to get around licenses⌠note that if you allow but donât require a recipient to re-license under a newer version, a nefarious recipient will choose whichever license best allows them to abuse the system. This means if they receive a GPL2+ source, and wish to TIVO it, theyâll just take it under the terms of the GPL2, and pass it along under the terms of the GPL2+. If you want to later force them to use 3+, you must still relicense the project, complete with rescinding old licenses where applicable.
True, but as more GPL 3.0-only software gets created, it gets harder to find enough GPL 2.0 software to create a complete system, so it becomes less likely that a company will pull a TIVO trick if wants to use a full Linux stack.
When I was a younger guy, and had what I thought was a great idea to do something, I always hated it when someone would spoil it with: âbut it already existsâ.
But here I go. Sorry. But it already exists.
I agree that GIMP is much too bloated for many jobs. But what about gthumb, photoflare, darktable, shotwell viewer, pinta, or photoxx, or showphoto, or at least take one of these and fork it and make it into what youâre looking for?
Also there is ImageMagic which has lots of solid support for image operations and types of formats. I read somewhere the most of the above suggested image programs actually use ImageMagic underneath do do the work.
@ OP - so far youâve encountered SUCH fierce opposition . if after all this you still make a more efficient image app SPECIFICALLY for the L5 then youâll be much better prepared to tackle more complex projects ⌠2D IS better
Of course, in the long run it would be best to have the existing projects run well on the L5. However, there may be a disproportionate amount of effort just to work with any of the upstream projects, compared to rolling your own. Especially if you can get away with some simple scripts and a small GUI wrapper.
Good pointer, and quoting from OP:
@johndoe, I think many useful things could be implemented your way (cropping may be tricky, though). So go ahead and see where it takes you. Whatever the outcome, you will learn something to unlock the next level.
In case you havenât seen it already, Purism have published blog posts about simple app development based on scripts. These may give a good starting point:
It is been some time since I posted here. But I had a lot of other things to do and I wanted to get familiar with the basics of git and deb packages, before I upload things on GitLab. The project is not finished and there are probably some bugs, but I think it is already usable, if the picture is not to big.