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.

11 of 83 comments (clear)

  1. Re:Explain please... by Fluffy+the+Cat · · Score: 3

    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.

  2. Re:Not about PDAs! by Ed+Avis · · Score: 3

    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
  3. Re:Oh Boy ... by Simon+Brooke · · Score: 3
    If you develop web pages for fixed sizes you are by definition an amateur. The Web was designed ab initio to be resolution independent, and this neither the only nor the smallest handheld Web browser. Remember, the people browsing the Web on small devices are the wealthy, technically switched-on members of society - the people who commission and pay for Web sites are likely to be among them. Do you want them to see what your 640x480 fixed size site looks like on their handheld screen? Do you want them to see what your 640x480 fixed size site looks like on their 1200x1000 pixel screen (or, next year, on their 3000x2000 pixel screen) on their desktop?

    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.
  4. Precompiled Version For Mandrake 7.2 Available by belbo · · Score: 5
    Since I'm always looking for smaller browsers, I've compiled this little thingy (took some 50 minutes, though) as a static version with SSL support on LM 7.2.

    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."

  5. Not about PDAs! by JohnZed · · Score: 5

    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

  6. Isn't that quite big? by SmileyBen · · Score: 3

    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?

  7. On the desktop w/o KDE by Straker+Skunk · · Score: 3

    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!
  8. Note: CSS is cool (was *sigh*) by extrasolar · · Score: 3

    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.

  9. X11 has shared memory and all the other features by q000921 · · Score: 5
    The shared memory transport under X-Window has never been implemented,

    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.

  10. Consider the screen size, too... by bradfitz · · Score: 3
    The challenge for making an embedded web browser isn't in porting the code, it's in laying out the page such that you don't have to scroll so far in both directions.

    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*

  11. Oh Boy ... by Hrunting · · Score: 3

    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.