Re: labels for lines?

2001-04-20 Thread David Thompson

  is there a way to stick a text label to a line in dia, to identify the
  relationship that the line signifies? i want the label to follow the line
  when i move it.
 
 There are several sheets that have such lines.  For instance, UML/Message
 or FS/Flow will do that.  Unfortunately, they are not very flexible in
 terms of line attributes.

I looked at this a while back with the idea of making a "child class" of
the line types for lines with text and then a "child" of _that_ class as
my FS/Flow object, but it wasn't clear to me how to derive an object without
copying a bunch of the code at that point. Now I see how, but I keep hearing
that there's going to be a move to the GTK inheritance mechanism and GObject
in the not-too-distant future, so I've held off. I guess the other reason
I've held off is that it seems like there should really only be one type of
line (instead of orthogonal, polygonal, bezier, arc, ...). The curve's
shape should be independent of the connections. That way, a lot more code
could be shared. For instance, you could add text to a line and have it work
no matter the shape of the line.

Is anyone else interested in working on that? If we were careful, we could even
make the same code used for lines work for the boxed shapes (they would just be
closed curves instead of open curves).

David




Re: FS patch

2001-04-13 Thread David Thompson

 Seems to work.  That sure is a lot of words in those menus.  Now I don't
 know the FS system, but a submenu link Verb/Channel/Guide/Guide/Guide seems
 funny to me.  Is this a standardized setup?
There is no standard setup I'm making it up as I go along (the
interface, that is -- the verbs form a "standard basis" that people
contend will cover every mechanical product). I struggled with the
menus, but
1. There's no way for a menu item to be a button and a submenu
2. Having a menu with a repeated word seemed just as awkward,
   especially since the menu is really there for people that are
   just learning, who will need to see the list of "refinements"
   of each word anyway.
If you have any suggestions, I'd be glad to hear them.

 Also, it would be nice if the two Fn entries were togglemenus.
I didn't see a way to do this with DiaMenu items. Want me to add
something to the DiaMenu struct for it, or is there a better way?

The other thing I've been thinking about is a way to add some
"document-class" specific functions to Dia. For instance, many
people want to add functions to Dia that only run on UML diagrams.
What if, in addition to 
  object name="blahdescriptionyadda/description/object
entries in sheets there were
  menu name="blah"descriptionyadda/description
function name="blah"descriptionyadda/description/function
  /menu
tags that would put up sheet-sensitive menu items only when that
sheet was selected?

 It will be in CVS in the morning.
Thanks!

 Just so that we have somebody do it, I will make sure to apply any patch
 sent to the list, unless somebody else objects to it.  I'll give one day
 for objections, and send an acknowledgement when it's in CVS.
I hope I didn't sound angry about it... it's just a little tedious to keep
a patch up to date when the CVS source is changing. (Not that CVS
maintainers have exciting, tedium-free lives :-)

David




Submenus for the object menu

2001-03-11 Thread David Thompson

The patch
http://madlab.me.utexas.edu/~dcthomp/dload/dia-submenu.patch.gz
changes create_object_menu() to allow for submenus in Dia's object-
related popup menus. The DiaMenu and DiaMenuItem structures are unchanged.
If you want a submenu, create a DiaMenuItem with callback=NULL and 
callback_data pointing to a DiaMenu.

Also, if the DiaMenu's title == NULL, no menu item is created
in the submenu with the name of the submenu's title.

The patch also includes a modification to the FS module that
uses this new feature to make the function structure object menu
much more usable.

The patch is against the current CVS. Please let me know if
you have any philosphical or diff-related trouble with it.

Thanks,
David




Re: Double-headed arrows

2000-08-02 Thread David Thompson

  Do you need this for all arrow types (some new mechanism needed) or just the
  'standard' - arrow (just one new arrow type)?
 I would need it for only 2 arrowtypes, the hollow-triangle arrow ( --||  )
 and it's filled counterpart. The 'standard' - arrow isn't used for my
 application.
 ...
 Why is it harder for all but the 'standard' arrow?

I think the point is: It's not any harder, but having a double-headed
version for every type of arrow adds clutter to the user interface.
If lots of double-headed versions are needed, it would be better to
rewrite the draw_type functions to accept an additional parameter
indicating double-headedness rather than make a whole new 
draw_type_doubleheaded function. Of course, then you have to put
a button somewhere on the user interface to set the value of the
double-headedness parameter passed to the draw_type function.

David




[PATCH] Undo information for flow.c

2000-06-04 Thread David Thompson

I've added undo information to the flow object on the
FS sheet. The patch is attached. Note that I modified
the KNOWN_BUGS file to remove the notice about undo
information, but the non-standard use of menus is
still there. If you tell me what seems broken to you
(or even better yet, what kind of a fix you had in mind),
I will work on it.

David

*** dia-0.85/objects/FS/flow.c  Mon May  8 20:21:34 2000
--- dia-0.86/objects/FS/flow.c  Sun Jun  4 21:58:25 2000
***
*** 33,44 
  
  #include "pixmaps/flow.xpm"
  
- Color flow_color_energy   = { 1.0f, 0.0f, 0.0f };
- Color flow_color_material = { 0.8f, 0.0f, 0.8f };
- Color flow_color_signal   = { 0.0f, 0.0f, 1.0f };
- 
  typedef struct _Flow Flow;
  typedef struct _FlowDialog FlowDialog;
  
  typedef enum {
FLOW_ENERGY,
--- 33,41 
  
  #include "pixmaps/flow.xpm"
  
  typedef struct _Flow Flow;
  typedef struct _FlowDialog FlowDialog;
+ typedef struct _FlowChange FlowChange;
  
  typedef enum {
FLOW_ENERGY,
***
*** 64,69 
--- 61,83 
GtkWidget *m_material;
GtkWidget *m_signal;
  };
+ 
+ enum FlowChangeType {
+   TEXT_EDIT=1,
+   FLOW_TYPE=2,
+   BOTH=3
+ };
+ 
+ struct _FlowChange {
+   ObjectChangeobj_change ;
+   enum FlowChangeType change_type ;
+   FlowTypetype ;
+   char*   text ;
+ };
+ 
+ Color flow_color_energy   = { 1.0f, 0.0f, 0.0f };
+ Color flow_color_material = { 0.8f, 0.0f, 0.8f };
+ Color flow_color_signal   = { 0.0f, 0.0f, 1.0f };

  #define FLOW_WIDTH 0.1
  #define FLOW_MATERIAL_WIDTH 0.2
***
*** 139,144 
--- 153,208 
(ObjectMenuFunc)  flow_get_object_menu,
  };
  
+ static void
+ flow_change_apply_revert(ObjectChange* objchg, Object* obj)
+ {
+   struct _FlowChange* change = (struct _FlowChange*) objchg ;
+   Flow* oflow = (Flow*) obj ;
+ 
+   if ( change-change_type == FLOW_TYPE || change-change_type == BOTH ) {
+ FlowType type = oflow-type ;
+ oflow-type = change-type ;
+ change-type = type ;
+ flow_update_data(oflow) ;
+   }
+ 
+   if ( change-change_type  TEXT_EDIT  || change-change_type == BOTH ) {
+ char* tmp = text_get_string_copy( oflow-text ) ;
+ text_set_string( oflow-text, change-text ) ;
+ g_free( change-text ) ;
+ change-text = tmp ;
+   }
+ }
+ 
+ static void
+ flow_change_free(ObjectChange* objchg)
+ {
+   struct _FlowChange* change = (struct _FlowChange*) objchg ;
+ 
+   if (change-change_type  TEXT_EDIT  || change-change_type == BOTH ) {
+ g_free(change-text) ;
+   }
+ }
+ 
+ static ObjectChange*
+ flow_create_change( enum FlowChangeType change_type,
+   FlowType type, Text* text )
+ {
+   struct _FlowChange* change ;
+   change = g_new( struct _FlowChange, 1 ) ;
+   change-obj_change.apply = (ObjectChangeApplyFunc) flow_change_apply_revert ;
+   change-obj_change.revert =  (ObjectChangeRevertFunc) flow_change_apply_revert ;
+   change-obj_change.free =  (ObjectChangeFreeFunc) flow_change_free ;
+   change-change_type = change_type ;
+ 
+   change-type = type ;
+   if ( text ) {
+ change-text = text_get_string_copy( text ) ;
+   }
+ 
+   return (ObjectChange*) change ;
+ }
+ 
  static real
  flow_distance_from(Flow *flow, Point *point)
  {
***
*** 256,262 
Point *endpoints, p1, p2;
ArrowType arrow_type;
int n1 = 1, n2 = 0;
!   Color* render_color ;
  
assert(flow != NULL);
assert(renderer != NULL);
--- 320,326 
Point *endpoints, p1, p2;
ArrowType arrow_type;
int n1 = 1, n2 = 0;
!   Color* render_color = color_black ;
  
assert(flow != NULL);
assert(renderer != NULL);
***
*** 351,357 
  flow-text = text_copy( flow_default_label ) ;
  text_set_position( flow-text, p ) ;
} else {
! Color* color ;
  
  if (flow_font == NULL)
flow_font = font_getfont("Helvetica-Oblique");
--- 415,421 
  flow-text = text_copy( flow_default_label ) ;
  text_set_position( flow-text, p ) ;
} else {
! Color* color = color_black ;
  
  if (flow_font == NULL)
flow_font = font_getfont("Helvetica-Oblique");
***
*** 424,430 
Connection *conn = flow-connection;
Object *obj = (Object *) flow;
Rectangle rect;
!   Color* color ;

obj-position = conn-endpoints[0];
  
--- 488,494 
Connection *conn = flow-connection;
Object *obj = (Object *) flow;
Rectangle rect;
!   Color* color = color_black ;

obj-position = conn-endpoints[0];
  
***
*** 519,527 
  flow_apply_properties(Flow *flow)
  {
FlowDialog *prop_dialog;
!   
prop_dialog = properties_dialog;
  
text_set_string(flow-text,
gtk_editable_get_chars( GTK_EDITABLE(prop_dialog-text),
  0, -1));
--- 583,594 
  flow_apply_properties(Flow *flow)
  {
FlowDialog *prop_dialog;
!   ObjectChange *change;
! 
prop_dialog = 

Re: Another crash, latest CVS sources

2000-05-09 Thread David Thompson

  Also, were there problems with the other FS patch
  I sent a couple weeks ago?
  You mean the undo stuff? That is applied.
Sorry, there must have been some fuzz on my brain when
I looked at Bonsai CVS archive.

I noticed that in KNOWN_BUGS, you say that I am using menus
in a non-standard way -- I assume you mean the names of all
the functions. These names are supposed to form a "standard
basis" for all function structures and we (the professor and
teaching assistants for the design course that will be using
this in the summer) would like to have these function names
available for students because it improves their work. Is
there some standard way to make these available? The object
menu seems like a good place to me because you don't even
have to leave the "function tool" mode to add the text to a
newly created function. I am open to suggestions, but I would
like to see it remain as easy to use.

David




[PATCH] Function structure update

2000-04-12 Thread David Thompson
oc(sizeof(Orthflow));
+  orthflow = g_new(Orthflow,1);
 
   orth = orthflow-orth ;
   orthconn_init( orth, startpoint ) ;
@@ -311,12 +300,13 @@
   orthflow-text_handle.type = HANDLE_MINOR_CONTROL;
   orthflow-text_handle.connect_type = HANDLE_NONCONNECTABLE;
   orthflow-text_handle.connected_to = NULL;
-  obj-handles[2] = orthflow-text_handle;
+  object_add_handle( obj, orthflow-text_handle ) ;
   
   orthflow_update_data(orthflow);
 
+  /*obj-handles[1] = orth-handles[2] ;*/
   *handle1 = obj-handles[0];
-  *handle2 = obj-handles[1];
+  *handle2 = obj-handles[2];
   return (Object *)orthflow;
 }
 
@@ -451,9 +441,12 @@
 orthflow_apply_properties(Orthflow *orthflow)
 {
   OrthflowDialog *prop_dialog;
+  ObjectChange* change ;
   
   prop_dialog = properties_dialog;
 
+  change = orthflow_create_change( BOTH,
+  orthflow-type, orthflow-text ) ;
   text_set_string(orthflow-text,
   gtk_editable_get_chars( GTK_EDITABLE(prop_dialog-text),
  0, -1));
@@ -467,7 +460,7 @@
 
   orthflow_update_data(orthflow);
 
-  return NULL;
+  return change ;
 }
 
 static void
@@ -619,19 +612,33 @@
 static ObjectChange *
 orthflow_set_type_callback (Object* obj, Point* clicked, gpointer data)
 {
+  ObjectChange* change ;
+  change = orthflow_create_change( FLOW_TYPE, ((Orthflow*)obj)-type, 0 ) ;
+
   ((Orthflow*)obj)-type = (int) data ;
   orthflow_update_defaults( (Orthflow*) obj, 1 ) ;
   if ( defaults_dialog )
 fill_in_defaults_dialog() ;
   orthflow_update_data((Orthflow*)obj);
 
-  return NULL;
+  return change;
+}
+
+static ObjectChange *
+orthflow_segment_callback (Object* obj, Point* clicked, gpointer data)
+{
+  if ( (int)data )
+ return orthconn_add_segment( (OrthConn*)obj, clicked ) ;
+
+  return orthconn_delete_segment( (OrthConn*)obj, clicked ) ;
 }
 
 static DiaMenuItem orthflow_menu_items[] = {
   { N_("Energy"), orthflow_set_type_callback, (void*)ORTHFLOW_ENERGY, 1 },
   { N_("Material"), orthflow_set_type_callback, (void*)ORTHFLOW_MATERIAL, 1 },
   { N_("Signal"), orthflow_set_type_callback, (void*)ORTHFLOW_SIGNAL, 1 },
+  { N_("Add segment"), orthflow_segment_callback, (void*)1, 1 },
+  { N_("Delete segment"), orthflow_segment_callback, (void*)0, 1 }
 };
 
 static DiaMenu orthflow_menu = {
diff -N -u -r dia-0.82/objects/FS/flow-ortho.h dia-0.82-patched/objects/FS/flow-ortho.h
--- dia-0.82/objects/FS/flow-ortho.hWed Dec 31 18:00:00 1969
+++ dia-0.82-patched/objects/FS/flow-ortho.hMon Feb 28 22:33:01 2000
@@ -0,0 +1,85 @@
+/* Dia -- an diagram creation/manipulation program
+ * Copyright (C) 1998, 1999 Alexander Larsson
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+
+/* If you have a problem with the Function Structure (FS) components,
+ * please send e-mail to David Thompson [EMAIL PROTECTED]
+ */
+#ifndef flow_ortho_h
+#define flow_ortho_h
+
+#include assert.h
+#include gtk/gtk.h
+#include math.h
+#include string.h
+#include stdio.h
+
+#include "config.h"
+#include "intl.h"
+#include "object.h"
+#include "objchange.h"
+#include "connection.h"
+#include "render.h"
+#include "handle.h"
+#include "arrows.h"
+#include "diamenu.h"
+#include "text.h"
+#include "orth_conn.h"
+
+typedef struct _Orthflow Orthflow;
+typedef struct _OrthflowDialog OrthflowDialog;
+typedef struct _OrthflowChange OrthflowChange;
+
+typedef enum {
+  ORTHFLOW_ENERGY,
+  ORTHFLOW_MATERIAL,
+  ORTHFLOW_SIGNAL
+} OrthflowType;
+
+struct _Orthflow {
+  OrthConn orth ;
+
+  Handle text_handle;
+
+  Text* text;
+  OrthflowType type;
+};
+
+struct _OrthflowDialog {
+  GtkWidget *dialog;
+  
+  GtkWidget *text;
+
+  GtkWidget *m_energy;
+  GtkWidget *m_material;
+  GtkWidget *m_signal;
+};
+
+enum OrthflowChangeType {
+  TEXT_EDIT=1,
+  FLOW_TYPE=2,
+  BOTH=3
+};
+
+struct _OrthflowChange {
+  ObjectChange obj_change ;
+  enum OrthflowChangeType  change_type ;
+  OrthflowType type ;
+  char*text ;
+};
+
+#endif /* flow_ortho_h */
diff -N -u -r dia-0.82/objects/FS/function.c dia-0.82-patched/objects/FS/function.c
--- dia-0.82/objects/FS/function.c  Thu 

Re: Dataflow diagrams?

2000-03-07 Thread David Thompson

 (What *does* FS stand for, anyways?)
It stands for "Function Structure" and is kind of like UML for mechanical
engineers. 

 Also, are there any docs anywhere for creating new objects?
Just the source. BTW, after a long absence, I will be posting some
fixes to make the FS stuff work again after the change from 0.4 to 0.84.
I hope FS stays in the distribution, but with everything being a module
and pretty much no mechanical engineers using Linux, I'd understand if
it got the axe.

David



Re: Dataflow diagrams?

2000-03-07 Thread David Thompson

 IMHO, it would be wrong to just axe it...  I am sure there are people
 using the FS stuff, and since it wouldn't really bother someone using
 dia, I don't think it's worth the axing. ;)

and

 ... One would hope that FS stays as well as all
 the other object types; indeed more types should be added (and hurrahs to
 all of you who are working on objects)!

Well, I am glad people want it to stay, but (as I am working madly on
my PhD) I don't have time to maintain it properly -- witness its
current state. That's why I offered to move it out. I may be able to
find someone around here who is researching function structures to
maintain it, though. The Win32 port also means that an undergrad class
here might end up using it, since right now they use Word for their
diagrams -- and complain endlessy.

David



Re: Dia for Win32

2000-03-01 Thread David Thompson

 Could you tell me more about the problem?
I downloaded dia-bin-2000-02-05.zip and
gtk+-bin-2000-02-05.zip from your site. I put
the gtk+ dlls in C:\winnt\system32\ (I also tried
putting them in the same directory as dia.exe
later). When I run dia, it generates an
application exception error.

Exception: access violation (0xc005) address 0x7800533b

I also tried downloading the Gimp for Win32
development library zip files that had dlls
in them (dated 2215) and that produced the
same error.

I am running NT 4.0sp5 under VMware (I use the
Linux version, but my professor wants Dia available
in the undergrad lab which is all NT). If you want,
I can try booting into NT directly.

Thanks,
David



Re: Dia for Win32

2000-02-29 Thread David Thompson

 The link on the Dia developer page to Dia for Win32 is dead. Could someone
 tell me where Dia for Win32 can be downloaded from ?
http://hans.breuer.org/dia/

If you are able to get the binary running without installing
the Gimp for Windows (i.e., just using the supplied gtk+ binaries),
let me know. When I tried, it just croaked and I don't have the
disk space to get cygwin and compile it under NT...

David