From kmail-devel Sun Sep 07 21:52:51 2003 From: Ingo =?iso-8859-1?q?Kl=F6cker?= Date: Sun, 07 Sep 2003 21:52:51 +0000 To: kmail-devel Subject: Re: custom header view X-MARC-Message: https://marc.info/?l=kmail-devel&m=106297166320089 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============97025447825222022==" --===============97025447825222022== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_+i6W/baJomGocff"; charset="iso-8859-1" Content-Transfer-Encoding: 7bit --Boundary-02=_+i6W/baJomGocff Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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 =3D) ... > > > > 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 =3D) I don't agree with Aaron that the other header styles are unnecessary.=20 The important difference between the different header styles is=20 actually the appearance of the header and not the fact that some styles=20 show more information than other styles. OTOH, I think we can probably reduce the choice to a "plain" style (like=20 the currently used "standard" or "long") and a "fancy" style. We don't=20 need a "custom" style. Both, the "plain" and the "fancy" style should=20 be customizable. Maybe we should also keep the "brief" style because else some users=20 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:=20 I'm too lazy) to hack the code myself just in order to compare what=20 looks better. BTW, the "More headers..." should be in a much smaller size than the=20 normal font size so that it's not too obtrusive. > > 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=20 knowledge). > > "go back" is a bit misleading, since one isn't really "going back" > > =3D) 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=20 like "Show only selected headers". > > 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=20 the mailing list that he didn't CC to you). > 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=20 thesis which needs to be finished next week or so. Regards, Ingo --Boundary-02=_+i6W/baJomGocff Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux) iD8DBQA/W6i+GnR+RTDgudgRAqq6AJ48KpmaLE11u6/bxXUjnlC2G/a8xACfaHFY 1k7YJk1cLxTw0BJvcByS5jo= =j0Hx -----END PGP SIGNATURE----- --Boundary-02=_+i6W/baJomGocff-- --===============97025447825222022== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ KMail Developers mailing list kmail@mail.kde.org http://mail.kde.org/mailman/listinfo/kmail --===============97025447825222022==--