[HN Gopher] GIMP PyDev
       ___________________________________________________________________
        
       GIMP PyDev
        
       Author : app4soft
       Score  : 87 points
       Date   : 2021-03-26 08:07 UTC (14 hours ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | jonnycomputer wrote:
       | 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.
        
       | TaylorAlexander wrote:
       | 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/
        
         | brudgers wrote:
         | I was not familiar with Glimpse. Thanks.
         | 
         | Are there technical between the projects differences or simply
         | the names?
        
       | durkie wrote:
       | 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.
        
         | ris wrote:
         | Interactively scripting Blender in python is a joy in
         | comparison to a lot of other environments.
        
         | derekja wrote:
         | openSCAD perhaps?
        
         | MayeulC wrote:
         | 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.
        
         | brudgers wrote:
         | 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.
        
         | randoramax wrote:
         | Qgis and Grass, and the whole suit of geospatial open source
         | tools. https://qgis.org/en/site/ for more
        
         | uneekname wrote:
         | 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/
        
         | sitkack wrote:
         | 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?
        
       | tubularhells wrote:
       | I see flatpack mentioned in a readme, I close the page.
        
         | jackric wrote:
         | Why?
        
       | toyg wrote:
       | 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.
        
         | brudgers wrote:
         | 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.
        
         | unwind wrote:
         | 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.
        
           | resoluteteeth wrote:
           | 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
        
           | re wrote:
           | 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...
        
             | unwind wrote:
             | 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.
        
           | pjmlp wrote:
           | GIMP always supported their Scheme dialect.
        
         | nly wrote:
         | 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.
        
         | dagw wrote:
         | 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.
        
           | m-watson wrote:
           | 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.
        
       ___________________________________________________________________
       (page generated 2021-03-26 23:02 UTC)