Recent Posts

Pages: [1] 2 3 4 5 6 7 8 ... 10
User Interface / Re: The context menu
« Last post by a.l.e on March 22, 2017, 04:11:12 pm »
A complement to my question: What are you using the context menu for?

I use it:

- in Firefox for starting the inspector on a specific item (otherwise it's F12)
- in Irc to leave channels (right click on a specific channel and leave it)
- In Firefox / Libreoffice / Email to pick a spelling correction
- In Gimp to crop and resize images
- In Scribus for sending items to specific layers (I miss the action in Inkscape)
- In Scribus for fitting a frame to the image (but not the image to the frame)

Those are tasks that are highly related with a visual element I see on screen.

Personally, I'd wish that Scribus would have only few action in the context menu, mostly without sub menus.
Highly context sensitive.
Fast to trigger.

And use other means for making the available actions discoverable.
User Interface / Re: The context menu
« Last post by GarryP on March 22, 2017, 02:34:17 pm »
If we think about what the context menu is called then there is the argument that its contents should relate to the object that has been right-clicked. In other words, the context menu should - using this argument - only hold actions that are relevant within the "context" of that object. To say it a bit differently, the context menu should only show actions that can be applied to the object that is selected.

For instance, if you right-click on an image frame then - using the above argument - there should only be actions in the context menu that can be applied to an image frame. That's a pretty reasonable argument but there's a slight problem: What about actions that are relevant to the context but are currently either not available or not applicable?

To expand the above scenario, if you right-click on an image frame you get a list of actions that relate to that frame - all well and good so far - but you may also get some actions that are not actually applicable. For instance, there's currently an action for "Adjust Image to Frame". This action is always available, even if the action has just been applied and the image already fits the frame. Using the argument above, this action should not be available as there is no reason to fit the image to the frame again; it's a pointless action - at this moment - because it has no effect. (The same goes for "Level -> Raise" when the object is at the top of the stack. etc.)

So now we have the question of what to do with this action. Should it be greyed out - to show the user that it might become available in the future - or should it not appear in the menu until it can be applied?

There is an argument that the action should not appear because it can't be applied and having it there takes up valuable space forcing the user to mouse over it to get to other actions. There is also the counter-argument that the action should appear - but be greyed out - so that the user knows that it's a possible action but it's just not available at the moment.

The discussion about which argument is correct has gone on for decades and will probably never conclude satisfactorily to both sides but it leads me to the next point: You either clamp down on the available actions and only show those that can be applied at the moment in time the user right-clicks, or you show more actions than those which are applicable. If you show more, then how many more do you show? Who decides which are to be shown and how far do you go?

As has already been mentioned, some applications - like GIMP - offer the user all possible actions but some are greyed out and unavailable. This means that you have a very large context menu with a lot of potential actions which the user can browse through to see if they can find one they want to use. This can be very useful to casual users where they know they did something a while back that performed the action they wanted but they can't quite remember what it was called. On the other hand, it can mean that the user is shown a multitude of choices, some of which are not available and they don't know how to make them available, and that can be frustrating.

Personally, I think that the main menu should offer every possible action - with some greyed out if they are not currently available - and the context menu should only offer those actions that can be currently applied within the context of the object that has been right-clicked. (By way of example, Scribus already does this by not showing the "Adjust Image to Frame" action if an image frame has no image.) I think this is a reasonable compromise between the two arguments. People who want to see every possible action - even if they can't actually preform them at the time - can see them through the main menu and people who only want to see the actions they can currently perform can use the context menu.

To expand on that a little: There also should be no action available via the context menu that isn't also available via the main menu. To rephrase that, there should be no actions that are "hidden" in the contextual menu. There are some people who don't use the contextual menus. There could be many reasons for this: they are using a pointing device that only has one button; they have limited physical ability and cannot use more than one button; etc. These people should not be given a worse experience of using the software because they cannot access part of it.

Then there is then the argument between having a "long" context menu and having a hierarchical context menu. Again, the arguments about this have been going on for decades and there is no "correct" answer. Some people like to have everything available on the first level of the menu while others prefer a shorter menu with sub-levels. I have used some applications where a long single-level menu is good and I have used some applications where a multi-level menu is good. It really depends on the application.

I think Scribus 1.4.6 has a decent compromise between the two. For instance, I like to be able to get to "Adjust Image to Frame" straight from the root level of the menu rather than having to go through something like "Image -> Adjustments -> Adjust Image to Frame". Conversely, I prefer to use "Level -> Raise" rather than having the Raise, Lower, Raise to Top and Lower to Bottom actions all in the root level. And when you consider the "Send To Layer" actions that makes even more sense.

As for which actions should be in the context menu and where they should be in it, I don't think anyone is going to agree with anyone else on everything. For me, having "Info" as the first action isn't very useful. I hardly ever use that function and having to mouse over it every time makes the menu feel awkward. The same goes for the Undo function (I generally use CTRL+Z). I also use "Send to Layer" much more often than I use "Edit Image" or "Attributes". But that's just me, other people might use Scribus differently. I don't think there will be consensus on this.

In summary then, I think that:
* The main menu should show all possible actions - even if they're not currently available.
* The context menu should only show actions that are applicable to the object currently selected.
* The context menu should present a compromise between a single-level list and a hierarchical list.

I realise that this doesn't answer a lot of questions but I hope I've been able to explain some reasoning in a decent way that helps the discussion move forward.
Text and Typography / Re: Importing .docx or .pages files in Scribus 1.4.6?
« Last post by utnik on March 22, 2017, 07:11:22 am »
hi john

yes, that's different from the file you uploaded before:
  • now there are four master pages – but of course not two of them applied to the same document page, as this is not possible… (three of them are used in the document, 'normal right' is unused so far.)
  • and there are two sections
Your assumptions from the beginning that those originals had only the margin-defined text box set up at that point

no, these boxes aren't on any master page. when creating a new document, you can tell scribus to apply a chain of linked margin sized text boxes across all pages of the document – independent of the master pages. that's where they went from.

…also note the pagination reverses itself, left odd right even…

again, it's not something scribus does wrong.
you should be more careful when experimenting with functions which are new for you!
in the 'sections' tab of 'document setup' you told scribus to start the numbering in the first section (pages 1-9) with '0' – so scribus does it's job well and marks page 1 as '0', page 2 as '1', page 3 as '2', and so on.
as all the left pages in this section and te first page are based on 'normal left', they don't show any page numbers.
but all the right pages aof the whole document (except the first one) are based on 'number right' and show page numbers based on the counting and formatting scheme you defined in the 'sections' tab.

Text and Typography / Re: Importing .docx or .pages files in Scribus 1.4.6?
« Last post by JohnJR on March 22, 2017, 01:37:28 am »
Hi Utnik,

I checked here and there should be four Master Pages.  The default Normal Left and Right Master Pages I originally used to construct the entire book.  Your assumptions from the beginning that those originals had only the margin-defined text box set up at that point, while I added the header and page number text boxes to those two in Document Set Up later.  When I applied those two Master Pages, only the margin-defined text box would activate, the two header boxes remained mute, just grey outlines.

That is when I thought I was doing the right thing by creating two new Master Pages via Edit > Master Pages.  These two new Master Pages are named "Numbers Left" and "Numbers Right" and are listed as such at my end.  The two new Master Pages were created from the original Normal Left and Right by applying text frames to the two header boxes greyed out on those and adding repetitive text and pagination place holders two those header text boxes.

In that sense maybe they are not stand alone Master Pages in their own right but somehow only derivatives of the two originals.  Could that be why they might not show as Master Pages in there own right--named as such?  And perhaps acting now like such renegades?

After all, I applied these two "Numbers" Pages By defining pagination for them and then what I thought was correct; applying them over the original Pages for the specified pagination and it worked.  I thought the manuscript was done, saved.  But opening it up, originally had only the two pages at the end that just needed deleting.  (Thanks for the tip: Pages > Delete I was highlighting the pages and trying to use my delete-key.  There was na-da I could find in help forums about that simple sequence.)

Upon opening the file for the second time, that is when the rogue new "Numbers" Masters Pages populated themselves where they were never applied to: document pages 3-9 (title page through first chapter page, also note the pagination reverses itself, left odd right even while the text remains correct) with page numbers commencing with 2 and going thru 8.  Beginning with document page 10 (numbered as 2) both header text boxes are applied correctly as specified to document page 48 (page number 40).  As I said, Page > Apply and re-applying the Numbers Pages does nothing to eliminate the initial header wackiness up to document page page 9.

I've saved, closed, and reopened the file enough be fairly confident that the document seems fairly stable and in case something has changed I'm attaching a new zip file again.


User Interface / Re: The context menu
« Last post by tim_occ on March 21, 2017, 08:21:50 pm »

In a classic menu bar you have actions sorted by topics, like Edit, Item, Page, etc.
In a context menu you have actions sorted by item.

I like context menues that give me an idea what I can do with the object. But at these point it should be focus on often used things. A second level is ok to group some actions into one topic. What I don't like is an overloaded one-level-menu which is like a wall of text.

I use context menues for two reasons:
1. to see what I can do
2. as a cheat sheet for action shortcuts

User Interface / Re: The context menu
« Last post by utnik on March 21, 2017, 07:09:52 pm »
hi ale

good question!

i like to see all the available actions in the current context in the CM.
for this it needs a good tree structure.

for speed i prefere keyboard shortcuts. (the context menu is for actions i don't need as often as i would remember the shortcut – so ultimate speed is secondary, but more keyboard shortcuts are needed…)

User Interface / Re: The context menu
« Last post by CGood on March 21, 2017, 06:16:06 pm »
My immediate responses. I'd like context menus to show a very large proportion of all relevant actions.

I prefer a context menu like in 1.5.1 where there is a tree structure. I think the context menu design in 1.5.1 is better than 1.4.6 for example.

Adding hyperlink to a text via an item or tree branch of items in the context menu seems sensible.

I would add that I'd also like to see more actions accessible via keyboard shortcuts. I suspect that is a topic for a different thread but speed of access to actions is connected to this thread.
User Interface / The context menu
« Last post by a.l.e on March 21, 2017, 05:56:21 pm »
What is the role of the context menu in Scribus?

- Show the most relevant actions in the current context?
- Show all the available actions in the current context?
- Show all the possible actions? (Gimp is doing that)

Once this question is answered, how fast should the context menu be?

- Should it have only (mostly) one level for fast triggering?
- Should it have good tree structure? (like now)

Anybody wants to propose a cocept that could be discussed with the team?
(currently, it seems that anybody can wish something and it will be added...)
(the idea to discuss this came from the discussion on the hyperlinks... where somebody proposed to add them to the context menu...)
Beginner Talk / Re: Backgrounds of transparent images suddenly showing up as white
« Last post by Mapsking on March 21, 2017, 03:04:59 pm »
I've been (an still am) using PDF 1.5, and up until recently, the print preview did not show white backgrounds in Scribus, but now they do.  I'm printing on my HP Laserjet M521nw printer, not sending to a commercial printer, and I export to a .pdf, and use Foxit Reader.  Is that a "good" .pdf program to use?  I wanted to try printing directly from Scribus instead of a .pdf, as it is a three face brochure I've made, and the margins are printing at inconsistent distances from the left to right margin, and I wanted to test to see if it was coming from the /pdf reader, but I think maybe it was because I had two sided printing turned on.
Beginner Talk / Re: Backgrounds of transparent images suddenly showing up as white
« Last post by a.l.e on March 21, 2017, 11:16:38 am »
ah, don't print from scribus, create a pdf and use a (good) pdf reader for printing the pdf.
Pages: [1] 2 3 4 5 6 7 8 ... 10