GSoC 2012 Ideas: Difference between revisions

From Scribus Wiki
Jump to navigation Jump to search
Line 87: Line 87:
The second part would be to thoroughfully code and document the approved solution.
The second part would be to thoroughfully code and document the approved solution.


==== discussion =====
===== discussion =====


Scribus cannot handdle easily documents with 100 or 200 pages or more, specially when there are linked frames (and possibly when there are lots of images) : it becomes sluggish.  
Scribus cannot handdle easily documents with 100 or 200 pages or more, specially when there are linked frames (and possibly when there are lots of images) : it becomes sluggish.  

Revision as of 21:01, 25 March 2012

Minimum Requirements * C++ * Scribus uses the Qt toolkit, so knowledge of it would be of significant advantage, but could be learnt. STL is not used much. * Python if you want to do any major scripting work * Visit GSoC_2012_Student_Requirements for others * Further questions can be posed to the team, please review GSoC_2012_Contact_Information. List ideas for prospective Google Summer of Code 2012 projects here... scribus-dev mailling list

Project ideas

#1 - Improve usability and get rid of little bugs

Scribus is a great and powerfull DTP programm. Its main drawback is in its restricted userfriendliness. The aim of this project would be to improve general Scribus usability and userfriendliness by tackling many little possible improvements, improving curious behaviour or curing little bugs.

The bug tracker records enough such bugs and feature requests that AFAICT look easier to solve.

Here are some of these, in 2 groups : 1) general bugs and improvements, 2) undo bugs

general bugs and improvements

  • Improve search : option to extand the search scope to the whole document, 3-state style filters, ...
  • Add "vertical space before/after paragraph" input in the PP

undo bugs

  • last but not least, a specific time should be dedicated to improve undo, since undo is perfect for basic edit but still very hasardous for not so easy edits (see http://bugs.scribus.net/view.php?id=5745 metabug for a list of some undo related bugs)

Some of these might be more difficult than forthought : if you feel this is the case, please explain it, or take the request out of the list.

There are probably a lot more of these little bugs and probably easy new possible features : please add the one you know or think of, specifically when related to usability and user friendliness.

Some of these points relating with masterpage dialogs might be coordinated with the following GSOC project idea about "project management".

#2 - Scribus Project Manager

Scribus Project Manager will enable to manage multiple file parts of a single large book or set of documents, all sharing some common attributes : masterpages, styles,...

The GSOC Project aims to define and implement a basic project manager that would enable to

  • define the scope of a project (list of files)
  • define shared objects : mainly styles and masterpages
  • synchronise the files using the most recent version of shared files
  • print or generate updated PDFs for whole project
  • optionnaly if time left : synchronise page numbers, indexes and other datas accross files of the project

The first part of this GSOC project would be to define how the Sribus Project Manager will work precisely.

  • collect needs for a project mananegr amongst users
  • propose and discuss a synthesis
  • propose and discuss User Interface elements and technical solution

The second part would be to thoroughfully code and document the approved solution.

discussion

Scribus cannot handdle easily documents with 100 or 200 pages or more, specially when there are linked frames (and possibly when there are lots of images) : it becomes sluggish. However, as one can see on the success story pages [ http://wiki.scribus.net/canvas/Category:Success_Stories ] Scribus is largely used to edit such large books. So as to edit books or large documents, one has to make lots of 20 or 40 pages documents. These document share identical styles and masterpages. Identical, but stored in each different document, since there is no sharing. So as to change something in the styles or in the masterpage, one has to do it in EACH document part of the single big book or magazine. That is painfull since there is no way to manage the import of all styles or all masterpages at once.

The document manager would enable to do this automatically : easily update all documents parts of the project, each time it is required, when the style or masterpage change.

This would not only easyen the creation of large document, but also easyen the use of graphic chartas : having a set of independant documents sharing the same styles and masterdocuments, all requiring the same updates sometime.

#3 - Rendering and multithreading

Please check the discussion tab attached to this page for some ideas about this topic.

#4 - TBD

Retrieved from "https://wiki.scribus.net/wiki/index.php?title=GSoC_2012_Ideas&oldid=26855"