Archive for March, 2006

Sorting favorite hubs (part two)

Thursday, March 30th, 2006

While reading/writing the comments in a previous post, I remembered something that’s of importance for the “no, we won’t add a sorting possibility” argument.

The favorite hubs work in a way that may not be very intuitive, but you’ll have to get used to it since it’s here to stay…

When you add a new hub to favorite hubs, there’s a check that validates if the hub address entry already exist or not. If it exist, a box will popup and say ‘Hub already exists as a favorite’ (my wording, yay!). Now, this box will only popup if you enter a hub address that already exist (if you try and not enter anything, another box will popup…). If you enter a hub address that’s gibberish, and when it’s created change the hub address, there will be no popup. (One could argue there should be, but what until I explain further.)

If you create two favorite hub entries, with the same address but with different nick names (multiple accounts for instance) you will only be able to use one of the nick names. This is because DC++ will always choose the nick name for the hub that’s highest in the list.
Nick: Name1 Password: pwd Address:
Nick: Name2 Password: pwd Address:
No matter how many times you wish to enter the hub with ‘Name2′, you will never as long as ‘Name1′ is higher up on the list.

Toggling and re-sizing (part two)

Thursday, March 30th, 2006

I realized after the last post, that the behaviour experienced with the userlist can be experienced in other places. (The behaviour being that certain settings are global and only count if it’s the last frame that’s shut down.)

The search frame is one place. File type, ‘Only users with free slots’ and ‘Only users with TTH root’ gets set as globally (only though if a search has been carried out - and it’s not affected if you press ‘Search for alternatives’).
One major thing that is global is the re-sizing of the columns in various places, such as the userlist, search frame and a filelist.

Toggling userlists

Tuesday, March 28th, 2006

One of the undocumented features that exist in DC++ is the little checkbox below the userlist in hubs. The command “/userlist” does the same thing and that is documented.
Toggles visibility of the list of users for the current hub.

What isn’t documented is how much the feature affect the total state of DC++. When you check the box (or uncheck it, or uses /userlist), the setting to have the user list visable is global. This means that when you close the hub window, all future hub windows will not display a user list since this setting uses whatever the last hub used. So, closing three hubs, will make DC++ to save the setting used in the hub that was closed last.

Sorting and displaying hangs

Monday, March 27th, 2006

There can be a lot of reasons why DC++ would hang (stop responding), but I’m only going to talk about one today.

The following are situations where DC++ almost always hangs for me (it responds fine if I wait a few moments);
* When I do a search and 10000+ results come flooding in. (Stupid me not using “-foo”.)
* When I’ve had DC++ running for a few days, and I’ve uploaded tens of thousands of files and I try to browse the ‘Finished Uploads tab’.
* When I try to browse the public hubs.

What does these three things have in common? Their sorting and displaying of items.

Let me illustrate with an example on how DC++ not does it; Consider you’re flipping through your city address book (”flipping through”… Fat chance). You take one page at a time and looks at it. You only store one page at a time in your memory since it would be too hard for you to have all the pages in your (human) memory.

This is quite logical. And good too since if you did have all those pages in your memory, it would take a huge amount of time to do anything with it.

Unfortunately, DC++ does not use this technique. Instead, it loads everything in memory, sorts the results and displays all the results. So, even if you only can visually see 40 hits in your search frame window and DC++ has found 4000 hits, DC++ will load 4000 items. And DC++ of course sorts the items while it loads all of these items.

Sorting auto connects

Monday, March 27th, 2006

Every once in a while, a feature request (”Proposal”) appear in the forum that involve listing possibilities and the Favorite hubs tab.

Basically, people ask why we can’t implement a way to sort the hubs in the Favorite hubs tab. Like the sorting you find under Favorite users, file listing or the search frame.

So, why isn’t it possible to sort?
Well, first off, it’s not about lack of knowledge. My estimation would be that I could do the feature, make the patch, test it and put up a new Bugzilla entry, all in 30 minutes.
“OK, you know how to, then give us the feature!” No, because you’d lose functionality if sorting was possible. “What? Loss of functionality when you add something? Come on!” Yes, functionality would be lost.
I documented this in the help file (you do read it, now don’t you?);
If several hubs have auto connect enabled, the highest hub will be connected to first.
Auto connect, that is, the little checkbox beside the ‘Name’ of the hub. Not to be confused with auto reconnect.

So you see, it’s a tradeoff. If there was a sorting feature, auto connect order would break entirely.

“So what? Add a feature so we can mark hubs as “auto connect first”, “auto connect second” etcetera.” This is probably never going to happen with DC++. It is bloated enough and arnetheduck has said he wants less features, not more.

Progressing your index

Saturday, March 25th, 2006

The indexing progress located under the View tab is basically just another phrase for ‘hashing progress’. The window display just that; Which current file being hashed and stats about various things concerning files to be hashed.

There’s on major advantage of having this window open. (No, I don’t count being able to see which file DC++ is hashing.) When the window is closed, the thread that runs the hashing process is set to ‘Idle’. (Think of a ‘thread’ as a lane on the highway. Different threads, “lanes”, can do different things.) This ‘Idle’ means that DC++ should run the hashing in a way that’s not supposed to affect the performance of the computer. When you open the window, the process is set to ‘Normal’. This will (should - I don’t experience any difference) make DC++ to hash your files faster. The downside with that is of course that the overall performance of the computer goes down.

Moral of the story; If you want files to be hashed sooner and don’t care if it affects your computer, have the window open.

Starting with the help file

Sunday, March 19th, 2006

In the notes for DC++ 0.68, you could see the following;
* [bug 521] Help instead of readme shown on first startup (thanks paka)
(What you didn’t see was that I removed the readme completely as it was redundant and absolete. The help file is/was better in every way.)

What does ‘first startup’ mean? It doesn’t neccesarily mean the first time you start DC++. What the ‘first startup’ indicicated is that there’s a check in Settings, that will check if there’s anything in the box ‘Nick’. If the box is empty, the help file (before, the help file and readme and before that only the readme) will popup so “a new user” will get information about DC++ to set it up. Why did I put “a new user” in quatation marks? Because the check cannot know if the user is new or not. It will just popup when the box is empty. The most common reason (that I can think of atleast) why the box would be empty while the user is not new, is if the user has chosen to install DC++ in a folder which doesn’t contain dcplusplus.xml (which store the nick).

DC++ FAQ appearance

Sunday, March 19th, 2006

If you read the previous post, you noticed the new appearance of the DC++ FAQ. I just noticed its official appearance (there was a post about it on the forum in the support section but posts gets purged after two weeks). Check it out.

Circumventing maximum slot rules

Saturday, March 18th, 2006

Most (all?) hubs have a minimum slot ratio which means that you have to have x amount of slots open per hub you’re in. x changes of course depending on hub.

There are a lot of hubs that also have a limit on the amount of total slots opened. That is, x slots can’t override the limit y. This can make people use multiple instances, or use another technique to circumvent this “limit y”.

The technique is to use DC++’s rich feature set to avoid “going beond” y without actually going beond it. As explained in Slots, slots, slots…, there are plenty of slots DC++ have. One of the features, the ‘Open an extra slot if speed is below…’, is the one I wouldn’t recommend to use as a circumvent. Why? Well, sure, it will still accomplish the task (set the option to something really high) but the setting will be broadcasted (in the form of “O:x”) so operators can take action. The second option is to set ‘Mini slot size’ to something really high. This is the preferred way in my opinion. Why? Yes, it will also do the same, but nothing is broadcasted to users (they might notice it if they download from you). I’ve yet to see any hub have a rule against method one, but it’s even more unlikely there’s a rule for the mini slot size.

It’d be really amusing if hubs started checking for “O:x” because of this post…

Why you would need to circument the limit y, I have no idea as y is usually something ridiculous (50+). If you’re in need for that many slots because of the slots/hub ratio, you might want to cut back on the number of hubs you’re in…

0.688 is now out!

Saturday, March 18th, 2006

0.688 is now out! Installer, zip and source.