Ultima

@Snowknight26: Will fix. I guess I should give the compressed version a whirl before actually releasing next time. @DonGato: Keyboard shortcuts / Hotkeys, and I'm not sure what you mean by "small version". @braykov: I develop this primarily under Chrome. You have any extensions or Greasemonkey scripts installed or something?

Wait, what??? Ultima actually released WebUI with RSS support? This must be some sort of miracle! Notes / Rant Yeah, I've been sitting on this for a long while now because it's somewhat incomplete, but I'm tired of waiting, and I can't really make much progress right now due to various factors. So instead of letting it just bit-rot doing nothing, I decided I'd do something useful with it and at least let users provide feedback. That, and I feel like a part of the reason why the backend has remained stagnant for so long despite all my complaints about RSS support is that there's no one else complaining, and no real way for the devs to even see the problems. So here's exhibit A. As I've said, it's still incomplete, so you can expect a few bugs/limitations right now. The most annoying issue lies with filter modification. Because the backend is broken by extremely poor API design, various options won't be set properly when you change them. Those who care to know the technical details can see this thread. The fix is relatively simple, but I'm in no way interested in writing stupid logic in the frontend to work around stupid logic in the backend. So, you'll have to put up with it for now, but it'll magically fix itself if the backend is ever fixed (and if never, then I really have no faith in the future of WebUI). Anyway, a workaround right now I suppose would be to disable every checkbox option for filters, hitting Apply, then enabling every option you actually do want to use, and then Apply again. The checkbox next to the RSS filters isn't really usable either for the time being, since it's not implemented in the backend. Some columns in the RSS feed item list aren't implemented either, because I have no idea how to interpret the data sent by the backend (if the backend is even sending the correct data). The Date column is just broken, period. Unicode isn't properly supported. Again, all the backend's fault. The rather incomplete backend documentation on WebUI+RSS did the exact opposite of making me love the API too. So the moral of the story is that RSS support is somewhat broken right now because the backend is somwhat broken. Oh, by the way, it should be well noted that only µTorrent 3.0 allows you to add/remove/modify feeds and filters. µTorrent 2.2 will allow you to at least look at feeds/filters and add torrents from feeds, but attempting to manipulate the feeds/filters themselves in µTorrent 2.2 will do nothing. Before anyone asks why RSS is implemented similarly to the way it was implemented in µTorrent 1.7 and prior, my explanation is that... I just don't get the current RSS UI implemented in µTorrent 1.8. RSS doesn't belong in the main overview because it does not, in any way, meaningfully interact with the rest of the UI elements in the main overview. Toolbar buttons? Useless for RSS items. Detailed info pane? Shows nothing for RSS items. Category list? It doesn't make sense to select both a RSS feed and a regular torrent label/category. Context menu? Completely distinct from torrent job context menu (with extra useless logic to make sure they remain distinct when you have mixed selections). So why is it in the main UI? Beats me. More screen real estate? Hardly any reason to destroy proper/logical UI design. In fact, the RSS Downloader dialog in µTorrent is resizable anyway, so there's no reason screen real estate should even be a consideration on the desktop UI either. Finally, I would love to have removed the WIP tag from this release, but... well, see all of the above. tl;dr µTorrent 2.2 only has read-only support for WebUI+RSS. µTorrent 3.0 has read/write support for WebUI+RSS. When editing RSS filters (favorites), checkbox options will behave erratically. If you need to modify them, disable all the checkboxes, Apply, then enable the ones you need, Apply. The RSS filter enable/disable toggle doesn't work. Various columns in the RSS feed item list are broken or incompletely implemented. Unicode isn't properly supported, so you will see weird characters if you use Unicode feeds. RSS Downloader is the centralized location to find everything RSS in WebUI.

So you're saying that you've looked at µTorrent's source code and found no instances of 10.5+ API calls that weren't present in 10.4? Or that all 10.5+ API calls that µTorrent makes are easily rewritten for 10.4-? Are you so certain that everything it's doing with the new APIs was always exposed to developers (no matter how roundabout a method was needed for older versions of OS X)?

http://www.winehq.org/download/ If your Linux distro doesn't isn't listed there, then you're probably out of luck unless you can figure out how to install 1.2+.

Wine bug. Update to Wine 1.2 or newer (preferably the current dev builds).

You don't seriously expect Apple to add stuff to 10.5, and have it magically work on 10.2, do you? That's like saying that Safari 1.0 could support modern HTML5 web apps just because developers "will" it to. The fact of the matter is, new API functionality gets added to new software all the time, and there is no reasonable expectation for it to work with software that was created before the API was added. An API isn't just a number as you seem to think it is.

http://forum.utorrent.com/viewtopic.php?id=88772

Ehm, Fornit is asking for date columns, which has been requested a bajillion times before, but isn't possible because the backend doesn't send the information.

Security isn't a feature. Yeah, they're fixing an exploit, so where's the contradiction? That defeats the whole purpose. The exact reason why this exploit could be used is because it's possible by default. It was always possible to prevent if the user optionally edited bt.no_connect_to_services_list themselves. You're basically asking for the devs to revert the thing entirely, and to leave it that way.

Last I checked, devs didn't need users' permissions to work around exploits. As for node counts being low... Are you really suggesting that 60+% of all peers (or just the peers accessible from known bootstrap nodes) are using ports < 1024? Seriously, I doubt it's related. Anecdotally, I just enabled DHT and µTorrent easily connected to 300+ nodes.

You're going to need to find out what the error indicates: http://forum.utorrent.com/viewtopic.php?id=92320 I've added the ability to see the error from within WebUI, but it's not yet in any public release.

If there's a problem with the backend request failing... then well, it's a problem you'll have to take up with the µTServer devs. Either way, I don't see any reason this should fail on µTServer when WebUI works too. The only time getsettings fails is if you're not authenticated using the main WebUI account (using a guest account, or no account at all).

@Barbas06: Not really. The backend doesn't supply the frontend with the bandwidth allocation information. A Tracker column would kill a ton of bandwidth if I were to implement it the only way it's currently possible -- and it would be very inefficient too. @yipikaye: http://forum.utorrent.com/viewtopic.php?pid=553340#p553340

Don't know what to tell you. I can't reproduce the problem here. The following is what should (and does) happen on FF 3.6.13 as you move your mouse cursor over the submenu:

Screenshot? Browser? The point of the menu changes was to prevent menu items from ever being inaccessible again due to falling off the edge of the screen, which could've happened in any number of ways. If you mouse over the submenu, it should scroll as you move up and down now. Arbitrarily long menus should always work, unlike with the old system.

Nah, the HTML wouldn't flow that way... The problem appears to be with the HTML compressor. Not sure why it's stupidly stripping the space only for that one item. I guess I have to put a instead of a plain space, or use CSS like I'm actually supposed to...

I wouldn't know what to tell you. My screenshot above shows what I see, and it's what I see in all browsers I've tested. As well, I don't do anything special for the Limited box compared to the other boxes.

@simplifyit: Not sure what you're referring to. It looks perfectly fine to me... @yipikaye: Funny you should ask right now. I just finished implementing most of RSS only yesterday. It's able to add/remove/update feeds and filters, though there are currently a few issues and limitations due to backend issues. I'm still polishing up the code (lots of work to do there), but if all goes well, you should expect to see RSS (finally) in the next build. With bugs/limitations as should be mentioned in the notes for the build, assuming things still aren't fixed in the backend by then (good chance they won't be fixed for another while). I still have other plans for the next build, so don't expect it immediately -- maybe on the order of weeks, since I still have other Real Life™ obligations. And uh... various aspects of the API for RSS are annoying to figure out due to the really horrendously written documentation. Unless you have a ton of free time on your hands to experiment, I'm not sure it's worth the stress.

If that happens, then it detected that you're running on a guest account. Meaning /gui/?action=getsettings is probably failing.

@lithopsian: Yeah, check the latest build (changelog/notes here). Most likely a utserver backend issue. It works perfectly fine on Windows.

It's currently impossible due to backend limitations -- else you can be sure it would've already been done. I've already requested it of the µTorrent devs, so there isn't much else we can do other than wait.

The links still work for me... But here are mirrors for the latest version: v0.7.1 x64: http://www.mediafire.com/?1u1dtf02u4nb15d v0.7.1 x86: http://www.mediafire.com/?jaizmmhd2aw

Ho ho ho. Notes The main focus of this release was to polish up existing stuff. To that end, I've heavily tweaked performance in this build so that WebUI should finally be usable on most browsers now. Chrome users probably won't notice any difference, but Firefox and Opera (and I suppose IE) users should find that it loads more quickly, and is more responsive now. For the technically inclined/interested, the biggest speedup was achieved by patching MooTools' $ function. It's extremely slow at finding element IDs (probably because the Slick selector engine is unoptimized, despite the MooTools devs' claims to the contrary), and so browsers other than Chrome end up taking tons of time just looking for elements. I have no idea why Opera was hit the hardest, but by discovering and fixing this, I managed to improve starup times on Opera by probably 80-90% (rough estimate). The fix was as simple as wrapping MooTools' $ function by performing document.getElementById() before passing the element into document.id(). Anyway, performance aside, the other somewhat-major bit of polish applied is that menus should no longer ever fall off the screen. If a submenu hits the right-edge of the screen, it'll show up on the left instead. If a menu is too long, it'll scroll instead on mouse over. The downside here is that IE6 probably doesn't support this all too well, but frankly, I don't think I should care anymore about such an antiquated browser anyhow. Pause/resume all is finally implemented in the main menu icon now found in the status bar. There are other minor changes all around, and the changelog should list most of them (though I probably missed a few things). Yep, RSS support still isn't there. I have a large chunk of it done, but it just isn't ready due to various factors. I didn't want it to hold the release up, so I cut my losses and pushed out everything else I've done since the last release. RSS support is the last major blocker that's preventing me from removing the WIP tag from the otherwise rather mature v0.380. Anyway, have a safe and happy holiday season, people!

Oh, yeah, I think it broke in Chromium only because Chromium's function bind() conflicts with mootools' Function.bind(), with the conflict arising as a result of Chromium having updated to match the updated ECMAscript spec for bind() a few months ago.

Hm...? "Linux Support" isn't something to visit. It's just a section of the first post in that thread I linked to that basically tells you what's expected of you if you run into bugs while running my WebUI under µTorrent Server...