Vector integration

[Felix Holmgren]

I was discussing with Eric on the silc channel about integrating the
DrawKit (www.apptree.net/drawkit.htm) code base into EtoileUI, which
we had both thought about doing. Eric told me that some of the
functionality (grouping and layers, styling etc, as I understood it)
is already a part of EtoileUI, so only certain parts of DrawKit should
be ported.

We also talked about the need for a CoreGraphics implementation and
Eric told me about the half-finished Opal implementation, which I
check out from the repository. I managed to compile most of it under
OSX (after installing Cairo using macports), although for some reason
cairo's font support was not linked correctly.

But then I saw that Quartz is actually used very little in DrawKit,
except for filter, which are nice but not a core feature. DK relies
mostly on NSBezierPath which is implemented in GNUstep. The gs
implementation uses post script to draw (using functions in
PSOperators.h), but I've seen talk on email lists about other
back-ends. Anyone know anything about this?

So, from what it looks like, we might not need a CoreGraphics
implementation after all, although it would surely be useful, if we
want flexible gradients and maybe other things. What do people think?
How interesting is a CoreGraphics implementation? I could give it a
shot, although I'm not dying to implement all those CGBitmapContext
methods.

In any case, wouldn't it be great if Etoile had really strong vector
drawing support throughout? Personally, I think that gui:s and
everything else in the world should be built using vector graphics as
much as possible.

/F

_______________________________________________
Etoile-dev mailing list
Etoile-dev@...
https://mail.gna.org/listinfo/etoile-dev

[Nicolas Roard]

On Sat, Jul 25, 2009 at 5:20 AM, Felix Holmgren<felix.holmgren@...> wrote:

> I was discussing with Eric on the silc channel about integrating the
> DrawKit (www.apptree.net/drawkit.htm) code base into EtoileUI, which
> we had both thought about doing. Eric told me that some of the
> functionality (grouping and layers, styling etc, as I understood it)
> is already a part of EtoileUI, so only certain parts of DrawKit should
> be ported.
>
> We also talked about the need for a CoreGraphics implementation and
> Eric told me about the half-finished Opal implementation, which I
> check out from the repository. I managed to compile most of it under
> OSX (after installing Cairo using macports), although for some reason
> cairo's font support was not linked correctly.
>
> But then I saw that Quartz is actually used very little in DrawKit,
> except for filter, which are nice but not a core feature. DK relies
> mostly on NSBezierPath which is implemented in GNUstep. The gs
> implementation uses post script to draw (using functions in
> PSOperators.h), but I've seen talk on email lists about other
> back-ends. Anyone know anything about this?

Nah, it doesn't use postscript, really. It simply use those
PSOperators functions, but they then are implemented by each backend.

AFAIK, all NSBezierPath operations should be working fine at least for
the libart backend and the cairo backend (I vaguely remember that the
xlib backend had some trouble with some operations though, but this
might have been fixed). Drawing gradients (or at least some way of
drawing gradients) is implemented in the libart backend, it should
also be implemented with the cairo backend (and if not it shouldn't be
difficult to add).

> So, from what it looks like, we might not need a CoreGraphics
> implementation after all, although it would surely be useful, if we
> want flexible gradients and maybe other things. What do people think?
> How interesting is a CoreGraphics implementation? I could give it a
> shot, although I'm not dying to implement all those CGBitmapContext
> methods.

A CoreGraphics implementation might be interesting when porting OSX
programs. In the case of  DrawKit, as you say it's using NSBezierPath,
this wouldn't be needed.

> In any case, wouldn't it be great if Etoile had really strong vector
> drawing support throughout? Personally, I think that gui:s and
> everything else in the world should be built using vector graphics as
> much as possible.

I'm not sure I follow you -- GNUstep gui is already vector-based. If
you mean having a vector drawing editor then yes :)

--
Nicolas Roard
"I love deadlines. I like the whooshing sound
they make as they fly by." -- Douglas Adams

_______________________________________________
Etoile-dev mailing list
Etoile-dev@...
https://mail.gna.org/listinfo/etoile-dev

[Quentin Mathé-2]

Hi Felix,

Le 25 juil. 09 à 06:20, Felix Holmgren a écrit :

> I was discussing with Eric on the silc channel about integrating the
> DrawKit (www.apptree.net/drawkit.htm) code base into EtoileUI, which
> we had both thought about doing. Eric told me that some of the
> functionality (grouping and layers, styling etc, as I understood it)
> is already a part of EtoileUI, so only certain parts of DrawKit should
> be ported.

Yes. In fact, I took a look at DrawKit two years ago and I have been  
following it since then.
I initially thought about porting it to GNUstep at the same time I  
started EtoileUI.
In the end, I found that that DrawKit was more complex than it ought  
to be and woun't fit well with EtoileUI which has a broader goal  
(compound document support, UI builder, core object integration etc.)
More important the license appears to be BSD, but doesn't seem to be  
since there is this extra clause:

'Furthermore, DrawKit is licensed under these conditions FREE OF  
CHARGE for all non-commercial and educational use.

For commercial use, a FEE may be due. Please contact the author for  
details. Alternative licensing may be negotiated in individual cases for
commercial, fee-paying users. Please note that any fee is individually  
negotiable, and may be waived in certain circumstances.'

This means no DrawKit code be reused.

Extending EtoileUI (or a new framework sitting on top of it) with  
vector graphics related features such as boolean operations on paths/
shapes, text on a path, interactive path editing with control points  
etc. still remains to be implemented though.

> So, from what it looks like, we might not need a CoreGraphics
> implementation after all, although it would surely be useful, if we
> want flexible gradients and maybe other things. What do people think?

It would be useful mainly for compatibility with Mac OS X and new  
Cocoa frameworks. It's also a clean and consistent low-level graphics  
API. GNUstep doesn't really have an equivalent consistent and well  
organized API, so it could be nice to have GNUstep uses it. imo it can  
help to make GNUstep code more consistent in the long run and ensure  
the Cocoa compatibility is optimal.
With a CoreGraphics implementation, CoreText can also be implemented.  
CoreText is a new Mac OS X 10.5 library for font handling and text  
layout. Since the GNUstep text system would benefit to be cleaned, it  
might interesting to use this API as a new base.

> In any case, wouldn't it be great if Etoile had really strong vector
> drawing support throughout? Personally, I think that gui:s and
> everything else in the world should be built using vector graphics as
> much as possible.

Yes :-) I fully agree. From a low-level viewpoint it is already the  
case as Nicolas pointed it. From a high-level viewpoint, the driving  
idea behind EtoileUI is to treat everything on screen as a single  
compound document. Exactly as if the whole environment was an Inkscape/
Illustrator/Flash document and running inside such an application.
The traditional approach is to build a graphics editor framework on  
top of the UI toolkit (AppKit in our case). With EtoileUI the graphics  
editor framework is put under the UI toolkit and UI building becomes a  
subcase of graphics editing.
However EtoileUI won't provide a full-blown vector graphics editor out  
of the box and it will just provide a small core that can be extended.  
We'll probably have a additional vector graphics editing framework  
that provide the missing pieces to build a full-featured vector  
graphics editor.

Cheers,
Quentin.



_______________________________________________
Etoile-dev mailing list
Etoile-dev@...
https://mail.gna.org/listinfo/etoile-dev

[Eric Wasylishen-2]

> More important the license appears to be BSD, but doesn't seem to be
> since there is this extra clause:

The author removed the extra clause a few months ago - DrawKit is now
available under a standard BSD license. So if there is some interesting
code worth borrowing/adapting, we can now.

> Extending EtoileUI (or a new framework sitting on top of it) with
> vector graphics related features such as boolean operations on paths/
> shapes, text on a path, interactive path editing with control points
> etc. still remains to be implemented though.

I'll add a new framework where these things can go as soon as I clean
up my brush code :)

Eric

_______________________________________________
Etoile-dev mailing list
Etoile-dev@...
https://mail.gna.org/listinfo/etoile-dev

[Quentin Mathé-2]

Le 26 juil. 09 à 08:05, Eric Wasylishen a écrit :

>> More important the license appears to be BSD, but doesn't seem to be
>> since there is this extra clause:
>
> The author removed the extra clause a few months ago - DrawKit is now
> available under a standard BSD license. So if there is some  
> interesting
> code worth borrowing/adapting, we can now.

Cool. I missed that. Looks like a new beta (v6) was released on July  
15. I'll take a look at it.
Various NSBezierPath additions are probably worth to borrow from I can  
recall.

>> Extending EtoileUI (or a new framework sitting on top of it) with
>> vector graphics related features such as boolean operations on paths/
>> shapes, text on a path, interactive path editing with control points
>> etc. still remains to be implemented though.
>
> I'll add a new framework where these things can go as soon as I clean
> up my brush code :)

ok :-)

Quentin.
_______________________________________________
Etoile-dev mailing list
Etoile-dev@...
https://mail.gna.org/listinfo/etoile-dev

[Felix Holmgren]

> A CoreGraphics implementation might be interesting when porting OSX
> programs.
But this would belong in the GNUstep code base rather than Etoile, right?

> I'm not sure I follow you -- GNUstep gui is already vector-based. If
> you mean having a vector drawing editor then yes :)
Eh, yeah... that didn't make much sense. What I meant was to actively
push usage of parametric curve elements throughout the ui. (Correct me
if I'm wrong, but GNUstep apps don't normally do that.) Bezier (or
other) path editing and scripting should in my opinion be integral to
Gorm-like apps.

Quentin:
>In the end, I found that that DrawKit was more complex than it ought
>to be and woun't fit well with EtoileUI which has a broader goal
>(compound document support, UI builder, core object integration etc.)
I discovered DrawKit when I was working on a vector editing-capable
application in Java and had a lot of problems figuring out how to
factor the code. I found DK:s model to be well thought out in it's
domain. I like it's way of handling tooling, extensibility, styling,
etc. But I need to take a longer look at EtoileUI before I have any
idea if/how DK:s ideas would fit in with Etoile.

_______________________________________________
Etoile-dev mailing list
Etoile-dev@...
https://mail.gna.org/listinfo/etoile-dev

[Quentin Mathé-2]

Le 29 juil. 09 à 11:59, Felix Holmgren a écrit :

>> A CoreGraphics implementation might be interesting when porting OSX
>> programs.
> But this would belong in the GNUstep code base rather than Etoile,  
> right?

yes.

> Quentin:
>> In the end, I found that that DrawKit was more complex than it ought
>> to be and woun't fit well with EtoileUI which has a broader goal
>> (compound document support, UI builder, core object integration etc.)
> I discovered DrawKit when I was working on a vector editing-capable
> application in Java and had a lot of problems figuring out how to
> factor the code. I found DK:s model to be well thought out in it's
> domain. I like it's way of handling tooling, extensibility, styling,
> etc. But I need to take a longer look at EtoileUI before I have any
> idea if/how DK:s ideas would fit in with Etoile.

I don't dislike DK model, many things are nice in fact, but I think it  
offers too many convenience methods which results in a pretty big API.

Here are some more specific points…
I wouldn't implement layers as it does. DKLayer and DKLayerGroup could  
be implemented a normal nodes in the tree structure, by sharing common  
superclasses with DKDrawableShape/DKDrawableObject and ETShapeGroup.
To have put the whole action handling (wit the selection notion) in a  
layer class (DKObjectDrawingLayer) is quite weird and rigid.
DK has no clear way to support the nesting of the graphics editors.  
You have a single high-level controller to control your whole document  
and its layers which handle actions. Which means you cannot attach a  
new graphics editor or viewer to an arbitrary node in a compound  
document being already viewed/edited.
I was also not  really convinced by the way the style registry behaves  
from the user viewpoint, how to use it felt a bit awkard when I played  
with the demo application. I don't  recall exactly why, the last time  
I tried it was one year ago.

However you seem to know DrawKit quite well, so you might want to  
object to my points :-)

Cheers,
Quentin.
_______________________________________________
Etoile-dev mailing list
Etoile-dev@...
https://mail.gna.org/listinfo/etoile-dev