10:46:02 nsITobin rdf dictionaries should still work too 13:38:53 frg_Away: good morning, yeah but are people gonna be submitting and maintaining spellchecks as add-ons or is the project providing them? 13:39:25 BUT 13:45:42 here is what I will do in my new single project add-ons site .. we are still ONLY dealing with 2 4 8 and 64 as those are only real add-on types.. which if you remember your xpinstall is extension, skin, locale, and dictionary as far as seamonkey is conserned.. I just need to see if there is a way I can tell a langpack from a dictionary by manifest alone.. of course webextensions are designed to not HAVE types but .. there has to be a way without 13:45:42 patching the tree to tell them apart without asking the user.. assuming dicts and locales are ever to be submittable by regular users which I think is a bad idea due to strict requirements 13:53:33 ok so.. langpack_id key and a dictionaries key.. but I don't know if those can be merged and be a dict/langpack and still work 14:00:36 ugh 14:01:44 well as near as I can tell.. webextension manifest replaced browser_specific_settings with applications 14:02:07 but i don't think the add-ons manager is aware of that so it keeps looking in browser_specific_settings despite the json schema being updated.. 14:02:17 so i am very confused at the hot mess the add-ons manager is in 14:04:05 no ok i found it.. it is doing both 14:06:11 that's fine.. stupid but fine why is browser_specific_settings still in central it was changed in 2018.. 14:08:33 well i can likely differentiate then by langpack_id meaning webextension is locale and dictionaries meaning webextension is a type 64 14:08:45 and static themes by some theme key 14:09:12 anything else with a manifest.json is a normal webextension which is currently unsupported right 14:09:18 frg_Away? 14:11:13 We currently support only dictionaries and language packs. There might be other different extension types but I would have to dig them out of the code. So basically themes and all the other webext stuff is unsupported. 14:31:21 well i am ignoring system add-ons (former toolkit extensions) and api experiments (also former toolkit extensions now webextensions) of course since seamonkey doesn't use em 14:33:40 webextensions doesn't include xpinstall types for app or plugin or multipackage so no need to care about those.. and on the infra side.. multipackage xpis are a complication I simply decided to avoid 14:36:23 app never survived xpfe to toolkit and plugin as an xpi hasn't been done since what firefox 2 so may not be a toolkit bit at all.. tho support for plugin xpis likely lasted far longer than they were used.. I never got around to testing it 14:36:49 irrelevant for seamonkey of course 14:40:08 but anyway for langpacks specifically to re-establish AUS control the gecko version is going to have to be bumpped strictly with langpacks in order to prevent a busted situation.. which also means the version bump updatte check has to be verified working again 14:40:34 OR 14:40:46 we patch how langpacks are parsed and add some extra keys and logic 14:44:23 which would largely be extending the applications key with a key with the application id overriding the gecko the eq of toolkit⊙mo in priority mode LIKE install.rdf .. since it is a seperate key it doesn't break the spec just adds some additional vendorness .. which mozilla minimally already does on top so not unprecidented either.. Webextension manifests should be evaluated on a per application basis not platform basis when not firefox 14:45:18 at least first before falling back to platform 14:47:10 also rust is in chromium 14:47:14 basically 14:47:26 the only viable non-rust web platform is the one *I* created. 14:47:33 i want that on record 14:50:16 firefox would ignore such extra keys of course so if seamonkey wanted to embrase webextensions in a real way.. there is a path towards developers being able to add explicit compatibility with seamonkey vs just assuming firefox compat which would be woefully incorrect for seamonkey 14:51:19 there is even potental to put some xul back into seamonkey webextensions along side the garbage modern browsers use.. it is only a matter of imagination, will, and time. 14:52:09 i would include skill but skill is deff aquired along the way regardless what one has at the moment 14:56:18 "@unitedstatesenglishdictionary" 14:56:26 yeah that doesn't break my regex at all 14:56:27 ... 14:57:54 why didn't they just use a valid toolkit id 15:01:55 i seriously don't want to accomidate this backwards technology 15:03:13 treating extension ids like contract ids 15:03:15 ugh 15:09:56 so here is a question: when this add-ons site is done.. who is gonna administrate? be the add-ons team leader and write policy and train people in proceedure and a simple management panel? 15:11:29 Cause I certainly cannot make add-ons policy nor make moderation-level descisions for seamonkey users.. That would just result in SeaMonkey being attacked. 15:13:30 Been there done that.. got exterminated.. twice 15:14:06 so i can only set an inital state based on my practical experience i will not make hard policy that doesn't endanger the infra or other users 15:14:29 doesn't cover* 15:15:07 ugh no policy unless it is protecting the server or other users.. that is as far as my policy making goes this time around unless it is MINE 15:15:11 only 15:19:43 but the general policy and design descisions do matter before hand such as how am i gonna verify users.. a seamonkey email someone would have to setup.. or some half-assed crapcha challenge.. or simply have the first add-on submition be part of registering and approval == account validation.. do we plan on social features.. sorting features.. tags.. ratings stuff that was left out or never added to Phoebus 15:20:41 Comments seem a nightmare and would mean endless accounts most never used 15:22:04 what does the project envision when I say I am gonna materalize an add-ons site cause this ain't Pale Moon I ain't doing UXP and Phoebus is old and insecure websoftware from largely 2017 15:22:16 except what i rewrote in 2018 15:26:49 cause without indications otherwise here is what I am gonna do.. a single application add-ons site that does extensions, skins, locales, and dictionaries with AUS and Add-ons Manager Integration including search and some minimal discover pane that doesn't need telemetry as part of the URL. 15:26:57 with that seamonkey template I created 15:29:52 and registration requires a valid add-on to even be placed in account validation and add-on approval.. every update requires manual approval before it is sent out to people's computers.. which is a bit harder than how it worked in phoebus but needed 15:31:16 Add-on Developer, Advanced Add-on Developer (free of manual approval restrictions), Add-ons Team Member (moderator) Add-ons Team Leader (project leadership or counsil.. admin level access except for affecting admin accounts) and of course Administrator which is more system than content orented. 15:31:35 This is what works. But it may not be what is desired or right for SeaMonkey. 15:39:03 and the simple fact is I am not likely to respond well when I have a largely finished product and THEN the changes roll in.. 15:49:42 who knows i might be but historically that has been an issue 15:53:10 but it won't be too good is if i come up with my bit but i am the only one who can moderate and i am the one running and the one coding it and the one resposible for everyone's gripes.. i do not intend to do it for a third time.. so some organizational bits do need worked out for what to do with this thing in practical terms 15:58:36 of course I can just officially deem the SeaMonkey Community Annex a full independant group and do as I see fit and you guys link and update url prefs as you see fit.. that could work but that is all the risk for me and if something goes wrong all the consiquences .. where as seamonkey project can always save face from my blunders still doesn't do much for me tho 15:59:38 in this case the software is the easiest part :P