| 05:56.58 | *** join/#brlcad madant_ (n=d@117.196.139.52) |
| 07:05.59 | *** join/#brlcad elena (n=elena@92.86.0.28) |
| 07:07.55 | CIA-28 | BRL-CAD: 03d_rossberg * r34416 10/brlcad/trunk/src/libged/CMakeLists.txt: added scale_ell.c to stay in sync with Makefile.am |
| 07:18.44 | *** join/#brlcad _clock_ (n=_sushi_@77-58-147-167.dclient.hispeed.ch) |
| 08:08.54 | *** join/#brlcad Elrohir (n=kvirc@p5B14E442.dip.t-dialin.net) |
| 08:11.41 | *** join/#brlcad IriX64 (n=IriX64@bas2-sudbury98-1128565123.dsl.bell.ca) |
| 08:13.06 | *** join/#brlcad Elrohir (n=kvirc@p5B14E442.dip.t-dialin.net) |
| 08:50.42 | *** join/#brlcad _clock__ (n=_sushi_@zux221-122-143.adsl.green.ch) |
| 08:54.10 | *** join/#brlcad mafm (n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 08:55.30 | mafm | hi |
| 08:56.11 | brlcad | hi! |
| 09:23.30 | mafm | brlcad: I was talking with a friend yesterday and reminded me of our discussions |
| 09:23.36 | mafm | he hates Ogre with passion |
| 09:24.27 | mafm | it seems that the holy wars about 3d engines are the new rage, after sysv vs bsd, vi vs emacs and kde vs gnome :D |
| 09:32.52 | ``Erik | hrm, yet a new convert O.o I'm pimping BRL-CAD on WoW :( |
| 09:33.03 | ``Erik | lemme guess, crystal space? :D |
| 09:33.19 | ``Erik | has yet to find a 3d engine that doesn't suck |
| 09:33.54 | mafm | yep, he's a crystal space partisan :D |
| 09:33.56 | ``Erik | of course, vim and emacs each suck in their own way... bsd and sysv each have their issues... linux just sucks, plain and simple |
| 09:34.05 | mafm | and yes, I don't like much any of them |
| 09:34.45 | ``Erik | (and windows makes black holes look like minor deflective entities) |
| 09:36.30 | mafm | lol |
| 09:43.58 | *** join/#brlcad mafm_ (n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 10:21.41 | d-lo | Mernin all! ``Erik, you're up early! |
| 10:25.01 | archivist | sleep seg faulted |
| 10:37.48 | *** join/#brlcad Mouette (n=chatzill@122-116-39-75.HINET-IP.hinet.net) |
| 10:44.48 | *** join/#brlcad elite01 (n=omg@unaffiliated/elite01) |
| 11:26.58 | *** join/#brlcad _clock_ (n=_sushi_@zux221-122-143.adsl.green.ch) |
| 11:49.09 | *** join/#brlcad elite01 (n=omg@unaffiliated/elite01) |
| 12:43.49 | archivist | brlcad, been seeing that type of spam on other lists |
| 13:01.22 | brlcad | archivist: I know, I've read that it looks like viral social networking |
| 13:01.52 | brlcad | that if you sign up on yaari, it spams everyone in your contact list after you import them (automatically and unknown to the user) |
| 13:02.24 | archivist | heh...not the sort of thing I visit or sign up for :) |
| 13:04.24 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-61.sbndin.btas.verizon.net) |
| 13:08.16 | *** join/#brlcad _clock_ (n=_sushi_@zux221-122-143.adsl.green.ch) |
| 13:33.25 | starseeker | ``Erik: Linux may suck, but we have drivers :-P |
| 13:34.03 | starseeker | looks forward to Haiku becoming usable so he can again adopt a niche OS |
| 13:46.48 | *** join/#brlcad _clock_ (n=_sushi_@zux221-122-143.adsl.green.ch) |
| 13:49.16 | ``Erik | hm, I have no gear that doesn't have bsd drivers, and scars from when linux did lack drivers for common equipment |
| 13:49.32 | starseeker | raises eyebrows. |
| 13:49.39 | starseeker | do the nvidia drivers work well now? |
| 13:49.40 | ``Erik | d-lo: late |
| 13:49.43 | ``Erik | yes |
| 13:49.53 | ``Erik | for the last 5 or so years |
| 13:50.23 | starseeker | ``Erik: wow. Guess it has been a while since I did comparative operating system testing |
| 13:51.00 | ``Erik | I think I did manage to force a release a few years back to support a chipset... the code was all their but the driver lagged with its listing, so it refused to try to use an 'known' pci id |
| 13:51.23 | archivist | nvidia dont work well with a realtime kernel though |
| 13:51.28 | ``Erik | so I sent a message that, uh, kinda insinuated need from my work address (at the time, I was developing ogl code) |
| 13:51.55 | ``Erik | careful, archivist, someone will state that the NT series is a realtime kernel :D |
| 13:52.10 | starseeker | heh :-) |
| 13:53.29 | ``Erik | starseeker: I was happily running linux games (rtcw, ut) on my fbsd box with an nvidia card before I moved to md in '03 |
| 13:54.37 | ``Erik | I think the drivers came out in '01 |
| 13:55.26 | starseeker | remembers the original fuss about subpar support on *BSD - guess by the time things settled down I had stopped operating system hopping |
| 13:55.39 | ``Erik | it lags, but it's there, kinda |
| 13:57.19 | ``Erik | https://sourceforge.net/projects/fbsd-nvdriver/ <-- shortly after that, they had a driver for fbsd |
| 13:58.22 | ``Erik | stupid effin' linux |
| 13:59.44 | ``Erik | ioctl(fd,code,...) hm, ioctl(fd,in,out,len) geeeee, { out = in; } /* DONE! */ |
| 13:59.48 | ``Erik | shakes fist |
| 14:05.52 | *** join/#brlcad mafm (n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 14:21.19 | *** join/#brlcad d_rossberg (n=rossberg@bz.bzflag.bz) |
| 14:44.16 | *** join/#brlcad _clock_ (n=_sushi_@zux221-122-143.adsl.green.ch) |
| 15:44.30 | *** join/#brlcad d-lo_ (n=claymore@bz.bzflag.bz) |
| 15:49.56 | ``Erik | y'know, I need to make smaller portions when I stir-fry... about half of what I do (or invite a fool over) |
| 15:57.20 | *** join/#brlcad Elrohir (n=kvirc@p5B14E442.dip.t-dialin.net) [NETSPLIT VICTIM] |
| 16:02.44 | d-lo | so ``Erik , taking today off? |
| 16:03.27 | ``Erik | yesterday was al expecting dude to show up... today, dude called off again but I felt like poop, so SL, hopefully tomorrow will be AL for house repair |
| 16:03.49 | ``Erik | check out "polly scattergood" |
| 16:04.02 | d-lo | dude as in Cable repair dude? |
| 16:04.04 | ``Erik | I think she's gonna make waves in the next year |
| 16:04.13 | ``Erik | no, house repair, the rotted out wood |
| 16:04.29 | d-lo | ah, the door frame? |
| 16:04.36 | ``Erik | he's gonna disassemble my houses face to get all the rotten wood out |
| 16:04.42 | d-lo | wow. |
| 16:04.51 | d-lo | good to do. Not cheap? |
| 16:05.09 | ``Erik | his initial estimate is 375, he's retired and does this for fun |
| 16:05.18 | ``Erik | eric edwards hooked us up |
| 16:05.24 | d-lo | nice :) |
| 16:05.26 | ``Erik | eric knows RRRVRONE |
| 16:05.37 | d-lo | que? |
| 16:05.51 | ``Erik | for? |
| 16:06.27 | d-lo | RRRVRONE = ? |
| 16:06.30 | ``Erik | the 'rrrvrone' is a family guy joke, 'cleaveland' style |
| 16:08.01 | ``Erik | aaanyways, I was talkin' about goldfrapp a couple years ago, they just recently were spotting in commercials and stuff... good stuff... I think this polly girl is the next one |
| 16:08.09 | ``Erik | in spite of her essex accent |
| 16:08.37 | ``Erik | should so be a label recruiter : |
| 16:08.39 | ``Erik | :) |
| 16:08.44 | d-lo | lol |
| 16:08.54 | d-lo | its your calling. Goferit. |
| 16:09.24 | ``Erik | well, check out her youtubes |
| 16:10.04 | d-lo | Prolly when I get home. Kinda involved in werk right now :/ |
| 16:10.13 | ``Erik | a very british face, but she does good tunes |
| 16:11.28 | d-lo | Ah, so she's the kind of female vocalist where you look at her face and not elsewhere? |
| 16:11.39 | ``Erik | no, ... other way 'round |
| 16:13.52 | ``Erik | not uh, susan boyle, but ... up that alley |
| 16:13.59 | d-lo | heh, you weren't kidding about the british face. |
| 16:14.44 | ``Erik | at least the girl from goldfrapp was adolescent jack material |
| 16:15.05 | ``Erik | I think this polly girl will make a mark, *shrug* |
| 16:19.48 | d-lo | Well I will check out her vids at home. Just hope she isn't a nother mute-and-watch chickie. |
| 16:20.20 | ``Erik | heh, if you mute, just close the window |
| 16:20.30 | ``Erik | honest, she ain't pretty |
| 16:21.10 | starseeker | hmm, this sounds like it might be interesting: http://www-hagen.informatik.uni-kl.de/~hijazi/Publications/gpuimpcsg-tr.pdf |
| 16:21.20 | CIA-28 | BRL-CAD: 03bob1961 * r34417 10/brlcad/trunk/src/libged/concat.c: Modified ged_concat to not require a suffix/prefix. If one is not provided, it behaves as if / was specified. |
| 16:49.06 | *** join/#brlcad jdoliner (n=jdoliner@98.227.157.38) |
| 17:02.58 | brlcad | wow, kudos to NX5 .. nice interface revamping |
| 17:04.18 | starseeker | googles NX5 |
| 17:04.47 | starseeker | ah |
| 17:04.52 | brlcad | unigraphics |
| 17:05.08 | starseeker | wow |
| 17:05.09 | brlcad | they (stupidly) renamed to 'NX' a while back |
| 17:05.46 | starseeker | erm. Throwing away a widely recognized brand name for "NX"?? that IS stupid |
| 17:06.05 | brlcad | one that is barely even searchable by itself |
| 17:06.36 | starseeker | agreed though - nice UI |
| 17:06.44 | ``Erik | thowing away a widley recognized brand name for "AMCAC"??? that IS stupid |
| 17:06.50 | ``Erik | thowing away a widley recognized brand name for "ARL"??? that IS stupid |
| 17:07.06 | starseeker | ``Erik: ARL is the brand |
| 17:07.22 | brlcad | that's actually not far from the look of the icons I had in mind |
| 17:07.23 | starseeker | what do you mean? |
| 17:07.28 | brlcad | he meant BRL |
| 17:07.31 | ``Erik | ok, you can believe hat. I'll keep working on BRL |
| 17:07.32 | brlcad | was renamed to ARL |
| 17:07.35 | ``Erik | no, I meant ARL |
| 17:07.45 | starseeker | Oh, gotcha |
| 17:07.49 | ``Erik | BRL was a widely recognized name, we changed to ARL |
| 17:07.55 | brlcad | that's what I meant |
| 17:08.03 | brlcad | go back to your embibbing |
| 17:08.13 | ``Erik | returns to lisp development |
| 17:08.59 | starseeker | those icons look like they could be vector |
| 17:09.09 | brlcad | nice bright high-resolution icons, clean theme, crisp tabbing |
| 17:09.40 | brlcad | still a little dead space but some basic concepts to be noted |
| 17:10.12 | starseeker | is puzzled by the virtually empty bar below the two rows of icons |
| 17:10.18 | *** join/#brlcad Ralith (n=ralith@216.162.199.202) |
| 17:10.34 | brlcad | yeah, selection-sensitive options |
| 17:10.41 | starseeker | ah |
| 17:10.48 | brlcad | not the best organization for those |
| 17:11.11 | brlcad | photoshop does the same thing but better because there aren't icons above, but similar concept |
| 17:11.22 | starseeker | perhaps appearing/disappearing transparent toolbars for selection sensitive would be an option? |
| 17:11.32 | starseeker | s/toolbars/whatever |
| 17:13.14 | brlcad | who is to say that theirs doesn't appear/disappear ;) |
| 17:13.22 | brlcad | still clunky by the placement alone |
| 17:14.02 | brlcad | bigger issue is the buffet of probably somewhat randomly used buttons above it |
| 17:14.19 | starseeker | heh, true. I was thinking along the lines of the toolbars on the edge in stellarium |
| 17:14.26 | brlcad | the lesson to take from it, though, is nice vibrant icons ;) |
| 17:14.42 | Ralith | takes notes |
| 17:14.43 | starseeker | nods - yes, those are striking and easily viewed |
| 17:14.59 | brlcad | and fairly unambiguous |
| 17:15.07 | starseeker | if I'm not mistaken, those are all expressible as vector icons - great for resolution independence :-) |
| 17:15.32 | brlcad | i highly doubt they are vectors, but sure :) |
| 17:15.37 | starseeker | THINKS QT supports that, but isn't sure... |
| 17:16.01 | ``Erik | dislikes qt |
| 17:16.03 | starseeker | I know KDE was working towards it for their desktop icons at the very least, and I think it was across the board |
| 17:16.04 | Ralith | I would be surprised if it didn't |
| 17:19.25 | starseeker | ah, yeah - as of QT 4.2 they support svg icons |
| 17:21.23 | starseeker | likes the idea of not having to shove lots of different resolution .png files into the repository :-) |
| 17:29.29 | *** join/#brlcad Ralith (n=ralith@216.162.199.202) |
| 17:59.03 | *** join/#brlcad samrose (n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) |
| 18:27.42 | *** join/#brlcad BigAToo (n=BigAToo@64.74.225.82) |
| 19:31.21 | brlcad | aaalmost gets the new mirroring equations to work |
| 19:32.44 | brlcad | starseeker: true |
| 19:33.16 | starseeker | winces in sympath with brlcad - nothing as frustrating as "almost" working |
| 19:33.18 | brlcad | though while unclean, it's *very* trivial to maintain image resource files |
| 19:33.29 | *** join/#brlcad samrose (n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) |
| 19:33.37 | starseeker | true. We will be doing it with Archer anyway, I guess |
| 19:33.49 | starseeker | or rather, are doing |
| 19:33.52 | brlcad | vector is of course better, but it 'can' be considerably more complicated |
| 19:34.20 | starseeker | to store, or to use? |
| 19:34.25 | brlcad | not that you need to store multiple image files either, can always store just one and downsample as needed |
| 19:34.28 | brlcad | yes |
| 19:34.33 | starseeker | heh |
| 19:34.40 | starseeker | was thinking they're harder to design... |
| 19:34.58 | brlcad | actually more on use, storing it is just a matter of yet another resource file |
| 19:35.18 | brlcad | storing in memory can be more tricky, but that's akin to use |
| 19:35.25 | starseeker | ah. |
| 19:35.33 | starseeker | was hoping QT could take care of that... |
| 19:36.03 | brlcad | hopefully |
| 19:36.06 | brlcad | but if not, meh |
| 19:36.11 | starseeker | nods |
| 19:36.20 | starseeker | if not, simpler to go with images |
| 19:36.22 | brlcad | that's not really a technical problem |
| 19:36.26 | brlcad | yeah |
| 19:37.01 | starseeker | can even create them as svg, generate images if needed, then "someday" convert to straight svg |
| 19:37.14 | starseeker | after all our other problems go away |
| 19:37.40 | brlcad | another potentially 'neat' idea would be for each 'icon' to be a tiny little .g scene :) |
| 19:38.29 | brlcad | even better over svg since most of what we need to display isn't vector 2d, it's actually 3d.. so we could just make a 3d resource and display that instead |
| 19:38.44 | brlcad | would need a little backend work to make it flexible though |
| 19:38.53 | starseeker | that is an interesting idea |
| 19:39.22 | starseeker | you're thinking to raytrace the .g scenes to generate the icons? |
| 19:39.27 | brlcad | no no |
| 19:39.59 | brlcad | shaded display geometry, just tiny to whatever size the icons are |
| 19:40.03 | starseeker | ah |
| 19:40.11 | brlcad | i mean you could render them, but no need really |
| 19:40.24 | starseeker | once we can do shaded displays :-) |
| 19:40.27 | brlcad | what it would require, though, is some good display support |
| 19:40.33 | starseeker | no kidding |
| 19:40.40 | brlcad | and probably annotations |
| 19:40.44 | starseeker | isn't sure if he has ever heard of such an approach to icons |
| 19:40.49 | brlcad | since most of the icons require some form of annotative overlay |
| 19:41.13 | starseeker | blender did their whole interface on opengl IIRC, but I don't think their icons are mini blender scenes.. |
| 19:41.32 | starseeker | probably made in blender though, come to think of it... |
| 19:41.44 | starseeker | that is a nifty idea |
| 19:43.00 | starseeker | probably would be for "new interface mark 2" though - lot of things need to be working really well to pull that off |
| 19:44.43 | brlcad | I wouldn't put it in archer, but it's not that complicated at all really |
| 19:45.19 | starseeker | is wondering about the performance implications of so many tiny shaded scenes |
| 19:45.45 | brlcad | you're making the scene, so it really can be just about anything -- e.g. bots so shaded display works, geometry for whatever annotations you want to display, etc .. text is the main stickler and something like ftgl solves that |
| 19:46.42 | starseeker | true - I was thinking more along the lines of how the display management would cope with it |
| 19:46.47 | brlcad | they're static scenes and don't even need to update each frame unless there are antialiased/transparent items in the icon |
| 19:47.50 | brlcad | it wouldn't be more than a few hundred polys per icon, likely less than 100 displayed at a time -- insignificant |
| 19:48.11 | starseeker | right, but wouldn't each icon be its own opengl context? |
| 19:48.23 | brlcad | and even if it were a problem, you grab it from the framebuffer and display static image until resizes |
| 19:48.28 | starseeker | maybe that isn't a problem... |
| 19:48.31 | starseeker | ah |
| 19:48.41 | brlcad | no, just the one context |
| 19:49.00 | starseeker | oh, right - full screen context with elements within it |
| 19:49.09 | starseeker | duh |
| 20:04.37 | brlcad | heh, cool |
| 20:06.17 | brlcad | it's now actually more efficient (space-wise) to store a sphere as a pnt primitive |
| 20:06.31 | starseeker | heh :-) |
| 20:06.36 | starseeker | neat! |
| 20:07.08 | brlcad | when I put that optimization in for per-point radius values, that makes it actually only store series of 3+1 instead of sph's usual serialization which is same as tgc (12) |
| 20:07.39 | brlcad | even with the pnt overhead (2 values), it's still less for a single sphere (6 values) |
| 20:07.52 | starseeker | is it worth reworking sph? |
| 20:07.54 | brlcad | half the storage :) |
| 20:08.00 | starseeker | cool! |
| 20:08.03 | brlcad | no, just funny |
| 20:08.30 | brlcad | sph does it that way so it's compatible and interchangeable with an ell (said tgc earlier, meant ell) |
| 20:08.43 | starseeker | figured ;-) |
| 20:09.17 | brlcad | and changing it would break db compatibility, so not really worth it |
| 20:09.33 | starseeker | nods |
| 20:09.38 | brlcad | would only matter if you had a lot of spheres.. and if you do, then you probably should be using a pnt anyways |
| 20:09.51 | starseeker | point :-P |
| 20:10.27 | brlcad | shakes his fist at this dotproduct |
| 20:13.19 | brlcad | ahhh, it's bug in the *current* mirror command too |
| 20:28.38 | *** join/#brlcad Elrohir (n=kvirc@91.20.228.66) |
| 20:43.21 | CIA-28 | BRL-CAD: 03brlcad * r34418 10/brlcad/trunk/TODO: |
| 20:43.21 | CIA-28 | BRL-CAD: mged inconsistently ignores signals. initially allows it to be backgrounded, |
| 20:43.21 | CIA-28 | BRL-CAD: but then later will ignore them. may be related to some issue introduced with |
| 20:43.21 | CIA-28 | BRL-CAD: bu_suspend_interrupts() and libged, but either way it's really annoying and |
| 20:43.21 | CIA-28 | BRL-CAD: should be changed (ideally to allow them) |
| 21:06.39 | CIA-28 | BRL-CAD: 03bob1961 * r34419 10/brlcad/trunk/src/libtclcad/ged_obj.c: Need to convert/scale points to local units before calling routines that expect local units. |
| 21:07.58 | CIA-28 | BRL-CAD: 03bob1961 * r34420 10/brlcad/trunk/src/libged/ (move_arb_edge.c move_arb_face.c): Need to convert points from local to base units before using. |
| 21:14.26 | CIA-28 | BRL-CAD: 03bob1961 * r34421 10/brlcad/trunk/src/tclscripts/archer/ (Archer.tcl GeometryEditFrame.tcl): Provide better interaction when editing in Archer (i.e. update value panel and change the edit mode if the current edit class is not appropriate). |
| 21:50.46 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-61.sbndin.btas.verizon.net) |
| 22:09.03 | CIA-28 | BRL-CAD: 03brlcad * r34422 10/brlcad/trunk/include/vmath.h: |
| 22:09.03 | CIA-28 | BRL-CAD: instead of referring to the 4th component of a plane_t as [3], refer to it as |
| 22:09.03 | CIA-28 | BRL-CAD: [W] given it's effectively a homogeneous component for the normalized plane |
| 22:09.03 | CIA-28 | BRL-CAD: equation vector. aside from that, code shouldn't be accessing the element by a |
| 22:09.03 | CIA-28 | BRL-CAD: magic number regardless in case we want to change the implementation. |
| 22:19.49 | starseeker | will be wanting one of these if he has a yard someday: http://www.friendlyrobotics.com/ |
| 22:21.06 | starseeker | with that and roomba, life starts to get good :-) |
| 22:21.27 | starseeker | especially if you're a cat, apparently: http://www.youtube.com/watch?v=LQ-jv8g1YVI |
| 22:38.38 | brlcad | starseeker: back to our earlier work (which we should pick up again sometime soon) since I just ran across it again, check out src/libbn/plane.c |
| 22:38.51 | brlcad | should look pretty familiar |
| 22:39.26 | starseeker | ah yes |
| 22:39.35 | starseeker | excellent :-) |
| 22:41.22 | starseeker | how robust are those? |
| 22:42.00 | brlcad | most of them do exactly what we'd want, doing a given test and taking tolerance into account |
| 22:42.15 | brlcad | a lot of line/point/plane tests, no curves |
| 22:42.20 | starseeker | excellent. |
| 22:42.26 | starseeker | yeah, I was looking for curves ;-) |
| 22:42.58 | brlcad | so specialized, like finding the intersection of three unique planes |
| 22:43.01 | brlcad | s/so/some/ |
| 22:43.35 | brlcad | or given three points, make a plane |
| 22:43.41 | starseeker | nods |
| 22:44.18 | starseeker | I've been trying to figure out if there are any good reference books containing algorithms for curve/* intersections |
| 22:50.42 | starseeker | hmmm. http://www.siggraph.org/s2009/sessions/courses/details/?type=course&id=6 |
| 22:56.42 | brlcad | not exactly what we were referring to earlier |
| 22:56.51 | brlcad | fully 3D user interfaces are a different beast altogether |
| 22:57.13 | brlcad | where you have windows and palletes and widgets floating around in space potentially |
| 22:57.24 | starseeker | mmm |
| 22:57.33 | Ralith | that strikes me as confusing. |
| 22:57.41 | starseeker | I was hoping they might talk about interacting with 3D models |
| 22:58.13 | starseeker | nuts - yeah, I'm not a big fan of 3D interfaces in that sense |
| 23:00.04 | brlcad | it still applies -- just depends what we're talking about |
| 23:00.54 | brlcad | for example, I've had in mind to use something like radial menus around objects that are selected (or to at least have it as an option) .. that becomes rather effective only if set in the 3d scene with the object |
| 23:01.19 | Ralith | oo, that does sound neat |
| 23:01.36 | Ralith | visually anyway; dunno if it'd be more usable than standard radial menus around the pointer. |
| 23:03.14 | ``Erik | pie menus are a nifty idea, but I imagine most users wouldn't follow them well because they're so ingrained in the drop menu paradigm :( |
| 23:03.16 | brlcad | yeah, there's some work that has shown it 'can' be effective, but depends on a lot of things |
| 23:03.53 | Ralith | the work I saw depended on it being around the cursor, though |
| 23:04.31 | Ralith | 'cuz then you get the ability to select any item with a very small constant amount of imprecise movement |
| 23:04.49 | Ralith | if it's not centered on the pointer, then I think you lose most of that advantage. |
| 23:05.06 | ``Erik | you also need to be away from a screen edge, and to break the users mentality |
| 23:05.12 | ``Erik | but it is a really neat idea |
| 23:06.03 | brlcad | that's just a matter of view-dependent scaling of the menu in the scene (which you would have to have) |
| 23:06.10 | brlcad | so that you don't end up with precision issues |
| 23:06.25 | ``Erik | what, the screen edge aspect? |
| 23:06.43 | brlcad | ``Erik: fortunately, we don't give them any such option at the moment .. so no behavior that we're breaking on our part :) |
| 23:06.59 | Ralith | hehe |
| 23:07.10 | ``Erik | if your user invokes right at the edge of the screen, do you draw a hemisphere? in a corner, just a quadrant? |
| 23:07.30 | Ralith | I'd just have the thing appear a little bit offset. |
| 23:07.34 | Ralith | it's not got *that* large a radius. |
| 23:07.36 | ``Erik | well, effort to add a feature that "doesn't feel right" to 99% of users is probably ... wasted |
| 23:07.54 | ``Erik | and if your pie expansion is towards the corner? |
| 23:08.00 | brlcad | technically, displaying the vertices in the 3D scene when an object being edited is a form of a 3D gui, particularly when you then allow vertices/objects/points to be selected and edited in the scene directly |
| 23:08.09 | Ralith | then that's a problem, I guess. You'd have to move everything. |
| 23:08.12 | ``Erik | moving hte menu out from under the user seems... almost criminal to me |
| 23:08.23 | Ralith | indeed. |
| 23:08.41 | Ralith | although... |
| 23:08.58 | Ralith | it might not be completely unreasonable to just swap the new menu in place of the old one, in general |
| 23:09.10 | ``Erik | technically, we don't support 3d gui yet... every "3d" thing any of us deal with are compressed into 2d for display.. :) (unless you do stereoscopics or a cave or something) |
| 23:09.11 | Ralith | kind of like GUI file browsers moved from new windowing all the time to just changing dir in the current window |
| 23:09.48 | ``Erik | ralith: most make that selectable, some have a number of approaches |
| 23:09.55 | Ralith | I think the effort of learning a CAD tool of any kind is enough that we're justified in being creative with GUI work, and possibly doing uncommon things. |
| 23:10.10 | brlcad | if the gui is in the scene, it's in the scene and is a normal "out of view" problem if an object is near the edge |
| 23:10.23 | ``Erik | I think the default mac 'finder' settings are abysmal, but still better than the default winderz explorer |
| 23:10.24 | Ralith | since, ultimately, any unfamiliarity induced by such will be less than the challenge posed by learning the fundementals of the system. |
| 23:10.46 | brlcad | i.e. the menu is displayed and they can't see it all because of where the object is, just like that control point they can't click because it's too close to a menu or the edge of a context or whatever |
| 23:10.57 | ``Erik | aint' sayin' it ain't a good idea, just playing devils advocate and looking for corner cases |
| 23:11.04 | brlcad | it's also not to say that it'd be the *only* method available |
| 23:11.28 | brlcad | there are a couple really good 'proof of concepts' out there that are remarkable |
| 23:11.45 | ``Erik | yeah, but they tend to be cotton candy examples, y'know? |
| 23:11.59 | ``Erik | if they're the couple that I was looking at around '00 or '01 |
| 23:12.05 | ``Erik | when the papers came out |
| 23:13.39 | ``Erik | I was looking at coding video game stuff at the time (so there's a lot of leeway in breaking user convention), I d'no, it seemed like a paper idea to me when talking serious production *shrug* |
| 23:13.52 | brlcad | these were working prototypes, don't have the link atm though |
| 23:14.17 | brlcad | here's an example that's not as impressive, but at least related and functional: http://image.com.com/gamespot/images/2007/225/942784_20070814_screen004.jpg |
| 23:14.28 | ``Erik | but I'm old, bitter and cynical... I like zui as a notion, but it'd take a ground shaking 'killer app' to move it from a geek curiousity to a real thing |
| 23:14.51 | ``Erik | ah, I hadn't seen that image before |
| 23:15.12 | ``Erik | the examples I saw made a bit point of concentric rings |
| 23:15.36 | brlcad | yeah, something like http://stevejbayer.com/files/images/2%20level%20Radial%20Menu.jpg |
| 23:16.05 | ``Erik | yes |
| 23:16.23 | ``Erik | the downside is what does that picture MEAN? to a cold user, wtf? |
| 23:16.42 | ``Erik | the video game picture, I think I understand... two of those images |
| 23:16.55 | brlcad | a variant of the radial is simply two horizontal menus and two vertical menus |
| 23:17.10 | ``Erik | I assume the wrench means "repair this unit" and the dollar sign means something about expenses... the rest... I d'no |
| 23:17.25 | brlcad | like I said, not as impressive -- the icons are not exactly intuitive outside the domain |
| 23:17.36 | brlcad | but then so are most of the icons in a CAD app to an outsider |
| 23:17.37 | ``Erik | but video games are lenient :) |
| 23:17.45 | ``Erik | *ponder* |
| 23:17.51 | ``Erik | brainfart time |
| 23:17.58 | ``Erik | imagine instead of a full circle of images |
| 23:17.58 | Ralith | tooltips come into their own here, too. |
| 23:18.08 | Ralith | or an equivalent. |
| 23:18.21 | ``Erik | ralith, if I have to mouseover something to understand what it is, the hci guys failed. |
| 23:18.33 | Ralith | you only have to mouseover it *once* though |
| 23:18.51 | ``Erik | ok, imagine two quarter-circles, centered on each side, with the functional text drifting off against it |
| 23:19.05 | ``Erik | uh, ralith, if I have to memorize from a mouseover, your hci has failed :D |
| 23:19.09 | Ralith | :[ |
| 23:19.28 | Ralith | large menu options w/ text instead of icons? |
| 23:19.32 | Ralith | which is what you seem to be suggesting. |
| 23:19.50 | Ralith | as brlcad says, I don't think you can do much about icons being unintuitive. |
| 23:20.16 | ``Erik | no, I suggest an amber screen with a cable bundle to a server :D |
| 23:20.51 | ``Erik | what's the infamous usenet quote? the only intuitive interface is the nipple? |
| 23:20.57 | brlcad | ideally, there's as little menu, buttons, and widgets as possible, the less the better is generally the case for usability (i.e., if it looks like something you should be able to do, then you should be able to do it.. lots of direct manipulation) |
| 23:21.31 | ``Erik | so when you design a gui, it's a balance between making things clean for a knowledgable superuser and accessable to a newbie |
| 23:21.43 | brlcad | it's more a matter of context management so that there's as little conflict of options as possible, without resorting to all-out modalities |
| 23:21.49 | ``Erik | I hate to say it, but the microsoft 'faded menu' approach appeals to the ugly truth fairly well |
| 23:22.08 | ``Erik | imho |
| 23:24.02 | brlcad | Ralith: that's why a lot of what you're doing is more leaning towards the work that's gone into IEO since that's a lot more about context management |
| 23:24.43 | ``Erik | aaaanyways, coders tend to look for glitzy 'neat' solutions that just make the mere mortal experience more difficult, I'm just trying to be 'that guy' to pull folk back to ground :) |
| 23:24.44 | brlcad | and not so much the 3D scene interaction |
| 23:26.00 | Ralith | but the glitzy neat solutions are glitzy and neat! |
| 23:26.22 | ``Erik | hehehehe precisely! I'm glad you understand! |
| 23:26.24 | ``Erik | :D |
| 23:28.00 | ``Erik | my mother works for a bank, she just recently got approval to work from home... before that, she sat in an aeron chair, running XP... filled her screen with putty and ran a curses(or equivelant) program on a dusty as/400 |
| 23:28.01 | brlcad | would rather focus on trying to figure out how to make things work or implementing prototypes rather than spending time trying to navel gaze on all the possible ways that something might go wrong or be implemented poorly :) |
| 23:28.22 | ``Erik | there's glitzy neat stuff, and then there's stuff people use to get the job done :) |
| 23:28.44 | ``Erik | *point* yes, no glitz, get something working : |
| 23:28.45 | ``Erik | :D |
| 23:29.09 | brlcad | "glitz" can often tie in almost directly to usability |
| 23:29.11 | ``Erik | wants the modelers to tell him what frustrates them the most :( |
| 23:29.20 | brlcad | depends entirely what you mean by glitz |
| 23:30.12 | brlcad | because very often, what many call glitz in some interfaces is actually HCI hinting, which can be very effective for shifting locus of attention |
| 23:30.19 | ``Erik | hm, yeah, I don't think there's a hard definition, I think I consider it to be eye candy that is not necessary to efficiently accomplish the task |
| 23:30.43 | ``Erik | when the gui inhibits the use, then it's just glitz |
| 23:30.46 | ``Erik | :) |
| 23:30.59 | brlcad | e.g., the "genie minimize" or "scale minimize" in mac os x .. on the surface is purely 'glitz', a shiny effect .. but it's not |
| 23:31.07 | brlcad | it actually shows you where the window went |
| 23:31.09 | brlcad | very effective |
| 23:31.12 | brlcad | and looks cool to boot |
| 23:31.53 | brlcad | if you need to restore that working context, you were told exactly where it went, or at least the direction it went |
| 23:31.58 | ``Erik | <-- uses genie |
| 23:32.51 | brlcad | is it "necessary", absolutely not -- is it useful, very much so in combination with many other usability hints that are going on simultaneously |
| 23:33.01 | ``Erik | I've seen a lot of instances where code was developed to look cool, but the users felt it made things more difficult to use.. THAT is what I want to cut off |
| 23:33.15 | brlcad | well complain about that when you see it :) |
| 23:33.32 | ``Erik | and it's the user that matters, not the chapter about hinting in the hci book :D |
| 23:33.48 | brlcad | otherwise, it's just contemplating all the possible horrible ways things could go fantastically wrong |
| 23:34.10 | brlcad | which isn't productive :P |
| 23:34.15 | ``Erik | I called in sick today, I'm allowed to be the peanut gallery, damnit |
| 23:34.17 | ``Erik | :D |
| 23:34.35 | Ralith | hehe |
| 23:34.38 | starseeker | not to mention I'll accidently stumble into at least 10 of the worst UI mistakes anyway, regardless |
| 23:34.48 | starseeker | so don't worry about it ;-) |
| 23:35.14 | starseeker | we'll just be ready to correct mistakes |
| 23:35.37 | ``Erik | pie menus are neat, I bet if you cut off the top and bottom quarters and put text next to the items (context based), it'd be more usable to a newbie |
| 23:36.29 | brlcad | that's the variant I mentioned that is basically two vertical and two horizontal menus |
| 23:36.32 | starseeker | remembers when he was learning Tribes, there were interactive tutorials that went through the uses and meanings of the various options |
| 23:36.50 | starseeker | was actually fairly effective |
| 23:37.12 | ``Erik | brlcad: ss? |
| 23:37.36 | brlcad | more radical hierarchical example: http://farm1.static.flickr.com/39/76817786_0cbe787afa_o_d.png (not a fan, but interesting nonetheless) |
| 23:37.47 | brlcad | ss? |
| 23:37.49 | starseeker | we could convert the cup tutorial steps into an in-gui step-by-step... |
| 23:37.57 | brlcad | the cup sucks |
| 23:37.58 | brlcad | it's boring |
| 23:37.59 | ``Erik | starseeker: yes, but video games are a special turf, like I mentioned earlier... that ti's challenging to operate is often considered a boon, unlike other apps |
| 23:38.05 | ``Erik | ss == screenshot |
| 23:38.10 | starseeker | well, something more interesting than the cup then |
| 23:38.11 | brlcad | ah, don't have one |
| 23:38.28 | brlcad | at least not on hand at the moment, there are some examples stashed away in my data archive |
| 23:38.38 | ``Erik | hm, that's an interesting image, but not what I mean |
| 23:38.50 | brlcad | I know, it was unrelated |
| 23:38.55 | brlcad | just another example |
| 23:39.02 | ``Erik | tell ya what, on thursday or friday, I can draw on my whiteboard, or gimp one up |
| 23:39.04 | archivist | that was fugly |
| 23:39.04 | starseeker | that is radical |
| 23:40.06 | starseeker | is a traditionalist in some ways - he likes what stellarium does with the toolbars hidden at the edges |
| 23:40.27 | ``Erik | tell ya what, man, amber crt, vt102, ... |
| 23:40.42 | starseeker | isn't THAT much of a traditionalist... |
| 23:40.58 | brlcad | that's what command-mode is for, part why it's first and fundamental ;) |
| 23:41.11 | brlcad | command mode is pervasively available |
| 23:41.13 | ``Erik | when the library bought wyse terminals to place next to the card catalog, that was hot shit |
| 23:41.38 | ``Erik | uhmmmmmmmm, lee had a question about the tcl command prompt in BRL-CAD on friday, did he get to you on that? |
| 23:41.44 | starseeker | well sure - if it's all you've got, vacuum tubes are the bomb |
| 23:42.00 | starseeker | to me? don't think so |
| 23:42.01 | starseeker | what was it? |
| 23:42.06 | ``Erik | to brlcad |
| 23:42.09 | starseeker | oh |
| 23:42.18 | ``Erik | s/^/brlcad: / |
| 23:42.19 | ``Erik | :) |
| 23:42.29 | brlcad | what's interesting about a (well-designed) radial menu is that they're measurably more efficient than a linear menu due to directionality, spatial memorization, and distance travelled (fitts) so long as the menu stays small (and isn't a decision tree) |
| 23:42.54 | brlcad | ``Erik: think he did .. at least I talked to him friday and solved some problem for him |
| 23:43.02 | brlcad | don't remember what it was atm though |
| 23:43.15 | ``Erik | 'k, he was looking for some command to find something in a .g file and I didn' have an answer for him |
| 23:43.16 | brlcad | ah, catching a db get |
| 23:43.25 | brlcad | yeah |
| 23:43.33 | ``Erik | <-- doesn't do the tcl side |
| 23:43.33 | brlcad | problem solved |
| 23:43.37 | ``Erik | aight, good |
| 23:44.14 | ``Erik | y'know, I'm struck by differences in utilization of "world of warcraft" between me and redvsblue |
| 23:45.12 | ``Erik | I use addons to place icons in the fitts positions and pack my keyboard full of immediate commands, she likes to use the mouse for everything and doesn't have any command object in any corner or edge |
| 23:45.47 | starseeker | ``Erik: spoken like a true vim user :-) |
| 23:45.47 | ``Erik | (doesn't even run the program full screen) |
| 23:46.02 | brlcad | it was pretty simple -- if you do a "db get_type foo" in a db, it'll either tell you "foo"'s type if it found that object or return an error |
| 23:46.20 | brlcad | he was making a new user command and wanted to supress that error |
| 23:46.30 | ``Erik | I use both vim and emacs these days... and netbeans on occasion :) I like to imagine that I strive to be task oriented instead of tool oriented |
| 23:46.33 | brlcad | which is done by simply wrapping the command in a catch statement |
| 23:46.43 | brlcad | catch {db get_type foo} |
| 23:46.53 | brlcad | will return 0 or 1 on success/failure |
| 23:46.57 | ``Erik | ok, lee asked me and I immediately threw my hands up and said "ain't my turf" |
| 23:47.07 | brlcad | well now ya know ;) |
| 23:47.11 | brlcad | can catch most commands |
| 23:47.16 | ``Erik | I've already forgotten :D |
| 23:47.38 | ``Erik | when we get python and lisp wired in right, mebbe I'll pay more attention O:-) |
| 23:48.06 | brlcad | has little to do with tcl |
| 23:48.24 | ``Erik | if I had to write a mod for one of my eggdrop bots, I'd probably rewrite the bot in C to avoid being in the neighborhood of tcl |
| 23:48.42 | brlcad | in any arg-style command language it'd be nearly the same |
| 23:48.57 | ``Erik | I assume the tcl 'catch' is modelled after the 'error/catch' facility found in, uhhhh, lisp, snobol, etc? |
| 23:49.09 | brlcad | pretty much |
| 23:49.10 | ``Erik | um, like an exception? |
| 23:49.15 | ``Erik | in c++/jabba? |
| 23:49.18 | brlcad | sorta |
| 23:49.23 | brlcad | little more basic than exceptions |
| 23:49.32 | brlcad | just captures the result in a variable |
| 23:49.34 | ``Erik | oh, so it doesn't grok heirarchy |
| 23:49.42 | ``Erik | just a push/jmp/pop |
| 23:50.08 | brlcad | akin to something like: foo="`cat asdf 2>&1`" ; echo $? |
| 23:50.17 | brlcad | if this were posix shell interp |
| 23:50.24 | ``Erik | *nod* push/jmp/pop :) |
| 23:50.28 | brlcad | catch {cat asdf} foo |
| 23:53.27 | ``Erik | ralith == ben? |
| 23:54.10 | ``Erik | is looking at gsoc crap |
| 23:54.20 | madant_ | :) |
| 23:55.02 | ``Erik | ya'll with your weirdassed handles |
| 23:55.18 | ``Erik | Hi, my name is Erik, my handle is Erik, if you want to connect the dots, it's Erik. |
| 23:55.21 | ``Erik | :D |
| 23:55.51 | CIA-28 | BRL-CAD: 03brlcad * r34423 10/brlcad/trunk/src/ (28 files in 17 dirs): universally use [W] instead of directly accessing plane_t's distance factor at index [3]. it's a homogeneous scaling factor. |
| 23:58.08 | ``Erik | w00t, :g/\[3\]/[W]/g ftw |
| 23:58.16 | brlcad | heh, not quite |
| 23:58.41 | ``Erik | is 'w' understandable in all those contexts, or commented if not? :D |
