This approach of using the system python, although somewhat mitigated by flatpak, is Bad. What happens when you have to ship GIMP on non-flatpak platforms, like MacOS...? You're either stuck on an ancient version or you must ask the user to install it separately. Neither option is particularly good.
It shouldn't be too hard to pack up a python executable instead.
I don't even understand what the standalone Python interpreter is used for; for plug-ins wouldn't you expect the hosting application to integrate the interpreter? That's at least my "traditional" view of how application plug-ins work.
On the other hand it's 20 years since I last worked with GIMP plug-ins, and back then it was C all the way.
GIMP plugins run in a separate process from the main process. My guess is that the main motivation is resiliency, to prevent crashes in buggy plugins from taking down the whole program. The plugin is essentially a standalone program that loads a library to help it talk to the parent process, in the case of both C and Python, so there isn't a real need to embed the Python interpreter in another process like you would with a more "traditional" Python plugin architecture.
QGIS on Linux does this as well, and it's really quite annoying. On Windows nobody assumes you'll have python installed, so everybody ships their own python. Sure I probably have at least 6 pythons installed on my machine, but at least I know that I can safely upgrade or install a package in one python without it risking breaking 6 other applications.
I think part of that has to do with it being a pythonic choice as well though. Python actively encourages you to segment off your environment for everything you do, that mentality continues to packaging and deploying.
Gimp's use of Flatpack has greatly simplified staying up to date for Linux users.
The Gimp community is not obligated to dedicate resources to working around Apple's business decisions. The absence of Flatpack on MacOS is solely for the sake of Apple's bottom line.
Apple itself certainly has the wherewithal to make Gimp available on its platforms. It simply does not have the interest. As you say, it shouldn't be too hard.
That’s as unreasonable as expecting every OS under the sun should ship apt-get, and it’s really not what this is about. I’m not criticising GIMP’s adoption of flatpak, I’m pointing out that building its essential infrastructure around a specific deployment scenario is probably not in GIMP’s best interest.
Because it's the equivalent of web developer abstraction creeping into the desktop. First it was electron, now containers. These people do t know how to architect, how to design, nor how to secure applications.
This is a bit off-topic here, but can anyone recommend some good programs / workflows for programmatic image generation / manipulation?
I have some geospatial boundary data that I'd like to extrude to a 3d object, apply textures to the faces, and save images of the object at different perspectives. I have several hundred to do, so it'd be ideal to automate this.
Something like Gimp PyDev or ImageMagick seem like they could sort of work, but the math around creating a 3D extrusion in either of those seems difficult. On the other hand something like Blender seems like kind of overkill maybe.
It might end up being one of those solutions, just curious if anyone has any other ideas.
You might want to look into Processing[1]. Depending on your needs it might feel more intuitive/appropriate for graphics programming, and there seems to be an active community of people who use it.
Not sure why you would think blender overkill for this. It seems perfectly suited to that, and can be scripted in python, albeit with mostly the same caveats as GIMP.
Are you converting topo maps to 3d printable objects?
There is software for this, if you can do a workflow with various pieces of desktop software, you could automate swaths of it and then do manual portions where you need to make specific decisions that can't be automated.
The geospatial boundary data, is it geojson or wkt? What does extrude mean specifically?
No 3D printing: just making stylized images of OSM administrative boundaries. "Extrude" being to give the 2D boundary a bit of height and make it look like more of an "object" than a line drawing.
I wrote a Gimp python plugin for my spouse; I was rather dismayed at how hard it was to learn what I needed to do, especially when what I wanted to do was relatively simple. But in the end, I got it working, and the second time wouldn't be so hard. I did have python distribution issues between my dev environment on Mac and the production environment on Windows.
I’ve found that technical types often don’t care about issues like this... but the name GIMP is imo an abelist slur and I really wish they would change it. Sadly the devs don’t seem to care, but there is a fork called Glimpse that aims to remedy this. If any of y’all care about removing discriminatory language from open source projects, please promote Glimpse!
> Who qualified you to speak on behalf of everyone else?
I am not speaking on anyone else's behalf. Disabled people have said they don't like language like this, so in order to be respectful I stop using it and encourage others to do the same.
> Disabled people have said they don't like language like this.
I haven’t read a single complaint from organizations focusing on disabilities. AAPD? The Arc? While I don’t agree with changing they acronym because the offensive doesn’t match the impact. Getting backing by a group of individuals is the way to go. [1] [2]
32 comments
[ 3.9 ms ] story [ 81.9 ms ] threadIt shouldn't be too hard to pack up a python executable instead.
On the other hand it's 20 years since I last worked with GIMP plug-ins, and back then it was C all the way.
https://wiki.gimp.org/wiki/Hacking:Plugins#GIMP_Plug-in_Arch...
It's fairly common to ship Windows applications with bundled DLLs but to link to more system libraries on Linux platforms, for instance.
The Gimp community is not obligated to dedicate resources to working around Apple's business decisions. The absence of Flatpack on MacOS is solely for the sake of Apple's bottom line.
Apple itself certainly has the wherewithal to make Gimp available on its platforms. It simply does not have the interest. As you say, it shouldn't be too hard.
They are volunteers.
I have some geospatial boundary data that I'd like to extrude to a 3d object, apply textures to the faces, and save images of the object at different perspectives. I have several hundred to do, so it'd be ideal to automate this.
Something like Gimp PyDev or ImageMagick seem like they could sort of work, but the math around creating a 3D extrusion in either of those seems difficult. On the other hand something like Blender seems like kind of overkill maybe.
It might end up being one of those solutions, just curious if anyone has any other ideas.
[1] https://processing.org/
Automation comes later. It comes with experience.
There is software for this, if you can do a workflow with various pieces of desktop software, you could automate swaths of it and then do manual portions where you need to make specific decisions that can't be automated.
The geospatial boundary data, is it geojson or wkt? What does extrude mean specifically?
https://glimpse-editor.org/
Are there technical between the projects differences or simply the names?
I am not speaking on anyone else's behalf. Disabled people have said they don't like language like this, so in order to be respectful I stop using it and encourage others to do the same.
> Disabled people have said they don't like language like this.
I haven’t read a single complaint from organizations focusing on disabilities. AAPD? The Arc? While I don’t agree with changing they acronym because the offensive doesn’t match the impact. Getting backing by a group of individuals is the way to go. [1] [2]
1. https://abc13.com/negrohead-lake-baytown-texas-naacp-name-ch...
2. https://en.m.wikipedia.org/wiki/Niggerhead