In this week's KDE CVS-Digest (all on one page): Kttsd adds support for Italian Festival voices.
Umbrello improves import from ArtisanSW, Visio, ArgoUML, Fujaba and NSUML.
KSpread has a new insert calendar plugin.
Konqueror loses its Cut/Copy/Paste buttons.
KDE begins move to Subversion and discusses future roadmap.
Dot Categories:
Comments
I don't want 'focus follows mouse'. If I'm dragging something off a window I just want to leave the window heirarchy as it was - I expect the target of the drag operation to be left unchanged, apart from responding to having something dropped onto it. Focus follows mouse is not a solution, it is a workround to some problem with X windows I think.
I think the problem here is difference is culture. I am a Mac user and I love the drap&drop on Mac OS X. I think Mac users are using it because it works well. But Windows and KDE users might not used it very often if it is not well supported.
Being able to drag & drop from a window without bring it to front would be great in KDE. It is one of the thing that I miss from the Mac.
Clicking on a window must bring that window to front. With Drag & Drop this not an exception. This is because clicking means pressing the mouse button and release the mouse immediately while staying at the same location.
When you drag and drop, you press the mouse button, you hold that mouse button, you stay in place a few milliseconds, you move the mouse to the destination and you release the mouse button. The 'stay in place a few milliseconds' is necessary because otherwise when you move the mouse directly is to make a selection which as slightly mouse gesture.
Mac OS X as it right. I hope KDE can learn from it.
Shame on you. The Usability Police have spoken. Do as you are told and everyone will be happy. In the future the totality of the KDE interface will consist of a single large "do it" button, and it will mark the New Millenium of Utter Fulfillment.
"Now they are being asked to right-click or use keyboard shortcuts, neither of which is very obvious to somebody new to computers."
they can use keyboard-shortcuts. Or they can use context-menu. Or they can use the menubar. Or they can drag and drop. I think newbies will do just fine. And besides, why do you think that clicking a button (among several other buttons I might add) in the toolbar is easier than right-clicking and choosing the action from there?
Keyboard-shortcuts will do fine as well. Espesially since they are used consistently across the desktop. Same key-combo cuts and pastes across wide variety of apps.
And, like it or not: very very few people are "new to computers". And if they are, they shouldn't have any problems using drag and drop, menubar, shortcuts or context-menu. Toolbar-buttons are NOT any simpler than those are. And if they have never even used computers, how will they know to miss the buttons in the toolbar ;)? They will make do with whatever is offered to them.
"I have first hand experience training people 65 and plus on Linux and know that this is a step backwards."
And I have first-hand experience with people who were at a loss with Konqueror, because it overwhelmed them with buttons. So what's your point?
Hell, if I had my way, Konqueror would only have the browsing-buttons (up, back, forward, home, stop)! Luckily for you, I'm not the one who decides these things ;).
Heh, isn't it funny? I've been customising the toolbar buttons for ages to suit my needs, but I always kept these three as usable. And actually when they include text below (as I think it should be by default for users' best comprehension), they take the least space of all.
Couldn't agree more. It is nice to see that things change to the better in applications that people actually use on a dayly basis.
Too much effort have been spent in the past to get the perfect kcontol. Sure, at each attempt, it have improved significantly, but kcontrol is something that users use quite seldom. They usuallay configure their system once and that's it. When new versions of KDE comes out they usually keep old settings for most of the things.
Now its time to focus on applications that people use frequently, if we could get people to save five minute a day on better userinterfaces in e.g. konquerer or kontact we would achieve much more than if configuration takes five minutes less.
Giving less frequently used functions a less visible position in the GUI or as in this case removing unfrequently ways to do common things is a good start.
We should not be afraid to look at other DEs such as MacOS, Gnome or even windows to see what they do well, and try to make an improved version of it that fits in the KDE environment.
An example of things that could be borrowed from Gnome is the dual top and bottom panels. The screen edges are the provides the largest targets on the screen to hit by the mouse. why not make as much use of them as possible.
Even the Gnome "Program", "Action" and "Places" menu is better than the current single K-menu as the menus gets shorter and more focused. We see the same idea in the double start menu of windows XP, but in my oppinion Gnome has implemented it better. The question is can we make it even better?
Another thing that would make life easier for normal users, would be if directories almost never enter, or at least should have no reason to enter, was
hidden by default in konquerer unless they are logged in as root. Good candidates for hiding would be:
/etc, /bin/, /lib, /boot, /selinux, /lost+found, /root, /usr/bin, /usr/lib and perhaps some more.
The files should also be hidden in file dialogs, exept for dialogs for creation of application starters that need to be able to reach all directories that contains executable files.
This behaviour should be configurable perhaps by adding a .hidden file or something. That .hidden file should decide what directoris that can be seen on a per user and group basis.
>Another thing that would make life easier for normal users, would be if
>directories almost never enter, or at least should have no reason to enter,
>was hidden by default in konquerer.
>This behaviour should be configurable
What are you talking about, this is already the case. When you open Konqueror in filemanger mode it opens in your home dir (/home/yourusername), already effectively hiding the directories you talk about. To get to those dir you have to deliberately click the Up icon twice or deliberately select Root Folder in the sidebar. "Normal users" will never encounter those directories unless they for some reason take actions to get to them. And in those cases hiding of directories behind a config option only makes whatever the users want too do harder. Actually ending up making it much worse for your "Normal users". I'll even give you a example, one of the most frequent files referenced when doing genereal support/troubleshooting is /etc/fstab. Hiding it make little sense.
In this case there are absolutely no reason to copy windows, besides the reason you have this functionality in windows are not to make it less confusing for users. The functionality was added to make it harder for users do destroy the system by deleting systemfiles from the windows directory. A non issue on *nix, since users don't have write permissions in the system and binary dirs.
So, if hiding setting in config options make things harder, why have kcontrol in the first place. People could just go to the appropriate file /etc/ and make whatever changes they need assuming they have the correct permissions.
I think that the problem is that we have different definitions of "normal" users. In my world, normal users are the ones who use a Xerox machine to copy a discette. They haven't a clue what /etc/fstab is, and even less on how to use it for diagnostics. They don't trouble shoot things. If something goes wrong, they call support. The support people should of course be allowed to see all directories just like they do today.
Allowing ordinary users to trouble shoot things could actually prove costly, as it means that a lot of your employees will first try to fix things themselves instead of calling the sysadmin that could fix it for all users.
Your assumption that users always stay in their home directory is also somewhat flawed. In many organizations there are shared resorces that may well reside outside the users home directorise. And even if there are not ordinary users may want to navigate to /tmp to create some temporary file. And I can assure you that a user that only have to choose from /tmp, /home, will have a much easier task finding that /tmp folder than the one having /bin/, /boot, /etc/, /lost+found, /proc, /dev, /selinux, /sys, /sbin, and 10 or so more folders to choose from.
My basic idea is that the user should be able to see should as much as possible relate to their working world not to the computer system. If the user needs something in /usr/bin it should have an application starter and be found from some programs:/// folder or the K-menu. If there are things that the user needs to do in /etc that is a sign that the kcontrol settings arn't good enough net an indication that normal users need to see that directory.
>if hiding setting in config options make things harder, why have kcontrol in the first place.
Nonsens, in this case a it's about a option who does not make sense since the system in it's design already provides it. It has nothing to do with kcontrol.
You are right on one account, we have different definitions of "normal" users. You deffine "normal" users as complete computer illiterate. In my observations they are rather a lot more capable, since they actally use the computer to accomplice some tasks. And they are capable to follow instructions, verbal or written.
>Allowing ordinary users to trouble shoot things could actually prove costly.
Again, nonsens. Since the user don't have permissions to do anything to the system. On the other hand he would be able to do things like change the desktop cdrom icon's path from /mnt/cdrom to /mnt/cdrom1 with the information from /etc/fstab. (with or without help from suport).
> Your assumption that users always stay in their home directory is also somewhat flawed.
>In many organizations there are shared resources that may well reside outside the users home directories.
Even more nonsens. If you have "normal" users who are like you describe them, they need one or more admins. If the admins are competent enough to set up *nix boxes, and with shared resources. They are in the case of users having the problems you describe, also competent enough to make those available from the users home directory removing the "problem". And if the user need still more babysitting you can restrict them to their homedir with Kiosktool.
Using imaginary user scenarios with a marginal user class are rather useless when discussing usability. Afterall the goal in usability are to make the most number of persons able to get their tasks done as fast and easy as possible. Not to make the system idiot proof.
>>if hiding setting in config options make things harder, why have kcontrol in the first place.
>Nonsens, in this case a it's about a option who does not make sense since the system in it's design already provides it. It has nothing to do with kcontrol.
The system, allready provides a lot of things that we allready manage in kcontrol. We use kcontrol to have one place to manage and control various settings. Having more places to look in will not help users. It is also very hard to provide help to users if you admin the filesystem way.
>You are right on one account, we have different definitions of "normal" users. You deffine "normal" users as complete computer illiterate. In my observations they are rather a lot more capable, since they actally use the computer to accomplice some tasks. And they are capable to follow instructions, verbal or written.
Even if they can follow instructions, written or not. Who will pay for it?
Assume you have 100 users. The sysadmin will do some task in one minute, it will take him 10 minutes to write the instructions in a way that his moderately experienced users can undurstand it. Each of the users will spend 10 to 15 minutes to read and understand these instructions. Some will succeed in performing the tasks directly, some will fail and call the sysadmin. Now a task that would have take one minute have taken at least 110, probably more minutes.
The time is most likely not billable. The way of administration you advocate is so windows.
>>Allowing ordinary users to trouble shoot things could actually prove costly.
Again, nonsens. Since the user don't have permissions to do anything to the system. On the other hand he would be able to do things like change the desktop cdrom icon's path from /mnt/cdrom to /mnt/cdrom1 with the information from /etc/fstab. (with or without help from suport).
A user should not have to manually scan the file systems for system icons. The dialog to change icons should directly provide some iconselector, not a general file selector. And if it is not system icons, they would be in some place where the user can access them even with hidden directories the way I suggested.
>>In many organizations there are shared resources that may well reside outside the users home directories.
>Even more nonsens. If you have "normal" users who are like you describe them, they need one or more admins. If the admins are competent enough to set up *nix boxes, and with shared resources. They are in the case of users having the problems you describe, also competent enough to make those available from the users home directory removing the "problem". And if the user need still more babysitting you can restrict them to their homedir with Kiosktool.
Sure, the sysadmin can have whatever resources appear within the home directory of each user. However, this sometimes pose a problem. How is the user to know that the resource is not entirely under his control? By putting the shared resouce somewhere else in the file system this becomes more clear.
>Afterall the goal in usability are to make the most number of persons able to get their tasks done as fast and easy as possible. Not to make the system idiot proof.
Exactly. this is why we shouldn't have things that gets in our way. Its not about making the system fool proof. A user with a little skills could still fire up cate and look /etc/fstab if he wants to. But the need for this appears extremely rarely, so it doesn't matter if they are slightly more difficult if it makes everyday use easier. Reducing the number of available chosies in file dialogs does that.
The user should have all the information he needs when he needs it and only when he needs it. This is the same principles as you use in design of cockpits in modern aircrafts its not some kind of attempt to stupidyfy the user. Its about making more of the users intellectual capacities available to his work tasks. From what I understand most users of MacOS-X is quite satisfied with this behavior, there is no reason to believe that the situation would be much different for KDE users.
>We use kcontrol to have one place to manage and control various settings.
And that's correct, but stop pretending I am arguing against kcontroll. What I am arguing about is adding an unnecessary configuration for something the design of the system already provides adequately.
>Even if they can follow instructions, written or not. Who will pay for it?
>The way of administration you advocate is so windows.
Again you take what I say out of context, I'm not saying you should make the users do the administrators job. I'm pointing out to you that in any normal corporate setting the "normal" users are not complete idiots, like you argue. A company with your kind of user would need a it-staffer for every 4 user or so.
>By putting the shared resource somewhere else in the file system this becomes more clear.
Or perhaps naming the directory: This_Directory_is_shared_by_whole_company. Please stop dreaming up nonexisting problems.
>this is why we shouldn't have things that gets in our way.
>But the need for this appears extremely rarely, so it doesn't matter if they
>are slightly more difficult if it makes everyday use easier.
>Reducing the number of available chosies in file dialogs does that.
From a usability perspective those two first statements together are pure nonsens and they are contradictory. The third statement are by itself also non essential nonsens, it only marks you as a member of "the too cluttered school of removal".
Instead of throwing nonsensical statements around, I'll argue by example (using today's popular topic). Take a everyday task like browsing this site, the fact is it makes no difference on my usability experience having 6, 12 or 18 icons in my Konqueror toolbar. It will have no impact of my understanding or speed which i read the pages(usage). Fewer icons may perhaps look better, but it does not impact on my use. Its only fluff. It may confuse a newbie slightly for for a few minutes, but since (based on estimates after watching real users) 95% or more of browsing are done using links/bookmarks/locationbar/back button they will really soon have learned to ignore the other 5, 11 or 17 icons. On the other hand, I once wanted to print out the content of a frame, not the whole page. Without the print frame icon I had probably used a manual cut/paste solution, looking for the function had never occurred to me if I didn't know of it's existence. And that's actual usability in practice.
Well, what can I say.
I could recomend some books on usability, but you would probably not read them, so whats the point.
And yes, I do belong to the "too cluttered school of removal" that think less is more, and I am proud of it.
Unix have been around for over 30 years, and the first time it gets any significant marketshare on everyday users desktops, it does so in a non cluttered form (MacOS-X). That should tell you something on what way to go.
If not the MacOS is example enough for you, look at Gnome. A couple of years ago KDE was the only boy in town to count on. It had a market penetration in the free desktop of about 50%. Today that market is schrinking rapidly in favor of Gnome. You almost can't open a webpage without being told how wonderful Ubuntuu, JDS or some other Gnome based Linux distro is.
Who in their right mind would replace a system where things like kio-slaves that just works is replaced by a non functional gnome-vfs if there wasn't some reason?. But still it happens. I tell you. The reason is simplicity and elegans.
Graphical user interfaces have been around for over 30 years, and the first time it gets any significant marketshare on everyday users desktops, it does so with MS Windows. That should tell you something on what way to go.
Notice how funny your argument reads? :-)
> A couple of years ago KDE was the only boy in town to count on. It had a market penetration in the free desktop of about 50%.
I still have to see numbers which claim that KDE has now less than 50%.
> Today that market is schrinking rapidly in favor of Gnome.
Reference?
> You almost can't open a webpage without being told how wonderful Ubuntuu, JDS or some other Gnome based Linux distro is.
You're reading the wrong webpages or only those writing about the latest hype (JDS!? Get real). And IMO people are more excited about Ubuntu (only three 'u') because "it tries to fix Debian" rathen than because it has GNOME as (up to now sole) desktop environment.
> Who in their right mind would replace a system where things like kio-slaves that just works is replaced by a non functional gnome-vfs if there wasn't some reason?
Nobody?
>Notice how funny your argument reads? :-)
Oops, that certainly didn't come out right. A little too late in the evning I think.
What I ment to do, was to draw your attention to Mac OS-X as the first resonably popular desktop unix system (have no idea why MS-windows slipped in). And by the way unix GUIs have only been around since mid eighties.
>> Today that market is schrinking rapidly in favor of Gnome.
>Reference?
Well, I have a consulting firm, I only have to look at what my customers use.
Sorry to have to inform you, this crave for simplicity and the shift to Gnome is a very clear trend. If KDE doesn't join in, it will be left behind, and others will decide the looks of the future free desktop.
You could argue that this is of no consequence, since KDE is GPL and as such it will never go away as long as there are users. Unfortunately, it isn't all that simple. The problem is that commersial software that get ported to Linux, FreeBSD or the soon to be free Solaris will use the dominant DE and such apps will stick out like a sore thumb when run on our favorite DE if it is built for Gnome. This will further enforce the trend of switching to Gnome.
>> Who in their right mind would replace a system where things like kio-slaves that just works is replaced by a non functional gnome-vfs if there wasn't some reason?
>Nobody?
Sigh, I only wish...
Evidently usability is nowdays valued higher than technical perfection and that is not a good sign for KDE.
> Well, I have a consulting firm, I only have to look at what my customers use.
Ok, so nothing representative. Those things differ very much from country to country.
stop being a troll, please. it's guys like you I hate discussing about anything most, because they take every argument, flip it in your mouth and pluck it into pieces, argue about the validity of fictional examples or exact source of some explaining figures. How about this: it is not about what you think it is.
>I could recomend some books on usability
I'd suggest you go read some yourself, since usability is a lot more than throwing out unsupported statements of clutter and basing all arguments on a made up type of users. It has to be based on the real world, and actual usage patterns not the chanting of "less is more". As an example take a look at, http://www.openusability.org/reports/get_file.php?group_id=44&repid=33 that's professional usability.
I'll suggest you read this quote by Ellen Reitmayr until you actually understands the real extent of usability. "would be more easy for unexperienced users, but come up with many disadvantages for the others."(on why a simplification should not be done).
And your MacOS "example" is not very convincing either btw, don't you think over 20 years of building their customer base has something to with marketshare. Their strongest point when marketing are still that they are Mac, not the Unix part of it.
As for your so called rapidly shrinking in favor of Gnome, that's also an usuported statement. In fact all statistic I have seen lately still puts KDE about 50%, as it has done the last 3-4 years. And the Ubuntuu hype are similar to the Xandros and Linspire generated hype for KDE, we saw a few years back.
>I'll suggest you read this quote by Ellen Reitmayr until you actually understands the real extent of usability. "would be more easy for unexperienced users, but come up with many disadvantages for the others."(on why a simplification should not be done).
I have no problem agreeing with that. However my suggestion have little to do with the advantages for unexperienced users contra disadvantages for more experienced ones. It would be an advantage to all users.
To have to deal with information you don't need is not good for any user. Not newbies, not experienced ones. E.g its a good thing if your car tells you its time for service, but its not a good thing if it insists on doing so when you are close to colliding with something and have to have your mental focus elsewhere.
I have worked with various Unix systems for almost 20 years, I still don't want to see things I only need for system administration when I do tasks that is not related to system administration. Just like I don't want to see grep, awk, and other apps that is not suitable to run in a graphical context the like in my K-menu or even when I navigate my files through konqueror. If I want/need them I start a terminal window.
>And your MacOS "example" is not very convincing either btw, don't you think over 20 years of building their customer base has something to with marketshare. Their strongest point when marketing are still that they are Mac, not the Unix part of it.
I think you are on to something. You are right, Apple doesn't have success with the Mac because it uses unix. It is because it enables their users to get their work done. The unix part is only there to provide a stable platform.
They don't give a darn about underlying unix file structures. they present the user with a GUI that works. They don't present the user with directories which contents can be better handled in elsewhere or with double clickalble applications that doesn't make sense in a graphical context. This is what makes MacOS special, and this that make people prefer it over various other DEs.
You have to remember that Sun, HP, IBM and others have also tried to get their share of the desktop in these 20 years using a more system centric approach, and they didn't have the same success.
>As for your so called rapidly shrinking in favor of Gnome, that's also an usuported statement. In fact all statistic I have seen lately still puts KDE about 50%, as it has done the last 3-4 years. And the Ubuntuu hype are similar to the Xandros and Linspire generated hype for KDE, we saw a few years back.
Can only hope you are right. It would be a big loss if KDE disappeared into the realm of the irrellevant. KDE holds far too much technical excelence to diserve that.
> You are right, Apple doesn't have success with the Mac because it uses unix.
Funny that you put "Apple", "Mac" and "success" in the same sentence:
"Apple Computer's worldwide market share fell to 1.8% in the third quarter of this year [2004] from 2.1%, and dropped to 3.2% from 3.6% in the U.S., according to figures from research company Gartner. The numbers also showed dramatic declines in the quarter-to-quarter growth rate of Macs sold while Apple's Windows-based competitors saw double digit increases in the U.S and an almost 10% rise worldwide."
(http://www.macobserver.com/article/2004/10/29.6.shtml)
Success can be measured in other ways than market share. When was the last time you met an unsatisfied Mac user.
"Sure, the sysadmin can have whatever resources appear within the home directory of each user. However, this sometimes pose a problem. How is the user to know that the resource is not entirely under his control? By putting the shared resouce somewhere else in the file system this becomes more clear."
Arrgh. I can't believe it.
You suggest a usability-nightmare ("hiding" stuff in the filemanager which runs completely against the purpose of the filemanager in the first place) for everybody to suit a very, very specialized case (the case in which some administrator is too stupid to put a symlink in the user's home directories or doesn't put a symlink because that would "confuse" users... Sheesh. The confusion argument has become a catch-all reason for everything.)
Goddammit, it's a file manager. It's purpose is to manage files.
> In my world, normal users are the ones who use a Xerox machine to copy a discette.
Ah, vintage memories.
It's also a total lie and fabrication.
If this is the kind of fictitious user you are targetting then don't be surprised when your userbase is just as fictitious.
"An example of things that could be borrowed from Gnome is the dual top and bottom panels."
Oh please God, no.
My laptop has a 1024x768 screen. Many people use this resolution or lower. Have you considered how much of the useable screen is going to be used up by a top panel, a lower panel, a window title, a menu line, one or two toolbar lines, maybe a row of tabs, and a status line ? You'll be left with a postbox-sized hole in the middle of the screen.
I thought the idea was to try and NOT overload new users with too much information.
Try using Gnome on a 1024x768 or 800x600 display (not TOO uncommon on laptops). A lot of your screen is used up by its overly-thick toolbars. This is one thing KDE does much better - at least the toolbars CAN be made thinner. Top and bottom panels visible by default will just make things worse.
As a thought, why not size toolbars, panels, etc, according to the screen resolution set (i.e. try and take up a (more-or-less) consistent proportion of the screen) ?
Actually, I'm writing this on a laptop with 1024x768 with a top and a bottom kicker panel.
Today the standard kicker panel is two rows high. Splitting these two rows into two separate panels doesn't make it use more screen space, but they will be easier to reach.
It will also be esier to utilize auto hiding as you may want to have some of your panel applets auto hidden and some other always visible. So in this respect I think the situation would be improved rather than worsened.
Your idea of scaling the toolbars according to screen size is very good, it would not only be a good on small screens but even more so on large screen resolution where controls have a tendency to get too small. I think the keyworkd here is Cairo.
I wonder how many people use kicker placed on the left or right. I do, but I have the feeling that it's not too popular, having seen the system tray broken in 3.4 Beta in vertical mode for quite some time.
Vertical space is usually more valuable - web pages, A4/legal pdf files,
just about any kind of text file. The only thing I can think of which benefits from a wider screen are movies.
Still kicker isn't really good to use in vertical mode. You can't make it very wide without wasting a lot of space for the K-menu icon and other big kicker icons - but this is both necessary and possible in vertical mode without hurting much, since the right hand side of the screen is underoccupied rather often, while I rarely see windows without a vertical scrollbar.
It would also be helpful if kicker could display window names in two rows in vertical mode. If kicker could be made work well in vertical mode, then we had plenty of space to waste.
About the hidding of directories thing, I totally disagree with that solution. That's just a work-around for the nightmare that the Linux distros' directory tree is. Following the way MacOSX went is the way to go IMO -- grouping and naming everything sanely. Some examples:
/home -> /Users
/usr -> /System
/lib -> /Libraries
/mnt -> /Devices
By the way, something cool would be an hidden file (ie. .folder) in all those folders to allow internationalization and setting an icon for the folder.
You people are freaking out over nothing.
"Trained ?"
Times are advancing mostly every kid nowdays own a computer or have easy access to one, and wen you are young belive me youll take 5 minutes to learn how to drag and drop properly, use rmb, and keyboard shortcuts in that time.
About the elderly folks or persons that never had any kind of contact with a computer and might have troubles learning. Thats the only ones that I can call newbs as its been labeled. Those are the kind of persons that dont actualy seek out how to use a computer, and if they must use it they will probaly get help out of it...
And if they need help then I belive it wount be that hard to find someone to teach them how to use the rmb to copy and paste files properly.
So all those raging posts about the holly buttons on konqueror toolbar are pretty much pointless imho.
What kde should focus is on having a clean apealing user interface, thats what will make tomorrows users, that are seeking an alternative to windows and have some computer knowlage, move to kde (why do you think everyone loves screenshots ? ).
- Why do you think XP change its look so much ? why did they remove the clutter betwen versions ? (because theyr evil... yeah)
- Why MacosX then (theyr creeps, ms bought them)
- Gnome... (yeah right, the propaganda machine)
All I can say is that Im a geek that started with kde 1.1 and I still use kde. Then I joined university (3 years ago) and alot of ppl that never heard of linux were being forced to use it (no guis there, unix, apache, and db related stuff).
Guess what. Most of the ppl I knew here and use linux at home to do theyr school work have gone with GNOME (why I ask them... they say it looked alot better than kde...). Even though I think feature whise its pretty damn crap compared to kde.
I think this is by far the best way to do it:
"Next release after 3.4 will be 3.5. We use the four months till the QT 4
release for implementing outstanding features and usability
improvements, integrating new artwork from kde-look contests, improving
documentation, completing translations, moving to subversion,
experimenting with a new build system, but don't do any QT 4 porting
yet.
The day Trolltech releases the final version of QT 4.0 we branch and
freeze CVS (or rather subversion then) for the 3.5 release and start
porting the HEAD branch (libraries and modules) to QT4. Then we proceed
with the alpha release scheme Stephan proposed until we have a KDE 4.
Not doing 3.5 and 4.0 development in parallel avoids the problems I
mentioned above and has the additional advantage that the QT 4 port
could be done as concerted effort by all developers, so that we quickly
get to a state where everything compiles and is usable for development
again. Maybe something like a "porting meeting" could be held to do
this in the most efficient way. Maybe also Trolltech could help with
this, the QT developers won't have anything to do anymore after the QT
4 release, after all ;-) "
This would also mean that KDE would have something to cempete with GNOME 2.12, ATI and Nvidia will tell you how important that is ;)
But, it's not just that, I think it would be easier for the developers and much much better for the users.
Unfortunately someone is trying to hold off the developers from doing bugfixing for the KDE 3.4 release. For example discussions about KDE4 build systems are started, discussions about additional KDE releases and to take away the last second of spair time the whole KDE cource tree has been imported into an experimental Subseven server so that everyone is testing subseven now.
Actual bug count:
Konqueror: 1763 - increased by 7 during the last week
kdelibs: 329 - decreased by 2 during the last week
kwin: 103 - increased by 4 during the last week
Congratulations to the KDE-Pim team:
kmail: 28 bugs less than a week ago
korganizer: 18 bugs less
> Unfortunately someone is trying to hold off the developers from doing bugfixing for the KDE 3.4 release.
Sh*t, you just disclosed our conspiracy...
Hehe ;-)
I'm sure you are here to help increasing the developers' productivity further by checking all those reports whether they still apply and respective validated or closed them.
Overall more bugs were closed in the last 7 days than new ones reported as reaction to KDE 3.4 Beta 2 - I don't understand what problem you have.
> This would also mean that KDE would have something to cempete with GNOME 2.12
KDE 3.4 can compete just fine with GNOME 2.1x
> ATI and Nvidia will tell you how important that is ;)
?
yeah, I didn't get the "ANI and Nvidia" too.
but I do think, while KDE 3.4 can compete with gnome 2.12 (it beats it, I'm sure) it would be cool to have a KDE 3.5, just to finnish the 3.x in a really cool way.
altough it's imho also a good thing to start on certain QT4 porting things. it would be esp nice if KDE-base and kde-libs would be in a QT4-ready state when KDE 3.5 hits the streets.
> it would be esp nice if KDE-base and kde-libs would be in a QT4-ready state when KDE 3.5 hits the streets.
It will never be able to compile against both Qt 3.3 and Qt 4 at same time.
Qt 4 will come with a compatibility library that Qt 3 applications can link against.
http://www.trolltech.com/newsroom/announcements/00000169.html
"Porting" is not the try to make Qt 3 code run with Qt 4's Qt 3 compatibility library.
it doesn't have to, KDE 3.5 could be build against the same (or just slightly changed) KDE libs as KDE 3.4 is. There can be different branches, isn't it?
> ?
The Gnome camp plans to migrate GTK+ to cairo and glitz, hardware-accelerated (-> ATi and nVidia) vector graphics libraries. I assume he's referring to that announcement.
However, this will take them a while, and Trolltech is talking about cairo integration in Qt4 as well. Bottom line, this is a non-issue for KDE 3.5.
thats not good, lets start before ! qt4 gets out so the final release for qt4 will be very very good and stable !!!
After reading through the religious wars regarding which build system to choose, I must ask, have the KDE developers considered creating their own build system? Some may immediately scoff at the idea of writing a complicated new tool when there are plenty of build systems out there. However, I think the mere exercise of planning out a new build system will address many concerns the developers have argued and others they haven't even considered.
While the developers argued viciously about the pros and cons of various build systems, there was very little discussion about what KDE actually needs. How can the developers make an educated decision when they don't even know what the requirements are?
Someone said the build system needs the backing of a full programming language. There seemed to be no debate about this statement. I submit to you that if you need to hack together complex rules to build a project, perhaps the build system doesn't meet your requirements. It would be easier to make that determination if we knew what the requirements were.
Unsermake was developed by our fearless release coordinator Stephan Kulow.
Derek
Maybe in 4.0 we can get rid of some overlapping apps, and specialize a bit more, like:
Kuickshow, Kview -- Two different image engines (imlib and ...?). Lots of overlapping functionality, none is quick enough for quick viewing or complete enough for image management. Aim should be a complete image manager (Like Kimdaba, or Digikam, or Gwenview) with photo importing abilities, and a really quick image viewer (only one-shot, or, at most, one-shot and slideshowing).
Juk, Amarok, Kaffeine, Noatun, Kaboodle -- Same as above. We need a media manager (amarok would be closer to that aim, if it weren't for GUI weirdness. Juk is not as complete, but okay) with support for ripping, visualization, etc., and a quick player (something like kaboodle, sans aRTs weirdness). I can't really tell if video capability is needed on the media manager, but, with a decent media backend, it should be so simple to implement (since we already have visual effects) that it wouldn't hurt to add just to please ppl who find it useful.
Kate, Kwrite, Kedit -- If Qt4 supports RTL decently, Kedit isn't needed anymore. Kate is something between Kwrite and Kdevelop/Quanta/Kile. I don't really see the need for both it and Kwrite -- If Kate is lightweight enough, there's no need for Kwrite, if it is heavyweight, just open Kdevelop.
KSirc -- It is a usability beast. Konversation, although not perfect, is way more usable...
Rethinking apps within a new KDE context will only be possible for the apps which are actually within KDE's standard packages. Most of the ones you mention are not.
And perhaps whats in the standard packages, needs rethinking. The fact that they currently arn't is not any reason not to consider them, or improved versions of them.
If Kate Part gets BiDi support, KEdit may be deprecated, but KWrite/Kate pair will stay, KWrite is just a easy version of Kate, and I see no real clash between Kate and KDevelop/Quanta, me doesn't want to start an IDE or web development app to work on bash scripts or to play around with SML ;)
I don't see why there needs to be an "easy" version of Kate. As far as I (and I would add any inexperienced user) can see at a first glance, Kate is Kwrite with MDI. If you just ignore the Sidebar, using Kate is no different from using Kwrite.
kwrite is actually as lightweight as kate, and i didnt know about kedit
afaik ksirc isnt cpp project so it must die