Polls are an oft-requested feature of the dot. KDE.com has risen to the challenge with its latest user poll: "What Should Be the Highest Priority of KDE Developers Leading Up to KDE 2.2?". I just installed Linux Mandrake 7.2 (until my SuSE package arrives), and after upgrading to KDE 2.1.1, I feel that a KDE port of the configuration utilities could bring a huge amount of polish to this distribution. A KDE interface to Linuxconf might be a good start. Others would however prefer a KDE installer, and some simply think that KDE should be faster and/or less of a memory hog. Here's your chance to cast a vote and voice an opinion.
Dot Categories:
Comments
#1 for me is m$ import/export filters on koffice apps.
#2 gnome has the option to 1) close a window 2) nuke it (or somesuchphrase). i think that's handy. in kde i have to open up a terminal and kill -9 it if it's frozen. (i.e. every 5 minutes with netscape...)
#3- more stability. stuff in kde 1.x used to crash once in a blue moon, kde2.1 on my computer is certainly no more stable than windows 98 (eek!). personally i put stability _way_ above things like animating/fading menus etc. (lack of stability is one of the things that moved me away from windows in the 1st place...)
great job with kde 2.1 'tho folks, i've been raving to all my friends about it since installing it a few weeks ago! #:-)
p.
Regarding #2: Press Ctrl+Alt+Escape or whatever you have defined under Look&Feel/Key bindings and click on a window.
for #2
Hit Ctrl-Alt-ESC and you'll get a skull as your mousepointer. Now click the desired window and it will go away *g*
And if you want to be really sure (for instance about netscape which likes to close its windows and still run in the background) open the minicli (Alt-F2) and type "killall -9 netscape".
#1 - in work
#2 - covered above
#3 - I'm running KDE 2.2 alpha and it's rock steady. Of course I compiled it. However from 2.0 on it's been good and getting better. I can't remember the last time KDE crashed and with stable releases app crashes are pretty rare. Admittedly some system configurations or other things can be a problem but for the most part stability issues are configuration related. If you have stability issues iwth KDE maybe you should look into this? I have a desktop up sometimes for months.
#1 - in work
#2 - covered above
#3 - I'm running KDE 2.2 alpha and it's rock steady. Of course I compiled it. However from 2.0 on it's been good and getting better. I can't remember the last time KDE crashed and with stable releases app crashes are pretty rare. Admittedly some system configurations or other things can be a problem but for the most part stability issues are configuration related. If you have stability issues iwth KDE maybe you should look into this? I have a desktop up sometimes for months.
thanks for all the follow-up's folks. i should perhaps qualify #3 a bit further- the desktop itself has not (in about 2 weeks since install) failed once, although in a typical day i seem to get about 1 or 2 of the key applications (normally conquerer i guess) falling over at some time.
Completely agreed on #3.
When I'm using an app, and I decide to start another app, either by the panel or a menu option, I don't want the launched app to appear on top when it starts, nor do I want it to grab focus. What I want is:
* focus follows mouse
* focus stays with whatever currently has focus, unless I change it by clicking somewhere else
* No windows are ever created on top of the window which currently has the focus
I haven't found any window manager or desktop environment that does this.
Yes!
This is interesting in so,e case:
When I right click on link in konqueror,
and choose "new windows",
I don't want to see this windows on top.
I would like this for opening new windows in konqueror to open behind it
Does this exist? An installer such as the ones in windows. You click on setiup.exe and it asks you several questions such as aggree on the terms and conditions, directory to install, packages to install, serial number :))), etc.
I've never understood why people want a KDE installer.....unless they mean a KDE frontend to rpm -i or (or other distribution / OS equivalent)
I think a lot of people don't realise that package management and installation on Linux and other Unixes is actually better than windows.
Windows 9x has NO standard installation and package management tools besides a registry key for adding the name of your package, and the uninstaller.
So as a result every program has a slightly different installation procedure (though usualy rather simple) and dependency issues are difficult to the point that most software always installs everything it needs to run, which can result in DLL version hell...
besides you cant really get much simpler than rpm -i *
What I want is a multiprocess web browser, like IE. It stinks to have ALL browser windows disappear because of some bug triggered by a badly written web page.
Process switching under Linux is extremely fast, and besides improving stability, so making Konqueror multi-proccess would actually increase it's speed as no locks would be needed to protect access between several threads to shared data. Have you ever notice how slow goes Konqueror when you open more than just a couple of windows?
I agree that threading Konqueror *could* make it faster. But it is absurd to think that this would somehow lead to increased stability. Threading is very difficult in a complex application such as Konqueror and would need extensive testing before it would stabilize. Not to mention how hard it is to debug a multithreaded app.
Matt Newell
I said "multi-process" as opposed to "multi-threaded". Each browser window is conceptually independent of the others (except maybe for some popups), so I really can't see why it can't be multi-process. It would only involve the use of some locks to control access to the history and bookmark files...
I forgot to say: every unix program is multi-process by default. Try this on a xterm:
$ xlogo &
$ xlogo &
$ ps
See? xlogo is multi-process...
Even if you need launch a process from another one all you have to do is fork()...
Memory protection is a Good Thing. IMO, since process switching on linux is fast, the main reason linux programers use threads (or single process programs) is because they're too dumb or lazy to use IPC.
You gotta be kiddin'. Processes take up memory and are slow to load on Linux (given the large number of symbols that must be resolved). A large program like Konqueror, which links with many libraries, can take a while to load. Notice the difference in time lag between the first Konqueror window you open (make sure no konqueror shows up in 'ps -auxw') and subsequent ones?
And no, people don't use threads b/c they are stupid or lazy. Threaded apps are quite a bit harder to write than ones that fork. So people who use threads are both smarter and more diligent. Threads have a number of advantages, like (a) memory consumption, and (b) speed.
New processes which must exec() are slow to load, fork()ed processes using the same code (i.e., no exec()) are fast.
And yes, many times people use threads because they are stupid (or brainwashed) and lazy. There are some applications where threads are clearly preferable to processes, mainly in programs where most data is to be shared, but different browser windows don't need data sharing except for cache and bookmarks, so using threads is just plain stupid.
People usually learn the advantages of threads from OSs where there's a big difference in the timings for thread switching and process switching. Linux has a one-to-one mapping between threads and processes, so it doesn't apply here. About memory consumption, using threads buys you *nothing* if the data accessed by different threads/processes isn't the same, as is the case with browsers, and you have copy-on-write fork().
Actually, IE is worse than Konqueror in this respect...
If IE locks up for some reason...your entire desktop is frozen....and when IE crashes, every browser window, explorer window and even the start menu and taskbar all disapear.
"What I want is a multiprocess web browser, like IE."
HAH! That's really funny. I *wish* IE was a multiprocess web browser. In actuality, it's all one process, and sometimes it seems like the entire GUI is being run in the same process. An IE bug can take down not only ALL your browser windows, but all your other applications, your desktop, and even the OS kernel!
Making Konqueror multi-process would take much more memory. I think what should be done instead is Konqui should keep a temporary file with the URLs of the sites that are open (or install a crash handler that would do this). Then if it crashes, it could just open the sites back up again (asking you whether to open each site of course to avoid infinite crash loops!)
A "Save State" menu option would be nice too. Imagine saving the state of all Konqui windows on your computer at the same time!
"making Konqueror multi-proccess would actually increase it's speed as no locks would be needed to protect access between several threads to shared data. "
I do not think Konqueror is a threaded application. QT is not thread-safe, or at least it wasn't when KDE 2.0 came out, so I don't think it would be possible to use threads in Konqueror.
Your wish has come true: look at the configuration options of IE and you'll find a tiny little check box, disabled by default, to make IE multi-process. I've been using it since I installed IE5 the first time. It rocks. And no, I found no noticeable slowdowns compared to the default multithread behaviour.
One small drawback: a different process is launched only when you start IE again and copy/paste the link. "Open in new window" will just launch another thread.
As for multi-process taking a lot of memory, this isn't but a misconception: the linux implementation of fork() doesn't copy the code to the child as it's read-only. This way, even if you have 100 processes forked from the same parent, there's only ONE copy of the code for all of them, but a private memory space for modifiable data pages for each one of them. If only what's conceptually distinct (the data) is private, there's no memory waste: data for each open document would exist anyway.
"you'll find a tiny little check box"
Oh yes, I know all about that little checkbox. Problem is, it has disappeared from my IE options! I think it happened when I installed IE 5.5. Anyway, it's gone, and so IE is all single-process for me. It also doesn't change the fact that Windows is a bad OS and any process can crash any other process and even take down the kernel.
About memory usage: each new instance of Konqueror started from the panel takes about 10 MB, while opening a new window of an existing instance makes the exsisting instance about 1.5 MB larger (rough figures obtained from KPM, your mileage may vary). I don't think Konqueror is forking itself, but it is being forked off of kdeinit, if this makes a difference. If this is the case, then the question becomes: why is Konqueror not forking itself? That would give stability _and_ low memory usage! (and probably faster startup as well!)
It _does_ work this way. If you start a new Konqi window from an existing window they share the same process, but if you start a new window from the Panel it is a seperate process. The memory footprint for konqueror is around 5MB-20MB depending on how complex the page is.
In fact...
I didn't know about this. Thanks a lot for the tip.
Now it should be extremely easy to add an "open in new process" entry in the context menu of a link...
Another solution for this problem would be if konqueror cud remember what pages you have open and the current state of all pages, so when konqueror does crash, it can reopen all pages automatically (except for the page that cause the crash)
Just received this reply to my message to the konqueror wishlist:
Update to kde-2.2-alpha1, there is a kcontrol setting for when to create a new process and when not to.
KDE is like a song from the Beatles' Sargent Pepper's: it's getting better all the time!!!
To those who want a multiprocess application,
I wonder which debugger tool you guys use to develop multiprocess programs for Linux. I chose multithreaded programming because I can run 'ddd' to track my program, but I din't find a proper tool to debug multiprocess program.
Bernard.
I remember we had a KDE2 wishlist. Couldn't we have something similar for future releases of KDE? It would be great if it was arranged the same way as the old one.
bugs.kde.org has an integrated wishlist. You can submit a wish at any time and the developers will see it. It works quite nicely.
#1 is SPEED and STABILITY !!! while stability is better than speed , it crashes much too often to work with.
#2 Able to choose which Programm can reside in Memory for faster startup , because most of us have very much ram , and i can hold the complete kde in ram if i want to , and that would be very cool, (no i dont want to copy it on a ramdisk)
greetings..
Careful Chris,
They will call you a "troll" if you say that!
Regards,
James Alan Brown
Nah, only if you continually bitch about problems others don't have but never submit even submit a real bug report ;-)
Opps, bad grammar again - just woke up and trying to multitask with email... wonder if me will correct me (grin).
You wakeup @ 10 to 12! Man that's a life. Of course you work all night though but still you're in mosfet's own timezone.
Well, I'm no longer employed right now so can sleep as late as I want :)
I really miss the browse button in Menu Editor... It is really difficult for beginning users to add gnome / X / terminal applications to start menu if they do not appear there automagically.
I really would love imporovements on kde help center:
* the ability to add books, like the NAT, downloaded books, howtos etc
* possible inclusion of kde, qt, .. api docs
* the search feature can be improved with more details: search only this book/app, select
The helpcenter should be available as a sidebar/tab in konqueror.
1. Browsing windows shares. All clients are configured to authenicate with a central password server. It would be good to be able to connect to SMB shares using the current login name and password. Oh, and have access permissions as per your restrictions on the SMB share.
2. IMAP server availability in KMail. 'nuf said on that one.
"IMAP server availability in KMail. 'nuf said on that one."
KMail 2.2alpha1. 'nuf said.
At this moment in time, it's my belief that KDE is not only perfectly usable now, but more so than its MS or even Apple competitors. For what it does in the way of a user interface I really do believe it is either the best, or the only thing I've seen on the right track to being so.
The basic question here has to do with what applications are missing. I've read the previous posts here talking about config tools, office apps, and browsers. I think this misses the point a bit. Konqueror is making tremendous progress, and only rarely do I need to fall back to some other browser to properly view a page. It also looks like KOffice is on the road to be something really exciting. The config issue gets back to the core of what I'm getting at.
From what I've read, and personal experience it would seem that the core of the *nix user base is comprised of system admins and webmasters looking to work on the box they're designing they're work around. On the web side, it is encouraging to see Quanta making significant progress. Thing is, there still isn't any GUI application that compares with Macromedia's Dreamweaver. Please, if you've only spent five minutes looking at it, scoffed, and went back to emacs you can save your reply. This is a hugely powerful web designing platform without any *nix equivalent. I fully realize this would not be a simple app to develop, but if KDE is looking for that "killer app"(tm), that would be it.
On the config side, there are some areas that I believe KDE should step into, not specifically relying upon a distro. X configuration comes to mind. A GUI should be the place where folks adjust the GUI. KDE, Konqueror, and Samba should be something nearly synonomous with each other. Not only to look at shares, but to create ones. Other front line daemon configs could also fit in here, such as Sendmail, QMail, Inn, Apache, or even IRC. These kinds of things aren't distro specific, and well thought out config tools for those kinds of core Internet services would be a killer app for KDE with admins and users alike.
Linux, the BSD's, and the like may not be ready for converting over the generic Windows ME user (god help them), but it could be made very ready for the core users that are here now. Convert the already faithful, and they'll bring many more to the party.
DISCLAIMER: I may be dead wrong about the make up of the bulk the *nix crowd. Even still, defining exactly who is now using these operating systems will make decisions like what are the next majorly important applications to develop that much easier.
> On the web side, it is encouraging to see Quanta making significant progress.
Thank you! I'm depressed that we have not made more progress on DTDs, intelligent tag management, autocompletiion, templating and a few more things... but at least we have got our infrastructure in place and these things can be done much quicker.
> Thing is, there still isn't any GUI application that compares with Macromedia's Dreamweaver.
Yeah, Rich Moore is pretty hot on Dreamweaver and we have discussed some of the UI concepts and how we might learn from and improve on them in Quanta. Also there is a wysiwyg web tool for KDE being developed and that is Kafka in kdenonbeta.
Here is what is on the horizon with Quanta. For one there will be a new rich text widget in QT3. We've thought about doing a wysiwyg part for Quanta and something like that will happen, but not likely a full implimentation any time soon. Our current design objective is partial wysiwyg for a few reasons.
1) wysiwyg editors are notorious for disregarding the integrity of your code so we have to address that.
2) most importanly wysiwyg editors primarily are good at static layout... and let's face it that is largely history on the dynamic web!
Our focus is to have graphical layout tools to enhance and accelerate layout design, but to really focus on development tools, like our primary PHP focus, to enable far greater productivity here.
Please note that Quanta is not just an "I want to build an app" web tool but a product by and for professional web developers. It is also intended to be quick and easy to pick up by people new to web development and usable by newbies... but it is not focused on being a "so you want to build a home page" tool. Kafka is much more focused in that direction. Unfortunately it is not very usable yet but it has some sharp people working on it.
We believe that this year Quanta will become a truly killer app on KDE and we are focusing on that. Currently we are in the 99.9% activity level at source forge... so we can comfort our impatience with the idea we must be doing something right. ;-)
I agree that Quanta is a great application. In fact it has been the one app that has enabled me to persuade several people to use KDE / Linux rather than that 'other' choice. In a similar vein to the kdevelop thread though, I would like to know if there are any plans to embed kvim as the editor. Granted, the kwrite thing is easier for newbies, but I find vim far more productive than quanta.
It would be nice for example to go
:gg
=GG
In quanta to autoformat everything like I do about a zillion times a day in vim :)
Another feature I would really like to see in quanta is an object tree browser (ala kdev) so that I can see all my php classes and drill down to a given function, bringing the editor to that place in the code.
Vim + code completion in quanta = killer app!
Tim
Sorry, make that
gg
=GG
:~)
Thanks for a great reply Eric. As a follow up I'd like to illustrate how Dreamweaver fits into my web development for a dynamic web site. Just one little ol' perspective out here.
Pretty much any page I'm going to be working on starts in Dreamweaver today. Yes, even if it's to be a dynamic database fed page. I start by dumping in dummy data into tables so as to get a visual feel for how the data will be laid out. All the graphics and tables are put in at this point in the process. When I'm cool with the look, I'll replace the data with the variable names right within the GUI editing.
Following this initial layout work, I would then pull the source code into HomeSite and add in my PHP code to fill in those variables. This process drasticly reduces the amount of code I have to type in since darn near all the HTML is already in place. Lines with variables just get the framing PHP tags and a print statement added.
Where this is a decent time saver for doing results layout, it's invaluable when designing a fairly complex form with different types of input tags. Within DW I fill in default values with variable names, and name all the objects. By the time I get the file into a text editor, again all I need do is add some framing tags and a wee bit of code to make it all work dynamicly.
I just fealt this kind of perspective might be helpful in how a GUI based editor truly does fit into the dynamic web. At this point on Windows it requires both a Dreamweaver and a HomeSite combo to get this kind of thing to work nicely. A single integrated product that works this kind of thing would be a very appealing application for webmasters of all sorts I would think.
Lastly, since we're talking about Quanta I need to get a couple of wishes plugged in here :) Snippets and Server Mappings, both of which are HomeSite features sorely missing from Quanta.
Snippets are small bits of code that get stowed away into a dir of their own to be inserted into the active file. Instead of trying to map all kinds of funky key bindings, you just get an extra window allowing for multiple bits of code that can be double-click inserted. Over in HomeSite I've got a personal library of about 50 of these little buggers, broken down into subdirectories and such for organization. That's easily the biggest thing I miss when working with Quanta.
Server Mappings are used as a redirect for previewing files. The idea here is that directories on the local hard drive are mapped within the editor to an http domain. This allows your server side scripts run through the local web server for testing. Puts Apache to work for ya.
Okay, rant over... thanks for the ear.
I would like to have a font engine to render Indic fonts with Unicode. How about Devanagari for a start?
My dream is a Linux desktop supporting all major Indian languages, at least one in each Indian village.
I am ready to be a part of the KIndic project.
Thanks for all the good work.
Regards,
Sandy.
Now that QT 2.3 and KDE 2.1 support true-type fonts, all you need to have Indic font support is to find .ttf files for Indic fonts and import them into your X11 truetype font list.
If these truetype fonts don't exist, you can probably find someone who is working on making some.
Other than that, you may also want to join the KBabel project to create KDE localizations in your preferred Indic dialect.
--bfelger
It's not quite as simple as that. To properly display Indic languages requires the displayer to pick the right glyph for each letter. It's like English had four different forms for A, and the user just hit A and the computer had to figure out the right form to use, depending on where it was in the word.
Two small ideas:
1. cvsKIOslave:
type cvs:pserver: ..etc..
at the location bar in konq and you get a list of the
available modules.
Move a module to the Desktop and you checkout
a version.
(I know cervisia, but a tighter integration into kde would be
cool, and KIOslave seems and obvious choice. For
browsing the local checkedout version cervisia as
a kpart could be an idea, konq could be made to switch
to cvs mode when such a directory was entered.)
2. Singlet app.
Make an option for the application launching buttons in
the panel that only one application will be launched at a
time. If the button has been pushed before and the app
is still running it should be brought in to focus, just like
pressing on the taskbar. This is mostly for newbies to avoid
them having fire up a flood of identical application while
waiting for a slow app to start.
My kids do this all the time :-)
The last suggestion seems so obvious perhaps its already
implemented? If so please tell me how to use it :-)
Sune
> 1. cvsKIOslave:
> For browsing the local checkedout version cervisia as a kpart could be an idea
Funny you should mention this... we have been discussing these very ideas wrt to cvs implimentation in Quanta. Our ideal scenario is waking up and finding out Bernd did it. ;-) But if we could ever crystalize how we wanted to handle some of the particulars we'd like to contact Bernd (Cervisia's author) and launch into it.
I'm afraid your 'ideal scenario' won't happen
as my priorities are very different at the
moment ;-(
Of course, that doesn't mean I wouldn't like someone else to work in that direction :-)