proposal for different grids and guides UI

[lochi009]

Hello

I work with "guides and grids" very often. What I really don't like with the current scribus UI, are the many different places you have to go, to to adjust these.

We have

File --> Document Setup / Preferences
Page --> Manage Guides
Page --> Snap to ...
View --> Text Frames --> Show Baseline Grid
View --> Grids and Guides --> Show ...

That's why I would like to suggest the following proposal for the UI:

Grids and Guides are not much different to layers, as which they are handled by scribus internally anyway, I suppose.
So why don't treat them as such, also? My proposal is to implement either a second layer-panel for grids and guides or to merge it as a new part of the existing layer-panel.

To illustrate my thoughts, I made the attached draft, based on the existing scribus layers-panel.

Aside to much less "clicking" this could maybe also lead to the possibility to define different grids (grid1, grid2, ...) or different guide-combinations for one page, that could be used with more flexibility, e.g. show, snap to, reordering etc.

regards, lochi009


[attachment deleted by admin]

[GarryP]

Welcome to the forum lochi009.

That's a really nice idea that I would also like to see in Scribus. I like the idea of having control of all of the guides and grids in one place.

I'm sure that a lot of thought will have to go into the idea so that nothing is overlooked but it's got my vote from the start.

I would like to add a suggestion that the drawing/placement - I.e. foreground versus background - is also handled by this dialog rather than having to go into Document Setup.

And, just wondering about extending it a bit further, could things like frame outlines and margins be handled in the same way?

Could this also be further extended to other non-document displayed items such as rulers, text chain arrows, layer indicators? That might be going too far but having a single place to control the display of things that aren't part of the document might be very useful.

Anyway, even if this only does guides and grids it would be an excellent addition to Scribus.

P.S. I also like the idea of having multiple grids but I think that might be a separate function to this.

[a.l.e]

can i ask you, what you are using the grid for?

personally, i see it more as a stumbling block that hinders people from discovering / developing good workflows (guides, rows / columns, frame snapping).

in some cases i use the grid in vector design, but i've never did feel the need with scribus...

[lochi009]

To be honest, I actually use the guidelines most oft the time (for rows and columns in magazine layouts). But why should the grids be left out, when one thinks about a streamlined UI (in my opinion) for that kind of "service-layers".

By the way: I filled a bug-report with my idea.

https://bugs.scribus.net/view.php?id=14573

[a.l.e]

psst, don't tell anybody, but in secret i would love if the grid -- as they are currently implemented in scribus --  was removed from scribus.

and since it's a goal that cannot be achieved, i would at least keep grids and guides as far apart as possible...

(
basically: people are lazy and if they see that they can use the grid to have a visible structure, they (rightly) do so. and then they ask more and more features to be added to the  grid, until the grid becomes more and more like the guides but way harder to use... finally, instead of having better guides, we get bloated grids that are hard to use. and no better guides.
yourself, you're asking for a new dialog that triggers the guides manager... instead of displaying the guides manager itself : - ) you see what i mean?
of course, everybody is entitled to her opinion and my answer is also only my opinion!
)

p.s.: really, i'd love to see a dialog that makes it easy to manage everything about the guides in one place... like putting them shortly above everything and moving them down again when i'm done with that set of guides on top of an image...
a dialog that can be kept open during the work... a bit like the one your suggesting, but just for the guides...
(i just had to do that and it's a bit "awkward" to look for it in the document settings...)

[GarryP]

On a first read, I like the latest idea shown in the bug report of mixing the layers and "service layers" (I really like that name for some reason) together into the same dialog. I'm not sure how it would work in practice but it sounds sensible to me at the moment. (I haven't got 1.5.3 so I can't read the SLA.)

One thing I would add is that the service layers should look different in some way to content layers so they can be mixed together in the order the user wants without the user getting confused as to which is which. For example:
1. Content Upper Layer
2. [Margins]
3. Content Lower Layer
4. [Guidelines]
5. Content Background
6. [Baseline Grid]
7. [Grid]

Adding some "send to top" and "send to bottom" buttons would also make things easier to use when the number of layers gets large. (I think this is another way of saying what a.l.e said, but maybe not.) In general, full control over the z-order of all of the layers (normal and service) would be a nice thing.

P.S. On the matter of grids, personally I think the grid should only really be used when drawing vectors and shouldn't be used for page layout but people do use them so - since the grid will probably be around forever - why can't we have different ones for different uses on different pages? If we have to have a grid, why not multiple ones and the user can select which one they want to use depending on what they want to do? E.g. On page 9 you display a 1cm grid and when on page 15 you switch the 1cm grid off and switch a 1in grid on. That sort of thing. (Oh, and while grids are an issue, can we please have an isometric grid option too?)

[utnik]

...why not multiple ones and the user can select which one they want to use depending on what they want to do? E.g. On page 9 you display a 1cm grid and when on page 15 you switch the 1cm grid off and switch a 1in grid on. That sort of thing. (Oh, and while grids are an issue, can we please have an isometric grid option too?)

wouldn't it be better practice to use a vector drawing tool for vector artwork and a layout tool for it's designed purpose?

utnik

[GarryP]

Absolutely.

But... Can you give me the specification of exactly what a layout tool should and should not do? Specifically, can you give me a list of the features that Scribus should and should not have? And, even more specifically, can you explain why each feature should or should not be in a layout tool?

It's not easy.

For instance, if you want a circular image frame - a reasonable request - should you have to draw it in another application and import it into Scribus? Probably not. So, if you can draw circles then you probably already have a function for drawing curves. So shouldn't the user be able to draw curves also? Well yes, I suppose. So now you also have a curve drawing tool. If you have a curve drawing tool then that's just a fancy line drawing tool. So now you also have a line drawing tool. If you can draw lines and curves, surely it would be possible to change the colour and width and other aspects of the lines/curves such as what goes at the end points? Well, yes, probably. So now you have arrow drawing functionality on top of being able to draw lines and curves. And so on, and so on. This is quickly turning into vector artwork.

And so my main question is this: "At which point do you stop?" Or, to put it another way: "When does a function become a vector artwork tool rather than a layout tool?"

I've never seen any definition of what constitutes layout software functionality and I'm pretty sure that one doesn't exist. And that's the problem. There is no definition of what Scribus should and should not do, so how can anyone say that a feature should or should not exist? There is no "Functionality Police" working to make sure sure that features only exist because they have to.

To cut a long story short (too late?), Scribus has vector drawing tools, therefore it should have a grid that supports those tools. The grid should not be used to create layouts but there is no way of stopping people from using it that way. If people want to use the wrong tool for the job then that's up to them.

Anyway, I'm more interested in what people think about the original poster's idea of putting all of the layer (content and service) controls into a single dialog. That's the thing that I think is more important than discussing whether Scribus should continue to have a feature that will never be removed.

[utnik]

hi gary

...Scribus has vector drawing tools, therefore it should have a grid that supports those tools.

i disagree!
there are quite some disadvantages of the grid in scribus:

   
• beginners use it instead of guides – but everything snaps everywhere...
• users miss the benefits of the page, margin and object related grids generated by guides in rows and columns
• a 'do everything application' will always be crippled in comparition to specialized tools.

The grid should not be used to create layouts but there is no way of stopping people from using it that way. If people want to use the wrong tool for the job then that's up to them.

but you can show it in the same place as the more useful guides or you hide it somehow – just to priorize the better choice...
in earlier scribus versions the default color palette showed a limited set of colors. the newbies didn't understand, why scribus doesn't allow the use of more colors.
now there ar only the standard rgb and cmyk colors, white and 'registration' in the the default color palette and almost nobody complains about a limited color set – maybe the absence of a useful color set let the user search for (and find) a possibility to create colors, while a limited color set let them think of a limited functionality. the same could happen with advanced guides and the grid...

can you give me a list of the features that Scribus should and should not have?

no – i can't...
but i don't like the idea to implement everything into the same tool. some user request for a full vector drawing tool as a part of scribus. others would like to see the .pdf export blown up to a complex impositioning software.
...i prefere a slim and stable tool for a specific task.
for scribus, this means:

   
• good import options for the essential text, data base, table, image and vector graphic formats
• a highly developed style management (character, paragraph, line...)
• complex typographic options
• (a bit more than) basic text editing tools (and maybe the option to link text instead of importing it...)
• a reliable color management
• basic vector drawing tools
• export options to the actual print and publishing formats

i could have missed something. but i don't need stuff like the built in image tools (interesting, but limited and resource absorbing ... and they make the program more complex...)

utnik

[GarryP]

Okay, the way I see it there are two issues relating to the grid:
1. The grid should not be available for layout purposes;
2. The grid should be available for vector drawing purposes.

I don't think anyone is arguing with the first point. Using the grid for layout is bad, full stop.
I also think that there's no real argument against the second point when taken by itself. A grid can be an invaluable tool when manipulating vectors and that's why every single vector drawing application - and just about every application that allows for any vector manipulation - has a grid.

So, how can we reconcile these two, apparently, opposing viewpoints?

Well, what about moving all of the grid functionality to the Node Editor?

If the grid was only available while the Node Editor was open, users would not be able to use it for layout - where it shouldn't be used - but they could still use it for vector editing - where it's needed. (The guides and margins would, of course, still be available in the Node Editor as they are now; there's no reason to change that.)

No functionality would need to be added and none would need to be taken away. The only thing that would change is that the controls for the grid - visibility/snapping/etc. - would be moved from the general UI into the Node Editor UI. (The controls would need persistence between Node Editor invocations - so that the user didn't need to keep switching things back to how they wanted it - but that shouldn't be very difficult.)

If a user doesn't use the Node Editor then they will not know that a grid is available and so will be forced to find out that they should be using guides. Once the user starts editing vectors they will find out there is a grid available but it's only there for vector editing. And they will already have learned to use guides for layout so they're unlikely to want to unlearn that to use something worse.

(Actually, there is a chance that someone might still try and use the grid for layout but they would have to be using the software in such a bizarre, awkward and long-winded way that they should either be given a medal for perseverance or be referred for some kind of psychological tests. It would be like driving to a nearby furnace every time you wanted to light a cigarette; it's do-able but it's so non-practical that only a crazy person would do it.)

What do you think? Would this solve both problems at the same time without creating others?

[a.l.e]

yes, in the context of the node editor, the grid can be useful.

but it's only useful, if the grid's origin relates in some way to the drawing, not the origin of the page.

even if, in most cases, having a good snapping between nodes, lines & co is probably a better way of aligning things...
(so, if i would have to choose in improving the nodes snapping and moving the grid to the nodes editor, i would suggest simply dropping the grid)

all in all, i don't feel a urge to improve the grids (as utnik says: not a core tool for scribus) but if changes are made, they should go in a good direction...
making the grid more visible in the layout context is imo not a good direction.

[GarryP]

but it's only useful, if the grid's origin relates in some way to the drawing, not the origin of the page

I disagree.

The whole point of having a grid - as it currently functions in Scribus - is that you can align things to the same vertical or horizontal. That's what a grid is for. To put it simply, rows and columns.

If the origin of the grid was related to the individual shapes then it would be useless for alignment between shapes as they would have their own independent grids with different origins. The grid, therefore - and see below for a caveat - must be universal to all shapes on the page. (You could, however, have a different grid on different pages - or spreads - like you can with guides.)

To think about it differently: In the same way, guides are not related to frames, they are universal to the page. If guides were related to frames - in the same way as you say the grid should be - then there would be the same problem. It's the guides that allow the layout for the page. The guides are not just for specific frames, they're for the whole page. It's the same for the grid. So both guides and the grid should be defined to the page, not the frames/shapes.

Guides are for the page, not individual frames. Grids are for the page, not individual shapes.

However, having said all that, there could be a good argument for shape-specific grids where you aligned shapes using the guides or the geometry of other things on the page but that would require much better snapping and alignment tools. And since we don't have those, the grid must be page-oriented. If we did get much better snapping/alignment tools then I'd be happy to reconsider my opinion in the future but I can only comment on the current situation. (If someone wants to start a separate discussion about the future direction of snapping and alignment then I'd be happy to chip in with some comments but I think that's even further out of the scope of this post.)

having a good snapping between nodes, lines & co is probably a better way of aligning things

I disagree (as Scribus is currently, but keep previous comment in mind).

Consider, for instance, the exercises in: https://wiki.scribus.net/canvas/Bezier_Curve_Basics_-_Part_1_-_Simple_Geometric_Shapes

How would you draw any of those examples without a grid? Without a grid you would have to enter specific co-ordinates for each node and control point; a very laborious task.

I'm not saying that the grid should be kept just because these exercises couldn't be drawn otherwise, but this is how you draw geometric shapes, with a grid. A grid is both a vertical and horizontal rule at the same time. You draw a shape in relation to the other points of the shape. That's how geometrical construction normally works. (Not always, but normally.) I realise that this sounds a bit like having a shape-specific grid would be better but without the better snapping/alignment tools it would not be.

Yes, we do need better snapping functionality (see above, in various places), but currently that is not a substitute for a grid. The grid is needed because it gives you a structure to work with, or to put it another way, a ruled substrate upon which you can work.

(Even with better snapping and alignment you can't do everything that a grid allows for. If you want to put a point at a specific place but there's nothing to align it to then you're stuck. With a grid you just put it where you want. Done.)

Dropping the grid altogether - without providing tools that would make it obsolete - would make Scribus far less usable for shape drawing and almost impossible for geometric work. People would say, "Here's an application that lets you draw vectors but it has no grid to draw them on. Wow, that's terrible. What other basic stuff doesn't it have? How much is InDesign again?"

It would be far better to pack the grid away into the Node Editor where it is useful and doesn't get in the way of the page layout. Once the grid is "inside" the Node Editor, it can then be worked on separately to the rest of the application.

I know that Scribus isn't an art application and I know it's not a CAD application, but it does allow the creation of vector art and geometrical shapes (whether by accident or intention is irrelevant, it just does). Because of this, and until it provides better tools, it needs a grid and that grid should be "inside" the Node Editor and it should be a page-related grid. The grid doesn't need to be improved, at the moment, just moved so that it's out of the way of the layout stuff.

I don't think I can make myself any more clearer on this issue.

[a.l.e]

personally, i don't do vector design in scribus.
inkscape is a copy paste away...

by combining the two softwares, i have most of the advantages, i wrote about in the previous post.
but i agree, sometimes, it can be handy to do the vector work inside of scribus.
that's why, having vector tools inside of scribus is a good idea!
(even if you probably can achieve everything, by going back and forth between scribus and inkscape.)

concerning the pacman: in inkscape, you can add four points at random places in the lower line and and then distribute them equally between the extremes. then duplicate some of them and move them around.
i think that i would only use the grid for drawing diagrams... but, i don't do that much anymore...

anyway, i'm not here to convince you not to use the grid, but if something has to change, i'd like the grid to be a bit more hidden and not getting even more visibility.

on the other side, improving the guides management would be very very welcome!

[utnik]

i don't use the node editor very often – but the reason could lie in its limitations...
some vector work inside of scribus can be handy. (i. e. adjusting the textflow around a graphic, let a graphical element flow out to the bleed area without losing much of it...)

i would like to see some improvements:

   
• the possibility to define the position of a node by numeric values
• shift click to select multiple nodes
• even a snapping grid could be useful – but i agree with ale: the grid should be related to the graphic. (for the layout work the guides are much better!)

utnik

[GarryP]

As I have already said above, the grid has to be defined to the page rather than individual shapes.

If you are creating a diagram or drawing that uses multiple shapes then the grid must be shared between the shapes, otherwise the grids would not have the same origins. If the grid used in one shape has a different origin to the grid used by another shape it means you don't have a way of making things join up. The grids are not the same so the shapes cannot use the same points. I really can't think of a way to explain this any clearer. Just think about it for a while.

Defining the position of a node with numerical values is pointless (pardon the pun) if you use a properly defined grid that allows for snapping. The grid gives you the points you need and you snap to those points. It's what a grid is for. Think of graph paper. You use graph paper so you don't have to measure things, you just draw from point to point.

Being able to easily select multiple nodes would be very useful and a great time-saver.

Anyway, this is all irrelevant to the original poster's idea about having all of the controls for layers and "service layers" in one dialog. Does anyone have any comments on that?