--- Log opened Tue Dec 13 15:41:16 2005
15:41 -!- robtaylor [n=rob@nat5.sesnet.co.uk] has joined #dogtail
15:41 -!- Irssi: #dogtail: Total of 8 nicks [0 ops, 0 halfops, 0 voices, 8 normal]
15:41 -!- Irssi: Join to #dogtail was synced in 1 secs
15:41 -!- Irssi: #dogtail: Total of 8 nicks [0 ops, 0 halfops, 0 voices, 8 normal]
15:43 < robtaylor> tko: hey what are you doing here? :)
15:44 < robtaylor> dhm_away: 'lo
15:44 < tko> idling
15:45 < tko> I came to ask about how to run python+dogtail on desktop and the necessary at bits on 770, but no one apparently has tried it (it should be a matter of configuring ORBit2 to work over TCP/IP but...)
15:45 < tko> and as usual, I forgot to go away :)
15:45 < robtaylor> uurk, soudsn difficult
15:45 < robtaylor> why not just run it on the 770?
15:46 < robtaylor> of course none of the current widgets have ATK iirc, so its a bit, umm acacdemic atm..
15:46 < robtaylor> ;)
15:46 < tko> robtaylor, run python + bonobo + orbit on 770? what are you smoking, I want some :-P
15:47 < robtaylor> tko: does dogtail require bonobo and orbit?!
15:47 < robtaylor> eek
15:47 < tko> adding atk support wouldn't be that difficult
15:47 < robtaylor> tko: no, but someone needs to do it...
15:47 < zack> robtaylor: it requires at-spi, which at the moment needs bonobo, yeah
15:48 < tko> robtaylor, yes, well, we're doing it *g*
15:48 < robtaylor> zack: argh
15:48 < robtaylor> tko: coool :)
15:48 < tko> but trying to squeeze python+dogtail there is.. err.. academic :)
15:48 < robtaylor> tko: hmm, difficult
15:49 < robtaylor> tko: which dept are you in btw?
15:49 < robtaylor> tko: python runs pretty well, if there wasnt a bonobo dep, i think it'd be fine
15:49 < zack> robtaylor: yeah, at-spi was designed to work with^W^Wneed CORBA, not that i've heard of anyone using at's over a network...
15:49 < tko> robtaylor, desktop, same as onne
15:49 < robtaylor> tko: we demoed the telepathy stuff just using python
15:50  * zack wasn't aware maemo didn't use atk! ;)
15:51 < zack> tko: any other issues besides the lack of atk/bonobo?
15:51 < tko> zack, we don't support left handed people that well, how well do you think we support the blind? :)
15:51 < zack> tko: haha
15:51  * zack imagines a 770 user with a braille monitor
15:51 < robtaylor> i can imagine one with a screen reader, mind you
15:51 < zack> well, a screen reader could work
15:52 < zack> but what kind of input would you need to replace the touchscreen? scary.
15:52 < tko> zack, bonobo isn't an issue as such, yes you can run dogtail on the device (I suppose) but the test framework would eat hogs of memory and limit our options
15:52 < zack> tko: would using huge RSMMC cards just for testing purposes help?
15:52 < robtaylor> well anyway, the reason i came in that we're planning soemthing similar to dogtail for frobbling dbus objects
15:53 < tko> and atk enables you to test only so much (completely lacks testing, for example, stylus drags)
15:53 < robtaylor> and i was wondering if it made sense to do this as a component of dogtail or not
15:53 < tko> but for application testing it's probably ok
15:53 < tko> zack, swap on mmc.. well, maybe :)
15:53 < zack> tko: yeah, well at-spi is more than just atk. dogtail has working raw input.
15:53 < zack> robtaylor: hmm, interesting - but i'm not quite sure i understand
15:54 < robtaylor> zack: heh, i'm not sure *i8 understand either, just trying out ideas atm..
15:54 < robtaylor> zack: what dont you understand?
15:55 < zack> robtaylor: i'm just trying to figure out what you're planning - a GUI test tool using dbus instead of at-spi, or...?
15:55 < robtaylor> zack: ooh no
15:55 < tko> I think there was some at-spi implementation using dbus which would be great for us... =)
15:55 < zack> tko: that'd be nice
15:55 < robtaylor> tko: hmm, well maybe we can think about that
15:55 < robtaylor> i have some resources
15:56 < zack> as long as you give me the same wonky api, it'll work
15:56 < zack> a better api would be... better, but then we'd have compatibility issues, of course
15:56 < robtaylor> zack: no, this is just calling dbus objects, or exposing 'fake' objects and responding to signals ets
15:57 < zack> robtaylor: oh ok, that was my second guess :)
15:57 < robtaylor> zack:  heh
15:57 < tko> hmm.. using dbus gobject wrapper to wrap AtkObjects ?
15:57 < dhm_away> hi robtaylor!
15:57 < robtaylor> basically we're gonna do it, and it just needs a home..
15:57 < robtaylor> dhm_away: hey :)
15:57 -!- dhm_away is now known as dhm
15:58 < robtaylor> dhm_away: i sold dogtail to the N testing guys a couple of months ago.. 
15:58 < zack> robtaylor: N? Novell?
15:58 < robtaylor> dhm: think you can make it run without bonobo? ;)
15:58 < robtaylor> zack: no, the other one ...
15:58 < dhm> robtaylor: I think it can be made to work without bonobo
15:58 < dhm> nokia?
15:59 < robtaylor> yep
15:59 < zack> robtaylor: Nokia? then they need to use atk on the 770, no?
15:59 < robtaylor> zack: indeed, hence mine and tko's discussion earlier ..
15:59 < dhm> hi tko!
15:59 < zack> dhm: sure, it can be done, but someone would have to totally gut at-spi
15:59  * dhm is not a fan of bonobo
15:59 < robtaylor> is that the only way?
15:59 < zack> well
15:59 < dhm> robtaylor: that would probably be the best way
16:00 < zack> i guess maybe reimplement it
16:00 < tko> dhm, oh, we hate bonobo.. :)
16:00 < robtaylor> tko: if we managed that, do you think it would be tractable for testing?
16:00  * dhm contemplates founding #bonobo-haters
16:00 < robtaylor> tko: or do you think having this running on the device would squew results too much?
16:00 < robtaylor> dhm: go for it ;)
16:00 < zack> my understanding of bonobo is limited, but i can at least say that getting rid of orbit would mean a lot of work.
16:01 < dhm> robtaylor: would it basically be a port to dbus rather than bonobo?
16:01 < robtaylor> dhm: *shrug* just asking for theoretical purposes
16:02 < zack> there was some talk, long ago, about removing at-spi's dependency on corba in general
16:02  * zack doesn't know where that went
16:02  * dhm decides to actually _read_ the scrollback to gigure out what on earth you're trying to do
16:02 < tko> robtaylor, well, once we get atk support we could do a lot of testing on the desktop already. replacing bonobo/orbit with dbus would let us do more on the target device as well
16:02 < dhm> figure outm even
16:02 < robtaylor> tko: thats a good point, we can do a lot of testing just with xephyr
16:03 < zack> tko: yeah? what would moving to dbus give you besides getting rid of bonobo?
16:03 < robtaylor> dhm: after you've read scollback, some feedback on my origional q would be interesting :)
16:04 < robtaylor> zack: well the device is already running dbus
16:04 < zack> robtaylor: yes, but i'm wondering how that lets you do more
16:04 < robtaylor> so, i know nothing about at-spi..does this reside in every app?
16:05 < tko> zack, orbit+bonobo are nothing but overhead, and if you read any of the reviews you'd know there's not that much memory to spare
16:05 < robtaylor> zack: oh, its just a matter of limited resources
16:05 < zack> robtaylor: basically, gtk uses atk internally to export information and procedure calls to at-spi
16:05 < dhm> robtaylor: basically it's an IPC mechanism
16:06 < zack> tko: yeah, i understand the memory issue
16:06 < dhm> the applications expose the UI metadata in the form of a tree of objects that support interfaces
16:06 < zack> add more memory! :)
16:06 < dhm> which currently is published using a CORBA server...
16:06 < robtaylor> righty
16:06 < dhm> the AT-SPI C interface is simply a C wrapper around a load of CORBA client calls
16:06 < robtaylor> dhm: my initial guess was more or less right then ;)
16:07 < dhm> so a plan would be:
16:07 < robtaylor> so this defines the ipc that dogtail uses to talk to the app and control the ui.
16:07 < zack> robtaylor: yes
16:07  * dhm believes that in theory if you port two underlying wrapper layers from CORBA to DBus it ought to work...
16:08 < dhm> i.e. the wrapper layer in ATK that toolkits uses to expose themselves (as it were)
16:08 < robtaylor> modulo nasty bitty bits, of course ;)
16:08 < robtaylor> right
16:08 < robtaylor> dhm: but my origional question wasn't about this ;)
16:08 < dhm> and the wrapper layer in AT-SPI which is used by consumers of that metadata (screenreaders, andf the like, plus dogtail etc)
16:09 < robtaylor> dhm: my orgional question was would a module to do dogtail like frobbling of dbus objects be a welcome addition?
16:09 < dhm> robtaylor: OK, please help me.  What's the original question?
16:09 < zack> dhm: sounds right
16:09 < dhm> ah
16:09 < robtaylor> (modulo spelling mistakes ;)
16:09  * dhm regrets that his telepathy skills are still under development :-P
16:09 < zack> robtaylor: i'm thinking about how that'd work. what's an example use case?
16:10 < robtaylor> dhm: heh ;)
16:10 < zack> robtaylor: bah, your *original* question was about dependencies :)
16:11 < robtaylor> zack: well, say, for example... you have an gui app thats controlled by dbus signals (e.g. notifications) and you want to script testing this
16:11 < zack> oh!
16:11 < zack> so f.e. for testing NetworkManager
16:12 < dhm> hmmm... my gut reaction is "use the python dbus bindings"
16:12 < zack> faking network events
16:12 < zack> (er, nm-applet)
16:12 < dhm> oh
16:13 < dhm> robtaylor: by "frobbling" do you mean (i) inspecting (ii) simulating ?
16:13 < zack> he wants to create fake dbus objects
16:13 < robtaylor> dhm: both, and emulating
16:13 < dhm> (there's a sentence I didn't think I'd be typing when I got up this morning)
16:13 < robtaylor> maybe for emulating, it makes more sense to just go straight to the bindings
16:14 < zack> robtaylor: well, how much of an abstraction layer do you need on top of the dbus bindings?
16:14 < robtaylor> but we need to build a suitably simple way for the simple testing people to do the script writing...
16:14 < robtaylor> probably not that big
16:14 < dhm> ah
16:15 < dhm> maybe that's a valid use case then
16:15 < zack> but it's safe to say you'll need one? (i don't know the dbus api)
16:15 < robtaylor> zack: yep, you need a little something, thats for sure
16:16 < zack> so it sounds like a certain amount of tests using dogtail might want to be able to fake dbus objects, as in the NM example
16:16 < zack> but i'm trying to think of a sane way to integrate it...
16:16 < robtaylor> cool, thats why i came to ask ;)
16:17 < zack> it probably doesn't help that dbus is a giant black box to me at the moment :)
16:17 < robtaylor> yep, at the moment the python bindings are very event oriented, this probably isnt great for those script writers..
16:17 < dhm> robtaylor: I just spoke briefly to J5
16:17 < robtaylor> dhm: heh
16:17 < zack> do the python bindings have docs online?
16:18  * dhm isn't that familiar with the dbus API or bindings atm
16:18 < dhm> robtaylor: one idea I had is that DBus supports introspection of interfaces
16:18  * zack is googling
16:18  * robtaylor is pretty familiar
16:18 < robtaylor> yep
16:18 < dhm> robtaylor: so you could do an XML dump of an interface...
16:18 < robtaylor> yep
16:19 < dhm> do the bindings allow you to use this to dynamically generate a python class?
16:19 < robtaylor> dhm: not at the moment, no
16:19 < dhm> is it the sort of thing for which a patch could be written and would be accepted into dbus?
16:20 < robtaylor> well, that i'm not so sure about
16:21 < robtaylor> it would kinda confuse the python bindings i think
16:21 < dhm> am i gith in thinking that currently a scriptwriter already has the ability to emulate a real DBus service, but that it's really longwinded ATM?
16:21 < dhm> gith = right
16:21 < robtaylor> i guessed ;)
16:21 < dhm> (dunno how that happened)
16:21 < zack> wow :)
16:21 < dhm> Microsoft "Natural" Keyboard
16:22 < robtaylor> well.. a python coder could pretty easily do it
16:22 < dhm> (about the only MS product I sill use)
16:22 < dhm> sill=still     gah.....
16:22  * robtaylor always has days like that...
16:23 < dhm> robtaylor: would it (i) be a pain for an experienced python coder, and/or (ii) far too hard for a novice python coder?
16:23 < robtaylor> (ii)
16:23 < dhm> but not (i)?
16:23 < robtaylor> no, its pretty nice for an experience python coder, i think
16:24 < robtaylor> *d
16:24 < dhm> gah, it's contagious!
16:25 < zack> is it something that could be abstracted out to be easy enough, and still general enough, that said novice coder could emulate whatever dbus service he needs?
16:26 < robtaylor> zack: not sure i understand what you're asking :/
16:26 < robtaylor> dhm: http://cvs.freedesktop.org/dbus/dbus/test/python/test-client.py?rev=1.18&view=markup for example client code
16:29 < robtaylor> dhm: i'd really prefer a script writer to do soemthing more like "a = interface.get("/foo/Bar", "foo.Bar.Moo"); a.Badger(); waitforsignal(a, "Badgered"); "
16:29 < robtaylor> etc
16:29 < robtaylor> and was thinking that kinda fits in with the way dogtail works ;)
16:30  * dhm quite likes the idea of using introspection to dump the XML, and then having an Emulator class that takes this XML... simple for a novice to understand?
16:31 < robtaylor> maybe, maybe.i already have the code to dump xml from objects from arbitary object/interface lists
16:31 < dhm> that "methods" thing looks hard to explain to a newbie
16:31 < zack> dhm: yeah, that's not a bad idea
16:31 < robtaylor> (i use it to pull xml from python, then i generate gobjects from this... ;)
16:31 < dhm> so you'd have something like:
16:31 < dhm> class Emulator:
16:31 < zack> robtaylor: yeah, i was just asking in a confusing way if what you just typed was possible :)
16:31 < dhm>   def __init__(self, xmlFile):
16:31 < dhm>      etc
16:32 < robtaylor> oh, i gotta go pick up my gf from the station, bbiab.. i'll read scrollback :)
16:32 < dhm> and then e = EMulator("dump-of-NetworkManager.xml")
16:32 < dhm> dir (e) would show you the methods you can overrride
16:32 < dhm> and have sane defaults for each one
16:32 < zack> dhm: how do we know what sane defaults would be?
16:33 < dhm> though that's very much like a IDL/CORBA stubs approach
16:33 -!- s1aden [i=paul@starsky.19inch.net] has joined #dogtail