Re: [Gimp-developer] Icons for layer modes
On 2009-10-03, yahvuu yah...@gmail.com wrote: Using an analogy, the current situation for blending is like not having the curves tool, but only preset curves to choose from. And indeed there's a relation between curves and blending, for each RGB blend mode can be described as a set of 256 curves, at least within 8bit-accuracy. A curve is a function of one variable. A layer mode is a function of two variables (value of a current level, and value of the composite of levels below it; here value is, typically, the level of R/G/B considered separately). [Here I assume Porter-Duff semantic of layer modes, so transparency is handled automatically when a function of 2 variables is given. Otherwise (as with Dissolve) it is two functions of 4 variables: given levels and transparency of this level, and those of the composite below, one gets new level and new transparency.] The problem with your proposal is 2-fold: 1) Invert is just a particular case of an apply-curve; let's remove this redundant misfeature; 1') Likewise for levels. 2) More seriously: a graph is a convenient down-to-earth representation of a function of one variable. It allows a simple intuitive concept of direct manipulation. I never saw a similar in convenience UI to directly manipulate a function of two variables. Hope this helps, Ilya P.S. When GIMP has a JIT compiler present, there would be no significant problem in representing a layer mode as a programming language CODE implementing a function of two variables. [Note similarity with how shaders in OpenGL work...] ___ 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?
On 2009-10-21, David Gowers 00a...@gmail.com wrote: 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, it means the bugs are in GTK+, not GIMP, It was GIMP's decision to use GTK+, so any bug in GTK is automatically a bug in GIMP - and a responsibility of GIMP maintainers. and it requires GTK+ developers who run Windows to fix these bugs (or a GIMP developer who runs Windows and has some knowledge of GTK+ and an inclination to fix these bugs). Do you seriously think a person running Linux is going to be able to reliably fix a bug that only shows up on Windows? Now you know that your question was very misdirected, right? [Judging by your other post.] Your expectations that GIMP will exert such extreme control over the window management are also unreasonable. No. Expectations of a user that things work the way they are documented are NEVER unreasonable. They may be unconvenient/embarassing to developers, but this is a different topic... Your window manager manages your windows, GTK+ communicates to the window manager what window behaviour GIMP is asking for, GIMP communicates to GTK+ what window behaviour it wants. You write as if I care how things are implemented (and as if I do not know this ;-). The particular 'communications breakdown' is between GTK+ and the Windows window manager, GIMP is not involved in the problem, only a casualty of it. Wrong. And even if it were true, the problem is *with GIMP*, not with some intermediaries. WMs differ; this is a fact of life. When developers hide their heads in sand (it just works with my WM), it is nothing to be proud of... Ilya ___ 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?
On 2009-10-21, Alexandre Prokoudine alexandre.prokoud...@gmail.com wrote: Good to know; so let me refine: is there ANYTHING in the move to single window which would not be achieved by a) restricting the maximal size of image window to the gap between two toolboxes; and b) making z-order changes syncronized between the main window and toolboxes? As mentioned before, synchronized panning in tiled image windows, for instance. Great! So ANYTHING-question is answered. How about a complete list? ;-) Thanks, Ilya ___ 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] Icons for layer modes
Ilya Zakharevich wrote: On 2009-10-03, yahvuu yah...@gmail.com wrote: Using an analogy, the current situation for blending is like not having the curves tool, but only preset curves to choose from. And indeed there's a relation between curves and blending, for each RGB blend mode can be described as a set of 256 curves, at least within 8bit-accuracy. The problem with your proposal is 2-fold: [..] naa, don't worry, this wasn't meant as a proposal to replace layer modes. The analogy was given to show why the the current interface to blending (i.e. choosing among a discrete set of layer modes) is a poor one: it is both limited and mostly non-intuitive. Developing a proper successor for layer modes remains an open challenge. regards, yahvuu ___ 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?
On Wed, Oct 21, 2009 at 12:14 PM, Ilya Zakharevich wrote: It was GIMP's decision to use GTK+ You made my day :) The particular 'communications breakdown' is between GTK+ and the Windows window manager, GIMP is not involved in the problem, only a casualty of it. Wrong. And even if it were true, the problem is *with GIMP*, If a particular system service in Windows gets broken and some apps don't work as expected, would it be their developers fault? :) I can see how a John Do can blame GIMP for GTK+ issues, but I don't see why GIMP developers should bother about John Do's misconceptions about software development. Alexandre ___ 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?
On Wednesday 21 October 2009, Ilya Zakharevich wrote: Good to know; so let me refine: is there ANYTHING in the move to single window which would not be achieved by a) restricting the maximal size of image window to the gap between two toolboxes; and b) making z-order changes syncronized between the main window and toolboxes? IMHO the move to a single image window with dockables would solve quite a lot of interoperability problems. For example there are plenty of broken window managers out there. Relying on them (WM developers) getting it right in the end for the GIMP is proving to be a long wait. As desktop environments go the window managers that work with the GIMP as intended tend OTOH to be the ones that don't play well with KDE for example (if you even have the choice, which you haven't really in KDE4). Oh and windows is a beast that isn't handled easily as well - the window manager there sucks at managing applications that consist of multiple single windows that don't have a proper native inheritance structure - which places the problem either into the GTK+ ballpark (a vital library once created to suit GIMP but which now is driven by people with their own development goals which don't necessarily match the GIMP requirements any longer) or forces the GIMP developers to avoid this area in the long run. Besides that there are things like split layer views that I'd like to see - for example editing a layer mask side by side the image area it belongs to which IMHO are next to impossible with the current multi window arrangement. -- mfg Karl Günter ___ 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?
Hi all, Alexandre Prokoudine wrote: I can see how a John Do can blame GIMP for GTK+ issues, but I don't see why GIMP developers should bother about John Do's misconceptions about software development. perhaps the Windows version should wear a 'beta port of GTK+' disclaimer as a nag-screen. Seriously. The most annoying buggy software is buggy software which you expected to work flawlessly. As Ilya points out, it's legitimate that users blame the GIMP project. So i think a warning upfront can reduce the frustration, and also communicate the responsibilities a bit. regards, yahvuu ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Airbrush/Brush Banding Effect At Low Pressure/Opacity
On Oct 20, 2009, at 1:39 PM, Sven Neumann wrote: Hi, On Tue, 2009-10-20 at 12:22 -0800, Christopher Howard wrote: Though having a far from sufficient understanding of how the GIMP brush painting process works, it seems to me like this is the fundamental problem: In making black-and-white brushes semi-transparent, GIMP somehow levels out the grey-scale, so that certain ranges of darkness become the same. On a fuzzy brush, the result is that the fine graduation is changed to appear stepped or banded. The problem here is that the brush masks are 8bit only. With such a limited set of values to start with, banding is basically unavoidable. Sven You should be able to get rid of most of the banding by performing error diffusion when multiplying the opacity into the brush mask. I suspect that a simple 1d error diffusion algorithm will be sufficient and I wouldn't bother with a Floyd-Steinberg type algorithm unless you could come up with an example where the simpler algorithm showed visible artifacts. I believe the function that introduces the banding is apply_mask_to_sub_region in paint-funcs.c or in the function apply_mask_to_alpha_channel depending on your point of view. I have not worked with that code in a long time and I could be wrong about that. You will need to make the starting error term effectively random or you run the risk of letting the upper-left pixel in each tile get special treatment. Good luck, Jay Cox jay...@gimp.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] using a parasite in a python import/export script
Hello, If this is the wrong list for my question, please tell me the right place for it. I wrote an exporter script (to a new file format) in python. This script requires the user to choose the location of some other file, amongst other settings before saving the image so in the call to the register function, there is the following: (PF_BOOL, compression, _(Use _compression (LZO, not yet implemented)), True), (PF_FILE, ftsarc, _(The ftsarc binary), /some/path/to/some/file) Once the user selected that file, I would like to keep that setting in mind to avoid him the need to re-select it, as it is very likely to never change. I could do this by saving it into a well-defined file, like ~/.something, but that sucks (I don't like to pollute the filesystem). I found that the png exporter plugin uses parasites for this, that sounds interesting. Now, trying to read my parasite is a problem, I need to read it before the call to register but at that time, the GIMP system doesn't seem to be ready yet. Just doing: print gimp.parasite_list() in the script will print out the error: LibGimpBase-ERROR **: gimp_wire_write_msg: the wire protocol has not been initialized aborting... (gimp:17350): LibGimpBase-WARNING **: gimp: gimp_wire_read(): error to the console. Is there any other way to achieve what I want? (Without saving it to a well-defined file in the user's home) -- Regards, Lucas http://arkana-fts.sourceforge.net ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] using a parasite in a python import/export script
I found that the png exporter plugin uses parasites for this, that sounds
interesting. Now, trying to read my parasite is a problem, I need to read it
before the call to register but at that time, the GIMP system doesn't seem
to be ready yet. Just doing:
print gimp.parasite_list()
in the script will print out the error:
LibGimpBase-ERROR **: gimp_wire_write_msg: the wire protocol has not
been initialized
aborting...
(gimp:17350): LibGimpBase-WARNING **: gimp: gimp_wire_read(): error
to the console.
Is there any other way to achieve what I want? (Without saving it to a
well-defined file in the user's home)
Works for me. Here is a capture from my python console:
GIMP 2.6.4 Python Console
Python 2.5.4 (r254:67916, Dec 23 2008, 15:10:54) [MSC v.1310 32 bit (Intel)]
print gimp.parasite_list()
('exif-orientation-rotate', 'testing', 'jpeg-save-defaults')
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] using a parasite in a python import/export script
Works for me. Here is a capture from my python console:
GIMP 2.6.4 Python Console
Python 2.5.4 (r254:67916, Dec 23 2008, 15:10:54) [MSC v.1310 32 bit
(Intel)]
print gimp.parasite_list()
('exif-orientation-rotate', 'testing', 'jpeg-save-defaults')
Yes, in the python-console it works like a charm, I tested it there.
The problem is with the python scripts that get loaded during GIMP startup
(i.e. scripts in ~/.gimp-2.4/plug-ins), it seems they are loaded even before
some GIMP core.
Oh, if it may help, here are my versions:
Gimp 2.4.5 Python Console
Python 2.5.2 (r252:60911, Dec 1 2008, 18:10:01)
[GCC 4.3.1 20080507 (prerelease) [gcc-4_3-branch revision 135036]]
--
Regards, Lucas
http://arkana-fts.sourceforge.net
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Progressive escalation of help
On Wed, 2009-10-21 at 00:41 +, Ilya Zakharevich wrote: This is a very sad situation. Note that most of users won't be able to install GIMP documentation locally [*], and in today's state of mobility, people are very often without Internet access... [*] Try to understand how to get GIMP docs starting at http://www.gimp.org/windows/ I could not... (Most probably, *I* would be able to do it if I would not decide to restrict access to resources mentioned on www.gimp.org... But most users would be stuck at this point...) Oh, come on. If you click on the very first link on this page, you end up on http://gimp-win.sourceforge.net/stable.html which lists installers for all the available translations of the user manual for GIMP 2.6. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Progressive escalation of help
On 2009-10-21, Sven Neumann s...@gimp.org wrote: This is a very sad situation. Note that most of users won't be able to install GIMP documentation locally [*], and in today's state of mobility, people are very often without Internet access... [*] Try to understand how to get GIMP docs starting at http://www.gimp.org/windows/ I could not... (Most probably, *I* would be able to do it if I would not decide to restrict access to resources mentioned on www.gimp.org... But most users would be stuck at this point...) Oh, come on. If you click on the very first link on this page, you end up on http://gimp-win.sourceforge.net/stable.html which lists installers for all the available translations of the user manual for GIMP 2.6. But the point was that I did not want to install GIMP! I already had it installed, and wanted just to add documentation... The documentation of this link clearly says: Note that the user manual is an extra package So, obviously, I investigated OTHER links on this page... Yours, Ilya ___ 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?
On 2009-10-21, Alexandre Prokoudine alexandre.prokoud...@gmail.com wrote: The particular 'communications breakdown' is between GTK+ and the Windows window manager, GIMP is not involved in the problem, only a casualty of it. Wrong. And even if it were true, the problem is *with GIMP*, If a particular system service in Windows gets broken and some apps don't work as expected, would it be their developers fault? :) If they fix the defect - yes, of course. If not - of course it is their developers fault. Why do you ask, is not the answer obvious (most obvious if the problem happens on ALL windows systems)? The situation with free software is *slightly* more delicate. But only slightly; remember what fox explained to the little prince... I can see how a John Do can blame GIMP for GTK+ issues, but I don't see why GIMP developers should bother about John Do's misconceptions about software development. These are not misconceptions. Software does not modularize; at least not in the sense of dilution of responsibility. If you use a library, its bugs BUG YOU. Ilya ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
