[Kget] transfer status

Felix Berger bflat1 at gmx.net
Thu Feb 24 19:00:46 CET 2005


Hi,

two points of criticism as far as the transfer states are concerned:

You have write three lines of code to set a new state and notify listeners of 
it:

  tInfo.status = ST_Trying;
  setTransferChange(Tc_Status);
  emit transferChanged(this);

I'd suggest to provide just one (protected) change function that emits the 
signal. If necessary the signal could be suppressed depending on an optional 
boolean parameter at the end. I also don't see why the transfer change has to 
be so fine grained to report the kind of change.

void setTransferChange(int newState, const QString& stateString, bool 
emitSignal = true)
{
 tInfo.status = newState;
 if (emitSignal) {
  emit changed(this);
 }
}

Second point:

The list of states is limited and will always be, for example bittorrent has a 
state "hashing". That's why I would suggest only managing the states that are 
important from the outside (i.e. user interface), like active, stopped, or 
better resumable, stoppable,removable etc. So the userinterface knows what 
actions it can offer.

ST_Trying is not an important state for the userinterface and should be opaque 
from the outside. I'd rather have a status string I can set from the subclass 
like:

setTransferState(Stoppable|Active, i18n("Downloading..."));

or

setTransferState(Stoppable|Active, i18n("Hashing..."));

or

setTransferState(Resumable|Inactive, i18n("Paused"));

The last one is a direct reaction to a user action so it should maybe handled 
in the userinterface to guarantee the same state string everywhere though.

Another point: What's the advantage of providing the Info struct inside of 
Transfer, since it's not hidden in the cpp file, it doesn't help to keep 
binary compatibility for future versions and from a first glance it looks 
like a 1:1 relation between info and transfer. Am I missing something?

Felix

-- 
Try Debian GNU/Linux!
http://www.felix.beldesign.de/



More information about the Kget mailing list