Hedley Finger wrote: > For example, you cannot copy from the layout and paste into the > Scrapbook but must right-drag. (When was the first Macintosh released?) > > I found this one odd myself. Normal left D&D would also make sense, but right-drag is a very unusual UI action.
Some of this stuff is a holdover from very early Scribus releases. The dev team *are* improving the UI, tidying up odditities, fixing up performance problems, etc. Given how few people work on Scribus, many with limited time, they're getting plenty done. However, there's a huge amount to do. Additionally, changing something in Scribus is often a lot harder than it looks, since some of the code is very tangled and arranged in strange ways. This means that a "simple" UI change can actually involve many changes across significant parts of the code, some of which can be hard to track down or can also affect other things. It can sometimes require significant internal restructuring or redesign to implement what looks like a small change in behaviour. Additionally, as Craig Bradney noted there are some changes that must wait for the qt4 transition to be practical. 1.3.5svn is using qt4 and fixes to make it more stable and better behaved are progressing, along with plenty of internal cleanup work to make future changes and fixes more practical. With luck, as the cleanup work progresses Scribus will become easier and quicker to improve and fix. The other thing that would be helpful is usability testing. It's all well and good to say "but product <x> does it like this" ... and to an extent that can be useful. If almost all other apps do it a certain way, Scribus probably should too unless there's a reason to do otherwise. However, sometimes it's not that clear, and there's no one common way to handle a task. In those cases, real usability testing - with different approaches tried out and the results observed - would be helpful in deciding what the best way to handle something is. > If you do something in a palette or dialogue which changes an object, > you would think that Ctrl-z would restore the previous state but more > often than not, the key event is not trapped by the palette/dialogue > with focus but goes through to the layout/canvas/window where it > undoes some OTHER state. > Undo support is incomplete, at least in 1.3.3.x . An action that isn't recorded as undoable may have no effect on the undo system, causing the previous undoable action to be undone when you wanted to undo some more recent action the undo system didn't record. I think there's been some work in 1.3.5svn on this, but I'm not sure what/how much. IIRC some improvements to undo were also waiting on other fixes and cleanups to the core Scribus code. > The serious point I am trying to make is that perhaps it is time for > a moratorium on feature building for a point release or two while > usability issues are addressed, especially implementing orthogonality > across objects and controls. > [Note: I've been inactive as a developer for a long while now, so I hardly speak for the team; then again, I'm not saying anything unusual.] That's where comprehensive UI review and usability testing (by people who have usability testing and UI design experience) would be helpful. If someone goes through the app and can say things like "task <x> is done this way in dialog <a>but this other way in dialog <b>" ... that's handy. If they can further say "<list of apps or platforms> do it this this way; <other list> do it this way. Our tests suggest that a random user sample with experience in none, either, or both platforms/apps find the first way easier to use on average" than that's even more handy. What doesn't help much is just saying "this UI element should work like this instead" or "<app x> does it this way, so Scribus should too". In other words, attention to detail, comprehensive coverage, and testing is needed to make truly useful decisions about UI issues. Even if the problem is pretty obvious, the right solution often isn't . Of course, just knowing what needs doing doesn't make it happen, and as I said earlier sometimes apparently simple changes are a lot harder and more time consuming than they look. As for a moratorium on features .... the 1.3.5svn branch is largely focused on cleanups, fixes, qt4 porting, and architectural improvemetns as it is. Have a look at the svn logs (you can get them using an svn client on anonsvn) and you'll get some idea of what's going on in development. There has been feature work but much of it is contributed by people who've become involved specifically to work on that feature, like the Google Summer of Code folks. Such fixes and cleanups are really slow and tiring work, and it's work that often feels unrewarding since it usually feels like there's just more of the same waiting for you. That's part of why I'm largely inactive in Scribus development these days - I find that I lack the patience and dedication to spend weeks struggling to understand, clean up, and document a large section of code in order to make it possible to make the changes I truly want to work on. I really enjoy cleanup and API design work at a certain scale, but find that often what's needed to work on Scribus exceeds that scale, with fixes on on one area demanding changes in another and so on throughout much of the application. So ... don't knock the efforts of the folks working on said cleanups and fixes (not that you were). It's seriously hard work, and the results they're producing are becoming pretty impressive when you compare the code of two years ago to the code today. Volunteers for that sort of work aren't thick on the ground, either. -- Craig Ringer
