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

List:       kmail-devel
Subject:    Re: Rewrite of KMail / KMail Filter Idea
From:       Michael =?iso-8859-1?q?H=E4ckel?= <Michael () Haeckel ! Net>
Date:       2000-12-30 21:54:59
[Download RAW message or body]

On Friday, 29. December 2000 23:03, Matthias Grimrath wrote:
> > They could be cleaned out now, since Roberto Alsina finally declared KRN
> > for dead, but that is not that urgent since they have simple the same
> > effect as a comment and they don't use that much lines of code.
>
> It makes the code less readable. A small but unnecessary nuisance. Since I
> am trying my hands on that code now I see no need to keep obsolete code.

If you send a patch for that after KDE 2.1, I'll gladly commit it.

> Yes, but IMHO it tends to be more abused than used. Here are my complaints
> about the current scheme:
>
> a) Everytime a header field is activated/removed, the old QGridLayout gets
> deleted and a new one is constructed. I tested it and it would be
> sufficient to just hide() the widgets. The QGridLayout gets initialized
> once in the constructor and you are done with it.

I think that doesn't happen that often, also your suggestion is probably 
better.

> b) I found code 'if (!mDone) return'. My experience tells me that this is
> +very+ ugly code. It is not obvious when this method actually executes. You
> have to search through the whole file to find out where 'mDone' gets its
> values assigned. If things get worse these assignments are again executed
> conditionally. It's a first step towards spaghetti. If possible, avoid such
> style, and I think it is possible here.

Doesn't the comment in the code make that clear?

> c) 'rethinkHeaders()' is manipulating the widgets' size. This is against Qt
> style where the widgets tell the system about their requirements through
> methods like sizeHint() etc. What I am doing now is deriving my own classes
> from standard widgets with adapted sizeHint() methods.

Ok, it is possibly not perfect.

At least I don't think, that everything has to be rewritten only, because 
someone doesn't like the coding style of someone else.

> > > > same effect. I think I can also make the 'KMComposeWin' calls more
> > > > readable by putting the headerwidgets in some kind of list and remove
> > > > the circular dependency with KMEdit by using signal/slots.
> >
> > I can't see, what is bad with that.
>
> Code (non)reuseability. Suppose someone wants in his/her app the KMEdit
> widget. Now imagine you just have to write '#include <kkmedit.h>' and link
> with kmedit.o. This is not possible now, because KMEdit requires a pointer
> to a KMComposeWin.
>
> Besides, if you look at how that pointer is used, it really screams to be
> replaced by signal/slots. :-)
>
> Now:
> 	mComposer->focusNextPrevEdit(0, false); //take me up
> Later:
> 	emit previousFocus(); // take me up
>
> 	KMComposer::KMComposer
> 		connect(kmedit, SIGNAL(previousFocus), SLOT(focusToSubject()))
>
> (The above code is not thought out, but I hope you get the idea...)

Sorry, I don't. The first version looks shorter. No code is doubled here, but 
I didn't look into KMails code too much to answer this mail.

There are really some things in KMail, that could be better structured or 
otherwise be done better, but I think most problems that were talked about in 
this thread are minor issues. They don't have any effect for the user.

There are IMHO much more important things, that could be improved in KMail. 
For example switching big folder is still a bit slow. Searching could be much 
faster. Downloading mails via pop3 should support pipelining to use the full 
bandwith on slow connections...

A short comment to the filter idea: Wouldn't a filter rule "if 
xxxperl.shell.script returns 1" allow the expert user to do everything he 
wants? The script has to be fed with the message of course.

BTW: I hope it is clear to all, that we are currently in feature freeze and 
everything that does not fix a bug has to wait until after KDE 2.1.

Regards,
Michael Häckel
_______________________________________________
Kmail Developers mailing list
Kmail@master.kde.org
http://master.kde.org/mailman/listinfo/kmail

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