Crise

I explained that in the 1.4.0 release topic, I think... we have interest in bringing the icons from 1.3.x back and Mek has kindly said that he would help us with updating of the icons. So for now you are stuck with these icons but hopefully not for long :)

They are old because I didn't bother fixing up the order of the images in the new flags image to reflect the requirements of code merged from SDC. (there are a lot of flags in that file so even locating the ones that would have had to be moved around seemed like a pain, so basically I was lazy and copied the updated version of the old image from SDC). As for the reason to my laziness, I am completely useless when it comes to anything that has to do with image manipulation. That said we are of course hoping to include the flags from 1.3.9 to this one as soon as possible.

I don't think Lee meant you contributing directly in terms of code but with opinions and discussion, after all as you said since we are the party that is interested in merging with your work you contributing to our repository would not make any sense at all (to condense: communication). I am, by default, not aware about private communication that happens between you and Lee. However, Lee is not a programmer so it makes sense he wouldn't know about how to disable emulation by default (among other things), that said I don't deny the fact that there are certain areas of code that I am not completely familiar with either (since there are things I don't use the program for so it is not high on my priority list to learn or modify those areas of the code) but I certainly have always known how to disable emulation by default. As for why we did not disable emulation by default before you, there is always a risk in being the first to do something so basically we wanted to see the general response to it before making a decision on it. As for this, some of it is certainly true... we wanted to have something so that we could send builds to certain people who are necessarily not developers to test and since sharing is integral part of DC we felt that at least that should be somehow accessible without having to explain how to make changes manually. As for why send builds out to people at this stage even though ApexDC specifics have barely been touched on in the UI. The reason is simple: we don't necessarily use all aspects of the program equally some not at all, not to mention that for a developer to test a program is not the same as for user to test it. Users have tendency of coming up with very creative ways of using a program you know, also we get feedback on what kind of behavior the user expects for instance if user tries to do something and nothing happens if this is repeated more than once then it is reasonable to do something about it even if it may not seem the best choice for us personally. Something that compiles does not necessarily mean that it works, besides that there are behavioral differences between different OSes which also means that what may seem like regular or standard behavior on windows may not be the most natural behavior on other operating systems. This is how a team can work, however, the more people doing this the more inconvenient it will get, since with your model the communication is closed off between you and someone else (in this case adrian). There are also no public reference accesible when you are not reachable anywhere so the people involved will have to always wait for you to be available to even ask the simplest questions and with people on different timezones the inconvenience factor just keeps going up.

So it crashed 6 times, why don't you upload the generated exception info for us to look at rather than just say this version is no good. Where does this come from, 1.4.0 does not block any Apex users (or any other type of users for that matter). If it is about what is written on the news posts that is a note aimed at hub owners not regular users.

Off topic discussion moved to:

I will only say that there are patches for SDC issues in there, for instance the view menu has been fixed (also added system log and transferview as separate entries to it). Also fixed right clicking on the bottom pane tabs (have proper context menus now, and can be closed, instead of showing active hubs context menu) Also NetStatsFrame is fully functional in it. These of course apply to the current SDC wx which I can see, what happened beyond then is something I can neither predict nor account for. (We also had versions making use of the AUI framework before any of such was seen on your svn afaik, but this is of no importance, same with the share page which I believe you labeled as not good enough for not having the modern UI, over being portable and significantly faster choice for the time being). I know the things listed above are nothing significant, because for us portability was and is top priority (until linux and mac variants are reasonably close to the current state of the windows build), but it is incorrect to say that we never did any of those at all. As for new features not being there, but some actually are there (some incomplete, and most not in UI yet but they are there). Also there is no point in adding further untested code on top of an existing code that has number of issues. Before major feature development on the UI side can be done with confidence we need to be closer to the state where the WTL UI is right now (to avoid the possibility of a snowball effect). Regarding contributing code to the StrongDC wxWidgets, we don't do patches just in case you might want to include them. This means to say that with your irregular commit frequency and no detailed info on what you are currently working on outside committed code preparing patches for you with the risk of you already having fixed an issue in your working copy will be waste of both your and our time (which is also the reason why we have steered clear from many issues in the UI code, since we have to always guess whether you have already fixed in your working copy or not). Essentially I am implying that for multiple generally unrelated people to work together effectively some kind of activity tracking/tracking of assigned tasks would be beneficial. In other words what we have been doing is what we can do in the light of the current situation.

For one, we never brought the new UI into spotlight in our news posts, what we have been highlighting is the cross-platform support. For us this, running on multiple platforms, means not only windows and linux but Mac as well (here Mac implies wxCocoa, and linux wxGTK obviously). Also we were already working on portability at the time when you said that SDC wx UI running on linux was not a priority for you at the time. If you have since then patched your code to run on linux then that is great nonetheless. Also while we have made big deal out of 2.0. running on multiple platforms that is just one of the things 2.0 will be.

Profit, hardly... while it is true that we do use earlier revision of your work as base and have merged some of your later changes recently by no means is it a pure/direct copy nor are we making profit out of your work (as a matter of fact, right now we are not making any profit at all - if Lee so chooses he can get into more detail on this).

BASE_QUEUE_ADD_DL(core, aTarget, aSize, aHash, aFlags, aData)

Even though I agree with you and pROPs it is only natural for us to push for ApexDC, like I said to Toast when he complained to me over IM: What has been done here is something each participating project has an equal chance to do. It's upto them however whether to do it or not. If you want to ensure recognition based on actual progress and features implemented then open vote where all projects have a slot automatically is not the best choice (what I am implying is that perhaps there should have been a nomination round, that is not necessarily a vote, or something like that).

It attempts to download from beginning and end of file first, thus enabling capable players to play back the incomplete file (to an extent such that you should be able to verify whether the file is what you are after). There will be options to better configure this behavior in upcoming versions (in practice this means 2.0, since that one has most of my attention as the nature of the updates for 1.x shows I believe).

Also it would be good advice to pick the hubs (or servers as the opening post called them) that have content relevant to your needs. DC as a network is not one where you can be connected to the entire network at once anyways (hence why the addition of a DHT based network was very welcome).

Most of those are in the "remove forbidden" list (an on/off option in advanced, enabled by default).

You need to forward: - two different TCP ports and two different UDP ports. - one pair goes as the regular TCP and UDP ports the other as TLS and DHT ports. Or: - two different ports each for both TCP and UDP. - thus TCP and UDP can use one port, TLS and DHT the other, but for example TCP can't use same port as TLS. Also remember it isnät just your ports that need to be forwarded correctly but also the other users you are trying to download from (because if he has in correctly set himself as active, that would be a problem).

I'll be seding PM's to people having these issues later today... because I need to be certain of something before I invest any more time into this.

ApexDC should be able to handle 2TB, and more, just fine (memory usage might be bit much with large shares, but it should still work just fine). One more thing, if you haven't try disabling fast hashing, I dunno what kind of problems it may cause... since haven't had any, but there is a note about it in settings.

About validity, run it through W3C's validator, or open it in a web browser... Regarding AppData, if you don't have dcppboot.xml in you program directory then don't worry about it. If you do, AppData is a system folder used for storing application data (called Application Data in XP) %APPDATA% in find, should find the directory for you.

hmm, off hand I don't recall what may cause this. However, make sure the file you are trying to load is in correct location. (ie. if you have dcppboot.xml in your apex directory then you need to put the file in AppData, not in ./Settings/ most likely). Also check that the xml is well formed. The parser is stricter thesedays that it was in older versions.

Yes, because we actually enabled TLS for upgrading users as well, not just new installations (this is because originally tls was enabled by default, then due to certain issues we disabled it for all installations, and now we reversed that)

About progress bars and cpu, what type of progress bars, and how many at a time?

Our text box expands as well... though you have to enable that behavior (it is buried in settings > advanced > experts only > max resize lines, I think). Don't ask me why I choose to hide it under there, because I honestly can't remember...

Either forward TLS port (set it to something besides 0), or disable TLS in settings > advanced > security (topmost of the three checkboxes) if you have no use for encryption.

Your hubsoft might provide facilities for doing that kind of thing, other than that the only other option is the presently outdated CDM but configuring that is not worth the trouble since there are no premade profiles available anymore that we know of. I will say this though, there are barely any who use that version afaik, and the only undesired change in it is the removal of limiter rules if the changelog is accurate. The point we are trying to make is that this version was not released by us and should be treated as such... and more importantly it is each individual hub owners choice of how to deal with. All we want to make sure is that hub owners are aware that there is a difference if they see this version.

Well the proper thing to do would be to forward the port marked as TLS, it's another TCP port though so you can't use same number in all.

About hash database, a /rebuild in some hubs main chat could be useful from time to time.