| Topic The channel topic is "Plasma: KDE4 desktop, panel and application widgetry. Devel wiki @ http://techbase.kde.org/Projects/Plasma | Plasma IRC Meeting This Saturday - 13:00 UTC: http://techbase.kde.org/index.php?title=Projects/Plasma/20080209 | gobby server for the meeting: ruphy.org:5555". | 13:13 | |
| richmoore2 | http://techbase.kde.org/index.php?title=Projects/Plasma/20080209 <-- here is the agenda for those who've not read it | 13:13 |
|---|---|---|
| aseigo | ok, everyone here? jpwhiting: have you joinged the boggy document? | 13:13 |
| aseigo | er, gobby | 13:13 |
| aseigo | oh, there's jpwhiting in the gobby doc, yes | 13:14 |
| aseigo | richmoore2: moin | 13:14 |
| richmoore2 | hey aseigo | 13:14 |
| Lure | will the chat go on in this channel or on gobby chat or both? | 13:16 |
| aseigo | Lure: in here, but we use gobby to record the minutes and findings | 13:16 |
| Chani | yay | 13:16 |
| aseigo | ok, let's get started if all is well | 13:16 |
| Chani | this window is prettier :) | 13:17 |
| Lure | aseigo: good, as it is hard to follow two chat windows at once ;-) | 13:17 |
| aseigo | so i'd like to rip through the process bits as fast as possible so we can get to fun stuff (design) | 13:17 |
| jpwhiting | Chani: yes, apparently those files are gone | 13:17 |
| * aseigo was surprised when he logged into the gobby and it said someone was already using my pink =/ | 13:17 | |
| annma | ouch, sorry | 13:17 |
| tmske | annma: I think I fixed it, i forgot to uncomment some lines | 13:17 |
| spstarr | lol | 13:17 |
| jpwhiting | no worries, I'll select everything and be able to see maybe... | 13:17 |
| aseigo | =) | 13:17 |
| aseigo | so... | 13:17 |
| aseigo | first item: review board. | 13:17 |
| Chani | aseigo: I wanted green, but there were several greens alerady in use | 13:18 |
| spstarr | aseigo: funny thing is.. konversation ALWAYS makes you pink on my client | 13:18 |
| aseigo | should we keep, it what's people's thoughts on it? | 13:18 |
| aseigo | spstarr: see, it knjows | 13:18 |
| annma | tmske: yup, the config initialization ;) | 13:18 |
| spstarr | haha | 13:18 |
| richmoore2 | i think having the review board to collect patches is good, but it seems a bit slow | 13:18 |
| Chani | review board. hrm. | 13:18 |
| dirk|home | ruphy: yes :) | 13:18 |
| ruphy | ok :-) | 13:18 |
| richmoore2 | is the host it's on on an adsl link or something? | 13:18 |
| Chani | it's certainly a nice idea, I just get really annoyed at the web2.0 stuff and having to boot up firefox to use it | 13:19 |
| richmoore2 | if so i could put it on my server (100 meg link) | 13:19 |
| aseigo | richmoore2: it's not so much that ... apparently mattr kicked over his apache last week and then it was really fast for a while | 13:19 |
| ruphy | richmoore2: 100MB/s unlimited | 13:19 |
| Chani | I like the python script | 13:19 |
| aseigo | richmoore2: i wonder if it is something to do with another app he's running, or if it is some brainddamage in r-b that starts bogging down? | 13:19 |
| Chani | thing is, review board is new, and needs a fair bit of work done on it. | 13:19 |
| aseigo | yes | 13:20 |
| spstarr | yeah it seems slow ;/ | 13:20 |
| aseigo | i'm not overly happy with the speed either, but then most of the review work is done client side | 13:20 |
| Chani | are we gonna end up putting a lot of effort into review board to make it less annoying? | 13:20 |
| aseigo | and posting is done with the script | 13:20 |
| Chani | I haven't noticed speed | 13:20 |
| Chani | I'm too busy being annoye at the interface n'stuff :) | 13:20 |
| aseigo | Chani: well, i don't have time / energy / desire for that.. i don't mind hacking on the post-review script here and there, but that's about it | 13:21 |
| richmoore2 | i agreed that the interface could use some work too | 13:21 |
| spstarr | we need like a 'gobby' patch reviewer | 13:21 |
| * aseigo doesn't mind the interface, actually. | 13:21 | |
| spstarr | where people can modify it :) | 13:21 |
| ruphy | well, I don't use the scripts, but think review-board is great | 13:21 |
| aseigo | heh.. oh lord =) | 13:21 |
| Quit nihui has left this server (Read error: 104 (Connection reset by peer)). | 13:21 | |
| ruphy | spstarr: I think we should try collaborative coding instead ;-) | 13:21 |
| spstarr | ruphy: Kdevelop 4.x has this no? | 13:22 |
| hardloop | dirk|home: the patch fixed the problem. thanks again :) | 13:22 |
| aseigo | as long as its clear to everyone that it's for those non-totally-obvious patches to core things ... i do want to avoid bogging people down in process, but i think this is better than losing patches on the mailng list | 13:22 |
| dirk|home | hardloop: thanks. sorry for not getting around testing it | 13:22 |
| richmoore2 | i've not seen how i can add a comment to a patch with iyt | 13:22 |
| Chani | I like tossing things up on review board with hte python script, but after that I tend to let them rot there for a while... | 13:22 |
| Join cgoncalves has joined this channel (n=carlos@cr-217-129-232-159.netvisao.pt). | 13:22 | |
| aseigo | richmoore2: it doesnt'work in konqi, only firefox | 13:22 |
| richmoore2 | aseigo: that could be the problem | 13:22 |
| Chani | it is quite useful for seeing whta uncommitted patches are still around. I like not having to wonder about that | 13:23 |
| jpwhiting | richmoore2: and you can only comment from the view that shows the diff also | 13:23 |
| aseigo | richmoore2: you view the diff, then you can click in the margin and add notes... then you click "review" and it gathers up all your notes for the various lines and you can provide a summary | 13:23 |
| aseigo | richmoore2: that part is *really* slick | 13:23 |
| spstarr | aseigo: it doesnt seem to be Web 2.0 'enough' | 13:23 |
| aseigo | in fact, that's my favourite part of it: easy per-line or per-block annotation | 13:23 |
| richmoore2 | cool, i've been using it as a patch viewer then using irc to give feedback so far | 13:24 |
| ruphy | yeah, for me too | 13:24 |
| Chani | per-block? | 13:24 |
| Chani | how do you do per block? I couldn't figure that out | 13:24 |
| aseigo | Chani: you can click and drag in the margin to select multiple lines | 13:24 |
| Chani | agh | 13:24 |
| Chani | ah | 13:24 |
| aseigo | richmoore2: ah.. hehe.. yeah, it's a little less fun that way ;) | 13:24 |
| aseigo | spstarr: agreed... | 13:24 |
| notmart | i also have never discovered how to do per block (probably too lazy) | 13:24 |
| Quit hardloop has left this server ("Verlassend"). | 13:25 | |
| spstarr | aseigo: maybe define the use of the patch viewer to be for 'core' changes and or for new people to get their hands dirty in? | 13:25 |
| aseigo | maybe we should pop an email to them and see what their devel roadmap for r-b is, if nay | 13:25 |
| ruphy | ok, so speed seem the only problem, right? | 13:25 |
| Quit ereslibre has left this server (Remote closed the connection). | 13:25 | |
| spstarr | since you mentioned that a moment ago, i dont think people knew | 13:25 |
| richmoore2 | aseigo: that sounds like a good plan | 13:25 |
| dirk|home | can it send emails? does it have a rss feed? | 13:26 |
| dirk|home | is it possible to script it via a rich client (e.g. a pyqt app?) | 13:26 |
| spstarr | rss feed would be really nice (then plasma can use it) | 13:26 |
| annma | it can send emails | 13:26 |
| aseigo | yeah, rss feeds would be very nice | 13:26 |
| Join ereslibre has joined this channel (n=rafael@84.76.213.0). | 13:26 | |
| Chani | it already emails the list | 13:26 |
| Chani | those emails seem to get kinda long sometimes | 13:27 |
| annma | a bit too much | 13:27 |
| dirk|home | lynx cannot handle it at all though :) | 13:27 |
| Join nihui has joined this channel (n=nihui@58.34.80.2). | 13:27 | |
| aseigo | dirk|home: it has a json interface | 13:27 |
| annma | so there are things that would need to be fixed but do we want to keep using it? | 13:27 |
| * ruphy says yea | 13:27 | |
| annma | I do | 13:27 |
| aseigo | dirk|home: we already use a pythong cli script to post patches directly from the svn | 13:27 |
| richmoore2 | i'd say yes | 13:27 |
| jpwhiting | I think so, yes | 13:28 |
| Chani | yeah, it's certainly better than plain email | 13:28 |
| annma | 5 for | 13:28 |
| Topic spstarr sets the channel topic to "Plasma: KDE4 desktop, panel and application widgetry. Devel wiki @ http://techbase.kde.org/Projects/Plasma | Plasma IRC Meeting IN PROGRESS NOW - http://techbase.kde.org/index.php?title=Projects/Plasma/20080209 | gobby server for the meeting: ruphy.org:5555". | 13:28 | |
| ruphy | any proposal for how to speed it up? | 13:28 |
| aseigo | dirk|home: that in particular is *very* nice as i never have to touch a web browser to post a patch | 13:28 |
| aseigo | mattr: ping? | 13:28 |
| aseigo | oh, he's probably sleeping | 13:28 |
| aseigo | because he's not insane like me ;) | 13:28 |
| ruphy | :P | 13:28 |
| jpwhiting | aseigo: yes, probably | 13:28 |
| dirk|home | we could move it to a faster server though if anyone asks sysadmin@ I guess | 13:28 |
| aseigo | ruphy: i'll bring that up with mattr | 13:28 |
| Chani | I think I'm gonna get annoyed about all hte things that aren't done though. blah. especially since nobody has time/ability to make it work in other browsers | 13:28 |
| richmoore2 | aseigo: is the lack of sleep cause or effect? :-) | 13:28 |
| spstarr | well i went to sleep 2am and got up 8am :) so can mattr :P | 13:29 |
| * aseigo notes that jpwhiting is similarly affected ;) | 13:29 | |
| jpwhiting | aseigo: is he in our or even worse, west coast timezone? | 13:29 |
| aseigo | richmoore2: hm. that's a question best left unasked, i think ;) | 13:29 |
| jpwhiting | aseigo: luckily I'm a morning person | 13:29 |
| aseigo | jpwhiting: texas.. so same | 13:29 |
| Chani | I'm tempted to dig into this python script myself | 13:29 |
| ruphy | notmart: please, use a slightly less saturated and lighter color =) | 13:29 |
| jpwhiting | KO | 13:29 |
| aseigo | Chani: it's not the most beautiful thing in the world.. but i've seen worse | 13:29 |
| notmart | ruphy: ok :) | 13:29 |
| Chani | I don't know much python, so the chances of me actually making it work better aren't high :) | 13:30 |
| * ruphy encourages everyone to have a look at what he writes in the summary, from time to time ;-) | 13:30 | |
| ruphy | Chani: personally I'm more than happy with the web interface | 13:30 |
| aseigo | python is very straight forward. | 13:30 |
| richmoore2 | ruphy: is there an export of some kind that is viewable without a gobby client? | 13:30 |
| richmoore2 | you can pick up the basics of python in a hour or so | 13:30 |
| * spstarr thinks konversation needs a gobby plugin :) | 13:30 | |
| Chani | aseigo: yeah, I've done a few little things and often it just worked how I wanted it to work | 13:30 |
| ruphy | richmoore2: I can do that! | 13:31 |
| spstarr | then you wouldn't need two chat areas | 13:31 |
| ruphy | probably, wait a sec | 13:31 |
| Join nogden has joined this channel (n=nick@p54993D2A.dip.t-dialin.net). | 13:31 | |
| aseigo | ok... let's move on then. | 13:31 |
| Chani | ok | 13:31 |
| aseigo | backporting policy | 13:31 |
| * aseigo is taking the easy topics first to get us rolling ;) | 13:31 | |
| ruphy | richmoore2: no, sorry... but for nex time I'll be able to do that =) | 13:31 |
| aseigo | ruphy: that was your agenda item i think? | 13:31 |
| richmoore2 | ruphy: ok, thanks | 13:32 |
| richmoore2 | aseigo: next on the agenda was libplasma to kdelibs | 13:32 |
| ruphy | spstarr: if eveyone had a gobby client I would have suggested to just have the meeting there | 13:32 |
| ruphy | easier | 13:32 |
| ruphy | aseigo: what makes you think that? ;-) | 13:32 |
| spstarr | :) | 13:32 |
| aseigo | richmoore2: yeah, i rearranged stuff | 13:32 |
| aseigo | ruphy: heh.. it wasn't? =) | 13:33 |
| ruphy | no, well, I just want a policy defined, and maybe let's decide a list of features to be backported | 13:33 |
| Join Riddell has joined this channel (i=jr@kde/jriddell). | 13:33 | |
| ruphy | to me the things are: | 13:33 |
| spstarr | well, no bic/abi changes would be the big one for backport changes :) | 13:33 |
| jpwhiting | and adding new strings | 13:34 |
| jpwhiting | no need to piss off translators ;-) | 13:34 |
| richmoore2 | actually, i'd suggest we do a big backport immediately prior to adopting 4.4 | 13:34 |
| ruphy | - dashboard (+ the new animation) | 13:34 |
| ruphy | - panel config | 13:34 |
| ruphy | - systray (if it's not already) | 13:34 |
| Beineri | ruphy: how about no "list of features to be backported" but some intermim Plasma release soon? :-) | 13:35 |
| richmoore2 | Beineri: yes, that's what i'd prefer | 13:35 |
| aseigo | richmoore2: yes, that seems the least insane thing... however, it'll be harrd on translators, etc | 13:35 |
| ruphy | anything else? | 13:35 |
| aseigo | ah, Beineri beat me to it | 13:35 |
| jpwhiting | and it's on the agenda ;-) | 13:35 |
| ruphy | - oh, and taskbar plasmoid improvements | 13:35 |
| aseigo | hm, why don't we pull those two items together, because they do overlap | 13:35 |
| rabauke | ruphy: panel config seems to be already backported by opensuse | 13:35 |
| aseigo | rabauke: but not to the branch, just to their patches really | 13:36 |
| richmoore2 | rabauke: yes, it's in some distros but not in our svn | 13:36 |
| ruphy | exact | 13:36 |
| aseigo | right now backporting is easy: svn merge | 13:36 |
| ruphy | Beineri: that'd be cool, but actually this is more crucial =) | 13:36 |
| ruphy | Beineri: plus, it's BC | 13:36 |
| aseigo | but it's hard on translators, and it's not binary compat | 13:36 |
| Beineri | rabauke: well, panel config is for me also span optoin and amount of panels ;-) | 13:36 |
| rabauke | well then use their patch | 13:36 |
| ruphy | aseigo: (for /me is easier... git-cherry-pick <commit-nr>) :D | 13:36 |
| aseigo | ;) | 13:36 |
| rabauke | Beineri: is that available in trunk? | 13:36 |
| Beineri | rabauke: and left/center/right | 13:36 |
| richmoore2 | aseigo: i think having a single big day of pain rather than a drip feed would probably be better for them | 13:37 |
| aseigo | rabauke: not yet | 13:37 |
| richmoore2 | we'll be able to backport much less when we go to 4.4 | 13:37 |
| ruphy | agreed | 13:37 |
| * aseigo notes he doesn't plan on copying kicker's left/center/right approach as it was very limiting... | 13:37 | |
| dirk|home | when is the interim plasma release planned? | 13:37 |
| rabauke | so there is no backporting possible yet... :) I was talking about the things that are already backported by someone and using those patches to get them into kde svn | 13:37 |
| ruphy | so, anyone has any other important feature to add to the backport list? | 13:37 |
| dirk|home | a week, a month? a quarter of a year? | 13:37 |
| aseigo | richmoore2: yes, one big day of pain would be better | 13:37 |
| spstarr | yeah, i want my panel diagonal :P | 13:38 |
| aseigo | dirk|home: we haven't gotten to that point on the agenda yet =) | 13:38 |
| ruphy | (in the taskbar improvements there's also the 2-rows layout thing) | 13:38 |
| aseigo | oh... it would be more like this month | 13:38 |
| Beineri | ruphy: some features have to exist first at all :-) | 13:38 |
| aseigo | personally, i think backporting should be limited to important bug fixes | 13:38 |
| ruphy | Beineri: those do... the panel config is at least already decent =) | 13:38 |
| ruphy | containments config and a plasma kcm would be great either, agreed | 13:38 |
| ruphy | but at least it's something | 13:39 |
| randomguy3 | if we have an interim release, then we can limit backports | 13:39 |
| aseigo | i don't really want to see us spend too much time trying to do big feature merges.. both because of the time involved and that it rather violates the idea of the branch | 13:39 |
| aseigo | right | 13:39 |
| ruphy | agreed | 13:39 |
| aseigo | so.. interim release. | 13:39 |
| aseigo | something that works with 4.0 libs | 13:39 |
| ruphy | randomguy3: the only thing the worrries me a it is bc... | 13:39 |
| Beineri | for me the interim release should have the basic features KDE 4.0.0 should have had actually | 13:39 |
| aseigo | it will require bundling up workspace/libs and workspace/plasma at a minimum | 13:39 |
| Chani | hmm. do we have stuff that would *not* work with 4.0? | 13:40 |
| ruphy | and, just backporting commits assures us that no BiC changes go in | 13:40 |
| aseigo | Beineri: an interim release can only have the features that are in trunk/ ;) | 13:40 |
| aseigo | Chani: not yet, no | 13:40 |
| Beineri | (plus the backfixes like behaving plasmoid well with vertical panel and other than 48 point size) | 13:40 |
| randomguy3 | something to consider for the interim release is that there are one or two applets in other modules that would break | 13:40 |
| rabauke | Chani: every clock that uses the new clock-lib | 13:41 |
| dirk|home | how do you plan to make distros swallow an interim release? | 13:41 |
| Beineri | aseigo: in trunk at what time? :-) | 13:41 |
| aseigo | personally, i'd like to see us do a release every 2 months or so .... even after we're out of this "feature critical" phase | 13:41 |
| dirk|home | its the desktop shell itself.. | 13:41 |
| Chani | rabauke: but te clock-lib would be part of hte interim release | 13:41 |
| dirk|home | personally, I'd like to see updates being pushed into 4.0.x (violating feature freeze) rather than done yet another way | 13:41 |
| aseigo | dirk|home: i'm not sure i'm overly concerned about that.. should i be? | 13:41 |
| dirk|home | aseigo: yes | 13:41 |
| richmoore2 | aseigo: that's going to be hard if we're using woc instead of plasma::widgets | 13:41 |
| ruphy | why 'only important bugfixes'? I'd say that the mofe bugfixes go in, the better | 13:41 |
| rabauke | Chani: ah ok, if that is the case they will, I thought you asked about curent 4.0 | 13:42 |
| aseigo | dirk|home: the goal would be to simply make it easy for people to access the latest plasma... | 13:42 |
| spstarr | richmoore: Plasma::Widgets aren't 'going away' they become legacy | 13:42 |
| dirk|home | aseigo: because if the distributors cannot package it properly, users will have a problem getting/installing it, which means that in return you'll get a lot of bugreports | 13:42 |
| Beineri | aseigo: for me 4-6 weeks features work, and 2 weeks stabilizing would be fine if 4.0.3 has some string freeze lift eg | 13:42 |
| dirk|home | aseigo: we have those monthly kde releases, anything easier than that? :) | 13:42 |
| richmoore2 | spstarr: yes, but i suspect most applets etc. will switch pretty quickly | 13:42 |
| notmart | richmoore2: i think all the important backportings should be done before qt4.2, after that it will be really painful | 13:42 |
| aseigo | ruphy: important bugfixes are a sort of "must", while detail stuff is up to the time/effort/etc of the individual imho | 13:42 |
| ruphy | dirk|home: agreed. and you have the problem of c++ plasmoids (almost all for now) and BC | 13:42 |
| spstarr | yeah, they could, I already have begun the process :) | 13:42 |
| randomguy3 | and if plasma-interim is BIC with the kget plasmoid in kdenetwork, for example, what do packagers do about that? | 13:43 |
| dirk|home | well, binary compatibility gaines another dimension with another plasma release | 13:43 |
| dirk|home | because then it has to be checked against 4.0, 4.1 and that other branch | 13:43 |
| dirk|home | or something like that | 13:43 |
| aseigo | dirk|home: those are for branch, right? i'd love to see us do regular tarballs of trunk/ too, but am to afraid of the overhead that would cause to suggest it =) | 13:43 |
| ruphy | aseigo: ok, in case you need to backport something, just ask me, it's a one-liner for me to do that | 13:43 |
| Lure | randomguy3: distros should rebuild (not an issue if they know that they have to) | 13:43 |
| dirk|home | it also makes the release team look silly, because they're doing a hard time planning releases and releasing, and then thhhe core component of KDE just decides to go another way | 13:43 |
| aseigo | randomguy3: yes, that's the big rub indeed. | 13:44 |
| dirk|home | aseigo: we're doing regular tarball releases of trunk! | 13:44 |
| aseigo | dirk|home: ah, we are? that's great, i missed that somewhere... | 13:44 |
| dirk|home | I guess I didn't blog about it :) | 13:44 |
| randomguy3 | Lure: so distros would have to make a once-and-for-all choice, and this would assume no source incompatibility (which I'm not sure we can guantee) | 13:44 |
| aseigo | dirk|home: hehe.. evidently not ;) | 13:44 |
| randomguy3 | I think some symbols have already moved | 13:44 |
| aseigo | randomguy3: yes, they have | 13:45 |
| ruphy | randomguy3: they do.... | 13:45 |
| dirk|home | I really need a secretary that knows how to blog | 13:45 |
| Join jaguilera has joined this channel (n=opsi@unaffiliated/opsidao). | 13:45 | |
| aseigo | Beineri: since the interim release was your agenda item, maybe you could say something about what you'd like to see (process-wise) | 13:45 |
| randomguy3 | so we'd have kdenetwork-4.0.x is either incompatible with kdebase-workspace-4.0.x or with plasma-interim | 13:46 |
| aseigo | dirk|home: oooh... now *that's* a good idea | 13:46 |
| aseigo | randomguy3: perhaps we could package up kget-interim along with plasma-interim... | 13:46 |
| richmoore2 | aseigo: and kdeedu's applets? | 13:46 |
| Beineri | aseigo: backport of the most important features into some 4.0.x release? :-) | 13:46 |
| randomguy3 | aseigo: and quickly get throttled by the packagers :-P | 13:47 |
| notmart | so if it's big there will be the need of a separate kdenetwork-plasma package, if it's source incompatible, well,.. :( | 13:47 |
| dirk|home | sorry, I missed the kget point? | 13:47 |
| notmart | s/big/bic | 13:47 |
| dirk|home | what is the issue with kget? | 13:47 |
| randomguy3 | dirk|home: kget has a plasmoid in kdenetwork | 13:47 |
| dirk|home | and thats a problem because..? | 13:47 |
| rabauke | dirk|home: there is a plasmoid in the package that might not work after the iterim release | 13:47 |
| * ruphy fears that is going to be a whole mess | 13:48 | |
| Beineri | why must be there 4.0 BIC changes to have panel config? isn't the base system good enough and just the gui missing? | 13:48 |
| randomguy3 | dirk|home: if we release a source incompatible plasma, then kdenetwork-4.0.x will be incompatible with it | 13:48 |
| rabauke | so there would have to be a fixed knetwork package | 13:48 |
| Lure | randomguy3: but if we include bic changes to plasma in 4.0.2, then kdenetwork for 4.0.2 can include changes to new plasma | 13:48 |
| ruphy | Beineri: that can be easily done | 13:48 |
| dirk|home | so thats yet another reason for doing sic changes not inside an interim release,but as part of 4.0.x | 13:48 |
| spstarr | Chani: you didnt attend? (add yourself on gobby ;-) | 13:48 |
| ruphy | Beineri: without breaking anything actually | 13:48 |
| Chani | what? | 13:48 |
| aseigo | Lure: that's generally not how x.y release happen =) | 13:48 |
| Chani | spstarr: someone else added me | 13:48 |
| ruphy | spstarr, she's there ;-) | 13:48 |
| spstarr | oh | 13:49 |
| spstarr | :) | 13:49 |
| Beineri | ruphy: same for moving applets on panel and dnd between desktop & panel? | 13:49 |
| ruphy | Beineri: the problem is with an ad-interim release, which will push in also other changes happened in the lib | 13:49 |
| aseigo | Beineri: ok, so that's different then.. backport vs release | 13:49 |
| dirk|home | is it really necessary to break source backward compatbility btw? | 13:49 |
| aseigo | Beineri: that gets us back again to the issue that we'd be backporting string changes ... | 13:49 |
| Lure | aseigo: we could make exception for 4.0.x series for plasma (if benefits of new plasma features are bigger than pain), right? | 13:49 |
| * ruphy would say no | 13:49 | |
| ruphy | aseigo: for string changes we could request an exemption I think... | 13:50 |
| notmart | shittyshit: i'm away for a moment hope to get back in a moment :( | 13:50 |
| notmart | seeya | 13:50 |
| aseigo | Beineri: we can probably avoid BIC changes, hopefully... though it does mean backporting changes to the boxlayout at a minimum, and there have been BIC changes there | 13:50 |
| Beineri | aseigo: ask the translators if they have problems with some strings if they have 3-4 weeks to translate them between to 4.0.x... | 13:50 |
| Beineri | two even | 13:50 |
| richmoore2 | it's sounding impractical to do an interim release to me, backporting some feature improvements seems possible though | 13:50 |
| ruphy | it's 3 or 4 strings I think, not that big issue... | 13:50 |
| ruphy | richmoore2: agreedx | 13:51 |
| Beineri | ruphy: the panel config dialog alone has more ;-) | 13:51 |
| ruphy | well, the problems are just with panel config and taskbar config | 13:51 |
| * aseigo hates that dialog, but that's another matter | 13:51 | |
| Beineri | aseigo: well, you have 4+ weeks to write something better ;-) | 13:51 |
| aseigo | so ... to backport massively ... or to do a full scale interim release | 13:52 |
| Beineri | or 8+ for 4.0.x+1 | 13:52 |
| ruphy | aseigo: if we backport just the single commits, I think we can keep the boxlayout bic... | 13:52 |
| aseigo | you mean BC =) | 13:52 |
| jpwhiting | :) | 13:52 |
| ruphy | yeah, bc | 13:52 |
| ruphy | spstarr: please change the blue... make it lighter | 13:52 |
| Beineri | this shouldn't delay 4.1 development more than required but IHMO there should be something more advanced released before August | 13:52 |
| Join riccardo has joined this channel (n=riccardo@85-18-136-80.fastres.net). | 13:53 | |
| ruphy | riccardo != me, for the records ;-) | 13:53 |
| ruphy | spstarr: danks shön =) | 13:53 |
| spstarr | :) | 13:53 |
| Nick riccardo is now known as goric. | 13:53 | |
| goric | :-) | 13:54 |
| ruphy | ok... so? what are we going to do? /me votes for just backporting | 13:54 |
| Beineri | and the feature list should also be not unlimited, something like suggested in http://lists.kde.org/?l=kde-panel-devel&m=120228833517668&w=2 (for those without gobby :-) | 13:54 |
| Nick jaguilera is now known as opsiAway. | 13:54 | |
| spstarr | WOC is going to cause a split in 4.0.x with 4.1 though | 13:54 |
| * ruphy would really love to do the next meeting entirely on gobby | 13:55 | |
| Chani | the backporting argument sounds persuasive | 13:55 |
| ruphy | ok then, let's do that. agreements/objections? | 13:55 |
| dirk|home | thats why I asked when you want to do an interim release? | 13:56 |
| * jpwhiting agrees | 13:56 | |
| dirk|home | becuase qt 4.4 will be introduced probably within 2 weeks for trunk | 13:56 |
| spstarr | woot | 13:56 |
| aseigo | dirk|home: are we doing that before 4.0.2 is out then? | 13:57 |
| Quit nihui has left this server (Read error: 104 (Connection reset by peer)). | 13:57 | |
| Beineri | dirk|home: nobody is forced to start using its feature immediately for Plasma, or? | 13:57 |
| Chani | btw, I'm probably going to be away from the 17th to the 7th | 13:57 |
| aseigo | dirk|home: maybe it would be good to time those two events together... | 13:57 |
| ruphy | spstarr: the things you wrote are the reasons for backporting, not for interim release ;-) | 13:57 |
| Chani | aseigo: sounds smart | 13:57 |
| aseigo | Beineri: we'll need to start using those new features asap though to be able to make the development window of 4.1 | 13:57 |
| aseigo | we have 10 weeks of feature devel left | 13:58 |
| Chani | once woc hits, I expect things are going to get very BIC :) | 13:58 |
| Quit longh has left this server (Remote closed the connection). | 13:58 | |
| jpwhiting | yes, probably... | 13:58 |
| spstarr | ruphy: er, they are for things you cannot do for backporting | 13:58 |
| richmoore2 | sounds like having a backport day would be a good idea - no changes, just backports | 13:58 |
| dirk|home | Beineri: nobody is forced to, but it might happen | 13:58 |
| aseigo | s,day,weekend, | 13:58 |
| ruphy | spstarr: hmm? | 13:58 |
| richmoore2 | ok, weekend | 13:59 |
| dirk|home | Beineri: I can set up dashbot to check for qt 4.4 dependencies crawling in if anyone asks for that though | 13:59 |
| ruphy | spstarr: translation, stabilizing... those are backportings | 13:59 |
| aseigo | or maybe it'll only take a day.. hm.. yeah, maybe if we're dilligent | 13:59 |
| dirk|home | aseigo: which two events exactly ? | 13:59 |
| dirk|home | aseigo: 4.0.2 release and qt 4.4 switch? | 13:59 |
| spstarr | ruphy: not BIC though | 13:59 |
| aseigo | dirk|home: 4.0.2 being tagged and movign to qt 4.4 | 13:59 |
| Chani | remember, in kdeland a "day" takes 48 hours at least :) | 13:59 |
| dirk|home | the current plan is to go with qt 4.4 beta1 as soon as it is released | 13:59 |
| ruphy | spstarr: yeah, and that's pretty bad! | 13:59 |
| Chani | like bic mondays... :) | 13:59 |
| dirk|home | which is being delayed already for several weeks due to that nokia thing | 13:59 |
| Beineri | Chani: so a month has 1440 hours? :-) | 13:59 |
| spstarr | ruphy: but WOC will begin new bic changes | 13:59 |
| begert | morning :P | 14:00 |
| dirk|home | aseigo: hmm, to make sure that you can backport trunk to 4.0.x branch without breaking something? | 14:00 |
| aseigo | dirk|home: ok... | 14:00 |
| aseigo | heh.. "That nokia thing" yeah.. those details =) | 14:00 |
| richmoore2 | the scripting stuff will be bic due to 4.4 - the trolls fixed a bic in qt | 14:00 |
| dirk|home | aseigo: or why exactly should those two events be synced? | 14:00 |
| ruphy | spstarr: htat's why we should have it in 4.1 | 14:00 |
| aseigo | dirk|home: to keep people writing easily backported changes until then? =) | 14:00 |
| aseigo | anyways.. ok, so backporting major changes seems to be the consensus | 14:01 |
| aseigo | that means: | 14:01 |
| aseigo | a) enumerating which changes to backport (probably not that hard =) | 14:01 |
| Beineri | just for the record, plasma trunk already uses kdelibs trunk api ;-( | 14:01 |
| spstarr | ruphy: well, we will | 14:01 |
| ruphy | just commit small and I'll take care to cherry-pick the commits ;-) | 14:01 |
| aseigo | b) getting blessing from the i18n teams so they don't send hit men out after me | 14:01 |
| aseigo | Beineri: oh, the animations thing. yeah | 14:01 |
| aseigo | for one | 14:02 |
| richmoore2 | lets put a page on techbase listing the features to backport | 14:02 |
| Beineri | aseigo: no, the drag to panel uses something KConfigGroup.regroup() or alike | 14:02 |
| Beineri | reparent iirc | 14:02 |
| cb400f | aseigo: at least one translator is very much for lifting feature/string freeze for plasma :-) | 14:02 |
| annma | richmoore2: yes | 14:02 |
| aseigo | c) scheduling a day or two where we keep plasma in trunk/ static so we can concentrate on backporting stuff | 14:02 |
| dirk|home | aseigo: b) is not a problem if done reasonable time before the actual tagging day | 14:02 |
| spstarr | heh | 14:02 |
| aseigo | dirk|home: yeah, i don't think it'll be a problem. i just want to be sure we give them a heads up... just out of respect for them if nothing else | 14:03 |
| dirk|home | aseigo: d) testing that trunk plasma works against 4.0 kdelibs | 14:03 |
| dirk|home | as in.. compiles | 14:03 |
| dirk|home | can be done by dashbot though | 14:03 |
| ruphy | I'm writing what I propose for a) in the gobby doc | 14:03 |
| aseigo | so... giving them two weeks to translate would mean by the 13th | 14:04 |
| aseigo | for 4.0.2 | 14:04 |
| aseigo | we could instead try for 4.0.3 which would give us mroe time to pick up some of the other panel related features everyone wants | 14:05 |
| Beineri | that doesn't no/not much time to implement the missing 'important' features, or? | 14:05 |
| * aseigo hates how this is turning, yet again, into "make a traditional desktop, fuck the future" development cycle | 14:05 | |
| cb400f | yes, no need to rush.. the important thing is the major distro releases with 4.0 in the spring/early summer | 14:05 |
| ruphy | I've written in the gobby doc what I propose | 14:06 |
| aseigo | cb400f: my only concern is the timing with qt 4.4 landing.. | 14:06 |
| Beineri | aseigo: traditional? drag and drop between desktop and panel and vice versa is the future I thought ;-) | 14:06 |
| * ruphy encourages everyone to have a look | 14:06 | |
| aseigo | if we go for 4.0.3 then it needs to be *before* we commit too hard to any qt 4.4 specific stuff in the code base for things we'd like to backport | 14:06 |
| begert | aseigo: don't h8, retaliate! | 14:06 |
| aseigo | but after 4.0.2 is tagged | 14:06 |
| dirk|home | aseigo: why not going with 4.0.2 and with 4.0.3 ? | 14:06 |
| dirk|home | aseigo: only want to do the backporting work once? | 14:06 |
| aseigo | Beineri: the other things are ;) | 14:06 |
| Quit ereslibre has left this server (Remote closed the connection). | 14:07 | |
| Join ereslibre has joined this channel (n=rafael@84.76.213.0). | 14:07 | |
| rabauke | what about creating a separate branch for "internal backporting use" which does not use qt 4.4? | 14:07 |
| Beineri | ruphy: add moving plasmoids on the panel, very missing | 14:07 |
| aseigo | dirk|home: yes, we could do it twice.. once early next week, then again after 4.0.2 | 14:07 |
| Join apol has joined this channel (n=apol@84.78.178.63). | 14:07 | |
| aseigo | dirk|home: as long as people are fine with us breaking all the rules multiple times =) | 14:07 |
| spstarr | we need to all use git and cherry-pick it seems ;p | 14:08 |
| ruphy | Beineri: added, but you can do that yourself too ;-) | 14:08 |
| spstarr | (not that i've used cherry pick before) | 14:08 |
| * aseigo gives plasma a leather jacket, a motorcycle and some cigarettes ... 'cause it don't play by your rules. ;) | 14:08 | |
| ruphy | spstarr: eheh, I told you. ;-) | 14:08 |
| spstarr | lol | 14:08 |
| ruphy | spstarr: anyway, I can do that, just give me the rev number | 14:08 |
| richmoore2 | aseigo: i think given how people are complaining about the lack of some features we'll need to do that | 14:08 |
| aseigo | so .. two backport days? one for 4.0.2, one for 4.0.3? | 14:09 |
| ruphy | unless hard conflicts show up I can do the merge quite easily | 14:09 |
| richmoore2 | yes | 14:09 |
| spstarr | did the Plasma::Dialog change get merged to branch? | 14:09 |
| dirk|home | aseigo: well, I think its the least painful way, so I'm in favor of breaking the rules | 14:09 |
| * aseigo checks for spstarr | 14:10 | |
| aseigo | spstarr: Plasma::Dialog is in there, yes... | 14:10 |
| spstarr | ok | 14:10 |
| dirk|home | aseigo: but only as long as we don't run into serious regressions ;) | 14:10 |
| dirk|home | the problem with the 4.0.x releases is that they're not well tested before release | 14:10 |
| aseigo | dirk|home: heh. indeed. well, things are pretty happy in trunk/ right now | 14:10 |
| * aseigo nods | 14:10 | |
| Join maxx_k has joined this channel (n=max@p57A7CAD4.dip.t-dialin.net). | 14:10 | |
| ruphy | if you guys give me a hand to find all the rev numbers that need to be backported, I can do all the backports tomorrow, or even tonight | 14:11 |
| aseigo | tomorrow is more sane for me, as i'll be sleeping much of the rest of the day today ;) | 14:11 |
| aseigo | but yeah.. | 14:11 |
| begert | dirk|home: I would think 4.0.x releases would have more focus on bug/security fixes, and not feature releases | 14:12 |
| spstarr | aseigo: has the plasma resizing code been fixed? or you planning to revert/refactor (or you did this already and it got absorbed into one of my trunk builds :-)? | 14:12 |
| annma | maybe we need to send a mail about that to the list ruphy | 14:12 |
| ruphy | it's ok, just remain a bit more, and help me find all the commits for a given element | 14:12 |
| aseigo | so we need to identify all the features to backport, get it done before the 13th, and then schedule another day for 4.0.3 | 14:12 |
| ruphy | 'find-the-commit' marathone | 14:12 |
| aseigo | spstarr: resizing code? | 14:12 |
| spstarr | for panel | 14:12 |
| aseigo | again, resizing code? | 14:12 |
| Beineri | aseigo: so that's about 4 weeks for 'missed features'? | 14:12 |
| spstarr | changing the size/resizing the panel | 14:12 |
| aseigo | Beineri: for those that aren't in trunk/ already | 14:13 |
| aseigo | spstarr: i wasn't aware that it was broken | 14:13 |
| spstarr | I remember you disliking the dialog popup or something? | 14:13 |
| ruphy | annma: we can ask for permissions later, after all, for me I have to 'git svn dcommit' to get all the changes in svn, but before locally I've got everything | 14:13 |
| CIA-31 | 03tcoopman * r772716 10applets/trunk/extragear/plasma/applets/frame/frame.cpp: set the default config entries. | 14:14 |
| annma | ruphy: I thought to help you identify the ones to be backported | 14:14 |
| ruphy | oh, ok =) | 14:14 |
| * ruphy announces the 'spot-the-commit-marathone' | 14:14 | |
| aseigo | annma: that would be awesome | 14:14 |
| spstarr | I'll assume whats in trunk then is blessed :) | 14:14 |
| aseigo | hey! who's writing code instead of at the meeting! ;) | 14:14 |
| spstarr | heh | 14:14 |
| Chani | hrm. | 14:15 |
| Chani | aseigo: do you have plams to work on the panel in hte near future? | 14:15 |
| tmske | :) | 14:16 |
| dirk|home | Bethat is true | 14:16 |
| dirk|home | begert: that is true, thats why we talk about bending the rules a little | 14:16 |
| begert | gotcha | 14:16 |
| annma | OK, shall we move to next point? | 14:18 |
| jpwhiting | I think so | 14:18 |
| ruphy | yup | 14:18 |
| annma | => a libplasma to kdelibs strategy | 14:18 |
| aseigo | begert: btw, flow layout -> commit at will =) | 14:18 |
| * ruphy writes a summary on the gobby doc | 14:18 | |
| begert | :) | 14:18 |
| Quit boom1992 has left this server (Remote closed the connection). | 14:18 | |
| aseigo | yeah, so that one scares the living daylights out of me ;) | 14:18 |
| jpwhiting | hehe | 14:18 |
| aseigo | as it means hard BC requirements and making sure all our crazy changes work for apps in general | 14:19 |
| ruphy | aseigo: just 1 sec, why is c) needed? | 14:19 |
| jpwhiting | aseigo: would it be easier after WoC? | 14:19 |
| aseigo | not that we aren't doing the latter and have the former as a goal for 4.1 | 14:19 |
| aseigo | ruphy: if you don't need it, then we don't have to... just figured it would be easier | 14:19 |
| Join boom1992 has joined this channel (n=lukas@pD9E1938F.dip.t-dialin.net). | 14:19 | |
| aseigo | jpwhiting: impossible before really | 14:19 |
| begert | http://matt.rogers.name/r/96/s/6/ it loks good with tasks | 14:20 |
| Quit boom1992 has left this server (Remote closed the connection). | 14:20 | |
| begert | *looks | 14:20 |
| aseigo | that's also when we will want to look at whether we wish to move things like Plasma::Package into GHNS2 | 14:20 |
| jpwhiting | :) | 14:20 |
| ruphy | aseigo: I'll need it just if people are more concentrated on helping me spotting the right revs ;-) | 14:20 |
| annma | yes! | 14:20 |
| jpwhiting | I'd better get that cleaned up soon then... | 14:20 |
| ruphy | spstarr, can I cut the "reasons for interim release to be part of 4.0.x release series" part? | 14:21 |
| spstarr | do what you like :) | 14:21 |
| aseigo | jpwhiting: which cleaned up? ::Package? | 14:21 |
| aseigo | or GHNS2? oh right you're working ont hat | 14:21 |
| jpwhiting | aseigo: no, knewstuff2 | 14:21 |
| jpwhiting | :) | 14:21 |
| jpwhiting | aseigo: yes, and I could definitely use a core dev to bounce some design ideas off of some time if you get a spare minute... ;-) | 14:22 |
| aseigo | right.. so the big question is do we go for a move into kdelibs for 4.1 or for 4.2 and i'm really hesitant to commit to 4.1 for that out of general conservatism | 14:23 |
| dirk|home | ruphy: I wrote that btw | 14:23 |
| richmoore2 | 4.2 | 14:23 |
| aseigo | jpwhiting: absolutely | 14:23 |
| mattr | 4.2 | 14:23 |
| spstarr | aseigo: 4.2 | 14:23 |
| aseigo | yay! | 14:23 |
| spstarr | we're way to hot of code right now | 14:23 |
| aseigo | 4.2 it is ... | 14:23 |
| Chani | ok, moving alongthen | 14:23 |
| aseigo | spstarr: agreed | 14:23 |
| jpwhiting | does that mean amarok 2.0 will not be possible until after 4.2? ;-) | 14:23 |
| rabauke | what benefits does a user have from going into 4.1? | 14:23 |
| leinir | jpwhiting: Yes, it does | 14:23 |
| jpwhiting | meh, ok | 14:23 |
| dirk|home | ruphy: was there a reason for removing it? it is a good idea to document the reasons that where foudn for a given decision | 14:23 |
| leinir | (well, without a kdebase dependency at any rate) | 14:24 |
| richmoore2 | jpwhiting: they can use a local copy | 14:24 |
| jpwhiting | as long as I can build it locally before then :) | 14:24 |
| aseigo | so 4.1 will be our "if we were in kdelibs" dry run, still in workspace.. and we'll shift to kdelibs with everyone's blessing once 4.1 is out | 14:24 |
| jpwhiting | richmoore2: exactly! | 14:24 |
| spstarr | aseigo: you think 4.1 will be enough time to get in all the functionality? including media centre stuff etc | 14:24 |
| dirk|home | what does that have to do with amarok? | 14:24 |
| aseigo | leinir: why can't you do what you're doing now and just ship with a version of libplasma included? e.g. the 4.1 v? | 14:24 |
| dirk|home | amarok can (and should) build against workspace | 14:24 |
| aseigo | dirk|home: they are using it. | 14:24 |
| jackrabbit | aseigo: that sounds right, because I think we'll need the time | 14:24 |
| jpwhiting | dirk|home: ah, true | 14:24 |
| ruphy | dirk|home: oh, you wrote that, sorry | 14:24 |
| dirk|home | not everything has to be in kdelibs | 14:24 |
| ruphy | dirk|home: I thought it was spstarr :\ | 14:24 |
| jackrabbit | aseigo: if we rush it then we're stuck with what we got until kde5 | 14:25 |
| aseigo | spstarr: i have several meetings this month re: MCE stuff... so, we'll see it | 14:25 |
| dirk|home | it is just that if its in workspace, it should be optional (because of windows/mac) | 14:25 |
| spstarr | good stuff | 14:25 |
| dirk|home | but there is no reason whatsoever for not building against workspace | 14:25 |
| leinir | aseigo: It's not really an optimal solution, but sure, it works :) | 14:25 |
| dirk|home | so amarok2 is not concerned with 4.1 | 14:25 |
| dirk|home | not having libplasma in kdelibs | 14:25 |
| ruphy | dirk|home: I removed it because it was quite confusing, especially given that we didn't write reasons for the backporting strategy | 14:25 |
| aseigo | jackrabbit: i'm less concerned about that and more cncerned about not getting something solid for app devs | 14:25 |
| jpwhiting | dirk|home: but amarok2 is concerned with mac/windows ;-) | 14:25 |
| Join boom1992 has joined this channel (n=lukas@pD9E1938F.dip.t-dialin.net). | 14:25 | |
| aseigo | win/mac is fine. we build and work there | 14:26 |
| jpwhiting | ok, sorry, moving on... | 14:26 |
| ruphy | aseigo: I'd really like to finish off the GUIs before merging Package into kdelibs... | 14:26 |
| * aseigo notes that the new locolor detection is x11 only though. would need someone to port that to other platforms for him if anyone cares too | 14:26 | |
| dirk|home | aseigo: but it doesn't make sense to build workspace on windows ;) | 14:26 |
| spstarr | ahh yes.... | 14:26 |
| randomguy3 | dirk|home: which is why amarok currently holds a copy of libplasma internally | 14:26 |
| jpwhiting | dirk|home: but they can build workspace/lib/plasma fine currently | 14:26 |
| ruphy | aseigo: also because it needs some more love... which I'm pretty confident will be BC, but better not to rush on such things :-) | 14:27 |
| spstarr | ruphy: we need oxygen love for Plasma ;P | 14:27 |
| * Mek is btw working on porting lots of plasma/workspace stuff to OSX :) | 14:27 | |
| * jpwhiting hugs Mek | 14:27 | |
| spstarr | Mek: we didnt forget about that :-) | 14:27 |
| ruphy | spstarr: everything needs my love :-) | 14:27 |
| spstarr | haha | 14:27 |
| aseigo | begert: hm. woudl be nice if flowlayout kep things top aligned, even if there is tons of space? | 14:27 |
| aseigo | ok.. roadmap... | 14:28 |
| aseigo | hm.. actually, no.. | 14:28 |
| aseigo | april sprint first. | 14:28 |
| ruphy | lol :D | 14:28 |
| aseigo | what's the status on that? | 14:28 |
| jpwhiting | I'll try to attend remotely if needed | 14:28 |
| * aseigo , honestly, hasn't been keep up with the planning on that | 14:29 | |
| jpwhiting | I'm trying to do less and less plasma stuff so I can focus on khns more... | 14:29 |
| CIA-31 | 03begert * r772729 10workspace/trunk/KDE/kdebase/workspace/libs/plasma/layouts/flowlayout.cpp: | 14:29 |
| CIA-31 | Re-work of the relayout() function so that it actually works. | 14:29 |
| CIA-31 | screenshot of using flowlayout with tasks applet: http://matt.rogers.name/r/96/s/6/ | 14:29 |
| dirk|home | randomguy3: why are they doing that? | 14:29 |
| begert | top aligned? | 14:29 |
| dirk|home | randomguy3: do they want to run plasma on mac/windows? | 14:29 |
| dirk|home | randomguy3: or just integrate with plasma on mac/windows? | 14:29 |
| jpwhiting | dirk|home: they run plasma inside amarok | 14:29 |
| ruphy | me and sebas are working out the last details, I'm waiting to have concrete dates to get in touch with the hotel | 14:30 |
| ruphy | how many days do we want? | 14:30 |
| leinir | dirk|home: amarok 2's context browser is a plasma view | 14:30 |
| richmoore2 | given the distance some people are travelling i'd say 3-5days | 14:31 |
| * spstarr will attend from IRC :) | 14:31 | |
| dirk|home | leinir: okay.. tough issue ;( | 14:31 |
| ruphy | ah, btw, we should probably want to rent a car to ease the transports... if annma (or darktears) come with one, and we rent one (5 places should be ok) we should be fine =) | 14:31 |
| ruphy | for obvious reasons I don't have mine yet ;-) | 14:31 |
| aseigo | public transit that bad? | 14:31 |
| ruphy | now, dates... how many days do we want it to last? | 14:32 |
| annma | not sure I can get a suitable car | 14:32 |
| * aseigo doesn't drive abroad | 14:32 | |
| Chani | oh yeah, it'd be nice to know dates. I'm in the awkward position of not being able to use my credit card online for some raeson, so I have to get my dad to buy plane tickets for me, and I think he might be off in england or something | 14:32 |
| aseigo | (personal policy_ | 14:32 |
| spstarr | ruphy: can you pull north america closer to Europe? k, thanx, love shawn. :p | 14:32 |
| * Chani can't drive at all | 14:32 | |
| Quit cgoncalves has left this server ("Konversation terminated!"). | 14:32 | |
| aseigo | spstarr: lol | 14:32 |
| jpwhiting | hehe | 14:32 |
| aseigo | yes, we need firm dates. that's the #1 thing here | 14:32 |
| Join rui has joined this channel (n=rui@e180042206.adsl.alicedsl.de). | 14:32 | |
| annma | ruphy: what dates are you looking for with sebas? | 14:32 |
| aseigo | i'll need to book tickets as well, we need to ask the e.V. board for financial aide (and they can be completely pricks ;) | 14:33 |
| annma | lol | 14:33 |
| ruphy | aseigo: unfortunately it's bad to reach milano | 14:33 |
| aseigo | ruphy: hm.. ok... | 14:33 |
| aseigo | ruphy: where would people fly into then? | 14:34 |
| ruphy | (we will be at the external part of it... and unfortunately it sucks there :( ) | 14:34 |
| ruphy | aseigo: milano malpensa | 14:34 |
| * aseigo notes that more remote place are actually great for these events... even it's a bit more post-fight travel, the lack of distraction == focus | 14:34 | |
| ruphy | aseigo: from there the transportation is pretty good | 14:34 |
| Chani | ruphy: airport code? | 14:34 |
| ruphy | there's a train directly from the airport to a station which is 2-3 mins from my house | 14:35 |
| ruphy | Chani: MXP | 14:35 |
| Chani | ah, good. | 14:35 |
| Chani | the cheap flight I saw goes to that one | 14:35 |
| Chani | iirc | 14:35 |
| ruphy | anyway, after we get into milano, at night, (10-15 min by car) there public transportation is very good | 14:36 |
| spstarr | ruphy: stream the event :) | 14:36 |
| * annma has to go, will someone log the rest for me please? | 14:36 | |
| aseigo | ruphy: ok, so it's pretty easy for me to get there | 14:36 |
| jpwhiting | annma: if I have to... ;-) | 14:36 |
| annma | thanks jpwhiting | 14:36 |
| ruphy | annma: sure, we'll send the summary to the panel-devel ml =) | 14:36 |
| annma | OK | 14:36 |
| annma | thanks, sorry about that | 14:37 |
| aseigo | straight through frankfurt... ~830 euro | 14:37 |
| ruphy | annma: btw, to answer your question... | 14:37 |
| ruphy | annma: ~14 of april | 14:37 |
| annma | yes | 14:37 |
| annma | OK | 14:37 |
| Chani | ok, so.. dates? | 14:37 |
| aseigo | ruphy: hm. if it's only 10-15 min, can we take a taxi for that part? | 14:37 |
| ruphy | aseigo: the house is on three floors, + a small garden but with a very nice gazebo... we can have smaller groups working closer toghether if we want to | 14:38 |
| aseigo | ruphy: great =) | 14:38 |
| aseigo | yeah, dates are useful... if we don't know them yet, that's the part we'll need to get asap | 14:38 |
| aseigo | annma: see you =) | 14:38 |
| Chani | yeah. can't book flihts without dates :) | 14:38 |
| * annma was waiting for the dates | 14:38 | |
| richmoore2 | yes, i have to give a seminar on security some time in march, so dates would be very useful | 14:39 |
| * spstarr notes it would be nice if KDE e.V could get google to pay for videoconferencing for people not able to attend sprints ;) | 14:39 | |
| mattr | yeah, good luck with that. ;) | 14:39 |
| Quit annma has left this server (Remote closed the connection). | 14:39 | |
| ruphy | aseigo: it's way better if we rent a car, maybe a big one... cheaper and easier ;-) | 14:39 |
| Quit rawicki has left this server (Remote closed the connection). | 14:40 | |
| spstarr | I will be @ aKademy 2008 so, more plasma discussions will occur then im sure also. | 14:40 |
| ruphy | plus, we are more free to go in there... and I can choose good resturants to go into also for lunch =) | 14:40 |
| Chani | is this gonna be over the weekend? how many days? | 14:40 |
| aseigo | ruphy: hm.. ok.. i am somewhat sceptical of cheaper if it's 15 min drive there, and nothing's easier than catching a cab ;) though yes, certainly not as convenient for other driving around. | 14:40 |
| aseigo | spstarr: absolutely | 14:41 |
| spstarr | :-) | 14:41 |
| aseigo | spstarr: as for vid conf.. that would be great. we could probably set something up ad-hoc over the 'net... but "real" vid conf would be nice | 14:41 |
| richmoore2 | spstarr: no, akademy 2008 will be a plasma free zone :-) | 14:41 |
| aseigo | haha | 14:42 |
| aseigo | yes, NO PLASMA PLEASE! signs everywhere | 14:42 |
| ruphy | aseigo: not that easy, italy, or europe in general, is not that good for that... except if you live in the downtown | 14:42 |
| jpwhiting | right | 14:42 |
| spstarr | though, how much does KDE e.V pay for in terms of assistance? hotel/plane? im curious | 14:42 |
| dirk|home | how about an audio conference for a start? ;) | 14:42 |
| ruphy | lol :D | 14:42 |
| aseigo | ruphy: hehe. you've not been to n. america then? ;) we put the meaning into the phrase "need a car" | 14:42 |
| ruphy | :D | 14:42 |
| aseigo | dirk|home: that's much easier with skype, e.g. yes | 14:42 |
| jpwhiting | spstarr: http://ev.kde.org/rules/reimbursement_policy.php | 14:42 |
| ruphy | well, in sf it was extremely easy and cheap to get one | 14:42 |
| spstarr | i dont mind splitting a hotel room with 4 people, just get cot beds etc | 14:42 |
| aseigo | spstarr: 80% is standard, more in case of need | 14:43 |
| spstarr | jpwhiting: looking | 14:43 |
| spstarr | 80% is more than generous ! | 14:43 |
| aseigo | ruphy: s.f. is an odd place ;) | 14:43 |
| jpwhiting | yep | 14:43 |
| ruphy | i see ;-) | 14:43 |
| * notmart is back, woo | 14:43 | |
| aseigo | anyways.. ok.. dates <-- harping | 14:43 |
| aseigo | ruphy: when might we have solid dates to work with here? | 14:43 |
| * richmoore2 will have to leave in 15 (looking at a flat) | 14:43 | |
| aseigo | which days almost doesn't matter. just having them is important | 14:43 |
| ruphy | we can decide that now if we want | 14:44 |
| jpwhiting | we want! | 14:44 |
| aseigo | sure. for me: any time in april. | 14:44 |
| ruphy | agreed ;-) | 14:44 |
| Chani | are the dates gonna be 11th-14th or something? I saw someone say "~14" up there and I'm not sure what that meant | 14:44 |
| ruphy | so.... good dates seem to be between 10 and 18 of april | 14:44 |
| ruphy | if the google doc says the truth | 14:44 |
| * ruphy checks it back | 14:44 | |
| Chani | yeah | 14:45 |
| ruphy | ok | 14:45 |
| Chani | hmm. the jetlag is gonna suck | 14:45 |
| ruphy | bad dates are 10 and 19 | 14:45 |
| Quit hdevalence has left this server ("Konversation terminated!"). | 14:46 | |
| spstarr | very nice, with 80% that is more than enough to help me go to aKademy 2008, now i just need to hack more libplasma ;p | 14:46 |
| Join tue has joined this channel (n=tue@port351.ds1-ly.adsl.cybercity.dk). | 14:46 | |
| aseigo | Chani: welcome to my world | 14:46 |
| * aseigo says "nice" http://lists.kde.org/?l=kde-commits&m=120256037907209&w=2 | 14:46 | |
| ruphy | plus, I want to give some time to chani and annma, which are the ones who have those bad dates... | 14:46 |
| Chani | ruphy: my dates are only suggestions | 14:46 |
| ruphy | ok | 14:46 |
| aseigo | ruphy: want to do it over the weekend then? often easier for people to make that... | 14:47 |
| ruphy | aseigo: agreed, easier for me too | 14:47 |
| spstarr | +*** New widget independent image canvas concept and implementation :)))))))) | 14:47 |
| aseigo | ruphy: and then we can fly in/out mid-week, which tends to be cheaper | 14:47 |
| ruphy | how many days? | 14:47 |
| aseigo | 4? | 14:47 |
| aseigo | arrive thursday, fri-mon, leave tue/wed or something like that | 14:47 |
| ruphy | ok, 4 full days + 2 of travel | 14:47 |
| Chani | what's the usual amount of time between arrival and things starting? | 14:47 |
| Chani | ah | 14:47 |
| aseigo | Chani: personally, i aim for one night's sleep. but some people need more than that | 14:48 |
| * aseigo will die early for all this, he is sure | 14:48 | |
| Chani | hehehe | 14:48 |
| ruphy | aseigo: ah, I'd say 4 full days... | 14:48 |
| Chani | aseigo: at least it's for a good cause ;) | 14:48 |
| Chani | I'm not entirely sure why I'm shortening my lifespan by being here in china... | 14:49 |
| spstarr | erm, shouldn't we move onto the roadmap now? :) | 14:49 |
| Chani | anyways. hmm. | 14:49 |
| ruphy | Chani: eheh :D | 14:49 |
| Chani | 11-14 it is then | 14:49 |
| Join nf2 has joined this channel (n=norbert@vie-062-116-122-020.dsl.sil.at). | 14:49 | |
| richmoore2 | Chani: because it's the only country that's an anagram of your name | 14:49 |
| aseigo | great. ruphy, can you announce that on the list then? =) | 14:49 |
| ruphy | ok, 11-14... arrivals 10, departures 15 | 14:49 |
| ruphy | ok | 14:49 |
| aseigo | ok.. so: http://techbase.kde.org/Projects/Plasma/4.1_Roadmap | 14:49 |
| ruphy | anything special that we need setup? | 14:49 |
| spstarr | ruphy: well, wireless for those who are attending? ;) | 14:50 |
| dirk|home | a magnetic field to contain the plasma | 14:50 |
| spstarr | LOL | 14:50 |
| ruphy | lol :D | 14:50 |
| aseigo | honestly, i don't see anything on there that causes concern | 14:50 |
| ruphy | well, like... I have a projector we can use, or, a shared folder... | 14:50 |
| aseigo | i'm sure we'll get much more than that done too | 14:50 |
| ruphy | spstarr: obvious ;-) | 14:50 |
| richmoore2 | in addition to the stuff on the roadmap so far, i'll be adding support for the rest of the script engine api to the qtscript support | 14:50 |
| aseigo | dirk|home: heh.. yeah, that's the whole joke behind the Plasma::Containment class, actually ;) | 14:50 |
| jpwhiting | aseigo: I will also try to get the background wallpaper setup stuff pulled out into a widget for frame applet to use in it's config | 14:51 |
| aseigo | plasma: architected for humour | 14:51 |
| * Chani has already bought a power adaptor thingy for italy | 14:51 | |
| jpwhiting | which means default desktop will also get picture-of-the-day for free hopefully in the process :) | 14:51 |
| aseigo | jpwhiting: that'll also be important for providing a generic background config (e.g. one that also lets people switch containments) | 14:51 |
| richmoore2 | ruphy: one thing we're always short of is plug sockets | 14:52 |
| * aseigo has 4 of those power adaptor things. | 14:52 | |
| Beineri | aseigo: all from Trolltech? :-) | 14:52 |
| aseigo | yes, plugs and network.. we're brutal on both | 14:52 |
| aseigo | Beineri: hehe.. no, only 2 | 14:52 |
| jpwhiting | aseigo: containment choice is wanted in that dialog? | 14:52 |
| spstarr | hmm, i guess i need a power converter for aKademy also...hmm maybe a new laptop battery too.. | 14:52 |
| aseigo | Beineri: i like NOT getting electrocuted, so i have other, safer ones | 14:52 |
| ruphy | richmoore2: need foreign->european adaptor?? | 14:52 |
| aseigo | Beineri: i like my guests use the tt ones ;) | 14:52 |
| richmoore2 | ruphy: i have 2 | 14:52 |
| jpwhiting | aseigo: you'll have to explain how that will look to me later | 14:52 |
| ruphy | ok, what do you need then? ;-) | 14:53 |
| aseigo | jpwhiting: no, that dialog will end up inside the other one | 14:53 |
| aseigo | jpwhiting: sure =) | 14:53 |
| Chani | I don't seem to be follwing my raodmap stuff so well. I'm avoiding the applet browser, just got back into twitter, and now I'm distracted by svg weirdness... | 14:53 |
| jpwhiting | ah, ok | 14:53 |
| aseigo | jpwhiting: but we can discuss that later on | 14:53 |
| jpwhiting | yep | 14:53 |
| richmoore2 | ruphy: generally we have so many people pluging stuff in that we need lots of extension cables so there are enough sockets | 14:53 |
| * spstarr distracts Chani with shiny objects | 14:53 | |
| Quit goric has left this server ("using sirc version 2.211+KSIRC/1.3.12"). | 14:53 | |
| richmoore2 | ruphy: and the adaptors mean that often stuff can't physically fit | 14:53 |
| Chani | ooooh... shiiiiny.... | 14:53 |
| spstarr | hah | 14:54 |
| * mattr helps | 14:54 | |
| mattr | spstarr: quick! hold up larger shiny objects. ;) | 14:54 |
| spstarr | hehe | 14:54 |
| * richmoore2 points at the moon applet | 14:54 | |
| ruphy | lol :D | 14:54 |
| Chani | richmoore2: and we need to get the good grounded ones, not those dangerous ones that take a grounded plug but aren't grounded themselves | 14:54 |
| mattr | lol | 14:54 |
| ruphy | lol^2 :°°D | 14:54 |
| aseigo | if there are going to be other n. americans there i can bring a n. american power bar and we can plug it in using an adaptor.. anyways | 14:54 |
| * Chani has found out the hard way that they're bad | 14:55 | |
| ruphy | sorry, what have we agreed on for the libplasma->kdelibs? not to rush? | 14:55 |
| richmoore2 | 4.2 | 14:55 |
| mattr | ruphy: 4.2 is the consensus | 14:55 |
| Chani | aseigo: well, too late for me | 14:55 |
| aseigo | ok, i don't see anything really discussing worthy on the roadmap. we have another 6 weeks or so before it has to be finalized anyways | 14:55 |
| Chani | ok | 14:55 |
| Chani | data engines then? | 14:56 |
| * mattr notes there are 6 patches in review-board that could use reviewing | 14:56 | |
| aseigo | well, we've been at this for almost 2 hours now | 14:56 |
| spstarr | Design time | 14:56 |
| CIA-31 | 03begert * r772740 10workspace/trunk/KDE/kdebase/workspace/libs/plasma/layouts/flowlayout.cpp: Top Align...let items be as large as they can be. | 14:56 |
| ruphy | htanks | 14:56 |
| Chani | damn | 14:56 |
| mattr | (7 if you count toma's mailody test patch) | 14:56 |
| Chani | ok, so only aseigo and spstarr have seen my thoughts on dataengines | 14:56 |
| aseigo | if people are cool with continuing ... i'd like to suggest a break, come back at 10 past... | 14:56 |
| ruphy | mattr: btw, sorry for the predefined-letter way of closing bugs, but that's what kbugbuster provides ;-) | 14:56 |
| spstarr | break for breakfast :) | 14:57 |
| Chani | aseigo: sure | 14:57 |
| jpwhiting | yes | 14:57 |
| * aseigo makes coffee. | 14:57 | |
| * begert scrambles eggs | 14:57 | |
| Nick spstarr is now known as spstarr_breakfas. | 14:57 | |
| * Chani wishes there was caffiene in the room | 14:57 | |
| * ruphy calls the hotel | 14:57 | |
| Chani | ok, I'm gonna go get some of that dodgy hot water, make tea, and hope it doesn't kill me ;) | 14:57 |
| aseigo | mattr: my older patch there is just waiting for monday as it's highly BIC | 14:57 |
| mattr | ruphy: you should learn to be creative. :) | 14:58 |
| Chani | it'll be less dodgy than the 6-month-old fruits tea | 14:58 |
| mattr | aseigo: ah, ok | 14:58 |
| ruphy | mattr: you're telling an oxygen artist that he's not creative?!? :P | 14:58 |
| aseigo | and my runner patch seems to be a bit on the esoteric side for people ;) | 14:58 |
| * aseigo will just commit that one | 14:58 | |
| tmske | ok. I'll have to go, but I have some quick remarks for if you have some more time: shouldn't kde-apps have a plasmoids category and kde-look plasma themes? | 14:58 |
| mattr | ruphy: just because you're creative with paint and ink and digital pixel does not mean you are also creative with words. :) | 14:59 |
| ruphy | this is the hotel, btw: http://www.hotellatorretta.it/Italiano/NF-home_ntorretta_01.htm | 14:59 |
| ruphy | you probably want the english version ;-) http://www.hotellatorretta.it/Ing/Inglese/NF-home_ntorretta_01.htm | 14:59 |
| CIA-31 | 03aseigo * r772741 10workspace/trunk/KDE/kdebase/workspace/libs/plasma/abstractrunner.cpp: automatic rate limiting of runners: mark ill performing runners as slow, but let speed runners marked as slow back into the main thread pool. | 14:59 |
| aseigo | mattr: and i think i've peer reviewed all the other patches there | 15:00 |
| Join litb has joined this channel (n=litb@p54AED6FA.dip.t-dialin.net). | 15:00 | |
| litb | hello all | 15:00 |
| mattr | aseigo: cool. | 15:01 |
| mattr | aseigo: everything still working ok for you then? | 15:01 |
| Quit rabauke has left this server ("Konversation terminated!"). | 15:04 | |
| * richmoore2 is late, see you later guys | 15:04 | |
| ruphy | ok, great | 15:04 |
| ruphy | hotel is ok | 15:04 |
| Quit leinir has left this server (Remote closed the connection). | 15:06 | |
| * aseigo waves to richmoore2 | 15:06 | |
| aseigo | mattr: yeah, it's back to being a bit slow at times though.. *shrug8 | 15:06 |
| jackrabbit | are we still talking about the plasma-dev sprint? | 15:06 |
| Chani | jackrabbit: we're having a break | 15:07 |
| jpwhiting | jackrabbit: it's a break | 15:07 |
| aseigo | jackrabbit: we're in a meeting break, so you can talk about whatever =) | 15:07 |
| * aseigo thinks we have consensus that it's a break | 15:07 | |
| Chani | hehehe | 15:07 |
| jpwhiting | aseigo: btw, handles annoy me | 15:07 |
| Chani | oh yeah | 15:07 |
| jackrabbit | all opposed? :) | 15:07 |
| Chani | damn, I forgot to put that on the agenda | 15:07 |
| jpwhiting | I think they need a quadrant detection? | 15:07 |
| Chani | there are several thinga about handles that are driving me nuts. | 15:08 |
| jpwhiting | so when you put an applet in the top-left quadrant of the screen, the handle buttons should show on the bottom-right instead of top-right | 15:08 |
| Join leinir has joined this channel (n=leinir@amarok/usability/leinir). | 15:08 | |
| jpwhiting | or top-left sometimes... | 15:08 |
| Chani | the placement of the buttons and the z-order, basically | 15:08 |
| aseigo | jpwhiting: yes, that's been discussed a few times... | 15:08 |
| jpwhiting | thought so | 15:08 |
| aseigo | it would also be great if the handle resized itself rather than applied the transform matrix to itself | 15:09 |
| aseigo | and only applied the temporary transform matrix to the applet | 15:09 |
| Chani | z-order is retarded, somehow when I mouseover an applet it *sinks* below anything it overlaps, which often means I can't reach those buttons | 15:09 |
| jackrabbit | Chani: I get that too | 15:09 |
| aseigo | yes, z-order is another item that needs fixing... | 15:09 |
| Chani | hmm. | 15:09 |
| aseigo | right now we z-order everything consistenly ..... except active applets ;) | 15:09 |
| aseigo | so fixing it should be relatively easy | 15:09 |
| Chani | somewhere I had a patch for more complicated button placement, but I think it's bitrotted too much now | 15:09 |
| Chani | do we? | 15:10 |
| jackrabbit | I think icons should have the lowest z-order | 15:10 |
| Chani | it doesn't feel consistent :) | 15:10 |
| * ruphy invites everyone to read mail | 15:10 | |
| aseigo | Chani: yes.. containments, toolbox, applets, etc all get consistent z order values | 15:10 |
| Nick spstarr_breakfas is now known as spstarr. | 15:10 | |
| Chani | I think icons should die, but that's just me ;) | 15:10 |
| ruphy | see you richmoore2 | 15:10 |
| aseigo | Chani: we just don't do it for active/selected/dragged widgets so it's all for nothing ;) | 15:10 |
| spstarr | <-- reads /scroll | 15:10 |
| aseigo | jackrabbit: they should be treated as any other object | 15:10 |
| * aseigo notes his coffee is just about done... which means it must be nearly break time over | 15:11 | |
| Quit miga_ has left this server (Remote closed the connection). | 15:11 | |
| spstarr | :-) | 15:11 |
| Join hdevalence has joined this channel (n=harry@bas9-toronto12-1088716929.dsl.bell.ca). | 15:11 | |
| Chani | 23:11 | 15:11 |
| Chani | yup | 15:11 |
| ruphy | aseigo: it would be nice if handles would appear from the transparent border of the default bg that just expands | 15:11 |
| notmart | Chani: i think they should survive, but oly as a mean to launch app, not to be a desktop view | 15:11 |
| spstarr | 10:11am | 15:11 |
| jpwhiting | aseigo: except we have these silly desktop actions that apply only to icons (align vertically, horizontally, etc.) | 15:11 |
| ruphy | aseigo: it would actually even make it have some sense ;-) | 15:11 |
| Chani | I've been avoiding any attempts at a folder plasmoid, hoping I could wait for woc | 15:12 |
| aseigo | ruphy: of course, not all items have the background, but yeah... | 15:12 |
| aseigo | Chani: ditto | 15:12 |
| jpwhiting | k, back on task? | 15:12 |
| notmart | ruphy: si it means that a "normal" default background and a different one with borders expanded would be needed? | 15:12 |
| Chani | I'm concerned about that panel config thing getting backported. didn't someone say that it'll introduce incompatible config file stuff? | 15:13 |
| aseigo | ruphy: i'm RSVP'ing to your email with a "yes, need a room" | 15:13 |
| * Chani checks emnail, sees nothing | 15:13 | |
| * aseigo bangs the gavel | 15:13 | |
| aseigo | Chani: it's still going through the censors ;) | 15:13 |
| spstarr | hehe | 15:13 |
| Chani | got it | 15:14 |
| Chani | ok. dataengines | 15:14 |
| aseigo | i think we only have time for a couple of items | 15:14 |
| Chani | darn | 15:14 |
| jpwhiting | yes, probably | 15:14 |
| aseigo | so ... | 15:14 |
| aseigo | we can come back to the other items in less formal meets (the process stuff was most important for this meeting imo) | 15:15 |
| jpwhiting | yes | 15:15 |
| aseigo | so let's take two fairly easy ones, and one hard one | 15:15 |
| ruphy | Chani: | 15:15 |
| jpwhiting | and almost all the implementation ones can be just small (the devs involved) meetings | 15:15 |
| aseigo | keyboard shortcuts, menus in containments and mutable dataengines | 15:15 |
| aseigo | jpwhiting: yep | 15:16 |
| * aseigo "mmmmm"s over his coffee .. | 15:16 | |
| Chani | hehe | 15:16 |
| aseigo | so .. keyboard shortcuts. this is pretty important. | 15:16 |
| Chani | yes, it is | 15:16 |
| jpwhiting | ok, keyboard shortcuts we are trying to achieve accessibility | 15:16 |
| Chani | and I forgot to prepre for that one. damn. | 15:16 |
| aseigo | people are asking for "alt-f1" which obviously is completely broken w/respect to the plasma model if we just copied kicker | 15:16 |
| jpwhiting | make everything usable without a mouse, correct? | 15:16 |
| aseigo | right | 15:16 |
| * spstarr notes not all keyboard have a Windoez logo key ;p | 15:16 | |
| aseigo | so, my proposal is this: | 15:17 |
| spstarr | (which annoys me in kwin effects since i cant change some!) | 15:17 |
| Chani | with my laptop mouse dying, I'm very aware of the lack of keyboard stuff | 15:17 |
| jpwhiting | so applet selection, shortcuts for moving, resizing, etc. | 15:17 |
| aseigo | - a shortcut manager in libplasma | 15:17 |
| aseigo | - each applet can register a shortcut | 15:17 |
| ruphy | that'd be lovely | 15:17 |
| aseigo | - the user can define the shortcut for that applet | 15:17 |
| jpwhiting | and handles have shortcuts for their methods also | 15:18 |
| aseigo | the challenge is: | 15:18 |
| ruphy | and... bang! top-level-window ;-) | 15:18 |
| aseigo | jpwhiting: yes.. | 15:18 |
| aseigo | there are very few global accels available | 15:18 |
| * jpwhiting continues to kick the dead horse... | 15:18 | |
| aseigo | so ... we'll probably also need a two-stage system | 15:18 |
| aseigo | we can accomodate alt-f1 type stuff, but plasma will also need a "application global" shortcut that gives focus to the libplasma application (seli will hate us for that one, i'm sure ;) | 15:19 |
| aseigo | and then we can use local shortcuts from there | 15:19 |
| aseigo | so one might assign alt-f5 for instance... | 15:19 |
| jpwhiting | hehe, yes, probably | 15:19 |
| aseigo | and then ctrl+p for panel | 15:19 |
| Chani | I've discovered a little keyboard issue: applets in the panel cannot get text focus. try adding a note, you can't type in it | 15:19 |
| jpwhiting | aseigo: ah, but which panel? | 15:19 |
| aseigo | and getting to the panel by the keyboard would then be alt+f5, ctrl+p | 15:19 |
| aseigo | jpwhiting: whichever one you assign it to | 15:20 |
| * jpwhiting is just playing devils advocate | 15:20 | |
| Chani | aseigo: ctrl-f12 should also focus plasma desktop, I assume | 15:20 |
| begert | I might be way off base here, but we will need an applet equivalent of Alt-Tab ? | 15:20 |
| hdevalence | thanks for the help | 15:20 |
| aseigo | once picked, then we can provide other shortcuts for things like the handles, etc | 15:20 |
| hdevalence | err | 15:20 |
| jpwhiting | begert: yes, probably | 15:20 |
| aseigo | begert: i think we will need to allow one to tab through widgets yes.. | 15:20 |
| Chani | yes | 15:20 |
| begert | cool | 15:20 |
| aseigo | so, e.g. alt-f5, p, tab tab tab | 15:21 |
| aseigo | that's an a11y requirement, actually | 15:21 |
| Chani | alt+f5 is very close to alt+f4 | 15:21 |
| notmart | maybe pressing altf1 a toplevel window is opened similar to alt tab that says what every shortcut is and is also clickable? | 15:21 |
| Chani | given the number of typos I', m making right now, I don't like f5 :) | 15:21 |
| aseigo | Chani: sure, it's jsut an example | 15:21 |
| randomguy3 | but we need to distinguish between tabbing through applets and tabbing through widgets contained in applets | 15:21 |
| jpwhiting | Chani: you can change it on yours, don't worry | 15:21 |
| * aseigo decides to make the windows key the plasma key. | 15:22 | |
| spstarr | noooooooo | 15:22 |
| aseigo | ;) | 15:22 |
| jpwhiting | lol | 15:22 |
| spstarr | I dont have one :P | 15:22 |
| aseigo | spstarr: no keyboard for you then ;) | 15:22 |
| jackrabbit | aseigo: isn't it already the amarok key? | 15:22 |
| * Chani has done alt-f4 instaed of ctrl-f4 many times while global shortcuts were stuck | 15:22 | |
| jpwhiting | aseigo: or use that meta key that none of us NA'ers have | 15:22 |
| Chani | hmm | 15:22 |
| spstarr | aseigo: unless i can map a Fn key to a letter | 15:22 |
| spstarr | Fn + P for Plasma :P | 15:22 |
| aseigo | hehe.. we'll arm wrestle for it ;) | 15:22 |
| jpwhiting | ok, back on topic, sorry... | 15:22 |
| Chani | aseigo: I thought the windows key is used as a meta key? | 15:22 |
| * aseigo phones up logitech and suggests they start shipping keyboard with a cashew key | 15:22 | |
| spstarr | haha | 15:22 |
| jpwhiting | rofl | 15:22 |
| Join fred84 has joined this channel (i=fred79@host76-139-dynamic.60-82-r.retail.telecomitalia.it). | 15:23 | |
| spstarr | "Press the cashew" | 15:23 |
| Chani | win+p? :) | 15:23 |
| spstarr | if i can map Fn + P im good | 15:23 |
| notmart | we need to begin to sell keyboards with a key with the plasma logo on it :D | 15:23 |
| jpwhiting | aseigo: we can just ship stickers of cashews for ppl to put on their windows key ;-) | 15:23 |
| aseigo | win+p is cool... | 15:23 |
| aseigo | notmart: yes... | 15:23 |
| aseigo | absolutely... | 15:23 |
| jpwhiting | cashew+p is cooler ;-) | 15:23 |
| Chani | jpwhiting: get some orange nail polish and mod it ;) | 15:24 |
| begert | I would think ctrl-f12 to show desktop, then tab, tab, tab to cycle applets? | 15:24 |
| aseigo | mac has the flower (i miss open/closed apple, btw), window has the flag, we'll have the cashew | 15:24 |
| jpwhiting | Chani: can't stand the stuff | 15:24 |
| aseigo | begert: doesn't work for panels, doesn't work for multiple containments, etc | 15:24 |
| dani_l | okay, let's take the default amarok global shortcut :) (which is win+p) | 15:24 |
| * ruphy still can't believe that the thread "KDE being misspelled as KD in transcript of Linux Foundation interview with Linus Torvalds" got more than 20 answers O_O | 15:24 | |
| aseigo | ruphy: yeah, but they were all light hearted =) | 15:24 |
| jpwhiting | dani_l: seriously? | 15:24 |
| ruphy | aseigo: eheh, yeah ;-) | 15:25 |
| aseigo | kraft dinner! | 15:25 |
| Chani | ok, back on topic! :) | 15:25 |
| * ruphy is still wondering what the heck i that | 15:25 | |
| aseigo | ok.. so no one has issues with that proposed plan? great | 15:25 |
| jpwhiting | ruphy: at least it wasn't asking for the global replacement of the letter K to some sanscrit thingy ;-) | 15:25 |
| aseigo | ruphy: macaroni and cheese in a box | 15:25 |
| * Beineri can't believe ruphy is talking here about not public threads | 15:25 | |
| leinir | dani_l: No it's not! It's [super][p] - just because your dialogue says it's [win][p] doesn't make that our choice ;) | 15:25 |
| Chani | aseigo: yeah, your proposal is generally what I was thinking | 15:25 |
| * jpwhiting agrees | 15:25 | |
| dani_l | leinir: lol | 15:25 |
| * ruphy agrees too | 15:25 | |
| spstarr | :P | 15:26 |
| aseigo | ok.. menu handling in containments | 15:26 |
| jpwhiting | um, the ui for picking shortcuts wont that just go into the keybindings kcm? | 15:26 |
| aseigo | this one's fun | 15:26 |
| * ruphy , being italian, would rather not imagine how that would taste like | 15:26 | |
| Chani | menu handling? | 15:26 |
| ruphy | Beineri: c'mon dude ;-) | 15:26 |
| aseigo | so someone *finally* requested it: they wanted "the k menu on left click, and window list on right click" | 15:26 |
| aseigo | ugh | 15:26 |
| Chani | ahh, that | 15:27 |
| aseigo | the bigger problem here, of course, is that we have code in DefaultDesktop that really needs to be shared, but does not belong in Containment | 15:27 |
| Chani | I used to use that feature a lot on my desktop. one menu per button | 15:27 |
| aseigo | (for menus that is) | 15:27 |
| leinir | About that amarok shortcut, mind, i do believe we could be convinced to select another one as default for amarok 2 - since the p meant playlist, and that is not exactly true any longer, we need really to find another shortcut for showing/hiding the amarok window... thus leaving [super][p] free for plasma :) | 15:27 |
| ruphy | woot :D | 15:27 |
| jpwhiting | aseigo: yes | 15:27 |
| aseigo | so my proposal is this: | 15:27 |
| aseigo | Plasma::Menu | 15:27 |
| Chani | aseigo: have you seen the BR that proposes a floating mini-containment that can pop up by the mouse? | 15:28 |
| ruphy | aseigo: hmm... what would it do? | 15:28 |
| aseigo | which will let us write plugins that either the contianment or the user can pull in an associate with left/middle/right/etc (gesture?) | 15:28 |
| ruphy | Chani: top-level window plasmoids? I already have the design | 15:28 |
| aseigo | Chani: yeah... | 15:28 |
| jpwhiting | aseigo: similar to windows shell extensions? | 15:28 |
| aseigo | ruphy: no, she's talking about replacing menus with a plasmoid thingy | 15:29 |
| aseigo | jpwhiting: sort of... | 15:29 |
| spstarr | hmm | 15:29 |
| ruphy | oh | 15:29 |
| jpwhiting | hmm, interesting | 15:29 |
| ruphy | aseigo: hmm.... don't we want to mix that up with extenders? | 15:29 |
| ruphy | ereslibre: ping, btw ;-) | 15:29 |
| aseigo | i'd like to avoid putting any UI assumptions in it | 15:29 |
| aseigo | essentially just a "show at (x,y)" along with a loading mechanism | 15:29 |
| Chani | aseigo: not exactly replacing, because you wouldn't need the desktopp showing to summon it | 15:29 |
| ruphy | ok | 15:29 |
| aseigo | oh, and some context information that it can use (e.g. which containment, applet, etc0 | 15:29 |
| aseigo | so that if people want they can make little pie menus | 15:30 |
| aseigo | or popup entire windows | 15:30 |
| aseigo | or whatever | 15:30 |
| ruphy | aseigo: how would that relate with extenders? extenders will be a subclass? | 15:30 |
| Join wirr has joined this channel (n=wirr@i59F5C297.versanet.de). | 15:30 | |
| jpwhiting | ah | 15:30 |
| ereslibre | ruphy: pong | 15:30 |
| aseigo | ruphy: extenders are a completely different idea | 15:30 |
| notmart | uhm, so different? | 15:31 |
| aseigo | ruphy: those are for applets to get more space temporarily to show information (e.g. the clock's calender, the device notifier's device listing, etc0 | 15:31 |
| ruphy | aseigo: ah, right, they probably are more related to Plasma::Dialog, right? | 15:31 |
| aseigo | ruphy: the applet populates those | 15:31 |
| aseigo | right | 15:31 |
| ruphy | ok | 15:31 |
| aseigo | once we have WoC i'll be adding a generic interface to a standardize form of Plasma::Dialog in Applet | 15:31 |
| aseigo | so you can just request "your" Extender and populate it | 15:32 |
| Join whitman_ has joined this channel (n=whitman@host86-128-208-57.range86-128.btcentralplus.com). | 15:32 | |
| ruphy | ereslibre: nothing, I thought you would have been interested... you know, extenders... | 15:32 |
| aseigo | and everything is handled for you otherwise (including how it shows up, where it shows up, etc) | 15:32 |
| ruphy | ok | 15:32 |
| ereslibre | ruphy: hehe yeah... is a pity i cannot concentrate... tuesday statistics exam :( | 15:32 |
| crazy | aseigo: are there any plans to make kickoff themable ? and a bit more 'plasma style' ? | 15:32 |
| ruphy | ereslibre: good luck! =) | 15:32 |
| ereslibre | heh thx :) | 15:32 |
| notmart | so Applet will draw in a toplevel window that it would have drawn if it would have more space | 15:32 |
| ruphy | crazy: yeah, raptor :P | 15:33 |
| Quit apol has left this server (Remote closed the connection). | 15:33 | |
| spstarr | :) | 15:33 |
| aseigo | crazy: i don't have any such plans. the suse people (e.g. Beineri) have a number of nice patches that can make it a lot better | 15:33 |
| Join apol has joined this channel (n=apol@84.78.178.63). | 15:33 | |
| ruphy | which actually still needs a maintainer... | 15:33 |
| ruphy | mandriva is pretty interested in making that better too | 15:33 |
| * aseigo wants to see the bold text headings go away and get replaced with the same "line with text under, right justified" they have in kickoff in opensuse 10.3 | 15:33 | |
| Beineri | aseigo: are you thinking of something other than the bottom bar? :-) | 15:33 |
| crazy | ruphy: be sure once raptor work I won't ven build kickoff ever again =) ( I hate it that much you can't imagine that :P ) | 15:34 |
| hdevalence | i was asking about something the other day and I was told that it was one of the topics. I have a 128px vertical panel [widescreen++] and unfortunately the stuff like battery icon etc scaled to 128x128 :( is there a way to make them go side-by-side? | 15:34 |
| Quit whitman has left this server (Nick collision from services.). | 15:34 | |
| Nick whitman_ is now known as whitma. | 15:34 | |
| * Chani ywans | 15:34 | |
| Nick whitma is now known as whitman. | 15:34 | |
| * aseigo puts "build time dependency on kickoff in raptor" on his todo for crazy ;) | 15:34 | |
| aseigo | ok... so no objections there, moving on to the Annoyingly Hard One | 15:35 |
| crazy | aieeee =) | 15:35 |
| aseigo | mutable data engines | 15:35 |
| Chani | ok :) | 15:35 |
| spstarr | the dirty truth about dataengines | 15:35 |
| ruphy | ouch! | 15:35 |
| spstarr | ;) | 15:35 |
| * ruphy would love an xmlrpc dataengine | 15:36 | |
| spstarr | warning! this is ___ SENSORED ___ | 15:36 |
| ruphy | .... so? :D | 15:37 |
| aseigo | spstarr: Chani: wish to air your desires? | 15:37 |
| * Chani looks at aseigo | 15:37 | |
| aseigo | haha | 15:37 |
| Chani | oh, I thought you were typing | 15:37 |
| aseigo | it's a mexican standoff | 15:37 |
| Chani | lol | 15:37 |
| Chani | ok, so | 15:37 |
| spstarr | Desires | 15:37 |
| Chani | I had a big long email about this but I was shy and didn't send it to the list | 15:38 |
| spstarr | Parameterization of dataengines | 15:38 |
| spstarr | instead of "foo|bar|goo" | 15:38 |
| spstarr | need a sane way to pass data back and forth between dataengine <-> applet | 15:38 |
| Chani | what I'd like most of all is a function in DataEngine that takes a qvariant or something, so that I can shove data at the engine | 15:39 |
| aseigo | let's define that a bit better before things get confusing | 15:39 |
| spstarr | connectSource cannot set [datasource, key, value] | 15:39 |
| aseigo | "pass data" ==> pass query data | 15:39 |
| aseigo | spstarr: nore should it *Ever* be allowed to | 15:39 |
| notmart | yeah: a little bit lost :D | 15:39 |
| Chani | yeah, there's also this issue that source names are starting to turn into long strings of information | 15:39 |
| spstarr | aseigo: well, the abusure of Q_PROPERTY is fugly | 15:40 |
| aseigo | spstarr: that would, seriously, fuck things up so badly i'm not even going to consider allowing direct manipulation of DataEngine data from outside the engine | 15:40 |
| aseigo | we can provide a way to request changes, maybe, but not directly | 15:40 |
| aseigo | that's not the only other choice | 15:40 |
| spstarr | so, then what do you propose? :) this is the meeting for that | 15:40 |
| Join apol_ has joined this channel (n=apol@84.78.178.63). | 15:40 | |
| notmart | Chani: so it's needed a way to separate the source name and the actual query, that it's a little bit blurred now | 15:40 |
| Join Eren has joined this channel (n=eren@88.231.191.127). | 15:40 | |
| aseigo | we really should avoid encouraging engines to abuse the *data store* as a way to get data from the applets as well | 15:40 |
| aseigo | because, again, that really fucks things up. how do you map that to the "one data, many visualizations" pattern? answer: you can't | 15:41 |
| Chani | I see this as two distinct cases: wanting to send an engine info for internal use (like a password) and wanting to send an engine data for it to pass on to hte outside world, so that the apllet doesn't need to know how | 15:41 |
| spstarr | aseigo: thats difficult for online services applets | 15:41 |
| aseigo | spstarr: not at all | 15:41 |
| spstarr | i can confine the 'type' of data which the ions do right now | 15:41 |
| aseigo | spstarr: "online service" is the right start though | 15:41 |
| notmart | aseigo: so dataengine will be always read only? | 15:42 |
| aseigo | personally, i think we should add a generic (e.g. hidden behind API) mechanism for applets to pass additional query information to a source request | 15:42 |
| * aseigo ponders why people see things in binary when it's computers that are stuck in 0s and 1s | 15:42 | |
| aseigo | notmart: is that the only other choice? | 15:42 |
| notmart | uhm, don't know :) | 15:43 |
| aseigo | that mostly solves the weatherengine issues | 15:43 |
| jackrabbit | aseigo: the subject is mutable dataengines but has the *problem* been defined? | 15:43 |
| Chani | aseigo: are you thinking of passing such information at the same time or something that can be done whenever? | 15:43 |
| * begert wishes I did not try and move my panel around :( | 15:43 | |
| aseigo | jackrabbit: yes, there are two sets of use cases: | 15:43 |
| jackrabbit | I'm not sure what we're trying to do here | 15:43 |
| aseigo | a) a source being requested needs a phrase, not just a word. so ... "validate Calgary" | 15:44 |
| * ruphy points out that for the meeting... in the lowest floor there's a sauna we can use, 3-4 at time... ;-) | 15:44 | |
| aseigo | which means that there is a syntax, which is the annoying part: | 15:44 |
| aseigo | - each engine needs to implement a tokenizer | 15:44 |
| * Chani just created a new document on gobby with her email | 15:44 | |
| aseigo | - each visualization needs to know how that engine expects it to be formatted | 15:44 |
| Chani | ruphy: oooh | 15:45 |
| aseigo | sauna! | 15:45 |
| Chani | ruphy: is there a hot tub too? :) | 15:45 |
| aseigo | b) there is some desire to have data sinks | 15:45 |
| aseigo | personally, i don't think (b) belongs in DataEngine | 15:45 |
| aseigo | so, e.g. a way to generically write a new twitter | 15:45 |
| fregl | I'd like to have a data sink ;) | 15:46 |
| ruphy | Chani: not in that house :( | 15:46 |
| Chani | aseigo: the reason I want it in dataengine is that my engine already understands how to deal with this kind of data, so it's a tiny extra bit of code for me there | 15:46 |
| fregl | answer vocabulary question → evaluate | 15:46 |
| aseigo | _personally_ i think that should be exposed via another interface completely... | 15:46 |
| Chani | aseigo: a separate DataSink class? | 15:46 |
| * spstarr really, really dislikes tokenization handling | 15:46 | |
| jackrabbit | DataFuelTank | 15:47 |
| Chani | aseigo: why? | 15:47 |
| * ruphy would love to see an easy way for plasmoids to query web services via XML-RPC and SOAP | 15:47 | |
| ruphy | that would dramatically increase the number of plasmoids | 15:47 |
| randomguy3 | aseigo: one that can be implemented by the same class as the data engine, if that makes sense? | 15:47 |
| notmart | so for instance twitter would have a data engine to download the updates and a DataSink to post updates.. hmm | 15:47 |
| aseigo | fregl: could that be done with paramaterized sources though? sort of like how a web service would do it? | 15:47 |
| fregl | aseigo: how do web services do it? | 15:47 |
| fregl | I'm just getting started with plasma... | 15:47 |
| aseigo | ruphy: well, if we do a nice simple sourcename + query impl for data engine, then that becomes rather easy | 15:48 |
| Quit apol has left this server (Nick collision from services.). | 15:48 | |
| Chani | aseigo: what sort of interface are you thinking of? | 15:48 |
| Nick apol_ is now known as apol. | 15:48 | |
| fregl | I would like to get the string from say a text edit to be able to provide a response, so I guess possible | 15:48 |
| aseigo | the *challenge* with adding query to sourcename is this: do we allow one to modify the query? that's going to be the natural desire... if so ... how do we maintain the "one data, many visualizations" pattern | 15:49 |
| spstarr | aseigo: it gets messy when you have to keep track of *more* than one datasource at a time , keeping them unique etc | 15:49 |
| aseigo | that's essentially what fregl wants: a data source, that can react to changes based on updated queries | 15:49 |
| aseigo | spstarr: precisely | 15:49 |
| spstarr | which is where im ripping my hair out :) | 15:49 |
| aseigo | spstarr: well, it's not so much trakcing the multiple sources, it's tracking their relationship to visualizations | 15:50 |
| spstarr | yes | 15:50 |
| aseigo | tracking multiple sources is actually fairly trivial | 15:50 |
| aseigo | detail oriented, but trivial | 15:50 |
| Chani | aseigo: when i was pondering this, I first wanted to be able to reconfigure and existing source, but after writing code I decided it was better to ditch the source and reconnect with different setttings | 15:50 |
| Quit uwolfer has left this server (Remote closed the connection). | 15:50 | |
| aseigo | Chani: writing code on which side.. engine or applet? | 15:50 |
| spstarr | well, yes/no, my madness of ions makes that not so trivial :) | 15:50 |
| aseigo | Chani: because for the applet, it'd be nice to just interact with the source... | 15:51 |
| spstarr | since im the only crazy one to do it so far | 15:51 |
| Chani | aseigo: engine iirc | 15:51 |
| Nick apol is now known as apol_. | 15:51 | |
| randomguy3 | so: are we considering whether adding query parameters to a source changes all instances of that source, or only the ones with those parameters? | 15:51 |
| * randomguy3 is slightly lost | 15:51 | |
| Chani | aseigo: the applet just does a disconnect/reconnect when anything changes | 15:51 |
| aseigo | Chani: right.. if it's added to engine properly, though, maybe it's not so bad.. e.g. you get an updateSource with both the source and the current query params | 15:51 |
| Nick apol_ is now known as apol. | 15:51 | |
| Chani | the function has a horrid name though. downloadSomething | 15:52 |
| aseigo | Chani: which sucks for applet developers | 15:52 |
| Chani | I forget uit | 15:52 |
| randomguy3 | applet1 connects to source1 | 15:52 |
| aseigo | the trivial thing for applet developers would be to just respond to incoming dataUpdated calls | 15:52 |
| randomguy3 | applet2 connects to source1 with parameter foo=bar | 15:52 |
| spstarr | randomguy3: not so simple :) | 15:52 |
| randomguy3 | does that change applet1's source1? | 15:52 |
| spstarr | applet1 connects to mainsource which connects to source1. | 15:52 |
| Chani | aseigo: then the engine will have to intelligently handle two source connections with different params. maybe kinda like it handles different update intervals, I dunno | 15:52 |
| aseigo | as for actual sending of data, e.g. twitters, that really does need its own class.. and that needs to be though out a bit more than i've put to it i think | 15:52 |
| Join uwolfer has joined this channel (n=uwolfer@kde/developer/uwolfer). | 15:53 | |
| aseigo | e.g. we may end up havng a sort of specialized class of problems that can be summarized as, "send this data here to that service there" | 15:53 |
| Chani | randomguy3: that's why I changed my mind and wanted separate sources for such things | 15:53 |
| ruphy | this meeting is so fucking long... o.o | 15:53 |
| aseigo | in which case, we may go for a completely different scheme than with engines, where we have a centralized registry of services that accept data (a sort of switchboard) | 15:54 |
| spstarr | aseigo: I need to disconnect 'dead' sources though and its not too trivial when im generating so many different sources :) | 15:54 |
| Chani | aseigo: but I don't understand why you think it should be separated out so much | 15:54 |
| aseigo | spstarr: from the applet side? | 15:54 |
| spstarr | yes | 15:54 |
| Chani | I haven't thought through the DataSink idea well enough myself | 15:54 |
| aseigo | Chani: because the design pattern is *incompatible* | 15:54 |
| notmart | but maybe some times the query and an update could be very blurred, if querying modifies something in the server would be considered a query? an updated? | 15:54 |
| Quit cheko has left this server (Remote closed the connection). | 15:54 | |
| aseigo | seriously, look at the entire concept behind DataEngine: | 15:54 |
| aseigo | * simplified, generic access to varied data sets | 15:55 |
| Quit uwolfer has left this server (Remote closed the connection). | 15:55 | |
| aseigo | * one source, multiple visualizaitons | 15:55 |
| aseigo | * no assumptions on what the visualization is | 15:55 |
| aseigo | * timing, resource allocation, etc all handled for you | 15:55 |
| Join uwolfer has joined this channel (n=uwolfer@62.48.114.50). | 15:55 | |
| aseigo | that just gets completely raped as soon as you start adding write services into it | 15:55 |
| randomguy3 | so, what doesn't fit this pattern: | 15:56 |
| spstarr | multiple sources <-> multiple visualizations ;p | 15:56 |
| notmart | but if two visualizations asks for slightly different data it would be kept one source? made two sources? | 15:56 |
| Chani | I guess I've been looking at it as a small extra feature of engines | 15:56 |
| randomguy3 | (1) sending updates (eg: twitter) | 15:56 |
| aseigo | there's no reason to add a jumble of crap to that when we can have a nice, clean separate interface | 15:56 |
| randomguy3 | (2) sending commands (eg: nowplaying - play/pause etc) | 15:56 |
| aseigo | have you ever considered that there may be data sinks that have no need for a dataengine? | 15:56 |
| Chani | aseigo: I don't understand how adding one little function is so bad :) | 15:56 |
| Chani | no, I haven't, that's a very valid point | 15:56 |
| Join apokryphos has joined this channel (n=francis@opensuse/board/apokryphos). | 15:56 | |
| aseigo | Chani: it's not one little function, though. | 15:57 |
| spstarr | aseigo: we need some sort of method in DataEngine to pass 'internal' query information to engines, but that really is 'writing' though | 15:57 |
| aseigo | Chani: it's quite a bit of code to do it right | 15:57 |
| Chani | aseigo: why not? | 15:57 |
| aseigo | there's nothing that says you can't meld your engine/sink at the hip and share code and what not | 15:57 |
| aseigo | hell, your sink could request the engine, or vice versa if need be | 15:57 |
| Chani | hmm. | 15:57 |
| aseigo | spstarr: no, it's not writing | 15:57 |
| fregl | so engine and sink would communicate in which way? | 15:57 |
| aseigo | spstarr: it's parameterization | 15:57 |
| aseigo | those are very different things | 15:58 |
| jackrabbit | having a datasink would be a great feature for the soliddevice engine | 15:58 |
| aseigo | one is actually passing data, the other is defining how the response should look like | 15:58 |
| spstarr | aseigo: an example is when i pass WINDFORMAT to the engines they 'adjust' themselves accordingly and return different data back to the applet. | 15:58 |
| Chani | fregl: well, the sink can *get* info from the engine quite easily | 15:58 |
| spstarr | per source | 15:58 |
| Chani | given its nature | 15:58 |
| fregl | Chani: right | 15:58 |
| Chani | jackrabbit: how so? | 15:58 |
| randomguy3 | spstarr: but couldn't the engine provide both and allow the applet to select the appropriate one? | 15:58 |
| aseigo | spstarr: personally i think WINDFORMAT is crackrock ;) you should just put multiple wind sources and visualizations can connect to the one they want | 15:59 |
| spstarr | randomguy3: I'd overflow the dataengine source limit | 15:59 |
| aseigo | what limit is that? | 15:59 |
| Chani | spstarr: why don't you offer a sorce for each wind format? | 15:59 |
| jackrabbit | Chani: it would allow you to use solidcontrol to control things, like eject a optical disc | 15:59 |
| aseigo | s,source,data key, | 15:59 |
| Chani | oh | 15:59 |
| spstarr | aseigo: well, at this right I might have 100 keys just for _one_ place :) | 15:59 |
| Chani | there's a limit? | 15:59 |
| aseigo | jackrabbit: right | 15:59 |
| aseigo | spstarr: and? | 15:59 |
| notmart | i'm a little bit lost: if two applets will asks for thw weather of two locations it would still required to create two souces, right? | 15:59 |
| spstarr | well, it adds memory usage? | 16:00 |
| Chani | jackrabbit: mmmm | 16:00 |
| spstarr | notmart: they are independent of one another | 16:00 |
| jackrabbit | Chani: and the possibilities are much greater once we get to solidnetwork[control] | 16:00 |
| aseigo | spstarr: that's where you have to sit down and ask yourself: "what data really matters? what data should be split out into separate sources all together?" etc. | 16:00 |
| notmart | spstarr ok :) | 16:00 |
| Chani | spstarr: do you really need to have all sources existing all the time? | 16:00 |
| spstarr | aseigo: im fine with killing Q_PROPERTY fuglyness and 'exporting' all the wind formats in the datasource | 16:00 |
| aseigo | and we are, after all, talking 100s of bytes here, not even Ks | 16:00 |
| aseigo | er, KBs | 16:01 |
| Join apol_ has joined this channel (n=apol@84.78.178.63). | 16:01 | |
| spstarr | Chani: well, yes | 16:01 |
| spstarr | because users can dynamically change their minds :) | 16:01 |
| Chani | aseigo: mmkay, so what does DataSink need, other than the ability to accept data? | 16:01 |
| Chani | spstarr: but sources can be created ondemand, just by connecting to them | 16:01 |
| aseigo | Chani: need to define the service (e.g. Twitter) just as we do with engine | 16:01 |
| * aseigo notes that there's probably no real reason one couldn't MI engine and sink | 16:01 | |
| aseigo | well, no.. because sink will also be a qobject | 16:02 |
| Chani | MI? | 16:02 |
| aseigo | so.. composition then. anyways | 16:02 |
| Chani | oh, n/m | 16:02 |
| aseigo | multiple inherit | 16:02 |
| jackrabbit | sendQuery(QString function, QVariant param1 . . .) | 16:02 |
| spstarr | ok i will drop the Q_PROPERTY stuff in trunk.. which will break my ABI/BC but thats fine, nobody uses these parts yet :) | 16:02 |
| aseigo | so... sth like ... | 16:02 |
| spstarr | but i still think we do need a way to pass additional query information to a source request | 16:03 |
| Join sebbar has joined this channel (n=sebbar@p5B1573B4.dip.t-dialin.net). | 16:03 | |
| aseigo | Plasma::Service *twitterService = service("twitter"); | 16:03 |
| Chani | aseigo: ok. so the DatSink has a name, like the data source. gotta have that to call it up from the manager (can hte engine manager manage these too?) | 16:03 |
| jackrabbit | twitterService->sendQuery("Post", QString("We had a Plasma Meeting today.")) | 16:03 |
| spstarr | oh yes aseigo: we also discussed the fuglyness of my KConfigGroup nastyness also | 16:03 |
| aseigo | twitterService->setProperty("username", "foo") | 16:04 |
| Chani | setProperty? | 16:04 |
| aseigo | twitterService->send( ...) <-- something | 16:04 |
| spstarr | aseigo: you mean use Q_PROPERTY in this case? | 16:04 |
| Chani | aseigo: nonono, how do you know there's only one username? | 16:04 |
| spstarr | or setProperty becomes a Plasma API method? | 16:04 |
| aseigo | Chani: ah, here, you see, is why i used Service and not Sink | 16:04 |
| jackrabbit | spstarr: setProperty becomes a plasma method | 16:04 |
| Chani | also, you need a password :) | 16:04 |
| aseigo | DataSink will provide a factory for Service | 16:04 |
| spstarr | ok | 16:05 |
| jackrabbit | or DataService | 16:05 |
| Chani | but that's just a detail | 16:05 |
| aseigo | so each caller gets their own Service | 16:05 |
| spstarr | we should document this on gobby? | 16:05 |
| Chani | so... hmm... | 16:05 |
| aseigo | and DataSink manages those Services that belong to it | 16:05 |
| spstarr | if we're going to have Plasma::Service etc | 16:05 |
| Chani | yeah, someone start copying this stuf for us :) | 16:05 |
| ruphy | aseigo: they shouldn't be all QString. e.g. rpcService->sendQuery("methodName", QList("arg1", "argn")); | 16:05 |
| aseigo | at least, that's my first draft thoughts from earlier in the week | 16:05 |
| aseigo | so just like DataEngine, we DataSink has multiple "sources" | 16:06 |
| aseigo | called Services | 16:06 |
| spstarr | weatherService->sendQuery("Validate" , "Calgary, AB"); <-- but i cant deal with chained dataengines | 16:06 |
| aseigo | but in this case they are one-to-one with the visualization | 16:06 |
| Chani | aseigo: so... one Sink, and then one Service per user (or other configuration thing)? | 16:06 |
| aseigo | spstarr: your sink could use your ion engines | 16:06 |
| spstarr | aseigo: i'll need to see how Sink will work | 16:06 |
| * aseigo realizes that that line probably sounds more like a bit of Star Trek dialog than coding | 16:06 | |
| spstarr | haha | 16:07 |
| Quit begert has left this server ("Konversation terminated!"). | 16:07 | |
| aseigo | Chani: one Service per visualization | 16:07 |
| aseigo | e.g. per applet | 16:07 |
| Chani | hehehe | 16:07 |
| Chani | hmmmm. | 16:07 |
| aseigo | so each twitter applet would end up with its own Service | 16:07 |
| Chani | aseigo: okay | 16:07 |
| aseigo | well, actually, that would be up to the Sink at the end of the day, but likely it'll just hand out a new Service on each request | 16:07 |
| Chani | I'm not 100% that's good, but... hmm | 16:07 |
| Join begert has joined this channel (n=bill@cpe-74-74-217-64.rochester.res.rr.com). | 16:07 | |
| spstarr | should sendQuery have ([source], key, value); ? | 16:07 |
| spstarr | since you need to distinguish which source? | 16:08 |
| aseigo | this allows us to keep the simplicity of display only widgets | 16:08 |
| Chani | I imagine things like jackrabbit's solid cd-eject idea would only need one service to do that :) | 16:08 |
| aseigo | it also makes it trivial to do things like have multiple applets updating the same service without banging into each other | 16:08 |
| aseigo | Chani: right | 16:08 |
| * Chani already has them not banging into each other | 16:08 | |
| ruphy | how do you get the data back? the usual way? | 16:09 |
| aseigo | and most importantly: it avoid tempting engine writers to write engines that only work with one account or visualization at a time | 16:09 |
| aseigo | Chani: yeah, but it's ugly and frustrating, isn't it? | 16:09 |
| Chani | but with the horrif hackl of setProperty("status", "user:message") | 16:09 |
| jackrabbit | ruphy: I would think through the dataengine | 16:09 |
| Chani | yep | 16:09 |
| spstarr | aseigo: and then there is 'this problem: | 16:09 |
| aseigo | ruphy: i think we'll probably do just as with engines and have a generic update slot... serviceUpdated or somesuch | 16:09 |
| litb | hello all | 16:10 |
| aseigo | Chani: and it's that pain i want to relieve without screwing widget writers over | 16:10 |
| aseigo | litb: yo | 16:10 |
| litb | i consider porting kima with ken | 16:10 |
| Chani | aseigo: originally I thiought I was just gonna quickly fix up the twitter engine so that it could handle >1 user, and here I am now... | 16:10 |
| litb | is this teh right time, and what engine should we look at? | 16:10 |
| spstarr | [Containments][1][Applets][20][Configuration][Calgary] | 16:10 |
| spstarr | data=http://feeds.bbc.co.uk/weather/feeds/obs/world/0262.xml | 16:10 |
| spstarr | ion=bbcukmet | 16:10 |
| aseigo | so ... DataSink -> Service .. and a way to pass query specifications to DataEngine::connectSource | 16:10 |
| spstarr | the uglyness of metadata | 16:10 |
| ruphy | aseigo: just brainstorming... what about getting an id back and then QVariant getResultFor(id)? | 16:10 |
| litb | (it's a monitoring plasmoid for temperatures, speed and so on) | 16:10 |
| Chani | aseigo: wait... generic update slot? eh? | 16:10 |
| aseigo | ruphy: like Phase .. well, if you have the Service kicking around, you should be able to just do service->result() | 16:11 |
| ruphy | no idea if it's better, just throwing the idea i | 16:11 |
| ruphy | yeah, like phase | 16:11 |
| fregl | hm, getting data from a sink feels wrong... | 16:11 |
| jackrabbit | service-result(id) | 16:11 |
| aseigo | hopefully i'll make Applet do nice trickery like manage the services associated with the applet automatically | 16:11 |
| * Chani feels her brain slowing down | 16:11 | |
| jackrabbit | if you wanna have multiple queries | 16:11 |
| aseigo | so you can just call service("foo") multiple times and keep getting the same one until you say your done with it | 16:11 |
| Chani | fregl: yes it does | 16:11 |
| spstarr | this is a fundamental shift in dataengines aseigo :-) | 16:11 |
| spstarr | well, apiwise | 16:12 |
| aseigo | fregl: return values are a fact of life with such things | 16:12 |
| Quit apol_ has left this server (Remote closed the connection). | 16:12 | |
| Chani | so | 16:12 |
| Join apol_ has joined this channel (n=apol@84.78.178.63). | 16:12 | |
| fregl | but then there is no reason for engines to exist... they are just reduced sinks then... | 16:12 |
| aseigo | spstarr: not really. it adds another connectSource method, and another sourceRequested method (or an overload.. but i think i prefer the latter) | 16:12 |
| Chani | aseigo: feedback on async stuff... how would that work? right now my dataengine has sources beginning with Error to tell the applet when things go wrong | 16:13 |
| spstarr | serviceRequested() ?? | 16:13 |
| aseigo | spstarr: so engines that care about parameterization implement those methods for parameterized requests, and everyone else ignores it | 16:13 |
| aseigo | spstarr: that's not for engines | 16:13 |
| aseigo | Chani: engines are naturally async... | 16:13 |
| aseigo | Chani: the source is created on demand, but the engine decides when data actually gets shipped back | 16:13 |
| Chani | aseigo: yes. | 16:14 |
| spstarr | so Plasma::Service is for setting up 'metadata' to the Engine? | 16:14 |
| aseigo | Chani: that's why you can return false from sourceRequested | 16:14 |
| aseigo | spstarr: no. | 16:14 |
| aseigo | spstarr: that's for sending data / commands to services, and has NOTHING to do with engines | 16:14 |
| Chani | aseigo: it is? I thought false meant "no, we're never creating this source" | 16:14 |
| * aseigo notes this is also why he wants to separate these things, because everyone gets confused about the differences | 16:14 | |
| spstarr | hehe | 16:14 |
| aseigo | spstarr: parameterization will be for setting up metadata to the engine | 16:14 |
| * randomguy3 urges everyone to make sure what he's dumping into gobby makes sense | 16:15 | |
| spstarr | i think im gonna need to see an example as to how this all works so i can blow up code | 16:15 |
| Join hydrogen has joined this channel (n=hydrogen@ignorance.campus.alfred.edu). | 16:15 | |
| jackrabbit | randomguy3; looks right to me | 16:15 |
| spstarr | aseigo: that I got :) | 16:15 |
| aseigo | Chani: ah, sorry.. right.. reading the api docu it says: | 16:15 |
| aseigo | * If the source can not be populated with data immediately (e.g. due to | 16:15 |
| aseigo | * an asynchronous data acquisition method such as an HTTP request) | 16:15 |
| aseigo | * the source must still be created, even if it is empty. This can | 16:15 |
| aseigo | * be accomplished in these cases with the follow line: | 16:15 |
| Quit apol has left this server (Connection timed out). | 16:15 | |
| aseigo | so you just create an empty source | 16:15 |
| Chani | aseigo: ok, so say I send a twitter update to a DataSink, and 30 seconds later the http bit times out. how do I tell the applet? | 16:16 |
| jackrabbit | through the data engine | 16:16 |
| randomguy3 | serviceUpdated()? | 16:16 |
| spstarr | ok then what *is* a Plasma::Service if it's not a dataengine? | 16:16 |
| Chani | aseigo: ok good, that's what I've been doing, create empty source and return true, but have updateSource always return falssee | 16:16 |
| aseigo | Chani: that's why we need to get data back from DataSink, despite fregl's iinitial queasyness ;) | 16:16 |
| Chani | spstarr: it's a data *sink* | 16:16 |
| spstarr | or would my WeatherEngine actually be the Service and the ions are the dataengines? | 16:17 |
| aseigo | spstarr: it's a place to send data to places, such as a twitter update | 16:17 |
| Chani | aseigo: if we need to get data back from it, how do we avoid reimplementing 90% of DataEngine? | 16:17 |
| aseigo | spstarr: don't think about Service and Engine at the same time =) | 16:17 |
| randomguy3 | spstarr: I'm not sure why your weather engine would need a sink at all | 16:17 |
| randomguy3 | spstarr: weather info is read-only | 16:17 |
| aseigo | Chani: because it has a one-to-one relationship with the visualization, has not timing updates, etc | 16:17 |
| Chani | spstarr: I don't think data sinks are any use to your plasmoid | 16:18 |
| aseigo | Chani: it's a much simpler use case. | 16:18 |
| spstarr | randomguy3: its read-only but you can adjust the 'metrics' of that data only. | 16:18 |
| fregl | aseigo: sure, but then I'd like to be able to have multiple applets being notified by the same sink (just to add to that queasyness :p ) | 16:18 |
| Chani | aseigo: ok | 16:18 |
| randomguy3 | spstarr: that's just a case of getting different data, not sending it anywhere | 16:18 |
| aseigo | Chani: they *might* be useful for validating place names in the weather applet.. dunno yet though | 16:18 |
| Chani | aseigo: so really we just need some kind of result-thing to connect to? | 16:18 |
| aseigo | fregl: that's why Sink provides Service | 16:18 |
| randomguy3 | spstarr: it's "passive", in the sense that requesting a service is passive | 16:18 |
| fregl | I think maybe subclassing engine would make sense then?? | 16:19 |
| aseigo | no, that would be silly | 16:19 |
| randomguy3 | spstarr: it may create a service, but you don't care whether it has any real effect or not | 16:19 |
| spstarr | randomguy3: the WeatherEngine itself is pretty small, it merely forwards the applet requests to the ion plugins and passes their data back to the applet | 16:19 |
| aseigo | fregl: ok, if you are trying to pass data to multiple sources, that's an engine | 16:19 |
| aseigo | fregl: if you are trying to provide interactive data flow, that would be a sink | 16:19 |
| aseigo | the latter is inherently 1:1 | 16:19 |
| spstarr | randomguy3: the reason is to keep the 1 : 1 ratio :) | 16:19 |
| aseigo | the former coudl be either, but for reasons that should be obvious at this point, we opted for 1:many | 16:19 |
| Chani | aseigo: if it just sends out a signal when it's got a result... that could be pretty simple.. just gotta assicoate it with the Service properly | 16:20 |
| randomguy3 | spstarr: but my point is that it's a passive mechanism - the applet just asks for data and reads it, so there are no "sinks" involved | 16:20 |
| spstarr | one applet for one weatherengine [multiple data backend sources to choose from] | 16:20 |
| aseigo | Chani: right. | 16:20 |
| fregl | well, I imagine one user input effects multiple applets | 16:20 |
| spstarr | randomguy3: correct | 16:20 |
| aseigo | fregl: ok, real world case: twitter | 16:20 |
| aseigo | so ... you have two applets watching two different twitter accounts | 16:20 |
| aseigo | A and B | 16:20 |
| randomguy3 | spstarr: but you could, in theory, have two applets displaying the same info, and they would use the same source | 16:20 |
| fregl | yes, I see that case | 16:20 |
| aseigo | B's account is set to watch A's updates | 16:21 |
| spstarr | randomguy3: and they do | 16:21 |
| fregl | then it goes to twitter and back... | 16:21 |
| Chani | fregl: say I send a tewwt to twitter. sure, that'll affect my timeline: but the twitter server will tell the engine about it | 16:21 |
| fregl | sure | 16:21 |
| aseigo | applet A uses a Service to send a tweet | 16:21 |
| aseigo | the engine picks it up when it is available ... | 16:21 |
| aseigo | and both applets show it | 16:21 |
| spstarr | except the Q_PROPERTYs of each collides with one another being the same 'unique' key both applets would adjust their properties at the same time | 16:21 |
| aseigo | if we wanted to be extra cute ... | 16:21 |
| * randomguy3 shrugs, as he has lost track of what he and spstarr were discussing | 16:21 | |
| aseigo | we could allow Services to kick Engines to update | 16:21 |
| spstarr | heh | 16:21 |
| fregl | aseigo: yes, that's what I want | 16:22 |
| * hydrogen waves | 16:22 | |
| randomguy3 | spstarr: oh, yes, changing the metric in one shouldn't change the metric in the other | 16:22 |
| aseigo | fregl: can you think of a situation that isn't a specialization of the above A & B, A updates scenario? | 16:22 |
| aseigo | hydrogen: at what hertz? | 16:22 |
| spstarr | aseigo: actually I *do* need a Service if people would be writing different weather applets | 16:22 |
| randomguy3 | spstarr: because that makes it "active" | 16:22 |
| fregl | user enters a word, one applet shows some feedback and another shows that feedback in a different way | 16:23 |
| randomguy3 | spstarr: for why? | 16:23 |
| Chani | aseigo: that would be mildly useful to me: sending a tweet already kicks all hte sources, but hte problem is that the twitter server is usually too slow for it to be useful :) | 16:23 |
| spstarr | randomguy3: i cant keep track of the differences though, im encountering this now | 16:23 |
| hydrogen | aseigo: a 47 hertz sine wave, to be precise | 16:23 |
| fregl | for example one applet showing a box with 3/20 vocabulary, one giving a sentence liek "your anwer was good" ... | 16:23 |
| aseigo | Chani: yes.. another reason i want separation.. it actually makes that *easier* to accomplish in the code | 16:23 |
| spstarr | unless i added applet ID to the connectSource() | 16:23 |
| spstarr | then i could keep track of duplicate sources being displayed at once | 16:24 |
| fregl | but if sinks are able to update engines, it sounds perfect to me | 16:24 |
| Chani | spstarr: oh god no | 16:24 |
| aseigo | fregl: in particular, i'd want source level resolution | 16:24 |
| ruphy | omg | 16:24 |
| spstarr | so if I load 6 weather applets with Calgary and I wanted to see them all, 'each' one would be unique | 16:24 |
| ruphy | still that prob :D | 16:24 |
| aseigo | fregl: so a Service request can kick a specific source | 16:24 |
| aseigo | ruphy: it's non-trivial =) | 16:24 |
| Chani | spstarr: why? why? | 16:24 |
| spstarr | Chani: i didnt say it was a sane thing :) | 16:24 |
| hdevalence | I had an idea that might be wrong, but I think it might be interesting. | 16:25 |
| aseigo | hdevalence: shoot | 16:25 |
| Chani | spstarr: how about we discuss the weather engine tomorrow? | 16:25 |
| Chani | spstarr: I'd like to chat about it but my brain is turning to slush | 16:25 |
| spstarr | na, im gonna blow things up after this meeting :) | 16:25 |
| hdevalence | one min, let me type it up | 16:25 |
| * aseigo notes that the weather engine needs will also be met.. we just need parameterization | 16:25 | |
| Join maxk has joined this channel (n=max@p57A7CAD4.dip.t-dialin.net). | 16:25 | |
| spstarr | i only bring up my applet cause its the craziest one in Plasma :) | 16:25 |
| Quit maxx_k has left this server (Connection reset by peer). | 16:25 | |
| aseigo | .. and that that is _different_ from services =) | 16:26 |
| spstarr | yes that is different | 16:26 |
| hydrogen | aseigo: wrt reviewing.. paleo came across this stuff that we are going to play with for Amarok... it is software that allows fairly in depth code review after commiting, basically a websvn viewer with integrated review stuff | 16:26 |
| Chani | aseigo: ok, so I think I mostly Get the DataSink thing now. I just hopew someone wrote it up 'caiuse I'll forget by morning | 16:26 |
| hydrogen | http://www.atlassian.com/software/crucible/ | 16:26 |
| hydrogen | They give out licenses to open source projects for free | 16:26 |
| * jackrabbit notes that with this it would be possible to implement knetworkmanager as a dataengine/sink/applet combo | 16:26 | |
| Chani | so, parameterization? | 16:26 |
| spstarr | hydrogen: yes we use their software | 16:26 |
| spstarr | hydrogen: just never used the code reviewer, just the bug/wiki stuff | 16:26 |
| spstarr | i didnt know about their code reviewer! | 16:27 |
| Chani | jackrabbit: awesomesauce! | 16:27 |
| aseigo | Chani: it's in my head. i'm happy. i'll write it up next week (as in code) | 16:27 |
| Nick leinir is now known as leinirAWAY. | 16:27 | |
| spstarr | aseigo: that looks SO nice | 16:27 |
| Chani | aseigo: sweet :) | 16:27 |
| Quit Eren has left this server (Remote closed the connection). | 16:27 | |
| spstarr | danke aseigo :) | 16:27 |
| spstarr | but i will begin removing Q_PROPERTY and that will drop LOC | 16:28 |
| Chani | aseigo: I have another twitter refactor planned Real Soon Now, so once I've done that I'll start using hte datasink | 16:28 |
| aseigo | hydrogen: i met one of the guys who works there at l.c.a | 16:28 |
| aseigo | hydrogen: he said he could get us full licenses for free | 16:28 |
| Chani | aseigo: your australia presentation made me realise why I hated my userimage handling and how to solve it | 16:28 |
| spstarr | aseigo :) we can get it cause KDE is FLOSS. | 16:28 |
| aseigo | hydrogen: ah, i see you noted that already | 16:28 |
| randomguy3 | does my description of the distinction between services and engines look right? | 16:29 |
| hydrogen | mm | 16:29 |
| hdevalence | we make a bunch of applets that are simple, generic visualizations -- stuff like line graph, chart, bar graph, pies, etc etc. then we have a set of 'intermediate' things that process stuff and then we connect it all to to data engines with a gui. So the user connects the dataengines to the ``processors'' and then set some kiund of simplified rules to process it, and then connect that to the visualizations. Kinda like pipes on a | 16:29 |
| hdevalence | unix shell, but easier to use. | 16:29 |
| hydrogen | I was playing with it yesterday.. It is fairly impressive | 16:29 |
| * Chani wanders over to goobby | 16:29 | |
| aseigo | hdevalence: yes, we'll eventually need to go there.. with engine and visualization you already get much of that if there was a gui designer | 16:30 |
| ruphy | Chani: ? | 16:30 |
| aseigo | hdevalence: processors would simply make it even nicer to do post-processing / amalgamation / etc of data | 16:30 |
| Quit rui has left this server (Remote closed the connection). | 16:30 | |
| aseigo | hydrogen: my only real concern with it is that it is non-free... | 16:31 |
| Chani | ruphy: what? | 16:31 |
| aseigo | hydrogen: honestly, i'd prefer to stick with Free software options as long as they exist | 16:31 |
| Quit dirk|home has left this server (Remote closed the connection). | 16:31 | |
| hdevalence | i for one would rather not have another blowup like what happened with (bitkeeper?) and the linux kernel | 16:32 |
| * Chani finishes her tea | 16:32 | |
| Chani | are we gonnna talk about this parameterization thing? | 16:33 |
| Quit nogden has left this server (Remote closed the connection). | 16:33 | |
| jackrabbit | hdevalence: there is a big difference between this and bitkeeper though | 16:33 |
| Quit hydrogen has left this server ("Konversation terminated!"). | 16:33 | |
| Chani | or is the meeting over? | 16:33 |
| aseigo | yes, i think so.. | 16:34 |
| * aseigo can't go on at thi spoint.. needs to go.. | 16:34 | |
| * aseigo bangs the gavel again, just to be officious | 16:34 | |
Generated by irclog2html.py 2.6 by Marius Gedminas - find it at mg.pov.lt!