[00:00] i think we can justify to not let koffice stuff in the gnome template folder [00:00] but I can see that quickly turning into a mess [00:00] and to be honest I've a clean menu there I'm using [00:00] right. but we can focus on most common use-cases to unbreak the situation [00:00] and push back the other cases until there is a real solutino [00:00] and I would be able to be able to keep it this way without having to use dpkg-divert [00:01] ie I don't use openoffice and I don't want my menu cluttered with 6 office templates [00:01] I guess I would be happy if we have an easy way to opt out of things [00:02] i wouldnt allow all openoffice apps to install templats i guess ... just odt document, and maybe a spreadsheet and a presentation [00:02] so maybe not install templates with packages but have a default ubuntu-templates [00:02] yeah ... but opting out without editor is hard [00:02] I would remove ubuntu-templates and be fine with it [00:02] seb128: we could require packages to ship templates in a -templates package which is a recommends [00:02] abiword-nautilus-templates [00:02] I don't really like adding extra binaries though [00:03] or we must make the template mechanism sensible on whether the binary referred to exist [00:03] the apt index takes long enough to download and that clutter the package management tools [00:03] well. === asac_ is now known as asac [00:03] i think the apt index can be ignored. that will be like 10 packages in karmic at max and then maybe 10 more later [00:03] anyway ;) [00:04] needs some thinking and brain-baking [00:04] I would be in favor of an ubuntu-templates for now [00:04] which would be part of the default install with a fixed set of templates [00:04] and easy to uninstall for users [00:04] seb128: i like ubuntu-templates, but we need to hide templates that dont have a binary [00:04] it's not too intrusive and replies to the first need [00:04] well that should be easy enough to do from nautilus [00:05] or do we need to do that? nautilus will suggest to install the required software when trying to open one [00:05] seb128: how does that work? do templates have a dedicated mime-type? [00:06] e.g. application/odt-template-openoffice ? [00:06] no, they are normal files [00:06] copy a file in ~/Templates [00:06] it will be added to the menu [00:06] yes. but how does it detect which package to install? [00:06] and using the menu item will copy the file where you are [00:07] nautilus knows the mimetype [00:07] right. thats what i mean [00:07] and gnome-app-install has a mapping of mimetypes and softwares [00:07] there are special mimetypes for templates of a certain app [00:07] but i think that wouldnt help [00:07] because the automatic install feature doesnt reduce the amount of menu items [00:08] right [00:08] but the amount of packges being installed [00:08] you want the other way around [00:08] potentially more packages with templates installed than listed [00:08] well, I want an ubuntu-templates which I can uninstall if I want to manage my templates myself ;-) [00:24] 'night everybody [00:31] robert_ancell: i suppose you did not see bug 399046 before starting to update cheese, no? [00:31] Launchpad bug 399046 in cheese "Please sponsor version 2.27.4 in karmic (dup-of: 399056)" [Undecided,New] https://launchpad.net/bugs/399046 [00:31] Launchpad bug 399056 in cheese "Update to 2.27.4" [Wishlist,In progress] https://launchpad.net/bugs/399056 [00:32] Ampelbein, sorry didn't see that. Have you done the work? [00:32] robert_ancell: but you can do it if you want since someone duped the report anyways. [00:33] i'm at building it [00:33] Ampelbein, there are changes that StevenK didn't commit so I'm adding those now too [00:33] robert_ancell: ok, then you do the update. [00:34] robert_ancell: add x11proto-core-dev to build-dep and pass --enable-mmkeys to configure to build with multimediakeys-support enabled. [00:43] robert_ancell: oh, and build-dep on docbook-utils, too. otherwise the documentation-build will fail with "unable to parse en_GB/cheese.xml" [00:45] Ampelbein, thanks, I've pushed to bzr+ssh://bazaar.launchpad.net/~ubuntu-desktop/cheese/ubuntu/, please check if it looks ok [00:49] robert_ancell: i think rarian-compat is not needed as a build-dep, we build with disable-scrollkeeper anyway. [00:50] Ampelbein, right. Why do we disable scrollkeeper? [00:50] robert_ancell: and in regard of bug 345772 i chose to not build the non-hildon packages with hildon on lpia. [00:50] Launchpad bug 345772 in cheese "lpia package built with hildon support while there is a separate hildon package" [Low,New] https://launchpad.net/bugs/345772 [00:53] Ampelbein, ok I'm reading that line a couple of times to get it. So many double negatives :) [00:54] robert_ancell: scrollkeeper is of no use on the buildd's as far as i can tell. it's database get's purged after every build. [00:54] robert_ancell: sorry, i'm no native speaker ;-) [00:56] I mean bug 345772 - you say that snippet should be there? [00:56] Launchpad bug 345772 in cheese "lpia package built with hildon support while there is a separate hildon package" [Low,New] https://launchpad.net/bugs/345772 [00:57] robert_ancell: no, i meant that should be gone. so that ONLY the -hildon packages get hildon support. [00:57] robert_ancell: with that snippet the "normal" packages on lpia are built with hildon. [00:57] robert_ancell: and i think that's wrong (as stated by the bug reporter) [00:58] Ampelbein, I see. I'll make that change too [00:59] Hello everyone! [00:59] robert_ancell: Hey there. How was your trip? [01:00] TheMuso, hey yourself. The trip was really good. Got to meet up with a bunch of GNOME people [01:08] Cool. [01:10] Can somebody help move Empathy dependencies to main and change the desktop seed? https://bugs.launchpad.net/ubuntu/+source/telepathy-farsight/+bug/388898 [01:10] Ubuntu bug 388898 in telepathy-farsight "Move Empathy Dependencies to Main and Update Desktop Seed" [High,Fix released] [01:32] TheMuso, Luke, are you going to do gnome-media today? I have a patch in bug 299642 that I want to put in [01:32] Launchpad bug 299642 in gnome-media "Microphone Capture ALWAYS muted" [Low,Fix released] https://launchpad.net/bugs/299642 [01:36] robert_ancell: I've just uploaded it. When I see announcements go out of a morning I start working on them right away. [01:36] TheMuso, ok [01:36] If its in bzr when I get to uploading the package, i will go in then. [01:36] s/i/it/ [01:37] I'm negotiating with upstream about it at the moment [01:37] aho ok [01:38] Well put it in bzr when ready, and feel free to prod me if you want it uploaded sooner than the next point release. [01:40] Actually, more to the point, I start working on package updates as soon as I see the listed as uploads on the gnome-ftp list. [07:09] Good morning [07:10] pitti: good morning :) [07:15] Morning pitti. [07:48] robert_ancell: is nautilus ready for sponsoring? I just uploaded a 2.27.2 followup with a dependency fix [07:49] morning pitti, yes, please sponsor [07:49] robert_ancell: good morning! [07:50] I wonder why it isn't on http://people.ubuntu.com/~dholbach/sponsoring/index.html [07:50] pitti, did you see the blueprint I opened for a new gdmsetup (https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-karmic-gdmconfig) [07:50] robert_ancell: I didn't, I just heared that yuo want to work on it (*applauds*) [07:51] guess the page hasn't updated yet? It shows up in http://people.ubuntu.com/~seb128/versions.html [07:51] robert_ancell: the bug would have been enough, but I don't mind having a blueprint; accepted for karmic [07:52] rick wanted it blueprinted [07:56] pitti, I'm doing the gvfs package - how did you do the 90_relibtoolize.patch? Mine is being difficult... [07:56] robert_ancell: with quilt? [07:56] did you run autoreconf or gnome-autogen.sh? [07:57] robert_ancell: btw, the patches might not apply any more; I recently updated the gphoto port upstream, but hasn't been applied yet [07:57] so if you wish, I can do the update [07:57] then I'd replace the patches with the current versions, etc. [07:57] robert_ancell: I always use autoreconf -fvi [07:57] that worked last time [07:57] pitti, I'm half-way through it. Seems ok apart from autoreconf. 3 of the patches went upstream [07:58] I'm bugging davidz to commit the other ones as well [07:59] robert_ancell: AFAIR, I pushed up to the previous patch, cp -r gvfs-... gvfs-....new, cd gvfs-....new, autoreconf -fvi, cd .., diff -Nur gvfs-... gvfs-....new > /tmp/p, cd to the original one, mv /tmp/p debian/patches/90_relibtoolize.patch [07:59] go quilt [08:00] heh [08:00] The -fvi works well, it doesn't add all the extra files you get without it [08:50] mvo: btw, do you have any Python programs that talk to policykit? I ported jockey yesterday, so that might help you [08:51] it's delightful, actually; rip out all the stuff from the client side, and just adapt the server side check a bit [08:55] pitti: yeah, system-service-d is one - I have a look at your commit :) [08:55] pitti: did you had a chance to check my apport branch yet? [08:56] mvo: ah, I wanted to ask you about that [08:57] mvo: the diff looks weird, it adds all the debian stuff [08:57] but I guess launchpad just got confused and diffed your branch against trunk instead of the ubuntu branch [08:57] or you branched off the ubuntu branch instead of trunk [08:57] pitti: most likely, I did the work against the ubuntu branch I think [08:57] either way, I'll sort it out [08:58] some stuff needs to go to trunk, some is ubuntu specific [08:58] * mvo nods [08:58] mvo: you locally tested the retracing stuff, I guess [08:58] yes [08:58] mvo: great work, btw! [08:58] well, to the extend I know about it :) [08:58] apport-retrace [08:58] I wouldn't have known how to handle kernel crashdumps [08:58] not the magic database [08:58] me neither (until I looked into it) [08:59] but its a pretty elegant thing and crash (the kernel debugger thing) is pretty amazing [08:59] mvo: http://bazaar.launchpad.net/%7Ejockey-hackers/jockey/trunk/revision/562 FYI [09:00] mvo: did you update apport/report.py, crash_signature() for kernel crashes? so that auto-duplication works? [09:00] pitti: thanks for the diff, that looks pretty tame, I have ubuntu-system-service and aptdaemon on the porting list [09:01] pitti: no, but I can do that today (updating crash_signature) [09:01] mvo: indeed, most of it is easy; only difficulty was to find out the incantation of CheckAuthorization() [09:01] it will currently just not to signature checks because there is no executablepath [09:02] mvo: would be great if you could add a "typical" output to test_crash_signature() to the test suite [09:02] I guess that is ok-ish at this point because linux-crashdump is not instaled by default so we probably get few reports [09:02] ah, I see [09:02] so it should not do that exepath check for ProblemType: Kernel [09:02] pitti: yeah, I read over the new code yesterday briefly and found dict a bit odd :) [09:03] pitti: yeah [09:03] mvo: it's much nicer with libpolkit, but with raw D-BUS API it looks like that now [09:03] mvo: mainly because you can identify processes by other stuff than pid nowadays [09:04] pitti: I will add a test and the check_signature today, if the add_os_info() bit in the client could be merged then we can declare the lcient as ready, its the only piece that is missing there [09:04] * mvo nods [09:04] mvo: can do [09:05] pitti: thanks, I knew the branch had some warts, but I wanted to pass it along so that you can check and see if it fits into the general direction :) [10:08] morning o/ [10:09] good morning didrocks [10:10] hey chrisccoulson [10:21] good morning everybody [10:22] Monsieur! [10:23] hey pitti! [10:23] how is everybody going today? [10:23] pitti, dunno if you read that but I dropped you a note saying that you can do the gvfs update if you want yesterday [10:23] seb128: oh, I woudl have, but seems that robert_ancell beat me to it [10:24] * pitti isn't really used to IRC notes, sorry [10:24] ok, if you want to look at it and sponsor then [10:24] since there is lot of your changes there [10:24] yes, I will [10:24] yeah, sorry for those [10:24] pitti, it's not an IRC "note", it's just me writting "pitti: something" on this channel ;-) [10:24] I'm not sure how much you read highlights in the morning [10:24] seb128: hm, didn't see that; I did read overnight scrollback, I guess I just missed it [10:25] ok [10:27] pitti, you managed to build the new nautilus without the new gvfs? [10:28] yes, it just built [10:28] perhaps not correctly then? [10:28] it also built on LP [10:28] if it conditionally enables new features, then we shuold bump the build dep [10:29] * pitti drops other work and sponsors gvfs now [10:29] hello seb128 [10:29] pitti, it relies on gvfs changes to work correctly I think but that might not be at build time [10:30] hm, "oops" [10:30] pitti, not sure how it will work on the old gvfs [10:30] I didn't test it extensively TBH [10:30] lut didrocks [10:30] hey didrocks [10:30] hey pitti [10:31] pitti, no worry, it might work fine the changelog just suggests it use the new gvfs changes [10:31] where would be the fun without some karmic breakages ;-) [10:31] seb128: we should definitively build it again then, with a bumped b-dep [10:32] the new features sound interesting [10:32] pitti, well it might not test a build time but rather use that over dbus at run time [10:32] too bad that the gphoto port didn't make it into 1.3.2 [10:32] distro patch it? [10:32] ah, I see [10:32] hey seb128, pitti. good morning :) [10:32] hey chrisccoulson [10:32] seb128: we already do [10:33] ;-) [10:33] but requires this silly 90_relibtoolize.patch [10:33] seb128: btw, any idea why we have this 01_maintainer_mode.patch thing? [10:33] to avoid random autotools trying to be clever and running again at build time [10:34] E: gvfs source: quilt-series-references-non-existent-patch 02-cdda-backend-support-and-prefer-gudev.patch [10:34] robert_ancell: ^ *cough* :0) [10:35] pitti - i had to do the same to tracker too. sometimes the autotools update only alters the timestamp of some files without adjusting their contents, and those files drop off the patch [10:36] ok, thanks [10:38] pitti, it's just a way to say "don't try to be clever and run autotools at build time even if timestamp changed" [10:39] pitti, otherwise you can get racy timestamp changes between patches and the build running autoreconf when it should not [10:41] * pitti wants a quilt-update-autoreconf-patch [10:42] lool has a such script and there is a quilt patch for that in the debian bts too [10:43] we should make cdbs-edit-patch work on quilt packages [10:47] grr quilt [10:47] robert_ancell: don't worry, fixed; I also updated the gphoto patches while I was at it [10:47] pitti, weird, it built for me using bzr-buildpackage [10:47] perhaps quilt ignores missing patches [10:48] it does [10:48] those not listed in the series are just not applied [10:48] that's a bug.. [10:48] seb128: no, I meant patches that do appear in series which are missing [10:48] pitti, was there a problem with the gphoto patches? They seemed to apply fine [10:48] oh [10:48] robert_ancell: no, not a problem, but I rewrote them last weekend based on some feedback from David [10:48] hey robert_ancell btw ;-) [10:49] seb128, hey seb [10:49] robert_ancell, did you manage to adjust back to your timezone? [10:50] btw can someone drop into #ubuntu-meeting in 10 mins to support me for ubuntu membership? [10:50] robert_ancell, I'm there now [10:50] robert_ancell, not running for motu yet? [10:51] Back to Sydney time. Was a little tired Sunday night but pretty much ok today [10:51] * pitti joins and fetches his fanboy equipment [10:51] I need to run out in some 20 mins, though [10:52] seb128, I was thinking about it but you guys are doing a fine job there :) I think my return rate on my packages update is getting sufficiently low to go for that next [10:52] robert_ancell, being motu will not give you extra access for main packages anyway [10:52] ie we will still need to sponsor your changes [10:53] but that's one step on the main uploader way ;-) [10:53] sure, then no rush [10:54] pitti: not sure you read yesterday my demand for reviewing the setup.py for quickly package [10:56] seb128, robert_ancell: can you wave this around in the meeting? http://people.ubuntu.com/~pitti/tmp/robert-ancell-fanboying.txt.asc [10:56] since I might have gone when it's your turn [10:56] pitti, thanks [10:57] * pitti hugs robert_ancell [10:57] * robert_ancell hugs pitti [10:58] didrocks: oh, that looks complex [10:58] didrocks: you don't want to use DistUtilsExtra.auto? [10:58] http://people.ubuntu.com/~seb128/versions.html is a field of mushrooms :) [10:58] robert_ancell, thanks to you :-p [10:59] didrocks: you could probably drop all the list_files() etc. functions, and move completion/bash/quickly to etc/bash_completion.d/quickly [10:59] gvfs uploaded, BTW [11:00] thanks pitti robert_ancell ;-) [11:00] didrocks: of course you are welcome to write your own build system, but in the interest of dogfooding and DistUtilsExtra.auto testing I'd be interested in how it works for you [11:01] pitti: do you have any doc on it? (documentation on distutils is well hidden)? :) [11:01] didrocks: see python -c 'import DistUtilsExtra.auto; help(DistUtilsExtra.auto)' [11:01] pitti: thanks. I'm giving a look at it. Will it resolve my issue with po/ directory? [11:01] didrocks: it's pretty sparse, admittedly; but it gives you the supported file types and their expected extensions/locations [11:02] what's the issue? [11:02] didrocks: you don't need LINGUAS and POTFILES.in with that either [11:02] didrocks: and MANIFEST.in [11:02] eww, Makefile? [11:02] you should drop that [11:03] pitti: I had to list po/ directory in setup.py an in MANIFEST.in to have it copied in ./setup.py sdist, but then, I have it in /usr/po when installing :/ [11:03] didrocks: you'd need to move templates/ to data/templates, I guess (then it will land in /usr/share/quickly/templates/) [11:03] pitti: yes, my work there is to change the Makefile into a working setup.py :) [11:03] didrocks: yeah; just throw away all that stuff :) [11:03] ok, noted. I'm giving a try to that [11:04] didrocks: you should reorganize the source tree to have a dir per package (quickly/, already done), and data/* (-> /usr/share/quickly/), and etc/* (-> /etc/) [11:04] po files, manifest, packages, etc. is all auto-handled [11:04] didrocks: if you rename src/quickly to ./quickly or bin/quickly, it'll be auto-handled, too (see above help) [11:05] pitti: ok, let me try that and I will fire you with questions if it doesn't work :) Thanks pitti! [11:05] didrocks: yes, please do [11:05] didrocks: in general, if you need _anything_ except setup.py with author/project name, etc., I consider that a bug in distutils-extra [11:06] didrocks: i. e. no scripts, data_files, packages, MANIFEST.in, POTFILES.in, etc. [11:06] pitti: ok. I will list that. is there any backport for Distutilsextra.auto for jaunty? [11:06] (I will list if I need extra files) [11:06] didrocks: https://edge.launchpad.net/~pitti/+archive/ppa [11:07] perfect, I know what will take my afternoon then ;) [11:07] I'm off for some errands and lunch then [11:07] pitti: have a good lunch and thanks again [11:07] I need back a working washing machine soon, after all [11:08] didrocks: have fun! [11:08] sure ^^ [11:08] pitti, see you later [11:14] pitti: I didn't check recently but quilt used to fail when a patch was missing [11:15] didrocks: http://people.dooz.org/~lool/debian/differ is a script to record a patch; it uses git or bzr to import your current tree, when you're done exit the shell it created and it will output a patch (unless you exit the shell with an error) [11:16] lool: great, very handy, thanks. I will test it. But the patch thingy was for chrisccoulson I guess :) [11:17] chrisccoulson: ^ :-) [11:17] i think it was for robert_ancell actually [11:17] ;) [11:17] i can't remember now [11:17] robert_ancell: ^ :-) [11:17] lool: pitti: FYI, I tested to add a unexisting patch to the series, quilt doesn't fail [11:17] robert_ancell: Don't forget to tell me that the patch thingie was actually for someone else [11:17] thanks anyway look - looks very useful :) [11:17] didrocks: that's bad [11:17] clearly [11:18] major trap for not applying patches due to typos, etc. [11:18] look -> lool. d'oh! [11:18] this can be a easy thing to fix. Added to my todo list :) [11:18] dquilt push -a || echo error [11:18] Patch foo does not exist [11:18] Application de foo [11:18] error [11:18] It does fail [11:18] That's with 0.46-7 [11:19] didrocks: How did you test that? [11:19] lool: quilt push -a and I have 0.46-6 [11:19] I see that the patch does not exist, but it applies the first one and exit with 0 [11:20] let me try with a valid patch first [11:20] didrocks: Indeed; if it has a valid patch first, it doesn't fail [11:20] Oh sorry it does [11:20] Patch foo does not exist [11:20] Application de bar [11:20] Le patch bar semble vide. Il a été appliqué. [11:20] Application de foo [11:20] => error [11:21] strange, I tested before a valid patch, and it fails and then, reverted back to my first test case and it exited with error now :/ [11:21] I don't understand what happened the first time [11:26] really off now, bbl [11:30] robert_ancell, ok, seems you will have to run for motu anyway [11:31] seb128, ok, that makes sense. Based on the Wiki I wasn't aware membership = "community membership". There are so many levels :) [11:31] I think there is somewhat a fail in the current membership structure though [11:31] yeah me neither, I didn't go through all those things I was there before [11:33] seb128, ok, I've followed the MOTU membership details on the Wiki and it links back to the original Membership page!! [11:35] lol [11:36] it's the same pretty much, except you get interviewed by the motu council instead of a membership board [11:36] https://wiki.ubuntu.com/UbuntuDevelopers#Applying === MacSlow is now known as MacSlow|lunch [12:38] seb128: do we need further coordination for the gnome-control-center polkit1 migration? I ported ubuntu-system-service now and our patches inside g-c-c - can I upload this or is there other stuff pending? [12:51] seb128: regarding templates, forgive me if this has been brought up before, but has it been discussed whether users actually expect to interact with templates through the filesystem at all? It seems very strange to me that ~/Templates isn't a hidden folder, as I suspect many users just see it as a weird empty default directory rather than a place to navigate to and place files [12:54] mvo, talk to chriscoulson when he's around he's working on the g-c-c 2.27 update [12:55] YokoZar, what do you mean exactly? [12:55] YokoZar, ie what else would you suggest? [12:55] seb128: ok [12:55] we could probably display a banner in the templates directory to indicate how to use it [12:55] seb128: that was my thought [12:56] that's orthogonal to the system templates issue though [12:56] seb128: But then I thought that if you add or remove templates, you currently do this by adding and deleting files from a folder that you interact with in nautilus. But most other configuration of this sort we use control panels and such [12:57] So i don't think that the whole "moving files around" matches user expectations for people that want to mess with templates; worse, since it's user visible, the ~/Templates folder can clutter the home directory [12:58] It might be worthwhile to have a way of deactivating systemwide templates from an individual user perspective as well, but that would mean being able to "delete" templates from ~/Templates that aren't actual files there [12:59] all that seems orthogonal to the launchpad bug [12:59] I've no strong opinion either way, it's far from being perfect and patches are welcome [12:59] but it just re-enforce what I was saying, that needs design decisions before starting just adding random templates to fix the issue [12:59] Yeah true [13:00] Well the launchpad bug is kinda broad ("difficult to use") -- it sure would be convenient if we could put templates into packages and install them by default, that way the odd user that installs 3 word processors and also uses templates all the time could deactivate them [13:01] would you split those packages by formats, ie template for word editors, templates for images, etc? [13:01] and what would you do when a template is installed but not matching software? [13:02] Well if the template were part of the matching software package that wouldn't be an issue (thinking of open office here...could be done with depends on the template package) [13:03] YokoZar, still, do you split templates by function then, template-work, template-oocal, template-abiword, template-java? [13:04] Honestly I think user testing will reveal that we likely only need a very small number of templates; users may make lots of use of right click->create empty office document, but when they want to make an image they'll instead open gimp and start working until they have something to save [13:05] But I was thinking template-odt that then depends on openoffice | koffice and such [13:06] and install that in a central place (not the user home folder) so that when they upgrade from 9.04 to 9.10 they'll get the template without having their home folder mangled === mac_vr is now known as macvre [13:06] dbus-daemon loops and consumes ~20% of CPU here - constantly ... ouch [13:07] Then all we need is a convenient way for users to remove/deactivate templates: my suggestion is to right click the context menu and delete it [13:07] YokoZar, the issue is that once you have that in place people will want templates for abiword, and for oocal and for presentations, and for zip and for etc [13:07] i guess the dbus problem is caused by indicator-applet which also eats lots of CPU all the time [13:07] and gconfd is also looping [13:07] seb128: yup, and our design team can then test and figure out which of those we actually need and should have ubuntu-desktop depend on [13:07] wth [13:08] YokoZar, the design team will not state on that, some users might uninstall openoffice and use abiword which shouldn't those get templates? [13:08] * mvo takes gcalctool and brasero from the sponsoring queue [13:08] YokoZar, why java programmers should not be able to get a template? [13:08] mvo, thanks [13:09] i dont think the design team input is valuable for deciding which templates to display [13:09] right, me neither [13:09] I see what you mean [13:09] design team is for design issues and not the instance we ask for input on everything we haven't found a consent yet === mac_vr is now known as macvre [13:10] My expectation is that templates for a program will come when I install that program, if they're going to come at all [13:10] we already had all those things discussed yesterday [13:10] fair enough [13:11] http://irclogs.ubuntu.com/2009/07/13/%23ubuntu-desktop.txt [13:11] look at 23:18 [13:11] it continues the next day [13:11] http://irclogs.ubuntu.com/2009/07/14/%23ubuntu-desktop.txt [13:11] I commented on the bug with a summary === MacSlow|lunch is now known as MacSlow [13:12] so about 00:08 we have more or less reached a consent [13:12] we should split the bug anyway [13:12] adding a cluebar in the templates directory is not controversial [13:12] seb128: i have another idea though. we could let apps ship their template to a system place [13:12] then we need discussion on how we ship templates, if those are shared between desktop, etc [13:12] seb128: and make nautilus-templates-support which then just creates a link to the right dir to enable the system templates [13:12] seb128: you could remove nautilus-templates-support to get rid of templates [13:13] to prevent general clutter in the system menu, we can use policy [13:13] just a slight variation compared to what you suggested with ubuntu-templates package [13:13] maybe a compromise? [13:14] asac, we could also have a gconf key to enable system templates [13:14] yes. depends on which level we want to approach this [13:14] packaging or code [13:14] so the users who find those too cluttered could dnd the ones they want to their user dir and turn the key off to stop using the default list [13:14] easy to pick some in the system dir and turn off the dir use [13:15] right. if that works for you we can do the gconf key. but then we could also do a gconf key that allows you to disable a few ;) [13:15] anyway I think there is enough variant to justify a spec or a mailing list or meeting topic [13:15] agreed seb128 [13:15] right. [13:16] It sounds like once we have system/user templates together, and the user disabling system templates, the whole deleting/adding files to ~/Templates metaphor breaks down [13:16] seb128: i would think we should prepare a mail with the proposed solutions ... its probably a topc where a meeting discussion out of the blue would lead to an unqualified decision [13:16] right [13:16] lots of thoughts would get repeated et al [13:16] or lets make a wiki page out of it ... which could become a spec [13:16] we should start with list discussions [13:17] and then post the content to list [13:17] and maybe discuss in a meeting once discussion is over [13:17] right [13:17] reach consent based on list discussion [13:17] Would it be appropriate to have a context-menu in the context menu (as in right click->create document->hover over office writer document->right click THAT->remove template) [13:17] I don't know if we do this anywhere else [13:17] seb128: so how about setting up a wiki page where we list the suggested approaches with Pros/Cons [13:17] seb128: and once everyone has added his ideas there we sent that to mailing list? [13:17] asac, sounds good to me [13:18] YokoZar: i dont think that would be a good user experience [13:18] YokoZar, right click is not discoverable and should not be the only way to do something [13:18] of course [13:18] YokoZar: the final solution would be a template editor that you can probably open from that menu [13:18] e.g. (edit ...) [13:18] Yeah [13:18]