Sounds brilliant Bulia. Perhaps you could put a screenshot on the site? Cheers Jon bulia byak wrote: -- Jonathan Leighton aka. Turnip http://turnipspatch.com/ | http://digital-proof.org/

FANTASTIC!! but of course I've to remark some things :) It would maybe be nice if the nodes had the color that is applied, but that's not importand, since you see it anyways. More importantly: The stops inbetween the end nodes should be configurable as well imho... Also: the snapping of the nodes is real cool, but i think they should snap, when you press shift and not the other way around. There's probably a lot more, but I'm still to facinated by the new feature :) Thank you! David

Hi bulia, that sounds very nice, but I have problems to compile CVS. Tobias ------------------------------------------------------------------- make all-recursive make[1]: Entering directory `/home/tobias/cvs/inkscape' Making all in src make[2]: Entering directory `/home/tobias/cvs/inkscape/src' if g++ -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/include/freetype2 -I/usr/include/freetype2 -I/usr/X11R6/include -DPOTRACE=\"potrace\" -DXTHREADS -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/X11R6/include -I/usr/include/atk-1.0 -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libxml2 -I/usr/include/sigc ++-2.0 -I/usr/lib/sigc++-2.0/include -I/usr/include/gtkmm-2.4 -I/usr/lib/gtkmm-2.4/include -I/usr/include/glibmm-2.4 -I/usr/lib/glibmm-2.4/include -I/usr/include/gdkmm-2.4 -I/usr/lib/gdkmm-2.4/include -I/usr/include/pangomm-1.4 -I/usr/include/atkmm-1.6 -Wall -W -Wpointer-arith -Wcast-align -Wsign-compare -Woverloaded-virtual -Wswitch -Wno-unused-parameter -g -O2 -MT gradient-chemistry.o -MD -MP -MF ".deps/gradient-chemistry.Tpo" \ -c -o gradient-chemistry.o `test -f 'gradient-chemistry.cpp' || echo './'`gradient-chemistry.cpp; \ then mv -f ".deps/gradient-chemistry.Tpo" ".deps/gradient-chemistry.Po"; \ else rm -f ".deps/gradient-chemistry.Tpo"; exit 1; \ fi gradient-chemistry.cpp: In function `void sp_gradient_set_coords(SPGradient*, unsigned int, NR::Point, bool, NR::Matrix)': gradient-chemistry.cpp:487: error: parse error before `*' token gradient-chemistry.cpp:494: error: no match for 'operator*' in ' NR::operator*(const NR::Matrix&, const NR::Matrix&)((&i2d)) * move' libnr/nr-matrix-ops.h:51: error: candidates are: NR::Matrix NR::operator*(const NR::Matrix&, const NRMatrix&) libnr/nr-matrix-ops.h:48: error: NR::Matrix NR::operator*(const NR::Matrix&, const NR::Matrix&) libnr/nr-matrix-ops.h:26: error: NR::Point NR::operator*(const NR::Point&, const NR::Matrix&) libnr/nr-point-ops.h:45: error: NR::Point NR::operator*(double, const NR::Point&) gradient-chemistry.cpp:484: warning: unused variable `double move_angle' gradient-chemistry.cpp:485: warning: unused variable `double move_stretch' gradient-chemistry.cpp:506: error: parse error before `*' token gradient-chemistry.cpp:513: error: no match for 'operator*' in ' NR::operator*(const NR::Matrix&, const NR::Matrix&)((&i2d)) * move' libnr/nr-matrix-ops.h:51: error: candidates are: NR::Matrix NR::operator*(const NR::Matrix&, const NRMatrix&) libnr/nr-matrix-ops.h:48: error: NR::Matrix NR::operator*(const NR::Matrix&, const NR::Matrix&) libnr/nr-matrix-ops.h:26: error: NR::Point NR::operator*(const NR::Point&, const NR::Matrix&) libnr/nr-point-ops.h:45: error: NR::Point NR::operator*(double, const NR::Point&) gradient-chemistry.cpp:503: warning: unused variable `double move_angle' gradient-chemistry.cpp:504: warning: unused variable `double move_stretch' make[2]: *** [gradient-chemistry.o] Error 1 make[2]: Leaving directory `/home/tobias/cvs/inkscape/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/tobias/cvs/inkscape' make: *** [all] Error 2

Hi, Le Sat, 19 Feb 2005 12:39:48 -0400, bulia byak a écrit : I had the same problem yesterday, and now inkscape compiles fine. Emmanuel.

On Sat, Feb 19, 2005 at 05:46:57PM +0300, Alexandre Prokoudine wrote: Eep. If you notice a significant lag on the daily win32 snaps, please email the devel list. I'll check on them. -- Kees Cook @outflux.net

Alexandre Prokoudine wrote: I have been generating builds on an almost daily basis again here: http://troi.hous.es3.titan.com/inkscape/builds/ Here is today's: http://troi.hous.es3.titan.com/inkscape/builds/Inkscape0502190935.zip Bob

On Fri, 18 Feb 2005, bulia byak wrote: That is very cool. There is a bit of lag between the spot/handle and when the axis/spokes move which makes it feel a bit sluggish but otherwise this is great. It is particularly trippy if you wave your mouse around while using repeating gradient. I expect you can safely remove most of it but it might be useful to have a more controlled way to adjust gradients in addition to the interactive editing... ... but it sounds like the tool you have planned will provide for most of those issues. While I'm taking a few minutes to try out the latest and greatest test build I have noticed a few unrelated oddities: There definately should not be ((parenthesis)) used in menu labels. Singular or plural, pick one (one or more can be implied). Document Preferences could be labelled as "Document Properties" or simply Properties (it is in the file menu so it is implied that it is the Properties of the current file). It would help disambiguate it from the standard Preferences (and allow a more terse label). Looking at it more closely it is actually a combination of what other applications would call "Page Setup" and Metadata corresponds to what most applications simply refer to as Properties. There are other things I find disconcerting about Inkscape and rough edges here and there but I'd be just repeating myself to bring them up again now so I'll leave it at that. The new interactive gradient functionality is great and I'm sure it will draw even more people to Inkscape (no pun intended). Sincerely Alan Horkan Inkscape, Draw Freely http://inkscape.org Abiword is Awesome http://abisource.com

On Saturday 19 February 2005 21:20, bulia byak wrote: Can I ask a Q here at this point? Sorry, I need to get into building Inkscape CVS so I havent seen it yet. IE, how have you handled large gradient "lengths" where the item its applied to is much smaller than the gradient vector? This is one thing we have had trouble with importing SVGs into Scribus where the vector is much larger than the item. Currently a limitation of Scribus gradients is that the end points of the vector must be within the boundaries of the object, which was never the case before in Inkscape IIRC. We can edit the gradient vector on the canvas in 1.3 though. Hopefully to achieve this you wont have to zoom right out. Of course, theres argument for just changing the end points colours but that will become inaccurate if applying the same gradient to multiple objects. Craig

On Sat, 19 Feb 2005, bulia byak wrote: Great. The current gradient system isn't very controlled but I mean that in general a dialog with input widgets like spinners/sliders allow users to specify exactly what they want with much greater precision. Even with a very steady hand it is not always possible to get exactly what you want using a more interactive tool. (Sorry for not being clearer.) I cannot believe you are asking me to verify that. Inkscape has an Object menu that applies to one or more objects. It is not labelled Object(s). Have you ever seen a popular application with Parenthesis in the menus before? Do I also need to explain why abbreviations in menu labels are not a good idea? If I was willing to spend a considerable amount of time I could probably find some to find suitable reference in the the Gnome HIG or Gnome Documentation Style Guide but it such a simple thing it will be dificult to find anything specifically telling you not to do it. (I know all too well that it is poor writing style to use parenthesis exactly because I do it all the time and it isn't very aesthetically pleasing either to have excessive punctuation.) You are looking at this one in isolation thinking only of Inkscape. I'm looking at it in terms of Gnome and a variety of other applications and I'm thinking of consistancy and many applications have an item for "Page Setup" grouped with Print and Print Preview (some apps like OpenOffice put this elsewhere like under formatting) and a Properties item (metadata is still a technical term even if you and I might be using it all the time). While writing my previous mail I was going to say that if Inkscape were following the Gnome Human Interface Guidelines then Preferences would be in the Edit menu but the Edit menu in Inkscape is very crowded at the moment and I'm fairly sure I've already pointed that out so I was going to leave it for another day. Seeing Inkscape in the menu label for anything other than "About Inkscape" (and even there it is redundant) just seems wrong to me. I've done my bit, I've provided feedback as best I can. Make of it what you will. Sincerely Alan Horkan Free SVG Clip Art http://OpenClipArt.org Inkscape, Draw Freely http://inkscape.org Abiword is Awesome http://abisource.com

On Sun, 20 Feb 2005 02:22:19 +0100, Jakub Steiner <jimmac@...659...> wrote: It always struck me as something extremely odd that the global preferences of a program are in "Edit", just below Copy and Paste. What's the connection? I fail to see it. Yeah, I know, everyone does that. But it does not make it less stupid in my opinion. And in other programs, it's in Tools instead, which isn't any better. I always swear when I'm trying to find it on one of these menus while it's (of course!) in another. In my experience, most users of most programs have very vague idea of what are the various kinds of properties and preferences. In many cases they are surprised to find that some of those thingies they changed are saved with the document and some are with the program itself. And most programs don't make it easier for them to figure this out. A typical user goes like this, "I think it must be settable somewhere... OK, let's try Properties... Nope... Maybe Configuration... No. Where did I see it last time? Ah! It also has this Preferences thing, dammit. Yeah, there it is. OK, let's hope it will now remember it and I won't have to set it again." It's more trial-and-error than anything else. And it's frustrating. So, in an attempt to fix this, I put the two configuration commands next to each other so that: 1) the user is instantly aware that there are two similar-but-different commands for setting various things; 2) the user is given an idea of how they are different (the statusbar tips explain that document preferences are saved with the document); 3) the user does not need to hunt these commands down in different menus. So, I think it's much easier to understand and remember it this way. I don't want to start a flamewar, so if the consensus is that we must change that, let it be. I just wanted to explain my reasoning.

bulia byak wrote: i think we can learn form other projects. Mozilla people had a similar dilemma in Firefox: traditionally, Netscape and Mozilla Suite used Edit>Preferences (which is consistent with Gnome). in the desire to attract Windows people, they copied the Internet Explorer layout and moved to Tools>Options. the old user base and Linux people was outraged and a bad compromise was reached: now Firefox has two different menu layouts, one for Windows, with Tools>Options and another for Linux, with Edit>Preferences (don't know about Mac). and as a personal opinion, i think it make sense, because you Edit the Preferences

On Sun, 20 Feb 2005 11:52:38 +0100, Andreas Nilsson <nisses.mail@...563...> wrote: Wow, I love this reasoning. It basically says, put it on Edit because Edit exists and because you can't put it in a menu of its own. Clever. Now, putting it to File is of course not much better, but at least it is compliant with the idea that File has items that control the application as a whole (such as Exit), which seems more relevant for global preferences.

On Sun, 20 Feb 2005 10:11:52 -0800, Bryce Harrington <bryce@...260...> wrote: Already done in CVS of Scribus (1.3 branch) about 2 weeks ago :) Alexandre

Bryce Harrington wrote: I don't think it is that confusing actually, because they adress two different things. Preferences how the program behave and Page Setup (or whatever it's called) properties for the current document. Having document properties close to the printing stuff in the file menu is also nice, because often when you print stuff, the document is a bit to big, or has to small margins and stuff like that so having it close to eachother feels natural. - Andreas Nilsson

On Sat, 2005-02-19 at 21:48 -0400, bulia byak wrote: That is exactly why such things need to be standardized. Since Inkscape is a multiplatform application, ideally it should follow Firefox' example and structure the menus depending on the platform specifications and usanses. Mac users will be looking for an "Inkscape" menu and "Preferences". Windows and GNOME users are used to "Edit>Preferences" even though it uses a wrong pattern of action>object instead of object>action. These issues have to be tackled globally for the whole platform and not application by application even though I see it's a lot harder change things. There is so many ways a structure could make sense. To really have a user in mind, have *consistency with the rest of the platform* in mind. And since I already mentioned Firefox, I have to express my utter amazement by the design of it. The application is stripped down to solve a basic set of tasks, keeping the complexity down as much as possible. Then it has means to extend its functionality with extensions. Specific functionality that is very useful to a group of people doesn't pollute the interface for everybody while making it easy for users to install an extension providing the functionality. Also it lowers the maintenance for the core application. I am hoping to see you guys invest in making a sane API for scriptability since an illustrator app is just screaming for people to write custom scrpits that automa so many tiring tasks. And last but not least, as mentioned above, while sharing the core, each platform has a specific interface making it feel native on its host system. Users will find it easy to learn to use the application because it will feel "natural" to them. Adding features surely is a noble goal. Looking back at why the Inkscape project started I hope the interest in usability isn't just marginal. cheers -- Jakub Steiner <jimmac@...653...>

On Sun, 2005-02-20 at 19:39 +0200, Nicu Buculei wrote: Well maintaining so many language versions sucks in a similar manner. The question is if it's worth it. I'm saying yes, that interface consistency is worth it. The number of items that would be different is not too big. As far as I know the documentation now is XML that's processed with an XSLT stylesheet, so creating platform dependent version isn't all that complex really. Let me reply to Bulia's comment on having some more sane structure than what the HIG suggests (or generally the Mac/... HIG, not sure if Windows have interface guidelines). It may sound like a good idea to play on your own field if you think you can design a better structure. But look at MS Internet Explorer, they do the same -- the box model in CSS specifies the width and height doesn't include the padding of the box, so you need to be careful about using % units since padding is added to that. MS didn't like that idea and have width and height be defined so that padding is subtracted from this amount. While it may sound like it's making the % units more useful, the fact that only IE has this behavior makes all web designers cry. Similarly Inkscape doesn't try to interpret SVG differently from what the SVG spec says. It does uses its own namespace to extend it, but whatever you save as SVG will be interpreted by a standard SVG renderer. You don't have circles defined differently than in SVG because it's more efficient (yes t would rock if I actualy knew enough to give a better example). Unfortunately there is no single standard, interface guidelines for all platforms, which makes this a little worse of a situation. cheers -- Jakub Steiner <jimmac@...659...> Novell, Inc.

On Sun, 20 Feb 2005 18:09:07 +0100, Jakub Steiner <jimmac@...653...> wrote: This analogy doesn't work either. Firefox must be transparent and simple, because it's used by millions, and used for a simple task of viewing pages. A vector editor is a very different thing with a very different audience. Editing a vector drawing is all about tweaking things. Why should we be afraid of letting people tweak things in preferences - if at the same time we allow and encourage them to tweak things on canvas in new and unexpected ways?

On Sun, 2005-02-20 at 14:38 -0400, bulia byak wrote: Sure, but I'm not sure you picked up the core of my message. With a vector editor you have a very diverse user base. People will draw icons, create diagrams, draw schemas, blueprints. If you provide an easy way to extend the core functionality, you will make Inkscape a nice *platform* for people to focus on a very niche market/area without affecting people who don't give a heck about it. cheers -- Jakub Steiner <jimmac@...653...>

On Sun, Feb 20, 2005 at 07:02:14PM +0000, Alan Horkan wrote: This may be rhetorical, but if not the answer should hopefully be pretty obvious that we give priority to Linux. But that doesn't mean we want to exclude other platforms. The view I tend to take (and I think others agree), is that we're not fighting so much for a _platform_ oriented mindshare as much as a _philosophical_ mindshare. I.e., the fight is not Linux-vs-Windows so much as Open Source -vs- Closed. For those who do want to think in terms of platforms, the presence of Inkscape on Windows is not meant to imply we're embracing Microsoft. A better analogy might be a Viking invasion type thing... Note that we're not adopting native widgets, not using the native compiler, etc. but are bringing the open source versions (gtk, gcc) along with us. The grand strategy is that Inkscape's presence (along with Firefox, OpenOffice, Gimp, etc.) on other operating systems will flatten the playing field. Once Windows users are comfortably using all-OSS on top of Windows, they become very easy to shift to another platform. When I first switched to Linux, it was pretty extreme. I had to leave behind all the tools, processes, etc. I had grown accustomed to on Windows and devote several unproductive months to training myself in what was available on Linux. Having these apps on Windows helps reduce the cost of change, so when the user does finally pull up Linux, they'll be able to return to their normal productivity reasonably quickly. I can't resist answering rhetorical questions like that, with a big long dissertation. ;-) In any product, it is worthwhile to know where you get your value, so you can make appropriate decisions and direct resources accordingly. For commercial software, value comes in the form of money paid by corporations and individuals who purchase the software (presumably to use it). Thus you focus your energies towards efforts that will result in good magazine reviews, prime shelf-space location, etc. If you also put out an actually good and useful product, then you'll also benefit from word of mouth. The name of the game is to get as many people to buy each release of the software. You probably don't care if the user buys the software but never uses it - still counts as a sale. The value allows you to build up the organization, fund support, administration and marketing, and maybe also develop new versions of the software with what cash remains. Essentially: 1. User spends their time on a job 2. Job pays user some money in exchange for the time spent 3. User pays money for new copy of software 4. Some large portion of money goes to profit, overhead, administration, paying off debt, etc. 5. Some small portion is allocated to improve product 6. Development occurs (out of user's visibility) 7. A new version is packaged and released 8. User learns that a new copy is available, possibly with some features they want 9. Repeat For open source software, on the other hand, value doesn't come from money paid by users (except maybe for donations, but that tends to be for secondary purposes). Instead it comes in the form of voluntary contributions from people, in the form of patches, articles, bug reports / fixes, translations, packaging, etc. This value results in direct improvements to the software and the organization around it. Thus, our target users are those that provide value in some fashion back to the project. By focusing on their needs, we can increase the amount of contributions to the project, which accelerates the development, pulls in more users, and improves the software and the community organization that surrounds it. Essentially: 1. User gets copy of the software, and spends their time improving it 2. Improvements are incorporated into product 3. A new version is released including the changes they wanted 4. Repeat Inkscape's priorities should focus first on helping existing users that are contributing actively to the project, and to gaining new users that will become contributors in the future. Thus, it is important not only to provide new features and fix bugs but also to make it easier for others to add changes to the software, and to develop good relations such that the community organization improves and grows. One of the best ways to ensure that actively contributing users are getting their needs met is to encourage those users to work specifically on fulfilling their needs themselves, where they have the skills to do so. By 'scratching their own itch' they can directly ensure things are done according to how they need them. Our strength, though, is in our ability to coordinate and work as a team; each can then do things that leverage their strong skills to do things that maximize the project's gains. Windows as a platform is important because there are people who will work on improving Inkscape if they can use it there. Similarly for OSX. However, I think we'll get the most bang for the buck from Linux, since Linux users tend to be more active with development communities in general, and because there are so many programmers using Linux. Bryce

On Mon, 21 Feb 2005 12:56:24 +1000, Andy Fitzsimon <andyfitz@...400...> wrote: Very cool, thanks :) It's a good starting point for a 0.42 about box, don't you think? :)

Bryce Harrington wrote: you are pretty good at those dissertations, you should send them more often to osnews or such or even publish a blog -- nicu

On Mon, 21 Feb 2005 13:47:24 +0100, Jakub Steiner <jimmac@...659...> wrote: IMHO much more convenient is to snap together the vectors of several objects on canvas (of course unless there are too many of them) and then adjust the common snapped vector. It will remain snapped even if you deselect and then reselect the objects. Of course, that was the plan.