Greg

Indeed, some way to recheck files... even so could take a long time and a lot of CPU to do it with large filelists...

Surely Apex would have started re-downloading the files from the beginning and therefore the info in relation to what has been downloaded etc. would then be inaccurate? Heh could "re-check" the files after moving them back/replacing the filenames/paths in the queue.xml but even if you could that would take a long time/CPU if you did it with lots of files...

As I understand it, the original poster was complaining about losing a slot, if you disconnect from all sources as you say you're just as (if not more) likely to lose the slot.

Worry about getting a decent basic client first, adding stuff in comes later. Hopefully after release we will start to establish a userbase and due to the Linux community (as you mentioned) generally knowing what they're doing, maybe one of these new users will be willing to help the develop the client further. Basically let's just get a usable client for we worry about any sort of extras.

The thing you have to remember is that you can't really change this mid-transfer... therefore it wouldn't solve the users' problem. Unfortunatly that's the disadvantage of multisourcing, and it wuld probably take a lot to change it. Would be nice if segments were just extended during transfer when a fast user was found, but I would assume that'd not be too easy.

Haha, I never delete anything anyway... whether I'm drunk or not.

Santa told us we had to release another preview release otherwise we couldn't use the code. :P

Heh what's wrong with being on the PC whilest drunk? I just type badly and take things less seriously... Not a problem. :P

Yeah, it should of course be optional... some people may find it annoying or whatever.

It's a feature that is within other chat programs (Lee :w00t: ). Basically in the window/chat of the active window within Apex a "marker line" is produced whenever the user minimizes the windows or changes focus away from the window. This means that when you get back to the window you know quickly where you left off. This may not seem like an important featue but until I used it within another program I didn't realise how useful it was, can save a bit of time finding your place within a convo. However, DC is a different kind of chat enviroment from where I have seen this and it may not even be useful on a lot of (public) hubs but it can useful, and with DC maybe should be for every hub so you can change to another chat then get back and read recent changes quickly. It is a very nice feature in my opinion, all it's simply a line/breaker within the text which clearly stands out. So the whole line is underlined kinda thing. For an idea of what I mean (might be quite clear already?) take a lot at XChat. Thanks Greg

Who's this "Grogs" you mention? :P

No comments on the present Santa gave us yet? :)

No snow here either. Personally my family doesn't like turkey all that much so we just get 2 ducks instead. Can;t wait for those little sausages wrapped in bacon... yum.

Of course it would limit the userbase. Plenty of people use "standard" ApexDC++ on hubs where they are an OP already. The non-OP users make up a bigger proportion of the DC network, or so I would hope at least, you don't want more OP than normal users. As such, by making a client targeted mainly to non-OP users you get the target share of the userbase. The current version of ApexDC++ is much more suitable for OPing than any other client I know of available on Linux. As for the faster development point you raised... anything in ApexDC++ as it is at the moment which can't easily be ported will probably be stripped by almightycow (deliberately [in]correctly spelled) I guess, so I would hope the extra features added won;t slow development too much. Less bugs... well, hopefully we don't have too many anyway. Easier support... surely it;s easier to give support for things which are in both clients, with a little less that can't be ported, than having to give support for a load of different features etc. too?

Eeek, it specifically mentions the "Staff team" as writers for the guides in the first post. I really need to get my PC up and running so I can complete/redo those video tutorials...

The group icon at least is Mauve, not just purple. ...in Doctor Who Mauve is the universal colour of danger. :D

Me too. I guess I'm bias. Anyway, shame about zK++'s code.

Very true, compared to LinuxDC++, ApexDC++ is very OP orientated.

Hmm, the non-image alternatives are just as CPU heavy. Another forum I'm on is using snow too... which also uses plenty of CPU.

:)

I wonder if almighty (yes deliberately spelled that [in]correctly) will actually pay the $50. Anyway, hopefully this will get someone to figure it out, and maybe that person may want to do more developement for free? :)

I guess it's a little harder to make a person of specifically one sex in such a small space. Anyway, as long as this is disabled when emulating DC++ then I don't see a major problem with it, just got to get the hubsofts and other users making use of it.

Goes down to around 50-60% when the snow isn't actually in on the screen... but still high 90s rest of the time. EDIT: Should mention that's using Firefox 3 alpha (Gran Paradiso) on a 1.8Ghz Pentium 4.

It is indeed the lovely snow that is causing it... I'm having the same problem, it's the same with the main site. The script is designed for use with larger (and less) snowflakes, as we're using so many it causes the massive CPU use, as far as I can tell. Maybe this can be somewhat solved by some changes in the script...

Why do you think it is using too many resources? If this was put in ApexDC++ it would still use those extra resources... Maybe it'll be less but probably still be quite a bit more. RegEx would be useful though.