-1 from me.  IMO leave it for 2.0 release.  Maybe add a message into the SPIT dialog that says &quot;I will be removed in the next release by learn to use X to upload into PostGIS&quot;<div><br></div><div>I have never had issues with uploading layers into postgis using SPIT however on the other had dbmanger still feels very touch and go with if it will work or not. </div>

<div><br></div><div>- Nathan<br><div><div><br><div class="gmail_quote">On Thu, May 3, 2012 at 4:59 AM, Werner Macho <span dir="ltr">&lt;<a href="mailto:werner.macho@gmail.com" target="_blank">werner.macho@gmail.com</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<div class="im"><br>
On 05/02/2012 07:31 PM, Horst Düster wrote:<br>
&gt; +1 on Mayeuls comment<br>
&gt;<br>
&gt; <a href="mailto:mayeul.kauffmann@free.fr">mayeul.kauffmann@free.fr</a> schrieb:<br>
&gt;<br>
&gt;&gt;<br>
&gt;&gt;&gt; oh, yes, you&#39;re right - it&#39;s PostGIS Manager that requires<br>
&gt;&gt;&gt; shp2pgsql,<br>
&gt;&gt; not SPIT. My mistake. Sure, duplication of tools is bad. But<br>
&gt;&gt; removing SPIT would mean removing the *only* (correct?) QGIS GUI<br>
&gt;&gt; tool to load shapefiles into postgis without external<br>
&gt;&gt; dependencies. Do we want to get read of this before putting it in<br>
&gt;&gt; DB manager?<br>
<br>
</div>The same with me (beside the fact that I just learned howto use SPIT<br>
(thanks Horst)) it seems much more clearer to me using SPIT than using<br>
the dbmanager (for now) ..<br>
Don&#39;t get me wrong .. dbmanager is great but as long as SPIT is more<br>
intuitive (maybe because it just does ONE thing) I&#39;d like to wait with<br>
removing it until a filedialog import has been implemented that<br>
creates something like the batch upload which you currently see when<br>
you add more than one shapefile ..<br>
But I am quite sure guiseppe will have that soon :)<br>
<br>
So..<br>
- -1 from me for removing it right now (and probably think about the<br>
dependencies too which mayeul pointed out)<br>
<br>
Beside that ..<br>
What about creating hints for obsolete plugins that are getting<br>
removed with a hint that the function has been<br>
integrated/extended/moved to &quot;the new plugin&quot; .. or maybe a hint<br>
inside the plugin that this will become obsolete soon because the<br>
function will be available in core/new-plugin-name.<br>
<br>
marking plugins like that for at least one &quot;official&quot;-release-period<br>
will probably easen the migration for the user too..<br>
<br>
kind regards<br>
Werner<br>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v1.4.12 (GNU/Linux)<br>
Comment: Using GnuPG with Mozilla - <a href="http://enigmail.mozdev.org/" target="_blank">http://enigmail.mozdev.org/</a><br>
<br>
iEYEARECAAYFAk+hhAcACgkQDAH1YiCxBgkkdwCeOiDF96J6FTJdbQe+8IVb1ESG<br>
NwIAnj3euWQOLrYBjion8y0ifngCGLWL<br>
=E8B0<br>
-----END PGP SIGNATURE-----<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
Qgis-developer mailing list<br>
<a href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
</div></div></blockquote></div><br></div></div></div>