• Content Count

  • Joined

  • Last visited

  • Days Won


About APC

  • Rank
  1. Please add total files again to 1.4 UI as it was in 1.3 UI (MySync ab). This was for the most part the only way to quickly see if all the devices are in fact up to date. 1.4 now only shows total size - which is really no indication at all of total files per folder. See below.
  2. Not that I would retract anything I suggested so far, but I have actually debugged and resolved this issue [without the source code] - BTSync can send a cheque when they actually make money from it First, I simply assumed BTSync is not directly responsible and that it is the IE plugin's fault - which seems a safe assumption. The IE plugin works pretty straightforward, you simply give it files and it serves them. Also, the symptoms seems pretty much that CSS was not being served to the embedded browser. I could especially reinforce this line of thinking when I also started looking at Syncthing and got almost an identical issue, but this time on three browsers FF, IE and Chrome. So if neither BTSync and Syncthing explicitly set their CSS mimes in their HTML head tags, on windows, the registry would be used to determine the mimetype. So I checked. For whatever reason, it seems there are a lot of Windows machines for which the HKCR\\.css type is set to text/plain - which according to W3C spec would be considered invalid by the UA (browsers). I corrected this and suddenly Syncthing was up and running on 3 different browsers. Then upgraded BTSync to 1.4 again and boom - now works like a charm! Suggestions: I'll keep to my mantra of adding a HTTP daemon and CLI to windows distro instead of embedding IEHowever, for now, BT should update 1.4 to explicitly set the type attr of the HTML linking the CSS so BTSync is independent of the OS mimetypes - minimizing points of failureAnd in the meantime, win users could simply correct their registry mimetype to get BTSync 1.4 to work. Enjoy!
  3. Nothing, if it works and you did it properly Which is exactly the point. IE doesn't and BT didn't. I deal with IE issues every day in large companies (>100,000 emps) and this is mostly on intranets where one is in full control of standards, IE versions, etc. It is so bad, that certain IEs isn't even compatible with certain SharePoints - how ironic. I've even seen occurrences over the years where the latest stable IE release couldn't render microsoft.com. Everyone knows IE isn't on w3c spec and hasn't been for years now, and it has and always had lots of compatibility issues just between versions leading to statements like "BTSync will work with IE gt 8" but clearly it doesn't OOTB with IE11? So, now what? There is a "window" of IE OS browsers BTSync will work with? Nice for cutting down market share... that is. That being the bottomline of the argument, if you have to embed a browser, at least pick one that works from one version to the next or one that you have full control over which version your software will be using. And even then consider not embedding at all and instead add a pure HTTP UI to BTSync which will simply render in whichever browser is default on the OS. Works for Linux BTSync, as does the CLI - both of which are non-existent on win.
  4. All three main browsers have been embeddable for some years now (FF was probably first since the late '90s if memory serves - I clearly remember using it as ActiveX control in Delphi 5 days - and did it that you could even choose if you wanted to use IE or FF as the engine) - takes some digging, some tweaking and a couple of SDKs to do it properly though. As said, also wouldn't be my first choice these days. If you really want a HTML-ish interface there are a million nice toolsuites available to do it with in anything from VS to Eclipse. PS: Also less trouble than you would think to embed FF. Nice thing is you then have a safe and stable snapshot of FF only for your app. As long as it works for your app, you don't have to worry about updates, fixes, patches, etc - it only every browse to localhost, so proxies, caching, security, etc all goes out the door. All you really use is the rendering engine. And, as long as it works for your HTML, it is irrelevant to ever update it. These days however I would probably have gone for a WebKit rendering engine though - then you would have been compatible effectively with any Chrome or Android rendering - and master of just about 3 billion devices.... if, that is, I could not go for a pure httpd daemon and you held a gun to my head and forced me to embed "something". Millions of projects like this: http://sourceforge.net/projects/wke/
  5. That may be Marko. However, in my particular case I have a prime machine with Win7Ult, a lot of hardware, one AV running (MSE), IE11 up and running and up to date - in fact, my own machine is completely up to date with all the latest windows patches. In fact, you could not ask for a better "up to date" example of a windows machine. Yet, it fires up with a "textual" UI just like anyone else's. So this "is it the IE version?", "is it the IE settings?", "is it the AV?" and "is it the firewall?", is typical dev-speak for grasping at straws. Unless you embedded a virus in BTSync or the firewall is blocking localhost - both of which I highly doubt - the cause is obviously neither. BT made two prime mistakes: Choosing IE as browser on windows (since there are a millions things that can in fact be changed on it that will prevent your UI to load - most if not all of which you can pretty much disable on the embedded version btw) It is clear that the HTML is in fact loading, but not the CSS - something which could and should have been tested for on any up to date Win7 with IE11 VM - before it was shipped to the testers. Most likely a dev did actually test it, but forgot he actually had to tweak a registry setting or relpath along the way to get it to work. Or tested it on 9 and 10, but not 11. Fact is, was FF chosen none of this would have happened, since FF embed becomes a distinct copy in your app's folder which neither shares settings, nor folders with any other installed FFs, nevermind IE or Chrome. Yes, it would bloat the BTSync install, but since when does a 10MB download bother windows users? BT simply took the easy road with IE because it seemed obvious at the time it then wouldn't require any additional files to be part of the BTSync distro. This would have been true... 10 years ago, before all the court cases and before Chrome, but is no longer the case. I know because I too made the same mistake ... about 10 years ago. Personally, these days, I would simply have steered clear of "embedded"-anything, and simply have added a HTTP GUI using the user's default browser to BTSync. Which BT has been asked for in a million posts and which has been available on all the linux distros for months. Yet, is still lacking on win. Easiest thing in the world to embed a simple http daemon in BTSync, or use Lighttpd if you want a proper one. Even more simple to make the BTSync popup menus point to URLs instead of actual win UIs - and then the user could use whichever browser they liked best and everyone would have been happy. BT could have done this in half the time it took to do a halfhearted-attempt-to-embed-IE. Look, don't get me wrong, the basic principles of BTSync is solid, it could be great product, I have hit my head against the same thing in the past and it obviously is a huge task to cater for all the platforms - so I have a) a huge amount of respect for the devs and a lot of sympathy, but shoot gents, a 10min session of due diligence and planning could have gone a long way to prevent a disastrous release like this one. Just actually listening to the users of BTSync would have already had you 100% on the correct path.
  6. +1 Development lessons BT are learning the hard way today: You don't make big UI change like this, not test it properly and leave your software without a GUI - effectively making it unusable. At a minimum BT should have kept the old UI around for a version or two as alternative for a situation just like this.You never embed IE. Rather opt for embedding FireFox or Chrome. IE is customized by every big corporation, it is neither forward nor backward compatible even on CSS level.You don't assume Windows users are all "obviously" using IE. Reality is IE has not been even the 3rd most popular browser on Windows for almost 5 years. Only place IE is more "popular" is in the Fortune 500 companies where a "Microsoft only"-policy exist, and they are definitely not even testing BTSync... yet. Suggestion: Revert back to 1.3. And because BT also did not test reverting back and 1.3 won't run on the same settings as 1.4, do the following - Uninstall 1.4, then go delete your AppData\Roaming\BT Sync folder, reinstall 1.3 and setup all your folders again. Worked for me.