On Sat, Aug 24, 2013 at 11:16 PM, David Flanagan <[email protected]> wrote:
> On 8/23/13 10:50 PM, Tim Chien wrote:
>>
>> David, by build size, you mean the size of the built packaged zip
>> files, of the original source files?
>
> I mean 18mb of new files are going into the keyboard app zip file. Those
> data files are already fairly compressed, so I would guess that the zip file
> itself increases by 12-15mb.  The data is read out of the raw data file
> everytime, so there is no indexeddb hit once it starts getting used.
>

Right. That's really a lot :-/

>
>>
>> I am updating the Traditional Chinese IME which will increase the
>> zip'ed size by ~1mb (bug 908577). When enabled, the IndexedDB backend
>> of the IME will create results a 18mb sqlite in the profile. When
>> removed the zip'ed size is reduced by 2.3mb.
>>
>> Removing the Simplified Chinese IME saves about 600kb (zip'ed).
>>
>> Drivers, do we have a hard limit of the build size on any particular
>> devices?
>>
>> I hope that when we ship 3rd-party keyboard framework, eventually, we
>> should be able to split these keyboards into different keyboard apps,
>> not preloading them, and make them available on Marketplace (just like
>> Firefox spell check dictionaries).
>
> And for the built-in keyboard, it would be nice if there was a way for users
> to add keyboard layouts and dictionaries. I don't know how that would work,
> but it would be easy to modify the code to look in DeviceStorage for
> auto-correct dictionaries that aren't found pre-packaged in the app.  I
> don't know how you'd get an autocorrect-dictionary from Marketplace to
> device storage, however (unless we started treating them like wallpapers and
> had the keyboard use a Pick activity to obtain them from some other app).
>

I mean actually split the Gaia keyboard app into many, many keyboard
apps for different regions, or even individual layouts. Then we could
simply leverage 3rd-party keyboard framework (where users are free to
install/enable multiple layouts from multiple keyboards) and select
the keyboard app(s) to include in the build.

>> Alternatively, if we hit the hard limit before that, we would need to
>> make the build script of keyboard app configureable (I hope not).
>>
>>
> Build-time configurability is actually my plan for bug 884752, which Andreas
> marked Koi+.  The idea is to make the list of keyboard layouts and
> dictionaries configurable at build time (like the list of locales is) so
> that carriers can create builds for exactly the counties that they plan to
> support.
>

The reason I don't like this is because it remove features from Gaia.
I would imagine when the user get a hold of a Firefox OS phone, she/he
expects a same set of features present. If we remove feature like this
then it has to be recoverable, maybe from Marketplace (hence my
previously mentioned idea).

-- 
Tim Guan-tin Chien, Engineering Manager and Front-end Lead, Firefox
OS, Mozilla Corp. (Taiwan)
_______________________________________________
dev-b2g mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-b2g

Reply via email to