W dniu 10 stycznia 2010 04:27 użytkownik Joshua A. Andler <scislac@...400...> napisał: Apparently, yes :/ Yes, it doesn't work yet. If it's a must before it goes into trunk, then of course I will implement it, but without the ability to change "sculpting profiles" (there was no UI for this before as well). They will be back once I add enumerations as a value type to the preferences API. It is a promise that means "I will fix this before I start a new large project" :) It should be an on/off switch. It would still possible to clear the node selection by clicking on a node that's not selected, or in an empty space. When working with transforms, constantly clicking the button after each selection change could become annoying as well :) What does it mean "(if a selection of >1 node, always a show queue)"? Right now the default is to show the handles only when more than one node is selected, but there is an option to turn it on even for single nodes. Regards, Krzysztof

2010/1/9 Krzysztof Kosiński <tweenk.pl@...400...>: This sounds like a command for Path menu, not something specific to Node tool. Maybe also combine it with other cleanup operations, such as removing subpaths with zero or one node, and call "Clean up path". Its promise will be to preserve appearance for solid paths but possibly change it if there are markers or dashes. As we discussed, in Selector it's Shift+S, but we cannot use the same in Node because there it means turning node to smooth. We also shouldn't use Shift+R because it conflicts with reversing path (analogous to reversing gradient in Gradient tool). We need to use some globally unused, and ideally somewhat intuitive, Shift+letter combination. In addition to that we might add a toggle button for this, on Node as well as Selector controls bars. -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

On 01/10/2010 03:06 AM, Krzysztof Kosiński wrote: I've just made some changes to the snapping API today, as Joshua already noted. Shouldn't take you more than a few minutes extra though :-) Well, that's the whole idea of the snapping mechanism: If snapping is on, then snapping should take place. For some tools though it can be overridden by holding the shift key. But maybe I don't understand the problem here; what else would you expect? BTW, there is a shortcut key to toggle snapping quickly. Why don't you just turn off the snap delay in the preferences? This gives you the behavior you're looking for, or doesn't it? Regards, Diederik

On 10/1/10 11:11, ~suv wrote: oops, not true - e.g. node snapping 'Snap to path' and 'Snap to path intersections' fails for me, works with r8958 (tested with default prefs in new file from default A4 template). ~suv

On 11/1/10 17:40, Diederik van Lierop wrote: Yep, thanks for fixing that. I should have confirmed earlier that fixing the typo also restored both mentioned snapping modes, sorry. ~suv

On 01/10/2010 12:09 PM, Jon Cruz wrote: Fixed. But is the crash below yours? Program received signal SIGSEGV, Segmentation fault. 0x000000362c87ecd2 in __strlen_sse2 () from /lib64/libc.so.6 (gdb) bt #0 0x000000362c87ecd2 in __strlen_sse2 () from /lib64/libc.so.6 #1 0x000000300ae590e2 in g_strdup () from /lib64/libglib-2.0.so.0 #2 0x000000300b23107d in ?? () from /lib64/libgobject-2.0.so.0 #3 0x0000003fe0d49f32 in ?? () from /usr/lib64/libgtk-x11-2.0.so.0 #4 0x0000003fe0d4a419 in gtk_list_store_set_valist () from /usr/lib64/libgtk-x11-2.0.so.0 #5 0x0000003fe0d4a518 in gtk_list_store_set () from /usr/lib64/libgtk-x11-2.0.so.0 #6 0x00000000007e91e8 in create_or_fetch_actions (desktop=0x1a51c00) at widgets/toolbox.cpp:849 #7 0x00000000007ec5d9 in setupToolboxCommon (toolbox=0x2beb1c0, desktop=0x1a51c00, descr= 0xe25198 "<ui> <toolbar name='ToolToolbar'> <toolitem action='ToolSelector' /> <toolitem action='ToolNode' /> <toolitem action='ToolTweak' /> <toolitem action='ToolSpray' /> <toolitem action='To"..., toolbarName=0xe25478 "/ui/ToolToolbar", sizePref=0xe2487e "/toolbox/tools/small") at widgets/toolbox.cpp:1631 #8 0x00000000007ecf0d in setup_tool_toolbox (toolbox=0x2beb1c0, desktop=0x1a51c00) at widgets/toolbox.cpp:1758 #9 0x00000000007ec474 in Inkscape::UI::ToolboxFactory::setToolboxDesktop (toolbox=0x2beb1c0, desktop=0x1a51c00) at widgets/toolbox.cpp:1615 #10 0x0000000000833888 in Inkscape::UI::UXManager::connectToDesktop (this=0x2daffd0, toolboxes=std::vector of length 4, capacity 4 = {...}, desktop=0x1a51c00) at ui/uxmanager.cpp:98 #11 0x00000000007b5ce8 in SPDesktopWidget::createInstance (namedview=0x22680a0) at widgets/desktop-widget.cpp:1395 #12 0x00000000007b5904 in sp_desktop_widget_new (namedview=0x22680a0) at widgets/desktop-widget.cpp:1346 #13 0x00000000004649f8 in sp_file_new (templ=...) at file.cpp:129 #14 0x0000000000464d4d in sp_file_new_default () at file.cpp:177 #15 0x000000000044d5b4 in sp_main_gui (argc=1, argv=0x7fffffffe1a8) at main.cpp:949 #16 0x00000000005abe32 in Inkscape::NSApplication::Application::run (this=0x7fffffffe070) at application/application.cpp:114 #17 0x000000000044ca4a in main (argc=1, argv=0x7fffffffe1a8) at main.cpp:689 Regards, Diederik

On Jan 10, 2010, at 6:17 AM, Krzysztof Kosiński wrote: No, it's not. Please note Josh's mail on 0.48

On Jan 10, 2010, at 10:38 AM, Krzysztof Kosiński wrote: No, no. You missed the point. This is not refactoring, this is the new feature that Josh mentioned: "*JonCruz's Adaptive UI work"

On Jan 10, 2010, at 6:17 AM, Krzysztof Kosiński wrote: Well, that should have been "Yes", as Diederik was replying to and asking me. :-)

On 01/10/2010 03:36 PM, Krzysztof Kosiński wrote: Ah, now I see: you're interpreting the snap indicator differently. If you see the snap indicator then snapping _has_ already occurred. The indicator has been implemented to show what we've snapped to, not to show what we'll snap to _after_ the mouse button is released. That's how it's supposed to work. Forget the snap indicator for a moment, and think about snapping to a grid. When using a grid, many users will expect all objects to be aligned to any of the grid lines, at any time; after all that's what you're using a grid for. Now when dragging an object it will become unaligned, but it should be aligned again once its released (only if snapping has been enabled ofcourse). That's why snapping is triggered when the mouse button is released. The snap delay mechanism controls how often Inkscape tries to snap while dragging the object around, but still we always snap when releasing the mouse button. The snap indicator only tells us where snapping took place. Believe me, there are users who prefer it like this! I found that out _after_ implementing the snap delay ;-) Correct, you'll have to switch snapping off yourself explicitly, Inkscape will not do that for you. We should not try to guess when a user wants to snap and when not, we might guess wrong without the user noticing. The most elegant way is to disable snapping when holding the SHIFT key, as some tools do, but unfortunately the modifier keys are already heavily contested so we will probably never get that implemented in all tools. The second best thing is to use the % key to toggle snapping, and to toggle it back on again afterwards. Regards, Diederik

On 01/10/2010 10:43 PM, Krzysztof Kosiński wrote: It's in the UI because I didn't know at that time what a good value would be, and to allow users to turn it off and get the old behavior back. The latter might still be desired, so I propose leaving the slider there, but we can indeed lower the default value as you suggested. Could you do a short test and see at what value it becomes acceptable for you? My assumption here is that the user is moving from one aligned position to the other, and the unaligned position is just an intermediate state. So if the user drags an object it's not because he wants it to become unaligned, but to move to another aligned position. Different users might have different expectations though. It might be counter-intuitive to you, but at least it's predictable. IMHO that's very important for users who use snapping because they tend to value accuracy and want to be sure that their drawings are perfectly aligned and orthogonal. In the days before we had the snap-indicator this predictability was even more important because they didn't get any feedback; nowadays this predictability is still useful though. That could very well be the case, so that's why they can disable it. You will need it though on complex documents, or on a slow pc For me 150 msec (the current default value if I'm correct) is hardly noticeable, but maybe I'm getting old ;-) ? Please confirm if you really want to go as low as 50 msec. Have a try at e.g. 75 or 100 msec and report your experiences. I think the higher the more better, but obviously there should be an optimum somewhere. No we're not guessing here, we're being predictable! Snapping is enabled, so we'll snap. Always. Period. ... or until it comes closer to another snap target. This is exactly the behavior you'll get when you set the snap delay to zero. This requires some snapping code to be executed for each and every motion event. Because of the boundary condition that snapping should always occur, and because we don't want to snap on each and every motion event (the snap delay mechanism), we must snap when releasing the mouse button. If the user drops an object "on the fly", snapping must be triggered, even though the mouse speed doesn't drop to zero. So only monitoring the speed of the pointer to trigger snapping is not sufficient. Diederik

On Tue, 12 Jan 2010 05:46:30 +0100, Krzysztof Kosiński <tweenk.pl@...400...> wrote: It's the other way around: something that is _not_ predictable is bad. I'm obviously not arguing that something that's predictable is always good, regardless of the implementation No, because the snap indicator can be overlooked or can be disabled. And if that happens the predictability is gone. Reduce the snap delay and this will be solved. We don't. It's there within 150 msec. That won't work. If you have a cloud of points, it will not be possible to snap to points in the middle of that cloud. When moving towards that cloud, Inkscape will snap to a point at the circumference and stick there. Only by moving away from the cloud the user can snap again, but by approaching that cloud from a different direction another point on the circumference will be snapped too, and again not the point at the center of the cloud. This can only be solved by taking into account each small motion increment, looking at all points in the vicinity for each motion event, and each time determining which snap target is the closest. See my reasoning above about the cloud of points. Snapping code must be executed on each motion event and your algorithm won't work in this case. The only way to speed this up is to use the snap delay mechanism which eliminates snapping on some of the motion events, to implement better caching of the snap target candidates and their snap points, and to make it faster to find the items in the vicinity (e.g. using some 2D database). Diederik

On 01/12/2010 02:32 PM, Krzysztof Kosiński wrote: No, it means sitting to close to an 24" monitor ;-). Snapping doesn't always happen close to the mousepointer, so it's possible to miss a few blinking pixels at the other side of the screen! But anyway, that doesn't really matter. Please remmber that what works for you might not work for others, and vice versa. I don't feel this is a quirk at all. But about the usefulness of the snap delay slider you might be right. It should however at least be switchable between 0 and some fixed small delay. You're explanation is quite clear to me I believe, but I still don't see how you would solve the "cloud" issue when using the sticky snap feature you're proposing. I'll describe the problem in a bit more detail: suppose you have three snap targets close to each other, e.g. within 5 screen pixels distance whereas the snap distance is set to 20 screen pixels. All three snap targets lie on a single vertical line, so when approaching the snap targets from above Inkscape will snap to the upper target, and stick to it. When approaching from below Inkscape will snap to the lower target, and stick to it. But what if you want to snap to the middle point? PS: The answer I'm looking for is not to approach from the right or left, because I can easily extend this 1D problem to a 2D problem ;-) Regards, Diederik

On 01/12/2010 10:10 PM, Krzysztof Kosiński wrote: I expected that, but that will prove to be very difficult when the snap targets are close to each other. It's like darts, aiming for the bull's eye! Our current implementation doesn't have this problem because it will evaluate all snap targets in the vicinity of the mouse pointer, so a small movement will allow to select another nearby snap target. If we would implement your sticky snap feature then the user would have to move far enough away from where (s)he wants to be and then return to aim for the bull's eye all over again. And aiming will have to be done at a speed above a certain speed threshold because otherwise snapping will occur before arriving at the snap target. This is not acceptable because it's very annoying. It takes control away. Regards, Diederik

On 10/1/10 03:06, Krzysztof Kosiński wrote: BZR Revision 8976 fails to build on OS X 10.5.8: Any further information I can provide? compiler version: build configuration: ~suv

W dniu 14 stycznia 2010 18:10 użytkownik ~suv <suv-sf@...58...> napisał: At first glance it looks like a bug in <tr1/unordered_set> in your compiler version. Can you compile the example from the third answer here, to see whether unordered_set works at all? http://stackoverflow.com/questions/1335739/how-to-determine-if-a-list-is-... Regards, Krzysztof

W dniu 14 stycznia 2010 20:06 użytkownik ~suv <suv-sf@...58...> napisał: The example should compile without any special flags or other magic. It is definitely a bug in the <tr1/unordered_set> header. You'll have to upgrade to a version of GCC that has a working header. I don't think I can fix this (short of not using unordered_set at all). Regards, Krzysztof

On Jan 14, 2010, at 12:28 PM, ~suv wrote: We can't let that happen. That is, we can't just jump on the latest and greatest compiler, libs, etc. at the expense of common platforms. At a minimum we should definitely not require anything beyond the deployed OS X versions, and LTS versions of the base Linux distros.

On 14/1/10 23:44, Krzysztof Kosiński wrote: I did not upgrade anything tonight (the latest Xcode version is needed to build the dependencies for Inkscape in MacPorts, so I had it already installed). Xcode on Leopard installs both versions of gcc, but uses 4.0.1 as default. I never changed that default and only now tried if using 4.2.1 would make a difference. There are not separate c++ headers for g++-4.2 for 'tr1' (see attached file with the default paths used by the installed gcc/g++ versions) revision 8980 built ok on OS X 10.5.8 Thank you for the quick response! :) ~suv Last login: Thu Jan 14 22:00:45 on ttys003 FYI: ~/.bashrc sourced. LeWitt:~ suv$ export LANG="en_US.UTF-8" LeWitt:~ suv$ gcc -v -x c -E /dev/null Using built-in specs. Target: i686-apple-darwin9 Configured with: /var/tmp/gcc/gcc-5493~1/src/configure --disable-checking -enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib --build=i686-apple-darwin9 --with-arch=apple --with-tune=generic --host=i686-apple-darwin9 --target=i686-apple-darwin9 Thread model: posix gcc version 4.0.1 (Apple Inc. build 5493) /usr/libexec/gcc/i686-apple-darwin9/4.0.1/cc1 -E -quiet -v -D__DYNAMIC__ /dev/null -fPIC -mmacosx-version-min=10.5.8 -mtune=generic -march=apple ignoring nonexistent directory "/usr/local/include" ignoring nonexistent directory "/usr/lib/gcc/i686-apple-darwin9/4.0.1/../../../../i686-apple-darwin9/include" #include "..." search starts here: #include <...> search starts here: /usr/lib/gcc/i686-apple-darwin9/4.0.1/include /usr/include /System/Library/Frameworks (framework directory) /Library/Frameworks (framework directory) End of search list. # 1 "/dev/null" # 1 "<built-in>" # 1 "<command line>" # 1 "/dev/null" LeWitt:~ suv$ g++ -v -x c++ -E /dev/null Using built-in specs. Target: i686-apple-darwin9 Configured with: /var/tmp/gcc/gcc-5493~1/src/configure --disable-checking -enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib --build=i686-apple-darwin9 --with-arch=apple --with-tune=generic --host=i686-apple-darwin9 --target=i686-apple-darwin9 Thread model: posix gcc version 4.0.1 (Apple Inc. build 5493) /usr/libexec/gcc/i686-apple-darwin9/4.0.1/cc1plus -E -quiet -v -D__DYNAMIC__ /dev/null -fPIC -mmacosx-version-min=10.5.8 -mtune=generic -march=apple -D__private_extern__=extern ignoring nonexistent directory "/usr/local/include" ignoring nonexistent directory "/usr/lib/gcc/i686-apple-darwin9/4.0.1/../../../../i686-apple-darwin9/include" #include "..." search starts here: #include <...> search starts here: /usr/include/c++/4.0.0 /usr/include/c++/4.0.0/i686-apple-darwin9 /usr/include/c++/4.0.0/backward /usr/lib/gcc/i686-apple-darwin9/4.0.1/include /usr/include /System/Library/Frameworks (framework directory) /Library/Frameworks (framework directory) End of search list. # 1 "/dev/null" # 1 "<built-in>" # 1 "<command line>" # 1 "/dev/null" LeWitt:~ suv$ g++-4.2 -v -x c++ -E /dev/null Using built-in specs. Target: i686-apple-darwin9 Configured with: /var/tmp/gcc_42/gcc_42-5577~1/src/configure --disable-checking --enable-werror --prefix=/usr --mandir=/usr/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin9 --with-gxx-include-dir=/usr/include/c++/4.0.0 --host=i686-apple-darwin9 --target=i686-apple-darwin9 Thread model: posix gcc version 4.2.1 (Apple Inc. build 5577) /usr/libexec/gcc/i686-apple-darwin9/4.2.1/cc1plus -E -quiet -v -D__DYNAMIC__ /dev/null -fPIC -mmacosx-version-min=10.5.8 -mtune=core2 -D__private_extern__=extern ignoring nonexistent directory "/usr/local/include" ignoring nonexistent directory "/usr/lib/gcc/i686-apple-darwin9/4.2.1/../../../../i686-apple-darwin9/include" #include "..." search starts here: #include <...> search starts here: /usr/include/c++/4.0.0 /usr/include/c++/4.0.0/i686-apple-darwin9 /usr/include/c++/4.0.0/backward /usr/lib/gcc/i686-apple-darwin9/4.2.1/include /usr/include /System/Library/Frameworks (framework directory) /Library/Frameworks (framework directory) End of search list. # 1 "/dev/null" # 1 "<built-in>" # 1 "<command-line>" # 1 "/dev/null" LeWitt:~ suv$

W dniu 15 stycznia 2010 08:39 użytkownik ~suv <suv-sf@...58...> napisał: Yes, we are hitting this bug. By the way, the configure stanza for Apple's gcc-4.2 looks wrong. Note that is says "--with-gxx-include-dir=/include/c++/4.0.0", and headers <= 4.0.2 are broken. It should say something like "--with-gxx-include-dir=/include/c++/4.2.1". I have no idea why they did this. The fixes described at http://mohri-lt.cs.nyu.edu/twiki/bin/view/FST/CompilingOnMacOSX should work. Check whether you can compile rev 8979 or the test with one of them. If it works, I will change back to using TR1 unordered_set/map and add some configure code to detect the broken headers. Regards, Krzysztof