<div dir="ltr">Hello,<div><br></div><div>Sorry for the late reply. With respect to the types of resources, I had symbols, symbology style sheets, plugins, script runner scripts, sextante models, and if possible print composer templates. But the basic idea is not to create a GUI for all of these or change the existing ones like the plugins downloader, that is already present. My idea is to create the remote infrastructure (server - qgis-django) with the required API and write the basic backend library for the Quantum-GIS desktop application. Then the desktop application API can be used at respective places, wherever required. </div>
<div><br></div><div>When I wrote the proposal, initially I had the idea to write a single plugin, perhaps in Python to show-case the idea. But presently I think writing the backend code in the "core" library would be more helpful than a single plugin for a particular resource. Basic working is downloading -> validating -> initiating integration. This is common to any resource we might share.</div>
<div><br></div><div>The present code with the QgsSymbolResource class in my gsoc13 branch is an example of the above mentioned methodology with GUI integration done in the Symbol Import Dialog.</div><div><br></div><div>It would be great if others could add their ideas as well.</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jul 29, 2013 at 5:19 PM, Borys Jurgiel <span dir="ltr"><<a href="mailto:lists@borysjurgiel.pl" target="_blank">lists@borysjurgiel.pl</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">> Il 27/07/2013 17:58, <a href="mailto:aruntheguy@gmail.com">aruntheguy@gmail.com</a> ha scritto:<br>

> > What did I do this week?<br>
> > I finished integrating the symbols API of the qgis-django application<br>
> > into the Quntum-GIS desktop application. The Symbols import-export<br>
> > dialog now fetches the data from the remote resource  server configured<br>
> > in the settings.<br>
> ><br>
> > Commits at: <a href="https://github.com/tecoholic/Quantum-GIS/commits/gsoc13" target="_blank">https://github.com/tecoholic/Quantum-GIS/commits/gsoc13</a><br>
> ><br>
> > What do I plan to do next Week?<br>
> > Moving on from the symbols, I would like to concentrate on resource in<br>
> > general. Hence, I would work on finalizing the resources that would be<br>
> > shared remotely and the metadata structure of the resources.<br>
<br>
Hi Arun,<br>
<br>
When coding the new plugin manager recently, I was thinking how to cooperate<br>
with you to not duplicate the code. Finally I don't decided to consult with<br>
you at that stage, because - due to a time pression - I had to focus on the<br>
architecture, reusing as much as possible from the old code, postponing any<br>
nicer gui for 2.1.<br>
<br>
Unfortunately I don't plan to assign much time to the manager/installer during<br>
your current GSoC period and I even haven't compiled your branch yet (shame on<br>
me!), however, if you have any ideas how to include the plugin management to<br>
the common framework, I'd be happy to cooperate. The manager is accessible<br>
from Python, however, I don't consider it as any public API, so we still can<br>
change it quite much in QGIS 2.1<br>
<br>
Anyway, I haven't found any common way for presenting items. For plugins, I've<br>
found the simple name list + www browser for details the most suitable, while<br>
for styles probably a rich list would be better. Code snippets may be closer<br>
to plugins though...<br>
<br>
What do you think about it all?<br>
<br>
Borys.<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Regards<br>Arunmozhi<br>
</div>