Re: [Gimp-developer] Why GIMP is Inadequate
> I think that someone of you that can replay to false things must post a > replay. Why bother? There are lots of false things in the Internet. --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Graphic Tablet Sponsoring
OK from me, of course. --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] IMPORTANT: GIMP AND OPENSOURCE SCAM ON EBAY!
> Whether you have/had the authority > to grant that permission is another question. I should note that nowadays such requests coming to me are for PSPI, not GIMP itself, as I haven't built and distributed any GIMP binaries in a long time. When they used to ask for "permission" to redistribute GIMP, I did always try to reply "I can't give the permission even if I wanted, but you don't need it anyway" or something to that effect. (Also for PSPI, I always reply "you don't need to ask for permission", but some insist. Not often nowadays though.) --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] IMPORTANT: GIMP AND OPENSOURCE SCAM ON EBAY!
> selling the software on ebay. In my country (germany) some people do not > have access to broadband internet and like to buy a CD of the software. GIMP has been relatively often distributed on CDs that come with relevant magazines, also in Germany. Very recently even, I know because some of these publishers tend to ask for permission (even if they don't have to) and have asked for my postal address and sent me copies... And like ten years ago I received some Japanese computer graphics magazine (which was not very useful) for maybe a year after "giving permission" to distribute a Windows build I had done back then... --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] IMPORTANT: GIMP AND OPENSOURCE SCAM ON EBAY!
As long as it seems clear that none of the actually affected parties (i.e. the people who hold the copyright to parts of GIMP and other (L)GPL-licensed bits bundled by the "scammers") care about the alleged problem or would consider doing anything, this discussion is mostly pointless. --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP build from source code on Windows
> Pls give me a hand to inform a right place > (guide line) to compile GIMP source code upon windows OS, It's much easier to cross-compile it from Linux. I suggest you use openSUSE and familiarzie yourself with the GIMP (and all dependencies) cross-compiled to Windows (both 32- and 64-bit) available in the openSUSE Build Service. See http://download.opensuse.org/repositories/windows:/mingw:/win32/openSUSE_11.3/noarch/ for Windows binaries (packaged into "noarch" RPMs for openSUSE 11.3), and http://download.opensuse.org/repositories/windows:/mingw:/win32/openSUSE_11.3/src/ for corresponding source RPMs. (But it is equally possible to cross-compile from other Linux distros, as long as there are cross-compilation tools available for the distro. openSUSE and the openSUSE Build Service is just what I know.) Sure, it is possible to build GIMP natively on Windows, too, but it is much harder, and it is not possible to explain it in one mail message to somebody who has never done anything similar. Of course, in any case (either cross-compilation or building natively) it helps very much if one has experience of building simpler software that uses similar build techniques (configure scripts, makefiles, GNU autotools, libtool, make etc). > because I want to do some hacking on GIMP. What kind of hacking? It is usually a good idea to discuss development ideas on the GIMP developer mailing list (gimp-developer@lists.xcf.berkeley.edu , subscription instructions at https://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer/ ) instead of doing develpment without any cooperation with others. --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Rotational Motion Blur
> A motion blur is a retinal effect that has a time dependence. Is "motion blur" actually something people perceive with their eyes and brain, or something that only exists in physical artefacts? (Either intentionally created by an artist to give the impression of motion, or as an direct result of the method the still or motion picture was created.) And we have been so used to it that we "know" what it means, even if it doesn't correspond to what we actually see? (But yeah, gg's arguments make sense.) --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Plugged-in tools
I think an IWarp tool would require mechanisms in GIMP that don't exist yet as none of the current tools, even if superficially similar (like the smudge tool) requires them. Also, the exact way an IWarp tool should behave should be specified before one starts coding on it;) Yeah, getting input on how the corresponding functionality UI works in PS might be useful, or not. GIMP is not supposed to be a PS lookalike. Should using an IWarp tool mean entering a separate "mode" where you then have to "apply and exit" it when done? That is somewhat ugly, isn't it? Or should an IWarp tool automatically do the final application of the displacement map that has been built up during subsequent IWarp "brush" strokes and whatnot when another tool is selected and used? Will that be unbearably slow? In a non-destructive GEGLified future, that probably doesn't matter much as the calculation of updated actual image pixels can be done in the background (as long as the preview is correct enough), or something. I quote my comment in the bug mentioned, "The smudge tool is inherently quite different from what an IWarp tool would be. Each stroke of the smudge tool immediately affects the pixels the brush touches. There is no memory of previous strokes. In IWarp, on the other hand, what happens when you stroke is that the displacement map gets updated, and the effect on the *original* pixels from when the tool was started has to be recalculated. (At least, something like this is what I recall from when I was hacking on making IWarp a tool.)" --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] ANNOUNCE: GIMP 2.7.1
> Tor, and what solution can you advice? File bugs with the respective maintainers to fix the problem? But yeah, that might take a while of course. So sure, if you know what you are doing, and you verify that it works, feel free to rename DLLs. But be aware then that telling about it might inspire random, more clueless, other people to repeat the trick without really knowing what they are doing. --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] ANNOUNCE: GIMP 2.7.1
> after renaming some libraries (libintl-8 to intl, > libpng14-14 to libpng12-0) everything went Ok Renaming DLLs is never a good idea. There might be a good reason why the name was changed - namely because the API and/or ABI has changed. --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Q: cygwin GIMP build problems: missing execinfo.h
> Can anyone tell me the trick to building GIMP under cygwin (on Windows XP > 64-bit). You really mean you are building for Cygwin, not Windows? > My immediate problem is that the GEGL make fails because execinfo.h is not > found. Well, most likely nobody has attempted to build GEGL for Cygwin before. > the build should not be including this file on windows platforms. Well, Cygwin is a Unix platform. It should not be treated as Windows. It's just a coincidence that Cygwin runs on top of Windows. --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Compiling GIMP for/on Windows (on Cygwin)
> 0. Have to use M$ Windows Don't bother writing "M$", that is so last century. > way out: Use Cygwin. In what way is that a way out? You will still be using Windows... You should be aware that if you use Cygwin, and your intent is to build software for "native" Windows (software that doesn't use the Unix emulation that Cygwin provides), you must be very careful to avoid confusion. I really suggest using MSYS instead. (Distributed from the same site as MinGW.) You should think of Cygwin as a completely separate operating system, that just happens to run on top of Windows. > 2. After downloading the code, I am not able to figure out the dependencies > (on Cygwin) Even if you do insist on using Cygwin as you interactive shell environment, don't look for dependencies "on Cygwin". If you for instance use GTK+ for Cygwin it will require the X window system at run-time, as far as I know. If you use a Cygwin build of libjpeg or libpng, for instance, but GTK+ for Windows, you will justl be creating an awful mess for yourself. > So, is there any way for Cygwin (for compiling GIMP from source), other than > manually going through each dependency and installing them (which I dont > know if will work in Cygwin or not)? Well, let's forget Cygwin for now, right? But still, indeed, you need to manually install suitable run-time and developer packages for the dependencies for Windows. Most importantly, the GTK+ stack, and libraries like libjpeg and libpng. http://www.gtk.org/download-windows.html will help you a bit. And you will have to build babl and gegl. > I hope I don't "have" to switch Linux for this. Most people think it is easier to cross-compile GIMP for Windows from Linux. --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Testing on NULL an unitialized values
> Will the compiler stop execution on any warning? It should, and not > compile any code that gives warnings, otherwise your attempt will not > work. People will ignore it "just for testing". That depends on the project. Many projects do use flags like -Werror, although that is not always possible. And most good programmers in the FLOSS world use flags like -Wall and take compiler warnings quite seriously. --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Testing on NULL an unitialized values
> You are right, that in some seldom situations it might make sense
> to initialize values to other start values. But they should always be
> predictable.
You didn't get the reasoning about letting the compiler, or valgrind,
catch use of uninitialized variables, did you?
> The same is here: a NULL-pointer is an exception.
Only if you try to dereference it. There are some standard C library
functions, and many GTK+ stack functions, where passing a NULL pointer
for a parameter is a documented fully normal way to specify some
semantic variation of its API.
> And it's the only
> exception that you have for your pointers,
Well, as such some API could very well define some "well-known"
special ("exceptional") pointer values and give them semantic meaning
by themselves (i.e. the contents of what they point to would be
irrelevant). That doesn't happen often, but it would be perfectly
normal C.
I mean something like:
typedef struct FooBarStruct *FooBar;
extern const FooBar FooBarMUMBLE;
extern const FooBar FooBarPLUGH;
where the actual contents of the structs pointed to by FooBarMUMBLE
and FooBarPLUGH would have no meaning, the only meaning would be that
if for some function a FooBar argument equals FooBarMUMBLE it would
have a special meaning (and the pointer would not be dereferenced),
and ditto for FooBarPLUGH.
--tml
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Testing on NULL an unitialized values
> The test > if( template ) > makes only sense, if you can be sure that uninitialzed values > will definitelky be NULL. You must have missed the g_return_val_if_fail (! template || GIMP_IS_CONTEXT (template), NULL) . It checks if template is NULL or a pointer to a valid GimpContext. If template is some random non-NULL value, the test will fail and a warning message will be printed. Such warning messages indicate a programmer error and should be dealt with during development. --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP and Python
> It seems that you're talking Windows in this case. ;-) > Frankly, it is a very bad thing when applications include a script language > engine in their distribution that then is installed somewhere in a non- > standard place on the platform. But what is the "standard" place for Python on Windows? And are you sure that some version of OpenOffice.org for instance even would work with whatever Python version the python.org people currently consider "standard"? On systems with package management and svendor package repositories that *do* offer standard packages of everything imagineable in the FLOSS worls, the situation is quite different of course. --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Windows snapshot of 2.7 - possible?
Nothing personal, just a friendly reminder to people who distribute personal builds like this: Please note that even if you do it just temporarily on a small scale, you still need to follow the licenses, i.e.offer the sources for all GPL or LGPL code you distribute. You don't want to give anybody the opportunity to start flaming you about breaking the license. --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp <-> prolog interface
> Thanks, I believe Python is the solution I was looking for. But if you really wanted to use Prolog, surely Python is quite far from that? Or is there some extension or whatever to Python that allows one to write Prolog-like clauses, a Python-hosted Prolog in a way? (Apparently, yes, there are several, see for instance http://code.activestate.com/recipes/303057/ , http://christophe.delord.free.fr/pylog/index.html and and http://codespeak.net/pypy/extradoc/paper/prolog-in-python.pdf ) --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Would single-window fix usability nightmares?
> In your educated guess, are the GIMP-vs-window-management problems: > 1) bugs in the port of GTK+, or > 2) are they inherent limitations of "window properties" model of > the interaction between an application and graphic system? Both;) The exact meaning of what in the X11 world is called "window manager hints" is not specified. (And that's as such not a serious problem; they are just "hints" after all, window managers are free to ignore them, and the principle in X11 has always been to "provide mechanism, not policy".) That said, there is a reference environment (the window manager called "metacity" used in the GNOME desktop environment), and from the GTK+ on Windows point of view, what is desired is to emulate the behaviour of that. So how the window management GTK+ API should behave is well-defined, if one just compares the behaviour of some specific sequence of GTK+ API calls under metacity in GNOME and on Windows. > The limitations which may be addressed only by adding specific CODE > to application (as opposed to specific DATA on the app-WM interface)... Yes, everything is just a small matter of programming... As such the amount of code changes needed to get rid of the most glaring GIMP problems on Windows (window z-order getting confused and windows occasionally seeming to refuse activation or focus) is probably not large. But the code is a bit convoluted. Also one must be careful not to break something else when fixing one thing, of course. --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Would single-window fix usability nightmares?
> [ It's all about attitude. Saying "Patches welcome" is an unhelpful attitude. OK, so what about "Feel free to ask for your money back"? Or "OK, I guess you have to use the competing products then"? --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Would single-window fix usability nightmares?
> Let me restate it: > > it is pointless to fix bugs/problems on windows, since they do not > happen (and if they happen, developers do not want to see reports). No, not at all. Bug reports (in the proper place, i.e. bugzilla.gnome.org) are always welcome, especially if they describe specific error scenarios, that have not been reported earlier, that can be easily reproduced even with some relatively simple app like gtk-demo without requiring running a complex one like GIMP. Sure, I certainly am well aware that the maintainers of GTK+ on Windows (i.e. myself and a couple of others, in our "copious spare time") are not as responsive to bug reports as some users seem to expect. That doesn't mean we would ignore the reports, though. > Are you sure that the situation is as you describe it? You mean when I said "It is pointless to describe the misbehaviour of GIMP windows on Windows to GIMP developers, as they don't use Windows themselves." ? That depends on who is counted as a GIMP developer, but at least currently, the people who understand GIMP best and actively work on GIMP don't use Windows. (This means something like two to four people, in their spare time, in case you have the unfortunate common misconception that there would be a large number of GIMP developers.) Personally I do use Windows, and I am to some extent a (or even "the") maintainer of GTK+ and GLib on Windows, but currently I am sorry to say that I don't really have the resources or inspiration to work much on GIMP. I would love to, in principle. > Sorry, but I find this attitude as misplaced as one in the previous > paragraph... I am just stating what I see being the factual situation. It's not a question of "attitude". You mean the (de-facto active) GIMP developers have "an attitude" when they don't bother to use Windows? --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Would single-window fix usability nightmares?
> It was "GIMP's decision" to use GTK+, Well, d'oh! I wonder if you know what the "G" in GTK+ means? Yeah, they should have stayed with Motif, would have prevented the port to Windows and all the clueless whining that causes. --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Would single-window fix usability nightmares?
> 2.6.6. Tested on Windows. As has been said before, one should not think that the way GIMP's windows behave on Windows is how they are supposed to behave. There are bugs in GTK+ on Windows that affect GIMP. It is pointless to describe the misbehaviour of GIMP windows on Windows to GIMP developers, as they don't use Windows themselves. To see GIMP behave as it is supposed to, you need to use it on Linux. The reference window manager is metacity, as far as I know, but also other window managers might work well enough. --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] minimising
Please note that the behaviour of GIMP's windows on Windows is not necessarily as intended by the developers. The reference environment is using metacity as widnow manager on GNOME on Linux. You shouldn't infer anything about the developers' intentions from how GIMP's windows happen to behave on Windows. Most likely suboptimal window behaviour on Windows is just caused by bugs in GTK+ on Windows. The active GIMP developers don't use Windows much. --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp printing future direction
> I have tried all possible permutations of paper size between Gimp and the > Windows driver. Since this setup works great for all other applications > (e.g. Word, IE, Firefox, etc.), I don't see how the problem could lie > anywhere else than Gimp. (The problem is in GTK+ more likely, but that GTK+ is technically separate is mostly irrelevant to end-users.) Yes, it is well known that GTK+ printing (and thus GIMP printing) on Windows doesn't really work that well. My advice is always to use some other application to print images then instead, if GIMP isn't up to it. Opening an image file in another app and printing from there shouldn't take more than five seconds extra. In fact, I would even recommend that, if the situation really is as bad as it seems to be, the print plug-in is made optional (and not selected by default) in the GIMP installer for Windows... Sure, it would be nice if somebody fixed the problems. Volunteers welcome. --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Has anybody successfully built gimp with gtk+ > 2.17.2 (mingw/windows)?
> Between 2.17.2 and 2.17.3 the client-side-window branch was merged to > master. What you see is very likely due to this. FWIW, not even gtk-demo built from git master head of GTK+ runs properly on Windows at this time. I don't see any crash, though, just screen updating failures (blank areas that shouldn't be). I haven't build GIMP master head in a while, will try to do that today. --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [wish] alignment rotation
> It's a horrible trick. You would probably never guess if you weren't > told how it works or read about it somewhere. So what? It wouldn't hurt anybody either. It would presumably be trivial to implement and it wouldn't require any new UI. --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Installing GIMP 2.6 to a computer that is NOT internet-accessible
> I'm hoping somebody can help me with a GIMP problem. I want to install > GIMP 2.6 on a computer that is NOT internet-accessible. And presumably, running Windows? > I do not need, nor do I want all the added perks such as Weatherbug and PC > Confidential. Huh? What are these and what do they have to do with GIMP? Are you downloading GIMP from some fly-by-night site that tries to force random crapware on you at the same time? Just download the GIMP installer from the official site (gimp-win.sourceforge.net), copy the installer onto a USB stick, CD-R or whatever, take that USB stick or CR-R to the target computer, and run the installer from it. Doesn't that work? --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp on a Commercial CD-Rom ?
>> The Linux kernel is also GLP [sic], but the majority of Linux CD >> distributions >> does not ship the source. Oh yes they do. Not on single-CD installation disks, but all Linux distros provide source package files for all Open Source packages they provide, from their own repositories. Usually the "original" tarball included in such source packages is *exactly* the same one that is or was available from the package's upstream, and the distro-specific changes, if any, are then as separate diff files. --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp2.6.4 for ARM processor
> i am trying to cross compile gegl-0.0.22 with command CC=arm-linux-gcc > ./configure arm-linux --target=arm-linux When cross-compiling you should use --host, not --target, to specify the architecture the executables you are building will run on. --target is used when configuring compilers and similar tools, to specify the architecture of the object files the tools will operate on. --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] How to capture Gimp-log=dnd e vents on Windows? (re: Bug 561973 – Missi ng drag and drop target)
See the bug report for my comment. http://bugzilla.gnome.org/show_bug.cgi?id=561973#c6 In short, it is a known fact that GTK+ on Windows doesn't implement generic inter-process drag-and-drop. Only accepting files dragged from Explorer onto GTK+ applications work, and dragging images from IE (which is closely related to Explorer) apparently uses the same protocol. --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] RGB to YMCK conversion
> all colors can be specified with light wavelength measures isn't that true? > can't it be that instead of RGB color you say > light color wavelength instead? Not at all. There are lots of coloursthat are not equivalent to that of visible light of some single wavelength. Just think of purple. The term "colour" as used here means "colour as perceived by a human with normal colour vision" . Without referring to some animal's perception (or technical sensor's), the term "colour" is meaningless, and what actually exists in the physical sense is a spectrum of (visible) light wavelengths. Only so-called spectral colours (which are a very limited subset of the colours we can perceive) correspond to a specific wavelength of visible light. Read up on colour perception. For instance, start with http://en.wikipedia.org/wiki/Color , http://en.wikipedia.org/wiki/Spectral_color , http://en.wikipedia.org/wiki/Color_vision , http://en.wikipedia.org/wiki/CIE_1931_color_space and http://en.wikipedia.org/wiki/Purple . Ideally and simplified, for single largish fields of uniform colour, "idealistic" colour models as RGB or CMYK are as far as I know equivalent. But that is not what usually is meant when talking about "CMYK support" in software like GIMP. CMYK is used to describe colours in images as printed by actual physical processes on paper. In that context there are lots of very arcane and small-scale additional details that affects how the image end up looking. Think of issues as how well different inks can cover each other, how inks spreads onto the paper, what the colour of the actual paper itself is, how much ink can be printed before the paper cannot absorb any more and the ink starts to smear or whatever, etc. I am really no expert in this, but I do know enough that I understand this is not anything trivial;) --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Compiling LibOpenJPEG using MINGW/MSYS
> it was trivial to modify the Unix > Makefile to work with mingw. Took some fifteen minutes. That said, as there already *are* official Windows binaries (including a DLL) of libopenjpeg available from the openjpeg.org site, why not use that instead of compiling an own build? My personal opinion has always been that one should use official DLLs when available and usable. That the OpenJPEG.dll evidently is linked with a static unknown C library and not the msvcrt.dll that mingw-compiled code uses should not be of any harm here, as the libopenjpeg API doesn't seem to pass any references to data inside the C library (like file descriptors, including those in FILE structs). Sure, the openjpeg_v1_3_win32.zip contains no import library for the GNU toolchain, just the MS import library OpenJPEG.lib. But it should be trivial to generate a .def file from the DLL with the pexports command, and then an import library from the .def file with the dlltool command (both part of mingw). --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Compiling LibOpenJPEG using MINGW/MSYS
> But openjpeg is far from complex I mean source code file and folder structure -wise. The algorithms and code in the source files is of course probably quite complex. But one doesn't need to dive into the actual code just to build the software. --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Compiling LibOpenJPEG using MINGW/MSYS
> What you need to do is to *port* the code to use what's available on > Windows instead of the functionality declared in the "missing" header > files. Of course, it is highly likely that a library like openjpeg intended to be generally usable and cross-platform already *is* portable to Windows. And indeed it is. It's just that only project files for MSVC are provided. Furthermore, openjpeg uses a hardcoded Makefile for Unix-like compilation. no configure scripts etc, which is a bit sad. But openjpeg is far from complex and it was trivial to modify the Unix Makefile to work with mingw. Took some fifteen minutes. There is no comprehensive test suite, but I tried building the two programs in the "codec" folder and they seemed to work, converting a TIFF image to JPEG2000 and back to TIFF. The JPEG2000 image also loaded fine into IrfanView. Patch included below, as I don't think attachments make it through this mailing list. The patch simply adds two files, Makefile.mingw and codec/Makefile.mingw, and adds the targets "mingw", "mingwinstall" and "mingwclean" to the main Makefile. I build only a shared library (DLL) in Makefile.mingw. Building a static library is left as an exercise to the interested. BTW, why does the code bother to use the stdcall calling convention? Isn't stdcall kinda a historical artefact of dubious value for new code? But oh well, I didn't bother to change that. --tml diff -ru ../1.3.orig/codec/Makefile.mingw ./codec/Makefile.mingw --- ../1.3.orig/codec/Makefile.mingw2008-10-28 12:27:23.50900 +0200 +++ ./codec/Makefile.mingw 2008-10-28 12:24:06.66550 +0200 @@ -0,0 +1,16 @@ +# Makefile for the main OpenJPEG codecs: j2k_to_image and image_to_j2k + +CFLAGS = -O3 + +TIFF = /devel/dist/win32/tiff-3.8.2-1 + +all: j2k_to_image.exe image_to_j2k.exe + +j2k_to_image.exe: j2k_to_image.c ../libopenjpeg-2.dll.a + gcc $(CFLAGS) compat/getopt.c index.c convert.c j2k_to_image.c -o j2k_to_image -L.. -lopenjpeg-2 -I ../libopenjpeg -L$(TIFF)/lib -ltiff + +image_to_j2k.exe: image_to_j2k.c ../libopenjpeg-2.dll.a + gcc $(CFLAGS) compat/getopt.c index.c convert.c image_to_j2k.c -o image_to_j2k -L.. -lopenjpeg-2 -I ../libopenjpeg -L$(TIFF)/lib -ltiff + +clean: + rm -f j2k_to_image image_to_j2k diff -ru ../1.3.orig/Makefile ./Makefile --- ../1.3.orig/Makefile2007-12-21 12:39:41.0 +0200 +++ ./Makefile 2008-10-28 12:12:18.149875000 +0200 @@ -76,3 +76,13 @@ osxclean: make -f Makefile.osx clean + +mingw: + make -f Makefile.mingw + +mingwinstall: + make -f Makefile.mingw install + +mingwclean: + make -f Makefile.mingw clean + diff -ru ../1.3.orig/Makefile.mingw ./Makefile.mingw --- ../1.3.orig/Makefile.mingw 2008-10-28 12:27:29.19600 +0200 +++ ./Makefile.mingw2008-10-28 12:37:06.681125000 +0200 @@ -0,0 +1,54 @@ +# MinGW (i.e. GNU toolchain targeting Win32) makefile for OpenJPEG + +VER_MAJOR = 2 +VER_MINOR = 1.3.0 + +SRCS = ./libopenjpeg/bio.c ./libopenjpeg/cio.c ./libopenjpeg/dwt.c ./libopenjpeg/event.c ./libopenjpeg/image.c ./libopenjpeg/j2k.c ./libopenjpeg/j2k_lib.c ./libopenjpeg/jp2.c ./libopenjpeg/jpt.c ./libopenjpeg/mct.c ./libopenjpeg/mqc.c ./libopenjpeg/openjpeg.c ./libopenjpeg/pi.c ./libopenjpeg/raw.c ./libopenjpeg/t1.c ./libopenjpeg/t2.c ./libopenjpeg/tcd.c ./libopenjpeg/tgt.c +INCLS = ./libopenjpeg/bio.h ./libopenjpeg/cio.h ./libopenjpeg/dwt.h ./libopenjpeg/event.h ./libopenjpeg/fix.h ./libopenjpeg/image.h ./libopenjpeg/int.h ./libopenjpeg/j2k.h ./libopenjpeg/j2k_lib.h ./libopenjpeg/jp2.h ./libopenjpeg/jpt.h ./libopenjpeg/mct.h ./libopenjpeg/mqc.h ./libopenjpeg/openjpeg.h ./libopenjpeg/pi.h ./libopenjpeg/raw.h ./libopenjpeg/t1.h ./libopenjpeg/t2.h ./libopenjpeg/tcd.h ./libopenjpeg/tgt.h ./libopenjpeg/opj_malloc.h ./libopenjpeg/opj_includes.h +INCLUDE = -Ilibopenjpeg + +# General configuration variables: +CC = gcc +AR = ar + +PREFIX = /dummy +INSTALL_BINDIR = $(PREFIX)/bin +INSTALL_LIBDIR = $(PREFIX)/lib +INSTALL_INCLUDE = $(PREFIX)/include + +COMPILERFLAGS = -Wall -O3 -ffast-math -std=c99 -DWIN32 -DOPJ_EXPORTS + +MODULES = $(SRCS:.c=.o) +CFLAGS = $(COMPILERFLAGS) $(INCLUDE) + +TARGET = openjpeg +SHAREDLIB = lib$(TARGET)-$(VER_MAJOR).$(VER_MINOR).dll +IMPLIB = lib$(TARGET)-$(VER_MAJOR).dll.a + + +default: all + +all: OpenJPEG + +dist: OpenJPEG + install -d dist + install $(SHAREDLIB) dist + install $(IMPLIB) dist + install libopenjpeg/openjpeg.h dist + +OpenJPEG: $(SHAREDLIB) + +.c.o: + $(CC) $(CFLAGS) -c $< -o $@ + +$(SHAREDLIB): $(MODULES) + $(CC) -shared -o $@ -Wl,--out-implib,$(IMPLIB) $(MODULES) $(LIBRARIES) + +install: OpenJPEG + install -d '$(DESTDIR)$(INSTALL_LIBDIR)' '$(DESTDIR)$(INSTALL_INCLUDE)' + install $(SHAREDLIB) '$(DESTDIR)$(INSTALL_BINDIR)' + install $(IMPLIB) '$(DESTDIR)$(INSTALL_LIBDIR)' + install libopenjpeg/openjpeg.h '$(DESTDIR)$(INSTALL_INCLUDE)' + +clean: + rm -rf dist u2dtmp* $(MODULES) $(SHAREDLIB) $(IMPLIB) _
Re: [Gimp-developer] Compiling LibOpenJPEG using MINGW/MSYS
> Ok. I choose Cygwin, as it contains these files. Is this OK ? Sure, if you want to build code for Cygwin, but that has then nothing to do with the "native" Win32. My reply was perhaps a bit too terse, a failed attempt to be ironic. > I've copied the files from this crappy system into my MSYS/MINGW tree. That is totally wrong and won't work at all. You wouldn't copy header files like from Windows to Linux and think "hey, now I can build Windows software to run on Linux", would you? No more can you copy header files from Cygwin to a Win32 compiler and expect to be able to build Win32 software using those header files. What you need to do is to *port* the code to use what's available on Windows instead of the functionality declared in the "missing" header files. #ifndef _WIN32 #include #else #include #endif ... #ifndef _WIN32 ... whatever code that uses functionality declared in #else ... either just dummy replacement, or use corresponding Win32 APIs #endif > This is the same tree I'm using for my mozilla build environment. (I don't > want two msys systems on the same PC, unless there is no choice). No need for two MSYS systems. --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Compiling LibOpenJPEG using MINGW/MSYS
> Anyone know where I can get a valid sys/resource.h & sys/times.h ? On a Unix system of your choice. --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] (no subject)
> Full cygwin development tree install.
Please avoid Cygwin if you are building native Windows software.
Cygwin is nice if you build Cygwin software, but presumably that is
not what you are wanting to do, if you want to build plug-ins that
work with the "native" Windows GIMP.
(Yes, I do know that there are some software packages where the way to
build for Windows (no Cygwin used at run-time) uses Cygwin. I know of
OpenOffice.org and Mono. But for packages that use "normal" GNU
autofoo and libtool, like GIMP, Cygwin should usually be avoided if
what one wants is to build non-Cygwin "native" Windows code. It's way
too easy to confuse things and mix Cygwin libraries with non-Cygwin
ones.)
Use the mingw toolchain instead, and MSYS to run configure scripts and
as interactive shell. Or use the cross-compiling mingw on Linux.
> I had to spend around a day and a half messing about to do something that
> should have taken around half an hour.
"should have taken" in an ideal world.
> It should not be particularly difficult to enhance your build system to
> build natively on
> Windows. I suggest looking at the Mozilla build system for an example of
> how to do this properly.
Are you volunteering?
> One example. This pkgconfig thingy. In every module, I needed to edit each
> .pc file so that :
>
> prefix=[local path to module]
If you use the native Windows pkg-config, you don't need to edit .pc
files (at least not for the libraries whose Windows development
packages are distributed on ftp.gnome.org).
> ... now, what's this all about ?
> You can figure out this path implicitly from the location of the .pc file !
Yes, and that is what pkg-config does on Windows (*not* Cygwin, which
from software point of view is just a variant of Unix, even if
actually running on top of Windows). Read the manual page. The prefix
entry in the .pc file is not used on Windows.
IMHO pkg-config could well have been designed/defined to work this way
on Unix, also, but I don't think it can be changed at this stage, in
case there really are some packages out there where the location of
the .pc file is not $prefix/{lib,share}/pkconfig.
The prefix line is present in the .pc files o (at least "my") Windows
packages just because it would require more work to edit out the
prefix line from .pc files when building a library for Windows. In the
Windows packages I build, the prefix used at build-time on my machines
on purpose contain a string of hex digits (an md5 hash value actually)
as a hint that it is more or less a dummy string that is not expected
to exist on the user machine.
> GIMP itself is an excellent cross plaform app. The build system however
> looks like it needs a little work.
Sure. Again, are you volunteering?
--tml
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Built-in help
> As far as I know there is no GIO/win32 backend which supports http. Http is supported in libgio itself (using the winhttp API from winhttp.dll, which is looked up at run-time, so if you lack that, it won't work). See gio/win32/gwinhttp*.c. --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] I want to help translating
> I don't think these things are in any po-files, but in separate files Ah, OK, now I understand which strings you mean. Yes, it would indeed be nice if these strings would also be translated, and if that would happen as part of the normal localisation process, i.e. if the strings were present in the normal .po files for translators to find. As far as I see (Jernej will be able to fill in the details) these strings are specified in the input files to the installer builder Jernej uses (InnoSetup). These installer-builder source files can be found at http://sourceforge.net/project/showfiles.php?group_id=121075&package_id=132256 . (The latest one there seems to be from 2006 for GIMP 2.2, though. But I assume they have changed since only in details.) In there you find a file en.setup.isl that contains the English strings. I don't know how InnoSetup manages localisation of the installer and of strings that the installer adds to the Registry. But if we want these strings to be translated by the translators using their normal workflow, like the strings in the program itself, we need to 1) make sure they appear in the .po files, and then 2) some tool should be written that would take the message catalogs and spews out InnoSetup format .isl files for the various languages. As for the 1) part, it is relatively easy, just create some dummy .c file which contains all these strings, and let it be scanned by the mechanism which creates the .po files. The 2) part requires some more work, but is hardly rocket science either. --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] I want to help translating
> I'd like to help with the translation of Gimp and especially the > translation of the Windows version's menu entries and file context > menu entries. I don't think there are many translated strings that would be Windows-specific in GIMP? Any file chooser ones might be in GTK+ and not GIMP. > Where can I find the po-files or other sources and to whom shall I > send the translated files? http://svn.gnome.org/viewvc/gimp/trunk/po/ , http://svn.gnome.org/viewvc/gimp/trunk/po-libgimp/, http://svn.gnome.org/viewvc/gimp/trunk/po-plug-ins/ , http://svn.gnome.org/viewvc/gimp/trunk/po-python/ , http://svn.gnome.org/viewvc/gimp/trunk/po-script-fu/ and http://svn.gnome.org/viewvc/gimp/trunk/po-tips/ . > grep Language-Team po*/fi.po po-libgimp/fi.po:"Language-Team: Finnish <[EMAIL PROTECTED]>\n" po-plug-ins/fi.po:"Language-Team: Finnish <[EMAIL PROTECTED]>\n" po-python/fi.po:"Language-Team: fi\n" po-script-fu/fi.po:"Language-Team: fi\n" po-tips/fi.po:"Language-Team: Finnish <[EMAIL PROTECTED]>\n" po/fi.po:"Language-Team: Finnish <[EMAIL PROTECTED]>\n" --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] All GIMP windows to top when one selected
>> That said, at least the gdk_window_set_keep_above() function can be >> tested with testgtk, and it seems to work. > I may be wrong, but I remember that various users reported that it would > not work on Windows. Is GIMP doing something differently than testgtk? (Pay attention to gdk vs. gtk below...) The way GIMP uses gdk_window_set_keep_above() is different from the way testgtk uses it. GIMP actually calls gtk_window_set_keep_above(), and before the window has been mapped even. This, I guess, as such is a reasonable thing to do, but the end result is that gdk_window_set_keep_above() never gets called for a mapped window with setting=TRUE. Presumably this is due to some bug in GTK+, but I have no idea where in GTK+ exactly. As such the code for the non-mapped case of gdk_window_set_keep_above() in the win32 backend is exactly like the corresponding code in the x11 backend, it calls the cross-platform gdk_synthesize_window_state() function and the result of the actions caused by this is in cross-platform code, until eventually then something *should* cause gdk_window_set_keep_above() to be called with setting=TRUE once the window has been mapped. But that doesn't happen. My guess is that the reason for the above is some slight difference in when and/or in what sequence GDK events are generated between the win32 and x11 backend, and that the related cross-platform code some implicit dependency on the event sequence or timing of the x11 backend. More debugging and comparing of function call traces on win32 vs. x11 would be needed to find out exactly... testgtk on the other hand (when one clicks the "Keep above" toggle button of the "window states" test) explicitly calls gdk_window_set_keep_above() with setting=TRUE on an already mapped window... and that works. Perhaps it would be a good idea to add also a test for the setting keep-above before a window is shown to testgtk. > I'd say the somewhat established behavior for 'utility windows' is that > they are not listed in the taskbar and that they are kept above normal > windows of the same application. Some window managers also reduce the > window decorations, but that is probably not obligatory. > Would it help if we made a small example application? Perhaps add some > code to testgtk? That would make testing a bit easier, yes. --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] All GIMP windows to top when one selected
> One problem in implementing window manager hints and related things > correctly on Windows is the lack of exact specifications what they > should do, and a lack of *minimal* sample programs that could be used > to verify that the implementation is correct. That said, at least the gdk_window_set_keep_above() function can be tested with testgtk, and it seems to work. Is this what was referred to earlier in this thread? --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] All GIMP windows to top when one selected
> If you want to change the behaviour on Windows, then you should check how you > can contribute to GTK+. This is where window-management related problems are > supposed to be solved (for example, if the the "always on top" hint for docks > would work, then one big problem would be solved already). One problem in implementing window manager hints and related things correctly on Windows is the lack of exact specifications what they should do, and a lack of *minimal* sample programs that could be used to verify that the implementation is correct. --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] IWarp as a tool
> Will we be able to do "undo" *between* the strokes ? > * before "Do it"? > * after "Do it" ? In other words, will the undo stack be updated > after each stroke ? After "Do it", yes, definitely. But before, that is a tough question. In my first patch (which is not good), each stroke is undoable, but then it works in a different way. If implemented to work in the style of the transform tools, the strokes won't be undoable as such, any more than you can undo each incremental rotation "nudge" in the rotation tool while you are tweaking looking for the right rotation, for instance. Which is sad, true. Perhaps for the rotation tool it doesn't mean much, but at least for the perspective tool it would be nice if one could undo the incremental changes one does to the control points. Probably this wouldn't be hard to implement? I doubt the normal undo mechanism could be used, though, the transform tool would have to implement and own simple undo mechanism. For a warp tool working in the style of the transform tool, the amount of state is much larger, and implementing an own undo mechanism for it does not necessarily sound like a good idea. --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] IWarp as a tool
On 16/02/2008, Sven Neumann <[EMAIL PROTECTED]> wrote: > No, the tool class shouldn't do anything but providing the user interface. I now realize that the non-GUI code for a warp tool does not need to be very interesting or complicated. One could maybe even just use the existing displace plug-in for the non-GUI code. The only problem, if it is a problem, with the displace plug-in is a matter of precision, as it uses just signed bytes for the X and Y displacement, and IWarp uses doubles. It's the GUI part that has to do all the "interesting" stuff, collecting separate strokes and build up a deformation vector array, i.e. displacement map. I guess, in a way the warp tool should be like the transform (rotate/perspective/shear) tools. While interacting with it a preview is shown. Separate mouse drags are incremental, and just add to the in-progress build-up of data for the warp. Only when the user is satisfied and explicitly chooses some "Do it" action, does the actual warping take place. (Or would it be possibly to do it implicitly when the user switches tools?) So a more or less complete redesign of my current patch is indeed needed. (But that's what I was expecting anyway.) On 17/02/2008, Bill Skaggs <[EMAIL PROTECTED]> wrote: > I have doubts that the Warp tool should be a paint tool at all -- it > certainly doesn't use a brush. Yes. I thought long about this for a long time back and forth, and I had to at least actually get something done that works in some way, if only to get visual proof that it is the wrong approach... > Multiple strokes are always treated incrementally, though. That is a problem. But as I said above, a complete redesign is needed anyway, and if the warp tool is implemented more in the style of the transform tool, this shouldn't be a problem. --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] IWarp as a tool
> You don't need to allocate such a copy as it is already allocated for > you by means of the undo tile-manager. If you need access to the > original drawable, just read from the undo tiles. If your warp object is > a GimpPaintCore, then you can just use gimp_paint_core_get_orig_image(). But isn't each stroke with a tool a separate GimpPaintCore object? In the warp tool's case, I would like sequential strokes to have access to the same original image, the one before the first stroke. Is there any existing infrastructure to do this, or would the warp tool code need to manage such bookkeeping itself? --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] IWarp as a tool
> Do you really need to do it exactly the way the filter does it? > From your description, I don't really understand why your > current approach is less valid, or even why it will produce a > significantly different result. It does produce a significantly different result. In my current code, there is interpolation upon interpolation when calculating the new pixels as the stroke proceeds, and the affected area gets more and more blurred. In IWarp, even when updating the preview while stroking, it is just one interpolation away from the original (scaled) preview pixels. > the system is set up > so that tools are automatically halted if a drawable is dirtied > while a tool is active. (More precisely, while tool_control > is active.) That sounds promising indeed. I do wish that there was some technical documentation on how this all hangs together. Just trying to understand by reading the code is a bit hard. When you say "tool", you mean an object of a subclass of GimpTool, right, not an object of a subclass of GimpPaintCore? That is one thing that was a unclear to me, what is the proper division of tasks between a GimpTool and a GimpPaintCore? --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] IWarp as a tool
Unfortunately now that I have had time to think a bit harder, I understand that there is a fundamental difference in how my initial effort to implement a warp tool works compared to how the IWarp filter does. Basically, when using the IWarp filter, and manipulating the preview in its dialog, IWarp all the time has access to the complete original drawable (well, it uses a preview-sized scaled version of it). Also, the deformation vector array is built up and modified by each stroke in the preview, and not re-initialized between strokes. The displayed result preview is continuously based on pixels fetched from the original drawable, not from the already warped preview. In my current warp tool, on the other hand, each stroke (i.e. invocation of a GimpWarp object, a subclass of GimpPaintCore) is independent and reinitialises the deformation vector array. Also, it continuously modifies the drawable being painted on from itself to itself, if you understand what I think I mean... So, how to solve this? Should the bookeeping of deformation vectors be done per-drawawble by the GimpWarpTool object (a subclass of GimpPaintTool) and not GimpWarp object? Ditto for a copy of the original drawable. But when should this state then be discarded? Can a GimpWarpTool object know when some other tool or filter is being used on the drawable, and thus the warping data for that drawable should be discarded? Hopefully this is a question with an obvious answer, and there is some tool that already works like this... Or is it really so that a warp tool, and the "filter brush" kinds of tools that Ankh asks for, and all other nice cool things will need to wait for a complete geglification? --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] IWarp as a tool
A first version is here: http://tml.pp.fi/gimpwarp.diff . Diff against current SVN. Known problems: - reuses the smudge icon and cursor - the "remove warp" functionality doesn't do anything - the "bilinear filtering" and "adaptive supersampling" toggles have no effect - especially in the Move mode you often get "cracks" in the image Doesn't seem to crash, though. Currently it allocates a big buffer for the deformation vectors, two doubles for each pixel in the image. This should probably be changed to either use tile-based storage, or use a scaled (when necessary) deformation vector array with some fixed maximum size. If you compare to the iwarp plug-in source code, you will notice that the core "business logic" is mostly identical. The hardest thing was to find out how to plug this into the paint core etc stuff... --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] MIDI input controllers on Windows.
> I managed to get the Direct X input controller working with my Joystick. The > buttons trigger various things OK, but I can't get the Z Axis to control > sliders > (the paint brush radius for example). Might be something I've misunderstood > about the setup though. It might also be just because of some bug in the directx input module. It hasn't been extensively tested. I will have a look at it again someday. > Does MS Direct X input include Midi device support ? Sorry, no idea. I would guess not. > Who is working on the input module ? I wrote the directx controller module, but it was a quick hack, and I haven't looked at it since. --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Compiling "denoise" plug-in
> I downloaded and tried to compile Roland Simmen's "DeNoise" plug-in. It > only comes with source files, no Makefile, no configure to make the > Makefile. gimptool-2.0 doesn't seem to like multiple *.c source files. Well, I don't know anything about DeNoise in particular, but have you tried then just running gimptool-2.0 --dry-run with some dummy.c filename to see the correct flags to use, then copy-paste the output of that, i.e. the command to use to compile a plug-in with just one source file dummy.c, replaceing dummy,c with the actual source files of DeNoise? --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Compiling plugin for windows
> Now it is there: http://www.gimp.org/~tml/gimp/win32/gimp-dev-2.4.zip > . Please test and tell me if something is missing. Ah, I now see it needs some tweaking, Please hold on for a day or so until I have fixed the gimptool program to work better. (I hadn't looked at it for a long time...) --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Compiling plugin for windows
On 13/11/2007, Tor Lillqvist <[EMAIL PROTECTED]> wrote: > I will shortly create a developer package for GIMP 2.4 and add a link > to it on the http://www.gimp.org/~tml/gimp/win32/downloads.html page. Now it is there: http://www.gimp.org/~tml/gimp/win32/gimp-dev-2.4.zip . Please test and tell me if something is missing. --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Compiling plugin for windows
On 13/11/2007, Aurimas Juška <[EMAIL PROTECTED]> wrote: > I think it would be very useful if you could tell us how to compile > using both Microsoft Visual Studio and msys/mingw32. Well, in a nutshell, you have to know what you are doing;) Short instructions: Most importantly, the plug-in obviously must not use some POSIX-only or Linux-only APIs that are not available in the C library on Windows. You will need the header files for GIMP and the ones they include (GTK+ and its dependencies), and import libraries for the DLLs that the plug-in uses. (If you don't know what an import library is, look in the interweb.) As far as I know there is no distribution of a GIMP 2.4 developer package for Windows, unfortunately. But I think it should work fine to use headers and import libraries from GIMP 2.2, so get http://www.gimp.org/~tml/gimp/win32/gimp-dev-2.2.7.zip . (I will shortly create a developer package for GIMP 2.4 and add a link to it on the http://www.gimp.org/~tml/gimp/win32/downloads.html page.) Unzip the developer package in some suitably named new, empty folder. You will also need developer packages for GTK+, Pango, atk and glib. Unzip them, too, in either the same, or separate folders. With Visual Studio: set up a project that compiles the plug-in's source file(s), and pass the correct -I flags to the compiler so that it finds the header files, and the correct /libpath switches to the linker so that it finds the import libraries, and link with the correct libraries (the same ones you link with on Linux). With MSYS: Basically do like on Linux. If you are using auto* and libtool on Linux (as you should), but have never used those on Windows before, it can be a pain to set them up. So maybe for a small, perhaps just a single source file, program like a GIMP plug-in you shouldn't bother. Just write a makefile from scratch that builds your plug-in. One thing you need to watch out for is the correct order of object (or source) files and -L and -l options on the command line. The non-traditional order allowed by gcc and ld on Linux don't work for ld on Win32. To find out what the correct compiler and linker flags are, you can use the gimptool-2.0.exe program distributed with the gimp developer package. It requires that you also have the pkg-config program (available from the downloads.html web page mentioned above) and the PKG_CONFIG_PATH environment variable correctly set up, so if that causes a headache to you, it might be easier to just write the makefile from scratch. You can use gimptool-2.0.exe also to find out the flags for the Microsoft compiler and linker. Just pass the --msvc-syntax flag to gimptool-2.0.exe. (But see above about pkg-config and PKG_CONFIG_PATH.) So, in a nutshell, this is not rocket science. It's simply a matter of invoking the compiler with the right flags. I suggest staying away from tools like dev-cpp that try to make things easier but only succeed in preventing you from learning how things actually work. Dev-cpp etc might be fine for Your First Hello World program, but once you get past that, you need to get your fingers dirty. Feel free to disagree, of course. --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Compiling plugin for windows
> Hi all. I had develop a couple of plug-in and I need to compile it for > windows... Can anyone can tell me how? First tell us how you compiled it on Linux, and what kind of experience, if any, you have of development on Windows, and what tools, if any, you already have for that. (ILike, have you used Microsoft's Developer Studio and know your way around it very well, and have access to it? Or do you come from a Unix background only?) --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.4 and how to continue from here
> So if are planning any particular features for 2.6, now is the time to > present them here so that they can be put on the roadmap. I plan to make iwarp into a tool. --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Primary monitor profile (Windows)
Yoshinori Yamakawa writes: > For example, it can read the primary monitor profile as follows: Looks good. Please file this code in bugzilla.gnome.org attached to an enhancement request for GIMP. --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] winicon.exe - libpng12.dll issue
Heiko Schmidt writes: > I just compiled Gimp 2.3.19. > 'Der Prozedureinsprungspunkt "png_set_add_alpha" wurde in der DLL > "libpng12.dll" nicht gefunden.' > What could cause this? Your executable is using another libpng12.dll than the one that corresponds to the import library you linked it against. You have some older version of libpng12.dll in the Windows system32 folder that you are not aware of? --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Win32 plugin console window
=?WINDOWS-1252?Q?Aurimas_Ju=9Aka?= writes: > How do I change plug-in source tree so that console window wouldn't > appear in background (On Win32 platform)? Add -mwindows to the *linking* command line. (Or /subsystem:windows if you use MSVC.) --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [Suggestion] Windows .lnk shortcuts
ICMP Request writes: > Although I have to recognize that it's a very low priority issue, could > be nice to see it implemented on new versions. Thanks for the suggestion. This problem is already reported in our bug tracking system. See http://bugzilla.gnome.org/show_bug.cgi?id=163544 . It will be fixed eventually. --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg quality factor.
Sven Neumann writes:
> If someone wants to try to recover some of the JPEG save settings
> when loading the JPEG file, feel free.
I did.
Index: plug-ins/jpeg/jpeg-load.c
===
--- plug-ins/jpeg/jpeg-load.c (revision 22905)
+++ plug-ins/jpeg/jpeg-load.c (working copy)
@@ -50,6 +50,61 @@
gint32 layer_ID_global;
+static gboolean
+check_table (const JQUANT_TBL *file_table,
+ gint quant_tbl_no,
+ gint *quality)
+{
+ int i;
+ gboolean all_ones = TRUE;
+ gint q;
+ struct jpeg_compress_struct cinfo;
+
+ /* First do the simple check for quality 100, a table with all ones */
+ for (i = 0; i < 64; i++)
+{
+ if (file_table->quantval[i] != 1)
+all_ones = 0;
+}
+
+ if (all_ones)
+{
+ *quality = 100;
+ return TRUE;
+}
+
+ /* Then produce tables for all qualities 1..99 and compare. It's
+ * better to do it this way than to calculate the quality factor
+ * backwards from the table in the file because of rounding errors:
+ * We would never match all quality factors exactly.
+ */
+ for (q = 1; q < 100; q++)
+{
+ jpeg_create_compress (&cinfo);
+
+ jpeg_set_quality (&cinfo, q, TRUE);
+
+ for (i = 0; i < 64; i++)
+{
+ if (cinfo.quant_tbl_ptrs[quant_tbl_no]->quantval[i] !=
file_table->quantval[i])
+break;
+}
+
+ jpeg_destroy_compress (&cinfo);
+
+ if (i == 64)
+break;
+}
+
+ if (q < 100)
+{
+ *quality = q;
+ return TRUE;
+}
+
+ return FALSE;
+}
+
gint32
load_image (const gchar *filename,
GimpRunMode runmode,
@@ -57,6 +112,7 @@
{
GimpPixelRgn pixel_rgn;
GimpDrawable*drawable;
+ GimpParasite*parasite;
gint32 volatile image_ID;
gint32 layer_ID;
struct jpeg_decompress_struct cinfo;
@@ -76,6 +132,8 @@
GimpParasite * volatile comment_parasite = NULL;
jpeg_saved_marker_ptr marker;
gboolean found_exif = FALSE;
+ gint q0, q1, q2;
+ gint quality = -1;
/* We set up the normal JPEG error routines. */
cinfo.err = jpeg_std_error (&jerr.pub);
@@ -153,6 +211,32 @@
(void) jpeg_read_header (&cinfo, TRUE);
+ /* Check if the quantization tables used are produced by libjpeg's
+ * jpeg_set_quality().
+ */
+
+ if ((cinfo.jpeg_color_space == JCS_GRAYSCALE &&
+ check_table (cinfo.quant_tbl_ptrs[cinfo.comp_info[0].quant_tbl_no],
+cinfo.comp_info[0].quant_tbl_no,
+&q0)) ||
+ (cinfo.jpeg_color_space == JCS_YCbCr &&
+ check_table (cinfo.quant_tbl_ptrs[cinfo.comp_info[0].quant_tbl_no],
+cinfo.comp_info[0].quant_tbl_no,
+&q0) &&
+ check_table (cinfo.quant_tbl_ptrs[cinfo.comp_info[1].quant_tbl_no],
+cinfo.comp_info[1].quant_tbl_no,
+&q1) &&
+ q0 == q1 &&
+ (cinfo.comp_info[1].quant_tbl_no == cinfo.comp_info[2].quant_tbl_no ||
+(check_table (cinfo.quant_tbl_ptrs[cinfo.comp_info[2].quant_tbl_no],
+ cinfo.comp_info[2].quant_tbl_no,
+ &q2) &&
+ q1 == q2
+{
+ /* Yes. Store the quality in a parasite below. */
+ quality = q0;
+}
+
/* We can ignore the return value from jpeg_read_header since
* (a) suspension is not possible with the stdio data source, and
* (b) we passed TRUE to reject a tables-only JPEG file as an error.
@@ -257,6 +341,14 @@
layer_type, 100, GIMP_NORMAL_MODE);
}
+ if (quality > 0)
+{
+ parasite = gimp_parasite_new ("jpeg-original-quality",
+0, sizeof (gint), &quality);
+ gimp_image_parasite_attach (image_ID, parasite);
+ gimp_parasite_free (parasite);
+}
+
drawable_global = drawable = gimp_drawable_get (layer_ID);
gimp_pixel_rgn_init (&pixel_rgn, drawable, 0, 0,
drawable->width, drawable->height, TRUE, FALSE);
Index: plug-ins/jpeg/jpeg.c
===
--- plug-ins/jpeg/jpeg.c(revision 22905)
+++ plug-ins/jpeg/jpeg.c(working copy)
@@ -428,6 +428,23 @@
* over the JPEG encoding parameters.
*/
run_mode = GIMP_RUN_INTERACTIVE;
+
+ /* If we have stored an estimate of the libjpeg quality
+ * factor used when creating the original image, and
+ * that is larger than the default quality, use it as
+ * default for the dialog.
+ */
+ parasite = gimp_image_parasite_find (orig_image_ID,
+ "jpeg-original-quality");
+ if (parasite)
+{
+ gint quality;
+ memmove (&quality, gimp_parasite_data (parasite),
Re: [Gimp-developer] jpeg quality factor.
Sven Neumann writes: > If someone wants to try to recover some of the JPEG save settings when > loading the JPEG file, feel free. There are some scenarios in which blindly reusing the quality factor guesstimated from loading an image is not a good idea, even if the guesstimate is very accurate. (Which happens when the loaded image's quantization tables exactly match the JPEG standard's sample tables scaled in libjpeg's manner with said factor). I mean cases where the entire image contents has been replaced with a fresh (original quality) one. Or if the image has been scaled down. Or if some filter(s) that modifies all of the image substantially has been applied to the whole image. In cases like these it perhaps doesn't make sense to blindly re-use the original jpeg file's quality factor, but one should let the user decide. Maybe a good heuristic would be only use the original quality factor if available to increase the user's default setting, never decrease it. Show the settings dialog, as in current SVN, and if there is a guesstimated scale factor from the original image and it is better than the one in the user's default jpeg settings, use that initially in the dialog instead of the default. Anyway, I think that to really be able to to advanced tricks, the jpeg saving needs to re-decompress the original image while saving the new version. When it makes sense it should reuse the exact same quantization tables and subsamplig parameters. Then it could do tricks like avoid recompression artefacts for blocks that haven't changed. That would be really cool. One could load and save a JPEG image as much as one likes, just touching up small parts here and there (like correcting red-eye), with no quality degradation for the rest of the image. BTW, is there any reason to keep the "DCT method" choice? Why not just use floating-point always? Is there any significant speed difference on modern machines? --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg quality factor.
Tor Lillqvist writes: > One might imagine some application even doing a clever analysis of an > individual image to come up with image-specific quantization > tables. http://citeseer.ist.psu.edu/cache/papers/cs/1634/ftp:zSzzSzftp.cs.wisc.eduzSzpubzSztech-reportszSzreportszSz94zSztr1257.pdf/rd-opt-an-efficient.pdf --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg quality factor.
Sven Neumann writes: > I already explained that the JPEG plug-in cannot access the settings > that were used to save the file. Actually, it shouldn't be that hard to at least try. If the quantization tables used in an image correspond exactly (or "closely enough") to those produced by libjpeg with some setting of jpeg_set_quality(), it would be nice if GIMP remembered that as the default quality to use for the file. Or something like that... One might even consider keeping and re-using the original quantization tables instead of using jpeg_set_quality() in case the quantization tables don't seem to be produced by libjpeg. --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg quality factor.
Guillermo Espertino writes: > I didn't know that PS compression scale doesn't follow the jpeg > specification. There is no such specification for a compression scale or quality factor. Inside an JPEG image, what actually defines the lossiness of the compression are a set of so-called "quantization tables". A quantization table is a table of 64 8- or 16-bit integers. (Typically 8-bit values are used.) Typically, one such table is used for the "Y" channel (luminance, i.e. "B&W" information) and another for the Cb and Cr channels (colour information). These tables are actually stored inside each JPEG image. (There are not some standard one(s) that would implicitly be referenced to by some single index that would say "use standard table 1" or something like that. In retrospect, that might have been a good idea I think.) I.e. what actually determines the lossiness and "loss style" of the compression, what information is thrown away, are 128 (or just 64, or even 192) numbers (!). Not a single quality value. (It is in fact even possible to use different quantization tables for different parts of an image, I think. I have no idea how common such JPEG images are, and if any software in common use produces such.) The single quality value 1..100 that GIMP uses is passed to libjpeg's jpeg_set_quality() function. This function is used to scale two sample quantization tables given in the JPEG specification. But nothing forces some application to use linear scalings of these sample quantization tables. I don't know if the sample tables are even normative in the standard, or just informative. One might imagine some application even doing a clever analysis of an individual image to come up with image-specific quantization tables. The website http://www.impulseadventure.com/photo/jpeg-quantization.html seems to have a good collection and comparison of quantization tables used by different firmware and software implementations of JPEG compression. http://markcox.googlecode.com/svn/trunk/jpegdump/jpegdump/ has sources to a nice program one can dump the contents of a JPEG file, if one wants to have a look at the quantization tables used. There is another program with the same name at http://www.programmersheaven.com/download/17054/download.aspx that is less useful in general, but has one nice feature: it attempts a guess at the libjpeg-style quality factor used for the quantization tables. --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg quality factor.
[EMAIL PROTECTED] writes: > Here if I can do say 10 re-saves at 85% quality, it produces no > discernible changes in picture quality. Presumably you also re-load the image you just saved each time? --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg quality factor.
Guillermo Espertino writes: > The same image exported as jpeg with the same quality factor (let's take > 75% as an example) Where did you get that percent sign from? GIMP doesn't show any percent sign. The quality value is not a percentage of anything. You should just treat it as a number on a nonlinear scale between 1 and 100. (With the usable range being between 70 and 95, say.) (What would it be linear to? File size? Perceived quality, as if that could even be quantized?) It is not necessarily related to corresponding scales in other software at all. The only thing one can know is that the higher the number is, the less compression artefacts one should see (and the bigger the file will be). > Both programs calculate the compression ratio differently. That is no surprise, as they use different JPEG software. You shoukd not think of the JPEG quality value as some "compression ratio" or any other "ratio". It is just a number whose exact meaning you will have to check from the libjpeg sources in GIMP's case. It is just a coincidence that both programs in this case happen to use a scale from 1 to 100. --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] about carol
Campbell Barton writes: > Since carol had the composure to be civil with people face-to-face makes > me think that she does KNOW BETTER... I am not so sure. At LGM2007 there was at least one occasion where I was present when carol started her typical carol-speak, and (predictably) directing odd insinuative questions to one of the female developers present. I guess most of us others just thought "oh. here we go again" and tried to pretend we didn't listen (at least I did). Luckily the subject of carol's harrassment this time understoof what was going on and didn't bother feeding the troll, so nothing more serious happened. --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] how to
(Let's keep this discussion on the gimp-developer list. In general, please don't reply privately to messages sent to a mailing list. At least in Open Source circles that is commonly considered rude. The purpose of public mailing lists is to keep the discussion open and archived.) > I am a newbie,and I haven't used Linux. But now I want to study > GIMP in Windows. Do you just want to study (read) the source code? Well, you already have it... Or do you want to work on implementing some changes or fixes to GIMP? > I really want a project which works as GIMP in Windows. Hmm, what do you mean with this? Do you want to create a competing application? Hopefully you aren't planning to use GIMP source code in a way that is against its license? > What should I do? You can start by describing what programming background you have. It's impossible to know what kind of advice you need without knowing that... What programming environments are you used to? What programming languages have you used? For how many years? --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] how to
> I am a newbie to GIMP. I have downloaded gimp-2.2.13.tar.gz, but I > have a problem now. I don't know how to compile it in WindowsXP. Are you really sure you want to? Have you built any non-trivial Open Source software on Windows (or on Linux even) earlier? (Just running "./configure && make install" on Linux without understanding what is happening doesn't count.) If not, don't start with GIMP... --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.4 release date
SorinN writes: > That's why we need a Gimp PRO, Inkscape PRO, Scribus PRO - someone, a > Firm / Govern / Foundation / Linux Distro / Billionaire ...or a > mixture of them must hire core developers of all 3 projects - put them > into a big WEB / DTP Core Linux project and manage development and > releases. If they saw any money making potential in it, they presumably would? None of the commercial Linux companies which one would assume have very skilled market analysts etc that can do research to find out what is worth doing has seen much business in funding work on GIMP or Inkscape to the extent of actually hiring developers so far. The closest thing, I guess, is that f-spot is being developed by a paid employee. Plus, OpenOffice.org has lots of paid developers, and it includes some rudimentary graphic capabilities. This should tell you something. Not sure what;) --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Tools
Federico Alcantara writes: > I am interested in knowning if Gimp is written in C/C++, There is no programming language called C/C++. GIMP is written in C. It can be scripted in Scheme (a dialect of Lisp), and the usual suspects Perl and Python. > and which tools are needed to compile, debug, and test it? A compiler, a debugger, and a human tester. Which compiler and debugger depends on the platform. On Linux and most other Unix systems, that would be the GNU ones, gcc and gdb. Proprietary compilers like Sun's compiler on Solaris can be used, too. On Windows either gcc or Microsoft's compiler can be used. --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimpwin install
Joao S. O. Bueno Calligaris writes: > How hard would it be to create a .msi installer for gimp + gtk+, > instead of the current zip files? The current installer zip file is just a wrapper around a single .exe file installer. (Just in case somebody confuses this with the gtk+ etc zip files on ftp.gtk.org and ftp.gnome.org that are different, they are "real" archives of an installed set of files, to be unpacked as such with no additional scripts or code executed.) If the .zip format is problematic because people tend to (unnecessarily) use the silly proprietary/shareware WinZip application (which I think was the case browsing the IRC backlog) to open .zip archives, would it be a good idea to also offer the .exe file separately? I guess the main reason for wrapping a single .exe file inside a .zip is to work around download restrictions. Some sites might prevent download of .exe files but do allow download of .zip files (yeah, how useful that is then...). There are no real size savings, at least for the gimp-2.2.13-i586-setup-1.zip: The .zip is 7930697 bytes, the single .exe inside is 7953024 bytes. > It seems to be quite standard nowadays, and a couple high profile free > software packages are uisng it. I have extensive experience with creating Windows Installer installers from my day job at Novell (working on OpenOffce.org). One can without a doubt say that Windows Installer technology is massively powerful, but on the other hand it can equally well be said to be massively over-engineered ;) One doesn't have to use all the features of course. One problem with Windows Installer is that it's so complex that there are umpteen additional products on top of it to make it supposedly easier to use for the packager and give a supposedly nicer experience for the end-user. When you google for more information about some murky point in the base technology, all you find is pages related to these various add-on packages... (In the OpenOffice.org case, no such external add-on is used. The OOo installer is built using a shitload of complex Perl code that manipulate the data files from which the Windows Installer database is built using the Microsoft SDK tools. This is much more complex than it would need to be because of historical reasons.) Microsoft itself has an Open Source (!) add-on toolset for Windows Installer, WiX (http://wix.sourceforge.net/ , http://www.tramontana.co.hu/wix/). (Hmm, at least I think I have read that WiX is sponsored by Microsoft, although it can't find that explicitly mentioned now when quickly browsing their sourceforge site.) Maybe WiX would be something worth looking into? Seems like it could be a fresh start with little historical baggage. --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] lcms plugin crashing
Hal V. Engel writes: > I have noticed that recent CVS builds will issue the following error when > opening some files with embedded profiles: How recent? Could this be the problem fixed by: 2007-01-03 Tor Lillqvist <[EMAIL PROTECTED]> * plug-ins/common/lcms.c (run): Fix mixup in retrieving the filename parameter. (Which fixed a crash in lcms for me.) --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Getting console messages from GIMP on Win32
David Gowers writes: > Is there some way of convincing GIMP to send warning/error/informative > messages to a useful place on Win32? Start GIMP with the command: gimp-2.2 >gimp.log 2>&1 from cmd.exe. This requires that you have added GIMP's bin folder to your PATH. --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [GIMP] Suggestion to simplify user interaction
Michael Natterer writes: > No. You don't want to look at emacs code. Really. While talking about Emacsish features, one feature I often miss in GUI apps is something equivalent to Emacs's C-h c (describe-key-briefly). I.e., a way to find out what a certain keypress does. The main use case for this would be when you by accident press the wrong key, and you don't immediately notice anything happening, but you still are afraid that by mistake you have done damage to your document. OK, so in most well-written apps Undo will undo any such inadvertent changes. (But if you don't know if your accidental keypress did anything or not, you don't know what Undo will undo...). It helps a bit if the menu entry for Undo says what the last operation that are to be undone is called. Or if the app has a history feature. But still... --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Win32 patch to fontconfig
Hi,
This patch should fix a couple of longstanding problems with
fontconfig on Windows that manifest themselves especially in GIMP. The
root cause to the problems is in Microsoft's incredibly stupid stat()
implementation.
See for instance http://bugzilla.gnome.org/show_bug.cgi?id=154968 and
http://www.codeproject.com/datetime/dstbugs.asp
--tml
--- /tmp/fontconfig-2.3.2/src/fccache.c Tue Jan 4 23:53:36 2005
+++ src/fccache.c Fri Aug 25 05:27:06 2006
@@ -43,0 +44,58 @@
+#ifdef _WIN32
+
+#include
+
+#ifdef __GNUC__
+typedef long long INT64;
+#define EPOCH_OFFSET 11644473600ll
+#else
+#define EPOCH_OFFSET 11644473600i64
+typedef __int64 INT64;
+#endif
+
+/* Workaround for problems in the stat() in the Microsoft C library:
+ *
+ * 1) stat() uses FindFirstFile() to get the file
+ * attributes. Unfortunately this API doesn't return correct values
+ * for modification time of a directory until some time after a file
+ * or subdirectory has been added to the directory. (This causes
+ * run-test.sh to fail, for instance.) GetFileAttributesEx() is
+ * better, it returns the updated timestamp right away.
+ *
+ * 2) stat() does some very strange crap related to backward
+ * compatibility with the local time timestamps on FAT volumes and
+ * daylight saving time. This causes problems after the switches
+ * to/from daylight saving time. See
+ * http://bugzilla.gnome.org/show_bug.cgi?id=154968 , especially
+ * comment #30, and http://www.codeproject.com/datetime/dstbugs.asp .
+ * We don't need any of that crap, FAT and Win9x are dead. So just use
+ * the UTC timestamps from NTFS, converted to the Unix epoch.
+ */
+
+static int
+FcStat (const FcChar8 *file, struct stat *statb)
+{
+ WIN32_FILE_ATTRIBUTE_DATA wfad;
+
+ if (!GetFileAttributesEx (file, GetFileExInfoStandard, &wfad))
+return -1;
+
+ statb->st_mtime = (*(INT64 *)&wfad.ftLastWriteTime)/1000 - EPOCH_OFFSET;
+
+ if (wfad.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY)
+statb->st_mode = _S_IFDIR;
+ else
+statb->st_mode = _S_IFREG;
+
+ /* Don't bother with other mode bits or other fields, they aren't
+ * looked at by the code in this file.
+ */
+ return 0;
+}
+
+#else
+
+#define FcStat stat
+
+#endif
+
@@ -342 +400 @@ FcGlobalCacheCheckTime (const FcChar8 *f
-if (stat ((char *) file, &statb) < 0)
+if (FcStat ((char *) file, &statb) < 0)
@@ -836 +894 @@ FcGlobalCacheUpdate (FcGlobalCache *cac
-if (stat ((char *) file, &statb) < 0)
+if (FcStat ((char *) file, &statb) < 0)
@@ -965 +1023 @@ FcDirCacheValid (const FcChar8 *dir)
-if (stat ((char *) dir, &dir_stat) < 0)
+if (FcStat ((char *) dir, &dir_stat) < 0)
@@ -970 +1028 @@ FcDirCacheValid (const FcChar8 *dir)
-if (stat ((char *) cache_file, &file_stat) < 0)
+if (FcStat ((char *) cache_file, &file_stat) < 0)
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Re: gimptool-2.0 installed on Windows XP?
PLinnell writes: > Here is how Scribus launches GIMP on Win32 from within Scribus: > [...] If I am wrong, I hope someone corrects this. I am sure you are right, but I don't see what your answer has to do with the original question ;) gimptool-2.0.exe, and the header files and import libraries for GIMP 2.2, can be found in http://www.gimp.org/~tml/gimp/win32/gimp-dev-2.2.7.zip . Yes, I know the current GIMP 2.2 version is 2.2.11, but the API hasn't changed (that's the point with stable versions), so even if this developer package is for 2.2.7 it will work fine for plug-in development for any GIMP 2.2.x. There probably ought to be a public link to this file somewhere, people ask for gimptool-2.0 on Windows now and then. --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Plea for a new interface for the GIMP
Carol Spears writes: > another really awesome approach to fixing this problem would be to write > a window manager for windows! you would become famous and wellknown in > all of the software communities if you could accomplish such a task! Hmm, no. Don't mix up things here. The X11 protocol was designed from the start to have well-defined and well-separated special clients called "window managers" that do a specific job and are interchangeable, and there is no *the* standard window manager. In Windows, however, things are way different. Sure, there are some 3rd-party replacements for the Explorer "shell" (which is what corresponds most closely to the concept of window manager in X11). But I don't think one can seriously consider them more than fringe efforts. (Sure, I am certain they have a bunch of fanatical followers as fringe efforts usually have...) > the standards for this window manager that all of the cool free software > applications have agreed to use can be found at: > http://www.freedesktop.org so if you follow those guidelines, you will > be working with us and not against us. Yeah, but the specifications and guidelines on freedesktop.org are explicitly specific to X11. Their relevance for GTK (and GIMP) on Windows is that if they define how things should work on X11, and then if there is a program that exercises some specific window state manipulation functionality on X11, one can then look at that program's behaviour on X11 as a model when implementing the same functionality on GTK/Win32. Many of the problems related to GIMP window management on Windows are simply because of bugs in GTK on Win32. Fixing these bugs is just a matter of somebody having the time and inspiration to do it, and most importantly, to verify that fixing one thing doesn't break something else... It would be most welcome to have a set of minimal test programs that would exercise specific window management features that are visible though the platform-independent GTK API, so that one could then hack GTK/Win32 until the programs behaves as close as possible as on X11 (using some popular and hopefully standards-conforming window manager). These test programs would then also form a regression test suite. To put it a bit bluntly, much of the window state manipulation functionality in GTK has just appeared in the X11 backend, with little specification what it should exactly do, and what function call sequences are expected to work and what aren't necessarily expected to work. (For instance, is it expected to work if a program sets a GTK window decorations before the underlying real GDK window has been realized?) It shouldn't be hard to understand that the Win32 implementation then has been partly just guesswork, which happens to work well with some programs, but not with others. --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: pspi for gimp on linux
cedric GEMY writes: > But how are these filters licensed by Adobe ? What "these" filters? As I said, pspi doesn't even work with Adobe's filters (those that are bundled with Photoshop). Even if it did, I don't know whether your Photoshop license would allow them to be used with other plug-in hosts. As for 3rd-party filters, why would their vendors want to restrict what program they are used with? The more customers 3rd-party filter vendors get, the happier they are, presumably. There are lots of programs other than Photoshop that can use Photoshop plug-in filters: PaintShopPro, Xara, and IrfanView for instance. --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Re: pspi for gimp on linux
e extensions .EFF and .DLL are checked to see if they are Photoshop plug-ins. Reverse engineering === The hardest thing in writing this plug-in was figuring out the stuff in the Photoshop plug-in communication that isn't clearly documented. To make the reverse engineering easier, I wrote a "proxy" Photoshop plug-in, piproxy. The Windows resources of a real Photoshop plug-in (the "target") is copied to piproxy.8bf. The target should be moved away so that Photoshop won't find it, and instead piproxy.8bf shouild be put where Photoshop will find it. Thus, piproxy gets loaded when the menu entry for the original plug-in is invoked. It then loads the original target plug-in, and starts passing calls back and forth between Photoshop and the target, while logging the stuff that passes through. This works fine. If you intend to run piproxy, set the PIPROXY_LOG and PIPROXY_TARGET environment variables. See the source code. The piproxy sources are included, but it does not get built by default. After a week of late-evening hacking, the breakthrough came when I realized that the "Handle" type in the Photoshop API is used by some plug-ins in an undocumented way. Instead of treating a Handle as an opaque type, they "know" that a Handle in fact is a pointer to a pointer, and use it like that without calling the "lock" API which is the documented way to get the pointer from a Handle. Tor Lillqvist <[EMAIL PROTECTED]>, December 2001, March 2006. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Why be cryptic? 'Xtns' should be name 'Extensions'
Brendan writes: > Please, oh Lord, someone fork Gimp. I can imagine the scenario: (This is a parody, not a flame) Someones forks GIMP, sets up a project on (say) SourceForge. He spends lots of effort on the project's web page. (He is a c00l web designer.) It has a long list of features that this forked GIMP will have. The small print at the bottom says "looking for developers". --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Why be cryptic? 'Xtns' should be name 'Extensions'
Martin Nordholts writes:
> I've have experience with both of Photoshop and GIMP, and I don't agree. To
> me Photoshop's interface is much more thoroughly designed.
Well, using usability expertise and the experience of real power GIMP
users in (re)designing GIMP's UI is something which the GIMP
developers are actively doing now. But as Sven said, the point is not
to make GIMP look like Photoshop.
> At first I had a hard time grasping the philosify behind
> Photoshop's interface, but after taking a class where we learned
> PS, it all made sense.
The same approach would work as well for GIMP, too.
> Well, I think it should! If there is any software today that has
> potential to be a PS counterpart, it is GIMP. I mean why, would we
> not want it to be Photoshop?
Why would we want it to be Photoshop?
That would be silly. It will take years for GIMP to have the same
features as Photoshop has now, and by then, Photoshop will have
evolved again ;) This is just a fact that I assume most fellow GIMP
developers realize. GIMP developers are not motivated by making PS
users switch. Most of the (actually quite few) GIMP developers work on
GIMP because they love to program. Not because GIMP wants increased
market share.
> It would be more logical to have a separate toolbox, and a separate 'GIMP
> window'. The GIMP window would be a container for toolbox window, the layer
> window etc (á la PS).
No, having a big GIMP window with the image and tool dialogs inside it
is definitely something that the developers don't want to implement
(themselves).
However, the way free software works is that if somebody wants a
feature hard enough, they write a patch that is clean and implements
the feature, and submit that to the maintainers. (Or alternatively,
they convince (perhaps through funding) somebody, like their Linux
distro company, to write the feature.)
The writer of such a patch should also be prepared to maintain her
code for at least some years. It's not nice to just dump a bunch of
code on people who are kind enough to accept it even if they don't
really like the features it provides, and leave.
I assume GIMP maintainers would gladly accept such a patch as long as
it was well-written and clean. That would at least make a part of the
users happier.
("Clean" meaning here that it doesn't unnecessaily stomp on other
parts of the code, uses the same coding style as the rest of the code,
and doesn't break anything else.)
It would have been much more productive if the author of the "GIMP
deweirdifyer", for instance, would have cooperated with GIMP
developers and searched for ways to have that code in the official
GIMP sources instead of as a freestanding separately distributed tool.
> If you don't take the time to understand that interface, it will
> feel unlogical (I had the same feeling) and it can easily be
> dismissed as 'badly designed'. Once you know it though, the
> workflow is absolutley brilliant.
This can be said about GIMP, too. Watching an experienced GIMP user
work can be a revelation. The GIMP workflow looks absolutely brilliant
then, too.
--tml
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] support for the PSD
Bart writes: > BTW the SDK is available on other sites on the net i posted the url at > the beginning of that thread. Surely you aren't suggesting that we should use illegally (well, against its license anyway) redistributed copies of the PS6 SDK to improve the psd plug-in? That would be very unethical and also greatly increase the risk of attacks from Adobe's lawyers. --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Photoshop PSD 6 format Spec / Gimp XCF format Spec
Alexandre Prokoudine writes:
> > 8bi files working on Mac and Win only (as far as i know).
> *cough*
> http://tml-blog.blogspot.com/2006/02/photoshop-filters-in-gimp-on-linux.html
pspi handles only .8bf files ("filter" plug-ins), though. (It would be
possible extend it to handle file format plug-ins, too, for some value
of "possible".)
--tml
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 16bit channels, doh
Brannon King writes: > compositing (I think that term refers to handling/merging the image > data formats) Umm, no. As far as I know compositing refers to the handling/merging of the layers of an image. In a future GEGL-based GIMP, layers can also be "algorithmic", for example: a blurring layer. (Photoshop calls these "adjustment layers".). Layers can also form a general directed acyclic graph, not just a linear stack as now. --tml ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer]
Yavala writes:
> Can someone help me with the simple plug-in (hello message
> box)http://developer.gimp.org/writing-a-plug-in/1/index.html?
Well, the most obvious error is that there is no initial '#' character
on the line where you try to include libgimp/gimp.h. (Have you never
programmed in C before?) It should look like this:
#include "libgimp/gimp.h"
You also need to have the PLUG_IN_INFO array and MAIN(). Add the
following to the bottom of the source file:
GimpPlugInInfo PLUG_IN_INFO =
{
NULL, /* init_proc */
NULL, /* quit_proc */
query, /* query_proc */
run, /* run_proc */
};
MAIN ()
The menu path to the plug-in that is passed to
gimp_install_procedure() needs to start with . Change it as
follows:
gimp_install_procedure (
"plug_in_hello",
"Hello, world!",
"Displays \"Hello, world!\" in a dialog",
"David Neary",
"Copyright David Neary",
"2004",
"/Filters/Misc/Hello world...",
"RGB*, GRAY*",
GIMP_PLUGIN,
G_N_ELEMENTS (args), 0,
args, NULL);
}
With these changes your plug-in compiles and works fine with GIMP 2.2.
--tml
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Compiling a Simple Plug-in.
Yavala writes: > Can anyone show me how to compile the simple Plug-in1 "hello' message on > GIMP. > The simple plugin for gimp is available at this link > http://developer.gimp.org/writing-a-plug-in/1/index.html. I don't see any complete source code on that page, unfortunately. What did you do, paste together the code snippets on the page? > I have included one header file called libgimp.h which is similar > to #include from the developers website. So you say, but then the error messages you include below talk about gimp.h? > gcc.exe "D:\New Folder\hello.c" -o "D:\New Folder\hello.exe" Hmm, actually using a folder called "New Folder" does not seem like a terribly bright idea. You are supposed to rename folders you create to some meaningful name. I would also recommend not using spaces in folder names, it can cause various problems sooner or later. > D:\New Folder\/gimp.h:10: error: syntax error before '*' token Is this gimp.h something you created yourself, or where did you get it from? And why is it in "New Folder"? If it is the standard gimp.h from a GIMP distribution, it should be in a subfolder include\gimp-2.0\libgimp of where you installed the GIMP developer files [1]. Anyway, the normal gimp.h has about twenty lines of comments at the beginning, so how can line 10 have a syntax error? --tml [1] There doesn't seem to be any GIMP development package for Win32 at the gimp-win.sf.net site. There is one at http://www.gimp.org/win32/gimp-dev-2.2.7.zip . Maybe it should be advertised somewhere, although I initially intended it to be just temporary until gimp-win.sf.net would offer also a developer package. If you haven't already gathered the same headers and import libraries from somewhere else, you probably want to download that and point your compiler to use headers and (import) libraries from there. ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP 2.3.4
lode leroy writes: > The thing is that for compiling gimp from cvs, you need quite some expertise > in the autotools, libtool, aclocal, pkg-config etc to fix those > not-100%-working-together- distributed binaries... > Would it be feasible to create a big zip-file that contains everything for > gimp for download? It would be possible, but wouldn't such a zipfile just create open up the possibility for even more confusion when there would then be yet another distribution of these libs? (A long time ago I *did* distribute self-built jpeg, tiff, zlib and whatnot, but stopped doing that as there were other distributions, too, that were just as good, or even more directly from the source, like zlib.) --tml ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP 2.3.4
lode leroy writes: > In fact, what happens is that when linking with ZLIB.DLL, > the exe expects ZLIB-1.DLL instead of ZLIB1.DLL. (or vice-versa). The official zlib dll is called zlib1.dll. Any other name means it is not official. "Official" as in directly from real maintainer of zlib. As the actual maintainer of zlib distributes Win32 zlib binaries, I fail to see any reason why one would want to use anybody else's version. I have only zlib1.dll on my system. Don't know about the other examples you list. Presumably caused by confusion at the "gnuwin32" (not related to GNU) site. You really should try to find a coherent set of interdependent packages. Is it so that the GTK+ binaries I depend on differently named DLLs than what gnuwin32 currently distribute? Argh, I just hate that kind of instability. --tml ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP 2.3.4 crash on winxp
John Cupitt writes:
> > glib-2.8.2 glib-dev-2.8.2 gtk+-2.8.4 gtk+-dev-2.8.4 pango-1.10.0
> > pango-dev-1.10.0 atk-1.10.1 atk-dev-1.10.1 cairo-1.0.0 cairo-dev-1.0.0
> You pango and atk seem very old, but your glib and gtk seem too new.
No, atk 1.10.1 and Pango 1.10.0 are quite new, the latest
versions. (Actually, for performance reasons, one should make sure to
use the latest pango 1.10.0 snapshot (20050922) from the ftp.gtk.org
site.) (GTK+ 2.8 won't even work with any older Pango.) They are
available from ftp.gtk.org but not really "advertised" yet on the GTK+
for Win32 download page on the GIMP site.
Sigh, I had hoped that the infamous "shape.c: line 75" assertion
failure would have been a thing of the past with GTK+ 2.8 and Pango
1.10. But apparently not. Try the usual stuff, mainly try without the
ms-windows theme ("wimp"). (Edit the etc/gtk-2.0/gtkrc file.) Or check
what your default font in the Display Properties is, try changing that
to for instance Arial.
--tml
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP 2.3.4
> > There is no longer a gimp on windows mailing list, > Well, for a list that doesn't exist it is pretty active... > http://groups.yahoo.com/group/gimpwin-users/ I guess rockwalrus meant there is no *developer-oriented* Windows-specific GIMP (or GTK+) list. That's true. --tml ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP 2.3.4
Lance Dockins writes: > 1) Is there a way to get python to work on Windows Yes. Personally I have so far not really been interested in Python and haven't attempted to build the Python scripting support. But others have it working. > AND is it even necessary to build GIMP? No. > 2) Where do I install/unzip the all the auto tools? Should I just unzip > them to a location in MinGW and use the export command to include those > directories? I'm assuming that I don't need a special Win32 build of > these tools so I've just downloaded them from their respective > locations. Hmm, you downloaded the auto* sources, or ready-built packages (from where?)? Anyway, you can install them (after building them) anywhere, as long as the executable commands are found in PATH. GIMP HEAD requires newer autotools than what's in the MSYS-DTK package, unfortunately, so I guess you really need to build them yourself. (I don't recall which one of the autotools it is that's too old in MSYS. Probably automake?) --tml ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP 2.3.4
michael chang writes:
> Solution: Linux/POSIX emulation layer. Cygwin is usually used.
Actually, I think MSYS is more commonly used nowadays, or Microsoft's
own Interix. Cygwin is a bit too heavy, and has a tendency of
occasionally getting too much in your way. Please note the use of
POSIX emulation is for running the build tools (shell, sed, m4, make,
awk, expr, perl etc) only, not GIMP itself.
(It presumably is possible to build GIMP to run itself under some
POSIX emulation like Cygwin, of course, but then it isn't GIMP on
Windows, but really GIMP on yet another Unix (that just happens to be
emulated on top of Windows).)
> You'll also need the development codes for various graphics libraries,
> e.g. libpng-dev. These are provided in sepearte packages (e.g. select
> in the Cygwin Installer)
No. Cygwin's libpng etc development packages are for building Cygwin
programs. I don't think Cygwin packages stuff like libpng for
cross-development to native Win32 ("mingw"), although they do provide
the cross-compiler (gcc -mno-cygwin) and C runtime and Win32 headers
and libraries (w32api).
The www.gimp.org/win32/downloads.html page has links to Win32 packages
of the required dependencies.
--tml
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
R: [Gimp-developer] Error compiling gimp 2.3.3 with mingw on winxp
Paolo Magnoli writes: > Hi, I've put up a file with that line only in it and tried to compile it, I > got the same error: > /mingw/include/unistd.h:13:27: no include path in which to search for > unistd.h There must be something broken in your mingw installation. I have never seen that message myself, but some googling leads me to believe it is related to the #include_next directive? Does your unistd.h (the file d:/mingw/bin/../lib/gcc/mingw32/3.4.2/../../../../include/unistd.h, i.e. d:/mingw/include/unistd.h) on line 13 have an #include_next directive? (That's funny, as I too have gcc 3.4.2, but my unistd.h does not contain any #include_next.) If you can't find any other solution, my suggestion is removing all of mingw and re-install... --tml ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Error compiling gimp 2.3.3 with mingw on winxp
Paolo Magnoli writes: > /mingw/include/unistd.h:13:27: no include path in which to search for > unistd.h Huh? That's a very odd message. What happens if you compile a trivial source file that just contains the line "#include "? --tml ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] A Visit to GIMP
Carol Spears writes: > even photographs from the way back past would be interesting. http://www.flickr.com/photos/tml/tags/gimpcon/ --tml ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] authors.xml, volunteer needed
Stephen Robert Norris writes: > I wrote the original Plasma plugin, Displace plugin and... waves? > plugin... It's been a while. OK. As Sven said, no big changes are expected. I assume all who can't be with 100% certainty classified as "documenter" or "artist" will stay as "author". --tml ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] authors.xml, volunteer needed
Based on ChangeLog* po*/ChangeLog: Index: authors.xml === RCS file: /cvs/gnome/gimp/authors.xml,v retrieving revision 1.6 diff -u -0 -r1.6 authors.xml --- authors.xml 20 Aug 2005 02:28:29 - 1.6 +++ authors.xml 27 Aug 2005 09:48:39 - @@ -26 +26 @@ - Robert Brady + Robert Brady @@ -30 +30 @@ - Carey Bunks + Carey Bunks @@ -38 +38 @@ - Kenneth Christiansen + Kenneth Christiansen @@ -48 +48 @@ - Gert Dewit + Gert Dewit @@ -58 +58 @@ - Valek Filippov + Valek Filippov @@ -64 +64 @@ - Sami Gerdt + Sami Gerdt @@ -76,2 +76,2 @@ - Henrik Hansen - Ville Hautamäki + Henrik Hansen + Ville Hautamäki @@ -85 +85 @@ - Andreas Hyden + Andreas Hyden @@ -87 +87 @@ - Krzysztof Jakubowski + Krzysztof Jakubowski @@ -90 +90 @@ - Fellmann Joaquim + Fellmann Joaquim @@ -127 +127 @@ - Daniele Medri + Daniele Medri @@ -130 +130 @@ - James Mitchell + James Mitchell @@ -135,2 +135,2 @@ - Yukihiro Nakai - Sung-Hyun Nam + Yukihiro Nakai + Sung-Hyun Nam @@ -138 +138 @@ - Felix Natter + Felix Natter @@ -153 +153 @@ - Sergey Panov + Sergey Panov @@ -158 +158 @@ - Artur Polaczynski + Artur Polaczynski @@ -162 +162 @@ - Vincent Renardias + Vincent Renardias @@ -169 +169 @@ - Pablo Saratxaga + Pablo Saratxaga @@ -182 +182 @@ - Carol Spears + Carol Spears @@ -187 +187 @@ - Yuri Syrota + Yuri Syrota The following names I couldn't find in the ChangeLogs, somebody else could grep through the mailint list archives. My apologies if I have missed someone obvious whom I should know by name. Karl-Johan Andersson John Beale Marc Bless Edward Blevins Reagan Blundell Xavier Bouchoux Roberto Boyd Brent Burton Francisco Bustamante Albert Cahalan Sean Cier Ed Connel Brian Degenhardt Scott Draves Daniel Dunbar Misha Dynin Morton Eriksen David Forsyth Jochen Friedrich Jim Geuther Graeme Gill Heiko Goller Marcelo de Gomensoro Malheiros Michael Hammel Jan HubiÄka Simon Janes Andrew Kieschnick Philipp Klaus Karl La Rocca Laramie Leavitt Elliot Lee Wing Tung Leung Ingo Lütkebohle Ed Mackey Ian Main Torsten Martinsen Hirotsuna Mizuno Balazs Nagy Stephen Robert Norris Tim Newsome Erik Nygren Thom van Os Mike Phillips Jens Restemeier Daniel Risacher James Robinson Tim Rowley Mike Schaeffer John Schlag Norbert Schmitz Thorsten Schnier Tracy Scott Aaron Sherman Daniel Skarda Mike Sweet Michael Taylor Ian Tester James Wang Kris Wehner Nigel Wetten --tml ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
