gmane.comp.video.gimp.devel

Re: [Gimp-developer] Merging visible paths via scripts

Ofnuts — 2012-05-24T22:52:25

Indeed, this is a piece of cake/SMOP in Python.


If the PBD emulates the current "manual" version  (all paths are 
replaced by a single, merged one) scripts will often have to copy the 
paths first, so we are back to square one :)

[Gimp-developer] application suggestions to evaluate tool options -input needed

foser — 2012-05-24T19:08:45

Hello,

as mentioned earlier a new UI design project has started under the
supervision of Kate and Peter with a focus on the Tool Options. The
current progress can be found on
http://gui.gimp.org/index.php/Work_in_progress .

For the next step we are looking to evaluate GIMP using the user
scenarios mentioned in the link above, the scenarios are firmly rooted
in the vision described. Besides evaluating GIMP we will also be
looking at a number of (similar) applications and their use of Tool
Options or equivalant UI elements.

Of course we have some applications in mind, but we would also like to
hear from you what applications you think of if you think about
working with tools and manipulating their options in a graphics
manipulation context. Name the application and a short description of
how it supports and/or interferes with your workflow.

We will use the suggestions here as a basis for the list of
applications to be evaluated in this design process.

I'm eager to find out what you all come up with.

Thanks,
foser

Re: [Gimp-developer] Merging visible paths via scripts

Gino D — 2012-05-24T18:47:28

I suspected this, now I have confirmation.


That's a good suggestion. Hence I think that for this purpose I will
try to operate with Python as soon as I have learned to handle this
language sufficiently.


I don't know if I really can. In fact, unless rules have changed
recently (can you confirm?), whenever in the past I have tried to open
any bugs of this type at Bugzilla Gnome, I was responded that wished
features are not real bugs but they must be submitted in this mailing
list instead.


At present I'm only skilled in scripting, but I hope one day to become
able to edit the source code too. If and when I succeed, I shall not
fail to contribute to this feature. Thanks for the proposal.

Re: [Gimp-developer] feature: Set exclusive layer visibility within groups

Richard Gitschlag — 2012-05-24T15:25:26

That is an unrelated question. As far as I know GIMP only allows one 'active' layer at a time because that is the surface that any drawing operations are applied to.

On further reflection I agree - if you Shift+click on a layer within a group it should toggle between all items visible and THAT LAYER (regardless of location within the overall layer tree) exclusively. If you want to do this for an entire layer group as a whole, you Shift+click on the layer group. Simple!

Besides, the behavior should be that your first Shift+clicking on a layer should hide all layers except that one, but I'm having difficulty figuring out the conceptual logic of making it unhide the parent layers (if any) one at a time -- too difficult to differentiate between that state and "all layers visible" state. After all, in the current behavior, if an image contains multiple layers but only some are visible, the first Shift+Click is to make only the selected layer visible. Only when the selected layer is the sole visible item does it restore visibility to all layers.

So a better loop that preserves the two-state "all items -> selected layer only -> all items" click chain, but also supports layers within groups, would look like:

1 - Note the full layer path from image root to the selected item (excluding the selected item). It does not matter whether the selected item is itself a layer or group. (Note that if we clicked a top-level item, the path will have only contain one entry: the image root itself.)
2 - Begin iterating through the path starting at the top-level of the layer tree.
3 - At each node in the path, retrieve a list of all child nodes (layers or groups) and note which one actually belongs to the selected path. IF that item is not visible, OR if any other (sibling) items are visible, THEN the action to take is "set exclusive visibility = true"; we can break from the loop and proceed directly to step 6.
4 - Repeat step 3 until we have reached the end of the path.
5 - If we do reach the end of the path, this means the selected item is the only thing visible in the entire image (whether or not it is a group containing visible sublayers is irrelevant), and the action to take is "set exclusive visibility = false".
6 - Now that we've determined what action we are performing, iterate through the path a second time and apply visibility accordingly. If the child of a node belongs to the selected path, its visibility becomes true. Otherwise, it is only a sibling to such a node and its visibility becomes FALSE (show selected item only) or TRUE (show all items).

Also, as you hinted above a way to toggle exclusive visibility with respect to the current item's group WITHOUT evaluating or affecting other layers higher up in the layer tree can also be useful. Maybe a Shift+Alt or Shift+Ctrl modifier for this purpose. The same logic above applies, except that instead of iterating the fullpath from top level to selected item, we'd be evaluating a partial path using the item's parent group only.

Re: [Gimp-developer] Merging visible paths via scripts

Joao S. O. Bueno — 2012-05-24T14:05:59

Indeed - there are no vectors merging calls whatsoever on the PDB -
for the time being, the only way to merge vectors using a script or plug-on is
to explictly adding strokes read from other vectors to another vector.
(using gimp-vectors-stroke-new-from-points ).

Coding an algorithm that loops through an image vectors, cehck which
are visible, and for each visible vectors object, read its strokes,
and add them to the target vectors is the way to go. Other, higher
level languages, can make this task easier than in scheme - like
Python.

On the other hand, indeed, there should be some support for that on
the PDB - could you open a bug at https://bugzilla.gnome.org/ asking
for this feature?
Maybe you could even come to do some work on its developement on a
nearby future, in order for it to be in gimp 2.10.

  js
 -><-

[Gimp-developer] Merging visible paths via scripts

Gino D — 2012-05-24T10:37:37

Hi.

I'm searching for the Script-Fu procedure corresponding to the "Merge
Visible Paths" widget available in the "Path" context menu, but so far
I have been able neither to find it nor to devise a way to do the same
by using other procedures.

Have I missed something? Or the reason is that the Procedure Database
doesn't currently provide this unique command yet?
If so, is there anyone who can suggest or at least draft me a code
snippet aimed to implement the aforesaid operation?

Thanks in advance.

Re: [Gimp-developer] Poor Display-Performance of Gimp 2.8 on Windows

Claus (Gimp-Devel-List — 2012-05-23T16:33:10

I'd love to hear, what Michael Schumacher says on this topic. If he thinks its helpfull, I will file a bug report.
_______________________________________________
gimp-developer-list mailing list
gimp-developer-list< at >gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] feature: Set exclusive layer visibility within groups

gfxuser — 2012-05-23T16:04:49

You're right.

I'm also missing two other possibilities in changing layers' visibility:
1) Only one layer can be selected at one time. It can be useful to make 
just a few layers visible while hiding the others. Could it be made 
possible to multiselect layers?
2) Shift-clicking on a layers visibility icon toggles between the state 
of 'exclusive visibility' and the state 'all layers are visible', no 
matter whether all layers were visible before.
An example:
Layer L1 visible, L2 hidden, L3 hidden, L4 visible. Make L2 visible 
exclusively, shift-click on L2's eye again -> L1 to L4 will become 
visible, including L3 which was hidden before. It's annoying to set the 
previous visibility settings manually again, especially for users who 
have to handle a lot of layers.
This should be changed to restore the previous visibility settings, for 
instance to the following state chain:
Exclusive visibility -> Restore previous visibility -> Exclusive 
visibility ->.....
A second state chain could be added, which resembles the current 
behaviour. Perhaps this could be bound to the Shift + double click on 
the layers eye.

Both chains can be complemented with the aforementioned 'visibility in 
groups' functionality: Exclusive visibility in group-> ... in the 
surrounding groups -> ... in the whole layer stack-> Restore previous 
visibility in the whole layer stack-> ... in the surrounding groups 
->... in the current group -> Exclusive visibility in group->.....
and
Show exclusively in the whole layer stack -> Show all layers in the 
whole layer stack -> Show exclusively in the whole layer stack -> ...

Best regards,

grafxuser

Re: [Gimp-developer] Cross-application work-flows and document fileformats

Alexandre Prokoudine — 2012-05-23T15:35:49


Or layer groups :) And port the plug-in to GEGL anyway :)

Alexandre Prokoudine
http://libregraphicsworld.org

Re: [Gimp-developer] Cross-application work-flows and document file formats

Kevin Cozens — 2012-05-23T15:33:00

Thanks, Alexandre. Good to see that the publically available information on 
the PSD file format has been updated to include something beyond PS6. Let's 
hope the information always stays public. The information in that page will 
make it possible for someone to update the PSD plug-in to fully support text 
layers.

Re: [Gimp-developer] gimp-win downloads for 2.6

Richard Gitschlag — 2012-05-23T15:03:18




Okay, that is a problem.  I'm hoping it is just a temporary glitch on 
Simon's part (i.e: 2.6 is no longer the "current version" so it's 
removed from that page, but he hasn't added it to the "old versions" 
page yet), but if it isn't addressed soon, definitely contact him.



In the meantime, all packages are in fact still available, you just have to check the "Releases" page instead.

Re: [Gimp-developer] gimp-win downloads for 2.6

Ofnuts — 2012-05-23T07:04:24

I'l referring to that one:

http://gimp-win.sourceforge.net/old.html

Which is the one pointed to by the "Dowload/old versions" link on the 
home page.

_______________________________________________
gimp-developer-list mailing list
gimp-developer-list< at >gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] gimp-win downloads for 2.6

Bertrand Denoix — 2012-05-23T07:04:11

I'l referring to that one:

http://gimp-win.sourceforge.net/old.html

Which is the one pointed to by the "Dowload/old versions" link on the 
home page.

_______________________________________________
gimp-developer-list mailing list
gimp-developer-list< at >gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] gimp-win downloads for 2.6

Cristian Secară — 2012-05-23T06:44:09

În data de Wed, 23 May 2012 01:48:50 +0200, Ofnuts a scris:


Which page dou you refer ?

On Sourceforge there is a loong list of all 2.6.x stable releases
http://sourceforge.net/projects/gimp-win/files/GIMP%20%2B%20GTK%2B%20(stable%20release)/


Cristi

[Gimp-developer] feature: Set exclusive layer visibility withingroups

Richard Gitschlag — 2012-05-23T05:23:08

I have a little gripe about setting "exclusive visibility" (shift+click a layer's visibility icon) in an image. Now that we have layer groups in GIMP 2.8, it only functions on the "top level" of the layer stack -- it seems impossible to toggle exclusive visibility inside a group.

Since a layer group can itself be a complex combination of layers (apparently including other layer groups!), we should have some ability to toggle exclusive visibility with respect to other members in that group only.

For example, the current behavior could be expanded from a simple on/off toggle to an iterative loop somewhat like this:

1 - When toggling exclusive visibility, first note the full path from image root to the selected item (inclusively) and begin iterating through it.
2 - IF at any point along this path there are any visible sibling items, THEN hide them, leaving only the selected item visible, and break and return.
3 - Otherwise, if we have traversed the entire path without finding any visible siblings, then selected item is the only visible item in the whole image. (Whether the selected item is itself a layer or group is irrelevant.) Therefore, traverse the selected path again and ensure that any and all sibling items at any point along the path are made visible.

This would establish a toggle chain of all items -> selected group -> (subgroup, etc.) -> selected item in group -> all items.

It could also be reversed; all items -> selected item in group -> selected group -> (parent group, etc.) -> all items, but I'm not exactly sure how that logic would pan out.

Note that in the simple case of an image with no layer groups, this quickly reduces to the current behavior of all items -> selected layer -> all items. (This also applies when setting exclusive visibility on a top-level group, because in that case we DO want to act on the group as a whole).

[Gimp-developer] gimp-win downloads for 2.6

Ofnuts — 2012-05-22T23:48:50

Unless I'm overlooking something, the gimp-win download pages on 
Sourceforge offer either 2.8 (stable version), or 2.4 and older 
("Previous Gimp versions" page), but 2.6 is no longer referenced. 
Wouldn't it be nice if the "Previous Gimp versions" page listed at least 
one 2.6 installer?

Re: [Gimp-developer] Gimp 2.8.0 - Saving in .jpg or .png hmmmmm

Burnie West — 2012-05-22T16:27:23

Seems to me a "project" is a superstructure whose character is broadly 
independent of the nature of the tasks it contains. A "project" incorporates 
tasks, resources, status, sometimes even schedules -:-) - and when opened 
presents the entirety of the project scope. Kinda "eclipse"-like.

   -- Burnie

Re: [Gimp-developer] Problems with brushes

Richard Gitschlag — 2012-05-22T15:59:18


The last time I reported it (bugzilla #588984) I was told "Not A Bug" but also "discuss on mailing list".  I did not have access to said mailing list that time ago - but I do now.  So yes, let's.

If I set my tool to 50% opacity I want the visible end result of a single (non-overlapping) stroke to be 50% opacity.  Whether or not I have incremental mode enabled should make absolutely no difference in this context; it should only make a difference when parts of a stroke overlap or intersect each other (such as shading one area back-and-forth).

Re: [Gimp-developer] Cross-application work-flows and document fileformats

Alexandre Prokoudine — 2012-05-22T15:25:19


www.adobe.com/devnet-apps/photoshop/fileformatashtml/

Alexandre Prokoudine
http://libregraphicsworld.org

Re: [Gimp-developer] Cross-application work-flows and document file formats

Kevin Cozens — 2012-05-22T15:10:44

While PSD format *might* support saving all GIMP data, it doesn't currently 
(text layers are converted to bitmaps IIRC). The XCF file format is subject 
to change as GIMP evolves. The other problem with this is that the PSD 
format is mostly undocumented and changes over time.

Re: [Gimp-developer] Gimp 2.8.0 - Saving in .jpg or .png hmmmmm

Nicolas Robidoux — 2012-05-22T15:05:06

On Mon, May 21, 2012 at 5:31 PM, Guillermo Espertino (Gez)
<gespertino< at >gmail.com> wrote:

The reason is that a GIMP project may contain more than one "finished
product"; XCF only collects data relevant to *one* image. For example,
I may want to produce various sized versions of a logo.

In addition, XCF does not contain information about how GIMP windows
and tools were organized around the related collection of output
images. A "project" would, in my mind, collect everything: related
images and GIMP configuration.