headers
Gino D | 24 May 12:37
Picon

[Gimp-developer] Merging visible paths via scripts

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.
Permalink | Reply | 1 comment |
headers
Ofnuts | 23 May 01:48
Favicon

[Gimp-developer] gimp-win downloads for 2.6

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?
Permalink | Reply | 4 comments |
headers
Claus (Gimp-Devel-List | 21 May 12:12
Picon
Favicon

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


Hello Gimp Developers,

First of all, thanks for your efforts in making Gimp better and better. I'm a longtime Gimp User, and really
love the program.

I loved to read about all the new features, that 2.8 brings to the table. Nevertheless, I was disappointed a
lot, after testing it for a few minutes. The Viewport/Display/Canvas (don't know what you call it) is
soooo extremely slow, compared to 2.6. Some examples:

When using the Rectangular Select Tool, the redraw-rate of the selection is extremely slow compared to 2.6.

Even worse. When I move a image in the window with the MiddleMouseButton, then the image totally breaks apart.

After that, I stopped testing, but I'm sure there are other tools and Situations, where this issues occur.

I have already read, that there is not a single developer in your team, which uses windows as his/her
development-environment. And that you even consider to stop the support for windows platform. I can
understand that thinking. Windows users must seem like a big croud of parasites to you ;-) Well, sadly I'm
too, one of the many windows users, who can't develop applications on them self. So I sadly cant contribute
to The Gimp, with more then bugreports.

I don't want to drop oil into the fire, and I really hope, that support for windows will not be dropped.

Back to the problem above. Is there already a bugreport for this issue? Shall I create one? Or doesn't it make
sense, cos there is no windows-developer that could look into it?

If this won't be fixed, or at least not in the near future, is there a chance, we get updated 2.6 builds?
Primarily security fixes, but also the latest fix for the JPEG-Issue introduced in 2.6.12?
(Continue reading)

Permalink | Reply | 8 comments |
headers
Jon Nordby | 21 May 03:26
Picon
Gravatar

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

Thread split out from [Gimp-developer] Gimp 2.8.0 - Saving in .jpg or
.png hmmmmm

On 20 May 2012 20:02, twfb <twfb09 <at> gmail.com> wrote:
> 1. Large complex, multilayered collage type images aiming for close to
>   photorealism. Often painting shadows etc.
> 2. Adjustments to photographs, curves, sharpness, size perspective corr.
> 3. Lo res images and graphics for websites.
> 4. Preparation of images for use as textures, bumpmaps etc for 3d
>   visualisation software. I mainly use Blender and Luxrender.
>
> The thing is that of all those tasks only no 1 could potentially benefit
> from the safety feature of xcf only save. But even there it actually
> gets in the way. I've never accidentally lost work due to saving in the
> wrong format. And I'm in my mid 30's having done graphics for ever ;)

Thanks for bringing the workflows/tasks you have do into the
discussion. That makes it much easier to have a fruitful discussion.

You say that only task 1 can potentially benefit from saving as xcf.
XCF is the only format that can store what you have done to the image
in a non-destructive way, and allow you to go back and change these
decisions. In your work-flows 2-4, do you never go back to an image
after having modified and saved it? Do you, like many others, keep an
original .png and export the modified version as a .png with a
different name, so you can always get the original?

For instance when preparing textures and bump-maps, do you ever go
back to tweak the textures after having used them in a Blender render
(after looking at the initial result)?
(Continue reading)

Permalink | Reply | 19 comments |
headers
Cristian Secară | 20 May 23:10
X-Face
Picon
Favicon

[Gimp-developer] and if I don't have middle click ?

I wanted to (ex)change a color of a simple png image, so I tried to use
Colors -> Map -> Color Exchange... tool.

There I am invited to "Middle-click inside preview to pick "From
color"". Where to middle click ? I only have a two button touchpad. I
switched the working place to my main dektop computer where the wheel
button is set to magnify function. I had to change the wheel button
to "middle click" function just to be able to pick the "From color"
from the original image.

I suppose I could use previously the color picker, write down the
desired color value and then enter manually the value in the "From
color" area of the Color exchange, but what is then the purpose of all
features of the tool ?

Cristi

--

-- 
Cristian Secară
http://www.secarica.ro
_______________________________________________
gimp-developer-list mailing list
gimp-developer-list <at> gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Permalink | Reply | 1 comment |
headers
Anke Lange | 20 May 14:48
Picon
Picon

[Gimp-developer] Problems with brushes

Hello list

I'm having a closer look at the use of brushes and I came across a few 
things, that were easy to use in the previous gimp (2.6) and now they 
are not there anymore. And some of the new features don't seem to work 
for me. So are they a features or bugs? Well, I just make a little list ;)

1. Why don't the brushes show their real size when aktivated?
The tool seems to adopt the settings of the previous used brush.

2. How can I paint adopting the gradiant for brush-colors?
When using brush-dynamics random-color, it does use the gradient-color, 
but not in the correct sequence.

3. Using brushes with a minimum distance of 1 lieves a gap using a brush 
caligraphic-brush with an angle of 40%.

4. The mapping matrix for the dynamic settings of the bushes is not 
editable. How can I edit this map to use on my own brushes?

5. When making a grayscale gih-brush, it doesn't display adopt the 
setting-procedures
Like when you create a brush to write GIMP using 5 layers. G, I, M, P, 
empty. Settings: ranks 5 random.

Using the brush, doesn't display the word GIMP , It just jumbles it all 
up so something like GMMGGIP PPII comes out of it.

6. The Gimp Tool Options  "Smooth stroke" and "Incremental" don't show 
any affect on the stroke of any brush. Do they only effect brushes using
(Continue reading)

Permalink | Reply | 5 comments |
headers
yahvuu | 19 May 16:29
Picon

[Gimp-developer] Quasimode Adjustments -- fastest adjustments [demo included]

Dear all,

for your inspiration, here's the fastest way to perform adjustments that i can think of:

While pressing a shortcut key
    - the corresponding slider gets displayed right under the pointer
    - moving the pointer left-right immediately performs the adjustment. 
To commit, simply release the key.

You may try the following channel mixer demo to test-drive the interaction:
https://sites.google.com/site/yahvuu/stuff/quasimode-adjust-demo.swf?attredirects=0

For the Flash-averse, there's also a screenshot available:
http://yahvuu.files.wordpress.com/2009/08/quasimode-adjust.png

The rationale behind is that most of the adjustments are relative adjustments by nature,
by which i mean that the absolute numbers are mostly irrelevant. The desired amount of
the effect gets determined by applying a bit more or less of it until it looks right.

Grabbing the slider handle is only cognitive burden here, which can be shortcut away.

enjoy,
yahvuu

PS: Flash demos do not fit the UI brainstorm well, so i'm posting here
Permalink | Reply | 6 comments |
headers
Saul Goode | 19 May 01:25

[Gimp-developer] contribution processes...

I apologize for the double-post; my mail system barfed and apparently sent a draft version of my post. Here
is a more refined version.

In my opinion the language of the draft is not very inviting to contribution. At minimum, each of the "has
to"s should be changed to either "should"s or "should strive to"s. Also, it is unclear whether the final
"does not have to be perfect" trumps any or all of the previous seven bullet points -- if it does not then the
requirements are indeed exceedingly stringent.

Especially problematic is the sixth bullet. A contributor should not be expected to learn or have access to
other platforms just so he can submit code; he should write his code to work on his development system and
those with access to and familiarity with alternative deployments should be able to submit patches or
propose changes to accommodate their systems. This suggests that the infrastructure to support
contributor participation should be hierarchical in nature; i.e., each enhancement/bugfix should be
treated as an openly developed "subproject" in which all are welcome to participate. 

I would propose a "centralized, distributed" approach akin to the following:

A separate 'gimp-contrib' repository be created in which development of larger enhancements and more
involved bugfixes takes place. Smaller bugfixes and enhancements could still employ the process of
submitting patches through Bugzilla. 

* A potential contributor submits a Bugzilla report outlining his issue and indicating that he/she is
willing to work towards its resolution.

* Upon approval of the endeavor by the GIMP developers, the contributor is granted branching and commit
privileges to the 'gimp-contrib' repository (if not already granted previously). This does NOT offer
push privileges to the Gnome-hosted 'gimp' repository.

* The contributor solicits whatever support and aid for his project he/she can, through whatever channels
he/she wishes. More significant aspects of the development should be inclusive of the official GIMP
(Continue reading)

Permalink | Reply | 0 comments |
headers
Crazy Aunt Gail's, LLC | 19 May 01:17

[Gimp-developer] contribution processes...

In my opinion the language of the draft is not inviting to contribution. At minimum, each of the "has to"s
should be changed to either "should"s or "should strive to"s. Also, it is unclear whether the final "does
not have to be perfect" trumps any or all of the previous seven bullet points -- if it does not then the
requirements are indeed exceedingly stringent.

Especially problematic is the sixth bullet. A contributor should not be expected to learn or have access to
other platforms just so he can submit code; he should write his code to work on his development system and
those with access to and familiarity with alternative deployments should be able to submit patches or
propose changes to accommodate their systems. This suggests that the infrastructure to support
contributor participation should be hierarchical in nature; i.e., each enhancement/bugfix should be
treated as an openly developed "subproject" in which all are welcome to participate. 

I would propose something akin to the following:

A separate 'gimp-contrib' repository be created in which development of patches takes place. 

* A potential contributor submits a Bugzilla report outlining his issue and indicating that he/she is
willing to work towards its resolution.

* Upon approval of the endeavor by the GIMP developers, the contributor is granted branching and commit
privileges to the 'gimp-contrib' repository (if not already granted previously). This does NOT offer
push privileges to the Gnome-hosted 'gimp' repository.

* The contributor solicits whatever support and aid for his project he/she can, through whatever channels
he/she wishes. More significant aspects of the development should be inclusive of the official GIMP
channels (mailing list, IRC, and the corresponding Bugzilla report), but smaller issues can be handled
without interfering with the main project.

* They are responsible for keeping their branch in synch with the GNOME 'gimp' module (or 'gimp-help-2',
'gimp-web', 'gimp-data-extras', etc) and following the feedback provided by the GIMP developers and
(Continue reading)

Permalink | Reply | 0 comments |
headers
Partha Bagchi | 19 May 00:24
Picon

[Gimp-developer] Wishlist: gegl Gaussian blur X&Y settings

Hi All,

For the Gaussian blur gegl tool, is it possible to link the X & Y size
settings so that they scroll together? More often than not, you are
likely to use the same value in both directions.

Thanks,
Partha
Permalink | Reply | 5 comments |
headers
Ryan Johnson | 18 May 09:33
Picon
Gravatar

[Gimp-developer] Feature request: Improve the Open file dialog thumbnails

I've been using GIMP to play around with some lighting, color, and GEGL operations on images.
What I've noticed is that the "Open file" dialog is very poorly constructed and it has become a problem. I'm using Win7 x64.
Nicely put, it's unintuitive.

These are suggested fixes, and you can choose more than one if it permits.

1. Raise the file size limit for autogeneration of thumbnails.
Many of my JPEGs are just slightly over 3 MB or whatever the small current limit is. Many of my RAW NEF files are just under 10 MB, at a resolution of 10.2 Megapixels. Many dSLR's exceed my camera's resolution, so my recommended upper limit is 20 MB, but doing a progressive scan (priority queue) would work best. Start out with anything under 5 MB, then 10, then 20 MB, so it is a rough priority queue, instead of a fine-grain one.

2. Allow users to multiselect files and explicitly batch-generate thumbnails (just clicking on the thumbnail placeholder with multiple images selected should initiate the process).

3. Use the native "Open file" dialog.

Additional comments: I have seen no other modern program, even open source, that has such an unusable thumbnail generator. If I recall correctly, there is a free implementation in Evince Document reader for a regular thumbnailer (thumbnail grid) and Open file dialog.

Bigger Goal:
Improve the "Open file" dialog to include other viewing modes besides a detail list. It's a graphics program after all! Appeal to the senses!

--
I'm an FSF member. The Free Software Foundation fights to keep your computer in your control, and only your control. Help protect you and your friends from customer abuse in the technology industry! http://www.fsf.org/jf?referrer=9448
_______________________________________________
gimp-developer-list mailing list
gimp-developer-list <at> gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Permalink | Reply | 22 comments |

Gmane