Konqueror Ported To QT/Embedded 83
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.
Re:Oh Boy ... (Score:1)
And really, with the way the web looks today, this would just look like complete and total CRAP on a PDA. Buy a damn laptop with wireless crap, or just wait until you get home to a full PC or appliance...
disclaimer: my mind really started to wander on this one (4-month old spitting up all over mom) - so hopefully its not too incoherent.
Re:Anyone knows if.. (Score:2)
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.
Re:Is this really a good idea on a handheld device (Score:1)
Thanks
Re:Slightly offtopic, I know ... (Score:2)
Really nice to see KDE in Debian.
And really nice to have a working apt.
Re:Explain please... (Score:3)
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.
Re:*sigh* - try your own advice (Score:1)
I did resize slashdot, down to the size of these screenshots. The resulting page was twice the horizontal size of my browser window.
This is a valid point being raised here, even on those screenshots, you could only see a fragment of the webpage that was loaded into it
Yes, HTML is a markup language, and does not lend itself to the ideas of most graphic designers that think they understand the web, but it is challening to fit content and navigation elements into a document and make it look good in any browser.
And don't tell me that it doesn't matter how it looks. The reality of web design is that your customers want it to look good, and when they go and visit their friend who has IE3 and 640 x 480 resolution with 256 colours to show off their site, and the site looks like crap, they are going to come back to you asking why.
I personaly like the original concept of the web, and I would like to create websites that are functional, not too flashy, and render well in any browser because they don't try and do anything unatural, but I have to make a living, and my customers want their site to look like www.whatever.com that was designed by some new york web design company that thinks HTML is what u generate with a Flash export.
The fact that full blown browsers may appear on a PDA is scary, cause if that gets in the hands of one of my customers, they will want their site to look awesome on it, as well as on the 20" monitor they have at their office. And they don't want to make design compromises to account for that.
Konqueror running on a PDA is cool as long as it stays fringe, otherwise its going to be a big shit for web designersRe:Slightly offtopic, I know ... (Score:1)
Reading Package Lists... Done
Building Dependency Tree... Done
The following extra packages will be installed:
kdebase-libs kdelibs3 libkonq3
The following NEW packages will be installed:
kdebase-libs kdelibs3 konqueror libkonq3
0 packages upgraded, 4 newly installed, 0 to remove and 0 not upgraded.
Need to get 8965kB of archives. After unpacking 30.7MB will be used.
Do you want to continue? [Y/n] n
Abort.
Yea that looks realllll nice especially with all of my 200mb of free space
on my big ass 2gb hd.
Re:Slightly offtopic, I know ... (Score:1)
deb http://kde.tdyc.com potato main optional crypto qt1apps
Re:*sigh* (Score:1)
HTML is markup, if you want absolute positioning, use PDF and spawn a plugin, as some sites do.
Re:Consider the screen size, too... (Score:2)
Re:*sigh* (Score:1)
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."
Being 'new' to web site building, I got interested in what approach to take to deal with this problem of different screen sizes. I seldom see a web site that fits my viewport just right.
So it occurs to me that the notion of a 'page' is just not valid. We have the 'url', and we have a 'variable viewport'. But there are no pages. The viewport destroys that.
In a CAD system you draw using real coordinates (like mm) -- it's only when you plot onto paper that you need to set a scale, to handle the limitations of the real page. The problem you describe with the pda being even smaller is just symptomatic of the problem. Just wait until you have to cope with users on 200dpi 21" screens.
In viewports we just don't have anything resembling 'pages', other than what site designers try to force with their habits aquired from printed media. Try taking a full length snapshot of the contents of a /. 'page', and what you get resembles more a toilet roll* than any 'golden ratio'd' proportions.
I think we can just drop the page metaphor and design the structures and mechanisms for adapting content to the viewport. At present very little information is available about the browser and the preferences of the user.
It would be nice to let the user set their preferences to "never scroll horizontally" or "reduce color depth of graphics" or stuff like that. We shouldn't have to turn PDA's into friggin desktop machines in order to access the train times info from a web site via a pocket gizmo.
Perhaps site builders design thinking is still stuck working on old print media problems of "balances of abstract 'Mondrian'ist elements positioned in the pure space of pages", while the web is going beyond all that onto more interesting design problems of "information survivability in an ecology of graphical rendering architectures" or whatever (insert favourite poncy designer blurb here).
The philosophy was present since HTML1, but some designers keep trying to fight against it, rather than designing ways to help and enhance it.
* Before it's used... although some first posts...
Re:Big is relative... (Score:2)
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!
Um, what the hell? (Score:1)
Re:Not about PDAs! (Score:3)
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.
Re:Oh Boy ... (Score:3)
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.
Re:Is it a good browser? (Score:1)
Re:Is it a good browser? (Score:1)
Re: (Score:1)
Precompiled Version For Mandrake 7.2 Available (Score:5)
I've put a tarball of this compile [mandrakeuser.org] 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
--
Not about PDAs! (Score:5)
-JRZ
This doesn't run under X (Score:1)
A cut down Konq without the KDE stuff would be very nice tho.
Who is HeUnique? (Score:1)
On a similar note, how does one go about getting onto the staff, anyways? I'm envisioning some sorta drunk frat prank. I can see CmdrTaco with the paddle, Hemos with the goldfish-filled condom, and RobLimo conducting the elephant walk!
Actually... (Score:2)
Re:This doesn't run under X (Score:2)
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
Re:Slightly offtopic, I know ... (Score:1)
KDE is currently only in "unstable"; you'd need to add a line similar to
deb http://http.us.debian.org/debian/ unstable main non-free contrib
in your sources.list to make KDE available.
Re:w0w (Score:2)
Just takes one now doesn't it
Re:Precompiled Version For Mandrake 7.2 Available (Score:2)
Thanks for the effort
I'm sure that the non-KDE crowd would very much appreciate your efforts were you to bring a fully-functional web browerser(statically linked, of course) to their desktops
Personally, I use Konqueror under GNOME, but it's a wee bit bloated/slow to respond for my tastes. I imagine a large part of that is the way it was compiled
Dave
Barclay family motto:
Aut agere aut mori.
(Either action or death.)
Re:Big is relative... (Score:2)
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.
------
Static? (Score:1)
linux01 ~/tmp/kde ->ldd konq
libssl.so.0 => not found
libcrypto.so.0 => not found
libqt.so.2 => not found
libjpeg.so.62 =>
libXext.so.6 =>
libX11.so.6 =>
libSM.so.6 =>
libICE.so.6 =>
libstdc++-libc6.1-2.so.3 => not found
libm.so.6 =>
libc.so.6 =>
Re:Isn't that quite big? (Score:1)
- since the Cassiopeia also takes type II cards, you can else well mention the 1 gb Microdrive (well enough to install Windows 2000 and IE 5.5, talk about embedded browser
Re:Because of X Window and KDE (Score:2)
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 [precisioninsight.com] 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
Re:X11 has shared memory and all the other feature (Score:1)
LOL. Good one ! Now lets program the graphic chipset thru X11, and order a bunch of hardware bitblt with a few binary operations. Mix it with a bunch of multiplane hardware scrolling. Isn't that low-level graphic programming ? You can do it with Windows...
It's a myth that X11 is slower than the Win32 API. In fact, whenever I have compared the two, X11 wins hands down.
LOL (again). Please provide benchmarks or even a way to witness such amazing behavior.
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.
First X11 is (way way) older than Win32 (so much for the "antiquated" adjective, at least as far as history is concerned).
Secondly, I find it extremely suprising that all graphic processors, being all designed and optimised for Windows (up to putting in hardware the function handling the shadow of the mouse cursor that appears in Windows 2000), with drivers specifically optimised for Windows by big teams of programmers with excellent documentation (and direct access to the hardware engineers who made the beast) could be better managed by X11.
So please stop the FUD. X11 is slower than Win32, and infinitely slower than DirectX (which speaks the graphic processors language). X11 has its good points - but it is definitely not the best graphic API in the world... (and not only bested by Win32, but also BeOS, MacOS X, etc.). And there's a reason the DirectX API is regularly updated : it follows the evolution of graphic hardware. Which X11 is doing very poorly (still relying on the good old OpenGL, which doesn't evolve much either)
Re:Oh Boy ... (Score:2)
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.
Excellent question (Score:2)
Re:Not about PDAs! (Score:1)
to be bound to WinCE and pocket explorer.
Gosh! "Pocket explorer" sounds just great.
It must be a great tool for thieves!
Re:Oh Boy ... (Score:2)
Slashdot in text mode. My own site. Any site which uses text, the proper method of literate communication. Pictures are for three-year-olds.
Re:X11 has shared memory and all the other feature (Score:2)
> 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
Re:Oh Boy ... (Score:2)
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.
Re:Oh Boy ... (Score:2)
On the other hand, Digikey's catalog page [digikey.com] has little presentation, but their catalog [digikey.com] 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.
Re:X11 has shared memory and all the other feature (Score:2)
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
Isn't that quite big? (Score:3)
More stuff on dot.kde.org (Score:1)
Re:Isn't that quite big? (Score:2)
Explain please... (Score:1)
Can somebody explain what it means really; what is the deal with QT or QT/Embedded vs X vs KDE?
Thanks in advance.
Size matters (Score:1)
Re:Isn't that quite big? (Score:1)
On the desktop w/o KDE (Score:3)
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...
My understanding (Score:1)
2.8 megs? (Score:1)
Slightly offtopic, I know ... (Score:2)
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
qt for win too? (Score:2)
Re:Who is HeUnique? (Score:2)
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
Anyone knows if.. (Score:1)
love to use that instead of xfree. I never use
the features of xwindows that make it slow
(client/server) so i wouldnt mind using qt
embedded and missing using x from another
terminal.
Any one knows?
Re:Slightly offtopic, I know ... (Score:1)
Re:qt for win too? (Score:1)
Re:Because of X Window and KDE (Score:1)
Re:Because of X Window and KDE (Score:2)
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 (was *sigh*) (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 [oreillynet.com] 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.
X11 has shared memory and all the other features (Score:5)
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.
Re:Because of X Window and KDE (Score:1)
Re:Oh Boy ... (Score:1)
Two words: Fluff sells.
Hey, I didn't say I _liked_ it..
Your Working Boy,
Re:qt for win too? (Score:1)
Not for developers but AFAIK there's no fee attached to the runtime so if some licence holder compiles konqi/embedded with qtwin he's free to put the resulting binary out as freeware.
Re:Is it a good browser? (Score:1)
Re:More stuff on dot.kde.org (Score:1)
--------
Re:Isn't that quite big? (Score:2)
Re:*sigh* (Score:1)
Yeah, you "know exactly what HTML is". Sigh. You are just another web designer stuck in his visual world of flash and ignorance.
/mill
Realize XFree86 shortcoming (Score:1)
We, Linux people have to realize that XFree86 still has a lot of shortcoming, and if we say that XFree86 is already good, why would companies such as Metro-X and XiGraphics make commercial X servers which are much faster than XFree? Don't be stubborn. The MIT-SMT code is not optimized AT ALL and still needs a lot of work, and it's not faster AT ALL compared to Win32 graphic
Re:Not about PDAs! (Score:1)
Re:X11 has shared memory and all the other feature (Score:2)
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
Consider the screen size, too... (Score:3)
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*
Oh Boy ... (Score:3)
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.
Re:Oh Boy ... (Score:1)
--- well, fact is that in the developing world chances are that the Internet will be more often accessed with wireless devices [pda, cellphone, etc.] than with a regular PC by 2002.
There are several reasons for this:
-1- Cellphones are much more common in Southeast Asia than landlines.
-2- Many non-urban areas are not likely to get landlines anytime soon [and those that do, have to often live with congestions, polluted lines and frequent interruptions.
-3- Buying one cellphone is cheaper than buying a PC [well in Asia it is way cheaper].
-4- With the introduction of G3 in the region, towards the middle of next year, connection speeds are expected to average at 200kps - which obviously beats the 48kps you can get out of a 56 dial-up modem on a good day.
I certainly agree that it's a PITA ['pain in the ass'] for us poor developers who have to allow for two main types of display and two main types of browsers when developing web sites and applications, but the easiest way to allow for small [tiny] displays would be to simply script a 'device detect' into the of the homepage. From there you send visitors with small displays into a W@P subroutine. Meaning, they get their own pages, rather than finding the lowest common denominator. Which makes even more sense if you consider that XML/WML is likely to be the standard for webpages in the not too distant future. So, conventional visitors get the full XML site, while wireless get a slimmer WML version.
"Get a life - Torch AOL!"
Can your Palm do that? (Score:2)
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.
Re:*sigh* (Score:1)
Any images depend on the minimum screen size. To state an obvious one, a 500x15 "rule" won't work very well on a 320x240 screen. You have to draw the line somewhere, otherwise you have to start catering to folks with 48x24 pixel screens.
Re:*sigh* (Score:2)
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.
Re:My understanding (Score:2)
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
Is it a good browser? (Score:1)
But the speed at which they got it running is impressive.
Because of X Window and KDE (Score:2)
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.
Bad example (Score:2)
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...
Re:Oh Boy ... (Score:1)
Maintain one light version of the site for Avantago, Lynx, WebTV, whatever, and maintain your full-screen full version. Ideally you're using a templating system that lets both be auto-generated from the same content source.
Then, let users decide which they access. If they want to torture themselves using the full-screen version on their little device, it's their choice.
Is this really a good idea on a handheld device? (Score:2)
Re:Explain please... (Score:1)
x is server that allows for *nixes to have guis/window managers/integrated destops running... if you want more than that ask a real programer...
kde stands for k desktop enviornemnt... it's the integrated destop that includes konquerer web/file browser.. hope this helps
and if you want to be more clued up on linux issues stick around.. lots of people here have issues *grin*
Re:Isn't that quite big? (Score:1)