Wireshark-dev: Re: [Wireshark-dev] RTP player - a suggestion

From: Erik de Jong <erikdejong@xxxxxxxxx>
Date: Tue, 2 May 2017 19:58:22 +0200


On Tue, Mar 28, 2017 at 9:44 AM, Alexis La Goutte <alexis.lagoutte@xxxxxxxxx> wrote:


On Mon, Mar 27, 2017 at 9:33 PM, Jirka Novak <j.novak@xxxxxxxxxxxx> wrote:
Hi,

>> I disagree.  Right now, the GTK RTP player is the only one that I consider usable.  By comparison, the Qt RTP player only barely works, and is unusable if you're dealing with more than one stream.  If these changes can improve the Qt >version to be about as good as the GTK version was/is, then perhaps breaking the GTK version is okay.  But don't break/remove the GTK version *and* leave the Qt version less than fully functional.
>> --
>> Peter Budny
>
> My thinking is that if fixing the Qt version without too much work means ditching the GTK version that is OK in the development track as the GTK version is still available in older
> Versions. Hopefully a usable Qt version would be available before the next release.

I understand Peter, but I'm afraid it is not possible to change Qt code
without touching GTK. The reason is that both depends on common files in
ui/ (ui/rtp_stream, ui/tap-rtp* etc).
When I started to work on Qt, it induced changes in common ui/ code and
as consequence I broke GTK code.

I might be wrong because my additional aim was to write common code for
RTP analysis too (when you check the code for RTP analysis, you will
again find multiple places with same functionality - GTK, Qt and
TShark). Therefore I had to touch code in common ui/ directory more
often than just RTP player related changes might require.

On the other hand, I'm really afraid that changes for Qt will induce
changes for GTK. The option could be copy all related ui/ files and
split them for GTK and Qt.
But I'm not sure whether it is good approach.
For me, it can be a valid approach because we can to remove GTK... (in next release GTK is disable by default and i think for 2018, we remove GTK support...)

I'm afraid this thread kind of silently died, looks like it's a difficult thing to tackle ;-)

In my opinion my suggestion earlier (https://www.wireshark.org/lists/wireshark-dev/201703/msg00073.html) is the least invasive way to go about this. It won't harm legacy users and will promote code reuse.
 

                                        Sincerely yours,

                                                Jirka Novak

___________________________________________________________________________
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@wireshark.org?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@wireshark.org?subject=unsubscribe