GNOME.org
 

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

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


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.


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 ;)


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.


* A simple widget to test container layout

I prefer Chapin charts.


* 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
here.


From there we can implement  more widgets, the use of arrays, callback and
scripting.

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.

[snip]

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. ;)


--J5

cu Andre
-- 
Tolerance rulez, everything else sux! -- Andre Kloss
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]