GSoC 2012 Project Manager baazigar
Short description:
“Scribus is an opensource DTP application which is primarily used to design small newspapers, brochures, newsletters, posters and books.” These lines-as seen on many sites like wikipedia- clearly emphasize the word “small” . This is because presently Scribus cannot easily handle large documents with 100 or more pages – scrolling through pages gets tough, it takes much time to update pages and within that time scribus becomes inactive as theres is a lot of data to be loaded. Anyways, Scribus users can still handle large Books and Newspapers by dividing a big document into small parts, (which are 20 – 40 pages documents)which can be easily handled for editing and combining them finally. But the problem that arises is that when layout of the book needs to be edited, it must done multiple times for each document.(around 10 times for a 300 page book). And this problem is not small as there are many attributes in a document like master pages, layers, styles, images, tables, numbering variables, frames and scrapbooks which need to be edited regularly while designing a book. So we need to solve this problem. The Project Manager solves the problem by having a set of common resources(master pages, styles, fonts, images, layers, stored in shared location) for the documents. It would make accessing these resources faster and since only a fraction of memory is used now, the speed of application also increases. Updating the document would be so easy that with just one edit every document gets updated. This would increase the preferability of Scribus over its other counterparts.
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-as seen on many sites like wikipedia- clearly emphasize the word “small” .This is because presently Scribus cannot easily handle large documents with 100 or more pages – scrolling through pages gets tough, it takes much time to update pages and within that time scribus becomes inactive as theres is a lot of data to be loaded.Anyways, Scribus users can still handle large Books and Newspapers by dividing a big document into small parts, (which are 20 – 40 pages documents)which can be easily handled for editing and combining them finally.But the problem that arises is that when layout of the book needs to be edited, it must done multiple times for each document.(around 10 times for a 300 page book). And this problem is not small as there are many attributes in a document like master pages, layers, styles, images, tables, numbering variables, frames and scrapbooks which need to be edited regularly while designing a book.So we need to solve this problem.The Project Manager solves the problem by having a set of common resources(master pages, styles, images, tables,scrapbooks,frames and numbering variables stored in shared location) for the documents. It would make accessing these resources faster and since only a fraction of memory is used now, the speed of application also increases. Updating the document would be so easy that with just one edit every document gets updated.This would increase the preferability 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 todefine the scope of a project (list of files)define shared objects: mainly styles and masterpagessynchronize the files using the most recent version of shared filesprint or generate updated PDFs for whole projectoptionally if time left: synchronize page numbers, indexes and other data across files of the projectThe first part of this GSOC project would be to define how the Scribus Project Manager will work precisely.collect needs for a project manager amongst userspropose and discuss a synthesispropose and discuss User Interface elements and technical solutionThe second part would be to thoroughly code and document the approved solution.
PRECISE DESCRIPTION OF PROJECT MANAGER:
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 [1]. 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. 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
Email: rajarajatsraj@gmail.com