Re: [Gimp-developer] single-window fix and WMs
On 2009-10-21, Karl Günter Wünsch k...@mineralien-verkauf.de 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. You are right, somehow I assumed that the problems of GIMP's window management would be solved. Taking into account the history, this was a short-sighted assumption. 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 BTW, I see again and again this assumption that the responsibility for observed problems of GIMP may be shifted to WM's problems. I never could understand it. [Keep in mind that my experience in apps--WM interaction is rather minimal - I participated in porting Perl/Tk toolkit from X11 to non-X11 system, and watched the corresponding mailings lists for slightly more than a decade.] Here is the picture as I understand the rare morcels I saw: a) on window creation, GIMP registers a few bits of information with GTK++; b) the exact meaning of these bits is not documented, and is known to vary widely; c) the observed results are most of the time not what one would want; d) the interpretation is that it's somebody else's fault. Obviously, I'm missing something... I hate to ask for somebody else's time, but I would appreciate a correction (or at least a reference to older discussions...). the window manager there sucks at managing applications that consist of multiple single windows that don't have a proper native inheritance structure I'm pretty sure that this is NOT how it happens in Windows. AFAIK, there is no window manager; each application is responsible to arrange the x/y/z-order of its toplevel windows itself (there is a simple callback interface for such arrangements). 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. Yes, this was already covered earlier in the thread... 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?
On 2009-10-21, Tor Lillqvist t...@iki.fi wrote: 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. So could you answer what is IMO the key question: 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? The limitations which may be addressed only by adding specific CODE to application (as opposed to specific DATA on the app-WM interface)... (This is just a restatement of my question on a parallel message in this thread, with subject single-window fix and WMs, so it is enough to answer one of them...) 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?
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] Icons for layer modes
On 2009-10-01, yahvuu yah...@gmail.com wrote: Technically, these are diagrams where the x-axis is the bottom layer brightness and the y-axis denotes the top layer brightness. The brightness difference caused by the blending operation is then color-coded as described above. The full explanation is available at: http://yahvuu.wordpress.com/2009/09/27/blendmodes1/#brightness_diff Yet another idea: for most of puzzling layer modes the mode is just a function F of two variables: level in current layer, and level L in composite of layers below (here level is the value of a particular channel). So for each value of level in current layer, one gets a *curve* applied to the composite of layers below (essentially, I consider the effect of the mode when the current level is a solid color). Moreover, for most of the modes, F is linear in level in current channel (or piecewise-linear on [0..128] and [128..255]). So in this variable, knowing F for very few values allows one to reconstruct F for the rest of the values. And it is not mentally hard to consider simultaneously 3 graphs of 3 functions: F(20, L), F(128, L), F(245, L). So what about the following icon: take some background color in good contrast with all gray20, gray128, and gray245. On this back, plot the graph of F(20,L) in gray20, etc. One gets an icon with 3 graphs. For me, it is going to be a much better visualization than a color-coded graph of a function of 2 variables. But it is quite probable that I'm not representative enough. What do you think? Yours, Ilya P.S. One could also combine both icons (maybe even one layered on top of another)... ___ 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-22, Alexandre Prokoudine alexandre.prokoud...@gmail.com wrote: On Thu, Oct 22, 2009 at 1:54 AM, Ilya Zakharevich wrote: 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. Yes, of course -- what? ;) Yes, it would not be their fault ;-). Mea culpa. (similar to one of the difference between Russian and English: in Russian, when you say Yes, you agree with what the other person says; in English, you just indicate that the correct statement has affirmative verb form [Yes it does vs No it does not). 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-23, g...@catking.net g...@catking.net wrote: If you see a homeless person with his hand out and give him burger, you don't expect him to come back and complain about the sauce. Obviously, you never did this. And one could even think that you never heard about food allergies (or had friends/relatives dying from it...). (OT, of course...) Ilya ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] single-window fix and WMs
On Sat, Oct 24, 2009 at 6:43 PM, Ilya Zakharevich nospam-ab...@ilyaz.org wrote: On 2009-10-21, Karl Günter Wünsch k...@mineralien-verkauf.de wrote: 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. You are right, somehow I assumed that the problems of GIMP's window management would be solved. Taking into account the history, this was a short-sighted assumption. There are no problems of *GIMP*'s window management. Your failure to understand this is the reason that people are getting annoyed at you. 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 BTW, I see again and again this assumption that the responsibility for observed problems of GIMP may be shifted to WM's problems. I never could understand it. WM is only responsible insofar as having the WM behaves in a consistent and predictable way is very helpful. On Linux, virtually all WMs conform to the ICCCM window management standard (the window management hints in GTK+ were designed based on ICCCM, I think). On Windows, the management conforms to no recognized standard. So the WM holds some responsibility in such misbehaviour. The main responsibility is GTKs. In the case where I confirmed the TAB behaviour, I suspect that's because I haven't configured AwesomeWM correctly: in my case it is focusing the toolbox window when it reappears, instead of keeping the focus on the image window.. this is what is preventing TAB from working, and it's definitely outside of both GIMP and GTK+'s scope to address this. I'm currently looking at how to fix my configuration. [Keep in mind that my experience in apps--WM interaction is rather minimal - I participated in porting Perl/Tk toolkit from X11 to non-X11 system, and watched the corresponding mailings lists for slightly more than a decade.] Here is the picture as I understand the rare morcels I saw: a) on window creation, GIMP registers a few bits of information with GTK++; b) the exact meaning of these bits is not documented, and is known to vary widely; Completely false. http://library.gnome.org/devel/gtk/unstable/GtkWindow.html http://library.gnome.org/devel/gdk/unstable/gdk-Windows.html#GdkWindowTypeHint Provides comprehensive documentation, even though it may not be in the language you most easily understand. Missing content for certain languages is not at all the same as missing content for all languages. c) the observed results are most of the time not what one would want; This is true. Even on the stated standard, Metacity, some odd behaviour with TAB seems to be happening (Every time the toolbox reappears, it has moved down and to the right somewhat.) I'm not sure if there is any problematic behaviour on other WMs like the KDE window manager, XFCE, fvwm, blackbox/fluxbox/etc, WindowMaker.. d) the interpretation is that it's somebody else's fault. 'somebody else'.That's vague. GIMP devs have been specific and definite about this problem for a long time: it's GTK+'s fault. GIMP provides specific information, which it is GTK's job to interpret and pass onto the WM in a way that it can understand. GTK+ currently fails to translate certain information accurately for the Windows WM. You can scream until you're blue in the face and it won't make this any less true. Obviously, I'm missing something... I hate to ask for somebody else's time, but I would appreciate a correction (or at least a reference to older discussions...). the window manager there sucks at managing applications that consist of multiple single windows that don't have a proper native inheritance structure I'm pretty sure that this is NOT how it happens in Windows. AFAIK, there is no window manager; each application is responsible to arrange the x/y/z-order of its toplevel windows itself (there is a simple callback interface for such arrangements). There is window management -- otherwise you could not close windows, or minimize or maximize or move or resize windows (or switch between windows like with ALT-TAB or clicking). In fact window management covers more than the initial creation of windows, but also their movement, resizing, reordering, delivering keyboard and mouse events to the right windows, etc. The callback interface is not unique (in fact GTK implements it in a way that works on all platforms and WMs I've tried, which are many, so the 'callback' behaviour appears to be ubiquitous rather than unique to Windows.). With most WMs, the client program has a high degree of control over the particular behaviour of the
[Gimp-developer] [Fwd: Re: Would single-window fix usability nightmares?]
---BeginMessage--- Ilya Zakharevich wrote: On 2009-10-23, g...@catking.net g...@catking.net wrote: If you see a homeless person with his hand out and give him burger, you don't expect him to come back and complain about the sauce. Obviously, you never did this. And one could even think that you never heard about food allergies (or had friends/relatives dying from it...). (OT, of course...) Ilya What you manage to take out of context is this was part of a series of comments about user attitudes to FOSS in this case whether their complaints could be returned with don't complain , you did not pay for it. Maybe this is another Russian/English problem for you but you would not expect does not mean it can't happen it means you would not expect . Obviously, you never did this. Really? Obviously your ability to infer my whole life experience from one phrase is not as reliable as you believe it to be. I spent a couple of years living rough, eating from bins an never saw any of the low life around me complain about the sauce. Obscure food allergies were not one of our major concerns. You may post any more comments about what you assume I obviously did or did not do somewhere more appropriate than gimp-devel. Thanks. ---End Message--- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] GIMP T-shirts in our online store
Greetings, We are FreeWear.org, we print and sell t-shirts with FOSS designs (Linux distros, desktops environments, etc) and donate to each organization a percentage of each sold article. We usually sell via website, but we can also be found in local FOSS-related events. We also cover special orders, like commemorative t-shirts for events. We've been conducting a poll about which T-shirts our customers want, and looks like GIMP is the most popular one (besides Ubuntu), so we'd like to improve our catalog with some GIMP stuff. We've taken the liberty of making some simple designs based on Wilber: http://www.freewear.org/images/release_candidates/propuesta_gimp.png There are some possibilities that look cool, and we would love to have some feedback on which design (A, B, C or D) and tee color (white or black) look best to you. Also, is the font okay? Is there any better font available out there for a GIMP logo? We'd be happy to know what you think :) About donations: With other organizations like Gnome or KDE, we've agreed that they link our website from theirs and we donate 3€ for each sold 14€ t-shirt. If you don't want to place a link, you'd still receive some donation to thank you for letting us use your logo and name, but no fixed amount. You can find our website in http://www.freewear.org/ Regards, Ismael Barros ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP T-shirts in our online store
On Sunday 25 October 2009 01:43:56 Ismael Barros² wrote: There are some possibilities that look cool, and we would love to have some feedback on which design (A, B, C or D) and tee color (white or black) look best to you. Also, is the font okay? Is there any better font available out there for a GIMP logo? We'd be happy to know what you think :) A - no mouth and a bad squint... Bleh. B - still a bad squint. naah C - best option D - also good but a bit too much contrast with the bg I might actually buy one, when they are available. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Force gimp reload plugins?
Dear developers Is there a quick way to test (my) plugin when I just have compiled it? What I do right now is: * compile * su * make install * quit gimp * start gimp and it takes forever. Is there a quicker way? E.g. a way to force gimp to reload the plugins? =) Hugs, Louise ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Force gimp reload plugins?
On Sun, 2009-10-25 at 03:53 +0100, Louise Hoffman wrote: Is there a quick way to test (my) plugin when I just have compiled it? Once Gimp has been started with the plugin present, you can just replace the executable (make install) and call up the plugin again - Gimp will run the new version. You only need to restart Gimp the first time that you add a new plugin. (As long as the name of the executable and the name of the plugin don't change.) -- David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
