Re: [Wireshark-dev] [Wireshark-commits] rev 42038: /trunk/ui/gtk/ /trunk/ui/gtk/: main_proto_draw.c
That does look better. I knew there must be a better way :) On Thu, Apr 12, 2012 at 5:56 PM, wrote: > http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=42038 > > User: darkjames > Date: 2012/04/12 02:56 PM > > Log: > Simplify r42030 expression. Thanks! > > Directory: /trunk/ui/gtk/ > ChangesPath Action > +1 -1 main_proto_draw.cModified > > ___ > Sent via:Wireshark-commits mailing list < > wireshark-comm...@wireshark.org> > Archives:http://www.wireshark.org/lists/wireshark-commits > Unsubscribe: https://wireshark.org/mailman/options/wireshark-commits > mailto:wireshark-commits-requ...@wireshark.org > ?subject=unsubscribe > ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] QtShark Translation
Hi Jaap,
On Thu, Apr 12, 2012 at 8:50 PM, Jaap Keuter wrote:
> Hi,
>
> Do we really want to allow for a translation of the program name?
>
> r41389:main_welcome.cpp:
>
> QString banner = QString(tr("Wireshark"));
>
Mmh Yes ! for the next 1st April ;-)
Fil de Requin is a good name ? ;-)
>
>
> Thanks,
> Jaap
>
>
> On 03/04/2012 08:21 PM, Alexis La Goutte wrote:
>
>> Hi,
>>
>> I realized a patch to add the i10n version of QtShark. The goal is only to
>> translate the Gui (not dissector)
>> Actually, there is only a french translations !
>>
>> To test, launch qtshark with LANG=fr ./qtshark (in ui/qt folder)
>>
>> For make your own translation! it is easy !
>>
>> * Add your translation (wireshark_XX.ts) in QtShark.pro
>> * Launch lupdate QtShark.pro to generate/update your translation file
>> * Translate with Qt Linguist
>> * Launch lrelease QtShark.pro to create/update wireshark_xx.qm file
>>
>>
>>
>> More information about Qt Translation is available in
>> http://qt-project.org/doc/qt-**4.8/linguist-manual.html
>>
>> It missing some feature :
>> * Add preference to select(force) your language
>> * Support of Cmake
>> * Some text it is no available for translation...
>>
>> Regards,
>>
>>
>>
>
___
Sent via:Wireshark-dev mailing list
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Static analysis and FT_STRING encodings
On Thu, Apr 12, 2012 at 2:33 PM, Guy Harris wrote: > > On Apr 12, 2012, at 10:47 AM, Evan Huus wrote: > > > 2. Most dissectors add FT_STRINGs with an encoding value of 'ENC_ANSII | > ENC_NA'. Based on the comments in epan/proto.h this doesn't make sense > (they should be 'ENC_ASCII' only?), > > Which comments? > The comment for ENC_NA reads as: * For protocols (FT_PROTOCOL), aggregate items with subtrees (FT_NONE), * opaque byte-array fields (FT_BYTES), and other fields where there * is no choice of encoding (either because it's "just a bucket * of bytes" or because the encoding is completely fixed), we * have ENC_NA (for "Not Applicable"). My interpretation of this is that it's not *wrong* to say 'ENC_ASCII | ENC_NA', but simply redundant. I've been reading ENC_NA as "endianness is irrelevant but we need a placeholder here". Since ENC_ASCII implies everything we need to know about byte order, adding an ENC_NA isn't really useful. We currently have no ENC_UTF_16, but, when we do, it would have to be ORed > either with ENC_BIG_ENDIAN or ENC_LITTLE_ENDIAN, so, at least for some > character encodings, a byte-order specification would make sense. > Agreed. > ASCII has no byte-order issues, and the convention is that ENC_NA is used > to explicitly indicate that the byte order is not applicable. > But, as above, we already get that from the fact that it's ASCII in the first place. If the agreed style is to be explicit in these cases, that's fine, but then that should be made clearer in the comments. (As an aside, I'm assuming based on this that the few places which do 'ENC_ASCII | ENC_BIG_ENDIAN' or 'ENC_ASCII | ENC_LITTLE_ENDIAN' are actually wrong?) The comment for ENC_NA should probably be updated to reflect that. > Yes, a clearer comment would help. Appending the following to what's already there would be good: "For encodings (such as ENC_ASCII) where the encoding already specifies the byte order (or lack thereof), ENC_NA should be explicitly ORed in for completeness." > and they cause CppCheck to complain because both ENC_s are #defined to 0 > (which makes or-ing them a no-op). > > On occasion, C/C++/etc. programmers might have values that consist of > multiple bitfields and that valid values of those types might have more > than one of said bitfields with values of 0, and therefore that there are > legitimate reasons to OR together various constants that happen to be 0. > ENC_ values happen to be one of those occasions. > True. Given that, for cppcheck, "The goal is no false positives." > > > http://sourceforge.net/apps/mediawiki/cppcheck/index.php?title=Main_Page > > they either need to stop warning about that or provide a way to control > which cases of ORing 0's together to warn about. > They do provide a way to control that warning. I just wasn't sure if it was right to filter those instances or not. Now that I know, I can adjust the CppCheck parameters accordingly. Thanks, Evan ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] QtShark Translation
Hi,
Do we really want to allow for a translation of the program name?
r41389:main_welcome.cpp:
QString banner = QString(tr("Wireshark"));
Thanks,
Jaap
On 03/04/2012 08:21 PM, Alexis La Goutte wrote:
Hi,
I realized a patch to add the i10n version of QtShark. The goal is only to
translate the Gui (not dissector)
Actually, there is only a french translations !
To test, launch qtshark with LANG=fr ./qtshark (in ui/qt folder)
For make your own translation! it is easy !
* Add your translation (wireshark_XX.ts) in QtShark.pro
* Launch lupdate QtShark.pro to generate/update your translation file
* Translate with Qt Linguist
* Launch lrelease QtShark.pro to create/update wireshark_xx.qm file
More information about Qt Translation is available in
http://qt-project.org/doc/qt-4.8/linguist-manual.html
It missing some feature :
* Add preference to select(force) your language
* Support of Cmake
* Some text it is no available for translation...
Regards,
___
Sent via:Wireshark-dev mailing list
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Static analysis and FT_STRING encodings
On Apr 12, 2012, at 10:47 AM, Evan Huus wrote: > 2. Most dissectors add FT_STRINGs with an encoding value of 'ENC_ANSII | > ENC_NA'. Based on the comments in epan/proto.h this doesn't make sense (they > should be 'ENC_ASCII' only?), Which comments? We currently have no ENC_UTF_16, but, when we do, it would have to be ORed either with ENC_BIG_ENDIAN or ENC_LITTLE_ENDIAN, so, at least for some character encodings, a byte-order specification would make sense. ASCII has no byte-order issues, and the convention is that ENC_NA is used to explicitly indicate that the byte order is not applicable. The comment for ENC_NA should probably be updated to reflect that. > and they cause CppCheck to complain because both ENC_s are #defined to 0 > (which makes or-ing them a no-op). On occasion, C/C++/etc. programmers might have values that consist of multiple bitfields and that valid values of those types might have more than one of said bitfields with values of 0, and therefore that there are legitimate reasons to OR together various constants that happen to be 0. ENC_ values happen to be one of those occasions. Given that, for cppcheck, "The goal is no false positives." http://sourceforge.net/apps/mediawiki/cppcheck/index.php?title=Main_Page they either need to stop warning about that or provide a way to control which cases of ORing 0's together to warn about. ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] Static analysis and FT_STRING encodings
Hi all, This is my first post to the list, I just joined, so please be kind in pointing out the numerous mistakes I'm sure to make :) While I've been working with Wireshark for a while now already, this is my first foray into actual upstream development. I wrote a couple of custom dissectors for a co-op placement last year, and have subsequently started caring for bug reports in Ubuntu (many thanks to Balint Reczey, the Debian maintainer, for some help there). Now I feel I'd like to contribute a little more. I've read a bunch of documentation and checked out the Wireshark trunk. To get my feet wet, I started running CppCheck Static Analyzer [1] on the source. It's reported lots of interesting (but mostly quite minor) problems so far, but it's also raised a few questions: 1. Based on the documentation, the correct way to submit code normally is to file a bug and attach a patch for each unrelated issue. Given that so many of the CppCheck-reported issues are minor, one-line fixes, is it acceptable to file a single bug (with patch) for a group of issues, simply to save on bug spam? 2. Most dissectors add FT_STRINGs with an encoding value of 'ENC_ANSII | ENC_NA'. Based on the comments in epan/proto.h this doesn't make sense (they should be 'ENC_ASCII' only?), and they cause CppCheck to complain because both ENC_s are #defined to 0 (which makes or-ing them a no-op). Since 99% of the dissectors do it there must be a reason, but I can't for the life of me figure out what it is. I'm sure I'll have more questions in a few days, but I'll hopefully also have some patches to submit by then! Thanks, Evan [1] http://sourceforge.net/apps/mediawiki/cppcheck/index.php?title=Main_Page ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Adding features in VOIP analysis
libmysqlclient-dev, obviously in linux/unix/BSD This feature will be a nice one i think. mysql c library is quiet stable and used in various opensource products. another note does wireshark has a script engine to support scripted plugins? like many other big projects(openoffice supports python, something like that) On Wed, Apr 11, 2012 at 10:02 PM, Graham Bloice wrote: > > > > -Original Message- > > From: wireshark-dev-boun...@wireshark.org [mailto:wireshark-dev- > > boun...@wireshark.org] On Behalf Of Guy Harris > > Sent: 11 April 2012 16:52 > > To: Developer support list for Wireshark > > Subject: Re: [Wireshark-dev] Adding features in VOIP analysis > > > > > > On Apr 11, 2012, at 4:37 AM, Arif Hossain wrote: > > > > > Ok, what about exporting to mysql database instead of CSV? > > > > (Perhaps better stated as "in addition to CSV", in that you won't be > > *removing* the ability to export to CSV.) > > > > > This is a worthy addition i guess. > > > > Yes, as long as it doesn't have a schema hardcoded into it; I doubt > everybody > > who would want stuff exported to a database would want the exact same > > schema. > > Presumably this will create a dependency on a sql client library somewhere. > What platforms do you intend to support with this? > > > ___ > Sent via:Wireshark-dev mailing list > Archives:http://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe > ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
