Re: [Gimp-developer] Camp Ticket Presale Closing

2011-07-19 Thread Simon Budig
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.

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


Re: [Gimp-developer] Example: Vala as code generator

2011-05-02 Thread Simon Budig
Martin Nordholts (ense...@gmail.com) wrote:
 I'm trying hard to find time hacking on GIMP, and not having to waste
 time on GObject C boiler plate means a lot to me. At first I was
 thinking what the hell, I'll just come up with the the damn
 boilerplate code manually then. But right after I began doing that I
 started to feel like I was wasting my time, and I can't stand that
 feeling.

Hm. This paragraphs leaves me a bit perplexed, because it gives the
impression that the most important thing about including vala is to make
you more comfortable with our codebase. You blame mitch for a blunt
dismissal, but this reads a lot like bluntly forcing down something
through mitchs throat. Not sure if that is any better.

I must say that - while I have my share of frustrations with the gobject
boilerplate code - I don't think that adding vala helps the quality of
the Gimp codebase. And this is IMHO what should be in our focus.

From reading a lot of code in a lot of different free software projects
I have to say, that Gimp still is one of the shining examples regarding
consistency and quality of the source code. This has a lot to do with
mainly Sven and Mitch investing countless hours into refactoring and
restructuring the code, enforcing a common code structure and generally
fighting against sloppiness.

I don't see how mixing this code with code written in a new language
will help the quality of the source. Vala code will inherently develop a
set of patterns that differs from the C code (and don't underestimate
the value of grepping through the code base). Also new contributors will
not only have to learn about GObject and GTK+, they have to learn vala
as well. And adding vala *is* adding a new entry barrier, vala is by no
means a lingua franca.

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


Re: [Gimp-developer] GIMP Developer Meeting #3 - March 28, 2011

2011-03-28 Thread Simon Budig
Martin Nordholts (ense...@gmail.com) wrote:
 2011/3/27 Michael Natterer mi...@gimp.org:
  And this is *exactly* the problem. We would end up with programmers
  that quickly learnt vala, having no clue about GObject. That's
  absolutely horrible.
 
 How is it a problem that our code becomes so easy that even dumb
 programmers can understand and improve it when we are not forced to
 include patches from such dumb programmers?

They're bound to hit problems that out of their scope, leaving them
perplexed.

My experience with vala is deeply tainted by the (now resolved) bug
https://bugzilla.gnome.org/show_bug.cgi?id=587683

Bye,
Simon

PS: I don't like how you rephrase mitch's argument with offending words.

-- 
  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


Re: [Gimp-developer] gimp_vectors_bezier_stroke_lineto() working backwards?

2011-03-21 Thread Simon Budig
Ofnuts (ofn...@laposte.net) wrote:
 Why is gimp_vectors_bezier_stroke_lineto(vectors, stroke_id, x0, y0) 
 (and Stroke.lineto(x,y)) working backwards? If I add a lineto() to the 
 stroke, the point of origin
 (the one returned by gimp_vectors_stroke_get_point_at_dist(0,..)) 
 changes... I'm sure there is a good reason, but I can't find it. Can 
 someone enlighten me?

The reason is simply the internal data structure as well as a
(possibly over-)optimzation in the code. A lineto basically needs to add
three anchors to the list of anchors. If the current point is the
beginning of the list, you can add these three anchors in an O(1)
operation. If you'd append them to the end you'd have to first search
for the end, making this an O(n) operation (unless you of course keep
track of the other end).

The API does not guarantee consistency for the distance-point mapping
when the length of the total path changes. When I designed the API I
tried to avoid the idea of a specific start and end for each stroke,
since this would introduce a directionality which would not be visible
in the User Interface.

Do you need to have get_point_at_dist(0...) staying constant while
constructing the stroke with the _lineto-family of commands?

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


Re: [Gimp-developer] [Bug 325564] Use CIE LCH instead of HSL for layer mode Color

2011-03-16 Thread Simon Budig
Charlie De (charlieco...@yahoo.com) wrote:
 Could you please demonstrate your sincerity by escalating the 'bug' to
 critical? It would demonstrate commitment to really having this in
 2.10, rather than just 'looking at it'. I think you owe it to the
 developer to make that gesture at the very least.

critical in Bugzilla has a specific meaning: It means that the bug can
cause the application to crash and cause e.g. data loss.

There is the target milestone for the purpose of indicating in which
version this is supposed to be fixed, but this already is set to 2.10.

Bugzilla is a tool to manage bug reports and/or accepted feature
requests, and we try to use it as such. Overloading random bug
attributes with different meanings does not help here.

Bugzilla is not a tool to demonstrate commitment or to fulfil other
social purposes. I think it would be the wrong place.

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


Re: [Gimp-developer] scanfs without field width limits making Gimp crash

2011-01-24 Thread Simon Budig
Nelson A. de Oliveira (nao...@gmail.com) wrote:
 While testing gimp with cppcheck I saw a lot of warnings caused by the
 usage of scanf and fscanf without specifying a width limit.

For Gimp itself there is a bug report on this issue at
https://bugzilla.gnome.org/show_bug.cgi?id=639203

I guess I'll commit the patch attached to the bugreport soon unless
someone has a better suggestion.

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


Re: [Gimp-developer] scanfs without field width limits making Gimp crash

2011-01-24 Thread Simon Budig
Nelson A. de Oliveira (nao...@gmail.com) wrote:
 On Mon, Jan 24, 2011 at 8:26 AM, Simon Budig si...@budig.de wrote:
  For Gimp itself there is a bug report on this issue at
  https://bugzilla.gnome.org/show_bug.cgi?id=639203
 
  I guess I'll commit the patch attached to the bugreport soon unless
  someone has a better suggestion.
 
 But here, for example (from your patch):
 
 snprintf (fmt_str, sizeof (fmt_str), %%d %%d %%%lds, sizeof (endbuf) - 1);
 if (sscanf (line, fmt_str, t-majtype, t-type, end) != 3)
 
 Won't it still be affected by a very large integer (like the example
 that I sent on my initial message) at the first or second position in
 the file?

Ah sorry, should have mentioned that. The bug report is older than your
mail to the list. We had a report on the %s conversion earlier which is
what the patch attached to the bug attempts to fix.

The %i problems are new to me and I tend to think that these are bugs in
the libc and should be fixed there, although it probably would not hurt
to add some more length specifiers...

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


Re: [Gimp-developer] GUI enhancement patch from GIMP UI brainstorm blog

2011-01-05 Thread Simon Budig
Mathias Lindner (monocero...@googlemail.com) wrote:
 Can I add something?

Sure.  :)

 All fine to now, two controversial opinions that may be solved by some 
 trade-off... But I still have to give some critique: I have experienced 
 similar incidents quite a few times. Again, you may all be right and I 
 understand your perspective. But if you want to get/keep contributors 
 you want to consider *how* to stress your workflow. Please try some 
 empathy: somebody invests a lot of time (and even more important does 
 the step to actually start doing something) and is rejected with not too 
 much thankfulness. Or at least it sounds like that. I know about some 
 people that wanted to contribute but also gave up due to bad help and 
 harsh conversation.

I understand your concerns and I do share them - at least partially. So
with all clearness:

I do appreciate the effort from しげっち (I hope that comes out
correctly...  :)  and I love the fact that he actually dived into the
code and made this work. We get a lot of why don't you? It is easy!
requests, and having some existing code is nice for a change.

Unfortunately we have a tendency to be a bit blunt in our wording and
rejecting stuff - even for hopefully good reasons - is hard. It does
have the advantage of being very clear, but yeah - it can put people
off, which is something I hate.

Especially with regards to the UI we currently are in a tricky
situation: On one hand the collaboration with Peter is very fruitful
and we got some enthusiastic responses to the stuff that has been
developed with his help. Since it is clear that a consistent UI does not
happen with people developing on random bits in the UI we - in my
opinion - need a person that coordinates the efforts in the UI, and that
person is Peter. On the other hand, yes, this unfortunately creates a
bottleneck (which scares me), but I don't see a good way around this.

So I really recommend to discuss stuff (on this list, in irc etc.)
before investing lots of time into code, that might get rejected for the
reasons mentioned above. This not only applies to GUI stuff, but to
other functionality as well.

In my opinion the current Gimp source code is in a very good state and I
tend to attribute this to strong maintainership and a reluctance to
accept random patches. Yes, this is sometimes hard on new contributors
(which we urgently need), but I don't think just opening the floodgates
would be a good strategy here.

What currently is needed is some more work on the single-window mode.
AFAIK there are some bugs in there and Martin (Enselic) can no longer
dedicate as much of his time to it as he used to. It would be awesome if
this work could be picked up and continued, I think a lot of the GUI
issues have been worked out already and there is a spec for it at
http://gui.gimp.org/index.php/Single-window_mode_specification .

Thanks,
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


Re: [Gimp-developer] GUI enhancement patch from GIMP UI brainstorm blog

2011-01-04 Thread Simon Budig
sigetch (sige...@gmail.com) wrote:
 Well, you don't permit the GIMP to have the toolbars even if it is
 OPTIONAL and it doesn't replace or overwrite any existing GUI policy ?

Each and every optional thing is a burden. Even if disabled it clutters
the preferences dialog, it makes inconsistent User-Interfaces across
installations (think about telephone support where you first have to
figure out how the user interface on the other side actually looks) and
it has the potential of confusing users. So before adding a new option
we need to make sure that it is really necessary.

 I think it can be merged as an optional code, and safely ignore that feature
 in compile time of runtime switch.
 (currently I don't implement any switches though.)

Compile-Time switches are a maintenance nightmare: If larger chunks of
code are not compiled by default, the code quality tends to degrade with
the time, since it does not automatically follow the rest of the code in
the case of API changes etc.

So another burden, which - given our very limited development ressources
- is not a good idea to have.

 I think open source project can have several policy as a optional
 implementations, and it can provide alternative way for users who has
 alternative demands.

I don't get how open source maps to several policys. Except maybe
that one easily can fork an open source project, if the predominant
policy feels wrong or unsuitable.

Which btw. you're free to do (although I'd consider this a bad idea).

I hope this helps,
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


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

2010-09-13 Thread Simon Budig
Joao S. O. Bueno (gwid...@mpc.com.br) wrote:
 On Sun, Sep 12, 2010 at 8:58 AM,  oli...@first.in-berlin.de wrote:
  (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 :-)

There already is an internal API that uses the gimp-path-prefix and I
wanted to avoid confusion. The new shiny vectors API should have its
own namespace, to clearly separate it from the old pesky
gimp-path-*-API  :-)

Also, the vectors infrastructure was designed to allow future extensions
that go beyond simple paths. The goal was to have a vectors object as
a container for strokes (i.e. connected bezier segments) or
circles/ellipses or contrast-following-segments. So it theoretically could
contain other stuff as well, going beyond plain paths.

That aspect has never been fleshed out, mostly due to
UI-confusion-considerations.

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


Re: [Gimp-developer] GIMP paths.

2010-09-10 Thread Simon Budig
Mirza Husadzic (mirza.husad...@gmail.com) wrote:
   Can you please open a bug-report and attach the most simple test case
   that you can come up with? We need a small .svg file that illustrates
   the problem. I am pretty sure that the problem can easily be fixed then.
 
 Here it is: https://bugzilla.gnome.org/show_bug.cgi?id=629318

Fixed in GIT. We miscounted the numbers in the points string when it
had additional whitespace at the end, resulting in a rejection of the
data, since an uneven count means invalid data.

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


Re: [Gimp-developer] GIMP paths.

2010-09-09 Thread Simon Budig
Mirza Husadzic (mirza.husad...@gmail.com) wrote:
 I think that better solution is that 'librsvg' do the parsing job and that
 GIMP can fetch points from the lib to render.

Using which rsvg function calls exactly?

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


Re: [Gimp-developer] GIMP paths.

2010-09-09 Thread Simon Budig
Mirza Husadzic (mirza.husad...@gmail.com) wrote:
  Using which rsvg function calls exactly?
 
 I checked the 'librsvg' and yes, there is no API exposed to satisfy this.
 Maybe the 'librsvg' can be subtly redesigned to expose this API? ;-)

I did not look at the librsvg internals, but interpreting svg data in a
way that results in a bitmap image is something very different from
preparing SVG data for easy consumption by an application. Just as an
example: Librsvg could just offload all the transformation stuff to
cairo for rendering the image. To provide path coordinates flattened
(with all transformations applied) it would have to compute the
transformations itself. So it is not obviously clear, that librsvg *has*
the data readily available for the use in the GIMP.

I don't see a good reason to abandon our own parser. If it has problems
we need an isolated testcase of a compact, validated SVG that results in
bogus paths. Then we can track this down.

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


Re: [Gimp-developer] Lab conversion, GEGL, RGB space, Illuminant

2010-08-11 Thread Simon Budig
Rupert Weber (g...@leguanease.org) wrote:
 D50 vs D65
 ==
 Another question during transformation to Lab is, which illuminant or 
 reference white to use.
 
 That part, I don't quite understand yet. Does that depend on the source 
 data, or simply on how the monitor is calibrated?

Well, Lab as a color space is not fully defined. Without further
information it is not possible to have a Lab color calculated back to
e.g. sRGB.

The problem is, that the white in Lab (100%, 0, 0) has no absolute
color coordinates. You don't know if this is a reddish white of a light
bulb or the blueish white of a fluorescent tube. In that sense Lab is
not an absolute color space, unless you define what you actually mean by
white.

So if you have a sRGB image (where sRGB defines D65 as the white point)
you can easily transform this into an Lab image, but you need to attach
the information the white is actually D65 to the result, to be able
to meaningfully be able to transform the image back.

Maybe this helps a bit,
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] Merchandizing for the GIMP.

2010-06-08 Thread Simon Budig
Hi all.

At LGM we threw some ideas around for Gimp-Merchandizing.

I am a little bit involved in this, since the company I work for -
kernel concepts - has a lot of experience with doing these things for
various free software projects. I am usually the person, preparing
artwork provided by the projects into something suitable for the product
in question.

While I am convinced that we do a good work there and I'd very much
welcome doing stuff for the GIMP please understand that I want to leave
the selection of a partner for merchandizing stuff to you, by no means
should my involvement with the GIMP imply in any way that GIMP should do
the stuff with us.

Having said that, here are some ideas what we have done already and what
could be explored. Also have a look at our shop, where some of the stuff
we have is presented:

   http://shop.kernelconcepts.de/product_info.php?cPath=22_30products_id=75

Options:

- T-Shirts and hoodies. We prefer silk-screen printing for T-Shirts,
  which gives a great durability of the shirt. It might be possible to
  create special effects like e.g. night-glow paint or colors with
  glittering stuff in them. (we did this for some LinuxTag-T-Shirts, but
  this may have to be re-evaluated, since our printing-provider recently
  changed his color-source)

- Mugs. We prefer silk-screen printing for the mugs. The openstreetmap
  mugs we did some time ago are done in some sort of transfer-print, and
  it turned out that the quality is not as good as we expected. We also
  have done some frosted-glass mugs, which can be printed on in clear.

- Pins. In fact we did a Gimp-Pin as the very first pin and grossly
  overestimated the sellability of a gimp pin. As a result we're now
  sitting on 100's of Gimp pins, which don't sell. So there might be an
  option for a special deal  :)

  They're silk-screen printed in 5 colors and beautiful. These are
  something I hand out frequently on community events, unfortunately I
  did forget them at this LGM.

- Stickers. We have a contact, who creates stickers with an epoxy cover,
  pretty much as you know them from PC case stickers. They are not cheap
  but can be manufactured in small quantities and can be arbitrarily
  shaped.

  Regular stickers for distributing are something we still need to
  evaluate a bit. We once created a set of custom shaped linux penguins:
  http://shop.kernelconcepts.de/images/tux_aufkleberbogen.png

  However, creating a custom shape for mass-printing stickers is
  expensive. It might be possible to ask for a standard layout of a 
  page full of stickers. We did not do this yet, but it should be fairly
  easy to figure this out.

- Keyrings and other small stuff: the guy creating the epoxy-stickers
  also offers products, which provide a place for the epoxy stickers.

  Some of you know the key rings with a shopping-basket-chip I handed
  out to some people. This kind of stuff. This could be an interesting
  option, since there is no setup cost and manufacturing can happen in
  fairly small quantities.

- Pens. For the FSFE we did a pen with analog printer printed on it.
  I wonder if it would make sense to have real world brushes and/or
  pencils with some reference to GIMP on it.

- Ties. Michael keeps asking for them. We once did a Tie with the
  BSD-Daemon on it. They're not cheap, minimum order is about 40, and
  I am not *that* happy with the quality, they feel a little bit weird.

- We also evaluated pins with blinking LEDs on them. Unfortunately we
  tend to care about regulations in Germany and when confronted with the
  requirements for the Elektro- und Elektronikgerätegesetz our
  supplier promptly retracted his initial offer, remarking oh, you're
  the first one to ask for this...

Please feel free to continue the brainstorm. We're not scared of new
challenges  :)

Tomorrow LinuxTag is starting again in Berlin and kernel concepts again
manages the merchandizing booth there. Feel free to drop by (I'll be
there on Friday and Saturday) and evaluate stuff.

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] Notes of the GIMP BOF meeting at the LGM 2010

2010-06-02 Thread Simon Budig
Hi all.

Thanks to all attendants to the LGM 2010, it was a tremendous
conference, I enjoyed it a lot.

And thanks to the organizers for coming up with the note taking
service: for our GIMP BOF agnez did jot down what was discussed, thanks
a lot for this.

I mostly left the notes unedited, except for filling in some missing
names. If you attended the BOF please feel free to fill in stuff you
feel is missing, and if one of the non-attendants wants to have some
clarification, please ask on the mailinglist.

Thanks,
Simon

annual gimp developer meeting
organizational meeting

collecting topics
agenda
- decide about future gimp website
www.gimp.org not updated any more...
and other sites
- improve to get non developers involved
- merchandising, gimp brand
- introduce google summer of code project
- coming gimp releases, generic chat about releases
- group photo



introductions
- Michael [schumaml], building gimps on windows admin german gimp forum,
  taking care about agenda, organise summer of code...
- Peter [guiguru], interaction architect, effort of renovating gimp ui,
  multiprocess
- Alexia [Death], estonia, paint tools,
- Simon [nomis], 13 years gimp involvement, no current projects
- Tobias [tobi], gimp user since 1.2, moderator german gimp forum
- Alexander [prokudine], using since99, technical support for russian
  users , russian documentation
- Agnez, note taker
- Tor [tml], finnalnd, no gimp involvement, gtk on windows
- Øyvind [pippin], gegl project
- Lukáš, krita, here for steeling gimp ideas
- Boudewijn, krita, here to see how gimp community works
- Michael [Bat`O] student, contributing code
- Joao, trying to keep functionalities
- Akkana [akk], user support, writing books about gimp
- Jakub [jimmac], not involved for over a year, getting into the dialogue


-- future of gimp websites
www.gimp.org, current release announced there is not up to date. the
site is running on a replacement system, parts of the site are broken
for several months, not going to be fixed on the actual server,
- same problem for wiki, spammed and not maintained, down now
- needed: new server, rent server service, no problem to pay,
dedicated server,
- needed: admin or maintainer is needed
paying someone full time is not foreseen, no one feels responsible for
taking care of this problem at the moment
- site maintainer needed

- hard deadline needed?
- who owns the domains? - Shawn Amundson, old gimp member, can
be asked to redirect or create sub-domains without problem

?? set up a gimp foundation? there was a call for ideas and actions,
no feedback came fo that idea
domain name should be owned by a foundation
- problem that Shawn owns the domain name? no problem per se, it
worked fine for yeas, but would be more appropriate via gimp
foundation.

money is not a problem, flow of donations is large, need to figure out
how to spend it. the money is there for a sysadmin

- hardware is more pressing problem than domain name discussion
- dedicated server

- existing custom build system for the websites
- buying hardware, or renting server, not important
- what hosting company? what software?
- hi traffic shouldn't be a problem, good quality hosting needed, not
choosing the cheapest!!!

?? who is going to lead the web projects?
traditionally : if someone starts to take a responsibility many will
follow and take decisions.
- alexia can take over some responsibilities, has been doing some of
[admin work] before, take care of technical part
- organizing migration to new technical hardware
- who asks Shawn about dns matters. joao can take care of that?

- choosing a hosting provider, do we care about the hosting country?
no us.
export regulations
autralia?

what can be taken of the site? what is going to be maintained?
some parts have been sleeping for a while
www top priority
registry.gimp.org for uploading scripts and other resources. has been
started by someone not close to gimp community but working good. has
been drowned by it's success, heavy to use,

?? www.gimp.org running on a cms system? we need internationalization!!
more system admin work?
no complicated roles for contributers!! blocking everywhere
take out the static part, throw away the python part, making adding
news easy
dynamic and localize

site that can involve people into gimp (content contributors)?
cms can be pain in the a**, but the actual site (git) is to technical
for many contributors
cms is going to get hacked,
dock books plain html is blocking people, keep it as simple as possible
basic machinery of the site should be founded in simple html, wikis
etc can be connected to it.use git for contributing
site going to stay static
jakub volunteering for taking care of the website

moderator access actually maintained by ingo (not present)
also taking care of content cleanup
ask him how the admin works, who has access to what? how is
maintaining working?

requirement set
registry as a one click install site

what happens if server crashes?
there are 

Re: [Gimp-developer] New on this list... how to start juming into Gimp-dvelopment?

2010-04-15 Thread Simon Budig
Oliver Bandel (oli...@first.in-berlin.de) wrote:
 I'm new on the developer list.

Welcome.

 I would like to help in pushing into the direction of overcoming the  
 8-Bit limitation. Also interesting would be for me to have more  
 knowledge on the plugin-stuff; I had already written some little  
 Python-plugins, but to know more about that would be fine I also  
 think about implementing a foreign language interface for OCaml.

For the 8-bit limitation the important keyword is GEGL, which is the
project we want to base on for higher bit depths. Pippin is the person
in the know there.

 At the moment I'm using Ubuntu and used the apt-get source gimp to  
 download the sources of the current Gimp on my distribution. I looked  
 for the necessary tools, which were not all installed. So then I  
 installed them.

I suspect this is not the current gimp source you're getting there. For
development you really need to look at the stuff in the git repository.

Of importance are the three git repositories babl / gegl / gimp, which
need to be built and installed (in your own prefix, not (!) parallel to
the system installed babl/gegl/gimp versions). For gtk+ and glib
development code the system stuff *might* be too old, we have debian
testing as a rule-of-thumb of the versions we depend on.

A lot of other information is available at http://developer.gimp.org/faq.html
and the surrounding pages. Probably does not answer *all* questions but
hopefully enables a start.

 It looks like a lot of code...

It is. But it is IMHO really good code...  :)

If you drop by in #gimp on irc.gimp.org (aka gimpnet) ask questions (and
wait patiently, it is not really a real-time-response channel) a lot of
questions could be answered live if you manage to catch the right
persons (which is not too hard if you ask specific questions). 

Hope this helps,
Simon (aka nomis in IRC)

-- 
  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


Re: [Gimp-developer] Bug #164774

2009-09-13 Thread Simon Budig
David Gowers (00a...@gmail.com) wrote:
 On Fri, Sep 11, 2009 at 6:54 PM, peter sikking pe...@mmiworks.net wrote:
  can somebody tell me why we have a tiny replacement for the menu bar
  right below the menu bar?
 
 The obvious answer here is that it's visible when the menubar is not.

Well, it has been introduced in the times where there was *no* menubar
and tablet-users (with no RMB) needed a way to invoke the menu.

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


Re: [Gimp-developer] connecting to update signal in uimanager

2009-06-29 Thread Simon Budig
Jordan Stinson (jordan.stinso...@gmail.com) wrote:
 I'm trying to hack gimp. For my purposes, I want to be notified when certain
 actions become sensitive, or insensitive. The way I wanted to do this was to
 store the actions I wanted to keep track of and connect to the UIManager's
 update signal. That way, when an update happened, my callback function would
 be called and I could loop through my list and check the sensitive property
 of my actions.

Wouldn't it make more sense to connect to notify::sensitive on the
actions you're interested in?

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] Raw notes from the LGM2009 BOF meeting

2009-06-17 Thread Simon Budig
Hi all.

I am sorry, but I forgot about the notes I took at the LGM2009 GIMP bof.

I'll just send them around in the state I took them during the BOF in
the hope that they are useful. If you have the impression that there is
stuff missing or that I misrepresent some of the discussions then please
feel free to comment.

Sorry for letting this slip.
Simon

Roadmap 2008?
-

trying to do 2.8 before SOC 2010

* Merge vector layer branch
  - might need some work, especially in the UI
  - undo is broken
  -- mitch, nomis?
  -- End of May Univ.-Project with Peter, possibly Vector Layers?
  try to get it in 2.8.

* Polish/finalize new features
  - on canvas Text editing
  must have in 2.8.

  - tagging
  no real problems at the horizon.
  Internationalization? (Jon: CREATE-Discussion)
  Support for Default-Tags?
  Multi-Select-Tagging? -- later.
  

* Default Tags for Default ressources
  - Alexia + Rore are working on it / Data Extras
  not suggesting any specific workflows, purely descriptive
  also avoid culture-specific references.

* finishing Save  Export
  how to get a unified dialog?
  (GtkPlug/Socket? Sounds evil. Supported on Windows? No.) (Review of
  current plugins, which are the most important ones? can we come away
  with widget-descriptions, similiar to script-fu?)
  (we're trying for 2.8 -- Enselic)

* unified transform tool
(optional for 2.8)

* Cairo Drawing on Canvas -- Sven?

-- so that we can do the unified transform tool?

* Summer of Code projects, integrate them into the codebase
  - python binding improvements (2008)

FFTW3 is a GPL library, so we have a licensing problem with
Frequency-Domain GEGL operations SOC, needs to wait for out-of-
process GEGL ops.

SOC 2009 final evaluation is on Aug. 24th
  - improved brush dynamics UI-- alexia
  - improved foreground selection

GEGL performance improvements (!)
  - API is stable
  - Gimp doesn't use GEGL in a good way.
  - second view with gegl widget?
  - nobody currently working on it 
  - not relevant to the 2.8 release

Other SOC projects are basically about GEGL and don't directly affect
GIMP.





Stani: Python 3.0: any plans?
   - there will be differences
   - depends also on pygtk et al.

Stani: Buffer-protocol for Gimp?
   - also in Python 2.6
   - Joao wants to include the SOC2008-Python-Code into mainline
   - separate module to not have to depend on python 2.6


-- 
  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


Re: [Gimp-developer] Hacking GIMP - Gimp top level menu

2009-06-16 Thread Simon Budig
Jordan Stinson (jordan.stinso...@gmail.com) wrote:
 Hi,I'm trying (for starters) to make the hue saturation tool visible in the
 toolbox.

Uhm, actually there is no need to start hacking for this:

1) Go to Windows - Dockable Dialogs - Tools
2) toggle the eye icon next to the hue-saturation tool
3) watch it appear in the toolbox.

Hope this helps,
 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


Re: [Gimp-developer] Support for SpaceNavigator

2009-06-15 Thread Simon Budig
Håvard Tørring (htoer...@gmail.com) wrote:
 Hello,
 
 I have a 3dconnexion space navigator that I would love to be able to use to
 pan and zoom the images in gimp.

Yay, I have one of these as well. Please hack on that  :-)

 The problem with this approach is that gimp ignores the value of the events,
 making it unusable. Browsing around the source code, I have identified that
 the events from the navigator are correctly identified in
 controller_linux_input.c, but when mapped to actual events, such as panning,
 the values from the controller are ignored, and the panning is performed
 with a fixed pixelcount per event. So my questions are as follows:
 
 - Are there any ongoing work with this controller that I should be aware of?

I am not aware of any current work in that area.

 - Are there someone that could give me a brief description of how the events
 from the input controller are communicated through the software? I have been
 unable to identify where in the code the calls to the panning and zooming
 functions are generated.

The linux input controller module has a mapping, that maps events to
so called actions, which are the same thing that e.g. get attached to
the menu. The mapping from event to action happens in
app/widgets/gimpcontrollerinfo.c in gimp_controller_info_event, which -
if it has a mapping - emits an event-mapped signal. This in turn gets
handled in app/widgets/gimpcontrollers.c, there you also see the logic
how events with values are handled. Basically the assigned action needs
to be an GIMP_ENUM_ACTION for the reported value to have an effect.

It is perfectly possible that the actions used to scroll the view are
not ENUM_ACTIONs and need fixing for this to work as expected.

I hope this helps,
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


Re: [Gimp-developer] open/save/export

2009-06-11 Thread Simon Budig
Graeme Gill (grae...@argyllcms.com) wrote:
 peter sikking wrote:
 
  what we really must avoid is the old confusion that users think
  that what they see in the window is just the jpg. it is not,
  else there would be no possibility to add a layer, a path, etc.
 
 If they've not actually added any of those elements, then it
 is actually just a jpg - ie. it should be possible to save a file
 without additional warnings to any format that is capable of
 representing all actually used elements.

No it is not.

It is decompressed pixel data. It would be a pure accident if a
recompression to JPEG would result in the same file.

The decompressed pixel data lives in a layer object, which has
properties like e.g. a name. The layer itself lives in a container
object, which also can contain channels and paths. There possibly are
attached parasites, containing thumbnail and comment information. A
default color profile has been attached if none was specified. Etc. pp.

It just no longer is a jpeg.

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


Re: [Gimp-developer] open/save/export

2009-06-10 Thread Simon Budig
Hi all.

Some random thoughts from me. Not sure if they form a coherent picture
though...  :)

peter sikking (pe...@mmiworks.net) wrote:
 [Liam wrote]
  Consider
 
  (1) open typewriter.jpg that came in from my camera
  (2) do some fun editing
  (3) save-as to go to typewriter2.xcf.gz
  (4) now I want to make a jpeg so other programs can use the file, so I
 can upload it on the Web, etc.  Aha! there's File-Export to
 typewriter.jpg,right there in the file menu.  I do this, not
 noticing that it's using the OLD filename,and the file is
 overwritten with no confirmation.  Because jpeg is lossy, I can't
 now get back the original (actually it was backed up)
 
 it is ironic that this tripped you up, because we spent s much
 time optimising this for that other substantial group that insists
 to really under all circumstances export back the xcf they have
 in their window (it is never a jpg or png...) to the original file.

The spec has the reasoning A much better reason for optimising are
situations where high-end GIMP users have to do some quick touch-ups on
graphic files for mates or clients, and send them back.

This is a Workflow, where I don't see a xcf-file (in the file system)
involved at all, i.e. the artist imports a PNG, does some touchups,
exports back to the same file and quits Gimp/closes the image, not
caring about not having saved his work.

Liams workflow had a step in it, where he conciously changed the
perceived identity of the image he is working on, by *changing* the
suggested filename. To me it would be reasonable to assume, that he did
this to protect his original file.

(A kind of related irk for me is btw., that an image imported from a flat
file format is Untitled and has the same naming state as a blank slate
created with File-New. It feels like throwing away information. It is a
bit unfortunate, that the Title is basically the same as the filename,
inkluding extensions. If we would change this to use e.g. the basename
with stripped extensions it would be natural to have - after importing
typewriter.jpg - a title of typewriter, which results in the default
suggestion of typewriter.xcf for saving and exporting (back) to
typewriter.jpg)

Upon saving as funky-keys.xcf - i.e. a conscious change of the title -
the default export-filename-suggestion could change to funky-keys.jpg
(Format derived from the originally imported file).

Note that this does not at all change the workflow in the spec for quick
touchups with no concious name changing involved, esp. if not at all
saving your work.

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


Re: [Gimp-developer] open/save/export

2009-06-10 Thread Simon Budig
Liam R E Quin (l...@holoweb.net) wrote:
 [...]  Experienced users are
 unlikely to want to overwrite the original jpeg, because they
 know it loses data.

Well, no. The Export to filename Menupoint is exactly for the
usecase that someone opens a jpeg, does some quick adjustments and fully
intentionally wants to overwrite the original file, because he does not
care about the full blown XCF data.

The point is, that with the semantic change of Save to use XCF
always (which is IMHO a very good thing) you lose this kind of
non-xcf-load-edit-save possibility for quick and dirty editing. Which is
why the Export to filename thing got added to accomodate for this.

The problem that arises with this is though, that the user suddenly
mentally has to deal with two not-really-but-nearly independant
filenames and to predict what a keyboard shortcut will do you have to
read the window title.

I think I'd prefer a tighter coupling between the XCF filename and the
Export-to filename, i.e. changing the XCF filename also changes the
basename of the Export-to-filename.

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


Re: [Gimp-developer] open/save/export

2009-06-10 Thread Simon Budig
gg (g...@catking.net) wrote:
 Subsequent Save as png should automatically set the default file name to 
 /path/foo.png .

*Please* try to be exact in this discussion. You *cannot* Save as PNG,
you can only Export as PNG. The *only* format you can Save to is XCF
and its compressed variants.

Thanks,
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


Re: [Gimp-developer] open/save/export

2009-06-10 Thread Simon Budig
Jay Smith (j...@jaysmith.com) wrote:
 On 06/10/2009 04:33 PM, Simon Budig wrote:
  gg (g...@catking.net) wrote:
  Subsequent Save as png should automatically set the default file name to 
  /path/foo.png .
  
  *Please* try to be exact in this discussion. You *cannot* Save as PNG,
  you can only Export as PNG. The *only* format you can Save to is XCF
  and its compressed variants.
  
  Thanks,
  Simon
 
 I have tried to stay out of this, but I can't resist any longer.  It is
 likely my own ignorance and/or not having seen a previous related
 discussion, but.

I'll make it short to not distract from the original point of the
discussion, if there is a need to discuss this in more depth, please
open a new thread.

 Why is there such a strong distinction between Save As and Export?
 
 To the _user_ what benefit is this distinction?

We want to make it absolutely clear to the user, that with basically all
fileformats you lose more or less information. We want the user to make
a conscious descision on that.

If some programs have both Save and Export and offer multiple
options in both of them, then hopefully all the options in Save can
store all the aspects of the document you're working on and load them
back properly.

More on the reasoning can be found in the spec:
http://gui.gimp.org/index.php/Save_%2B_export_specification

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


Re: [Gimp-developer] Wanted: Gimp Modification for Kids Product

2009-05-27 Thread Simon Budig
Jackson Tam (j...@sditech.com) wrote:
 We want to simplify things so that a kid could : 

Actually you might want to have a look at tuxpaint, which seems to have
the same target audience as you.

Hope this helps,
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


Re: [Gimp-developer] Changelog inactive or developers inactive?

2009-05-25 Thread Simon Budig
Lars Lindley (lind...@coyote.org) wrote:
 I usually follow the  http://developer.gimp.org/ChangeLog site to see
 what's
 happening in gimp.
 The last update there was on april 13:th and I guess there has been
 _some_ work
 done since then...
 Has that site been discontinued or has there actually been no
 develompent for a
 couple of months?

Don't worry, development is alive and kicking. However, the software
repository has changed from svn to git and that makes it inpractical to
continue the changelog in the same manner as up to this time.

http://git.gnome.org/cgit/gimp/log/ is the best link I find right now.
Not sure if there is a link where the commit messages have an expanded
description...

Hope this helps,
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


Re: [Gimp-developer] Gimp interface changes

2009-03-30 Thread Simon Budig
Nathael Pajani (g...@nathael.net) wrote:
 Right. Because I do not see why there are now two windows at startup.
 Yes, you pointed to the wiki explanation already. It seems you are all OK for 
 this empty unuseful window at Gimp startup

Please don't confuse your opinion with facts. This window is useful and
why it is useful has been discussed already or is described in the spec.

 With screens becoming wider, a vertical toolbox is not too much space wasted, 
 but that big empty window is here for nothing. You even had to specify what 
 it 
 should look like for it not to be mistaken for an image window. This was 
 impossible with the toolbox window.

But the toolbox window cannot fulfil the tasks of the no-image window.
For a start it cannot show the proper global menu.

  If the complexity increases logarithmic or linear is not that
  impotent. But I don't understand, why you are trying tu discuss facts.
  Every option is expensive. It costs time in programming, testing,
  documenting, supporting ...
 And ?
 Gimp is not a paint. I thought free software were not bound to
 create releases in time at the lowest possible cost.

Gimp not being paint - which in itself is a polemic and not-helpful
non-comparison - does not mean that we *have* to make our life harder
than necessary.

[...]
  Right and wrong.
  Right, the UI must not come as an afterthought.
  But the UI is not the main part of an Image manipulation program, it's 
  here to
  give access to it's capabilities.
  Have a look into the code, the UI is the biggest part in GIMP.
 The number of lines of code has nothing to do with what is important.
 Gnome is a UI
 Window managers are UI
 GIMP is an Image Manipulation Program
 The User interface is here to allow access to it's capabilities as an image 
 manipulation program.
 Or am I mistaken again ?

Count the numbers of people using gimp as a programmatic backend and
compare it to the number of people using gimp via the GUI. Then you have
a rough estimate if the UI of Gimp is important or not.

(Hint: There is a reason why we recomment imagemagick to people for
certain tasks)

   The UI actually is the main part of an Image manipulation program;
 NO
   at least, it's the main part of GIMP.
 NO again, because you are confusing it's goal, and the number of lines
 of code related to each part.

Why are you trying to argue against our own perception of the Gimp?
Isn't Gimp what the Gimp developers think it is?

  An other reason for keeping the 'New Image' at top is, that it is the
  recommended place from the Gnome HIG.
 And ?
 Gimp will become GNOME dependent ?
  (And the Apple HIG)
 Apple dependent ?

I guess we should follow the NHIG - i.e. The Nathael Human Interface
Guidelines. Because there is nothing that is researched better. /sarcasm

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


Re: [Gimp-developer] Please restore removed crop tool functionality

2009-03-27 Thread Simon Budig
Sampo Niskanen (spnis...@cc.hut.fi) wrote:
 The point is changing the canvas size, but leaving the layers uncropped. 
 The current crop tool always crops the layers to the selected area, so you 
 cannot fine-tune the position afterwards - previously there was the option 
 of cropping only the canvas, and the layers still stretched beyond the 
 canvas.

The current development branch has the menu entry Image - Fit Canvas
to Selection, which - together with the rectangle select tool - does
provide exactly this functionality.

I hope this helps,
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


Re: [Gimp-developer] new feature request - gimp

2008-10-21 Thread Simon Budig
Jim Michaels ([EMAIL PROTECTED]) wrote:
 Akima spline curves give drawing freedom, at least some kind of
 interpolating spline curve where you can just simply lay the points
 down and the curve follows along the points - I have a hard time
 getting bezier curves to do what I want.  It's like Alice in
 wonderland using a flamingo for a mallet in a game of croquet.
 unweildly.

Oh well, that all kind of depends on how you implement it. In the Curves
dialog we also use bezier curves and you don't really notice it, because
the control handles get determined automatically.

 Bezier Curves were introduced into Windows NT.  It seems like a lot of
 paint programs began including Bezier Curves as a drawing method after
 that.

Bezier Curves have a lot of (computationally) nice properties, making it
easy to implement it. Plus it really is nice how you can control them in
quite detail.

 Akima spline curves are cool.  just put points along where you want
 the curve. simple.  you just need more points around sharp edges, or
 you get a ringing effect around that area. (See discussion and
 visuals link).

Yeah, just laying down nodes is a cool way to edit curves. From your
links it seems that Akima-Splines have a better locality and are more
stable than e.g. Spiro curves.

The thing is that there are dozends of interpolation types that have
this laying down nodes editing property and it is hard to put a finger
on which one to choose. We do know that spiro curves have been developed
to create visually appealing curves by requiring certain smoothness
properties. That makes them an appealing choice for design oriented
programs. The instability of spiros however might kind of hamper their
adoption for real use though.

Do you know of any study on how suitable Akima splines are for graphic
design? It would be nice to have a comparison of different spline types
for this kind of application. I believe the criteria you mentioned above
(locality, interpolates all control points) are not necessarily enough
to judge on that.

Bye,
Simon


-- 
  [EMAIL PROTECTED]  http://simon.budig.de/
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] [wish] provide transparent color

2008-09-23 Thread Simon Budig
Maciej Pilichowski ([EMAIL PROTECTED]) wrote:
 Please, provide transparent color or in other words -- treat 
 transparency _also_ as a color.

I don't think that this is a sensible approach in general.

We currently use alpha to do proper antialiasing, compositing existing
photos on top of each other and in all of these cases a coupled
alphacolor (= color + alpha value) would be cumbersome and unhelpful.

 Such metaphor is more accurate to real world and thus more appealing 
 to weekend artist (who would like to do some things in simple 
 manner).

Note, that Gimp is not designed with the weekend artist in primary
focus. But even taking him into account the current model has served us
well for the last years and there has been very few discussion about
this specific problem, if it cropped up it was in the context of indexed
PNGs with alphacolors or generating textures for renderers. For the
general public the current model seems to generally work and I don't see
a compelling reason to change this.

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


Re: [Gimp-developer] [wish] provide transparent color

2008-09-23 Thread Simon Budig
Maciej Pilichowski ([EMAIL PROTECTED]) wrote:
 From: Simon Budig [EMAIL PROTECTED]
  But even taking him into account the current model
  has served us well for the last years and there has been very few
  discussion about this specific problem, if it cropped up it was in
  the context of indexed PNGs with alphacolors or generating
  textures for renderers. For the general public the current model
  seems to generally work and I don't see a compelling reason to
  change this.
 
 Well, one thing is history -- everything (in general) worked in the 
 past -- why introduce cars when horses... etc etc etc :-)
 
Well, historically new stuff always had to proove that it is better than
the old stuff and I personally don't think that is a bad thing.

I guess I have not yet understood what you actually want to achieve.

 The second thing is potential benefit -- and I believe less time spent 
 on creating an image _is_ benefit. Note, that it will not introduce 
 new features per se, it only could only change the way you work (if 
 one wishes so). You can work with colors with color tools and you can 
 only work with alpha channel with alpha channel tools. It is 
 narrowing possibilities -- why not pick up brush, shape, pressure and 
 polish a picture edges with transparency (as color)?

So how do you want to work with transparency? What should happen if you
have a semi-transparent red and you paint on top of blue? Currently it
gets blended on top of the blue resulting in some kind of violet and
that is a widely used feature to do natural looking paintings. I
understand your proposal, that you actually want to have a
semi-transparent red in the image after painting?

How is your new feature supposed to interact with tablets with varying
pressure devices like tablets? Right now you can map the pressure
information pretty naturally to the opacity. Your replacement approach
for alphacolors would directly influence the images alpha channel,
making it pretty tricky to lift off the pen without leaving a
transparent spot (tablets tend to add some events at the end et the
stroke with very low pressure).

How is your replacement approach supposed to work with multiple
layers?

I see lots of open questions here and I have doubts that your desired
workflow is an improvement over the current one. Also I think that most
of the tasks you mention in other mails - like cleaning up edges - can
nicely be done with the current gimp, provided that you don't need 100%
exact control over the alpha values (like the texture guys seem to need
it, but they are not the main target audience). So I still don't see the
problem here that needs to be solved.

Bye,
Simon

-- 
  [EMAIL PROTECTED]  http://simon.budig.de/
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] what means EEK ?

2008-06-02 Thread Simon Budig
Cristian Secară ([EMAIL PROTECTED]) wrote:
 A language string says this:
 EEK: can't undo
 What is EEK ?

http://www.levien.com/gimp/jargon.html: 

 * eek An expression of shock. Even better is to make Burrito eek. He
   does it so nicely. Derived from Eeek, a German, the standard
   greeting whenever jtl logs on.

also with a varying amount of es...  :)

I suspect that this is something that is basically never shown in the
UI, don't bother too much with it.

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


Re: [Gimp-developer] what means EEK ?

2008-06-02 Thread Simon Budig
Cristian Secară ([EMAIL PROTECTED]) wrote:
 On Mon, 2 Jun 2008 12:12:53 +0200, Simon Budig wrote:
 
  http://www.levien.com/gimp/jargon.html: 
   * eek An expression of shock. Even better is to make Burrito eek. He
 does it so nicely. Derived from Eeek, a German, the standard
 greeting whenever jtl logs on.
 
 Ok about EEK (thanks), but then ... what is Burrito ? This seems to be
 a Mexican food, how can a food have an expression of shock ? Or is this
 some cartoon character ? (this appears to be too cultural-dependant
 for successful internationalization)

http://www.levien.com/gimp/jargon.html: 
 * Burrito One of the #gimp's two beloved bots. Burrito is based on the
   same code as Xachbot, and is run by yosh. One of Burrito's most
   important extensions is its ability to eek. It also has a database of
   2-letter country codes.

Yeah, cultural-specific, but the culture is the Gimp IRC-Channel
culture. The text of that error message is probably not really useful to
translate since it is never shown to the user anyway (unless something
is very broken in the Gimp code)...

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


Re: [Gimp-developer] GSOC 2008 mentors list deadline

2008-03-11 Thread Simon Budig
Joao S. O. Bueno ([EMAIL PROTECTED]) wrote:
 That said, can I enlist you as Google Summer of Code 2008 mentors?
 - Simon?

Sorry, I am buried in work and most likely won't be able to mentor
adequately. Sorry again  :-(

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


Re: [Gimp-developer] Adding SpaceNavigator support

2008-03-04 Thread Simon Budig
Sven Neumann ([EMAIL PROTECTED]) wrote:
 On Wed, 2008-02-27 at 19:16 -0800, Ettore Pasquini wrote:
  After fixing that I was able to map the device actions and it works!
  Panning is pretty good, although there is no acceleration (moving the device
  hard or soft makes no difference).
 
 Does moving the device hard or soft make a difference in terms of what
 input events the Linux kernel delivers?

The value element of the struct input_event may contain values with
an absolute value  1.

I found it a bit tricky to work with these events. On one hand it
absolutely makes sense that the SpaceNavigator delivers relative events,
at least for the intended purpose. But this means that the amount of
pressure you apply controls the *rate* of the events, which is a bit
tricky to measure.

For me it would be easier to get absolute events from the SpaceNavigator
and - if needed - convert them to a series of relative events myself.
The other way around is not as trivial I think.

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


Re: [Gimp-developer] Adding SpaceNavigator support

2008-03-04 Thread Simon Budig
Ettore Pasquini ([EMAIL PROTECTED]) wrote:
 On 3/2/08 8:46 AM, Sven Neumann [EMAIL PROTECTED] wrote:
 
  On Wed, 2008-02-27 at 19:16 -0800, Ettore Pasquini wrote:
  
  It turned out to be a couple wrong assumptions on my side.  First the linux
  device file /dev/input/eventN was for some reason not readable by anyone 
  but
  root.
  
  I usually fix this by adding a udev rule that changes the device
  permissions for all usb input devices to allow the group plugdev to
  access the device.
 
 Yep, that's pretty much what I did.  I added a post to our forum:
 
 http://www.3dconnexion.com/forum/viewtopic.php?t=1917

For helix I have prepared the following udev rule:

KERNEL==event[0-9]*, ATTRS{name}==3Dconnexion Space*, 
SYMLINK+=input/3d-nav, MODE=0666

This matches the USB device name against 3Dconnexion Space*, which
should cover all 6DOF devices from 3Dconnexion. It also symlinks that
device to a fixed position so that programs can make assumptions about
the device name without probing the linux input layer.

Maybe this is useful for you.

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


Re: [Gimp-developer] Adding SpaceNavigator support

2008-01-25 Thread Simon Budig
Hi Ettore.

Ettore Pasquini ([EMAIL PROTECTED]) wrote:
 I work for 3Dconnexion (a Logitech company) and we make 3D input devices.
 We also care about popular 2D apps that could use the high sensitivity of
 our SpaceNavigator for panning and zooming.  GIMP was under our radar and
 now we are considering to add support for our devices.
 
 I am new to the GIMP code base so I wanted to ask some questions about the
 architecture first.  What would be the best way (from a pure engineering
 standpoint) to integrate my code? Meaning, via a plugin or just into the
 main app?  Are there modules for I/O events (to deal with tablets,
 controllers, etc) that I should start with and expand?
 
 BTW let's not worry about licensing issues now.  My code will obviously be
 shared and our devices are HID compliant, so no need to mess with
 proprietary drivers.

yeah, except for at least one quirk  :)
(I wrote the patch to enable the LEDs for the Linux-Kernel  :)

On what Operation System are you working btw.?

There already is a HID input module for the Gimp, you can find the
source code in the top-level modules directory, relevant are the
controller_*-files.

We have various input modules, also available is a MIDI input module.

The current architecture unfortunately does not yet allow you to hook
into the (paint)-Tools directly, you can only invoke actions. There
are lots of actions and it is easy to e.g. control the opacity.

However, you can not control the pointer position in this way.

Have a look into this, I'd be glad to help you to work on this.

Bye,
Simon

-- 
  [EMAIL PROTECTED]  http://simon.budig.de/
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] MIDI input controllers on Windows.

2008-01-21 Thread Simon Budig
barney holmes ([EMAIL PROTECTED]) wrote:
 Does MS Direct X input include Midi device support ? My USB Midi
 device and normal Midi did not show up in the list ... but maybe they
 can be supported through Direct X ?

There is a MIDI module for Gimp on Linux where you can map Midi events
to Gimp actions. I have no clue about MIDI on Windows and/or DirectX.
But if you figure out a way to get access to the raw MIDI Bytestream it
should be fairly easy to adapt the MIDI module.

Maybe this helps (and sorry for not spotting this message earlier)

Bye,
 Simon


-- 
  [EMAIL PROTECTED]  http://simon.budig.de/
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] next generation size entries

2007-12-18 Thread Simon Budig
Martin Nordholts ([EMAIL PROTECTED]) wrote:
 Simon Budig wrote:
  Martin Nordholts ([EMAIL PROTECTED]) wrote:
  I'm currently interested in looking into this, mostly because I think
  this needs a clean solution before I will be able to cleanly finalize
  the GimpRectangleTool.
  
  I have a prototypeish parser running here, specified with yacc:
  
  If you're curious I'll put the code online somewhere.
  
 
 Please do, it would be useful to have a look at it.

   http://www.home.unix-ag.org/simon/files/parseunit.y

I am not really convinced that it is a good idea to track the dimension
of the entry with the grammar, it probably is easier to do this
generically in the code and later check that the final result has
dimensions 1 or 0 (default unit).

Bye,
Simon

-- 
  [EMAIL PROTECTED]  http://simon.budig.de/
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] next generation size entries

2007-12-17 Thread Simon Budig
Martin Nordholts ([EMAIL PROTECTED]) wrote:
 I'm currently interested in looking into this, mostly because I think
 this needs a clean solution before I will be able to cleanly finalize
 the GimpRectangleTool.

I have a prototypeish parser running here, specified with yacc:

$ ./parseunit
2m + 3in
Result: 2.076200 m
40cm / 2in
Result: 7.874000
2m * 3ft
syntax error
2m * 3ft / 2in
Ergebnis: 35.998171 m

It kind of tries to track the dimension of the value entered and
currently bails out for dimensions  2. Not very reliable but it might
help for a good start of the parser.

If you're curious I'll put the code online somewhere.

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


Re: [Gimp-developer] momentary shortcut to the zoom tool?

2007-11-05 Thread Simon Budig
Sven Neumann ([EMAIL PROTECTED]) wrote:
 On Sat, 2007-11-03 at 10:25 -0400, Daniel Falk wrote:
  There doesn't seem to be a way to temporarily switch to the zoom tool
  while a button is pressed.  For example if I hold down ctrl + space, it
  would switch to the zoom tool, I could click-drag a rectangle to zoom,
  and let up on the ctrl + space, and it would switch back to the tool
  that was selected previously.  
 
 There is code in GIMP to temporarily switch tools. We used to use it for
 switching to the Move tool when Space is being pressed (this can still
 be enabled in the Preferences). I guess that code could be used to
 implement the described behavior. But I can't tell if that is a good
 idea or not. Or if it is likely to collide with other tools. Or with
 changes planned for other tools.

I am actually unsure if the Zoom tool really should be a tool. It is the
only tool that does not affect the image, but the display of the image
(the measure-tool at least lets you create guides).

At least for me it is an annoyance: I never really use it and if I use
it I am annoyed that it does not switch back to the previously used
tool.

I tend to think that it should be moved to the display of the image to
make it easier to fluently change the view/zoom on the image without
interrupting the current workflow.

-- UI team  :)

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


Re: [Gimp-developer] GIMP Vectors Object Documentation

2007-09-11 Thread Simon Budig
Sven Neumann ([EMAIL PROTECTED]) wrote:
 On Mon, 2007-09-10 at 21:04 -0700, Barton wrote:
  That's the gotcha that got me on this one.  Another minor issue is that 
  immediately after running draw_circle, the stroke appears in the layer 
  dialog but it does not appear in the image itself unless you toggle the 
  layer's visibility off and on.
 
 Does your script call gimp-drawable-flush()? If it doesn't, then it's
 not surprising that the image view is not updated.

Right, I forgot about this - The script I posted did not have the
(gimp-displays-flush) in it.

Also note that for general bezier paths it is a bit different - there
you would create a new stroke using
gimp-vectors-bezier-stroke-new-moveto and then pass its return values to
functions like gimp-vectors-bezier-stroke-lineto, -curveto, -conicto
etc. to iteratively construct the stroke in the vectors object.

I hope this helps,
Simon
-- 
  [EMAIL PROTECTED]  http://simon.budig.de/
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] GIMP Vectors Object Documentation

2007-09-10 Thread Simon Budig
Barton ([EMAIL PROTECTED]) wrote:
 I've tried translating the draw_circle script-fu to python, and also 
 checked the script-fu itself in my 2.3.18 installation without success;  
 the circular path is created but it isn't stroked. 
 
 Simon, did you write your sample script-fu for 2.3.19?

I created it for the current svn version. It shouldn't be a that big
difference, but I found a bug while writing it, which is fixed in
current SVN - this bug created artefacts in the created stroke, but you
should get a visible somethign.

Make sure that the context you're using for stroking is set up correctly
and make sure you're not stroking white on white or whatever.

Hope this helps,
Simon
-- 
  [EMAIL PROTECTED]  http://simon.budig.de/
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] GIMP Vectors Object Documentation

2007-09-04 Thread Simon Budig
Barton ([EMAIL PROTECTED]) wrote:
 I've been doing a little python-fu lately and find that in 2.3.18 
 stroking paths uses vector objects.  So far I haven't turned up any 
 practical examples of the use of the various pdb vectors functions in 
 the source or on the Web, nor had any success through trial and error.
 
 Could someone point me to documentation for the pdb vectors procedures 
 and/or post a brief sample python-fu snippet that creates a circular 
 path and then draws a circle by stroking the path/vector?

Here is a simple script-fu script to construct an circle and stroke it,
It should be possible to convert it to python easily.

Note that you right now cannot control every aspect of stroking, since
the gimp context does not yet store stuff like e.g. a dash pattern.

I hope this helps.
Simon
-- 
  [EMAIL PROTECTED]  http://simon.budig.de/
(define (script-fu-draw-circle image layer)
(let* (
   (w (car (gimp-image-width image)))
   (vectors 0)
  )
  (set! vectors (car (gimp-vectors-new image circle)))
  (gimp-image-add-vectors image vectors -1)
  (gimp-vectors-bezier-stroke-new-ellipse vectors (/ w 2) (/ w 2) (/ w 
3) (/ w 3) 0)
  (gimp-edit-stroke-vectors layer vectors)
)
)

(script-fu-register script-fu-draw-circle
Draw Circle
Sample script to draw a circle
Simon Budig
(c) 2007 Simon Budig
4. 09. 2007
*
SF-IMAGE  input image -1
SF-DRAWABLE   active drawable -1
)

(script-fu-menu-register script-fu-draw-circle
 Image/Filters/Render)
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Feature request, - liquid resize

2007-08-22 Thread Simon Budig
David Gowers ([EMAIL PROTECTED]) wrote:
 Anyway, if you give a link to a paper describing the exact workings of
 the algorithym, then it's much more likely that something will get
 done in relation to it.

It seems to be fairly straightforward and the results are beautiful. The
related paper is available at
http://www.faculty.idc.ac.il/arik/imret.pdf - but since this page is
pretty slow try these URLs:

   http://www.faculty.idc.ac.il.nyud.net/arik/imret.pdf
   http://www.faculty.idc.ac.il.nyud.net:8080/arik/imret.pdf

Would be cool if someone would tackle this.

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


Re: [Gimp-developer] 2.4 showstoppers

2007-08-07 Thread Simon Budig
Sven Neumann ([EMAIL PROTECTED]) wrote:
 374854 possible optimizations in Script-Fu 
 
   This one can possibly be closed or moved from the milestone. Waiting
   for a comment from Kevin.
[...]
 438997 Output on stdout when using script-fu console
 
   Looks like a low-hanging fruit. Some help from Kevin would be
   appreciated.

I'll look into these when at the camp.

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


Re: [Gimp-developer] Downscaling quality.

2007-08-05 Thread Simon Budig
Guillermo Espertino ([EMAIL PROTECTED]) wrote:
 David Gowers wrote:
  Perhaps you mean supersampling?
   
 Yes, it must be. I'm using a spanish localization of Gimp and try to 
 guess the correct translation.
 Is there a command line option to launch gimp in english (just once, not 
 permanent) so I can use the correct words when I'm reporting a bug or 
 discussing something like this?

Try
LANG=C gimp

AFAIK this works in most unix shells, most notably in bash.

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


Re: [Gimp-developer] Print plugin

2007-07-24 Thread Simon Budig
Alexandre Prokoudine ([EMAIL PROTECTED]) wrote:
 - Will it be possible since GIMP doesn't use Cairo yet?

It does implicitely, since it already depends on a GTK+ version that
depends on cairo.

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


Re: [Gimp-developer] A plan for GimpRectangleTool

2007-06-25 Thread Simon Budig
Martin Nordholts ([EMAIL PROTECTED]) wrote:
 With the introduction of helper functions like
 
 void gimp_rectangle_tool_constrain_aspect (GimpRectangleTool
 *rectangle_tool, gdouble aspect, const gchar *apply_on_x, const gchar
 *apply_on_y)
 {
   /* apply_on_x may be x1, x2 or center_x, same for on_y */
 }

Hmm, wouldn't an enum for apply_on_* make more sense?

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


Re: [Gimp-developer] about carol

2007-06-19 Thread Simon Budig
Sven Neumann ([EMAIL PROTECTED]) wrote:
 I don't know if everyone of the GIMP development team is as annoyed of
 Carol as I am, but I know that there are quite a few people who are.

I for sure am annoyed as well. I absolutely hate the idea of driving
someone out of the project and still worry about doing it, but I am out
of alternatives.

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


Re: [Gimp-developer] how to save plugin's data

2007-05-16 Thread Simon Budig
tao frank ([EMAIL PROTECTED]) wrote:
 I know that some data of plugin can be stored in GIMP's pool by the function
 below:
 
 gimp_set_data (some_data, mydata, sizeof (MyData));
 
 But how big can this data be? If I want to store a very big data, say, a
 color mask of an image, what should I do? Is it advisable to save this
 kind of data outside GIMP?

This data gets stored in the RAM and then sits there. Although there is
no limit on the size of this data this functionality is not intended to
store huge amounts of data. It is more about a small struct saving the
preferences of a plugin or similiar stuff.

If you want to store a color mask of an image consider storing it in the
image itself, e.g. in an extra channel or as a parasite. This has the
advantage, that it will get stored inside the XCF format and will
be available in the next gimp session.

Bye,
Simon

-- 
  [EMAIL PROTECTED]  http://simon.budig.de/
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Checking type for a GimpDisplayShell in 2.3.16

2007-05-15 Thread Simon Budig
Hi Terry.

Michael Terry ([EMAIL PROTECTED]) wrote:
 After presenting ingimp (http://www.ingimp.org) at LGM a week ago, it 
 was suggested we port it to the 2.3.x developer branch. The port is 
 almost complete, but I'm trying to understand a particular change 
 between the 2.2.x and 2.3.x code trees.

Yay!

 reference to gimp_display_shell_get_type). Our interaction logging code 
 is linked in with app/core; where does this missing function reside so 
 that we can use GIMP_IS_DISPLAY_SHELL?

This is in app/display/gimpdisplayshell.h.

Hope this helps,
Simon
-- 
  [EMAIL PROTECTED]  http://simon.budig.de/
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] scheme changes

2007-04-16 Thread Simon Budig
Renan Birck Pinheiro ([EMAIL PROTECTED]) wrote:
 Em Sáb, 2007-04-14 às 18:37 -0500, Jim Sabatke escreveu:
  I have a lot of scripts that no longer work under 2.3.x.  I
  understand that gimp has migrated to tiny scheme and variables need
  to be declared with let or let*.  I have tried and tried to modify
  some of the scripts and can't get them to work.  I've looked at
  examples of scripts that do work and I've gone over (and over) the
  syntax for 'let' in my Lisp books, all to no avail. 
 
 This might or might not be what you want, but for most of my scripts,
 replacing set! by define worked. 

I do believe that properly scoping the variables within a let*-block
would be more appropriate here. However, I really cannot tell without
looking at the problematic scripts. I'd be glad to discuss the issues on
this list, if someone could summarize this into a tutorial or something
I'd be glad to put it on the website.

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


Re: [Gimp-developer] [Gimp-Developer] One-click binary downloads via the gimp website

2007-04-10 Thread Simon Budig
Christopher Curtis ([EMAIL PROTECTED]) wrote:
 On 3/30/07, David Marrs [EMAIL PROTECTED] wrote:
  We already get Gimpshop users coming to the mailing lists asking for
  help and,
 
 Would it be a good idea to embrace these users as well?  Gimpshop may
 be a non-supported hack, but hosting a Gimpshop-specific list may
 provide insight into a larger user base with applicability to the One
 True GIMP.  IE: They're beating at the door, would it be a loss to let
 them in if only to lend an ear?

I don't think hosting a gimpshop-specific list is a good idea, it would
imply that we'd support gimpshop. Since we know that it is a badly
executed hack and its author apparently is not interested in
cooperation, I believe this would be a bad idea.

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


Re: [Gimp-developer] Rudeness on gimp devel and bugzilla - was:?Re: Tools

2007-03-23 Thread Simon Budig
Manish Singh ([EMAIL PROTECTED]) wrote:
 On Fri, Mar 23, 2007 at 09:42:03AM +0200, Shlomi Fish wrote:
 As brought up earlier, claiming other projects have significantly more
 developers is simply untrue. Please stop spreading FUD.

Oh, btw, FUD is another candidate.

AFAIK the term FUD has the very specific meaning of spreading
(mis)information with the intent to hurt a project.

Since this obviously is not the intent here, the term FUD in this
place is IMO wrong.

I thus propose the following simple rule:

- replace FUD with misinformation or ill researched information.

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


Re: [Gimp-developer] Rudeness on gimp devel and bugzilla - was:?Re: Tools

2007-03-21 Thread Simon Budig
Shlomi Fish ([EMAIL PROTECTED]) wrote:
 Actually I also think it was too rude. Let's analyze it:
[...]
 1. You didn't say hi.

Oh, come on. A lot of the mails on mailinglists don't include a greeting
if quoting something. I've never perceived that as *rude*.

 2. You phrased it as a question that implied the original poster should have 
 thought abuot it himself, instead of giving an answer.

Oh, come on again. It is not unusual to formulate a suggestion in terms
of a question. To pose this as rude is IMHO blown way out of proportion.

I really don't get why this discussion sparked from this specific mail.
Please also keep in mind that most of us are *not* native speakers and
discussing stuff in this linguistic nuances is probably a wasted effort.

[...]
 However, I believe Alpár's and Joao commentary was induced by the general 
 trend of treating people on this list (and potential future contributors) 
 rudely or impatiently. I've noticed this general trend here too after someone 
 made me more aware of it.

Funny, my impression is, that it got better in the last few months.

 I believe the GIMP could have been much better off today, if it weren't for 
 all the antagonism that the developers' have created. I mean, sure after 
 Spencer Kimball and Peter Mattis left the project and most of the other 
 original developers left to work on GNOME, very few developers were left. But 
 since then the community of FOSS developers grew by leaps and bounds, and 
 there shouldn't have been any problem finding much more potential developers 
 than we have today. There are plenty of fish in the sea.

I am concerned that this might not be exactly true. I don't have
specific numbers, but my impression is, that it is way harder to sort
the wheat from the chaff nowadays. In the beginning of the GIMP the
people who a) found the GIMP, b) bothered to subscribe to the
mailinglist, c) expressed interest in contributing generally already
were enthusiasts about free software. They used stuff like e.g.
slackware to convince their boxes to boot into linux. They were editing
textfiles to get an internet connection. They had a thorough
understanding of their system. This is no longer the case today. I mean,
I am teaching stuff at the CS department of our universities and there
really are students here who never did any programming and/or are
annoyed if they have to. I mean, WTF?

Granted, the pool became bigger, but the amount of fish in it did not
increase in the same proportion. And there are a lot more projects
fishing around in there.

I am not sure if this is a fair description, I probably sound a little
bit like a grumpy old man. Not sure what to do about this though...  :)

 Let's look at Inkscape for a counter example. They have been around
 for a much shorter time than the GIMP, but have made remarkable
 progress, because the atomosphere they have is much better. If they
 could do it, why can't we? Only because we reject potential
 developers.

I believe that reject is the wrong word here, because it implies that
we'd do this on purpose which is in general not true. We do have a habit
of expecting a lot from patches (look at the number of iterations some
patches go in bugzilla) but in general I believe that even the original
patch author will agree that the result is way better than what was
originally submitted. We also have the habit of expecting more than
half-baked ideas when someone comes up with an idea and sometimes ideas
are probed a lot before a developer admits that it might be a good idea.

I guess that these intentions do not always make it through to the
person presenting the idea and they take it as a hostile attitude of the
gimp developers (sometimes even threatening us with switching to other
applications). This is the area where we probably can improve things
a lot by being more careful with the language. However, the probing in
itself is necessary and important for the quality of the Gimp.

[and regarding inkscape - I like the project a lot and I don't mean them
any harm, but they lost me as a contributor even before I tried to
communicate with them - 430 source files in a single directory is a good
way to do this, hopefully they will improve there.]

About your suggestions:
 1. Create a page with some FAQs and canned responses in both HTML and plain 
 text formats. I volunteer to prepare and maintain this page. I also get sick 
 of reading more You should change the name of the GIMP, it is an insult in 
 English, When is CMYK/16-bit/whatever support coming?, etc. questions, but 
 I believe we can at least answer them politely.

Please add I will switch to [whatever] to that list...

 2. Have a system of self-moderation. Let the messages of developers with a 
 tendency to be rude and untactful pass through a small forward 
 of friendliness experts for approval and correction. IF the experts are 
 unhappy, they'll tell the senders to edit them and re-send them.
 
 Note that I'm not necessarily suggesting we 

Re: [Gimp-developer] Rudeness on gimp devel and bugzilla - was: Re: Tools

2007-03-20 Thread Simon Budig
Joao S. O. Bueno Calligaris ([EMAIL PROTECTED]) wrote:
 On Monday 19 March 2007 08:11, Simon Budig wrote:
   IMHO, refraining from posts like this could greatly improve the
   atmosphere of this list.
   It is really up to you to help  somebody with answering his
   question or not to help, but this answer only hurts and helps
   nothing.
 
  I don't agree with you there.
 ... (remaining ranst tossed on bascket)
 
 
 Simon, where does that forbid one to add words 
 like thanks, please, would and etc... to even a short answer, 
 like a FAQ URL???

Nothing forbids that. The absence of these things does not make an
answer rude though, which is the point I am arguing. I did hope that I
made that clear in the rest of the message, but since you perceived that
as a rant I seem to have chosen the wrong words.

As I said: there are other messages that can be interpreted as very
abrupt or curt, no doubt about this. And I really think that it makes
sense to reconsider certain standard sentences, especially - as Sven
explained - there certainly is no hurt intended.

 It is not really hard - and that is to you Mitch, you Sven, you Nomis, 
 to simply rememebr the person on the other sidee is sitll a human 
 being, is not it?

Since you were referring to me specifically as well, I'd like to ask you
to point out to me when/where I have chosen poor words or disrespect
towards the other human being. Feel free to discuss this on the list
although private mail probably is more appropriate.

Bye,
Simon

-- 
  [EMAIL PROTECTED]  http://simon.budig.de/
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Rudeness on gimp devel and bugzilla - was: Re: Tools

2007-03-20 Thread Simon Budig
[EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote:
 On Tue, 20 Mar 2007 12:21:23 +0100, Michael Natterer [EMAIL PROTECTED]  
 wrote:
 
  It is not really hard - and that is to you Mitch, you Sven, you Nomis,
  to simply remember the person on the other side is still a human
  being, is not it? Not less human for having less abilities to
  compile/hack complicated software projects, much less for simply not
  knowing how to do so.
 
  Come on, that is simply a rude accusation.
 
 Is it rude? It seems perfectly reasonable and polite to me.

Actually I too think that this is - uhm - not very carefully worded. It
implies that we actually do judge people only by their coding abilities
and/or cluelessness. Which is something I personally do not like to hear
about me (because I don't think it is true).

To be a bit more constructive here: If our way of communicating gives
the *impression* that we judge people by their coding skills only, then
we should try to work on this. I think that (especially in the bug
reports) there are subtle things that already would improve a lot:

- replace obviously with apparently.
- replace useless with not helpful
- sprinkle more please and thanks

there are probably other simple examples that would kind of defuse the
perceived rudeness. To me it is important though that we avoid the
corporate speak sound of some other projects, which in itselfs also
creates a barriere between the users and the developers as well.

As for the missing canned responses - it probably is fairly easy to
whip up a small javascript bookmarklet, that fills in the comment section
of a bugzilla entry, if one is really ambitious one could write an
firefox extension that automatically adds these to the context menu. But
really - a text file on disk with all of these would suffice.

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


Re: [Gimp-developer] Rudeness on gimp devel and bugzilla - was:?Re: Tools

2007-03-20 Thread Simon Budig
Hi.

Shlomi Fish ([EMAIL PROTECTED]) wrote:
 It took me 10 minutes to write.

Oh wow. Is it just me or is this really a *lot* of time? Personally I'd
consider answering 6 lazy questions per hour a waste of time.

(Sorry for not replying to all of your mail - this just stuck out to me)

Bye,
   Simon

-- 
  [EMAIL PROTECTED]  http://simon.budig.de/
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Meaning of delay in screenshot plugin

2007-01-30 Thread Simon Budig
Sven Neumann ([EMAIL PROTECTED]) wrote:
 Also your approach is very lame indeed. This discussion wasn't even
 close to coming to an end. It would have been a lot nicer to propose a
 solution instead of wasting time like this.

Please realize that your mails sound very much like you dont really want
to change anything. You nearly suggested removing the screenshot plugin,
you think of the current UI to be more appealing, you suggest
various workarounds. None of your mails up to Akkanas latest mails
even suggests that you are willing to reopen this issue.

Now you are demeaning akkanas IMHO valid approach which is IMHO not
fair. Fortunately you finally seem to open up a little regarding a
discussion of the UI. But I'd really appreciate if you'd value other
peoples work as much as you expect your own work to be valued.

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


Re: [Gimp-developer] changes in script-fu in 2.3.14

2007-01-30 Thread Simon Budig
Alexander Rabtchevich ([EMAIL PROTECTED]) wrote:
 Raphaël, this IS exactly my point! Why should the global variables be 
 prohibited if there is no difference in memory consumption with local 
 ones, only additional efforts to a programmer to track all parenthesis.

Because global variables are not allowed in scheme and global variables
are bad programming practice anyway (in basically all programming
languages). And misuse can do great harm - we've seen that.

Bye,
Simon


-- 
  [EMAIL PROTECTED]  http://simon.budig.de/
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Rotate tool

2007-01-14 Thread Simon Budig
Manfred Joerg ([EMAIL PROTECTED]) wrote:
 It would be nice if the rotate tool could do that for me. It could work this 
 way:
 - Click on the left hand size of the horizon
 - Shift-click on the right hand size
 - The rotate tool calculates the angle.
 
 What do you think about my suggestion?

Just use the corrective mode of the rotate tool and align the grid
with the horizon.

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


Re: [Gimp-developer] Successfull compile, will not run

2006-11-27 Thread Simon Budig
Milos Prudek ([EMAIL PROTECTED]) wrote:
 After successfully compiling gimp-2.3.13, on Mandriva 2007.0, Gimp fails to 
 run with this error message:
 
 /usr/local/bin/gimp-2.3: symbol lookup error: /usr/local/bin/gimp-2.3: 
 undefined symbol: gimp_vectors_stroke_type_get_type
 
 Should I file a bug report?

Please try 'ldd /usr/local/bin/gimp-2.3' first to verify that gimp does
pick up the correct libraries on startup. I suspect a broken
installation here.

Bye,
 Simon

-- 
  [EMAIL PROTECTED]  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] Resignation (fwd)

2006-10-06 Thread Simon Budig
Hi all.

No, it is not yet about me. Here is a mail Dave asked me to forward to
gimp-devel - he wrote it after he unsubscribed from the list and the
list is configured to members-only posting...

Dave, let me add that it was great to have you in the project, thanks
for the massive amount of good work you did. I hope that the very real
problems you mention will get resolved at some point.

Thanks for everything.
Simon


- Forwarded message from Dave Neary [EMAIL PROTECTED] -

Subject: Resignation
Date: Fri, 06 Oct 2006 14:42:11 +0200
From: Dave Neary [EMAIL PROTECTED]
To: simon budig [EMAIL PROTECTED]


Hi,

I'm resigning from the GIMP project.

I have come to terms with the fact that there will never be any code of
conduct in this community, and I don't identify with that. For many
years, yosh has been imposing his very particular view of the community
on mailing lists, IRC and all other gimp.org resources, and I'm no
longer willing to put up with it. I don't foresee any resolution to the
problem in the near future.

This isn't a decision I'm taking lightly (although I am certainly angry) 
and it's something which I have been thinking about for quite a while.

I've already contacted Google to let them know that Sven will be the
point man for the gimp for all things SoC, and I would like to have my
name removed from the [EMAIL PROTECTED] alias as soon as possible. If
you're interested in dealing with our money and donors, contact Sven,
and we'll get you sorted out.

It has been a great few years with the GIMP project, as coder, release
manager and LGM/GIMPCon organiser. I wish the project the best, and hope
that you can get past the community problems that you have.

Cheers,
Dave.



- End forwarded message -

-- 
  [EMAIL PROTECTED]  http://simon.budig.de/
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] SoC roundup

2006-09-11 Thread Simon Budig
Alexandre Prokoudine ([EMAIL PROTECTED]) wrote:
 On 9/10/06, David Neary wrote:
 * Proposal for wavelets-based imaging applications in GIMP
 Divyanshu Vats  (Simon Budig)
 
 Divyanshu successfully completed jpeg2000 support, and a number of image
 filters integrating wavelet transforms.
 
 Divyanshu's blog has no download links, registry.gimp.org knows
 nothing about wavelet and it's not clear if his code is going to
 make its way to 2.4 or after 2.4, or will be available as plug-ins at
 registry.gimp.org sometime later. Any updates on this please?

Since Divyanshu developed plugins that can easily live outside the core
he did not commit his stuff into CVS. I'd very much welcome if he'd
make his plugins available soon.

Regarding the inclusion in 2.4: Maybe the jpeg2000 plugin could be
included, although it relies on the not very popular obenjpeg library.
The other plugins are very rough and still need tweaking, before they
could be included.

Bye,
Simon

-- 
  [EMAIL PROTECTED]  http://simon.budig.de/
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Hard edged Ink tool?

2006-08-29 Thread Simon Budig
Henning Makholm ([EMAIL PROTECTED]) wrote:
 Scripsit Øyvind Kolås [EMAIL PROTECTED]
  I cannot use the smudge or blur|sharpen tool, gaussian blur doesn't
  work neither does unsharp mask, layer masks seems to work but get
  their alpha thresholded.
 
 Neither of which are something one usually needs in a situation where
 one wants to stick to a colormap while editing.
 
  To do any real work on an indexed image I already have to go by RGB.
 
 Your idea of real work is obviously very different from mine.
 I do lots of real work on indexed images.
 
  Duplicating this behavior in GEGL would not be appropriate in my
  opinion,
 
 I don't really care whether it is duplicated in GEGL or outside it, as
 long as the net effect of don't let my editing result in pixel colors
 outside this small predeterined palette is still attainable with the
 sum of GEGL + futureGimp.

I wonder if a quantize to palette Gegl Op would solve these problems.
In most of the cases when people are asking for an indexed palette, the
palette is already determined somehow, either by importing from the
image or by editing for a specific hardware or certain texture
conventions.

In that case you really could have a quantize op, that maps all colors
in the images to the appropriate colors in the palette. You'd have all
the power of semitransparent layers, all tools would work as expected
for a given definition of expected  :), blurring would work etc.

I am pretty positive that these problems could be sorted out when we
know what people working with palette-based images want to have. I am
just guessing on the needs here...

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


Re: [Gimp-developer] SoC - only four weeks left

2006-07-25 Thread Simon Budig
Michael Schumacher ([EMAIL PROTECTED]) wrote:
 It would be nice if everyone who is involved in SoC could provide a
 short status report - the overall progress, maybe some results (screen
 shots are usually very useful :). Or problems, if any.

I am mentoring two projects:

Proposal for implementing vector layers in the GIMP
---

Henk Boom is working on implementing vector layers for the GIMP and
has made nice progress. He basically has vector layers that work, a
rudimentary dialog for the stroke/fill properties, which could use some
HIG/GUI review, which is probably the place where input from you would
be helpful.

The vector layers do not yet get stored in XCF, there is a crash lurking
somewhere, we lack some updates (which I just figured out with mitch to
be a missing gimp_image_flush ()) and additional stroke types would be
nice, although they are probably the least important now.

Check out the soc-2006-vector-layers branch of this stuff and play with
it. I hope Henk is reading this as well and will get good input from
you.

Henk logs his progress at http://lunarcrisis.pooq.com/Gimp/SoC2006Log .


Proposal for wavelets-based imaging applications in GIMP


Divyanshu Vats works on several wavelet based image manipulation tools.
His first thing was a JPEG2000 plugin, he is now working on denoising
and inverse halftoning.

This is more a research-type project. He has some interesting results.
Since he is mainly working on standalone plugins the code is not in the
GIMPs cvs yet.

He logs his progress at http://deebuv.wordpress.com/, although I've seen
stuff that is not visible there yet. From the images he mailed me he has
inverse halftoning basically working, but I did not see that code yet.


I'd welcome if both of my mentees (?) would present their view on the
current status on the gimp-developer mailing list as well  :-)

I hope this helps,
   Simon
-- 
  [EMAIL PROTECTED]  http://simon.budig.de/
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] fact roundup

2006-07-19 Thread Simon Budig
Brendan ([EMAIL PROTECTED]) wrote:
 On Wednesday 19 July 2006 02:35, Sven Neumann wrote:
  On Tue, 2006-07-18 at 13:10 -0700, Carol Spears wrote:
   this is what i learned about how these booths are handled here in the
   San Francisco area.  to be mailed about their existence and to know
   about where to get the literature and such, you must have been owen
   taylors girlfriend.
 
  Stop this now. We don't want this mailing-list to be a place where
  people can spread such filthy and completely unfounded rumours. And
  don't start to discuss this with me or even try to provide evidence.
  Even if it was a fact, it's offtopic and simply doesn't belong here.
 
  Please unsubscribe yourself from all GIMP mailing-lists and leave us
  alone.
 
 I guess I'm confused. Does Carol represent some threat that I haven't noticed 
 in the year or so I have been watching this list? Does she have laser beams 
 coming out of her frickin' eyes or something? 

Well, we (as in old gimp farts) are dealing with this kind of shit for
at least four years now. If anybody of us would be able to understand what
Carol is asking for then there would be no issue - we would answer her
question and the issue would be no more.

Carol was basically a source of incomprehensible messages for four years
now. It is getting on at least my nerves. Other people told me that
they have left GIMP/Gimp-Web development because of her. That hurts,
especially for a project with that few active developers as GIMP.

In the last few mails carol is indirectly suggesting that the organisation
of the Siggraph stuff is somehow shady. We all want to kill Wilber -
whatever that means and Gnome is evil anyway. She coerces Dave to
respond to vague allegations about the GIMP-Gnome relationship,
financing, how-to-become-a-volunteer-for-siggraph and whatever

I am sick of that kind of stuff. I am about to unsubscribe from
gimp-developer because of that kind of stuff - reading gimp-developer is
no fun anymore, because at any time you can hit a message that has a very
confusing and frustrating content.

So yeah, Carol does represent some threat: Driving people away. This is
a very real problem for the GIMP.

Bye,
Simon

-- 
  [EMAIL PROTECTED]  http://simon.budig.de/
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] ANNOUNCE: GIMP 2.3.9 Development Release

2006-06-06 Thread Simon Budig
Alexandre Prokoudine ([EMAIL PROTECTED]) wrote:
 On 6/6/06, Sven Neumann wrote:
 Over the next weeks, we will try to add the remaining missing features
 and to iron out all the bugs that are blocking the 2.4 release.  Any
 help with that is very much appreciated.
 
 Is the plan to have SoC code in 2.4?

Unlikely. We should focus on stabilizing and have the new features from
the GSoC in the 2.5.x series. Then they have enough time to mature and
we can get out 2.4 without having to care about the timeline of the GSoC
program.

bye,
Simon

-- 
  [EMAIL PROTECTED]  http://simon.budig.de/
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Gimp-python: Artefacts when creating layer

2006-06-03 Thread Simon Budig
Sebastian Breuers ([EMAIL PROTECTED]) wrote:
 The plug-in, I'm writing, creates a number of layers, every layer receives an 
 object, for example a circle (created by ellipse selection, an selection 
 fill), but somewhen, don't know why, the layer contains not only the desired 
 circle but also some artefacts. Stripes, areas of white, the mouse cursor, 
 things they should not be there.
 Is that a problem that can be solved by a certain programmable handling or do 
 I have to remove these artefacts by hand?

That sounds as if you don't clear the layer before you use it for the
first time. Layers created from a Plugin are not initialized from the
very beginning. They need to be cleared using e.g. gimp_drawable_fill.

Hope this helps,
Simon
-- 
  [EMAIL PROTECTED]  http://simon.budig.de/
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Gimp-python: Artefacts when creating layer

2006-06-03 Thread Simon Budig
Alan Horkan ([EMAIL PROTECTED]) wrote:
 On Sat, 3 Jun 2006, Simon Budig wrote:
  That sounds as if you don't clear the layer before you use it for the
  first time. Layers created from a Plugin are not initialized from the
  very beginning. They need to be cleared using e.g. gimp_drawable_fill.
 
 I remember getting caught out by this too.  Why is necessary to manually
 clear a new layer rather than have it done automatically?

I have no strong opinions on that. I guess the reasoning behind this
behaviour was a speed optimization: If a plugin later renders stuff to
a new layer anyway it would be a waste of time to clear it
automatically. If it doesn't it would just invoke gimp_drawable_fill. No
harm done, except that you have to know about it.

It might even matter for big images...

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


Re: [Gimp-developer] Suggestion: Make the 'New layer' command defaultto 'New lay

2006-05-17 Thread Simon Budig
Martin Nordholts ([EMAIL PROTECTED]) wrote:
 1. GIMP wants to provide its users with a good workflow, independent and 
 unaffected by other similar applications.
 2. The majority of 'New layer' commands are equal, i.e. users rarely 
 changes the properties (width, height, prefilled color, etc) of a new layer
 
 I fail to see why this should not be adjusted.

As Joao already said, it is quite easy to create a new layer with the
default properties. Just Shift-Click on the New Layer button in the
layers dialog.

We earlier had it the other way around: Click would create the layers
with the defaults, Shift-Click would show the dialog.
We then switched it around again, because Shift-Clicking to get the
dialog, made the dialog a pretty hidden feature. Most people would not
even be aware that there is a dialog, that is pretty useful at times.

If the dialog pops up it is pretty easy to basically ignore it and hit
OK. The other way around is not so easy to solve.

Better have an undiscoverable workflow-optimization than an
undiscoverable feature.

If you know about the Shift-Click it basically is not more or less
convenient than a simple click on the button. Hence I don't see how
switching this around again would drastically improve the workflow.

I'd say, lets stick to the current solution, it works good enough (TM)
and we don't need to invent a different way to create new layers.

Bye,
Simon

-- 
  [EMAIL PROTECTED]  http://simon.budig.de/

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


Re: [Gimp-developer] Suggestion: Make the 'New layer' commanddefaultto 'New lay

2006-05-17 Thread Simon Budig
Martin Nordholts ([EMAIL PROTECTED]) wrote:
 We earlier had it the other way around: Click would create the layers
 with the defaults, Shift-Click would show the dialog.
 We then switched it around again, because Shift-Clicking to get the
 dialog, made the dialog a pretty hidden feature. Most people would not
 even be aware that there is a dialog, that is pretty useful at times.
 
 Ah, it was the other way around before, I see.
 
 From previous discussions however, I concluded that GIMP is not inteded to 
 be an app for newbies, but rather be effective to its faithful users.

I don't think that discoverability is about newbies vs. professionals.

 Better have an undiscoverable workflow-optimization than an
 undiscoverable feature.
 
 Note that the patch does not affect that when you use the Layer _menu_ 
 instead of the shortcut button in the Layer window, the dialog shows as 
 default. I find this quite logical too, that the shortcut command should 
 be fast, and the slower menu command should offer more details.

Actually it would be interesting to review the usage of buttons in the
GIMP, maybe it would be an interesting topic for an usability study.
Then we could try to make this consistent all across the GIMP.

I wouldn't be surprised at all if some usability engineer would tell us,
that buttons usually ask for an immediate action to the image (or
whatever is supposed to manipulated by the button) and that dialogs in
that case are not that usable. But I'd like to argue about this in a
more global scope. Discussing this for a specific button is not that
useful: Arguments get over-emphasized (as if this were the most
important button in the GIMP) and we lose the big picture.

 If you know about the Shift-Click it basically is not more or less
 convenient than a simple click on the button. Hence I don't see how
 switching this around again would drastically improve the workflow.
 
 Having to use two hands instead of one is a dramatic loss of workflow IMHO. 

Uh, please back that up.

 If you would want _one_ new layer per image, than this doesn't matter. 
 However, for more serious work where creating many layers often, having to 
 use the left hand for shift is not effective I think.

Why? I don't buy this.

Bye,
Simon
-- 
  [EMAIL PROTECTED]  http://simon.budig.de/

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


Re: [Gimp-developer] Suggestion: Make the 'New layer'commanddefaultto'New lay

2006-05-17 Thread Simon Budig
Martin Nordholts ([EMAIL PROTECTED]) wrote:
 Probably yes, but from what I remember, Shift + Click works in several
 more parts of GIMP's UI. If so, changing it would break consistence.
 
 I am not sure in what way? Yes, there are other commands that are altered 
 by Shift. However, the logical relationship between Shift and non-Shift is 
 (or at least should be) that the most common use of a certain button should 
 be executed with non-Shift, and the other (less used) command with Shift.
 
 If you agree on that, then this improves consistence.

I don't agree. First, determining what the most common use of a button
is, probably is subjective at all. And even if we could determine this
in an unambigous way we'd end up basically with a list: This button
shows a dialog, this button does not. Shift toggles this. The user would
have to learn the behaviour of all the buttons by heart, since there is
no simple rule to describe the behaviour all over the application. I
wouldn't call that situation consistent (Note that I don't claim that
the current behaviour is consistent).

Bye,
Simon
-- 
  [EMAIL PROTECTED]  http://simon.budig.de/

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


Re: [Gimp-developer] Suggestion: Make the 'Newlayer'commanddefaultto'New lay

2006-05-17 Thread Simon Budig
Martin Nordholts ([EMAIL PROTECTED]) wrote:
  If you agree on that, then this improves consistence.
 
 I don't agree. First, determining what the most common use of a button
 is, probably is subjective at all. And even if we could determine this
 in an unambigous way we'd end up basically with a list: This button
 shows a dialog, this button does not. Shift toggles this. The user would
 have to learn the behaviour of all the buttons by heart, since there is
 no simple rule to describe the behaviour all over the application.
 
 I strongly doubt that any regular user had any idea that that was the 
 logical connection between a Shift and a non-Shift click. I had no idea.

I did state explicitely that I don't claim that GIMP is consistent at the
moment. There is no doubt that the current situation can be improved. It
however IMHO cannot be improved by randomly changing the behaviour of
individual buttons.

 As I said, I always figured GIMP wants to be _effective_ to work with 
 rather than logical. I mean there are a lot of inconsistences in the UI, 
 however, they make it _effective_ to work with GIMP.

So to use GIMP effectively you have to go through a list of dozends of
buttons and memorize what they do when clicking and what they do when
shift-clicking?

My idea of consistency is: The user looks at a button and can predict
(maybe after learning one or two rules) what the button will do when it
gets clicked, and what it will do when it gets shift-clicked. Even when
he encounters this particular button for the first time.

Your approach involves a lot of guesswork: We have to make an educated
guess, what is the more frequent usage of each of the dozends of
buttons. Each user has to guess what we guessed. And I bet that there
are users out there who don't agree with our guesses. How do we defend
our guesses?

To exaggerate your approach: Wouldn't it be the most usable GIMP if we
keep counters for the button presses? And if it turns out that a user
uses SHIFT-Click more than a simple click, shouldn't we just switch the
behaviour of the button on the fly? Maybe we should also reorder the
buttons according to the button click count.

According to your arguments this would result in the most usable GIMP
ever, because we react to the individual usage pattern of each user. But
it basically will result in a Chaos, where it is unpredictable what a
specific button will do, even where it will be located. It is impossible
to document.

I firmly believe that simple consistency rules are important for
usability. And that saving 0.3 seconds per new-layer (assuming for 0.5
seconds, that your made-up number resembles reality) or 30 seconds per
100 new layers is not as important as a goal.

Conclusion: We definitely can improve the GIMP, but we need a
coordinated approach. A usability study would help here.

Bye,
 Simon

-- 
  [EMAIL PROTECTED]  http://simon.budig.de/

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


Re: [Gimp-developer] Suggestion: Make the'Newlayer'commanddefaultto'New lay

2006-05-17 Thread Simon Budig
Martin Nordholts ([EMAIL PROTECTED]) wrote:
 To exaggerate your approach: Wouldn't it be the most usable GIMP if we
 keep counters for the button presses? And if it turns out that a user
 uses SHIFT-Click more than a simple click, shouldn't we just switch the
 behaviour of the button on the fly? Maybe we should also reorder the
 buttons according to the button click count.
 
 According to your arguments this would result in the most usable GIMP
 ever, because we react to the individual usage pattern of each user. But
 it basically will result in a Chaos, where it is unpredictable what a
 specific button will do, even where it will be located. It is impossible
 to document.
 
 That sure is exagerating.

Sometimes it is necessary to exaggerate to make a specific point clear.

 For this particular button however, I think we are not even talking about a 
 majority, but rahter as good as _all_ users.

Yes. You think. And you have no way to back that up.

I for myself *do* use the dialog occasionally, mainly for creating new
white layers.

 If you ask yourselves, how often do I need to adjust the settings of a 
 layer, and how often do I just click OK on the dialog, what is your answer?

I am not sure you are trying to understand what I write. If you've read
my mails you'd understand that I don't see a point in arguing about this
single individual button. I'll readily agree that you have a point when
looking at this specific button in an isolated manner. Heck, I even was
involved into making this button behave in this way before we reverted
it back to its current behaviour. But that is not my point.

My point is that we need to look at the big picture. The New-Channel and
New-Path button behave the same way. In a lot of other dockable dialogs
there are New-Buttons as well. For the reasons stated earlier I want a
consistent behaviour. This is not the case currently, but your change
won't make it more consistent at all. We need to analyze these things
and change them in an coordinated manner. Read: Usability-Study or at
least a description of the current situation and then try to improve
that.

If you don't adress the big picture in your future mails I don't see
much point in a further discussion.

Bye,
Simon

-- 
  [EMAIL PROTECTED]  http://simon.budig.de/

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


Re: [Gimp-developer] SOC - brush system

2006-05-08 Thread Simon Budig
Philip L. ([EMAIL PROTECTED]) wrote:
 You've given me another idea, though. Perhaps the path tool could be
 extended so that each node in a path could be a 'keyframe' in the
 stroke, holding brush parameters at that point. This would certainly
 make path stroking more powerful. On top of that, there could be a way
 to record a brush stroke into a path approximation, also holding brush
 parameters as measured during the stroke. It could then be edited and
 'replayed' as desired.

Actually the vector objects already store GimpCoords at the control
points and hopefully the code already interpolates them properly. This
is all totally untested though, since there is no real way to control
the additional parameters (pressure, xtilt, ytilt, angle).

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


Re: [Gimp-developer] SOC - brush system

2006-05-07 Thread Simon Budig
Philip L. ([EMAIL PROTECTED]) wrote:
 I'm considering creating a new brush system for the GIMP as part of the
 Summer of Code in order to make GIMP more suitable to digital painting.
 I've made some contributions to the project before, but it has been a
 while. Can anyone comment on how extensive changes to the rest of the
 codebase would need to be, how this would be affected by the future
 incorporation of GEGL, and whether this could be completed in the
 allotted time?

It is not exactly clear to me what you mean by how extensive changes to
the rest of the codebase would need to be - this seems to me to be very
much up to you and your ideas for the brush system enhancements.

As for GEGL, I believe in your case it is pretty safe to ignore GEGL for
now and just work on the current model. You should keep your code that
generates the images that get pasted on the layer as generic as
possible, so that it can be changed to different pixel data
representations later (16-bit, floats, maybe other color models etc.)

Does this help?

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


Re: [Gimp-developer] RFI: Article on GIMP Development for LinuxFormat magazine

2006-04-27 Thread Simon Budig
Michael J. Hammel ([EMAIL PROTECTED]) wrote:
 I'm looking for feedback on this (see below) from both core developers
 as well as casual (infrequent) contributors and end users.

Ok, I guess I am a casual core developer...  :)

I'll just drop in some thoughts, not really ordered

 Here is a summary of what we're looking for in this article:
 
 Part I:  Overiew and History
 -  Overview of the development process:
design/planning, development, bugfixing, and release
 -  Who are the current GIMP core developers?

Not enough people. Sven and Mitch do most of the work on the core, then
there are some people like me who donate less time to the GIMP than
they'd like to. See the Changelog to get an idea about the number of
really active developers.

Then there are people like Pippin, who does groundbreaking work that is
not visible in the GIMPs changelog yet.

 -  The joys of bugfixing and generally being involved in a project's
development - preferrably from a non-core developer's point of view
 -  Overview of Bugzilla
 -  This history of the GIMP CVS repository:  access and support

We use Gnome CVS, people who contribute good patches via bugzilla can
get CVS access pretty quickly.

 -  Where to go for help: mailing lists, web sites
 
 Part II:  Getting Involved
 1. Finding a bug and how to reproduce it simply.
 2. Reporting the bug.
 3. Finding the broken code (show code)
 4. Fixing it (print the solution too)
 5. Making a patch file and submitting the fix (step by step).

Maybe it would be good to actually fix a bug in the article. That would
probably require to quickly spot something small that can be fixed
easily. Look for Bugs with the gnome-love keyword.

 Additional info (usually presented in sidebars):
 1. Photos of developers and/or people I correspond with and are quoted
 in this article
 2. 1 sidebar on Writing a GIMP Plugin
 3. One or more of the following:
a. 1 sidebar on GEGL
b. 1 sidebar on Developer Wishlist
c. 1 sidebar on the 5 most annoying GIMP bugs
d. 1 sidebar on important bug fixes provided by non-core developers
 
 Any additional advocacy information is also welcome (Carol, you've got
 lots there, right?).
 
 The annoying bugs should come from non-developers because we want to
 show people what needs to be fixed as encouragement to have them come
 fit it.

It might make more sense to harp on the gnome-love bugs, since they
are specifically marked this way because we consider them easy prey for
new developers.

I hope this helps,
Simon
-- 
  [EMAIL PROTECTED]  http://simon.budig.de/

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


Re: [Gimp-developer] GIMP and Google SoC

2006-04-22 Thread Simon Budig
Gerald Friedland ([EMAIL PROTECTED]) wrote:
 However, as far as I understood, there is still an issue: Is GIMP able
 to display non-binary alpha values? I loaded in a PNG that I created
 using the SIOX demonstration Applet and I saw that GIMP binarizes the
 alpha values

This should only happen for indexed images, then indeed GIMP does
binarize the alpha values, at least in the display. If the PNG is stored
as a RGBA-PNG then everything should be fine.

Hope this helps,
Simon
-- 
  [EMAIL PROTECTED]  http://simon.budig.de/
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] GIMP and Google SoC

2006-04-22 Thread Simon Budig
William Skaggs ([EMAIL PROTECTED]) wrote:
 4) Vector layers and tools to manipulate them -- allowing adjustable
 rectangle and ellipse shapes, lines with arrow, etc.

Actually my roadmap for vector layers would look something like this:

  - create the infrastructure to have vector styles, i.e. a vectors
object has fill and stroke attributes. Create GUI to edit these
styles.

  - make it possible to create a connection between a vectors object and
a drawable, similiar to a text layer: the drawable gets rerendered
when the vectors object changes.

  - probably it should be possible to attach multiple vectors to a
single drawable. Each vectors object would have its own style
attributes and the order in the paths dialog would determine the
rendering order on the drawable.

  - Try to figure out a workflow for editing this in a sane manner. IMHO
the path tool is sufficient to edit the shape of the associated
path, but all the other stuff might need some thinking.

Stuff like rectangle and ellipse shapes are not inherently connected to
the vector layer stuff, they would simply be different stroke types. I
already have implemented an proof-of-concept rectangle stroke type, that
is a bit weird to edit, but works.

I offer to mentor this project.

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


Re: [Gimp-developer] How Do I Customize GIMP

2006-04-12 Thread Simon Budig
digi artist ([EMAIL PROTECTED]) wrote:
 I have just been introduced to GIMP and think it is a great software.
 I would like to be able to customize it i.e. change menu options,
 Toolbox, hide the layer box on startup and change the splash screen.

Just close the layer box and it will stay closed - gimp does its own
session management, so that your dialogs will stay where they were on
last startup. You can edit the visible tools in the toolbox by changing
the order in the File-Dialogs-Tools dialog: Toggle the eye for the
visibility of the tool, drag the tools around to change the order in the
toolbox.

To change the menus you need to edit XML files and I actually don't
recommend this since it might make it harder for you to follow
tutorials. However, we are interested in feedback if you believe that
some changes to the menustructure would improve the usability.

Bye,
Simon
-- 
  [EMAIL PROTECTED]  http://simon.budig.de/

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


Re: [Gimp-developer] Why be cryptic? 'Xtns' should be name 'Extensions'

2006-03-21 Thread Simon Budig
Martin Nordholts ([EMAIL PROTECTED]) wrote:
 I am also a big fan of usability though, and I must wonder why there is a 
 menu item named 'Xtns'? From a usability point of view, it is not very 
 good...

For hysterical raisins. It has been there forever and we have not yet
found a good place to put the stuff in it. The stuff in it is not
specific to an image, hence the image menu is probably not the best
choice...

If you have suggestions, go ahead!

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


Re: [Gimp-developer] Why be cryptic? 'Xtns' should be name 'Extensions'

2006-03-21 Thread Simon Budig
Martin Nordholts ([EMAIL PROTECTED]) wrote:
 However, I think that when you use GIMP, the taskbar quickly gets bloated 
 with lots of images. Would a TDI (Tabbed Document Interface) be very tough 
 to implement in GIMP? TDI's have become very popular, and afaik lots of 
 people agrees that TDIs are very effective for handling multiple documents.

Please read http://bugzilla.gnome.org/show_bug.cgi?id=7379 - there
already has been an awful lot of discussion about this and your idea is
nothing new (Sorry). Please feel free to comment on this enhancement
request if you think you have something new to contribute.

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


Re: [Gimp-developer] Photoshop PSD 6 format Spec / Gimp XCF format Spec

2006-03-02 Thread Simon Budig
Frédéric ([EMAIL PROTECTED]) wrote:
 Gimp is OpenSource, and its file format should be open too. And so, well 
 documented. Even if it still evolves, it is possible to make something 
 without breaking previous rules when adding new features. Maybe by 
 providing an complete API, like HDF does.

Actually the current XCF format has its limitations and we are not
really convinced that it is a really good (tm) format, it has some
pretty severe limitations.

There were plans to work on a next-generation XCF resolving these
issues. I too see the need for a widely accepted exchange format for
multilayered images with a lot of additional information, but the
current XCF format does not meet the good enough criteria.

The main documentation for XCF is in the source unfortunately, and for
the reasons above we don't encourage support for XCF.

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


Re: [Gimp-developer] Photoshop PSD 6 format Spec / Gimp XCF format Spec

2006-03-02 Thread Simon Budig
Campbell Barton ([EMAIL PROTECTED]) wrote:
 Hey Gimp dev's (by the way, how many gimp dev's are there?)

well, that depends on how you define gimp developer - there are about
180 people listed in the AUTHORS file. The listed persons have at least
once added something to the GIMP in the last 10 years.

However, this number reflects the number of *active* developers very
badly: this year 16 people have committed something to the gimp core,
10 more than once and 3 people more than five times[*].

So, there is no army of developers eager waiting for stuff to do, to the
contrary - we really could use some more people contributing regularily.

Bye,
Simon

[*] These numbers unfortunately ignore the people that are helping
tremendously by giving good and detailed bug reports, sometimes with
good patches. Thanks to you all, keep up the good work!

-- 
  [EMAIL PROTECTED]  http://simon.budig.de/
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Selections in plugins

2006-01-28 Thread Simon Budig
Joël-Alexis Bialkiewicz ([EMAIL PROTECTED]) wrote:
 On 1/26/06, Simon Budig [EMAIL PROTECTED] wrote:
 
  Joël-Alexis Bialkiewicz ([EMAIL PROTECTED]) wrote:
  
   In fact I don't want to ignore selections but to use them in a different
   way. Especially, I would like to be able know, for a specific point,
  whether
   it is selected or not.
 
  You can request the selection as a drawable using
  gimp_image_get_selection(). You then can peek into this drawable to get
  the selection value for a specific pixel. You probably need to be
  careful with the offset handling a bit though.
 
 1) What do you mean by careful with the offset handling?

Layers are not necessarily at the 0,0 position of the canvas. The
selection however is. So you need to take that difference into account.

 2) When I read the data from the selection drawable, 1 means selected and 0
 means not selected, isn't it?

A selection is not binary. 255 means selected, 0 means not selected, 100
means partially selected.

 3) When I call gimp_drawable_mask_bounds and there is a complex selection,
 what part of the image does it point out to me? Does it correspond the
 littlest square possible containing all selected points?

this returns the bounding box, All pixels outside are *not* selected,
there may be not selected pixels inside.

 4) When I try to read a point that is not selected, will it give me the
 right value for this point or some dummy value?

When reading the pixels from a drawable the selection does not affect
the result. You always get the correct result (under the assumption that
you do read correctly...)

Hope this helps,
Simon

-- 
  [EMAIL PROTECTED]  http://simon.budig.de/
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Selections in plugins

2006-01-26 Thread Simon Budig
Joël-Alexis Bialkiewicz ([EMAIL PROTECTED]) wrote:
 My primary hypothesis is that gimp gives the full image (or a square portion
 of it including all selections) when you call gimp_drawable_mask_bounds, and
 that when you write your results using gimp_drawable_update, it just updates
 the selected portion of this square.
 
 There come my questions :
 A) Have I figuret it correctly?
 B) If not, how does it really work?
 C) Is there a way to force writing outside the selection?
 D) Is there a way to know if a given coordinate is selected or not?

The selection gets respected when you're using shadow tiles and use
gimp_drawable_merge_shadow. You can ignore the selection by not using
shadow tiles IIRC, I am at the moment not sure how this would affect the
undo system if you don't use shadow tiles.

Hope this helps a bit,
Simon

-- 
  [EMAIL PROTECTED]  http://simon.budig.de/

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


Re: [Gimp-developer] Selections in plugins

2006-01-26 Thread Simon Budig
Joël-Alexis Bialkiewicz ([EMAIL PROTECTED]) wrote:
 On 1/26/06, Simon Budig [EMAIL PROTECTED] wrote:
  The selection gets respected when you're using shadow tiles and use
  gimp_drawable_merge_shadow. You can ignore the selection by not using
  shadow tiles IIRC, I am at the moment not sure how this would affect the
  undo system if you don't use shadow tiles.
 
 In fact I don't want to ignore selections but to use them in a different
 way. Especially, I would like to be able know, for a specific point, whether
 it is selected or not.

You can request the selection as a drawable using
gimp_image_get_selection(). You then can peek into this drawable to get
the selection value for a specific pixel. You probably need to be
careful with the offset handling a bit though.

Hope this helps,
Simon
-- 
  [EMAIL PROTECTED]  http://simon.budig.de/

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


Re: [Gimp-developer] Filter source code

2006-01-23 Thread Simon Budig
Fred Lupien ([EMAIL PROTECTED]) wrote:
   sorry if this seems a bit out of place, but it seemed the most reasonable 
 list to post this question to. I am looking for the source code for the 
 filters in the Filters menu for a research on image processing algorithms 
 and I was not able to find them in the GIMP 2.2 source code package. Can 
 someone point me in the right direction please?

The filters in the Filter menu are the plugins. You can find them in the
gimp-2.2.X/plug-ins/  directory.

Hope this helps,
Simon
-- 
  [EMAIL PROTECTED]  http://simon.budig.de/

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


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

2006-01-11 Thread Simon Budig
Nathan Summers ([EMAIL PROTECTED]) wrote:
 On 1/10/06, Sven Neumann [EMAIL PROTECTED] wrote:
   (fopen path mode)
   (fwrite data stream)
   (fclose stream)
 
 Hmm, interesting.  I couldn't get this to work with script-fu under
 1.2, but it seems to work fine under 2.2.

Well, it certainly worked 7 years ago:
   http://www.home.unix-ag.org/simon/gimp/hotspots.html

:-)

Bye,
Simon

-- 
  [EMAIL PROTECTED]  http://simon.budig.de/

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


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

2005-08-26 Thread Simon Budig
Sven Neumann ([EMAIL PROTECTED]) wrote:
 Sven Neumann [EMAIL PROTECTED] writes:
   http://cvs.gnome.org/viewcvs/gimp/authors.xml?view=markup
 
  I am now looking for a volunteer to go over authors.xml and check
  what roles apply to the people listed there. Perhaps also check that
  noone important is missing (last time we did that was before the 2.2
  release). No coding skills required, you don't even need to know
  anything but the mere basics about XML.  Some knowledge of the GIMP
  history will definitely help though...
 
 No response whatsoever. So there isn't even interest in helping with
 the simple tasks any longer? This is becoming somewhat frustrating...

I am pretty sure that it is *not* simple and that there are very few
people being able to do that. And no, I don't think I could do this.
There are too many names in that file I've never heard of and I have no
interest at all go digging through ancient maillogs or changelogs just
to figure out if someone was a contributor or doc-writer or whatever.

I am surprised that you're surprised about the underwhelming response.

Bye,
Simon
-- 
  [EMAIL PROTECTED]  http://simon.budig.de/
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Snap To Canvas

2005-07-12 Thread Simon Budig
Joao S. O. Bueno Calligaris ([EMAIL PROTECTED]) wrote:
 On Tuesday 12 July 2005 08:16, Michael Natterer wrote:
[snapping to guides/borders by default]
  you have a point here. IMHO we should change this to snap by
  default. Would you file a bug about this so it's not forgotten?
 
 Beware there: 
 while snapping layers to the canvas on by default would be good, the 
 option also snaps paint strokes!!
 
 That is _not_ good to be on by default - one goes carefully painting 
 with the paintbrush, and suddenly it is sucked to the edge, out of 
 nowhere!!

While I agree that snapping to the guides would be a good default
(you're usually placing the guides conciously on the image) I am not
sure about the snapping to canvas borders by default. This is probably
unexpected to the unsuspecting user.

Bye,
Simon

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


Re: [Gimp-developer] Layer locking proposal

2005-06-27 Thread Simon Budig
Nathan Summers ([EMAIL PROTECTED]) wrote:
 On 6/26/05, Simon Budig [EMAIL PROTECTED] wrote:
  A way to overcome this is to have e.g. two lines per layer. A sample
  mockup is available at
http://www.home.unix-ag.org/simon/files/layer-dialog-many-properties.png
 
 This would work.  All you would need to do is increase the text 2pt or
 so, and make the icons visually look a little less like text.

Well, this is the small theme, a mockup with the regular theme would
probably also be needed to judge on that one.

Bye,
Simon
-- 
  [EMAIL PROTECTED]  http://simon.budig.de/
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Blending Modes: Mathematical Perspective

2005-06-27 Thread Simon Budig
Martin du Saire ([EMAIL PROTECTED]) wrote:
 In general, are there a handful of recommended sources (print or on-line) 
 that detail the typical image manipulation algorithms?

Have a look at http://www.pegtop.net/delphi/blendmodes/ , this explains
the mathematical background of several blending modes.

Bye,
Simon
-- 
  [EMAIL PROTECTED]  http://simon.budig.de/
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Layer locking proposal

2005-06-26 Thread Simon Budig
Sven Neumann ([EMAIL PROTECTED]) wrote:
 Simon Budig [EMAIL PROTECTED] writes:
 
  I also think that it will clutter the rows too much if we move it to
  the front. Perhaps consider to add it on the top of the dialog with
  the opacity slider and the Lock Alpha Channel toggle ?
 
  I don't think this is practical. In Skencil I use locking of layers
  as a method to quickly protect the layers of the objects I am not using.
  However, that means that I iterate over the column of the layer locking
  buttons and decide if I want to change that layer or not.
 
  Having to individually select the layers and then toggle the button
  somewhere else makes this feature basically useless.
 
 Well, we do that already for the alpha channel lock and it doesn't
 seem to work that badly. Sooner or later we will probably want to add
 more such toggles.

actually the alpha channel lock is a major source of confusion,
sometimes even for me. Huh, painting doesn't work. Also it has a
different use pattern: Your descision if you need to toggle it depends
only on the layer itself. This is - as I explained - very much different
from locking the layer completely: Your attention shifts to a different
group of layers and you want to toggle this on multiple layers
simultaneously. With your proposed solution it would be a major PITA to
do this.

Bye,
Simon
-- 
  [EMAIL PROTECTED]  http://simon.budig.de/
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Layer locking proposal

2005-06-26 Thread Simon Budig
Michael Schumacher ([EMAIL PROTECTED]) wrote:
  Also we should consider making the layers not selectable in the layers
  dialog if they are locked. This removes a source of confusion (why
  doesn't this work) and gives immediate additional feedback about the
  locking. 
 
 I was about to suggest this myself, but then dismissed it because of the
  why can't I select the layer? problem.
 
  However, it requires the locking button in the layer row itself.
 
 Hm, if you can't select it (e.g. with the cursor keys), how are you
 going to change the lock state using the keyboard?

Good question. Probably we need to grey out the layer somehow instead.
Or decouple focussing from selecting for these layers. Not sure if this
is easily possible.

Bye,
Simon
-- 
  [EMAIL PROTECTED]  http://simon.budig.de/
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


  1   2   3   >