Re: UrShape definition Part IV: Full header (?)

Hehe.  Well lets see if I can clarify what I was thinking.

Andre Kloss wrote:

Hi again. John, you raised some points I dislike, so here's what I

How can UrShapes interact? If a UrShape is dragged over a (free)
UrContainer, it should snap into it until dragged out again. Any
UrContainer that has means of containing another UrShape should resize
to make place for one if one's dragged over. How does a UrShape know
what UrContainer it is over?

H'mm,  me thinks this is a bit complicated.  Are we trying to make this
into a widget layout program like Glade?
No. Don't mistake UrShapes as widgets. Think the bigger picture: A
UrShape is some SVG plus Text plus UrContainers. UrShapes can build an
arbitrary deep tree. The only widget we need (yet) is a textbox.

Agreed, the Glade part was the drag and drop stuff which would be nice to have
but turns Dia into a shape creation program instead of a diagramming tool.  I
say that this is good to have in the future but as a separate developers mode
(Perhaps even having the ability to edit scripts).  Of course we could always
add a drag 'n drop container that can be used for shapes that need this ability
in design mode.

I don't think interaction with containers is necessary, at least
for the first iteration of UrShape.
Ok, first put it on the screen, then make it work. Agreed, for the
first iteration.

Containers are just there to hold a small subset of GTK+ widgets.
I disagree on this point. UrContainers are just there to hold whatever
we want them to hold - as long as it's a UrShape ;)

Oops, what I meant here is that they dictate the layout of a small subset of
GTK+ widgets.  Yes they should be able to hold anything that is a UrShape.

I would think it were pretty annoying if I were dragging a shape
across container and it was suddenly sucked in.
But only if you drag it to the container and drop it within a
(adjustable) range of it. If you drag further, nothing happens (yet -
maybe wa may want some more visual feedback in the future). I don't
think that this would be too annoying. Maybe each diagram type could
have its own "embedding" range?

This might be good for a separate shape creation mode to make it
easy to create new shapes but for right now doing them by hand
with the UrShape DTD would be the best thing.
I do not want to create shapes. I want to create trees of shapes.


We need to implement _first_:
* Rendering on the dia canvas
As seen in custom_object. This includes the SVG subset and text boxes.

* Grab points for manually resizing
You mean the handles? If so, we'll just follow the implementation in
whatever uses elements.


* Layout based on containers
What do you mean here? Layout is just the positioning of shapes.

Layout is the positioning of shapes based on the size of the containers which is
based on 2 things:
* Manual resizing
* Size of widget within the container (i.e. as the user types TextBoxs get

We have to make sure this is consistent, smooth and works in a visually pleasing
manner.  Should they grow, up, down, sideways?  Should restrictions be put on
textbox growth?  Should we allow to restrict horizontally? vertically? Should we
have a min and max size of widgets and then add scrollbars beyond that point?

Layout is the big issue here.  Personally I don't like how the current shapes
with text expand (In all directions) but that is a judgment call I will not make
on my own.  If everyone wants the UrShapes to expand the same way then so be it.

* A simple widget to test container layout
I prefer Chapin charts.

Enlighten me to what a Chapin chart is.  I was referring to the textbox widget
as being a simple one to use at first.

* Load UrShape files
Yep. That's what I'll write the parser for.

  * Load UrShapes from within Dia docs
(You forgot this)
* Save UrShapes within Dia documents

Here I'm undecided, since I'm wading not deep enough in the code to
know the interface to the core, but I believe we'll stick with DOM

From there we can implement  more widgets, the use of arrays, callback and
I come more and more to the conclusion that we should add a callback
hash in the first place. It will not disturb our design and I'm quite
convinced that this will be how we implement it later anyway.

If you feel confident then go for it.

struct _UrShape {
  Element element;      /* Inheritance (C sometimes sucks ;) */

This is why I want to use GObject since it brings OO to C in a more
complete manner well, more standardized (by GTK+) manner.  I guess we can
wait until the rest of Dia moves to GObject and GTK 2.0 compliance.
Certainly. Let's just run with the wind, not ahead. ;)

Yep, though I wish C++ played nicer in the dynamic sense.  Too bad ObjectiveC
never really took off like C++.  I think the only reason GNOME and Gtk+ use C is
because it is so easy to bind to other languages.  Oh well.

cu Andre
Tolerance rulez, everything else sux! -- Andre Kloss

Dia-list mailing list
Dia-list gnome org


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]