Re: [Gimp-developer] Missing layer features

2005-06-25 Thread Sven Neumann
Hi,

Pedro Kiefer [EMAIL PROTECTED] writes:

 As a gimp user I've always missed two things, both related to layers.
 One is not having an option of locking a layer. The other is not being
 able to group layers, so that I can hide / show all the layers inside
 the group. Both of this appears as bugs in bugzilla. The first one dates
 back to 2001 [1], the other is from 2002 [2]. So I came to ask, is this,
 apart from the bugs reports, being worked on? If it's not, how can I
 contribute? I'm no expert in gdk / gtk programming, but I'm willing to
 learn whatever it takes to get these features in gimp. With that said, I
 would like to know where should I start? Could someone mentorship me?

You could start by making a nice proposal, perhaps including a mockup
of how the user interface for this should look like and how it should
behave. We can then help you to implement this, perhaps starting with
layer locking since that is probably going to be easier.


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


Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP

2005-06-25 Thread pcg
On Wed, Jun 22, 2005 at 11:53:18PM +0200, Sven Neumann [EMAIL PROTECTED] 
wrote:
  That is, I think the fundamental flaw. A user interface that works for the
  majority is a pretty idiotic goal. A user interface should work for ALL
  users, and likely should have features to support the majority.
 
 Yeah, of course. If it works for all users, that's even better. Are
 you trying to make an argument out of this now?

Are you trying to argue? Maybe there is hope for you then, although the
above is not an argument. It's better than activey ignoring what people
write.

  So that argument is *completely* and *utterly* bogus, firstly
  because you equate majority==newbies, and secondly because it's not
  a viable goal at all.
 
 So let's see then. The goal is to please you and ignore the majority?

You have weird ways of deliberately misinterpreting and twisting other
persons words. What does it buy you? Time? Ignorance? Shying away people?

 Developers are also users. But the same argument holds true for users.
 You can't find out facts about a user interface by discussing it.

Yeah, that should work, except here, as you immediately drive ad-hominem
attacks and spread FUD (again...). I don't think it's even remotely
possible to really discuss these issues with you.

 at any discussion out there. It is always a few people who are very
 loud at complaining. Are these users representative? No, they aren't.

You jump to conclusions. Maybe they are, maybe they are not. But I already
said that designing just for the majority is an idiotic goal, one that
gtk+ certainly _does not follow_, so telling me that that goal would be a
good goal contradicts reality.

 agree on. But that is not the case here. So, that's why I have made
 the offer of organizing a usability test with the goal to gather some
 facts on the current design compared to whatever we can come up with
 as an alternative. Feel free to ignore that offer.

Well, I certainly didn't ignore it, and unfortunately you know that.

 But if you do, don't expect me to ever discuss user interface issues
 with you again.

Yes, we *know* that your goal is to talk down and ignore this issue. Hint:
you did succeed again.

 The original problem was you accusing me of ignorance. That has been
 proven to be a lie. So please don't continue with it.

Just because you claim something doesn't mean it is proven. Sorry, but
that really is what I think is happening. It's far from being a lie.

 Still you failed so far to give a detailed and useful description of
 your problems.

That's another of _your_ lies. Sorry to use that word, it's really
not appropriate, but aybe if I talk in your language communicaqtion
improves? I even pointed you to working code that exactly reproduces the
desired behaviour (but it's not gtk+2 compatible, if you meant that. And
if you meant that, say so).

 You listed a few things but you never got further than
 half a sentence on each of them.

Another of your lies. You tactics is very simple: people complain
and explain, and you accuse them of not explaining and lieing. Then
people explain some more (because they have no idea which part of
their explanatiomn you didn't understand) and then they get some more
accusations.

In the end, you simply ignore them in good shape, as you always tried to
discuss, it's always the others who play bad and fail to explain their
issues.

 I still don't know what your complaints really are but

You should certainly know *that* by now, even if you might miss some
details. If you are really that dense, then for your sake just *ask*
instead of just producing more accusations. Just because you don't
understand something does _not_ mean people tried hard to explain it. Just
review tis thread.

But as your goal is not discussion but ignoring others (for whatever maybe
understandable reasons), this only drives people away again, with no
resolution for either side. It's just too frustrating to explain things
again and again and be told to stop whining and start explaining things.

 that you want the text entry back.

Well, at least that part got through.

 A useful complaint includes use cases, describes a
 certain workflow and outlines where the current UI gets into your way.

This has been done multiple times. You keep ignoring this and ask for it.
Maybe you don't receive all of the mails from this list?

In any case, I just tried to point out to you that you factually do
ignore this kind of discussion (in a very active way, actually, but
nevertheless), but you still don't get it. I won't intrude further into
your world, as all I wanted to do has been done, even though I couldn't
get through to you like so many others couldn't.

I am out of here again

-- 
The choice of a
  -==- _GNU_
  ==-- _   generation Marc Lehmann
  ---==---(_)__  __   __  [EMAIL PROTECTED]
  --==---/ / _ \/ // /\ \/ /  http://schmorp.de/
  -=/_/_//_/\_,_/ /_/\_\  XX11-RIPE

[Gimp-developer] Failed to compile the CVS

2005-06-25 Thread Jean-Luc Coulon (f5ibh)

Hi,

I got:

gcc -g -O2 -Wall -o .libs/aa aa.o  ../../libgimp/.libs/libgimpui-2.0.so  
libgimpconfig/.libs/libgimpconfig-2.0.so  
../../libgimpwidgets/.libs/libgimpwidgets-2.0.so  
../../libgimp/.libs/libgimp-2.0.so  
../../libgimpcolor/.libs/libgimpcolor-2.0.so  
../../libgimpmath/.libs/libgimpmath-2.0.so  
../../libgimpbase/.libs/libgimpbase-2.0.so /usr/lib/libaa.so  
/usr/lib/libgtk-x11-2.0.so /usr/lib/libgdk-x11-2.0.so  
/usr/lib/libatk-1.0.so /usr/lib/libgdk_pixbuf-2.0.so -lm  
/usr/lib/libpangoxft-1.0.so /usr/lib/libpangox-1.0.so  
/usr/lib/libpango-1.0.so /usr/lib/libgobject-2.0.so  
/usr/lib/libgmodule-2.0.so -ldl /usr/lib/libglib-2.0.so -Wl,--rpath  
-Wl,/opt/gimp-2.3.2/lib

aa.o(.text+0x379): In function `save_aa':
/usr/local/src/gimp/gimp-2.3.2-cvs20050625/plug-ins/common/aa.c:250:  
undefined reference to `save_d'

collect2: ld returned 1 exit status
make[3]: *** [aa] Erreur 1
make[3]: Leaving directory  
`/usr/local/src/gimp/gimp-2.3.2-cvs20050625/plug-ins/common'


Do I missed something ?

Jean-Luc


pgpaAe1WCTp45.pgp
Description: PGP signature


[Gimp-developer] Gimp - Innerbevel Effect ???

2005-06-25 Thread Thorsten Will

Hi guys!
Does Gimp support graphic effect like InnerBevel??? If so, can someone 
explain me please in a few lines (psydo basic or whatever)
how to code such an effect or where i can found the source of its 
routine or a link to a url explaining how to code such an effect?

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


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

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

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

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


[Gimp-developer] [Debian Sid issue] Failed to compile the CVS

2005-06-25 Thread Jean-Luc Coulon (f5ibh)
Some symbols (including save_d) are missing in the latest update of  
aalib



Regards

Jean-Luc


pgpnjciBg0kyD.pgp
Description: PGP signature


Re: [Gimp-developer] [Debian Sid issue] Failed to compile the CVS

2005-06-25 Thread Manish Singh
On Sat, Jun 25, 2005 at 12:30:02PM +, Jean-Luc Coulon (f5ibh) wrote:
 Some symbols (including save_d) are missing in the latest update of  
 aalib

Yes, the debian maintainer made a bogus change:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=315606

Downgrade aalib for now.

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


Re : [Gimp-developer] [Debian Sid issue] Failed to compile the CVS

2005-06-25 Thread Jean-Luc Coulon (f5ibh)

Le 25.06.2005 22:13:15, Manish Singh a écrit :

On Sat, Jun 25, 2005 at 12:30:02PM +, Jean-Luc Coulon (f5ibh)
wrote:
 Some symbols (including save_d) are missing in the latest update of

 aalib

Yes, the debian maintainer made a bogus change:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=315606

Downgrade aalib for now.


Done, thanks snapshot.debian.net ;-)



-Yosh


Thank you

J-L


pgp76SngK8h4I.pgp
Description: PGP signature


[Gimp-developer] Layer locking proposal

2005-06-25 Thread Pedro Kiefer
Objective: Lock the layer from user actions.

It should lock the selected layer or layer group, by lock I mean:
 - you cannot move the layer and it's contents
 - you cannot change the blend mode, the opacity and the keep
transperancy modifier
 - you can select an area to copy / define as pattern, et al.
 - you can restack the layer among the others layers avaiable or add it
to a layer group
 - the layer should still be visible in the image
 - when the layer is locked, and the user tries to use any of the locked
actions it should warn the user that the given layer is locked

Maybe a more advance locking mechanism would be good, but having this
basic locking is a good begin. I've done a little bit of research, using
this feature in photoshop. Photoshop adds 2 [1] more locking options,
pixel locking and position locking. The first locks the contents of the
layer, but it lets you apply transformations (scale, rotate, skew, etc).
The latter locks the position of the layer, but you can draw to it,
apply effects, etc but no transformations. Both of this locking lets you
change the blend mode and the opacity of the layer. As I said before,
this would be a simple locking mechanism, but if well designed it could
scale in the future to support this, and others desirables locking.

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

How all this should be implemented is something that I don't know in the
moment. I need to learn a little bit of how actions interacts with the
layer to try to propose some functions. But what comes to my mind is to
have a function that returns, based on it's caller, if the given caller
is able to act upon the given layer. And a simple set / unset pair of
functions to be called from the UI.

-- 
Pedro Kiefer [EMAIL PROTECTED]

[1] It actually photoshop has one more locking option, keep transparency
which is already implemented in gimp.
attachment: layer_locking_mockup.jpg
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Layer locking proposal

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

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

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

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

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

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

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


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

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

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

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