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
Re: XSLT Transformer plugin
Le Fri, May 17, 2002, à 03:59:23PM +0200, Mattam a écrit: > > * how does it behave when the XSLT processor isn't here? (we need to > >have dia not depend on the xslt processor, just suggest it). Ideally, we > >gray out the option; at the minimum, we should display an error dialog box. > Use dlopen. But I don't know how to avoid compiling it (using #ifdef's ?) Oh, if you use dlopen, then it's fine: the ELF loader will not complain loading your plug-in even if the xlst lib is not here. Then, you only have to fail gracefully if dlopen returns an error. > > * is the string handling UTF-8-clean ? This is a must. At the > >moment, there still must be #hell to handle both a non-UTF-8 gtk (*nix) and > >a modern GTK (Win32). > Not concerned. I take this as meaning: there is no string handling at all (except perhaps concatenations) in your plug-in. OK, this is UTF-8 clean. > >ObPatchNote: it would be even better if the archive was only a patch (with > >the new files patched against "empty" (there is an option for that in "cvs > >diff") > > I tried the option (-N) but I got errors from cvs not founding the > CVS/Entries file inside my local directory (which is quite logical :) > Could you tell me the exact way how to do it? Oh, I see. You're adding a whole new directory (of course). Hmmm. Perhaps a way would be to have a duplicate tree from the same CVS source, but without your modifications. Then, I guess a real "diff(1)" (/not/ cvs diff) with a couple -x arguments (to avoid diff'ing the CVS directories, for instance, or the .cvsignore'd files) will do the trick. -- Cyrille -- Grumpf. msg02315/pgp0.pgp Description: PGP signature
Re: Zoom Limit
Le Sat, May 18, 2002, à 03:23:28PM +0300, Steffen Macke a écrit: > Is there a reason why it's not > possible to zoom out beyond 5.00%? no reason, I guess. -- Cyrille -- Grumpf. ___ Dia-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/dia-list
RE: Zoom Limit
Title: RE: Zoom Limit Forget my answer: I realy love you, I´m very, very hot with you. -Mensaje original- De: Cyrille Chepelov [SMTP:[EMAIL PROTECTED]] Enviado el: lunes 20 de mayo de 2002 15:34 Para: [EMAIL PROTECTED] Asunto: Re: Zoom Limit Le Sat, May 18, 2002, à 03:23:28PM +0300, Steffen Macke a écrit: > Is there a reason why it's not > possible to zoom out beyond 5.00%? no reason, I guess. -- Cyrille -- Grumpf. ___ Dia-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/dia-list
Re: XSLT Transformer plugin
At 20:33 20.05.02 +0200, Cyrille Chepelov wrote: >Le Fri, May 17, 2002, à 03:59:23PM +0200, Mattam a écrit: > >> >* how does it behave when the XSLT processor isn't here? (we need to >> >have dia not depend on the xslt processor, just suggest it). Ideally, we >> >gray out the option; at the minimum, we should display an error dialog box. >> Use dlopen. But I don't know how to avoid compiling it (using #ifdef's ?) > >Oh, if you use dlopen, then it's fine: the ELF loader will not complain >loading your plug-in even if the xlst lib is not here. Then, you only have >to fail gracefully if dlopen returns an error. > do you mean the dlopen known as LoadLibrary/GetProcAddress on win32 :-) If the code is prepared to do truly dynamic (=runtime) linking with ELF binaries it should be simple to make it cross-platform with the gmodule api, i.e. g_module_open/g_module_symbol. Though on win32 if a plug-in is linked against a non existing library Dia (or better gmodule) simply refuses to load it. That is: there already is code to handle the error gracefully. Hans Hans "at" Breuer "dot" Org --- Tell me what you need, and I'll tell you how to get along without it.-- Dilbert ___ Dia-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/dia-list
Re: XSLT Transformer plugin
Le Mon, 20 May 2002 22:22:37 +0200, Hans Breuer a écrit: >do you mean the dlopen known as LoadLibrary/GetProcAddress on win32 :-) >If the code is prepared to do truly dynamic (=runtime) linking >with ELF binaries it should be simple to make it cross-platform >with the gmodule api, i.e. g_module_open/g_module_symbol. > >Though on win32 if a plug-in is linked against a non existing >library Dia (or better gmodule) simply refuses to load it. >That is: there already is code to handle the error gracefully. Could you tell me where to find such code? I was thinking of #ifdefs to handle win32 builds, but this seems more general and elegant. -- "Not only is there no God, but try finding a plumber on Sunday. " - Woody Allen MaT|TaM (http://mattam.ath.cx) ___ Dia-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/dia-list
RE: Freetype problems under RH7.3
> Lars Clausen wrote: > On Fri, 17 May 2002, Robert Young wrote: > > The current FreeType code relies on X providing a font path > list, and on > > this list containing paths to TrueType and other fonts. > Under RH7.3 the > > XFree86 supplied has the font paths specified correctly. It doesn't > > however, load the modules which enable XFree86 to interpret > these fonts > > and hence XFree86 discards the paths to these fonts from > the font path. > > Hence dia complains about not having any fonts, and the > usual suspect, > > the font path, is not to blame. > > But if you tell X to load the modules, won't it work? Yes, but I consider this to be beyond most users, especially if there is a way around it. I know that we'll get lots of RH users asking the same question - could be annoying :-) > > I note that other programs which use freetype have a list > of hard coded, > > or user supplied, font paths. Should we look at this, or do > a hack by > > looking for an xfs configuration file (/etc/X11/fs/config) > and using the > > chkfontpath (a RH utility) code to extract font paths? > > If it exists, we can use it. In fact, we can include > hard-coded common > font paths as well. The more the merrier. Should I put this in diarc? I don't think it belongs in the preferences dialog, and if we include enough defaults for most of the known world, the FAQ can point them to playing with diarc? Mind you, this question is posed before I look at the code... > > I am concious that most RH7.x users will have the same > troubles I have > > experienced when we make a release. > > > > I'm willing to cut some code if required. > > That would be nice. Using XGetFontPath was the quick and easy way. And it works well in most cases! Give us a couple of days and I'll post a patch. Regards, Rob. ___ Dia-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/dia-list
Re: RE: Freetype problems under RH7.3
Le Tue, May 21, 2002, à 11:32:23AM +0930, Young, Robert a écrit: > > If it exists, we can use it. In fact, we can include > > hard-coded common > > font paths as well. The more the merrier. > > Should I put this in diarc? I don't think it belongs in the preferences > dialog, and if we include enough defaults for most of the known world, the > FAQ can point them to playing with diarc? Mind you, this question is posed > before I look at the code... Hmmm... Since the reason for this setting would be the lack of a working font path with the system (almost a bug in the OS' XF86Config, IMO), thus the lack of a bunch of fonts (a detectable condition), we could even pop a message up (ONCE !) pointing the user to the manual/to the FAQ on how to tweak this diarc setting. This would help us be very comfortable with ignoring PEBKAC/googlelessness/lack of FAQ-reading skills-type of questions on that topic. -- Cyrille -- Grumpf. ___ Dia-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/dia-list
