[12:09] <vaxo> hi
[12:09] <vaxo> im just making my own kubuntu live cd aaaaaand have a problem
[12:10] <vaxo> how the heck does kicker store all of its kmenu entries?
[12:16] <allee> vaxo: all desktop files below /usr/share/applications and /usr/share/applnk are used to generate the menu
[12:18] <vaxo> hm oki thanks
[12:19] <vaxo> but how do i clean up a group like "editors"
[12:20] <vaxo> no entries == no group?
[12:29] <allee> delete /usr/share/applnk/Editors/ ? (should be empty)
[12:32] <vaxo> this dir isnt there
[12:32] <vaxo> ;)
[12:32] <vaxo> well german kde
[12:32] <vaxo> so "editoren
[12:32] <vaxo> "
[12:32] <vaxo> but
[12:32] <vaxo> its not there aswell
[12:32] <vaxo> only one member left "scribus"
[12:32] <vaxo> no scribus.desktop file on the system anymore ... x restart ... its still there
[12:32] <vaxo> so "somewhere" it still contains that info
[12:33] <vaxo> dpkg -L just shows one scribus.desktop to be installed
[12:33] <allee> where?
[12:33] <vaxo> ehhhh
[12:33] <vaxo> hold on
[12:33] <vaxo> applnk
[12:33] <vaxo> didnt kill this one
[12:42] <vaxo> nope
[12:42] <vaxo> didnt work either
[12:51] <allee> vaxo: hmm, removed ksubtile (my only entry in Editors) and /usr/share/applnk/Editor is gone and so my Editor menu entry
[12:52] <allee> try run: kbuildsycoca
[12:52] <allee> just to be sure ;)
[01:07] <vaxo> hm still there
[01:08] <allee> grep -R ^Catego /usr/share/applications/ | grep -i editor
[01:12] <vaxo> hmmm it works for other menues
[01:12] <vaxo> but
[01:12] <vaxo> i cannot kill kate
[01:15] <vaxo> anyway
[01:15] <vaxo> i have to sleep
[01:15] <vaxo> but allee, youre ma man!
[01:15] <vaxo> ;)
[01:16] <vaxo> thanks for the hints, im on the right track now
[01:16] <vaxo> gn8
[01:19] <allee> vaxo: nite!  tomorrow I tell you about visibility=hidden (or something like that ;)
[01:19] <vaxo> hehe
[01:19] <vaxo> oki
[01:20] <vaxo> till then
[03:49] <spstarr_home> which KDevelop is in Beta2? I dont see the newest 3.3.x release:(
[04:53] <spstarr_home> hrm, are we going to add eric3 3.8.0?
[04:53] <spstarr_home> its rather old version in kubuntu and its broken dependencies right now in dapper
[04:59] <spstarr_home> oh
[04:59] <spstarr_home> eric3 -> eric
[04:59] <spstarr_home>  eric: Depends: python (< 2.4) but 2.4.2-0ubuntu2 is installed.
[05:00] <spstarr_home> doh
[05:00] <spstarr_home> stupid dependency check
[05:09] <spstarr_home> oh libqt3-mt is 3.3.5 in debian testing so we need to move this to dapper
[05:18] <spstarr_home> got it working
[05:18] <spstarr_home> move the eric3 python2.3 stuff to 2.4 site-packages
[05:18] <spstarr_home> worked
[08:19] <pef> hello
[08:21] <pef> Riddell: hello, no more informations about my mixxx upload :/
[08:37] <pef> Riddell: I wish get assignement for bugzilla #10185, but I don't have enough permissions (not allowed)
[08:42] <pef> Riddell: can you do something for me ? :)
[09:51] <icefox> _Sime: SYN?
[03:49] <pef> Riddell: konversation seems to be synced, please close bugzilla #10185
[05:06] <spstarr_work> any other KDE Ubuntu Toronto people? :-)
[06:07] <mornfall> booh
[06:08] <Riddell> spstarr: hybble lives in Hamilton, which I believe is close
[06:43] <Drakeson> Riddell: I changed that cover yesterday : http://gazor3.ece.queensu.ca/~hon/Drakeson/cd-disk2.svg
[06:43] <Drakeson> but I cannot do anything now (for a few days I guess)
[07:05] <spstarr> 1.3 hours from me
[07:05] <spstarr> Drakeson: you live Downtown Toronto?
[07:06] <Drakeson> yep
[07:52] <allee> AFAIR (is it true?) that on installation kmix is only enabled/started if sound is available, otherwise not? If yes, what 'trick' is used (that would be useful for kdebluetooth too))
[08:53] <Riddell> allee: kmix is always started (it's in kubuntu-default-settings as a saved session), it displays itself with a red X if it can't talk to the sound drivers
[08:54] <allee> Riddell: 'k. Again memory leak here :(
[09:06] <Riddell> allee: on kmix?
[09:07] <allee> Riddell: sorry,  in my brain not kmix
[10:44] <_Sime> icefox: I've blogged it up a bit: http://www.kdedevelopers.org/node/1602
[11:04] <allee> _Sime: really good blog!
[11:06] <_Sime> allee: thanks,
[11:07] <_Sime> allee: descriptions aren't too helpful IMHO. picture aren't hard. They just take a lot of work.
[11:07] <allee> fwiw: xkeyboard-config prefers to write core in GUI independ way so a gtk gui can be written ;)
[11:07] <allee> _Sime: lot of work -> lot of time --> a big problem ;)
[11:08] <allee> the highlighting of important part may be not so hard in principle
[11:08] <_Sime> allee: true, but it is also a problem that could be distributed to lots of other people.
[11:09] <allee> a keyboard is normaly augmented from many different peaces.  So I one finds a way to 'catch' the augment one has groups of keyboard keys
[11:09] <allee> _Sime: right
[11:09] <_Sime> allee: highlighting could just be as simple as drawing a red border, or glow. It doesn't even have to be animated.
[11:09] <_Sime> allee: just a drawn picture of a keyboard with the important keys in a brighter colour, for example.
[11:09] <allee> I don't meant animated but how to determine 'group' of keys that belong together
[11:10] <_Sime> sorry, which part are you thinking of exactly?
[11:13] <allee> 'every keymap' starts with xkb_keycodes "basic  (see /etc/X11/xkb/keycodes/xfree86) then PC<xyz> use it and add more keys, in keycodes/inet MM keys are added
[11:14] <allee> so every group can be defined by keys added via an 'include' statement of xkb_keycodes.  Forming a group with a, e.g. different color
[11:15] <_Sime> I was thinking about how people can identify a US layout keyboard by looking at the layout of important keys, while not being distracted by things which are not important such as the pipe key and things like "mulitmedia" keys.
[11:17] <allee> yeah, but if the visualization use no emphasiz of the 'basic' group and colorized the keys that are defined in 'pcXYZ' group you get what you want
[11:17] <_Sime> ok, I see what you are getting at.
[11:18] <allee> and /etc/X11/geometry contains input for keyboard drawing.  This is normally no added because there _no_ tool to easily create them
[11:18] <allee> + :(
[11:19] <allee> I submitted some MM definitions but never had the nerve to fight with geometry files
[11:20] <allee> _Sime: IMHO as a start a tool that allows to easly catch undefined keys and let add my keys to an existing keyboard file would be a good start.
[11:21] <allee> For your plans you need lots of people but if it takes pages to describe how to produce them, and 'hours' to use them you find noone that supplies input
[11:25] <allee> For me it looks like every information is or can be added to /etc/X11/*/.  What's missing is a good tool to find (as you blogged) _and_ to extent add new keyboards easily
[11:32] <Riddell> debian merges needing done http://tinyurl.com/9cmuw
[11:36] <allee> Riddell: do you know some (kde) pkgs that use scons?  I hacked something togehter for codeine, but it's, well, a hack
[11:39] <Riddell> allee: kdissert
[11:40] <allee> Riddell: thx! I'll check it
[11:40] <Riddell> allee: no cdbs though, that would be handy
[11:41] <allee> Riddell: yeah, I missed cdbs a lot last night while fighting again with dh_make 
[11:42] <allee> But scons cdbs is  IMHO not worth starting yet  As soon as bksys/scons stabilized for KDE4, we should start on hacking a cdbs module.
[11:43] <allee> many extragear developers are only waiting for the stabilization to use them for their (KDE3) apps right away
[11:46] <Riddell> :)
[11:47] <allee> kdissert rules file is much cooler than mine hack.  Good! Thx again
[11:55] <_Sime> allee: thanks for the feedback.