[01:31] <duflu> RAOF: https://launchpad.net/ubuntu/+source/libinput ?
[01:31] <duflu> Sounds official
[01:31] <RAOF> Indeed.
[01:32]  * RAOF upgrades to utopic
[01:32] <RAOF> But first: coffee!
[01:48] <josharenson> kdub, re: way earlier, I am following the same method as the acceptance tests to launch server/client combo... but it isn't working, likely due to the fact that popen forks
[02:29] <bschaefer> anyone know why mesa-common-dev is installing GL headers on arm?
[02:37] <duflu> RAOF: I just noticed this happening on my system:
[02:37] <duflu> [    1.345960] fb: conflicting fb hw usage inteldrmfb vs EFI VGA - removing generic driver
[02:37] <duflu> which sounds logical
[02:37] <duflu> but doesn't that mean we can never have a seamless boot screen?
[02:38] <duflu> Because any modern system will start with efifb (or other) and then switch to the GPU-specific driver
[02:58] <RAOF> bschaefer: Because you can totally build GL applications against mesa on arm?
[02:59] <RAOF> duflu: No; intel, for example, has code to seamlessly take over from the EFI bootsplash.
[02:59] <duflu> RAOF: I suspected as much. Cool
[03:00] <duflu> RAOF: By default?
[03:00] <RAOF> I'm not sure if they've enabled it yet.
[03:01] <duflu> Trusty's boot screens seem quite broken for many possible reasons. Grub is often one
[03:01] <duflu> As usual, most of the boot experience is a black screen. Sometimes a purple border. And then the login screen
[03:01] <duflu> Plymouth doesn't really play a part any more
[03:04] <RAOF> It's because we boot too fast.
[03:04] <duflu> Yeah. I wonder what purpose the black screen with purple border is intended for though
[03:04] <duflu> It just looks confusing
[03:04] <RAOF> That would probably be grubish.
[03:07] <bschaefer> RAOF, with glx?
[03:07] <RAOF> bschaefer: Sure, why not!
[03:08] <bschaefer> RAOF, hmm then either SDL2 is confused or i am :)
[03:08] <RAOF> There would be some adrino GPUs where you could do GLX :)
[03:08] <bschaefer> as SDL2 assumes if GL/gl.h and GL/glx.h then opengl is supported, and attempts to render in opengl on arm
[03:08] <bschaefer> which fails
[03:15] <RAOF> And this is at compile-time, obviously.
[03:15] <RAOF> There's no way of explicitly asking for EGL?
[03:15] <bschaefer> there is, and it compiles fine, its at run time when a renderer is picked
[03:15] <bschaefer> which usually if opengl is around, opengl is picked first
[03:16] <bschaefer> RAOF, i can get around this by --disable-video-opengl in the deb for arm builds
[03:16] <bschaefer> RAOF, i just thought that opengl stayed away from arm, and it was just es 1/2
[03:17] <RAOF> It's technically possible to do on arm hardware (although I haven't followed up if Rob has actually implemented it for any of the reverse-engineered drivers), and (for example) the new nvidia arm stuff supports OpenGL 4.4.
[03:19] <RAOF> bschaefer: How does it pick a renderer? It can't pick a GLX one for Mir, because it can't get an X connection :)
[03:19] <bschaefer> RAOF, thats awesome! I didn't even know that was close to being supported on arm
[03:20] <bschaefer> RAOF, well, SDL2 just does 2 checks
[03:20] <bschaefer> if GL/gl.h and GL/glx.h exists, then flip the define VIDEO_OPENGL = 1
[03:20] <bschaefer> if VIDEO_OPENGL = 1, then we assume opengl is supported, and we attempt to return an opengl context for the renderer in the mir backend
[03:22] <RAOF> Ah.
[03:22] <bschaefer> actually its changed a bit in mir since then, but we get flags that'll hand that to us (in the mir back end)
[03:22] <RAOF> Well, it should be checking whether the EGL implementation supports OpenGL.
[03:23] <bschaefer> The check is just for OpenGLX11(), which flips that flag  :(
[03:23] <bschaefer> i should add a check if x11 is even around at that point though?
[03:24] <bschaefer> Ill have to dig more into its criteria for picking opengl, as i think its a bit to loose
[03:24] <bschaefer> RAOF, thanks!
[03:25] <RAOF> NP :)
[08:01] <duflu> RAOF: Here you go. It works at near light speed :)   https://code.launchpad.net/~vanvugt/mir/single-buffer/+merge/217555
[08:04] <RAOF> duflu: I notice you assume that reading and writing to that buffer simultaneously won't crash :)
[08:04] <duflu> RAOF: Correct for all memory types I know of...?
[08:08] <RAOF> I'm pretty sure doing so on some graphics hardware invokes undefined behaviour.
[08:08] <RAOF> But that's ok, because you can't hardware-accelerate single-buffered clients anyway!
[08:08] <duflu> RAOF:  I doubt it. Traditionally most GL implementation support single buffering
[08:09] <RAOF> Not to window surfaces?
[08:09] <RAOF> And only GL; that's one of the things removed in GLES
[08:10] <duflu> RAOF: Yeah "traditionally" in the good old GL days
[08:36] <anpok_> RAOF: duflu: you could have the other buffer in the display control unit that does the scan out.. and only block gl during scanout.. so the gles driver would really see only one buffer
[08:37] <anpok_> greyback: duflu is out for short, but comes back soon
[08:54] <duflu> greyback: Not sure there was any WM news this week... ?
[08:55] <greyback> duflu: not from me, I was out last week
[08:55] <greyback> duflu: have you anything?
[08:55] <duflu> I have grand plans for making a start on defining "Window" (maybe) and the multi-surface support stuff
[08:57] <duflu> greyback: But nothing official yet. I got delayed last week trying to fix some regressions.
[08:57] <duflu> And it happened to be a 3-day week in Australia :)
[08:59] <greyback> duflu: fair enough. This week I hope to sort out the QtCompositor multi-monitor story
[08:59] <duflu> anpok_: Yeah I was thinking you could block single buffered clients "only during scanout". But not a pressing issue
[08:59] <duflu> greyback: Fun. Let us know if anything needs fixing/improving
[09:01] <greyback> duflu: once anpok's custom-input-dispatcher branch lands, I'll be a happy bunny
[09:01]  * duflu doesn't even know what that means
[09:03] <greyback> anpok_: note https://code.launchpad.net/~andreas-pokorny/mir/custom_input_dispatcher/+merge/215174 has conflicts with trunk, could you update please
[09:09] <anpok_> greyback: ok
[09:31] <anpok_> hm i seem to be using a different compiler than our ci - the new 4.8 or 4.9 does not include string.h..
[09:31] <anpok_> hmm or that caused by a change in boost exception
[13:21] <greyback> fginther: ping
[16:57] <greyback> anpok_: hey, do you think lp:~andreas-pokorny/mir/input-sender-split is close to MR?
[16:58] <greyback> (fyi it has conflicts with mir-devel right now)
[16:59] <anpok_> i know
[16:59] <anpok_> i am untangling things that I added during custom_input_dispatcher
[17:01] <greyback> anpok_: ok
[17:01] <anpok_> it is closeish .. but not done
[17:02] <greyback> I'll be working off it for now anyway
[17:02] <anpok_> thanks
[17:15] <kdub> yay, figured out my resizing problem, lets see if there's any other way to break this overlay stuff
[17:22] <josharenson> So I still cannot figure out how to launch a mir client (via popen) and have it attach to a mir server that was started from a different thread (at least that isn't some kind of hack)... Has anyone done this? I think the issues is popen forks
[17:24] <kdub> josharenson, what sort of problem?
[17:25] <josharenson> kdub its either not working at all (client cannot connect to mir), or the performance is terrible (.5 frames / sec)
[17:25] <kdub> generally, I'd fork first, then have the processes do their things
[17:26] <josharenson> kdub I've tried using the test framework (launch_client_process) which does exactly that... no dice
[17:26] <kdub> josharenson, what is like the overarching goal?
[17:27] <kdub> like, launch glmark or something automatically?
[17:27] <josharenson> kdub, start server, run benchmark, stop server
[17:27] <kdub> right, just making sure
[17:27] <josharenson> if i call run_mir in a separate thread, sleep the main thread while server inits, and then call popen, it works
[17:28] <josharenson> kdub, but that uses a sleep call, and there is no way to gracefully stop the server
[17:28] <kdub> use a condition_variable to wake it up when the client has stopped
[17:29] <josharenson> kdub, it blocks at the run_mir call though
[17:30] <kdub> well, run_mir will just stop on the signals iirc
[17:30] <josharenson> kdub, so just raise(sigint)?
[17:30] <kdub> well, I dunno if that's the preferable way
[17:30] <kdub> if you're using the test framework directly (eg, like writing a new acceptance test)
[17:31] <kdub> then the drivers might not be being hit I think the default with those is to stub out the drivers
[17:31] <kdub> like, this new executable that does this should be more of 'in the spirit of the acceptance tests' than an acceptance test itself I guess
[17:31] <kdub> just my two cents though :)
[17:32] <josharenson> kdub, nod... however when I tried everything acceptance test related, up to and including dropping the popen into an existing acceptance test, the benchmark still couldn't connect to mir... I'll keep trying things...
[17:33] <alan_g|EOD> josharenson: kdub how about using InProcessServer with the default configuration? You can launch glmark in the test body.
[17:33]  * alan_g|EOD hasn't tried it but it should be possible
[17:33] <kdub> josharenson, yeah, thats another idea
[17:33] <kdub> like, check out the demo_inprocess_egl example
[17:33] <kdub> alan_g|EOD, but if the purpose is benchmarking, I'd rather not cut out the IPC stuff
[17:33]  * josharenson looking at that function
[17:35] <josharenson> kdub, alan_g|EOD certainly looks like what I'm trying to do.. I'll give it a try. Thanks
[17:36] <alan_g|EOD> kdub: If you launch a child process you'll be doing IPC
[17:36] <kdub> alan_g|EOD, yeah, good point
[17:36] <kdub> no process context switches though
[17:37] <alan_g|EOD> kdub: If you launch glmark as a child process it will be a different process
[17:38] <kdub> well, I thought we were talking about inprocess egl clients
[17:39] <alan_g|EOD> InProcessServer creates a server in the test process. But the client can be another process - provided you ship the connection FD across.
[17:39]  * alan_g|EOD wanders away again
[17:40] <kdub> have a nice wander :D
[17:40]  * kdub has to reacquaint myself with InProcessServer
[19:37] <stgraber> hey there
[19:37] <stgraber> so asac asked me to get a Unity8 + Mir desktop session running inside a LXC container (as a way to run 14.10's unity8+mir on 14.04)
[19:38] <stgraber> so far I'm trying to run unity8 with mir on vt8 from within a container. I've got access to /dev/tty8 and to /dev/dri but things are still failing a bit
[19:38] <stgraber> http://paste.ubuntu.com/7361449/ any idea?
[19:38] <stgraber> that's basically a clean container with just unity8-desktop-session-mir installed in there
[20:07] <stgraber> asac: http://paste.ubuntu.com/7361648/
[20:07] <asac> greyback: ^^
[20:08] <asac> greyback: who could help?
[20:09] <asac> kdub: ^ ?
[20:10] <asac> racarr__: ^ :) (that was last ping i'll try)
[20:10] <racarr__> Hola!
[20:10] <asac> yay!
[20:10] <racarr__> asac: stgraber: It's not familiar off the top of my head...lemme think/try something
[20:11] <asac> nice one... thanks!
[20:11] <racarr__> hmm experiment uninformative lol, lsof on a running mir_demo_server_shell
[20:12] <racarr__> is all libraries, /dev/tty /dev/dri and /dev/input (which wouldnt give this error...I think opening input still just fails with a log message)
[20:12] <kdub> stgraber, lxc container on the desktop?
[20:12] <stgraber> kdub: yep
[20:14] <racarr__> stgraber: Ok looking at gbm source its definitely the DRM fd
[20:14] <racarr__> *thinks*
[20:17] <racarr__> stgraber: Hmm if you aren't running USC
[20:17] <racarr__> then EGL_PLATFORM="mir" shouldnt be set
[20:17] <racarr__> because mir clients (incl nested mir server )use the mir egl platform
[20:17] <racarr__> but a host mir server uses the
[20:17] <racarr__> drm egl platform
[20:18] <racarr__> it shouldnt be necessary to set EGL_PLATFORM="mir"
[20:18] <racarr__> that could be it.
[20:19] <racarr__> if not, backtrace would be next step to see if its the server context or unity8 failing to initialize
[20:19] <racarr__> seems like the server...but *shrug*
[20:40] <asac> racarr__: stgraber: no luck?
[20:52] <stgraber> asac: sorry, had a meeting, back now
[20:52] <asac> heh
[20:52] <asac> dont worry
[20:52] <asac> i just wanted to check before i drop off :)
[20:53] <stgraber> racarr__: ok, so things should work if I only set QT_QPA_PLATFORM=ubuntumirserver in the environment and call unity8?
[20:53] <asac> allright, i am off, cu around tomorrow
[20:57] <racarr__> stgraber: Should!
[21:21] <AlbertA> kdub: ping
[21:21] <kdub> AlbertA, pong
[21:21] <AlbertA> kdub: so on the fallback path
[21:21] <kdub> sure
[21:21] <AlbertA> kdub: let's say you are using demo shell
[21:22] <AlbertA> kdub: and lets' say evertying is hooked up to hwc as envisioned
[21:22] <kdub> right
[21:22] <AlbertA> kdub: how does the extended
[21:22] <AlbertA> renderer get to render the shadows?
[21:22] <AlbertA> I'm not clear how the fallback and the compositor render interplay
[21:23] <kdub> well, in that case, the user of mg::DisplayBuffer (eg, the demo shell writer) would know they're doing something advanced, so they wouldn't try the optimization function
[21:23] <kdub> like, if the compositor writer can fit what they want to appear on the screen into a RenderableList, then they have the shot at optimization
[21:24] <kdub> otherwise, they have OpenGL to do what they want
[21:24] <AlbertA> ah I see
[21:24] <kdub> now, a clever compositor writer with this scenario could make a Renderable that is black, and insert it into the list
[21:25] <kdub> but not all ideas behind effects can be captured in the RenderableList
[21:25] <kdub> like from a compositor writer's perspective, they don't know about the android fallback GL code
[21:26] <kdub> and this is a cool abstraction (i'm biased :) ) because it works for like
[21:26] <kdub> hardware cursor + bypass buffer too
[21:26] <kdub> on mesa
[21:28] <AlbertA> I see you could render the shadows just once (until window size changes) and keep inserting into the list
[21:31] <kdub> right, but take like the 'magic lamp' animation (like a macos minimize)
[21:31] <kdub> during the animation, the compositor writer wants to do GL, so they have the flexibility
[21:32] <kdub> but once the window has become steady, then the compositor writer knows its simple, and can try submitting to the optimized function to get the optimized render the platform provides
[23:41] <racarr__> living on the edge and having a second coffee today :D


[01:21] <linuxtech> https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/1247148 should be set to invalid.  https://help.launchpad.net/Bugs/Statuses says the status is invalid to everyone, but while I am logged into launchpad, I am not seeing how I can change it.
[01:21] <ubot2> Launchpad bug 1247148 in bind9 (Ubuntu) "rndc addzone isn't working. fix available" [High,Confirmed]
[01:22] <linuxtech> Badly worded...  https://help.launchpad.net/Bugs/Statuses says the status of invalid is available to everyone...
[17:37] <dkessel> good evening. does anybody want to try and confirm bug 1252402 ?
[17:37] <ubot2> Launchpad bug 1252402 in testdrive (Ubuntu) "testdrive UI becomes unresponsive after saving settings" [Undecided,New] https://launchpad.net/bugs/1252402
[19:11] <hggdh> dkessel: balloons already did
[19:12] <dkessel> hggdh, oh yes sorry for not updating here...
[19:12] <hggdh> dkessel: just promoted it to triaged/high
[19:13] <dkessel> hggdh, thanks
[19:14] <hggdh> linuxtech: indeed. If a bug is triaged, only a bug supervisor can change it (or, perhaps, the OP)
[23:13] <crhrabal> anyone willing to review this for me:  https://code.launchpad.net/~tjguthrie4600/ubuntu/trusty/apt/bug-1206047/+merge/195553


[22:48] <Bashing-om> UWN: Issue707 up for review and final edits: https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/Issue707 :D
[22:50] <krytarik> Bashing-om: "Congratulations to this contributor!" seems to have been lost.
[22:53] <krytarik> Isn't the Ubuntu Budgie article more for the Press section, given its review nature without a current context?
[22:54] <Bashing-om> krytarik: Ouch ! haste makes waste - thanks !
[23:11] <Bashing-om> UWN: Next edits !


[02:47] <j4jackj> well what do you know? !flavors is out of date and is not in British English as well as it's American (i'm talking about the !command)
[03:15] <tsimpson> !-flavors
[03:15] <tsimpson> !flavours
[03:17] <tsimpson> !flavors is <sed> s/GNOME/Unity/
[03:17] <tsimpson> !flavors
[11:04] <j4jackj> thanks for that (a bit late :)


[13:56] <ddstreet> mapreri teward hey sorry but i'm sick today and need to skip the backporters mtg...please feel free to have it without me, and/or i can schedule/reschedule the next one later


[00:16] <shadeslayer> anyone around? :D
[00:19] <shadeslayer> apachelogger: ok, so that parser is complete, just one problem, DTSTART and DEND don't work for some reason
[00:19] <shadeslayer> plz fix
[00:43] <shadeslayer> meh
[00:44] <shadeslayer> apachelogger: QDateTime issue fixed as well
[00:44] <shadeslayer> yer parser is ready
[00:45] <shadeslayer> night guys
[00:57]  * afiestas is close to tarball // tag 1.2.1
[00:57] <afiestas> together with a patch for libbluedevil (one line patch)
[07:16] <Quintasan> shadeslayer: http://vladimirputin.soup.io/post/154482096/Image
[07:26] <valorie> booooooo Quintasan!
[10:20] <apachelogger> shadeslayer: woohoo, if you give me access I can improve it a bit :P
[10:20]  * apachelogger only got up so did not yet look at it in detail
[10:25] <bambee> morning
[10:52] <shadeslayer> apachelogger: you already have
[10:52] <apachelogger> cool
[10:52] <apachelogger> shadeslayer: btw     Q_ASSERT(iCalFile->open(QIODevice::ReadOnly | QIODevice::Text));  I'd not call the thing a library with something like that :P
[10:52] <shadeslayer> apachelogger: there's one thing that needs doing, handling \n characters at the end of a descriptio
[10:53] <shadeslayer> +n
[10:53] <apachelogger> huh?
[10:53] <shadeslayer> apachelogger: huh? why not? ( i'm relatively new to library development )
[10:53] <apachelogger> shadeslayer: because a library must never ever go down
[10:53] <apachelogger> well
[10:53] <shadeslayer> ah
[10:53] <apachelogger> unless there is an issue that it can definitely not prevent or recover from
[10:54] <apachelogger> I mean, for internal libs it makes no difference but for public shared ones it does
[10:54] <shadeslayer> bah, that \n is for vjournal
[10:55] <shadeslayer> so nvm that :P
[10:55] <apachelogger> *shrug*
[10:55] <apachelogger> even so
[10:55] <apachelogger> readline would simply come up with an empty line
[10:55] <shadeslayer> yeah
[10:55] <apachelogger> shadeslayer: another thing: it is very uncommon to do all the work in the ctor
[10:56] <apachelogger> shadeslayer: one would provide a static function for that most of the time
[10:56] <shadeslayer> ok, we could just move stuff into a static function
[10:56] <shadeslayer> right
[10:56] <apachelogger> Parser::parse(File)
[10:56] <apachelogger> yeah
[10:56] <apachelogger> plus we need that anyway since I also need a ctor for QBA
[10:57] <shadeslayer> QBA?
[10:57] <apachelogger> only the on-disk cache is read from file, incoming updates form remote are processed from the networkreply directly
[10:57] <apachelogger> shadeslayer: qbytearray
[10:57] <shadeslayer> ah ok
[10:57] <shadeslayer> ah kewl
[10:57] <shadeslayer> Quintasan: hahah :D
[10:58] <apachelogger> shadeslayer: so, two options... a) one ctor and multiple parse(QFile), parse(QBA) ... b) multiple ctor and one parse
[10:58] <apachelogger> former seems bettar
[10:58] <apachelogger> oh
[10:58] <apachelogger> Quintasan: ping
[10:58] <Quintasan> apachelogger: pong
[10:58] <shadeslayer> apachelogger: btw how fast is this yer device
[10:59] <apachelogger> shadeslayer: what device?
[10:59] <shadeslayer> apachelogger: N950
[10:59] <apachelogger> what kind of fast?
[10:59] <shadeslayer> how fast does it process the ical file
[10:59] <shadeslayer> because it was insanely fast on my machine
[10:59] <shadeslayer> but since we need it to be fast on a ARM device ...
[11:00] <apachelogger> parsing is not so much the problem...
[11:00] <apachelogger> problem is that currently I have multiple lists which in JS means multiple memcopies
[11:01] <apachelogger> IIRC the main oneiric ical had something like 220 sessions
[11:01] <apachelogger> so that means like 3*220 memcopies or so
[11:01] <apachelogger> and memcopies are evil!
[11:01] <shadeslayer> heh
[11:02] <apachelogger> even so it only hung for like 1 second
[11:02] <shadeslayer> neat
[11:02] <apachelogger> so for ondisk cache reads actually starting the app is slower than parsing
[11:02] <apachelogger> and for remote updates the actual file transfer was slower than parsing
[11:03] <shadeslayer> apachelogger:  btw is the QBA going to contain the entire iCal starting with BEGIN: VEVENT ... or just one particular field like DESCRIPTION
[11:03] <shadeslayer> O_O
[11:03] <apachelogger> shadeslayer: the ical as read from UDS
[11:03] <apachelogger> ah
[11:03] <apachelogger> yeah
[11:03] <apachelogger> your parser will trip over that
[11:04] <apachelogger> ical files have a sort of manifest section before the first event
[11:05] <shadeslayer> apachelogger: i ignore that :P
[11:06] <apachelogger> oh yeah
[11:06] <apachelogger> sorry misread the code there
[11:06] <shadeslayer> although i shouldn't, but seeing how i couldn't figure out what i should do with that, i left them
[11:06] <apachelogger> bad code...
[11:06] <apachelogger> I shall refactor :P
[11:06] <shadeslayer> feel free too :P
[11:06] <apachelogger> shadeslayer: you should const the read line IMHO
[11:06] <apachelogger> more compiler love + no changes by accident
[11:06] <shadeslayer> hmm ... yeah, we don't want to change the values
[11:07] <shadeslayer> apachelogger: are you  refactoring the entire thing right now?
[11:07] <apachelogger> sorta
[11:08] <shadeslayer> alright i'll wait for you to push yer changes
[11:09] <apachelogger> shadeslayer: another thing ...the event class is likely to be derived, whereas the parser is less likely to
[11:09] <Quintasan> shadeslayer: Any news about the touchpad or I missed it?
[11:09] <apachelogger> so former needs a virtual dtor and latter does not
[11:09] <shadeslayer> Quintasan: nothing so far
[11:10] <shadeslayer> Quintasan: they're going to take some time and i'm pretty sure it won't be available before another month
[11:10] <shadeslayer> and as soon as they make it available its going to be gone
[11:10] <shadeslayer> they've said they can't even gurantee pricing
[11:11] <shadeslayer> wtf dbus is taking all my cores
[11:11] <apachelogger> shadeslayer: some thought on formartting btw ... functions always before members in the header
[11:12] <shadeslayer> i'll keep that in mind :)
[11:13] <shadeslayer> apachelogger: does the event even require a dtor?
[11:13] <shadeslayer> i'm not allocating memory manually anywhere in the event , which is why i didn't have a dtor there
[11:14] <apachelogger> shadeslayer: a library class *always* needs a dtor :P
[11:14] <shadeslayer> even if its empty? :P
[11:14] <apachelogger> the compiler has free hand at where he puts the dtor and what it makes of it
[11:15] <apachelogger> if you do not declare a dtor the compiler might make a virtual one because one of your classes derives the class internally
[11:15] <apachelogger> suddenly stuff starts segfaulting for no apparent reason
[11:15] <shadeslayer> heh
[11:18] <shadeslayer> apachelogger: we could make it a bit more faster by using  continue in parseICalBlock
[11:19] <shadeslayer> as soon as it finds the field, it sets stuff in the event and then proceeds to the next line instead of checking it again
[11:19] <apachelogger> yes
[11:22] <apachelogger> shadeslayer: you should fix your copyright line btw :P
[11:23] <shadeslayer> where
[11:24] <apachelogger> everywhere, year misisng
[11:24] <shadeslayer> ah
[11:27] <apachelogger> that loop needs help
[11:27] <shadeslayer> done
[11:27] <apachelogger>         } else if (line.startsWith(QLatin1String("DTSTART:"))){
[11:27] <apachelogger>            event->setStartDate(QDateTime::fromString(line, "'DTSTART:'yyyyMMdd'T'hhmmss'Z'"));
[11:27] <apachelogger> formatting fail :P
[11:27] <shadeslayer> yes? what about it?
[11:27] <apachelogger> get a proper editor
[11:27] <shadeslayer> i'm using qtcreator
[11:27] <shadeslayer> :P
[11:27] <apachelogger> learn to use it then
[11:28] <shadeslayer> heh :P
[11:29] <apachelogger> so
[11:29] <apachelogger> that loop needs to go away
[11:30] <apachelogger> 1 if that checks for dtstart, dtend and categories, any other value that is end:vevent is then parsed as key:value and insertered into the property map
[11:30] <apachelogger> that said
[11:30] <apachelogger> instead of having hard coded properties the event should probably use a property map
[11:30] <apachelogger> so it is easily enhancable
[11:37] <shadeslayer> you broke something
[11:37] <shadeslayer> i can't parser anymore
[11:37] <shadeslayer> s/parser/parse
[11:37] <shadeslayer> [~/projects/libqcalparser/build]$ ./qcalparser /tmp/uds-p.ical
[11:37] <shadeslayer> [~/projects/libqcalparser/build]$
[11:38] <apachelogger> no
[11:38] <apachelogger> your library was badly designed
[11:38] <apachelogger>     QCalParser *parser = new QCalParser(file);
[11:38] <apachelogger> that now passes for QCalParser(QObject*)
[11:38] <shadeslayer> ah ok
[11:39] <apachelogger> so you need to change that to construct and then parse
[11:39] <apachelogger> shadeslayer: how do we do property management?
[11:39] <shadeslayer> apachelogger: QVariantMaps ?
[11:39] <apachelogger> 2 options: dynamic property injection via QtMetaObject OR QVariantMap
[11:39] <shadeslayer> because QML has better support for QVariants than other Qt classes i hear
[11:39] <apachelogger> former is again bettar
[11:39] <apachelogger> shadeslayer: qml also expects properties
[11:40] <apachelogger> so if we use a QVM we need to manually declare the properties in the header still
[11:40] <apachelogger> actually
[11:40] <apachelogger> we need to declare them and write getters
[11:40] <apachelogger> so dynamic injection via the metaobject might in fact be the only sane solution
[11:41]  * apachelogger tests this for a bit
[11:41]  * shadeslayer tries to understand what apachelogger just said
[11:41] <apachelogger> lol
[11:41] <apachelogger> I'll show you code :P
[11:41] <shadeslayer> that would actually be better :P
[11:43] <apachelogger> shadeslayer: http://paste.kde.org/123079/
[11:43] <apachelogger> the qtmetaobject of the qobject already has a QVM for the properties
[11:43] <apachelogger> so you can inject new properties by simply setting a new property
[11:43] <apachelogger> without having to declare ANYTHING
[11:44] <shadeslayer> O_O
[11:44] <shadeslayer> sweet
[11:44] <apachelogger> every time I tell people about this a jahava kitten dies
[11:44] <shadeslayer> hahaha
[11:45] <shadeslayer> apachelogger: so, we just inject new properties in our QCalEvent
[11:46] <shadeslayer> when the setters are called
[11:46] <shadeslayer> and change getters to return that property
[11:48] <apachelogger> if it were working :O
[11:49] <shadeslayer> its not ? :O
[11:49] <apachelogger> not in qml
[11:49] <shadeslayer> aw :(
[11:52]  * apachelogger tries to debug
[11:59] <apachelogger> Note that dynamic properties are added on a per instance basis, i.e., they are added to QObject, not QMetaObject.
[11:59] <apachelogger> great
[12:00] <apachelogger> shadeslayer: so we can use the dynamic properties, but we still need to provide Q_PROPERTY macros and reader functions
[12:00] <apachelogger> (latter can be put into a macro too though
[12:00] <apachelogger> )
[12:01] <shadeslayer> hmm
[12:01] <apachelogger> or.....
[12:01] <apachelogger> we could write our own metaobject which allows for this use case ^^
[12:03] <apachelogger> actually
[12:03] <apachelogger> shadeslayer: we could just not use properties
[12:04] <apachelogger> Q_INVOKABLE QVariant getValue(QString key)
[12:04] <apachelogger> actually
[12:04] <apachelogger> scratch the get
[12:04]  * apachelogger has used too much crappy qtmobility api
[12:04] <shadeslayer> heh
[12:04] <shadeslayer> apachelogger: and we could just reuse the current API to deal with that
[12:05] <apachelogger> deal with what?
[12:05] <apachelogger> shadeslayer: we'd still setProperty()
[12:05] <shadeslayer> Q_INVOKABLE QVariant getValue(QString key)
[12:05] <shadeslayer> oh
[12:05] <apachelogger> only that we provide a Q_INVOKABLE which gives access
[12:05] <shadeslayer> ah
[12:05] <shadeslayer> i get it
[12:05] <apachelogger> Q_INVOKABLE QVariant value(QString key) { return getProperty(key); }
[12:05]  * apachelogger did it again
[12:06] <shadeslayer> heh
[12:07] <shadeslayer> did i mention KCombBox is weird
[12:07] <apachelogger> because of the K
[12:07] <shadeslayer> probably
[12:07] <apachelogger> shadeslayer: well, make a choice on the event matter... either is fine with me
[12:08] <apachelogger> actually having Q_PROPERTY hardcoded props allows for easier use in qml as qtcreator will autocomplete ^^
[12:08] <apachelogger> for ultimate scalability one will need a value() function anyway
[12:08] <shadeslayer> ok, lets go with Q_PROPERTY then
[12:12] <apachelogger> k
[12:12] <apachelogger> shadeslayer: btw     QDateTime eventStartDate();
[12:12] <shadeslayer> yes?
[12:12] <apachelogger> that is a C func name, not a cpp one :P
[12:13] <apachelogger> QDateTime startDate()
[12:13] <shadeslayer> how?
[12:13] <apachelogger> we know that it is a event because it is an Event class :P
[12:13] <apachelogger> event->eventStartDate()?
[12:13] <apachelogger> vs
[12:13] <shadeslayer> ah heh
[12:13] <apachelogger> event->startDate()
[12:13] <apachelogger> that reminds me
[12:13] <apachelogger> shadeslayer: scope is broken there
[12:13] <apachelogger> the event is held by the parser
[12:13] <shadeslayer> i think everything is currently using eventFoo
[12:14] <apachelogger> yeah, well, fixing
[12:14] <shadeslayer> heh :P
[12:14] <apachelogger>     Q_PROPERTY(QDateTime dtStart READ dtStart)
[12:14] <apachelogger>     QDateTime dtStart() const { return getProperty("DTSTART"); }
[12:14] <apachelogger> hm
[12:15] <apachelogger> something is not cool about this
[12:15] <shadeslayer> that does not look right
[12:16] <shadeslayer> looks weird tbh
[12:16] <apachelogger> but why?
[12:16] <shadeslayer> how does it know to return the dtStart property
[12:17] <shadeslayer> when we call it with getProperty("DTSTART")
[12:22] <apachelogger> qvariant?
[12:23] <shadeslayer> whut
[12:35] <apachelogger> doesnt work
[12:35] <apachelogger> no idea why
[12:35] <apachelogger> it works for a qstring but not for a datetime
[12:35] <apachelogger> http://paste.kde.org/123109/
[12:37] <apachelogger> this sucks
[12:37] <apachelogger> shadeslayer: so either we make our own QVM OR we create our own metaobject which allows this stuff OR we simply do not use Q_PROPERTY
[12:38] <apachelogger> actually, this is a bit weird
[12:38] <shadeslayer> you could return a datetime string
[12:38] <apachelogger> no, I need actual date objects in qml
[12:39] <shadeslayer> QML can parse thos?
[12:39] <shadeslayer> *those
[12:39] <apachelogger> slow
[12:39] <apachelogger> for no good reason
[12:39] <shadeslayer> heh
[12:43]  * apachelogger tries with own QVM
[12:45] <shadeslayer> i'll bbl
[12:46] <apachelogger> oh
[12:46] <apachelogger> I know what is wrong
[12:47]  * apachelogger is a bad maco coder
[12:47] <apachelogger> worky worky \o/
[12:55] <debfx> fabo: Check_for_buffer_overflow_in_Lookup_MarkMarkPos_CVE-2011-3193.patch is already part of qt 4.7.4
[13:45] <shadeslayer> apachelogger: new API done?
[13:45] <shadeslayer> and/or want my help?
[13:46] <apachelogger> WIP
[13:46] <apachelogger> rewriting parseBlock righ tnow
[13:46] <apachelogger> QString is a right PITA
[13:46] <shadeslayer> what s the problem with parseBlock
[13:47] <shadeslayer> or are you changing it to use the new API
[13:49] <apachelogger> new api
[13:49] <apachelogger> http://paste.kde.org/123121/
[13:50] <shadeslayer> dude
[13:50] <shadeslayer> that is wrong
[13:51] <shadeslayer>             event->setProperty(key, QDateTime::fromString(value, "'DTSTART:'yyyyMMdd'T'hhmmss'Z'"));
[13:51] <shadeslayer> what about poor DTEND
[13:51] <shadeslayer> your forgot about him
[13:52] <shadeslayer> otherwise ... this new API will handle other keys as well, awesome
[13:53] <apachelogger> shadeslayer: take a closer look at the if
[13:54] <shadeslayer> i did
[13:54] <shadeslayer> apachelogger: how would it work for DTEND
[13:54] <apachelogger> ah
[13:54] <shadeslayer> :)
[13:54] <apachelogger> now I see
[13:54] <apachelogger> your code was rubbish :P
[13:54] <shadeslayer> but it worked :P
[13:54] <apachelogger>             event->setProperty(key, QDateTime::fromString(value, "yyyyMMdd'T'hhmmss'Z'"));
[13:54] <apachelogger> ah
[13:54] <apachelogger> no
[13:55] <shadeslayer> wont work
[13:55] <shadeslayer> :D
[13:55] <apachelogger> or maybe
[13:55] <apachelogger> shadeslayer: why not?
[13:55] <shadeslayer> cuz you don't ignore DTSTART ... uh ... maybe it will
[13:55] <shadeslayer> not sure
[13:55] <apachelogger> lol
[13:55] <shadeslayer> need to look at docs again
[13:57] <shadeslayer> ah ok, i understand now
[13:57] <shadeslayer> apachelogger: value is just the part after DTSTART: right?
[13:57] <shadeslayer> not the entire line itself
[14:00] <apachelogger> yes
[14:00] <apachelogger> hence there is a key and a vlue
[14:00] <apachelogger> *value
[14:01] <shadeslayer> right, didn't read closely
[14:01]  * shadeslayer should probably blog about the stuff he did over the weekend
[14:33]  * apachelogger thinks he is happy with the event now
[14:36] <apachelogger> shadeslayer: pushd
[14:36] <apachelogger> please have a look
[14:38] <shadeslayer> looking
[14:51] <nikola> hi kubuntu devs. gtk2-engines-oxygen doesn't work for all gtk apps in oneiric. please fix it :)
[14:51] <shadeslayer> apachelogger: looks good, but, you don't need #include <QtCore/QDebug> in qcalparser.cpp
[14:51] <apachelogger> yeah, noticed that
[14:51] <shadeslayer> nikola: got a patch?
[14:51] <apachelogger> more worrying is that it does not work
[14:51] <nikola> bugreport: https://bugs.launchpad.net/ubuntu/+source/gtk2-engines-oxygen/+bug/853264
[14:51] <nikola> shadeslayer: no sorry
[14:52] <shadeslayer> apachelogger: it doesn't work?
[14:52] <apachelogger> I get an undefined qlist in qml
[14:53] <shadeslayer> maybe we need to export our QCalEvent as a property or sth?
[14:53] <shadeslayer> so that QML recognises it
[14:53] <apachelogger> even when I just use a qobject
[14:54] <apachelogger> file:///home/me/src/git/uds-build-desktop-Qt_4_7_4__System__Release/src/qml/ubuntudevelopersummit/main.qml:65: TypeError: Result of expression 'model[0]' [undefined] is not an object.
[14:54] <apachelogger> wtf
[14:56] <shadeslayer> 0.o
[14:56] <apachelogger> "A list of QObject* values can also be used as a model. A QList<QObject*> provides the properties of the objects in the list as roles."
[14:57] <shadeslayer> possibly different versions of documentation ?
[14:57] <shadeslayer> :P
[14:57] <apachelogger> I have been using qobj* list before
[14:57] <shadeslayer> oh
[14:58] <apachelogger> most confusing
[14:58] <apachelogger> QVariant(QList<QObject*>)
[14:58] <apachelogger> intersting
[15:00] <shadeslayer> apachelogger: btw instead of using a deliminatorPosition we could also use QString::section
[15:02] <apachelogger> point?
[15:02] <shadeslayer> no point, i'm just saying :)
[15:03] <apachelogger> I mean, section() has to seek the string to find the seperator and consequently a section
[15:03] <shadeslayer> and, shouldn't that be a QLatin1Char
[15:03] <apachelogger> so since we need lhs and rhs it makes more sense to find the seperator position within the string
[15:04] <apachelogger> and then take everything left and right of that
[15:04] <apachelogger> (since we know the exact position of seperator qstring will not have to seek for the seperator anymore)
[15:04] <shadeslayer> right
[15:06] <apachelogger> so
[15:06] <apachelogger> I think qml is just bugged again
[15:06] <shadeslayer> huh
[15:07] <shadeslayer> apachelogger: use a C++ backend to set data in the QML app?
[15:07] <apachelogger> I am emitting it
[15:07] <shadeslayer> using setContextProperty or whatever
[15:07] <apachelogger> and apparently qml it to stupid to convert to declarative type in a handler
[15:07] <apachelogger> shadeslayer: setcontextproperty? what is this? kindergarten?
[15:07] <apachelogger> Oo
[15:08] <apachelogger> you do not set stuff like that as a context property
[15:08] <apachelogger> a KDE i18n handler you could set ther
[15:08] <shadeslayer> heh :P
[15:19] <apachelogger> shadeslayer: I think I know what to do
[15:19] <apachelogger> but first I need a break
[15:19] <shadeslayer> alright
[15:19] <shadeslayer> i'm off to dinner myself
[15:20] <shadeslayer> apachelogger: oh btw, one thing that we can extract form the ical file is the time zone
[15:21] <shadeslayer> there's a field for that in the
[15:21] <shadeslayer> +beginning
[15:21] <shadeslayer> X-WR-TIMEZONE:UTC
[15:52] <shadeslayer> apachelogger: upload digikam already
[15:54] <ScottK> debfx: There were two security issues that fabo was working on.  One is already fixed in 4.7.4, the other is not.
[16:20] <shadeslayer> apachelogger: see email if you're around
[16:21] <apachelogger> why
[16:21] <apachelogger> I am at war
[16:21] <shadeslayer> apachelogger: just do it
[16:22] <apachelogger> what mail
[16:22] <apachelogger> Your Amazon.co.uk order has dispatched
[16:22] <apachelogger> yay
[16:22] <apachelogger> shadeslayer: how did you know that? :O
[16:22] <shadeslayer> lol
[16:22] <shadeslayer> not that
[16:23] <shadeslayer> apachelogger: see the one from wordpress
[16:23]  * shadeslayer needs to start prepping for his US visa
[16:23] <apachelogger> ah
[16:24] <apachelogger> that must wait
[16:24] <apachelogger> because I need booze
[16:24]  * shadeslayer switches apachelogger's booze with coffee
[16:25] <apachelogger> STUPID qdeclarativelistproperty
[16:27] <apachelogger> cant use qsharedpointers
[16:27] <apachelogger> terrible
[16:29] <Quintasan> apachelogger:  That's why I find school absolutely exasparating. I just learned we have a test on thermodynamics tomorrow
[16:29] <Quintasan> I mean what the f...
[16:29] <apachelogger> I do not even know what that is
[16:29] <Quintasan> lol
[16:29]  * apachelogger wonders if one could store it in a sharedpointer so he does not need to know about it
[16:30] <Quintasan> Not really
[16:30] <apachelogger> dang me running
[16:30] <Quintasan> It's basically useless info so I am not entirely sure why would you want to store it anywhere
[16:30] <shadeslayer> Quintasan: up for reviewing me blog post?
[16:30] <Quintasan> shadeslayer: Send it this way, might take a break as well
[16:31] <apachelogger> shadeslayer: so.... I think I will have to do major refcktoring of the uds app to accomodate qcal
[16:31] <shadeslayer> Quintasan: alright
[16:31] <apachelogger> particularly to add threading into the picture
[16:31] <apachelogger> oh it makes me sweat already
[16:31] <shadeslayer> Quintasan: done
[16:31] <shadeslayer> apachelogger: threading in QML ?
[16:31] <shadeslayer> :O
[16:31] <apachelogger> yes
[16:31]  * Quintasan goes reading
[16:31] <apachelogger> workerscript
[16:31] <apachelogger> but no
[16:31] <shadeslayer> are you shitting me
[16:31] <apachelogger> in cpp
[16:31] <shadeslayer> ah ok
[16:31] <shadeslayer> that makes sense
[16:32] <apachelogger> the data retrieval and storage becomes thread0red
[16:32] <shadeslayer> threading in QML would probably make my mind implode
[16:32] <apachelogger> Quintasan: so, actually thermodynamics is a very important thing
[16:33] <apachelogger> if you have too fast intercourse you can start a fire, and no one wants that
[16:33] <apachelogger> so I consider it in everyones interest that everyone knows about this and consequently does not cause accidential fires ever night
[16:33] <shadeslayer> Quintasan: also, review my digikam packaging at : https://code.launchpad.net/~rohangarg/kubuntu-packaging/digikam : if its alright, i'll upload to kubuntu-packaging and then someone can upload it
[16:33] <apachelogger> it aint even merged
[16:33] <apachelogger> good ld
[16:34] <apachelogger> howwas I supposed to do stuff
[16:34] <apachelogger> G
[16:34] <shadeslayer> apachelogger: you were supposed to review it, give me the OK and then i would i have pushed to kubuntu packagers :P
[16:34] <apachelogger> shadeslayer: you really want a different background for the presence screenshot
[16:34] <apachelogger> shadeslayer: did you do a merge proposal?
[16:34] <shadeslayer> apachelogger: hehe, i was thinking that too :P
[16:34] <apachelogger> ....
[16:34] <shadeslayer> apachelogger: k i'll do that
[16:36] <Quintasan> shadeslayer: wptouch skin has broken feedback table :P
[16:36] <Quintasan> "i" should be uppercase when you are talking about yourself
[16:36] <shadeslayer> heh
[16:36] <Quintasan> Also, use more sophisticated words so you sound cool and all intelectual
[16:37] <Quintasan> :P
[16:37] <shadeslayer> lol
[16:37] <Quintasan> You know, words like "splendid" or "superb" :P
[16:38] <Quintasan> There is also "awesome" which can be used almost everywhere
[16:38] <Quintasan> Ask apachelogger if you don't believe in this one :P
[16:39] <Quintasan> Okay. I'm going back to physics
[16:39] <shadeslayer> haha :D
[16:40] <Quintasan> See you later or tomorrow, depending on results of my studying :P
[16:40] <apachelogger> splendid comes right after fabulous
[16:40] <apachelogger> superb is when you cought a good bottle of wine
[16:40] <apachelogger> which I did not
[16:40]  * apachelogger gets whisky
[16:40] <apachelogger> Quintasan: hf
[16:40] <apachelogger> Quintasan: and remember the intercourse impact of it all
[16:41] <shadeslayer> apachelogger: review up
[16:42]  * apachelogger wonders how to thread
[16:51]  * shadeslayer hits publish
[17:06] <muntiKubu> which pkg has the add-apt-repository? tia
[17:07] <muntiKubu> apt-utils is installed but could not find command
[17:09] <muntiKubu> anyone?
[17:15] <JontheEchidna> muntiKubu: dpkg -S add-apt-repository shows python-software-properties to be the package
[17:15] <muntiKubu> JontheEchidna: thanks
[17:33] <bulldog98> shadeslayer: where to find the telepathy-kde packages?
[17:34] <shadeslayer> www.pad.lv/~telepathy-kde
[17:34] <shadeslayer> uh
[17:34] <shadeslayer> no
[17:34] <shadeslayer> http://pad.lv/~telepathy-kde
[17:35] <bulldog98> kthx
[17:35]  * bulldog98 is doing some backporting
[17:35] <bulldog98> shadeslayer: what to install daily or stable?
[17:36] <shadeslayer> bulldog98: i use git master personally
[17:36] <shadeslayer> along with neon
[17:39] <bulldog98> shadeslayer: oneiric or natty?
[17:39] <shadeslayer> oneiric
[17:39] <bulldog98> welcome in the club (I used it since development was opened)
[17:40] <shadeslayer> same here
[17:41] <bulldog98> nice :)
[17:44] <bulldog98> Quintasan: kde-config-telepathy-accounts-plugins : Depends: libkcmtelepathyaccounts4 (= 0.1.0+20110831-0~oneiric1) but 0.1.0+20110911-0~oneiric1
[17:56] <bulldog98> shadeslayer: do you have the rights to add me to telepathy-kde?
[17:57] <shadeslayer> nope, ask Quintasan
[17:58] <bulldog98> Quintasan: could you please add me to the telepathy-kde group, so I can fix that?
[17:58] <bulldog98> btw why don’t we add kubuntu-members as default to that sort of groups?
[17:59] <bulldog98> or ninjas?
[18:00]  * apachelogger ponder modelling
[18:00] <apachelogger> bulldog98: more interesting why not use a kubuntu-ppa :P
[18:00] <bulldog98> apachelogger: for daily builds?
[18:01] <apachelogger> why not?
[18:01] <bulldog98> we would end up having 200 PPAs for the dailys
[18:01] <apachelogger> so
[18:01] <bulldog98> apachelogger: I find it more convinient to have an group for that
[18:01] <apachelogger> indefinitely less management overhead than all the rubbish teams growing out of each of launchpad's openings
[18:02] <shadeslayer> lol ^^
[18:05] <apachelogger> shadeslayer: hooray it is working
[18:05] <shadeslayer> \o/
[18:05] <apachelogger> although it all turned into a super hack
[18:05] <apachelogger> good lawd
[18:05] <shadeslayer> heh
[18:05] <apachelogger> even my qmake files are all messed up
[18:08] <shadeslayer> apachelogger: btw you forgot a continue
[18:08] <shadeslayer> in the parser
[18:08] <shadeslayer> for CATEGORIES
[18:08] <bulldog98> apachelogger: maybe an kubuntu-dailybuilds would do?
[18:09] <shadeslayer> actually .. nvm
[18:12] <shadeslayer> apachelogger: whats the problem with QML and QList<QObject*> ?
[18:13] <apachelogger> you need to wrap it into a qdeclarativelistproperty
[18:13] <apachelogger> for which you need a qlist<T*> or you will get screwed over by having to implement qdeclarative stuff yourself
[18:13] <shadeslayer> and?
[18:14] <apachelogger> incidentially enough that means one cannot use qsharedpointer which is usually a good idea for the stinky pim data
[18:17] <shadeslayer> oh
[18:30]  * apachelogger sighs a bit
[18:33] <shadeslayer> apachelogger: btw see pm
[18:33] <apachelogger> no pm I have
[18:33] <shadeslayer> i sent it a couple of hours agon
[18:33] <shadeslayer> -n
[18:33] <apachelogger> I probably saw and ignored it then :P
[18:33] <shadeslayer> lol
[18:33] <BarkingFish> yoda, you are?
[18:34] <BarkingFish> :)
[18:34] <apachelogger> at times I am
[18:34] <shadeslayer> at times he's just apachelogger
[18:34] <apachelogger> "just"
[18:35] <apachelogger> good scope
[18:35] <apachelogger> shadeslayer: this no qsharedpointer stuff is nothing but trouble
[18:35] <shadeslayer> heh
[18:36] <shadeslayer> apachelogger: we could use DBus
[18:36] <shadeslayer> oh but QML doesn't do DBus
[18:36] <apachelogger> how would that fix antyhing?
[18:36] <shadeslayer> can't use dataengines as well
[18:36] <apachelogger> how would they fix anything?
[18:36] <apachelogger> "put random shit into your software until it stops crashing"?
[18:36] <shadeslayer> apachelogger: you could read data from a data engine into a QML plasmoid
[18:37] <apachelogger> shadeslayer: yeah, how does that help with scope?
[18:37] <apachelogger> because a dataengine is really nothing but a fancy model
[18:37] <shadeslayer> scope?
[18:37] <shadeslayer> ah
[18:37] <apachelogger> that said
[18:37] <apachelogger> could use a model
[18:37] <shadeslayer> the scope of QList<QCalEvent*> ?
[18:37] <apachelogger> that way the events could be held within the model and all would be good
[18:38] <apachelogger> shadeslayer: yes
[18:38] <apachelogger> paritcularly the ptr
[18:38] <shadeslayer> hmm
[18:38] <apachelogger> it has undefined scope when being passed to the Q
[18:39] <apachelogger> then apachelogger in his infinite wisdom likes to run multiple updates at once which might change a model while being accessed
[18:39] <apachelogger> boom
[18:39] <apachelogger> model being the list
[18:40] <apachelogger> worse yet, unless I run compares on the events they need to be all wiped and redone inbetween updates
[18:40] <apachelogger> making all previous invalid up until the new model arrives
[18:50] <apachelogger> context omnomonom
[19:01] <yofel> o/
[19:03] <shadeslayer> hey yofel
[19:03] <shadeslayer> back from vacation?
[19:03] <yofel> yep
[19:03] <shadeslayer> yofel: great, go check my digikam merge :P
[19:04] <yofel> just wondering how to add the archive version to my repo stat page. I could a) take it from apt-cache b) do the same but update apt-cache on every update (10min) c) fetch version from launchpad
[19:04] <shadeslayer> yofel: btw the bug number is wrong in your current changelog which is in bzr :P
[19:04] <shadeslayer> i
[19:04] <shadeslayer> use lp lib i'd say
[19:04] <yofel> shadeslayer: the FFe didn't yet exist back then. 2.0.0 does fix *that* bug too
[19:05] <shadeslayer> yofel: but isn't that a Qt bug or sth?
[19:05] <yofel> would also be my favorite way, but I'm wondering how to do that fast enought since I need to combine bash + python
[19:05] <yofel> shadeslayer: well, not sure, at least it's fixed
[19:05] <shadeslayer> fooey
[19:05] <shadeslayer> yofel: create a new language combining the 2 :P
[19:05] <shadeslayer> like QML xD
[19:06] <yofel> currently the page is created by bash, and there's a python script to fetch the existing repositories from LP
[19:06] <shadeslayer> also look at the poll i sent you, add/remove questions etc
[19:06] <yofel> now I'm wondering if I shouldn't just rewrite the whole thing in python
[19:06] <shadeslayer> yofel: store the stuff you get from LP into a file and read it into bash?
[19:07] <shadeslayer> bug 781128 << qt4-x11 bug
[19:07] <yofel> shadeslayer: yeah, which I'll probably do for now and rewrite it at some point
[19:07] <shadeslayer> which is weird
[19:07] <yofel> shadeslayer: ah, didn't see that, thanks
[19:07] <shadeslayer> SourcePackage: digikam
[19:07] <shadeslayer> wtf?
[19:07] <shadeslayer> ah right apachelogger explains why
[19:08]  * shadeslayer got confused for a second there
[19:44] <apachelogger> shadeslayer: ok, I think a model
[19:45] <apachelogger> this is getting way out of hand here
[19:45] <apachelogger> brrrr
[19:45] <shadeslayer> hahaha
[19:45] <apachelogger> 7 models
[19:45] <apachelogger> for 7 days
[19:45] <apachelogger> *2
[19:45] <shadeslayer> WHAT
[19:45] <shadeslayer> @_@
[19:45] <apachelogger> models being qlists again
[19:45] <shadeslayer> that is maddness
[19:45] <apachelogger> plus the scope issue is still there anyway
[19:45]  * apachelogger waves fist
[19:45]  * bulldog98 thinks he found the issue with icecc not supporting i386 client when building on amd64 for i386
[19:46] <bulldog98> I need a crosscompiler for that, I’m currently doing a package for that
[19:47] <apachelogger> shadeslayer: loading is rather instant now
[19:47] <shadeslayer> apachelogger: with 7 models?
[19:47] <apachelogger> yes
[19:47] <shadeslayer> are  you sure? :P
[19:47] <apachelogger> well
[19:47] <shadeslayer> did you thread them?
[19:47] <apachelogger> they only do points
[19:47] <apachelogger> no
[19:47] <shadeslayer> but then there's no point of threading
[19:47] <apachelogger> only parsing is threaded
[19:47] <shadeslayer> you only have a single core
[19:47] <apachelogger> the tearing apart into models is not
[19:48] <apachelogger> which causes lockup for about 0.5 secs
[19:48] <shadeslayer> points?
[19:48] <apachelogger> shadeslayer: sure there is
[19:48] <apachelogger> fancy systems like to put excess load onto the gpu
[19:48] <shadeslayer> ah
[19:49] <apachelogger> at any rate the OS will have an easier job knowing what to schedule when if you have logical unit threads
[19:49] <apachelogger> anywho
[19:49] <apachelogger> parsing is fast
[19:49] <apachelogger> shadeslayer: you are awesome
[19:49] <apachelogger> <3
[19:49] <apachelogger> shadeslayer++
[19:49] <shadeslayer> thank you :)
[19:49] <apachelogger> shadeslayer: thanks!
[19:49] <shadeslayer> hehe :)
[19:50] <shadeslayer> apachelogger: you fixed up the rest of the stuff :P
[19:50] <apachelogger> dunno
[19:50] <apachelogger> I pretty much broke the app
[19:50] <shadeslayer> lol
[19:50] <apachelogger> working copy of qcal in git should be good to go though
[19:50] <shadeslayer> yup
[19:50]  * apachelogger did some minor changes apparenlty
[19:51] <apachelogger> ah yeah
[19:51] <apachelogger> parse are slots now
[19:51] <apachelogger> though I cannot recall why I made them slots
[19:51] <apachelogger> might be a bogus change
[19:51] <shadeslayer> heh
[19:51] <apachelogger> or not, because they probably should be slots as they represent actions
[19:51] <apachelogger> you could create a parser, move it to a thread and then invokemethod parse on it
[19:52] <shadeslayer> sounds right
[19:52]  * apachelogger has put it into a qrunnable though as he has to do more stuff after/before parsing
[19:53] <shadeslayer> apachelogger: re write the QML from the ground up to suit the parser :P
[19:53] <apachelogger> nothing to be rewritten
[19:53]  * apachelogger is a good software designer :P
[19:53] <shadeslayer> ah, problem of scopes :P
[19:53] <apachelogger> the qml stuff knows no nothing about no parser
[19:53] <apachelogger> it knows about a model provider
[19:54] <apachelogger> shadeslayer: I'll just have to migrate to a proper abstractitemmodel
[19:54] <shadeslayer>  42 files changed, 1689 insertions(+), 154 deletions(-)
[19:54] <apachelogger> which ought to be supported in QML IIRC
[19:54] <shadeslayer> @_@
[19:54] <apachelogger> even better than qobject* models
[19:55] <apachelogger> then the qml items would not have to work with the pointers directly but only get the data from the model
[19:55] <apachelogger> so the ptr scope is under control then
[19:55] <apachelogger> plus I can get rid of the 7 models
[19:55] <apachelogger> shadeslayer: where is that from?
[19:56] <shadeslayer> yer git repo
[19:56] <shadeslayer> i hadn't updated
[19:56] <apachelogger> ah
[19:56] <apachelogger> I also implemented the raw stuff for maemo5 :P
[19:56]  * apachelogger looks up
[19:56] <shadeslayer> haha i can see that
[19:57] <apachelogger> http://i.imgur.com/I7njX.png
[19:57] <apachelogger> I think my app is the only qml app on maemo5 that actually implements the stacked window system
[19:57] <apachelogger> i.e. you can stack a window ontop of another window and the blue X in the top right corner turns into a back icon
[19:57] <shadeslayer> :O
[19:58] <apachelogger> their impl is entirely based on the window manager
[19:58] <apachelogger> completely horrible really
[19:58] <apachelogger> I mean, not in Qt, but if you look at the GTK code necessary
[19:58] <apachelogger> brrrrrr
[19:58] <shadeslayer> heh
[19:58] <apachelogger> no idea how they ever thought that maemo would be a success
[19:59] <apachelogger> ohohoh
[19:59] <apachelogger> doctor who
[19:59] <apachelogger> zomg
[19:59]  * apachelogger completely forgot
[20:01] <apachelogger> question is
[20:01] <apachelogger> what sort of model is my data
[20:01]  * apachelogger always fails to asses this correctly
[20:20] <shadeslayer> i'm sleeping guys
[20:20] <shadeslayer> night
[20:36] <bulldog98> apachelogger: what is the trivial way to get a cross compiler compiling for amd64 on i386?
[21:12] <BarkingFish> i know you can do it the other way round using a wrapper script, bulldog98 - whether it works backwards I don't know.
[21:12] <BarkingFish> there's bits of info on debian's wiki
[21:13] <BarkingFish> http://wiki.debian.org/DebianAMD64Faq
[21:13] <bulldog98> BarkingFish: main problem is that crosscompiler should be used in icecream
[21:13] <bulldog98> but thx anyway
[21:13] <BarkingFish> no problem
[21:13] <BarkingFish> sorry for butting in :)
[21:15] <yofel> bulldog98: icecc-build-native is what packages the compiler IIRC, can't you adjust that?
[21:16] <yofel> not sure how it works
[21:16] <bulldog98> yofel: I looked into that but it’s some obscure stuff
[21:16] <yofel> hm
[21:16] <bulldog98> and I don’t know if i386 gcc can build amd64 out of the box
[21:17] <bulldog98> seems like I have to rebuild binutils and gcc
[21:17]  * bulldog98 will create i386 packages for crosscompiling to amd64
[21:28]  * bulldog98 gives up, cause it’s to late to manage that stuff
[21:28] <bulldog98> I’ll build that stuff by hand
[21:28] <bulldog98> and not package an deb
[21:34] <bulldog98> apachelogger: how do I access the people.ubuntu.com page (I want to upload a icecc cross compile tarball)
[21:34] <apachelogger> go there
[21:34] <apachelogger> it tells you how
[21:39] <bulldog98> thx
[21:44] <bulldog98> apachelogger: I get Permission denied (publickey). with the key that is register in lp since ever
[21:44] <apachelogger> maybe not synced yet
[21:44] <apachelogger> or you are in fact using the wrong key
[21:45] <bulldog98> apachelogger: that’s the key that works for pushing to lp, so it’s the right one
[21:45] <apachelogger> not synced I guess
[21:45] <apachelogger> or dolphin is broken
[21:45] <apachelogger> I have seen weird key issues with sftp
[21:55] <yofel> bulldog98: using ssh or sftp? there's no shell on people.ubuntu.com
[22:01] <bulldog98> yofel: both
[22:03] <apachelogger> ditch the code from your knownhosts and try again
[22:03] <apachelogger> with sftp
[22:03] <apachelogger> in dolphin
[22:03] <apachelogger> as first try
[22:10] <bulldog98> it says something about timeout
[22:11] <bulldog98> sftp://people.ubuntu.com/~bulldog98/ is in my bar is that ok?
[22:12] <apachelogger> no
[22:12] <apachelogger><EMAIL_ADDRESS>[22:12] <bulldog98> ah ok
[22:13] <bulldog98> still the same error message
[22:15] <bulldog98> hm ok works now strange