![]() |
Re: Tear 0.3 - Simple WebKit browser, now with Dashboard
Quote:
|
Re: Tear 0.3 - Simple WebKit browser, now with Dashboard
looked like the hammer and sickle in the upper right corner to me...wouldnt even display most of the text.
|
Re: Tear 0.3 - Simple WebKit browser, now with Dashboard
Quote:
|
Re: Tear 0.3 - Simple WebKit browser, now with Dashboard
http://repository.maemo.org/extras-d...free/w/webkit/ ;)
An old revision now though, I wouldn't use it to install the lib from - rather just if you want to upload something "webkitty" to extras. |
Re: Tear 0.3 - Simple WebKit browser, now with Dashboard
Quote:
|
Re: Tear 0.3 - Simple WebKit browser, now with Dashboard
heh, when i first read that, i thought about surgeons forgetting clamps or scalpels in their patients...
|
Re: Tear 0.3 - Simple WebKit browser, now with Dashboard
Hi there,
I just have two (simple) things to say : - first is : THANK YOU. Since I installed Tear I'm starting using back again my N800. MicroB was so sloooow I just dropped my N800 and abandonned it. Right now I feel surfing the web on my device is really possible. - second is : how can I make Tear the default browser ? This question must have been answered previously but I haven't found out the anwser. Any help ? Keep up the good work ! |
Re: Tear 0.3 - Simple WebKit browser, now with Dashboard
In some pages with frames, Tear shows a download box and asks to download the page, rather than opening it. When I point the browser to the frames individually, it has no problem rendering them.
Is this a bug of some sorts or am I doing something wrong? |
Re: Tear 0.3 - Simple WebKit browser, now with Dashboard
@Cowboydan: You can partially make it default using the Task Navigator plugin mentioned earlier and Dbus-switchboard.
@kornish: Its a bug with some post requests, yes. |
Re: Tear 0.3 - Simple WebKit browser, now with Dashboard
|
Re: Tear 0.3 - Simple WebKit browser, now with Dashboard
Now as is well known, Tear has major problems with black themes such as the wonderful LCARS themes: Input fields using native GTK+ appearance end up having black type on black background, and are as such unusable.
Now, one approach to solving this is to use user CSS to restyle <input> and other tags to be readable again, but that means losing the integration factor. At least, unless putting in a little more effort. Is anyone interested in creating a user stylesheet that essentially recreates the LCARS themes' GTK+ widgets in Tear on a CSS basis (just without the font color problem)? Using attributes like --webkit-border-radius and the recently-added ability to style scrollbars in a pretty sophisticated manner should make this possible. |
Re: Tear 0.3 - Simple WebKit browser, now with Dashboard
Quote:
|
Re: Tear 0.3 - Simple WebKit browser, now with Dashboard
Quote:
|
Re: Tear 0.3 - Simple WebKit browser, now with Dashboard
Quote:
I would advise against using border-radius, it is very slow. |
Re: Tear 0.3 - Simple WebKit browser, now with Dashboard
Quote:
tear = 0.3-6 -webkit-border-radius = disabled Time to uninstall/re-install? |
Re: Tear 0.3 - Simple WebKit browser, now with Dashboard
Hmm, do any bookmarklets work? I tried using the one from Evernote by copying and pasting it into the url box (after highlighting some text) and it just gets stuck trying to load. In Microb this will start the Evernote clipping dialog and add it to my Evernote account
|
Re: Tear 0.3 - Simple WebKit browser, now with Dashboard
Quote:
Quote:
|
Re: Tear 0.3 - Simple WebKit browser, now with Dashboard
Quote:
if hostname.css exists use hostname.css else if domain.css exists use domain.css else use default.css Then fall in love with your tablet all over again. |
Re: Tear 0.3 - Simple WebKit browser, now with Dashboard
About the bug to which kornish was referring , when I try to attach an image to a post on ITT when I click upload after selecting a file a download dialog pops up and wont let me upload anything. Is this the same bug?
|
Re: Tear 0.3 - Simple WebKit browser, now with Dashboard
Probably..
|
Re: Tear 0.3 - Simple WebKit browser, now with Dashboard
Quote:
I thought that alluded to the black-on-black problem when using a dark theme like LCARS. I mean, MicroB essentially uses a "browser-only theme change" too, by virtue of Gecko using its own input field rendering rather than GTK+. This is also why my above post came out a bit annoyed - "filed for weeks, no movement on it" ;). Edit: Bug filed: http://bugs.bundyo.org/viewissue.php?issue_no=29 |
Re: Tear 0.3 - Simple WebKit browser, now with Dashboard
The previous bug was about dark to light controls, but I wasn't aware of any invisible text.
By the way I'm facing similar problem on the Desktop - I'm using black theme on my openSUSE and my controls in the browser are dark gray with black text. This is due to the browser using specified colors by default. You can switch system colors but it gets worse - many sites are setting the background and not the color of the text and it becomes light gray or white on white... So I suspect your problem is due to the same feature/setting. |
Re: Tear 0.3 - Simple WebKit browser, now with Dashboard
Not sure. Browsers like Firefox have a default font color setting that is used if the website doesn't specify a color. I assume WebKit has a similar default color setting, and I'd like it to be initialized to the system default text color at least for input fields. Basically, if it uses system native widgets to render an unstyled input field, it should also use the system native font color that goes along with it. Makes sense, no? If a site actually applies any formatting to the input field, it can divert from the system default at that point. This is also a smarter approach than using user CSS, which would always override the site author's formatting.
|
Re: Tear 0.3 - Simple WebKit browser, now with Dashboard
Getting trigger-happy, I suppose, I also filed two other bugs:
Issue #30 - Ctrl+C to copy and Ctrl+V to paste don't work in the address bar Issue #31 - Add an option to auto-select address bar contents on widget activation |
Re: Tear 0.3 - Simple WebKit browser, now with Dashboard
@Sho - The first is a duplicate, the second is very hard :) GTKEntry auto-select on focus was ripped off in Maemo, sorry. Also the focus events don't fire on it :( I lost several days to that. There probably is a way, but I don't know it yet so I suspended it for now. Good to have a bug report though :)
About the colors - yes, I think I wrote just that above, though you missed something - when you turn on the system colors, the rest of the site breaks, not the input boxes. :) |
Re: Tear 0.3 - Simple WebKit browser, now with Dashboard
Oops, sorry about the dupe. I used "Find on page" to scan the list for "copy" and "ctrl", but forgot "paste", or I would have found it.
Regarding the auto-select: If MicroB can do it, you should be able to, too, right? Strange that the widget doesn't get a QFocusEvent of type QEvent::FocusIn that you can simply hook QLineEdit::selectAll() up to in an event handler, though, to translate into the jargon used by my QBrain. :D |
Re: Tear 0.3 - Simple WebKit browser, now with Dashboard
Let me be more specific:
Here's the Firefox 3 Colors dialog: http://bundyo.org/maemo/screenshot1.png Here's what the Google News looks like with system colors enabled: http://bundyo.org/maemo/screenshot2.png And that's a big player. My line is this: the problem is in the web sites, not in the browsers. If you set all your colors, your site will be readable despite any settings. |
Re: Tear 0.3 - Simple WebKit browser, now with Dashboard
I can check MicroB's sources to check how they do it. Didn't notice that it was possible there, I seldom write in the URL bar :)
|
Re: Tear 0.3 - Simple WebKit browser, now with Dashboard
Quote:
I did understand your point that using the system theme colors outright as default background and font colors would break many pages; I'm familiar with the problem, actually. Site authors frequently set a text color but forget to set a background color, so a browser inheriting a black window background color from the system for its document viewport corrupts site layout. I get it. However, this is a more limited problem. It's about input fields. Somewhere in WebKit(GTK) is code that checks whether an input field is styled or unstyled, and then either uses custom drawing or goes to the system widgets. E.g. if I set "border:1px solid black" on an <input>, WebKit will draw a simple 1px border rectangle instead of a GTK+ widget. In the Google case I cite in the bug report, the website sets up black as default text color in <body>, but applies no other formatting to <input> tags. So WebKit(GTK) probably decides that this is an amount/a type of formatting that can be handled by the system widget and spawns one, asking it to render text in black. I believe that this decision right there is broken, because the widget's *background color* isn't taken from the site (because, well, there usually isn't one set by the author) while the *font color* is, which causes problems like this. So I ask that it ignores the site's formatting and goes for the system default input field font color in all rendering cases that can satisfied by the system widget. This basically won't really break any pages, because any page that cares to set an unusual (i.e. other than black) font color on <input> will usually also change its background and border properties to a degree causing the GTK+ widget not to be used anyway. As a KDE developer, I'm more familiar with the KHTML code than with WebKit's, and I expect this is one of the areas where the WebKit codebase diverges the most from KHTML, as KHTML simply directly goes for Qt widgets whereas WebKit has a platform/backend abstraction mechanism. But if the WebKit authors have at all managed to preserve the cleanness and simplicity of the KHTML codebase, the above behavioral change should be fairly simple to pull off. |
Re: Tear 0.3 - Simple WebKit browser, now with Dashboard
Yes, probably won't be so hard. I'll check it at some point.
|
Re: Tear 0.3 - Simple WebKit browser, now with Dashboard
Thanks :).
Of course the "browser-only theme change" approach from Issue #2 would sort of fix my problem, too, since if the browser used one of the Maemo GTK+ themes with a white input field background, the black-on-black thing goes away. This would also still be more elegant than the user CSS workaround which conflicts with site stylesheets that do apply their own formatting to a degree that causes the GTK+ widget not to be used (e.g. if I force text color for <input> to white via user CSS and then a site comes along that gives their input fields a pink border and a mostly white background image with pink polka dots ;)). That said, loading up another theme to use in the browser is probably more resource-intensive than changing the behavior as suggested above ... MicroB only get this for "free" because it uses/activates Gecko's old pre-GTK-integration codepath where Gecko gets to draw its very own simple Windows 95-like input field widgets, I guess. The other downside of using a different theme is losing the extra integration provided by using system widgets when possible in the first place, but then the LCARS widgets don't really fit into most websites visually. As in, they're not very neutral-looking. |
Re: Tear 0.3 - Simple WebKit browser, now with Dashboard
Im having a problem on a particular site, when I press the back button it doesnt go back but seems to reload the page. Any ideas?
|
Re: Tear 0.3 - Simple WebKit browser, now with Dashboard
Probably Ajax and injects history?
|
Re: Tear 0.3 - Simple WebKit browser, now with Dashboard
Its a singles site, plentyoffish.com try viewing a users profile and try to hit the back button and see if you think thats what it is when you get a chance.
|
Re: Tear 0.3 - Simple WebKit browser, now with Dashboard
Quote:
Exactly the same symptoms under the same conditions that Tso reported here: http://www.internettablettalk.com/fo...&postcount=819 (i.e, very slow on un-cached load of page with images; better on re-load) |
Re: Tear 0.3 - Simple WebKit browser, now with Dashboard
Quote:
Solutions: In tear, either:
Regardless, the best you can do for now is try to hit the back button twice, really quick. This is a change that needs to be made in tear, I'll file a bug. |
Re: Tear 0.3 - Simple WebKit browser, now with Dashboard
another duplicate then. i filed a enhancement request for tap-n-hold on back/forward a while back...
|
Re: Tear 0.3 - Simple WebKit browser, now with Dashboard
Woops. Sorry about that! It's closed, so in the next version, I assume. Removing link, Bundyo, can you remove the bug?
|
Re: Tear 0.3 - Simple WebKit browser, now with Dashboard
Yeah, tap_and_hold history is implemented. :)
|
Re: Tear 0.3 - Simple WebKit browser, now with Dashboard
Oh my gawd! I just discovered this today, installed it on my N800, and I am blown away! Hasn't crashed yet, is stable and fast, and improves on MicroB in so many ways that it brings tears to my eyes! I love the ability to turn off js, images and flash - this is a must for mobile browsing. I can use the backspace button on the virtual keyboard without it closing. Kinetic scrolling! Awesome bar type search! Dashboard! Even you tube plays smoother! Thank you for essentially giving me a whole new internet tablet!
|
| All times are GMT. The time now is 20:34. |
vBulletin® Version 3.8.8