bino-list
[Top][All Lists]
Advanced

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

Re: [Bino-list] GUI polishing


From: Joe
Subject: Re: [Bino-list] GUI polishing
Date: Sun, 24 Apr 2011 21:05:32 +0200
User-agent: KMail/4.6 beta5 (Linux/2.6.38-gentoo; KDE/4.6.0; x86_64; ; )

Hi Martin!

> 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.
My task is to convince you to like Designer :-) I also preferred in-code GUI, 
but I've spent many hard hours while modifying existing in-code GUI. On the 
other hand in Designer it is just few clicks.

> - 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.
Remake is practically done. In one hour all the remaining dialogs can be 
easily converted.

> - 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.

I understand your resistance to having GUI in Designer. However I think GUI 
logic should be separated from GUI definition. If you could just look at the 
attached patch that transfer main GUI to Designer together with incorporating 
GUI compilation in autoconf/automake. I think all the GUI is completely 
identical and a lot of hard to maintain code is now gone and can be 
comfortably modified using graphical editor. The justification for move can be 
this git stat:

 src/player_qt.cpp |  530 +++++++++++++++-------------------------------------
 1 files changed, 153 insertions(+), 377 deletions(-)

Well ... just take a look and decide if you like it. The attached patch 
applies cleanly to 6df88a12e3807b5ad97d6eb2928332b5ce4a8271 (without scaled 
seek buttons)

Bye,
Joe.

Attachment: designer_remake.patch
Description: Text Data


reply via email to

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