Related
I think that, after has proved two roms that there is in this moment, many of us have valuable contributions that made to help to perfect the final score. I have seen many very positive dispersed suggestions for the different threads that treat the topic.
I think that it is better to open a thread exclusively for suggestions and only suggestions (although they could accompany oneself of a comment) of progress, which is plain and practical for the consultation of the creators of roms.
Also I think that if some suggestion is debatable, we could debate on it and even to vote if we weigh that it must be included or not.
Clearly, they will take their own decisions according to what here they see and of their own perceptions; but it is sure that we serve them as help.
I begin with my own suggestions:
Only for that of Phil:
- To include the STK services to be able to use dual sim.
For both:
- To support most of free possible memory, by means of:
*To install only a source for defect and to be able to have others by means of cabs
*To include neither Windows Live nor the Office, not even Voice Command for defect. To add them in cabs.
- If someone manages to make to work this, to include in the rom (WLAN IP Manager) since it would solve the one that for me is the worst defect of Tornados: the inability to get connected with fixed IPs.
Thanks
PD: I have seen many different, as one on a driver for the joystick, someone on the starter, others on the multimedia player, etc., that also would like to see me implemented, but I hope that there should be the first ones in contributing them who posteen here, so they will be able to make it much better than I.
Excuse us, to me for my horrible English and to Google for his horrifying Spanish.
You are contradicting with yourself. You are saying that they must leave as much free memory as possible and then you are asking for a feature only a few of us will ever use.
I believe the roms must be left as clean as possible. A couple of things such as HTC tasks, file manager, comm manager etc. may be default. But other than that anything can be left out. This way we guarantee that everybody has his own OS style (like linux, unlike windows).
Right now I am using Phil's rom and it is quite stable and fast and I am very satisfied. There are some debug related applications in it which will probably be removed in the next release. And the rest, for me, just works like a charm.
wrong section
burkay said:
You are contradicting with yourself. You are saying that they must leave as much free memory as possible and then you are asking for a feature only a few of us will ever use.
Click to expand...
Click to collapse
Which? If you talk about STK services, to where I understand I believe that it is an own service of the phone that does not consume resources that only become “visible” when there are several options of to switch on. I do not believe that that is to request a new characteristic, but to correct an error. If you talk about WLAN IP Manager, the same. It does not do more than small adjustments in the registry to correct a tremendous error of the Tornado.
I do not see that it requests nothing else, but good, if some of the things comes aside in cab installable, because better.
It seemed to me very interesting something of a magnificent one to driver for joistick, but no longer I know nor by where it walks.
In order to themselves separate the possible discussions of the suggestions, I believe that it is going to be better to put in negrilla these last ones. In case the creators of roms want to review the thread of a look it will be more easy.
i did have a small list of improvements made some time ago:
ok phil.
if u remove windows update, at least supply it as a cab in the extras folder.
channels don't work.
long pressed side button does not work! it used to start voice note record for the sda and i'd like that to work.
mms.
better camera software. btw htc camera makes the phone SLOW..... not a good one. need an alternate
enable profile switching to silent when long pressing '#' key
default folder for saving pictures on storage card is not my documents\my pictures any more but a lame dcim folder. that would be nice to be changed.
also, sometimes when answering a call, the keyboard stays locked, the call is still on, but the home screen is active and not the call screen.
joystick seems much better but sometimes it doesn't want to work as it should. maybe another driver; if not, this one is good
we need wpa2 for wifi enabled.
also add in the extras folder:
moblue
tcpmp with extra codecs
htc audio manager could be good
if u need the cabs for moblue and htc audio, i have them
there is an newer version of sim manager. v6.10. has a couple of new things (got it if u need it)
and maybe add a good version of opera. not the java one.
we also need a good midlet manager
also a good instant messaging program. maybe a multi client one like oz mobile im, or like im+
\
Click to expand...
Click to collapse
Click to expand...
Click to collapse
Very worked, correct an useful list. I am in agreement with almost everything.
I believe everybody wants is a small, fast and clean ROM, with the latest and more reliable drivers.
Imho, any application that is not mandatory, OR if could be installed in SD should be packed together with the ROM in a ZIP file, so everyone could choose which extra features to install.
Since the extra features installation take some (lot of) time reset or first installation. - It would be Great if someone could manage to create a package installer, where the user may choose what "extras" to install.
nCoder said:
... if someone could manage to create a package installer, where the user may choose what "extras" to install.
Click to expand...
Click to collapse
Excellent idea. Save lots of time. (Excuse me for I put it in "bold")
Headset profile is missing
I would also add Autokeylock and Right Menu in ROM. They seem to me two essential littel applications.
right menu is not free.
i don't think it's a good idea to include all those 3d party, just the esential stuff (as mms, camera, etc).
DSF said:
right menu is not free.
i don't think it's a good idea to include all those 3d party, just the esential stuff (as mms, camera, etc).
Click to expand...
Click to collapse
Ohhh. It's correct. Excuse me. I thought that it was free. It's mine for a long time.
I agree totally in the rest, but… for me Autokeylock isa essential stuff.
Just give us a basic version, do not include things which can be installed in storage card to maximize the available space
Well said, I agree.
oh yeah... i did forget one bug for my list:
the wm6 t9 does not work right. it seems it has been borrowed from a chinese rom or something because when you switch between typing modes with the * key, it displays some chineese characters.
To break the Modaco xT9 language pack so only the necessary language can be installed .
Very important. About 2.5 Mg will be saved. I know It by experience
Dezamundano said:
To break the Modaco xT9 language pack so only the necessary language can be installed .
Very important. About 2.5 Mg will be saved. I know It by experience
Click to expand...
Click to collapse
Ditto. Good idea!
This topic has been floating around the forums for a long time now. For as long as chefs been cooking, they’ve been trying to cook their “perfect rom.” Well…unfortunately they can’t do it by themselves. They need some help from us…so this thread is for any and all feedback we may all have as users, to offer to our chefs in order to achieve our goal.
Keep in mind guys, we’re all different people, we all require different things. Let’s keep our thoughts realistic and respectful. We’re use to 3 types of roms….Full, Medium and Light (lite.) Let’s see if we can offer up a somewhat standard model and set of applications for each type of rom.
But not just apps….lets break this down to CE builds..OS tweaks…radio performance…visual preferences…..EVERYTHING!!!!
also (i know this is gonna cause an outbreak!....) if there are any outstanding issues you've been having with all coked roms across the board...feel free to mention....The more we're all aware of something the better the chance it will be addressed!
======================================================================================
((Results and conclusions))
-For the most part, we can all agree certain apps should not be cooked in because they're updated too often.
======================================================================================
((Topics and issues))
--------------------------------------------------------------------------------------------
*well i can't edit the poll...so we'll have to do this the hard way. So we have the "to be cooked or not" apps figured out. Next is the model in which the roms are produced. Like i said before...theres usually 3. Lite, Medium and full. We need to define the roll and specs of each and what they contain. Sound Off
--------------------------------------------------------------------------------------------
At the request of mr.dutty i've added a poll. Im not sure if i can do this, but i'll try to switch it up everyday with a new subject everyday or so.
* = current topic
almost was going to warn you to get some flame retardant clothing at first glance. However after reading a bit more it does not seem to be a bad idea, assuming it can be kept free from garbage. Ill put some thought and contribute what i can but not a bad idea.
A few things I look for in a cooked ROM -
Hardware keyboard performance: We're talking about a device that features a very nice full hardware keyboard, and roms should take this into account. I've encountered roms that have laggy keyboard entry, other weird keyboard entry problems, and some which work beautifully.
Careful which apps are cooked in: If an app is likely to get updated frequently, it's my opinion that it shouldn't get cooked into a rom (unless, of course, it's a PITA to install in the first place). There'd be no point cooking PointUI's Home into a ROM, as it gets updated a lot. Also, the legality of any cooked in App should be considered. For example, I'd love to see a rom that's got Opera Mini cooked in and ready to go as the default browser, which is a lot of fiddling around and hard work, rather than a rom that uses the NOT FREE Opera Mobile.
Screen Rotation Speed: Some ROMs have managed to achieve near instant screen rotation speeds, others have not. It'd be great to know what settings affect this, and cook them in.
Options: I hate Large Start Menu. I love the fact that you can easily turn it off without any side-effects. I love the fact that Quick Menu gets cooked in, but you have the option to not use it (I'm firmly in the "loving quick menu" camp though, at the moment).
Most important: Speed. I really don't feel like this device is performing quite as well as it could do. I think we could get there - I think there's still some exploring to do, and at some point there'll be a major breakthrough.
Maybe this thread is the start of all of that?
Thank you For starting this as this will alow us to find out from different individuals thier own opinions and also from different chefs as to how we can maximise the best performance out of this baby kaiser.
At the moment Im trying different stuffs
I don't know to much about this stuff, but in my last month of looking at these forums.. I think a lot of people use these
- Pocket Core Media Player
- SOme form of Registry Edit
- Task Manager (Detialed one, WTask i think it's called?)
- Pocket Screen
- Office (obviously)
- Note pad (love it)
- Touch Settings
- Query Analyzer (maybe not for everyone..)
- Slide 2 unlock (better to get that yourself probably now that I think about it)
- Schapps advanced config 1.1
- KaiserTweak
- Total Commander looks pretty usefull
- Some sort of FTP program
- I wish there was some app for linking HTC favorites in the cube to their contact record (give you option of calling,e mailing, etc, instead of a quick call)
Not very advanced stuff, but stuff I hav efound pretty usefull that i never knew about.
swtaltima said:
almost was going to warn you to get some flame retardant clothing at first glance. However after reading a bit more it does not seem to be a bad idea, assuming it can be kept free from garbage. Ill put some thought and contribute what i can but not a bad idea.
Click to expand...
Click to collapse
lol no worries man. i got my suit bag unzipped and waiting!
i guess i'll give it a go....
me myself...I prefer a Full rom. but it seems very unrealistic as to what’s in a full rom or not. I’ve been talking to dutty a bit about this and he wanted me to get some ideas and get back to him….so I guess this is the place to get it all together. For those of us with a tilt…we all know how fat the shipped att rom was. But the funny thing is…it wasn’t slow at all! This is what sparked my thoughts. How about…a full rom = a bloated rom! But not bad bloated….good bloated. I’m talking about any and all those little apps we all know and love. Such as….group sms…call firewall…opermini (files provided to set as main browser…I think that should be left up to the user,) tom tom...quick menu….Live search and all other live apps, all HTC current apps and dialers….ect ect. I wanted to include slide to unlock, point ui and pocket cm…but these apps are updated too often to cook in….but non the less would be great for a full rom. I believe the cooks can find a way to make a rom like this work!
For a media rom….pretty much the rom…plus all the htc goodies we’re all used to. And the the rest of the inessentials….things like flash lite…youtube already cooked in....ect ect. It should be kept clean and nice.
A lite rom?....nothing! lol…lite roms are for those of us who like to tinker ourselves or just don’t use a damn thing on the phone…so I think it should be just the os! And call it a day.
I think we need to add a poll of some sort to vote on what apps should be included in each rom so we can observe, study and compare what individuals use in thier roms and what they dont like.
dan13l said:
A few things I look for in a cooked ROM -
Hardware keyboard performance: We're talking about a device that features a very nice full hardware keyboard, and roms should take this into account. I've encountered roms that have laggy keyboard entry, other weird keyboard entry problems, and some which work beautifully.
Careful which apps are cooked in: If an app is likely to get updated frequently, it's my opinion that it shouldn't get cooked into a rom (unless, of course, it's a PITA to install in the first place). There'd be no point cooking PointUI's Home into a ROM, as it gets updated a lot. Also, the legality of any cooked in App should be considered. For example, I'd love to see a rom that's got Opera Mini cooked in and ready to go as the default browser, which is a lot of fiddling around and hard work, rather than a rom that uses the NOT FREE Opera Mobile.
Screen Rotation Speed: Some ROMs have managed to achieve near instant screen rotation speeds, others have not. It'd be great to know what settings affect this, and cook them in.
Options: I hate Large Start Menu. I love the fact that you can easily turn it off without any side-effects. I love the fact that Quick Menu gets cooked in, but you have the option to not use it (I'm firmly in the "loving quick menu" camp though, at the moment).
Most important: Speed. I really don't feel like this device is performing quite as well as it could do. I think we could get there - I think there's still some exploring to do, and at some point there'll be a major breakthrough.
Maybe this thread is the start of all of that?
Click to expand...
Click to collapse
point ui makes for a good debate....the reason i would cook it in is because it comes with its own update client. so even if an older version is cooked in....or an update is available a day after the rom is cooked....you just need to go into update and that will take care of that. but i do agree with the idea of frequently updated apps should be avoided.
the screen roatation is another one....i agree. i've seen it vary from rom to rom even within dutty's camp. maybe the cooks can unite and nail that one down.
I've been using different ROMs over the last month or so and what I normally go for is the lite ROM with all the performance updates. Then I add my own apps to it. From the ROMs that have applications cooked into it I may use 80-90% of it which I find is not good for me and I think this holds true for most, if not all users. Everyone has different taste/needs.
Maybe a ROM with just the OS and performance/optimization tweaks and leave the rest up to the users. They can find the cabs for everything so why bother to cook it in. The other thing with cooking in the apps if is if the app gets an update a new ROM is needed.
Or just cook your own ROM. There's enough info within the forums to make your own ROM and include whatever apps you want.
Maybe the focus should be on optimizing the OS and leave the apps to the choice of the user.
ecltech said:
I've been using different ROMs over the last month or so and what I normally go for is the lite ROM with all the performance updates. Then I add my own apps to it. From the ROMs that have applications cooked into it I may use 80-90% of it which I find is not good for me and I think this holds true for most, if not all users. Everyone has different taste/needs.
I think make a ROM with just the OS and performance tweaks and leave the rest up to the users. They can find the cabs for everything so why bother to cook it in. The other thing with cooking in the apps if is if the app gets an update a new ROM is needed.
Or just cook your own ROM. There's enough info within the forums to make your own ROM and include whatever apps you want.
Maybe the focus should be on optimizing the OS and leave the apps to the choice of the user.
Click to expand...
Click to collapse
I cooked a lot of roms but always stick with the full rom, Reason is i could take out 50mb of programs out of a rom and This doesnt give me that equvalent space and also performance sometimes are un-stable, thats my own opinion.
I think there is a halfway line with how much goodies you can install in a rom to please most people
ecltech said:
I've been using different ROMs over the last month or so and what I normally go for is the lite ROM with all the performance updates. Then I add my own apps to it. From the ROMs that have applications cooked into it I may use 80-90% of it which I find is not good for me and I think this holds true for most, if not all users. Everyone has different taste/needs.
Maybe a ROM with just the OS and performance/optimization tweaks and leave the rest up to the users. They can find the cabs for everything so why bother to cook it in. The other thing with cooking in the apps if is if the app gets an update a new ROM is needed.
Or just cook your own ROM. There's enough info within the forums to make your own ROM and include whatever apps you want.
Maybe the focus should be on optimizing the OS and leave the apps to the choice of the user.
Click to expand...
Click to collapse
all good points...i tend to agree with you. but lets not forget we're dealing with people who dont know how to hard slp...refuse to read through 30 pages of posts or even use teh search feature. so a full features rom will always be needed.
rzanology said:
all good points...i tend to agree with you. but lets not forget we're dealing with people who dont know how to hard slp...refuse to read through 30 pages of posts or even use teh search feature. so a full features rom will always be needed.
Click to expand...
Click to collapse
This is true. For a full featured ROM I think a based ROM might be better versus cooking in many apps. Here's a list that I think can be a good starting point for a base ROM. Some utilities, tweaks, visuals, etc. The rest can be managed by the user.
- Advanced Config
- GPS Test
- HTC Album
- HTC Camera (new version)
- NotePad
- Registry Editor
- Pocket RAR
- Office w/OneNote
- PDF Viewer
- psShutXP
- QuickGPS
- Total Commander
- NetCF 3.5
- ClearTemp
- KaiserTweak
ecltech said:
This is true. For a full featured ROM I think a based ROM might be better versus cooking in many apps. Here's a list that I think can be a good starting point for a base ROM. Some utilities, tweaks, visuals, etc. The rest can be managed by the user.
- Advanced Config
- GPS Test
- HTC Album
- HTC Camera (new version)
- NotePad
- Registry Editor
- Pocket RAR
- Office w/OneNote
- PDF Viewer
- psShutXP
- QuickGPS
- Total Commander
- NetCF 3.5
- ClearTemp
- KaiserTweak
Click to expand...
Click to collapse
agreed. can we all agree this should be a common app set?
rzanology said:
agreed. can we all agree this should be a common app set?
Click to expand...
Click to collapse
Thats almost what I got apart from pdf viewer which i left out for user preference with adobe reader
the most popular apps don't have to be cooked into a ROM. every ROM can be a light or medium with everything else added as shared backup files using Sprite or SPB Backup. in another thread, some folks expressed reservations about my idea of Backup Install Packs, but i still think it could work. and no one would be forced to use them. it's something at least worth trying.
after flashing a new ROM, the ROM cooker or someone else could install demo versions of the most popular apps (HTC apps, Resco, SPB, SBSH, Opera, Palm Messaging, Kaiser Tweak, TCPMP and the plugins, etc.) onto their devices. They can then make a backup of their devices and make that backup available to other users. Then if someone installs the identical ROM, they could simply install the entire backup of those applications to their own devices. Users can keep the apps they want and register them with their own serials. They could then uninstall the rest.
that would be my idea. keep all ROMs medium and lite and let users customize them to full status with backup install packs.
PointUI drove me nuts, was nice and pretty, but in the way. Then again, I don't like the Cube either. Perhaps if I set up the cube I'd use it more, mainly for the contacts though - I don't use WMP or HTC's, I use TCPMP.'
I love the apps Dutty has, especially WKTask with its launcher and battery bar, quickmenu is awesome (without the large setting).
PocketCM has asked that it NOT be cooked in so...
IMHO a ROM should be usable for as much user as possible.
For one person S2U2 is a must-have application, but others just don't like it.
So a stable, fast and clean ROM should be the best for everyone.
Everyone can add his favorite apps, or don't add apps if you don't like them!
Just my opinion. (Of course I always go for the LITE variant, cause I just don't use a lot of apps)
What I would like to see:
Pretty much the default set of apps and tools in the stock ROM. Some of general use like pocketrar could be integrated but not much more.
Larger page pool.
What I absoltely don't want to see:
Too many UI changes, trial versions, bloated battery status apps and such.
Basically I just want the latest radio, OS and default apps all in one.
Stuff that's not likely to get upgrades for quite some time like the flash player and flash lite could preferebly be integrated but other than that I don't like too much tweaking, I just want the latest versions of the default stuff and then I do my own modifications and tweaks from there.
thanks for setting this up!! But i agree should install from CABs
No, They're updated too often to even think about cooking into the rom!
We need 1 stable EMPTY ROM. And cabs what have been edited for working on the 1 stable empty rom.
One of the big issues I have noticed is that there is no rationale behind the version number assignment for a lot of the mod firmware. There are different modders using their own versioning, and there isn't even a hint of what version of android they are using, so we have things like;
"KiNgxKxROM Version 1.1r1"
"The Official Blur - Hero-V1.5.7 by Drizzy"
"JACxHEROSkiv2.2"
"CyanogenMod 4.1.11.1"
*** these all have the same problem... what version of android do they correspond to? How new IS each one of them?
I would like to propose a new standard to be adopted by everyone.
name-officialversion-modversion.
Of the form i.e.
"superxmod-1.6.DRC83-0.1.0.0"
***WHERE the modversion RESETS TO ZERO each time the official version increases, so for example, "CyanogenMod 4.1.11.1" should be called "CyanogenMod-1.6.DRC63-0.1.11.1".
* this will allow the user to immediately know where this rom comes from in terms of the official android versions and approximately how old it is.
I do my best
I do my best ... with the "limited space" we're given for Thread Titles on the forum.
~enom~
I support this though I find it unnecessary. The new beginner user will most likely READ atleast the first post of the thread and they will know what the ROM is based off of. The end user will of course know to read the thread before doing any flashing of any kind so organizing mod rom versioning isn't a necessity. It's convienent but not necessary
I support this because it would make ROM catalogs easier to build, which would benefit the whole community.
why not just post what android version the rom is based on in the first post. First post should always hold the most info anyways.
Since this thread hasn't been moved from the Dev section so far.
+1 for the versioning.
Also, how about we all stick to one benchmarking app (or is there any one app that we CAN rely on)
to test performance of ROMs, so that there's an objective way of figuring out
whether the latest frankenROM (thanks devs! ) is faster than X or Y?
Benchmark Pi has a score that's difficult to figure out, seeing as it throws up an
awesome number on a fairly sluggish HERO whereas the score for a fast-as-light
cyan ROM is way way worse. I know that Benchmark Pi isn't the answer,
not by a long shot. So is there a better alternative out there?
I'm tired of posts that go "THIS IS WAY FASTER! THANKS!" only to find
that the supposed speed increase is more rooted in perception than in
reality.
We need definitive numbers for ModelNumber+ROMVersion+CC/SwapSettings combinations.
Any help?
alritewhadeva said:
The end user will of course know to read the thread before doing any flashing of any kind
Click to expand...
Click to collapse
rofl. Funniest thing i've read all week.
+1
how about shorthand naming such as
for example:
CyanogenMod = CM-AOSP1.6r1-v4.20
If you're talking about cyanogen mod, you might want to add a couple more zeroes at the end. Anyway, I had proposed this too a while ago. I like your format, and I'll go one better; let's do cook-androidVersion-buildVersion-feature.bugfix
for example, the build I made this morning would be "jm-1.6-Donut eng.jubeh.20090930.070211-0.0"
jm is what I use for my builds (short for jubehMod)
1.6 is the current android branch (as per build.prop, no 1.6_r1 yet)
Donut eng.jubeh.20090930.070211 is the build number the compiler assigned to my build, people who work off of modding factory releases or build for dream_open are the ones who usually come up with things like CRC or DRC etc, I build for "AOSP for Dream" (it's a new "vendor" added)
first 0 is feature number, at this point my build is nothing but stock AOSP donut, no Google apps, no a2sd, no netfilter, no compcache, no bfs, just stock donut, so say I were to add a2sd, then I'd go up to 1, as I would have added one or more features (and this would be listed at the change log), basically, anything added that improves the build (and that's not a fix) is a +1 to feature
second 0 is bugfix. For example, right now my build works correctly in every sense, but I have a problem with the video camera where video is of very poor quality (real problem, I'm trying to figure it out), so say i get it fixed, then my bugfix number would go up 1, so basically, anything changed in the build strictly because it didn't work as intended is a bugfix
the last two numbers would be allowed to go past 9, so no more pressures to add .1s at the end like cyanogen was doing to prevent jumping to build # 4.2
karthikjr said:
+1 for the versioning.
Also, how about we all stick to one benchmarking app (or is there any one app that we CAN rely on)
to test performance of ROMs, so that there's an objective way of figuring out
whether the latest frankenROM (thanks devs! ) is faster than X or Y?
Benchmark Pi has a score that's difficult to figure out, seeing as it throws up an
awesome number on a fairly sluggish HERO whereas the score for a fast-as-light
cyan ROM is way way worse. I know that Benchmark Pi isn't the answer,
not by a long shot. So is there a better alternative out there?
I'm tired of posts that go "THIS IS WAY FASTER! THANKS!" only to find
that the supposed speed increase is more rooted in perception than in
reality.
We need definitive numbers for ModelNumber+ROMVersion+CC/SwapSettings combinations.
Any help?
Click to expand...
Click to collapse
yes just bench mark. its much better than benchmark pi only test the cpu really
by the way, I've been saving pretty much all roms that have been posted here (notable exceptions are haykuro's, jf's, and theduded's roms, I haven't been here THAT long) and I have them all saved on my computer separated by /cook/build/ for the Dream roms and /build/cook/ for the Hero ports. I guess I could run a quick filesystem lister and upload that list for people to see so they can sort of get an idea what mod release corresponds to what build
Here we go, I had to upload it inside a zip because of the stupid 2kb limitation on text files (this is 10kb)
lbcoder said:
One of the big issues I have noticed is that there is no rationale behind the version number assignment for a lot of the mod firmware. There are different modders using their own versioning, and there isn't even a hint of what version of android they are using, so we have things like;
"KiNgxKxROM Version 1.1r1"
"The Official Blur - Hero-V1.5.7 by Drizzy"
"JACxHEROSkiv2.2"
"CyanogenMod 4.1.11.1"
*** these all have the same problem... what version of android do they correspond to? How new IS each one of them?
I would like to propose a new standard to be adopted by everyone.
name-officialversion-modversion.
Of the form i.e.
"superxmod-1.6.DRC83-0.1.0.0"
***WHERE the modversion RESETS TO ZERO each time the official version increases, so for example, "CyanogenMod 4.1.11.1" should be called "CyanogenMod-1.6.DRC63-0.1.11.1".
* this will allow the user to immediately know where this rom comes from in terms of the official android versions and approximately how old it is.
Click to expand...
Click to collapse
................................
Hi jubeh,
Thanks, this kind of cataloging is exactly why the OP's suggestion will be helpful.
karthikjr said:
We need definitive numbers for ModelNumber+ROMVersion+CC/SwapSettings combinations.
Any help?
Click to expand...
Click to collapse
I'm not so sure that we do...
I think that that should be more of a "details" thing.
Maybe we can go with "name-officialversion-modversion[-custom]" (square braces mean optional). Name might be a good place to keep modelnumber (I assume you mean by that "dream", "magic", "hero", etc.),
i.e.: supercustomrom(DREAM)-1.6r1-0.0.0.0.0.0.0.1-cc_swap_a2sd
I have now researched the various 'ROMs' (actually firmware), and have narrowed the field to four. I'd like input on these. Priorities are (in order):
1. Complete Stability. I've run TomTom on WM5 for 6 years, and outside of TomTom it's a real mess. WM is so buggy I can't use it confidently for anything other than nav.
2. Good Battery. I have a friend who just got an Evo, and he says battery lasts only ~3 hours. I'm sure that's because of the large display, but also I read that several ROMs and apps really sacrifice battery on the N1. One screen I want to have dedicated to some sort of CPU/Mem/Storage monitor, so I can easily check it.
3. Lots Of Cool Features. It seems that video at 720p might be problematic as I gather it's really 3Mp upsampled, and/or it disables the still camera/flash somehow? Kernel optimizations are nice, although "deodexing" is not defined -anywhere-. I'm unlikely to stray beyond the UI built into the ROM, as it could introduce instabilities.
a. CM6 - The Big Kahouna. This ROM will likely be supported for a long time and is likely to integrate the newest kool features over time.
b. MoDaCo - Its thing seems to be stability, although a feature-by-feature comparison with CM6 leaves me confused, much less comparative usability is impossible to determine. Kitchen allows preclusion of G**gle apps.
c. LeoFroYo - The guy seems to know what he's doing, so under consideration. Comes with G**gle apps tho.
d. Kang-o-rama - an innovator whose improvements have been co-opted by others.
e. RoDrIgUeZsTyLe - I like it, but it is clearly very ill given the thread comments. Rejected.
Really? Nobody knows anything about this?
it depends on which phone u have bro, u didnt even specify that
So, I've been at this for about 48 hours now (not continuously, but closer than you might think) and I figured I should take a break from modifying project files and puzzling over alignment issues to discuss the project, share some of the problems I've been having and ask if anybody can help, and so on.
The general idea is "Chromium build for Windows (on x86/x64) and build on ARM (for Linux), so there must be a way to build it for Windows on ARM". For the most part, that even looks like it's true. Probably at least 80% of 654 Visual Studio projects (no, that's not a joke) either build just fine with only minor amounts of work, or are things that we don't actually need (I'll try building the test suites... once everything else builds!!)
Areas that have given me problems (caution: some chance of brief rants ahead):
v8. Less than you might think, though. Setting the flags for Arm seems to have been enough.
Sandbox. There's a fair bit of thunking coded in assembly going on in the sandbox for x86. Not sure what's up with it (I don't know exactly how the Chromium sandbox works) but it'll have to come out or be replaced. The Linux (including ARM) sandbox seems to be SELinux-based, which doesn't help at all.
Native Client (NaCl). I think all the assembly is in test code, though, so I may just boldly #ifdef if all away.
libjpg-turbo (libjpg). Piles of carefully optimized assembly... for x86 and x64. There is a set of ARM assembly (for Linux) that Visual Studio won't compile, but something else might... or I may tweak until it works. Of course, I could also just accept the speed hit and use the version of libjpg implemented in nice, portable C.
Anything where the developers tried to use some SSE to speed things up. I may be able to replace it with NEON code, or I may just remove it and hope **** doesn't break. We'll see.
Inline assembly in general. Even when it's ARM assembly, Visual Studio / CL.exe don't want anything to do with it (__asm is apparently now an invalid keyword). I suspect I'll have to just pull the assembly out into stand-alone functions in their own files, then compile them to object files and link them back in later. If I can figure out the best way to do this (for example, I'll want to inline the asm functions) then it shouldn't impact performance. Seriously though, I kind of hate inline assembly. I can read assembly just fine, but I'm usually staring at it in a debugger or disassembly tool, not in the middle of source code I'm trying to build...
Everywhere that the current state of the CPU is cared about (exception and crash handlers, in particular) because the CONTEXT structure is, of course, CPU-specific. They're pretty easy to get past, though.
Low-level functions, like MemoryBarrier. Fortunately, it's implemented in ntdll.h... but as a macro, which breaks at least half the places it's referenced. Solution: where it breaks things, undefine the macro and just have it be an inline function that does what the macro did.
Running out of memory. Not even joking... well, OK, a little bit. I've got 32GB; I won't actually run out. Both Visual Studio and cl.exe do at times, though!. Task Manager says VS is currently using 1,928 MB, and before I restarted it, it broke 2.5GB private working set. Pretty good for a program that for some reason is still 32-bit...
Goddamn compiler flags. Seriously, every single project (I mentioned there are over 600, right?) has its LIBPATHs hardcoded to point at x86. Several projects have /D:_X86_ or similar (that's supposed to be set by the build tools, not the user, you idiots...) which plays merry hell with the #ifdef guards. Everything has /SAFESEH specified, not in the actual property table where the IDE could have removed it (unneeded and invlaid on ARM) but in the "extra stuff we'll pass on the build command line" field, which means every single .EXE/.DLL project must be modified or the linker will fail.
My current biggest goal is the JPG library; nobody wants to use a browser without it. After that, I'll tackle the sandbox, leaving NaCl for last... well, last before whatever else crops up.
Anyhow, thoughts/comments/advice are welcome... in the mean time, I'm going to go eat something (for the first time in ~22 hours) and then get some sleep.
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?
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..
great
Please make that happen !
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).
GoodDayToDie said:
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).
Click to expand...
Click to collapse
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
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.
GoodDayToDie said:
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.
Click to expand...
Click to collapse
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
Yep... but they did it without v8. That's not an encouraging result, but I feel like I'm so close...
Is there a GitHub repo so we can help or track the progress of the project ?
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.
http://www.engadget.com/2013/01/22/google-chrome-native-client-arm-support/
This wouldn't have any impact on this project, would it?
Sent from my SCH-I535 using xda-developers app, complete with annoying signatures.
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.
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.
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...
You may upload only the diff files, they'll probably be smaller then the whole distribution.
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
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.
LastBattle said:
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.
Click to expand...
Click to collapse
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.