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

List:       kmail-devel
Subject:    Re: custom header view
From:       Klas Kalass <klas.kalass () gmx ! de>
Date:       2003-09-08 20:35:40
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


Am Sonntag, 7. September 2003 23:52 schrieb Ingo Klöcker:
> On Saturday 06 September 2003 01:28, Klas Kalass wrote:
> > Am Dienstag, 2. September 2003 22:03 schrieb Aaron J. Seigo:
> > > On Friday 29 August 2003 05:28, Klas Kalass wrote:
> > > > I made a patch to make the visible header fields in the reader
> > > > configurable. The patch is attached and screenshots can be found
> > > > at http://www.kalass.de/kmail/index.html
> > >
> > > i just compiled it and have tried it out... i haven't looked at the
> > > code in detail yet (just skimmed through it), so i won't comment on
> > > that (yet =) ...
> > >
> > > first, this is great ... i think it makes a lot of sense as a
> > > mechanism ... personally, i'd propose that this feature (which is
> > > on the feature list, btw) is polished up and the other header
> > > styles removed from the code as they are then unecessary ... this
> > > would get rid of the View -> Headers submenu as an extra bonus... i
> > > think there's a comment in your patch to a similar affect =)
>
> I don't agree with Aaron that the other header styles are unnecessary.
> The important difference between the different header styles is
> actually the appearance of the header and not the fact that some styles
> show more information than other styles.
>
> OTOH, I think we can probably reduce the choice to a "plain" style (like
> the currently used "standard" or "long") and a "fancy" style. We don't
> need a "custom" style. Both, the "plain" and the "fancy" style should
> be customizable.
I agree - the question is wether people will find "More headers..." disturbing 
when it is always there.

> Maybe we should also keep the "brief" style because else some users
> might be pissed if it's gone.
>
> > > some comments on the interface:
> > >
> > > "More..." should perhaps be "More headers..." and aligned with the
> > > header data rather than the header titles, e.g.:
> > >
> > > Date: 2003 05:28:31
> > >        More headers...
> >
> > What is the general opinion on this? I will change it when there is a
> > consensus.
>
> Could you please create two screenshots. I don't have the time (read:
> I'm too lazy) to hack the code myself just in order to compare what
> looks better.
>
> BTW, the "More headers..." should be in a much smaller size than the
> normal font size so that it's not too obtrusive.
I will make the screenie - but that might take a few days (I don't have the 
time but am not too lazy ;-) )

>
> > > the checkbox icon for adding a header isn't very intuitive, as you
> > > noted. using some simple text such as "Always show: " might help...
> > > or perhaps have that as a header and use checkboxes to mark which
> > > ones to always show (don't know how easy / possible it is to use
> > > form elements in the readerwin, though)...
>
> Using forms in messages is currently impossible (to the best of my
> knowledge).
Yepp - that was my first try but it is impossible because there is some code 
in khtml previnting forms functionality for the options set by kmail.

>
> > > "go back" is a bit misleading, since one isn't really "going back"
> > > =) if one uses "More headers..." then perhaps "go back" could
> > > become "Fewer headers..." or "Less headers..." or "Collapse
> > > headers..."
> >
> > Well, blame Ralf Nolden for that - Originally I had simply "less" and
> > he complained about it, so I changed it to "go back" to make him
> > happy. Personally I don't care, as long as I get reasonably backed
> > arguments I will change it to anything ;-)
>
> I agree with Aaron that "go back" is bad wording. I propose something
> like "Show only selected headers".
see reply to Aaron

>
> > > also, it seems just by looking at it in usage that it redisplays
> > > the whole email whenever a header edit link is clicked (via a call
> > > to updateReaderwin ()) ... perhaps it would be better to provide a
> > > named div in the headers area and simply edit that section of the
> > > HTML directly, allowing KHTML to just rerender that section rather
> > > than the whole readerwindow. this would decrease flicker, increase
> > > responsiveness and make a huge difference if you have a large
> > > attachment being viewed inline or some other part of the mail
> > > display process requires a lot of processing...
> >
> > I am not sure if that is possible - I think I would need to alter the
> > dom tree which is displayed by khtml for that, don't I? I don't have
> > the code here at the moment so I don't know if I could access it
> > without doing hacks.
>
> It would be cool if you would try what Aaron wrote (in the message to
> the mailing list that he didn't CC to you).
Yes, will try - thanks for pointing me there.

>
> > At N7H I got positive feedback from Don, Ingo, Till and Zack, but I
> > would especially like to hear comments from Marc because my code is
> > based on his work - so what do you think, Marc?
>
> Don't expect a quick answer from Marc. He's busy writing his diploma
> thesis which needs to be finished next week or so.
Oh, I am lucky then  - I got something like 3 weeks left for mine...

Regards,
  Klas

[Attachment #5 (application/pgp-signature)]

_______________________________________________
KMail Developers mailing list
kmail@mail.kde.org
http://mail.kde.org/mailman/listinfo/kmail


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

Configure | About | News | Add a list | Sponsored by KoreLogic