Jump to content

Ultima

µTorrent Helper
  • Posts

    27,924
  • Joined

  • Last visited

  • Days Won

    4

Posts posted by Ultima

  1. Yeah, I noticed that during development, but chalked it up to a Firefox bug that cropped up in conjunction with the MooTools upgrade. I'm still not sure if that's the correct classification (it may just be that MooTools isn't paying attention to the W3C specs, but I don't know for sure). Either way, I was hoping Firefox would "fix" itself (no other browser behaves in this way), but that's just silly idealism, so I'll work around the issue.

    For anyone wondering what the exact issue is:

    When you perform XMLHttpRequest.open(), you can optionally include login credentials with the request. The MooTools Request object wraps itself around XMLHttpRequest, and in the process, sends a username/password with the request. If I don't include a username/password when creating the Request object, MooTools sends undefined instead for the login credentials. I would think browsers should be ignoring the parameters if they're undefined, but Firefox doesn't. Instead, it stringifies 'undefined' and uses that as the username/password, and so every XMLHttpRequest gets sent under the login undefined:undefined. Needless to say, you end up with this bug. The workaround? Send empty strings for the login credentials with all requests if you don't want to override the existing login. Kinda stupid, but oh well.

    As it turns out, the MooTools devs seem to have known about this behavior, but decided not include the fix by default (it was commented out). Anyway, it's uncommented now, so it'll be fixed in the next release. (Which should be soonish, as there are too many regressions in the last build for me to be comfortable with. Just need to work out some other changes before release.)

  2. Adding torrents anywhere, in any way, crashes the current 3.0. Not WebUI's fault.

    I have no idea what you're talking about when you say that you can't see the directories.

    jYMjr.png

    Edit: Seems action=list-dirs is another request that requires µTorrent Web (Falcon) to be enabled. Not WebUI's fault either. I've bugged the devs enough about this, so the ball's on their court.

    Sorry, I'm an idiot.

  3. Yeah, another v0.380 WIP. No different from how there are multiple µTorrent v2.2 betas. It isn't labeled "stable" yet due to its having tons of experimental changes. You can always check the About dialog (F2 in WebUI) to see the build date of the one you're currently running.

    And in true WIP fashion, I already discovered a few regressions with this build that came as a result of the MooTools upgrade (yet again... seems like very time I upgrade MooTools, there's a break somewhere). Specifically, multi-torrent support for the Properties dialog is broken, and the Files tab context menu doesn't work. Will be fixed in the next build, whenever I get that out.

  4. Trick or treat!

    v0.380 WIP (2010-10-31)

    + Feature: Download path selection (uTorrent 3.0 and newer only)

    + Feature: Full torrent job removal support (uTorrent 3.0 and newer only)

    ~ Change: Append log entries to bottom of log

    ~ Change: Default to using virtual listview (rather than paged listview)

    ~ Change: Hide "Remove Label" if all selected torrent jobs have no label

    ~ Change: More robust handling of labels with special characters

    ~ Change: No longer requires compatibility mode when viewed under IE

    ~ Change: Setting "Max. rows per page" to 0 uses full virtual listview

    ~ Change: Show "New Label..." and "Remove Label" at top of Label submenu

    ~ Change: Speed graph line colors changed to more closely match desktop UI

    ~ Change: Support gui.log_date

    ~ Change: Updated MooTools to v1.3

    * Fix: Context menu display issue in some situations

    * Fix: Guest page broken after Transfer Cap usage history implemented

    * Fix: Guest page listviews displaying incorrect data sometimes

    * Fix: Language selection dropdown missing in IE

    * Fix: Some comboboxes don't have a default value set in IE

    * Fix: Status column not updating while torrent is being checked

    * Fix: Torrent job items being updated with data for torrent job on another page

    * Fix: Unstyled General tab item in IE

    Massive changelog (relatively speaking anyway).

    Finally got around to implementing download path selection several weeks ago. It requires µTorrent 3.0, but the sub-path support is very limited due to a backend limitation. Specifically, sub-paths will not be used unless the sub-path already exists in the filesystem as a directory. Nearly useless indeed, but it wasn't my call. I'll bug the backend devs some more about it, but for the time being, enjoy :P (At least base path selection definitely works.)

    People who hate the paging system used in the listview can rejoice, because I finally got around to fixing the virtual listview support. Gone is the need to flip to the next page to see more torrents -- just keep scrolling, and it'll dynamically populate the rest. This is enabled by default for clean installs of WebUI. For users upgrading and wanting this virtual listview behavior, set the max number of listview rows to 0 in the Preferences.

    Anybody experiencing the issue schnurlos previously reported also have cause for celebration now, because I finally managed to reproduce the problem and fix it. Sort of. I don't like my fix, but a lot of the listview code is a mess already as is. I'm still trying to clean up whatever I can, but it's not simple. Interestingly, this bug only affected listviews because they were using paging. Had the virtual listview support been fixed sooner, this bug might not have been noticed, so I guess it's a good thing I kept putting virtual listview support off.

    Um, yeah, in other news, this build also has better IE support too (no more need for compatibility view). The changelog tells all.

  5. One alternative is to use WebUI to set it for you too:

    http://localhost:port/gui/?action=setsetting&s=logger_mask&v=-1

    This works under the assumption that you've set up the login for WebUI, and disabled webui.token_auth (temporarily anyway). Advantage here is that you don't have to get involved with manually editing settings.dat, or restarting the client. Disadvantage is that you have to remember to restore the WebUI-related settings afterwards. Logging to file can be handled via the usual Logger context menu item.

  6. Indeed, did a bit more testing just earlier, and it seems like it may have been coincidental -- or maybe it happens more frequently with more network/disk activity. For the most part, I only get very short hangs, but every now and then, I get hangs that last upwards of 5 seconds. Based on the way I'm stating this, it may seem like it's a rare occurrence, but the fact that several people have been complaining about this in recent weeks indicates that it isn't actually that rare.

    It doesn't happen for me every time I try changing the settings, but it happens often enough. So the only real problem is figuring out how to reproduce these long hangs reliably enough to debug. Just repeatedly pressing Ctrl+P and Enter eventually induces a hang, and I've reported it accordingly. Seems like alus is sorta investigating it too (he's been seeing hangs on occasion as well).

    Edit: Alrighty. So alus tracked the bug down to potentially being a problem with closesocket() randomly taking a long time to complete on Windows 7 (the only OS he and I have available to test). Interestingly, I also noticed a while back that all of the reports on this problem were also from users running Windows 7. Not sure if it also affects other OSes based on the more current NT kernels (Vista/7/2008), and so far, I have yet to see any reports from the older kernels (2000/XP/2003). So... just to confirm (Simon100), what OS are you running?

  7. The specs don't define how files are to be handled by the client.

    0-byte files are of very questionable value. They're nothing more than filesystem data, and if exploited, could be a simple way to inundate a user's filesystem with tons of junk filesystem entries instantly. If anything, I'd say 0-byte files shouldn't be "allocated" at all unless the user explicitly tells the client to do so somehow (pre-allocate all files, or some extra option in some menu).

  8. Builds pushed out through the auto-update server are placed there manually. Not every build gets put on auto-update, and even those that are put there are generally given buffer time and a staggered rollout on the off-chance that there's something horribly wrong with the build.

  9. He's probably referring to having an API request. Rainmeter is a widget engine, so it probably has its own custom widget to throw the data on screen (it doesn't use the WebUI frontend, only the backend). Without scripting, it isn't simple (if not impossible) to display only a subset of the data, and that's why poiru wants an extra parameter.

  10. Depends on what you mean by "true".

    - It probably is true that he saw that message from his anti-malware software.

    - It probably isn't true that there actually was a virus.

    Why probably? Because that depends on whether or not his computer itself was already infected with malware. And historically, many anti-malware packages throw false-positives on µTorrent anyway.

  11. Just tested it on an iPhone. WebUI v0.380 looks okay on it (albeit, without any scrollbars on the listviews it seems). I'm not sure what you're referring to. And I didn't really alter the UI resizing code much for v0.380 anyway.

  12. Yep, I know of the problem with Web needing to be enabled. It's really not something I can resolve from the WebUI frontend. I have bugged Firon about it, and have brought it up with a dev. mcdonald has said that stated that it'll be resolved in the future.

    I should probably note that any features that require a non-stable version of µTorrent should themselves be considered and treated as experimental features, so expect bugs :P Regarding the duplication, I did run across such a problem while I was first implementing it, but (thought?) I fixed it by the time I'd released it. I don't seem to be able to reproduce the bug.

  13. µTorrent 2.0.x has been released for a while now, with many changes since 1.8.x. Among the biggest changes are full uTP support, UDP tracker support, and a transfer cap. As well, several security vulnerabilities that affect older versions of µTorrent have been fixed.

    See the changelogs!

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

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

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

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

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

    Download: http://download.utorrent.com/2.0.4/utorrent.exe

    Yes, this is a tad bit late an announcement, since 2.0.x has been out for approximately 3/4 of a year now, but I guess it's never too late. Adding to this thread for the sake of continuity and completeness. And, I suppose, to notify anybody who's been relying exclusively on this thread for update notifications...

  14. Regarding the titlebar moving off-screen, I'd complained pretty extensively to Firon about the minify button somewhere last month...

    [00:08:58] <&Ultima> oh, and uh, that toolbar button for minifying the UI? yeah... having µTorrent center around it is an interesting idea, but in practice, it makes it rather easy to lose the titlebar off the top of the screen

    [00:10:10] <&Ultima> there's hardly any reason to have the entire UI reposition itself so that the mouse remains on that button

    [00:10:25] <&Ultima> I mean, it's not like people will be toggling between mini and full UI that often/quickly

    [00:10:34] <&Ultima> or is that seriously a use-case scenario?

    [00:16:05] <&Ultima> just to note, losing the titlebar isn't really a problem with centering around the mouse in and of itself -- it's a problem with the fact that µTorrent doesn't actually match the button position exactly after the UI mode is toggled

    [00:22:10] <&Ultima> if you don't want to lose the titlebar, but want to keep the recentering, then at least do it properly :\ if the user clicks position (X,Y) relative to the top-left corner of the button, then when you recenter the UI after click, make sure the button's top-left corner is (-X,-Y) away from the mouse position. currently, it seems to recenter by centering the button at some position (-A,-B) from the mouse, where A and B are fixed (so it keeps sliding around every time you click anywhere but point (A,B) on the button)

    [00:22:15] <&Ultima> if there's some technical limitation preventing it, just don't do the half-way "solution" at all D;

    [00:23:15] <&Ultima> er, centering isn't the right word, but you get it

    [01:10:27] <&Ultima> I'm pretty sure it's been a problem ever since the recentering thing was first implemented, but I never bothered to test it seriously

    [01:13:24] <&Ultima> even given my proposed "fix" above, there's no perfect way to prevent the window from going off screen because of the differences between minified and full UI (namely, the menubar being present in full mode, but not in minified mode)

    [01:14:20] <&Ultima> you can prevent it by just clamping, but then the window is no longer centered properly with the button around the mouse

    [01:15:53] <&Ultima> and this is exactly why I think centering the UI around the button when it's clicked is a bad idea (aside from the fact that, as mentioned above, this seems to have an extremely unlikely use-case scenario to begin with)

    [01:17:14] <&Ultima> I'm betting the button was placed to the right of the search bar in order to minimize the differences between the full and minified UI so that the recentering doesn't look as jarring

    [01:17:58] <&Ultima> which is a very silly compensation for a pointless feature. I've never seen the search bar be to the left of any other button in any application that implements a similar search bar

    [01:20:01] * &Ultima pokes Firon

    [01:20:16] <&Ultima> I'm hoping you don't tl;dr this stuff :P

    [01:20:45] <schnurlos> about the centering of windows: I'm no programmer, but isn't the window size and position known and checkable? If utorrent checks it before it's drawn, why not move it to be inside the screen?

    [01:21:35] <&Ultima> it is easily possible, but as I've mentioned, if it has to clamp the position, then the window/button would no longer be centered around the mouse, which would defeat the whole purpose of centering

    I do believe someone else reported this problem not too long after recentering was first introduced too. I say it should just be removed, because honestly, I can't imagine anyone needing a way to quickly toggle between the mini and full UIs. Not that Windows Media Player is some kind of model application, but when you toggle between its player and library view, for example, it doesn't bother recentering the UI around the mouse either. It just lets the mouse fall outside the window bounds on switch, which feels perfectly fine to me, so I don't see why it shouldn't be fine for µTorrent too.

    Edit: Yep, icleolion got to the report first.

×
×
  • Create New...