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) |