| | Logging Started : Sat Jan 09 14:14:14 EST 1999 |
|
anoq:
|
Since there's not much discussion...
|
| | graydon just got a call from landlord warning about the noise.. sigh. |
|
anoq:
|
I have been implementing the Abstract GUI thingy in ML on WindowsNT
|
|
anoq:
|
It seems to work just great..
|
|
graydon:
|
Woah! y'all didn't actually get a clock and an xeyes clone working, did ya?
|
|
Chalky:
|
graydon: yep
|
|
graydon:
|
Chalky: youdeman!
|
|
graydon:
|
anoq: why code ML on NT? sml/nj is linuxified..
|
|
anoq:
|
I need this for a commercial project, and the money is on NT... sigh
|
|
anoq:
|
It's a LightWave-helper utility
|
|
Chalky:
|
graydon: there is a bug with eyes though.. sometimes it locks up, tho not as often with larger window sizes (aaron said it was a child_mutex deadlock or something)
|
|
graydon:
|
Ohh, lots of native-API integration :)
|
|
graydon:
|
Chalky: did you commit it to cvs?
|
|
anoq:
|
But it's no problem to port to SML/NJ eXene :)
|
|
Chalky:
|
graydon: aaron did.. I dont have access
|
|
anoq:
|
graydon: MLWorks has got a NICE version of the Windows API (nice for being the Windows API that is...)
|
|
graydon:
|
Chalky: err. I suppose you'll be needing cvs access.. send me an SSH 1.x pubkey
|
|
graydon:
|
Chalky: graydon@pobox.com
|
|
Chalky:
|
graydon: would that be /etc/ssh/ssh_host_key.pub? (I'm not familiar with this ssh stuff)
|
|
graydon:
|
Chalky: it'll be in ~/.ssh/ideneity.pub
|
|
graydon:
|
Chalky: after you do ssh-keygen
|
|
graydon:
|
oops. identity.pub
|
|
anoq:
|
graydon: I'll send you a key some day I remember it when in Linux :)
|
|
Chalky:
|
graydon: does it matter that the user@host at the end is wrong? (my /etc/hostname doesnt really exist.. dynamic IP and all)
|
|
graydon:
|
Chalky: no, the user@host is just a string it uses to lookup the key by. so long as it's the same name now as in the future, even if it's a bogus name.
|
|
Chalky:
|
grayon: okay, sending
|
|
Aaron:
|
ok back
|
| | Aaron is back from the dead. Gone 0 hrs 16 min 5 secs |
|
Chalky:
|
Aaron: s/button/polygon/ in the idl, that'll fix it
|
|
Aaron:
|
Chalky: ack
|
|
Aaron:
|
cgalky: did everything else look almost right?
|
|
Chalky:
|
Aaron: didn't look.. but libwarsaw.so compiles fine
|
|
graydon:
|
chalky: did you write a new demo application to open up the eyes & clock?
|
|
Aaron:
|
ok
|
|
Aaron:
|
graydon: they're in the repository
|
|
Aaron:
|
graydon: ts is writing a space invaders
|
|
ts:
|
heh
|
|
Chalky:
|
hi ts
|
|
Aaron:
|
hi ts
|
|
Aaron:
|
hmml.
|
|
Aaron:
|
wonder why the build setup doesn't relink libraries when their depends are old....
|
|
ts:
|
speaking of space invaders... i think someone invaded my body while i was asleep
|
|
Aaron:
|
or incomplete
|
|
ts:
|
i feel horrible
|
|
graydon:
|
chalky: hmm, this demo program looks so familliar :)
|
|
Loren__:
|
Did I miss anything?
|
|
yanele:
|
anyone know any software to mirror a website?
|
|
Aaron:
|
ts: sick?
|
|
ts:
|
aaron: just tired ;)
|
|
Chalky:
|
graydon: GPL in action :)
|
|
Jordy:
|
mm
|
|
Aaron:
|
re jordy
|
|
Jordy:
|
brb
|
|
graydon:
|
Aaron: you committed identical polygonWidget.cc and polygonWidget_impl.cc, likewise for .hh. is this intentional?
|
|
anoq:
|
mmmm, nice candy :) Are we about ready to begin?
|
| | graydon thinks it's time, yeah? |
|
Aaron:
|
graydon: no
|
|
Loren__:
|
Anyone we know of missing?
|
|
Aaron:
|
graydon: I'll delete some
|
| | graydon goes to find that "agenda"... hehe |
|
Jordy:
|
alrighy
|
| | Rowan (email@p035.gro.euronet.nl) has joined channel #berlin |
|
Rowan:
|
hello again
|
|
graydon:
|
iirc there was a sorta split between "administrive" stuff to discuss and "code/design" stuff
|
|
stefan:
|
hi Rowan
|
|
anoq:
|
Hello Jordy and Rowan! L=:)
|
|
graydon:
|
anyone have any preferences which order we do 'em in?
|
|
Loren__:
|
My organizer just went off... (alarm) That's one thing a paper daytimer won't do
|
|
Rowan:
|
who uses ISDN?
|
|
stefan:
|
I think administrative stuff is settled more easily
|
|
Loren__:
|
graydon: iirc???
|
|
Jordy:
|
i just woke up, give me a sec graydon
|
|
stefan:
|
so lets start with that
|
|
Jordy:
|
i got to get some soda :)
|
|
Jordy:
|
need coke, must wake up
|
|
graydon:
|
Loren: if I recall correctly
|
|
Loren__:
|
thanks
|
| | graydon has set the topic: "Berlin meeting: administrative stuff" |
| | graydon has set the topic: Berlin meeting: administrative stuff |
|
ts:
|
jordy: me too
|
|
Dusk:
|
Cool, I always thought it meant "If I ReCall"
|
|
Rowan:
|
nobody uses ISDN?
|
|
graydon:
|
ok, we *did* get a BTS set up from linuxcare.com
|
|
Aaron:
|
graydon: what's needed to get it going
|
|
Jordy:
|
ok
|
|
Chalky:
|
BTS?
|
|
Jordy:
|
i got my coke :)
|
|
graydon:
|
the problem is, it appears to be somewhat if not completely broken, and they don't answer their mail
|
| | Loren__ is feeling dumb... what's a BTS? |
|
graydon:
|
Chalky: bug tracking system
|
|
Chalky:
|
oh, right
|
|
Jordy:
|
bug t
|
|
Loren__:
|
Yeh... those are good...
|
|
graydon:
|
it's in instance of jitterbug, but it's not useable at the moment
|
|
ts:
|
graydon: maybe they cant figure out how to apply it to their own site?
|
|
Chalky:
|
I like tinderbox :)
|
|
Aaron:
|
class polygonWidget_impl : virtual public _lc_sk_polygonWidget,
|
|
Aaron:
|
{
|
|
Aaron:
|
oops sorry people
|
|
Jordy:
|
tinderbox is nice, but the entry for for a bug is well
|
|
Dusk:
|
Any other good (free) BTS's out there?
|
|
Loren__:
|
graydon: can I recommend something?
|
|
graydon:
|
Dusk: we probably have access to the debian one if we want it, but I have no experience with it. Anyone used it?
|
|
graydon:
|
Loren: sure
|
|
Jordy:
|
a bit harsh, it should show you all open bugs so you can make sure you are not entering in one which isn't already in the db
|
|
Jordy:
|
debian one?
|
|
Dusk:
|
Yes, it would need good filtering.
|
|
Jordy:
|
i've only used tinderbox from mozilla.org
|
|
Loren__:
|
graydon: as far as BTS... I wanna recommend something similar to what we use at work...
|
|
graydon:
|
Jordy: yeah, debian has a custom written email-based BTS, which revolves around some (so I've heared) unpleasant perl4 scripts, but it apparantly works.
|
|
Jordy:
|
email-based?
|
|
Dusk:
|
graydon: Does it have any kind of web interface?
|
|
Aaron:
|
Dusk: no
|
| | graydon uses gnats at work, which is OK, but not perfect. |
|
Jordy:
|
actually, i have used gnats
|
|
graydon:
|
Well, it's not *critical* at the moment, I'll keep hounding linuxcare.com :).. was just fishing for suggestions.
|
|
Loren__:
|
Basically we have a DB of severtal different types of data... STRs(Software Trouble Rpts) RCI (Request for Content Items -- Req for new feature)... SEP (Suggestions to Enhance Product) and SCRs or (Software change reports--bugfix reports...)
|
|
ts:
|
heh
|
|
graydon:
|
Loren: it's not so much the categories I'm concerned about, it's the useability. it has to encourage people to submit bugs, nag people who need to fix bugs, and be easy enough to track who's fixed them.
|
|
Loren__:
|
graydon: I'm not reccomending that we have the same exact type of system, but having the paper trail to go back to is often quite usefull...
|
|
graydon:
|
Loren: yes, that's what all BTSs do. just trying to get one we can rely on, for berlin.
|
|
graydon:
|
ok, dead topic.
|
| | graydon has set the topic: "Berlin meeting: administrative stuff : announcement mailing list" |
| | graydon has set the topic: Berlin meeting: administrative stuff : announcement mailing list |
| | saganic (shane@cx637332-a.omhas1.ne.home.com) has joined channel #berlin |
|
Jordy:
|
announcement mailing list?
|
|
graydon:
|
there's a new mailing list set up which I'm shortly going to pipe all CVS log messages into, and will possibly serve as an announcement list for entries into the BTS
|
|
Loren__:
|
graydon: Yeh... The reson I brought up the catagories is because it makes it very easy to determine what code change fixed what bug....
|
|
Jordy:
|
ooooo
|
|
Jordy:
|
now that's nice
|
|
Jordy:
|
i wish we could get our own names into the log messages though, it's sort of confusing to know who committed changes
|
|
Loren__:
|
BTW... someone is logging this? right?
|
|
graydon:
|
no humans can post to it, I don't want it turning into some "private" forum, but for non-lurkers who want to see the CVS activity, I think it'll be useful.
|
|
Aaron:
|
Jordy: just put a -jordy at the end of your comments
|
|
graydon:
|
Jordy: yes, it's silly to all have to work under 1 uid..
|
|
Jordy:
|
there must be a way to get around that
|
|
Aaron:
|
graydon: we can't all get cvs accounts on va though...
|
|
graydon:
|
Jordy: if we use CVS Pserver protocol, we get around it, but pserver is insecure. otherwise everyone would need accounts on va, which is a lengthy process and would be debated by the admins most likely.
|
|
Chalky:
|
cant pserver use ssh?
|
|
graydon:
|
I think we'll just need to wait until we get an enormous grant from compaq with our own free servers.
|
| | graydon grins. |
| | anoq doesn't know what va is |
|
graydon:
|
va is the machine hosting cvs
|
|
Dusk:
|
"very apt"?
|
|
Rowan:
|
Heh I have to leave ... I don't like Windoze at all and ISDN isn't willing to work in Linux :-(
|
|
graydon:
|
va, as in VA Research. www.varesearch.com. linux hardware company.
|
| | Jonas (jonasa@p139-35.ppp.get2net.dk) has joined channel #berlin |
|
Aaron:
|
alo jonas
|
|
Jonas:
|
ehlo all
|
|
graydon:
|
hey hey jonas
|
|
Jordy:
|
well, i have a nice command for cvslog which will generate ChangeLog style reports for the last x days/minutes/years/weeks
|
|
anoq:
|
Hej Jonas! :)
|
|
Jordy:
|
which would be a good way to send out everything
|
|
graydon:
|
jonas: what are you an esmtp mta?
|
|
Jonas:
|
sorry for being late, had to dl mirc and find server
|
|
ts:
|
anoq: VA Research
|
| | Rowan has left channel #berlin |
|
Jonas:
|
graydon: been playing with (e)smtp (both)
|
|
Jonas:
|
ok, is the current also the first topic?
|
|
graydon:
|
ok, so anyone who would like to be barraged with CVS messages & bugreports, um, well I guess I'll put a more general announcement on the list about how to subscribe.
|
|
Aaron:
|
cool
|
|
graydon:
|
Jonas: almost. also briefly mentionned the non-working bug tracking system linuxcare.com gave us.
|
| | graydon has set the topic: "Berlin meeting: administrative stuff : docbook" |
| | graydon has set the topic: Berlin meeting: administrative stuff : docbook |
|
graydon:
|
you might have noticed some parts of the website went away and got replaced with a link to "docs"
|
|
Jonas:
|
ok, would be good when we make the first public release (DR1). Announcement should be something like dev-announce@berlin...!?
|
|
Dusk:
|
FWIW, GNOME is considering switching from jitterbug to debian's bug system, or Mozilla's bugzilla.
|
|
Loren__:
|
graydon: now... CVS revisons are numbered... One thing I like about this SCARS system is the bug reports are numbered too... so you can corelate the two...
|
|
graydon:
|
Dusk: that is useful to know.. I've heared rumblings about jitterbug not being very useable when it gets big.
|
|
Jordy:
|
i'm just looking at the web page for CVS, it says you can use SSH as a tunnel for pserver protocol, which sounds to me like you can log in as individual names, but have encryption as well.. using SSH's port forwarding feature
|
|
Dusk:
|
I would have mentioned it sooner, but I had trouble finding it in my old mail...
|
|
graydon:
|
Jordy: uh, yeah, most likely you can do that actually. hadn't thought of that.
|
| | graydon puts "ssh tunnel" on the to-do list. |
|
Jordy:
|
graydon: that way logs and history will show the corect names, we'd be basically logging in twice I guess
|
|
Jonas:
|
graydon (or somebody else) could you make me a patch dated from 29th of dec.? (My last co)
|
|
graydon:
|
Jordy: if you use ssh-agent on your machine, you never notice ssh anyway.
|
|
graydon:
|
Jonas: there's a snapshot from just a couple days ago, on the website.
|
|
Jordy:
|
i personally can't stand SSH, but if I have to use it, I have to use it :)
|
|
Loren__:
|
Jordy: Isn't there a GPLed equivelant of SSH?
|
|
graydon:
|
Loren: yeah, pssst, but it's not done.
|
|
Loren__:
|
graydon: oh well... tough beans...]
|
|
Jordy:
|
i don't know, I just think creating a single application to create an encrypted tunnel is silly especially when you have free SSL library which you can apply to any application (like SSL pop3, SSL ftp, SSL telnet, SSL NFS)
|
|
graydon:
|
Ok, I just want people to know (a) those parts of the website didn't disappear, it was converted into docbook. (b) if you want more stuff to go on the website, best route is to add it to the docbook
|
|
ts:
|
okay so we have GPG now and... what, HSS?
|
|
Jordy:
|
docbook?
|
|
ts:
|
jordy: for sgml
|
|
Loren__:
|
ts: and what do we need to read docbook?
|
|
Jordy:
|
those sgml utils to convert it to html :)
|
|
Dusk:
|
PSGML for emacs works pretty well.
|
|
graydon:
|
to read/write docbook you can use something simple like emacs, or you can convert it very smoothly to TeX/ps/pdf or HTML. the HTML-ified version is on our website, under the "docs" link
|
|
stefan:
|
graydon: could you put some pointers on the home page on how to write docbook compatible docs ?
|
|
ts:
|
loren: you can read it as it is, its tagged
|
|
graydon:
|
stefan: sure, I'll put a link to the docbook home page on the links page.
|
|
stefan:
|
fine.
|
|
Jonas:
|
stefan: the docbook docs are pretty good at describing each tag and combined with psgml :)
|
|
Dusk:
|
There's also good little intro by Mark Galassi at http://nis-www.lanl.gov/~rosalia/mydocs/docbook-intro.html
|
|
graydon:
|
It's a pretty easy format, very much like editing HTML only you're more concerned with structure and less with appearance.
|
|
anoq:
|
wrt SGML - does anyone know if one would ideally make homepages in XML or in SGML?
|
|
Loren__:
|
ts: I kind of figured THAT, but HTML is tagged, and I usually don't read that as text... (same with LaTeX)
|
|
stefan:
|
what exactly is ment to go into the docs ? Warsaw ? Berlin ? Both ?
|
|
Aaron:
|
xml is sgml, isn't it?
|
|
Loren__:
|
Aaron: I don't know, but I'm pretty sure it's not
|
|
Dusk:
|
SGML is just the standard, not the implementation (like HTML, XML, docbook)
|
|
Jordy:
|
XML is a description language, not a layout language
|
|
graydon:
|
stefan: anything and everything you want to explain the workings of. including supporting libraries. it will eventually mature into a developers reference manual
|
|
Jonas:
|
stefan: Warsaw (API) doc, a doc describing the stock implementation (berlin) and such - you know, "standard" documentation :)
|
|
ts:
|
loren: i ususally hand edit HTML... oh well.
|
|
Dusk:
|
You can't write anything in SGML, per se.
|
|
Jordy:
|
you create your information in XML, and you apply a XSL or CSS layout to it
|
|
Jordy:
|
it's really odd :)
|
|
graydon:
|
nonono, XML is a simplification of SGML, but is almost identical
|
|
ts:
|
haha
|
|
ts:
|
they call it a "extended subset of SGML"
|
|
ts:
|
:)
|
|
graydon:
|
ts: well, it's a *huge* simplification, but the idea is to get rid of all the crap nobody was using much anyway and make it possible for joe average to implement
|
|
Jordy:
|
probably because SGML is pretty complex compared to XML
|
|
Loren__:
|
graydon: I thought XML was a turring complete functional language and SGML was just a markup language... but what do I know???
|
|
anoq:
|
So I should use XML for a homepage and convert to HTML?
|
|
stefan:
|
does docbook give rules on how to embedd docs into source code too ?
|
|
ts:
|
graydon: thats what it says on the W3 pages :)
|
|
Aaron:
|
hey, someone take a loowhen you 'cvs rm' something do you have to do anything else for it to be removed?
|
|
graydon:
|
there is actually a docbook XML dtd, which is almost the same
|
|
graydon:
|
Aaron: remove first, then cvs rm.
|
|
Aaron:
|
ok
|
|
graydon:
|
Loren: naw, SML is a functional language :)
|
|
Dusk:
|
Aaron, yeah, you have to run 'cvs commit'.
|
|
anoq:
|
graydon: :)
|
|
graydon:
|
stefan: no. it would be very ugly, since & and < are special characters for SGML/XML, and would need escaping in sourcecode
|
|
ts:
|
heh
|
|
Loren__:
|
Okay... so a meeting summary so far is we're seeting up a BTS... part of which is a CVS log listserve... and much of our web page hase been converted to docbook... right???
|
|
stefan:
|
no, I ment in comments within source code a la //.
|
|
graydon:
|
anoq: right now I'm using a very kludgy perl script for the homepage. I'd like to move it to XML entirely someday.
|
|
graydon:
|
Loren: yeah, we're still in administrative details :(
|
|
Jordy:
|
graydon: wait for generation 5 web browsers first :)
|
|
anoq:
|
jordy: ?
|
|
anoq:
|
list the features! :)
|
|
Jordy:
|
anoq: hard to view XML on a web page without a web browser which can view it
|
|
Dusk:
|
stefan: nope, sorry. You'd need another program to parse out the comments and assemble them into a docbook file.
|
|
graydon:
|
Jordy: no need, you can write server-side stylesheets and make HTML
|
|
graydon:
|
Jordy: I do that for a living :)
|
|
Jordy:
|
really?
|
|
stefan:
|
dusk: exactly ! don't we already have such tools ?
|
| | graydon has set the topic: "Berlin meeting: administrative stuff : new /include directory and CVS branching" |
| | graydon has set the topic: Berlin meeting: administrative stuff : new /include directory and CVS branching |
|
graydon:
|
Jordy: yep
|
|
Jordy:
|
ok, so we are committing omniidl2 generated include files now?
|
|
graydon:
|
ok: a couple weeks ago I branched CVS
|
|
graydon:
|
there is a tag called berlin_0_0_1. everyone saw that happen right?
|
|
Jonas:
|
I like the include/src dirs, except for the #include should just be warsaw/...
|
|
Aaron:
|
which builds, btw ;)
|
|
graydon:
|
it's a sticky tag and anything you commit once checked out under that tag does *not* go back to the main branch
|
|
Jordy:
|
i've been committing to the main branch
|
|
graydon:
|
Jonas: we might (probably will) support multiple ORBs tho
|
|
Jonas:
|
I almost got the 29 dec. to build except missing rtti in _lc_* files, don't get it! all Makefiles contain -fno-rtti ?
|
|
Dusk:
|
graydon: good way to get more language bindings...
|
|
Jordy:
|
no, registrar does not contain -fno-rtti
|
|
Aaron:
|
Jonas: that's fixed in the stable branch
|
|
Jordy:
|
i removed all those flags, registrar kept throwing exceptions when i used them
|
|
Jonas:
|
graydon: I know, but which ORB to use should be "transparant" perhaps just a sym.link? Instead of changing all the #includes
|
|
graydon:
|
The stable branch still requires rtti
|
|
Dusk:
|
So berlin_0_0_1 is the stable branch, and HEAD is the development branch?
|
|
graydon:
|
Jonas: hmm.. yes. you're right.
|
|
graydon:
|
Dusk: yes
|
|
graydon:
|
and HEAD is broken. really broken, because I ran a perl script which rewrote all the #includes and moved everything into /include/foo/bar/baz directories
|
|
Jonas:
|
graydon: I just did cvs co in my "usual" berlin-tree dir, is that not the dev tree?
|
|
graydon:
|
such that you only need -I$(TOPDIR)/include
|
|
stefan:
|
jonas: I think the naming scheme differs from orb to orb, not all orbs call their skeletton _sk_Class...
|
|
graydon:
|
Jonas: that's the head branch.
|
|
Jonas:
|
stefan: oh yeah :)
|
|
graydon:
|
You can always check which branch you're working in using "cvs status"
|
|
Jonas:
|
gray: so I should cvs co HEAD?
|
|
graydon:
|
it'll list all symbolic tags sticking to your branch
|
|
Aaron:
|
just cvs co
|
|
graydon:
|
Jonas: no, HEAD is assumed automatically
|
|
Aaron:
|
it picks which branch for you
|
|
Dusk:
|
cvs co -A
|
|
Loren__:
|
would you need to recompile to use different ORBs???
|
|
Aaron:
|
Loren__: yes
|
|
graydon:
|
Loren: yes
|
|
Jonas:
|
ok, I got the new include/src split so I assume that is the dev?
|
|
stefan:
|
loren: you would even need to rename things a bit :-(
|
|
Jonas:
|
Loren: atleast for some time....
|
|
graydon:
|
Jonas: yeah. a lot of people were asking for it but I knew it would delay 0_0_1, so branch occured.
|
|
Loren__:
|
Aaron: then you can just #ifdef ORB sepcific code... no
|
|
anoq:
|
The new CORBA spec should fix that - right?
|
|
Loren__:
|
?
|
|
Jordy:
|
ok, so even though I've committed things to the main branch, they won't show up in the tags... which i can understand
|
|
Aaron:
|
corba 3 fixes some implementation-end stuff
|
|
Jordy:
|
i was going to buy a book on the CORBA POA and what not, but the only books that were new enough come out in a few months
|
| | graydon thinks we can solve the orb dependency with a couple MAKE variables and some cpp macros |
|
Aaron:
|
Jordy: just get the omg spec
|
|
stefan:
|
that would be nice, indeed...
|
|
Jordy:
|
i can't read those omg docs, ghostscript gives me a headache
|
|
graydon:
|
Jordy: acroread is much better
|
|
Jonas:
|
jordy, try the pdfs?
|
|
Jordy:
|
acrobat format? mm
|
|
Jordy:
|
acrobat has this odd definition for page-down :)
|
|
Jonas:
|
jordy: my version of gv has antialiasing, very nice! :)
|
| | Aaron notes a new gv was released |
|
graydon:
|
Anyone else have other administrative / non-code issues to discuss?
|
| | Jordy thinks |
|
stefan:
|
graydon: what about naming rules for classes/files etc. ?
|
|
Jordy:
|
nope
|
|
Aaron:
|
anyone want to tell me what syntax errors I'm making in widgets/polygonWidget_impl{.cc|.hh}?
|
|
Dusk:
|
I have one...
|
|
Jordy:
|
oh, wait yeah... graydon, why are we committing omniidl2 generated headers
|
|
Dusk:
|
Was the mailing list subscribe process fixed?
|
|
Jonas:
|
ahh yes, what modules/namespace names to use?
|
|
Jonas:
|
oops, code issue? :)
|
|
graydon:
|
Dusk: er, not to my knowledge. did you mail joey?
|
|
Dusk:
|
It seems to get confused between berlin-design-request and design-request.
|
|
graydon:
|
Jordy: oh, you're right, none of those should be under source control. overzealous perl script!
|
|
Dusk:
|
Well, I mailed listmaster@berlin-consortium.org 2 or 3 times...
|
|
Jordy:
|
oh
|
|
Jordy:
|
i though twe were committing those
|
|
Jordy:
|
so i made a little thing for registrat to cp the header over :)
|
|
Aaron:
|
and my cvs is still committing to attic.
|
| | Aaron swears at it |
| | Aaron kicks it |
|
graydon:
|
Jordy: this is the thing -- every time you make, they might all be updated. it's hard to tell..
|
|
graydon:
|
hmm
|
| | saganic has left channel #berlin |
|
graydon:
|
no, on second thought they should be under version control
|
|
graydon:
|
that way we can make a berlin-dev package for people without an IDL compiler
|
|
Jordy:
|
but uhm
|
|
graydon:
|
they're enormous though..
|
|
Jordy:
|
don't all ORBs come with an IDL compiler?
|
|
Jonas:
|
graydon: eh? why, they still need to ORB libs, so they _should_ have idl compiler?
|
|
anoq:
|
graydon: can't they just be generated for the release?
|
|
graydon:
|
Jonas: netscape has an orb in it. did you get an IDL compiler with it?
|
|
stefan:
|
graydon: people will need a orb package to compile it anyway, why shouldn't they have an idl compiler too ??
|
|
Jordy:
|
my biggest problem with swapping out ORBs is that, do all ORBs generate the same files? ie nameSK.cc and name.hh?
|
|
Jonas:
|
but that's a Java ORB, no need for omniORB headers for that one!?
|
|
graydon:
|
Jonas: true..
|
|
Jordy:
|
java orb has an idl compiler
|
|
Jordy:
|
it's called idl2java
|
|
Jordy:
|
comes with java 1.2
|
|
Jonas:
|
jordy: yup, with jdk or if you have the dev edition, but not with netscape browser which has the orb
|
|
Dusk:
|
With the java distribution? Interesting...
|
|
graydon:
|
many orbs can reverse-engineer the IDL from the classfile
|
| | Signoff: yves (Hey! Where'd my controlling terminal go?) |
|
Jordy:
|
not to that will matter much, netscape is ripping out their java implementation anyway :)
|
| | Jonas can't wait for DSI/DII in omniOrb - hopefully IMR and IR will follow! |
|
graydon:
|
well, ok, so consensus is that we remove the generated headers from cvs? (i.e. put it back to the way it was, roughly?)
|
|
ts:
|
jodry: there are older versions have one too
|
|
Jonas:
|
jordy: everybody is :)
|
|
Jordy:
|
graydon: yeah, i think so
|
|
Dusk:
|
I thought OmniORB wasn't planning on implementing the Interface Rep. ever....?
|
|
Jordy:
|
generated files shouldn't really be in the repostiroy
|
|
Jordy:
|
just wa big waste of space :0
|
|
Jonas:
|
dusk: I'm _hoping_ for it :) Pretty important if they want DSI/DII, right?
|
|
Jordy:
|
if we want to do it later, we can do it in a tag
|
|
Jordy:
|
for stable branch
|
|
Loren__:
|
Can someone set the /topic so I have some clue if this is what we're taling about.. or just an elaborate digression???
|
|
ts:
|
jordy: netscape put a very fast JIT under the mozilla license
|
|
Dusk:
|
I would think so...just recalling something from their website.
|
|
graydon:
|
also note: the makefiles need a little fixing because the IDL compiler won't make a file and put it in another dir. we have to move the stub headers from /src/libwarsaw to /include/warsaw/foo manually
|
|
Jordy:
|
ts: really? i thought they ripped out their java impl for that OJI interface
|
|
Dusk:
|
Jonas: maybe I read wrong, tho...
|
|
ts:
|
it was being developed about the time of javagator but they scapped it because of "shifting company focus away from java"
|
|
Jordy:
|
graydon: heh, that's what i do in src/libregistrar
|
|
Jordy:
|
little $(CP)
|
| | Loren__ has set the topic: "ORBs... ???" |
| | Loren__ has set the topic: ORBs... ??? |
| | graydon has set the topic: "ORBs... ???" |
| | graydon has set the topic: ORBs... ??? |
| | graydon has set the topic: "berlin meeting: code stuff : new text interfaces" |
| | graydon has set the topic: berlin meeting: code stuff : new text interfaces |
|
Jonas:
|
dusk: a month or so ago, somebody announced the DSI/DII was comming to omniOrb (and the requires intf repo?)
|
|
graydon:
|
anyone read text.idl?
|
|
anoq:
|
nope :(
|
|
Jonas:
|
:(
|
|
graydon:
|
in the head branch, I rewrote text again, including the implementation
|
|
Jordy:
|
not really
|
|
graydon:
|
jeez, nobody likes text!
|
|
anoq:
|
OT: Is people abandoning Java now? Reason?
|
|
Jordy:
|
where is our text implementation coming from? the renderer and what not?
|
|
Jonas:
|
gray: love it :)
|
|
ts:
|
jordy: they did. thats in mozilla already
|
|
graydon:
|
Jordy: rendering from freetype and t1lib, hidden inside libgfont
|
|
Jordy:
|
mmm, i hope someone fixes that antialiasing in freetype
|
|
Jordy:
|
it's still a bit off
|
| | graydon is also very interested in the subpixel font code written by the guy who claims MS stole apple technology with cleartype |
|
Jordy:
|
it supposedly only works on LCDs
|
|
Dusk:
|
graydon: yeah, I saw that too.
|
|
Jordy:
|
because LCD's matrix is made of tricolor pixels
|
|
Loren__:
|
Jordy: at least we don't need to worry about the bas-ackwards font system in X that KDE and GNOME are griping about..
|
|
Jonas:
|
gray: isn't the cleartype tech seriously crippled (copyright wise)?
|
|
graydon:
|
Jordy: notice LCD monitors are becoming more prevalent
|
|
stefan:
|
graydon: a general question: if we use graphic as a shared class, do we need GlyphIndex ? I mean, a Glyph *is* only instanciated once anyway...
|
|
graydon:
|
Jonas: not if this guy is correct
|
|
Jordy:
|
i've noticed, i'm even thinking of buying an LCD monitor, but the quality is far lower
|
|
graydon:
|
stefan: the point of that is to make fonts as lazy as possible, only implementing a glyph when absolutely necessary
|
|
Loren__:
|
Jordy: typically you'll run at lower res on LCD anyway... so this helps make up for it...
|
|
graydon:
|
stefan: also, more importantly, it's because glyph selection routines inside a font only deal with their own internal indicies, so we'd need *another* manager to map from instances -> indicies
|
|
stefan:
|
graydon: isn't that what Fresco does with their base classes ? (that's why the DAG etc.)
|
|
graydon:
|
stefan: or else a glyph would need to have a myIndex addtribute
|
|
stefan:
|
graydon: we would need a way to localize a glyph based on it's attributes within the server
|
|
graydon:
|
stefan: localize?
|
|
graydon:
|
stefan: as in bring-glyph-into-server?
|
|
ts:
|
jordy: you just have to use it on one of the resolutions that fits the ratio of the "pixels"
|
|
graydon:
|
stefan: or as in make-glyph-different-based-on-locale?
|
|
ts:
|
otherwise, it looks like someone resized an image wrong
|
|
stefan:
|
graydon: exactly, instanciate once for a given set of attributes, then only reference it multiple times and share it on the screen
|
|
graydon:
|
stefan: yes, we're doing that. but why instance it at all if it's still flowed off the screen?
|
|
graydon:
|
stefan: an index is just an integer. no constructor, no pointer, nothing. it's smaller than a glyph.
|
|
stefan:
|
graydon: sure, but why not simply use pointers (*_ptr, *_var) ?
|
|
anoq:
|
stefan: CORBA?
|
|
anoq:
|
stefan: It might get heavy...
|
|
graydon:
|
stefan: because they need to point to something. I might not want to construct the glyphs. I might be about to send the whole thing to a printer, or be processing in the background.
|
|
Dusk:
|
Could someone give me a quick one-line definition of a Glyph, as used in Berlin?
|
|
graydon:
|
anoq: locally they are just pointers, he's right.
|
|
anoq:
|
OK :)
|
|
ts:
|
dusk: there is a description on the web page now...
|
|
graydon:
|
Dusk: a "little picture" produced by the text process, representative of one or more characters in a given context.
|
|
stefan:
|
anoq: in Fresco: to find a glyph on the screen, you not only need the glyph instance but the full trail of parent glyphs, that's what makes a 'screen dump of a glyph unique.
|
|
Dusk:
|
graydon: by index, do you sort of mean a "handle"?
|
|
graydon:
|
Dusk: glyphs come from fonts. every glyph in a font has an index number. that's the number i mean.
|
|
Dusk:
|
'k thanks.
|
|
Dusk:
|
Ok, index meaning offset into font array.
|
|
graydon:
|
Dusk: there's no universally agreed upon way of identifying glyphs, so it has to be relative to a given font.
|
|
anoq:
|
then stefan and graydon disagrees an what a glyph is or?
|
|
anoq:
|
s/an/on
|
|
graydon:
|
that's the major change from the last text system -- realized you can't have an array of glyph identifiers :)
|
|
graydon:
|
anoq: i think i might have beaten stefan into calling graphica graphics :)
|
|
graydon:
|
s/graphica/graphics/
|
|
stefan:
|
graydon: hehe
|
|
anoq:
|
This makes more sense... then do we need pointers for graphics?
|
|
Loren__:
|
graydon: one thing I didn't understand about caching glyphs, is if the characters aren't pixel aligned, then what good does caching them do?
|
|
graydon:
|
anoq: yes. and we do have pointers to glyphs when they're instantiated, I'm just arguing in favour of letting a process decide to instantiate after glyphs are completely determined *by index*
|
|
anoq:
|
oooh
|
|
graydon:
|
Loren: there's a few options. You can store multiple cached images at varying pixel offsets
|
|
stefan:
|
sharing graphics makes them flyweight. You don't need to store the full information because you can easily compute it from the known trail (transformation etc.)
|
|
graydon:
|
Loren: or you can cache at subpixel resolution and anti-alias on the fly, which I think we'll do
|
|
anoq:
|
graydon: is that fast enough? :)
|
|
Loren__:
|
graydon: you mean store at sub pixel res in black&white? or grey?
|
| | anoq still has ressource-waste-o-phobia |
|
graydon:
|
Loren: the thing is, anti-aliasing of multiple glyphs in a sequence has interactions, like if 1 glyphs partly overlap in a pixel, it's darker than in either of their single anti-aliased images.
|
|
graydon:
|
Loren: b&w
|
|
graydon:
|
Loren: big bitmaps.
|
|
graydon:
|
Loren: roughly as expensive as small pixmaps
|
|
graydon:
|
Loren: depending on how many grays you were planning on using, and what the subpixel res is
|
|
graydon:
|
DOH. if *2* glyphs partly overlap
|
| | graydon got a new keyboard this week, so is re-learning how to type |
|
Loren__:
|
graydon: I guess as long as we're caching at at least 16x res then b&w is okay...
|
|
graydon:
|
Loren: I doubt that'll be necessary, but we'll make it a parameter of the anti-aliaser.
|
|
Loren__:
|
graydon: you might wanna make caching as grey an option too....
|
|
graydon:
|
Loren: actually, I think we can probably delegate to freetype on this issue, since they do have a finished anti-aliaser
|
|
graydon:
|
Loren: and internally they cache glyphs
|
|
Loren__:
|
graydon: understood... but are we doing the caching, or are they?
|
|
Aaron:
|
gee va is being slow today
|
|
graydon:
|
Loren: I don't think it matters much. if all support libraries to caching, we might as well just use them
|
|
Loren__:
|
okay... then that's fine...
|
|
graydon:
|
Loren: although we are doing a flyweight pattern on the glyph *objects* as well, but that's another issue. still in the name of efficiency :)
|
|
Loren__:
|
flyweight?????
|
|
graydon:
|
Loren: yeah, uh, fancy term for OOP caching basically
|
|
stefan:
|
loren: that means, only put into it what is really needed, everything else can be delivered with method calls
|
|
anoq:
|
graydon: = ref-counting?
|
|
graydon:
|
Loren: you use pointers to the same object in multiple locations, and determine the remainder of its identity via context of use
|
|
Loren__:
|
BTW... are we garenteeing that words are pixel-aligned?
|
|
graydon:
|
anoq: yeah, we'll need refcounting of some sort
|
|
stefan:
|
anoq: sort of, but a flyweight can be used in different contexts, so the context has to be given when methods are called
|
|
Aaron:
|
somehow we have to keep composite transforms workable for non-GL logic....
|
|
anoq:
|
stefan: aha...
|
|
Aaron:
|
like, an input garbler that applies the transformation matrix
|
|
graydon:
|
Loren: memory words or textual words?
|
|
stefan:
|
anoq: and the context here often will mean the transformation matrix to get the graphic to the position you want
|
|
Jordy:
|
i'm staying out of this one, i know little about text
|
|
Dusk:
|
So when you draw the same glyph object into differently-scaled widgets, it'll have to do some recalculations for each draw?
|
|
Loren__:
|
graydon: textual....
|
|
Dusk:
|
...But it's still the same glyph object...?
|
|
graydon:
|
Dusk: yes.
|
|
stefan:
|
dusk: that's the idea
|
|
Loren__:
|
graydon: strings of characters seperated by whitespace...
|
|
Dusk:
|
Any idea where the term "flyweight" came from?
|
|
stefan:
|
dusk: look into the GoF's pattern book
|
|
Dusk:
|
GoF?
|
|
graydon:
|
Loren: fonts have hinting information. it'll be, uh, it'll be a lot of work but probably necessary to convey proper device space under transformations to the font renderer. that gets you alignment along the non-flow axis.
|
|
stefan:
|
dusk: 'gang of four': Vlissides, Gamma et al.
|
|
Jonas:
|
if it's the same glyph object that's scaled what size should the glypsh be in then? I want my times-new-roman in 1200! ?? Did I miss something? will they be rendered on the fly?
|
| | Jonas wonders if anyone read "CORBA design patterns"? |
|
stefan:
|
jonas: I think 'size' is no information of a graphic but on a graphic+context
|
|
graydon:
|
Loren: as far as the flow direction, that's why the new interface processes text in "chunks".. a chunk being a piece the layout system can feel free to adjust by a further subpixel or two if required for pixel alignment.
|
|
Dusk:
|
stefan: is it a book or a URL?
|
|
Loren__:
|
graydon: yeh... but I meant horizonatlly (along the flow axis)... are word positions being sub-pixeled?
|
|
Jonas:
|
stefan: so the glyph contains the outline info and not the rendered image?
|
|
Jordy:
|
you mean corba design patterns jonas?
|
|
stefan:
|
dusk: it was basically a book which is now a CDROM as well
|
|
graydon:
|
Jonas: at a certain resolution the cache will no longer be a valid, I suspect.
|
|
Jonas:
|
jordy: the book title CORBA design patterns
|
|
Jordy:
|
jonas: i was gonna buy it, but it only got 2 1/2 stars on amazon :)
|
|
Jonas:
|
graydon: ok, so we just have to find a golden "medium" for sizes and then re-render if needed?
|
|
stefan:
|
jonas: the glyph contains very little, as a piece of vector graphic, only when you apply a set of parameters you will get something usable
|
|
graydon:
|
Loren: I think that's the best we can do.. start each word on a pixel boundary.
|
|
Jonas:
|
stefan: but what about a bitmap image, can't just seamesly re-size that one?
|
|
Dusk:
|
Jordy: same here...I got CORBA Essentials instead.
|
|
graydon:
|
Jonas: well, like I said I'm hoping the support library is already somewhat smart about that, but it might be that you re-cache the subpixel image for each new size.
|
|
Jordy:
|
i got an order on C++ Programming With Corba
|
|
Jordy:
|
and waiting for Advanced CORBA programming with C++
|
|
stefan:
|
jonas: that depends on how you want the 'pixels' to behave (become rectangles ?)
|
|
Aaron:
|
how do you make xemacs show you what line you're on?
|
|
Loren__:
|
graydon: so in a left-to-right system, a space character is always going to be pixel aligned on the right side?
|
|
stefan:
|
aaron: 'line-number-mode'
|
|
Dusk:
|
mmmmm....books.
|
|
graydon:
|
Loren: something like that, yeah
|
|
Jordy:
|
i really like this C++ book on ANSI C++ i bought, brought me up to speed with current standard practices
|
|
graydon:
|
Loren: at least, I've been told that gives best results.
|
|
Loren__:
|
graydon: is the renderer going to streach the word to copensate?
|
|
graydon:
|
Loren: inter-word spaces are the best place to insert layout hints
|
|
graydon:
|
Loren: no way!
|
|
Loren__:
|
s/copensate/compensate/
|
|
graydon:
|
Loren: it'll stretch the *spaces*
|
|
Dusk:
|
So is a glyph more likely to be a word, a character, an entire sentence, or a single displayed line?
|
|
Loren__:
|
graydon I KNOW it will streach the spaces (at least mostly)... but will there be some play in the word spacing???
|
|
Dusk:
|
Is the renderer aware of formatting, justification, etc.
|
|
stefan:
|
dusk: I'd like it to be everything I want. I imagine a TextKit which creates a Glyph from characters/text etc.
|
|
graydon:
|
Dusk: no, a word is a chunk of glyphs
|
|
stefan:
|
dusk: evidently, text in one single Glyph only makes sense if the text is not going to be changed any more...
|
|
Dusk:
|
Hm, so is a glyph ever more than one character?
|
|
graydon:
|
Loren: like what? there might be kerning pairs and glyph hints, but that's about it, I think
|
|
stefan:
|
graydon: why not allow text to *become* flatened into a single Glyph instance for efficiency ?
|
|
Jordy:
|
if we are using two text rendering engines, don't they both include antialiasing engines? can we remove them and make one big generic antialiasing mech?
|
|
Dusk:
|
So a glyph is analogous to a rubber stamp?
|
|
Jordy:
|
or is this what you are discussing? :)
|
|
anoq:
|
dusk: unless they changed specs again, it's 1 character, but it seems the specs are changing again :)
|
|
graydon:
|
stefan: chunks could be. anything beyond chunks and you'll get subpixel errors accumulating, I think
|
|
Jonas:
|
stefan: how often will you draw the same word on screen? Compared to e.g. 'e'?
|
|
graydon:
|
anoq: no, it's definitely not 1 character!
|
|
graydon:
|
anoq: it can be multiple characters
|
|
Dusk:
|
anoq: Good, then I'm not asking stupid questions. (c:
|
|
stefan:
|
jonas: if a widget label has fixed size, you can equally look at it as a bitmap, so once the size is determined,
|
|
anoq:
|
oops!
|
|
graydon:
|
anoq: ligatures & combining accents
|
|
Aaron:
|
polygonWidget_impl.cc: In function `class cloneable_impl * getPlugin(...)':
|
|
Aaron:
|
polygonWidget_impl.cc:234: cannot allocate an object of type `polygonWidget_impl'
|
|
Aaron:
|
polygonWidget_impl.cc:234: since the following virtual functions are abstract:
|
|
Aaron:
|
polygonWidget_impl.cc:234: void _lc_sk_polygonWidget::pressed(_CORBA_Boolean)
|
|
Aaron:
|
Chalky: you know what that means?
|
|
anoq:
|
oooh! Like ji etc. in english?
|
|
Loren__:
|
brb
|
|
stefan:
|
jonas: I can imagine the list of Glyphs to be put into a single one, this makes a bit of calculation unnecessary
|
|
ts:
|
im on the phone... GRR! im really getting behind
|
|
Chalky:
|
did you implement polygonWidget_impl::pressed()?
|
|
Aaron:
|
yes.
|
|
Jonas:
|
stefan: hmm, you're right
|
|
Aaron:
|
it's virtual
|
|
graydon:
|
anoq: yeah, fi, ae, ffi, etc. but in many languages ligatures are the *majority* of the glyphs
|
|
anoq:
|
Aaron: You need to implement pressed....
|
|
Aaron:
|
anoq: I did
|
|
graydon:
|
Jordy: you could use 1 anti-aliaser, but if they both work the same way (unlikely) it might be wasted effort.
|
|
anoq:
|
graydon: OK, but glyphs are not words... :)
|
|
Jordy:
|
well i just figured there only needs to be one way to antialias text
|
|
graydon:
|
anoq: well, stefan was just mentionning that you could, if you like, allocate "superglyphs" in your cache, which *are* words.
|
|
Jordy:
|
but don't mind me, i don't know much about text :)
|
|
anoq:
|
Aaron: Are you sure the name is correct? the arguments? all types on the arguments?
|
|
graydon:
|
Jordy: would be nice, except that different font formats specify hinting differently, and hinting overrides anti-aliasing.
|
|
Aaron:
|
anoq: I've triple checked it
|
|
Aaron:
|
I actually hav three functions it's complaining about
|
|
Jordy:
|
alright, so we done with text? :)
|
|
anoq:
|
graydon: changing specs - yes :)
|
|
Loren__:
|
I'm back....
|
|
graydon:
|
Jordy: yah.. it's still a ways off.
|
| | graydon has set the topic: "berlin meeting: code stuff : GGI and GLUT" |
| | graydon has set the topic: berlin meeting: code stuff : GGI and GLUT |
|
Dusk:
|
Anyone have a good URL that explains glyphs, so I can research it in my spare time?
|
| | graydon ported berlin to use GLUT. |
|
Aaron:
|
I suggest this:
|
|
Aaron:
|
we leave berlin with gl
|
|
graydon:
|
Dusk: there's a link to microsoft typography and apple typography on the webpage links section
|
|
Aaron:
|
until which time libggi3d is implemented
|
|
Dusk:
|
graydon: thanks.
|
|
Jordy:
|
well GGI actually works now... but i wish they'd release degas
|
|
anoq:
|
Aaron: you remembered it in both interface and implementation? Got the classname and returntypes correct in the impl?
|
|
Jordy:
|
is it my imagination, or has GGI abandoned KGI?
|
|
Aaron:
|
anoq: yes
|
|
Aaron:
|
KGI is still being worked on, but because fb took over some of its scope they've re-done it.
|
|
Jonas:
|
why was the code changed to use GLUT? Just linking with another library changing 5-7 lines into 2, right?
|
|
stefan:
|
dusk: you may look for Fresco, which has nice implementations even for TeX like WYSIWYG editors. The explanations are quite clear
|
|
anoq:
|
Aaron: out of ideas :(
|
|
Aaron:
|
chalky's looking at it ;)
|
|
graydon:
|
Jonas: it's not a particularly complex port, I did it because I was worried GGI was holding us up. magically they then proceeded to stabilize, almost the next day.
|
| | jjanx (mjv3@lucy.cs.waikato.ac.nz) has joined channel #berlin |
|
anoq:
|
Aaron: You didn't forget virutal in multiple inheritance did you?
|
| | graydon chuckles |
|
Aaron:
|
anoq: I don't understand virtual very well.
|
|
Jordy:
|
libggi3d states that it's only low-level 3d primitives.. we need Mesa for 2D as well as 3D and Mesa is high level graphic primitives
|
|
Aaron:
|
anoq: I think I'm putting the keyword in all the wrong places
|
|
Aaron:
|
ok committed. chalky can you take a look?
|
|
Jonas:
|
graydon: ah, ok, then when Xi releases a hardware OGL I can use that one instead :)
|
|
Dusk:
|
OGL?
|
|
graydon:
|
my only remaining issue with ggi is that it doesn't seem to implement poll() in a threadsafe way, but nevermind that.
|
|
Jonas:
|
Dusk: OpenGL
|
|
Aaron:
|
everyone should go read the thread about libggi3d in ggi-develop
|
|
Jordy:
|
virtual function == function defined in a base class made to be redefined by a derived class
|
|
Aaron:
|
libggi2 is in debian 2.1
|
|
Aaron:
|
!find libggi2
|
|
dpkg:
|
Aaron: alas, libggi2 is not in any package :-(
|
|
graydon:
|
ok. nobody has anything GGI-related they need to urgently discuss?
|
|
Aaron:
|
!find libggi2 slink
|
|
Jordy:
|
graydon: not really
|
|
dpkg:
|
Aaron: alas, libggi2 is not in any package :-(
|
|
Aaron:
|
!find libggi2 potato
|
|
Jordy:
|
FBCon actually has working drivers for my video card
|
|
dpkg:
|
Aaron: um, dists/potato/main/binary-i386/libs/libggi2_981216-1.deb
|
|
Aaron:
|
ok, it's in spud then
|
| | graydon has set the topic: "berlin meeting: code stuff : new graphics hierarchy" |
| | graydon has set the topic: berlin meeting: code stuff : new graphics hierarchy |
|
graydon:
|
the big hairy topic!
|
| | Aaron stops dicking with widgets and listens ;) |
|
ts:
|
aww man! i missed a whole section
|
| | Jordy whips out his comb |
|
stefan:
|
graydon: hehe
|
|
Jonas:
|
is it even possible? :)
|
|
anoq:
|
Aaron: If B and C inherits from A and D inherits both B and C, you've got diamond inheritance, and which A will
|
|
Aaron:
|
graydon: why do we need to make ourselves easy to port between APIs when libggi will walk platforms so easy?
|
|
anoq:
|
Aaron: you reference? Then the B and C inheritances need to be virtual so there's just one A
|
|
stefan:
|
graydon: may be we should discuss layout/constraints first, I think the graphics hierarchy depends on it
|
|
graydon:
|
Aaron: merely because it, uh, wasn't.. but nevermind. seems irrelevant
|
|
Jordy:
|
layout constraints
|
| | graydon has set the topic: "berlin meeting: code stuff : new graphics hierarchy : layout" |
| | graydon has set the topic: berlin meeting: code stuff : new graphics hierarchy : layout |
|
graydon:
|
hierarchical topics!
|
|
Jordy:
|
so how do we draw a widget which wants to be 50x50
|
|
Aaron:
|
ok.
|
|
graydon:
|
Jordy: indeed, a deep, zen-like question
|
|
stefan:
|
Well, I have thought about layout as in Fresco and constraints quite a lot recently.
|
|
graydon:
|
stefan: do tell
|
|
stefan:
|
My concerns are with respect to global constraints which don't respect the hierarchy
|
|
Chalky:
|
Aaron: the skeleton has: void pressed (CORBA::Boolean _value) and you have: void pressed( const CORBA::Boolean &p) .. they are not the same
|
|
Aaron:
|
Chalky: urk
|
|
Aaron:
|
Chalky: no idea how to fix that
|
|
Jordy:
|
remove the &
|
|
graydon:
|
stefan: can you not represent the constraint of hierarchical containment as yet another constraint?
|
|
graydon:
|
Jordy: makes no difference
|
|
stefan:
|
The current paradigm which uses local coordinate systems for each graphic fails miserably when you connect graphics across the hierarchy with constraints
|
|
anoq:
|
Aaron: You checked? 8)
|
|
Jordy:
|
remove the const :)
|
|
Aaron:
|
Jordy: no difference
|
|
Jonas:
|
speaking of layout, anyone else tried the Motif XmForm? I think it's way easier than any packing apis
|
|
ts:
|
ACK! i get off the phone and there are a few pages of stuff i've missed
|
|
graydon:
|
stefan: how so?
|
|
stefan:
|
Hmmm, we should only allow non-local constraints in limited cases, and this in designing the interface so.
|
|
ts:
|
my back buffer doesnt even hold it all
|
|
graydon:
|
Jordy: whoops, oh, it *does* make a difference if you're talking about matching the skeleton
|
|
graydon:
|
Aaron: remove the & and the const!
|
|
Jordy:
|
graydon: ok, just making sure i didn't forget some important C++ rule about inheriting classes :)
|
|
Aaron:
|
oh, uhm, ok
|
|
stefan:
|
graydon: if a widget only knows local coordinates, what do you have to base constraints on ?
|
|
ts:
|
until which time libggi3d is implemented
|
|
Jordy:
|
yeah, CORBA in general won't pass by reference for anything but structs
|
|
ts:
|
libggi2d is what we need ;)
|
|
graydon:
|
stefan: well, constraints are based on constraint variables right?
|
|
Aaron:
|
ts: there won't be a mesa for ggi2d/ggi3d until ggi3d is finished
|
|
Jordy:
|
anyhow, what are the options we have for a constraint system
|
|
Jonas:
|
stefan: disallowing non-local contstraints, is that like saying a window can't say to be located in a certain location on screen (unmoveable)?? Or did I misunderstand?
|
|
graydon:
|
stefan: and constraint variables can be changed either by the solver or by the object holding them
|
|
Loren__:
|
What is going to be the difference between libggi3d and OpenGL for GGI?
|
|
Jordy:
|
loren: GL handles high level 2d and 3d graphic primitives
|
|
Jordy:
|
libggi3d handles low level 3d graphic primitives
|
|
Jordy:
|
we want to use high level :)
|
|
stefan:
|
graydon: right, but you have to put them somewhere. Say, the upper y coordinate of a widget is constrained by some non-local constraint.
|
|
Jordy:
|
the higher level, the better.. less network traffic
|
|
graydon:
|
stefan: so, hmm, well they won't work for non-local layout, because they'll be thinking in terms of the wrong coordinates.
|
|
stefan:
|
graydon: what is it's value ? in which coordinate system ? what if I try to rotate just that widget ? what happens ?
|
|
Loren__:
|
Jordy: so OpenGL is just going to fit on top of libggi3d anyway??? right?
|
|
graydon:
|
stefan: but they won't intrinsically be evil, I just think they won't achieve the desired effect
|
|
Jordy:
|
loren: right
|
|
Jordy:
|
Mesa will call GGI to write stuff, libggi, libggi2d and libggi3d whenever they mature
|
| | MenTaLguY (mental@ppp24.bcpl.net) has joined channel #berlin |
|
MenTaLguY:
|
hey.
|
|
anoq:
|
graydon, stefan: In Delphi there are nice conversion functions: localToScreen, screenToLocal
|
|
graydon:
|
hey hey mental
|
|
stefan:
|
graydon: exactly ! And if you look at constraints more in abstract terms, say a pattern or so, you will realize that the 'Requirement' based layout *is* a constraint concept
|
|
Jonas:
|
ehlo mental
|
|
Loren__:
|
Does OpenGL allow for a projection of one 3d world mapped to a surface in another?
|
|
graydon:
|
stefan: what do you call "requirements"?
|
|
Aaron:
|
libggi3d just provides an environment fo a _clean_ GL
|
|
Aaron:
|
and for clean, efficient 2d *and* 3d acceleration
|
|
MenTaLguY:
|
well, there's still a lot of debate with what's happening with libggi3d
|
|
Aaron:
|
YAY!!! it built!!!
|
|
MenTaLguY:
|
the thought now is to do something a little more general-purpose
|
|
Jordy:
|
loren: OpenGL gives you everything you want from a 2d/3d library
|
|
Jordy:
|
:)
|
|
ts:
|
jordy: higher level graphics api doesnt mean less network traffic, it just means slower
|
|
Aaron:
|
MenTaLguY: is james pursuing his proposal for ggi3d?
|
|
stefan:
|
graydon: the InterViews/Fresco way of life, where every Glyph (here: Graphic) fills out a Requirement form.
|
|
MenTaLguY:
|
i.e. not really GL, but a fresh, cleaner API that would be easy to build a GL implementation on top of
|
|
stefan:
|
graydon: this is something in between a constraint and an objective function
|
|
graydon:
|
anoq: that would be useful in many cases, being able to access device space (for hinting, for example)
|
|
Jordy:
|
ts: if a widget has to call, drawline instead of drawbox it does so via CORA over the network, drawbox will obviously cause less network traffic than 50 drawlines
|
|
Jordy:
|
CORA
|
|
Jordy:
|
er CORBA
|
|
Jordy:
|
damn b key
|
|
Jordy:
|
just like drawline is faster than drawpixel
|
|
graydon:
|
Stefan: and the parent transforms the requirements into its local space before turning them into constraints?
|
|
Aaron:
|
Jordy: and in that case, we want to keep as much knowledge about look/feel server-side as we can.
|
|
anoq:
|
What if we let the constraint solver be able to get coords both as local or global coords?
|
|
stefan:
|
graydon: there are a couple of examples where Fresco's layout management can't just do what I want, there is still room for improvement ;-)
|
|
Jonas:
|
out-of-server widgets are evil :) hopefully they can be kept to a minimum!
|
|
Aaron:
|
anoq: it has to. there are some things that simply can't function in a constrained environment
|
|
stefan:
|
graydon: exactly.
|
|
graydon:
|
stefan: anoq has a good point -- accessing device space is useful for a lot of things.
|
|
Jordy:
|
all i know is the packer is going to have a bitch of a time dealing with widgets, can't we steal the Java Swing's packer?
|
|
Jordy:
|
:)
|
|
anoq:
|
Jonas: agree! :)
|
|
Aaron:
|
Jonas: the whole strength of this layout is that we can concievably have widgets from one server displaying on another...
|
|
|