Using GIMP in the textile industry

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Using GIMP in the textile industry

Simon Budig
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

--
              [hidden email]              http://simon.budig.de/
_______________________________________________
gimp-developer-list mailing list
List address:    [hidden email]
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list
Reply | Threaded
Open this post in threaded view
|

Re: GIMP in the textile industry: handling of indexed colors

Simon Budig
Hi all.

Please see my previous mail for more context of this problem.

So here we go about the handling of colors in indexed images:

In the current toolchain for the carpets the images are indexed, i.e.
instead of RGB data per pixel each pixel stores an index into a color
palette.

At the company it is important to have good tools to manipulate color
palettes and I think there definitely is room in GIMP for a plugin that
provides advanced control over the colors contained in a project
specific palette as well as tools to control names and order of the
color entries.

In GIMP color palettes are available and they also can carry names. But
while you can use these palettes to create indexed images, the indexed
image itself carries a "colormap" which does not provide named colors.
It would be necessary to extend the core to store names associated to
the indexed colors. A small sideproject then is to make sure that these
color names also end up in the final resulting image, one thought there
was to define and write a specific text chunk into a PNG file that
provides advanced information about the palette.

I personally think that this would be a welcome addtition to GIMP. It
also is a project that is not too huge and might be beneficial to other
usecases as well.

I'd welcome input on that topic.

Bye,
         Simon
--
              [hidden email]              http://simon.budig.de/
_______________________________________________
gimp-developer-list mailing list
List address:    [hidden email]
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list
Reply | Threaded
Open this post in threaded view
|

Re: Using GIMP in the textile industry

Simon Budig
In reply to this post by Simon Budig
Hi all.

Please see my previous mail for more context of this problem.

We also discussed some changes to the UI:

The company representative I was talking to was also concerned about the
amount of functionality in the GIMPs UI and fears that it might be
overwhelming to the operators, plus that it also makes it easy to use
functionality that actually is harmful to the task at hand. I explained
that it is possible to reduce the amount of stuff shown on screen
(including making specific tools invisible, possibly even changing XML
files to reduce the number of menu entries), but also mentioned that
we're not too keen on having that, since it possibly increases the
support ballast for our community. It remains to be evaluated how much
changes are actually needed there.

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

Not sure how much consensus we have on this point and what amount of
effort is needed here.

Another thing related to the UI was to have a dockable, which would
contain a configurable set of buttons referring to specific actions (as
in "menu items"). That might be a handy thing for quickly acessing
frequently used functionality.

Another thing was a histogram for indexed images: Obviously counting the
indexed colors is important to calcuate the amount of color needed for
the carpet. The current histogram dockable could be extended with a more
tabular view for indexed images.

I'd welcome input on that topic.

Bye,
         Simon

--
              [hidden email]              http://simon.budig.de/
_______________________________________________
gimp-developer-list mailing list
List address:    [hidden email]
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list
Reply | Threaded
Open this post in threaded view
|

Re: Using GIMP in the textile industry

Simon Budig
In reply to this post by Simon Budig
Hi all.

Please see my previous mail for more context of this problem.

In the textile industry working with patterns is hugely important:

One quite important aspect of designing carpets is dealing with
patterns. The kind of projects we're talking about here is of the scale
"print carpet for a whole building, adhering to a common design across
the building".

So the layout of the building is known and the area of the floors gets
"sliced up" in advance so that it is known, which part of the room will
be filled with what part of the carpet run. It is vital that the
patterning of the carpet will seamlessly match when the carpet runs are
finally placed in the building.

In GIMP the fill tool provides no control over how a pattern is placed
in the selection to be filled, which in this context obviously is a huge
problem. I imagine it should be feasible to provide on canvas controls
for the fill tool, allowing to move a pattern around and to finetune how
a pattern is placed inside the selection.

I also saw other workflows where they worked with patterns dragged onto
the canvas and subsequently being expanded onto the image by dragging on
the pattern bounding box. The pattern in this case would be "locked"
into a specific position. One application is to place a pattern for a
trim on the carpet and then expand it in a repeating manner across one
side of the carpet.
I am not sure if this is a feasible thing for GIMP.

I'd welcome input on that topic.

Bye,
         Simon

--
              [hidden email]              http://simon.budig.de/
_______________________________________________
gimp-developer-list mailing list
List address:    [hidden email]
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list
Reply | Threaded
Open this post in threaded view
|

Re: Using GIMP in the textile industry

Simon Budig
In reply to this post by Simon Budig
Hi all.

Please see my previous mail for more context of this problem.

Working with indexed images:

I witnessed one very funky way of working with indexed images and I am
not sure if I have fully wrapped my head around the ways they use some
features of the proprietary tool they're using now.

The tool in question does not provide multiple layers, but it does have
some sort of floating selection. It however has funky means of dealing
with indexed images. For each entry in the color palette you can
  a) set the resp. color to transparency  and
  b) protect specific colors

I've seen these features used in various workflows:

* If you want to extend a patterned area you'd drag the pattern onto the
canvas and roughly align it to an already patterned area. You'd then
swich some colors to transparency, making it easier to align the
patterns in a pixel exact manner. To actually do the expansion of the
patterns you'd then make the colors visible again and drag on the
bounding box of the pattern to extend it into the desired areas. That
way it is ensured that the alignment of the new area fits the old area
pixel perfectly.

* if you want to combine a decor element of a pattern over a different
pattern (with the same repeating properties) you can place the new
pattern on top of the old one, then protect certain colors of the old
pattern and expand the area of the new pattern by dragging on the
bounding box. This basically places the new pattern "behind" certain
areas (as defined by the protected colors) of the old pattern. This also
can be used in conjunction with swiching some colors of the new pattern
to transparent, making parts of the new pattern invisible.

As I said, I was kind of swamped by the speed the operator toggled the
properties of the different indexed colors and it was hard to judge what
she actually was trying to do.

I kind of suspect that it is worth evaluating if there are more
straightforward ways to arrive at the same goal of the workflow, but
right now I do not have specific ideas there. That having said: being
able to "protect" some indexed colors (in a similiar way to a protected
alpha channel maybe?) as well as temporarily making some indexed colors
invisible/transparent might be helpful to other pixel based artists as
well. Opinions?

An interesting side problem is: If we had patterns with indexed colors
and would want to use them in an indexed image - how could we go about
mapping the two palettes to each other?

I'd welcome input on that topic.

Bye,
         Simon

--
              [hidden email]              http://simon.budig.de/
_______________________________________________
gimp-developer-list mailing list
List address:    [hidden email]
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list
Reply | Threaded
Open this post in threaded view
|

Re: Using GIMP in the textile industry: Document Management

Simon Budig
In reply to this post by Simon Budig
Hi all.

Please see my previous mail for more context of this problem.

Integration into a Document Management System

It will be necessary to incorporate GIMP into a site specific Document
Management System. I kind of suspect that this will end up being either
a separate plugin to access the files within the DMS. As of now I am
unsure what is needed there exactly and if it maybe is feasible to
develop something a bit more flexible, allowing for an integration into
different DMS backends. This very well might end up in a customer
specific plugin. If someone more familiar with DMS's than me has any
input on that I'd be glad.

I'd welcome input on that topic.

Bye,
         Simon

--
              [hidden email]              http://simon.budig.de/
_______________________________________________
gimp-developer-list mailing list
List address:    [hidden email]
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list
Reply | Threaded
Open this post in threaded view
|

Re: Using GIMP in the textile industry

Developers mailing list
In reply to this post by Simon Budig
Simon Budig <[hidden email]> 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
>
> --
>               [hidden email]              http://simon.budig.de/
> _______________________________________________
> gimp-developer-list mailing list
> List address:    [hidden email]
> 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:    [hidden email]
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list
Reply | Threaded
Open this post in threaded view
|

Re: Using GIMP in the textile industry

Developers mailing 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
 ><-

On Tue, 28 May 2019 at 08:41, Sven Görsmann via gimp-developer-list <
[hidden email]> wrote:

> Simon Budig <[hidden email]> 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
> >
> > --
> >               [hidden email]              http://simon.budig.de/
> > _______________________________________________
> > gimp-developer-list mailing list
> > List address:    [hidden email]
> > 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:    [hidden email]
> 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:    [hidden email]
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list
Reply | Threaded
Open this post in threaded view
|

Re: Using GIMP in the textile industry

Tobias Ellinghaus
In reply to this post by Simon Budig
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

_______________________________________________
gimp-developer-list mailing list
List address:    [hidden email]
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Gimp-gui] Using GIMP in the textile industry

Jehan
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
> [hidden email]
> 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
_______________________________________________
gimp-developer-list mailing list
List address:    [hidden email]
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list