Since KDE migrated to Subversion, I have been creating semi-weekly development builds in the hopes of finding bugs to report. Notable new features include Konqueror's new adblocking mechanism and Kicker's new applet manager. Since everyone likes screenshots, I created two articles with screenshots from my observational usage: previews of KDE's trunk code and Trolltech's Qt 4 alongside brief documentation of what one is looking at.

Comments

I am compiling KDE svn trunk on a nightly basis with my own scripts and it really rocks. I am here to thank everyone from the KDE team (and the cool people from #kde-devel) for their carefully work on keeping svn trunk always in shape. There are rarely any issues with svn trunk and it usually compiles over night without any issues. Rarely you need to do some manual work to have it finish the compile and the committs to svn trunk are usually tested and work. Thanks to the people for having created a nice, round and feature complete Desktop Environment for the Open Source world to get serious business, science and normal work done. Stuff that feel mature, complete, consistent and truly integrated.

You should give kdesvn-build, located in kdesdk/scripts, a try, it can't do everything yet (l10n doesn't quite work). But, all in all, it's a great script. And I'm not just saying that because i wrote the code to make it do apidox.

well actually the extensions in firefox is also the source of their biggest security holes they have (hopefully _had_).
I prefer not having 'dynamic' extensions if I lose security.
I am fed up of all these browsers that in the name of extensibility drops basic security measures.
Firefox really disappointed me in that area.
These days, security in browsers should always be first and I have to say that konqui is one of those too few browsers I have never had major security concerns.

as soon as you allow a dynamic thing to come into your browser, you definitely open new security bugs.

Agreed, Konqueror needs to be able to be extended. I'd like to see Konqueror to become as good as Opera as a browser. I still use Opera for all its small conveniences which is also where I find Koqueror (KDE 3.3 here) still lacking.. something like the session thing could be done as an extension, the rest probably needs to be done in Koqueror itself -- some kind of wishlist here:

- save & restore sessions (Operas *.win files), also session restoring for crashes
- mouse gestures (admittedly I didn't test KHotKeys yet but an Opera compliant preset would be nice)
- the hopefully soon arriving panning (aka continuous smooth scrolling)
- and some more settings as how many connections to allow for one site and overall

Problems I still have with Konqueror:
- different kind of tabs than Opera (again). This also applies to Firefox. The advantage of the more pushbutton like tabs in Opera is that they can be minimized so you can change which tabs you want to see and when. Any chance for it being implemented?
- fullscreen not really implemented? It's just half a fullscreen, menus, address bar (ok might be useful)and status bar still there. Will a full fullscreen be done where only the page can be seen? To me both seems useful.
- revenge of the kparts: currently an image is shown in a gwenview tab here where I can email or compress it or copy it to a location with a rightclick. Somehow this is lacking important functions for the image (on rightclick) like save it, copy it, copy url and properties. Don't really know if Konqueror can't show images on its own or if these functions are missing in the Gwenview kpart.

Konqueror is really good and usable apart from that, but at least for me needs still some tuning to make it first choice as a browser.

But no panning on third mouse button which triggers the notorious x clipboard.

ok the Profiles seemed more like (and probably are) for setting the layout, but perhaps could be fleshed out, with the history of the saved sites. Wasn't that obvious under the settings tab. (usability to the rescue).

The stuff noted under "problems" remains.
Especially Konqueror loading an image in a Gwenview kpart should be emphasized.
This might be handy on a local filesystem, but it's just unusable on a website.
I'd just need about four basic operations on rightclick (save image..., copy image, copy image url, image properties)
and all four are gone because the picture is embedded in the viewing part of an application. Instead I can rotate it now in the browser.. *sigh*
Don't know anymore how it was handled before I installed Gwenview.

I think it's indeed Gwenview that decides what options are shown there.

If you don't want Gwenview to be used for embedded viewing you can tweak that in the control center under KDE Components -> File Associations (for each image type in question): Just change the "Service Preference Order" on the "Embedding tab" of each image type. The entry on top is used.

That way you can keep Gwenview installed and still use something else inside Konqueror.

Sorry Roland, Privoxy just doesn't compare. With AdBlock, I see something annoying, I right-click, and block it. Messing around with a proxy every time I see something annoying is too much hassle, I'd rather just put up with the ads.

Firefox extensions create a lot of security holes and make it unstable. I'm the developer of Plastikfox and extensions usually step one on top of other forcing me to do dirty hacks to make it work. They have full access to all the parts of the browser, which is very dangerous. Also, extension developers don't usually care not to do things that could break other extensions. They just care their extension works but sometimes two extensions try to access the same resource causing problems. The result is a bunch of bloated dirty code running on your computer that could explode in your face at any time. If they were implemented in a clean way it would be a point but they don't. That's the reason I don't like extensions and I wouldn't like Konqueror to get that too, or at least in a similar way to Firefox. Perhaps if extensions were implemented in a way similar like plugins are (being them all independent and one extension not having access to others' variables an code) it would be much better.

and why did you think you'd find bugs related to 3rd party extensions in the mozilla bug database?

The trouble with Firefox extensions is that they've given full access to the browser, but are generally only written and maintained by one person. Often someone with very little experience.
They just don't have the same level of QA as the browser itself.

Obviously there are exceptions, but the Firefox extension mechanism opens itself up for a whole lot of half arsed buggy, insecure extensions.

So, at last after many years, KDE Developers got the courage to have Icon+Text! Congrats, but make it beautiful, attractive, customizable, animated. Support MNG and GIF for K button. Allow 4 state png/mng for k buttons! unfocused, focused(hover), pressed (focused), pressed (not hover).

Please, no text in the K-Menu! Or at least a text different than "Applications", I don't want a Gnome clone and Gnome people will say we're dropping our pants. Also make it a configurable option so people can disable the text (I will do!).

i turned it on by default for one week (and turned it back off at the end of that period of time) so that the code path for button text would get wide testing. apparently these screenshots where taken during that week =)

one of the problems with having as many features, several of them "hidden", in an application such as kicker where people tend to run it in a more-or-less static configuration is that getting good testing coverage can be difficult. so i occasionally turn things on or off by default in SVN to get some testing by those who follow svn. KConfigXT has made this easier since i just modify an XML file and it doesn't write default values to the rc; both features are nice for this =)

unfortunately there isn't much that a test suite could automate here, either, since most of the "output" of kicker is graphical and interactive in nature requiring a user to try things and interpret the results as "expected" or "buggy". kicker behaviour is also sensitive to things like X configurations, including having save-unders enabled, Xinerama setups, dual-head configurations and screen resolutions.

Current svn trunk is for 3.5, so it's still Qt3. It feels mostly like 3.4 did, a bit more gnomeish (not a bad thing) due to the 'add applet' dialog and the hidden option to have taskbar buttons take up the full length of the taskbar.

(The Qt4 branch probably feels not much more than buggy at this early stage, though I haven't tried it...)

I love that sidebar with HORIZONTAL text!
I think the last I heard is that some of this was accepted, but some also required Qt changes, which couldn't be done.
Too bad really, it looks really nice.
cheers,
-Ryan

Trying to get the sidebar to "scale" is clearly a case of overengineering. There are wayyyy too many tabs if you need it to "scale" beyond 3 or 4. Usability wise that would just be suicide to have too many tabs. Well I guess it's suicide right now already. =)

This is why the horizontal design is superior. It solves the right problem not an invented "scale" issue.

You forgot the uninvented i need to run over the full screen height to switch tabs suckage. Forget it. It's no solution. And it's annoying when you misclick. Go think again (and come with something usable next time, please).

nice preview. I really like how things are coming along. The vector demo looks really nice. there is also some qt4 preview stuff at the digitalfanatics qt4 website, but it's geared more towards programmers.

While attempting to port a medium-sized program to Qt4, I noticed a SEVERE drop in performance. To diagnose this droppage, I wrote a very small, simple program that depicts two rectangles bouncing around on the screen, and reports the framerate (which is calculated as an average over 5 seconds).

Under both versions of Qt, the program used a QTimer widget to control the movement of the rectangles. The Qt3 version can simply draw the rectangles directly from the QTimer handler, while the Qt4 version must generate a paintEvent, which I tried both with the "update()" method (which supposedly waits until Qt's main loop to call paintEvent normally), and with the "repaint()" method (which supposedly calls paintEvent immediately, which is supposed to be faster but more likely to flicker).

On my machine (A 1-GHz Celeron with a low-end Radeon, resolution 1400x1050, 16bpp), both versions run fast when the window is at its default size (49 FPS-- the target framerate).

When the window is maximized, however, Qt4 takes a 39% performance hit (19 FPS), while Qt3 takes no hit at all!

In larger programs with lots of widgets (such as the program I was porting when I first noticed the problem), I notice that any use of a timer-updated widget drags the program to a near halt.

I have attached the program, so you can see for yourself that Qt4 really is inferior. It must be built with the $QTDIR environment variable set appropriately. Two Makefiles are required because MOC doesn't pay attention to #ifdef directives. You must run 'make clean' between building the demo with Qt4 and Qt3.