On Thu, 21 Feb 2019 at 00:51, Thomas Baumann <rdbath.regiod...@gmail.com> wrote: > > Hi Nyall, > > thanks for your feedback. > You are right that some of my examples were not ideal to explain what I > meant, so I try to explain it a bit better this time ;-)
Thanks - it's much appreciated! > create a vectorlayer > > Something like: > > https://gist.github.com/rdbath/bbba7640cf98ab09dc9bb6018011f05e#file-pyqgis_common_functions_examples-py-L24 Ah, that one IS a source of pain. QGIS 3.0 makes it easier with new_empty_memory_layer = QgsMemoryDataProvider.createMemoryLayer( ... ) and new_memory_layer_with_copy_of_features = source_layer.materialize( QgsFeatureRequest().setFilterExpression( ... ) ) You'd still need to follow these up with a call to QgsVectorFileWriter to save as a disk based format. There's some trickiness here because with some disk formats it's not possible to create an empty layer upfront -- e.g. geojson. You have to have some features ready to initially populate that layer with at time of creation. I'd be interested to hear any ideas for "ultimate wishlist" api here? > Example2: For loading layer I meant something like > > https://gist.github.com/rdbath/bbba7640cf98ab09dc9bb6018011f05e#file-pyqgis_common_functions_examples-py-L7: ... This approach is somewhat of a hack, which is why I wouldn't like to see it as part of any "officially supported" python library. Really, API for doing this belongs in core QGIS API itself (covered by appropriate documentation + unit tests, of course!) > Example3: Iterate through layers: ... > So if there would be a pyqgis-commons library where I would know that I just > have to call a function "get_visible_layers" instead of using [l.layer() for > l in > QgsProject.instance().layerTreeRoot().findLayers() if l.isVisible()] I > probably could use this in my next plugin without having to search/google how > to do this. Right - but again, this doesn't belong in a Python specific library. What we need here is a core API addition "visibleLayers": visible_layers = QgsProject.instance().layerTreeRoot().visibleLayers() > Example4: show messages / log messages: > One other example would be the function "display_warning_message_bar" from > the inasafe-utilities where I can show a short message and also provide a > button to show more details about a warning: > https://github.com/inasafe/inasafe/blob/bd00bfeac510722b427544b186bfa10861749e51/safe/utilities/qgis_utilities.py#L132 Once again, I think this could easily be in the c++ API, so that both Python and c++ code could take advantage of it. I don't see anything Python-specific here. > Example5: Settings: > Here I hat something in mind like the qgis-settingsmanager of opengis ( > https://github.com/opengisch/qgissettingmanager ). > I know it is not only a collection of python-/pyqt-functions but a whole > python module but I still it is an example of how functionalities are > provided to make the development of plugins easier. Yes, that one *is* nice. I think Denis originally intended that to be made available in the default PyQGIS library, but I suspect just ran out of time. > So it is always about providing some helper functions that I could also write > by myself but which will save time during development and can help me to do > the things in a consistent way in all of my plugins. Right, but I think it's very important to differentiate here between: 1. API additions which are useful in all contexts (c++ and Python) 2. Python specific API additions, which make use of Python only functionality like decorators, exceptions, and context managers > > >> >> I'm not saying we can't improve the PyQGIS experience, but I don't >> personally see these as good candidates. >> >> I think we have a LOT of work to do with things like: >> - throwing proper exceptions instead of crashing/returning "None" >> values/returning "invalid" objects (e.g. QgsGeometry.fromWkt should >> ideally raise an exception for invalid wkt instead of returning a null >> geometry) >> - providing Python-esque things like __repr__ methods, __len__, [] >> operators (which behave in a python style, e.g. with -1 returning the >> last item), iterators, etc >> - providing more "context managers" (e.g. with .... : #something ) > > > I don't have such a deep insight in the QGIS-codebase but I guess this would > probably have to be done in the C++-part of QGIS, wouldn't it? Sometimes, or sometimes it's done like this: https://github.com/qgis/QGIS/blob/master/python/core/__init__.py.in > I agree. Even if the PyQGIS-Documentation is now much better than in the past > for me often some short examples like the ones from Thomas Gratier are really > helpful to know how to proceed: > https://webgeodatavore.github.io/pyqgis-samples/ I'd love to see discussion on how we can merge this awesome resource into the new PyQGIS documentation. Together they'd make an awesome resource! Nyall > > So I see three ideas here: > > - provide a collection of common PyQGIS-functions > - provide nice PyQGIS-examples > - improve the PyQGIS experience in generall (your examples like throwing > proper exception) > > > regards, > Thomas > > > >> Nyall >> >> > >> > >> > >> > Wouldn't it be possible to provide such a collection not only from privat >> > persons/projects but from the QGIS-project itself so users could add >> > common functions? >> > I think the chances would be higher that such a "official" collection >> > would be used in the long run and constantly extended. >> > >> > Apart from the fact that developers could save time while writing their >> > plugins this could perhaps also help to improve the overall quality of the >> > qgis-plugins as there would probably be several persons who could/would >> > countercheck these common functions to make sure they are well written. >> > >> > regards, >> > Thomas >> > >> > PS: I asked something similar also on gis.stackexchange recently: >> > >> > https://gis.stackexchange.com/questions/311755/looking-for-common-pyqgis-functions-for-qgis-3 >> > >> > >> > >> > >> > _______________________________________________ >> > QGIS-Developer mailing list >> > QGIS-Developer@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@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer