This is really cool. The best would be the ability to resize individual icons in an easy way. For example, if I wanted to see just a little more of a certain document (or in this case, see a little more detail), I could put the mouse over it, hold the right( or middle ) button down, and drag. This goes for those alpha-blended previews we saw last week, too. Nautilus has something similar with it's document preview, but you have to right click, choose resize, and then resize the icon. A fast way to do it could be very helpful.

I dont think it would be possible, because KDE makes previews in a directory (.pics for exemple).
Since the preview is calculed previewsly, you shouldn't be able to modify it that way...
It s not a preview then. I don't know this
(sorry for my english)

Text preview has already been implemented by Carsten about two weeks ago. If HTML preview is off, it also handles HTML files, otherwise it is used exactly for "all but HTML documents...", as long as they are some sort text files. If you enable alpha-blending, it also blends in the normal icon for the file so you can still quickly see if it's a C source, a header, just a plain text file...
Of course you need a recent snapshot or a CVS checkout of KDE for it unless you want to wait for the upcoming 2.1 Beta.

So how fast is this? Will the display of the previews cause a delay in useage of a folder with many .htm's, or will there be some kind of placeholder icon that gets replaced as each page is rendered so that we don't have to wait? I'd really like to try this, but I'm wondering how my K6-2 400 would handle it...

On my PII 500 it takes about 1-2 secs for an average HTML page, if a thumbnail didn't finish rendering after 5 secs, it is cancelled.
All this happens in the background so you can use Konqueror in the meantime of course. It surely takes some cycles so the file manager might be a little less responsive, but still it's not blocked.
Also, if the directory is writable, the thumbnails are cached in .pics (just as image previews are already), so next time the HTML pages need not be parsed and re-rendered again.
Hope this helps.

I know you're probably sick of all those "how about this and that", but too me it seems like the way Windows handles it might be a solution(not _the_ solution). Have the preview generated in its own "view", split the treeview in two, and have the bottom view display the preview of the GIF/HTML/C-source file when the icon is clicked/marked, with its filename as its title. This might be what many users will prefer, but of cource people with dual P-IV will have all their icons in preview-mode.

Just $0.02, and it would not be so hard to implement now that preview allready exists.

Normally in Konqueror, once you click on a file it gets displayed in your active view. I'd like a feature where the display can be in a dedicated view, so I can browse and view my files more quickly.
That could be a good solution, too.

I agree with Klas, I really miss the opportunity to dedicate a view for previews.

When for example programming, I often want to view source files for reference, and going through the trouble of unlocking/moving/locking each time I change the dir is cumbersome, and so is finding my way in a large directory structure in tree mode.

Maybe I have grossly overlooked some option, but this is the first time that I have seen the History tree in konqueror. Could someone tell me how to do this? Is this a new feature only in CVS? Could bookmarks be implemented like this as well?

Select "Go" from the menu, and then select "Directory Tree", you can then add and modify anything you want in the directory tree.. Check the attached screenshot to see how I've made it :)

The preview stuff is great. What's really cool is that I don't even notice that this is going on, and konqueror doesn't slow down AT ALL(!!) when using all of these previews. And after it's done once, it pops up in less then 1 second when re-entering the directory. But a preview window below would be really cool too, so when you click on a file a larger preview appears in the window below. Also, check out my Napster shortcut in "Network". It's a shortcut to the napster io-slave, and when clicking that icon I get the search html page up and can search for mp3's on Napster.

Also note that the icons I've choosen are medium, using larger icons will give you larger previews (and smaller ->).

Another cool thing that's been added, and that you can see in the screenshot, is that you can select to have either the 5 most frequent used or the 5 most recently used applications on top of the kmenu. This makes getting to those often used programs even easier.

There's also been added a smaller kpanel (now you have: tiny, small, normal, large), this is great for us that wants as much desktop space as possible.

If anybody wants more screenshots of new features, then please say so and I'll make more and send them :)

Well this let me to another thing:
The configuration option for the directory tree is nice, but it is a shame that it only accepts directories!

Say I wan't to have a link to my PIM data there, like my calendar and address book - korganizer works completely fine inside konqueror, and it probably wouldn't be that hard to define a view for .kab files...

But it dosen't work. Actually confusing, since Knoqueror includes the new->link to location option when I go to Go->Directory tree.

It seems that the directory tree can only accept directories or http/ftp urls, whereas a link to file:/home/anders/anders.vcs makes it complaint that it expects a directory. (kde 2.01)

Konqueror is already looking absolutely fabulous. I think that it should be called the "Universal File Viewer" because that seems to be the direction it is heading in. The only thing it needs is to get rid of KHTML (which frankly is not really all that good, especially at JavaScript) and use Gecko or something similar. That would allow me to finally delete the powerful but slow and klunky Mozilla!

Why should they get rid of KHTML - it doesn't do JavaScript that good right now, but otherwise it supports most of the w3 standards you can find, and I bet it's JavaScript support will be much better soon.

I really just don't like KHTML. The reason : it's too good. I know this sounds stupid, but KHTML works really well when it's handed clean code, when it dies is when it runs into a badly designed site. Technically, it supports all the JS calls, but only if they are done to spec. Unfortunately, almost 95% of the sites on the net are either done by idiots who use badly designed 5 year old WYSIWYG HTML editors on their iMacs, or WinNT/Novell fanatics. That's why gecko is so good : it's based off spec, but because that makes sense because most sites are off spec.

I suppose that it would also make sense to fix KHTML to be able to deal with stuff like that. But the reason I reccomend Gecko is because it's the most advanced (with ability to view the largest amount of sites), and the spirit of open-source is based on finding the best available, and improving that.

Or, perhaps we could have a project merge, or a Gecko/QT port? Kecgo or GecKo sounds nice.
Anyone who wants to see a demonstration of KHTML's excpectations that sites be spec, go to www.littleguitars.com, (that address might be wrong), and watch as Konqueror sucks proc cycles until you are forced to Ctrl-Alt-Bksp.

Please don't take this as an anti-KDE flame. Just because I don't like a particular kde project doesnt mean i dont like kde.

According to this post on this site, Corel is working on a Qt port of Gecko - if that is true, your will soon be able to use Gecko...

But I still haven't seen any documentation on why KHTML isn't good - sure it maybe fails to render www.littleguitars.com (I haven't got access to Linux/KDE2 from where I am now), but as I said before, JS isn't that good supported in KHTML yet, or that is what I've heard and the above site contains broken JS code. But please come with some more facts? I've tried it with numerous sites, and one of the only sites I've seen it doesn't render properly is www.zdnet.com.

I'm not running KDE right now, so forgive me if this isn't quite the correct spot...

This is somewhere in Konqi's control panels, as a text field. It's not a checkbox or anything...it's a user-agent checkfield. Right now, it probably says something like Mozilla 4.0 (compatible; Konqueror 1.0). Internet Explorer's string is something like Mozilla 4.0 (compatible; Microsoft Internet Explorer 5.0).

www.merckmedco.com (even if you don't have an account, any entry in the login box complains that the entry was empty)

www.ebay.com (unpredictable crashes upon doing a search in the keyword box)

apps.kde.com (a memory leak problem upon loading the view that has many frames [of course, IE has this problem as well]).

I'm not saying that we should abandon KHTML! As I said before, i'm not dissing it, I'm just saying that we need to realize that it isn't compatible with certain sites. These problems must be fixed!

Also, perhaps some of it is not neccessairly related to KHTML. Perhaps it's a problem with distros. In any case, we really need to either fix KHTML or replace it before Konqueror can become fully usable as a web browser. It's already a totally awesome file manager (whups windows explorer into many tiny sized chunks), but it needs to be improved.

P.S. This is a great example of what is so cool about Open-Source, and in particular, KDE. A great big debate is being started over this issue, and in a large company that uses a totally proprietary development mode, these sort of problems simply get stashed in someones 'in' box, often to be ignored.

Sorry, but Netscape 6 that is based on your favorite HTML engine crashed after 30 minutes of use after installation (first run). And now I can't run this "browser" again. Even after reinstallation.
And I don't want to speak about its speed and rendering of pages and visual interface - this is pre-pre-pre-alpha version in fact!!! I didn't ever see so many problems!
So, sorry, but really, the place for all this "Gecko" is in trash. From my point of view two years of development produced only a big, huge piece of shit and nothing more :-(((
Yes, konqueror not always working properly. But it is possible to say this about _any_ browser, even IE. In most cases konqueror working really good. Even with JS. Of course, it crashes often on one of my favorite websites ixbt.stack.net, but I'm really shure that this will improve. Because the konqueror becomes better every day. And I can't say this about other such projects.

Ok, first of all, this borders on flaming. Second, I already stated that I think Netscape 6 and (to a lesser degree) Mozilla stink. The rendering engine is what I think we need to either port or borrow code from. The part that dies and slows down the system are the basically unrelated to web browsing composer, email system, news browser, chat engine, stock and news quote checking, and other misc. stinkiness.

Also, I'm not advocating against konqueror! This is open source : what I'm suggesting is ways in which we might improve it! You seem to take my message as a suggestion that we should ditch konqy! Nothing could be further from the truth.

Konqueror is modular. I think it was designed so that even if some functionality (like khtml) is not fully working yet, it does work where it can.

khtml is just a part, a lightweight (better designed, that is) simile to activex document/control for you windo$e oriented. khtml lives its own life. kthml it's not the main element of konqueror as far as I can tell (I'm not developing kde). In fact (again, kde developers correct me please), konqueror doesn't vitally depend on khtml. You can make it browse any document for which a kpart exists. Say if you feel like implementing .rtf renderer, just write a part. You don't need to even touch konqueror, yet konqueror will use your part to render .rtf files when you configure filetypes right.

khtml will improve, and if anybody cares to implement gecko renderer as a kpart, he/she would be probably better off starting with qtscape/qtzilla (get it from trolls site). It MIGHT be nice to have two html parts of different implementations... but what for if khtml is going to be more foolproof than IE anyway in a year or two.

khtml is important, but not most important, and konqueror doesn't equal khtml ;-)

Gecko renders better than khtml, even if khtml is a close second and is far better than all the others (except gecko).
As an example (and just an example), with CSS, you can redefine bullets of the UL LI tags, using images. Unfortunately, Gecko aligns then to the top of the text (like IE5, btw) while bullets should be aligned with the baseline of the text. Gecko does this fine.

Well, maybe Gecko is a web developers dream, but in many ways KHTML is superior.

E.g. often when loading a large,complex page A Gecko-based browser processes all content and then displays it all at once. Konqueror OTOH starts rendering the page immediatly, adjusting the page dynamically. This is much smoother, especially if you're using a 56k connection.

You should try Gecko, because it is the faster rendering engine for html available. I do not say that khtml say has to be disposed. I just say that gecko faster and more accurate for standards.
Really, I have just loaded a few slashdot pages and then resized the window
Everything is done the same way you describe it for khtml. The display is changed dynamically when elements are received (for instance the gif ads appear when they are loaded, and the page display is then redrawn for them).

Mostly, the slowdowns are not a gecko thing, but rather a problem with the browser frame around the rendering engine. Netscape 6 and Mozilla both use Gecko, and they are slow because not only do they do web page rendering, but also:

Email reading and composing

News-browsing

Constant updates with "My Sidebar" to display such information as "What's related", "tinderbox", and stock quotes

Web site WYSIWYG composing

Chatting (Netscape with AOL, Mozilla with Chatzilla)

Also, all these things are actually internal in the binary, as opposed to Konqueror's system of dynamically loading plugins.

That isn't what I said. I said, the way open source works now is to take whatever is the best option available and improve it. The point of open-source is to avoid wasted programmer time by needlessly copying code that already exists in someone else's program. At the moment, Gecko is capable of viewing more sites better then KHTML is (at least to my knowledge, I haven't being keeping current with the latest CVS). This isn't meant as a dis to KHTML, since we aren't in competetion anyways.

I totally agree. You see, I said the best option. It's up to the developers to decide that. Although I'm doing a little coding, konqueror is outside my forte by a large degree! Seriously though, if the people who do konqueror would rather use khtml, then fine, they can! Signals and slots seem a little redundant for a html processor, which is mostly built on a parser system, but that's just me. I trust the konqueror team to do this properly, even if they decide to use the lynx html rendering engine, because their fabulous work so far has me drooling!

I perfectly agree. Konquorer is very shoddy in
rendering java script. It takes too much time and
even then does not do it correctly and sometimes
does not even do it!!! Even Netscape is pretty much
faster than konqueror in rendering java script
This is something which should be very urgently
done. This can really harm people who are planning to switch to kde.
To view a javascript page, you will have to separately start
netscape.

Not to diss the developer since any additional work is great but in the big picture this is kind of a trivial addition. After all thumbnail previews have been a feature of xv since prehistoric time ....

Adding a DAV IO slave so that Konqui will work with mod_dav enhanced apache web servers (and with apache 2.0 which includes DAV) is a bit more important task and perhaps more involved. But given the API of Konqui/KDE and the wealth of info and libraries and info at webdav.org I can't for the life of me figure out why this hasn't happened. A knowledgeable Konqui developer could likely add DAV support in a day.

I guess the problem is that not many developper's ever use DAV enabled web servers or clients (IE 5's "Web Folders" are the only popular implementation in use). Many users probably view DAV as a "web developer" issue.

But DAV is **not** just about web editing or "replacing frontpage" (it would be worthy if that was all it was): it's about version control, locking and seamless collaboration using HTTP. In fact Greg Stein joked that DAV may become the "mother of all protocols" given its extensive features (see http://www.webdav.org).

Decent DAV support in a client can create possibilities for shared applications like calendars, mailbox files, etc. etc. all over the web. DAV is a HUGE "under the radar" (like linux used to be) project - a standard for which support will be necessary in the future. The sooner it gets included and debugged by users the better.

BTW Gnome's new desktop filemanager thingie supports it, so it when it finally gets out of alpha there will be a working proof of concept for how to support DAV in a filemanager style client.