The things can be visually organized like the Inkscape does:
http://wiki.inkscape.org/wiki/index.php/Roadmap . As I think, the
roadmap at their site is much late to the current features implemented,
but the whole framework represents the picture.
Although there can be something like
On 10/26/07, saulgoode wrote:
Finally, there should be an effort to maintain integrity of the XCF
file format by converting between the core implementation of layer
groups and parasites attached to drawables during saves and loads of
XCF files (older GIMP versions would read the files but
Regarding the process of developing a roadmap, I think this mailing
list should be where proposals are made and commented upon (there has
already been some nice commentary in this thread). The main GIMP
developers should fairly rapidly be able to come to a decision about
the roadmap
A change in file formats should be postponed until a bump in the major
version number takes place (per GNU coding standards?). But my
proposal of adding parasites containing layer group meta-data to files
saved in the current XCF standard is indeed merely an interim
solution, permitting
Go for the low-hanging fruit. Do whatever work is easiest that can roll into
new releases. If GEGL is toughest, leave that until 2nd, and do the GDK stuff
first. Do whatever you have the strongest team for.
___
Gimp-developer mailing list
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
What do you think?
I think it's a great idea to have shorter deveopment cycles. It looks
like the project is more active and alive.
I've heard a lot of people saying that gimp was almost dead, while I was
testing 2.3.x series almost monthly. But people tend to think that the
activity of
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
development
Hi,
so far we didn't have a well-defined development roadmap. I would like
to propose that this is changed for GIMP 2.6 and beyond. Hopefully this
can help to acomplish two goals:
- GIMP 2.6 should not take too long to develop
- we will get more developers
Before we start the discussion of
Sven Neumann wrote:
Hi,
so far we didn't have a well-defined development roadmap. I would like
to propose that this is changed for GIMP 2.6 and beyond. Hopefully this
can help to acomplish two goals:
- GIMP 2.6 should not take too long to develop
- we will get more developers
Before
On 10/24/07, Sven Neumann [EMAIL PROTECTED] wrote:
[...]
IMO it would be best if people proposed features here so that they can
be discussed on the list. We should then collect these proposals
somewhere and try to decide on milestones for them later. It would
probably help if we try to be
11 matches
Mail list logo
