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 -- da...@dindinx.net ___ 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: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. -- da...@dindinx.net ___ 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. -- da...@dindinx.net ___ 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 BW 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 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] [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] 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
[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(i3)return;L=atoi(v[1]);l=atoi(v[2]);T=
alloca(4*L*l);while(nL*l){for(i=D[d];i(d1?l:L)-D[d^2];i++)T[!d?i+L*D[1]:d
2?L-D[2]-1+L*i:d3?-i-1+L*(l-D[3]):*D+L*(l-i-1)]=++n;D[d=++d3]++;}while(n)
printf(--n%L?%5d:%5d\n,*T++);}
___
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 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
[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(;id;i++){r[i+1]=(r[i]*
10)%d;q[i+1]=48+(r[i]*10)/d;for(j=0;ji+1;j++)if(r[i+1]==r[j])return*r=q[j+1
],q[j+1]=0,printf(%s,q),q[j+1]=*r,q[i+2]=0,printf([%s]\n,q+j+1);}}}
___
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
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] 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*Y4++c8;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
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] 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
[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: 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 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
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
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
[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] 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] 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(cr){r++;puts();for(c=39-r;--c;)
printf( );}printf(~rc? `: #);}}
___
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-33c-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-=a2?.1/(a=-2):0,b2;putchar(30+
c),a+=.0503)for(x=y=c=0;++c90x*x+y*y4;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
[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
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] 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: 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] 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 ctype.h
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: 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--E32;){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: 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: 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_table_attach (GTK_TABLE (table2), vscrollbar, 1, 2, 0, 1,
- GTK_FILL, GTK_EXPAND | GTK_SHRINK | GTK_FILL, 0, 0);
- gtk_widget_show (vscrollbar);
+ scrolled_window = gtk_scrolled_window_new (NULL, NULL
[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_table = gtk_table_new (1, 1, FALSE);
- gtk_box_pack_start (GTK_BOX (hbox), com_table, TRUE, TRUE, 0);
+ /* the comment text_view in a gtk_scrolled_window */
+ scrolled_window
[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 No modules @@ -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 contenir au moins un pinceau. +msgstr Les pinceaux animés doivent contenir au moins un pinceau :\n +« %s ». #: app/core/gimpbrushpipe.c:387 -#, fuzzy, c-format +#, c-format msgid Failed to load one of
[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] 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
