[Graham Bloice <graham.bloice@xxxxxxxxxxxxx>]

On 31 December 2015 at 11:35, Bálint Réczey <balint@xxxxxxxxxxxxxxx> wrote:

2015-12-31 0:10 GMT+01:00 Anders Broman <a.broman58@xxxxxxxxx>:
>
> Den 30 dec 2015 17:01 skrev "Graham Bloice" <graham.bloice@xxxxxxxxxxxxx>:
>>
>>
>>
>> On 30 December 2015 at 10:52, VIKRAM VENKATESH HEGDE
>> <vikram.h@xxxxxxxxxxx> wrote:
>>>
>>> Hi,
>>>
>>>
>>>
>>> Sure, will submit the feature in patches may be will start doing so by
>>> next week.
>>>
>>> Thanks for the support.
>>>
>>>
>>>
>>> Thanks & Regards,
>>>
>>> Vikram
>>>
>>>
>>
>> FWIW, I have a different opinion than Anders regarding the UI.   Qt "is"
>> the Wireshark UI toolkit, GTK is legacy, and Qt is better supported on our
>> target platforms, especially OSX.  I think any new UI development should be
>> for Qt first, then if developer cycles are available, it can be ported to
>> GTK.
>
> As I understand it in this case the GTK code exist and the Qt does not. Not
> accepting it would slow progress and accepting it might speed up the port to
> Qt and sort out any problems or design flaws early. IMHO
I agree that we should not reject UI patches because they improve the GTK+
implementation only.

I would prefer having Wireshark development guided by users' needs and
contributions
rather than pushing devs' choices very hard [1].

Cheers,
Balint

[1] In Debian we have the social contract clarifying that:
...
4. Our priorities are our users and free software
We will be guided by the needs of our users and the free software
community. We will place their interests first in our priorities. We
will support the needs of our users for operation in many different
kinds of computing environments. ...
...
(From: https://www.debian.org/social_contract)

I'm not being hard-nosed about this, just trying to be practical.  The Flows analysis stuff (which looked really interesting to me at SharkFest) seems to be dead because of licencing issues and nobody seems to be stepping up to fix that,

In a volunteer project, any changes rely on the goodwill of the volunteers, both internal and external, and developing code for a UI that we're stated an intention to drop for all (most, RH\Fedora exceptions??) platforms in the future and have dropped already for a major platform (OSX? AFAIK, they don't have a GTK version) is then asking someone else to step up for the porting effort, possibly reducing their ability to effect other improvements.

I don't think it's unfriendly or impolite to ask contributors to follow the aims of the project if possible.

--

Graham Bloice