Proposal for new "stealth" selection mode

[Zyphon]

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

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.

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.

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.

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

[a.l.e]

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

[Zyphon]

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.

[GarryP]

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

[Zyphon]

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

[a.l.e]

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

[GarryP]

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.

[a.l.e]

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? :-)

[Nermander]

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.

[GarryP]

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.

[Zyphon]

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.