[João Valverde <j@xxxxxx>]

    I see. I think Qt translations should be used for the UI only. If
    you are going to do translation for this (a big if) it would be
    better to do the translation in libwireshark so any libwireshark
    user (like tshark) can benefit from that. The cost of translation is
    95% to find a translator and only 5% to set up and maintain the
    infrastructure.

On 04/04/22 15:51, Roland Knall wrote:

No, I dont want to present the error code to the user. But if you create the error string in C we cannot translate it into other languages with the Qt translation system. Therefore I would prefer passing an enum or just codes and we host the error strings on the C++ side, where they can be properly translated. The user won'T get to see them.

I am working on an update for the textfield anyhow, this will tie into that nicely

Am Mo., 4. Apr. 2022 um 16:39 Uhr schrieb João Valverde <j@xxxxxx>:

A tool window console that stays hidden by default is probably a good idea.

Error codes on the other hand are a throw-back to Windows 95. Dial 1-800-SHARK to translate your error code to human readable string. :-P

On 04/04/22 15:19, Roland Knall wrote:

Sorry, that seemed to be a tippo on the phone. toolwindow was the term I was looking for. 

Actually, for a system that sensitive I would only report an error code. Those messages need translations and we do not have that on the c-side of things. Also, usually, error messages like that get not displayed in the textbox, but rather as a popup hint/toolwindow, which I was referring to.

But I am very much for making the errors more clear, and maybe also providing a line position to highlight where the error began

Am Mo., 4. Apr. 2022 um 16:12 Uhr schrieb João Valverde <j@xxxxxx>:

Not sure what rtoolwindow is.
 
My idea is that the filter compiler can emit errors, deprecations and warnings/suggestions, of which only the first too should be intrusive (displayed in the filter entry box in red/yellow). To see all messages the user would have to click a button to open a second level with some sort of console (which could also find uses to display runtime errors like integer overflow and division by zero).
 
The change in AND/OR precedence is in [1].
 
[1]https://gitlab.com/wireshark/wireshark/-/merge_requests/6598

On 04/04/22 10:39, Roland Knall wrote:

I think the system may be improved by advising the user via a rtoolwindow in the entry dialog, on how to properly stack the operators. I am currently looking into that. But at the very least, the release notes should be updated to contain a note on this.

cheers

Am Mo., 4. Apr. 2022 um 09:59 Uhr schrieb Guy Harris <gharris@xxxxxxxxx>:

On Apr 3, 2022, at 5:25 PM, João Valverde <j@xxxxxx> wrote:

> I removed the "parenthesis around && within ||" warning/suggestion in [1], then noticed the precedence of AND and OR is flipped from most programming languages, then found [2].
>
> The consensus seemed to be in favor of being consistent with the rest of the world, but in the end it wasn't done.
>
> Should AND have higher precedence than OR?

Yes, especially if, as I seem to remember Gerald indicating would be the case, the next release will be 4.0 rather than 3.8.  That's the order in C, and presumably in languages that follow "C" with one or more characters from the top row of the keyboard :-), as well as those preceding "C" with the word "Objective" :-), as well as Java, Perl, Python, Lua and BPF filters.

We should probably mention this very notably in the documentation, including the release notes, and recommend that people use parentheses in all packet-matching expressions that use both AND and OR.

We may want to have some sort of warning (with the different UI design) as well.
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe