[Qgis-developer] Future of standalone browser?

G. Allegri giohappy at gmail.com
Mon Feb 20 00:22:08 PST 2017


I agree for dropping it. Never used and many partecipants to our courses
were doubtful of its usefulness.

I guess it was meant to be similar to ESRI ArcCatalog but in that case a
lot more of functionalities should be implemented to give it a reason to
exist as a standalone sw.

giovanni

Il 20 feb 2017 09:12, "Régis Haubourg" <regis.haubourg at gmail.com> ha
scritto:

> Agreed here,
> never used it, and it sends a wrong message saying Esri UX choices are
> good enough to be copied. Let's get rid of it :)
> Régis
>
> 2017-02-20 8:52 GMT+01:00 Nathan Woodrow <madmanwoo at gmail.com>:
>
>> It's the same code, just in dock form.  I find the browser dock to be
>> super helpful but have never used the standalone version.
>>
>> On Mon, Feb 20, 2017 at 5:30 PM, Richard Duivenvoorde <
>> rdmailings at duif.net> wrote:
>>
>>> On 19-02-17 23:33, Nyall Dawson wrote:
>>> > Hi all,
>>> >
>>> > Just wanted to raise the discussion about the future of the standalone
>>> > QGIS browser.
>>> ...
>>> > So what should we do with the standalone browser in 3.0 and future? is
>>> > there a future here, or should we just drop this functionality and
>>> > save ourselves the maintenance burden? And if there IS interest in
>>> > keeping the browser around, is anyone able to step up and sponsor some
>>> > investment into making browser more useful and polished?
>>>
>>> Hi Nyall,
>>>
>>> I would be ok too to drop de browser (mainly because I've never used it
>>> standalone, and seeing Tim's first point in practice too).
>>> But what I'm wondering is what code is shared between the
>>> Browser-panel-widget and the stand alone one.
>>> Because some of your points are also valid for the widget? And I have a
>>> troublesome relation with the widget too:
>>> - eating cpu when you have a WMS-node or db node open when you
>>> stop/start QGIS
>>> - very silent failing of drag en drop behaviour (if it works it works,
>>> but ...)
>>> - missing datatypes/services too
>>>
>>> So same questions for the panel/widget?
>>>
>>> In general I'm in favour of making QGIS as lean as possible for 3.0, it
>>> will gain weight in near future anyway. And this is the only time in
>>> near future that we can do such a diet :-)
>>>
>>> Regards,
>>>
>>> Richard D
>>>
>>>
>>>
>>> _______________________________________________
>>> Qgis-developer mailing list
>>> Qgis-developer at lists.osgeo.org
>>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>>
>>
>>
>> _______________________________________________
>> Qgis-developer mailing list
>> Qgis-developer at lists.osgeo.org
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
>
>
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20170220/77426a39/attachment.html>


More information about the Qgis-developer mailing list