[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/BlueprintReworkedDocumentPropertiesD...
Would be great if someone took the time to review it and give me some feedback.
Thank you in advance,
Sebastian
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/BlueprintReworkedDocumentPropertiesD...
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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
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 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/BlueprintReworkedDocumentPropertiesD...
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@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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Hi Brynn, hi Maren,
thank you for the feedback!
On 28 May 2016 at 12:21, 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.
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/BlueprintReworkedDocumentPropertiesD...
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@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@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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Sun, May 29, 2016 at 11:46 AM, Sebastian Zartner < sebastianzartner@...400...> wrote:
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.
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 Sun, May 29, 2016 at 1:11 PM, Diederik van Lierop <mail@...1689...> wrote:
On Sun, May 29, 2016 at 11:46 AM, Sebastian Zartner < sebastianzartner@...400...> wrote:
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.
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.
Responding to my own e-mail: It could be argued indeed that some of the
snap-settings in the document properties should be part of the preferences instead. But that's not the case for all of them, and it's tricky to change. For example "snap to clip paths", and "snap to mask paths", shouldn't be changed into preferences. They are very similar to the buttons on the snap toolbar, which must stay document properties. So "snap to clip paths", and "snap to mask paths" would have to move to the snap toolbar then. But people have already been complaining that the snap toolbar is too long and crowded, and these two buttons do not really need a prominent location. But they have to go somewhere...
It's still very important however that the grid settings stay part of the document properties.
Diederik
On 30 May 2016 at 08:25, Diederik van Lierop <mail@...1689...> wrote:
On Sun, May 29, 2016 at 1:11 PM, Diederik van Lierop <mail@...1689...> wrote:
On Sun, May 29, 2016 at 11:46 AM, Sebastian Zartner <sebastianzartner@...1761....400...> wrote:
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.
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.
Responding to my own e-mail: It could be argued indeed that some of the snap-settings in the document properties should be part of the preferences instead. But that's not the case for all of them, and it's tricky to change. For example "snap to clip paths", and "snap to mask paths", shouldn't be changed into preferences. They are very similar to the buttons on the snap toolbar, which must stay document properties. So "snap to clip paths", and "snap to mask paths" would have to move to the snap toolbar then. But people have already been complaining that the snap toolbar is too long and crowded, and these two buttons do not really need a prominent location. But they have to go somewhere...
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
My opinion is that toolbars are good for frequent actions, where you really need to have a rapid access. Personally I don't spend so much time playing with snapping's internal options so I don't like the idea of having them take some of the already little space still available in the GUI.
-- View this message in context: http://inkscape.13.x6.nabble.com/UI-Rework-Document-Properties-dialog-tp4976... Sent from the Inkscape - Dev mailing list archive at Nabble.com.
On 30 May 2016 at 16:30, LucaDC <dicappello@...2144...> wrote:
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.
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:
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.
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.
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.
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:
My opinion is that toolbars are good for frequent actions, where you really need to have a rapid access. Personally I don't spend so much time playing with snapping's internal options so I don't like the idea of having them take some of the already little space still available in the GUI.
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
Sebastian Zartner wrote
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?
I was thinking about separate editing UIs, where, if you really want, you may have two separate lists. I'm not a big fan of a guides' list because I don't see a quick way to connect what I see in the list to what I have in the canvas and if I need to address a guide in the canvas the quicker way to work with that object is dobule-clicking on it, not opening a document wide dialog and looking for it in a huge list.
In general I expect a global UI to act on global options and not on single objecs, and single objects' UI not to affect global options (because it could be confusing as you may miss the boundary between local and global). Grids are global objects so a single central menù has sense. Guides are usually non global objects because each one has its own motivation and is contextualized. I feel this concept is enforced by the fact that guides are editable by the mouse while grids are not (and IMHO this is the correct behavior).
Sebastian Zartner 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.
I'm not disturbed by finding different configurations packed in the same interface provided they are well organized. The current tabbed UI where each "argument" has its own space is fine to me. I agree that users may look for the same piece of interface starting from other places so in this case it's a good idea to split the accesses into each single function addressed by the configuration UI. It all boils down to what you need to do: if you just need to change all guides' color because you have a blue background, you'll probably start from all in the UI that deals with guides. I usually prefer opening the document's options dialog just after creating a new document, sweeping all relevant configurations to set them to what I need and then start working in a globally already set environment. Would it be too hard to let users access the same configuration dialog both by its own from the tool and tabbed in the general document's options one?
Sebastian Zartner wrote
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.
As I tend to look for a global options dialog, for me splitting the configurations into many small independent dialogs would negatively impact discoverability. But, of course, we are all different so this could be the opposite for others. I still think that to really improve discoverability, different access points for the same dialog should be provided; just like how the same function can be triggered by a shortcut or by a toolbar menu entry or by a left-click contextual menu and so on.
Sebastian Zartner wrote
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.
I won't base the decision on "most frequently used" or on usage data, but rather on which options usually need to be changed _while_ working on a document hence deserve a quick click access in the toolbars. I suppose that changing the page size is not an operation you commonly do back and forth while drawing so a toolbar button to set the page size would just be a space waste. OTOH, the same can be said about the two document's and program's options buttons which I don't feel a big urge to have there as their accesses in the File and Edit menus are enough (and removing them would be a start in fixing the missing icons bug in the front UI ;).
Please, take all I've written knowing that I'm not an UI expert (I'm only a U :).
Luca
-- View this message in context: http://inkscape.13.x6.nabble.com/UI-Rework-Document-Properties-dialog-tp4976... Sent from the Inkscape - Dev mailing list archive at Nabble.com.
On 31 May 2016 at 14:41, LucaDC <dicappello@...2144...> wrote:
Sebastian Zartner wrote
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?
I was thinking about separate editing UIs, where, if you really want, you may have two separate lists.
I see. In my mockups they have different editing UIs but only one is shown at a time (depending on the selected item).
I'm not a big fan of a guides' list because I don't see a quick way to connect what I see in the list to what I have in the canvas and if I need to address a guide in the canvas the quicker way to work with that object is dobule-clicking on it, not opening a document wide dialog and looking for it in a huge list.
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.
In general I expect a global UI to act on global options and not on single objecs, and single objects' UI not to affect global options (because it could be confusing as you may miss the boundary between local and global). Grids are global objects so a single central menù has sense. Guides are usually non global objects because each one has its own motivation and is contextualized. I feel this concept is enforced by the fact that guides are editable by the mouse while grids are not (and IMHO this is the correct behavior).
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.
Sebastian Zartner 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.
I'm not disturbed by finding different configurations packed in the same interface provided they are well organized. The current tabbed UI where each "argument" has its own space is fine to me. I agree that users may look for the same piece of interface starting from other places so in this case it's a good idea to split the accesses into each single function addressed by the configuration UI. It all boils down to what you need to do: if you just need to change all guides' color because you have a blue background, you'll probably start from all in the UI that deals with guides. I usually prefer opening the document's options dialog just after creating a new document, sweeping all relevant configurations to set them to what I need and then start working in a globally already set environment.
You may be interested in https://bugs.launchpad.net/inkscape/+bug/1362061 then.
Would it be too hard to let users access the same configuration dialog both by its own from the tool and tabbed in the general document's options one?
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.
Sebastian Zartner wrote
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.
I won't base the decision on "most frequently used" or on usage data, but rather on which options usually need to be changed _while_ working on a document hence deserve a quick click access in the toolbars. I suppose that changing the page size is not an operation you commonly do back and forth while drawing so a toolbar button to set the page size would just be a space waste. OTOH, the same can be said about the two document's and program's options buttons which I don't feel a big urge to have there as their accesses in the File and Edit menus are enough (and removing them would be a start in fixing the missing icons bug in the front UI ;).
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.
Please, take all I've written knowing that I'm not an UI expert (I'm only a U :).
Your input is very valuable, non-the-less. So, thank you!
Sebastian
Sebastian Zartner wrote
Grids and guides have different usage contexts, that's right, but both are document related helpers that serve to align objects.
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
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.
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
You may be interested in https://bugs.launchpad.net/inkscape/+bug/1362061 then.
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-tp4976... Sent from the Inkscape - Dev mailing list archive at Nabble.com.
On 1 June 2016 at 12:40, LucaDC <dicappello@...2144...> wrote:
Sebastian Zartner wrote
Grids and guides have different usage contexts, that's right, but both are document related helpers that serve to align objects.
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.
Sure, guides serve more use cases than the one mentioned by me.
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;
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).
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.
I have a very poorly equipped laptop at home, though I still never have to wait long for the dialogs to appear.
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).
Got your point.
Sebastian Zartner wrote
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.
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 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.
Sebastian Zartner wrote
You may be interested in https://bugs.launchpad.net/inkscape/+bug/1362061 then.
I agree with Alvin and su_v replies.
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.
Also, I don't like those programs that try to guess what I need, because they usually fail.
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.
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.
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
Sebastian Zartner wrote
...by removing the option for relative changes...
WHAT?!? I didn't notice this, good you pointed out. Erm, well, I'll be explicit: don't even dare thinking to do something like this! This makes me think that you don't have a clear idea about some important use cases for guides. Really.
Sebastian Zartner wrote
...and the unit;
Why? Don't you think that they are there for a reason? Now I fear that there are other decisions you took without making them explicit but I don't have time to x-ray your blueprint, sorry. I'll see how it goes on hoping that someone else will join the analysis to help. Be sure you're going to hear me if you break something. :)
Please, before introducing the changes you're thinking about, let me invite you to go a bit more into the argument because I fear you don't have a picture clear enough to avoid missing some important points like the ones above. My opinion is that you're going to touch more points than intended for the main goal of your blueprint. Let me advise you to be careful.
Guides are a very very important tool for my workflow (and I suppose not only for mine) and if you break them... ;)
Luca
-- View this message in context: http://inkscape.13.x6.nabble.com/UI-Rework-Document-Properties-dialog-tp4976... Sent from the Inkscape - Dev mailing list archive at Nabble.com.
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@lists.sourceforge.net Subject: Re: [Inkscape-devel] [UI] Rework Document Properties dialog
Sebastian Zartner wrote
...by removing the option for relative changes...
WHAT?!? I didn't notice this, good you pointed out. Erm, well, I'll be explicit: don't even dare thinking to do something like this! This makes me think that you don't have a clear idea about some important use cases for guides. Really.
Sebastian Zartner wrote
...and the unit;
Why? Don't you think that they are there for a reason? Now I fear that there are other decisions you took without making them explicit but I don't have time to x-ray your blueprint, sorry. I'll see how it goes on hoping that someone else will join the analysis to help. Be sure you're going to hear me if you break something. :)
Please, before introducing the changes you're thinking about, let me invite you to go a bit more into the argument because I fear you don't have a picture clear enough to avoid missing some important points like the ones above. My opinion is that you're going to touch more points than intended for the main goal of your blueprint. Let me advise you to be careful.
Guides are a very very important tool for my workflow (and I suppose not only for mine) and if you break them... ;)
Luca
-- View this message in context: http://inkscape.13.x6.nabble.com/UI-Rework-Document-Properties-dialog-tp4976... Sent from the Inkscape - Dev mailing list archive at Nabble.com.
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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On 29 May 2016 at 13:11, Diederik van Lierop <mail@...1689...> wrote:
On Sun, May 29, 2016 at 11:46 AM, Sebastian Zartner <sebastianzartner@...400...> wrote:
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.
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.
Got the point. So, I'll add the Grids tab back.
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.
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 Sun, May 29, 2016 at 1:11 PM, Diederik van Lierop <mail@...1689...> wrote:
On Sun, May 29, 2016 at 11:46 AM, Sebastian Zartner <sebastianzartner@...400...> wrote:
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.
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.
Responding to my own e-mail: It could be argued indeed that some of the snap-settings in the document properties should be part of the preferences instead. But that's not the case for all of them, and it's tricky to change. For example "snap to clip paths", and "snap to mask paths", shouldn't be changed into preferences. They are very similar to the buttons on the snap toolbar, which must stay document properties. So "snap to clip paths", and "snap to mask paths" would have to move to the snap toolbar then. But people have already been complaining that the snap toolbar is too long and crowded, and these two buttons do not really need a prominent location. But they have to go somewhere...
It's still very important however that the grid settings stay part of the document properties.
Diederik
On Mon, 2016-05-30 at 12:48 +0200, Sebastian Zartner wrote:
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.
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
Thanks, Sebastian, for your answers!
Am 29.05.2016 um 11:46 schrieb Sebastian Zartner:
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.
- For me, the page border is a per-document setting, too... I may work with things I want to print in one project, and with things that never leave the svg file in another.
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.
- While I wouldn't mind the dialog being moved to a different place (if that makes things easier, and not less accessible), I would mind if the grid settings there would become global settings instead of per-document settings. Examples were given by Diederik.
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.
- We can already define guide colors per guide in 0.91, just like guides can be labelled. The individual color is not saved, currently, but that's a bug (of which I can't tell if it has been fixed in trunk yet or not).
Those guides come with some comfort functions :) - and having them lockable in the next version will make them much more useful to me.
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?
- In 0.91, I often use px as document units (to prevent a few bugs and to have more fine-grained control, they are the smallest available unit - just think of stroke widths, there's a limit to the number of decimal places after the comma in the entry field).
I'd still like to set the page size for my document in a unit that I can measure with a real-world ruler, and cut out with a real-world pair of scissors ;-) . Of course, it would still be possible to switch the unit twice to get the same result. The automagically adapting number fields do confuse new users, I think.
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!
- I just realized that there's no free-form licence entry field anymore. As Inkscape sometimes is a bit late in updating the list of available licences (I recently read that OSI has created an API for retrieving info about free licences...), and as it can never list all possible ones, how will people enter a different licence in your blueprint?
Kind Regards, Maren
On 29 May 2016 at 16:42, Maren Hachmann <maren@...3165...> wrote:
Thanks, Sebastian, for your answers!
Am 29.05.2016 um 11:46 schrieb Sebastian Zartner:
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.
- For me, the page border is a per-document setting, too... I may work
with things I want to print in one project, and with things that never leave the svg file in another.
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.
- While I wouldn't mind the dialog being moved to a different place (if
that makes things easier, and not less accessible), I would mind if the grid settings there would become global settings instead of per-document settings. Examples were given by Diederik.
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.
- We can already define guide colors per guide in 0.91, just like guides
can be labelled. The individual color is not saved, currently, but that's a bug (of which I can't tell if it has been fixed in trunk yet or not).
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?
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'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).
What are the use cases to adjust them individually?
- In 0.91, I often use px as document units (to prevent a few bugs and
to have more fine-grained control, they are the smallest available unit
- just think of stroke widths, there's a limit to the number of decimal
places after the comma in the entry field).
I'd still like to set the page size for my document in a unit that I can measure with a real-world ruler, and cut out with a real-world pair of scissors ;-) . Of course, it would still be possible to switch the unit twice to get the same result. The automagically adapting number fields do confuse new users, I think.
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 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!
- I just realized that there's no free-form licence entry field anymore.
As Inkscape sometimes is a bit late in updating the list of available licences (I recently read that OSI has created an API for retrieving info about free licences...), and as it can never list all possible ones, how will people enter a different licence in your blueprint?
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
On Mon, 2016-05-30 at 12:49 +0200, Sebastian Zartner 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?
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
Hi Sebastian,
Am 30.05.2016 um 12:49 schrieb Sebastian Zartner:
[guides]
Still, is there a need for a document-wide color definition for them in case they would automatically keep a high contrast by default?
- 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]
So, that's obviously workflow dependent. Regarding your usage of pixels as units I assume you use integer values for them.
- Not really... ;) I just use what looks best in each case.
[License]
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.
That will work, thanks!
Maren
Hi Maren,
On 31 May 2016 at 00:44, Maren Hachmann <maren@...3165...> wrote:
Hi Sebastian,
Am 30.05.2016 um 12:49 schrieb Sebastian Zartner:
[guides]
Still, is there a need for a document-wide color definition for them in case they would automatically keep a high contrast by default?
- 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?
Its color would differ like it's already done for the the object handles.
(would that look okay...? Might look 'wild' if you have lots of guides...)
That might be the case. This would need to be tried out first.
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).
Good point. Related bug reports: https://bugs.launchpad.net/inkscape/+bug/511788 https://bugs.launchpad.net/inkscape/+bug/535573
Sebastian
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.
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@lists.sourceforge.net 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 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.
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:
- 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/BlueprintReworkedDocumentPropertiesD...
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@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@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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
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.
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.)
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)?
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.
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?
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
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@lists.sourceforge.net 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 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.
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:
- 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/BlueprintReworkedDocumentPropertiesD...
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@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@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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On 30 May 2016 at 12:48, Sebastian Zartner <sebastianzartner@...400...> wrote:
On 29 May 2016 at 13:11, Diederik van Lierop <mail@...1689...> wrote:
On Sun, May 29, 2016 at 11:46 AM, Sebastian Zartner <sebastianzartner@...400...> wrote:
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.
I don't agree with this. [...]
Got the point. So, I'll add the Grids tab back.
On 30 May 2016 at 12:49, Sebastian Zartner <sebastianzartner@...400...> wrote:
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.
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
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@lists.sourceforge.net 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 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.
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:
- 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/BlueprintReworkedDocumentPropertiesD...
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@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@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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On 30 May 2016 at 13:23, Sebastian Zartner <sebastianzartner@...400...> wrote:
On 30 May 2016 at 12:48, Sebastian Zartner <sebastianzartner@...400...> wrote:
On 29 May 2016 at 13:11, Diederik van Lierop <mail@...1689...> wrote:
On Sun, May 29, 2016 at 11:46 AM, Sebastian Zartner <sebastianzartner@...400...> wrote:
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.
I don't agree with this. [...]
Got the point. So, I'll add the Grids tab back.
On 30 May 2016 at 12:49, Sebastian Zartner <sebastianzartner@...400...> wrote:
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.
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.)
I've created two mockups of how this dialog could look like: http://wiki.inkscape.org/wiki/index.php/BlueprintReworkedDocumentPropertiesD...
Sebastian
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@lists.sourceforge.net 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 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.
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:
- 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/BlueprintReworkedDocumentPropertiesD...
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@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@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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
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-tp4976... Sent from the Inkscape - Dev mailing list archive at Nabble.com.
On Mon, 2016-05-30 at 12:49 +0200, Sebastian Zartner wrote:
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 couple of options about border and shadow could be quite useful in the view menu. They'd just need to be worked in, because our menus (like everything else) exhibits an unusual richness in complexity.
Best Regards, Martin Owens
Replying to various comments from different messages, all in one place.
From this message:
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.
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.
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.)
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)?
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.
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?
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 this msg:
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@lists.sourceforge.net Subject: Re: [Inkscape-devel] [UI] Rework Document Properties dialog
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.
I would very much disagree about turning the snap toolbar into a dialog!!
--------------------------------------------------
From this msg:
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@lists.sourceforge.net Subject: Re: [Inkscape-devel] [UI] Rework Document Properties dialog
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.
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@lists.sourceforge.net 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.
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.)
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)?
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.
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?
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
On 31 May 2016 at 22:35, Brynn <brynn@...3133...> wrote:
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.)
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)?
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
Of course. I've added that to the wiki article.
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.
Sure, you can't have shortcuts for everything. Assigning one also depends on how often it is supposed to be used.
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?
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!
Of course data should only be send back with the consent of the user. Though I do not want to open Pandora's box here starting a discussion about usage data collection.
From this msg:
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@lists.sourceforge.net Subject: Re: [Inkscape-devel] [UI] Rework Document Properties dialog
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.
I would very much disagree about turning the snap toolbar into a dialog!!
Reason? Taking too much UI space? Anyway, I already revised my statement in a later message saying that the options should be moved to the global Preferences dialog.
From this msg:
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@lists.sourceforge.net Subject: Re: [Inkscape-devel] [UI] Rework Document Properties dialog
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.
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.
So far nobody gave a reason why people adjust the snap settings of that dialog. I'm very interested in getting a proper use case for them.
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.
UI decisions are always hard to do, as people have very different opinions. Personally I also find the dialog ok to use as I know where to look for the different features, though I believe some parts of it can be optimized. So, as mentioned earlier, I consider some properties to be global, some unused or rather confusing people and some just not being or expected to be part of the document properties.
Sebastian
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@lists.sourceforge.net 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.
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.)
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)?
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.
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?
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-tp4976... Sent from the Inkscape - Dev mailing list archive at Nabble.com.
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-tp4976... 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:
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-tp4976... Sent from the Inkscape - Dev mailing list archive at Nabble.com.
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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On 1 June 2016 at 17:46, LucaDC <dicappello@...2144...> wrote:
Sebastian Zartner wrote
...by removing the option for relative changes...
WHAT?!? I didn't notice this, good you pointed out. Erm, well, I'll be explicit: don't even dare thinking to do something like this! This makes me think that you don't have a clear idea about some important use cases for guides. Really.
I missed to explain why. You can do relative changes by entering calculations into the fields just like in all the other value fields.
Sebastian Zartner wrote
...and the unit;
Why? Don't you think that they are there for a reason?
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?
Now I fear that there are other decisions you took without making them explicit but I don't have time to x-ray your blueprint, sorry. I'll see how it goes on hoping that someone else will join the analysis to help. Be sure you're going to hear me if you break something. :)
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.
Please, before introducing the changes you're thinking about, let me invite you to go a bit more into the argument because I fear you don't have a picture clear enough to avoid missing some important points like the ones above. My opinion is that you're going to touch more points than intended for the main goal of your blueprint. Let me advise you to be careful.
Guides are a very very important tool for my workflow (and I suppose not only for mine) and if you break 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:
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.
Fixed. I didn't mean to change it. The current default is rgb(102, 102, 102).
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.
My intention was to move all those options to the View menu, which was accepted by Martin and Brynn.
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.
The feature itself is clear to me. Though I still wonder whether that is actually something people use.
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.
Sounds good to me to move them to the main interface.
On 1 June 2016 at 19:22, Maren Hachmann <maren@...3165...> wrote:
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... ;)
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 missed to explain why. You can do relative changes by entering calculations into the fields just like in all the other value fields.
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
Sebastian Zartner wrote
...and the unit;
Why? Don't you think that they are there for a reason?
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?
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
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'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
My intention was to move all those options to the View menu, which was accepted by Martin and Brynn.
And that's fine for me too, as long as the options are still reachable somewhere.
Sebastian Zartner wrote
The feature itself is clear to me. Though I still wonder whether that is actually something people use.
Same as before: if you take this feature away, nobody will use it for sure.
Sebastian Zartner 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.
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-tp4976... Sent from the Inkscape - Dev mailing list archive at Nabble.com.
Please excuse the long delay! I was very busy the past two weeks.
On 2 June 2016 at 18:18, Brynn <brynn@...3133...> wrote:
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.
A tooltip already helps, I guess. What may also be added is a little visual indicator within the fields like a +/- sign to improve the discoverability. What do you think abou that?
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.
I still believe that having different units all over the UI is counter-intuitive for most users, though I've still added it back now.
It seems you're branching out from just reworking the Document Properties dialog?
Reworking the dialog requires thinking about what to do with the options it has at the moment, which includes the guides options placed in it. Moving options out of it means they need to be put somewhere else. So, this affects other parts of the UI as well. And merging them with the ones from the Guideline dialog seems logical to me.
On 3 June 2016 at 11:11, LucaDC <dicappello@...2144...> wrote:
Sebastian Zartner 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.
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.
Calculations should always be done on the exact coordinates, not their visual representation, but that's a whole different story and should be discussed separately from this thread.
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.
As I get it, your current workflow is: 1. Double-click the guide line => Dialog opens, focus is already in the right field. 2. Enter a new relative value 3. Hit Enter to accept the value and close the dialog 4. Edit something on your objects 5. Start over from step 1
The suggested workflow is: 1. Double-click the guide line => Dialog opens, focus is already in the right field. 2. Press Left Arrow, Plus and enter the relative value 3. Edit something on your objects 4. Click into the field you want to change 5. Type Plus and enter the new relative value 6. Start over with step 3
So, when you often edit the same guide line, you'll additionally have to press Plus but save the step for opening the dialog again on subsequent changes.
Sebastian Zartner wrote
Sebastian Zartner wrote
...and the unit;
Why? Don't you think that they are there for a reason?
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?
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?
If a feature is not used, it benefits the UI to remove it.
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 can see your point. As mentioned above, I've added the units field back now.
Sebastian Zartner wrote
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'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.
And that's great. I'd love to get such detailed input from more users.
Sebastian Zartner wrote
The feature itself is clear to me. Though I still wonder whether that is actually something people use.
Same as before: if you take this feature away, nobody will use it for sure.
Well, that's clear. ;-) The question was whether people use it *now*.
Sebastian Zartner 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.
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.
There are always people that complain about everything, other people that are happy with things as they are, people that would like to have things changed but don't raise their voice, etc. Also, people are creatures of habit, so there are always complaints when something gets changed. To answer your question, one mention is at https://sourceforge.net/p/inkscape/mailman/message/32764778/. There were others, though I'd need to look them up again.
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.
That's a good idea! I think, once the discussion has settled, I'll split the changes up in the ones we agreed on, covered by the blueprint, and the ones needing further discussion, for which I'll create new blueprints or bugs.
Sebastian
Sebastian Zartner wrote
Calculations should always be done on the exact coordinates, not their visual representation, but that's a whole different story and should be discussed separately from this thread.
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-tp4976... Sent from the Inkscape - Dev mailing list archive at Nabble.com.
On 22 June 2016 at 16:24, LucaDC <dicappello@...2144...> wrote:
Sebastian Zartner wrote
Calculations should always be done on the exact coordinates, not their visual representation, but that's a whole different story and should be discussed separately from this thread.
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?
Yes, it's more complicated than just parsing the mathematical string, though provides more precise results. If one of the values is the rounded version of the exact original value, it's mapped to the original value in calculations.
Also, when I hit enter I assume that I'm inputting what I see, not what the program thinks while showing me something different.
So you accept the rounding errors.
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.
That's wrong. The problem already exists today. You can already enter calculations into those fields. And it applies to all fields allowing calculations, so it's a broader issue.
Sebastian
Sebastian Zartner wrote
Yes, it's more complicated than just parsing the mathematical string, though provides more precise results. If one of the values is the rounded version of the exact original value, it's mapped to the original value in calculations.
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
Also, when I hit enter I assume that I'm inputting what I see, not what the program thinks while showing me something different.
So you accept the rounding errors.
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
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.
That's wrong. The problem already exists today. You can already enter calculations into those fields. And it applies to all fields allowing calculations, so it's a broader issue.
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-tp4976... Sent from the Inkscape - Dev mailing list archive at Nabble.com.
On 23 June 2016 at 09:06, LucaDC <dicappello@...2144...> wrote:
Sebastian Zartner wrote
Yes, it's more complicated than just parsing the mathematical string, though provides more precise results. If one of the values is the rounded version of the exact original value, it's mapped to the original value in calculations.
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
Also, when I hit enter I assume that I'm inputting what I see, not what the program thinks while showing me something different.
So you accept the rounding errors.
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.
Ok, that's a valid point.
Sebastian Zartner wrote
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.
That's wrong. The problem already exists today. You can already enter calculations into those fields. And it applies to all fields allowing calculations, so it's a broader issue.
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.
As a simple solution to this issue I've extended the number of displayed decimals to five. Though I've also added back the checkbox.
Sebastian
participants (6)
-
Brynn -
Diederik van Lierop -
LucaDC -
Maren Hachmann -
Martin Owens -
Sebastian Zartner