Re: [Gimp-developer] The name Gimp

2009-10-30 Thread Nathan Summers
On Fri, Oct 30, 2009 at 6:26 PM, Christopher Howard chow...@indicium.us wrote:

 People keep saying the original developers named it GIMP and that is
 that. Every heard, though, of the original name of the Linux OS?
 Torvalds wanted it called Freaxs. Fortunately, though, the name Linux
 stuck, and even Linus admitted this was better.

Furthermore, if the original developers still prefer the name GIMP,
they are entitled to their own fork!

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


Re: [Gimp-developer] We should go for a single-window mode in 2.8

2009-09-29 Thread Nathan Summers
On Mon, Sep 28, 2009 at 11:56 AM, Cole cole.ans...@googlemail.com wrote:
/ For developers: CurlyAnkles gtk+ lib has tab/tile widgets I'm talking
 // about: URL.
 /
 Eeek, here is the missing URL:
 http://curlyankles.sourceforge.net/widgets_docking.html

 Alexandre

 Hello,

 I think the term single-window mode is potentially confusing.
 It's how you dock the windows together that gives the user the
 *perceived* single-window or multiple-window mode.

I'm still thinking GIMP could benefit from Eclipse-style
perspectives, where which dialogs are visible and which are hidden
are user-defined sets that can be switched between.  The user can then
define which dialogs are useful for certain commonly occurring tasks
and quickly switch between them.  It takes a little getting used to at
first, but once you understand the paradigm you never want to go back
to managing individual windows.

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


Re: [Gimp-developer] Using parasites in script-fu

2009-02-19 Thread Nathan Summers
On Thu, Feb 19, 2009 at 9:05 AM, Rob Antonishen
rob.antonis...@gmail.com wrote:

 Is this enough information that I should create a bug tracker entry?

Definately!

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


Re: [Gimp-developer] Gimp license

2009-01-12 Thread Nathan Summers
On Fri, Jan 9, 2009 at 2:49 PM, Michael Natterer mi...@gimp.org wrote:

 So finally, I hereby suggest to move to GPL3 asap.

 Comments from any developers appreciated.

The sooner the better as far as I'm concerned.

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


Re: [Gimp-developer] Splash proposal for 2.6

2008-09-23 Thread Nathan Summers
On Mon, Sep 22, 2008 at 7:41 PM, Joao S. O. Bueno [EMAIL PROTECTED] wrote:
 On Monday 22 September 2008, Aurore D. wrote:
 Hello,

 A while ago Jimmac asked me if I could try to work on a splash screen
 for GIMP 2.6.
 I did several proposals, and here is the one that has the preference:
 http://aurore.d.googlepages.com/splash_proposal

 Tell me what you think :)

 Cheers,

 Hi.

 Sorry -
 This is a beautiful image, but I don't think it would do a great splash
 screen.

Maybe it would make a good about box image.

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


Re: [Gimp-developer] Gimp natively on mac OS X

2007-03-26 Thread Nathan Summers
On 3/26/07, Michael Natterer [EMAIL PROTECTED] wrote:
 On Sat, 2007-03-24 at 19:52 -0400, M. Gagnon wrote:
  Hi everyone,
 
  i just thought i would report my sucess of building Gimp on mac OS X with
  native GTK+ port by Imendio
  (http://developer.imendio.com/projects/gtk-macosx).
 
  Overall the process was not too hard, i however had to change a makefile at
  one point. The one located in /app/Makefile contains a line 'munix =
  -Wl,-rpath '-Wl,$$ORIGIN/../lib'' - this line is incompatible with mac OS X
  because it uses Apple's ld, not GNU's. I just made munix empty and
  everything built fine. Do you think makefiles can be adapted to be
  cross-platform or do you support only linux?

 That's odd, since I have to change *nothing* in any of the source
 packages to get the entire toolchain plus gimp build on OS X.

 I can't look into that right now but will do as soon as I have
 access to my apple machine again,

Perhaps the difference is due to a different version of one of the
autofoo tools, or a different version of XCode.

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


Re: [Gimp-developer] The GIMP

2006-12-06 Thread Nathan Summers
On 12/6/06, Sven Neumann [EMAIL PROTECTED] wrote:
 Hi,

 I'd like to do the following change to the comment at the top of all
 source files in the GIMP tree:

 -/* The GIMP -- an image manipulation program
 +/* GNU Image Manipulation Program

 Any objections?

No objections personally, but if I recall correctly, the new comment
violates some inconsenquential part of the GNU coding standards, if we
care about them.

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


Re: [Gimp-developer] Win32: Invoking a GIMP plug-in using a batch file

2006-09-15 Thread Nathan Summers

On 9/15/06, Massimo Perga [EMAIL PROTECTED] wrote:



Hello All,
  I'm currently working on GIMP# development, and the plug-ins so generated 
under
Windows use the .exe file format. In such a way, we're forced to use the 
Microsoft .NET
platform but, for debuggining purposes, we'd want to use the Mono platform: 
this can be
accomplished using the command

mono pluginname  $@

Under Linux it can be done writing a proper script file invoking the plug-in, 
but is it
possible to do the same under Win32 using a batch file ? If so, could you 
please write
me in which way I should invoke it ?


It can probably be done with a wrapper batch file similar to the one
above, with the caveat that you'd need to keep the .exe file in a
different directory not searched by gimp in order for the .bat to not
conflict with the .exe.

A better solution for debugging is probably to use the environment
variables GIMP already has for the purpose of running plug-ins under
debugging wrappers.  See http://developer.gimp.org/debug-plug-ins.txt
for more information.

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


Re: [Gimp-developer] GIMP plug-in disabled.

2006-09-12 Thread Nathan Summers

On 9/12/06, Dream Artist Aspiring [EMAIL PROTECTED] wrote:


Hi all, I am very new to gimp and it's development. I am trying to learn 
gimp-plugins. I can run the plugin fine for the first using  the Xtns-... 
menu. But if I want to run the same plugin for second time, the menu entry is 
disabled. Is there something that I am doing wrong? please let me know. Thanks 
much in advance.

HERE IS MY CODE:
---
static void
run (const gchar  *name,
 gint  nparams,
 const GimpParam  *param,
 gint *nreturn_vals,
 GimpParam   **return_vals)
{

  static GimpParam  values[1];
  GimpPDBStatusType status = GIMP_PDB_SUCCESS;

  gint32 SImg, SLay;

  /* Setting mandatory output values */
  *nreturn_vals = 1;
  *return_vals  = values;

  values[0].type = GIMP_PDB_STATUS;
  values[0].data.d_status = status;

  SImg = gimp_image_new(720,720,GIMP_RGB);
  SLay = gimp_layer_new(SImg, Layer1, 720, 720, GIMP_RGB_IMAGE, 100, 
GIMP_NORMAL_MODE);
  gimp_image_add_layer(SImg, SLay, 0);
  gimp_drawable_fill(SLay, GIMP_BACKGROUND_FILL);
  gimp_display_new(SImg);
  gimp_displays_flush();

  return;
}


I don't see anything obviously wrong with this code, but you left out
the registration part.  I'm going to guess that you registered this as
an extension and not as a plugin.  That might cause the symptoms you
describe.  (This is one of several reasons why Xtns is a bad name for
that menu.)

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


Re: [Gimp-developer] PixelRegions?

2006-06-17 Thread Nathan Summers

On 6/16/06, Frédéric [EMAIL PROTECTED] wrote:

On Friday 16 June 2006 21:41, Michael Thaler wrote:

 Can someone explain to me why the code iterates over all pixels in a
 region and then over all regions and not just over all pixels in a
 layer? What are PixelRegions actually, what are they used for and why
 they are needed here? (I had a look at
 http://developer.gimp.org/api/2.0/app/app-pixel-region.html but this
 doesn't explain what they are for)

As far as I understand, a region can be what you want; it can cover a
entire layer, or just a small part (like the preview for plug-ins. Have a
look here:

http://developer.gimp.org/writing-a-plug-in/2/index.html

When you have initialized a region, you can access it pixel by pixel, row
by row, or tile by tile, depending what you want to do (I guess each
method has advantages, according to the filter you want to write).


I think it's important to mention that if your algorithm supports it,
using pixel_regions_process () or the new gimp_rgn_iterate() functions
is by far the easiest and best performing way to use pixel regions.
If you use them on more than one pixel region, the regions are
registered such that through each iteration, all of the regions are
pointing to the same part.  This makes operations like copying from
one layer to another a snap to write.  You might want to look at
tile.c or threshold_alpha.c in the plug-ins/common directory for some
examples.

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


Re: [Gimp-developer] new default icon theme proposal

2006-06-15 Thread Nathan Summers

On 6/15/06, Jakub Steiner [EMAIL PROTECTED] wrote:


Hi GIMP developers,
I write to propose a new default icon set for GIMP 2.4. As GIMP is a
multiplatform application it will in my view benefit greatly from an
icon set that follows the Tango style guidelines.

You can preview the looks of the new GIMP icon set here:

http://jimmac.musichall.cz/screenshots/gimp-light-tango.png
http://jimmac.musichall.cz/screenshots/gimp-dark.png

http://jimmac.musichall.cz/stuff/libgimpwidgets/libgimpwidgets-GimpStock.html


I really like them.  They seem a little more distinct from each other
than the old ones did, which will make it faster to recognize them.
The new eek icon is fantastic.

The only concern I have is the small Wilbers.  They seem very square.
While it's true that Wilber is somewhat more linear than a true
organic shape would be, he still is much more more rounded than the
small icons appear.

Will you be planning to create a grayscale version as well, or would
it be better to stay with the existing grayscale version for our users
that prefer desaturated icons?

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


Re: [Gimp-developer] core plugin concept

2006-06-09 Thread Nathan Summers

On 6/8/06, Olivier Ravard [EMAIL PROTECTED] wrote:

Hi,

I have a question for core developers about plugins :

How are the images and other parameters passed to (C++) plugins ?
via network or via the file system ?


Gimp plugins communicate with the gimp process through pipes.  Image
data is shared between the plugin and the gimp process using shared
memory if available, otherwise it is sent through the pipe.


Is there any documentation about the gimp plugins concept (I don't want
documentation on how to build a plugin for gimp) ?


IIRC, the original (pre-gimp.org) website maintained by S  P had a
bit on how they work.  You might be able to find an archived version
of that site somewhere.  http://developer.gimp.org has the gtkdoc for
the applicable classes.  But really the best way to understand it is
to look at the code itself.  It's not that difficult of a read.  Off
the top of my head, I seem to recall that the names of the files most
involved are gimpplugin.c, gimpprotocol.c and gimpwire.c.

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


Re: [Gimp-developer] Cancel function and plugins

2006-06-07 Thread Nathan Summers

On 6/7/06, Toby Speight [EMAIL PROTECTED] wrote:

(Delurk: I'm a sporadic developer of plugins, some of which are almost
good enough to shove in the registry, and I've watched this list for a
few months)

One of my current projects is a multifrequency blend tool (inspired
by, but not based on, the enblend program), and as part of its
operation, it invokes a couple of other plugins (I don't see the point
in reinventing wheels!).

One thing that's not covered in any of the how to write a plugin
guides is how to poll for cancel.  Of course, the plugin could have
its own cancel button, but then the user would have to know which
sub-plugin is running and find the correct cancel button!  (I'm happy
to deal with the call to the sub-plugin returning GIMP_PDB_CANCEL).

So - how does a plugin poll the Gimp's cancel button?  I couldn't find
any examples in the src/plug-ins directory...


Cancelling a plugin kills it unconditionally.  It's been a few
months since I looked at that code, but I'm fairly sure that there is
no way for a plug-in to catch that it's been cancelled.

You really should check the value of each pdb call you make and make
sure that the return value is GIMP_PDB_SUCCESS.  There is almost
certainly code out there that doesn't check the return value and just
assumes nothing wrong happened, but that doesn't mean it's the right
thing to do. :)

Which gives me an idea for a simple macro that causes the function to
return GIMP_EXECUTION_ERROR when given an error status, and does
nothing otherwise.

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


Re: [Gimp-developer] Getting the GIMP to work well on a OLPC laptop

2006-06-06 Thread Nathan Summers

On 6/6/06, Dave Neary [EMAIL PROTECTED] wrote:

 a small screen laptop


Am I the only one that sees a conflict between GIMP and small-screen?

:)

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


Re: [Gimp-developer] New microsoft image format

2006-05-27 Thread Nathan Summers

On 5/27/06, Michael Natterer [EMAIL PROTECTED] wrote:

On Sat, 2006-05-27 at 08:08 +0100, Alan Horkan wrote:

 (Frankly I'm more interested in XPS/Metro which attempts to replace PDF,
 and XAML/WVG/Avalon/whatever-they're-calling-it-this-week attempt to
 replace SVG.)

Really? I'm not interested at all. Zero percent.

To me that looks like the usual M$ attempts to replace
just about anything that other people have done.

It's already ambivalent to have GIMP running on windows
at all, I'm not interested in taking this any further
by supporting these formats, and thereby supporting M$.
The free software community doesn't get any support from
them either.


Plus the fact that M$ submarine patents are no idle threat.  I'm very
wary of M$ geeks baring gifts, especially when they explicitly don't
grant patent licenses in the legalease.

Anyway, all this reminds me that I started writing a pdf output plugin
a while ago.  Maybe I should dust it off this three-day weekend.

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


Re: [Gimp-developer] New microsoft image format

2006-05-26 Thread Nathan Summers

On 5/26/06, Alan Horkan [EMAIL PROTECTED] wrote:


If you hit the Do not agree option it will still let you read the
specifications without agreeing.  I expect they'll change that soon
though.


Is there anything interesting in there?

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


Re: [Gimp-developer] New microsoft image format

2006-05-25 Thread Nathan Summers

On 5/25/06, Joao S. O. Bueno Calligaris [EMAIL PROTECTED] wrote:

Just missing the deadline for a SoC sponsored plugin for it,
microsoft released the specs for their new image file format here:


http://www.microsoft.com/whdc/xps/wmphoto.mspx

I di dnot download it, bu I read the agreement for ownlaoding it. One
keep his soul and his mother in doing so. I mean- there is no nasty
NDA, it seems possible to implement a free software  as fara s
copyright issues stand, for reading and writing the beast - but the
nDA says that software patents involving that owned by MS still
apply.

They announce  a lot of miracles for this format, and it would be nice
to be able to read and write to it if half of then hold true.


They lost me with the first sentence of the first clause:
You may review these Materials only (a) as a reference to assist You
in planning and designing Your product, service or technology
(Product) to interface with a Microsoft product, specification,
service or technology (Microsoft Product) as described in these
Materials; and (b) to provide feedback on these Materials to
Microsoft.

Talk about a viral license!  If you design your own format that uses
features similar to this format, you're breaking the agreement.  Or if
you do a review of it.  Etc.

Hypocritically, while Microsoft gives you no patent license, if you
make a suggestion to them, they automatically get a patent license
from you.  Really, the lack of patent licenses is very disturbing,
especially given MS's anti-GPL stance.

Oh, and oddly enough, if you read this spec as part of your job and
the company you work for gets bought out, you have to agree to destroy
all your copies of the specification.  That's fun.

All I can say is that it's too bad that the text box that the license
shows up in isn't editable. :)

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


Re: [Gimp-developer] Summer of Code

2006-05-07 Thread Nathan Summers

On 5/7/06, Michael Schumacher [EMAIL PROTECTED] wrote:

elf wrote:

 Well, today is 7 may and for registration I have only 1 day. So, I
 would like to know answer for my question: if I can develop this
 module in the context Summer of Code?

Right now, my answer would be no. This looks like yet another edge
detection filter.


True, although it seems like a better edge-detector than anything we
have so far.


This might be caused by mutual problem with the english language - from
your description, there seems to be much more than is visible in the
example images, almost like you're trying to convert an image to a
vector representation with the ability to restore the bitmap image (the
parameters your were talking about?).

You should show us why your approach it is outstanding - for example,
how it performs in comparison to other edge detection filters in GIMP.
Also, a short summary of possible uses (image analysis?, image
recognition?) would help us to understand what a user can do with your
approach.

Please submit your application to Google, and try to include anything
make makes it possible to understand what you're going to do.


One thing you might consider is that it appears that you already have
working code, and in that case, converting that working code into a
working GIMP plugin is usually a fairly straightforward process that
is far less work than the scope of a typical SoC project.  If there is
a way you can think of broadening your proposal, it would help.  You
obviously have the education and experience that is most useful in a
GIMP collaborator.

There are several example projects you might be interested in tackling
alongside converting your code into a GIMP plugin.  Perhaps one of
those captures your imagination.  Some of them involve plug-ins, so
would be a natural tie-in.

You also might want to propose doing some work in translating the GIMP
UI and/or help into your native language.  While pure documentation
work is not allowed by Google, I see nothing that forbids *any*
documentation work, and depending on the state of the translation of
gimp into your native tongue, it could be a great help to us.  Still,
if you do that, I suggest that you make at least one other proposal
(Google allows you up to 20!) in case it gets disqualified.

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


Re: [Gimp-developer] Accepted plug-in development for Google SoC ?

2006-04-21 Thread Nathan Summers
On 4/21/06, Pedro Alonso [EMAIL PROTECTED] wrote:
 Hello,

 I would like to develop a plug-in for The Gimp, but I don't know if it
 would be accepted as Google SoC project or need to be a contribution
 to the core of the program.

Depending on the nature of the plugin, it could very well be accepted
as part or all of a SoC project.

 If it were possible my purpose is:
 - Implements the algorithm based on the paper capturing a black cat
 in shade:  past and present of Retinex color
 appearance models

That paper doesn't appear to be online.  Could you provide a summary
of the algorithm and its effects?

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


Re: [Gimp-developer] GIMP and Google SoC

2006-04-21 Thread Nathan Summers
On 4/21/06, Sven Neumann [EMAIL PROTECTED] wrote:
 Hi,

 another thing that came to my mind:

 - Add a (unit) testing framework and tests to GIMP.

 Details are left out for now but the idea is to get more unit tests
 and to make it easier to add and maintain them. But also to have more
 complex test scripts that perform GIMP operation using the PDB. These
 scripts would be run on a set of test images and the results would be
 compared against a set of output images. The test framework should
 also allow to easily test functionality of a certain plug-in. This way
 errors could easily be spotted and it would make changes to plug-ins a
 lot safer. Such tests could also be used as benchmarks to help with
 optimizations.

 Should we try to turn this into a more detailed proposal?

This sounds like an excellent idea.

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


Re: [Gimp-developer] PDF import

2006-04-21 Thread Nathan Summers
On 4/20/06, Dalai Felinto [EMAIL PROTECTED] wrote:
 Hi,
 I'm using the GIMP 2.2.11 in the Windows XP.

 To import PDF I've downloaded the ghostscript interpretor at -
 http://www.cs.wisc.edu/~ghost/doc/AFPL/get850.htm
 and is working perfectly. (remember to make a copy of the executable file to
 the gimp\bin directory)

 I have some questions and suggestions:
 1) What is the difference between the new PDF import plug-in based on
 libpoppler and the gs?

The new plugin uses poppler, which is based on the same code that xpdf
uses.  The older plugin used gs's pdf reading support.  Poppler is
usual faster; which renders more accurately seems to be a matter of
opinion.  The new plugin definately has a better user interface.

 2) Why the link above isn't in the GIMP for Windows page?

It probably should be.  *makes silent guestures suggesting that the
gimp web team take note*

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


Re: [Gimp-developer] Re: GIMP and Google SoC (from digest)

2006-04-21 Thread Nathan Summers
On 4/19/06, GSR - FR [EMAIL PROTECTED] wrote:
 Hi,
 [EMAIL PROTECTED] (2006-04-19 at 1158.08 +0200):
   How is this fairly straightforward with the current architecture? I
   would rather say that it is currently almost impossible to implement
   sanely.
  Ah, but I'm insane.
  Add a layer type for effect layers, and define 3 operations that you can
  associate with the layer (to start): curves, levels and colour balance.
  All the operations are pixel-by-pixel, which should make things easier.
  Then hack the projection code to add a special case for an effect layer.

 Internally I would say they are blend modes. Make them special so
 content is fixed and flat (better compression), so only layer mask
 matters. Then make the formula for the blend mode be curves, levels,
 colour balance... whatever you can find that is pix to pix (and
 probably LUT based in many cases, if not all) and make it work in BG
 while the FG is unused. The settings would be stored in a parasite.

Excellent idea.  Unfortunately, when people say they want layer
effects most of the time what they mean is that they want spiffy
auto-drop shadows.  Of course, that's not that hard to represent with
a few parameters.  But it's not exactly something you can implement
with a LUT.  Still, I think it's pretty doable as a custom layer. 
Perhaps implementing some as blend types and some as custom layers is
a good plan.

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


Re: [Gimp-developer] Customzing GIMP

2006-04-17 Thread Nathan Summers
On 4/17/06, digi artist [EMAIL PROTECTED] wrote:
 Thanks Al,

 All I really want to do is to hide some menu items (especially when the
 picture has been opened) and rename some items on the 'Filters' menu.
 period.
 I would really appreciate your help.

Actually, we would be interested in hearing your input on how the menu
items can be improved in general.  One of the goals for the next
version of GIMP is to have better menus.

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


Re: Project proposal: Resource contribution, distribution and management system (was: Re: [Gimp-developer] Google Summer of Code 2006, to whom it may concern)

2006-04-17 Thread Nathan Summers
On 4/17/06, Michael Schumacher [EMAIL PROTECTED] wrote:

 The programming language of choice would be Python. PHP and Perl are
 frowned upon by many GIMP developers, and Python can also be used for
 the second part of the project.

PHP is frowned upon, perhaps, but it's news to me that perl is frowned
upon by many gimp developers, especially considering how much it's
used in various little scripts in the gimp build process.  At any
rate, I say as long as it's reasonably portable and sufficiently
scalable, why limit ourselves?

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


Re: [Gimp-developer] Re: [Gimp-user] `Bucket fill' ..

2006-03-28 Thread Nathan Summers
On 3/27/06, Sven Neumann [EMAIL PROTECTED] wrote:
 Hi,

 Gerald Friedland [EMAIL PROTECTED] writes:

  True. As long as you have got an appropiate selection too, you could
  select the object, fill it, and you are done. A natural bucket fill
  would just be a short cut to this process.

 Do we really need the overhead in code and complexity to achieve
 something that can be easily done in two steps? I think that using the
 selection tools followed by a fill is the natural way to achieve the
 desired effect and it is also a lot more flexible than a dedicated
 tool.

Maybe I'm not understanding what's wanted here, but I get the
impression that they're talking about a tool that you could use to
e.g. change the color of a shirt someone is wearing without loosing
the lighting and shading.  That would be a pretty cool tool to have,
and I can imagine a decent algorithm for doing it, but I can't think
of a reasonable way to do it with the existing tools.

 If someone wants to put effort into a specialised tool, maybe it could
 be a red-eye-removal tool because that is really an often requested
 feature and it is not easily achievable using a combination of the
 existing tools.

Again, yes, a useful tool.  But I think that before we go about making
more tools, we finally implement pluggable tools.  To avoid the
problems we had last time, I suggest that we come up with a sane tool
API, implement it in the core, port several tools over to it, and then
after it's fairly stable worry about finding a way to do things
out-of-process.

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


Re: [Gimp-developer] Bring Back the Keyboard!

2006-02-13 Thread Nathan Summers
On 2/13/06, Scott [EMAIL PROTECTED] wrote:
 On Sat, Feb 11, 2006 at 01:25:21AM +, Alastair M. Robinson wrote:
 
  Ironic, isn't it, that a UI simplification intended to make newbies more
  comfortable results in me resorting to the shell...

 I wonder; are we witnessing the coming-of-age of a new generation of
 programmers who grew up *not* using the shell, and who therefore
 overlook the importance of shell-like features in the GUI?

It would be ironic if that were the case.

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


Re: [Gimp-developer] Re: [Gimp-user] Problems compiling GIMP

2006-02-13 Thread Nathan Summers
On 2/11/06, Axel Wernicke [EMAIL PROTECTED] wrote:
 Am 11.02.2006 um 15:14 schrieb Scott:
  Am 11.02.2006 um 05:43 schrieb Scott:

  I ran it with --disable-mmx, now ld does not support the -rpath
  switch on
  OS X. And there does not seem to be an option to disable it in the
  configure, at least that I found .

So am I to take it that this is an issue with libtool on OS X?  Does
it work with newer/older versions of libtool?  Is this problem
specific to MacOS on x86?

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


Re: [Gimp-developer] GAP translation

2006-01-13 Thread Nathan Summers
On 1/13/06, Fabrizzio Mellerti [EMAIL PROTECTED] wrote:
 Hi:

 I think I found this bug with the GAP. The menus doesn't translate if the 
 system where is
 installed is not where orignially was compiled. I'd like to help to fix this 
 bug, but I need
 someone to point me where to start

Are you installing the .po files as well?

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


Re: [Gimp-developer] [SCM] text file management

2006-01-11 Thread Nathan Summers
f

On 1/10/06, Sven Neumann [EMAIL PROTECTED] wrote:
 Hi,

 Fab Psycho [EMAIL PROTECTED] writes:

   I'd like to write in a text file from a scm plugin.I didn't see
   any relevant fx in gimp function browser... Someone could give
   me a sample source for file opening, writing and closing ?

 From the SIOD reference:

  (fopen path mode)

   Opens the file and returns a file stream.


  (fwrite data stream)

   Write the data, a string or byte-array to the stream. Or data can also
   be a list of a string or byte-array and a numerical length.


  (fclose stream)

   Closes the open file stream.

Hmm, interesting.  I couldn't get this to work with script-fu under
1.2, but it seems to work fine under 2.2.

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


Re: [Gimp-developer] [SCM] text file management

2006-01-10 Thread Nathan Summers
On 1/9/06, Fab Psycho [EMAIL PROTECTED] wrote:
 Hi,

  I'd like to write in a text file from a scm plugin.I didn't see any
 relevant fx in gimp function browser... Someone could give me a sample
 source for file opening, writing and closing  ?

Script-Fu isn't capible of doing this.  If you haven't checked out
tiny-fu, you probably should.

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


Re: [Gimp-developer] compiling gtk programs on cygwin

2005-12-23 Thread Nathan Summers
On 12/23/05, Hari [EMAIL PROTECTED] wrote:
 Hi,

  I am trying to compile GTK applications on cygwin to produce

 a windows exxecutable. However, I am unable to free the executable
 produced from some sygwin dlls which doesn't allow me to open
 this on windows..

You need to use mingw in order to produce executables that don't
require cygwin.  If you have the mingw package for cygwin, you can
compile/link with mingw by passing CC the -mno-cygwin flag.  There is
also a mingw development environment called MSYS that is very popular.

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


Re: [Gimp-developer] color balance (preserve luminosity) bug

2005-12-16 Thread Nathan Summers
On 12/14/05, Jon Niehof [EMAIL PROTECTED] wrote:
 --- sean [EMAIL PROTECTED] wrote:

  Why would it not be:
 
  L = (R + G + B) / 3

 Because 255 blue is dimmer than 255 green. NTSC standard:
 Gray scale intensity = 0.299R + 0.587G + 0.114B

True, although unless you are coding for a 1960's color television,
it's probably better to use the sRGB/ITU-R 709 formula: Y = 0.2126R +
0.7152G + 0.0722B.

If you're really interested, the finer points of color are explained
at http://www.poynton.com/notes/colour_and_gamma/ColorFAQ.html

Rockwalrus

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


Re: [Gimp-developer] P.S.

2005-12-11 Thread Nathan Summers
On 12/9/05, Carol Spears [EMAIL PROTECTED] wrote:
 On Fri, Dec 09, 2005 at 08:12:01PM +, Chris Share wrote:
  I forgot to mention I'm working on Windows.
 
 i don't think that you get one then.

There is a gimptool for windows.  If you don't build gimp yourself, it
might be available in the hard-to-find gimp development package for
windows.

 gimptool only provides the information about where the files are on your
 computer.  i think (and they reminded me of this on the irc today) that
 being able to use a Makefile would eliminate the need for gimptool.

This is true.  Gimptool is only a convenience.  But if you are going
to develop on windows, you definately need msys, a bunch of developer
packages for gtk, gettext, etc, and the gimp developer package.

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


Re: [Gimp-developer] Looking for sources

2005-11-30 Thread Nathan Summers
On 11/30/05, Pierre Bucher [EMAIL PROTECTED] wrote:
 Hi.

 I don't know if I'm sending this to the right mail-list, but I would
 be really happy to get any help.

 I'm a french student preparing a study on the un-continous geometry
 and I would like to find some source code of real programs drawing
 lines, circles or ellipses in order to be abble to give exemples of
 reals applications during my presentation ...
 I would also be very happy to find some people abble to explain me how
 some programs are performing rotations ...

I'm not sure exactly what you mean by un-continous, but assuming you
mean rasterized graphics, there is far too much information to explain
in an email-message. Computer Graphics: Principles and Practice by
Foley and van Dam is the typically suggested book for learning
computer graphics.

In particular, you probably will be interested in Bresenham lines and
circles, which are discussed practically anywhere graphics are taught.
 They are two simple and clever algorithms, and I'm sure you can find
source code for them on the web.  Note that they are not anti-aliased;
they will not look as good as anti-aliased methods.

Two GIMP-related libraries that implement this kind of thing are
libart and cairo.  You can find information on how to get them on the
web.

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


Re: [Gimp-developer] cvs-version install(?) problem - please help

2005-11-29 Thread Nathan Summers
On 11/29/05, Helmut Jarausch [EMAIL PROTECTED] wrote:

 Yes, thanks. So the next questions is about a high level changelog.

That is more-or-less what the NEWS file is supposed to be.

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


Re: [Gimp-developer] PATCH: Oilify plug-in enhancements

2005-11-23 Thread Nathan Summers
On 11/23/05, Daniel Richard G. [EMAIL PROTECTED] wrote:

 chinrub
 Now, I'm idly thinking... how feasible it would be to have an option
 allowing a separate image to control Oilify's mask size, so that some areas
 could come out more detailed in the oil painting, and others less so
 /chinrub

That would be great to have.

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


Re: [Gimp-developer] Font Hinting in PDL

2005-11-22 Thread Nathan Summers
On 11/22/05, Iain Kennedy [EMAIL PROTECTED] wrote:

 I'd like to submit a patch to bugzilla of this and get some feedback, but
 I'm having a little trouble generating the patch file from the CVS in that
 I'm not sure how to clean the source before generating the patch, so that
 the automatically generated files are not included in the patch.

You can remove the autogenerated file from the patch using a text
editor.  That's probably the easiest thing to do.

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


Re: [Gimp-developer] GIMP 2.3.4

2005-09-28 Thread Nathan Summers
On 9/28/05, Carol Spears [EMAIL PROTECTED] wrote:
 On Wed, Sep 28, 2005 at 07:56:12AM -0500, Lance Dockins wrote:
 do not count on the user base being only as you defined it here.

 if you do not want sarcasm or even honest requests for good development
 style, please post these questions on either the gimp user list or the
 gimp on windows user list.

There is no longer a gimp on windows mailing list, and this isn't a
user list question.

 the project historically does not want the type of help you described.
 only if you believe everything that you read is this not still the case.

What?  Customer service is exactly the type of thing that we need help with.

Rockwalrus
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] GIMP 2.3.4

2005-09-28 Thread Nathan Summers
On 9/28/05, Michael Schumacher [EMAIL PROTECTED] wrote:
 Nathan Summers wrote:

  There is no longer a gimp on windows mailing list,

 Well, for a list that doesn't exist it is pretty active...
 http://groups.yahoo.com/group/gimpwin-users/

That is not the list that no longer exists.  :)

Rockwalrus
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Average Face / Photo blending for large number of pics

2005-09-14 Thread Nathan Summers
On 9/14/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
 Greetings :)
 
 I would like to be able to take a group of head
 shots (photo of just the face of a person) from
 different peopleand then stack or blend them
 so that one average face results.
 
 To be clear...there may be hundreds of individual face
 shots that we want to stack or blend (not sure
 what the right term is)...and the end result would be
 one facethat would then be the average of all
 the faces in the stack.
 
 This is different than standard morphing in which
 the final outcome is simply the last image in the
 stack. Again, we want the average face effecta
 true blend of all of the individual stacked images
 as our outcome.
 
 How can we achieve this?

You still would probably want to use morphing software.  The
difference is that instead of interpolating between the meshes of two
images, you have to find the average between all the meshes, and then
morph to that point.  GtkMorph can do a lot of that, but it would
probably take some modification to get it to do all of that.

Rockwalrus
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] [Fwd: Some suggestions for the plug-in registry]

2005-08-27 Thread Nathan Summers
On 8/26/05, Sven Neumann [EMAIL PROTECTED] wrote:
 Hi,
 
 Nathan Summers [EMAIL PROTECTED]  writes:
 
  2.3 is a development version with no API guarantees whatsoever. The
  API is constantly changing and noone should be developing any
  plug-ins for it.
 
  If you have such a closed Gimp Club attitude, why make developer
  releases at all?  After all, all the members of the Gimp Club have
  cvs accounts.  One of the most important reasons that we have
  preview releases is so that when 2.4 is released, third-party
  plugins are already available for it.  It's abundantly obvious that
  2.3 is a developer edition, with all that entails, and both users
  and plugin developers are aware of the fact that things can break,
  but that doesn't mean that it's counterproductive to track
  development and to test the new features.  Would you prefer that
  serious problems in newly added plug-in apis not be discovered until
  after they are frozen?
 
 The only reason I don't want to see a 2.3 version in a plug-in
 registry is that doesn't seem to make much sense. After all any new
 API could change with the next new minor 2.3 release. The version
 listed in the registry would also have to include the micro version
 number then.

All plugins will eventually go obsolete, true, regardless of what
versions they compile against.  Including the point release is easy
enough.  Chances are also pretty good that a plugin that compiles
against 7.5.15 will compile against 7.5.17 even if they are both
development versions.  Caveat compilor, but I would be willing to give
it a go, especially if it were a plugin I had a distinct need for.

 I am deliberately ignoring the hostile attitude of your mail. We both
 know very well that we don't like each other.  There's no point in
 continuing this in public. Feel free to flame me in private mail.

I'm sorry if you don't like me, but I like you just fine.  Would you
honestly want me to not speak up when you say something that's not in
GIMP's best interests?  If I wanted to be hostile, I would have been
much, much more hostile.  I would have been more subtle, but subtly is
often lost on you.

So no, I will say what I think is best for the GIMP project, and I
will do so publicly.  If you think I disagree with everything you do,
you're wrong.  You have good judgement on technical matters, and I
respect pretty much all the decisions you've made in that area.  (The
few I haven't are well-documented.)  You can't possibly want me to me
too every good decision you make like some AOLer. :)

But realize that you are not perfect, and when I do speak up, it's
because I want GIMP to be the best it can be.  I'm not perfect either,
and I'm not always right, but I truly believe that by putting our
heads together, we can all come to a mutually-agreed conclusion on
what is best.  GIMP used to be run by that principle, and it's my
personal belief that that system can work better than any personal
dictatorship ever could.

Right now one of the most serious problems that GIMP has is a lack of
active developers.  I will be blunt (frank, not hostile, and only
because such frankness is necessary.)  The reason for this is that
GIMP development has become dysfunctional, and the original mail I
responded to was symptomatic of this dysfunction.

Like any good dysfunction, there are several interrelated parts.  One
part is that a small but vocal minority of the community are quite
hostilely impatient with practically any newcomer who tries to learn
the ropes, and as a result, almost all of them get driven away.  There
were serious problems with the first patch I ever submitted to a
software project.  If I had gotten the treatment that most newcomers
who haven't been magically endowed with the all the right skills now
get here, I'd probably be working for Microsoft and spending my free
time blogging about how the open source zealots don't understand the
real world.  Instead, I got a patient reply explaining how exactly how
to submit my changes in the most suitable form, and I got very
prominent mention in the release notes of the next version. 
Unsurprisingly, I continued to contribute to that and later to other
projects.

The unwillingness to mentor potential new developers, combined with
the fact that practically everyone who was willing to speak up if they
didn't like a particular decision have left in disgust at your
tendency to turn any disagreement into a personal matter, as you just
tried to here, has resulted in a very unhealthy environment.  For
example, I used to spend all of my free time hacking gimp, but that is
no longer the case, and the only reason for this is that it's not
worth it for me to fight for every single nontrivial change or
addition that I make, especially since no one is left who will back me
if I don't get time to complete it.

I am far from the only contributor that feels this way.  I might knock
off a low-hanging feature or bug if I'm bored or it scratches a
personal itch

Re: [Gimp-developer] authors.xml, volunteer needed

2005-08-27 Thread Nathan Summers
On 8/27/05, Tor Lillqvist [EMAIL PROTECTED] wrote:
 
 The following names I couldn't find in the ChangeLogs, somebody else
 could grep through the mailint list archives. My apologies if I have
 missed someone obvious whom I should know by name.
 
 Thom van Os

He did the selective gaussian blur plugin, and I think I've seen the
name in other places as well.  But he definately qualifies as
author.

Rockwalrus
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] [Fwd: Some suggestions for the plug-in registry]

2005-08-26 Thread Nathan Summers
On 8/26/05, Sven Neumann [EMAIL PROTECTED] wrote:
 Hi,
 
 michael chang [EMAIL PROTECTED] writes:
 
  1. Make it possible to indicate that a plug-in requires GIMP 2.2
 
  2.3, and 2.4 options would be nice here too, I suppose.  And also,
  change the list of links of types to a drop down box, maybe?  (Dunno.)
 
 2.3 is a development version with no API guarantees whatsoever. The
 API is constantly changing and noone should be developing any plug-ins
 for it.

If you have such a closed Gimp Club attitude, why make developer
releases at all?  After all, all the members of the Gimp Club have cvs
accounts.  One of the most important reasons that we have preview
releases is so that when 2.4 is released, third-party plugins are
already available for it.  It's abundantly obvious that 2.3 is a
developer edition, with all that entails, and both users and plugin
developers are aware of the fact that things can break, but that
doesn't mean that it's counterproductive to track development and to
test the new features.  Would you prefer that serious problems in
newly added plug-in apis not be discovered until after they are
frozen?

Since 2.3 cvs contains a plugin that was originally maintained
separately, and GIMP was developed against gtk 1.3 long before API
freeze, it's obvious that you already know this, which makes me ask
the question: why did you say this in the first place?  Seriously, it
served no other purpose than discouraging people from testing the 2.3
series.  GIMP isn't exactly overwhelmed with volunteers. We should be
doing everything we can to encourage more people to try out 2.3, and
more people to be testing its new features.  Yes, that even includes
those features that have to be accessed programmatically.  Anyone who
is capible of developing a plugin against 2.3 is capible of fixing any
breakage if we change a non-frozen API.

 And 2.4 shouldn't be added before the 2.4 release.

That's a matter of taste.  After all, if 2.4 is backwards compatible
with 2.0 plugins, there are a ton of plugins that are already 2.4
compatible.  What's not a matter of taste is that plug-ins shouldn't
be marked as 2.4 compatible if they use non-frozen APIs.  After the
API is frozen is a different matter.

Rockwalrus
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] WMF on GIMP

2005-08-25 Thread Nathan Summers
On 8/25/05, Uma Maran [EMAIL PROTECTED] wrote:
  
 Hi 
   
 I want to use WMF on my C/GTK application 
 As such, when i try to open a WMF on the GIMP or on my application, the
 image is set to a specific size on its own and hence it gets distorted.. 
 Can anybody give a solution for this? 
 Thanks in advance 

If I understand your problem correctly, this is a limitation of the
WMF format.  You'll need to make sure that the aspect ratio you are
rasterizing to is the same as the aspect ratio it was intended to be
rasterized to.

You might want to consider using SVG in place of WMF.  It's newer and
has its own warts, but it doesn't suffer from this particular problem.

Rockwalrus
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] The GUI

2005-08-18 Thread Nathan Summers
On 8/17/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
 Hi,
 I've got a suggestion about the GUI/Layout. You can se the idea at
 http://www.linet.se/gimp/
 
 I hope you like it!

Placing a dockable location to the side of the image view window could
be nice to have.

Rockwalrus
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] They Might Be a Developer

2005-08-17 Thread Nathan Summers
On 8/17/05, Jeremy White [EMAIL PROTECTED] wrote:
 Howdy everyone... thought this would be a good message to introduce myself
 in and my intents:
  
  I wanna get into debugging a bit of GIMP (that's right... I'm fresh blood)
 and once I get used to it, I guess I'll go ahead and add something to the
 core code if you'd approve. I went ahead and typed up my ideas but I decided
 it would be a bad idea to post any of my thoughts until I got some feedback.
 Is the mailing list a good place for me to announce ideas like that and
 whatever? I just would hate to spam this list with my thoughts if it's the
 wrong place.

That is exciting to hear. We have plenty of bug to choose from; try
http://bugs.gimp.org .  The easiest way to submit bugfixes is to sign
up for an account there and then to attach the  patches in diff -u
form to the appropriate bug.
  
  OH! And another thought. I'm assuming you people don't need a resume or any
 of that jazz... 

Your code is your resume.

 you just want me to debug stuff until I prove I'm better
 than another developer, then he/she gets voted off the island and gets eaten
 by sharks while we watch and eat popcorn and then I go ahead and start
 developing code until I die so many times that I don't have any quarters
 left to put in the video game. Am I loosely right?

We don't have enough developers to start killing them off yet.

  Dang, I need to lessen the sugar.

We can use a bit of lightheartedness every once in a while.  Too much
of it might upset one of our resident grouches, but you'd know if that
happened. :)

  Ta ta, ya' GIMPy people,
  Jeremy White
  
  P.S. Do you want my system(s) specs?

They are probably not all that relevant, although if you are competent
at doing builds for non-Linux or non-Intel platforms, they might be.

Rockwalrus
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Transparent Vector images

2005-07-05 Thread Nathan Summers
On 7/4/05, Uma Maran [EMAIL PROTECTED] wrote:
  
 Hi all 
 This is my first posting in the group.. 
 We have been developing a GTK software for the Linux desktop and Simputer.. 
 My requirement is as follows: 
   
 1. Impose/Overlap more than one Transparent Vector Images of the same size 
 2. View them all together as a single Image 
 3. Capture mouse events on the images 
   
 If anybody could help me out.. 
   
 Thanks and regards... 

Perhaps using librsvg and doing your own renderer/mouse handler would
be best for your situation.

Rockwalrus
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] GEGL alive?

2005-07-02 Thread Nathan Summers
On 7/1/05, Jan Prach [EMAIL PROTECTED] wrote:
   Hi Gimps,
  Is GEGL alive or not?

GeGL is alive, and unlike say, six months ago, is not even in a coma. :)

  I like gimp. I feel very limited by 8 bit color depth in gimp for a
 quite some time. I'm going to start my diploma thesis. It'll be about
 HDR (high dynamic range) images. If the idea of GEGL is alive I'd like
 very much to contribute.

Excellent!

  I've read that you have realized 8bits are not enough for the future
 during the GUADEC. Than I saw some activity in GEGL cvs. I've also read
 something about gggl. I'd like to see those ideas working in gimp.

GIMP is currently understaffed and has been for a while.  But we
definately are still committed to getting gegl to be more than a pipe
dream.  Actually, a directed acyclic graph dream.

  The question is: Are you going to move gimp forward with GEGL or just
 dispute KDEification?

Well, try not to put it as a mutually exclusive choice.  Flamewars are
so much fun, you know. :)

Rockwalrus
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Using Gimp's functionality

2005-07-01 Thread Nathan Summers
On 7/1/05, Pavel Grinfeld [EMAIL PROTECTED] wrote:

 If I would like to use the gimp functionality in a
 separate application, what do I need to link? I assume
 libgimpbase etc, but is there a complete list?

Here's a list of all the libraries in 2.3.2:
libgimp
libgimpbase
libgimpcolor
libgimpconfig
libgimpmath
libgimpmodule
libgimpthumb
libgimpwidgets

 Basically, suppose that I want to create an image
 programatically, do something gimpy with it, and save
 it to hard disk. I want to be able to distribute this
 program and not expect that the user has gtk and gimp
 installed.

Unfortunately, this is currently not feasable without considerable
butcher work on your part.  Gimp's libraries are mostly intended to be
used to share code needed by both plug-ins and the core.  While much
of what is in libraries other than libgimp and libgimpmodule can be
useful for other programs as well, it sounds like they probably don't
have what you are interested in.

Being able to use gimp routines in other programs without having to
invoke a separate gimp process is interesting to me personally, and
probably to other gimp developers as well.  I have no doubt that the
best way to achieve this is to focus on the GEGL backend library that
gimp developers are presently working on; if you are interested, your
help in completing GEGL is much appreciated.

As a more short-term option, you might consider looking into
gimp-console, the UI-free version of gimp suitable for servers. 
Gimp-console itself does not depend on gtk at all, although if you
wish to use any gimp plugins with it, you probably will need gtk
anyway.

Sorry we couldn't be of more help, but think of this as an opportunity
to help us improve gimp!

Rockwalrus
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


[Gimp-developer] Re: [poppler] ANNOUNCE: gimp-poppler version 0.4.0

2005-06-30 Thread Nathan Summers
On 6/29/05, Kristian Høgsberg [EMAIL PROTECTED] wrote:
 Nathan Summers wrote:
  gimp-poppler version 0.4.0 has been released.  It can be downloaded at
  http://rockwalrus.dyndns.org/~rockwlrs/gimp-poppler . This new version
  features thumbnailing and the ability to only load individual pages.
  There are other features; check the NEWS file for details.
 
 Wow, good work, that's really nice.  Ideally, you shouldn't have to use
 the /usr/include/popper/* API, so I was looking through glib_glue.cc to
 see what kind of functionality we need to provide in the glib wrapper to
 avoid this.  First, the page label is actually available in the glib
 wrapper - it's probably not the most discoverable interface, but it's a
 GObject property.  So you can do
 
  char *label = NULL;
 
  g_object_get (G_OBJECT (poppler_page),
label, label,
NULL);
 
 to get the label for a PopplerPage.

Yes, this was discovered by one of the gimp developers literally
minutes after I made the 0.4.0 release.  It's generally considered
good style for gobjects to provide a C accessor function for each
property, and vica-versa, for exactly this reason.

  As for the anti-alias toggle... I'm not sure.  It's only affecting the
 fonts with the splash backend, right?  And the cairo backend can't
 respect that setting.  Is it really something you'd want to disable?

Generally, the ability to turn off antialiasing is not necessary or
desirable, but there are certainly image-manipulation situations where
having crisp, full-intensity borders is more important than subpixel
accuracy.  This is why pretty much every operation in GIMP can have
the antialiasing turned off.  It would be a shame if the poppler
plugin couldn't do this, when the old ghostscript-based plugin could.

 Getting at the paths and text in the PDF as you mention in your previous
 mail is a lot more difficult.  We can't easily get at that with the
 current poppler structure, and defining a good API for this isn't easy
 either.

We'll see what we can come up with.

 Anyway, it's great to see poppler and the glib wrapper used outside
 evince.  Let us know if there is more information you need from the
 poppler-glib API.

We'll stay in touch.

Rockwalrus
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


[Gimp-developer] ANNOUNCE: gimp-poppler version 0.4.0

2005-06-29 Thread Nathan Summers
gimp-poppler version 0.4.0 has been released.  It can be downloaded at
http://rockwalrus.dyndns.org/~rockwlrs/gimp-poppler . This new version
features thumbnailing and the ability to only load individual pages. 
There are other features; check the NEWS file for details.

Unlike previous versions of gimp-poppler, this version relies on
features only present in the developer's version of GIMP.  At present,
it requires a fairly recent version from CVS.

Rockwalrus
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] preview for scrip-fu plugin?

2005-06-29 Thread Nathan Summers
On 6/29/05, pepster [EMAIL PROTECTED] wrote:
 Kevin Cozens wrote:
 
  pepster wrote:
 
  Say I have a scrip-fu plugin (I am thinking about wrap sharp), and I
  want to add a preview window to make it more useful.
 
  Does it mean I must re-write the plugin in C, or is there an easier way?
 
 
  You would have to re-write it in C. There is no easy way to add a
  preview window to Script-Fu.
 
 
 I tried to make a start but facing immediate problems. Would appreciate
 some pointers -
 
   1. The scm code calls the (pdb) plugin plug_in_edge. I am not sure how
 my C plugin can make a call to another plugin??

The way to do this is with one of the gimp_run_procedure functions,
but in this case edge-detection is trivial enough that it doesn't make
sense to call a separate plug-in to do it.
In fact, copying the existing edge-detection plug-in might be the best
way to start.

Rockwalrus
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Layer locking proposal

2005-06-27 Thread Nathan Summers
On 6/26/05, Joao S. O. Bueno Calligaris [EMAIL PROTECTED] wrote:
 On Sunday 26 June 2005 17:48, Sven Neumann wrote:
  Hi,
 
  Joao S. O. Bueno Calligaris [EMAIL PROTECTED] writes:
   If we want to have all the lock types that PS offers, we would
   have to add three new toggles to the layer row. Is that
   feasible?
  
   kkk...
   I thought of three  different  states for the lock Icon (and a
   nice tooltip, of course).
 
  Three lock types make up for 2^3 states. Not sure if all of them
  are useful but it could become difficult to display all useful
  states in a single icon.
 
 Oh well, as Homer Simpson would say:
 DOH!
 
 :-)

It's a little less scary if you refer to 2^3 by its other name, 8.  :)

Rockwalrus
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Layer locking proposal

2005-06-27 Thread Nathan Summers
On 6/26/05, Simon Budig [EMAIL PROTECTED] wrote:
 A way to overcome this is to have e.g. two lines per layer. A sample
 mockup is available at
   http://www.home.unix-ag.org/simon/files/layer-dialog-many-properties.png

This would work.  All you would need to do is increase the text 2pt or
so, and make the icons visually look a little less like text.

Rockwalrus
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] About Preferences enrtry in the Edit menu

2005-06-25 Thread Nathan Summers
On 6/24/05, Sven Neumann [EMAIL PROTECTED] wrote:
 Nathan Summers [EMAIL PROTECTED]  writes:
 
  No, just more sophisticated.  You still have to create a path in order
  to import an svg as a path.
 
 No, you don't have and you never had to. There's a Paths menu that
 allows you to import an SVG even if no other path exists yet.

I used to have a co-worker that would often say that if a user can't
find a feature, it doesn't exist.  Even after rummaging through the
code with grep for a few minutes, the only menu I can find that allows
you to import an SVG is the one that you right-click an existing item
in the Paths dialog to get.  I'd have to say that since even a casual
but directed search through the source code can't find the menu that
you're talking about, the discoverablity of the feature is
impressively bad.

Rockwalrus
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Layer locking proposal

2005-06-25 Thread Nathan Summers
On 6/25/05, Pedro Kiefer [EMAIL PROTECTED] wrote:
 Objective: Lock the layer from user actions.

 I've just made this mockup (attached) of how the locking mechanism
 should appear to the user in the layers tab. But that could be wrong, in
 not really familiar with the GNOME HIG. Clicking in an unlocked lock
 will lock the layer, clicking in a locked lock will unlock it.

Looks nice.  The only thing that comes to mind is that keep
transparency and lock are similar, and yet displayed so differently on
the dialog. But that's a minor issue.
 
 How all this should be implemented is something that I don't know in the
 moment. I need to learn a little bit of how actions interacts with the
 layer to try to propose some functions. But what comes to my mind is to
 have a function that returns, based on it's caller, if the given caller
 is able to act upon the given layer. And a simple set / unset pair of
 functions to be called from the UI.

It doesn't sound like it should be that hard to implement.

 [1] It actually photoshop has one more locking option, keep transparency
 which is already implemented in gimp.

Out of curiosity, if you have keep pixels on and keep trans off, can
you munge the alpha channel but not the color channels?

Rockwalrus
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] pygimp on windows? success!

2005-06-25 Thread Nathan Summers
On 6/24/05, Alan Horkan [EMAIL PROTECTED] wrote:
 
 On Fri, 24 Jun 2005, Michael Schumacher wrote:
 
  Great work! Seems like we will finally have pygimp 2.4 for GIMP 2.4 on each
  of the officially supported platforms. Hm, how about letting
  Script-Fu/Tiny-Fu die in favor of it? ;)
 
 The best thing about Script-Fu has been knowing it would be available and
 included in the 'default install'.  Many existing scripts are written in
 Script-Fu and as you know we still regularly get users asking how to get
 and old script to work with the current version.
 
 From a technical standpoint it is great that Python and Perl subsystems
 are well achitectured and entirely seperable but the failure of
 distributors to include them in the 'default install' or even bother to
 build them has dicouraged people from using them.  Making it possible to
 leave things out is different from it being a good idea to leave things
 out and I do not think users are given the best impression of the GIMP
 because to the ordinary user if it is not installed it may as well not
 exists.
 
 My point is Script-Fu remains useful despite it's flaws and I am concerned
 by the potential side-effects of killing it off.

Agreed!  There is great value in having a scripting interface that is
guaranteed to be present in any gimp installation.  Regardless of how
hard we implore, people are quite simply not going to universally
include script-fu in their gimp packages if we package it separately
ourselves.  That is human nature.  While I think it would be great to
replace script-fu with tiny-fu, it would be a big mistake to ship a
gimp tarball that doesn't include either.

Rockwalrus
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Integrated Scripting

2005-06-23 Thread Nathan Summers
On 6/23/05, Alan Horkan [EMAIL PROTECTED] wrote:
 On Thu, 23 Jun 2005, Sven Neumann wrote:
  Alan Horkan [EMAIL PROTECTED] writes:
   and I would like to see it replaced with a term that doesn't require
   extra localisation work and yes I wouldn't be averse to slapping the
   slightly inappropriate Windows label on it (benefit of consistency
   with other software) but Palettes or even Docks which actualy
   describes the type of dialogs might be better.
 
  Windows is usually used for a list of opened windows.
 
 Photoshop is a bit weird I admit but the Windows menu is where it puts the
 menu items to control what Palettes are shown.  The list of Open Windows
 is also included in there somewhere, and also an option to save
 workspace which will make sure window positions are remembered and a few
 other bits and peices (like maybe Close All, but I dont have convenient
 access to Photoshop so I'm really not sure what is in there).

I've used plenty of applications where the Windows menu does
double-duty, with the kinds of windows that can be opened, followed by
a separator, followed by the current open windows.  Come to think of
it, I'd say the only apps that I've used that don't do it that way are
ones were all the windows are the same kind, anyway.
 
  So if we used that we would use a term that is consistently used in
  other applications for something completely different.
 
 In theory the View menu would be the place to put menu items to control
 what windows/dialogs are shown or not shown but in this case it is not at
 all pratical.  

At least to me, the View menu is for stuff that affects this
particular view of this particular image, not dialogs and windows
unrelated to it.

  And we should actually consider to add a Windows menu that lists all
  open GIMP windows.
 
 Listing all the open window list might help reduce the requests for a
 tabbed interface to the gimp many of which seem to be due to difficulties
 in managing lots of open windows.

That would be a nice feature to have, but I don't think it would be a
complete substitution for tabs.

Rockwalrus
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] About Preferences enrtry in the Edit menu

2005-06-23 Thread Nathan Summers
On 6/23/05, Michael Schumacher [EMAIL PROTECTED] wrote:
 Joao S. O. Bueno Calligaris wrote:
  It just feels great.
 
  I t always took me sometime when pointing someone to Preferences to go
  to Toolbox-FIles-Preferences and not Image-File...
 
 Well, unfortunately this seems to lead back to the Why the heck do I
 have to open an image to access $feature? times... and I thought these
 were finally gone.

No, just more sophisticated.  You still have to create a path in order
to import an svg as a path.

Rockwalrus
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] About Preferences enrtry in the Edit menu

2005-06-23 Thread Nathan Summers
On 6/23/05, Joao S. O. Bueno Calligaris [EMAIL PROTECTED] wrote:
 On Thursday 23 June 2005 17:22, Michael Schumacher wrote:

 Why so? The Preferences entry is still in the toolbox-File menu.
 
 One other possible rearangement would be drop the dialogs and
 prefences entries into Xtns and rename that to Extras once for
 all.

Extras:  If you can't find it in any other menu, it's probably here!

Rockwalrus
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Integrated Scripting

2005-06-22 Thread Nathan Summers
On 6/22/05, Sven Neumann [EMAIL PROTECTED] wrote:
 Hi,
 
 Leon Brooks [EMAIL PROTECTED]  writes:
 
  Could a language-related mini-icon (16x16 or smaller) against each
  menu entry help?
 
 The idea of the menu reorganization is to hide the language from the
 user because the user shouldn't have to care what language a filter is
 written in. Adding a language specific icon is contradicting this
 effort. 

I can't speak for anyone else who is working on menu reorginization,
but my personal goal is to restructure the menus so that it is easier
to find things.  Putting everything in the same categories regardless
of implementation flows naturally from this desire, since you look for
things by functionality, and because searching four menus in different
locations is more cumbersome.

It is important not to lose the forest for the trees.  One result of
moving functionality out of implementation-specific menus into a
common group is that information about implementation is less
prominant, but it would be a serious mistake to conclude from that
that this side effect is a goal.

 There will always be the plug-in browser if someone wants to  find out more 
 about a
 plug-in / script.

I'm not going to say that there isn't a place for the plug-in browser,
but this is not the place for it.  There are very legitimate reasons
that everyday users need to be aware of how a menu item is
implemented.  Some of these reasons are differences we can paper over
or eliminate, such as the fact that repeat repeats the last non-core
menu item ran, not the last run menu item.  Some issues, such as
knowing which bindings need to be installed to run your favorite
script, cannot.  There are several more examples I could list for both
categories, but I will be brief, since you are intellegent enough to
come up with them by yourself.

Since there are good reasons that users should be familiar with how
each menu item is implemented, it needs to be information that is well
presented.  Having such information unobtrusively placed in the UI is
the only way this can be achieved.  It is simply not reasonable to
bury this information in the plug-in browser, where the user has to
wade through irrelevant and likely-to-be uninteresting information for
every single menu entry.

For menu items that pop up dialogs, some ui element in the dialog
would be a good location; perl-fu already does this.  However, there
are some plug-ins, like Gradient Map, that don't show a dialog, so
unless you want to show a dialog like this:

--[Gradient Map]-
| Gradient Map is written in C. |
| Since it's a plug-in you can  |
| use the repeat command to |
| run it again. |
|---|
|  [Ok] |
-

the most reasonable place to stick that info is in an icon in the menu.

Futhermore, the fact that this particular suggestion -- icons by the
menu items -- has been made by and most likely independantly thought
up by several people should be enough in of itself to show that there
is some merit to it.

 We should try to improve this browser instead of cluttering the menus with 
 such icons.

I don't think that adding such icons would be so bad, since after all,
there are icons in other spots in the menus already.  Even if doing so
did make the menus a bit less attractive, the added useful information
would more than balance it out.  Our goal is to have a program that is
useful and usable, not one that makes the centerfold of
Awesome-Looking Programs Monthly.  (Of course, it would be excellent
if the editors of said magazine used GIMP to edit their content, and
we don't want them to barf too much over looking at it in the
meantime.)

Rockwalrus
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Integrated Scripting

2005-06-21 Thread Nathan Summers
On 6/21/05, Carol Spears [EMAIL PROTECTED] wrote:
 now that marc and sven have had their fun and we have all been allowed
 an example of how the perlized obfiscuates script-foneys with equal yet
 different levels of artificial intelligence; are there opinions of ways
 to rearrange the Xtns portion of the menu system?
 
 questions i have are these:
 what of the history of Xtns?
 
 it seems to be steeped in mystery and mis-use

Originally, there was a rule that if you wrote a load/save plug-in,
you added it to the list of loading/saving file types.  Otherwise, a
plug-in was supposed to be added to the Image/Filters menu. 
Extensions were to be added to the Xtns menu.

There was then the problem of what to do with plug-ins that don't take
an image, and therefore aren't very meaningful in the Filters menu. 
Following the strict segregation rule of the time, Xtns seemed like
the natural place to put them.

Since then, people started putting plug-ins into the menu structure
willy-nilly, comingled with the core-implemented menu items, and
extensions have gone from being cool to being a last resort if you
can't implement the required functionality with the regular plug-in
mechanism.  So what we are left with is the Xtns menu being the junk
drawer of miscellaneous stuff, the only real thing the items having in
common being that they are implemented with either plug-ins or
extensions.  Actually, come to think of it, I seem to recall that the
core puts a menu item there as well, so we might not even have that in
common.

 people rearranging the menus now do not seem to see that Xtns
 makes its own image and do not need to start with an image; even
 though the logic is very clear to some.

The thing is that there are plenty of exceptions to that rule. 
File|Dialogs being a big source of stuff that doesn't need an image,
for example.  I know that the reason for the difference is that the
Dialogs are implemented by the core, but why should I care?
 
 is there a sane way to include a script from each of the languages?
 
 examples: font-mapping, yinyang drawing; all the scripts have
 one.

 some of the scripting languages have an example that shows how to
 use the script; however the result of using it is ugly.

A unified script browser would be nice.  If we had heard about the
Summer of Very Short Coding-related Deadlines sooner, we might have
been able to make it a bounty.

 include a menu entry for each of the gimp script powertools:
 the browsers
 the consoles
 the servers

I see little reason why these shouldn't be a subcategory of the other
dialogs.  The name Development was suggested.

 potentially helpful non-gimp urls

That opens another can of worms, but to be brief, I like the idea of
having such urls either being redirects from the gimp website, or
dynamically updated every gimp startup.

 i personally would not mind keeping Kevi1 busy with changes to Tiny-fu
 for a while

Kevi? is certainly not the only one qualifed to change the locations
the scripts register under.  It's actually a trivial change for
anyone.

, however, i am uncomfortable with the limited view i have
 had of the menu reorganization.  my completely unresearched opinion was
 formed while seeing that it is being handled by people who have not
 actually experienced the whole gimp eh, experience.  i also would be one
 of these people.

Well, no one has experienced all of the gimp experience.  That's
what good old fashioned kibitzing is for.

  i can at least see that by the time i started to use
 gimp, everything that appeared in Xtns were plug-ins that did not need
 an image to start with. 

Not technically true, as script-fu scripts are implemented through an
extension, not a plug-in, but this only reinforces the point that no
one knows/cares about the distinction.

 fixing the problem with different types of
 scripts that do the same job in Xtns where it is much more of a problem
 will help everyone with the Image menu which has a few instances of this
 but not as many.

My suggestion is that Xtns menu items that create images should be
called something like File|New Generated Image and that the rest
should be merged with the other dialogs, ether as File|Dialogs or as a
new toplevel Dialogs menu item.

Rockwalrus
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


[Gimp-developer] Prototype PDF import GIMP plug-in based on poppler

2005-06-19 Thread Nathan Summers
I've created an initial version of a PDF import plugin for GIMP that
uses poppler.  Currently this version has little to offer compared to
the existing ghostscript-based PDF import plugin, but I feel like a
poppler-based plug-in has much more potential in the long run.

While this version uses poppler to render whole pages, it would be
nice if it were possible to access individual elements, such as boxes
of text or images, and have each rendered into a separate GIMP layer.
Currently, there isn't enough exposed to the glib bindings to make
this possible.

This initial version is downloadable at
http://rockwalrus.dyndns.org/~rockwlrs/gimp-poppler , and should be
buildable with the appropriate libgimp devel package.  I would very
much appreciate it if some poppler developers took a look at what is
there already and let their imaginations run wild.  :)

Rockwalrus
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


[Gimp-developer] Re: [poppler] Prototype PDF import GIMP plug-in based on poppler

2005-06-19 Thread Nathan Summers
On 6/19/05, Leonard Rosenthol [EMAIL PROTECTED] wrote:
 At 06:23 AM 6/19/2005, Nathan Summers wrote:
 I've created an initial version of a PDF import plugin for GIMP that
 uses poppler.
 
  Cool!
 
 
   Currently this version has little to offer compared to
 the existing ghostscript-based PDF import plugin,
 
  Should be noticeably faster (and depending on the version of GS
 installed), higher quality.

I was refering mostly to the fact that there are several features that
the GS version has that the poppler version, being a prototype, does
not.  For instance, the version I put on the web has the resolution
hard-coded at 72 dpi, which isn't very reasonable.

 While this version uses poppler to render whole pages, it would be
 nice if it were possible to access individual elements, such as boxes
 of text or images, and have each rendered into a separate GIMP layer.
 
  Interesting, but what purpose would it serve?   If GIMP had real
 text layers (ala PSD), then it might be interesting to create such from PDF
 - but otherwise, I don't see any use.

I'm not sure what you mean by real text layers. GIMP certainly can't
do text layout as well as a typesetting program yet, but you certainly
could click on a text layer, edit what the text says, and have the
gimp engine re-render the text.

  What did you have in mind?

It would be nice for different parts to be rendered into separate
layers so they can be manipulated individually. GIMP already has some
vector graphics features, and it is growing more constantly.  Being
able to inport paths actually as paths, etc, would be a very useful
thing to have.  Furthermore, if you only need a specific part of a
large file, the ability to just import a few elements instead of the
whole thing makes the workflow much easier.

Rockwalrus
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] GIMP is not a GNOME application

2005-06-18 Thread Nathan Summers
On 6/18/05, Alan Horkan [EMAIL PROTECTED] wrote:
 
 On Fri, 17 Jun 2005, Sven Neumann wrote:
 
  Date: Fri, 17 Jun 2005 23:11:25 +0200
  From: Sven Neumann [EMAIL PROTECTED] 
  To: Leon Brooks [EMAIL PROTECTED] 
  Cc: gimp-developer@lists.xcf.berkeley.edu 
  Subject: Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of
  GIMP
 
  Hi,
 
  Leon Brooks [EMAIL PROTECTED]  writes:
 
   This may seem like an oxymoron, given GIMP's heavy defacto relationship
   with GNOME-flavoured GTK, but is there any GIMP equivalent to
   OpenOffice's KDE integration (http://kde.openoffice.org/ )?
 
  GIMP is not a GNOME application,
 
 This point has been made before and I hope Sven is willing to clarify this
 point a little more as I do not entirely understand his purpose in saying
 it or putting it exactly that way.

Certainly there are as many definitions of what it means to be gnome
as there are gnome developers.  But if you've seen the much
talked-about 10x10 video, I'd say to use the terminology there, gimp
is GNOME, but is not in GNOME.  If you haven't seen that video,
the distinction probably doesn't mean a thing for you, of course. :)

Rockwalrus
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Google Summer of Code - urgent

2005-06-13 Thread Nathan Summers
On 6/13/05, Dave Neary [EMAIL PROTECTED] wrote:
 we need a mentor for the plug-in
 system. There is a related resource distribution project for gDesklets
 in the bounties already - some coordination might be possible.

I'm willing to be a mentor for that one.

Rockwalrus
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Re: Akanna Menu patch

2005-06-13 Thread Nathan Summers
On 6/12/05, Sven Neumann [EMAIL PROTECTED] wrote:
 Nathan Summers [EMAIL PROTECTED] writes:
 
  Sorry, but GIMP also doesn't know what language the procedure is
  written in. Such a framework would first have to be added and I don't
  see it as particularily useful.
 
  It's a great solution for the real world problem of :
 
  Run the Foo plugin.
  I don't have the Foo plugin.
  Oh crap, what package is it in?
 
 I see that problem but the suggested solution doesn't help with it.
 What the user really wants to know is how to get that particular
 plug-in/script. Telling the user what language it is written in, is
 not going to solve that problem.

Given that in the Real World, the vast majority of the scripts people
have installed came in the same package as the scripting language
itself, this solves a major part of the problem.  On the other hand,
if we are adding a field-of-origin, it's trivial to make it specify
not just language but a URL or somesuch for how to get it.

Rockwalrus
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Re: Akanna Menu patch

2005-06-11 Thread Nathan Summers
On 6/11/05, Sven Neumann [EMAIL PROTECTED] wrote:

 Sorry, but GIMP also doesn't know what language the procedure is
 written in. Such a framework would first have to be added and I don't
 see it as particularily useful.

It's a great solution for the real world problem of :

Run the Foo plugin.
I don't have the Foo plugin.
Oh crap, what package is it in?

Rockwalrus
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Gimp 2.3.1 crash

2005-06-11 Thread Nathan Summers
On 6/11/05, David Neary [EMAIL PROTECTED] wrote:

 This could be because the directory where the older GIMP libraries are
 installed is in /etc/ld.so.conf - I seem to recall that this plays havoc
 with link-time linking (which libtool does) and definitely does with
 runtime linking. I'm not sure what the solution might be if you've
 installed an official 2.2 or 2.0 GIMP in /usr, and you want to install
 2.3.1 in /usr/local or /some/special/prefix - perhaps someone else can
 give ideas how to get around that problem.

the 2.2 libraries can be in /etc/ld.so.conf's path, but the 2.3 cannot be.

$ ldd `which gimp`
libgimpwidgets-2.0.so.0 = /usr/lib/libgimpwidgets-2.0.so.0 (0x4003)
libgimpmodule-2.0.so.0 = /usr/lib/libgimpmodule-2.0.so.0 (0x4010e000)
etc..

$ ldd `which gimp-2.3`
libgimpwidgets-2.0.so.0 =
/usr/unstable/lib/libgimpwidgets-2.0.so.0 (0x40018000)
libgimpmodule-2.0.so.0 =
/usr/unstable/lib/libgimpmodule-2.0.so.0 (0x40106000)

where /usr/lib is always in the ldconfig path, and /usr/unstable/lib
is most definitely not.

Rockwalrus
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: Akkana Menu patch [was Re: [Gimp-developer] The GUADEC meeting]

2005-06-07 Thread Nathan Summers
On 6/7/05, Akkana Peck [EMAIL PROTECTED] wrote:
 
 Nobody's commented on any of the other questions I asked in the bug,
 like whether it would be a good idea to fold the short Glass Effects
 menu into Light Effects, 

Sure, although it might be nice to put a separator between them

 or moving Enhance up to where it's just
 under Blur, 

That makes perfect sense to me.

 or whether there's a reasonable place for Show Image
 Structure since it's now the only item in Utils.

It seems to me like Show Image Structure belongs under
Image/Image/Show Structure

 Alan Horkan writes:

  making sure to add ellipses where needed).  However some of the python
  plugins duplicate existing functionality so putting two Clothify plugins
  beside each other would only confuse users.  I see Akkanna tackled this by
  marking the Script-Fu unsharp as Unsharp 2 but if people have idea on
  how to tackle this duplication of functionality I would be interested to
 
 I'd be interested too. I don't like Unsharp Mask 2 but strings
 like Unsharp Mask (script-fu) are likely to make the menus too
 long. Anyone have a better idea?

Does the script-fu version do anything the plug-in does not?  If it
doesn't, there isn't any sense in keeping it around.

Rockwalrus
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Re: [Gegl-developer] The GUADEC meeting

2005-06-06 Thread Nathan Summers
On 6/6/05, Sven Neumann [EMAIL PROTECTED]  wrote:
 Hi,

 Sven Neumann [EMAIL PROTECTED]  writes:

  Rearranging the core menus is a matter of editing a couple of XML files.

 I should probably add that this is primarily meant as a way to easily
 edit the menu structure with the goal of getting these changes
 accepted in the GIMP development tree. I don't like the idea of seeing
 forks of the menu structure since this will make documentation
 difficult to say the least. It will also break mnemonics. Mnemonics
 are defined in the menu labels and their translations and a lot of
 effort has gone into avoiding collisions. Moving menus around will
 finally make string changes necessary which is something that you
 cannot do with the GtkUiManager XML files.

 The possibility to easily rearrange the menus is nice to have but
 should be used with care.

It seems to be wanted by enough of our users that we should give it
some serious thought, though.

Rockwalrus
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] parsing path data from xcf files

2005-06-06 Thread Nathan Summers
On 6/6/05, Sven Neumann [EMAIL PROTECTED] wrote:
 
 Actually, it would be nice if GIMP would not reject your corrupt XCF
 file but warn and load as much of it as possible. Of course that will
 not be possible in all cases but it might be worth trying. You could
 file an enhancement request for this and attach your corrupt XCF file
 to it.

Actually, I'd rather see a command-line xcfrecover program.  Of course
the big problem in either case is that XCF is not designed for
recoverability.

Rockwalrus
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Menu reorganization

2005-05-09 Thread Nathan Summers
On 5/7/05, Akkana Peck [EMAIL PROTECTED] wrote:
 I haven't seen anything in a while about the menu reorganization
 which was proposed a while back.
 
 One thing I'd like to see is getting script-fu and python-fu items
 out of separate menus and integrating them into the regular menus,
 so users don't have to know what language something was written in
 to find it.

I very much agree.
 
 - Put the Alchemy scripts under Artistic.  They're not really
   Artistic but they do vaguely similar things.

While some of the Alchemy scripts work fine under Artistic, for some
of them, Alchemy really is a better choice.
 
 I ended up with 2 more items under Filters than are there now.
 Admittedly that's still a lot; some of these could be combined,
 but since it's only two more items and I was trying to change as
 little as possible, I didn't try.

That's ripe for another proposal. :)

 I only looked briefly at Xtns.  Really, I think that menu is fine

The big problem is Xtns is that the menu has no real purpose.  It's
just a junk drawer for things that don't fit under File or Help.

 except that again I'd get rid of the language menus, and put the
 script-fu stuff under Render.  That seemed so simple that I didn't
 bother to write that up as a proposal.

I'd put the script-fu stuff under File as Render New, since it creates
new images.
 
 So here's my proposal.  Does it look reasonable?  I tried to compare
 it both to the existing menus in 2.2.6 (haven't compared with CVS
 yet) and to the proposal on the wiki, but things got confused with
 the re-editing I needed to do so I might have missed something.
 
 I'm willing to do some work to make this happen, if people agree
 that it should happen and if it's not too late to get it in for 2.4.
 I think most of the work involves tweaking script-fu and python-fu
 registration routines.  

I say go for it!

Rockwalrus
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Photoshop CS2 Features

2005-04-05 Thread Nathan Summers
On Apr 5, 2005 3:08 PM, Sven Neumann [EMAIL PROTECTED] wrote:
 Hi,
 
 can't hurt to have a look over the fence:
 
   http://www.adobe.com/products/photoshop/newfeatures.html 

The perspective cloning tool sounds cool, although the example image
looks like something from Attack of the Killer Aliasing.

Rockwalrus
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] CVS HEAD dependency on glib-2.6 / gtk+-2.6

2005-02-15 Thread Nathan Summers
On Sun, 13 Feb 2005 20:53:17 +0100, Marc A. Lehmann [EMAIL PROTECTED] wrote:

 For example, you can switch between dynamic keybindigs and mnemonic use
 via preferences, but the 2.x dynamic keybindings are not as useful as
 the 1.2 DKB were, and I do not think that penalizing people who prefer
 that way (remember, it once was a killer feature of the gimp, just as
 shell-like tab completion in the file dialog was) is reasonable.

Out of curiosity, why do you find the 2.x dynamic keybindings not as useful?

Rockwalrus
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] CVS HEAD dependency on glib-2.6 / gtk+-2.6

2005-02-15 Thread Nathan Summers
On Mon, 14 Feb 2005 03:06:33 +0100, Sven Neumann [EMAIL PROTECTED] wrote:

 The discussion about the design of the file-chooser widget is
 off-topic since we are not in the position to change it.

Waaait, we're you advocating a few days ago that we follow the burning
GTK edge because, after all, it's the Gimp ToolKit and so we can
ensure that GTK continues to support the GIMP's needs?

Rockwalrus
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] GIMP and multiple processors

2005-02-15 Thread Nathan Summers
On Sun, 13 Feb 2005 22:10:21 +0100, Sven Neumann [EMAIL PROTECTED] wrote:

 Also tried to port the code to GThreadPool but it turned out to be not
 as trivial as I expected. The current code blocks until all threads
 are returned and it is not trivial to implement this behaviour with
 GThreadPool. So this part, the more interesting part of the TODO, is
 still open.
 
 I don't want to put more time into this, but I think it would
 definitely make sense to introduce a thread pool to cut down the
 number of thread creations. Any volunteers?

Here's a solution that would work:  (note, untested code, error
checking and unintersting stuff omitted for clarity, etc)

Calling code:
struct SynchStuff {
GThreadPool *pool;
GCond *cond;
GMutex *mutex;
} synch;

typedef struct SynchStuff SynchStuff;

synch.cond = g_cond_new();
synch.mutex = g_mutex_new();


/* create an exclusive threadpool */
synch.pool = g_thread_pool_new(gimp_thread_func, synch, ...); 

/* make sure that all the tasks are in the queue before checking if
queue is empty.
 */

g_mutex_lock(synch.mutex);

for (/* each task */ ...) {
g_thread_pool_push(sych.pool, task, );
}

/* alll threads are now launched.  allow threads to test queue for emptiness
 * and wait for signal that all tasks are complete */

g_cond_wait (synch.cond, synch.mutex); 

/* all tasks are now complete */

g_mutex_unlock(synch.mutex);



void gimp_thread_func(GimpTaskData *task, SynchStuff *synch) {

  /* process task */
  .
  .
  .

  /* wait until all tasks have been queued */
  g_mutex_lock(synch-mutex);

  if (g_thread_pool_get_num_threads(synch-pool) == 1)
  g_cond_signal(synch-cond, synch-mutex);

  g_mutex_unlock(mutex);
}

We could also try to talk the glib developers into including
g_thread_pool_join, which would block until the task pool is empty. 
It would be nice if the GThreadPool API were modelled on OpenMP to the
extent possible, which I admit is not really stellar because of the
compiler modifications OpenMP requires.  But perhaps some of what
OpenMP does with compiler modifications we can do with macros.

Rockwalrus
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] GIMP and multiple processors

2005-02-15 Thread Nathan Summers
On Tue, 15 Feb 2005 16:29:00 -0500, Nathan Summers [EMAIL PROTECTED] wrote:

   if (g_thread_pool_get_num_threads(synch-pool) == 1)

correction: I meant if (g_thread_pool_get_num_threads(synch-pool) == 1  
   g_thread_pool_unprocessed(synch-pool) == 0)

although the first test is sufficient if n(tasks) = n(threads)

Rockwalrus
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] CVS HEAD dependency on glib-2.6 / gtk+-2.6

2005-02-11 Thread Nathan Summers
On Fri, 11 Feb 2005 14:32:03 +0100, Marc A. Lehmann [EMAIL PROTECTED] wrote:

 I think the reaction of accusing people of spreading FUD is pretty dumb,
 but it seems to become the norm around here.

Especially because as far as I can tell you weren't making vague
misleading or dishonest statements about a competitor's product for
your personal financial gain.  But it is interesting to note that
Mitch considers gimp-developer read by enough members of the general
public to be usable for FUD purposes.

Rockwalrus
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] CVS HEAD dependency on glib-2.6 / gtk+-2.6

2005-02-06 Thread Nathan Summers
On Sun, 06 Feb 2005 17:22:00 +0100, Sven Neumann [EMAIL PROTECTED] wrote:

 That said, I would like to state that whatever happens in GTK+, is of
 course our responsibility as well. After all it's the GIMP toolkit.
 IMO we should work a lot closer with the GTK+ development team. If it
 was me, the GIMP development branch would depend on the latest CVS
 versions of glib and gtk+. That would allow us to follow the
 development a lot closer and would allow us to give feedback early
 enough for it to be considered. The way we are working now (a lot of
 developers still using the now unmaintained gtk+-2.4 branch), we are
 of course always way too late.

For a long time the policy was that we used the most recent devel
branch release.  When did that change?  CVS HEAD is a little too
fast-moving, but I don't have a problem with using the latest devel
version, and I don't remember anyone else having a problem with it,
either.

Rockwalrus
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] file handling, something for GIMP 2.4 ?

2005-02-06 Thread Nathan Summers
On Sun, 06 Feb 2005 17:03:20 +0100, Michael Natterer [EMAIL PROTECTED] wrote:

 An alternative to implementing our own vfs would be to entirely
 hide file handling from file plug-ins, for example by passing them
 already opened GIOChannels which they would use to read/write.
 It woud be easily possible to make the IO channels use some vfs
 layer and the plug-ins wouldn't even notice.
 
 While this would make straightforward file plug-ins (which just
 open, read sequentially, close) much easier to implement, it is
 problematic for plug-ins which want to seek around in the files
 a lot (like jpeg.c). GIOChannel has a seeking API, but we cannot
 guarantee that for all vfs backends we may want to use.

This seems like a sensible abstraction.  There are two ways to handle
the seeking problem:

1) Just make sure that all plug-ins that need to seek handle the can't
seek error message correctly.  This solution sucks.

2) Implement some mechanism whereby the plug-in signals ahead of time
that it needs to be able to seek around.  On non-seekable streams, the
backend transparently uses temporary files (which of course can be
seeked.)

Rockwalrus
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] CVS HEAD dependency on glib-2.6 / gtk+-2.6

2005-02-05 Thread Nathan Summers
On Sat, 05 Feb 2005 18:36:29 +0100, Sven Neumann [EMAIL PROTECTED] wrote:
 Hi,
 
 Robert L Krawitz [EMAIL PROTECTED]  writes:
 
  There could be plenty of other reasons why, of course.  But it isn't
  FUD for people to report that they're having problems compiling and
  running GTK 2.6 against a particular distribution.  Multiple people
  reporting the same thing suggests there's an issue, but doesn't
  pinpoint where it is.
 
 I am only asking that you show us what problems exactly you have when
 building gtk+, so that we can help you to solve them. Saying that
 there are a lot of problems doesn't help at all and is what I would
 consider spreading FUD.


This still doesn't meet the definition of spreading FUD.  To spread
FUD you must:
1) Either lie or deliberately misrepresent the truth (this includes
selective retelling of the facts)
2) In one or more fora such that a large number of poorly-informed
people are reached
3) In an attempt to keep people from using a competitor's product
(esp. to keep them from switching from your product.)

The reports from SUSE users that they have had problems upgrading gtk
don't meet any of the three requirements.  Thus they are not spreading
FUD.  You don't get to redefine the term. :)

 We are trying to move GIMP development along
 and we will need to use GTK+-2.6 to make this happen. So it should be
 our goal to make sure that all developers update glib and gtk+.
 Telling them that this update will cause problems, but not saying what
 problems these are, doesn't help anyone.

You asked if going to 2.6 would cause a problem for them, and they
indicated it would.  They didn't ask you for any help in solving their
distro woes, so it was wrong for you to criticize them for that.
(especially by using such a loaded term.)

I especially find it amusing that you consider the vagueness of the
SUSE user's descriptions to be a problem because you've been much less
clear in this thread than they have.  Here is a perfect example:

 Mitch, me and probably others already have some changes pending that
 would introduce a dependency on gtk+-2.6.

What exactly are these changes?  Why are they so critical?  By your
(unusual) definition, you've been spreading FUD about gtk 2.4, saying
that it is inadequate without saying what the problems are, which, as
you so astutely observe, doesn't help anyone.

For the record, I have no problems with using 2.4, especially if
they've fixed the disaster that was the 2.4 file selector dialog. 
(Why do I say disaster?  Because it was _less usable_ for me than the
original dialog, but ymmv.)

Rockwalrus
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] CVS HEAD dependency on glib-2.6 / gtk+-2.6

2005-02-05 Thread Nathan Summers
On Sat, 5 Feb 2005 13:53:27 -0800, Carol Spears [EMAIL PROTECTED] wrote:
 i heard earlier this week that gtk+-2.6 is available on debian sid now.
 none of the sources i checked had it and still today, an apt-get update
 and still only gtk+-2.4 is available.
 
 perhaps you could share the debian source of gtk+-2.6?

http://packages.debian.org/unstable/libs/libgtk2.0-0

Rockwalrus
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] scheduling name change to boondoggle

2004-12-13 Thread Nathan Summers
On Sun, 12 Dec 2004 08:59:08 -0800, Carol Spears [EMAIL PROTECTED] wrote:
 hi,
 
 lets schedule the changing of the name TheGIMP to Boondoggle right after
 it is announced that you can change the name of photoshop to something
 less hyped and media driven also.

Oh, I'm sure with a hex editor and a resource editor you can change
the name of Photoshop already!  :)

Rockwalrus
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Re: [Gimp-user] keybinding for File-Open Location

2004-09-20 Thread Nathan Summers
On Mon, 20 Sep 2004 20:27:30 +0200, Simon Budig [EMAIL PROTECTED] wrote:
 [Sven pondered changing the CTRL-L shortcut of the layers dialog so that
 it is available for File / Open Location as suggested by the HIG.]
 
 Sven Neumann ([EMAIL PROTECTED]) wrote:
  Simon Budig [EMAIL PROTECTED] writes:
   I frequently use CTRL-L to bring the layers tab to the front, it is a
   handy shortcut.
 Generally I'd like to have some kind of policy on the keyboard
 shortcuts. I tend to be a bit conservative with changing defaults,
 especially when I have to explain changes to people on fairs etc.
 (The Image-Image/Layers reorganisation still bites people - but this
 was IMO a necessary change).
 
 Maybe I am talking blatantly obvious stuff now, but maybe it is the time
 to explicitely state this: We should prefer Gimp-Usability over
 Standard-Compliance. Always. And just because we happen to implement
 lots of the HIG-suggestions that should not imply that we implement
 everything that remotely seems applicable. Especially I'd like to
 suggest better reasoning than it's in the HIG when it is about
 first-class[2] established keyboard shortcuts.

Definately.  The HIG is useful, but even its authors will tell you
it's not perfect, and every single niggly detail isn't necessarily
applicable to every application.  I think in general we should have a
good reason for departing from the HIG, but in this case we definately
have a good reason.

Rockwalrus
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Bug...or do we turn it into a feature?

2004-09-19 Thread Nathan Summers
On Sun, 19 Sep 2004 18:39:29 -0300, Joao S. O. Bueno Calligaris
[EMAIL PROTECTED] wrote:
 Hi,
 
 I just came across  a GIMP behavior that although is a programing
 error, I have liked, and as it may be hard to fix, it could be
 documented to become more a feature than a bug.
 
 It has to do with Quick Mask: If one enables it, and while it is on,
 click to select a new working drawable (either in the Layers or in
 the dialogs channel), the QuickMask will still be visible, but
 drawing will take place on the newly selected drawable.

It seems to me that the correct behavior is that the new drawable
becomes activated, but quickmask is still on -- that is, the paint
tools still affect the selection mask.

Rockwalrus
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Console window on Win32

2004-09-17 Thread Nathan Summers
On Fri, 17 Sep 2004 18:59:38 GMT, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
 
 However, it is in our power
 to work around the problem.  One such workaround is to only
 use a console if a command line option (like --console)
 or an environment variable is set.

Since gtk already meddles with the program's arguments, it's not
unreasonable for this to be done at the gtk level.

Rockwalrus
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Wishes

2004-09-16 Thread Nathan Summers
On 16 Sep 2004 21:03:12 +0200, Sven Neumann [EMAIL PROTECTED] wrote:
 William Skaggs [EMAIL PROTECTED] writes:

  1) The fact that selection tools move things if you click inside the
 selection. . . .  In fact, it actually makes
 things harder for me more often than it makes things easier.  

 Oh? I don't remember to have heard complaints about this before.  IMO
 this is a very useful feature since it makes working with the
 selection tools so intuitive. 

I'll second that it's sometimes annoying, although it's sometimes nice
to have.  When I've thought about it before, I've come to the
conclusion that for me it's nice more often than annoying,  but I can
see how Bill can come to the opposite conclusion.

 IMHO what needs to be done to ease your
 workflow is to let the selection tools modify an existing selection by
 allowing the user to drag the selection borders or some handles
 located at the borders. We would first have to use vectors for the
 selection though.

Yes, we've talked about that before, and I think it would be a pretty
nice improvement, although certainly not trivial to implement.  Is
there a Bugzilla for it already?

  2) The fact that Tool Options persist across sessions, which means that
 any unusual option I use for some momentary reason is bound to come
 back to haunt me in a later session.  I wish at least I could set a
 preference so that all tool options would be reset to their defaults
 at the beginning of each session.
 
 This preference option was planned from the very beginning. Didn't we
 add it already? Oh well, I think we didn't. There's a simple way to
 work around it though: rm -rf ~/.gimp-2.1/tool-options. Probably
 because of this workaround, we have never added the preference.

I have a feeling that most people expect the tool options to not
persist.  If nothing else, I think it would be more useful to be able
to save a tool options state manually and have gimp automatically
restore to that.

Rockwalrus
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] previewarea and drawablepreview

2004-09-15 Thread Nathan Summers
On 15 Sep 2004 12:29:43 +0200, Sven Neumann [EMAIL PROTECTED] wrote:
 geert jordaens [EMAIL PROTECTED] writes:
 The popup menu API is likely going to change before 2.2.
 GimpPreviewArea shouldn't provide a full menu, it should only add the
 checkerboard related submenus. That way our widgets could add other
 things to this menu. GimpPreview should for example add a toggle menu
 item for the Update Preview. I just haven't settled on an API here
 but gimp_preview_area_menu_popup() is not likely going to stay.

GtkUIManager's merging functions seem appropriate here.

 I would really like to see a
 preview widget being added that deals with previewing the effect on a
 scaled-down version of the drawable. That widget would show the full
 drawable and wouldn't need any scrollbars and such. Still looking for
 a good name for this beast...

Off the top of my head:

GimpScalablePreview
GimpScaledPreview
GimpScalePreview
GimpScaledDrawablePreview

Rockwalrus
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] fonts

2004-09-11 Thread Nathan Summers
On 11 Sep 2004 09:28:54 +0200, Sven Neumann [EMAIL PROTECTED] wrote:

 The information given above may be appropriate for adding fonts to
 your win32 system but it is irrelevant for GIMP on Win32. Please read
 my other mail in this very thread.

That's funny.  Works for me.  I'd call the method I use to install
fonts that I use in GIMP on Win32 very relevant.  I don't do anything
that is gimp-specific.  Please see my other mail in this very thread.

Rockwalrus
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] New Image dialog usability bug

2004-09-11 Thread Nathan Summers
On Sat, 11 Sep 2004 07:47:39 -0700, William Skaggs
[EMAIL PROTECTED] wrote:
 
 Remember, even moving a menu entry to a more logical place is
 annoying to many people.  We don't want to offend our most
 loyal customers!

Of course, since this dialog is already radically different from how
it looked in 2.0, making a minor redesign to it now isn't going to
change how different it will appear to users switching from 2.0 in the
slightest.

Rockwalrus
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] fonts

2004-09-10 Thread Nathan Summers
On Fri, 10 Sep 2004 10:47:52 -0700, William Skaggs
[EMAIL PROTECTED] wrote:
 3) How do you add fonts in Windows, and what types of fonts can GIMP use
 there?

The easiest way is to drag the file onto the Fonts directory and let
the shell do its magic.  Unless you've done something creative, it's
probably in its default location of C:\windows\fonts or
C:\winnt\fonts.  Sometimes double-clicking on a font will install it
as well as display it; sometimes it only displays it.  I don't know
what the pattern is.

I would imagine that GIMP can use any type of font on Windows that
FreeType can handle, although figuring out how to install fonts that
Windows can't handle natively is left as an exercise for the reader.

The support Windows has varies by version; all that GIMP runs on
support at least TrueType, Windows FON, and Windows FNT.  2000 and
later support Type 1 and OpenType.  ME supports OpenType.  I don't
know about Type 1.

To install a Type 1 file, you need both the .pfb and .pfm.  Drag the
one that gets an icon into the fonts folder.  The other one doesn't
strictly need to be in the same directory when you drag the file,
since it uses some kind of search algorithm to find it if it's not,
but I'm not sure what the algorithm is, and only know that it does
this because I've accidentally put the other file in the wrong
directory.

Rockwalrus
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


[Gimp-developer] New Image dialog usability bug

2004-09-09 Thread Nathan Summers
Sven suggested that I direct the mailing list's attention to
http://bugzilla.gnome.org/show_bug.cgi?id=152224 to see if there were
any ideas about the best way to go about fixing it.  Basically, if you
enter in that you want a 200 mm x 100 mm image using the order that
makes sense (top to bottom, left to right), you enter 200 in width,
100 in height, and then mm for the units.  Unfortunately, if you were
to do that, you would end up with a 17 x 8.5 mm image, since changing
the units causes the width and height to change as well.

Consistancy is a good thing, of course, and in all the other places
where units are used, this is a very nice behavior to have.  But the
new image dialog is different in that there really are no
pre-existing sizes or units, really.  You are entering new ones from
scratch.

It's not absurd to think of a case where having unit conversion in the
dialog box is useful, but most of the time it's not a desirable
behavior.  Actually, that's being polite.  In reality, it's the kind
of frustrating, annoying thing that I make fun of the stupidity of the
developers when I run across in propriatary code.

There are a couple of ways to fix it that we've discussed on the
bugzilla.  None of them are completely satisfactory.  Does anyone here
have a better idea, or, if not, which of the existing solutions do you
think is best?

Rockwalrus
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer