Welcome to KC KDE! This week the bulk of email on the lists concentrated on getting KDE3 ready for its first beta. Activity was high across all the lists the KC KDE authors monitor, reflecting the general level of activity going on in within the KDE project. Even those areas that have historically seen lesser amounts of development, such as konsole and the KDE PIM applications, were hopping.
With Beta 1 approaching, we hope that you enjoy this week's summaries and as always, happy hacking!
Jean-Phillipe Bouchard wrote in with a patch to add mouse gesture support in Konqueror:
Earlier this week, I decided to give the implementation of mouse gestures in Konqueror/Embedded a try. I implemented back and forward mouse gestures in this patch and want feedback before going further. In particular, I'd like to know if:
- the patch has a chance to be integrated into Konqueror;
- the implementation makes sense (I'm new to QT/KDE and pretty green in C++);
- there should be an option to enable/disable mouse gestures in the settings;
- we should keep the 'Right click goes back in history' feature and if so, should it be mutually exclusive with mouse gestures;
While no response has been given so far, this patch should provide users to test out mouse gestures. And if the code works to satisfaction they could give feedback to the Konqueror/Embedded developers and ask for inclusion to the main codebase. The patch can be found in the KDE mailing list archives.
SVG is a hot
new technology that is emerging within the graphics community as a next generation
network-friendly format. Hetz Ben-Hamo mentioned
the new SVG Mozilla plugin
from Adobe and asked, can this plugin be supported? Konqueror Netscape-Plugin
check doesn't recognize this plugin..
It was quickly suggested that it would be better to provide native support for SVG graphics within KDE
than to simply support Adobe's plugin. Regarding why such an effort might not be
the best way to approach the problem of SVG support in Konqueror,
Guillaume Laurent commented, Because it will be a *long* time before it reaches the level of Adobe's ?
No offense, but two of my co-workers are part of the Batik team, so I know
that full SVG support isn't exactly a 2-week job. And Adobe simply sets the
state of the art on the matter.
It would be great to have our own plugin, but at the moment the right thing
to do is indeed to get Adobe's plugin working with Konq, and then worry about
our version.
Nickolas Zimmerman countered,
You don't need to tell me that it isn't a 2 week job, i know that
but ksvg exists for several months and we _are_ pretty far already.
...
of course it would be nice to have it working
but why not trying the own work first ??
I would be glad if someone would really use ksvg,
so i can get bug reports and fix them
KSVG can currently be found in the
kdenonbeta CVS module.
Objections to supporting technology from Adobe surfaced, due to their recent
track record in dealing with the open source community. But perhaps the most
lucid reason for a native KDE SVG implementation
came from Ian Reinhart Geiser who said,
Well I am on a PPC, not only does Adobe ignore the fact that we exist they
have flat out said that unless someone was going to pay them they would never
port is. (9 times out of 10 this involves a recompile)
The idea of Mozzila plugins is okay, I guess it is a neat feature, but again
useless to me. Heck flash barely works on the PPC here. Why dont we just
get more developers working on our version of SVG that DOES work on the PPC
and my dec alpha.
Lets keep KDE portable, please. I mean if I wanted to use a more freindly
platform I would have never chosen Linux. I wanted something more portable
than MacOS though.
Discussion continued (for quite some time) as to exactly how far along in development KSVG is and how reasonable it would be to expect KSVG to be ready for real world usage in the near future. If nothing else, the topic spurred on development of KSVG which has since seen a constant and heavy stream of CVS commits. The discussion has also underlined the need for Mozilla plugin support in Konqueror.
Anne-Marie Mahfouf came up with this remarkable news:
2 days ago, Charles Samuel (AKA Njaard on IRC) DCCed me an
app he coded with Qt. The aim of the program is to learn the conjugation of norvegian verbs
but this could easily be adapted to other languages, as I see it.
The application, formally known as "norskverb", is now known as "Konjugate", as suggested by
Jason Harris.
Later on, Konjugate was examined by Ewald Arnold, who
also made a screenshot available, saying:
As far as I can see this is the only visible widget,
no editing or query mode. On the left there is a list with the verbs. When you select one,
you see the tenses and conjugations on the right. You can also select one of the tenses
with the listbox in the middle.
It appears that Konjugate is still at an early stage of development. Jump on board and join the development by subscribing here or mail Anne-Marie Mahfouf or Ewald Arnold.
KDE3 release maintainer Dirk Mueller provided another update on the tagging of KDE3beta1 in CVS, which had not yet occurred due to various unresolved issues, saying:
I've updated qt-copy now to todays snapshot. I'd like to ask everyone to update and check if your patches / bugfixes to Qt actually made in and if KDE still works like intended with it, and if not, to mail qt-bugs ASAP about it so that 3.0.1 will be something we can use.
I'd like to suggest to delay Beta1 tagging till 3.0.1 is out. Its just a matter of a few days I hope. In case 3.0.1 is still not out by next Friday I'd tag then and release qt-copy with it.
Meanwhile, please help fixing the remaining show stopper problems (I've heard there are still problems with KAccel i.e.) and delay bigger changes till after tagging. Thanks in advance!
Discussion of the status of various beta-quality features ensued.
Regarding a long standing problem with Konsole when using ssh or joe,
Stephan Binner asked Does this still happen with
KDE 2.2.2?
. After getting feedback from various users Stephan concluded,
No, at the moment there doesn't seem to be a "ssh with joe" bug.
While not dramatic by itself, CVS users must have noticed that Konsole is
under heavy development these days and bugs and problems that have persisted
are getting fixed.
The relatively new mailinglist konsole-devel offers a good forum for those who are interested in making KDE's terminal application better than it already is. It looks like Konsole is getting more attention that it ever has; the CVS version seems to be prove of that!
It is easy for developers to forget that the intended audience of their work may not be as technically advanced as they are. For this reason there are people in the industry who do nothing but write documentation and user-visible messages. In an open source project consisting primarily of developers it can be a large challenge to keep visible texts relevant and understandable to average users. Claudiu Costin noted this in an email saying:
I want to tell that many strings in PO's are too technical strings:
From kcmbackground.pot: "Checking this box lets KDE to use shared memory for image to pixmap conversions."
Beside the fact that joe average user don't know even what shared memory is, he will must cope with the idea that image is transformed in pixmap.
Claudiu also discussed error messages and suggested using predefined numbers for
these messages as a possible solution. Rob Kaper
replied,
That's helpful how? It doesn't provide more accurate information for the
author (after all, I supposed the author knows the meaning of current
messages) and it certainly won't make things less cryptic for users.
Ian Reinhart Geiser added:
What I have done on the MacOS is i make a dilog that says
ERROR: <Short Error Title> <Code>
V
<A longer description of what happend here for more technical users>Where the V is a show/hide arrow thingy. This is cool because you can get the best of both worlds here. Short error codes so that users can call a support line and not have to feel absolutly stupid. And a longer error message for more savvy users. I know this is more work but I think I have seen it being done in a few places in KDE already.
Elsewhere, Thomas Zander said,
a text on screen is there for the user, not the developer.
The principle is simple; the user does not have to know much to be able
to use a computer as long as all the knowledge needed for using this is
'in the world' (in contrairy to 'in the head') Which basically boils down to
the fact that texts have to be understood without referring to documentation.
Corrin Lakeland replied to Thomas saying:
The problem with this is that error messages occur when something goes wrong. Normally there are all sorts of nice concepts you can use to explain things things to the user, you share a `world view' in UI speak. When something goes wrong this world view breaks down and you've got two jobs: 1) Tell the user something screwed up, maybe with enough information for the user to avoid the problem 2) get information to the developer for a bug report.
Giving the user enough information to avoid the problem is tricky. Sometimes the developer can guess a likely reason ``check file permissions'' but in generally error conditions occur when the program enters a state the developer considered impossible.
This is obviously not a simple issue, but one that most developers realize is an important problem to address. With appropriate care and solutions, the many users of KDE will thank them for their efforts.
A new how-to written by Anne-Marie Mahfouf for running KDE2 and KDE3 from cvs on the same machine is now available online:
I wrote a HowTo have KDE3 from cvs running smoothly with KDE2 tutorial and you can find it at http://women.kde.org/projects/coding/kde2+3.html
This is done by creating a new user (named kde3) and when logging in as this user, you get to the KDE3 system. This differs slightly from the other method on the kde website. Personnally, I used my method for KDE1+2 and I find that easy.
The only drawback is that you have to log in and out to switch between KDE2 and 3.
In reply to this, Primoz Anzur came up with another solution:
In the file called .xinitrc, somewhere in the last lines goes:
exec $WINDOWMANAGER <-- this will execute the command for your desktop... We have to replace this with just:
exec path_to_your_kde3_dir/bin/startkde
^this will switch to the KDE environment ONLY....when you boot up, this will start run your current KDE2 session, because things in the PATH... To go around this, just write a shell script, that goes:
<< begin kde3.sh >>
export QTDIR=path_to_your_Qt3_dir
export KDEDIR=path_to_your_KDE3_dir
export LD_LIBRARY_PATH=$QTDIR/lib:$KDEDIR/lib
export
PATH=$QTDIR/bin:KDEDIR/bin:/bin:/usr/bin:path_to_your_X11R6_dir/bin
startx
<< end kde3.sh >>Well... This is about it... You don't need to create another user or relogin. A simple script.
Now it's up to you to choose your way of using the lastest development version of KDE.
Oliver Strutnyski has put up a website concerning the issue of our beloved Konqueror and how it deals with online banking systems:
with Konqueror being a really great and stable browser, one should expect most banking sites to function correctly. Unfortunately that is not the case: A number of banking services simply block all browsers except for Netscape and MSIE (ok, sometimes faking UA string helps, but shouldn't they be accessible for all browsers), others use some strange java applets that don't work within Konqueror.
I started setting up a list of online banking services at http://home.in.tum.de/strutyns/banking (could be moved to konqueror.org later on) to gather and provide information about Konqueror's interaction with various banks. It is the purpose of that page to
- be useful for Konqueror users: they can easily check, whether they can access their accounts online using Konqueror and possibly find work-arounds to access some of the sited, that don't work straight out of the box
- kind of pillory the banks that discriminate users based on the browser they use. While Konqueror's market share is still relatively small, companies might want to avoid the bad pr they might get from preventing Konqueror users to use their services, especially if their direct competitors allow Konqueror users to access their online banking sites.
It is not possible for me to collect all that information, especially since a lot of banks do not provide demo accounts, making it impossible to test their sites. If you think such a page might prove useful, please drop me a line if you use Konqueror to access your banks online service or if you know of a bank's web site that works/does not work with Konqueror please drop me a line, so that I can update the summary page.
Thanks for your help, Oliver! Let's get it on!
