Re: [Gimp-developer] Class Diagram

[Sven Neumann]

On 22.05.11 20:51, Chad Wolpert wrote:
> Hi
> Can someone please tell me where I can find a UML class diagram for GIMP?

There isn't any. Probably the closest you can get are the object 
hierarchies in the GIMP API Reference Manuals:

http://developer.gimp.org/api/2.0/app/app-hierarchy-part.html

Note that this doesn't represent the current state of development, but 
rather the state of the stable 2.6 release. If you have the current 
source around, you can build a more recent version yourself.


Sven
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Announcing Gimpscripter plugin authoring tool, beta prototype

[Sven Neumann]

Hi,

On 09.05.11 15:23, lloyd konneker wrote:
> Announcing a new version of the "Make Shortcut" plugin, now called
> "GimpScripter". It lets you point-and-click create a plugin that calls a
> sequence of plugins, PDB procedures, or macros. It is a plugin authoring
> tool.
>
> Gimpscripter is a Gimp plugin written in Python. It generates Python
> code for a plugin.

Sounds great. You should consider to name it GIMPScripter or similar 
though as GIMP is called GIMP and not Gimp.

> Here is an example use, to make a plugin "Stroke selection with
> selection":
>
> Choose "Filter/Gimpscripter" to start Gimpscripter.
>> From the menu pane choose "Edit/Copy".
> Choose "Edit/Paste as/New Brush".
> Choose "Select/To path".
> Choose "Edit/Stroke/Path".
> Enter a name for the plugin, for example "Stroke selection with
> selection".
> Choose the OK button.
> Read the summary and choose the OK button.
> Restart Gimp.

It's a pity that GIMP needs to be restarted. We should add API to 
(re)load all or a particular plug-in at run-time.


Sven
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Standard Keyboard Shortcut for Don't Save Button

[Sven Neumann]

On Wed, 2011-03-09 at 08:55 -0800, Charlie De wrote:
> Hello all,
> 
> 
> I would like to make a request if I may for the keyboard shortcut, the key 
> that 
> corresponds to the underlined letter, for the Don't Save button in Save/Save 
> As 
> dialogs to be standardised, preferrably to the "d" key. At present, this is 
> inconsistent, in some instances the key is "n".
> 
> Some time ago I successfully edited the source files for version 2.6.11 to 
> this 
> effect, but after compiling and installing the program a number of issues 
> arose 
> that weren't present when using a binary from a repository, so I don't plan 
> on 
> compiling again if I can avoid it. As far as I remember, it's a small change, 
> to 
> be made in one or two of the files containing interface strings or settings.

The current development version (which is where such a change would have
to happen), doesn't use the string "Don't Save" any longer.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] GIMP won't quit

[Sven Neumann]

On Tue, 2011-03-01 at 16:42 +, jcup...@gmail.com wrote:
> On 1 March 2011 05:00, Roger Penn  wrote:
> > work out all the how's and so-forth, but for now if anyone knows the inner
> > workings of gimp-quit or why calling gimp.exe from the command line forks
> > two gimp processes I'd sure be grateful for some insight. Thanks.
> 
> I might be able to help a little on the forks-two-processes thing. My
> app does this as well, because Windows distinguishes between
> command-line and GUI .exes.
> 
> When Windows launches a program from the shell, it checks a flag in
> the .exe to see if this is a command-line or a GUI program. If it's
> been tagged as a GUI program, it just gets started, but if it's been
> tagged as command-line, Windows will pop up a console and use that to
> display stdin and accept stdout for the program.
> 
> Conversely, if you start a command-line program from the command-line,
> command.com will display stdout, pipe stdin, and wait until the
> program terminates before showing the prompt again. If you run a GUI
> program from the command-line, stdin/stdout for the program go nowhere
> and command.com will offer the prompt again immediately without
> waiting for the program to finish.
> 
> As a result of this strange design, it's impossible on Windows to
> write a .exe that can be used smoothly both from the command-line and
> from the desktop.

Which is why GIMP ships two binaries. A UI version called gimp.exe and a
command-line tool called gimp-console.exe. The latter does not provide
any user interface and doesn't even link with GTK+.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Pencil Tool

[Sven Neumann]

On Sat, 2011-02-26 at 20:36 +0100, Bogdan Szczurek wrote:
> > I've begun working on GIMP documentation so GIMP is on my mind a lot
> > lately. So, I have a suggestion - remove the pencil tool, and
> > instead, add a checkbox to the brush tool with an "antialiased"
> > label.
> 
> I'd go even further with that: make “antialiased” one of specific brush
> settings, not the “tool” itself. That way one would be able to have as
> much “pencils” predefined as one sees fit. And all that without
> touching tool tickbox back and forth if needed.

There's a difference between an aliased brush applied with the Brush
tool compared to the same brush applied with the Pencil tool. Try it.

The Pencil tool is important for tasks that require pixel-perfect
retouching, such as icon drawing, as it doesn't do sub-pixel positioning
such as the Brush tool does.

But of course under the hood it's the same paint core with just one
setting changed. But that is true for more tools. Paint tools, as the
user sees them, are solely a user interface thing. They represent a
certain bunch of properties set on the paint core. We could of course
expose all these properties to the user and doing so would allow us to
merge some tools. But actually I think it would be much better if we
would offer more presets to choose from. Instead of merging Pencil and
Paintbrush we should rather offer more variants like a "Soft Pencil"
that works more like what Liam expects, a "Hard Pencil" for pixel-pefect
icon retouching, a "Crayon", ...


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] GIMP developer meeting

[Sven Neumann]

On Mon, 2011-02-28 at 19:38 +0200, Alexia Death wrote:
> On Mon, Feb 28, 2011 at 7:23 PM, Kevin Cozens  wrote:
> > LightningIsMyName wrote:
> >> said on IRC that she can't point a domain at that adress so we really
> >> should get wiki.gimp.org running or pay for some web server with the
> >> GIMP funds.
> >
> > We can discuss this more at todays meeting. I would like to know what the
> > problem is with having wiki.gimp.org. GIMP has its own website so adding a
> > wiki to it should be no problem. Is it a lack of diskspace, lack of someone
> > to set it up, or lack of someone who keep an eye on the wiki and maintain 
> > it?
> 
> Wiki needs an admin that cares, a database and php installed on the
> server. AFAIK there is no gimp host that meets all those requirements,
> specially the admin part.

Well, the machine that hosts www.gimp.org meets all those requirements.
It has database and PHP installed and if anyone volunteers to become
"the admin that cares", it's no problem to add accounts on the machine.

> I wouldn't put in the same machine as any part of the main gimp site.
> Any dynamic site is vulnerable to exploits and hacks. Compromising
> such a trivial side thing like the wiki should in no way threaten the
> operation of any of the main sites and integrity of a heavily used and
> trusted host like gimp.org that could be used to spread malware far
> and wide.

Well, that's a point. But I guess that one could run such a server in a
chroot environment or even a virtual host.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] GIMP won't quit

[Sven Neumann]

On Sun, 2011-02-27 at 01:27 +0200, Aurimas Juška wrote:
> Hi,
> 
> On Sun, Feb 27, 2011 at 12:15 AM, Roger Penn  wrote:
> > I'm using the GIMP to create custom graphics on the fly for a CMS by calling
> > the script from the web page through ASP.NET.
> For what you want to do, Script-fu server should be the best option.
> See http://docs.gimp.org/en/gimp-filters-script-fu.html (Section
> 10.6.4. Start Server).

I don't think so. As far as I can see Script-Fu won't handle multiple
scripts running simultaneously.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Google Summer of Code 2011 - Project Ideas/Suggestions

[Sven Neumann]

On Sun, 2011-02-13 at 18:55 +0100, Martin Nordholts wrote:
> On 02/13/2011 12:04 AM, LightningIsMyName wrote:
> > I'm starting this thread to list ideas for Google Summer of Code 2011,
> > for the GIMP project. Since in the last year collecting ideas was done
> > partially by the mailing list, let's try it again this year and keep
> > most ideas here.
> 
> Thanks for a good start on this Barak
> 
> 
> I would like to add:
> 
> Port UI code to a non-low level language
> 
> Hacking UI code in C is a resource eater for us, we should use C for 
> quick and efficient pixel processing but not for creating buttons. It 
> would be interesting to make changes to the GIMP codebase that would 
> allow us for example write the Pointer Information Dialog in JavaScript.

We (or actually you) added support for defining plug-in dialog UIs using
GtkBuilder some time ago. But  there has been no progress on this since
then. As far as I can see there is still no support for using GIMP
specific widgets from GtkBuilder and no other plug-ins have been ported
yet. Perhaps that would be an area that should get some attention from a
GSoC developer.

Definitely sounds more useful to me than introducing Javascript to GIMP.
I somewhat doubt that we would get more developers hacking on the core
if we added JS as another entry barrier.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Icon for dynamics

[Sven Neumann]

On Thu, 2011-02-03 at 13:18 +, Nelson A. de Oliveira wrote:
> Hi!
> 
> I don't know if it's related to the GTK theme or something else, but
> having a button with "?" on it, to choose the dynamics mode is somehow
> strange (see http://sites.google.com/site/naoliv/gimp/1.png). It looks
> something like a help button.

That is obviously a place-holder. It is meant as an invitation for
someone to volunteer to draw a better icon.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Wrong tools contour

[Sven Neumann]

On Thu, 2011-02-03 at 16:32 +0200, Alexia Death wrote:
> On Thu, Feb 3, 2011 at 2:50 PM, Nelson A. de Oliveira  
> wrote:
> > I don't know if it's a know issue,
> Im sorry, but I find this question a bit annoying. It's a big issue
> smack in the middle where you cant miss it. Of course its known.
> 
> > but it seems that the contour from
> > pencil, paintbrush and rubber are being wrongly drawn on the screen
> Yes its know. And I restored it to its usual state(that is also
> broken, but less so) a few days ago.
> 
> > (using latest git version).
> Git is a moving target. It is occasionally broken. If you want to
> complain about something in it, its best done in IRC and after
> building again to see if it has been fixed already.

Alexia, it is still OK to ask here. Asking here should be as appropriate
as asking on IRC. A short answer stating that this is a known issue
would have been appropriate.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Photoshop ?compatibility? mode

[Sven Neumann]

On Tue, 2011-02-01 at 17:16 +, Michael Grosberg wrote:
> Alexandre Prokoudine  gmail.com> writes:
> 
> > *sigh*
> > 
> > http://git.gnome.org/browse/gimp/tree/etc/ps-menurc
> > 
> > Alexandre Prokoudine
> > http://libregraphicsworld.org
> > 
> 
> I will refrain from expressing my opinion on undocumented, undiscoverable
> features. 

This is documented in the user manual even:
http://docs.gimp.org/en/gimp-introduction-history-2-0.html

I am sure the gimp-docs team will appreciate a patch that moves this
information to a better place though. It's somewhat difficult to locate
it in the list of changes for GIMP 2.0.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Coding Convention Question

[Sven Neumann]

On Fri, 2011-01-21 at 19:05 -0500, Eric Grivel wrote:
> Hi,
> 
> I'm looking at bug #596410 and in order to get to the import source in 
> gimpimage.c, I seem to have to #include "../file/gimp-file.h" (to get to 
> the GIMP_FILE_IMPORT_SOURCE_KEY constant). Is it appropriate to include 
> a header file from a sibling directory this way?

No, you just #include "file/gimp-file.h". The include paths for the
compiler are configured so that this will work.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] translate menu mod

[Sven Neumann]

On Tue, 2011-01-18 at 00:29 -0500, Kevin Cozens wrote:
> Sven Neumann wrote:
> > Um, sorry. Somehow I was under the impression that it should work. But
> > you are right, it's supported for plug-ins but not (yet) for Script-Fu
> > scripts.
> 
> Are translations enabled on all plug-ins? What about for Python scripts?

Python scripts are full-fledged plug-ins and can use the framework that
exists for GIMP plug-ins. There's API to register a translation domain
and this allows third-party plug-ins to install their own message
catalogs.

> Having taken a look at a plugin just after I wrote those initial questions I 
> remember we talked about adding a _ function (or something like that) so 
> that Script-Fu would have a way to mark strings for translation allowing for 
> getenv(?) to be called during runtime.

Script-Fu has that already (and it's gettext that gets called, or
actually dgetext). However so far the message is translated in the
standard script-fu translation domain so this doesn't work for
third-party scripts.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] donations for GIMP 2.8

[Sven Neumann]

On Fri, 2011-01-07 at 00:27 +0100, Martin Nordholts wrote:
> On 01/06/2011 11:01 PM, Sven Neumann wrote:
> > I just wanted to let you know that we have seen a dramatic increase in
> > donations since then. More than 120 people donated over the last 8 days
> > and sent us about 2,500 dollars. Perhaps it would be a good idea to
> > discuss how we can actually use this money to make the GIMP 2.8 release
> > happen soon...
> 
> Here are some examples of what I think blocks a GIMP 2.8 release:
> 
>   * Finish single-window mode
>   * Make layer masks work with layer groups
>   * Bug 596410 - gimp-image-get-filename returns NULL for imported files
>   * Bug 597117 - impossible to drop a group as a sibling inside a group
>   * Bug 612931 - Moving individual layer in layer group not possible
>  with Move Tool
>   * Bug 600554 - Implement layer group transforms
>   * Bug 624303 - Introduce an item class in PyGIMP
>   * Bug 630748 - display filters do not work
>   * Bug 631766 - Bad performance when moving brush outline on canvas
> 
> One natural use of money donated specifically to speed up a GIMP 2.8 
> release would be in the form of bounties for fixing bugs that blocks 
> GIMP 2.8 from being released. I know we have a history of disliking 
> bounties, but as far as I know we never really tried, and now we have 
> money more or less ear-marked for this purpose.

So far this has been the most constructive idea that has been brought up
in this thread. So why not? Let's try to come up with a list of bugs
that block the GIMP 2.8 release and put bounties on them. Who wants to
volunteer to prepare a list of bugs that are worth having a bounty put
on them?

The stream of donations has dropped a little but there is still
significantly more money coming in than usual. We have received more
than $1,000 in the last 7 days.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] translate menu mod

[Sven Neumann]

On Fri, 2011-01-14 at 01:42 +0300, Alexandre Prokoudine wrote:
> On 1/13/11, Sven Neumann wrote:
> 
> > Why doesn't FX Foundry install its own po files in its own translation
> > domain? Script-Fu has support for registering an additional translation
> > domain.
> 
> Because you said it was impossible :)
> 
> http://www.mail-archive.com/gimp-developer@lists.xcf.berkeley.edu/msg19130.html
> 
> And Kevin agreed :)

Um, sorry. Somehow I was under the impression that it should work. But
you are right, it's supported for plug-ins but not (yet) for Script-Fu
scripts.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] combo boxes in osx

[Sven Neumann]

On Tue, 2011-01-11 at 14:41 +0700, Ek kian wrote:
> i also experience this on OSX 10.6.2,
> i use GIMP 2.6.8 compiled with GTK-OSX
> (http://gtk-osx.sourceforge.net/).
> 
> but for GIMP from http://gimp.lisanet.de, it working ok and i think it
> using X11.
> 
> i prefer using GIMP with GTK-OSX because it using Global Menu and
> using OSX Native UI.Regards,

You can compile a more recent version of GIMP and GTK+ on Quartz using
Macports. Just make sure you compile the "+no_x11+quartz" variant of
GIMP and all the libraries.


Sven



___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] translate menu mod

[Sven Neumann]

On Tue, 2011-01-11 at 15:36 +0300, Alexandre Prokoudine wrote:
> On 1/11/11, Alexia Death wrote:
> 
> > anything up. If you use strings that have translations in their
> > original location, you may even get translation working, tho Im not
> > sure how script-fu and localization interact specially in regard to
> > lables.
> 
> Checboxes and suchlike in FX Foundry scripts dialogs are partly
> translated, because some messages ara translated in po-script-fu/*.po.

Why doesn't FX Foundry install its own po files in its own translation
domain? Script-Fu has support for registering an additional translation
domain.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] donations for GIMP 2.8

[Sven Neumann]

On Mon, 2011-01-10 at 19:39 +0200, Alexia Death wrote:
> On Monday, January 10, 2011 19:17:51 Øyvind Kolås wrote:
> > Code documentation is also one of the tasks that are not permitted for
> > instance in the Google summer of code, perhaps we could come up with a
> > set of bounties, or find someone motivated and fund them on a task by
> > task basis or even part time for documenting?
> 
> I think this is a frightfully good idea too. One of those tasks could be 
> writing the GIMP code Codex. Coding standards and best practices and so on. 
> It 
> could give us much easyer to merge forks for example. Its extremely annoying 
> having to rewrite most of a great feature to make it fit  for merge And 
> yes, I do remember my starting days trying to make sense of the GIMP on the 
> inside.

But who could write (and review) such docs? That would be the core
developers and we really need the core developers to work on GIMP 2.8.
Focusing on developer documentation is not going to make GIMP 2.8 happen
earlier. On the contrary, it is likely to delay it further.

Please try to come up with suggestions that focus on the 2.8 release.
Thanks.


Sven



___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] combo boxes in osx

[Sven Neumann]

On Mon, 2011-01-10 at 17:14 +, s...@startide.org wrote:
> Hi
> 
> I've just got gimp to compile from git on OSX, I've just noticed that the
> combo boxes popup is displaying behind the dialogue panel so they are
> hidden.
> Thats every combo box.

Are you running GTK+ on X11 or did you compile GTK+ with the Quartz
backend?


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] translate menu mod

[Sven Neumann]

On Sat, 2011-01-08 at 12:02 +0700, Ek kian wrote:

> i usually modify menu directly from image-menu.xml,
> but that made menu is broken on other language than English.
> 
> what is the right steps to do menu modification so the menu still can
> be translateable to other language?

The right step is to get your changes upstream. What exactly are you
changing and why?


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Gimp-developer] donations for GIMP 2.8

[Sven Neumann]

Hi,

I guess most of you noticed that several people blogged about the fact
that GIMP 2.8 has not yet been released even though the schedule that
Martin published a while ago estimated that this would have happened by
the end of 2010. As far as I can see this is the article that started it
all:

http://libregraphicsworld.org/news.php?readmore=667

And this post suggested that donating to the GIMP project could help us
to achieve our goal of releasing GIMP 2.8 earlier:

http://www.omgubuntu.co.uk/2010/12/single-window-gimp-release-delayed-but-why/

I just wanted to let you know that we have seen a dramatic increase in
donations since then. More than 120 people donated over the last 8 days
and sent us about 2,500 dollars. Perhaps it would be a good idea to
discuss how we can actually use this money to make the GIMP 2.8 release
happen soon...


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] How to use UNDO stack?

[Sven Neumann]

On Tue, 2010-12-14 at 14:43 +0100, Jose Antonio Muñoz Montero wrote:

> The actions to be made on an image is saved in the undo history.As I
> read, the Undo stack temporarily stores these actions, but do not know
> in what format. I want to retrieve this data from the Undo stack in a
> text file.

That is a misunderstanding. The undo stack stores image states so that
you can go back to these states. It doesn't store the actions performed
on an image. What you are asking for is not possible with the current
undo framework.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Gimp on OSX, Mac App Store and Funding

[Sven Neumann]

On Sun, 2010-12-12 at 10:45 +, jcup...@gmail.com wrote:
> On 7 December 2010 22:07, Sven Neumann  wrote:
> > in GIMP on OS X. Even though there's a pretty well working Quartz port
> > of GTK+, there haven't been any successful attempts to make a binary
> > GIMP installer from this (as far as I know). I very much doubt that
> 
> gtk-osx is used to make binary installers for inkscape, gimp, gnucash
> and others. There's a gimp binary here, and probably other places
> around the net:
> 
>   http://gimp.lisanet.de/Website/News/News.html
> 
> I've used it for my own project and it seems to work OK.

This is GIMP based on GTK+ for X11. It needs an additional X11 server
running on OS X and thus integration into the system is very poor. What
I was talking about is the Quartz backend for GTK+ which allows GIMP to
run as a native application. As far as I know no one has ever made a
binary installer for OS X based on this.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] unsharp mask

[Sven Neumann]

On Wed, 2010-12-08 at 23:15 +0200, Alexia Death wrote:

> I'm not suggesting changing it's name, I'm proposing suffixing the
> name of the algorithm with its purpose because the algorithm name
> itself is outright misleading. Putting it in the menu in a menu item
> named Sharpen would serve the same purpose, but I dont think we have
> any other sharpening algorithms in default distribution to justify
> that.

Well, you are suggesting to change its name. Suffixing it is a name
change and it has the potential to confuse users that are actually
looking for "Unsharp Mask" and expect to find a standard filter under
its usual name.

About the menu, that's a good point. IMO it would be useful to have a
"Sharpen" group in the "Filters->Enhance" menu, separated from the other
filters. Here all sharpen filters can register and having "Unsharp Mask"
in a group with "Sharpen" should be a good hint on what it actually
does.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] unsharp mask

[Sven Neumann]

On Wed, 2010-12-08 at 20:35 +0200, Alexia Death wrote:
> When we are on the subject already, I have a suggestion. Lets save the
> countless noobs time and change the menu label of unsharp mask to
> Unsharp Mask Sharpen?

Seriously, Unsharp Mask is the correct term and it is widely known and
mentioned in pretty much any book/tutorial that covers image
manipulation and sharpening algorithms. It doesn't really help to
disguise the filter by giving it a different name. GIMP is not really
meant to be the application that a noob should use for their casual
image manipulation needs. There are other application that fill this
need and we should leave it to them to present the user with just a
single sharpening algorithm and calling it "Sharpen" (even though it
would most probably be "Unsharp Mask").


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] unsharp mask

[Sven Neumann]

On Wed, 2010-12-08 at 14:40 -0500, Rob Antonishen wrote:
> >
> > We prefer patches created from git commits using 'git format-patch'. If
> > you had submitted such a patch, I would have pushed your commit by now.
> > Can you resend your diff with a commit log please?
> >
> >
> > Sven
> 
> Sorry.  I've never worked with git before.
> 
> Would the attached be correct?

Doesn't totally follow the rules for the git commit log message (taken
from the git commit manual page):

 Though not required, it’s a good idea to begin the commit message with
 a single short (less than 50 character) line summarizing the change,
 followed by a blank line and then a more thorough description. Tools
 that turn commits into email, for example, use the first line on the
 Subject: line and the rest of the commit in the body.

But yes, it does the trick and I'll push it right away.


Thanks,
Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] unsharp mask

[Sven Neumann]

On Wed, 2010-12-08 at 13:22 -0500, Rob Antonishen wrote:
> Looks simple enough - it is only a GUI restriction (I was able to
> apply larger radii using the script-fu console)
> 
> Attached is a diff

We prefer patches created from git commits using 'git format-patch'. If
you had submitted such a patch, I would have pushed your commit by now.
Can you resend your diff with a commit log please?


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Gimp on OSX, Mac App Store and Funding

[Sven Neumann]

On Tue, 2010-12-07 at 18:15 +, Filipe Sim-Sim wrote:

> My idea is this: Put Gimp on the App Store. with a symbolic fee, let's
> say 2.5$ . If the 70/30 ratio of apple store is applied, then that
> should be 1.75$ for each download. This could be a significant source
> of income for the Gimp Project, the Gimp on Mac and could possibly
> allow a single developer to be committed full-time to it. This
> symbolic fee could be either for each 2.X updates or perpetual, that
> is open to discussion, i'm not that sure on the details. 

If anyone wants to improve GIMP on OS X and put it up on the App Store,
for whatever fee, they are free to do that. We can't stop anyone from
doing that anyway and as long as the changes are pushed back upstream,
everyone will benefit.

Now I am curious if some real improvements to GTK+ on OS X and GIMP
would result from this. Currently there doesn't seem to be any interest
in GIMP on OS X. Even though there's a pretty well working Quartz port
of GTK+, there haven't been any successful attempts to make a binary
GIMP installer from this (as far as I know). I very much doubt that
money would change this, but if someone thinks that he/she could make a
living from this, please go ahead and give it a try. In general we (and
the GTK+ developers) are very much interested in getting your changes
integrated upstream.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] servers consolidation

[Sven Neumann]

On Thu, 2010-11-04 at 22:09 +0300, Alexandre Prokoudine wrote:

> It appears that the plan for servers consolidation was never realized.
> And it looks like this is one of the problems behind some ongoing
> issues with availability of our sites.

That impression is not entirely correct. While the FTP service is still
on wilber, wilber.gimp.org got new hardware and provides enough disk
space now.

The problematic thing is that developer.gimp.org wasn't set up after the
hardware replacement. But as far as I can see this has been fixed in the
mean-time.

So as far as I can see all is well, isn't it?


Sven

PS: Please ask such questions on the gimp-web mailing-list next time.


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] [PATCH] Fix for memory and file descriptor leaks

[Sven Neumann]

On Tue, 2010-11-09 at 16:20 -0200, Nelson A. de Oliveira wrote:

> Can somebody review two patches that (hopefully) fix some memory and
> file descriptor leaks, please?
> 
> The first one is basically g_free()s and fclose()s:
> http://people.debian.org/~naoliv/misc/gimp/patches/0001-Fix-memory-and-descriptor-leaks.patch
> 
> For the second one, instead including a fclose(fp) for every block
> with a "return FALSE;" in it I just moved it below (since it was not
> being used before).
> http://people.debian.org/~naoliv/misc/gimp/patches/0002-Move-file-opening-block-to-after-some-tests.patch
> 
> Is there something wrong with them, please?

I have pushed both patches to master. Thanks for your contribution.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Any examples for gimp-progress-install?

[Sven Neumann]

On Sat, 2010-10-30 at 12:51 +0200, Gino D wrote:

> I would like to precisely understand how the "gimp-progress-install"
> procedure works; sorry, I have tried to see the source code for this
> purpose, but I am still not very experienced in reading and managing
> it, and I have some difficulty in figuring out what a
> "progress-callback" exactly represents.
> 
> More than anything, I am interested in knowing in which cases and for
> what purposes the aforesaid procedure (as well as related commands,
> such as "gimp-progress-uninstall" and "gimp-progress-cancel") could be
> used within scripts. Can you give me some examples?

You don't need to use these procedures from scripts.

Their purpose is to allow plug-ins to install their own UI for
displaying progress information from other procedures. The Script-Fu
extension uses it for example to redirect progress information from a
script to the progress-bar in the script dialog window.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] where is this string in practice (from quick-mask-commands.c)

[Sven Neumann]

On Mon, 2010-10-25 at 19:03 +0300, Cristian Secară wrote:
> I like to know where (or how) can I see this string in practice:
> 
> #: ../app/actions/quick-mask-commands.c:105
> msgid "Quick Mask Attributes"
> 
> #: ../app/actions/quick-mask-commands.c:108
> msgid "Edit Quick Mask Attributes"
> 
> #: ../app/actions/quick-mask-commands.c:110
> msgid "Edit Quick Mask Color"
> 
> #: ../app/actions/quick-mask-commands.c:111
> msgid "_Mask opacity:"

There's a button in the lower left of the image window between the ruler
and the scroll-bar. It has a right-click menu that allows to open a
dialog to configure the Quick Mask attributes. I believe that's where
these strings are being used.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] LAB in Info Window

[Sven Neumann]

On Fri, 2010-10-22 at 11:15 +1100, Graeme Gill wrote:
> Retrieving the display profiles automatically
> would be nice though, and there is code around to do this on various platforms

Code for retrieving the display color profile from the operating system
is already in place in GIMP for X11 and Mac OS.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] LAB in Info Window

[Sven Neumann]

On Thu, 2010-10-21 at 23:23 +0200, Martin Nordholts wrote:

> > You can't really take the active color profile into account unless we
> > decide to add a dependency on littlecms to the core. The whole color
> > management system would basically need to be rewritten. This has the
> > potential to allow some important improvements all over the place. But
> > we really need someone willing and capable to finish this work if we
> > want to open this can of worms.
> 
> The experiment doesn't need to take place in git master though, we can 
> create an experimental branch if we get a set of interesting patches. So 
> it doesn't matter if it gets finished or not, we either abandon or merge 
> that experimental branch depending on the outcome.
> 
> If someone starts experimenting with this, I suggest making littlecms 
> one of potentially backends, so that we can compile against the native 
> color management library of a platform when available.

That is what the current color management infrastructure does. So far no
one has ever expressed any interest in implementing a native backend
though. So I guess we better abandon that idea and just use lcms for all
platforms. Would be a lot easier if lcms could be used in the core and
if we wouldn't have to create some sort of abstraction layer that fits
all color management backends.

But then we might run into trouble when cairo gets color management
capabilities. Currently display color management is totally broken in
trunk, so we need to find a way out of this anway...


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] LAB in Info Window

[Sven Neumann]

On Thu, 2010-10-21 at 21:26 +0200, Martin Nordholts wrote:
> On 10/21/2010 09:10 PM, Jacek Poplawski wrote:
> > The question is - can I do it? Can I submit a patch somewhere and it
> > could be commited into development branch?
> 
> Of course you can!
> 
> I suggest you create a patch and attach it to a new bug report filed at 
> bugs.gimp.org. Don't forget to take the active color profile into account.

You can't really take the active color profile into account unless we
decide to add a dependency on littlecms to the core. The whole color
management system would basically need to be rewritten. This has the
potential to allow some important improvements all over the place. But
we really need someone willing and capable to finish this work if we
want to open this can of worms.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Batch command syntax for calling Python plugins/scripts on Windows XP

[Sven Neumann]

On Mon, 2010-10-11 at 15:38 +0200, Sebastian Koblinger wrote:

> Further I open the command line, go to the directory that contains my
> pictures to be processed and type:
> 
> gimp-2.6 -i --batch-interpreter=python-fu-eval -b python-fu-my-function
> 
> which starts to print the usual loading commands but stops with:
> 
> Starting extension: 'extension-script-fu'
> batch command experienced an execution error
> 
> Is there essentially anything wrong with my syntax?

Please post a simple example script to illustrate what you are trying to
achieve.

> I guess the issues are the input paramters of the function. A function
> requires an image and a drawable as input, am I right?

No, procedures don't require any input parameters at all. For procedures
to be run from the image menu, it makes sense to have an image and a
drawable parameters, but even there this is not a requirement.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] brush tool artefacts => slow brush tools

[Sven Neumann]

On Sun, 2010-10-10 at 17:24 +0200, Olivier wrote:
> There are no longer brush tool artefacts on the canvas, which is very
> good. Unfortunately, and maybe this is because of the repair, the
> brush tools are now very slow.

Olivier, please, this is ongoing development. And yes, we are using the
application that we are developing. And yes, we notice such problems.
There is really no need to tell us about each and every problem you
encounter with current git. In particular not if there's already a
bug-report on it.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Detecting "closure" of selection

[Sven Neumann]

On Sun, 2010-10-10 at 14:55 +0200, Ofnuts wrote:

> > (let ((count (cdddr (gimp-histogram (car (gimp-image-get-selection image))
> >   HISTOGRAM-VALUE
> >   255
> >   255
> > (= (car count) (cadr count)) ; compare num of all pixels to all white 
> > pixels
> > )
> 
> Exactly what the doctor ordered. Thanks (and to Rob...). However, the 
> only documentation I found of this function was in the API browser of 
> the python-fu console. I couldn't find it in the files I sampled at 
> . Where is it documented?

http://developer.gimp.org/api/2.0/libgimp/libgimp-gimpcolor.html#gimp-histogram


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Fade has a blocking dialog

[Sven Neumann]

On Mon, 2010-10-04 at 15:01 +0200, Olivier wrote:
> I'm not sure whether this is a bug or a feature: although most GIMP
> dialogs are not-blocking ones (i.e. you can leave the dialog open and
> do something else), the Image: Edit -> Fade dialog is blocking. It
> happens in the current git version, but maybe also in the stable
> version.

That's intentional. Due to the way that Edit->Fade is implemented, the
user must not do anything else while this dialog is opened.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Gimp-developer] ANNOUNCE: GIMP 2.6.11

[Sven Neumann]

Hi,

GIMP 2.6.11 is a bug-fix release in the stable GIMP 2.6 series. Among
other bug-fixes, it restores printing functionality with version 1.10 of
the cairo library. Many Linux distributions start to ship this version
now.

The source code for GIMP 2.6.11 can be downloaded from ftp.gimp.org or
from one of the mirrors listed at http://gimp.org/downloads/#mirrors.
Binary packages for the supported platforms should become available
soon; please check the Downloads section at www.gimp.org.


Overview of Changes from GIMP 2.6.10 to GIMP 2.6.11
===

* Bugs fixed:

 631199 - Printing and Print preview broken with cairo 1.10
 572865 - Parasite handling had problems and can cause crashing
 628893 - Error with string-append and gimp-drawable-get-name
 623850 - (Paco) Recursive Gaussian Filter error
 624487 - Fix incorrect "wrap mode" documentation values in Edge plug-in
 557380 - Difference of Gaussians gives blank doc if "Invert" selected
 627009 - Image type filter doesn't include .rgba SGI files
 626020 - Console window opening on file-ps-load
 624698 - Wood 1 and Wood 2 have bad alpha value
 624275 - Image saved from google docs generates a
  'gimp-image-set-resolution' error message

* Updated translations:

 German (de)
 Spanish (es)
 Italian (it)
 Japanese (ja)
 Romanian (ro)
 Chinese (Hong Kong) (zh_HK)
 Chinese (Taiwan) (zh_HK)


Happy GIMPing,
Sven



___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] strict aliasing warning in build.

[Sven Neumann]

On Fri, 2010-10-01 at 00:46 -0700, Patrick Horgan wrote:
>  The fix would be to make a union:
> 
>   union {
>  gchar idaschars[16];
>  int idasints[4];
>  } id;
> 
> and access the appropriate sections.
> 
>id.idasints[0] = ebx;
>id.idasints[1] = edx;
>id.idasints[2] = ecx;
> 
>id.idaschars[12] = '\0';
> 
> then do the comparisons against id.idaschars.

Could you send a patch please, preferably generated from a git commit?


Thanks, Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] X copy-paste in text tool

[Sven Neumann]

On Fri, 2010-10-01 at 09:12 +0200, g...@catking.net wrote:
> Hi,
> 
> noticed a defect in the text entry tool.
> 
> I was preparing a few lines of text on top of an image using the small 
> edit window of the text tool. If I select a text segment with the mouse 
> and do middle button to paste the text cursor does not move.

If you are using the "small edit window of the text tool", then I assume
you are talking about the 2.6 text tool here, right? This edit window is
a standard GtkTextView. So if there's misbehavior when pasting to this
window, then please report this to GTK+.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Megapixels counter

[Sven Neumann]

On Thu, 2010-09-30 at 08:11 +0200, Martin Nordholts wrote:
> On 09/29/2010 11:32 PM, Bogdan Szczurek wrote:
> >>> There's a small thing that I missed in GIMP for some time. That
> >>> thing is a megapixel counter to add to window title or status.
> >>
> >> Hi!
> >>
> >> IMO we need to make it easier than editing a complex format-string to
> >> get this info in the window title.
> >
> > Well… I haven't thought of that, to be frank, since I'm comfy with the
> > current state of things :). Also, I just wanted to fill the gap that
> > was important for me.
> >
> > As an afterthought I would change presentation from 2 to 1 decimal
> > places. I don't think there's much use of having such precise
> > measurement as 1/100 of MP.
> 
> I can certainly see that showing size in megapixels can be useful for 
> our target user base. We're even lucky enough to have the prefect char 
> 'M' free for it. So I have pushed a cleaned up version of your patch 
> (that only uses 1 decimal) to git master:

You missed to add the documentation for this new option. But I have
taken care of that now:

commit 2a67bfcb101d597782a080e7f4963638e122
Author: Sven Neumann 
Date:   Thu Sep 30 10:11:45 2010 +0200

app: document the new display title option

 app/config/gimpconfig-dump.c |1 +
 app/display/gimpdisplayshell-title.c |5 ++---
 docs/gimprc.5.in |4 
 etc/gimprc   |2 ++
 4 files changed, 9 insertions(+), 3 deletions(-)


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Optimizing border-like selection in python

[Sven Neumann]

On Mon, 2010-09-27 at 08:58 -0300, Joao S. O. Bueno wrote:

> Hmm..maybe soem of the spped-up I experience has tod o with the new
> image I create on BG  not being displayed -
> it will certainly help on this due to the marching ants that are used
> midway that don't need to show up.

Shouldn't make much of a difference. The change to the selection only
invalidates the view and queues a redraw. The pending redraw shouldn't
slow things down considerably.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] IMPORTANT: GIMP AND OPENSOURCE SCAM ON EBAY!

[Sven Neumann]

On Thu, 2010-09-23 at 18:28 +0200, Bernhard Guillon wrote:
> On 23.09.2010 06:05, Abir Sadik wrote:
> > Heyy..
> >
> > I was looking for something on ebay and this is what i stumbled upon: 
> > some seller or sellers are selling GIMP and many other open source 
> > applications (vlc, pidgin) pretending as a "distributor" of the 
> > softwares. check this seller http://myworld.ebay.com/bourleche
> > He is selling GIMP and vlc, oo, pidgin etc. with it as "bonus" softwares.
> >
> 
> If there is such a market for selling GIMP why not the project itself is 
> selling the software on ebay. In my country (germany) some people do not 
> have access to broadband internet and like to buy a CD of the software.

You can get a copy of GIMP on a CD/DVD in the newspaper shop nearby
pretty much every week. Just check out the computer magazines. Currently
there's the c't special on sale that comes with lots of interesting
software for photo editing:
https://www.heise.de/kiosk/special/ct/10/06/programme.shtml


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Native RAW support

[Sven Neumann]

On Tue, 2010-09-21 at 07:53 +0200, Martin Nordholts wrote:

> I think the point here is that configure, make, make install on a GIMP 
> tarball - with all dependencies met - should result in a GIMP 
> installation with good support for working with RAW images.

Oh come on. The ufraw plug-in is much better maintained outside the GIMP
source tree. No one would benefit if we tried to include all third-party
plug-ins in the GIMP source tree. That's just silly. Our product vision
states that GIMP should be easily extendable. Instead of adding more
plug-ins to the source tree, as you suggest, we should work on making it
easier for users to install additional plug-ins.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] shorthanded and outnumbered (Re: Native RAW support)

[Sven Neumann]

On Mon, 2010-09-20 at 20:13 -0400,
saulgo...@flashingtwelve.brickfilms.com wrote:
> Quoting "Joao S. O. Bueno" :
> 
> > Oliver -
> >
> > this rant has no reason to be.  Sorry for that.
> 
> I disagree. Oliver has politely raised an issue to be discussed and  
> presents some valid points.
> 
> GIMP is nearly a million lines of code -- well over a million if you  
> take into account GEGL and BABL. If a potential code contributor  
> examine 1000 lines of code each and every day, it would take nearly  
> three years before his perusal would be complete.

That's why we have the devel-docs folder in the GIMP source tree where
we try to explain the structure of the source code and document the
internal and external APIs as well as file formats. Sure, there should
be more documentation like this. Everyone is invited to contribute.

> Libgimp also is not what I would expect an application's library to  
> be. Instead of being a library of functions which GIMP invokes but are  
> factored out so other programs can make use them separate from GIMP,  
> the opposite seems to be the case: libgimp invokes functions internal  
> to GIMP (other programs can thus use libgimp, but only if GIMP is  
> running).

Taking your example, the role of libgimp is explained in
devel-docs/structure.xml. Sure, this documentation could be extended to
make things even more clear. Everyone is invited to contribute.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Native RAW support

[Sven Neumann]

On Mon, 2010-09-20 at 22:18 +0200, fu...@gmx.net wrote:
> > GIMP can't load or save any file format except XCF without separate
> > plug-ins. So by your definition of "native support" GIMP doesn't support
> > any file formats except XCF. Most features in GIMP are implemented as
> > plug-ins. So I don't see your point in asking us to add RAW support to
> > the core. There's a plug-in for it, just as for any other file format.
> > 
> 
> You get me wrong! I don't say to program it into the core, I am just
> suggesting, that GIMP should already be shipped with all the required
> stuff (third-party libraries/plug-ins) that's needed to open/write raw
> files, instead of depending on software, that has to be
> downloaded/installed separately.

Then you should direct that suggestion to your distribution of choice.
We don't decide what's included in the GIMP package that you install. I
agree that it would be a good idea if the gimp-ufraw package was
suggested whenever you select gimp for installation. It should probably
also be included in the Windows installer.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Native RAW support

[Sven Neumann]

On Mon, 2010-09-20 at 01:11 +0200, fu...@gmx.net wrote:
> Without the requirement of installing separate software/plug-ins.

GIMP can't load or save any file format except XCF without separate
plug-ins. So by your definition of "native support" GIMP doesn't support
any file formats except XCF. Most features in GIMP are implemented as
plug-ins. So I don't see your point in asking us to add RAW support to
the core. There's a plug-in for it, just as for any other file format.

What's admittedly missing is the ability of the core to process files in
higher bit depths than 8bit per pixel. This is definitely on the
roadmap.

> I read on the Internet, that GEGL will provide support for many raw
> format types of different camera manufacturers already by itself,
> without the need of UFRAW or anything else.

That is wrong. GEGL will also use third-party libraries to read and
write RAW files. We are certainly not going to reinvent the wheel.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Native RAW support

[Sven Neumann]

On Sun, 2010-09-19 at 21:01 +0200, fu...@gmx.net wrote:
> Thanks, but I know UFRAW and I am also using it myself, but that's not
> the point of my question. I just wanted to know, when GIMP will
> support RAW processing out of the box.

Define "out of the box", please.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Gracefully handling BPP in a python plugin

[Sven Neumann]

On Sun, 2010-09-19 at 21:36 +0200, Ofnuts wrote:
> On 19/09/2010 20:44, Sven Neumann wrote:
> 
> >
> > First of all, why are you using the PDB directly instead of using the
> > Python objects?
> 
> Ignorance, defiance, and laziness. The doc for the Image class 
> (http://www.gimp.org/docs/python/index.html) has around 20 methods. 
> Compare to the number of gimp_image_* functions in the PDB (not speaking 
> of all the Python class methods/attributes vs the whole PDB)(*) For a 
> newcomer, it looks like using the Python classes isn't going to cut it, 
> since PDB functions will have to be used anyway, so why bother with two 
> ways of doing things?

Because the 20 methods that are available in the Image class cover about
95% of what people actually need. It's much more convenient and you can
of course still use methods from the pdb module.

Oh, and the docs you pointed at are hopelessly outdated and should
probably be taken off-line. You better refer to the help you get in the
Python console.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Native RAW support

[Sven Neumann]

On Sun, 2010-09-19 at 15:46 +0200, fu...@gmx.net wrote:
> A few programs (CinePaint for example) use dcraw to allow direct
> support for opening/processing RAW files of many camera manufacturers.
> I personally think, that it would be a great feature for GIMP, too.

You can already open and process RAW files of many camera manufacturers
in GIMP after installing the UFRaw plug-in from
http://ufraw.sourceforge.net/. But I guess that "direct support" means
something else for you?


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Gracefully handling BPP in a python plugin

[Sven Neumann]

On Sat, 2010-09-18 at 21:55 +0200, Ofnuts wrote:

> > If that is the case, then there is a bug somewhere. But I very much
> > doubt that gray-scale layers are reported to have 3 or channels. Perhaps
> > you can show us some example code?
> >
> 
> Hmm. Wrote some fresh code to demonstrate this and of course it behaves 
> as you say. Grumble, grumble. Back to the drawing board. Thx for the 
> heads up.
> 
> PS: well, something fishy still.  Creating a greyscale layer in a RGB 
> image works, and yields a 1BPP layer:
> 
> image_color = pdb.gimp_image_new(100,100,0)
> layer_grayscale=pdb.gimp_layer_new(image_color,100,100,2,'grayscale_layer',100,0)
> print pdb.gimp_drawable_get_pixel(layer_grayscale,0,0)

First of all, why are you using the PDB directly instead of using the
Python objects? The code to create an image and an RGBA layer should
look like this:

image = image = gimp.Image(100, 100, RGB)
layer = gimp.Layer(image, "RGB layer", 100, 100, RGBA_IMAGE)
image.add_layer(layer)

Then to address you problem, you are not really creating a grayscale
layer in an RGB image. Your code only creates the layer, it doesn't
actually add it to the image. If you tried to do that, then that would
fail.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Gracefully handling BPP in a python plugin

[Sven Neumann]

On Sat, 2010-09-18 at 01:51 +0200, Ofnuts wrote:

> 
> I had overlooked the fact that greyscale was an attribute of the image 
> and not the layer. Thanks for the reminder. With that in mind I could 
> perform some more tests with greyscale and it turns out that at least 
> the python interface returns 3 or 4 channels even in greyscale, so 
> everything is OK.

If that is the case, then there is a bug somewhere. But I very much
doubt that gray-scale layers are reported to have 3 or channels. Perhaps
you can show us some example code?


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Gracefully handling BPP in a python plugin

[Sven Neumann]

On Fri, 2010-09-17 at 20:48 +0200, Ofnuts wrote:
> Hello,
> 
> I'm writing a plugin that takes a drawable as input for pixel values. 
> What kind of BPP can I expect? I'd say 4 and 3 are color layers with and 
> without alpha. Will I encounter 2 and 1 for grey-levels with and without 
> alpha, too?

Well, it depends on what your procedure specifies as image types when it
registers. The documentation says:

  image_types is a comma separated list of image types, or actually
  drawable types, that this procedure can deal with. Wildcards are
  possible here, so you could say "RGB*" instead of "RGB, RGBA" or "*"
  for all image types. If the procedure doesn't need an image to run,
  use the empty string.

>  I can't find a way to create a layer in grey levels (or to 
> change an existing color one to grey levels). Am I overlooking the 
> obvious or would that only apply to layer masks?

Grayscale layers only exist in grayscale images. If you specify "GRAY"
and/or "GRAYA" or "*", then your procedure needs to handle those
drawable types.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] GIMP paths - optimization & tricks

[Sven Neumann]

On Mon, 2010-09-13 at 22:19 +0200, Mirza wrote:

> Please consider optimization with merged paths as this is crucial to  
> smooth rendering on current GIMP's architecture.

Such "optimizations" don't belong into the core. We already provide the
infrastructure for scripts and plug-ins to hook into the Paths dialog
where they could provide a menu entry to "Remove overlapping paths".


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] GIMP paths - optimization & tricks

[Sven Neumann]

On Sun, 2010-09-12 at 23:25 +0200, Mirza Husadzic wrote:
> Hi all,
> 
> I came up with solution to import and merge Blender's SVG file as path
> into GIMP. 
> This is just quick and dirty solution which I hacked this afternoon.
> But it works very well.
> I opened bug report yesterday concerning GIMP's invalid path-line
> drawing (https://bugzilla.gnome.org/show_bug.cgi?id=629340).
> Then, as Sven marked this ticket as duplicate of
> https://bugzilla.gnome.org/show_bug.cgi?id=55364 (dating form 2001) I
> realized that 
> things will change really slow:-).

Actually I have fixed the paths drawing problem Friday evening and the
problem is solved in my tree. Just needs a little more work to finish
it. So please stop wasting your time with work-arounds.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Drawing per Script

[Sven Neumann]

On Sun, 2010-09-12 at 13:58 +0200, oli...@first.in-berlin.de wrote:
> Hello,
> 
> 
> I tried drawing per Script.
> I'm using Python.
> 
> I can already use vectors for drawing circles,
> and set single points.
> 
> I did not found a way to create rectangles,
> or lines.

Probably the easiest method is to have your script generate SVG and use 
gimp_vectors_import_from_string(). You can of course also create vector
strokes using the gimp_vectors_bezier_stroke method.

> How can I speed up my drawings without switching to C?
> With my Python script I need about 3 or 4 seconds just for drawing 2072 
> circles.

How do you draw your circles now?


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] GIMP paths.

[Sven Neumann]

On Thu, 2010-09-09 at 12:13 +0200, Mirza Husadzic wrote:

> The problem is manifested when I imported SVG file (the mesh UV Layout
> generated by Blender 2.53) into GIMP, in order to be able
> to paint textures by keeping guide-lines with paths.
> 
> The paths are not imported/merged properly where SVG image is
> generated correctly (probably by 'librsvg'?).
> The Blender's 'uv.py' exporter script had generated uv's layout as SVG
> polygons as follows (note that polygon is a quad):
> 
>  stroke-width="1px" 
>   points="67.334,493.895 77.587,494.896 78.033,463.871 67.768,463.723
> " />

Can you please open a bug-report and attach the most simple test case
that you can come up with? We need a small .svg file that illustrates
the problem. I am pretty sure that the problem can easily be fixed then.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Python plugin registration: choosing between a "closed" set of strings

[Sven Neumann]

On Tue, 2010-09-07 at 16:53 +0200, Ofnuts wrote:
> I'd like the user to select a "variant" of a plugin (among 3 to 5 
> ones). I would normally do so with a R/O drop-down box displaying the 
> names. Is there a way to do so using the right type of parameter type in 
> the registration (couldn't find it)?

You should consider to avoid gimpfu for this and write a real GIMP
plug-in in Python using a user interface built in PyGTK. The
auto-generated UI of gimpfu is really just suited for very simple
scripts. And there is a lot of awkwardness in gimpfu. It tries to make
things easy for you, but then it gets into your way and you end up
spending time to find workarounds for that.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Nightly builds with buildbot, where can we host?

[Sven Neumann]

On Mon, 2010-09-06 at 21:38 +0200, Martin Nordholts wrote:
> On 09/06/2010 09:22 PM, Sven Neumann wrote:
> > Will buildbot build failures be posted to this list? Do you have the
> > 'blame' feature setup so that the commits that potentially broke the
> > build are listed?
> 
> I think posting failures to the list would create too much spam, my plan 
> was to have an IRC bot for that instead.

Hmm, buildbot has support for that, but I don't quite understand what
buildbot output on IRC would be good for. IMO the buildbot web-site
should be accessible by anyone and the bot should send mails in the case
of a build failure. Given how seldom the GIMP tree does not compile,
this shouldn't create too much traffic.

> I don't have the blame feature set up yet, but is is usually not hard to 
> figure out what commit that caused make distcheck to fail. Eventually I 
> want to run make distcheck for each commit pushed, but we can live 
> without that for now.

Sure, it's easy to figure out. But with a list of commits to consider
(commits between the last successful build and the broken one), it's
even easier.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Bucket-fill the selection in a python plugin

[Sven Neumann]

On Mon, 2010-09-06 at 20:59 +0200, Ofnuts wrote:

> I'm working on my first Gimp plugin in python, and most things work, but 
> I can't seem to make a bucket-fill into the selection.
> 
> My code currently does:
> 
>  
> res=pdb.gimp_edit_bucket_fill_full(drawable,FG_BUCKET_FILL,NORMAL_MODE,0,0,True,False,SELECT_CRITERION_COMPOSITE,0,0)

You are using opacity=0. The fill does of course not have any effect
then.

Are you certain that you actually want to bucket-fill at all? Since you
are using a selection, it seems likely that you actually want to fill
that selection. Then you can use layer.fill() instead.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Nightly builds with buildbot, where can we host?

[Sven Neumann]

On Mon, 2010-09-06 at 21:22 +0200, Martin Nordholts wrote:

>   * We can do development releases whenever we want, there will
> always be a tarball ready to be released. In the past, getting
> ready for a development release has taken weeks some times.

That's over-exaggerating things a little. It has sometimes taken hours
to fix 'make distcheck'. By running this more regularly this can of
course be much improved.

Will buildbot build failures be posted to this list? Do you have the
'blame' feature setup so that the commits that potentially broke the
build are listed?

> I don't have a fixed IP address however which makes it hard for me to 
> host a machine for this. So the question is: what alternatives do we 
> have? Maybe this would be a good thing to spend our money on? I guess 
> the easiest thing would be to rent a (possibly virtual) machine 
> reachable from the internet. We can then add links to that machine on 
> gimp.org to the tarball dir it produces.

Well, we could ask if it is possible to have this run on cube. But I
guess that it really makes sense to have a dedicated (virtual) machine
for this.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Update on LCH layer modes

[Sven Neumann]

Hi,

On Mon, 2010-09-06 at 17:42 +0200, Rupert Weber wrote:

> just wanted to get this out before another week passes, as I probably 
> won't be getting to it before next weekend (or maybe the odd sleepless 
> night).
> 
> I posted an update to the patch to
>   https://bugzilla.gnome.org/show_bug.cgi?id=325564
> which now hides the old layer modes unless they are loaded from an XCF.

I am not so happy about the choice of the term "obsolete". The old layer
modes are not obsolete. I'd suggest to use the term "legacy" instead.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] GPU-accelerated Image Filtering w/ CUDA

[Sven Neumann]

On Thu, 2010-09-02 at 20:37 -0400, Alan wrote:
> Hi all,
> 
> It sounds like CUDA is not ideal for GIMP, but individuals on this list 
> might be personally interested in it (it is free, just not OSS, might be 
> good for plugin devel).  I pushed my code into a git repo:
> 
> http://github.com/etotheipi/CUDA_Image_Convolution
> 
> Keep in mind that the state of the code is very immature in structure, 
> but the algorithms are solid and work very fast if you have a 
> CUDA-enabled graphics card.   The readme has a lot of useful information
> 
> Some timings:
> 
> Basic convolution, erosion or dilation (on NVIDIA GTX 460):
>   4096x4096 image with 15x15 PSF/SE: 125 ms compute time (   
> 8 Hz)
>   4096x4096 image with  3x3  PSF/SE:  20 ms compute time (  
> 50 Hz)
>   2048x2048 image with  5x5  PSF/SE:   7.5   ms compute time ( 
> 130 Hz)
>512x512  image with  3x3  PSF/SE:   0.36  ms compute time 
> (2750 Hz)
> 
> These timings are without memory transfers, which is somewhere between 1 
> GB/s and 3 GB/s host<-->device.  Keep in mind that the code operates 
> only on floats (which I need for my application), but it could be 
> significantly faster if modified to work on 8-bit integers and batch 
> memory operations in 128-bit chunks.  Maybe one day...
> 
> Let me know if you have any interest developing or simply using this code.

You might want to resend this offer to the gegl-developer list. It might
be interesting to integrate your work with the gsoc2009-gpu branch.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] scanner support should be File->Acquire

[Sven Neumann]

On Wed, 2010-09-01 at 12:22 +0200, yahvuu wrote:

> after some more thinking, here's my take for 2.8:
> 
> 
> File->New...
> File->Acquire->Scan from Device xy...
> Scan from Device yz...
> 
> Nice extra: if there's only one device connected, the whole 'File->Acquire' 
> submenu
> can be replaced by 'File->Aquire Scan from Device xy...'.
> That should maximize scanner discoverability.

That's actually not implementable as the scanner entries are created by
plug-ins. All a plug-in can do is to register entries in a menu.

As far as I can tell not all scanner plug-ins register a menu entry per
device. Actually it's even a rather bad idea to do that since that means
that the plug-in needs to be run at every GIMP startup in order to query
for scanner devices. Actually it would even have to keep runnning to
make hot-plug of scanners work. It's a much better idea to just have a
"Scan" menu entry and do the device discovery at the moment the plug-in
is invoked. If there are multiple scanners connected, the plug-in can
present a device selection. For a single scanner it can skip this.

It will also be a pain to persuade the authors of scanner plug-ins to
change their menu registration based on the GIMP version. We can
work-around that to some extent by mapping menu paths to a different
place. That functionality is already in place for menu paths that have
been moved over the last GIMP versions. I guess most scanner plug-ins
even still register in /File/Acquire and are being mapped to
/File/Create/Acquire


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Patch shortening GIMP startup time

[Sven Neumann]

On Tue, 2010-08-31 at 14:18 +0200, Łukasz Czerwiński wrote:

> Passing a string literal directly to g_message() is also not a
> good
> idea. Please use g_message("%s", message) instead. But I
> didn't
> understand what this part of your patch is trying to achieve.
> 
> 
> Why it's not a good idea? What's the difference? Nevertheless, ok,
> I'll change it.

It's potentially dangerous. g_message() takes a format string as the
first parameter. Of course you can pass a literal string to it. But in
case that literal string contains printf-like format directive, your
code will crash. Since we can't safely assume that the error message
will definitely not contain such format directives, it is safer to use
"%s" as the format string.

> A description of an optimization: all script-fu scripts loaded on
> startup was loaded using a command "(load ...)" of a TinyScheme
> language. This means running several functions escaping a path to a
> script, interpreting the string, choping it to tokens, analyzing,
> unescaping and finally loading the script. My optimization makes Gimp
> call directly a function loading a script without using a slow
> (comparing to calling one function in native C) TinyScheme
> interpreter. Instead I've written two helper functions
> (load_script_file and scheme_file_push) responsible for loading
> scripts.
> 
> 
> I have done also a second modification - connected with comparing
> strings (stricmp), but I've just spotted an error in it, so I'll fix
> it and send it later.

It would be best if you could start to use git for your changes. You can
then make separate commits for each of your changes and submit your
changes broken into smaller commits. That makes review a lot easier. It
is also easier for us to apply your patches then.


Sven



___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Patch shortening GIMP startup time

[Sven Neumann]

On Mon, 2010-08-30 at 23:31 +0200, Łukasz Czerwiński wrote:


> I have made several optimizations in loading script-fu extension
> making the loading process a bit faster. It's the first time I change
> something in an open source program and don't know best way to
> "announce" it and get it reviewed, so I send a patch in a mail. 
> The major speedup is caused by calling my function load_script_file
> instead of script_fu_run_command("(load "). Please review my
> changes and send an answer if the patch is OK. 

Thanks for your patch. It definitely needs some work though. First of
all it is not OK to comment out code. If code should be removed, then
please remove it. 

Passing a string literal directly to g_message() is also not a good
idea. Please use g_message("%s", message) instead. But I didn't
understand what this part of your patch is trying to achieve.

Overall it would help a lot if you could explain what your patch tries
to achieve and what the purpose of the changes are. I have not been able
to understand the benefits of your changes just by looking at the patch.


Sven



___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Getting new layer modes fit for inclusion

[Sven Neumann]

On Mon, 2010-08-30 at 20:25 +0200, Rupert Weber wrote:
> so I've played around with babl a bit, and quite a few questions came 
> up. Is there a separate babl mailing list?

gegl-developer is the place for discussing babl things.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] (no subject) plus dockables

[Sven Neumann]

On Fri, 2010-08-27 at 12:39 +0200, yahvuu wrote:
> On 27.08.2010 07:32, Martin Nordholts wrote:
> > If people have troubles finding the Layers dockable, we should instead
> > look into making it more discoverable, like adding a 'Dockables' top
> > menu or moving them directly under 'Windows' instead of having a sub menu.
> 
> What about naming it the 'Dialogs' menu?
> 
> -- 'Dockables' sounds like implementation slang to me. And the 'Windows'
> menu becomes confusing in single-window-mode.

"Dialogs" is even more special than "Windows" and in single-window-mode
it is at least as wrong as using the term "Windows". The "Windows" menu
name on the other hand is pretty much default and used in many
applications as a place to list all currently open windows. And that's
the main use of it in GIMP as well. With the exception that we also list
the dockables since we consider them something like sub-windows.

> Making the Layers dialog discoverable under the 'Layers' menu and color
> dialogs below the 'Colors' menu etc.. makes a lot of sense, but IMHO that's
> the job of a 3.0 redesign -- there is a whole lot more to do than just 
> releasing
> the dockables from their current hiding place and distributing them over the
> menu structure.

As I pointed out in another mail, most dialogs are already available in
their respective menus. Completing this is not a major overhaul, it's a
bug-fix.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] (no subject) plus dockables

[Sven Neumann]

On Fri, 2010-08-27 at 07:32 +0200, Martin Nordholts wrote:

> >> If I want a colour , I should find it on the colour menu . If I want to
> >> select  layers I should fine the necessary interface elements on the
> >> layer menu.
> >
> > Sounds reasonable. We could duplicate the menu items from the Dockables
> > menu that raise/create those dialogs in the places where they belong. So
> > we would have "Layers dialog" in the "Image/Layers" menu and the like.
> > That's as simple as editing the XML files in the menus sub-directory.
> > Perhaps someone wants to come up with a patch...
> 
> I don't think we should duplicate any menu items. Having things in two 
> places tends to cause unnecessary confusion. A user will have to answer 
> questions like "Why is this menu item in two places? Is it the same menu 
> item? Does it do the same thing? Which one should I use now?" Having 
> just one place to do things avoids such ambiguity and mental friction.

We do that for a few menu items already and I don't think it has ever
caused any problems. Some examples are (and there are many more):
 
 Edit->Undo History
 View->Navigation Window
 Select->Selection Editor
 Colors->Info->Histogram
 
Actually I think it's just an oversight that the Layers dialog is
missing from the Layers menu. IMO all dialogs should be accessible from
the menus where they belong to functionally. The "Dockables" menu is
just a place to list all the available dialogs. It should be secondary.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Newbie startup problems

[Sven Neumann]

On Fri, 2010-08-27 at 14:55 +0200, oli...@first.in-berlin.de wrote:
> Hi,
> 
> 
> On Thu, Aug 26, 2010 at 01:55:22PM +0530, Phani Bhushan Tholeti wrote:
> > Hi,
> > 
> > I am new to GIMP (its source, usage and features). I had joined this list
> > with a view to contribute to GIMP.
> > I did manage to get it to compile and run (though my code is old - about a
> > month or two).
> > 
> > Currently I am giving the manual a try (to get used to GIMP), but its HUGE
> > and a lot of features for me to learn.  :( or :) ?
> > The wiki took me here: http://gimp-wiki.who.ee/index.php/Hacking:Source_Tree
> [...]
> 
> Oh, an overview on the organization of the source tree!

More complete and up-to-date documentation can be found in the
devel-docs folder of the source tree. Here is also the place where any
new developer documentation should be added.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] (no subject) plus dockables

[Sven Neumann]

On Thu, 2010-08-26 at 22:05 +0200, oli...@first.in-berlin.de wrote:

> I'm not long enough on this list to know all the old discussions, but AFAIK
> Sven Neumann once (some years ago) was interviewed by the Chaos Radio, and
> mentioned there, that one person did a complete usability anylsis.
> 
> I don't know idf this work has already been finished and published.
> 
> Would be interesting to see at the recommendations. I mean: not necessarily
> adopt all such things (maybe thera ara also other concepts and ideas), but at
> least it could be something for a discussion.

This is all documented at http://gui.gimp.org/ and for some years now we
are changing the UI based on input from the GIMP UI team.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] (no subject) plus dockables

[Sven Neumann]

On Thu, 2010-08-26 at 21:11 +0200, g...@catking.net wrote:

> If I want a colour , I should find it on the colour menu . If I want to 
> select  layers I should fine the necessary interface elements on the 
> layer menu.

Sounds reasonable. We could duplicate the menu items from the Dockables
menu that raise/create those dialogs in the places where they belong. So
we would have "Layers dialog" in the "Image/Layers" menu and the like.
That's as simple as editing the XML files in the menus sub-directory.
Perhaps someone wants to come up with a patch...


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Closing Command Line Window in Batch Mode (Windows

[Sven Neumann]

On Wed, 2010-08-25 at 15:27 +0200, pakko wrote:
> Hi,
> 
> i'm writing a java application that automatizes some processes. One part of
> the process is to start the gimp with a predefined script. The script loads an
> image an applies some filter. For this purpose i use the commmand line
> switches:
> 
> gimp2-6.exe -i -b "(script_name params)" -b "(gimp-quit 0)"
> 
> This works fine so far, but this opens a new windows-console. After the script
> finished it states:
> 
> "batch command successfull - "

You are supposed to use the gimp-console binary for non-interactive use.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] scanner support should be File->Acquire

[Sven Neumann]

On Tue, 2010-08-24 at 23:23 -0700, Jim Michaels wrote:
> newbies who are using GIMP are always asking where is the scanner
> support.
> why? because they can't find it.

Most probably they ask this because you need to install a third-party
plug-in in order to have scanner access from within GIMP.

> File->Acquire would be more appropriate.  maybe even File->Scanners if
> you want to be obvious (which is even better!).
> 
> but I can tell you from a thought process and human usability
> standpoint that grouping it under File->Create makes no rational,
> reasoning sense.
> 
> at least keep the scanner stuff separate and make it obvious that it's
> for scanners.

Scanner plug-ins are supposed to register in
"/File/Create/Acquire". "Acquire" is a menu group inside the
File/Create sub-menu. So scanners are already grouped separately from
the other plug-ins that create a new image.


Sven



___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] scanner support should be File->Acquire

[Sven Neumann]

On Wed, 2010-08-25 at 13:39 -0300, Luiz Felipe Moraes Pereira wrote:
> I agree with you, also the other stuff related to creation(button, etc)
> should go somewhere else in gimp. 

"somewhere else" is not a very intuitive place either. We've had a
longer discussion when these items were moved to File->Create and no one
came up with a better solution. So unless someone comes up with a very
good idea this time, things will stay as they are.

And no, just adding yet another sub-menu to the File menu is not a very
good options. That menu is pretty much overloaded already.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Getting new layer modes fit for inclusion

[Sven Neumann]

On Tue, 2010-08-24 at 22:59 +0200, Sven Neumann wrote:
> On Tue, 2010-08-24 at 17:06 +0200, Rupert Weber wrote:
> 
> > > I suspect that the code is already triply duplicated now then, the
> > > original GIMP CIE Lab code in app/base/cpercep.c , it's copy in
> > > babl/ectensions/CIE.c and your conversion code.
> > 
> > I'm surprised to find that code in app/base. As you say, it's the same 
> > as in babl.
> > But I don't see that code being called from anywhere within GIMP. Why is 
> > it even there?
> 
> It is used by the RGB->Indexed conversion in core/gimpimage-convert.c

Oh, and also by the SIOX algorithm in base/siox.c


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Getting new layer modes fit for inclusion

[Sven Neumann]

Hi,

On Tue, 2010-08-24 at 02:52 +0200, Rupert Weber wrote:

> The patch is here. Now, and it works. The conversions add 17k of code. 
> Once GEGL takes over, they'll simply removed again. No one gets hurt.

Well, the problem with your patch is that it adds new public API to
libgimpcolor. And that will hurt us pretty badly. We will have to
maintain that API for a couple of releases and I would really like to
avoid that. Plug-ins will start to use it and that code will pretty soon
have to be converted to use babl then.

Instead of adding more pixel conversion routines to libgimpcolor, all of
libgimpcolor should be deprecated as soon as possible and all users
should be converted to use babl instead. Otherwise we will stick with
our legacy APIs forever.

Unfortunately I can't access bugzilla.gnome.org at the moment (seems to
be a temporary server problem), so I can't review your patch in detail.
I really don't want to stand in the way of this patch, but I strongly
suggest that we go the road of deprecating libgimpcolor asap instead of
extending it further.

And no, I didn't ask you to work on the GEGL modes, I just ask you (or
actually anyone) to use and improve babl when it comes to pixel format
conversions.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Getting new layer modes fit for inclusion

[Sven Neumann]

On Tue, 2010-08-24 at 17:06 +0200, Rupert Weber wrote:

> > I suspect that the code is already triply duplicated now then, the
> > original GIMP CIE Lab code in app/base/cpercep.c , it's copy in
> > babl/ectensions/CIE.c and your conversion code.
> 
> I'm surprised to find that code in app/base. As you say, it's the same 
> as in babl.
> But I don't see that code being called from anywhere within GIMP. Why is 
> it even there?

It is used by the RGB->Indexed conversion in core/gimpimage-convert.c


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Alignment-Tool && Guides

[Sven Neumann]

On Mon, 2010-08-23 at 09:56 +0200, oli...@first.in-berlin.de wrote:
> On Sun, Aug 22, 2010 at 06:23:37PM -0700, Bill Skaggs wrote:
> [...]
> > 
> > My recollection is that layer border are already magnetic, too.
> 
> New feature? Since when?
> I have 2.6.7 here.

Canvas borders are magnetic, but layer borders aren't (yet).


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Getting new layer modes fit for inclusion

[Sven Neumann]

On Mon, 2010-08-09 at 15:42 +0200, Rupert Weber wrote:

> (2) Separate out the actual conversion routines in gimplibcolor as
>  a standalone patch.
>  Maybe change the Decompose plug-in to use those, so we at least
>  have something to make use of the new conversions.
>  (as far as I can tell, the current Decompose Lab functions are
>  broken, anyway).
> (3) Once gimplibcolor updates are all settled, go about adding new layer
>  modes which make use of them.
>  (a) decide, which modes. Be conservative, don't clutter the menu
>  too much with modes that nobody needs. Once they are out, we
>  can't take them back.
>  (b) decide how to name them.
>  (c) decide how to deal with storing them (XCF version++)

New code in GIMP should use babl for pixel format conversion. There's no
need to introduce new API for that as we have babl which is available to
the core and plug-ins and provides a much superior API. If your
optimized routines turn out to outperform the CIE Lab <-> sRGB
conversions that are in babl right now, then your code should be added
to babl.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] c++ gimp plug-in

[Sven Neumann]

On Fri, 2010-08-06 at 08:58 +0800, Tim Chen wrote:

> I am developing a GIMP plug-in with C for quite some time and I just
> realized that there is a useful C++ library that could save me a lot
> of trouble.
> 
> Is it possible to write GIMP plug-in in C++?

Well, C can be used easily from C++, so there is nothing to prevent you
from using C++ to write a GIMP plug-in.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] what is the meaning of "git commit %s" ? (translation related)

[Sven Neumann]

On Thu, 2010-08-05 at 14:03 +0300, LightningIsMyName wrote:

> I'm not sure this should be translated though, since git is a name of
> a tool and "commit" is a git specific term which should probably be
> kept untranslated (I saw the term "commit" in other non-English
> articles so it's probably best not to translate it).

Yes, please unmark the string for translation.

> I'll add a comment to the file as soon as I get to a non-public computer.

Translator comments are not added to the pot file (which is generated),
but directly to the C code. In this case though the message should
simply not be marked for translation at all.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Introduction / Color layer modes

[Sven Neumann]

On Tue, 2010-08-03 at 18:46 +0200, Rupert Weber wrote:

> About how to store in XCF:
> The obviuos choice seems to be to bump up the version to 3, which is 
> what the patch currently does if one of the new modes is used.
> 
> That might not be good, though:
> - Older versions will simply refuse to open the file.
> - With e.g. 2.6.8, you can still open a file with the new modes, it's
>just that the display will be a mess until you've set valid layer
>modes.
>While this won't allow you to render the image correctly, you can
>still *access* it, which might be valuable.

Without having looked at the patch (yet), I think that bumping the
version in case that the new modes are being used is the right thing to
do. Sure you can do something with the file in an old version, but the
behavior is undefined and unexpected and it would IMO be better to
require that the user uses a version that is new enough to handle the
new modes.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] pick color anywhere on the screen ? not quite

[Sven Neumann]

On Sun, 2010-08-01 at 23:48 +0300, LightningIsMyName wrote:
> Hello,
> 
> I discovered that when using windows it will indeed turn to the
> regular cursor when you leave GIMP's UI, but the "pick" functionality
> still works. Click anywhere on the screen - although GIMP's window
> will loose focus (in favour of the window you clicked on) the right
> color would still be picked (at least on my windows XP SP3 32).
> 
> On linux it works perfectly - the GIMP window doesn't even loose the focus.
> 
> If colour picking still doesn't work (check that if you click out of
> the window and go back to GIMP, if the foreground color was set to the
> right color) you are welcome to open a bug report at the GIMP bugzilla
> https://bugzilla.gnome.org/enter_bug.cgi?product=GIMP

If it doesn't work, then that's more likely a bug in GTK+ then.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Please fix Color and/or Value transfer mode

[Sven Neumann]

On Thu, 2010-07-29 at 01:56 -0700, Charlie De wrote:
> > So go fix it in gegl. I think it was  decided 4 years ago what is going to 
> > happen to the layer mode  bugs.
> 
> And my point is that wasn't such a good decision precisely because it took 4 
> years to get it fixed.  As stated, an earlier native fix would have brought 
> the 
> benefit to GEGL.  It's disingenuous to challenge me now, 4 years later, to 
> fix 
> it in GEGL.  If my line of thought had been followed 4 years ago, GEGL would 
> most likely already be fixed.

It would have taken an afternoon or two to fix it. Someone just needs to
spend that time and actually prepare a patch. This is not a question
about GEGL or not GEGL. If you feel that it is important to get this
fixed, then please submit a patch that introduces new fixed color modes.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Please fix Color and/or Value transfer mode

[Sven Neumann]

On Wed, 2010-07-28 at 17:34 -0700, Charlie De wrote:
> It's worth noting, however, that XCF is not meant to be an 
> archival format. 

Uh, oh. Of course it is meant to be used that way. If you work on images
using layers, then saving as XCF is the only way you can archive your
work.

As others have pointed out already, it is of course possible to
introduce a new color mode to fix the old broken one. Old XCF files
would still load fine then and the problem would be fixed. But we are
certainly not going to break the XCF file format.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Please fix Color and/or Value transfer mode

[Sven Neumann]

On Tue, 2010-07-27 at 11:08 -0700, Charlie De wrote:

> I thought that it had been decided the existing GIMP Color mode was broken, 
> so 
> "files relying on old behaviour" is not an issue.

Since we released stable versions with this broken behavior we now have
to maintain backward compatibility to it. It is considered very
important that you can open your old XCF files in a new version of GIMP
and get the same result as in the version you created them in.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] about getting involved in developing Gimp

[Sven Neumann]

On Thu, 2010-07-22 at 18:04 +, Michael Grosberg wrote:

> I think the reason is lack of vision and inspiration. There is a perception 
> that
> Gimp isn't going anywhere. To attract people, a project must FEEL as if it's
> going somewhere; people want to see their effort being put to good use. And if
> they know what the result is  going to be in advance, they will be more 
> willing
> to contribute.

Despite the fact that GIMP has a very clearly defined vision and very
interesting features on the roadmap, it may be true that this isn't
communicated well enough. But this is a matter that should be discussed
on the gimp-web mailing-list. What we are lacking even more than
programmers is a capable and thrust-worthy sysadmin to overhaul our web
services.


Sven

PS: Could you pretty please learn to spell the name of the program
properly? It is called "GIMP" or "GNU Image Manipulation Program" and
not "Gimp".


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] 6 DOF HID support

[Sven Neumann]

On Sun, 2010-07-18 at 07:55 +0200, Cedric Sodhi wrote:

> I also might want to map Tilt (which GIMP currently has no support
> for)

That is incorrect. GIMP has had support for Tilt for more than ten years
(since before version 1.0). It was limited to the Ink tool though until
recently.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] MIDI messages are not to be translated ? (comment on es translation)

[Sven Neumann]

On Wed, 2010-07-14 at 22:38 +0300, Cristian Secară wrote:
> The comment in the following strings from the Spanish translation
> say that the string should not be translated. Is there a reason for
> this ? (other languages have translated the strings)

If the strings shouldn't be translated, we wouldn't have marked them for
translation.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] where are two strings in practice (from grid.c)

[Sven Neumann]

On Wed, 2010-07-14 at 22:30 +0300, Cristian Secară wrote:
> I like to know where can I see these strings in practice in 2.7.1:
> 
> #. attach labels
> #: ../plug-ins/common/grid.c:717
> msgid ""
> "Horizontal\n"
> "Lines"
> 
> #: ../plug-ins/common/grid.c:719
> msgid ""
> "Vertical\n"
> "Lines"

/Filters/Render/Pattern/Grid


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Question about tools (and other) icons in GIMP.

[Sven Neumann]

On Wed, 2010-07-14 at 22:00 +0400, Эллина Петухова wrote:
> Hello everybody. I want to sorry for my English because it's not my 
> native language and i am not familiar with it.
> 
> Also i am not a serious developer so if i talk something wrong or even 
> bother you please tell me about that.
> 
> Since i migrate to open-source programs  i am using GIMP often and 
> everything is great (and i am very much obliged to you).
> But one thing that has been distracting my attention at work is a bright 
> and coloured icon theme. Searching the way to change them i founded a 
> source code and icons inside in uncompiled form. It seems to be very 
> good and i am tried to change them and compile package.

You can change the icons without changing the source code and without
recompiling GIMP. Just add a gtkrc file that overrides the icons. The
gtkrc format is documented in the GTK+ developer documentation.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Optimized Despeckle plug-in

[Sven Neumann]

On Tue, 2010-07-13 at 22:19 +0200, g...@catking.net wrote:

> I agree. I had to clean up some photos recently and ended up doing most 
> of it by hand.
> 
> If you code produces the same kind of results with that much of a speed 
> increase a patch would be worth providing. Kudos for achieving that 
> level of speed up.

The quality of results also very much depends on how the parameters are
chosen. A speedup of the algorithm will make it easier to experiment
with the parameters as it should also speed up the preview
significantly.

So yes, we should try to get that patch into GIMP as soon as possible.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Optimized Despeckle plug-in

[Sven Neumann]

On Tue, 2010-07-13 at 10:49 +0200, Martin Nordholts wrote:
> On 07/13/2010 10:28 AM, Przemysław Zych wrote:
> > Hi,
> >
> > As a part of my student project for "Optimizing Open-Source
> > Applications" at Warsaw University I have speed up despeckle plug-in for
> > gimp.
> >
> > Original version of the plugin run 56seconds for 1024x768 image with
> > despeckle radius 30 and adaptive flag turned off (on my Intel Macbook
> > 2.1GHz). My optimized version with the same settings completes the task
> > in 3.5 seconds with the same image quality :-)
> >
> > Sources for this optimized plug-in can be downloaded from here:
> > http://students.mimuw.edu.pl/~pz248275/despeckle.c
> > 
> >
> > What should I do to get this to the gimp repository?
> > Should I change the copyright header?
> 
> Hi!
> 
> That sounds great.
> 
> To maximize chances of getting this into GIMP:
> 
> 1. Create a regression test for the despecle plug-in that is run
> with 'make check'. This is a great way to convince us that
> your optimization in fact does not change the output, only
> improves performance.

Well, as far as I can see the current implementation of the despeckle
plug-in does not match the expectations. IMO it is buggy. Thus we should
not absolutely require that the result does not change. But it would be
desirable to get fixes to the algorithm submitted separately from
optimizations.

It would also help a lot if the patch followed the GIMP coding style.
Please see the file HACKING in the GIMP source tree.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] to devs from a translator

[Sven Neumann]

On Thu, 2010-07-08 at 08:58 +0300, LightningIsMyName wrote:

> Sven: I think this should somehow be handled for the future - what's
> the best place to leave a note to developers/commiters that before
> commiting new strings they should add some contexts for their strings?
> If we don't do this, we will have this problem of mis-translation
> continue to appear every time new strings are introduced...

We certainly don't want to do this for any new string that is added. If
you like you can add a note to README.i18n though and suggest that
strings which are likely going to be troublesome should have translator
context added.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] to devs from a translator

[Sven Neumann]

On Wed, 2010-07-07 at 18:41 +0200, Marco Ciampa wrote:
> Please differentiate more the strings.
> 
> For example the "None" string has many meanings in English that in
> Italian correspond to different words. Unfortunately "None" is used in
> many different context so it's difficoult, if not impossible, to give
> the translation the exact meaning that it deserve.

We can easily add context to strings where necessary. The framework for
this is there and it is being used. We just need the translators to tell
us exactly where translation context is needed. Preferably open bug
reports for this.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] possible to announce here an upcoming update ?

[Sven Neumann]

On Thu, 2010-06-24 at 00:50 +0300, Cristian Secară wrote:
> Is it possible to announce with a few days before an upcoming update
> release ? I have missed a translation update for 2.6.9 because I didn't
> know it would happen.

Sorry, not in general. We don't really know in advance when the time has
come for a release. It basically happens when enough bug-fixes have
piled up and I find the time to roll out a release. And that time-slot
doesn't announce itself.

I suggest that you try to push your changes to git as soon as possible.
That's the best way to make it into the next release.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Rotate on the arbitrary line -- feature request

[Sven Neumann]

On Sat, 2010-06-19 at 17:50 +0200, doug p. wrote:
> I had scanned a bunch of small odd shapped images and most of them I couldn't
> get rotated exactly right. I had to use photoshop and they have a feature
> where I can draw a straight line, and say to rotate the image to that line. It
> was called Rotate to Arbitrary. I see a similiar feature in Gimp where I can
> rotate the image, but I can't have it rotate to a line.

The feature, or something very similar, is already present in GIMP. You
select the Rotate Tool and choose "Corrective" as the Transform
Direction in the tool options. Set preview mode to "Grid" and align your
grid with the line on the image that you want to be horizontal. That's
it.

Having this feature exposed with a UI similar to that available in PS
has been suggested every so often. Everyone agrees that it would
probably be a nice thing to add, but so far no one has started to work
on it.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer