Scribus Forums

Development => User Interface => Topic started by: GarryP on September 28, 2016, 02:14:40 PM

Title: Proposal for new "stealth" selection mode
Post by: GarryP on September 28, 2016, 02:14:40 PM
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]
Title: Re: Proposal for new "stealth" selection mode
Post by: Nermander on September 28, 2016, 02:18:34 PM
Wouldn't this be just like a preview mode?
Title: Re: Proposal for new "stealth" selection mode
Post by: GarryP on September 28, 2016, 02:36:58 PM
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.
Title: Re: Proposal for new "stealth" selection mode
Post by: Nermander on September 28, 2016, 02:52:58 PM
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.
Title: Re: Proposal for new "stealth" selection mode
Post by: GarryP on September 28, 2016, 03:19:53 PM
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.
Title: Re: Proposal for new "stealth" selection mode
Post by: a.l.e on September 28, 2016, 03:48:14 PM
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 :-(
Title: Re: Proposal for new "stealth" selection mode
Post by: mnawij on September 28, 2016, 11:16:12 PM
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
Title: Re: Proposal for new "stealth" selection mode
Post by: 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. 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.
Title: Re: Proposal for new "stealth" selection mode
Post by: Nermander on September 29, 2016, 12:13:00 PM
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).

Title: Re: Proposal for new "stealth" selection mode
Post by: a.l.e on September 29, 2016, 12:43:49 PM
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... :-)
Title: Re: Proposal for new "stealth" selection mode
Post by: GarryP on September 29, 2016, 01:40:54 PM
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.
Title: Re: Proposal for new "stealth" selection mode
Post by: Zyphon on October 04, 2016, 11:35:59 PM
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]
Title: Re: Proposal for new "stealth" selection mode
Post by: a.l.e on October 05, 2016, 09:45:54 AM
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
Title: Re: Proposal for new "stealth" selection mode
Post by: GarryP on October 05, 2016, 03:48:01 PM
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.
Title: Re: Proposal for new "stealth" selection mode
Post by: a.l.e on October 05, 2016, 04:24:28 PM
... or we could ask jean to rename the "preview mode" into "blocked mode" :-)
Title: Re: Proposal for new "stealth" selection mode
Post by: Zyphon on October 05, 2016, 08:41:14 PM
Quote from: a.l.enice 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...

Thanks, I can see where you are coming from. I think perhaps the user could have the option to turn this feature on and off. I agree sometimes I do like to see where the frames are so that I can move them into position with the keyboard. However once they are placed and you are happy with them this feature would be useful for a clean display of the final layout.

I'm no expert coder but perhaps this feature could be toggled on and off by setting a flag in the code. 0 for off and 1 for on. I don't know how difficult this would be to implement it into the main code.

Quote from: GarryPMichael, 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.
You're welcome. No it is not a crazy idea :) and yes it is nice to compare different DTP software and how they deal with certain situations. I do like the idea of the frames auto-hiding, however like I said in my response to a.l.e above it would be good if this feature could be switched on or off to suit the individual's needs.

Quote from: a.l.e... or we could ask jean to rename the "preview mode" into "blocked mode" :-)

I'm not so sure. I do like the preview mode and I use it frequently to check how my final design will look. I think this should form as an additional feature further down the line.



Title: Re: Proposal for new "stealth" selection mode
Post by: a.l.e on October 05, 2016, 08:51:37 PM
as i already had the chance to say: i prefer software to work correctly and avoid too many configuration options.

some are needed, of course...

but it's the task of the people who create the software to make it correct, not the task of the user to tweak it to work good enough.
configuration is not an excuse for sloppy programming, even if it's just a 1 or a 0 :-)
Title: Re: Proposal for new "stealth" selection mode
Post by: Zyphon on October 05, 2016, 09:04:30 PM
Quote from: a.l.e on October 05, 2016, 08:51:37 PM
as i already had the chance to say: i prefer software to work correctly and avoid too many configuration options.

some are needed, of course...

but it's the task of the people who create the software to make it correct, not the task of the user to tweak it to work good enough.
configuration is not an excuse for sloppy programming, even if it's just a 1 or a 0 :-)
I agree. I think the developers should focus on bug fixes for the next release before even considering this option. I was being deliberately simplistic when I mentioned a 1 or a 0, obviously to code this correctly would need a little more sophisticated programming. :)
Title: Re: Proposal for new "stealth" selection mode
Post by: GarryP on October 06, 2016, 01:23:37 PM
<rant>

Is it really worth us discussing what should and should not be added/removed/changed in Scribus? Is it worth us bothering to give opinions about what we think the future of Scribus should be?

The change to the preview mode is a clear indication that the developers can remove a large and useful chunk of functionality without any consideration to the user base.

It's obvious from comments here and in Mantis that a lot of users liked - and even relied on - the functionality of the preview mode that existed in 1.4.6 but it was taken away without any kind of consultation process.

There is clear proof that many users - from the numbers I have seen it's the majority of users - want the preview mode to go back to how it was in 1.4.6 but nothing has been done about it for more than two years.

I have asked to be given some kind of reasoning for this via Mantis but there has been no reply. No-one has bothered to give any reason at all why such a major removal of functionality was implemented. Basically: "We've done this, you live with it".

Editing software should allow the user to change stuff. That's what it is for. Scribus is a page layout editing application. It's there for people to edit page layouts. It is not a page layout viewer. It is not for viewing page layouts. That is what PDF Viewers are for. (The clue is in the name.) Having a mode in an editor that doesn't allow people to edit stuff is simply pointless. And removing existing functionality that previously allowed editing is stupid.

If someone doesn't want to make changes while in preview mode then they should simply not make any changes. It's that simple. Don't make changes if you don't want changes made. Keep your hands off the keyboard and the mouse buttons and everything will be fine.

If you don't want to make changes to something then you can lock objects or entire layers. That's what locking is for. Why else would it exist?

If the argument is that making the mode read-only is to stop accidental changes then that's what the undo function is for. If the undo function doesn't work well enough for that then fix the undo function, don't remove a very useful chunk of functionality instead.

In my many years of using software I can't ever remember coming across an application that has an "I'm so bad at using this that I need to be stopped from doing anything at all" mode. By all means try and stop the user from doing things that might cause a major problem but don't stop them doing anything at all.

Does GIMP or Photoshop have such a mode? Does InDesign or Quark Xpress? How about Inkscape or Illustrator? What about Blender, or LibreOffice? Can anyone give an example of some software that has a mode entirely given over to not allowing the user to make any changes at all? (I realise that some applications have read-only modes where things like security are involved but that's not the same thing.)

Unless the 1.4.6 preview mode functionality is restored before, or in, 1.6 then I, for one, plan to stick with 1.4.6. It works the way I expect it to work and, for the most part, it works the way I want it to work. It's not perfect but at least it lets me do what I want to do.

</rant> (for now...)
Title: Re: Proposal for new "stealth" selection mode
Post by: Zyphon on October 06, 2016, 09:34:08 PM
@GarryP

I see where you are come from now.

I have been using version 1.5.2 (because of the additional features) that I completely forgot about the fact that version 1.4.6 allowed you to move frames around in preview mode. This was an excellent feature and I can see no logical sense to remove this option. Like you said you can lock frames from accidental movement.

I tested both versions and as you stated in 1.5.2 it makes the document 'read only', I hadn't even noticed this change. I think the 1.4.6 preview option should be re-instated to allow you to move frames around for design tweaks while in preview mode.

Good call.  :)

EDIT: I have just noticed the little "Edit in Preview Mode" button, see attached image. So moving frames can be done in 1.5.2 after all.

[attachment deleted by admin]
Title: Re: Proposal for new "stealth" selection mode
Post by: a.l.e on October 07, 2016, 10:30:24 AM
i think that calling names won't help us.

anyway,

- the change was deliberate (even if it is stupid). it was a feature request.
- the locking in the preview mode is badly implemented, and the document is not even really locked.
- we should focus on getting the improvements to the preview mode here... discussing in here why the change has not been reverted yet won't bring us further.

p.s.: and, yes, one can edit in preview mode, but it's a two steps action, which is insane. and i guess you know what my opinion is, about adding options that distract from implementing a good workflow... (i mean, we could add an option that makes the editable optionally the default one... but scribus would only get more complicated and most people would never discover that option!)
Title: Re: Proposal for new "stealth" selection mode
Post by: GarryP on October 07, 2016, 11:11:15 AM
Thanks for pointing that out Michael.

While there is, as you say, an "Edit In Preview Mode" button, my point is - just to be clear for anyone reading this who is still wondering what the problem is - that it should not be necessary to have to press an extra button to edit in preview mode.

If the preview mode allowed editing by default - and why would it not? it was absolutely fine all the way up to and including 1.4.6 - then the "edit" button becomes redundant.

Someone - I don't know who, and I don't really care - has taken it into their own hands to fundamentally change how Scribus works and no-one is giving any reason for it.

Yes, the developers can do whatever they want; it's their time and effort they are putting into the project. But there should be, at the very least and in all reasonableness, some way for the user base to give opinions about major changes of functionality before such changes are made.

Most users will just use whatever is there and not want to get into discussions about it but there are some users who use Scribus to make a living and major changes can affect them much more than the "average" user.

If a major change is implemented that forces people away from Scribus - for whatever reason - then that's bad for the project overall. We want more people to come to Scribus. Pushing them back to the commercial alternatives just because they can't rely on the software working as well as it used to just makes things worse.

If the developers can make major changes just because of one feature request then that doesn't make for much of a "community driven" project. Major changes should be discussed before any expenditure of effort is made (and then later, potentially, reversed). Surely that's the sensible way to do things?

a.l.e: No offence was intended and apologies for any taken. I was merely calling the decision to make the change stupid, not the person who made the change. Intelligent people make silly decisions all the time; that's why there are so many lawyers.
Title: Re: Proposal for new "stealth" selection mode
Post by: a.l.e on October 07, 2016, 12:36:34 PM
garry, i did not say that you offended me :-)

just that i will not start calling names (and that i think that we should stop repeating that that change is stupid...)

fyi, as far as i recall, the change was asked, because the person wanted to be able to show features that are supported by scribus but not by (most) pdf readers.
iirc, the main target were 3d objects.

now, can we concentrate on the way the highlighting of the hovered frames should work? :-)
Title: Re: Proposal for new "stealth" selection mode
Post by: Nermander on October 07, 2016, 12:59:22 PM
Quote from: GarryP on October 06, 2016, 01:23:37 PM
Having a mode in an editor that doesn't allow people to edit stuff is simply pointless.
The same may apply for a mode that shows how the result is going to look... Scribus is intended to edit the document, hiding the border of a selected item does not help editing, it only helps the preview.

I'm not advocating making the preview mode read only, I'm just picking on the arguments here. Your arguments can be applied both ways.

I have noting against the possibility to edit in the preview mode, what I am against is that the preview mode is requested to only show the frame of the selected object when it is hovered over. Then it is no longer a preview mode, but some mix of preview and edit mode.

To me, it makes most sense to have two modes:
1. Outline/working mode, where guides, margins, object boundaries etc are shown
2. Preview mode, showing the documents as it would look when exported.

Editing can be possible in both modes, but in preview mode if might be hard to select the correct object due to lack of visual feedback. But if the modes can be easily switched between you can select the object in working mode and then change it in preview mode.
Title: Re: Proposal for new "stealth" selection mode
Post by: GarryP on October 08, 2016, 01:30:14 PM
I think what I've already said about the change to the preview mode pretty much sums up what I think about it so I don't see any reason for me to say any more about it unless some new facts come to light.

As for the selection mode/box stuff, my proposal was only valid within the preview mode as it is in 1.4.6. So, unless a decision is made to reverse the change made to this mode as it persists in 1.5.2, the whole point is moot.

If the preview mode continues to be read-only then being able to select objects in that mode is irrelevant. Therefore, if objects can't be selected - because nothing can be done with them - then displaying the selection box is also irrelevant. Therefore, a discussion about how the selection box should be shown in preview mode is also irrelevant. If the user can't make changes in preview mode then there should be no selection box shown.

Why display something that's only there for the user to do something with if the user can't do anything with it?

I don't think there's really much more I can say on this subject. If preview mode 1.5.2 persists then my proposal falls at the first hurdle. Easy come, easy go.
Title: Re: Proposal for new "stealth" selection mode
Post by: Zyphon on October 10, 2016, 09:54:17 PM
Quote from: GarryP on October 08, 2016, 01:30:14 PM
I think what I've already said about the change to the preview mode pretty much sums up what I think about it so I don't see any reason for me to say any more about it unless some new facts come to light.

As for the selection mode/box stuff, my proposal was only valid within the preview mode as it is in 1.4.6. So, unless a decision is made to reverse the change made to this mode as it persists in 1.5.2, the whole point is moot.

If the preview mode continues to be read-only then being able to select objects in that mode is irrelevant. Therefore, if objects can't be selected - because nothing can be done with them - then displaying the selection box is also irrelevant. Therefore, a discussion about how the selection box should be shown in preview mode is also irrelevant. If the user can't make changes in preview mode then there should be no selection box shown.

Why display something that's only there for the user to do something with if the user can't do anything with it?

I don't think there's really much more I can say on this subject. If preview mode 1.5.2 persists then my proposal falls at the first hurdle. Easy come, easy go.

Hi Gary,

I agree the locking of the screen in preview mode is a pointless feature, in my opinion and if people want this option then it should be unlocked by default and locked by clicking the button. Like you if I am happy with the layout of my frames I lock them and if I need to move any of them I simply unlock them move them into position and re-lock them.

It is nice to be able to freely move frames around while in preview mode to fine-tune the layout and having to click the 'edit' button is an unnecessary additional step.

Also I have been in jobs where I was part of the systems change configuration control board where we would look at additional feature requests for our systems and we would only make updates and changes if there was a decent enough percentage of users who requested a particular change (unless of course there was an obvious bug). We would not make unnecessary changes for just one or two people and even if we did it would be very far down on the priority list.

It's a shame as I really do like most of the new features in 1.5.2.