GSoC Proposal: Live news feed from financial newspapers

[Christian Stimming]

Dear Ajay,

Zitat von Ajay Thomas <ajaythomas.inc at gmail.com>:
> I didn't quite get the difference between Menu only Plugins and Content
> Plugins, the difference in functionality between the two. I looked into
> gnc-plugin-bi_import.c source code under plugins but it still didn't answer
> my doubt.

I don't think there is any difference. Also, the "bi_import" code is  
rather new and probably not so good as an example - I would recommend  
looking at the src/import-export/aqbanking/ code as an example because  
it has received multiple developers' iterations of code cleanup and  
improvements. (Incidentally, I also know that code much better, so I  
can answer questions there much better as well.) I don't think there  
is anything like a "content plugin".

There is a chance of some name confusion, because there is the  
"gnome-utils/gnc-plugin-page.h" object but this doesn't necessarily  
have to be tied to a "plugin". The correct naming is used for  
"gnome-utils/gnc-plugin.h" - that object is a GObject-derived class  
which represents one loadable module, with init and fini functions,  
that will usually add some GtkAction menu items to the gnucash menus,  
but additionally it could add some hooks at engine/gnc-hooks.h or  
event handlers at libqof/qof/qofevent.h for specific events.

Then there is gnome-utils/gnc-plugin-page.h. This is meant for a  
plugin that not only has some GtkActions, but additionally it will  
want to display data in a tab window inside the gnucash main window.  
If the plugin wants to implement such a tab window on its own, from my  
understanding the gnc-plugin-page.h supplies a useful framework to  
manage all the dynamic menu items that are specific to that tab  
window. The plugins can use such a gnc-plugin-page.h but they don't  
have to.

> I am currently going through the src/optional/gtkmm. I also looked into the
> gnucash report renderer using webkit (src/html/gnc-html-webkit.c) and I have
> a small doubt regarding implementation of my proposal using webkit. Will it
> be coding html and Javascript codes in a webkit c file?

The recent discussion with javascript in the reports  
http://lists.gnucash.org/pipermail/gnucash-devel/2011-March/031509.html were  
all about some code that generates a HTML page with embedded  
javascript, including loading of further HTML and/or javascript files  
from the gnucash installation path. This means your Internet-related  
ideas about a live feed could be implemented by writing a  
HTML/javascript page just like you would write one for a web browser,  
then writing some very short gnucash plugin code that just opens a  
webkit window, loads your HTML page (from somewhere of gnucash's  
installation path), and the rest is done by your javascript code that  
is embedded in that HTML page.

This is just one implementation option. Other options exist as well.

> Last, I would like to know, if I have to come to a conclusion about which
> technology I am going to use before the application deadline (April 8). I
> feel there won't be enough time by then to actually come to a conclusion
> about the implementation to be used. I intend to study thoroughly and
> develop some test plugins using both gtk widgets and webkit window before I
> can actually come to a conclusion.

This is completely fine. After all, trying more than one technology is  
already an important part of the project on its own, so it can be done  
during the summer and not before the application. I'm just explaining  
the availability of different options so that you have that in mind  
during the project. For now, it is fine to do some more experiments  
with one of the technologies, then explain your already observed  
advantages and disadvantages in your application. If your application  
is accepted, you can continue with your initially chosen technology,  
but for each disadvantage, you have the option to either live with it  
or to decide to try a different technology in case that disadvantage  
is grave enough. I mean, it is a good situation for you! You have your  
goal in mind, and you are not stuck to one single technology to reach  
that goal but instead you already know there are multiple different  
ways to reach that goal. If there were only one technology available,  
and after half of the project you found out some unsurmountable  
difficulties, you would be stuck - but due to the availability of  
various options, you already know you will have back up technologies  
available. There are other projects or goals where this is not the  
case, so this situation should be more comfortable for you.

Best Regards,

Christian