Author Topic: Window/Panel Priority  (Read 2466 times)

mnawij

  • Sr. Member
  • ****
  • Posts: 254
  • Karma: 2
  • Scribus User
Window/Panel Priority
« on: January 30, 2014, 01:14:21 am »
I have an element selected (text frame).  I then click on the text panel within [properties].  I wish for the priority to stay with the selected element and not with the panel.  Example: I select a text frame, then I put the cursor into the letting box within the panel.  I make the change with my mouse to the dialog in the panel, but I wish to be able to move the text frame with the arrow keys to align my new changes to the copy with a {fpo} on a layer underneath.  I need the text panel to be active with the mouse and the frame available to move with the arrow keys to align the {fpo}, instead of only one being active at a time.  The will greatly speed up my creating artwork by at least 10+%.  Is this possible?

fyi: {fpo} = for position only, a template.

Thanks.

GarryP

  • Hero Member
  • *****
  • Posts: 1600
  • Karma: 25
  • Scribus User
Re: Window/Panel Priority
« Reply #1 on: January 30, 2014, 04:58:31 pm »
mnawij, if I understand you correctly, I think this would only be possible by overriding the default UI behaviour of certain input fields.

For example, the cursor keys have a default behaviour within input fields - move the caret left or right, increment/decrement a spinner, etc. - so, if this was overridden in order to control the position of a frame, you would have to always use the mouse to position the cursor within that input field or change its value.

I can see where it could speed up some workflows but I've a feeling that most people would prefer the input fields to act the same way throughout the software rather than doing things differently in different circumstances.

And you can't have a key having two behaviours at once without it getting very confusing.

It may well be possible to do what you want and many other people might want the same thing, or I could have just got the wrong end of the stick altogether and you were asking for something entirely different, but personally I can't see it being something that would be entertained by the developers or the Scribus users.

Apologies if I've misunderstood your idea in any way.

GarryP

  • Hero Member
  • *****
  • Posts: 1600
  • Karma: 25
  • Scribus User
Re: Window/Panel Priority
« Reply #2 on: January 30, 2014, 05:08:42 pm »
Sorry, I've just realised that what I said above doesn't apply to other UI elements - such as buttons, sliders, etc. - but it would still require the focus to be put back to the canvas window, which I'm assuming is where the cursor keys are "trapped" to provide the nudging function.

And doing so would stop users from using Tab/Shift-Tab to move between UI elements in the panel. And some people might use this more often as it's standard practice.

I hope I've explained this properly, it's been a while since I've done any UI programming and my memory is a bit fuzzy.

mnawij

  • Sr. Member
  • ****
  • Posts: 254
  • Karma: 2
  • Scribus User
Re: Window/Panel Priority
« Reply #3 on: January 31, 2014, 07:47:16 am »
Yes GarryP you have the gist of it...  I would like to see a preference option added to turn this on or off... do not know if this is possible.  My workflow might not be that of others, maybe a poll sometime on the issue.

mnawij

GarryP

  • Hero Member
  • *****
  • Posts: 1600
  • Karma: 25
  • Scribus User
Re: Window/Panel Priority
« Reply #4 on: January 31, 2014, 03:07:17 pm »
Ah, good, I'm glad I didn't go off on a tangent too much there.

I can see that some kind of "[] Nudge keys override normal UI behaviour" check box might be possible - or something similar with related functionality - but, looking at the list of outstanding issues the developers are already working on, I really can't see it being a priority.

When there's so much new stuff being developed and so many other issues to fix I'd say that the developers already have too much to do.

I've a feeling that such functionality would have to override the standard UI behaviour in so many places that it would be very difficult/laborious to code and test, for very little return.

I don't mean to belittle your request - it's perfectly valid - but the developers have to weigh up how much time and effort would be used implementing, testing and maintaining something against how much effort it saves. And, if you think about it, saving a couple of mouse clicks every now and again - on a total global use of Scribus overall level - versus making sizeable changes to the way the software works on a basic level doesn't really weigh up.

By all means raise a poll if you want to. All I'm saying is that I can't really see anyone doing anything about it any time soon.

But, I'm not a Scribus developer and I've been wrong before so what do I know?!

Anyway, that's probably enough prattling by me on the matter. If you decide to take this potential feature request further I'll wish you good luck on your journey.

P.S. To formally request a feature see the advice(?) I gave you on your other recent topic.

 

palmate