Re: [Gimp-developer] (python) string don't appear translated

2011-09-02 Thread Joao S. O. Bueno
2011/9/2 Cristian Secară li...@secarica.ro:
 In GIMP 2.7.3 (testing on Windows with the latest development version
 from Sourceforge) there is a menu File - New Brush from Text...

 The New Brush from _Text... string is present in python template
 http://l10n.gnome.org/POT/gimp.master/gimp-python.master.pot
 and is already translated in my Romanian translation file
 http://l10n.gnome.org/POT/gimp.master/gimp-python.master.ro.po

 However, that particular menu displays in English.

Hi Cristian --

thank your for your feedback -
that particular plug-in was added in the current development cycle, and
incorrectly was not marked for translation -

Regards,

   js
  --


 Any known reason for this ?

 Thank you,
 Cristi

 --
 Cristian Secară
 http://www.secarica.ro
 ___
 Gimp-developer mailing list
 Gimp-developer@lists.XCF.Berkeley.EDU
 https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

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


Re: [Gimp-developer] Camp Ticket Presale Closing

2011-07-19 Thread Joao S. O. Bueno
On Tue, Jul 19, 2011 at 5:32 AM, Simon Budig si...@budig.de wrote:
 Michael Natterer (mi...@gimp.org) wrote:
 everybody who wants to come to the camp
 should buy a ticket until *tommorow* the
 20th of July:

 I ordered mine a while ago already and I can only wholeheartedly
 recommend this event.


I won't be able to join you there this year.  Got my fun quote at good
old LGM. - best hacking wishes.

   js
  --

 Bye,
        Simon
 --
              si...@budig.de              http://simon.budig.de/
 ___
 Gimp-developer mailing list
 Gimp-developer@lists.XCF.Berkeley.EDU
 https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

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


Re: [Gimp-developer] I need help about CMYK on gimp

2011-05-23 Thread Joao S. O. Bueno
On Mon, May 23, 2011 at 3:59 AM, Arnon Namsanit arnon.g...@gmail.com wrote:

 Dear GIMP developer team,

 My name is Arnon Namsanit. I am a Thailand government officer working
 for the Ministry of Science and Technology. My team's main
 responsibility is introducing the open source software to Thais
 including GIMP. At the moment we are interested in introducing GIMP to
 a group of users in publisher manufacturing therefore we have been
 discussing about CMYK on GIMP. I might need to ask you some questions
 please.
 - Is there any people currently working on CMYK on GIMP?
 - If yes, How? Can we join them?
 - If no, Could we know the complexities or the problems of that please?
 Since I am not a developer but my organization is able to set up a
 team to implement the module. I would like to have your opinion on
 this please. We are looking forward to hear from you.

 Kind Regards,

Good morning, Arnon,

The agrreded idea among GIMP developers is that CMYK as an _image
 editing mode_ will not be implemented in GIMP. Where as there maybe
in the future more straightforward ways foreasier CMYK separation and printing.
That is due to the fact that CMYK is more the mapping to inks of a
printing method
than a color mode. Even though this is the de facto printing method for
volume, and even personal printing, CMYK values don't have a
1:1 mapping of color values as are visible to the eye, or representable
in computer videos or images. (which color is black in an image?
(100, 100, 100, 0),
(0,0,0,100) or (100, 100, 100,100)?  )

That said, for generating CMYK Tiff files as expected for some of
today's printshops, and even allowing for some per-plate correction
of the amount of colorants in each part of the image, there is the third party
plug-in Separate+ ( http://cue.yellowmagic.info/softwares/separate-plus/ )
I believe that installing and getting used to that might your requirements
for CMYK.

So ..what is the idea for GIMP presently and on the long term, is that proper
printing requires actually conversion between the color spaces of the various
devices used in the press chain (video monitor, proof printer, large
scale printer),
making use of _color profiles_ . With proper calibration of devices and use of
color profiles one can ensure that a color shade will look on paper, under
certain lighting conditions, as it does look on the screen at editing
time. All the
time the colors are represented internally as an RGB tripplet, and
just the printing
driver, or software, takes care of mapping the normalized color to the actual
colorants in use on the device - taking into account information on the
device's color profile.

On GIMP's roadmap, there lays, in the future, a way to preview a per plate
separation of the image prior to having it exported to a CMYK file in a
more integrated way than currently possible with the separate+ plug-in. But that
depends on the implementation of a new, very different, U.I. that will allow
for non-destructive editing, among other things. Work on this U.I. will start
only after current development cycle (which will yield GIMP 2.8).

Meanwhile, if you find that GIMP with the Separate+ plugin is not
enough for your
office's needs, there are other Open Source graphic editing programs that
offer varying CMYK capabilities, such as Krita and Cinepaint.


Regards,

js
   --

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


Re: [Gimp-developer] I need help about CMYK on gimp

2011-05-23 Thread Joao S. O. Bueno
On Mon, May 23, 2011 at 11:05 AM, Bogdan Szczurek thebod...@gmail.com wrote:
 One final thougt: CMYK support subject was touched more than once on this
 list, but I think we should consider much broader view on the matters of
 printing. CMYK is only most often used set of colorants but there are much
 more colorants out there. Having native CMYK would be cool thing but even
 cooler would be to be able to add more colorants to prepared images. What
 about having metallic overprint/underprint in your projects? What about
 Hexachrome? Sure, one could prepare image in wide enough RGB (example ;))
 and rely on profiles with hexachrome or prepare metallic layer in separate
 file but hey… one could also edit RGB files stored channel by channel in
 separate files but what for?

Note that GIMP does offer support for such a a manual spot-color
workflow through the use of Channels - it can work for jobs sporting
one or more distinct spot ink such as metallic or fluorescent.
Although there is no preview or separation for that, at least one can
edit everything in the same .xcf project and export to distinct files.


As for yor other comments, even though they might express a need of
some designers, as you stated, they are not in current GIMP road map
neither seem as a  goal of the program. If one is willing to ditch
color profiling alltogether, and wants to compose an image work only
with colorant intensity, it should be clear that GIMP's code base does
not support that, and another program should be used, unless it can be
achieved with the naive approach offered by image Channels.

Regards,

   js
  --


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


Re: [Gimp-developer] file-psd-save plug-in should embed a color profile

2011-05-06 Thread Joao S. O. Bueno
On Fri, May 6, 2011 at 4:27 AM, Yoshinori Yamakawa y...@yellowmagic.info 
wrote:
 Hi,

 The GIMP can read embeded color profile from the PSD file, but cannot
 save into the PSD file.
  I think that file-psd-save plug-in should embed a color profile.

 I already wrote patch :
 https://bugzilla.gnome.org/show_bug.cgi?id=647361


Very nice - thank you!

I think that an important next step is to get people to indepently
test the files
generated with this patch working, to see if its working fine.
I say that  since most GIMP developers won't have easy access to a Photoshop
to test the generated files.

After that, I think we can just apply it, after a review.


  js
 --


 --
 Yoshinori Yamakawa y...@yellowmagic.info
 ___
 Gimp-developer mailing list
 Gimp-developer@lists.XCF.Berkeley.EDU
 https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

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


Re: [Gimp-developer] Fractal image scaling

2011-04-01 Thread Joao S. O. Bueno
2011/4/1 Александр Белобородов vala...@gmail.com:
 Good evening!
 Liquid scaling is beautiful technology, but differs from fractal scaling
 pretty much.
 The fractal image scaling is based upon an Fractal compression algorythm and
 a functional analisys.
 In the fractal compression algorythm we propose that our image is fixed
 point of contractive affine transformations. Such system of the affine
 transformations is called Iterated function system (IFS). We build the IFS
 based upon our image. Then, to get our image we should take any starting
 point (any image for example) and apply the IFS many times. As the result we
 get our image. That's interesting, that the IFS don't know about image
 resolution, and we can take an big resolution image as the starting point.
 This way of image scaling is noted by Stephen Welstead in his book Fractal
 and Wavelet Image Compression Techniques (Chapter 3, 3.6. Resolution
 independence).
 If it is not good approach, could you offer me another task related to image
 processing research field?
 Regards, Alexander Beloborodov.]



Hi Alexander -

I myself find this idea very interesting. Certainly, a fractal scaling
algorithm of some sort should find its way into GEGL.

Can you elaborate a bit more, or give us a link to a digest article
describing fractal scaling?
In order to consider it as a project, the motivation and advantages of
it should be clear to all developers, so that your project is voted
up.

Your e-mail above is still a bit cryptic on the capabilities of this
algorithm regarding what could be available for the final user. You
describe the general lines on how does, but we don't know now what it
does. For example - can it scale up and down? Can it compare,
visually, to the algorithms already implemented in GIMP? Does it offer
at least a theoretical big advantage for the final user? (/me hopes so
:-)  )

Thanks,

  js
 --



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


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


Re: [Gimp-developer] Enabling a 2.8 release: planning for a 2.10 release

2011-03-15 Thread Joao S. O. Bueno
On Tue, Mar 15, 2011 at 4:43 AM, Martin Nordholts ense...@gmail.com wrote:
 On 03/14/2011 11:59 AM, Joao S. O. Bueno wrote:
 Hi,

 This decision, as I see it, change the release date from within
 months to within some weeks -

 May I ask for the calculations that led you to the conclusion that we
 are weeks away from a release? I haven't done the math yet, but I still
 expect us to be months away from a release.


 I hope you have in mind that Translators have to  know about so they
 can update translations as possible, as well. At some reasonable point
 before the release, a string freeze status for GIMPshould be set
 (even if a few string chanegs are to happen after that).

 Thanks for the reminder. We should probably enter a soft string freeze
 soon...


 Other than translation, we have to work the Python bindings so there
 are no functionality regressions, (whch includes the ability to work
 with layer groups) -
 so to the above list of bugs, we shuld at least have one more about this 
 task.
 (this also depends on being able to transform layer groups).

 Not including API to work with layer groups in Python is not a
 regression, it's just missing functionality in one of the scripting
 languages. It is unfortunate if GIMP 2.8 will be released without layer
 groups support in Python, but the alternative is worse: not releasing
 GIMP 2.8 at all. And we should arrange for the Python bindings to be
 automatically generated from the PDB rather than wasting man-weeks on
 manually keeping it up to date. Not an easy task perhaps, but the only
 sensible one.

Scripts which previously interated through layers are currently not
working. That is a regression.
Possibly making layer groups transform work seamlessly.

I will do my best to include such support personally over the next few
days - allright if you think it shoud
not be a blocker.


The python bindings do work from the PDB. The current matter with
layer groups is that they introduce a new kind o f object, and the
Python bindngs on't work with simple integer IDs that the PDB use -
there must be a corresponding object on the Python side. (it won't
cost a single man week to integrate it - but I've been so absetn I
ahven't weven checked the PDB calls available to deal with layer
groups yet).


  js
 --


  / Martin


 --

 My GIMP Blog:
 http://www.chromecode.com/
 Why GIMP 2.8 is not released yet
 ___
 Gimp-developer mailing list
 Gimp-developer@lists.XCF.Berkeley.EDU
 https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

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


Re: [Gimp-developer] CMYK file export plug-in

2011-03-12 Thread Joao S. O. Bueno
On Sat, Mar 12, 2011 at 5:15 PM, Yoshinori Yamakawa
y...@yellowmagic.info wrote:
 Hi,

 According to the GIMP Roadmap, it seems to take time very much for the
 CMYK support to be added to the GIMP.

 Now we can use the separate+ plug-in, but I think that the separate+
 plug-in is not proper for the GIMP distribution because the separate+
 plug-in has unnecessary features for general users and the separate+
 workflow is not very seamless.

 The Separate+ team has written the subset version of separate+ (named
 separate-) as a GIMP file plug-in. Separate- is the CMYK file exporter
 and is very simple to use. It supports TIFF, JPEG and Photoshop PSD formats.

 https://bugzilla.gnome.org/show_bug.cgi?id=640613


From the feedback I have from users here in Brazil - and I mean
professional artists
working with FreeSoftware, I'd say it would be very important if we
could get this in GIMP 2.8

Even if for gimp 3.0 and beyod we think of CMYK exports in a totally
different way - all plug-ins will have to be rethough when we get to
GIMP 3.0 anyway. The demand for this ability however we agree that it
is not the best approach, is very high in the professional levels. At
least around here, where the print stores  use to require
pre-separated artwork from the authors.

Regards,

  js
 --


 --
 Yoshinori Yamakawa y...@yellowmagic.info
 ___
 Gimp-developer mailing list
 Gimp-developer@lists.XCF.Berkeley.EDU
 https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

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


Re: [Gimp-developer] Adding a layer mode

2011-03-02 Thread Joao S. O. Bueno
On Wed, Mar 2, 2011 at 10:00 PM, Jörn P. Meier li...@netgods.de wrote:
 Hi,

 I would like to implement the following layer mode in the GIMP:

 1) Transform destination and source pixels to HSL space.
 2) Note original destination pixel saturation.
 3) Set luminance component of destination pixel to luminance component
    of source pixel.
 4) Transform destination to HSV color space.
 5) Set saturation of destination pixel to original saturation of
    destination pixel.

 I'm assuming destination is also the result of the operation. Not sure
 how GIMP handles this, though.

 The purpose of the mode is to colorize a greyscale image while keeping
 both the saturation and hue data of the color layer and the luminance
 data of the greyscale image. Existing modes (as far as I see)
 unfortunately either mess up the color information or the luminance
 information.


Hi John ---

regardless of the desired operation, it would be very difficult to
stick a new layer operation in GIMP  -
due to file compatibilities, and everything else.

When I first started hacking around the GIMP source code, some years
ago, new layer operations
also where something that I messed with.

But see..even if one doe shave a great idea, and a nice pacth taht
wuld be included in the GIMP's source, there would be a problem of
compatibility of new XCF images using the new layer mode, and older
GIMP versions around.

So, while, yes, you could create a new layer mode just to poke around,
it would be of little use other than for yourself. (Regardless, it is
fun enough, I suggest you try it). If you get a usefull enough result,
maybe yu could make a plug-in that would combine two normal layers
using the algorithm you describe. You loose all real time niceness,
but at least you can achieve your result. (and this plug-in can be
passed around to others).


As for where to create a layer mode-- there are some files - -I don
remember which now -- part of the fun is locating them -- you get to
know yoru way around GIMP. You will even find out that there are
different  code paths to render layers on the source tree. There are
all the files on the app/composite directory -- or one can enable GEGL
compositing, for which the files are under app/gegl

This article can have some usefull hints on how to poke around GIMP' s source:
http://www.ibm.com/developerworks/linux/library/os-gimp

Regards,

   js
  --



 So, the question is, what changes would I need to make to add this
 layer mode?

 I would be very grateful for any hints. :)

 Cheers,

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

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


Re: [Gimp-developer] gimp-item-transform-scale vs gimp-drawable-transform-scale

2011-02-11 Thread Joao S. O. Bueno
On Fri, Feb 11, 2011 at 11:13 AM, Ofnuts ofn...@laposte.net wrote:

 On 02/11/2011 01:02 PM, Alexander Rabtchevich wrote:
 I apologize, you are right. I apparently only added links to
 the new context functions from the new selection API.

 It's the new context API, e.g. gimp_context_set_interpolation().
 Will add the docs after work today.

 Hmmm. What proportion of existing plug-ins working in 2.6 will have to
 be rewritten for 2.8? In my neck of the IT woods, within the same
 version backward compatibility is implied... And if a rewrite is
 necessary we will have to support both versions for quite some time
 (some people fall in love with some plug-ins and won't upgrade Gimp
 until there is a new version  of their beloved plug-in). And do it again
 when 3.0 shows up...


Most existing plug-ins will just work in gimp 2.8 - at least in
non-layer group using images (and
most plug-ins don't care about more than the current layer/drawable,
so these will work anyway, just
not on the group, but on individual layers).

The fact that some procedures are marked as  deprecated does not
mean they will
stop working in gimp-2.8: they are still there. New plug-ins are
however expected not to use
these calls (an expectation that is strongly enforced by the fact that
the deprecated procedures have their
documentation replaced by a stub)

When the time comes to GIMP 3.0, that is another history - - chanigng
in the major version number
also means it is time to break backwards compatibility, and remove
deprecated functions. But that is not the
case for 2.8.

   js
  --




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

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


Re: [Gimp-developer] gimp-item-transform-scale vs gimp-drawable-transform-scale

2011-02-11 Thread Joao S. O. Bueno
On Fri, Feb 11, 2011 at 12:41 PM, Øyvind Kolås pip...@gimp.org wrote:
 On Fri, Feb 11, 2011 at 1:13 PM, Ofnuts ofn...@laposte.net wrote:

 On 02/11/2011 01:02 PM, Alexander Rabtchevich wrote:
 I apologize, you are right. I apparently only added links to
 the new context functions from the new selection API.

 It's the new context API, e.g. gimp_context_set_interpolation().
 Will add the docs after work today.

 Hmmm. What proportion of existing plug-ins working in 2.6 will have to
 be rewritten for 2.8? In my neck of the IT woods, within the same
 version backward compatibility is implied... And if a rewrite is
 necessary we will have to support both versions for quite some time
 (some people fall in love with some plug-ins and won't upgrade Gimp
 until there is a new version  of their beloved plug-in). And do it again
 when 3.0 shows up...

 But the rewriting needed for 3.0, porting to be GEGL ops, can be done
 already now, and I would strongly encourage GIMP to make use of GEGL
 ops more on an equal footing to GIMP plug-ins (and not be hidden in an
 own menu under the GEGL tool like it is now) so that freshly developed
 plug-ins can be done as GEGL ops already now and be more future proof.


For example, people usually marvel at the GEGL c2g filter - and it is
completly hidden
under tools-GEGL operations.

Maybe it could be somewhat more exposed as an option in
Colors-desaturate, or filters-artistic?

  js
 --


 /Øyvind K.
 --
 «The future is already here. It's just not very evenly distributed»
                                                  -- William Gibson
 http://pippin.gimp.org/                     http://gegl.org/contribute.html
 ___
 Gimp-developer mailing list
 Gimp-developer@lists.XCF.Berkeley.EDU
 https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

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


Re: [Gimp-developer] Creating sub-directories from Script-Fu scripts

2011-02-07 Thread Joao S. O. Bueno
On Mon, Feb 7, 2011 at 1:24 PM, Alexia Death alexiade...@gmail.com wrote:
 On Mon, Feb 7, 2011 at 4:12 PM, Rob Antonishen rob.antonis...@gmail.com 
 wrote:
 In particular, (system command) would be real handy.

 It would also make gimp scripts easily exploitable for abuse on the
 system, like exectuting malware.



Well.. since we never put a single thought in hardening script-fu
scripts against being explotable for abuse - then it is all for the
better that the possibilities are explicit, and available for users.


It is clear that running a complete-featured language program wihtout
a carelfully constructed sandbox environment pretty much gives the
script access to all resources the user runningt he script has. It is
hard to make it otherwise in specific environments to avoid that - so
I think this  is a non-issue.


Note that I still advice anyone trying more sophisticated scripts to
do so in Python, but I see no point in artificially restricting
tiny-fu.

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

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


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

2011-02-01 Thread Joao S. O. Bueno
On Tue, Feb 1, 2011 at 1:45 PM, Alexandre Prokoudine
alexandre.prokoud...@gmail.com wrote:

 Because people talk about the big picture. Pretty please carefully
 reread what Jon Cruz wrote in the thread. It's a spot-on message.

You mean Jon Senior?

  js
 --


 Alexandre Prokoudine
 http://libregraphicsworld.org
 ___
 Gimp-developer mailing list
 Gimp-developer@lists.XCF.Berkeley.EDU
 https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

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


Re: [Gimp-developer] GIMP GNU GPLv3/LGPLv3 in general (was: Re: distributing gimp with another program)

2010-11-22 Thread Joao S. O. Bueno
On Mon, Nov 22, 2010 at 8:04 AM, Michael Schumacher schum...@gmx.de wrote:
 Von: Christopher Curtis ccurt...@gmail.com

 *** (Sven, Mitch) ***

 This LICENSE text should probably be updated as 'Section 2' of GPLv3
 doesn't talk about aggregations - it's been moved into section 5.  It
 might also be useful to address this issue directly as the GPLv2 is
 generally well understood to allow command line usage as an
 'aggregation', but GPLv3 seems to muddy this distinction.

 At the moment I'm not even sure if GIMP should be licensed under GPLv3 
 without a much better understanding of the license.
 For example, the fact that it is now impossible to use GPLv2-only libraries 
 in plug-in wasn't considered at all. It's not such much the fact that we 
 can't use them anymore, rather the problem of no one even thinking about it 
 when we changed the license version to v3.

 I have contacted the Freedom Task Force of the FSF in order to get help, and 
 they requested more details. Unfortunately my spare time (or the lack 
 thereof) didn't allow me to write a reply yet.


 I'd be glad to learn about any additional side-effects of a GPLv3-licensed 
 GIMP (note that libgimp* is licensed under LGPLv3) that may surprise us - but 
 please base them on actual FSF information and not mere speculation.



Since a long time ago, we had an exception of the license for plug-ins
in a sense that GIMP plug-ins can be non GPL. If you as much as take a
look at the LICENSE file provided in the tree, it is at the second and
third paragraphs.

Therefore, there should be no problem in suiong GPLv2 or any other
license for libraries linking to plug-ins.

 js
 --



 Regards,
 Michael
 --
 Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief!
 Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail
 ___
 Gimp-developer mailing list
 Gimp-developer@lists.XCF.Berkeley.EDU
 https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

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


Re: [Gimp-developer] Blocking for...@gimpusers.com

2010-11-16 Thread Joao S. O. Bueno
On Tue, Nov 16, 2010 at 6:28 PM, g...@catking.net wrote:

 Hi,

 the running polemical thread on VG filter has made me aware of what is
 presumably a new feature on that gimpusers.com blog that allows users of
 the site direct access to this list via the address  for...@gimpusers.com

 Would it be a best to simply block this address?

 Anyone wishing to discuss gimp-devel can sign up here and join the list.
 Letting users spam the list with inane comments form a blog is probably
 not productive.

 A request could be made to remove that from the blog but bouncing that
 address would probably be quicker and easier.


 regards, gg


No - we rather let people participate -
the amount of messages on that topic is not that overwhelming - and anyone
not interested might simply ignore it by subject.

  js
  --



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

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


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

2010-09-27 Thread Joao S. O. Bueno
On Mon, Sep 27, 2010 at 3:45 AM, Ofnuts ofn...@laposte.net wrote:
 On 24/09/2010 17:05, Joao S. O. Bueno wrote:

 On Fri, Sep 24, 2010 at 11:19 AM, Ofnutsofn...@laposte.net  wrote:
   Hi,

 My code needs to do a one-pixel-wide selection, at distance x from the
 current selection.  This looks a lot like a border selection except that
 the border selection creates at best a two-pixel wide ribbon and I only
 want one (but if I'm wrong, please tell me how to :-)

 So far my code goes like this:

 # Selects pixels that are between x and x+1 pixels from
 # the original selection. Bumping the selection by one
 # each time doesn't work, a small circle degenerates into
 # a square with rounded corners instead of a big circle.
      def select_ribbon(self,image,selection,dist):
          pdb.gimp_selection_load(selection)
          pdb.gimp_selection_grow(image,dist+1)
          outer=pdb.gimp_selection_save(image)
          pdb.gimp_selection_load(selection)
          pdb.gimp_selection_grow(image,dist)
          inner=pdb.gimp_selection_save(image)
          pdb.gimp_channel_combine_masks(outer,inner,CHANNEL_OP_SUBTRACT,0,0)
          pdb.gimp_selection_load(outer)
          image.remove_channel(outer)
          image.remove_channel(inner)

 That works, but can be slow (especially since it's at the core of a
 loop). Is there any better way? Or useless code to jettison?

 Next improvement is to create a 3-pixels selection and feather it one
 pixel. Anything to be wary of?

 Hmm..this _will_ be slow. :-)

 You can speed it up by making a copy of your drawable to another
 image, disable the undo system on this new image  and perform your
 cations above, before copying the results back to the original image -
 but it is about it.
 Maybe you can perform the whole loop in the copy with undo disabled -
 but I don't know your intent.

 Disabling undo on the main image (just for tests) doesn't show much
 speed gain (from 2'03 to 1'56 in my test). It's only better memory-wise.


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

  js
  --

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

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


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

2010-09-24 Thread Joao S. O. Bueno
On Fri, Sep 24, 2010 at 11:19 AM, Ofnuts ofn...@laposte.net wrote:
  Hi,

 My code needs to do a one-pixel-wide selection, at distance x from the
 current selection.  This looks a lot like a border selection except that
 the border selection creates at best a two-pixel wide ribbon and I only
 want one (but if I'm wrong, please tell me how to :-)

 So far my code goes like this:

 # Selects pixels that are between x and x+1 pixels from
 # the original selection. Bumping the selection by one
 # each time doesn't work, a small circle degenerates into
 # a square with rounded corners instead of a big circle.
     def select_ribbon(self,image,selection,dist):
         pdb.gimp_selection_load(selection)
         pdb.gimp_selection_grow(image,dist+1)
         outer=pdb.gimp_selection_save(image)
         pdb.gimp_selection_load(selection)
         pdb.gimp_selection_grow(image,dist)
         inner=pdb.gimp_selection_save(image)
         pdb.gimp_channel_combine_masks(outer,inner,CHANNEL_OP_SUBTRACT,0,0)
         pdb.gimp_selection_load(outer)
         image.remove_channel(outer)
         image.remove_channel(inner)

 That works, but can be slow (especially since it's at the core of a
 loop). Is there any better way? Or useless code to jettison?

 Next improvement is to create a 3-pixels selection and feather it one
 pixel. Anything to be wary of?

Hmm..this _will_ be slow. :-)

You can speed it up by making a copy of your drawable to another
image, disable the undo system on this new image  and perform your
cations above, before copying the results back to the original image -
but it is about it.
Maybe you can perform the whole loop in the copy with undo disabled -
but I don't know your intent.

  js
  --



 --
 Ofnuts

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

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


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

2010-09-20 Thread Joao S. O. Bueno
On Mon, Sep 20, 2010 at 7:38 AM,  oli...@first.in-berlin.de wrote:
 On Mon, Sep 20, 2010 at 01:39:42PM +0400, Alexandre Prokoudine wrote:
 [...]
 The way things are going native RAW support in GIMP using GEGL + some
 can-opener library will likely require a dedicated developer in the
 team. Which the team doesn't seem to have right now, being heavily
 shorthanded and outnumbered.
 [...]


Oliver -

this rant has no reason to be.  Sorry for that.
It makes no sense to start working in a project the size of GIMP
without having to learn the code already in there first.

What do you mean by a workshop? Like a physical face to face class,
where one would be pointing this is the tools directory, inside it
there are the files that ,make for the tool classes...? Not shure if
that could help.

Anyway, I've written an article a couplle of months ago that is now
published here:
http://www.ibm.com/developerworks/linux/library/os-gimp/index.html?ca=drs-
Maybe that fulfills part of what you call a workshop.

Now, please - these kindof rants won't change anyones atitude in here
- the developers willjust feel ill towards you. Keep experimenting,
trying, learning, and asking about code - refrain from rants: they
just take us nowhere.

regards,

   js
  --

 (...)

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

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


[Gimp-developer] Fwd: Drawing per Script

2010-09-13 Thread Joao S. O. Bueno
On Sun, Sep 12, 2010 at 8:58 AM,  oli...@first.in-berlin.de wrote:
 Hello,


Hi


 I tried drawing per Script.
 I'm using Python.

 I can already use vectors for drawing circles,
 and set single points.

 I did not found a way to create rectangles,
 or lines.


You are probablu using pdb_gimp_vectors_bezier_stroke_new_ellipse
to draw circles, right?
What does prevent you from using the calls for
gimp_vectors_bezier_stroke_new_moveto and
gimp_vectors_bezier_stroke_lineto to draw lines?
(Don't  forget to alias then in your code to shorter names, last you
have really undereadable stuff)

Still, creating a vectors object from stroking is one way of painting
with scripts in GIMP (the recomended one to draw curves and circles,
though) - for stragiht lines you can use pdb.gimp_paintbrush instead.





 Aren't there pdb-functions that draw a line?

 Do I have to create it pixelwise?
 In a loop?


As I stated above, there are calls to draw lines.
Are you even using the procedure browser? (Help menu -  Procedure browser) -

In Python you can access the image data directly, using calls to get
the pixel regions if you want to as well (that is about 100x  faster
than gimp_drawable_set_pixel  due to the function calls involved for
each pixel change)


 When using the circle drawing with vectors I would
 expect that this technique can do it's work fast.
 But it's very slow (using a loop to set paths in those vectors).
 (In OpenGL for example there are Vertex Arrays that can be used to speed up
  drawing. Something like that in GIMP, and available for scripting would be 
 nice.)

Sorry to tell you that - tehre is some slowdown in using the PDB, but
this is more or less as fast as it gets using GIMP to draw yiu stroken
circles. You probably coukd get some speed-u dealing straight with the
image data if you don't need the stroking engines from GIMP - i.e. -
no need to use different brushes, gradients, dynamics and so on)
If so you can get some significant speed-up using C, or maybe even
python if you get an efficient way to draw your circles using pixel
data.
(A suggestion would be to cache different pixel data for the circles
with the radii you want, as gimp-buffers, and paste then on the desred
places on teh image - that shoul be much  faster than
creating/stroking paths)


 (I also saw, that what on the GUI are Paths internally are called vectors.
 To make things better undesrstandable, it would make sense to give things the
 same name... but maybe there is more to vectors and I don't see it so far.
 Why are there different names?)


 will leave that up to Simon :-)


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


So, besides my hints above: when I need speed on a PDB using script
(which includes python scripts),
I found out that GIMP's undo system is the cause for a significant slow down.
Creating an Undo group does not help - you have to disbale the undo with
pdb.gimp_image_undo_disable
This can give you a 3x to 4x times improvement when you have many
small operations going on (like drawing thousands of circles) .
Unfortunatelly this spoins the undo system for you rimage -even after
a call to undo_enable.
If you are editing the image interactvely I suggest you make your script to:
- copy the drawable you are interested to a new image
- disable the undo system on the new image
- perform your painting operations
 - copy the drawable back to the original image
(and destroy the newly created image, of course)




 This seems very slow to me.

 If I also would need to write pixels of a line pixel-wise,
If you weant 1 pixel thick straight lines, use the pencil tool and the
pixel brush.

 I would also await to have very slow scripts.
 Special functions for drawing lines from within Python-plugins,
 that use C-speed would be fine.



Regards,

 js
 --

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

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


Re: [Gimp-developer] Fwd: Drawing per Script

2010-09-13 Thread Joao S. O. Bueno
On Mon, Sep 13, 2010 at 8:56 PM,  oli...@first.in-berlin.de wrote:
 Hi,

 On Mon, Sep 13, 2010 at 05:21:09PM -0300, Joao S. O. Bueno wrote:
 On Sun, Sep 12, 2010 at 8:58 AM,  oli...@first.in-berlin.de wrote:
  Hello,


 Hi

 
  I tried drawing per Script.
  I'm using Python.
 
  I can already use vectors for drawing circles,
  and set single points.
 
  I did not found a way to create rectangles,
  or lines.


 You are probablu using pdb_gimp_vectors_bezier_stroke_new_ellipse
 to draw circles, right?

 I use:
  pdb.gimp_vectors_bezier_stroke_new_ellipse


Your way is the correct - mine was just a typo - a thing I excel in.

 So I think it's what you are talking about, just
 the absolute name is different.



 What does prevent you from using the calls for
 gimp_vectors_bezier_stroke_new_moveto and
 gimp_vectors_bezier_stroke_lineto to draw lines?

 I looked for draw and did not find functions that do it.
 So, in short words: I did not found thos functions.

yes-- the procedure broswer has this downside --
you have to keep looking with related words if you don't find
something at first.

 (Don't  forget to alias then in your code to shorter names, last you
 have really undereadable stuff)

 If it does not eat up too much ressources in Python...

It does not.
What is delaying the execution is much more the nature of the PDB and
the Undo system than python.

With aliasing I mea just attributing the pdb functions to a local
variable - with lines like these at the start of your function (or
even at the start of your module):

lineto = pdb.gimp_vectors_bezier_stroke_new_lineto
ellipse = pdb.gimp_vectors_bezier_stroke_new_ellipse

From then on you can jsut type ellipse( ...)  instead of the long
name designed to avoid namespace clash.
This does not create new functions - you call the very same function,
 just using another name.

 ...you mean using def for creating a function that just calls the other one?
 or are aliases what Python offers as a separate feature?



 [...]
  Aren't there pdb-functions that draw a line?
 
  Do I have to create it pixelwise?
  In a loop?
 

 As I stated above, there are calls to draw lines.
 Are you even using the procedure browser? (Help menu -  Procedure browser) -

 I use the procedure browser.
 But it does not help me, if I look for names that aren't there
 ...if I look for draw I got nothing.
 The circle-drawing function via bezier I found by accident/chance.

If you type vectors you will see all teh vector related functions.
Howeer to paint straight without using a path, you have to look for
the tool name:
pencil, paintbrush, etc...


 In Python you can access the image data directly, using calls to get
 the pixel regions if you want to as well (that is about 100x  faster
 than gimp_drawable_set_pixel  due to the function calls involved for
 each pixel change)

 How can I access the pixel data directly?

 That would be very interesting to me, especially for some other scripts,
 where I think about even more intensive work.

px = drawable.get_pixel_rgn(top, left, width, height)
px [:, :]  = \xff\x00\x00 * drawable.width * drawable.height()
drawable.update(top, left, width, height)

The get_pixel_region and update are methods of GIMP drawable objects.

The item assignment to set/reset pixels is a bit aukward - the example above
paints the whole drawable in red (if it is  a 3BPP RGB channel, else
you willget an
error telling the setting string is of the wrong size)

For serious work with pixel regions you might prefer to copy the pixel
data to a Numpy array - ther eyou can work with numbers from 0 to 2545
instead of having to convert all data to string prior to setting the
pixels.


 [...]
 So, besides my hints above: when I need speed on a PDB using script
 (which includes python scripts),
 I found out that GIMP's undo system is the cause for a significant slow down.
 Creating an Undo group does not help - you have to disbale the undo with
 pdb.gimp_image_undo_disable

 OK, I will try that.


 Thanks for all that hints. :)

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


regards,

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


Re: [Gimp-developer] make layer active when enabling its visibility

2010-08-16 Thread Joao S. O. Bueno
On Mon, Aug 16, 2010 at 8:57 AM, tmaes thierry.m...@gmail.com wrote:

 Hi, here is an enhacement request I posted in the bugzilla, Martin Nordholts 
 told me to send it to the mailinglist, so I hope I post it in the right place:

 I often have this problem:

 when enabling/disabling layers visibility during my work, to choose in whitch
 layer I want to work, when I find the one I want, I directly go to the image
 and draw... but sadly, it is in the last active layer that I draw and the 
 result
 is not what I wanted.
 I think it would be more ergonomic if the turned on layer becomes
 automatically the active layer. At least, if people could choose this
 behaviour(instead of the actual) in the preferences, it would be great, I
 think.

 I hope my description is understandable.
 Regards to all,


Hi Thierry -

While this behavior can make for a productive workflow in you case, it
would otherwise break completely the way the program behaves now - it
would be impossible for one turning on another layer to continue
painting where he was previously. In contrast,  activating the newly
visible layer is just a  matter of one additional click for who wants
this to happen.

So I think your request is not feasible in the way it stands.

On a connected issue, there is a somewhat hidden feature regarding
activating layers: in the preferences dialog, on the tool options, you
can set the Move tool to automatically select the moved layer (that is
not the default behavior) - and on the Image Windows tab of the
preferences, you can set the Space bar to switch temporarily to the
Move tool (instead of the default 'pan') - in that way, you can have a
fast and agile workflow to change the active layer, by pressing space
and clicking on a part of the image on the desired layer.

Regards,

  js
  --


 --
 Thierry Maes

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

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


Re: [Gimp-developer] Help with new default resources in 2.8

2010-07-19 Thread Joao S. O. Bueno
On Mon, Jul 19, 2010 at 10:49 AM, peter sikking pe...@mmiworks.net wrote:
 hi all,

 the reason I talked myself into the position of 'maintainer of default
 resources' (is that a title like 'floor manager' at mcdonalds?) at the
 LGM is that I voiced concern over how they can either enhance or
 sabotage the product vision:
 (...)

 one last thing: we have a green pepper problem. it fails several of
 criteria outlined above, but the GIMP team seems to be emotionally
 attached to it. similar to the GIMP name, we seem to wear it as a
 badge of honour. so I am 50/50 on in/out. this may prove to be
 the hardest decision of my career ^}

One thing that applies to to the pepper , but may ease the conflict of
what should go in or not:
maybe the default resources could be tagged to default -- and
instead of showing all items at program satrt=up, we could show just
the deffault tagged items.

That way, the pepper, sun, wine brushes could go under a bitmap tag,
but have no default tag attached. That would also make it easier to
display just the wanted gradients - several of the gradients shipped
with GIMP are used in tiny-fu scripts.

(as for the pepper per se, my personal opinion: I have no problem at
all with it going away. I have _one_ real use for it: it helps me to
locate the pixel brush, since it is next to it in alphabetical order.
The pixel brush should, IMHO, be tagged pixel by default, so it
can be found with less keystrokes)


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


Re: [Gimp-developer] Gimp UX: Paste

2010-06-02 Thread Joao S. O. Bueno
Hi, This has just been discussed in the Libre Graphics Meeting which
just took place, and should be the main subject of the Summer of Code
project I am mentoring.

there are other motives for the Floating Selection (i.e. the quasi
layer) to exist, but of course, the existing usability for that is
way broken.  We will be working closely with peter Siking to get
pasted objects to behave in the most useful and unobtrusive way
possible.

  js
  --

On Wed, Jun 2, 2010 at 10:14 AM, Michael Schumacher schum...@gmx.de wrote:
 Von: Jason Simanek jsima...@gmail.com

 Thanks for listening. If a discussion about these issues has already
 taken place, please provide URLs to those discussions. I have no
 intention of reopening discussions that have already been resolved.

 https://bugzilla.gnome.org/show_bug.cgi?id=561576


 HTH,
 Michael
 --
 GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
 Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
 ___
 Gimp-developer mailing list
 Gimp-developer@lists.XCF.Berkeley.EDU
 https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

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


Re: [Gimp-developer] Question on new (2.8) paint dynamics

2010-05-20 Thread Joao S. O. Bueno
On Thu, May 20, 2010 at 10:35 AM, Rob Antonishen
rob.antonis...@gmail.com wrote:
 I will have to play with the force setting. I a looking to have a
 pixmap brush be lighter or darker based on brush pressure. Maybe
 explained like a dynamic dodge/burn applied to the brush source while
 painting?

Features apart, Rob, you can use some sort of source layer tracking
by using the clone tool instead. Just use it in registered mode, and
explore the painting modes/ painting on the layer mask, etc...

Regards,

   js





 -Rob A

 On 5/20/10, Alexia Death alexiade...@gmail.com wrote:
 On Thu, May 20, 2010 at 7:13 AM, Rob Antonishen
 rob.antonis...@gmail.com wrote:
 I have looked at some of the previews and devel paint dynamic
 reports/reviews and still have a couple questions.

 In amongst all those settings is there any trace a source layer as an
 option?
 No. and there wont be one in this iteration either. Its nontrivial and
 probably pretty slow to access pixel under cursor for dynamics
 evaluation and the whole thing needs to stabilize first. there are
 other simpler dynamics inputs that are proposed, but not happening for
 2.8, like the position of the cursor in the image.

 And along with that is there a brush dynamic to control the gamma of a
 brush while painting?  (This would be much like hardness for
 parametric brushes but for colour (stamp) type brushes would have some
 value).

 What do you mean by gamma? There is the Force output. It tries to
 emulate the force a brush is applied  to the canvas with, that
 saturates some parts of the brush when applied. It has been part of
 gimp for ages, under the name of hardness but it is not really
 hardness as used in vector brushes so it has a new name now.

 --
 --Alexia


 --
 Sent from my mobile device
 ___
 Gimp-developer mailing list
 Gimp-developer@lists.XCF.Berkeley.EDU
 https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

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


[Gimp-developer] Still GIMP @ LGM 2010

2010-05-13 Thread Joao S. O. Bueno
So,

When I emailed about this subject last week, I've been told everyone
was already booked up and talks registered: it looks like teh talk
registration is not quite complete, and we have to fill in the details
for the LGM programme.

Who is intending to talk? Peter? GSoC mentors? (including myself)?
We shouldprovide then some details ASAP.


 js
 --


-- Forwarded message --
From: Femke Snelting snelt...@collectifs.net
Date: Thu, May 13, 2010 at 8:51 AM
Subject: Re: GIMP @ LGM 2010
To: gwid...@gmail.com


Hey Joao

Any news on who will be there for Gimp :-)

We're finalizing the program right now and it would be great to know
more about your contributions.

Here's what the programme looks like at the moment:
http://ospublish.constantvzw.org/documents/LGM2010/LGM_programme_110510.pdf

all the best + hope to hear soon

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


Re: [Gimp-developer] Still GIMP @ LGM 2010

2010-05-13 Thread Joao S. O. Bueno
On Thu, May 13, 2010 at 1:08 PM, Tobias Ellinghaus h...@gmx.de wrote:
 Am Donnerstag, 13. Mai 2010 schrub Michael Schumacher:
 On 13.05.2010 14:46, Joao S. O. Bueno wrote:
  So,
 
  When I emailed about this subject last week, I've been told everyone
  was already booked up and talks registered: it looks like teh talk
  registration is not quite complete, and we have to fill in the details
  for the LGM programme.

 No idea what the Saturday 100:00 talk is supposed to be, but for...

  Who is intending to talk? Peter? GSoC mentors? (including myself)?
  We shouldprovide then some details ASAP.

 ... there are two talk proposals in their wiki:

 http://create.freedesktop.org/wiki/A_first_outline_for_a_UI_for_a_fully_GEG
 Led_GIMP
 http://create.freedesktop.org/wiki/Writing_GIMP_scripts_and_plug-ins

 According to [0] those two are scheduled for thursday, yet there is still a
 half hour slot on saturday which just reads GIMP.

So - maybe we should take this slot to demonstrate thenews in 2.7
master and GSoC projects?
Who could do the talk?



 HTH,
 Michael

 Tobias

 [0]
 http://ospublish.constantvzw.org/documents/LGM2010/LGM_programme_070510.pdf
 ___
 Gimp-developer mailing list
 Gimp-developer@lists.XCF.Berkeley.EDU
 https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

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


Re: [Gimp-developer] Fwd: GIMP @ LGM 2010

2010-05-07 Thread Joao S. O. Bueno
On Fri, May 7, 2010 at 7:46 AM, Michael Schumacher schum...@gmx.de wrote:
 Von: Joao S. O. Bueno gwid...@mpc.com.br

 I think I have seen no e-mail on this list about LGM 2010 - it is due
 in a couple weeks.

 That's because everything has been discussed on IRC - the participants are 
 registered, two talks and one lightning talk have been proposed, everyone has 
 travel and hotel booked, ...

 ... and we've agreed on handling reimbursement with GIMP money.

Ok; Since I had been absent from IRC, I know nothing of the discussions.
I've got myself travel tickets  yesterday. - Can you give me details
on the hotel people are staying?

   js
  --


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


Re: [Gimp-developer] Creating a new Layer

2010-05-06 Thread Joao S. O. Bueno
Hi Thales --

thank you for your feedback  -  we will take that in account while
working in the UI -

However, this need of yours can be easily implemented through a script
- either in Python or Script-fu (if you are on Windows and have issues
configuring GIMP- Python) -- this would give yiou this feature
immediatelly (instead of you having to wait several months for a new
gimp release).

feel free to write further if you want more information on such a plug-in.

  js
  --


On Thu, May 6, 2010 at 11:24 AM, Thales img tha...@imgbrasil.com wrote:
 Hello,
 I have an idea and I'd like to know what you think about it.
 Let's suppose a situation:
 We make a 100 x 100px rectangle selection on a 2000 x 2000px, and we want to
 create a new layer to paint the rectangle, so when we  ask a for a new layer
 a popup is opened asking Name, Width, Height, etc, for the new layer, for
 default the Width and Height values are 2000px² (our document's size), we
 click Ok and we have a new layer.
 My point here it is that we have a 2000px² layer for a 100px² object, and as
 I can see - as a user - a 2000px² consumes more performance(I don't know if
 it's Memory or CPU) than a 100px².
 So my idea is to have a option when creating a new layer; maybe a checkbox
 with something like:

 [__] Follow Selection's Size
 Did I make myself clear?

 Anyway, thanks for the attention,
 Thales
 --
 Thales Oliveira - Img Brasil
 +55 31 (8365 3869 - 3309 8760)

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


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


[Gimp-developer] Fwd: GIMP @ LGM 2010

2010-05-06 Thread Joao S. O. Bueno
Moin -

Hi folks -

I think I have seen no e-mail on this list about LGM 2010 - it is due
in a couple weeks.
(I know I am at fault with the reimbursements for last year - lets get
that moving as well)

So, who is intending to get to Brussels? Can someone help organizing the lists?
We also should have to plan GIMP activities beforehand.

I  just got the e-mail pasted bellow from Femke

regards,

   js
  --


-- Forwarded message --
From: Femke Snelting fe...@constantvzw.org
Date: Thu, May 6, 2010 at 4:43 PM
Subject: GIMP @ LGM 2010
To: gwid...@gmail.com
Cc: Jon Phillips j...@rejon.org, Louis Desjardins
louis.desjard...@gmail.com, Nathan Willis nwil...@glyphography.com


Hello Joao,

I'm Femke, local organiser for LGM 2010.

We're currently finalising the program and I was wondering whether
GIMP team members would like to give talks, demo's or anything else?

Do you have plans for sponsoring teammembers to participate in the
Brussels meeting and if so, is there any way we can help to do this?

Let me know!

best,


Femke
--
Constant: Association for Art and Media | Rue du Fort straat 5 | 1060
Brussels Belgium | t/f +32(0)2 5392467 | http://www.constantvzw.org

        *
   *
 *
 *
  *
    *
      *
         *
             *
                 C O N S T A N T
                      V Z W
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] square brushes

2010-04-25 Thread Joao S. O. Bueno
On Sat, Apr 24, 2010 at 12:29 PM, Alexandre Prokoudine
alexandre.prokoud...@gmail.com wrote:
 Hi,

 An interesting issue was brought up by a user. It really isn't easy
 defining a square brush with a particular length of a side. For
 example, creating a square brush with a side exactly 2px large.

 Could anything sensible be done about that? (Apart from telling users
 they don't really need 2px large square brushes, that is :))



Hi Prokoudine --

Right now, I am afraid it would not be easy - and I don't see how
someone could go and work on change the measurement on radius for
generated brushes to side when the shape is square.

However, a way to create a 2px square brush would be to make a 2x2px
selection in agrayscale image, , copy it and edit- paste as -
brush...

It would be easy to have that as a plug-in, but I can't think of a way
such a plug-in would not clutter the menus.

However, now that I mentioned it, ther is a File - create[...] action
that create a brush. (create brush from phrase)

Maybe we could come along with some more 2 or 3 ideas to populate a
file-create-brush...  submenu. There an Exact square brush...
could easily fit.

Let's see whatthe maintainers and Peter have to say on sucha  submenu,
and throw in some ideas on whatthe other entries could be.

regards,

   js
  --

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


Re: [Gimp-developer] [Gimp-user] [GSoC] Student applications can be submitted, mentors please sign up

2010-04-05 Thread Joao S. O. Bueno
Hi Schumanl --

I am apply8ng as a mentor, as I intend to mentor Thiago's work on Siox
integration and implementation of a second algorithm for segmentation
- as can beseeen on his e-mails.

On Mon, Apr 5, 2010 at 1:50 PM, Michael Schumacher schum...@gmx.de wrote:
 Hi,

 the student application period for Google Summer of Code 2010 is on.
 Applications can be submitted until 2010-04-09, 19:00 UTC

 1. Students
 ---

 To apply, visit http://socghop.appspot.com/ and follow the instructions.


 2. Mentors
 --

 Sign up at
 http://socghop.appspot.com/gsoc/org/apply_mentor/google/gsoc2010 and pay
 attention to your notifications.


 3. Next important dates
 ---

 2010-04-09, 19:00 UTC : Student application period ends

 2010-04-21, 07:00 UTC : All mentors have to be signed up, all viable
 proposals have to have a mentor assigned

 2010-04-21, 17:00 UTC : Application scoring period ends


 GIMP  GEGL GSoC home page:
 ---

 http://socghop.appspot.com/gsoc/org/home/google/gsoc2010/gimp


 Regards,
 Michael

 --
    GIMP  http://www.gimp.org      | IRC: irc://irc.gimp.org/gimp
 Plug-ins  http://registry.gimp.org | .de: http://gimpforum.de
 ___
 Gimp-user mailing list
 gimp-u...@lists.xcf.berkeley.edu
 https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user

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


Re: [Gimp-developer] GSOC proposal: cage-based transform tool

2010-03-25 Thread Joao S. O. Bueno
On Wed, Mar 24, 2010 at 5:14 PM, Alexia Death alexiade...@gmail.com wrote:
 Hi:)

 The basic behavior of this tool would be:
 - you put a closed polygon on the image (not limited to 4 handles)
 - you deform the cage, the image is deformed accordingly
 - user can choice if the pixels can go outside of the cage or not. In the
 normal behavior of the Green Coordinates, the pixels can overflow the cage,
 due to the shape preservation.

 I looked through the paper and examples there were very impressive.
 This tool can be the tool of choice for many use-cases currently
 handled by iwarp plugin and perspective transform in a much more
 convenient and usable way. As a project it has great potential.

 Im thinking, it might make sense to implement it as a gegl op with UI
 in gimp. however, we dont have an example of such tool yet...


Haven't checked the references - but it sounds like the same UI could
be used to perform the Liquid Resize magic, currently existing as a
3rd party plug-in - what do you say?


  js
 --



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

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


Re: [Gimp-developer] GSOC proposal: cage-based transform tool

2010-03-25 Thread Joao S. O. Bueno
On Thu, Mar 25, 2010 at 1:23 PM, Alexia Death alexiade...@gmail.com wrote:
 On Thu, Mar 25, 2010 at 6:12 PM, Joao S. O. Bueno gwid...@mpc.com.br wrote:
 On Wed, Mar 24, 2010 at 5:14 PM, Alexia Death alexiade...@gmail.com wrote:
 Haven't checked the references - but it sounds like the same UI could
 be used to perform the Liquid Resize magic, currently existing as a
 3rd party plug-in - what do you say?
 Could you point me to the plug-in? I don't think Ive seen it before

http://liquidrescale.wikidot.com/

It does the trick thatadobe sohowed off in the new photoshop yesterday
-- it is quite well maintained - I keep the .pt_BR translation for it.
 Give it a try, it is worth it.


 --
 --Alexia

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


Re: [Gimp-developer] remove layer should not force you to last selected layer

2010-03-05 Thread Joao S. O. Bueno
On Fri, Mar 5, 2010 at 3:05 PM, Akkana Peck akk...@shallowsky.com wrote:
 Luiz Felipe Moraes Pereira writes:
 Also I do not mind much about not having a selected layer after
 the deletion of a layer. But the forced viewer scroll down( or up ),
 depending of the last selected layer is a problem.

 This used to annoy me a lot, because I frequently want to delete,
 say, the top 5 layers. But once I figured out what it was doing,
 I developed a habit of clicking on the layers I want to delete in
 sequence before deleting. For instance, click on the 5th layer from
 the top, then the 4th, and so on until I get to the top; then click
 Delete 5 times. It sounds tedious but it doesn't take long at all --
 certainly it's a lot faster than scrolling back up each time.
 Try it -- you may find that it solves the problem.


yes, I do that as well.

The new Layer Groups feature in 2.7 will ease this and several other
workflows a whole lot.
(For example, probably all the layers you are deleting, if more than
one, would not be themselves part of the same group - you just have to
delete the group)


  js
  --

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

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


Re: [Gimp-developer] enhancement: warnings instead of fatal error for duplicate calls to gimp_env_init

2010-03-03 Thread Joao S. O. Bueno
On Tue, Mar 2, 2010 at 2:58 PM, Sven Neumann s...@gimp.org wrote:
 On Tue, 2010-03-02 at 08:01 -0500, lloyd konneker wrote:
 Yes, I will submit a proper patch.  I'm new but I can figure it out.

 I mainly wanted to get feedback whether it was desirable.  I'm not clear
 when a discussion of an enhancement should move to Bugzilla.

 More testing reveals other issues and test cases:

 First, most plugins have unguarded calls to register(), so importing
 some plugins from a plugin ends up reregistering a plugin, with a
 warning to stderr from the Gimp PDB but apparently harmlessly.  I'm
 still exploring, eg whether the order in which plugins are loaded
 matters, whether the warning is only for local plugins, whether Gimp
 supports multiple registrations of different plugins from the same
 Python source, etc.

 I wonder if importing a plug-in from another plug-in is really something
 that we want to support. If the goal is to share code, then perhaps the
 code that is worth sharing should be factored out into a Python module
 that the plug-ins can import.


Every Python program is also able to be a python module that plug-ins
can import. We should preserve this feature of the language.

(For example, one can implement an app with a comand line interface,
and then just add a GUI in another file that uses the functions
defined on the stand-alone first file).


 Sven


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


Re: [Gimp-developer] enhancement: warnings instead of fatal error for duplicate calls to gimp_env_init

2010-03-03 Thread Joao S. O. Bueno
On Wed, Mar 3, 2010 at 9:07 AM, Sven Neumann s...@gimp.org wrote:
 On Wed, 2010-03-03 at 08:46 -0300, Joao S. O. Bueno wrote:

  I wonder if importing a plug-in from another plug-in is really something
  that we want to support. If the goal is to share code, then perhaps the
  code that is worth sharing should be factored out into a Python module
  that the plug-ins can import.
 

 Every Python program is also able to be a python module that plug-ins
 can import. We should preserve this feature of the language.

 What exactly does that statement mean for the problem at hand?

Means that the language has a feature to make development easier: that
is it eases up reuse of the code by requiring less source code fiels
to achieve the same tasks.

So - it is not usual for a Python developer to be required do factor
out a fully working source code file, that can be used as a stand
alone piece, in order to re-use parts of the code in that file in
other applications. The language has a trivial, elegant and seamless
mechanism to allow this.

The problem at hand as I see is exactly to preserve this Python
language feature in GIMP plug-ins.

On the other hand, simply putting a python module that is not a fully
functional plug-in in GIMP's plug-ins directory, would cause GIMP to
issue error messages on start-up , due to failed plug-in
initialization.  All GIMP will see is an executable .py file along
with the plug-ins.

Having to provide a directory structure, hacking with import paths,
etc...just because one wants to share, say a couple RGB-HSV
functions in a set of 2 or 3 plug-ins is overkill.

   js
  --






 Sven


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

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


Re: [Gimp-developer] Gimp - prolog interface

2009-12-03 Thread Joao S. O. Bueno
Hi Ryan -

I strongly suggest you learn python instead, and us it for your
scripts, instead.

It attends eveeryone of yoru requisites:
- no dealing with pointers or memory allocation/deallocation
- gimp data structures are provided as high level objects
- the language syntax even allows for a funciotnal-like programing if
you prefer that.

(for example to interact through layers, you just do:
image = gimp.list_images()[0]
for layer in image.layers:
#your code dealing with the layer object

When you get to the pixels you have then as a byte sequence, you then
convert to a bytearray (python 2.6)  - to get all the green bytes for
the pixels from such an array on a separate array, I could do:

green =[1::4]

Follow the tutorial in www.python.org docs, you could get proficient
in the language in less than 1 hour - then check the pythons cripts
that come with gimp for examples of the API use and pixel access.


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


Re: [Gimp-developer] GIMP to be removed from Ubuntu Lucid Lynx?

2009-11-19 Thread Joao S. O. Bueno
On Thu, Nov 19, 2009 at 4:48 PM, Alexandre Prokoudine
alexandre.prokoud...@gmail.com wrote:
 On Thu, Nov 19, 2009 at 9:45 PM, Thorsten Wilms  wrote:

 I have been in that session and can confirm it.

 OK, but what session? At UDS?

Yes, friend of mine was tehre, confirmed it too. (btw, it evenshowed
up in slashdot).

IMHO, stupidiest decision ever - they _want_ their users to be dumb
and continue that way. As for me, up to today I used to recomend
ubuntu to people I presented Free Software. (despite some ongoing
really great flaws, like translating the name of special user folders
such as Desktop and Documents). Now, with the promise of a GIMPless
Ubuntu, I will burn some other distro for people to taste Linux and
Free Software.




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

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


Re: [Gimp-developer] What would be a better set of default resources?

2009-07-27 Thread Joao S. O. Bueno
Getting back to the start of this discussion --

I am in talks with the new mantainer of a very popular brazillian GIMP 
comunity portal this week (Guilherme coordinating www.ogimp.com.br  with 
~20.000 unique visitors a day)-- he has resources of his own which could be 
made available eitehr in GIMP or in gimp-data-extras . Moreovr a call for 
help on these online comunities could result in a large number of 
contributions from Brazillian artists (most with poor English comunication 
skills)

So it ocurred to me: maybe we could make a call for contributions for new 
resources, and some open voting mechanism. The top rated artwork would make it 
into GIMP as patterns and brushes, and some  more could be made available in 
gimp-data-extras .  

The last call for contributions of this kind we had, taht I rememebr, was for 
the gimp 2.2's splash screen, and had a good number of nice submitions.

Guilerme, me, and other brazillian Free Graphics software contributors could 
help to assemble the needed structure for voting + contributing in a few weeks 
- we could set some prdefined tags to help orient the contributions (like 
natural brushes, clip-art, and so on) and  populate the gimp-data-extras 
package with them.

(Of course I am talking about itnernational contributions, not only .br ones - 
some 'call for clip-art' well placed announcements could make it)

So, any objections to something like this?  

If anyone think this might have drawbacks an alternative would be to make a 
low-profile 'trial' and put the results in a branch for review. 

  js
  --


On Sunday 19 July 2009, Martin Nordholts wrote:
 Hi,

 With the integration of tagging support in GIMP we have a mechanism that
 allows us to organize resources (brushes, patterns, palettes, and
 gradients). This enables us to add a bigger set of default resources.

 Not being an artist myself makes me rather useless for this task. To get
 things rolling I thought I'd start a discussion on what a better set of
 default resources would be.

 A few things are clear:

   * The new default resources must fit the product vision [1]
   * The resources must be very general in nature
   * We can't have a huge set of resources since we need to keep
 the size of the tarball within reasonable limits
   * We not only need resources, we also need to assign tags to them

 I think we at least should:

   * Add larger variants of the circle and fuzzy circle
 brushes, say 50, 100, 250 and 500 px
   * Try to get rid of the Pepper, Sparks and Vine brushes
 in a backwards compatible way

 Does anyone have any suggestions on adjustments and additions to the
 default set of GIMP resources?

   / Martin


 [1] http://gui.gimp.org/index.php/GIMP_UI_Redesign#product_vision
 ___
 Gimp-developer mailing list
 Gimp-developer@lists.XCF.Berkeley.EDU
 https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


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


Re: [Gimp-developer] http post or ftp post

2009-07-25 Thread Joao S. O. Bueno
On Saturday 25 July 2009, Nico wrote:
 Hi

 Is it possible to send data (http and/or ftp) in a script-fu plugin ?
 Some examples ?
 Wich way ?

 Nico

The Scheme intrpreter used in script-fu it is there because an scheme 
interpreter is tiny enough to fit inside the source tree. (And for historical 
reasons as well, of course.) There are no libraries or moduyle to provide the 
tiny-fu scheme with much outside the GIMP API and some basic file I/O.
So, while with unixish systems it is possible to provide a pipe/socket setup 
to make tiny-fu scripts answer network requests, that is not the way to do it.

For doing larger applications, you should use plug-ins in a language that can 
make full use of libraries and modules manintained outside of the GIMP 
project.  The oficial high level language supported for GIMP plug-ins is 
Python, and it is  easy to make data available via vairous network protocols 
using Python's standard libraries.

There re also gimp bindings for perl (although I think this is currently 
unmaintained) and ruby should you prefer these languages. 

  js
  --



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


Re: [Gimp-developer] What would be a better set of default resources?

2009-07-21 Thread Joao S. O. Bueno
On Monday 20 July 2009, Sven Neumann wrote:
 Hi,

 On Mon, 2009-07-20 at 00:36 +0200, Martin Nordholts wrote:
* Try to get rid of the Pepper, Sparks and Vine brushes
  in a backwards compatible way

 You can just remove those if we agree that they are not useful. I doubt
 that any script out there actually uses them. This is different for the
 main geometric brushes. They are actually used and it would be nice if
 we could add code that avoids breaking scripts if we decide to remove
 them.

 +1 from me for the removal of all brushes that only serve as an example
 but have no other value for the user.

I d'be against the removal of the vintage pixmaped brushes.

However, what I think would be a good solution for preserving compatibility 
would also take these out of the way of users, while keping then available for 
scripts or anyone who looks for them.

Basically: we have to figure out a way of GIMP not displayin all available 
resources if no tag filtering is active. By figuring out a way, I mean an 
interface way. 

Then, woud be a matter of tagging the unwanted-by-default backwards compatible 
brushes with an specifc tag (like classic), that would not be shown. 

If changes in the current behavior of displaying everything when there are no 
tag filters are not desirable, the way to achieve this would be simply to tag 
the resoruces we want showing with default, and this tag could come pre-
selected on the UI. 


js
--

 Sven


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


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


Re: [Gimp-developer] What would be a better set of default resources?

2009-07-21 Thread Joao S. O. Bueno
On Tuesday 21 July 2009, Sven Neumann wrote:
  Why? Tell us a good reason then why we should keep them.

On Tuesday 21 July 2009, Rob Antonishen wrote:
 One reason to keep some image hose brushes in the default set is just
 to demonstrate that gimp supports them!  I participate in a web forum
 for amateur cartography, and one of the most common requests is how to
 use tubes with photoshop.  Most are extremely impressed that this
 capability exists in Gimp.


Thanks Rob --
that is goog reason enough.

Sven: 
Besides, with the current set, without these, GIMP woul be a  100% bw 
boring looking program - A litle bit of color in the brushes would be needed 
for this reason alone, IMHO. 

It is true that when lecturing on GIMP I usually to say that the best use for 
the Pepper brush is to help us locate the Pixel brush, right next to it  :-)
(but then, I'd actually favor a whole set of fruit  vegetable brushes to 
ship by default with GIMP)

Alexia also holds that they should stay in terms even more clear than Rob did: 
they help one experimentt with the brush dynamics, color combination modes and 
otehr painting settings in ways that generated brushes or monochrome + alpha 
brushes can't help.

Now, my tagging proposal would just keep then available for people and scritps 
alike, while making then 100% non-obtrusive, - I don' t understand why you 
haven't commented on that.

 js
 --

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


Re: [Gimp-developer] API for bringing up a Save dialog

2009-07-12 Thread Joao S. O. Bueno
On Friday 29 May 2009, Martin Nordholts wrote:
 Akkana Peck wrote:
  I'd like a way of bringing up a Save-as or Export-as dialog
  from a Python script. There's no API for this currently, as far
  as I can tell.

 The Save and Export dialogs are rather tightly coupled to the core
 currently so it will not be trivial to extend the plug-in API to show
 and interact these dialogs but I would not reject patches that
 implemented it properly.

  Would be be possible to add an API for this, or maybe an optional
  argument in gimp_file_save and the corresponding _export function?

 IMO we should not reuse gimp_file_save() for this but instead introduce
 gimp_show_save_dialog() and gimp_show_export_dialog(). I am a bit
 worried however that plug-ins will abuse this power. In your case, why
 do you need to show these dialogs? Isn't it better if the user has to go
 through a single place to save or export?


Certainly not -- the idea of plug-ins is to automate workflows!
And a common enoguh use case is to save a modified copy of an image - or a 
series of images with diferences between them (although this would need a  
folder + file name pattern rther than =justa  file path).


Akkana: I've never missed callign the save or export dialogs because I 
normally use the PF_FILE and PF_DIRECTORY entry parameters for my plug-ins 
taht deal with file export.  Aren't they (with gimp_file_save) enough for your 
use case? 



  In the new framework, will gimp_file_save() fail if the filename isn't
  xcf?

 No, the existing API needs to be backwards compatible so even though it
 is unfortunate that _save() can be used to export, we need to allow that
 for the sake of backwards compatibility.

  / Martin

  js
  --

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


Re: [Gimp-developer] API for bringing up a Save dialog

2009-07-12 Thread Joao S. O. Bueno
k!!

The E-mail client is showing me unread messages from months ago as if they 
where New  :-(
Sorry for digging into this ancient thread.  :-(  


js
--

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


[Gimp-developer] brush rotation - abotu the chanegs on 10-feb-09

2009-02-10 Thread Joao S. O. Bueno
Hi,

I am aware that it is a work in progress --
just to let you know (Alexia and others) - the changes in the two commits 
dated 10-feb-2009 got things a lot worse and less natural for me than it was 
before.  

I am nto complainign, I know a lot of tunning is getting in, and I am writing 
this just for feedback while you adjust it.

Now, I f I paint slowly, the brush will suddenly reverse its angle - Also, if 
I mark the direction x angle dynamic, the painting angle does nto feel 
natural, and it felt before - at least when I use a brush that is oriented 
towards up like an up arrow, or the letter A  - both behaviores were 
better previously.

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


[Gimp-developer] brush rotation

2009-02-08 Thread Joao S. O. Bueno
For those of you who don'tṫ follow trunk closely or the irc channel, I can't 
resist the urge to tell that Alexia Death and Mich have been working on brush 
dynamics over the last few days - and have thus far added brush rotation.
It now works both as a fixed factor and following painting direction. 
Yaii!!

(as any brand new feature, it still buggy and error prone, but they are 
actvelyy fixing everything)

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


[Gimp-developer] Travel expenses estimates for LGM 2009

2009-02-03 Thread Joao S. O. Bueno
So people,

As for Louis'e-mail I had forwarded a couple weeks back, 
I am collecting the travel estimates for GIMP people who wants to attend LGM 
2009 in Montreál.

Please write me at gwidion(at)gmail.com  

Regards,

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


[Gimp-developer] trunk - new status for empty images

2009-01-30 Thread Joao S. O. Bueno


2009-01-29  Sven Neumann  s...@gimp.org

* app/tools/gimptool.c (gimp_tool_oper_update): if the image is
empty and the tool can't handle that, display a message in the
statusbar telling the user about this.

That works great! thanks, Sven.

But when trying i I could not help bu tnote it also show upswht the text 
tool -- 
text tool should be able to work with an epty image, should'nt it?

The move tool, o the other hand, is not displaying the message properly. I t 
does, however whe n I try to move a path on a 0 layer image - then, instead 
of moving the path it eels me it is expecing layers.

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


[Gimp-developer] Fwd: LGM 2009 Travel cost estimation

2009-01-20 Thread Joao S. O. Bueno
Hi there --

just got this from Louis.
I can  handle the estimated costs and assemble a spreadsheet as I've done 
in '07. -
So I'd like those of you who intend to go to Montreal on the beginning of May  
send me your travel estimates (please use the gmail address -  
gwid...@gmail.com as I've had blacklisting problems with this .br one)

js
--
 
--  Forwarded Message  --

Subject: LGM 2009 Travel cost estimation
Date: Tuesday 20 January 2009
From: Louis Desjardins louis.desjard...@gmail.com
To: Bryce Harrington bryce@, Joao S. O. Bueno gwid...@mpc.com.br, mrb@
Hi Bryce, Joao and Craig,

* Please feel free to reforward this email to the person in your team that
could help gather the estimated travel costs for the LGM participants.

So here we are! We need to establish a rough budget for now and for this I
would need within the next 2 weeks a fair estimate of the travel costs per
team. Please include the name of the developers and the amount for the
flight or train or car to Montreal. This can be in Euros or USD, as needed.
Try to be as precise as possible.

My first rough bet is we're looking at 40K USD but it could be more or
less... I need to know.

Also, if anyone can give a hand with the sponsors, we would all be happy!

Please let me hear some feedback. You can cc all so we all know who's in
charge of what, who responded and what.

Thanks!

Looking forward to welcome you again in MTL!

Louis

---
___
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-11 Thread Joao S. O. Bueno
On Friday 09 January 2009, Martin Nordholts wrote:
 Michael Natterer wrote:
  On Fri, 2009-01-09 at 15:36 +0800, C Wang wrote:
 
  So finally, I hereby suggest to move to GPL3 asap.
 
  Comments from any developers appreciated.

 Hi

 I agree, it's about time we move to GPLv3 now.

I am all for it as well!
js
--

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


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


Re: [Gimp-developer] Fwd: [CREATE] Suggested dates for LGM 2009 Montreal

2008-11-09 Thread Joao S. O. Bueno
On Sunday 09 November 2008, Sven Neumann wrote:
 Hi,

 On Fri, 2008-11-07 at 20:31 -0200, Joao S. O. Bueno wrote:
  May 6-7-8-9, 2009.

 
  LGM would start on Wednesday morning and end on Saturday, end of the day!

 That would mean taking at least four days off to participate in the
 conference. That makes it very hard for anyone who has a regular job.

The format is under discussion, as are the dates. 
What do you think about proposing something like having teo core days on the 
weekend, and one or two days before that for end usre talks and workshops?

Something like: thee mroe technical oriented, and inter-software operation 
talks for subjects like GEGL, the Create Raster format, etc..all would be 
scheduled on Saturday, and on Sunday we schedule inter-team BOFs and other 
thing, like the in the first LGM), and thurday and friday would have using 
the GIMP, doing great art with Inskcape, maybe a plug-in creation 
workshop, and such? 


(btw, at my regular job, if I am going to an itnernational conference, I can 
have the extra days off)


 Sven


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


[Gimp-developer] Fwd: [CREATE] Suggested dates for LGM 2009 Montreal

2008-11-07 Thread Joao S. O. Bueno
So -
anyone wnat a say on the proposed dates for LGM (bellow)?

Regards,

js
--

--  Forwarded Message  --

Subject: [CREATE] Suggested dates for LGM 2009 Montreal
Date: Friday 07 November 2008
From: Louis Desjardins [EMAIL PROTECTED]
To: Create ML [EMAIL PROTECTED]

Hi all,

Here are the best possible dates for LGM 2009.

May 6-7-8-9, 2009.

LGM would start on Wednesday morning and end on Saturday, end of the day!
(maybe with a party?!?!)

Before we make that the official dates, anyone with serious concerns about
those dates, please speak up asap!

Side note : we could move that from 7-10 including Sunday instead of
Wednesday. But why not take Sunday to visit... or relax... of have a beer on
a terrasse!!! :-) Or a poutine! ;-)

Anyway, you let me know!

Cheers!!!

Louis

--
Louis Desjardins
Organiser
Libre Graphics Meeting 2009 - Montréal

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


Re: [Gimp-developer] Better grouping of layer modes

2008-11-04 Thread Joao S. O. Bueno
On Tuesday 04 November 2008, David Gowers wrote:
 Hi vabijou,

 On Wed, Nov 5, 2008 at 2:21 AM, vabijou2 [EMAIL PROTECTED] wrote:
  peter sikking wrote:
  the only thing I would change is to swap the order of Grain merge and
  Grain extract. simply because it is explained as a workflow in that
  order in the manual.
 
  I would also like to see a dynamically updated list at the top of the
  list that shows the last 3-5 used blend modes under a heading of
  Recent:.  This may be outside the scope of the OP's original
  suggestion, but for many users there are a select few modes that are used
  frequently, and having to dig through a long list slows things down.

 I am such a user, and I say: This is a change I do not want, it would
 reduce my working speed further.
 This is because of the way recently-accessed lists work -- the most
 recent is at the top. This means unless I am constantly selecting
 *the* most recent (instead of eg. 2nd most recent), where I have to
 click to achieve the same result changes, because my choice reorders
 the list.

 In conjunction with locking functionality (so that your later choices
 no longer change the order or content of the recent-list), this could
 be effective. I would honestly like similar locking functionality for
 the recent-filters-list .. the constant disordering is just so
 confusing and slow that I usually find it faster to select from the
 original menu path.. which defeats the purpose.


David, 
as far as filters are concerned, I'd strongly, and that means __strongly__, 
suggest you to use keyboard shrotcuts to get to your filters. 
Yes,  stopping ytour work to configure keyboard shortcuts is a major pita, and 
that is why most people donṫ do it in any software, even knowing it is 
possible. However, GIMP has setup a unique feature that was once available to 
all GTK+ applications: 
dynamic keyboard shortcuts. 
Just enable these once in preferences, and you will never again have to selct 
a single filter in the thrid menu level more than once. The tooltip on the 
edit-preferences-interface option that enable these shortcuts is self 
explanatory.

As for layer combination modes...Martin, is there any clean way of allowiyng 
setting keyboard shortcuts to layer combiantion modes? That ḋ be a nice 
feature to have.


js
--



 David


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


Re: [Gimp-developer] make the layer name still

2008-11-03 Thread Joao S. O. Bueno
On Monday 03 November 2008, Martin Nordholts wrote:
 [EMAIL PROTECTED] wrote:
  hi guys and girls :)
 
  As far as we know the name, we still have to scroll the slider to reach
  it. So what is my purpose? Could we add another shortcut to make the
  layer name still? For example right button click. It would make my life
  easier. :)

 Hi!

 Edit - Preferences - Tool Options - Move Tool, Set layer or path as
 active

 Then you can select layers with the Move Tool.


Actually, this is the only sane way of working with GIMP at all.
I can't really understand why the default behavior had changed to the current 
one (not keeping the picked layer). Probably it was a matter of  mimicking 
the main proprietary similar program once again.

And even then, at the time of the change, I remember restoring the classic 
behavior as a tool option, and this was later changed from a  tool option to 
a tool preference, and got hidden deep in the preferences dialog where it 
can't be found by anyone, unless one ask the developers thenselves (like it 
just happened).
I remeber the excuse for hidding it in preferences was nto to polutte the 
tool options with many options. Right now, I have there: 
Move tool: 4 lines worth of options. 
Blend tool: 8 lines in the tool options
Bucket fill: 15 lines in the tool options!!!

(move tool would bump to merely 6 six lines of widgets with the option for 
the keep selected layer  there in plain view of everyone).

Anyone feeling like reconsidering this, unless we get layer groupign and a 
completley new way of getting to layers on gimp 2.8 ?



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


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


Re: [Gimp-developer] [CREATE] LGM 2009 Proposals

2008-10-16 Thread Joao S. O. Bueno
On Wednesday 15 October 2008, Louis Desjardins wrote:
 2008/10/8 Sven Neumann [EMAIL PROTECTED]

  Hi,
 
  On Tue, 2008-10-07 at 10:39 +0200, Dave Neary wrote:
   I've previously proposed a committee made up of ex-organisers and the
   biggest attending projects. That is, a group of 6 with:
   Me, Louis, Kamila, and someone from each of the GIMP, Inkscape and
   Scribus (probably Sven, don't know who from Inkscape (Bryce maybe?) and
   either Peter or Craig).
 
  I don't think I will have time to become part of that committee. And I
  haven't even been at Montreal, nor do I expect to find time for next
  year's LGM. But I am sure we can find someone else from the GIMP team
  for the committee.

 Hi Sven,

 I am cc'ing the gimp dev list so we find a good soul from the GIMP team to
 be part of the LGM committee. If anyone is interested in representing the
 GIMP team, please don't be shy and show up here quick! We need to make a
 decision for next year's venue. A week ago, we thought 2 weeks would be
 fine to complete the discussion. So we have one more week from now. I
 propose that we make that decision by Friday, October 24. Is that ok?


/me steps forward.

I've been GIMP LGM contact  person for 2007 (for 2008, I had been 
mostly unreachable, tough). If no one else is picking that, it would ok for 
me.

As well, I am looking forward to bring LGM to Brazil - but not in 2009 - I am 
looking at a 2010/11 timeframe. Anyway, I will be talkign to the right 
people in a conference at the end of the month.  (The same one Bolhs attended 
once, in Foz do Iguaçu)

js
--

 Cheers!

 Louis

 p.s. I have made a slight update on
 http://create.freedesktop.org/wiki/index.php/Conference Please follow the
 Montreal link to find out.

  Sven
 
 
  ___
  CREATE mailing list
  [EMAIL PROTECTED]
  http://lists.freedesktop.org/mailman/listinfo/create


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


Re: [Gimp-developer] [CREATE] LGM 2009 Proposals

2008-10-16 Thread Joao S. O. Bueno
On Friday 17 October 2008, Dalai Felinto wrote:
 LGM in Brazil?
 This would be awesome.

 We have already the BlenderPRO www.blender.pro.br that is a one day
 Blender event. And I will look forward for this initiative.
 2010/11 looks a little distance but I'm interested about the plans.

 I have the feeling that this is not the proper channel to specifically
 follows LGM discussion.
 João, there is another site/email list/... that you plain to put your
 ideas and actions regarding that?

Yes, the create list: [EMAIL PROTECTED] 
[EMAIL PROTECTED], 
http://create.freedesktop.org/wiki/index.php/Conference 

 Cheers,

 Dalai
 http://blenderecia.orgfree.com

 ps.: congratulations and thanks for the new GIMP.
 It's becoming a very stable/robust software.

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


Re: [Gimp-developer] Python back-up files

2008-09-27 Thread Joao S. O. Bueno
On Saturday 27 September 2008, Chris Mohler wrote:
 On Sat, Sep 27, 2008 at 6:16 PM, Samuel [EMAIL PROTECTED] wrote:
  Another question from me:
 
  When I write a plugin, my text editor (kwrite or kate) creates a backup
  file named plugin.py~. When I start now the plugin in GIMP, it is
  executing the backup instead the original.

 Hi,

 I think you should file a bug against kwrite and kate - while it's a
 good idea to create backup files, I see no reason why they should have
 the execute bit turned on (even if the file you are editing is
 executable).
Yes.
I have filed such a bug some years ago.  
Never fixed that I remember.
Onthe same day I flied the same bug against  gedit - they did implement the 
fix some 18 months later or so. 

But as for kde editors, the only way to go is to delete the backup files by 
hand. :-(

js
--

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


___
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-22 Thread Joao S. O. Bueno
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.

IMHO wilber's sleep would be too easily associated with the lack of some 
features that are waiting to be implemented for a long time - that among 
those who already know the program.

Among those who don't know the program, it would be rather difficult to 
associate the sleeping wilber with a really great product.

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


[Gimp-developer] 2.6 splash screen

2008-09-22 Thread Joao S. O. Bueno
There have been on the list a few propostions for splash screens. 

It is a quite hard decision to pick one above others. It is allright if one is 
quietly picked up, or developed under request by one of the long time 
contributors.

However since we alrady have more than one proposal, and from project 
contributors, maybe tehre should eb a more formal process for choosing a 
splash screen?

For Gimp 2.2 we made a widerepad contest, havign to select from hundreds of 
entries.  Maybe this time we could just formalize a deadline, and having some 
people to pick one from the presented entries - but without making the 
widespread advertisement. 

I do volunteer for helping picking the best one, but I am ok if we just have a 
date and a single person picks one and commit it. 

I just don't think we will have the best choice if people sparsely send their 
entries to this list, and whoever feels compeled enough comment on it. There 
is the matter of having to publicly express teh motives why one feels or 
thinks an entry should not qualify (like I just did) - and that is annoying 
both for the proponent and for the one who comments negatively on the 
proposal.

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


Re: [Gimp-developer] Should we replace the 'Zoom when res izing image window'-button?

2008-08-10 Thread Joao S. O. Bueno
On Sunday 10 August 2008, Akkana Peck wrote:
 Martin Nordholts writes:
  Hi
 
  There is a little button in the upper right corner of each image
  window with the tooltip Zoom image when window size changes.
 
  I have never used this and I can't figure out in what way it is
  useful.

 It's useful in that it lets you scale the window exactly as big
 as you want -- you're not limited to 25%, 33%, 50%, 100% etc.

 That said ...

  Does anyone ever use it?

 I don't (partly because I always forget it's there). I set the
 Resize on zoom preference, and usually scale with the +/-/1 keys.

  I suggest we replace it with a shortcut to the Resize window on
  zoom option which I find much more useful.
 
  Does anyone have any objections to this? Should some completely
  other feature be accessible through that button?

 It seems odd to devote space to toggling a preference like that
 ... in theory, the current functionality seems more useful since
 it lets you do something that isn't otherwise possible. But as
 I said, I don't actually use it very often in practice. And it's
 not very discoverable. I didn't know from the tooltip what it would
 do and only found out by experimentation. It might be clearer if
 the tooltip added a few words, e.g. Zoom image to fit window
 when window size changes or Zoom image proportionally when window
 size changes.

I don'tṫ know how many people actually rely on this toggle. But this 
is a usefull behavior when you scale up small image by a 2 or 3 times 
factor (rather usefull), and could be anooying when scalling down. 

So maybe, one thing would be to make GIMP's defuaslt behavior to be:
- if the image is scaled up and the window is smaller than a certain 
percent of the screen(like 60%, or space for the main window + 
dockables at the sides), the iamge window would increase in size
- if the image is scaled down, do not reduce window size. (Or reduce 
to the minimum  size where all menus would fit in the menu bar)

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


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


Re: [Gimp-developer] Enhancement request - Use alpha channel for non-transparent information

2008-07-20 Thread Joao S. O. Bueno
On Sunday 20 July 2008, Raphaël Quinet wrote:
 On Sun, 20 Jul 2008 21:22:11 +1000, Snake Arsenic 
[EMAIL PROTECTED] wrote:
  Okay I made a feature request at
  http://bugzilla.gnome.org/show_bug.cgi?id=543810 but it's missing
  a solution that will not remove any functionality. [...]


Hi!
Going beyond all of Raphael's excelent remarks, I still see some 
issues here :
1) The ability to  ciew teh layer sans transparency and edit the 
alpha channel as if it where any other channel is provided in GIMP - 
you copy the alpha channel to the layer's mask, and edit it (the 
layer's mask). 

2) The request indeed points a thing: GIMP _has_ the ability to set 
each channel visible or not - in the layers channel. If the image 
channel is disabled in the channels dialog, channel cvaleus are 
considere as zero for all display operations.  However, setting  the 
alpha channel to zero in this way - which is what gimp does -is 
useless - you just can't see anything in the image, as it is rendered 
with alpha = 0 for all layers.
I'd suggest that when the alpha channekll si disabled in the channel 
dialog, image is rendered with alpha =1.0  (255)  insetead.  That 
would:
   a) enable the feature thought when the ability to run channel'son 
and off was included;
   b) Make gimp attend the requesterś (Snake) needs.

Maybe the bug request should be chanegd accordingly? 

Moreover -  I really think it is a more usefull (even if seldom used) 
behavior for disabling the alpha. What do you say of doing it?

 I think that it would be a big mistake to use the alpha channel for
 anything else than transparency.  I assume that you are asking for
 this because you have some program (I don't know which one) that is
 incorrectly using the alpha channel to store bump map information
 or something else that is not related to transparency.  It is
 likely that this program doesn't use a file format that supports
 layers or independent channels, so its authors of have decided to
 hijack the alpha channel in some existing file format.

 The correct way to solve this problem is to use layers instead of
 abusing the alpha channel (or maybe additional channels, but I
 think that using layers would be more convenient in this case). 
 With layers, it is very easy to toggle the visibility of the image
 or the bump map layer, specular map layer or whatever else you are
 working on.

 So instead of extending the mistakes done by the authors of some
 other software, it would be much better to know what file format
 has been subverted, and to perform the conversion in the file
 plug-in: * When the plug-in loads a file that uses this strange
 format, it would convert the alpha channel into a layer and mark
 that layer (using a special name like the GIF plug-in does for
 animations, because that can be edited easily by the user if
 necessary).
 * You would then be free to edit the image in GIMP and modify the
 layer containing what should be visible or the layer containing the
 bump map.
 * When saving the file, the plug-in would detect that some layers
 have a special name and would then combine these layers in a way
 that can be read by whatever other program you are using.

 So I suggest that you:
 1) Identify what file formats need some special treatment.
 2) Check if there is a way to detect what files using that format
 are special, so that we do not have to ask the user every time if a
 file using that file format should be read in the intended way
 (alpha channel = transparency) or in the non-standard way (bump
 map). 3) Suggest improvements to the corresponding file plug-ins,
 instead of requesting major changes in the GIMP core.
 -Raphaël
 ___
 Gimp-developer mailing list
 Gimp-developer@lists.XCF.Berkeley.EDU
 https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


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


Re: [Gimp-developer] Enhancement idea: Snapshot tool for quick comparisons

2008-06-27 Thread Joao S. O. Bueno
On Thursday 26 June 2008, Akkana Peck wrote:
 vabijou2 writes:
  Image - Duplicate is an unacceptable alternative.  The idea is
  to create a single window that allows the user to cycle through
  multiple (named) snapshots
  in any order he chooses to see large or small changes more
  readily.  Image -
  Duplicate has so many negatives to this process that I don't know
  where to start.

 How about this?

 The first time, do Copy Visible then Paste as-New Image.
 Call this new image the snapshot image.

 After that, do Copy Visible then go to the snapshot image and Paste
 (then click New Layer).

 Now the snapshot image has all the snapshots as layers. To cycle
 through you need only turn layers on and off.

 Of course, if you did this all the time you could very easily
 automate the process: make a little script-fu that does Copy
 Visible, checks whether the snapshot image exists, then either
 does Paste as New or Paste + New Layer in the snapshot image,
 from a single menu item.


k
Please stop that. :-p
I will finish the more usable layer group plug-in this weekend.  

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


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


Re: [Gimp-developer] Enhancement idea: Snapshot tool for quick comparisons

2008-06-26 Thread Joao S. O. Bueno
On Thursday 26 June 2008, vabijou2 wrote:
 I tried posting this to the list first, but apparently the list was
 down, so I went ahead and submitted a bug (#540091).  The text
 below is from that bug report, and I would love to have this idea
 discussed on the list for possible development.


 When editing photos I find that it is tedious waiting for the
 rendering to be
 completed as I turn layers on and off for comparing the effects of
 the changes
 I'm making.  I would like to see a new tool/UI that would allow a
 snapshot to
 be taken of any currently displayed view and saved for comparison
 with other snapshots later.  It would be good to allow these
 snapshots to be named.  I visualize a list of snapshots, and
 clicking on each one displays it in a snapshot review window.  This
 window would have zooming and panning capabilities.  By eliminating
 the processing that I assume is required each time a layer is
 turned on/off, I would think that the snapshots could be displayed
 very quickly and make subtle differences between snapshots more
 apparent.  Perhaps something like this might be done using the
 Copy Visible
 function and creating a display window with a list of snapshots
 displayed on the side?


Hi there -

I am improving the layer group plug-in that hacks some layer group 
functionality in GIMP. 
You can have a version of it at [1] right now - but I am working on a 
version featuring a dialog where one can trun the groups visible or 
invisible with a single click. That will still work on teh same 
image, but you can do image-duplicate if you need to see diferent 
versions at once.


[1] - 
http://www.gimpstuff.org/content/show.php/Layer+groups?content=83137

js
--


 ---
-


 Comment #1 from Martin Nordholts (GIMP developer, points: 14)
 2008-06-25 04:29 UTC [reply]
 Hi

 Why not just use Image - Duplicate as the snapshot mechanism? If
 that doesn't
 work, please bring this up on the gimp-developer mailing list.
 Before opening
 an enhancement request the feature and solution should have been
 discussed there.

 Thanks

 ---
-


 Comment #2 from vabijou yahoo com (reporter, points: 6)
 2008-06-25 13:12 UTC [reply]

 The gimp-developer mailing list has had no activity since June 16,
 so it does
 not appear to be working.  I've tried posting there, and my e-mails
 have been
 returned.  I've e-mailed the gimp-developer administrator and had
 that e-mail
 returned.  I posted it on nabble on June 20 and there it sits.  I
 think I've done my best to work within the system, and the system
 failed me.  Hence, I'm
 posting it here.

 Image - Duplicate is an unacceptable alternative.  The idea is to
 create a single window that allows the user to cycle through
 multiple (named) snapshots
 in any order he chooses to see large or small changes more readily.
  Image -
 Duplicate has so many negatives to this process that I don't know
 where to start.

 Two major problems with Image - Duplicate immediately come to
 mind:

 1)  It would be a huge waste of memory, since it completely copies
 the image info (except for the History).

 2)  It scatters windows all over the place, making comparisons
 difficult.

 What I'm after is a fast-rendering, easy to use method of flipping
 through snapshots of my workflow.  Shift-clicking on the eye-ball
 by each layer comes
 close, but it is slowed by the processing required during
 rendering.  My proposal is a way to get around that and speed
 things up for the user.


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


Re: [Gimp-developer] GSoC Status Report for pygimp

2008-06-15 Thread Joao S. O. Bueno
On Sunday 15 June 2008, Lars-Peter Clausen wrote:

Thank you  for the e-mail -- there is a lot fo thing going on.
I am not shure if I understood the exact nature of the palletes and 
gradients problems you describe - but you have to take care to let 
they behave like python - even if it is not the most intuitive thing 
when one does not understand what python is doing.

if 

  palette.entries[0] = palette.entries[1]
  palette.entries[0].color = gimp.colors.RGB(0, 0, 0)

  From a python point of view it should change the color of entry 0 
and 1.  This is what should happen in pygimp. We should introduce a 
copy methotd to gimp colors, if they don't have.
So one would do:
  palette.entries[0] = palette.entries[1].copy() 
to duplicate the entry.  (this won't be a problem,  and will be even 
less of an issue if it is properly documented on the palette and 
gradient classes doc strings )

 * I have been looking into wrapping libgimpmath. But I'm not sure
 how to handle it. The matrix and vectors code looks incomplete and
 inconsistent. Some objects are GObjects others are not.
hmmm..Python cando it is own math -- but it may be possible that are 
function calls that use the matrix structs and others as they are 
defined in libgimpmath - maybe you could use ctypes  there? It is 
an easy wrapping around C dynamic libraries taht is made in python 
only at runtime (Ctypes is part of standard python distro as of 
python 2.5 so it won't increase our dependencies).

On the other hand, if the structs desscribed in the libgimpmap/*h 
files are not  usefull for other function calls made from python, 
just docuemtning  what is available and suggesting how to do it in 
NumPy would be enough, IMO.

Thank you for the post. I think it is a nice oportunity for everyone 
to see the money they make google win with their eyeballs is being 
well spent!  :-)


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


Re: [Gimp-developer] Image color representation?

2008-06-15 Thread Joao S. O. Bueno
On Sunday 15 June 2008, TriKri wrote:
 Hi!

 I am wondering which data type GIMP uses to represent the color in
 a pixel of an image? 8 bits/channel? 12 or 16 bits? float?

Hi!

The gimop currently works with 8 bit per channel only.
 According to
 http://pippin.gimp.org/image_processing/chap_dir.html#id2525344,
 there seems to be some different representation types, but glaus is
 somewhat unknown to me, though.

 I’m having a bit of trouble myself deciding which type I should
 have in the program I’m going to make, to use for each channel. If
 I use 8 bits per channel, the different functions will probably run
 a bit faster than if I use floating point values.

In a new program dealin gwith images, you certainly should take  a 
close look in GEGL - the Generic Graphics Library - which has been 
though from the beggining as a library to enable GIMP to work in 
other color dephs in a clean way. Most likely, if your program needs 
to perform operations in an image you will be fine implementing these 
operations in GEGL thenselves, and then havign the remaning of the 
program as a UI around the GEGL calls (or even as a GIMP Plug-in if 
the users of your programs are likely to do other things with the 
images before or after your program do its thing on them)

 If you should, by chance, use floating point representation of the
 colors, is there some function in GIMP to read a jpg image directly
 into an image with floats, instead of using some function already
 existing to read it into an image with 24-bit color and then
 convert it to floating point values?

yes, GEGL can do that for you (but not GIMP). 


 /Kristofer

js
--

(ps. http://www.gegl.org/ )
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Gimp Customizable Toolbar

2008-06-14 Thread Joao S. O. Bueno
On Saturday 14 June 2008, Sven Neumann wrote:
 Hi,

 On Sat, 2008-06-14 at 19:03 +0200, Ingo Ruhnke wrote:
  It currently only supports a single toolbar and isn't
  customizable via the GUI, but only by editing
  menus/image-toolbar.xml.

 In my opinion this is useless as long as it is not configurable by
 the user. And editing XML files doesn't count as being configurable
 by the user.

And in my opinion, this is a 80% done feature that should not be 
simply called useless and disregarded.

I myself had never missed such a toolbar, but as well, I am not a 
tablet user. 

From where it is, it does not seen it will be to hard to implement 
some drag and drop using the actions (configure keyboard shortcuts) 
dialog. 

I would agree that it imight be too late for consideration for 2.6, 
and of course we just can't just go bloating the UI, but I think 
shuch a toolbar would be highly praised and the UI team shoudl take a 
look at it.   Moreover, once configurable, it could keep the most 
used tool icons, making the toolbox really optional, which is one of 
the ains of the whole set of UI large changes for 2.6.


js
--

  One open question: Can menus/image-toolbar.xml currently be
  stored inside ~/.gimp directory, i.e. is there a way to customize
  those .xml files without messing around with the systemwide Gimp
  installation?

 No, there isn't. I dount that this would be implementable at all,
 at least not without changes in GTK+.



 Sven


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


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


Re: [Gimp-developer] Little question about development

2008-05-23 Thread Joao S. O. Bueno
On Friday 23 May 2008, Michael Natterer wrote:
 On Fri, 2008-05-23 at 11:44 +0200, Marco D'Ambros wrote:
  Dear GIMP developers,
 

BTW, Marco - 
GIMP's ChangeLog files are usally accurate to the last white-space.
And the person who overssess that even whitespaces are correct is 
exactly Mitch.

  I am Marco D'Ambros, a PhD student in the university of Lugano
  Switzerland. I am working in analyzing the evolution of software
  system and a couple of years ago I was looking at the development
  of GIMP.
  I saw that a large number of commits in the GIMP cvs repository
  were performed by an account called mitch. I was wondering if
  that account was used by one developer only, who contributed with
  a lot of code, or maybe it was an account used by several
  developers which works as a kind of proxy.

 Heh, nope this is simply me :-)

 ciao,
 --mitch

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


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


Re: [Gimp-developer] LGM 2008 - rooms are booked, all is well

2008-05-01 Thread Joao S. O. Bueno
On Thursday 01 May 2008, Michael Schumacher wrote:
 Hi,

 just wanted to let everyone know that the rooms are booked now (May
 7th to May 13th; Joao: please contact me for 14th and 15th, I have
 asked for a single room as well but haven't booked it yet).


Hi - I am around - I  donṫ know how these apartmnents work - but maybe 
for just one person, booking a hotel would be simpler. If 
arrangements for a single person are on the same price range, then I 
am fine with the room anyway.

Thank you very much  for taking care of this!

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


[Gimp-developer] LGM again

2008-04-26 Thread Joao S. O. Bueno
Hi Folks --

Soory for the long time offline.

Schuman has been taking care of people willing to go to LGM at Wroklaw 
while I e been out. He passed me the names and costs, and there are 
very few people compared to other 2006, 2007.

If anyone else of the GIMP Developers decide to go to LGM, please 
e-mail me ASAP. (If Schumanl have confirmed you, no need to contact 
me - his notes include the carpool leaving Berlin, for example.).

ASAP == tomorrow!  LGM orgs need to close their costs sheet.

regards,

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


Re: [Gimp-developer] Feature idea for GSoC - Separate+ Plugin integration.

2008-03-24 Thread Joao S. O. Bueno
Hi Guillermo,

On Mon 24 Mar 2008 14:01:00 Sven Neumann wrote:
 Hi,

 On Mon, 2008-03-24 at 13:34 -0300, Guillermo Espertino wrote:
  First of all, sorry if this is the wrong place or moment to post this.
  II think that integrating the separate+ plugin to Gimp would be a great
  GSoC project.

 Doesn't sound like it would be worth making this a GSoC project. In
 particular because that would mean that it would definitely not make it
 into GIMP 2.6.

 As far as I can see all that is needed for integration of the seperate+
 plug-in is someone who volunteers to review the code and the user
 interface and to propose it for inclusion on this list. As we wanted to
 have this plug-in in 2.4 already, I wonder why this has still not
 happened yet.


So, adding on to this  - while only reviewing the code and the UI might be 
much less than expected for a whoe GSoC project, I perceive this as a 
valuable idea.

Maybe adding to this review the implementation of some, or even more, 
of the features suggested could do for a Google Summer of Code.

Guillermo, I would encourage you towards formalizing this application -
try to summarize objectively what exists today and what do you plan to 
implement. Also, try some guestimates  on a time frame for completing 
each task. 

The idea, bellow, of integrating it to the GIMP TIFF save plug-in is great and 
would make it really feel like part of GIMP. So, take a look at GIMP's TIff 
plug-in and giver your say on it.

And of course, the separate plug-in should take into account ICC color profile 
magement, as implemented in the GIMP core (I reall don't know if it aready 
does that).

And least - have in mind that the chances of approval depend very much on a 
favorable review of your proposal by the GIMP developers. You got  some 
critics on your first e-mail,  and some ideas as well. So use those in your 
favor and come up with a propose everyone here should like.

regards,
js
--

 Sven

 On Mon, 2008-03-24 at 18:01 +0100, Sven Neumann wrote:
  As far as I can see all that is needed for integration of the seperate+
  plug-in is someone who volunteers to review the code and the user
  interface and to propose it for inclusion on this list.

 An alternative that we should consider would be to integrate the
 functionality into the TIFF save plug-in. But I will leave it up to
 whoever evaluates and proposes the plug-in here to consider this option.


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


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


[Gimp-developer] LGM 2008 - call for atendants

2008-03-19 Thread Joao S. O. Bueno
Hi Gimp folks!

We are getting close to the 3rd edition of the ibre Graphics Meeting, where, 
over the last years, we have been organizing the equivalent of GimpConf as 
well.

It will take place in may, 8th to 11th, in Wrocław, Poland.

So, it is time for us to organize who is attending so that the conference and 
GIMP treasure can hep funding transportation fees.

People interested in attending, please send me name, and a rough estimative of 
the travel costs to getting there (sometime nearby we will need more precise 
values, but I prefer to have a rough estimate as soon as possible)

Note that in other years people where asked to put their names on a wiki 
page - this time, I am asking you to write me directly. We shall setup such a 
wiki page, but I am rather getting e-mails and preparing a list here without 
having to rely on the wiki.

http://www.libregraphicsmeeting.org/2008/index.php?lang=en

http://create.freedesktop.org/wiki/index.php/Conference

Regards,

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


Re: [Gimp-developer] Rotation for brushes

2008-03-18 Thread Joao S. O. Bueno
On Tue 18 Mar 2008 09:38:26 jbaker wrote:
 it would also be nice to tie in scale and rotate (and any other changes)
 with gimp-python...

That part comes last - when it is implemented in the core, calls for this 
should be added to te PDB (there are missing PDB calls for controling brush 
scale, and paint parameters as jitter currently).

Once it is in the PDB, they wod be available from python, but also, I am 
working in implementing gimp brushes as python objects, and it would be 
trivial to add rotation support there once it is in the core.


As for the User Interface for this, I think mapping curves from input 
parameters to brush/tool properties is the way to go. (that is,  I can think 
of a curve mapping painting angle to brush angle  :-)   )

http://wiki.gimp.org/gimp/SummerOfCode2008ideas
http://bugzilla.gnome.org/show_bug.cgi?id=119240

js
--

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


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


[Gimp-developer] Congratulations, your organization has been accepted in to the Google Summer of Code(tm) 2008T

2008-03-17 Thread Joao S. O. Bueno
There it is -  we are in!  :-)

I should post some follow up to mentors later on.  :-)

I see no number of slots at this point!

E-mail has been sent by google by the mentors I had added previously. AFAIK 
there is further room for mentors if anybody else is interested

js
--

-
Congratulations, your organization has been accepted in to the Google Summer 
of Code(tm) 2008
 
 [EMAIL PROTECTED] 
 [EMAIL PROTECTED]Mon, Mar 17, 2008 at 4:47 PM 
   To: [EMAIL PROTECTED] 


   Congratulations!
 Your organization GIMP - GNU Image Manipulation Program has been
 accepted in to the Google Summer of Code(tm) 2008. You have been
 assigned as primary point of contact and as an administrator for your 
organization.
 Please make sure you review the information we have on your
 organization and about you by logging in to the Google Summer of
 Code(tm) 2008 web application at
 http://code.google.com/soc/mentor_step1.html. You can then visit
 http://code.google.com/soc/mentor_home.html to make any updates to your
 organization profile. Make sure you are logged in using your Google
 Account ([EMAIL PROTECTED]).
 Thanks.
  - Your friendly Google Summer of Code administrators
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


[Gimp-developer] GSOC 2008 ideas

2008-03-07 Thread Joao S. O. Bueno
Hi - 

here are the ideas listed again. I had trimmed down the previous list,
as there are things that simply do not sound attractive enough for
anyone to pick.

Ideas for Gimp-python and the UF-Raw plug-in have been added. 
And we are still lacking mentors for pretty much everything else.  :-)  

Also, there is still a little time for adding some more ideas, or try 
to focus some more.

Regards,
js
--

[http://wiki.gimp.org/gimp/SummerOfCode2008ideas]

= GSoC2008 Project Ideas =

''
Please note that, although you are welcome to look at what is here, 
this
is a workspace for mentors to write down and modify their ideas, and
suggestions here should not be taken as necessarily viable projects 
until they have been finalized.  Also, the fact that something appears
here does not necessarily mean that anybody has volunteered to mentor
it.''

Note to people who add stuff here: Please try to add information about 
a proposal's overall  complexity and experience that could be 
helpful. E.G. experience with GTK+, image manipulation algorithms, 
web application development, ...


== Tagging of GIMP resources ==

Currently resources such as brushes, gradients etc are shown to the 
user in an unstructured way, only sorted alphabetically. This greatly 
limits the number of items a user can deal with. 

People love to make collections of things and think of them by names 
for these collections, like sprinf flower brushes or fancy fonts. 
However, one resource can belong to more than one set, and there can 
be sets which are determined by other means than the content, maybe 
even without the user having to do anything manually - 
think Favorites, Most recently used and Most frequently used. 
It has been suggested that this should not be a finite set of 
categories, bug rather done by assigning tags.

The tasks in this project include:

 * adding a way for gimp resources to be tagged
 * decide which types of resources (i.e. which types of gimp objects) 
should be tagged
 * find a nice way for users to manage tags (add them, remove them)
 * present tags in the UI (i.e. how do you show them in the brush 
list, font list, ...?)
 * think about how tags can assigned to resources (or resources to 
tags)


== On-canvas text editing ==

 Right now, the text tool opens a dialog window where the text has to 
be put, thereby creating a new text layer. Nearly every other option 
of the text tool - font, font size, color, line height, ... - is 
available in the text tool options dialog, so it would be nice to get 
rid of this dialog as well. There have been feature requests about 
being able to edit text directly on the image, like for example 
Inkscape does it. 

It may be that getting to the point where editing text on the image 
canvas is possible isn't that much of work, actually. But this is 
where the interesting challenges do begin: eventually, we do also 
want multiple styles in one text layer. This is not so straight 
forward anymore if your enter text in the image. Not present right 
now, so not having it isn't exactly a showstopper, but making it hard 
to ever get there is.

And you will have to consider support for GTK+ input methods. They may 
be used to enter characters from languages (or, more precisely, 
scripts) beyond the simple Western scripts which define how our 
common keyboards are layed out. This is supported right now in any 
GTK+ text entry, not having it for on-canvas editing would be a 
regression.

Tasks for this project include:

 * port the text core to PangoCairo
 * get on-convas text editing implemented
 * figure out if we do still need a text entry dialog (even Inkscape 
still has it in the properties of the text object)
 * make sure that GTK+ input methods work this this new approach
 * think about making it possible or not making it impossible to style 
the text while editing it this way


== GIMP Python ==

mentors: Yosh or João

With version 2.4, python becomes the preferred method
of scripting plug-ins for GIMP. Python is an universal multipurpose 
cross-platform
language, adopted as scripting language by several applicatives, easy 
to understand,
with a feature rich set of standard libraries.

GIMP python scripting is possible since 1999, before version 1.2 and 
it allows
access either to GIMP's procedural database and to internal image 
pixel data, just like
plug-ins written in C.

However there are points that can be greatly improved. Things that can 
be done for a
Google Summer of Code project:

 Properly map Gimp Widgets and objects to Python 

 Wrap all libgimpwidgets to be acessible from python, so python 
plug-ins can have the same presentation as gimp components written in 
C (that is gradient and palette selectors,
scale entries). Additionally map all remaining gimp objects to proper 
python objects,
just as layers and images are already: palettes, gradients, brushes, 
patterns, fonts, 

 Enhance the interface builder, add plug-in previews 

Add 

[Gimp-developer] GSOC 2008 - ideas

2008-03-02 Thread Joao S. O. Bueno
Hi there!

We have some ideas for Google Summer of Code project in the wiki, but 
all of tehna re dangling since last year.

Mos t of tehm look good, but some may have been obsoleted in the 
current devel cycle, or would involve changes in code that is going 
away in the cycle.

I am posting the full set of ideas bellow and asking for commetns on 
ideas, new ideas, and overall, people who would be willing to mentor 
a stundet through some of them.


regards,
js
--

http://wiki.gimp.org/gimp/SummerOfCode2008ideas
-
 
[BOTTOM][TOP]GSoC2008 Project Ideas
 Please note that, although you are welcome to look at what is here, 
this is a workspace for mentors to write down and modify their ideas, 
and suggestions here should not be taken as necessarily viable 
projects until they have been finalized. Also, the fact that 
something appears here does not necessarily mean that anybody has 
volunteered to mentor it. 
Note to people who add stuff here: Please try to add information about 
a prorpsal's overall complexity and experience that could be helpful. 
E.G. experience with GTK+, image manipulation algorithms, web 
application development, ... 
 Filetype registration 
There is currently no way to register a file type to open with GIMP 
from within GIMP itself. On some desktop environments and platforms, 
this makes registering types to open with GIMP awkward. We need a 
configuration GUI within GIMP, which does show the available types 
and/or file extensions, and a means (a backend) to register them 
according to the platform/environment. The latter should probably be 
modular and extensible, because this is different on each of them. 
 Resource management. 
Currently resources such as brushes, gradients etc are shown to the 
user in an unstructured way, only sorted alphabetically. This greatly 
limits the number of items a user can deal with. People love to make 
collections of things, so this would greatly enhance the user 
experience. It has been suggested that this should not be a finite 
set of categories, bug rather tags. 
 Create an SDI manager widget. 
Would allow all of GIMP's windows to be contained in a single parent 
window, as requested hundreds of times by Windows users. (This would 
be optional, not forced on people who don't want it.) 
 Plug-in stability effort 
Tests have shown that it is possible to crash plug-ins when feeding 
them bogus data via the PDB API, for example when calling them from 
scripts (another interesting approach might be to run file loader 
plug-ins with [WWW] zzuf). Needed: a test framework to find the bugs, 
and then time to fix them. 
 Additional file format plug-ins 
There is a number of file formats that GIMP should support, but 
doesn't or at least doesn't support fully, for example MNG. The MNG 
save plug-in needs to be modified to save images in MNG-LC profile. 
Then a loader can be easily written to work similar to the GIF 
loader. It also needs support for JPEG chunks. 
 On-canvas text editing 
Right now, the text tool opens a dialog window where the text has to 
be put. Nearly every other option of the text toold is in its tool 
options dialog, so it would be nice to get rid of this dialog as 
well. 
 Search-based menu browser 
The amount of menu entries in GIMP - either from plug-ins, scripts or 
internal functions - is huge. The name of a particular function might 
be easier to remember than its menu location. Being able to search 
for the function and applying it to the image without having to go 
through the menus can help (similar to Emacs' M-x feature). 
 Unified UI for scripting 
We have three major scripting interfaces, Script-Fu, ?PyGimp and 
Perl-Fu. All of them allow to create an interface for a script 
easily, just by registering a function with their respective 
parameters. However, all widgets look a bit different depending on 
the binding. 
 Redesign and reimplementation of Save and Export in GIMP. 
Change the semantics of Save and Save As so that images are always 
saved in the XCF file format. Only the native GIMP format really 
saves all the image information and allows to lossless continue 
editing later. So only saving as XCF should clear the dirty flag of 
the image. 
Saving to other formats than XCF is done by exporting the image. The 
File menu should have an Export menu item (and perhaps also Export 
As). 
 Unit testing framework 
GIMP currently doesn't have a test framework that API changes or 
internal changes could be tested against. This is crucial to avoid 
regressions, especially with the major rewrite we will seen when GEGL 
is introduced. 
 Work on GEGL 
[WWW] GEGL is a graph based image processing framework. It will be 
introduced into the GIMP trunk after 2.4 has been released. 
Processing is done by the nodes of the graph, which are implemented 
as so-called operations or 'ops'. A good introduction to the current 
state of GEGL is the [WWW] 

Re: [Gimp-developer] script-fu menu

2008-03-02 Thread Joao S. O. Bueno
On Sunday 02 March 2008, Luis A. Florit wrote:
 * El 02/03/08 a las 15:25, Laxminarayan Kamath chamullaba:
  I am not a GIMP developer, though I have been a spectator on this
  list for a while now.
 
  I suggest that you specify exactly what you are trying, and what
  exactly you are looking for.
 
  A detailed work-flow and a UI mock-up image would best describe
  what you want.
 
  Specify the problem.. not the solution.

 Sorry, I thought I was clear enough (did I specify the solution??)
 What I want to do is what is pretty standard in these cases:

 My script-fu has a lot of options, and a check box to use
 default values of these options. I want these options to
 become grayed out when the check box is checked. Just that.

 My other question was if it is possible to add text to a script-fu
 option window that is not related to an option of the script.

 But I do not know if these are possible in script-fu, and I didn't
 find a complete enough reference for script-fu.

 Thanks again,

 L.



Hi there,

At first, I have toḋ say to you it is likely these chanegs are not 
going to be made. 

The auto-interface build up in script-fu, perl-fu and python-fu is a 
convenience, and presented as is. More sofisticated plug-ins should 
use GTK+ to draw their own interfaces . Unfortunatelly this is no 
option when you are using Scheme (script-fu).

If you do your work in python, however, you have, in the opinos of 
many people, and in my strong opinion, an easier to work langauge 
than Scheme, and will gain the flexibility to build your custom 
interface as you please. (And still, won't miss any flexibilit 
otherwise avaliable only to plug-ins written in C).
Ah, there are also Ruby bindings, should you prefer Ruby than Python. 

And finally, so that you don't think you are alone in this desire for 
greater control on the authomatic interfaces, I have thoguth about 
that as well, and it is possible that something more or less like 
what you are asking to be implemented for Python plug-ins.

Regards,

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


Re: [Gimp-developer] Gimp-developer Digest, Vol 66, Issue 3

2008-03-02 Thread Joao S. O. Bueno
On Sunday 02 March 2008, Luis A. Florit wrote:
 Ok, this is what I suspected. Someone here told me some time
 ago to try python-fu, but my script is almost done since long
 time ago, and I am not sure if python-fu would do it.
 Of course C would...

     Thanks Bill!


Python-fu is capable of everything script-fu is, an dmost of what C 
is, as well.

Translating a script-fu to a python-fu is mostly a matter of 
re-arranging (and dropping) parenthesis :-)

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


[Gimp-developer] GSOC 2008

2008-02-29 Thread Joao S. O. Bueno
Hi,

Iṕ've been talking to Schumanl and Prokoudine this afternoon, and they 
agreeded to indicate me to be GIMP's Google Summer of Code Admin 
(mostly: contact person), for 2008 edition.

I am willing to pick the role, but I have to know if everyone agrees, 
or if someone else would like to do it (Iḋ'd still colaborate).

Regardless of that the window for registration starts next Monday and 
it will be somewhat short.  So we have to get things ready at  
http://wiki.gimp.org/gimp/SummerOfCode2008application and even more 
important (as this application is most bureacratic stuff I can fill 
in), we have to arrange the ideas we'd like to see implemented in 
this years' project - here 
http://wiki.gimp.org/gimp/SummerOfCode2008ideas

We have up to  March, the 12th to have this in order. If I am in 
charge I'd prefer doing it even earlier. This is not unmutable 
though, and even applying students can suggest their own ideas.

And more important than filling the application, and having the ideas, 
are _mentors_ ! So people willing to mentor students, please do so at 
the application wiki page, and possibly indicate which ideas you 
would like to mentor. 

Regards,

js
--


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


Re: [Gimp-developer] Libre Graphics Meeting 2008 - call for presentations

2008-02-28 Thread Joao S. O. Bueno
On Monday 25 February 2008, kamila giedrojc wrote:
 Dear GIMP team,


Hi,

I've added a talk I'd like to give there: 
http://create.freedesktop.org/wiki/index.php/PythonTalkLgm3

It goes well beyond GIMP, but I hope it is ok for everybody. 

js
--

 Libre Graphics Meeting 2008 is few steps from here. We are
 currently working on the program. I'm sure I can count on you. This
 week we are waiting for the emails from everyone who did not yet
 contact us, and would be interested in giving a talk, or conducting
 a workshop. I'd be grateful to get your responses up to March 2nd.

 You can also subscribe as a presenter in conference wiki
 http://create.freedesktop.org/wiki/index.php/Conference

 Don't hesitate to contact me if you have any questions.
 Cheers!
 Kamila

 ---
 Kamila Giedrojc
 Official Organiser
 Libre Graphics Meeting 2008 - Wroclaw
 kamila.giedrojc [at] gmail [dot] com
 www.libregraphicsmeeting.org

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


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


Re: [Gimp-developer] tagged resources such as brushes, gradients, etc

2008-01-18 Thread Joao S. O. Bueno
On Friday 18 January 2008 15:08, William Skaggs wrote:
 In any case, let me ask a basic sort of question about user
 interaction.  Suppose I'm a user, painting with a set of brushes.
 I decide that I want to use a certain grunge brush.  (Let's
 say I have a specific brush in mind, but all I remember about
 its tags is that it is  a grunge brush from a set I imported last
 week.)  What are the steps I have to take, as a user, in order
 to find the new brush and start using it, without losing access
 to the other brushes I am currently using?  (I'm willing to assume
 that if I load everything with the grunge tag, I will be able
 to find the brush I want in there.)


Of couse, this will have to be refined by the UI team.
But I have two ideas for it: one would be abel to type in tags into a 
dialgo shwing brushes without lossing the ones already selected. 
Like, just typing more tags on the tag text entry widget, and having 
tehn combiend as or. The other one, is to allow the user to pop up 
another brushes dialog, in which he perfomes hs searches, He then can 
either select brushes from this ne dialog, or drag brushes from there 
to the first one, where they are transparently added to the group tag 
in use on the first window.

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


Re: [Gimp-developer] proposal for managing resources s uch as brushes , gradients, etc

2008-01-17 Thread Joao S. O. Bueno
On Thursday 17 January 2008 14:45, William Skaggs wrote:
 From: peter sikking [EMAIL PROTECTED]

  chiming in here (getting back to speed). [...]

 Peter!  Great to hear from you again!

 I absolutely agree about the virtues of a tagging system, but
 I fear that the difficulties are not being appreciated well enough.
 Here, for example, is just one of the problems:

 Problem: should tags be stored as part of a data file, or in a
 separate tags-database?

separate tags database - which might be a xml file, I think.

 1) If they are stored as part of the data file, then this calls for
 a new file format for every sort of gimp resource object, and
 changing tags calls for file system operations.
ok - this won't happen.


 2) If they are stored in a separate database, keyed by file
 names, then there is a great danger of losing the linkage
 between tags and object.  If, for example, the user renames
 the directory holding some brushes, all of the tags for those
 brushes will be lost.  The only way to prevent this sort of
 thing from happening is to make sure that all operations
 on resource files are mediated by Gimp (or some new
 utility program) that will make sure to keep the tags in
 sync with the data files.  If for some reason a user's tags
 database gets corrupted, it will be a major disaster.

I think we just need to worry about it being a minor disaster. I can 
think of recover scripts that could be written  to restore some 
tags, in case of directory renaming, for example.

 There are many other issues of the same sort, which I don't
 believe have been thought through.
I don´ t think so. It looks plain straightforward for me.
I have worked with many web systems that reference filesystem paths 
for images, for example, and never had a maintanance  problem due to 
that. 

Besides, yes, gimp would need some kind of scanning through resource 
folders, and possibly group all resopurces tehre under an all flag. 
That is needed so that one can download resources and add then to 
GIMP through the filesystem.


 The bottom line is that introducing tag-based resource
 organization is like setting up a virtual, non-hierarchical
 file system.  The ordinary file system may be weak in
 comparison, but it is extremely robust, and users know
 how to manipulate it.  A new tag-based file system can't
 possibly be robust until it has had an extensive testing
 period, and therefore exposes a user to the worst of all
 disasters:  a corrupted file system.

 The solution I favor is to build a tag-based system *on
 top of* a filesystem-based system.  That way:

 1) The tag-based system can be built gradually, instead
 of being imposed all at once on a flat set of files.
A flat set of files become a flat set under one tag in teh worst 
case scenario. 

 2) The user can manipulate files using ordinary filesystem
 operations without fear of wrecking gimp.
Yes, that need to happen therefore the folders where resources are 
expected to be, as they are today should remain, IMHO.


 3)  A naive user who doesn't understand tags will still be
 able to use Gimp without having to learn about tags at
 the very beginning.
This one is for Peter. In short: yes, there should be resources 
visible in a default GIMP install, first use. Maybe we could name 
a Basic tag for these start-up resources.  A drop down for the most 
used tags could be fine as well.


 4) A corrupted tags database will still be very bad, but won't
 make Gimp completely unusable.
Indeed. As I said, the scanning should be made at gimp-load, and any 
resources found should be mapped to a default tag. Using something 
as simple as a hash of the entire file data could preserve all tags 
even when resources where moved across directories (rescanning 
hashest might need an explicit action)

regards,
js
--


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


Re: [Gimp-developer] proposal for managing resources s uch as brushes , gradients, etc

2008-01-16 Thread Joao S. O. Bueno
On Wednesday 16 January 2008 17:42, William Skaggs wrote:
 This mixes together two separate issues.  Tags are, as I have
 already agreed, an excellent way of doing a search mechanism.  They
 don't get rid of the need to have a workspace, though.  Suppose I
 want to switch back and forth between five very different brushes.
  Must I remember and select a set of tags each time I switch?  That
 would be very unpleasant.  No, whether or not there is a tag-based
 search system, there still needs to be a way for the user to
 maintain a workspace holding a limited set of arbitrarily chosen
 brushes.


What about using...tags... for that?

The idea of such a workspace would be that it would display brushes 
containing a certain tag. In teh above use case, I'd just apply 
a one-of-five-very-different-brushes  tag to all the brushes.  For 
this to make sense  it _must_ be very easy and fast to edit a 
resource's tags. But that could be refined later on the development.

Actually, maybe it would make sense containers that could show several 
types of gimp data in a single dialog. So, if I am working 
with trees, I'd have palettes, gradients, and brushes which show up 
in a single window. More than one such dialog should be allowed to be 
open at once, so that a user could simply drag and drop things around 
(and internally, tags are added/removed transparently). 

So ... the workflow for the case of use above would be something like:
create an empty multicontainer, go to another multicontainer 
displaying only brushes (the equivalent of today's brushes dialog), 
type in a tag to the first brush, drag it into the empty new 
container - repeat for brushes 2-5. Start painting. When it is over, 
destroy the current container, or just save it under an arbitray tag 
name for later re-use. 

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


Re: [Gimp-developer] GIMP at the 24C3

2007-12-16 Thread Joao S. O. Bueno
On Sunday 16 December 2007 09:48, Sven Neumann wrote:
 Hi,

 as announced earlier, some GIMP developers are going to meet at the
 24th Chaos Communication Congress (24C3)
 http://events.ccc.de/congress/2007/

 We already discussed that travel costs for such events should be
 reimbursed from GIMP donation money. For this event, I would like
 to transfer EUR 1000 from the GIMP account. We would use that money
 mainly for travel costs. Should something be left, we will spend it
 on pizza. Does anyone see a problem with that? Please object now or
 never...


never. :-)
Enjoy it!

js
--

 Sven


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


Re: [Gimp-developer] dir(gimpfu.pdb) crashes

2007-12-03 Thread Joao S. O. Bueno
On Monday 03 December 2007 06:19:21 am Jayesh Salvi wrote:
 Hi,

 I am trying to see what all methods gimpfu.pdb offers, by running dir()
 operation on it. But it crashes as follows:

 [EMAIL PROTECTED] plug-ins]$
 PYTHONPATH=$PYTHONPATH:/usr/lib64/gimp/2.0/python python
 Python 2.5 (r25:51908, Apr 10 2007, 10:27:40)
 [GCC 4.1.2 20070403 (Red Hat 4.1.2-8)] on linux2
 Type help, copyright, credits or license for more information.

  import gimpfu
  dir(gimpfu.pdb)

 LibGimpBase-ERROR **: gimp_wire_write_msg: the wire protocol has not been
 initialized
 aborting...
 Aborted

 [EMAIL PROTECTED] plug-ins]$ rpm -qf /usr/lib64/gimp/2.0/python
 gimp-2.4.2-1.fc7


 Does anyone know if this is known error? Is someone fixing it? I won't be
 using dir() operation in final code, but can this abort happen in other
 situations as well?

Gimpfu module can only be imported from a python console which is run under 
GIMP itself. Try that from the python console within GIMP.

js
--

 Thanks,
 Jayesh


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


Re: [Gimp-developer] changing the shape of a text layer

2007-12-02 Thread Joao S. O. Bueno
On Sunday 02 December 2007 01:29:39 am William Skaggs wrote:
 From: [EMAIL PROTECTED]

  I like the idea of having this functionality available. I have tried the
  patch and it seems very capable. There appears to be bug which presented
  itself when I did the following: ...

 Thanks for the bug report.  I'll take a look at it. As a general
 comment, I would point out that this interface might present

  a problem in the future when in-place text editing is implemented.
  Since the primary function of the tool is text input, perhaps it would be
  better to require a modal key (ALT?) when adjusting the frame so that, in
  the future, unmodified mouse clicks could be used to specify cursor
  location and text selections.

 I hadn't thought about this, but it seems to me that it would
 be simpler to distinguish between clicking (used in in-place
 editing) and click-and-drag (used for modifying shape).

I actually dislike the idea of having clicking modes - We might 
have clicking locations - ike, clicking in the handlers always do resize, 
and just draw the handlers so that no text falls inside them.

Certain programs that do use the two modes  for editing and dragging the 
text container are an absolute PITA to use exactly  due to this. (OOo 
anyone?)

js
--

 But 
 in general I am absolutely delighted to leave that sort of question
 to the wisdom of Peter and his cohorts.
 -- Bill
  


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


Re: [Gimp-developer] New option for the fill tool (feature suggestion/request)

2007-11-22 Thread Joao S. O. Bueno
Hi Shin,
  

I'd hardly find this useful but for some very specific patterns.

Instead, I'd suggest you tried using layers and layer masks in your workflow, 
more or less like this: once you select the area to be filled, create an 
empty layer, create a layer mask on it, choose from selection (and empty 
your selection afterwards)
There you are - you now fill the whole layer with your pattern and transform 
it however you like, with translation (not move tool), scaling, rotation, 
etc... 

js
--


On Thursday 22 November 2007 02:14:56 pm Shin Diggar wrote:
 Sorry, I'm not a programmer so I wouldn't know how to do this myself but
 I'd like to suggest a new feature for the fill tool.

 How about an option to use the cursor position as a start point for tiling
 fill-patterns rather than the top left corner of the layer? Perhaps this
 could be greyed-out when fill mode is set to colours rather than patterns.

 I still want the whole layer/selection filled, but wherever the cursor is
 when I click it is where the top-left pixel of the filling pattern should
 be aligned to.

 I'd find this useful sometimes, would anyone else?
 _
 Share life as it happens with the new Windows Live.Download today it's
 FREE!
 http://www.windowslive.com/share.html?ocid=TXT_TAGLM_Wave2_sharelife_112007
 ___
 Gimp-developer mailing list
 Gimp-developer@lists.XCF.Berkeley.EDU
 https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


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


Re: [Gimp-developer] Exporting Vectors to a SVG file

2007-11-16 Thread Joao S. O. Bueno
A Thursday 15 November 2007 14:27:30, Lionel Tarazon Alcocer escreveu:
 I am developing a plug-in which makes use of SVG files to store Gimp
 Vectors. The Import functionality is quite straight-on due to the
 gimp_vectors_import_from_file(), but I haven't found a function which works
 the other way around.

 Is there a function which exports paths/vectors to a SVG file or string?

 Given that this is quite straight-on at the GIMP GUI (right-button over a
 path, Export Path), I was wondering if I had missed it at the API.

 thanks

Hi,

I have a python script that does this.
It has not been updated for the new vectors API in gimp 2.4 however.

Anyway you can take a look at a simple translation of gimp bezier curves to 
svg equivalents, without using gimp internals:

http://www.pion.com.br/~gwidion/paths.tar.gz

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


Re: [Gimp-developer] 2.4 and how to continue from here

2007-11-11 Thread Joao S. O. Bueno
A Sunday 11 November 2007 20:48:27, peter sikking escreveu:
 but the real question is the priority of this yet-another-feature.
 something like geometry tools integration has a much higher priority
 than this.


There eason I proposed this at this stage is that I have this feature  
complete minus UI and XCF saving in my GIMP tree. It has been like that for 
over an year when I was told it was too late to make it into gimp 2.4.

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


Re: [Gimp-developer] 2.4 and how to continue from here

2007-11-09 Thread Joao S. O. Bueno
A Monday 29 October 2007 16:24:11, Sven Neumann escreveu:
 I suggest that we keep brainstorming for the 2.6 roadmap for another
 week and then collect the ideas. It would be nice if we could end with a
 list of well-defined tasks. When that list is collected, I would like to
 discuss which of these tasks should be put on the roadmap for 2.6.


Hi Sevn and others,

I have been obn the process of moving myself to another city over the last few 
weeks (almost complet now, just waiting for my mobile nad main machinne to 
get here).
]
As soons as that happens I should consolidate my work hours and spare a few of 
then for GIMP.

The feature I'd like to work on is a brush stroke pannel to be able to set up 
stroking with curves for relating pressure, speed, angle,  etc with opacity, 
size, jitter, color, etc... 

One other smallf eature I will want to add is the ability to add free- angled 
guides. I have this almost complete on my codebase, just .XCF saving for it 
is missing. I should commit that early on 2.6 cycle.


Regards,

   js
  --

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


[Gimp-developer] Angled guides - was Re: 2.4 and how to continue from here

2007-11-09 Thread Joao S. O. Bueno
A Friday 09 November 2007 13:01:06, você escreveu:
 Hi,

 On Fri, 2007-11-09 at 12:36 -0300, Joao S. O. Bueno wrote:
  One other smallf eature I will want to add is the ability to add free-
  angled guides. I have this almost complete on my codebase, just .XCF
  saving for it is missing. I should commit that early on 2.6 cycle.

 I would like to get some feedback from the UI team and from some artists
 on this. And of course the patch would have to be reviewed before it is
 committed. I am not yet convinced that this is an important feature and
 I also have the impression that it's just added ad-hoc without seeing
 the big picture. It certainly has the potential to cause a lot of
 problems.



I had never added a UI for it - I add then through scripts. 
And except for bugs with the guides thenselves (which i ironed out as I 
developed then), I never had any side effect from using them. Snapping to 
these guides or intesections of these guides and others works fine. If tehre 
are potential greater problems, just a larger userbase  would be able to 
detect it, and then we just fix it, or remove the feature if it needs very 
large changes to other program areas to work properly. 

And rest assured I would not commit it without having an ok from you first.

Of course I'd like more feedback from users and the UI team, but nearly 
everyone I had mentioned this had liked the idea. It is of little use in a 
program like GIMP where free handed drawing is not emphasized, but sometimes 
it is just nice it is there. (like for stamping a brush repeating it at a 
gven angle).

My idea for UI is just writing some code for the rotate tool to be able to 
rotate guides, just as the move tool can move guides. i think that once 
tested this won't get in anyone's path and will be a little nice feature for 
GIMP. 

regards,

js
--

 Sven


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


Re: [Gimp-developer] GAP

2007-08-05 Thread Joao S. O. Bueno Calligaris
On Sunday 05 August 2007 06:45, 
[EMAIL PROTECTED] wrote:
  Hi,
 
  On Sat, 2007-08-04 at 01:58 -0300, Joao S. O. Bueno Calligaris 
wrote:
  I am getting an error linking gimp-gap svn in a 64bit
  enviromment, in both trunk and gap-2-2 branch:
 
  That's a problem with the copy of libavcodec that is included
  with GAP. You better disable support for libavcodec when
  configuring gap. For GAP 2.4 we should include a recent version
  of libavcodec.
 
  Sven

 To expand on Sven's answer a little, the FFMPEG project does not
 provide a stable API; therefore the GAP includes the source for a
 specific snapshot of the code and staticly links to it. The
 snapshot in the GAP's tree is from 2005 ; it needs to be updated
 and the GAP code modified to employ the new FFMPEG API (also for
 64-bit support and GCC4 compatibility as well).

 Wolgang Hofer, the main developer of the GAP, is working on that
 update but he does not have direct access to the Internet right
 now. It may be a few months before updated FFMPEG support is
 available but it is being worked on. In the interim, I would
 suggest disabling libavcodec support and using an external utility
 to convert your frames to video.



Hehh..that is a bit too much, ain't it?
It actually _did_ build when  I tweaked the Makefiles in the library 
dirs (and only there) to include the  -fPIC GCC directive.
64 bit, GCC 4.1.1

It is not like this will only work in 2010 or 2012.

js
--



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


Re: [Gimp-developer] GAP

2007-08-04 Thread Joao S. O. Bueno Calligaris
On Friday 03 August 2007 17:18, Sven Neumann wrote:
 Hi,

 On Fri, 2007-08-03 at 23:54 +0400, Alexandre Prokoudine wrote:
   Are you absolutely sure that you removed the fuzzy marker
   after updating the translation?
 
  Yes, I am.

 OK, please try again after updating from SVN. I added some missing
 calls to gimp_plugin_domain_register(). That should fix it, but
 there might be more places affected that need a similar fix.


 Sven


I am getting an error linking gimp-gap svn in a 64bit enviromment, in 
both trunk and gap-2-2 branch:

/usr/bin/ld: bitstream.o: relocation R_X86_64_32 against `a local 
symbol' can not be used when making a shared object; recompile 
with -fPIC
bitstream.o: could not read symbols: Bad value
collect2: ld returned 1 exit status
make[4]: *** [libavcodec.so] Error 1


when doing:
gcc -shared -o libavcodec.so bitstream.o utils.o mem.o allcodecs.o 
mpegvideo.o jrevdct.o jfdctfst.o jfdctint.o mpegaudio.o ac3enc.o 
mjpeg.o resample.o resample2.o dsputil.o motion_est.o imgconvert.o 
imgresample.o mpeg12.o mpegaudiodec.o pcm.o simple_idct.o 
ratecontrol.o adpcm.o eval.o dv.o error_resilience.o fft.o mdct.o 
mace.o huffyuv.o cyuv.o raw.o h264.o golomb.o vp3.o asv1.o 4xm.o 
cabac.o ffv1.o ra144.o ra288.o vcr1.o cljr.o roqvideo.o dpcm.o 
interplayvideo.o xan.o rpza.o cinepak.o msrle.o msvideo1.o vqavideo.o 
idcinvideo.o adx.o rational.o faandct.o 8bps.o smc.o parser.o 
flicvideo.o truemotion1.o vmdav.o lcl.o qtrle.o g726.o flac.o 
vp3dsp.o integer.o snow.o tscc.o sonic.o ulti.o h264idct.o qdrw.o 
xl.o rangecoder.o png.o pnm.o qpeg.o vc9.o h263.o h261.o msmpeg4.o 
h263dec.o svq1.o rv10.o wmadec.o indeo3.o shorten.o loco.o alac.o 
wnv1.o ws-snd1.o aasc.o  a52dec.o liba52/bit_allocate.o 
liba52/bitstream.o liba52/downmix.o liba52/imdct.o  liba52/parse.o 
liba52/crc.o 
liba52/resample.o  -lm -lz -ldl  -Wl,--warn-common -rdynamic

(trying the suggested fPIC makes build halt early on.)



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


Re: [Gimp-developer] [Gegl-developer] PyGEGL instant crash

2007-07-19 Thread Joao S. O. Bueno Calligaris
On Thursday 19 July 2007 19:28, Kevin Cozens wrote:
 David Gowers wrote:
  Using Python 2.6, typing 'import gegl' at the interpreter prompt
  causes the following crash to immediately happen:

 [snip]

  I'm also pretty sure that the bug lies in the pygegl module, as
  I've compiled and used many other modules for Python 2.6, with no
  problems, and I ran the babl and gegl tests successfully (and the
  gegl editor works okay too)

 I have only tested pyGEGL with the 2.4 version of Python. It
 possible (or very likely?) that something has changed in the 2.6
 version of Python. I don't have the 2.6 version installed at the
 moment so I can't investigate this further.


Python 2.6???


The stable python is 2.5.1  - there is not even mention of a 2.6 
release on teh python.org pages.

David: do  you mean python 2.5 instead? 


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


[Gimp-developer] Fwd: LGM 2007 Final Report - Help needed

2007-05-10 Thread Joao S. O. Bueno Calligaris


--  Forwarded Message  --

Subject: LGM 2007 Final Report - Help needed
Date: Thursday 10 May 2007 12:10
From: Louis Desjardins [EMAIL PROTECTED]
To: Sven Neumann [EMAIL PROTECTED], Joao S. O. Bueno Calligaris 
[EMAIL PROTECTED], Plinnell [EMAIL PROTECTED], Cyrille 
Berger [EMAIL PROTECTED], Boudewijn Rempt 
[EMAIL PROTECTED], Igor Novikov 
[EMAIL PROTECTED], Alexandre Prokoudine 
[EMAIL PROTECTED], Jon Phillips 
[EMAIL PROTECTED], Andy Fitzsimon 
[EMAIL PROTECTED], Martin Poirier [EMAIL PROTECTED]

Hi guys,

(I am writing to a few of the team leaders and please feel free to
 relay this request to the person in your team you feel would do the
 best job to gather the resquested information. Also, if you think I
 have forgotten somebody or a project, please let me know. — Thanks!)

LGM 2007 has been a tremendous experience! I hope all travellers had
 a good trip back home! Thank you so much for being in Montréal with
 us! Thank you so much for all your encouragements and enthusiasm!

We now must think about the final report of this year's LGM. This is
important to keep track of what was accomplished and to prepare next
 year's edition. It is of upmost importance for our sponsors, to
 secure next year sponsorship, to let them know how and why LGM is
 important for the participating projects.

From each team I would ask a short but enough detailed summary of
 what was accomplished since last year. It can be both quantitative
 and qualitative. I doesn't need to be a long text. Since it is the
 first time we do that (I think) I leave it up to you. We will make
 it a nice layout and will include some nice pics as well. The report
 will help us draw attention on LGM and will also serve as a
 reference point for the teams.

Thank you for responding quickly. We'd like to have the report done
 within a few weeks from now.

Cheers!

Louis



--
Louis Desjardins
Organisateur / Organiser
Libre Graphics Meeting 2007 - Montréal
www.libregraphicsmeeting.org/fr
www.libregraphicsmeeting.org
+1 514 934 1353 HAE / EDT GMT -4

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


Re: [Gimp-developer] Pixel coordinates input type for script-fu?

2007-05-01 Thread Joao S. O. Bueno Calligaris
On Tuesday 01 May 2007 00:15, Mark Lowry wrote:
 I'm working on a script in which it would be
 advantageous to use the mouse to click on an image and
 have the pixel coordinates captured as an input.
 Right now I have to manually enter the coordinates for
 four points, which is a tedious process.

 Is there a way to capture these coordinates as inputs
 to a script?  If not, where is the appropriate place
 to suggest a feature request for this?


Hi - no, there is no official way to do that.

What I do in my scripts is require the user to start a Path with the 
bezier tool before calling the script - The script then use the 
coordiantes of the first (or how many I want) points of this path as 
input coordinates. These can e read through the PDB.

js
--
 Thanks . Mark

 __
 Do You Yahoo!?
 Tired of spam?  Yahoo! Mail has the best spam protection around
 http://mail.yahoo.com
 ___
 Gimp-developer mailing list
 Gimp-developer@lists.XCF.Berkeley.EDU
 https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Pixel coordinates input type for script-fu?

2007-05-01 Thread Joao S. O. Bueno Calligaris
On Tuesday 01 May 2007 17:05, Mark Lowry wrote:
 --- Joao S. O. Bueno Calligaris [EMAIL PROTECTED]

 wrote:
  Hi - no, there is no official way to do that.
 
  What I do in my scripts is require the user to start
  a Path with the
  bezier tool before calling the script - The script
  then use the
  coordiantes of the first (or how many I want) points
  of this path as
  input coordinates. These can e read through the PDB.
 
  js
  --

 I have thought about doing that and I think that is
 the way I will have to go.  I'm confused with how to
 extract elements from the vector returned by
 gimp-path-get-points.  I thought I understood that
 (vector-ref vector k) was the way to pull the k-1
 element from the vector, but when I input (vector-ref
 '#(1 1 2 3 5 8 13 21) 5) I just get an errobj on
 vector-ref.  What do I need to do to be able to
 extract a value from the result of
 (gimp-path-get-points image path)?

oh man.,..
2 things:
1) I do python-fu, not Scheme (script-fu) - so I have erased from my 
mind the esoteric ways of getting elements out of a vector or array 
in Scheme. btw, if your plug-in is of any complexity, unless you 
think your time is being well spent as you exercise your mind around 
how to get and use data with scheme expressions as an extra exercise, 
I'd  suggest writting it in python. If you are on windows, that will 
only work witht he developemtn version of GIJMP, though. But it has 
the advantadge of letting you worry with your problem instead of the 
language _and_ your problem.


2) this very API is being obsoleted in GIMP 2.3.x - there are all new 
vector manipulation calls in place, that can finally deal correctly 
with multiple stroke vectors (not needed to fecth just one or two 
coordinates anyway)

In python, an interactiuve session exploring the return values might 
just display:
 img = gimp.image_list()[0]
 pdb.gimp_path_get_points (img, a)
(1, 0, 15, (103.03428571428572, 101.01142857142861, 1.0, 
104.74857142857149, 98.902857142857101, 2.0, 529.68571428571431, 
102.38, 2.0, 529.480002, 102.039996, 1.0, 
529.27428571428572, 101.679995, 2.0))
 v = pdb.gimp_path_get_points (img, a)
 points  = v[3]
 points
(103.03428571428572, 101.01142857142861, 1.0, 104.74857142857149, 
98.902857142857101, 2.0, 529.68571428571431, 102.38, 2.0, 
529.480002, 102.039996, 1.0, 529.27428571428572, 
101.679995, 2.0)
 points[0], points[1]
(103.03428571428572, 101.01142857142861)

(the   are the prompt, not part of the language)


--
Bill...could you see if it iyou can add a simple api for retrieving 
the sample points? I think this will bother no one at this point, it 
is starightforward as you said, and...we want to get 2.4 out, so it 
has to be done real soon.

js
--


 __
 Do You Yahoo!?
 Tired of spam?  Yahoo! Mail has the best spam protection around
 http://mail.yahoo.com
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] How to change the active current tool from a plugin?

2007-04-25 Thread Joao S. O. Bueno Calligaris
On Wednesday 25 April 2007 17:27, Laurent gauvrit wrote:
 hello everybody,

 I work on a hopefull edge detection plugin for gimp and i need to
 change the active current tool by a button in my plugin.

 Anyone know the answer???

Yes.

The answer is: it is not possible at the moment.
Sorry for that.

A plug-in can itself use the tools, , but it can't change most things 
in the UI context.

js
--



 thanks


 lolo

 _
 Windows Live Spaces : créez votre blog à votre image !
 http://www.windowslive.fr/spaces

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


Re: [Gimp-developer] how to call gimp procedure from text terminal ?

2007-04-23 Thread Joao S. O. Bueno Calligaris
On Monday 23 April 2007 21:02, stu seven wrote:
 +I asked this on the google group, but with no answer yet...

  How can a menu item or gimp procedure be called from a
 text terminal, with a graphical gimp session already running ?

  I know that, using a function name, and parameters, this can
 be done in batch mode, for instance... however, all Im looking for
 is to remotely open the function dialog, via the text terminal.

  Is this possible... or... some other way of opening the menu
 item dialog besides clicking on it ?


Such a terminal would have to be done from within GIMP.

The easiest way I can think of doingthis is writing a python plug-in 
that will listen to a socket and execute what you type in there once 
you connect to that socket.


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


[Gimp-developer] Fwd: [CREATE] Standard RAW File Format (fwd)

2007-04-18 Thread Joao S. O. Bueno Calligaris


--  Forwarded Message  --

Subject: [CREATE] Standard RAW File Format (fwd)
Date: Tuesday 17 April 2007 05:36
From: Kai-Uwe Behrmann [EMAIL PROTECTED]
To: libtiff - Liste [EMAIL PROTECTED], Kunst Tuepfel 
[EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]

Hello, just to inform all the digital camera RAW developers out here.
Sorry for any duplication.

-- Forwarded message --
Date: Fri, 16 Mar 2007 18:18:33 +0100
From: Dietmar Wueller [EMAIL PROTECTED]
To: Dietmar Wueller [EMAIL PROTECTED]
Subject: Standard RAW File Format

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello,

as a member of the ISO TC42 (technical committee for photography)
working group 18 (electronic imaging) standards group I would like to
inform you that the existing Tiff/EP (ISO 12234) standard for images
captured by digital cameras is currently under revision.

The Adobe DNG format was derived from this standard and the group has
Adobe's permission to incorporate modifications and developments made
for DNG in the new standard.

In addition the standards group is asking all interested people for
comments and requirements - which are not part of the current DNG or
Tiff/EP standard - to be incorporated in the new standard.
If you have such please forward them to me by the end of April.

Hopefully we will soon be able to provide a standardized file format
which meets everybody's expectations and gets a wide support by
 camera manufacturers, software vendors, and photographers.

Please forward this message to everybody who may have contributions
 to the revision.


Best regards
Dietmar Wueller

Image Engineering
Dietmar Wueller
Augustinusstr. 9d
50226 Frechen
Germany

phone +49 2234 912141
fax +49 2234 912142
[EMAIL PROTECTED]
www.image-engineering.de


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFF+tFp7Olj94xfLY4RArPaAKCtTyhP4rWNjRwfNmb5WW7B9TrtngCfYKMm
qSARyPFRA4/lBFuQE54LTm0=
=1Yi9
-END PGP SIGNATURE-
___
CREATE mailing list
[EMAIL PROTECTED]
http://lists.freedesktop.org/mailman/listinfo/create

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


Re: [Gimp-developer] internal representation of a selection

2007-03-30 Thread Joao S. O. Bueno Calligaris
On Friday 30 March 2007 13:10, Helmut Jarausch wrote:
 Hi,

 can somebody, please, point me to some information on how a
 selection is represented (internally) within Gimp and how one can
 access this. Is it represented by a matrix of bits?
 If the selection has many holes it's not sufficient to have a lower
 and upper bound for each pixel row. I need the selection exactly
 for my attempt at a new healing tool.

 Many thanks for a pointer,

Hi Helmut - 
the selection is a matrix of bits, yes - a drawable object, with one 
byte per pixel, meaning the strenght  of the selection at that 
point.

the call gimp_image_get_selectin available for plug-ins can return you 
the selection as a drawable object.
Through the UI you can simply enable the quickmask (click on the 
little square to the left of the hor. scroll bar on an image window), 
to transfer the selection to an editable image channel.

js
--


 Helmut Jarausch.

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


  1   2   3   >