In this week's KDE-CVS-Digest: KStars is now using a new free star map and the telescope interface gains some new wizards.
KGhostview (PDF/PostScript viewer) now has a thumbnail preview.
A new KHotKeys is in the works. KOrganizer is improved with work on drag and drop, alarms and todo lists.The KDE Config Editor moves along. The trash icon is cleaned up. KHTML caret navigation is almost completed. The KDE dialogs can now be used by non-KDE applications. And more.
Dot Categories:
Comments
Hello. I'm the author and SuperKaramba. I think it would be great to add it to KDE at some point if people want it. However, I really don't think it will be mature enough to include by the 3.2 release.
The program is still developing very rapidly and putting a release in KDE at this point would hurt KDE (unstable program, documentation improving but still lacking) and hurt SuperKaramba (people wouldn't take advantage of new features because they would be stuck with an old version and have no idea how to get a new one).
SK in kdeutils in kde 4 would be great :-)
Okay, I couldn't take it any more, seeing each KDE version get more and more bloated context menus and slowly turning into a usability monster who's rampage is making more and more KDE applications have bloated, illogical menus.
This in my eyes is by far the most serious problem with Konqueor. It's like havinga book who's index is scattered with all kinds of entries from other books and with inaccurate page numbers causing an unbelievable amount of problems.
In response to this issue I wanted to make the first step in the right direction by submitting a bug report, if you are as disspointed in the way KDE's context menus are going please vote for my bug here: http://tinylink.com/?DMZFXCKyrA and maybe such dire problems will get resolved by 3.2.
If you want to see more of my wishes and bugs here is my bug list: http://tinylink.com/?rfvbhDinLz
Thank you and have a good day ;)
Hi Alex...
You really need to take a look at CVS. A lot of work has been done by people in changing the context menus. These should be very evident in 3.2, as will the KControl changes and many other usability tweaks.
You might like to subscribe to the usability mailing list to keep up to date with these things. There is a signup form at http://lists.kde.org
This si good news and I'm aware that an actions menu has been added in 3.2, but I'm not sure what else has been added. I would love to see a screenshot of the context menu that comes up when text is selected.
Anyway, I found out there was already a bug report about this and it has over 300 votes! But it needs even more votes, it needs to have more votes than any other wish because this really is the worst part of KDE and what the gnomers complain about the most ;p
Please vote here: http://bugs.kde.org/show_bug.cgi?id=53772
THANK YOU!
Please don't campaign for bug report votes. It is counter-productive. It is essential that users only vote for the bugs that *annoy them*. If they vote for campaigned things, then some bugs will be artifically inflated, leading to them being fixed before bugs which annoy the community more.
To be honest, Gnome users usually have a go at KControl, the K menu, Kicker and Konqy. Context menus are eventually on their lists, but fairly low. To be frank, fixing/changing any of these things won't make them change over to KDE, and the first priority is improving the user experience for existing KDE users. For example, people complain about the Gnome file selector, and while I accept that it is a dog, fixing it won't get me to change to Gnome. Fixing GTK so that it isn't so hideous to program with would be a good start, but that is a topic for another day.
And which would you prefer, more votes for existing bugs or more bug reports about the same bugs? Bugzilla search system is not perfect, you know. I'd open at least 30 new bugs, but it's too much of a burden to prepare proper test cases. However, if I knew that these bugs already exist, I'd vote for them.
The thing is, this bug was opened in January, and KDE users *are* bothered with it. Developers obviously don't care. The voting system is there exactly for cases like this.
Personally, I'd like more votes for the bugs people find meaningful. The fact is, it is a self-resolving issue. If you really get annoyed by a bug and it means something to you, you'll either vote for it, if the report already exists, or you'll open one yourself. It is really annoys you, you'll take the time to open the report and produce a few screenies or other testcases. If it's really too much of a burden, then it doesn't mean that much to you...
In January, 3.0 was out and 3.1 was in feature freeze. Changing the menus like this really does mess up the internationalisation strings, and people would be more annoyed it most of the context menus didn't work in 3.1 in their language, if it wasn't English.
Developers do care about this stuff... that's my point. They have been working hard on changing the context menus fo 3.2, because users wanted it. There has been a great deal of work on K menu organisation, Konqy menus and KControl for exactly the same reason. Developers really do care and you'll see that in 3.2.
"If you really get annoyed by a bug and it means something to you, you'll either vote for it, if the report already exists, or you'll open one yourself. It is really annoys you, you'll take the time to open the report and produce a few screenies or other testcases. If it's really too much of a burden, then it doesn't mean that much to you..."
Regardless of the rest of the conversaion, this attitude really annoys me. I can understand that there's only so many bugs KDE developers can handle, and that a flood would just make development even more slow. But this attitude just means that you'll only get techies submitting bugs. Unless I'd prodded her, my girlfriend would never have submitted the bugs she had, including some for bugs that really caused her problems, because it looked confusing, and because she didn't see the bug system and think: ah, if I submit a bug report, it will get fixed, hooray!
If we are to cater for users who aren't used to the Free Software way of doing things, we can't take this attitude that it's good to keep people from filing bugs unless they're *really* bothered.
In the case of the Konqueror menubar and context menus, I think it's incredibly obvious that there are serious problems. Just look at the menu bar... many of the items from "View", "Tools" and "Settings" could be in any one of those menus for all I know!
I think maybe what I said came across in a different way to the way it was intended.
What I meant to say, is that without bug campaigning, the system will naturally float to the top the most critical bugs, and the less important bugs will get, by their nature, reported and voted for less, simply because people won't go out of their way for them.
Don't get me wrong, I accept entirely that current bug reporting is a barrier to entry for many non-technical end users, but I also submit that there are technical end users who perform the same roles, or know people such as yourself who can assist them in filing bug reports. Ideally we have a bug reporting system that is perfectly user-friendly and everyone can submit reports and the thing automates screen-grabs, sample cases, etc. But unfortunately, there is a limit on those things. There are users, for example, who don't understand the concept of a mouse. Bugs.kde.org doesn't cater for them. An extreme case, but a very real barrier to entry. Similarly, moderate users who can't grab a screenshot or describe their problem in a useful manner ("Tables don't work in KWord") are difficult to deal with too.
In the long term, a better bug reporting system would be very nice, maybe with automated recording of user actions and users able to attach notes to explain what they wanted to happen. Until that can be brought about, however, there are a great deal of bugs to work through, that, although submitted by technical users, can be representative of general users too. Those are what we have, and we need a balanced bug voting system to understand how critical those bugs are to the community and in what proportion. It's not truly representative of the total user body, but we have to hope that it isn't so far off. Also, at present, fairly significant bugs are being fixed, which I'm sure all users need to see resolved.
As for Konqy menus and context menus, there is a lot of work going on wrt those, and the results are progressing nicely in CVS. Those will be released in 3.2, as mentioned earlier. Hopefully all users will enjoy the benefits of that work.
To be honest, if the KDE's most serious problems are that there are context menus with limited ergonomics, I would consider the project to be doing rather nicely. It's a definite move forward from applications not existing/not working/crashing all the time.
This is what the 3.x series has been all about. 3.0 was definitely a massive leap forward. 3.1 saw a stabilisation of that to a very high degree, with features being rounded off and added to, making them more usable. In feature terms, 3.1 is relatively complete. It will work on anyone's desktop, and applications notwithstanding (I still want a KDE replacement for Photoshop), it is ready for daily use. 3.2 is really a refinement of 3.1, with a number of new features to make life easier and some great additions, such as Kopete, but it is most of all, a usability improvement. Menus are improved, KControl is changed, context menus are redesigned, Konqy's tabbing is improved and hundreds of other tweaks to make life easier and more intuitive for users.
The developers are working really hard on these things, and really listening to users about many issues, in fact, this is a user-experience focussed release, more than anything else. Wait and see what you think. I think you'll like it.
Ok, I have here KDE compiled from CVS maybe one week old:
- There is no significant improvement in RMB menues.
- There is still no Copy option when selecting a piece of text.
- Right click on background in file management mode shows 24 options.
Your other points: I entirely agree. This same problem existed before, but I think now is the time to solve it, since other major issues are mostly solved. If I have time I will dive into Konqueror code during the following few weeks and try to at least understand how it works.
Pardon my previous post. I accidentally ran the older version of Konqueror. Right click on background in file management mode gives now only 14 options. This is definitely an improvement.
Any campaigning for votes obviously skews usefulness of votes at all. And our friend
Alex has been doing so much of that, that for many areas votes are absolutely meaningless,
because they loose any statistical signficance. Just because you can post on 10 websites
and convince 15 people to vote does not mean it's more important than something
a lot of people /independently/ came to conclusion of. Frankly, I'd like to see
a dot and kde-look policy forbidding campaigning for bugs.
If 15 people voted for a bug, then 15 people are annoyed by that bug. If you think that there is something more important, just post it here so we can see for ourselves.
Maybe we should consider lowering the maximum number of votes one can give, so people would make priorities? Perhaps 20 votes per package and 100 votes total? Or maybe someone could attempt a "weekly bug digest" (ugh, sounds disgusting ;) ) where various bug reports would be presented in a non-coder friendly way, so people could consider voting for them?
Anyway, I dislike the ban because a) spammers will just post the link to other forums, such as kdelook or slashdot and b) that way you limit the votes just to coders and people that know how to use bugzilla, and this will skew results away from wishes of regular, non-coding people - and KDE of all OSS projects should try to cater to non-coders. The reason why Alex alone can pump the votes for a bug is because so few people vote for bugs at all!? The most wanted wish has 1200 votes, that's 60 people - most web polls are considered useless if the top voted option has less than 100 votes. So, if you want to prevent skewing, vote! And ask others to vote as well :o)
Do you actually think more votes will help? Isn't it like spam?
The developers are well aware of the problem. CVS HEAD already has a reduced context menu. No doubt more fine tuning will happen in the months to come. This is one of many usablility issues that are being resolved.
Derek
I don't think that's true. All I did was make some of my bugs known, you don't have to vote for them if you don't want to.
It's just that without spreading the word nobody will know. Believ eit or not most people who are annoyed by something in KDE wil not bother to report it or search through the bug database.
Some of the things that annoy people the most are never voted on because users don't case to do so, KDE has about 9,200 bugs and wishes!!! How many people do you think will ever bother to look through all of them or even search through them.
Not a lot. this is why if I want any votes I need to spread the word. Also, I've only plugged my bugs on the dot.
But the developers are the ones that need to be aware of the issue. They are. More votes won't do anything. What is needed are coders to fix the problem. It may not be a simple matter of changing a small thing. There may be some infrastructure needed. Or it may be a matter of someone spending alot of time going through each application. Are you volunteering?
Derek
I don't think that his intention was to spam the index. It's just that he's trying to help KDE in the best way he can. There are many, many users who are annoyed by this bug and Alex is trying to make developers aware that this is one bug that needs to be fixed.
While some have complained about bloated context menus being present in many KDE apps, in fact, the main culprit is Konqueror. And fixing it will not require creating and translating new menu entries, but rather just deleting irrelevant ones.
There is no reason for a selection CM (to pick but one example) to have options for page navigation (that gets rid of Up, Back, Forward, Reload), window/file operations (Open in new window, tab, background tab, add to bookmarks, Open with, K3b)
I hope other toolkit systems start using some method like this, this way we can for example, have a kde file dialog in openoffice while running kde, a gnome file open dialog when on gnome, or the own openoffice file dialog when running on other desktop that dosen't provide a file dialog.
This would be good for users I belive, making apps looks as the user expects (because he is working on kde he expect things to look as kde apps).
Less confusion I belive.
Next step would be making styles/themes compatible between toolkits.
I'm afraid that OpenOffice and Gnome apps tend to implement their own file selectors per application, or re-write the existing ones heavily, which is why the Gnome folk are having a hard time creating a new one for their desktops. The Oo one has to be self-written for cross-platform stability, too, so that can't really change, which is a shame.
All i all, it isn't an easy problem, I'm afraid :-/
I believe the new file dialog stuff in Gtk 2.4 allowed other file selectors to be used in Gtk/Gnome programs..
(including the KDE one)
Actually, the OOo version for Windows (and the future OSX-native one) do not use the dialogs used in the X Window System version of OOo. Creating a KDE binding will not be too difficult.
Your point about "GNOME apps" is also wrong since one of the criteria for being a GNOME app is that one must use the GNOME dialogs. Gtk programs, on the other hand, do tend to make their own dialogs.
This new opening of the KDE file dialogs will be good for those wishing to write multi-platform Qt apps. Now, we're not stuck with the basic Qt boxes and don't have to reinvent the wheel.
I hope that kdeinit won't be run all the way, though. That would sort of defeat the purpose of running non-KDE WMs.