=== jono is now known as Guest45463 === agateau_ is now known as agateau === jibel_ is now known as jibel === DrPepperKid is now known as MacSlow|lunch === om26er_ is now known as om26er === MacSlow|lunch is now known as MacSlow [15:49] mhall119: hey, are you around? [15:50] davidcalle: if you want I can look at the scope packaging as I've packaged the other lenses [15:52] Hey didrocks. Thank you. I'd like to because I'm not sure of the quality of the packaged ones. [15:53] they are all python, aren't they? [15:54] yes [15:55] Could you have a look at this one, for example? https://code.launchpad.net/~davidc3/onehundredscopes/dribbble It's packaged, it works, but I'd like to have your insight on the packaging. [15:55] looking :) [15:55] didrocks: I am [15:55] didrocks, ty :) [15:56] didrocks: do you know how scopes are identified as add-ons for a lens in USC? [15:57] mhall119: are they? right now, you just have lenses which are shown as plugin, do we have scopes already? [15:57] davidcalle: so, some comments: [15:58] davidcalle: debian/control: why all those build-deps? seems you just need debhelper and python, isn't it? [15:58] (even not python-all) [15:58] davidcalle: also, if you wait autodetection of build-deps, you need to add gir1.2-unity-4.0, and gir1.2-dee-0.5, as well as python-lxml [15:59] davidcalle: then, in debian/rules, replace: dh $@ by dh $@ --with python2 [15:59] and normally ${python:Depends} will be expanded with the right depends [15:59] didrocks, ok. ( The original packaging is kenvandine's one, for the AskUbuntu lens. I've mostly copied and pasted. ) [16:00] davidcalle: no worry ;) [16:00] didrocks: I was told they were... [16:00] also, the short description shouldn't be the same than the long one [16:00] didrocks: either way, who should I talk to about how they are/should be? [16:00] mhall119: mpt on #software-center [16:00] didrocks, I blame my lack of inspiration for this one ;) [16:00] thanks [16:01] mhall119: also, mention the scope to him, I think he just think about lens for the new category [16:01] will do [16:01] davidcalle: heh, it just has to be fixed when we start to push them to precise [16:01] davidcalle: last thing, on the copyright file [16:01] davidcalle: we try to move to a parsable format [16:02] davidcalle: you can find the spec here: http://dep.debian.net/deps/dep5/ [16:02] didrocks, mhall119 in the updated specs : lenses are in the Dash search plugins sub-category, scopes are not displayed but are listed as suggested plug-ins in the package view. [16:02] mhall119, https://wiki.ubuntu.com/SoftwareCenter#lenses [16:03] and about the scope detection? It should be detected as a plug in of the right lens [16:03] mpt: davidcalle: right, it says they are listed as add-ons, but doesn't specify how USC knows that what lens they are an add-on for [16:04] didrocks, thanks, looking at it. [16:04] davidcalle: apart from that, it looks good :) [16:05] didrocks, great :) On my way to fix packaged lenses and scopes. [16:05] davidcalle: excellent, keep me in touch if you need anything :) [16:06] I will. [16:06] didrocks: I've been browsing the quickly packaging code, and wow it does a lot of maintenance [16:06] mhall119: so, I looked at singlet on my side, and yeah, this can be definitively be integrated [16:06] didrocks: cool, in what way were you thinking? [16:06] also, having some commands like "create" "package", "release" [16:07] mhall119: yeah, I have some questions though, you are installing the actual code lens in /usr/lib/singlet, isn't it? [16:07] lens code* [16:07] didrocks: that's the default, yes [16:07] only because I copied from davidcalle's code which installed them to /usr/lib/ohscopes/ [16:07] that's not very LSB :) [16:07] where would be a better location? [16:07] davidcalle: you are doing that? :) [16:08] yeah, it depends what this code is [16:08] are there common code between all lenses/scopes? [16:08] didrocks: his instructions did, not sure about his packages [16:08] didrocks: not yet, other than dbus and gir [16:08] singlet may become a common foundation for python lenses/scopes [16:08] didrocks, I've followed what's done with default lenses, the daemon is in : /usr/lib/unity-lens* [16:08] ok, so it should be in /usr/share/lens_name then [16:08] didrocks, ok [16:08] davidcalle: indeed, but they are not python! :) [16:09] that's interesting thinking about it [16:09] as it's a service [16:09] but not a library service [16:09] I need to think about it :) [16:09] didrocks: executables in /usr/share? [16:09] mhall119: sure, we have a lot of them :) [16:10] sotware-center, oneconf… :p [16:10] ok [16:10] can they live in /usr/share/unity/lenses/ with the .lens files? [16:10] but as a service, I need to think about it [16:10] hum, I'm not fan of making this directory crowded [16:10] one sec, looking at something [16:10] bbiab [16:10] they'd each have their own subdirectory [16:11] /usr/share/unity/lenses/dictionary/(dictionary.lens, dictionary.svg, dictionary-lens) [16:11] mhall119, what about scopes? [16:11] right now the .lens and .svg already go there [16:11] davidcalle: good question, they currently go in the lens' directory in /usr/share/unity/lenses/ right? [16:12] make we should use /usr/share/unity/lenses//scopes// ? [16:13] didrocks: mpt: ^^ thoughts? [16:13] mhall119, I'd like that. But maybe we shouldn't complicate Unity's parsing of these folders. [16:13] mhall119: can you make a tree (in a pastebin) of what is produced by singlet? [16:13] would it complicate things? [16:13] there is not just one file, isn't it? [16:14] didrocks: there are 2, a unity .lens file, and a dbus .service file [16:14] the source code file also acts as the daemon executable [16:14] hum, so the helpers you wrote aren't necessary? [16:14] (as you created some subfolders) [16:14] which helpers are you talking about? [16:15] the 'make' and 'install' commands? [16:15] what's in http://bazaar.launchpad.net/~singlet-developers/singlet/trunk/files/head:/src/singlet/ [16:16] the ./lens/ folder has the base class and metaclass for a Lens object [16:16] yeah, and that's what can't go into /usr/lib :) [16:16] the ./scope/ folder doesn't have anything useful yet, that's what I plan on adding next [16:16] yeah, singlet will be a separate package, installed to wherever python libs go [16:17] ok, like quickly-widget in some way [16:17] /usr/share/pyshared or /usr/lib/python2.?/dist-packages [16:17] indeed [16:17] I guess (not familiar with quickly much) [16:17] (well, symlinked in fact) [16:17] ok, we are on the same page then :) [16:17] and the daemon alone can go in /usr/lib/ then [16:18] ok [16:18] davidcalle: 16:16 < kiwinote> mhall119: didrocks: I think the cleanest way to make an addon show up in s-c is for the scope to list the lens in the 'Enhances' field [16:19] in debian/control [16:19] so yeah, adds the field to the scope package ^ [16:19] mhall119, excellent [16:19] mhall119: ok, so I'll look closely to singlet and try to integrate it as a quickly template if you don't mind [16:20] didrocks: won't mind at all, I can provide a code file template too if you need me to [16:20] mhall119: that would be awesome! look at the ubuntu-application template (there are some string that we autoreplace) [16:20] or the ubuntu-cli one! [16:20] (in the data/ directory) [16:21] mhall119: I can't commit doing it next week as we have our platform rally in budapest, but the week after, we can do that together quite "quickly" ;) [16:21] didrocks: sure thing, I'll send you something later today [16:21] didrocks: ok [16:21] excellent! :-) [16:21] so, basically: [16:22] singlet factored as a common library between scope/lenses [16:22] (will be installed as a python library in /usr/share/pyshared) [16:22] yup, serving as an abstraction layer for DBus GObject [16:22] the code template moving apart, as a quickly template [16:22] (which will dep on singlet) [16:23] and install the .lens, .service files [16:23] sounds quite achievable :) [16:25] cool [16:38] didrocks: with singlet, there are going to be several choices of base Lens class to use, depending on what you want, how would that work with a quickly template? [16:38] mhall119: hum, can you expand your idea a little bit ? [16:39] with examples :) [16:39] didrocks: so right now I have Lens, which is pretty basic, and SingleScopeLens which has only one scope that is defined within the lens code itself [16:40] in the future there will be others [16:40] what the difference between Lens and SingleScopeLens, Lens can accept multiple scopes? [16:40] mhall119: for me that can be different template [16:40] yes, and by default it has none, and isn't connected to DBus events to handle searches or handle URIs [16:40] as they can share all the packaging code (well "inherit") rather [16:40] ok [16:41] I think SingleScopeLens will be the most used [16:42] probably [16:42] a hidden (no icon in dash) lens base will probably also be used [16:42] hum, that's just a parameter [16:43] we can use quickly for that [16:43] there is quickly configure [16:43] and we can tell "no icon please" [16:43] does quickly configure change the code? [16:43] it can do what we need [16:43] I can probably add a hidden=True to the Len's Meta innerclass [16:43] yeah, that was my pick :) [16:44] let's try to not create 1 billion templates when changes are minor :) [16:44] ok === jono_ is now known as jono === yofel_ is now known as yofel [18:47] hi, does a scope depend on the lens that it is for? [18:49] kiwinote: ^^ can you clarify for james? [18:49] he's curious about dependencies being disallowed by policy in the extras repo [18:51] from my understanding of our prior conversation, Depends isn't strictly necessary, only Enhances [18:51] but also that a scope depending on a lens will be allowed as an exception to the policy [18:53] mpt: ^^ [19:19] mhall119: to show up as an addon in software-center you only need the scope to list the lens in the enhances field [19:20] oh, never heard of the enhances field [19:20] mhall119: whether you want a dependency too is a more general packagin question which I can't really help you with as I don't know much about lenses and scopes and their interactions [19:20] nice :) [20:06] james_w: ^^ make sense to you? [20:35] mhall119, I guess [20:36] it's still not clear whether scopes are supposed to depend on the lenses, or whether that's just up to each scope [21:14] james_w: scopes don't *need* to depend on a lens. A scope *may* depend on a lens if the developers wants to, and we have an exception to the extras policy to allow that [21:14] where's that exception documented? [21:15] mhall119, ^ [21:15] james_w: I've just heard it, I'm not sure if it's been documented somewhere yet, or even where it would be [21:15] ok [21:19] jcastro: do you know where the official extras acceptance policy is documented? [21:40] no clue [21:41] https://wiki.ubuntu.com/ExtensionRepositoryPolicy [21:41] maybe? [21:49] hi mhall119 [21:49] I guess I could have just checked, huh AlanBell ? [21:49] I have put together a little lens that connects to an OpenERP server and searches for stuff [21:49] I think a desktop-wide credentials store would be ideal [21:50] nice little thing, very fast, but I need a way for the user to be able to specify the URL to their server and put in their password [21:50] I also want to do a lens that searches the vTiger CRM system, and various other internal business systems that will require a username and password [21:51] I can see it doing an RT issue tracker lens or a bugzilla lens or whatever [21:52] lots of useful lenses that need a bit of config and authentication and I don't know the right way to present that to the user [21:54] james_w: are you writing a lens? [21:54] statik: how did your singlet testing go? [21:55] mhall119: really good! [21:55] i got a working lens [21:57] statik: awesome, can I get a short description, screenshot and link to the code? I'm working on a blog post [21:57] statik: btw, we're going to use singlet to make a Quickly template for lens creating and packaging [21:58] mhall119: no, it was a lens for accessing some internal systems. i'd like to do a launchpad one inspired by pad.lv, and when I get that working I'll definitely share it with you. [21:58] mhall119, no, we have a query from a developer who wants to submit a scope + lens to software-center, and thinks they can't because of the policy [21:58] statik: ok [21:59] statik: btw, I think doctormon was going to be working on a launchpad lens too, you might want to see if he's gotten started yet [21:59] james_w: ok [22:00] james_w: can you tell me who the developer is, so I can see about featuring his lens too? [22:02] mhall119, I don't know who it is at this point [22:02] I can let you know when it is submitted though [22:53] thanks james_w [23:01] we need a new message-indicator like container for things like tasks/notes/snippets [23:02] jcastro: ^^ who should I talk to about that? [23:03] between tomboy, gtg and glipper, I have at least 2 more indicator icons than is necessary