View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0015518 | Scribus | User Interface | public | 2018-12-20 00:28 | 2019-01-07 17:35 |
| Reporter | christoph_s | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | new | Resolution | open | ||
| Platform | x86 64 | OS | Windows | OS Version | 10 |
| Product Version | 1.5.5.svn | ||||
| Summary | 0015518: Weird behaviour of moving/copying items to canvas with the right mouse button | ||||
| Description | I have attached a video that shows an unexpected behaviour regarding items moved to the empty canvas with the right mouse button pressed. If dragged too far to the right side, the item will be opened as a new doc. | ||||
| Tags | No tags attached. | ||||
| Patch | No | ||||
|
|
|
|
|
is the right click for moving / copying really useful? what's the use case? i've never heard of anybody doing that... the solution might be to remove the feature... (if we want copies while dragging, the inkscape way of doing is much better: normally drag your item and press space to create a copy... i don't think that scribus already has something similar, but i recall that it has been requested) |
|
|
"is the right click for moving / copying really useful?" Yes it is, and it has been a feature of Scribus for ages. Removing a feature just because ale doesn't use it or doesn't know anyone who's using it is unrelated to this bug report and generally not helpful. That doesn't mean the Inkscape way of copying items shouldn't be implemented as well, but that's an entirely different topic. |
|
|
no, the proposal for removing it, has nothing (or at least very little) to do with the fact that i use or not the feature. of course, the fact that i've never "seen" anybody using it is part of a mix of reasons. of course, there is no single reason, it's a mix that gives me that feeling: - i don't know of any software that has this feature (but there might be CAD or DTP programs that implement it... i don't know; inkscape, LO draw, krita and gimp don't) - it has a discoverability close to zero - i don't know of anybody that uses it or even knows that the feature exists - in my eyes it has a bad usability: - dragging with the right button pressed is something people are not really used to (at least it feels awkward to me... but i know that there are people doing it, like architects and 3D people...) - it does not integrate at all with the guides and the snapping. - you need to read three options and a further click to confirm what you wanted to do (ctrl-d and move feels imo "faster" and more straightforward) - it has bugs that have to be fixed, for very little use. - scribus has a huge and messy code base (every line of code that can be removed is a small improvement!) - as long as you don't suggest a use case, i don't see why this way of copying/moving is better than other (simpler) ways scribus already has. i know, you and other people have a hard time thinking about removing things from scribus. it's understandable. but if you read about what many power users (but also beginners) think, i'm not alone with the wish to remove features that are not cleanly implemented and are of little (to no) use: - they increase the UI clumsiness. - they are hard to explain to people who have issues with it. - one keeps on explaining how (not to) use them. - give a bad impression of scribus of course: - if scribus would have infinite programming resources, i would care a bit less about such issues. - if scribus already had a good UI, i would care less about the rotting bits. but it's not the case. it might be that i only know awkward people, but i really have the feeling that scribus has a very bad reputation. of course, they will not tell you, when you show up as the scribus marketing guy (nor tell me, after i have said that i've been working for the project for years). but i don't know of anybody who has used "good" tools before and loves the way scribus works. no, it's not all black or white. i'm really happy to see that so many people use (or know about) scribus... and that scribus exists. but i also have the sad feeling that most people use it despite the way it works and not because of it. yes, among other thins, i believe that the scribus project should learn to replace and deprecate features. of course, it's not about removing or keeping this single feature, it's more about a general trend. you might have the feeling that it's me myself and i, wanting to remove all the things i do not personally use . about making it a tool that is tailored to me. it's your right to think so. but, believe me, there are so many feature i never use in scribus and that i would never suggest they should be removed. it's really much more about making scribus a sound tool. over the years, we have lost OSP, we have lost OIF, we have lost louis, we have lost cezary, we have lost kunda, we have (mostly) lost vlada, we have lost garry, we have lost martin, we have mostly lost cédric... there is only one single active programmer left in the team. there might be reasons for asking for changes in the scribus project... all this having been said: there might be very valid use cases for the feature. i might just not know about them. and you failed at telling me what those use cases are. you preferred to get personal. it's your choice. |
|
|
ale, you have a history of demanding that features be removed from Scribus because you don't use them or see no use case for them. You even demanded the removal of features without a replacement, without considering the fact that this would lead to files created with older versions no longer being opened by new versions. That's what I was referring to, at least implicitly. Nothing personal at all. As for the rest of your rant, I suggest it'd be better placed on the Scribus or Scribus Development mailing lists, so they can be discussed openly, not hidden somewhere in the bugtracker. Then it would be easier to respond to each of your largely unfounded allegations in public. |
|
|
sorry, christoph, but i am not aware of having ever asked that a feature should be removed, just because i don't use it. i have also never willingly pushed for a change that would make old files unreadable. (i might not have known, that removing some feature would have consequences on the file format... but i really don't think that removing a feature can make files unreadable. some feature might disappear and scribus will have to do something with the "cruft" and reduce the user's lost to a minimum or to zero. some manual tweaking might be needed to get from the minimum to zero...) as for the rant, these topics have already been raised multiple times by several persons in multiple places. actions have sometimes been promised. most of the time there was no reaction at all. little to no change has came out of it. most of the time, the critical voices are silenced (unfounded allegations...), but the results are there for everybody to see: scribus is not a healthy project. my latest email to the mailing list raising some of the points above is just a few months old... and the reply was rather deceiving to me (basically: we like the way we are doing it, and there is no place for discussions). you're making vague statement about my intentions, you still haven't given valid reasons for the feature to be there, you dismiss other people's opinion as "unfounded" and you have an inclination towards attacking me. that was for me for today... |
|
|
Please don't argue with each other. Let me try and give you a neutral opinion, that might help you with your decision (or arguments) in going forward. First off: I didn't even know the feature existed, mainly because I use the keyboard for every copy and paste operation I do. That doesn't mean that there is no use case for it: Many users do not want to remember keyboard-shortcuts and they use the mouse explicitly. Those could still benefit from the implementation. Besides a similar feature works with files on windows, so the discovery rate isn't zero, but it is close to zero. Especially since it doesn't exist in other programs. In general, removing non-used features is not a bad thing though, as there are less lines of code that have to be maintained - but you do not know who uses this feature; Since the poster opened this bug ticket, they at least use it and thus it has the right to stay. Everything else you two have going on would best be done in private discussion and not on a bug tracker. Please, let's just try and make this software better, okay? |
|
|
no. it's not ok. but i'm not eager to continue the discussion. (and was not hot with the idea of starting it, believe me.) anyway, personally, i'm very fine with sticking to the core issue. is there a use case that makes it worth to fix (and keep) the feature? above you can find a few reasons why -- if there is none -- the team might consider removing the feature instead of fixing it. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2018-12-20 00:28 | christoph_s | New Issue | |
| 2018-12-20 00:28 | christoph_s | File Added: 2018-12-20_00-17-14.avi | |
| 2018-12-20 07:45 | ale | Note Added: 0045732 | |
| 2018-12-21 00:29 | christoph_s | Note Added: 0045736 | |
| 2018-12-21 10:05 | ale | Note Added: 0045737 | |
| 2018-12-21 10:07 | ale | Note Edited: 0045737 | |
| 2018-12-21 23:43 | christoph_s | Note Added: 0045738 | |
| 2019-01-04 09:31 | ale | Note Added: 0045749 | |
| 2019-01-04 14:16 | Luna Nightshade | Note Added: 0045750 | |
| 2019-01-07 17:35 | ale | Note Added: 0045751 |
