<kerio>
i thought one of the things holding the update of microb-engine was the microb UI itslef
<kerio>
itslef
<kerio>
FUCK
<kerio>
itself
<bencoh>
me too
AndrewX192 has quit [Ping timeout: 260 seconds]
AndrewX192 has joined #neo900
Agge has quit [Remote host closed the connection]
Agge has joined #neo900
Nokiabot has joined #neo900
<Nokiabot>
i bet every one is wet upon looking at jonwill s thread on upgrading microb aka microb+ ;)
sixwheeledbeast has joined #neo900
Nokiabot has quit [Quit: used jmIrc]
Kabouik_ has joined #neo900
Kabouik has quit [Ping timeout: 255 seconds]
_whitelogger has joined #neo900
_whitelogger has joined #neo900
sixwheeledbeast has joined #neo900
nox- has joined #neo900
che1 has quit [Ping timeout: 256 seconds]
<freemangordon>
kerio: bencoh: UI istelf is not that much of a problem, it talks to the engine vie the so-called EAL
<freemangordon>
*via
<freemangordon>
(Engine Abstraction Layer)
<freemangordon>
or somesuch
mvaenskae has quit [Quit: Lost terminal]
jonwil has joined #neo900
che1 has joined #neo900
<freemangordon>
jusa_: can you give some hints on the function names in xprot module? :) I really hate when I have to name a function something like nfc_what_it_does_func1()
<freemangordon>
jonwil: hi!
<jonwil>
hi
<freemangordon>
jonwil: I started work on xprot module, though nothing really completed so far
<jonwil>
ok
<jonwil>
nothing much I can help with there, I already cloned the bits from it that I am able to clone :)
<freemangordon>
BTW re browser - been there done that. I wasted tremendous amounts of tim on gecko, just to be screwed at the end by the removed qt4 support
<freemangordon>
yeah, I know
<freemangordon>
the only option we have AIUI is to fix gtkglext to have GLES support and to implement embedlite with gtk
<freemangordon>
but we need way more work force than as of now
<freemangordon>
than we have as of now that is
Kabouik has joined #neo900
<jonwil>
yeah reading some things it seems like Mozilla have either abandoned or depreciated the whole idea of embedding Gecko into other things, not just GTK stuff but everything.
<jonwil>
Probably because they dont want to have to care about backcompat when Firefox moves so fast
<jonwil>
Seems like a lot of the reason for getting rid of gtkmozembed and the whole "embedding" philosophy is because of ideas like the multi-process stuff where different windows/tabs are different processes
<bencoh>
their previous "design" was a mess anyway
<bencoh>
you really did not want to fiddle with gtk/gecko glue
<freemangordon>
oh, so their current is not?
<bencoh>
(building it alone is a nightmare, so ...)
<bencoh>
freemangordon: absolutely is as well ^^
<freemangordon>
bencoh: tell me about it, I did it till 24 or something (building)
<freemangordon>
for n900 that is
<bencoh>
I build firefox for osx/x11, my last build was 2years ago ... I've been stuck with an old version since then (dont really want to go through the manual process again)
<bencoh>
half hand-baked build
<bencoh>
(and I really mean it ... patching on the go and re-running gcc commands because they do "portable" stuff)
<freemangordon>
maybe we should choose another engine
<freemangordon>
webkit comes to mind
<jonwil>
If we switch engines we definatly loose any compat with flashplayer or maps
<freemangordon>
and there is gtkwebkit afaik
<freemangordon>
jonwil: why is that?
<jonwil>
because they are tied to Gecko APIs
<jonwil>
certainly maps is
<freemangordon>
it is standard API, NSsomething
<freemangordon>
we can RE maps, it is a small .so
<bencoh>
NSAPI ... mozilla is dropping support
<freemangordon>
hehe
<freemangordon>
coe on
<bencoh>
(I think latest release has it disabled)
<freemangordon>
*come
<bencoh>
yeah .... netscapeapi ... this thing is 15yo :)
<freemangordon>
oh, good reason. "It is old"
<bencoh>
(or is it 20 ? I dont remember anymore)
<bencoh>
I didnt say it was a good reason ;)
<freemangordon>
naah, I didn't mean you
<freemangordon>
:)
<freemangordon>
and how are they going to support flash?
<bencoh>
chrome dropped support as well
<freemangordon>
or they deprecate flash as well?
<jonwil>
ok, so we have flashplayer (which sits in browser/plugins and probably just uses NSAPI interface)
<bencoh>
I suspect they dont want flash anymore, I dunno the current status
<freemangordon>
jonwil: not probably, for sure
<jonwil>
ok
<freemangordon>
even qtwebkit in maemo is able to use it
<bencoh>
(or ... maybe recent flash doesnt use nsapi but plugs more closely to the browser)
<freemangordon>
anyway, I am going afk as otherwise GF will kill me, bbl :)
<bencoh>
"In February 2012, Adobe Systems announced that future GNU/Linux versions of Flash Player would only be provided via PPAPI, although the previous release, Flash Player 11.2, with NPAPI support, would receive security updates for five years"
<jonwil>
there is also libssoautologin which is implemented as a browser extention (with an .xpt file, a .so file and some other stuff)
<jonwil>
tablet-browser-default-plugin and tablet-browser-mediaplayer-plugin exist in /browser/plugins like flashplayer and may or may not be using just standard npapi
<jonwil>
as for nokia-maps, it has npmessagebus.so and npatlas.so in plugins (probably using npapi)
<jonwil>
then it has stuff in microb-engine/components (npatalasurlresolver.so, libatlas.so, libmessagebus.so) and a pair of xpt files
wazrus has joined #neo900
<jonwil>
in terms of the things that talk to the browser, the microb UI, tutorial-home-applet and rtcom-messaging-api all talk to it using browser-neteal and tablet-browser-daemon
<jonwil>
nokia-maps embeds GTK directly via browser-eal
wazrus has quit [Quit: Lost terminal]
xes has joined #neo900
<bencoh>
oooh right, rtcom-messaging uses microb
norly has joined #neo900
<kolp>
so does modest, apparently
<jonwil>
I dont think modest uses microb
<jonwil>
oh wait it does, it has a dep on microb-engine
<jonwil>
modest is FOSS though so we can make any porting necessary
<DocScrutinizer51>
how the heck would porting for microb be necessary?
Oxyd76 has joined #neo900
<DocScrutinizer51>
even for modest
<DocScrutinizer51>
please keep in mind that at least FOSS#frewmantle supposed to be ABI compatible to stock so all apps supposed to work OOTB, except modem related stuff
<DocScrutinizer51>
s/OOTB/out of the repo/
<jonwil>
That was in the context someone mentioned somewhere of "lets use webkit instead of gecko since webkit still has gtk bindings"
<jonwil>
as for backcompat, if we cant be backcompat with the stock package but we can clone it or modify its code so that it in turn remains backcompat with the rest of the system, that is also acceptable for FOSSFremantle
<jonwil>
e.g. CSSU already has a clone of fmtx-middleware
<jonwil>
we dont need to be able to run stock fmtx-middleware on fossfremantle as long as we make our clone of fmtxmiddleware compatible with all the things that talk to fmtx-middleware
<jonwil>
the fmtxmiddleware clone goes in our fossfremantle repos and gets used instead of the stock one
<jonwil>
just as an example
<DocScrutinizer51>
(acceptable) only when sytictly nothing depends on it
<DocScrutinizer51>
or the ABI stays compat
<jonwil>
yeah the idea is that we e.g. change fmtx-middleware so it talks to the same thing at the upper end but talks something different at the lower end
<DocScrutinizer51>
compt ABI is what we aim for e.g. for nokia PA plugins
<jonwil>
things that talk to fmtx-middleware would continue to work
<DocScrutinizer51>
exactly
<jonwil>
even though in Neo900 case fmtx-middleware is talking to different fmtx chip
<DocScrutinizer51>
I don't see why that's needed for browserd
<DocScrutinizer51>
browserd not depending on any chips that changed, right?
<DocScrutinizer51>
might be fine to have a *100%* compatible browserd that supports more recent stuff like flash >=10 etc
<DocScrutinizer05>
hehe, sign in pub: "bitte im Garten rauchen!" - somebody changed it to "bitte im Garten fauchen!"
<jonwil>
The benefit of upgrading the browser engine is exactly that, we get support for HTML5 and other new things
<DocScrutinizer05>
yeah, however I'd consider that not strictly a perting issue, rather a general maemo maintenance task
<DocScrutinizer05>
porting*
<DocScrutinizer05>
for sure nice to have
<DocScrutinizer05>
but not mandatory in any way
<DocScrutinizer05>
typical CSSU-optional upgrade
<DocScrutinizer05>
iow though it's part of metapackage, it's basically an upgrade that is completely under user's own preferences
<DocScrutinizer05>
until we run into a situation where stock browserd is considered dangerous for system and thus needs a security patch. Then we probably need to patch stock browserd and still the new improved browserd based on new rendering engine would be optional
<DocScrutinizer05>
of course we cannot patch flashplayer.so, so this might make the complete stock browserd deprecated as soon as we could provide a replacement that's 100% compatible and feature complete
<DocScrutinizer05>
but I'm not part of that tam anymore, so consider the above as some faint remark somebody unrelated uttered
<DocScrutinizer05>
team* (CSSU)
Oksana has joined #neo900
<DocScrutinizer05>
or, consider it as a remark the mentor of FPTF uttered
<DocScrutinizer05>
while FPTF is clearly only loosely related to CSSU
<DocScrutinizer05>
and a mentor can suggest only
<bencoh>
I'd say it depends whether ftpf is meant to be "fremantle" for freemantle/fossmantle", actually
<bencoh>
(regarding ftpf, not cssu)
<DocScrutinizer05>
fptf is clearly targeted at being ABI compatible to stock fremantle
<DocScrutinizer05>
that's the top consideration about fptf/foss-fremantle
<DocScrutinizer05>
then after a long distance, there's consideration #2 which is >maintainability< and implicitly introduces "we should have as many OSS parts instead of closed blobs as possible"
<DocScrutinizer05>
it yields >upgradeability< as a benefit
<DocScrutinizer05>
EAL is FOSS aiui. So it should be feasible for virtually 'everybody' to implement a new engine under the EAL hood#
<DocScrutinizer05>
new engine for browserd however is roundabout same class of improvement as new cameraui
<DocScrutinizer05>
new item must be API compatible (and ABI compatible) to old one, and there shouldn't be any dependencies in whole system that demand for new version
<DocScrutinizer05>
anyway ask timeless, he's the expert for microB
<ds2>
ARRRRRRRRRRRRRRRRRRRRRRGGGGGGGGGGG NO WEBKIT@#($*)@#$(&()!@#&$*#@*#!(@^$(*!@^#*(
<DocScrutinizer05>
stock browserd (whatever it's based on)
<DocScrutinizer05>
browserd used in roundabout three times as many apps as you could think of
<ds2>
that is gecko based, AFAIK
<ds2>
webkit is android crap
<DocScrutinizer05>
well, maybe even apple crap?
<DocScrutinizer05>
both start with "A" ;-)
AndrewX192 has quit [Ping timeout: 260 seconds]
<kolp>
webkit is originally a kde 'invention'
AndrewX192 has joined #neo900
<bencoh>
00:31 < ds2> webkit is android crap
<bencoh>
wtf ?
<DocScrutinizer05>
kolp: sure?
<DocScrutinizer05>
~wiki webkit
<infobot>
At http://en.wikipedia.org/wiki/Webkit (URL), Wikipedia explains: "{{Use mdy dates|date=October 2013}} {{Infobox software | name = WebKit | logo = | screenshot = | caption = | collapsible = | author = KDE{{cite web |url= http://donmelton.com/2013/01/10/safari-is-released-to-the-world/ |title=Safari is released to the world |publisher=Donmelton.com |date= |accessdate=January 13, 2013}}{{cite web|url=http://lists.kde.org/?m=104197092318639 |title='(fwd) ...
<kolp>
yepp
<DocScrutinizer05>
>>The code that would become WebKit began in 1998 as the KDE's HTML layout engine KHTML and KDE's JavaScript engine (KJS)<< wow
<DocScrutinizer05>
so wtf >>choice: webkit | KHTML<< in konqueror??
<kolp>
for quite a while khtml was developed in parallel with apple's efforts, as apple released their changes in one massive blob to kde, which was incorporate donly very slowly
<bencoh>
hmm well maybe not just legacy, it's still actively developped
<kolp>
and it seems as if it still exists
<bencoh>
(all this brings me back to the time where we really only had konqueror-embedded as a sane embedded browser option .... :)
<bencoh>
(at least with a modern web compliant engine)
<DocScrutinizer05>
seems we're currently at 385 devices