*** Recent ChangeLog entries:
--- ChangeLog.previous Mon Jun 11 09:23:03 2001
+++ dia/ChangeLog Tue Jun 12 09:05:27 2001
@@ -1,3 +1,33 @@
+2001-06-11 Cyrille Chepelov <[EMAIL PROTECTED]>
+
+ * objects/GRAFCET/boolequation.[ch]: zap lazyprops. Add standard props.
+ * objects/G
Ok, well I sent this reply to the list as well as to you James. We should keep the
discussion there so people can be free to comment or ignore us as we go along.
I can't code much now because I have no real access to CVS (Just graduated and am
relegated to using my parents AOL connection until I
Hi,
when exporting dia drawings to xfig, rectangles with rounded corners get
broken up into lines and arcs. I had used the "Flowchart - Box" item to
get rectangles with rounded corners which can also have text inside
them.
The same happens for standard rectangles.
While I understand that this is t
Le mar, jun 12, 2001, à 02:31:25 +0200, Cyrille Artho a écrit:
> Hi,
> when exporting dia drawings to xfig, rectangles with rounded corners get
> broken up into lines and arcs. I had used the "Flowchart - Box" item to
> get rectangles with rounded corners which can also have text inside
> them.
>
On Tue, 12 Jun 2001, Cyrille Chepelov wrote:
> Le mar, jun 12, 2001, à 02:31:25 +0200, Cyrille Artho a écrit:
>> Hi,
>> when exporting dia drawings to xfig, rectangles with rounded corners get
>> broken up into lines and arcs. I had used the "Flowchart - Box" item to
>> get rectangles with rounde
Le mar, jun 12, 2001, à 12:47:18 -0500, Lars Clausen a écrit:
> > Both these functions pointers would be members added at the end of struct
> > RendererOps, and would be totally optional (ie, diagramdata.c's routines
> > will check for NULL members, and either repeatedly check, or fill the
> > re
On Tue, 12 Jun 2001, Cyrille Chepelov wrote:
> Le mar, jun 12, 2001, à 12:47:18 -0500, Lars Clausen a écrit:
>
>> > Both these functions pointers would be members added at the end of
>> > struct RendererOps, and would be totally optional (ie, diagramdata.c's
>> > routines will check for NULL mem
Well, I was racking my head for a simple algorithm that could be used
for layouts involving dynamic shapes (ie UML shapes that "grow" when
data is placed in them). I hadn't realized how simple the algorithm
could be. First off I must introduce the concept of a container shape.
Container shapes w
Hmm, ascii art doesn't seem to work well. Hopefully you get the idea.
-J5
___
Dia-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/dia-list
Le mar, jun 12, 2001, à 03:59:25 +0100, John Palmieri a écrit:
> While this doesn't answer all layout questions it seems like a good
> start to getting rid of hard coded shapes (I'm thinking of UML) and
^ ^
> pushing dia to become a pretty nifty frontend/widget for a
Le mar, jun 12, 2001, à 01:53:50 -0500, Lars Clausen a écrit:
> > OTOH, we could have have FEATURE_ARROW etc. Both options are open (I'd
> > think have renderers give NULL ops pointers for optional functions, and
> > have something in diagramdata fill in stubs & helpers, so we don't need
> > to t
On Tue, 12 Jun 2001, Cyrille Chepelov wrote:
> Le mar, jun 12, 2001, à 01:53:50 -0500, Lars Clausen a écrit:
>> A third idea I came up with for this: Have the renderer only define the
>> most basic shapes as fixed function pointers, and everything else
>> (rectangles, arrows, polylines, even comp
Well the whole point of putting everything in XML is that there is a consistent
scripting interface (the DOM) and XML separates the logic from the data. Hard
coding only allows access to API's that the developer thought of including.
Sure you can create an object model so that all objects created
On 12 Jun 2001, Lars Clausen wrote:
> Sounds like a good implementation plan. Only the FEATURE and SHAPE groups
> don't really solve the problem, as all you can really do at this level is
> group.
>
> Somebody (I forget who) suggested having some more complex shapes (arrows,
> rounded rectangles
On Wed, 13 Jun 2001, James Henstridge wrote:
> On 12 Jun 2001, Lars Clausen wrote:
>
>> Sounds like a good implementation plan. Only the FEATURE and SHAPE
>> groups don't really solve the problem, as all you can really do at this
>> level is group.
>>
>> Somebody (I forget who) suggested having
Le mar, jun 12, 2001, à 05:39:56 +0100, John Palmieri a écrit:
> That is like saying configuration files should be written in C or PNG should be
> a series of putpixel commands. Abstracting your data into XML files allows for
> an easier to manage and more flexible program.
Have you ever read
16 matches
Mail list logo
