=== heHATEme is now known as Vorian [00:06] i think something during pre release of jaunty ment i ended up with a gtk password prompt from kpackagekit is there a known fix? [00:07] * seaLne watches the instructions for ubuntu one fail miserably on kubuntu :( [00:09] the install page is scarily lacking in details [00:12] * seaLne presumes he is not the first to notice the lack of QA in this [00:17] seaLne: seele had that in her kpackagekit review as well [00:17] she fixed it by installing another package [00:17] don't remember which one but check her slides [00:17] should be in there [00:18] and let me know which one it was so i can install it here as well :D [00:18] heh, i know its a pre release problem because its fine on machine installed later than this one :) [00:18] my upgrade has the problem as well [00:18] without any pre-release versions [00:18] oh? [00:19] seele: Pong [00:19] i gave up and did a clean install on my work machine upgrading with pre releases from hoary over the years had its tole [00:20] hehe [00:20] i think i upgraded this one since gutsy [00:20] sometimes prerelease sometimes not [01:00] Is it me, or does the ubuntu one installation does not work with konqueror [01:18] it won't work if it uses apt-url [01:19] txwikinger: you could just install it manually instead of clicking the link [01:19] well.. it works with firefox [01:19] I just wondered if it is only on my machine [01:20] txwikinger: the instructions say [01:20] Note: If you're using a non-Firefox web browser, you can install the client by going to System » Administration » Synaptic Package Manger and searching for ubuntuone-client [01:20] nellery: hehe... reading instructions? I must have lost that ability long time ago ;) [01:21] txwikinger: heheh well I completely missed out the big INSTALL button and just installed it manually [01:21] :D [01:30] ScottK: have you been following the discussion on the ayatana ml? i'm confused about some of the functionality they are talking about [01:30] ScottK: it doesnt seem like it will be compatible with any kde system [01:45] seele: I have been trying to follow it. I tend to agree. [02:17] Nightrose: too slow; new snapshot already packed in my personal PPA https://launchpad.net/~andreas-wenning/+archive/experimental , Lure would give it a quick test that it wasn't completely broken before it is sent out to a lot of people; but you're welcome to give it a try :) [02:22] of course including the claimed "working with hidden network part" ... snapshot taken 2½ hours before you asked ;) [03:02] ryanakca: hiding. And asleep ;) [07:13] a|wen: wow - i'm impressed :D [07:23] a|wen: hidden+wpa2-enterprise+peap+mschapv2 works for the first time with plasma-network-manager! [07:23] a|wen: I think your test package is more than ready for wider testing [07:30] Lure and Nightrose: sounds almost like we have a winner already :) ... I'll upload and send out a notice later today [07:37] hello [07:37] a|wen: yes, I am more than happy with this version [07:38] * Lure_ is currently connected both to wire and wireless === Lure_ is now known as Lure === crouic is now known as crouic5 [07:42] great :) [08:04] hi! i have a problem with the update of KDE4.2.3 [08:05] when I run in the console a comand with _sudo_ I got this error [08:05] Could not start ksmserver. Check yout installation [08:05] and the KDM restart [08:28] Riddell: thks for the mails on -talk [08:28] I merged phonon stuff [08:30] btw, I think you should merge firebird/ibase stuff as I rememember a launchpad bug requesting it. [08:37] Riddell: wrt to phonon global issue, I guess it's a Qt bug and should be fixed there instead of fixing all others packages [09:02] hi all [09:02] once upon a time, there were Qt 4.5 packages available for Intrepid, but I can't remember on which PPA... [09:08] I need those desperately :( [09:25] bug 375145 [09:25] Launchpad bug 375145 in ubuntuone-client "ubuntuone should have a kde client" [Wishlist,Triaged] https://launchpad.net/bugs/375145 [09:35] kwwii: https://edge.launchpad.net/~ubuntu-art <= description typo ... should be Qt instead of QT ;-) [10:03] <\sh_> moins === \sh_ is now known as \sh [10:25] apachelogger: thanks, I'll change it === dpm_ is now known as dpm === mcasadevall is now known as NCommander [11:32] Riddell: thiago fixed phonon global issue [11:32] fabo: yeah saw that, I reverted my the commits I made to KDE SVN [11:33] fabo: are you going to follow the packaging naming I used for phonon from qt? [11:35] Riddell: libqt4-phonon ? [11:35] yes [11:36] * fabo goes to lunch [11:38] groovy === santiago-pgsql is now known as santiago-ve [13:40] Why do some apps have several icons in the K-menu? [13:40] For example: k3b [13:42] I only have one. [13:42] Hmm [13:42] ScottK, did you upgrade or make a fresh install? [13:42] Upgrade. [13:43] ScottK, do you know if the .desktop entries are cached somewhere? [13:43] No idea. Sorry. [13:44] * ScottK just slams this stuff into pacakges - doesn't know how all the bits actually work. [13:44] ScottK, he, you're not the only one I think :-) === cmvo_ is now known as cmvo [14:04] ScottK, do you know why "hicolor" is special theme? It seems to be default [14:04] That should be a fallback. [14:04] ScottK, I see [14:04] ScottK, common for no matter what theme? [14:05] Common for when whatever theme you are using doesn't provide something. [14:05] Oxygen should be the default theme. [14:05] ScottK, sounds reasonable... except, it should be called "default" or "fallback" or something... [14:07] The following helped clean up my K-menu: right-click on it, select menu-editor -> Edit -> Restore to System Menu [14:08] ... and also: sudo update-icon-caches /usr/share/icons/hicolor [14:12] hmm.. i installed notify-osd, but how to i turn it on? [14:12] run gnome? [14:13] oh, it requires gnome? it doesnt work in kde yet? [14:13] why didnt it pull gnome in as a dependency then? [14:14] I don't know I was just guessing, you'd need to be running an app that uses it at least, like pidgen [14:15] ugh [14:16] how am i supposed to evaluate this compared to kde notifications if it doesnt work with kde apps yet.. [14:18] well run it from a gnome app and note the differences. that notifications don't work cross desktop is one of the more fiddly problem I hope the dx team will solve [14:23] seele: You can use notify-send to send yourself notifications. [14:23] That requires another package, but it'll tell you which one the first time you try it. [14:26] ScottK: thanks [14:26] No problem. [14:27] hmm.. am i missing something else? that doesn't look right. it's just a regular notification with a close button [14:27] * seele gives up === rickspencer3 is now known as rickspencer3-afk [14:54] seele: I would just install an ubuntu VM :D === rickspencer3-afk is now known as rickspencer3 [15:19] ryanakca: btw, will we ever get a proper tour for kubunt.org? [15:30] hi there ! [15:31] resalut Tonio_ [15:31] anybody else using screen with the new profiles stuff? [15:35] seele: the easiest way to try notify-osd is: [15:35] killall notification-daemon [15:35] /usr/lib/notify-osd/notify-osd [15:35] Then "notify-send " [15:43] seele: Based on Mark's reply to you on Ayatana, I guess KDE doesn't have a notification system. === kubotu_ is now known as kubotu [16:05] ScottK: heavens forbid anyone care about anything besides ubuntu [16:09] agateau: ah, that worked. thanks === kubotu_ is now known as kubotu [16:21] is there a way to convince Strigi to run in Jaunty? I can start nepomuk, but no way to get Strigi running [16:22] must admit I've not tried [16:22] tried strigi-client? [16:23] Mamarok: have you read? http://kubuntuforums.net/forums/index.php?topic=3102231.0 [16:24] in my system Strigi works after that workaround [16:26] lex79: that's what I was doing, but I must have missed a step somewhere, sec [16:29] * ScottK notes on http://summit.ubuntu.com/uds-karmic/ he seems to be the only one signed up for Kubuntu stuff. [16:30] lex79: well, now I could start Strigi, but I get an error message: [16:31] Failed to contact Strigi Indexer.... [16:32] ignore it and try to restart the system [16:32] Could not get owner of name 'org.kde.nepomuk.services.nepomukstrigiservice': no such name [16:32] ok, restart the whole system or only KDE? [16:32] same here but strigi works :) try only kde [16:33] ScottK: you probably should mail the list with it [16:33] If I cared enough, sure. [16:33] hm, that's actually another bug in Jaunty: I can't log out properly, have to go to a console and kill kdm [16:34] ScottK: man... [16:35] Well currently if it wasn't for bad attitude, I'd have no attitude at all. [16:38] ScottK: you really need a time out [16:38] Yeah, well I'm pretty sure that's what my conclusion will be after UDS. [16:39] I recommend taking one in any case, there is nothing like a good shift in perspective by getting as far away from everything as possible :) [16:39] maybe I need to subscribe to specs I registered [16:41] * txwikinger_work wishes he finally finds some time again for kubuntu [16:46] txwikinger_work: life in canada not as boring as in Birmingham? [16:46] Riddell: yes [16:47] and I have two jobs resulting in 12h per day work [16:47] now why doesn't that surprise me [16:48] Riddell: You know Bham far too well, I guess [16:55] * txwikinger_work thinks about an ubuntuone plasmoid [16:56] what does YMMV stand for in conversation? [16:57] your milage may very [16:58] roughly "it should work this way, it has in my experience, but it might not quite when you try it" [16:58] seele: FYI, Quassel already speaks the Galago protocol (which should work with the old gNOme notification daemon as well as Ayatana) already if KDE integration is disabled [16:59] I think for 0.5 I'll explore that a bit more, as well as the new-style KDE systray, and allow it for KDE integration as well (optionally) [17:00] * seele tries to parse this email [17:00] i still dont understand what mark is saying [17:00] > 2) will notification display systems be interchangable in Karmic? [17:00] > [17:00] They are already interchangeable. YMMV, on Ubuntu we will only test with [17:00] notify-osd. [17:01] seele: as I understand it, Atayana is another implementation of the Galago dbus protocol, so apps that that notify via dbus will work with it [17:01] from the app point of view, it doesn't matter what sits on the other end of the dbus bus [17:02] and that was slightly tautological now :) [17:02] right, and assumingly kde notifications will plug into the ayatana thing [17:02] I'd doubt that [17:02] unless KDE agrees to use the Galago spec [17:02] which they don't, because it's too limited [17:02] it's not far off as I understand it, it just needs galago to agree to use the KDE changes [17:03] yes, it's an extended galago API in the KDE namespace [17:03] apps that use knotify directly, however, would need knotify to plug into it. I would be surprised if KDE upstream decided to support that; however, certain distros might patch that in :) [17:04] if/when galago agrees to use the kde changes, will ubuntu use that spec? i thought they made modifications to galago and so it would still be out of sync? [17:04] Sput: Unfortunately the actions in your notifications won't be supported by notify-osd. [17:04] ScottK: well, the dbus interface supports actions, and Quassel offers an action [17:04] if the daemon doesn't display them, that's a different matter [17:04] Sput: Yes, and it appears Canonical's position is that you should notice their implementation is incomplete and not offer them. [17:05] that is an interesting position :) [17:05] I'd need to figure out if they offer a capability value for that [17:05] Considering 0.5 will support notifications with actions to move to another place in the app, that seems pretty invasive to me. [17:05] They do. [17:06] we already use those for figuring out if HTML needs to be escaped or not [17:06] * ScottK wonders how long it will be before an upstream 'supports' this by just not doing notifications if there are no actions (your notification library doesn't meet our minumum requirements, so no notifications for you). [17:07] That's spec compliant in exactly the same way notify-osd is. [17:07] for Quassel it's not a major change. the action is an additional feature that is treated exactly like a click on the bubble anyway [17:07] incidentally, we need the button only because KDE fails to handle bubble clicks properly :) [17:07] so in order for kde notifications to use the notify-osd, kde needs to use the galago spec, otherwise the notifications will continue to appear the same way as they do now? [17:07] and as a visual hint that there's something to click on [17:08] For Karmic I'm looking at providing both KDE'ified and non-KDE'ified versions. [17:08] seele: that's how I would understand it [17:08] Right, but notify-osd doesn't support clicking on the bubble. [17:08] well, that's the distro's loss then [17:08] :/ [17:08] * apachelogger ain't gonna accept any loss anymore [17:08] Agreed. [17:09] if kde does use the galago spec (or they get it updates, whatever) will you be able to choose to use notify-osd or notify-kde (whatever it is called)? because in theory all notifications should work perfectly fine regardless of the display [17:09] enough loss for the next 5 or 6 development cycles we had :P [17:09] and when notify-osd is shipped with kubuntu karmic next fall, will we get an option somewhere so that users can select which way they want to handle notifications? [17:09] * seele should probably just ml this for everyone to comment on [17:10] afaik, KNotify actually already allows registering other clients. the new plasma systray, for example, plugs into it replacing the old-style bubbles [17:10] seele: Mark seems pretty determined that actions are evil. [17:10] * Sput needs to run though [17:11] ScottK: forget actions for the moment [17:11] i'm asking if people will be able to switch to KDE-style notifications if they have the choice or not [17:11] regardless if they have actions on them or not [17:11] depends on the implementation [17:11] will upstream's experience be preserved [17:11] seele: I think it's fundamental to the utliity of application notifications. [17:11] seele: That's also a good question. [17:12] * Sput thinks that's a political issue - will kubuntu be allowed to not patch KNotify to be broken :) [17:12] ultimately notify-osd would be implemented via a plasma widget that binds to the appropriate dbus stuff and thus binds knotify to notify-osd [17:12] seele: good discussion for UDS [17:12] seele: I think that upstream KDE's notification experience is already very good and it would be a poor use of resources to make Kubuntu use something else. [17:12] so basically it will just have to eat knotify input and throw it out to notify-osd [17:12] btw, in Ubuntu, we have a session that you can log in with that gives closer to default GNOME experience [17:13] rickspencer3: In Kubuntu we don't need that and are generally happy for it. [17:13] perhaps Kubuntu would want to have a system like that [17:13] ooh, optional crippling :D [17:13] anyway, I'm gone for now. [17:13] See you later. [17:14] It's not crippling, it's just choice for the few users who care about having more of a default GNOME experience [17:15] seele: also, I think the KDE developer on the Dx team wants to figure out with sebas, etc... how best to proceed, so good discussion topic for UDS [17:15] GNOME experience on a KDE desktop? [17:15] rickspencer3: well, for GNOME it is not crippling, for KDE it might very well be since both the plasma notification as well as the knotification class itself leave the developer with a lot greater choice of what he wants the notification to look like [17:15] * txwikinger_work rather has a KDE experience [17:16] but what I'm saying is, that you are assuming that it will be separate from KDE, and not part of KDE ... we don't know how they will end up working with upstream on it [17:16] rickspencer3: also, is there any user research or testing planned for the notification system? there's an awful lot of design going on without any validation [17:16] seele: yes [17:16] now people are talking about finer details like delay length [17:16] you should connect with ivanka in #ayatana [17:16] rickspencer3: Is any of it going to be published? [17:17] I only know that the next step in the plan is to have a discussion at UDS [17:17] rickspencer3: I hope it is in fact discussion and not just disclosure of pre-ordained decisions. [17:17] regarding notify-osd and KDE/Kubuntu [17:17] seele: IMHO that is also something the application developer should be deciding [17:17] depending on what the application spits out you might want longer or shorter delay [17:18] apachelogger: yes, the responsibility could be put on the application developer because they are the domain expert. and hopefully know how long someone would want to see their app's message [17:18] apachelogger: I believe it may be dynamic depending on text length, not sure thoguh [17:18] but i think ubuntu is trying to "fix" all of the app notifications at once [17:18] * seele coughs *context* [17:18] seele: well, that is a quite good target for gnome :D [17:18] when is karmic feature freeze? [17:19] rickspencer3: that is still too unprecise [17:19] seele: https://wiki.ubuntu.com/KarmicReleaseSchedule [17:19] apachelogger: could be [17:19] thanks [17:19] also, by seting a general delay either depending on lenght or just use the same for everything [17:19] you prevent users from setting own delays [17:19] I believe that is an empirical question and will let the user researchers test that out [17:20] rickspencer3: If research is just going on now, it sounds like Karmic +1 would be a much more reasonable target for implementation. [17:20] in my experience, application developers are too generous in how important they believe their apps are for users, so given the option, they'll always turn it up to 11 [17:21] rickspencer3: those are issues that should be treated individually though [17:21] apachelogger: perhaps [17:21] that is like... because arora got rendering problems with the oxygen style you enforce plastique because it works for arora and all other Qt applications [17:21] a bloody workaround IMHO :P [17:22] I can say this: [17:22] rickspencer3: kde peoples say that their galago messages have gone into a black hole. is there some other way they can work to update the spec? [17:22] I believe that the KDE developers on Dx team really wants to work with the Kubuntu and KDE communities [17:22] Right, but they are implementers, not designers. [17:22] seele: fd.o ... there just needs to be a discussion between gnome, kde and possibly distributions to establish a spec [17:22] Most of the issues we are discussing are design issues. [17:23] so I would advise engaging with a positive attitude and not harping on the past (that he wasn't part of anyway) [17:23] because the galago spec is no approved spec anyway [17:23] so fd.o could just use it as a starting point and create a real cross desktop notification spec [17:23] apachelogger: the problem is the galago maintainer.. kde has been trying to communicate with him for a while for that exact reason [17:24] seele: our plan regarding galago and kde specs is to ensure notify-osd can handle both [17:24] seele: they don't need his approval to implement an fd.o spec [17:24] seele: and also work on fdo to achieve consensus on a unified spec [17:24] if he does not respond they should just go ahead and establish discussion between the affected parties and leave galago out of the loop [17:25] seele: notify-osd is going to be turned into a common library for all the desktop generic code [17:25] and two binaries: one for gnome and one for kde [17:25] rickspencer3: I think if the disucssion is about what should be implemented for Kubuntu to improve the user experience for Kubuntu users we can move forward just fine. I don't think discussions around replicating what was done for Ubuntu in Kubuntu will go well. [17:25] at the moment, we are experimenting with using plasma rendering for the kde binary [17:25] so it would follow plasma themes on kde [17:26] agateau: there was a previous question about kde implementation and if notify-osd and knotify can cooexist so that users can switch between them [17:26] seele: yes I think they can coexist [17:26] right now knotify works like this: [17:26] * txwikinger_work gets an headache [17:26] they are not doing the same thing anyway? [17:26] co-exists means more resource wastage? [17:26] I don't think the notify-osd notifications look at all good in a KDE environment. [17:26] knotify is not only about visible notification [17:27] txwikinger_work: Not necessarily. [17:27] it's also doing sound and log and actions and whatnot [17:27] seele: if there is someone listening on org.kde.VisualNotification dbus, send it to it [17:27] ScottK: ok ;) [17:27] seele: otherwise show an old school passive ugly popup [17:27] seele: right now plasma systray provides an implementation of org.kde.VisualNotification [17:28] seele: which shows plasma notifications [17:28] right [17:28] seele: if you disable this (there is an option in the plasma systray dialog) [17:28] you fallback to old school popup [17:28] the idea is to make it possible to switch between plasma notifications and notify-osd notifications [17:29] at run time [17:29] ok [17:29] at least that's my idea, given the constraint I have [17:29] seele: will you be at uds? [17:29] agateau: no [17:29] seele: you'll be able to call in though right? [17:29] too bad :/ [17:30] rickspencer3: hopefully for most of the sessions unless i get meetins scheduled [17:30] it would be good if we can get you connected, at least for that discussion [17:30] I can change the schedule around if needed to ensure there are no conflicts for you [17:31] to avoid confusions: knotify won't be affected by notify-osd [17:31] it looks like i might have a meeting on tuesday morning (EST), but it is a phone call and hopefully wont run into the first kubuntu session [17:31] you will still have the classic kde notification configuration system [17:31] will that notification system control notifications for notify-osd? [17:31] with ability to play sound and other actions [17:32] yeah... and speech synthesis [17:32] e.g. turn them off or add a sound, etc. [17:32] what will happen is that when knotify wants to show a visual notification, notify-osd will do it [17:32] ok [17:32] seele: take a look at the notifications module in systemsettings [17:32] everything you can control there is knotify [17:32] yes, i'm familiar with it [17:32] notify-osd would just replace what plasma is doing :) [17:34] agateau: I guess I don't see the point in switching to a different system. I think it would be better to make improvements in what we have now. [17:35] ScottK: that is not a decision i can take :/ [17:35] I understand. [17:36] If that decision has been taken it would be useful to know. [17:36] I tried to lobby for using/extending plasma notification system, but failed [17:37] Now I am going to concentrate on making notify-osd on kde rocks as much as possible [17:37] (or suck as less as possible, depending on your pov) [17:38] Well traditionally Kubuntu Council would take such a decision for Kubuntu. [17:38] If that's been overturned, I think it should be said. [17:39] sabdfl: ^ [17:39] I am not very aware of the way things are decided atm [17:39] that's just how I understand things [17:39] Of course. [17:39] Maybe rickspencer3 knows. [17:40] I'm in a meeting now, I'll ping you back soon [17:44] back for a moment [17:44] so "who decides"? [17:44] I don't think anything has really changed [17:45] I expect the Kubuntu Council is still the governing body for Kubuntu [17:45] that said, I would recommend striving to be easy to work with and thoughtful about the needs of *all* stakeholders [17:48] can someone summarize what the new system would improve (for varying meanings of improve) for us? so far I have heard about taking away actions from notifications [17:48] is there anything else at the moment? [17:49] There is making the systray smaller at the expense of making some apps harder to get to via systray icons [17:50] i see [17:51] - avoid notification flood [17:51] (notifications are queued) [17:51] done in plasma as well in 4.3 right? [17:51] - nice feedback for kmix volume [17:51] agateau: Doesn't Knotification in 4.3 have that? [17:51] maybe different [17:52] * txwikinger_work thought so [17:52] - nice feedback for powerdevil brightness [17:52] ScottK: possible yes [17:52] - click through (not everyone likes this one i guess) [17:53] is there a notification log? [17:53] txwikinger: yes, in knotify [17:53] this does not change [17:53] agateau: That's also the 'feature' that makes it so that the thing you do to hold the notification from going away (click) also makes it harder to read (transparent) [17:53] and there is also ~/.cache/notify-osd [17:53] ScottK: not sure what you mean [17:54] Actually I'm wrong on that. [17:54] Just checked it again. [17:54] at the moment, we are experimenting with using plasma rendering for the kde binary [17:54] Which binary is that? [17:55] Actually there is no way to keep the notification from going away with notify-osd. [17:55] sebas: notify-osd will be split into a library and two binaries, one for gnome and the other for kde [17:55] Uhm, and the binary does ... ? [17:55] the work :) [17:55] right now, notify-osd is a binary [17:55] agateau: I think it would be very nice if such a binary gave users of non-KDE apps in a KDE session a native feeling experience with their notifications. [17:55] which is started when someone talks to org.freedesktop.Notifications [17:56] * sebas would think that a Plasma applet would do the work, in fact I think that a plasma applet *does* the work right now [17:56] namely the systray [17:56] +1 [17:56] So you're saying you install a separate binary to do notifications? [17:56] yes [17:56] Why not get the system tray (which really is the notification thing) do that work? [17:56] ScottK: yes, non kde apps will show their notification the same way kde apps do [17:57] That's how we're implementing it right now [17:57] what would we gain doing it this way? [17:57] - No separate implementation from upstream for once [17:58] - no separate process running [17:58] - standard implementation that does it right [17:58] - sharing of developer resources [17:58] - feedback from all the people who test KDE [17:58] - open process, more likely to be merged upstream [17:58] sebas: as i said earlier, i tried to lobby for using plasma notification rendering on kde, but failed :/ [17:58] - saving of resources both upstream and downstream [17:59] - no diverging message to app developers [17:59] so i am left with ensuring notify-osd does not look completly alien on a kde desktop [17:59] agateau: That's within Ayatana (I gather). Kubuntu may have a differing view. [17:59] agateau: I'm not blaming you, I'm just wondering about the people who take this kind of decision [17:59] It's not like we didn't go over these issues a couple of times [17:59] ScottK: yes [17:59] sebas: ubuntu technical board I suppose [18:00] *sigh* [18:00] That's ... sad. [18:00] apachelogger: Nope. [18:00] sebas: will you be at uds? [18:00] Yes [18:00] ScottK: so, who is? [18:00] this would be the right place to try to convince people about doing it this way [18:00] I've added a systray / notificationarea to the proposed schedule wiki thing [18:00] The Ayatana project without reference to Kubuntu or Ubuntu. [18:00] well [18:00] we don't have to use ayatana :P [18:01] I agree. [18:01] well that's the question [18:01] do we? [18:01] I'm expecting we'll get told different and that's why I expect to quit after UDS. [18:01] I do hope that's not the case. [18:01] that's not acceptable [18:01] ;-) [18:01] well [18:02] using ayatana or ScottK quitting? [18:02] agateau: I feared this much, though I had hoped that people learnt from the mess they now have with GNOME to do it right this time around and not create a fork [18:02] txwikinger: ScottK quitting [18:02] * txwikinger_work agrees [18:02] And that's exactly what I've been talking about with rickspencer3, jono a while ago during a conf call [18:02] Then now I see it happened this exact same way is discouraging [18:03] * Nightrose notes that sebas is not the only one in that situation [18:03] That's true, makes it even more sad [18:03] hmmm [18:03] hmm [18:04] It's a lot like "Can we hear your opinion please, it should sound like this: ...., if it doesn't we'll silently ignore it" [18:04] sebas: I am not that good at convincing people, but I'll support you if you try to convince others about this way of working [18:04] agateau: I'm not out to convince anybody, really. I'm just damn sure it won't go into plasma this way, because it's broken in three ways: [18:05] - technically: a separate binary ... oh come on [18:05] - development behind close doors [18:05] i mean: convincing canonical to go the plasma way [18:05] - no obvious feedback from the community and we'll have our implementation by that time [18:05] I know [18:06] sebas: well there was feedback from the community specifically by you and seele no? [18:06] i do not believe people aim at integrating this work with plasma :/ but at least it should not require patching it [18:06] Nightrose: yes, very specifically, and from aseigo as well [18:06] and users should be able to choose between both solutions [18:06] * txwikinger_work wonders if anyone knows who has what decided anyway [18:06] And we all told the same story [18:07]