Ultima

As soon as the information is made available from µTorrent to the browser. Which it isn't yet.

After a long incubation period... Get it in the first post. As of this posting, VirusTotal reports 3/39 as the results for the Unicode build. False postives, probably because some antivirus softwares are still braindead and can't figure out that UPX does not automatically make an executable a virus. I finally got around to fixing the 64-bit build because... I'm finally running an x64 build of Windows. I do believe it should be slightly faster than the 32-bit build (something along the lines of 10-20%), but I never actually tested it to any careful degree. The 64-bit build is so much larger because there is no UPX for 64-bit executables, so I decided to just leave it unpacked. Didn't bother making an ANSI build because I can't test such a build properly at all (no Windows 9x to run it on), and I seriously doubt that there is any real demand for the ANSI builds to begin with. As well, for files that do contain Unicode characters, I can't even guarantee that the ANSI builds will edit/save them correctly at all.

@phunkyfish: What do you mean by "blank"? Is it completely blank with nothing, or are the fields just not filled in at all...? Screenshot? @joz: That doesn't make any sense. WebUI has always requested using /gui/, and the onus has always been on the URL rewriter to rewrite any and all requests for /gui/ to the proper location. If it isn't rewriting it now -- and especially only for token.html -- then chances are, somethng isn't set up properly on your end. It makes even less sense that regular requests are working for you, but just requesting token.html isn't. You'll notice in the request you observed, WebUI is requesting everything from the same base location. Anyway, browsers apply the login to the domain, so as long as the application is not making a request outside of that domain (which it isn't -- and can't, due to XHR security limitations), then there should be no reason the browser wouldn't properly send the auth header in the request, even if it's trying to request from a different directory. Unless of course the rewriter isn't rewriting all requests, such that the token request is hitting the wrong location on your server. Yes, WebUI never used to request token.html unless it was logged in as guest, and that changed with the latest release of v0.362, but that should never be a reason it should fail now. More and more, I'm thinking that it's a problem in your URL rewriting rules. FYI, I asked Lord Alderaan to test URL rewriting with v0.362 on his Apache server a few hours ago, and he didn't seem to have any such problems with basic HTTP auth failing. Have you tried clearing your browser cache and such like I asked you before? Additionally, it would be helpful if you included a log of some of the requests (working and non-working), and maybe the relevant parts of your Apache configuration that's doing the URL rewriting.

http://forum.utorrent.com/viewtopic.php?id=50718 And uh, grab v0.362 while you're at it.

Yeah, that should be possible... Well, that only pertains to the columns that are actually implemented in WebUI to begin with. Not all columns in µTorrent proper are available in WebUI because of WebUI backend limitations (currently -- as of this writing).

@lostinlodos: Keep in mind that often in software development, the last things to be finalized are the UI elements, whether it be artwork, or localization strings.

Please try upgrading webui.zip to the latest copy found here. As for the Ctrl+F5 thing, that must be a problem with Firefox caching very strongly. If you don't press Ctrl+F5, what goes wrong anyway?

From what I can tell, it's not possible. @joz: That I can't reproduce or explain by any changes to my code. It must be something else. Try clearing your browser cache or something. I've seen similar behavior when trying to test MiniUI using the Android emulator, but it went away on its own after upgrading the OS.

@icleolion: Heya, long time no see Yeah, every now and then, I burst out with a huge rant because of how a discussion is progressing (or not progressing), as usual, but I'm hoping others see it as being a reasoned rant, and not just a random outburst. Users have actually requested a skin manager of sorts before, and even some way to pack the skins together into single theme packs for easier changing of themes, but I don't know what the statuses are on those requests. @Seyss: People always complain about skin changes. They simply move on because they can skin it anyway, which is why you no longer see any complaints about them anymore -- it's already blown over. Need a few examples of people complaining about the old toolbar? http://forum.utorrent.com/viewtopic.php?pid=163206#p163206 http://forum.utorrent.com/viewtopic.php?pid=169636#p169636 http://forum.utorrent.com/viewtopic.php?pid=177944#p177944 Admittedly, there weren't as many complaints about the old toolbar as there are about this new one, I'll give you that, but there were complaints nevertheless. Only a guess, but maybe part of the reason it was better received may be that that ludde used a skin that was already relatively well accepted by the community, designed by a well respected designer in the community (Operanized by BSH/savaden). I don't know why a change was deemed necessary, but having no complaints about the old skin isn't necessarily a reason to keep it either. If the devs/designer(s)/product managers felt like they needed a visual refresh, then that's usually reason enough (not like they're trying to run the thing into the ground). The only thing we can do is help them along in polishing it. Unless, of course, they feel like it's a lost cause, and decide to revert. Dunno, but I think they get the point -- a lot of people are complaining about the new skin (bold to emphasize it for them ;D). It's time to give them reasons why, and let them decide whether they want to go back want wait to refresh in another release, or push forward with this new toolbar for 2.0.

I think the change from the play button to the up/down button also presents a bit of a consistency problem. There is a pause and stop button that is reminiscent of old "standards" set (probably?) by VCR controls, but for whatever reason, only the button to start the torrent was changed. If the idiom isn't going to change completely, I think it probably shouldn't change at all. If I had to venture a guess as to why it was changed at all, I'd say that it was probably to match up the toolbar icon with the status icons. "Play" doesn't match with up/down arrows used for seeding/downloading, so it was probably changed because of that. Or maybe "play" would get in the way of that whole streaming idea where you're actually playing videos.

I have absolutely no problem with your efforts (along with emc's). In fact, I recognize and applaud it in my post. Regarding taking it easy... I don't know how else to word it. Again, I said above that I myself am not a fan of the new artwork, but I did take it easy by just using it and figuring out what problems I had with it. My rant wasn't about the skin itself -- it was about the lack of constructive complaints railed against it. lostinlodos's post was the proverbial straw the broke the camel's back. I understand completely that it's difficult to formulate concrete complaints about abstract ideas like artwork (and was planning on editing in such a note in my above post), but if people just took the time to figure out why they disliked it, it would be infinitely more helpful to people who work on the design than just "ew." It doesn't have to be a conscious effort for users to draw up reasons they dislike it. Just using it and realizing specifics along the way would be enough. If the user really can't stand the overall design ("kid-like") enough to even bother trying it for a while, then they should mention how the skin is kid-like instead of making readers guess. Really, if the entire style doesn't suit you, then that's what skinnability is for, because there's no fix for complete objection to a style other than to replace it entirely. The default isn't getting forced onto anyone. One man's junk is another man's treasure, and the saying applies extremely well here. Just because you liked the old skin doesn't mean everyone else liked the old skin -- otherwise, there wouldn't be hundreds of skins uploaded to the skins repository in the first place -- so why must the old skin be kept? All of his complaints can apply equally well to Operanized too. The one gray area is with the colorblindness issue, which I won't fault lostinlodos completely for, but as explained above, rolling back to the old skin won't fix that aspect of the UI either. To Reiterate: I am not trying to stifle complaints. I am trying to promote complaints that could help the designer improve the icons. A pretty scathing rant was (IMHO) in order to set people straight.

@Some of the people complaining about the new skin: [rant]Jeez people, it's a freaking skin. I can't see why it's received the kind of reaction it has (to paraphrase, "zomg its so ugly cant believe it go back go back"). rafi and emc have been working hard to make the old skin available to use; if you prefer them, use them! There's a reason you can skin the thing in the first place. I won't say I'm a fan of the new icons myself, but to call them "kid-like" without any further explanation? And are you seriously comparing it to some paradigm shift like the Ribbon interface? (Which, by the way, was based on well-tested usability and usage research, and even many once-detractors end up preferring Ribbons over menus after a while anyway -- non-argument) Colorblindness? The interface never was colorblind friendly to begin with -- not even the old icons. Red-green colorblindness is the most common form of colorblindness, and yet I don't see you complaining here about how people can't figure out the difference between the upload/download lines on the Speed graph, or an errored upload status icon vs a normal upload status icon in the old status icons. If you want us to consider all possibilities, why aren't you yourself considering this possibility? If you're going to try and make a case for changing the icons back (or to change them to something else), that's perfectly fine (really, I wouldn't be against it). But don't pick out things that can easily be argued about for the old skin (colorblindness), and don't just throw around unsubstantiated and subjective criticisms ("kid-like" or just plain old "ugly"). @lostinlodos: "Stop trying to mess it up." Really? Then here's my suggestion to you: don't be so obtuse. Do you seriously think anyone's trying to mess anything up? Are you telling us that things should never ever change because it would make things "unstable"? I guess we should all switch back to and stick with µTorrent 1.0's icons. Or stop working on µTorrent altogether. Or whatever other extreme action I can just as easily imagine you coming up with, based on your "arguments". To be honest, posts and quotes like these would be counterproductive in convincing anyone to do anything. Your issue with poor accessibility of the new skin at least has some basis in fact, but IMO, that's not a problem that should be dealt with through the default skin anyway, because fixing colors for one form of colorblindness might break colors for another form of colorblindness anyhow. What are we supposed to do? Make all icons grayscale or monochrome by default instead? No, it's better left up to customizability of the skins.[/rant] @lostinlodos: Don't take this rant personally. Your post just struck a chord in the wrong way (not so much because of any kernel of truth, but mostly because of the attitude). Yeah. I just unleashed some pent up frustration after seeing so many complaints from users about the new skin, with nary a bit of constructive or reasonable criticism. Again, this isn't to say that complaints aren't welcome. But don't keep repeating the same exact non-arguments. Please make your reasons more concrete. Want someone to start it off? Here we go. [ul][li]lostinlodos says it's "kid-like". In what way? Well presumably because the start, pause, stop, and queue buttons (and maybe the RSS icons) are relatively bubbly. There's no way anyone can argue that the other icons are "kid-like". How do we fix this? By making the offending buttons more consistent with the other non-offending buttons in quality. Not rounding the corners might be a good start. [/li][li]To expand on that, inconsistency is a major issue with the skin, and consistency is very important when trying to design a skin. Even the shading for icons isn't consistent. Some icons have very smooth gradient shading with matte coloring (like the Add Torrent from URL toolbar icon, or the Pieces tab icon), while others have a glossy look (like the start/stop/etc buttons, or the General tab's icons). This should be looked into. Now, I'm by no means a designer (whether by trade, or by hobby), but as I understand it, when people are making a theme, they pick out an idea and a design principle by which to guide them in the process -- maybe whoever designs the default skin should consider this. [/li][li]The icons have very finely outlined edges, which in and of itself isn't a problem, but that makes it easy to see extreme aliasing on the icon edges. Example? Preferences button's icon. So apply some antialiasing/smooting to the skin's edges, or something. (Just make sure you don't blur entire icons to oblivion) If it's hard to get it right, then maybe the icons are a bit too packed with details, and you should ease up on the lines a bit. [/li][/ul] Disclaimer: This entire post is a reflection of my opinions only, and does not necessarily reflect the opinions of BitTorrent Inc.

I... really don't know what to say. I'm testing using Windows 7 (should behave similarly to Windows 2008 R2), and I'm not experiencing any problems. I also tested using Windows Vista (should behave similarly to Windows 2008), and I'm not experiencing any problems either.

http://trac.utorrent.com/trac/ticket/54#comment:5 Yep, I noticed this a few months ago, but can't really correct that number due to the WebUI backend currently not sending enough information :/

Can't reproduce the issue here. I just created a BEncoded file with the following contents: Performed search/replace on "D:\halfcd" to "F:\halfcd", and the result was exactly as expected: Got a file I can test? As well, have you tried editing the item to make sure it's not just a UI glitch?

:/ Do you see whether the mobile client ever requests token.html?

Oh, er... I don't have any web server installed for me to test URL rewriting, so... I guess you'll need to be the guinea pig ;D http://sites.google.com/site/ultimasites/files/utorrent-webui.webui.2009122508400292.js.gz?attredirects=0 Can you grab this, rename it to webui.js.gz, replace it in webui.zip, and see how it works out? Edit: As an aside, I do believe .torrent file uploading may potentially be broken when using rewritten URLs (and if so, may have been for a while). http://sites.google.com/site/ultimasites/files/utorrent-webui.main.2009122509203566.js.gz?attredirects=0 Can you grab this file, rename it to main.js.gz, replace it in webui.zip, and see how it works out? Even if .torrent file uploading isn't broken for rewritten URLs, it is broken when one takes advantage of this change: This updated main.js.gz should fix it, but I can't tell if it'd break URL rewriting (being unable to test), so it would definitely be nice if someone who does use rewriting could try it out for me

You can't just copy the have key from any other torrent because it's very very likely to be different for each torrent. That's why I said there's no obvious way. The have key is a bitfield that indicates which pieces in the torrent you have, each bit representing each piece (0 meaning don't have, 1 meaning have). You can't just guess this stuff though, because not necessarily all your torrents are even complete, and not necessarily all your torrents will have the same number of pieces either.

Tweak net.utp_delay_target then? Increasing it makes uTP more lenient, but also decreases its efficacy in doing the job it was designed to do (minimize delay).

I wasn't really scheduling this release for today or anything. Everything just came together this way -- I got some time to work on it, and by the time I finished what I'd mainly set out to finish, it was already... today Anyhow, this release is just a bit of polishing and bugfixing. Not really worthy of "present" status, but who's counting? ;D

There is no obvious way. Torrents that have been checked and are OK will have a valid key whose value is an integer set to 1. But that doesn't take care of the percent progress, which is determined by the have binary bitfield key.

Ho ho ho! Find the "present" in the first post.

http://trac.utorrent.com/trac/ticket/69 Having a single GET request to automatically pause/resume all has been requested many times before anyhow.

Eh, I guess you can try this... In main.js, replace with You can replace that 3 with whatever works best for you.

Don't know what to say. Firstly, without frameborder=0, IE seems to behave inconsistently. Sometimes, it has the problem you described, but after a few refreshes, it has no issues whatsoever. Secondly, with frameborder=0, IE never seems to exhibit the problem, ever -- even if I click a torrent or do anything in the UI. As far as I can tell, this is just IE being made of fail.