Notification Area issues

Here's the place for discussion related to coding in FreeCAD, C++ or Python. Design, interfaces and structures.
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
User avatar
uwestoehr
Veteran
Posts: 4961
Joined: Sun Jan 27, 2019 3:21 am
Location: Germany
Contact:

Re: Notification Area issues

Post by uwestoehr »

uwestoehr wrote: Thu Mar 16, 2023 8:25 pm
Many thanks. This fixes the issue with warnings by copying something to the clipboard.
But it seems this was just a fraction of useless warnings. For example working with FEM is hard because for every new iteration one gets 2 warnings. As a typical analysis has few hundred iterations, the notification area is quickly full:
oH4dCyRy9w.png
oH4dCyRy9w.png (161.05 KiB) Viewed 1009 times
openBrain
Veteran
Posts: 9034
Joined: Fri Nov 09, 2018 5:38 pm
Contact:

Re: Notification Area issues

Post by openBrain »

uwestoehr wrote: Fri Mar 17, 2023 4:46 am But it seems this was just a fraction of useless warnings. For example working with FEM is hard because for every new iteration one gets 2 warnings. As a typical analysis has few hundred iterations, the notification area is quickly full:
Do you run a debug or release build?
wmayer
Founder
Posts: 20241
Joined: Thu Feb 19, 2009 10:32 am
Contact:

Re: Notification Area issues

Post by wmayer »

For example when I make a typical mistake like selecting 2 lines in sketcher and press the radius constraint button.
The Sketcher had too many annoying modal dialogs that always stopped the workflow. If you moved the cursor to the toolbar and clicked a button then the error dialog popped up in the middle of the screen. You then had to move the cursor there, click OK and then back to the toolbar.
With the notification area you immediately see what's wrong and don't have to additionally confirm it.

Another very annoying message is the one that appears when you create a new body and still have selected in element of the old body. The warning dialog says that the object cannot be transferred to the new body. Nevertheless the new body will be created without problems.
Can we therefore please bring this back?
Nothing simpler than that. Go to the preferences > Notification Area > Untick the option Enable non-intrusive notifications
But it seems this was just a fraction of useless warnings. For example working with FEM is hard because for every new iteration one gets 2 warnings. As a typical analysis has few hundred iterations, the notification area is quickly full:
The question is what's the reason for these warnings. To me this rather looks like a bug and should be fixed.
abdullah
Veteran
Posts: 4935
Joined: Sun May 04, 2014 3:16 pm
Contact:

Re: Notification Area issues

Post by abdullah »

uwestoehr wrote: Thu Mar 16, 2023 8:34 pm
abdullah wrote: Thu Mar 16, 2023 7:46 pm Warnings and Errors that are reported should be about FreeCAD. Here, if FreeCAD is too chatty we will have to look into each case.
This is what I want to avoid.
I do not think avoiding it is a sound decision.

If we never tailor errors and warnings to our real needs, we will never have appropriate messages. Hiding them and pretending them not be there... the imagine of my neighbour's toddler comes to my mind covering ears or eyes when he does not want to hear or see. Reality keeps happening. Ignoring reality rarely brings something positive.
uwestoehr wrote: Thu Mar 16, 2023 8:01 pm Therefore the default setting should be as we have it in FC 0.20: warnings are not pop up. Experiences users can enable an option the preferences to show them.
I think that experienced users may be the ones considering not seeing the messages, while newbies should be the ones attentively reading the messages. Otherwise they will never learn. In fact, removing the non-intrusive notifications and making them intrusive (like in 0.20) is possible from preferences. This may be good for newcomers, as their workflow will be stop requiring them to click OK.
chrisb wrote: Thu Mar 16, 2023 8:48 pm If it is wanted, we can probably list some warnings which occur frequently, and should be checked.
Things will probably not change from one day to the other, but I think this functionality opens a window of opportunity to improve the information to users, and fix FC where it needs be fixed.

So yes, we should have some kind of list of "annoying warnings or errors", because this is an indicator that something needs fixing.
uwestoehr wrote: Thu Mar 16, 2023 8:49 pm So the info is hidden at the bottom (not prominent) and even outside of FreeCAD's main window. For me it appears in the Windows task bar and therefore it took me a while to realizes that this is a message from FreeCAD.
I have never seen it outside the frame. This should not happen. Please file an issue.

The location was chosen so that it does not clutter the view and allows a user to keep working. I think it may require some user adaptation to the new location.
uwestoehr wrote: Thu Mar 16, 2023 8:49 pm Also, there is now less info: I get a message what to select, but not why. So it is not clear that I got the message because I made a selection mistake.
Good point. This I will fix in a PR. The information is still there. It is just not being used.
uwestoehr wrote: Thu Mar 16, 2023 8:49 pm The icon in the notifier says it is an info, but this is not just a hint. The action could not be performed because of a mistake of the user, so it is an error.
Oh, we have a discussion about what this actually was. We came to the conclusion that errors and warnings should be FC's errors and warnings and that "user mistakes" should be called notifications.

As for the icon, we can change it. I did not have anything else handy and I am not good at designing.
uwestoehr wrote: Thu Mar 16, 2023 8:49 pm Then people might be annoyed by the popups and turn of the notification. Then they don't get any info at all about the mistake.
I doubt that any experience user, at least with a well functioning NotificationArea would like to go back to having the intrusive pop-ups. However, it is available in preferences.

Because I see your screenshots, I understand that it is not behaving the same for you and for me. It may relate to Windows/Linux differences. This we need to fix.
uwestoehr wrote: Fri Mar 17, 2023 4:46 am But it seems this was just a fraction of useless warnings. For example working with FEM is hard because for every new iteration one gets 2 warnings. As a typical analysis has few hundred iterations, the notification area is quickly full:
FEM uses multiple threads. Only the main thread, which is a QThread, has an event loop. Between QThreads one can "move" a timer. It is no possible to move a QTimer between non-QThreads. Then any QTimer should then be started and stopped on the main QThread.

Please, file an issue in GH how to reproduce this, so that we can identify the cause and fix it.
chrisb
Veteran
Posts: 53919
Joined: Tue Mar 17, 2015 9:14 am

Re: Notification Area issues

Post by chrisb »

FYI: I created an issue concerning a warning: issue #8932.
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
User avatar
uwestoehr
Veteran
Posts: 4961
Joined: Sun Jan 27, 2019 3:21 am
Location: Germany
Contact:

Re: Notification Area issues

Post by uwestoehr »

wmayer wrote: Fri Mar 17, 2023 7:19 am With the notification area you immediately see what's wrong and don't have to additionally confirm it.
The info is missing why you get a notification. But @abdullah already wrote he will fix this.
wmayer wrote: Fri Mar 17, 2023 7:19 am Another very annoying message is the one that appears when you create a new body and still have selected in element of the old body. The warning dialog says that the object cannot be transferred to the new body. Nevertheless the new body will be created without problems.
Yes and this is why I argument not to bother by default users with warnings. They just block the workflow.
Take for example my use case
- I have a running 3D-printing production, I taught colleagues FreeCAD and they created files with it
- all their files work fine, meaning you can create a mesh/STL file and that can be printed.
- some of the files bring the warning "references out of scope" and I got phone calls what this means. In fact you can ignore it because the task to make a print can be fulfilled. Ideally one might want to have a closer look abut the warning. But in real life, the task is what counts:" You can print, fine, so let's do this, there are many other tasks around to be done."

As someone who uses FC for production and taught several persons to use FC in a productive way, I can report that not showing warnings by default improved the workflow a lot. Since FC 0,20 I don't get calls anymore what message X means and if this could be a problem etc. :)

Regarding the warnings, another example. I had to work today on real-life models and I got from time to time this message:

Code: Select all

QGraphicsView::dragLeaveEvent: drag leave received before drag enter
I spent for sure 10 minutes for this and decided to ignore it. But it is super annoying to see such warnings.

So I stay with my opinion, bringing back to output warnings by default worse the workflow.
Don't get me wrong, the notification is per se a cool feature, I am fighting here that it does not output warnings by default.
wmayer wrote: Fri Mar 17, 2023 7:19 am
Can we therefore please bring this back?
Nothing simpler than that. Go to the preferences > Notification Area > Untick the option Enable non-intrusive notifications
Thanks. But you gave valid arguments for the notification area. The point is that for my mistake example, it is very helpful to have a message dialog in the center and forced to move the mouse. I speak here about my experiences with newbies. Once you are more experienced, I understand that a notification is better.

So what about this?:
- non-intrusive notifications are disables by default and experienced users can enable this option
User avatar
uwestoehr
Veteran
Posts: 4961
Joined: Sun Jan 27, 2019 3:21 am
Location: Germany
Contact:

Re: Notification Area issues

Post by uwestoehr »

abdullah wrote: Fri Mar 17, 2023 11:10 am I think that experienced users may be the ones considering not seeing the messages, while newbies should be the ones attentively reading the messages. Otherwise they will never learn.
I come from a productive environment, meaning tasks have to be fulfilled as fast as possible. Nobody has time and will to care for warnings as long as the file does what it should. I think it is a common misconception that developers (I include myself of course ;) ) think users should become experts. At the Brussels conference @chennes reported back that one of the main complaints was that users feel that they are forced to become developers.
I see here the same. References might be out of scope, a dragging operation might have gone wrong or whatever, but as average user it is not relevant. You just need you part to get done.
abdullah wrote: Fri Mar 17, 2023 11:10 am In fact, removing the non-intrusive notifications and making them intrusive (like in 0.20) is possible from preferences. This may be good for newcomers, as their workflow will be stop requiring them to click OK.
Good, this is what I want, as I wrote in my previous post.
abdullah wrote: Fri Mar 17, 2023 11:10 am I have never seen it outside the frame. This should not happen. Please file an issue.
Here it is _always_ below FC's main window -> I will open an issue: issue #8940.
abdullah wrote: Fri Mar 17, 2023 11:10 am Good point. This I will fix in a PR. The information is still there. It is just not being used.
Thanks.
abdullah wrote: Fri Mar 17, 2023 11:10 am Oh, we have a discussion about what this actually was. We came to the conclusion that errors and warnings should be FC's errors and warnings and that "user mistakes" should be called notifications.
OK. I find it confusing but OK if this is by design.
Following this design, the current icon is then the correct one.
abdullah wrote: Fri Mar 17, 2023 11:10 am FEM uses multiple threads. Only the main thread, which is a QThread, has an event loop. Between QThreads one can "move" a timer. It is no possible to move a QTimer between non-QThreads. Then any QTimer should then be started and stopped on the main QThread.
Please, file an issue in GH how to reproduce this, so that we can identify the cause and fix it.
Things like this, (also see my previous post) are one of the reasons why showing warnings by default is a big problem. There are so many warnings that could occur under certain circumstances.
You know me, I report usually all warnings I see, so I am only speaking here for the average user. We as developers should of course take care.

Here is the bug report: issue #8939
abdullah
Veteran
Posts: 4935
Joined: Sun May 04, 2014 3:16 pm
Contact:

Re: Notification Area issues

Post by abdullah »

uwestoehr wrote: Sat Mar 18, 2023 1:11 am I come from a productive environment, meaning tasks have to be fulfilled as fast as possible. Nobody has time and will to care for warnings as long as the file does what it should.
But you just reported that even with FreeCAD working perfectly and generating the STLs for your production line, colleagues would pick up the phone to be reassured the warning was not serious. ;)

How colleagues react depends a lot on their personality and possibly there are also cultural factors, as in average certain cultures tend to ignore if it works, others would want three levels of hierarchical written assurance that a warning it is no problem just in case something happens to avoid liability, yet others just want to do their job at the very best of their possibilities and want to know.
uwestoehr wrote: Sat Mar 18, 2023 1:11 am I think it is a common misconception that developers (I include myself of course ;) ) think users should become experts. At the Brussels conference @chennes reported back that one of the main complaints was that users feel that they are forced to become developers.
I see here the same. References might be out of scope, a dragging operation might have gone wrong or whatever, but as average user it is not relevant. You just need you part to get done.

Things like this, (also see my previous post) are one of the reasons why showing warnings by default is a big problem. There are so many warnings that could occur under certain circumstances.
You know me, I report usually all warnings I see, so I am only speaking here for the average user. We as developers should of course take care.
There is no requirement for users to become developers (though they may do so voluntarily :D).

A professional using a tool must decide the level of expertise he wants to achieve in the tool. Appropriate warnings, errors and notifications are necessary so that a user can decide on the level of expertise to pursue.

Of course, we do not want to have unnecessary warnings, and as developers, with the invaluable help of our power users and regular users, we should strive to avoid unnecessary warnings and properly classify warnings, errors and notifications. However, when an error or warning is there and is legit, not reporting it should not be an option. Yes, it may be that 90% of the times is nothing and can be ignored, yet there may be a 10% of times where it has a impact.

If a warning can systematically be ignored... well it is bad generalising, but there is a strong presumption that it may be unnecessary or perhaps should be changed to a Log category. NotificationArea does not report logs. If we really feel we need yet another category, it could perhaps be added (expertwarning, and make it into preferences). We might be tempted to make optional that the NoficationArea shows warnings (which is feasible but it does not sound right to me).

I think there is value in having well informed users and there is an educational vector to pushing for increased information rather than hide it away. At the end, only users understanding the software well can make effective use of it as a tool, and this is what, I believe, ultimately saves time and is necessary in a production line to boost productivity and ultimately efficiency.

Let it be via training budgets, or via weekly newsletter exchanges, discussions over coffee in a break, or pizza evening, a company or institution making use of FreeCAD should promote that its members understand the notifications, errors and warnings and their impact in their models. If you want the cheeky ending... FreeCAD is for free, so c'mon invest a little bit into your taskforce for your own medium-long term benefit.
User avatar
onekk
Veteran
Posts: 6144
Joined: Sat Jan 17, 2015 7:48 am
Contact:

Re: Notification Area issues

Post by onekk »

From an user point of view, only.

And from my peculiar uses cases, I almost exclusively modelling with scripts.

Non intrusive notifications is a good thing, but errors are errors, warnings are warnings, so maybe an indicator visible somewhere that tells as example:

"task completed with 0 errors and 1234 warnings"

will indicate that:

- from "I need only that the things are working" guys the task is fulfilled

- from "I want a perfect thing and 0 warnings shown" guys some in dept analysis is necessary

How this could be done? Let's discuss it:

- two icons wnd two numbers in status bar an error icon with number of errors and s earning icon with number of warning, you click on it and a popup window with list of warning (a sort of log report) will open and maybe a butyon to "save to file" for future references or bug reports.

- 4 icons and numbers a couple as above regarding "last performed operation" and a couple regarding the whole file / session.

Let apart the analisis and improvement in what should be an error and what should be a warning, as it as to be discussed for every situation what is the optimal behaviour.


Kind regards.

Carlo D.
GitHub page: https://github.com/onekk/freecad-doc.
- In deep articles on FreeCAD.
- Learning how to model with scripting.
- Various other stuffs.

Blog: https://okkmkblog.wordpress.com/
wmayer
Founder
Posts: 20241
Joined: Thu Feb 19, 2009 10:32 am
Contact:

Re: Notification Area issues

Post by wmayer »

uwestoehr wrote: Sat Mar 18, 2023 12:50 am I spent for sure 10 minutes for this and decided to ignore it. But it is super annoying to see such warnings.
As Abdullah already has pointed out ignoring Qt warnings in general is a bad advice. A warning is not printed to annoy the user but is an indication that the API is not used correctly.

Now there are indeed cases where a warning is harmless and can be ignored or cases where we can't do anything about it. That's why I have setup the filter to ignore certain warnings. The next step is to make a list of all Qt warnings and check for each case whether it's something that must be fixed or whether it can be ignored.
Post Reply