GSoC 2012 Project Manager baazigar: Difference between revisions

From Scribus Wiki
Jump to navigation Jump to search
No edit summary
m (Protected "GSoC 2012 Project Manager baazigar" ([edit=sysop] (indefinite) [move=sysop] (indefinite)))
 
(One intermediate revision by the same user not shown)
Line 1: Line 1:
[[Category:GSOC]][[Category:GSOC_2012]][[Category:GSOC_2012_Proposals]]
[[Category:GSOC_2012]][[Category:GSOC_2012_Proposals]]


[http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/rajatgupta/1002 original-google-melange-proposal is here]
[http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/rajatgupta/1002 original-google-melange-proposal is here]

Latest revision as of 20:21, 20 April 2012


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.


PRECISE DESCRIPTION OF PROJECT MANAGER:

IMPLEMENTATION OF BACK END:

The Project Manager will implement two type of documents: masterDocument and slaveDocuments.


What is a masterDocument(Definition)


A masterDocument is an sla file(normal Scribus file)which will have all the details regarding the shared attributes. It will be storing all the attributes(masterPages, styles, colors, etc.). It will store the attributes which are global(ie common to whole book, all documents use them and can edit them with changes shown in all the documents automatically)


What is a slaveDocument(Definition)


A slaveDocument is a sla file which will be used to make actual book pages. This Document will be containing links to the masterDocument for accessing the updated attributes from other slaveDocuments. There is only one masterDocument and more than one slaveDocuments.


How will masters and the slave relate?

The master will control all the slaves. Each edit done on the master will show up in the slave automatically. The slave do not talk to each other. They only link with the master. If one slave asks for a change in the global attribute, the change will show up in other slaves only through masterDocument.


How will the change in attributes propagate?

When some attribute is created, modified, deleted, its a change.

way 1. Change the masterDocument and all slaves will follow.

way 2. Make a change in the slaveDocument and make it global ie store that change in the masterDocument


Which fileformat will masters and slaves use?

The masterDocument and the slaveDocuments will be implemented by changing the sla slightly and modifying according to our needs


After that, the PM 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 by exporting individual slaves and then combining them finally by calling pdftk.


Use cases for PM:

Users have to write a book divided in chapters and user wants to make sure that they use the same styles.

Users want to be able to work with multiple files open at the same time on the same computer.

the scrapbook must be shared. and there is a file with the full TOC, one with the bibliography and one with the index.

each chapter has its own table of contents: just the list of the sections without more details.

the page numbers must go through the chapters, but not for the TOC, the bibliography and the index.

User has a visit card, letter paper, badges and invoices paper to create regularly for different clients. The master define the logo, name, adresses, styles, and these apply automatically to various slave docs : letter paper, visit card, invoices and badges.


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 sla fileformat has been designed to store attributes.

Learning how pdf generation takes place from scribus documents.


May 28-June 3:

Implementing the master Document properties

June 4-June 10:

Implementing the slave Document properties

June 11-June 17:

Connecting the slaves to the Master

June 18 -June 24:

Adding support for attributes like masterpages, styles, colors , images, frames, etc

June 25 – July 1:

Implementing the generation of masterDoc from generation of slave as a copy of the master.

Implementing the import of sla files and making them slaves.

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:

Making a nice user interface for the Project Manager

July 23 -July 29:

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

July 30 -August 5:

PDF generation from individual docs and combining them finally.

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.

It may be possible that time may not remain for pdf generation part or the numbering system part. This would be due to the possible demand of a more precise and powerful base of the master and slave relation. A more advanced GUI may also take more time.

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 two bugs on the bug tracking system of scribus

http://bugs.scribus.net/view.php?id=10409

http://bugs.scribus.net/view.php?id=10455

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