bino-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bino-list] GUI polishing


From: Martin Lambers
Subject: Re: [Bino-list] GUI polishing
Date: Sun, 24 Apr 2011 14:17:47 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8

Hi Joe!

On 24/04/11 02:53, Joe wrote:
>> I think all the current GUI can be created using Designer and I want to
>> prove it :-) 
> 
> I could not sleep so first attempt of Bino in Designer is attached. It is 
> whole 
> main window including icons, menu, content of input/output combo boxes and 
> even video_output_qt_widget (Designer support custom widgets from different 
> files).
> 
> There are no tooltips and no signals defined yet, but both are just 
> copy/paste. 
> So what do you say? Should I prepare testing patch with main window generated 
> from Designer UI file?

OK, I see the VLC Qt4 module uses Designer, and they have a very
flexible and configurable GUI, so apparently Designer can do that if one
knows how.

Still, I personally see no reason to move to Designer - everything can
be done in source code directly.

I would place the following strict conditions on a move to Designer
(please protest if you think they are not justified):

- There must be real advantages of moving to Designer, and these
advantages must be worth the trouble.
Rationale: you don't throw away a working solution without very good
reasons.

- There must be a significant development force that is convinced that
moving to Designer is the right thing to do.
Rationale: those who do the work decide how it should be done.
Currently, I do most of the coding, and I prefer source code editing. If
we move to Designer, then there must be enough developers who prefer
Designer and who take over GUI development and maintenance permanently.
If in the long run it turns out that I still need to do most of the
development and maintenance work, I'll move back to source code.

- There must be a fully functional, complete, clean, and reasonably
bug-free Designer-based GUI before it can be merged.
Rationale: if the development drive behind a move to Designer is not
strong enough to reach that point, then there's no hope that it would
work in the long run.

- If at any point there is something the GUI reasonably should do but
Designer does not let us do, then we move back to source code.
Rationale: we should not introduce dependencies on tools that limit our
flexibility. This includes Qt itself: Qt code should be restricted to
the GUI only so that we have the option to go with different GUI
toolkits later, if the need arises.

Martin



reply via email to

[Prev in Thread] Current Thread [Next in Thread]