Re: [Gimp-developer] Question about bundled "iBryte" GIMP installer
On Thu, Jul 14, 2011 at 4:55 PM, Chris Mohler wrote: > 2011/7/14 Christopher Curtis : >> >> This may not be accurate. Current GIMP releases are GPLv3: > > Oops - guess I need to pay more attention while lurking ;) I thought > the GPLv3 switch was still in the works... Andrew didn't mention if the binary in question was a 2.6.x or 2.7.x so we can't be sure which applies. However, to try to answer Andrew's original question: The GIMP team doesn't officially release executables - only source tarballs - at http://www.gimp.org/downloads/ . As such, I think it's safe to assume that it is expected that others will compile and redistribute the resultant binaries. It's kinda crappy when people bundle spyware with GIMP, but they are free to do so as long as they comply with GIMP's license. Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Question about bundled "iBryte" GIMP installer
2011/7/14 Jernej Simončič : > On Thursday, July 14, 2011, 19:34:08, Andrew Brandt wrote: >> -- Are third parties permitted, according to your EULA, to bundle your >> product this way? > > GIMP is licensed under the GNU General Public License, version 2. The This may not be accurate. Current GIMP releases are GPLv3: http://git.gnome.org/browse/gimp/tree/COPYING?id=GIMP_2_7_2 And there remains an inconsistency between the GPLv3 and the LICENSE file: https://lists.xcf.berkeley.edu/lists/gimp-developer/2010-November/025875.html Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Example: Vala as code generator
On Mon, May 2, 2011 at 9:15 AM, Nicolas Robidoux wrote: One way of viewing the issue is: > > Do you want to cater to the programmers you want, or the programmers you > have? > (With the hope of turning the latter into the former.) > It's worse than that, even. This is a perpetual argument. People were railing against C in the 70s because people who weren't programming in assembler weren't intimate with the stack, heap, or registers. They hated the subroutine call inefficiency. They hated losing the ability to dynamically change executing code, or freely use instructions as data. Software development - all engineering, really - is about trades. C imposed a base level of inefficiency for a higher level of productivity. Today, C is a hindrance to even greater productivity (GObject itself is evidence of this). It's less useful to know how to write a hash table interface with its own unique API than it is to know how or when to use one. If a hash table is part of the language, then it becomes the One True Implementation and Everybody knows it and uses it, and does so mostly-correctly. FWIW, to me, Vala seems like a reasonable choice for GObject based systems. I don't think it's going to expand the developer base now because Vala prefers an understanding of GObject, which is little used outside OSS systems. The syntax should be familiar to C/C++/C# users, but the trade here is for productivity. While another language (C++, C# or Java) may have more developers, that language would require an object system be built around GObject, which just raises the question: "Why not Vala?" One would assume that a stable Vala compiler exists or is currently stable enough to use on all target platforms. Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [Bug 325564] Use CIE LCH instead of HSL for layer mode "Color"
How about: This patch seems to have been completed last year; there are no outstanding issues against it. What needs to be done in order for this to be integrated? Chris On Tue, Mar 15, 2011 at 3:47 PM, Charlie De wrote: > Why?? Rupert Weber finished this last September and you promised it would be > in > 2.8. Is this how you show respect for the most stellar effort by a new talent? > Shame, truly, shame on you. It's now been 5 years since the issue was first > reported, you're going to add another year even though the work is done. That > is, if you don't break your promise again. Where's your integrity? > > Charlie > > > > > - Original Message >> From: GIMP >> To: charlieco...@yahoo.com >> Sent: Mon, March 14, 2011 9:05:01 AM >> Subject: [Bug 325564] Use CIE LCH instead of HSL for layer mode "Color" >> >> https://bugzilla.gnome.org/show_bug.cgi?id=325564 >> GIMP | General | git master >> >> --- Comment #53 from Martin Nordholts 2011-03-14 08:04:28 >>UTC --- >> We really must release 2.8 now, let's look at this for 2.10 instead. >> >> -- >> Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email >> --- You are receiving this mail because: --- >> You are on the CC list for the bug. >> > > > > ___ > Gimp-developer mailing list > Gimp-developer@lists.XCF.Berkeley.EDU > https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer > ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Photoshop ?compatibility? mode
On Tue, Feb 1, 2011 at 4:00 AM, Alexandre Prokoudine wrote: > On 2/1/11, Christopher Curtis wrote: > >> interact on this list. One of which is the knee-jerk reaction >> whenever an email comes across with the word Photoshop in it. > > What you call "knee-jerk reaction" is the result of generations of > users coming and telling the team to just make GIMP like Photoshop or I recognize the root of the issue, but that makes it no less an issue. What may seem to you like bikeshedding seems to me like the immortal remnants of the Carol Spears hydra. I asked if anyone would complain about a patch that brings GIMP in line with every other program that I could find wrt using Backspace as color fill. One person objected, nobody said it would be a fine patch -- they'd rather complain about Photoshop users. Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Photoshop ?compatibility? mode
On Mon, Jan 31, 2011 at 9:39 PM, gespert...@gmail.com wrote: > And all this conversation is because you think CTRL+Backspace makes > more sense than CTRL+. (because you're used to that combination) and > you don't want to take 30 seconds of your time to personalize the > accelerators? By "you" are you referring to me? If I've used Photoshop it hasn't been in the past decade. I'm not saying any particular keystroke makes any sense whatsoever. It doesn't make any sense to me that keyboard shortcuts tend to assume the user speaks English. > A couple of days ago a voluntary coder (with an impressive CV) arrived > to this list offering his help and he only got a couple of replies. I would agree that there are problems with the way people tend to interact on this list. One of which is the knee-jerk reaction whenever an email comes across with the word Photoshop in it. Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Photoshop “compatibility” mode
Let me start off by saying that this conversion is exasperating, and this will likely be my last message on the topic. Firstly, let me define "peer group": Any set of applications that interpret data in a specific way and allows the user to view or manipulate said interpretation in any specific way. As an example, all applications which interpret data as pixel information form a peer group. Common features such as panning and zooming should be the same across all these applications. These groups can be broken down further into "viewers" and "editors". Editors can be broken down further into "raster" and "vector". And then "layered" versus "flat", etc. As application groups get more specific their shortcuts will by necessity diverge, but these peers should have more shortcuts in common than not. What does not matter within a peer group is what programming language the application uses, what libraries it uses, what the primary deployment platform is, what other applications someone may or may not use with it, or what license the application is distributed under. These are all immaterial to what the application _is_ or _does_ (which also defines who uses it). If there's confusion because I'm posting in a thread called "Photoshop compatibility mode" let me apologize for confusing anyone and clearly state that I am not suggesting this mode be adopted as the default mode for GIMP. I am also not suggesting blindly following "old Adobe products". However, it is equally a mistake to blindly follow "old GIMP products" when it's clear the rest of the world is moving to another set of default keybindings. The crux of my argument is simply that - regardless of what we've become used to - it is beneficial to all users - existing and future - to monitor default keybindings across peer applications and mimic each other where appropriate. I do like the page Alexandre put together on the Create wiki, but I do not like that closed-source applications appear to have been excluded. I don't want to diverge into a Free Software "Purity" versus Open Source "Practicality" debate but closed source applications are an important part of the software ecosystem -- if for no other reason than we're trying to provide a better alternative to them. And "better alternative" in no way, shape, or form means "clone". One example given - the idiotic Microsoft + shortcuts for cut/copy/paste - is a classic NIH problem, just like this might be considered to be. Maybe they thought they were saving DVORAK users (where +X,C,V isn't at all intuitive) when the rest of world had moved on to QWERTY, but now there are keyboards that have moved the key onto the row and doubled the size of the key! (Mine is one of these monstrosities.) The simple reality is that things get easier for users when common assumptions are shared. Some say that smart people learn from their mistakes; wise people learn from the mistakes of others. As to the GNOME HIG, that is a much broader topic. If the GNOME HIG has an entry that says "The 'R' key shall select the 'Rectangle Selection' tool", I would say that it is over-specified and doomed to failure. Note that I am not saying that it is the case that it is - just that it would be. However, if an application is intended to be cross-platform, it should conform to the conventions of that platform. Very broadly, that means on MacOS it should do the weird titlebar thing by default; it would do single window mode on Windows; Ok/Cancel conventions would match the platform; and as there really aren't that many expectations of what a *nix system looks like, it can pretty much be whatever - but should follow the GNOME HIG on GNOME and the KDE HIG on KDE ... ideally. And these HIGs should not have sections called anything like "Keyboard shortcuts for raster image editors". Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Photoshop “compatibility” mode
On Sun, Jan 30, 2011 at 8:51 PM, Liam R E Quin wrote: > I'm actually Ok with this. But we have to agree what we mean by "peer > applications" - I'd say gimp and inkscape are, for example, and not gimp > and photoshop. So your argument is that on the "Software Spectrum" GIMP is not a graphics application but is first a GNOME application. For the people who want, you know, to create GNOME. It just happens to create GNOME using graphics. That's sarcasm of course - you say that primary platform trumps application domain, and GIMP is GNOME because that's where it's hosted; a rather myopic and user-hostile view, IMHO. Most people don't care one whit about GNOME or where GIMP is hosted. They want software that is better than what they currently have, fits the way they work, and is relatively familiar ... which is going to lead down an ugly road. So let me ask you this instead: Are you going to oppose a patch that changes the GIMP shortcut for FG/BG fill to match PhotoShop's on the basis that Backspace does something completely different in GEdit? Or on the basis that GIMP is not a PS clone? Or some other reason? Or would you have no opposition at all? Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Photoshop “compatibility” mode
On Sun, Jan 30, 2011 at 1:33 PM, Liam R E Quin wrote: > Yes, perhaps it might be nice if the key to get the eraser was the same > in inkscape and gimp and blender and gedit and krita and mypaint, but it [...] I overlooked Krita. Krita uses as a BG Color Fill and + as a FG Color Fill according to: http://community.kde.org/Krita/Shortcuts MyPaint doesn't seem to have a 'fill' accelerator: http://wiki.mypaint.info/Documentation/Shortcuts So it looks to me like Krita and PhotoShop agree that + is FG Color Fill; Krita and Paint.NET agree that is BG Color Fill (with PhotoShop the outlier using ); and GIMP thinks that is good for nothing. Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Photoshop “compatibility” mode
On Sun, Jan 30, 2011 at 1:33 PM, Liam R E Quin wrote: > Yes, perhaps it might be nice if the key to get the eraser was the same > in inkscape and gimp and blender and gedit and krita and mypaint, but it > could no longer be "E" because that inserts text in gedit, so we'd end > up using conrtol-shift-e or something. But that's already Export in gimp > now, and what if it does something in Blender? I don't know if you're intentionally setting up a stawman here, but inkscape is a vector editor, blender is a 3D modeler, and gedit is a text editor. These applications aren't in the same domain as GIMP and MyPaint. Exercising my bad analogy skills, I would expect GIMP, MyPaint, and PhotoShop accelerators to all "speak" English, though one might be American, another British, and another Australian. Inkscape may sound a bit more like Jamaican and Blender would be German (or perhaps Navajo, since they don't even honor as help). So all I'm suggesting is that instead of simply producing PhotoShop keybindings (which is a fine idea, IMO) that an interested person actually look at the broader picture to see if there is any accelerator convergence among peer applications and propose bringing GIMP into alignment where it makes sense to do so. Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Photoshop “compatibility” mode
On Sun, Jan 30, 2011 at 12:55 PM, Rob Antonishen wrote: >> The world would be better if each application domain had a consistent >> set of core accelerators. File->New, File->Save, Cut/Copy/Paste, etc. >> are good for most all applications. For a graphics program, common >> tools like Pencil, Eraser, Move, Crop, etc. should have consistent >> accelerators. Accelerators can diverge where the application domain >> differs of course (e.g. raster versus vector editors) and where >> applications specialize (tablet support versus not), but within each >> sub-domain consistent cross-application accelerators would be better. > > But they don't. Maintaining legacy shortcuts prevents moving forward > with new features. What don't what? I'm not at all suggesting immutable accelerators - in the next paragraph I clearly state: "even if it means that accelerators occasionally change between versions." As one example (likely not the best one, I'm sure), GIMP uses +, for FG Color Fill and +. for BG Color Fill. I assume these keys are near each other on all keyboards... PhotoShop uses + for FG Fill and + for BG Fill. + pulls up the Fill Dialog. These seem like reasonable accelerators that don't conflict with GIMP's. I used this for reference: http://morris-photographics.com/photoshop/shortcuts/index.html Paint Shop Pro doesn't seem to have a "fill" accelerator, but it looks like Paint.NET uses : http://www.keyxl.com/aaad5b6/325/Paint-Dot-Net-keyboard-shortcuts.htm Confusingly, Ps uses unmodified as a synonym for . But based on my sample size of 3, one could say that there may be a convergence towards as having something to do with fills. This is hardly overwhelming evidence of anything, but if we as a graphics-software producing community can all agree that = "Fills", that will only help the users of our collective software. This suggestion isn't so much about cloning "competitive" software but of recognizing that graphics professionals may use many different (but similar) tools and the more similarity there is among them the better off they will be in producing their works. Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Photoshop “compatibility” mode
On Sat, Jan 29, 2011 at 9:12 PM, Liam R E Quin wrote: > On Sun, 2011-01-30 at 01:43 +0100, Bogdan Szczurek wrote: > >> The thing is, that we concluded that permamenet transition or even >> occasional use of Gimp would be much more appealing for Ps-bred guys >> (like me ;)) if one would have possibility to use the same (or at least >> much similar) keyboard shortcuts. > > There's some danger here -- as people in Germany found when they > compared moving to KDE or Gnome from Windows: when the new system is too > similar to the old, people start going into automatic mode, and trip up > much more over the differences. > I think the problem then is the differences; creating more differences isn't a good solution. Things tend to converge over time, and that's a good thing. The key is almost universally known as the help key today. Having each application provide it's own "Help" accelerator is to nobody's benefit. The world would be better if each application domain had a consistent set of core accelerators. File->New, File->Save, Cut/Copy/Paste, etc. are good for most all applications. For a graphics program, common tools like Pencil, Eraser, Move, Crop, etc. should have consistent accelerators. Accelerators can diverge where the application domain differs of course (e.g. raster versus vector editors) and where applications specialize (tablet support versus not), but within each sub-domain consistent cross-application accelerators would be better. I don't know what (each version of) Ps uses, but it would be beneficial to look at what they are, how they compare to other apps (PSP, Paint.Net, iPhoto, Krita, etc.) and see if they make sense for GIMP as well. This should probably be done periodically to promote application convergence for the general users' benefit (i.e: don't think of them as application accelerators, but as accelerators for graphics professionals) even if it means that accelerators occasionally change between versions. Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] scanfs without field width limits making Gimp crash
On Mon, Jan 24, 2011 at 8:09 AM, Nelson A. de Oliveira wrote:
> Here (also from your patch):
>
> snprintf (fmt_str, sizeof (fmt_str), "%%%lds %%%lds %%%lds %%%lds",
> sizeof (colorstr_r) - 1, sizeof (colorstr_g) - 1,
> sizeof (colorstr_b) - 1, sizeof (colorstr_a) - 1);
>
> sscanf (ptr, fmt_str, colorstr_r, colorstr_g, colorstr_b, colorstr_a);
FWIW, I often use an idiom like this:
--
#include
#define stringy(x) cpp2str(x)
#define cpp2str(x) #x
#define CONSTLEN 24
int main()
{
char var[CONSTLEN+1];
scanf( "%" stringy(CONSTLEN) "[^ ]s", var );
return 0;
}
--
It's not as flexible as being able to use a sizeof() operator but I've
found it to generally be reasonable.
Chris
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] scanfs without field width limits making Gimp crash
On Sun, Jan 23, 2011 at 10:20 PM, Nelson A. de Oliveira wrote: > On Mon, Jan 24, 2011 at 1:11 AM, Christopher Curtis > wrote: >> On Sat, Jan 22, 2011 at 2:04 AM, Nelson A. de Oliveira >> wrote: >> >>> To make it crash: >>> perl -e 'print "5"x210' | ./a.out >> >> The example it gives doesn't crash when I run it. Instead scanf >> returns ERANGE and (oddly) sets 'a' to -1. This may be Linux specific >> behavior though. > > Both on Linux and FreeBSD I get a segmentation fault with the example > code. I can't test on other platforms however. If I add another '0' to the perl line I get a seg fault as well. Must be a not-quite 64-bit limit. Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] scanfs without field width limits making Gimp crash
On Sat, Jan 22, 2011 at 2:04 AM, Nelson A. de Oliveira wrote: > To make it crash: > perl -e 'print "5"x210' | ./a.out I believe the unbounded '%s' is a legitimate bug, but is the '%i' assertion true? The example it gives doesn't crash when I run it. Instead scanf returns ERANGE and (oddly) sets 'a' to -1. This may be Linux specific behavior though. Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] distributing gimp with another program
On Sun, Nov 21, 2010 at 11:27 PM, ash oakenfold wrote: > My application can function without gimp. I only use gimp to stitch together > and save a larger image as an optional last step. If your needs really are this simple, ImageMagick is a pretty powerful tool released under a BSD-like license that may suit your needs. You may also want to consider using GEGL for your application. There is a plan afoot to use GEGL as the backend for GIMP compositing, and I'm sure everyone would appreciate as much 'real-world' testing of this library as possible - assuming flash allows that level of integration. Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] distributing gimp with another program
On Sun, Nov 21, 2010 at 5:12 PM, Graeme Gill wrote: > What counts > is dependence. I think all of your arguments are wrong, but on this point you may be right. I didn't realize that the GIMP is GPLv3 now, which is a very different license. GPLv3 is very fuzzy about linking. The appropriate FAQ then is this: - The difference between this [communicating at arm's length] and “incorporating” the GPL-covered software is partly a matter of substance and partly form. The substantive part is this: if the two programs are combined so that they become effectively two parts of one program, then you can't treat them as two separate programs. So the GPL has to cover the whole thing. - Section 5 of the GPLv3 states only: - A compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, and which are not combined with it such as to form a larger program, in or on a volume of a storage or distribution medium, is called an “aggregate” [...] - So our legal situation appears to be "not an extension of the work and not combined to make a larger program" -- the significance of this being under 'Section 5: Modified Source' instead of 'Section 4: Verbatim Copies' is not entirely clear to me. However, the GIMP LICENSE file states: --- * If you create a program which invokes (or provides) methods within (or for) the GPL GIMP application core through the medium of libgimp or another implementation of the 'procedural database' (pdb) serial protocol, then the GIMP developers' position is that this is a 'mere aggregation' of the program invoking the method and the program implementing the method as per section 2 of the GNU General Public License. --- This does not talk about running the GIMP from the command line specifically but does state that you can call into the GIMP core via libgimp or any other PDB interface and that is considered by the GIMP team as a 'mere aggregation'. Whether the command line is considered an 'implementation of the PDB' is not explicitly stated. *** (Sven, Mitch) *** This LICENSE text should probably be updated as 'Section 2' of GPLv3 doesn't talk about aggregations - it's been moved into section 5. It might also be useful to address this issue directly as the GPLv2 is generally well understood to allow command line usage as an 'aggregation', but GPLv3 seems to muddy this distinction. NAL, Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] distributing gimp with another program
On Sun, Nov 21, 2010 at 4:26 PM, Graeme Gill wrote: >> If the program dynamically links plug-ins, but the communication >> between them is limited to invoking the ‘main’ function of the plug-in >> with some options and waiting for it to return, that is a borderline >> case. > > But this is all irrelevant. The fact that the package contains > GPL code, makes the package derived from the GPL code, even if > the non-GPL contents of the package are un-connected with the GPL > contents. The only "out" you have is if it is "mere aggregation". The GPL applies to the GIMP and nothing more. Distributing a binary of the GIMP only requires the person shipping the binary to abide by the rule of offering access to the GIMP source code. Distributing anything else along with this binary is aggregation. The text you quoted says it's gray if the GIMP is opened as a shared object - but the default case or calling it via fork()/exec() (or flash's equivalent) is perfectly legitimate. What is wrong is calling GNU's FAQ for their GPL "irrelevant". > [...] (and the non > GPL code having functionality that is dependent on GPL code > seems a pretty strong hint I think, that this is not mere aggregation), The GNU project is very explicit that your interpretation does not match theirs: http://www.gnu.org/licenses/gpl-faq.html#MereAggregation -- What is the difference between an “aggregate” and other kinds of “modified versions”? An “aggregate” consists of a number of separate programs, distributed together on the same CD-ROM or other media. The GPL permits you to create and distribute an aggregate, even when the licenses of the other software are non-free or GPL-incompatible. The only condition is that you cannot release the aggregate under a license that prohibits users from exercising rights that each program's individual license would grant them. Where's the line between two separate programs, and one program with two parts? This is a legal question, which ultimately judges will decide. We believe that a proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged). If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program. By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program. -- AFAIK, GIMP doesn't allow "exchanging complex internal data structures" via the command line, and even if it did, the GNU project itself states only that if this were taken to court a lawyer would argue the point. And at that point, a judge would have to decide. Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] distributing gimp with another program
On Sun, Nov 21, 2010 at 8:03 AM, Graeme Gill wrote: > Daniel Hornung wrote: >> I am not a lawyer but I think that distributing GIMP along with other >> non-free >> programs should be ok if those other programs just use it through the command >> line. Of course you will still have to distribute GIMP under the GPL, which > > Hmm. What's the command line got to do with it ? The command line delineates program boundaries. If your application makes a call to another program, then your application and the application being called are separate entities. As they are separate entities, one is not derived from the other. > irrelevant, the dependence is what counts. A non-GPL program that invokes > a GPL program via any mechanism sounds a lot like is has some dependence > on the GPL code. It is dependent on it, yes, but dependence is not derivation. Specifically, from the GPL FAQ: -- Can I release a non-free program that's designed to load a GPL-covered plug-in? It depends on how the program invokes its plug-ins. For instance, if the program uses only simple fork and exec to invoke and communicate with plug-ins, then the plug-ins are separate programs, so the license of the plug-in makes no requirements about the main program. [...] If the program dynamically links plug-ins, but the communication between them is limited to invoking the ‘main’ function of the plug-in with some options and waiting for it to return, that is a borderline case. -- Calling GIMP from your application is perfectly acceptable under the terms of the GPL. Calling GIMP plugins directly gets fuzzier. If they are scripts, it can be done. If they are compiled code it is unclear. If you invoke them via the GIMP command line however, it does not matter - you are in compliance. http://www.gnu.org/licenses/gpl-faq.html I am also not a lawyer, but believe Daniel is correct. Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] distributing gimp with another program
Let me try to clarify one thing: On Sun, Nov 21, 2010 at 9:27 AM, Christopher Curtis wrote: > terms of the GPL. Calling GIMP plugins directly gets fuzzier. If > they are scripts, it can be done. If they are compiled code it is > unclear. I should have said 'If they are scripts that communicate via main()' - ie, at the commandline. If you have a python interpreter in your app and are loading python scripts for GIMP, the two applications would have to share certain data structures and calling conventions so there would be a derivation. I suppose both cases of calling plugins via a 'main' are borderline whether the code is compiled or not. But calling a GPL application from a closed application is allowable. Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] astronomical use of GIMP
On Fri, Nov 19, 2010 at 5:47 AM, Alexandre Prokoudine wrote: > On 11/19/10, Bill Skaggs wrote: >> On Thu, Nov 18, 2010 at 6:19 AM, Alexandre Prokoudine >> wrote: >>> >>> You know how to submit patches, don't you? :) >> >>That's not a very useful reply. Adjustment layers have been discussed >> extensively in the past, [...] > > Well, my point is that adjustment layers have been discussed to death > already (sorry, Alexia :)) So there is not much point saing "How about > implementing them" once again. At some point someone should JFDI. You know how to submit patches, don't you? :) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] scanner support should be File->Acquire
On Wed, Aug 25, 2010 at 2:55 PM, Sven Neumann wrote: > "somewhere else" is not a very intuitive place either. We've had a > longer discussion when these items were moved to File->Create and no one > came up with a better solution. I find the 'Create' label non-obvious as well. It makes sense for the logo scripts, but I'd suggest considering: File -v- New -> From Template... [Ctrl+N] From Clipboard [Shift+Ctrl+V] Scanned Image... Screenshot... Create -> Buttons -> [etc] I don't think that adding an extra click to File->New would be terribly flow-impacting, and "File->New->Screenshot" flows well in my head, whereas Create->Screenshot does not (how is that creative?). "File->New->From Template" may be a bit non-obvious, but should be fixable with some wordsmithing if so. Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Color spaces and layer blend modes - tool layers
On Sun, Aug 1, 2010 at 1:04 PM, Bill Skaggs wrote: > It would be much better not to use the word "tool"in this way. I agree terminology is going to be difficult. I get the impression you are only thinking about color, but I'm not. Maybe it's clearer if I use the terms "Image layer" and "Blend layer". So our layer tree has an image on the bottom and an image on the top. Where the top image has alpha, the bottom image can been seen through, as it is today. Now, instead of making the layer mode "Multiply" (or 'screen' or 'saturation' or 'lighten' (which have the same issues as color), etc), the user inserts a "Blend Layer" between the images. This "Blend Layer" is a "Multiply" type, and the "Multiply Blend Layer" has properties associated with it. One of these is "Color Space". Further, this "Blend Layer" has a gray(/alpha) mask so that the layer effect may apply to only a portion of the image. Further still, multiple "Blend Layers" may reside between the two images. So for example, picture a bottom layer of a frog sitting on a log. Above that is a "Desaturation Blend Layer" in the HSY color space, making it appear black and white. Above that is "Lighten Blend Layer" that is a graymask of the frog, making only the frog appear slightly puched-out. Above that is a color image layer of a butterfly (or something) near the frog. Your graph now resembles: - [Image]: Butterfly - [Blend]: Lighten (Lab), Frog mask - [Blend]: Desaturate (HSY) - [Image]: Frog on a log I'm thinking that some color tools could become unnecessary if you do this (just create a blend layer and flatten the image...), but I'm not advocating their removal. I'm also thinking that 'layer modes' could be useful when you have multiple blend layers, but they wouldn't be as problematic as they are all gray masks (add, subtract, etc. are all well-defined.) > backward compatibility. If you can find a way to make the Hue/Saturation > tool work better, there's no strong reason it couldn't be put into Gimp. > Changing layer modes that are stored in XCF files is more problematic. I'm not sure where this is coming from, but so it's clear: I think that Hue/Saturation is essentially unfixable. If you want to work in L*a*b space, such ideas don't exist. You would either need a color space selector and a complicated tool, or a tool for each colorspace type. And layer modes go away altogether. Instead you get a "Blend Layer" that performs the operations of the tool, using the color space specified in the properties of this "Blend Layer". And instead of constraining your image using a selection, the "Blend Layer" retains a gray mask indicating the affected pixels. The gray, in this case, replacing (or augmenting) an opacity slider. Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] html layers
On Sun, Aug 1, 2010 at 3:40 AM, Martin Nordholts wrote: > Have you tried GIMP from git? It has been made possible to do > per-character formating in text layers there. What format does it save the per-character formatting in? Would HTML be an option? Understanding even a subset of the basic HTML1 tags plus could likely be a good 80% solution. That's not to say that it's easy ( the most obvious problem), but HTML is a decent way to store stylized text. Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Color spaces and layer blend modes - tool layers
Hello, Let me start by saying I haven't been following any development builds of GIMP or GEGL, so I may have some false presumptions and I certainly lack some information. That aside, I'd like to ask some broader questions about color spaces. Firstly, some background: the HSY color space appears to be much better than HSL, at least for some color operations. The package "PhotoPNMTools" operate in HSY mode and produce very nice output on their page of sample images. I'm not sure how the operation "Increase saturation 4x" is performed in GIMP, but when I use the Hue-Saturation tool and set Saturation to "100" four times the result is far worse than what is displayed on the sample images page (using GIMP 2.6.8). [ PhotoPNMTools: http://www.13thmonkey.org/~boris/photopnmtools/ ] [ Sample Images: http://www.13thmonkey.org/~boris/photopnmtools/saturation-test.html ] Using the PhotoPNMTools and the flower image, I've set the saturation to 4000 (on a scale of 0..1) and it still looks better than GIMP's output. I've also set the saturation to '2' four times in series. There is a difference between these two images (the saturation at 2 four times and at 4000) but the distorted parts of the image remain fairly consistent, so the algorithm appears to produce very stable results. Next, Windows Vista uses something called the Windows Color System, which uses CIECAM02 LMS space, ratified in 2008. I don't see any tools that work in this space for comparison with HSY, but it seems to be clear that there are a lot of different models of how colors can be displayed and manipulated. [ http://en.wikipedia.org/wiki/CIECAM02 ] My observations, now, are that the layer blend modes chose a color space based on some semi-abritrary criteria, and that this information isn't immediately obvious to the end user. Secondly, tools such as Hue-Saturation are fixed to the HLS color model. My thoughts are that this is too limiting, and I'd like to know what you think about the following: #1: Add additional color spaces to the color manipulation tools (HSV/HSL/HSY/RGB/Lab/LMS/CMYK/etc/etc), where appropriate. #2: Allow a tool configuration layer to appear as a node in a GEGL graph. #3: Remove the concept of explicit layer blend modes. So what we end up with is something like the following: - Image01 - + Layer Group 1 - - Layer Group 2 - - - Top Image - - : Saturation Tool in HSY-space @40% - - - Bottom Image - + Layer Group 3 ... etc. This is probably a very poor example and I'm sure I'm abusing some terminology, but I hope you get the gist of what I'm saying. "Layer Group 2" is an image-tool-image sandwich, which in current GIMP would be two images with a layer blend mode of "Saturation". But this way, instead of a fixed mode, we have something far more configurable. Unlike a layer mode it's not a fixed thing, so it should also be relatively future-proof as new modes or color spaces simply become new options for this tool layer. I expect some people will want to know what this "tool layer" looks like, and I'm thinking it would be something like a simple gray mask, but I'm more interested what people think about the concept at this time. Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Please fix Color and/or Value transfer mode
On Sat, Jul 31, 2010 at 3:13 PM, Christopher Curtis wrote: > it is custom coefficients in HSY-space: Here's a reference to the HSY color model, since it seems uncommon, and because when searching for "gimp hsy" in Google the second result is the email I _just_ sent (!!) http://www.x-infinity.com/files/xm/HSY.pdf Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Please fix Color and/or Value transfer mode
On Sat, Jul 31, 2010 at 9:13 AM, Sven Neumann wrote: > > On Thu, 2010-07-29 at 01:56 -0700, Charlie De wrote: > > > And my point is that wasn't such a good decision precisely because it took 4 > > years to get it fixed. [...] If my line of thought had been followed 4 > > years ago, > > GEGL would most likely already be fixed. > > It would have taken an afternoon or two to fix it. Someone just needs to > spend that time and actually prepare a patch. This is not a question > about GEGL or not GEGL. If you feel that it is important to get this > fixed, then please submit a patch that introduces new fixed color modes. It might also be nice to get a definition of what it means to be "fixed". If I understand bugzilla correctly, this issue is bug 325564 (https://bugzilla.gnome.org/show_bug.cgi?id=325564). Martin's comments there are that changing the colorspace from HSL to CIE LCH resolve the issue but do not match Photoshop's results. I searched for a while and could only find some speculation that Photoshop may use CIE Lab, though these people claim they figured it out and that it is custom coefficients in HSY-space: [ http://www.filterforge.com/forum/read.php?FID=8&TID=319 ]. There may be other resources available, but I found this article to be a good introduction to some of the issues involved: [ http://en.wikipedia.org/wiki/HSL_and_HSV ]. Hopefully people can read this and not say things like "only the color should be transferred" -- excluding what - brightness? luminosity? intensity? Or just admit that they want GIMP to do whatever it is that Photoshop does. Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Merchandizing for the GIMP.
On Wed, Jun 9, 2010 at 1:43 PM, Alexia Death wrote: > On Wednesday, June 09, 2010 20:19:03 Sven Neumann wrote: > > > > Since I haven't been at LGM, I have trouble to understand the motivation > > for doing GIMP merchandising. > [...] > > b) Something a little bit better as a token of appreciation. Google gives > the > GSOC students shirts... It would be rally nice if we could give them a nice > little mug with Wilber on or something. > I've always found T-shirts to be infinitely more useful than most of the other baubles I've received. However, I certainly like the idea of sending "Merged" shirts to GSoC participants, presuming the code gets merged. They could also be used as rewards if anyone wanted to assign bug-bounties to bugzilla entries. It would be nice if whatever design this "Merged" graphic would be also shows support for the efforts of translators and documentation writers. Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Why artificially constrain toolbox window size?
On Thu, May 27, 2010 at 12:48 PM, Michael Natterer wrote: > On Thu, 2010-05-27 at 09:18 +0200, Martin Nordholts wrote: > > > > The GtkToolPalette widget that hosts the buttons is able to nicely > > distribute available space among the buttons, so I would like to remove > > the resize constraint and make the toolbox dock window freely > > resizeable. The attached patch does that. > > Yes, the concern is that tool buttons *do* have a fixed size, and I > really don't think we should scale them. The interface is IMHO > better with the resize steps. There is no reason to have non-square > buttons, because it doesn't exactly look good or professional. > By looking at the screenshot I don't think this is true; to the contrary, I like the look with more space around the buttons, and expect that I would find it easier to use because it's (a) a bigger target, but more importantly, (b) I find it a challenge sometimes to find a tool in the newer versions because many of them tend to blend together for me. I think more spacing like this makes them more distinct and easier to discern. Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Color management dataflow [was: Color management (UI perspective for GIMP 2.8)]
On Sat, Feb 13, 2010 at 5:58 PM, Jon Cruz wrote: [...] > does seem to come down to the points that X11 does not and should not deal > with color management in these regards and needs to leave it to the > individual apps. To get a fully usable system, X11 would require some major > reworking, and thus won't be seen any time soon. Do you have a reference to these discussions? It seems like X *should*, accepting that it may be difficult. > Of course, to end up with an optimal workflow for end users, GTK could be > adapted to handle a fair bit by itself (and, yes, there is work happening on > this at the moment). Toolbars, icons, menus, color selectors, [...] I was just going to say here that putting it in GTK could also 'fix' the color selector issues; let me just emphasize that point here. On a more philosophical note, how does one represent a color that does not exist on a display but does on an output device? Do we make the assumption that the display always has the widest gamut? (I.e: GIMP will never run on a mono/CGA device and print to a CMYK printer.) Is that a concern? Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Color management dataflow [was: Color management (UI perspective for GIMP 2.8)]
On Sat, Feb 13, 2010 at 5:39 AM, yahvuu wrote: > Christopher Curtis wrote: >> What happens in a multi-head setup when I maximize an image over (say) >> a CRT and an LCD? Does "monitor profile" take this into account? > > Following the logic of the diagram, i'd say yes: > your case is equivalent to cutting an image into two pieces and printing > one piece with an ink jet and the other one with a laser printer. I don't know that I'd agree with that; the example was not meant as a use-case, just a demonstration of a potential problem. One could argue that you'd need to print exactly this way to take advantage of the specific gamuts (or materials) of each device. But that's not my point. I would rather suggest this: that GIMP not do colorspace management of the display profile at all, and rely on X to do the right thing even if it does not do so today. Imagine you are editing some image on one screen and trying to match another image opened in another program on a different head. This other program is not colorspace aware because it's scientific modeling data or whatever so you have this dichotomy. In reality, you may never be able to match the colors because of the different display device gamuts. Maybe you can work around this with 'Acquire Image -> Screen Shot' but isn't that really too burdensome? You could push colorspace management into GTK, which would be better, but at the end of the day only one thing should be transforming gamuts and I think that thing is X. Perhaps GTK and X can negotiate who's in control so it becomes optional at the GTK level, but then you have the possibility that the transformations are implemented differently and slightly incompatibly. I think it's better to fix the problem once and to do so in a way that all applications can take advantage of it. It is X's job to render the final display, whether it's local, remote, DPS, Xprt, or whatever else X can render to. $0.02 Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Color management dataflow [was: Color management (UI perspective for GIMP 2.8)]
On Fri, Feb 12, 2010 at 11:55 AM, yahvuu wrote: > here are some diagrams depicting selected configurations for colormanagement: > http://yahvuu.files.wordpress.com/2009/08/dataflow.png What happens in a multi-head setup when I maximize an image over (say) a CRT and an LCD? Does "monitor profile" take this into account? I think my question is: Is X handling the colorspace or are profiles being applied on individual pixel regions? Is this even supported or is there something else I'm not understanding at a very basic level? Thanks, Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] cant save image with new comment
On Mon, Aug 3, 2009 at 5:12 PM, Martin Nordholts wrote: > Please let's not bombard the UI with modal dialogs. They are excellent > for interrupting workflows and annoying users. The proper solution is to > make changing the comment dirty the image, it is not to show a modal While I agree, what about the idea of an 'elevated status' message appearing in a toaster? If you think of how some IM clients notify, this 'elevated status' message could pop up from the status bar. It would stay open for 10-15 seconds and then disappear back into the status bar. There could be a small red 'X' in the upper right to dismiss the message immediately, otherwise it remains non-modal. Clicking the message itself could pull up the appropriate section of the GIMP help manual (or something else useful). Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] misleading / missing install instructions on website
On Sat, Jan 24, 2009 at 2:32 AM, Michael Grosberg < grosberg.mich...@gmail.com> wrote: > Is there a way to install 2.6.4 (or any other bugfix version or developer > snapshot) on Ubuntu? Are there alternate software sources that should be > specified? If so, what are they and can they be added to the install > instructions on the website? I was going to say you want http://apt-get.org/ but it looks like we're all left wanting. This may help: http://www.getdeb.net/search.php?keywords=gimp I believe there's a separate list for website changes; if this works, perhaps you'd like to suggest a link to http://getdeb.net/ there? Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Requesting advice for solving bug #325564
On Nov 26, 2007 2:26 PM, Sven Neumann <[EMAIL PROTECTED]> wrote: > On Mon, 2007-11-26 at 20:15 +0100, Jesper de Jong wrote: > > I have been looking into bug #325564 the past few days and I know how > > this should be solved, and I'm looking for advice on how best to > > implement this in GIMP. > > The best thing you can do at this point is to look at GEGL and make sure [...] > I don't think it makes sense to even attempt to fix it in GIMP. If this change is implemented in GEGL, does that mean it will make it into 2.6? If not, wouldn't it make more sense to allow Jesper to improve 2.6, then port it to GEGL (and remove the non-CMS aware version)? Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.6 roadmapping, the UI part of it...
On 10/28/07, Robert Krawitz <[EMAIL PROTECTED]> wrote: > From: "Christopher Curtis" <[EMAIL PROTECTED]> >>From: Micahel Grosberg <[EMAIL PROTECTED]> >>>here's the mockup (I made it long ago): >>>http://www.geocities.com/preacher_mg/UI_gimp_menu.png > >I think the easiest way is with a "last-clicked" policy. The GIMP >would hint to the user which image was active by either shading >inactive images (eg, making their rulers darker) or highlighting >the active image (eg, making the menu button brigher). Perhaps >both of these concepts could be added to the mockup; currently it >looks like there are 5 active windows. > > So then what happens if I'm using focus strictly follows mouse and I > put the mouse over another window (giving it focus)? What if I don't > click in the window, but do type a key (select a tool, for example)? Don't focus on the word 'click'. This has nothing to do with pointer focus. It's simply that the menu applies to the last image you did something with. And when you read "did something with", think "clicked on" and not "moved mouse over". Changing a tool or tool option does not change what image you're working on. The GIMP already does something similar with the layers dialog. Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.6 roadmapping, the UI part of it...
On 10/28/07, Robert Krawitz <[EMAIL PROTECTED]> wrote: >Date: Sun, 28 Oct 2007 12:03:57 -0700 (PDT) >From: Micahel Grosberg <[EMAIL PROTECTED]> > >>As an alternative, I'd like to suggest a UI setup I filched from >>Erdas Imagine (a GIS app). It sort-of emulates the Mac OS idea of >>starting an application with just a toolbar. >> >>here's the mockup (I made it long ago): >>http://www.geocities.com/preacher_mg/UI_gimp_menu.png > > What image does the menu apply to? In particular, how does this work > with focus strictly follows mouse? I think the easiest way is with a "last-clicked" policy. The GIMP would hint to the user which image was active by either shading inactive images (eg, making their rulers darker) or highlighting the active image (eg, making the menu button brigher). Perhaps both of these concepts could be added to the mockup; currently it looks like there are 5 active windows. Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Save Changes Integrated
On 5/20/07, Thorsten Wilms <[EMAIL PROTECTED]> wrote: > I will try to raise this with the Metacity project. > http://thorwil.wordpress.com/2007/05/20/save-changes-integrated-3/ I don't think you want to go too far down this path. A significant portion of GIMP users run Windows and WMs other than metacity. Back in the day, hitting '/' in Lotus 1-2-3 would present a menu at the top of the screen (Excel emulates this behavior to this day). I'm not sure I understand the problem with proposal 2, but perhaps replacing the menu Lotus-style would be agreeable. Are there MacOS-type environments that put the GIMP menu at the top of the screen? That could be a hinderance to this idea. Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [Gimp-Developer] One-click binary downloads via the gimp website
On 3/30/07, David Marrs <[EMAIL PROTECTED]> wrote: > We already get Gimpshop users coming to the mailing lists asking for help and, Would it be a good idea to embrace these users as well? Gimpshop may be a non-supported hack, but hosting a Gimpshop-specific list may provide insight into a larger user base with applicability to the One True GIMP. IE: They're beating at the door, would it be a loss to let them in if only to lend an ear? Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Rudeness on gimp devel and bugzilla - was:?Re: Tools
Hi, general comments: The tone of the GIMP mailing list has improved dramatically over the years (long time lurker here) and I would assert that it is generally very reasonable. However, language barriers can cause problems and special care should be taken when this is obviously the case. Also, it's easy to slip into "bad habits" that may just require a bit of extra self-control. To that end, spending 10 minutes on email is simply a waste of time. Terse is acceptable (even preferrable to long and meandering) and needn't be rude. I suggest an internal triage, where appropriate: (a) Is it worth my time to reply? Can anyone else answer this? (b) Is my response genuinely helpful? (c) Can I mitigate a problem by replying? For the email that instigated this, I found it to be unfriendly as well. The conversation basically went: "What language do you use?", "Figure it out yourself." I would say this fails my little triage test. If you think the question is foolish, treat it like the lunatic ranting on the corner: walk as far away as possible. Alternately, be concise, but helpful: "It's written in C. You can get the source from ... -or- Just search for 'GIMP source code'." The goal would be to encourage the requestor to work forward, not to dissuade them from doing so. Triage test (c) is simply damage control: If someone gets a rude message, a polite response from someone else gives people another place to focus. There is a video called "How Open Source Projects Susvive Poisonous People" available on Google Video from a couple Subversion folks: http://video.google.nl/videoplay?docid=-4216011961522818645 It's an hour long but is generally interesting. There are some valuable points not just from a "how to be friendly" perspective (which isn't always the answer, either) but also "how to keep a project on track". The section from 30:00-45:00 is probably most appropriate. And a FAQ would certainly be helpful. Regards, Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] kdevelop and gimp
On 1/26/07, Michael Natterer <[EMAIL PROTECTED]> wrote: > On Fri, 2007-01-26 at 10:33 +0100, [EMAIL PROTECTED] wrote: > > > This was pretty trivial but not obvious at first since gimp uses autotools > > in a non-standard way. > > Where exactly was the problem in using a different --prefix and > how does GIMP use autotools in a "non-standard" way? gg is probably referring to KDevelop's automake manager. I can only assume that it is following some "best practices" that they have themselves derived and what GIMP does doesn't match perfectly. KDevelop is certainly becoming very useful; I've had it lock up on me (regularly) when trying to edit larger projects imported from other systems though. It seems to especially not like code thrown by Rational Rose. Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Color management preferences not working and other CM stuff
On 1/16/07, Sven Neumann <[EMAIL PROTECTED]> wrote: > 2.6 has an even minor version number so it's obviously a stable release Obvious only to people who don't need to ask. > series. It will most probably use GEGL at a few places internally, but [...] > 2.6 is to finish some stuff that wasn't completed in time for 2.4 and to > start porting the core to GEGL. Perhaps we should also start porting the > display code to Cairo. But that depends on whether someone wants to work > on this or not. Something to consider, I think, is momentum. I think that people want to be part of a vibrant developer community. If a project does not have this, it may be beneficial to create an artificial one by increasing the number of releases. To this end, it may be wise to make future releases more "bite-sized": 2.6 implements CMS workflow and fixes 2.4 problems. 2.8 introduces Cairo rendering. And then 3.0 can integrate GEGL. GEGL of course has the same problem (limited developers) so it may be wise to do some partial integration where reasonable through the 2.x series to help keep that project going - people want to see the results of their efforts. More releases furthers this goal, and also entices new users to try the new features. This can create a nice feedback loop where lots of little changes can be cleaned up across each release. I don't think that additional stable releases further this goal because the GIMP generally just works. Bug fixes here and there just aren't exciting. Now, I'm not trying to be so bold as to propose a schedule, but it seems that if there were three or four releases this year - 2.4 now, then 2.6, 2.8, and maybe a 2.10 - that's roughly four months per release. Asking people to "wait for the next release to include your plugin" doesn't sound so severe then. The biggest burden I think would fall to the translators, which is something that developers just need to be sensitive to. The 3.0 release doesn't have to be so quick, assuming that GEGL integration upsets things. If timed properly, it may be wise to adapt a schedule to the Google summer of code program. The implication then being that this would complete summer 2009. Of course, that also means that this has to be a reasonable SoC project. Finally, in relation to my first comment, every mailing list has its share of hostile people. If developers truly want a large and vibrant development community, somebody needs to be a welcoming beacon. Condenscending remarks (blah blah is _obvious_) are damaging to that goal. There needs to be a consistent voice that welcomes masses of newbies asking "dumb questions" in hopes that some kernel within that mass are new GIMP developers that just need a little nurturing. (If it _should_ be obvious to someone, replying privately is better because the tone of the list matters.) Also, and this is related to above, I think we (all) should recognize the growing numbers of people running free software on non-free platforms and realize that they are important parts of the user base. Linux, for example, is not as scary to people who are already familiar with and use its software. But in order for them to use that software, it has to be a good experience on that non-free platform. "You mean if I buy a computer with Linux it already has the GIMP installed? Great!" For your consideration, Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Moving selection contents with the move tool?
On 9/27/06, Raphaël Quinet <[EMAIL PROTECTED]> wrote: This is a different issue from what was discussed here. You can toggle between moving layers, selection masks or paths by using the modifiers: Ctrl or Alt (this will soon be indicated in the status bar). I don't How will this be indicated? Is it via 'discovery mode' or 'explicit mode'? Discovery mode = Press shift, the description changes. Explicit mode = At the bottom of the toolbox (or in a tooltip, or ...) a guide: [Move] = Pick Layer/Guide [Shift] = Move Layer/Guide [Ctrl] = Pick Path [Ctrl][Shift] = Move Path [Alt] = Move Selection [Alt][Shift] = Move Selection (again?) These are the 2.2.13 options. I have to say I don't see a difference between 'pick' and 'move' for the normal/shifted case but I didn't try too hard. The [Alt] selections are very confusing, too. [Alt]-drag moved the window (KDE grabs it); [Alt][Shift]-drag picks "the other move" but the mouse cursor looks like a "ø". And [Shift][Alt]-drag shows "move layer" in the tool menu but drags an outline that doesn't affect the image if the entire image is masked, then returns to the [Alt][Shift] tool options; while if the mask is not present behaves like a regular move and returns to the [Alt][Shift] tool options with the mouse cursor now a "ø". Hmm. Selection/Quickmask confuses me. Things that operate on selections have icons that look like quickmasks. Anyway ... The 'scale' tool has the largest toolbar options area (2.2.13). With the toolbar maximized on my 1280x1024 screen, there's lots of blank space on the bottom where the shift-modifiers can be explicitly enumerated (it looks like they already are in this case, but a uniformity would be good). I'm not positive, but this could also be helpful for informing the user of "pre-use" and "during-use" modifiers, like the wacky select add/remove/square/center/move tools. I'm thinking of something that just looks like the list I have above, but with widgets for the [shift] keys, bottom aligned to the toolbox. Alternately, they could be in a giant tooltip, but this would prevent showing the 'during-use' modifiers. Does this seem like a valid use of the toolbox option pane? Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Tool statusbar error messages
I hope I'm not showing my lack of UI skills here, but: On 9/26/06, Carol Spears <[EMAIL PROTECTED]> wrote: On Tue, Sep 26, 2006 at 02:17:34PM -0700, William Skaggs wrote: > From: Michael Natterer <[EMAIL PROTECTED]> > > >While doing so I noticed they are all bad and inconsistent. > >"Indexed images are not currently supported."(heal) > Healing does not operate on indexed layers Healing cannot manipulate indexed images. "Cannot heal indexed images. Use Image->Mode to change color mode." Points: Instructs how to fix the problem. Concise enough (I hope) to fit translations. Remove "Use" if constraints prevent users from seeing "Image->Mode" (the important part) when clipping. And as a general, pie-in-the-sky, comment: It seems that indexed mode editing is cumbersome, confusing, and limited. When core operations are moved into a GEGL, The GIMP should probably lose indexed mode editing (indexed formats autoconvert to/from) and a separate tool be created just for this type of editing. More blue sky: It would be really slick if all GEGL-apps could shuffle images amongst themselves, assuming that interface is intuitive. So that, for example, an indexed editor, a pixel editor, a SVG editor, and a prepress app could all have a 'window' onto a shared image stored in GEGL space. Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: [Inkscape-devel] common interface for graphics apps on the"free desktop"
Sven Neumann wrote: Michael Natterer <[EMAIL PROTECTED]> writes: Perhaps we should just swap the Shift and Ctrl modifiers for display scrolling to be consistent with the HIG and across graphics apps. Sounds like a good idea. Let's do this for 2.4. Two questions about the current GIMP behavior (unrelated to modifiers): 1: Ctrl-Scroll up/down scrolls left/right. Wouldn't scroll up/down scrolling up/down be more logical? What happens on mice with scroll wheels for left/right? Does it just work out? 2: Shift-Scroll up/down zooms in/out from the center of the image. Would it be more useful if the zoom in feature zooms at the current cursor position? Is that possible, or would it be too confusing? Chris ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] first impressions of GIMP 2.0
[EMAIL PROTECTED] wrote: I don't think a lot of people would prefer a scrolling menubar over the ability to always reach the image menu using the right mouse button. Those who are new wouldn't know to right-click, and their voice is not heard here. If we want GIMP to gain popularity, it has to appeal to users on their first encounter. My logic detector must be broken. You are complaining that people who do not know they can right click will be disappointed because if they ever do right click they are going to get a menu instead of something they were never going to get because they didn't know to right click? The original implication was that by somehow making the menu bar 'scrollable' that the right click menu could be something else. Chris ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp GUI
Jakub Friedl, adresa do konferenci wrote: Flash is an absolute essential - we have no tools at all at present for Flash is, to my best knowledge, closed proprietary format. So there is only a little hope we can make our own Flash creating application. Hi, I've never looked at any of this stuff personally, but PHP suuports SWF: http://us2.php.net/ming And I also have a libswf on my Debian machine. A quick apt-get search: libming-dev - Library to generate SWF (Flash) Files (development files) libming-util - Library to generate SWF (Flash) Files - Utilities libswf-perl - Ming (SWF) module for Perl php4-ming - Ming (SWF) module for php4 python-ming - Ming (SWF) module for Python python2.2-ming - Ming (SWF) module for Python 2.2 gstreamer-swfdec - SWF (Macromedia Flash) decoder plugin for GStreamer libswfdec-dev - SWF (Macromedia Flash) decoder library libswfdec0 - SWF (Macromedia Flash) decoder library swf-player - SWF (Macromedia Flash) player libflash-dev - GPL Flash (SWF) Library - development files libflash-mozplugin - GPL Flash (SWF) Library - Mozilla-compatible plugin libflash-swfplayer - GPL Flash (SWF) Library - stand-alone player libflash0 - GPL Flash (SWF) Library - shared library libming - Library to generate SWF (Flash) Files libming-fonts-openoffice - Fonts for use with the Ming Library for SWF Creation It appears that openoffice has some SWF support ... rgds, Chris ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Should the checkerboard be linked to the window or to the image?
Sven Neumann wrote: It would still be interesting to hear about people's preferences. So please ignore my technical comments and tell us what which behaviour you would prefer from a user's point of view. I personally like the image preview fixed-checkerboard method, at least on the preview. I don't know how well it would translate onto the main canvas. However ... wouldn't this question be better directed at the user list? rgds, Chris ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Blur plug-in
Sven Neumann wrote: I'd like to get some feedback on the following plan for the Blur plug-in (details are in http://bugzilla.gnome.org/show_bug.cgi?id=142318): The plan is to remove the randomize and repeat functionality. [...] So the question is, is anyone actually using this functionality? Are there scripts out there that rely on plug-in-blur-randomize to be available? Is it possible to remove the dialog without removing the options? Also, I skimmed the bug report, which was initially about a preview. Another random thought (based on my previous 'impossible' one: Does it seem possible to make a 'fixed' preview area somewhere (maybe in the layers dialog?) that all plugins have access to, instead of reimplementing each one? Then maybe have this preview area call into the plugin to update itself when the user interacts with it? I realize this may not be a practical thing, but it may be something that someone else could run with ... Chris ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Refactoring code from GPL to LGPL
Manish Singh wrote: snipped out: the fact that clueless Robin completely missed the point that there was plenty of refactoring done into GPL libraries, quite independent of the PDB infastructure. [...] misinformation about the GIMP project. He completely deserves to be called on his lack of understanding and knowledge, and his complete inexperience with real software development. Hmm ... seeing as most decisions seem to be made on IRC, patches are only accepted if they are attached to bugs in the BTS, and evidently it's some great sin to ask a question here, what exactly IS the purpose of this mailing list? Or is Robin just special? I would imagine that if there are any archives of this mailing list that people can search that the number of flagrantly ignorant questions would go down. Of course, if the list archives convery no knowledge except 'ask not lest ye don asbestos and return none the wiser' that the archives are better off nonexistant. Chris ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] plug-in preview widget (another try)
Hello, This is just a random thought off the top of my head, but maybe it will inspire someone... It would probably be very cool if the "preview" functionality could be implemented so that it could also act as a filter. Such that, for instance, someone could grab a "looking glass" and "attach an effect" to it and move it over the image area. The image within this "looking glass" would then show a preview of the effect in this area in pseudo-realtime. Maybe if the design is made with this in mind it would make for a very useful bit of code where a 'preview' is simply a copy of the image or layer with a fixed 'looking glass' size and a couple scrollbars. And it would make for some very powerful effects, perhaps even to the extent of having 'effect layers'. Or not. Food for thought, Chris ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Gimp usability tests
Juhana Sadeharju wrote: From: "Christopher W. Curtis" <[EMAIL PROTECTED]> Would it be possible to solve this issue by placing "transient corners" on the image? It perhaps would not be a good idea if the original corner would move when the equivalent transient corner is moved. I agree ... did I suggest that? Oh, my kingdom for an archive!! Also, user would be moving a completely invisible edge. See figure: view -crop/selection region | --|- | | || --o--| | | The mark "o" would be a transient corner. When it is moved up and down, it would move the lower edge which is completely invisible. Actually, it's more like this: view -crop/selection region | +-a- | | || --b--| | | Both 'a' and 'b' are transient corners, and "+" is the regular crop corner. Point 'a' is only movable vertically, 'b' is only movable horizontally. I recall having said something about both a move and a resize always being visible, but I can't for the life of me remember what it was. I may have changed my mind in the middle of the message. But if the transient edge would only move the edge in horizontal direction, then why not grab and drag the edge itself -- it would be easier to implement. I would like being able to grab the border itself; grippies just "lend themselves to clicking" to paraphase some usability stuff I once read. If they are tied to a border, they should be centered in the view. Perhaps the whole region could be moved by grabbing inside the region so that no special "move" corners are required. The only problem I see with that is that clicking within the cropped area completes the crop operation (which I find very handy). Maybe a Ctrl-click-n-drag could be used. I really don't care for the resize corner and move corner. Maybe it might even be most useful if the square selections all behaved as "windows", with a "titlebar" that could be grabbed for moving, and the edges available for resizing ... that would be kinda neat and fairly obvious (except maybe to the mac people). Personally, I drag the rulers out to where I want them because they're always in 'move' mode (and you go to that mode if you aren't there already). Then I crop. Perfect every time! :) But I don't write GIMP code; I just blurt about occassionally. Chris ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Re: Gimp usability tests
GSR - FR wrote: [EMAIL PROTECTED] (2004-04-22 at 2052.21 +0200): This would, of course, make selection CSG operations more difficult. Simon said that implementing CSG operations on vectors would be not feasible. Ok, maybe you misunderstood me or I expressed it the wrong way: It would of course would be very good to have CSG operations available, but I am not particularily eager to implement them: I hope I'm not the only one asking myself this question... what is a CSG operation? Constructive Solid Geometry. I have seen it mostly in 3D apps, ie, you Hmm. I thought it meant Ctrl-Shift-[Alt/]Graph have solid cube and you substract a solid cilinder and get a cube with hole, then you had a piramid on top, and you end with a home like thing with a hole, and so on. With 2D (closed) vectors it should be similar, add, substract and interesect them to get different shapes. Sounds like the same thing to me. ;-) Chris ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Costs estimates
Sven Neumann wrote: Nathan Carl Summers <[EMAIL PROTECTED]> writes: For funding requests for GIMPCon in Norway, it will be very useful to have cost estimates for the event for the GIMP. Could everyone planning to go to Kristiansand send an estimate of how much money they will need to get there? It would have been nice to include dates and places. I didn't search the archives, but I couldn't find anything in the Wiki. Ugh! I can't find airfare there any cheaper than about US$1500. Has anyone from the US found a much better deal? Did you also check flights going to Oslo? On a whim last night, I saw a number of flights from Orlando to Oslo from ~US$420+ at Travelocity. They had restrictions like "anytime in June," but not knowing the dates I couldn't tell if that mattered. rgds, Chris ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] tentative GIMP 2.0 release plans
Nathan Carl Summers wrote:
Yes, calling the new release 2.0 is a LIE. I cannot emphasize this
strongly enough. It is a lie because we have told many, many people what
2.0 will do. To release a 2.0 without these features is pure
misrepresentation. It is much too late to put the worms back into the
can.
"Me Too."
I've expressed my opinion before, but here are some links:
http://developer.gimp.org/gimp-future
Notable points:
The 1.3.x "Cleanup for 2.0" branch
o Port gimp to gtk+-2.0
o Cleanup some internal structures
o Implement a few, well defined, new features
o Think about a new way to handle plug-in distribution
The 1.9.x "Building GIMP 2.0" branch
o GEGL -- Gimp 'E' Graphical Library
o GCim -- The convergence integrated media object and utility library.
Colophon:
Feel free to send updates/comments/fixes/flames/whatever. We will keep
this document up-to-date and post new versions when neccessary.
Sven & Mitch
Second link:
http://developer.gimp.org/gimp-todo.html
Lots of features listed, all of them targetted at GIMP 1.4, none of
which mention GEGL and fully conform the above document. Some of which,
in fact, I don't think have even been completed. ("Script-Fu overhaul",
"Image/File Information", ?)
Chris
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: new-xcf [Re: Gimp-developer Digest, Vol10, Issue 18]
Alan Horkan wrote: It is far better not to XML at all than to break XML. (incidentally this is similar to what has been suggested for Cinepaint). Just for the record ... I read the CinePaint file format, and it doesn't even resemble XML. My "PREAMBLE" is valid XML. If they implement what they have written, they don't even bother with things like closing tags or putting parameters in quotes. The proper XML way to do what you describe would be to take the raw binary and base 64 encode it (ick) which is grossly inefficient for anything Which is why I said preamble. large. The more sensible way and still valid way is to use a container format and to link to the raw BLOB (binary large object) that would be another file in your container format. Which is what, at this point, I would prefer. OTOH, any Using Zip as a container is not "On The Other Hand", it does not prevent any of the things you are suggesting. Using a container at all is OTOH. run 'head' on an OpenOffice document and you will see that the manifest is left uncompresses so that you can easily read it as text. OpenOffice documents are zipped; you can't head them. btw: META-INF/manifest.xml is at the end of my .sxi file. Chris ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: new-xcf
Ok .. I want to apologise to everyone for overreacting. After a brief moment of reflection, a simple container has notable advantages over a single file, not to mention that a one of my assumptions didn't make sense. Where is there documentation on the ar format? I can't seem to find any. I'd like to read up on it some before commenting further... Thanks, Chris ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: new-xcf
Sven Neumann wrote: Hi, But you couldn't use any generic XML tools like validators or XSL transformations. If we go for XML we should really make sure that we make it proper XML, otherwise XML doesn't make sense at all. We could then as well go for a sexp syntax. Actually the latter would be a lot easier to implement since we could build on the established GimpConfig framework. I'm not going to argue it. I disagree that an XML preamble is useless becuase you can't XSLT the entire file just as much as I'd disagree if you said that saving a file to disk is useless because it's not a full core image. You don't have to unpack the whole archive and you can use existing widely-available tools to extract the parts you need. Fair enough. When I save a file, I typically need the whole thing. Chris ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: new-xcf
Manish Singh wrote: On Thu, Jul 17, 2003 at 12:06:12PM -0400, Christopher Curtis wrote: Rule #1 in brainstorming: don't criticise any idea, no matter how silly. So much for rules... Another downside: needing a special tool to manipulate it. Well, now, I want to end this silliness right here. Here's what you need to manipulate files in my propsed format: (cat and dd), or (vi), or (type and wordpad). There are no tools more standard than these. Consider the case of a corrupted xcf file. Maybe only 1 layer out of 20 is corrupted. With this proposal, a user needs either a special tool to extract out the good layers, or do a lot of work by hand to figure out how to use dd to grab it. With this format, a tool like the gimp can say "layer X is corrupt" and the user would have to do something crazy like edit the file with "vi" and delete the `` ... '' section from the XML header. With say ar, the user can extract individual layers by some tag, referenced in the xml metadata. Then can edit the xml to stub out the broken layer, and repack it and have a valid xcf file. This could be the difference between losing 10% of the work vs. all of it. Ahh yes, this way all the user has to do is: ar x file look for the right xml and edit it out or something based on some tag (I'm so glad this is so well thought out...) ar a file everythingelse1,2,3 Won't the Windows people be happy that they can do this instead of just opening a friggin binary-safe text editor. So while a user can open a text file header in an editor, they are going to need a tool anyway to manipulate it effectively. Yeah - it's called the same text editor. That's the advantage of using a standard format. Using standard tools to manipulate it. More likelihood of a machine having a tool installed, and less work for the GIMP team in maintaining special tools. ... is this thing on? You're right about simplicity though -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: new-xcf
Sven Neumann wrote: "Christopher W. Curtis" <[EMAIL PROTECTED]> writes: The nice thing about this is that it should be fully parseable by XML parsers (up until the first NULL [1 is required, the rest are optional I don't think the format you proposed is valid XML. There might be XML Rule #1 in brainstorming: don't criticise any idea, no matter how silly. parsers that are able to read it but it violates the spec. If I am wrong here, please show me where the spec defines the special role of the NULL character. I would reiterate what I said, but you quoted it. "fully parseable by XML parsers up until the first NULL". I'm not trying to jam image data into an XML format - simply prepending an XML header and using NULL as a separator. This means you can cat the file and know exactly what's there. Or you can open it in notepad (maybe make it NULL, ^Z for Windows people...) "file" will be able to readily identify the individual formats, and people could even use dd to extract the layers. Is there a special reason you dislike the idea of using an archive instead of a single XML file? I thought we would have been past this point already... I just don't see using another archive format as giving you anything. So say you use ZIP or JAR or TAR or AR: you still have to unpack (and possibly decompress) the thing just to find out what's in it. OTOH, any program that can open a file can read the XML header here, even if they don't parse it, it's still human readable. And this lets you do your fancy compression-based-on-data-type instead of generic-text-compression over each layer or the whole archive. If you want something fast, you can leave compression off and modify the data directly on disk without having to unpack/pack, as long as you stay within limits (ie: you can paint on a layer or move the layer around, but not add a new layer or change the bit-depth, and you just have to munmap() that section). This makes it easy to have specialized external tools that manipulate layer data without all the GIMP overhead, easily scriptable, etc... This would also be a much simpler format, and I like simple. If you want to talk about downsides, I can think of only one: the first data offset is not predictable. But I assert that that is irrelevant because you can specify it to be anywhere. Chris ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: [CinePaint-dev] GIMP GBR format spec
Sven Neumann wrote: We actually had something else in mind but since you don't seem to be interested I won't waste my time explaining our ideas. It is very sad to see that Sven thinks that Robin Rowe is the only person to whom his ideas should be told. Pity the rest of the GIMP developers (current and future) who might like to comment on it. Christopher ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: availibility of Gobe source code
On Thu, 2002-03-28 at 05:59, Branko Collin wrote: > On 28 Mar 2002, at 11:02, Sven Neumann wrote: > > > I heard that Gobe Productive (http://www.gobe.com/) ships with > > plug-ins based on source code from The GIMP and sent them a letter > > asking for source code. I'm forwarding their answer here... > > IANAL, so IMO these are the things you should run by the FSF, just to > make sure. > > Specifically, I wonder if using GPL'ed plug-ins cause the main app to > become GPL'ed. Similarly, IANAL, but the whole debate surrounding these types of issues is what is it that constitutes "linking". RMS has made it clear (as I recall) that simply calling a GPL program does not constitute linking. So you can run ``system( "cp file1 file2" );'' without violating the GPL if the 'cp' program is covered by the GPL. You cannot, however, do something like ``dlopen( "/bin/cp" );'' Now, what has been done with the plugins? To my best understanding (and please consult the FSF), if the plugin can run as a standalone app, they are OK. If the plugin is being dlopened or otherwise "link"ed into the program, they are in violation of the GPL. If they modified the plugins to run as standalone programs, and made these changes available under the GPL as required by the GPL, they may have gotten away with it. Unfair, but not a violation. GPL 2 is not bulletproof (especially with anything web-based and the "distribution" clause). Naturally, I've done no research, and haven't even looked at their ZIPped mods, and know little about GIMP internals, but that won't stop me from giving an uninformed opinion!!! Either way, I hope everything can be resolved amicably ... Cheers, Chris ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] TIFF plugin deficiency
I'm not sure if anyone was aware of this, but the TIFF plugin does not (seem to) support multiple pages. I notices this when I converted a .pdf to a .tiff (for HylaFAX usage) and the Windows 98 viewer saw all 12 pages, but looked horrible (of course); so I fired up the GIMP and it was beautiful, but I could only get the first page. I'm assuming this isn't just a problem with the Win32 port, of course ... I don't know what I've done with either file now that I'm at my Linux box :( Chris ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
