In this week's KDE Commit-Digest: Introductions of a Dictionary, Photoframe, and Facebook Plasmoids, and a Weather and Solid DataEngine in Plasma. Usability improvements and optimisations in KListView, used for icon views in Konqueror and Dolphin. The start of a shared, common location for vocabulary files across KDE-Edu applications, with initial implementation in Kanagram. Support for application-specific caches in the Icon Cache implementation, and further progress in the KOrganizer Theming and KRDC Summer of Code projects. Better support for ALSA in KMix. Umbrello gets support for SQL code generation. The start of enhanced animation support in KPresenter. Scripting interaction with Yahoo! web services to provide weather and stock quote information in KSpread. Advancements in the KTorrent port to KDE 4. The creation of the PopUpDropper, a context-sensitive drag-and-drop widget in Amarok. Import of kollagame, a game development IDE. Systemsettings is moved to kdereview as a possible replacement for KControl in KDE 4.
Comments
"Sort of like how in Windows Explorer if you enter a web URL hey presto suddenly it's "internet explorer" with different menus and such, even though it's the same program."
Windows explorer is explorer.exe, and IE is iexplore.exe. Not the same program.
Technically iexplore.exe is just a wrapper for the IE ActiveX control provided by shdocvw.dll (at least it was up to IE6, I assume the same is true for IE7).
Interestingly I notice that with IE7, at least on my work system if you type a web address into Explorer it no longer mutates into IE as it did with IE6 (and the same applies if you type a local path into IE's address bar).
Oops, I forgot to add - instead of mutating the current window, it opens a new one.
It almost sounds like you've never used konqi... It does change it's interface. menu's and toolbars are differend, depending on what kparts are loaded... It has been this way since what, forever?
Yes, I know it does. I would just like to see this support extended beyond what is implemented today. For instance, the configuration dialogue is pretty much geared toward web browsing / file management. How about redesigning it and making it possible to configure each KPart individually (pluggable configuration dialogues?). For instance, if I load a PDF file in a tab I can configure the behaviour via "Configure KPDF" but wouldn't it seem more natural to have it in one place?
Well, for a start, I disagree with having different bookmarks.
You see, to me one konqueror window is the same as another. When I need to access to the local filesystem, or to an ftp site, I just open a new tab...
if the bookmarks were "magically" changed, depending on the "mode" (how would you decide the mode?) it would lose functionality for me.
But Konqueror *works* according to the unix philosophy, only you look at it from the wrong angle: it's not a simple program, it's the shell.
In the *nix shell, there are small programs that do one thing well... these are KParts in KDE. And Konqueror let us combine those to make a more powerful application, just like the shell let us combine ls with more to paginate through a long directory listing.
I think this is pure sophism :) I mean, in the unix shell you don't have ls, awk, grep etc always in your face. In fact, since discoverability is completely different in a text-based interface, if you don't know about grep, grep almost doesn't exist for you. On the other hand, if in the View menu there is a "Show as hexadecimal" (or what's the description of the KHex Kpart) while browsing a web page, IT IS in your face. Or if I go in the Preferences panel while browsing a web page and I find at first sight options about file management IT IS in your face, and IT IS *highly* unusable, irritating and discouraging, even for power users.
I would for sure welcome a more powerful profile management, but I think that the better choice is the radical one, as they already did with Dolphin.
Konqi already only shows what is usefull right now. OK, it might need some cleanup here and there, but imho the principle is great.
"On the other hand, if in the View menu there is a "Show as hexadecimal" (or what's the description of the KHex Kpart) while browsing a web page, IT IS in your face."
This happens because KHexEdit is associated with the mime-type that you're viewing (like for me, when I go to View -> View Mode -> I only have "KHTML" and "Embedded Advanced Text Editor" for this page). The View menu point is invalid (since apparently on your system its associated with that filetype), though your Settings point is valid, Konqi's config dialog can appear daunting because of all the options for Web and File at the same time (I think maybe a tree view would be better, or that other widget... toolbox I think it was called? and then have one section for File Management, one for Web Browsing, and maybe a misc section as well for options that aren't really related to file/web exactly).
Konqi does need a good bit of loving to clean up and restructure the code, or possibly even a complete rewrite depending on how much a mess the code is (one day I plan on attempting a rewrite).
No, my point about the View menu is still valid, because my complaint is that Konqueror should act ONLY as a webbrowser, and not as a KPart swiss-knife that shows me every possibile kpart associated with the file I'm viewing.
I know that sounds drastic, and in fact it could even be worth trying to spawn a new project, just as Dolphin did, but I recognize that it would loose brand recognition. But in this way Konqueror could still live in its current form (for the power-users) and the new program would be the default for web browsing in KDE.
Other browsers (AFAIK Firefox, Opera, IE) have the feature of integrating other apps, e. g. Acrobat Reader. This is very simple in Konqueror, as if an embedded viewer is associated with pdf, it will open in Konqueror, using some kpart . And the possibility of changing the kpart is important: for example, I use kpdfpart by default (because it is fast and it is kde) and if a pdf does not display well in kpdf, I simply switch to nspluginwrapper which shows Adobe Reader inside Konqueror.
Well, this means Konqueror is more discoverable than the shell. I can't see this as bad. How else would you invoke a new command in a "graphical shell", if not through toolbuttons or menu entries?
At the moment there is a way to control which extensions should be enabled. Probably it would be useful to offer the user a way to disable certain parts (or conversely, to enable rarely needed parts).
Yes, the CVS view is probably not needed by everybody, as the hex view.
So, it could be useful to have the parts enabled only if the user requires them. In the same way, it could be useful to enable only the simper file-management views, and let the user decide if they want more advanced views, or if they prefer different views altogether.
Exactly, this should be the principle for all of KDE:
Minimum defaults; the user adds stuff.
Not the other way around.
"IT IS *highly* unusable, irritating and discouraging, even for power users."
After you have first found a feature, you know where it is and you do not have to bother with the features you do not use at the moment. I think beginners use this "method" frequently, and mostly with success. (Except that sometimes they do not bother with the important features also. :) )
I agree with that person who wrote that Konqueror works accordingly to the Unix philosophy. One task is viewing a certain file type, or downloading (and in some cases also uploading) using a certain protocol. A typical "web browser" integrates the two almost unrelated task of downloading a file using http and displaying a html file. And what if I want to display a html file which is located on an sftp server?
Hi
Most of your problems are those can be fixed by extending and working on Konqueror's Profile tool.Yes I know that it currently doesnt work as excepted, but I think its easier to extend (or even rewrite) them than creating a whole new Browser.
I mean improving Konquerors profiles and Plugins Structure is easier than creating whole new browser + new Extension API.
and please...Konqueror is not just for power users.for example, think about when a normal user tries to open a picture.which is easier for him, a new application opens up, with new everything, or Konqueror just changes its menu items to it??
I tried it, please! you should try it too! I tested it with my grandma ;)
I cant understand whats the matter of konqueror with idiots ;)
It isn't likely to happen, but I'd love to see a branch of Firefox with KHTML/Unity as the renderer.
1 - It would be true Web Unity, bringing together Firefox (and quite possibly Camino, Flock and all the Mozilla-based browsers), Safari, Konqueror together under one rendering engine. Fast, compliant, standard rendering across every platform.
2 - People keep asking for Firefox plugin support into Konqueror. Either you rewrite a branch of Konqueror to be a dedicated web-browser that supports Firefox plugins, or you port KHTML into Firefox. Given the two choices, I think injected QT and KHTML into Firefox is the one that is most likely to gain mass exposure and acceptance, especially when you'll be able to use the QT/KHTML branch on all major platforms.
3 - If Trolltech and KDE want to show the entire world what they've got going with QT 4.x and the KDE 4 libraries, then grab a hold of one of the biggest OSS programs on the planet and introduce yourself to some new users, and thusly some new developers as well. I know tons of programmers. I've worked for several large IT departments, and even those that know Linux know nothing of QT. That is sad indeed.
4 - People are not only already familiar with Firefox, but you save yourself all the time, effort and heart-ache of designing the look, interface, etc. of the browser. Invariably, all those decisions will upset people anyway, and the time investment in planning such a huge project is not to be underestimated. So instead of making a new browser, just beef up the one that so many use and love. As far as I know, there is already a long-abandoned QT branch in the Mozilla repositories that is just begging for some QT 4 love.
1. Yeah, it'd be lovely if firefox would adapt KHTML, and indeed KHTML is the better technology, but being better never brought KDE technology much good.
2. Well, you could rewrite firefox' interface into Qt, I guess, but then you'd have the bad interface firefox has (fitting in nowhere with it's own look & feel, a typical windows app). Why would you want that, you can't use the name firefox anyway (see how debian has to use 'Iceweasel' just because they maintain their OWN security patches...)
3. - firefox is controlled by the company/whatever behind it, you can't use it's name for anything else, nor influence the project much. Forget any KDE/Qt influence in Firefox: they focus on windows users mostly, and IF they look at the linux platform, it's mostly Gnome/GTK centric.
4. Firefox might be loved, but that's not because it's any good. It has a mediocre interface (OK, it's main interface is OK, but the rest sucks - configuration, extensions behave weird, etc). It's not fast either (konqi has always been faster, and IE is also faster!). Firefox is only loved because ppl know it, it has a pretty widespread use and as such receives a lot of promotion and plugins. And we can't use these plugins (they aren't even usable between firefox versions, so forget about different apps, I guess they don't have a real plugin structure but just expose their internals like compiz and beryl do).
I think having a seperate webbrowser for KDE wouldn't be bad, but I would love to keep konqi. I don't see myself use dolphin, as it can't do webbrowsing, and I always mix local and webbrowsing and filepreview (PDF) etc in a window. Any filemanager/webbrowser which can't do that sucks for me.
1 - I wish honestly I had thought to suggest this a good year back. From what I understand, the majority of the work on Firefox 3.0 has been developing a new/updated rendering engine, and all the while it has been getting slower and slower. If their concern was putting in a better renderer after Firefox 2.0, they might have been much more open minded a year ago.
2 - If I had to guess, I'd say Apache is the most widely used OSS program out there, but to the average user, Firefox is one of the biggest OSS programs on the planet. They use it every day, and it keeps growing in popularity. The interface can't be that horrible. My wife installed Kubuntu just tonight, and tried Konqueror for about two hours before screaming to have Firefox back.
3 - Mozilla controls Firefox, and they are pretty specific. Clearly label your build "Unofficial" or don't use the name Firefox, and that is fine. The Mozilla trunk has a branch for OSX widgets called Camino. I'm not suggesting that we demand that Mozilla switch wholly to KHTML tomorrow, even though I think it would be a good idea. I'm suggesting that some talented QT/KDE devs consider adding a KHTML based brank to the huge Mozilla trunk. Do you know have many branches/splits they have? Again, they already have a QT branch, it just needs (sorely) to be updated.
4 - As far as speed, everyone says how incredible QT 4.x and the new KDELIBS are, so put them to the test. Plug in this faster rendering engine, and fast widgets, and voila, you should get a faster Firefox. I'm sure that will turn heads and bring attention to the masses what wonderful technology QT and KDE is. That's somewhat my main point.
And frankly, the massive collection of add-ons is a huge selling point. I just use nightly-testing-tools, force compatibility, and all my plugins magically work, even though I use nightly tester builds of 3.0
And KDE often has multiple apps for the same job. I doubt Konqi will ever disappear, but it does have easily spotted flaws that come from trying to be all things to all people.
2. She's just used to firefox. I use it now and then, mostly at my job - IE 4/5/6 suck because they don't have tabbed browsing, but I have no problem with IE 7. Imho firefox isn't much better, at least for what I do. Konqi, on the other hand, IS much better. But maybe I'm just used to it...
I like your idea of having firefox based on KDE/Qt technology, sure, I just think it won't happen. Unless they can totally lay off the NIH syndrome, but I don't expect it'll happen...
"If I'm using it as a file manager, pressing "Home" should take me to ~, not Google, and vice versa."
For what do you need a home page button so much? In most browsers Home page has 2 functions: 1. The browser starts with it. In Konqueror this can be set in the profile. 2. It loads in when the user presses the Home button. But what about using bookmarks instead? Nevertheless, what you want could be simply solved within Konqueror: a home button which loads the start page of the current profile.
"If I'm using it as a web browser, why would mistyping a URL cause a scan of my harddrive for what I typed using kio_locate, instead of searching google?"
Well, I think when a mistyped URL starts a google search is equally annoying.
"Whay is there no Undo Close Tab? Why no "Protect Tab"? The list of missing features one would expect to see in a modern browser shell goes on and on, and a large part of the lack of progress is due to the fact that spanning the worlds of file manager and web browser all at once is immensely difficult."
I do not see why these features would be more difficult to include within Konqueror than in a specialised web browser. (And it would also be useful in the filemanager part.)
I agree in that Konqueror should provide a better intrface for extnsions.
you know, I don't think there's anything stopping anyone from building a simple KBrowser app that just does khtml and nothing else. it could be a fun experiment. :)
imho we definitely need konqueror for the flexible-kpart-viewer thing, though. it's really convenient to have a bunch of documents in one app, regardless of whether they're text or images or some weird crazy format and regardless of where they're stored. :)
Actually, there is an application that is almost that: Akregator.
While evidently it is a news aggregator, it could function well enough as a browser... Even if it is missing a few features.
heh, true. all it's missing is javascript and an address bar :) ahh, the magic of kparts.
It does have JS support.
then why do all websites complain that there's no js when I open a page in akregator?
There are many Konqueror specific things that could (and should) be improved:
- Session handling (almost every other browser does this and it would also be usable in the filemanager)
- Better profile handling (more settings stored in proiles, e. g. toolbars)
- Better tab handling: rearranging tabs (currently dragging a tab to another place duplicates it), Undo close, etc.
- Home button which reloads th start page of the current profile (for some people it is a major problem that the home button directs to the home directory when they browse the web)
- Better arranged configuration area: a tiny central configration and then the configuration area of the filemanager (Dolphin), khtml, kpdf, whichever is currently used
- File information sidebar. I know Dolphin does this, but it could also be implemented in KDE, as many people would continu to use Konqueror as a file manager. (See our debate )
(Sorry, duplicated)
There are many Konqueror specific things that could (and should) be improved, including:
- Session handling (almost every other browser does this and it would also be usable in the filemanager)
- Better profile handling (more settings stored in proiles, e. g. toolbars)
- Better tab handling: rearranging tabs (currently dragging a tab to another place duplicates it), Undo close, etc.
- Home button which reloads th start page of the current profile (for some people it is a major problem that the home button directs to the home directory when they browse the web)
- Better arranged configuration area: a tiny central configration and then the configuration area of the filemanager (Dolphin), khtml, kpdf, whichever is currently used
- File information sidebar. I know Dolphin does this, but it could also be implemented in KDE, as many people would continu to use Konqueror as a file manager. (See our debate at http://dot.kde.org/1172721427/1172897220/1172915550/1172918074/ . So is the purpose of Dolphin to be really a subset of Konqueror?)
Anyone remember this:
http://konqueror4.linuxdevel.net/
?
Konqueror for a new experience! It was the cool new Konqueror 4 vision discussed widely on the mailing list about a year ago.
What ever happened to it?
That is a brilliant mock-up. Kudos.
I would absolutely love to see a Konqueror like that. Quite frankly, the mockup isn't really aimed at the web-browsing capabilities all that much.
Most of the concepts of the mockup could be ported in Dolphin design.
If this Dolphin 4.1 or Konqueror 4.1, I would be a very, very happy man.
Someone please make this so.
To me that looks mostly like SVN Dolphin with the Konqueror sidebar (and a few other modifications, but mostly how Dolphin already looks).
All of you guys wishing for a "dedicated" KDE web browser are unaware that one has already existed for a long time, albeit unmaintained - Kafilah. Unlike Dolphin, Kafilah is focused on simplicity, and not usability. To be more exact, it's little more than a performance test.
http://websvn.kde.org/trunk/kdenonbeta/kafilah/
Not of much use but interesting nonetheless ;)
oh, last commit was 2 years ago.seems to be a dead project.
I just remembered something from the last commit-digest:
" updated printer icon to use blur shadow. tweaked to reduce svg file size of 50%."
Does that mean Qt supports blur now?
Hi Danny, the link to "Icon Cache" points to the kopete implementation of MP15
Fixed.
Thanks,
Danny
Why didn't you announce KDE 4 alpha 2?