View Full Version : Meego: Goodbye Mozilla, hello Webkit?
There's been so much noise about Harmattan and MeeGo, but I find it interesting that I haven't seen any comments on the fact that Nokia will probably be dumping the Mozilla-based browser engine to go instead with WebKit, the browser engine found in their competition, Android and iPhone OS.
Why do I say this? Nokia has clearly stated that they will be supporting the Nokia WRT (Web RunTime) engine based on WebKit in Harmattan forward. Why would they have two big bulky browser engines on a limited-resources device?
So now we know why Firefox is being ported to the N900 so aggressively when the N900's Mozilla-based browser is currently one of the best in the industry.
In Harmattan, Firefox, an optional, third-party browser, will the Mozilla-based browser. Just like almost every other platform (except maybe Ubuntu? Can you get Ubuntu on anything out-of-the-box?).
Is there anyone else a bit sad about this?
livefreeordie
2010-03-15, 18:50
Is there anyone else a bit sad about this?
I've always preferred Konqueror, so not me. Unfortunately KHTML is getting so dated I'm forced to use Firefox on the desktop, but more people working on WebKit can't hurt at least.
javispedro
2010-03-15, 18:55
I think it's a good point, but also consider WRT is also planned (or at least, was planned) for the N900, where both webkit and microb will coexist from PR1.2 onwards... (unless they plan to ship Qt without Webkit, which I doubt).
Not been a linux/maemo user for long but why would they get rid of the browser we have now? Its fast, it loads full web pages well and has a nice easy UI to it, i wudnt give up microb for any other browser at the moment. Im not sad by this news i just hope they do it correctly, i porsonaly prefer opera (gecko is it?) over webkit.
It is better to have MeeGo WebKit browser and Firefox Mozilla on future MeeGo devices than having two very similar Mozilla-based browsers. Keep in mind that Firefox doesn't need much to become as good as MicroB and it has a great potential to even surpass it by the time MeeGo+WebKit will be here.
Is there anyone else a bit sad about this?
In the same lines of other topics around MeeGo, I would wait for facts before feeling sad (or happy for that matter).
No no no no.
Webkit might have faster javascript execution or so, but if you look at MicroB and compare it to S60 Browser, iPhone Safari or Android Browser, there is no doubt which is superior.
HangLoose
2010-03-15, 19:22
I say, let Mozilla do their bit and let Nokia concentrate on one browser...
AFAIK, the webkit will also be used as a development strategy (much like python, qt) correct? I think the decision went for keeping a standard across all the platforms because of Qt.
As long as I have more options for browser for me it is okay...
sjgadsby
2010-03-15, 19:27
...I haven't seen any comments on the fact that Nokia will probably be dumping the Mozilla-based browser engine to go instead with WebKit...
Hmm. I could have sworn someone from Nokia* stated some time ago that in Harmattan, the browser would continue to be Mozilla-based, while WRT would use WebKit. I believe that was pre-MeeGo, but I would imagine it will hold true for Harmattan at least.
* My brain is telling me it was qgil responding to a question posted by YoDude, but my brain isn't to be trusted.
EDIT: Yep, my brain was completely wrong. go1dfish responded to Bundyo with second-hand information (http://talk.maemo.org/showthread.php?p=443052#post443052).
(qgil launched the thread, and there's a "yo" in "Bundyo". Yeah, stupid brain.)
i porsonaly prefer opera (gecko is it?) over webkit.
Mozilla is using Gecko. Operas layout engine is called Presto.
Mozilla is using Gecko. Operas layout engine is called Presto.
Thanx for the info.:D
Ok, the vibe I'm getting (beyond the usual "Stop speculating; wait for official announcements") is that there will be a nice overlap period where we'll have the two major open source browser engines living side-by-side on Maemo/MeeGo devices, as crazy as that sounds. Meego, the OS with two browser engines built-in!
As warm and fuzzy as that is, I can't see that as being sustainable indefinitely. Just like Qt and GTK, In the long term, Nokia's going to have to choose an "official" browser platform. Since Qt and WRT have both made that decision already, and they chose Webkit, I just don't see Mozilla winning here.
Since Qt and WRT have both made that decision already, and they chose Webkit, I just don't see Mozilla winning here.
+ That Other Nokia Platform (tm) allready uses Webkit.
Ignacius
2010-03-15, 20:43
I wouldn't be surprised if Nokia drops Gecko in favor of Webkit. The fact that Gecko is always loaded in memory in Maemo <= 5 so the browser starts faster is not the most desirable situation in a limited resource environment as a mobile phone. Also, Gecko has it's own toolkit so it doesn't fit with the rest of the desktop. If you want Gecko, installing Fennec should do the job.
ITOH I'm willing what is Nokia going to do for the Qt-ified Modest as it needs an HTML widget with DOM capabilities accesible through his API and AFAIK Qt Webkit lacks this support.
I personally prefer Gecko. I also don't expect Gecko to be dumped in favor of WebKit, but of course everyone can be proved wrong.
Opera is out of question. Its also buggy as hell. Still. :D
Can we have a question mark on the end of the topic? There's no WebKit default browser in MeeGo yet AFAIHS.
Nightly Fennec is already faster than microb in some cases if you don't mind initial start time and it is being updated frequently unlike all Nokia software.
For example microb fails to render wow armory properly and despite bugzilla says it is fixed in upcoming firmware for over 2 patches now I can't just grab nightly and use it if I choose to do so.
I personally prefer Gecko. I also don't expect Gecko to be dumped in favor of WebKit, but of course everyone can be proved wrong.
Oh I hope you aren't proven wrong.
Can we have a question mark on the end of the topic? There's no WebKit default browser in MeeGo yet AFAIHS.
There's no MeeGo yet AFAIHS. ;)
But I agree, a question mark would be better. If I could change it I would. And I tried. Really! I did!
I think one of the reasons Nokia stayed with Gecko was because of XUL?
There's no MeeGo yet AFAIHS. ;)
Well, my netbook says MeeGo on boot and I didn't put any specific boot screen there :P
Bundyo: oh come on, you grabbed that short-lived version of Moblin that was superficially branded as MeeGo. Can anyone else get that version?
ARJWright
2010-03-16, 01:42
There's probably more experience with Webkit, and given that its already integrated with Qt, it makes sense to go that route. Plus, Symbian and S40 both use Webkit-based browsers, and so this makes for easier porting of WRT and other tech between them.
Hopefully, Nokia will unifiy the engine, controls, and UI across these platforms. This move would make a lot of sense for them.
For Mozilla, it would be a good play as well, as they'd get to play a good bit more with making the browser-as-a-platform, and work out the usability of Weave on OSS and closed systems.
ARJWright: So you think it would actually be better for Mozilla if the Gecko-based browser in Maemo/MeeGo was replaced with a Webkit one? That's an interesting view.
I can see what you mean, though. By offering the Firefox-branded browser to MeeGo as a separate product, Mozilla can have much more control over the experience.
but I find it interesting that I haven't seen any comments on the fact that Nokia will probably be dumping the Mozilla-based browser engine to go instead with WebKit
Even though it turned out to be false, you did (http://talk.maemo.org/showthread.php?p=268940), over a year ago.
ossipena
2010-03-16, 05:04
Not been a linux/maemo user for long but why would they get rid of the browser we have now? Its fast, it loads full web pages well and has a nice easy UI to it, i wudnt give up microb for any other browser at the moment. Im not sad by this news i just hope they do it correctly, i porsonaly prefer opera (gecko is it?) over webkit.
you haven't tried webkit with n800. It was unbelieveable at the time the first patches appeared to itt. It was blazing fast compared to OS2008 microb....
daperl: good memory! And good catch!
As long as it's not remotely close to the Symbian browser and like the MicroB I don't care if they even use Internet Explorer's engine! :)
we'll have the two major open source browser engines living side-by-side on Maemo/MeeGo devices, as crazy as that sounds. Meego, the OS with two browser engines built-in!
We've had two for quite some time now: gecko for the browser (OK, and maps in Fremantle) and gtkhtml for everything else (email, rss etc). Seems to me like webkit will take the place of the latter as a somewhat lightweight engine embeddable in whatever app needs it.
ZShakespeare
2010-03-16, 06:44
If using webkit to render pages improves performance on the same level that Chrome/Safari have demonstrated over Firefox, I'm all for seeing that checkerboard/grid pattern less.
Why do I say this? Nokia has clearly stated that they will be supporting the Nokia WRT (Web RunTime) engine based on WebKit in Harmattan forward. Why would they have two big bulky browser engines on a limited-resources device?
AFAIK WebKit support is built-in Qt, so considering Harmattan is Qt based, they have no choice of not supporting it. :rolleyes:
But that does not necessary mean, that the browser will be WebKit based. Let me explain a bit Maemo browser architecture.
MicroB is not N900 web browser.
N900 web browser is called... Browser.
It's a high level component providing the UI for the web browsing. The rest is provided by EAL - Engine Abstraction Layer - which is remote-controlled by browser with D-BUS calls. EAL is a component (a daemon in Maemo 5) that provides the web browsing engine. The default EAL provided in N900 is Mozilla Gecko based and is called MicroB.
This architecture allows for easy engine replacement - either by Nokia, the OEM or the user.
I don't know whether that architecture will be used in MeeGo, but I hope so. This will allow the freedom of choice - not leaving you with "the one" chosen by the manufacturer.
I always (in general, on different computers) use lots of different web browsers. On my N800 I preferred Opera. On the desktop I use several at the same time.
However, on all these devices, I've found that it's best to have a gecko/mozilla-based browser readily available, because at some point it's the only browser that may work properly at certain sites, often important ones. Sometimes it's a silly as getting through the login-page of networks that require you to enter a user and code before you can access it.
So go webkit, that's fine, but please someone leave us with a backup mozilla/gecko-based browser, just in case..
ARJWright
2010-03-16, 12:19
ARJWright: So you think it would actually be better for Mozilla if the Gecko-based browser in Maemo/MeeGo was replaced with a Webkit one? That's an interesting view.
I can see what you mean, though. By offering the Firefox-branded browser to MeeGo as a separate product, Mozilla can have much more control over the experience.
Pretty much. With Mozilla having to play the role of owning the product that's not installed by default, they would have to show forth a product that's head and shoulders in UI and UX better than the default browser. This speaks well for developers and users, and keeps Mozilla on the side of "freedom of choice is good" which is in many ways how they approached the desktop.
MeeGo having a base platform that's using a different engine offers a chance to do enhancements to the browser that might not be directed by the browser engine. And - hopefully - a browser that doesn't turn stagnant because its OEM/ODM controlled.
I think Mozilla's significance is more important than it's ever been. IE has been handed its hat on the desktop by a one-two Gecko-Webkit punch, but now all eyes are on handhelds. Webkit branches sharply at the UI level, and thus, so do plenty of features. We're the big winners here so far, and as long Nokia continues to use Mozilla for the flagship browser we'll stay that way. It's a very good, yet bizarre twist of fate with all things considered. Either that, or Nokia is alot smarter than most of us give them credit for.
ARJWright
2010-03-16, 13:56
I think Mozilla's significance is more important than it's ever been. IE has been handed its hat on the desktop by a one-two Gecko-Webkit punch, but now all eyes are on handhelds. Webkit branches sharply at the UI level, and thus, so do plenty of features. We're the big winners here so far, and as long Nokia continues to use Mozilla for the flagship browser we'll stay that way. It's a very good, yet bizarre twist of fate with all things considered. Either that, or Nokia is alot smarter than most of us give them credit for.
However, while Nokia uses a Gecko-engined browser, they aren't using one that seems to use the better user-facing aspect of it - extensions (edit: extensions which are cross-device and platform compatible). If that piece of things were more in sync with Mozilla's Firefox, then I could agree that Nokia is being smarter. At this point, I'm not sure so much that its an issue of being smarter - especially with they have Webkit already in-house and on their other, larger platforms.
At this point, I'm not sure so much that its an issue of being smarter - especially with they have Webkit already in-house and on their other, larger platforms.
Smart, as in they're simultaneously championing both technologies. Maybe smart's not the exact word I was looking for. But I'm a big OSS person, so watching Nokia step into Google's shoes to foster good, clean competition is a good thing. Maybe that's the word I was looking for: Good. As in good vs. evil. Nothin' like a little drama on a Monday morning!
We've had two for quite some time now: gecko for the browser (OK, and maps in Fremantle) and gtkhtml for everything else (email, rss etc). Seems to me like webkit will take the place of the latter as a somewhat lightweight engine embeddable in whatever app needs it.
I wish they were using something fast and lightweight for rendering the Conversations window. As soon as you start tweaking the CSS of the page (for instance, to make speech bubbles), the rendering grinds to a crawl.
The smart guys over in the Customize N900 Conversations (http://talk.maemo.org/showthread.php?t=36618) thread say that it is being rendered with a Gecko engine. Makes me wonder about the pervasiveness of the Gecko engine throughout the UI...
I wish they were using something fast and lightweight for rendering the Conversations window. As soon as you start tweaking the CSS of the page (for instance, to make speech bubbles), the rendering grinds to a crawl.
The smart guys over in the Customize N900 Conversations (http://talk.maemo.org/showthread.php?t=36618) thread say that it is being rendered with a Gecko engine. Makes me wonder about the pervasiveness of the Gecko engine throughout the UI...
On the technical side, they probably had to go a route like this because all rows in the standard GTK list widgets have to be the same height. And you nailed it: It's a speed thing. These are inexcusable, but known weaknesses of GTK. But I'm still not sure using the Gecko engine was necessary. Currently, I'm recreating some of the mediaplayer functionalty, and I'm using JSON config files to expose Pango markup that I then use in a kind of variable argument printf statement. Here's a clip:
"list-store" : [
{"type":"pixbuf",
"value":["pixbuf","thumbnail-uri",5]},
{"type":"text",
"value":["<span size=\"13200\">%s\n","title",3,
"<span foreground=\"#a0a0a0\">%s</span></span>","duration",4]}]
I'm sure I could recreate the Conversations UI using a similar technique combined with GtkTables instead of GtkTreeViews. I also combine those JSON config files with GtkBuilder files. This leaves plenty of room for customization and fast scrolling. And no HTML/CSS overkill.
javispedro
2010-03-16, 20:16
The smart guys over in the Customize N900 Conversations (http://talk.maemo.org/showthread.php?t=36618) thread say that it is being rendered with a Gecko engine. Makes me wonder about the pervasiveness of the Gecko engine throughout the UI...
From looking at the "rtcom-messaging-ui" package dependencies, they seem to use browser-neteal (aka the rendering engine abstraction layer).
So theoretically you could even plug Webkit or Opera in ;)
Whoa, I just took a long look over at the conversations thread. It must be Gecko. Well, welcome to the WRT preview. I don't think this is a good direction. If you think people are complaining about speed and battery consumption now... Until Javascript is in its 2nd or 3rd generation of multi-threading support, I will probably be steering clear. Currently, it's the wrong tool for the job. I'm a little concerned. The latency of dbus asynchronous communication is plenty for me, thanks. Don't we all have enough bad experiences with crappy Javascript and websites? If WRT is suppose to be the answer for opening up the platform to gather more developers, are these the types of developers we want for front facing apps? I say no. And f*ck no. I was all ready for Qt and hardcore C++ programmers.
Does Nokia have it backwards? The OS is suppose to be easy and joyful to use. I'm going to paraphrase Einstein: Make API's and programming languages as easy as possible, but no easier. Isn't WebOS the only example we need of what not to do? It's a beautiful OS that seems to be choking on Javascript. Oh, the virus of the browser. Me frightened. Rant over.
On the technical side, they probably had to go a route like this because all rows in the standard GTK list widgets have to be the same height. And you nailed it: It's a speed thing. These are inexcusable, but known weaknesses of GTK. But I'm still not sure using the Gecko engine was necessary. Currently, I'm recreating some of the mediaplayer functionalty, and I'm using JSON config files to expose Pango markup that I then use in a kind of variable argument printf statement. Here's a clip:
"list-store" : [
{"type":"pixbuf",
"value":["pixbuf","thumbnail-uri",5]},
{"type":"text",
"value":["<span size=\"13200\">%s\n","title",3,
"<span foreground=\"#a0a0a0\">%s</span></span>","duration",4]}]
I'm sure I could recreate the Conversations UI using a similar technique combined with GtkTables instead of GtkTreeViews. I also combine those JSON config files with GtkBuilder files. This leaves plenty of room for customization and fast scrolling. And no HTML/CSS overkill.
It would be great if you could recreate conversations with speech bubbles using the techniques that improve performance / scrolling while providing room for customization.
Master of Gizmo
2010-03-16, 21:17
Why do I say this? Nokia has clearly stated that they will be supporting the Nokia WRT (Web RunTime) engine based on WebKit in Harmattan forward. Why would they have two big bulky browser engines on a limited-resources device?
Uhm, today they have gtkhtml (doing e.g. the html email rendering) and microb. Why shouldn't they have webkit and microb in the future?
It would be great if you could recreate conversations with speech bubbles using the techniques that improve performance / scrolling while providing room for customization.
I took a quick crack at seeing if I would have any scrolling issues with the GtkTable approach I was suggesting. None. I don't have markup yet 'cause GtkBuilder doesn't actually let you have markup inside UI files, and I was too lazy to produce a corresponding JSON file. That goes double for adding timestamps. Maybe tomorrow, but my proof-of-concept has just about run its course.
Also, adding bubble background pixbufs wouldn't be that difficult, and shouldn't cause any performance issues.
Anyway, no scrolling issues, and this is Python. Here's a screen shot of a 105 message conversation:
8142
I took a quick crack at seeing if I would have any scrolling issues with the GtkTable approach I was suggesting. None. I don't have markup yet 'cause GtkBuilder doesn't actually let you have markup inside UI files, and I was too lazy to produce a corresponding JSON file. That goes double for adding timestamps. Maybe tomorrow, but my proof-of-concept has just about run its course.
Also, adding bubble background pixbufs wouldn't be that difficult, and shouldn't cause any performance issues.
Anyway, no scrolling issues, and this is Python. Here's a screen shot of a 105 message conversation:
8142
It's great to have tmo members like you that are willing to do these kinds of things.
It looks good so far. Perhaps a new thread could be created for this so that we don't hijack the current thread since this stuff is a bit off-topic.
Thanks for the efforts so far!
@byte_76:
I appreciate the kind words, but I'm afraid I've misled you, and I apologize for that. You probably have heard this cliche before, but I'm just scratching an itch, and I have many that need my attention. But I am here to help as well as learn, so if you do find someone to champion your cause, I'm happy to answer any technical questions that I can.
After what qole wrote, and then seeing your post in the conversations thread, I was disturbed. I have a running conversation with my young son; we have great fun sending messages back and forth to each other from an iPod touch to my n900. I hadn't given it much notice, but sure enough, even using the conversations app default settings, scrolling is jerky and painful. That's why I did what I did.
Again, sorry, I'm not the goto guy on this one, but I did want to inspire someone else to pick up the ball. In my opinion, Nokia used a hammer where a screwdriver would do, but the promise of this environment is that the right community can fix such things. I see myself as just one cog here at tmo, but for my own selfish reasons I choose not to be a single point of success or failure. I tend to be a FOSS purest, so when it comes to anything software, my motto is simply: "Love it or leave it." That's where the best stuff comes from, and believe it or not, that quote is a paraphrase of something Steve Jobs believes. But he just seems to want to keep all the love for himself. Good luck!
P.S. Not to tease you further, but I'm not sure I've finished scratching this particular itch, so don't be surprised if I continue to post updates here. Considering that we know Harmattan will have a WRT front end, and kind of knowing the spirit of the OP's intent, I consider what I've been doing mildly relevant to this thread.
Granted, a very ugly first attempt at balloons, but it scrolls nice and I added some markup. Copy-and-paste is going to be the tricky part. I either have to create a lite version of GtkTextView, or just expand GtkLabel.
8189
I just came up with one of my best algorithms in about 2 years. The speedup and memory savings are possibly optimal. I should have a demo early this week, but I'm so excited that I just had to share. It's basically 5 mem copies per label background. The one-and-only, per-person background pixbuf grows to max-width and max-height as necessary. Since the corners never change, there's just four border copies and one middle section copy. No scaling, no Cairo, no extra memory, and no unnecessary memory creation/destruction. Just pixel-pushin' speed. And I get copy-and-paste for free. After that, it will be time to see about creating an entire read-only GtkTextView/GtkTextBuffer that could be exported as a document of a user's chosen format.
daperl: package it and they will come... :) ;)
@qole:
I'm just hackin' around, but I think I did what I came to do.
8310
...
If WRT is suppose to be the answer for opening up the platform to gather more developers, are these the types of developers we want for front facing apps? I say no. And f*ck no. I was all ready for Qt and hardcore C++ programmers.
Does Nokia have it backwards? The OS is suppose to be easy and joyful to use. I'm going to paraphrase Einstein: Make API's and programming languages as easy as possible, but no easier. Isn't WebOS the only example we need of what not to do? It's a beautiful OS that seems to be choking on Javascript. Oh, the virus of the browser. Me frightened. Rant over.
At last: someone else that finds this a scarey possibility! I got told by qgil that I was being paranoid and the only one!
At last: someone else that finds this a scarey possibility! I got told by qgil that I was being paranoid and the only one!
All I can figure is that it must have something to do with advertising. There's already a well established ad infrastructure built-in to the web. Otherwise, I can't make much sense out of it. It's a 180° from where I want to be going; the Web is a desktop technology, but relatively speaking, tcp and udp are lean-and-mean communication technologies.
I want to be running my own light weight walwart push server that is my instantly-connected proxy workhorse. It can filter and ping the crap out of other poorly implemented services for me. I want more fine-grain control of how I use my battery and CPU. I can't see WRT being that answer. But I can see the big players, Nokia included, wanting their own piece of push services. How much longer can the cellcos get away with being a messaging mafia?
Wow, I can't seem to stop this tangential ranting. Time for bed.
Web Runtime is for offline apps as well! The main point is "easy and fast to develop with a technology familiar to most web developers", not online push or something.
About security, I keep saying that security experts are confident about the Web Runtime so if you have concrete arguments please just expose them. Blunt conclusions based on the use of Javascript leave little space for constructive discussion. fwiw (http://library.forum.nokia.com/index.jsp?topic=/Web_Developers_Library/GUID-BDBE85E0-2A33-4AE9-92F6-85E1861256F0.html)
About security, I keep saying that security experts are confident about the Web Runtime so if you have concrete arguments please just expose them. Blunt conclusions based on the use of Javascript leave little space for constructive discussion. fwiw (http://library.forum.nokia.com/index.jsp?topic=/Web_Developers_Library/GUID-BDBE85E0-2A33-4AE9-92F6-85E1861256F0.html)
It's a pity that we don't have documents with that quality and organization for Maemo, but I still have hope :)
javispedro
2010-03-23, 16:08
It's a pity that we don't have documents with that quality and organization for Maemo, but I still have hope :)
Hey, we have (or used to have) the libhildon devhelp package, which wasn't that bad! (and also offline!).
If this idle speculation should happen to be fact, I would judge it as this:
- It would be sad because it would be leaving behind a part of the soul of Maemo. Maemo has always been about standing apart when it comes to internet browsing.
- It would be leaving behind advantages to go running after the competition. Much like Phone 7 dropping multitasking.
- It would be a shame because microb is a better browser than Firefox. microb is in manys opinion the best browser among the current alternatives.
- It would however not be the death of mobile browsing, because both the Gecko, Webkit and Gecko strains are improving fast. We have an OS that allows for installing whatever software someone is willing to port.
- I believe Nokia has resources to make a good webkit browser. Of course, that also goes for every competitor.
That said, this is idle speculation, right?
Yes, I will say it again, this is an Idle Speculation Thread.
I'm frustrated that I can't change the title of my thread to end in a question mark.
EDIT: Thanks Mr. Moderator for fixing my thread title.
Web Runtime is for offline apps as well! The main point is "easy and fast to develop with a technology familiar to most web developers", not online push or something.
Offline as well? Are you guys thinking about getting rid of the X server?
About security, I keep saying that security experts are confident about the Web Runtime so if you have concrete arguments please just expose them.
I'm not sure if you we're referring to me here, but I'm not worried about security in the context of this thread. When I mentioned being frightened, I was referring to resource usage such as the CPU.
Blunt conclusions based on the use of Javascript leave little space for constructive discussion.
I'm in the middle of porting my bluntness to C. I'll post it and the similar Python here soon. Even though some other details are needed for completeness, I think it's a decent demonstration of the technology differences. The default configuration of the Conversation app stutters consistently; it seems simple text that spans more than one line creates problems. According to others, these problems get noticeably worse as the UI configuration gets more complex. That makes sense, but there's no good reason for a simple UI to exhibit such behavior.
I didn't think so anyway, and I decided to demonstrate why. I'm not sure I can be more constructive than that.
As much as i hate flash, i hope that no matter what browser we get till the end on the n900 we at least get the accelerated flash 10 so we can have a good flash support until it's deprecated...
GeneralAntilles
2010-03-23, 21:51
I can see what you mean, though. By offering the Firefox-branded browser to MeeGo as a separate product, Mozilla can have much more control over the experience.
I can't say I have a whole lot of confidence in either company having control over the experience, although Nokia's experience has generally been more pleasant and usable than Mozilla's so far.
I suspect the dismal state of javascript on ARM is a big part of the problem with mobile browsers (and browser-based frameworks) at the moment. I think a well-optimised javascript engine would go a long, long way towards helping WRT (and the browser) fly.
daperl: A fast, themeable Conversations GUI replacement (even if those themes were just a handful of preset themes) would be an incredibly useful app for me.
I'm an edge-case user in many things, so I may be wrong, but I think there'd be some serious demand for something like that in Extras.
daperl: A fast, themeable Conversations GUI replacement (even if those themes were just a handful of preset themes) would be an incredibly useful app for me.
I'm an edge-case user in many things, so I may be wrong, but I think there'd be some serious demand for something like that in Extras.
I'll take a look under the hood and let you know what I see.
@qole:
Well, the obvious place to try and plug something in would be microb. It actually could be a killer hack depending on how much widget creation and communication is outside the proprietary stuff. I'm naively optimistic, as usual. You've sucked me in a little bit.
Copyright prohibits me from posting it here, but I ask anyone who cares, look at
line 517 of /usr/share/rtcom-messaging-ui/html/MessagingWidgetsChatConversation.js
and
line 642 of /usr/share/rtcom-messaging-ui/html/MessagingWidgetsSMSConversation.js,
and tell me if the comment and the following code doesn't concern you. If it doesn't, it should. It also might explain a few things. And just in case, my humble apologies if it doesn't mean what I think it means. :eek:
In space, no one can hear you scream.
@daperl: Why would they even want to wait one second before requesting?
Sounds very stupid IMO.
Wonder what would happen if you change it to maybe 100? :D
If I read the files copyright correctly, without Nokia's permission we can't disclose any information about the file's contents. I'm not sure I was even within my rights, yet the conversation thread posts changes to these files. So, I don't know, but my opinion is that it warrants discussion.
daperl: Interesting.
I assume that you are talking about the artificially introduced 1s delay to allow rendering of the first screen?
Did you try changing the delay? Did it make any difference? Do you think it really takes that long to render a screen of information?
Did you try changing the delay? Did it make any difference?
I just did. I put it to 1/10th the value. The behavior seems different but I'm not sure it's better. And I changed it back and forth a few times.
Do you think it really takes that long to render a screen of information?
Well, maybe in a Javascript for loop it does, but not anywhere else. I didn't look too closely, but it seems they have a moving window of 100 items with maybe 15 viewable at any one time. So maybe to keep the memory footprint down their playing some prefetching games. But without multi-threading or some form of asynchronous messaging, jerkiness can be expected with this kind of approach. This is a guess.
Just a warning, I noticed that when making changes to the css file, I had to open the conversation window and then close it, then open it again to see the changes I had made. So you may not be opening the window enough to actually trigger the changes.
EDIT: You're right, though, the change seems to be very subtle...
Just a warning, I noticed that when making changes to the css file, I had to open the conversation window and then close it, then open it again to see the changes I had made. So you may not be opening the window enough to actually trigger the changes.
It might be worse than that. I did a diff on two ps's and noticed no change. rtcomm-messaging-ui is always running, but it should be asking for new .js .css .html files everytime.
The only way to be sure is:
kill -9 <rtcomm-messaging-ui pid>
EDIT:
No change in behavior.
No, the only way to be sure is to kill -9 <rtcomm-messaging-ui pid> from space.
qwerty12
2010-03-24, 17:55
It might be worse than that. I did a diff on two ps's and noticed no change. rtcomm-messaging-ui is always running, but it should be asking for new .js .css .html files everytime.
.
FWIW, it's not rtcomm-messaging-ui that is rendering the webpage. That job belongs to browserd (grep for rtcomm - you should see a browserd process with "rtcomm" in its cmdline). You can also abuse browserd for use in your own program; build the stuff found here: https://garage.maemo.org/plugins/scmsvn/viewcvs.php/client-server/trunk/neteal/?root=browser and look through the header files. I have a shitty desktop widget that is doing this and it works, somewhat...
Ah, so this browser-neteal stuff is Maemo's gecko equivalent of WRT?
FWIW, it's not rtcomm-messaging-ui that is rendering the webpage. That job belongs to browserd (grep for rtcomm - you should see a browserd process with "rtcomm" in its cmdline). You can also abuse browserd for use in your own program; build the stuff found here: https://garage.maemo.org/plugins/scmsvn/viewcvs.php/client-server/trunk/neteal/?root=browser and look through the header files. I have a shitty desktop widget that is doing this and it works, somewhat...
You're right, I knew that. I was thinking last night of having my own server at that port number, but I scrapped that idea for hacking into microb. Ya know, behind enemy lines.
javispedro
2010-03-24, 18:21
Ah, so this browser-neteal stuff is Maemo's gecko equivalent of WRT?
Neteal is the "(browser) engine abstraction layer".
An interesting related development:
Mozilla stops Firefox development on Windows Phone 7. (http://blog.pavlov.net/2010/03/22/stopping-development-for-windows-mobile/)
Well, it was expected... Unless they want to rewrite it from scratch.
bxbomber
2010-03-31, 21:08
silly questions, with the new movement to webkit, any words if it'll support html5? I ask because with the launch of the ipad alot of websites are moving to html5. and what video format will it support? theora, h264?
and my last question, what are the odds that microb keeps being updated? it's got a spot in my heart and i'll miss it. lol
itpastorn
2010-04-02, 10:02
silly questions, with the new movement to webkit, any words if it'll support html5?
HTML5 is a big spec. No rendering engine supports it completely. In fact no engine is even close to supporting it.
Sometimes people say "HTML5" but also mean stuff like worker threads, postmessage, client side storage, SVG, etc. Once again no engine comes close to supporting all of these completely.
Sometimes people even include CSS 3 and ECMAScript 5th edition when they say HTML5. Once again no engine comes close to supporting all of these completely.
Firefox on Maemo/Meego supports "HTML5", regardless of which definition you use about equally well to Webkit and Presto. Some charts, based on Modernizr, are very Webkit biased. Other tests show an equal running. Other tests will put some other engine on top.
Some of Gecko's unknown "HTML5" strengths (talking about nightly builds now and widest possible definition of HTML5):
Gecko is closer than anyone else to have fully compliant HTML5 parser. Not sexy, not something the average user will even notice, but very important.
Gecko will skip SQL-storage (since that technique is being abandoned) and probably implement indexed storage first of all.
Tracemonkey (JavaScript) tracing is a very memory efficient technique, very suitable for mobile devices.
Spidermonkey is way ahead of everyone else in incorporating ECMAScript 5th edition. (Brendan Eich works for Mozilla, after all.)
Gecko supports SVG filters and clip-paths on non-SVG content. Really cool effects can be achieved this way.
Gecko is the first rendering engine to have hardware accelerated SVG.
I could make that list even longer, but I just wanted to prove that switching to Webkit might not be a superior solution, as some people seem to take for granted.
Webkit's main strength is that it is very easy to embed in C++ applications. It's thus a perfect fit for WRT.
As for H.264, it is said to see how little people value freedom. Large segments of the open web advocates gladly sell their ideals and believe the FUD, just because H.264 happen to be the choice of iFruit.
BTW, there is work in progress to get HW-acceleration for Theora as well.
vBulletin® v3.8.8, Copyright ©2000-2024, vBulletin Solutions, Inc.