Can't read files that dia saves?
I made a drawing with Dia and saved it. When I try to re-open it, it won't read it. I tried giving it several extensions (.xml, .dia), but none seemed to help. I'm using 0.82. What gives? Dave -- David Copeland Software Engineering Director NOVO Relationship Architects for e-Business Voice 415 646 7026 | Fax 415 646 7001 http://www.novocorp.com
Re: DIA for Win32
On Sun, 6 Feb 2000, Hans Breuer wrote: Hi James et. al., based on tml's great work on Gimp and GTK, I've ported DIA to Windoze in almost one weekend. Cool! 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. Yeah. Were appicable I've replaced the some functions with their glib counter part (e.g.: snprintf - g_snprintf) There is actually an snprintf in lib/util.c that is compiled in if configure cannot detect snprintf (HAVE_SNPRINTF), but i guess it is better to use g_snprintf really. In fact maybe the snprintf implementation should be removed. 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]). Ok. - 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. The OS/2 port needed this too. I guess we're stuck with it. Is this patch and the availibility of DIA on Win32 interesting enough to be applied to CVS? Sure thing. It's not very intrusive. I'm checking it in right now. / Alex
Re: Can't read files that dia saves?
On Sun, 6 Feb 2000 [EMAIL PROTECTED] wrote: I made a drawing with Dia and saved it. When I try to re-open it, it won't read it. I tried giving it several extensions (.xml, .dia), but none seemed to help. I'm using 0.82. What gives? You need a newer version of libxml. Version 1.8.0 and some later ones had a bug. I don't know exactly which version fixed it, get the newest one. / Alex
Exporting EPS gives too big a bounding box
I have a diagram that I'm exporting to eps to include in a texinfo file. However, the file is too large (bounding box-wise). How might I get the file out with a more reasonable scale ? TeX simply rejects a file that 'size' :-( Please CC incase the sub request doesn't get processed in time :-) Nicholas. -- [EMAIL PROTECTED] http://www.innotts.co.uk/~nicholas/ 2048/BEC44395 1999/08/02 Nicholas C. Piper [EMAIL PROTECTED] If you want to change the automatic PGP actions of my mailer, see; http://www.innotts.co.uk/~nicholas/Personal/personal.php3?page=pgp
Re: Properties code
On Sat, 5 Feb 2000, Cyrille Chepelov (home) wrote: 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'll take a look at this if i get some time free this week. I think it would be good, and it should be done before all objects are converted to minimize work. / Alex
Re: Exporting EPS gives too big a bounding box
On Sun, 6 Feb 2000, Nicholas Piper wrote: I have a diagram that I'm exporting to eps to include in a texinfo file. However, the file is too large (bounding box-wise). How might I get the file out with a more reasonable scale ? TeX simply rejects a file that 'size' :-( Check out "File - Page setup in the CVS version". It has scaling functions. / Alex
Re: Properties code
On 5 Feb 2000, Lars Clausen wrote: 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 $* Strange. It works for me. / alex
Re: DIA for Win32
On Sun, 6 Feb 2000, Alexander Larsson wrote:
- 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.
The OS/2 port needed this too. I guess we're stuck with it.
It looks like there is something in the gmodule.h header which looks like
it could help with this. Instead of adding the stuff to the header file,
does it work if we change color.c to include gmodule.h and declare the
exported variables as:
G_MODULE_EXPORT Color color_black = { 0.0, 0.0, 0.0 };
...
This seems to be used in a few other programs on CVS, and looks a little
nicer (after doing a quick check with LXR). I can't test if this works on
win32 as I don't have a windows system set up with compilers and
everything.
James.
Re: Properties code
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].
Sometimes a simple offset is not enough -- for instance, with flowchart
box, one property corresponds to box-text-height, which can't be
described as an offset in the box structure (although, in this case maybe
making the Text structure a single property would be useful).
Having some convenience routines to help write the get/set_props functions
would be good.
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).
Another good idea. I think we may have touched on this in the last lot of
properties discussions on the list. The save function could be a standard
function, but the load one would probably need a small amount of object
dependent code. Each object will need to implement the properties they
inherit from Object, Element, etc. This should not be too difficult to
do.
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.
That should not be too difficult. I am not sure how many objects will
require a get_state/set_state function now though.
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).
Being able to specify some extra formatting for the properties would be
good. I don't think it is worth making it complicated enough to build the
UML class dialog though :)
Just my .02 EUR, of course.
-- Cyrille
James.
Re: DIA for WIN32
If someone wants to put in the effort to get dia to work on another platform, do you really think it is the right thing to stop them because you don't like the platform? If anything, this sort of thing makes free unix like operating systems a more desirable platform for writing cross platform GUI apps (the majority of the patch was windows makefiles and a few bug fixes that are not windows specific). If it is any consolation, GTK applications generally work better under X than windows (redraws aren't handled as well) at the moment. GTK-1.4 will probably change this as it is becomming cross platform itself (at least X and win32 will be supported -- probably beos as well). James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ On Sun, 6 Feb 2000, Sean Doull-Connolly wrote: Just a thoughtsome of us (eg me!) are using Linux so that we can eliminate Microsoft hassles (eg poor software, poor value, high cost, etc) from our lives. Although I admit it would be nice if great software like DIA was widely used by WIN32 users, it would be nicer if more people realized that it's easy to use Linux ... and cheaper ... and more reliable and ...but I'm sure you get the point. Thanks for great software. Sean
Re: DIA for WIN32
On Sun, 6 Feb 2000, Sean Doull-Connolly wrote: Just a thoughtsome of us (eg me!) are using Linux so that we can eliminate Microsoft hassles (eg poor software, poor value, high cost, etc) from our lives. Although I admit it would be nice if great software like DIA was widely used by WIN32 users, it would be nicer if more people realized that it's easy to use Linux ... and cheaper ... and more reliable and WIN32 is unsuitable for *me*, but I feel that the freedom to use the software one wants to is an important freedom, and ports go a long way to support that freedom. The only counter-argument to ports I can see is that developers have a finite amount of time, and some software can be ridiculously to port to some OSes. (WIN32 is (rightly) infamous for this, but appearently the dia win32 port wasn't too hard.) (Not a dia developer, but I couldn't keep my mouth shut.)
Re: DIA for WIN32
James Henstridge wrote: If anything, this sort of thing makes free unix like operating systems a more desirable platform for writing cross platform GUI apps (the majority of the patch was windows makefiles and a few bug fixes that are not windows specific). On Sun, 6 Feb 2000, Sean Doull-Connolly wrote: Although I admit it would be nice if great software like DIA was widely used by WIN32 users, it would be nicer if more people realized that it's easy to use Linux ... and cheaper ... and more reliable and For my personal use, I use Linux almost exclusively. At the office we do quite a bit of jumping around. Sometimes a tool establishes itself as a great tool regardless of platform. The Win32 GIMP does have its quirks, but 1) I don't have to learn a new tool, and I can swap xcf files around between Windows and my Linux box. 2) The boss would've never sprung for PhotoShop - its not really an official duty, and I worked for a very small company (no - not all corporations are big evil heartless creations that exist solely to dump pollutants into the environment (ala Captain Planet), despite what some in the free software movement seem to think), and 3) Apps drive most folks choice of platform. When someone takes a look at GIMP or DIA, cause its free and does pretty much what they need it to do, they're more likely to say later "Hey, maybe I could give Linux a try." I don't particular like Microsoft either, but let's please grow up about it. I welcome a Win32 port for Dia, in hopes that I'll be able to use the same drawing package on Linux, Irix, and Windows. That would be truly useful to me. Sorry for the OT rant. Nathan
UML diagrams - source code conversion
Hi, I have been using dia for a while now to create UML diagrams for various C++ projects of mine - I must say, it's very nice and has matured very well. Thanks! I'm wondering whether there is any interest in writing some kind of UML - source code converter (I would be very interested in getting something like that going for C++/Python, even Perl) that supports the XML output generated by Dia. It shouldn't be all that hard, thanks to the output being in XML. If there is such an effort already started, I would appreciate any pointers to it. Otherwise I'll probably start a dia-c++ conversion tool of my own. Thanks, Stefanus Du Toit - mailto:[EMAIL PROTECTED] | http://ultracool.net/ | icq:16775610 - WorldForge server coder. http://www.worldforge.org/ - GPG key: http://slashdot.org/users.pl?nick=sdt ---(random tagline)--- My way of joking is to tell the truth. That's the funniest joke in the world. -- Muhammad Ali
