0.89/CVS test: UML issues

I thought I would take a look at the most recent dia code, in preparation
for the 0.89 release. I found a few issues, described below. First, though,
my test conditions:
- debian linux 
- CVS as of 9/2/01 afternoon, pacific daylight time (not the 0.89 tarball)
- dia drawings created/modified using both the 0.86 and 0.88-1 dia releases

1. When launching dia (./app/run_dia.sh) I always get the following error:

     Gtk-CRITICAL **: gtkcontainer.c: line 713 (gtk_container_add):
     assertion `widget != NULL' failed.

   Is this related to the reason I don't get the dia graphic in the
   startup "splash" screen? I'm sure this is because I'm doing something
   stupid when I build, but I'm not certain what that is... I have 
   dia_logo.png in my local area, I have libpng2-dev and libpng0g-dev
   (i.e., "#define HAVE_LIBPNG 1").

2. UML Lifelines cause warning messages to print on the console because 
   the old objects don't contain new fields cpl_northeast, cpl_northwest,
   cpl_southeast, and cpl_southwest. This is not a huge issue, just a
   minor annoyance. Typical message output:

     ** WARNING **: No attribute cpl_southeast ((nil)) or no data((nil))
     in this attribute

3. In the new 0.89 candidate, UML Messages from previous versions 
   cause error dialog boxes to display the text:

     Taking enum value of non-enum node.

   This is also seems to be merely an annoyance, but with usability
   Consequences: with the drawing I loaded, I had to clean up more than
   100 of these dialog boxes splattered around my display!

Attached are two trivial dia files illustrating these problems. Both 
examples were created in dia 0.88-1.

These are, of course, non-issues if backwards compatibility is not a goal
of the 0.89 release. Is this the case?  I guess one question is: since it
appears that these are cosmetic and not functional problems, i.e., the
files *seemed* to be fine despite all the squawking, can warnings for these
new functionalities be supressed so all the legacy diagrams can be more
easily used in the new version?

Aside: it doesn't appear that the dia file format itself supports
versioning.  This might be a nice, easy addition: future dia versions
could use a compatibility mode when reading obsolete dia files, or refuse
to read the file when there is no reasonable way to convert to the new
file format. Has this ever been considered?



Attachment: lifeline.dia
Description: Text document

Attachment: enum.dia
Description: Text document

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