Best forum

[BN_Dev]

Hi all,

This forum doesn't seem overly active with regards to development chat.  The Wiki is also a little out of date with regards to the articles on getting involved with development hence me asking.

Is this still the best place to discuss code changes? We found an old mailing list which is deactivated and points to the forum. I have registered at the issue tracker and I'm aware there is an IRC channel too.

I note the development model is a bit more closed compared to most projects on GitHub, with the development happening on SVN.  The issue tracker on GitHub is also quite quiet and not all patches there get merged in.  I understand submitting .patch files against the SVN is the preferred option for the core developers.

I would like to discuss some ideas and get feedback on proposed changes before working on any patches, to ensure that the work matches the development roadplan and would not be wasted.  Which is the best place to thrash out these sorts of ideas and get feedback before doing any work?

Many thanks,
Paul

[a.l.e]

Yes, this is probably the best place for starting discussions on the Scribus development.

As a side note, you're welcome to use Git instead of SVN... there are even community maintenance mirrors on Gitlab and Github...

But, indeed, at the end you are supposed to propose the patches as attachments in the Scribus own bug tracker.

P.s.: there is a bit of dev discussions in the bug tracker,  but ideas are probably better discussed in here....

[BN_Dev]

Thanks a.l.e,

Git workflows have been the de facto for my career for a while, but I accept the core devs have their own preference. I'd like to be involved so I'm more than happy to put in the effort to work directly with what the project uses to reduce friction for patches to be contributed. Besides, working with svn might be a fun change.

I'm currently heading a project in a publishing company that acquired a large regional newspaper with an existing production workflow based on QuarkXPress + Adobe CC.  There's a plan to enable more editors to perform layout tasks and to introduce some automation for various things (such as announcements, events, sports results, etc.) We've evaluated Quark's CopyDesk (CD) and Publishing Platform (QPP NextGen) and although they capable of doing what's needed, our company culture is open-source first.

To evaluate Scribus we've been recreating a previous issue in it to compare the output (and the process) to see if it's production ready for our use cases; and so far the results are very promising.  There are a few rough edges and we're currently sifting through these to see if it's a lack of knowledge on our part (we need more learning/training), or there are bugs which we can report, or there are missing required features (that are available in QXP), and if it can support our future requirements (match some features in CD/QPP NG).

Over the course of the next week I'll open separate threads for each feature to keep the discussion focused to that particular feature.  I'll also try submitting some basic patches to see how well I do with svn and how smooth the process is.

My hope is if the features are possible and the patches are accepted, and the cost to sponsor the development is comparable to the cost of QXP/CS/QPP NG, then it would be a no-brainer for us to switch production to being fully open-source.  I'm encouraged one of the roadmap wiki pages has some things on similar to what we need so hopefully the discussions will be fruitful.

Many thanks,
Paul

[Nermander]

If you can "sponsor" with developer time to develop the code this is probably the best way. It has been discussed many times before that the main problem with the development is time, not money. And also donating money causes issues when it comes to taxes etc.

But there are features in Scribus that were developed as Google Summer of Code projects and and think a lot of the support for complex script was developed with support from the government in a country who wanted good open source support for their language (it might have been Tamil, but I am not 100%).

So contributing with code is the best way to help.

[MrB]

This forum plus the bug tracker, along with IRC for live chat, are the best methods to discuss development.

[MrB]

My hope is if the features are possible and the patches are accepted, and the cost to sponsor the development is comparable to the cost of QXP/CS/QPP NG, then it would be a no-brainer for us to switch production to being fully open-source.  I'm encouraged one of the roadmap wiki pages has some things on similar to what we need so hopefully the discussions will be fruitful.

Hi Paul

We'd be more than happy to review proposals and code for inclusion.
As you've identified, quite a portion of the wiki needs updating but we can provide direct responses to questions.
Note 1.6.x is our stable branch. 1.7.x is our development series where most development occurs - significant changes to the UI, table of contents and index generation are there.

Scribus is used in some newspapers and magazines, with some good examples from India in particular. Some examples come up on this Facebook page at times: https://www.facebook.com/groups/scribus/

thanks
Craig

[BN_Dev]

If you can "sponsor" with developer time to develop the code this is probably the best way.

Thanks for your comments. To clarify, yes the "cost" would be for my development time to work on the features and make them available in the project. I'm an experienced Qt developer.

This forum plus the bug tracker, along with IRC for live chat, are the best methods to discuss development.

Thank you. I'll jump on IRC when starting any actual development but will put proposals for discussion in the forum first.

We'd be more than happy to review proposals and code for inclusion.
As you've identified, quite a portion of the wiki needs updating but we can provide direct responses to questions.
Note 1.6.x is our stable branch. 1.7.x is our development series where most development occurs - significant changes to the UI, table of contents and index generation are there.

Thanks for the links, we'll check them out. I have 1.7 from svn compiling and running. I used to use svn ages ago and it's come back to me surprisingly quickly! With regards to the development, I would generally hope to update any associated documentation as I go. There were a few old roadmaps I found on the Wiki and some of the ideas aren't too far off what we want to achieve. Hopefully some good proposals can cover our use case and easily fit with other use cases too for maximum value to the work.

Scribus seems like a great community to be involved in too, thanks for everyone's pointers 

[a.l.e]

Nice to read your thoughts.

The only thing I can contribute for now: I'm not sure if it's worth to get into SVN, if you don't know it yet.

You won't interact with the Scribus' own SVN server, except for pulling updates that have been merged into the official code.
If you're proficient with Git, stick with it and focus on working on the features you need.

At the end of the day, the only way for you to propose patches will be through attachements in the bug tracker and, for that purpose, it does not matter if you got the code (and manage it) with SVN or Git.

And, currently, most people (if not everyone) proposing patches to the team is using Git: the "mixed" workflow is well  tested : - )

[tim_occ]

@BN_Dev, very nice to see more support in code development.

Currently, I'm focusing on general UI improvements for 1.7.0.
Regularly I publish the latest development state on Codeberg (it's based on Git) and try to keep it in sync with the latest SVN changes. https://codeberg.org/Scribus/scribus
You can also check it out if you want to see the latest UI changes, but keep in mind that it's not the official codebase, not maintained by the Scribus lead dev team (only by me ). It contains more or less experimental changes that lead to some patches that I post in the bugtracker.

If you prefer a git based workflow, I can grant you access to the project. But, as ale said, you have to submit your changes as a patch file via the Scribus bugtracker.


Thanks
Martin

[BN_Dev]

Thanks @all, it's been nice to start getting involved and the community is very friendly. I used to use svn before git; I was worried I forgot everything but it all came back to me quickly and I'm happy to use it until/if the project officially switches.  I found the process to start submitting patches was easy, plus KDevelop has made it super fast to jump straight in although I mostly live in the terminal.

I finally have a list but it took a small while longer than I thought to collate feedback related to my post above:

Over the course of the next week I'll open separate threads for each feature to keep the discussion focused to that particular feature.

I'm going to start typing them out now and I'll put an index post after this one with links directly to them.  Our ultimate hope is to switch from QuarkXPress to Scribus for an existing production workflow without any downtime.  In order for us to do this we have classified features as essential/desired/future.  For essential features we intend to be present and actively work on these and contribute to them in a way that supports our goals whilst also being useful for other users and improving the software overall.  If we can meet all our essential needs we will certainly switch to Scribus.

Functionality considered desired are things we can work towards without time constraints and it doesn't matter if they aren't all possible as any pain points are likely to be less than what we currently have with QXP.  Functionality considered future is long-term roadmap stuff and we will be happy to continue to commit resources to ensuring Scribus stays on-par with QXP/ID and their offerings.

Our hope is that by working with an open-source project to recreate the features we need in production we can offer a migration path for other publications off proprietary layout software too.  As a background project we have also considered documenting how we intend to achieve the QXP>Scribus migration plus the actual migration itself (if it becomes possible) to offer a blueprint for others.

At the very core of a lot of consideration for Scribus is the open XML file format; which is far more accessible than Quark's .QXP format.  Some of the features we need could be implemented with external tooling to modify tags if all else fails; but we feel this is too hacky and we would rather have actual native UI support that all users can benefit from on all platforms without external tooling.

Many thanks,
Paul