Problem with Snapping/new Document Properties pannel
Happy New Year to everybody and let 2006 be the year when Inkscape rules!
I recently tested the new document properties pannel on mac os X. I think I am a bit late for that but I liked better the first one (with frames) because it was more compact even if it was not HIG compliant. Would it be possible to have the metadata tab scrollable and the others more compact so that the dialog is smaller. I keep this one open very frequently to change snapping settings and I think it would be really nice to have it smaller.
Another problem is with snapping and the freehand and bezier tools: snapping to grid seems to be always on for these tools as long as the grid is displayed and whatever the status of snapping is in the Document Properties pannel (even before the it is changed). Is it the desired behaviour? If it is it should be the same for all tools and it does not seem to be the case.
Finally, the current distinction between "screen pixels" and "px units" is not really clear to me. what are px units? 1 px unit = 1 grid unit? may be it could be explained a bit better if it is to be kept.
Thank you in advance for considering this. I would happily fill a bug report for the second problem if it is necessary.
JiHO.
PS: for testing purposes the new document preferences pannel is in the last two dev builds for mac os X (24 december and 4 january). btw, is there no way to have the downloads for these builds mirrored and handled by sourceforge? because the download rate is awfully low and the download fails very often.
JiHO wrote :
PS: for testing purposes the new document preferences pannel is in the last two dev builds for mac os X (24 december and 4 january).
First, this is work in progress, and you might not have the recent version. I keep changing things daily. The best way to stay up-to-date if you must is by compiling yourself.
I recently tested the new document properties pannel on mac os X. I think I am a bit late for that but I liked better the first one (with frames) because it was more compact even if it was not HIG compliant.
This is not so under Linux where it's smaller, mainly due to License having its own page.
Would it be possible to have the metadata tab scrollable and the others more compact so that the dialog is smaller.
I'm surprised that there is such a problem when, in fact, the size of the dialog under Linux was reduced. There must be widgets under OSX that are not implemented 1:1.
Ideally, we would be HIG and <insert the OSX/Aqua equivalent> compliant. This is the real world, however.
Another problem is with snapping and the freehand and bezier tools: snapping to grid seems to be always on for these tools as long as the grid is displayed and whatever the status of snapping is in the Document Properties pannel (even before the it is changed). Is
Do you mean you want 'snapping to invisible grid'? I'm for it. I remember, though, this is contrary to Bulia's opinion.
Finally, the current distinction between "screen pixels" and "px units" is not really clear to me. what are px units? 1 px unit = 1 grid unit? may be it could be explained a bit better if it is to be kept.
Maybe you didn't see the recent version with tooltips on the radio buttons? If the issue can be explained better then please someone substitute the text. It's not really difficult. Just search for the string _rrb_pix in ui/dialog/document-properties.cpp
Thanks for the feedback. ralf
On 4 janv. 06, at 16:12, Ralf Stephan wrote:
JiHO wrote :
PS: for testing purposes the new document preferences pannel is in the last two dev builds for mac os X (24 december and 4 january).
First, this is work in progress, and you might not have the recent version. I keep changing things daily. The best way to stay up-to-date if you must is by compiling yourself.
This is what I am doing: I am doing the dev builds for mac os X ;-) but not as often as I would like to though.
I recently tested the new document properties pannel on mac os X. I think I am a bit late for that but I liked better the first one (with frames) because it was more compact even if it was not HIG compliant.
This is not so under Linux where it's smaller, mainly due to License having its own page.
Its the same under OS X. on OS X inkscape uses GTK and X11 so it really looks the same as on linux. there is no native "GTK to Aqua" port used right now. And license has it's own page in the latest builds. It is indeed smaller than the one of 0.43 but bigger on the 4th january (frames suppressed) than on the 24th decemeber (with frames). The main reason being a big metadata page I think. hence:
Would it be possible to have the metadata tab scrollable and the others more compact so that the dialog is smaller.
I'm surprised that there is such a problem when, in fact, the size of the dialog under Linux was reduced. There must be widgets under OSX that are not implemented 1:1.
Ideally, we would be HIG and <insert the OSX/Aqua equivalent> compliant. This is the real world, however.
cf what I wrote before. it's exactly the same on OS X and linux. It's just that it was smaller at some point of the rework and I just liked it better that way.
Another problem is with snapping and the freehand and bezier tools: snapping to grid seems to be always on for these tools as long as the grid is displayed and whatever the status of snapping is in the Document Properties pannel (even before the it is changed). Is
Do you mean you want 'snapping to invisible grid'? I'm for it. I remember, though, this is contrary to Bulia's opinion.
no. sorry if I explained it wrong. for snapping I'll probably be with bulia: snapping to grid should be enabled only when grid is on. the problem is that right now there is _always_ some snapping when the grid is on, even when nothing is checked in the grid snapping part. which is a bug in my opinion.
Finally, the current distinction between "screen pixels" and "px units" is not really clear to me. what are px units? 1 px unit = 1 grid unit? may be it could be explained a bit better if it is to be kept.
Maybe you didn't see the recent version with tooltips on the radio buttons? If the issue can be explained better then please someone substitute the text. It's not really difficult. Just search for the string _rrb_pix in ui/dialog/document-properties.cpp
I have the tooltips. I still don't fully understand what px units are. I understand _how_ it works because it is explained but I still don't know what it means if I set it to 1.0, 2.0 or 90.0. Previously, if my grid was every 1cm and that I set snapping distance to 1cm I knew thaht anything I draw will exactly snap to grid. what about now?
Thanks for the feedback. ralf
You're welcome. Thanks for the work. The dialog is better now IMHO... it just needs a little more work I'm afraid... :-)
builds. It is indeed smaller than the one of 0.43 but bigger on the 4th january (frames suppressed) than on the 24th decemeber (with frames). The main reason being a big metadata page I think.
Ah that's true, I moved the multiline input entries back to Metadata1 from Metadata2. But, now that Metadata2 is 'License' (which is much better imho), we can't put the two entities back, it would no longer be the License page.
Sorry.
the problem is that right now there is _always_ some snapping when the grid is on, even when nothing is checked in the grid snapping part. which is a bug in my opinion.
I cannot confirm this. Please give exact steps to reproduce.
I have the tooltips. I still don't fully understand what px units are. I understand _how_ it works because it is explained but I still don't know what it means if I set it to 1.0, 2.0 or 90.0. Previously, if my grid was every 1cm and that I set snapping distance to 1cm I knew thaht anything I draw will exactly snap to grid. what about now?
Now, it's always px because it's not ready. Work in progress.
When it's finished then px and screen units are identical at 100% zoom but the px choice changes visible sensitivity (not distance measured by ruler!) with zoom. Or, with screen pixels choice, the visible sensitivity stays the same (==screen pixels) but the measured distance changes with zoom.
You're welcome. Thanks for the work. The dialog is better now IMHO... it just needs a little more work I'm afraid... :-)
On my list is only the spx/px issue and some HIG stuff.
ralf
Metadata1 from Metadata2. But, now that Metadata2 is 'License' (which is much better imho), we can't put the two entities back, it would no longer be the License page.
Also, the dialog would not shrink because the first page has grown due to necessary spacing.
See it this way: if you hadn't looked at the Dec-24 version, you wouldn't even know about even smaller size.
ralf
On 4 janv. 06, at 17:59, Ralf Stephan wrote:
builds. It is indeed smaller than the one of 0.43 but bigger on the 4th january (frames suppressed) than on the 24th decemeber (with frames). The main reason being a big metadata page I think.
Ah that's true, I moved the multiline input entries back to Metadata1 from Metadata2. But, now that Metadata2 is 'License' (which is much better imho), we can't put the two entities back, it would no longer be the License page.
Sorry.
is there now way to have a scrollable metadata page? because it is the limiting factor now, all other tabs can be much smaller (75% of their current size at least), even the first one.
the problem is that right now there is _always_ some snapping when the grid is on, even when nothing is checked in the grid snapping part. which is a bug in my opinion.
I cannot confirm this. Please give exact steps to reproduce.
OK it might be os X related only then. I'll try to build latest inkscape on linux. the steps are simple: open a new document, put the grid on, zoom enough so that all grid lines become visible, select the freehand tool and try to trace a straight line: it snaps to the grid though grid snapping is normaly disabled by default.
I have the tooltips. I still don't fully understand what px units are. I understand _how_ it works because it is explained but I still don't know what it means if I set it to 1.0, 2.0 or 90.0. Previously, if my grid was every 1cm and that I set snapping distance to 1cm I knew thaht anything I draw will exactly snap to grid. what about now?
Now, it's always px because it's not ready. Work in progress.
When it's finished then px and screen units are identical at 100% zoom but the px choice changes visible sensitivity (not distance measured by ruler!) with zoom. Or, with screen pixels choice, the visible sensitivity stays the same (==screen pixels) but the measured distance changes with zoom.
OK, I thought that bulias question about keeping absolute units was about keeping cm/mm/... I'll juste test when this is finished, but not having cm for me who uses inkscape mostly for printed work might be annoying.
JiHO
jiho wrote:
OK, I thought that bulias question about keeping absolute units was about keeping cm/mm/... I'll juste test when this is finished, but not having cm for me who uses inkscape mostly for printed work might be annoying.
I understood Bulia's question to be asking about the pixel or px unit specifically and how it would be treated (screen vs absolute). If I'm wrong, I'd be less apt to call the removal of other units annoying than I would a leap backwards in usability.
-Josh
I understood Bulia's question to be asking about the pixel or px unit specifically and how it would be treated (screen vs absolute). If I'm wrong, I'd be less apt to call the removal of other units annoying than I would a leap backwards in usability.
Gross. A feature that will not be used must be even extended IYHO, making the dialog even more complicated.
Other than you, I think my measly work force is better applied to fixing real bugs than questionable backward leaps in usability. One goal of gtkmmification is to make dialogs more understandable. If I have succeded you should have no problem adding the feature.
But think of it: no one wants snapping to change behaviour when zooming.
ralf
Ralf Stephan wrote:
I understood Bulia's question to be asking about the pixel or px unit specifically and how it would be treated (screen vs absolute). If I'm wrong, I'd be less apt to call the removal of other units annoying than I would a leap backwards in usability.
Gross. A feature that will not be used must be even extended IYHO, making the dialog even more complicated.
Other than you, I think my measly work force is better applied to fixing real bugs than questionable backward leaps in usability. One goal of gtkmmification is to make dialogs more understandable. If I have succeded you should have no problem adding the feature.
But think of it: no one wants snapping to change behaviour when zooming.
Ralph,
It's quite obvious to me that I offended you and I'm very sorry for that. My statement was definitely worded too strongly.
I was just making an observation that we now have screen pixels or absolute pixels as options for snapping, but not the combobox containing the rest of the absolute units (in place of absolute pixels). We had it before, we don't have it now... that's all.
It ties into the argument I had originally that some people think relationally (unit-wise) to whatever they're working with. If one is working in inches, centimeters, or pixels, it helps to have every thing that deals with units (in general) work in a uniform manner. If I have my document set to inches, grid set to inches, can use the transform dialog with inches, and (as it ties to the document-wide unit) my rulers show inches as well... doesn't it make sense to have inches available for snapping (especially with the new snapping types)? That's the only thing I'm trying to communicate.
In my opinion, you have done a phenomenal job of simplifying the document properties dialog. It's clean, organized, and in general it makes much more sense and you can find things where you would expect them. I for one am greatly appreciative for the work you've put into this and sorry if it came across otherwise.
And for the record, I do agree that your workforce is probably much better spent on bug fixing or whatever else YOU want to work on rather than infinitely tweaking this dialog. If there isn't great opposition, I will look into replacing 'absolute pixel' with the absolute unit combobox (based on my reasoning above). Will people please chime in? I will not make this change if it isn't wanted, but it just seems to make sense to me and a few friends of mine who aren't on the list.
Again Ralph, I'm sorry for the way that comment came across. I truly would not want (nor have a reason) to offend/insult you or your work. I will try to be more cautious in the future and re-read before I send.
-Josh
Joshua A. Andler wrote:
It ties into the argument I had originally that some people think relationally (unit-wise) to whatever they're working with. If one is working in inches, centimeters, or pixels, it helps to have every thing that deals with units (in general) work in a uniform manner. If I have my document set to inches, grid set to inches, can use the transform dialog with inches, and (as it ties to the document-wide unit) my rulers show inches as well... doesn't it make sense to have inches available for snapping (especially with the new snapping types)? That's the only thing I'm trying to communicate.
I would have to agree with this, as a designer it is absolutely essential for me to know precise measurements that I may wish to reuse in, say, a suite of stationery and then send to a printer's. My printer may also call and question dimensions within a document - although it is rare, it could have been an eventuality in the last piece of work I produced, making a set of corporate banners and display signage which was set up on a kind of 'easel'. On both the hanging sign and the easel stand piece I had to be sure to avoid covering areas of the document which were to contain punch-holes. Snapping my document to exact inches or, in this case, millimetres, was essential.
I've been meaning to introduce myself to the list and say hi, but this thread seems an appropriate time - I joined initially in late 2004 while writing a review for Linux User and Developer magazine of GNU/Linux graphics software and its current potential for usability within a professional design environment. I rated Inkscape highly. Since then I've been away from the list for a while but decided I would like to rejoin, as my interests in joining was also to test the program and possibly contribute some constructive comments from the point of view of its use as part of a designer's suite.
This arose out of a discussion with RMS on the 'clunky' and counter-intuitive feel of many GNU/Linux graphics programs to designers; many others are very obviously written from a coder's point of view with menus obfuscated within the program and a counterintuitive interface. His words to me were - how is a coder to know what a designer needs unless you tell them? I was glad that I had found a way in which a non-coder could finally contribute to the Free Software community.
I must say that Inkscape made quite an impression on me even a year ago when I wrote my review - it is one of the few programs that combine both versatility and the intuitive feel which a designer needs; we need to feel that the interface is either invisible, or fits like a glove, not hindering our flow of ideas. I'd describe Inkscape as being in the latter category; its versatility means there is much to explore in the use of the interface. And I've got a lot to explore and a hell of a lot of catching up to do - even though verbal thinking isnt my natural realm, I'm impressed by the metadata page which looks interesting to explore.
Well.. I digress... but I'd just like to say hi to everyone, and hope that my comments and testing might be useful to your development work.
In my opinion, you have done a phenomenal job of simplifying the document properties dialog. It's clean, organized, and in general it makes much more sense and you can find things where you would expect them. I for one am greatly appreciative for the work you've put into this and sorry if it came across otherwise.
I must second this; as I said above, coming back to Inkscape after some months focusing on other work, I'm impressed at the improvements in usability of the entire program. There was a lot more to explore, but it was easy to pick up (unlike Adobe, actually ;p )....
best,
mC~
Quoting "miriam clinton (iriXx)" <iriXx@...568...>:
I would have to agree with this, as a designer it is absolutely essential for me to know precise measurements that I may wish to reuse in, say, a suite of stationery and then send to a printer's.
Well, bear in mind we're talking about snapping sensitivity here. As far as I can tell, that's a UI thing which is tied to screen and mouse characteristics rather than document dimensions, sort of like mouse acceleration.
The question is -- is your printer going to be interested in the snapping sensitivity of your mouse? Ever?
(This does also raise the question of whether snapping sensitivity should really be a per-document setting...)
-mental
p.s. Welcome back!
On 1/4/06, mental@...3... <mental@...3...> wrote:
(This does also raise the question of whether snapping sensitivity should really be a per-document setting...)
Good point. However, as long as we have people preferring snap sensitivity to be absolute units, this value is likely to be tied to grid snapping, and that being per-document, we have to keep sensitivity per-document as well.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
mental@...3... wrote:
Quoting "miriam clinton (iriXx)" <iriXx@...568...>:
I would have to agree with this, as a designer it is absolutely essential for me to know precise measurements that I may wish to reuse in, say, a suite of stationery and then send to a printer's.
Well, bear in mind we're talking about snapping sensitivity here. As far as I can tell, that's a UI thing which is tied to screen and mouse characteristics rather than document dimensions, sort of like mouse acceleration.
The question is -- is your printer going to be interested in the snapping sensitivity of your mouse? Ever?
(This does also raise the question of whether snapping sensitivity should really be a per-document setting...)
-mental
p.s. Welcome back!
Thanks! And apologies for my late reply... have been somewhat snowed under with work...
It seems that this topic has lead us into a hardware/software issue, somewhat akin to balancing color profiles when viewing on different monitors or with different graphics accelerators. For me, snapping sensetivity /ought/ to be something I have absolute control over with my requirements for print design, yet it seems from your description, if I read it correctly, that hardware-software communication may get in the way?
Personally, I desire absolute accuracy, but then again I also work in sound design and am accustomed to editing segments a few microseconds long - knowing that I can snap to the microsecond in ProTools - using flat-response studio monitor speakers... and get highly frustrated when I listen through speakers that have bass-boosting or nasty little PC speakers... ;)...
The per-document setting idea is interesting to me, particularly when it comes to working with both web and print design. For web, my computer is interested in the mouse only, and ymmv depending on web browsers... For print, I may be placing a design on a business card or custom-sized document and require to-the-millimitre accuracy or smaller when it comes to bleeds etc. Yes, I'm a perfectionist and fussy... but within a commercial environment sometimes this is necessary (I could post a scan of a colleague's business card as an example if anyone is interested).
I am not a coder, but simply commenting on the needs of users... It seems to me that the issue of whether snapping to this degree is possible depends not only on software but on hardware communication, and maybe even on the choice of desktop within GNU/Linux or Windows / Mac?...
mC~
NB...
Whoops... looks like I've been asleep over the last week or two and I've got another build to download... these comments may or may not be relevant now.... apologies if I'm covering old ground in trying to catch up with my mails...
On 1/12/06, Ralf Stephan <ralf@...748...> wrote:
not be relevant now.... apologies if I'm covering old ground in trying to catch up with my mails...
A threaded mailreader like mutt can be helpful here.
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) is definitely threads aware :-P
Alexandre
On 1/12/06, miriam clinton (iriXx) wrote:
mental@...3... wrote:
Well, bear in mind we're talking about snapping sensitivity here. As far as I can tell, that's a UI thing which is tied to screen and mouse characteristics rather than document dimensions, sort of like mouse acceleration.
The question is -- is your printer going to be interested in the snapping sensitivity of your mouse? Ever?
It seems that this topic has lead us into a hardware/software issue, somewhat akin to balancing color profiles when viewing on different monitors or with different graphics accelerators. For me, snapping sensetivity /ought/ to be something I have absolute control over with my requirements for print design, yet it seems from your description, if I read it correctly, that hardware-software communication may get in the way?
Maybe it helps if you first try to explain what snapping distance/sensitivity means to you? (i think you might have the wrong idea still, but i am not sure)
Personally, I desire absolute accuracy, but then again I also work in sound design and am accustomed to editing segments a few microseconds long - knowing that I can snap to the microsecond in ProTools - using flat-response studio monitor speakers... and get highly frustrated when I listen through speakers that have bass-boosting or nasty little PC speakers... ;)...
Being able to snap to microseconds (or millimeters) come from the grid spacing, not the snap distance.
Snap distance is how close to grid points you must come before snapping to them. Once an object has snapped to a grid point it has the exact position of that grid point. For the printed result it doesn't matter from how far away the snapping occurred (or whether the snap distance was configured in screen or document units).
On 1/4/06, miriam clinton (iriXx) <iriXx@...569...> wrote:
Snapping my document to exact inches or, in this case, millimetres, was essential.
Sure, but this is NOT what this setting is about. The setting is snapping sensitivity, a purely interactive thing.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
Quoting "Joshua A. Andler" <joshua@...533...>:
doesn't it make sense to have inches available for snapping
(especially with the new snapping types)?
No, why? I still don't get the argument. One's physical ability to move the mouse precisely doesn't change with zoom level.
Defining snap sensitivity in document units (versus screen units) just means that it's harder to get things to snap, the further out you zoom.
-mental
On 1/4/06, Joshua A. Andler <joshua@...533...> wrote:
It ties into the argument I had originally that some people think relationally (unit-wise) to whatever they're working with. If one is working in inches, centimeters, or pixels, it helps to have every thing that deals with units (in general) work in a uniform manner. If I have my document set to inches, grid set to inches, can use the transform dialog with inches, and (as it ties to the document-wide unit) my rulers show inches as well... doesn't it make sense to have inches available for snapping (especially with the new snapping types)?
To me, not at all. I think specifying snap sensitivity in document units makes about as much sense as specifying the size of the mouse cursor in document units, so it changes on zoom :)
However, we respected your request, and Ralph added that switch. (Even though I think you were the only one who insisted on that; many other people also initially requested that, but backed out after I explained the difference between grid spacing and snap sensitivity.)
And for the record, I do agree that your workforce is probably much better spent on bug fixing or whatever else YOU want to work on rather than infinitely tweaking this dialog. If there isn't great opposition, I will look into replacing 'absolute pixel' with the absolute unit combobox (based on my reasoning above). Will people please chime in? I will not make this change if it isn't wanted, but it just seems to make sense to me and a few friends of mine who aren't on the list.
Perfectly OK with me (if Ralf does not object).
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
You wrote
is there now way to have a scrollable metadata page? because it is
show me an example application, and I will steal the source.
OK, I thought that bulias question about keeping absolute units was about keeping cm/mm/... I'll juste test when this is finished, but not having cm for me who uses inkscape mostly for printed work might be annoying.
you don't understand. answer please: do you need snapping, where the snap distance changes with zoom. really?
ralf
the problem is that right now there is _always_ some snapping when the grid is on, even when nothing is checked in the grid snapping part. which is a bug in my opinion.
I cannot confirm this. Please give exact steps to reproduce.
OK it might be os X related only then. I'll try to build latest inkscape on linux. the steps are simple: open a new document, put the grid on, zoom enough so that all grid lines become visible, select the freehand tool and try to trace a straight line: it snaps to the grid though grid snapping is normaly disabled by default.
Its happening on last night's Windows build too - I ran a quick test and while the freehand line came out mostly free-looking, i felt a 'snap' at certain places as I drew, and some sections were angular.
The strange thing is that it only seemed to be happening in certain places - is that at all possible? I did have a large grid, but the squiggle I drew took up half the page.
mC~
On Wed, 4 Jan 2006, jiho wrote:
Date: Wed, 4 Jan 2006 18:23:43 +0100 From: jiho <jo.irisson@...400...> To: ralf@...748... Cc: Inkscape Devel List inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] Problem with Snapping/new Document Properties pannel
On 4 janv. 06, at 17:59, Ralf Stephan wrote:
builds. It is indeed smaller than the one of 0.43 but bigger on the 4th january (frames suppressed) than on the 24th decemeber (with frames). The main reason being a big metadata page I think.
Ah that's true, I moved the multiline input entries back to Metadata1 from Metadata2. But, now that Metadata2 is 'License' (which is much better imho), we can't put the two entities back, it would no longer be the License page.
Sorry.
is there now way to have a scrollable metadata page?
Please don't. I think there might be too much information to present it nicely in a Palette style dialog and I think a scrolling dialog might not be the best way to address the real problem.
the limiting factor now, all other tabs can be much smaller (75% of their current size at least), even the first one.
I think some of the features people want fast access to might be better presented as menu items. (Menu restructuring will be needed at some point anyway, having hardly any submenus was nice while it lasted.)
I would like to reiterate my suggestion that metadata have a seperate dialog. Many programs, particularly office programs have a "Properties" dialog which contains all kinds of "metadata", and Visio particularly has a dialog with lots of options for metadata/properties. (What Inkscape calls Document Preferences is much more like what other applications put under Page Setup, and to a lesser extent Preferences. I cannot think of any other applications with two menu itmes both labelled as preferences and I've always thought it was confusing.)
The way things are going we really do have enough metadata information to put it in a single dialog. Thinking about Licenses I wonder what users who are not already familiar with the various license types would make of it and if there might be some way to make it more self explanitory.
Sincerely
Alan Horkan http://advogato.org/person/AlanHorkan/
Quoting Alan Horkan <horkana@...44...>:
I would like to reiterate my suggestion that metadata have a seperate dialog. ... The way things are going we really do have enough metadata information to put it in a single dialog.
I'd like to second this, for what it's worth.
-mental
mental:
Quoting Alan Horkan <horkana@...44...>:
I would like to reiterate my suggestion that metadata have a seperate dialog. ... The way things are going we really do have enough metadata information to put it in a single dialog.
I'd like to second this, for what it's worth.
The (minor) problem with this is that Metadata is a document property, and now that the dialog has that name, it belongs there.
I don't think it would be a problem if the menu item (suggest 'Document Metadata') was placed directly under 'Document Properties'. Objections?
ralf
NB: sorry for double posting I sent previous mail by error.
wow, I didn't imagine that this post will lead to so much discussion! so:
SNAPPING SENSITIVITY: On 5 janv. 06, at 04:46, bulia byak wrote:
On 1/4/06, jiho <jo.irisson@...400...> wrote:
OK, I thought that bulias question about keeping absolute units was about keeping cm/mm/... I'll juste test when this is finished, but not having cm for me who uses inkscape mostly for printed work might be annoying.
Do you understand the difference between grid spacing and snap sensitivity?
I probably didn't and that was the problem ;-) My issue was about precision in snapping but in fact, playing with it more yesterday evening I remarked that setting the snapping to a very large number of screen pixels will only let me put nodes on grid points, which is exactly what I want for a precise work. My point with absolute units was that if you set your grid to 1cm and your snapping distance to
1cm the behavior above is guaranteed in a quite intuitive way and
whatever the zoom factor and that was how I used the snapping before. As Bryce noted, one has to actually use the feature on some real work to fully appreciate if he needs absolute units or not. I personally will be happy enough with only screen pixels and was only confused by the difference between screen pixels and px units which I didn't understand. One additional remark though. My confusion probably came from the fact that pixels where mentioned in the two snapping modes. In fact, the screen pixels do not have to be explicitly mentioned IMHO. It is just an "arbitrary" measure of snapping sensitivity and I do not think that the user really needs to know to how many screen pixels this is set. So I would second the suggestion to have "snap distance" renamed to something like "snap sensitivity" and suggest also that the scroll buttons go from 1 to 100 or 1 to 10 or something that does not mention screen pixels directly but underscores the fact that this is just a "measure" of sensitivity and that if you set it high, it will snap more.
From: bulia byak <buliabyak@...400...>
I have the tooltips. I still don't fully understand what px units are. I understand _how_ it works because it is explained but I still don't know what it means if I set it to 1.0, 2.0 or 90.0.
Simple. 1px = 0.8pt, so 1cm = 35.433px.
Previously, if my grid was every 1cm and that I set snapping distance to 1cm I knew thaht anything I draw will exactly snap to grid. what about now?
Se it to 35.433px.
OK now I understand. So px units are just what was previously called pixels :-) If absolute distances are to be kept I'll be with Joshua Andler for the complete set of absolute distances to be restored. Indeed I don't think that the user should have to calculate the equivalent of the distance he wants in pixels (i.e. what you did above). But once again, only one arbitrary measure of sensitivity will be ok for me as long as setting it to the maximum sets it to a sufficient number of screen pixels so that it always snap.
SNAPPING BUG: Begin forwarded message:
From: bulia byak <buliabyak@...400...> On 1/4/06, jiho <jo.irisson@...400...> wrote:
no. sorry if I explained it wrong. for snapping I'll probably be with bulia: snapping to grid should be enabled only when grid is on. the problem is that right now there is _always_ some snapping when the grid is on, even when nothing is checked in the grid snapping part. which is a bug in my opinion.
I cannot reproduce this (just tried).
probably a mac problem so. Fink (mac os x package manager) switched to gcc4 so some of my packages are build with gcc4, others with gcc3.3 and inkscape is build with gcc3.3 so I'll try to have everything complied with gcc4 and see what happens... but not soon I guess because recompiling everything will take some time.
However not that if you enable grid with # key, it turns on BOTH grid display and snapping to it (which makes sense). The dialog, if open, reflects both these changes immediately.
Yes that's nice but I only used the dialog.
From: "miriam clinton (iriXx)" <iriXx@...568...>
[...]
Its happening on last night's Windows build too - I ran a quick test and while the freehand line came out mostly free-looking, i felt a 'snap' at certain places as I drew, and some sections were angular. The strange thing is that it only seemed to be happening in certain places - is that at all possible? I did have a large grid, but the squiggle I drew took up half the page.
The problem appears everywhere for me. If you let everything by default snapping distance is 0.4 absolute px and grid is 1 px so there are chances that you do not see snapping everywhere. Try to only move the snapping to grid slider back and forth, it sets the distance to 1 px while not setting snapping on and you should see snapping everywhere afterwards.
DOCUMENT DIALOG: On 5 janv. 06, at 11:25, Ralf Stephan wrote:
mental:
Quoting Alan Horkan <horkana@...44...>:
I would like to reiterate my suggestion that metadata have a seperate dialog. ... The way things are going we really do have enough metadata information to put it in a single dialog.
I'd like to second this, for what it's worth.
The (minor) problem with this is that Metadata is a document property, and now that the dialog has that name, it belongs there.
I don't think it would be a problem if the menu item (suggest 'Document Metadata') was placed directly under 'Document Properties'. Objections?
I second this too, for what it's worth too :-) From a usability point of view it would be better IMHO: metadata is probably something you edit once for the document so the dialog can be large but the rest (page, grid, snap) might be changed often so the dialog has to be more compact in order to stay open at all time.
Thank you for all your work Ralf, I probably reacted a bit to soon because of the snapping bug which was preventing me to get some urgent work done. The rework of the dialog is great and will probably improve again if you implement a separate metadata dialog. I feel bad sending all these comments and not doing any real thing to improve it. I just hope it's not too "displaced" (I don't know if it is the correct word in english). Thanks a million anyway.
JiHO
On Thu, 5 Jan 2006, Ralf Stephan wrote:
Date: Thu, 5 Jan 2006 11:25:39 +0100 From: Ralf Stephan <ralf@...748...> To: mental@...3... Cc: Alan Horkan <horkana@...44...>, jiho <jo.irisson@...400...>, Inkscape Devel List inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] Problem with Snapping/new Document Properties pannel
mental:
Quoting Alan Horkan <horkana@...44...>:
I would like to reiterate my suggestion that metadata have a seperate dialog. ... The way things are going we really do have enough metadata information to put it in a single dialog.
I'd like to second this, for what it's worth.
The (minor) problem with this is that Metadata is a document property, and now that the dialog has that name, it belongs there.
Names can be changed. The important thing to do is think of the real problem being solved. Do not get hung up on cosmetic details, tweaking what we have already is okay but there are times when it is better to step back and reevaluate the problem and make sure we are not micro-optimising the problem.
I don't think it would be a problem if the menu item (suggest 'Document Metadata') was placed directly under 'Document Properties'. Objections?
I'd prefer to see Metadata take care of in a single Properties dialog (and have a menu item using the GTK_STOCK_PROPERTIES icon and label, because correct use of stock items gives lots of free localisation, leveraging all the work which has already been done translating the stock items and standard widgets).
A lot of what is currently described in Inkscape as Document Properties could go under "Page Setup", Preferences, or have specific menu items for fast access.
Back to metadata, I cannot think of users needing fast frequent access to the metadata dialog under more ordinary use working on one document at a time. There may more unusual cases of users with a collection of existing SVG files they want to tag the whole lot but if I recall correctly there are some Perl scripts for that kind of batch processing (written by Bryce?), and perhaps if we could provide an optional GTK frontend for those scripts? That way I think we could make users really happy, give them the kind of powerful batch processing and tagging functionality they really want and allow inkscape to have a metadata designed more for tagging the current document. (Hell if someone was really adventurous they might make an Inkscape extension out of it.)
- Alan H.
On Thu, Jan 05, 2006 at 04:35:50PM +0000, Alan Horkan wrote:
Back to metadata, I cannot think of users needing fast frequent access to the metadata dialog under more ordinary use working on one document at a time. There may more unusual cases of users with a collection of existing SVG files they want to tag the whole lot but if I recall correctly there are some Perl scripts for that kind of batch processing (written by Bryce?),
Yes, SVG::Metadata.
and perhaps if we could provide an optional GTK frontend for those scripts?
Doubtful. While some need the batch processing power of SVG::Metadata, I think the vast majority will fit in between - not enough images to process to need batch processing, but enough that efficiency doing it right within Inkscape would be appreciated.
Bryce
On Thu, 5 Jan 2006, Bryce Harrington wrote:
Date: Thu, 5 Jan 2006 09:42:54 -0800 From: Bryce Harrington <bryce@...961...> To: Alan Horkan <horkana@...44...> Cc: Inkscape Devel List inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] Metadata [was Re: Problem with ... Document Properties pannel]
On Thu, Jan 05, 2006 at 04:35:50PM +0000, Alan Horkan wrote:
Back to metadata, I cannot think of users needing fast frequent access to the metadata dialog under more ordinary use working on one document at a time. There may more unusual cases of users with a collection of existing SVG files they want to tag the whole lot but if I recall correctly there are some Perl scripts for that kind of batch processing (written by Bryce?),
Yes, SVG::Metadata.
I meant the specific metadata scripts rather than the general functionality for manipulating SVG, specifically some of the tagging scripts I believe Bryce wrote to help with OpenClipart.org (I'd look it up if I weren't stuck on dialup).
and perhaps if we could provide an optional GTK frontend for those scripts?
Some users are extremely averse to using the command line. I got over it eventually but most of the time I'd prefer a simple GUI frontend to having to read a manual page and use a command line app.
Zenity might be enough to provide simple list GUI or if more was needed possible something quick and dirty in glade, maybe something like so:
label [ value ] label [ value ] label [ value ] label [ value ]
[Cancel] [OK]
Doubtful. While some need the batch processing power of SVG::Metadata, I think the vast majority will fit in between - not enough images to process to need batch processing, but enough that efficiency doing it right within Inkscape would be appreciated.
I see some features (like the Export) being added to and tweaked over and over and fear micro-optimisation which doesn't quite go far enough for the power users and baffles the beginners. I hope the balance can be maintained between Inkscape as a straighforward application with a Single Document Interface (in the broadest sense) while also being very fast and efficient for users working on repative tasks. I guess I'm trying to say I hope developers will be inspired by the requests for lots of little tweaks to dialogs and then see the bigger picture and streamline the task not just the repitition. (That was supposed to sound encouraging...)
Sincerely
Alan Horkan
Inkscape http://inkscape.org Abiword http://www.abisource.com Dia http://gnome.org/projects/dia/ Open Clip Art http://OpenClipArt.org
Alan's Diary http://advogato.org/person/AlanHorkan/
On Thu, Jan 05, 2006 at 09:54:50PM +0000, Alan Horkan wrote:
SVG files they want to tag the whole lot but if I recall correctly there are some Perl scripts for that kind of batch processing (written by Bryce?),
Yes, SVG::Metadata.
I meant the specific metadata scripts rather than the general functionality for manipulating SVG, specifically some of the tagging scripts I believe Bryce wrote to help with OpenClipart.org (I'd look it up if I weren't stuck on dialup).
The SVG::Metadata package includes several scripts for manipulating the SVG as well, so it's a handy self contained kit. ;-)
and perhaps if we could provide an optional GTK frontend for those scripts?
Some users are extremely averse to using the command line. I got over it eventually but most of the time I'd prefer a simple GUI frontend to having to read a manual page and use a command line app.
I'm not saying it wouldn't be useful, just that it's not something I'm at all likely to work on.
Doubtful. While some need the batch processing power of SVG::Metadata, I think the vast majority will fit in between - not enough images to process to need batch processing, but enough that efficiency doing it right within Inkscape would be appreciated.
I see some features (like the Export) being added to and tweaked over and over and fear micro-optimisation which doesn't quite go far enough for the power users and baffles the beginners. I hope the balance can be maintained between Inkscape as a straighforward application with a Single Document Interface (in the broadest sense) while also being very fast and efficient for users working on repative tasks. I guess I'm trying to say I hope developers will be inspired by the requests for lots of little tweaks to dialogs and then see the bigger picture and streamline the task not just the repitition. (That was supposed to sound encouraging...)
I suspect 'tweaks' are a lot more time efficient than grand sweeping big pictures. ;-)
Bryce
Alan Horkan wrote:
I don't think it would be a problem if the menu item (suggest 'Document Metadata') was placed directly under 'Document Properties'. Objections?
I'd prefer to see Metadata take care of in a single Properties dialog (and have a menu item using the GTK_STOCK_PROPERTIES icon and label, because correct use of stock items gives lots of free localisation, leveraging all the work which has already been done translating the stock items and standard widgets).
A lot of what is currently described in Inkscape as Document Properties could go under "Page Setup", Preferences, or have specific menu items for fast access.
Back to metadata, I cannot think of users needing fast frequent access to the metadata dialog under more ordinary use working on one document at a time. There may more unusual cases of users with a collection of existing SVG files they want to tag the whole lot but if I recall correctly there are some Perl scripts for that kind of batch processing (written by Bryce?), and perhaps if we could provide an optional GTK frontend for those scripts? That way I think we could make users really happy, give them the kind of powerful batch processing and tagging functionality they really want and allow inkscape to have a metadata designed more for tagging the current document. (Hell if someone was really adventurous they might make an Inkscape extension out of it.)
- Alan H.
I would agree with this as a user and a barely literate coder (HTML/CSS/ActionScript and some very basic shell scripts are about as far as I go); when I am designing I am thinking entirely pictorially, and while I may need absolute accuracy, that is either for the purposes of print work or quite often for proportional alignment - the eye of a graphic designer is as fussy as the ear of a sound editor when it comes to being able to see misalignment down to the millimetre level or smaller. If I can do something quickly with a front-end, it doesnt interfere with the creative process.
Metadata to me is a curiousity, yet with the push towards SVG implementation, it may also become a necessity, particularly within the Free Software world. Using a dialog is essential for the most part of my work, as I cannot wear two hats when it comes to design and coding at the same time - I am in a dream-world when I design, thinking purely in pictures and throwing my vision on to the page, and I cannot interrupt the flow to work with verbal data. How I manage web design is a different matter, it is a case of cutting and pasting at a later stage, but again, visual thinking is prime - one reason why I still find GNU/Linux impossible for creating websites, even Quanta is difficult for me as it has not fully implemented dialogs and WYSIWYG layout (tables are a nightmare - the last time I used Quanta a table would be placed in the code but not visible on-screen).
So a front end would be preferable for me - but the idea of access to metadata is also irresistable... having looked briefly at the metadata editing within Inkscape, this gives me ideas of 'playing' and producing rather random results, without knowing any code.. just messing with what is already on the screen. Yes, we artists will do rather terrible things with your software! sometimes this desire to play produces fruitless results, sometimes it causes everything to crash... but in the process, sometimes it will create something I may not have been able to do otherwise through an entirely random process.
An analogy - I use Ceres3 and Mammut for sound design work, but I know nothing about FFT other than the visual editing that I can do in Ceres3 and some very basic understanding of acoustics/psychoacoustics; that which I need to know to produce the results that my ears will do intuitively given a nice dialog. Yet sometimes I will pull out the highly mathematical options available in these programs and type in completely random numbers. What comes out will occasionally be rubbish but often be quite curious - there are bell-like sounds I can make in Mammut by typing in a negative figure for a certain option (can't even remember what the function was!) which I cannot produce in any other program. It was just something I stumbled upon and can repeat by typing in similiar random numbers within a certain range. I have absolutely no idea of what I am doing technically, but I love the result.
This artistic curiousity I would apply to metadata as well... I may be designing a complex piece of art (something like the Peter Gabriel series on http://www.irixx.org/print.html) and simply play with it to produce random effects. Which in all likelyhood will be awful... but who knows? If it works once out of ten, that is enough to encourage me to keep playing...
In short... I'm suggesting a front-end would be essential for a visually-oriented designer's needs, but having access to metadata is a curiousity that I cannot resist playing with.
mC~
On 1/4/06, jiho <jo.irisson@...400...> wrote:
OK, I thought that bulias question about keeping absolute units was about keeping cm/mm/... I'll juste test when this is finished, but not having cm for me who uses inkscape mostly for printed work might be annoying.
Do you understand the difference between grid spacing and snap sensitivity?
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
wow, I didn't imagine that this post will lead to so much discussion! so:
SNAPPING SENSITIVITY: On 5 janv. 06, at 04:46, bulia byak wrote:
On 1/4/06, jiho <jo.irisson@...400...> wrote:
OK, I thought that bulias question about keeping absolute units was about keeping cm/mm/... I'll juste test when this is finished, but not having cm for me who uses inkscape mostly for printed work might be annoying.
Do you understand the difference between grid spacing and snap sensitivity?
I probably didn't and that was the problem ;-) My issue was about precision in snapping but in fact, playing with it more yesterday evening I remarked that setting the snapping to a very large number of screen pixels will only let me put nodes on grid points, which is exactly what I want for a precise work. My point with absolute units was that if you set your grid to 1cm and your snapping distance to
1cm the behavior above is guaranteed in a quite intuitive way and
whatever the zoom factor and that was how I used the snapping before. As Bryce noted, one has to actually use the feature on some real work to fully appreciate if he needs absolute units or not. I personally will be happy enough with only screen pixels and was only confused by the difference between screen pixels and px units which I didn't understand. One additional remark though. My confusion probably came from the fact that pixels where mentioned in the two snapping modes. In fact, the screen pixels do not have to be explicitly mentioned IMHO. It is just an "arbitrary" measure of snapping sensitivity and I do not think that the user really needs to know to how many screen pixels this is set. So I would second the suggestion to have "snap distance" renamed to something like "snap sensitivity" and suggest also that the scroll buttons go from 1 to 100 or 1 to 10 or something that does not mention screen pixels directly but underscores the fact that this is just a "measure" of sensitivity and that if you set it high, it will snap more.
From: bulia byak <buliabyak@...400...>
I have the tooltips. I still don't fully understand what px units are. I understand _how_ it works because it is explained but I still don't know what it means if I set it to 1.0, 2.0 or 90.0.
Simple. 1px = 0.8pt, so 1cm = 35.433px.
Previously, if my grid was every 1cm and that I set snapping distance to 1cm I knew thaht anything I draw will exactly snap to grid. what about now?
Se it to 35.433px.
OK now I understand. So px units are just what was previously called pixels. If absolute distances are to be kept I'll be with Joshua Andler for the complete set of absolute distances to be restored. Indeed I don't think that the user should have to calculate the equivalent of the distance he wants in pixels (i.e. what you did above). But once again, only one arbitrary measure of sensitivity will be ok for me as long as setting it to the maximum sets it to a sufficient number of screen pixels so that it always snap.
SNAPPING BUG: Begin forwarded message:
From: bulia byak <buliabyak@...400...> On 1/4/06, jiho <jo.irisson@...400...> wrote:
no. sorry if I explained it wrong. for snapping I'll probably be with bulia: snapping to grid should be enabled only when grid is on. the problem is that right now there is _always_ some snapping when the grid is on, even when nothing is checked in the grid snapping part. which is a bug in my opinion.
I cannot reproduce this (just tried).
probably a mac problem so. Fink (mac os x package manager) switched to gcc4 so some of my packages are build with gcc4, others with gcc3.3 and inkscape is build with gcc3.3 so I'll try to have everything complied with gcc4 and see what happens... but not soon I guess because recompiling everything will take some time.
However not that if you enable grid with # key, it turns on BOTH grid display and snapping to it (which makes sense). The dialog, if open, reflects both these changes immediately.
Yes that's nice but I only used the dialog.
On 1/5/06, jiho <jo.irisson@...400...> wrote:
Do you understand the difference between grid spacing and snap sensitivity?
I probably didn't and that was the problem ;-) My issue was about precision in snapping but in fact, playing with it more yesterday evening I remarked that setting the snapping to a very large number of screen pixels will only let me put nodes on grid points, which is exactly what I want for a precise work.
Cool, thanks for the clarification. This (AFAIK) again leaves Scislac as the only person who insists on specifying snap sensitivity in document units :)
One additional remark though. My confusion probably came from the fact that pixels where mentioned in the two snapping modes. In fact, the screen pixels do not have to be explicitly mentioned IMHO. It is just an "arbitrary" measure of snapping sensitivity and I do not think that the user really needs to know to how many screen pixels this is set. So I would second the suggestion to have "snap distance" renamed to something like "snap sensitivity"
Agree, and I already proposed that, with most people supporting it. Ralf, can you please do the rename?
and suggest also that the scroll buttons go from 1 to 100 or 1 to 10 or something that does not mention screen pixels directly but underscores the fact that this is just a "measure" of sensitivity and that if you set it high, it will snap more.
To me, 10 is too small, but 100 is too much. Other opinions?
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
bulia byak wrote:
On 1/5/06, jiho <jo.irisson@...400...> wrote:
Do you understand the difference between grid spacing and snap sensitivity?
I probably didn't and that was the problem ;-) My issue was about precision in snapping but in fact, playing with it more yesterday evening I remarked that setting the snapping to a very large number of screen pixels will only let me put nodes on grid points, which is exactly what I want for a precise work.
Cool, thanks for the clarification. This (AFAIK) again leaves Scislac as the only person who insists on specifying snap sensitivity in document units :)
No, I too insist on it. And to make matters worse your Con is my Pro. :) You say "screen based snapping units stop the snapping from jumping across the screen at high zoom." I say "Document based snapping units allow me to enforce alignment to a grid even at high zoom." When I say enforce I mean lines fall only on the grid no matter what, and never in the no-mans-land between adjacent snapping thresholds. I still believe both camps are legitimate use cases. (And the "enforcement" camp can benefit from snapping to gridlines that have become hidden because of super low zooms too. :) )
Aaron Spike
On 1/5/06, aaron@...749... <aaron@...749...> wrote:
No, I too insist on it. And to make matters worse your Con is my Pro. :) You say "screen based snapping units stop the snapping from jumping across the screen at high zoom." I say "Document based snapping units allow me to enforce alignment to a grid even at high zoom."
As jiho has just explained, getting this enforcement is just a matter of a very high sensitivity, no matter what units. Will you be satisfied by a 2000 screen pixel sensitivity, which enforces snapping at ANY zoom?
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
bulia byak wrote:
On 1/5/06, aaron@...749... <aaron@...749...> wrote:
No, I too insist on it. And to make matters worse your Con is my Pro. :) You say "screen based snapping units stop the snapping from jumping across the screen at high zoom." I say "Document based snapping units allow me to enforce alignment to a grid even at high zoom."
As jiho has just explained, getting this enforcement is just a matter of a very high sensitivity, no matter what units. Will you be satisfied by a 2000 screen pixel sensitivity, which enforces snapping at ANY zoom?
I will be satisfied by the functionality, until the resolution of my monitor increases beyond that. :) I had thought that document units made more sense because it doesn't require one to switch domains, first thinking about the size of the grid in document units and then thinking about screen pixels. But given that, it actually would require less thought if the interface was cluttered with an "Enforce snapping to grid" checkbox, which I believe had been suggested before.
Aaron Spike
aaron@...749... wrote:
bulia byak wrote:
On 1/5/06, aaron@...749... <aaron@...749...> wrote:
No, I too insist on it. And to make matters worse your Con is my Pro. :) You say "screen based snapping units stop the snapping from jumping across the screen at high zoom." I say "Document based snapping units allow me to enforce alignment to a grid even at high zoom."
As jiho has just explained, getting this enforcement is just a matter of a very high sensitivity, no matter what units. Will you be satisfied by a 2000 screen pixel sensitivity, which enforces snapping at ANY zoom?
I will be satisfied by the functionality, until the resolution of my monitor increases beyond that. :) I had thought that document units made more sense because it doesn't require one to switch domains, first thinking about the size of the grid in document units and then thinking about screen pixels. But given that, it actually would require less thought if the interface was cluttered with an "Enforce snapping to grid" checkbox, which I believe had been suggested before.
And the switching domains is part what my argument had been about (things remaining in the same unit, the other part would be it remaining relative to scale). Bulia, please also recognize that A) only a small fraction of our users participate on the lists and B) that you can be VERY intimidating to people that don't know you... So, making an argument based on how many people speak up is far from an accurate method to gage things. In addition to that, it almost seems like when you ask these questions on the list, you do it as a formality only with no intention of it potentially making a difference in what you have planned. Your argument is always "you still haven't convinced me", and the reality is, you're about as easy to convince as talking to a devout religious person of a different faith about why your religion/beliefs is/are just as valid as theirs is. So, pardon me if this message has any emotion tied to it (specifically the end).
In the last message I wrote, I had mentioned a few friends of mine (that don't even do email, much less participate on the lists) that desire keeping absolute units as well. Two of them specifically work with metal and wood (note the "blue collar" nature of their work). They are far from what you would consider tech savvy. And truthfully, they don't know and have no need to know what a pixel is... they just need Inkscape to keep working like it has. In the real world, they most commonly work in inches or millimeters (or whatever measurement their clients request), and therefore in the "virtual" realm when they're making templates in Inkscape they're using those same units. One issue other the "pixel" unit being useless and meaningless to them is that when they're working with angles or curves, the grid (which you keep bringing up in this discussion) is of little or no use to them. For note, over the past few weeks they've really grown fond of the new object and node snapping stuff (as opposed to bbox that they used before).
When it comes to working with Inkscape, the absolute units make sense. Snapping with absolute units (other than pixel) also makes sense to them. You had mentioned that having snap change with zoom makes as much sense as the cursor changing being scaled with zoom, which is an inaccurate comparison. I'd liken it more to working with a map and the Scale "meter" not magnifying with the rest of the map. According the map, a km is a km is a km, and it stays relevant to the level of magnification. Let's use military troops as an example for this. If any of my troops are within .3 km of either point A, B, or C, I want them to go to that point. If they're not within that .3 km, they can stay where they are. If my map is just a world map, .3 km is impossible to see... however if it's scalable to the point where I can differentiate by .01km, it becomes more workable. And if I'm zoomed in to see that .01km, .3km will be nice and gigantic, and [drum roll please] it will make sense (since it's what I set).
As one of my friends had pointed out, if he moves his face closer or further away from a piece of wood (in the physical world of course), it doesn't change what size the measurement is. If he marks the start and end of an inch on a board and moves his face really close to it, the inch looks bigger (as our rulers and canvas work). Therefore he would expect that if he sets .0625 (1/16th) inches for snapping, that it scales with the zoom level and rulers (moving the face closer/further in relation to the virtual board). He also said that if he stands at arms length away from the board and tries to do something useful in that small of an increment, it's just not possible and it shouldn't be, some things require getting in close to do detail. Absolute units (with regard to snapping) in Inkscape give him the same "feel" for the scale of things as if he were working in the physical world.
It does feel like this last ditch attempt at trying to make the point that different users use inkscape differently and they also don't all think the same, will fall on deaf ears. From what a few other users (those friends) have communicated to me, it's not just myself that thinks in units other than screen pixels with regard to snapping. Whatever, this was probably a waste of my time and energy... so fine, I concede... forget absolute units with snapping... I'll retrain myself and teach those friends all about pixels. If you guys have no use for them, obviously no one else should and anyone that does is just dumb or otherwise not "clued in" to your superior understanding of what /should/ make sense to them.
I guess part of my frustration stems from the fact that this feature already existed and is useful to some users (even if it is a niche). In reality, (just like the real world where minorities don't matter... unless you're one of them) perhaps the best solution would be a key combo or whatever to toggle object snapping only as Bulia had briefly mentioned before. This way they won't worry about snapping at far distances, and when they need to use it, it will be easy enough to toggle on and off.
Note: I didn't have a chance to proof read before sending, sorry for any incomplete thoughts.
-Josh
On 1/6/06, Joshua A. Andler <joshua@...533...> wrote:
B) that you can be VERY intimidating to people that don't know you...
Joshua, I realize that what I'm now going to say may not sound very polite, but I have to ask you (and everyone else) to please stop making such accusations without supporting them with any facts. I strive to be extremely polite and to the point in everything I write. Maybe I fail sometimes, but then I would apprecitate specific pointers to such occasions. Sorry but I'm getting tired of this "bbyak is intimidating" talk which is never adequately proven or even explained. If you are prepared to make a case against me supported by evidence, I would like to hear, and I will apologize if proven wrong. If you are not prepared to do this, I would appreciate your keeping your opinion about me in private. Is this not too much to ask?
Specifically in this case, a lot of people initially protested against this change, despite my "intimidation". And what made them change their mind was again not "intimidation" but a better explanation of what is being proposed as well as an extension of the original proposal (adding the "Always snap" checkbox for grid).
So, making an argument based on how many people speak up is far from an accurate method to gage things. In addition to that, it almost seems like when you ask these questions on the list, you do it as a formality only with no intention of it potentially making a difference in what you have planned.
That's simply not correct. You asked for abs units, you got them.
OK, knowing that you have worked with Illustrator, I went there and checked how it implements this. It's version 9, but I don't think much has changed in this department since then. Here are my findings:
- For grid: Snapping is always forced, i.e. even if the grid cell takes all screen, you will snap to grid across half the screen no matter what. This is what we will have with "Always snap" checkbox.
- For guides: Snapping distance is very small (2 or 3 pixels maybe), not settable anywhere I could find, and most importantly, it's definitely IN SCREEN PIXELS. So, if I zoom out, I will snap from farther away in document units than when zoomed in.
So, by your definition, Illustrator seems to be unfit for work with real world units, right? :)
Anyway, this little problem definitely takes way more of my energy than it deserves. I will not respond to your accusations that "we ignore you", because the best refutation to this is just a look at the current dialog which, per your request, DOES have abs pixels as an option. I am sorry (really) that we lost all other abs units in this transition, but it wasn't me who coded that. As I wrote already, you are perfectly welcome to add a full units dropdown back, it should not be too difficult. I hope this closes the issue; at least I very much hope to be able to not write about this anymore.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
bulia byak wrote:
On 1/6/06, Joshua A. Andler <joshua@...533...> wrote:
B) that you can be VERY intimidating to people that don't know you...
Joshua, I realize that what I'm now going to say may not sound very polite, but I have to ask you (and everyone else) to please stop making such accusations without supporting them with any facts. I strive to be extremely polite and to the point in everything I write. Maybe I fail sometimes, but then I would apprecitate specific pointers to such occasions. Sorry but I'm getting tired of this "bbyak is intimidating" talk which is never adequately proven or even explained. If you are prepared to make a case against me supported by evidence, I would like to hear, and I will apologize if proven wrong. If you are not prepared to do this, I would appreciate your keeping your opinion about me in private. Is this not too much to ask?
It is not too much to ask. But, intimidation is a feeling and not easily rationalized or explained. So it may be difficult to give examples that prove. I'm convinced that this feeling of intimidation is caused by differences of culture and language. In my dealings with you I initially felt intimidated. But as I realized that English isn't your first language (which is easy to forget because you have a perfect grasp on grammar and spelling) I realized that the force with which I understood your words was not the force with which you had written them. It is these dynamics that make international interpersonal communication interesting, I think we as a community are doing pretty well.
Aaron Spike
On 1/6/06, aaron@...749... <aaron@...749...> wrote:
It is not too much to ask. But, intimidation is a feeling and not easily rationalized or explained.
OK, I guess you are right, and we'll have to write this off to cultural differences. For me, "intimidation" is a very harsh and specific accusation, which implies an easily demonstrable type of behavior. If instead of "intimidating" you would say "opinionated" or "strong-worded", I would not argue at all. But "intimidating", to me, implies an evil intent on my part, which I find rather insulting. Sorry if this was a misinterpretation.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
On Fri, 2006-01-06 at 09:32 -0700, Joshua A. Andler wrote:
He also said that if he stands at arms length away from the board and tries to do something useful in that small of an increment, it's just not possible and it shouldn't be, some things require getting in close to do detail. Absolute units (with regard to snapping) in Inkscape give him the same "feel" for the scale of things as if he were working in the physical world.
So, it's an issue of the physical analogy making it easier to work with?
-mental
MenTaLguY wrote:
On Fri, 2006-01-06 at 09:32 -0700, Joshua A. Andler wrote:
He also said that if he stands at arms length away from the board and tries to do something useful in that small of an increment, it's just not possible and it shouldn't be, some things require getting in close to do detail. Absolute units (with regard to snapping) in Inkscape give him the same "feel" for the scale of things as if he were working in the physical world.
So, it's an issue of the physical analogy making it easier to work with?
I guess so. At least for him since that's what he said. For me, personally, it isn't about physical analogy because 90% of my stuff ends up rasterized... absolute pixels (snapping-wise) in a document with set pixel dimensions just makes more sense while I'm working with it. With my case, perhaps it's more of a raster mentality, but unfortunately Inkscape has kept me trained in this way.
I vote that the conversation be done though... please?
-Josh
On 1/6/06, aaron@...749... <aaron@...749...> wrote:
I will be satisfied by the functionality, until the resolution of my monitor increases beyond that. :) I had thought that document units made more sense because it doesn't require one to switch domains, first thinking about the size of the grid in document units and then thinking about screen pixels. But given that, it actually would require less thought if the interface was cluttered with an "Enforce snapping to grid" checkbox, which I believe had been suggested before.
Exactly. So what I would like to propose is:
Sensitivity: [========] 12 [x] Always snap
with slider range of e.g. 0..50; when the checkbox is on, the slider is disabled. Note that the checkbox is there only for grid snapping, as it makes no sense for guides and object snapping. Internally, the checkbox sets the sensitivity e.g. to 10000. The screen/document units switch is then removed.
Will this satisfy everyone?
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
bulia byak wrote:
On 1/6/06, aaron@...749... <aaron@...749...> wrote:
I will be satisfied by the functionality, until the resolution of my monitor increases beyond that. :) I had thought that document units made more sense because it doesn't require one to switch domains, first thinking about the size of the grid in document units and then thinking about screen pixels. But given that, it actually would require less thought if the interface was cluttered with an "Enforce snapping to grid" checkbox, which I believe had been suggested before.
Exactly. So what I would like to propose is:
Sensitivity: [========] 12 [x] Always snap
with slider range of e.g. 0..50; when the checkbox is on, the slider is disabled. Note that the checkbox is there only for grid snapping, as it makes no sense for guides and object snapping. Internally, the checkbox sets the sensitivity e.g. to 10000. The screen/document units switch is then removed.
Will this satisfy everyone?
This satisfies my functional needs. Is there a further refinment we can make to address the shift in thought that is required by screen pixels vs document units? I'm only asking because I don't know if the handy "Always snap" checkbox satifies everything. Will a user ever think, "I want all points within 1/4 inch to snap to the 1 inch grid but points in the mid 1/2 inch need not be snapped?" That is the functionality we are losing, right? I think just about everyone is ready for a hands on trial of the new model (with complaints to follow, of course). :)
Aaron Spike
Aaron wrote
as the only person who insists on specifying snap sensitivity in document units :)
No, I too insist on it. And to make matters worse your Con is my Pro. :) You say "screen based snapping units stop the snapping from jumping across the screen at high zoom." I say "Document based snapping units allow me to enforce alignment to a grid even at high zoom." When I say enforce I mean lines fall only on the grid no matter what, and never in the no-mans-land between adjacent snapping thresholds. I still believe both camps are legitimate use cases. (And the "enforcement" camp can benefit from snapping to gridlines that have become hidden because of super low zooms too.
This is theoretical, not a use case. A use case involves you using the selector tool for moving an object on the screen, not some objects lying in the grid and mysteriously snapping to it or not.
Your argument supports my suspicion that you both are simply being facetous here.
ralf
Ralf Stephan wrote:
Your argument supports my suspicion that you both are simply being facetous here.
http://sourceforge.net/mailarchive/message.php?msg_id=14302471
Making well aligned rectangles with 1px borders to avoid the appearance of anti-aliasing in a diagram.
:P
Aaron Spike
On 1/6/06, bulia byak wrote:
On 1/5/06, jiho <jo.irisson@...400...> wrote:
and suggest also that the scroll buttons go from 1 to 100 or 1 to 10 or something that does not mention screen pixels directly but underscores the fact that this is just a "measure" of sensitivity and that if you set it high, it will snap more.
To me, 10 is too small, but 100 is too much. Other opinions?
If 100 is too much for regular use could not 100 mean 100% snapping (enforce snapping at any zoom)? Or would it be more obvious to add a checkbox that toggles forced snapping on and off?
A sensitivity max of 2000 (when most people would only use values in the range 2-20 depending on their screen resolution) sounds rather baroque. Implementing 100% snapping might be possible with such a high value, but users should not have to bother.
On 6 janv. 06, at 09:05, Ulf Erikson wrote:
On 1/6/06, bulia byak wrote:
On 1/5/06, jiho <jo.irisson@...400...> wrote:
and suggest also that the scroll buttons go from 1 to 100 or 1 to 10 or something that does not mention screen pixels directly but underscores the fact that this is just a "measure" of sensitivity and that if you set it high, it will snap more.
To me, 10 is too small, but 100 is too much. Other opinions?
If 100 is too much for regular use could not 100 mean 100% snapping (enforce snapping at any zoom)? Or would it be more obvious to add a checkbox that toggles forced snapping on and off?
I meant exactly that with my 10 or 100 in fact. I saw it as a snapping sensitivity percentage, no matter what is behind 100 in term of screen pixels. maybe something non linear could be done there. I looked for a nice function from 1 to 100 but I'm not so good at maths. Maybe two functions: - x/2 from 1 to 70 (goes from 0.5 to 35 which seems reasonable and usable) - 1200*(exp((x/100)^10)-0.999) from 70 to 100 (goes from 35 to around 2000) the function looks like this in the end: http://jo.irisson.free.fr/dropbox/functions.pdf The power function can be increased to have a steeper climb and keep things more linear from 70 to say 90. I don't know if it is possible to reflect the non linearity in the interface (have a red gradient starting from 70 for example) but it will do what people expect so I guess it won't be too much of a problem.
A sensitivity max of 2000 (when most people would only use values in the range 2-20 depending on their screen resolution) sounds rather baroque. Implementing 100% snapping might be possible with such a high value, but users should not have to bother.
And this takes care of the 100% snapping without being so baroque I think.
JiHO
On 1/4/06, jiho <jo.irisson@...400...> wrote:
no. sorry if I explained it wrong. for snapping I'll probably be with bulia: snapping to grid should be enabled only when grid is on. the problem is that right now there is _always_ some snapping when the grid is on, even when nothing is checked in the grid snapping part. which is a bug in my opinion.
I cannot reproduce this (just tried).
However not that if you enable grid with # key, it turns on BOTH grid display and snapping to it (which makes sense). The dialog, if open, reflects both these changes immediately.
I have the tooltips. I still don't fully understand what px units are. I understand _how_ it works because it is explained but I still don't know what it means if I set it to 1.0, 2.0 or 90.0.
Simple. 1px = 0.8pt, so 1cm = 35.433px.
Previously, if my grid was every 1cm and that I set snapping distance to 1cm I knew thaht anything I draw will exactly snap to grid. what about now?
Se it to 35.433px.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
On 1/4/06, Ralf Stephan <ralf@...748...> wrote:
Do you mean you want 'snapping to invisible grid'? I'm for it. I remember, though, this is contrary to Bulia's opinion.
As far as I remember, NOT snapping to invisible lines was more or less a consensus. (By the way, thanks Mathieu for implementing this!)
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
participants (13)
-
unknown＠example.com -
aaron＠...749... -
Alan Horkan -
Alexandre Prokoudine -
Bryce Harrington -
bulia byak -
jiho -
Joshua A. Andler -
Mathieu Dimanche -
MenTaLguY -
miriam clinton (iriXx) -
Ralf Stephan -
Ulf Erikson