[11:14] <dbarth_> klattimer: hi, hey man, the ibus indicator, it's an appindicator one you've done right?
[11:14] <klattimer> dbarth_: yeah
[11:15] <klattimer> dbarth_: please don't tell me that the patches have been unapplied during the build
[11:15] <klattimer> that was happening to me repeatedly when trying to build the package
[11:19] <klattimer> dbarth_: ?
[11:19] <dbarth_> klattimer: don't think so, no
[11:19] <dbarth_> klattimer: it was just to double check the nature of the indicator; mpt was not aware a new appindicator version of the ibus one was available
[11:19] <klattimer> yeah, that's what I fixed
[11:19] <klattimer> in theory
[11:20] <klattimer> I haven't been able to build the package though
[11:20] <klattimer> so many weird dpkg-buildpackage errors
[11:20] <klattimer> but the python code was replaced in the system and tested
[11:20] <klattimer> and the patch built from that
[11:20] <klattimer> so everything *should* be working well
[11:21] <dbarth_> cool
[11:21] <dbarth_> mpt: ^^ see, almost good news ;)
[11:21] <klattimer> dbarth_: I'm rebuilding the package now to test
[11:21] <klattimer> from upstream tarball and all seems to be working OK
[11:21] <klattimer> although GIR causes hell too
[11:27] <dbarth_> klattimer: did you get news from kenvandine yesterday on the build?
[11:27] <dbarth_> klattimer: seb128 was also asking
[11:31] <klattimer> yeah
[11:32] <klattimer> dbarth_: he left me a message in the channel and via email
[14:56] <sladen> klattimer: greetings, dbarth_ has pointed me in your direction about language icons
[14:56] <klattimer> sladen: hi
[14:56] <klattimer> sladen: well, the first part isn't about language icons
[14:56] <sladen> klattimer: although I suspect/fear that it's more a case of you teaching me first :)
[14:56] <klattimer> it's about language bar/proposed input
[14:56] <klattimer> can you install ibus from maverick proposed and configure it with a couple of input methods?
[14:57] <sladen> klattimer: I can... could you give me some high-level context first
[14:57] <klattimer> sladen: once you've got ibus up and running you should be able to select an input window and then start typing
[14:58] <klattimer> you notice that a) the "language bar" appears with some icons on it in the bottom right
[14:58] <klattimer> and b) with many input methods a "proposed input" window appears with some suggestions
[14:58] <sladen> klattimer: right, after clicking 4 x pointless dialogues, I get a keyboard in the gnome-panel
[14:58] <klattimer> heh
[14:58] <sladen> klattimer: English ispell
[14:59] <klattimer> sladen: english wont show up the proposed input
[14:59] <klattimer> pinyin is probably the best
[14:59] <klattimer> we need these two floating windows to have a "unity" look about them
[14:59] <sladen> klattimer: anyone, keep talking, so that I have an idea of the end goal
[14:59] <klattimer> so it matches the overall desktop
[15:00] <sladen> klattimer: so this is an issue with the full-screen one-app-at-a-time setup in Unity, and needing to have siultaneous floating input method windows
[15:01] <klattimer> sladen: well, it's not just about one app at a time
[15:02] <klattimer> effectively just a new visual style for those floating windows
[15:02] <sladen> klattimer: do I need to be running anything other than maverick-proposed/ibus-indicator ?
[15:02] <klattimer> me and njpatel will work out what we're going to do about positioning them
[15:02] <klattimer> I just want them to look prettier :)
[15:02] <klattimer> sladen: nope, the maverick proposed ibus is the only thing you'll need
[15:03] <klattimer> that should be released soon
[15:03] <klattimer> but the current release in the repos is very broken
[15:03] <klattimer> proposed actually works so you can see the windows I'm talking about
[15:07] <sladen> klattimer: it appears I can't on _this_ machine, which is on 10.04
[15:07] <klattimer> sladen: ah, you'll need 10.10
[15:07] <klattimer> :)
[15:08] <klattimer> update dude
[15:08] <sladen> klattimer: that's the other machine, which is not the one I'm using just now
[15:08] <klattimer> sladen: ok, cool
[15:08] <sladen> klattimer: so moving on, there is $some proposed window layout idea
[15:08] <klattimer> well I'm sure you know what to do when you're in front of it
[15:09] <klattimer> sladen: exactly the same layout
[15:09] <sladen> klattimer: which is what is trying to be demonstrated
[15:09] <klattimer> just more in tune with the general UI design
[15:09] <sladen> ...rather than a small floating box with a star in it?
[15:09] <klattimer> at the moment it's just gtk background colour and doesn't sit very well on the unity desktop for someething which will be mostly a permanent floating window for many users
[15:10] <klattimer> sladen: there'll be more icons than just the star once you're on maverick
[15:10] <sladen> klattimer: nod
[15:10] <klattimer> but still, yeah basically the existing look is pretty lame
[15:11] <sladen> klattimer: so what are you thinking, more of a iPhone press-and-hold-a-key popup?
[15:12] <sladen> klattimer: or something a kin to the semi-transparent notify-osd popups?
[15:12] <sladen> klattimer: (sorry, I know looking in person would give me the answer)
[15:13] <njpatel> klattimer, sladen (excuse the fact that I haven't every used ibus), does this popup window require/allow user input through the mouse?
[15:13] <njpatel> every*
[15:13] <njpatel> ever*
[15:13] <njpatel> wow
[15:14] <klattimer> sladen: more like notify osd style
[15:14] <klattimer> njpatel: yeah, both of them I believe require mouse input
[15:14] <klattimer> but maybe it's just the language bar
[15:14] <njpatel> cool, then it'll probably take the quicklist style
[15:14] <klattimer> the proposed input window is keyboard driven for the most part
[15:15] <klattimer> but I think it still supports mouse
[15:15] <klattimer> I should check
[15:15] <njpatel> notify-osd style is meant to signal "you can't touch this" (with a picture of mc hammer in your head)
[15:15] <klattimer> njpatel: I meant visual style
[15:15] <njpatel> whereas there is a specific overlay style
[15:15] <klattimer> the interaction as it stands is perfectly fine atm
[15:15] <njpatel> klattimer, so do I
[15:16] <njpatel> klattimer, we have a specific style for overlay windows that can accept input, is what I mean to say, sorry for the confusion. Notify-OSD styling is a overlay window that can't accept input
[15:16] <klattimer> njpatel: well, either way, I don't want the interaction changed at all, just the visual appearance of it
[15:16] <klattimer> so it's got a dark back ground, rounded corners and looks nice
[15:16] <njpatel> yeah, no change to interaction
[15:16] <njpatel> well, it'll have a dark background with dots and a bit of shine, rounded corner and will look lovely ;)
[15:18] <klattimer> njpatel: that's exactly what I was thinking :)
[15:18] <klattimer> just like the tooltips on the dock/launcher
[15:19] <njpatel> klattimer, the cairo code that gives the correct still will be in the unity plugin, so hopefully just be able to use that
[15:19] <njpatel> style*
[15:19] <njpatel> bloody hell I can't type today
[15:19] <klattimer> ah, excellent
[15:19] <klattimer> except...
[15:19] <klattimer> the windows will probably still need to be drawn with gtk
[15:19] <klattimer> ...
[15:19] <njpatel> sure, but just override the gtkwindows paint right?
[15:19] <klattimer> I can port the cairo cuteness to gtk without worries though
[15:19] <njpatel> yep
[15:19] <klattimer> njpatel: yeah
[15:20] <klattimer> sladen: the other thing is, we need all the existing m17n icons, and any other icons associated with the various ibus packages re-done to match the symbolic icons style
[15:22] <sladen> klattimer: njpatel: so is there a brand/style/guideline already defined for "floating windows that accept input"), or is this the first time it's come up and therefore it's the issue?
[15:23] <klattimer> sladen: I think this is pretty much the first time it's come up
[15:24] <njpatel> sladen, the quicklist windows are the first that use the style, I'm 95% that other overlay windows that accept input should use the same style, but there's no harm in making sure with chaotic
[15:24] <njpatel> sladen, to that end, the tooltips on the latest unity are styled like notify osd, as it was confusing because you can't actually click them until you right-click to get a quicklist
[15:27] <dbarth_> tedg: ping? hi Ted
[15:28] <dbarth_> checking your email about the orphan indicators
[15:28] <dbarth_> it's a good point, so i'm switching datetime and session to klattimer, to reflect the uds planning
[15:28] <dbarth_> https://blueprints.edge.launchpad.net/ubuntu/+spec/packageselection-dx-n-indicator-datetime
[15:29] <klattimer> dbarth_: nice to know
[15:30] <dbarth_> https://blueprints.edge.launchpad.net/ubuntu/+spec/other-dx-n-indicator-session
[15:30] <dbarth_> well, that's why i'm doing the switch here
[15:31] <klattimer> dbarth_: :)
[15:31] <dbarth_> klattimer: session is mostly bug fixes ataicr, while datetime is nicer piece with eds integration
[15:31] <tedg> Good morning dbarth_
[15:31] <dbarth_> tedg: good morning
[15:31] <tedg> Uhm, so what is happening to keyboard then?
[15:32] <dbarth_> keyboard is on hold
[15:32] <dbarth_> i chatted about it a bit with mpt this morning
[15:32] <klattimer> yeah we need a better idea from the users
[15:32] <tedg> So then what are we doing for Natty?  The AppIndicator ones still?
[15:32] <klattimer> tedg: yeah atm
[15:32] <tedg> I thought they had a few bugs... do those need to be fixed?
[15:32] <klattimer> ibus at least is working now
[15:33] <klattimer> with gsd layout indicator I think we just need to work on the icon situation
[15:33] <klattimer> not sure how to get flags into a theme package at the moment though
[15:33] <klattimer> we'll need to figure that out, but it should be easy
[15:33] <dbarth_> tedg: quickly, it's the result of the uds session; the designs (mpt's, klattimer's and even mccan) where not matching the expectations of the people we had in the room
[15:34] <mpt> Fixing the title icons can be done regardless of the rest of the design, though
[15:34] <dbarth_> we had people from different regions of the world, and the main use cases they helped us understand were, well different
[15:34] <dbarth_> mpt yes, there are a couple of elements that can be fixed, and can be targetted for natty
[15:34] <tedg> So are we going to mail mpt to China for a few weeks?  :)
[15:35] <dbarth_> atm i see that more as a set of bug fixes, ie the workload is not at the same level as a merge/rewrite like was envisionned initially
[15:36] <dbarth_> tedg: you're kidding, but I feel we learned a lot during this session; at least i did
[15:36] <dbarth_> ;)
[15:36] <dbarth_> so ok, those 2 indicators are on the map now
[15:37] <tedg> Yeah, I'm just concerned that we don't have a plan to solve it eventually.  If it needs to be redesign, sure, makes sense.  But we need a plan to get the expertise so that it can be redesigned.
[15:37] <dbarth_> tedg: the other thing i'm worried about is the appmenu-gtk / libappindicator code merge
[15:37] <tedg> For the most part, assuming mpt is going home for Christmas, it's on his way ;)
[15:37] <dbarth_> since bratsche won't be available much to do it; something i had also in mind for karl
[15:38] <klattimer> dbarth_: its already on my list of things I've been asked to work on
[15:38] <dbarth_> but it's a major chunk and something i'd prefer you guys to talk about a bit more before we commit to doing it
[15:38] <dbarth_> klattimer: ah, that was already in the air
[15:38] <dbarth_> oh yes, mt was already around when we made that list
[15:38] <tedg> It honestly should be "cut-and-paste" coding-wise.  But then it's just test, test, test, test :)
[15:38] <dbarth_> test is the keyword
[15:39] <klattimer> tedg: that was what I was thinking too
[15:39] <dbarth_> and we know from maverick that tesdt is not easy here
[15:39] <klattimer> so I'll poke session bugs for the next few days, then move onto the merge after?
[15:39] <dbarth_> klattimer: session bugs i think can wait a bit
[15:39] <tedg> klattimer, It'd be good to start looking at datetime as well, that's a reasonably large development task.
[15:40] <klattimer> k
[15:40] <tedg> klattimer, Make sure that you're comfortable with the design.
[15:40] <klattimer> so guys, which one first?
[15:40] <dbarth_> you also have that im-context thing at the moment on your plate
[15:40] <klattimer> dbarth_: true
[15:40] <mpt> tedg! You're awake!
[15:40] <dbarth_> so i'd suggest not taking too much at the same time
[15:40] <dbarth_> well, maybe another small feature or list of bugs; and im-context (the bigger dev. task)
[15:40] <tedg> klattimer, The one thing that I haven't figured out is how to make the backends "plugable" in that it'd be nice if we provided an easy way for Akanadi support.  It may just have to be an #ifdef thing :-/
[15:40] <klattimer> dbarth_: getting the indicator code merged will let app developers fix their indicators
[15:40] <dbarth_> once the im thing is under control, you can take another big one; that'd be my recommendation
[15:40] <klattimer> as signalling click is a major issue for them
[15:41] <tedg> klattimer, Yeah, that's not as much merging the GTK parsing code.
[15:41] <mpt> tedg, there are a few blueprints assigned to you that aren't approved or accepted, and I don't know who is supposed to do those things.
[15:41] <dbarth_> unless you get back on fire like the other day ;) in which case, i'll throw a couple more blueprints
[15:41] <tedg> mpt, Well, the only ones I'm assigned are the dbusmenu ones and indicator-messages.
[15:41] <njpatel> dbarth_, can we drop mutter im context? and concentrate on natty?
[15:42] <klattimer> dbarth_: the other day was the end of a long drawn out fist fight with ibus, eventually he got tired and I managed to land a KO
[15:42] <tedg> klattimer, But, yes, we need that and another couple appindicator features as well.  I'm trying to prioritize those as early as possible, but I dont' think most appindicator developers are using dev releases...
[15:42] <dbarth_> njpatel: yeah, i think it's not a high prio; the only reason i was considering it was as a way to clear the ground and see what to do for natty
[15:42] <klattimer> unless I face an opponent as well trained at messing my day up as ibus
[15:42] <klattimer> it's mostly just getting it done
[15:42] <dbarth_> klattimer: ;)
[15:43] <njpatel> dbarth_, i think they will differ enough that we could get away with just working on natty (i.e. writing the module loaders or just using gtk-im, if possible)
[15:43] <njpatel> klattimer, heh
[15:43] <dbarth_> right, let's try to conclude tomorrow on that
[15:43] <dbarth_> but i guess you're right
[15:43] <mpt> tedg, you're also assigned to <https://blueprints.launchpad.net/ubuntu/+spec/packageselection-dx-n-indicator-application> and <https://blueprints.launchpad.net/ubuntu/+spec/packageselection-dx-n-indicator-datetime>.
[15:43] <dbarth_> mpt: datetime, not anymore
[15:44] <dbarth_> mpt: karl just got offered it
[15:44] <tedg> mpt, yes, datetime will be klattimer.  I imagine application will end up a group effort.
[15:44] <mpt> ok
[15:44] <tedg> mpt, klattimer is doing the appmenu-gtk integration. for instance.
[15:44] <tedg> mpt, And I believe that kamstrup is doing the GDBus port, etc.
[15:46] <seb128> tedg, what application?
[15:46] <klattimer> seb128: indicator-application blue print
[15:47] <dbarth_> tedg: not sure for the gdbus port though
[15:47] <seb128> ok
[15:48] <mpt> still shows tedg as Drafter and Assignee
[15:49] <tedg> mpt, We just decided like 20min ago -- give us some time :)
[15:57] <dbarth_> mpt: oh really
[15:57] <dbarth_> which one? datetime?
[16:01] <dbarth_> application menu however is not updated, right
[16:02] <mpt> dbarth_, https://blueprints.launchpad.net/ubuntu/+spec/packageselection-dx-n-indicator-application
[16:18] <tedg> kenvandine, Seems that I can't create a new Facebook account with the new Gwibber.  Gets to a page saying "SUCCESS" but doesn't do anything after that.
[16:21] <kklimonda> tedg: could you take a look at bug 673302 ?
[16:21] <kenvandine> tedg, that is the facebook allocation problem
[16:22] <kenvandine> tedg, i promise i will make that work better when that fails... soon
[16:22] <kklimonda> tedg: can I for example disable appmenu integration for emacs?
[16:23] <tedg> kenvandine, Ah, okay, even with the latest?
[16:23] <kenvandine> yes
[16:23] <kenvandine> tedg, until more people get the update in lucid and maverick
[16:23] <tedg> kklimonda, Yeah, you just can do UBUNTU_MENU_PROXY= emacs
[16:23] <kenvandine> :/
[16:24] <tedg> kenvandine, Can I have your magic API key that works ;)
[16:24] <kenvandine> their are versions in -proposed for lucid and maverick now that fixes it... :)
[16:24] <kenvandine> hehe
[16:24] <kenvandine> tedg, i would rather you suffer until you rename indicator-*
[16:24] <kenvandine> my personal vengeance
[16:24] <kenvandine> :-D
[16:25] <tedg> This is the funny thing.  Half the people complain when you name things explanatory names -- the other half complain when you name things fun names.
[16:25] <tedg> Hmm, Kaleo isn't in this channel.  You two should have a death match.
[16:26] <kenvandine> i am fine with the names now... but i do still get confused sometimes
[16:26] <kenvandine> it's just too many packages with similar names
[16:26] <kenvandine> like i would prefer me-indicator, messages-indicator, etc
[16:26] <kenvandine> still descriptive :)
[16:27] <tedg> Shouldn't it be broadest category to more specific?  Eh?  Like com.ubuntu.indicator.messages ?