yashsingh1/xdaforums huggingface dataset:
[Verizon Samsung Galaxy Note II] tarheeldan:
Someone has got to have made this but I can't seem to find it. I'm using a "hubs" layout (one screen for social media, one for productivity etc) and I'd like to essentially have a horizontally scrollable launcher widget on each screen with apps that make sense for that hub.

Currently using simi folder widget which is cool, but I'd prefer the launcher bar that is activated by clicking on the folder to live in a widget right on the home screen.

Could anybody point me to a widget app like this? I'm pretty sure I saw a video where someone had this but didn't see details on what they were using. Thanks!

Edit: sorry if this would have been better posted in themes and apps. Please move if necessary.
[Verizon Samsung Galaxy Note II] heatpipe:
If I'm understanding you then what you're looking for is a dock that can display icons that are specific to the current page? Something close would be Nova launcher which provides a scrollable dock. If you haven't tried it, I highly recommend it!
[Verizon Samsung Galaxy Note II] tarheeldan:
Thanks, I'm currently using Apex and I really like it. I don't want just 1 dock (no matter how many pages on it you can scroll through). I want a different set of apps in a horizontally scrolling launcher bar widget. Then I could put an instance of this widget on each of my homescreens with different apps in each one. Then when I swipe from my "Office" homescreen to my "Photo" or "Video" homescreens this "launcher" widget has the appropriate apps for that hub. Hopefully that makes sense.

Like I said, simi folder widget is pretty good for this kind of setup, but I thought there might be a better solution out there.
[HTC One X+] crammo:
Hi,

I have unlocked HTC One X+ and the center part of touch screen stopped responding.

Will they accept rooted HOX+ or I need to unroot it?

EDIT: I live in EU.
[HTC One X+] skdubg:
you can send it
[HTC One X+] crammo:
There won't be any problems (like. they will mail it back to me and I'll have to pay for this etc.)?
[HTC One X+] Dfballa:
As long as you pay for it, there won't be a problem
[HTC One X+] crammo:
How much I'll have to pay?

I've read this and I'm confused: https :// fsfe.org / freesoftware/legal/flashingdevices.en.html
[HTC One X+] Krzysiec:
I suggest You to relock Your phone and flash RUU to get phone to "stock" It will show relocked in bootloader but here where I live (in Poland) it looks like they still make repairs under warranty whn relocked.
[HTC One X+] Dfballa:
You should call them and make sure
[HTC One X+] alexverzosa:
HI,

I'm from the Philippines and experienced the same problem you described (a portion of the touchscreen became unresponsive). I had unlocked my bootloader, rooted and flashed custom ROMs previously. What i did was to relock bootloader using the toolkit and revert to stock rom and recovery using a cid-specific RUU.

I sent it to the service center and they replaced the lcd and digitizer(they're fused together) for free.
[HTC One X+] Dfballa:
It shouldn't be a problem if your screen was broken and you had your phone unlocked and rooted because the root doesn't do anything to break the screen.
[Windows RT Development and Hacking] peterdn:
Kudos for having the patience to look though this monster.

It's my understanding that NaCl is still a pretty niche thing at the moment. Is it possible to easily either disable it or completely hack it out, or do other more critical parts of Chromium now depend on it?
[Windows RT Development and Hacking] GoodDayToDie:
I don't think anything truly depends on it. I'll look in the VS dependency hierarchy and see how many things list it, and how awful it would be to remove them.. after I get the other stuff working. I may pass on the sandbox as well, if possible; it makes the security guy in me cringe something awful, but as they say, shipping is a feature..
[Windows RT Development and Hacking] Harkunwar:
great
[Windows RT Development and Hacking] save_jeff:
Please make that happen !
[Windows RT Development and Hacking] GoodDayToDie:
Working on it! I've gotten over half of the projects to build and link, but some other stuff is adamantly refusing to work. I'm beginning to suspect I'll need to work from the other direction - rather than starting at the bottom and building all the dependencies, then combining them into browser components, and then eventually combining all the components into a complete piece of software, I may have to work from the top, removing components until the whole thing builds (at which point it will likely be useless, or all-but) and then seeing what I can add back in. I thought it would be faster to just assume everything can be made to work and only exclude something if it proved intractable, but at this point I've got a ton of very small components and almost no ability to combine them.

It would also help if VS was better at managing such truly immense tasks. For example, I have no simple graph of what all is and is not building, so I'm being forced to manually map that onto the VS dependency tree and see what is blocking a given component from building successfully, and how much is dependent upon it, one erroring project at a time (and there are a *lot* of erroring projects - my last attempt to build any substantial part of the system saw 50 of 400 projects fail).
[Windows RT Development and Hacking] save_jeff:
I thinkt tht is a mutch better taktic and mutch less frustrading.

I would love to see just a minimal version of it. After that all the small componens can follow.

50 of 400 is pretty good i think. Better then i expected
[Windows RT Development and Hacking] GoodDayToDie:
Bear in mind that the entire thing is 650 projects. If 50 fail at that level, many of the higher-level ones (dependent upon the lower-level) will fail too. I'll see what I can do. I may or may not be able to get v8 actually working (without it, the JS speed will be very bad, think IE8 at best) and I may have to fall back to the legacy libjpeg (which will cut JPEG render speeds by at least a factor of 2). Skia (2D drawing library used by Chrome) has a bunch of assembly optimizations that I need to get it to use the Arm version of instead. There's a couple of total hacks with the library files I've had to pull, which may or may not result in a working final build. We'll see.
[Windows RT Development and Hacking] flo850:
the v8 engine ( used in nodejs ) has been ported to ARM :

I still can't link : htt p://ww w.it-wars.com/article305/compiler-node-js-pour-arm-v5

perhaps it will help you

Edit : oups, I just see that another great user of this forum made the port of nodejs to RT
[Windows RT Development and Hacking] GoodDayToDie:
Yep... but they did it without v8. That's not an encouraging result, but I feel like I'm so close...
[Windows RT Development and Hacking] Slymayer:
Is there a GitHub repo so we can help or track the progress of the project ?
[Windows RT Development and Hacking] GoodDayToDie:
Sorry, not at present. There probably should be. The sheer size of the codebase is incredible (about 2.4GB) and having some way to share it practically would be good.

Also, I suspect this would go a lot faster if I don't have to repeat the work of others. I know that there's a working Webkit DLL out there, for example (though with several features, including the V8 JS engine, missing) and if I could get my hands on that it would drastically reduce the number of additional components I need to build. Currently I'm working on the sandbux, but expect that I will need to rip the whole thing out and basically have the browser run as though it was always passed the --no-sandbox parameter, at least for the first build. Too damn much assembly.
[Windows RT Development and Hacking] jtg007:
http://www.engadget.com/2013/01/22/google-chrome-native-client-arm-support/

This wouldn't have any impact on this project, would it?
[Windows RT Development and Hacking] GoodDayToDie:
It probably means that NaCl on Windows RT will be possible in the future. At present, I'm cutting it out of the build - too much x86-specific stuff there to port it over myself, and it owuldn't be able to run x86-compiled NaCl code anyhow.
[Windows RT Development and Hacking] someniceguy:
You might have bit off more than you could chew. It'd better if you put your current progress under version control on some public site so that other people may be able to help you.

It's a big and complex project. You are taking a lot of time, and understandably so. But just open up to other people and you could get this done faster. :cowboy:
[Windows RT Development and Hacking] GoodDayToDie:
Yeah, this is probably true. My life also got unexpectedly *busy* in the last week; a couple weeks ago I had many times as much free time as I do now, and so porting has slowed down.

My upload speed would take ages (literally probably at least a day of solid activity; it's embarassingly slow) to push the full source anywhere, but I may make the effort anyhow. I'll have to post it somewhere for GPL compliance in any case...
[Windows RT Development and Hacking] mamaich:
You may upload only the diff files, they'll probably be smaller then the whole distribution.
[Windows RT Development and Hacking] LastBattle:
Not to pour cold water on you however, IE10 is already faster than the latest Chrome build in Windows Phone, Windows 8.

I don't see the point of this.

I have personally jumped from IE8 > FF > Chrome and finally back to IE10 over the years depends on its usability, smoothness, speed, etc
[Windows RT Development and Hacking] GoodDayToDie:
Speed isn't the only reason to use a browser. I actually prefer IE myself, but there are some things that other browsers do better than it (in the case of Chrome, parts of HTML5, the syncing across Google services, etc.) Also, Chrome gets updated far more often than IE; IE9 was equal with Chrome on speed at its release, and was far behind by the time IE10 came out.

The reason for this project, though, is a mixture of interest in what it takes, and a desire to benefit the community. Microsoft has deeped that only software which they have blessed may run on the Windows RT desktop. I disagree, and have chosen (among several other things) to port a web browser because I feel that it's important for users to have choice.
[Windows RT Development and Hacking] lilstevie:
Some websites do not get along with the trident rendering engine. Some webdevs are so "Oh f*** IE I don't care" and block access to features just because it is IE. I have experienced this first hand on IE10 on my surface where it tells me to come back when I have a decent browser, only to not have the choice to do that.

This really isn't the webdevs fault either, for years IE was the scum of the internet, only recently has IE caught up to the rest of the browsers (and in my opinion exceeded some) but the years of IE being bad have left a lot of disjointed webdevs who won't even consider giving the latest IE a chance.
[Windows RT Development and Hacking] GoodDayToDie:
FYI: IE has a built-in user-agent-string changer. This can be used to spoof other browsers, causing the web server to think you're using Chrome or Firefox or similar.

This is using desktop mode; it might not be possible in Metro.

Developer Tools (F12, or the Tools button -> Developer Tools) -> Tools menu -> Change user agent string. You may have to refresh the page after switching. Note that this doesn't actually change the features that the browser supports, but it's a way to work around lazy or incometent web developers who just check for the IE user agent string and then get return something useless.
[Windows RT Development and Hacking] lilstevie:
This is too much effort for most people, hell even I won't go to this level of effort, I just move on
[Windows RT Development and Hacking] kenikh:
The way WebKit handles javascript and a few other things means that Trident can barf on sites coded by clueless devs. There are far too many web devs that think (or don't know better) that webkit dialect is the gold standard for web code. Reminds me of the old days when IE4/5/6/7 ran amok with "extended" HTML and an "enhanced" JVM, neither of which were built standards compliant.

"W3C...what's that?"

Frankly, I can't stand Chrome, but applaud the "can do" effort and look forward to the outcome!
[Windows RT Development and Hacking] GoodDayToDie:
Yeah, this is not a project undertaken due to my undying love of Chrome, merely to try and make it happen. That said, like you, I've seen sites which only work with WebKit-specific functionality... even if the exact function is now standard, and the webkit-prefixed version deprecated, they keep using that anyhow. It may well be easier to port a different WK-based browser, but Chrome is the big and well-known one.
[Windows RT Development and Hacking] someniceguy:
That's great man

When can you share the diff files? Many people may be eager to help but not to start from scratch

Cheers
[Windows RT Development and Hacking] Catscratch:
Is there any progress here?
[Windows RT Development and Hacking] someniceguy:
This port is dead, I am afraid.
[Windows RT Development and Hacking] GoodDayToDie:
No, it's not... it's just not something I can work on very often.

The announcement of the new rendering engine, which apparently vastly reduces the complexity, may be worth starting from a clean state for - at this point, I'm unsure how many of the issues I encounter are due to problems inhernet in trying to port, and how many are just due to mistakes while trying to correct those problems. This thing is obscenely huge and very poorly organized, with a lot of duplicated and nearly-duplicated code that sometimes nonetheless needs different treatment. Trying to make it all work is a nightmare.
[Windows RT Development and Hacking] RaiderX303:
If someone can point me in the direction for a guide on building RT compatible desktop apps I might see what I can contribute to this port
[Windows RT Development and Hacking] GoodDayToDie:
There's a thread on here covering how to go about building and porting apps... I can see how you missed it though, it's all the way down to the ninth item on the first page of the forum.

http://xdaforums.com/showthread.php?t=2096820

I'd be happy for some help, but I'm currently starting again with a forked, publicly-hosted project. This will make it a lot easier for people to collaborate. I'm trying to write some scripts to help automate the changes that had to be made, too... that would save a lot of time, if I can get them right. Hundreds of goddamn projects... hope you have a beefy PC!
[Windows RT Development and Hacking] bigsnack:
I take that this isn't being worked on anymore?
[Windows RT Development and Hacking] netham45:
Since this thread hasn't been posted in in 3 months, and the creator has stated as much, yea, that'd be a pretty good bet.
[Windows RT Development and Hacking] GoodDayToDie:
It's not quite right to say I'm not working on it anymore, actually... I still intend to return to it. However, there's a lot of other things that I've actually been able to make progress on, and besides, I'm not personally actually a fan of Chrome. I only have so much time for hacking on stuff, and this project ate a huge portion of it for a while without getting even close to completion.

That said, it *is* on my to-do list.
[Windows RT Development and Hacking] bigsnack:
A bit off topic, but what browser are you a fan of? I just want a different browser that isn't IE or QuipZilla(didn't really like it) when I tested it out on a friends Vivo Tab RT.
[Windows RT Development and Hacking] Myriachan:
I like Firefox, but I read that Firefox's JITter is ARM rather than Thumb-2. =(
[Windows RT Development and Hacking] southbird:
This is correct. It emits ARMv7 code. Interestingly, I was just poking around on this topic, and this blog post shows the author running a build of Firefox on jailbroken RT, with JIT disabled. I understand that no JIT is pretty much a dealbreaker, but it's still kind of neat.
[Windows RT Development and Hacking] GoodDayToDie:
Cool link! If by libffi the author means Python's Foreign Function Interface (which we couldn't get working in the current port), that would be awesome too. Re-writing the JIT to emit THUMB2 might actually be feasible, though, if the JIT was architected sanely. Mamaich took DOSbox's ARM jit and made it use thumb2 for his emulator...

Yeah, I'm thinking I may just have to turn off JIT and NaCl entirely in Chromium, which will make it pretty close to QupZilla but with a few more Googly features (none of which are of any particular value, or even desirable, to me personally... hence my lack of excitement). I primarily use IE, with Opera as my fallback / usable-on-crappy-connections alternative. On Linux I use Konqueror, but its Windows integration wasn't up to snuff last time I checked. I do have both Firefox and Chrome installed on Windows as well, but I don't use them much.
[Windows RT Development and Hacking] SixSixSevenSeven:
Someone needs to poke that guy.

NaCl is an x86 exclusive sandbox. Even check the google docs, they even say not for ARM. They are meant to be working on PNaCl which is aimed to be cross platform (think they are doing something like LLVM as an intermediate and then compiling that to the host architecture at app install time or something, pretty much delaying the intermediate > native compile step to the time the application is on the host architecture).

There is chrome on the raspberry pi (ARMv6) and debian for ARMv7. Wonder what they are doing on the JIT front, of course ARMv7 still isn't THUMB2. What was the issue with windows RT and THUMB2? Better still, why the hell did MS choose THUMB2? Memory footprint perhaps (THUMB2 supposedly has a smaller footprint than regular ARMv7)???
[Windows RT Development and Hacking] netham45:
As far as I can tell the reason that we're restricted to THUMB-2 is because the interrupt handlers don't bother checking which mode the CPU is in when they're called, and always leave it in THUMB-2 upon exit.
[Windows RT Development and Hacking] GoodDayToDie:
Some seem to return to the previous mode as you'd expect, but apparently not all of them...

THUMB2 is a more space-efficient instruction set. By using 16-bit instructions for most things, you can fit more instructions into a given cache line (or memory, or for that matter file on disk... but it's the cache lines that really matter). By using 32-bit instructions for some things, you can execute unusual instructions, or those requiring a large amount of data, in fewer CPU cycles.

It's the same reason why x86 uses variable-length instructions. It's just more efficient. Of course, it makes the instruction decoder on the CPU require a lot more silicon, but "2 bytes or 4 bytes" is a lot less complex than "anywhere from 1 byte to 17 bytes" or whatever the largest x86 instruction is.
[Windows RT Development and Hacking] Myriachan:
I am quite curious about what causes this. In order to do this, doesn't the interrupt handler actually have to intentionally change the mode? Isn't the processor mode just the low bit of the interrupted program's PC register? Wouldn't it have to OR the saved register with 1 explicitly?
[Windows RT Development and Hacking] GoodDayToDie:
While jumps use the low bit as the ARM/THUMB flag, I think the actual instruction set state is stored in a different register. It's possible that some NT interrupt service routines don't bother to test that flag before returning from an interrupt, and instead just sets THUMB2 mode regardless.
[Windows RT Development and Hacking] netham45:
It's stored in the CPSR register.
[Windows RT Development and Hacking] Myriachan:
I found the cause: the two functions that copy from a CONTEXT to KTRAP_FRAME, KeContextToTrapFrame and PspSetContext, are explicitly setting CPSR's T bit. The following code pastes are from 8.1 preview's ntoskrnl.exe.

KeContextToKframes:

.text:00439FD0 72 6C LDR R2, [R6,#0x44]
.text:00439FD2 00 F0 9F 80 BEQ.W loc_43A114
.text:00439FD6 5B 4B LDR R3, =0xFF0FFC30
.text:00439FD8 13 40 ANDS R3, R2
.text:00439FDA 43 F0 30 03 ORR.W R3, R3, #0x30

PspSetContext:

PAGE:0065C3F2 21 F0 73 AD BEQ.W loc_73DEDC
PAGE:0065C3F6 72 6C LDR R2, [R6,#0x44]
PAGE:0065C3F8 4F 4B LDR R3, =0xFF0FFC30
PAGE:0065C3FA 13 40 ANDS R3, R2
PAGE:0065C3FC 43 F0 30 03 ORR.W R3, R3, #0x30

0x44 is offsetof(CONTEXT, Cpsr). The BEQ is to the kernel case, which sets the mode bits to SVC.

If the next version of the jailbreak can neuter PatchGuard, changing those two ORR.W's to be 0x10 would likely be enough to fix ARM code in Windows RT.
[Windows RT Development and Hacking] netham45:
Fun fact: Patchguard is disabled if debugging is enabled. And since you've shown the ability to enable the kernel debugger with your exploit it shouldn't be much of an issue.

But, if that won't work out, wouldn't it be possible to change the address that interrupts call to our own that stores the state of THUMB, calls MS's implementation, and restores on exit?
[Windows RT Development and Hacking] Myriachan:
Sure, but if we don't use that exploit and try to release a different one...?

PatchGuard protects the interrupt vector registers, so short of virtualizing the whole OS, that doesn't work =(. PatchGuard is designed to be a pain in the ass. It's probably easier to go find it in the DPC and timer queues and kick it.
[Windows RT Development and Hacking] ericerk:
I'm sorry to be a pest, but is there a blog to keep up with the progress of this port, and possibly download semi functioning attempts / alphas and betas?

Thanks for your time!!!

--

Eric
[Windows RT Development and Hacking] SixSixSevenSeven:
There are no semi functioning alphas or betas. This is the place where if there is any progress it would be posted.
[Windows RT Development and Hacking] GoodDayToDie:
Yeah, sorry, I've been completely consumed by hacking WP8 in the last few weeks, so no progress here at all, really. I'll try to get back to it but I can't promise when.
[Windows RT Development and Hacking] ericerk:
The only reason I ask is because i'm trying to figure out weather I should keep the device.
[Windows RT Development and Hacking] GoodDayToDie:
Frankly, if you're that dependent on a single browser, you have problems that I can't really help with. If you're that dependent on a single browser *and* you bought a device that doesn't run it...? I really don't know what to say. If the existing WebKit browser for RT isn't cutting it for you, there's no point waiting for Chrome.
[Windows RT Development and Hacking] ericerk:
It's not that I'm dependent on a browser, I'm just not sure of the whole RT system... But since this is a browser thread...

My biggest qualms w/ internet explorer:

No Hangout support (via google plus)

No Google Video Chat options via Gmail or Google Plus.

Lag... Lag.. Lag!!

---

Off topic...

Don't get me wrong the jailbreak helps, and writing some bat files really helped make the system work better, but I still question the point of keeping it.

The dev team is the

only

thing reason I'm considering keeping it. Because you guys are

amazing
[Windows RT Development and Hacking] SixSixSevenSeven:
I am yet to have any lag issues since IE9 came out. IE10 is perfectly fine (especially if you use EasyList to block adverts from appearing).

Hangouts I can't confirm as they don't work in chrome or firefox either for me, the same server time out error in all 3 browsers, so internet explorer is at least trying hangouts. According to google they work fine in internet explorer though...
[Windows RT Development and Hacking] GoodDayToDie:
Heh... I can't even test any Google Plus features; Google thinks I'm not a real person and tries to block me. I hold them in slightly less contempt than Oracle or Sony right now, but that's pretty damn faint praise.

I also did think they were supposed to work in recent IE versions. This is especially true (on RT) because Google uses Flash for some of their web stuff, and RT supports Flash... but only on IE. It would be pretty funny, all things considered, if you actually got a Chromium port and it was less useful to you than IE10/11 just because it doesn't have Flash (and it won't; there's no way I know of to make it use IE's ActiveX plugin model and porting the NPAPI version is out of the question).