GSoC 2012 Ideas: Difference between revisions

From Scribus Wiki
Jump to navigation Jump to search
m (Protected "GSoC 2012 Ideas" ([edit=sysop] (indefinite) [move=sysop] (indefinite)))
 
(2 intermediate revisions by 2 users not shown)
Line 1: Line 1:
[[Category:GSOC]][[Category:GSOC 2012]][[Category:EN]]
[[Category:GSOC 2012]][[Category:EN]]
'''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...'''  [http://lists.scribus.info/mailman/listinfo/scribus-dev scribus-dev mailling list]   
'''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...'''  [http://lists.scribus.info/mailman/listinfo/scribus-dev scribus-dev mailling list]   


Line 115: Line 115:
The idea is to fill the cache by worker threads and let the render thread use a dummy or previous version as long as the results aren't ready:
The idea is to fill the cache by worker threads and let the render thread use a dummy or previous version as long as the results aren't ready:


<avox_> Scribus uses ScImage to store images
<avox_> (explains) Scribus uses class ScImage to store images
 
<avox_> those need to be scaled and color corrected before display
<avox_> those need to be scaled and color corrected before display
<avox_> also sometimes there are image effects active  
<avox_> also sometimes there are image effects active  
<avox_> In documents with lots of images, that really slows Scribus down, especially because hires images have to be loaded from disk to memory
<avox_> In documents with lots of images, that really slows Scribus down, especially because hires images have to be loaded from disk to memory
<avox_> The patch stores the result of scaling + color correction on disk, so Scribus only has toload the smaller PNGs and display them directly
<avox_> The patch stores the result of scaling + color correction on disk, so Scribus only has toload the smaller PNGs and display them directly
<avox_> look at the times which show the speedup when opening a document for the second time
<avox_> look at the times which show the speedup when opening a document for the second time
<avox_> of course the times for the first time are still long. So the idea is to use a dummy image as preview if there's no preview in the cache yet and calculate the preview with a worker thread
<avox_> of course the times for the first time are still long. So the idea is to use a dummy image as preview if there's no preview in the cache yet and calculate the preview with a worker thread
<avox_> then, when the preview is ready, signal Scribus to redraw the screen and display the final preview
<avox_> then, when the preview is ready, signal Scribus to redraw the screen and display the final preview
<janardhan> can we use any dummy image
<janardhan> can we use any dummy image
<avox_> my idea is to use a clock or something, so that the user knows the images is still being calculated
<avox_> my idea is to use a clock or something, so that the user knows the images is still being calculated
<janardhan> so we should do scaling and color correction in separate thread
<janardhan> so we should do scaling and color correction in separate thread
...
...
<janardhan> if there are some common resources, then we have to use mutexex and parlled processing may not yield desired results
<janardhan> if there are some common resources, then we have to use mutexex and parlled processing may not yield desired results
<avox_> it's all read access, so simultanous use should be no problem
<avox_> it's all read access, so simultanous use should be no problem
<avox_> synchronization is only necessary for storing/reading previews from the cache and for signaling a rewrite (I think Qt has a special function to send a message to the rendering thread. or QWidget.update() can be used from any thread anyway, will need to look up the docs)
<avox_> synchronization is only necessary for storing/reading previews from the cache and for signaling a rewrite (I think Qt has a special function to send a message to the rendering thread. or QWidget.update() can be used from any thread anyway, will need to look up the docs)


Line 149: Line 163:
* xmlIn() should be implemented as a recursive descent parser [ http://en.wikipedia.org/wiki/Recursive_descent_parser ]. This type of parser is usually fast, robust and modular.
* xmlIn() should be implemented as a recursive descent parser [ http://en.wikipedia.org/wiki/Recursive_descent_parser ]. This type of parser is usually fast, robust and modular.
* Use of QAbstractXmlReceiver in xmlOut() will allow filtering the output with XQuery [ http://doc.qt.nokia.com/4.7/qxmlquery.html ] which could be used to convert to older fileformats. For this project using QXmlSerializer (a subclass of QAbstractXmlReceiver) will be enough.
* Use of QAbstractXmlReceiver in xmlOut() will allow filtering the output with XQuery [ http://doc.qt.nokia.com/4.7/qxmlquery.html ] which could be used to convert to older fileformats. For this project using QXmlSerializer (a subclass of QAbstractXmlReceiver) will be enough.
==#5 - TBD ==

Latest revision as of 20:18, 20 April 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) undo bugs 2) general bugs and improvements

Undo bugs

  • 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)

General little 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" style input in the PP

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 #2 project idea about "project management".

More possible not so little improvements

There are other domains where improvements would enhance the user experience, but these are probably more difficult, so they are not part of this GSOC project, unless previous points are completed !

  • enhance search : 1) enable whole document scope search 2) use 3 state styles button so as to search italics only but bold or not bold occurences of a text. 3) text linked frames scope

See http://bugs.scribus.net/view.php?id=1752 and maybe http://bugs.scribus.net/view.php?id=5189

#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.

Why a project manager ?

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 too) : it becomes kind of 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 or newspaper. 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 (on demand), when the style or masterpage change.

Beside easying the creation of large document, this would 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.

A first step would be to use multithreading only for preparing preview images, similar in scope as this patch [ http://bugs.scribus.net/view.php?id=8730 ].

The idea is to fill the cache by worker threads and let the render thread use a dummy or previous version as long as the results aren't ready:

<avox_> (explains) Scribus uses class ScImage to store images

<avox_> those need to be scaled and color corrected before display

<avox_> also sometimes there are image effects active

<avox_> In documents with lots of images, that really slows Scribus down, especially because hires images have to be loaded from disk to memory

<avox_> The patch stores the result of scaling + color correction on disk, so Scribus only has toload the smaller PNGs and display them directly

<avox_> look at the times which show the speedup when opening a document for the second time

<avox_> of course the times for the first time are still long. So the idea is to use a dummy image as preview if there's no preview in the cache yet and calculate the preview with a worker thread

<avox_> then, when the preview is ready, signal Scribus to redraw the screen and display the final preview

<janardhan> can we use any dummy image

<avox_> my idea is to use a clock or something, so that the user knows the images is still being calculated

<janardhan> so we should do scaling and color correction in separate thread

...

<janardhan> if there are some common resources, then we have to use mutexex and parlled processing may not yield desired results

<avox_> it's all read access, so simultanous use should be no problem

<avox_> synchronization is only necessary for storing/reading previews from the cache and for signaling a rewrite (I think Qt has a special function to send a message to the rendering thread. or QWidget.update() can be used from any thread anyway, will need to look up the docs)

#4 - Implement a Scribus XML file format suitable for document interchange

Currently Scribus uses a variant of homebrewed XML. Although there exists some documentation, it's usually outdated and of limited use. A few months ago I (avox) proposed to have a RelaxNG [ http://relaxng.org/compact-tutorial-20030326.html ] specification for a new fileformat (in fact I was even caught on video while I proposed that [ http://river-valley.tv/towards-an-document-object-model-dom-for-scribus/ ] :-) ).

The project would consist of:

  • Setting up a website for the new fileformat and invite users to discuss
  • Implement the interface class Scribus IO { void xmlOut(QAbstractXmlReceiver r) const; void xmlIn(QXmlStreamReader r, ScribusBuilder b); } for all relevant Scribus model classes
  • Implement the class ScribusBuilder, which will contain common methods for creating page items, defining styles, writing text etc. Currently this code is spread among various scribus1XYformat.cpp and other source files.
  • Implement simple save and load action based on ScribusIO
  • Use RelaxNG tools to check conformity of the generated XML [ http://code.google.com/p/jing-trang/ ]

The result should be a modular and well-defined file format for Scribus which will be a candidate for replacement of sla files in the future. It should cover document content, but not necessarily all Scribus preferences which are stored in an sla file now.

Notes on implementation:

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