Bug#247312: konqueror: opening of bookmarks is much slower when clicking directly on Bookmarks menu
On Fri, May 19, 2006 at 02:22:24PM +0200, Pierre HABOUZIT wrote: Hi Pierre, > On Sun, Jan 09, 2005 at 02:41:43AM +0100, Hervé Eychenne wrote: > > On Sun, Jan 09, 2005 at 02:10:22AM +0100, Adeodato Simó wrote: > > > > > so, could you please: > > > > > (a) check what happens with other styles (to discard it being a > > > style issue). Please try Keramik and Plastik, both with 'menu > > > effect' enabled an disabled. > > > > I had tried this before sending the last email: no change at all. > > > > > (b) create a new system user and log in a KDE session. Add a few > > > bookmarks, and check. See if adding a large amount of bookmarks > > > (just start normal navigation, and press Ctrl-B for each page > > > you visit) makes the delay to be present at some point. > > > > I did that and noticed no change in speed (it's fast). > > Then, I copied the 150Ko bookmarks.xml file which caused the problem with > > my normal account to the new user's account: the problem disappears, > > everything is always fast as it should. > > > > So there's clearly a problem with my actual configuration (remember, > > that it only shows in particular situations described in the bug > > history) even if changing style and effects doesn't help. > > If only there was a reliable way to monitor (strace would be tricky) what > > konqueror exactly does within these 2.5s... maybe that would give a > > hint about what's going on... Do you have an idea of how it could be > > best achieved? > I've faked a new bookmark.xml full of crap (more than 500 bookmarks, > 150ko big). the menu is almost instantaneous here. > slowness begin to appear over 400ko-big bookmark.xml (which is rather > unusable anyway. Like I already said, by clicking on the "Go" menu entry and dragging the mouse to the right over the "Bookmarks" entry, the "Bookmarks" menu displays instantaneously (whereas it takes 5 seconds by directly clicking on "Bookmarks"). Even more, I said that copying the bookmark file to a new user's account makes the problem disappear... > do you still have the behaviour ? if yes, could you provide your > bookmark.xml please ? ... So my problem definitely seems unrelated to the size of the file itself. As I cannot afford making my bookmarks public (it contains too many business sensitive URLs), just to be sure, would you mind providing me your "crappy" 250 Ko bookmarks.xml file instead, so I can test if I still get the same behaviour? That would be nice. Thanks, Hervé -- _ (°= Hervé Eychenne //) Homepage: http://www.eychenne.org/ v_/_ WallFire project: http://www.wallfire.org/
Bug#247312: konqueror: opening of bookmarks is much slower when clicking directly on Bookmarks menu
Package: konqueror Version: 4:3.2.2-1 Severity: minor Hi, After a click on Bookmarks menu, the opening of the Bookmarks takes something like 2s, which is quite slow. If I click on "Go" menu and drags the mouse to the right (on Bookmarks menu entry), then the opening is really instantaneous. Something must be wrong (it was the same with kde 3.1.5). (Maybe this difference can be better showed when bookmark file is big) -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.5 Locale: LANG=C, LC_CTYPE=C Versions of packages konqueror depends on: ii kcontrol4:3.2.2-1KDE Control Center ii kdebase-kio-plugins 4:3.2.2-1KDE I/O Slaves ii kdelibs44:3.2.2-2KDE core libraries ii kdesktop4:3.2.2-1KDE Desktop ii kfind 4:3.2.2-1KDE File Find Utility ii libart-2.0-22.3.16-5 Library of functions for 2D graphi ii libc6 2.3.2.ds1-11 GNU C Library: Shared libraries an ii libfam0c102 2.7.0-5 client library to control the FAM ii libgcc1 1:3.3.3-6GCC support library ii libice6 4.3.0-7 Inter-Client Exchange library ii libjpeg62 6b-9 The Independent JPEG Group's JPEG ii libkonq44:3.2.2-1Core libraries for KDE's file mana ii libpcre34.5-1.1 Perl 5 Compatible Regular Expressi ii libpng12-0 1.2.5.0-6PNG library - runtime ii libqt3c102-mt 3:3.2.3-2Qt GUI Library (Threaded runtime v ii libsm6 4.3.0-7 X Window System Session Management ii libstdc++5 1:3.3.3-6The GNU Standard C++ Library v3 ii libx11-64.3.0-7 X Window System protocol client li ii libxext64.3.0-7 X Window System miscellaneous exte ii libxrender1 0.8.3-7 X Rendering Extension client libra ii xlibs 4.3.0-7 X Window System client libraries m ii zlib1g 1:1.2.1-5compression library - runtime -- no debconf information
Bug#247312: konqueror: opening of bookmarks is much slower when clicking directly on Bookmarks menu
On Tue, May 04, 2004 at 04:42:01PM +0200, Adeodato Simó wrote: > * Hervé Eychenne [Tue, 04 May 2004 15:48:43 +0200]: > > After a click on Bookmarks menu, the opening of the Bookmarks takes > > something like 2s, which is quite slow. > > If I click on "Go" menu and drags the mouse to the right (on Bookmarks > > menu entry), then the opening is really instantaneous. > > Something must be wrong (it was the same with kde 3.1.5). > > (Maybe this difference can be better showed when bookmark file is big) > What happens if you click in the Bookmarks menu and maintain the mouse > button pressed? I mean, I've observed that when there are lots of > bookmarks and you click, what really happens is that the click passes > through and one of the first actions (e.g., Edit bookmarks) get > selected. I understand what you mean, but that is not what I'm talking about. I cannot reproduce what you are describing. Whether I only quickly click on Bookmarks menu or I leave the mouse button pressed, I get the same behaviour: it take about 2s seconds to open the bookmarks, which is way too long, considering that I can have them displayed instantaneously when clicking on Go and shifting to the right. Herve -- _ (°= Hervé Eychenne //) Homepage: http://www.eychenne.org/ v_/_ WallFire project: http://www.wallfire.org/
Bug#247312: konqueror: opening of bookmarks is much slower when clicking directly on Bookmarks menu
> After a click on Bookmarks menu, the opening of the Bookmarks takes > something like 2s, which is quite slow. > If I click on "Go" menu and drags the mouse to the right (on Bookmarks > menu entry), then the opening is really instantaneous. > Something must be wrong (it was the same with kde 3.1.5). > (Maybe this difference can be better showed when bookmark file is big) When accessing bookmarks via the menu obtained by right-clicking on the desktop, I noticed that the display of the bookmark window is really slow when you point directly on the "Bookmarks" entry (of the desktop menu), whereas it is quick when the mouse pointer first goes on another menu entry (for example "Create New") _that opens a submenu_. I mean, when I first pass on "Run Command", which opens no submenu, then going upper on "Bookmarks" shows a slow behaviour. But first going on "Create New", _waiting for the submenu to open_, then going down on "Bookmarks" opens the bookmark submenu much faster (as it should be). So I think this bug is definitely related to some submenu display/initialization concerns. Now, a question for the Debian maintainers of this package. This bug is now 2 months old. Has it been tagged upstream and forwarded to upstream? That does not seem to me... Can I ask you a simple question: Why? Herve -- _ (°= Hervé Eychenne //) Homepage: http://www.eychenne.org/ v_/_ WallFire project: http://www.wallfire.org/
Bug#247312: konqueror: opening of bookmarks is much slower when clicking directly on Bookmarks menu
On Fri, Jul 02, 2004 at 01:14:30PM +0200, Hervé Eychenne wrote: > > After a click on Bookmarks menu, the opening of the Bookmarks takes > > something like 2s, which is quite slow. > > If I click on "Go" menu and drags the mouse to the right (on Bookmarks > > menu entry), then the opening is really instantaneous. > > Something must be wrong (it was the same with kde 3.1.5). > > (Maybe this difference can be better showed when bookmark file is big) > When accessing bookmarks via the menu obtained by right-clicking > on the desktop, I noticed that the display of the bookmark window is really > slow when you point directly on the "Bookmarks" entry (of the desktop > menu), whereas it is quick when the mouse pointer first goes on > another menu entry (for example "Create New") _that opens a submenu_. > I mean, when I first pass on "Run Command", which opens no submenu, > then going upper on "Bookmarks" shows a slow behaviour. > But first going on "Create New", _waiting for the submenu to open_, > then going down on "Bookmarks" opens the bookmark submenu much faster (as > it should be). > So I think this bug is definitely related to some submenu > display/initialization concerns. Please note: I just upgraded to KDE 3.3.1 (testing), and the bug is still there. > This bug is now 2 months old. Has it been tagged upstream and forwarded > to upstream? That does not seem to me... > Can I ask you a simple question: Why? 247 days after, this question remains the same, and is still unanswered... :-( Herve
Bug#247312: konqueror: opening of bookmarks is much slower when clicking directly on Bookmarks menu
On Fri, Jan 07, 2005 at 12:49:17AM +0100, Adeodato Simó wrote: > * Hervé Eychenne [Fri, 07 Jan 2005 00:18:30 +0100]: > > > This bug is now 2 months old. Has it been tagged upstream and forwarded > > > to upstream? That does not seem to me... > > > Can I ask you a simple question: Why? > > 247 days after, this question remains the same, and is still unanswered... > > :-( > can I ask you a simple question: why haven't done it yourself? Done what? Forwarded it to KDE people and tagged the bug as upstream, you mean? Simply because I'm not a Debian developper myself, just a simple user, and mostly because the Debian way of doing things (correct me if I'm wrong) offers the possibility to report bugs to Debian and let the package maintainers deal with them whether they are Debian-specific or not. So, if some Debian maintainers should "refuse" to tag and forward upstream bugs to upstream, let's all get rid of this upstream tag everywhere, let's inform users explicitely that they have to deal with upstream directly, and modify the Debian procedures accordingly. But until that change is decided/done, if some Debian maintainers are unable to do this tagging and forwarding within a decent amount of time, they should really be considered as failling to do their maintainer's job properly, ok? Especially since doing such a minor thing would require so little of their time compared with the average Debian user, as they are supposed to have a much better understanding of the upstream practices, as well as things like being aware of known bugs, getting in touch with the upstream team, be subscribed to adequate upstream mailing-lists, etc. Without even mentionning being responsible for the good work of the application they proposed to help with. So, I did fill this bug to Debian because I could, and because I (naively) thought it would be a so simple and usual thing for them to process. Does this bitter response answer your question? What I would like to understand now is why the Debian counterpart failed to manage such a simple thing til now (more than 7 months of delay for a few minutes operation, let's face it). But frankly, I would prefer that, instead of replying to this post, any responsible Debian person would step up and take these 2 minutes of his time to do it at last. Herve
Bug#247312: konqueror: opening of bookmarks is much slower when clicking directly on Bookmarks menu
On Fri, Jan 07, 2005 at 10:51:09AM +0100, Jesús Roncero Franco wrote: > > Done what? Forwarded it to KDE people and tagged the bug as upstream, > > you mean? > > Simply because I'm not a Debian developper myself, just a simple user, > > and mostly because the Debian way of doing things (correct me if I'm wrong) > > offers the possibility to report bugs to Debian and let the package > > maintainers deal with them whether they are Debian-specific or not. > Ok, this bitter answer demonstrates that you don't know how things work here > (at leat in debian KDE). > To put it straight, there's not enought people and not enought time. I'm absolutely not supposed to know that... > > But until that change is decided/done, if some Debian maintainers are > > unable to do this tagging and forwarding within a decent amount of time, > > they should really be considered as failling to do their maintainer's > > job properly, ok? > Hervé, this is a "job" done in our spare time. You know, we all study/work > and > usually have some other life to attend, as you might have as well. So be a > little bit more understanding. Of course I can undertand that. But a problem remains: from the user point of view, the only visible part is an application that enables to report bugs, and a Web interface showing how this bug is dealt with. In this particular case, all an external user like me can see is that such an elementary task remained without any concrete action for 7 months, so there is a problem. If maintainers are so overbooked that they cannot even afford to process a whole kind of things, at least they should let the bug reporters know, so they are _aware_ of this fact, and maybe they can try to deal with things themselves (with upstream, here) if they can, trying _consciously_ not to overload maintainers a bit more. But until you let them know (and I know, you're to busy to even let them know ;-)... too much time is stupidly wasted. > > Especially since doing such a minor thing would require so little > > of their time compared with the average Debian user, as they are supposed > Sometimes, what you think it's going to take little time, is in fact a very > time consuming task. Some other time, there's so many bugs one can't deal > with them all, etc. Solution: take 1 minute per bug you feel you won't be able to process before long, and let the bug reporter know you probably won't deal with it soon. Please don't tell me none of you can do that. I know you all do only what you can (and that you're probably doing a good job for what to have the time to catch up), but let's face and handle resource shortage a bit better, please. Hervé
Bug#247312: konqueror: opening of bookmarks is much slower when clicking directly on Bookmarks menu
On Sat, Jan 08, 2005 at 05:26:48AM +0100, Adeodato Simó wrote: > * Hervé Eychenne [Sat, 08 Jan 2005 04:33:05 +0100]: > > Some ask why the submitter has not submitted the bug directly to > > upstream when noticing months after that nothing had happened. Once > > more, I regret: if the submitter gets no feedback, he'll consider > > that the upstream team had hard times chasing the bug (some bugs are > > tricky), certainly not that the Debian guys has left his report in the > > bottom of the barrel for months. Do you actually understand that? > no, because (unless the person doing it forgets to) you get a mail > when your bug is forwarded upstream. That's what _you_ Debian maintainer think, because you know exactly how the BTS works. The user is absolutely not supposed to know that in each and every detail, and that's not written in any document the average user "should" be aware of. Summary: contrary to any argument you have raised or may raise, I had no way to figure out that I should not have acted like I did, that is as an average user (read "not an experienced Debian maintainer"). Be prepared to flame other users for being at fault of not knowing that you're so buried in work that even the simplest requests may sleep for months without care. > > Sorry if I'm becoming more and more sarcastic, but I feel that some > > are more concerned with finding any excuse for justifying the > > unjustifiable, rather than actually trying to analyze the reasons and > > change things so that this will not happen again. > three random things that I did for Debian today: No one assumes you personnally don't do enough for Debian, so there is no point in justifying yourself like that... However, the Debian KDE team managment system as a whole leaked in this particular tag+forward case. Yet, rather than recognizing it and trying to make things better for the future, some get angry instead... I naively thought pointing the leak may have come to a better handling of this cases, but it's pretty clear now that probably no improvement in practices may ever come out of this discussion, sadly, so I stop here. In the end we've all wasted our time with annoying discussions for two days, and 8 months were wasted for this sleeping bug (and God only knows for how long it would have if I hadn't eventually insisted to know what was going on). With probably other similar cases existing, or to come. Great, you win. Hervé
Bug#247312: konqueror: opening of bookmarks is much slower when clicking directly on Bookmarks menu
On Sat, Jan 08, 2005 at 05:11:14AM +0100, Adeodato Simó wrote: > I see. could you please tell us what Style are you using (e.g., > Keramik, Plastik, some other) and what are your settings under Control > Center -> Appearance & Themes -> Style -> Effects? The style is HighColor Classic. And no change in the style configuration (style, effects, etc) has any impact on this odd behaviour. Hervé
Bug#247312: konqueror: opening of bookmarks is much slower when clicking directly on Bookmarks menu
On Sun, Jan 09, 2005 at 02:10:22AM +0100, Adeodato Simó wrote: > so, could you please: > (a) check what happens with other styles (to discard it being a > style issue). Please try Keramik and Plastik, both with 'menu > effect' enabled an disabled. I had tried this before sending the last email: no change at all. > (b) create a new system user and log in a KDE session. Add a few > bookmarks, and check. See if adding a large amount of bookmarks > (just start normal navigation, and press Ctrl-B for each page > you visit) makes the delay to be present at some point. I did that and noticed no change in speed (it's fast). Then, I copied the 150Ko bookmarks.xml file which caused the problem with my normal account to the new user's account: the problem disappears, everything is always fast as it should. So there's clearly a problem with my actual configuration (remember, that it only shows in particular situations described in the bug history) even if changing style and effects doesn't help. If only there was a reliable way to monitor (strace would be tricky) what konqueror exactly does within these 2.5s... maybe that would give a hint about what's going on... Do you have an idea of how it could be best achieved? Hervé
