No subject

process of 4 tabs and 1 enter key to feed entries one after other. A
possible issue would be if user needs to enter transactions for different
dates. This can be solved by including date field inside "Basic Info" group
at the expense of extra tab key to cycle through. A more better way is to
offer the choice to user by making it a user preference setting.

3)    To integrate (with unified transaction dialog created above or / and
on an independent tab) a new feature called First Person Overview or First
Person Dynamic Reporting. The idea behind this is that of a human being's
memory. A person can very well remember what he/she has spent/earned of the
past few days (like previous 2 days). If that person were to document his
transactions on a physical book, it would follow a specific pattern most
similar to General journal reporting or diary writing. The idea is to
integrate this common human way of visualising and present these entries
below transaction dialog. So for example a user can enter a transaction and
its dynamically updated below it in the "First Person Overview" (FPO). This
view will further allow as a central point to open up various types of
reports and charts. This would either open up in a new tab or a popup
depending on the amount of reporting the user wishes to see. Implementation
of pie charts in pop ups is one of the ideas being thought about first.
Further, this FPO would implement backlog fetching (like in some irc clients
like Quassel which fetch previous entries as and when we scroll up). The
advantage is that there is no pre rendering and the need to generate a
complete report.

Here is a very rough mockup with details:
http://cdn.nishmu.com/cutecash/mockups/first-person-overview-details.png

Just plain mockup:
http://cdn.nishmu.com/cutecash/mockups/first-person-overview.png

The various reports that can be generated at present serve very well for
some particular purpose. There is a need for generating a report system that
consolidates the whole activity and provide an interactive way for specific
entries to be analysed upon (by offering user to click on individual
items/accounts appearing on FPO. The idea is to integrate the existing solid
reporting systems (various types of reports), and integrate it into FPO.

4)    I understand that I would be contributing code to a new undeveloped
code of a new branch of the project, so I think it would become my
responsibility to provide and maintain good documentation. This would make
it easier and encourage other developers to get involved and get started up
quickly. I believe this can be done using a wiki to maintain the
developments. Also since new features would be included, a separate wiki of
end user documentation would be maintained. This can aid in creating Help
files for users.

5)    This is only a thinking part of the project to develop further ideas
for project. The ideas mentioned here would not translate to working
solutions withing my GSOC period. The vast Qt library would make it possible
to extend the functionality of CuteCash. Qt Linguist tool for easy
translations to many languages. This would help non developers to easily
contribute their translations. Use of Qt Network libray to think about
implementing a server concept, to act as central processor. It can thus
communicate with simple applications which are present on mobile devices
(iphone, android, maemo, meego, etc). They would only act as front end and
would leave all processing to CuteCash server. Thus greatly increasing the
types for access methods of accounting systems.

Deliverables:
==========
1) I provide a solid tested unified data (transaction) entry system for
CuteCash.
2) I provide integration of atleast two report views.
3) I enhance the accounts overview and its sub accounts overview on
different tabs.
4) I provide "First Person Overview reporting" with "backlog fetching
method" with dynamic features to "interact with individual transactions and
items to pull up detailed reports", which a user has to normally select from
pull down menu from Tool Bar.
5) I provide auto-suggest feature across various field types. Auto-suggest
data would be independent and stored outside the accounts database.

Timeline:
=======
1) First phase would be to get familiar with the backend C API of GnuCash,
discuss and get suggestions and ideas on how to get started out using the
core code. This period would also involve getting familiar with SVN (with my
experience with Mercurial, it should be easy).

2) With a better understanding of the codebase, the next step would be on
designing GUI's for various interfaces. This phase would involve creating
mockups and getting reviews from end users. Probably by sending the updates
and mockups via a separate mailing list for CuteCash. This is essential
since I believe that, the earlier the design issues are sorted out, the
better.

3) This part overlaps with the previous step. Basically translating the
existing GUI, while improving the design of the specific feature: Data entry
system and Dynamic reporting.

  4) Completely involve the development in the unified data entry system.
Adopt code-release(to users)-fix cycle. Then work on dynamic reporting based
on the design decisions done from the research in step 3.

 5) Implement auto-suggest feature for the fields in unified transaction
entry system. It could be replicated to other areas, but the goal withing
the GSOC period is to provide working auto-suggest for transaction dialog
fields.

6) Development pens down. Most of the documentation would go hand in hand
with development, since I believe "log things down as you go". But any
remaining documentation would be done in this phase.

During the project period, for approximately one week there will be minimal
activity on the project. The lost time will be covered up "in advance" and I
would make sure to notify about this to the relevant people.

What has been done till now:
=====================
I have built and tested the CuteCash code from svn on debian with kde. Got
comfortable with the c++ UI source files, able to add further controls on
the QMainWindow. Also checked out the GnuCash gtk UI files to get an insight
of the application. Meanwhile I am in the process of building the code on
Windows. But for development I would rather prefer my current unix cmake
setup. During project period, I plan to release alpha versions of windows
binaries from time to time, so that a general end user can give suggestions
on the development process.

What I think about this project:
======================
1) I am very enthusiastic and excited about this particular project not only
because of the fun part in coding but also due to a particular personal
interest and desire. I have analysed a bulk of real world accounting data of
typical general consumer and have lots of ideas on how to improve the user
experience with this tool for a general user.
2) Stick to it in the long run, to see it does make out to what it set out
to be, an easy to use solid accounting system.

Thank you for reading. The content presented here is based on what I could
comprehend, research and analyse. I am sure there are lots of areas to
improve upon. I would gladly appreciate your suggestions and advice to help
improve the proposal. I look forward to join an exciting open source
community, get to know a lot of real world developers out there, and be a
humble contributor to the community.

Good day!

Regards,
Nitish