[scribus] ideas for the future (was: Jpeg Files and PNG files)

[Gregory Pittman]

On 07/30/2015 11:40 AM, a.l.e wrote:
> hi martin
>> But what would be stress to me, is when a beloved program is being
>> changed too often or "just for matters of purer IT-philosophy". Or in
>> other words: If possible, please leave us the useful and fine-working
>> bitmap exports.   :)
>>
> 
> no, it's not a matter of IT-philosophy.
> 
> well, when you build something, it's imo a good thing to have a good
> philosophy in mind.
> even multiple philosophies.
> and you should also be able to notice when it's time to make an
> exception to your philosophy.
> 
> but that's not the (main) issue here.
> 
> 
> the problem is that the huge code base is one of the reasons why we have
> a hard time finding new people who are willing to dive into the scribus
> code.
> myself included.
> and get them to write code for scribus.
> 
> many programmers have "left" the pool over the years. (very) few have
> joined after the first few years.
> (and it's nice to see that right now we have a few new candidates!)
> 
> 
> another problem -- this time on the user side -- is that there are so
> many options and commands available, that many people have a hard time
> finding the ones that are relevant to their workflow. and then
> understand how to use them.
> DTP is a complex task and there is so much involved that the UI won't
> ever be trivial.
> but we can try to avoid to reimplement mostly unused features, features
> that can already be found outside of scribus. so that people can focus
> on their work.
> 
> 
> the list of the bitmap file format scribus exports to -- as already
> written -- is mostly a marginal issue.
> really, i don't see it as as a big thing.
> 
> i simply would prefer to see scribus getting a bit (much!) slimmer. i'd
> like to see good tools raise around it. tools that could take some of
> the features out of scribus and make the overall user experience even
> better!
> tools like swatchbooker!
> tools that one can use also when not working directly with scribus.
> without having to learn everything again from scratch.
> 

Something I would like to see is an evolution of the documentation so
that we focus on workflows, emphasis on the plural. What we would need
is some feedback from various persons/groups who use Scribus on a
day-to-day basis, who can give new users some insights into more
efficient ways of learning and using Scribus.

You need multiple workflows because different sorts of projects, like
newsletters vs books vs webpages, need different approaches. You also
need different approaches because different people have different styles
of working.

I have doubts as to whether we need an update of the "official manual".
References like this are hard to digest, and the bigger they are, harder
to search for various small bits of info you need at the moment.

Greg