[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-pim
Subject:    Re: [Kde-pim] KAddressBook GUI design issues
From:       "Mirko Boehm" <mirco.boehm () comcast ! net>
Date:       2002-10-01 18:26:07
[Download RAW message or body]

<Zitiere wer="Anders Lund">
> On Tirsdag den 1. oktober 2002 15:14, Mirko Boehm wrote:
> <snip>
> So maybe a scrollbar solution would be nice anyways?
Or maybe another widget alignment, smaller images, another tab, whatever.

I was thinking about implementing two different layouts, one for
width>height and one for the other way round.
>> My intention was to modify it to be a details view. Tobias stated that
>> he does not like the idea of detail view implementations that allow
>> the user to modify the selected addressee, but I do like it. In fact,
>> since most displays provide a larger width than height, this should
>> solve the size problems, too, with a little layout work in quickedit.
>
> I like editable views too, so there is a discussion to make. Anyway,
> even not  editable, some views - detail is one of them - needs
> selection/copying  features.
True. I just never thought about it.

> I'm not sure what you mean by "be a details view" - the details view is
> showing details about the current item in a list|card|icon view, and is
> currently displayed in a vertical frame, whereas the addressee editor
> and the  dist list manager seems to work better as horizontal frames.
Agreed for dist list manager. I am not sure about the adddressee editor,
though. Putting the pieces below each other adds the problem that we need
large Y resolution of the desktop, what is usually limited. Especially
with upcoming 16x9 screens or Sony Vaio subnotebooks that have a 1024x600
resolution I think.
...
> Ok, I'll come up with a class that can handle the work and be used as a
> embedded tool view as well as a dialog. That is if noone allready did
> it?  I'll give you a few days to alert me if so:)
Noone did, I think. Have alook at the code, it is very common and does
already share a base. I did not merge both approaches because I did not
want to muddle around in kdelibs/kabc during the beta phase (the dist list
dialog is in kdelibs).
>> > It doesn't seem to provide a minimum width. That's a bug.
>>
>> Remembering the reason ... it is because there is no generic minumim
>> width. It is either undefined or wrong :-) The solution could be to
>> just set some kind of minimum width and use scrollbars.
>
> It needs to calculate the required space during it's paint() or
> loadAddresse()  [whatever it is called] method. <hint>There is a
> QPainter::drawText() variant  that takes a rect which contains the
> measures of the used space when the  function returns.</hint>
You will have to find a "representative dummy entry" for that. Otherwise
it results in flickering resizes.
The code is prepared to do this, it has a "fake painting mode" where it
paints everything on a QPainter and calculates the size.
>> This is the advantage of having different styles that can be developed
>> by different people - we can provide solutions for different taste.
>
> Ok, that just leaves you with a lot of work with that widget...
Oh, no problem here. I like that. But if you want to implement a
QTextView- or whatever based details page I am fine with that. The code to
add it should be easy to understand. See look_basic.h for a start.
I like the option to have different detail styles, it relieves us from
having to find the perfect solution for everybody :-)
CU,
--Mirko.



_______________________________________________
kde-pim mailing list
kde-pim@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-pim
kde-pim home page at http://pim.kde.org/
[prev in list] [next in list] [prev in thread] [next in thread]