restarting hacks

I finally finished “my” exams yesterday and now I’m free to restart hacking on 🙂
Yesterday night I moved to KDE SC 4.5 and I have to say that the compilation was incredibly smooth! I had just two problems and just on the beginning: when I finally could compile & install kdelibs, I start my usual compile scripts and this morning everything was ok!
My two problems were:

  1. Phonon: as it seems that Qt 4.7 will ship with phonon 4.4.2, I tried using just that for my needs. This because I’d like to compile Qt with phonon, cause of webkit and some other not so important stuffs. It doesn’t work. It said “installed phonon 4.3.1” and things didn’t work. So, I tried hacking the phonon release version and kdelibs “compiled well” (see point 2 about). That’s not the same with kdebase_runtime. it seems it’s a problem of angular brackets against double quotes one. I could solve it just installing a new phonon copy on my $KDEDIR (btw, I install Qt on /opt/qt and KDE on /opt/kde)
  2. kdelibs depends on docbook-xml 4.2. This is really a pain as slackware releases a docbook-xml 4.5 package. So I started playing a bit with its official slackbuild (the script slackware uses to build packages) and I noticed this:

    # Rewrites for older docbooks. This allows older docbooks to be referenced.
    # It means, however, that you __*shouldn't* have these older docbooks__
    # installed on your system;
    # so if you just keep the Slackware linuxdoc-tools package you'll be fine:
    for DTDVERSION in 4.1.2 4.2 4.3 4.4
    xmlcatalog --noout --add "public" \
    "$DTDVERSION/docbookx.dtd" \

    So I patched kdelibs to compile with docbook-xml 4.5 and everything works well. in compilation and in runtime. So, why the hell do we need 4.2?

This morning, after a short look to this new kde sc minor release, I restarted hacking on what will be rekonq 1.0. First work need visual help (better than explanations):

rekonq 0.5 bar

rekonq 1.0 proposed bar

So, what do you guys think about?

38 responses to “restarting hacks

  1. Lionel Chauvin

    @J. Janz

    Ok, perhaps it should be on the same page but hidden

  2. I agree with the other commenters that being able to configure the toolbar is an absolute necessity for a KDE app (what is the advantage of basing an app on kdelibs if the features that kdelibs provides are not available for the user?).

    IMHO v0.3 was a serious regression w.r.t. v0.2 because of the removal of the menubar and the removal of the possibility to configure the toolbar. The removal of the menubar led to the current bad design in which everything that in the past was nicely ordered in different menus is now crammed in one single menu (available from the “Tools” button). In order to find the requested action, one has to read all items in that big menu (in the past the user only had to select the correct menu and read the items in that menu only). Clearly you realize the clutter in that menu, that’s why you have crammed the zoom actions on one line. Yet the result can hardly be called usable: the user has to guess what that slider and its related buttons mean, furthermore the user may think that the slider actually belongs to the “Find” action since there is no label specifying the use of the slider. Having a line with three buttons and a slider and no label is against the normal look & feel (and therefore against the expectations of the user and hence against the usability) of a menu: in a menu each item consists of an icon with a label specifying exactly one action. Some actions are hidden in the context-menu (such as “Page source” or “New Window”) because there is no place in the “real” menu. I have read on several occasions that a lot of people never use the right mouse button, so for those people the “Page source” action is unavailable. There is even no “Quit” action.

    Rekonq cannot be used with only the keyboard, since there is no shortcut to trigger the “Bookmarks” and “Tools” menus (and even if those shortcuts existed, how does the user find them?).

    Why does only the “Back” button have an “extension” button (I don’t know how to call it, it is that down arrow to the right of the back button which has a submenu with the previous items in the browsing history). It would be nice to have such an “extension” button also for the “Forward” button (similarly as in Konqueror).

    Somehow in your frenzy to remove stuff from the visible user interface you didn’t find it necessary to remove tabs: since kwin now has tab support there is no reason why apps such as konqueror or konsole have tabs. Tabs make sense in apps such as kdevelop or kile because there you have projects with multiple files and actions (such as compile, typeset latex, view output, …) which are related to a project (and therefore to all the open documents at the same time). In konqueror or konsole you don’t have actions that are applicable to all tabs at the same time (because each tab is logically disconnected from all the other tabs). Of course, all the nice tab-handling stuff (such as “add new tab” (with a similar window), “duplicate tab”, …) available in konq and konsole should be implemented in kwin.

    One of the main reasons why I use konqueror for browsing the web is the usage of kparts: if a pdf file is on the internet, then it is logical that it is opened in the program with which I browse the internet, therefore the pdf file must be opened in the browser using a kpart (even Firefox has an Acrobat Reader plugin). Not having kpart support is again a non-usage of kde technology (why is rekonq based on kdelibs and not on pure Qt?) and is so 1990s.

    When I first heard about rekonq (v0.1) I was hoping that it would turn into an Arora with kpart and kwallet support (and of course all the other KDE goodies such as configuring toolbars, usage of KIO for saving a web page, creating a web-archive, …) with a less cluttered interface than Konqueror. Unfortunately you decided that turning rekonq in a Google Chrome clone was a better idea 😦

  3. I can agree many things what top poster says. But some I do not agree like the moving the tabs to be handled by KWin. I do not like KWin tabs. They are in my way. Even that I always move/resize the window with Meta+Mouse button.

    But I would really want that it is possible to configure the toolbar. I want to remove refresh/stop and home buttons.

    And the menubar is always somekind functional, it just should be always be possible hide what is one the extra feature what no other UI offer. The menuhide feature allows user to have simple and clear menu structure and allow developer to make own toolbar if wanted and when it is possible to configure the toolbars (and shortcuts etc) user has all the power to get application what does not fight against user needs.

  4. @g Nonsense! …

    This ain’t the use case for kwin tabs! It aims only for user’s window arrangement/organization (see that is can join windows’ instances from different apps?) … Despite it *can* have that use, why to have another whole rekonq instance just to have tabs on top?!

    And why do you think all KDE technology should be used by one app? Using kparts is a choice, as well as any other KDE technologies. And, btw, In my first comment on this post I just said how embeded files in a web browser confused me for a while (making me lose precious time), exactly to show how bad it can be (and, yes, I loved it some day). That’s why it’s a plugin on firefox, not a default behaviour. And I guess KDE people agree on it when dolphin makes no use of it by default. Actually, their answer to people that were missing these or those of Konqueror’s features was: that’s why konq’s there, for you people. Really, if konqueror’s features are what you want, I don’t see manually (even less script automated) uncluttering its UI being that hard (again, is one of those stuff you do once — I know it, I used to do it on old KDE3 and KDE2 days but, of course, only after fresh system installations)!

    And, about the extreme need for a menu … Oh, no, Internet Explorer 7+, Chrome and Firefox 4 are unusable! I know IE might show a menu on keyboard shortcut or context menu (and I used to force this with rekonq 0.2-, after removing some buttons and adding the “show/hide menu” one — Oh, configurable toolbars! … 😉 ). But can you realize that konq, opera and whatever gnome’s is will be pretty much the (most known) ones with a menu on top of them (by default, at least)? What does it tell you?

    I agree that zoom looks some sort of misplaced but a single “Zoom: ” label in front of the widget would perfectly do the job! It’s an unusual way of using a menu? Surely yes! But it’s also thought outside-the-box and, hey, it works!

    Maybe it what Tools button misses is a shortcut for it (and where’s ctrl+s to save … as, in this case? 😉 )

    People, look and see that what is not 1990’s but 2010’s is the uncluttering of apps (by using new widget arragements/design only with keeping features in mind), from browsers, through desktop environments/apps (ms office, kde 4.x desktop and apps, anyone?) to whole OSs (look at windows 7)! Time to review your concepts, open your mind to not to get behind (no lame rhyme intented).

  5. Lionel Chauvin


    Configure toolbars will be reintroduced when the following issue will be fixed in kdelibs:
    if the menubar is removed or hidden, and the toolbar allows to be configured then it automatically allows to remove it.
    When there are no menubar and no toolbar the application became unusable: you must delete its rc file.

    Some KDE applications does not need a menubar by default: systemsettings, dragonplayer, kget etc. During my free time I prefer work on the new url bar but when it will be finished I will try to work on kde itself.
    If someone want work on this problem, he should read this mail:

    >Some actions are hidden in the context-menu (such as “Page source” or “New Window”) because there is no place in the “real” menu.

    “Page source” is in the tool menu, it is a developer tool so it is with other developer tools.

    “New window” is relevent only with links, how you open a link in a new windows without right click ? If you want open a new empty window, you can do it in the same way you opened the first one.

    >There is even no “Quit” action

    The “Quit” action it is relevent only when there is no “close” button on the window. In this particular case it could be added to the tool button menu. If KDE is not able to detect when a “close” button is available then KDE must be improved.

    >Clearly you realize the clutter in that menu, that’s why you have crammed the zoom actions on one line.

    It was for remove a submenu. It was a try, I agree it is not a so good idea. It will be replaced in the next version by a zoom bar, like the find bar.

    >Rekonq cannot be used with only the keyboard, since there is no shortcut to trigger the “Bookmarks” and “Tools” menus (and even if those shortcuts existed, how does the user find them?).

    It must be fixed in Rekonq if possible. If it is not possible with only button menus then KDE must be fixed.

    For kwin tabs, we are studying that, but it will not be before KDE 4.6: kwin still needs some improvements.
    The two points I don’t like with tabs on top:
    – tab previews will appear over the toolbar
    – tabs are more far
    – where will be the new tab button ?
    Anyway, there are other good points so it must be studied.

    >therefore the pdf file must be opened in the browser using a kpart

    Kparts are available in rekonq 0.5.

  6. I love the work you’re doing on rekonq. There will always be folks who want everything to remain exactly the way they’ve always been. Their reasons for which, despite whatever post-rationalizations they come up with, almost always, under any credible scrutiny, reduce to: It’s always been that way.

    Time to move on to something better and rekonq continues to take steps in the right direction. Keep pushing the platform forward and thanks for all your hard work!

  7. >>therefore the pdf file must be opened in the browser using a kpart

    Where is that written? First of all, when I run a web browser, I expect it to contain web pages, or whatever web content it might be, which holds no relation with pdf files, except where it might have come from. I, however, expect pdf file to be on my pdf reader, no matter where it came from. It makes perfect sense that a pdf file get opened in my pdf reader, as well as audio in my music player. When it’s the website’s intention to have different content opened inside the browser, they use object, video or audio html tags.

    Just to mention another problem (one being this files/apps unconsistency with file associations settings), their controls and features get mixed/badly functional among the 2 interfaces (as happened to me).

    >Kparts are available in rekonq 0.5.

    I see rekonq for the web as dolphin for files. And the same way as dolphin doesn’t allow to open files inside it because there’s no much point as there’s confusion on it (again, there are file associations), please, follow that (KISS) thought. That confusion Ialready had from it (yes, rekonq 0.5) is just one case of what users might get into every day and the reason why it’s not default in any app today, as I said before.

  8. @ Lionel: Thanks for explaining the toolbar issue.
    I think a configurable toolbar is crucial for the 1.0 release. Without it rekonq will never be able to satisfy new users who demand a simple user interface and advanced users who have very diverse wishes.

    I am one of those who like the ui as it is, with home and favorites button. I even have a favorites button extension in firefox since i use rekonq.

    The main aspect i like about using kwin tabs is that when using expose or taskbar previews every open tab is shown. This is important when you have lots of open tabs and want to find a particular one or use e.g. gmail. Gmail is more like an application running inside your browser than just a website, so it should be treated as such by the wm. Let the window manager manage the windows (and tabs) because this it what its made for and best at.

  9. Lionel Chauvin


    >I think a configurable toolbar is crucial for the 1.0 release.

    As it needs modifications in kdelibs, I fear 1.0 will be released without that.

  10. Thanks for answering my comments!

    @J. Janz:

    Having a new instance for each new window is what Google Chrome does and they claim it to be a feature (it is a feature because if one tab crashes, the other tabs survive). Anyway, my suggestion was from a purely logical way of thinking: it seems more logical to me that each tab has its own “Back”, “Forward”, “Reload”, … buttons and URL-bar, rather than the current situation which seems to suggest that these buttons are global and that they act on all tabs (I know that we are all used to the current situation and that we know that the buttons only act on the current tab, but still it is illogical).

    The fact that IE, Opera, Firefox, etc. all remove the menubar only shows one thing: removing menubars is popular. As you probably know, MS Windows and MS Office are popular, but are they usable??? (As a side note: the Ribbon interface in MS Office sucks, because it forces me to remember all the icons that possibly exist, or I have to hover each button and wait each time before the tooltip appears. Furthermore, not frequently used icons are very small, so very hard to identify and to click on.)

    I am in favour of uncluttering user interfaces, but not at the expense of usability. In rekonq the default window is uncluttered, but the “Tools” menu is cluttered, so it seems that the problem has been moved (instead of removed). MS Office is a very bad example of uncluttering, the Ribbon interface is the most cluttered and unusable thing I ever saw.


    Thank you for giving information on the problems with the configurability of the toolbar.

    I agree with your observation about “New window”, but I assumed previously that it had the same purpose as the “New window” item in Konqueror’s “File” menu. I didn’t notice “Page source” in the “Development” submenu before, thanks for notifying it.

    Concerning the quit button, you cannot assume that all users of rekonq use kwin as window manager. I am not acquainted with window managers enough to know whether there exists a standard way of querying the availability of a close button.

    I agree with your suggestions about xmlgui in the referenced email. This would be much better than the current situation.

    I didn’t notice before that kparts are used in rekonq. It’s cool that they are supported!

    The zoom bar is a very good idea!

    It is possible to have shortcuts for triggering the Bookmarks and Tools menus. I will send the small patch by email to you.

    You are right that the previews will appear over the toolbar and that this isn’t nice. The fact that they are more far is not such a big problem because there is only the toolbar separating the tabs from the web view. The new tab button should be added to the titlebar (the default behaviour of that button would be to open the same application as in the current tab).

    @J. Janz:

    The kparts are also used in the version from git. There should be an option to switch embedding off (for those who want it). I see in kdelibs-4.4.5/kparts/browseropenorsavequestion.h that there is a TODO to introduce a function askOpenEmbedOrSave() which would be the best solution since I do not always want the PDF files to be opened in the webbrowser.

    Another idea would be to open e.g. a PDF file on the internet in a separate okular window but as a new kwin tab in the same group as the rekonq window. In this way, there would still be a visual connection that the PDF file is actually on the internet (and the behaviour would be the same as for “Open page in new tab” if my idea of using kwin tabs instead of usual tabs is implemented). But this would break the normal flow of using the back and forward button to browse your websurfing history.

  11. Actually, I think it is possible to make the toolbar configurable using the current kdelibs: your mainwindow should be a KXmlGuiWindow, you do the usual stuff such as (in the constructor of MainWindow):

    setupGUI(ToolBar | Keys | Save);

    but you add below that code the following line:


    When running the application, there will be no menubar and ~/.kde/share/config/rekonqrc will have an entry:


    Well, at least this is what happens when I try it for my own app that uses KXMLGuiWindow.

    Of course, if it works, then the “Tools” menu will also be removable. But IMHO this inconvenience is far outweighed by the advantage of being able to configure the toolbar (especially because the context menu of the toolbar has a “Configure Toolbars…” entry).

  12. Oh, I reread your comment and I see that in my previous post I answered to the wrong problem. Sorry.

  13. Ciao, ti scrivo qui perchè non sapevo dove contattarti per segnalare queste cose.
    Hi first of all thank you for your great browser rekonq,i use it as kde default browser(however i also use chromium) from rekonq0.2,it is growing up nice but i have to mention 2 big issue:the downloads,i just tried to download a big files from a popular hosting service and both with kget an the simpler KIO and plasma i got rekonq still open with the download in progress and after its closing,and rekonq menaged to get 500MB of ram memory,unacepptable,and the poor performance of javascript engine i know it doesn’t depends on you its a qt issue but i hope it will become better soon,do you notice any important improvements in qt4.7 webkit module?thanks

  14. While you’re working on aesthetics, please fix this bug so we can make Rekonq’s fonts always do what we want them to:

  15. Hey would you mind stating which blog platform you’re working with? I’m planning
    to start my own blog soon but I’m having a hard time making a decision between BlogEngine/Wordpress/B2evolution and Drupal. The reason I ask is because your design and style seems different then most blogs and I’m looking for something completely unique.
    P.S Apologies for being off-topic but I had to ask!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s