Hi,
On Wed, 2007-03-14 at 13:41 +0300, Alexandre Prokoudine wrote:
Related entry is: http://bugzilla.gnome.org/show_bug.cgi?id=119874
It would be useful, perhaps even necessary, to also address bug 330099:
http://bugzilla.gnome.org/show_bug.cgi?id=330099
Sven
On 3/14/07, Aurimas Juška wrote:
I think that's a very nice idea. In addition to this, a way of
organizing resources (brushes, gradients, etc) in collections could be
introduced. They could be stored in a single file, so that user could
easily share, install or remove many resources in a
On 3/6/07, peter sikking wrote:
it clashes with the toolbox shortcuts.
That is a different thing. In my opinion shortcuts need revisiting.
now there is a thought-provoking idea, want to discuss it?
(off-list if this is a repeatedly-flogged dead horse on this list)
Yep, I do. I fact I
On Thu, 2007-03-08 at 01:43 -0500, Kevin Cozens wrote:
It is pretty easy to crash many (most?) of the plug-ins when
passed bad data from some script. Checks in libgimp can stop GIMP
from crashing but will only go so far to stop the plug-in from
crashing. I think it would be a worthwhile
On Tuesday 06 March 2007 05:03, Sven Neumann wrote:
Hi,
I have read through the list at
http://wiki.gimp.org/gimp/SummerOfCode and I think we need to
triage the list and try to come up with fewer but more detailed
proposals. Here are some comments to get us started:
I added some more ideas
Sven Neumann wrote:
Create an SDI manager widget
Do we really want to ask someone to waste his/her time with this? It
is in my opinion not implementable in a sane way and we would likely
not accept the results then. If this is supposed to be kept on the
list then we need to agree
Hi,
On Thu, 2007-03-08 at 01:43 -0500, Kevin Cozens wrote:
It is pretty easy to crash many (most?) of the plug-ins when passed bad data
from some script. Checks in libgimp can stop GIMP from crashing but will only
go so far to stop the plug-in from crashing. I think it would be a worthwhile
Hi,
I have read through the list at http://wiki.gimp.org/gimp/SummerOfCode
and I think we need to triage the list and try to come up with fewer but
more detailed proposals. Here are some comments to get us started:
Color management
I guess it's up to me to come up with a more detailed proposal
On 3/6/07, Sven Neumann [EMAIL PROTECTED] wrote:
Work on GEGL
Needs a more detailed spec, perhaps even a list of proposed projects.
This is a list showing a todo/roadmap for GEGL in its current state,
some of it depends on having a more stable operations API, which is
going to be one of
my
Sven wrote,
Here are some comments to get us started:
Resource management
This looks like a nice project but perhaps needs to be specified
better.
This needs a concept, to start with, which will roll out of the
evaluation project. It is more about where do we want to go
with brushes,
On 3/6/07, peter sikking wrote:
On-canvas text editing
Nice, but pretty much depends on the port of the display code to
Cairo. Perhaps concentrate more on rich text support instead of
focusing on the on-canvas editing?
I am not sure on canvas-editing is that desirable
I would
Alexandre wrote:
On 3/6/07, peter sikking wrote:
On-canvas text editing
Nice, but pretty much depends on the port of the display code to
Cairo. Perhaps concentrate more on rich text support instead of
focusing on the on-canvas editing?
I am not sure on canvas-editing is that
Sven Neumann writes:
Create an SDI manager widget
Do we really want to ask someone to waste his/her time with this? It
is in my opinion not implementable in a sane way and we would likely
not accept the results then. If this is supposed to be kept on the
list then we need to agree
Hi,
On Tue, 2007-03-06 at 11:19 -0800, Akkana Peck wrote:
Rich text support would be a very useful and fun SOC project.
It might require architectural agreement on how the rich text would
be stored in the XCF (which might not be backward compatible).
Is that a problem? Or is there already
14 matches
Mail list logo
