The only problem with the current implementation is that it isn't possible to pass temporary data. All that needs to be added to the current code is to free the pdata pointer if it isn't null:
1. To trigger an action that passes data to the listeners: void *pdata = malloc(sizeof(data_struct)); data_struct *d = (data_struct *)pdata; data_struct->x0 = 4.0; data_struct->y0 = 5.5; sp_perform_action(ACTION_EXPORT_AREA, pdata);
2. sp_perform_action passes pdata to the listeners for the event, casting pdata to (data_struct *). If the listener needs to save some of the data, it makes a local copy. void action_export_area(..., void *pdata) { data_struct *d = (data_struct *)pdata; set_area(d->x0, d->y0, ...) }
3. After serving all the listeners, sp_perform_action calls free on pdata.
DBus is meant for data communication between processes. It uses strings to represent the format of the data that is being passed back and forth. This is way overkill for an event system in a single application, because it's possible to pass around void pointers and cast to the correct data structure in the handler.
- Alex
On Thu, Dec 31, 2009 at 12:34 AM, Jon Cruz <jon@...18...> wrote:
On Dec 31, 2009, at 12:05 AM, Jon Cruz wrote:
... and speaking of command-line. I think that's the place for Alex to look. (next mail coming soon)
So... checking on the command-line help, I noticed one command that looks promising:
-a, --export-area=x0:y0:x1:y1 Exported area in SVG user units (default is the page; 0,0 is lower-left corner)
That one takes four parameters that are coordinates. Could easily take four that were page margins, etc.
So, I did a search on the codebase for that string. I found hits in only main.cpp:
c$ find . -name '*.cpp' -exec grep -H 'export-area' {} ; ./main.cpp: {"export-area", 'a', ./main.cpp: {"export-area-drawing", 'D', ./main.cpp: {"export-area-page", 'C', ./main.cpp: {"export-area-snap", 0, ./main.cpp: || !strncmp(argv[i], "--export-area-drawing", 21) ./main.cpp: || !strncmp(argv[i], "--export-area-page", 18) ./main.cpp: g_warning ("--export-use-hints can only be used with --export-id or --export-area-drawing; ignored."); ./main.cpp: g_warning ("You cannot use --export-area-page and --export-area-drawing at the same time; only the former will take effect."); ./main.cpp: g_warning ("EPS cannot have its bounding box extend beyond its content, so if your drawing is smaller than the page, --export-area-page will
Chasing that one with ""'s down, I see {"export-area", 'a', POPT_ARG_STRING, &sp_export_area, SP_ARG_EXPORT_AREA,
Aha! That tells us it is using the library support for parsing command-line options in a consistent manner. The parameters then are stored in that sp_export_area variable.
Doing a search, it can be seen as defined in main.cpp as static gchar *sp_export_area = NULL;
Uh oh. We see a bit of "evilness" sneak in where it is reinitialized: static void resetCommandlineGlobals() {
That's not so good, since global variables are in general not such a good thing. But we can ignore that for now...
Down in sp_do_export_png, we see that the string is parsed, used to set "area" which is in turn used to actually do the export of the image right there.
:-(
So it appears to not use the verb mechanism at all. Which means we're stuck for a "pretty" solution right off hand. Perhaps we will need to see how the DBus work is leveraging things.
So, Alex, what I think this shows is that you're not missing something obvious. However, Inkscape's internals appear to be, and really need to have that fixed.