Re: [Gimp-developer] Class Diagram

2011-05-22 Thread 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

2011-05-10 Thread 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

2011-03-09 Thread 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

2011-03-05 Thread Sven Neumann
On Tue, 2011-03-01 at 16:42 +, jcup...@gmail.com wrote:
 On 1 March 2011 05:00, Roger Penn roger.p...@gmail.com 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] GIMP developer meeting

2011-02-28 Thread 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 ke...@ve3syb.ca 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] Pencil Tool

2011-02-28 Thread 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 won't quit

2011-02-27 Thread 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 roger.p...@gmail.com 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

2011-02-15 Thread 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] Wrong tools contour

2011-02-03 Thread 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 nao...@gmail.com 
 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] Icon for dynamics

2011-02-03 Thread 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] Photoshop ?compatibility? mode

2011-02-01 Thread Sven Neumann
On Tue, 2011-02-01 at 17:16 +, Michael Grosberg wrote:
 Alexandre Prokoudine alexandre.prokoudine at 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

2011-01-22 Thread 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

2011-01-18 Thread 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] translate menu mod

2011-01-17 Thread 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] donations for GIMP 2.8

2011-01-17 Thread 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

2011-01-13 Thread 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] combo boxes in osx

2011-01-13 Thread 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

2011-01-10 Thread 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


Re: [Gimp-developer] combo boxes in osx

2011-01-10 Thread 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] donations for GIMP 2.8

2011-01-10 Thread 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


[Gimp-developer] donations for GIMP 2.8

2011-01-06 Thread 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?

2010-12-14 Thread 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

2010-12-13 Thread Sven Neumann
On Sun, 2010-12-12 at 10:45 +, jcup...@gmail.com wrote:
 On 7 December 2010 22:07, Sven Neumann s...@gimp.org 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

2010-12-08 Thread 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] unsharp mask

2010-12-08 Thread 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

2010-12-08 Thread 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

2010-12-08 Thread 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] Gimp on OSX, Mac App Store and Funding

2010-12-07 Thread 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

2010-11-21 Thread 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

2010-11-12 Thread 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?

2010-10-30 Thread 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)

2010-10-25 Thread 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

2010-10-23 Thread 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

2010-10-21 Thread 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] LAB in Info Window

2010-10-21 Thread 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] Batch command syntax for calling Python plugins/scripts on Windows XP

2010-10-11 Thread 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

2010-10-10 Thread 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


[Gimp-developer] ANNOUNCE: GIMP 2.6.11

2010-10-04 Thread 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] Fade has a blocking dialog

2010-10-04 Thread 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


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

2010-10-01 Thread 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

2010-09-30 Thread 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 s...@gimp.org
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

2010-09-27 Thread 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!

2010-09-26 Thread 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] shorthanded and outnumbered (Re: Native RAW support)

2010-09-22 Thread Sven Neumann
On Mon, 2010-09-20 at 20:13 -0400,
saulgo...@flashingtwelve.brickfilms.com wrote:
 Quoting Joao S. O. Bueno gwid...@mpc.com.br:
 
  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

2010-09-22 Thread 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] Native RAW support

2010-09-20 Thread 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

2010-09-20 Thread 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] Gracefully handling BPP in a python plugin

2010-09-19 Thread 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] Native RAW support

2010-09-19 Thread 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

2010-09-19 Thread 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

2010-09-19 Thread 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

2010-09-18 Thread 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

2010-09-17 Thread 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

2010-09-14 Thread 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] Drawing per Script

2010-09-13 Thread 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 - optimization tricks

2010-09-13 Thread 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] GIMP paths.

2010-09-10 Thread 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):
 
 polygon fill=rgb(204, 204, 204) fill-opacity=0.5 stroke=black
 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

2010-09-07 Thread 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] Update on LCH layer modes

2010-09-06 Thread 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] Nightly builds with buildbot, where can we host?

2010-09-06 Thread 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] Bucket-fill the selection in a python plugin

2010-09-06 Thread 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] GPU-accelerated Image Filtering w/ CUDA

2010-09-04 Thread 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

2010-09-02 Thread 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 Image/File/Acquire and are being mapped to
Image/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

2010-08-31 Thread 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] Getting new layer modes fit for inclusion

2010-08-30 Thread 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] Patch shortening GIMP startup time

2010-08-30 Thread 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] Newbie startup problems

2010-08-28 Thread 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

2010-08-28 Thread 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] (no subject) plus dockables

2010-08-28 Thread 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

2010-08-26 Thread 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] (no subject) plus dockables

2010-08-26 Thread 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] scanner support should be File-Acquire

2010-08-25 Thread 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] scanner support should be File-Acquire

2010-08-25 Thread 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
Image/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] Closing Command Line Window in Batch Mode (Windows

2010-08-25 Thread 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 - Press any key to exit

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] Getting new layer modes fit for inclusion

2010-08-24 Thread 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] Getting new layer modes fit for inclusion

2010-08-24 Thread 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] Alignment-Tool Guides

2010-08-23 Thread 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

2010-08-22 Thread 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

2010-08-06 Thread 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)

2010-08-05 Thread 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

2010-08-03 Thread 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

2010-08-02 Thread 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

2010-07-31 Thread 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

2010-07-31 Thread 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

2010-07-27 Thread 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

2010-07-22 Thread 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

2010-07-20 Thread 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] Question about tools (and other) icons in GIMP.

2010-07-14 Thread 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] where are two strings in practice (from grid.c)

2010-07-14 Thread 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

Image/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] MIDI messages are not to be translated ? (comment on es translation)

2010-07-14 Thread 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] Optimized Despeckle plug-in

2010-07-13 Thread 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
  http://students.mimuw.edu.pl/%7Epz248275/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] Optimized Despeckle plug-in

2010-07-13 Thread 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] to devs from a translator

2010-07-08 Thread 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] possible to announce here an upcoming update ?

2010-06-24 Thread 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] How to edit context menu?

2010-06-19 Thread Sven Neumann
On Sat, 2010-06-19 at 23:49 +0800, Bear wrote:
 hi,
 Er... but my work is to make it popup something like a new window instead the 
 original context menu... Could you help me? thx!

Are you familiar with GTK+? If not, please read the documentation and
tutorials before you ask here. We can certainly help you with GIMP
specific questions, but I get the impression that you are lacking some
fundamental GTK+ knowledge that is absolutely essential for what you are
trying to achieve.


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

2010-06-19 Thread 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


Re: [Gimp-developer] Merchandizing for the GIMP.

2010-06-09 Thread Sven Neumann
On Tue, 2010-06-08 at 16:32 +0200, Simon Budig wrote:
 Hi all.
 
 At LGM we threw some ideas around for Gimp-Merchandizing.

Since I haven't been at LGM, I have trouble to understand the motivation
for doing GIMP merchandising.

You are certainly not doing this for the money, are you? We have a
steady flow of donations coming in and basically nothing to spend this
money for.

Perhaps someone can explain why the GIMP developers should even care
about merchandising. There are other parties who are interested to do
GIMP merchandising (freewear.org for example) and willing to organize
all of it. This failed because we aren't even capable of adding a link
to their products on the gimp.org web-site. What makes you think that it
would work better if we did this all by our-selves?


Sven


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


Re: [Gimp-developer] Gimp UX: Paste

2010-06-03 Thread Sven Neumann
On Thu, 2010-06-03 at 13:45 -0400, Rob Antonishen wrote:

 I bound this to ctrl-v and played for a while and it feels pretty
 intuitive.  One feature is that if you make a selection and go
 ctrl-x, ctrl-v it pastes the cut out bit exactly where it was cut out
 from, which makes sense.

That is what GIMP has been doing all the time, right ?


Sven


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


Re: [Gimp-developer] comparison of enlargements produced with two GIMP methods, three GEGL methods, and three candidate GEGL methods

2010-06-03 Thread Sven Neumann
On Wed, 2010-06-02 at 23:49 -0400, Nicolas Robidoux wrote:
 I have created 6.11x enlargements with two GIMP methods, three GEGL
 methods, and three candidate GEGL methods for which patches are
 provided in
 
 https://bugzilla.gnome.org/show_bug.cgi?id=619314
 
 The enlargements, named a.png to h.png, are found in the 15M tar archive
 
 http://web.cs.laurentian.ca/nrobidoux/misc/catenlargementtests.tgz
 
 To know which method was used to produce each image, read the KEY text file.

One thing I noticed when looking at these images is that the GEGL ops
all create a black border at the bottom-right edges. Is that something
you are aware of and expect to get fixed ?


Sven


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


Re: [Gimp-developer] Gimp UX: Paste

2010-06-03 Thread Sven Neumann
On Thu, 2010-06-03 at 21:01 +0100, Chris Mohler wrote:
 On Thu, Jun 3, 2010 at 8:47 PM, Sven Neumann s...@gimp.org wrote:
  I bound this to ctrl-v and played for a while and it feels pretty
  intuitive.  One feature is that if you make a selection and go
  ctrl-x, ctrl-v it pastes the cut out bit exactly where it was cut out
  from, which makes sense.
 
  That is what GIMP has been doing all the time, right ?
 
 Yes, as long as the selection remains.
 
 Selecting nothing and copy+paste also pastes the layer in place -
 unless you select a layer with a different size before pasting.  For
 example, copying a 300px wide layer, selecting a 600px wide layer and
 pasting centers the floating selection.  I'd prefer it pasted in the
 original position in this case - but this is only my opinion.

Well, then we'd have to attach the original coordinates to the clipboard
somehow. This information is not kept currently.


Sven


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


  1   2   3   4   5   6   7   8   9   10   >