suggestions sought for a framework for a quick, dirty, really simple GUI prototype

[Shlomi Fish]

Hi,

On Wed, Jul 18, 2012 at 4:33 PM, Meir Michanie <meirm at riunx.com> wrote:
> I wish there was a like button to the email thread.
> Two thumps up, even do I love Perl and I think it is r34dabl3.
> :)

Well, you can always "like" the posts' URL on StumbleUpon:

* http://www.stumbleupon.com/

* http://en.wikipedia.org/wiki/StumbleUpon .

Though it seems a bit redundant marking random mailing list threads like that.

Regards,

-- Shlomi Fish

>
> On Wed, Jul 18, 2012 at 3:28 PM, Gilboa Davara <gilboad at gmail.com> wrote:
>> On Wed, Jul 18, 2012 at 11:50 AM, Oleg Goldshmidt <pub at goldshmidt.org> wrote:
>>>
>>> Hi,
>>>
>>> I have no - literally zero - experience in creating GUIs of any kind. I
>>> face the following task now: there is a C++ program that runs on Linux and
>>> basically receives some packets with some data over the network and does
>>> some transformations on the data. As a result some data structures are
>>> created and updated - potentially many times a second, say, a few times a
>>> second for any *single piece* of data. I need a *prototype* GUI that would
>>> display and constantly update (parts of) those structures, say strings and
>>> numbers with colours and labels and stuff. There may be a need for a
>>> drop-down menu for some configuration - don't know yet. Eventually maybe a
>>> button or two will be added to invoke some actions.
>>>
>>> I figure that the simplest way about it would be to make the GUI run on
>>> the same Linux machine and write it in C++ for ease of integration. What
>>> would be the easiest / simplest framework to use? Is it Qt? Ultimate++
>>> (http://www.ultimatepp.org/ - just one of the things I found in a simple and
>>> brief search)? Since I have no experience it's difficult for me to judge
>>> quickly.
>>>
>>> What is important here is speed and painless ramp-up to some fairly low
>>> level. I want to be up and running as fast as possible with as little coding
>>> as possible. No need for bells and whistles. No need for long term
>>> maintenance. It is for a throw away demo/prototype - and yes, I am sure it
>>> (the GUI part) will be thrown away.
>>>
>>> Any suggestions / experiences / war stories / whatever?
>>>
>>> Thanks in advance,
>>
>>  (Sorry for the long post, I'm writing a very boring code and feel a bit chatty)
>>
>> This might not be the suggesting you're looking for, but hear me out.
>>
>> I write in-kernel C-based DPI software for a living and as such, I
>> rather dislike C++ and the only GUIs I wrote in the past ~15 years are
>> bash scripts that used xdialog and zenity.
>>
>> Long story short (?), we needed a fairly complex GUI to display the
>> output of our system, and needed to do it within ~3 weeks (the life of
>> a startup...) - as I was the only one with some free time, the job
>> landed on my shoulders.
>> Tried Qt, two hours later the police managed to persuade me to get off
>> the roof. pass.
>> (In Qt's defense, I usually start scratching when I see too many
>> templates in one header file; If you're a OO-happy developer YMMV).
>> Tried GTK, felt like re-learning Win32 GDI all over ago, 14 days left, pass.
>> Tried a couple of other options (Tk, etc), but nothing really stuck.
>>
>> Tick tock, tick tock, I could hear the clock.
>>
>> Did some reading and saw a suggestion about Python / PyGTK combo (GTK
>> over Python).
>> Now, I never wrote a single line of Python in my life, but having
>> depleted most of the logical options (Raw X11 is not really an
>> option), I decided to give it a try and... ZING! I liked it. I mean,
>> really liked it.
>> Python is midway between C and C++ and uses the more-or-less the logic
>> and code structure, so I simply dove in. The code itself is very
>> readable (Yep, Pearl, I'm looking at you!), so coding by examples is
>> as strait forward as it gets.
>> Per GUI, the PyGTK API is simple and logical, and the documentation is
>> fairly good (somewhat less if you decide to use PyGI as I did once I
>> got going).
>> Tools are not really needed (I used vim, what else?), though you may
>> want to give glade a try when you build the initial GUI skeleton.
>>
>> In ~3 weeks we had a fairly complex multi-threaded GUI with a binary
>> data conversion, grids, views, tabs, attachments and multimedia
>> support (courtesy of pygtkwebkit and its gstreamer plugins) and as a
>> added bonus, the performance is quite good (far better than, err,
>> Java) and we even managed to add a nice animated splash screen :)
>>
>> Now, I wish I could take credit for being an excellent GUI programmer
>> (I could, but I'm not really into getting struck by a lightning).
>> The credit goes to Python and PyGTK (or actually, PyGI)
>>
>> In short (.......), unless you have a good reason to use C++ or C for
>> this GUI, I'd give PyGTK a chance. You won't be disappointed.
>>
>> - Gilboa "I wish someone could mmap me to the Bahamas" Davara
>>
>> _______________________________________________
>> Linux-il mailing list
>> Linux-il at cs.huji.ac.il
>> http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
>
> _______________________________________________
> Linux-il mailing list
> Linux-il at cs.huji.ac.il
> http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il



-- 
------------------------------------------
Shlomi Fish http://www.shlomifish.org/

Electrical Engineering studies. In the Technion. Been there. Done
that. Forgot a lot. Remember too much.

Please reply to list if it's a mailing list post - http://shlom.in/reply .