dmvn

The Tracker rearrangement is the perfect modification. The second one (hiding the national support) seems strange.... But, i have one idea... I hope we can create direct links to these subforums on the apexdc.net site. For example, we can add a section named Support (or International Support, maybe?) at the site with text "ApexDC has support in following languages: <list/links to corresponding subforums>". This came to me when i had a look to 'Customise' section of the website. Going further, we can determine the viewer's location via GeoIP database, and translate word "Support" to the corresponding language to display it in a quite comfortable form for non-english-speaking people.

+1. Any antispam/antiflood control mechanisms ars based on passing-through-hub all control messages, including PM. This will break the scheme. Of course, if this disabled on target machine, no spam will flow. BTW, ApexDC is a filesharing program. And chat/PMs are secondary functions... Anyway, this will lead to additional options/settings window overload, etc... I think we should wait while other clients will (or not!) support this feature... And then add it... This is not the case when Apex should be the first one who supports this... We have many other interesting extensions to work out. All typed above is only M.H.O ;)

Существенное добавление к предыдущему посту. STLport надо брать из svn, иначе ничего работать не будет. STL 5.1 не годится, вряд ли вообще соберётся.

Damn it, what the hell is going here? Why do you talking about FlyLink??? This is the APEX forum, no? VamKir, your translation is rather good, but... there are some bugs/not-russian-phrases: i'm native Russian, so i know the language well. Is your translation posted there is the last available one? I believe i can fix some strange phrases in it... So please guide me to the latest one, and i'll produce a .patch. Also i can put it into svn repo to track down all changes... [cp1251]

More precisely, this discussion was here: http://forums.apexdc.net/index.php?showtopic=1166

Maybe this one (in fact, the cutoff of subj) http://forums.apexdc.net/index.php?showtopic=2420 seems to be smth that will be implemented... But not subj "as is".

I agree with Greg: somebody who wants to use this feature, *will* sacrifice DC++ compatibility. This option must force disabling 'dc++ compat' checkbox, and vice versa. Then people will be able to make their own choice. Uff, filelist size... This field is the UNIX timestamp... So it's 10-15 bytes per shared file... Not so much, especially for modern HDDs and LANs. Anyway, sounds good. For it.

The great rule sounds like that: There cannot be too many settings/options. There can be a bad interface/layout. But it's not the case The color selection window is organized well, so I see no evil if one more item adds to the list. But this feature improves readability of long conversations... :)

Zlo, i think pluginz (uff, huge 10x to devs for plug support!) solve the 'homebrewing' problem you mention A beautiful example for programming practice :(

Plus one Useful feature! This shall be done... I will use it, 100%. Fwd thanks to devs.

Well, probably you're not working with large files 'Slow' is a RELATIVE characteristic Smth can seem slow for me and seem FAST for you If you think that 100M is enough for any user, you can just sit back and relax, we understand you completely The most interesting is that, indeed, in the 1G-network i really cannot achieve speeds more than 20-25 megs per sec via Apex/sDC/... although wind0ze can transmit files quicker. First, i dont want you to change DC protocol, etc... The only thing i want to understand, what can slow such a fast transfers... Small blocks? Insufficient disk cache? Slow CPU? Smth else? I suggested smth above, but there were only guesses. It's not a problem (because we can use another protocol), but... now I'm interested in knowing what component is the real bottleneck. Hint: the answer 'HDD' is wrong, obviously. The only one idea is that windows can achieve speeds ~30-40Mbytes/sec over 1G-LAN when data on HDD is arranged in a large linear block. When any fragmenation present, it drops to 15-18 megs, or so on. So i think that this can be a main reason (blockish behaviour of DC creates 'turbulence' and slows processs).

This is not connected with 100M Limit. This is, more probably, connected with the nature of DC++ protocol itself... Small chunks, hash checking, alternate searching... etc... Windowz performs faster as it doesn't do a half of it, it sends only data.

Of course, i DO understand it. But this means I cannot provide adequate info for hub while using 1G-connections This is a tiny bug/typo, of course... Well, you may name it as you wish, but the solution is so easy...

I said so because it's obvious that HDD speed (for modern HDDs) is MUCH MORE than 100 Mbit (that is maximum in "Settings->General" window). I think this is so easy do add one more item for conn spedd combo... Well, i provided the example of the real situation (and can also make some screenshots to prove...) where this setting can be useful... What any arguments you need? <offtopic>PATA HDD... Oh yes... Such a slow devices... Wide IDE connectors.... Nostalgy.... </offtopic>

BM, it does not matter at all! One HDD can fill upto 1/3-2/5 of 1G-uplink. But i think there is no problem at all... Or, at least, no serious problem... I also have 1G uplink in my LAN, but other computers connected using 100M-switches, so each of them can load it's own channel up to the full capacity. When all limits turned off, I often watch upload speeds like 20-25 megs per second, so DC allows such fast transmissions indeed, although maximum connection speed is set at 100M (in settings). Please note I have no RAID arrays, that allow speeds like 100-150 Mbytes/sec So, the suggestion is the only to add one more item to ConnSpeed combo-box, named "1000M" or "1G".

Well, i passed this problem in another way -- and done it much more effective... I've changed the DC protocol a bit for my special anti-leech hub and compiled a special DC client without any leeching/cheating options. Nobody can connect this hub using other client, due to protocol modification. This client still can connect to other hubs using standard DC protocol (there is a special autoswitching mechanism). So i don't need to ban/detect leeching mods -- i should only set up minsharelimit and minimal upload speed than can be done in hub settings. That's all. Please note that this solution is used in 100mbit-LAN with free internal traffic, not over Internet, so we don't violate anything -- we only want from users to share more This is not applicable for Inet hubs where different users use different (f.ex ADSL, hence slow) connections...

Or, you can backup section <Share.../> in DCPlusPlus.xml, then run new .exe, quit it and then restore it in that file. It's useful if you have lots of shared dirs, not to tick 1000 (omg) directories... Hope this helps.

Well, i'm not a beta tester, but it's so easy to check... Using apex 1.0.1 built from source. I swap some tabs, then closed apex. Then opened it again. The tabs order is saved. I tried it three or four times in different ways -- everything is OK. So if there any bug, it lies deeper than the surface... I recommend two things: 1) ensure that you're using *LAST* version of apex. 2) try to *delete* all settings, leave bare .exe and run it again (and then check behavior) -- maybe you put your new .exe into your beta5's folder (i noticed some strange effects including share flushing, maybe this is the next one...) Sorry if any flood :)

Oh **** You're right So much settings, so much options... As for me, my implementation is more useful, but this is only IMHO, anyway. Thanx for advice, next time i'll read the source code more review code more carefully, although i revised "Experts only" section.... The one thing still remains useful in my post... Would you like to adjust the layout of Appearance dlgbox, as shown? More precisely, extend space for "AWAY msg" to the width of the dialog, and move timestamp box to bottom. It's quite easy, but improves design, because AWAY message shall be long enough to see the whole message, while the path for langfile can be short as nobody actually enters it with hands, i believe everybody uses "Browse" button :)

I added a useful feature to my apex mod that I watched some months ago in speedmod. The Chat Message now can be resized up to 10 lines of text, like this: And this is the new Appearance window (yellow box marks the new setting control). Also I optimized the layout of Appearance dlgbox (shown with the red frame): the AWAY message was too short, and the path to langfile is too small... (this is also included in this patch). I tried to add .patchfile as attach to this post, but it failed, so here is the direct link... (why .bz2 files are not acepted??? ) http://dmvn.myftp.org/soft/chatmessage.patch.bz2 (svn diff with the 1.0.1 final version taken from site). Hope this will be merged into the project Any comments, wishes?

Plus one !!! It'll be a *great* fix PMs are always annoying, esp. for large hubs operators/masters. I'm not so sure about file lists.... but PMs definitely must be backgrounded by default.

Well, if implemented, so the *exe-backup* must be the important sub-feature of auto-updater. Afaik, some settings transfer incorrectly while moving to new versions (f.e the share problem noticed at 1.0.0.b5-->1.0.1.Final, also the quicksearch window was invisible until i deleted /Settings folder, and so on...). Sure, this feature/setting must be disabled by default (or we get thousands of angry users at new release date).

Well, thank you for your comments... I know at least one project invoking ApexDC++ that needs this feature So we're waiting for complete ADC implementation :D

OK, thank you... Let the force of diff be with me...

Nice work, thank you for some notes about stlport. I've managed to compile 1.0.1 with the latest STLport from svn repo. Before reading this topic i have a strange trouble -- no slider in the main window that allows to resize userlist window while being compiled with the _old_ stlport library (i don't exactly remember what version, but < 5.1.5) and the standard patched WTL from strongdc site. When upgraded to new stlport and recompiled it, everything is OK, the slider is moving. Decided to notice this, to avoid same mistakes on the final release (due to no same effect achieved at 1.0.0.beta5!). PS. /me wants to commit some useful things that I've modded in beta5... (chat msg/private frame msg resizing, etc...)...