=== chiluk is now known as chiluk_away === chiluk_away is now known as chiluk === chiluk is now known as chiluk_away === statik_ is now known as statik === chiluk_away is now known as chiluk === chiluk is now known as chiluk_away === Ursinha is now known as Ursinha-afk === fabo_ is now known as fabo === Tonio__ is now known as Tonio_aw === doko_ is now known as doko === Pricey_ is now known as Pricey === Tonio_aw is now known as Tonio__ === Tonio__ is now known as Tonio_aw === Tonio_aw is now known as Tonio__ === Tonio__ is now known as Tonio_aw === Ursinha-afk is now known as Ursinha === yofel_ is now known as yofel === Quintasan_ is now known as Quintasan === Tonio_aw is now known as Tonio__ === Tonio__ is now known as Tonio_aw === Tonio_aw is now known as Tonio__ === chiluk_away is now known as chiluk === bdrung_ is now known as bdrung === rrnwexec is now known as rrnwexec_ === chiluk is now known as chiluk_away === rrnwexec_ is now known as rrnwexec === chiluk_away is now known as chiluk === Tonio__ is now known as Tonio_aw === Tonio_aw is now known as Tonio__ === Tonio__ is now known as Tonio_aw === Tonio_aw is now known as Tonio__ [18:00] o/ === chiluk is now known as chiluk_away === chiluk_away is now known as chiluk === chiluk is now known as chiluk_away === chiluk_away is now known as chiluk [19:00] #startmeeting [19:00] Meeting started Thu Dec 13 19:00:23 2012 UTC. The chair is jono. Information about MeetBot at http://wiki.ubuntu.com/meetingology. [19:00] Available commands: #accept #accepted #action #agree #agreed #chair #commands #endmeeting #endvote #halp #help #idea #info #link #lurk #meetingname #meetingtopic #nick #progress #rejected #replay #restrictlogs #save #startmeeting #subtopic #topic #unchair #undo #unlurk #vote #voters #votesrequired [19:00] hey everyone, and welcome to the Ubuntu Accomplishments meeting! [19:00] who is here for the meeting? [19:00] o/ [19:00] o/ [19:00] \o [19:00] o/ [19:01] \o/ [19:01] :-) [19:01] mhall119, are you here too? [19:01] so unfortunately I have to leave in 30m for a call, but I have a few agenda topics to raise [19:01] is it OK if I raise these first? [19:01] sure [19:01] awesome :-) [19:02] so the first is regarding the server deployment [19:02] so mhall119 has been taking care of getting the validation, admin, and web gallery deployment instructions in place [19:02] one thing we need to decide on is how we push changes to IS for deployment [19:02] typically they prefer to simply pull a branch for a deployment [19:02] as such, I wanted to propose the following: [19:03] - we will have the staging and production servers set up [19:03] - staging pulls from trunk for each of the server-related projects [19:03] will we have a separate project for the admin dashboard? [19:03] - when we cut a new release of a project, trunk is branched to a version number (as we do with the -daemon and -viewer projects), and that version is pushed to production [19:04] cielak, right now the admin is just a branch, but I will set up a project [19:04] jono: I'm here [19:04] okay [19:04] does that workflow sound OK to you folks? [19:04] seems fine to me [19:04] this way we can then just file an RT with a branch pull for an update [19:04] sounds like a good idea to me [19:04] mhall119, do you think IS will be happy with that? [19:04] jono: why would staging pull from trunk? [19:05] mhall119, as that is where we develop the projects [19:05] the idea being that you only push to trunk when your code works :-) [19:05] so trunk is sacred [19:05] so this is feature staging, not deployment staging [19:05] so the projects that are going to have their 'production' branches are the validation server, the dashboard and comunity-accomplishments? [19:05] mhall119, right [19:05] ok [19:05] cielak, right, so the only weird one is UCA [19:06] we can have production branches for validation, admin, and gallery [19:06] actually I guess we can just do the same for UCA [19:06] my thinking here though is that the server won't pull UCA from trunk and instead pull it from the releases PPA [19:06] as the accoms live in /usr/share [19:07] the production one? or the staging one? [19:07] cielak, for production [19:07] right [19:07] this is fine with me [19:07] cool [19:07] mhall119, sound OK with you? [19:08] jono: yeah, we'd want to pull from something close to what users are using [19:08] so PPA instead of trunk [19:08] sounds good [19:08] yep [19:08] OK, I will document this on a wiki page [19:08] and then we can point IS at it [19:09] to ensure it is what they expect [19:09] so the other topic I wanted to discuss was getting ready for the release in 13.04 [19:09] last night I was chatting to Janos about the gallery [19:09] unfortunately he can't be in this meeting [19:10] he has created a milestone and suggested we file bugs against the milestone that we need fixing in preparation for the release [19:10] I wanted to suggest we do the same across our different projects [19:10] I know we have many of these bugs already [19:10] cielak, how are things looking with the daemon/viewer in terms of quality? [19:11] we have not messed up anything, but new features that were added have not yet been thoroughly tested [19:11] cielak, so I think we are going to want to put in place a more rigerous testing plan for this next release [19:11] as for the daemon and the viewer, I tend to assign bugs to 0.4 milestones [19:11] sounds good [19:11] did we decide on a 0.4 release date? [19:11] I seem to remeber feb [19:11] 15 feb [19:12] cool [19:12] this makes sense [19:12] so I think if we can shoot to have the server deployed by then and release 0.4 [19:12] and then why don't we focus on getting our accoms and any other bug fixed after that [19:12] so the release after 0.4 will be 1.0 [19:12] and will be the release in 13.04 [19:12] make sense? [19:13] so you mean we do not care much about bug fixing for 0.4, but for 1.0 instead?? [19:13] my thinking is that 0.4 is all about bug fixing [19:13] I personally think we should lock down features [19:13] but to focus on the server, daemon and viewer mainly for 0.4 [19:13] and then we focus on UCA for 1.0 and any other bugs [19:14] okay, let it be this way [19:14] cielak, is that OK with you? [19:14] there are two more major features I'd like to implement in 0.4 [19:14] oh? [19:14] so just wanted to ensure I understand the plan well ;) [19:14] :-) [19:15] which features, cielak? [19:15] first is getting the daemon to run scripts in paralell [19:15] this will improve the performance, as most of time scripts are just waiting for servers to respond [19:16] this is kind of experimental, I will investigate how that changes resource usage and execution time [19:16] cielak, sounds cool [19:16] and the other thing is support for custom validation servers for third-party collection [19:16] cielak, right [19:16] just to make our platform fully expandable [19:17] yup [19:17] cielak, are you going to work on both of those features? [19:17] I should have some more time to work on that during the winter break, and I am really excited to work on them, but if anyone wants, help is very welcome ;) [19:17] plus there is the thing of making the daemon a DBus service [19:18] cielak, right [19:18] cielak, would you mind emailing didrocks and discussing the dbus work there? [19:18] I know you have not had as much IRC time [19:19] I am hoping the dbus thing won't be a blocker for inclusion in the USC [19:19] I will, but first I will reproduce all the problems, to clarify what I had troubles with [19:19] sounds great [19:19] thanks, cielak :-) [19:20] just being busy recently, but that should change soon [19:20] ok, I will take some time later to put together a release schedule with these dates [19:20] cielak, awesome [19:20] we are not far off our 1.0 goal :-) [19:20] this is going to be *awesome* [19:20] :-) [19:20] it will be super cool to see people's trophies on the web [19:20] and shared on Twitter :-) [19:20] indeed! [19:21] ok, those were my agenda items [19:21] any other topics? [19:21] i have none. [19:22] I have one [19:22] a lot of things I don't understand but this is great :) .... cielak should I still focus on 10.04 or new versions of Ubuntu so I can catch up with you guys easier? [19:22] JasnaBencic: we never really supporter 10.04 [19:22] JasnaBencic, , 12.04 is our minimum version [19:22] cielak, what topic? [19:22] I expect you may be successful running Accomplishments on 10.04, but we can't guarantee that [19:23] I wanted to ask if anyone has recently followed the Accomplishments Writing Guide [19:23] I don't remember us updating it frequently [19:23] so it might be wise to check if it's not outdated [19:23] Sorry late, is meeting still happening? [19:23] doctormon: yes! :) [19:24] cielak, I haven't checked into it recently [19:24] this is something we should check into, particularly after 0.4 [19:24] doctormon, still going :-) [19:24] Zilvador, did you follow the guide? [19:24] although I have to run in a few mins [19:25] so this is a thing that certainly should land on our todo list [19:25] I'm here to tend to the code submitted for gtk-shelves; message to jono might have been lost in the pipes. [19:26] s-fox, I did. And I am planning to go through it soon to update it. [19:26] ^ cielak :) [19:26] doctormon: I would be interested in examining your code [19:26] doctormon, did you file a MP? [19:26] Zilvador: awesome! you are very welcome to improve it :) [19:26] ok, sorry folks, I need to run to this call [19:26] :) [19:26] thanks for joining everyone! [19:27] feel free to keep discussing [19:27] thanks jono! see you :) [19:27] jono: No, because it's not production code. [19:27] just end the meeting when you need to [19:27] doctormon, ok [19:27] doctormon: you did a simple proof-of-concept GTK app, right? [19:27] thank you jono [19:27] cielak: lp:~doctormo/junk/gtk-shelves [19:27] doctormon, have a screenshot? [19:28] Took a while to root through all the gtk bolocks though. The gtk devs were unhappy about it, *shrug* but it works. [19:28] jono: You've seen the screenshot already, the difference is now you can scroll. [19:28] (without it messing up) [19:28] doctormon, can you link us again? [19:28] doctormon: have you tested it on various GTK themes? I had one way of doing it that worked on some, but not others [19:29] doctormon: testing out, this looks fine, but I wonder what would happen if the items would have variable height [19:29] cielak: Bad things [19:30] mhall119: Yes, this works by painting, not styles. [19:30] jono: Image is gone on imagebin, cielak can you generate a screenshot for jono? [19:30] oops, the accomplishments viewer has items of different heights... is there a chance your trick could be applied in such case too? [19:31] cielak: No, you'd have to find the height of the row and change the image accordingly. That's a lot of code. [19:31] doctormon: cool [19:31] Recommend you change the viewer habbit. [19:31] (actually what I have is control over the icon display, it paints them all as a fixed size anyway) [19:32] doctormon: the point is that the different height is not because icon size, but because the accompishment title varies, and long titles (or long translations) result in higher rows [19:32] I took the titles out, too much trouble. [19:32] cielak: sorry I had another meeting [19:33] * davidcalle has just arrived [19:33] yeah, but there is no way we could not display the title in the viewer [19:33] hello davidcalle :) [19:33] * davidcalle waves :) [19:33] But it is possible to calculate the pango paint size of the text and consider that in the painting. But we're talking about a very different order of magnatude on the code there. [19:33] there is a screenshot of doctormon's experimental branch: http://i.imgur.com/f6fAY.png [19:34] For instance, repeating each row is done by the context, we'd have to manually do all that. [19:34] doctormon: yes, I expect so [19:34] this would also significantly affect performance [19:35] Probably. There are ways to show the title though. have a fixed number of letters and use an elipse. Do a hover over screen with title and other info. [19:35] * janos_ these icons in the shot are not so good... simpler would be better [19:36] Useful once we get the icon-level and branding destinctions in there. Maybe the trophies will each be unique enough. [19:36] a hover would make browsing difficult [19:36] cielak: It's not for browsing, it's for admiring. Browsing is when you want to view the achievements you don't have yet. No? [19:36] is the UI searchable with ctrl-F or something? [19:36] a fixed number of letters is't a perfect solution too, though, look at how varied the titles are [19:36] i think titles are important [19:37] janos_: the trunk/dailies contain already a search feature [19:37] doctormon: so that would make sense only once we have tons of easily distinguishable icons for trophies [19:38] cielak: thanks i just meant that to highlight the importance of titles (searchability) [19:38] We could afix the position and give each more space, 3 lines height each. [19:38] but i do see doctormon's point about admiration [19:38] can a one-line title be vertical aligned in the middle? [19:39] a fixed 3 lines height seems like a kind of a good solution [19:39] janos_: It would be if we painted it ;-) [19:39] yeah, if painted manually, we can do everything [19:39] using a custom, not theme-dependent font+size would be significant [19:40] So, we don't use the listview as just a painting canvas. We hijack the icon's own paint mechanism to do that side of things. [19:40] So it's basically 3 hijacks of different widget/parts. [19:40] but drawing the text manually has one disadvantage - the more we move away from standard GTK, the more accesibility features we may loose [19:41] cielak: In this case not, we're not painting the text onto the iconview widget. [19:41] but onto it's embeded label? [19:41] cielak: But the item's own internal draw method. The text is still in the item's data store, the item still has a bounding box. It's all good. [19:41] aah [19:41] that's fine indeed [19:42] Now don't ask me about drag and drop :-P [19:42] It might work ;-) [19:42] it should... I guess, but we never supported it anyway [19:42] I don't see any use of dragging the trophies, neither within nor outsite the window [19:43] doctormon: and I expect this would not interfere with GtkTreeModelFilters we use? [19:43] silly me, of course it wouldn't [19:45] :-) [19:45] my opinion is that it would be worth to work on that in a viewer's branch [19:46] I've tried hacking on the viewers code, but it's deps are far too high for devel [19:46] what do you mean? [19:46] (I can't get it to run without a server, dbus and all that other guff running) [19:46] doctormon: you will need dbus and the accomplishments-daemon [19:47] server shouldn't be needed, though [19:47] Exactly why do I need the daemon for to test a viewer? Is there no test daemon with pre-set data? [19:47] the viewer is just the frontend for the daemon [19:48] it does not know at all how accomplishments work, how to process their files etc [19:48] it asks the daemon to do whatever is needed [19:48] a good thing about that is that it keeps the viewer much less complicated for you to hack [19:48] but there is no way you could run it without the daemon [19:49] anyway, awesome work with the branch :) It would be great if you could reproduce these effects in the viewer, but if not I guess I could work on that, your code seems clear to me [19:50] in case of problems with getting the daemon to run you are welcome in #ubuntu-accomplishments [19:50] * gepatino waves. sorry I'm late [19:50] hi gepatino, good to see you :) [19:51] okay, there are 10 more minutes time left, so if anyone wants to discuss anything else, please go ahead! [19:52] is there something to talk about the web gallery? [19:52] janos_: ^ [19:53] thanks guys! [19:53] the only problem I had deploying the gallery was that the samples/users.json is out of date [19:53] and wasn't setting the share id/folder properly [19:53] probably made for an older version of the data model [19:56] cielak, do you have a screenshot of doctormon's branch? [19:56] jono: http://i.imgur.com/f6fAY.png [19:56] cielak, cool [19:57] would be cool if the trophies could have a little shadow too [19:57] I think this is to be done in the accomplishment icon [19:57] cielak, so is he going to work on a production branch? [19:58] yes, it seems so [19:58] cool [19:58] we should change all the trophies to ponies [19:59] mhall119: +1 for a new ponies-related accomplishments collection [20:00] right, we're running out of time and it seems there is nothing more to discuss [20:00] thanks everyone for joining us! [20:02] mhall119, could you send a mail with this info to the list? I'll try to take a look at it [20:03] I mean the issue with the samples/users.json file, not the ponies icons :) [20:05] * janos_ reading up [20:07] meeting done? cielak you'll get a lot of questions from me via mail :) I'm very happy that I came here despite I didn't understand a lot :) [20:08] JasnaBencic: sure. you are also welcome to ask us all via the mailing list we use [20:08] ok [20:09] mhall119: oh the samples/users.json was just for an initial proof of concept demo [20:11] mhall119, gepatino: yup, samples/users.json is just for developers, should not be in prod. I will update the readme [20:11] ok [20:12] oh i see the meeting is over :) heading over to the other channel then, bye all [20:17] ok === Tonio__ is now known as Tonio_aw === toddyhb is now known as toddy === ev_ is now known as ev === Seveas is now known as Guest65145 === micahg_ is now known as micahg === jussi01 is now known as jussi === chiluk is now known as chiluk_away === fader_` is now known as fader_ === Tonio_aw is now known as Tonio__ === Tonio__ is now known as Tonio_ === Tonio_ is now known as Tonio_aw === Tonio_aw is now known as Tonio_ === Tonio_ is now known as Tonio_aw