**** BEGIN LOGGING AT Thu Nov 06 02:59:57 2008
Nov 06 03:51:16 <gambler> is anyone else having problems with eclipse/android?
Nov 06 03:51:18 <gambler> eclipse is going haywire/bluescreening for me.
Nov 06 03:51:23 <gambler> its not compiling
Nov 06 03:51:47 <gambler> Error log says: "Unable to execute dex: null" Plug-in: com.android.ide.eclipse.adt
Nov 06 03:52:07 <michaelnovakjr_> gambler: windows?
Nov 06 03:52:13 <gambler> michaelnovakjr, yep
Nov 06 03:52:41 <michaelnovakjr_> :( i'm on linux.. i had issues with androind in general, but it was an ubuntu upgrade that wiped my java settings
Nov 06 03:53:29 <gambler> Its all so sudden, thats what I dont understand
Nov 06 03:53:57 <gambler> ive got eclipse on my linux box too, but I prefer windows because it supports my multi-mon setup
Nov 06 03:54:24 <gambler> :/
Nov 06 03:54:35 <michaelnovakjr_> and linux doesn't :) ?
Nov 06 03:54:53 <gambler> does it?
Nov 06 03:55:03 <gambler> can you do >2 monitors?
Nov 06 03:55:08 <michaelnovakjr_> i do
Nov 06 03:56:03 <michaelnovakjr_> gambler: what linux do you use?
Nov 06 03:56:19 <gambler> FC
Nov 06 03:56:50 <michaelnovakjr_> nvidia graphics?
Nov 06 03:57:01 <gambler> yeah
Nov 06 03:57:28 <michaelnovakjr_> look up nvidia in your package manager
Nov 06 03:57:32 <gambler> GeForce 7600gs
Nov 06 03:57:35 <gambler> ok ill take a look
Nov 06 03:57:48 <gambler> did you fix the fonts in eclipse?
Nov 06 03:57:51 <michaelnovakjr_> there's nonfree drivers for me that work great, but i'm on debian..... shouldn't matter though just not sure
Nov 06 03:57:58 <michaelnovakjr_> gambler: i use monospace
Nov 06 04:00:20 <gambler> michaelnovakjr, do you know if there is a linux version of ultramon?
Nov 06 04:01:23 <michaelnovakjr_> not sure
Nov 06 04:01:50 * gambler thinks...if I switch back to linux I dont have to devote an entire monitor to this box anymore :/
Nov 06 04:02:58 <michaelnovakjr_> :)
Nov 06 04:03:03 <michaelnovakjr_> its not a bad idea
Nov 06 04:08:42 <gambler> michaelnovakjr, quick question, I havent configured X manually in a looong time.
Nov 06 04:08:52 <gambler> I just looked at Gnome->System->Display->Dual Head  ...that looks like it only supports 2 monitors
Nov 06 04:08:59 <gambler> Ive got 3 here
Nov 06 04:09:12 <gambler> how do you hand that
Nov 06 04:09:18 <michaelnovakjr_> there's a package nvidia-settings and nvidia-xconfig
Nov 06 04:09:26 <michaelnovakjr_> did you grab those?
Nov 06 04:09:40 <gambler> no I havent actually set it up yet. ok so those are alternate config utils
Nov 06 04:09:51 <michaelnovakjr_> yea, those are the ones i use
Nov 06 04:10:02 <gambler> ok that clarifies
Nov 06 04:51:41 <jasta> boy it sure would be nice if you could assume success ;)
Nov 06 04:52:07 <jasta> i'm adding all kinds of sophistication in five to handle each type of network error differently hehe
Nov 06 04:52:16 <jasta> based on DownloadProvider
Nov 06 08:04:38 <jasta> hmm, gsm data off doesn't actually shut off data?
Nov 06 08:04:49 <jasta> how do i simulate a total loss of connection?  iptables + gsm data off?
Nov 06 08:12:50 <languish> airplane mode?
Nov 06 08:13:00 <languish> lead box?
Nov 06 08:13:06 <jasta> i mean in the emulator
Nov 06 08:13:13 <languish> ah :)
Nov 06 08:13:47 <jasta> iptables + gsm data off seems to work ok.  might just make a script to do them both at the same time at least
Nov 06 14:24:28 <vol> Clever android fellows using gdb, what version of gdb are you using?
Nov 06 14:24:39 <vol> The GDB I'm using is from here
Nov 06 14:24:40 <vol> http://www.billrocks.org/ideas/index.php?/archives/20-Debugging-Android-Native-C-Applications-with-gdb.html#extended
Nov 06 14:25:03 <vol> or should I recompile my own copy
Nov 06 14:35:00 <vol> In any event, ttuttle, I spoke to the dev who's been working on this a little longer than I, and apparently HTC is staunchly against the idea of us running against their libs like the surface flinger, in that those may change unexpectedly any second
Nov 06 15:04:01 <famast> is there a download manager service?
Nov 06 15:09:35 <jbq> famast: yes there's one, but it's not currently accessible to 3rd-party apps.
Nov 06 15:10:10 <famast> ah bummer, but thanks anyways
Nov 06 15:12:16 <famast> downloads.java?
Nov 06 15:12:46 <jbq> That's where the public API would eventually be (if it becomes public at some point)
Nov 06 15:13:17 <jbq> The actual implementation is here: http://git.source.android.com/?p=platform/packages/providers/DownloadProvider.git;a=summary
Nov 06 15:14:25 <jbq> (unfortunately you can't take it "as is" and re-use it directly in your app, as it itself uses a few private APIs)
Nov 06 15:15:51 <famast> ah nooo!
Nov 06 15:16:42 <jbq> I'd like to clean that up in the future, but the code was written before we had a clear notion of what would be public and what would be private.
Nov 06 15:25:45 <Tauno> ..or you could also take the dependent stuff "as is" and put it directly in your app :P
Nov 06 15:28:43 <jbq> Tauno: not easy, as some of it is JNI.
Nov 06 15:29:26 <Tauno> crap
Nov 06 15:29:30 <Tauno> sorry
Nov 06 15:30:52 <jbq> It'd still be possible to do it, but that'd require a bit more work overall.
Nov 06 15:31:55 <jbq> I mean, it'd be possible to adapt the code to re-use in an app, but that'd require a few tweaks here and there.
Nov 06 15:32:22 <jbq> A good number of the private APIs are for functions that wouldn't matter for apps, so the code in question could be removed entirely.
Nov 06 15:39:27 <famast> Is there any timeline for when it is expected to go public?
Nov 06 15:39:30 <Tauno> jbq, are you by any chance familiar with ListView dividers?
Nov 06 15:39:45 <jbq> Tauno: not at all
Nov 06 15:39:52 <Tauno> anyone else?
Nov 06 15:40:28 <jbq> famast: At this point the download manager is likely to stay unchanged for a while.
Nov 06 15:40:41 <Tauno> android:divider="#FFFF0000" removes the divider completely... setting the prop to anything at all removes the divider completely :/
Nov 06 15:54:37 <Tauno> headcrabs..
Nov 06 15:55:40 <SanMehat> ?
Nov 06 16:02:45 <Tauno> it just does not work... I mean.. I even cried a little.. and it still does not work.. no way to change the divider color :|
Nov 06 16:05:21 <Tauno> oh well.. time to dig into source again :/
Nov 06 17:12:52 <vol> headcrabs?
Nov 06 17:16:46 <Tauno> well.. it felt like headcrabs (it still does)
Nov 06 17:16:56 <Disconnect> ...huh?
Nov 06 17:17:51 <Tauno> I see you have never had headcrabs? :P
Nov 06 17:19:20 <Tauno> I finally got the listview divider color changed (have not figured out yet how do do it from xml) but now the whole listview is with that color... everything is OK only when I scroll the view.. as soon as I stop the listview is filled with the divider color
Nov 06 17:20:20 <Tauno> romainguy was the key that I needed to get there.. but he vanished and I'm stuck at this stage..
Nov 06 17:25:28 <Tauno> I'm ready to ship Estonian beer to somebody who helps me out with this :P (wonder if I can ship alcohol by mail? :P)
Nov 06 17:36:26 <michaelnovakjr> Tauno: have you set android:divider on the ListView in xml?
Nov 06 18:24:10 <F_R_I_T_Z> TO ALL> Anyone have a pieve of idea of what happens with XDA SITE?
Nov 06 18:25:31 <michaelnovakjr> ?
Nov 06 18:25:38 <Disconnect> TO F_R_I_T_Z> Maybe you should ask somewhere more appropriate
Nov 06 18:32:26 <F_R_I_T_Z> Hupss, my mistake.. i write in wrong channel. APOLOGIZE... :-)... iam RED NOW
Nov 06 18:57:26 <romainguy> Tauno: I just fixed the bug about the ColorDrawable used as a divider
Nov 06 19:15:38 <famast> Anyone have any suggestions on writing threads that play nicely when you have to clean them up due to an onPause/onStop/onDestroy event?
Nov 06 19:17:11 <romainguy> depends on your thread :)
Nov 06 19:18:39 <famast> I have a thread that opens an InputStream and parses a response from a server
Nov 06 19:19:20 <famast> I could call thread.interrupt(), but apparently that only works when the thread is waiting?
Nov 06 19:20:56 <andyross> Never kill a thread from outside.  You don't know what state it's in, and thus can't recover from whatever race condition results.  Setting a kill flag in an atomic (!) variable works.  Or have the threads read from a work queue filled from the main thread, and stuff an "end" token in it.
Nov 06 19:21:39 <jbq> what andyross said.
Nov 06 19:22:13 <andyross> Not sure about the Java end of things, but if you close the underlying file descriptor the existing readers will wake up and return an error.  So that's probably worth trying if it's implemented the way I think it should be.
Nov 06 19:23:31 <romainguy> what andyross said :)
Nov 06 19:23:38 <famast> lol thank you
Nov 06 19:24:06 <romainguy> in Java, you want your stop flag to be a volatile variable
Nov 06 19:24:33 <famast> so if I use atomic variables, my thread would something like..
Nov 06 19:24:33 <famast> if (!kill) { doSomething()}
Nov 06 19:24:33 <famast> if (!kill) { doSomethingElse()}
Nov 06 19:24:59 <romainguy> pretty much
Nov 06 19:25:08 <romainguy> also note that if your thread can finish quickly, you can just let it finish
Nov 06 19:25:17 <romainguy> without stopping it
Nov 06 19:25:48 <romainguy> famast: does your thread do something with the UI when it's done parsing the server's response?
Nov 06 19:26:52 <famast> volatile variable.. ok learn something new every day. You can tell I don't do much concurrent programming
Nov 06 19:27:09 <famast> yea my thread sends a message to a handler
Nov 06 19:27:14 <romainguy> ok then you should use this instead: http://code.google.com/p/apps-for-android/source/browse/trunk/Photostream/src/com/google/android/photostream/UserTask.java
Nov 06 19:27:26 <romainguy> it's a class meant to make background thread/ui thread interaction easier
Nov 06 19:27:31 <romainguy> it also supports cancellation
Nov 06 19:27:49 <famast> interesting, thank you I will check it out!
Nov 06 19:27:54 <romainguy> (it's gonna be part of a future SDK under a new name)
Nov 06 19:31:38 <Disconnect> so how do i convince repo to give me a diff withut prettyprinting it?
Nov 06 19:33:50 * Disconnect could copy/paste it but.. uck
Nov 06 19:36:40 <andyross> "git diff" ?
Nov 06 19:37:30 <Disconnect> repo diff shows a ton of changes. git diff shows nada (no matter where i run it from)
Nov 06 19:37:41 <Disconnect> oooh. scratch that. found it. :)
Nov 06 19:46:13 <jasta> hmm
Nov 06 20:33:05 <famast> What exactly is a device independent pixel anyhow
Nov 06 20:33:27 <famast> pixels seem very dependent on devices :)
Nov 06 20:34:15 <Disconnect> its a vague number that should be tuned on each different resolution to produce 'about' the same results on different devices
Nov 06 20:34:21 <Disconnect> (tuned by the device maker)_
Nov 06 20:35:15 <andyross> I think the intent is to allow for future devices with intentionally different pixel size concepts.  Think of PalmOS when it went from 160x160 to 320x320.  The "new" pixels were high pitch, but the screens were still  the same "psychological size".
Nov 06 20:35:32 <famast> so if I used pixels everything would appear smaller
Nov 06 20:35:40 <famast> (going with this PalmOS scenario)
Nov 06 20:35:52 <famast> but using DIP it would look the same
Nov 06 20:36:05 <famast> so why not use inches or mm
Nov 06 20:36:43 <andyross> It's to avoid brain damage like what happens (or used to happen) when you installed the NVIDIA drivers on a odd pitch monitor (like my 15.4" 1920x1200 laptop, or a 47" 1920x1080 TV) and then run a gdm greeter.  It tries to honor the physical DPI and produces bizarre results.
Nov 06 20:36:59 <Disconnect> because 1" is supposed to be 1" everywhere and device-pixels includes actual size, as well. you don't want it to be 1" on a device like an internet tablet (5" display) and the same 1" on the phone
Nov 06 20:37:02 <andyross> Not sure if newer gdm's are still doing that.  But it's weird.
Nov 06 20:37:35 <Disconnect> includes an adjustment for size i mean. so its more of an attempt at normalizing resolution and size (or dpi if you like) across different displays
Nov 06 20:37:42 <andyross> famast: Because physical measurements are still not quite what you want.  A Palm centro has a *much* smaller screen than the original palm, but still wants to display the same kinds of stuff.
Nov 06 20:39:17 <famast> ok right right, everything is clear now to me
Nov 06 20:39:59 <famast> fascinating stuff
Nov 06 21:35:06 <zhobbs> how can I build an unsigned apk in the android-git tree?
Nov 06 21:38:31 <duncanfoo> if I have an app that displays a progression of screens (such as login->interact->drill down, etc) is the intent to model each of these as an activity?
Nov 06 21:41:54 <famast> to my  understanding yes. One benefit is android can then handle the functionality of the back button
Nov 06 21:43:09 <famast> plus it makes it easier to "bookmark" parts of your application. If you ever want to jump into some spot in the middle of your app, its simpler to do so
Nov 06 21:43:23 <duncanfoo> yeah, well I definitely don't want to do that ;)
Nov 06 21:43:34 <duncanfoo> it shoul;dn't be possible to "jump" into the middle without going through the login process :)
Nov 06 21:43:52 <famast> well its only if you design it to be that way
Nov 06 22:06:29 <jasta> zhobbs: you there?
Nov 06 22:06:38 <zhobbs> yep
Nov 06 22:07:01 <duncanfoo> if I define a static member in an Activity is it available to other activities that I launch?
Nov 06 22:07:04 <jasta> i still cannot figure out why the Music app uses a static instance of the service interface in MusicUtils
Nov 06 22:07:18 <jasta> do you have any insight?
Nov 06 22:07:43 <zhobbs> lemme take a look...
Nov 06 22:07:54 <jasta> oh wait, i might have just been looking at the wrong activity
Nov 06 22:08:12 <jasta> I was looking at their StreamStarter, which called bindToService during onResume
Nov 06 22:08:51 <zhobbs> seems like there is some code in there that isn't used
Nov 06 22:08:54 <jasta> well, actually, even if you call it onCreate, what's the point of using a static field?
Nov 06 22:09:26 <jasta> in what case could an activity re-use the static connection?
Nov 06 22:10:43 <zhobbs> it uses that static reference in that BroadcastReceiver
Nov 06 22:10:45 <jasta> the way i look at this is that if each activity's onCreate is calling bindToService, but then they are all sharing the same handle, isn't every activities connection handle just getting updated each time an activity connects?  so maybe this logic is to just avoid keeping lots of interface stubs around, instead of just reallocating 1 each time?
Nov 06 22:11:28 <jasta> oh, that makes sense.  i initially saw this as an optimization to re-use the interface handle, but i dont think that is what they are doing
Nov 06 22:12:33 <zhobbs> hmmm...very strange...
Nov 06 22:14:16 <zhobbs> I guess it's just for convenience to put all the service interaction login in one class?
Nov 06 22:14:23 <zhobbs> logic*
Nov 06 22:16:52 <jasta> zhobbs: yeah i guess.  but it is really misleading to me...
Nov 06 22:17:03 <jasta> i kept thinking it was an optimization
Nov 06 22:41:37 <romainguy> if only there were comments in Android's source code... :))
Nov 06 22:45:55 * andyross finds it (well, except the javadoc areas) refreshingly free of cruft, actually.
Nov 06 22:47:52 <romainguy> many pieces could be much better with documentation
Nov 06 22:47:59 <romainguy> like ListView/AbsListView/AdapterView
Nov 06 22:51:44 <jmo> andyross, what about the javadoc?
Nov 06 22:54:44 <duncanfoo> is it expected to take 2.5minutes to get a connection failed exception connecting to 10.0.2.2 on a port with nothing running?
Nov 06 22:54:48 <duncanfoo> from the emulator obviously :)
Nov 06 22:59:19 <andyross> jmo: Nothing that wouldn't be a meaningless flame.  I'm not a big fan of javadoc.  The idea of automatic documentation generation is sound, but the end result is that javadoc'd source ends up being decidedly *less* readable to me.
Nov 06 22:59:36 <andyross> There's nothing particular wrong with the existing docs as such.
Nov 06 22:59:38 <duncanfoo> looks nice in eclipse ;)
Nov 06 22:59:48 <romainguy> andyross: except with an IDE :)
Nov 06 23:01:06 <jmo> I'm interested in your meaningless flames btw
Nov 06 23:01:54 <fadden> jmo: your hair is funny looking
Nov 06 23:02:03 <andyross> When I read source code (as opposed to reading the generated docs), I'm looking to read the *source* code.  I want to see the implementation, not the specification.  Having paragraphs of HTML markup in front of every function tends to obscure that pretty badly, IMHO.
Nov 06 23:02:25 <jmo> ahh, ok, so it's more about the impact on the source code, than the resultant docs
Nov 06 23:02:40 <jmo> fadden, that's just not fair
Nov 06 23:02:52 <jmo> especially considering your mom
Nov 06 23:02:53 <andyross> Yes, exactly.  Ditto for long block comments of any form, generally.  And honestly I have no idea what eclipse does with javadoc: format the markup inline?  Not sure I'd like that either.
Nov 06 23:03:08 <andyross> Although a "hide javadoc blocks" button would be a nice feature, I guess. :)
Nov 06 23:03:21 <duncanfoo> that's not what I meant... I meant from the point of view of using the source.
Nov 06 23:03:55 <duncanfoo> seeing the docuemntation in the IDE when you click on a function is great.
Nov 06 23:04:08 <romainguy> andyross: IDEs let you do that
Nov 06 23:04:19 <romainguy> andyross: IntelliJ for instance has an option to automatically collapse javadoc blocs
Nov 06 23:04:47 <andyross> The core point being that the questions I'm looking to answer when reading a .java file are by definition not found in the javadoc comments (if they were, I'd be reading the docs, not the source).  To the extent that tools allow that (hell, I wouldn't be surprised if there was something in java-mode along the same lines) I'm all for it.
Nov 06 23:05:34 <duncanfoo> javadoc is the doc AND the source, so ... by definition (of javadoc) you are looking in the right place ;)
Nov 06 23:06:19 <romainguy> javadoc is far from perfect but it brought something great: Java APIs are usually more documented than they would normally be :))
Nov 06 23:06:22 <andyross> We seem to be talking past each other.  The fact that java likes to put the docs *and* the source in the same place is exactly what I'm complaining about: it makes reading the source harder.
Nov 06 23:06:44 <duncanfoo> I realize that... however, I don't agree with you.
Nov 06 23:06:46 <andyross> There's a tool to pull the source out of the documentation.  The reverse is much harder.
Nov 06 23:07:24 <duncanfoo> having the source AND the documentation in the same place is a great asset for many reasons. not the least of which, keeping the source and docuemntation in sync with one another and correct.
Nov 06 23:08:43 <andyross> Might be true (although lots of very good documentation has been generated the old fashioned way, so it's certainly not empirically proved).  But that still doesn't say that reading the source to find a bug isn't complicated by having to wade through comments.
Nov 06 23:10:38 <duncanfoo> if the length of the comments bothers you, then perhaps you need a better IDE which folds the comments. I wouldn't throw the baby out with the bathwater :)
Nov 06 23:11:36 <andyross> Or just maybe I'm not actually wrong.  You aren't in my head, I'm not in yours.  I'm not telling you what tools you should use, just explaining my preferences in the hope that you might be interested.
Nov 06 23:12:46 <duncanfoo> I'm not saying you are wrong... I'm suggesting alternatives that might help you look at java source code with lots of javadoc comments. At any rate, its not a very helpful discussion, since javadoc is here and widely used and isn't likely to go away no matter what you or I say :)
Nov 06 23:13:33 <andyross> ... did I say I wanted it to go away?  Not that I can see.  Hell, I even warned you ahead of time that this was going to turn into a flame war.
Nov 06 23:13:51 <duncanfoo> lol
Nov 06 23:13:56 <romainguy> andyross: you're often the source of such wars it seems :))
Nov 06 23:14:17 <duncanfoo> any comments on the 2.5 minute connection failure response? :)
Nov 06 23:14:19 <andyross> I have opinions.
Nov 06 23:14:32 <romainguy> duncanfoo: nope :(
Nov 06 23:14:45 <duncanfoo> is it expected?
Nov 06 23:14:49 <romainguy> no idea
Nov 06 23:15:15 <duncanfoo> bummer ;(
Nov 06 23:17:56 <jmo> andyross, I wanted to ask, because there's a big refresh of the docs happening now, and I wanted to get any feedback you might have.
Nov 06 23:18:06 <jmo> but I don't think we're going to be able to take your suggestion :-)
Nov 06 23:18:15 <jmo> or your implicit suggestion I mean
Nov 06 23:18:32 <jmo> that said, I'm in favor of getting rid of as much boilerplate stuff as possible.
Nov 06 23:19:01 <romainguy> it'd be nice if all the public APIs were documented ^^
Nov 06 23:21:57 <jmo> romainguy: they all are
Nov 06 23:22:05 <jmo> it lists the functions and their parameters :-D
Nov 06 23:23:08 <romainguy> lol
Nov 06 23:23:19 <romainguy> maybe I should start writing javadocs for my APIs :)
Nov 06 23:23:44 <duncanfoo> once you start using libraries with javadoc APIs from eclipse, it really shows how great it is ;)
Nov 06 23:24:04 <duncanfoo> now what was that parameter again, etc. no more of that crufty stuff
Nov 06 23:24:17 <andyross> But you can do that in a browser.
Nov 06 23:24:38 <andyross> I'm not saying I refuse to read the docs, just that I prefer not seeing them next to source code I'm trying to read.
Nov 06 23:24:41 <romainguy> it's pretty darn useful to type ctrl-j in the IDE on any method call and get the formatted documentation in a popup :)
Nov 06 23:25:16 <duncanfoo> going to the browser, compared to getting it immediately... well that sucks
Nov 06 23:25:16 <jmo> romainguy, how is that working these days?
Nov 06 23:25:22 <romainguy> what do you mean?
Nov 06 23:25:47 <jmo> it's a running battle to keep it formatted reasonably in eclipse, because of how eclipse scrapes the html for the docs
Nov 06 23:26:03 <duncanfoo> the javadoc looks formatted well to me
Nov 06 23:26:05 <duncanfoo> in eclipse that is
Nov 06 23:26:09 <romainguy> I don't know about Eclipse
Nov 06 23:26:09 <jmo> or are you just using it for a platform build, where it doesn't use the generated docs
Nov 06 23:26:10 <jmo> oh, cool
Nov 06 23:26:11 <romainguy> I use IntelliJ
Nov 06 23:26:21 <romainguy> and it formats the raw javadocs from the source
Nov 06 23:26:26 <romainguy> at least in my setup
Nov 06 23:26:29 <jmo> ah oh
Nov 06 23:26:30 <romainguy> so no HTML scraping
Nov 06 23:26:33 <duncanfoo> note: I'm talking about the presentation in the javadoc panel or a popup, not the javadoc in the source code stuff.
Nov 06 23:26:40 <jmo> yeah
Nov 06 23:26:42 <duncanfoo> I don't think eclipse uses HTML scraping either
Nov 06 23:26:53 <romainguy> it does if you don't have the source but just the html
Nov 06 23:27:02 <duncanfoo> ok, that's possible
Nov 06 23:27:08 <jmo> In the SDK, eclipse scrapes the html looking for stuff like <A NAME="MethodName()">
Nov 06 23:27:10 <duncanfoo> I typically only deal with those libraries to which I have the source.
Nov 06 23:27:34 <duncanfoo> speaking of... annoyingly enough none of the Java SDK stuff has javadoc source whne I'm working on android project
Nov 06 23:27:44 <jmo> I had to go dig through eclipse to find out how exactly to write the html so it would find it
Nov 06 23:27:57 <romainguy> duncanfoo: did you grab the source from git?
Nov 06 23:28:05 <duncanfoo> yes
Nov 06 23:28:10 <romainguy> duncanfoo: in that case you could point Eclipse to the java.* packages source code
Nov 06 23:28:13 <romainguy> that should give you the doc
Nov 06 23:28:28 <duncanfoo> I have
Nov 06 23:28:32 <duncanfoo> java.util.List l;
Nov 06 23:28:34 <duncanfoo> for example
Nov 06 23:28:36 <duncanfoo> when I click on List
Nov 06 23:28:42 <duncanfoo> it says: this element has no attached java doc...
Nov 06 23:28:52 <duncanfoo> perhaps I didn't get the source for the SDK libraries? that'spossible
Nov 06 23:29:05 <romainguy> or you didn't point to the right directory
Nov 06 23:29:18 <duncanfoo> I get the source for the android.* stuff
Nov 06 23:29:37 <romainguy> ok
Nov 06 23:29:42 <romainguy> you also want platform/dalvik
Nov 06 23:29:53 <romainguy> and in there, the code you want is in libcore/luni/src
Nov 06 23:30:05 <duncanfoo> ok, I haven't pulled that. thanks!
Nov 06 23:30:06 <romainguy> that's the core (Lang Util Network Io) Java libs
Nov 06 23:30:29 <romainguy> thre's also libcore/text, xml, nio, math...
Nov 06 23:30:45 <duncanfoo> yup, ok, thanks!
Nov 07 00:35:27 <mocsrox> getChangingConfigurations ... is that method reliable on the Activity?
Nov 07 01:29:33 <jasta> hmm, you dont need special permissions to use LISTEN_CALL_STATE?
Nov 07 01:32:32 <jasta> that seems strange.  without permission, i could log the users phone calls?
Nov 07 01:34:44 <michaelnovakjr__> seriously?
Nov 07 01:35:09 <jasta> well, i havent tested it yet, but the docs say that they document what permission you need and they dont say anything for that one
Nov 07 01:35:24 <romainguy> jasta: probably just a doc error
Nov 07 01:36:16 <michaelnovakjr__> :) hopefully
Nov 07 01:43:34 <zhobbs> jasta: I think you need that permission
Nov 07 02:11:23 <zhobbs> why do I only have about 80% of my copy/pastes actually work in eclipse?!?
Nov 07 02:44:09 <zhobbs> seems like it takes too long to inflate a menu from xml...I might go back to doing it in code
Nov 07 02:46:38 <michaelnovakjr__> code's pretty simple
Nov 07 02:46:46 <zhobbs> yeah
Nov 07 02:47:42 <zhobbs> michaelnovakjr__: what android projects are you working on these days?
Nov 07 02:48:03 <michaelnovakjr__> i'm writing an IRC client
Nov 07 02:48:11 <zhobbs> ahh, great
Nov 07 02:48:12 <michaelnovakjr__> and flickr manager..
Nov 07 02:48:36 <michaelnovakjr__> i put my file manager up on the market last weekend, putting an update on sunday
Nov 07 02:49:20 <zhobbs> that's cool
Nov 07 02:49:58 <romainguy> zhobbs: seems like it takes too long to inflate a menu from xml...I might go back to doing it in code << I inflate all of my menus from XML and I never noticed such an issue
Nov 07 02:51:46 <zhobbs> yeah, it's only 6 items, and the first time you press menu there is a small delay
Nov 07 02:52:27 <zhobbs> this is while playing video and possibly even parsing other xml in the background though...
Nov 07 02:53:11 <zhobbs> in my other activities I haven't noticed it, just on the video player
Nov 07 02:54:22 <zhobbs> I think I'm just being nit-picky...
**** ENDING LOGGING AT Fri Nov 07 02:59:57 2008