Sebastian, I've seen a lot of people using the 'set page border color' option when they are using a dark background for their drawings. Where would that option go? Or did you mean to remove that completely? As guides colors are document-specific (as far as I understand), having them set in the preferences doesn't make a lot of sense to me. I imagine that the best guide color also depends upon the selected background color for the document, and as such should either also be in a separate 'Guide' dialog, or stay where it is. The coupling of document units and page size units, mmh. I think it would simplify things for new users. For myself, I don't like it too much. I like the Licences being put into the Metadata section and the 'Save as template' option a lot. The change to the colors tab also is really nice. And the cancel button is really useful (so the document will not be resized while you're still entering the values, and you can change your mind, too, without several actions happening in the background). What I always find difficult about these kinds of dialogs, though, is that I never know if I need to hit OK for each tab separately, or if it will apply for everything I changed in all tabs (different programs do this differently). Is there an UI way to make this really obvious? Will the dialog close automatically upon hitting OK? Regards, Maren Am 28.05.2016 um 12:21 schrieb Brynn:

On Sun, May 29, 2016 at 11:46 AM, Sebastian Zartner < sebastianzartner@...400...> wrote: I don't agree with this. In one document you might have aligned your objects using visual bounding boxes, to a grid of 1/8", whereas in another document you might have aligned the center of your paths to a 5 mm grid. In another document, you might have designed icons on the pixel level with a pixel grid. This is all very different for various workflows or projects. If these snap and grid settings are not remembered per document, then for every document you open you would first need to zoom in, figure out what has been used for alignment and at what pitch, try to find out where the origin of the grid was (if that was not at 0,0), and re-apply the grid and snap settings. This is not a good idea, because it's cumbersome and error prone. Some snap settings are indeed more global, for example the ones related to the sensitivity of the snapping, and that's why these are in the preferences dialog already. Diederik

Respectfully, I disagree. Grids tab: Sometimes I might have 2 or 3 grids in 1 file (although only 1 at a time is visible). But other times, no grids at all. So this is very much a "per document" feature for me. Snap tab: I don't usually change those snap settings. So such a change probably would not affect me. But I can imagine some people probably change them per document. Display section on Page tab (page border, color, shadow, antialiasing): I hide and display the page border, sometimes several times per document. I do it so often sometimes, I've wished for a key shortcut! While in some documents, I never use it. It doesn't seem appropriate to take it out of Doc. Props. (to me). (I want it out of the way while I'm drawing. But then from time to time, I want to see it, to judge the overall visual balance and scale of the drawing as a whole.) Although I suppose one could use Guides instead. From that point of view, the border could be eliminated. But I think it's just too convenient of a feature, to get rid of. For me, the border shadow could be eliminated. I never use it. But I have no idea about how other people use it. I also think antialiasing is a "per document" feature. From time to time, in forums, we suggest changing that for a particular image or file. Guides tab: I didn't originally comment on Guides, but I see them as very much a "per document" feature. All best, brynn -------------------------------------------------- From: "Sebastian Zartner" <sebastianzartner@...400...> Sent: Sunday, May 29, 2016 3:46 AM To: "Maren Hachmann" <maren@...3165...>; "Brynn" <brynn@...3133...> Cc: "Inkscape" <inkscape-devel(a)lists.sourceforge.net&gt; Subject: Re: [Inkscape-devel] [UI] Rework Document Properties dialog > Hi Brynn, hi Maren, > > thank you for the feedback! > > On 28 May 2016 at 12:21, Brynn <brynn@...3133...> wrote: > > On 28 May 2016 at 16:13, Maren Hachmann <maren@...3165...> wrote: >> Sebastian, I've seen a lot of people using the 'set page border color' >> option when they are using a dark background for their drawings. >> Where would that option go? Or did you mean to remove that completely? > > Well, I imagined this option not to be used often. Though I agree that > with dark backgrounds the contrast may be very low, so people would > like to adjust it. > > As I guess keeping a high contrast is the main reason for having that > option and people are currently required to adjust the border color > accordingly when they set a background color, I see two possible > solutions to improve this: > > 1. Only set the viewport background color and keep the area outside of > it unchanged. > 2. Adjust the border color automatically according to the chosen > background color, so that you always keep a high contrast (like it's > done for the grippies on object selection). > > Having said that, this is probably out of scope for the blueprint, so > I may just add the option back for now. > >> As guides colors are document-specific (as far as I understand), having >> them set in the preferences doesn't make a lot of sense to me. I imagine >> that the best guide color also depends upon the selected background >> color for the document, and as such should either also be in a separate >> 'Guide' dialog, or stay where it is. > > While the same solution as for the border color might be applied > (automatically keep a high contrast), I agree that moving them into a > separate dialog might be a good solution - also in regard of future > feature additions like allowing to adjust their position precisely > within that dialog or allowing to define different colors per guide. > I'll adjust the proposal accordingly. > >> The coupling of document units and page size units, mmh. I think it >> would simplify things for new users. For myself, I don't like it too >> much. > > What are the use cases to adjust them individually? > >> I like the Licences being put into the Metadata section and the 'Save as >> template' option a lot. The change to the colors tab also is really >> nice. And the cancel button is really useful (so the document will not >> be resized while you're still entering the values, and you can change >> your mind, too, without several actions happening in the background). > > Thank you! > >> What I always find difficult about these kinds of dialogs, though, is >> that I never know if I need to hit OK for each tab separately, or if it >> will apply for everything I changed in all tabs (different programs do >> this differently). Is there an UI way to make this really obvious? > > The programs I know on Windows and Linux always accept the whole > preferences when clicking the OK button. > Sometimes there is an additional 'Apply' button, which saves the > settings without closing the dialog. Eclipse has such a button within > its preferences dialog, for example. Though there it's clear that the > 'Apply' button only affects the current options page, as it is located > within the options area (while the OK button is outside that area, so > it's meant to save all preferences). > >> Will the dialog close automatically upon hitting OK? > > In accordance to the above, yes, it will close the dialog (as it is > located outside the tabs; normal behavior across programs). > > Sebastian > >> Am 28.05.2016 um 12:21 schrieb Brynn: >>> On the Page tab, what happened to the Display section, where you can >>> show or >>> hide the page border, or disable antialiasing? >>> >>> What is the benefit of moving Grids and Snap tabs to a separate dialog? >>> Same for Scripting tab? >>> >>> All best, brynn >>> >>> _______________________ >>> From: Sebastian Zartner >>> Sent: Thursday, May 26, 2016 4:39 PM >>> To: Inkscape >>> Subject: [Inkscape-devel] [UI] Rework Document Properties dialog >>> >>> >>> Hi all, >>> >>> >>> I took the time to draft a reworked Document Properties dialog. >>> >>> >>> I already created a blueprint for that two years ago: >>> https://blueprints.launchpad.net/inkscape/+spec/document-properties-rework >>> >>> >>> And now I finally also described my proposal in a bit more detail >>> including >>> some mockups within the wiki: >>> http://wiki.inkscape.org/wiki/index.php/BlueprintReworkedDocumentProperti... >>> >>> >>> Would be great if someone took the time to review it and give me some >>> feedback. >>> >>> >>> Thank you in advance, >>> >>> >>> >>> Sebastian >>> >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> What NetFlow Analyzer can do for you? Monitors network bandwidth and >>> traffic >>> patterns at an interface-level. Reveals which users, apps, and protocols >>> are >>> consuming the most bandwidth. Provides multi-vendor support for NetFlow, >>> J-Flow, sFlow and other flows. Make informed decisions using capacity >>> planning reports. >>> https://ad.doubleclick.net/ddm/clk/305295220;132659582;e >>> >>> >>> >>> _______________________________________________ >>> Inkscape-devel mailing list >>> Inkscape-devel(a)lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/inkscape-devel >>> >>> >>> ------------------------------------------------------------------------------ >>> What NetFlow Analyzer can do for you? Monitors network bandwidth and >>> traffic >>> patterns at an interface-level. Reveals which users, apps, and protocols >>> are >>> consuming the most bandwidth. Provides multi-vendor support for NetFlow, >>> J-Flow, sFlow and other flows. Make informed decisions using capacity >>> planning reports. >>> https://ad.doubleclick.net/ddm/clk/305295220;132659582;e >>> _______________________________________________ >>> Inkscape-devel mailing list >>> Inkscape-devel(a)lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/inkscape-devel >>> >> >> >> ------------------------------------------------------------------------------ >> What NetFlow Analyzer can do for you? Monitors network bandwidth and >> traffic >> patterns at an interface-level. Reveals which users, apps, and protocols >> are >> consuming the most bandwidth. Provides multi-vendor support for NetFlow, >> J-Flow, sFlow and other flows. Make informed decisions using capacity >> planning reports. >> https://ad.doubleclick.net/ddm/clk/305295220;132659582;e >> _______________________________________________ >> Inkscape-devel mailing list >> Inkscape-devel(a)lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/inkscape-devel

On 29 May 2016 at 13:11, Diederik van Lierop <mail@...1689...> wrote: Got the point. So, I'll add the Grids tab back. In 0.91 the snap sensitivity (meaning the 'Snap distance') is located within the Document Properties dialog. In the Preferences dialog I only see 'Enable snap indicator', 'Delay (in ms)', 'Only snap the node closest to the pointer', 'Weight factor' and 'Snap the mouse pointer when dragging a constrained know'. Did that change on trunk? I'm not convinced yet to keep the snap settings per-document. In my opinion, if there is currently a need to set the snapping distances, then snapping should be made smarter. Sebastian On 30 May 2016 at 08:25, Diederik van Lierop <mail@...1689...> wrote:

On 30 May 2016 at 04:32, Brynn <brynn@...3133...> wrote: Convinced, adding the tab back. I'd like to know the use case for this. As written in the response to Diederik, I believe that this feature is only used in cases where the snapping is not smart enough. Obviously your main point is to have the option for toggling the border display handy and it doesn't matter much whether it's a document preference or an Inkscape setting, right? So, what about moving those options into the 'View' menu (where they could also get shortcuts assigned)? Personally, I always leave it checked even though I mostly use Inkscape for web-based work where displaying the border like a page is rather undesireable. Though I guess most people don't care about that option. There's no automatic usage feedback in Inkscape to clarify such things, right? What are the use cases for this? Would it be enough to be able to toggle it globally via the 'View' menu as mentioned above or is it really something that should be part of the document? The guides themselves are of course per-document. I am just wondering whether the three related settings 'Show guides', 'Guide color' and 'Highlight color' need to be document properties. Sebastian

On 30 May 2016 at 12:48, Sebastian Zartner <sebastianzartner@...400...> wrote: On 30 May 2016 at 12:49, Sebastian Zartner <sebastianzartner@...400...> wrote: While writing this, I forgot about my own suggestion. What about moving guides and grids into a separate dialog? Doing so, those would still be document specific though could be adjusted separately from the general document properties. (Previously I suggested to move grids + snapping into a combined dialog, though snapping is not restricted to grids, so it should rather be kept separate.) Sebastian

On Mon, 2016-05-30 at 12:49 +0200, Sebastian Zartner wrote: Maybe a solution would be to move the options into the guide UI itself. (a change like this would necessitate user testing IMO) but... Right now the guide ui has a unlabeled colour widget button for colour, if we can sneak in "Use Default Colour", "Custom Colour", "Set all guides to this colour" somewhere in there, then you reduce load on the properties and focus the options into a place where users using that feature will find them. Best Regards, Martin Owens

On 30 May 2016 at 13:23, Sebastian Zartner <sebastianzartner@...400...> wrote: I've created two mockups of how this dialog could look like: http://wiki.inkscape.org/wiki/index.php/BlueprintReworkedDocumentProperti... Sebastian

Personally I find convenient having a single place where all specific document options are grouped because in this way they can be better spotted, understood and controlled. I agree that having them near where they are used could be convenient too and for this I'm not against having different access points to the same option. -- View this message in context: http://inkscape.13.x6.nabble.com/UI-Rework-Document-Properties-dialog-tp4... Sent from the Inkscape - Dev mailing list archive at Nabble.com.

Hi Sebastian, Am 30.05.2016 um 12:49 schrieb Sebastian Zartner: [guides] - A guide can be positioned over objects, or over the canvas background (and both at the same time). Which one should the guide's color depend upon? Or would the color differ upon the current local background, so the guide doesn't have a uniform color, but differring colors over its length? (would that look okay...? Might look 'wild' if you have lots of guides...) I'm still in favour of setting the base guide color document-wide, but don't care too much about where that setting can be made. Although one could argue that if it were possible to duplicate a guide, then the document-wide setting would be less needed (as you don't need to set the color for each guide separately when you duplicate one that already has the color you want). [document units] - Not really... ;) I just use what looks best in each case. [License] That will work, thanks! Maren

Hi Maren, On 31 May 2016 at 00:44, Maren Hachmann <maren@...3165...> wrote: Its color would differ like it's already done for the the object handles. That might be the case. This would need to be tried out first. Good point. Related bug reports: https://bugs.launchpad.net/inkscape/+bug/511788 https://bugs.launchpad.net/inkscape/+bug/535573 Sebastian

Replying to various comments from different messages, all in one place. I don't have a use case. But I trust the developers who designed it knew what they were doing. I'm glad Diederik has responded. Sure, that would be fine with me, except for 2 things: 1 - don't take it out of Doc Props without putting the new menu item in 2 - I've been told (in long ago old messages, and might have been in a forum) that key shortcuts come at a premium....meaning that there aren't many available anymore. I think that old message was in regard to snapping. Originally, when snapping first was available, you could hold a key (I think was Shift, but my memory might not be accurate) to globally disable snapping. I found was indispensible! But the next version of Inkscape, that shortcut was removed, because it had another function. (If you were dragging a node, it would drag out a handle instead of disabling snapping.) So that's how I have the impression that key shortcuts can't be handed out like candy. There's no automatice usage feedback in Inkscape....not that I've ever heard of. I'd have to seriously investigate such a feature, before using it willingly! Please don't turn Inkscape into another guugle app! -------------------------------------------------- From: "Sebastian Zartner" <sebastianzartner@...400...> Sent: Monday, May 30, 2016 5:04 AM To: "Diederik van Lierop" <mail@...1689...> Cc: "Maren Hachmann" <maren@...3165...>; "Brynn" <brynn@...3133...>; "Inkscape" <inkscape-devel(a)lists.sourceforge.net&gt; Subject: Re: [Inkscape-devel] [UI] Rework Document Properties dialog I would very much disagree about turning the snap toolbar into a dialog!! -------------------------------------------------- From: "Sebastian Zartner" <sebastianzartner@...400...> Sent: Monday, May 30, 2016 5:23 AM To: "Brynn" <brynn@...3133...> Cc: "Maren Hachmann" <maren@...3165...>; "Inkscape-Devel" <inkscape-devel(a)lists.sourceforge.net&gt; Subject: Re: [Inkscape-devel] [UI] Rework Document Properties dialog I don't see turning 1 dialog into 2 or 3 dialogs as an improvement. To be honest, I replied right away to this message because I don't see anything wrong with the Document Properties dialog. If someone asked me, I might point to the page border shadow as a problem, because I just don't see what use it is. But more than that, I don't see any problems. Personally, I use snapping, together with either grids or guides in literally every new document. So now I will have to open 2 or 3 dialogs at the beginning of each new document? It doesn't make sense to me. Granted, I'm just a simple user, and not a developer. But it seems to me like everything that someone needs to set up a document, should be all in one dialog. All best, brynn -------------------------------------------------- From: "Sebastian Zartner" <sebastianzartner@...400...> Sent: Monday, May 30, 2016 4:49 AM To: "Brynn" <brynn@...3133...> Cc: "Maren Hachmann" <maren@...3165...>; "Inkscape-Devel" <inkscape-devel(a)lists.sourceforge.net&gt; Subject: Re: [Inkscape-devel] [UI] Rework Document Properties dialog > On 30 May 2016 at 04:32, Brynn <brynn@...3133...> wrote: >>>> On the Page tab, what happened to the Display section, where you can >>>> show >>>> or >>>> hide the page border, or disable antialiasing? >>> >>> >>> The display options would be moved to the general 'Preferences' >>> dialog, i.e. be made global. I assume there is not much need to set >>> them per document. Regarding the page border field, see below. >>> >>>> What is the benefit of moving Grids and Snap tabs to a separate dialog? >>>> Same >>>> for Scripting tab? >>> >>> >>> Grids and snap options are not document properties in my eyes but >>> helper functionality. Also, snapping is rather a global functionality >>> than specific to a document. >> >> >> Respectfully, I disagree. >> >> Grids tab: >> Sometimes I might have 2 or 3 grids in 1 file (although only 1 at a time >> is >> visible). But other times, no grids at all. So this is very much a "per >> document" feature for me. > > Convinced, adding the tab back. > >> Snap tab: >> I don't usually change those snap settings. So such a change probably >> would >> not affect me. But I can imagine some people probably change them per >> document. > > I'd like to know the use case for this. As written in the response to > Diederik, I believe that this feature is only used in cases where the > snapping is not smart enough. > > >> Although I suppose one could use Guides instead. From that point of >> view, >> the border could be eliminated. But I think it's just too convenient of >> a >> feature, to get rid of. >> >> For me, the border shadow could be eliminated. I never use it. But I >> have >> no idea about how other people use it. >> I also think antialiasing is a "per document" feature. From time to >> time, >> in forums, we suggest changing that for a particular image or file. > > What are the use cases for this? Would it be enough to be able to > toggle it globally via the 'View' menu as mentioned above or is it > really something that should be part of the document? > >> Guides tab: >> I didn't originally comment on Guides, but I see them as very much a "per >> document" feature. > > The guides themselves are of course per-document. I am just wondering > whether the three related settings 'Show guides', 'Guide color' and > 'Highlight color' need to be document properties. > > Sebastian

Sebastian Zartner wrote I find that speaking about guides in this terms is pretty reductive. I use guides to make geometric constructions, to copy angles, to calculate tangent points, to offset distances, to draw circles with a given diameter or rectangles with given dimensions and much, much more. To me guides are mostly (temporary) objects related helpers and I very often open the guide dialog, even more than once for each guide to set it in the right position and to work with it: this dialog shall be lightweight, fast and small, focused on the single guide's options; I usually cycle between fields with tab so they should be few and well ordered and grouped; everything more than this is only going to distract me from what I'm doing or going to cause time waste while waiting for it to appear and populate. Further, I can't see any need for relationships with global options in here (which I would change at most only once per document). In few words: the current single guide dialog is good (I'd only reduce its size rearranging what's already in it and reducing the tab for the color which I find unnecessarily big now). Sebastian Zartner wrote Locked/unlocked is different than editable/non editable. There's no point in locking a non editable object. The lock feature is useful exactly because guides are editable. Grids are not editable. This makes a huge difference to me. Sebastian Zartner wrote I agree with Alvin and su_v replies. Also, I don't like those programs that try to guess what I need, because they usually fail. If I need the document's options dialog I'm fine with having to call for it; if I don't need the dialog I'd be annoyed to have to close it, even if the former was more frequent than the latter. (Anyway, this point would make sense only if the document's options button is removed from the toolbar: now the dialog requires only one click.) Luca -- View this message in context: http://inkscape.13.x6.nabble.com/UI-Rework-Document-Properties-dialog-tp4... Sent from the Inkscape - Dev mailing list archive at Nabble.com.

On 1 June 2016 at 12:40, LucaDC <dicappello@...2144...> wrote: Sure, guides serve more use cases than the one mentioned by me. Regarding the options to edit a single guide my mockup currently has the same amount of options (two more for visibility and showing dots instead of lines and two less by removing the option for relative changes and the unit; editing the label moved into the list). I have a very poorly equipped laptop at home, though I still never have to wait long for the dialogs to appear. Got your point. This is not completely correct. Grids *are* editable (from within the Document Properties dialog), just not directly on the canvas. I interpret this as 'always-locked'. My mockup would allow to unlock them, so they could be edited (moved) within the canvas. They would still initially be locked, though, so the default behavior would stay the same. Alvin and su_v pointed out that 0.91 features a dialog, which allows to create a new document based on a template. My suggestion there was to combine its features with the ability to adjust the preferences before creating the document and to allow to save your own templates. And I don't like that I have to adjust the preferences after I've created the document. I believe programs should try to provide you with some properly chosen defaults but always allow you to adjust them to your needs. For your use case I could imagine a checkbox allowing you to skip the dialog and always create a document based on the default template - i.e. restore the current behavior. This would serve both use cases. Any further discussion specifically related to the 'New Document' dialog should take place in the bug report. Sebastian

Just a couple of other points I noticed in the blueprint. I use a lighter page border color to easily distinguish it from the lines I draw. I definitely need an option to set it somewhere and it could be a program option for me (i.e. the same for all created or loaded documents) but I suppose that someone else may prefer having it per document. I also find the page border shadow useful to easily spot the page rectangle when zooming out. Consider that I use Inkscape mostly for technical drawings so I have a lot of horizontal and vertical lines and 0° rectangles. IMHO the option to show or hide the page shadow, if any, should be near the one for the page border color. About the snapping options, they are clearly related to the use you make of grids and guides in each document: in some documents the grid could be just a reference (so snapping to grid should be secondary related to snapping to guides), in others the grid alignment could be a strict requirement so snapping to it should take precedence over anything else. This can be achieved adjusting the snapping distances. I think they are definitely document's settings. A different story are the two 'Miscellaneous' tangential and perpendicular checkboxes: they are there only because Diederik did not find a better place at the time he introduced them and nobody came back on them since then. IMHO those two may deserve a less hidden place in the main interface but I haven't spoke about this because there are other problems to solve before. Up to now I still open the document's options dialog every time to toggle them when I need and it's not the best experience (but they are so useful that I tolerate). If you try them you'll realize that they are neither global options nor document's options: they are toggles that need to be untoggled after being used. Luca -- View this message in context: http://inkscape.13.x6.nabble.com/UI-Rework-Document-Properties-dialog-tp4... Sent from the Inkscape - Dev mailing list archive at Nabble.com.

On 1 June 2016 at 17:46, LucaDC <dicappello@...2144...> wrote: I missed to explain why. You can do relative changes by entering calculations into the fields just like in all the other value fields. Because I believe it is better to keep to the general document's units. Or is there a reason to have the document in centimeters but use inches for the guides? After all, the blueprint is just a proposal and the goal is to improve the UI. And I started the discussion here to get a consensus on it. If there are reasonable objections against parts of it, I'll change them. I also use guides very often and I intent to improve features and workflows. On 1 June 2016 at 18:43, LucaDC <dicappello@...2144...> wrote: Fixed. I didn't mean to change it. The current default is rgb(102, 102, 102). My intention was to move all those options to the View menu, which was accepted by Martin and Brynn. The feature itself is clear to me. Though I still wonder whether that is actually something people use. Sounds good to me to move them to the main interface. On 1 June 2016 at 19:22, Maren Hachmann <maren@...3165...> wrote: It's not that the dialog is too crowded, it's just that some options may not be needed or belong to somewhere else. Sebastian

Sebastian Zartner wrote I guessed you had thought this. But it's not the same: when you open the dialog the coordinates field have to be populated by decimal numbers, that is the internal representation of the exact coordinates (exact in the sense that they're exactly what the program is using) are converted into a certain amount of characters. If you then write "+5" a second conversion of the original coordinates is needed because the arithmetic operation will then be performed with the character representation converted back to binary. I always use the guide's dialog in relative mode, that's why at the time I asked to make this field persistent at least inside the single Inkscape session (at first I had to enable it every time the dialog was open) and it had been a big improvement in my workflow. Now I open the dialog and the cursor is already in the field I need (e.g. in a horizontal guide's dialog the Y field is selected) so I just have to type the offset and press enter. I agree that it's not a big difference but given how often I do this small operation your proposal is going to negatively impact my workflow. And I still can't see any good reason to do so. Sebastian Zartner wrote You never know what user's may need. A feature is a feature and if you take it out nobody will be able to use it anymore. And where is the improvement? Personally I've used this option to have offset in inches in a mm document because the parts I was drawing had their measurements specified in inches but the rest of the drawing was in mm (and don't tell me that I could have just typed '*25.4' because the units were introduced exactly to get rid of this so it would be a step back). I've also used the angle unit combo for moving between ° and rad. I don't see any reason to have the freedom of choosing the angle unit and not the coordinates' one. Sebastian Zartner wrote I'm sure about this. In my last post I've slipped in using a more passionate tone to express my surprise (which was due to my fault as I had not read well your blueprint before) because guides is the main tool I use in Inkscape and even a small change is going to affect, positively or negatively, my workflow. I'm just trying to give you as much input I can as a heavy user of guides. Every node in my drawing is placed snapping it to a guide or to two guide's intersection. This is the only way I've found to have (almost) exact measures and dimensions in Inkscape. And it's very easy too. Sebastian Zartner wrote And that's fine for me too, as long as the options are still reachable somewhere. Sebastian Zartner wrote Same as before: if you take this feature away, nobody will use it for sure. Sebastian Zartner wrote About the "may not be needed" I've already written twice above. About the "belong to somewhere else" it's a very subjective sentence: I'd read it as "I feel that they may belong to somewhere else", hence not an strong argument. Let me propose a different point of view: have you heard people complaining specifically about the points we're talking about in the current document's options dialog? Remember that people who are happy with the current state of things usually don't care about writing, they'll just complain when realizing that you've changed what they were using. My global opinion is that there are many points in your blueprint that would effectively improve the dialog (all those I didn't write about because I think are valid) but some others, which I think are minor and not strictly required to reach the main goal, could break usages. I'd take a more conservative approach, introducing the core changes while leaving alone the others, at least until you get some real feedback from a larger pool. The main ones I wouldn't touch are the tabs in the dialog and the single guide's dialog as I don't see a strong relationship with the improvements in managing the document's options you're proposing (that is, leaving them alone shouldn't hinder you). And if you think that the presence of some features is an obstacle for what you want to implement, please share your concerns so we can look for alternative solutions that may save both ways. Luca -- View this message in context: http://inkscape.13.x6.nabble.com/UI-Rework-Document-Properties-dialog-tp4... Sent from the Inkscape - Dev mailing list archive at Nabble.com.

Sebastian Zartner wrote I'm not into Inkscape's code but AFAIU things are not so simple as you say. When you hit enter into the textual field, how can the exact original coordinate be extracted from the mathematical string that you are feeding to the parser? Also, when I hit enter I assume that I'm inputting what I see, not what the program thinks while showing me something different. I don't agree that this should be discussed in a different thread because the problem wouldn't even exist without what's in this thread. Luca -- View this message in context: http://inkscape.13.x6.nabble.com/UI-Rework-Document-Properties-dialog-tp4... Sent from the Inkscape - Dev mailing list archive at Nabble.com.

Sebastian Zartner wrote So if you directly write a number that falls inside the amount you take as "rounded version of the exact original value" the program is going to cut it to the original value. I don't like this approach. Sebastian Zartner wrote If I decide to press enter on a value, I accept (and expect) the number I see. That's why I think that the relative mode is needed, so you don't have to care about the original number, if it's rounded or not, if it's nice or not and so on. Sebastian Zartner wrote Please, don't mix things. The problem already exists and is broader than what we're discussing here. So I agree with what you've written. But that's not the point. The point is that today we have the relative mode on the guide's dialog that permits to avoid this issue and lets me move guides with the precision I need. Your proposal is to remove a well working feature and substitute it with another one that you know is not well working. So I'd say: fix the mathematical parser before and then I'll think about accepting your proposal to remove the relative mode (after having well checked that your fix is effective, of course ;) ). That's why I say that the parser issue is linked to this thread. Or to say it differently: you're linking it. Luca -- View this message in context: http://inkscape.13.x6.nabble.com/UI-Rework-Document-Properties-dialog-tp4... Sent from the Inkscape - Dev mailing list archive at Nabble.com.