Re: [Gimp-developer] Redo shortcut (was: Undo shortcut)
On Wed, Sep 24, 2003 at 11:39:44PM +0200, David Neary <[EMAIL PROTECTED]> wrote: > I'm sure that ergonomy was considered for Photoshop when they > chose Ctrl-Shift-Z for Redo... I do think it's overstating our > importance somewhat to say that what's good for a large portion > of the rest of the world is not good for us. "Others do it" is never an argument, though. What you need are arguments in favour of Ctrl-Shift-Z, and the only ones that there are is "the HIG and other platforms use it, so people are probably used to it, making it easier for them to switch". That is one aspect of usability. It doesn't have much to do with ergonomics, and as others already have said, Ctrl-R/Ctrl-Z is much more ergonomical than three-key-combinations. I think "two keys vs. three keys" is extremely obvious, too. So ergonomics is might have been considered, but it was certainly _dismissed_, as other, much more ergonomic combinations, are available. > > Switching between views this fast with accuracy is simply not possible > > using Shift-Ctrl-Z due the the physiology of the human hand. The optimal > > hand position is left on the shift and control and right on the z, with > > the finger on the shift moving every other beat of the other hand and the > > finger on the control key staying still. > > That depends where the z is on the keyboard :) As a user with german keyboard, I can say that two keys (Ctrl-Z / Ctrl-R) are much easier to toggle than using the proposed three-key combinations. It's of no importance where the z key is, as it is used in your proposed better solution, too. > I believe we could hard-code two keybindings to work as the > default, couldn't we? Technically possible, but extremely horrible, since the user has to be educated about it. And since the only argument in favour of the less ergonomic C-S-Z is "easier to learn", that sounds even worse than leaving it at C-R. > It's pretty consistent. This is true and has been demonstrated :) > And the usability people have considerably more experience with this > than either of us :) usable != ergonomic, though. And I think that gimp users have considerable more experience with using gimp than the usability people. -- -==- | ==-- _ | ---==---(_)__ __ __ 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] Status of gegl, gimp 3.0?
On Wed, Nov 05, 2003 at 12:27:04PM +0100, Sven Neumann <[EMAIL PROTECTED]> wrote: > avoid another large rewrite of the GIMP that would cause another > endless development cycle. So at the moment we consider to start using > some parts of GEGL after GIMP-2.0 is out. This does not necessarily > mean that GIMP-2.2 will have significantly better support for color Looking at the subject, I'd certainly say that the version that a) integrates gegl and b) makes full use of it (La*b*, fixed & floatingpoint etc.) would certainly qualify to be gimp-3.0 (I'd even say a major bump is a must) :) -- -==- | ==-- _ | ---==---(_)__ __ __ 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] Dicom plug-in for gimp
On Sun, Nov 09, 2003 at 11:34:48PM +0200, Dov Grobgeld <[EMAIL PROTECTED]> wrote: > Sven wanted to have a discussion whether this plug-in should be included If discussion means "wants to see some opinions", then here we go :) - No, it should not be included, in general. - As long as there is no good repository for plug-ins (and my opinion is that there isn't), it (and any other plug-ins that can be maintained at reasonable cost(!)) should be included, as that's the best way to ensure total user satisfaction. In other words: Right now, yes, but in the long run it should be a seperately installable module, just as python or perl come with some common modules/extensions, but not all of them. -- -==- | ==-- _ | ---==---(_)__ __ __ 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] Re: [Gimp-announce] ANNOUNCE: gimp-plugin-template 1.3.2
On Tue, Dec 02, 2003 at 06:24:49PM +0100, Sven Neumann <[EMAIL PROTECTED]> wrote: > > i usually advocate the "let bump the major lib" on api/abi change > > because it enable to track common problems: > > myself on this), we do exactly this. During a development cycle, each > and every release is incompatible with the former release, that's why That's, of course, factually wrong. Real incompatibilities have been very rare in practise. What's true is that often a newer version provides features not found in older gimps and vice versa. However, it still did support the old api, which is IMHO the point. > We use the same versioning scheme as almost all of the libaries we > depend on. That alone is a strong argument to stick with it. (Philosophically, I always had a problem with agruments of the form: the others do it, so it must be right. libtool does a lot of things wrong, e.g. forcing -fPIC and other things for no good reason. Just because many packages use libtool, for example, does not magically make it correct). > I doubt that you can find a release in the 1.3 cycle that is API and > ABI compatible with another release from the 1.3 cycle. Very often during the early 1.3 releases I simply re-linked gimp-perl. For many plug-ins, I also just symlinked the old library name to the new library binary, and only once had a problem with that. That's why I wrote "factually wrong". > admit that we don't go thru the hassle of checking this for each > release but simply follow the policy of assuming that the API has > changed. But I am pretty sure that it did indeed change for every or > at least almost every 1.3 release. Still, you don't bump the major library number, which is the standard and historic way to do that, as you have special support from your dynamic linker for that. Changing the name works, too, but I never understood why the established and working scheme is not used by the g* community. yes, many packages use it, but the majority of packages out there does not, especially packages not within the gnome (and to a lesser extent gnu) communities. -- -==- | ==-- _ | ---==---(_)__ __ __ 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] Re: [Gimp-announce] ANNOUNCE: gimp-plugin-template 1.3.2
On Tue, Dec 02, 2003 at 01:25:24PM -0800, Manish Singh <[EMAIL PROTECTED]> wrote: > > since the major is not anymore unique (eg gimp-2.0.23 will provide > > libgimp-2.0.so.23 with the same major as libgimp-1.3.so.23 from > > gimp-1.3.23), we've to include version number into package name too. > > No, you misunderstand. GIMP 2.0.0 will provide libgimp-2.0.so.0.0.0. GIMP > 2.0.23 will provide libgimp-2.0.so.0.0.23. ABI will be maintained for the > the 2.0.x series (and possibly the 2.x series, if we decide to do that). hmm, I don't think both of you are talking about the same thing, as I think both of you are right, but you are talking past each other. The point is, according to custom packaging rules: libgimp-1.3.so.23 => libgimp23 libgimp-2.0.so.0.0.23 => libgimp23 (debian, mandrake.. linux in general). Gimp uses a major of "0" all the time, and thus it's useless to distinguish between major numbers, you need to include the "version number" (that is, not the library version number but the version string encoded in the _name_, or stem), and, while this is "correct", it's a hassle, somewhat more difficult to use etc. Of course, it's perfectly doable. the question is what the benefits are, I mean, you usually get some benefits while sacrificing others. And since the normal way to manage libraries is both established and does solve the problems, it's hard to explain why a second, incompatible (but of course perfectly working) scheme is required or useful. I simply suspect that this has crept in because it's the only portable way to get it right (e.g. on windows, which doesn't have a de-factor workign dll versioning system, although dlls do come with versions). So, the gimp scheme works anywhere where you can have long enough filenames (== "everywhere"), while the usual ELF-way only works on platforms where encoding the major at the end is established practise. As such, the benefit might be "less hassle and less platform specific code". That is enough to justify it, to me, but if it's the case one should acknowledge it and simply tell people: "if you want to fixed, write the patch and get it into the neccessary packages..." > Note that GTK+ 1.3.x bumped the major so number at every release too. Again, "others do it", is not a sound argument... -- -==- | ==-- _ | ---==---(_)__ __ __ 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] Re: [Gimp-announce] ANNOUNCE: gimp-plugin-template 1.3.2
> > Again, "others do it", is not a sound argument... > > Yeah, but the original poster implied in his mail that GTK+ was doing > the right thing by him. I was pointing out the GTK+ does the same thing > as GIMP, so if he thinks it's right, then GIMP is right too. ;) Now that's an extremely good argument :) -- -==- | ==-- _ | ---==---(_)__ __ __ 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] Displaying image using GTK
On Sat, Dec 13, 2003 at 04:19:44PM +0100, Hans Breuer <[EMAIL PROTECTED]> wrote: > - especially if they stop to work as advertised, or if the configure > step takes longer than the actual package compile ;-] which is a severe shortcoming of the build environment (AFAIK, Msys uses cygwin which is awfully slow due to a large number of reasons). On any non-m$ unix, the configure script works reasonably quickly. Maybe some of the commercial unix packages for windows would run them faster, too... (Or maybe the compilers are so much slower, but I'd disagree with that) -- -==- | ==-- _ | ---==---(_)__ __ __ 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] Displaying image using GTK
On Sun, Dec 14, 2003 at 12:46:54PM +0100, Sven Neumann <[EMAIL PROTECTED]> wrote: > This sounds like if you had a clue on what is causing the slowliness > of running configure on Cygnus. The biggest reason is very slow fork(), followed by extremely slow select(), filehandle operations, pipes and much more. Basically, windows makes it very difficult to do simple things, for example, there is no way to simply wait for events, every type of object needs a different waiting paradigm. So to use select, cygwin has to start threads per type of filehandle etc... you can imagine how slow that becomes. And fork is simply not window's model of managing processes (instead you use CreateProcess with 10 arguments...). Windows isn't based on an efficient process model. If you want to do "IPC", you 'simply' load a dll into your memory area and start some threads (which is being called "ActiveX" in the hipper areas of this world). Real IPC is slow, and not really meant to be used. Since configure scripts use fork() and IPC a lot, that's why it's slow. > software on Windows and noticed this shortcoming as well. I wondered > what might be the cause and if there are ways to work around it. Are > there any? Cygwin tries to be correct first, fast second. I don't think there is any workaround, as it's not really a bug that could be workarounded. One could sacrifice posix compatibility to some degree to get faster, but configure scripts will likely always be slow, even if e.g. the sus spawn facilities are being used. One "workaround" would be to link in most shell-utilities into your shell, that would certainly help, to some extent, but don't expect wonders. This is being written by somebody who doesn't think very highly of the windows API, keep that in mind :) I am convinced that the major reason for bad software under windows is the extremely complicated, overloaded and non-orthogonal API. -- -==- | ==-- _ | ---==---(_)__ __ __ 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] Displaying image using GTK
On Sun, Dec 14, 2003 at 01:08:20PM +, "Adam D. Moss" <[EMAIL PROTECTED]> wrote: > As a data point, I use a (optimized build) mingw cross-compiler > hosted on linux, and the raw compilation itself takes a lot longer > (50% longer, or more) than the same compiler version built That's interesting, but fortunately way better than the time configure takes. Preprocessing is indeed a nontrivial compiler phase, but especially with gcc-3, I would not have expected that to make a 50% difference. It could be that for some reason math emulation is enabled because it's a cross compiler build, but since the architecture is the same I wouldn't expect that. Still, my area of gcc expertise isn't in that area, so I would have to research that :) Still, 50% is a lot to be explained by mere monstrous include files. Maybe someone should profile it *g* -- -==- | ==-- _ | ---==---(_)__ __ __ 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] Displaying image using GTK
On Sun, Dec 14, 2003 at 12:46:27PM +, Roger Leigh <[EMAIL PROTECTED]> wrote: > MSYS does not depend on cygwin, BTW. It's entirely standalone. Why do you claim this if a few simple checks could have convinced you otherwise? At least the shell, which is just bash, is linked against the cygwin lib This makes sense, too, because why would you want to duplicate work for no apperent gain? Anyways, forking speed is not the full story, as bash and gcc usually take advantage of the spawn functions, which don't incur the overhead of fork. Of course, what's quite sure is that it's dog-slow, no matter what, and there is no workaround in sight, unless somebody radically changes the design of configure. -- -==- | ==-- _ | ---==---(_)__ __ __ 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] Displaying image using GTK
On Sun, Dec 14, 2003 at 05:13:30PM +, Tor Lillqvist <[EMAIL PROTECTED]> wrote: > I wonder, could the typical fork() immeditaly followed by exec() (in > the child process) be somehow detected by Cygwin/MSYS, avoiding the > need for emulating the full fork() semantics in this typical case? No, but common software like bash has been modified to use the posix spawn functions, which _are_ streamlined on cygwin. Starting processes is still very, very heavyweight under windows. No doubt the large startup overhead of cygwin executables just adds to this. -- -==- | ==-- _ | ---==---(_)__ __ __ 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] Handling of transparent pixels
On Mon, Dec 15, 2003 at 10:45:56PM +, "Adam D. Moss" <[EMAIL PROTECTED]> wrote: > it's quite equivalent to letting the user take the saturation > knob down to zero and then coming back later, turning up > the saturation again and wondering where the original colours To just throw in another personal opinion: The behaviour you describe wrt. saturation would be hilarious. It's even implemented that way in current gimp _until_ you say "OK". After which you have to (comparatively) clumsily have to re-adjust it. Being able to change the saturation later by moving it up again would be rather desirable, even if it will not likely to be done that way for the next decade or so. However, the "layer effects" people want is (in my eyes) exactly that: apply some saturation effect to a layer that you can later change without loss of fidelity. > mask. The solution to just about all the 'I want my RGB data > preserved orthogonally to the alpha in my file!' objections is to Orthoginality is a different argument (and can be rather valid, too). Tools in the current gimp don't work like alpha behaves. If you press OK, the old image is gone. While I sometimes find the erase tool conceptually difficult to use (maybe because it's so unusual), the question is wether this is just a weird added feature (as most people including me _seem_ to view it), or something that hinders people. -- -==- | ==-- _ | ---==---(_)__ __ __ 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] Handling of transparent pixels
On Tue, Dec 16, 2003 at 07:51:13PM +, "Adam D. Moss" <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) wrote:
> >While I sometimes find the erase tool conceptually difficult to use
> >(maybe because it's so unusual), the question is wether this is just a
> >weird added feature (as most people including me _seem_ to view it), or
> >something that hinders people.
>
> Oh yeah, I don't know if you simply made a typo, but 'erase'
> isn't a problem, while 'unerase' is. Not a 'your app will
No, I was referring to the "erase tool" (actually "Eraser") since I was
too lazy to check how the unerase option is called ("Anti-Erase" here).
Sorry for making you guess.
I fully agree with what you say, othwerwise (I think :).
--
-==- |
==-- _ |
---==---(_)__ __ __ 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] Handling of transparent pixels
On Tue, Dec 16, 2003 at 05:55:06PM -0200, "Joao S. O. Bueno" <[EMAIL PROTECTED]> wrote: > Actually, this will be quite possible with the "custom layer mode" I > was cooking a couple months ago, and which I plan do revive to Gimp Right, still I disagree in practise, and here is why: While "it can be done" with the custom layer mode is true, the problem is not the implementation, but the user-interface. The model I was referring to (that is not going to be implemented too soon, if at all) would work somewhat like "whenever the user does something, the operation is added to the pipe/tree for the image. if necessary the user can revisit any stage of the tree and change parameters or insert new steps." This poses a computing problem (it might be too slow/use too much memory for caching etc.) and also a UI problem (how can I make this accessible to the user in an easy way). Incidentally, this is (in a pipe not tree way) how the display app of ImageMagick works, but it's often overlooked. I can resize an image as often as I want (and display will do it in LQ mode quickly for me), but only when I hit the apply menu will it actually resize the underlying image data, keeping highest possible (for imagemagick) quality. > One will just have to write the effect (if he's writiing from scracth, The "just" is the problem. I can do it without custom layer modes, too, I just have to write the program. -- -==- | ==-- _ | ---==---(_)__ __ __ 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] Updating Script-Fu scripts for GIMP 1.3+
On Wed, Dec 17, 2003 at 04:09:45AM +0100, Sven Neumann <[EMAIL PROTECTED]> wrote: > > Script-Fu scripts? In the days of GIMP 1.1.x there used to be a > > script which aided in the updating of Script-Fu scripts from the 1.0 > > API to the 1.1/1.2 API but I don't see one in the 1.3 CVS copy of GIMP. > > This script still needs to be written. The header file gimpcompat.h is > probably the best source of information about the changes to the PDB. If you talk about scm2scm, it's part of the gimp-perl distro and relatively straightfoward (no dependencies, it builds a tree of the script, runs some filtering operations and prints out the script again). If anybody wants to give it a try, I think modifying it for the 2.0 api might take about as long as modifying the scripts manually :) -- -==- | ==-- _ | ---==---(_)__ __ __ 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] Re: GIMP Aqua GTK+OSX
On Thu, Dec 25, 2003 at 02:12:22PM -0800, Robin Rowe <[EMAIL PROTECTED]> wrote: > As documented in our HOWTO, GIMP code is using quote marks instead of angle > brackets when including some GTK library header files. That should not work. If that is true, the gimp developers would be rather happy for reports or patches about that, I am sure. Especially as writing a HOWTO entry is probably _more_ work than just going in and fixing the relevant parts. > As I'm the official project leader for GTK+OSX and posted here representing Woaw, impressive! > surprise us just once by reacting positively when somebody from our team > does something that benefits your project? Frankly, writing howto entries on how broken the gimp codebase is is not benefitting gimp very much. Or did I miss something very obvious? Apologies if that is the case. -- -==- | ==-- _ | ---==---(_)__ __ __ 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] Re: Alternative zoom algorithm
On Sat, Jan 17, 2004 at 01:26:09PM +0100, GSR - FR <[EMAIL PROTECTED]> wrote: > what people is used to or the levels for typical images and finaly get > my patch encouragingly classified as evil, I think I will stop wasting > time and keep my ideas and suggestions to myself. Get used to it, that's how gimp-developer works :( -- -==- | ==-- _ | ---==---(_)__ __ __ 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] Re: Alternative zoom algorithm
On Sat, Jan 17, 2004 at 05:24:51PM +0100, Sven Neumann <[EMAIL PROTECTED]> wrote: > <[EMAIL PROTECTED] ( Marc) (A.) (Lehmann )> writes: > > > Get used to it, that's how gimp-developer works :( > > Marc, your comment is highly inappropriate. Eh, really? Yes, maybe I should have said "that's how gimp developers work", which would be more approriate. > discussion on #gimp and #gimp is IRC and not gimp-developer The discussion took partly place here also, so please take your dogs back and complain elsewhere about appropriateness. > you haven't been around on #gimp when this conversation took place, Well, the discussion here was quite similar (although on #irc it seems to have been worse, which is not surprising to me, many people on #gimp are rather bigheaded and aggressive, much more so than on gimp-developer). > you are definitely not in the position to make such a comment. Oh! I definitely am, having had many similar experiences on #gimp (and few here). However, may I ask you why you think you are in a position to judge this better? I don't think you are. You are welcome to drag this topic out again as I am sure you will do because you think you are something better, but I will stop going down to that level right now. -- -==- | ==-- _ | ---==---(_)__ __ __ 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] Re: Re: Alternative zoom algorithm
On Sun, Jan 18, 2004 at 07:24:01PM +0100, GSR - FR <[EMAIL PROTECTED]> wrote: > -O2 > -O2 -ffloat-store > -O2 -fno-strict-aliasing > -O2 -ffloat-store -fno-strict-aliasing Just to clarify, -fno-strict-aliasing works around bugs in existing code, while -ffloat-store ensures that rounding is done at every step necessary to get exact ieee 754 semantics. > declared const, and still the only way is -O0. There are not too many options here: - this is a bug in the code - this is the bug in gcc - this is a bug in the algorithm If it's not a gcc bug (which is possible but not necessarily probable), thens ee below for some ideas on what this might have caused. > Getting different values cos the compiler decides you can go with > different data size depending if it keeps all or not in CPU is not It's still legal, if you define "legal" as following the standards. It's also not much of a problem usually since you just get extra precision and less rounding, which only a few algorithms have a problem with, and these usually fit into the "designed for specific fp implementations" class. It's also, fortunately, an x86-only-problem, as it's only a big speed hit on x86. As for workarounds for this, you can either use -ffloat-store or setfpucw, in which case you lose the ability to do double precision. However, since -ffloat-store doesn't fix the problems, it could be that the compiler does some unexpected (but legal) transformations. For example, in C, the compiler is legally allowed to transform: r = (1 - a) * b; into: r = a - a * b; Which might not be the same value. If that is a problem, you either have to use more sequence points (i.e. multiple statements), or you need to use fortran, where these kinds of transformations are not allowed :) Unless you are certain that this isn't caused by a real gcc bug (usually, compiling with different major versions of the compiler is a good indication in favour or against it, depending on the outcome, as the same bug in gcc-2.95 and gcc-3.x is a rare thing), you might want to chekc your code for constructs where the limited precision of floating point values makes a difference. This is just a hint, this does not mean that there is a bug there, but floating point values, as you of course know, have their problems that real numbers don't have. (BTW, gdoubles and doubles etc. are not different, so there is no need to bother with testing one set against the other). -- -==- | ==-- _ | ---==---(_)__ __ __ 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] Re: Re: Re: Alternative zoom algorithm
On Tue, Jan 20, 2004 at 02:22:57AM +0100, Simon Budig <[EMAIL PROTECTED]> wrote: > > other parts, and I already had enough with C guts) and is small, it > > just fits in place with the old code instead of more deep changes. > > True. (These "break strict aliasing rules" warnings however are harmless > according to Yosh.) Just a sidenote, unless caused by a bug in the compiler, these warnings are never harmless. They might not cause problems with current gcc, but there is no guarentee that the code will do as expected with other compilers or future versions of gcc, unless one uses -fno-strict-aliasing, which can be a major performance problem in some cases. -- -==- | ==-- _ | ---==---(_)__ __ __ 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] Re: Re: Re: Alternative zoom algorithm
On Tue, Jan 20, 2004 at 01:24:15AM -0800, Manish Singh <[EMAIL PROTECTED]> wrote:
> Well, the bulk of the code in gimp that causes warnings is stuff like:
> void foo (void **p);
>
> void bar (void)
> {
> int *i;
> foo ((void **) &i);
> }
>
> While it does break the letter of the law wrt aliasing rules, are there any
> assumptions that the compiler can legally make that would cause problems?
Well, troubling to me would be the fact that a int is not the same as
a void *, so this very example is a bit strange and could likely cause
problems on 64-bit (or else) architectures, but that is, of course, not
the main point.
I don't know the real case this is based on, but I'd wonder what this code
is supposed to do then. Please note that the warning will not happen when
you cast to a void *, since the pointers might alias then.
Legally, the compiler could cache the contents of i in a register before
and after the call, because foo is not allowed to change it's value. (And
I might guess that foo will not do that, but it's equally hard to see this
as a compiler as it is for a human, so the warning is IMnsO justified).
It's unlikely that this will happen with gcc <= 3.5, which is, IMHO,
a viable platform to tie oneself to, but there are no guarentees that
this won't happen in more complicated cases, with other (less or more
intelligent) compilers or with future gcc versions.
It's hard to judge from his example, but right now it's difficult for
me to imagine a valid use for the above that couldn't easily be written
correctly.
To repeat it: I am quite certain that the above example will simply work
for quite some time in the future, because of some gcc assumptions about
pointers that are difficult to change but make no good otimized code.
Perl does similar pointer castings and has opted the safe way by simply
using -fno-strict-aliasing to compile itself at all times, after being
bitten once.
That might be easier then going through all the code and fixing it, and
will of course silence the warning. Right now, it doesn't make much of a
difference in generated code with gcc, as it is not very good at taking
advantage of (no-) aliasing yet, but this is a hot area in gcc, since
exploiting aliasing rules allow a great deal of optimizations in typical
numerical code.
--
-==- |
==-- _ |
---==---(_)__ __ __ 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] Re: Windows suggestion
On Thu, Jan 29, 2004 at 01:19:14AM +0100, Sven Neumann <[EMAIL PROTECTED]> wrote: > check if there's dominant empty space between them. If that's the > case, the image window could be sized so that it fits into this > space. I am not sure wether this is possible, as you only know the size of a window after it has been mapped, because of the decorations (I might err, but trying to do this portably smells like a nightmare :) -- -==- | ==-- _ | ---==---(_)__ __ __ 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] Re: Bug 132698 - Script-Fu constants vs DB Browser
On Thu, Jan 29, 2004 at 12:27:44PM -0500, Kevin Cozens <[EMAIL PROTECTED]> wrote: > Is the - vs _ use in function names by C vs. Script-Fu historical (as in > typical of the respective languages)? Yupp. > values for plug-ins based on different languages? DB Browser shows > GIMP_RGB_IMAGE for an image type (for C) but its only RGB-IMAGE for > Script-Fu scripts and I have no idea off-hand what it would be for Perl > plug-ins (a third set of enums?). Just FYI, perl uses the enums.pl from the gimp core which lists all the enums. It does, however, do this: $const =~ s/^GIMP_//; i.e.., strip the GIMP_-prefix, so the contants are the names with "_" (easier to type in perl than "-"), but withouth the prefixes. Looks like a third set to me. (Also, perl isn't updated automatically, you have to run a script, so it might be sightly out of sync). -- -==- | ==-- _ | ---==---(_)__ __ __ 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] Re: Bug 132698 - Script-Fu constants vs DB Browser
On Fri, Jan 30, 2004 at 11:57:32AM -0500, Kevin Cozens <[EMAIL PROTECTED]> wrote: > >i.e.., strip the GIMP_-prefix, so the contants are the names with "_" > >(easier to type in perl than "-"), but withouth the prefixes. Looks like > >a third set to me. > > A third set? I was afraid that might be the case. Well, a set extremely similar and in-sync (at least loosely) to the C contants, so while technically different constant names, there is a very easy rule to convert from C to Perl: drop the GIMP_. The gimpdoc program already converts between C and Perl method syntax, so it could just be extended to drop DIMP_ for Contants, too. The pdb documentation is "almost" parseable nowadays (or at leats when I last looked). > I will take a look at the way gimp-perl does things. Constants are hardcoded in Gimp.pm, and there is a program named insenums which will replace these in-place. > The script should be invoked during a build process as it is for the > core part of GIMP. Not so quickly ;) Changes in these enums will immediately break existing scripts, which is a very bad thing. Also, some wild renaming during the 1.3 era resulted in duplicated constants that had to be resolved differently, so this usually involves some manual work, which is why the script has to be run manually, too. > Another way to look at this is from he point of view of help/documentation. > Someone has to create information somewhere that documents the constants > used for plug-ins (whether they be C-based, Script-Fu, or Perl). If we have > one set of constants for use in all plug-in languages the constants only > need be documented once for C. I am not sure wether I understand your concept of "sameness". To me, GIMP_RGB_IMAGE, RGB-IMAGE and RGB_IMAGE is exactly the same constant, just as gimp-drawable-add-layer is the same as gimp_drawable_add_layer and $drawable->add_layer. > For other languages you would need a one liner explaining whether they > are the same as for C or whether you need to change _ to - and you are > done. This is the situation with perl right now, although that line is probably hard to find, but people don't read this type of documentation anyway, they just look at other scripts, and then consistency really pays off. -- -==- | ==-- _ | ---==---(_)__ __ __ 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] Re: Bug 132698 - Script-Fu constants vs DB Browser
On Fri, Jan 30, 2004 at 02:19:56PM -0500, Kevin Cozens <[EMAIL PROTECTED]> wrote:
> regardless of plug-in language. On the other hand, if you want to create
> a new image using an indexed palette its easier to remember to use
> GIMP_INDEXED_IMAGE rather than 4 or was that INDEXED_IMAGE, or
> INDEXED-IMAGE?
In perl, INDEXED-IMAGE needs to be quoted rather unnaturally
(&{'INDEXED-IMAGE'}), so perl users won't bother thinking about
this. Also, perl, unlike C, has mostly working namespaces, so prefixing
each and everything with an application/module name like GIMP_ is not
necessary.
Things are similar for script-fu (there are no namespace issues in
script-fu because it's self-contained and _ looks rather unnatural, I
think).
If somebody wants to write a plug-in in perl who only ever had written
plug-ins in C will have to think twice (at least), there is no doubt.
But a user having used perl before will look at some existing script
anyways (nobody writes plug-ins from scratch).
Think about the GIMP_ prefix as C's way to handle namespaces. As such,
it's part of the C calling convention only. This is handled different in
perl (Gimp::INDEXED_IMAGE or just INDEXED_IMAGE) and script-fu (script-fu
does not have a module or library concept to my knowledge, the the problem
of namespaces does not apply).
> What type of plug-in am I writing again? :-) You get the idea.
Frankly, people forgetting which type of plug-in (in which language) they
are currently writing need professional help *g*.
I am rather convinced that the number of people who can't remember that
they are currently writing C as opposed to scheme is rather low compared
to people that are aware of this.
> DB Browser. People are told to use the DB Browser information and yet,
> it provides misleading information that could frustrate the budding new
> script writer out there.
The DB Browser information should be consistent (i.e. for C _or_
scheme). The information in the DB Browser will never apply to perl
(python...) unless it would have a "perl mode", as perl simply is a
different language with different calling conventions.
Constant names are a much smaller difference than calling conventions
between languages. It is, in general, impossible to use an API for one
language in another without adapting it to the target language.
> And finally, on line 263 of plug-ins/script-fu/siod-wrapper.c is a
> comment which reads:
> These are for backwards compatibility; they should be removed sometime
>
> It appears in the end that I have merely finished something that was
Cleaning up things by removing cruft like this is very useful, and often
being overlooked. Thanks for doing this :=>
I'd also find it cool if you looked into the DB Browser and made it "fully
scheme" or "fully C", i.e. consistent at least to one language. However,
the idea of having the same API, character-for-character, in all languages
is futile. Don't bother with it.
Changing script-fu to comply with this sounds ok, changing the Browser to
comply with script-fu is better, but more difficult (right now it's a mix
of both, or maybe the "abstract PDB language"?).
Perl specifically has a tool named gimpdoc, which shows calling
conventions in perl, e.g.:
layer = gimp_layer_new (image,width,height,type,name,opacity,mode)
layer = $image->layer_new (width,height,type,name,opacity,mode)
Which is close to actual perl, and should give developers the right
idea. It should convert constant names to perl form, too (it currently
doesn't, AFAICR). Having this info in the DB Browser might be useful, but
making the interface support all languages is quite difficult.
One could also argue that the DB Browser does things the "abstract PDB"
way, and is fine this way, although a bit unspecified, as long as rules
exist to convert them to specific implementations. In the case of perl,
these rules are stated in the Gimp manpage, which is a must-read if you
want to develop plug-ins from scratch.
--
-==- |
==-- _ |
---==---(_)__ __ __ 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] Changes needed to DB Browser content?
On Mon, Feb 02, 2004 at 12:49:21PM -0500, Kevin Cozens <[EMAIL PROTECTED]> wrote: > DB Browser should be consistent for one language even if its just the > "abstract PDB language". I don't think it should have different 'modes' to > have it show things depending on a user selectable plug-in language. That > would probably complicate things too much on the developer/documenter side. > I would think that making it consistent to Script-Fu (scheme) would be the > way to go. (no objections form me) > > layer = gimp_layer_new (image,width,height,type,name,opacity,mode) > > layer = $image->layer_new (width,height,type,name,opacity,mode) > > I'm not sure what the difference is between Script-Fu and the "abstract PDB > language". Constant names for one thing, I thought? > The DB Browser should not include examples of the invocation of a given > function. Well, I am sure it will not contain examples for a long time in the future, but surely including examples in _any_ language, even if it's not the one you are developing in, are extremely useful. During normal development, examples are a hundred times better than lots of prose, even if the synatx is from a (slightly) different language. > given plug-in language. That should be considered beyond the scope of the > contents of DB Browser. Language specific information should be part of the > help system of the GIMP or more likely in external documentation. It's called "user friendlyness". I don't ask anybody to add examples to all the functions, but from a theoretic standpoint, having examples in the function reference makes for a very usable interface, because you aren't forced to look into different places for the same info. [lots of other stuff removed that I agree with] > I won't make any changes related to DB Browser information until it is > confirmed that changes are needed, Personally, I don't think they are *necessary*, but I don't object them, either. Not that my objection or agreement should weigh very much(!). > general sense. ie. move things towards language X), and which files need to > be updated (ie. ones ending in .c or is it .pdb with the .c files generated > from that?). AFAICR, most if not all of the pdb interface is created from the .pdb files. At least the constant names, docs etc. are in there. -- -==- | ==-- _ | ---==---(_)__ __ __ 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] Misnamed structure element in SFScript structure?
On Tue, Feb 03, 2004 at 11:52:29PM +0100, Sven Neumann <[EMAIL PROTECTED]> wrote: > Another thing that could be considered is to use a dedicated > interpreter instance for each script. Currently you cannot run two or > more scripts simultanously. Another problem that could be solved with this measure is that script-fu no longer needs to be in memory all the time and would get rid of the delay caused on startup. -- -==- | ==-- _ | ---==---(_)__ __ __ 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] Misnamed structure element in SFScript structure?
On Tue, Feb 03, 2004 at 05:30:19PM -0600, Tim Mooney <[EMAIL PROTECTED]> wrote: > Does anyone know any good reasons why Guile would be an inappropriate > choice for replacing SIOD? As far as I remember, it was because it adds a rather big dependency, and people thought that gimp should come with at least one script interpreter on it's own. (These are not my arguments, I just repeat what I think was one of the bigger points back then). -- -==- | ==-- _ | ---==---(_)__ __ __ 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] Misnamed structure element in SFScript structure?
On Thu, Feb 05, 2004 at 01:06:58PM +0100, Sven Neumann <[EMAIL PROTECTED]> wrote: > I don't think we should do that simply because I don't see what is so > important about having a self-contained scripting language. I'd rather > like to see three or four well-maintained and working scripting > languages that can be installed separately. If we can make sure that > the language extensions work and can be easily installed that should > be good enough then. I think this is already reality, as most people will get gimp from a gnu/linux distribution and many if not most of them will ship these extensions as seperate packages already. (and the rest should easily be prepared to deal with installing things from source). To me it's all a matter of the installer. Simons agruments, however, smell a lot of "standard gimp extension language", because his goal is to have one language that is always pat of gimp, which would effectively be a standard. I don't think that's a bad idea at all, especially when we later think of macro recording and other tasks, where we _will_ need some standardized macro language that should be easy to translate into real scripts. -- -==- | ==-- _ | ---==---(_)__ __ __ 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] Gimp on OS X (was: Re: Misnamed structure element in SFScript structure?)
On Thu, Feb 05, 2004 at 06:10:35PM +0100, Daniel Egger <[EMAIL PROTECTED]> wrote: > BTW: In OSX gtk 2 has really sucky rendering performance compared > to gtk 1. The same is true for gtk+ on other X11 platforms (but it's usually bearable, but very noticable). The biggest offender is font drawing: Xft is a rather slow design already and the (very good!) i18n features of gtk+2 seem to cost even further cycles. It helps to a) avoid antialiasing (small effect) b) use x fonts (big effect). Also, if you use a theme of some kind, try wether not using one will improve your rendering. In my experience, even a simple theme engine can make rendering much slower. There might be other slowdowns, but I think fonts and themes are the predominant offenders that make gtk+2 so slow. -- -==- | ==-- _ | ---==---(_)__ __ __ 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] Misnamed structure element in SFScript structure?
On Sun, Feb 08, 2004 at 07:35:08PM -0800, Manish Singh <[EMAIL PROTECTED]> wrote: > currently, and go beyond that with a full gtk and gimp binding. The > same should be done for python (I have plans to do this) and perl, the > idea being having languages besides C that can use the entire gimp API. Hmm, at least during the 1.2 era, perl did have access to the full API (i.e. low-level pixel access, full UI transparency etc.), and right now I don't think something important has been added that is not accessible (as opposed to parts that haven't been converted to the new API). I mean, in the sense of "you can write plug-ins indistinguishable from plug-ins wirtten in C", this was possible in perl for a long time already. However, very few authors have used these features, and only two perl plug-ins, both written by me, use their own Gtk-UI instead of relying on Gimp::Fu, so I guess the demand for the latter power in perl is pretty low. (I might err and there are lots out there, perl developers have this tendency of doing stuff for themselves without polishing & publishing them...) -- -==- | ==-- _ | ---==---(_)__ __ __ 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] Misnamed structure element in SFScript structure?
On Mon, Feb 09, 2004 at 12:53:40AM -0800, Manish Singh <[EMAIL PROTECTED]> wrote: > Oh sure, out of all the bindings, perl comes closest by far to full coverage. > But iirc it doesn't wrap libgimpcolor, libgimpmath, some of libgimpwidgets, > and libgimpthumb. Ah yes, I haven't looked into the new stuff... [hints for implementors, after looking into a slightly older 2.0 snapshot that I have on my disk:] Most of libgimpcolor and libgimpmath is available in other perl modules (using them directly would be rather slow in perl, using pdl is faster, although the results might be subtly dfferent, of course. Wrapping these into PDL interfaces would be best). The way to wrap the remaining libgimpwidgets is to make them into real gtk2 widgets with properties and signals. The way it is now, every language interface has to reimplement the api, if they were written in the same way as other libgtk2 widgets it would be as simple as calling the register function and have everything available without extra C code. (as I understand, at least the python gtk2 interface is working very similar and would benefit automatically from this). libgimpthumb would probably just need a few init calls to be called on module init, although the design of combining an initialisation function with setting parameters (gimp_thumb_init) might not have been the wisest choice, but this could be handled in perl using "use Gimp:Thumb (MyApp /basedir)", athough it's not clear how to handle multiple users of Gimp::Thumb. Everything else is nicely wrapped into gtk enums and properties there. (Gimp::Thumb might become an extra module on CPAN, even, I see possible uses in non-gimp-apps. Same is true for the other libgimp interfaces that are not tied into the gimp protocol themselves). -- -==- | ==-- _ | ---==---(_)__ __ __ 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] Re: Gimp 2.0
On Thu, Apr 22, 2004 at 03:53:18AM +, Markus Triska <[EMAIL PROTECTED]> wrote: > we would not show a naked woman in a Gimp advertisement, even if it is > perfectly natural. So why would you show a naked baby? Because that's apples to bananas. Naked woman are sexually attractive to normal people. and babies are not.(*) Hinting that babies are objects of sexual desire is becoming more and more commonplace nowadays, in certain cultures at least (mostly, but not limited to, the us). I do not believe that this is a good direction. In other words, people who equate babies (or children) with sexually desirable objects automatically acknowledge that babies _are_ valid sexual objects. They are not, and harassing others to think that way is not, IMnsHO, a direction we should take. I think this is what Sven wanted to hint at with his comment (that such people were sick). It is not the right thing to do to make yourself a slave of this "babies are sexually attractive" thinking, which is, as you hopefully agree, not normal. If you don't, then photos of babies are just that, and should evoke feelings of joy, especially for the parents :=> I voiced my opinion on this mainly to not leave Dave in a kind of limbo, as if he did something wrong. What he did was not wrong at all. (*) pedosexuality is still a mental illness, as defined by most medical associations. (**) (**) homosexuality was a mental illness back in the seventies, and the attempts by doctors to get pedosexuality off the list of mental illnesses have increased a lot recently, so I do not know what the future brings, maybe that proves me wrong -- -==- | ==-- _ | ---==---(_)__ __ __ 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] Baby photos (was: Gimp 2.0)
On Fri, Apr 23, 2004 at 01:40:14AM +, Markus Triska <[EMAIL PROTECTED]> wrote: > > You have not yet explained what exactly makes you think of Dutroux > > when looking at the Photo and what exactly you think has been gained by > > removing that image in that context. The Dutroux connection is > > especially important, since this is a typical "Totschlagargument" [1] > > It rather was the other way around. Only because I continuously read and hear > about this alleged criminal on the media did I think about this context when > looking at the photo. You can take that remark out of my initial mail, and > the point it raised would still be valid. Please consider that millions of people have heard about this case on TV, but so far you are the only person who thinks of this case when looking at baby pictures (there is no connection to babies in the dutroux case at all...), at least the only person on this list, while many others have made it clear to you that they don't think in tis strange way, including Dave. This is certainly not normal. What's also not normal is that you continously insist that you know that Dave removed the picture because he follows your reasoning, despite there is evidence to the contrary. At the moment, you are just trolling, nothing more. And you surely know that and still go on with your abuse of this case, which is probably the reason why so many people on this list are upset. Shame on you. -- -==- | ==-- _ | ---==---(_)__ __ __ 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] more GIMP foundation stuff
On Fri, Apr 23, 2004 at 08:00:17PM -0700, Daniel Rogers <[EMAIL PROTECTED]> wrote: > I've put it here: http://www.phasevelocity.org/bylaws.doc These bylaws Woaw, the bylaws for a free software organisation, written in a proprietary microsoft format! *g* -- -==- | ==-- _ | ---==---(_)__ __ __ 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] Refactoring code from GPL to LGPL
On Wed, May 12, 2004 at 01:12:03PM +0200, Dave Neary <[EMAIL PROTECTED]> wrote: > But let's take an example... > > I write a GPL network daemon (say red carpet). Someone write a non-GPL > compliant client (say an LGPL encapsulation of the RedCarpet XML-RPC > protocol to allow proprietary implementations). Now that library is calling > GPL code, albeit via a network protocol. Is the client library in breach of > the GPL? Well, that's what the license says: The "Program", below, refers to any such program or work, and a "work based on the Program" means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language. (Hereinafter, translation is included without limitation in the term "modification".) [...] If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. [maybe other sections apply] So I hope it's very clear now that "it depends". On what it does depend very much is influenced by local jurisdiction. In short, you won't know what a derived or a seperate work is until you go to court. No matter what people here think or claim, what counts is an actual decision by the court. Always. Usually, there are two groups that might be consulted when one goes to court: the author of the original license document (the FSF) and the author of the program in question. It's a very good idea to have a clarification accompanying the license for this case (as is the case with the linux kernel, and the gimp). In most courts, it counts a lot if the gimp developers say: "uses of libgimp to interface with the gimp do not fall under the gpl, even though it's doing rpc to the gimp". What most people want, however, is a clear indication and definition of derived work, just like you seem to do. However, it's important to understand that this is impossible, not just because local laws apply different in each country, but also because a precise definition is impossible in general. So the best bet you can do is to say: ok, the authors specified their intent explicitly, and I depend on that. Wether that works in court is a different question that not even a lawyer can answer, but usually a court does depend on statements of intent by the program authors. -- -==- | ==-- _ | ---==---(_)__ __ __ 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] Re: GPL discussion (was something else)
On Thu, May 13, 2004 at 01:04:23AM +, Tor Lillqvist <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) writes: > > According to you, this shouldn't be. Additionally, one would assume that > > these are additional restrictions that are explicitly forbidden by the GPL > > itself. First of all, it should have been "could", not "would" in the above sentence. > But these restrictions are placed by the MySQL copyright holders > themselves, aren't they? Yes. But they can't license a product to me saying it's licensed under the GPL and then, in another part of the documentation _outside_ the license, place restrictions not mentioned in the GPL. This is at best contradicting. Also, I am quite sure that not everybody who contributed code to mysql is aware that the GPL is, in fact, not the whole license. That is, *iff* these are additional restrictions, which is a point of view not everybody needs to share. My point is solely that most arguing (even by me, I might interpret the license totally correctly, yet still fail to predict reality) about the requirements of the GPL is moot if somebody goes to court :) -- -==- | ==-- _ | ---==---(_)__ __ __ 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
[Gimp-developer] Re: GPL discussion (was something else)
On Wed, May 12, 2004 at 03:55:31PM +0200, Dave Neary <[EMAIL PROTECTED]> wrote: > > into another language. (Hereinafter, translation is included without > > limitation in the term "modification".) > > I've read and re-read this, and I'm having trouble figuring out how anyone > can consider a network client as being a derivative work of the server. The > client does not contain any of the server. The point is that whatever you think is of no concern, mostly. What counts is what local law says, to a lesser extent what the authors of the program or the license say, and to most extent what decision this might result in court. It might matter to people in the sense of influencing them to either use or not use a piece of software based on their understanding of the license or the laws. However, licenses are a purely legal tool. I am sure the FSF would rather do without licenses and copyright law (which is the reason for the term "copyleft", basically it means "abusing" increasingly restrictive copyright laws to _force_ sharing). As a legal tool, they only mean something in court (well, depending on the legal system in force :) > gets a response (still using xml-rpc as the example). At no stage does the > client contain part of the server. The client can exist with an alternate, > non-GPL implementation of the same server with no change (similarly, It mostly doesn't matter. If the authors say it is covered by the GPL it might be, or it might not be. If you want to know, ignore the authors and if they go to court, hope that you prevail As an example, mysql itself is under the General Public License. The mysql interface library is under the Lesser General Public License. You would expect that you can link against the interface library and get away with only providing a dynamically linked binary. However, a little known "clarification" to the mysql license states that if your product requires mysql (because it e.g. it either uses SQL features only available in mysql OR it is being delivered with mysql) then it's not mere aggregation but a derived work, and the GPL applies to your software. According to you, this shouldn't be. Additionally, one would assume that these are additional restrictions that are explicitly forbidden by the GPL itself. I'd bet, however, that in a court the mysql authors/owners would have good chances to force the GPL license on your product, at least in some countries. It's still a game of chance, though. The point really is to understand that no license can exactly define terms that are completely outside of it's scope, e.g. "derived work", or even dependent on local laws. The GPL doesn't try to define this, and that is what you have to cope with. It's vague, ugly (especially for hackers us who would like to have everything strictly defined and unambgiuous), but really no different to the situation in mathematics, which also contains paradoxies and unresolvable problems. It's something that, I believe, one just has to live with. > >So I hope it's very clear now that "it depends". > > Ummm.. no. And getting unclearer all the time. Get used to it. The "unclearness" is *precisely* :) what this is about. -- -==- | ==-- _ | ---==---(_)__ __ __ 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] three minor issues concerning parasites
On Fri, May 14, 2004 at 07:31:03AM -0700, William Skaggs <[EMAIL PROTECTED]> wrote: > 3) In devel-docs/parasites.txt, a standard parasite called "rendering-intent" > is defined. I think this is based on a misunderstanding. Rendering > intents come into play when you convert an image from one colorspace > to another -- often the best way of doing the conversion is a function > of the intended use of the result: printing, CRT viewing, etc. That > is, a rendering intent is a property not of an image but of an > image transformation. I've two comments on this: first some image format store a rendering intent, and this setting should be preserved, and the natural place to do it is a parasite. And second, rendering intent is a property of a image transformation, but there needs to be a way to select the actual image transformation, so the rendering intent _is_ a property of the image just like a image comment is. Think of it that way: an image using pseudocolour should probably be rendered with wide colour spread. This is a property of a the image, i.e. exact colours are not important. The rendering intent is used to select, out of a set of colour transforms, one that best preserves this aspect of the image. -- -==- | ==-- _ | ---==---(_)__ __ __ 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] Joining the GNOME Foundation
On Sat, May 01, 2004 at 06:06:54PM +0200, David Neary <[EMAIL PROTECTED]> wrote: > For the moment, I am working under the supposition that the best > option available to us is to join the GNOME Foundation. That > means that when we do fundraising, the donations would go to the > GNOME Foundation, and when we have expenses we would ask the > GNOME Foundation for money. In what way would this be different to "we give the donations to the FSF and ask them nicely if we want money"? The original idea behind a seperate gimp foundation was that begging would be necessary (even if the GNOME foudation might be rather open to giving money...) > Are there any people opposed to closer ties with the GNOME > Foundation? Well, GIMP is not part of GNOME, and this assertion was made repeatedly over the years. Apart from labeling GIMP more of a GNOME program, I wouldn't oppose (but I don't count much anyway :) -- -==- | ==-- _ | ---==---(_)__ __ __ 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] Script-fu-server and queuing
> > Because the Gimp was not originally designed as a server, it does > > not follow some conventions that are necessary for such a mode. This > > includes the issue of managing shared resources among different > > threads of execution. A few of the resources that are not > > 'thread-safe' include the current foreground/background color and > > brush shape. Your can work around this problem by using Gimp::lock until it is solved. -- The choice of a | -==- _GNU_ | ==-- _ generation Marc Lehmann +-- ---==---(_)__ __ __ [EMAIL PROTECTED] |e| --==---/ / _ \/ // /\ \/ / http://schmorp.de/ --+ -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE| | ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] wanted: talk at the linxuworldexpo.de
Hi, Unlike previous years, this year there will be freely attendable .org sessions on the linuxworldexpo.de, which is a great improvement over previous yeras. Unfortunately, these were added fairly late, and there are still free slots. I think it would be a great opportunity for some gimp developer (or a technically unchallenged user :) to talk about gimp-2.x, the new features and possibly future plans. Except that it should be about The Gimp the topic and contents of the talk could be chosen freely. The LinuxWorld Conference & Expo will be held in Frankfurt, 26. - 28.10.2004, the free slots would be in the evening of the 26th and 27th, from 18:00-19:00. You can see the preliminary program schedule here: http://www.linuxworldexpo.de/04_03_ixb.php?ID=14&lang=de You'd be in the company of talks about XBox-Linux (Jens Kühnel), KDE (danimo), GNOME (Sven Herzberg), Debian (Alexander Schmehl) and the OSDL Desktop Linux initiative. If you are interested, please reply till tomorrow (yes, it's fairly late, sorry). Thanks, -- The choice of a | -==- _GNU_ | ==-- _ generation Marc Lehmann +-- ---==---(_)__ __ __ [EMAIL PROTECTED] |e| --==---/ / _ \/ // /\ \/ / http://schmorp.de/ --+ -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE| | ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] wanted: talk at the linxuworldexpo.de
On Fri, Aug 06, 2004 at 06:17:32PM +0200, " Marc A. Lehmann " <[EMAIL PROTECTED]> wrote: > If you are interested, please reply till tomorrow (yes, it's fairly late, > sorry). Actually till Sunday, sorry, I was confused. -- The choice of a | -==- _GNU_ | ==-- _ generation Marc Lehmann +-- ---==---(_)__ __ __ [EMAIL PROTECTED] |e| --==---/ / _ \/ // /\ \/ / http://schmorp.de/ --+ -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE| | ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp-remote
On Sun, Feb 06, 2005 at 01:52:40AM +0100, Sven Neumann <[EMAIL PROTECTED]> wrote: > department. What I would like to suggest today is to merge the > gimp-remote functionality into the gimp binary. This would eliminate > the confusion about which binary to use. It would also give us the > chance to reimplement gimp-remote in a less akward way and to > integrate gimp-win-remote, the win32 implementation of gimp-remote. A thing to remember is that even when it is folded into the main gimp binary it still needs special command line switches (otherwise gimp will run into the same problems as mozilla/firebird etc. which often have frontend shell scripts that mistakenly try to contact a running mozilla instance, which only works in single-machine, single-user configs (fixed in debian, btw, but many distros still do this)). -- The choice of a -==- _GNU_ ==-- _ generation Marc Lehmann ---==---(_)__ __ __ [EMAIL PROTECTED] --==---/ / _ \/ // /\ \/ / http://schmorp.de/ -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp-remote
On Sun, Feb 06, 2005 at 02:51:05PM +0100, Sven Neumann <[EMAIL PROTECTED]> wrote: > Would you mind to explain what sort of problems that would be? If we mozilla ./file => file not acesssible (permission denied, other user, inaccessible dir) => file not accessible (different machine) => file not acesssible (different filesystem view) Assuming that a process has exactly the same view of the filesystem as any other is in general not true. Comparing hostnames helps somewhat in the first case. There was a debian bug about this against mozilla, but as it is solved, it's archived and I couldn't find it anymore. So at least some people found that annoying enough to have it fixes. (I found it pretty annoying, but didn't file it as a bug report because I thought I would be alone in that opinion :) Such automatic behaviour presumes single-user (everything is readable to the gimp user) and single-machine (no remote display) configurations, whcih are pretty common nowadays, but universities and other big instalations still often have highly networked environments where this behaviour is annoyung, especially, if, as in the case of mozilla, you couldn't switch it off. > need special command-line switches, we can as well stick to the > current solution. As far as I know, the remote feature of mozilla If the only reason to fold it into the main binary is indeed to get this automatic (but annoying) behaviour, then indeed I see no reason to stick to it. Rifght now, gimp-remote and gimp do semantically very different things. Folding them into the same binary (without different switches) makes behaviour of gimp rather underterministic, especially for scripts etc., and personally I don't think it's worth it. The best thing would be to have gimp-remote automatically start a background instance of the gimp (as it already does). That way one gets these semantics: gimp - start a new editing session, return when closed gimp-remote - make sure a session is already running, return immediately And only the second alternative might run the risk of the file not being accessible. However, the recent trends in GUIs under unix *is* towards single-user-single-machine configs (witness the problems gnome/kde/debian pose in these environments), so you might just ignore these reasons, assuming that such configs will die out. > works by looking for a mozilla window in the current X session. I > don't see what problem that could cause on a multi-user machine. It's pretty annoying if you have to kill mozilla if you want to look at a file in networked or multi-user environments. With gimp, you have the choice. -- The choice of a -==- _GNU_ ==-- _ generation Marc Lehmann ---==---(_)__ __ __ [EMAIL PROTECTED] --==---/ / _ \/ // /\ \/ / http://schmorp.de/ -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: gimp-remote
On Sun, Feb 06, 2005 at 08:41:30PM +0100, Sven Neumann <[EMAIL PROTECTED]> wrote: > Of course you can't load a local file into a gimp instance running on This is, of course, possible, but not with the current gimp-remote, and it's probably not that desirable t make it run. > a different machine but on the same X server. That's not any different > to the current situation though. It's very different, the current situation "just works" when invoking gimp. With your proposed change it simply doesn't work. That *is* a big difference in my book. > And it would probably be possible to design the remote protocol in a way > that avoids this problem. So we can only improve things. I don't thin it is in general. It's possible t ake it work in, say, most circumstances, but I don't think the current behaviouor is so annoying as to make failures acceptable. -- The choice of a -==- _GNU_ ==-- _ generation Marc Lehmann ---==---(_)__ __ __ [EMAIL PROTECTED] --==---/ / _ \/ // /\ \/ / http://schmorp.de/ -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: gimp-remote
On Mon, Feb 07, 2005 at 12:16:33AM +0100, Sven Neumann <[EMAIL PROTECTED]> wrote: > > new, local instance should start to open that file, since the remote > > one can't load that file. But if the remote protocol just looks for a > > gimp window, it will try to use the existing gimp instance to open the > > file. Unsuccessfully. > > Yes, I understood that. And I said that we already have exactly this > problem with the current implementation, so it can probably not become > worse. > > Daniel mentioned problems that could be caused by moving the > gimp-remote functionality to the gimp binary. I asked him to explain > what kind of problems that would be. I don't know why you answered to > this question since it appears that your answer was unrelated. I am sorry to get off-topic, but in your recent posts (weeks) you became very very unfriendly towards other people who want to be helpful. I find his answer very related, as he explained a problem that your proposed change would result in, which is basically what you asked. Now, if you don't want to hear about problems, why are you asking in the first place? -- The choice of a -==- _GNU_ ==-- _ generation Marc Lehmann ---==---(_)__ __ __ [EMAIL PROTECTED] --==---/ / _ \/ // /\ \/ / http://schmorp.de/ -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] CVS HEAD dependency on glib-2.6 / gtk+-2.6
On Sun, Feb 06, 2005 at 02:48:03PM +0100, Sven Neumann <[EMAIL PROTECTED]> wrote: > keybindings have been added and some of the focus problems have been > eliminated. These changes improve usability of the file chooser a lot > and I think that it can now really be called an improvement over the > old GtkFileSelection widget. But of course you will disagree with me. In some directories it takes the Save As dialog a verified 40 minutes to open. Tab completion is still missing. I still have to use my mouse for every operation in the layers dialog because no shortcuts work there, etc. etc. For me, gimp-2.x is a big step backwards in usability, and I am not alone, and I still use 1.3 for editing sometimes, and I think it sucks compared to the power 2.x offers, but at least I can work pretty fast with it. Many people have voiced their concerns, and I think it's a shame that they all get ignored. -- The choice of a -==- _GNU_ ==-- _ generation Marc Lehmann ---==---(_)__ __ __ [EMAIL PROTECTED] --==---/ / _ \/ // /\ \/ / http://schmorp.de/ -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp-remote
On Mon, Feb 07, 2005 at 02:51:00AM +0100, Sven Neumann <[EMAIL PROTECTED]> wrote: > Hi, > > <[EMAIL PROTECTED] ( Marc) (A.) (Lehmann )> writes: > > >> Would you mind to explain what sort of problems that would be? If we > > > > mozilla ./file > > > > => file not acesssible (permission denied, other user, inaccessible dir) > > => file not accessible (different machine) > > => file not acesssible (different filesystem view) > > > > Assuming that a process has exactly the same view of the filesystem > > as any other is in general not true. Comparing hostnames helps > > somewhat in the first case. > > I see the point. But it would be trivial to take care of this, > wouldn't it? The remote protocol would have to check if the instance > of gimp that is already running on the current X server is a local > process or not. Did I miss something obvious? Yes, you miss the first and last error causes given above. A "local" process proves nothing about file accessibility. Think about it, X11 is a networked environment. Processes share an X-display, but not the filesystem view. Linux for example provides each process with it's own filesystem view, and this is expected to be used more and more in the future. The only save protocol would be to tansfer the file contents and name through the x-server (a selection for example), and keep the gimp-remote around to receive the file on saves, which is an awkward solution. I think having the option of using "gimp-remote" with clearly defined limitations (same filesyetm view required) and using "gimp" to ensure correctness is preferable over some heuristic that gets it right for 95% of the users or so. What advantage does an integrated solution bring? As far as -i can see, it's only badly written programs that mindlessly use "gimp" when they should offer the option of using either gimp or gimp-remote. -- The choice of a -==- _GNU_ ==-- _ generation Marc Lehmann ---==---(_)__ __ __ [EMAIL PROTECTED] --==---/ / _ \/ // /\ \/ / http://schmorp.de/ -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp-remote
On Sun, Feb 06, 2005 at 08:08:29PM -0800, Manish Singh <[EMAIL PROTECTED]> wrote: > I think the behavior should be as follows: > > By default, gimp should try to connect to a running instance, but *only* > if it's on the same machine and running as the same user. gimp --remote > (or if argv[0] == gimp-remote) should always attempt to connect to a > running instance, and honor the args that the current gimp-remote has. > And gimp --new-instance always starts a new instance. > > The default in absence of a command line argument should be controlled > by an environment variable, for people with uncommon setups (like, > differing filesystem views). That's a very good approach, as it can be configured system-wide and without requiring commandline args. > That should make everyone happy. It certainly would make me happy. -- The choice of a -==- _GNU_ ==-- _ generation Marc Lehmann ---==---(_)__ __ __ [EMAIL PROTECTED] --==---/ / _ \/ // /\ \/ / http://schmorp.de/ -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] CVS HEAD dependency on glib-2.6 / gtk+-2.6
On Mon, Feb 07, 2005 at 03:00:44AM +0100, Sven Neumann <[EMAIL PROTECTED]> wrote: > Hi, > > <[EMAIL PROTECTED] ( Marc) (A.) (Lehmann )> writes: > > > In some directories it takes the Save As dialog a verified 40 > > minutes to open. > > You better file a bug report about this then or at least make sure > that there's one filed about it. No sweat, already done for some time :) I wouldn't dare to menton bugs here without :) > There have been a couple of changes that deal with exactly this problem > so it would surprise me if the problem is still there. You better make > sure that the relevant people know about it. Well, for one thing it's a gtk+ problem (reading about every file in the directory, which, for large directories, takes ages), and there the bug is filed. However, when I think about it, there is another problem in the gimp: The save-as dialog (by default) only gives me a path-entry, so it's questionable why all that information is being read (in a blocking way, too), when it's not being displayed. This is likely specific to the gimp. > > Tab completion is still missing. I still have to use my mouse for > > every operation in the layers dialog because no shortcuts work > > there, etc. etc. > > How is the layers dialog related to this? It's related to general usability. I have a problem with clicking icons, mainly because I seem to have a mental disorder causing me not to be able to identify icons. Well, seriously, me and a lot of people I know are able to read text much faster than icons, and can enter keyboard shortcuts much faster then clicking icons or menu items. In gimp-2.x, I seem to be unable to set shortcuts in the layers dialog (and the predefined shortcuts that didn't work in 2.0 were removed), so it seems gimp-2 forces me to use menus or clicking icons were I could use keyboard shortcuts before. > I don't think we have ever ignored any concerns and I know that the > GTK+ developers do also care a lot about feedback as long as it > doesn't boil down to "it sucks". Hmm, after reading the various threads about the file-selector, I got a different impression, namely, "the file-selector is great, if you can't see this, you suck" (I am exaggerating a bit here, obviously) :) But many people complained about the good features, namely, being able to paste paths or enter paths using tab completion. This seems to get ignored, because there are undocumented and invisible keyboard shortcuts that provide workarounds... Right now, people laugh at me when they see the "current" (this is gimp-2.2.2) layers dialog and file open/close dialogs. > Unfortunately there seems to be a trend to bitch on other people's work > without even trying to propose better solutions. Hmm, many people (including me, remember my shock when dynamic keyboard shortcuts were mostly gone, which was one of the killer features with gimp) just said sth. akin to "I want the old way back", which in my book counts as "proposing better" (to them) "solutions". I think there is a general trend in making gimp "more user friendly" and less powerful to use (dialogs, shortcuts, icons), to make gimp uniform to other apps even when it makes little sense because gimp is, after all, different (undo/redo etc.). (Another interesting but completely unrelated thing is that gnome offers a wide variety of extending your desktop/panel/menus with more icons, but not with text. It certainly looks more colourful, but most people quickly become confused because there is only so much info that you can convey with an icon, and nobody can remember the actions between 20+ different icons. gimp partly follows that, IMHO). -- The choice of a -==- _GNU_ ==-- _ generation Marc Lehmann ---==---(_)__ __ __ [EMAIL PROTECTED] --==---/ / _ \/ // /\ \/ / http://schmorp.de/ -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] CVS HEAD dependency on glib-2.6 / gtk+-2.6
On Mon, Feb 07, 2005 at 11:01:07PM +0100, Sven Neumann <[EMAIL PROTECTED]>
wrote:
> How would that be specific to GIMP? The problem is that there is not
> only the combo-box. There's a full directory view below it. It's
> hidden in an expander but that doesn't change the fact that it is
> there.
"On my screen, there isn't". It doesn't matter to the user how something
is implemented internally, and that it is hidden but there. by default,
it's not there ("displayed"), and it's hard to imagine why a uI element
that is hidden and not used in many cases should require the majority of
cpu time.
> This is however completely in the GTK+ realm. It could probably
> be improved but that would have to be done in GTK+.
I don't think it's completely in the GTK+ realm. But yes, the biggets
problem is in the GTK+ realm.
> > In gimp-2.x, I seem to be unable to set shortcuts in the layers
> > dialog (and the predefined shortcuts that didn't work in 2.0 were
> > removed), so it seems gimp-2 forces me to use menus or clicking
> > icons were I could use keyboard shortcuts before.
>
> The entries are all available in the Image menu, so you can easily
> bind shortcuts to the entries that don't have one yet. In GIMP 2.2
> these shortcuts work globally. Even if the Layers dialog, the toolbox
Yes, that's a usability drawback for me, too :(
> limited to what appears in the menus. Perhaps you should explain that
> to the people laughing. Laugh about their ignorance.
I don't understand why they are ignorant - having to use undocumented
functionality and keyboard shortcuts without visible representation
anyhwere is a usability problem. It doesn't matter if you post information
how to wrk around that on some mailnglist.
I really find it bad that you think those people are ignorant - not
everybody can (or even will) read the source to find hidden keyboard
shortcuts. That is simply "too much" to ask from anybody.
--
The choice of a
-==- _GNU_
==-- _ generation Marc Lehmann
---==---(_)__ __ __ [EMAIL PROTECTED]
--==---/ / _ \/ // /\ \/ / http://schmorp.de/
-=/_/_//_/\_,_/ /_/\_\ XX11-RIPE
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] CVS HEAD dependency on glib-2.6 / gtk+-2.6
On Wed, Feb 09, 2005 at 09:56:07PM -0800, William Skaggs <[EMAIL PROTECTED]> wrote: > > I really find it bad that you think those people are ignorant - not > > everybody can (or even will) read the source to find hidden keyboard > > shortcuts. That is simply "too much" to ask from anybody. > > Your points are valid, but you have to realize that there is no such > thing as a perfect ui solution in a program as complex as GIMP. If > every interface element is always visible, the interface gets so > complicated as to be unusable. But if elements are hidden, they are > hard to use for that very reason. We can't win. Well, it should be clear that, except for small changes, the old file dialog worked better for the largest number of users. Also, the file save dialog in gimp-2.2 does have a path entry, so I don't think it's impossible to do it (that's just an example). Some problems might be caused by misdesigns in gtk+, but not all. > approach is not to be dogmatic, but to try to find the compromises > that work best for the largest number of users. I don't think the largest number of users specifically need a stripped-down file dialog. -- The choice of a -==- _GNU_ ==-- _ generation Marc Lehmann ---==---(_)__ __ __ [EMAIL PROTECTED] --==---/ / _ \/ // /\ \/ / http://schmorp.de/ -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] CVS HEAD dependency on glib-2.6 / gtk+-2.6
On Fri, Feb 11, 2005 at 01:17:32AM +0100, Sven Neumann <[EMAIL PROTECTED]> wrote: > Hi Marc, > > <[EMAIL PROTECTED] ( Marc) (A.) (Lehmann )> writes: > > > I don't understand why they are ignorant - having to use > > undocumented functionality and keyboard shortcuts without visible > > representation anyhwere is a usability problem. It doesn't matter if > > you post information how to wrk around that on some mailnglist. > > Sorry, but the Image->Layer menu is visible and it is fully documented > also. Sorry, I was talking about the file dialog, which certainly has undocumented and invisilble keybindings, such as ctrl-l. > We can certainly improve the set of default keybindings and try to add > some useful ones in the Layer menu. There's also still the great menu > reorganisation project looking for volunteers... Yeah, that's fine. I just couldn't understand why usability first has to be reduced and then maybe later improved, but if it's according to some master plan it might work even for me, later. -- The choice of a -==- _GNU_ ==-- _ generation Marc Lehmann ---==---(_)__ __ __ [EMAIL PROTECTED] --==---/ / _ \/ // /\ \/ / http://schmorp.de/ -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] CVS HEAD dependency on glib-2.6 / gtk+-2.6
On Thu, Feb 10, 2005 at 07:35:11PM +0100, Michael Natterer <[EMAIL PROTECTED]> wrote: > <[EMAIL PROTECTED] ( Marc) (A.) (Lehmann )> writes: > > Some problems might be caused by misdesigns in gtk+, but not all. > > Ah, So which problem you have with the file dialog is GIMP specific? It takes a long time to open, for no reason. That is gimp-specific, other apps using the file dialog behave differently, as I explained. As I already wrote, the gtk+-specific bug has already been reported. I do think it's worthwhile if you read the beginning of this thread. > Why don't you stop complaining here and talk to the GTK+ mailing list? I didn't know the gtk+ mailing list is responsible for gimp-specific behaviour. Other apps that use the gtk+ file dialog behave differently, as I explained. > There is absolutely nothing we can do about that. That's fine with me then, really. Please note that i never asked you to do something for me. I did, however, describe usability problems with gimp. If you want to ignore these, that is your option (most probably because they are totally out of your control, as neither sven nor you ever shied away from more work to improve the gimp), but please don't claim they aren't there. > And no, we will certainly not hack around to make the GIMP's file > dialogs look different from all other GTK+ apps' file dialogs. On my system (debian), gimp's file dialogs already look very different to other gtk+2 apps. No hack is required, and I didn't ask for one, either. Now, why are you reacting so hostile? I just reported on some general deficiencies in gimp-2.x usability, of which the file dialog is the biggest one. If you (both sven and you) don't want to hear about that, just say so. I do, however, think it's a bad sign that users (I read a few cases on this mailinglist before) who report their problems with usability get treated like that. The very least you can do is acknowledge the problems people have, whatever causes it and wether and how it can and should be fixed is secondary. -- The choice of a -==- _GNU_ ==-- _ generation Marc Lehmann ---==---(_)__ __ __ [EMAIL PROTECTED] --==---/ / _ \/ // /\ \/ / http://schmorp.de/ -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] CVS HEAD dependency on glib-2.6 / gtk+-2.6
On Fri, Feb 11, 2005 at 10:56:38AM +0100, Michael Natterer <[EMAIL PROTECTED]> wrote: > > It takes a long time to open, for no reason. That is gimp-specific, other > > apps using the file dialog behave differently, as I explained. > > On my machine it takes about as long to open GIMP's file dialog > as opening other GTK+/Gnome apps' file dialogs, for example gedit. On mine, too. Really, you are putting words intgo my mouth that I didn't say. _Please_ stay out of this thread _or_ read my original mails where I clearly differentiated between gimp-specific issues and gtk+-specific ones. I think the reaction of accusing people of spreading FUD is pretty dumb, but it seems to become the norm around here. As you continuously ignore what I wrote I see no reason in prolonging this discussion with you further, it just isn't productive to iterate over facts when the other side ignores them. > I don't ignore usability problems which (a) really exist and are (b) > our fault. Indeed, you call people reporting them as spreading FUD. Way cool. Thanks god I am mostly out of here. > fault. It took me some days to sort out usability and look an feel > problems with the GTK+ team right before the new file chooser was > initially released. They added/changed things because we figured them > when porting GIMP to GtkFileChooser. And yes, I am sure you are a) doing good work and b) do that diligently. Still, your reaction to reported usability problems is extremely poor. > GIMP. That's why I asked to complain against GTK+. Well, that's funny, because I already *wrote* that I have reported that problem. This make sit pretty clear thta you didn't read the report, at leats not very carefully, so why do you think you should accuse me of spreading FUD? Do you even know what I am "spreading"? Probably not... -- The choice of a -==- _GNU_ ==-- _ generation Marc Lehmann ---==---(_)__ __ __ [EMAIL PROTECTED] --==---/ / _ \/ // /\ \/ / http://schmorp.de/ -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] CVS HEAD dependency on glib-2.6 / gtk+-2.6
On Sat, Feb 12, 2005 at 01:15:02PM +0100, Sven Neumann <[EMAIL PROTECTED]> wrote: > > where I clearly differentiated between gimp-specific issues and > > gtk+-specific ones. > > Marc, it is you who is constantly trying to change your words. Ehem? > as you figure out that you have been wrong, you start to claim that > you didn't say this or that you referred to a different subject. Ehem? Is this bullshitting tactics? I never changed my words. I originally described a problem with the gimp file dialog, which is caused by two things, a problem in gtk+ and a less disastrous problem in gimp. > did this at least twice in this very thread. Please try to acknowledge > when you have been wrong. Others are doing that here as well. You will Sorry, but bullshitting and bullying around does not help. If at all it's Mitch who should apologize :( If that is the new kind of tactics of you, namely calling others as spreading FUD, trying to intimadate them and bullying them around then you are very poor. You should learn to argue based on sound arguments instead of relying on lies and distasteful bullying tactics. > also have to apologize to Mitch or stay not only out of this thread > but out of this mailing-list. What's that supposed to mean? I have to stay out of this mailing list because I won't apologize to Mitch that he made a mistake? That is, of course, not what will happen. I am not responsible for you and mitch's personal problems, but it's bad that you take it out on others who are trying to be constructive :( -- The choice of a -==- _GNU_ ==-- _ generation Marc Lehmann ---==---(_)__ __ __ [EMAIL PROTECTED] --==---/ / _ \/ // /\ \/ / http://schmorp.de/ -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] CVS HEAD dependency on glib-2.6 / gtk+-2.6
On Sat, Feb 12, 2005 at 09:22:59PM +0100, Sven Neumann <[EMAIL PROTECTED]> wrote: > > Ehem? Is this bullshitting tactics? I never changed my words. I > > originally described a problem with the gimp file dialog, which is > > caused by two things, a problem in gtk+ and a less disastrous > > problem in gimp. > > We had already figured out that the file-chooser issues don't belong Well, it's nice that you figured that out, but I still haven't - yes, the speed problem is inside gtk+, but not the rest of the problems. > here and were discussing the keybindings in the layers dialog. I > explained the Image->Layer menu to you and you claimed that it would > be hidden. I claimed and still claim that I cannot set shortcuts in the layers dialog, which was possible before, and posed a problem for other people in the past, too. I would call this hidden, yes, and I still think it's a usability problem, because 1.2 clearly worked better. > I explained to you that it is clearly visible and documented. Well, but it isn't :( > That would have been the moment for you to shut up. I don't understand you. I described various problems. You claim they are simply not there. Why? I am just trying to explain the problems to you, but your only reactions are ignorance, hostility and bullshit like this. You *are* ignoring these problems, because you don't even *acknowledge* them. The worst problem is that you intimidate people who report such problems. Why?? > Instead you claimed that you were still talking about the > file-chooser. You are taking your words out of the context they > originally appeared in. That's not what I would call good style. You are certainly not in the position to tell others about good style :( > Look at the thread again, you are obviously only interested in a > flamewar. If somebody agrees with your assessment of problems you start accusing them of spreading FUD, twisting words or starting flamewars. Please *do* re-read the thread, if there is a flamewar, then you started it by stopping to discuss the probem and instead resorting to needless insults. I don't think you are interested in a flameware, neitehr am I. You seem to be interested in silencing problem reports, though, as if they didn't exist. > You've been accusing us of ignoring usability issues. There are ample examples of that :) > That is ridiculous since we have been working on nothing but usability > for the last two years. Your logic is broken. Wether you worked on usability or not has no relevance to wether you are ignoring *these* usability problems or not. > Other people are obviously capable of proposing enhancements without > pissing people off the way you do. Your bullying tactics happen to work with other people, that's the difference. Obviously there are a lot of people who can piss you off, judging by your insulting reactions to others, too. And no, singling me out doesn't impress me, as I went through the archives and know better... What does that buy you, I wonder, though. -- The choice of a -==- _GNU_ ==-- _ generation Marc Lehmann ---==---(_)__ __ __ [EMAIL PROTECTED] --==---/ / _ \/ // /\ \/ / http://schmorp.de/ -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] CVS HEAD dependency on glib-2.6 / gtk+-2.6
On Sat, Feb 12, 2005 at 08:29:10PM +0100, Simon Budig <[EMAIL PROTECTED]> wrote: > Marc Lehmann ([EMAIL PROTECTED]) wrote: > > On Sat, Feb 12, 2005 at 01:15:02PM +0100, Sven Neumann <[EMAIL PROTECTED]> > > wrote: > > > as you figure out that you have been wrong, you start to claim that > > > you didn't say this or that you referred to a different subject. > > > > Ehem? Is this bullshitting tactics? I never changed my words. I originally > > described a problem with the gimp file dialog, which is caused by two > > things, a problem in gtk+ and a less disastrous problem in gimp. > > Can all of you please take this off list? It is not at all on topic for > this list. I will now, completely, except for noting that svens postings resulted in precisely what he claimed it wouldn't: yet another thread with actual usability problems has been *killed* in the worst possible way. -- The choice of a -==- _GNU_ ==-- _ generation Marc Lehmann ---==---(_)__ __ __ [EMAIL PROTECTED] --==---/ / _ \/ // /\ \/ / http://schmorp.de/ -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] CVS HEAD dependency on glib-2.6 / gtk+-2.6
On Sun, Feb 13, 2005 at 02:19:52AM +0100, Sven Neumann <[EMAIL PROTECTED]> wrote: > > people in the past, too. > > > > I would call this hidden, yes, and I still think it's a usability problem, > > because 1.2 clearly worked better. > > Marc, I shouldn't argue with you Maybe, but I think sensible arguments are in the best interests of everybody. > but I have to disagree with you here. I don't think you need to, I completely agree with you on this: > Behaviour of keybindings was dependant on the window that has the > focus. I don't know if this has ever been a problem to you but have you > ever seen a new GIMP user struggling with this? Keybindings are vital in > an application like GIMP. If Ctrl-Z for Undo doesn't work in the Layers > dialog because it's only bound to the image window, then you end up > moving focus between windows only to make keybindings work. This is how > GIMP 1.2 worked. For a newbie it takes a long time to [it hasn't been a problem to me because I use focus-follows-mouse, but the current focus behaviour is not a problem to me either, so I agree that this change is a good one] I do not agree with that, though: > The GIMP 1.2 behaviour was a major pain in the ass. Parts of it were, others weren't. Dynamic keybindings worked much better. Also, this does not mean that all the other changes were good, certainly the file chooser was step backwards (it has good features, but all in all it's a step backwards, I guess just temporarily until the gtk+ filechooser gets fixed, but still, right now, it is, and it's not clear how this will be fixed, or wether it will be fixed at all). > get used to this behaviour. Sorry, but 1.2 didn't clearly work better. It did work better at least with respect to keybindings in the layers dialog. Right now, changing keybindings needs to be done in a very awkward way - first search what you want in another menu, with different menu ordering and contents, and then the keybinding isn't even reflected in the layers dialog menu. Yes, I think 1.2 worked clearly better in the layers dialog, and what you say doesn't really invalidate the arguments in favour of that view. > With GIMP 2.2 you can finally concentrate on your work instead of > tracking what window your keypress might go to and what action it will > cause there. I never had that problem with 1.2, but with 2.2, I have the problem of having to go to different places to change keybindings, and not having reminders where I need them. To users like me, this is an absolute step backwards. I don't think it's right to penalize the workflow of some users to improve it for others, just because their style is differently, unless you absolutely must choose between options that cross each other out. For example, you can switch between dynamic keybindigs and mnemonic use via preferences, but the 2.x dynamic keybindings are not as useful as the 1.2 DKB were, and I do not think that penalizing people who prefer that way (remember, it once was a killer feature of the gimp, just as shell-like tab completion in the file dialog was) is reasonable. > > I don't understand you. I described various problems. You claim they > > are simply not there. Why? > > You may have not realized, but I didn't ignore your problems at all. Well... so far... you... did... mostly... but that's ok if you forget them or I was unclear, as long as I have the chance of explaining it, which is difficult if you get insulted for trying... but... well... your choice. > There's a new thread I opened to discuss file-chooser performance and I I thought the file-chooser performance was gtk+ related and off-topic here? At least that was my original impression :) The real problems is unintituive behaviour, for example having to press a "hidden" key combination to get a text entry, or the fact that the file-chooser doesn't display the results of the (lengthy) file scan. If I have to wait for it, it should at least display the results, or do the file scan only when I want it displayed. That *seem* to be gimp-specific problems, at least nobody claimed something different. If these are gtk+-dependent, too, then I'd be glad to know about it, but other apps, such as gedit, which use the filechooser have different behaviour, so I guess it *is* customizable and gimp-specific. > realized that we should have more pre-defined shortcuts in the Layers > dialog. So I added shortcuts for New Layer and Duplicate Layer actions > last night. Cool! That is something that I would have liked to have, too, but it's not as important to _me_, as I can define my own shortcuts. However, defining them has become awkward in 2.2, and this is still an open issue, I think. Having more predefined bindings is nice, but not a solution. Also, please see that my problem was not that you ignored problems per-se, but that instead of arguing logically (even socially) over problems you start insulting people, which usually results in the thread ending prematurely, which IMHO
Re: [Gimp-developer] plugin defaults - where to put them?
On Sun, Feb 13, 2005 at 11:35:05AM -0800, William Skaggs <[EMAIL PROTECTED]> wrote: > > My plugin have various user selectable configuration settings. > > > > Right now, I use ~/.gimp-2.2/gimprc to store the defaults. > > > > I am not sure if it is correct to fill up gimprc in this way, and no > > setting is saved between sessions. > > > > So, Is there a better/recommended way for plugins to store such data in the > > gimp? Is there a recommended practice for saving loading such settings? > > We are developing a mechanism for plug-ins to save settings and configuration > information for GIMP 2.4, but there isn't one in 2.2. Using gimprc will Actually, gimp-perl does that (or at least did that) since the 1.x days, by either using gimp_set_data (obsolete) or global persistent parasites, which has the desired effect. Gimp::Fu uses that mechanism, so all perl plug-ins using Gimp::Fu als their UI have persistency for their settings. That has worked without problems so far. (Actually both global and per-image defaults, so when opening the same plug-in on an image it will use the values used before, if possible, or the global last-recently-used ones). -- The choice of a -==- _GNU_ ==-- _ generation Marc Lehmann ---==---(_)__ __ __ [EMAIL PROTECTED] --==---/ / _ \/ // /\ \/ / http://schmorp.de/ -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: file chooser performance
> If anyone sees this problem and updating to gtk+-2.4.14 or gtk+-2.6.2 > doesn't solve it, I'd like to hear about a way to reproduce it. We Just to make it clear: this is *not* a problem with the gimp code :) After updating to debian's "2.6.2-2", I made a few tests (with gedit, though, which should have similar performance). Opening a large directory over NFS took well over 8 minutes, which is probably quite an improvement, but it's not quite acceptable. (testing with gimp on smaller dirs shows similar performance, which is not surprising, as it's a gtk+ issue) For comparison: CV (which does NOT do file"content"type detection but only checks wether something is a directory or not) requires 23 seconds for the same directory, while the good old xv (which also doesn't do content detection) takes around 88 seconds between opening the schnauzer and seeing the dir contents. strace'ing gedit shows that the only change seems to be that instead of reading 128k of every file, only 8k is being read. One obvious problem is that it first stat's all files _then_ reads them, which is quite inefficient even for local filesystems. However, the detected content types are not even being displayed. Seemingly, they are not used at all, so the obvious improvement, as for the gimp file save dialog, would be to not gather costly data that is not being used or displayed (at least by default). (Not that this is a job for the gimp developers...) (Of course, I only *guess* that it's reading the files to detect content types, I have not *verified* that it does it for that purpose). -- The choice of a -==- _GNU_ ==-- _ generation Marc Lehmann ---==---(_)__ __ __ [EMAIL PROTECTED] --==---/ / _ \/ // /\ \/ / http://schmorp.de/ -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] CVS HEAD dependency on glib-2.6 / gtk+-2.6
On Tue, Feb 15, 2005 at 02:59:55PM -0500, Nathan Summers <[EMAIL PROTECTED]> wrote: > On Sun, 13 Feb 2005 20:53:17 +0100, Marc A. Lehmann <[EMAIL PROTECTED]> wrote: > > > For example, you can switch between dynamic keybindigs and mnemonic use > > via preferences, but the 2.x dynamic keybindings are not as useful as > > the 1.2 DKB were, and I do not think that penalizing people who prefer > > that way (remember, it once was a killer feature of the gimp, just as > > shell-like tab completion in the file dialog was) is reasonable. > > Out of curiosity, why do you find the 2.x dynamic keybindings not as useful? Mostly because they need to be set in a different place (e.g. image menu) then where they are used (e.g. layers dialog) and the shortcuts are not being shown (Which is bad because I often change them depending on my needs). That is what I meant by "penalizing". A minor point is that I need to organize my already-crowded keybindings better because they are global, whereas before I ctrl-d could mean duplicate image or layer, depending on the context (I am used to focus-follows-mouse so this didn't bug me the least, but apperently it did bug many others, so the change improve dusability for the masses or so :). I call this "minor" because it's just that: a minor nuisance, and I guess very difficult to make switchable via a preferences item. And of course very minor is that I need to enable it, but that's sth. I don't need to do very often :-> -- The choice of a -==- _GNU_ ==-- _ generation Marc Lehmann ---==---(_)__ __ __ [EMAIL PROTECTED] --==---/ / _ \/ // /\ \/ / http://schmorp.de/ -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] CVS HEAD dependency on glib-2.6 / gtk+-2.6
On Tue, Feb 15, 2005 at 03:07:43PM -0500, David Gowers <[EMAIL PROTECTED]> wrote: > the difficulty of dynamic-keyboard-shortcutting, you can avoid by creating a > shortcut scheme in advance. That certainly works for you, but it also takes the "dynamic" out of "dynamic keyboard shortcuts", and some users (probably an absolute minority, I have no counts) grew very fond of the dynamic aspect and used it heavily. Having to enter some shortcut editor would destroy this style of working (and isn't necessary right now, of course :) -- The choice of a -==- _GNU_ ==-- _ generation Marc Lehmann ---==---(_)__ __ __ [EMAIL PROTECTED] --==---/ / _ \/ // /\ \/ / http://schmorp.de/ -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP and multiple processors
On Sun, Feb 20, 2005 at 10:55:18PM +0100, Sven Neumann <[EMAIL PROTECTED]> wrote: > mean that it's a stupid pthread implementation. To me this looks like > the kernel believes that it would be better to keep the threads local > than to move one to the other CPU. Linux will not keep two threads running on a single cpu if both are ready and nothing else is running, regardless of locality etc., as the kernel lacks the tools to effectively decide wether threads should stay on a cpu or not. (I mean, it's of course bad to interlave operations on a per-pixel basis instead of e.g. a per-tile basis, but the kernel will run the threads concurrently wether or not it gets slower). > right and using two CPUs would actually cause more overhead than it's > worth? That's quite possible, but IFF the kernel indeed keeps the two threads on a single cpu then it means that both aren't ready at the same time, e.g. due to lock contention or other things. -- The choice of a -==- _GNU_ ==-- _ generation Marc Lehmann ---==---(_)__ __ __ [EMAIL PROTECTED] --==---/ / _ \/ // /\ \/ / http://schmorp.de/ -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP and multiple processors
On Mon, Feb 21, 2005 at 12:12:51AM +0100, Daniel Egger <[EMAIL PROTECTED]> wrote: > >Linux will not keep two threads running on a single cpu if both are > >ready > >and nothing else is running, regardless of locality etc., as the kernel > >lacks the tools to effectively decide wether threads should stay on a > >cpu > >or not. > > Yes and no. I just figured out that the tools I were > looking for are called schedutils and can be used to > change the affinity settings of a process, i.e. pin > it to some CPU or allow it to migrate as the kernel > decides between a set of CPUs. I should have said "unless specially instructed to do so", i.e., not by default. > Forcing the NPTL implementation to degrade to legacy BTW, is this 2.4 or 2.6? > I can force it to use both CPUs now, but even with > 200% utilization it is 2s slower to run this stupid > ubenchmark than on 1 CPU without threads. Now, that's definitely a result then :) -- The choice of a -==- _GNU_ ==-- _ generation Marc Lehmann ---==---(_)__ __ __ [EMAIL PROTECTED] --==---/ / _ \/ // /\ \/ / http://schmorp.de/ -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP and multiple processors
On Mon, Feb 21, 2005 at 09:14:13AM +0100, Tino Schwarze <[EMAIL PROTECTED]> wrote: > > >I can force it to use both CPUs now, but even with > > >200% utilization it is 2s slower to run this stupid > > >ubenchmark than on 1 CPU without threads. > > > > Just a vague guess, but the multiprocessor GIMP pixel > > work scheduler might* farm alternating tiles to alternating > > CPUs. These are reasonably likely to have been allocated > > together and thus sit close together in memory This is unlikely, as the gimp has no say in the physical layout of the memory it gets from the kernel. Also, interleaving should not have much of an effect, as the blocks are large, so there will be no thrashing between cpus (if hyperthreading is in use, then interleaving would actually be slightly better due to limited cache associativity). It's more likely that gimp is doing something wrong currently, with respect to locking or sth. similar. -- The choice of a -==- _GNU_ ==-- _ generation Marc Lehmann ---==---(_)__ __ __ [EMAIL PROTECTED] --==---/ / _ \/ // /\ \/ / http://schmorp.de/ -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [EMAIL PROTECTED]: Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP]
[This is a re-sent because my reent mails had been sent for moderation ut never appeared on-list: is the list still moderated?] On Sat, Jun 18, 2005 at 03:23:02PM +0200, Sven Neumann <[EMAIL PROTECTED]> wrote: > And, you aren't seriously trying to argue that the new GtkFileChooser > would be worse than the old file selection widget, are you? That used Lots of people have expressed that the new filechooser feels worse for them. I, for example, as a heavy unix shell user (probably a totally unimportant part of the gimp user community as I am no graphics artist), still find the old (gtk+-1) file dialogs much easier and more intuitive to use, with less clutter. The best file dialogs ever, because they never got in my way. The new (gtk+-2.6) dialogs _do_ come in my way. They work like ms windows, they feel like ms windows, and they feel clumsy, in the parts that I use: entering filenames. (Despite still blocking for ages due to excessive stat() ing for remote filesystems not in the directory I started them, and many more minor annoyances that certainly _will_ be fixed, or at least be improved, but still make it slow business with gtk+-2.6.4). Other things (workflow) will not get fixed because the target (me!) is not the majority, and not important either. But that doesn't magically make the dialogs useful for me and claiming so again and again makes that more and more grotesque. > to be the case with the early implementations but certainly not with > the latest GTK+ 2.6 releases. The file dialog is getting better and > better with each release. You keep repeating this as if it were some kind of religion - why do you ignore the people who simply disagree? Of course the new dialogs have many more features, but they are _much_ less usable for _some_ people. This is a simple fact. You should really accept that, even if it works for you, and even if you cannot understand it. -- The choice of a -==- _GNU_ ==-- _ generation Marc Lehmann ---==---(_)__ __ __ [EMAIL PROTECTED] --==---/ / _ \/ // /\ \/ / http://schmorp.de/ -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [EMAIL PROTECTED]: Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP]
On Sun, Jun 19, 2005 at 11:53:32AM +0200, Sven Neumann <[EMAIL PROTECTED]> wrote: > > You should really accept that, even if it works for you, and even if you > > cannot understand it. > > I do accept that For some reaosn I cna hardly believe that after reading your original posting. You simply show no sign of understanding for the preferences other people have, as if one-size-fits-all would be the perfect solution. > but I would like people to point out exactly what > problems they have instead of just saying that they dislike the new > dialogs. ... but people do that. And you tell them this is the gimp and not the right place to do that. This is contradictory. > Without detailed complaints we can't do anything to improve > the situation. Well, let's make an example (this has been said before): "I would like to have the file open and save dialogs work the same as the ones in gtk+-1.0, with typing paths into the dialog and tab completion". If you want details then "exactly as in gtk+-1.0" should suffice, because that dialog simply worked. No extra window, no slow extra popups that you have to wait for, no fancy and distracting _hiliting_, no stealing of the current selection etc. etc. Basically I want to be able to blindly enter paths as I could with gimp-1.0, press enter and presto - saved or loaded, with no other die effects. Now, lots of people want other things, for example bookmarks etc. I don't, and some others don't either. There is great diversity. I am not even able to find out wether the file dialog I would like to have is even remotely compatible with the file dialogs other people want to have. I can only say that nice features I found both cool and supportive have been removed, and not been put back in, with the new file dialogs. I am not telling you to go and "fix" it (it ain't even broken!). Other features have been removed or made more difficult or different to use as well and it seems the majority of users found this an improvement. I can live with that. What I simply find annoying is this "there is no problem" attitude. I would find a "there are problems, but we will not go back to that for the very few users who liked it" attitude much much better. -- The choice of a -==- _GNU_ ==-- _ generation Marc Lehmann ---==---(_)__ __ __ [EMAIL PROTECTED] --==---/ / _ \/ // /\ \/ / http://schmorp.de/ -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP
On Mon, Jun 20, 2005 at 12:40:37AM +0200, Sven Neumann <[EMAIL PROTECTED]> wrote: > Perhaps you should stop looking at the dialog and just blindly enter > paths. It works surprisingly well. I just told you that this is not true. Then you told me you'd not ignore complaints. Now you tell me what I should do instead and that it would work "surprisingly well." I don't know what "I am smoking", but this very compaint has come up a number of times, and your only reaction is to talk it down. No, it does not at all work surprisingly well. It is *extremely* slow, it hinders, it flickers, it destroys the selection, it pops up a window. It feels like an ugly kludge and certainly does not wor "surprisingly well". But you should know that. We can argue wether it works "surprisingly well" because it's not clear what it means. To me, this surprisingly well working input is an annoyance and slow-down compared to the simple and fast gtk+1.0 selector. Just compare it to your typical shell: path input time: very few seconds. gtk+: ranging form 5+ seconds to minutes (not counting the time it takes to open the dialog). And no flickering in the shell, no extra popups and it does not even destroy your selection. Obvously, the very term "surprisingly well" is meaningless because other people have different definitons for what works well. And you keep ignoring this. Really. Maybe you just don't understand it. I don't know. I am 100% sure it's not malice! One thing is that people, and _many_ people, just want their location entry back, for lots of reasons: discoverability, pastability and so on. But for some reason this simply does not happen. This is an example where lots of people continually *are* being ignored because the new design is supposedly better. > There's no such atttitude. The new file chooser has bugs and they need > to be fixed. Asking us to revert to the old widget is however not an > option. That might be true, but *if* the old widget was better for the users it should be reverted, no question to be asked. Again, there is an *if* in that sentence. (Also, I really don't see the many bugs. I see misdesign, but I would not call that a bug. There were design decisions involved, and these might be good for some uses and bad for others. At least the problems I have with the dialogs do not seem to be bugs at all, but simply design decisions). I often heard argumnts like "it was a lot of work to design and implement", but there is a logical fallacy in that (a red herring): no matter how much work it was, if the result is bad, it is bad. (Now, there are probably good sides to the new file dialog, but none of the new features mean anything to me, so for me it is only negative). You also said file dialogs should go away (in some distant future) and people should use drag&drop. This is another very bad way to force unnatural (for some) workflow on people: for one thing, drag&drop doesn't work very wlel under X, for another thing it is quite difficult to actually "drag&drop" while prpessing your mouse button for some people. Even I who can easily do drga&drop find for example the selection much easier, because I can do things in etween and do not have to press hte button all the time, which improves my aim. The new file dialog gets more and more byzantine, without offering the simple and effective interface that the old dialog. Now I hear in the long term people should switch from it completey. That is the wrong direction, IMHO. -- The choice of a -==- _GNU_ ==-- _ generation Marc Lehmann ---==---(_)__ __ __ [EMAIL PROTECTED] --==---/ / _ \/ // /\ \/ / http://schmorp.de/ -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP
On Mon, Jun 20, 2005 at 11:14:03AM +0200, Dennis Bjorklund <[EMAIL PROTECTED]> wrote: > > One thing is that people, and _many_ people, just want their location > > entry back, for lots of reasons: discoverability, pastability and so > > on. But for some reason this simply does not happen. > > Do you want this only in gimp or in all programs that use the gtk+ > widgets and dialogs? My understanding is that the dialog (mostly) resides in gtk+, and yes, I would want this functionality everywhere. > I think the gtk dialog can be made better and should be improved for all > applications, not just gimp. Agree. > * In fedora 3 I can type in a filename and it selects that file in the > file tree view and it just works. It does not work with full paths so I At leats in gtk+-2.6 (probably earlier, too), you can start typing the path and a location window will pop up. For absolute paths, start with "/". > never do this). If one fixes so one can type in any path directly, and not > just filenames in the current selected dir, then the Ctrl-L is not needed > anymore. That should be done in gtk+-2.6 already. > * The file tree view does not always have input focus when the dialog is > opened. So sometimes when I type in a filename the focus is in the > bookmark part of the dialog and it matches a bookmark instead. I guess if the focus is that inconsistent you should check wether it's still behaving that way in gtk+-2.6 and report it as a bug if it is. > I've not filed any bugs for the above and I don't know if maybe this have > already been improved in later versions of gtk+ then what's in FC3. It's > simply not a big enough problem for me that I've done that but I still > would want these things to be improved. Well, eventually newer versins will arrive at your desktop. If you report it by then that should be fine. The more annoying a problem is the earlier it will be reported (and, unfortunately more often). > The battle for you to fight is with gtk2 and not with gimp. If gimp > started to use another dialog then what other gtk2 programs did, then > people would start a fight about that. I'm not trying to battle with either the gimp or gtk+. I am trying to battle the continuous attitude of neglecting that there are problems for some users. My understanding here is that the new file dialog has nice features that improve it for many users. I am willing to pay the price of having a less optimal interface in favour of supporting "most" (hopefully) other users. The reasoning is that I often have a different workflow than "the majority" so what's good for me is not necessarily good for others. One could change behaviou base don some preferences, but that would priarily be my job to code. As long as I don't code it as I want it, I cannot complain that others don't do it for me. I think I can complain, however, whe other people claim that problems don't exist. > For you reverting to the old dialog is a solution, If I think about it, yes, that would be by far the best solution for me. > for me that would make > the dialog a lot worse. I am fully aware of some features beign useful to others. That's why I always and clearly wrote "me" when refering to the usefulness of any such features. > be improved so most of us are happy in the future. If not, then what do > you suggest? Either way you choose someone will be unhappy. No, you can still go the preferences way and support both (or more) UI interactions. I am not complaining about missing code, I am merely complaining about neglecting that problems exist repeatedly, which unncessarily drives people mad. The most negative side effect of such comments is that you get endless threads on the issue: every comment of the style "it works" will provoke reactions like "no, it doesn't." -- The choice of a -==- _GNU_ ==-- _ generation Marc Lehmann ---==---(_)__ __ __ [EMAIL PROTECTED] --==---/ / _ \/ // /\ \/ / http://schmorp.de/ -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP
On Tue, Jun 21, 2005 at 01:02:34AM +0200, Sven Neumann <[EMAIL PROTECTED]> wrote: > > I don't know what "I am smoking", but this very compaint has come up > > a number of times, and your only reaction is to talk it down. > > That is a blatant lie. The reaction to these concerns is that me and This is the end of reasonable discussion with you again. Too bad you immediately call other people liars and worse. Couldn'T you simply be reasonable? > these concern with Federico and other GTK+ developers, entering bug > reports and writing patches to fix them. The fact that you completely > ignore this and stick to your lies is becoming rather insulting. I did not even claim that you didn't and where did I ignore this. What's your problem? Accusing me of saying things I clearly haven't again? Accusing me of not having said things that you assume I think? Come on, get a life... > > No, it does not at all work surprisingly well. It is *extremely* > > slow, it hinders, it flickers, it destroys the selection, it pops up > > a window. It feels like an ugly kludge and certainly does not wor > > "surprisingly well". > > I cannot reproduce most of your problems. Which would be? Why does your inability to partly reproduce problems mean that I cannot be taken seriously? > At least not from this description. If you want to be taken seriously, > then please come up with serious descriptions and make sure that > comprehensive and useful bug reports exist for them. You cannot reproduce some aspect of my description but others so claim I can't be taken seriously. That is *exactly* the kind of tactics that annoys so many people: They report sth., you have a problem with some aspect of their descriptino so you dismiss it all. Don't other people simply deserve to be taken seriously, especially if _so_many_people_ report the same kind of problems? It's juts as I said: you ignore or talk down these issues. Fact is, people agree that the way the gtk+-1 file selector worked with regards to text entry and tab completion has no problems. So all this wiggly-waggly "we don't know what you mean" is pretty dumb: I repeat: The behaviour of thre gtk+-1.0 file dialog with regards to text entry and tab completion is *exactly* what people want, and even if it weren't, it's most close. It's exactly what I said earlier, too. All the questions on what to do are completely superfluous, as there even exists working code that explains what people need. What happens instead is that we see kludge after kludge and claims that these kludges would be superior. If the gtk+ developers would want to help they would just listen to the users. And you accuse me of lieing and claim I can't be taken seriously. Don't you realize something? Just because you can bully other people and silence them (well, not all fortunately) does not mean you are right. But I said that before, and you simply don't want to understand that or improve the situation. You need a serious attitude change when dealing with people. > > You also said file dialogs should go away (in some distant future) and > > people should use drag&drop. > > You misunderstood me. If you say so, then it is so. If I were you I'd just accuse you of lieing :( Sorry, but that's not at all funny. > I didn't say that DND is going to replace file choosers. I said that > sooner or later most people will not even know about the concept of > hierarchical file systems. That doesn't mean that they will be dragging > in files from file managers. File managers will also cease to exist (at > least for a large user group). Yeah, I have seriously misinterpretetd what you said when you actually meant that. Have fun! -- The choice of a -==- _GNU_ ==-- _ generation Marc Lehmann ---==---(_)__ __ __ [EMAIL PROTECTED] --==---/ / _ \/ // /\ \/ / http://schmorp.de/ -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Peace!
On Tue, Jun 21, 2005 at 11:20:44AM -0700, Carol Spears <[EMAIL PROTECTED]>
wrote:
> completely off-thread, i would like to see the way mr. lehmann has the
> menu structure set in his own personal instance of gimp.
I never ever changed the menu structure compared to the cvs/source
releases, and I always run in the C locale.
> the Xtns menu. gimp-perl tried to make the scripting environment
> invisible to the user a very very long time ago.
If you mean that I didn't make a separate Perl subhierarchy like
script-fu does (or did), then yes, this I did because I believed
that a user must not be forced to learn the difference between a
C/Script-Fu/python/perl/whatever plug-in. It makes no difference, as long
as it does what it states it would do.
I still believe that making language-specific menus is a disservice to
users. It's only use is for marketing of the language in question ("oh,
so it's in script-fu!"). But such ideas were and probably are unpopular
within a community that prejuduices some languages over others.
--
The choice of a
-==- _GNU_
==-- _ generation Marc Lehmann
---==---(_)__ __ __ [EMAIL PROTECTED]
--==---/ / _ \/ // /\ \/ / http://schmorp.de/
-=/_/_//_/\_,_/ /_/\_\ XX11-RIPE
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Peace!
On Tue, Jun 21, 2005 at 10:24:46PM +0200, Sven Neumann <[EMAIL PROTECTED]> wrote: > Giles <[EMAIL PROTECTED]> writes: > > > I don't think the list can afford to lose the input of either one of you. > > Don't worry. We are just having some fun. At least I hope that Marc > does. I am certainly enjoying it. I am certainly not enjoying it; I don't see it as "having fun", either, and I must say you have weird ways of enjoying yourself. I am trying to make you realize that ignoring problems does not make them go away. Sorry for being a pain in the ass... -- The choice of a -==- _GNU_ ==-- _ generation Marc Lehmann ---==---(_)__ __ __ [EMAIL PROTECTED] --==---/ / _ \/ // /\ \/ / http://schmorp.de/ -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP
On Tue, Jun 21, 2005 at 10:48:15PM +0200, Sven Neumann <[EMAIL PROTECTED]> wrote: > Huh? Is it all over already? That would be a pity. I won't let you drga me down to that level of discussion. So when you want to rant about lies and accusations, feel free to do so without me. > >> I cannot reproduce most of your problems. > > > > Which would be? Why does your inability to partly reproduce problems > > mean that I cannot be taken seriously? > > I simply want you and anyone else who wants to have a discussion on > the file-chooser to do three things: > > (1) Use the latest GTK+ 2.6 release. Most of the problems that you and > others mentioned have been addressed in the meantime and it > doesn't really make sense to have a discussion on bugs that are > already fixed. While there are some changes, fundamentally it's the same behaviour as in 2.6.7. It's simply slowing down users who just want to type in paths. > (2) Take a step back and try to understand the concepts behind the new > dialog. There is room for improvement but the overall design is > good. It is good because it works for newcomers and it still has a > lot to offer to the expert user. As I told you before: for using the dialogs, it doesn't matter wether the design is a beauty in itself or wether it is spaghetti code. What counts is how it works for the user. And the new dialog is still not up to the level of usefulness as the gtk+-1.0 one, despite your continual claims to the contrary. Yes, this is subjective, but you need to accept that some people have different workflows and different styles of user interaction, and for some people, the above statement is true. > (3) Don't try to advertise the old GtkFileSelection dialog as being > the solution that we should revert too. I didn't. I did advertise the way the old file selection dialog used it's text entry as the solution for me (and others with similar complaints). For some reason you really want to misinterpret that again and again, but I am convinced that enough people have made this clear, so there really is no reason to imply that those who complain want to revert tot he old dialog. > That widget sucked badly. Well, it sucked much less than the current dialog in some important respects, like text entry and completion. > It's main problem was that it was completely unusable for > newcomers. Probably. I admit am not concerned with that. > It had exactly one feature to overcome its limitations > and that was Tab completion. That was really great, and was ripped from the users, to be put back step for step and in a still very suboptimal fashion. > Without Tab completion the old dialog > was pretty much unusable. Well, that's quite subjective, but I think it sufficed quite nicely for the simple task of selecting files. It was no worse than most other file dialogs around. The new dialogs have many more potentially useful features (even for me). The pity is that the old "pretty unusable" file dialog was much more supportive than the current one (again, for me, and at least the few others who have complained similalry). I'd take it back everyday, regardless of what it means for other I'users. Now, before you accuse me of asking you to revert the dialog *again*: no, I did not mean to say that, and I did not say that, if you read closely. > The problem here is that Tab completion > is not something that people can discover. At least not the larger > part of our userbase. So if you want to revert to the old dialog, > don't expect to be taken seriously. Well, well... but the gtk+ people who designed the current dialog vividly disagree with you on that. After all, the current dialog is full of features that are not discoverable. You should explain why you outright refuse to consider tab completion (I interpret "not taken seriously" as an refusal to seriously consider something), even though it's part of the current design and despite the fact that people actualyl complain about discoverability issues with the *new* file dialogs. If discoverability of features is the goal of the new dialogs, they clearly failed. > If you insist on being taken seriously with this approach, please > show me evidence to back up your claims. I, and others, did so. I know you want to ignore it (and you do). I just find it annoying of you to ask or details again and again and the accuse people of not providing details (or worse). If you want to ignore it anyways, just say so, so people can stop wasting their time. It should be *extremely* and *crystal* clear of what people want: a visible text entry, and tab completion as in the old gtk+ file selector. There is even code that shows the behaviour. I don't know what "evidence" you want, "to be taken seriously". Isn't people arguing for it all the evidence you need? > So as long as you can try to even consider these three points, we can > probably have a very interesting
Re: [Gimp-developer] Peace!
On Tue, Jun 21, 2005 at 09:28:56PM +0200, Michael Schumacher <[EMAIL
PROTECTED]> wrote:
> > I still believe that making language-specific menus is a disservice to
> > users. It's only use is for marketing of the language in question ("oh,
> > so it's in script-fu!"). But such ideas were and probably are unpopular
> > within a community that prejuduices some languages over others.
>
> You didn't miss the current efforts or restructuring the menus, did you?
I very likely did miss them. That's why I wrote "as script fu does (or
did)" because I am not that well-informed about future menu plans. Not
even about the current cvs menus.
If it coincides with what I stated as my goals and preferences then just the
better...
(Please note that I was asked a specific question and gave a specific
answer. I did not criticise current or future plans).
--
The choice of a
-==- _GNU_
==-- _ generation Marc Lehmann
---==---(_)__ __ __ [EMAIL PROTECTED]
--==---/ / _ \/ // /\ \/ / http://schmorp.de/
-=/_/_//_/\_,_/ /_/\_\ XX11-RIPE
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP
On Tue, Jun 21, 2005 at 10:48:15PM +0200, Sven Neumann <[EMAIL PROTECTED]> wrote: > (1) Use the latest GTK+ 2.6 release. Most of the problems that you and > others mentioned have been addressed in the meantime and it > doesn't really make sense to have a discussion on bugs that are > already fixed. Sorry, I was completely wrong earlier. I just spent some more time with the 2.6.8 file dialog. Not a _single_ problem I described been changed (I originally assumed that the "kills the selection" problem has gone away, but it's still there). So what you said above is wrong (in your langauge "is a blatant lie"). Why do you claim that if it isn't true? What is the purpose behind your behaviour? Really, just claiming that problems aren't there doesn't make them go away. -- The choice of a -==- _GNU_ ==-- _ generation Marc Lehmann ---==---(_)__ __ __ [EMAIL PROTECTED] --==---/ / _ \/ // /\ \/ / http://schmorp.de/ -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP
On Wed, Jun 22, 2005 at 12:59:33AM +0200, Sven Neumann <[EMAIL PROTECTED]> wrote: > Hi, > > <[EMAIL PROTECTED] ( Marc) (A.) (Lehmann )> writes: > > > Not a _single_ problem I described been changed (I originally > > assumed that the "kills the selection" problem has gone away, but > > it's still there). > > What is "kills the selection"? I haven't been able to make anything > out of that term. No problem: make a selection, open the file dialog, start typing => the selection is gone (this is an illness that generally started to spread within the last 6 months, at least I have never seen programs doing that before, now lots of programs do that). -- The choice of a -==- _GNU_ ==-- _ generation Marc Lehmann ---==---(_)__ __ __ [EMAIL PROTECTED] --==---/ / _ \/ // /\ \/ / http://schmorp.de/ -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP
On Wed, Jun 22, 2005 at 12:18:34AM +0200, Sven Neumann <[EMAIL PROTECTED]> wrote: > all that bad compared to the former. Most of the complaints seem to > come from people who got accustomed to the old dialog and haven't > really tried to approach the new one yet w/o leaving the old habits > behind. Of course that's an assumption but the discussions that > evolved around these complaints seem to show that. In the case of tab completion, you don't seriously want people to leave the "old habits" behind? That argument has a problem: old habits are not bad at all. Habits are bad if they can be improved. But in this case, making tab completion slower and/or more clumsy and difficult to use is not really a useful option. Or, put in other words: just becasue it's new and difefrent doesn'T automatically make it better. > > Yes, this is subjective, but you need to accept that some people > > Of course. That has never been questioned. Well, many of the things you say certainly sound as if there would be only one valid workflow, and whoever doesn't use it is mistaken (for a very mild example see the "old habits" argument above. There is no logical connection between "old habits" and "bad habits"). > But I am not concerned with that, at least not as much as with the > usability of GIMP for new and infrequent users. Well, if those features get in the way of more experienced people, I'd be strictly against it. But we can easily disagree on this point... > >> (3) Don't try to advertise the old GtkFileSelection dialog as being > >> the solution that we should revert too. > > > > I didn't. I did advertise the way the old file selection dialog used > > it's text entry as the solution for me (and others with similar > > complaints). > > So far noone has made a proposal on how such an entry should be > integrated with the current dialog. Argh. Lots of people have. If you look closely, many people just asked for a text entry. Integrating that into the dialog would make tab completion the old way very natural. Given that there *are* proposals, a) why do you say no one proposed it and b) what would the possible problems be? I can easily understand that keyboard shortcuts get in the way, but right now, typing creates a tetx entry, so entering characters is already reserved for that. Is it a limitation inside gtk+? It would be great if you could enlighten us why the proposals don't work. > So I don't have much chance but to assume that what you have in mind is > basically the behaviour of the old dialog. The behaviour with regards to having an entry widget and how it works. Yes, I guess you completely understood that then. > Perhaps you aren't suggesting to revert to it code-wise, Certainly not. > but I haven't yet seen a detailed proposal on how an entry with Tab > completion is supposed to work without bringing back the problems we > had with the old dialog. I am not aware of any problems with regards to tab completion in the old dialog. Talking about that might be quite productive. > I certainly wouldn't want to miss the current key-navigation > behaviour. But perhaps you can offer a viable alternative? What is the current key navigation behaviour? cursor keys? I don't really need cursor keys when I do tab completion, and when I need them, I could easily use my mouse to click. > Such an alternative would have to be a concept for the whole > dialog. Just adding an entry with Tab completion is going to ruin the > whole thing. Well, the simplest solution would be some (non-gimp) preferences to enable a text entry for those people who prefer it. (Remember that I don't ask for people to implement that. My primary concern is that the existing problems and complaints are (or were) being talked down). > >> It's main problem was that it was completely unusable for > >> newcomers. > > > > Probably. I admit am not concerned with that. > > See. That is the main problem with your approach. You are only > concerned with your needs. That's obviously wrong. If I were the only one who'd like to have an effective tab completion I would be very very silent. So no, I am not just concerned with my needs, but with the needs of at least some more people. > That is all valid but you should at least try to look at the bigger > picture or else I don't see how we can get anywhere if we are discussing > user interfaces. Well, I am mostly concerned with my needs (and have said a lot of times that you semed to have missed that I do understand that other needs need to be satisfied, too) and you said you are mostly concerned with newbie needs, so what's the big difference here? Why is it bad when I say it but good when you say it? That makes no sense... > > Well, well... but the gtk+ people who designed the current dialog > > vividly disagree with you on that. After all, the current dialog is > > full of features that are not discoverable. > > The question here is if the dialog works w/o discovering these > fea
Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP
On Tue, Jun 21, 2005 at 09:53:20PM -0400, Robert L Krawitz <[EMAIL PROTECTED]> wrote: > people"? The problem (to me, and I daresay to Marc) is very simple -- > there's no obvious way to simply enter a pathname with a simple form > of completion that's only activated on demand. Actually, the old file selector didn't just have an entry to type in. As a matter of fact, most file dialogs I know are very hard and unintuitive to use, I often end up activating all sorts of things and often have to close and reopen it to get into a sane state. Most motif programs fall intot hat category. Whta made the old dialog so special was that you could just type in paths as you could elswhere in unix - namely via tab completion. For example replacing tab by enter completely wrecks this feature, as this is not at all intuitive, because enter usually means "do it" (either in the shell or in a dialog), so people are not quick at pressing enter and using it as a key to press oftentimes slows down considerably. The thing is, the old dialog had this tremendously great and useful and fats and efficient (whatever) feature that make it distinct to most other file dialogs and extremely easy and joyful to use for me and all the people around me (who incidentally also use a terminal and vim to to most of their other tasks. Those people are not by any means rare in the unix world, and making their life worse by making gimp more windows-like in behaviour (such as the current file dialog does) is imho a very wrong direction: People are not used to press enter after pathname components, people are not used to use cursor-down/up to select between components, as both of those usually destroy what you were typing). _Everybody_ I showed that tab feature (that they didn't expect in clumsy graphical programs), wether on trade shows or in private, was immediately drawn in to how great it was. Similarly to the dynamic keyboard shortcuts which are not disabled by default. Those fetaures had definitely a discoverability problem, but the new field dialog is IMHO worse with respect to discovering those features. I feel (And judging from the feedback I am not alone) that removing those features (or making them harder to use) in the name of usability is the wrong approach. Making everything easy for newbies most often means making it more difficult for regular users. sometimes you can find a compromise, such as with the menu bar (again, a discoverability problem), sometimes you cannot (if tab completion is fundamentally incompatible with newbie-support). Incidentally, lots of those things have been solved by supporting both styles and using preferences to switch, and while not a perfect solution, it might well the achievable optimum. > using the GIMP altogether for a while; I used Cinepaint or xv (!) > despite it being obsolete in many ways where I could, and otherwise > started a new instance of the GIMP each time I had to use it, because > dealing with the file dialog was so hopeless. Eventually after poking > around Google I found the ctrl-L hack, but it's still very clumsy > compared to the simplicity of a text entry box. This experience is close to mine, and close to the experiences of the people around me. It seems sven's standpoint is that this just needs to some more experience, or learning the new way of using the dialog, but I have to use those dialogs for quite some time now, and I simply don't believe that I am too dumb or too stubborn for the new dialog, but that it's simply slowing me down at best. > Bookmarks are of no use to me because I have a lot of files that I > work with whose names I generally know by memory. [Agree with all of that. The great thing is, however, that bookmarks don't seem to collide with a text entry, so one could have both, which is just great, and a win-win situation]. > Anyone who tells me that I should organize my files differently > will be told (politely or otherwise) to fsck off. The irony is that one gets told that the old way would be somehow inferior without any evidence and lots of evidence to the contrary. It's new and completely different, so it must be better. > frankly I can't believe what I see there (e. g. file dialogs should go > away, and everything should be done through the file manager or some > such). This is design for its own sake rather than design for what's > actually usable. A lot of people feel that way. > I have half a mind to do a fork of GTK+ just to fix the file dialog. > This would really be an insane thing for me to do. Yes, it would :( It's a waste of time. -- The choice of a -==- _GNU_ ==-- _ generation Marc Lehmann ---==---(_)__ __ __ [EMAIL PROTECTED] --==---/ / _ \/ // /\ \/ / http://schmorp.de/ -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.ber
Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP
On Wed, Jun 22, 2005 at 10:12:05AM +0200, Sven Neumann <[EMAIL PROTECTED]> wrote: > This is not about making you and Marc shut up. This is about designing > a user interface that works for the majority of users. Whatever we do, > there will always be someone complaining. I don't really care who that > is. That is, I think the fundamental flaw. A user interface that works for the majority is a pretty idiotic goal. A user interface should work for ALL users, and likely should have features to support the majority. The simple goal of "works for the majority" is nothing short of a dictatorship (while in a democracy the majority rules, the fundamental point of democracy is minority rights). If that *were* the goal, why have things like ATK, which are decidedly not for the majority? And who decides what the majority is? The newbies? I am not sure newbies are the majority of gimp users (but I am pretty sure at some point in ther future this will be the case). So that argument is *completely* and *utterly* bogus, firstly because you equate majority==newbies, and secondly because it's not a viable goal at all. > > And why is it so important that there be a concept for the entire > > dialog beyond "what works best for people"? The problem (to me, and > > I daresay to Marc) is very simple -- there's no obvious way to > > simply enter a pathname with a simple form of completion that's only > > activated on demand. A file dialog without this is just plain > > fatally flawed. > > The problem is to find out what works best for people. Trying to > decide this in an argument among developers is very certainly going to > fail. I disagree, and I haven't actually seen evidence of that, despite hearing that a lot, I don't think developers are somehow worse off then users. Despite, I am unfortunately a mere gimp _user_ right now. This is basically the same argument, where you exchanged "the majority" by "people", and it has the same flaws. I _am_ part of that "people", as are you and other developers. The easiest way to find out is to try it, and see how it works. This is currently what's being done, and you can't complain about the negative (and also positive) feedback, so it seems to be the correct approach. > > Make it a configuration option, if you like. > > No, I don't like configuration options, I hate them. Others would love them! (In most cases there are unavoidable, wether it's themes or keyboard layout. Some people simply have different preferences. And while you hate preferences some people would be rather better of with them). > And it would also not have to be me who adds it but the GTK+ > developers. We are certainly not going to fiddle with the internals of > the GtkFileChooser widget. Yes, the discussion has become a little bit out of bounds for gimp-developer again. Just remember that the original problem was the attitude of yours with regards to user complaints (or suggestions). > > despite it being obsolete in many ways where I could, and otherwise > > started a new instance of the GIMP each time I had to use it, because > > dealing with the file dialog was so hopeless. Eventually after poking > > around Google I found the ctrl-L hack, but it's still very clumsy > > compared to the simplicity of a text entry box. > > I agree that the Ctrl-L is clumsy and I would like it to be removed > (of course after it has been completely obsoleted). But you don't > really need Ctrl-L to use the dialog. I am sorry that you made your > first experiences with the new dialog with the early versions that > were indeed rather akward to use. Well, it's not as if this has fundamentally changed till the current version. You seem to relate all the bad user experiences to old versions, but that is not true. I based my initial response on gtk+-2.6.7, and now used gtk+-2.6.8, which is exactly the version you asked people to try. -- The choice of a -==- _GNU_ ==-- _ generation Marc Lehmann ---==---(_)__ __ __ [EMAIL PROTECTED] --==---/ / _ \/ // /\ \/ / http://schmorp.de/ -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gtk file choser widget
On Thu, Jun 23, 2005 at 12:24:24AM +0200, Sven Neumann <[EMAIL PROTECTED]> wrote: > > developers removed it. Why is something removed that is apparently > > useful to a lot of people and is no problem for someone who does not > > want to use it? > > Because it isn't needed. You can still enter the filename and without > the entry it is easier to keep your eye focused on the list while you > are doing that. My experience shows that I need less keystrokes to > select a file with the new dialog. How are we to interpret that? You use more keystrokes because there is an additional widget on the screen? Or is this just the general "the new dialogs are good, just believe me" slogna? -- The choice of a -==- _GNU_ ==-- _ generation Marc Lehmann ---==---(_)__ __ __ [EMAIL PROTECTED] --==---/ / _ \/ // /\ \/ / http://schmorp.de/ -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP
On Wed, Jun 22, 2005 at 11:53:18PM +0200, Sven Neumann <[EMAIL PROTECTED]> wrote: > > That is, I think the fundamental flaw. A user interface that works for the > > majority is a pretty idiotic goal. A user interface should work for ALL > > users, and likely should have features to support the majority. > > Yeah, of course. If it works for all users, that's even better. Are > you trying to make an argument out of this now? Are you trying to argue? Maybe there is hope for you then, although the above is not an argument. It's better than activey ignoring what people write. > > So that argument is *completely* and *utterly* bogus, firstly > > because you equate majority==newbies, and secondly because it's not > > a viable goal at all. > > So let's see then. The goal is to please you and ignore the majority? You have weird ways of deliberately misinterpreting and twisting other persons words. What does it buy you? Time? Ignorance? Shying away people? > Developers are also users. But the same argument holds true for users. > You can't find out facts about a user interface by discussing it. Yeah, that should work, except here, as you immediately drive ad-hominem attacks and spread FUD (again...). I don't think it's even remotely possible to really discuss these issues with you. > at any discussion out there. It is always a few people who are very > loud at complaining. Are these users representative? No, they aren't. You jump to conclusions. Maybe they are, maybe they are not. But I already said that designing just for the majority is an idiotic goal, one that gtk+ certainly _does not follow_, so telling me that that goal would be a good goal contradicts reality. > agree on. But that is not the case here. So, that's why I have made > the offer of organizing a usability test with the goal to gather some > facts on the current design compared to whatever we can come up with > as an alternative. Feel free to ignore that offer. Well, I certainly didn't ignore it, and unfortunately you know that. > But if you do, don't expect me to ever discuss user interface issues > with you again. Yes, we *know* that your goal is to talk down and ignore this issue. Hint: you did succeed again. > The original problem was you accusing me of ignorance. That has been > proven to be a lie. So please don't continue with it. Just because you claim something doesn't mean it is proven. Sorry, but that really is what I think is happening. It's far from being a lie. > Still you failed so far to give a detailed and useful description of > your problems. That's another of _your_ lies. Sorry to use that word, it's really not appropriate, but aybe if I talk in your language communicaqtion improves? I even pointed you to working code that exactly reproduces the desired behaviour (but it's not gtk+2 compatible, if you meant that. And if you meant that, say so). > You listed a few things but you never got further than > half a sentence on each of them. Another of your lies. You tactics is very simple: people complain and explain, and you accuse them of not explaining and lieing. Then people explain some more (because they have no idea which part of their explanatiomn you didn't understand) and then they get some more accusations. In the end, you simply ignore them in good shape, as you always tried to discuss, it's always the others who play bad and fail to explain their issues. > I still don't know what your complaints really are but You should certainly know *that* by now, even if you might miss some details. If you are really that dense, then for your sake just *ask* instead of just producing more accusations. Just because you don't understand something does _not_ mean people tried hard to explain it. Just review tis thread. But as your goal is not discussion but ignoring others (for whatever maybe understandable reasons), this only drives people away again, with no resolution for either side. It's just too frustrating to explain things again and again and be told to stop whining and start explaining things. > that you want the text entry back. Well, at least that part got through. > A useful complaint includes use cases, describes a > certain workflow and outlines where the current UI gets into your way. This has been done multiple times. You keep ignoring this and ask for it. Maybe you don't receive all of the mails from this list? In any case, I just tried to point out to you that you factually do ignore this kind of discussion (in a very active way, actually, but nevertheless), but you still don't get it. I won't intrude further into your world, as all I wanted to do has been done, even though I couldn't get through to you like so many others couldn't. "I am out of here again" -- The choice of a -==- _GNU_ ==-- _ generation Marc Lehmann ---==---(_)__ __ __ [EMAIL PROTECTED] --==---/ / _ \/ // /\ \/ / http://schmorp.de/ -=/
Re: [Gimp-developer] Lanczos algorithm funnyness?
On Sat, Nov 19, 2005 at 02:18:03AM +, "Alastair M. Robinson" <[EMAIL PROTECTED]> wrote: > >But still, its clearly a faulty algorithm... Quite serious as well(?) > > This might be a silly question, but why is GIMP using interpolation at > all when reducing images? > > Shouldn't it be doing weighted averaging of all the source pixels that > contribute to a destination pixel? Weighted averaging is a way of interpolation. Regarding the original image, though: at least imagemagick produces a sharp image without any artifacts when using lanczos, so maybe there is a problem. -- The choice of a -==- _GNU_ ==-- _ generation Marc Lehmann ---==---(_)__ __ __ [EMAIL PROTECTED] --==---/ / _ \/ // /\ \/ / http://schmorp.de/ -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] writing customized GTK interfaces
On Wed, Jul 18, 2001 at 04:32:09AM +0530, Deepika Sikri <[EMAIL PROTECTED]>
wrote:
>Any help reg writing customized GTK interfaces in PERL for GIMP will
>be appreciated.
Basically, it works by NOT using Gimp::Fu. If you don't need arguments
then you can call the register function, which will not open a window
but instead will just call your plugin (e.g. examples/parasite-editor or
gap-vcr).
If you want arguments then it works very much like a plug-in in C:
# register a function that's called when
# gimp requests execution for it from this plugin
Gimp::register_callback plugin_mine => \&plugin_mine;
# gimp only clals us when we tell it which functions
# we implement
Gimp::on_query {
Gimp->install_procedure("plugin_mine", see Perl-Server for an example)
};
# optionally, you can define more callbacks:
Gimp::on_run { # optional
# run before any callback
};
Gimp::on_net { # optional
# when started from the network
};
Gimp::on_lib { # optional
# when started using the direct interface
};
# that's mandatory ;)
exit Gimp::main;
Inside your casllback you have to chekc the first argument (run_mode) as
usual. If you want to open a gtk dialog you should use call Gimp->gtk_init
instead of Gtk->init, because the former fetcvhes the corretc values
(ccube, visual etc..)
>Thanks in advance.
if you have any questions feel free to aks them ;)
> The Information contained and transmitted by this E-MAIL is proprietary to
> Wipro Limited and is intended for use only by the individual or entity to which
I pity you...
> recipient, you are notified that any use, distribution, transmission, printing,
> copying or dissemination of this information in any way or in any manner is
> strictly prohibited. If you have received this communication in error, please
and all this to a publicly arhcived mailinglist.. ;)
--
-==- |
==-- _ |
---==---(_)__ __ __ 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] glib/gtk+ 2.0 port
On Wed, Jul 25, 2001 at 07:43:12PM +0100, Nick Lamb <[EMAIL PROTECTED]> wrote: > * Can you 100% guarantee that Gtk+ HEAD builds and runs? > If not, every time it's red we stall work on Gimp. That's no good. There is cvs, so knowledge about "HEAD doesn't work, try last week's version" will spread soon through developer circles. I think that the work of porting now is less than the work of porting after a release IF the head version really is as stable as Michael says. I take his word for that ;) > * Can you 100% guarantee that APIs are frozen? Of couse not, not even with gtk-1.2. > How about ABIs? Get broken all the time. Sidenote: To make confusion worse, neither gimp nor gtk (nor glib AFAICS) use proper version numbers. Instead of encoding the ABI version (as is common standard with ELF) they all just encode their "public" version number, which is useless with respect to ABI changes. > If not we have to screen out errors caused by mis-matched versions on > a daily basis just as some projects did during 1.1.x. It is painful. Hmmm... -- -==- | ==-- _ | ---==---(_)__ __ __ 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] glib/gtk+ 2.0 port
On Wed, Jul 25, 2001 at 03:43:51PM -0500, Kelly Martin <[EMAIL PROTECTED]> wrote: > If you have to use a "development" version at least pick a fixed point > in development and use that. Otherwise you're coding to not one, but > two moving targets: your own code PLUS the moving code in the library > you depend on. Or, in this case, five. > > If your goal is to make development as chaotic and difficult as > possible, you are on the right track. I am sorry, but what you describe is reality for most plug-in authors. Did plug-in developers develop for gtk-1.0 and gimp-1.0 a year ago? It's more of a social problem: do we *trust* the gtk development model to be stable most of the time? I did trust the gimp developers that they want working code as well, and it worked fine. If gtk+ is as chaotic as you think it is, it is evry bad and gimp shouldn't use the HEAD revision. -- -==- | ==-- _ | ---==---(_)__ __ __ 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] glib/gtk+ 2.0 port
On Wed, Jul 25, 2001 at 04:40:41PM -0500, Kelly Martin <[EMAIL PROTECTED]> wrote: > Why should we expect the GTK+ developers to keep their HEAD revision > compilable at every moment? because that's what they do, what gimp does, what every other project does. if the head revision isn't compilable nobody can wotk with it. > That is a completely unreasonable It's completely reasonable ;) > expectation in the first place. If I were a GTK+ developer I would be > asking that you NOT do what you're proposing because it creates I am not proposing anything. > in the GIMP (which it probably is not), I would strongly urge picking > a relatively stable snapshot of GTK+ current development (possibly, > but not necessarily HEAD today) and use that. We might have to adjust > later to any changes GTK+ makes to its HEAD after that snapshot, but > at least we won't have to adjust to them willy-nilly as they make As sven has said, they made an API freeze recently. That means they are already pretty late in the development phase. I think it's totally unreasonable to expect non-compilability on a regular base. How often couldn't you compile gimp-1.1.2x? -- -==- | ==-- _ | ---==---(_)__ __ __ 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] glib/gtk+ 2.0 port
On Wed, Jul 25, 2001 at 11:18:58PM -0500, Kelly Martin <[EMAIL PROTECTED]> wrote: > sufficiently large y. We bumped y as it became necessary. The HEAD > revision was only occasionally required, and usually only for a short > time until GTK+ released a new unstable version. so what? nobody requires the head revision all the time. please calm down! if you think about then you'd see that "requiring the head revision" as you interpret it makes no sense. > I don't know what "every project" you've worked on. Probably because I didn't mention any. Why should I? Am I required to work on a project before I can tell which libraries they use? > This is a completely INSANE model for any project of any size that wants > to actually get anything done. It works fine, thank you. Do you have any _reasons_ to object, apart from not personally liking that model? > (Of course, project leadership in most open-source projects is almost > completely nonexistent You really escape me here. Project leadership is quite strong in most open-source projects IMHO. Gimp is the exception, and worked exceptionally well so far. To the contrary, many projects with strong leadership (glibc, gnome, even gcc althoguh I am not that sure about strong leadership ;) had a lot of problems. Look at all the BSD projects. > reason why GIMP development has to be that way. It wasn't in 1.0, at > least. I wasn't as involved in 1.2.) I don't think the pre-1.0 "development model" (if you could call it a model) is a goal to go for, actually. > > if the head revision isn't compilable nobody can wotk with it. > > Which is precisely why GIMP developers should not rely on it. GIMP > developers are developing GIMP, not GTK+. GTK+ is gimp's toolkit, and breaking ties even more than already is the case is a bad thing for both projects. > If an individual developer WANTS to work with the head revision, > that's fine, but development should not REQUIRE it, why? > should be wary of introducing dependencies on features not yet > stabilized. why do you think they aren't? why do you not trust mitch? > You should require the OLDEST version that suffices, not > the newest. but that might well be the current head revision. your logic is this: we could write gimp using motif and it is stable. let's not move to gtk. progress can only be made by using newer gtk and esp. glib versions. what yo you expect from developers: develop a second glib because glib itself is not released yet, or just plain WAIT until it comes out so they cna finally make progress? > usage of GTK+.) Application authors should NEVER assume that their > users like to live on the cutting edge. Are you remotely aware of the fact that we are talking about development versions here? Obviously not. EVERY free software project progresses by using other people's work. Otherwise linux would still require gcc-2.5.2, gimp would sitll require motif and Xfree would still have no 3d. > Most users do not. Most users use unstable alpha versions of gimp? Hello? > upgrade the Linux systems that I'm paid to maintain when something > breaks, and we should not force users to upgrade a nonbroken library > unless the upgrade provides essential (or at least strongly desirable) > functionality. Hello? Development version? > >totally unreasonable to expect non-compilability on a regular > >base. How often couldn't you compile gimp-1.1.2x? > > I broke 0.99.x and 1.1.x on several occasions. Too bad. Nobody would veer had found out if there weren't some savy users out there who, indeed, like to be on the cutting edge and used unstable development versions of gimp. -- -==- | ==-- _ | ---==---(_)__ __ __ 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] glib/gtk+ 2.0 port
On Thu, Jul 26, 2001 at 12:01:35PM +0200, Michael Natterer <[EMAIL PROTECTED]> wrote: > Porting GIMP to Gtk2 will need a substantial amount of time and hacking > and if we'd start it _after_ GTK 2.0 is final, we will need another 12-24 > months until it's stable. In addition, gimp is a very nontrivial application. Porting gimp before gtk-2.0 makes it possible to correct problems in gtk+, if there are any. afetr 2.0 is released it's more difficult. -- -==- | ==-- _ | ---==---(_)__ __ __ 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] RFC: support for multi-image files and API change for load/save plug-ins
On Tue, Aug 07, 2001 at 05:28:15PM +0200, Raphael Quinet <[EMAIL PROTECTED]> wrote: > 3) Changes to the plug-in API > > The File->Open dialog would behave as follows: if the given path leads > to a regular file, open it as usual (no extra path). If the path does A loong time ago I hacked the gimp to allow a variable number of arguments in pdb calls - if the code still works then it's already possible to call functions with a variable number of arguments. Each plug-in gets the actual number of arguments so it's a matter of checking it to see wether an extra argument exists. > In order to support this, the file_load/save API has to be changed by extended, only, even ;) > file is edited. The only thing that would have to change in the > current plug-ins is the addition of this parameter that would be > ignored. Even if we didn't have variable-number-of-args, the gimp itself knows how many agruments a plug-in takes and could act accordingly, i.e. by not passing in more argument than neccessary. > 4) Feedback > > Any comments? I just looked at gif.c, it does this: if (nparams != 9) in the noninteractive case, which nobody cares about and leaves the interactive case untouched (i.e. it doesn't check). The same is true for pnm.c. I only expect problems with the non-optimal plug-in load/save data api or maybe something obvious that I miss, but it would be sensible to call plug-ins interactively with other arguments (or specially pre-populated agruments) than in the interactive case - the api already allows all this, I think. The noninteractive part is much more difficult (in that it requires sourcecode changes), but we could actually use the argument names (this is off-topic). This might sound ugly in C, but most scripting languages (e.g. perl) actually have functions which accept many arguments. The key is not to use them but default them sensibly: new Coro::Socket PeerHost => "gimp.org", PeerPort => 80; and the many other arguments get sensible default values (like Multihomed => 1). In the long run, we need to use this approach anyway (think all the nice gimp functions with waaay to many arguments). -- -==- | ==-- _ | ---==---(_)__ __ __ 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] RFC: support for multi-image files and API change for load/save plug-ins
On Wed, Aug 08, 2001 at 01:54:53PM +0200, Raphael Quinet <[EMAIL PROTECTED]> wrote:
> No, using a special protocol in the URI will not work, because it
then how about appendign a space and then attr=value pairs? spaces are not
valid in uris. other options incldue { } or other characters not allowed
in uris. or 8 bit characters (still not allowed in uris etc..)
> should still be possible to retrieve the file using any protocol such
> as http: or ftp: (the only difference being that you only use a part
> of it).
the question is, could it hurt us doing things like this:
of course, there is a user interface issue: users like to enter broken
uris (usually a cut&paste issue).
> and the extra path to the image. I initially thought about this and
> then rejected the idea later because local files can have a "#" in
> their name
wenn, if we insist on uris in the api this is not a problem as # must be
escaped. but it's bad because of other reasons: # makes sense for http
uris (e.g. xpointers!) already, so we would have this:
http://...#fragment#subimage
or
http://...#subimage#fragment
both of which are "wrong".
> anything after the "#" before sending the request, and then interpret
the problem is that "#" is not nestable. and the file system layer might
want to use it itself.
--
-==- |
==-- _ |
---==---(_)__ __ __ 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] RFC: support for multi-image files and API change for load/save plug-ins
On Wed, Aug 08, 2001 at 05:05:23PM +0200, Jens Lautenbacher <[EMAIL PROTECTED]> wrote: > > the problem is that "#" is not nestable. and the file system layer might > > want to use it itself. > > Hmm? No. Fragments are interpreted by the UserAgent. so, who is the user agent, gimp or the gimp? the file system layer is part of the gimp, for sure. -- -==- | ==-- _ | ---==---(_)__ __ __ 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] RFC: support for multi-image files and API change for load/save plug-ins
On Wed, Aug 08, 2001 at 05:22:44PM +0200, Raphael Quinet <[EMAIL PROTECTED]> wrote: > and then interpret it locally. As far as I know, there is nothing > that prevents the URI from having one or several "#" in the fragment Except rfc2396, which specifically disallows this ;) > The other characters that Marc proposed (spaces or 8-bit characters) > are not valid in URIs and their behavior is undefined (they should be > url-encoded) That's the whole point, that they are not valid in URI's and as such it's not possible to find a URL that would clash with our definition. Using "#" means that common URI's to find documents (including "#fragment") might suddenly clash with gimp, since the gimp interprets "#" as the image component. Here is how I see it: - "#" precludes using fragments to subselect ressources, since only one "#fragment" is allowed in an URI. - "#" is the natural thing to choose sub-objects - other characters thta are not valid in a uri make this unamigious - other characters are unnatural Another option would be ot use something like this: ...#gimp(name) ...#gimp(subimage=name) ...#subimage(name) ...#entry(name) ...#image(name) or soemthing alike, which would make our fragment identifers coexistent with other fragement identifiers. (and soemwhat off-topic: the uri definition with respect to characters is a single bug: it requires character sets that are strict (bytewise!) supersets of ascii and, worse, gives no possible way to interpret it. so I say that using "#" twice, even if forbidden would not be a problema t all ;) -- -==- | ==-- _ | ---==---(_)__ __ __ 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] RFC: support for multi-image files and API change for load/save plug-ins
On Wed, Aug 08, 2001 at 07:49:54PM +0200, Jens Lautenbacher <[EMAIL PROTECTED]> wrote: > > so, who is the user agent, gimp or the gimp? the file system layer is part of > > the gimp, for sure. > > Hello? The FS or a web or a ftp server is the "Server" conceptually. > The UA (gimp) loads the whole Document (a file maybe containing > multiple images) and interprets the fragment identifier locally -- i assumed that gimp does have a file-system layer. or otherwise who handles "paths" that really are urls for example? will every plug-in implement it's own http:// parsing+fetching? no, i guess gimp handles this, the file system layer within gimp, specifically. > The uri would only clash if there are UAs who already have some > widely accepted meaning for a fragment id in e.g. an animated actually, it's dependent on the media type. and my concerns are not about compatibility to current browsers or servers but in the future. it would be bad if gimp became successfull and would create/user uri's internally that cnanot be parsed by other programs (not even like: "oh, i can't parse this"). my suggestions make them unambigous. > that they would use the FID much the same way and not for > e.g. addressing a coordinate in the image (or any other random stupid > thing one could think of) well, xpointers are quite new and use their own "namespace", and i think that's for a reason. gimp should also use it's own namespace. yes, it might not make a difefrence in the future, but I expect the difefernce between path and uri to go away completely in the future, and it's betetr to be safe and sorry then. -- -==- | ==-- _ | ---==---(_)__ __ __ 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] RFC: support for multi-image files and API change for load/save plug-ins
On Wed, Aug 08, 2001 at 06:52:39PM +0100, Nick Lamb <[EMAIL PROTECTED]> wrote: > That creates an equivalent problem to your original one. If you really > want gimp-devel to believe that you routinely load remote WAD files > from HTTP then I'm going to have to ask that they also believe that users > routinely create files called foo.wad#Q/S_SKY1 Well, gimp should not work "routinely" only (at the moment it does with respect to the plug-in api, and everybody agrees that this is a bug that will be fixed eventually). Also, invention does not come from limiting ourselves to the common case. otherwise i think out-of-band information might be better in the end. or use fragment identifiers ina sensible way. I also think that uri's and the user interface should be seperated, i.e. the user should rarely be bothered to enter plain uris, as most people don't understand the rather complex syntax (most html writers don't, for example, so i don't epxect gimp users to do). so there must be some translation layer between user input and internal paths. which in essence means we are not limited to uri's that look nice, but can implement the right thing. > users being able to save their Doom textures back into the WAD. With > the wad:// URI scheme and associated interactive browser we can make The wad uri scheme sounds backwards to me. like file uris, there is no inbuilt access method available for wads. (i mean, this looks like gif:// jpeg:// and so on). > Raph, don't let me stop you if you're sure this is the Right Thing, > but maybe you should consider bolting Doom itself into Gimp, so that > we can just use weapons/ tools to retexture things from inside the > game and see the results instantly? :) ;) at least we should loudly think about the issues. i mean, nobody talks about the enw gimp core, or... so let's discuss the _really_ important topics ;) (I must admit i am quite picky about uri/url/protocol issues since they bite me every day). -- -==- | ==-- _ | ---==---(_)__ __ __ 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] RFC: support for multi-image files and API change for load/save plug-ins
On Thu, Aug 09, 2001 at 12:42:33AM +0200, Jens Lautenbacher <[EMAIL PROTECTED]> wrote: > yes of course, but where's the difference in our problem here? that the user agent is the gimp and might interpret fragment identifiers - at leats some underlying library might (and should) do that. my point is that we shouldn't just claim fragment identifiers as being "plug-in namespace". > why should any future app that groks uris be unable to parse > these??? > > http://www.mozilla.org/images/mozilla-banner.gif#eeek > > when I type this in a web browser, there's no problem. There's in fact > no problem with any app that correctly handles uris. Wrong. Some app might validly try to interpret eeek as something strange. for example, some (bad) app might want a number there and might display nothing. For some deifnition of correct this is correct, but... The problem is that nobody knows how to interpret that "eeek" except the gimp, and using a more verbose form at leats might give a clue that a subimage with name is meant. > And not only does it not make a problem, the outcome is also the > expected --- it loads the gif. You are arguing backwards. That current technology is quite low-level does not mean that it won't improve in the future. You are arguing that ua's basically thwo away fragment identifiers on images, which is the case currently, but I don't think that's what people want. I mean, the fragment identifier is there for some reason so ignoring it is not nice. > GIMP on the other would maybe throw a warning for this uri, as there's > no "subimage" of any sort in this gif. But that's just the added value > we get because we decide what a fragment means for e.g. a wad file. Indeed. Why not do it as others and mark our namespace with something like subimage(xxx) or gimp(xxx)? > As the "meaning" of a fragment is left to the media type (and the UA) > there will just _never_ be a problem. Sorry, I really cannot follow you here. When that logic is applied to, e.g. URI's or form data sets I get this sentence: "As the 'character set detection' of a URI or form data set is left to the server, there will just _never_ be a problem." Sorry to disagree, but I think that's just plain backwards: we need _less_ ambiguities, not more. -- -==- | ==-- _ | ---==---(_)__ __ __ 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
[Gimp-developer] Thoughts on CMYK, and getting it without implementing it.
Sorry that it took so long, Simon ;)
Anyways, I had some conversation with two graphics designers about CMYK
problems and the Gimp at the Systems, and I think it might be worthwhile
to read the following "sometimes true" observations. Remember, they are
hearsay ;)
1. "colour matching for photos is a don't care". Ok, this is a blatant
lie, however, exact colours are not that much of a concern for
photos. Much more important are logo colours (most companies have
pretty strict definitions of these). If a photo doesn't exactly
match the screen colours ("which screen colours, anyways") this
is often not a reason to not use gimp. If a logo colour can't be
reproduced, however, it keeps Gimp from being used.
2. "Logo colours are not CMYK". Yupp. Logo "colours" might not be
representable in CMYK at all (gold etc...). Even if, you often (but
not always) want seperate planes for important colours.
Most uses of spot colours want the concept of an "indexed channel",
i.e. a channel where each value represents a different palette
colour. No bleeding with image contents.
Gimp's channels can be used instead, which is not that perfect for
all uses, but exists and at least photoshop doesn't offer a better
solution ;) They also allow gradients of a single spot colour, which
indexed channels wouldn't allow. Wether all this makes them easier
or harder to use is something to explore.
3. "You don't print from within the gimp". At least you don't print
brochures from within the Gimp. You use gimp for artwork, often the
logos, but you obviously don't set text using the Gimp. You instead
import images into some layout program (quark xpress ;).
I was told that the principal reason for bad quality of gimp
images within quarkxpress is that quarkxpress imports gimp's rgb
tiffs like garbage. I was told that loading the rgb data into
photoshop, associating sRGB with it (changing _nothing_ else)
improved the quality very much, making the results reproducable on
printers. Without absolute colours, they look different.
4. "Cheap CMYK vs. RGB makes a difference". Many programs also seem
to have problems ("looks like shit") with RGB data, not because it
isn't associated with a colourspace, but because it's RGB. Cheaply
("formula") converted CMYK data seems to help a lot here. That
CMY has an additional K is of no concern - users don't sue this
additional level of freedom,
Things like trapping are handled by other programs or by very
expensive photoshop plug-ins.
5. "Logos are done by overlays". At least one method of using spot
colours is to create them as seperate channels. Tiff/Eps are
reportadly able to save additional channels in a way that a program
can read them sensibly.
The spot colour "planes" are then laid over the other graphics. For
this to work a mask is necessary, since channels range from white
(not transparent) to "channel colour", at leats in quarkxpress.
It seems that traditional masks are not what's called for - instead
you want a path saved in the tiff/eps file (don't ask me wether that
is possible). This clipping path is then used for the overlay - gimp
can't create this kind of paths, nor can it save it.
CONCLUSIONS - THE 60% WAY TO CMYK
If one were so bold as to draw some conclusions, they would probably be very
similar to these:
1. Enhance the tiff/eps save plug-ins to do cheap RGB->CMYK conversion. This
would work around conversion problems in other programs.
2. Associate sRGB or any other colourspace with the saved data in
tiff/eps. It doesn't matter wether it's true or not, just give
programs something to depend on.
3. Educate users about channels and what they can be used for - on this
Systems I was frequently confronted with users who were unhappy with
the gimp because it didn't allow them to do things as easily as under
photoshop. Often(!) I was able to get exactly the same results, with
a much easier and faster sequence than the one that user used with
Photoshop.
This could be a start, to work around bugs in other programs. Also
relatively cheap, unlike the following:
4. Find out wether saving paths as paths as opposed to masks is really
required to do overlays in common layout programs. If yes:
4a. enhance the path tool to be able to work with generic paths (holes,
multipart etc.).
4b. enhance the tiff/eps plug-ins to be able to save these paths together
with channels.
4b. (optional) make tiff/eps save images together with their channels in
the same file.
5. Implement "indexed channels", or somethign else that makes handling spot
colours easier. An easy way is to use one channel for each spot colour.
Re: [Gimp-developer] Thoughts on CMYK, and getting it without implementing it.
On Thu, Nov 29, 2001 at 03:17:51AM -0800, Jay Cox <[EMAIL PROTECTED]> wrote:
> > pretty strict definitions of these). If a photo doesn't exactly
> > match the screen colours ("which screen colours, anyways") this
> > is often not a reason to not use gimp. If a logo colour can't be
> > reproduced, however, it keeps Gimp from being used.
>
> You should not create a logo requiring "Logo Colours" in a program such
> as photoshop or gimp. You will get superior results using a vector
> based application such as illustrator.
That's what I was told, too (together with: many people do it with
photoshop anyways ;)
> Sometimes you will need to match a logo captured in a photograph to a
> specific "logo colour" , but the first step would be to convert your
> photograph to CMYK.
But how critical is that process? Do you think that my main point - cheap
conversion to cmyk in the tiff/eps-plugin(s) - would really ease life and
would enable gimp to enter prepress world (even if not at all perfect)?
> "Logo Colours" (aka spot colors or PMS colors) can already be used in
> gimp if you are only using one ink at a time. Just save your image as a
> grayscale tiff and place the image in quark using whatever ink you want.
What about the clipping path, though? I'd guess you want to overlay these
layers often.
> are not usualy working with a logo. Usually you are trying to match a
> color in a photograph that is not representable in the CMYK color space
> Any image that you would want indexed "Logo Colours" for would be better
> off handled in a vector based program such as illustrator.
I was told that trapping can be done with expensive plug-ins for photoshop
only, which would make sense, since trapping is (AFAICS, no idea actually)
not really well-defined for photos, what users would buy such a trapping
plug-in for photoshop?
> In my experience people don't use gimp (or photoshop) for logos
> (I mean for print work, of course the web is a whole different story)
But gimp already works fine for the web, so that's a problem ;)
> I am not certain, but I think that the rgb->cmyk conversion is not done
> by quark, but by the postscript rip when you print your file.
That would nicely explain why it "looks like crap".
> setting the colour profile to sRGB in gimp is the wrong fix. There
> should be a setting on either quark or the rip that tells it what color
> profile to use for images that have no assigned profile.
Unfortunately, users usually don't have control over the rip. I guess
whatever rip is used just uses it's defaults for RGB. quark is a difefrent
story - what if quark doesn't have such a setting?
But I think that acse would be rather irelevant once we have CMYK in tiff.
> > can't create this kind of paths, nor can it save it.
>
> The industry standard way of saving raster files that have spot channels
> in them is the DCS file format (A very close cousin of EPS).
I knew eps couldn't do it (directly ;).
Ok, prepare for:
REVISED CONCLUSIONS (ordered my importance).
1. implement CMYK saving in tiff and eps.
2. enhance tiff(?) & eps to save all channels & paths in whatever format
is actually understood (DCS for eps). one path must be marked as
clipping path (e.g. by name "Clipping Path" or by some parasite
(gimp-clippath on the image containing the ascii form of the path
tattoo or somesuch).
3. (optional, but important) finally enhance the paths to be multipart,
contain holes etc. simon? smoon? ;)
--
-==- |
==-- _ |
---==---(_)__ __ __ 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] Re: GIMP Tip of the Day messages
On Sat, Oct 06, 2001 at 07:33:28PM +0200, Sven Neumann <[EMAIL PROTECTED]> wrote: > have done it before. I can see at least one more advantages of using an > external file: The tips don't stay in memory all the time. So we should > probably go for it. (just a sidenote: if tips were compiled-in and large enough for this to be relevant, they would still not stay in memory all the time. guess that the parser would take up more memory ;). -- -==- | ==-- _ | ---==---(_)__ __ __ 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
