- Inkscape Devel - Inkscape Mailman

3D box tool
by Dave & Ann Marie Barry 30 Mar '07

30 Mar '07

Hi All, I've spoken with Máirín Duffy about helping out with the 3D box tool listed in the google summer of code project list. I'm a full time engineer, and I'm sure I could handle the vector math work and support functions. However, I'm not a GUI/application programmer. What do you think? Dave Barry

2 1

Inkscape go-slow issues redux
by Donn 29 Mar '07

29 Mar '07

Inkscape Issues Date : Started this on 28 March 2007 Version : 0.45.1 self-compiled on Kubuntu Dapper (32 bit version) Machine : Brand new AMD 64x2, Gigabyte m/b, 1 gig DDR2 RAM, lots of drive space (old IDE drives), PCI-Express nvidia card of no particular specs. (My old machine literally went boom!) I reported this slowing-down on my last machine (an old AMD 1 ghz) on the inkscape-users list. I was very surprised to see the same thing on my new machine. I apt-get installed the build requirements (as per the Inkscape wiki) and compiled 0.45.1 to see if that would boost performance, it *was* much quicker but the slow-down still happens. Inkscape starts nice and fast. For example panning is very quick, even with a complex drawing. After a time, perhaps 20/30 minutes, the panning becomes choppy and then unusable. I find it quicker to zoom out and zoom-in to a new area than to pan across to it. After a time the GTK dialogs start to draw very slowly. I have noticed this on: 1. The fill/stroke dialog (particular culprit) 2. The Doc properties 3. The Global prefs 4. Export sub-dialogs like the 'confirm file replace' dialogue. 5. Now and then on the Font dialog After they begin to 'go slow' they quickly stop working at all. I often get blank forms (see attached -- assuming it does not get stripped.) BTW - This is the only GTK app that does this. Pan, Gimp, Tomboy, FontyPython, Firefox all work fine, if slowly. When I feel Inkscape slowing, I save and restart it. Inkscape can take up to 30 seconds to close. The entire machine is non-responsive during that time. Music playing usually stutters and while the mouse will move around, nothing can be clicked or dragged. Is there something I can do to help diagnose this? Can I compile with other flags (I am clueless about gcc/g++) in order to produce debug info or something? Or perhaps there is a trick to track memory useage to a logfile that I can post? Could this issue be a problem with the quality of the supporting libraries as released on Kubuntu Dapper? I have always thought GTK apps were easily half the speed of QT apps on Kubuntu Dapper (and before that Fedora Core 1 and 3). Please let me know what I can do to help, I am not well so I often fall off the net, but I thought I needed to let you know about my experiences. Donn.

7 34

Re: [Inkscape-devel] SoC 3D box tool - website updated
by Maximilian Albert 29 Mar '07

29 Mar '07

Thorsten Wilms schrieb: > You can't have a box without VPs and VPs are useless if there is no > box. Hmm, to me a perspective is essentially _defined_ by the position/arrangement of its VPs. It seems to me that we have different understandings of the term. What do you mean by perspective then? How would you add and modify perspectives without using VPs? Also, given my point of view I don't agree that VPs without a box are useless. Rather, they define a perspective, which you can use to draw boxes whose edges (or rather their prolongations) meet in the respective VPs, i.e. essentially to draw boxes _in the given perspective_, from a visual POV. Note that I use the term 'perspective' in a slightly broader sense than usual here, for it also covers arrangements like the one you entitled as 'impossible' (the second picture in the 'core' section on the website). Again, it's nothing else than a configuration of VPs. > Additionaly the VPs of a perspective share a horizon. Well, they certainly do. But I can't see why a horizon makes working with boxes cumbersome, especially since it's supposed to be only a kind of add-on to make things more convenient, but it's certainly not required for drawing boxes (and can probably be toggled to be off by default). I still think I'm misreading you here because I don't know your precise definition of a perspective. > Regarding adding a box by dragging, I'm a bit concerned about the > need for 3 drags in a row. It's only two, actually. ;) One drag for the "front" face, and one drag to add depth. > Simply adding a box with default size > would work around this (where the 'default' size should actually > take the zoom level into account). Hmm, but you don't need perspectives as separate modifiable objects to achieve that. Just add a button or a menu item or whatever to create such a box in the given configuration of VPs. > If any number of boxes can be tied to a 3-VP/horizon system, > I think this clearly establishes that there are separate entities. > The user can't form the right expectations if you try to cover this > up. True. We are definitely not going to cover it up. But I think it should remain to be seen how much _functionality_ for working with perspectives alone (without a box) we need to provide. Can't tell at the moment, tough. > Well, where I said 2 VPs, I actually meant 2 'finite' and one 'infinite', > as I have a hard time thinking of a point if I see parallel lines ;) Granted. I normally don't realize how much my studies of mathematics influence my thinking about these things. ;) > 'have to be' is maybe a bit hard, but say you have 3 boxes, all on the > same plane. 2 have parallel edges, the 3rd is rotated. The 2 share all > 3 VPs, but the 3rd only has the nadir in common with them. > For additional boxes, you could choose between 2 groups of VPs (or > create additional VPs). Ah, now I see what you mean. But which are the two groups? If I'm reading you correctly then you are suggesting to have one group of VPs for the two boxes with parallel edges, and a separate group for the third box, each of which you can choose for drawing new boxes. Is that right? But this is precisely the concept that I have in mind when talking about 'perspectives'. In my wording, a perspective is precisely such a group of three VPs (maybe some of them at infinity) which can be used to draw new boxes whose edges point in the directions of the VPs. So you could simply select one of the three boxes and define its 'perspective' as the default for the new box. Is this what you have in mind? Or did I get it completely wrong? Max

1 0

SoC 3D box tool - website updated
by Maximilian Albert 29 Mar '07

29 Mar '07

Hi all, for my official SoC application I have considerably updated the website describing my thoughts on the 3D box tool. It now includes some ideas for advanced features and future work (outside the scope of SoC itself). It is far from being complete, but anyone who is interested is warmly invited to have a look and make comments, praise it or goof on it. Here is the URL once again: http://www.rzuser.uni-heidelberg.de/~malbert/ In any case, I really hope that my application may be successful. Contributing to your great work would be a huge pleasure and honour for me. Thanks and cheers, Max

2 1

Compiling with btool on Windows Vista
by Joel Holdsworth 29 Mar '07

29 Mar '07

Hi Everyone, I'm just in the process of trying to get involved with the development of inkscape, and I've spent the last few weeks trying to compile it by various methods. The btool method (as suggested here http://wiki.inkscape.org/wiki/index.php/Win32Port), is the simplest way, and in the end, the only way I can see to compile inkscape in Windows (although I have tried several approaches). Inkscape can be compiled no problem on a fresh install of Windows XP - I tried it on Virtual PC this morning. However, (and you may already be aware of this), it does not compile properly on Windows Vista, my main OS. First, mingwenv.bat runs successfully, whether running in an administrator or normal console. But there's hitch on the next step. The problem relates to g++ I think. If I do the step: "g++ buildtool.cpp -o btool", I get back the response "g++: _spawnvp: No such file or directory". It is possible to get past this step by compiling with btool with cygwin. However once you try and run btool.exe, you get the output printed below, which you may notice contains the killer line "i686-pc-mingw32-g++.exe: _spawnvp: No such file or directory". I think this must all be a problem with g++ in Vista. I'm not sure how what the dev team can do, but I think the wiki should be updated at least. Best Regards Joel Holdsworth ----------------------------------------- #################################################### # BuildTool v0.6, 2006 Bob Jamison #################################################### ######## PARSE : build.xml ######## PARSE COMPLETE ######## EXECUTE ## Target : init ---- task : mkdir : build ---- task : mkdir : inkscape ---- task : copy : src/helper/sp-marshal.h.mingw to src/helper/sp-marshal.h ---- task : copy : src/helper/sp-marshal.cpp.mingw to src/helper/sp-marshal.cpp ---- task : makefile : inkscape_version.h ---- task : makefile : config.h ## Target : compile ---- task : cc : regenerating C/C++ dependency cache : compile of build/obj/arc-context.o required by src/arc-context.cpp ============ cmd ============ i686-pc-mingw32-g++ -c -Wall -O3 -mms-bitfields -DVERSION=\"0.45.1\" -DHAVE_CONFIG_H -DXP_WIN -D_INTL_REDIRECT_INLINE -I. -Ic:/gtk210/include -Ic:/gtk210/include/glibmm-2.4 -Ic:/gtk210/lib/glibmm-2.4/include -Ic:/gtk210/include/gtkmm-2.4 -Ic:/gtk210/lib/gtkmm-2.4/include -Ic:/gtk210/include/gdkmm-2.4 -Ic:/gtk210/lib/gdkmm-2.4/include -Ic:/gtk210/include/pangomm-1.4 -Ic:/gtk210/include/atkmm-1.6 -Ic:/gtk210/include/cairomm-1.0 -Ic:/gtk210/include/sigc++-2.0 -Ic:/gtk210/lib/sigc++-2.0/include -Ic:/gtk210/include/gtk-2.0 -Ic:/gtk210/lib/gtk-2.0/include -Ic:/gtk210/include/atk-1.0 -Ic:/gtk210/include/pango-1.0 -Ic:/gtk210/include/glib-2.0 -Ic:/gtk210/lib/glib-2.0/include -Ic:/gtk210/include/libxml2 -Ic:/gtk210/include/freetype2 -Ic:/gtk210/include/cairo -Wno-comment -Ic:/gtk210/perl/lib/CORE -Ic:/gtk210/python/include -Isrc -Isrc/application -Isrc/debug -Isrc/dialogs -Isrc/display -Isrc/dom -Isrc/dom/io -Isrc/dom/odf -Isrc/dom/svg -Isrc/dom/util -Isrc/extension -Isrc/extension/implementation -Isrc/extension/internal -Isrc/extension/internal/libwpg -Isrc/extension/script -Isrc/graphlayout -Isrc/helper -Isrc/inkjar -Isrc/io -Isrc/jabber_whiteboard -Isrc/jabber_whiteboard/dialog -Isrc/libavoid -Isrc/libcola -Isrc/libcroco -Isrc/libnr -Isrc/libnrtype -Isrc/libvpsc -Isrc/libvpsc/pairingheap -Isrc/livarot -Isrc/pedro -Isrc/removeoverlap -Isrc/svg -Isrc/trace -Isrc/trace/potrace -Isrc/ui -Isrc/ui/dialog -Isrc/ui/view -Isrc/ui/widget -Isrc/util -Isrc/widgets -Isrc/xml src/arc-context.cpp -o build/obj/arc-context.o ============================= i686-pc-mingw32-g++.exe: _spawnvp: No such file or directory Make error: exec of command 'i686-pc-mingw32-g++ -c -Wall -O3 -mms-bitfields -DV ERSION=\"0.45.1\" -DHAVE_CONFIG_H -DXP_WIN -D_INTL_REDIRECT_INLINE -I. -Ic:/gtk2 10/include -Ic:/gtk210/include/glibmm-2.4 -Ic:/gtk210/lib/glibmm-2.4/include -Ic :/gtk210/include/gtkmm-2.4 -Ic:/gtk210/lib/gtkmm-2.4/include -Ic:/gtk210/include /gdkmm-2.4 -Ic:/gtk210/lib/gdkmm-2.4/include -Ic:/gtk210/include/pangomm-1.4 -Ic :/gtk210/include/atkmm-1.6 -Ic:/gtk210/include/cairomm-1.0 -Ic:/gtk210/include/s igc++-2.0 -Ic:/gtk210/lib/sigc++-2.0/include -Ic:/gtk210/include/gtk-2.0 -Ic:/gt k210/lib/gtk-2.0/include -Ic:/gtk210/include/atk-1.0 -Ic:/gtk210/include/pango-1 .0 -Ic:/gtk210/include/glib-2.0 -Ic:/gtk210/lib/glib-2.0/include -Ic:/gtk210/inc lude/libxml2 -Ic:/gtk210/include/freetype2 -Ic:/gtk210/include/cairo -Wno-commen t -Ic:/gtk210/perl/lib/CORE -Ic:/gtk210/python/include -Isrc -Isrc/application -Isrc/debug -Isrc/dialogs -Isrc/display -Isrc/dom -Isrc/dom/io -Isrc/dom/odf -I src/dom/svg -Isrc/dom/util -Isrc/extension -Isrc/extension/implementation -Isrc/ extension/internal -Isrc/extension/internal/libwpg -Isrc/extension/script -Isrc/ graphlayout -Isrc/helper -Isrc/inkjar -Isrc/io -Isrc/jabber_whiteboard -Isrc/jab ber_whiteboard/dialog -Isrc/libavoid -Isrc/libcola -Isrc/libcroco -Isrc/libnr -I src/libnrtype -Isrc/libvpsc -Isrc/libvpsc/pairingheap -Isrc/livarot -Isrc/pedro -Isrc/removeoverlap -Isrc/svg -Isrc/trace -Isrc/trace/potrace -Isrc/ui -Isrc/ui/ dialog -Isrc/ui/view -Isrc/ui/widget -Isrc/util -Isrc/widgets -Isrc/xml src/arc- context.cpp -o build/obj/arc-context.o' failed : No such file or directory Make error: problem compiling:

1 0

Re: [Inkscape-devel] SoC 3D box tool - website updated
by Maximilian Albert 29 Mar '07

29 Mar '07

Thorsten Wilms schrieb: > Just some idea of a slightly different organisation: > - Don't have the user add VPs or a box, but a perspective > object I'm not sure if I get you right here. Why would it be more convenient to add an "abstract" perspective object rather than just adjusting some VPs with a few drags, where you can _see_ what happens? Or do you mean that you want to be able to treat perspectives as objects of their own? Internally, perspectives will be separated from boxes anyway. This makes it possible to compare perspectives for different boxes, to copy them from one box to another (here some care must of course be taken as to which corners should remain fixed), to define a default perspective, etc. But boxes are a very convenient way to define perspectives, so why not use them for this purpose? > - The perspective object could come with 2 VPs on a horizon and > one box per default. That kind of perspective will be the default when dragging a box anyway (at least, in the beginning). You may be right, however, that one could try and separate the concepts a bit more from the user's point of view, too. But only if this doesn't make things less intuitive or more complicated to grasp. I'll give it some further thoughts. > - The number of VPs would be a parameter of the perspective > object like corners are for stars/polygons. Hmm, I think the number of VPs should be three unconditionally. However, each of them should be toggleable between 'finite' and 'infinite', i.e. the PLs either meet in a point or they are parallel. This provides a way to keep track of the _direction_ of parallel PLs, too. It's just an internal thing, though. > Hmm, for setups with several boxes in different perspectives, > VPs have to be organised in groups. For what purpose exactly? Max

1 0

Re: [Inkscape-devel] Multi-page UI
by Tom Lechner 29 Mar '07

29 Mar '07

Hi, Just in case anyone's interested, I've been writing a program called Laidout to lay out cartoon books of mine. It features sort of arbitrary impositions, including the ability to have non-rectangular pages. It does make a distinction between page, paper, and also page spreads (how it looks assembled, rather than how it looks on master printing pages). No art, trim, crop, bleed, and media box tags yet though. It has a viewer window where you edit the things in the pages, and also a spread editor, where you can rearrange page orders. One of my TODO items for a long time has been to somehow port my spread editor (after it gets a little more advanced) to Inkscape. There are just not enough hours in the day! Unless you happen to be me, Laidout's probably difficult to use, as everything's still in rough, primitive stages right now, but you can get the idea from these screenshots: http://www.laidout.org/screenshots I started writing Laidout years ago as an exercise to learn how to program better. It's been a much larger endeavor than I had at first been imagining, meaning the code's rather a mess, but I do get to lay out my books pretty easily! Tom http://www.tomlechner.com

2 1

Re: [Inkscape-devel] [PATCH] Dockable dialogs, and some concerns...
by Jon A. Cruz 28 Mar '07

28 Mar '07

On Mar 28, 2007, at 11:44 AM, Thorsten Wilms wrote: > A proposal to bring Blender-like splitable views, detachable panels > and tabs > to the WM level is on my too-long todo list. Splitable views and tabs are mechanisms that will probably solve all the problems people want MDI used to solve, but in a much better solution. In fact, having split views on a single document in a single window along with having a separate window for each document will probably be the best solution. Adding in tabs will be a solution for some people, but personally I don't use them nearly as much as others. Having both implemented and allowing the users to use as little or as much of each as they desire will probably maximize productivity, and that will be far better than trying to solve those with MDI.

3 2

Re: [Inkscape-devel] [PATCH] Dockable dialogs, and some concerns...
by Jon A. Cruz 28 Mar '07

28 Mar '07

On Mar 28, 2007, at 11:44 AM, Thorsten Wilms wrote: Thanks for the list. It's actually a bit outdated, especially for MS Windows users. > * Many child windows do not fill up the OS task management > interface, as they > are hierarchically organized. Users simply switch applications. As of Windows XP this is no longer an issue. Windows automatically collapses documents from the same app so that the management interface does not get filled up. Also, users usually want to switch to a *document*, not an *application*, so switching applications is actually a negative. > * With MDI (and also TDI), a single menu bar and/or toolbar is > shared between > all child windows, reducing clutter and increasing efficient use of > screen > space. The extent of benefit depends on the application and if windows are tiled or worked with individually. Most applications have more efficient screen use and customizable toolbars, so the base clutter is far less than it used to be. Additionally, unless the windows are tiled, there is no net gain, since switching from App A window A to App A Window B will bring forward and use the same screen pixel locations. > * All child windows for an application can be hidden/shown/ > minimized/maximized > as a whole. Again, questionable if it is an actual "advantage". It is a property/ behavior of MDI, but most studies indicate this is a negative for most users. People most often think of "documents" and tend to work "on documents" instead of "in applications". > * Without an MDI frame window, floating toolbars from one > application can > clutter the workspace of other applications, potentially confusing > users with > the jumble of interfaces. True. But this advantage is also gained by not having floating toolbars and does not require MDI to gain. SDI also has this advantage, so it really shouldn't be a factor here. > * Features such as "Tile" and "Cascade" can be implemented for the > child windows. A decent advantage. However, it is also a disadvantage in that it means all documents of a given application are tiled, not of a given set. The work-around in MDI to make this point an advantage is to only open documents for client A. However, that also then is the same thing to give SDI the same advantage.

1 0

Memoryleak? when creating text object
by unknown＠example.com 28 Mar '07

28 Mar '07

Hi all, I may have found a memoryleak (don't know what they look like). When i run Inkscape from gdb (svn-head, winxp) the debugger will catch a SIGTRAP after dragging and releasing the text tool: warning: HEAP[inkscape.exe]: warning: Heap block at 053640B8 modified at 053640C4 past requested size of 4 Program received signal SIGTRAP, Trace/breakpoint trap. 0x7c901231 in ntdll!DbgUiConnectToDbg () from ntdll.dll The backtrace ends with: #56 0x00000000 in ?? () from #57 0x04a295c0 in ?? () #58 0x02b60000 in ?? () #59 0x00ab63fc in std::vector<Inkscape::Text::Layout::Chunk, std::allocator<Inkscape::Text::Layout::Chunk> >::_M_insert_aux () at c:/dev/gcc/gcc-4.1.1/objdir/i686-pc-mingw32/libstdc++-v3/include/bits/ios_base.h:169 Previous frame inner to this frame (corrupt stack?) This bug might be related to bug 1645874. When running Inkscape normally, nothing happens, other than that memory seems leaking (the allocated memory keeps increasing when more text objects are drawn with the texttool) Cheers, Johan

2 2