Re: Win32 plugin build
At 22:11 01.06.01 -0700, Lennon Day-Reynolds wrote: >Okay, ladies and germs, here's my dilemma: > >My plug-in, which is compiling wonderfully on Linux, is supposed to be >demonstrated on a Windows box in a little less than 48 hours. I'm in the >process of pulling a fresh copy of the latest CVS version onto an NT >machine to try building from scratch, but I'm somewhat (understandably, >I think) nervous about manually tweaking everything to get it working. >Oh yeah, and I don't have Visual Studio -- just the Cygwin tools. > >Any bright ideas, aside from wiping Windows off the demo machine? > If you haven't had luck compiling it yet, you may want to send me a copy of the sources. If there isn't any terribly done with system dependencies or Gtk internals I may be able to compile it and send you a working binary within some hours, though I'm not constantly online. 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
Beziergon Bounding Box Broken and other Bugs
Hi Cyrille, recent CVS doesn't allow to draw Beziergons anymore - most of the time. There are only some few angles for the control lines which give a visible outline. Bezier lines are drwan more often but there are modes which make them dissappear as well, e.g. a straight vertical line or a sharp rectangular edge build with a three point bezier. I've taken a short look into your restructering of the bbox code but would prefer not to dive too deep into it. But one problem obvious from playing around with beziers is, that points with zero length control lines are totally ignored for the bounding box calculation. Regards, 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: Beziergon Bounding Box Broken and other Bugs
At 13:30 14.06.01 +0200, Cyrille Chepelov wrote:
>Le mer, jun 13, 2001, à 01:00:40 +0200, Hans Breuer a écrit:
>
>> recent CVS doesn't allow to draw Beziergons anymore - most of
>> the time. There are only some few angles for the control lines
>> which give a visible outline.
>>
>> Bezier lines are drwan more often but there are modes which
>> make them dissappear as well, e.g. a straight vertical line
>> or a sharp rectangular edge build with a three point bezier.
>>
>
>Hans,
>
> this is a bit embarrassing ; this happens precisely the day when I
>have real work to do :-(. I've tried in a hurry to reproduce the problem,
>but failed (here are a few attempts).
>
> On what platform does the problem happen ? Win32 ?
Yepp, my favourite :)
>I hope it's not a
>porting bug (especially -lm issues). Without going as far as diving into the
>code, perhaps you can spot places where I used non-portable math code in
>lib/boundingbox.c? Can you also send me problematic samples (in .dia form) ?
>
the following patch fixes - or better works around the problem.
Doing a normalization of (0,0) vector gave the interesting behaviour.
What do you think the 'portable' result of 0/0 should be ?
Hans
--- from-cvs/dia/lib/geometry.h Sat May 26 09:37:26 2001
+++ my-gtk/dia/lib/geometry.h Thu Jun 14 18:55:42 2001
@@ -138,8 +138,14 @@
len = sqrt(p->x*p->x + p->y*p->y);
- p->x /= len;
- p->y /= len;
+ if (len > 0.0) {
+p->x /= len;
+p->y /= len;
+ } else {
+p->x = 0.0;
+p->y = 0.0;
+ }
+
}
#endif
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: Font structure needs name change
At 14:32 07.07.01 -0500, Lars Clausen wrote:
>
>To get the list of fonts from X for FreeType, I need to include Xlib.h, but
>that defines a Font struct. I will need to rename the Font structure to
>DiaFont. Stand by for mass renaming. I wish I had a refactoring editor:)
>
Or even better C++:
namespace X {
#include "XLib.h"
}
Why can't you use the XListFonts (and XFreeFonts) surrogates defined by the
gtk-1.3-win32-production branch which work on string lists too and are
rather portable ? They are called gdk_font_list_new/gdk_font_list_free and
can be implemented as simple wrappers on X.
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: python plugin and object properties
At 17:01 30.06.01 +0200, Michael Maluck wrote:
>Hi all,
>
>tried to get some object properties of "UML Class" objects in the
>python dia console.
>
>i comiled dia 0.88.1 from source with the --with-python option.
>dia.active_display().diagram.layers[0].properties.get("obj_pos") returns
>always None.
Doesn't it give a runtime-error AttributeError: properties ?
dia.active_display().diagram.layers[0].objects[0].properties['obj_pos'].value
works:
[Though there are probably Dia objects, which do not support the property
api yet]
>The has_key method says that the property exists. It is also listed
>in keys().
The main problem is, that the layer object has no properties, because it
isn't a DiaObject as one may expect. The property api is only supported by
most objects within the diagram, like
dia.active_display().diagram.layers[0].objects[0].type
>i doesn't matter which property i want to get. it doesn't work for all.
>any ideas?
>
There is probably no senseful way to write Dia Extensions in Python without
being able to read and understand the C-Sources
>are there any docs for the python plugin?
NAFAIK. I've attached a small interface description extracted from the
C-Source, no real documentation :(
>is it possible to use the dia api not only in the python dia console?
>
Yes. There are two examples how to write an export filter in Python, but
again I don't think it would be much fun to write one, without being able
to debug or 'investigate the limitations in' the Python-Plugin as well.
The Plugin will probably remain such limited as it is, at least until it
(and first the Dia Object System) is converted to Gtk+2.0 especially the
GObject system, because the current access does not allow to ref-count the
objects, to easily back-propagate property changes, etc. ...
Hans
dia.active_display()DiaDisplay
dia.diagrams() DiaDiagram[n]
dia.get_object_type(string) DiaObjectType 'name_of_object_type
dia.load(string)'filename
dia.register_export(string,string,object) 'name,extension,DiaRenderer
dia.register_callback(string,string,function)
'description,menupath,callback(DiaDiagramData,int)
dia.update_all()
DiaArrow
type int
width double
lengthdouble
DiaBezPoint
p1DiaPoint
p2DiaPoint
p3DiaPoint
DiaColor
red double
green double
blue double
DiaConnectionPoint
connected DiaObject[n]
objectDiaObject
pos double[n] '(x,y)
DiaDiagram
raise_layer()
lower_layer()
add_layer(string[,int]) DiaLayer'name, optional poisition
set_active_layer(DiaLayer)
delete_layer(DiaLayer)
select(DiaObject)
is_selected(DiaObject)int
unselect(DiaObject)
remove_all_selected()
update_extents()
get_sorted_selected() DiaObject[n]
get_sorted_selected_remove()
add_update(double,double,double,double)
add_update_all()
flush()
find_clicked_object((double,double),double) DiaObject '(x,y), distance
find_closest_handle(double,double)DiaHandle
find_closest_connectionpoint(double,double) (DiaHandle,DiaObject) 'x,y
group_selected()
ungroup_selected()
save([string])int 'optional filename
DiaDiagramData
extents DiaRectangle
bg_color DiaColor
paper
grid.widthdouble[2]
grid.visible int[2]
hguides double[n]
vguides double[n]
layersDiaLayer[n]
active_layer DiaLayer
selected DiaObject[n]
DiaDisplay
diagram DiaDiagram
origindouble[2] 'todo? DiaPoint
visible double[4] 'todo? DiaRectangle
zoom_factor double
add_update_all()
flush()
set_origion(double,double)
zoom(double,double,double)'pt.x, pt.x, factor
resize_canvas(int,int)'width, height
close()
set_title(string)
scroll(double,double) 'delta x,y
scroll_up()
scroll_down()
scroll_left()
scroll_right()
DiaError
write(object) 'writes obeject as string
DiaExportFilter
DiaFont
name string
DiaHandle
connect_type int
connected_to DiaConnectionPoint
idint
pos double[2] '(x,y)
type int
DiaImage
width int
heightint
rgb_data char[widht*height*3]
mask_data char[widht*height]
filename string
DiaLayer
extents double[4] '(top,left,bottom,right)
name string
objects DiaObject[n]
visible int
destroy()
object_index()int
add_object(DiaObject[,int]) 'object, optional index 'at'
remove_object(DiaObject)
find_objects_in_rectangle(double,double,double,doub
StdProp overhaul: broken plug-ins
+ * plug-ins/python/**/*: I gave up converting this; I can't
+ compile --with-python (problems with object.h defined both by us
+ and by Python). I'll gladly help whomever cares to fix it !
+ (or, fix it myself if someone tells me how to compile it).
+
Hi Cyrille,
while making the Python plug-in compile again I stumbled over
two issues with the new property access, which would be nice
if you could address them.
1) it would be nice if one could get a property refernce directly
from the object, like:
/* Return a reference to objects property with 'name' or NULL */
Property *object_find_prop (Object *obj, const char* name);
2) IMO the property->type should become integral again, to allow
for a switch statement, instead of string comparsions. See patch.
BTW: 'eml' still doesn't compile.
Thanks in advance,
Hans
diff --exclude-from=c:\util\tool\diff.ign -u -r
from-cvs/dia/plug-ins/python/pydia-display.c
my-gtk/dia/plug-ins/python/pydia-display.c
--- from-cvs/dia/plug-ins/python/pydia-display.cFri Mar 23 20:03:54 2001
+++ my-gtk/dia/plug-ins/python/pydia-display.c Sun Jul 08 14:19:34 2001
@@ -220,7 +220,8 @@
"zoom_factor");
else if (!strcmp(attr, "diagram"))
return PyDiaDiagram_New(self->disp->diagram);
-else if (!strcmp(attr, "origo") || !strcmp(attr, "origion"))
+/* FIXME: shouldn't it have only one name */
+else if (!strcmp(attr, "origo") || !strcmp(attr, "origion") ||
!strcmp(attr, "origin"))
return Py_BuildValue("(dd)", self->disp->origo.x, self->disp->origo.y);
else if (!strcmp(attr, "zoom_factor"))
return PyFloat_FromDouble(self->disp->zoom_factor);
diff --exclude-from=c:\util\tool\diff.ign -u -r
from-cvs/dia/plug-ins/python/pydia-font.c
my-gtk/dia/plug-ins/python/pydia-font.c
--- from-cvs/dia/plug-ins/python/pydia-font.c Fri Mar 23 20:03:56 2001
+++ my-gtk/dia/plug-ins/python/pydia-font.c Wed Aug 15 12:48:34 2001
@@ -27,7 +27,7 @@
/*
* New
*/
-PyObject* PyDiaFont_New (Font* font)
+PyObject* PyDiaFont_New (DiaFont* font)
{
PyDiaFont *self;
diff --exclude-from=c:\util\tool\diff.ign -u -r
from-cvs/dia/plug-ins/python/pydia-font.h
my-gtk/dia/plug-ins/python/pydia-font.h
--- from-cvs/dia/plug-ins/python/pydia-font.h Sat Aug 11 13:47:14 2001
+++ my-gtk/dia/plug-ins/python/pydia-font.h Wed Aug 15 12:47:16 2001
@@ -11,6 +11,6 @@
extern PyTypeObject PyDiaFont_Type;
-PyObject* PyDiaFont_New (Font* font);
+PyObject* PyDiaFont_New (DiaFont* font);
#endif
\ No newline at end of file
diff --exclude-from=c:\util\tool\diff.ign -u -r
from-cvs/dia/plug-ins/python/pydia-properties.c
my-gtk/dia/plug-ins/python/pydia-properties.c
--- from-cvs/dia/plug-ins/python/pydia-properties.c Fri May 25 18:35:42 2001
+++ my-gtk/dia/plug-ins/python/pydia-properties.c Wed Aug 15 17:52:42 2001
@@ -98,17 +98,11 @@
return NULL;
if (self->object->ops->get_props != NULL) {
-Property prop;
-
-prop.name = PyString_AsString(key);
-prop.type = PROP_TYPE_INVALID;
-if (prop.name) {
- /* Get the first property with name */
- self->object->ops->get_props(self->object, &prop, 1);
- if (prop.type != PROP_TYPE_INVALID)
-val = PyDiaProperty_New(&prop); /* makes a copy, too. */
- prop_free(&prop);
-}
+Property *p;
+char* name = PyString_AsString(key);
+p = object_find_prop (self->object, name);
+if (p && p->type != PROP_TYPE_INVALID)
+ val = PyDiaProperty_New(p); /* makes a copy */
}
if (val == NULL) {
@@ -132,22 +126,12 @@
ok = 0; /* is this too drastic? */
if (self->object->ops->get_props != NULL) {
-Property prop;
-PropDescription *desc;
-
-prop.name = PyString_AsString(key);
+Property *p;
+char *name;
-desc = self->object->ops->describe_props(self->object);
-desc = prop_desc_list_find_prop (desc, prop.name);
-
-prop.type = desc->type;
+name = PyString_AsString(key);
-if (prop.name) {
- /* Get the first property with name */
- self->object->ops->get_props(self->object, &prop, 1);
- ok = (prop.type != PROP_TYPE_INVALID);
- prop_free(&prop);
-}
+ok = (NULL != object_find_prop (self->object, name));
}
return PyInt_FromLong(ok);
@@ -205,23 +189,14 @@
return NULL;
}
else {
-Property prop;
-PropDescription *desc;
+Property *p;
+char *name;
-prop.name = PyString_AsString(key);
+name = PyString_AsString(key);
+p = object_find_prop (self->object, name);
-desc = self->object->ops->describe_props(self->object);
-desc = prop_desc_list_find_prop (desc, prop.name);
-
-prop.type = desc->type;
-
-if (prop.name) {
- /* Get the first property with name */
- self->object->ops->get_props(self->object, &prop, 1);
- if (prop.type != PROP_TYPE_INVALID)
-v = PyDiaProperty_New(&prop); /* makes a copy, too. */
- prop_free(&prop);
-}
+
Re: StdProp overhaul: broken plug-ins
At 22:02 15.08.01 +0200, Cyrille Chepelov wrote:
>Hans, it's good to see you're back !
>
Don't expect too much, IMO Gtk2 has still higher priority.
Even all you factorizing would be simplier there :)
>> [...]
>>
>> 1) it would be nice if one could get a property refernce directly
>> from the object, like:
>>
>> /* Return a reference to objects property with 'name' or NULL */
>
>You already can do something like
> prop = make_new_prop(PROP_TYPE_FOO, "name", 0);
>
>Yes, this is a bit disturbing ; Property, rather than being an object's
>property like its name implies, is just a cookie holding information of
>various types (a bit like OLE2/COM's VARIANT).
Obviously a Property class can be a VARIANT, which allows all the
nice abstract handling for operations which aren't interested in
the type ...
>So, an object never "has"
>Properties.
It obviously has specific properties like 'width', 'height', etc. which
are in fact properties of single objects. (They are assumed to vary
between different objects). And the next thing one wants to do with
the properties (from language bindings is to read and change them.
You definetly need to have the concrete type than to don't do
obj.width = obj.width + obj.name
Ooops. Type error ...
>It can be applied a _set_ of properties, and then it can choose to
>either process the properties itself, or delegate to the library routines
>(giving a set of PropOffsets, for instance). Hmmm. OK, you know that
>already.
>
Yeah. And I haven't continued on the Dia Python plug-in because there
are simply missing (or to complicated) things to do with the current
api. You may want to take a look into GObject, which addresses them
all as far as i know.
Say ref counting, change notification, ...
>I'll comment on your usage of object_find_prop() in the patch.
>
>> 2) IMO the property->type should become integral again, to allow
>> for a switch statement, instead of string comparsions. See patch.
>
>No. switch statements are the disease which turned lib/properties.c into
>unmaintainability. If you need to make fast comparisons, use the type_quark
>field. PropertyType is a string, because it allows an object library to
>define its own property type, perhaps of very specific purpose, and have the
>StdProp core handle it, and never need to recompile the StdProp core for
>that. And with constant initialisers (the old properties code had provisions
>for library-custom property types, but that would have meant a variable
>PROP_TYPE_FOO value, which is obviously a problem).
>
But any de-marshalling needs them. Or one needs to provide member
functions to common types, see GObject::g_value_transform
>If you really need a switch statement (I'm not going to force you to shuffle
>around your code !), you can define a private integral property type, and
>store the mapping between strings and your type in a GHash you initialise at
>load time. Or better, mapping between quark and private type (should be
>pretty fast).
>
Ok you're right with the switch statement, I'll probably need to
understand Quarks some time ...
>>
>> BTW: 'eml' still doesn't compile.
>
>Yes, and that is intentional. I'm not touching this module even with 3 metre
>pole, until at least his author is identified (remember that COPYING file ?)
>
>I've sent a message to the single address I could scrounge from the commit
>log (*not even* the ChangeLog !), about month ago, and am still waiting for
>an answer. EML is out of objects/Makefile.am.
>
ok, I'll disable it in the win32 build too.
>> else if (!strcmp(attr, "diagram"))
>> return PyDiaDiagram_New(self->disp->diagram);
>> -else if (!strcmp(attr, "origo") || !strcmp(attr, "origion"))
>> +/* FIXME: shouldn't it have only one name */
>> +else if (!strcmp(attr, "origo") || !strcmp(attr, "origion") ||
>> !strcmp(attr, "origin"))
>
>why do we have these many names, where some obviously look like typos ? Now
>the plugin interface version has changed...
>
I'm only maintaining it. Could probably be fixed.
>> -
>> -prop.name = PyString_AsString(key);
>> -prop.type = PROP_TYPE_INVALID;
>> -if (prop.name) {
>> - /* Get the first property with name */
>> - self->object->ops->get_props(self->object, &prop, 1);
>> - if (prop.type != PROP_TYPE_INVALID)
>> -val = PyDiaProperty_New(&prop); /* makes a copy, too. */
>> - prop_free(&prop);
>> -}
>> +Property *p;
>> +char* name = PyString_AsString(key);
>> +p = object_find_prop (self->object, name);
>> +if (p && p->type != PROP_TYPE_INVALID)
>> + val = PyDiaProperty_New(p); /* makes a copy */
>
>Isn't this better ?:
> GPtrArray *props = g_ptr_array_new();
> char *name = PyString_AsString(key);
> Property *prop = make_new_property(name,type /* find the type ! */,0)
> g_ptr_array_add(props,prop);
>
> self->object->ops->get_props(self->object,props);
>
> if (prop->experience & PXP_HAS_GFO) {
> /* then it's valid */
> }
>
>Mmmm... I thin
Re: Dia ChangeLog report for Thu Aug 16 07:23:01 2001 (UTC)
At 15:41 16.08.01 +0200, Cyrille Chepelov wrote: >Le jeu, aoû 16, 2001, à 09:24:05 +0200, Dia ChangeLog Daemon a écrit: > >> +* objects/sadt/annotation.c : disable TEMPORARY_EVENT_TEST for >> +msvc instead of cleaning missing includes > >Which includes are missing ? I'd like to make sure that event delivery works >also for Win32. I'll depend on it when I finally convert UML Class to >StdProp. > Ok. Will fix compilation for the test case than ... 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: StdProp overhaul: broken plug-ins
At 00:47 16.08.01 +0200, Cyrille Chepelov wrote: >Le jeu, aoû 16, 2001, à 12:00:47 +0200, Hans Breuer a écrit: > >[advertisement for GObject] > It was not really advertisement. For your reading pleasure you may want to replace every occurence of GObject with GtkObject (without the GUI dependence) and read it again :-) >I'm a bit wary of GObject Given the effort which will be required to >convert to GObject anyway, shouldn't we just convert (rewrite) in C++ ? Or >maybe in Python. > This isn't the point. IMO the DiaObject systems is already quite similar to GObject. And we are using Gtk Objects all over the place. In contrast to simply switch to a really object orientated language we would get all the benefits of a well thought object system. There is neither reference counting (=object lifetime management) nor a signal system built-in in C++. Python has at least the first, but IMHO the core should still consist of a compile language not only for performance reasons. >Oh well. As I've already said, I'm not developing for an unstable platform >(no, I mean GTK2 ). So I'll look at GObject, but when it's about to >be mainstream, not sooner And until this happens re-invent everything which it would give you for free ? From my experience it is even useful to look into something which tries to address the same problem, even if it never becomes mainstream. >(but this "let's make Pythonic objects in C" >thing sure looks strange, and perhaps a bit awkward !) > I'm not concerned about it looking strange, but if it doesn't allow fundamental functionallity by design, it's not that promising to further work on it. (No I don't mean Python, but part of the current Dia Object system, respectively it's Python 'wrapability'.) >Whoops, of course not. I mean, list of a single element (I think I used a >lowercase "s" letter, though). This routine will have to be renamed, I >don't want to cause any confusion on this particular topic. Mmmm... Is >prop_list_of_single(prop) clear enough ? > The common semantic at least with COM is attaching an 's'. A Property or many Properties (ok bad example :-). Either a collection with 0..n objects (a list) or a single instance of an object. [...] >No. It's not for future unknown additions, it's because the name (type) and >flags parameters are used by make_new_property(), which will synthetise a >property descriptor. Some plug-ins will want to make synthetic visible >properties, some won't. Hmmm. In this function, we can get rid of it, and >instanciate the property through its pdesc->ops->new_prop(pdesc->ops,pdtpp_true) Ah, here are the IMO most questionable additions to the Dia namespace of your whole restructuring. While make_new_property only is somewhat odd (not counting the fact, that I still don't think a copy is needed in my use case). pdtpp_true i a thing which should not only be more literal, but IMHO even than needs some explanation/documentation. prop_desc_to_prop_true ? Not that speaking to me :) >class method rather than rebuild a dynamic propdesc. > >If you're working on this before I remove the flags parameter, please do, >just pass a 0 as the last argument of make_new_property() in >object_prop_from_name_type(). > >> >You'll have noted that object_prop_by_name is almost object_find_prop(). If >> >it can't find a matching property name in the object's description, it'll >> >return NULL. If it can, it will (as you assumed) ask the object to fill the >> >property. >> Why mot simply return the (ref counted) pointer of the object. > >What object ? If it's the first argument of object_prop_by_name(), I don't >see the point > I see the Property itself as an object, or in 'C' notation: 'Gimme the pointer'. The lifetime of an DiaObjects Properties is managed by the DiaObject. As long as it survives the Property will, too. Or is it i.e. looseing it's bounding box somewhere on the way ? With a real object orientated approach even ints are objects. Given the following hierachy DiaObject Property[bounding box] UMLObject Property[function list] Property[function] Property[name] Property[parameter list] Property[paramater] ... If you give me a reference to the parameter property and than delete the whole DiaObject I still would have a valid property object, though it's not connected to an object anymore ... >> Ok there is currently no ref counting, but the Python plug-in >> will crash on deleting whole Dia objects under it's feet >> anyway. But the object reference is needed. > >You already have it, since you pass it to object_prop_b
libxml 1-2-3
Hi Cyrille, your recent libxml changes introduce a problem (which is probably long-time built-in in libxml). Why does a single library need two names ? In dia_xml.c you are referencing the libxml headers as but there are many places which just #include "tree.h". Really fixing it isn't allowed, because AFAIK at least gnome install libxml (1.8.x) headers under http://mail.gnome.org/mailman/listinfo/dia-list
Re: dia Win32 0.89 installer
At 07:16 13.09.01 +0200, Cyrille Chepelov wrote: >Le jeu, sep 13, 2001, à 07:27:33 +0200, Steffen Macke a écrit: > >> You can get it from >> http://dia-installer.sourceforge.net/dia-0.89-setup.exe >> I'll make the release on sourceforge just before 0.89 is >> released officially. > > >This build uses which tree ? (that is, CVS of when ?) > >From about five minutes ago, just commited the require changes for the win32 build. BUT BEWARE: (This is what I original wrote to Steffen, only translated) A new version is available at http://hans.breuer.org/dia/dia-0.89.htm but it's almost untested. I also seriously doubt if the recent changes really justify a new version. (Much restructuring, all new bugs ?, no essential new features ...) I should have added: It is not yet decided if it will become an official win32 release, but wasn't this said between the lines above ... 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: dia Win32 0.89 installer
At 17:53 13.09.01 +0200, Cyrille Chepelov wrote: >Le jeu, sep 13, 2001, à 04:20:29 +0200, Cyrille Chepelov a écrit: > >me again. > > * I've reloaded a file saved with dia 0.88."2". It was in French, with >diacritics. dia-0.89-test2 for Win32 silently corrupted all diacritics, >turning them into what looks to be "double-UTF-8" encoding >(that is, we now have in the dia file something which looks like the output >of `echo "élémentaire" | iconv -f latin1 -t utf-8 | iconv -f latin1 -t utf-8') > AFAIK it's all your code :) I haven't changed anything in this area but GTK_TALKS_UTF8_WE_DONT is defined and it's using libxml2 ... >The *nix version of dia complains when it finds a file with no encoding, >that it makes a possibily wrong assumption. It would be good if the Win32 >version did something the same. I can't build on Windows, so basically, >whenever I whine about a Win32-specific problem, I'm a random user stuck >with a problematic binary. > See my previous mail. But as always: patches accepted :-) 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: Dia ChangeLog report for Fri Sep 14 07:23:01 2001 (UTC)
At 09:24 14.09.01 +0200, Dia ChangeLog Daemon wrote:
>Snapshots available at http://www.crans.org/~chepelov/dia/snapshots
>
>*** Recent ChangeLog entries:
>
>--- ChangeLog.previous Sun Sep 9 09:23:18 2001
>+++ dia-cvs-snapshot/ChangeLog Fri Sep 14 09:23:16 2001
>@@ -1,3 +1,39 @@
>+2001-09-13 Cyrille Chepelov <[EMAIL PROTECTED]>
>+
>+ * lib/charconv.c: (get_local_charset): at least please try to not
>+ silently change the logic, while avoiding crashes.
>+
Logic ? I can't see the logic :)
here's the IMHO questionable function:
int get_local_charset(char **charset)
{
static char *this_charset = NULL;
static int local_is_utf8 = 0;
if (this_charset) {
*charset = this_charset;
return local_is_utf8;
}
#ifdef HAVE_UNICODE
local_is_utf8 = unicode_get_charset(charset);
#else
*charset = NULL;
#endif
// ...
below then, if UNICODE isn't defined it is complained about
not having an encoding (not a miracle, because it is set
to NULL explicit.)
Is it supposed to almost silently break if HAVE_UNICODE isn't
defined ?
Or may there g_get_charset () be used, which knows about
charset determination on win32 ? (Mine returns 'CP1252')
On the other hand this gives the nice ability to complain for every
older file _AND_ finally not being able to ready _any_ of it ?
Suggestions beside avoiding 'Dia 0.89 rcx' on win32 ?
Thanks,
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
more utf8 #ifdefs
to fix some more issues related to utf8 (GTK_TALKS_UTF8_WE_DONT)
and our previously broken xml files (due to missing encoding)
I've produced the following patch.
to 'try to not silently change the logic, while avoiding crashes'
and because all those char conversion logic is a litte out of my
usual buisiness here are my suggested changes for review.
[
It fixes #59982 and should reduce all 'missing encoding'
complains to only files which may have the problem
(=highest bit used)
]
Ok to apply ?
Hans
diff --exclude-from=c:\util\tool\diff.ign -u -r
from-cvs/dia/app/render_gdk.c my-gtk/dia/app/render_gdk.c
--- from-cvs/dia/app/render_gdk.c Sat Aug 11 13:46:50 2001
+++ my-gtk/dia/app/render_gdk.c Fri Sep 14 18:44:24 2001
@@ -938,7 +938,15 @@
ddisplay_transform_coords(ddisp, pos->x, pos->y,
&x, &y);
+# if defined (GTK_TALKS_UTF8_WE_DONT)
+ {
+utfchar *utfbuf = charconv_local8_to_utf8(text);
+iwidth = gdk_string_width(renderer->gdk_font, utfbuf);
+g_free(utfbuf);
+ }
+# else
iwidth = gdk_string_width(renderer->gdk_font, text);
+# endif
switch (alignment) {
case ALIGN_LEFT:
@@ -954,9 +962,19 @@
color_convert(color, &gdkcolor);
gdk_gc_set_foreground(gc, &gdkcolor);
+# if defined (GTK_TALKS_UTF8_WE_DONT)
+ {
+utfchar *utfbuf = charconv_local8_to_utf8(text);
+gdk_draw_string(renderer->pixmap,
+ renderer->gdk_font, gc,
+ x,y, utfbuf);
+g_free(utfbuf);
+ }
+# else
gdk_draw_string(renderer->pixmap,
renderer->gdk_font, gc,
x,y, text);
+# endif
#endif
}
@@ -985,7 +1003,15 @@
#ifdef HAVE_FREETYPE
iwidth = freetype_load_string(text, renderer->freetype_font, length);
#else
+# if defined (GTK_TALKS_UTF8_WE_DONT)
+ {
+utfchar *utfbuf = charconv_local8_to_utf8(text);
+iwidth = gdk_string_width(renderer->gdk_font, utfbuf);
+g_free(utfbuf);
+ }
+# else
iwidth = gdk_text_width(renderer->gdk_font, text, length);
+# endif
#endif
return ddisplay_untransform_length(renderer->ddisp, (real) iwidth);
diff --exclude-from=c:\util\tool\diff.ign -u -r from-cvs/dia/lib/charconv.c
my-gtk/dia/lib/charconv.c
--- from-cvs/dia/lib/charconv.c Fri Sep 14 13:11:56 2001
+++ my-gtk/dia/lib/charconv.c Fri Sep 14 18:53:48 2001
@@ -73,7 +73,11 @@
#ifdef HAVE_UNICODE
local_is_utf8 = unicode_get_charset(charset);
#else
+# if GLIB_CHECK_VERSION(1,3,0)
+ local_is_utf8 = g_get_charset (charset);
+# else
*charset = NULL;
+# endif
#endif
if (local_is_utf8) {
this_charset = *charset;
@@ -255,13 +259,21 @@
extern utfchar *
charconv_local8_to_utf8(const gchar *local)
{
+#if GLIB_CHECK_VERSION(1,3,1)
+ return g_locale_to_utf8 (local, -1, NULL, NULL, NULL);
+#else
return g_strdup(local);
+#endif
}
extern gchar *
charconv_utf8_to_local8(const utfchar *utf)
{
- return g_strdup(utf);
+#if GLIB_CHECK_VERSION(1,3,1)
+ return g_locale_from_utf8 (utf, -1, NULL, NULL, NULL);
+#else
+ return g_strdup(local);
+#endif
}
diff --exclude-from=c:\util\tool\diff.ign -u -r from-cvs/dia/lib/dia_xml.c
my-gtk/dia/lib/dia_xml.c
--- from-cvs/dia/lib/dia_xml.c Sun Sep 09 16:45:36 2001
+++ my-gtk/dia/lib/dia_xml.cFri Sep 14 17:19:22 2001
@@ -77,6 +77,7 @@
int len;
gchar *tmp,*res;
int uf;
+ gboolean well_formed_utf8;
static char magic_xml[] =
{0x3c,0x3f,0x78,0x6d,0x6c,0x00}; /* " 0 && well_formed_utf8);
+ if (well_formed_utf8) {
+gzclose(zf); /* this file is utf-8 compatible */
+return filename;
+ }
+
if (0 != strcmp(default_enc,"UTF-8")) {
message_warning(_("The file %s has no encoding specification;\n"
"assuming it is encoded in %s"),filename,default_enc);
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: Printing
At 14:07 04.10.01 -0400, Mike Bruckheimer wrote: >I just found DIA (Windows) and am quite excited by its speed and >functionality but I have been unable to successfully print. my >(network) printer appears in the print dialog but when I select [OK} to >print, i receive a dialog box stating: Could not run command >'\\BUFIS1\is36_4mv' which is the path to the printer que. I am running >Win NT 4 SP 5. I believe the print server is at a similar level of NT. > And your server is running Samba 2.2, right ? (Infact this is just guessing, but I noticed the same behaviour at work recently and have no idea what else could have broken the code, which still appears to work with our older server ...) BTW: printing to file and trnafering to the printer outside of Dia should still work. Any other clues ? 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: Diagram tree window - patch (Was: Re: xml-i18n and a new feature)
At 07:24 31.10.01 +0100, Cyrille Chepelov wrote: >Le mer, oct 31, 2001, à 01:18:43 +0100, Jose A. Ortega Ruiz a écrit: > >> the attached patch (to be applied to the current CVS tree) implements >> the diagram window idea i mentioned a few days ago: > >unfortunately, it lacks diagtree.h, which makes it uncompilable. > > [...] > > * I see nothing which could prevent that code from running on >Win32, but I'm no Win32-gtk expert. Hans ? > Me neither. Stuff only using the Gtk+ api is amost always running quite flawlessly under win32. Problems here are arising mostly because of compiler differences. (Or because of missing prototypes - which is made a fatal bug via glibconfig.h - as it was here :) > * this stuff looks really cool, I'm impatient to try it out. > Me too :-) Already compiled and slightly modified (I did not like the View menu in the toolbox, so 'Diagram Tree' is moved to the file menu (similar to what The Gimp does with 'Dialogs'). Also applied small portatbility fixes (g_snprintf), include the correct headers etc. Nice feature, I'm ready to apply it to cvs if no-one complains ... 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: Diagram tree window - patch (Was: Re: xml-i18n and a new feature)
At 14:25 01.11.01 +0100, Jose A. Ortega Ruiz wrote: >Cyrille Chepelov <[EMAIL PROTECTED]> writes: > >> >> Thanks a lot, Jose. This thing rocks. >> >> -- Cyrille >> > >you're welcome. it's a pleasure contributing to such a great project! >if you miss any feature in this tree thing (e.g. pop up menus), please >tell me about it :-) > Just commited your patch. Please check if I've accidently broken anything while fixing some glitches :) Some features and improvements which came to my mind: - It would be nice to have some ordering options for the diagram tree, i.e. sort by type, sort by name, ... - to improve performance and decrease resource consumption when not using the diagram tree it maybe sensible to make the notification messages work (= do nothing) when diagram_tree() returns NULL and and only create the tree on users demand - allow multiple object selection from the tree and within the diagram ? - I'm not sure if the gdk_window_raise should really be done when clicking around in the tree, instead the tree window could keep the focus - ... Or maybe wait for some more users input ... Thanks, 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: Diagram tree window
At 02:00 02.11.01 +0100, Jose A. Ortega Ruiz wrote: >Hans Breuer <[EMAIL PROTECTED]> writes: > >> Just commited your patch. Please check if I've accidently broken anything >> while fixing some glitches :) >> > >i've updated my local copy, but the patch is not there yet... i guess >the update relies on some cron job? (i'm using >:pserver:[EMAIL PROTECTED]:/cvs/gnome ) > I think so. AFAIK gnome cvs is mirrored to four servers under the name anoncvs.gnome.org. A least one of them had _very_ noticeable delay in the time I worked with them ... >> Some features and improvements which came to my mind: >> - It would be nice to have some ordering options for the diagram tree, >> i.e. sort by type, sort by name, ... > >i agree... i'll work on this... maybe we could have a tab for the >diagram tree configuration options in the properties dialog (i would >add the initial size of the window too)... > An own page for sounds reasonable to me. Though for window sizes it would probably be better to impement some kind of generic SessionInfo handling like The Gimp does. There are more top level windows which would benefit from 'remember where placed last time'. >> - allow multiple object selection from the tree and within the >> diagram ? > >i can do that, but do you think it is really useful? when i want to >mark multiple objects, i think i'd always do that on the diagram >window... > I recently have worked on diagrams too huge to have readable class names when showing all. There some other selection ui would have been rather useful ... >> - I'm not sure if the gdk_window_raise should really be done when >> clicking around in the tree, instead the tree window could keep the >> focus > >well, i had the idea of this tree thing because i usually have a lot >of open diagrams, and wanted to quickly locate any of them and bring >it to the foreground, but i agree that loosing the focus can be >annoying... we can fix this in (at least) two ways: either call >gdk_window_raise both for the diagram window and, afterwards, for the >diagram tree window (and you have the diagram on the foreground and >don't miss the focus), or raise the selected diagram only if you >double click on its node (and, btw, double clicking an object node >could pop up its properties window): what do you think? > The latter option(s) are more appealing to me (don't mess around with focus until explicit being told to do so). As you already sayed there are more operations which are nice to have while operating with the tree. What about a context menu for tree nodes which offers: - Locate (i.e. select) - Properties - Delete ? - ... (more to come) 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: Dia + OO
At 02:39 02.11.01 +, Alan Horkan wrote: > >You are probably already aware of libwmf its used by a bunch of other >Gnome Office Apps. >(but just in case you aren't ill post this link anyway) > >http://www.wvware.com/libwmf.html > Last time I looked it did only implement Import. Not that useful when writing of wmf is required, isn't it ? > >On Fri, 2 Nov 2001, Young, Robert wrote: > >> What about WMF import? Surely OO can import this? Dia can export this under >> windoze and the plugin just needs a bit owf work (Hans as done the bulk of >> the work) to get it working under non windoze platforms (according to the >> comment in dia/plug-ins/wmf/wmf_gdi.cpp). >> >> If you want to get this working, take a look - the code looks quite >> readable. > Thanks :-) 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: Dia + OO
At 09:34 02.11.01 -0800, Robert Campbell wrote: >I'm going to reply to my own post before it even shows up on the list. I just opened a MS Word document that contains embedded EPS with OpenOffice, and the image was visible. So the problem may be with the EPS output that Dia is producing. Maybe the library that Dia is using for this purpose has an option for creating previews that could be turned on. If not, the interested party ought to put a request into that library's maintainers. Dia is not using a library to produce the eps, but does it from scratch. (app/render_eps.c). If I would have to implement a preview image for the eps files I would probably try to delay it until Dia uses Gtk2, because there are some nice functions to get on the bits of a drawable. Producing the output would involve the Gdk Renderer already available in the Dia sources. Another workaround for the original problem may be to simply use Dia's png exporter ... 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: diagram tree update
At 00:47 19.11.01 +0100, Jose A. Ortega Ruiz wrote: > [...] > >- a single mouse click on a diagram or object node does not raise > the corresponding diagram window nor selects the object. a double > click is needed. > What about single click -> select in tree and diagram double click -> additional raise ? > [...] > >caveats: > >- the pop-up menus are created using raw gtk (no #ifdef GNOME > stuff). i have not added GNOME-style menus because gtk menus work > fine for both GNOME and gtk, and the pop-up menus are so simple that > i thought GNOME menus were not necessary: am i mistaken? > Fine with me, not using Gnome under win32 :-) >- the menus are implemented in diagram_tree_menu.c instead of putting > the code in menus.c... maybe i'm missing some i18n handling of the > new menus: i have not fully understood the stuff in menus.c: any > help/comments greatly appreciated! :-) > Maybe someone else could comment ? >todo: > >- allow multiple selection of objects/diagram nodes > >- a menu/preferences option to hide objects of some type (for > instance, when displaying UML use cases, i'm not interested in > seeing the connectors...) > >- delete command in pop-ups??? > >- handle the tree window size using sessions > Maybe on the way: store diagram tree size from the actual tree window size, not only as numerical parameters in the prefs dialog ? >- > >as always, any comment will be highly appreciated. > BTW: just applied your patch. Maybe you could shorten your next ChangeLog entries a bit (or maybe not :-) Thanks, 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: new diagram tree patch
Hi Jose,
sorry for not answering earlier. I've applied your patch to
my local tree, but it was the missing ChangeLog entry, what
stopped me from commiting to cvs.
Also there was some probably minor glitch with :
patching file `app/diagram_tree_menu_callbacks.c'
Hunk #2 FAILED at 74.
misordered hunks! output would be garbled
Hunk #3 FAILED at 24.
Hunk #4 FAILED at 55.
Hunk #5 FAILED at 69.
4 out of 5 hunks FAILED -- saving rejects to
app/diagram_tree_menu_callbacks.c.rej
I think I have corrected it by hand, but you should
look into it after it's commited.
Hans
At 00:08 11.12.01 +0100, Jose A. Ortega Ruiz wrote:
>
>hi,
>
>i'm attaching yet another patch adding new functionality to the
>diagram tree thing, namely:
>
>- single click on a object tree node now selects the object in the
> diagram. double click, in addition, raises its window.
>
>- new preference ("Remember last size" in the preferences tab) to
> remember the last tree window size as the default
> (poor-man's-session-management :-).
>
>- new popup menu commands:
>* Hide this type: makes invisible (in the tree) all objects of
> this type (useful to avoid clutter by uninteresting objects
> such as connectors, and the like).
>* Show object type. hidden types are listed in this
> submenu. click on any of the to bring it back.
>
>- preferences toggle ("Remember hidden types") to save the list of
> hidden types as a preference.
>
>that's it. i think the functionality of the tree window is now quite
>complete, but for the absence of multiple object selection (i'll work
>on it in the next days). nevertheless i'm open to any suggestion on
>your side :-)
>
>IMPLEMENTATION NOTE: i've tweaked preferences.c to make PREF_STRING
>work. the functionality was almost there, and i've simply put the code
>related to PREF_STRING out of the '#ifdef PREF_CHOICE' guard, changed
>expressions of the form *(char *) to *(char **) (since a string
>preference is stored as a char *), and make it save the string value
>in the diarc file using double quotes, to make the parser happy. it
>works for me (i use it to store the list of hidden types), but maybe
>the preferences.c author would like to have a look at it?
>
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: Printing in Dia 0.88.1 win32
At 14:01 27.12.01 +0100, Gerbrand van Dieijen wrote: >Hello, > >when I print in Dia 0.88 for Win32 under MS Windows 98 to a networkprinter >(don't know if the same applies to local printers), the printjob isn't >actually started after a new printjob in another windows program is started. > I also noticed this but never found a workaround, despite ... To: [EMAIL PROTECTED], <[EMAIL PROTECTED]> From: Hans Breuer <[EMAIL PROTECTED]> Subject: Re: Printing / DIA /Win32 At 15:11 25.02.01 -0500, Vincent Kelly wrote: >Is it possible to print in the Win32 version of DIA. >I use Windows ME with a Lexmark Z11 printer and am not familiar with the >Print UI in DIA. Are you familiar with programming the Printer API on win32? Than you could take the source of plug-ins/wmf/wmf.cpp and parts of app/paginate_psprint.c and implement native windoze GDI printing. This is finally done. Current cvs includes the code to interlink the wmf plug-in with the win32 print api. It is currently only tested with FinePrints PDF-Factory on win98 but I'm confident that it's working with almost all windoze printer drivers (not limited to postscript printers like the previous version) ... >Also, under Windows 2000 I can't print at all, when I use print, a I get the >error "Could not run command '\\SERVER\HP LaseserJet 8100 Series PS'. > There probably was an error message written to the console window, which may contain the real reason. >Does anyone else have this problem, is there a workaround (like a different >'command' in the printer textfield) and does the new cvs problem still have >this problem (I could not yet compile it, still have to try it)? > You may want to give the all new Dia-0.89 version a try (or wait some days until I've tested it a little more). Anyway it is available at: http://hans.breuer.org/dia/dia-0.89.htm 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: Struggling with CVS version of dia
At 17:25 04.01.02 +, [EMAIL PROTECTED] wrote: >> What is the current state of dia on Win32, BTW. Is >> there any person using it regularily? >> >> Martin > > [...] >If you compile a CVS version for Windows, I would >appreciate if you placed it somewhere that I could >download it from. > The version 'hidden' announced three days ago _is_ recent cvs, and it even prints via GDI ... 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: working progress for UTF-8
At 07:15 18.01.02 +0100, Cyrille Chepelov wrote: >Le jeu, jan 17, 2002, à 09:52:38 +, Michael Meeks a écrit: > > >Michael, > >> It would most likely be more productive to help with the Gnome 2.0 >> port, there was a therad about it last week; rather than re-write the >> i18n work [ not using utf-8: wchar !? ] under the Gnome 1.4 platform, > >The GNOME 2.0 port can't really be done until the UTF-8 audit is complete. >We still have too many 8-bit-isms everywhere. Completing that will benefit >all three platforms (as explained in my reply to Akira). > IMHO the UTF-8 audit can more easily be done while porting to GTK 2.0. Doing it in it's own branch would allow to remove almost all of those #ifdef mess, because GTK+ 2.0 requires (GUI-)strings to be in UTF-8 and offers many of the tools to work with them (g_locale_to_utf8, g_convert(_with_iconv), g_utf8_*) Look at glib/gunicode.h and glib/gconvert.h. Also GTK+ is now official api frozen so most of the arguments against Date: Thu, 12 Apr 2001 21:10:31 +0200 To: [EMAIL PROTECTED] From: Hans Breuer <[EMAIL PROTECTED]> Subject: Target Gtk+2.0 (was Re: plug-ins/renderer.inc) should now be resolved. If someone with better cvs access than mine could create the branch TARGET_GTK_2_0 I would love to contribute/ apply patches to make Dia GTK+ 2.0 aware. (That is making it work under win32). Regards, 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: dia 0.88-1 export problem?
At 20:33 20.01.02 -, Tariq Rashid wrote: > >dear all, > >i have been having some frustrating problems with dia going a bit unstable >after a while... producing "junk" files... > It would be nice if you could provide information about the platform your Dia is running on. First I concluded from your mailer that it is probably win32, but than ... >for example the file attched opens fine... ... none of my local Dia versions does open the attached file without tweakink. (It enters an endless loop in app/grid.c:grid_draw()). I've tracked it down to the paper.scaling value being "0" in your file which leads to some division by zero misbehaviour done on the paper.width and paper.height ... see app/load_save.c:diagram_data_load around line 360. Further calculations are done with bogus values for either scaling or width and height or even both, so the results are almost unpredictable ... >but copying and pasting out of it >into a new dia window fails. > >more to the point, export to eps "appears" to work... but using imagemagicks >convert : > convert a.eps b.png >fails for the eps file created... something about no image delegate... [...] The workaround would be to manually correct the scaling value in your file. But at least I have not yet found where it actually got the invalid value in the first place so it will probably break again 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: dia gdk warning
At 08:35 24.01.02 -, Adrian Stacey wrote: >Hans, > >Re: ReleaseDC failed: I have had the same problem and it is coupled with the >text not appearing in dialog boxes under Dia. It is not simply a matter of >using Dia until it windows runs out of GDI memory: Dia becomes unuseable as >a result of the bug, which is a big shame. Version 0.86 of Dia does NOT have >this problem, later versions (0.88, 0.89) do, so I wonder a bit what has >changed between 0.86 to 0.88 which might have created the issue? > As tried to make obvious by my mail it is a GTK issue. IIRC Dia 0.89 shouldn't have this problem anymore (if used with the gtk+ libs from my site http://hans.breuer.org/dia/dia-0.89.htm ) But beware other problems (like crashing when exporting to PNG) in this preview release ... >Thanks for your work on Dia; I really appreciate it and would *love* to run >a later version, but at the moment it is not possible due to this problem. > If you installed Dia with the setup program there may as well be issues which I don't know of ... 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: Dia ChangeLog report for Tue Feb 12 08:23:01 2002 (UTC)
At 09:25 12.02.02 +0100, Dia ChangeLog Daemon wrote: >+++ dia-cvs-snapshot/ChangeLog Tue Feb 12 09:23:14 2002 >@@ -1,3 +1,30 @@ >+2002-02-12 Akira TAGOH <[EMAIL PROTECTED]> >+ >+ * lib/text.c (text_draw): fixed XIM position, when menubar is shown for >+ diagram window. >+ UHM. Your recent change introduce an ../app/display.h dependency to libdia which IMO is plain wrong. Please don't add circular dependencies! Without really understanding GdkIC/GdkICAttr issues I guess the cleanest way to solve the problem would be to create a new _InteractiveRenderOps member function which delivers the required information and lives in ./app On the other hand it's just a temporary solution given that some day dia may use Pango based text rendering anyway. Regards, 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: copying dig to MS word
At 19:00 19.02.02 -, sartajsingh wrote: > >how can I copy the UML diag to MS word. >HOw do you export your diagrams somewhere else in a document ? What about reading documentation ? Try File/Export and find a file format which M$ Word is capable to read in. Like WMF, WPG, PNG, etc. Before you suggest this extension: Copy & Paste of vector graphics between different applications is by no means a simple task to implement - even if it shouldn't be done cross-platform ... 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: copying dig to MS word
At 21:48 19.02.02 +0100, Matthieu Sozeau wrote: >You can currently export to PNG or PostScript (PS). Support for other file >types in M$ Word is only for M$ File Types (Excel...). But if you want >your Diagrams to be exported into MS Word, well just ask them! You are obviously talking about M$ Word for Linux, aren't you ? To make the list from my previous mail on this subject longer: WMF, WPG, HPGL (PLT), EPS (PS), PNG, CGM, DXF are supported to be imported AFAIK (some of them need explicit activation during the setup of Word though) ... 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(3): copying dig to MS word
At 10:32 20.02.02 -, sartajsingh wrote: > > >hate to tell you I am using windows. >Does the same apply ?? Ever asked yourself who has made Dia available for win32 ? Hans >sartaj > >On Wed, 20 Feb 2002 Hans Breuer wrote : [...] 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
g_get_home_dir() [was Re: Re(3): copying dig to MS word]
At 23:38 20.02.02 +, Alan Horkan wrote: > > [...] > >BTW where in the code is the home dir set? i think Application Data is >the appropriate place to put the .diarc (and on multiuser windows >%userprofile%/Application Data). I'd like to _try_ and solve the problem >so that it "just works", unless of course someone else has followed up on the >other similar suggestions made recently... > IMO using some strange Micros~1 definition is _not_ the right way to go. Problems like this should probably used on the toolkit level. It probably will vanish, when g_get_home_dir() from glib-1.3 (than 2.0) is used. It returns the homedir; if not available the tmpdir; if not available "C:\". And all the people not reading any FAQ but starting complains have probably deserved to get the C: root dir filled with junk and they probably won't even notice :-) Regards, 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: gtk-2.0
At 16:12 11.03.02 -0600, Lars Clausen wrote: > >So GTK-2.0 came out over the weekend[1]. I've spent some time today trying >to get Dia to compile with it. There's a bunch of smaller things, but now >I'm hitting the big stuff. Major changes would include using ATK instead >of XIM and changes to redrawing. I'm currentl;y stuck at changing >GdkColorContexts into Gdk_RGB_* stuff. My notes on changes are attached >below. > You apparently haven't noticed, that there already is a TARGET_GTK_2_0 branch in cvs. It does compile and work quite nice, but has fallen a little behind with respect to full UTF-8 conversion (and there are no plans to do direct FT2 rendering (The Text rendering IMHO should be converted to straight Pango and when limitations in Pango arise it first should be tried to get the Pango API extended instead of reinventing the Font/Text wheel once more ...) >The main question now is: What do we do about Gtk 2.0 in Dia? Do we make >a branch for the conversion? Do we use a HAVE_GTK_2_0 macro (as I have >done so far)? Do we ignore it till it stabilizes a bit? > There was some off-list discussion to first do a stable Dia release based on Gtk+-1.2 (early Gtk+1.3 on windoze) before creating a 'stable' branch and switching cvs HEAD to Gtk+2.0. Though I'm not sure how much time people (including me) are willing or able to contribute to one or both projects at the moment. One major goal of mine is to _not_ introduce anymore #ifdef mess to any Dia branch (at least not for the GTK+2.0 branch). In fact if there really is the need for different implementations of the same functionality (like rendering with differnt Font/Text Systems) it should be tried to first build an abstract interface where both (all) implementation can live with and after that keep the implementations as separate as possible. [Printing code comes to my mind as an example as well.] Maybe the different 'plugable' implementations can even be run-time selectable ... Regards, Hans > >[1] And they still didn't improve the file dialog. *grumpf* > But finally it is there. And the file selector very high on the todo list (see recent posts to gtk-devel-list). > > [..., see TARGET_GTK_2_0 branch] > >Overall: Our redrawing mechanisms may have to be reconsidered. > Not really. Only the default double buffering of Gtk+2.0 needed to be switched off to avoid nasty flickering quad buffering. 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: gtk-2.0
At 16:26 13.03.02 -0600, Lars Clausen wrote: >On Wed, 13 Mar 2002, Hans Breuer wrote: [...] >> You apparently haven't noticed, that there already is a TARGET_GTK_2_0 >> branch in cvs. [...] > >Didn't think of that -- that was started quite a while ago, wasn't it? Has >it been kept up to date wrt other stuff than UTF-8? I.e. changes in the >properties system etc? I'm in the middle of a major change to the vtable >system that should definitely go into both branches. > >From its ChangeLog: [TARGET_GTK2_0 : branched from HEAD with -D 2002-01-17] I 'ported' some of the stuff after that date (not noticing any changes to the properties system) but my time to spend on it was less than expected ... >>> [...] >> There was some off-list discussion to first do a stable Dia release >> based on Gtk+-1.2 (early Gtk+1.3 on windoze) before creating a >> 'stable' branch and switching cvs HEAD to Gtk+2.0. > >That sounds like the way to go. The code is a mess right now and needs to >stabilize before we start an even greater mess:) > >> Though I'm not sure how much time people (including me) are willing >> or able to contribute to one or both projects at the moment. > >Once we switch to Gtk+2.0 for our head, we probably wouldn't want to >do more than bugfixes on the 1.2 branch. > Obviously. But at the moment there appears to happen more work on new features based on Gtk+1.2 code than stabelizing for a new release. [IMHO - as noted before - even the utf-8 conversion should have been done - or at least would have been much simpler - based on GLib 2.0 services] >> One major goal of mine is to _not_ introduce anymore #ifdef mess >> to any Dia branch (at least not for the GTK+2.0 branch). >> In fact if there really is the need for different implementations >> of the same functionality (like rendering with differnt Font/Text >> Systems) it should be tried to first build an abstract interface >> where both (all) implementation can live with and after that >> keep the implementations as separate as possible. >> [Printing code comes to my mind as an example as well.] > >Indeed. I am thinking the GTK+2.0 branch should not include the freetype >stuff (but that is fairly easy to remove). Pango looks like a good thing >(though I don't know how it prints yet -- any programs does printing with >Gtk+2.0 yet?). Fonts are already somewhat abstracted, but the abstraction >and implementations aren't completely split yet. > Agreed. This is what I meant by extending the Pango API. Even rendering to a bitmap isn't supported by Pango without introducing a specific backend (pango-ft2). I once (gtk-devel-list: Pango Backend Abstraction, 2001-08-26) tried to get something to avoid this into Pango, but with some more convincing arguments provide by some working Dia code it probably would be simpler :-) >Notice that Pango rendering is a completely different thing than Gtk+1.2 >rendering. In particular, it renders a full line at a time in order to do >some of the high-level transformations that south-east asian languages >have. So we will need to rewrite a lot of stuff anyway. > Yupp. The whole dia/lib/font.c much of lib/text.c some of app/render_[gdk|libart].c. But at least on win32 it should be quite simple to get printing work with it because of pango_win32_render() which takes a Device Context either used for display or printing. Don't know about X11 equivalents (probably they are not there) ... >>>Overall: Our redrawing mechanisms may have to be reconsidered. >>> >> Not really. Only the default double buffering of Gtk+2.0 needed >> to be switched off to avoid nasty flickering quad buffering. > >Well, wouldn't we want to make use of the Gtk+2.0 redrawing instead of >doing it ourselves? > Keeping it the old way took me one call to gtk_widget_set_double_buffered() and the goal was to first get an almost working Dia again. Don't know much more about keeping the own double buffering instead of using gtk+ ones beside not needing to rewrite anything ... 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: Dia's user interface
At 16:43 21.04.02 -0500, Lars Clausen wrote: > >After reading http://www106.pair.com/rhp/free-software-ui.html> about >user interfaces in open-source software, I would like to hear if anybody >on the list knows something about user interfaces (more than just from >having used a bunch). If there are any, could you point out the worst >problems that Dia has in its interface? I'd like to turn some attention to >that as we work towards a 1.0 release. > The first place to look at should probably be: http://developer.gnome.org/projects/gup/articles/why_care/ It even has two screen shots of dia dialogs to show bad UI design, one of which I've modified before to increase useability :) Cause the useability people choose to use Dia as an example they would probably love to give more detailed hints how to improve Dia's useability :-) Though solving common toolkit problems - like tab ordering in dialogs - or shortcut changes should probably be delayed _after_ porting to Gtk+2.0 which will give us other useability improvements, 'inverted' No and Yes ordering and the like (almost) for free anyway ... Regards, 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: Zoom combo box?
At 20:00 23.04.02 -0500, Lars Clausen wrote: > >Now that we're talking about the bottom of the display, do anybody have >strong feelings about the zoom combobox? It's not currently as functional >as it could be (Sodipodi gets it right), but it could also just be replaced >with a label. Or a button with a pop-up menu like the Zoom menu. It >certainly needs fixing, one way or the other. > I'm all for removing the zoom combo, in fact it already isn't compiled in Dia for win32 versions ... Instead providing some useful information like upper left pos and size of the currently selected object would be nice. 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: Dia ChangeLog report for Sat Apr 27 07:23:01 2002 (UTC)
Hi Lars, At 10:35 29.04.02 -0500, Lars Clausen wrote: >On Mon, 29 Apr 2002, Pierre Pronchery wrote: >> On Sat, Apr 27, 2002 at 09:24:25AM +0200, Dia ChangeLog Daemon wrote: >> *** Recent ChangeLog entries: >> >> +* app/sheets_dialog_callbacks.c : #ifdef HAVE_UNISTD_H and >> +#ifdef HAVE_UTIME_H. Otherwise #include and >> +name space corrections for utime() and utim_buf #ifdef >> +G_OS_WIN32 >> >> of course I replaced with , then thought all would follow well >> in the best world ever. the next file failed, for another reason: >> This one was my bad:) Could someone compiling on Linux add the appropriate configure patch to get HAVE_UTIME_H and/or HAVE_SYS_UTIME_H ? Thanks, 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: Dia plugins and C++
At 11:40 30.04.02 +0200, Pierre Pronchery wrote:
>question: can I use both C and C++ in a Dia plugin?
>else, can I use C++, or do I have to use C?
>
There already is one Dia plug-in compiles as C++ (wmf).
The only real C++ feature used/needed there is namespaces
to avoid clashes between Dia's and Windoze namespace
pollutions :)
Such thing should be possible with any decent GNU compiler
cause interfacing between modules in both languages are
a fundamental part of the C++ specification. Obviously
the interface part needs to restrict to "C" then. [The
C++ specification does not include an ABI specification.
It's compiler specific.]
The wmf plug-in is somewhat dirty with respect to the use
of ../render.inc without any extern "C". Though it works
fine because the interchanged function pointer are
compatible.
If you experience problems in the link step from differnt
name mangling an
extern "C"
PluginInitResult
dia_plugin_init(PluginInfo *info)
{
/* ... */
}
should do the trick.
Regards,
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: Review of Keybindings [Re: Dia's user interface]
At 12:33 03.05.02 -0500, Lars Clausen wrote: > [...] > >You know, I just noticed that you can have a tabbing widget with the tabs >to the left. It's not quite a tree, but with the reorganization we talked >about earlier, it would probably be nicer, and it should be easy to change >into a tree if so desired. I believe the tree widget is getting an >overhaul in Gtk2.0, so that change may need to wait until then. > Since Gtk+ 2.0 was released on 11th of March it should possiblly read: The tree widget already got an advanced replacement, or from the official release announcement: [...] New widgets and widget improvements: [...] * GtkTreeView - a flexible widget for tree and list display, with features such as a model-view split for abstracting data storage from display, the ability to create custom models to accommodate large data sets, versatile display/rendering features, and editable data cells. [...] See: http://mail.gnome.org/archives/gtk-devel-list/2002-March/msg00228.html Regards, 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: 0.90.RC1 available
At 22:50 14.05.02 +0300, Steffen Macke wrote: >> and that it will read old documents. Hans & Steffen will bring out a new >> Windows binary shortly. Please try it out and post any critical bugs both > >The zip files containing Hans' build are available from: >http://hans.breuer.org/dia/dia-0.90-rc1.htm > >Some notes: >* Shape export is not working (Could not confirm this on Linux) > Looks like the namespace is wrong (Outdate plug-in source?) Definitely not outdated plug-in source but maybe different versions of libxml? (win32 version is libxml2-2.4.2) Looking deeper into it shows an #ifdef'ed 0 implementation of xmlNewGlobalNs () in libxml2. So I'm pretty sure it's a cross platform issue. Anyone taking it ? >* I omitted the python plugin. I guess users capable of using python > should be able to install Hans' zip files. Python would double the > size of the installer. If required, I would rather create a separate > installer for the plug-in. Is this ok? Just checked: at least is is neither in my dia zip file nor linked on the RC1 page. If there is a vesion available it is either outdated, created by someone else or still on my harddisk ;-) Please don't even think about including a whole Python in the Dia setup. IMHO the Python plug-in isn't that useful at the moment anyway without being able to read and extend the C sources ... 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: 0.90.RC1 available
At 14:19 15.05.02 -0400, Maiorana, Jason wrote: > >I downloaded the rc1 windows version (im at work, and no have visio >installed) > >Ive noticed that dia is not accepting unicode input from the GUI. (this >may be >a limitation in the version of gtk as built with that version?) > Uhmm. How do you expect 'unicode input' to work ? Using those funny Umlauts printed at least at german keyboards does work finally and Alt-Numeric Keyboard Keys does work as well ... >that got me wondering what the state of utf-8 support is within dia at >the moment. I also noticed that dia's still doing that #string# thing with >the hash marks, and my relatively uninformed post was the only >response i saw to a question about that earlier. > I fail to see the problem with using hashes or anything like that as 'internal' string markers. But there will be a compatibility problem removing them. At 15:18 13.05.02 -0400, Maiorana, Jason wrote: > >>I was wondering why all strings are enclosed with '#' in my dia files >(UML objects). Thanks in >>advance. > >I as well am annoyed by that, to my thinking the default XML >encoding is UTF-8, which is more than enough for internationalization, >which I believe had something to do with it... The default XML encoding from Dia is utf-8 _now_. There where version of Dia and libxml which did simply use the system locale without giving any hint about which it was. And most of the long time user probably would be rather annoyed if Dia could not read its old files anymore ... 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
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
At 23:19 20.05.02 +0200, Mattam wrote: >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. > It's all used in Dia: see lib/plug-ins.c gmodule is part of glib. The other side (here your XSLT library) normally would require some G_MODULE_EXPORT, but if it is libxslt the required functions are already exported. 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: New shapes are wrong zoom
On 08.02.2006 19:42, Paul Kroculick wrote: Hello, I created some custom shapes, and have some drawings using these shapes. When I try to add a new shape to a drawing (by dragging it from a sheet) it is appearing at a zoom factor of 6. > [...] Notice the elem_width and elem_height are 6x the shape size. Does anyone know why this is? Shapes are given a default size when dragging them to the diagram. But they are resiable 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 Dia-list@gnome.org http://mail.gnome.org/mailman/listinfo/dia-list FAQ at http://www.gnome.org/projects/dia/faq.html Main page at http://www.gnome.org/projects/dia
Re: Add FAQ to manual?
On 11.02.2006 10:08, Steffen Macke wrote: Hello All, Adding the FAQ to the Dia manual would make packaging of the Windows installer easier. I think it would make this important information more accessible to the users (through the help menu of the application). Having a link to the website looks more reasonable to me. Usually a FAQ should be a more dynamic document than the users manual. This can be accomplished in two ways: * A script that creates DocBook output from faq.src If it would contain a link to the master document at http://gnome.org/projects/dia/faq.html *and* state it's date of creation this may be an improvement. * Convert faq.src to DocBook and maintain the DocBook FAQ from now on. Please don't do that. 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 Dia-list@gnome.org http://mail.gnome.org/mailman/listinfo/dia-list FAQ at http://www.gnome.org/projects/dia/faq.html Main page at http://www.gnome.org/projects/dia
Re: New shapes are wrong zoom
On 11.02.2006 13:53, Paul Kroculick wrote: I ran my test again using an icon that I didn't create, and the icon appeared at 11x the size that was in the shape file. Also, the elem height and width was different between the two icons. 1. From my experiments, it looks like the dragged icons are not appearing with a fixed magnification level (i.e. not always 6x, or 11x, etc). 2. From my experiments, it looks like the dragged icons are not appearing with a fixed elem height and width (i.e. the shape is resized to be 1x1). There is some more logic involved than only the default size, which is 2x2. But that's intended behavior rather than "wrong zoom". I don't want my users to have to resize. I want the dragged shape to be the same size as in the shape file. Does anyone know how I can do this? Currently there is no concept of fixed size custom shapes that I know of. The code in question is in objects/custom/custom_object.c custom_create(). It may be possible to introduce the concept of preserving size for some elements to fit your needs without breaking a lot of already existing shapes (use cases). I would start looking into http://cvs.gnome.org/viewcvs/*checkout*/dia/doc/custom-shapes?rev=1.7 Maybe what you want can be done by aspectratio="range" which apparently isn't used by any of the included shapes yet. So beware there could be bugs in the implementation ... 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 Dia-list@gnome.org http://mail.gnome.org/mailman/listinfo/dia-list FAQ at http://www.gnome.org/projects/dia/faq.html Main page at http://www.gnome.org/projects/dia
Re: dia.exe and dia-win.exe
On 12.02.2006 06:36, Steffen Macke wrote: Hello All, I would like to ship two flavours of dia with the next Windows installer: * dia.exe which is linked with /subsystem:console, allowing to use see commandline output and error messages * dia-win.exe which should be used by default, linked with /subsystem:windows This is available from the Start Menu, Desktop and Explorer double-click Looks so reasonable that I just have changed the win32 build to do it. dia.exe and diaw.exe both link dia-app.dll which contains almost all of the previous executable. What do you think about this? Remember the many complaints of people about the "DOS" Window that confused them. IMO the sum of complaints is a constant - if not rising like the entropy of the universe ... Hans: Is it ok with you to change app/makefile.msc to build both dia.exe and dia-win.exe? See above. Just creating two parts seemed to be too much of a waste in build time as well as in disk space. The three part solution is already in CVS. 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 Dia-list@gnome.org http://mail.gnome.org/mailman/listinfo/dia-list FAQ at http://www.gnome.org/projects/dia/faq.html Main page at http://www.gnome.org/projects/dia
Re: 0.95-pre1 uploaded
On 12.02.2006 19:01, Lars Clausen wrote: I've just uploaded the first prerelease of version 0.95 to http://download.gnome.org/sources/dia/0.95/. Thanks for doing this. I planned to do it this weekend as well but was dragged away with other interesting stuff. Please go ahead and try it, and hopefully Steffen can put a Win32 version out soon. We're particularly interested in people who can reproduce bugs in 0.94 to see if they can reproduce them in 0.95 too. Note that GTK 2.6 is required to compile. At the same time we're having string freeze, so no changing strings unless absolutely necessary for fixing a bug. Unless there are serious bugs open still, 0.95 will go out next weekend. Although I'm pretty confident in the stability of our current code base I'd like less of a hurry here. Could we please try to follow our own document ( http://cvs.gnome.org/viewcvs/dia/RELEASE-PROCESS?view=markup ) A settle time of at least about two weeks looks much more reasonable to me. Otherwise we could just do a 0.95 *now* followed by a series of brown bag releases ;) Also it appears as if there are no traces of 0.95-pre1 in the ChangeLog nor in the NEWS file. Or am I missing something? Thanks, 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 Dia-list@gnome.org http://mail.gnome.org/mailman/listinfo/dia-list FAQ at http://www.gnome.org/projects/dia/faq.html Main page at http://www.gnome.org/projects/dia
Re: CAIRO build
On 13.02.2006 08:14, Steffen Macke wrote: Hello All, I'll try to get the installer ready as soon as possible. I have a CAIRO plug-in now, but it doesn't contain any new export filters. Maybe somebody (Hans ?) can tell me which #defines make sense to use in order to get a useful CAIRO plug-in. The most important define is HAVE_CAIRO from Dia's config.h The other defines come from cairo-features.h and say what's compiled into cairo. The only useful and available option on win32 with 1-0-2 is CAIRO_HAS_PNG_FUNCTIONS. The PDF and PS surface are not available for win32 without depending on Freetype. And they are not considered useful enough by the cairo people to be officially supported on all platforms for 1.0.x. The CAIRO_HAS_WIN32X_SURFACE is (or better was) my attempt to have a wmf based backend in cairo. But nowadays it is almost discussed to death. See: http://hans.breuer.org/gtk/cairo.html 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 Dia-list@gnome.org http://mail.gnome.org/mailman/listinfo/dia-list FAQ at http://www.gnome.org/projects/dia/faq.html Main page at http://www.gnome.org/projects/dia
Dia (Installer?) Homedir (was : Re: 0.95-pre1 uploaded)
On 14.02.2006 20:29, Alan G Isaac wrote: On Tue, 14 Feb 2006, Luc Cessieux apparently wrote: 1. I have XP but I had not the home in my path. Often on XP %home% expands to %userprofile%, so installers that assume it expands directly to a directory fail. AFAIK the installer does not mess at all with the 'home' dir (Steffen?). The code in GLib looks for both %HOME% as well as %USERPROFILE% - in that order. So did you *see* a concrete problem or did you just suspect one? Thanks, 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 Dia-list@gnome.org http://mail.gnome.org/mailman/listinfo/dia-list FAQ at http://www.gnome.org/projects/dia/faq.html Main page at http://www.gnome.org/projects/dia
Re: 0.95-pre1 uploaded
On 14.02.2006 19:05, Lars Clausen wrote: On Tue, 2006-02-14 at 08:32 +0200, Steffen Macke wrote: Hello All, the Dia for Windows 0.95-pre1 installer is available from http://dia-installer.sourceforge.net Please install the GTK+ Runtime Environment from gimp-win.sourceforge.net first. >You are recommending to install gtk+-2.8.x. Does this mean you have *built* Dia against gtk+-2.8 ? If so this is definitely the end of Dia on win9x as gtk+-2.8 does not run there anymore. [ Dia will compile just fine against gt+-2.6 and *may* run on win9x with that. ALso there will be the option to use gtk+-2.8 with the same compile of Dia as Gtk+ has pretty strong binary compatibility guarantees. ] Not knowing first thing about Win32 installation of GTK stuff, is this new separation an effect of the rewrite, of GTK developments, or what? Although I'm not using any of the Gtk+ run-time environments (is there a difference between the versions from http://gimp-win.sf.net and http://gladewin32.sf.net/ ?) they will allow a Dia users to update Dia's dependencies if there is some bug in there. Bundling Gtk+ with Dia would give a little more simple Dia install but even I have sometimes problems to diagnose issues resulting from an included Gtk+ vs. some new installed Gtk+ version (IIRC the all inclusive Gtk+ from Gnumeric was causing them.) It would be preferable to have just one thing to install, but is it practical/feasible to do that? I tend to disagree, see above. The installer is a complete rewrite, one of the major new features is that the installer will only uninstall the files actually installed (Using uninstall.log). Thank you, Steffen! I hope this makes life easier for Win32 people. Thank you, Steffen! 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 Dia-list@gnome.org http://mail.gnome.org/mailman/listinfo/dia-list FAQ at http://www.gnome.org/projects/dia/faq.html Main page at http://www.gnome.org/projects/dia
Re: 0.95-pre1 uploaded
On 14.02.2006 19:16, Luc Cessieux wrote: Not knowing first thing about Win32 installation of GTK stuff, is this new separation an effect of the rewrite, of GTK developments, or what? It would be preferable to have just one thing to install, but is it practical/feasible to do that? > The installer is a complete rewrite, one of the major new features is > that the installer will only uninstall the files actually installed > (Using uninstall.log). Thank you, Steffen! I hope this makes life easier for Win32 people. I have install the new verison and 2 things. 1. I have XP but I had not the home in my path. Know I make this variable problem it is OK. From my understanding the issue should be gone with a recent enough GLib version. But maybe not. What exactly was the problem you were encountering ? 2. Some shapes don't works. Cybernétique shape for exemple "Aucune feuille de nom Cybernétique ". Sorry but I haven't translete the error message. Sorry I can't translate the error message. So no clue what's going wrong. 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 Dia-list@gnome.org http://mail.gnome.org/mailman/listinfo/dia-list FAQ at http://www.gnome.org/projects/dia/faq.html Main page at http://www.gnome.org/projects/dia
PyDia and Metapost (was Re: 0.95-pre1 uploaded)
On 14.02.2006 19:45, Rob McDonald wrote: Is it possible to run Python plugins (group_props.py) in the Windows version of Dia? Obviously, changing group properties would be very nice. Sure - if you have Python installed as well as a compiled version of Dia's Python bindings (pydia) as well as Gtk+ Python binding (pygtk). The latter is only required to run Dia Python plug-ins with GUI like group_props.py. Other stuff implemented in Python like diasvg(_import).py or codegen.py will work without pygtk. I am using the MetaPost export functionality. When the diagram is imported into LaTeX, the font sizes and positions (vertically) are wrong. I can mostly fix this by scaling the font to be too small in Dia, but that would be much easier with group_props.py (: Fixing the Metapost plug-in would first require to reproduce the issue on a developers machine. One step in that direction would be a complete bug report including all the necessary files and steps description to reproduce and understand the bug : - sample diagram - sample integration in Latex (command line, tex 'container' file) - suggested (manually modified) .mp output of Dia Even better would be a thorough analysis of the transfer function for the text size. It may be just a linear scale, but it also may depend on the diagram size, the TeX environment or something completely different ... Of course, a better font sizing & positioning routine would be even better. Is it practical to hack on the MetaPost export routine without setting up a huge Windows development environment? Being able to compile Dia should be enough: http://dia-installer.sourceforge.net/compiling.php Is there anyone in particular that is the 'keeper' of the MetaPost plugin? Not really. But if the info requested above would be available I may be interested enough to look into it. 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 Dia-list@gnome.org http://mail.gnome.org/mailman/listinfo/dia-list FAQ at http://www.gnome.org/projects/dia/faq.html Main page at http://www.gnome.org/projects/dia
Re: Dia (Installer?) Homedir (was : Re: 0.95-pre1 uploaded)
On 15.02.2006 06:16, Steffen Macke wrote: On Tue, 14 Feb 2006, Hans Breuer apparently wrote: AFAIK the installer does not mess at all with the 'home' dir (Steffen?). If %HOME% is set then the installer will install the XSLT files in %HOME%\.dia. Otherwise they are installed in %USERPROFILE%\.dia Why are the xslt files treated different as the sheets and shapes? They (their default directory) are supposed supposed to live in xslt side by side with shapes, sheets, python, bin, ... Thanks, 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 Dia-list@gnome.org http://mail.gnome.org/mailman/listinfo/dia-list FAQ at http://www.gnome.org/projects/dia/faq.html Main page at http://www.gnome.org/projects/dia
Re: Dia (Installer?) Homedir (was : Re: 0.95-pre1 uploaded)
On 15.02.2006 00:37, Alan G Isaac wrote:
On Tue, 14 Feb 2006, Luc Cessieux apparently wrote:
1. I have XP but I had not the home in my path.
On 14.02.2006 20:29, Alan G Isaac wrote:
Often on XP %home% expands to %userprofile%, so installers
that assume it expands directly to a directory fail.
On Tue, 14 Feb 2006, Hans Breuer apparently wrote:
AFAIK the installer does not mess at all with the 'home' dir (Steffen?).
The code in GLib looks for both %HOME% as well as %USERPROFILE% - in
that order.
So did you see a concrete problem or did you just suspect one?
I suspected this might be what Luc was referring to.
(I could not tell from his post.)
Cheers,
Alan Isaac
PS Again, the problem with looking for %HOME% first is that
it is often defined to be *literally* %USERPROFILE%, so that
a 2nd expansion is necessary. (Odd but true.) If you look
at %HOME% first, you need to check that you have been handed
an actual directory. (E.g., by using os.path.isdir in Python.)
See http://mail.python.org/pipermail/python-list/2005-February/263921.html
This is handled in Glib for quite some time, at least since 2004!
http://cvs.gnome.org/viewcvs/glib/glib/gutils.c?r1=1.148&r2=1.149
/* We check $HOME first for Win32, though it is a last resort for Unix
* where we prefer the results of getpwuid().
*/
g_home_dir = g_strdup (g_getenv ("HOME"));
/* Only believe HOME if it is an absolute path and exists */
if (g_home_dir)
{
if (!(g_path_is_absolute (g_home_dir) &&
g_file_test (g_home_dir, G_FILE_TEST_IS_DIR)))
{
g_free (g_home_dir);
g_home_dir = NULL;
}
}
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
Dia-list@gnome.org
http://mail.gnome.org/mailman/listinfo/dia-list
FAQ at http://www.gnome.org/projects/dia/faq.html
Main page at http://www.gnome.org/projects/dia
Re: UML Diagram & line thickness
On 16.02.2006 15:38, Rob McDonald wrote: How can I change the line thickness in a UML class diagram? I don't see an option in the GUI, and I've poked around the uncompressed *.xml file, and nothing jumps out at me. Try bugzilla ;-) http://bugzilla.gnome.org/show_bug.cgi?id=86238 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 Dia-list@gnome.org http://mail.gnome.org/mailman/listinfo/dia-list FAQ at http://www.gnome.org/projects/dia/faq.html Main page at http://www.gnome.org/projects/dia
Re: Metapost bug with font size... (Was: PyDia and Metapost)
On 16.02.2006 21:42, Rob McDonald wrote: I think I've found the problem. The text size appears to be keyed into the zoom level selected on screen. Zoom to 100%, the exported text looks right. Zoom to 200%, the font gets bigger. Zoom to 400%, everything gets bigger yet. Previously, when I deleted 14 of the objects, I must've selected some intermediate zoom level. Hope this helps, this one ought to be pretty easy to fix. If someone wants an easy way to re-create this bug, the following procedure does it for me... 1) Start Dia. 2) Insert a text label "foo". 3) Set the zoom to 100%. 4) Export a MetaPost file foo1.mp 5) Set the zoom to 200% (or anything else) 6) Export a MetaPost file foo2.mp 7) Compare the two files. diff foo1.mp foo2.mp The font scaling parameter will be different, while it shouldn't be. The exported output should in no way be tied to the current on-screen view (scroll bar position, zoom, grid on/off, etc.) I would appreciate if someone else would confirm this problem, but I'm pretty sure I've seen it in 0.95-pre1 Windows and 0.94 Linux. I tried following through the code where the MetaPost export does a lookup for the font size. It makes a call to pango and that's where I decided to defer to the experts. Just looked into it and it appears to be a really simple solution. Currently set_font() is ignoring the passed in parameter 'height' which has the size independent of the scale. Instead their is a call to dia_font_height() which apparently returns a scaled font size. The latter may be a bug in itself but the whole font handling is a little messy at the moment;) Anyway, as noted before, I'd like to be able to reproduce the complete issue, so could you please file a bug in http://bugzilla.gnome.org and attach the information requested? Also note: the size currently used at zoom 100% is different from the size passed in (0.56 vs 0.80). Would that scale explain the size mismatch you have mentioned earlier? Thanks, 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 Dia-list@gnome.org http://mail.gnome.org/mailman/listinfo/dia-list FAQ at http://www.gnome.org/projects/dia/faq.html Main page at http://www.gnome.org/projects/dia
Re: Dia Windows batch mod
On 21.02.2006 16:55, Rob McDonald wrote: I tried to do a dia foo.dia --filter=mp --export=foo.mp On dia-0.95-pre1 on Windows. Works for me D:\graph\dia-0.95-pre1\bin>dia -e u.mp ..\samples\UML-demo.dia ..\samples\UML-demo.dia --> u.mp or D:\graph\dia-0.95-pre1\bin>dia ..\samples\UML-demo.dia --filter=mp -e u.mp ..\samples\UML-demo.dia --> u.mp It crashed with lots of Pango errors. The first is a GDK_IS_SCREEN assertion. D:\graph\dia-0.95-pre1\bin>dia --version --verbose Dia version 0.95-pre1, compiled 09:34:19 Feb 20 2006 Compiler: MSC 1200 with : threads cairo libart Library versions libpng : 1.2.8 (1.2.8) libxml : 200.60.6 (2.6.6) glib: 2.6.7 (2.6.7) pango : version not available gtk+: 2.6.11 (2.6.11) I was going to batch convert a bunch of files, but it isn't too important. Just figured this may not be something that gets lots of testing. I'm assuming you are using gtk+-2.8 ? Please file a bug conaining more information. Thanks, Hans Thanks, Rob ___ Dia-list mailing list Dia-list@gnome.org http://mail.gnome.org/mailman/listinfo/dia-list FAQ at http://www.gnome.org/projects/dia/faq.html Main page at http://www.gnome.org/projects/dia -- 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 Dia-list@gnome.org http://mail.gnome.org/mailman/listinfo/dia-list FAQ at http://www.gnome.org/projects/dia/faq.html Main page at http://www.gnome.org/projects/dia
Re: More MetaPost text positioning....
On 22.02.2006 15:06, Rob McDonald wrote: Hans, [...] Ok, I got an answer from the good people at comp.text.tex . Would you like me to append this to the previous bug, or open a new one, or what? A bug report with a some summary of this mail is the right thing to do. It does not matter much if you reopen the previous one or open a new one. As the label command (and all its variants) are based on positioning text by the coordinates of its bounding box, it is impossible to get precisely controlled text layout (using that command) in MetaPost. Instead, you have to use the (less powerful) draw command... It is less powerful because draw won't take care of left, right, center positioning for you. You'll have to calculate that yourself... For an example of a list of attributes in a UML diagram. Talking of UML (class?) diagram I had another issue with the matapost plug-in: collision with TeX escapes and special chars marking the access of class members. Could you try Self/dia-core.dia and suggest some solution (maybe escaping as done in pstricks?). Thanks, 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 Dia-list@gnome.org http://mail.gnome.org/mailman/listinfo/dia-list FAQ at http://www.gnome.org/projects/dia/faq.html Main page at http://www.gnome.org/projects/dia
Remove Element width/height from properties dialog again
As already mentioned in http://bugzilla.gnome.org/show_bug.cgi?id=328200 and http://bugzilla.gnome.org/show_bug.cgi?id=331027 I'd like to get rid of the Element width (and height) entries in the standard properties dialogs again. IMHO they are causing more harm than good. Thoughts? Thanks, 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 Dia-list@gnome.org http://mail.gnome.org/mailman/listinfo/dia-list FAQ at http://www.gnome.org/projects/dia/faq.html Main page at http://www.gnome.org/projects/dia
Re: Remove Element width/height from properties dialog again
On 25.02.2006 17:59, Lars Clausen wrote: On Sat, 2006-02-25 at 10:04 +0100, Hans Breuer wrote: As already mentioned in http://bugzilla.gnome.org/show_bug.cgi?id=328200 and http://bugzilla.gnome.org/show_bug.cgi?id=331027 I'd like to get rid of the Element width (and height) entries in the standard properties dialogs again. IMHO they are causing more harm than good. Thoughts? It is very useful for anyone doing modelling of things with a physical size. I have had a use for it already. I know of one problem only they have, namely that if you change the size of the object while the properties dialog is open, it doesn't update. Do you see any other kind of harm in having them? Yes, please follow the give bug links: - the aspect ratio property is not respectzed - the grouped object properties work-around badly breaks cause it is very common to change colors, line widths etc. but much less common to make same size. The latter even does only work if all included objects support arbitrary resizing - which most don't ... Hans -Lars -- 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 Dia-list@gnome.org http://mail.gnome.org/mailman/listinfo/dia-list FAQ at http://www.gnome.org/projects/dia/faq.html Main page at http://www.gnome.org/projects/dia
Re: Graphical question
On 27.02.2006 20:44, Jim Clark wrote: In the charts I am making that I mentioned previously (and 0.95 still has funky Windows font issues) http://bugzilla.gnome.org/show_bug.cgi?id=158549 ? I have decided to color code my boxes, based upon who performs the task listed. This will work well, with one exception. I have a series of boxes about things that are done in conjunction with the customer. The system admin (blue box) performs the task, the customer (red box) works with the sys admin. I wonder if there is some way to have (for instance) diagonal colored stripes going through the box,rather than a monochromatic background, showing that this box is a team effort. No way yet. The only fill style supported is FILLSTYLE_SOLID and almost any plug-in:set_fillstyle message_error(s) on it ... 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 Dia-list@gnome.org http://mail.gnome.org/mailman/listinfo/dia-list FAQ at http://www.gnome.org/projects/dia/faq.html Main page at http://www.gnome.org/projects/dia
Re: dia 0.95 pre release 4 UML class line thickness
On 10.03.2006 12:36, Richard Gipps wrote: Firstly I would like to say what a great improvement version 0.95 is over version 0.94. I have found one issue though and I am not sure whether it is a bug or my lack of experience with Dia. At least a missing feature ... When placing a Class (from the UML library) I do not seem to be able to change the line thickness of the Class symbol. I have no problems changing it for general purpose box symbols from the Assorted library, but the same settings seem to have no effect on the Class symbol. I am using Dia in Windows XP. .. but apparently there is nowone giving it priority for years http://bugzilla.gnome.org/show_bug.cgi?id=86238 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 Dia-list@gnome.org http://mail.gnome.org/mailman/listinfo/dia-list FAQ at http://www.gnome.org/projects/dia/faq.html Main page at http://www.gnome.org/projects/dia
Re: Read only attribute
On 19.03.2006 12:11, Nadim Khemir wrote: Please, please, please, Could the dev team _stop_ doing a backup and allow the modification of "read only" files. I understand that this is a unix file attribute problem and not a Dia problem (that's why I haven't reported it as a bug) but applications must also play the game and not change file names for files that are marked read only. At least display some message and allow the user to cancel. There already is a bug report http://bugzilla.gnome.org/show_bug.cgi?id=133324 I'm not going to fix it before we dependend on a GLib version providing g_access() http://developer.gnome.org/doc/API/2.0/glib/glib-File-Utilities.html#g-access 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 Dia-list@gnome.org http://mail.gnome.org/mailman/listinfo/dia-list FAQ at http://www.gnome.org/projects/dia/faq.html Main page at http://www.gnome.org/projects/dia
Re: Graph::ASCII::Dia
On 19.03.2006 12:00, Nadim Khemir wrote: Hi, I need ASCII diagramming; I couldn't find anything so I decided to wrap one myself :). I 'm writting a perl module to generate ASCII diagrams from Dia. If I would want an ASCII diagram export I'd implement it as a PyDia plug-in like e.g. http://cvs.gnome.org/viewcvs/dia/plug-ins/python/dot.py?rev=1.2&view=log 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 Dia-list@gnome.org http://mail.gnome.org/mailman/listinfo/dia-list FAQ at http://www.gnome.org/projects/dia/faq.html Main page at http://www.gnome.org/projects/dia
Re: Read only attribute
On 19.03.2006 15:08, nadim khemir wrote: Nice to know other got the problem too; it makes me feel less lonely. I hope glib gets what you need soon. Following the link provided would have revealed that GLib already has g_access() since 2.8. An implementation conditionalized on GLIB_CHECK_VERSION(2,8,0) would be accepted. But there are at least two reasons why we don't have a hard dependency on GLib 2.8 yet. For one it would imply gtk+-2.8 and thus cairo and complete dropping of win9x. The other reason are users with outdated Linux distributions ;) [I was going to say the maemo platform but that has gtk+-2.6.x but apparently GLib 2.8.x already.] Hans, do you want small stuff to be discussed in the mailling list first or to be reported as "bug" directly? an example, when moving connector ends, the standard icon is a 4 way arrow which obscures completely the connector making the whole procedure a pain. is that to be discussed here or reported? It depends. More effective than just discussing minor points would be providing patches. And they should definitely go into bugzilla to reduce the probability of being forgotten. An example, having a better cursor (maybe a 'target' less ugly than the one provided by standard X cursors) and a patch to set it at the right places would belong into bugzilla and could be applied quite quickly ;-) 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 Dia-list@gnome.org http://mail.gnome.org/mailman/listinfo/dia-list FAQ at http://www.gnome.org/projects/dia/faq.html Main page at http://www.gnome.org/projects/dia
Re: Prerelease 6 now out
On 21.03.2006 19:55, Lars Clausen wrote: Since Hans fixed a couple nasty bugs, there's now a prerelease 6 available at http://download.gnome.org/sources/dia/0.95/ I'm hoping to turn this into a final release this Sunday, if nothing unforeseen happens. Did you notice http://bugzilla.gnome.org/show_bug.cgi?id=335096 [ Although not completely unforeseen this should probably be addressed before a final release. Although it is dieing in Pango, see http://bugzilla.gnome.org/show_bug.cgi?id=304702 and *may* already be fixed ... ] 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 Dia-list@gnome.org http://mail.gnome.org/mailman/listinfo/dia-list FAQ at http://www.gnome.org/projects/dia/faq.html Main page at http://www.gnome.org/projects/dia
Re: Graph::ASCII::Dia
On 22.03.2006 13:37, Aaron Trevena wrote: On 19/03/06, Hans Breuer <[EMAIL PROTECTED]> wrote: On 19.03.2006 12:00, Nadim Khemir wrote: Hi, I need ASCII diagramming; I couldn't find anything so I decided to wrap one myself :). I 'm writting a perl module to generate ASCII diagrams from Dia. If I would want an ASCII diagram export I'd implement it as a PyDia plug-in like e.g. http://cvs.gnome.org/viewcvs/dia/plug-ins/python/dot.py?rev=1.2&view=log Thats one of the things I find annoying about dia - WTF should I learn python and rewrite cpan modules just to call a script from dia - lame lame lame. Very impressing and motivating words. Feel free to provide Perl bindings to Dia or do what ever you see fit ;) Stuff python, I write perl, I'm not going to faff about with somebody elses choice of language. Not to start a language war - but I never got the reason why people prefer write-only programming languages. Autodia is perl, and I'd write more dia related code if it wasn't a python bigot. And I would write less Dia related code if it would require Perl. Who cares ? 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 Dia-list@gnome.org http://mail.gnome.org/mailman/listinfo/dia-list FAQ at http://www.gnome.org/projects/dia/faq.html Main page at http://www.gnome.org/projects/dia
Dia Language Bindings (was: Re: Graph::ASCII::Dia)
On 23.03.2006 14:39, Aaron Trevena wrote: On 23/03/06, Aaron Trevena <[EMAIL PROTECTED]> wrote: On 22/03/06, Hans Breuer <[EMAIL PROTECTED]> wrote: Thats one of the things I find annoying about dia - WTF should I learn python and rewrite cpan modules just to call a script from dia - lame lame lame. Very impressing and motivating words. Feel free to provide Perl bindings to Dia or do what ever you see fit ;) Of course if there was a binding API to build on, rather than just some nasty python hackery I might bother. Ah, I see Hans has already pointed out on list that he'd rather everybody learn python Not sure where I did do this but probably somewhere between my 'nasty python hackery' and the 'lame, lame, lame' C-hacking ;) What I meant was: Please don't expect me to help with any Perl specific questions cause my little mind is too limited to deal with all it's expressiveness :-) Or maybe: instead of complaining about missing Perl, Basic, C# or whatever bindings you may want to take a look at the *existing* and maintained Python bindings. Or maybe not. that actually be helpful in anyway towards a language independant API. My best guess on Dia's way for 'language independent API' or better bindability would be GObject: "The Plugin will probably remain such limited as it is, at least until it (and first the Dia Object System) is converted to Gtk+2.0 especially the GObject system, because the current access does not allow to ref-count the objects, to easily back-propagate property changes, etc. ..." [ http://mail.gnome.org/archives/dia-list/2001-July/msg00054.html ] Sorry, it again talks about Python - cause the Dia Python bindings predate GObject and Gtk+-2.0 and even the start of my contributions to Dia. How about some useful information Hans (or anybody else), or do I have to have a hard time reading thru the Dia source code because you did. Some more discussion was done in that same year (found from my local backup; if only the gnome mail archive could become searchable again) http://mail.gnome.org/archives/dia-list/2001-August/msg00101.html And a year later http://mail.gnome.org/archives/dia-list/2002-October/msg00027.html I still have plans to do the full GObjectification of Dia's object system, but given the average development speed of the last five years it may as well take some more five years ... Some very high level documentation of Dia Python is available here: http://www.gnome.org/projects/dia/python.html but I'm not sure if this would be of help to any other language binding writer. 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 Dia-list@gnome.org http://mail.gnome.org/mailman/listinfo/dia-list FAQ at http://www.gnome.org/projects/dia/faq.html Main page at http://www.gnome.org/projects/dia
Re: Working it out...
On 24.03.2006 18:11, Athanasios Anastasiou wrote: Hello Guys Sorry to be a nuisance with "simple" questions but is it possible to provide some hint on the following? 1) I have been looking at the Dia source code to find out some more info on how to add some properties to a graph in the way it shows up in UML. I took a look at the shapes related files and the properties related files but it seems like the shapes are very abstracted. Could you provide some insight? I suppose that there are "hooks" on things like "Show me the properties" where Dia calls a supplied function instead of its default one for properties. Something similar must be happening with the objects them selfs to provide the extra properties and stuff. Otherwise i would have to recompile Dia everytime i would like to add a new set of symbols. Any direction is greatly appreciated. Start reading in lib/object.h The concrete function (pointer) you are looking for is GetPropertiesFunc which is implemented for UML as umlclass_get_properties Every DiaObject has a factory DiaObjectType e.g. to create, load, save the object; see _ObjectTypeOps. And there is also for every object an interface definition (_ObjectOps) which allows object (class) specific implementations. GetPropertiesFunc is a function pointer in this structure. 2) Is there a way to completely reload a package in Python? I hate to restart Dia everytime i am making a change to my script. I have experimented with that but did not find a way. The idea was a proxy object which does 'import' and 'delete' on the real implementation. 3) How does the dia.register_* family of functions works? (From within Python that is) I mean, i am assigning a function to a particular menu item but it does not appear there :-/ am i missing something there? This is only working for the 'old' menu, not for the 'diagram menubar', see http://bugzilla.gnome.org/show_bug.cgi?id=171397 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 Dia-list@gnome.org http://mail.gnome.org/mailman/listinfo/dia-list FAQ at http://www.gnome.org/projects/dia/faq.html Main page at http://www.gnome.org/projects/dia
Re: bug in DIA for Windows XP?
On 27.03.2006 13:45, Philippe SENOT wrote: Hi, With DIA under Windows XP, I would like to know why I get this error in a command window: I/O warning : failed to load external entity "NULL" DIA works fine if I don't close the command window. Yes, known issue: http://bugzilla.gnome.org/show_bug.cgi?id=153056 It even is fixed with 0.95-pre: http://dia-installer.sf.net Another question: Is there a translation in french for DIA for Windows? Yes. Should be automatically selected with the new version if the systems locale setting does match. 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 Dia-list@gnome.org http://mail.gnome.org/mailman/listinfo/dia-list FAQ at http://www.gnome.org/projects/dia/faq.html Main page at http://www.gnome.org/projects/dia
Re: *UserData Suggestion
On 28.03.2006 12:42, Athanasios Anastasiou wrote: Hello All After taking a look at the UML Objects i found it somewhat complicated. You are not alone ;) I love the way you describe the properties and mem offsets within the struct. I guess that the user interface is generated through the series of DEFINEs in the PropDescription structure. This is only partially true. Especially the UML Class has all of it's user interface written by hand. However, i was just wondering why don't you use a Glib Dataset or a GLib Datalist to store the properties (under UserData). The properties need not have a particular type. These could just be strings and any code that needs them later can do the conversion. I'm not sure if I understand your question so the answer may not fit (: Dia's property system (aka. StdProps) has an extra indirection between the real Object properties and a set of properties. The latter gets passed around between the objects, the dialogs and the undo system. As already noted elsewhere Dia's type system predates GObject so if you are refering to UserData as in g_object_set_data() formerly known as gtk_object_set_user_data() that wasn't an option. Also loosing the type information too early would e.g. not allow to generate type specific - but property agnostic - user interface, which is one of the main points of the StdProps system. This will simplify the User Interface and the operations of getting and setting properties. In fact get and set operations will somewhat be taken care by the datalist. Interfacing the properties of each object with Python will also be easier this way. If you think of writing # set object's name o.name = "New Name" instead of o.properties["name"].value = "New Name" that would certainly be possible with quite some extra code in the bindings layer. But for one it could be considered as syntactical sugar not worth the effort. And also it will introduce name space clashes between the objects properties and it's core attributes, example: o.type != o.properties["type"].value Having the syntactical sugar would not make the dictionary based stuff obsolete - at least not if one wants more generic access as in export-object.py. 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 Dia-list@gnome.org http://mail.gnome.org/mailman/listinfo/dia-list FAQ at http://www.gnome.org/projects/dia/faq.html Main page at http://www.gnome.org/projects/dia
Re: Dia crashed when setting page
On 03.04.2006 08:53, Bui Vinh wrote: Hi, My name is Vinh. I use dia to create a diagram for my research. My problem is every time I access Page Setup menu in my dia (0.94 on FC3), the program crashes. If anyone can help, I will appreciate very much. Thank you. http://bugzilla.gnome.org/show_bug.cgi?id=154637 because this is a Fedora build problem I even looked it up there: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=137404 In general the most interesting page regarding Dia bugs is this: http://bugzilla.gnome.org/duplicates.cgi?product=dia 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 Dia-list@gnome.org http://mail.gnome.org/mailman/listinfo/dia-list FAQ at http://www.gnome.org/projects/dia/faq.html Main page at http://www.gnome.org/projects/dia
Re: export as image too small
On 07.04.2006 23:42, Anthony Ettinger wrote: The image export seems to only handle 1 size. I have shrunk down the UML doc to fit on one page, prints fine, but when I export to PNG, JPG, etc...it's incredible tiny. There are up to three export filters capable to produce PNG 1) via libart: antialiased, built-in 2) gdk-pixbuf: using gdk drawing like done for the display, can also export to BMP or JPEG 3) via cairo: still expiremental, can export with alpha. More formats depending on the the ones offered by the cairo library (e.g. PDF, PS) All of them share the same default size calculated from the scale entered at [Page Setup] -> scale. For scale 100% this is 20 pixels per centimeter. Only one of them offers an extra UI to modify the size during the export. 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 Dia-list@gnome.org http://mail.gnome.org/mailman/listinfo/dia-list FAQ at http://www.gnome.org/projects/dia/faq.html Main page at http://www.gnome.org/projects/dia
Re: bug: two dia toolbars open at once
On 07.04.2006 23:57, Anthony Ettinger wrote: When two are open, In the case of two toolboxes you have two independent instances of Dia running at the same time. and I export as PNG, I get an option for dimensions (which is not typical), Which of the (up to three) PNG export filters is chosen depends on the user selection in the export dialog. If 'by extension' is selected it depends on the 'random' internal order of export filters. See e.g.: http://bugzilla.gnome.org/show_bug.cgi?id=335693 however when I open the .png file, text does not show up. Know issue when Dia is running with gtk+-2-6. Seems to be solved when using a more recent gtk+-2-8 version. Can't find it at the moment in http://bugzilla.gnome.org/browse.cgi?product=dia 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 Dia-list@gnome.org http://mail.gnome.org/mailman/listinfo/dia-list FAQ at http://www.gnome.org/projects/dia/faq.html Main page at http://www.gnome.org/projects/dia
Re: Creating connection points for a PNG file
On 11.04.2006 16:34, Adrian Wooster wrote: I have a comprehensive set of professional 3D PNG files of network elements and have successfully created a simple sheet out of them - and will happily share them once complete. However, at the moment they are just insertable shapes with no connection points assigned. Can anyone advise me on a simple way of calculating where the connection points? Simply draw them with Dia and save as shape. Some connection points probably need to be removed later with a text editor. As described here http://mail.gnome.org/archives/dia-list/2004-December/msg00014.html 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 Dia-list@gnome.org http://mail.gnome.org/mailman/listinfo/dia-list FAQ at http://www.gnome.org/projects/dia/faq.html Main page at http://www.gnome.org/projects/dia
Re: Can't run Dia 0.95-pre7 on XP
On 11.04.2006 18:58, [EMAIL PROTECTED] wrote: If you had a previous dia installation on the machine before, please remove it completely (unistaller and/or deletion of program files\dia)before installing the latest version Uninstalled and reinstalled. Same error. Removal of the program files\dia folder might give better results. I hope that libcairo-2.dll is only used in the cairo plug-in. Try to delete dia\cairo.dll in your 0.95-pre7 installation. I deleted program files\dia, reinstalled Dia and it failed. Then I deleted cairo.dll and it still failed (same error). If you have gtk+-2.8 the cairo library is one of the *required* dependencies. The library is libcairo-[somenumber].dll. The cairo plug-in is called cairo.dll. And I've never seen crashes with just *loading* the plug-in as done on startup (there is no cairo code involved there at all, just Dia's plug-in registration. Instead of a de- and re-installation dance you may want to try some of the *built-in* diagnostics. Look into your $(TEMP) directory for a file called dia-0.95-pre7.log and attach it. Or change in a console window to Dia's bin directory and run 'dia', *not* diaw. Than you may see some meesages on the console window which could help us to further analyze the problem. To get rid of the libcairo-2.dll dependecy you also could install gtk+-2.6 instead of 2.8. [The only way to possibly run Dia on win9x.] 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 Dia-list@gnome.org http://mail.gnome.org/mailman/listinfo/dia-list FAQ at http://www.gnome.org/projects/dia/faq.html Main page at http://www.gnome.org/projects/dia
Re: Fix of ungroup bug
On 03.05.2006 21:04, Victor Stinner wrote: Hi, I wrote a patch to fix the "ungroup" bug (looks important since 3 people send bug report with CRITICAL level) in Dia. The bug was hard to understand (memory free()'d), but easy to fix. Please look at: http://bugzilla.gnome.org/show_bug.cgi?id=334771 ( duplicate: http://bugzilla.gnome.org/show_bug.cgi?id=338936 ) Thanks for the analysis and the fix. I will apply it to HEAD and 0.95 branch as soon as I'll find the time (probably at the weekend). I can fix other bugs if it's possible to reproduce them under my computer (Linux only). Fixing more bugs would be very much appreciated :-) Thanks, 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 Dia-list@gnome.org http://mail.gnome.org/mailman/listinfo/dia-list FAQ at http://www.gnome.org/projects/dia/faq.html Main page at http://www.gnome.org/projects/dia
Re: GtkAction, Plugins and PyGtk
On 03.05.2006 21:22, Robert Staudinger wrote: Hi, tracked in [1] i have been starting to move dia towards use of the GtkUIManager/GtkAction framework instead of the deprecated GtkItemFactory. A first patch for the toolbox is available, but API to add menu items is also exported to the python plugins via dia.register_callback. While this call is string based exporting the new new GtkAction-based API would require either + dia to depend on PyGTK or This does not sound like an option. By definition the core must not depend on a plug-in (though there is one plug-in not optional : libstandard) + the implementation of a custom API. Something like that seems to be done for The Gimp's plug-ins. The plug-in action identifiers can be added into ui files. But if there isn't already a matching action I think it is created automatically. PyGTK is of course a pretty big dependency, but for exporting internal GObject-based API and gtk widgets it can save lots of coding effort. At the moment I think you are overestimating the coding effort but underestimate the effect of screwed by design ;) What do you think about that, which way would you consider appropriate? As noted above there seems to be a solution to this exact problem in The Gimp, part of it here http://cvs.gnome.org/viewcvs/gimp/app/widgets/gimppluginaction.c?view=markup So IMO the way to go would be to change the filter_register_callback() to something more appropriate to action based menus and change some few plug-ins. One of the problems action based menus are supposed to fix cleanly is http://bugzilla.gnome.org/show_bug.cgi?id=171397 Having a proxy action seems to be a small price to pay ... Thanks, 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 Dia-list@gnome.org http://mail.gnome.org/mailman/listinfo/dia-list FAQ at http://www.gnome.org/projects/dia/faq.html Main page at http://www.gnome.org/projects/dia
Re: GtkAction, Plugins and PyGtk
Hi Robert,
it seems as if again I wont find the time this weekend to apply your
patch to my local tree. So here is some feedback from reading your patch.
On 07.05.2006 23:07, Robert Staudinger wrote:
On 5/4/06, Robert Staudinger <[EMAIL PROTECTED]> wrote:
On 5/3/06, Hans Breuer <[EMAIL PROTECTED]> wrote:
> On 03.05.2006 21:22, Robert Staudinger wrote:
[...]
> So IMO the way to go would be to change the
filter_register_callback() to
> something more appropriate to action based menus and change some few
> plug-ins. One of the problems action based menus are supposed to fix
> cleanly is http://bugzilla.gnome.org/show_bug.cgi?id=171397
>
> Having a proxy action seems to be a small price to pay ...
Ok, i will look into that.
A new patch is available now [1] which fixes the plugin issue by
introducing a new call:
dia.register_action (
action, # string
label, # string
path, # string
callback) # callable
which is an enhanced version of dia.register_callback.
Looks fine. Probably we should just drop the old signature
and thus break the (few?) plug-ins not living in Dia's tree.
If you could look at the patch that'd be great. Some feedback before
tearing things apart when moving the diagram window to use
GtkUIManager would be nice.
Some general remarks, more detailed patch review following.
- Apparently you are using a tab width of 4 while 8 is commonly used
- Maybe you could do the new development in some new files like
app/dia-actions.[hc] to improve the readability of the patches
and finally have better separation of functionalities than before?
RCS file: /cvs/gnome/dia/app/dia_embedd.c,v
retrieving revision 1.14
diff -a -u -p -r1.14 dia_embedd.c
--- dia/app/dia_embedd.c17 Nov 2003 21:41:24 - 1.14
+++ dia/app/dia_embedd.c7 May 2006 20:54:11 -
...
+/* TODO is this needed, what for?
The hiding of some of our menu entries is necessary to
adapt to the 'run-embeded' case, e.g. no File/(New|Open|Exit)
because these would conflict with the embedder's menu entries.
But maybe we should just remove app/dia_embed.c
--- dia/lib/filter.h4 Dec 2004 23:53:21 - 1.10
+++ dia/lib/filter.h7 May 2006 20:54:15 -
[...]
If you change the API between plug-ins and core you should also
increase DIA_PLUGIN_API_VERSION in lib/plug-ins.h to avoid
crashing on older plug-ins possibly laying around.
--- dia-orig/data/dia-ui.xml1970-01-01 01:00:00.0 +0100
+++ dia/data/dia-ui.xml 2006-05-07 19:10:25.0 +0200
To me a different naming conventions for actions looks more
natural, e.g. similar to what's done in The GIMP.
Instead of CamelCase ("FileNew") could we use all lower
as in "file-new" ? [Note: I don't know exactly the difference
between 'action' and 'name'. The GIMP people - who usually do
give good examples to follow - are using camel case for 'name'
but as described for 'action'.]
Thanks,
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
Dia-list@gnome.org
http://mail.gnome.org/mailman/listinfo/dia-list
FAQ at http://www.gnome.org/projects/dia/faq.html
Main page at http://www.gnome.org/projects/dia
Bugzilla Noise
Lars, the exact same feature request gets reported over and over again - apparently with your account. See: http://bugzilla.gnome.org/show_bug.cgi?id=342664 Do you see any way to stop this ? Or do we need help from the bugzilla team? Thanks, 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 Dia-list@gnome.org http://mail.gnome.org/mailman/listinfo/dia-list FAQ at http://www.gnome.org/projects/dia/faq.html Main page at http://www.gnome.org/projects/dia
Re: Bugzilla Noise
On 30.05.2006 22:04, Hubert Figuiere wrote: Hans Breuer wrote: Lars, the exact same feature request gets reported over and over again - apparently with your account. See: http://bugzilla.gnome.org/show_bug.cgi?id=342664 Do you see any way to stop this ? Or do we need help from the bugzilla team? Closing as dupe? Does not look like a good idea to me, except if it could be done automatically. The question here is: if there is something systematically wrong, should there be continuous manual intervention? Or wouldn't it be better to find the root cause of the issue? BTW: I'm resolving the bugs as INVALID because otherwise they would sooner or later show up at the dupes page http://bugzilla.gnome.org/duplicates.cgi?product=dia with unappropriate priority ... 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 Dia-list@gnome.org http://mail.gnome.org/mailman/listinfo/dia-list FAQ at http://www.gnome.org/projects/dia/faq.html Main page at http://www.gnome.org/projects/dia
Head broken - missing file
Since two days the Dia build from HEAD is broken due to make[3]: *** No rule to make target `vdx-xml.c', needed by `vdx-xml.lo'. Stop. make[3]: Leaving directory `/floss/building/gnome/dia/plug-ins/vdx' make[2]: *** [all-recursive] Error 1 http://bugzilla.gnome.org/show_bug.cgi?id=344804 2006-06-13 Lars Clausen <[EMAIL PROTECTED]> * plug-ins/vdx/*: Version 0.3 of Visio import filters, thanks again to Ian Redfern. I'd like to fix this but can't find the patch neither on the mailing list nor in bugzilla. It would be nice to have patches available in public before they (or some small bug applying them) break the build. Thanks, 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 Dia-list@gnome.org http://mail.gnome.org/mailman/listinfo/dia-list FAQ at http://www.gnome.org/projects/dia/faq.html Main page at http://www.gnome.org/projects/dia
Re: Head broken - missing file
On 15.06.2006 12:42, Ian Redfern wrote: > Apologies for this - the missing file is at > http://www.redferni.uklinux.net/dia/vdx/vdx-xml.c and the latest set of > files (currently version 0.3) is at http://www.redferni.uklinux.net/dia/vdx/ > > I'll announce all future versions to the list. > Thanks, applied: 2006-06-15 Hans Breuer <[EMAIL PROTECTED]> * plug-ins/vdx/vdx-xml.c : added file missing from 0.3 version commit. Fixes bug #344804 * lib/create.h : add create_standard_group() prototype * lib/libdia.def lib/makefile.msc objects/makefile.msc plug-ins/makefile.msc : added missing (files|exports) 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 Dia-list@gnome.org http://mail.gnome.org/mailman/listinfo/dia-list FAQ at http://www.gnome.org/projects/dia/faq.html Main page at http://www.gnome.org/projects/dia
Re: can't install dia for windows
On 21.06.2006 19:25, [EMAIL PROTECTED] wrote: > Hi, > I've followed de instruccions on the page http://dia-installer. > sourceforge.net/ but I still can not install dia for Windows. > It's installed (OK), GTK+ Runtime Environment 2.6, because I'm using > Windows 98. > When I try to install dia (dia-setup-0.95-1.exe or dia-setup-0.95-pre4. > exe) an error messagge appear: Error! Can't initialize plug-ins > directory. Please try again later. Seems like http://bugzilla.gnome.org/show_bug.cgi?id=334141 Apparently Steffen did not yet6 find the time to update his NSIS version to something above 2.13. > Some places suggest to verify if there is a problem with temp > directory, I confirmed there isn't any problem. > I've also tryed on another Windows 98 PC with same results. > What can I do? One workaround described in the above mentioned bug report is to install under some newer windoze, like Win2K or WinXP and copy over the files to the win98 machine. Another way would be to wait for a version with updated installer. 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 Dia-list@gnome.org http://mail.gnome.org/mailman/listinfo/dia-list FAQ at http://www.gnome.org/projects/dia/faq.html Main page at http://www.gnome.org/projects/dia
Re: how to use different fonts on the windows version
On 21.06.2006 10:30, Malte Stücker wrote: > Hi, > i canŽt figure out how to select different fonts (in my case symbols) in the > windows version of dia. > Tanks for your help in advance, The underlying text rendering library Pango does not support anything beside truetype fonts. SO if you don't have a truetype version of the Symbol font you are out of luck. 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 Dia-list@gnome.org http://mail.gnome.org/mailman/listinfo/dia-list FAQ at http://www.gnome.org/projects/dia/faq.html Main page at http://www.gnome.org/projects/dia
Re: Displayed Font issues
On 20.06.2006 22:18, Darin R. Thomas wrote: > I'm having a problem using Dia 0.94. When I zoom in or out the > fonts visually and sporadically change size. I have to dial in new > zoom values to get them to appear correctly. Is this a Dia issue > or a desktop issue. My os is Linux Fedora Core 3. > This is a known issue of 0.94 - in fact the most annoying one. It is fixed with the recent 0.95 release. 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 Dia-list@gnome.org http://mail.gnome.org/mailman/listinfo/dia-list FAQ at http://www.gnome.org/projects/dia/faq.html Main page at http://www.gnome.org/projects/dia
Re: create python dia plugin : need help !
On 26.07.2006 14:07, lidiriel wrote:
> I have recompiled dia 0.95 on linux.
> I paste into ~/.dia/python/hello.py , the hello code found in this
> mailling list :
> import dia
> def hello_callback(data, flags):
>print "Hello, Dia!\n"
> dia.register_callback("Hello, world",
>"/Plugins/Hello",
>hello_callback)
>
Works for me. The only issue I found was two plug-ins with the same
name in the system- and user-directory. Than only the first gets
imported.
> my dia is compiled with option --enable-debug and --with-python
Did you install it or are you running dia via app/run_dia.sh?
Is the Python plug-in loaded, i.e. visible and activated in File/Plugins?
> But i don't find the plugin entry hello in dia. It the same thing for
> center.py whit a callback function
>
> dia.register_callback ("Center Objects",
> "/Objects/Center",
> dia_objects_center_cb)
>
Not sure if I understood correctly: neither hello.py nor center.py are
registered? Does *any* of the included Python plug-ins show up? E.g. is
there /Help/Self Doc/Object Types and
/Dialogs/Group Properties ?
> What's happended ? I have no idea ?
>
Me neither. If all the above questions did not help find an answer maybe
you should start debugging yourself.
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
Dia-list@gnome.org
http://mail.gnome.org/mailman/listinfo/dia-list
FAQ at http://www.gnome.org/projects/dia/faq.html
Main page at http://www.gnome.org/projects/dia
Re: Cairo image format
> - Original Message - > From: "Staffan Hämälä" <[EMAIL PROTECTED]> > To: dia-list@gnome.org > Subject: Cairo image format > Date: Fri, 4 Aug 2006 10:53:03 +0200 > > > Hi, > > I've compiled dia on solaris 9, but I get this error message when I try to run > it: > > /app/dia/0.95/bin/dia > Error: Cairo does not yet support the requested image format: > Depth: 32 > Alpha mask: 0x > Red mask: 0x00ff > Blue mask: 0xff00 > Green mask: 0x00ff > Please file an enhacement request (quoting the above) at: > http://bugs.freedesktop.org/enter_bug.cgi?product=cairo > Assertion failed: NOT_REACHED, file cairo-image-surface.c, line 144 > Maybe the way to go would have been to follow the advice from the console dump. Or maybe you already did ... > Is this something that needs to be enabled in Cairo? And in that case, which > image format might that be? > Probably BGR (and it seems to be fixed with upcoming cairo 1.2.2), see http://lists.freedesktop.org/archives/cairo/2006-August/007558.html > I use the newest GTK+/Glib/Cairo/Pango. > If your later attempt (disabling the cairo *plug-in*) did not work, please update again. Or even downgrade cause gtk+-2.6 did not have the cairo dependency and Dia should still run with that version. Hans ___ Dia-list mailing list Dia-list@gnome.org http://mail.gnome.org/mailman/listinfo/dia-list FAQ at http://www.gnome.org/projects/dia/faq.html Main page at http://www.gnome.org/projects/dia
NewGroup (was: Dia ChangeLog report for 2006-08-15 03:00:00 UTC (Tue 15 Aug))
Am 15.08.2006 05:08, Dia ChangeLog Daemon schrieb:
> Snapshots available at http://www.raeder.dk/~larsrc/Dia/snapshots
>
> *** Recent ChangeLog entries:
>
> --- ChangeLog.previous2006-08-12 05:00:34.0 +0200
> +++ dia-cvs-snapshot/ChangeLog2006-08-15 05:00:07.092200264 +0200
> @@ -1,3 +1,24 @@
> +2006-08-13 Lars Clausen <[EMAIL PROTECTED]>
> +
> + * objects/Misc/libmisc.c:
> + * {app,objects/Misc}/Makefile.am:
> + * objects/Misc/newgroup.c:
> + * app/newgroup.c: Moved newgroup.
> +
If newgroup should replace the old group at some point in time, could
we keep it in lib/ instead of app/ for dependency reasons?
A short look did not reveal anything probiting this at the moment. And
even if there is, I'd say *that* has to change ...
Thanks,
Hans
___
Dia-list mailing list
Dia-list@gnome.org
http://mail.gnome.org/mailman/listinfo/dia-list
FAQ at http://www.gnome.org/projects/dia/faq.html
Main page at http://www.gnome.org/projects/dia
Re: group_props.py import dia [was: stroke-width]
Am 23.08.2006 15:48, Mike Dewhirst schrieb: > Lars Clausen wrote: >> Mike Dewhirst sagde: > > > >>> As an alternative, I am looking at group_props.py but it fails to import >>> dia.py. Google reveals a few dia.py results but none are apparently Dia >>> related. >> That is Hans' area, I don't claim to understand the Python parts. Hans? > > It appears from the all python scripts shown on the website, that there > must be a module called dia.py. There needs to be a module called 'dia' to somehow make dia functionality accessible to Python. It has always been this way, but it is not 'dia.py'. The Dia's Python bindings are written in C, the source code is in plug-ins/python. Under windows it is compiled to dia.pyd; under *NIX it is build if: ./configure --with-python; make; make install > Maybe Hans can indicate where it can be > found? I have downloaded the latest snapshot (21 Aug) and cannot find > any trace of it. Perhaps it has been renamed? > Nope. See above. Hans ___ Dia-list mailing list Dia-list@gnome.org http://mail.gnome.org/mailman/listinfo/dia-list FAQ at http://www.gnome.org/projects/dia/faq.html Main page at http://www.gnome.org/projects/dia
Re: dia tips
Am 14.09.2006 23:26, Lars Clausen schrieb: > äÒÁÐÉËÏ å×ÇÅÎÉÊ sagde: >> Hello >> >> After drawing (draging) any object, my mouse pointer switches to Modify >> object(s) type, so if i want to draw another same object i must click it >> again. So is it can be tune, do not switch to Modify but keep the >> abuility to draw another object of the same type without clicking it? >> Cause when drawing a lot of similar objects (lines or boxes) it realy >> irks. > > If you hold down Shift while selecting the object type in the toolbox, it > becomes 'sticky' and keeps making that object until you select something > else. > There is also the switch "Reset tools after create" in File/Preferences. Finally the IMHO most convenient ability to hit [space] when in modification mode to get back the last used tool (shape). Hans ___ Dia-list mailing list Dia-list@gnome.org http://mail.gnome.org/mailman/listinfo/dia-list FAQ at http://www.gnome.org/projects/dia/faq.html Main page at http://www.gnome.org/projects/dia
Re: win32 dia with python
At 19.09.2006 11:03, Mike Dewhirst wrote: > Steffen Macke wrote: >> Mike, >> >> I've used Python 2.2.3 from www.python.org to compile. It was installed >> in the default location (c:\Python22) > The placement of Python does not matter, Python can deduce it's placement from the registry - if only the right python2x.dll is found. > Steffen > > Further to 2.2.3, is there a reason you have stayed with that version of > Python? > > I started with 2.3.x and have recently (and painlessly) AFAIK the last Python version officially build with msvc6 (linked to msvcrt.dll) was Python 2.3 ... > been using 2.4.x > and looking forward to 2.5.x. I would be surprised if anything broke in > dia.pyd if you advanced to 2.4 or even 2.5. ... and I am not suprised but instead *know* there are problems with Python 2.4 and 2.5 almost certainly caused by the C-runtime mix. Not at compile time but at runtime. I've just tested with python25 and the problem is (as expected) still there. But even when building python25 with vc6 there are problems. Like the one mentioned in the Porting to Python 2.5 guide: mixing allocators for PyObject_* and PyMem_*() does not work anymore, see http://docs.python.org/dev/whatsnew/section-other.html [...] > The reason I like Dia is that it promises (via the Python plugin) to let > me convert UML diagrams into Python source. I'm thinking that's some > sort of holy grail :) > http://cvs.gnome.org/viewcvs/dia/plug-ins/python/codegen.py ? At 18.09.2006 03:45, Mike Dewhirst wrote: > Has anybody got Dia with Python support working in Windows? Yes, most of the newer stuff is even developed on win32. Hans ___ Dia-list mailing list Dia-list@gnome.org http://mail.gnome.org/mailman/listinfo/dia-list FAQ at http://www.gnome.org/projects/dia/faq.html Main page at http://www.gnome.org/projects/dia
Re: News on the text rendering front
Hi Lars, sorry for the late answer. There where constantly other things dragging away my time, prohibting to look closely enough into Dia's weakest area ;) On 05.09.2006 20:34, Lars Clausen wrote: The last couple of weeks, I have been working on secret text rendering stuff, trying out various things I had hoped would work to improve the quality and speed. To that end, I have introduced a new object, called TextLine, which comprises a single line of text with its font and height and possibly some cached information. This is an interesting idea but at the moment the TextLine objects seem to be too short-lived to have much positive impact. In fact they only seem to be created within the draw_text methods, so any performance boost through caching seems moot, when looking at the code. [In fact there is a huge speed improvement, but I don't completely understand why that is.] Also your implementation heavily depends on direct Freetype usage which is a problem for portability. [Although Freetype is available for win32, Dia does not depend on it, but instead transparently uses the win32 native font backend through Gtk+ and Pango (or Pango/cairo since gtk+-2.8)] So instead of poking into the internals of the various backends I've asked google for help about the root problem, switching off font hinting: http://www.google.com/search?q=win32+font+hinting The first match is a post [1] from Owen Taylor of Gtk+, Pango and cairo fame. Owens answer to specific rendering needs for Pango is PangoRenderer [2,3], introduced with Pango 1.8, which is a requirement of Gtk+-2.6, so acceptable as Dia's minimal version. PangoRender allows to set a matrix to adapt the rendering, which also seems to be the only way to switch of hinting in win32 [1]. Just completely turning of dia_font_scaled_build_layout() and instead using an appropriate pango_matrix_scale() gave very encouraging results, Dia's strings were perfectly matching the width of the box - regardless of the zoom - for the first time in Dia's history. The remaining issues were: 1) if you use a large scale factor the missing hinting is very visible, to the extend, that single glyphs are not not drawn at all, see: http://hans.breuer.org/dia/text-box-1282-1.png But with a combination of scaled font and font matrix it got much better. 2) the alignment adjustment is somewhat wrong, probably a combination from still using dia_font_get_scaled_string_width() to offset but already somewhat adjusting the offset for Pango with the matrix http://hans.breuer.org/dia/text-box-1282-1.png 3) the cursor position is wrong when zoomed. This is not new with the new approach, but should be fixed anyway. For the unscaled version see: http://hans.breuer.org/dia/text-box-100-1.png This allowed me to fiddle enough with rendering to finally find what appears to be the root cause of the font rendering problems: Pango seems to round the width of glyphs in its layout to pixels. Thus rendering the same text at different font sizes is almost guaranteed to give different relative widths. Our current kludge of trying to find a proper height was not only very slow, potentially creating many layouts per rendering, but also could not possibly work in all cases. But that kludge is still used in CVS, isn't it? In the TextLine rendering function for the GDK FT2 rendering, I make use of cached values for the sizes of the glyphs at 100% to "manually" adjust the sizes at other zoom levels to match. This has allowed me to sidestep the whole ugly kludge and render directly with the desired size. Could you explain me in simple words why we need another high level Text object or better how the new TextLine is conceptually different from the long time existing Text object, which already used to cache its size. Even better it clearly belongs to the object side of rendering so many object implementations alreay benefit from it. The outcome: Text rendering is now up to 30 times (not just 30%, 30 times!) faster than before, text width is actually accurate, and we can toss out our ugly kludge. Three very annoying birds with one stone. I am very happy. There's still some amount of work for this to be used throughout the renderers, and the objects should use TextLine instead of ever calling draw_string. Getting rid of draw_string, where font and text are completely separated may be a worthwhile goal, but both our approaches don't really need this. I expect to be working on this in the upcoming weeks, and any help would be appreciated, especially from those who know the ins and outs of the various renderers. The patch I've done just calculates the the width of the string a second time and returns the deviation of the desired as scale factor. It does not need the new TexLine object to be almost as fast and I would prefer to not have another object between DiaObjects and DiaRenderers at least if we can do as well without. Thanks, Hans [1] http://l
msvc link problems (wa Re: Dia-list Digest, Vol 30, Issue 23)
On 27.10.2006 23:40, Andreas Owen wrote: > Hello > > I've solved my previous compiling problems but now i'm having trouble > with the obj-files. i found something about multithreading option "/MT". > It didn't have any affect. can someone please help. > The /mt option *has* the effect to use the correct c-runtime version: msvcrt.dll. It does not slove other missing libraries if that's what you are expecting. The cl command line shown by should look like this: Microsoft (R) Program Maintenance Utility Version 6.00.8168.0 Copyright (C) Microsoft Corp 1988-1998. All rights reserved. cl -G5 -Zi -MD -W3 -nologo -I. -DHAVE_CONFIG_H -LD -Felibdia.dll autoroute.obj arrows.obj attributes.obj bezier_conn.obj beziershape.obj boundingbox.obj color.obj connection.obj connectionpoint.obj connpoint_line.obj create.obj debug.obj diaarrowchooser.obj dialinechooser.obj diatransform.obj dia_dirs.obj dia_image.obj dia_svg.obj dia_xml.obj diaerror.obj diagramdata.obj diagdkrenderer.obj diagtkfontsel.obj diainteractiverenderer.obj dialibartrenderer.obj diarenderer.obj diasvgrenderer.obj dynamic_obj.obj element.obj filter.obj focus.obj font.obj geometry.obj group.obj intl.obj message.obj neworth_conn.obj objchange.obj object.obj object_defaults.obj orth_conn.obj paper.obj parent.obj persistence.obj plug-ins.obj poly_conn.obj polyshape.obj prop_attr.obj prop_basic.obj prop_geomtypes.obj prop_inttypes.obj prop_sdarray.obj prop_text.obj prop_widgets.obj propdesc.obj propdialogs.obj properties.obj proplist.obj propobject.obj propoffsets.obj propregistry.obj ps-utf8.obj render_pixmap.obj sheet.obj text.obj textline.obj utils.obj widgets.obj diamarshal.obj ..\../gtk+-2-8\gtk\gtk-wi32-2.0.lib ..\../gtk+-2-8\gdk\gdk-win32-2.0.lib ..\../gtk+-2-8\gdk-pixbuf\gdk_pixbuf-2.0.lib ..\../pango\pan go\pango-1.0.lib ..\../pango\pango\pango-1.0.lib ..\../pango\pango\pangowin32-1.0.lib ..\../pango\pango\pango-1.0.lib ..\../pango\pango\pangocairo-1.0.lib ..\..\glib\glib\glib-2.0.lib ..\..\glib\gmodule\gmodule-2.0.lib ..\..\glib\gobject\gobject-2.0.lib ..\../gnome-xml\libxml2.lib ..\../other/zlib123\zlib.lib ..\../ libart_lgpl\libart.lib ..\../gtk+-2-8\gdk-pixbuf\gdk_pixbuf-2.0.lib ..\../other/intl-tml\libintl-1.lib user32.lib advapi32.lib wsock32.lib /link /OPT:REF /def:libdia.def Creating library libdia.lib and object libdia.exp > MSCVC6 output: > > Creating library libdia.lib and object libdia.exp > sheet.obj : error LNK2001: unresolved external symbol __imp__xmlFree > [...] > NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual > Studio\VC98\BIN\nmake.exe"' : return code '0x2' Although you haven't shown it your command line is missing the libxml2 part. You either did not follow step 6. in Steffen's list [1] or the make.msc you are reading does not have something like: LIBXML2_CFLAGS = $(LIBICONV_CFLAGS) -I $(LIBXML2)\include LIBXML2_LIBS = $(LIBXML2)\libxml2.lib BTW: are you aware of the first document [2] trying to describe the build configuration? [1] http://dia-installer.sourceforge.net/dia_win32_compilation.html [2] http://cvs.gnome.org/viewcvs/glib/README.win32?rev=1.43&view=markup 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 Dia-list@gnome.org http://mail.gnome.org/mailman/listinfo/dia-list FAQ at http://www.gnome.org/projects/dia/faq.html Main page at http://www.gnome.org/projects/dia
Re: dia libs 3 errors
On 28.10.2006 18:45, Andi Owen wrote: > hello > > thanks alot ofr the help, i didn't notice that i only had libxml and not > libxml2 in the makefile. unfortunatley there are still 3 linking > problems eventhough i've got the libraries. or am i missing something. > > thanks and regardes > andi > > ps: > am i aloud to mail you directly or shout it always go over the mailinglist? > I'd prefer to keep this on the public mailing list, so possibly other people trying the same can benefit. > my cl is as follows: > > cl -G5 -GF -MDd -W3 -nologo -I. -DHAVE_CONFIG_H -LD -Felibdia.dll > autoroute.obj arrows.obj attributes.obj bezier_conn.obj > beziershape.obj boundingbox.obj color.obj connection.obj > connectionpoint.obj connpoint_line.obj debug.obj diaarrowc > hooser.obj dialinechooser.obj diatransform.obj dia_dirs.obj > dia_image.obj dia_svg.obj dia_xml.obj diaerror.obj diagramdata.obj > diagdkrenderer.obj diagtkfontsel.obj diainteractiverenderer.obj > dialibartrenderer.obj diarenderer.obj diasvg > renderer.obj dynamic_obj.obj element.obj filter.obj focus.obj > font.obj geometry.obj group.obj intl.obj message.obj > neworth_conn.obj objchange.obj object.obj object_defaults.obj > orth_conn.obj paper.obj parent.obj persistence.obj plu > g-ins.obj poly_conn.obj polyshape.obj prop_attr.obj prop_basic.obj > prop_geomtypes.obj prop_inttypes.obj prop_sdarray.obj prop_text.obj > prop_widgets.obj propdesc.obj propdialogs.obj properties.obj > proplist.obj propobject.obj propoffse > ts.obj propregistry.obj ps-utf8.obj render_pixmap.obj sheet.obj > text.obj utils.obj widgets.obj diamarshal.obj gtk-win32-2.0.lib > gdk-win32-2.0.lib pango-1.0.lib pango-1.0.lib pangowin32-1.0.lib > glib-2.0.lib gmodule-2.0.lib gobject-2.0.lib l > ibxml2.lib zlib.lib art_lgpl_2.lib gdk_pixbuf-2.0.lib intl.lib > user32.lib advapi32.lib wsock32.lib /link /debug /def:libdia.def > Creating library libdia.lib and object libdia.exp > dia_image.obj : error LNK2001: unresolved external symbol > _gdk_pixbuf_new_from_file > widgets.obj : error LNK2001: unresolved external symbol > _gtk_file_chooser_set_filename > widgets.obj : error LNK2001: unresolved external symbol > _gtk_file_chooser_get_filename > libdia.dll : fatal error LNK1120: 3 unresolved externals > NMAKE : fatal error U1077: 'cl' : return code '0x2' > Stop. > NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual > Studio\VC98\BIN\nmake.exe"' : return code '0x2' > Stop. > Error executing nmake. > Since gtk+ 2.6 all gtk+ functions taking filename argument are redefined to have a _utf8 postfix. The pure symbols are marked as private. One reason to have them unresolved is a mismatch between the headers and the libraries versions. If you have updated the gtk version since your first build attempt try deleting widgets.obj and rebuild. Or better: nmake -f makefile.msc clean to also avoid other issues where you may have compiled without matching prototype. 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 Dia-list@gnome.org http://mail.gnome.org/mailman/listinfo/dia-list FAQ at http://www.gnome.org/projects/dia/faq.html Main page at http://www.gnome.org/projects/dia
Re: 2 last compile problems
On 31.10.2006 19:19, Andreas Owen wrote: > Hello > > i've only got to errors left when compiling. ... both are from plug-ins so you should be able to completely ignore them. > one of them is gnomeprint, > i cant compile it nor get any win32 precompilations for it. the secound > error is quite weired. can anyone help? > I do not link the gnomeprint plug-in anymore myself on win32. It is marked experimental and should be superseded by gtk/cairo print. [...] > LINK : fatal error LNK1181: cannot open input file "libgnomeprint-2-2.dll" the DLL in the link line is wrong. You probably have it in GNOMEPRINT_LIBS in make.msc, but see above. [...] > cl -G5 -GF -MD -W3 -nologo -I. -I..\.. -DHAVE_CONFIG_H -GD -c > -FImsvc_recommended_pragmas.h -I ..\..\..\glib -I ..\..\..\glib\glib -I > ..\..\..\glib\gmodule -I ..\..\../gettext-0.14.5/intl -I ..\..\..\glib > -I ..\..\..\glib\glib -I ..\..\..\glib\gm > odule -I ..\..\../gettext-0.14.5/intl -I ..\..\../atk > -I..\..\../gtk+\gdk -I..\..\../gtk+\gdk -I..\..\../gtk+ -I..\..\../pango > -I..\..\../atk -I. -I ..\..\../libiconv-1.9.1\include -I \include > -I..\..\lib -I ..\..\..\cairo\cairo\src -I ..\..\..\cai > ro\libpixman\src -I ..\..\..\cairo -I ..\..\../freetype2\include diacairo.c > diacairo.c > diacairo.c(1019) : error C4013: > 'cairo_pdf_surface_set_dpi_REPLACED_BY_cairo_surface_set_fallback_resolution' > undefined; assuming extern returning int This is cairo's way to deprecate functions. It shows me that you are not trying to compile from cvs HEAD but maybe from 0.95-1 tarball. An older version of cairo or better a merge form HEAD would fix it. 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 Dia-list@gnome.org http://mail.gnome.org/mailman/listinfo/dia-list FAQ at http://www.gnome.org/projects/dia/faq.html Main page at http://www.gnome.org/projects/dia
Re: gtk+ 2.8 in Windows and Cygwin
On 16.11.2006 14:27, Dan Fabrizio wrote: > Hello dia_list, > > I have cygwin installed on my Windows XP system and I use a program called > gtkwave 3.0 which depends on the gtk+ 2.6 libs installed by cygwin. > > I want to use dia in cygwin but haven't been able to compile it so I tried > the Windows version of dia but it depends on gtk+ 2.8 libs. > Where did you get that information? Even the most recent version from cvs still has: GTK_MODULES="gtk+-2.0 >= 2.6.0 glib-2.0 >= 2.6.0 libxml-2.0 gdk-pixbuf-2.0 gthread-2.0" and /should/ compile just fine with gtk+ 2.6. Though this may not be checked very often since even gtk+-2.10 is released for quite some time. > 2 questions: > >Is there help for installing dia on cygwin??? Not that I know of. And to me it looks a litte pointless cause there is a native version for win32 available for years. For someone with good *nix/cygwin knowledge the usual ./configure; make; make install may work. > I have the latest version > of gtk+ from cygwin which is 2.6.xx. > >Is there a way to run gtkwave with gtk+ 2.6 and dia with gtk+ 2.8?? If I > install gtk+ 2.8 on windows will it get confused with gtk+ 2.6 on cygwin? > If the PATH is different between your two environments it should work flawlessly. (Given that the cygwin gtk does not use the windows registry nor windows PATH environment variables. But instead provides a *NIX environment even). 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 Dia-list@gnome.org http://mail.gnome.org/mailman/listinfo/dia-list FAQ at http://www.gnome.org/projects/dia/faq.html Main page at http://www.gnome.org/projects/dia
Re: Non-interactive mode
On 12.12.2006 16:49, Alan Woodland wrote: > Hi, > > I just downloaded and compiled Dia 0.94 on my Mac (10.4), under fink. > Following the instructions in the posting [1]. With Dia 0.94 on > Debian when I run dia --version or --help it does what I expected, > i.e. showing the version or the help and exiting. When I try this on > my Mac (or more importantly use --export= and --export-to-format=) it > doesn't work, instead it tries to treat all the arguments passed to > it as files to open. > > Am I being really stupid here? Is this a known issue? The > documentation installed in /usr/local/man/man1/dia.1 indicates this > should work as I expected. > Looking at the code I think this *is* expected, at least if you don't have a new enough GLib version (>= 2.6) and also POPT (see HAVE_POPT in app_procs.c) is missing. BTW: I only looked at the current source verion, not the obsolete 0.94. But I'm sure the code has only improved since that. 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 Dia-list@gnome.org http://mail.gnome.org/mailman/listinfo/dia-list FAQ at http://www.gnome.org/projects/dia/faq.html Main page at http://www.gnome.org/projects/dia
Re: Problem compiling from cvs
On 03.01.2007 13:37, Tor Harald Thorland wrote: > > Hello, > > I downloaded the latest cvs version of Dia. > Did run: > ./autogen.sh --prefix=/home/tortho/dia --enable-gnome > and then make. > > Make gives me the following error. > I/usr/include/libgnomeui-2.0 -I/usr/include/libgnomecanvas-2.0 > -I/usr/include/libbonoboui-2.0 -I/usr/include/gnome-keyring-1 > -I/usr/include/libart-2.0 -DPREFIX=\""/home/tortho/dia"\" > -DSYSCONFDIR=\""/home/tortho/dia/etc"\" > -DDIA_DATADIR=\""/home/tortho/dia/share"\" > -DDIA_LIBDIR=\""/home/tortho/dia/lib"\" > -DLOCALEDIR=\"/home/tortho/dia/share/locale\" > -DUIDATADIR=\"/home/tortho/dia/share/dia/ui\" > -I/usr/include/libxml2 -I/usr/include/freetype2 -g -O2 -Wall -Wunused > --std=c89 -Wdeclaration-after-statement -Wmissing-prototypes > -Wmissing-declarations -finline-functions -fstrict-aliasing -MT > app_procs.o -MD -MP -MF ".deps/app_procs.Tpo" -c -o app_procs.o > app_procs.c; \ > then mv -f ".deps/app_procs.Tpo" ".deps/app_procs.Po"; else > rm -f ".deps/app_procs.Tpo"; exit 1; fi > app_procs.c: In function ?do_convert?: > app_procs.c:421: warning: passing argument 4 of ?ef->export_func? > discards qualifiers from pointer target type > app_procs.c: In function ?app_init?: > app_procs.c:791: error: ?DATADIR? undeclared (first use in this function) > app_procs.c:791: error: (Each undeclared identifier is reported only once > app_procs.c:791: error: for each function it appears in.) > app_procs.c:791: error: ?LIBDIR? undeclared (first use in this function) > make[4]: *** [app_procs.o] Error 1 > make[4]: Leaving directory `/home/tortho/source/dia/app' > make[3]: *** [all-recursive] Error 1 > make[3]: Leaving directory `/home/tortho/source/dia/app' > make[2]: *** [all] Error 2 > make[2]: Leaving directory `/home/tortho/source/dia/app' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/home/tortho/source/dia' > make: *** [all] Error 2 > > Does anyone have any hint on this one? This is a side-effect of: 2006-10-12 Lars Clausen <[EMAIL PROTECTED]> * lib/dia_dirs.c (dia_get_lib_directory, dia_get_data_directory): * lib/Makefile.am (AM_CPPFLAGS): * app/Makefile.am (INCLUDES): Rename DATADIR and LIBDIR to DIA_DATADIR and DIA_LIBDIR to avoid conflicts with libtool and the like. Thanks to lode leroy <[EMAIL PROTECTED]> for pointing out the solution. Unfortuantely I don't know what problem was supposed to be fixed by that. The issue already is reported as http://bugzilla.gnome.org/show_bug.cgi?id=385701 The current work-around is to use --disable-gnome. BTW: this wont be fixed in CVS anymore because we switched to SVN [1] To get the most recent version use svn co http://svn.gnome.org/svn/dia/trunk or for write access svn svn+ssh://[EMAIL PROTECTED]/svn/dia/trunk > Also, is there a description somewhere on how to make and add symbols to > Dia, I wan't to contribute with symbols used by engineers onboard > ships/shipbuilding. > http://svn.gnome.org/viewcvs/dia/trunk/doc/custom-shapes?rev=2543&view=markup or http://www.seanet.com/~hgg9140/comp/diatut/all/all.html#6.4. 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 Dia-list@gnome.org http://mail.gnome.org/mailman/listinfo/dia-list FAQ at http://www.gnome.org/projects/dia/faq.html Main page at http://www.gnome.org/projects/dia
