over last couple of month I hacked a little on OGL, to make it better
suit my needs in the Pyphant framework.
Some time ago I already posted some patches, which were kind of rejected
due to different views of the desired architecture.
Now we are about to release Pyphant[1] as an Open Source Project on
Sourceforge under the BSD License and thus need to release the modified
OGL.
My question now is whether you want it back in the source tree or if you
would prefer to have it dealt with by us.
Furthermore as I understand it Pierre Hjälm is sort of the current
maintainer, so I am very much interested in youre opinion.
Lastly if you want us to go away should we change the name entirely or
have it resemble ogl? I neither want to steal your project, nor betray
the projects roots.
However last time the topic arose I was under the impression that there
was some disagreement on the desireable direction.
Here is some of the things I want to do:
1) Unify Canvas and Diagram.
Since the one is pretty useless without the other and much redundancy is
generate through the imho somewhat artificial seperation I think this is
a good idea.
2) Straightening out ControlPoints from the Shape hierarchy.
Though I see some advantages to ControlPoints being shapes my impression
is that the cycle in the shape hierarchy thereby introduced generates
unfortunate dependencies, so my goal would be to seperate them, possibly
introducing a new common baseclass.
3) Restructuring the line<->shape.
As of now lines get special treatment, which not only shows in
themselves, but also throughout the shape-tree, which I belief should be
remedied. This especially is true for the 'draggable' properties.
As you can see the end result does not aim at resembling the current ogl
too much.
Any input is greatly appreciated!
> Hi List,
>
> My question now is whether you want it back in the source tree or if you
> would prefer to have it dealt with by us.
> Furthermore as I understand it Pierre Hjälm is sort of the current
> maintainer, so I am very much interested in youre opinion.
> Lastly if you want us to go away should we change the name entirely or
> have it resemble ogl? I neither want to steal your project, nor betray
> the projects roots.
>
> However last time the topic arose I was under the impression that there
> was some disagreement on the desireable direction.
>
> Here is some of the things I want to do:
> 1) Unify Canvas and Diagram.
> Since the one is pretty useless without the other and much redundancy is
> generate through the imho somewhat artificial seperation I think this is
> a good idea.
> 2) Straightening out ControlPoints from the Shape hierarchy.
> Though I see some advantages to ControlPoints being shapes my impression
> is that the cycle in the shape hierarchy thereby introduced generates
> unfortunate dependencies, so my goal would be to seperate them, possibly
> introducing a new common baseclass.
> 3) Restructuring the line<->shape.
> As of now lines get special treatment, which not only shows in
> themselves, but also throughout the shape-tree, which I belief should be
> remedied. This especially is true for the 'draggable' properties.
>
> As you can see the end result does not aim at resembling the current ogl
> too much.
> Any input is greatly appreciated!
>
Well, seeing as I don't have much time for this these days, I wouldn't object
too strongly to changes. However, I would mind if backwards compatibility was
sacrificed without a real good reason.
I have no real way of knowing how your changes affect current code though.
Do you have a copy for download somewhere?
···
--
Pierre Hjälm, Systems Administrator
Department of Information Science, Uppsala University, Sweden
email:pierre.hjalm@dis.uu.se phone:+46-(0)18-4711044 fax:+46-(0)18-554422
There you'll find what we currently use.
However backwards compatibility will be broken.
That is kind of the point:
We do see no advantage to having a canvas as well as a diagram.
One could argue, that the diagram is the model, while the canvas was the
View/Controller. We belief that the model will have to be written by the
user of ogl anyway and that the diagram in its current form is not
suitable as base for that.
Thus it seems better to have a solid View/Controller with a well defined
interface allowing for easy adaptation of ones own models.
There you'll find what we currently use.
However backwards compatibility will be broken.
That is kind of the point:
We do see no advantage to having a canvas as well as a diagram.
One could argue, that the diagram is the model, while the canvas was the
View/Controller. We belief that the model will have to be written by the
user of ogl anyway and that the diagram in its current form is not
suitable as base for that.
Thus it seems better to have a solid View/Controller with a well defined
interface allowing for easy adaptation of ones own models.
If it isn't backwards compatible with the old version then I don't feel comfortable with including it with wxPython. (I get flamed enough as it is for breaking compatibility by accident, I don't need to intentionally offer myself up for the flame-throwers to crispify me.)
If you can make it such that both the old way and the new and improved methodology works, then I think that would be okay.
···
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
If it isn't backwards compatible with the old version then I don't feel comfortable with including it with wxPython. (I get flamed enough as it is for breaking compatibility by accident, I don't need to intentionally offer myself up for the flame-throwers to crispify me.)
If you can make it such that both the old way and the new and improved methodology works, then I think that would be okay.
Or if push comes to shove, then provide a wxOGL2 class. Then maybe overtime people will migrate to wxOGL2 when/if they see the advantages. If need be, wxOGL can be deprecated later down the track.
We do see no advantage to having a canvas as well as a diagram.
I'm not very familiar with OGL, so I'm just guessing what these are, but, if I'm right, one advantage might be that you could have two Canvas showing different views of the same diagram.
However, if you can't do that anyway, then I agree.
-Chris
···
--
Christopher Barker, Ph.D.
Oceanographer
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Since I expect this to be somewhat unstable for quite some time, we will
host it ourselves for the time being.
I hope to reintroduce it sometime in the future (ETA half a year - one
year).