RSS/Atom feed Twitter
Site is read-only, email is disabled
  1. Chat
  2. Useful links
  3. Polls

Featured content

SPAM-LOW: floating selections and other annoyances

This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.

This is a read-only list on gimpusers.com so this discussion thread is read-only, too.

5 of 5 messages available
Toggle history

Please log in to manage your subscriptions.
floating selections and other annoyances Sven Neumann 27 Oct 22:05
  floating selections and other annoyances Øyvind Kolås 27 Oct 22:26
   floating selections and other annoyances Sven Neumann 27 Oct 23:44
  SPAM-LOW: floating selections and other annoyances Alastair M. Robinson 28 Oct 00:11
   SPAM-LOW: floating selections and other annoyances Sven Neumann 28 Oct 00:17
Sven Neumann
2007-10-27 22:05:55 UTC (about 18 years ago)

floating selections and other annoyances

Moin,

yet another list of tasks that we should IMO commit ourselves to:

Floating Selections -------------------
We should try to remove floating selections from the user interface. It should be possible to completely hide this implementation detail.

This needs a thorough analysis first. How exactly should all the case be handled where a floating selection is involved?

Alpha Channel -------------
Bug 486902 (http://bugzilla.gnome.org/show_bug.cgi?id=486902) makes an interesting suggestion on how to remove the burden of adding/removing alpha channels to layers.

This should be looked at and it might turn out to be relatively simple to implement.

Layer boundaries ----------------
It would be nice if layers would enlarge themselves when needed. It is annoying that the user has to care about this.

This should be looked at from a user perspective first. When we have figured out the details (like how to align a text layer if it doesn't have a border), we can look how to best implement it. GEGL supports sparse tiles, doesn't it?

Sven

Øyvind Kolås
2007-10-27 22:26:01 UTC (about 18 years ago)

floating selections and other annoyances

On 10/27/07, Sven Neumann wrote:

Layer boundaries
----------------
It would be nice if layers would enlarge themselves when needed. It is annoying that the user has to care about this.

This should be looked at from a user perspective first. When we have figured out the details (like how to align a text layer if it doesn't have a border), we can look how to best implement it. GEGL supports sparse tiles, doesn't it?

At the moment the GeglBuffer system is only catering to the immediate needs of rendering from
input buffers (what would be considered drawables in GIMP) that do not change size after they
have been initially constructed. Internally in the GeglBuffer itself this limitation is manifested by GEGL only keeping one (huge) buffer for each pixel format, and handing out pieces of this as buffers are constructed. This is something that is open for change, and I very much subscribe
to the idea that layer boundaries should be dealt with automatically.

Another part of GeglBuffer that is lacking in this regard is that it doesn't automatically replace a
fully erased tile with a clone of the blank tile of the buffer, similar optimizations could probably be applied for tiles that have completely uniform color.

/Øyvind K.

Sven Neumann
2007-10-27 23:44:29 UTC (about 18 years ago)

floating selections and other annoyances

Hi,

On Sat, 2007-10-27 at 21:26 +0100, Øyvind Kolås wrote:

Another part of GeglBuffer that is lacking in this regard is that it doesn't automatically replace a
fully erased tile with a clone of the blank tile of the buffer, similar optimizations could probably be applied for tiles that have completely uniform color.

That would indeed be very interesting for GIMP and I would very much welcome if someone could try to address this in GEGL soonish.

Perhaps we also need to make a list of GEGL tasks that we should publish together with the GIMP tasks list? This might attract some more developers to GEGL as well.

Sven

Alastair M. Robinson
2007-10-28 00:11:53 UTC (about 18 years ago)

SPAM-LOW: floating selections and other annoyances

Hi,

Sven Neumann wrote:

Floating Selections
-------------------
We should try to remove floating selections from the user interface. It should be possible to completely hide this implementation detail.

This needs a thorough analysis first. How exactly should all the case be handled where a floating selection is involved?

Unfortunately I have very little time to devote to coding currently, and haven't really been keeping up with the changes here. In 2.4 The user can no longer use a selection tool to "tear off" and float a selected region, am I right? If you want to select and move a region you now have to manually float with either ctrl-shift-L or do Ctrl-X, Ctrl-V, correct?

If floating selections are to be removed, how do you anticipate a user selecting a section of an image and moving it? By creating a proper layer from the selection?

Thanks, --
Alastair M. Robinson

Sven Neumann
2007-10-28 00:17:40 UTC (about 18 years ago)

SPAM-LOW: floating selections and other annoyances

Hi,

On Sat, 2007-10-27 at 23:11 +0100, Alastair M. Robinson wrote:

In 2.4 The user
can no longer use a selection tool to "tear off" and float a selected region, am I right? If you want to select and move a region you now have to manually float with either ctrl-shift-L or do Ctrl-X, Ctrl-V, correct?

Not quite. You can still float and move a selection using Crtl-Alt-Drag. Perhaps we need to make this easier again...

If floating selections are to be removed, how do you anticipate a user selecting a section of an image and moving it? By creating a proper layer from the selection?

I didn't suggest floating selections to be removed. They will be kept, but they will be kept as what they were supposed to be from the very beginning: an internal implementation detail that the user doesn't need to know about.

This change has not yet been laid out in all details, but it looks promising.

Sven