Slashdot Mirror
Konqueror Ported To QT/Embedded
It appears that the Konqueror [?] browser has been ported to QT/Embedded. The entire Konqueror takes between 2.1 and 2.8 Megabytes. You can read more details (with some screenshots) on the porting site. Although it's not completed yet, from the screenshots it looks very promising - good work, Simon.
In fact, the "demo" version comes in x86 form as well as source and handheld binaries.
1st Law Of Networking: Loose ends are bad, termination is good.
WWJD? JWRTFM!!!
Hey - I did the same thing.
:)
Really nice to see KDE in Debian.
And really nice to have a working apt.
X is the protocol that X applications talk in order to get themselves displayed on your screen.
QT is a graphical toolkit used for producing GUIs. The UNIX version of QT talks X, allowing QT apps to display on your X server (There's also a Windows version of QT which talks to the Windows GUI rather than talking to the X server).
QT/Embedded is a version of QT optimised for embedded applications. IIRC, it's able to talk to the framebuffer device directly. This allows you to avoid having to run an X server or using all of the X libraries, reducing memory overhead considerably.
KDE is a desktop environment written using the QT libraries.
You don't have to design pages specifically for any browser. You design a page that is accessible, and it works anywhere. It's the whole point of the web.
Employee of Inrupt, Project Release Manager and Community Manager for Solid
Uhm - excuse me but ALL new designs that are power sensitive applications use CMOS design technologies today, not Bipolar Junction transistors(BJT's) (If you don't believe me - take a look at my profile ;-)
As for this embedded browser being to big, nope. I've recently been on a hunt for such things commercially, and 2.5Mb is within the nominal range of such products (between 1Mb and 3Mb) and this guy is touting ALL the features I was seeing people charge 1Million dollars for!
Have you compiled your kernel today??
I'd be cool to have a 'small Linux' distribution running on standard desktop PCs which used this kind of thing.
There are 'small' distros already but they tend to work by picking older and smaller versions of everything - kernel 1.0 etc. I'm thinking of something which is up-to-date but based on the 'lite' versions of software such as Qt/Embedded.
We're getting to the point where an old PC is pretty much equivalent - in screen space, processing power and memory - to a palmtop. So it seems sensible to backport things from palmtops to PCs.
-- Ed Avis ed@membled.com
The Web is an open system. You don't control the client. You don't control how much screen real estate you have. A professional, competent Web designer designs sites which flexibly and gracefully adapt to the amount of screen real estate the user chooses to give you.
I'm old enough to remember when discussions on Slashdot were well informed.
I've put a tarball of this compile on my MandrakeUser.Org site. Just unpack and run the 'konq' binary. It's pretty good, actually, although as basic as you can get.
tom, tom@mandrakeuser.org
--
--
"Just believe everything I tell you, and it will all be very, very simple."
Many of the comments here have discussed whether or not this would be a good option for a palmtop/PDA. But let's remember that "embedded" != PDA. What about internet kiosks, web pads, diskless workstations, super-subnotebooks (quite a few of these run WinCE), etc.? These sorts of embedded devices are often diskless, but with 16-32 megs of flash memory. Konqi (if its JavaScript + SSL support became more stable) and Gecko will quite probably dominate these increasingly important platforms, which means that system designers don't have to be bound to WinCE and pocket explorer.
-JRZ
Sure, not Qt/Embedded, but you can build this against Qt/X11. So, for all intents and purposes, this is a cut-down Konq without the KDE stuff!
iSKUNK!
You can compile Konq/Embedded to use with Qt/X11. I've seen screenshots of it over on dot.kde.org. So, it's really all the other guy hoped for and more
Supreme Lord High Commander of the Interstellar Task Force for the Eradication of Stupidity
I know it's flame bait - but I'll give you one product you may have heard of. Tivo is a linux based product.
;-)
Just takes one now doesn't it
Have you compiled your kernel today??
Can you give me a link to wherever you discovered that Palm uses BJT's? RTL logic has been obsolete for decades. If they are really using that stuff, they ought to be taken out and shot.
Also, how do you figure that the fourth pin on a MOSFET makes any difference? In every diagram I've seen, the base pin is always connected to the source pin, if it is even drawn. Usually, and especially in digital circuits, the base pin is omitted because there isn't anything useful you can do with it...
And why are you talking about flip-flops being designed with BJT's? It's either everything in the chip is made from BJT's or everything in the chip is made from MOSFET's, or everything is made using a newer, non-obsolete method (aren't MOSFET's obsolete for digital logic as well?).
For that matter, why are you talking about flip-flops in relation to SDRAM? RAM does not use flip-flops. Only registers do, and they typically use D flip-flops, not J/K.
Your post confuses me... it almost seems as if you took a bunch of words related to electronic circuits and threw them together randomly... Do explain.
------
Aaah yes, the old shared memory transport thing in X. It's not the panacea you make it out to be - far from being inefficient, unix domain sockets are actually not significantly slower than a shared memory transport in a modern PC system. In Linux at least, the unix domain socket code is some of the most heavily hand-optimized code there is - it just doesn't get any faster.
:p
As for an SHM transport never having been implemented in XFree86, no, it has, but the improvement in speed was so negligible that it is not compiled in by default.
Check out Precision Insight's paper on a shared-memory transport in XFree86 and please would everybody stop moaning about how crap XFree86 is - it isn't. BTW your alpha channels and font anti-aliasing are coming soon
But, back on topic, I find it very useful to design sites for a common-denominator, which is generally accepted as 640x480. I'm not worried about PDA browsers, and my sites look fine under larger resolutions.
You can't simply say that resolution doesn't matter. Any website that has more than just text, and flash-graphics is going to be designed for a resolution. Maybe it's designed for multiple resolution. Maybe it looks good on a couple different resolutions; maybe even a lot of them. But if it's got raster graphics, it's tied to resolutions. And that is by definition.
This is not to say that a good develop won't take this into account. But it's an act of futility to design a functional and aesthetic website that is completely resolution independent. I challenge you to show me a site you've created that will look equally well in a 320x240 screen *and* a 1600x1200 screen, without a fundamental change in how it appears.
If someone more in the know would like to answer that'd be great. The info I found was that K-Meleon is 2.6 megs, which puts it more or less on par with Konqueror. Unfortunately, it does take 10 megs of ram to run, and it requires Windows, so I'm not sure they can be fully compared. Either can be run embedded, as above posters have pointed out, because many systems are now coming with 16 or more megs, and it appears that Gecko and Konqueror are more or less comarable in terms of storage space required. Anybody with more info want to speak up?
"The question of whether a computer can think is no more interesting than that of whether a submarine can swim" -EWD
Slashdot in text mode. My own site. Any site which uses text, the proper method of literate communication. Pictures are for three-year-olds.
I agreed (more or less) with your post, until I found:
> Which X11 is doing very poorly (still relying on the good old OpenGL,
For a start, X11 have no dependency on OpenGL. Those are totally different beast. Nowadays, 3D acceleration is done via OpenGL extensions in the X11 server. Maybe you were specifcally talking about Direct3D when saying DirectX, but in that case, you are making a pure Direct3D vs OpenGL comparison, and X11 have nothing to do with that.
> which doesn't evolve much either)
Direct3D sucked badly for years. The 'evolutions' of Direct3D were desesperate tentatives to play catch-up with OpenGL. OpenGL have no real need to evolve, as it have a very open extension method ('ext') that enable developers to add features in hardware and release drivers with extended functionality. Such a functionality become standard only when proved usefull.
Direct3D is much more marketing-driven, with a lot of successsive releases containing hyped funtionality that are barely usable. From my experience, Direct3D is (it was 2 years ago, so maybe was is more appropriate) a pain to develop with.
OpenGL is much more mature. It does not _need_ to evolve.
Cheers,
--fred
1 reply beneath your current threshold.
Say what you will about today's web, but it's undeniably a commercial entity. And commerce is, and always will be, about presentation. If you think any major site, slashdot included, could get along without graphics, today, you're simply mistaken.
"Presentation" is so damn annoying that some of us install Junkbuster just to get away from it. Radio Shack might have a nice presentation, but they've neglected to make a searchable catalog.
On the other hand, Digikey's catalog page has little presentation, but their catalog is actually useful.
Commerce isn't about fluff. Commerce is about meeting a need that your customer has. Maybe retail stuff needs some fluff to get average Joe into the store, but in case you haven't heard B2B is where it's at. When IBM is buying 10 million resistors to put into a power supply, they will probably not go to Radio Shack.
If tits were wings it'd be flying around.
For a start, X11 have no dependency on OpenGL.
:)
When it comes to 3D rendering, it DOES RELY on OpenGL, since this is about the only serious 3D API that works under X11... until someone comes up with an extended X API with 3D functionnality, OpenGL is the only game in town.
Maybe you were specifcally talking about Direct3D when saying DirectX
Nope - although Direct3D is the "hotest" part of DirectX, DirectDraw is nice too (it's the 2D part, since we were talking about X11). I won't even go into the other DirectX API, which are out of the subject yet have no real equivalent under Unix.
OpenGL have no real need to evolve
Yes it does ! Every API that talks to hardware need to evolve sometimes - since hardware always add new functions and possibilities.
as it have a very open extension method ('ext') that enable developers to add features in hardware and release drivers with extended functionality. Such a functionality become standard only when proved usefull.
Which is why it doesn't evolve : since every 3D hardware manufacturer wants different extensions, there's not one that stands out and nothing change. At least with Direct3D, there's a clear direction that is shown, someone (MS) says what's right or not and drivers are written accordingly. OpenGL would already be dead if Quake III wasn't around. So yeah, people can moan and bitch about the choices Bill's minion do, but at least they somewhat listen between every iteration of DirectX and everyone has a chance to write a game that use the latest hardware capabilities (which are cool
Sorry to be really ignorant, but that sounds quite big in terms of embedded stuff? Isn't that's like half most Palm's memories? How does that compare, with say, the barebones of Gecko?
And to think I just recently commented on the trials of running Konqueror standalone, having to compile a good chunk of KDE and all those pesky kdeinit/kio processes that would start up and never go away.
That this will run as an (almost) self-contained binary under Qt/X11 is awesome. It greatly simplifies running Konqueror w/o KDE, and makes that a very attractive alternative to other monolithic browsers.
Given that this is targetted to embedded systems, I think the memory usage comparisons with NS4 will be rather interesting...
iSKUNK!
I'm posting this using Konqueror. After reading several stories in the past few weeks regarding Konqueror, I decided to give it a try:
I have to say, I'm quite impressed. It blows mozilla away in terms of speed (at least on my setup). Good job, Konqueror team!apt-get update
apt-get install konqueror
So, if QT is available for windows, and is meant for multiple-platform development will we be seeing a windows version? Something to finally compete with IE5.5+, other than free opera (no netscape and mozilla are not quite there yet). Many libraries (non-kde specific) are available for win platforms, so this should be a matter of how much code is kde/linux specifc. Anyone got any idea how much is?
Heh :)
/. community would be interested, then I post it..
:)
I'm already 2 years posting stories in slashdot..
I don't post as frequent as hemos or cmdrtco, but when I find a good story which I think that the
Nice to meet u
Hetz (Heunique)
I didn't say that X Window was bad though. The problem might not only rely on the transport either. One of the test was conducted on "on a 350MHz Pentium II with an ATI Rage 128 Pro card and 64MB of PC-100 SDRAM running Linux 2.3.42" with XFree86 prior to v3.9.18.
I think only 1 test on one machine is not too fair though (they only use that PII-350). I think if they try another machine too (eg: PII-266) and conduct the same test the result will be different.
Also, I wonder:
0) Besides that ATI Rage Pro, have they tested another graphic card on the Intel x86 platform? It seems they only tested 1 graphic card though. Also notice the comparison on SGI Irix X Server.
1) What about the CPU usage comparison when using shared memory transport and unix domain socket?
2) What processes & daemons are running on that machine besides the XFree server itself?
3) How efficient is their SMT algorithm? Have they tested if there's a bug in it that makes the performance only 10% faster? Is there an inefficiency in their SMT code?
4) Notice the SGI X Server test comment:The SMT run did not complete, so all operations are not represented in the aggregate results. Does it mean that the SMT code is maybe stil buggy?
5) Notice the section 3.3 from that document:
Shared memory is a precious system-wide resource. The XF86Config file should specify:
- minimum and maximum values for the amount of shared memory that may be used by each client, and
- a maximum value for the amount of shared memory that may be used by all clients.
When the shared memory limits are exceeded, a request for SMT should fall-back to a non-SMT connection.
What if the SMT limit was exceeded in that test? How efficient is the algorithm written (in that short time?) for the SMT? How come, for example: MS-Windows 2000, BeOS, QNX doesn't even need to fall back to the non-SMT connection? MS-Win2k doesn't use non-SMT connection at all, since it doesn't have a network transparency like X-Window
I'm not saying that the overall MS-Windows is better. For example, Win2k's kernel is bloated, but the graphic code was pretty good, plus companies support it by providing drivers for hardware acceleration.
For your information, I develop Linux apps too. I don't use MS-Windows for my workstation at all. X-Window is good, but it can be improved a lot.
Note: CSS is cool
I would like to respond to both you and the posters who responded to you.
I know a lot about HTML. It *was* meant to be a simple markup language. It wasn't meant for design. Well...developers demanded more control over presentation and that is what we have. tags and tables and nested tables. Now anyone worth their salt knows that using these techniques cruddify the language. But in order to maintain *some* control over the display of web pages, they were needed.
That time is over. Cascading Style Sheets is definitely the answer. Konqueror is supposed to have full CSS compliance. Embedded web browsing was one of the things that CSS was *designed* for. You just need a user style sheet that overrides the formatting in the web page. I don't know if Konqueror supports user style sheets, but you'd think it should.
Here is definitely a must-read article for those who doesn't understand the power of stylesheets. Changing the size of images to 20x20 pixels. Decreasing font sizes. Getting rid of banner ads. These are ways to make web sites more usable for users on embedded devices. If you are a more traditional HTML coder, than you may find your web site rather mangled, but usable, on these platforms. But if you design your site using the web standards that were designed so that the web could be universally accessed, then you *can* give your web site a distinctive look and feel that your users will always recognize, even as your user moves from device to device.
Your design *will* be overrided by someone's browser, there is nothing you can do about it. It is part of the universallness of the web. For people who need larger font-sizes and contrasting colors, they will probably have user style sheets also. If you *work* with the standards, you can still influence the presentation of the web site.
But fixed-size, paper-like web displays are a thing of the past. Computers are far more flexible than paper.
Shared memory transport for X11 has been around for over a decade. If you are running XFree86, you almost certainly have the MIT-SHM extension installed. It is widely used by programs that need high performance graphics.
Some vendors have additionally created server and Xlib implementations that use shared memory instead of sockets, although that never seemed to result in an interesting additional speedup. Eventually, I think people stopped bothering.
since in the beginning [X11] was not designed for fast graphic routine for personal computing, etc.
X11 was designed for implementing high-performance graphics workstation applications on what is fairly modest hardware by modern standards. That's why X11 is actually quite fast, efficient, and gives you a lot of low-level hooks.
However, X has advantage: although it's slower, it has network transparency so that you can run app over other computer via network. [...] Oh, by the way, the graphic display in MS-Windows is faster not only because of its driver is better + DirectX accel support, but also because it uses shared memory transport.
It's a myth that X11 is slower than the Win32 API. In fact, whenever I have compared the two, X11 wins hands down. The reason is probably that the Win32 API uses a lot more synchronous calls and forces more context switches.
In fact, in these days of accelerated graphics cards with their own processors, the X11 model is much closer to what is going on under the hood than the antiquated and inefficient Win32 "graphics library" model.
> At least with Direct3D, there's a clear direction that is shown, someone (MS) says what's right or not and drivers are written accordingly
:)
Having followed the Direct3D vs OpenGL controversy very closely three years ago, this is the precise point where the philosophical difference is.
M$ is (or at least was) about clueless when design new features for Direct3D (For instance, in the first versions of Direct3D, they specified what the vertex format was, and that definition sucked fantastically). M$ have a vested interest in what features are or are not avalaible in Direct3D releases (hey, they will sell X-Box hardware), so reliying on them to make specs, is amusing, to say the least.
> and everyone has a chance to write a game that use the latest hardware capabilities (which are cool
Unless you needed Stencil buffers in Direct3D 6, of instance. Lastly, Direct3D uses a fundamentally broken Capability interface that basically prevent usefull software fallback...
Cheers,
--fred
1 reply beneath your current threshold.
WebTV and Pocket Explorer for Windows CE do a pretty nice job at this ... scaling images and everything so that normal webpages look decent, without having to do a special site design specifically for them.
From the screenshots, the embedded Koqueror didn't appear to do any of this. It looks like you have to scroll quite a bit.
*shrug*
As a web developer, I'm constantly developing for the lowest common denominator, despite what may or may not make the site look ultra-cool. This typically means 640x480, and that's a pretty good size for a minimum size. You don't worry about smaller screens like those found on handhelds, because they generally have their own web translation tools, and sometimes even their own specific web sites (see Avantgo channels).
But now, what happens when someone embeds a full web browser into a PDA app? All the sudden, your lowest common denominator drops and you're screwed. Did you see the size of those screenshots?!
Personally, I think it's "cool" kind of like it's "cool" that someone flew around the world in a balloon, but I think it completely destroys the idea of a PDA when try to cram everything from something larger inside of it. But that's an opinion thing. I don't think I'll be looking forward to developing web pages for tiny screens.
Seeing the Konqueror/Embedded screenshots makes me think of Microsoft's Pocket PC ads. A 20-something model holds a PDA at arm's length (which is telling, because whenever I see someone with a Palm, he's engrossed in actually using it), boasting that he can read MS Office attachments. Then again, the company president routinely sends email with a one-line memo as a Word attachment, so maybe there is a market for this kind of feature.
As to developing web pages for these microbrowsers, I have two comments. You shouldn't develop your pages with any resolution in mind. On the other hand, the PDA user should pass on images. I recently posted a classified ad with a picture that the site scales to 200 x 150. It looks like a postage stamp on a normal monitor, but it would pretty much fill a PDA screen.
All right, flamebait, I'll bite, cause you're going into the world that is a little pet peeve of mine.
Any type of graphic presentation is dependent on the size of it's medium, be it print, film, or digital. Just because web pages are done in HTML does not mean that you have to ignore this fact.
If I take your example, Slashdot, and narrow my window, Slashdot induces horizontal scrollbars at around 690 pixels. That means, that if my monitor resolution is 640x480, I can't read from left to right continuously without scrolling. Of course, it's a rare resolution that can read Slashdot without vertical scrolling, but humans are accustomed to scrolling down a page (at least in most societies), so that's not a major issue, horizontal scrolling is.
Now, take your window frame. As a graphic display medium (which is what a web page is, regardless of what language it's written in), you want the parts of the page that are important to your design (whether that be blank space for the artsy fartsy types or the company sales droning for the business types) to be in the initial window, no scrolling. You have to know your resolutions to do this. If I'm operating within a 640x480 paradigm, I want that main content to be within that window. Yes, if I grow my window, I still want my web page to keep its purpose and flow, BUT, I still operate within that 640x480 area. When you have a PDA, that suddenly drops your area from 640x480 to something smaller than 320x240 (depends). Do you know how hard it is to get any kind of message across in that space? It's not impossible, it's just more challenging.
Yes, HTML is a markup language, but it has nothing to do with design. HTML is just the implentation. I know exactly what HTML is. I also know exactly what Flash is, and exactly what XML is, and exactly what plain text is, and all can be used to prepare a web site, but they're just languages used to implement a design, not the design itself, and what I'm talking about are confines on design.
Graphic material is always developed for a "screen size". With web pages, that screen size is variable, but you still have a minimum point at which you say, "Welp, they'll have to turn the page to see the rest of this content." And with PDAs, that minimum point is much lower.
I suspect that your whole post is simply flamebait (and if I could moderate it as so, I would), simply because you sound like you know nothing about design in general and web design in particular, but in the off-chance that you do know something, you are sorely lacking in that knowledge.
Nah, you *could* do it that way, but that would be silly
Qt/Embedded and Qt/X11 have the same API, so anything that compiles against one should compile against the other, with no kdelibs involved...
Plus somebody else already did that. Check the other posts for somebody talking about Mandrake 7.2.
Supreme Lord High Commander of the Interstellar Task Force for the Eradication of Stupidity
why can't they make it that small on normal machines? it takes up nearly all my RAM under normal linux
It's also because of X. First of all, X Window's screen is typically large: from 640x480, 800x600, and 1024x768 with 16bit per pixel.
For example, calculate this: for 1 pixel for PutImage routine, it requires 1024 x 768 x 2 byte, so that is quite large. For 24 bpp, multiply that with 4 byte. The screen in that handheld is definitely much smaller than X-Window's screen size.
Also, X Window is not efficient the way it uses intra-process communication. For localhost display (which is the one in that handheld), X-Window still uses unix domain socket, which requires another memory segment for its routine for TCP/IP stuff and whatnot. If you don't trust me, try tcpdump -i lo and you can watch traffic on your loopback device even when you run the simplest application like xclock, xcpuinfo, kedit, gedit, gnome-terminal, etc.
The thing that most people don't really care/realize is that X-Window can actually be improved to be more efficient by using shared memory transport so that it's faster and more efficient. It is much faster than using the inefficient unix domain socket, and also when there is a very very heavy load, using socket vs using shared memory can be compared like tricycle vs Porsche. The shared memory transport under X-Window has never been implemented, since in the beginning it was not designed for fast graphic routine for personal computing, etc. However, X has advantage: although it's slower, it has network transparency so that you can run app over other computer via network.
That Qt/Embedded for the handheld does not use X-Window at all. That's one of the factor why it's small and fast. Oh, by the way, the graphic display in MS-Windows is faster not only because of its driver is better + DirectX accel support, but also because it uses shared memory transport.
I hope this helps.
Here's a clue: resize /.'s window - what do you notice?
I notice that at 640x480, that row of section category icons at the top of each page causes both Mozilla and IE5 to require a horizontal scrollbar to render the page correctly.
You see, while Slashdot avoids all the fixed table size travesties which make half the web look like a thin column (subtly phallic - does it imply that the web developer was a dick?) of text at my preferred high browsing resolution, it does succumb to the temptation of those fancy "graphics" which are all the rage among the kiddies.
And even though this example could be coded around (it wouldn't be hard to make those icons wrap when the available space is too small), there are others that won't. I had a graphical button bar on the top of an old website of mine, for instance, and while it only took a little work to make it happy with 640x480, trying to view it on a palm pilot (except with a text-only browser) would be disasterous.
The future solution is not to code "The One True HTML Subset", by the way. If you do that, then you avoid having 5% of users think your page sucks, at the expense of the 95% who now think it's mediocre. The ideal solution is to provide a second stylesheet to control the layout of your pages for the smallest web browsers. Of course, this requires you to get the content/presentation separation right from the beginning, so it won't be the popular near future solution...
The reason that Palm OS dominates the handheld market is that it uses a very simple, minimalist interface which lends itself quite well to a tiny screen. When you are using a handheld, you want your GUI to: 1) minimize screen real estate to save it for useful information 2) minimize taps/clicks required to perform a function 3) take up as little memory as possible, since handhelds generally don't have much due to power constraints. 4) take up as little CPU as possible, because of power constraints. While KDE, or some of its components, may be a good choice for some people on a desktop system, it really is probably not a good choice for a handheld, because it wasn't designed with the constraints mentioned above in mind. As an example, look at the old Windows CE interface, which attempted to stick a Windows 95 style paradigm on a tiny screen. It was difficult to use on a handheld, and the CE devices sold poorly. As soon as MS learned to simplify its interface, CE started to jump in market share. Linux handhelds need to learn this lesson, not repeat Microsoft's mistakes.