[Wireshark-dev] File extension is missing on Linux when WiresharkFileDialog::getSaveFileName/QFileDialog::getSaveFileName is used

[Jirka Novak]

Hi,

  I noticed that when I would like to save e.g. diagram exports with
Wireshark (not main dialog Save/Save As), it offers me e.g. .pdf, .ps
and other extensions in save dialog. When I write just name of file and
commit the dialog, created file has correct content (PDF, PS, ...), but
filename is missing extension.
  I tested it and it happens just on Linux, but on every Linux I tested
- multiple distributions from past years. On MAC or Windows it works fine.

  I checked the code and it looks that
WiresharkFileDialog::getSaveFileName calls QFileDialog::getSaveFileName
and it returns just name without extension. I tested it with
QFileDialog::DontUseNativeDialog flag too, but same results.
  Then I compared it with CaptureFileDialog and there is method which
checks whether file extension is there and then adds it if it is missing.
  Therefore it looks like Qt feature and some parts of Wireshark code
are aware of it and fix it and some do not.

  Should I try to modify WiresharkFileDialog to handle it for all cases?

Best regards,

Jirka Novak
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] 16 byte integer decoding

[Constantine Gavrilov]

No.

So the idea is to have a new type FT_UINT128, and one new format 
BASE_BYTES.

The BASE_HEX would display as it displays today -- there is no problem 
printing two  FT_UINT64 in HEX (high and low parts).


For FT_UNIT128 and BASE_DEC, 12 would be displayed as 12,  and 100 
would be displayed as 100. But after a certain digit length, it would 
be displayed as X.YYe+Z.

Similar for BASE_BYTES, 12 would be displayed as 12, and 1048576 would be 
displayed as 1048576. But, after a cretain value, the display would round 
to the units of KiB, or MiB, or GiB, or TiB, etc... Just because these 
values are too long to print.

Sometimes, the spec also says these are units of x10, or , x100, or x1000. 
This can be handled as a scaling factor in the field definion.  If a 
multiplier does not exist, I can add it as well.

--

Constantine Gavrilov
Storage Architect
Master Inventor
Tel-Aviv Storage Lab IDT Lead
Tel-Aviv IBM Storage Lab
1 Azrieli Center, Tel-Aviv
Phone: +972-3-6897318 
Fax:  +972-3-6897230




From:   Guy Harris 
To: Developer support list for Wireshark 
Date:   03/22/2021 11:25 PM
Subject:[EXTERNAL] Re: [Wireshark-dev] 16 byte integer decoding
Sent by:"Wireshark-dev" 



On Mar 22, 2021, at 11:35 AM, Constantine Gavrilov  
wrote:

> There are two repeated patterns for this:
> 
> 1. For capacity (bytes, blocks, etc.).
> 2. For units (how many times).
> 
> So, I am thinking about two formats:
> 1. For bytes.
> 2. For units.
> 
> The implementation would get high and low 64-bits, and compute a 64-bit 
value in units of 10^x (depending on the value) for units, and in units of 
KiB-ZiB (depending on the value) for bytes.

So a value of 12 would be shown as "1.2 deca-XXX" for units, and a value 
of 1 would be shown as "1/1024 KiB bytes" for bytes?
___
Sent via:Wireshark-dev mailing list 
Archives:
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.wireshark.org_lists_wireshark-2Ddev=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=XzHrT4jzZ2lsSkPL8XE51gcxM30kcdBgWfG2QV6bUpw=tQcxqgz5hde146ve9M9j1qhqTetC04DMFRtybs97_8M=OSgT1leFMYub6iWFr_4xCHXLkD-ORYmaPPBkhO_j7KQ=
 

Unsubscribe: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.wireshark.org_mailman_options_wireshark-2Ddev=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=XzHrT4jzZ2lsSkPL8XE51gcxM30kcdBgWfG2QV6bUpw=tQcxqgz5hde146ve9M9j1qhqTetC04DMFRtybs97_8M=2II6jhyUzo3gDG2D4C8Pp4OyRKh1IHGY4buVKQ43nEs=
 

 
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe




___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe