Re: [Gimp-developer] Dockable Dialogs Should be Dockable Everywhere
On Fri, Mar 27, 2009 at 08:51:10PM +0100, Sven Neumann wrote: > Hi, > > On Fri, 2009-03-27 at 20:29 +0100, David Odin wrote: > > > > > > Still that narrow minded? You obviously didn't read the drizzt's post > > at all! Drizzt was comparing the linux kernel _user_ interface with the > > gimp's _user_ interface. > > As far as I know the kernel doesn't have a user interface in the sense > the term is used for a graphical user application such as GIMP. It does > provide a lot of interfaces to device drivers and to the higher levels > of the operating system though. And these interfaces are changing quite > frequently. > I won't say that the syscalls or the /proc interfaces are changing that frequently. And when they change, the older behaviour is still available as an option. A device driver isn't really a user of the kernel, but a part of it. Whatever. > Perhaps this was a misunderstanding. I don't really understand the > purpose of the Linux kernel example. > > > Well, of course, everything could be better if more people would be > > even allowed to work on gimp. But I guess this won't happen since even > > confirmed former contributors aren't even allowed to commit trivial > > patches without having to explain many times what these patches do, and > > pass many many controls. > > No idea what you are referring to here. Can you explain to me what you > are talking about? Of course there is a patch review process. It would > be insane not to have one. But we are trying hard to review patches very > fast. Did you really have to wait an unreasonable time to have your > patches reviewed? > No. I won't explain all that once more since having to explain the same thing over and over instead of doing the real work is precisely why I have quit the gimp development. And it is also why the gimp development is so slow. I now prefer to give my time to some more attractive projects. I'm still a gimp user, though and I'm very desapointed to see which directions it takes. At least, I'm still able to maintain my own private tree when I want a special feature that won't get in because it would just take years to explain to every one why it is useful to me. -- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Dockable Dialogs Should be Dockable Everywhere
On Fri, Mar 27, 2009 at 08:02:13PM +0100, Sven Neumann wrote: > Hi, > > On Wed, 2009-03-25 at 14:52 -0700, drizzt wrote: > > > Just think of the most used piece of code on a GNU/Linux system: the Linux > > kernel. Didn't you know that the user interface is stable ? > > How would you feel if between releases the behavior of interfaces changed, > > and when asking the kernel developers you were told "just keep using the old > > kernel you used to". > > Obviously you have no idea of what you are talking about here. The Linux > kernel APIs are changing faster than anything else in the software > world. If you had ever maintained a device driver outside the main > kernel tree, you wouldn't have chosen the Linux kernel as an example of > something that doesn't change its interface between releases. GIMP is > very conservative compared to the Linux kernel. Our plug-in API has not > seen an incompatible change for five years now. > Still that narrow minded? You obviously didn't read the drizzt's post at all! Drizzt was comparing the linux kernel _user_ interface with the gimp's _user_ interface. As a matter of fact, I personnaly know drizzt and an I can assure you he really knows what he is talking about regarding kernel developping as he does exactly that for a living. > You also probably do not realize how much work an optional change is. > Every option that is added doubles the complexity of the code. It is > already impossible for us to test all possible configurations that GIMP > offers. If we tried to make major interface changes optional, the code > would become completely unmaintainable very soon. > Well, of course, everything could be better if more people would be even allowed to work on gimp. But I guess this won't happen since even confirmed former contributors aren't even allowed to commit trivial patches without having to explain many times what these patches do, and pass many many controls. You did everything to discourage people to contribute, so now, please, don't tell people you need ressources to maintain the whole mess. Cheers, DindinX -- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] One contributor less.
Today, the gimp community has lost yet another contributor. Me. I'm really fed up with the attitude of some here (Enselic, yes, I'm looking at you...) Gimp is really in need of more contributors, but before trying to even find new ones, maybe you should try to keep the few you have. I'm quitting this project. Don't ever ask me anything more. I'm left. Farewell. -- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Request to include Gimp Manual Book at Gimp.org
On Wed, Oct 22, 2008 at 10:22:11PM -0300, Monica Kraenzle wrote: > > The users manual version we used is for gimp 2.4, dated December 2007. > > I have uploaded a reduced pdf to show the cover and the interior pages: > http://www.maxishare.net/en/file/8416/gimp-manual-2-4-reduced-pdf.html > > Basicly it's nothing else than a printed version of the electronic > version (and it's NOT mass-distributed). > Basically, it is a _black_and_white_ printed version, which make most screenshots completly useless, at least that pdf is a B&W version. > The only customizations we made is creating a cover and formatting > this electronic manual to a printed manual. All authors and > contributors are credited. License terms and information about what > version as well as a link to the gimp.org site for software and manual > updates etc. are included. > Does that really allow you to put a copyright for the 2008 year on page 4? > As soon as there would be available an updated 2.6 manual we could > update the edition as well. > Repeat after me: "as soon as there would be available an updated 2.6 manual we WON'T publish a printed edition, but we will ASK the documentation team what to do, since we don't want to repeat the same errors again and again". > > Many others are distributing CD's with gimp software versions from the > website and are allowed to do so (surely these are also not always the > latest software versions without any bugs) and we printed the > electronic manual on paper ... Yes, they are allowed to do so, some are even contacting us beforehand, and all of them have to distribute the real official package (which is the tar.gz source package, and not an svn or unstable release), and none of them asked us to advertise their CD on our website. Again, I'm speaking in my name, and _not_ in the name of the gimp team (or I would have chosen another email address) Cheers, DindinX -- <[EMAIL PROTECTED]> ___ 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
On Tue, Sep 23, 2008 at 09:19:09PM +0200, Maciej Pilichowski wrote: > > From: David Odin <[EMAIL PROTECTED]> > > In the real world I live in, I have yet to see a transparent > > pencil. > > Wish granted -- simply use your finger (I assume you thought of glass > painting because it is only good metaphor source for working with > alpha channel in the first place). > So your wishes are granted too. There are already tools for that in the gimp toolbox: eraser and smudge. -- <[EMAIL PROTECTED]> ___ 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
On Tue, Sep 23, 2008 at 08:38:53PM +0200, Maciej Pilichowski wrote: > Hello, > > I know GIMP has alpha channel and it provides transparency. However it > is artificial for me that you have colors and then you have distinct > entity -- transparency. It would be useful (and _intuitive_) to have > black color, white color, ... and transparent "color", so user could > pick up color dialog, choose transparent and paint/draw with > transparency. > > 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). > In the real world I live in, I have yet to see a transparent pencil. -- <[EMAIL PROTECTED]> ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] simple suggestion for the UI
On Sat, Jul 12, 2008 at 07:38:33AM -0700, vabijou2 wrote: > > > > Bernhard Stockmann wrote: > > > > ...I wanted to suggest that if > > someone double clicks the main window (the one that is displayed if no > > other image is opened) the "new image" dialog should open. > > > > How would you propose for this functionality be discovered by the user? A message in the status bar would do it. -- <[EMAIL PROTECTED]> ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GimpCon dates
On Tue, Sep 13, 2005 at 12:07:25PM -0700, Carol Spears wrote: > On Tue, Sep 13, 2005 at 04:00:58PM +0200, David Odin wrote: > > > > The dates for the next GimpCon are march 17h-18th-19th 2006. > > > > Please have a look at http://wiki.gimp.org/GimpCon and confirm if you > > will come as soon as possible, > > > perhaps Mr. Neary can publish a list of people he will "allow" to attend > so that those people who are not allowed will not waste their time? > I for one will be honored if you can come. -- [EMAIL PROTECTED] He's not dead, He's electroencephalographically challenged. ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GimpCon dates
On Tue, Sep 13, 2005 at 04:00:58PM +0200, David Odin wrote: > Hi, > > The dates for the next GimpCon are march 17h-18th-19th 2006. > > Please have a look at http://wiki.gimp.org/GimpCon and confirm if you > will come as soon as possible, > Sorry, the correct link is http://wiki.gimp.org/gimp/GimpCon Sorry for this, DindinX -- [EMAIL PROTECTED] A woman never forgets the men she could have had; a man, the women he couldn't. ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] GimpCon dates
Hi,
The dates for the next GimpCon are march 17h-18th-19th 2006.
Please have a look at http://wiki.gimp.org/GimpCon and confirm if you
will come as soon as possible,
Cheers,
DindinX
--
[EMAIL PROTECTED]
D[4],n,d,*T,l,L;main(i,v)char**v;{if(i<3)return;L=atoi(v[1]);l=atoi(v[2]);T=
alloca(4*L*l);while(nhttp://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: new gfig [Re: [Gimp-developer] canvas background options]
On Sun, Nov 14, 2004 at 07:13:32PM +, Alan Horkan wrote: > > It might help you to understand my negativity when I explain that the > underlying instability of windows doesn't do the gimp any favours. When > binaries are available windows is the easiest platform to test on and in a > way the instability of the platform is actually helpful for testing. I > have tried to compile the gimp serveral times during 2.1 but rather than > asking even more questions here and needing to chase down and compile lots > of little dependancies and parts of the toolchain I dont have I waited > for more releases to try again (until eventually there was a windows > binary I could test with). > So, you're telling us you haven't yet tried the current cvs version of gfig, yet asking us to use the 2.0 one? > My comments [1] were very restrained, I did say it had potential. The new > SDI application style inteface for Gfig will be very good as it is an > easier way to present all the features that Gfig managed to cram into the > old dialog style of interface. The Gfig had crashed several times > (reproducably and in different places) I haven't seen any bug-report for this. I'm am aware of some bugs in gfig and I have told the mailing list about them. May be you could take the time to check if your crashes and mines are related? > and if I recall correctly it crashed badly enough to take the rest of > the gimp down with it. I really doubt it. > Feedback takes time, and I haven't gotten around to checking if the > problems are known issues or writing a detailed explaination of how to > reproduce them or otherwise tracking them down. One bug is very easy to trigger: draw a line, erase it, draw another line. Don't tell me this takes too much time to check. > I have started to David Odin offlist about it further. The mail you send me only shown you're not following the current gfig development as gfig *does* already use a GtkUIManager toolbar. > > [1] The new Gfig is definately is a bit rough around the edges. It has a > lot of potential though. It really should be reverted to the old usuable > ugly but stable version for the 2.2 release. new gfig has some issues and I've tried to list them on this very mailing-list. If you can list more, please list them in the correct thread. and as I already said before, using the 2.0 version of gfig would mean to at least port the old version to the HIG standards, and to update to the new apis. I don't volonteer to do this, but if you can come up with such a beast I will consider to compare both versions. Regards, DindinX -- [EMAIL PROTECTED] A conscience is what hurts when all your other parts feel so good. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Things left to do with gfig.
On Sun, Nov 14, 2004 at 01:29:58PM +0100, Karine Proot wrote:
> David Odin wrote:
> >[...]
> >
> >2 Normal.
> > 2.1 The undo button should be moved to the toolbar.
> > 2.2 The 'select object' tool seems useless, and might be removed.
> > 2.3 Find out how the gradient fill is supposed to work (it is
> > unimplemented for now), or remove it from the filling choice.
> >
> >[...]
> >
> >All the points in 2 are very easy to fix once it has been decided how to
> >fix them.
>
> I'd like to work on them as soon as things are decided.
>
2.1 should really happen. (I would very much appreciate a patch for
this).
2.2 should be fixed the right way, so the selected object can become
the current one (it doesn't seems to work atm). So my point of
view is that the select object tool should stay.
2.3 is only a matter of calling the right function in
gfig-dialog.c:paint_layer_fill() to use a shapeburst gradient fill
since it is the only gradient fill that doesn't need a direction.
Then again, I would appreciate a patch or even a direct commit
since I don't intend to change this function in a near future.
Regards,
DindinX
--
[EMAIL PROTECTED]
i;main(b,v)char**v;{char t1['e'],t2['e'],*p;strcpy(t2,v[1]);while(strlen
(t2)<50){puts(strcpy(t1,t2));for(p=t2;t1[i];p+=2)for(*p=49,p[1]=t1[i];t1
[++i]==p[1];(*p)++);*p=i=0;}}
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Things left to do with gfig.
Hi, As you may know the gfig plug-in was in bad shape, and I've been working on it for a few weeks. Still, there are some issues. I've tried to make a list (ordered by severity): 1 Major. 1.1 deleting an object, by using the delete tool or even undo mess up the current_style variable and can cause a crash on the next object creation. This will be easier to fix when 3.2 and 3.3 will be done. 2 Normal. 2.1 The undo button should be moved to the toolbar. 2.2 The 'select object' tool seems useless, and might be removed. 2.3 Find out how the gradient fill is supposed to work (it is unimplemented for now), or remove it from the filling choice. 3 Cleanups. 3.1 gfig should use glist in some places instead of reimplementing its own structures (DAllObjs, DObjpoints), undos and styles would also benefit to use something else than a static array. 3.2 dobject is used as an abstract class for every kind of objects (arc, line, bezier, etc.) This should be redone using the gobject system. 3.3 the style class should also be derived from a gobject, so it can be easily refcounted. 3.4 use our coding standards all over the place. 4 Tests. As I focus only on some points, I certainly missed some important parts/bugs. For instance, I haven't try to test the saving and loading code. As I said, 1.1 is the major problem for now. Depending on the time we have I would like to have 3.2 and 3.3 fixed before dealings with 1, but it isn't really necessary. All the points in 2 are very easy to fix once it has been decided how to fix them. I'm currently working on 3.1. Any help is of course welcome, but please contact me here or on #gimp before coding anything, to avoid duplicate work. Regards, DindinX -- [EMAIL PROTECTED] You cannot produce a baby in one month by impregnating nine women. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] canvas background options
On Sat, Nov 13, 2004 at 08:51:26PM +, Alan Horkan wrote:
>
> (I really hope Gfig will be rolled back as the developer working on it has
> previously suggested, it is definately not ready for 2.2)
>
Thanks for your help. AFAIK, I'm the only one really working on gfig
for now. It isn't ready for 2.2, but I'm doing my best to achieve
this. If you have the skills to put a fully debugged, easy to read
and fully HIG compliant version of gfig (even a rolled back version, I
don't care), feel free to provide the sources to us. Until I see this
code, I'll go on with debugging and polishing the existing version.
Regards,
DindinX
--
[EMAIL PROTECTED]
i,d,j;main(n,v)char**v;{n=atoi(v[1]);d=atoi(v[2]);{int*r=alloca(5*d+10);char
*q=r+d+2;printf("%d/%d=%d",n,d,n/d);*q=46;*r=n%d;for(;ihttp://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] canvas background options
On Fri, Nov 12, 2004 at 12:48:02PM +, Alan Horkan wrote: > > On Fri, 12 Nov 2004, David Odin wrote: > > > Date: Fri, 12 Nov 2004 01:02:31 +0100 > > From: David Odin <[EMAIL PROTECTED]> > > To: Alan Horkan <[EMAIL PROTECTED]> > > Cc: [EMAIL PROTECTED] > > Subject: Re: [Gimp-developer] canvas background options > > > > On Thu, Nov 11, 2004 at 11:06:21PM +, Alan Horkan wrote: > > > > > > I noticed the Canvas background colour options under the Image menu in the > > > gimp 2.2. > > > > > > In gimp 2.0 this option was fairly discrete and was available on the top > > > right just above the scrollbar which seemed fair enough even if it was > > > not something I would ever change (except perhaps by changing my desktop > > > theme). > > > > > > Is this feature really important to some users, so much so that it needs > > > menu items? I am suggesting it would be better to put this in the > > > preferences if at all rather than cluttering the menus. > > > > > Yes, this feature is important to me at least. It is important to > > have a dark surrounding around a dark image and a light one around a > > light image, so you can judge the contrast better. > > I can understand how that would require you to change it regularly and why > you might want a menu item for it. > How did you like how the feature was presented in 2.0 or were you unaware > of it until it was given a prominant menu item? > I tend to prefer the gimp-2.0 way since it is quicker to use. I don't remember why it has been put to the menu. A "prominant menu item" as it is now also let the user to tear it off and have it handy. So my preference (have it on the upper right corner window) is only a matter of taste I guess. Regards, DindinX -- [EMAIL PROTECTED] Do jellyfish get gas from eating jellybeans? ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] canvas background options
On Thu, Nov 11, 2004 at 11:06:21PM +, Alan Horkan wrote: > > I noticed the Canvas background colour options under the Image menu in the > gimp 2.2. > > In gimp 2.0 this option was fairly discrete and was available on the top > right just above the scrollbar which seemed fair enough even if it was > not something I would ever change (except perhaps by changing my desktop > theme). > > Is this feature really important to some users, so much so that it needs > menu items? I am suggesting it would be better to put this in the > preferences if at all rather than cluttering the menus. > Yes, this feature is important to me at least. It is important to have a dark surrounding around a dark image and a light one around a light image, so you can judge the contrast better. Regards, DindinX -- [EMAIL PROTECTED] If you must choose between two evils, pick the one you've never tried before. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Bugzilla privileges
On Thu, Nov 04, 2004 at 05:25:27PM -0200, Joao S. O. Bueno Calligaris wrote:
> Hi.
>
>
> Through this e-mail I am formally asking the GIMP team to be granted
> with some bugzilla privileges.
>
> I do not know which level of privileges are there, but I'd like to be
> able to mark bugs as duplicates, reset the priority and severity of
> bugs and so on.
>
> I've noticed that I am - in pratice - doing this, but as I do not have
> the privileges, someone else has to show up to do the changes for me
> later on.
>
> So, here is the request for your consideration.
>
> Regards,
>
Given the amount of work you've done lately, I entierly agree you
should be granted with such privileges. I don't know how to give you
this. But at least, you have my blessing :)
Regards,
DindinX
--
[EMAIL PROTECTED]
/B{0 0 moveto l 0 rlineto 0 l rlineto l neg 0 rlineto closepath
fill}def/x{l 0 translate}def/l 500 def 50 100 translate B 1 setgray
/Rep 0 def 2 1 6{/i exch def/l l 3 div def i 2 eq{/Rep 3 def}{/Rep
Rep 3 mul def}ifelse/Par Rep 2 idiv def gsave 1 1 Rep{gsave 2 mod 0 eq{B x}
if Par{x B x}repeat grestore 0 l translate}for grestore}for showpage
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Newsprint
On Fri, Oct 29, 2004 at 04:35:17PM -0200, Joao S. O. Bueno Calligaris wrote:
> Newsprint plug-in is working fine now.
>
> Sorry for not replying you earlier. I just rubilt the GIMPyesterday,
> and I was lost on the broken-plug-ins-with-gcc-3.3 mess.
>
> :-)
You should really upgrade to 3.4, it is much faster and produce much
smaller executables.
>
> However, I still think it is too tall, and that an easy way to get it
> more confortable is a right-placed preview. Do you mind if we talk
> about it on gimp-developer to get more opinions?
>
I would strongly object to have a preview at the right of a dialog.
Most (I would like all, but...) dialogs show the preview at the top.
Some are showing it at the left. So, if it has to be on the side, it
should be the left one. I would much prefer to change the rest of the
interface.
However, the Gimp is a group effort, and of course it is always better
to have more than one opinion. I've CC this to gimp-devel. Can someone
please give us an advice here?
Regards,
DindinX
--
[EMAIL PROTECTED]
/C/neg/d/mul/R/rlineto/E/exp/H{{cvx def}repeat}def/T/dup/g/gt/r/roll/J/ifelse 8
H/A/copy(z&v4QX&93r9AxYQOZomQalxS2w!!O&vMYa43d6r93rMYvx2dca!D&cjSnjSnjjS3o!v&6A
X&55SAxM1CD7AjYxTTd62rmxCnTdSST0g&12wECST!&!J0g&D1!&xM0!J0g!l&544dC2Ac96ra!m&3A
F&&vGoGSnCT0g&wDmlvGoS8wpn6wpS2wTCpS1Sd7ov7Uk7o4Qkdw!&Mvlx1S7oZES3w!J!J!Q&7185d
Z&lx1CS9d9nE4!k&X&MY7!&1!J!x&jdnjdS3odS!N&mmx1C2wEc!G&150Nx4!n&2o!j&43r!U&0777d
]&2AY2A776ddT4oS3oSnMVC00VV0RRR45E42063rNz&v7UX&UOzF!F!J![&44ETCnVn!a&1CDN!Y&0M
V1c&j2AYdjmMdjjd!o&1r!M){( )T 0 4 3 r put T(/)g{T(9)g{cvn}{cvi}J}{($)g{[}{]}J}J
cvx}forall/moveto/p/floor/w/div/S/add 29 H[{[{]setgray fill}for Y}for showpage
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] about the gfig plug-in
Hi, The gfig plug-in has been easily modified between 2.0 and now. I think it is much more usable now than before, but there are some points that must be fixed before we could ship it in a stable release. I've tried to make a list, and I will certainly open a bugreport about this, but I would like you to check if I've forgotten something: - importing a shape doesn't work (nothing happen when choosing the entry) - it isn't fully HIGed (most notably the menus and some popup windows) - it brings some strange error message about brushes sometimes - some drawing options are missing compared to the 2.0 version (the 'draw' tab of the bottom left notebook) - it also segfaults from time to time. I think all of this can be fixed in a short time, but before jumping into the source, I would like to know if someone else is (actively) working on this, and if I've missed some important point. Regards, DindinX -- [EMAIL PROTECTED] I think men who have a pierced ear are better prepared for marriage. They've experienced pain and bought jewelry. - Rita Rudner ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Getting selection mask
On Sat, Oct 02, 2004 at 07:20:03PM -0400, Thierry Pierron wrote: > Hello, > > Can someone explain basic steps to get bitmap of the selection mask of gimp > inside a plugin ? > > I try to play with gimp_image_get_selection(), passing the current image ID, > but it always returns -1. > > Any example available somewhere ? > Have a look at libgimp/gimpdrawablepreview.c, in current CVS, in the function gimp_drawable_preview_draw_area (). This function use the selection and put it into an array of guchar. Examine how the sel variable is filled. Regards, DindinX -- [EMAIL PROTECTED] Everyone has a scheme for getting rich that will not work ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] previewarea and drawablepreview
On Tue, Sep 14, 2004 at 10:23:10PM +0200, geert jordaens wrote: > > why not just using GimpPreviewArea in a frame? : > Well applying a plugin on a 3000*2000 pixel image could take a lot of time. > Making the preview scrollable and applying the effect on the "viewable" > part solves most of the time the performance issues. (and in general i am > very happy with that) This is the current situation with GimpDrawablePreview. > However when applying a effect that should give a general enhancement of > the whole image (like color enhancement) it would be nice to have a larger > scrollable previewarea working on a scaled down version eg. 600*400. > This would be another widget, with zooming facilities. This is planed by Sven and me, but we need to solve some problem in the core before this would happen. In the meantime, you can put a thumbnail in a GimpPreviewArea and resize the area (and such the thumbnail) when the user resize the dialog. Regards, DindinX -- [EMAIL PROTECTED] Why do the signs that say "Slow Children" have a picture of a running child? ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] previewarea and drawablepreview
On Tue, Sep 14, 2004 at 07:42:18PM +0200, geert jordaens wrote:
> hello,
>
> I'm trying to catch up with the changes concerning the preview widget
> Could somebody explain me why the functions
>
> gimp_preview_area_menu_popup
> gimp_preview_area_menu_new
> gimp_preview_area_menu_toggled
>
> are located in gimppreviewarea this way the preview area is not a basic
> replacement for the gtk_preview widget. If i understand the function of
> gimp_drawable_preview then I would place forementioned functions there.
>
Certainly not. The menu is for changing the checker aspect. It is in
no way related to a particular drawable.
> I would like to use the gimp_drawable_preview for a plugin on a scaled down
> version of the drawable (let's say thumbnail).
You'll have to create a new widget derived from GimpPreview to do
this, then. But then, why not just using GimpPreviewArea in a frame?
Regards,
DindinX
--
[EMAIL PROTECTED]
/D{def}def 306 108 translate 57.6 dup scale 1 setlinecap 0.005 setlinewidth
0 0 15 {/r rand 100 mod D r 1 lt {/m[0 0 0 0.16 0 0]D}{r 86 lt{/m[0.85
-0.04 0.04 0.85 0 1.6]D}{r 93 lt{/m[0.2 0.23 -0.26 0.22 0 1.6]D}{/m[-0.15
0.26 0.28 0.24 0 0.44]D}ifelse}ifelse}ifelse m transform 2 copy moveto 0.001
dup rlineto stroke}repeat showpage %(c)DindinX
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP 2.2
On Mon, Sep 06, 2004 at 05:52:20PM +0200, Sven Neumann wrote:
> Hi,
>
> a while ago we decided for a feature freeze for GIMP 2.2 that should
> have taken effect last week. I haven't enforced this feature freeze
> yet because there's been some good hacking going on recently and I
> think we definitely wanted to have these features in 2.2. With the
> 2.1.4 release, we've reached a point where the new stuff
> (GimpProgress, GimpPreview) seems to be rather well working so we
> could declare a feature freeze right now. I do think however that we
> should give us a little bit more time and try to get the following
> done during the next weeks:
>
> - add more plug-in previews
I'm already on this. If someone wants to help, please contact me.
> - try to make the previews scale with the dialog
Just to make it clear, this would just resize the preview widget,
nothing to do with a zoom feature.
> - implement color management as was discussed earlier
> - fix unit handling and resize / scale dialogs
> - allow for better layer positioning / alignment
> - integrate the metadata editor that Raphael is working on
> - finish and fix whatever is unfinished or broken
>
> I would suggest we attempt to get a 2.2 prerelease out by the end of
> this month or early in october. Given the fact that the tree is fairly
> stable, we should then be able to deliver 2.2.0 by the end of october.
>
Sounds reasonable.
DindinX
--
[EMAIL PROTECTED]
main(c){float x,y=2,X,Y,Z,q,t;q=sin(time(0))*1.3;t=sqrt(1.69-q*q);
for(;(x=-2)<(y-=.1);puts(""))for(;Y=y,(X=x+=.05)<2;c=printf("%c",c
[" .-:|O8H#"]))for(;X*X+Y*Y<4&&++c<8;Z=q+X*X-Y*Y,Y=2*X*Y+t,X=Z);}
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Should the checkerboard be linked to the window or to the image?
On Fri, Sep 03, 2004 at 06:42:43PM +0300, Tuomas Kuosmanen wrote: > On Wed, 2004-09-01 at 11:41 +0200, David Odin wrote: > > Imho, the later is nicer, but Sven told me it could make the scrolling > > and panning of the main image window much slower. > > > > > > What to you think? > > Yeah, I think the fixed checker might be nice - but the speed is more > important here, especially with larger images. > Fixed and scrolled checker will draw at the same speed in the previews. Fixed will only be slower in main image window. This doesn't really change the problem here, but I wanted to make this clear. DindinX -- [EMAIL PROTECTED] You have to stay in shape. My grandmother, she started walking five miles a day when she was 60. She's 97 today and we don't know where the hell she is. - Ellen DeGeneris ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Should the checkerboard be linked to the window or to the image?
On Thu, Sep 02, 2004 at 12:36:43PM +0200, Sven Neumann wrote: > Hi, > > Carol Spears <[EMAIL PROTECTED]> writes: > > > the same way you can change the padding color now. i would not have > > been able to imagine such an interface to the previews without all those > > new options for customizing your sessions. all this stuff is sane? > > You might not have noticed that we have started to remove options from > the user interface. However you should be aware of the fact that we > try not to add new options unless there's a very good reason for it. > > Actually the plan was to let the plug-in previews respect the settings > from gimprc that already exist: > > (transparency-size medium-checks) > > Sets the size of the checkerboard used to display transparency. > Possible values are small-checks, medium-checks and large- > checks. > > (transparency-type gray-checks) > > Sets the manner in which transparency is displayed in images. > Possible values are light-checks, gray-checks, dark-checks, > white-only, gray-only and black-only. > How hard would this be to implement? > That would of course mean that the same settings apply to plug-in > previews and to image windows. > Which is the way it should be if we want to be consistant. -- [EMAIL PROTECTED] Friends help you move. Real friends help you move bodies. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Should the checkerboard be linked to the window or to the image?
Hi,
You all know that the gimp is using a checkerboard to show the transparency
of some parts of images. This checkerboard has always been fixed with
repect to the image. That is, if you scroll a zoomed-in image, the
checkerboard is scrolled with the image.
If you have played with the plug-in's previews in the cvs (until today),
you may have noticed that the checkerboard was fixed to the window, and
it didn't move during panning or scrolling. This behaviour has been
fixed in the name of consistency with the image window behaviour.
But I liked the old behaviour (having the checkerboard fixed to the
window) since it really shows that the checkerboard isn't part of the
drawable as soon as you pan or scroll the preview, and such, the
transparency is more obvious.
Anyway we have to be consistent here. So, I would like to know what
you (especially artists) do prefer:
- keep the checkerboard fixed to the drawable for images and previews.
- have the checkerboard fixed to the window for images and previews.
Imho, the later is nicer, but Sven told me it could make the scrolling
and panning of the main image window much slower.
What to you think?
DindinX
--
[EMAIL PROTECTED]
int m,u,e=0;float l,_,I;main() {for(;e<1863; putchar((++e>924&&952>
e?60-m:u) ["\n [EMAIL PROTECTED] ]"])) for(u=_=l=0;(m=e%81)
<80&&I*l+_*_ <6&&25>++u;_=2*l*_+e/81*.09-1,l=I)I=l*l-_*_-2+.035*m;}
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Linux Journal Editors Choice Award
On Sun, Aug 01, 2004 at 08:17:47PM +0200, David Neary wrote: > Hi, > > Alan Horkan wrote: > > The Gimp has won the Linux Journal Editors choice Award for Best > > Graphics software, they seemed particularly pleased by the improved > > EXIF support. > > Cool :) With the OSI award, and the O'Reilly reader's choice > award from last year, it's cool to see us winning awards again. > > It'd be great to see some kind of trophy cabinet section on the site > where we collect our favourite awards. > Yes! And then we could award one of them: award for the best award! -- [EMAIL PROTECTED] If swimming is good for your shape, then why do the whales look the way they do? ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] easy questions
On Wed, Jul 07, 2004 at 10:06:58AM +0200, David Neary wrote: > > Hi Zack, > > Quoting Zack <[EMAIL PROTECTED]>: > > The first is, how intimately is the GIMP tied to GTK+? > > Very. Although the GUI code has been separated out from the internals, the GIMP > depends on GTK+ to a huge extent. It is inextricably linked to glib and gobject too. > > > The second is, I haven't looked at the code at all, but is the GIMP > > multithreaded and/or does it absolutely require a multitasking OS? > > I wouldn't say so. I don't believe there is threading code in the GIMP, but I am > not sure. > You won't be able to use any plugin without a multitasking OS... Regards, DindinX -- [EMAIL PROTECTED] Celibacy is not hereditary ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] [OFFTOPIC] About the Guadec-2004
Hi all,
I just wanted to thanks every one who's came to the Guadec-2004 in
Kristiansand. It really has been a great time meeting you, and I was
kind of proud assisting to our meeting with many of the great names of
the Gimp.
Also I would like to thanks all of you who has been patient enough to
talk to me and my very very bad spoken english.
For those who wasn't there, I've put some random pictures here:
http://dindinx.net/photos/album.php?a=/GUADEC-2004/
Regards,
DindinX
--
[EMAIL PROTECTED]
main(int n,char**a){for(n=0;putchar(a[2][n]?(a[2][n]%32+(**a%2*2-1)*
(a[1][n++%(a[2]-a[1]-1)]%32-1)+25)%26+97:10)-10;);}
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP and the new GTK+ filechooser
On Thu, Mar 11, 2004 at 04:25:47PM +0100, Sven Neumann wrote:
> Hi Dave,
>
> Dave Neary <[EMAIL PROTECTED]> writes:
>
> > We should just say that GTK+ 2.4 is not out yet, and we can't base
> > stable software on an unstable toolkit. Especially since we've been in
> > a pre-release freeze for 3 months.
>
> By the time that GIMP 2.0 is release, GTK+ 2.4 will be released as
> well. We might be able to be release a few days earlier, or it might
> happen the other way around.
>
Agreed, but the filechooser is still under development/testing.
> > > If we do that we will most likely very soon
> > > see binary GIMP2 packages showing up that have these patches included.
> > > Mitch, what do you think? Would that be a problem at all?
> >
> > I doubt that. Especially since the sources we'll provide will only
> > require gtk+ 2.2. The target, I guess, is to have a GIMP based on 2.4
> > around the time where distros start shipping GNOME 2.6. Which will
> > probably be towards the end of the Summer.
>
> Distros will start shipping GNOME 2.6 shortly after it has been
> released and the release schedule for GNOME 2.6 says March 22nd. This
> date will have to be corrected due to the delayed GTK+-2.4 release but
> I think we can expect a GNOME 2.6 release in early April.
>
> Thus, we should face the fact that at least some distros will make
> their GIMP 2.0 packages depend on GTK+-2.4 and ship with these patches
> applied.
>
I don't see a problem with this. As long as the distros maintain their
patches themselves. I don't really know how Mitch's patch works, but
may be it could be included with some #ifdef GTK2_4. This way, we could
release a gimp-2.0.1 with or without support for filechooser.
DindinX
--
[EMAIL PROTECTED]
i;main(b,v)char**v;{char t1['e'],t2['e'],*p;strcpy(t2,v[1]);while(strlen
(t2)<50){puts(strcpy(t1,t2));for(p=t2;t1[i];p+=2)for(*p=49,p[1]=t1[i];t1
[++i]==p[1];(*p)++);*p=i=0;}}
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Pushing the 2.0 release
On Tue, Mar 09, 2004 at 07:46:16PM +0100, David Neary wrote: > Hi Sven, > > Sven Neumann wrote: > > think we can get GIMP into shape for 2.0rc1 until sunday. Since this > > will involve quite some hacking, we should IMO do a 2.0rc1 tarball but > > the idea is that unless there are major problems with this tarball, > > 2.0.0 should be released a few days later. > > This sounds great. Thanks. > Ditto. > > PPS: I would also appreciate if people would not spend their time with > > discussions that are not related to the 2.0 release. These can > > probably wait until 2.0 is out of the door. > > I'll work on the press pack this weekend. As to the other > discussions, I guess that we can talk more about the project's > organisation after 2.0. > Just to avoid duplicate efforts, I guess we should try to tell who is doing an announce and where. I can do the announce on linuxfr (french linux related news site), if nobody object. Who will do on slashdot, and other major news sites? Regards, DindinX -- [EMAIL PROTECTED] Why is the third hand on the watch called a second hand? ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Tentative 2.2 feature list
On Fri, Feb 06, 2004 at 04:51:28PM +0100, Sven Neumann wrote: > Hi, > > David Odin <[EMAIL PROTECTED]> writes: > > > Anyway, this isn't clear in my mind for now. I'll propose a draft > > on this list as soon as I have more valuable thing to show. > > I hope you are aware that there is an implementation already. We were > not happy with the API and some implementation details but it is > definitely worth to at least have a look at it: > > http://refocus.sourceforge.net/preview/gimppreview.html > I wasn't aware of this. I'll have a look. Thanks. DindinX -- [EMAIL PROTECTED] Despite the cost of living, have you noticed how it remains so popular? ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Tentative 2.2 feature list
On Fri, Feb 06, 2004 at 04:02:37PM +0100, Sven Neumann wrote: > Hi, > > David Odin <[EMAIL PROTECTED]> writes: > > > It looks so. While it is true that GtkPreview has been deprecated > > without a replacement widget without a good reason (in my opinion, and > > obviously in Sven's opinion too), GimpOldPreview is much more than only > > a wrapper around GtkPreview. Besides, we (I ?) could do a better job by > > integrating GimpPreview (or whatever its name will be) more with gimp's > > internal. > > Integrating with GIMP's internal? There's no need for such a widget in > the GIMP core (and we have GimpPreview in the core already). What we > are looking for is a preview widget that is especially modeled for the > need of GIMP plug-ins. How would this integrate with internals? I > guess I somehow misunderstood you here. > Sorry. I haven't been clear enough here. GimpPreview as I see it should be able so show exactly the same thing as a Drawable, but with a different scale. For instance, it should be able to show the composited image, with a background layer or whatever. This sort of thing could involve more than just gdkrgb functions, that's why I said this _could_ use more gimp's way of rendering than gtk's. Anyway, this isn't clear in my mind for now. I'll propose a draft on this list as soon as I have more valuable thing to show. Regards, DindinX -- [EMAIL PROTECTED] Laugh alone and the world thinks you're an idiot. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Tentative 2.2 feature list
On Fri, Feb 06, 2004 at 03:45:21PM +0100, Sven Neumann wrote: > Hi, > > David Odin <[EMAIL PROTECTED]> writes: > > > To be more precise, since the GTK+ team has deprecated GtkPreview, > > I would have like to see if the gimp couldn't have its own widget > > for this. I won't promise it will be done on time, though. Let's put > > this on the "maybe included" list. > > GtkPreview is still available, there's nothing that keeps us from > using it. > If needed, yes. > What we are aiming for is a lot more complex than what GtkPreview is > providing. The goal is to have a widget that can zoom and pan. It > should also provide an API that allows to use the same image > processing routines for the preview as are used for the drawable. The > plug-in author shouldn't have to care much about the preview. > Exactly, selection and layers handling should be there two. But please, see my other mail. Regards, DindinX -- [EMAIL PROTECTED] If law school is so hard to get through, how come there are so many lawyers? - Calvin Trillin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Tentative 2.2 feature list
On Fri, Feb 06, 2004 at 01:16:28PM +0100, David Neary wrote: > > Hi, > > Sven Neumann wrote: > >Dave Neary <[EMAIL PROTECTED]> writes: > >>As a matter of interest, why do we not simply take the old GtkPreview > >>code an rename it GimpPreview, put it in libgimpwidgets and use that? > >>Just wondering. > > > >Because the old GtkPreview code is not what we would like to see as a > >GIMP preview widget? It shares a few characters in the name but that's > >about where the similarity ends. > > Ah - I recalled you saying on several occasions that you didn't understand > why GtkPreview had been deprecated, that you thought it was a very good > widget. I must have misunderstood. > It looks so. While it is true that GtkPreview has been deprecated without a replacement widget without a good reason (in my opinion, and obviously in Sven's opinion too), GimpOldPreview is much more than only a wrapper around GtkPreview. Besides, we (I ?) could do a better job by integrating GimpPreview (or whatever its name will be) more with gimp's internal. Regards, DindinX -- [EMAIL PROTECTED] The best way to hold a man is in your arms. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Tentative 2.2 feature list
On Fri, Feb 06, 2004 at 12:38:33PM +0100, David Neary wrote: > > >>5) Preview widget to replace GimpOldPreview > > > >That's a rather large change. If we get someone interested and a > >proposal for an implementation is posted early enough, then it should > >probably go in. > > David Odin has said he would like to do this for 2.2, which is why it's on > the list. > To be more precise, since the GTK+ team has deprecated GtkPreview, I would have like to see if the gimp couldn't have its own widget for this. I won't promise it will be done on time, though. Let's put this on the "maybe included" list. Regards, DindinX -- [EMAIL PROTECTED] The more beautiful the woman is who loves you, the easier it is to leave her with no hard feelings. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: gimpmisc cvs fixes.
On Tue, Jan 13, 2004 at 02:32:50AM -0800, Manish Singh wrote:
> On Tue, Jan 13, 2004 at 10:41:46AM +0100, David Odin wrote:
> >
> > Hi,
> >
> > as you may know, the files libgimp/gimpmisc.[ch] have been split into
> > libgimp/gimppixelfetcher.[ch] and libgimp/gimpregioniterator.[ch]. Can
> > you do the necessary changes to keep cvs history for these files? This
> > is something like copying gimpmisc.c,v and gimpmisc.h,v directly on the
> > CVS server.
>
> Done. In the future, it's smoother to take care of this before you commit
> the new files.
>
Oh. Didn't know this. I'll remember this.
Thanks.
DindinX
--
[EMAIL PROTECTED]
/D{def}def /d{.00017 add D}D /C{2 copy dup mul exch dup mul}D /g 150 string
D /y .29 D 150 150 8[.4 0 0 .4 -45 -90]{/x -1.2 D 0 1 149{x y /n 300 D{/n n
5 sub D C exch sub x add 3 1 roll 2 mul mul y add C add 4 gt n 5 eq or{exit
}if}loop pop pop g exch n put /x x d}for /y y d g}image showpage
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] gimpmisc cvs fixes.
Hi, as you may know, the files libgimp/gimpmisc.[ch] have been split into libgimp/gimppixelfetcher.[ch] and libgimp/gimpregioniterator.[ch]. Can you do the necessary changes to keep cvs history for these files? This is something like copying gimpmisc.c,v and gimpmisc.h,v directly on the CVS server. Thanks, DindinX -- [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] plugindetails plug-in
Hi,
Just to let you know and to avoid duplicate work, I'm currently fixing
the plugindetails plug-in so it won't use the deprecated gtkctree and
gtkclist widgets.
Regards,
DindinX
--
[EMAIL PROTECTED]
c,r;main(){for(--r;38-r;c++){if(c>r){r++;puts("");for(c=39-r;--c;)
printf(" ");}printf(~r&c?" `":" #");}}
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: GIMP Aqua GTK+OSX
On Tue, Dec 23, 2003 at 04:52:41PM -0800, Robin Rowe wrote:
> GIMP on Mac OS X without X11:
>
> http://gtk-osx.sourceforge.net/docs/gimp.html
>
Yeah! Good job. Now, it would be great if you managed to do the same
for gimp-1.3.x. If all the necessary libs were ported too, we could even
consider to include this in the main tree, WDYT?
DindinX
--
[EMAIL PROTECTED]
main(c,r){for(r=0;c=getchar()+1;r=c-33&&c-11?r+r+1+(c
<47):putchar(" etianmsurwdkgohvf-l-pjbxcyzq"[r])*0);}
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: cvs : gimpmiscui.h has gone
On Sun, Dec 14, 2003 at 02:26:03PM +0100, Jean-Luc Coulon (f5ibh) wrote:
> Hi,
>
> I cannot compile the cvs as libgimp/gimpmiscui.h has gone ..
>
> gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I/usr/local/include/glib-2.0
> -I/usr/local/lib/glib-2.0/include -I/usr/include/gtk-2.0 -I/usr/lib/
> gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/pango-1.0 -I/
> usr/include/freetype2 -I/usr/X11R6/include -I/opt/gimp1.3//include -
> DG_LOG_DOMAIN=\"LibGimp\" -DG_DISABLE_DEPRECATED -
> DGDK_PIXBUF_DISABLE_DEPRECATED -DGDK_DISABLE_DEPRECATED -
> DGTK_DISABLE_DEPRECATED -DGDK_MULTIHEAD_SAFE -DGTK_MULTIHEAD_SAFE -g
> -O2 -Wall -MT gimpui.lo -MD -MP -MF .deps/gimpui.Tpo -c gimpui.c -
> fPIC -DPIC -o .libs/gimpui.o
> Dans le fichier inclus à partir de gimpui.c:29:
> gimpui.h:35:32: libgimp/gimpmiscui.h : Aucun fichier ou répertoire de
> ce type
>
Oups! My fault. Raphaël just fixed this in the CVS.
Sorry,
DindinX
--
[EMAIL PROTECTED]
main(c){float t,x,y,b=-2,a=b;for(;b-=a>2?.1/(a=-2):0,b<2;putchar(30+
c),a+=.0503)for(x=y=c=0;++c<90&x*x+y*y<4;y=2*x*y+b,x=t)t=x*x-y*y+a;}
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GIMP at GUADEC
On Tue, Nov 25, 2003 at 09:18:11PM +0100, Sven Neumann wrote: > Hi, > > David Odin <[EMAIL PROTECTED]> writes: > > > The rent for the rooms and the lunch at 12:00 might be paid by some > > presentations made by one of us to the CPE's students. > > That sounds more like breakfast to me ... > It depends where you live. I personnaly take my breakfast at 7:30, a lunch at 12:00 and a diner at 20:00 :-). Cheers, DindinX -- [EMAIL PROTECTED] Do people in Australia call the rest of the world "up over"? ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: GIMP at GUADEC
On Tue, Nov 25, 2003 at 03:20:49PM +0100, David Neary wrote: > Hi all, > > Following up from the mail last week discussing the date and > location of GIMPCon, here's the state of play on the various > possibilities discussed. > I will only respond about the "Lyon" possibility: > snip. > > 2) Lyon: We have been in contact with the university, and are > awaiting a response on what kind of facilities will be available, > and what dates suit them. This is looking pretty promising too. > The local LUG are prepared to help out and play host. > > snip. If the GIMPCon stand in Lyon, there will be at least some rooms, with Internet access (ssh, web, mail, at least), via a switch/hub. Any laptop with a dhcp config could then be connected. The rent for the rooms and the lunch at 12:00 might be paid by some presentations made by one of us to the CPE's students. I still have to discuss this point though. Regards, DindinX -- [EMAIL PROTECTED] Make it idiot proof and someone will make a better idiot. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: About libgimp/gimpmisc* files
On Sun, Nov 23, 2003 at 02:27:31PM -0200, Joao S. O. Bueno wrote: > No vacancy here > > On Sunday 23 November 2003 13:56, David Odin wrote: > > > > > gimpmiscui.h also defines the gimp_plug_in_get_path() function > > which is only used by the FractalExplorer, gfig, and gflare > > plug-ins. This function doesn't look really useful, since it is > > only a wrapper for gimp_gimprc_query(), with some error-checking. I > > would vote to remove it. Anyway, even if we keep it, it should at > > least be moved to libgimp/gimppaths_pdb.c. > > > > gimppaths_pdb.c is related to path (vector) objects. This > gimp_plug_in_get_path seems to relate to filesystem paths. We better > think of somewhere else for it to live. > Oups! Sorry. I should have read the contents of gimppaths_pdb.c :-} Anyway, you get the idea. This function should be moved in a better place or sent to /dev/null. Regards, DindinX -- [EMAIL PROTECTED] Always remember you're unique, just like everyone else. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] About libgimp/gimpmisc* files
Hi, As you may know, one of the "blocker" bug for the future 2.0 release is bugzilla bug #125141: deprecation of gimpmisc/gimpmiscui. Most of the functions of gimpmiscui.h are related to the GimpFixmePreview stuff. This part looks pretty useful to me, and the API is clean enough to be kept imho. The only bad point I see here is that this code use the deprecated widget GtkPreview, but this could be easily fixed by using some GtkDrawingArea/GdkRgb stuff. gimpmiscui.h also defines the gimp_plug_in_get_path() function which is only used by the FractalExplorer, gfig, and gflare plug-ins. This function doesn't look really useful, since it is only a wrapper for gimp_gimprc_query(), with some error-checking. I would vote to remove it. Anyway, even if we keep it, it should at least be moved to libgimp/gimppaths_pdb.c. The last function in gimpmiscui.h is gimp_parameter_settings_new(). It is currently used by many plug-ins to present the parameters in a consistant way. This one looks pretty useful to me, but should be moved to in a more appropriate place, such as libgimpwidgets/gimpwidgets.[ch] All the functions in libgimp/gimpmisc.h are related to regions or pixels fetchers or iterators. I'll investigate more to see if they should be kept, moved in a better place, or removed. In the meantime, if everyone agree, I'll move and document gimp_parameter_settings_new(), and remove gimp_plug_in_get_path(). Regards, DindinX -- [EMAIL PROTECTED] Everyone has a photographic memory. Some just don't have film. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: GimpDialog API change
On Tue, Nov 04, 2003 at 12:28:09PM +0100, Michael Natterer wrote:
> Hi,
>
> As you may know, GimpDialog from libgimpwidgets badly needs an
> API change for GIMP 2.0.
>
> The relevant bugzilla entry:
> http://bugzilla.gnome.org/show_bug.cgi?id=125143
>
> The plan is to just remove our own action_area API and use GtkDialog's
> one, which involves making use of the dialog's "response" signal
> instead of connecting to each button's "clicked".
>
> The old API is just way too complicated and does things nobody
> really needs. The new stuff boils down to one function:
>
> /**
> * gimp_dialog_new:
> * @title:The dialog's title which will be set with
> *gtk_window_set_title().
> * @role: The dialog's @role which will be set with
> *gtk_window_set_role().
> * @parent: The @parent widget of this dialog.
> * @flags:The @flags (see the #GtkDialog documentation).
> * @help_func:The function which will be called if the user presses "F1".
> * @help_id: The help_id which will be passed to @help_func.
> * @...: A %NULL-terminated @va_list destribing the
> *action_area buttons.
> *
> * Creates a new @GimpDialog widget.
> *
> * This function simply packs the action_area arguments passed in "..."
> * into a @va_list variable and passes everything to gimp_dialog_new_valist().
> *
> * For a description of the format of the @va_list describing the
> * action_area buttons see gtk_dialog_new_with_buttons().
> *
> * Returns: A #GimpDialog.
> **/
> GtkWidget *
> gimp_dialog_new (const gchar*title,
> const gchar*role,
> GtkWidget *parent,
> GtkDialogFlags flags,
> GimpHelpFunchelp_func,
> const gchar*help_id,
> ...);
>
>
> Of course there will be a _valist() variant.
>
> I'll start hacking this today but would like to get some ACKs or EEKs
> before I start porting the plug-ins (which have many many GimpDialogs).
>
You have my bless on this. As I've said I can help you converting some
of the plug-ins.
DindinX
--
[EMAIL PROTECTED]
#include
b;main(c,v)char**v;{for(c=0;v[1][c];c++){**v=v[1][c];putchar(islower(**v)?
97+(**v-97*2+v[2][(c-b)%strlen(v[2])])%26:(b++,**v));}putchar(10);}
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: 1.3.x milestone bugs
On Fri, Oct 24, 2003 at 11:46:13AM +0200, Sven Neumann wrote: > Hi, > > David Neary <[EMAIL PROTECTED]> writes: > > > I got a mail from David Odin proposing to work on some of the API > > clean-up (specifically, he proposed addressing the gimp_dialog_new > > () bug) - I asked him to send the same mail to the list. > > Mitch is working on this already and said he will return from his > short vacation with a new GimpDialog API. He's supposed to return > somewhen this weekend. > I guess some of the problems are the allow_shrink, allow_grow, and auto_shrink parameters to gimp_dialog_new() which are tied to the deprecated gtk_window_set_policy() function. I will wait for Mitch before trying anything. Regards, DindinX -- <[EMAIL PROTECTED]> ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: When will we branch CVS gimp-2-0?
On Wed, Oct 01, 2003 at 07:39:58PM +0200, Sven Neumann wrote:
> Hi,
>
> Raphaël Quinet <[EMAIL PROTECTED]> writes:
>
> > I suggest to create that branch immediately after the 1.3.21 release.
> > What do you think?
>
> We create a branch immidiately after 2.0 is released. We don't have
> the resources to handle more branches. If you branch now (or after
> 1.3.21), we will never get a 2.0 release out.
>
I second this. If we create a 2.0 branch too soo, I'm afraid people
will think "ok, this branch is for bugfixes only, let's play with HEAD
instead". This way coders will be much more interested in adding new
features in HEAD than in finding bugs into the 2.0 branch. So please
delay the 2.0 branch until 2.0 is out.
Regards,
DindinX
--
[EMAIL PROTECTED]
float l,I,Q,_,o;int E;main(){I=1.125;while(I>=-1.225){for(l=
-2;l<=1;l+=3/79.0){Q=_=0;for(E=127;Q*Q+_*_<4.0&&--E>32;){o=Q
;Q=Q*Q-_*_+l;_=2*o*_+I;}putchar(E);}putchar(10);I-=9/88.0;}}
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] clone tool segfault.
Hi, Currently in CVS HEAD, selecting the clone tool makes gimp segfault. I don't understand all the issues, but this patch fix the segfault: --- gimpclonetool.c 21 Apr 2002 07:30:53 - 1.90 +++ gimpclonetool.c 24 Apr 2002 19:44:42 - @@ -172,13 +172,13 @@ GIMP_CURSOR_MODIFIER_NONE /* toggle_cursor_modifier */); - clone_core->init_callback = gimp_clone_init_callback; +/* clone_core->init_callback = gimp_clone_init_callback; clone_core->finish_callback= gimp_clone_finish_callback; clone_core->pretrace_callback = gimp_clone_pretrace_callback; clone_core->posttrace_callback = gimp_clone_posttrace_callback; - clone_core->callback_data = clone; + clone_core->callback_data = clone;*/ - paint_tool->core = GIMP_PAINT_CORE (clone_core); + paint_tool->core = g_object_new (GIMP_TYPE_CLONE, NULL); } static void - Can I commit, or is someone else working on this? Regards, DindinX -- [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Curves files
On Thu, Apr 04, 2002 at 10:20:40PM +0200, Guillermo S. Romero / Familia Romero wrote:
> [EMAIL PROTECTED] (2002-04-04 at 1942.21 +0200):
> > I have a question about this limitation: why the Gimp spline curves is
> > limited to 17 entries and the procedure gimp-curves-spline use a 32
> > items array of points?
> > May be it is not the same goal but that is the difference?
>
> Code from the file, it reads 16 pairs:
>
> for (j = 0; j < 17; j++)
> {
> fields = fscanf (f, "%d %d ", &index[i][j], &value[i][j]);
> if (fields != 2)
> {
> g_print ("fields != 2");
> return FALSE;
> }
> }
>
> Umm, hehehe, it reads 16 pairs, x and y values, not 17 (< 17, not <=
> 17). Sorry, my fault. I am still investigating why 16 and not other
> value (could be 256 as amp files, and avoid the x value). Must be
> something about the curve widget, I guess, but today I am a bit
> "obtuse" with my grep and coding skills.
>
More than you think ;-)
from 0 to 16, that's seventeen values!
--
[EMAIL PROTECTED]
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: TODOs for GIMP-1.3
On Tue, Feb 12, 2002 at 03:56:08PM +0100, Sven Neumann wrote: > Hi, > > surely a lot of people want to help with GIMP-1.3 but don't know where > to start. I'd like to point you to some places that list TODOs for > GIMP-1.3. > > First, we have TODO.xml which is in CVS and available online at: > > http://developer.gimp.org/gimp-todo.html > > Then, there's Bugzilla which can be queried for bugs with the > 1.3.x target milestone. That query at the moment gives this > nice list: > > [ ... ] > 51563 "Count colors" option I'm taking that one (using some code from xpm.c) -- [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] cvs gimp segfault in gimp_tool_pop_status
Hi, I've just discovered a segfault bug in the current HEAD CVS gimp. To activate the bug: start gimp, select some rectangle area, use the move tool, bang! Here is the gdb trace: coruscant:/export3/Gimp/gimp$ gdb gimp-1.3 GNU gdb 5.1 Copyright 2001 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-linux"... (gdb) run Starting program: /usr/local/bin/gimp-1.3 using MMX: yes gimp_container_add_handler: key = dirty-0, id = 509 gimp_container_add_handler: key = disconnect-1, id = 699 /usr/local/bin/gimp-1.3: run called extension_plugin_helper /usr/local/bin/gimp-1.3: Could not open module /usr/local/lib/gimp/1.3/plugin-modules/libiwarp.so! /usr/local/bin/gimp-1.3: time for the evil loop gimp_dialog_factory_add_dialog: registering toplevel "gimp:toolbox" gimp_dialog_factory_add_dialog: registering toplevel "gimp:tool-options-dialog" gimp_display_connect: gimage->ref_count before refing: 1 rect_select: 118 x 84 gimp-1.3 (pid:32541): GLib-GObject-WARNING **: invalid cast from (NULL) pointer to `GimpObject' Program received signal SIGSEGV, Segmentation fault. 0x080d4459 in gimp_tool_pop_status (tool=0x82c1c30) at gimptool.c:313 313 gimp_statusbar_pop (statusbar, (gdb) list 308 g_return_if_fail (GIMP_IS_DISPLAY (tool->gdisp)); 309 310 statusbar = 311 GIMP_STATUSBAR (GIMP_DISPLAY_SHELL (tool->gdisp->shell)->statusbar); 312 313 gimp_statusbar_pop (statusbar, 314 GIMP_OBJECT (tool->tool_info)->name); 315 } 316 317 (gdb) print statusbar $1 = (GimpStatusbar *) 0x87a8358 (gdb) print tool->tool_info $2 = (GimpToolInfo *) 0x0 (gdb) Obviously, the segfault comes from there. tool->tool_info is NULL and dereferenced. I guess this is related to the new GimpStatusbar widget Mitch just created. I don't have time to investigate more right now, but if you want more informations, just ask me. Regards, DindinX -- [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] adding a threshold to the magnify tool
On Thu, Dec 27, 2001 at 03:47:50PM +0100, Sven Neumann wrote: > Hi, > > David Odin <[EMAIL PROTECTED]> writes: > > > The following patch add a "threshold" to the magnify tool. > > This threshold is between 1 and 15 (adjustable in the tool option box) > > and default to 5. > > If the user mouse the mouse by less than this threshold, a simple zoom > > (with a scale of 1) is performed, else a window-zoom is performed. > > > > It is usefull if your mouse isn't very accurate, or if your tablet is > > too sensible. > > > > Is it OK to commit, or does anyone object to the inclusion of this > > feature? > > I think it's fine. Go ahead and commit. > Done. -- [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] adding a threshold to the magnify tool
Hi,
The following patch add a "threshold" to the magnify tool.
This threshold is between 1 and 15 (adjustable in the tool option box)
and default to 5.
If the user mouse the mouse by less than this threshold, a simple zoom
(with a scale of 1) is performed, else a window-zoom is performed.
It is usefull if your mouse isn't very accurate, or if your tablet is
too sensible.
Is it OK to commit, or does anyone object to the inclusion of this
feature?
Regards,
DindinX
---
--- gimp/app/tools/gimpmagnifytool.c.orig Mon Dec 24 04:44:54 2001
+++ gimp/app/tools/gimpmagnifytool.cMon Dec 24 04:45:58 2001
@@ -54,6 +54,8 @@
GimpZoomType type;
GimpZoomType type_d;
GtkWidget*type_w[2];
+ gdouble threshold_d;
+ GtkWidget*threshold_w;
};
@@ -270,8 +272,10 @@
width = (win_width * scalesrc) / scaledest;
height = (win_height * scalesrc) / scaledest;
- if (!w || !h)
+ if ( (w < options->threshold_d) || (h < options->threshold_d))
scale = 1;
else
scale = MIN ((width / w), (height / h));
@@ -439,6 +443,7 @@
MagnifyOptions *options;
GtkWidget *vbox;
GtkWidget *frame;
+ GtkWidget *hbox, *label, *abox, *scale;
options = g_new0 (MagnifyOptions, 1);
@@ -448,6 +453,7 @@
options->allow_resize_d = gimprc.resize_windows_on_zoom;
options->type_d = options->type = GIMP_ZOOM_IN;
+ options->threshold_d= 5;
/* the main vbox */
vbox = options->tool_options.main_vbox;
@@ -483,6 +489,32 @@
gtk_box_pack_start (GTK_BOX (vbox), frame, FALSE, FALSE, 0);
gtk_widget_show (frame);
+
+ /* window threshold */
+ hbox = gtk_hbox_new (FALSE, 4);
+ gtk_box_pack_start (GTK_BOX (vbox), hbox, FALSE, FALSE, 0);
+
+ label = gtk_label_new (_("Threshold:"));
+ gtk_misc_set_alignment (GTK_MISC (label), 1.0, 1.0);
+ gtk_box_pack_start( GTK_BOX (hbox), label, FALSE, FALSE, 0);
+ gtk_widget_show (label);
+
+ abox = gtk_alignment_new (0.5, 1.0, 1.0, 0.0);
+ gtk_box_pack_start_defaults (GTK_BOX (hbox), abox);
+ gtk_widget_show (abox);
+
+ options->threshold_w =
+ gtk_adjustment_new (options->threshold_d, 1.0, 15.0, 2.0, 2.0, 0.0);
+ scale = gtk_hscale_new (GTK_ADJUSTMENT (options->threshold_w));
+ gtk_scale_set_digits (GTK_SCALE (scale), 0);
+ gtk_container_add (GTK_CONTAINER (abox), scale);
+ gtk_scale_set_value_pos (GTK_SCALE (scale), GTK_POS_TOP);
+ gtk_range_set_update_policy (GTK_RANGE (scale), GTK_UPDATE_DELAYED);
+ g_signal_connect (G_OBJECT (options->threshold_w), "value_changed",
+G_CALLBACK (gimp_double_adjustment_update),
+&options->threshold_d);
+ gtk_widget_show (scale);
+ gtk_widget_show (hbox);
return (GimpToolOptions *) options;
}
--
[EMAIL PROTECTED]
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Current work
Continuing Dave Neary's thread. My current work on gimp is very small. I'm reading the sources, looking for typos, small bugs or obvious optimisations. i'm also use CVS gimp on a regular basis (my art work isn't very important, so I don't care loosing my datas here) in order to catch bugs. What I intend to work on in the short term is two things that anoy me: - if you move the pointer, even a very little while using the zoom tool, you end up with a 16:1 (or a 1:16) ratio while you only wanted to increase (decrease) the zoom factor by one. I think the amount of pixels the mouse should move to produce window zooming instead of a simple zooming should be user configurable in the zoom-tool-option-dialog-box. This looks like a very easy thing to implement, so if noone disagree, I'll implement this asap. - There's a report in bugzilla about the need for a better interface for graphic tablet, namely to allow the edition of the pression curve. I wish to work on this too (when I'll get my tablet back...) Best regards, DindinX -- [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: gimp HEAD and glib from CVS
On Tue, Oct 02, 2001 at 07:34:27PM +0200, Sven Neumann wrote: > Hi, > > we have tried to keep the CVS version of GIMP compileable with the > latest releases of GTK+ and friends as well as with the current state > of these modules in CVS. The latest (small) changes in glib break > source compatibility and since the glib version number has not yet > been incremented, I don't see a way to conditionalize the code so > that it works with both versions of glib. As a first solution, I'm > posting a patch here for the people among you that follow CVS > development of glib, pango, atk and gtk+. I'd like to know how many > of you would prefer to have this changes applied to the gimp CVS > tree now and how many would prefer us to stay source compatible with > the latest glib, pango, atk and gtk+ development releases. > To me, it looks like until the release of the first 2.0 version of GTK+, it would be more logical to sync CVS gimp with CVS glib-atk-pango-gtk+. So, please apply. Anyhow, the GTK+ API should be frozen real soon now, no ? -- [EMAIL PROTECTED] Linux - Why use Windows, since there is a door? ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Fix for the mail plugin [was Re: Fix for the gif plugin.]
On Sun, Sep 09, 2001 at 08:09:19PM +0200, Sven Neumann wrote:
> Hi,
>
> David Odin <[EMAIL PROTECTED]> writes:
>
> > OK. I've attached a similar patch for the gif plugin. It does
> > basically the same thing as my patch for the jpeg plugin (replacing a
> > GtkText by a GtkTextView/GtkTextBuffer couple).
> >
> > I've two question about this plugin:
> >- why gifload and gif are kept separated, when, for most image
> > formats, the loader and the saver is in the same plugin?
> >- the code of gif.c looks unmaintained, and rather dirty (lots of
> > code commented out, define for "FACEHUGGERS", no real copyright
> > notice, etc.) Who is the current maintainer?
>
> as stated in PLUGIN_MAINTAINERS Adam D. Moss <[EMAIL PROTECTED]> maintains
> the gif plug-ins. He should be able to tell you why he chose two
> separate plug-ins (licensing?!). Oh, and yes, Adam has this very special
> british humour that makes his code fun to read...
>
Yes, Adam's code is fun to read. I particulary appreciated the joke
about the Facehuggers, since I'm a big fan of the Alien tetralogy. But
what about the commented out code? I really think the gif.c file need a
little clean up. What to you think, Adam?
Anyway, you'll find a fix for the mail-plugin attached to this mail.
This fix restore the mail plugin to the state it was in the 1.2 release.
Nevertheless, I think it could be improved in some ways. For instance,
the mime type is deduced from the filename the user has to write. May be
we should provide a list of supported format in an optionmenu. I'll see
how this could be implemented.
A part from this, I've noticed that the plugindetail and nlfilt are
still commented out in plugin-defs.pl.
I don't know what nlfilt is supposed to do, but the UI seems to work
ok, and plugindetail works as it is supposed to work.
Why are these two plugin disabled?
Regards,
DindinX
--
[EMAIL PROTECTED]
Today is the tomorrow you worried about yesterday.
--- gimp/plug-ins/common/mail.c.origTue Sep 11 22:48:03 2001
+++ gimp/plug-ins/common/mail.c Tue Sep 11 23:14:51 2001
@@ -140,12 +140,12 @@
gint32 run_mode);
static gint save_dialog (void);
-static void ok_callback (GtkWidget *widget,
- gpointer data);
-static void mail_entry_callback (GtkWidget *widget,
- gpointer data);
-static void mesg_body_callback (GtkWidget *widget,
- gpointer data);
+static void ok_callback (GtkWidget *widget,
+ gpointer data);
+static void mail_entry_callback (GtkWidget *widget,
+ gpointer data);
+static void mesg_body_callback (GtkTextBuffer *buffer,
+ gpointer data);
static gint valid_file (gchar *filename);
static void create_headers (FILE *mailpipe);
@@ -189,7 +189,7 @@
if you prefer that as the default */
};
-static gchar * mesg_body = "\0";
+static gchar * mesg_body = NULL;
static gintrun_flag = 0;
MAIN ()
@@ -436,14 +436,14 @@
static gint
save_dialog (void)
{
- GtkWidget *dlg;
- GtkWidget *entry;
- GtkWidget *table;
- GtkWidget *table2;
- GtkWidget *label;
- GtkWidget *vbox;
- GtkWidget *text;
- GtkWidget *vscrollbar;
+ GtkWidget *dlg;
+ GtkWidget *entry;
+ GtkWidget *table;
+ GtkWidget *label;
+ GtkWidget *vbox;
+ GtkWidget *scrolled_window;
+ GtkWidget *text_view;
+ GtkTextBuffer *text_buffer;
gchar buffer[BUFFER_SIZE];
gchar *gump_from;
@@ -545,34 +545,30 @@
&mail_info.filename);
/* comment */
- table2 = gtk_table_new (2, 2, FALSE);
- gtk_table_set_row_spacing (GTK_TABLE (table2), 0, 2);
- gtk_table_set_col_spacing (GTK_TABLE (table2), 0, 2);
-
- gtk_table_attach (GTK_TABLE (table), table2,
- 0, 2, 5, 6,
- GTK_EXPAND | GTK_FILL,
- GTK_EXPAND | GTK_FILL,
- 0, 0);
-
- text = gtk_text_new (NULL, NULL);
- gtk_text_set_editable (GTK_TEXT (text), TRUE);
- gtk_table_attach (GTK_TABLE (table2), text,
- 0, 1, 0, 1,
- GTK_EXPAND | GTK_FILL,
- GTK_EXPAND | GTK_FILL,
- 0, 0);
- gtk_widget_set_usize (text, 200, 100);
- gtk_widget_show (text);
- gtk_signal_connect (GTK_OBJECT (text), "changed",
- GTK_SIGNAL_FUNC (mesg_body_callback),
- mesg_body);
- gtk_widget_show (table2);
-
- vscrollbar = gtk_vscrollbar_new (GTK_TEXT (text)->vadj);
- gtk_tab
[Gimp-developer] Fix for the gif plugin.
On Tue, Sep 04, 2001 at 03:41:14PM +0200, Michael Natterer wrote:
> David Odin <[EMAIL PROTECTED]> writes:
>
> > Hi,
> >
> > I've attached a patch that allow the compilation (and installation) of
> > the jpeg plugin. It uses a GtkTextView/GtkTextBuffer couple instead of
> > the deprecated GtkText for the image comment.
> >
> > Well, to use this patch, you'll also have to remove the '#' in front
> > of the jpeg plugin definition in plugin-defs.pl, and re-run mkgen.pl.
> >
> > The patch works OK. I've tested it, and I'm happy to see this plugin
> > back :-).
> >
> > Please apply.
>
> Done.
>
Thanks.
> PS: please attach patches unzipped so we can read them in the mail client ;)
OK. I've attached a similar patch for the gif plugin. It does
basically the same thing as my patch for the jpeg plugin (replacing a
GtkText by a GtkTextView/GtkTextBuffer couple).
I've two question about this plugin:
- why gifload and gif are kept separated, when, for most image
formats, the loader and the saver is in the same plugin?
- the code of gif.c looks unmaintained, and rather dirty (lots of
code commented out, define for "FACEHUGGERS", no real copyright
notice, etc.) Who is the current maintainer?
Thanks,
DindinX
--
[EMAIL PROTECTED]
Paranoid schizophrenics outnumber their enemies at least two to one.
--- gimp/plug-ins/common/gif.c.orig Sat Sep 8 02:01:01 2001
+++ gimp/plug-ins/common/gif.c Sat Sep 8 18:17:13 2001
@@ -314,28 +314,27 @@
/* Declare some local functions.
*/
static void query(void);
-static void run (gchar *name,
- gintnparams,
- GimpParam *param,
- gint *nreturn_vals,
- GimpParam **return_vals);
-static gint save_image (gchar *filename,
- gint32 image_ID,
- gint32 drawable_ID,
- gint32 orig_image_ID);
+static void run (gchar *name,
+ gintnparams,
+ GimpParam *param,
+ gint *nreturn_vals,
+ GimpParam **return_vals);
+static gint save_image (gchar *filename,
+ gint32 image_ID,
+ gint32 drawable_ID,
+ gint32 orig_image_ID);
-static gboolean boundscheck(gint32 image_ID);
+static gboolean boundscheck(gint32 image_ID);
static gboolean badbounds_dialog (void);
-static void cropok_callback (GtkWidget *widget,
- gpointerdata);
+static void cropok_callback (GtkWidget *widget,
+ gpointerdata);
-static gint save_dialog (gint32 image_ID);
+static gint save_dialog (gint32 image_ID);
-static void save_ok_callback (GtkWidget *widget,
- gpointerdata);
-static void comment_entry_callback (GtkWidget *widget,
- gpointerdata);
+static void save_ok_callback (GtkWidget *widget,
+ gpointerdata);
+static void comment_entry_callback (GtkTextBuffer *buffer);
static gboolean comment_was_edited = FALSE;
@@ -1198,21 +1197,21 @@
static gint
save_dialog (gint32 image_ID)
{
- GtkWidget *dlg;
- GtkWidget *main_vbox;
- GtkWidget *toggle;
- GtkWidget *label;
- GtkWidget *spinbutton;
- GtkObject *adj;
- GtkWidget *text;
- GtkWidget *frame;
- GtkWidget *vbox;
- GtkWidget *hbox;
- GtkWidget *disposal_option_menu;
- GtkWidget *com_table;
- GtkWidget *vscrollbar;
+ GtkWidget *dlg;
+ GtkWidget *main_vbox;
+ GtkWidget *toggle;
+ GtkWidget *label;
+ GtkWidget *spinbutton;
+ GtkObject *adj;
+ GtkWidget *text_view;
+ GtkTextBuffer *text_buffer;
+ GtkWidget *frame;
+ GtkWidget *vbox;
+ GtkWidget *hbox;
+ GtkWidget *disposal_option_menu;
+ GtkWidget *scrolled_window;
#ifdef FACEHUGGERS
- GimpParasite* GIF2_CMNT;
+ GimpParasite *GIF2_CMNT;
#endif
gint32 nlayers;
@@ -1268,16 +1267,24 @@
gtk_toggle_button_set_active (GTK_TOGGLE_BUTTON (toggle), gsvals.save_comment);
gtk_widget_show (toggle);
- com_tab
[Gimp-developer] Patch to fix the jpeg plugin compilation
Hi, I've attached a patch that allow the compilation (and installation) of the jpeg plugin. It uses a GtkTextView/GtkTextBuffer couple instead of the deprecated GtkText for the image comment. Well, to use this patch, you'll also have to remove the '#' in front of the jpeg plugin definition in plugin-defs.pl, and re-run mkgen.pl. The patch works OK. I've tested it, and I'm happy to see this plugin back :-). Please apply. Now that I know how to do this, and if my patch is good enough, I could fix the other plugins if you want to. Just tell me. Regards, DindinX -- [EMAIL PROTECTED] patch-jpeg-plugin.bz2
[Gimp-developer] patch for gimp/po/fr.po
Hi, You'll find a patch for the gimp/po/fr.po file attached to this mail. I hope this is the right list for this. Regards, DindinX -- [EMAIL PROTECTED] For a light heart lives long. -- Shakespeare, "Love's Labour's Lost" --- gimp/po/fr.po.orig Wed Aug 29 04:41:06 2001 +++ gimp/po/fr.po Wed Aug 29 05:13:09 2001 @@ -80,14 +80,14 @@ msgstr "Fermer" #: app/devices.c:1058 -#, fuzzy, c-format +#, c-format msgid "Foreground: %d, %d, %d" -msgstr "Avant-Plan" +msgstr "Avant-Plan : %d, %d, %d" #: app/devices.c:1072 -#, fuzzy, c-format +#, c-format msgid "Background: %d, %d, %d" -msgstr "Fond" +msgstr "Fond : %d, %d, %d" #: app/disp_callbacks.c:854 app/global_edit.c:323 app/global_edit.c:329 #: app/global_edit.c:403 @@ -573,13 +573,13 @@ msgstr "%.1f Mo" #: app/main.c:298 -#, fuzzy, c-format +#, c-format msgid "" "\n" "Invalid option \"%s\"\n" msgstr "" "\n" -"Option invalide.\n" +"Option invalide « %s ».\n" #: app/main.c:314 msgid "GIMP version" @@ -726,17 +726,17 @@ #: app/module_db.c:621 #, c-format msgid "load module: \"%s\"\n" -msgstr "charger module: \"%s\"\n" +msgstr "charger module: « %s »\n" #: app/module_db.c:628 #, c-format msgid "skipping module: \"%s\"\n" -msgstr "module ignoré: \"%s\"\n" +msgstr "module ignoré: « %s »\n" #: app/module_db.c:654 #, c-format msgid "module load error: %s: %s" -msgstr "erreur de chargement du module: %s: %s" +msgstr "erreur de chargement du module: %s : %s" #: app/module_db.c:841 msgid "" @@ -815,12 +815,12 @@ #: app/plug_in.c:363 #, c-format msgid "query plug-in: \"%s\"\n" -msgstr "interrogation du greffon : \"%s\"\n" +msgstr "interrogation du greffon : « %s »\n" #: app/plug_in.c:401 #, c-format msgid "writing \"%s\"\n" -msgstr "écriture \"%s\"\n" +msgstr "écriture « %s »\n" #: app/plug_in.c:416 msgid "Starting extensions: " @@ -833,7 +833,7 @@ #: app/plug_in.c:862 #, c-format msgid "Unable to locate Plug-In: \"%s\"" -msgstr "Impossible de trouver le greffon : \"%s\"" +msgstr "Impossible de trouver le greffon : « %s »" #: app/plug_in.c:1489 #, c-format @@ -845,7 +845,7 @@ "You may want to save your images and restart GIMP\n" "to be on the safe side." msgstr "" -"Le greffon a planté : \"%s\"\n" +"Le greffon a planté : « %s »\n" "(%s)\n" "\n" "Le greffon a peut être corrompu l'état interne de GIMP.\n" @@ -853,9 +853,8 @@ "pour être sur de sa stabilité." #: app/qmask.c:283 -#, fuzzy msgid "Edit Qmask Color" -msgstr "Éditer les attributs du masque rapide" +msgstr "Éditer la couleur du masque rapide" #: app/qmask.c:290 msgid "Edit Qmask Attributes" @@ -1641,7 +1640,7 @@ #: app/user_install.c:875 msgid "Click \"Continue\" to start The GIMP." -msgstr "Cliquez sur \"Continuer\" pour démarrer GIMP." +msgstr "Cliquez sur « Continuer » pour démarrer GIMP." #: app/user_install.c:878 msgid "" @@ -1686,7 +1685,7 @@ #: app/user_install.c:1077 msgid "Click \"Continue\" to complete GIMP installation." -msgstr "Cliquez sur \"Continuer\" pour compléter l'installation de GIMP." +msgstr "Cliquez sur « Continuer » pour compléter l'installation de GIMP." #: app/user_install.c:1082 msgid "Installation failed. Contact system administrator." @@ -1766,7 +1765,7 @@ "You can also press the \"Calibrate\" button to open a window\n" "which lets you determine your monitor resolution interactively." msgstr "" -"Vous pouvez aussi presser le bouton \"Calibrer\" pour ouvrir\n" +"Vous pouvez aussi presser le bouton « Calibrer » pour ouvrir\n" "une fenêtre qui vous laissera déterminer la résolution de votre\n" "moniteur interactivement." @@ -1782,7 +1781,7 @@ #: app/gui/paths-dialog.c:1978 app/xcf.c:444 #, c-format msgid "open failed on %s: %s\n" -msgstr "échec de l'ouverture de %s: %s\n" +msgstr "échec de l'ouverture de %s : %s\n" #: app/xcf.c:1859 msgid "" @@ -1795,14 +1794,14 @@ "les palettes des images indexées." #: app/core/gimpbrush.c:416 -#, fuzzy, c-format +#, c-format msgid "Unknown brush format version #%d in \"%s\"." -msgstr "Format de pinceau inconnu #%d dans \"%s\"\n" +msgstr "Format de pinceau inconnu version n°%d dans « %s »\n" #: app/core/gimpbrush.c:436 -#, fuzzy, c-format +#, c-format msgid "Error in GIMP brush file \"%s\"." -msgstr "Erreur dans le fichier de motifs de GIMP \"%s\"" +msgstr "Erreur dans le fichier de pinceau de GIMP « %s »" #: app/core/gimpbrush.c:443 app/core/gimppattern.c:313 #: app/gui/palette-import-dialog.c:570 @@ -1810,23 +1809,25 @@ msgstr "SansNom" #: app/core/gimpbrush.c:456 app/core/gimpbrush.c:475 -#, fuzzy, c-format +#, c-format msgid "GIMP brush file appears to be truncated: \"%s\"." -msgstr "Le fichier de pinceaux GIMP semble avoir été tronqué." +msgstr "Le fichier de pinceaux GIMP semble avoir été tronqué : « %s »." #: app/core/gimpbrushpipe.c:296 -#, fuzzy, c-format +#, c-format msgid "" "Brush pipes should have at least one brush:\n" "\"%s\"" -msgstr "Les pinceaux animés doivent con
[Gimp-developer] Re: current gimp status and a patch for apply_lens.
On Mon, Aug 27, 2001 at 11:42:20AM +0200, Michael Natterer wrote: > David Odin <[EMAIL PROTECTED]> writes: > > > On Sun, Aug 26, 2001 at 08:38:57PM +0200, David Odin wrote: > > > > > >Hi, > > > > > > I'm using current HEAD cvs of the Gimp. > > > I've seen that all the filter plugins which use a GTK interface are > > > crashing. Is this a known bug and is this due to the switch to the > > > version 2.0 of gtk+? Is there anything I can do to help fixing this? > > > > > > I've notice that plugins use gtk_signal* fonctions while the gimp > > > application (under the app directory) use g_signal* ones. This lets me > > > think the plugins are not yet converted to use gtk+-2.0. > > > > > > If you can tell me what need to be changed for the migration, I'll be > > > happy to fix all these plugins. > > > > > To be more precise, here are the plugins I've seen crashed on > > invocation : > > - destripe, > > - NL filter, > > - gflare, > > - gimpressionist, > > - gfig, > > - gdyntext, > > - imagemap, > > - jpeg. > > Hi David, > > all the plug-ins you mention are currently excluded from CVS HEAD build > because we didn't get around fixing them (mostly GtkText -> GtkTextView > migration needed). Seems you have old 1.2 plug-in binaries hanging around > which badly crash... > Oops! You are right (Sven also is right). In fact, these were old 1.3 plugins (from the early stage of the 1.3 branch...) > > The ongoing presence of gtk_signal_foo() stuff in the plug-ins is > however perfectly ok, since gtk 2.0 offers wrappers around the new > GLib signal stuff. We will do some kind of perl mass processing of > the plug-ins at some point to remove this Gtk 1.2 compat cruft. > Ok. So we should let perl do this stuff. > Any yes, patches to make them compile again are welcome :-) > Well, at least to make the jpeg plugins to compile (and works!) again, I just had to remove the '#' in front of its definition in plugin-defs.pl. Did I miss something important? Regards, DindinX -- [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: current gimp status and a patch for apply_lens.
On Sun, Aug 26, 2001 at 08:38:57PM +0200, David Odin wrote: > >Hi, > > I'm using current HEAD cvs of the Gimp. > I've seen that all the filter plugins which use a GTK interface are > crashing. Is this a known bug and is this due to the switch to the > version 2.0 of gtk+? Is there anything I can do to help fixing this? > > I've notice that plugins use gtk_signal* fonctions while the gimp > application (under the app directory) use g_signal* ones. This lets me > think the plugins are not yet converted to use gtk+-2.0. > > If you can tell me what need to be changed for the migration, I'll be > happy to fix all these plugins. > To be more precise, here are the plugins I've seen crashed on invocation : - destripe, - NL filter, - gflare, - gimpressionist, - gfig, - gdyntext, - imagemap, - jpeg. -- [EMAIL PROTECTED] Applause, n: The echo of a platitude from the mouth of a fool. -- Ambrose Bierce ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] current gimp status and a patch for apply_lens.
Hi,
I'm using current HEAD cvs of the Gimp.
I've seen that all the filter plugins which use a GTK interface are
crashing. Is this a known bug and is this due to the switch to the
version 2.0 of gtk+? Is there anything I can do to help fixing this?
I've notice that plugins use gtk_signal* fonctions while the gimp
application (under the app directory) use g_signal* ones. This lets me
think the plugins are not yet converted to use gtk+-2.0.
If you can tell me what need to be changed for the migration, I'll be
happy to fix all these plugins.
Apart from this, you'll find a patch for the apply_lens plugins which
improve a little bit its speed attached to this mail. I'm pretty sure
this could be even more optimized.
Regards,
DindinX
--
[EMAIL PROTECTED]
Fishbowl, n.:
A glass-enclosed isolation cell where newly promoted managers are
kept for observation.
--- apply_lens.c.orig Sun Aug 26 19:25:22 2001
+++ apply_lens.cSun Aug 26 19:37:27 2001
@@ -210,25 +210,22 @@
Ellipsoid formula: x^2/a^2 + y^2/b^2 + z^2/c^2 = 1
*/
static void
-find_projected_pos (gfloat a,
- gfloat b,
+find_projected_pos (gfloat a2,
+ gfloat b2,
+gfloat c2,
gfloat x,
gfloat y,
gfloat *projx,
gfloat *projy)
{
- gfloat c;
gfloat n[3];
gfloat nxangle, nyangle, theta1, theta2;
gfloat ri1 = 1.0;
gfloat ri2 = lvals.refraction;
- /* PARAM */
- c = MIN (a, b);
-
n[0] = x;
n[1] = y;
- n[2] = sqrt ((1 - x * x / (a * a) - y * y / (b * b)) * (c * c));
+ n[2] = sqrt ((1 - x * x / a2 - y * y / b2) * c2);
nxangle = acos (n[0] / sqrt(n[0] * n[0] + n[2] * n[2]));
theta1 = G_PI / 2 - nxangle;
@@ -255,7 +252,7 @@
guchar *src, *dest;
gint i, col;
gfloat regionwidth, regionheight, dx, dy, xsqr, ysqr;
- gfloat a, b, asqr, bsqr, x, y;
+ gfloat a, b, c, asqr, bsqr, csqr, x, y;
glongpixelpos, pos;
GimpRGB background;
guchar bgr_red, bgr_blue, bgr_green;
@@ -271,8 +268,11 @@
regionheight = y2 - y1;
b = regionheight / 2;
+ c = MIN (a, b);
+
asqr = a * a;
bsqr = b * b;
+ csqr = c * c;
width = drawable->width;
height = drawable->height;
@@ -296,7 +296,7 @@
ysqr = dy * dy;
if (ysqr < (bsqr - (bsqr * xsqr) / asqr))
{
- find_projected_pos (a, b, dx, dy, &x, &y);
+ find_projected_pos (asqr, bsqr, csqr, dx, dy, &x, &y);
y = -y;
pos = ((gint) (y + b) * regionwidth + (gint) (x + a)) * bytes;
[Gimp-developer] typo in a comment for in the bzip2 plugin.
Hi,
A very small an unimportant patch, to correct a typo in a comment in
the bzip2 plugins (too much cut & paste?):
--- gimp/plug-ins/common/bz2.c.orig Wed Aug 22 00:47:18 2001
+++ gimp/plug-ins/common/bz2.c Wed Aug 22 00:48:49 2001
@@ -362,7 +362,7 @@
tmpname = gimp_temp_name (ext + 1);
#ifndef __EMX__
- /* fork off a g(un)zip and wait for it */
+ /* fork off a bzip2 process and wait for it */
if ((pid = fork ()) < 0)
{
g_message ("bz2: fork failed: %s\n", g_strerror (errno));
Regards,
DindinX
--
[EMAIL PROTECTED]
Honesty's the best policy.
-- Miguel de Cervantes
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] [Patch] some more gint->gboolean changes.
Hi, I've sent this before, but the gimp's source tree changes too fast... This patch basically fix some function prototype which are said to return gint when they really return gboolean. I know this is not that important, but imho, gimp's sources look better with this patch ;-). Please apply. DindinX P.S: Sven, this is an adaptation of the previous patch I sent you. I'm sorry, I've lost your answer during a mutt crash :-( -- [EMAIL PROTECTED] Premature optimization is the root of all evil. -- D.E. Knuth gboolean.patch.bz2
[Gimp-developer] some gint -> gboolean fixes.
Hi, I was looking in the gimp sources, and noticed some mixes between gint and gboolean. Here is a patch witch fixes all those I found. Regards, DindinX -- [EMAIL PROTECTED] recursive : adj, see recursive gboolean.patch.bz2
[Gimp-developer] A typo in preferences_dialog.c
Hi,
By lurking into the gimp sources, I've noticed a small typo in
app/preferences_dialog.c (today's cvs)
Here is a patch fixing this:
-8<--
--- gimp/app/preferences_dialog.c.orig Sat Mar 3 03:04:42 2001
+++ gimp/app/preferences_dialog.c Sat Mar 3 03:05:11 2001
@@ -684,7 +684,7 @@
if (trust_dirty_flag != old_trust_dirty_flag)
{
update = g_list_append (update, "trust-dirty-flag");
- remove = g_list_append (update, "dont-trust-dirty-flag");
+ remove = g_list_append (remove, "dont-trust-dirty-flag");
}
if (use_help != old_use_help)
{
->8--
Regards,
DindinX
--
[EMAIL PROTECTED]
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] STUB
On Sat, Feb 24, 2001 at 08:45:58PM +0100, Michael Natterer wrote: > David Odin <[EMAIL PROTECTED]> writes: > > > Hi, > > > > I'm trying to compile and run the current cvs gimp. I know I have to > > expect to bug here or there, but I've seen quite a strange thing: > > When I run the gimp, it always segfault with this backtrace: > > > > #0 g_on_error_stack_trace (prg_name=0xbb78 "lt-gimp") at gerror.c:176 > > #1 0x4002a59c in g_on_error_query (prg_name=0xbb78 "lt-gimp") > > #2 0x808d57e in gimp_fatal_error (fmt=0x402d2dc0 "Segmentation fault") > > #3 0x80d9bac in gimp_sigfatal_handler (sig_num=11) at main.c:476 > > #4 > > #5 0x400fc0db in gtk_notebook_update_labels (notebook=0x8588f68) > > #6 0x400feabe in gtk_notebook_insert_page_menu (notebook=0x8588f68, > > #7 0x400fe8a5 in gtk_notebook_append_page (notebook=0x8588f68, child=0x0, > > #8 0x80d78b6 in lc_dialog_create (gimage=0x0) at lc_dialog.c:212 > > #9 0x807da7a in dialogs_lc_cmd_callback (widget=0xb970, > > #10 0x80f6a19 in session_open_dialog (info=0x8199038) at session.c:333 > > #11 0x4002dad5 in g_list_foreach (list=0x81f6134, > > #12 0x80f695e in session_restore () at session.c:305 > > #13 0x806a99c in app_init () at app_procs.c:675 > > #14 0x80699e0 in gimp_init (gimp_argc=0, gimp_argv=0xba68) > > #15 0x80d9b04 in init () at main.c:442 > > #16 0x80fcf72 in user_install_verify (user_install_callback=0x80d9af0 ) > > #17 0x80d9acb in main (argc=1, argv=0xba64) at main.c:408 > > > > The segfault is ovbiously caused by the call to > > gtk_notebook_append_page() (in frame 8) with NULL as a second parameter. > > > > After further investigation, it happens that this second parameter is > > the return value of the paths_dialog_create() function. > > > > Unfortunately, this function as been temporary replace by a "STUB" > > function (in tools/tool.c) which always return NULL. > > > > So the segfault is almost done on purpose. Is there a workaround so I > > can still launch the gimp and do further testing? Am I missing something > > obvious? Is there a way to compile the current gimp so one can at least > > see the toolbox and/or an edited picture? > > Hi David, > > you need to install glib and gtk+ with debugging enabled. Ohterwise > all g_return_if_fail() macros expand to nothing and gtk+ simply crashes > instead of spitting out warnings and then returning from the function. > > The warning you should get instead of crashing is: > > Gtk-CRITICAL **: file gtknotebook.c: line 3601 (gtk_notebook_insert_page_menu): >assertion `child != NULL' failed. > Silly me! I've been doing this many times a few months ago. Thanks. It works better now ;-) DindinX -- [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] STUB
Hi, I'm trying to compile and run the current cvs gimp. I know I have to expect to bug here or there, but I've seen quite a strange thing: When I run the gimp, it always segfault with this backtrace: #0 g_on_error_stack_trace (prg_name=0xbb78 "lt-gimp") at gerror.c:176 #1 0x4002a59c in g_on_error_query (prg_name=0xbb78 "lt-gimp") #2 0x808d57e in gimp_fatal_error (fmt=0x402d2dc0 "Segmentation fault") #3 0x80d9bac in gimp_sigfatal_handler (sig_num=11) at main.c:476 #4 #5 0x400fc0db in gtk_notebook_update_labels (notebook=0x8588f68) #6 0x400feabe in gtk_notebook_insert_page_menu (notebook=0x8588f68, #7 0x400fe8a5 in gtk_notebook_append_page (notebook=0x8588f68, child=0x0, #8 0x80d78b6 in lc_dialog_create (gimage=0x0) at lc_dialog.c:212 #9 0x807da7a in dialogs_lc_cmd_callback (widget=0xb970, #10 0x80f6a19 in session_open_dialog (info=0x8199038) at session.c:333 #11 0x4002dad5 in g_list_foreach (list=0x81f6134, #12 0x80f695e in session_restore () at session.c:305 #13 0x806a99c in app_init () at app_procs.c:675 #14 0x80699e0 in gimp_init (gimp_argc=0, gimp_argv=0xba68) #15 0x80d9b04 in init () at main.c:442 #16 0x80fcf72 in user_install_verify (user_install_callback=0x80d9af0 ) #17 0x80d9acb in main (argc=1, argv=0xba64) at main.c:408 The segfault is ovbiously caused by the call to gtk_notebook_append_page() (in frame 8) with NULL as a second parameter. After further investigation, it happens that this second parameter is the return value of the paths_dialog_create() function. Unfortunately, this function as been temporary replace by a "STUB" function (in tools/tool.c) which always return NULL. So the segfault is almost done on purpose. Is there a workaround so I can still launch the gimp and do further testing? Am I missing something obvious? Is there a way to compile the current gimp so one can at least see the toolbox and/or an edited picture? I know the current cvs gimp is not for a daily use. I just want to help. Thanks, DindinX -- [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
