View Issue Details

IDProjectCategoryView StatusLast Update
0016016ScribusUsabilitypublic2019-12-18 10:24
ReporterPeterBenedek Assigned To 
PrioritynoneSeverityminorReproducibilityalways
Status newResolutionopen 
Platformx64OSLinux MintOS Version19 (64bit)
Product Version1.5.6.svn 
Summary0016016: Current zoom level field loses the focus, after you manually enter a value and pressed the enter button
Description-- You write a value in the curret zoom field and press enter button
Scribus settings the page zoom
-- Try modified the value of field and press enter button
Oops...
The value is highlighted but cannot be changed, field lost it the focus.
TagsNo tags attached.
PatchNo

Activities

PeterBenedek

2019-12-17 14:52

developer  

zoom_field_loses_focus.jpg (4,102 bytes)   
zoom_field_loses_focus.jpg (4,102 bytes)   

jghali

2019-12-17 17:46

administrator   ~0047289

Unable to reproduce.

PeterBenedek

2019-12-17 18:45

developer   ~0047290

Sorry, I try again step by step...

-- Click on the zoom field
-- Change value for 50% (or any) and press enter button
Result: Scribus settings the page zoom. That's okay
-- Do not click again on the field, only write: 40 % (or any)
 The value is highlighted but cannot be changed, because field lost it the focus.

Isn't reproducible in this case?

If I want to change one after another it several times the zoom, always I have to click in the zoom field.

ale

2019-12-18 09:06

manager   ~0047293

... this is one of the things i don't like in scribus: there are at least eight ways to change the zoom level and none of them works really well.

but asking to remove things will hurt the "we don't remove anything" wall.

- we don't have the manpower for maintaining all the different ways of doing each thing,
- the complexity in the code, makes the onboarding of new contributors harder (even for simple tasks!)

in the case of the zoom i would really like to have

- a fast (shortcuts based) workflow (probably mousewheel and +/-/1,0 based)
- a slow (dialog based) workflow (with a new non modal and dockable dialog that can be called directly from the view menu, not from a sub menu)

of course, it's nice to see the zoom level in the toolbar, but, what i really care about is: do i see the details or overview i need.

 and:

- i want to a fast keyboard based way to switch among overviews / details and
- a discoverable, comfortable but slow way for those who do not need speed.

two ways, not eight!

personally, i would welcome it, if scribus could lose some flexibility and -- as a counterpart we could get carefully shaped tools; with one version for the beginners and one for the "pros".

it is possible that some people will not like the way scribus does it, but , at least, the people who like it and actually are using scribus will get tools that are powerful and comfortable to use.

not half baked solution that try to please everyone but mostly fail in the small but important details.

yes, i'm really convinced that if the zoom tool and the zoom widget in the status bar would disappear tomorrow, the users will not lose any real feature (of course, some people would need to change the way theur workflow).
adding a dockable zoom palette would probably empower those users that formerly were using the zoom in the status bar.

personally, i would love a status bar that looks like this:



                                                                                                                            � 100% � 1 ≣ Background ⌖ -47.150, 142.567 mm � ▮▮▮▮▯▯▯▯▯▯

- all right aligned (more place for tips and feebdack on the left)
- the icons would open a non modal dockable palette (zoom, page navigation / creation, layers, units picker)
- except the eye icon which would enable disable a new preview mode that allows editing
- all the values would be read only.
- the progress bar should be removed when no status is being displayed.
- i'm not sure that the mouse coordinates belong down there (i do use them, but every time i do so, it feels so painful...)

this proposal would probably be rather easy to program and this bug would "automagically" be solved ��.
forever.
</rant>

getting back on topic: i can replicate the bug...

ale

2019-12-18 09:08

manager   ~0047294

ok, this version of mantis does not like unicode (or emojis) ... here is a screenshot or my carefully shaped artwork...
statusbar.png (12,865 bytes)   
statusbar.png (12,865 bytes)   

PeterBenedek

2019-12-18 09:57

developer   ~0047295

I checked in Xnview same function and this behaves exemplarily.

What I did:
-- Click on zoom box and select the contetnt
-- Change the value
-- Press enter button
Application sets the zoom value, the zoom box will remain active and accept the new value.
-- Press up/down arrow button
Application sets the zoom value, the zoom box will remain active and accept the new value.

This is great.
Xnview_zoom_field.gif (809,596 bytes)   
Xnview_zoom_field.gif (809,596 bytes)   

ale

2019-12-18 10:24

manager   ~0047296

peter, can you ask some xnview programmer to fix this bug in scribus?

no?

that's the problem i was talking about: we don't have the manpower to maintain 8+ ways of setting the zoom.
and each minute we spend on fixing such a bug cannot be used for more important things.
just commenting / reading this is stealing developers time.
i should just shut up.

and, really, scribus offers better ways of zooming than the spinbox in the status bar. fortunately!
(and, no, a feature that is sane in a picture preview application must not be the best way of doing in a DTP program. it can be. but it most not.)

i stick to my point of view: scribus should learn to do things well. and if we cannot do it well in 8 ways, then we should reduce the number of ways we can do it. and improve (to perfection) the remaining few ways. even if some people lose their preferred way of doing. but they get well behaving tools!

jean will probably fix this bug. i'm pretty sure. and what i wrote above makes it even more likely.
but i would prefer that he would put his time into making the character format at the cursor predictable (and sane!) for everybody.
or finally review and accept that damned xyz panel we have been refining for a full week.

Issue History

Date Modified Username Field Change
2019-12-17 14:52 PeterBenedek New Issue
2019-12-17 14:52 PeterBenedek File Added: zoom_field_loses_focus.jpg
2019-12-17 14:54 PeterBenedek Description Updated
2019-12-17 17:46 jghali Note Added: 0047289
2019-12-17 18:45 PeterBenedek Note Added: 0047290
2019-12-18 09:06 ale Note Added: 0047293
2019-12-18 09:08 ale File Added: statusbar.png
2019-12-18 09:08 ale Note Added: 0047294
2019-12-18 09:57 PeterBenedek File Added: Xnview_zoom_field.gif
2019-12-18 09:57 PeterBenedek Note Added: 0047295
2019-12-18 10:24 ale Note Added: 0047296