|
|
zoom_field_loses_focus.jpg (4,102 bytes) |
|
|
Unable to reproduce. |
|
|
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. |
|
|
... 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... |
|
|
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) |
|
|
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) |
|
|
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. |
- Anonymous
