As per title.
I just pulled the latest (587c260eff, Thu Nov 6 07:33:06 UTC), and its “About” still identifies it as a 3.1.5?
Also, there are still no ImageChooser and PathChooser widgets and the corresponding support in GimpUi.ProcedureDialog?
I just pulled the latest (587c260eff, Thu Nov 6 07:33:06 UTC), and its “About” still identifies it as a 3.1.5?
Hi. What you was expecting? This is exactly the version number of the commit: meson.build · 587c260effae7eff3d8acd80b41fc6f407d112a8 · GNOME / GIMP · GitLab
Also, there are still no ImageChooser and PathChooser widgets and the corresponding support in GimpUi.ProcedureDialog?
That was reported? If it is a regression from 2.10, tell me that I will put a milestone to e.g. 3.4
Hi. What you was expecting?
3.2, or 3.1.7 or whatever
That was reported? If it is a regression from 2.10, tell me that I will put a milestone to e.g. 3.4
Yes, at least for ImageChooser. I have asked numerous times already. See last one here. Or here.
The problem is that it is always bumped to the next milestone.
But how? 3.2 RC was not released. See: GIMP - Development Downloads
As long 3.2.0-RC(1) is released there will be no 3.1.7 but 3.2.0-RC2.
Yes, at least for ImageChooser. I have asked numerous times already. See last one here. Or here.
Hmm… The GL issue you linked is not labeled as bug on the API so indeed is unlikely to be implemented any time soon. All depends on the 2-3 C developers we have
Hi Bruno
Not being able to pick an image in a generated GUI plugin is a significant regression from 2.10 (for paths, IIRC, we had to use the path name as a string anyway)
COuld you be kind enough to change that to a bug and set the milestone to 3.2? -Even if we don’t have the resources to work on that, it should at least have the visibility it deserves.
Best regards
1 Like
Anyone is still welcome to make their own widgets to select paths by name or whatever other type of objects like this. All the API which existed in 2.10, as well as all GTK API, still exists and nobody blocks anyone else from using it in their plug-ins. Only the new easy API for fully generated plug-in dialogs was not created yet.
Saying there is a regression when making plug-ins and GUI for them in 3.0 is like 100 times easier, but just because some of the new easy API is not there yet for some specific types, I consider it a bad faith claim.
There is absolutely no regression here.
It’s not how things work. We are in the opposite process of de-milestoning various non critical reports (and just to answer in advance any comment on the word “critical”: no it’s not a critical issue; a critical issue is like a very ugly crash, or some complete breakage of some common feature, or basically anything judged critical by someone willing to work on it before release).
We are not just adding random reports to the 3.2 milestone now, unless this someone appears. Now I know for a fact (because someone asked about this on IRC) that this Discourse thread was enough to raise some awareness to it. So some new API might appear (or not) for 3.2. We’ll see. And if it does, only then the milestone will be set.
As @brunvonlope said, there are very few developers and said developers do what they can within the limits of their time and their life. We are not in the habit of putting pressure on contributors, so it’s not how the milestone system is used. And for the record: it won’t ever be used this way as long as I’m around and that I have a say in this. Filling milestones with random new features because someone somewhere considered it important to them has one and only consequence: giving us pressure, and sending contributors to depression therapies. Also I lied, it has a second consequence: it makes releases slower by delaying them forever because we are never able to finish it all.
GIMP is not perfect, it has a bunch of issues, more than just this one. And GIMP is a community before anything else. Everything just depends on the volunteers making things happen. We absolutely welcome reports, remarks and suggestions. But we don’t make deadline promises, we don’t pressure contributors, and we won’t jump through hoops.
This needed to be said. Thanks.
Hi Jehan -
Sorry for that.
I suggested putting an earluy milestone as I saw Bruno commenting about putting a 3.4 milestone in it - but I am for having the milestone open (as I know quite well as the development process takes place).
I apologize if it looks like I was putting pressure there - also I mistook this for not being able to select an image at all.
The big difference is that if these widgets exist, you don’t need to get involved in the UI, you use Gimp.ProcedureDialog and you’re done. Without them, you have to write write a whole UI and suddenly the size of the code is multiplied by two or three… The migration effort isn’t the same at all.
And it’s even worse for those who have script-fu code.
No prob. I know my message was with a bit of an annoyed undertone. But that’s also because I was indeed a bit annoyed 
! I know things are not perfect, and it never will… but we have to do with what we have. All what matters in the end if if someone does (and wants to do) the work. Milestones are used for organizational purpose, no to mirror reporters’ annoyances. 
Anyway no prob. It just needed to be said, but there is no bad feeling at all.
Sure. As I said, it’s an improvement of GIMP 3 (so not a regression), and it is true for most data types, though you are right that it’s not true for images and paths (where you could still do something with custom code, just like in 2.10; and yeah it means blowing up the size of the code!). I understand you’d also like to have this new API extended. So do I! I was annoyed by this exact same lack of support for image/path selection in our new API once or twice myself. No joke.
In the end, things come when they come and we just all have to be patient. The alternative to this is to implement it ourselves (I could of course! I just have other, more important, priorities), or even to hire a developer (this has been done in the past; some codes or bug fixes were implemented by hiring a developer; and for non-controversial features like this, there is no reason why it would be refused). Or else just be patient because contributors are volunteers otherwise.
Note that it may still happen for 3.2. A dev showed interest. But if it doesn’t, that’s life. 
In any case, I’m happy you appreciate this new GUI generation API. I put a lot of work and love in making it and am quite proud of the result. I do believe it improves a lot the experience of making GIMP plug-ins but never had much of a feedback about it.
Yes, it’s pretty cool. Not terribly pythonic (I understand it must work with about any language) but it can be pythonified. It is just that for some uses it looks a bit like this:
@Ofnuts @gwidion We put together a merge request for a GimpImage widget - widgets, pdb, libgimp: GimpProcedureDialog Image Widget (!2544) · Merge requests · GNOME / GIMP · GitLab
Feel free to try it out and let us know if it works as expected. I’ll try to get a GimpItemChooser built as well before 3.2.
1 Like
The one I miss most is the PathChooser. I have over a dozen scripts that depend on it.
Good news! @Jehan and I implemented an ItemChooser right before 3.2 RC1, so now you can select paths as well via the GUI. Feel free to try it out and let us know if there are issues.
Good. Will see what I can get from this.
1 Like