Well Rohit , the starting point depends on your knowledge.

There are many qt-gui sinks, for instance

QT GUI sink, QT GUI frequency sink, QT GUI waterfall sink, etc.

The QT GUI sink contains an optional frequency sink , waterfall sink, etc.

But the code the sinks in the QT GUI sink differ from 'standalone'
sinks. From a maintainance point of view it would be great to have a
unified codebase for all those sinks.

But I think creating a unified codebase is hard work.

-- Volker

Thanks Volker  for this example it will be very helpful .

Btw which widget would be good to start with?

Thanks
Rohit

On Tue, Jan 31, 2023, 1:52 PM Volker Schroer <dl1...@gmx.de
<mailto:dl1...@gmx.de>> wrote:

    Hi Marcus,

    thanks for the clarification.

    Maybe this helps:

    Qt Gui sink is an example how to use the designer together with
    gnuradio. You'll find it in qt-gui/lib.

    An example for an oot using the designer can be found in

    github.com/dl1ksv/gr-display <http://github.com/dl1ksv/gr-display>

    -- Volker
     > Hi Volker,
     >
     > I might have gotten my Qt jargon mixed up here :) Yeah I meant QT
     > Designer. Sorry for the confusion!
     >
     > Cheers,
     > Marcus
     >
     > On 30.01.23 17:29, Volker Schroer wrote:
     >> Hi,
     >>
     >> but I think in this case the qt-designer is the tool to to
    design the
     >> widget. I'm curious how, to integrate qt-creator in the build
    process.
     >>
     >> -- Volker
     >>
     >> Am 30.01.23 um 17:11 schrieb Marcus Müller:
     >>> Hi everyone!
     >>>
     >>> Sadly, the reply chain on this email thread got broken, so it's
    probably
     >>> hard for you all to see, but:
     >>> This is about a specific GSoC proposal, which does not at all
    imply that
     >>> you need Qt for every flowgraph.
     >>> Exactly as Rohit describes, this is about making it easier to
    build a
     >>> GUI for GNU Radio flowgraphs *should you decide you want graphical
     >>> visualizations*.
     >>> And if you do so, gr-qtgui is based on Qt, anyways.
     >>>
     >>> Cheers,
     >>> Marcus
     >>>
     >>> On 30.01.23 17:02, Jim Melton wrote:
     >>>> I'd propose that nothing you do *requires* Qt. There are many
    uses for
     >>>> GUI-less flowgraphs. Qt is a heavyweight framework; it should
    not be
     >>>> required in order to build GRC flowgraphs.
     >>>>
     >>>> ---
     >>>> Jim Melton
     >>>>
     >>>>
     >>>> -----Original Message-----
     >>>> From: discuss-gnuradio-bounces+jim.melton=sncorp....@gnu.org
    <mailto:sncorp....@gnu.org>
     >>>> <discuss-gnuradio-bounces+jim.melton=sncorp....@gnu.org
    <mailto:sncorp....@gnu.org>> On Behalf Of
     >>>> Marcus D. Leech
     >>>> Sent: Sunday, January 29, 2023 12:30
     >>>> To: discuss-gnuradio@gnu.org <mailto:discuss-gnuradio@gnu.org>
     >>>> Subject: [EXTERNAL] Re: Qt widgets Improvement
     >>>>
     >>>> On 29/01/2023 14:20, Rohit Bisht wrote:
     >>>>>
     >>>>> I'd like to start with "integrating gnu with qt creator"
    because it
     >>>>> would make it easier to write code in the integrated qt
    environment
     >>>>> and speed up build, run, and testing. I believe adjusting the
    cmake
     >>>>> file and fixing paths to missing library files would be the
    way to go
     >>>>> (though I'll require more directions on that).
     >>>>>
     >>>>> Then "adding new widgets" followed by "improving them" .
     >>>> I guess it depends on what you think the dominant design doctrine
     >>>> should be  "gorgeous UI with the DSP as a kind of afterthought",
     >>>>     or "robust DSP with the UI as a kind of afterthought".   I
    don't
     >>>> think that Qt designer is a particularly productive way to design
     >>>>     the DSP bits of a DSP application.
     >>>>
     >>>> The whole "form is more important than function" is a bit of
    leftover
     >>>> brain-death promulgated by Steve Jobs, and it was as
     >>>>     wrong-headed then as it is now, IMHO.
     >>>>
     >>>>
     >>>>
     >>>>
     >>>> CONFIDENTIALITY NOTICE - SNC EMAIL: This email and any
    attachments are
     >>>> confidential, may contain proprietary, protected, or export
    controlled
     >>>> information, and are intended for the use of the intended
    recipients
     >>>> only. Any review, reliance, distribution, disclosure, or
    forwarding of
     >>>> this email and/or attachments outside of Sierra Nevada Corporation
     >>>> (SNC) without express written approval of the sender, except
    to the
     >>>> extent required to further properly approved SNC business
    purposes, is
     >>>> strictly prohibited. If you are not the intended recipient of this
     >>>> email, please notify the sender immediately, and delete all copies
     >>>> without reading, printing, or saving in any manner. --- Thank You.
     >>>
     >>
     >>



Reply via email to