April 2007 - Inkscape Devel - Inkscape Mailman

Re: [Inkscape-devel] gcc 3.3 bug: configure -Wno-pointer-sign test uses wrong compiler
by John Faith 24 Apr '07

24 Apr '07

jiho wrote > looking into compiling Inkscape on Mac OS X 10.3 an error appeared > which is apparently not limited to OS X but more generally to old gcc > versions (3.3 is used here). John Faith, the investigator of these > issues, submitted a patch to configure.ac which fixes this. I am not > knowledgeable enough with autoconf to review this. Could someone > knowledgeable have a look at it and commit it or give me a go to > commit this? Hello, I was curious if anyone had a chance to think about this bug or if anyone had a minute to try a quick experiment. In configure.ac, there is a block used to check if gcc can use -Wno-pointer-sign in CFLAGS. Unfortunately, the "AC_LANG(g++)" means that g++ is used for this compile test when gcc should be used, CLFLAGS is ignored, and the test always passes. For gcc4 this doesn't matter, but this breaks gcc3 when building in src/libcroco. If anyone with gcc 3 or 4 could try a reconfigure, that would be helpful to see if this fixes other environments with gcc <4 and also does not break gcc4. Adding "AC_LANG_PUSH(C)" and "AC_LANG_POP" around the AC_COMPILE_IFELSE in configure.ac seems to fix this problem (see attached patch which is also in tracker #1702352). I've tried this patch on gcc3.3 OS 10.3.9. After changing configure.ac, run ./autogen.sh then ./configure. For gcc<4, the final bit of configure output should not have -Wno-pointer-sign in CFLAGS. Thanks in advance! , John

1 1

[PATCH] Dockable dialogs, and some concerns...
by Gustav Broberg 23 Apr '07

23 Apr '07

Hi all, I've been busy with work since the release of 0.45, but now I have finally found some time to spend on Inkscape again... :) I have uploaded a patch to the tracker which is a first attempt to implement dockable dialogs/panels using gdl (Gnome development library). http://sourceforge.net/tracker/index.php?func=detail&aid=1688508&group_id=9… The patch adds a dockable pane to the desktop on which any GTKmm:ified dialog can be docked. Here are some screenshots showing what it's all about: http://wiki.inkscape.org/wiki/index.php/Image:Dock_patch_1.png http://wiki.inkscape.org/wiki/index.php/Image:Inkscape_dock2.png To compile you'll need gdl >= 0.6.1, the latest version is available here: http://ftp.gnome.org/pub/GNOME/sources/gdl/0.7/gdl-0.7.2.tar.bz2 Gdl is a fairly small UI library developed for IDE:s such as Anjuta. The main thing it provides is a set of components to build dockable interfaces. I realize that it would be better to do this without an additional library, but right now I think gdl is the best option assuming that we want a dockable interface. The pros of using gdl, as I see it, are: * It provides a lot for free. Dockable items (dialogs in this case) can be attached and detached to docks, iconified to dock bars and docked to each other as separate floating groups. Furthermore they can be stacked as notebook tabs, and complete layouts can be saved/restored from disk (I haven't got that one working, though). It would require a major amount of work to reproduce the docking functionality found in gdl. * It's still actively developed. Inkscape could benefit from the new functionality added to gdl. ...and the cons: * It's yet another library, with all the problems that brings. The availability could be an issue. Distributions that provide Anjuta or Screem should have gdl in their repos as well. Merging gdl into Inkscape's tree is probably a bad idea... * I haven't tried it on win32 or Mac OS X, so I'm not sure about the compatibility. It used to require some gnome only libraries, but it doesn't anymore from what I know. * It's a C library. There is a C++ wrapper called gdlmm, but it hasn't been worked on since 2005, and I'm not sure how complete/stable it is. The only alternative to gdl that I know of is CurlyAnkles. It has the same issues with availability and compatibility as gdl, but is less mature (I'm not aware of any project that uses it yet). On the positive side it provides other widgets that could improve Inkscape's interface. As for the design I've chosen to keep the current UI::Dialog::Dialog hierarchy as opposed to extending UI::Widget::Panel, which I guess was planned to be the root class of everything dockable (?). The main reasons for this were that I wanted to keep the old dialog behavior as an option and also that I wanted to avoid rewriting the code of the current dialogs. The way I did this was to break out much of the functionality of Dialog::Dialog into the implementations of an interface Dialog::Behavior. The implementations that extends it are FloatingBehavior (the current dialog behavior) and DockBehavior. Each dialog is instantiated with a behavior and the DialogManager handles them the same way as before, regardless of behavior. The Dialog::Behavior interface covers most of the functionality of Gtk::Dialog. FloatingBehavior is just a proxy for a real Gtk::Dialog (just as before), while DockBehavior tries to emulate the dialog functionality on a GdlDockItem. This allows all the current dialogs (under UI::Dialog) to be dockable without rewriting them. A global preference "options.dialogtype" controls what the kind of dialogs to create (0 = old/floating, 1 = new/dock). It's still a work in progress, and I'd be glad to get feedback on the design, etc. (The class naming could probably be more accurate/consistent, for instance.) There's a bunch of known bugs, but I'm not experiencing any major ones right now. I've probably broken something that used to work with the floating dialogs, though. Please note that this patch only works for the GKmm:ified dialogs under UI::Dialog, so dialogs such as Fill&Stroke and the XML editor won't be dockable. If there's an interest in working on this, I could create a branch, otherwise I'll just drop patches as I proceed. (I intend to continue to keep it up to date even if there's no plan to merge it -- Inkscape is pretty much unusable without it for me when using my primary window manager :) I'll be on the IRC channel in a near future if anybody would like to discuss this further... -- Gustav

17 46

Fonts under Linux
by Donn 23 Apr '07

23 Apr '07

Hello, Up too late, must retire soon, a quick question if you will? I use Kubuntu (Dapper), but I reckon this will apply to a lot of distros: Where do all the installed system fonts live? I know that is simplistic and it has to do with fontconfig and a tonne of config files and a million type1 fonts in a bajillion folders, but can anyone get me started on the big picture? I'm asking because my little project, FontyPython, revolves around managing fonts etc. One of the most irksome things is to have fonts in a chooser (like under Inkscape) that I do not want there. For example, if I have *zero* fonts in my ~/fonts directory, and I run Inkscape, I have about 600 fonts listed in the chooser! That's just plain nuts! Man, that's cashew nuts, with salt! So, I am pondering (vs sleeping, which I should be doing) about ways to lessen this clutter and write a 'cleanup' script that can remove them from the system -- not delete them, just uninstall them or whatever the term is. I can't even find them by locate or find. There's one called "Christian Participants" which is the fugliest thing I have ever seen and I cannot even find the file on the drive, let alone uninstall it! So, anyone with a clue? have mercy on me :) /d -- I can bend minds with my spoon. -- unknown

3 3

Grids in development versions
by Michael Grosberg 21 Apr '07

21 Apr '07

Are the new grids still being worked on? I noticed that, using the new XYgrid, if you set the "major grid line" option to anything other than 5, they will show up correctly as long as all grid lines are in view, but if you zoom out to a view in which only the major grid lines should show, they will revert to a value of one major line every 5 grid lines.

2 2

Inkscape in top Apple downloads
by jiho 21 Apr '07

21 Apr '07

Hello everybody, Just a quick note to let you know that Inkscape is featured in the top downloads of the UNIX & Open source section of Apple.com, only behind OpenOffice, Gimp, Emacs, an OS X specific X11 utility, and Apache. A nice achievement in my opinion and many thanks to all developers who made all the great features Inkscape is known for (and now it's up to Micahel and me to make it even more Mac OS X friendly because the screenshot there does not look too engaging...). http://www.apple.com/downloads/macosx/unix_open_source/ JiHO --- http://jo.irisson.free.fr/

2 1

Help needed to fight spam in forums and wiki
by bulia byak 20 Apr '07

20 Apr '07

Hi all, We need volunteers! There's quite some spam in our forums: http://sourceforge.net/forum/?group_id=93438 Also, around Apr 11-12, we had an invasion of vandals deleting stuff on wiki: http://wiki.inkscape.org/wiki/index.php?title=Special:Recentchanges&limit=2… We need your help to weed this out. On wiki, you just need to register as usual to be able to revert vandalism; you can also request admin powers from Aho at strange-a at users.sourceforge.net to make it easier. On forums, you need a sourceforge account first, then please contact Bryce for granting you admin access to the forums. Thanks! -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

4 3

cairo 1.4.4 on win32 does not work
by Adib Taraben 20 Apr '07

20 Apr '07

Ishmal, I tried your cairo 1.4.4 that I saw this morning :-) The new libs does not work as expected. (I use your provided libs also in my own application to create some pdf report) I am not shure if this is caused by the optimisations in cairo or by your compilation. However thx. for the win32-libs Hope my report is somehow usefull, Adib. -- In my own application where I use your cairo libs it throws an SIGSEV somewhere on cairo_create(surface). As I use codeblocks as IDE I do not know how to copy a backtrcae from the list. The last entries are ntdll!WaitForCriticalSection, cairo_color_white(), msvrt!free(), ntdll!AppendStringToString(), msvcrt!free() however Inkscape dies as follow 0x7c928fea in ntdll!RtlpWaitForCriticalSection () from ntdll.dll (gdb) bt #0 0x7c928fea in ntdll!RtlpWaitForCriticalSection () from ntdll.dll #1 0x03c0d110 in ?? () #2 0x03c0d110 in ?? () #3 0x03c0d110 in ?? () #4 0x00000004 in ?? () #5 0x627449a3 in _libmsvcrt_a_iname () from D:\projekte\inkscape\inkscape\inkscape\libgobject-2.0-0.dll #6 0x00000000 in ?? () from #7 0x03c25110 in ?? () #8 0x0022e578 in ?? () #9 0x00000000 in ?? () from #10 0x00000000 in ?? () from #11 0x00000000 in ?? () from #12 0x0022e578 in ?? () #13 0x627466f7 in _libmsvcrt_a_iname () from D:\projekte\inkscape\inkscape\inkscape\libgobject-2.0-0.dll #14 0x03c25110 in ?? () #15 0x7c97e0f8 in ntdll!RtlpNtMakeTemporaryKey () from ntdll.dll #16 0xffffffff in ?? () #17 0x7c97e0d4 in ntdll!RtlpNtMakeTemporaryKey () from ntdll.dll #18 0x7c95a5d0 in ntdll!RtlInsertElementGenericTableAvl () from ntdll.dll #19 0x00240000 in ?? () #20 0x50000061 in ?? () ---Type <return> to continue, or q <return> to quit--- #21 0x03be9610 in ?? () #22 0x00240000 in ?? () #23 0x002595c8 in ?? () #24 0x40000060 in ?? () #25 0x00000000 in ?? () from #26 0x0022e5c0 in ?? () #27 0x00000000 in ?? () from #28 0x00000000 in ?? () from #29 0x00000688 in ?? () #30 0x0022e518 in ?? () #31 0x7c91104b in ntdll!RtlEnumerateGenericTableLikeADirectory () from ntdll.dll #32 0x000bc0a0 in ?? () #33 0x010939a3 in _cairo_scaled_font_map_lock () at src/cairo-scaled-font.c:195 Previous frame inner to this frame (corrupt stack?) (gdb)

2 4

Build failures on OS X 10.3.9: isnan, isinf, etc.
by John Faith 19 Apr '07

19 Apr '07

Hello, I've been looking at building source from SVN on OS X 10.3.9 and I've found these problems: - configure.ac uses g++ instead of gcc when testing for -Wno-pointer-sign support (ignoring $CFLAGS) and gcc3 dies in libcroco. Already reported by jiho. - isnan undeclared in src/libcola/cola.cpp. I worked around this by changing "isnan" to "isNaN" since the latter is defined in isnan.h, though I'm not sure this makes sense for all platforms. - libcola/gradient_projection.cpp:54 isinf undefined. Adding '#include <math.h>' fixes this. There are several issues for isnan already in the tracker, so my question is: are these new problems (requiring new bugs created), or the same as earlier bugs? - Although configure apparently finds msgfmt, In po/Makefile, both $MSGFMT and $GMSGFMT are empty. When make hits the '.po.gmo:' target, it complains "-o: command not found" since part of the command is "$(GMSGFMT) -o $$file $<". Has anyone run into this? Thanks!, John

3 2

Problems with new axonometric grid?
by Maximilian Albert 19 Apr '07

19 Apr '07

Hi Johan and everyone, first of all thanks a lot for your work on the grids!! Today I wanted to give the new functionality a try and was a bit stuck, however. Maybe this should go to the bug tracker directly but what I experienced seemed so weird that I thought I'd ask for other people's experience first, since I reckon that Johan would have realized if he had encountered this behaviour, too. Maybe I got something completely wrong, although I don't see what this should be. The rectangular grid works like a charm. But when I create an axonometric grid instead, I cannot get the pen tool, say, to snap to any of the intersections of the grid lines. Instead, it snaps to seemingly random points in between. Also, with "always snap" enabled, the mouse pointer doesn't cleanly jump from one intersection point to the next but shows a kind of "juddering" behaviour, as if it was snapping to some invisible (smaller) grid that's not precisely aligned with the visible one. When "always snap" is unchecked and very small sensitivities are chosen, it seems to work better, but the precise snapping points are still missed to a certain extent. Furthermore, when assigning a different color to the major grid lines, they are not drawn as continuous lines but only segment-wise and at irregular distances. To me it looks as if the regular grid lines were repainted with the new color, but since both lines are located at the same positions, sometimes one color dominates and sometimes the other. (This may also explain why the segments seem to change when zooming out.) Has anyone else seen this or is it just me? Does this work correctly for you, Johan? I was experimenting with the latest svn version (revision #14815), but this seems to occur with older (yet recent) versions, too. Please tell me if you want me to add this to the bug tracker. Thanks for your help! Cheers, Max P.S.: Wouldn't it make sense to have different colors for regular and major grid lines by default? And IMHO the default spacing for the axonometric grid should be larger than 1.

5 7

Kind reminder from your dedicated LGM organisation !!!
by Louis Desjardins 19 Apr '07

19 Apr '07

Hello all LGM participants and speakers, If you haven't done so yet, please, please take a few secs to register for LGM at http://www.libregraphicsmeeting.org/signup.html This is the best way to help me in the late stages of this big organisation, make sure we have enough food and drink, make sure we can accommodate everyone, etc. Many thanks in advance and looking forward to welcome you in Montréal! Louis p.s. Please forward this message to any list you might think it be important to send it. -- Louis Desjardins Organisateur / Organiser Libre Graphics Meeting 2007 - Montréal www.libregraphicsmeeting.org/fr www.libregraphicsmeeting.org +1 514 934 1353 HAE / EDT GMT -4

1 0