Page 1 of 3 123 LastLast
Results 1 to 10 of 22

Thread: More on OpenSuSE 11.1/KDE 3.5 Menu Delay

  1. #1

    Default More on OpenSuSE 11.1/KDE 3.5 Menu Delay

    Have examined thread beginning with post "Very Slow SLAB Loading" by IntelliJani on 15th April 2008 leading to a reference to "resolved" bug report 348183 and including suggestions along the way including removing ~/.thumbnails, running SuSEconfig, etc, etc. None of the suggestions help. I notice the bug report is marked "resolved". Resolved how?

    Tested the notion that there might be something in the user's home directory that was causing the problem. Created new user. On first login, the disk thrashing (both HD and USB disk) occurred for approx 2 min before pressing the chameleon. On subsequent logins the delay occurred only after pressing the chameleon.

    Am puzzled that this problem was allegedly "resolved" nearly 2 years ago but is still occurring. I'd appreciate hearing from anyone who has a solution to this irritating problem.

  2. #2
    Join Date
    Jun 2008
    Location
    The English Lake District. UK - GMT/BST
    Posts
    36,729
    Blog Entries
    20

    Default Re: More on OpenSuSE 11.1/KDE 3.5 Menu Delay

    Are you sure it's not beagle indexing
    In 11.1 most people disabled or deleted it
    Leap 15.1_KDE
    My Articles Was I any help? If yes: Click the star below

  3. #3

    Default Re: More on OpenSuSE 11.1/KDE 3.5 Menu Delay

    Thanks very much for the response. I believe that the problem is unrelated to Beagle. I've tried deleting it, and also running with it. My worry was that Beagle indexing might actually be trying to speed up menu loading.

    As far as Beagle itself is concerned, I'd love to read some discussion about what value it provides and at what resource costs. I never use Beagle Search for anything. Is there a downside to disabling it?

    My guess is that somebody needs to look at the code executed when the chameleon is pressed. Likely somebody put some really bad code in there, and he knows who he is.

    Anyway, thanks again for your response.

  4. #4
    Join Date
    Jun 2008
    Location
    The English Lake District. UK - GMT/BST
    Posts
    36,729
    Blog Entries
    20

    Default Re: More on OpenSuSE 11.1/KDE 3.5 Menu Delay

    IIRC there was an issue with this delay in the menu with 11.1 but I though it only affected kde4
    I am fairly certain it was fixed thru updates.

    On a modern system beagle shouldn't be too much of an issue though. As it is beagle does work well regardless of it's bad rep.
    Leap 15.1_KDE
    My Articles Was I any help? If yes: Click the star below

  5. #5

    Default Re: More on OpenSuSE 11.1/KDE 3.5 Menu Delay

    The menu has a search bar at the top. I'm guessing that some sort of index cache is being built, once per boot (or login), to facilitate searching from the menu. I'd gladly sacrifice this search feature to get rid of the symptom. Alternatively, possibly the cache should be made persistent and maintained by Beagle on an ongoing basis--rather than being completely rebuilt on first pressing the chameleon.

  6. #6
    Join Date
    Jun 2008
    Location
    The English Lake District. UK - GMT/BST
    Posts
    36,729
    Blog Entries
    20

    Default Re: More on OpenSuSE 11.1/KDE 3.5 Menu Delay

    The search function in the kicker is nothing to worry about.

    Can you please post the result of this form a terminal

    Code:
    zypper lr -d
    Leap 15.1_KDE
    My Articles Was I any help? If yes: Click the star below

  7. #7

    Default Re: More on OpenSuSE 11.1/KDE 3.5 Menu Delay

    Here goes:

    [?1034h# | Alias | Name | Enabled | Refresh | Priority | Type | URI | Service
    --+--------------------+-----------------------+---------+---------+----------+--------+-----------------------------------------------------------------+--------
    1 | Packman Repository | Packman Repository | Yes | Yes | 99 | rpm-md | Index of /pub/packman/suse/11.1 |
    2 | openSUSE 11.1-0 | openSUSE 11.1-0 | Yes | No | 99 | yast2 | cd:///?devices=/dev/sr0 |
    3 | repo-debug | openSUSE-11.1-Debug | No | Yes | 100 | NONE | Index of /debug/distribution/11.1/repo/oss |
    4 | repo-non-oss | openSUSE-11.1-Non-Oss | Yes | Yes | 100 | yast2 | Index of /distribution/11.1/repo/non-oss |
    5 | repo-oss | openSUSE-11.1-Oss | Yes | Yes | 100 | yast2 | Index of /distribution/11.1/repo/oss |
    6 | repo-source | openSUSE-11.1-Source | No | Yes | 100 | NONE | Index of /source/distribution/11.1/repo/oss |
    7 | repo-update | openSUSE-11.1-Update | Yes | Yes | 20 | rpm-md | Index of /update/11.1 |

    Sorry about the untidy format--not sure what to do about it though.

  8. #8
    Join Date
    Jun 2008
    Location
    The English Lake District. UK - GMT/BST
    Posts
    36,729
    Blog Entries
    20

    Default Re: More on OpenSuSE 11.1/KDE 3.5 Menu Delay

    First, not related to your issue but you should change Packman repo priority to 10
    Then do an unconditional update in the Packman repo

    There is a video here of it being done on a kde repo
    carl4926 - Unconditional Update in Yast Software management
    Leap 15.1_KDE
    My Articles Was I any help? If yes: Click the star below

  9. #9
    Join Date
    Jun 2008
    Location
    The English Lake District. UK - GMT/BST
    Posts
    36,729
    Blog Entries
    20

    Default Re: More on OpenSuSE 11.1/KDE 3.5 Menu Delay

    Back to your other issue.

    You could try adding this repo

    kde3
    Index of /repositories/KDE:/KDE3/openSUSE_11.1

    Then do update all in this list if newer version avail
    Leap 15.1_KDE
    My Articles Was I any help? If yes: Click the star below

  10. #10

    Default Re: More on OpenSuSE 11.1/KDE 3.5 Menu Delay

    OK, thanks for the suggestions and for continuing to help me sleuth this issue. My favorite theory is still that an index cache is being built on first clicking the chameleon, in order that future use of the menu search bar is facilitated.

    It appears that the menu search locates just about anything, anywhere, that appears to be executable--not just those executables that appear in the menu entries themselves. I can imagine that an index cache would be needed and that, depending on disk size and number of mounted volumes, building that cache could take a fair amount of time. Did I mention that if I have a USB disk plugged in when first pressing the chameleon--it also thrashes for about 1 minute after the main disk thrashes for about 1 minute, making the total thrash/delay time 2 minutes.

    I can't let go the theory that all mounted volumes are scanned for some reason on first chameleon click. It seems to me most likely that the purpose of disk scanning is to build an index.

    Anyway, I'm going to start reading code associated with kicker and allies....

Page 1 of 3 123 LastLast

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •