Re: INTERNET SPY
Alexander Larsson wrote: This mailing-list is intentionally set up so that non-subscribers can post. This is done so we won't lose any bug reports etc. (The mail-address on the homepage goes to this list.) I think this is a good idea. But I have another suggestion: Is it possible to place automati- cally some remarkable text like "[DIA]" into the subject? With this it would be possible to filter out the incoming mails. That would be great. -volker -- Volker Moell [EMAIL PROTECTED] (Products Developement) * ID-PRO Deutschland GmbH * Am Hofgarten 20 * D-53113 Bonn * Tel. +49 (0) 2 28-4 21 54-40 * Fax -29 * http://open-for-the-better.com
Re: INTERNET SPY
On Wed, 12 Apr 2000, Volker Moell wrote: But I have another suggestion: Is it possible to place automati- cally some remarkable text like "[DIA]" into the subject? With this it would be possible to filter out the incoming mails. This isn't necessary. Just check for ^.*Sender:.*dia-list.*@.*lysator.liu.se (for instance; regexp wizards can surely optimise that a bit) and you're go. -- Cyrille -- Grumpf.
crash in render_libart
Hi folks,
I just stumbled upon a crash in renderer_libart_copy_to_window, with
anti-aliased mode ON. I was resizing a window, just after dropping a
rectangle in it.
This might be the same as the crash which was reported a few days ago.
The last line of dia's code executed was here :
extern void
renderer_libart_copy_to_window(RendererLibart *renderer, GdkWindow *window,
int x, int y, int width, int height)
{
static GdkGC *copy_gc = NULL;
int w;
if (copy_gc == NULL) {
copy_gc = gdk_gc_new(window);
}
w = renderer-renderer.pixel_width;
/* HERE */ gdk_draw_rgb_image(window,
copy_gc,
x,y,
width, height,
GDK_RGB_DITHER_NONE,
renderer-rgb_buffer+x*3+y*3*w,
w*3);
}
The variables were :
x=-1, y=-1, width=0, height=121, w=0, renderer-rgb_buffer pointed
to something appearing to be valid.
I wonder if x and y really ought to be negative : renderer-rgb_buffer
is valid, but is (renderer-rgb_buffer - 3) really a place we can blit ?
Lacking time and expertise in that area, I hope that helps.
-- Cyrille
--
Grumpf.
app/dia.gnorba
Is there something to be shown to the user there ? If yes, is there a doc somewhere in the Gnome Doc project about how to translate that ? Thanks -- Cyrille -- Grumpf.
test
I think I got dropped from the list a bit over a week ago. I am sorry if I didn't respond to messages during that period. I think I am subscribed again now (I will know for sure when I get this message). James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/
Re: INTERNET SPY
On Wed, 12 Apr 2000, Cyrille Chepelov (home) wrote: On Wed, 12 Apr 2000, Volker Moell wrote: But I have another suggestion: Is it possible to place automati- cally some remarkable text like "[DIA]" into the subject? With this it would be possible to filter out the incoming mails. This isn't necessary. Just check for ^.*Sender:.*dia-list.*@.*lysator.liu.se Or even better: Resent-From: [EMAIL PROTECTED] (for instance; regexp wizards can surely optimise that a bit) and you're go. -- Cyrille James.
Re: app/dia.gnorba
The description string is displayed to the user (in the insert object dialog of a bonobo container application), but none of the other .gnorba files on my computer seem to contain translations. Also, as the bonobo container app is not finished, I don't know if end users really want to play around with it yet. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ On Wed, 12 Apr 2000, Cyrille Chepelov (home) wrote: Is there something to be shown to the user there ? If yes, is there a doc somewhere in the Gnome Doc project about how to translate that ? Thanks -- Cyrille -- Grumpf.
'Other' ER Diagrams
Hey, Has anyone done the ER diagrams that look something like this: TableName 0--||-TableName - columncolumn column column I think they are called an 'engineering' ER, but I can't remember. Anyway, I have yet to find an OS app that runs under unix that does them and they are far more useful to me than 'standard' ER charts. If someone hasn't done the layout for this yet, I guess I'll have to :) thanks.
Re: svg export/custom shape import
On Wed, 12 Apr 2000, [EMAIL PROTECTED] wrote: Hi all, I'm building a library of HP switches (a la visio) using custom shapes (dia-0.84). I'm using dia to build the shape, exporting it to svg, doing some vim stuff to get it right, firing dia to check the work. Here are some input on problem I got into : [schnip - don't know svg] More feature ;-) - As stated in a previous mail, it would be nice to had someway (menu,shortcut) to reload the libraries ... so when you're building a lib, you can test it on the fly (and not to close dia to reopen it in the following second). The newest CVS version has plugin support where the sheets can be loaded and unloaded (unloading everything makes dia start a lot faster). I think that'll do it. -sheet file stuff (2nd try :) In a sheet file, you got a description of the library associated for ex in the network sheet: descriptionObjects to design network diagrams with./description That description doesn't seem to be used in dia. Might be nice to have it showing (like for the objects) when you leave the mouse on the library button/onglet. Haven't heard the term 'onglet' before. Wazzat? But yes, it should be a tooltip for the tab. -Lars -- Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause) | Hårdgrim of Numenor "I do not agree with a word that you say, but I| Retainer of Sir Kegg will defend to the death your right to say it."| of Westfield --Evelyn Beatrice Hall paraphrasing Voltaire | Chaos Berserker of Khorne
Re: svg export/custom shape import
On 12 Apr 2000, Lars Clausen wrote: Haven't heard the term 'onglet' before. Wazzat? French for notebook-tab (in UI context) But yes, it should be a tooltip for the tab. didn't see one either. -- Cyrille -- Grumpf.
Processed: cleaning
Processing commands for [EMAIL PROTECTED]: reassign 8858 gtk+ [#8858] gtk+: scrolled text freezes Ticket assigned to `gtk+'. close 8873 [#8873] Ticket closed, ack sent to submitter - they'd better know why ! reassign 8901 dia [#8901] Anti-Aliasing causes crash (Other Crash at 128.227.212.142) Ticket reassigned from `general' to `dia'. reassign 8892 gnorpm [#8892] Shuts down gnorpm (Other Crash at 12.10.230.2) Ticket reassigned from `general' to `gnorpm'. close 8855 [#8855] Ticket closed, ack sent to submitter - they'd better know why ! close 8849 [#8849] Ticket closed, ack sent to submitter - they'd better know why ! close 8852 [#8852] Ticket closed, ack sent to submitter - they'd better know why ! close 8869 [#8869] Ticket closed, ack sent to submitter - they'd better know why ! close 8870 [#8870] Ticket closed, ack sent to submitter - they'd better know why ! close 8865 [#8865] Ticket closed, ack sent to submitter - they'd better know why ! close 8875 [#8875] Ticket closed, ack sent to submitter - they'd better know why ! close 8876 [#8876] Ticket closed, ack sent to submitter - they'd better know why ! close 8882 [#8882] Ticket closed, ack sent to submitter - they'd better know why ! close 8894 [#8894] Ticket closed, ack sent to submitter - they'd better know why ! close 8884 [#8884] Ticket closed, ack sent to submitter - they'd better know why ! End of message, stopping processing here. Please contact me if you need assistance. Webmaster (administrator, Gnome ticket database)
Re: svg export/custom shape import
On Wed, 12 Apr 2000, [EMAIL PROTECTED] wrote: Lars Clausen wrote: ... More feature ;-) - As stated in a previous mail, it would be nice to had someway (menu,shortcut) to reload the libraries ... so when you're building a lib, you can test it on the fly (and not to close dia to reopen it in the following second). The newest CVS version has plugin support where the sheets can be loaded and unloaded (unloading everything makes dia start a lot faster). I think that'll do it. Cool. Does that mean you will be able to choose the sheets/libs you want ??? Well, the way to install them is still the same, and every sheet that's installed will have a tab, but only those that are loaded actually have buttons showing up. This could probably be extended to a more flexible way to point at places to load sheets from. -sheet file stuff (2nd try :) In a sheet file, you got a description of the library associated for ex in the network sheet: descriptionObjects to design network diagrams with./description That description doesn't seem to be used in dia. Might be nice to have it showing (like for the objects) when you leave the mouse on the library button/onglet. Haven't heard the term 'onglet' before. Wazzat? But yes, it should be a tooltip for the tab. Cyrils seems to be more accustomed to english UI terms than me ... I wasn't sure about the tab term so I put the french one, just in case it could help :) Ah. Unfortunately, my french isn't that good. I kept thinking what an ong could be that you'd talk about a little version of:) -Lars -- Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause) | Hårdgrim of Numenor "I do not agree with a word that you say, but I| Retainer of Sir Kegg will defend to the death your right to say it."| of Westfield --Evelyn Beatrice Hall paraphrasing Voltaire | Chaos Berserker of Khorne
Re: svg export/custom shape import
I forgot to had the arc question in the "feature wanted section", so here it is : - Any plan, for the support of arc in svg/custom shape ??? Could ease the building of some objects. I try to redo a cloud shape using bezier curve but : - you have to be very patient ;-) playing arround with handles and control point to get it right - doing a one piece curve, I didn't get anything better than what we got already (scales well, doesn't look realy nice) - doing the cloud using a bunch of curve gives sth much better (in terms of look) but doesn't scale Using arcs, you got sth in between, scales well, nice looking and symmetry for those who like it. Just in case so as nothing on its todo list ;-)) Fab
handles/connexion points stuff
Working on my network lib, I got into some other pb/limitations : The way I'm building the lib is the following : - build the basic objects (basicaly an rj45 model and a fibre model) - include them in the lib - use those objects to build more complex ones (row of 4,6,8 RJ45, tranceiver) - include them in the lib - build even more complex object using the preceding ones (mainly daughter cards to put in some chassis) - include them blablalbla - finaly build your hubs, switches, router ... I already did all that a year and an half using xfig and it seems to work. BTW is the rotation of an object already in the CVS version ?? I had to build both the row and the columns of RJ45 by hand. Feel it a bit boring ;-) Now, I had that strange idea to but a connection point in the middle of my RJ45 object just in case I want to connect it to a station/switch/router etc ... Build my row of 4 rj's. Saved it, exported it to svg, build the custom shape and lost the information about my connexion points :-(( I had a look at the svg file nothing in there (normal), had a look at the .dia file nothing in there either, about the position of connexion points (sure, everything is in the custom shape and in the dia file you just got some position and properties stuff). So I build all my rows and columns of rj's adding the connexion points by hand (with the right initial position and the right scaling, it's not that much painful). Now I start building the switches ... and that really sucks. With rows of rj's on tranceivers or on daughter boards which are themselves on chassis or switches it's almost impossible to find a scale/position where the position of the connection points will be easy to find. And now I've 16, 24 position to find (I've also a 80 ports switches in my todo list). And as evry body nows, hand work doesn't scale well ;-)) So if so got a nice idea of how not to lose the information about the connexion points through the .dia/.svg/.shape cycle... I'm open to any advice :) Now for those who have read this far, we've tranceiver/daughter cards on my left and chassis on my right. In the middle a user, who wants to build his/her switch/router using those components ... The first way of doing it is just to put the element you want on the switch and zooming in and out to get it right. That's what I used with xfig but that are a lot of pbs with that approche : - difficulties to get your objet perfect (alignement in all directions, right position for each module you put etc ...) - there are small chances to be able to build exactly the same object a second time - trouble with scaling/moving So I had a look at visio this week and they solve that problem nicely using handle and connexion points : - they use connexion points on the chassis to mark the position of the tranceiver - they put handles on the tranceiver - and the user has just to clip his module on the right place to get it be a part of the chassis. Is there a way to implement that fonction in the custom objects ?? BWT, in the README at the root of the CVS, there is the following on handles : " Note on handles and connection points: -- An object has handles to resize it. A handle can be moved either because the user dragged it with the mouse, or the handle is attached to another object, which moved itself. The handles are diplayed as little squares (red: normal, green: attached to an object, blue: can't be moved). " Isn't there a mixup between green and red ;-) Good thinking, Fab
Re: 'Other' ER Diagrams
Has anyone done the ER diagrams that look something like this: TableName 0--||-TableName - columncolumn column column I think they are called an 'engineering' ER, but I can't remember. Looks a little like a "Ladder Logic" diagram, but that's an industrial controller programming tool.
Re: Dia in larger scale projects
... I wouldn't expect Dia to expand to include project management but more likely a separate Project Management application that uses Dia as a component ... Well, something like that. There is "DiaCanvas", which is just the display canvas, that can be used as a component in other programs. I'm waiting for a programmable interface to Dia; someone is working on a Python interface. When that's done, we can write routines for project management interfaces: displaying data in various ways, user interfaces for management functions, summary/detail displays, routines to interface to other data sources...
Re: 'Other' ER Diagrams
On Wed, 12 Apr 2000, Scot E. Wilcoxon wrote:
I am working on that, besides allowing the selection
of attribute data types. I am still not sure what notation
to use, but what I currently have in mind is slightly
different from yours (like the one in DataArchitect).
Relationships would be represented the same way as
what dia uses now, but attributes would be in the
same box as the entity. I was thinking about making
the cardinality of relationships be stated by numbers
(1-n, 1-1, etc), but I think Ill use ut the 'chicken foot' one.
I'll probably need to hack the main preogram code too,
as I need to extend it to support diagram specific menus,
so it won't be available as a plug-in module (unless
the official distro supports the diagram specific menu stuff).
This is part of my graduation project, whi will be an extension for
dia to create SQL scripts (and maybe reverse
engineering too) from an ER diagram.
--
Alfredo
Has anyone done the ER diagrams that look something like this:
TableName 0--||-TableName
-
columncolumn
column
column
I think they are called an 'engineering' ER, but I can't remember.
Looks a little like a "Ladder Logic" diagram, but that's an industrial
controller programming tool.
Polyshape improvement
I just checked in a few more distance algorithms to geometry.c, and made the new polyshape use the polygon distance algorithm. The polyshape is now much nicer to work with :) I also checked in some functions for bezier and ellipse distances, which should be enough to help write a correct distance algorithm for the custom shape code, which will be much better than the current bounding box distance algorithm currently in use. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/
Should we drop the imlib dependency alltogether?
I was wondering what people think of the idea of dropping imlib support in dia altogether in favour of gdk-pixbuf. The next version of gdk-pixbuf drops the libart dependency, so the only libraries required to build gdk-pixbuf are glib, gtk+ and the image libraries, so it is no more of a problem to compile than imlib. The current way we use imlib doesn't exploit any of its caching functionality, and fits what gdk-pixbuf provides quite nicely. What do you think? James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/
Re: Polyshape improvement
On Thu, 13 Apr 2000, [EMAIL PROTECTED] wrote: I just checked in a few more distance algorithms to geometry.c, and made the new polyshape use the polygon distance algorithm. The polyshape is now much nicer to work with :) You too? I put mine in polyshape itself, though. I also checked in some functions for bezier and ellipse distances, which should be enough to help write a correct distance algorithm for the custom shape code, which will be much better than the current bounding box distance algorithm currently in use. That's good; How easy would it be to transfer the bezier distance to a polycurve/beziergon/whachammacallit? -Lars -- Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause) | Hårdgrim of Numenor "I do not agree with a word that you say, but I| Retainer of Sir Kegg will defend to the death your right to say it."| of Westfield --Evelyn Beatrice Hall paraphrasing Voltaire | Chaos Berserker of Khorne
Re: Should we drop the imlib dependency alltogether?
On Thu, 13 Apr 2000, [EMAIL PROTECTED] wrote: I was wondering what people think of the idea of dropping imlib support in dia altogether in favour of gdk-pixbuf. The next version of gdk-pixbuf drops the libart dependency, so the only libraries required to build gdk-pixbuf are glib, gtk+ and the image libraries, so it is no more of a problem to compile than imlib. The current way we use imlib doesn't exploit any of its caching functionality, and fits what gdk-pixbuf provides quite nicely. I think we should keep it for now, since a lot of people will have imlib compiled but not gdk-pixbuf... on the other hand, it's better to get the changes out early. Code-wise, it doesn't matter much. -Lars -- Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause) | Hårdgrim of Numenor "I do not agree with a word that you say, but I| Retainer of Sir Kegg will defend to the death your right to say it."| of Westfield --Evelyn Beatrice Hall paraphrasing Voltaire | Chaos Berserker of Khorne
Re: Should we drop the imlib dependency alltogether?
On Wed, Apr 12, 2000 at 09:23:03PM -0500, Lars Clausen wrote: On Thu, 13 Apr 2000, [EMAIL PROTECTED] wrote: I was wondering what people think of the idea of dropping imlib support in dia altogether in favour of gdk-pixbuf. The next version of I think we should keep it for now, since a lot of people will have imlib compiled but not gdk-pixbuf... on the other hand, it's better to get the changes out early. Code-wise, it doesn't matter much. #ifdef USE_IMLIB do_it_the_old_broken_way (); #else do_it_the_new_way_with_pixbuf (); #endif And of course use autoconf; if pixbuf is found, don't use imlib. (Of course I have a big mouth and I'm not writing any code, but this looks to me like the correct way to make progressive changes, specially when backwards compatibility is concerned.) []s, |alo + -- Hack and Roll ( http://www.hackandroll.org ) News for, uh, whatever it is that we are. http://www.webcom.com/lalo mailto:[EMAIL PROTECTED] pgp key in the personal page Brazil of Darkness (RPG)--- http://zope.gf.com.br/BroDar
Re: Should we drop the imlib dependency alltogether?
James Henstridge wrote: I was wondering what people think of the idea of dropping imlib support in dia altogether in favour of gdk-pixbuf. The next version of gdk-pixbuf drops the libart dependency, so the only libraries required to build gdk-pixbuf are glib, gtk+ and the image libraries, so it is no more of a problem to compile than imlib. The current way we use imlib doesn't exploit any of its caching functionality, and fits what gdk-pixbuf provides quite nicely. What do you think? FWIW I work with a research project that is migrating our visual interface for the same reasons. By projecting ahead, we're ready to run with gdk-pixbuf when it and the gnome canvas widget are fully integrated. Since gnome will rely so heavily upon gdk-pixbuf I wouldn't be too concerned about the user base not having the library, or having it readily accessible very soon. On another issue, I haven't looked at your code, but I assume you're still using the DiaCanvas as your main widget. On Arjan Molenaar's web site the latest version is 0.40.0 of November 6 1999. Do you have an updated version of the widget in CVS? -- Rick L. Vinyard, Jr.
Re: Polyshape improvement
On 12 Apr 2000, Lars Clausen wrote: On Thu, 13 Apr 2000, [EMAIL PROTECTED] wrote: I just checked in a few more distance algorithms to geometry.c, and made the new polyshape use the polygon distance algorithm. The polyshape is now much nicer to work with :) You too? I put mine in polyshape itself, though. The stuff in lib/polyshape.c seemed to only look at distance from the edges. Interior points were not returning a distance of 0. My code fixes this. I also checked in some functions for bezier and ellipse distances, which should be enough to help write a correct distance algorithm for the custom shape code, which will be much better than the current bounding box distance algorithm currently in use. That's good; How easy would it be to transfer the bezier distance to a polycurve/beziergon/whachammacallit? Here are the bezier distance algorithm prototypes. You can do both open bezier lines and closed beziergons (or whatever you call them :) /* bezier distance calculations */ extern real distance_bez_seg_point(Point *b1, Point *b2, Point *b3, Point *b4, real line_width, Point *point); extern real distance_bez_line_point(BezPoint *b, guint npoints, real line_width, Point *point); extern real distance_bez_shape_point(BezPoint *b, guint npoints, real line_width, Point *point); I should probably get lib/bezierconn.c to use these distance functions. They should be fairly easy to use for your beziergon object though. -Lars James.
Re: Should we drop the imlib dependency alltogether?
On Wed, 12 Apr 2000, [EMAIL PROTECTED] wrote: On Wed, Apr 12, 2000 at 09:23:03PM -0500, Lars Clausen wrote: On Thu, 13 Apr 2000, [EMAIL PROTECTED] wrote: I was wondering what people think of the idea of dropping imlib support in dia altogether in favour of gdk-pixbuf. The next version of I think we should keep it for now, since a lot of people will have imlib compiled but not gdk-pixbuf... on the other hand, it's better to get the changes out early. Code-wise, it doesn't matter much. #ifdef USE_IMLIB do_it_the_old_broken_way (); #else do_it_the_new_way_with_pixbuf (); #endif And of course use autoconf; if pixbuf is found, don't use imlib. (Of course I have a big mouth and I'm not writing any code, but this looks to me like the correct way to make progressive changes, specially when backwards compatibility is concerned.) Way ahead of you:) That's the way it is now. The question is when we should remove imlib support altogether. -Lars -- Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause) | Hårdgrim of Numenor "I do not agree with a word that you say, but I| Retainer of Sir Kegg will defend to the death your right to say it."| of Westfield --Evelyn Beatrice Hall paraphrasing Voltaire | Chaos Berserker of Khorne
Re: Polyshape improvement
On Thu, 13 Apr 2000, [EMAIL PROTECTED] wrote:
On 12 Apr 2000, Lars Clausen wrote:
On Thu, 13 Apr 2000, [EMAIL PROTECTED] wrote:
I just checked in a few more distance algorithms to geometry.c, and
made the new polyshape use the polygon distance algorithm. The
polyshape is now much nicer to work with :)
You too? I put mine in polyshape itself, though.
The stuff in lib/polyshape.c seemed to only look at distance from the
edges. Interior points were not returning a distance of 0. My code
fixes this.
That's how it was, until today. I also implemented a proper interior-point
detection algorithm (both, in fact, though I haven't tested the winding
version). Check an update.
Here are the bezier distance algorithm prototypes. You can do both open
bezier lines and closed beziergons (or whatever you call them :)
/* bezier distance calculations */
extern real distance_bez_seg_point(Point *b1, Point *b2, Point *b3, Point *b4,
real line_width, Point *point);
extern real distance_bez_line_point(BezPoint *b, guint npoints,
real line_width, Point *point);
extern real distance_bez_shape_point(BezPoint *b, guint npoints,
real line_width, Point *point);
I should probably get lib/bezierconn.c to use these distance functions.
They should be fairly easy to use for your beziergon object though.
Very nice! That means once the polygon is ready (still have problems with
the connectionpoints), it'll be trivial to do the beziergon.
One thing about bezier{line,gon}: The two control lines around a point are
currently joined together. Is anybody interested in having the ability to
break them apart so they can move independently? (Or did I ask this
already?) It's almost, but not quite, trivial.
-Lars
--
Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause) | Hårdgrim of Numenor
"I do not agree with a word that you say, but I| Retainer of Sir Kegg
will defend to the death your right to say it."| of Westfield
--Evelyn Beatrice Hall paraphrasing Voltaire | Chaos Berserker of Khorne
Re: Should we drop the imlib dependency alltogether?
On Wed, 12 Apr 2000, Rick L. Vinyard, Jr. wrote: James Henstridge wrote: I was wondering what people think of the idea of dropping imlib support in dia altogether in favour of gdk-pixbuf. The next version of gdk-pixbuf drops the libart dependency, so the only libraries required to build gdk-pixbuf are glib, gtk+ and the image libraries, so it is no more of a problem to compile than imlib. The current way we use imlib doesn't exploit any of its caching functionality, and fits what gdk-pixbuf provides quite nicely. What do you think? FWIW I work with a research project that is migrating our visual interface for the same reasons. By projecting ahead, we're ready to run with gdk-pixbuf when it and the gnome canvas widget are fully integrated. Since gnome will rely so heavily upon gdk-pixbuf I wouldn't be too concerned about the user base not having the library, or having it readily accessible very soon. On another issue, I haven't looked at your code, but I assume you're still using the DiaCanvas as your main widget. On Arjan Molenaar's web site the latest version is 0.40.0 of November 6 1999. Do you have an updated version of the widget in CVS? The DiaCanvas is actually a modification of what Dia uses. I haven't actually looked at DiaCanvas though. As for gdk-pixbuf support, dia currently uses it if it is available in preference to imlib (this support is a bit broken after Federico's big gdk-pixbuf changes (which removed the libart dependency and made GdkPixbuf an opaque structure)). -- Rick L. Vinyard, Jr. James.
[PATCH] Function structure update
I've updated the FS module to include undo information
and the flow lines should work now. The patch should
apply cleanly to dia-0.82 and the CVS version. If you
have any problems with it please let me know. Thanks
for your patience with my glacially slow progress.
Because the patch is short, I'm including it in the
message. Is there somewhere else I should be sending
it?
David
diff -N -u -r dia-0.82/objects/FS/flow-ortho.c dia-0.82-patched/objects/FS/flow-ortho.c
--- dia-0.82/objects/FS/flow-ortho.cThu Nov 11 18:30:24 1999
+++ dia-0.82-patched/objects/FS/flow-ortho.cTue Feb 29 14:45:32 2000
@@ -1,70 +1,10 @@
-/* Dia -- an diagram creation/manipulation program
- * Copyright (C) 1998, 1999 Alexander Larsson
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
- */
-#include assert.h
-#include gtk/gtk.h
-#include math.h
-#include string.h
-#include stdio.h
-
-#include "config.h"
-#include "intl.h"
-#include "object.h"
-#include "connection.h"
-#include "render.h"
-#include "handle.h"
-#include "arrows.h"
-#include "diamenu.h"
-#include "text.h"
-#include "orth_conn.h"
-
+#include "flow-ortho.h"
#include "pixmaps/orthflow.xpm"
Color orthflow_color_energy = { 1.0f, 0.0f, 0.0f };
Color orthflow_color_material = { 0.8f, 0.0f, 0.8f };
Color orthflow_color_signal = { 0.0f, 0.0f, 1.0f };
-typedef struct _Orthflow Orthflow;
-typedef struct _OrthflowDialog OrthflowDialog;
-
-typedef enum {
- ORTHFLOW_ENERGY,
- ORTHFLOW_MATERIAL,
- ORTHFLOW_SIGNAL
-} OrthflowType;
-
-struct _Orthflow {
- OrthConn orth ;
-
- Handle text_handle;
-
- Text* text;
- OrthflowType type;
-};
-
-struct _OrthflowDialog {
- GtkWidget *dialog;
-
- GtkWidget *text;
-
- GtkWidget *m_energy;
- GtkWidget *m_material;
- GtkWidget *m_signal;
-};
#define ORTHFLOW_WIDTH 0.1
#define ORTHFLOW_MATERIAL_WIDTH 0.2
@@ -117,14 +57,15 @@
(SaveFunc) orthflow_save,
(GetDefaultsFunc)orthflow_get_defaults,
(ApplyDefaultsFunc) orthflow_apply_defaults
+
} ;
ObjectType orthflow_type =
{
- "FS - Orthflow", /* name */
- 0, /* version */
- (char **) orthflow_xpm, /* pixmap */
- orthflow_type_ops /* ops */
+ "FS - Orthflow", /* name */
+ 0, /* version */
+ (char **) orthflow_xpm, /* pixmap */
+ orthflow_type_ops /* ops */
};
static ObjectOps orthflow_ops = {
@@ -140,6 +81,54 @@
(ObjectMenuFunc) orthflow_get_object_menu,
};
+void orthflow_change_apply_revert( ObjectChange* objchg, Object* obj )
+{
+ struct _OrthflowChange* change = (struct _OrthflowChange*) objchg ;
+ Orthflow* oflow = (Orthflow*) obj ;
+
+ if ( change-change_type == FLOW_TYPE || change-change_type == BOTH ) {
+OrthflowType type = oflow-type ;
+oflow-type = change-type ;
+change-type = type ;
+orthflow_update_data(oflow) ;
+ }
+
+ if ( change-change_type TEXT_EDIT || change-change_type == BOTH ) {
+char* tmp = text_get_string_copy( oflow-text ) ;
+text_set_string( oflow-text, change-text ) ;
+g_free( change-text ) ;
+change-text = tmp ;
+ }
+}
+
+void orthflow_change_free( ObjectChange* objchg )
+{
+ struct _OrthflowChange* change = (struct _OrthflowChange*) objchg ;
+
+ if (change-change_type TEXT_EDIT || change-change_type == BOTH ) {
+g_free(change-text) ;
+ }
+}
+
+static ObjectChange*
+orthflow_create_change( enum OrthflowChangeType change_type,
+ OrthflowType type, Text* text )
+{
+ struct _OrthflowChange* change ;
+ change = g_new( struct _OrthflowChange, 1 ) ;
+ change-obj_change.apply = (ObjectChangeApplyFunc) orthflow_change_apply_revert ;
+ change-obj_change.revert = (ObjectChangeRevertFunc) orthflow_change_apply_revert ;
+ change-obj_change.free = (ObjectChangeFreeFunc) orthflow_change_free ;
+ change-change_type = change_type ;
+
+ change-type = type ;
+ if ( text ) {
+change-text = text_get_string_copy( text ) ;
+ }
+
+ return (ObjectChange*) change ;
+}
+
static real
orthflow_distance_from(Orthflow *orthflow, Point *point)
{
@@ -266,7 +255,7 @@
Object *obj;
Point p;
- orthflow = g_malloc(sizeof(Orthflow));
+ orthflow = g_new(Orthflow,1);
orth = orthflow-orth ;
orthconn_init( orth, startpoint ) ;
@@ -311,12 +300,13 @@
Re: Polyshape improvement
James Henstridge wrote: That's good; How easy would it be to transfer the bezier distance to a polycurve/beziergon/whachammacallit? Here are the bezier distance algorithm prototypes. You can do both open bezier lines and closed beziergons (or whatever you call them :) The graphics community tends to call them spline patchs/surfaces (or implicit surfaces). This refers to the different types of splined surfaces that can be created (NURBS and Bezier are just two of a whole class of different things, 2D or 3D surfaces, defined by functional means rather than verticies). For the 2D case here, just call them Bezier Patches. -- Justin Couch Author, Java Hacker Snr Software Engineer [EMAIL PROTECTED] rbuzz.net http://www.vlc.com.au/~justin/ Java3D FAQ http://www.j3d.org/faq/ --- "Look through the lens, and the light breaks down into many lights. Turn it or move it, and a new set of arrangements appears... is it a single light or many lights, lights that one must know how to distinguish, recognise and appreciate? Is it one light with many frames or one frame for many lights?" -Subcomandante Marcos ---
Re: Polyshape improvement
On 12 Apr 2000, Lars Clausen wrote:
That's how it was, until today. I also implemented a proper interior-point
detection algorithm (both, in fact, though I haven't tested the winding
version). Check an update.
Are you sure you have commited this? This is the change I made to
polyshape.c:
--- lib/polyshape.c 2000/04/11 23:45:37 1.4
+++ lib/polyshape.c 2000/04/13 00:55:46 1.5
@@ -137,18 +137,8 @@
real
polyshape_distance_from(PolyShape *poly, Point *point, real line_width)
{
- int i;
- real dist;
-
- /* FIXME: Need winding rule or something */
- dist = distance_line_point( poly-points[0], poly-points[1],
- line_width, point);
- for (i=1;ipoly-numpoints-1;i++) {
-dist = MIN(dist,
- distance_line_point( poly-points[i], poly-points[i+1],
- line_width, point));
- }
- return dist;
+ return distance_polygon_point(poly-points, poly-numpoints,
+ line_width, point);
}
static void
[snip]
Very nice! That means once the polygon is ready (still have problems with
the connectionpoints), it'll be trivial to do the beziergon.
One thing about bezier{line,gon}: The two control lines around a point are
currently joined together. Is anybody interested in having the ability to
break them apart so they can move independently? (Or did I ask this
already?) It's almost, but not quite, trivial.
That is probably a good idea. There are three ways to handle the control
lines - cusp (the two control points are independent), smooth (two control
points are on the same line) and symmetric (the current behaviour). It
would probably be nice to allow the user to change the behaviour for each
point on a bezierconn.
To keep compatibility, symmetric would have to be the default.
-Lars
James.
Re: Should we drop the imlib dependency alltogether?
James Henstridge wrote: The DiaCanvas is actually a modification of what Dia uses. I haven't actually looked at DiaCanvas though. Gotcha. I was under the impression that it was a separate component developed by the Dia developers and was broken out separately. As for gdk-pixbuf support, dia currently uses it if it is available in preference to imlib (this support is a bit broken after Federico's big gdk-pixbuf changes (which removed the libart dependency and made GdkPixbuf an opaque structure)). I see, I didn't read the question carefully enough. I interpreted it as when should migration begin as opposed to what was actually asked. It broke some of our code too, but wasn't too bad to fix. Ahhh, life on the CVS bleeding edge. -- Rick L. Vinyard, Jr.
Dia Documentation Project?
Just went looking for more documentation about how to use Dia (even Dia-Hacking-Howto:) and got 404'd on the link. What is the state of this area? Has someone put together a FAQ for the project? (I reckon I could contribute at least 5 questions just from 2 days of fulltime usage!) -- Justin Couch Author, Java Hacker Snr Software Engineer [EMAIL PROTECTED] rbuzz.net http://www.vlc.com.au/~justin/ Java3D FAQ http://www.j3d.org/faq/ --- "Look through the lens, and the light breaks down into many lights. Turn it or move it, and a new set of arrangements appears... is it a single light or many lights, lights that one must know how to distinguish, recognise and appreciate? Is it one light with many frames or one frame for many lights?" -Subcomandante Marcos ---
Re: Should we drop the imlib dependency alltogether?
On Wed, Apr 12, 2000 at 10:19:07PM -0500, Lars Clausen wrote: On Wed, 12 Apr 2000, [EMAIL PROTECTED] wrote: #ifdef USE_IMLIB do_it_the_old_broken_way (); #else do_it_the_new_way_with_pixbuf (); #endif Way ahead of you:) That's the way it is now. The question is when we should remove imlib support altogether. If that's the way it is, it is not broken, so don't fix it :-) When supporting the Imlib compatibility code becomes a burden, or pixbuf is known to be widely used (which is about 1.5 months after a version of gnome-core linked with pixbuf is declared stable enought for end-users release), remove it. Or in short: when maintaining it becomes a bigger pain than removing it. []s, |alo + -- Hack and Roll ( http://www.hackandroll.org ) News for, uh, whatever it is that we are. http://www.webcom.com/lalo mailto:[EMAIL PROTECTED] pgp key in the personal page Brazil of Darkness (RPG)--- http://zope.gf.com.br/BroDar
