Re: [QGIS-Developer] stale bot :-(
Am 22.12.2020 um 23:23 schrieb Nyall Dawson: That sounds ideal, but unfortunately things just don't work that way. If your bug report is not reproducible there's a very low chance it will get fixed. So if you want your bug fixed, the motivation sits with you to make it as easy as possible for the bug triaging team/developers to reproduce. Honestly, if we (developers) can't reproduce a bug in <5 minutes, we'll just move to the next ticket in the queue and you've missed your chance at a fix... And that's exactly what stale bot and the feedback tag is designed to assist with -- it helps push the responsibility back to the bug submitter to make sure there's sufficient detail and a reproducible test case in the ticket. It's actually in place to avoid frustration caused by the "I submitted this ticket 12 months ago, why has nothing been done?!?!?" situation. Nyall first of all, happy new year! thanks for the detailed answer! From a user-point-of-view I thought the "Copy Report" would contain enough information needed to fix the issue. Knowing that you will skip reports/bugs that can't be reproduced within <5 minutes, I would suggest to change the text of the QGIS-crashed dialog to reflect that. Right now the text is "Include as much information as you can as well as steps to reproduce the issue if possible" - it would be better if the text would say something like "if you can reproduce..." or "if you can provide sample data that crashes..." or "if this crash occured more than once...". You could also remove the "Tell us something about when you got the crash." because it is both above the input field and in the input field - this way you have more room to explain what a helpful report is for you developers. This might help to save time for the developer and the user. Even if you don't change anything I'm thankful for your answer, because now I know when to report and when not, which saves me precious time! greetz ___ 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
Re: [QGIS-Developer] Temporal controller issues
Hi all, Il 04/01/21 03:32, Nyall Dawson ha scritto: > As background, I implemented time handling for vector layers as a > VOLUNTEER (completely unpaid). Would you have preferred I didn't do > this, and we had no time support for vectors at all? Please be very > wary of your language in future -- every piece of feedback worded like > this directly equates to a developer losing interest in volunteering > their time on QGIS, to the harm of all. ... > I like making the world a better place through volunteering my time on > making a first-class desktop mapping application, but I'm far from > being a slave to this, and my family, garden, and drum kit want my > time too! very well said Nyall. It should be broadcasted for the users to understand how things really work. Thanks for your many gifts! Cheers. -- Paolo Cavallini www.faunalia.eu - QGIS.org training, support, development on QGIS, PostGIS and more ___ 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
Re: [QGIS-Developer] Temporal controller issues
On Sat, 2 Jan 2021 at 10:23, Cory Albrecht wrote: > > Can somebody help me under the basics of how things work inside QGIS starting > from when it loads all the features for a layer through the steps, and then > finally drawing them on the map canvas, specifically with respect to the new > temporal controller (NTC)? > > The issues caused by the NTC have been very frustrating for me as I make > mostly (historical) timeline maps and I relied heavily on the old TimeManager > (OTM) plugin by Antia Graser and group. So many tasks are now much more > laborious or difficult because so many tools are just not time-aware. > > Was it not possible to add the NTC in such a way that would have still let > all the other features work as before with the filtered feature set before > being made time-aware, rather than confusingly operating on the unfiltered > set? Or perhaps it shouldn't have been turned on until the infrastructure was > there for the tools to be time-aware right away? > > Because I've just submitted yet another bug about the NTC, this time for the > selection tool, and it has me more than a little annoyed. As a result of this > bug I now have an unknown number of duplicate objects in multiple layers > across multiple databases/projects that I unknowingly pasted into them over > the past several months since the NTC was added to QGIS. > > I feel that the NTC was both poorly thought out and badly implemented as all > these bugs would indicate. I can empathise with your frustration, but this is a very complex discussion! As background, I implemented time handling for vector layers as a VOLUNTEER (completely unpaid). Would you have preferred I didn't do this, and we had no time support for vectors at all? Please be very wary of your language in future -- every piece of feedback worded like this directly equates to a developer losing interest in volunteering their time on QGIS, to the harm of all. I've fixed two of your issues here https://github.com/qgis/QGIS/pull/40834, as an UNPAID VOLUNTEER. Without funding I'm just not interested in fixing the snapping related issues. I don't personally have any need for these, and the QGIS snapping code isn't something I'm motivated in getting involved with at all. Perhaps there's another developer interested in looking at this, or perhaps a developer will take a look at this during the 3.18 bug sprint. Or maybe someone will pay for this fix and financial gain will be the motivation. I like making the world a better place through volunteering my time on making a first-class desktop mapping application, but I'm far from being a slave to this, and my family, garden, and drum kit want my time too! Nyall > ___ > 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
[QGIS-Developer] 3D View Interface Usability
Happy New Year to all, Recently I’ve been spending time playing with the 3D view in QGIS and I’m hoping to start a discussion about the UI and whether or not it might make sense to consider some changes to that UI based on what the intended uses of the 3D view are. Since I haven’t been directly involved in QGIS development before I’m approaching this from a user’s perspective and thought I should start with my observations and assumptions in case they’re radically off-base compared to what the core developers envision for the 3D view. Looking at the current state of the 3D view it seems heavily influenced by Google Earth. In particular, it seems to be primarily designed to simply display content that was created elsewhere. In the context of the rest of the QGIS UI, it is much more similar to the Print Layout view than the main 2D Map view. From a workflow perspective, you work with your data in the main 2D Map and then switch to the Print Layout or 3D views when you want to render that data in a different context. I think now is a good time to start thinking about a potentially bigger role for the 3D view because of the upcoming point cloud support. I know that interactive tools are out of scope for the current point cloud project, however, I think as soon as users can visualize point clouds in QGIS they will want to start interacting with them. Once the novelty wears off, simply rendering a point cloud in 3D is pretty ugly and not terribly useful. However, being able to digitize 3D points or lines with snapping to that point cloud is extremely useful and that type of work will be difficult to do without a well-designed 3D viewport. Even without new interactive tools, I think the more volumetric and often unevenly distributed nature of most point cloud datasets will make the current Google Earth style navigation less intuitive than it is when dealing with the mostly 2D data it was designed to interact with. For example, with the current camera controls you can’t track along the world z-axis so you lose a degree of freedom when the camera is horizontal. If you are looking at a street level building facade and want to move to looking at the 20th floor you can’t just track along the z-axis to get there. You need to tilt the camera up, try to place it’s rotation point at the 20th floor (possibly moving the camera backward and hoping nothing blocks your view), then tilt the camera down (which translates the camera up) to get back to horizontal. Although I spend a fair amount of time doing GIS work, my perspective comes from spending the last 10 years working with lidar and similar data in 3D modeling and metrology applications, where the primary mode of interaction is a 3D viewport. As a result, I have several specific thoughts on changes to the 3D View’s UI that would make it easier to use, better able to eventually support more interactive tools and more consistent with the rest of the QGIS UI. This email is already long enough though so rather than get into that now, I’d first rather ask what others think of the current 3D view. How much do people currently use the 3D view? Is the current UI working well for how it is being used? What about down the road? Is there a desire for more 3D tools and if so are there limitations of the current design that should be reconsidered? Thanks for reading, -- Jed Frechette ___ 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
