GIMP PyDev | Hacker News Reader

GIMP PyDev

github.com

93 pointsapp4soft31 comments

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.

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.

[1] https://processing.org/

openSCAD perhaps?

Qgis and Grass, and the whole suit of geospatial open source tools. https://qgis.org/en/site/ for more

If you have several hundred, just start and figure out what tooling you need for your specific needs.

Automation comes later. It comes with experience.

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.

Interactively scripting Blender in python is a joy in comparison to a lot of other environments.

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 think one of the versions of processing would be ideal for this.

I see flatpack mentioned in a readme, I close the page.

Why?

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.

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!

https://glimpse-editor.org/

I was not familiar with Glimpse. Thanks.

Are there technical between the projects differences or simply the names?

I believe it is mostly a direct fork that maintains the name differences throughout the GUI, but I’m not totally sure!

This PC speech is BS. Who qualified you to speak on behalf of everyone else? GIMP stands for GNU Image Manipulation Program.

> 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.

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 always supported their Scheme dialect.

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.

https://wiki.gimp.org/wiki/Hacking:Plugins#GIMP_Plug-in_Arch...

Thanks, that makes sense of course and I'm pretty sure me[-20 years] knew this but it has since been flushed out of the poor brain tissue.

Gimp has had python plugins for more than 20 years, so it probably hasn't changed since you worked with them before: https://www.gimp.org/docs/python/index.html

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.

Sorry, but what prevents a different approach on each platform?

It's fairly common to ship Windows applications with bundled DLLs but to link to more system libraries on Linux platforms, for instance.

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.

In what way is not in the developers' best interest?

They are volunteers.

Reply on news.ycombinator.com