GSoC 2012 Ideas: Difference between revisions

From Scribus Wiki
Jump to navigation Jump to search
m (intro)
Line 84: Line 84:
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.


==#3 - TBD ==
==#3 - Rendering and multithreading ==
 
<Velmont> Hmmm. Anything else... -- Oh, yeah, it's actually nice and speedy. But a toggle from display to the other mode is very very slow. I was doing quite a few toggles because the editor was working in the same room and always coming over :P
 
<a-l-e> do you mean togling between preview and edit mode?
 
<Velmont> a-l-e: preview and edit, yes.
 
<a-l-e> i wonder if there is a reason for this switch to be slow... for what i know about scribus, i guess that it's redrawing all the pages and not only the ones shown on screen...
 
<Velmont> a-l-e: Seems maybe scribus is caching loads of stuff and thus is fast when you're in the mode, - but switching, it throws away everything. You probably can't switch back to the old one either, because it might be out of date.
 
<a-l-e> would be nice to know the reasons why it slows down...
 
<Velmont> Hmmm. Although it could maybe just switch to the old cached version, then show a progress indicator on that page (or gray it a little) to show that it's old and stale, -- then update that page, and on finished, switch from the old-cached-preview to the new-preview.  That way it could also paint only one or two pages (quite possibly the only ones you've changed), and very quickly show the whole document.
 
<a-l-e> imo a good place to do the first tries with some multithreading :-)
 
<Velmont> Or, -- no, if there is a "dirty" marker on each page. -- Maybe (I don't know anything about scribus internals), it could only re-render the changed pages. So you have a cache, -- and in the usual case of preview, change around do some more stuff on two pages (out of 50), and new preview, only 2 pages are dirty, so it only re-renders those, and uses the old for the others.
 
<Velmont> Anyway, -- I'm actually really happy with Scribus' speed in normal work. -- When it has switched, it's very nice and snappy.
 
<a-l-e> there is a potential gsoc student interested in multi threading...
i wonder if this could be a project for him...
not an easy one, though...
it would be nice to hear from the team if they think it's doable...
 
<Velmont> :-)
 
 
==#4 - TBD ==

Revision as of 10:55, 10 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 :

  • 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
  • last but not least, a specific time could 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.

#3 - Rendering and multithreading

<Velmont> Hmmm. Anything else... -- Oh, yeah, it's actually nice and speedy. But a toggle from display to the other mode is very very slow. I was doing quite a few toggles because the editor was working in the same room and always coming over :P

<a-l-e> do you mean togling between preview and edit mode?

<Velmont> a-l-e: preview and edit, yes.

<a-l-e> i wonder if there is a reason for this switch to be slow... for what i know about scribus, i guess that it's redrawing all the pages and not only the ones shown on screen...

<Velmont> a-l-e: Seems maybe scribus is caching loads of stuff and thus is fast when you're in the mode, - but switching, it throws away everything. You probably can't switch back to the old one either, because it might be out of date.

<a-l-e> would be nice to know the reasons why it slows down...

<Velmont> Hmmm. Although it could maybe just switch to the old cached version, then show a progress indicator on that page (or gray it a little) to show that it's old and stale, -- then update that page, and on finished, switch from the old-cached-preview to the new-preview. That way it could also paint only one or two pages (quite possibly the only ones you've changed), and very quickly show the whole document.

<a-l-e> imo a good place to do the first tries with some multithreading :-)

<Velmont> Or, -- no, if there is a "dirty" marker on each page. -- Maybe (I don't know anything about scribus internals), it could only re-render the changed pages. So you have a cache, -- and in the usual case of preview, change around do some more stuff on two pages (out of 50), and new preview, only 2 pages are dirty, so it only re-renders those, and uses the old for the others.

<Velmont> Anyway, -- I'm actually really happy with Scribus' speed in normal work. -- When it has switched, it's very nice and snappy.

<a-l-e> there is a potential gsoc student interested in multi threading... i wonder if this could be a project for him... not an easy one, though... it would be nice to hear from the team if they think it's doable...

<Velmont> :-)


#4 - TBD

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