Re: menu translation again - how does it work?
On 14 Jan, Marc Lehmann wrote: So, if at all possible, could some translation expert find a fix for this problem, and I'll just add Logulator to app/menus.c in the meantime. Or did I misunderstand the general plan for translation? I thought that would already have been fixed? At the moment we don't have any fix just an ugly workaround with a bunch of drawbacks. I'll check out whether my idea works and we'll see whether we can fix it for 1.2 or not -- Servus, Daniel
Nasty problem in new file requester...
Hiho! I recently discovered that using one of the spinbuttons in the filenew dialog causes redrawing of the whole upper table and thus flickering. This is quite annoying because it prevents users from using the spinbuttons to choose their imagesize because it is impossible (on my AMD K6-2 400) to accurately select a value; if I click long enough for the autorepeat function to work on one of the buttons the value rises up to really big number or down to 1. This behaviour is not shown for example in the scale dialog, so I guess the redraw signal is thrown by our magic size displaying frame, which leads me to the question: Wouldn't it be better to display the image size somewhere else IN the frame to curb this problem? -- Servus, Daniel
Plugin - Cancel - EXECUTION_ERROR
Hi all, while browsing and hacking many plugins I noticed that pressing "Cancel" in a plugin dialog causes the plugin's return value to be set to STATUS_EXECUTION_ERROR. While this has no effect in normal plugins, it causes a "save failed" message box to appear for all save plugins. I find this really annoying, because pressing cancel is just a normal mode of operation, not an error. Well, none of the current return values gives gimp a hint that "Cancel" was pressed. I suggest to add "STATUS_CANCEL" to the enum which could be treated specially. As I'm going to look at all the save plugins once more anyway, I offer to hack this if nobody objects. What do you think?? bye --Mitch
opinion of end-users
I've shown Gimp 1.1.15 to two "normal" end-users (ie non-programmers), one of which had a Wacom tablet. PROS: * Tear-off menus are useful and intuitive (I think we should perhaps reinforce the --- line by a scissor logo (such as character 0x21 in the Zapf Dingbats font). * Previews in file loading work well and are appreciated. * XInput-aware tools, especially Ink, do interesting effects. * i18n is appreciated. CONS: A few things in the core application: * Layers and channels are *not* intuitive enough. * Bucket fill and magic select can't be made to select an area of contiguous emptyness (alpha=0). * The error margin in Select By Color is not very satisfactory. A selector that could specify a portion of the HSV space (perhaps as three ranges) could be interesting. More problematic are the plugins: * Many plug-ins are not intuitive. They use self-made vocabulary, feature no online help, have numeric parameters whose influence is mysterious... * Plug-ins that generate another image from the current image (ex: polar coords) have no parameter (output size). * Some plugins don't work on grayscale images for no clear reason. PROBLEMS: * Printing (under Linux) yields back results on certain printers (HP DeskJet 690C). * The tablet doesn't work under Windows. * Sometimes, clicking on a layer name in the Layers dialog does not work. * PovRay synthesis is (incorrectly) disabled when no image is open. --- David Monniaux - Laboratoire d'Informatique de l'Ecole Normale Superieure 45, rue d'Ulm 75230 PARIS cedex 5 Phone: +33 1 44 32 20 83 http://www.di.ens.fr/~monniaux Fax: +33 1 44 32 20 80
Re: opinion of end-users
Date: Mon, 17 Jan 2000 18:56:42 +0100 (CET) From: David Monniaux [EMAIL PROTECTED] PROBLEMS: * Printing (under Linux) yields back results on certain printers (HP DeskJet 690C). What exactly are the problems? There are some fixes for HP printers in Print 3.0.5 (on my web site), but I'm curious as to the exact problems they've observed. -- Robert Krawitz [EMAIL PROTECTED] http://www.tiac.net/users/rlk/ Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton
Re: opinion of end-users
Glyph Lefkowitz writes: XInput *obviously* won't work on Win32, since it's **X**input ^_^ (sarcasmhm, I wonder, maybe we could use DirectX-Input or something/sarcasm)) The tablet input was just temporarily broken in the Windows GTk+ version in the currently distributed GIMP for Windows snapshot. The brokenness was a side-effect of the code changes when the GDK backends were reorganised. The code to support tablet input on Windows has been in GTk+ for some time. (Obviously it doesn't use XInput, but another API, called WinTab.) That said, I certainly admit that the tablet support on Windows needs improvement. --tml
Re: opinion of end-users
Date: Mon, 17 Jan 2000 19:04:20 +0100 (MET) From: Avi Bercovich [EMAIL PROTECTED] PROBLEMS: * Printing (under Linux) yields back results on certain printers (HP DeskJet 690C). adjusting the gamma of the image works really well for me. Maybe the print dialog should offer some 'standard' gamma settings. The print plugin does have standard gamma and density settings for different printers. The adjustments in the print dialog box are relative to these (e. g. a gamma setting of 100 in the dialog box is multiplied by the default gamma recorded for that printer). Things changed quite a bit in 1.1.15; there are a lot more settings to play with now. -- Robert Krawitz [EMAIL PROTECTED] http://www.tiac.net/users/rlk/ Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton
Re: opinion of end-users
On Mon, 17 Jan 2000, Robert L Krawitz wrote: Date: Mon, 17 Jan 2000 19:04:20 +0100 (MET) From: Avi Bercovich [EMAIL PROTECTED] PROBLEMS: * Printing (under Linux) yields back results on certain printers (HP DeskJet 690C). adjusting the gamma of the image works really well for me. Maybe the print dialog should offer some 'standard' gamma settings. The print plugin does have standard gamma and density settings for different printers. The adjustments in the print dialog box are relative to these (e. g. a gamma setting of 100 in the dialog box is multiplied by the default gamma recorded for that printer). Things changed quite a bit in 1.1.15; there are a lot more settings to play with now. Oops.. I'm still on a 10 day old 1.1.14 CVS... ttfn, avi -- Avi Bercovich [EMAIL PROTECTED] Sinjeur Semeynsstraat 9 Dept. of Social Science Informatics (SWI) 1183LD Amstelveen University of Amsterdam
Print plugin
The current Gimp plugin (3.0.5) is a stable release at this point. I will accept bug fixes, and support for new printers only if these can be expressed in terms of functionality already in the plugin. I'm starting work on a new development release (3.1) that will lead to a 3.2 release. The goals for 3.2 currently are: 1) Support for more printers. I particularly want to support the current generation of Epson printers (440/640/740/900/750/1200) and Canon printers, since these seem to be among the more popular printers around, but if anyone wants to contribute a driver for something else, please feel free to do so. Note that my only printer is currently an Epson Stylus Photo EX, so I need help here. Testers will be welcome, but I'd like people who have one or more of these printers (in particular, the 740, 900, 750, or 1200) who are not afraid to dig into the innards. 2) Clean up the dialog. The dialog is currently a real mess. For one, the save settings stuff really doesn't work correctly. There are a number of other things I'm considering here. Anyone who actually understands human factors should feel free to contribute. 3) Start the process of decommissioning the plugin (more or less) altogether :-) In other words, this business of each application supplying its own printer driver is nuts, but I've read a lot of comments that Ghostscript's dithering is awful, and that that really isn't the fault of the individual output drivers within it... 4) Clean up the configuration process so that it really can be built as a standalone plugin or as part of the Gimp distribution. 5) Performance improvements consistent with high quality. I'm willing to consider high performance, reduced quality modes as long as the sacrifice in development effort isn't too high, but I think that for the Gimp the emphasis should be on high quality output rather than fast rendering time. 6) Support for 16 bit Gimp (let's lead the way rather than follow). 7) Work with printer manufacturers whenever possible, and try to sell them on opening their own drivers. 8) More separation between the rendering engine and the printer drivers. I've separated the drivers and engine from the UI in 3.0; in 3.2 I want to further break things down to make it easier to add new stuff. 9) Quality improvements. This is a matter of taste; with some printers I've seen that it's possible to improve quality in one dimension (e. g. speckling) at the expense of something else (tonality and hue continuity). I'm a photographer (serious amateur) myself, and my bias is toward good tonality and color at the expense of some grain, but others disagree. Perhaps this should be configurable if we can't come up with algorithms that allow us to do both well. I will be putting the 3.1 development tree on Sourceforge as soon as I get to a reasonably stable point (i. e. things compile). Note that early 3.1 releases may have lots of regressions; I'm working on multibit pixels right now... -- Robert Krawitz [EMAIL PROTECTED] http://www.tiac.net/users/rlk/ Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton
remaining plug-ins to be getextized
Hi, I just received a mail from SHIRASAKI Yasuhiro [EMAIL PROTECTED] that he will not be able to complete the job of gettextizing all plug-ins. He has done a great job so far as all plug-ins in the common directory seem to be finished (I haven't checked, but I think they really are all done). A few plug-ins remain: MapObject gfig gflare gfli libgck twain winsnap xjt I will not have the time to finish this task either, but I will find the time to oversee and apply patches. This is a good chance to contribute, so please someone step forward and take the job. The earlier we finish this the better, since the translators will need some time too... Salut, Sven
some tiff image kills the tiff plug-in
I've got an 34k tiff file that xv cannot load (many errors), and gimp gives an error message "Falling back to RGBA, image might be inverted" (two times) and then the tiff-plug-in segfaults (no usable stacktrace, due to that
Re: Plugin - Cancel - EXECUTION_ERROR
On Mon, Jan 17, 2000 at 02:59:26PM +0100, Michael Natterer [EMAIL PROTECTED] wrote: While this has no effect in normal plugins, it causes a "save failed" message box to appear for all save plugins. I find this really annoying, because pressing cancel is just a normal mode of operation, not an error. I'm not completely sure, but since there simply is no way to cleanly "cancel" plug-ins, it really _is_ an error what is happending, and the save definitely failed (and might leave all sorts of garbage around!). Well, none of the current return values gives gimp a hint that "Cancel" Bad. was pressed. I suggest to add "STATUS_CANCEL" to the enum which could be treated specially. And what's next, "STATUS_DISK_FULL"? That enum shouldn't be taken lightly. Let's face it: gimp has _no_ way of communicating causes to the caller. Instead of extending that enum with more-or-less unspecific errors, one should better extend the system by communicating different error messages. An obvious extension would be to return another value describing the error in more detail (I have written quite a bit about that topic earlier). As I'm going to look at all the save plugins once more anyway, I offer to hack this if nobody objects. I do. At leats in that form, it look like yet another hack that just needs to be removed later on. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Converting Image format
Hi, I have the GIMP toolkit install on LINUX. I need to convert a BMP file to XPM. I am not able to do it successfully. What is the procedure involved in doing this conversion? I looked through all the tutorials that I could access on GIMP. But I didn't find sufficient information. Help will be greatly appreciated. Thanks. - Lakshmi
[patch] escaping double quotes in SF_STRING values
Tamito KAJIYAMA writes: I've just installed 1.1.15 and found a bug (IMO) that Script-Fu failed if a string containing double quotes was given as an argument of the SF_STRING type. Attached is a quick and dirty patch for fixing that bug. This patch is unnecessary when using GLib 1.3 or later, as the whole point of g_strescape() (which is what the ESCAPE macro in the source calls) is to escape chars that are risky in a C (or script-fu) string, like double quotes or nonprinting characters. Unfortunately g_strescape as implemented in GLib 1.2 escapes only backslashes... (because or my shortsightedness, I confess), not double quotes (or nonprinting characters). However, the code in the GIMP that uses g_strescape() gets unnecessary complex if we start taking that into consideration. Wouldn't it be far simpler to release a newer version of GLib 1.2, with g_strescape() having the same calling convention as before (the prototype was changed in GLib 1.3 (partial sigh)), but with a wider range of characters handled, and then require this GLib version (1.2.7?) for the development GIMP? --tml
Re: [patch] escaping double quotes in SF_STRING values
Tor Lillqvist writes: | | Tamito KAJIYAMA writes: | I've just installed 1.1.15 and found a bug (IMO) that Script-Fu | failed if a string containing double quotes was given as an | argument of the SF_STRING type. Attached is a quick and dirty | patch for fixing that bug. | | This patch is unnecessary when using GLib 1.3 or later, as the whole | point of g_strescape() (which is what the ESCAPE macro in the source | calls) is to escape chars that are risky in a C (or script-fu) string, | like double quotes or nonprinting characters. Good news :) | Unfortunately g_strescape as implemented in GLib 1.2 escapes only | backslashes... (because or my shortsightedness, I confess), not double | quotes (or nonprinting characters). However, the code in the GIMP that | uses g_strescape() gets unnecessary complex if we start taking that | into consideration. Yes. My patch was a compromise. | Wouldn't it be far simpler to release a newer version of GLib 1.2, | with g_strescape() having the same calling convention as before (the | prototype was changed in GLib 1.3 (partial sigh)), but with a wider | range of characters handled, and then require this GLib version | (1.2.7?) for the development GIMP? I cast my vote for this approach. -- KAJIYAMA, Tamito [EMAIL PROTECTED]
Re: opinion of end-users
Glyph Lefkowitz writes: XInput *obviously* won't work on Win32, since it's **X**input ^_^ (sarcasmhm, I wonder, maybe we could use DirectX-Input or something/sarcasm)) The tablet input was just temporarily broken in the Windows GTk+ version in the currently distributed GIMP for Windows snapshot. The brokenness was a side-effect of the code changes when the GDK backends were reorganised. The code to support tablet input on Windows has been in GTk+ for some time. (Obviously it doesn't use XInput, but another API, called WinTab.) WinTab? My old little friend WinTab. ; That said, I certainly admit that the tablet support on Windows needs improvement. I dunno Gimp, but MS Windows needs a better WinTab (at least NT). I complained to Wacom about being unable to turn off and on my tablet, and they told me it was a MS Windows problem. I tried with the NT services thing, and there was not way, it did nothing (at least nothing broke either). XFree allows it, if you do not need the tablet, you can turn it off. Only must be on when launching X, then you can play with the switch as much as you want. [For the record, so if problem arises it is answered already.] GSR
Re: [expert] 1.1.15 - internal compiler error
Davor Cengija [EMAIL PROTECTED] writes: print-util.c:1046: internal error--insn does not satisfy its constraints: (insn:HI 4670 5222 5219 (set (reg:DI 4 %esi) (if_then_else:DI (le:DI (reg:DI 0 %eax) (reg:DI 4 %esi)) When plug-ins/print is removed from the Makefile, build goes well even with the -march=pentiumpro flag. Any other informations I should provide in order to catch the bug easily? pgcc 1.1.3 has some problems with alignment please try to use gcc2.95.2, get them from the 7.0, they should work --Chmouel
