CVS of 2002-04-19 crashes
Hi, maybe I did sth. stupid, but I'm not able to start dia. I get the splash screen and than the crash, because menu_item_list is NULL, the first time sheets_optionmenu_create() is called, but is dereferenced. GDB says: $ DEBUGGER=gdb ./app/run_dia.sh GNU gdb 2002-04-01-cvs ... (gdb) run Starting program: /usr/local/src/dia-0419/app/dia Gdk-WARNING **: locale not supported by C library [New Thread 1024 (LWP 2860)] Gdk-WARNING **: locale not supported by C library Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 2860)] 0x0809c238 in sheets_optionmenu_create (option_menu=0x82ab780, wrapbox=0x825d750, sheet_name=0x0) at sheets.c:186 186 gtk_menu_item_activate(GTK_MENU_ITEM(menu_item_list->data)); (gdb) bt #0 0x0809c238 in sheets_optionmenu_create (option_menu=0x82ab780, wrapbox=0x825d750, sheet_name=0x0) at sheets.c:186 #1 0x0809c670 in sheets_dialog_create () at sheets.c:261 #2 0x08072e14 in app_init (argc=1, argv=0xbab4) at app_procs.c:342 #3 0x080a8152 in main (argc=1, argv=0xbab4) at main.c:36 (gdb) It seems that sheet_mods_list is NULL, so optionmenu_menu is empty and gtk_container_children() returns NULL. This return value Should be checked, maybe? Anyway, dia doesn't seem to find the sheets. Btw. gtk_container_children() is deprecated in GTK2. Thanks in advance! Cheers! ___ Dia-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/dia-list
Export PNG with fixed width?
Hi, I like to export a diagram in PNG format with a specific width, e.g. 400 pixels. Is this possible? I would prefer a command line over interactive usage, like $ dia foo.dia --export=foo.png --width=400 or sth. like that. Thanks in advance! Cheers! ___ Dia-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/dia-list
Use of the Python console/plugin
Hi, are there any examples or docs of the usage of the Python console and/or plugin in dia? Hints appreciated! Thanks in advance! Cheers! ___ Dia-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/dia-list
Extending dia using Python?
Hi, is it possible to use python for defining new dia object types instead of C? Thanks in advance! Cheers! ___ Dia-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/dia-list
Extending dia with libglade/glade?
Hi, is it possible to use glade and libglade to build object property dialogs etc. for dia objects? Thanks in advance! Cheers! ___ Dia-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/dia-list
How to use the PointArray property
Hallo,
I'm writing a new plugin for dia. I have defined a type
Condition derived from Connection, which has two "normal"
handles, and more handles can be added and removed by the
user via the object menu. This is similar to network/bus.c,
but I like to save the positions of the additional handles
without custom code. Instead I like to use the PointArray
property. The idea is to save the point positions when
saving and creating the Handle objects accordingly, because
all user-created handles are identical, except the ->pos.
Now my questions:
- Is my idea totally stupid?
- Can I save handle positions that way or do have I to write
custom code for saving the handle positions?
- Are the types etc. correct?
- Is there an example for using the PointArray property? (I
didn't find a dia plugin for that purpose, and
network/bus.c uses custom code instead. Why?)
- Isn't there a way to do the stuff in Python?
Here is an excerpt from my code, maybe someone can check it?
(I will give my code to the GNU community under GPL when
it's ready.)
Thanks in advance!
#include "prop_geomtypes.h"
typedef struct _Condition {
Connection connection;
...
GArray *handles;
GArray *handle_points;
} Condition;
static PropDescription condition_props[] = {
CONNECTION_COMMON_PROPERTIES,
...
{ "handle_points", PROP_TYPE_POINTARRAY, 0, NULL, NULL },
PROP_DESC_END
};
static PropOffset condition_offsets[] = {
CONNECTION_COMMON_PROPERTIES_OFFSETS,
...
{ "handle_points", PROP_TYPE_POINTARRAY, offsetof(Condition, handle_points)},
{NULL}
};
static Object *
condition_create(Point *startpoint,
void *user_data,
Handle **handle1,
Handle **handle2)
{
Condition *condition;
Connection *conn;
Object *obj;
Point p;
Handle *handle;
condition = g_new0(Condition, 1);
conn = &condition->connection;
obj = &conn->object;
conn->endpoints[0] = conn->endpoints[1] = *startpoint;
conn->endpoints[1].x += CONDITION_WIDTH;
obj->type = &condition_type;
obj->ops = &condition_ops;
connection_init(conn, 2, 0);
condition->handles = g_array_new(FALSE, TRUE, sizeof(Handle));
condition->handle_points = g_array_new(FALSE, TRUE, sizeof(Point));
condition_update_data(condition);
*handle1 = obj->handles[0];
*handle2 = obj->handles[1];
obj->handles[0]->connect_type = HANDLE_NONCONNECTABLE;
obj->handles[1]->connect_type = HANDLE_NONCONNECTABLE;
handle = g_new0(Handle, 1);
handle->id = HANDLE_CONDITION;
handle->type = HANDLE_MINOR_CONTROL;
handle->connect_type = HANDLE_CONNECTABLE_NOBREAK;
handle->connected_to = NULL;
handle->pos = *startpoint;
handle->pos.x = (conn->endpoints[0].x + conn->endpoints[1].x)/2.0;
handle->pos.y = conn->endpoints[0].y;
g_array_append_val(condition->handles, *handle);
object_add_handle(&condition->connection.object, handle);
return &condition->connection.object;
}
___
Dia-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/dia-list
XFig vs. dia 5:1
Hi, while I like dia more than XFig because of it's cool GTK+ GUI, there are some features I miss desperately. Maybe I just don't know, how to use dia rightly: 1. Hatches: XFig has all kind of lines and other patterns to fill shapes with. In many cases this is better than using colours, e.g. if it is for printing and no colour printer available. I did not find any hatches in dia. 2. LaTeX special fonts: XFig allows to mark text as "special". If exported to "Combined PS/LaTeX (both parts)" the result can be included in a LaTeX document while all fonts are the normal LaTeX fonts. This makes the resulting DVI look very consistent. I did not find this feature in dia. 3. Resizing of groups: XFig allows compound objects (or groups in dia jargon) to be resized. I don't need to explain why this is good :-) I didn't manage to resize groups in dia. 4. Libraries: XFig has some interesting element libraries, much like dia, but different. I don't know whether one import them in dia, but that would be nice. 5. Stability: XFig is (at least for me) a little bit more stable than dia. Maybe these are some suggestions for dia, maybe some of the functions are already there (but I did find them), or maybe one could port good ol' XFig to GTK+? :-) Cheers! ___ Dia-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/dia-list
Re: XFig vs. dia 5:1
Hi, thanks for your comments. On Sun, Jul 14, 2002 at 03:33:55PM +0100, Alan Horkan wrote: > i assume you did find the dashed lines feature which is set from the > bottom of the toolbox window. I meant hatches in respect to area, not line style. > Any shapes in particular? I like drawing new shapes for Dia when i am > not too busy. No, nothing in particular, but it would be cool too just use the XFig stuff. > If you can reproduce these crasher bugs please file them in > bugzilla.gnome.org > If you can run a debugger and send (as a link not as an attachment) > stack traces i am fairly sure Cyrille said he was willing to look at > them. That's what I did successfully in the past, but it's a matter of time - sometimes I just have to finish a diagram :-) > interoperability might be a better way to spend coding effort but to each > his own, good luck if you do decide to port it. "XFig versus Dia" this is > not a fight, if both work well together and both allow people to get stuff > done and choose the best software for the job then we all win. (i am > probably taking you too literally). As always in free software, I meant this to be productive competition and not a "fight". Cheers! ___ Dia-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/dia-list
Re: XFig vs. dia 5:1
Hi, thanks for your explanations. On Sun, Jul 14, 2002 at 11:08:09AM -0500, Lars Clausen wrote: > No, Dia does not have hatches. We're more geared towards structured > diagrams than vector art. It is a good suggestion, though. I see hatches mostly essential for technical diagrams, not as a part of vector art. Ideally, the hatches should be very flexible (colour, line style, angle, distance between lines, ...). > 0.88.1 was quite unstable. 0.90 is much better. Yes, dia becomes definitely more and more stable. Unfortunately, I had data losses on dia crashes. How about an "auto-save" feature like in Emacs? > > functions are already there (but I did find them), or maybe > > one could port good ol' XFig to GTK+? :-) > > That's been done: http://k332.feld.cvut.cz/~lemming/projects/gtkfig.html> This project seems to be not very active (last version 0.7.x of 1999) and more a rewrite than a port. Anyway, I didn't mean this too serious, and of course, the "XFig vs. dia" wasn't meant as a fight, more as a productive competition. Cheers! ___ Dia-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/dia-list
Re: XFig vs. dia 5:1
Hi, On Mon, Jul 15, 2002 at 10:28:55AM +0200, [EMAIL PROTECTED] wrote: > would you mind sending me some pointers to xfig shapes? Hm, I did `apt-get install xfig` on Debian unstable (yes, I'm one of the crazy/heroic people running unstable). This installs /usr/share/xfig/Libraries/ in fig format. It would be cool if dia could check this path and optionally, automatically use these. But much more important than the shapes are the hatches, IMHO - and this is difficult to implement. Cheers! ___ Dia-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/dia-list
Generic all-purpose text-box?
Hi, I'm looking for an all-purpose text-box, but didn't find one. The standard one in dia has optionally round corners, fill colour, line colour, line width, line style, but is missing multiline text and multiple connection points. I tried other boxes, like SADT box, but there I cannot change e.g. the fill colour. Anyway, it's kind of a basic need and should be in the standard box, right? Cheers! ___ Dia-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/dia-list
Re: Crazy colours in CVS dia
Hi, On Sat, Jul 20, 2002 at 06:36:40PM +0200, ml wrote: > in CVS dia of today I find all colours (background, grid, > lines, fill areas) totally weird. Sometimes blue or yellow > background with white grid, blue shapes. I'm pretty sure > being drug-free! All other gnome2/gtk2 apps look fine and Thanks to Lars the problem is gone! I'm still drug free and changed the default colour depth of my XServer from 8 to 24 bits. Thanks a lot and bye! ___ Dia-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/dia-list
Dia and GObject
Hi, just a general questions: As I understand, Object (lib/object.h) is not derived from GObject. Why? Same for other things like DiaMenu. Thanks for any explanation! Cheers! ___ Dia-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/dia-list FAQ at http://www.lysator.liu.se/~alla/dia/faq.html Main page at http://www.lysator.liu.se/~alla/dia
Restricting possible connections
Hi, I think about writing a new dia module, where certain objects can be connected only to certain others. (How) can I disallow connections between arbitrary objects? I.e. I have object types A, B, and C - while connections between A-B and A-C are allowed, but B-C should not be possible. Many thanks in advance! ___ Dia-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/dia-list FAQ at http://www.lysator.liu.se/~alla/dia/faq.html Main page at http://www.lysator.liu.se/~alla/dia
Re: Dia and GObject
On Thu, Oct 03, 2002 at 08:39:26AM -0500, Lars Clausen wrote: > Mainly because Dia started out before there was a GObject, and GTKObject > just wasn't right. We will move to GObject. Is the transition from GtkObject to GObject finished now? I.e. is it (relatively) save to cvs co, again? TIA! ___ Dia-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/dia-list FAQ at http://www.lysator.liu.se/~alla/dia/faq.html Main page at http://www.lysator.liu.se/~alla/dia
Re: Restricting possible connections
On Thu, Oct 24, 2002 at 12:21:22PM -0500, Lars Clausen wrote: > On Thu, 24 Oct 2002, [EMAIL PROTECTED] wrote: > > 2. Of course, this must be an option to the user. Maybe a > >diagram specific or a global option? > > Hmmm... good question. Global options are easier to make and do away > with. I really don't know which is better. Let's go for a global option first, and make it more advanced if the need is there. Other idea: Allow user the connection always if a modifier key is used (Escape/ Meta/Alt/Control/Shift). > > 3. The method to check has to be a new object function. > >Something like: > > > >typedef gboolean (*AllowConnectFunc) (Object* obj_me, > > Object* obj_other, > > ... /* ? */ ); > > You may want to give the handle and connection point to the function. > Could be some objects will allow objects to connect in certain ways and not > in others. Absolutely true. typedef gboolean (*AllowConnectFunc) (Object* obj_me, Object* obj_other, Handle* handle, ConnectionPoint* conpoint); Cheers! ___ Dia-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/dia-list FAQ at http://www.lysator.liu.se/~alla/dia/faq.html Main page at http://www.lysator.liu.se/~alla/dia
Re: Restricting possible connections
On Thu, Oct 24, 2002 at 09:23:48AM -0500, Lars Clausen wrote: > The right place to add a checking call would be in > layer_find_closest_connectionpoint() in app/diagramdata.c. Problem is, > that loop goes over all objects in a layer, so we can't afford to spend a > lot of time there. Well, we can keep it within the if, that'll cut out > most of it. And instead of adding code to DrawFunc, a new object func > should be defined for it. OK, I try to resume: 1. A restriction on possible connections seems to be a good idea. Think of network diagrams, not to speak of UML/Database/SDL/... code generation. 2. Of course, this must be an option to the user. Maybe a diagram specific or a global option? 3. The method to check has to be a new object function. Something like: typedef gboolean (*AllowConnectFunc) (Object* obj_me, Object* obj_other, ... /* ? */ ); 4. This function will be called twice (once for the connecting object, once for the connected one) from layer_find_closest_connectionpoint(). I don't see performance hits, if functions will be called after the "if (disthttp://mail.gnome.org/mailman/listinfo/dia-list FAQ at http://www.lysator.liu.se/~alla/dia/faq.html Main page at http://www.lysator.liu.se/~alla/dia
Re: Restricting possible connections
On Fri, Oct 25, 2002 at 08:05:51PM +0200, [EMAIL PROTECTED] wrote: > But, maybe, the function could be called only once - for the connection object. If >the > connection object wants, it can call some function in the two connected objects. > (But that would mean that it has to be able to find about objects' classes. Can it do > it now?) > > so e.g.: > > gboolean can_connect_objects (Object *self, Object *from, Handle *from_h, Object >*to, Handle *to_h) In principle, one function call is preferable to two or three :-) Question: How do I prevent a user from connecting a simple "line" with a UML class, if only the UML object "knows" about this access rights? (Note: I'm relatively new to the dia internals...) ___ Dia-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/dia-list FAQ at http://www.lysator.liu.se/~alla/dia/faq.html Main page at http://www.lysator.liu.se/~alla/dia
How to use the PointArray property
Hallo,
I had this question back in May, but most developers were
busy with the transition to GTK2, so I send it again:
I'm writing a new plugin for dia. I have defined a type
'Condition' derived from 'Connection', which has two
"normal" handles, and more handles can be added and removed
by the user via the object menu. This is similar to
network/bus.c, but I like to save the positions of the
additional handles without custom code. Instead I like to
use the PointArray property. The idea is to save the point
positions when saving and creating the Handle objects
accordingly, because all user-created handles are identical,
except the ->pos.
Now my questions:
- Can I save handle positions that way or do have I to write
custom code for saving (in XML) the handle positions?
- Are the types etc. correct?
- Is there an example for using the PointArray property? (I
didn't find a dia plugin for that purpose, and
network/bus.c uses custom code instead. Why?)
Here is an excerpt from my code, maybe someone can check it?
(I will give my code to the GNU community under GPL when
it's ready.)
Thanks in advance!
#include "prop_geomtypes.h"
typedef struct _Condition {
Connection connection;
...
GArray *handles;
GArray *handle_points;
} Condition;
static PropDescription condition_props[] = {
CONNECTION_COMMON_PROPERTIES,
...
{ "handle_points", PROP_TYPE_POINTARRAY, 0, NULL, NULL },
PROP_DESC_END
};
static PropOffset condition_offsets[] = {
CONNECTION_COMMON_PROPERTIES_OFFSETS,
...
{ "handle_points", PROP_TYPE_POINTARRAY, offsetof(Condition, handle_points)},
{NULL}
};
static Object *
condition_create(Point *startpoint,
void *user_data,
Handle **handle1,
Handle **handle2)
{
Condition *condition;
Connection *conn;
Object *obj;
Point p;
Handle *handle;
condition = g_new0(Condition, 1);
conn = &condition->connection;
obj = &conn->object;
conn->endpoints[0] = conn->endpoints[1] = *startpoint;
conn->endpoints[1].x += CONDITION_WIDTH;
obj->type = &condition_type;
obj->ops = &condition_ops;
connection_init(conn, 2, 0);
condition->handles = g_array_new(FALSE, TRUE, sizeof(Handle));
condition->handle_points = g_array_new(FALSE, TRUE, sizeof(Point));
condition_update_data(condition);
*handle1 = obj->handles[0];
*handle2 = obj->handles[1];
obj->handles[0]->connect_type = HANDLE_NONCONNECTABLE;
obj->handles[1]->connect_type = HANDLE_NONCONNECTABLE;
handle = g_new0(Handle, 1);
handle->id = HANDLE_CONDITION;
handle->type = HANDLE_MINOR_CONTROL;
handle->connect_type = HANDLE_CONNECTABLE_NOBREAK;
handle->connected_to = NULL;
handle->pos = *startpoint;
handle->pos.x = (conn->endpoints[0].x + conn->endpoints[1].x)/2.0;
handle->pos.y = conn->endpoints[0].y;
g_array_append_val(condition->handles, *handle);
object_add_handle(&condition->connection.object, handle);
return &condition->connection.object;
}
___
Dia-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/dia-list
FAQ at http://www.lysator.liu.se/~alla/dia/faq.html
Main page at http://www.lysator.liu.se/~alla/dia
Re: using dia for graphs (as in graph theory)
On Mon, Aug 11, 2003 at 05:34:46AM -0500, Lars Clausen wrote: > There's the basic shapes always shown in the toolbox. The boxes and > circles there don't allow parenting right now, but could be made to by > setting a single flag. Just for fun I set obj->can_parent = TRUE for the UML actor. It works great. Another important feature for graphing, I cannot yet find in dia: Allowing connections only between certain objects, e.g. not allow UML class inheritance between SDL state and network cloud. Cheers! ___ Dia-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/dia-list FAQ at http://www.lysator.liu.se/~alla/dia/faq.html Main page at http://www.lysator.liu.se/~alla/dia
Re: using dia for graphs (as in graph theory)
On Mon, Aug 11, 2003 at 03:46:12PM -0500, Lars Clausen wrote: > I don't think the objects should say anything about whether they can > connect to unknown other objects. I'd hate to try to set up an unorthodox > diagram only to find that the editor says no for no good reason. What we I agree 100%. I thought, there should be a switch "Allow all connections", defaulting to "yes", just like "Snap to grid" etc. IMHO, that's better than having the user to validate the diagram afterwards. Cheers! ___ Dia-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/dia-list FAQ at http://www.lysator.liu.se/~alla/dia/faq.html Main page at http://www.lysator.liu.se/~alla/dia
Dia "project" support
Hi, are there any plans to enhance dia to support diagrams that are belonging together? I.e. having a kind of "project" tree and allowing hyperlinks from objects to other diagrams? If dia were a bonobo component it could be embedded into an existing framework (anjuta?). Cheers! ___ Dia-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/dia-list FAQ at http://www.lysator.liu.se/~alla/dia/faq.html Main page at http://www.lysator.liu.se/~alla/dia
Drawing components? (UML, CORBA, CCM)
Hi, (how) can I draw CCM-like components in dia? CCM is the CORBA Component Model and one will use UML to describe CCM systems. However, some "arrows" seem to be missing in dia. receprecep facet +---+ taclefacet +---+ tacle o---|com|---(o---|com|---( |pon||pon| <>--|ent|---<<>--|ent|---< event |_| | event event |_| | event source | | sink source | | sink |_| | |_| | +---++---+ "component" and "implements" (= facet) exist, but receptacle, event source and event sink are missing. A much better and more accurate image can be found here: http://ccmtools.sourceforge.net/tutorial/node19.html (or http://ccmtools.sourceforge.net/tutorial/img27.png). Second question: (how) can I add more lines to an UML component? There seem to be only eight connection points by default. The left three of them are not even on the component box, but on the bounding box and thence useless to me. Many thanks in advance! Cheers! ___ Dia-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/dia-list FAQ at http://www.lysator.liu.se/~alla/dia/faq.html Main page at http://www.lysator.liu.se/~alla/dia
Re: using dia for graphs (as in graph theory)
On Mon, Aug 11, 2003 at 04:01:15PM -0500, Ribeiro, Glauber wrote: > I second this. I think dia should remain as a graphics editor, not try to be > an UML validator. Dia should remain as it is, but an optional(!) support for sensible drawings is desirable, IMHO. Cheers! ___ Dia-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/dia-list FAQ at http://www.lysator.liu.se/~alla/dia/faq.html Main page at http://www.lysator.liu.se/~alla/dia
