<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-html40/strict.dtd"><html><head><meta name="qrichtext" content="1" /><style type="text/css">p, li { white-space: pre-wrap; }</style></head><body style=" font-family:'DejaVu Sans Mono'; font-size:9pt; font-weight:400; font-style:normal;"><table style="-qt-table-type: root; margin-top:3px; margin-bottom:3px; margin-left:4px; margin-right:4px;"><tr><td style="border: none;">Tuesday 20 of January 2009 14:27:14 Paolo Cavallini napisał(a):<br>
> I think we should have a proper plugin infrastructure, analogous but<br>
> separated from C++ source code.<br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>Where do you mean the infrastructure should be implemented? In the svn or just <br>
in existing repositories? <br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>> Ideally this should:<br>
> - allow devs with privileges to upload their plugin<br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>it's done in the existing repositories<br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>> - do some consistency check (removing hidden, unnecessary files, .pyc<br>
> etc.) and pointing out missing elements (licence, minimum version, etc.)<br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>it's feasible, as I think (but requires unpacking the packages)<br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>> - generate automatically the relevant entry in plugins.xml<br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>it's done<br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>> - allow the maintainer to mark each plugin with the appropriate category<br>
> (sandbox, experimental, unstable, testing, stable), so users are warned<br>
> (but still allowed and encouraged to experiment).<br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>I think it would be too many categories too keep it all clean. Someone would <br>
have to evaluate them again and again. Now we have the two categories (official-<br>
stable and the rest). However we can implement the additional tag with 2 or 3 <br>
categories (experimental/testing/stable) to separate the plugin stage from its <br>
origin.<br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>In this case users could enable unofficial repositories but still mask e.g. <br>
experimental plugins. Also plugins could be available in various versions <br>
(older-stable and newer-unstable) so users would be able to easy downgrade to <br>
the stable one.<br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p></td></tr></table></body></html>