Re: [MeeGo-dev] MeeGo...
On Wed, Sep 28, 2011 at 15:31, Jeremiah Foster wrote: > On Wed, Sep 28, 2011 at 1:03 PM, Ross Burton wrote: >> >> On Wed, 2011-09-28 at 07:57 -0300, Fernando Cassia wrote: >> > Tell me how an HTML5 app will interface to a camera or gps device, for >> > instance >> >> Something like this I guess: >> >> http://www.w3.org/TR/html-media-capture/ >> >> http://www.w3.org/TR/geolocation-API/ > > Those documents only show how you pass audio, media, and other streams into > HTML. It doesn't describe how you actually drive the hardware or how you > connect the hardware to the operating system. While this answers the > question "how will an HTML5 app interface with a camera" it doesn't obviate > the need for native drivers and modules to talk to the hardware, which was > partly the OP's point. It also doesn't answer what would you be able to do with the content you get from camera and audio samples. There are some examples on how you could achieve computational photography and audio processing tasks in Javascript but that is still in early infant stages. One will need to make native modules (to what? to JS engine?) to be able to process those using all power of the device in question. -- / Alexander Bokovoy ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] https://bugs.meego.com/ can not work now, when will it be recovered?
Hi Adam, On Thu, May 5, 2011 at 20:57, adam.gretzin...@linux.intel.com wrote: > > On 05/04/2011 08:39 PM, Alexander Bokovoy wrote: >> >> There seem to be some misconfiguration of SSL setup at meego.com. I >> >> tried with QtWebkit and it also unable to reach and render it. >> >> Looking into a network trace I can see that Firefox 4 talks TLSv1 to >> meego.com while QtWebkit uses SSLv3. >> >> > This actually is how its intended, bugs.meego.com is a TLS-SNI website > (SSL named Vhosting): > (read about it here: http://en.wikipedia.org/wiki/Server_Name_Indication). > > The reason its TLS-SNI primarily is that we want to be good citizens and > conserve IPs. We also can't get more to dedicate to each SSL site. > > If you connect to some of our services you'll get a self-signed SSL > certificate when TLS-SNI support is not available in your user-agent. If > you hit this URL you'll be served a help page that talks about this: > > https://140.211.166.236/TLS-SNI.html > > Primarily the complaints about this have come from people using Internet > Explorer on Windows XP which led us to ask, why are you accessing our > site with such an old software stack? Qt Networking of 4.7 is not supporting TLS SNI on all platforms. See other mails in the thread. This primarily affects my RSS fetcher but a work around has been already found.(see the other mail) and Thiago said it is fixed in Qt 4.8 by supporting SNI. > meego.com has a dedicated IP and does not use TLS-SNI for its SSL. Nevertheless, it behaves the same way: when prompted to communicate with SSLv3, it aborts handshake. -- / Alexander Bokovoy ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] https://bugs.meego.com/ can not work now, when will it be recovered?
Hi Thiago,
On Thu, May 5, 2011 at 09:16, Thiago Macieira wrote:
> On Wednesday, 4 de May de 2011 22:54:34 Niels Mayer wrote:
>> On Wed, May 4, 2011 at 8:39 PM, Alexander Bokovoy wrote:
>> >> (https://bugs.meego.com)
>> >
>> > There seem to be some misconfiguration of SSL setup at meego.com. I
>> > tried with QtWebkit and it also unable to reach and render it.
>>
>> KDE's Konqueror browser also cannot browse bugs.meego.com over SSL. It
>> outputs the following error:
>> http://nielsmayer.com/meego/bugs-meego-com-bad-certificate.png
>>
>> It's as if the WebKit based browsers (such as Konqueror) do not
>> recognize Go Daddy as CA. (Note the empty certificate chain and "this
>> certificate is not signed by any trusted authority" in image above).
>
> That's not it.
>
> The reason is that the certificate presented *is* self-signed. There's no
> GoDaddy issuer.
>
> And the reason for that is that QSslSocket does not send the Server Name
> Identification SSL extension, whereas Firefox does. You can compare the two
> behaviours with:
>
> openssl s_client -connect bugs.meego.com:443 -servername bugs.meego.com
> openssl s_client -connect bugs.meego.com:443
>
> QSslSocket in Qt 4.8 does send SNI now.
Any chance this could be backported to stable 4.7?
Alternatively, one can do
QSslConfiguration config = _currentRequest.sslConfiguration();
config.setProtocol(QSsl::AnyProtocol);
_currentRequest.setSslConfiguration(config);
to force switchover to TLSv1 if SSLv3 does not work...
--
/ Alexander Bokovoy
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] https://bugs.meego.com/ can not work now, when will it be recovered?
Hi, On Thu, May 5, 2011 at 03:53, Gabriel M. Beddingfield wrote: > On Wednesday, May 04, 2011 07:12:57 pm David Woodhouse > wrote: >> On Fri, 2011-04-29 at 12:22 +0200, Andre Klapper wrote: >> > Works fine. Whatever "can not work now" is meant to >> > mean, next time at least posting your error message >> > would be welcome. >> >> For me it seems to have an invalid (self-signed) >> certificate. Although I only noticed that just now; has >> it changed? > > I show that it it is certified by Go Daddy Secure > Certification Authority and has a SHA-1 hash of: > > B0 6A AD 46 F7 5D B4 7B 55 53 7A 8E 08 DA 69 FD 7B DC FB A5 > > (https://bugs.meego.com) There seem to be some misconfiguration of SSL setup at meego.com. I tried with QtWebkit and it also unable to reach and render it. Looking into a network trace I can see that Firefox 4 talks TLSv1 to meego.com while QtWebkit uses SSLv3. When SSLv3 is used against meego.com, it responds: 40.222344192.168.100.34140.211.166.238SSLv3Client Hello 60.445039140.211.166.238192.168.100.34SSLv3Alert (Level:Fatal, Description: Handshake Failure) That's it, there is relatively little on the wire. I found this first when trying to debug RSS feed fetcher but it exhibits the same behavior with bugs.meego.com. -- / Alexander Bokovoy ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Architecture decisions (was Re: migration (back) to EDS)
Hi Arjen, On Fri, Mar 25, 2011 at 17:30, Arjan van de Ven wrote: >> I wouldn't have thought there was, but obviously the statement above from >> Arjan van de Ven concerned me. > > my concern is based on the (lack of) progress around QSparql in MeeGo. I'm > sure it's all great in Harmattan, > but a solid story for MeeGo has so far been lacking. Ideally QSparql becomes > a real, full and open source member of the Qt family of APIs. > (a solid story also includes proper moving away from older APIs) Where exactly your concerns are coming from? http://maemo.gitorious.org/maemo-af/qsparql and http://maemo.gitorious.org/maemo-af/libqtsparql-tracker are alive and available. Development there hapens daily. Developers are available at upstream tracker IRC channel. The code there exactly what is used in Harmattan, packages get built straight out of gitorious.org. Are you concerned that nobody has submitted libqtsparql-tracker for about three months to OBS? QSparql build itself as over a month old. I guess an "architecture decision" story hasn't really added any assurance at all. > Until that's there color me a bit skeptical... it's been promised for a > long time and hasn't really materialized very well yet. Code is there open, development is happening openly, and for what it worth, it gets very extensive testing as part of Harmattan application development. Don't tell me that at this level (Tracker <-> QSparql) testing in MeeGo would be totally different from any other recent GNU/Linux environment. Regarding "proper moving away from older APIs", meego-handset-photos hasn't seen any development in gitorious.org since October2010. Where can I find a recent version? -- / Alexander Bokovoy ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Meego Video API's
On Sat, Mar 5, 2011 at 13:28, Felipe Contreras wrote: >> Moorestown/Oaketrail is enabled via vaapi (with gstreamer elements wrapping >> vaapi.) Most app developers will have no need to do anything other then use >> the Qt/Mobility API. If the app needs to build an exotic pipeline then they >> can directly work with gstreamer, and if the app already has it's own >> concept of a pipeline infrastructure then the app could choose to directly >> talk to VAAPI. >> >> Some pinetrail based tablets (like the WeTab/ExoPC) have a third party hd >> video decoder. There is no such support for this in meego. I have no idea >> if somebody is planning to add support, but some kind of linux solution >> exist since this is integrated into the Linux that comes on WeTab. > > That's internals, the API for applications is GStreamer. Right? Qt MultimediaKit + QtGstreamer, for those of Qt destiny of any reasonable complexity and GStreamer for others. In other words, GStreamer is the one thing to hide low-level internals. -- / Alexander Bokovoy ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Gstreamer framework will upgrade to latest version 0.10.32
On Wed, Jan 19, 2011 at 09:31, Teemu Tuominen wrote: > Recarding N900 camera effort, this will take some time I'm afraid, but > generally I feel fine with update. > > The first appearance is that camerabin(1) with 0.10.20.3 still seems to use > metadatamux. > > We will need to build gstreamer with buffer-alignment (SR#11485) before we > can fully test our camera stack. There wasn't a bug for that, since we don't > have the setup to reproduce it with the current Meego images. > > In meantime, are there already efforts made to utilize Camerabin2 in Meego > 1.2 ? and should us concentrate on that scenario already. Work on camerabin2 continues upstream. I hope we'll be able to utilize camerabin2 in MeeGo 1.3. -- / Alexander Bokovoy ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Buteo MTP + gadgetfs
Hi, On Fri, Jan 14, 2011 at 17:52, Patrick Ohly wrote: > Hello Buteo team! > > I'm happy to report that Paul's gadgetfs-based transport for the Media > Transfer Protocol (MTP) passes initial tests and that we obtained > permission to publish the code. We'll do so shortly and hope to get this > included in buteo-mtp. Great! > Currently the code runs as part of mtp_test when started as root. That's > necessary because /dev/gadget must be read/writable. But eventually the > code needs to run as plugin as normal user inside msycnd. Initially the > process accesses /dev/gadget/ to configure USB, then some new > entries (like /dev/gadget/ep-a) which are created by gadgetfs based on > that configuration. We could do a "chmod" as root to grant the msyncd > process read/write permission for /dev/gadget/, but that doesn't > help with the additional files, which are exclusively for root. If > anyone knows how to solve this, ideally without patching the kernel, > please speak up... As these are devices, they would appear through udev events so you can handle it with udev scripts. > Even if there is a solution, which permissions would be suitable? We > don't want to grant all user-space processes the right to modify the > device's USB config. Here's one possibility: > * add a group "sync" > * make msyncd setgid "sync" > * grant the "sync" group read/write access > > The drawback is that everything running inside msyncd, including > third-party plugins, will have the possibility to reconfigure USB. I > don't see how this can be avoided, except by separating different sync > sessions into different processes. Splitting out the setup phase into a > separate setuid or setgid binary does not work, because the MTP > transport in msyncd needs full read/write access to everything, > including the main /dev/gadget/ file descriptor. > > IMHO granting privileges as part of the MeeGo Security Framework has > similar issues and perhaps changing msyncd such that it runs each sync > inside a separate process would be worthwhile in the long run (also > better for stability), but this is clearly out of scope right now. Yes, this is drawback clearly and process separation is welcomed. We did same in sharing framework when webupload-engine needed to load plugins which would do access to accounts and sign-on storage. So plugins are run in separate processes now. > /usr/share/mtp/deviceinfo.xml contains information like hardware vendor > and model. We need a way how this can be modified without recompiling > buteo-mtp. Perhaps the file could be installed in and read > from /etc/mtp, where device images or scripts can modify it? I think we need to follow traditional FHS way of handling config files (after all, this is config file) and have the default in /usr/share/mtp but use it only if /etc/mtp does not contain the one. > The path under which files are made accessible via MTP is currently > hard-coded to /home/user/MyDocs. "PlayLists" as sub-directory of that is > created by the MTP code. > > What is the purpose of "PlayLists", or in other words, how is it > special? How can the /home/user/MyDocs path be made configurable? Would > deviceinfo.xml be a good place? Could we use XDG user-dirs instead? Qt gives you QDesktopServices::storageLocation() for most of those paths albeight this is part of QtGui code even though it could have been in QtCore (there is only string management there and some cludge for openDocument() method around X11). So MyDocs would be QDesktopServices::storageLocation(QDesktopServices::DocumentsLocation). Alternatively, you can take inspiration from storageLocation() and make own implementation which does not require QtGui (it doesn't for this particular part, just placement of the method is a bit unfortunate). -- / Alexander Bokovoy ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Qt uses OpenSSL, and fails?
On Thu, Dec 16, 2010 at 10:24, David Woodhouse wrote: >> More to that, OpenSSL since late 0.9 versions has proper support to >> load crypto engines supporting other cryptography schemes. In >> particular, this is important for supporting Russian and Chinese >> cryptography standards. Neither of competing options has such feature >> and support -- not at least for Russian crypto. > > There are no PKCS#11 modules for Russian crypto standards? That seems > odd. There are proprietary ones, of course. http://cryptocom.ru/OpenSource/OpenSSL_eng.html adds more to the context. The code is in OpenSSL 1.0 already. Here is the (year's old) discussion on NSS and PKCS#11: http://old.nabble.com/Rus-GOST-89-td25395627.html It required to have few additions to PKCS#11 spec which was done last year. I'm not aware about open sourced version which does it as PKCS#11 module, currently known patches are in works to get into softoken of NSS -- https://bugzilla.mozilla.org/buglist.cgi?quicksearch=518787,519432,608725 -- / Alexander Bokovoy ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Launching browser
On Thu, Dec 9, 2010 at 16:34, Rubanov Ivan wrote:
> It doesn't work neither.
> I did:
> bool retVal = QDesktopServices::openUrl(QUrl("http://facebook.com";));
> qDebug() << "QDesktopServices::openUrl=" << retVal;
>
> and got message:
>
> QDesktopServices::openUrl= false
>
> Seems something goes wrong.
Make sure xdg-utils are installed, as Thiago said. If it still
continues to fail, file a bug to MeeGo bugzilla.
--
/ Alexander Bokovoy
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Launching browser
Hi, On Thu, Dec 9, 2010 at 16:03, Rubanov Ivan wrote: > Hello, all. > I need to launch web browser from the code. How could I do it? I tried to > launch it using dbus. Actually I used maemo dbus code: > > QDBusMessage m = QDBusMessage::createMethodCall( > "com.nokia.osso_browser", > "/com/nokia/osso_browser/request", > "com.nokia.osso_browser", > "open_new_window"); > m = QDBusConnection::systemBus().call(m); > > Unfortunately it doesn't work. I checked /usr/share/dbus-1/services and > didn't find any service that could launch browser. > I added file called com.nokia.osso_browser.service to > /usr/share/dbus-1/services and still fails to launch it with the same error > as earlier: > Error org.freedesktop.DBus.Error.ServiceUnknown: The name > com.nokia.osso_browser was not provided by any .service files. > The code inside of com.nokia.osso_browser.service file is: > > [D-BUS Service] > Name=com.nokia.osso_browser > Exec=/usr/lib/fennec/fennec > > So, if I did something wrong or there is better (other?) way to do it, please > explain me. > > I use N900 and meego-handset-armv7l-n900-devel-1.1.80.9.20101207.1-mmcblk0p > image. Use QDesktopServices::openUrl() instead. It should use proper mime type database and launch registered default application. -- / Alexander Bokovoy ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Qt uses OpenSSL, and fails?
Hi, On Wed, Dec 8, 2010 at 21:44, Thiago Macieira wrote: > Em Quarta-feira, 8 de Dezembro de 2010, às 08:49:30, Arjan van de Ven > escreveu: >> On 12/8/2010 8:44 AM, Rémi Denis-Courmont wrote: >> > - use GnuTLS or NSS instead of OpenSSL, >> >> we should be using NSS anyway wherever possible, not just for the >> licensing side, >> but also because openssl has a history of ABI mess. > > Which should hopefully be a thing of the past now that OpenSSL has reached > version 1.0. > > NSS is an alternative, but I think our legal department ruled out any Qt-NSS > code a while ago. I remember this because when the LSB wanted to standardise > on NSS, we reported we could never use it. I don't know if the circumstances > are still the same. Yep. More to that, OpenSSL since late 0.9 versions has proper support to load crypto engines supporting other cryptography schemes. In particular, this is important for supporting Russian and Chinese cryptography standards. Neither of competing options has such feature and support -- not at least for Russian crypto. -- / Alexander Bokovoy ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] data storage and indexing in MeeGo - a survey - libcontentaction
On Fri, Sep 10, 2010 at 13:23, Patrick Ohly wrote:
> On Thu, 2010-09-09 at 11:50 +0100, Patrick Ohly wrote:
>> On Wed, 2010-09-08 at 20:25 +0100, Alexander Bokovoy wrote:
>> > On Wed, Sep 8, 2010 at 21:29, Auke Kok wrote:
>> > > Do we need bugs against handset components for not providing the proper
>> > > "MimeType=..." fields in the respective handset app's .desktop files?
>> > Yes, we do need that. See libcontentaction for details.
>>
>> Ah, great! That was what I was looking for. Thanks for the pointer.
>
> After thinking about this some more, I'm still wondering whether a truly
> generic Tracker search + visualization + action implementation is
> possible.
>
> For a simple kind of visualization, yes, this probably works:
> 1. show uri (not localized, very technical)
> 2. pass uri to Action class to get list of available actions
> 3. show ContentAction::Action's localized name and icon (both from
> the .desktop file)
>
> But step 1 is clearly not sufficient. What would be needed instead is
> some class specific formatter which extracts further information and
> displays that. For example, a contact might be displayed with photo and
> full name.
So far this is part of application-specific resource usage and user
experience design for that application.
For example, a hypothetical file manager might want to expose broken
apart nfo:fileUrl while image viewer would use thumbnail and image
description (coming from EXIF or XMP) instead, not showing the name of
resource at all.
> I was wondering whether there were "generic" RDF triplets that would
> help (like "display name" or "thumbnail", set for anything which has
> something remotely resembling such properties), but that doesn't seem to
> be the case.
>
> Is there perhaps a libcontentvisualizer or libcontentsummarizer (mapping
> to some common properties, like thumbnail and text)? I doubt it because
> this is so design specific, but as always, better ask than be sorry ;-)
Exactly, it is too specific to application problem domain and UI
design concept so that making it generic would probably not work well.
Add to that l10n support and you'll get into real trouble even with
moderately rigid set of 15 languages in N900.
> Regarding step 3, there's a similar issue. Suppose there is a contact
> with several email addresses and an action for email addresses described
> as "send email". It would be nice to show this as:
> Aaron Alewife
> send email to work address (aaron.alew...@work.com)
> send private email (aa...@alewife.name)
>
> Instead one can only concatenate:
> Aaron Alewife
> work address (aaron.alew...@work.com): send email
> private address (aa...@alewife.name): send email
This is again question of representing actions: do you start from the
subject or object, do you want to play around the language forest by
using graphical concepts instead of the text and reverting to the
textual representation only for the parts that absolutely require it
(email address, for example). Each decision made limits the number of
choices and actually becomes part of the UX definition. For example,
http://meego.com/developers/ui-design-guidelines/handset/designing-your-application
recommends drill down style which implies repeatedly shortening
context choices.
If you are after the action rather than the tool (I want to send a
message to Aaron rather than I want to use Aaron's email), this moves
you through the context by eliminating extensive information -- after
you decided about sending an email, no need to repeat this information
again, concentrate on sending email options. This breaks down need for
linguistically perfect statements, for example, and allows to get away
without libcontentvisualizer or libcontentsummarizer.
This is just an example, not a rule, though.
> The part before the colon would have to be generated by some domain
> specific code.
>
> Because the "send email" part is provided by MeeGo apps without
> necessarily knowing in which context the text will be used, should we
> establish some MeeGo guidelines?
>
> For example:
> * reasonably short (40 characters)
> * no complete sentence
> * therefore capitalization as in the middle of a sentence ("send
> email" instead of "Send email")
I would rather go through the existing UI guidlines and look at what
style of communication it tries to promote, then design action
summarization guidelines around those.
--
/ Alexander Bokovoy
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] data storage and indexing in MeeGo - a survey
Hi, On Wed, Sep 8, 2010 at 21:29, Auke Kok wrote: > Do we need bugs against handset components for not providing the proper > "MimeType=..." fields in the respective handset app's .desktop files? Yes, we do need that. See libcontentaction for details. We also need libcontentaction in the Meego, if it is not yet there. It already implements mapping of handlers for the ontology parts. Ideally, it also need to be bound on Qt at QDesktopServices's url handler provider so that QDesktopServices::openUrl() will work with any of those. I think it is done in harmattan but not in the stock Qt yet. [libcontentaction] http://maemo.gitorious.org/maemo-af/libcontentaction -- / Alexander Bokovoy ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] How to get screen shot on Meego?
On Mon, Aug 16, 2010 at 06:00, Huo, Halton wrote: > Hi, > > I’m running the handset image on netbook. When I pressed the PrintScreen > key, there is nothing hannpens. Anyone know how to get a screenshot on > Meego? From meegotouch corelib/scene/mscene.h: - Development mode visual overlays, providing information to help debug applications: - Bounding rectangles, toggled by --B - Margins, toggled by --M - Positions, toggled by --P - Sizes, toggled by --S - Object names, toggled by --N - Frames per second, toggled by --F - Take screenshot, triggered by --T So you could try Ctrl-Shift-T for MeeGoTouch-based Handset applications to create screenshots. At least, it worked on my standalone compile and run of Widgets Gallery, you get screenshot saved in ~/MMDD-HHmmss.png where YYYMMDD represents date and HHmmss represents time. -- / Alexander Bokovoy ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Browser EAL?
On Tue, Mar 16, 2010 at 10:06 PM, Tomasz Sterna wrote: > Dnia 2010-03-16, wto o godzinie 21:47 +0200, Alexander Bokovoy pisze: >> So, yes, re-using Tablet Browser process separation is nice but >> expecting that things will work with QtWebKit interfacing with it is >> rather optimistic. > > I didn't say anything about QtWebKit. If someone wants to integrate it - > cool. > > But there are web browser engines that are designed from the ground to > have a clear separation of the layout engine and the user interface, > that would fit nicely in the current Browser + EAL schema. Does this really applicable to what is in Maemo 5? I know that implementation is different since the time Webkit-EAL was done. I can ask Romaxa to comment on the topic later this week if he will find time... -- / Alexander Bokovoy ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Browser EAL?
Hi, On Tue, Mar 16, 2010 at 8:59 PM, Tomasz Sterna wrote: > Dnia 2010-03-16, wto o godzinie 10:36 +0200, Alexander Bokovoy pisze: >> Unfortunately, there is no common support for that in current Gecko >> and WebKit implementations, they only support in-process EAL/UI >> separation. There is ongoing work on Mozilla side to have something >> similar to MicroB out-of-process separation (Electrolysis, >> https://wiki.mozilla.org/Electrolysis). One particular reason why it >> is relatively hard to do is due to use of the same event loop for both >> UI and EAL event processing. > > IIUC in Maemo EAL does not need to create any UI. It only sends/receives > D-BUS events and is perfectly fine with separate event loop - EAL runs > in separate proces under control of browserd and it's event loop handles > only I/O and rendering the page. The whole UI is handled in Browser > process separately. And it took Maemo browser team 1.5 year to develop this solution (it does not use D-BUS for interacting between EAL process and UI process, btw). Just to measure complexity and what you need to do. What you are missing here is that this process separation for engine and UI is not yet finished for upstream Gecko/Firefox (see Electrolysis) and not done for WebKit except for specific instance used within Chrome. So, yes, re-using Tablet Browser process separation is nice but expecting that things will work with QtWebKit interfacing with it is rather optimistic. -- / Alexander Bokovoy ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Browser EAL?
On Tue, Mar 16, 2010 at 2:53 PM, Alberto Cerato wrote: > Alexander Bokovoy wrote: >> Hi, >> >> On Tue, Mar 16, 2010 at 9:22 AM, Tomasz Sterna wrote: >>> Will MeeGo keep the Browser UI and Web Engine Abstraction Layer[1] >>> separation of Maemo? >>> > > I have mixed feelings about EAL and similar solutions. Abstraction is > a godd thing, but sometimes you lose advantages having the web engine > integrated in the UI toolkig (e.g. QtWebKit and Qt). I think one of key points you would need to support is to take apart event loops on backend and UI processing. It is one of issues with Mozilla and XUL where JS processing in XUL could slowdown rendering on the page and vice-versa. Similar with WebKit. But I'm not a browser developer in any way. -- / Alexander Bokovoy ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Browser EAL?
Hi, On Tue, Mar 16, 2010 at 9:22 AM, Tomasz Sterna wrote: > Will MeeGo keep the Browser UI and Web Engine Abstraction Layer[1] > separation of Maemo? > > I think it's worth keeping, since MeeGo is targeted for many > manufacturers and this will allow them to select the browser engine they > want to provide to the users. > This will also allow users to replace the engine if the one provided > does not fit her. > > There are already Gecko 1.9 EAL (MicroB)[2] and WebKit EAL[3] to choose > from. In order to do that, you have to have support for separated UI within the EAL as well. There are two different types of UI separation: in-process and out-of-process. In Maemo 5 out-of-process UI separation is used, MicroB EAL runs in a different process than UI. Unfortunately, there is no common support for that in current Gecko and WebKit implementations, they only support in-process EAL/UI separation. There is ongoing work on Mozilla side to have something similar to MicroB out-of-process separation (Electrolysis, https://wiki.mozilla.org/Electrolysis). One particular reason why it is relatively hard to do is due to use of the same event loop for both UI and EAL event processing. Again, I have not see any such work on WebKit side apart of Chrome-specific implementation which is not easy to port over to other WebKits. -- / Alexander Bokovoy ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
