No internal handles in polyline -- dia 0.86/Win32 port
Hello, I tried dia for the first time and liked it. Just a little glitch. I could not find the (orange) internal handles in the polyline tool. Getting it onto the canvas just gives me a line segment with two green end handles. Is this a bug? (or maybe known already). I'm using the version 0.86, win32 port. Cheers, ST --
Re: No internal handles in polyline -- dia 0.86/Win32 port
Just a little glitch. I could not find the (orange) internal handles in the polyline tool. Getting it onto the canvas just gives me a line segment with two green end handles. Is this a bug? (or maybe known already). Try adding more segments to the polyline using the middle mouse button. (Hold down the Ctrl key and use the right mouse button in case the middle mouse button doesn't work.) Steffen _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: No internal handles in polyline -- dia 0.86/Win32 port
Steffen Macke wrote: Just a little glitch. I could not find the (orange) internal handles in the polyline tool. Getting it onto the canvas just gives me a line segment with two green end handles. Is this a bug? (or maybe known already). Try adding more segments to the polyline using the middle mouse button. (Hold down the Ctrl key and use the right mouse button in case the middle mouse button doesn't work.) Thank you very much, Steffen. The icon for polyline shows two internal handles and therefore I expect to see two. I'm simple minded. ;-) The other tools zig-zag line, arc, beziergon etc *are* intuitive! If this is not going to change in the implementation, maybe Q7 of the FAQ should include something to warn users that polyline will give only a line segment and your have to add internal handles yourself. And finding that I can add and delete (lots of) handles makes me like dia more. Cheers, ST --
Re: Dia for Win32
At 11:10 22.09.00 +0200, Gérald Quintana wrote: Hi, The link to Dia for Win32 ( http://hans.breuer.org/dia/ ) seems to be broken, where can I find it ? The link is correct, but I'm not sure if my provider is ... Further investigating, Hans Hans "at" Breuer "dot" Org --- Tell me what you need, and I'll tell you how to get along without it.-- Dilbert
Re: Dia 0.85 Win32 patch
On Wed, 24 May 2000, Hans Breuer wrote: Dia 0.85 for Win32 will be available at http://www.hans.breuer.org/dia within in the next hours. The required patch to compile it is attached. Pseudo-ChangeLog-Entry follows: * app/disp_callbacks.c: add a modifier (ctrl) to get the middle mouse button menu even with a two button mouse * dia_image.[ch]: resolve naming conflict with typedef struct DiaImage *DiaImage, which bites me with a new plug-in written in c++ * lib/font.c: explicit usage of "courier new" on Win32 to get the scalable version of this font family. This fixes the font resizeing with uml diagrams (There must be a better way to do this?) Don't use the preallocated color_gdk_white.pixel for font rendering bitmaps but use 1 as the color index. This fixes the black on black fonts while exporting png. Okay, I just applied the patch. It is good to see that the patches are getting smaller :) With the last problem, it is just by chance that it actually worked under X. The color_gdk_white and color_gdk_black GdkColor's were created under the default colormap, while the pixmap we are using for the font sucking is a one bit pixmap. Pixel values are not portable across colormaps. So I fixed this problem by hard coding the pixel values to 0 and 1. Have Fun, Hans James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/
Re: Dia 0.85 Win32 patch
On Wed, 24 May 2000, [EMAIL PROTECTED] wrote: At 12:29 24.05.00 -0500, Lars Clausen wrote: On Wed, 24 May 2000, [EMAIL PROTECTED] wrote: --=_959165802==_ Content-Type: text/plain; charset="us-ascii" Dia 0.85 for Win32 will be available at http://www.hans.breuer.org/dia within in the next hours. The required patch to compile it is attached. Pseudo-ChangeLog-Entry follows: * app/disp_callbacks.c: add a modifier (ctrl) to get the middle mouse button menu even with a two button mouse Uh, that's not a good choice. Ctrl is already in use to restrict movement to horizontal/vertical. I should have told it is in combination with the Right Mouse Button. Oh, that's fine then. -Lars -- Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause) | Hårdgrim of Numenor "I do not agree with a word that you say, but I| Retainer of Sir Kegg will defend to the death your right to say it."| of Westfield --Evelyn Beatrice Hall paraphrasing Voltaire | Chaos Berserker of Khorne
dia-0.84 Win32 Patch
Hi James et. al., attached a growing patch, to compile Dia on Win32 again. It addresses - as usual - some missing includes. Additional there are some things, which may need deeper looking: * app/interface.c : reverted toolbar buttons to stretch to window borders. IHMO it looks quite nicer even with 13 buttons * app/paginate_psprint.c : diagram_print_ps(Diagram *dia) defined a local var *dia - removed. Shouldn't GCC report this as bug, too? * lib/dia_dirs.c : changed path calculation for G_OS_WIN32. Same functionality * lib/plug-ins.c : Plug-in extension ".la" not required, at least not on Win32 * lib/properties.[h,c] : DIAVAR PropNumData. Don't try export variables, whiches pointer should be used in constant struct. Use static vars instead. The last thing was resolved some time ago, see below. (James, it's the same issue recently discussed on PyGtk list) At 00:52 02.03.00 +0100, Hans Breuer wrote: ... properties.h uses GIMPVAR to export prop_std_line_width_data, etc. Thanks for using it, but because later on there is used a pointer to these vars, which breaks the built (initializer is not a constant). The address depends on the dynamic linker and probably isn't resolved when initializing is needed. I've fixed it by declaring these vars as static, which will result in many instances (one for every includage of properties.h). Thanks in advance for applying this patch to CVS, Hans dia-00-04-18-hb.zip Hans "at" Breuer "dot" Org --- Tell me what you need, and I'll tell you how to get along without it.-- Dilbert
Re: Dia for Win32
Hello, I've been using DIA for a while in a Linux box, but now I have to do some work in a Windows machine. I downloaded GIMP and DIA for Windows and the gtk DLL's, but I can't run DIA succesfully, I get the following messages on the gdk.err file: GLib-CRITICAL **: file gstrfuncs.c: line 155: assertion `string1 != NULL' failed. ** ERROR **: Could not create per-user Dia config directory aborting... Gdk-CRITICAL (recursed) **: file gdkdraw.c: line 122: assertion `drawable != NULL' failed. aborting... Could somebody tell me If I missed something? Thanks in advance, P.S. DIA is a really great product, and If we can use it in any OS I'm sure its use is going to spread more and more everyday. Marco A. Morales AguirreDepartamento de Ing. en Computaci'on [EMAIL PROTECTED] Divisi'on de Ing. El'ectrica [EMAIL PROTECTED]Facultad de Ingenieria UNAM On Thu, 2 Mar 2000, Hans Breuer wrote: At 23:52 29.02.00 -0600, David Thompson wrote: The link on the Dia developer page to Dia for Win32 is dead. Could someone tell me where Dia for Win32 can be downloaded from ? http://hans.breuer.org/dia/ This may not work for some browser/connections. The longer form http://www.hans.breuer.org/dia/ should do it ... If you are able to get the binary running without installing the Gimp for Windows (i.e., just using the supplied gtk+ binaries), let me know. When I tried, it just croaked and I don't have the disk space to get cygwin and compile it under NT... CygWin wouldn't help here, because my port is based on M$VC. Could you tell me more about the problem? Hans Hans "at" Breuer "dot" Org --- Tell me what you need, and I'll tell you how to get along without it.-- Dilbert
dia-0.84 Win32 Patch
Hi James,
attached a small patch (mainly missing includes). But there
one thing I need your advice.
properties.h uses GIMPVAR to export prop_std_line_width_data, etc.
Thanks for using it, but because later on there is used a pointer
to these vars, which breaks the built (initializer is not a constant).
The address depends on the dynamic linker and probably isn't resolved
when initializing is needed.
I've fixed it by declaring these vars as static, which will result
in many instances (one for every includage of properties.h).
Without diving too deep in your properties code, was it intended
to have only one prop_std_line_width_data in the whole dia address
space? If so, my patch will break it and I'll provide another
sollution, like initializing at first usage.
Hans
diff -u -r --exclude=*.obj from-cvs/dia/app/app_procs.c my-gtk/dia/app/app_procs.c
--- from-cvs/dia/app/app_procs.cTue Feb 29 21:45:50 2000
+++ my-gtk/dia/app/app_procs.c Wed Mar 01 22:36:08 2000
@@ -60,6 +60,7 @@
#include "dia_dirs.h"
#include "render_eps.h"
#include "render_svg.h"
+#include "sheet.h"
#if defined(HAVE_LIBPNG) defined(HAVE_LIBART)
extern DiaExportFilter png_export_filter;
diff -u -r --exclude=*.obj from-cvs/dia/app/export_png.c my-gtk/dia/app/export_png.c
--- from-cvs/dia/app/export_png.c Mon Feb 28 15:54:06 2000
+++ my-gtk/dia/app/export_png.c Wed Mar 01 23:53:28 2000
@@ -30,6 +30,7 @@
#include "filter.h"
#include "render_libart.h"
#include "display.h"
+#include "message.h"
/* the dots per centimetre to render this diagram at */
/* this matches the setting `100%' setting in dia. */
diff -u -r --exclude=*.obj from-cvs/dia/app/linewidth_area.c
my-gtk/dia/app/linewidth_area.c
--- from-cvs/dia/app/linewidth_area.c Fri Feb 18 21:17:58 2000
+++ my-gtk/dia/app/linewidth_area.c Wed Mar 01 22:43:56 2000
@@ -19,6 +19,11 @@
#include "attributes.h"
#include "intl.h"
+#if !defined(rint)
+# include math.h
+# define rint(x) floor ((x) + 0.5)
+#endif
+
#define BASE_WIDTH 0.05
#define PIXELS_BETWEEN_LINES 6
#define NUMLINES 5
diff -u -r --exclude=*.obj from-cvs/dia/app/preferences.c my-gtk/dia/app/preferences.c
--- from-cvs/dia/app/preferences.c Tue Feb 29 21:45:54 2000
+++ my-gtk/dia/app/preferences.cWed Mar 01 22:37:26 2000
@@ -38,6 +38,7 @@
#include "widgets.h"
#include "diagram.h"
#include "preferences.h"
+#include "message.h"
struct DiaPreferences prefs;
diff -u -r --exclude=*.obj from-cvs/dia/app/render_svg.c my-gtk/dia/app/render_svg.c
--- from-cvs/dia/app/render_svg.c Tue Feb 29 21:45:54 2000
+++ my-gtk/dia/app/render_svg.c Wed Mar 01 22:48:58 2000
@@ -22,6 +22,7 @@
#include time.h
#include math.h
#include unistd.h
+#include malloc.h
#include entities.h
diff -u -r --exclude=*.obj from-cvs/dia/lib/properties.c my-gtk/dia/lib/properties.c
--- from-cvs/dia/lib/properties.c Sat Feb 26 12:10:04 2000
+++ my-gtk/dia/lib/properties.c Wed Mar 01 23:11:10 2000
@@ -21,6 +21,7 @@
#include gtk/gtk.h
#include string.h
+#include stdlib.h
#include "geometry.h"
#include "arrows.h"
@@ -1094,7 +1095,7 @@
}
/* --- */
-
+#if 0 /* HB: see properties header */
/* standard property extra data members */
PropNumData prop_std_line_width_data = { 0.0, 10.0, 0.01 };
PropNumData prop_std_text_height_data = { 0.1, 10.0, 0.1 };
@@ -1104,3 +1105,4 @@
{ N_("Right"), ALIGN_RIGHT },
{ NULL, 0 }
};
+#endif
diff -u -r --exclude=*.obj from-cvs/dia/lib/properties.h my-gtk/dia/lib/properties.h
--- from-cvs/dia/lib/properties.h Sat Feb 26 12:10:04 2000
+++ my-gtk/dia/lib/properties.h Wed Mar 01 23:16:48 2000
@@ -27,6 +27,8 @@
#include stddef.h
#endif
+#include "intl.h"
+
#include "geometry.h"
#include "render.h"
#include "arrows.h"
@@ -305,8 +307,24 @@
* of a number of objects should be greater, making setting properties on
* groups better. */
+#if 0
+/* HB: exporting these vars, does mean the pointers used below have to
+ * be calculated at run-time by the loader, because they will exist
+ * only once in the process space. Indeed it causes compile
+ * time errors with MSVC (initialzer not a constant).
+ */
DIAVAR PropNumData prop_std_line_width_data, prop_std_text_height_data;
DIAVAR PropEnumData prop_std_text_align_data[];
+#else
+static PropNumData prop_std_line_width_data = { 0.0, 10.0, 0.01 };
+static PropNumData prop_std_text_height_data = { 0.1, 10.0, 0.1 };
+static PropEnumData prop_std_text_align_data[] = {
+ { N_("Left"), ALIGN_LEFT },
+ { N_("Center"), ALIGN_CENTER },
+ { N_("Right"), ALIGN_RIGHT },
+ { NULL, 0 }
+};
+#endif
#define PROP_STD_LINE_WIDTH \
{ "line_width", PROP_TYPE_REAL, PROP_FLAG_VISIBLE, \
Hans "at" Breuer "dot" Org ---
Tell me what you need, and I'll tell you how to
get along without it.-- Dilbert
Re: Dia for Win32
At 23:52 29.02.00 -0600, David Thompson wrote: The link on the Dia developer page to Dia for Win32 is dead. Could someone tell me where Dia for Win32 can be downloaded from ? http://hans.breuer.org/dia/ This may not work for some browser/connections. The longer form http://www.hans.breuer.org/dia/ should do it ... If you are able to get the binary running without installing the Gimp for Windows (i.e., just using the supplied gtk+ binaries), let me know. When I tried, it just croaked and I don't have the disk space to get cygwin and compile it under NT... CygWin wouldn't help here, because my port is based on M$VC. Could you tell me more about the problem? Hans Hans "at" Breuer "dot" Org --- Tell me what you need, and I'll tell you how to get along without it.-- Dilbert
Re: Dia for Win32
At 23:52 29.02.00 -0600, David Thompson wrote: The link on the Dia developer page to Dia for Win32 is dead. Could someone tell me where Dia for Win32 can be downloaded from ? http://hans.breuer.org/dia/ This may not work for some browser/connections. The longer form http://www.hans.breuer.org/dia/ should do it ... If you are able to get the binary running without installing the Gimp for Windows (i.e., just using the supplied gtk+ binaries), let me know. When I tried, it just croaked and I don't have the disk space to get cygwin and compile it under NT... CygWin wouldn't help here, because my port is based on M$VC. Could you tell me more about the problem? Hans Hans "at" Breuer "dot" Org --- Tell me what you need, and I'll tell you how to get along without it.-- Dilbert
Re: Dia for Win32
Could you tell me more about the problem? I downloaded dia-bin-2000-02-05.zip and gtk+-bin-2000-02-05.zip from your site. I put the gtk+ dlls in C:\winnt\system32\ (I also tried putting them in the same directory as dia.exe later). When I run dia, it generates an application exception error. Exception: access violation (0xc005) address 0x7800533b I also tried downloading the Gimp for Win32 development library zip files that had dlls in them (dated 2215) and that produced the same error. I am running NT 4.0sp5 under VMware (I use the Linux version, but my professor wants Dia available in the undergrad lab which is all NT). If you want, I can try booting into NT directly. Thanks, David
RE: Dia for Win32
David Thompson wrote: I downloaded dia-bin-2000-02-05.zip and gtk+-bin-2000-02-05.zip from your site. I put the gtk+ dlls in C:\winnt\system32\ (I also tried putting them in the same directory as dia.exe later). When I run dia, it generates an application exception error. Exception: access violation (0xc005) address 0x7800533b I am also using these downloads on NT4.0sp5 (native, not under VMware). For me, I get an assertion failure on startup: Gdk-CRITICAL **: file gdkdraw.c: line 122: assertion 'drawable != NULL' failed. Plus, of course, an access violation about reading memory at address 0x. Let me know if there's anything I can try to help debug this; I would be using Dia immediately if I could get it to run under NT4.0. Hope this helps, Zach Frey
Dia for Win32
Hi there, The link on the Dia developer page to Dia for Win32 is dead. Could someone tell me where Dia for Win32 can be downloaded from ? Thanks, Zsolt [EMAIL PROTECTED]
Re: Dia for Win32
The link on the Dia developer page to Dia for Win32 is dead. Could someone tell me where Dia for Win32 can be downloaded from ? http://hans.breuer.org/dia/ If you are able to get the binary running without installing the Gimp for Windows (i.e., just using the supplied gtk+ binaries), let me know. When I tried, it just croaked and I don't have the disk space to get cygwin and compile it under NT... David
Re: DIA for Win32
At 08:20 07.02.00 +0800, James Henstridge wrote:
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.
AFAIK if it is used, it's rather useless, because the same effect
- exporting a function - can be done by the *.def file.
This isn't needed on *ix because everything is exported by default.
Variables like color_black are a special case, at least on Win32.
They not only need to be *exported* but *imported* too.
Otherwise they wont get initialized correctly, in DIA case all
colors remain zero - simply drawing black on black ...
BTW: they same code is needed in libgimp, but there it is
called GIMPVAR.
Hans
Hans "at" Breuer "dot" Org ---
Tell me what you need, and I'll tell you how to
get along without it.-- Dilbert
Re: DIA for WIN32
At 20:25 06.02.00 -0500, 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 the mail of James does include almost everything about to say on this (Thanks James!), here's my personal answer: Sorry, but I'm earning my money with writing closed source Windoze NT image analysis software. If anyone is interested, there's a link on my website. And our customers *expect* simple data transfer to M$ Word and Excel, to state only one thing. 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 I could comment on this, too. But instead would like to quote Zach Beane (arguing for pretendedly ugly Gimp icons) Also, they are Standard Icons. I know that doesn't mean much in the GUI-of-the-week world of X, but they are they are Macintosh toolbox icons [...] ...but I'm sure you get the point. you too? Why not bundling our forces to strike against the Imperium, instead of continue whining? Hans Hans "at" Breuer "dot" Org --- Tell me what you need, and I'll tell you how to get along without it.-- Dilbert
Re: DIA for WIN32
Hans Breuer wrote: Why not bundling our forces to strike against the Imperium, instead of continue whining? I agree. I'm not a DIA developer; just commenting as one who is following the development of a great program. I think porting of good open source projects to Windows could have two positive impacts: 1. People will see where these projects originate, and will realize that it is more effecient to write cross-platform applications starting from the UNIX side. Because of the availability of toolkits like GTK, it's much easier to port UNIX apps to Windows than vise versa. 2. If you think that the open source movement is having a big impact in the software world, just imagine the impact it will have if it spreads to the Windows and Mac platforms. With a market more than 10 times larger (at the current time), it would be much easier to earn money from open source projects by selling service, support, and customization. Microsoft will be very squeezed if, some day, much of the software on their own platform is free and the highest cost item is the OS itself. -Dave
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: 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: 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
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
