Most of you dot readers already know what KDE 3.1 will be about (3.1beta2 story, 3.1beta1 story, 3.1alpha1 story). For the rest of you, you can find a little teaser preview, complete with some screenshots, at promo.kde.org. Enjoy! Update Saturday 19/Oct/2002, @16:17: ZDNet UK has published the story New KDE to arrive with Halloween eye candy based on the preview. Thanks to them for helping get the word out!
Dot Categories:
Comments
How do I use KMail plugins? Where are they??
right now the only plugins in kmail are cryptography plugins. these plugins enable S/MIME support in addition to the built-in inline-PGP/GPG support. more info can be had at: http://www.gnupg.org/aegypten/development.en.html
3.2 may bring more plugin goodness for KMail.
Actually the two cryptography plugins enable PGP/MIME (signing/encryption of attachments) support and S/MIME support in addition to the built-in inline-PGP/GnuPG support (which can't sign/encrypt attachments).
I want my KDE 3.1!!!!!! *drool*
Actually Desktop Sharing has not been designed for those who use several workstations. That's a different use case that I hope to take care of in 3.2. It has been designed for support issues or just to show something to your co-worker who's sitting in another office...
bye...
Actually, I find it quite useful as a remote control, althoguh it does hurt X pretty badly (using an older version). Any plans to reduce cpu utilization and further enhance this use?
thanks
-js
>>Any plans to reduce cpu utilization and further enhance this use?<<
This is not possible without a X11 extension that would notify me of changes on the screen.
bye...
I guess you try updating just the active window (or at least updating it more often than everything else). Alternatively you could try updating a rectange around the mouse cursor.
Rich.
No, I scan the whole screen. The scanning is triggered by a idle QTimer. In each run I test every 32nd line. When I detect one or more changes on a scanline, I'll fetch these parts as 32x32 blocks, get the height of the changed region and then prepare an update (adjacent modified blocks will be merged). The problem is that it takes a long time to scan the complete screen, so the server scans permanently.
Preferring an active window or the mouse pointer, like the Windows VNC server does, may improve the latency, but it will not lower the CPU load.
What about the VNC XFree86 extension at: http://sourceforge.net/projects/xf4vnc?
--A.C.
There are tw problems with xf4vnc:
- the XFree drivers need to be modified for that. xf4vnc has not been ported to all GFX cards, for example there is no support for the nv driver. And with binary drivers, like the nvidia driver or the new Radeon drivers, using xf4vnc is not possible at all. Nor will it work on older XFree versions or x11 servers on commecial OSes. So I would still need to maintain the original code
- it's very inflexible. I already have extended the VNC protocol (to transmit cursor movements), and I plan a number of further changes for authentication and better integration with KDE. I can't do this when the protocol stack resides in the X11 server
A X11 extension that reports screen changes is probably the easier and more flexible solution for the problem.
The article was pretty light on the details.. and tooted KDE 3.2 even.. which inherently downplays this release a bit. It would be nice if there was a more in-depth look at the changes from 3.0 to 3.1. Eg. dcop enhancements, updates to each application, etc. Something that compels users to upgrade with an argument other than "it looks prettier!"
Not that I'm complaining though, this is better than nothing!
It's called a teaser, genius.
Read this for "a more in-depth look at the changes from 3.0 to 3.1":
http://developer.kde.org/development-versions/kde-3.1-features.html
At least the items which are marked as finished and probably most of which is marked as in progress will be in KDE 3.1.
Where will I find this goodie? Couldn't find it in 3.1 beta2.
open konqueror in file browser mode. go to the View menu, select Preview and you should see an option for Video. select it and then view a directory with video clips in it. you'll get a little thumbnail of the video!
In my view->preview menu there is no Video to select. There is Pictures and Images though. Although I selected everything I didn't get any Videothumbnails. Probably a problem of the SuSE-rpm's I installed or with some config from my old KDE 3.0.1?
I'll wait for 3.1 final then.
shouldn't be a config issue, but it could be something to do with the SuSe RPMs... the video preview is part of kdemultimedia, in case you didn't install all the kde packages.
...in fact, I only just fixed it today. So I'm afraid you'll have to wait for RC1, or revert to beta 1 :)
The article was pretty light on the details.. and tooted KDE 3.2 even.. which inherently downplays this release a bit. It would be nice if there was a more in-depth look at the changes from 3.0 to 3.1. Eg. dcop enhancements, updates to each application, etc. Something that compels users to upgrade with an argument other than "it looks prettier!"
Not that I'm complaining though, this is better than nothing!
It's called a teaser, genius.
Look at the colour preview, it *still* looks like KDE 1. How hard can it be to adapt it to the current window decoration?
http://static.kdenews.org/mirrors/qwertz/kde31alpha/s13.png
Reported long ago as KDE bug #32101 ... It's not a big deal, I just think it's getting a bit embarrassing for KDE.
But it's cute and historical!
Your grandmother is "cute and historical", this thing out loud sucks!
Good work from the PROMO site that is partly sponsored by the League. KDE 3.1 is lookin' very good.
I put up a mirror (http://www.ofb.biz/mirror/kde31preview/) of the piece on our server at OfB.biz. Hopefully that will help since the promo.kde.org server is currently swamped from all the /.ers coming to it.
HTH,
Tim
KDE3.1 (beta2) is great; no doubt about it.
But KAddressBook is a usability disaster. What happened?
LOL!
:-)))
"After eight years as a Gnome owner"
What is she talking about?
This is Microsofts Mac-to-Windows campaign. Seems they substituted Gnome for Mac and KDE for Windows. Pretty clever. :)
Don't take this serious. Compare it with this:
http://216.239.53.100/search?q=cache:JmwQcVoG-ucJ:www.microsoft.com/insi...
(((-:
Bye
Thorsten
That's a weird joke. Strange humour.
Qt/KDE need to get Xft2 and fontconfig support as soon as possible. I recently switched from Debian to Redhat 8.0 *only* because of such a support, fontconfig makes font support/management so much better, better than what Windows have. Just imagine the world where KDE/Gnome/OpenOffice/Mozilla have unified font management infrastructure! Let's conquer the desktop world!
That's strange.
There is nothing in the world which could make me switch from debian to Red Hat.
Of course if you don't use Gnome, Open Office or Mozilla then you don't care about a unified font configuration...
Taken from the Qt 3.1beta 1 changes file (http://www.trolltech.com/developer/changes/3.1beta1.html):
QFont on X11
Improvements: Safe handling of huge font sizes. Added support for the new Xft2 font library on XFree-4.x.
KDE 3.1 is expected to be using Qt 3.1, so KDE 3.1 will use Xft2 if available. QED.
Switching from one DISTRO to another DISTRO because of a library option??? That seem rather bizarre to me. Just install the library yourself. It's not like you have to use their binary packages and are not allowed to compile your own stuff... I've been using the same base install for about 3 years now (slackware 7) with practiclaly everything updated now from a source compile. You have control over your install once you've installed the distro; take advantage of it.
Am I the only one that is noticing a rather annoying trend in KDE development. I mean, if you run your desktop in 800x600 resolution you will often get into trouble because more and more KDE apps fail to work in 800x600. Including sometimes even konqueror itself. You get missing buttons, buttons out of reach. We don't all have the ability to use such high resolutions!
I'm noticing a similar trend.
KDE should take a break from fancy graphics and concentrate on the real issues at stake like usability and OS integration. The work done by the Gnome team on these points has been very impressive lately. They are definitely "getting it" and we're not. (And don't get me started on the mostly cosmetic changes made by the "Usability Team"!)
Do we want KDE to be the prepubescent geek's desktop environment or do we want a solid, usable development framework others can build upon and work with?
go on, start with the "mostly cosmetic changes made by the 'Usability Team'". i'd love to hear it. perhaps you don't know half of what the usability project has done. or perhaps you do and it just isn't up to your personal expectations, in which case we'd love to have you help out because the only way we're going to get faster at addressing all the issues is with more bodies.
as for the general 800x600 issues, there are a couple of devels who keep an eye on this and do try to make things works. for instance, kmail has a couple of bad dialogs. these will be fixed in 3.2 (didn't get to those ones in 3.1)
thankfully, the overwhelming majority of people run resolutions higher than 800x600 these days, so this isn't a show stopper, just something we need to be vigilent about.
as for "KDE should take a break from fancy graphics", please see: http://kdemyths.urbanlizard.com/viewMyth.php?mythID=51
>>>go on, start with the "mostly cosmetic changes made by the 'Usability Team'". i'd love to hear it.
Actually I am very impressed with their efforts. Perhaps screen resolutions should get higher testing priority.
>>>as for the general 800x600 issues, there are a couple of devels who keep an eye on this and do try to make things works
So this means a trent can be noticed where low screen resolutions seem to be more and more ignored by KDE developers. Just because your making open source software, does not mean you should start to ignore lower resolutions.
>>>thankfully, the overwhelming majority of people run resolutions higher than 800x600 these days, so this isn't a show stopper, just something we need to be vigilent
Developers do love ALL their audience I hope.
Actually I joined KDE with a project as a developer and the first I mentioned was this very issue of screen resolution. So what I say is meant to be positive. I just think its fair to say that a project like KDE seems to allow developers to get more lazy about certain aspects. If your application is in the offcicial KDE CVS tree you should at least take simple resolution matters serious. For your code will shape the overall image of the official KDE package.
> Perhaps screen resolutions should get higher testing priority.
it isn't the testing (we know pretty much every part of KDE that sucks at 800x600) as much as it is those who can and will fix the problems.
> Just because your making open source software, does not mean you should
> start to ignore lower resolutions.
of course not. it's just hard when few devels run it at low resolutions. it's easy to forget. which is why we so need those people who keep an eye on those sorts of Q&A things.
> Actually I joined KDE with a project as a developer and the first I
> mentioned was this very issue of screen resolution.
excellent, so i suppose you are fixing the problems you come across? thanks!
> just think its fair to say that a project like KDE seems to allow developers > to get more lazy about certain aspects.
KDE devel doesn't work like that ("hey! do this now!"). it works more like what you are expressing personally: "i don't like this, or i think it should be this way. i'm going to fix it." this allows for much greater personal satisfaction and higher quality work in each person's area of interest.
we just need more people like you who will not only notice a problem but then dive in a fix it.
> For your code will shape the overall image of the official KDE package.
indeed.
There is the issue of 'not forcing rules' upon the developers. But for some things, these lacking rules allow packages which are included in the official package to have flaws which do create - to some extend - bad image, where a simple ruleset could have prevented this alltogether from the very beginning.
Some enforced rules don't need to be considered 'bad' rules, as I cannot see the harm in forcing a development team to consider for example resolution issues.
Such a simple rule (and there could be more) would be relatively easy for a development team to follow. This guarantees that if you do not comply to the most general of usability issues, your application would potentially break the most basic of KDE usability issues and should therefor better not (yet) be allowed in the official KDE package.
And community based as KDE is, it could even be the community deciding the most basic rules all official apps should at least comply to. This could prevent common devilish details to appear in our beloved common desktop creation.
The problem is some developers have not the greatest care about interface or for example screen resolution. But if they want their application to be shared with the official KDE CVS, the least the community and all your other fellow developers may expect is that you comply to official KDE rules. This would introduce some consistency, and remove these ever returning issues at the same time.
I know this is all theory but perhaps it is a theory that has some basic truth in it.
there are basic rules and guidelines that all KDE apps in CVS should follow, and apps are not allowed in until they meet them. i'm refering to the UI guidelines available on developer.kde.org, of course. making sure that the apps follow those guidelines is the job of every KDE developer. if an application doesn't meet those standards, then it should indeed be removed or even better: fixed. where this currently falls down on occasion is when developers either aren't aware of or don't really care about these issues.
this is one of the goals of the usability project: to educate and sensitize. and i think it is safe to say that we are making head-way. developers seem to be more conscious about those things.
of course, we then have people like stephan binner and ryan cumming who often comb through the UIs of apps fixing style guide issues. KDE can always use more "UI janitors" who does similar things. it isn't a glorious job, but it is very useful.
interestingly, there is a KDE widget style in kdenonbeta called scheck that, when used (e.g. mykdeapp -style=scheck) highlights possible style guide violations. very cool little addition and i hope to see it go into kdesdk one of these days. it makes finding various style guide violations much easier. it doesn't catch 100% of all violations, of course, but it sure does help.
I read almost all posts to the usability mailing list and keep an eye on the code so I do have a pretty good idea of what goes on "under the hood." Most of the work done by the "Usability Team" is based on speculations about what users want and need. That's my problem with it and that's why I say that most changes made so far have been "cosmetic" in nature.
Here's what needs to happen to really improve KDE's usability:
1 - We need to determine and agree upon what KDE is going to offer its users. That means selecting basic services that need to be held to higher usability standards than whatever is determined to be non-essential. Look for comparison at what Apple is doing with its i* applications (iSync, iCal...). They've determined that all Mac users should have access to a small set of utilities which Apple will distribute itself. Third-party vendors can offer whatever they care to put out on the market but Apple can ensure that its customers have access to usable applications that do what most of them want to do. It looks to me like KDE's official set of packages contains so many applications that it has prevented the "Usability Team" from concentrating on the essential bits and from forming a clear picture of what KDE should be(come).
2 - We need to understand how real people use these essential services (in KDE or other environments) and define goals for applications providing these services. These goals should correspond to what has been reported from observing actual users at work and not from "most users do this, most users do that" messages flying back and forth on the usability list.
3 - We need to guide developers in their implementation of these goals. This means conducting user tests of those refocused applications and correcting small usability problems when they creep up as development is taking place.
Right now, the "Usability Team" is stuck on a half-assed version of number 3. Without number 1 and 2, it's pretty much all BS. We can change things here and there but KDE as a whole will never become a usable environment.
Think about how much care goes into designing KDE's software infrastructure and contrast this to the current "usability engineering" process. KDE's core developers have a vision of what KDE should be technically. KParts, DCOP... all this stuff didn't just design itself. Now I'm asking: where's KDE's vision of a _usable_ "graphical desktop environment for Unix workstations"?
(still) Grumpy
> I read almost all posts to the usability mailing list
this is a good first bit; note that a lot also happens on IRC and on other KDE lists as well.
> keep an eye on the code so I do have a pretty good idea of what goes on
> "under the hood."
do you contribute at all? sorry, i just don't know who you are...
> Most of the work done by the "Usability Team" is based on speculations
SOME of the work has been based on speculation. much of it is based either on well known principles (thanks to those who have been doing research for years in the field of HCI) or through/with actual user testing. yes, i actually test changes on users. imagine that.
> 1 - We need to determine and agree upon what KDE is going to offer its users
that has already been done outside of the usability project itself. we have no need to reinvent that weel.
> It looks to me like KDE's official set of packages contains so many
> applications that it has prevented the "Usability Team" from concentrating
> on the essential bits and from forming a clear picture of what KDE should
> be(come).
it's a combination of two things: the usability project is young. we started on small things to get our feet and build some operation structures. we quickly moved up the ladder, however. take a look at the differences between kicker in 3.0 and 3.1 to see what i mean.
the other challenge is that all of KDE (and as you note, that's a big "all") is new territory from the perspective of usability. we can't simply tear into even all of the core pieces of KDE immediately since we lack the bodies to do so and because KDE is so huge. we're eating an elephant here. we need to do so one bite at a time. join the buffet and it'll get done that much faster.
> We need to understand how real people use these essential services (in KDE
> or other environments)
indeed, we need more user testing. this will be an ongoing thing. we had one article written up during the 3.1 devel period, it would be nice to see that doubled in 3.2. additionally, some of us do test on a rather regular basis applications / interfaces that are being worked on with Real Life Users.
> and define goals for applications providing these services.
the goals are largely defined for us by the feature set implemented / to be implemented by the maintainers/developers of the app. we also have a style guideline, which the usability project is tweaking and adding to over time in response to testing and discussion.
btw, i wouldn't use Apple's current software track as an example of HCI in action. MacOS X is the least usable MacOS ever.
> We can change things here and there but KDE as a whole will never become a
> usable environment.
so we need to change everything everywhere instantly to a harmonious end or else not at all? c'mon. we have only so many people and a huge area to cover. it will take time. again, please look at kicker and compare between 3.0 and 3.1. now imagine that this gets done to all parts of KDE.
the more people we have actually doing things the quicker it will go. which is why helping existing developers be more aware of usability concerns is so important. people whining off to the side about how slow its going doesn't help make it go faster, though.
> where's KDE's vision of a _usable_ "graphical desktop environment for Unix
> workstations"?
we have a style guide, we have years of research and dozens of books/papers to draw upon, and we have the KDE technologies to work with. i think you may be confusing the usability project with a project who's goal is to perform R&D into neat and cool new interfaces that do things we don't have yet. this would be a lot of fun and maybe we'll get there one day. but we have a lot of work to do with the existing KDE code base first. there is no point in creating new things in the name of usability when the existing is crying out for help.
that said: what's the first thing YOU would address?
>>> 1 - We need to determine and agree upon what KDE is going to offer its users
>> that has already been done outside of the usability project itself. we have no need to reinvent that weel.
That's the problem: "outside of the usability project." There is in fact a need to reinvent, or at least take a good look at, that wheel now that KDE has a "Usability Team." The KDE chariot (since we're talking wheel 8-) won't go much farther if this rethinking doesn't happen.
>> btw, i wouldn't use Apple's current software track as an example of HCI in action. MacOS X is the least usable MacOS ever.
Snobbing Apple on usability issues just sounds silly. Though there are indeed problems with OS X, Apple remains one of the companies with the greatest commitment to usability. Following their example, in moderation, could only improve KDE.
>> i think you may be confusing the usability project with a project who's goal is to perform R&D into neat and cool new interfaces that do things we don't have yet.
Not at all. I'm not advocating for the creation of "neat and cool new interfaces." I'm advocating for a better understanding of what usability really means for KDE and for a pervasive commitment to usability in KDE which I just can't see right now.
>> that said: what's the first thing YOU would address?
First, I would define those essential services I talked about earlier. Kdepim holds a large portion of them (calendar, address book, email) so that could be a good starting point. Then, I would gather as much material as I can about what people do with them: discover what's important in an address book, find out how people use their calendar and deal with some of the associated tasks (sync'ing to a PDA, coordinating events with friends and colleagues... who knows?) That kind of stuff. Once we get that, we can look at what we have (KMail, KAddressBook, KOrganizer) and see what we got wrong and what we got right and start addressing some of the usability issues in the existing software.
Creating user profiles could help too. I would create, say, 5 fictitious KDE users to use as conceptual tools in usability discussions. Developers have tools (compilers, debuggers and what not); the "Usability Team" should have some too. :) I would write up something about each one of them, make them as real as possible (give each one a name and everything) and post them on usability.kde.org as resources for the whole KDE community to use: "You want to write the latest and greatest <...>, think about Jose de Souza Magalhaes over in Sao Paulo and about how your application will affect him." Give usability faces.
I've got more.
(still a bit) Grumpy (but feeling better)
fictitious users aren't very useful. they require developers to create a mental model of them, which will inevitably reflect their own biases. this is why testing with real life users is so important versus simply pondering what someone _might_ do: it enables one to discover patterns of usage that they would never even dream of otherwise.
as for your description of dealing with the kdepim package, congratulations! you've JUST described EXACTLY what we've done in the recent past with a handful of smaller apps. what we could use, of course, is someone who can do up a report on korganizer, or kmail, or kaddressbook. they are all needed, and as i've said a few times now, it just takes time. if you are willing to write a comprehensive usability report on ONE of those apps (don't bother doing all of them, there's enough material in any ONE of them ;) please do so and post it to the usability list. follow the DTD on the usability web site and i promise you it will get serious consideration and issues will get addressed.
> Snobbing Apple on usability issues just sounds silly
holding them up as the usability mesiah is equally silly.
> That's the problem: "outside of the usability project." There is in fact a
> need to reinvent, or at least take a good look at, that wheel now that KDE
> has a "Usability Team."
i don't agree one whit. the usability project isn't here to reinvent KDE, it is to help refine and improve. KDE has gotten thus far with all of its integration and features w/out the usability project and will continue to do so regardless of the usability project. that process isn't broken, so i don't see why we should attempt to fix it. we also have a style guide that simply needs to be followed more closely. there are indeed improvements to be made, but ripping every program into little pieces and putting it back together is not the way to do it. an iterative, cooperative process is required.
i know that this is counter to traditional usability sense where those involved in HCI want to DOITALLATONCE, RIGHTNOW, BEFOREWECODE! this simply doesn't work with open source projects like KDE. just as open source brought to light new ways to write code, open source will require the bringing to light of new ways to approach usability.
and to the outsiders it will appear doomed from the start, just like open source coding did to outsiders back in the day. but i feel confident that if we are diligent and take in the lessons we have learned from open source in general, in the end we will not only have results to show but they will be impressive.
join us today or wish you did later. ;-)
*gets off of soapbox*
>> as for your description of dealing with the kdepim package, congratulations! you've JUST described EXACTLY what we've done in the recent past with a handful of smaller apps
Where? When?
>> KDE has gotten thus far with all of its integration and features w/out the usability project and will continue to do so regardless of the usability project.
I'm sure KDE can and will go on regardless of the usability project. But I feel that it would be a tremendous waste to carry on with a project of this importance, at a point when it can really make a difference in the current technological ecosystem (I'm starting to sound like Al Gore :), without committing more resources to the improvement of its usability. And to a certain extent this implies redefining KDE.
I believe that we are at a critical juncture in the evolution of KDE (and free desktop environments in general). We can decide now that we're going to give KDE the means to become a true alternative to existing environments or decide to keep it around as a glorified toy for geeks. KDE is getting to a point where it is good-enough for a lot of things. It's stable, it provides an interesting development framework, it plays nice with other important Open Source components and applications. That's all very positive. At the same time, there are real opportunities "out there" for it both as a business and a home desktop. BUT ... all of this is irrelevant if we fail to fundamentally take into account KDE's ability to appeal and make sense to a wider audience. I obviously don't need to convince you of the benefits of good usability but sometimes I feel the "Usability Team" doesn't see the complete picture.
>> i know that this is counter to traditional usability sense where those involved in HCI want to DOITALLATONCE, RIGHTNOW, BEFOREWECODE! this simply doesn't work with open source projects like KDE. just as open source brought to light new ways to write code, open source will require the bringing to light of new ways to approach usability.
OS didn't "bring to light new ways to write code." It brought to light new ways for people to collaborate and distribute their work. Coding technics and principles are still the same. Writing secure code or designing coherent interface and class hierarchies isn't obsolete in OS projects, is it? Same with usability. We may need to create new forms of usability partnerships with OS developers but the principles of the art remain the same. If you don't design for usability from the start, the resulting "product" will be of poor usability. You can't sprinkle usability on top of a crippled application and hope that people will be fooled.
>> but i feel confident that if we are diligent and take in the lessons we have learned from open source in general, in the end we will not only have results to show but they will be impressive.
The lesson in usability, for os projects and others, is clear: focus your product's design around its intended users from the start or pay the consequences later.
>> join us today or wish you did later. ;-)
You big tease!
(not really) Grumpy (anymore, just plain tired)