View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0016883 | Scribus | User Interface | public | 2023-01-05 18:19 | 2024-10-23 18:42 |
Reporter | pmjdebruijn | Assigned To | nitramr | ||
Priority | normal | Severity | minor | Reproducibility | always |
Status | closed | Resolution | fixed | ||
Product Version | 1.6.0.svn | ||||
Target Version | 1.7.0 | Fixed in Version | 1.7.0.svn | ||
Summary | 0016883: Ugly/Unreadable Arrange Pages / Document Pages labels | ||||
Description | See the attached screenshot montage for clarity. But the pages shown in the Document Pages section (which master pages are currently being applied to each page) in the Arrange Pages dockable window , typically end up unreadable, unless a two letter prefix is used. The attached patch applies such a prefix by default to the Normal master pages in Scribus, given these can't easily be renamed by the end user. I'm guessing this will impact translations though. | ||||
Tags | No tags attached. | ||||
Patch | Yes | ||||
|
normalmaster.patch (1,441 bytes)
diff --git a/scribus/commonstrings.cpp b/scribus/commonstrings.cpp index 66b725631..274cbafc3 100644 --- a/scribus/commonstrings.cpp +++ b/scribus/commonstrings.cpp @@ -356,13 +356,13 @@ void CommonStrings::languageChange() CommonStrings::trPageLocRight = tr( "Right Page", "Right page location" ); CommonStrings::masterPageNormal = "Normal"; - CommonStrings::trMasterPageNormal = tr( "Normal", "Default single master page" ); + CommonStrings::trMasterPageNormal = tr( "N - Normal", "Default single master page" ); CommonStrings::masterPageNormalLeft = "Normal Left"; - CommonStrings::trMasterPageNormalLeft = tr( "Normal Left", "Default left master page" ); + CommonStrings::trMasterPageNormalLeft = tr( "NL - Normal Left", "Default left master page" ); CommonStrings::masterPageNormalMiddle = "Normal Middle"; - CommonStrings::trMasterPageNormalMiddle = tr( "Normal Middle", "Default middle master page" ); + CommonStrings::trMasterPageNormalMiddle = tr( "NM - Normal Middle", "Default middle master page" ); CommonStrings::masterPageNormalRight = "Normal Right"; - CommonStrings::trMasterPageNormalRight = tr( "Normal Right", "Default right master page" ); + CommonStrings::trMasterPageNormalRight = tr( "NR - Normal Right", "Default right master page" ); CommonStrings::trPenStyle_SolidLine = tr("Solid Line"); CommonStrings::trPenStyle_DashedLine = tr("Dashed Line"); |
|
well, since you asked for feedback... i don't think that this patch is very useful. if the are only one set of left and right master pages, the left will be left and the right will be right (ok, as long as you don't delete single pages in a double sided page). in that case you won't even be really interested in this dialog. on the other side, for all user created master pages you would have the same issue as you have now (except if somebody copies your naming schema, which she can already do, without this patch...) but i also think that your patch might have paved the way for a more interesting approach: since the small pages cannot show much meaningful information in the name, we could just show the first letter of each word in the master page name. (instead of the first few letters in the name) that could be rather simple to implement. german people won't like that of course : - ) |
|
A language-independent solution is to use a color label... ...but it seems like a lot of work (0013297) |
|
I'm not sure those are strong points though. Just because it's easy to deduce which master page is applied to which actual page, isn't really a good reason for the UI to be unreadable. Changing the behavior to automatically show the first letter of each word, sounds nice at first, but what if some has master pages that abbreviate to the same letters? "My" approach (I didn't think of this myself, I saw it somewhere on YouTube, don't recall exactly where). Leaves control with the user, so if several master pages would abbreviate to the same letters, they can choose to abbreviate them L1 R1 L2 R2 etc, or whatever. Also by having the default master page naming like this, it signals to users, that it might be a good idea to name master pages in this fashion. The way it is now, it's not obvious this is a somewhat good idea to begin with. Same for colors, seems nice at first, but when you have a fair amount of master pages, easily distinguishable colors run out quickly. |
|
" Same for colors, seems nice at first, but when you have a fair amount of master pages, easily distinguishable colors run out quickly. " Master page worth be used when a template can be used on many pages of a document. Therefore, little is usually needed. The colors help identify incorrect master page assignments. It is a very effective help for documents with hundreds of pages. I like your idea, this is how I use Scribus by default (One character designation for master pages.) |
|
Another solution could be to automatically prefix master page names in the "Available Master Pages section" by a letter (A, B, C, D, ...) (or two in pathologic cases) and use that letter prefix in the "Document Pages" section. |
|
I don't see why that would be better. A semirandom letter does not make for a good reminder for that master page is assigned, as you'd still need to remember what letter presents what master page, which is sortof my point, let the user be in control. |
|
>> A semirandom letter does not make for a good reminder for that master page is assigned, as you'd still need to remember what letter presents what master page Not sure why it would be difficult to remember the letter used to represent a specific master page as it would be displayed next to master page name: A - Normal Left B - Normal Right C - My Other Master Page |
|
It totally depend on how many master pages anybody has, but in any case, why make it harder than it needs to be... "NL - Normal Left" is objectively easier/faster to remember than "A - Normal Left" "NR - Normal Right" is objectively easier/faster to remember than "B - Normal Right" The more master pages one has, the more cumbersome the alphabet scheme will become... So I really think my proposed solution is the optimal one ("least worst"), given the following advantages: - It's a trivial change, so few chances of regression - It's immediately applicable if we want it to be (i.e. ready before the next release) - It hints an easy to remember abbreviation scheme to the end user, but doesn't force anything for additional master pages (so effectively no change there) |
|
@pmjdebruijn, if it matters anything, i totally agree. |
|
>> why make it harder than it needs to be... Because if anyone adds another masterpage, the Document Pages labels are as broken as before. |
|
I think most users will pick up on the hint (some have already), and if they don't they will be no worse off than before. |
|
I still think my solution is the least worst, but even if it wasn't, it provides an immediate improvement, without any hard disadvantages compared to the current situation. So even if there are more ambition plans for the long term, wouldn't it still make sense to apply in the meanwhile? |
Date Modified | Username | Field | Change |
---|---|---|---|
2023-01-05 18:19 | pmjdebruijn | New Issue | |
2023-01-05 18:19 | pmjdebruijn | File Added: scribus_commonstrings_tr_normal.png | |
2023-01-05 18:19 | pmjdebruijn | File Added: normalmaster.patch | |
2023-01-17 20:37 | ale | Note Added: 0049944 | |
2023-01-18 04:51 | PeterBenedek | Relationship added | related to 0013297 |
2023-01-18 04:56 | PeterBenedek | Note Added: 0049945 | |
2023-01-18 17:27 | pmjdebruijn | Note Added: 0049948 | |
2023-01-18 18:22 | PeterBenedek | Note Added: 0049949 | |
2023-01-18 18:24 | PeterBenedek | Note Edited: 0049949 | |
2023-01-19 17:09 | jghali | Note Added: 0049952 | |
2023-01-19 18:19 | pmjdebruijn | Note Added: 0049953 | |
2023-01-19 23:05 | jghali | Note Added: 0049955 | |
2023-01-20 18:00 | pmjdebruijn | Note Added: 0049958 | |
2023-01-20 20:08 | PeterBenedek | Note Added: 0049959 | |
2023-01-20 21:00 | jghali | Note Added: 0049960 | |
2023-01-25 16:34 | pmjdebruijn | Note Added: 0049976 | |
2023-01-25 16:50 | pmjdebruijn | Note Added: 0049977 | |
2023-05-27 16:22 | cbradney | Target Version | => 1.7.0 |
2023-05-29 16:05 | nitramr | Assigned To | => nitramr |
2023-05-29 16:05 | nitramr | Status | new => assigned |
2024-10-23 18:37 | cbradney | Status | assigned => resolved |
2024-10-23 18:37 | cbradney | Resolution | open => fixed |
2024-10-23 18:37 | cbradney | Fixed in Version | => 1.7.0.svn |
2024-10-23 18:42 | cbradney | Status | resolved => closed |