GSoC 2012 Project Manager baazigar

original-google-melange-proposal is here

Short description:
Scribus is a great DTP application which is used to print many magazines and books.(See success stories link.) And a lot of these books are more than 100 pages in size. But due to high performance UI, these large books cannot be handled easily. Because documents containing more than 20 - 40 pages make it slow. So to overcome this problem, users make independent documents of 20-40 page and then combine them finally after editing. But attributes which are common to the whole document have to be changed regularly during designing (masterpages, styles, fonts, images, frames, tables, scrapbooks, page numbers), and it has to be done for each 20-40 page document. The Project manager aims to solve this problem by sharing the attributes between these independent documents which will make editing and updating easier for the greater user experience in book editing and designing.

Additional info: http://wiki.scribus.net/canvas/Category:Success_Stories

WHY SCRIBUS NEEDS A PROJECT MANAGER?
“Scribus is an opensource DTP application which is primarily used to design small newspapers, brochures, newsletters, posters and books.” These lines from wikipedia and other sites show that handling big documents or books in Scribus is pretty difficult.

This is because presently Scribus cannot easily handle large documents with 100 or more pages. Documents with more than 40 pages slow down Scribus mainly when there are lots of images or linked frames.

Anyways, Scribus users can still handle large Books and Newspapers by dividing a big document into small parts(which are 20 – 40 page documents).These independent documents can be handled easily for designing & editing individually. These are combined finally after editing.

But this method does not work well when lot of editing has to be done on a regular basis. When the design or layout of the book has to be updated, many attributes have to be changed. And for a 300 page book, 10 times editing must be done(for 10 individual documents). The attributes include masterpages, layers, styles, images, tables, numbering variables, frames, scrapbooks. This much amount of editing can be pretty tiring.

TO SOLVE THE PROBLEM,
The Project Manager will be implemented in such a way that the number of edits required to design a huge book will drastically decrease. This will be done by making the edited attributes common to the independent documents. Presently, only pages in document share these attributes among themselves.Sharing among documents will be implemented.

This will enable the user to edit only once and whole set of documents would be updated. A separate user interface for the project manager will be created which will give easy access to all the common resources/attributes.Since the resources are shared now, Scribus will work fast even for large no. of pages.

This would surely increase the preference of Scribus over its other counterparts.

AIM OF PROJECT MANAGER:
These aims have been given on Scribus GSoC ideas page. I have given a solution to each of the required aims of the project in PRECISE DESCRIPTION OF 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

1)define the scope of a project (list of files)

2)define shared objects: mainly styles and masterpages

3)synchronize the files using the most recent version of shared files

4)print or generate updated PDFs for whole project

5)optionally if time left: synchronize page numbers, indexes and other data across files of the project

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

1)collect needs for a project manager amongst users

2)propose and discuss a synthesis

3)propose and discuss User Interface elements and technical solution

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

IMPLEMENTATION OF BACK END:
Firstly Project Manager will start with creation of a new file called book.buk (.buk is a new filetype which will be added to Scribus.)

After that, project manager will be able to create new documents in the file book ,not more than 40 pages in size(i will call the collection of documents a “book” from now on). Preferably no. of pages=20 will be best.

After that, it would have the ability to import existing documents and dividing it into documents of size between 20-40 pages.

From the imported documents the attributes will be extracted and then stored in the shared place in the book.buk. The attributes include masterpages, styles, images, tables, scrapbooks, frames, numbering variables etc.

After that, project manager will have the ability to update, delete, create new attributes which when modified will automatically update all the documents in the book.

And most Importantly, the documents that are created or imported will not contain the shared attributes. Only the link or pointer to the .buk file will be stored in those documents.

After that, the book will be able to synchronize those documents in proper order for numbering them, adding cover and back pages, making indexes and appendices for the final touch to the book.

Lastly, pdf generation will take place from the file book.buk which will be done by adding shared attributes to the documents and then printing them out.

IMPLEMENTATION OF FRONT END:
The user interface for project manager will be in the form of a palette (dialogs are for temporary things and palette for permanent). All attributes will be accessible through this palette. Users can stack the palettes in the docked window and use many palettes and features with lesser clicks.

Points of attention:

Discoverability:

Most users don't use the potentiality of the software they use. A new tab for making big books in the “New document” dialog box that pops up in the beginning. It must be also added to the menu bar.

Ease of Access:

Users should be able to access functions with as few clicks as possible. To implement this, the project manager palette will be accessible at right side of main window in docked mode.

Efficiency and Productivity:

Shortcuts for finer functions for professional users. Keyboard shortcuts can also be added. I will add all attributes on the main palette.

The above synthesis that I proposed will be implemented in very great detail after discussing it with the community and the developers.

TIMELINE
Discussion with the community and developers and their feedback will take place every week regardless of the work to be done.

April and May will be the learning period when I will be getting to know how will I implement the required deliverables.

I will document each class and function before starting and after finishing. So that it would be easy to add final documentation on wiki later.

April:

Discuss with the Scribus community how the user interface of Project Manager should be.

Getting to know more about Scribus codebase by solving more bugs related to styles and masterpages.

Last week: exams.

May:

Learning how sharing of resources is done.

Learning how new filetypes are made and the file handling with qt.

Learning how pdf generation takes place from scribus documents.

May 28-June 3:

Creation of the project manager file called .buk and its implementation of what files it would store.

June 4-June 10:

Developing classes for adding new documents to project manager as well as importing documents.

June 11-June 17:

Extraction of attributes from the imported documents and storing them as shared objects in the file storage location of .buk

June 18 -June 24:

Connecting the editing classes of the attributes(masterpages, styles etc) to the book manager after making them capable of editing shared resources(masterpages, styles etc)

June 25 – July 1:

Enabling the documents to read shared data from shared location and updating the pages in canvas whenever attributes modification has been done.

July 2 – July 7:

Implementing finer qualities of project manager, connecting all the above mentioned details, debugging and testing.

July 8 to July 10 :

Mid term evaluation preparation.

July 11- July 22:

Two weeks for designing the palette and making handles for accessing and editing all these attributes. Two weeks are sufficient because discussion and research would have been done in april and may.

July 23 -July 29:

Synchronizing the documents by putting them in order and adding numbering system to the project manager.

July 30 -August 5:

Efficient pdf generation of the pages(It may seem a bit difficult to carry it out in a week but I would have done the research work on this in MAY itself)

August 5-August 13:

Testing and Debugging of GUI and merging with the trunk(I would try merging code to trunk whenever some deliverable has been implemented)

August 13-onwards:

Suggested pencils down date – preparing final evaluation and giving a final touch to requirements.

I will work for 40 hours or more per week during the GSoC as its a full time job. I have previously coded 10 hours a day for a week. So I can surely take out some more time if it becomes necessary.

And I have no other commitments during GSoC. I have shifted all my plans to before or after GSoC.

CONTINGENCY PLANS:
Should I be able to cover the above mentioned topic before the prescribed time, I will implement finer details of the project manager like having an indexing system, synchronizing other data, support for chapters and sections using text variables and little details like coverpage, backpage, appendix etc.

If some part of the project takes more time than required, I may postpone efficient pdf generation(directly from .buk file) after GSoC and instead do a normal pdf generation from separate documents or the numbering system(whichever is of lower preferance).

But I will try my best to stick to the plans and make this Project successful.

AFTER GSOC:
I would love to code for Scribus even after GSoC ends. I like the idea of contributing to a community and making its software better than it commercial counterparts.

I will add some more features to this project and make it better because I know this project is incomplete within the bounds of GSoC .I would solve the bugs and continue developing for Scribus like the guy who made tables successful in Scribus last GSoC.

For Example:

I will take up developing finer details and adding new features to this project.

I will try taking Scribus code closer to its release quality.

I will be an integral part of Scribus community.

and I wish to get accepted into the core developing team of Scribus.

ABOUT ME:
I am a pursuing btech from Dhirubhai Ambani Institute of Information and Communication Technology, India. I love reading books, pencil sketching and designing on pc.

Some of my friends in the designing field use Scribus and I got to know about this project through them.

RELATED SKILLS:
I know C++ from my 11th grade and have been using it to make small applications and projects for school and college. I learnt qt about a couple of months ago for voluntary development of a contract bridge game(a multiplayer card game used on tablets and uses networking) which is a long term sponsored project. I have made a poker bot with my friends in java (uses oop) which can play with humans.

I am well adapted to use version control system and bug tracking system.

I am also good at algorithms(I hope to use them in this project if required).

EASY HACKING:
I solved a bug on the bug tracking system of scribus http://bugs.scribus.net/view.php?id=10409

I am currently improving on the import of master pages(like styles) because my project demands it. It will be complete in a couple of days.

CONCLUDING REMARKS:
Although I am a second yearite, I am highly inspired and motivated to develop Scribus and be a part of the larger community. I was browsing through the Scribus code and getting to know how things work in the code even during my mid term exams. Its feels good when you solve a bug after days of getting to know how palettes work through use of docs and how canvas paints and how much difficult it is to design a good plugin.

I know it would be a huge learning curve for me to code for such a successful open source community like Scribus and I would be find myself lucky to contribute even after GsoC.

CONTACT INFORMATION:
Name:Rajat Gupta

irc : baazigar (irc.freenode)

Email: rajarajatsraj@gmail.com

201001216@daiict.ac.in

facebook:facebook.com/rajarajat