On Fri, Oct 2, 2009 at 10:25 AM, Ilya Zakharevich wrote:

a focus?  So how does this improves the current nightmares (e.g., keyboard shortcuts not working - especially when most needed ;-)?

Lemme guess - you are on WIndows? :)

Alexandre

Ilya Zakharevich wrote:

However, I do not see how much this would affect the (AFAIK) main complaint about multi-window GIMP: that having several windows with several possibilities of what is focused requires many extraneous mouse clicks and/or keypresses.

the introduction of a single window mode is in no way related to that.

When the windows are merged into one, STILL only one of subwindows has a focus? So how does this improves the current nightmares (e.g., keyboard shortcuts not working - especially when most needed ;-)?

that is a serious bug.

in what version(s) of GIMP does this happen?

--ps

founder + principal interaction architect man + machine interface works

http://mmiworks.net/blog : on interaction architecture

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

On Wed, Oct 21, 2009 at 1:42 PM, Ilya Zakharevich wrote:

On 2009-10-21, Tor Lillqvist wrote:

It is pointless to describe the misbehaviour of GIMP windows on Windows to GIMP developers, as they don't use Windows themselves.

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, it means the bugs are in GTK+, not GIMP, 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?

Are you sure that the situation is as you describe it?

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.

Sorry, but I find this attitude as misplaced as one in the previous paragraph...

Your expectations that GIMP will exert such extreme control over the window management are also unreasonable. 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. The particular 'communications breakdown' is between GTK+ and the Windows window manager, GIMP is not involved in the problem, only a casualty of it.

On Wed, Oct 21, 2009 at 11:22 AM, Ilya Zakharevich wrote:

On 2009-10-02, peter sikking wrote:

However, I do not see how much this would affect the (AFAIK) main complaint about multi-window GIMP: that having several windows with several possibilities of what is focused requires many extraneous mouse clicks and/or keypresses.

the introduction of a single window mode is in no way related to that.

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?

(I mean: whenever z-order of main GIMP window changes *wrt non-GIMP windows*, the z-order of "dependent" windows changes accordingly. Same for toolboxes: similar changes in THEIR z-order should be reflected in the z-order of the "current" image window)

When the windows are merged into one, STILL only one of subwindows has a focus?  So how does this improves the current nightmares (e.g., keyboard shortcuts not working - especially when most needed ;-)?

that is a serious bug.

in what version(s) of GIMP does this happen?

2.6.6.  Tested on Windows.  Examples:

a) Press TAB (toolboxes disappear);   Press TAB (toolboxes  reappear, focus on "Layers");   Press TAB - now you navigate "Layers" toolbox.

I can reproduce this very annoying behaviour. I have to refocus the image window in order to get TAB to work again, and basically gave up on using TAB at all. Platform: Arch Linux (i686), GTK 2.16.5, Window Manager: AwesomeWM 3.3

I believe my WM always focuses the newly shown window, which may reflect on this behaviour.

b) Focus to Layers.  Press F11.  Nothing.  Press o.  Nothing.  Press 4   (user configured to "1:4 zoom").  Nothing.

I can't reproduce this; all keyboard shortcuts work as expected, except where they conflict (for example, when a text-entry field like palette or color name is in focus, you have to be able to type o as an ordinary letter). May be Windows-only.

On Wed, Oct 21, 2009 at 4:52 AM, 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?

As mentioned before, synchronized panning in tiled image windows, for instance.

Alexandre

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

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

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.

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

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

On Thu, Oct 22, 2009 at 12:54 AM, Ilya Zakharevich 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.

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.

I think that it is one of the STRENGTHS of FOSS that if there's a bug in a component users of that component do not try to hack round it, but expect the bug to be fixed at the source benefiting everyone.

I'm sorry to say this, but your attitude is starting to piss me off. Your attack mentality and complaining are not helping. Perhaps you should stop that and do something that would actually help, like contribute some code.

We work on gimp for FUN. Most of us do not use Windows(I don't have one for my personal use) and those that do are not skilled enough to do GTK development on that platform. We do what we can. I personally got involved in the project by hunting a bug that ended up being in GTK. It got fixed. True, the bug was specific for Linux, but that's the platform I do my development on. I done have neither the will nor skills to do that. You can do it on windows if you want.

On Thu, Oct 22, 2009 at 5:14 PM, Alexia Death wrote:

On Thu, Oct 22, 2009 at 12:54 AM, Ilya Zakharevich 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.

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.

I think that it is one of the STRENGTHS of FOSS that if there's a bug in a component users of that component do not try to hack round it, but expect the bug to be fixed at the source benefiting everyone.

I'm sorry to say this, but your attitude is starting to piss me off. Your attack mentality and complaining are not helping. Perhaps you should stop that and do something that would actually help, like contribute some code.

We work on gimp for FUN. Most of us do not use Windows(I don't have one for my personal use) and those that do are not skilled enough to do GTK development on that platform. We do what we can. I personally got involved in the project by hunting a bug that ended up being in GTK. It got fixed. True, the bug was specific for Linux, but that's the platform I do my development on. I done have neither the will nor skills to do that. You can do it on windows if you want.

^^^^
This :).

You said all the things I wanted to say but didn't figure out how to express.

I won't say anything else to avoid being inflammatory.

OK guys,

the tone of this discussion is distracting from the real problems we have and a possible solution.

and we do have problems that are in gtk (mainly on windows) and with a load of window managers that do not even implement the window hint that we are apparently the bleeding-edge users of for our docks.

insight: I met with the openPrinting guys on tuesday and was telling them how this gtk+windows situation looked like a mini version of linux printing (_nobody_ can be bothered to work on print dialogs). the impression of one of the guys was that when it comes to gtk+windows, what you are talking about is GIMP and inkscape. these two seem to be the only clients (more than one way) that matter.

what is not helping us is that outsiders expect this big application to have a big and active development team. to my surprise even the official commit stats come to that conclusion. meanwhile everyone who hangs around here knows that we have very limited resources. piecing all the contributions together I say we got about 3.7 full developers worth going on a at any given time.

I am sure that the 1 million users who download GIMP for windows every month somehow expect that is was developed on windows.

so the solution is not to ask the people who (and I am grateful for it) do their best to contribute now. the solution is to stop potential contributors having to find out by osmosis how they can help us.

what we can do is be much more concrete on www.gimp.org and say on the home page: "Help wanted". This is eerily close to job openings at companies, but that is what we have.

and similar to companies we have to 'sell' our needs a bit. show that new developers can work on a coherent package of work where they can make an impact, pretty soon. I think for instance Martin and Alexia discovered that over the last years and they have carved out their niche(s) where they are having a large impact.

"GIMP is looking for an experienced windows XYZ developer who can really make a difference to our user experience on windows."

I do not want this to be a high-maintenance thing like the SoC. The effort for the current contributors should be limited to: - coming up with a coherent package of work and requirements for the new contributor ("has to know XYZ libs and ABC algos") - write the help wanted add (if you do one a month, it may become NEWS on all those GIMP tracking sites) - help the new contributor with the bug numbers and where to start in the source ("oh, that is in gtk") - be really clear in what we want to achieve (I can help with that) - no further hand-holding

another 'external' area where we really can use some help is gegl, to get that from its bumbling experimentation speed to production speeds that are same or even better that current GIMP (I read between the lines in irc that not everything in GIMP it profiled to the bone).

--ps

founder + principal interaction architect man + machine interface works

http://mmiworks.net/blog : on interaction architecture

On Thu, Oct 22, 2009 at 12:50 PM, peter sikking wrote:

what we can do is be much more concrete on www.gimp.org and say on the home page: "Help wanted". This is eerily close to job openings at companies, but that is what we have.

I actually like this idea. It would be awesome if we could link this from bugzilla somehow. Since we share it with GNOME project, being able to this is unlikely but a bug tracker is the best place to have contact with someone who would be willing, due to need and able by merit of having found the bugzilla in first place to contribute.

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? ;)

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.

Wow! :D

Alexandre

On Thu, Oct 22, 2009 at 1:50 PM, peter sikking wrote:

"GIMP is looking for an experienced windows XYZ developer who can really make a difference to our user experience on windows."

I do not want this to be a high-maintenance thing like the SoC. The effort for the current contributors should be limited to: - coming up with a coherent package of work and requirements  for the new contributor ("has to know XYZ libs and ABC algos") - write the help wanted add (if you do one a month, it may become  NEWS on all those GIMP tracking sites) - help the new contributor with the bug numbers and where to start  in the source ("oh, that is in gtk") - be really clear in what we want to achieve (I can help with that) - no further hand-holding

+1

another 'external' area where we really can use some help is gegl, to get that from its bumbling experimentation speed to production speeds that are same or even better that current GIMP (I read between the lines in irc that not everything in GIMP it profiled to the bone).

+2^32 :)

Alexandre

On Thu, Oct 22, 2009 at 15:57, Alexandre Prokoudine wrote:

another 'external' area where we really can use some help is gegl, to get that from its bumbling experimentation speed to production speeds that are same or even better that current GIMP (I read between the lines in irc that not everything in GIMP it profiled to the bone).

+2^32 :)

I hope that's not a 32-bit signed integer...

Sorry for the OT-spam, couldn't resist the urge. I'll crawl back under my rock now... :)

On Thu, Oct 22, 2009 at 1:50 PM, peter sikking wrote:

another 'external' area where we really can use some help is gegl, to get that from its bumbling experimentation speed to production speeds that are same or even better that current GIMP (I read between the lines in irc that not everything in GIMP it profiled to the bone).

(Warning: Foot in mouth ahead.)

I have the impression that the least painful way to make GEGL fast SOON may be to build its desired API on top of VIPS.

Nicolas Robidoux Universite Laurentienne

On 10/22/2009 04:15 PM, Nicolas Robidoux wrote:

On Thu, Oct 22, 2009 at 1:50 PM, peter sikking wrote:

another 'external' area where we really can use some help is gegl, to get that from its bumbling experimentation speed to production speeds that are same or even better that current GIMP (I read between the lines in irc that not everything in GIMP it profiled to the bone).

(Warning: Foot in mouth ahead.)

I have the impression that the least painful way to make GEGL fast SOON may be to build its desired API on top of VIPS.

We can't use VIPS in GIMP because we need a dynamic graph. In practice that also rules out implementing GEGL with VIPS.

Regarding GEGL's performance issues: It's not that GEGL still is slow because we don't know how to make it faster, there many identified areas that we know could be improved, it's just no one have had time to improve GEGL's performance further yet.

Once GIMP 2.8 is out that will change. At least I plan on hacking a lot on GEGL once 2.8 is out...

/ Martin

On Wed, Oct 21, 2009 at 5:54 PM, Ilya Zakharevich 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.

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.

Of course software responsibility modularizes. When World of Warcraft had graphics glitches on DirectX but not on OpenGL, whose fault was that? If your answer was "Microsoft", move to the head of the class. WoW users complained to Blizzard, who responded "Microsoft's library is broken, switch (temporarily)". Everyone waited for Microsoft to fix the DX problem (which never happened, ATI and nVidia implemented workarounds in their drivers instead). Expecting Blizzard's developers to fix (or even acknowledge) bugs in Microsoft's code is silly[1].

[1] plenty of WoW players are also silly, and thus continued to blame Blizzard, as you are blaming GIMP now for bugs in GTK+. Yes, I am calling you silly.

2009/10/22 Martin Nordholts :

I have the impression that the least painful way to make GEGL fast SOON may be to build its desired API on top of VIPS.

We can't use VIPS in GIMP because we need a dynamic graph. In practice that also rules out implementing GEGL with VIPS.

You could use VIPS as a backend for GEGL. You could have the dynamic graph stuff in a layer over VIPS and on a change, rebuild the VIPS pipeline underneath. This is how the VIPS GUI works.

Though I've not looked in detail and I'm not volunteering to do the work :-( But it seems possible to me anyway.

John

On 10/22/2009 09:58 PM, jcupitt@gmail.com wrote:

2009/10/22 Martin Nordholts :

I have the impression that the least painful way to make GEGL fast SOON may be to build its desired API on top of VIPS.

We can't use VIPS in GIMP because we need a dynamic graph. In practice that also rules out implementing GEGL with VIPS.

You could use VIPS as a backend for GEGL. You could have the dynamic graph stuff in a layer over VIPS and on a change, rebuild the VIPS pipeline underneath. This is how the VIPS GUI works.

Hi John,

It doesn't seem feasible from a performance perspective to construct complex compositing graphs from scratch all the time. For example, can caches be reused between VIPS pipeline setups?

Another thing that makes VIPS less attractive is that it is not designed using an object oriented approach but is instead written in a functional/procedural manner. I have looked briefly at the code a while ago and my first impression was that VIPS will hard to extend and adapt to GIMP needs.

BR,
Martin

Hi Martin,

2009/10/22 Martin Nordholts :

It doesn't seem feasible from a performance perspective to construct complex compositing graphs from scratch all the time. For example, can caches be reused between VIPS pipeline setups?

That's true, there is a cost there. I would argue:

- VIPS does almost no caching, so there's not actually much to throw away - you spend much more time rendering pixels through a pipeline than updating it, so it's the render part that needs to be quick - a simple static pipeline is a big performance win: a year ago (when I last timed GEGL) VIPS was always 10 and sometimes 100 times faster, though perhaps I messed up the benchmarking - with more than one CPU, large shared caches become a lot less useful and can begin to limit scalability
- you can keep a display cache between pipelines to make panning and zooming quick (the VIPS GUI does this)

Another thing that makes VIPS less attractive is that it is not designed using an object oriented approach but is instead written in a functional/procedural manner. I have looked briefly at the code a while ago and my first impression was that VIPS will hard to extend and adapt to GIMP needs.

That's certainly true. VIPS is pretty old and it shows in the ugly API.

I'm trying to fix it up. The more recent chunks of API are built on top of GObject and the long term plan is to break backwards compatibility and move the whole thing over.

We had a stab at a "big bang" from scratch rewrite on top of GObject a few years ago and it petered out (as any experienced programmer could have predicted, heh), We're now trying to evolve the existing code instead and reuse stuff from the big bang branch where we can.

John

Sparr wrote:

is broken, switch (temporarily)". Everyone waited for Microsoft to fix the DX problem (which never happened, ATI and nVidia implemented workarounds in their drivers instead). Expecting Blizzard's developers to fix (or even acknowledge) bugs in Microsoft's code is silly[1].

Try looking at this type of situation from the user point of view - it's all finger pointing, and doesn't actually help solve the problem. As soon as you put the user first, then as the vendor of a tool you will try to fix the problem if you can (working around it if you must), irrespective of who is ultimately "responsible".

[ It's all about attitude. Saying "It's not my fault" is an unhelpful attitude. Saying "Patches welcome" is an unhelpful attitude. Saying "Stop complaining, you got it for free!" is an unhelpful attitude. Saying "Too bad, it works for me" is an unhelpful attitude. Being unhelpful is a confrontational stance that gets peoples backs up, and convinces them that you are not to be trusted, since you seem to have no empathy for their situation, and seem to have no pride in what you do.
]

Graeme Gill.

[ 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

On Fri, Oct 23, 2009 at 08:14, Tor Lillqvist wrote:

[ 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"?

Not trying to inflame this more than necessary, but looking at the philosophical side, I think we can all agree that fixing the root cause of the problem generally produces a more reliable, maintainable product, compared to treating the symptoms first. Of course, you could argue that you should treat the symptoms first, and then cure the root cause, however, this removes the pressure to fix the root cause completely, not to mention that the 'fix' of the symptom will probably never be removed.

This is part of the beauty of volunteer based FOSS software, you don't have any employers who're only concerned with the quarterly results, and force you to treat the symptoms. The flip-side is of course that problems that no one knows how to fix are problem that's gonna take longer to solve.

Bottom line is, saying 'fix this for me, I don't care how' is the true unhelpful attitude, because we DO care how the fix is done. Not only what symptoms it treats. It's not as much you the customer, and we the developers of a product, it's you as my friend, and I'm lending you the code I made in my backyard. If there's something you don't like about it, by all means, help me solve it.

Just my two cents, sorry for the rambling. Fredrik.

Graeme Gill wrote:

Sparr wrote:

is broken, switch (temporarily)". Everyone waited for Microsoft to fix the DX problem (which never happened, ATI and nVidia implemented workarounds in their drivers instead). Expecting Blizzard's developers to fix (or even acknowledge) bugs in Microsoft's code is silly[1].

Try looking at this type of situation from the user point of view - it's all finger pointing, and doesn't actually help solve the problem. As soon as you put the user first, then as the vendor of a tool you will try to fix the problem if you can (working around it if you must), irrespective of who is ultimately "responsible".

[ It's all about attitude. Saying "It's not my fault" is an unhelpful attitude. Saying "Patches welcome" is an unhelpful attitude. Saying "Stop complaining, you got it for free!" is an unhelpful attitude. Saying "Too bad, it works for me" is an unhelpful attitude. Being unhelpful is a confrontational stance that gets peoples backs up, and convinces them that you are not to be trusted, since you seem to have no empathy for their situation, and seem to have no pride in what you do.
]

Graeme Gill.

Some of your comments are valid but your basic premise is wrong. There is nothing for sale, so the is NO VENDOR.

neither is a GIMP a "product" in more than the most literal term that it is something which is produced.

Applying your marketing terminology and mentality to a FOSS project is wrong . Different motivations are the driving force. The "customer" is not king. He can be a collaborator.

>Saying "Stop complaining, you got it for free!" is an unhelpful > attitude.

So is complaining. With FOSS you can submit bugs reports if something does not work , request a feature is you have an idea or contribute to the project. The is no channel or reason to deal with "complaints".

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.

But it's also true that suggesting something could be done differently is sometimes taken as an affront , that is unhelpful and may hinder improvements being made.

Many FOSS projects are refractory to user feedback and ideas coming from outside.

/gg

On Thu, Oct 22, 2009 at 9:50 PM, wrote:

- a simple static pipeline is a big performance win: a year ago (when I last timed GEGL) VIPS was always 10 and sometimes 100 times faster, though perhaps I messed up the benchmarking

- with more than one CPU, large shared caches become a lot less useful and can begin to limit scalability
- you can keep a display cache between pipelines to make panning and zooming quick (the VIPS GUI does this)

VIPS has received significant work on performance and refactoring after it started working (doing what it is meant to do). GEGL has not gone much beyond reaching the stage of doing what it says on the tin. Display caches between renderings is essentially what GEGL does as well, but it also permits doing this at check-point stages, (like for instance a full layer subgroup, meaning that that subgroup never would need to be recomposited if it doesnt change, GEGL also tracks all minor changes.)

The GEGL code is structured in such a manner that the public application API (the one using nodes) can be kept while replacing all the internals as well as the plug-in API either as a fork (or later if such a fork proves itself as an alternative backend). Feel free to spearhead such an effort, personally I prefer continuing my efforts at completing the existing GEGL plans.

/Øyvind K.

 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

On Sat, Oct 24, 2009 at 6:43 PM, Ilya Zakharevich wrote:

On 2009-10-21, Karl Günter Wünsch 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 appsWM 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 windows it creates. So, arguably GIMP *could* work around GTK's current shortcomings in this area. That is just not regarded as a serious option because it is a) ugly, b)evil, and c)inevitably going to confuse GTK+. Hence, we are left with fixing GTK+ (which is the right fix).

gg@catking.net wrote:

Some of your comments are valid but your basic premise is wrong. There is nothing for sale, so the is NO VENDOR.

Of course there is a vendor. "To Vend" in the context I use it means to offer for public consideration. Whether that is for a price is detail. Use another word if you prefer, but the developers of Gimp are offering it for public use.

Applying your marketing terminology and mentality to a FOSS project is wrong . Different motivations are the driving force. The "customer" is not king. He can be a collaborator.

In general though, a customer/user/whatever-you-want-to-call-them can't be a collaborator, because they lack the expertise. That the whole point of the exercise, someone chooses to use the expertise embodied in something like GIMP because they don't have it themselves. Even those few with the skill necessary to contribute may choose not to do so, because they are employing it fully on some other worthwhile project. (this is division of labor).

So is complaining. With FOSS you can submit bugs reports if something does not work , request a feature is you have an idea or contribute to the project. The is no channel or reason to deal with "complaints".

It seem to me that far too many FOSS developers are quick to interpret any sort of feedback or suggestion as a complaint and an affront. If you want to keep your software just between contributors, then simply don't make it available to the public. If you make it available to the public, then be prepared to deal positively with feedback of all sorts. To do otherwise amounts to bating.

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.

If the burger has gravel in it, they may think you are being unhelpful, or worse, trying to injure them. Do you expect them to say nothing ? [ I'm not sure your analogy is helpful, as I suspect it is culturally specific.]

Graeme Gill.