[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> sftp://apachelogger@people.ubuntu.com/
[22:12] <bulldog98> ah ok
[22:13] <bulldog98> still the same error message
[22:15] <bulldog98> hm ok works now strange