View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0011560 | Scribus | User Interface | public | 2013-05-31 10:26 | 2016-05-01 14:11 |
| Reporter | GarryP | Assigned To | |||
| Priority | low | Severity | minor | Reproducibility | always |
| Status | new | Resolution | open | ||
| Platform | Mac | OS | OS X | OS Version | 10.6.8 |
| Product Version | 1.4.5 | ||||
| Target Version | 1.6 milestone | ||||
| Summary | 0011560: "Is Locked" attribute functionality doesn't match documentation | ||||
| Description | Background: Wiki (e.g. http://wiki.scribus.net/canvas/Working_with_text_frames - Section "XYZ Tab: The Rest") and Help documentation say that the "Is Locked" attribute locks all changes to a frame. Problem: Only the position and size are locked. All other changes are still allowed. See http://forums.scribus.net/index.php/topic,923.0.html for more information. Potential Solution 1 (quick and dirty): * Change Wiki and Help to say that "Is Locked" only locks position and size and nothing else. Potential Solution 2 (harder to do but more consistent): * Change name and functionality of "Is Locked" to "Position is Locked" (while also removing inherent "size is locked" functionality, which is already covered by another attribute). * Change icons in Properties palette to show the difference. * Change documentation accordingly. | ||||
| Tags | locked | ||||
| Patch | No | ||||
|
|
I'm not sure this is a documentation bug, but I can't prove otherwise since I don't have 1.3.3.x around anymore. Rather, the button should do what the manual says. i.e., really preventing the editing of a frame and its contents. |
|
|
I don't believe that the button/attribute can do what the documentation says without significantly breaking how Scribus works. Consider the three following basic scenarios (assuming that when an item is "locked" it means that "nothing about the item including its contents can be changed until it is unlocked", as the documentation alludes to): 1. Create a text frame. Put some text in the frame. Apply a Style to the text. Lock the frame. Change the Style. At this point the contents of the frame MUST change, otherwise there's a disconnect between the Style itself and the Style used in the frame. 2. Create a text frame (A). Put some text in it. Create another frame (B) that overlaps frame A. Make text flow around frame B. Lock frame A. Move frame B. The text contents in frame A MUST re-flow, otherwise Scribus isn't showing the true state of the document. 3. Create an image frame. Put an image in it. Lock the frame. Edit the image using an editor. The image contents MUST change, otherwise Scribus would have to hold its own copy of the image and it won't be showing the image as the user required. And there are loads of other possible scenarios which display the same behaviour. Essentially, if Scribus is to remain a WYSIWYG editor, the contents of frames CANNOT be locked from changes. So, with this in mind, I think that - at the very least - the documentation needs to be changed to say that frame contents are not locked and that changes can still be made. Moreover, since the "Is Locked" attribute really means that only the position and size are locked, and that there's already a "Size is Locked" attribute, the "Is Locked" attribute is probably better renamed as "Position is Locked" while also removing the size is locked functionality from this attribute. This would give two distinct attributes which are easily differentiated - one for "lock position" the other for "lock size". To me this would be much more intuitive; you know exactly what you're locking, rather than having to guess/remember what else is happening. P.S. Apologies for the capitals, there's no bold or underscore. |
|
|
GarryP : "content of an item" and "layout of that item" are 2 different things. The content of an item is the data that is inside this item (text, name of file, styles, options and parameters applied). Your examples show that the layout of an item can change even when the content of the item does not change, because the layout of an item depends also of environemement data (other items, styles, content of an other file). This does not prevent the content to possibly be locked (which wouldnt mean that the layout would not change). I dont know about the best options are because there are many possibilities : - lock position - lock size - lock position and size - lock content In case the PP is splitted in 2, with 1 palette for the content properties and 1 palette for frame properties, it would make sense to have : - lock frame - lock content See also : the display of the selection handles and of the mouse pointer dont fit with the performed lock (0011686) |
|
|
Sorry, JLuc, I may be getting mixed up with the names of things because I'm looking at it from a user perspective. When I say "content of a frame" I mean "the stuff that can be seen inside the frame" and when I say "layout" I mean "where the frame is on the page". It seems from what you've said that I'm using simplistic naming so I apologise for any mix up. I'll try and re-word what I said to attempt to make myself a bit clearer. As Scribus currently works, the stuff that a person can see on the page inside a frame *cannot* be made impervious to all changes because of such things as: changing a style, or editing the image outside Scribus, or many other functions. However, the position and size of a frame on a page *can* be made impervious to changes by using the existing "locked" functions. Currently there are two "locked" buttons (as described in the documentation): the first (1) for "lock content and position", and the second (2) for "lock size". The second (2) seems to work fine, both as documented and as a normal user would expect (except for the issues in bug report 0011686). The first (1), as mentioned previously, cannot "lock" the contents of the frame - as the general user would describe them - but it does "lock" the position and other attributes such as Level and Node Editing etc. This makes things complicated for the user as they have to try and remember what sort of thing is locked and what isn't. To the general user - especially one who reads the manual - locking an object means "making it totally impervious to all changes". The current lock (1) doesn't work that way and it can't until Scribus works very differently internally. So, after reading the above and having more thoughts, my latest proposition is to have three "lock" functions. [A] Lock Position (including Level), i.e. stop all XYZ movement. [B] Lock Size only, i.e. stop any resize actions. [C] Lock Others. (By "Others" here I mean everything but Size, Position, and "contents". There's probably a better name for this.) The first two locks are probably the most used. The third is more of a "catch all" for everything else that can actually, in reality, be "locked". Having a separate lock function for every attribute would give users fine control over everything but I think it would be "overkill". Using three functions sounds like a good compromise to me. A fourth - [D] Lock Contents - can be introduced at some future time but I can't see it happening without major internal changes to the way Scribus works. Whatever happens, the manual needs to be changed to tell users that "locking" an object doesn't necessarily mean that changes can't happen to it or the stuff inside it. This documentation change, by itself with no programming, is the easiest change to make and would stop users getting the wrong idea. Phew, I hope I've managed to be a bit clearer this time. |
|
|
Situation has been replicated in 1.4.5. (Changed product version number in ticket as appropriate.) I've also just noticed that a shape can also be resized through the Node Editor even when "Size is Locked" is active. |
|
|
GarryP - Please don't update versions like that, it indicates the bug or feature requests did not apply to any version prior to 1.4.5. |
|
|
Please accept my apologies. I was asked to review the unassigned issues which were reported by me to see if the issues persisted into the current version. Due to my inexperience with Mantis - I only use it once in a blue moon - I thought that updating the version number would be a good way to show, in an obvious manner, that the issue was still current - rather than it just hanging around - with the history supplying the background for how long it's been open. Obviously this was wrong. (In truth I got a bit carried away thinking that I was helping.) In my defence there's no information - that I could find - on the proper way to update an issue but, in hindsight, I should have asked someone. Having said that though, I'd be happy to correct the wiki documentation accordingly if given the necessary procedure(s). In the light of the above, would you like me to go back and put the version numbers back to what they were? (It would only take a few minutes.) Or would that just confuse things more? I'd like to do what I can to fix things without making the situation worse. Again, my apologies, and I'll try to remember not to do the same thing in the future. P.S. I don't know about the security/authorisation set-up within Mantis but it seems that people like me - who don't know what they're doing - shouldn't be able to do silly things that we shouldn't do. Maybe Mantis can be altered to stop basic reporters like me from making changes that we shouldn't and leave all of the complicated stuff to the people who know what they're doing. For example, reporters can only add notes once someone has properly reviewed the issue. (It might stop similar problems from happening in the future.) |
|
|
Craig, I asked Garry to check his open bugs and see if they are still active/current. I didn't elaborate about: not updating the feature requests or changing the version #. Apologies for the confusion. re: Mantis Mantis has that capability though it's a bit kludgy when it comes to fine tuning permissions. For example, IIRC, If we remove your updater status then you wouldn't be able to fix spelling mistakes in the title of you bug report if you noticed it after you posted it. For the most part, I recommend keeping the status you have because you are a Scribus power user and contribute often. The mistake you made was minor. |
|
|
GarryP.. no problem.. all good :) |
|
|
Moved to 1.6 Milestone just so it doesn't get lost and if the change is made that it would be consistent with the documentation release for 1.6 |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2013-05-31 10:26 | GarryP | New Issue | |
| 2013-05-31 21:26 | christoph_s | Note Added: 0030207 | |
| 2013-06-01 09:59 | GarryP | Note Added: 0030213 | |
| 2013-07-26 18:09 | JLuc | Note Added: 0030464 | |
| 2013-07-26 18:33 | JLuc | Note Edited: 0030464 | |
| 2013-07-26 18:33 | JLuc | Note Edited: 0030464 | |
| 2013-07-29 12:51 | GarryP | Note Added: 0030474 | |
| 2015-02-02 09:45 | GarryP | Patch | => No |
| 2015-02-02 09:45 | GarryP | Product Version | 1.4.2 => 1.4.5 |
| 2015-02-02 09:45 | GarryP | Note Added: 0034424 | |
| 2015-02-03 06:37 | cbradney | Note Added: 0034432 | |
| 2015-02-03 09:41 | GarryP | Note Added: 0034433 | |
| 2015-02-03 13:24 | Kunda | Note Added: 0034434 | |
| 2015-02-03 13:28 | Kunda | Note Edited: 0034434 | |
| 2015-02-03 21:33 | cbradney | Note Added: 0034435 | |
| 2015-03-23 23:24 | Kunda | Note Added: 0034738 | |
| 2015-03-23 23:24 | Kunda | Target Version | => 1.6 milestone |
| 2016-05-01 14:11 | Kunda | Tag Attached: locked |
