DIA for Win32
Hi James et. al., based on tml's great work on Gimp and GTK, I've ported DIA to Windoze in almost one weekend. There are only small changes in the original sources needed. The whole patch (including hand written make- and export-files) consist of an only 22K zip file. Most of the work were missing includes, which I expect to be needed on Linux, too; if you would use the same warning as error level. Were appicable I've replaced the some functions with their glib counter part (e.g.: snprintf -> g_snprintf) There are only two windoze specific changes: - an additional indirection is needed to access DIA's directories. On Unix it simply maps to the respective compile time definitions. On Win32 it determines the dia executable directory at runtime and maps the sub-directories relative to it (see dia_dirs.[c|h]). - the color variables (color_black, gdk_color_black, ...) in lib/color.h need to be exported explicitly when compiling libdia.dll and to be imported from the other modules to get initialized properly. Is this patch and the availibility of DIA on Win32 interesting enough to be applied to CVS? Attached are only the changes to existing source files. If you are interested to get the whole thing, get the patch from: http://hans.breuer.org/dia/dia-2000-02-05-hb.zip There is a web page about dia on Win32, too: http://hans.breuer.org/dia Best Regards, Hans dia-2000-02-05-hb.diff.zip Hans "at" Breuer "dot" Org --- Tell me what you need, and I'll tell you how to get along without it.-- Dilbert
Re: Properties code
On Sat, 5 Feb 2000, [EMAIL PROTECTED] wrote: > I just thought I would post something about the code I am working on in > dia at the moment -- the properties interfaces. > > These interfaces give a standard way to programatically get or set > properties (eg. border width, text font, etc) of an object in dia. For > more information on this, see some of the earlier posts in the archives > at: > http://www.mail-archive.com/dia-list@lysator.liu.se/ Good! I'll start updating the standard objects as soon as I can. However, I found a crash bug: Create a standard box and a flowchart box. Double-click the standard box, then double-click the flowchart box. Crashes with the following output: IMLIB ERROR: SHM can't get SHM Identifier for Shared Pixmap Wrapper Falling back on Shared XImages IMLIB ERROR: SHM can't get SHM Identifier for Shared XImage Falling back on XImages app/run_dia.sh: line 17: 539 Segmentation fault (core dumped) $DEBUGGER /home/lrclause/src/dia/app/dia $* -Lars -- Lars R. Clausen (http://shasta.cs.uiuc.edu/~lrclause) Hårdgrim of Westfield "I do not agree with a word that you say, but I will defend to the death your right to say it." --Evelyn Beatrice Hall
Re: Properties code
First, congrats, your code passed the "Murphy, first stage" test : it
worked here (with -march=k6) (I didn't have the time to shake it with
ElectricFence, though).
On Sat, 5 Feb 2000, James Henstridge wrote:
> I have converted the flowchart/box object over to using the properties
> as a test case. It has reduced the code size by a fair ammount (there is
> still a bit of dead code I haven't trimmed out yet, but it looks like it
> cuts off around 100 lines of code). The automatically generated
> properties dialog works pretty well, and even undo with it works
> correctly. It doesn't seem to crash either, which is good :)
Are these masses of tests (in box_[sg]et_props()) really necessary ?
What about having struct type (ObjectType *) and field offset fields in
PropDescription, and then let a pair of object_auto[sg]et_props()
functions handle that automatically ? [there will probably be a need for
macros around G_STRUCT_MEMBER to handle the access to the object's
fields].
I've got a 4) to append to your list of things to do :
4) provide functions which use the PropDescription to automate the
grunt work of _save() and _load() functions (basically, _load() becomes
_create() + modification of the field values according to whatever was
saved, then only update_values() the object). Bumm ! 100 less lines of
code per object (30-40 with lazyprops.h).
Are _[sg]et_state() still useful/mandatory with your code ? If yes, then :
5) provide functions to automatically build state objects
according to the PropDescription. If an object is complicated enough to
require a manual implementation, then the programmer still has the choice
to manually implement _[sg]et_state(). Otherwise, it becomes :
void foo_set_state(Foo *foo, FooState *state) {
prop_auto_get_state(state,foo_props,foo);
}
and basta ! 30 less lines of code per object.
Finally (while I'm at this),
6) There might be a use for a NotebookPageDesc object :
struct NotebookPageDesc {
{ _N("page 1"), 0 },
{ _N("page 2"), 0 },
{ _N("page 3"), 0 },
{ NULL } };
Then a field in PropDescription to tell the dialog building code in which
page to put each field (NULL page meaning _N("General"), and if only NULL
pages, then no notebook).
Just my .02 EUR, of course.
-- Cyrille
--
Grumpf.
Properties code
I just thought I would post something about the code I am working on in dia at the moment -- the properties interfaces. These interfaces give a standard way to programatically get or set properties (eg. border width, text font, etc) of an object in dia. For more information on this, see some of the earlier posts in the archives at: http://www.mail-archive.com/dia-list@lysator.liu.se/ The new code adds three new methods to objects: describe_props, get_props and set_props. Describe_props passes back an array of PropDescription structures describing the properties of an object. Get_props returns the current values of properties, and set_props sets the properties. Describe_props is not an object type method, as the properties may not be the same for all instances of an object type (the group object being a good example -- its properties should be dependent on the grouped objects). The information from the properties interface is usually enough to construct the properties dialog for a particular object. This cuts down on the ammount of work for the person writing the object. I have converted the flowchart/box object over to using the properties as a test case. It has reduced the code size by a fair ammount (there is still a bit of dead code I haven't trimmed out yet, but it looks like it cuts off around 100 lines of code). The automatically generated properties dialog works pretty well, and even undo with it works correctly. It doesn't seem to crash either, which is good :) The following lists a number of things that still need to be done with respect to the properties interface: 1) convert more objects to new interface. This will probably also help find problems with the implementation. 2) Add ability to add extra properties to custom shapes. This would allow you to add some non visible data to certain shape types, which could be useful if exporting diagrams to some other format. 3) Add support in the python plug-in. The plug-in should then be powerful enough to do things such as extracting the information from a UML diagram for use with a code generator for instance. If you find any problems with the interface, or have any comments, post them on the list. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/
