[bt-devel] Eliminate KFontChooser from Configuration Dialog

Eeli Kaikkonen eekaikko at mail.student.oulu.fi
Wed Nov 19 04:28:10 MST 2008


Quoting Gary Holmlund <gary.holmlund at gmail.com>:

>
> I did take a lot of space out of the dialog because I thought the
> small height was a requirement. As you had put it, "even 800x480
> minus the desktop panel". I was not very happy with the result and
> had thought we might need to discuss a redesign of the layout

This was really my mistake - I should have said this is more like a
final future goal than an initial request. Sorry about the extra work.
I have a bad habit of "thinking aloud" and not telling that it's not a
fixed opinion or a roadmap. You can always ask before starting
anything time consuming.

> Interesting. I did not know that the Vista guidelines had changed
> so much from the XP guidelines. Title case would have been correct
> for the font chooser headings under Xp. I will plan to use the BT
> guidelines.
>
>> But back to the real thing. I tried to write a new structure but it's
>> very hard. Here's one proposition:
>>
>> Text view
>>     - Display templates (tab)
>>     - Text filters (tab)
>>     - Fonts (tab)
>> Default works
>> General
>>     - Bible book names (group)
>>     - Startup logo (group)
>>
>> But I don't think it's perfect. "General" is never a good name. This
>> structure doesn't necessarily reflect the way a user would think about it.
>>
>>
> This seems reasonable or perhaps the General group should be
> split as follows:
>
> Text view
>     - Display templates (tab)
>     - Text filters (tab)
>     - Fonts (tab)
> Default works
> Bible books
> Startup

That has some merits over the other one, but on the other hand a page
with only one checkbox looks a bit stupid. Looking at most of the PC
applications, designing a configuration dialog seems to be one of the
hardest jobs...

>
> I think a redesign like this could be done in the next two weeks


I would rather leave it in the current state, except the Languages
page. As Martin said in a previous post, we can't continue
adding/changing features for ever but have to complete the porting
work. It's much more fun to create something new and honestly I
wouldn't have had interest and patience enough to do nothing else than
only port code to Qt4. Therefore some of my feature changes and
restructurings have been almost necessary for myself. Now I have to
repent from that and start real work again :) But I want this to be
fun for everyone, so you are free to share ideas. If you really want
to do something, go ahead (but only if the final outcome is acceptable
for us/users and good for BibleTime).

> if I use Qt
> Designer. It is much easier to design these nested layouts visually and the
> amount of hand written code is much smaller. It also makes it easy to get
> re-sizable dialogs. Is there any reason not to use Designer?

I have found Designer invaluable, but only for fast visual design.
Eventually I have taken the code from the generated classes and put
them into files manually. The reasons are:
      - you can't do everything with Designer anyways
      - the class/file structure will be more complicated with Designer
because you have to subclass
      - you would have to add files to cmake with a special mechanism
      - you don't have easy direct access to elements in the manual part
      - you can't name layouts
      - it's hard to mix member and local variables (for example  
layouts are usually better to create locally, there's no need to  
access them as object members)
      - Designer creates much unnecessary, not so clean code
      - if you want to make a small change you may have to redesign the
whole UI and write the manual part again
      - and probably other reasons which I don't remember/don't know yet

It was really good when I started with Qt GUI classes and it's still  
very good for initial work when creating new widgets/dialogs. When I  
have gained more experience I have learned to do some things directly  
in code. And I feel it's better to use only manual code in our project.


--Eeli Kaikkonen




More information about the bt-devel mailing list