DC++ patching

[Saurod]

I just started digging into the DC++ source because I felt some features were missing and maybe I could help out fix a bug or two. I'm wondering what the proper procedure for submitting patches is. Say I add a new feature, must there be a feature request first? Should I submit a patch as an attachment in the feature request or somewhere else? In what format should the patch be in?

Currently I've added three features into my test source:
* Per favorite user configurable auto grant slot (has been requested several months ago and I think somebody worked on it but it never got into a release)
* Up/down arrows on list view column headers (has not been requested but it annoys me not to see how the items are sorted)
* Info tips on list view items (has not been requested but I just don't like resizing the column just to see long share descriptions or whatever it may be)

Is it just me or is this something that perhaps other users would want as well?

[TheParanoidOne]

Submitting patches

If you think you've done something that more people could use, you can always submit a patch for inclusion in the original distribution. I will then consider whether I like the patch or not based on things that might seem to be completely random, which just might be the case. Popular reasons for rejecting a patch include, but are not limited to, ugly code, abusable features, feature that I don't like that bloat the applications and incompatibility with othermodifications I've already done.

To increase the chances of your patch being accepted, mail them to me (j_s@telia.com) as diffs against the latest code you can find (for the moment, it should be the cvs repository on sourceforge, but sometimes I forget to update it, so check the source code distribution of the latest release as well...). You can find a lot of
information about diff and patch by googling for it.

By submitting a patch, you agree to that I get copyright of it. This to avoid stupid situations later on where the copyright is split out over a million people, each of which could stop further distribution of DC++. If you don't like this, start your own distribtution, if you're lucky it might become more popular than the original =).

[Saurod]

Maybe I should have mentioned that I had read that... So submitting patches to the author is the way to go even though there's such a nice feature request tracker? If I just submit a patch nobody will know that the feature has been requested and if it will make it into a future release or if it has been turned down (and for what reason).

[TheParanoidOne]

I guess there would be no harm in attaching the patches to the appropriate request in the Feature Tracker. I'm not sure how often that is checked though. Unless one of the DC++ code contributers pops their heads in, the best bet would probably be to ask arne himself what the situation is.

Also, I forgot to mention earlier - I like the changes you've made and hope they will be incorporated into the next version.

[GargoyleMT]

* Per favorite user configurable auto grant slot (has been requested several months ago and I think somebody worked on it but it never got into a release)

Me. I hope you didn't just modify the User class, that's why mine was rejected.

* Up/down arrows on list view column headers (has not been requested but it annoys me not to see how the items are sorted)

Good, this was on my todo list. I thought it'd be nice to make it tri-state sorting too.

* Info tips on list view items (has not been requested but I just don't like resizing the column just to see long share descriptions or whatever it may be)

I don't mind column resizing since I saw the tip of double-clicking the separator to auto-size the column. But I'm sure it'd be a wecome addition.

Welcome to the team. Just follow the instructions above that are included in compile.txt in the source.

If there are feature tracker items for what you coded, put patches on there for posterity. However, you should also mail them to arne's mail (either the one in the source, in the readme, or his sourceforge alias) so that he gets them in a timely fashion. I think only Iceman[grrr] gets notifications of all changes to tracker items. I do not, and I'm a SF project member.

[Saurod]

Saurod wrote:
* Per favorite user configurable auto grant slot (has been requested several months ago and I think somebody worked on it but it never got into a release)

Me. I hope you didn't just modify the User class, that's why mine was rejected.

I didn't just change the User class. I also had to change the HubManager (for saving the auto grant field per favorite user) and UploadManager (to check if the user should get a slot).

Quote:
* Up/down arrows on list view column headers (has not been requested but it annoys me not to see how the items are sorted)

Good, this was on my todo list. I thought it'd be nice to make it tri-state sorting too.

Yeah tri-state would be nice, especially in the MainFrame!!! (Otherwise the info tip will blink quite a lot when you've sorted on user name or whatever and people are trying to connect to you all the time. )

One final question about patching though. It can be quite cumbersome maintaining (and testing) one source tree per feature you've implemented. Is it acceptable to send a single patch for multiple features? It's easier for me with a single experimental source tree but if I was the one getting patches and I didn't want all the features it could be quite a lot of work to remove the unwanted code.

Thanks for the welcome! I hope I'll be around quite some time.

[GargoyleMT]

I didn't just change the User class. I also had to change the HubManager (for saving the auto grant field per favorite user) and UploadManager (to check if the user should get a slot).

Well, it was my understanding that Arne though it was wasteful to have a small list of favorite users, yet use the general Users list to store those attributes. I think he was looking for a map between user nick (hub included? -- something to think about since DC++ handles nicks as globally unique.. mostly) and favorite user/granted user status. I'd probably make alittle subclass if I did it again.

Yeah tri-state would be nice, especially in the MainFrame!!! (Otherwise the info tip will blink quite a lot when you've sorted on user name or whatever and people are trying to connect to you all the time. )

Plus, a lot of other applications behave that way (sort ascending, sort descending, and no sort), so it's natural to think that DC++ should as well.

Did you try your image maps with non-standard colors? I took note of the 3D_FACE style while creating the ImageList, but I haven't actually implemented anything myself...

One final question about patching though. It can be quite cumbersome maintaining (and testing) one source tree per feature you've implemented. Is it acceptable to send a single patch for multiple features? It's easier for me with a single experimental source tree but if I was the one getting patches and I didn't want all the features it could be quite a lot of work to remove the unwanted code.

I hear you loud and clear. I always like to send individual feature patches, Arne might not accept them all, and if not, separate patches make his job easier... I generally make a clean copy of the source tree, merge the feature that I want a patch for into it, compile it, run it, then do a diff with appropriate options (he wants unified for sure). I've found no tool that lets you split differences into many .diff files, though that would, in my mind, be a killer app.

Share and Enjoy!

[Saurod]

Saurod wrote:
I didn't just change the User class. I also had to change the HubManager (for saving the auto grant field per favorite user) and UploadManager (to check if the user should get a slot).

Well, it was my understanding that Arne though it was wasteful to have a small list of favorite users, yet use the general Users list to store those attributes. I think he was looking for a map between user nick (hub included? -- something to think about since DC++ handles nicks as globally unique.. mostly) and favorite user/granted user status. I'd probably make alittle subclass if I did it again.

Ok I can understand that. For future functionality of favorite users it's of course best to separate the fav user information into a separate class. I hope it's ok to store a pointer to, say, a FavoriteUser instance in the User though so one doesn't have to do a lookup every time you want to know if the user is indeed a favorite user. The cost is the same as storing the bool (because of padding...) but future functionality have a cost linearly proportional to the number of fav users.

(snip)

Did you try your image maps with non-standard colors? I took note of the 3D_FACE style while creating the ImageList, but I haven't actually implemented anything myself...

Every ExListViewCtrl creates two 8x8 bitmaps in code and handle WM_SETTINGCHANGE (there was no easy way to handle WM_SYSCOLORCHANGE but I don't expect a lot of WM_SETTINGCHANGE messages either...). Standard colors (COLOR_3DFACE, COLOR_3DHIGHLIGHT and COLOR_3DSHADOW) are used so the arrows will always look mighty fine

(snip)

Ok one source tree per feature it is :\

[GargoyleMT]

Every ExListViewCtrl creates two 8x8 bitmaps in code and handle WM_SETTINGCHANGE (there was no easy way to handle WM_SYSCOLORCHANGE but I don't expect a lot of WM_SETTINGCHANGE messages either...). Standard colors (COLOR_3DFACE, COLOR_3DHIGHLIGHT and COLOR_3DSHADOW) are used so the arrows will always look mighty fine

Sounds like the right way to do it.

Ok one source tree per feature it is :\

It's what works for me... Do you have a good merge tool? I tested a couple, and settled on Araxis Merge. I didn't go the full route and get their 3 way merge version, but the standard works fine. xAyiDe from the dev hub prefers Beyond Compare. Either of those should lessen the amount of work you'll have to do.

Share and Enjoy!