KDE 3.1.4 Released!
Wednesday, 17 September 2003 | Binner
The KDE Project announced KDE 3.1.4 today. It's the fourth maintenance release of the successful KDE 3.1.x series and ships with many bugfixes and improved translations. KDE 3.1.4 also contains two fixes for security issues in KDM. Users of KDE 3.x are advised to upgrade to KDE 3.1.4. Read the incomplete change log or jump directly to the download links on the KDE 3.1.4 Info Page. The Konstruct build toolset was updated accordingly.
Comments:
YAY!!! - mario - 2003-09-16
I hope it makes it into the releases for Mandrake RH, SuSE etc. It sounds like a lot of annoyances have been fixed making 3.1.4 top knotch.
Re: YAY!!! - Mumumba - 2003-09-17
there are not much important changes since 3.1.3 instead of the security issues related to KDM and maybe the "Konqueror: Don't crash when opening a directory in tab from the navigation panel" bug.. or are there any new features like font-shadow on desktop in Release 3.1.3 ? :)
Re: YAY!!! - mario - 2003-09-17
Well, the crashing fix and cpu waste of knewsticker was what pisse dme off most about 3.1.3. Anyway, Im sure that these are just a few improvements in 3.1.4, probably a lota re not mentioned.
Re: YAY!!! - Anonymous - 2003-09-17
You should study the changelog again now (and perhaps in some days again). And of course there are no new features because the KDE 3.1.x branch is feature-frozen.
font-shadow on desktop in Release 3.1.3 - Saiyine - 2003-09-17
Whoa, I thought it was a 3.2 feature! I'm using 3.1.3 right now, where can I activate the shadows? There's nothing in my 'Desktop configuration' dialog about it :?
Re: font-shadow on desktop in Release 3.1.3 - Mumumba - 2003-09-17
which packages are you using ? i am running SuSE8.2 but the kde-packages from ftp.suse.com (or mirros) doesn't contain the font-shadow patch. instead they included the window-shadow patch, but when i tried the packages, i didn't find the shadows or the configuration anywhere.. so i reinstalled the 3.1.3 packages from ftp.kde.org (well, from a mirror ;) (i read about the fact that SuSE removed the font-shadow patch from the kdebase3-3.1.3 package in the package-info, but i think, the font-shadow is more usable than window-shadow;) but now, i am looking for the SuSE packages of 3.1.4 ! it seems they are still not uploaded/finished on the ftp.kde.org Server.. also i found, there are much more bugfixes in 3.1.4 release.. when i first looked at the changelog, there where only some notes added. Great, now, where are the SuSE packages? ;) thx
I'll wait for 3.2... - Dave - 2003-09-17
I think that I will wait for the 3.2 release instead! /Dave
Re: I'll wait for 3.2... - ac - 2003-09-17
I thought it was a joke but it looks like they really did remove "View Document Source" from the Konqueror context menu in 3.2 unfortunately.
Re: I'll wait for 3.2... - ac - 2003-09-17
In case I give the wrong idea, other than that, I think KDE 3.2 is looking superb. Konqueror, KControl, etc have made some real advances!
Re: I'll wait for 3.2... - George Staikos - 2003-09-17
Honestly it doesn't make much sense. The "context" for the document is the application menu. That's why it was moved there. The context menu now has "Show Frame Source".
Re: I'll wait for 3.2... - mario - 2003-09-17
Wait, so View Document Source was completley remove dor not? I thought it was very useful, I would rather have this stuff removoed: http://bugs.kde.org/show_bug.cgi?id=53772 and making the context menus context sensitive, (read Alex's post in the above link)
Re: I'll wait for 3.2... - Rayiner Hashem - 2003-09-17
Actually, that seems like a better idea overall. What do people think of this suggestion? Would anyone really detest it if someone went and implemented it?
Re: I'll wait for 3.2... - Dawnrider - 2003-09-17
Nope. Go and implement it :)
Re: I'll wait for 3.2... - ac - 2003-09-17
There is no "Show Frame Source" when there is a single frame. It doesn't make sensce to have "Show Frame Source" sometimes and not other times. It's quite inconvenient in fact...
Re: I'll wait for 3.2... - Alex - 2003-09-18
Agreed. There should be "Show Frame Source" no amtter how many frames are open it should just show the source of the current frame, if it's only one than so be it. I do agree taht "Show Frame Source" is a technically more correct name, However I think "View Frame Source" is more consistent with other applications on all platforms.
Re: I'll wait for 3.2... - Tom - 2003-09-17
Agreed. The growing consensus from what I can gather on the usability list is that the context menu should be properly context sensitive, and only display items which are very inconvenient just being in the main menubar, or cannot be used there at all (like frame sensitive options).
Re: I'll wait for 3.2... - Rayiner Hashem - 2003-09-17
Awesome. The latest 3.2 menu down to about 14 entries. The next things I want to see go: Duplicate in New Window/Duplicate in New Tab --- There should only be one, following the same behavior the user chooses for opening links in new windows. Copy Text --- The menu should be context-sensitive to what's underneath. There should be a text menu similar to what you get when you right-click in a text-box, and that should have cut/copy/paste. The "Copy To" item already takes care of copying the page itself. Encrypt File --- I liked the "actions" menu that was in here originally. How often do you want to encrypt Slashdot? Stop animations --- Again, how is this context sensitive? It should be a toolbar button. Security --- This one doesn't even make much sense. It just tells you whether this page if secure, and gives you a shortcut to the SSL settings. The "page is secure" indicator should be a status bar item. This is probably the low hanging fruit, and gets Konqueror down to 10 entries. That's not bad. If you really want to hit that magic 7 and under number, you could go after a few of the more controversial entries, like set encoding.
Re: I'll wait for 3.2... - George Staikos - 2003-09-17
Security has to be in the menu because it is context sensitive. It shows you the security for the inner-most frame at that point. Encrypt file is a plugin, not part of konqueror.
Re: I'll wait for 3.2... - Spy Hunter - 2003-09-17
It should be reworked as a menu item that shows a dialog telling you about security for each frame on the page, and then removed from the context menu. Same with "view document source".
Re: I'll wait for 3.2... - mario - 2003-09-17
Still, I think secuirity and many context menu tiems do not belong there, they are not foten used and should be in the main menus. Also, please don't remove the open in new window option or open in new tab or duplciate tab or duplicate window options, these are useful in many isntances and tehre is a reason tehre are two. If tabs were as versatile as Windows I would have no problemw ith this, but they are not and widnwos have much ebtter drag and drop support etc. I'm all for removing features that do not fit into the context of the suer's actions or just plain aren't used by anybody, but I don't think this is one of them.
Re: I'll wait for 3.2... - luciano - 2003-09-17
You know that you can 'detach' a tab to its own window?
Re: I'll wait for 3.2... - George Staikos - 2003-09-17
And how do you intend to find out the security for the point where you're clicking on the page? This is all too complicated. The security is context sensitive and belongs in the context menu, plain and simple. Originally it wasn't in the context menu, but this was wrong.
thanks - Anton Velev - 2003-09-17
People, enough discussions about context menu in Conqueror! If you want to learn from someone how much they should be - learn from Apple! There are only two items in the context menu in Safari they are: -View Source -Save Page As... If you open context menu on a link they are more: - new win - new tab - download - copy link - add bookmark If you click somewhere else it's different but it's always exactly depending on place you click. Notice the meaning of the word "context" menu!!! The look of Safari is really very clean and extremely useful at the same time. Also it's far more stable than Conqueror. I will be happy if Apple or someone else ports Safari to Linux or Windows, of course you can merge their great improvements if you wish. And spellcheck the name of the app, it will be one of the greatest improvements to Konqueror. Thanks for your efforts, and your great service! Without your efforts Safari (the best browser for the best OS) would not be possible these days! Many thanks also to Andras Mantia of Quanta, once he and his team implements the WYSIWYG mode for KHTML, Apple will be able to burn a fresh new HTML editor. Anton
What are you Smoking ? Forget about Apple... - Chris Spencer - 2003-09-19
Man put the crackpipe down... It's easy to be the best when you're not exactly writing anything. I openly acknowledge Apple's improvements on KHTML that everyone has been ranting on and on about, but it's much easier to come up with short term hacks. Don't forget that Apple writes code ONLY for it's OS - designed ONLY to run on it's own hardware. They don't have a fourth of the responsibility KDE has. The orginal code base is the hardest part to come up with, but of course a MacOS user wouldn't know, seeing how Apple didn't write the codebase for any of it's top products. The GUI is NeXTStep with a shiny new theme and icons, the kernel is the Mach from NeXT, the core of the OS is FreeBSD, and the browser is based on KHTML. Maybe you meant the best assembly of misc programming projects ?
Re: What are you Smoking ? Forget about Apple... - Anton Velev - 2003-09-19
Friend, Read some news. Apple has a great framework and platform, have you ever heard of Quartz, Chrome and Cocoa? What about the QT technology? And a number of state of art applications like iTunes, AppleWorks, Mail, iCal, iChat, etc etc. I agree that Apple uses the truly free open source projects for implementing closed source solutions but there is nothing wrong about it. And that's why I am saying thanks to kde people for KHTML and of course would thank FreeBSD people for their great UNIX. Btw are really doing a good things be in terms of open source freedom because they support only truly free sources, more than that they are freeing them from GPL - look what they did to KHTML it is now not dependent on the Troll GPL library that KDE is relying on. Thanks Again.
Re: What are you Smoking ? Forget about Apple... - anon - 2003-09-19
> KHTML it is now not dependent on the Troll GPL library that KDE is relying on. KHTML has always had little Qt depedencies. You need someone expert in porting to port it to other platforms though (yes, Apple's team was expert)
Re: I'll wait for 3.2... - Carlo - 2003-09-17
> Awesome. The latest 3.2 menu down to about 14 entries. 14 - did you say f o u r t e e n !?! I expect a usable context memu to have 6 to 8 entries, maybe 10, if it is relly necessary.
Re: I'll wait for 3.2... - Rayiner Hashem - 2003-09-17
Read the rest of the post :) It is a CVS version, after all, and 3.2 won't be out until December at the earliest. Heck, its almost getting usable now :)
Re: I'll wait for 3.2... - anon - 2003-09-17
well, opera has 16. Nobody complains. I think the notion 'bloated' also caused by the horizontal and vertical spacing. By horizontal spacing, I mean the space between phrase (e.g "back") and shortcut ("alt-back"). Whereas for vertical spacing, I mean the line spacing between line could be reduce. Just compare with Opera, 16 entries, but the context menu looks small/ compact.
Re: I'll wait for 3.2... - Rayiner Hashem - 2003-09-17
It's not a matter of size. Its a matter of numbers. Anything more than 7 or 8 is too many for people to remember. Once you get too many for people to recall at once, you suffer a giant slowdown because people now actually have to *read* the menu to use it. There is a reason why phone numbers are only 7-10 digits long in most countries, as are license plates. Nobody complains about Opera because not that many people use Opera where on dot.kde.org :)
Re: I'll wait for 3.2... - Jonathan Abbey - 2003-09-17
Mmm. There was a titanic flame fest when the Mozilla folks took the "back" menu item out of a lot of the Mozilla context menus.. seems that was one that a lot of people really did expect to be everywhere so that they could always right click and flick to go back. Instead, the powers that be at Mozilla.org were very concerned about the menu length, even though for those users used to using the context back, the context back was used 99 times for every time any other context menu item was chosen. I'd say that unless you're talking about the very top one or two items, the length of the menu isn't really that critical, as you'll still need to read the menu to see if you've moved down far enough for what you're looking for. Far better to have slightly longer menus than to right click to go back and find you've accidentally right-clicked on a transparent gif file and your trusty back reflex has turned into a useless 'View this <invisible> image' item.
Re: I'll wait for 3.2... - Rayiner Hashem - 2003-09-17
I'd say that unless you're talking about the very top one or two items, the length of the menu isn't really that critical, as you'll still need to read the menu to see if you've moved down far enough for what you're looking for. >>>>>>>>>>>>>> That's the whole point. You can keep the whole menu in your head if it is only 7-8 items long. If it goes bigger than that, you can't really keep any of it in your head without a lot of practice.
Re: I'll wait for 3.2... - Derek Kite - 2003-09-17
That is utter nonsense. The context menu is to have local access to commonly used commands, or to have access to local object specific commands. Indeed there may be some menu items that don't apply. And context specific ones can be improved. But to cut out menu items that are commonly used for good reason to meet some imaginary number goal is nonsense. It is an attempt to change user habits into what you think is the right way. I have two machines, one a laptop with some useless touchpad, and hard to see mouse cursor. I don't want to move the mouse any more than I need to. Usability suffers greatly if I have to scratch all over the screen to do things that are very very common in browsing. If fact that is one thing I dislike about the Mac. You are forced to mouse all over the place to do anything. I think it is a major design flaw in the whole system. Derek
Re: I'll wait for 3.2... - Navindra Umanee - 2003-09-17
Agreed. I'd really like to see View Source back too.
Re: I'll wait for 3.2... - Anonymous - 2003-09-17
It's a context menu, not a common menu. "View Source" is unlikly very very common in browsing. Either use accels, define a shortcut or change your local khtml_popupmenu.rc copy.
Re: I'll wait for 3.2... - Alex - 2003-09-18
Don't put View Source in context menu it does not belong there and isn't context sensitive is it?
Re: I'll wait for 3.2... - Metrol - 2003-09-18
It is VERY context sensitive when browsing frames. In that regard, it's one of the most context sensitive items in that menu.
Re: I'll wait for 3.2... - Rayiner Hashem - 2003-09-17
Take up the argument with the psychological community. They say human beings are good at remembering sets of only about 7 entries. As a layperson in the field, I'm inclined to believe them. Go beyond that limited, its much more difficult to remember any of the items in the set (ordering gets confused). Its not an "imaginary" number, but a hard-limit of how our brains are wired. It should be a familier concept to anyone who wroks in computer science. Make sure your data-set fits in cache, or the performance of your algorithm plummets. PS> Context menus are about easiest access to the *most common* actions on an object, not all possible actions on an object. Context menus can greatly increase efficiency when designed properly. When you go over 7 menu items, you make them nearly useless for what they're really good at, and only save some mousing, which could be reduced anyway by proper use of keyboard shortcuts.
Re: I'll wait for 3.2... - Carlo - 2003-09-17
Yes Rayiner, that's what I had in mind, too. On the other hand, Derek's point isn't that wrong; The problem is, that everyone has his own habits and opinion what should be in a context menu and what not. I for one vote for extending the file types with a context menu for each of them, with restricted default "values" and editable system wide and user local entries.
Re: I'll wait for 3.2... - anon - 2003-09-18
Well, usability generally is like that, therefore, you want to target the largest amount of your users and make something that's good for them.
Re: I'll wait for 3.2... - Rayiner Hashem - 2003-09-18
A stop-gap measure to a more "OO" way of handling context menus might be to make them a configurable (but auto-managed) thing like toolbars. Toolbars in KDE are pretty well abstracted (ie. they provide for configuration without causing a lot of extra checks in the code) and KDE would be unusable to me if they weren't configurable. Maybe something similar for context menus would appease those who have special preferences.
Re: I'll wait for 3.2... - Hollywood finochio - 2003-09-18
Eh, what's with this mantra of "more than seven items - BAD"? My keyboard has more than seven key! BAD. It must be badly designed. The alphabet has more than seven letters in it. BAD! Can't you see this should be cut? The designer of the alphabet should be eviscerated! Point is, it doesn't matter about your magical seven number. What matters is that the context menu provides the most commonly used commands that users require in any given context. Yes, we don't want hundreds of options in there, but neither is having a dozen or more so awful - least not when the mental peons are catered for by putting the absolutely most commonly clicked at the very top of the menu - back, forward, all that. They don't even need to look down the menu, but it is there for the rest of us. Konqueror is hardly any different to most other popular browsers in terms of the size of its context menu, so I think established opinion is on the side of that application's designers, and the usability freaks (the ones that want to shoehorn everybody into a horrid spartan vision that lacks all utility and requires 10x the legwork to get things done), well, they always have Apple with its (imo) limited GUI (and Gnome by the looks of it, when its ready, <EM>any time real soon now</EM>). Ugh! You just can't pluck some half-arsed psychological factoid out of the air and apply it willy-nilly as though its the One Rule to guide all UI design. I thought this silly attitude died with the early Apple-fanatics.
Re: I'll wait for 3.2... - anon - 2003-09-18
> Gnome by the looks of it, when its ready Actually, Nautilus 2.4 has more context menu entries by default than Konqueror does. However, it has more sane entries. Why do we need crap like "Add to bookmarks" in the file manager? Why I click on a link, I want options for that link, not "Back" and "Forward" and "Set Encoding" (those are fine if I click on blank space I guess) Note that Konqueror is more sane than other browsers.. I'm typing this from IE 5.2 for MacOSX which includes things like "Track page with Auctions Manager" and "Set home page" in it's popup menu. People set their home page in what??? once per year?
Re: I'll wait for 3.2... - Rayiner Hashem - 2003-09-18
Eh, what's with this mantra of "more than seven items - BAD"? >>>>>>>>>>>>> If you want context menus to be a real time saver, you'll make it easy for people to quickly remember the exact entries in the list. If you have more than about seven items (depends on the person) most people can't remember all the items, and they have to linearly search the menu looking for the item they want. My keyboard has more than seven key! BAD. It must be badly designed. >>>>>>>>>>>> How long did it take you to learn to touch type? How'd you like to do that for each app you use? Remember how slow a typist you were before you memorized the layout of the keyboard? That's what giant lists of actions are doing to the usability of your context menus. Given enough time and patience, people can memorize anything. People learn 2000 Kanji characters just fine, after all. But the human brain has a special ability to quickly learn and recall sets of 7-8 items. That's why you can remember all your friends phone numbers without even trying to learn them. There is no point wasting this ability. least not when the mental peons are catered for by putting the absolutely most commonly clicked at the very top of the menu - back, forward, all that. They don't even need to look down the menu, but it is there for the rest of us. >>>>>>>>>>>>> This has nothing to do with "mental peons." I'm not bitching about this in the name of "let's make things easier for newbies!" I'm bitching about this because the lack of real context menus kills efficiency. Also, you seem to have no understanding what a context menu is about. Why are back/forward/etc at the top, when they are right on the menu bar? Besides the all-inclusive main menu, there are three access methods: toolbars context menus hotkeys These are all different things optimized for different uses and used for different purposes! They are not interchangable. Konqueror is hardly any different to most other popular browsers in terms of the size of its context menu, so I think established opinion is on the side of that application's designers >>>>>>>>>>> If by popular browsers you mean Internet Explorer, then yeah, Konqueror is no different. However, Microsoft is known widely for their horrid UIs! If you include other major browsers, you're just plain wrong. Mozilla's page context menu has 10 entries, and its link context menu has 9 entries. Its pushing it a little, but its usable. Most of the Mac browsers (again, aside from IE) have about half a dozen items in their menus. So the established opinion is most definately *not* on the side of large context menus, unless you want to do the judging by sheer numbers, in which case we might as well just make a WinXP clone... Ugh! You just can't pluck some half-arsed psychological factoid out of the air and apply it willy-nilly as though its the One Rule to guide all UI design. I thought this silly attitude died with the early Apple-fanatics. >>>>>>>>>>>>>> Its not a "half-arsed psychological factoid." Its a generally well-understood principle of UI design. UI design, in all its forms, is a science. There are researchers who study not only computer UI design, but all human-machine interfaces, such as in industrial design, etc. This is what they have come up with. Also, the guideline about keeping context menus as short as possible is in the Gnome, Apple and Microsoft HIGs. You're free to disagree with it, but please provide some evidence that would make us believe that *all these other people are wrong*.
Re: I'll wait for 3.2... - Dawnrider - 2003-09-18
The point is this... Learning the complete layout of a context menu is daft. If you really feel masochistic enough to do it, then you won't mind if there are 8 or 12 entries, or whatever. Moreover, if you have fully context-specific menus that change for links, files, pages, images, embedded objects, etc. Then that entirely breaks your learnt layout. Users are perfectly capable of reading the words in a context menu, moreover, context menus are there for power users, not the people who can barely open a browser and who can't master a double-click. Power users can read. Sure, reducing the menu does make reading is slightly faster, but users who use the menu enough to remember the entries are also capable of skimming-reading the menus fairly quickly. Typically the time for the eye to find the menu is more than the time to read. Moreover, Konqy does well through using separators to segment the different types of item and adding icons for common tasks. 12 items in Konqy is worth 8 anywhere else for those reasons. Actually, when it comes to the human brain, the brain prefers smaller sets than 7 or 8. Ideally, groups of 3 or 4, and then about 3 or 4 groups. Higher numbers are gained easily through associativity, such as the icons in the context menus. I think you need to appreciate, when you talk about productivity, that context menus are a minute issue in comparison. You say that Microsoft produce terrible UIs. Sometimes they do, but often they don't, at least not at the application level. their problem is that they make it hard to navigate between applications, control panels, etc. and make it a pain to find things. Microsoft, ultimately have produced basic software that fulfills a set of needs. It allows people to operate fast enough. No-one cares if it takes you 0.5s to read a context menu instead of automatically clicking the 5th entry for whatever you want. That time is dwarfed by reading the document, examining the images, getting interrupted by phone calls, going for a cup of tea, making a note on a piece of paper, creating a new file to store some text to copy and paste, and many other things. To be honest, OSX has short context menus, and they are absolutely useless for the power users they are meant to be addressing. How does it help me as a user of Safari if when I right click I get three options and the ones I wanted are elsewhere? Gnome is doing the same thing, and it is stupid. I want the context menu to hold the entries that I need for a task, and if it doesn't, then the entire idea of saving me the effort of going all the way up to the menus and digging out the correct entry is rendered a lie. Moreover, if entries aren't in the context menu, and you expect them to be there and go looking for them, then you also achieve a penalty, because after an exhaustive search, you have to go and look in the main menus afterwards. On balance, it is better to have all of the options *people reasonably expect* rather than a trimmed down menu. What are those options? They are the ones that are already there and people find useful, and an averaged set of ones from other browsers, most especially IE. We have to remember that the people coming to using the context menus are not brand new users who've never touched a mouse before. They are people who will almost always have experience of other browsers. Changing the menus to exclude things they need will cause them massive disruption. It's not a case of duplicating IE or windows XP, but it is a case of having a sane range of options and at least enough nods to WinXP that people migrating feel fairly at home. And for what it is worth, HIGs can be useful and they can be worthless. It depends on the audience and what the application/DE/OS wants to achieve. The ultimate trouble with usability studies, is that it only tests given users (who are at a given state, based on social factors and past exposure) with existing methods and applications. You then use this to try and inform future development, but by the very nature, sticking to the results of a usability study religiously prevents you from doing things in imaginative ways. The same is true of HCI books. It is trying to deduce trends in a snapshot of computing life, where the new moment has rendered portions of the work obselete. It is hard to truly derive long-term trends. At the moment, I personally would ask that developers spend very little time on the context menus, and instead make sure that for example KWord never crashes and loses people's work (not having a dig, btw... it's purely hypothetical), that IMAP support in KMail works properly, so that users don't have to rely on POP and drive to the office at night when they realise they forgot to turn off their mail client, which is grabbing all their e-mail that they need for tomorrow's report. There are a hundred things which are better to spend time on than Konqy's silly context menus.
Re: I'll wait for 3.2... - Rayiner Hashem - 2003-09-18
The point is this... Learning the complete layout of a context menu is daft. If you really feel masochistic enough to do it, then you won't mind if there are 8 or 12 entries, or whatever. >>>>>>>>>> You don't really seem to understand here. The whole idea is that yes, memorizing the items in the context menu *is* daft. But if there are only 6-7 items, you don't *have* to memorize it. Your brain just picks it up in the process of using it. There are all sorts of effects at work here, not just number, but location. When you have just a handful of items, its easy for your muscle memory to tie the important ones to the beginning or end of the menu. When you have 14-15, most are just in the middle, and your muscle memory fails. Moreover, if you have fully context-specific menus that change for links, files, pages, images, embedded objects, etc. Then that entirely breaks your learnt layout. >>>>>>>>>>>> No it doesn't. Human beings are incredibly adept at doing things like this. From what I understand, the number of sets learned is not very important, but the size of each set is. Its much easier to remember, for example, 10 sets of 3 items then to remember 3 sets of 10 items. Users are perfectly capable of reading the words in a context menu, moreover, context menus are there for power users, not the people who can barely open a browser and who can't master a double-click. Power users can read. >>>>>>>>>>>>> Yes, context menus are there for power users. Power users like efficiency. Scanning a linear list of words is a very slow process for humans. Flicking your wrist in a learned reaction is much faster. Typically the time for the eye to find the menu is more than the time to read. >>>>>>>>>>>>>> With small menus, your eye doesn't need to find it. That's the whole point of making them short! Your fingers do all the work. I think you need to appreciate, when you talk about productivity, that context menus are a minute issue in comparison. >>>>>>>>>>>>>>>> It depends on how you use the UI. I'm a twitchy user, I do most things through keyboard shortcuts and context menus. For me, bad context menus are a big productivity loss. But overall, yes, its a relatively minor (though not minute) issue. But if we're going to bother to do context menus, let's do them right. Microsoft, ultimately have produced basic software that fulfills a set of needs. It allows people to operate fast enough. >>>>>>>>>>>>> I didn't realize we were going for just "good enough." Well shucks, then, why don't we all strick with Win 3.1? I mean, that's good enough for the e-mail/word-processing/etc that most people do! No-one cares if it takes you 0.5s to read a context menu instead of automatically clicking the 5th entry for whatever you want. >>>>>>>>>>>> 0.5 seconds is an eternity. That time is dwarfed by reading the document, examining the images, getting interrupted by phone calls, going for a cup of tea, making a note on a piece of paper, creating a new file to store some text to copy and paste, and many other things. >>>>>>>>>>>>> Your net time lost is probably more than you think. The effort you're spending reading those context menus disrupts your thought process. This is why, for example, I prefer to use Vi for coding rather than a GUI editor. Since I know all the commands and shortcuts and whatnot, I never have to stop thinking about the code. Also, even if the net time saved isn't that much, its these little inefficiencies that make the computing process much less enjoyable.
Re: I'll wait for 3.2... - Roberto Alsina - 2003-09-18
That stuff about seven items lacks a qualifier. People has trouble remembering sets of over seven ARBITRARY items. Like "apple, dodge, bird, zuul, 4, mother, mars". It is absolutely trivial to remember larger sets if they are related. In fact, you don't have to remember the menu options at all. You want to do something to a thing in a page, then right click and it's there. What's there to remember?
Re: I'll wait for 3.2... - anon - 2003-09-17
Right now I'm working on a patch to implement #53772 -- making sure Konqueror's context menus are CONTEXT sensitive. Should have it ready soon. Should whack 4 or 5 enteries from links/images in html pages, and a few from icons in file manager modes. http://bugs.kde.org/show_bug.cgi?id=53772
Re: I'll wait for 3.2... - Alex - 2003-09-18
That sounds great, i always thought that context menus should be CONTEXT sensitive and not just the most commonly used items. I am defintely looking forward tos eeing your patch in 3.2 ;)
Re: I'll wait for 3.2... - Anonymous - 2003-09-17
> There is a reason why phone numbers are only 7-10 digits long in most countries Not every ant has telephone?
Re: I'll wait for 3.2... - Micha - 2003-09-19
Here it's 19 !!!
16 not 19 ! - Pat - 2003-09-19
sorry but Kmldonkey, Kgpg and k3b are not native kde apps. so that brings it down to 16 :-p
Re: I'll wait for 3.2... - Jason - 2003-09-19
You do not seem to be running 3.2/cvs When clicking on blank spots in html pages, Up has been removed, "Open in New Window/Open in background tab/Open in New tab" have been replaced with "Duplicate in New Window/Duplicate in New Tab". "Add to bookmarks" has changed to "Bookmark this page", "Copy To" has been removed, "View Document Source" and "View Document Information" have been removed. The k3b/kgpg/kmldonkey actions, as well as Open With, are now submenus. I'm not sure why "Stop Animations" and "Preview In" are still in the context menus in HEAD however. The latter seems inappropriate for http pages (is good for local files I guess.. perhaps move it to a submenu under "Actions" ), and the former isn't used much anymore (still is in menus for ppl who use it.)
Re: I'll wait for 3.2... - clee - 2003-09-18
For what it's worth I disagree quite strongly with the removal of "View Document Source" from the context menu. However, since there are people who are actually defending this action (yes, I'm looking at YOU aseigo ;) you can fix it locally by downloading this file from my site: http://c133.org/files/khtml_popupmenu.rc Download it, check it out and make sure it isn't a virus or an evil shell script, and then once you're satisfied that it's just a benign config file, drop it into ~/.kde/share/apps/khtml/ and be amazed at how much cleaner your context menus are in KHTML! -clee PS: No, Aaron isn't responsible for this one. That goes to Stephan Binner. Complaints about this will not be very visible here on the dot, but if you want to make yourself heard, why not send an email to binner @ kde.org to let him know that you use 'View document source' in your context menu?
Re: I'll wait for 3.2... - binner - 2003-09-18
> That goes to Stephan Binner. Complaints about this will not be very visible here on the dot This can IMO be read like that I would delete comments I don't like. This is not the case. > why not send an email to binner @ kde.org to let him know that you use 'View document source' in your context menu? Campaigning instead of arguments will not help.
Re: I'll wait for 3.2... - anon - 2003-09-19
Completely disagreed. View source should stay in the menus, and not the context menus. If we have view source, let's put in more frequently used items than that like close window into the context menu!
Re: I'll wait for 3.2... - Anonymous Monkey - 2003-09-17
If you want to permit root logins by anybody through KDM, sure. Here, I think we'll update since our configuration is definately vulnerable. I'd suggest you at least read the advisory...
Hooray - Anonymouse - 2003-09-17
That godawful-irritating horizontal scrollbar bug (http://bugs.kde.org/show_bug.cgi?id=61730) was also fixed, though it didn't get a mention in the changelog. Sooo happy!
Re: Hooray - Brent Cook - 2003-09-17
That was fixed in 3.1.3a or somesuch. Look here: http://www.kde.org/info/3.1.3.php
Re: Hooray - André Somers - 2003-09-17
It _is_ mentioned in the changelog. Look harder... (OK, it took me some time to find it too) :-)
feature request - ac - 2003-09-17
One thing I do wish is that the tabs in Konqueror would stop changing size all the time. It seems to be a bit worse in 3.2 than 3.1 because even the main tab changes size.
Re: feature request - Haakon Nilsen - 2003-09-17
Posting feature requests here is pretty useless. I'd submit wishlist items to bugs.kde.org instead (just make sure it's not already been wished for).
Re: feature request - J - 2003-09-18
bugs.kde.org is a pretty useless place for open, public discussion. Some would rather wait and discuss than rashly dump a slew of undiscussed comments into bugs.kde.org. take care, j
Re: feature request - Jeff Johnson - 2003-09-18
>bugs.kde.org is a pretty useless place for open, public discussion. That's the advantage. Most people do not want to be bothered with discussions about details, especially as long as there is no working code. If you want to implement a significant change, post it to the appropriate mailing list before. If you have a patch, post it to the mailing list. But please do not increase the noise level for every feature request...
Re: feature request - kabouterplip - 2003-09-17
There's a patch for that in qt-copy/patches .. (still doesn't work like it should though, but it's a bit better)
Re: feature request - Anonymous - 2003-09-17
The OP is not talking about flicker.
Re: feature request - kabouterplip - 2003-09-18
I'm not talking about the flicker either.
Re: feature request - Anonymous - 2003-09-18
So you're talking about a patch against Qt to fix/revert a "tab size problem" implemented as feature in Konqueror code? Now, that makes sense ;-)...
Yesss! but i will waiting KDE 3.2 - Teddy W Laksono - 2003-09-17
Yesss, but i will waiting the KDE 3.2 in this last year, and i hope KDE to be faster, couse sometime running KDE more slowly than WindowsXP in the same hardware system :(, and wish the help documentation more complete. Teddy
Re: Yesss! but i will waiting KDE 3.2 - anon - 2003-09-17
Unfortunatly, there is too few people working on docs. The good news is that it requires very little technical skill to contribute! Hope that if you have time, you'll contribute :-)
Re: Yesss! but i will waiting KDE 3.2 - Rayiner Hashem - 2003-09-17
3.2 is very fast. KDE has been pretty fast for me for awhile now, but with the 3.2 CVS versions, its about as fast as XP. The only real performance hits are for application startup (I can't use prelinking because of the NVIDIA drivers) and redraw in applications with complex canvases (like Konqueror, though Konqui is one of the most improved apps in 3.2 :)
Re: Yesss! but i will waiting KDE 3.2 - Mark Hannessen - 2003-09-17
prelinking.... i like that word! how do you do it, what does it do and is there really much performance gain.
Re: Yesss! but i will waiting KDE 3.2 - Tom - 2003-09-17
Have a look at this document: http://www.gentoo.org/doc/en/prelink-howto.xml It's intended for Gentoo, but other than the instructions on how to install the Prelink package itself, everything else applies. Personally, I did it, but didn't notice much gain. And then I realised that I had wasted 30 minutes setting it all up, when I really don't mind waiting a couple of seconds for KMail to apear ;-)
Re: Yesss! but i will waiting KDE 3.2 - Johan Veenstra - 2003-09-17
Why can't prelinking be used in combination with NVIDIA drivers?
Re: Yesss! but i will waiting KDE 3.2 - Rayiner Hashem - 2003-09-17
Because the NVIDIA binary drivers (specifically, the libgl) are compiled in a way that makes it impossible to prelink anything that links with them. This includes Qt, which links to them for QtGL.
Isn't prelinking overrated? - anonymous - 2003-09-17
According to this paper: http://objprelink.sourceforge.net/ you would only get a few milliseconds better startup times compared to the combreloc method already present in the linker. Check at the bottom were Konqueror starts at 2.80 versus 2.66 seconds.
Re: Isn't prelinking overrated? - Mark Hannessen - 2003-09-17
yep, and their is a lot of "WARNING !!" and "BEWARE !!" thingys on their site. and perhaps even more importend: objprelink2 does not currently work with gcc-3.x. so i guess it won't be really that usefull right now.
Re: Isn't prelinking overrated? - yg - 2003-09-17
this is actually the prelinking tool: http://freshmeat.net/projects/prelink/ objprelink is deprecated
Re: Isn't prelinking overrated? - anonymous - 2003-09-17
Ok, but the paper states: The runtime linking time now represents only a small part of the KDE3 application startup time. Large speedups are to be found elsewhere. How much more time can you shave off with the new tool?
Re: Isn't prelinking overrated? - Rayiner Hashem - 2003-09-17
Not really. Objprelink is somethink seperate from the Jakub Jelnik's *real* prelink. Prelink does help. On my 2GHz P4, (using LD_DEBUG=statistics) starting Konsole results in a linking time of a little over 0.2 seconds. Prelinking would bring that number almost to zero. Human response time is about 0.3 seconds. So the linking step already chews up 2/3s of the time you have to make application startup appear instananeous.
Re: Isn't prelinking overrated? - J - 2003-09-18
Did you remember to flush your memory so that the app was not cached when you ran your second test? I doubt its really that glamorous...
Re: Isn't prelinking overrated? - Rayiner Hashem - 2003-09-20
Actually, when I tried prelinking the first time (a couple of months ago) it showed a 99% reduction in linking time, from about 0.4 seconds to something like 0.01 seconds. But it fubar'ed my system, so I had to reinstall. Does that count as clearing the memory? But my original point is that linking time is still significant --- it is already known that prelinking almost completely eliminates linking time.
kicker/kasbar problem - thefrog - 2003-09-17
Does anybody know whether the bug 53735 (menu extensions, i.e. kasbar don't have transparent background) has been fixed? This annoying thing comes up in every version since 3.1.1 -:( regards rainald
Re: kicker/kasbar problem - Chris Howells - 2003-09-18
If it's not marked as fixed on bugs.kde.org, then it isn't.
Re: kicker/kasbar problem - Richard Moore - 2003-09-18
It's not fixed. I wrote a new rendering system for kasbar that fixes this, but I still haven't had a chance to merge it into the CVS. Rich.
Re: kicker/kasbar problem - thefrog - 2003-09-19
You will have at least one admirer for this ):- I tried to find out the reason for this bug for myself, but I didn't had success yet -(: regards rainald
Re: kicker/kasbar problem - anon - 2003-09-19
I really hope you do.. I used to use kasbar a long time ago (kde 2.1??), and I loved it. I had to stop using it because of the above mentioned problem. :( Hope you find time to merge it! (and if not, get someone else to, *snicker*)
Now what about fixing some old bugs? - noj - 2003-09-17
The oldest unassigned bug in konqueror -- reported almost three years ago: http://bugs.kde.org/show_bug.cgi?id=12994 More missing CSS: http://bugs.kde.org/show_bug.cgi?id=26326 (note that this is CSS1 -- without support for this basic property Konq's claim to support 100% of CSS1 is incorrect) Pathetic handling of PNGs (frequently valid images are inverted or even blank): http://bugs.kde.org/show_bug.cgi?id=16395 (note that this has been around since before KDE 2.0!) http://bugs.kde.org/old-bugs-statistics.cgi?tops=15&ids=20912 -- konqueror still has 13 bugs that were reported before KDE 2.1, and 45 from before KDE 2.2.
Re: Now what about fixing some old bugs? - Stephen Douglas - 2003-09-17
Let us know when you've fixed them, then.
-1 unhelpful - noj - 2003-09-17
'So fix them, then' is a sneering, pointless answer. Try again, using your brain this time.
Re: -1 unhelpful - Stephen Douglas - 2003-09-17
That's because it was an answer to a pointless, sneering question. Yes, there's a bug in there since 2000. But how likely is it that Konqueror/KHTML developers are unaware of it? Maybe if you'd asked if any progress had been made, or if people were looking at it, or whatever. But your question was more of a demand that somebody fix it.
Re: -1 unhelpful - J - 2003-09-18
Our demands are less than or equal to the overriding praise and publicity that KDE e.V. and friends spew forth about its greatness.
Re: -1 unhelpful - Stephen Douglas - 2003-09-18
And this is a rational statement, intended to persuade people to fix some of those bugs?
Re: Now what about fixing some old bugs? - anon - 2003-09-18
> http://bugs.kde.org/show_bug.cgi?id=16395 Can't be fixed until qt 4.0
Bugless by KDE-4.0 - Mystilleef - 2003-09-17
Seriously, after KDE-3.2 is released, I think we should devote a year to squashing bugs. It will be wonderful if one of KDE's mission/objective will be to be bugless by KDE-4.0. Now, I know I'll be flamed for this proposition, but let's fix things before adding new items. It really doesn't make sense releasing software with thousands of bugs. I understand KDE is an enormous project let's be a little more paranoid about bugs. There should be a policy not to add features to a package until all/most bugs in the package are squashed. Yes, I said it. *awaits the flames* P.S. Wishes and Requests do not count as bugs for the purpose of this rant.
Re: Bugless by KDE-4.0 - kabouterplip - 2003-09-17
Here's what I want: - Less bugs (how obvious..) - More solid desktop feeling (current KDE desktop doesn't feel solid - ie. flickering rubberbanding, flickering icons, ugly flickering xor-rects instead of translucent icons when dragging, flicker here, flicker there) - More UI improvements (not just reordering the widgets or adding 20 options to each dialog) - More professional programming API's (ie. well chosen method names, use of design patterns, namespacing, etc) - Optimizations (use of memory, runtime speed, etc) - Use of REAL context menus - Death to all geek themes (Motif fluff and themes like that) - Death to all the old pre-KDE3 icons (everything should be Crystal, more consistent) - Death of all (or at as much as possible) ugly hacks inside kdelibs, kdecore and kicker - Death of the many duplicated KWidgets (using QWidgets instead) which are only causing problems later on (ie. KStyle makes some Qt styles flaky (including the QtWindows style)) I'm affraid that last one won't happen, bad decision.. (even the guys at the Gtk/Gnome projects have seen the light and have started making everything use Gtk for the UI and no more Gnome specific UI fluff, except for common desktop dialogs and things like that) Oh, and I want lots of $$$ and make a trip to Mars. But I'm affraid that won't happen either.
Re: Bugless by KDE-4.0 - Janne - 2003-09-17
"It really doesn't make sense releasing software with thousands of bugs" Yes it does. Or are you saying that past KDE-releases were pointless and/or senseless? You would rather have KDE-team polish up KDE1, instead of releasing KDE2 and KDE3? Because that is what would have happened. Right now we might be running KDE 2.0, but it would be relatively (since you can't really eliminate all bugs) bug-free. Is that what you would want? Even if KDE was released 100% bug-free there would still be bugs there, they would just be unreported.
Re: Bugless by KDE-4.0 - Mystilleef - 2003-09-17
Sir, your last statement contradicts itself. And what makes you think that we would still be using KDE-2 right now if KDE-1 is bugless. Contrary to your mentality, bugs retard the development process, it doesn't spur it. Yeah, perhaps when the bugs increase to 10000 by KDE-4.0 it will begin to make more sense.
Re: Bugless by KDE-4.0 - ac - 2003-09-17
"Sir, your last statement contradicts itself." Why is that so difficult to understand? Even if KDE would be released bug free (as in: no bugs left open in database), there still might be (and surely would be) bugs in KDE which just would be discovered after release (when a lot more people would be using it).
Re: Bugless by KDE-4.0 - Janne - 2003-09-18
We would be using KDE2 right now, because the rate of developement would be so slow. Since developers would focus about 98% of their time to fixing bugs, there would be very little advancement of features taking place. Therefore the rate of developement would slow down and so would the functionality of the desktop (as in, we would be using KDE2 by now, instead of KDE 3.1.4). you can't add features and rewrite the code if all your time is being taken by bug-hunting. Also, you need to consider that it's more fun to add features than kill bugs. Your "bug-free KDE" would propably have alot less developers than current KDE does. users would notice that KDE isn't moving anywhere and they would vote with their feet and move to Gnome or some other desktop. KDE would die, but hey, at least the corpse of KDE would be bug-free!
Re: Bugless by KDE-4.0 - J - 2003-09-18
Myth. Been here: http://c2.com/cgi/wiki?RecentChanges lately?
Re: Bugless by KDE-4.0 - Matej Cepl - 2003-09-18
And what? I mean, how wrong it would be if we have less buggy KDE 2.0? I would actually prefer it. Matej
Re: Bugless by KDE-4.0 - Janne - 2003-09-19
Would you rather use less buggy (than it really was) KDE 2.0 or current KDE 3.1.4?
Re: Bugless by KDE-4.0 - André Somers - 2003-09-17
Go ahead, sponsor a (team of) KDE developer(s) to clean out all bugs. As most of the current KDE developers are doing it in their spare time without any payments, they are bound to be working on stuff they are interested in. Bughunting is not much fun, although I agree it's nessecairy.
Re: Bugless by KDE-4.0 - Mystilleef - 2003-09-17
I'm giving an all I can to the KDE community at the moment. If I could sponsor a team of KDE developers to clean out bugs I would, unfortunately I can't and that's besides the point. While the developers valuable efforts are much appreciated, with the right policies we could encourage them kill bugs relating to their apps before they commit sizzling features of interests to them. Bughunting is as much of the development process as testing and coding. Or perhaps, I'm being idealistic again.
Re: Bugless by KDE-4.0 - Haakon Nilsen - 2003-09-17
Make that "pretentious". You obviously don't contribute to KDE in the way of code, and yet you try to lecture the ~200 regular contributors about the best way to approach KDE development. Just appending "I'm oh so grateful, by the way" does not give you this right to mock.
Re: Bugless by KDE-4.0 - Mystilleef - 2003-09-18
I find your response repugnant and insulting. Even if I don't contribute to KDE in the way of code, couldn't there be other means I could contribute to KDE? First you insult my integrity then you *mock* my contributions to KDE because I don't provide code to the community. I guess the only way I can contribute suggestions to is if and only if I'm a coder, right? And when did I need to provide code to be a bonifide member of the community. If you do not agree with my suggestion there other less rude ways to state you point, rather than attack me in person. I'm not here to lecture anyone. You can agree with my suggestion, disagree with it or just shut up. Good day.
Re: Bugless by KDE-4.0 - Anonymous - 2003-09-18
" And when did I need to provide code to be a bonifide member of the community. " You don't. The KDE project is not just developers. It's programmers, doc writers, helpers, artists, and even layabouts giving suggestions :) As someone who *does* code and contributes semi-regularly to KDE, I'll have to say that although programmers are probably the single most important part of the __development__ of KDE, the KDE project itself would have gone nowhere fast without anybody else besides programmers.
Re: Bugless by KDE-4.0 - Alex - 2003-09-18
he did not say that! He just said that he doubts that you are qualified enoguh to give an objective and helpful answer about what KDE should focus on in their development process. Of course there are many ways to contribute to KDE and they are all much appreciated. kde.org/support
Re: Bugless by KDE-4.0 - J - 2003-09-18
So we've boiled down the KDE community down to a select few? Elitism? "The few, the brave". If your name is not on the NOC list, your opinions don't apply! Leave promptly to your left. Thank you!
Re: Bugless by KDE-4.0 - Daniel Molkentin - 2003-09-18
The rule has always been: "Who contributes, decides", because it can't work differently when you are dealing with free software. Why do you think people would implement your vision of something if they don't agree in their spare time? Either go and do it yourself or pay someone do to it for you, but don't expect the KDE Developers to be your personal code drones. And "Contribution" is not equal to "hacking". there are a lot of things non-developers can do. Check out Aarons' WhatsThis tutorial for an example, artwork, translation and documentation for others. Contribute! Make yourself a name, be reasonable. That's what will get you respect in discussions. KDE is no exclusive club. But people that keep demanding things while never contributing anything start to be annoying after a while. How would you react when you give out chewing gums to a kid and then the kid comes back every day expecting a new chewing gum with a new flavor and when you don't react it sits down and cries until you get him one? I hope you get the point. Contributors and bugreporters are welcome, whiners not. Cheers, Daniel
Re: Bugless by KDE-4.0 - ac - 2003-09-18
> Contributors and bugreporters are welcome, whiners not. Fully ACK. A year without no features and just bug fixes would probably even cause many contributors to lose interest in KDE and stop developing for that year. I probably would. Thank god that KDE doesn't really have a central authority that sets broad ranging policies like that.
Re: Bugless by KDE-4.0 - James Richard Tyrer - 2003-09-18
I think that you miss an important point. Software needs to be designed -- it must do the proper things. If we take your paradigm that 'he who writes the code decides' in that context it must mean 'he who writes the code designs it'. So suppose then that the 'he' got the design wrong. If we follow your idea; if someone else is capable of clearly stating exactly what the code does wrong and how it should work, then are you saying that this information has no value -- that it would not be a contribution because that someone didn't write the code? Designing something is not trivial. There is (or should be) a place for people that can only contribute by designing. -- JRT
Re: Bugless by KDE-4.0 - anon - 2003-09-19
> Designing something is not trivial. There is (or should be) a place for people that can only contribute by designing. Sure, but remember that open source != real/commercial world. Open source software is driven most by people who contribute in a physical manner. That means actual coders, doc writers, translators, artists, etc... People who contribute in a non-physical manner (designers, bug reporters) are also greatly appreciated by open source projects. The KDE project greatly appreciates them. However, unfortunatly, they aren't simply going to have as much influence compared to physical contributors. The KDE project is not a company where the non-physical contributors can force the physical contributors to do something (e.g, managers/project leaders, etc.. in a company compared to programmers, artists, etc..)
Re: Bugless by KDE-4.0 - Thomas - 2003-09-19
This is the strength of OpenSource (and at the same time its weakness)... ! Imagine a major car manufacturer, where the management fires itself and only the engineers decide what's cool and what's going to production.... heck, sometimes I wish it would be that way (even if I would have to learn a few more buttons and the tutorial would always date 2 years back..., but it'll be worth it) O.k., they tell you the car would be way too expensive and just too 'geeky' for the average user..., well be it that way: average cars for average people
Re: Bugless by KDE-4.0 - Jilks - 2003-09-19
> ...remember that open source != real/commercial world. Since when? I thought I was /really/ using this software. I also thought that most distros /really/ sold OSS. Must have been a dream....
Re: Bugless by KDE-4.0 - anon - 2003-09-19
Alright, I should have said, "KDE is not developed like a typical commercial application"..
Re: Bugless by KDE-4.0 - Chris Howells - 2003-09-18
> Even if I don't contribute to KDE in the way of code, couldn't there > be other means I could contribute to KDE? Oh sure... documentation... art work... about a million other things. > I guess the only way I can contribute suggestions to is if and only > if I'm a coder, right? If you're going to critiscise the coders then I think it would be prudent if you because one of them first. Nearly everybody works on KDE in their spare time because they enjoy it. You have to understand that implementing features is fun. Fixing bugs -- while vital -- isn't quite so fun. If you think you can try and make everybody only fix bugs for a year then you are at best misguided.
Re: Bugless by KDE-4.0 - ac - 2003-09-17
Postpone KDE by one year and GNOME will come and kill you dead. Guaranteed.
Re: Bugless by KDE-4.0 - anon - 2003-09-17
GNOME 2.4 already is far behind 3.1 except in a few areas. Remember that there was a huge lull in GNOME development from 2001 to 2002 because of gnome2 development.
Re: Bugless by KDE-4.0 - Tom - 2003-09-17
Why? KDE had a lead on GNOME, yet GNOME didn't die. Xfce, Xpde, Windowmaker, Fluxbox and many other DEs/WMs are still around. I don't get this "KDE vs. GNOME" mentality so many seem to have here at the dot. They are both great products, and they both do some things better than the other. Let's just leave it at that, and work towards better versions of KDE, OK?
Re: Bugless by KDE-4.0 - anon - 2003-09-17
So? As long as you make regular KDE releases that's fine.
Close - Alex - 2003-09-18
KDE does have far too many bugs but releasing a bug free product is just about impossible and would take many years of development, developer swould quickly lose interest and so would users because amny bugs are obscure and so msot won't even notice that they were fixed. KDE would be great if it just slipped from 5,000 bugs to sub 2,500.
Re: Close - Anonymous - 2003-09-18
> KDE would be great if it just slipped from 5,000 bugs to sub 2,500. Let's assume every second bug would be fixed but none of them would have ever affected you or would have been noticed by you: You would still be moaning. Summary: Only bugs which affect you currently matter, not numbers of reports of everyone collected over all time.
Re: Bugless by KDE-4.0 - James Richard Tyrer - 2003-09-18
I think that I said something like that after 3.1.0. Actually, I suggested a paradigm shift so that the development tree configuration favored fixing bugs over developing new features. This was posted to the: "kde-devel" list and all I got was flamed. :-( -- JRT
Re: Bugless by KDE-4.0 - Derek Kite - 2003-09-19
The best way to not have any bugs is to not have any users. Look at the list of bugs per module. It is highest with the modules that are used the most. That means release often, even release broken. Bugs get found, the critical ones get fixed first. The coders are constantly refactoring. The design process is to write code, throw away. Very efficient, producing very good quality code. Derek
Re: Bugless by KDE-4.0 - Eric Laffoon - 2003-09-20
KDE 3.2 was shifted to a focus of taking more time to work on bugs and the release schedule was taken off track until it reached particular levels of bugs. For our module we had low bugs and we got to spend more time working on features. Others may have chosen to take the time to work on features and perhaps even at the expense of bugs. That's because the process sets up to freeze what you can do for the purpose of fixing those bugs. Bug fixing is a matter involving a lot of factors, but procedure makes more difference than policy. The current system is procedurally very rational. New major point releases end up being incremental with less bugs being able to be introduced. Perfection is a noble aspiration, but often a very irrational goal when placed in context. Theoretical perfection is the extremely small percentage gain from the high percentage effort that insure stagnation, extremely long development cycles, user and develeper frustrations and lo and behold... you get bugs anyway. We have set our objective to realize an average 10 or less bugs, which has cost us features, and strangely enough obvious bugs occasionally crop up months after a release because testing becomes very difficult. A simplistic approach to clean software is not going to work. Nor is it going to happen without a lot of users being involved running CVS HEAD, which they are attracted to for new features.
Re: Bugless by KDE-4.0 - Mystilleef - 2003-09-19
Today, I have witnessed elitism among the KDE team. I'm as disgusted as I am disappointed. Because I do not possess proficient coding skills and I do not contributed code directly to the project, I've been labelled as second-class contributor and as such, my suggestions, which another member termed whining, are almost worthless, or carry less weight than that of a KDE coder. Way to go friends, you definately attrack more enthusiasm with this attitude. May KDE continue to filled with bugs. I'll take my second class contributions (AKA whining) where they are better appreciated and needed. Are you kidding me? It is acceptable for KDE to ship with thousands of bugs?
Re: Bugless by KDE-4.0 - Anonymous - 2003-09-19
For my part I don't take user comments serious which don't state "I actually use KDE and find it buggy" but do say "I have looked at Bugzilla statistics and find KDE unreleasable". And I wonder if this is KDE specific because I don't see such statements on gnomedesktop.org while GNOME has a comparable amount of issue reports. Perhaps it is because of the same impression like mine that here more developers participate in the comment section and users think they can change something with constant whining.
Re: Bugless by KDE-4.0 - Mystilleef - 2003-09-19
I don't care about gnomedesktop.org. If I had issues with gnome, I'd know where to *whine*, thank you. Well since you don't take users comments seriously, why don't you stick to the kde-devel mailing lists for now. I believe dot.kde.org is a forum where kde users are updated on the progress of KDE and share their comments, or whining as some of you put it.
Re: Bugless by KDE-4.0 - Debian User - 2003-09-19
Hello, for the KDE developers it's the fun that makes them develop KDE. Are you trying to kill the fun for them? You ideas of imposing policies on developers that the developers don't find themselves necessary is arrogant at least. It can be explained by ignorance only. In fact some people fix bugs, some create new features and it all works out well. Many new features like kwin rewrite fix very old bugs. So what's in bugs: 1. Bugs about new features which are obviously not too important anyway. 2. Bugs about khtml. Everybody seems satisfied with the rendering of Konqueror, only few sites don't work. Yet this creates like 1000 bug reports. I don't care. Since when would missing compatiblity to Mozilla and IE bugs be a problem? The standard pages work fairly well already. 3. Bugs about very special situations. How many bugs are about styles that few people use. The default style Keramik works bug free. That's what matters. 4. Bugs about non-completed designs. Some things are still inconsistent because redesigns are pending but not done yet. 5. Bugs that are plain wrong. The count is big, but I won't even notice many myself ever. Even more are unreported. What you people don't get is: KDE has a lot more testers now. KDE has a lot more applications and expectations now (like rendering everything perfect in khtml). So more bugs get reported and found because we have a bigger community now. The bug count will only increase from now on just for this reason. Stop killing the fun of others that develop KDE. Yours, Kay
Re: Bugless by KDE-4.0 - gdg - 2003-09-19
Again He just said that he doubts that you are qualified enoguh to give an objective and helpful answer about what KDE should focus on in their development process. Of course there are many ways to contribute to KDE and they are all much appreciated. kde.org/support
Re: Bugless by KDE-4.0 - Mario - 2003-09-19
Look budy, we all than you for your contributions, it's jsut that you don't know enoguh about how software works and the OSS development process to have a really helpful opinion rather than just wishful thinking. The KDE developers know the issues and problems they know how to adress them adn you're bringing nothing new to the plate with this. Yes, we would all like a less buggy KDE, but few would want KDE to appear to be at a standstill because all developers are fixing bugs and msot developer swill not do this anyway, tehy would make an experiemtnal or cool branch and jsut work on that instead. As many have explained to you it is virtually impossible to have a bugless KDE. It is just not achievable and many of those bugs are old and don't affect you.
Re: Bugless by KDE-4.0 - anon - 2003-09-19
Well, gnomedesktop.org updates their page much more often than the dot, and as such, they get much, much, fewer comments (ten times less?!) on each page. As such, dot.kde.org articles get many more whining/offtopic/inflamatory/trollish/flamebait comments than a gnomedesktop.org article does. Not only that, but they use a much more modern system than dot.kde.org uses, that shows IP's if it's not logged in. This probably reduces it too. (keep in mind that the old gnotices site, before gnomedesktop.org, had it's fair share of whining/offtopic/inflamatory/trollish/flamebait comments ).. but guess what? It was almost EXACTLY like dot.kde.org. It even used the same comments engine.
Re: Bugless by KDE-4.0 - Anonymous - 2003-09-19
> And I wonder if this is KDE specific because I don't see such statements on gnomedesktop.org while GNOME has a comparable amount of issue reports. Just found this interesting comment http://slashdot.org/comments.pl?sid=79139&cid=7003183 talking about the Mozilla/OpenOffice.org/RedHat situation.
Re: Bugless by KDE-4.0 - Janne - 2003-09-19
"Today, I have witnessed elitism among the KDE team." Have you? Have KDE-developers responded to you and said something like "STFU n00b!"? I haven't seen anything like that. Sure, few people (me included) have replied to your post, but are those KDE-developers or just casual dot-readers (like me)? Fact is that your suggestion of "100% bug-free KDE" is not realistic. It cannot be done. Yes, bugs should be killed, and they are. Just in the last seven days, KDE-team has killed 399 bugs. I just went through some random bug-reports. They were from old version of KDE. Most were from 3.1.x but not from 3.1.4. Some were from KDE 2.x or from CVS-version! Large part of the bug-reports were unconfirmed. Point is: you look at the number of bugs with horror. But how many of those bugs are REALLY valid? How many of them are from old versions that no-one runs anymore? How many of them are from the bleeding-edge-version that normal users don't run? How many of them are confirmed? How many of them have been fixed with the report being left open?
Re: Bugless by KDE-4.0 - anon - 2003-09-19
> or carry less weight than that of a KDE coder. You're mistaking "coder" for "contributor". And ___of course___ somebody who doesn't contribute in a physical manner (be it doc writing, programming, being an artist, web designer, etc...) to KDE is not going to have as much influence in the future development of KDE as someone else is going to have. This isn't elitism, it's just how it works. Most KDE contributors are volunteers working on their __free time__. Many are students with large course loads. Many have full time jobs. Some have families to feed and children to take care of. We are humans too, and we are working on this for __fun__. So, if you tell a set of KDE contributors to stop working on what they want to for a full year, don't expect your comment to be taken very seriously. Many KDE contributors would just stop contributing if they were forced to that. Thankfully, KDE just doesn't work like that.
Re: Bugless by KDE-4.0 - anon - 2003-09-19
And also, since you want KDE's bug stats to go down, I suggest testing out older bugs (especially things like khtml), and try to reproduce them if you have a CVS copy of KDE. I went through 30 last week (as many as I had time to do), and I found a few that worked in HEAD and commented as such. There are already a few people who do this, but there aren't enough. It doesn't need any coding skills, doc-writing skills, artist skills, but is a way you can influence the development of KDE more directly.
Re: Bugless by KDE-4.0 - Derek Kite - 2003-09-19
Yes you could call it elitism. Those who write the code decide their own priorities. If you can't code, hire someone who can. And they can do your bidding. Don't like it? Tell me, how else should it be done? The licenses permit forking. Go ahead. I'm serious. You can suggest. Many who actually contribute code dislike your suggestion. Maybe you should listen carefully to what they say. They are smart people. And what do you think the developers are doing, except fixing bugs? Two worked for the better part of a year to rewrite a basic module of KDE. Why? To fix bugs. Make it correct. For your edification. Bug statistics are as most other statistics: useless out of context. Like lines of code by developer. It tells you something, but not much. Same with number of bugs. I will make a prediction that may sound outrageous. There will be more open bugs at the end of this release cycle than at the beginning. It is a matter of the number of users. More users find more bugs. Regular users find small issues that irritate them, and bugs are reported. KDE is getting very good, and will attract a very large user base with this release. High bug numbers represent a large user base. This situation also reveal a flaw in the bug database system. The basic thing to remember is that software development is a process of the human mind. The fact that computers are involved tends to make us think that is should be logical, deterministic, predictable and all those comforting things. But it ain't. Even one developer. A large project made up of a few hundred contributors, a code repository of over 10gb, as a human endeavor is unimaginable. You are seeing the workings of the human mind in all it's glory and decripitude. I consider it a privilege to watch, let alone have a very small part in it. There are answers to many questions here, including how does one manage a very large software project. Derek
Re: Bugless by KDE-4.0 - anon - 2003-09-19
If you don't want feedback and discussion, then don't make comments. Otherwise if you want to make a comment expect feedback positive or negative. Not everybody in the world is going to agree with you or think you're a bloody genius. :-)
Re: Bugless by KDE-4.0 - Eric Laffoon - 2003-09-20
> Today, I have witnessed elitism among the KDE team. I think you need to chill out. You posted saying it was a rant and expecting to get flamed. I haven't read them all or who they were from but I think you need to climb down off your cross and be reasonable. > I'm as disgusted as I am disappointed. Because I do not possess proficient coding skills and I do not contributed code directly to the project, Really? I didn't have them when I joined the Quanta project to work on the UI specs. I was forced to learn C++, then I sponsored Andras and now I finally am getting fairly good at C++. Look, if you are interested in something then pursue it and stop making excuses. I've had 14 year olds contribute code to the project. How long do you think they have been coding? > I've been labelled as second-class contributor and as such, my suggestions, which another member termed whining, are almost worthless, or carry less weight than that of a KDE coder. Well people listen to me, but it's because I'm a project maintainer and I have a history of making good decisions about Quanta. I've gotten a reputation based on my performance. I still do not feel up to technical decisions on a number of things that I look to more experienced developers in the KDE project on before developing an opinion. This is just common sense. KDE is largely a meritocracy where your credibility is based on what you demonstrate. I like this because it doesn't allow for ideas that sound wonderful and noble in theory, but prove disasterous in practice, to harm the project. Where are your credentials? If you have none can you point me to some credible resource, such as a respected developers writings? You are the one who sets the weight of your suggestions by what you bring forward in demonstration of your ideas. > Way to go friends, you definately attrack more enthusiasm with this attitude. To be blunt, I love enthusiasm, but it needs to be directed and coupled with good experience to become leadership. I've had enthusiastic people who could do nothing more than waste my time with one wild idea after another that I could shoot holes in far too easily. I'll tell you something else too... if you have a strong feeling about something and you want to better it then you don't really give a rip about a little constructive rejection. If you could come up with the answer with no experience or knowledge of the process what does that say about the people who have that and the awareness of the problem? They're just stupid? They achieved greatly through stupidity? Possibly you may need to re think your strategy. I suffered a lot to get to where I am. It was hugely dissapointing when our original team split. I endured a lot that was far less pleasant than anything I've seen here. I didn't even have anyone to suggest what to do to. If you want to make something happen you are going to need a lot more than complaining about others and you're going to need to be willing to back up your ideas with proof and take action. > I'll take my second class contributions (AKA whining) where they are better appreciated and needed. And this is going to make me feel good that we could partner and I could depend on you? If you want to whine then by all means do it out of earshot. If you want to accomplish something then you're going to need a little more tenacity and you will need to be reasonable and open to the possibility that the truth may not be so obvious and you could be wrong. If you go through life assuming everyone who disagrees with you is irrational you could be headed for a lot of dissapointment. > Are you kidding me? It is acceptable for KDE to ship with thousands of bugs? It's an interesting question considering I've got systems that have had the desktop up for months without a problem and I almost never have a crash even with development software. I've only noticed a few of those bugs. Is it okay to tell me to stop adding features that I really need or maybe I should go work on something else? Who are you again, that you can tell me to do this? Is it okay to stagnate the project and slowly kill it for your ideals? Your credentials in this matter? Who's kidding who? What are the real world repurcussions? How do you go about enforcement if you can't get consensus? Where is the road map? You can't answer these questions... and if you think that there haven't been a number of people in KDE focusing on clean code and you're the first one to think of it then skip reality and just page up to where the earlier thread is on the same thing. No bugs is a noble aspiration, but an absolutely disasterous goal.
Re: Bugless by KDE-4.0 - Mystilleef - 2003-09-20
While I enjoyed reading your lessons of life, and the trials and tribulations you experienced during the development of quanta, a great software by the way, and your capacity as a developer in the KDE team, we both live and lead different lifestyles as well as different commitment capacities. As much as would wish to squiz everything out of my already tight schedule to contribute code into the KDE project, I just can't at least at the moment. I don't brag about my contributions to this project or any other. I don't like the attention. And as I have stated earlier I'm contributing all I can to the project directly and indirectly at the moment. I don't owe you or anyone else a credential of my contributions to the project or any other OSS project for that matter. It is against my principles and beliefs to brag about them as I don't contribute for popularity, fame or benign exposure. If you or anyone else feel you need to judge my suggestions based on how much code I contribute to the KDE community, then just do that. I have nothing loose. I have had intelligent discussions with professional software engineers working on interesting commercial projects, and none of them responded in a high ended manner as to suggest I'm not qualified to critize or make suggestions on ways they could improve their projects because I'm not a coder. You and anyone else are very welcome to critically analyze and attack my suggestions, but don't attack my person by politely calling stupid, dumb or not qualified in twisted terms. I welcome any criticism to my ideas. With regards to my coding skills, I would just not contribute code to the project until I'm comfortable doing so, that will be sometime in 2006 if I'm disciplined with the goal I've set for myself. :-P I'm very interested in kwin and kdelibs. I've joined the mailing lists and all what not. But I'm discouraged by the elitism I've witnessed here. This has been an eye opener. I don't place coders any higher than users, or maintainers or doc writers or testers or you name any member of the community. I've done all I can to support and promote KDE. I have encourage at least 2 people to contribute code to the community. I'm also learning a programing language just to be able to contribute code to the project. But if this high handedness is prevalent in the community, then I guess I need to stop wasting my time and effort. And perhaps that of yours and others. Once again, I'm not complaining or whining. Like I said elsewhere I whine and complain by reporting bugs at bugzilla.
Re: Bugless by KDE-4.0 - anonymous - 2003-09-19
I installed 3.1.4 about two weeks ago and I haven't shut it down since. In all this time I have found very few really serious bugs (Konqueror crashing a few times, that's all). Maybe I'm lucky and I can't say I have really used all apps, but I haven't found any serious problems that afflicts my productivity. I think you demand a bit too much, although I agree that there would be nice with some polish here and there. (I wish people would have had your demands back when Windows 95 was released. Then we would all be running Linux or OS/2 or something :))
Re: Bugless by KDE-4.0 - anonymous - 2003-09-19
Sorry, I meant 3.1.3
Re: Bugless by KDE-4.0 - James Richard Tyrer - 2003-09-21
First, I guess that I need to present my credentials: http://home.earthlink.net/~tyrerj/files/qt-x11-free-3.2.1-PSfontname.patch.bz2 I was told that the bugs I reported were Qt issues, so: I fixed Qt. With this patch, you can produce PostScript files with the correct font names. Now, you said that Konqueor only crashed a few times. I think that in version 3.1.x, that that should be considered a serious bug. Why in version 3.1.4 does Konqueror still crash on me? We should consider that there are different types of bugs. This is a serious bug -- probably a coding error. There are also bugs which are not serious -- things which could work better but work OK. I don't agree with everything that: "Mystilleef" said but he makes some good points. As I see it, it is the presence of serious bugs that we should be concerned with. They don't seem to be getting fixed. New versions are branched off and the bugs remain. I believe that there is a problem here with corporate culture -- it is the hacker mentality. I see a lot about coders, but where are the software engineers? Does the project have any? You can all say what you want, but the fact is that THIS is the weakness of OSS development. I will say it again, and many will disagree -- the design is more important than the codding. To say that design is not a physical contribution is nonsense. Back to the Qt code. What I tried to fix was something that was well codded, but poorly designed (it would NOT work even if perfectly executed). I see several other design problems with: "qpsprinter" which I didn't attempt to fix. So, the electronic engineer would like to make two points about bugs: 1. Many of them are the result of design issues not codding issues. 2. For the bugs to get fixed, the development paradigm needs to be changed. We are currently building software the way that Detroit used to build cars. First we build it, and then we try to fix the defects. But, they don't build cars that way any more. They now endeavor to build them without defects. My simple suggestion is that development should be based on the current release. As it is now, a development branch is created, it has unfixed bugs and it acquires new bugs. Then it is tagged for release and they try to fix some of the bugs. The result of this paradigm is that 3.2 will probably be more buggy than 2.2.x. And, it will just continue as it does at MicroSoft -- one buggy release after another. -- JRT
Re: Bugless by KDE-4.0 - Mystilleef - 2003-09-20
While I appreciate disagreements with my suggestions, which is absolutely welcome, I think it is ignorant and arrogant for anyone to insult my intelligence by telling me I don't know how software works or I don't understand OSS or I'm only qualified to make certain suggestions but aspiring for a bug-free KDE isn't one of them. Enlighten me. Attack my suggestions, not my person. I didn't come out here saying the KDE community (i.e. users, coders, testers, doc writers, sponsors, bug reporters, well wishers, to mention but a few) are all wankers for allowing KDE bugs to skyrocket. That would be trolling, flamebaiting or whining. No, I didn't do that. I acknowledged right from the begining that KDE is a large project and bugs of this magnitude can be expected. I am not imposing my suggestions over anybody. The *only* reasonable argument to my suggestion is the fact that KDE developers, coders in particular, are at liberty to do as they wish with their code contribution. And I don't disagree with that. However, most of us fail to acknowledge that squashing bugs is a part of the development process. Squashing bugs, doesn't slow down development contrary to popular belief. The KDE development team is small, and at this level the bugs are manageable. I fear for the day when the bug count is so high we can't manage or control them. I don't see how devoting one year to squashing bugs retards the development of KDE. We speak as if squashing bugs is counter productive and not useful while adding features is holier and better. While squashing bugs is not fun, I think developers should be encouraged to do so. I think if we can devote one year to squashing bugs it will improve the overall quality of KDE and in the future bugs will be more manageable. In this year, developers are at liberty to continue working on their new features and any other thing they consider fun. No developer will be forced to smash bugs against his or her will. Those who wish to will and those who don't wouldn't. And nothing guarantees that all bugs will be eliminated at the end of the period. The objective is just to bring the bug count down to a reasonable or controllable amount and there by improving the quality of KDE. The Gentoo project has a similar concept called the gentoo bug day (a day in a month devoted to eliminating bugs). And it has been very effective. That's where I stole my idea from. I'm not a genius and I'm not imposing my idea on anyone and neither I'm I being ungrateful nor I'm I whining or trolling. This is a genuine concern and wish for KDE to be the best. I'm also not insulting anyone persons integrity or intelligence or ideas, so be kind enough to reciprocate the gesture. Feel free to disagree with the issue, statements like, "It just won't work", "Stop whining", "You are trolling", "Software always has bugs", "Go hire developers or do it yourself", "Wishful thinking", "Go complain to gnomedesktop.org", "You don't have a Ph.D in computer science and C++, so you don't qualify to make that statement", and so on don't address the issue and as a result don't count. I'll henceforth ignore to such statements. On a final note, I whine by reporting bugs and nagging developers over at bugzilla and I encourage others to do so, but politely.
Re: Bugless by KDE-4.0 - Mario - 2003-09-20
Your real stubborn and spin anything we say the other way. Nobody insulted your intelligence, we only don't think that your more knowledgeable than the KDE developers themselves on how to develop KDE. Of course you can suggest whatever you please, but that doesnt mean that people will agree or follow your suggestions and they honestly have little reason to do so, as you said you are not a developer and are just speculating on this issue. So far in my opinion you have proved this. The developers have free will and KDE can not tell them "you may only use your free time to squash bugs" this has to be their decision, I'm glad you agree. However, just because they may refuse to fix bugs as many bugs as you want them to does not mean that they don't acknowledge that fixing bugs is a critical part of the project and that they don't do it. Just this week the obviously hard working KDE team has fixed over 385 bugs and also completed 140 wishes. Nobody ever thought that squashing bugs retards the development process; however, devoting an entire year to squashing bugs is preposterous! Most likely half of KDE developers will lose interest in the project and so no more bugs than usual will be fixed. In addition it would upset the user base of which most will not have been affected by the bugs fixed and feel that KDE is not giving them what they want and improving. Yes, maybe in a good two years we will have a eliminated just about every known bug (I doubt it since many are impossible to fix without adding new features) but we will be so far behind that nobody will care. Just like nobody will want Microsoft paint which lets pretend is a bug free product over CorelDraw 11 which most likely has hundreds of bugs. The same think would happen to KDE, most bugs that affect a lot of users are fixed quickly however the ones that affect 2% of the user base arent fixed as quickly and majority rules. In addition, the libraries and core change so automatically new bugs will be introduced quickly and your bug free product will quickly regress back to a buggy state. Its just not worth it, as long as our libraries are a moving target. What KDE needs is BALACE just like everything in life. This is a genuine concern and wish for KDE to be the best. I'm also not insulting anyone persons integrity or intelligence or ideas, so be kind enough to reciprocate the gesture. Feel free to disagree with the issue, statements like, "It just won't work", "Stop whining", "You are trolling", "Software always has bugs", "Go hire developers or do it yourself", "Wishful thinking", "Go complain to gnomedesktop.org", "You don't have a Ph.D in computer science and C++, so you don't qualify to make that statement", and so on don't address the issue and as a result don't count. I'll henceforth ignore to such statements. Here your just spinning again. These statements above are placed out of context, if that were all they said that would be bad, but the people said this and additional paragraphs. In addition you even made up a few such as ", "You don't have a Ph.D in computer science and C++, so you don't qualify to make that statement", and so on don't address the issue and as a result don't count. I'll henceforth ignore to such statements. Anyway, a Bug Day is a reasonable idea and would be helpful, I have nothing against this and in fact I like it ;) KDE already has similar things such as the Nove Hardy conference but this is more focused on one issue and Im all for it, maybe at the end of every 31 days is a good time BTW: No I'm nota KDE developer, i only player around with KDE code a bit, but didn't really contribute any useful code.
Re: Bugless by KDE-4.0 - Mystilleef - 2003-09-20
Thank you I appreciate your input. It is a much better criticism than your earlier responses. And yes, I'm a very stubborn individual, but I'm working on it. ;-) And, yes, I use hyperbole a lot to get my point accross. I play around with KDE code once in a while but I dare not contribute. Well except you are willing make me break your system. ;-)
Re: Bugless by KDE-4.0 - Mario - 2003-09-20
You don't have to code, tehre are plenty of things you can do otherwise http://www.kde.org/support/ and this is just a small list of things there are tutorials for improving documentation (in the what's this items for example) artwork, creating usability studies, posting news about KDE, submitting bugs, confirming bugs, donating money, translating, spreading the word (when 3.2 is released rather than now, I think that would make a lot better impact) etc. Anyway, i didn't do much for KDE, but considering that a proprietary software product that would equal KDE would retail for at least $30, I have donated $30 to KDE after 3.1 and I will donate at last $30 after each release.
Re: Bugless by KDE-4.0 - Mystilleef - 2003-09-20
Well I already do most of the things you mentioned. I test betas, report bugs, vote on bugs, I've donated money (I'm not going to mention dollar amounts but I've donate quite a lot to KDE and have forced all members of my family to do the same since they use it too), begged two of my friends, who are great coders, to help the project, I spread the word, use KDE ( and love it) etc. That is why I was a little disgusted by some of the comments made by other individuals above. Fine the only thing I don't do is code, at the moment ( I plan to in the future) but that doesn't mean I can't critize, offer ideas, or suggestions, or advice. I also already mentioned right from the begining that at the moment, I can't do more than I'm doing presently. If I could I would but I can't. Since the documentation team is a little short staffed, I was thinking contributing there too. But at the moment I'm angry and I'm just going to stay off any KDE involvement till I cool off and devote that time concentrating on my graduation coming up soon. Maybe KDE-3.2 will renew my interest. :-)
Re: Bugless by KDE-4.0 - Anonymous - 2003-09-20
> The KDE development team is small, and at this level the bugs are manageable. Hu? Around 200 contributors every week and several hundreds different over month(s)? All with different experience and a part of the contributors always being busy fixing trivial bugs by newer contributors. > I fear for the day when the bug count is so high we can't manage or control them. This day is already way back in the past. > While squashing bugs is not fun, I think developers should be encouraged to do so. [..] developers are at liberty to continue working on their new features and any other thing they consider fun. No developer will be forced to smash bugs against his or her will. Those who wish to will and those who don't wouldn't. And nothing guarantees that all bugs will be eliminated at the end of the period. The objective is just to bring the bug count down to a reasonable or controllable amount and there by improving the quality of KDE. You just described the status quo. Now why again do we need a so called "bug squash year"?
Apple's modifications and bugfixes? - captrb - 2003-09-17
Out of curiosity, when Apple borrowed parts from konqueror (kthml and javascript?), did they ever submit their performance enhancements and bugfixes? Where those fixes incorporated? -crb
Re: Apple's modifications and bugfixes? - anon - 2003-09-17
See http://webcvs.kde.org/cgi-bin/cvsweb.cgi/kdelibs/khtml/SAFARI_MERGE?rev=1.17&content-type=text/x-cvsweb-markup It hasn't been updated in 4 months tho, there have been several large merges since then (like Safari's box model) It will probably take at least another release cycle before Apple and KDE have a common khtml codebase.
Re: Apple's modifications and bugfixes? - cloose - 2003-09-18
See http://dot.kde.org/1063222993/1063253439/1063267452/ for a list of reasons why the safari merge seems so slow. > It will probably take at least another release cycle before Apple and KDE > have a common khtml codebase. I wouldn't bet on it.
KDE-3.1.4: configure fails to detect QT-3.2.1 - Helpless victim - 2003-09-17
It says in http://www.kde.org/announcements/changelogs/changelog3_1_3to3_1_4.php that this can be compiled with QT-3.2.1 but when I try to configure with respect to QT-3.2.1 it always quits saying: checking for Qt... configure: error: Qt (>= Qt 3.1.0) (library qt-mt) not found. Please check your installation! For more details about this problem, look at the end of config.log. Make sure that you have compiled Qt with thread support! This is not a problem of library qt-mt because these libs are definitely there. This problem is with all tested packages (arts, kdelibs). But the same configure script detects Qt-3.1.2 just fine. I guess then KDE-3.1.4 does not actually work with QT-3.2.x !!
Re: KDE-3.1.4: configure fails to detect QT-3.2.1 - Nicolas Goutte - 2003-09-18
The old questions: - where is your Qt? - to where points the neviroment variable $QTDIR ? - what are the few last lines of your config.log ? Have a nice day!
Re: KDE-3.1.4: configure fails to detect QT-3.2.1 - James Richard Tyrer - 2003-09-21
Perhaps it is not your intention, but your remarks are very arrogant. Not only this one, but others on lists. That is, you represent various remarks about 'arrogant developers'. -- JRT
Re: KDE-3.1.4: configure fails to detect QT-3.2.1 - Haakon Nilsen - 2003-09-18
I had a different problem with Qt 3.2.1. I'm using distcc across 34 computers to compile on Red Hat 9, and I would get a relocation error each time. Tried the latest Qt 3.1.x instead, compiled without problems. Don't know if this is a problem with RH9, KDE 3.1.4, Qt 3.2.1 or distcc. (FYI)
Re: KDE-3.1.4: configure fails to detect QT-3.2.1 - Chris Howells - 2003-09-18
So, did you check config.log like is says?
Re: KDE-3.1.4: configure fails to detect QT-3.2.1 - myself - 2003-09-19
The actual cause seems to be a QT-3.2.1 bug fixed in http://webcvs.kde.org/cgi-bin/cvsweb.cgi/qt-copy/qmake/generators/unix/unixmake2.cpp.diff?r1=1.29&r2=1.30&f=h
Re: KDE-3.1.4: configure fails to detect QT-3.2.1 - JCook - 2003-09-20
I applied the diff and it did not fix the problem.
Re: KDE-3.1.4: configure fails to detect QT-3.2.1 - JCook - 2003-09-20
Still doesn't work. Here is the config.log:
Re: KDE-3.1.4: configure fails to detect QT-3.2.1 - James Richard Tyrer - 2003-09-21
I don't want to sound too critical, but the entire 175 KBytes wasn't needed. :-) You might think that the: "configure" script didn't find Qt. Well the problem is that it seems to think that it did: << configure:25959: checking for Qt configure: 26024: /usr/X11R6/include/qstyle.h taking that >> This is a very odd system configuration. You shouldn't have anything 'qt' in /usr/X11R6 and even if you did, the 'include' should come after a: "qt-x.y.z" directory (in the path). I suggest that you move/install all versions of Qt on your system to: /usr/local/qt-x.y.z and see if it works. If not, you will probably have to hunt down and remove stuff that is in the wrong places. Please confinue this on the: "kde-linux" mailing list. -- JRT
Re: KDE-3.1.4: configure fails to detect QT-3.2.1 - someone - 2003-12-13
damn your a dildo. this is why linux will never be the strongest contender for desktop os's. the lack of explanation and condesending idiots such as yourself. and yes the entire 175KB was needed. that is what was asked of him.
Re: KDE-3.1.4: configure fails to detect QT-3.2.1 - jf - 2003-09-22
Try this: cd $QTDIR/lib ln -s libqt-mt.so.3 libqt-mt.so Cheers, Joerg
Re: ln -s - jf - 2003-09-22
The above is for Qt 3.1.2. Sorry about that! For 3.2.1 this works for me: cd /usr/lib ln -s $QTDIR/lib/libqt-mt.so . :-) Joerg
Re: KDE-3.1.4: configure fails to detect QT-3.2.1 - Bryan Thompson - 2004-02-02
I'm having the same problem. I just downloaded and installed qt-x11-free-3.3.0b1 to /usr/local/qt/ Here is the last part f my log: configure:30435: checking for Qt configure: 30506: /usr/local/qt/include/qstyle.h taking that tried NO tried /usr/local/qt/lib tried /usr/local/qt tried /usr/lib/qt3/lib tried /usr/lib/qt3 tried /usr/lib/qt/lib tried /usr/lib/qt tried /usr/share/qt3/lib tried /usr/share/qt3 tried /usr/X11R6/lib tried /usr/lib tried /usr/local/qt/lib tried /usr/X11R6/lib [bryan@zatara kdelibs]$ echo $QTDIR /usr/local/qt I have also exported my QTDIR to /usr/local/qt/ thinking the slash would matter, but it didn't. Any ideas? Thanks, Bryan
Magic Changelog - Alex - 2003-09-18
Everyone goc heck the changelog again, ti amgically includes doezens of items now!
SuSE Packages ??? - Mumumba - 2003-09-18
After some days of waiting now, where are the SuSE Packages on ftp.kde.org ?! anybody knows about the situation ? ;) thx
Re: SuSE Packages ??? - Eggert Ehmke - 2003-09-19
I tried to compile KDE 3.1.4 myself for SuSE 8.2, using the Konstruct tool. I run into problems because of missing berkeley db2. Is this a problem related to SuSE ? The same happens when I try to konstruct KDE 3.2 alpha. Eggert
Re: SuSE Packages ??? - Anonymous - 2003-09-19
Did you read the requirements listing? Do you have the glibc-devel package installed?
Re: SuSE Packages ??? - Eggert Ehmke - 2003-09-19
Yes of course. Eggert
Re: SuSE Packages ??? - DeckerEgo - 2003-09-19
Important point - several contributors (ASP Linux, TurboLinux, SuSE) are still missing. I wonder why? Too busy? Compile-time problems? Dependancy issues? Configuration conflicts?
Re: SuSE Packages ??? - Anonymous - 2003-09-19
I bet on busy or marketing decision to push their soon-coming next boxed version.
Re: SuSE Packages ??? - Mumumba - 2003-09-20
hm, maybe, but, i think, the suse-packages on ftp.org are independent from ftp.suse.org.. right ? hm, i thought, people from kde are making the packages.. but, maybe not, because i can't find a reason why the packages are delayed so long.. actually i am really hot to install the stuff ;) sure, kde3.2 will be there but, anyway i wish the packages will still be made and uploaded :) maybe there are problems compiling them on a suse box, but i can't really imagine that.. anyway, thanks for some reply :)
Re: SuSE Packages ??? - Anonymous - 2003-09-20
What ftp.org? What suse.org? > hm, i thought, people from kde are making the packages.. No, http://www.kde.org/download/packagepolicy.php
Re: SuSE Packages ??? - Mumumba - 2003-09-20
ah, i see.. but usually, the suse-packages from ftp.kde.org were a bit diffrent from ftp.suse.com. but anyway, really strange.. i think, announcement like this shouldn't be done if there aren't at least a dozen of diffrent distributions supported.. in the past, i remember, there were packages for the main distributions immediately on the server, just after annoucement.. that was great. actually they don't need to announce and an (important) update if most people can't use it, because they can't compile the source because of a slow machine or whatever.. i really hope the situation will be diffrent when kde3.2 will be released. :/
Re: SuSE Packages ??? - DeckerEgo - 2003-09-21
Here I am, beating a dead horse with a stick, but... Using konstruct isn't so bad, but then we have all the SuSE themes/applnks/default configs/kdm settings to deal with. Do any SuSE employees build KDE packages? Might there be some release in the ftp.suse.com/pub/people directory?
Re: SuSE Packages ??? - Anonymous - 2003-09-25
KDE 3.1.4 packages start to appear at ftp://ftp.suse.com/pub/suse/i386/supplementary/KDE/
No, "View Document Source" in context menu in 3.2! - Alex - 2003-09-19
Yes, the navigation options are necessary there, every browsr has them, they are commonly used and it would be a great mistake to remove them. Don't make the same mistake Mozilla did a few years ago when they removed these options and the entire userbase was furious and they were forced to put them back where they were in only a couple of days. Let's focus on removing context insensitive and rarely used items. Also, the "View Document Source" option really should be placed back into KDE and be called simply View Source"! I know KDE needs to focus a lot more on usabiltiy, but the View Document Source otpion was not a usability problem and actually belonged. Face it, every major browser has this feature in the context menu, from Internet Explorer, to Opera to all Mozilla based browsers, its there for a reason and makes perfect sense. KDE should bring back this feature even if it doesent believe it is necessary at least so that the 99.5% of users who dont use Konqueror will feel at home. I also like Clees patch very much it removes lots of redundant insensitive and just plain unecessary options which really make sKonqueror feel more refined. I am definitely hopeing this will make it in CVS, hopefully Clee can tell us, its obvious we all want it and agree with him so I am very hopeful. The point is also not that users can acess this item from other places, it is that it breaks away from the norm, makes the browsing exoperience inefficent and removes a commonly used and important feature from its rightful place. I defintely hoope Stephen will change his mind. PLEASE Stephen, help make KDE 3.2 great and bring back this great feature. More information here: http://www.kdedevelopers.org/node/view/194 and http://bugs.kde.org/show_bug.cgi?id=53772 Please tell me what you think about the removal of this item from the cotnext menu in 3.2.
Re: No, "View Document Source" in context menu in 3.2! - anon - 2003-09-19
> Yes, the navigation options are necessary there, every browsr has them, they are commonly used and it would be a great mistake to remove them. When did anyone talk about removing them? They are probably not going to show up when you click on a link or a image however (hopefully that gets fully implemented before 3.2) > Let's focus on removing context insensitive and rarely used items. There are very much less context insensitive items in HEAD, except for navigational items. As for rarely used items, those have been moved around and have a much less prominant place now. There are still a few to be changed however. > Please tell me what you think about the removal of this item from the cotnext menu in 3.2. I think it's fine. View Source has only been pretty much useful for web designers (and khtml hackers ;) ), and few power users are actually web designers. For the vast majority of power users, it just bogs down effiency. > KDE should bring back this feature even if it doesent believe it is necessary at least so that the 99.5% of users who dont use Konqueror will feel at home. Uh, not all of that 99.5% of users will ever use it, and most won't give two shits about it.
Re: No, "View Document Source" in context menu in - Alex - 2003-09-19
Sorry, copy/pasted the wrong part of my respone to the bug http://bugs.kde.org/show_bug.cgi?id=53772. here the were actually talkinga bout removing the back/forward buttons. Anyway, I don't think that "View Source" bogs down efficency, and it is often useful, I'm not a web developer and I use it all the time for posting in forums and adding news items to website slike PCLINUXONLINE.com. Even, fi maybe only 20% of Konqueror's suer will use it daily IMo the number is still big enough to be significant and the average user will just not use it if taht's the case. They won't be confused, every other browser has this in the context menu so I'm betting they will know what it does by now. Also, annon will CVS have Clee's patch for the pop-up menu: http://www.kdedevelopers.org/node/view/194?PHPSESSID=e4ac12df50c5ffbac8ea1d546f1992d5 to remove the "Stop Animations", "Set Encoding" item and other items that don't belong in the context menu?
Re: No, "View Document Source" in context menu in - anon - 2003-09-19
> I'm not a web developer and I use it all the time for posting in forums and adding news items to website slike PCLINUXONLINE.com. If you need to view the source of the page (and thus, at least partially understand html), just to grab a link, then something else is messed up. > the average user will just not use it if taht's the case. great.. the average power user probably doesn't need to access the internals of a webpage unless they are a developer ( or bug reporter! :) ) > Also, annon will CVS have Clee's patch for the pop-up menu: http://www.kdedevelopers.org/node/view/194?PHPSESSID=e4ac12df50c5ffbac8ea1d546f1992d5 to remove the "Stop Animations", "Set Encoding" item and other items that don't belong in the context menu? Uhm.. you propose to keep "View Source" because people are used to it and it's in other browsers, and yet, you want to remove "Set Encoding", which appears in the context menus of the browser than 95% of users use (eg, IE for windows) I think "Stop Animations" does not belong in context menus btw. It's a feature that really isn't used by people more than once per session (if they use it at all). It'll still be in the menu for people who use it.
Re: No, "View Document Source" in context menu in - Alex - 2003-09-19
>If you need to view the source of the page (and thus, at least partially understand html), just to grab a link, then something else is messed up. No, there's nothing messed up, it's just easier copying and pasting than it is writting it out. Mozilla, has an even more helpful feature though, it's called "View Selection Source". This is probably one of the main reasons that I still use Mozilla more, that and http://bugs.kde.org/show_bug.cgi?id=52884 There are many reasons to view the source of a page even if you're not a developer and face it msot Linux users tend to be power users and there is probably demand for this feature. Set Encoding is different, the same arguement applies to it, but in general there are more arguements against it and that's why the popularity bonus si not enough to tip the scales.
Re: No, "View Document Source" in context menu in - Anonymous - 2003-09-19
"probable demand" or "20% of the users would use it" are no good arguments to bloat the interface with duplicate entries (or in general to introduce more options to the control center).
Re: No, "View Document Source" in context menu in - anon - 2003-09-19
Clee also has a patch to give View Document Source a shortcut key by default. I don't think this is right as well. Giving it an accel key is fine of course. Shortcut keys should be distributed to actions which are used the most. Novice users practically never use it. Very few intermediate users ever use it. Some power users use it, but I don't think the majority use it daily, or even every time they use Konqueror. Save Ctrl-U for something more useful for the majority of intermediate or power users (and the occaisional novice user too)
Re: No, "View Document Source" in context menu in 3.2! - Anonymous - 2003-09-19
> the navigation options are necessary there, every browsr has them Safari? Hint: "every" statements are likely wrong in any case. > every major browser has this feature in the context menu, from Internet Explorer, to Opera to all Mozilla based browsers Mozilla based Epiphany doesn't have it. Yeah, this browser being infamous for usability. > I also like Clee's patch very much it removes lots of redundant insensitive and just plain unecessary options The patch which removes the "security" action making it unpossible for you to view the security of a frame? Removing necessary functionality completely is in no way an achievement. > More information here: http://www.kdedevelopers.org/node/view/194 and http://bugs.kde.org/show_bug.cgi?id=53772 Why must be the discussion held in parallel with same comments everywhere but not to where it belongs to, the kde-usability mailing list?
Re: No, "View Document Source" in context menu in - Mario - 2003-09-19
Sorry, i meant all good Mozilla based browsers. I'v tried Epiphany, what they call usability I call shit, tehy removed the best parts of Mozilla. Now Mozilla Firebird 0.7, that's very usable and still full of great features.
korganizer sessions - garrybaldi - 2003-09-19
Release after release I'm waiting for korganizer to handle sessions correctly. It consistently opens 'new calendars' in any new kde session no matter how much activated my personal calendar was. I'm not going to hope for relief in 3.1.4 because 3.1.99 still has it. And it became successfully implemented into kontact part of 3.2. I'm so sad. g.b.
Re: korganizer sessions - ed moyse - 2003-09-19
Hmm. I use korganiser every day and I've never had this problem...if I were you I'd be tempted to try stuff like moving your .kde directory for .kdeOLD and see if it works then. If so, your korganiser config has probably got screwed.
Re: korganizer sessions - ik - 2003-09-19
i'm having the same problem ...
Re: korganizer sessions - Gerry - 2003-09-20
I have this problem but, being in the slow class, I didn't quite understand your suggestion. May I ask you to amplify?
Re: korganizer sessions - Max Howell - 2003-09-19
Hi, if you haven't you really should submit the bug report or vote for this bug. Otherwise there's less chance it will be fixed. Cheers.
OT: boson video - impressive graphics - MK - 2003-09-19
On the KDE game-devel list it was recently announced that the boson guys (boson is a KDE real time strategy game) released two promotion videos showing the boson game engine in action. The game is full 3d and looks impressive so far, see http://boson.eu.org/ http://boson.eu.org/movies.php
Re: OT: boson video - impressive graphics - Mario - 2003-09-19
It's ok, but it totally pales inc omaprrison to games like Empires, Age of Mythology, Rise of Nations, etc. in terms of graphis, I haven't played the game so I can't judge on gameplay.
Re: OT: boson video - impressive graphics - MK - 2003-09-19
Yup, you are right - in comparison to the games you mentioned above the graphic isn't very impressive. IMHO your statement can even be generalized: windows games are in almost all areas a couple of years ahead compared to their free counterparts. But comparing boson with other open source RTS (real time strategy) games (such as the former freecraft) I think it is a big step in the right direction and it hopefully slowly closes the windows / open source gap in the games area.
Yup - Mario - 2003-09-19
If you compare it to other free games it defintely has great graphics. However, there are some Linux games with great graphics too, like Neverwitner Nights, unreal Tournament 22003, and in a few months Doom 3. With wineX you cal also enjoy a wide variety of Windows game swith acceptable performance if you have a good graphics card.
Re: Yup - CE - 2003-09-20
But we'll lose Epic (UT etc.) since their new publisher is MS.
Re: Yup - Rischwa - 2003-09-20
>But we'll lose Epic (UT etc.) since their new publisher is MS. Who needs Epic if there is Id ;-).
WTF - Mario - 2003-09-20
You mean UT 2004 won't be for Linux?
Re: WTF - FS - 2003-09-23
From http://www.planetunreal.com "we are not ready to discuss the particulars of the Microsoft deal but I can assure you that you have nothing to be worried about." And from http://www.planetunreal.com/ut2004/ (near the bottom) "Again, it'll probably ship with Linux executables." I _hope_ this means there will be a linux version...
When do we have something like windowsupdate? - Dave - 2003-09-20
I would really like something like windowsupdate on future releases of KDE. Wouldn't that be possible? I think that would help more unexperienced people to update their KDE installations.
Re: When do we have something like windowsupdate? - Chris Spencer - 2003-09-21
That would me more a job for your Linux distro. SuSE has YaST2, but it's somewhat buggy, and it doesn't provide new versions of software, only bugfix versions. It's a nice start though...
Re: When do we have something like windowsupdate? - Dave - 2003-09-21
Yes, that's true that <your favourite distro> should solve this issue... BUT still they haven't done this in a convenient way. Im just having a silly dream that the KDE team could come up with a far better tool for this. Im also sure that the most average users would appreciate a simple tool to update KDE within that version series from 3.xx till next major version is released. But then again maybe Im just dreaming /Dave
Re: When do we have something like windowsupdate? - Mumumba - 2003-09-21
yeah, a little tool, like "SuSE-Watcher", that is checking for kde-updates, asking for downloading the files and making the update.
Re: When do we have something like windowsupdate? - Anonymous - 2003-09-21
This would require binary packages: http://www.kde.org/download/packagepolicy.php
Re: When do we have something like windowsupdate? - Nobody - 2003-09-22
Or via sources just like on those source-based distributions (like gentoo) and just inform the user that "your machine will munch the OS for 5 hours (calculated by /proc/cpuinfo specs) to update kde-x.y.z"... ;-)
Re: When do we have something like windowsupdate? - James Richard Tyrer - 2003-09-22
Do you mean like a KDE version of Red-Carpet? This is based on having the RPM packages available somewhere to download. There is also the possibility of having Kpackage do APT for RPMs. Then the user would have to provide the URLs to check for new stuff. Both ideas sound good to me. -- JRT
Remembering - Mumumba - 2003-09-22
http://www.linux-magazin.de/Artikel/ausgabe/2000/10/KDE/kde.html :)
KDE 3.1.4 IS NOT Released! - Foobar - 2003-09-23
:( (will the source be with you)
*sigh* - security update not for SuSE? - nils23 - 2003-09-23
Ok guys, great work, I guess, with all this fixing of security holes and upgrades and all, but could anyone please pretty-please upload rpms for SuSE? Or at least say why there aren't any? I don't know why this is the first time that there aren't any SuSE rpms and no one even mentions anything about releasing them soon..? ... It would be a Good Thing(tm) to at least inform ppl about what's going on, yes? - With most users trying to escape FUD, it's bad to learn that there's new FUD on its way.. <=O) (Ok, I know: "volunteer work!", "help yourself, mate", etc., just trying to bring a problem to ppls attention here. Of course KDE rocks ok.. =O) ) cheers! nils
Re: *sigh* - security update not for SuSE? - Anonymous - 2003-09-23
There are no SuSE packages because SuSE didn't provide any. Ask on suse-security or suse-kde mailing lists for the reason, not here.
Re: *sigh* - security update not for SuSE? - Paul Leopardi - 2003-09-24
I did ask at suse-security. Roman Drahtmueller replied ( http://lists.suse.com/archive/suse-security/2003-Sep/0232.html ), saying "...you're vulnerable if you're using pam_krb5. Most people don't. ... We're doing our best. This one just takes a bit time."
Compiling KDE - Gerry - 2003-09-23
The absence of SuSE packages is making me think sbout compiling my own. I know that there is guidance out there on the website, and I've downloaded most of what I need. However, this would be by far and away the most significant compile I would ever have done. Is there anyone out there prepared to share with me their practical experiences: a) should I do it on my only machine? b) what are the pratfalls if any? c) once compiled, is that it or does it require extra know how? TIA