![]() |
Re: [WIP] Alopex: a mozilla embedlite implementation on fremantle
We have a couple of options:
1. Migrate to Qt5 Pros: maybe better performance of the library, being always up-to-date, no problem "they'll drop our support" Cons: More RAM usage, possible problems with the port being buggy 2. Stick with Qt4 Pros: no additional work required (apart from the UI creation) Cons: Being more and more out-of-date, not receiving updates, need to find a stable commit. 3. Go for Gtk Pros: Gtk support is still there, performance Cons: Manpower that knows Gtk, how long will they support gtk2, Gtk and Mozembed issues. No examples (correct me if I'm wrong) 4. Switch to WebKit Pros: We have QtWebkit in Qt4, good documentation Cons: WebKit is unmaintained AFAIK, WebKit in Qt5 is probably newer. 5. Port Fremantle to Qt5 Pros: compat, possible performance Cons: Whole lotta work! Really whole lotta... Impossible for two-men team :) Please add your opinions and suggestions. |
Re: [WIP] Alopex: a mozilla embedlite implementation on fremantle
With regards to gtk, tmeshkova makes it sound like we only need to reimplement qtmozembed in gtk. Compared to maintaining a qt port for mozilla/xulrunner, this would be much easier.
A quick check of dependencies, we meet most of them. Python requires 2.7.3, we have an -rc version but it might still work. |
Re: [WIP] Alopex: a mozilla embedlite implementation on fremantle
Wasn't that canvas thing a roadblocker for GTK version, that no one had idea how to solve?
|
Re: [WIP] Alopex: a mozilla embedlite implementation on fremantle
GStreamer patch needs some updating at the moment if anyone is looking into options. Recent commit added some if statements for gstreamer 1.0 in first patched file and removed a function from the list in the second. I will push to repo at some stage once I've tested build.
Code:
Index: gecko-dev/content/media/gstreamer/GStreamerFormatHelper.cpp |
Re: [WIP] Alopex: a mozilla embedlite implementation on fremantle
Android_808: You were concerned about loading qt5 libs into RAM. But doesn't each app load the libraries separately? So the RAM difference won't be
Code:
size(Qt5libs) Code:
size(Qt4libs) - size(Qt5libs) IIRC applauncherd was working it around by sharing libraries among apps |
Re: [WIP] Alopex: a mozilla embedlite implementation on fremantle
What happens if you multitask, say have OMP and browser opened? You'd then need to have Qt4 for OMP loaded and Qt5 for browser.
My real concern with qt5 was how well supported it is on Maemo. I don't see a great deal of apps using it, if any. If you compare the amount of code ripped out in the recent qt5 commit in embedlite, the new port seems to be much easier to work with for some interactions. However that simplification must at times come at a cost of increasing qt library size. |
Re: [WIP] Alopex: a mozilla embedlite implementation on fremantle
Quote:
|
Re: [WIP] Alopex: a mozilla embedlite implementation on fremantle
as i understand it. 2 apps each have text/data and a link to library. loading app 1 causes the app and library text to be loaded. loading app b causes its text to be loaded and page table entries are mapped to existing copy of library. the librarys read-only data segment is shared until an edit is made in which case that app gets its own copy.
|
Re: [WIP] Alopex: a mozilla embedlite implementation on fremantle
I have cssu thumb and all the files provided are not installed , alopex doesn't run . help ???
|
Re: [WIP] Alopex: a mozilla embedlite implementation on fremantle
@Android_808: You were right: http://unix.stackexchange.com/questi...irect=1#116332
|
All times are GMT. The time now is 12:16. |
vBulletin® Version 3.8.8