Our friend Simon Hausmann wrote in with some exciting news about KDE's excellent browser Konqueror: it's been ported to Qt/Embedded. He says: "I just uploaded a first version of a port of the
Konqueror webbrowser to Qt/Embedded, Konqueror/Embedded. The project aims to build a feature complete version of the webbrowsing
component of Konqueror for Qt/Embedded, including support for SSL, Cookies,
Javascript, non-blocking IO, HTML4/CSS, etc." Way to go, Simon! Simon has only been able to test this port on a virtual framebuffer -- if you can donate a Qt/Embedded-enabled palmtop device for Simon to perfect his work, please contact him!
Simon wrote:
I just uploaded a first version of Konqueror/Embedded, a port of the
Konqueror webbrowser to Qt/Embedded, to
http://devel-home.kde.org/~hausmann/konqueror-embedded-0.1.tar.gz. The project
aims to build a feature-complete version of the webbrowsing
component of Konqueror for Qt/Embedded, including support for SSL, cookies,
JavaScript, non-blocking I/O, HTML4/CSS, etc. Well, basically almost everything
the "big brother" can do, with the main difference that it consists of only
one static, small binary (plus some small data files). The status of development is that it is almost feature complete (http
authentication caching is missing). There are a few bugs left and some
cosmetic changes in the GUI.
Here are some screenshots:
Depending on the compiler/binutils used the size of a stripped binary is somewhere between
2.1 and 2.8 megabytes.
Please note that this is not a fork of the original Konqueror. The portis realized by copying the unmodified original sources (this is in fact
the very first step in the build process) and compiling them in a new
environment, an environment without X11 and without kdelibs. This means that
Konqueror/Embedded always automatically gains from the latest bugfixes
and improvements of the KHTML rendering engine, the HTTP KIO slave and
other sources by using/compiling the original sources directly!
The software compiles and runs on Qt/Embedded as well as on Qt/X11. The
support for Qt/Embedded has only been tested in the virtual framebuffer on a
PC, because I don't have the hardware for "real life" testing. So if anyone has a Qt/Embedded capable device and is looking for a
webbrowser please drop me a mail :-). I would love to know if this
software really works :-).
(I'd be happy to help out with any compilation/run-time problems, as far
as that's possible remotely)
In general I'd be happy about any feedback, especially with regard to the GUI
(for small resolutions like 320x240).
Bye,
Simon
Comments
I think that this is an awsome idea, and the fact that its finished is making KDE get closer to every computer. One thing I am concerned about is the fact that this is the only program that has been ported to QT/Embedded from the KDE project. Point your browsers to the online CVS for KDE and you will notice that in kdenox (KDE NO X) Konqueror is the only thing there. I do understand that this is a step in the right direction and I hope that others soon to follow. Tronical: mabey you should write a howto or some notes on how you ported it, many would follow you, and that is what we need.
Thanks,
Error
I guess everyone is waiting for Matthias Ettrich to initialize the development on KDE-NOX. History tells that this usually happens in form of an inconsiderable-looking USENET-posting. *hint* *hint*
Greetings,
Torsten Rahn
This is great news about Konqi, and could be the start of a full por of KDE to Qt/E.
as for Mattias Ettrich giving the thumbs up, does he really need to say so? It would be great for him to start the ball rolling, but surely anyone could port any part of KDE (including kdelibs, kdebase etc) in theory?
I think a full port of KDE away from X would be great, and I have been told by some coders that there is not a lot of KDE which relies on war X libs, and most requires purely Qt.
Can anyone comment on the likelyhood of this? There seems to be a demand for it. :-)
Jono, you got me -- I forgot the smiley. So here it is:
:^)))
Hehe...smileys are good. ;-)
How would KDE support video cards without X. Is there a way of just using those parts of X that pertain to video cards? What about the new anti-aliasing features?
Can KDE really just canniblize X to create a lean, mean, Windows-eating machine?
If any of the developers could give the brodest outline of what it would take to create KDE-NOX, that would be great to read!
Samawi
I wonder if it would be possible to just use the video card drivers from Xfree 4. Since they are now nice and separate from the server I would think that would be possible. Of course you could only run KDE apps, but I think it would be really nice for trying to create a low-overhead GUI for things like kiosks and what not.
Not really. You see, KDE wouldn't be making their own personal version of display drivers, rather, it would be using the internal framebuffer drivers that are loaded as part of the kernel. I'm not certain if FBDEV yet supports acceleration, but it runs in SVGA mode just fine.
the new kernel has its own accellerated drivers for a number of chipsets as well as a perfectly useful frame buffer. there ought to be some way to use kde right on top of the kernel -- which is, after all, already in a graphics mode.
anybody know what modifications would be needed to bring this about?
I haven't worked on KDE development much so don't know about the kdelibs and other libraries in KDE and there dependency on X.
However yestarday I was looking into qt/embedded(qte), based on my preliminary analysis there is a kernel directory within qte/src, the qgfx*.* files should give anyone a rough idea of how qte provides a flexible graphics layer.
Roughly:
1) One could use the Framebuffer driver in Linux kernel for their target to work with qte because qte already as support for Linux framebuffer.
OR
2) One could implement ones own graphic drivers by inheriting from qScreen for the framebuffer part and from qGfxRaster for the Drawing primitives.
KDE-NOX would be nice, except that by abandoning X, we lose the use of all X applications!
Sure, GNOME may not have much now, but what if they come up with some killer app later?
Oh, wait. Even if GNOME did come up with one, I probably wouldn't install the GNOME libs anyway. Never mind. :-)
"compiling them in a new environment, an environment without X11 and without kdelibs."
does this mean, that konqueror compiles without the kdelibs?
how does it work?
i can't believe it's so simple to make konqueror a non-kde application? (but it would be great :))
where can i find more about it?
This could be also great for old computers with low memory.
That's true. Handheld computers shouldn't be the only target group for ports of KDE stuff to Qt/embedded. Linux/Qt/embedded seems to be the perfect platform for thin clients. Install the browser and a couple of small-footprint client programs on the local machine and use http or XML-RPC or whatever to just communicate the data, not the graphics ...
Here's a small GUI suggestion:
Get rid of the scroll bar on the right. Since real estate is so tight on PDAs, it might be wiser to have the two scroll bars next to each other on the same horizontal line.
Eg:
[<]===[>] [^]===[^]
The second [^] would be the down arrow.
Another further improvement would be to create custom scroll bars that are about 1/2 or 2/3 the width of the default ones, in order to squeeze out more screen space.
Just my 2c.
-Niek
Excellent idea!
So one would loose a bit of height but get more
width?
Oh, and your idea of making the scrollbars thinner
is definitely great! I'll see if that is possible.
Thanks for the comments!
Bye,
Simon
As a user of Psion palmtops for some years, I see some things that can be improved. Symbian (Psion/EPOC developers) has published an excellent style guide: EIKON Application Style Guide. This document sums up many years of experience in GUI design on small devices.
I'd say the vertical scrollbar is the most important to keep, as it would be hard to quickly jump up and down without it. A more important change is to move the arrow buttons to one end (or both ends) of the scrollbar (like in some KDE themes). This makes it much easier to operate with the pen (most devices will probably have a touch screen). There can be a similar button pair for horizontal scrolling, but without the scroll bar.
Some things are unnecessary to keep on the screen. The menu should be hidden, accessible by a button (has worked nicely for ten years on Psion PDAs). Toolbars should be simple (like on the screenshots you've shown). All buttons should also be large enough to operate with a finger.
Regards,
Gaute Hvoslef Kvalnes
Get rid of the scrollbars completely, use the hand cursor instead, as have been used on Macs for ages.
The Windows image-viewer ACDsee uses the hand cursor exclusively and have no scrollbars at all!
This should be an option in KDE as well.
Ah, excellent idea. Hand cursor == small gameboy like joypad thingy, right?
Hmm, I wonder if Qt supports it? :-}
Hmmm, I'll probably just make it an option in the menus to turn off the scrollbars (combined with the idea someone else here brought up: make the menubar a toggable item, not visible all the time)
Bye,
Simon
This probably needs a hack of Qt.
Another idea is to make scroll- status- and tool-bars auto-hide, like the taskbar in Windows and the Panel and taskbar in KDE. They pop-up when you place the cursor at the edge of the screen.
The hand-cursor is used in all versions of Acrobat Reader as well, maybe it was old Aldus that started it. This could be applied to all apps, both regular KDE and embedded, you just shove the contents of a window or frame around while holding down a mouse-buttton.
the "hand-cursor" would make it impossible to drag-select text for cut& paste.
Thumbs down!
It would be selectable, don't worry.
The hand cursor is not really like a gameboy pad if I understand correctly.
The hand cursor is what you get when you hold the spacebar down on adobe products like illustrator, acrobat and photoshop. The idea would be that once you touch the screen you take mouse coordinates and pan the page you are viewing based on how you move the mouse. The part of the page you click on stays under the pen tip.
I believe AvantGo's web browser for the palm works this way.
-pos
Yes, AvantGO works this way, and it is quite functional. However,
it is difficult to scroll down many pages at once ("I want to get to the bottom of this damn thing!").
Having the option of hidding the scroll bars is quite useful,
especially if combined with some sort of "scrolling device",
like the "Up-Down" buttons on Palms (is there support for such thing in Qt-embedded?).
Joystick-like devices are very good when you *need* diagonal movement (ex. games). On a PDA I'd rather have 2 rolling-devices
(I don't know how you call it in english, you know like the
old style buttons used in radios to manage the volume).
One at the top of the device (I could use it with my thumb) to scroll horizontally and one at the left side (where the pointer usually is) to scroll vertically...
Panayotis.
What KDE needs is a more general configurability of things like scroll bars.
For example, they get a bit thin on a 21" monitor or larger. Fishing for the small target area with a mouse can be a pain. Seeing it well can be a pain. Which a lot of people will experience as the grow older, as I am finding out. And for some who have motor-coordination problems, being able to double a scroll bar's size would be useful. Being able to set colors would be good too, for those with vision problems. Generally speaking all around configurablity should be an aim in future KDE systems. As technology goes on we will have Linux on stuff from phones to PDA to 10" sub-portables to 32" screens and 42" home media centers, capable of monitor Display. One might envision future KDE systems with a set of preset configuations from PDA to large monitors, to widescreen laptops etc. Pick one which gets you in the ball park and then configure anything not quite right. A large screen might be set with wider scroll bars. It would be nice to have it sort of like Opera where you left click an item and pull up a configuration dialogue. Hit a scroll bar and set it 2 x normal size and make it light blue. And it would be nice to have profiles for more than one user on a machine. A big plus in a business setting. Or a one computer family situation. It would make it easer for somebody with several machines to coordinate uniform setups across machines.
To go a bit further Simon,
The location toolbar is not stricly necessary in this form factor either. My guess is that usability studies would show that pda's aren't used for browsing so much as they are for checking known (and thus bookmarked) sites.
The status bar can show the current location just as well as the url text box, therefore making it somewhat redundant. A toolbar button that brings up the url entry would be sufficient in the case that the user would want to navagate to a new site.
One could even go as far as maing the status bar only a toolbar button that brings up a tooltip on mouse over. (pen over?) What about a fullscreen mode?
overall, great work!
-pos
I would go even further and say that the title in the titlebar is not really necessary, and could be replaced by what is now the status bar/current status bar. Or at least on mouse-overs ?
Oh, there is a titlebar? Totally unnecessary as a window shouldn't be resizable at all. The current application is always maximized on a PDA (except for dialog boxes).
And mouse-over effects are not possible on a PDA, as you most often don't have a mouse but a touchscreen.
Regards,
Gaute Hvoslef Kvalnes
The titlebar I can't remove that easy, because it's what the Qt windowing system provides (well, I probably could remove it, but I'll better leave that to Qt ;-)
You are definitely right on the statusbar issue. I will probably remove it then and implement "pen-overs" as tooltips (so that when you hover over a link the url gets displayed as tooltip, not in the statusbar.
Bye,
Simon
"Pen-overs" are impossible - the touchscreen doesn't know where the pen is until you tap it. What you describe is implemented as follows in Psion Web: Tap once, link is displayed in a corner of the screen. Tap again, link is followed. These corner messages are Psion's variant of status bars - another great way of saving screen space.
Regards,
Gaute Hvoslef Kvalnes
well.. i planned to write this posting with konq/embedded but unfortunetly it hangs everytime i click on "add" :)
but other forums work great.
just wanted to say i really like it!
i use it with x11, though.
it's the fastest browser i have ever seen (in startup and in rendering) and has even a loweder memory footprint than opera.
this just needs some minor tweaks to become my new desktop browser of choice.
this could really be a killer application, especially for all those non-kde users out there!
i really really hope this won't be embedding only :) it's even great for the desktop.
this is EXACTLY what i was waiting for!
> unfortunetly it hangs everytime i click on "add"
That is a bug in current CVS. Why didn't you post your screenshot?
http://home.wtal.de/borgmann/konq.png
thx, whoever you are :)
i posted the link in my first two tries and than forgot it ;)
Anon used my e-mail address, and so I got e-mail confirmation of this reply. I have no idea what you people are talking about, but good luck with it.
So etwas hab ich auch schon gesucht, gibt es schon fertige bin's?
I actually never mentioned this, even though I always wanted to try out kdenox. I'm having trouble recompiling QT/Embedded (at the moment I don't have the error) with differen compilers (gcc-2.95.2 and egcs-2.96).
Anything I should be aware of?
I mean I think I have all the requistes (fb set up properly..)
Tack.
On a small screen it's very important to make as much space available for the viewing pane, by mininising the interface. The interface can be minimised by makeing thnigs smaller, hiding them until needed or getting rid of them all together.
As an example of the latter, get rid of the tile button. The screen is too small to support overlapping windows.
As suggested by others, the scroll bars should be half the size or less, if they are to be static, or a pop up option.
The URL location box should be hidden, probably brought up with a button on the button bar. The title bar probably should be removed or made optional.
The button bar should be shrunk a little. The Words File and Bookmarks should be replaced by buttons so that all the buttons can fit on one row (including shut and minimise). Actually, you could do without minimise.
On a PDA, the menu bar is usually hidden, and brought up with a hardware menu button.
If you have never used a palm pilot, you should try to get a hold of one, at least for a few weeks. This is the best example of a minimalist design that I know of - it's amazing. I read that the developers actually measured how many pen taps/strokes were needed for every possible action that could be performed in their program suite and tried to minimise this without making the interface ambiguous or confusing.
Chris
Yes this is some top advice IMO. I aggree that the text menus should be replaced with small icons and could be identified via tooltips. An interface similar to Internet Exploiters fullscreen mode would be good, ie a nav bar the optionally autohide navbar, and a stop button that pops up only durning network activity would be a good one same with the forward/back, if you cant go forward, why have a button..
Are you refering to InternetExploiters.com?
Does anyone else think the browser should
be wider than it is long? I noticed the
demo QT/Embed apps could roate themselves -
can Konqi do that?
konqueror -display Transformed:Rot90:0
I have a horizontal picture on my digital display in documents. How do I upright this picture so it is correct vetically?
U have to have a picture editor then open the picture with it. There should be options to rotate the picture and just select that. Once you exit the picture make sure you save the changes.
Excellent- I've been waiting for an easy way of fitting Konqueror onto my linux distribution "JAILBAIT" specifically for the I-Opener... and I had not yet heard of QT-Embedded until I stumbled across this...
Thank you, Simon! I'm really happy to hear about projects like this!
-Jeff
Great!, now if only we had Kword and Kspread embedded , we would REALLY be cooking!
You are soooo right!
how do i enable https?
if i want to reach a secured site it says something like "The protocol https is not supported". do i have to use some special compiler flags do enable ssl?
btw it's working for me with "real" konqueror, so all necessary libraries should be installed.
from http://lists.debian.org/debian-kde/2001/debian-kde-200109/msg00098.html
<<
> I get the message:
> "The protocol https is not supported."
>
> I think there might have been some message about crypto, perhaps
> mentioning that I needed to do something else to get it, when
> I installed KDE, but I don't recall.
You probably need kdebase-crypto and kdelibs-crypto. You might need to add a
non/US entry in your apt sources to get those.
>>
HI...
i'm also facing the similar problem.when i browser in the konqueror/embedded web browser. i got the error "the protocol https no supported".can you say what do you mean by "You might need to add a non/US entry in your apt sources to get those".Should i give any option while building inorder to activae it...? or what should i do inorder to get that working...?
thank in advance..
saravanan
Very cool!
Regarding the GUI thing: It seems that the main problem is that websites just are not "320x240" and also not "240*320" as your screenshots (or an iPac) would display them.
I support the other suggestions (rotating, minimizing the widget size etc.) and add a new one that might be a bit harder to acomplish:
What about a "zoom" mode? A lot of links can still be guessed at half the size, so this would give us almost the same usability as a full 640x480 screen ...