Simon Budig schrieb am Di., 28. Mai 2019 13:24:

Hi all.

Some of you will have noticed the Mail from Thomas Völker from the end of last February. He was looking for some Developers for paid Gimp development.

[putting on my business head]

I co-own and work for a small company doing embedded linux / customer specific application development.

After discussing this in the GIMP IRC channel I was ready to dip my toes into the somewhat murky water of doing paid development for my hobby pet project. So I went ahead and visited the company in question. It was a nice and productive meeting with interesting questions and I'd like to ask for your thoughts and input on the problems I'm about to explain. I'll split up this mail, so that different problems can be discussed in separate sub-threads.

If you're interested in doing paid development work on some of these problems please feel free to speak to me.

If you're interested in the problems, have input on working with printing in the textile industry please feel free to speak to me.

I am currently in Saarbrücken and would welcome discussions about these topics at LGM.

The Problem:

The Company is based in Germany and is manufacturing carpets, printing them with various customer specific designs.

Due to changes in their software toolchain (product upgrades with very unwelcome additional restrictions) they are looking for free alternatives and one part of a new toolchain could be GIMP.

During the two days of my (paid) visit there we tried to assess what features they need and looked for ways to fit GIMP into their needs.

I was very clear about that we need to be very careful about feature additions and how they fit into our future roadmap. That having said I really do believe that there are areas which would be useful for GIMP, other things are maybe a bit more tricky to incorporate in a sane manner into the GIMPs UI.

As for the background: the company in question manufactures long (dozends of meters) 4m wide runs of carpet, which then get printed on with customer specific designs in three different production lines. One of these lines uses a four color CMYK process, but the focus of this project are the two other lines using machines to print 24 and 32 individually mixed colors.

Since rooms wider than 4m are not uncommon site specific carpets need to get prepared in a way that multiple runs of carpet can be placed next to each other and the pattern globally match perfectly. This is one of the main concerns and I have the impression that the current tools in GIMP are not that great to deal with this kind of design constraints. Adressing these might expand our audience further into the realm of the textile industry, but I also believe that it might be helpful for people working with textures. To develop tools that make it more easy to work with this kind of constraints is probably the most tricky and questionable part of the project.

Lets first look at the in my opinion quite simple and uncontroversial things for the GIMP.

The two printing lines in question print with 24 resp. 32 customer specific colors. Each carpet project has its own color palette and while there is a predefined set of color recipes readily available it is not uncommon that specific projects get their own customer specific colors.

That is the basic situation. I'll send some follow up mails for the following sub-topics:

- Better handling of colors in indexed images - Changes to the UI
- Working with patterns
- Working with indexed images
- Integration into a Document Management System

Thanks! Simon

--
simon@budig.de http://simon.budig.de/ _______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership:
https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list

Having read things to this point, a first short remark on the feature you mentioned of allowing a pattern rotation/scaling before filling up an area:

That'd be great. I remember we used to have this as a feature request a long time ago
(10+ years), and it was dismissed at some point. That was well before we had
on-canvas controls.

But I think it would be great to have that for the fill tool, and maybe as a post-adjustment when
dragging the pattern directly to the image.

As for the various instances you mention of "expanding a selection containing a pattern",
the current way of doing this with GIMP would be to have initially a layer with a small (GIMP) selection on it, do the proofs there, then recreating a larger selection with the rectangle tool, and re-filling the pattern.

Another thing on the top of my mind is the current behavior for a pattern being used in a
palette-constrained GIMP image GIMP will transform the colors in the pattern to near colors
on the image - a behavior of replacing near-colors, and carefully add new colors could
be implemented with the current plug-in system.

Best regards, and a nice LGM for however is there!

js ><
gimp-developer-list@gnome.org> wrote:

Simon Budig schrieb am Di., 28. Mai 2019 13:24:

Hi all.

Some of you will have noticed the Mail from Thomas Völker from the end of last February. He was looking for some Developers for paid Gimp development.

[putting on my business head]

I co-own and work for a small company doing embedded linux / customer specific application development.

After discussing this in the GIMP IRC channel I was ready to dip my toes into the somewhat murky water of doing paid development for my hobby pet project. So I went ahead and visited the company in question. It was a nice and productive meeting with interesting questions and I'd like to ask for your thoughts and input on the problems I'm about to explain. I'll split up this mail, so that different problems can be discussed in separate sub-threads.

If you're interested in doing paid development work on some of these problems please feel free to speak to me.

If you're interested in the problems, have input on working with printing in the textile industry please feel free to speak to me.

I am currently in Saarbrücken and would welcome discussions about these topics at LGM.

The Problem:

The Company is based in Germany and is manufacturing carpets, printing them with various customer specific designs.

Due to changes in their software toolchain (product upgrades with very unwelcome additional restrictions) they are looking for free alternatives and one part of a new toolchain could be GIMP.

During the two days of my (paid) visit there we tried to assess what features they need and looked for ways to fit GIMP into their needs.

I was very clear about that we need to be very careful about feature additions and how they fit into our future roadmap. That having said I really do believe that there are areas which would be useful for GIMP, other things are maybe a bit more tricky to incorporate in a sane manner into the GIMPs UI.

As for the background: the company in question manufactures long (dozends of meters) 4m wide runs of carpet, which then get printed on with customer specific designs in three different production lines. One of these lines uses a four color CMYK process, but the focus of this project are the two other lines using machines to print 24 and 32 individually mixed colors.

Since rooms wider than 4m are not uncommon site specific carpets need to get prepared in a way that multiple runs of carpet can be placed next to each other and the pattern globally match perfectly. This is one of the main concerns and I have the impression that the current tools in GIMP are not that great to deal with this kind of design constraints. Adressing these might expand our audience further into the realm of the textile industry, but I also believe that it might be helpful for people working with textures. To develop tools that make it more easy to work with this kind of constraints is probably the most tricky and questionable part of the project.

Lets first look at the in my opinion quite simple and uncontroversial things for the GIMP.

The two printing lines in question print with 24 resp. 32 customer specific colors. Each carpet project has its own color palette and while there is a predefined set of color recipes readily available it is not uncommon that specific projects get their own customer specific colors.

That is the basic situation. I'll send some follow up mails for the following sub-topics:

- Better handling of colors in indexed images - Changes to the UI
- Working with patterns
- Working with indexed images
- Integration into a Document Management System

Thanks! Simon

--
simon@budig.de http://simon.budig.de/ _______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership:
https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list

_______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership:
https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list

Am Dienstag, 28. Mai 2019, 13:30:08 CEST schrieb Simon Budig:

[...]

One thing which came up though (and which we already have discussed in the past IIRC) is the need for a better support for multiple documents in single window mode. The software they're using currently is using a classic Windows Multiple Documents Interface (MDI) and they do in fact make use of it. I tried to explain why I personally consider GIMPs multiple window interface as quite good, but the not-so-great support for multiple desktops in windows (and the bad window management) made this a tough point to sell... :)

I see two options here and I think we've been discussing these in the past.
a) create multiple side-by-side image views within the single window mode. We could allow for tiling the image area into multiple notebooks, each containing its own set of images, allowing for Drag'n'Drop between them etc. ppp. My gut feeling is that this should be quite doable. It might be a bit tricky to control the keyboard focus there and to make it clear to the user, which of the images will be affected by the next keystroke.

b) (not necessary XOR) it might be feasible to allow for a kind of hybrid single/multiple window mode, where one can drag out notebook-tabs into their own image view that then is managed by the window manager. So we would have one dedicated main window containing the toolbox and the notebook-area with image views as well as separate windows containing image views (or a notebook of image views?).

What about this:

The tabs in single image mode are not just for one image each but contain "workspaces". By default an image is opened in a new workspace containing a single image, so it's the same we currently have. It would however be possible to split the image area to show more than one image or view. I somewhat like the quick and easy way that's done in blender, however, one would need to think about what to do when the last view of an image is closed. That way each tab could contain a arbitrarily complex setup of image views with the toolboxen staying the same for all of them. Having rip-off windows might be nice, but I personally don't feel the need, and having both a single image window mixed with some floating windows might be confusing.

I'm also CC'ing the gui list as that seems to be a better place for this part of the discussion.

[...]

Bye,
Simon

Tobias

On 2019-06-04 14:31, Tobias Ellinghaus wrote:

Am Dienstag, 28. Mai 2019, 13:30:08 CEST schrieb Simon Budig:

[...]

One thing which came up though (and which we already have discussed in the past IIRC) is the need for a better support for multiple documents in single window mode. The software they're using currently is using a classic Windows Multiple Documents Interface (MDI) and they do in fact make use of it. I tried to explain why I personally consider GIMPs multiple window interface as quite good, but the not-so-great support for multiple desktops in windows (and the bad window management) made this a tough point to sell... :)

I see two options here and I think we've been discussing these in the past.
a) create multiple side-by-side image views within the single window mode. We could allow for tiling the image area into multiple notebooks, each containing its own set of images, allowing for Drag'n'Drop between them etc. ppp. My gut feeling is that this should be quite doable. It might be a bit tricky to control the keyboard focus there and to make it clear to the user, which of the
images will be affected by the next keystroke.

b) (not necessary XOR) it might be feasible to allow for a kind of hybrid single/multiple window mode, where one can drag out notebook-tabs into their own image view that then is managed by the window
manager. So we would have one dedicated main window containing the
toolbox and the notebook-area with image views as well as separate
windows containing image views (or a notebook of image views?).

What about this:

The tabs in single image mode are not just for one image each but contain
"workspaces". By default an image is opened in a new workspace containing a
single image, so it's the same we currently have. It would however be possible
to split the image area to show more than one image or view. I somewhat like
the quick and easy way that's done in blender, however, one would need to
think about what to do when the last view of an image is closed. That way each
tab could contain a arbitrarily complex setup of image views with the toolboxen staying the same for all of them. Having rip-off windows might be
nice, but I personally don't feel the need, and having both a single image
window mixed with some floating windows might be confusing.

How we handle images in single window mode is anyway a real pain to me. Splitting a single tab to show several views of the same image or even different images is indeed a great idea. But also we should be able to detach image tabs (which is what you call rip-off windows, I guess?) into their own windows (same as we can detach dockables even when in single window mode). I personally don't believe this to be confusing. I mean detaching tabs is a common feature in many software (like web browsers!), and it allows to do much more than being limited by what the program will allow you. First of all, if you have several screens, you can leave some images on one screen (say your reference images) and others on another screen (the image(s) you are working on for instance). And more usage (you are then only limited by your window manager).

In other words, we should stop with the whole single vs multi window mode nonsense. We should simply have a single mode allowing all possibilities (attaching or detaching images, dockables, toolbox, etc.).

This is something which have been on my TODO-list for years, and I am never able to make the time to do this. I would support anyone wishing to work in such directions. :-)

I'm also CC'ing the gui list as that seems to be a better place for this part
of the discussion.

By the way, maybe you want to subscribe to the gui list. I had to manually approve this email. :-)

Jehan

[...]

Bye,
Simon

Tobias

_______________________________________________ gimp-gui-list mailing list
gimp-gui-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-gui-list

ZeMarmot open animation film
http://film.zemarmot.net
Liberapay: https://liberapay.com/ZeMarmot/
Patreon: https://patreon.com/zemarmot
Tipeee: https://www.tipeee.com/zemarmot