Hi,

of course I have read http://api.kde.org/4.x-api/kdelibs-apid ... Group.html

but based on that I don't get a clue what a KServiceGroup is. So first question would be if anyone knows a better documentation?

I wonder if KDE provides THE KServiceGroup or if there are many KServiceGroups for all differnt kind of things and before using it we have to create on ourselves somehow. From kmenuedit is this code, see my comments inside the code:

Code: Select all

void TreeView::readMenuFolderInfo(MenuFolderInfo *folderInfo, KServiceGroup::Ptr folder, const QString &prefix)
{
    if (!folderInfo)
    {
       // yes we are in here
       folderInfo = m_rootFolder;
       folder = KServiceGroup::root(); // what does this do?
       qDebug() << folder -> relPath(); // it just shows a "/", where does this Service group come from?
    }

    if (!folder || !folder->isValid())
        return; // no we do NOT return here

    folderInfo->caption = folder->caption();
    qDebug() << folder->caption(); // This shows "SUSE-Menü" But where did it get that name from? some config file?
//more code



Would be great if someone has either a better documentation or can shed some light on what happens in the above code. I don't have an idea right know where to look.

Thanks.

You may find the following code helpful.

KServiceGroup's are created automatically by the Sycoca for you. To begin, simply call KServiceGroup::group( "" );
This gets you the "root" service group.

You then retrieve all children of that group, by calling entries() on the root KServiceGroup object.
Then you simply walk the tree. Only two types of item exist:

KService: These represent actual applications in the menu.
KServiceGroup: These represent the folders in the menu. You will need to repeat the above on them.

Code: Select all

    KServiceGroup::Ptr root = KServiceGroup::group( path );             
    if ( !root ) {                                                     
        kWarning() << "No Service groups";                             
        return;                                                         
    }                                                                   
    KServiceGroup::List list = root->entries();                         
    KServiceGroup::List::ConstIterator iterator = list.constBegin();   

    for ( ; iterator != list.constEnd(); ++iterator ) {
        const KSycocaEntry::Ptr entry = *iterator;     

        // Determine type of Help Item, and prepare data
        HelpItem * item;                               
        switch( entry->sycocaType() ) {                 
            case KST_KService:                         
            {                                           
                KService::Ptr service = KService::Ptr::staticCast(entry);
                // Do what you need to do here
                break;
            }
            case KST_KServiceGroup:
            {
                KServiceGroup::Ptr group = KServiceGroup::Ptr::staticCast(entry);
                // Do what you want to do here
                // "item" is the item you just created here, which will be used to correctly parent the items that will be created
                buildTree( item, group->relPath() ); // Call this function again, to "walk" the tree
                break;
            }
            default:
                break;
        }
        // Handling complete
    }
    // Final cleanup

Your answer sounds a bit like that the KServiceGroup contains only menus and the only purpose why this KServiceGroups was invented is for menus. The API documentation talks about screensavers. So do I have to distingiush after the root element what part of the tree I want to read when I want to read the KDE menu and not something else?

Thanks for the code snippet.

I do not know if ( or even how ) it is used for screensavers. The code snippet I posted most certainly only handles the menu.

Okay and the database is build by kbuildsycoca4, the input files to build the database are spread over multiple locations. One of them is for example /etc/xdg/menus:

Code: Select all

-rw-r--r-- 1 root root 33424  8. Okt 23:15 applications.menu
-rw-r--r-- 1 root root 10795 29. Jul 13:09 applications.menu.kde4
drwxr-xr-x 2 root root  4096 10. Dez 14:31 applications-merged
-rw-r--r-- 1 root root   407 19. Okt 20:13 ggz.menu
-rw-r--r-- 1 root root   279  5. Jan 2008  kde4-information.menu
-rw-r--r-- 1 root root  1755  7. Dez 15:38 kde4-settings.menu
-rw-r--r-- 1 root root  2008  8. Okt 23:15 yast-settings.menu


It looks like that there are more menus than only the KDE startmenu. So I have to tell KServiceGroup which menu I want, don't I? My assumption is for example that kde4-settings.menu is for the "Kontrol Center" and not for the start menu.

You do not need to worry where the information comes from. The KDE libraries and their associated applications such as kbuildsycoca4 gather the information and make it available to you, without you having to do any work other than making the needed function calls to retrieve the information.

for reading this is correct. But I am trying to work through kmenuedit since it seems not to work very well.... and hence I need to understand where which data comes from to see where in the chain the problem lies.

The data in the service group is sourced from the Sycoca, which is built by "kbuildsycoca4" whenever changes to what it stores changes. The code of kbuildsycoca4 is not likely to contain a bug relevant to this, as virtually all KDE applications are heavily dependent on the Sycoca.

KBuildSycoca4 is part of KDE Libs.