| 00:04.50 | Ralith | pokes jonored |
| 00:05.46 | *** join/#brlcad schwinn434 (n=schwinn4@75.81.198.192) | |
| 00:20.45 | *** join/#brlcad Axman6 (n=Axman6@pdpc/supporter/student/Axman6) | |
| 00:43.16 | *** join/#brlcad Lez (n=lezardfl@189.58.212.25.dynamic.adsl.gvt.net.br) | |
| 00:51.40 | ``Erik | eeks, take that somewhere private, ralith O.O |
| 00:52.20 | Ralith | prude. |
| 01:09.55 | Ralith | discovers that all the pkgconfig files appear to be broken. |
| 01:09.59 | Ralith | does something about this. |
| 01:11.14 | CIA-40 | BRL-CAD: 03ralith * r34099 10/brlcad/trunk/misc/pkgconfig/ (13 files): Fixed fatal dependent variable mis-ordering |
| 01:29.35 | *** join/#brlcad Lezard (n=lezardfl@189.58.212.25.dynamic.adsl.gvt.net.br) | |
| 01:40.48 | kanzure | Hi all. Has anyone any experience with elmerfem? |
| 02:03.47 | Ralith | dear god it's hard to get RBGui to build |
| 02:34.53 | Ralith | rewrites most of g3d's build system |
| 02:41.02 | *** join/#brlcad schwinn434 (n=schwinn4@75.81.198.192) | |
| 02:43.35 | *** join/#brlcad schwinn434 (n=schwinn4@75.81.198.192) | |
| 02:46.20 | *** join/#brlcad schwinn434 (n=schwinn4@75.81.198.192) | |
| 02:51.53 | *** part/#brlcad jdoliner (n=jdoliner@c-68-51-76-57.hsd1.il.comcast.net) | |
| 03:20.39 | CIA-40 | BRL-CAD: 03ralith * r34100 10/rt^3/trunk/src/g3d/ (10 files in 2 dirs): Extensive build system cleanup/reliability fixes: BRL-CAD is now correctly autodetected, reliability of all other dependency detection has vastly improved. |
| 03:21.37 | *** join/#brlcad Ralith (n=ralith@216.162.199.202) | |
| 03:24.30 | Ralith | brlcad: do you know if mafm's returning this year to GSoC on the GUI? |
| 03:27.50 | Ralith | also, seems to work fine(ish) on OGRE 1.6.1 |
| 03:28.06 | Ralith | the build system's largely Done Right now :] |
| 03:47.44 | *** join/#brlcad ashishrai (i=d2d43dfb@gateway/web/ajax/mibbit.com/x-199c8c222cf2d764) | |
| 03:50.21 | *** join/#brlcad dreeves (n=IceChat7@67.130.253.14) | |
| 04:27.32 | brlcad | Ralith: actually I don't know -- he's had personal matters to take care of, he may not |
| 04:27.55 | brlcad | glad to hear it worked ;) |
| 04:29.41 | Ralith | I think I'll apply for that, then |
| 04:29.50 | Ralith | seeing as I've some degree of familiarity with it |
| 04:33.48 | brlcad | feel free to mail him or the mailing list to check up with him |
| 04:34.25 | brlcad | it would be nice to see someone continue making progress |
| 04:57.55 | Ralith | yeah, I'm looking forward to having it hooked up and doing things |
| 04:58.30 | Ralith | I'll see if I can get in touch with him, and get my app started in the meantime |
| 05:37.16 | *** join/#brlcad jdoliner (n=jdoliner@c-68-51-76-57.hsd1.il.comcast.net) | |
| 06:01.42 | brlcad | Ralith: if you do apply for a previous gsoc project, please try to also put forward another application for one of the other ideas as well |
| 06:01.57 | brlcad | that goes for anyone and any previous gsoc project |
| 06:03.55 | brlcad | it often happens that some of the most desirable students all put in for the same project, rejecting several desirable students that would have otherwise been selected for a different project |
| 06:04.40 | brlcad | course that's only if someone can put together two *good* applications, and the second one doesn't decrease the quality of the first one! if you just have time for one, then so be it |
| 06:05.18 | brlcad | also an even better reason to submit it earlier rather than later so we can give feedback and gauge whether there are conflicts |
| 06:06.32 | Ralith | there're multiple people going for that one? |
| 06:07.30 | Ralith | I'm certainly happy to apply to another, though; I'm quite interested in getting in on GSoC, so anything that increases my chances... |
| 06:07.48 | Ralith | not to mention this is a fun project. |
| 06:08.06 | brlcad | there usually are three or four projects that get several submissions each by the deadline |
| 06:08.45 | brlcad | last year, there were about 20 valid interesting applications, about 10 of those were very good, from there we narrowed down on 4 |
| 06:08.57 | Ralith | while you're around; do you remember if there was any reason g3d is using RBGui rather than something more active? |
| 06:09.02 | Ralith | the project's outright abandoned these days. |
| 06:09.29 | Ralith | says as much on the site, and it took me half an hour of hacking to make it and its dependent lib build, including writing a build system for it. |
| 06:09.45 | brlcad | yeah, there was a long long series of discussions about a gui framework |
| 06:10.46 | Ralith | so, preferable to adopt RBGui over switching it out? |
| 06:10.59 | brlcad | rbgui being dead was one of its downsides, but wasn't seen as a huge one iff it did everything that was needed (and it had several very interesting extension aspects) -- it was on par with two or so others iirc, and it came down to just running with any one of them |
| 06:11.12 | brlcad | no, not tied to rbgui |
| 06:11.51 | brlcad | it was just to move past dwelling on it since there were so many questions about it vs others that really couldn't be answered without just trying it out |
| 06:12.33 | Ralith | hm. I'd imagined there must have been some compelling reason to work off of a dead project. |
| 06:12.52 | brlcad | if it can be made to work, great -- I highly suspect we will end up with a lot of customized widgets and interactions as it starts coming to demo-state |
| 06:13.31 | brlcad | Ralith: have you seen their demo? |
| 06:13.36 | Ralith | I don't think so |
| 06:14.08 | brlcad | some of the previous discussion, fwiw -- http://brlcad.org/wiki/Talk:OpenGL_GUI_Framework |
| 06:14.10 | Ralith | I'll admit that when brought to a working state it doesn't look half bad in g3d |
| 06:14.36 | Ralith | quite modern. |
| 06:14.50 | brlcad | http://rightbraingames.com/Gui.wmv |
| 06:15.16 | Ralith | pulls it down |
| 06:16.23 | *** part/#brlcad jdoliner (n=jdoliner@c-68-51-76-57.hsd1.il.comcast.net) | |
| 06:19.00 | Ralith | ...that is *very* aesthetically appealing |
| 06:19.43 | Ralith | put even a reasonably usable editor behind that and we'd probably get quite the spike in users out of ooh-shiny factor alone. |
| 06:19.57 | brlcad | nods |
| 06:20.20 | brlcad | the basic skinny about cegui (which I love in concept, btw), is that it doesn't/didn't yet have vector gui elements, and some widgets are missing |
| 06:21.06 | Ralith | anything really that hard to add? |
| 06:21.09 | Ralith | oo, those spline widgets are neat |
| 06:21.39 | brlcad | yeah, it would be -- cegui is based around a markup description layer similar to html |
| 06:21.53 | Ralith | that extensively? I thought that was just for layout. |
| 06:21.55 | brlcad | so window decorations and borders are all themed using images |
| 06:22.22 | Ralith | do you know how extensive RBGui's vector support is? |
| 06:22.41 | brlcad | have talked to a couple of the devs that work on it before -- they plan to add it at some point, just will take a lot of api changes |
| 06:22.49 | brlcad | nope |
| 06:22.54 | Ralith | kk |
| 06:23.09 | brlcad | yeah, isn't to say that rbgui solves that problem |
| 06:23.11 | Ralith | first glance suggests just fills and gradients, but I haven't looked at the code yet, and those cover most practical use cases anyway I guess |
| 06:23.11 | brlcad | either |
| 06:23.21 | brlcad | more just what came up about cegui |
| 06:24.01 | brlcad | yeah, it's a simple enough library that the assertion was it can probably do just about everything we need it for in the immediate future regardless |
| 06:24.26 | brlcad | as could a couple others, and if we had to live with maintaining rbgui or one of the others, so be it |
| 06:24.26 | Ralith | well, you've talked me into agreement with the decision. |
| 06:24.45 | Ralith | as you say, considering the amount of customization we're ultimately likely to apply to anything, that's not unreasonable. |
| 06:25.05 | brlcad | still better than rolling our own :0 |
| 06:25.18 | Ralith | indeed. |
| 06:25.30 | brlcad | now another option that came up just in the last year |
| 06:25.46 | brlcad | that was previously a non-starter due to licensing.. qt |
| 06:26.05 | brlcad | could see someone trying out a qt+ogre swap out |
| 06:26.12 | Ralith | qt has bad licensing? |
| 06:26.19 | Ralith | I thought it was LGPL |
| 06:26.28 | brlcad | that just happened this year |
| 06:26.31 | Ralith | ah, right |
| 06:26.58 | Ralith | well, I dunno. Qt can't render inside an OpenGL context, can it? |
| 06:27.29 | brlcad | hm, I don't know -- would be a little surprised if it couldn't |
| 06:27.32 | Ralith | if that's correct, that limits our freedom in design significantly. |
| 06:27.33 | Ralith | really? |
| 06:28.02 | Ralith | I'd be surprised if it did; maybe I have a misconception of it, but it seems wholly targeted at, uh |
| 06:28.05 | Ralith | not sure what the term is |
| 06:28.06 | Ralith | normal apps? |
| 06:29.25 | Ralith | I wouldn't expect gtk to render within a OpenGL context, either. |
| 06:29.29 | Ralith | never seen them used that way, certainly |
| 06:29.54 | Ralith | every Qt/gtk opengl app I've seen always just had an embedded context, with the GUI surrounding it. |
| 06:30.17 | Ralith | not that that doesn't have a history of working perfectly well, but I like the possibilities offered by having them render to the same place. |
| 06:30.26 | brlcad | nods |
| 06:30.36 | Ralith | not to mention the plain visual appeal of all the neat fading, smooth movement, etc. that RBGui implements and that can't be reliably done otherwise. |
| 06:30.41 | brlcad | certainly can say definitely without some research/testing |
| 06:30.47 | Ralith | yeah |
| 06:31.35 | brlcad | rbgui gets away with it simply by rendering everything itself, which has the cost of lost native look and feel (which is a good and bad thing!) |
| 06:31.57 | brlcad | i don't mind not looking native if it looks really good, and it should |
| 06:32.01 | Ralith | I'm not sure anyone expects a modeling app to have native look and feel thesedays. |
| 06:32.10 | Ralith | or maybe that's just graphics apps. |
| 06:32.42 | brlcad | yeah, modeling is a lot like the gaming industry in that regard where custom guis are more the norm than the exception |
| 06:33.00 | Ralith | and beyond that, native look and feel is only an element on OSX/Windows |
| 06:33.07 | brlcad | http://doc.trolltech.com/3.3/opengl.html seems to indicate it's like any other widget |
| 06:33.17 | brlcad | implying it could be layered as needed |
| 06:33.26 | Ralith | it's nigh-impossible to guarantee an app fits in well on a *nix environment. |
| 06:33.37 | Ralith | oh, I didn't know Qt had capacity for that kind of layering. |
| 06:33.41 | Ralith | I guess it would make sense. |
| 06:34.09 | Ralith | would be an odd omission for something so large and widely used |
| 06:35.04 | brlcad | Ralith: you've seen the IOE video, yes? |
| 06:35.08 | Ralith | yup |
| 06:35.13 | brlcad | okay, great |
| 06:35.14 | Ralith | it was quite a while back though |
| 06:35.42 | Ralith | it struck me as very unique |
| 06:35.50 | brlcad | that pretty much surveys the basic look, feel, and interaction direction I'd like to start with |
| 06:35.54 | Ralith | have a link for it? I should probably review it. |
| 06:36.04 | brlcad | brlcad.org/design/gui |
| 06:36.10 | Ralith | hehe |
| 06:36.28 | Ralith | _final or _full? |
| 06:38.30 | brlcad | final I believe |
| 06:39.05 | brlcad | interesting qt interface with opengl contexts, http://www.qtsoftware.com/images/customers/coolapps/realflow4.jpg |
| 06:39.33 | Ralith | that looks about like what I'd expect |
| 06:39.45 | Ralith | blender-style UIs have always felt a lot more integrated to me, tbh |
| 06:39.48 | brlcad | yeah |
| 06:42.01 | brlcad | a little better, http://chaos.troll.no/%7Egunnar/jambi_image_viewer.jpg |
| 06:42.40 | brlcad | it's faked, though ;) |
| 06:42.47 | brlcad | rather, it's just an image |
| 06:42.54 | Ralith | yeah, looked that way |
| 06:43.01 | Ralith | (I can tell because of the pixels and etc) |
| 06:43.25 | Ralith | that and the inconsistent widgets. |
| 06:43.51 | Ralith | ...and the "Image Viewer" in the title. |
| 06:44.25 | Ralith | I suppose I like the idea of sticking with RBGui, then, and extending it to fit our needs; might well even be easier than adapting a more fully-realized lib. |
| 06:44.32 | brlcad | here's what I was looking for |
| 06:44.52 | brlcad | more in line, http://stellarium.org/img/screenshots/0.10-stel_gui.jpg |
| 06:45.06 | Ralith | ...that's Qt?> |
| 06:45.09 | brlcad | yep |
| 06:45.12 | Ralith | wow. |
| 06:45.17 | Ralith | because that doesn't look like Qt at all. |
| 06:45.20 | Ralith | that looks fully integrated. |
| 06:45.26 | Ralith | I wonder how hard it was for them to do that. |
| 06:45.56 | brlcad | yeah, qt's various classes (QtButton, etc) can have their display method overridden in various ways |
| 06:45.59 | Ralith | still probably can't offer the more 'fun' visual effects, but that's pretty impressive. |
| 06:46.16 | brlcad | basically allowing custom widget look and feel |
| 06:46.40 | brlcad | while still providing all the same "basic widgets" that you want like tabs, sliders, scrollers, textareas, etc |
| 06:47.24 | brlcad | yeah, don't know how hard in practice that is, just have seem several projects customize their qt gui that way |
| 06:47.38 | brlcad | if we ended up with something like that, I'd be content to live with qt ;) |
| 06:47.40 | Ralith | example code in abundance, then. |
| 06:47.56 | brlcad | or rbgui, or whatever, means to an end |
| 06:48.33 | Ralith | is inclined to favor the status quo for now, in the absence of any compelling reason to switch. |
| 06:49.15 | Ralith | reminds me, I recall reading on the Ogre forums a while back of someone working on a GPU backend for Cairo |
| 06:56.42 | Ralith | http://github.com/akyrtzi/cairo-gral/tree/master |
| 06:56.45 | Ralith | may be of interest. |
| 06:57.45 | brlcad | wow, stellarium gui is really impressive |
| 06:58.42 | Ralith | installs |
| 06:58.48 | Ralith | what's caught your eye with it? |
| 06:59.17 | brlcad | it's very neatly integrated |
| 07:00.32 | brlcad | translucent overlay windows, persistent menus, an info bar, a persistent info overlay, drawer menus, clean window/full-screen support |
| 07:03.01 | Ralith | hm. I wonder what license they use, and how easily torn out their GUI code is. |
| 07:03.41 | brlcad | gpl |
| 07:03.49 | Ralith | ah. |
| 07:03.56 | Ralith | that would be a problem, then, right? |
| 07:04.00 | Ralith | as far as taking directly. |
| 07:04.08 | brlcad | to use their code direclty, yes |
| 07:04.20 | Ralith | gaaah |
| 07:04.24 | Ralith | something on my system hates xinerama |
| 07:04.36 | Ralith | my mouse keeps dying >:| |
| 07:04.53 | Ralith | anyway. |
| 07:04.57 | Ralith | Qt's an awfully big dependency. |
| 07:05.11 | brlcad | intersting that they have many of the same widgets as ioe, just in different places, slightly different behaviors |
| 07:06.38 | Ralith | brb, need to restart X |
| 07:07.48 | *** join/#brlcad Ralith (n=ralith@216.162.199.202) | |
| 07:08.51 | brlcad | yes, it is a big dep. if it did exactly what we needed, though, I'd certainly live with that over anything else that didn't give us a crisp beautiful gui |
| 07:09.05 | brlcad | if we could get that gui with something else, something smaller, even better |
| 07:11.20 | Ralith | for all its size, does Qt actually offer much relevant to us that RBGui doesn't? |
| 07:16.01 | brlcad | that's hard to say without doing an evaluation |
| 07:16.27 | brlcad | laying out some of the basic requirements and features and directly doing a comparison |
| 07:16.49 | brlcad | or just dropping the code in and giving it a go to see how it works |
| 07:18.00 | brlcad | the glitzy things that make stellarium very compelling are not exactly provided by qt directly either, so it's really just a matter of widgets and extensibility |
| 07:18.23 | Ralith | nods |
| 07:18.36 | Ralith | examines the RBGui widget implementations |
| 07:19.41 | brlcad | rbgui is so simple that my initial reaction last year was that we could probably gut and extend rbgui to do what we needed with a minimal amount of effort (no less than most frameworks), at least to get to an end state that looks and feels like IOE |
| 07:21.25 | *** join/#brlcad jdoliner (n=jdoliner@c-68-51-76-57.hsd1.il.comcast.net) | |
| 07:21.52 | brlcad | where rbgui will fail is if we need native look and feel, native widget support and the bells and whistles that come with native widgets (like pervasive spell-checking, copy paste support, shortcut navigation and selection keybindings, etc) |
| 07:22.51 | Ralith | copy/paste support should at the very least be trivial to tack on. |
| 07:23.01 | Ralith | at least in X |
| 07:23.02 | brlcad | each feature individually is trivial |
| 07:23.15 | brlcad | there are just about a hundred of them :) |
| 07:23.18 | Ralith | point. |
| 07:24.09 | Ralith | and Qt is very, very well supported. |
| 07:24.38 | Ralith | and documented, and ported, and maintained, and... |
| 07:24.46 | brlcad | and big ;) |
| 07:25.01 | Ralith | the counterpoint to that is that most users will have it anyway. |
| 07:25.11 | brlcad | but yeah, it'd be a non-issue otherwise |
| 07:25.19 | brlcad | as it pretty much just works |
| 07:25.50 | Ralith | it certainly has its attractions. |
| 07:26.51 | brlcad | so that could be a gsoc project in itself |
| 07:27.03 | brlcad | make [insert toolkit here] work |
| 07:27.30 | Ralith | not nearly as fun as getting g3d able to actually interact with some geometry, though. |
| 07:27.32 | brlcad | taking it all the way to matching most of the look and feel intended with customizations |
| 07:27.45 | brlcad | true |
| 07:28.00 | brlcad | but the latter is also complicated by the fact that the backend is a rapidly moving target |
| 07:28.19 | brlcad | there's the libged library (which it presently hooks to) |
| 07:28.35 | brlcad | and which will give it most of mged's command-line functionality |
| 07:29.13 | brlcad | and there's also the new geometry engine, which is ready for basic geometry management but not for a full-blown editor just yet (not this summer) |
| 07:29.46 | brlcad | and there's the geometry service, which is what it should ultimately be using but is even farther still away from completion |
| 07:30.07 | Ralith | so, time might be best spent on the frontend? |
| 07:30.33 | brlcad | probably, that's the one piece that can be worked on in relative isolation |
| 07:30.59 | Ralith | alright. |
| 07:31.10 | brlcad | or working entirely on the backend, working on one of those three, but then there's not much to see |
| 07:31.34 | brlcad | doing just a little of the front and little of the back would be a bit of a mess I think |
| 07:31.34 | Ralith | and a lot more familiarity with BRL-CAD required, no? |
| 07:32.20 | brlcad | depends, for GE yes, for GS slightly less so, for GED not really (it's mostly refactoring and api cleanup now, almost done) |
| 07:33.16 | Ralith | I think my real reservation about Qt is not so much its raw size as that it tries to be an entire application framework rather than just a GUI. |
| 07:33.24 | Ralith | that said, I suppose this is not necessarily a bad thing. |
| 07:33.33 | brlcad | that is true |
| 07:33.54 | Ralith | if it's good at what it does--which I don't know--that might make things a lot easier. |
| 07:35.07 | brlcad | it would be a gsoc-sized project to convert existing rbgui portion over to qt, i'm sure there's refactoring that would need to happen along the way |
| 07:35.46 | Ralith | I'm not sure it wouldn't be easier to start mostly from scratch |
| 07:35.59 | Ralith | considering that even an interface to Ogre is missing |
| 07:36.40 | brlcad | hm, I wouldn't like that -- there's a lot of good effort invested already |
| 07:36.55 | Ralith | that's my feeling too. |
| 07:36.55 | brlcad | things like various mouse interaction modes for example |
| 07:37.27 | brlcad | I'd rather see it evolve that be replaced, even if it feels like it's a slower path |
| 07:37.33 | Ralith | it's hard to say how much of it would survive such a major switch |
| 07:38.08 | Ralith | but, I certainly see your point, and I'm sure such an approach is not infeasible. |
| 07:38.29 | brlcad | perfectly valid to evolve into something completely new |
| 07:40.16 | brlcad | but that would be determined by doing the work and seeing the incremental steps it needs to take to get there |
| 07:40.39 | Ralith | yeah. |
| 07:42.16 | brlcad | another good gsoc project.. de-tcl'fying the core libraries (libbu, libbn, libwdb, librt, libged) |
| 07:42.24 | Ralith | there's TCL in those? O.o |
| 07:42.25 | brlcad | that's a big refactoring task |
| 07:42.47 | Ralith | what's it doing there? |
| 07:42.48 | brlcad | the C api of tcl |
| 07:43.11 | brlcad | tcl actually has a very nice C library |
| 07:43.23 | Ralith | huh? |
| 07:43.33 | Ralith | maybe I just need to look at the code |
| 07:44.39 | brlcad | tcl provides a slew of basic utility classes and callback mechansisms that slowly integrated into the libs over two decades |
| 07:45.13 | brlcad | things like hash tables, appending results to strings, and evaluating callbacks |
| 07:46.09 | Ralith | so, move implementations of all that into libbu? |
| 07:46.10 | brlcad | that aspect of tcl is actually very nice, but for simple containment reasons, I'm reverting a decision that was made about 15 years ago to allow tcl to mix in with core code |
| 07:46.50 | brlcad | yeah, some things we have implementations for, other things would need some basic support added or alternatives found |
| 07:47.31 | Ralith | sounds fairly straightforward. |
| 07:48.01 | Ralith | if involved. |
| 07:48.30 | brlcad | it is, it's just a lot of work |
| 07:48.48 | brlcad | probably would end up refactoring somewhere around ... |
| 07:48.59 | brlcad | does a quick line count check for tcl'isms |
| 07:51.41 | brlcad | so at a minimum, that is refactoring about 4000 lines of code |
| 07:54.10 | Ralith | refactor linecounts can be misleading |
| 07:54.32 | Ralith | considering how much can be done with careful application of regular expressions. |
| 07:54.46 | brlcad | also includes about 200 functions apparently .. so expand that out to all callers and you're probably looking at 20k or so |
| 07:55.51 | brlcad | you could do a few things with regexps, but it'll still be a little tedious |
| 07:56.38 | Ralith | well, sure. |
| 07:56.47 | brlcad | most of it won't just be a function change though, it'll be a different interface and there will be a hundred files that have to be hand-edited because of all the different styles of use |
| 07:57.40 | brlcad | plus given this hits the grand-daddy librt library, extra care would have to be taken to verify changes don't break anything |
| 07:58.08 | Ralith | at least the benchmark suite is helpful there. |
| 07:59.07 | brlcad | that's just a minimum, but yeah |
| 08:01.47 | Ralith | there's also plenty to be said for a very well-defined task. |
| 08:03.05 | brlcad | refactoring tasks are often my favorite to work on |
| 08:03.38 | brlcad | they're well defined, you usually have an exact work list that you can identify, however long and tedious it may be |
| 08:04.11 | brlcad | i'll have the files in my emacs buffer and can watch the % complete increase as I make progress |
| 08:04.52 | brlcad | best part is usually the "clean" feeling that usually results |
| 08:04.59 | Ralith | yeah. |
| 08:05.12 | brlcad | and invariably, the code is then easier for others to understand and extend with new functionality |
| 08:05.55 | brlcad | seems to happen every time, gets cleaned up then someone takes it to the next level |
| 08:11.39 | Ralith | reviews the gsoc paperwork |
| 08:27.17 | Ralith | I should be able to get my applications in tomorrow. |
| 09:06.08 | *** join/#brlcad _sushi_ (n=_sushi_@77-58-239-242.dclient.hispeed.ch) | |
| 09:46.48 | *** join/#brlcad andrecastelo_ (n=chatzill@189.71.13.123) | |
| 10:04.58 | *** join/#brlcad hippieindamakin8 (n=hippiein@202.3.77.38) | |
| 12:09.57 | CIA-40 | BRL-CAD: 03Homovulgaris 07http://brlcad.org * r1312 10/wiki/Libpc: /* Objectives */ |
| 12:20.47 | *** join/#brlcad Axman6 (n=Axman6@pdpc/supporter/student/Axman6) | |
| 12:34.16 | CIA-40 | BRL-CAD: 03Homovulgaris 07http://brlcad.org * r1313 10/wiki/Libpc: /* Structure */ |
| 12:42.34 | *** join/#brlcad madant (n=madant@117.196.128.25) | |
| 13:38.29 | *** join/#brlcad hippieindamakin8 (n=hippiein@202.3.77.38) | |
| 13:39.33 | *** join/#brlcad ashishrai (i=d2d43dfb@gateway/web/ajax/mibbit.com/x-16e4f5c8f811b3db) | |
| 14:36.43 | *** join/#brlcad elite01 (n=omg@unaffiliated/elite01) | |
| 14:49.05 | ``Erik | <PROTECTED> |
| 15:12.00 | *** join/#brlcad madant (n=madant@117.196.145.133) | |
| 15:41.27 | *** join/#brlcad okias (n=5864db99@bz.bzflag.bz) | |
| 15:48.54 | starseeker | gapes in awe at the stellarium |
| 15:48.59 | starseeker | screenshot |
| 15:50.23 | starseeker | As to the point about it being GPL - that will be true for ALL code (up until QT4.5) using QT. It was a licensing requirement |
| 15:51.01 | starseeker | many will probably stick with GPL, but it wouldn't hurt (if there is interest) to talk to the authors and see if they would be willing to re-license under LGPL now that they can |
| 15:51.43 | starseeker | if we find a code base that is genuinely interesting in terms of wanting to drop code straight into BRL-CAD, that's certainly a reasonable first step |
| 15:52.06 | starseeker | if they say no, not a big deal - we simply identify the techniques used to achieve the effect and write our own solution |
| 15:53.22 | starseeker | I've never seen QT used in that way before, but seeing that it can be makes my interest in it rise by at least a factor of 2. |
| 16:00.25 | ``Erik | nifty app |
| 16:06.43 | starseeker | wooof. apparently my system isn't up to handling that |
| 16:07.22 | starseeker | checks website for minimum hardware requirements |
| 16:08.06 | starseeker | hmmmm |
| 16:08.31 | starseeker | my system is much faster than that.... |
| 16:08.34 | starseeker | weird |
| 16:08.51 | ``Erik | doing something silly like running linux on it? :D |
| 16:09.17 | starseeker | uh, vice versa actually |
| 16:09.30 | ``Erik | meant the system |
| 16:09.37 | starseeker | heh |
| 16:09.46 | ``Erik | english sucks for context sensitive statements :D |
| 16:10.26 | ``Erik | hopes it has a 'light pollution' slider O.o |
| 16:13.02 | starseeker | yuck: frames per second = 0.018 |
| 16:16.32 | ``Erik | fires it up |
| 16:20.12 | starseeker | wonders if his nvidia support didn't get reset or something... |
| 16:22.49 | ``Erik | hm, a light pollution selector |
| 16:22.54 | ``Erik | acceptable, I suppose |
| 16:24.16 | starseeker | yech. well, bzflag does it too so it's not stellarium's fault |
| 16:24.24 | starseeker | starts checking nvidia driver versions |
| 16:24.28 | *** join/#brlcad ashishrai (i=d2d43dfb@gateway/web/ajax/mibbit.com/x-8d422da770869a68) | |
| 16:25.49 | starseeker | oh, cute, it's using the software one. why???? |
| 16:25.53 | starseeker | alrightie... |
| 16:26.05 | ``Erik | 50fps here :) |
| 16:26.11 | ``Erik | that's a pretty nifty app |
| 16:30.20 | starseeker | yep, there we go |
| 16:30.38 | starseeker | in the 40 range here (after fixing acceleration) |
| 16:30.43 | starseeker | that is cool |
| 16:31.03 | *** join/#brlcad hippieindamakin8 (n=hippiein@202.3.77.38) | |
| 16:32.29 | ``Erik | I might stick my head out tonight to look for saturn |
| 16:39.33 | ``Erik | wonders why he has to put .cvsignore in his .cvsignore O.o |
| 16:47.02 | *** join/#brlcad dreeves (n=IceChat7@67.130.253.14) | |
| 17:30.58 | *** join/#brlcad madant (n=madant@117.196.135.248) | |
| 17:52.59 | brlcad | starseeker: it's not a big deal either way, it's really not that hard to design a custom interface (even with or without qt) |
| 17:53.41 | brlcad | we're talking about days or weeks of time, not months, generally speaking |
| 17:54.35 | brlcad | but yeah, stellarium is one of several projects that have a really nice custom interface (there are others) |
| 18:21.00 | starseeker | brlcad: Indeed. That's what inclines me more towards QT in fact - since it allows the custom part (and that wouldn't be a big deal, agreed) it gives us for free native look and feel when/if we want it, which is a lot harder and more maintainance headache |
| 18:36.10 | brlcad | not quite for free, but it does make that option a little bit easier |
| 18:37.43 | brlcad | starseeker: another really nice 'streamlined' but gorgeous interface to look at is one of the apple opengl source code demo applications |
| 18:40.25 | brlcad | that's actually more in-line with what I would really like to see for an initial pre-release interface with single main display manaer context with some bindings, text overlays, crisp opengl with various render modes available, and an on-demand command prompt |
| 18:41.03 | brlcad | alas, that demo itself is mac-specific |
| 18:45.52 | *** join/#brlcad pacman87 (n=pacman87@resnet-46-40.dorm.utexas.edu) | |
| 18:50.34 | starseeker | brlcad: any movies of it? |
| 19:18.55 | brlcad | starseeker: hm, no |
| 19:37.52 | *** join/#brlcad andrecastelo (n=chatzill@189.71.13.123) | |
| 19:40.29 | *** join/#brlcad jdoliner (n=jdoliner@c-68-51-76-57.hsd1.il.comcast.net) | |
| 20:02.09 | brlcad | contemplates stealing a couple of the bz buttons for menu items |
| 21:04.37 | *** join/#brlcad andax (n=andax__@d213-102-41-93.cust.tele2.ch) | |
| 21:55.17 | *** join/#brlcad dreeves (n=dreeves@67.130.253.14) | |
| 22:28.08 | Ralith | brlcad: I find myself still wondering if the benefits of relatively easy native integration are worth the effort necessary to openglify it; blender, for example, seems to get by fine with little to no native integration. |
| 22:28.15 | Ralith | (re: Qt) |
| 22:28.59 | Ralith | also, do you ever sleep? :P |
| 22:29.59 | andax | Ralith: opengl is not supported by all graphics cards. would there be alternatives? |
| 22:30.19 | Ralith | it's not? |
| 22:31.05 | andax | i remember i had a Asus AMD64 board with onboard graphics card (Chrome) which had no opengl |
| 22:31.35 | Ralith | I would be very surprised if that's the case. |
| 22:31.54 | Ralith | besides, anybody who expects to use a modern CAD app will need OpenGL one way or another. |
| 22:31.58 | Ralith | it's the industry standard |
| 22:35.13 | Ralith | that said, I believe RBGui + Ogre will allow us to run on DirectX for no extra effort |
| 22:36.24 | andax | it was a via s3 unichrome pro graphics card. okay, it was a cheap office PC but i remember i had vector graphics even on our first DOS-box with a 8086 CPU and wondered why i need that opengl support from hardware side for practically all 3d applications |
| 22:37.47 | *** join/#brlcad andax_ (n=andax__@d213-102-40-81.cust.tele2.ch) | |
| 22:38.44 | Ralith | because OpenGL is the standard. |
| 22:39.04 | Ralith | ancient hardware doesn't always implement the standards; this is one of the reasons it has been superseded. |
| 22:39.11 | kanzure | Hi all, does anyone know of anything capable of converting a .sldprt file that I have laying around here? |
| 22:40.06 | Ralith | kanzure: from solidworks? I think you'll have to convert it to something more standard using solidworks as an intermediary first. |
| 22:42.15 | Ralith | andax: you have to admit, "there used to be some hardware that didn't support it" is not a very strong argument. |
| 22:42.21 | Ralith | as it could be applied to anything. |
| 22:42.46 | kanzure | Ralith: I don't have solidworks. |
| 22:42.47 | andax_ | Ralith: yes, but on the other hand we already had 3d graphics on this acient hardware before anyone talked about opengl. i remember f-18 flight simulation from microprose, for example :) |
| 22:42.56 | Ralith | kanzure: that sounds like a problem. |
| 22:42.57 | kanzure | Blah. I told these guys why they shouldn't use non-free software. |
| 22:43.09 | kanzure | throws a fit |
| 22:43.16 | Ralith | andax_: usually not hardware accelerated, though. |
| 22:43.25 | Ralith | you can always use mged. |
| 22:43.37 | kanzure | ? |
| 22:43.43 | kanzure | to convert the file? |
| 22:44.04 | Ralith | was talking to andax_ |
| 22:44.06 | kanzure | the problem is that I have a dot sldprt file, and a dot stl of the file, but the dot stl is wrong- there are some triangle errors and so on that 'netgen' is able to find though not fix |
| 22:44.26 | kanzure | maybe I'll go pray to the netgen folks for "Dr. STL" to start working |
| 22:45.08 | kanzure | context- here's what I've been doing today- http://www.youtube.com/watch?v=sPY84NelFO4 |
| 22:49.30 | Ralith | kanzure: meshlab maybe? |
| 22:53.08 | kanzure | haven't heard of it |
| 22:53.25 | Ralith | it seems to be good at cleaning up that sort of thing |
| 22:56.45 | kanzure | http://meshlab.sourceforge.net/wiki/index.php/Compiling |
| 22:56.49 | kanzure | wtf is wrong with these people? :p |
| 22:58.06 | *** join/#brlcad brlcad (n=sean@bz.bzflag.bz) | |
| 22:58.07 | Ralith | ? |
| 22:58.23 | kanzure | guess they've never heard of dependency management and autogen |
| 22:58.54 | Ralith | where do you get that idea? |
| 22:59.02 | Ralith | just because they list the dependencies? |
| 22:59.42 | kanzure | because I downloaded it and I have to manually compile all of these sub packages or whatever |
| 23:00.01 | Ralith | or you could just, you know, install them with your package manager. |
| 23:00.02 | kanzure | also, that's a non-standard way of listing dependencies |
| 23:00.11 | kanzure | nope, they are not available from the package manager |
| 23:00.12 | Ralith | there's a standard way? |
| 23:00.15 | kanzure | I checked before I started ranting :) |
| 23:00.18 | Ralith | that's your distro's fault, then |
| 23:00.19 | Ralith | not theirs |
| 23:00.31 | kanzure | well, most distributions have standdard ways of managing dependencies |
| 23:00.33 | kanzure | not really |
| 23:00.37 | kanzure | they could have just picked any standard format |
| 23:00.46 | kanzure | for instance, on debian there is an 'alien' tool to convert between rpm and to deb and such |
| 23:00.51 | Ralith | then they would have been unable to support the others. |
| 23:00.56 | Ralith | and that's a binary release, not source. |
| 23:01.18 | kanzure | recalls obtaining source packages through package managers |
| 23:01.22 | Ralith | they're not responsible for making their tools available in your repository of source |
| 23:01.26 | Ralith | er |
| 23:01.27 | Ralith | of choice |
| 23:01.38 | Ralith | that's up to whoever manages the repository |
| 23:01.39 | kanzure | I guess they could make it completely unavailable |
| 23:01.52 | Ralith | if you don't like it, ask whoever manages the repository to include it |
| 23:01.59 | brlcad | 2yeah, same here |
| 23:02.04 | kanzure | still, lack of a make file.. |
| 23:02.17 | Ralith | nothing big comes with makefiles |
| 23:02.22 | Ralith | qmake is a build system that generates makefiles. |
| 23:02.29 | Ralith | just like autotools, cmake, etc |
| 23:02.31 | kanzure | so is autogen, like I mentioned :) |
| 23:02.32 | kanzure | yeah |
| 23:02.32 | *** join/#brlcad MinuteElectron (n=MinuteEl@unaffiliated/minuteelectron) | |
| 23:02.43 | Ralith | there's nothing wrong with using something other than autotools |
| 23:02.54 | kanzure | there's something wrong with using nothing. |
| 23:02.58 | Ralith | they're using qmake |
| 23:03.01 | Ralith | qmake != nothing |
| 23:03.06 | kanzure | wtf? /me checks the directory again |
| 23:03.30 | Ralith | brlcad: did you get my earlier comment? |
| 23:03.32 | kanzure | how can you tell? |
| 23:03.38 | Ralith | kanzure: because it says so in the wiki page you linked. |
| 23:03.39 | kanzure | ah, there's a make file at least |
| 23:05.33 | kanzure | okay, nevermind, you're right. |
| 23:07.36 | *** join/#brlcad d-lo (n=claymore@bz.bzflag.bz) | |
| 23:07.42 | *** join/#brlcad MinuteElectron (n=MinuteEl@unaffiliated/minuteelectron) | |
| 23:36.19 | *** join/#brlcad starseeker_ (n=CY@c-68-33-217-173.hsd1.md.comcast.net) | |
| 23:36.32 | starseeker_ | hmm - is bz having trouble? |
| 23:36.58 | starseeker_ | can't ssh in |
| 23:48.01 | *** join/#brlcad d-lo (n=claymore@bz.bzflag.bz) | |
