> > This is why I suspect it to be a transparency problem and not really
> > a process problem. People actually Won't criticize a process if they
> > think it is doing a good job. In the case of the GUI team, we don't
> > know if it's doing a good job. In fact, we don't see a job being done
> > at
> Well, I agree with the gist of your message... but one thing needs to be
> said:
> Designing a good UI doesn't require the same amount of people that
> implementing
> it in code does.
This is why I suspect it to be a transparency problem and not really
a process problem. People actually Won't c
I suspect the true "problem" isn't one about the process, but one
about the perceived results. When you think about it, people rarely
criticize a project Just for the process. People criticize MS
Windows for being closed-source and thus full of bugs and
functionality problems, but nobody criticizes
> Okay I want to clear this up:
> GEGL *is* coded (see www.gegl.org), and already in use by a few
> different applications.
Much apologies. I was always under the impression that while there
is a working version, more work could have been used for adding
features and such. I blame my lack of und
So... Gimp currently has 4 major goals?
- Cairo
- GEGL
- Add named parameters and default values to the PDB
- 6 months development cycle.
Wouldn't it be easier to treat them as Separate goals for separate
releases? Once Cairo and GEGL (I have no idea for the Parameters feature,
so apologies for no
> So, an important decision must be taken, imo. Plan the 2.6 version as a
> "new core" version (with important improvements in the technical area,
> but maybe not that visible for the final users), or a "new features"
> version. If this isn't defined, there is a risk to fall in a long
> develop
Gimp 2.4 is great!
On roadmaps: could enhancement requests be grouped by category somewhere?
Going through the list of enhancement proposals in Bugzilla is rather
awkward to say the least.
I do like how some programs have used a wiki, like Firefox 3 and Inkscape.
Eventually, for Gimp, each wiki
How about creating the following buttons on the jpeg save console?
- "Save at original image compression value"
- "Save at user-specified compression value" (insert current value of
used-specified quality)
- "Change user-specified compression value"
It can be abbreviated as the following:
Save at
> Quoting peter sikking's weblog:
>
(http://www.mmiworks.net/eng/publications/2007/05/lgm-gimp-project-overview.html)
>
> "ALSO NOT PAINTER
> the focus for GIMP is to work with ?found? images;"
>
> I do not understand the reason for this restriction. Myself, I am not
> a painter. I do not
> That's why we need a Gimp PRO, Inkscape PRO, Scribus PRO - someone, a
> Firm / Govern / Foundation / Linux Distro / Billionaire ...or a
> mixture of them must hire core developers of all 3 projects - put them
> into a big WEB / DTP Core Linux project
> and manage development and releases.
If I
Thanks to Sven for pointing out that I initially posted in the wrong
place! Also, I haven't used Gimp 2.3 yet, so I apologize if I'm repeating
things that are already inside.
Basically, while checking out Inkscape, I misunderstood its shortcut
system at first and thought that the "space" button to
11 matches
Mail list logo
