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

On 30 May 2016 at 08:25, Diederik van Lierop <mail@...1689...> wrote: I have to admit that I've totally missed that toolbar until now. So, those options should indeed be moved there. I agree that this makes the toolbar pretty crowded, though that may be handled by introducing toolbar button menus or by turning this toolbar into a dialog. Sebastian

On 30 May 2016 at 16:30, LucaDC <dicappello@...2144...> wrote: I was thinking about that, too. The easiest solution would be to sort them alphabetically by their ID (which probably isn't changed by hand, normally), so guides and grids would be grouped that way. But of course there are advanced ways to do that. I'd like to know what you mean by 'their own space'. Add a group header to the list? Two lists? completely separate editing UIs? On 30 May 2016 at 16:59, LucaDC <dicappello@...2144...> wrote: For me it is a bit strange to find scripting, snapping, etc. in the same dialog as document meta data or the page format, which was one motivation for creating the blueprint. The main goal of the blueprint is to improve the UX by tightening the dialog up and moving the options to the places where they are rather expected, i.e. improve their discoverability. On 30 May 2016 at 17:08, LucaDC <dicappello@...2144...> wrote: Not a good argument but the main toolbar besides the snap toolbar would still be longer. But I agree with you that the snapping toolbar is already very crowded and that the toolbars should only contain the commonly used options (or hide the less frequently used ones by default). Unfortunately we don't have usage data, so we have to guess what options are used/changed frequently and which are not. Regarding the Document Properties dialog I still suspect that the features there are very seldomly changed and are rather meant to be modified globally. So, against my previous statement, I think it would be better to move them to the other snapping settings in the global Preferences dialog or just remove them if they are not used at all. As I said before, I'd expect the snapping mechanisms to be smart enough (what they IMO mostly already are) that those options are not needed. Sebastian

On 31 May 2016 at 14:41, LucaDC <dicappello@...2144...> wrote: I see. In my mockups they have different editing UIs but only one is shown at a time (depending on the selected item). Double-clicking a guide line would select it in the dialog, so there is no need to search for it. The connection to the canvas could be improved further by highlighting the selected line within the canvas. Though that's out of scope of the blueprint. Grids and guides have different usage contexts, that's right, but both are document related helpers that serve to align objects. The editable vs. locked feature is just a state and as Maren wrote earlier, guides can also be locked in the next version. So, IMO there is no real local vs. global relation. You may be interested in https://bugs.launchpad.net/inkscape/+bug/1362061 then. Having several entry points to different parts of the same dialog is another possible solution, yes. The main point I'd move them into a separate dialog is that I see grids and guides as a special kind of objects rather than document properties. What features you usually use and what options you usually change depend on your workflow, preferences, knowledge, etc.. So, you have to base the decision on what to place in the toolbars (by default) on assumptions or additionally on collected usage data. Though there are some actions and options where doing the right guess is easier than for others. E. g. regarding the two document's and program's options buttons I agree that they could be removed. Your input is very valuable, non-the-less. So, thank you! Sebastian

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

I'm kind of in agreement with Luca. I had a similar reaction when you said you had never noticed the snap control bar. (I use it absolutely constantly!) (And I change the options, sometimes between each step I take on the canvas. That's why putting it in a dialog wouldn't work.) By removing the option for relative changes in the individual guides dialog, it makes that option invisible, especially for the non-technical Inkscape users out there. You'd have to know that ability was there, to do the calculations in the field, to be able to use it. Or at least wonder about it, and try it. To me, it's more intuitive the way it is. But if you remove the relative option, maybe you could replace it with a reminder note, that the fields can be used for calculating relative moves. Or at least a mouseover text (like the options in Inkscape Preferences). Just a thought. Removing the guide units borders on outrageous for me. It's one thing to make a dialog smaller or more efficient, or whatever you're doing. But it's a whole other thing to remove or hide functionality. Having many units available is part of what makes Inkscape great. It seems you're branching out from just reworking the Document Properties dialog? All best, brynn -------------------------------------------------- From: "LucaDC" <dicappello@...2144...> Sent: Wednesday, June 01, 2016 9:46 AM To: <inkscape-devel(a)lists.sourceforge.net&gt; Subject: Re: [Inkscape-devel] [UI] Rework Document Properties dialog

On Mon, 2016-05-30 at 12:48 +0200, Sebastian Zartner wrote: Whether an option is document or inkscape specific shouldn't be the focus. It'd be nice if these things were identifiable, but to be honest It's better when options are logically placed in terms of their use rather than how they are sustained. If there's a spot on the snapping toolbar/dialog/next_ui_here for document snapping options. That would be useful, making it clear these options get saved for the document can be mulled over when doing that ui part. Best Regards, Martin Owens

On 29 May 2016 at 16:42, Maren Hachmann <maren@...3165...> wrote: Ah, cool! I didn't know about that feature. (There's no hint that you can double-click them.) Still, is there a need for a document-wide color definition for them in case they would automatically keep a high contrast by default? I'd say not only for new users. I understand the difference between the two, though it can be quite confusing for users to have two units fields (especially when they are located on the same tab). So, that's obviously workflow dependent. Regarding your usage of pixels as units I assume you use integer values for them. In that case, 0.001 would be more fine-grained than a pixel. (Btw. my workflow is normally web-based, so I use pixels for both in most cases.) I'd like to get some feedback from other people on this before I add the second field back, as I am not convinced yet that the advantages of having two fields for them overweight the disadvantages. I also realized that after sending my previous mail related to that. Though the answer to this is pretty simple. The field would be a combobox, i.e. you could select from existing licenses but also type in your own URL. Sebastian

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

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 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

Personally I find a very bad idea having a list where both my one or (usually at most) two grids are listed together with tens of guides because it would be really hard to find them if that's what I'm looking for. Just give grids and guides each their own space because if they have the same main purpose (snapping) they still are different tools with different characteristics. -- 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.

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

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.

I'm thinking that maybe an 'Advanced' settings part that can either be shown or not shown by clicking on a small arrow in the dialogs (maybe additionally based on a preference: 'Hide advanced options by default') could provide a solution for quite a few issues here, and make the dialogs easy for new users, while the others can just activate to always show those settings, and stay equally happy... ;) Maren Am 01.06.2016 um 18:43 schrieb LucaDC:

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.