Discussion:
[9fans] nix at lsub
(too old to reply)
hiro
2012-04-19 01:37:08 UTC
Permalink
Is this a joke? Has cocoa been ported to qt now?
Jeff Sickel
2012-04-19 04:15:46 UTC
Permalink
Qt's been ported to OSX. It's not really worth it though,
better to go native drawing libraries with Cocoa or OpenGL.
Post by hiro
Is this a joke? Has cocoa been ported to qt now?
Charles Forsyth
2012-04-19 08:10:36 UTC
Permalink
OpenGL (within its scope) covers several platforms at once, and anyway has
to be handled somehow.
Early in Inferno's history, I looked at the then version OpenGL but since at
the time it kept drawing state hidden (similar to PostScript), and largely
global, and the
designers hadn't discovered data structures yet, it wasn't clear whether
one could do a pleasant interface to it. To judge from (say) the current
Python interface,
probably not. Still putrid, but there's apparently not a lot you can do.

(OpenVG by contrast seemed much better done, but that's 2D.)
Post by Jeff Sickel
better to go native drawing libraries with Cocoa or OpenGL.
Joseph Stewart
2012-04-19 08:16:08 UTC
Permalink
I've intended to see if I can glean any wisdom from the Android interface
to OpenGL but have had neither the time nor motivation.

Anyone here know if it's a model to learn from?

-joe

On Thu, Apr 19, 2012 at 5:10 PM, Charles Forsyth
Post by Charles Forsyth
OpenGL (within its scope) covers several platforms at once, and anyway has
to be handled somehow.
Early in Inferno's history, I looked at the then version OpenGL but since at
the time it kept drawing state hidden (similar to PostScript), and largely
global, and the
designers hadn't discovered data structures yet, it wasn't clear whether
one could do a pleasant interface to it. To judge from (say) the current
Python interface,
probably not. Still putrid, but there's apparently not a lot you can do.
(OpenVG by contrast seemed much better done, but that's 2D.)
Post by Jeff Sickel
better to go native drawing libraries with Cocoa or OpenGL.
Charles Forsyth
2012-04-19 08:46:28 UTC
Permalink
Post by Joseph Stewart
Anyone here know if it's a model to learn from?
Another glance, and I'd say it's similar to the others (except for the
onXYZ style of programming).
Because GL is fairly big and complicated, everyone copies the original
interface conventions precisely.
That way you can look it up in the manual. Unfortunately, it means you
get FORTRAN in every language.
(The original target might have been C, but it looks like "FORTRAN in
any language". There are older
graphics interfaces in C that have data structures, so it's not impossible.)
Thus, you get



// Enabled the vertices buffer for writing and to be used during
// rendering.
gl.glFrontFace(GL10.GL_CCW); // OpenGL docs
// Enable face culling.
gl.glEnable(GL10.GL_CULL_FACE); // OpenGL docs
// What faces to remove with the face culling.
gl.glCullFace(GL10.GL_BACK); // OpenGL docs

// Enabled the vertices buffer for writing and to be used during
// rendering.
gl.glEnableClientState(GL10.GL_VERTEX_ARRAY);// OpenGL docs.
// Specifies the location and data format of an array of vertex
// coordinates to use when rendering.
gl.glVertexPointer(3, GL10.GL_FLOAT, 0, // OpenGL docs
vertexBuffer);

gl.glDrawElements(GL10.GL_TRIANGLES, indices.length,// OpenGL docs
GL10.GL_UNSIGNED_SHORT, indexBuffer);

// Disable the vertices buffer.
gl.glDisableClientState(GL10.GL_VERTEX_ARRAY); // OpenGL docs
// Disable face culling.
gl.glDisable(GL10.GL_CULL_FACE); // OpenGL docs

Note the state, and the stylish "gl.gl...". Stutter and suffer!

"But wait!", I hear you cry. State, callbacks, no data structures to
speak of, ... why don't we look
at how they handle this stuff in ... Haskell! (Monads, and a learning
curve, though you can then build
up something that's not entirely graphics machine code.)
Bakul Shah
2012-04-19 10:03:02 UTC
Permalink
Post by Charles Forsyth
"But wait!", I hear you cry. State, callbacks, no data structures to
speak of, ... why don't we look
at how they handle this stuff in ... Haskell! (Monads, and a learning
curve, though you can then build
up something that's not entirely graphics machine code.)
It is a big state machine because you have to give it a lot of state & the 3D h/w does do a lot of complicated things! SGI had open inventor, a scene graph level C++ API but it didn't really go anywhere it seems.

But I think openGL 3.0+ and openGL ES 2.0 with their programmable pipeline can map well to a fileserver, where you write your data to the openGL server and the GPU does all the heavy lifting. This can also work reasonably well where the 3D h/w is a few tens of microseconds away from your cpu. I have a partial paper design but long way to go. A prototype is needed to see how well this will perform. An openInventor/coin3D/ivy (in scheme) kind of GUI library can be build on top of that.
Charles Forsyth
2012-04-19 10:32:03 UTC
Permalink
This post might be inappropriate. Click to display it.
Bakul Shah
2012-04-19 16:36:08 UTC
Permalink
Post by Charles Forsyth
I wasn't too worried about getting a file system interface to it.
I'd supposed that would be tedious (from the size of the language) but
straightforward, similar in principle to draw(2).
A filesystem interface seems to simplify things quite a bit.
Post by Charles Forsyth
Draw's programming interface can, however, present Images, Screens,
Points, Rectangles, Screens, Fonts, and so on as values that can be
created and manipulated like any other.
This can be built on top of the above. A /dev/draw shim
wouldn't be too hard either. In a sense openGL is at the
machine assembly language level while screens, rectangles,
fonts etc are at a higher language level.
Post by Charles Forsyth
Obviously there's still an underlying state in the image currently
drawn in an Image, or on a Display.
"None of the matrix manipulation commands have an explicit parameter
to control which matrix they affect. Instead, OpenGL maintains a
current matrix mode that determines which matrix type the previously
mentioned matrix manipulation commands actually affects" and "each
matrix type has its own a stack of matrices". (That's followed in a
document I'm looking at by all the ways you can get into trouble with
this,
but how much faster it all is!) And, that state is program global.
Still, that's what there is!
Indeed but GL ES 2 is simpler by virtue of leaving out fixed
pipeline functions etc. We may as well make the best use of it
when a $35 computer can provide a high performance openGL
implementation!
c***@gmail.com
2012-04-19 15:50:59 UTC
Permalink
having to write the same set of GUI interfaces
three times (X11, windows, Mac OS).
I'd like to put in a good word for Plan 9, in case it gets forgotten.
And, yes, Qt does not support Plan 9, I guess we'll need to find some
compromise, if at all possible.
++L
Good point. Unfortunately, until Plan 9 grows a C++ compiler, Qt isn't
an option for it. If/when that does happen, it would be a worthwhile
thing to have there (In My Humble Opinion, of course :-).
We would be glad to work further on such a C++ port with anybody who can handle the Qt end of things so anybody interested in exploring such an endeavor should discuss with us.

- Greg
Lucio De Re
2012-04-19 16:11:20 UTC
Permalink
Post by c***@gmail.com
We would be glad to work further on such a C++ port with anybody who
can handle the Qt end of things so anybody interested in exploring
such an endeavor should discuss with us.
I have a friend who is totally sold on LLVM, but I note that it is
itself written in C++, so bootstrapping would be difficult (I think I
still have a running version of GCC 3.0, . As for me, I guess I was
waiting for the opportunity to point out that the Go Nuts are
discussing options for a visual interface for Go which is where I
would place my bets.

Still, the point that the infrastructure could be based on an existing
code base is not to be frowned upon. I suspect that in this
particular instance we're either going to get very strong leadership
producing a robust, but easily criticised outcome, or a weak community
that produces a wishy-washy compromise that pleases no one, but is
just good enough and will become the next bloated standard.

I'm happy to take part in the former project.

++L
c***@gmail.com
2012-04-19 17:09:33 UTC
Permalink
Post by Lucio De Re
Post by c***@gmail.com
We would be glad to work further on such a C++ port with anybody who
can handle the Qt end of things so anybody interested in exploring
such an endeavor should discuss with us.
I have a friend who is totally sold on LLVM, but I note that it is
itself written in C++, so bootstrapping would be difficult (I think I
still have a running version of GCC 3.0,
Speaking with their developers a few years ago they did not think it was a good idea/reasonably feasible.
I may be biased, but still sure some general flavor of Comeau for Plan 9 could be a near term and not expensive endeavor (though it depends upon ones definition of inexpensive too I guess). And Qt definitely has its place in the world.
- Greg
Lucio De Re
2012-04-19 17:56:08 UTC
Permalink
This post might be inappropriate. Click to display it.
Comeau At9Fans
2012-04-19 18:05:51 UTC
Permalink
Post by Lucio De Re
I may be biased, but still sure some general flavor of Comeau for
Plan 9 could be a near term and not expensive endeavor (though it
depends upon ones definition of inexpensive too I guess). And Qt
definitely has its place in the world.
I've bought the Go faith lock, stock and barrel, to mix a couple of
metaphors. And I like Go specifically because its core belief is that
it is high time conventions were tossed out the window. I am actually
quite frustrated because I feel that evolution in the IT field is
taking a path of least resistance (I have occasionally pressed Russ
Cox to relent on the policy of minimal change in the Go toolchain, I
seldom, if ever, won on principle) and wish "I had words like a
hammer" to promote a much more aggressive approach to do what is right
rather than what is expedient.
IMO, there is nothing generally wrong with taking the path of least
resistence, so long as open is open minded and also so long as it is not
the only path being considered.
Post by Lucio De Re
I'd like to mention, for example, the idea expressed here that a $35
device will give you 3D capabilities. Sure, but the same $35 could
give you considerably more and accepting what's on offer is, in my
opinion, wimping out. Maybe I can immodestly (and probably
untruthfully) say that _I_ could do better than that and that so could
many others in this forum and we are all compelled to sacrifice our
possible contributions to a better world by those in the industry that
know how to manipulate our gratification sensors.
I could list many examples (and so no doubt could each one of us here)
of benefits whose real cost is much higher than the amount of dollars
being spent on them. In some respects I am fortunate: I live in an
old Apartheid-built small town in South Africa and the digital divide
is so obvious here, yet there is no real cause for it. But I don't
have the skill to express how infuriating it all is...
What I'm looking for is to replace obsolescence with efficiency: 3000
pupils in my immediate vicinity could enjoy much better access to the
Internet (_any_ access to the Internet) if I could deploy KA9Q over
MSDOS as the primary software on 8088 based computers. I know this
because back in 1992 I had precisely that hardware serving single
dial-up connections from a small community of BBSers. These children
don't need pr0n or video clips, Facebook or twitter, they need text
access, e-mail, the much maligned and damaged e-news, just as I found
them useful back in the very early 1990s. But we are stealing that
from them by moving the entry bar ever higher so that our obsolete
computers and our mobile phones with dead batteries and incompatible
SIM cards, VGA monitors, memory simms and all manners of perfectly
useful IT equipment cannot conceivably be deployed to improve their
standard of living and their ability to catch up.
Understood.
Post by Lucio De Re
What I'm looking for is the community that is savvy enough to embrace
new technology and caring enough to propagate their gains to those who
do not have the same access to that technology instead of making sure
of the opposite. I don't believe that there is a conflict, in fact, I
think that's the only option open to us, I'm just waving its flag a
little ahead of the tsunami. And that tsunami includes Go, Plan 9,
possibly Android, vx32 and Raspberry Pie. I pray that I'm not just a
crazy visionary.
Why not pray that you *are* a crazy visionary? :)
Post by Lucio De Re
Anyway, sorry to rant like this, I don't even know if it made me feel
any better to do it, I do hope that some of you will see things from
my perspective and perhaps my feelings will resonate with your own.
Lucio.
--
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
Lucio De Re
2012-04-19 18:27:30 UTC
Permalink
Post by Comeau At9Fans
Why not pray that you *are* a crazy visionary? :)
Too many years of logic, I'm a very rational materialist. But thank
you for the suggestion, it gave me reason to smile. I do get plenty,
in their lack of technical sophistication , my "previously
disadvantaged" neighbours have a great deal of warmth and friendship
to share. All the more reason for me to wish to help them.

++L
Lucio De Re
2012-04-19 18:23:22 UTC
Permalink
Post by Comeau At9Fans
IMO, there is nothing generally wrong with taking the path of least
resistence, so long as open is open minded and also so long as it is not
the only path being considered.
Except that by definition the path of least resistance is the only one
of its type. You buy the reason, you paint yourself in the corner. I
do grant that one may choose the path of least resistance for reasons
other than the ostensible one, but I doubt that would be anything more
than an accident. Can you see where my reasonaing takes me?

++L

Loading...