Re: [QGIS-Developer] 3D View Interface Usability

[Jed Frechette]

Hi Martin,

I’m glad to hear my impressions weren’t too far off. I do think there
are benefits to the GE style controls, especially for users that are
already familiar with that software. Perhaps it makes sense to keep
those controls as a separate navigation mode in addition to a new mode
that is better suited to more complex tasks? Although I guess there’s
the risk of muddying the interface by not picking one clear consistent
set of controls and optimizing them.

It’s interesting that you mention multiple viewports, as that would
actually be fairly low on my wish list. This may be a personal
preference, but I don’t use multiple views very often in applications
where I have access to them. There are definitely certain tasks which
are easier with multiple views so they are nice to have, but if I had
to choose I’d much rather have a single viewport that is very
efficient than multiple viewports that are less fluid. That’s what
most of my suggestions below are geared toward; a single viewport
where an experienced user can almost instantly navigate to the exact
view they want, potentially edit/create some data, and within a few
seconds be moving on to the next part of the scene.

I’ll provide links to a couple examples and videos at the end of my
post, but since there is so little consistency between 3D apps I want
to provide some justification for what I think works rather than just
say “Make it like my favorite program.”

Regardless of the exact control scheme, I think the most important
observation to make when designing a 3D interface is that for any type
of interactive task the user is constantly switching between
navigating around the scene and using tools to perform actions, e.g.
identify, measure, digitize, etc.. Therefore, switching between those
two modes of interaction needs to be as quick and easy as possible.
Clicking toolbar icons to switch modes works but is probably the
slowest way to do it. Some applications try to overload the mouse
buttons so you can navigate and use tools at the same time, but I’ve
never used a system like that which I thought worked well. I think
it’s much better to make a clear distinction between navigate mode and
tool mode and make the user responsible for switching between them via
hotkey. That way your tools can make use of all 3 mouse buttons
independently of your navigation control scheme, which can also
utilize all 3 buttons.

Although various applications have made different choices about the
hotkey to use, to me the space bar is the obvious choice. The space
bar is the most used key when typing and the navigation hotkey will be
the most used key while navigating in 3D view so it should be the
space bar too. The navigate hotkey could be used as a toggle, e.g.
with a tool active tap the spacebar to switch to navigate mode then
tap it again when you want to go back to the tool. Alternatively, the
hotkey could be a modifier, e.g. hold down the spacebar to navigate
then release it to return to the tool. Both can work well, but I
prefer the modifier approach. A modifier removes the need for an
indicator, e.g. different cursors, for which mode you’re currently in
like you would need with a toggle. In addition a modifier can act as a
hint to stay in dynamic mode if your viewport is set up to improve
interactive performance by rendering different LODs based on whether
the camera is currently static or dynamically moving.

The specific navigation control scheme I would advocate for is:

Dolly along camera z-axis (Space + RMB or Scroll wheel)
==
QGIS already behaves this way so no changes here. Usage of the scroll
wheel is also consistent between the 2D and 3D views so that’s good.

Track along camera x & y axes (Space + MMB, Space + Shift + RMB)
===
The middle mouse button is used for the same movement in the 2D view
so it would be good to stay consistent with that. The alternate
mapping, Space + Shift+ RMB, is for laptop users that only have 2
trackpad buttons. By tracking along the camera x & y axes instead of
GE style tracking navigation is much more intuitive in a fully 3D
world and you eliminate the orientation dependence I referred to in my
first post.

Tumble (Space + LMB)
=
Tumbling in QGIS is already pretty good. The only change I would make
is to pivot around the cursor’s current position rather than the
center of the viewport. uclaros already suggested this in the tracker
[1] and it would make precise navigation much easier.

Roll around camera z-axis (Space + Ctrl + LMB)
===
This is really useful when you just want to level the camera relative
to the horizon.

Box zoom (Space + Ctrl + RMB)

Good for zooming in to a specific region of the scene.

Other navigation controls could certainly be added, e.g. restricting
tumbling around additional axes, but I think the controls above cover
the majority of needs.

Two 

Re: [QGIS-Developer] stale bot :-(

[DIF]

Not to hijack the thread, but that had me thinking about the current Bug report 
template on GitHub. At **QGIS and OS versions**, it's written . However when doing this, the about info is simply pasted line by line 
which make it long and less readable. Instead, could a Copy info button be 
added on the about window that copy the info in the clipboard as a nice 
markdown table ready to paste?





Jean-François Bourdon, ing.f.

Analyste en télédétection

Direction des inventaires forestiers

Ministère des Forêts, de la Faune et des Parcs

5700, 4e Avenue Ouest, local A-108

Québec (Québec) G1H 6R1

Téléphone : 418 627-8669, poste 4304

jean-francois.bour...@mffp.gouv.qc.ca

mffp.gouv.qc.ca



-Message d'origine-
De : QGIS-Developer  De la part de 
Karsten Tebling
Envoyé : 4 janvier 2021 02:40
À : Nyall Dawson 
Cc : qgis-developer 
Objet : 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
___
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] Current script path from python console

[JD L]

Hi devs,

for a long time I used that code to get the __file__ when running

my scripts from the QGis python console. Is there a better way ?

Thxs,

import osfrom console.console import _console

script_path = _console.console.tabEditorWidget.currentWidget().path
print(os.path.dirname(script_path))
___
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] QgsProcessingParameterDateTime with default value

[matteo]

Hi all,

I noticed that even with defaultValue=NULL or defaultValue=None or other 
attempts, QgsProcessingParameterDateTime fills the parameter with the 
current date (or datetime).


Is it possible to have the calendar view empty?

Cheers and thanks

Matteo
___
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

[Nyall Dawson]

On Tue, 5 Jan 2021 at 05:42, Cory Albrecht  wrote:
>
> > 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 hear what you're saying, Nyall, I apologise if it sounded harsh, but what 
> do you want me to say after I find out that the latest of several bugs has 
> compromised my data and now I have to hunt down an unknown number of 
> duplicates silently created over the last few months of work? If you 
> empathise, do you understand how all these bugs and my data being compromised 
> might make me feel that this feature was not done very well and that there 
> was a lack of adequate testing?
>
> > 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?
>
> As to what I would have preferred, well, I've reverted back to 3.10 to use 
> the old TimeManager plugin to avoid using the NTC. I would have preferred 
> that the feature branch you used to implement the NTC had not gotten merged 
> and the feature included in release versions until it had been checked to 
> work with and not break basic features like the selection tool. So now I have 
> to work under some Damoclean time limit for a couple of months until 3.16 
> replaces 3.10 and I will have no choice but to move to a version with the NTC 
> and these bugs.

Full disclosure: I don't even really consider these issues as bugs.
Functionality gaps, yes, but it's important to keep in mind that the
new temporal framework was designed primarily around visualisation of
time based data, and that using it for data analysis has been a
secondary goal which has been slowly chipped away at since the initial
implementation. The selection tool was NEVER broken, it was just never
upgraded to be time aware. There's plenty of features in  QGIS which
don't completely work alongside each other, and these are not always
bugs but often are feature requests.

I'd rather shelve that part of the discussion now, because I suspect
we'll just keep going around in circles here at increasing levels of
emotion, and I don't think that's healthy. I realise there's hurt
here, but I DO think you are a valuable member of this community and
I've much appreciated your previous diligence with submitting quality
tickets. I'd rather move forward and find a way that we can move past
this.

Which leads me to a question: what exactly do you think should have
been done differently here? The way I see it:

1. The temporal framework was in discussion and consultation phases
for years prior to implementation. There were public calls for
comments on the related QEPs, and consultation with all relevant
stakeholders, including representatives from Kartoza (WMS-T), Lutra
(mesh temporal handling), and the Time Manager plugin maintainers.  It
was a group effort which pulled in ALL the expertise and experience of
the QGIS project community.

2. QGIS already has some of the most stringent and rigorous code
review processes around, and the pull requests implementing the
temporal framework were subject to all these processes and peer
review. There's plenty of developers who would attest to how difficult
it is to get code merged into QGIS, due to the very strict coding
guidelines and processes which govern the codebase. I fail to see
anyway we could realistically further tighten these code review
requirements without completely strangling the development of QGIS.

3. If you're asking for the pace of feature development to be slowed
then that problem was addressed years ago when the LTR releases were
introduced. The QGIS website is quite clear in advertising the LTR as
the officially recommended version for stability and for mission
critical work, while the non-LTR releases are clearly branded as
"bleeding edge". I'd make the case that in the situation you've
described you should never have been using the non-LTR release for
this work without doing your full diligence to determine that it
worked correctly in your workflow. And guess what? Most of the bugs
are now fixed in time for 3.16.4, when 3.16 officially becomes the
next LTR release! Again, I can't see how the project can do anything
differently here. In fact, the next LTR (3.16) will even be supported
for a massive 2 year period to ensure even more stable releases are
available for mission critical work.

So I ask again, in the full spirit of reconciliation and moving
forward: what concrete, practical changes do YOU think the project
should make?

Nyall



>
> On Sun, Jan 3, 2021 at 9:32 PM Nyall Dawson  wrote:
>>
>> 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