[01:53] <meebey> I have a question regards handling "seen" behavior of notifications which is not covered in the NotifyOSD wiki
[01:54] <meebey> say for an IM app there is a private message received and the user is current not in the window window, a notification is shown
[01:54] <meebey> now if the user goes back to the application (say because the notification is not supporting actions) should the app clear the notification as soon as the window is focused and the user is seeing the message?
[03:35] <meebey> kenvandine: you are around?
[04:40] <meebey> kenvandine: see twitter replies :)
[08:18] <klattimer> morning all
[08:22] <didrocks> hey klattimer, how are you?
[08:22] <klattimer> doing good
[08:23] <klattimer> gonna have to split up a patch today and try and wangle it into a partly already patched bit of code
[08:23] <klattimer> *sigh* a programmers work is never done
[08:23] <didrocks> klattimer: yeah you can always refactoring and such ;)
[08:24] <didrocks> klattimer: I'm cleaning openoffice package this week, I can ensure you it's not a joy as well :)
[08:24] <klattimer> didrocks: ouch, ooo is hell I'm sure
[08:24] <didrocks> klattimer: yeah, the makefile for the packaging (debian/rules) is more than 3 000 lines :/
[08:24] <klattimer> I can believe it
[08:35] <klattimer> morning seb128
[08:36] <seb128> hey klattimer
[10:41] <klattimer> seb128: I can't seem to find the libappindicator with the set_label api in launchpad
[10:41] <klattimer> any ideas where it might be?
[10:42] <seb128> klattimer, https://code.edge.launchpad.net/indicator-application/
[10:42] <seb128> I guess lp:~ted/indicator-application/labels-in-the-indicator
[10:43] <seb128> or, and lp:~ted/indicator-application/label-in-the-lib
[10:43] <klattimer> oh I ended up on https://code.launchpad.net/ubuntu/+source/indicator-application
[10:43] <seb128> right that can be confusing on launchpad
[10:43] <seb128> if you browse from the packages you land on ubuntu specific things
[10:43] <seb128> not upstream projects which is what you want there
[10:47] <klattimer> k
[10:47] <klattimer> although launchpad is great
[10:47] <klattimer> it has some minor issues like this I'm slowly learning
[11:42] <djsiegel> vish: oing
[11:42] <djsiegel> ping*
[11:42] <vish> djsiegel: hey.
[11:47] <djsiegel> vish: found a juicy paperctu
[11:47] <djsiegel> papercut even
[11:48] <vish> djsiegel: cool!
[11:48] <thorwil> interesting metaphor-combo :)
[11:50] <djsiegel> mmm, taste the delicious papercut juice
[11:53] <djsiegel> vish: https://bugs.edge.launchpad.net/hundredpapercuts/+bug/615793
[11:54] <vish> hmm , i think there was a notify-osd spec for that already..
[11:54] <vish> morphing windows?
[12:42] <bdrung> i am testing the ubuntufont. it looks ugly in the gnome-terminal, because the terminal tries to use it monospaced. what the plan for monospace?
[12:44] <klattimer> bdrung: you should never use a non-monospace font in a terminal because it'll bork badly
[12:45] <klattimer> switch to another font, I'm not sure that the ubuntufont even has a monospace one planned
[12:47] <bdrung> klattimer: that's the question: is there a monospace version planned?
[12:48] <klattimer> dunno
[12:48] <klattimer> monospace fonts are hard as they require very very intrictate understanding of how monospaced fonts are applied
[12:48] <klattimer> e.g. the { is better for programmers when it's very OBVIOUSLY a { same with 0 which should be struck through or dotted to make it clear
[13:42] <bratsche> bdrung: I've never heard that there is a monospace version planned.  I suspect there is not.
[13:43] <bratsche> bdrung: Actually, I was just told by a couple guys on the design team that they think there is a plan for it, but I don't think there is any timeframe for it.
[13:44] <bratsche> brb
[13:45] <bdrung> having it on the todo list is better than nothing
[13:49] <klattimer> davidbarth: I'm currently hacking on the gsd indicators and there's a bit of a problem
[13:50] <klattimer> it seems libgnomekbd might need patching in order to indicate the current layout
[13:50] <klattimer> seems it has a subclass in there for the status_icon
[13:50] <klattimer> :/
[13:50] <davidbarth> klattimer: hi
[13:51] <klattimer> so I doubt i'm going to be able to get this done by tomorrow
[13:51] <davidbarth> hmm, what about wrapping that class into an app. indicator version but at gsd's level?
[13:51] <davidbarth> hmm, or
[13:51] <davidbarth> klattimer: do you have an idea who else may be using that libgnomekbd class?
[13:52] <klattimer> davidbarth: it looks like it isn't used by anyone else
[13:52] <klattimer> it uses cairo to draw the surface
[13:52] <klattimer> I'm trying to find a way to get the current layout text out of the thing to set as a label
[13:52] <davidbarth> what i'm wondering is if a g-s-d patch only gives that change a better chance of being accepted upstream as a build dependency / or something easier to distro-patch
[13:52] <klattimer> but then I have the problem of how/when to set the label
[13:53] <davidbarth> as opposed to messing up with a lib api signature
[13:53] <klattimer> i think you're right
[13:53] <klattimer> hacking the lib would be problematic
[13:53] <klattimer> but I doubt anything else is using the gkb_status_icon
[13:54] <davidbarth> wdym with how/when to set the label?
[13:54] <davidbarth> if done at the library level? or when youṕ re in g-s-d?
[13:55] <klattimer> well, in the status icon, the label changes on click, or by the menu
[13:55] <klattimer> but with our indicators it might be slightly more problematic
[13:55] <klattimer> this has a lot of weird code crossover between libgnomekbd and gnome-settings-daemon
[13:55] <klattimer> it's not very well segregated at all
[13:56] <davidbarth> well, i don't have the code handy right now
[13:56] <klattimer> I'm printing the function which I believe does the work
[13:56] <klattimer> I'll pull it apart and find the bits which matter
[13:56] <davidbarth> but i'd say keep the lib manage the model side of the story, and duplicate what it'd take in g-s-d to cleanup the "view" side
[13:56] <klattimer> see how hard/easy it'll be to make gsd do this for app-indicators
[13:56] <klattimer> I really don't want to touch libgnomekbd
[13:57] <davidbarth> right
[14:00] <seb128> didn't the patch from jen in lucid did that?
[14:00] <seb128> ie was touching only g-s-d
[14:01] <seb128> libgnomekbd is also used in the gnome-screensaver unlock dialog to indicate the keyboard layout
[14:18] <klattimer> davidbarth: seb128 I think I might be able to do it without libgnomekbd but it's going to be messy :/
[14:19] <seb128> we had a patch working last cycle, can't you just reuse that and use the new api to the set the label?
[14:19] <seb128> the only issue it had is that it used an icon and that didn't reflect the layout
[14:19] <seb128> because there was no set_label yet
[14:20] <klattimer> seb128: that's what I'm trying to do
[14:20] <klattimer> but the problem is that libgnomekbd keeps all the labels private in a "globals" struct
[14:20] <klattimer> and has no method to get_short_name_for_group(int group) or some such
[14:20] <klattimer> which I could use directly
[14:20] <klattimer> instead I'm going to have to recreate some of the code from libgnomekbd in order to get it to work
[14:21] <seb128> right
[14:22] <seb128> it's suboptimal but it seems there is no better way
[14:22] <klattimer> seb128: take a look
[14:22] <klattimer> http://paste.ubuntu.com/475924/
[14:22] <klattimer> this is the code I've lovingly extracted from libgnomekbd
[14:23] <klattimer> in libgnomekbd this code is spread across so many different parts of the file, I'm not sure if there'll be some kind of dependency on the order of things or what
[14:23] <klattimer> but that's basically what's needed in order to get the short names out for the label
[14:23] <seb128> ok
[14:23] <seb128> session restart brb
[14:24] <davidbarth> klattimer: things live in libklavier actually, right? so the libgnomekbd is just a wrapper around the actual model data; so i think that's fine to shortcircuit it
[14:33] <klattimer> davidbarth: that's pretty much the plan
[14:33] <klattimer> although it's ugly
[14:33] <klattimer> and requires a bit of digging
[14:33] <klattimer> not sure I can get this done by feature freeze :/
[14:37] <davidbarth> klattimer: you mean this week?
[14:37] <klattimer> yeah
[14:38] <davidbarth> well, log off or /away; we'll let you work now ;)
[14:38] <klattimer> :)
[14:38] <klattimer> its OK, I've got multiple machines here
[14:39] <klattimer> it's like the setup in swordfish in my office
[14:39] <klattimer> except the multiple displays aren't arranged in a particularly cool way
[14:46] <meebey> is appindicator a replacement of gtk statusicon if available?
[14:52] <klattimer> meebey: yeah
[14:52] <klattimer> in basic terms
[14:52] <klattimer> it's actually an improvement on the concept of the notification area in many many ways
[14:53] <meebey> ok, and whats the connection to messaging menu? is it ok if my application support messaging menu + app indicator?
[14:53] <klattimer> meebey: that depends on how you classify the usage of either function
[14:53] <klattimer> if it's ONLY messaging related, then messaging menu
[14:54] <klattimer> if it's got some bits which are outside of the messaging menu scope, then pop it in the indicator applet
[14:54] <klattimer> meebey: there are specifications for this on the wiki, I'm really busy right now, but hope you get on well with using the API's
[14:54] <klattimer> personally, I really really like app-indicators, and am currently working on porting apps to use it
[14:54] <meebey> I am reading the wiki right now, thanks
[14:55] <jcastro> https://wiki.ubuntu.com/DesktopExperienceTeam/ApplicationIndicators
[14:55] <jcastro> and
[14:55] <jcastro> https://wiki.ubuntu.com/CustomStatusMenuDesignGuidelines
[14:56] <meebey> I will treat gtk statusicon as deprecated then and add addindicator support to smuxi
[14:56] <jcastro> oh awesome, you're the smuxi person?
[14:56] <meebey> the issue with statusicon is that I cant enable it by default as per GNOME HIG ;)
[14:56] <meebey> jcastro: yeah I am the crazy hacker
[14:56] <jcastro> I think for irc programs it's supposed to be a messaging menu? at least that's how it is with xchat
[14:57] <meebey> jcastro: look: http://twitter.com/smuxi/status/20763746895
[14:58] <jcastro> oh dude, nice
[14:58] <meebey> jcastro: while reading all the madness patches, I think I have better ayatana support than all the other apps out there ;)
[14:58] <jcastro> I've been meaning to try smuxi for a while
[14:58] <jcastro> meebey: oh, check this out
[14:58] <dieki> Hey, does anybody know if RGBA is still planned for Maverick?
[14:59] <meebey> jcastro: I have find some design issues that should be discussion on the mailing list
[14:59] <meebey> s/find/found/
[14:59] <jcastro> do you do anything funky with your menus? or just normal gtk menus?
[14:59] <jcastro> https://wiki.ubuntu.com/DesktopExperienceTeam/ApplicationMenu
[14:59] <jcastro> dieki: I don't think it is, I could be wrong though
[15:00] <meebey> jcastro: no special menu, just plain gtk menu, I would like to know of ApplicationMenu works with smuxi or not
[15:00] <meebey> jcastro: its not packaged in debian yet I think
[15:00] <jcastro> meebey: I see it in ubuntu, so it must be in debian
[15:00] <dieki> jcastro: Okay, thanks. Wonder why it got delayed again... (Not that it being delayed from Lucid was really suprising)
[15:00] <jcastro> I can test it with the menu now
[15:01] <meebey> jcastro: if you want to give the ayatana support in smuxi a go, grab it from git
[15:01] <jcastro> dieki: last I saw there were still bugs?
[15:01] <jcastro> meebey: let me rule out that the menu works first
[15:03] <dieki> jcastro: Well, in that case it's probably right in being delayed. I'm suprised RGBA wasn't on during the alphas though, it would have gotten far more testing.
[15:03] <jcastro> dieki: I think it's more of a case of finding time to fix the bugs than getting bugs filed
[15:04] <jcastro> meebey: ok I need to update my netbook and whatnot, I'll test the menu and then try it from git
[15:04] <dieki> jcastro: Ah, okay. Thanks.
[15:05] <meebey> jcastro: the main purpose of the status icon currently is to hide/show main window and quit, or should I skip app indicator on this case? I am open to use th app indicator for new innovative things but this is new land to me :) and I dont have (actually know) a single application supporting this for some inspiration
[15:06] <meebey> jcastro: thanks for testing :)
[15:07] <jcastro> I am unsure of the design aspects
[15:07] <jcastro> posting on the ayatana list asking for recommendations might be a good idea
[15:07] <jcastro> or maybe mpt is around to give a recommendation
[15:07] <meebey> ok, will do
[15:08] <klattimer> jcastro: hows it going?
[15:09] <jcastro> klattimer: good, you?
[15:09] <klattimer> good good
[15:09] <klattimer> cooking up a patch for keyboard indicator right now
[15:09] <jcastro> klattimer: I don't know if I mailed you but I am off this week, just checking in on occasion.
[15:09] <klattimer> it's looking OK
[15:09] <jcastro> they keeping you busy?
[15:09] <klattimer> yeah, there's been a lot to look over to get myself up to speed on some things
[15:09] <klattimer> but I'm hanging in there and getting through it
[15:09]  * jcastro nods
[15:10] <klattimer> hoping I can get this patch done today
[15:10] <klattimer> so I can maybe get the indicator for bluetooth tested and working by friday
[15:12] <mpt> meebey, I suggest using the messaging menu instead of having a separate menu.
[15:13] <mpt> meebey, how to handle IRC (where there's a hum of messages, and many of the messages aren't for you) is an interesting problem I haven't thought much about yet.
[15:13] <meebey> mpt: I solved that already, it only triggers on highlights
[15:13] <mpt> fair enough
[15:13] <meebey> mpt: that is, nick said on channel or pms
[15:14] <meebey> even says who said your nick on channels :)
[15:15] <meebey> mpt: the messaging menu can't have a context menu per application, I should live with that I guess? users should click on icon to get the window and then use the window menu, right?
[15:16] <mpt> yes
[15:17] <meebey> mpt: ok thanks
[15:17] <meebey> mpt: another topic I would like to get guidelines for is the close behavior of a window
[15:17] <meebey> what is the recommended way for that?
[15:19] <mpt> meebey, I'm not sure what you mean
[15:19] <gambs> bdrung: ping?
[15:19] <meebey> mpt: when you click the closee button the main window should it quit the app, hide the window, etc
[15:20] <bdrung> gambs: pong
[15:20] <meebey> mpt: thats a question that pops up when messaging menu and/or application menu gets used
[15:21] <mpt> meebey, if it's a single-window application, closing the window should exit the application. We try to have a clear distinction between (a) applications, which are based around windows and sometimes have a status menu, and (b) services, which are most often accessed from a status menu but sometimes have a window.
[15:22] <meebey> it's a tabbed single window for all the chats, so close should exit I guess
[15:29] <meebey> mpt: thanks for the info
[15:36]  * klattimer thinks he *might* have fixed the keyboard indicator 
[15:36] <klattimer> wooohooo
[15:36] <klattimer> building now :)
[15:43] <nickster> lo folks... ux bod here lurking for a bit...would like to contribute to the ayatana/ubuntu UX development, so will lurk until more clued
[15:53] <mpt> hi nickster, welcome
[16:03] <klattimer> ok, well that didn't fix it :(
[16:03] <klattimer> now I have no indicator at all
[16:03] <klattimer> :/
[16:06] <klattimer> tedg: is your branch label-in-lib for libappindicator complete?
[16:06] <tedg> klattimer, Yes, I'm working on merging it now.
[16:06] <klattimer> ok cool, I'm testing and hitting a snag, just wanted to check that it does what's expected right now, so this is definitely a problem with my code
[16:07] <klattimer> it's kinda hard to test gnome-settings-daemon as it starts/restarts on login so I can't get output
[16:07] <klattimer> do you have any ideas wrt to that?
[16:15] <klattimer> tedg: I'm having trouble with your branch
[16:16] <klattimer> I have app_indicator_new (...) and then immediately after app_indicator_set_label(app_indicator, "KBD_LABEL", NULL);
[16:16] <klattimer> and the label still isn't set
[16:16] <klattimer> maybe I should wait to test my patch until you've merged?
[16:16] <tedg> klattimer, As in the property isn't set or that the indicator isn't showing the label?
[16:16] <klattimer> the indicator isn't showing the label
[16:17] <tedg> klattimer, Yeah, that branch only fixes the lib, there's another one that fixes the indicator.   I split it in to two to make the review easier :)
[16:17] <klattimer> ok, well let me know when you've merged so I can test it
[16:17] <klattimer> I'll still be around tonight later as it's approaching "home time" in the UK
[16:18] <klattimer> so drop me a shout when it's done, I'm really eager to see if this patch is actually working
[16:18] <klattimer> want to get it off my plate if you know what I mean :)
[16:18] <tedg> klattimer, There, all in.
[16:19] <tedg> klattimer, Yeah, I understand.
[16:19] <klattimer> oh whats the lp: branch?
[16:19] <tedg> klattimer, I want to see it work in more than the demo app as well too :)
[16:19] <tedg> klattimer, lp:indicator-application
[16:19] <klattimer> hehe
[16:19] <klattimer> wicked
[16:19] <klattimer> :)
[16:19] <klattimer> to clarify, does setting a label unset the icon?
[16:19] <tedg> klattimer, In the examples directory there is a small program that sets a label, just if you want to check things.
[16:20] <tedg> klattimer, No, it shows the icon as well.
[16:20] <klattimer> tedg: is there a way to unset the icon, or can you just app_indicator_new with a null icon?
[16:21] <tedg> klattimer, No, I think the requirement from design was to always have an icon.  Though we should probably double check that.
[16:21] <klattimer> mpt would you like to clarify?
[16:21] <tedg> mpt, I thought when we discussed putting labels in app indicators, we said that we were going to require an icon as well.  So there'd always be one.  Is that what you remember?
[16:22] <mpt> tedg, yep.
[16:22] <klattimer> mpt: are there no concerns about the space being taken up by an icon+label?
[16:24] <mpt> klattimer, a label should be used only when it's extremely useful (e.g. for showing the time remaining on battery)
[16:24] <mpt> Most of the time it should be just an icon.
[16:24] <klattimer> mpt: well, we can't do icons on keyboard indicator
[16:24] <klattimer> we just have GBr, GBr2, USA etc... as a label text
[16:25] <mpt> klattimer, I've already specified in great detail what that icon should look like. I recognize you might not be able to implement it as an icon in time, but please don't persecute me about it
[16:26] <klattimer> ok
[16:26] <klattimer> cool
[16:26] <mpt> How you implement it is up to you and tedg
[16:32] <klattimer> tedg: where's the test
[16:32] <klattimer> after updating I still see no label
[16:33] <klattimer> oh hang on I've found it
[16:33] <klattimer> dumbass me
[16:33] <klattimer> :/
[16:34] <tedg> klattimer, You may need to restart the applet to load the new library.
[16:34] <klattimer> tedg: I logged out and back in
[16:34] <tedg> klattimer, That should work too :)
[16:34] <klattimer> I dunno, I'm gonna look at your sample client
[16:34] <klattimer> to see what I've done wrong
[16:40] <klattimer> tedg: the only difference I see is that I hadn't set the guide
[16:41] <klattimer> but there's a chance that the plugin is crashing perhaps, so that would account for the non-existent label :/
[16:41] <tedg> klattimer, Hmm, that shouldn't make a difference.  Do you set a menu?  Sometimes people forget that, but it's required.
[16:41] <klattimer> tedg: a menu is definitely set
[16:41] <tedg> klattimer, Is there an icon but no label?
[16:41] <klattimer> as it worked with just an icon
[16:41] <klattimer> no icon or label
[16:41] <tedg> klattimer, Hmm, look in ~/.cache at the log and see if it has anything?
[16:42] <tedg> klattimer, Also, if you grab libindicator-tools you can run $ /usr/lib/libindicator/indicator-loader /usr/lib/indicators/3/libapplication.so  and it will put the app indicators in their own window.  But then give you output when they get added and removed.
[16:43] <klattimer> tedg: awesome tip, except gnome-settings-daemon is loaded on login/logout so it makes it a bit harder
[16:43] <klattimer> can't seem to load it any other way
[16:43] <klattimer> nothing appears to be in the logs, I've changed my code, removing the major changes and just setting the label to see what's going on there
[16:45] <tedg> klattimer, Hmm.  I've not tried it before, but could you run the bustle logger at login and what the dbus traffic?
[16:46] <tedg> klattimer, I think there's some sort of race in libappindicator where sometimes things at startup fallback into the notification area, but that doesn't sound like what you're seeing either.
[16:46] <tedg> klattimer, But, perhaps the dbus traffic would give a clue.
[16:47] <klattimer> maybe
[16:50] <klattimer> tedg: your code must be fine as without my additions to the patch it sets the label
[16:50] <klattimer> I'll have to work out what my bugs are
[16:50] <klattimer> ;/