Re: Fw: Re: [Gimp-developer] What to do when zooming in? (bug #79384)
I got a reply from Miles O'Neal about my previous messsage. Since he cannot post to the list, here is his reply followed by my comments: On Tue, 23 Apr 2002 11:34:01 -0500, Miles O'Neal [EMAIL PROTECTED] wrote: On Tue, 23 Apr 2002 15:41:08 +0200, Raphaël Quinet [EMAIL PROTECTED] wrote: I am not sure that I understand the point about the focus behavior. The shortcut keys will only be received by the window that has the current focus. What I was suggesting is that the GIMP checks explicitely if the coordinates of the mouse pointer are within the image window. If it is in the image window (regardless of the focus model), then the GIMP would zoom towards that point. If not, then the current zoom behavior would be used. I understand that. My point is that with focus follows pointer, there is a very high probability that the cursor will be in the image window, but not where the user is looking. Yes, it *could* be elsewhere within the image panel, but since the image usually dominates the real estate, the most likely place for the cursor is inside the image window, itself. If you're mostly used to click to focus, this may not make sense unless you switch models (usually via your window manager) and play around. It's not a major disaster if zoom center defaults to cursor pointer - just an annoyance. If it annoys far less people than the current behavior, that's OK. I have no idea what the percentage of users is that uses each type of focus. I have always been a focus follows pointer user, so I am well aware of what this means. But I don't think that the choice of focus mode has a significant influence on the zoom-in behavior. While using the GIMP, I usually move the mouse a lot because most operations (e.g., selections) require the mouse. So I usually know where the mouse pointer is and I do not think that I would zoom in on the wrong area by accident. Anyway, it looks like most developers do not care much about how the zoom shortcuts behave (considering the low number of replies), so there is no strong preference for one or the other solution. -Raphaël ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Using Gimp
On Tue, 2002-04-23 at 23:57, Russell St.Fleur wrote: I created a plug-in for gimp and when given certain parameters add text to the file. I would like to know if there is a way for the plug-in to work ie.. add the text to the file via the command line. This plug-in is stored on a Server and being accessed by other client machines. I want them to be able to open a window access the server, run the program without getting the dreaded Gtk-WARNING **: cannot open display error. Just straight command line editing of an image and outputing it to a format. This is because Gimp needs an X display to work. Now, there is a way to work around this, either just point it to some machine that gives it access to the DISPLAY, or use the virtual framebuffer of the linux kernel (if the machine runs linux) and run an framebuffer X server on it. But you probably dont want to do that, since ImageMagick suits your task much better; see http://www.imagemagick.org/ - it is a poweful commandline tool that can also add text to images. And it has C, C++, Perl and Java API that you can use to write a small program or have it as part of a larger one. And it does not depend on a $DISPLAY, it can use truetype fonts directly from files. I use that myself with my webcam script to add the date and time and caption for example. I hope this helps Tuomas -- :: :: Tuomas Kuosmanen :: Art Director, Ximian :: :: :: :: [EMAIL PROTECTED] :: www.ximian.com :: :: ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Using Gimp
On Wed, Apr 24, 2002 at 12:55:15PM +0300, Tuomas Kuosmanen wrote: This plug-in is stored on a Server and being accessed by other client machines. I want them to be able to open a window access the server, run the program without getting the dreaded Gtk-WARNING **: cannot open display error. Just straight command line editing of an image and outputing it to a format. This is because Gimp needs an X display to work. Now, there is a way to work around this, either just point it to some machine that gives it access to the DISPLAY, or use the virtual framebuffer of the linux kernel (if the machine runs linux) and run an framebuffer X server on it. Hm. I suppose, Xvfb is the better choice here as there is no need to actually see anything. It also does not need any graphics hardware. Citing the man page: The X community has found many other novel uses for Xvfb, including testing clients against unusual depths and screen configurations, doing batch processing with Xvfb as a background rendering engine, load testing, as an aid to porting the X server to a new platform, and providing an unobtrusive way to run applications that don't really need an X server but insist on having one anyway. Bye, Tino. -- * LINUX - Where do you want to be tomorrow? * http://www.tu-chemnitz.de/linux/tag/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Using Gimp
Hi, [EMAIL PROTECTED] (Tino Schwarze) writes: This is because Gimp needs an X display to work. Now, there is a way to work around this, either just point it to some machine that gives it access to the DISPLAY, or use the virtual framebuffer of the linux kernel (if the machine runs linux) and run an framebuffer X server on it. Hm. I suppose, Xvfb is the better choice here as there is no need to actually see anything. It also does not need any graphics hardware. or (if you are brave) try to use gimp-1.3 which doesn't need an X display at all if started with the --no-interface command-line option. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Why is GIMP 1.3.x user interface much slower than 1.2.x?
This is something that has been bothering me for a while, and maybe I am not the only one who has noticed this. I have compiled the CVS HEAD version and the 1.2.3 version on the same old machine (a Pentium 200) and the CVS version is significantly slower than the 1.2.x version. Of course, there is a lot of debugging code in 1.3.x, but I am surprised that the differences are so significant on that machine. Some simple operations such as accessing the menus (both the pop-up menus and the menus from the toolbox), refreshing the toolbox or refreshing the contents of the docks take approximatively 5 to 6 times longer than with the old 1.2.3 version. The delays are significant enough to disturb the normal flow of operations (at least for me). Does anybody know what could be the source of these delays? Is this due to the GIMP itself (debugging code, new user interface) or is this due to the fact that the CVS version uses GTK+ 2.0 instead of GTK+ 1.2.x? -Raphaël ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: What to do when zooming in? (bug #79384)
[EMAIL PROTECTED] (2002-04-24 at 1306.29 +0300): For the record, I would probably like zoom on pointer since then you can avoid the panning-after-zooming to find the place of the image. And Yes, it would be great, place where you want, hit key and zoom there. Saves the switch to zoom tool and back. that is how the zoom tool works too, doesnt it already zoom centered on where you click? I mean, I dont know since I never use it, being so used to the shortcuts. It does, where you click becomes the centre of the window. I think too that zoom should track mouse, or if mouse is out (sloppy focus, ie, or over widgets around image) zoom based in centre. GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Why is GIMP 1.3.x user interface much slower than 1.2.x?
Hi, RaphaXl Quinet [EMAIL PROTECTED] writes: This is something that has been bothering me for a while, and maybe I am not the only one who has noticed this. I have compiled the CVS HEAD version and the 1.2.3 version on the same old machine (a Pentium 200) and the CVS version is significantly slower than the 1.2.x version. Of course, there is a lot of debugging code in 1.3.x, but I am surprised that the differences are so significant on that machine. Some simple operations such as accessing the menus (both the pop-up menus and the menus from the toolbox), refreshing the toolbox or refreshing the contents of the docks take approximatively 5 to 6 times longer than with the old 1.2.3 version. The delays are significant enough to disturb the normal flow of operations (at least for me). Does anybody know what could be the source of these delays? Is this due to the GIMP itself (debugging code, new user interface) or is this due to the fact that the CVS version uses GTK+ 2.0 instead of GTK+ 1.2.x? Hard to say. It's been said that GTK+-2.0 is substantially slower than 1.2. I don't notice much difference here but then my machine is probably fast enough. Have you played with testgtk; do you notice the same problems there? Of course GIMP-1.3 has lots of room for improvement. One thing that is on our TODO is to change GimpPreview so it can use GdkPixbuf directly. We'd avoid the conversion to TempBuf and could use the (optionally hardware accelerated) pixbuf render routines. Since we use a model-view concept in GIMP-1.3, we use a lot of signal emissions to synchronize the UI with the core data structs. You could get a noticeable speedup by compiling glib without debugging (default since 2.0) and make sure that app/core/gimpmarshal.[ch] is generated using a recent version of glib-genmarshal. Newer versions access the GValues used in signal emissions directly instead of going thru extensive type checks. Basically you should have some code like this in app/core/gimpmarshal.c: #ifdef G_ENABLE_DEBUG #define g_marshal_value_peek_boolean(v) g_value_get_boolean (v) #else #define g_marshal_value_peek_boolean(v) (v)-data[0].v_int #endif For further optimizations we should do some profiling first since it doesn't make sense to remove useful debugging code unless it shows up significantly in the profile. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Why is GIMP 1.3.x user interface much slower than 1.2.x?
On 24 Apr 2002 15:26:05 +0200, Sven Neumann [EMAIL PROTECTED] wrote: Raphaël Quinet [EMAIL PROTECTED] writes: Does anybody know what could be the source of these delays? Is this due to the GIMP itself (debugging code, new user interface) or is this due to the fact that the CVS version uses GTK+ 2.0 instead of GTK+ 1.2.x? Hard to say. It's been said that GTK+-2.0 is substantially slower than 1.2. I don't notice much difference here but then my machine is probably fast enough. Have you played with testgtk; do you notice the same problems there? Yes, I have played with testgtk in both versions. Unfortunately the interface has changed so it is hard to compare the performance in both cases. The new one from GTK+ 2.0 is definitely slower, but it is difficult to say if that would explain the difference seen in the GIMP. Maybe I need to find an even slower computer than my PC at home, so that I can compare how fast GTK+ 2.0 redraws its widgets compared to 1.2.x. Since we use a model-view concept in GIMP-1.3, we use a lot of signal emissions to synchronize the UI with the core data structs. You could get a noticeable speedup by compiling glib without debugging (default since 2.0) and make sure that app/core/gimpmarshal.[ch] is generated using a recent version of glib-genmarshal. Yes, I also get glib and gtk+ from anonymous CVS (updated during the week-end) so I should have the correct version. For further optimizations we should do some profiling first since it doesn't make sense to remove useful debugging code unless it shows up significantly in the profile. Of course! It is much too early to remove the debugging code from CVS HEAD and it would be foolish to start optimizing anything before the code is reasonably stable. And, as you pointed out, no optimization should be attempted before having a good profiling report. I was not trying to find a way to improve the speed of the current GIMP 1.3.x (not yet, at least), but I was curious to know if anybody had an idea about what was making it so slow. -Raphaël ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Why is GIMP 1.3.x user interface much slower than 1.2.x?
Hi, RaphaXl Quinet [EMAIL PROTECTED] writes: Yes, I have played with testgtk in both versions. Unfortunately the interface has changed so it is hard to compare the performance in both cases. The new one from GTK+ 2.0 is definitely slower, but it is difficult to say if that would explain the difference seen in the GIMP. Maybe I need to find an even slower computer than my PC at home, so that I can compare how fast GTK+ 2.0 redraws its widgets compared to 1.2.x. GTK+-2.0 draws its widgets double-buffered which definitely does not make it faster (but reduces flickering). It might be interesting to disable this feature by undefining USE_BACKING_STORE in gdkwindow.c. Since we use a model-view concept in GIMP-1.3, we use a lot of signal emissions to synchronize the UI with the core data structs. You could get a noticeable speedup by compiling glib without debugging (default since 2.0) and make sure that app/core/gimpmarshal.[ch] is generated using a recent version of glib-genmarshal. Yes, I also get glib and gtk+ from anonymous CVS (updated during the week-end) so I should have the correct version. gimpmarshal.[ch] might nevertheless not have been rebuilt since there's no dependency to glib-genmarshal. You better have a look at the files or touch gimpmarshal.list to force regeneration. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] action files in GIMP?
On Fri, Apr 19, 2002 at 10:34:19PM +0300, Tor Lillqvist [EMAIL PROTECTED] wrote: and Gtk is proven to be hard to port to that environment. ... but I still fear that porting gimp-perl might be quite a task. Why? I apart from trivial changes (gimp-perl has to parse the output of gimptool -n --install-admin-bin because gimptool doesn't have an option to output the pluginpath and can't be edited under windows), it compiled out of the box five minutes ago under windows 2000 using cygwin and the binaries from www.gimp.org/win32 (which, as I read it, are not really compatible with my environment anyways). I think the remaining problems are highly trivial (e.g. possible reliance on / instead of \, which mostly isn't a problem under windows anyways, socket functions etc.) It's just that this has to do somebody who knows windows better then me (I lack the time compiler to compile gimp c for windows just to test it). -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Tool Plug-In Changes
On 23 Apr 2002, Michael Natterer wrote: Hi Rock, sorry I did not comment on this earlier, I was quite busy since returning from Guadec. After a few weeks of silence, I figured that you didn't have anything more to say, so I started commiting again. I have my own schedule, too. As mentioned in an earlier mail from Sven, Really I got the impression from that email that you were concerned mostly about the few bugfixes that accidentally got overwritten. The fact that you didn't send me anything else for weeks later reinforced that. Resurrecting the bugfixes was fairly trivial, as was weeding out the few remaining segfaults. They would have been in weeks earlier had you simply asked for them. we are not at all happy with the introducion of plug-in tools and the ongoing exposure of the internal object structure outside the core. I understand some of your objections. What I entirely do NOT understand is why it has taken you so long to say anything concrete about my plans. I had heard some vague comments on irc, but nothing solid, and certainly nothing I didn't think I had resolved long before now. There is absolutely nothing you say here that you couldn't have said after looking at the plans I gave with the patch and two emails I sent to the list on the 23rd and 24 of Febuary, and very little of it couldn't have been said after looking at the original RFC I posted on December 17 of last year. After getting no response to any of those messages, I assumed that there were no objections. I have spent all of my free time working on tool plugins from the time I sent in the first RFC until the present date. Months have passed. I'm pretty busy with school and work, so I haven't had much time to work on it, but I've done practically nothing else with my free time. Yet I heard nothing from you before now, even when I solicited comments repeatedly. Why do you think that your time is orders of magnitude more important than mine? While I have no doubt that it's implementable in a nice and working way, I think it is the wrong way to go. Tools are an internal implementation detail that is closely related to ugly things like GdkEvents and fast response to user input. I don't find the tool class to be particularly ugly, myself. It is low-level, of course, but it seems to be pretty logical. GdkEvents have to be dealt with by any plugin author. They're hardly obscure or ugly. It would be nice if they were delivered in terms of image coordinates, of course, but other than that, pretty much everything in the GdkEvent is needed by the plugin. At the minimum, it needs to know location, pressure, and which shift buttons are being pressed. Of course, for special cases it doesn't need to know all of that, but for a general purpose api, that much is needed. It would be very easy to change the code to use something other than GdkEvents, certainly no harder than it was before. We've discussed response time before. I expect that most people will load most tool plugins into the core most of the time. But it's nice to have a mode where a crashing plugin doesn't crash everything, and that is only possible if the plugin is in a different address space. Response time, of course, will suffer, but response time isn't everything, especially when debugging. Thus people could try out plugins in a safe mode before trusting them, and developers could more easily do a compile-test-debug cycle without spending a lot of time restarting gimp. (Well, there is another way to shorten the edit-compile-debug cycle for tools. We could implement checkpointing and restore the checkpoint on SIGSEGV... But that would be a nightmare!) We should not add further tools, but drastically reduce their number by separating their ui from the core. I agree that better ui/logic separation is needed with the tools. That gives me an idea...but that is for a different email. Then we make the factored out core code (their actual functionality) accessible via both the PDB and a module API. This is close to be finished for the paint tools. In the end, there will be *one* paint tool with a variety of paint_core implementations, each of them optionally featuring it's own tool options. The same holds true for the ImageMap tools, they will probably all collapse into one single tool which simply uses the image_map modules which are compiled in or loaded. This is the first I've heard of any of these plans. I knew you had factored out the PaintCore, but I didn't know about your idea of eventually unifying all of the paint tools into one descendant of the GimpTool class. It is almost impossible for the rest of us to make improvements to Gimp when you keep on making huge changes without telling the other developers about your plans. Please spend a bit of time sharing your plans with the rest of us -- after all, it's much less than what you expect from us. The tool itself is an ugly piece of code which is particularly
Re: [Gimp-developer] SVG format
On 24 Apr 2002, at 16:28, DENAT Christian DvSI/SIReS/GRE wrote: I'm currently looking for svg tools on win32 and look into the gimp.org site to see if gimp supports such vector format. It seems that the answer is no. Please could you confirm this or at least could yout indicate me if there are some plans for such development ? I have not heard of any such plans. Google turns up a set of tools to convert bitmap images through GIMP paths into SVG files for Sodipodi to work with: http://sjbrown.geeky.net/gimp2sodi/HOWTO.html Same search: Raph Levien is planning on doing a full-fledged SVG implementation in the Gnome framework. I don't know how this (w|c)ould fit in with GIMP. What exactly are you looking for: a plug-in vector editor (like gfig), perhaps with vector layers? Or a SVG loader, like the Postscript loader? -- branko collin [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: Fw: Re: [Gimp-developer] What to do when zooming in? (bug #79384)
On 24 Apr 2002, at 10:41, Raphaël Quinet wrote: I got a reply from Miles O'Neal about my previous messsage. Since he cannot post to the list, here is his reply followed by my comments: On Tue, 23 Apr 2002 11:34:01 -0500, Miles O'Neal [EMAIL PROTECTED] wrote: On Tue, 23 Apr 2002 15:41:08 +0200, Raphaël Quinet [EMAIL PROTECTED] wrote: I am not sure that I understand the point about the focus behavior. The shortcut keys will only be received by the window that has the current focus. What I was suggesting is that the GIMP checks explicitely if the coordinates of the mouse pointer are within the image window. If it is in the image window (regardless of the focus model), then the GIMP would zoom towards that point. If not, then the current zoom behavior would be used. I understand that. My point is that with focus follows pointer, there is a very high probability that the cursor will be in the image window, but not where the user is looking. Yes, it *could* be elsewhere within the image panel, but since the image usually dominates the real estate, the most likely place for the cursor is inside the image window, itself. If you're mostly used to click to focus, this may not make sense unless you switch models (usually via your window manager) and play around. It's not a major disaster if zoom center defaults to cursor pointer - just an annoyance. If it annoys far less people than the current behavior, that's OK. I have no idea what the percentage of users is that uses each type of focus. The proposed keyboard shortcut _only_ zooms around the mouse pointer because you want it to. Just like the paint brush paints because you want it to. You would not use the short cut if you did not want to zoom the area around the mouse pointer I don't think the proposal tries to replace the existing zoom tools, but add an extra one. -- branko collin [EMAIL PROTECTED] ___ 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] Thank you
Dear Gimp developers, The gimp is absolutely is one of my indispensable apps. With it I have been able to create cool graphics for web design and photo manipulation for pictures of my family. I sell people on checking out linux and free/open source software by touting the power and usability of the gimp. It is a great, great program. I appreciate all the hard work that has gone into making the gimp, and just wanted to say 'Thank You.' Jamie Strandboge -- Email:[EMAIL PROTECTED] GPG/PGP ID: 26384A3A Fingerprint: D9FF DF4A 2D46 A353 A289 E8F5 AA75 DCBE 2638 4A3A signature.asc Description: This is a digitally signed message part
[Gimp-developer] How many points can be drawn with one call to gimp-paintbrush?
I'm working with L-Systems, using the GIMP as the image visualization engine, and doing the actual string rewriting, etc. in perl-fu. My test images tend to get pretty complicated pretty fast - the one running now is interpreting 88,940 symbols in the l-system. While the number of lines that gets drawn isn't quite this large, we're still talking in terms of tens of thousands of calls to gimp_paintbrush. At the moment I call gimp_paintbrush once for each line segment, as it gets processed from the command string (those 88,940 symbols I mentioned earlier). I was wondering if there might be a noticeable performance improvement if I were to accumulate a large number of line segments (saving their coordinates in an array), and making one call to gimp_paintbrush with some large number of line segments. Is there a known upper limit to the number of end points that can go into the array passed to gimp_paintbrush? -- --Jeff Jeff Trefftzs [EMAIL PROTECTED] http://www.tcsn.net/trefftzsHome Page http://gug.sunsite.dk/gallery.php?artist=68 Gimp Gallery http://trefftzs.topcities.com/home.html Photo galleries ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
