Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] UI Proposal for better Analysis for Android devices

From: Anders Broman <a.broman58@xxxxxxxxx>
Date: Thu, 31 Dec 2015 15:54:28 +0100


Den 31 dec 2015 14:30 skrev "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
>

I basically agree but if the code isn't made public it's not possible to pick it up should the contributor decide porting to Qt is to hard and if there's licencing or other problems with the code it might be better to find that out now rather then after any effort is spent to port to Qt.

I also stated that loosing the functionality will not stop us from deprecating gtk when the time comes which should be an incentive to do a qt version for those that want it.

Just my 2 cents.
Anders

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