KDE 4: the good, the bad and the broken

[Kevin Krammer]

On Thursday, 2010-04-29, Draciron Smith wrote:
> >> I will add Kedit to the list.
> >
> > IIRC it wasn't dropped as in explicitly removed by decision, but it
> > became unmaintained.
> > For a short period there was a new maintainer who was working on it as a
> > project with its own release cycle (e.g. like Amarok), but he eventually
> > moved to other things as well.
> 
> Did you mean IIRC or Kedit?

Sorry, used an acronym without thinking.
IIRC means "If I Remember Correctly"

> > Are the .desktop files for these applications installed into the proper
> > locations?
> > While it is quite uncommon today to find packages which either do not
> > install or misplace their description files, it could still happen.
> 
> Gimp is installed in it's default location.

Strange, then it should have been picked up by the menu all by itself.
Can you check if you have something like

/usr/share/applications/gimp.desktop

> I install Firefox from
> tarballs in /usr/bin since that makes it happy.

Does the tarball contain an application description file, e.g. 
firefox.desktop?
If yes, maybe the tar ball installation places it at a wrong location or it 
requires manual copying.

>  The installation method I normally use is rpms from Fedora
> repositories. If I install something from tarball I expect to have to
> go edit the menu manually but am sometimes pleasantly surprised to see
> it add itself to the menu.

Installations from source usually get this right because they default to 
/usr/local as the installation prefix and thus their description files end up 
in /usr/local/share/applications, which is one of the default paths.

Installations from binary tar balls either require to be extracted at a 
certain position or require manual copying of the description file for 
automatic application detection to work.
E.g. copying the application's .desktop file to /usr/local/share/applications 
(system wide) or $HOME/.local/share/applications (single user)

> > Default locations per specification are /usr/sharea/applications and
> > /usr/local/share/applications.
> > Those can be changed and/or extended by environment variables so a good
> > way to check the resulting search list is
> >
> > kde4-config --path xdgdata-apps
> 
> /home/draciron/.local/share/applications/:/usr/share/kde-settings/kde-profi
> le/default/share/applications/:/usr/local/share/applications/:/usr/share/ap
> plications/
> 
> Ah... I see the problem. No /usr/bin anything installed to /usr/bin
> which is the default home for a whole lot of stuff isn't in there.

No, this is a misunderstanding, I should have explained this better.
Basically if /usr is the prefix used for a software's installation, different 
parts of it go to different locations below /usr, e.g. executables into 
/usr/bin, libraries into /usr/lib, etc

Application description files used by launchers (e.g. KDE's or GNOME's 
application menus) go into /usr/share/applications.

Newly appearing files there are usually detected by means of file system 
change notifications, but sometimes those do not happen or timestamps are not 
updated correctly.
In such cases the cache [1] used for accessing the information at runtime gets 
out of sync with the information available in the text based .desktop files.
For KDE's cache a manual update can be triggered like this:

kbuildsycoca4 --noincremental


> > Hmm, short cut as in "link to program" or more precisely as in "right
> > click -> new ->link to program"?
> 
> A program or a location. Those are the two things I get asked about a
> whole lot. I don't use it myself. Sambba shares seem especially
> popular things people want shortcuts too.

Don't have a Samba share to try with, but linking to a program works for me by 
"context menu -> new" and throigh Drag&Drop from the K-Menu.
Works with individual folder views and when using the traditional "Desktop" 
through the respective folder view activity.

> >> > The loss of the ability to use a different image for each desktop.
> >> > Initially I thought this a minor annoyance but I didn't realize how
> >> > much I depended on this to keep track of what desktop I was actually
> >> > on.
> >>
> >> I think that's back in KDE 4.5.
> >
> > I think was will be back is an easier way to do it. AFAIK it is already
> > possible, just not as obvious as it should.
> 
> Please explain how to do it. I'd really really like to have different
> wallpapers for each of my desktops. I make too many mistakes thinking
> I'm on one desktop but I'm actually on another.

I think pre-4.5 this involves creating a separate activity for each desktop, 
so it is probably not worth the hassle.
(See under "Activities" here http://userbase.kde.org/Glossary though there is 
probably a page describing this in more detail)

Cheers,
Kevin

[1] Reading and parsing lots of files is a time consuming process, mainly due 
to I/O delays. Frameworks such as KDE and GNOME offset this problem by 
preparing a user local file containing the combined information in a format 
that makes it fast to access 
-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde/attachments/20100429/c7d2f30a/attachment.sig>
-------------- next part --------------
___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.