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?
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. ___ 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 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 ___ 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 10/22/2009 09:58 PM, jcup...@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 -- My GIMP Blog: http://www.chromecode.com/ ___ 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?
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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] The mailing list uptime; ask GNOME to host?
On 10/22/2009 07:37 PM, Michael Schumacher wrote: > Martin Nordholts wrote: > >> It is exactly that that is our root problem, we don't have such an admin. One >> way to solve this is to move the list to a place that has sysadmins. > > A place like XCF at Berkeley? > > Contrary to popular belief, the mailing list server is not located in > yosh's bedroom. > > I've mailed Vadim Kogan for the past two issues (expired SSL certificate > and the recent outage), and he responded and fixed the problems quickly, > even over a weekend. That's great, thanks! I thought yosh was the only one with access to the server. With a contact person at XCF the easiest is of course to keep our lists there. BR, Martin -- My GIMP Blog: http://www.chromecode.com/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] The mailing list uptime; ask GNOME to host?
Martin Nordholts wrote: > It is exactly that that is our root problem, we don't have such an admin. One > way to solve this is to move the list to a place that has sysadmins. A place like XCF at Berkeley? Contrary to popular belief, the mailing list server is not located in yosh's bedroom. I've mailed Vadim Kogan for the past two issues (expired SSL certificate and the recent outage), and he responded and fixed the problems quickly, even over a weekend. Regards, Michael -- GIMP > http://www.gimp.org | IRC: irc://irc.gimp.org/gimp Wiki > http://wiki.gimp.org | .de: http://gimpforum.de Plug-ins > http://registry.gimp.org | ___ 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 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. ___ 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 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 -- My GIMP Blog: http://www.chromecode.com/ ___ 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 Thu, Oct 22, 2009 at 7:03 PM, Alexandre Prokoudine wrote: > IMO the real solution is to shop documentation with GIMP. Ship, that is :) Alexandre ___ 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 Thu, Oct 22, 2009 at 1:39 AM, Sven Neumann 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. IMO the real solution is to shop documentation with GIMP. I know we probably don't have the manpower to, but it's the only solution that will ever Just Work (TM). 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 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 ___ 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 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... :) ___ 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 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
___
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 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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] GIMP/GEGL panorama (360 degrees) group photos from LGM 2009
Here's Yuval Levy's account of his experience using GIMP to produce the panoramas: http://panospace.wordpress.com/2009/10/13/making-the-gimp-work-for-me/ Nicolas Robidoux ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] GIMP/GEGL panorama (360 degrees) group photos from LGM 2009
Yuval Levy [0] has produced paroramic mug shots of the GIMP/GEGL developers present at Libre Graphics Meeting 2009 in Montreal. Everything was done with with FLOSS. This is a still picture: http://www.photopla.net/hugin/090509lgm03_gimp_240st.tif This is a rotating animation: http://www.photopla.net/fspan/RCMwOTA1MDlsZ20jMDkwNTA5bGdtMDNfZ2ltcCMw Good job and thanks Yuv! nicolas [0] http://panospace.wordpress.com/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] open/save/export
(Apologies if this repeats a previous suggestion.) I am wondering if making a distinction between saving an IMAGE (which would have an export format component) saving a PROJECT (basically, saving a GEGL tree: this should be the "quick save") saving a WORKSPACE (chosen set of parameters for tools, basic window configurations etc, stripped of image/"input" specific information) would help make things clear to users. I like "saving a project" because I expect users to immediately understand that a project is not an image, and consequently, a project can't be stored in jpg. On the other hand, when I have a certain type of work to be done with an image, I'd bring it to a specific workspace, which basically would provide a work context, a "table" with the most likely needed tools laid out in front of me with the settings I am most likely to need. Nicolas Robidoux Laurentian University ___ 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 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. -- --Alexia ___ 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?
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
smime.p7s
Description: S/MIME cryptographic signature
___
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 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. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
