Proposal for new "stealth" selection mode

Previous topic - Next topic

GarryP

Situation

Currently a coloured selection box is shown around the selected object.

Problem

The selection box can sometimes distract the user from the overall look of the page.

See the attached screen grab as an example. While the selection box is displayed it cuts through some other objects and makes it difficult to see how changes made to the selected object look in relation to the rest of the page.

The user has to de-select the object to see how the page looks, then re-select the object again to make changes. However, de-selecting the object (selecting nothing) "resets" the Properties Palette so you also need to re-select the PP tab you were last in.

So, you make some changes to, for example, the text size, then you need to de-select the object to get a better idea of how the text looks. Then, to make further changes, you need to re-select the object, then re-select the Text tab, then make the changes. Then do it all over again, if necessary, until it's right.

(Even if the PP didn't "reset" you would still have to de-select & re-select.)

This can make the user workflow much longer than it needs to be by adding lots of extra steps to tweak an object to get it looking right on the page.

Proposal

Add a new "stealth mode" to the selection process - toggled on/off via a button next to the Preview Mode button - which could work as follows:

* When an object is selected the selection box appears (as usual).
* However, when the pointer moves a certain distance from the selected object - or outside the bounds of the selected object - the selection box goes invisible (preferably fading out after a second or so).
* The object is still selected but the selection box is not shown.
* When the pointer moves back to the selected object the selection box can be shown again (preferably fading back in) to allow for moving/resizing etc.

This would allow the user to see the page as it would be printed - just move the pointer away - while alleviating the need for the extra de/re-selecting.

See attached animated GIF for a simple example.

I think this will make Scribus much better to use for complex pages. (And it will look pretty nice too!)

I know this probably isn't a major issue for everyone but with the kind of layouts I produce I can be de/re-selecting very frequently and, frankly, it's a pain in the bum.

What does everyone else think? Good? Bad? Pointless?

[attachment deleted by admin]

Nermander


GarryP

Not really.

When you use preview mode - and that's my usual mode - you can always see the selection box, which is the problem I've outlined above.

I'm not suggesting a new "mode" really, more of a tweak that allows the selection box to disappear when you're not near/on it. It could work in any of the existing modes.

Nermander

Well, my point was rather that in preview mode you should only see the page as it will look, thus selections frames should not be visible in preview mode.

GarryP

That would make things worse.

I often use preview mode to get rid of all the clutter and concentrate on how the page looks. For instance, I'm not really bothered where the frames actually are, just that whatever is in them is where I want it to be on the page.

I also often have objects stacked on top of each other. If I can't see which one is selected then I would have to start naming them so I can check which is selected in the PP and that would be way more hassle than what happens now.

a.l.e

personally, i agree with nermander: this is what the preview mode should be.

i don't hink that we need one more mode... but we can for sure improve the preview mode!

and revert that bcadfsdfwerqwreing commit that broke the preview mode and made most things not editable in preview mode.

everybody (but one person) who uses scribus agrees that the current preview is useless... there is a ticket for it... but nothing happens :-(

mnawij

hmmmm.... can preview mode be modified to accomplish this?  I agree with GarryP they do get in the way of designing and seeing the whole picture.  If Preview can be adapted, that would work, otherwise I could definitely use another mode and would not mind one if that was the case.

mnawij

GarryP

If selection boxes are not visible at all in Preview Mode then you are essentially making Preview Mode "read only" and not allowing any changes while it is in effect. In other words, if you cannot see what is selected then you cannot make changes properly. Reducing the functionality of Scribus by removing the ability to edit while in Preview Mode would be a very large step backwards and a very bad idea.

I think the ticket that has been referred to is https://bugs.scribus.net/view.php?id=12464 . This ticket seems to be related to a 1.5.x version which I don't use but the whole issue is still relevant. I would guess that many more people want to be able to edit in preview mode than do not.

I think the idea of a "mode" is getting confused a little here. All I am talking about is the ability to toggle between the current way that the selection box is shown and a different way. Nothing mode than that. Nothing more than if you were to toggle between showing/hiding frame outlines. No extra ways of doing things, no extra modes; just a simple toggle.

All it would mean would be a simple toggle - put it in the view menu if necessary - with the meaning of "Hide the Selection Box if the pointer is not over the selected item(s)".

Coding-wise, in the routine that draws the canvas it would be a change from:

DrawSelectionBox()

to something like:

if (PointerIsOverSelection() && !HideSelectionBox)
{
  DrawSelectionBox()
}


I realise it's more complicated than that but that's what it comes down to.

I have no idea what a "bcadfsdfwerqwreing commit" is so I can't comment on what it did.

Personally I think the Preview Mode - and I'm talking about 1.4.6 here - is okay for most things. It's not perfect - it doesn't show images at full resolution (allowing for monitor restrictions of course) - but it's better than having to repeatedly toggle a whole lot of view options off/on. All I'm asking for is an extra little tweak to say when the selection box is shown.

Nermander

Quote from: GarryP on September 29, 2016, 11:06:21 AM
If selection boxes are not visible at all in Preview Mode then you are essentially making Preview Mode "read only" and not allowing any changes while it is in effect. In other words, if you cannot see what is selected then you cannot make changes properly.
But you just said that you don't want to see what is selected when you are making changes...?

What I am thinking is that you select your object in "edit" mode, switch to preview mode and there you will see the changes of your changes to the properties (but you will not see the cursor, guides, selections etc because those are not printed and the preview mode should only show what gets printed).


a.l.e

euh... garry, if i understand you correctly, you got my opinion the wrong way round: the current default behavior in 1.5 is that you cannot edit while in preview mode and this is imo bad.
the 1.4 behavior should be restored: editing should always be allowed in preview mode.

i did not dig deeply into your proposal, but if people want to see the box around the item below the mouse, i think that this should be made the default (and only) option.

i don't see why adding the feature as optional really makes scribus better.
imo it only adds complexity to the program without any real benefit.

my personal conclusion: i don't think i need the feature, but -- afaict without trying it -- i would not have any problem with having to move my mouse to have a fully borderless preview!

p.s.: of course, in your proposal you have to consider that multiple items could be under the cursor... :-)

GarryP

Nermander:

My proposal is that - when the option to hide the selection box is switched on - the selection box is only visible when the pointer is over the selected object to:
A. See which object is selected (you might have many objects "under" the pointer), or
B. Be able to get at the drag handles for resizing.

Under all other conditions the selection box will be invisible. (When you are making changes via the PP you will know which object is selected because it is the object that is changing.)

Does this make things clearer?

Having to switch between modes to have the selection box appear/disappear is no different to de/re-selecting the object. It's extra clicks that should not be necessary.

a.l.e:

Yes, I think there's some confusion as different people are using different versions of the software. I'm only really concerned with the current stable version as that's what most users should be using.

Anyway, I agree that the Preview Mode of 1.4.6 should be restored and I've added my comments to the ticket linked above. Basically, a "no edits allowed" preview mode is a stupid idea.

I would have no problem having this proposal as the only way of doing things but I think it would confuse beginners, which is why I suggested it as an option. I know you don't like having lots of options - and in many ways I agree with you - but there is always a line to be drawn and in this case I think the line should be drawn on the side of the beginner.

Multiply-selected objects would not be a problem, the selection box is the same as if there's just one object selected. If there are multiple objects "under" the pointer then that's a reason - as mentioned above - that you need to be able to see the selection box sometimes.

Zyphon

Hi Gary,

I completely understand where you are coming from. I usually switch usage between Scribus and Serif PagePlus X9. PPX9 does exactly what you say. When you create a text frame and draw out the shape; if you move the cursor away from the text box it disappears. However hover the move over the text box and it re-appears. Also you can click within this box to get the full editable frame. Please see my attached gif below.

Thanks.

Kind regards,

Michael

[attachment deleted by admin]
Kind regards,

Michael

a.l.e

#12
nice screencast zyphon!

and thinking of what i'm seeing:

i'm not sure yet, if i'd prefer the border and handles only to be shown when the mouse is on the frame or if it should also always be shown when a frame is selected...

sometimes i want to move a frame with the keyboard and not see its border...

the difference between clicking on the box / on the frame has been rejected in the past... and rejected...

but if it's implemented in a very good way, well, i can think i could change my mind :-) (who needs handles if the mouse is not close to them?)

but:
- who specifies that perfect behavior?
- who implements the code?
eh eh eh...

p.s.: well, if i click on a frame and i want to move it with the keyboard... i'm not sure that i would first want to exit the edit mode first... but i wonder

GarryP

Michael, it's good to know that what I was thinking of wasn't just a crazy idea that popped into my head and that something very similar is actually being used in the real world.

Thanks for posting and letting people know what's happening in other DTP software. It's interesting to see how other software does things.

a.l.e

... or we could ask jean to rename the "preview mode" into "blocked mode" :-)