| | 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...
|
|
MenTaLguY:
|
ooh, yeah. the packer is downright awesome.
|
|
Jordy:
|
Swing does basically the same thing right? you can mix and match widgets... so the layout engine has to be able to deal with what we need to do... we jus tneed to copy it
|
|
Jonas:
|
Aaron: and the strength in that? Why not just create a local copy of the widget and multiplex messages?
|
|
MenTaLguY:
|
if it's anything like the AWT packer, it's a reasonably simplistic design, dealing with bounding rectangles
|
|
MenTaLguY:
|
IIRC
|
|
Aaron:
|
I must *disagree*. we should still have the facility to use outprocess widgets
|
|
Jordy:
|
jonas: can't create a local copy if remote box is a diff platform/architecture and the widget is native
|
|
Jordy:
|
:)
|
|
MenTaLguY:
|
oh, we get that facility through CORBA, Aaron.
|
|
Aaron:
|
Jonas: well, I can see the point in that.
|
|
MenTaLguY:
|
it'd actually be sort of hard to remove it.
|
|
Jonas:
|
Aaron: the only time I can see out-of-server as necessary is copyright or binary-incompatibility
|
|
stefan:
|
graydon: if local transformations are just shifts (as in X), there is no problem with global constraints. But if (and that would be really nice) we allow for arbitrary linear transformations, we will fail
|
|
MenTaLguY:
|
s/copyright/licensing/
|
|
ts:
|
jonas: low level drawing is going to be done on the server side anyway
|
|
ts:
|
no matter what
|
|
stefan:
|
graydon: this is not a technical issue, it is a conceptual one !
|
|
Loren__:
|
The probelm with widget running on one machine displaying on another is if there is network trouble....
|
|
Jordy:
|
no way jonas, what if you have a server which is 3000x more powerful than your wimpy workstation and you have a heavily math oriented widget, it should do *ALL* of it's stuff on the remote server, not your local box
|
|
ts:
|
s/jonas/jordy/
|
|
Jonas:
|
ts: depends on who does the drawing and where (directly in widgets as now or via a CORBA exported drawing API AKA canvases)
|
|
graydon:
|
stefan: umm, not necessarily. if the parent can instantiate a linear combination of variables into a constraint equation, I think you'll be ok. qoca can do quadratics.
|
|
Jordy:
|
it's too difficult handling two conversations at once
|
|
Jonas:
|
jordy: case number 3 :)
|
|
ts:
|
jonas: yes... in any case, noone should have to care what drawing api the server uses
|
|
anoq:
|
we should have out-of-server widgets, of course... but a minimum amount is preferable :)
|
|
Loren__:
|
Jordy: I think there should be some CORE pieces of the widget on the server... with most of the math on the remote host...
|
|
ts:
|
s/jonas/jordy/
|
|
stefan:
|
graydon: but what would be the meaning of a constraint which crosses arbitrary transformations ?
|
|
ts:
|
again
|
|
Aaron:
|
anoq: keep in mind that sometimes transparently using non-free code would be an extreme benefit. and would convince companies to write widgets for berlin for their proprietary datatypes
|
|
Jonas:
|
ts: but creating a uniform drawing API is _pretty_ difficult :)
|
|
graydon:
|
stefan: none whatsoever. they're meaningless.
|
|
graydon:
|
stefan: but if they *don't* cross a transformation, they're fine
|
|
stefan:
|
graydon: exactly ! And that's why I'd like to only allow meaningful constraints
|
|
Aaron:
|
graydon: then where does that poot composite transforms like rotate, etc
|
|
ts:
|
jonas: not if its high level enough... its like the functions of GTK and GDK
|
|
anoq:
|
Aaron: True, all true, agree etc. :)
|
|
anoq:
|
Aaron: but a minimum :)
|
|
Aaron:
|
anoq: of course ;)
|
|
ts:
|
GTK does drawing, but with special "widgets"
|
|
ts:
|
with GDK you can draw directly to the context
|
|
graydon:
|
stefan: but why not allow *any* constraints, and just tell the developer: "oh, btw, constraints won't work at all if you cross a transformation"
|
|
stefan:
|
graydon: I discussed with my girl friend who is a graphics designer: she never encountered a situation where
|
|
stefan:
|
graydon: non-local constraints where necessary
|
|
stefan:
|
graydon: it may be nice from a mathematical point to be able to do it but from a UI point of view I think it's useless
|
|
ts:
|
jonas: thats why gtk is portable
|
|
graydon:
|
stefan: why add an unnecessary limitation?
|
|
Jordy:
|
why add an unnecessary feature? :)
|
|
graydon:
|
Jordy: because it's easier
|
|
stefan:
|
graydon: because may be a programmer can't necessarily know where a transformation is applied (embedding etc.)
|
|
anoq:
|
graydon, stefan: the global coord option should be a simple conversion - yes?
|
|
MenTaLguY:
|
what about constraints across scaling transformations?
|
|
MenTaLguY:
|
(specifically)?
|
|
Aaron:
|
scaling/rotation will be *very* important
|
|
MenTaLguY:
|
they make sense, but I suppose it's not actually that easy to separate them from arbitrary transformations for our purposes.
|
|
Loren__:
|
I seriously don't think anyone can give me a widget idea that we don't want at least part of to run on the server...
|
|
MenTaLguY:
|
too bad we can't just assume something like MOSIX to take care of the load balancing for us.
|
|
graydon:
|
Loren: I'm gonna have to write a SHM widget just to kill this debate :)
|
|
ts:
|
jordy: most like the the case will not be that the box where the berlin display server is 3000x more powerful, but the other way around. that way you have things like "application servers" etc and a display server on every desktop
|
|
Loren__:
|
graydon: SHM???
|
|
Loren__:
|
Oh... sharewd mem
|
|
stefan:
|
graydon: I read a thesis work on constraints yesterday and the guy showed how a simple data plot could be managed with constraints
|
|
graydon:
|
anoq: not exactly simple. there really is no such thing as global coords in GL.
|
|
Aaron:
|
Loren__: some datatypes that carry lots of logic around with them won't suffer such a huge consequence of being outprocess
|
|
graydon:
|
anoq: at least, not in berlin, since the terminal itself can be embedded
|
|
stefan:
|
graydon: every point was connected to the axis through constraints so whenever the user moves the axes, the points move too.
|
|
Jordy:
|
ts: what about network computers?
|
|
Jordy:
|
i feel network computer would be an ideal place for the distributed nature of berlin
|
|
ts:
|
jordy: thats the same thing
|
|
Jordy:
|
you place the display server on the NC, you ut the widgets on your master server
|
|
stefan:
|
graydon: it is this kind of use which may be cute to see constraints in action but which is ridiculous in terms of efficiency.
|
|
anoq:
|
graydon: accumulated inverse transformations :)
|
|
stefan:
|
graydon: everything at it's place.
|
|
Jonas:
|
ts: have the math app run on the 3000x server and use the widget server-side api?
|
|
graydon:
|
stefan: sure, of course. I keep thinking about the unidraw example though
|
|
MenTaLguY:
|
need we have separate APIs for client-side and server-side? I think not... this IS CORBA we're talking about here...
|
|
Loren__:
|
graydon: what I'm saying is assume that you have a widget on one machine and a server on another... if someone trips over the network cable, you want the widget to be smart enough to at least indicate that there is a problem....
|
|
Jordy:
|
i personally would rather have 4 cheap NC's in my house and one server than 5 of these workstations I have :)
|
|
graydon:
|
stefan: I have 1 boxes and 1 line between them. I want the line to go "between" their 2 center-points, but I want it to only "touch" their edges
|
|
stefan:
|
graydon: unidraw is a great example *in favor* of constraints.
|
|
Jordy:
|
graydon wants to make a barbel
|
|
MenTaLguY:
|
s/1 box/2 box/
|
|
stefan:
|
graydon: and that because within an editor constraints play a different role as in a UI.
|
|
ts:
|
jonas: yes
|
|
ts:
|
like X Terminals
|
|
stefan:
|
graydon: UIs are basically simple, hierarchical, there will a much simpler protocol do.
|
|
graydon:
|
Loren: the widget will (in general) be removed
|
|
Jonas:
|
ts: then there would be no need for the widgets to run in 3000x adress space
|
|
ts:
|
except MUCH more elegant
|
|
Jordy:
|
+--+ +--+
|
|
Jordy:
|
| |--| |
|
|
Jordy:
|
+--+ +--+
|
|
Jordy:
|
like that graydon?
|
|
ts:
|
jonas: i wasnt making the case for it..
|
|
stefan:
|
graydon: that's why I like more Fresco's idea to delegate the layout management to the individual composite graphics
|
|
Loren__:
|
graydon: why... what if the network connection get's re-established?
|
|
Jonas:
|
ts: that's the point - Berlin doesn't use graphics API, but widget apis
|
|
MenTaLguY:
|
I was actually picturing something like:
|
|
graydon:
|
Jordy: yeah, only when you move them the lines stay connected.
|
|
MenTaLguY:
|
+--+\ +--+
|
|
MenTaLguY:
|
| | \ | |
|
|
MenTaLguY:
|
+--+ \+--+
|
|
Loren__:
|
why not have a small piece of the widget on the server smart enough to handle such situations???
|
|
Jordy:
|
diagonal
|
|
graydon:
|
Loren: if the sessionmanager notices the app is dead (unreachable) it'll reclaim all the objects.
|
|
MenTaLguY:
|
where it would intersect only with the boxes at their corners
|
|
ts:
|
jonas: the server could have as low level drawing as it wants... the API takes care of that
|
|
MenTaLguY:
|
I was picturing this with a mathematical (infinite) line
|
|
Aaron:
|
Loren__: because if you have 3000 machines then you need some type of migration device for that portion.
|
|
Jordy:
|
well technically your line is a rectangular deal anyway... it's just three boxes
|
|
stefan:
|
graydon: so an editor is basically a composite graphic where child graphics can be anything the editor was designed to serve.
|
|
graydon:
|
stefan: fine, I still think the constraint system should be *generally* available, not *just* embedded in 1 layout solution
|
|
stefan:
|
graydon: and in this context, I very much like the constraint idea
|
|
Loren__:
|
Aaron: what??????
|
|
Jonas:
|
ts: but using remote low-level drawing we would have accuired not much more than X. Having the in-server widget do all the "funky" stuff based on one (or a couple) of calls instead of loads of BDraw..()
|
|
Aaron:
|
Loren__: you're saying that if you have a widget, it should be in two parts: one remote, one local
|
|
Aaron:
|
Loren__: if you have 3000 machines, you're stuck with copying files to each, and you lose the benefits of CORBA right there.
|
|
Jonas:
|
ts: in my current perception of the Berlin philosophy all apps should be BApp (derived from reactor) and primarily implement functionality via commands
|
|
MenTaLguY:
|
Actually, I think what we really want to do is separate widgets into a number of components -- how many would depend on the widget implementation
|
|
Jordy:
|
jonas: exactly
|
|
stefan:
|
graydon: then, imagine each graphics in terms of six variables: four for the bounding box and two for the origin (for alignment).
|
|
Jordy:
|
anyway, what's this about new graphics hiearchy
|
|
MenTaLguY:
|
some would be smaller and less demanding than others, and have different migration requirements
|
|
stefan:
|
graydon: those are the variables which should be subject to constraints, right ?
|
|
ts:
|
Jonas: sounds like BeOS
|
|
Loren__:
|
Aaron: no... I'm saying that if part of it should/has to be remote... then a super-lightweight fasade widget should still sit on the server to handle adverse network conditions and such...
|
|
graydon:
|
Jonas: or alternatively they can just present C function pointers and hook *them* up to a server-side reactor
|
|
MenTaLguY:
|
Loren__: I think we should generalize this more than that
|
|
Aaron:
|
Loren__: ah
|
|
Jonas:
|
Jordy: to allow out-of-process wd
|
|
Jonas:
|
Jordy: to allow out-of-process widgets
|
|
stefan:
|
graydon: it will be a lot of computing cost to make them all views of the real variables which are stored within a constraint solver.
|
|
graydon:
|
stefan: well, if it's a flow object it needs bearing and advance as well
|
|
Loren__:
|
brb
|
|
Jordy:
|
put it this way, a berlin installation should not need (but may) include every corba object it needs (including widgets)... if it exists somewhere else on the network, it is used
|
|
stefan:
|
graydon: you mean flow object as in TeX ?
|
|
Jonas:
|
graydon: but when would I want that, besides creating the first "hello world". C ptrs are easier in the beginning but the splitting into commands keeps the functionality very clean - and should allow for command reuser
|
|
Jonas:
|
Jordy: yup
|
|
Jordy:
|
i don't imagine any sort of wiget copying... there may be a setting for that... but it shouldn't be done without implicitly telling the server to do so
|
|
graydon:
|
Jonas: you'd want it if your application is written in terms or C Function pointers (in conventional X toolkit, callbacks)
|
|
stefan:
|
graydon: that would be a quite specialized layout manager being able to do this, I doubt that it makes much sense to do *every* layout that way.
|
|
anoq:
|
Confession: Earlier on the Berlin-list when I talked about constraint, some of what I meant was automatical layout generation...
|
|
graydon:
|
stefan: agreed. all I'm saying is that constraints are a useful service in layout, widgets, editors, probably a lot of things. Why not make the constraint solver a general service rather than a specialized component.
|
|
anoq:
|
Should we have automatical layout generation?
|
|
MenTaLguY:
|
./configure --enable-maintainer-mode && make && { sync ; make install } && echo -e '\a\a\a'
|
|
MenTaLguY:
|
... whoops.
|
|
graydon:
|
anoq: what does that mean?
|
|
stefan:
|
graydon: because it makes other parts of the interface unclear.
|
|
stefan:
|
graydon: I know this is a subjective view but I find the Fresco interface *very* clear and consistent
|
|
anoq:
|
Ehm, that you just describe _which_ widgets you want, and how they are grouped. The server will make a suggested layout
|
|
MenTaLguY:
|
I think he means having the layout loosely described, and then have the actual layout computed on-they-fly according to what will fit onscreen within the other constraints
|
|
stefan:
|
graydon: introducing the possibility to global constraints would destroy that
|
|
Loren__:
|
I'm back...
|
|
graydon:
|
stefan: I disagree, I think it makes it extensible. my biggest problem with fresco is that it makes too many concretizations about how things have to be.
|
|
Aaron:
|
what about ok, um, what's the difference between a 'local', 'remote', or 'global' constraint?
|
|
Dusk:
|
anoq: So if you rezised your app window, that group of checkboxes may shift to the other corner...?
|
|
graydon:
|
Aaron: merely which coordinate space it's relative to
|
|
anoq:
|
dusk: No, it's just for creation of GUIs
|
|
Aaron:
|
ok.
|
|
stefan:
|
garydon: not to speek of the drawbacks if you really make a subject/view separation twice for each coordinate (which you would have to to allow users to hook constraints in)
|
|
Aaron:
|
so we're talking about transformations on coordinate spaces....
|
|
Dusk:
|
anoq: Oh, so once you compile and distribute your app, the layout is constant?
|
|
anoq:
|
Aaron: yes, by local and global constraints, I mean coordinate-wise
|
|
anoq:
|
dusk: but modifiable :)
|
|
stefan:
|
graydon: well, in Fresco, basically everything is defined in terms of springs (they call it Glue), we should call it an objective function)
|
|
anoq:
|
dusk: Autolayout should just be an option
|
|
graydon:
|
stefan: no, start with nothing using constraint variables, and let individual widgets or composites create/derive their own for the coords they are interested in having subject to constraints
|
|
stefan:
|
graydon: sure, if you look for completeness, there are other ways which you may not want to hinder,
|
|
Dusk:
|
anoq: Hmmm, so is autolayout runtime or compiletime?
|
|
graydon:
|
stefan: yeah, I really like springs. I think we should use them.. they're a good encapsulation of the common use of a constraint
|
|
anoq:
|
dusk: runtime, at the time a window/application is opened
|
|
stefan:
|
graydon: but I think that 'locality' is an important point, once you give it up, you end up in a huge mess
|
|
Dusk:
|
Define 'locality'
|
| | Jordy thinks we should remove exact positioning from berlin |
|
Jordy:
|
:)
|
|
ts:
|
i dont see the need for networked widgets... X has this feature and hardly anyone uses it unless they have a massive network and they need something to fill it up with
|
|
MenTaLguY:
|
unfortunately, I think game designers would beat us over the head for that, Jordy.
|
|
graydon:
|
stefan: how 'bout this -- the spring creation mechanism is at the level of a single composite. i.e. the composite is a factory for springs within itself, and they can only be attached to objects at the local level of the composite.
|
|
Jordy:
|
mental: well just for widgets
|
|
MenTaLguY:
|
even for those.
|
|
ts:
|
jordy: *BZZT* ;)
|
|
graydon:
|
stefan: that encapsulates the most common use, and makes it easy, but the constraint solver is still available elesewhere
|
|
MenTaLguY:
|
a lot of games that use GUI widgets, try to lay them out in specific patterns
|
|
anoq:
|
Jordy: It should be optional, but not recommended :)
|
|
Jordy:
|
damnit jim, if we enforce relative positioning, think how much heartache we could save
|
|
stefan:
|
dusk: to bind things together (with respect to layout) on the same level in the hierarchy, only children of the same parent can be constrained
|
|
Loren__:
|
ts: what? since when has X supported widgets at all... widgets are a Toolkit thing...
|
|
Dusk:
|
How about springs for top-level widgets, e.g. for window management?
|
|
Aaron:
|
so, um, each composite has its own coordinates.... (bbox, whatever else) -- functions that draw are relative to the composite's interpretation which is always completely unmolested.... but, when the server recieves drawing calls, they have been mangled by the transformations applied to the composite?
|
|
Jonas:
|
ts: what if you have a commercial widget for x86 but running app on alpha?
|
|
ts:
|
loren: gtk does drawing to gdk, which is a layer on top of xlib.
|
|
Loren__:
|
ts: right... and?
|
|
MenTaLguY:
|
I would like to see exact positioning depreciated, but it is still _occasionally_ required.
|
|
ts:
|
loren: the drawing is all done over the network
|
|
Aaron:
|
s: so why don't we just make an xlib-> berlin wrapper? everything would port instantly.
|
|
Jordy:
|
x's remote newtork layer isn't exactly fast :)
|
|
Loren__:
|
ts: right? and?
|
|
ts:
|
jordy: its MUCH faster than CORBA
|
|
anoq:
|
graydon, stefan: springs are nice, something similar exists in Swing and Delphi
|
|
Jordy:
|
ts: you must be kidding, X sends pixels
|
|
Jordy:
|
:)
|
|
ts:
|
jordy: in a relative sense
|
|
stefan:
|
anoq: springs are the basic concept in TeX (and so in Fresco):
|
|
anoq:
|
Mentalguy: yes :)
|
|
graydon:
|
ts: but it's a different level of abstraction.
|
|
Loren__:
|
Jordy: only when you're talking pixmaps... etc..
|
|
Aaron:
|
ts: if you send somewhat intelligent calls over CORBA, it's capable of being faster.
|
|
graydon:
|
stefan: would what I just mentionned be satisfactory?
|
|
Jonas:
|
Jordy: what? XDrawLine() et. al. are for what then? Or were you just joking?
|
|
Jordy:
|
jonas: kidding
|
|
ts:
|
graydon: i was making the point that asking to support networked widgets in berlin is rediculous unless they are eventually downloaded to the server machine
|
|
stefan:
|
anoq: if you tile things together and you are given a total width, you divide the streching in portions
|
|
Loren__:
|
Jordy: typically you draw rectangles, ellipses... etc.
|
|
Jonas:
|
Aaron: Exactly, using the in-server widget api instead of drawing over network
|
|
anoq:
|
stefan: springs are not always good
|
|
stefan:
|
anoq: depending on the stretching factor of each part.
|
| | Jordy thinks you guys need to stop arguing about things we've already decided on :) |
|
Aaron:
|
Jonas: and there you have the pluggable 'look' which all widgets will end up using.
|
| | graydon ts: it's rediculous until you need to do it. then you need to do it, so it's real. it'll be slow, but slow is better than nonexistent. it'd be a complete misappllication of berlin, but so what? |
|
anoq:
|
Jordy: X sends lines etc. and is fast for just this
|
|
Loren__:
|
ts: why don't you define "networked widgets" so that we're all talking the same language....
|
|
MenTaLguY:
|
oh, and xlib wouldn't fix everything. keep in mind that GTK and a few other toolkits aren't Xlib-based either.
|
|
ts:
|
aaron: thats my point. by you arent making "intelligent" calls with networked widgets
|
|
Jonas:
|
Aaron: not all. Each widget implements itself
|
|
anoq:
|
jordy: OK, kidding :)
|
|
Aaron:
|
Jonas: well, most should anyway.
|
| | jjanx has left channel #berlin |
|
Jonas:
|
Aaron: hopefully :)
|
|
ts:
|
graydon: im just saying, certain features can be useful in extreme cases, but trying to support everything is like asking for failure
|
| | graydon stefan: are we done with layout & constraints? |
|
Jordy:
|
yes
|
|
Jordy:
|
please
|
|
Loren__:
|
ts: please define "networked widgets"...
|
|
graydon:
|
ts: yes. it's a bizarre case I wouldn't expect to see often.
|
|
ts:
|
loren: any widget that doesnt live on the server
|
|
stefan:
|
graydon: may be we should continue this discussion elsewhere (via mail to get more reason into the arguments ;-)
|
|
Aaron:
|
Jonas: if the display server won't take any drawing calls besides what is in the pluggable API, or the SHM widget, then a widget can't unless it uses SHM which would be extremely slow in a remote implementation
|
|
graydon:
|
stefan: ok
|
| | 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:
|
up a level
|
|
Loren__:
|
ts: Ok... THAT's where you threw me... X uses ONLY networked widgets then...
|
|
Jonas:
|
Aaron: what? I don't understand?
|
|
ts:
|
graydon: even then, i would like to see enabling a VM to be able to send even a small amount of code to the server instead of trying to draw ANYTHING over the network using CORBA
|
|
Loren__:
|
ts: that's one of the big problems with it...
|
|
stefan:
|
I'm in favor of a Fresco like hierarchy:
|
|
Aaron:
|
Jonas: somehow you have to call a draw method on the server....
|
|
Aaron:
|
Jonas: you define a set of calls the server exports...
|
|
Jordy:
|
new graphics hierachy
|
|
Jordy:
|
ok
|
|
Jordy:
|
what's new about it gray
|
|
ts:
|
loren: which is why i think its rediculous to have it in berlin
|
|
graydon:
|
ts: yes, I agree. such will probably be done.
|
|
Loren__:
|
ts: we'll talk about the VM later...
|
|
stefan:
|
in the libberlin (or any other basic directory) the basic implementations to support the protocols
|
|
Jonas:
|
Aaron: that's what the new graphics hierarchy is supposed to define, but usually that will be in-process calls
|
|
Aaron:
|
Jonas: exactly
|
|
stefan:
|
then one subdirectory for each specialized 'Kit'
|
|
graydon:
|
what's new is there *is* no graphics hierarchy yet. we need one. stefan was talking like this is what he wanted to work on.
|
|
Jordy:
|
oh :)
|
|
Aaron:
|
Jonas: that's in the server
|
|
stefan:
|
So we have GraphicImpl in libBerlin
|
|
Jordy:
|
well let's start with the basics
|
|
Loren__:
|
ts: I think we should support some variation on it, but some core functionality widget should sit AROUND it on the server end in those rare cases...
|
|
Jonas:
|
Aaron: but what was the talk about SHM widgets? Should be no difference with the transport of requests
|
|
stefan:
|
All layout containers go into the LayoutKit directory, the LayoutKit factory builds Graphic instances
|
|
graydon:
|
stefan: yes, but what sort of graphic objects do you have in mind? basic geometrics? paths? pens?
|
|
Aaron:
|
Jonas: anything that didn't use the exported graphics calls would have to be SHM which would make it real slow.
|
|
stefan:
|
All Widgets go into..., the WidgetKit exports Widget instances which are derived from Reactor and Graphic
|
|
Jonas:
|
If we want widget location to be transparent, don't we need every widget to contain a "canvas" located on the server, in contrast to the current widget is a graphics/canvas?
|
|
Jonas:
|
stefan: what would widgetKit do? Aren't kits like factories (useless in our widget-scheme, right?)
|
|
graydon:
|
stefan: I tend to think people will like to experiment with loading some widgets as separate objects, but go on.
|
|
stefan:
|
graydon: almost the Glyph class from Fresco, it defines the protocol for layout negotiation (or constraints, to be discussed)
|
|
stefan:
|
graydon: it contains the stuff to calculate visibility (detect whether a given position is inside etc.)
|
|
graydon:
|
stefan: yes, sure, but you just want to mirror the whole fresco::glyph::* tree?
|
|
Jordy:
|
i'm not familiar with fresco
|
|
Jordy:
|
someone draw me a picture of the graphic hiearchy :)
|
|
stefan:
|
graydon: hmmm, the basic design at least. There are things to be changed, others totally to be reimplemented
|
|
Jordy:
|
i wish irc had a whiteboard capability
|
| | jjanx (mjv3@lucy.cs.waikato.ac.nz) has joined channel #berlin |
|
Aaron:
|
so how do you deal with separate implementations?
|
|
graydon:
|
jordy: it does
|
|
stefan:
|
graydon: I like for example the encapsulation of the DrawingKit and I think someone could use the interface to put openGL stuff into it
|
|
stefan:
|
graydon: I very much like the subject/view separation so I would want to learn a lot from the WidgetKit as well
|
|
Aaron:
|
if you want to use a different implementation of widget-x-blah, you have to replace your entire widgetKit?
|
|
Aaron:
|
not that that's bad
|
|
graydon:
|
stefan: yes, this was something we discussed, I'm still assuming you want to make a drawable type to encapsulate / substitute for displayLists
|
|
graydon:
|
Aaron: yeah, I don't like the sound of that particularly.
|
|
Aaron:
|
I just came upon another thing we have to discuss
|
|
graydon:
|
Aaron: I think the widgetKit's factory methods should delegate to the genericfactory, so as a user can replace things file-by-file
|
|
stefan:
|
Aaron: hmmm, no, noone hinders you to add your own stuff, it's just a default setting and I imagine for example different WidgetKit implementations for Motif look, Open look etc.
|
|
graydon:
|
Aaron: and that thing-to-discuss is?
|
|
MenTaLguY:
|
Hrm.?
|
|
MenTaLguY:
|
306 We'll miss you
|
|
Aaron:
|
stefan: ok. so you can still put something in lib/plugins/xxx.so and have it override what's in widgetkit?
|
| | MenTaLguY returns |
|
Jordy:
|
i personally think all widgets should go in their own file... otherwise we get into this toolkit bullshit
|
|
Jonas:
|
stefan: I think that's better done with the current prototype approach (I can have any combination I like).
|
|
graydon:
|
Jordy: agreed. if it matches the interface, I think it should be swappable.
|
|
Jordy:
|
where you have 80 toolkits which only want to replace 1 widget and duplicate the rest
|
|
stefan:
|
Aaron: not override, let's WidgetKit base on something like graydon says...
|
|
graydon:
|
Jonas: no prototypes anymore :)
|
|
graydon:
|
Jonas: they be gone.
|
|
jjanx:
|
(trying to compile for the first time): What is this when configuring: 1 = original, 2 = warsaw.cc, 3 = grouped" ?
|
|
Aaron:
|
jjanx: are you using head or stable?
|
|
Jordy:
|
head wont' compile
|
|
Jonas:
|
stefan: but what happens to the widgetKit when a new widget is introduced? Kit are like factories right?
|
|
Aaron:
|
oh, ignore 'configure'
|
|
Jordy:
|
graydon broke head :)
|
|
graydon:
|
Jonas: they were causing extreme confusion with the lifeCycle object.
|
|
Aaron:
|
just do make depend; make
|
|
graydon:
|
Jordy: head been broken for a while
|
|
jjanx:
|
aaron: no idea. I just did a cvs co berlin-tree.
|
|
Aaron:
|
jjanx: cvs co -rberlin_0_0_1 berlin-tree
|
|
Loren__:
|
Jordy: we might want a core collection of widgiets in one basic file, but that's of course optional...
|
|
Jonas:
|
graydon: so we're forced to use factories for widget "retrival" now?
|
|
Jordy:
|
graydon: i wouldn't know, i jus tplay with registrar and let you people do your thing until all the graphic apis is set in stone :)
|
|
stefan:
|
graydon, jordy: imagine two widgets which are only arrangements of some common graphics objects, just slightly different. Why putting them into extra plugins ?
|
|
graydon:
|
jjanx: delete that tree, do cvs co -rberlin_0_0_1 berlin-tree
|
|
Aaron:
|
what I propose is this: make a server side drawing_kit.so (runtime swappable/polymorphic) that implements all of berlin's drawing calls.
|
|
Jordy:
|
stefan: inherit both from a base widget ;)
|
|
Aaron:
|
this being the 'look'
|
|
graydon:
|
stefan: why not?
|
|
jjanx:
|
thanks.
|
|
graydon:
|
stefan: they can share code if necessary
|
|
Jonas:
|
Aaron: how can a drawline implement look?
|
|
Aaron:
|
then have widgets just use that set of functions (invoke them on the server), but themselves export a common set of functions that are required to do standard things (consistent behavior) so widgets are swappable
|
|
stefan:
|
jonas: yes, a look is higher level then a drawing command
|
|
graydon:
|
Aaron: that's what we got
|
|
Jordy:
|
what we want to do is minimize the amount of widgets which a person has to make to create a different look... like i should be able to create a macos scrollbar and use it in my windows98 window with my nextstep menubar
|
|
Aaron:
|
Jonas: 'drawbox', 'drawbeveledbox' etc
|
|
Jordy:
|
er toolbar
|
|
anoq:
|
wrt, swappable widgets, read the AbstractGUI document I wrote... :)
|
|
stefan:
|
aaron: as I see it every 'widget' is just the view of some user data subject, so widget==look (mostly)
|
|
Aaron:
|
Jonas: we have to go a level higher on the abstraction tree than 'drawline' becuase calls like that will bog down the communications layer (CORBA)
|
|
Jonas:
|
Aaron: but if you want _look_ to be in drawingKit then widgetKit::pushButton would have to use drawingKit::drawPushButton()
|
|
graydon:
|
stefan: no, a widget is more a controller that produces a look when it's told to.
|
|
Aaron:
|
Jonas:I see your point
|
|
Aaron:
|
Jonas: but the more knowledge that is in-server, the less bandwidth overhead there is
|
|
graydon:
|
stefan: a widget's primary role is to dispatch commands
|
|
Jordy:
|
and respond to events
|
|
Jonas:
|
Aaron: that's why widgets are very much prefered to be in-process - if not, you're asking for slow system
|
|
stefan:
|
graydon: you are right, a widget is both, the controler *and* the view
|
|
Aaron:
|
pushbutton could just be 'drawBeveledBox' and 'drawInvertedBeveledBox' which could also be used for other things
|
|
Aaron:
|
'button' is just one implementation where that would be almost too easy to implement
|
|
Dusk:
|
So the question is, who intercepts the render?
|
|
Aaron:
|
Dusk: the server *has* to
|
|
Jonas:
|
Aaron: the widgetKit (or each widget as I see it) must define it's own look according to the DrawingKit API
|
|
graydon:
|
stefan: I guess my point is that I really think the view should be "produced" as a separate object, by the controller. rendering takes place regardless of what a widget is upto at a given instant
|
|
stefan:
|
graydon: what I tried to say was that I like how InterViews/Fresco do it and I don't see any problems how to make widget instantiation independant from factories
|
|
Aaron:
|
Jonas: ok, so widgetKit is in the server process right?
|
|
Dusk:
|
Aaron: right, but how is it connected to the widget?
|
|
stefan:
|
graydon: yeah, the 'State' pattern, right ?
|
|
Aaron:
|
the 'widget' is the corba object instance that intercepts and forwards events to clients
|
|
Dusk:
|
Aaron: In other words, is it possible to swap out a look & feel without actually swapping out the widgets?
|
|
Jonas:
|
Aaron: widgetKit (which I think I'll have to adjust to :) is a factory for widgets. Widgets should preferably be in-process
|
|
Aaron:
|
the rendering process is completely different
|
|
Jonas:
|
Aaron: widgets responds to messages by executing one or more commands
|
|
graydon:
|
stefan: except the state it exports should be interpretable by the drawingKit. The drawingKit should just be a drawable "interpreter".
|
|
Loren__:
|
why does this sound very "back to the basics" wasn't all this finalized 6months ago?
|
|
Jordy:
|
yeah it was
|
|
Aaron:
|
Jonas: so, ok
|
|
Aaron:
|
i have a suggestion
|
|
graydon:
|
Loren: almost, only the openGL displayList apprach was unsatisfactory.
|
|
Aaron:
|
someone take control of this thing and make us stay on track ;)
|
|
Jordy:
|
we were talking about the graphics hiearchy, personally i think the graphic hiearchy should just be a little higher abstraction of opengl
|
|
anoq:
|
Loren, Jordy: Nobody wrote it down :)
|
|
stefan:
|
graydon: I see this State (Look) instance more as a holder of a 'Renderer' object which (much as a displayList) executes a list of drawing commands *on* the DrawingKit
|
|
MenTaLguY:
|
well, I have to go.
|
|
graydon:
|
Jordy: I agree. the graphics hierarchy should be in terms of objects most programmers want to write. *not* in terms of verticies, floating point color values, and displaylists
|
|
stefan:
|
graydon: so it is not the DrawingKit which knows about Looks, it is a special class, such as Button::Look (or so)
|
|
MenTaLguY:
|
not sure I actually contributed that much.
|
|
MenTaLguY:
|
oh well.
|
|
anoq:
|
Bye, mental!
|
|
MenTaLguY:
|
bye folks.
|
|
graydon:
|
stefan: a slight inversion of logic, but our views are the same.
|
|
Loren__:
|
bye
|
|
Jordy:
|
graydon: exactly
|
|
graydon:
|
see ya
|
| | Signoff: MenTaLguY (ircII EPIC4pre2 -- Accept no limitations) |
|
jjanx:
|
cvs co -rberlin_0_0_1 berlin-tree.. someone left a clock*.o in cvs, and it didn't compile.
|
|
Jonas:
|
stefan, graydon: now you want to split the widgets logic and the widgets appearence into two classes? Why?
|
|
Aaron:
|
oops
|
|
Aaron:
|
lemme fix
|
|
Jordy:
|
someone cvs remove clock*.o
|
|
Jordy:
|
:)
|
|
Dusk:
|
Jonas: that's what I was wondering, too...
|
|
stefan:
|
Jonas: to let the programmer decide which widget to use in a dialog box and the user decide upon which look of that widget
|
|
Jordy:
|
whoah, two classes?
|
|
jjanx:
|
./src/widgets/clockWidget_impl.o
|
|
graydon:
|
Jonas: no, the widget simply needs to be able to produce a concrete object, executable by another thread, which can draw it. Otherwise the draw thread can be held up if a widget has locked itself to change state.
|
|
Aaron:
|
jjanx: delete it and make again
|
|
Jordy:
|
maybe i should write a formal proposal on how our entire widget system should work
|
|
Jordy:
|
and you all can hack it to peices
|
|
Jordy:
|
:)
|
| | graydon thinks stefan is taking this a little further than I would.. |
|
Loren__:
|
Jonas: I don't think that the widgets should be split, but that each widget should be as flexible as possible... so we don't re-write 100 different styles of each widget...
|
|
Dusk:
|
graydon: so each widget is still responsible for its own specific rendering, but it's offloaded into a separate thread?
|
|
stefan:
|
jordy: what I currently use in my framework (OffiX) is one extreme:
|
|
stefan:
|
jordy: every widget implements a second class, a Widget::Look
|
|
Jordy:
|
what I currently use is the windows9x visualbasic objects, but one step further
|
|
graydon:
|
Dusk: well, that's what it currently does, I'm just suggesting we put a corba wrapper on it (GL) so as to make it portable. stefan apparantly wants a little more.
|
|
Jordy:
|
or swing objects
|
|
Jordy:
|
which do basically the same thing
|
|
anoq:
|
The way I do in the abstract GUI thingy to make it look, feel, platform, toolkit independent, is to say: I want these widgets tobe able to do this and that. I don't care how, just do it... The GUI could be a 3D-world or a script memorized by a naked woman :)
|
|
stefan:
|
jordy: this means for example that Button : public Widget defines a Button::Look : public Widget::Look
|
|
Jordy:
|
stefan: mmm
|
|
Dusk:
|
graydon: a CORBA wrapper on what, precisely?
|
|
Jonas:
|
stefan: What is gained from splitting a widget into two objects?
|
|
graydon:
|
anoq: that's impossible. sorry dude, computers can't read your mind.
|
|
Jordy:
|
jonas: less duplication of code
|
|
Jordy:
|
basically
|
|
stefan:
|
jordy: this isn't the best solution, the other extreme would be to let a factory (WidgetKit) deliver a widget in a given look.
|
|
Aaron:
|
stefan: but isn't a 'look' as you're defining it just accomplished by having a different widget stand in for the current one?
|
|
graydon:
|
Aaron: well, he's got a point, it lets you reuse more of the widget logic
|
|
Jonas:
|
jordy: I think the price is a little high :(
|
|
Jordy:
|
he wants to split the controller and look.. the problem is that they are inheritently intertwined
|
|
graydon:
|
Jordy: not always, not totally.
|
|
Jordy:
|
i like the swing/visual basic object method, i think delphi does the same thing
|
|
Jordy:
|
though i've never used delphi
|
|
anoq:
|
graydon: say = write :)
|
|
stefan:
|
aaron: no. I have definitions for OLButton : public Button::Look and MButton : public Button::Look and a global factory
|
|
Jonas:
|
graydon: oh but they can! Somebody has moved objects on screen by mind!
|
|
stefan:
|
loads them all and can create looks on demand
|
|
Jordy:
|
you create a button widget, the button widget contains all *basic* information... then if you want to create a win9x specific button, you can reuse the code from the button widget
|
|
Aaron:
|
stefan: so can you apply one look to more than one widget?
|
|
Jordy:
|
that is sort of like a merging of what stefan wants
|
|
Jonas:
|
stefan: but what is gained on that instead of just exchanging the button.so with another button.so?
|
|
Jordy:
|
the main button widget contains no "look"
|
|
graydon:
|
stefan: when you say "button : public widget defines button::look : public widget::look", how does it define it?
|
|
Jordy:
|
the win9x buttonw idget contains a look + some extra code to handle the new look
|
|
Jordy:
|
but then you have problems in applications
|
|
Jordy:
|
oi
|
|
graydon:
|
Jonas: true, I saw that mind control thing. ok. *my* computer can't read *my* mind. I have a sucky computer
|
|
stefan:
|
jordy: I don't reuse the widget, I *keep* it ! I just load another look (as in the State pattern)
|
|
Jordy:
|
stefan: hmmm
|
|
Jonas:
|
graydon: :)
|
|
Jordy:
|
stefan: that'll work... i guess :)
|
|
Aaron:
|
stefan: write up a proposal about exactly how it would be accomplished... I'd love to see details.
|
|
Loren__:
|
I thought this "mind-reading" issue was the whole point of the Registry...
|
|
stefan:
|
graydon: Button::Look defines the interface for the Buttonlook, concrete classes have to implement it (as here with Open Look and Motif)
|
|
Jonas:
|
stefan: but how does that differ from the current idea, with exchanging .so?
|
|
Jordy:
|
really the only advantage of that stefan that i can see is saving some disk space
|
|
Dusk:
|
stefan: you just swap out the renderer?
|
|
graydon:
|
stefan: right, but what kind of a *thing* is Button::Look? an inner class?
|
|
Jonas:
|
stefan: but wouldn't it just be Button::Look::draw()?
|
|
Jordy:
|
and possibly some memory if you have two buttons of two different types on screen at the same time
|
|
Jordy:
|
which would be a big win
|
|
Jordy:
|
memory is important, disk space is not :)
|
|
Jordy:
|
hmmm
|
|
Jonas:
|
Jordy: I have more need for diskspace the mem currently :)
|
|
Dusk:
|
What if you want to swap out widget behavior, but want to keep the same look?
|
|
stefan:
|
graydon: a nested interface, accessible to all who want to implement a new look
|
|
anoq:
|
Jonas: me too :0
|
|
graydon:
|
stefan: ok.. I'm not sure nested interfaces work in IDL
|
|
stefan:
|
jonas: exactly ! Button::draw() { look->draw();}
|
|
Jordy:
|
i get it
|
|
graydon:
|
stefan: I think we need to actually make a class called buttonLook
|
|
Jonas:
|
stefan: why not just use the current widget::draw()?? Why does it _have_ to be in another class?
|
| | jjanx has left channel #berlin : (problems > mailing list; less irclog) |
|
Jordy:
|
so you ahve ButtonWidget.so... ButtonWidgetMacLook.so
|
|
stefan:
|
graydon: I think it doesn't change anything if we make it an external hierarchy.
|
|
graydon:
|
Jonas: because it's a different concept. different concepts are objects you can vary intependently. he's got a point.
|
|
Jordy:
|
ButtonWidget.so -> ButtonWidgetMacLook.so to render look
|
|
Jordy:
|
but all reactor stuff is done in ButtonWidget
|
| | liet (martine@ts008d09.sea-wa.concentric.net) has joined channel #berlin |
|
Jordy:
|
as well as layout
|
|
graydon:
|
stefan: no, I don't think so. not much.
|
|
Jordy:
|
and sizing and wha tnot
|
|
stefan:
|
graydon: the only tricky thing is it is a 'dual hierarchy' and that demands attention with respect to creation and so on
|
|
graydon:
|
stefan: yeah, that's what I'm thinking. it's a little mess to work out.
|
|
Aaron:
|
stefan: so now you have 'looks' which can be substituted for one another... such that any widget designed to implement a 'look' can have any available look
|
|
graydon:
|
stefan: also, the look *still* needs to be able to produce a stable renderer object, right?
|
|
stefan:
|
aaron: exactly, and I have test applications running with lots of different button looks at the same time
|
|
Aaron:
|
stefan: 'look' would be in-process to the server, behavior would be via CORBA, right?
|
|
stefan:
|
graydon: if renderer means that thing which one day replaces a displayList, yes.
|
|
Aaron:
|
stefan: I see it.
|
|
graydon:
|
stefan: yea
|
|
Aaron:
|
stefan: that would make for a very flexible system...
|
|
anoq:
|
It seems we have at least 2 different abstraction levels of pluggable look & feel...
|
|
stefan:
|
graydon: but this renderer would work on a 'declarative basis', it is the same class which keeps different drawing commands
|
| | graydon rejoices at a moment of shared understanding by more than 1 person simultaneously |
| | Jonas is still puzzled |
|
Aaron:
|
IRC chats are ad-hoc, they tend to arouse confusion ;)
|
|
stefan:
|
graydon: 8-)
|
|
Aaron:
|
stefan: am I right about how these different pieces of logic would be placed?
|
|
anoq:
|
Aaron: agree
|
|
graydon:
|
stefan: yes, it is a semi-linguistic sequence of (nested) calls to the drawingKit
|
|
Dusk:
|
So does a single renderer support multiple types of widget (e.g. edit box, checkbox), or does each widget of each render style have its own renderer?
|
|
graydon:
|
stefan: and to other renderers
|
|
stefan:
|
aaron: yes, basically, the programmer's interface *is* the widget, which is exported through CORBA, the look is not (an implementation detail)
|
|
Jonas:
|
The only reason for splitting up into two hierarchies whould be that look-implementors have one hierarchy to change instead of changing the widgets draw()
|
|
graydon:
|
Dusk: a renderer is a replacement for a displayList. it's a frozen sequence of draw commands
|
|
anoq:
|
stefan: I must disagree here...
|
|
Aaron:
|
stefan: so widgets are in process too...
|
|
Dusk:
|
In other words, is there a MacLook renderer and a WinLook renderer, or a MacLookButton, MacLookCheckBox, etc.?
|
|
Jordy:
|
that's how i see it, which is a good idea
|
|
Jordy:
|
saves on memory
|
|
graydon:
|
Dusk: the latter
|
|
Jonas:
|
graydon: but why does the sequence of drawing cmds (defining look) has to be in a seperate hierarchy?
|
|
Dusk:
|
So a "renderer" is sort of a frozen "rendering"?
|
|
stefan:
|
graydon: it is frozen, but it is not imperative ! I don't want to write another class hierarchy, so
|
|
graydon:
|
Jonas: it doesn't. a renderer != a look
|
|
stefan:
|
graydon: I would simply add drawing commands like renderer->drawLine(...) and finally call a
|
|
Jordy:
|
right, don't worry about that, the look would be just a collection of drawing commands
|
|
Jordy:
|
for each state of the widget
|
|
stefan:
|
graydon: renderer->compile() to optimize so when it really comes to redrawing we can call renderer->execute()
|
|
Jordy:
|
basically just a bunch of callbacks
|
|
graydon:
|
stefan: and the renderer would hold those commands in an internal data structure
|
|
Jordy:
|
man, do you know how many IDLs berlin is going to have
|
| | Jordy is scared to think about it |
|
graydon:
|
Jordy: it's grody. this is why we need another ORB
|
|
stefan:
|
garydon: or better renderer->execute(currentTransformation) so the renderer knows where to draw actually
|
|
Jordy:
|
i like our orb, i just don't like our idl compiler
|
|
stefan:
|
graydon: as does the displayList internally
|
|
anoq:
|
Jordy, graydon: My idea of the Warsaw API is approx 10 lines :)
|
|
Jordy:
|
i gotta switch to my laptop so i can watch tv at the same time :)
|
|
graydon:
|
anoq: I think you'll be disappointed
|
|
Dusk:
|
Well, I gotta get going. See ya later!
|
|
Jordy:
|
warsaw needs to be bigger than that, we need event handlers, etc
|
| | Dusk has left channel #berlin |
|
Jonas:
|
ohh well, atleast we still have a little way before surpassing MFC! :)
|
|
anoq:
|
graydon: Nope! Since I can do it in ML, so it must be possible in IDL too
|
|
Jordy:
|
which are "default" set in stone API's
|
|
graydon:
|
stefan: so renderer should present the *exact* same functions as drawingKit, only it saves the commands rather than executing them.
|
|
graydon:
|
anoq: theres no way you can do a widget API in 10 lines of ML
|
|
stefan:
|
graydon: no, renderers should be able to *record* calls to DrawingKit (or to class instances created with it)
|
|
anoq:
|
graydon: I'll post an IDL proposal later :)
|
|
graydon:
|
stefan: uh.. wait, drawingKit->makeInstance(myRenderer) ?
|
|
Loren__:
|
one thing... you can easily have one widget have almost any look by allowing it to use pixmap backgrounds/fades... etc
|
|
Aaron:
|
also, would this scheme reduce the number of mutex locks we need? yes, I think it would...
|
|
stefan:
|
graydon: back to graphics hierarchy: I think that Graphic should have the interface for composites too
|
|
Jordy:
|
there we go
|
|
Aaron:
|
right now the display server is pained from having to do a zillion mutex locks/unlocks
|
|
graydon:
|
stefan: yes. composite is not widget, widget is composite
|
|
stefan:
|
graydon: because as Fresco showed, decoration graphics (in the pattern sense) are *very* useful so you have
|
|
stefan:
|
graydon: to have the full interface for those too if you want to delegate all method calls properly
|
|
Jonas:
|
sorry, but my time is running out, have to run :(
|
|
graydon:
|
stefan: I agree. composites rock. I just want to make sure I understand what you have in mind as far as renderers
|
|
graydon:
|
jonas: log will be posted on www.berlin-consortium.org
|
|
Jonas:
|
graydon: ok, will read and create excessive amount of email :)
|
|
stefan:
|
graydon: with respect to renderers: it's all just what I have come up with after our conversations with respect to openGL
|
|
Jordy:
|
i need to get something to eat
|
|
Jordy:
|
i'll be back in 5
|
|
graydon:
|
stefan: ok. i think we're all getting cranky & tired. been here for 3.5 hours
|
|
stefan:
|
graydon: fine, I think we can do the rest (;-) via email
|
|
graydon:
|
Loren asked if we could find someone to "take over" the integration of a JVM..
|
|
stefan:
|
nice to talk to you all !
|
|
Jonas:
|
Could we please see some papers on todays subjects?
|
|
graydon:
|
Jonas: I'll try to find more things to add to the links page. I re did it a while back, much new stuff.
|
|
stefan:
|
jonas: I have a whole bunch of Fresco related papers which I would like to put on the Berlin page
|
|
graydon:
|
oh, also!
|
|
Loren__:
|
graydon: ts sounded somewhat interested... but said he had to think about it...
|
|
graydon:
|
before peopel go running off, congradulate Aaron!
|
|
graydon:
|
look at the screenshot and drool over thee awesome might of berlin!
|
|
graydon:
|
http://www.sonic.net/~vanco/berlin-001-release.gif
|
|
anoq:
|
:)
|
|
Jonas:
|
I meant papers describing exactly what we mean. If the Fresco docs describes exactly why looks and logic should be seperated then link
|
|
anoq:
|
Good work Aaron! :)
|
|
graydon:
|
and Chalky, who wrote the eyes & clock (correct?)
|
|
Loren__:
|
Whoa... awesome...
|
|
Jonas:
|
these are widgets currently running on the Berlin server? Cool :)
|
|
Aaron:
|
yess
|
|
anoq:
|
good work you too :)
|
|
Aaron:
|
chalky did the demos.
|
|
Loren__:
|
ts... are you still here?????
|
|
Jordy:
|
alright
|
|
Jordy:
|
i'm back :)
|
|
Aaron:
|
I'm still trying to finish up my poly widget which will demonstrate situational logic and arbitrary transforms on composites
|
|
stefan:
|
graydon: we will have to have a closer look at amulet, apparently they use constraints
|
|
Chalky:
|
well, a buttonwidget and a box widget are not very inspiring to prospective developers
|
|
graydon:
|
stefan: cool. ok. this was useful. anyone have additional topics to discuss?
|
|
Chalky:
|
what is the status on the registrar currently?
|
|
Jordy:
|
working
|
|
Jordy:
|
needs some caching cleanup
|
|
Jordy:
|
and i need to implement threaded log writes
|
|
Jordy:
|
and a queue system for writing to the actual db
|
|
Chalky:
|
cool
|
|
Jordy:
|
plus implement checks so the damn thing won't crash if it gets corrupted :)
|
|
Jordy:
|
the log will help on that state
|
|
Jordy:
|
since i can just rewind the log to a point in time
|
| | Signoff: Jonas (jonas unreachable.... 414 operator not found..) |
|
Chalky:
|
oh, graydon: can I add in debug::setall() a bit which checks some env var and sets/unsets some debug/log types?
|
|
graydon:
|
Chalky: yeah, that'd be good.
|
|
Chalky:
|
since generally I am only interested in say widget info, and all that reactor spam can go to hell :)
|
|
graydon:
|
Chalky: yes, the server seems less fast because of it. if you pipe to dev null it runs faster :)
|
|
Chalky:
|
heh yeah
|
|
Jordy:
|
mmm, healthy lunch, 3 pb&j sandwiches
|
|
anoq:
|
the end?
|
|
Loren__:
|
Jordy: yummy...
|
|
graydon:
|
ok then, if we're all done, lets go home.
|
|
ts:
|
im almost caught up
|
|
Aaron:
|
oh my golly gosh
|
|
Aaron:
|
testEyes is hella fast when debug is going to /dev/null
|
|
Jordy:
|
wait, what is this picture at sonic.net?
|
|
Aaron:
|
but it deadlocks instantly
|
|
Aaron:
|
Jordy: taht's berlin
|
|
stefan:
|
bye then
|
|
graydon:
|
I'll close the log and go pretend like I didn't spend all day on IRC.
|
|
ts:
|
aaron: thats what i told chalky last night :)
|
|
ts:
|
i want to get rid of all those damn cerr message
|
| | stefan has left channel #Berlin |
|
Jordy:
|
throw the cerr to syslog
|
|
graydon:
|
running any particular widget, or just eyes?
|
|
anoq:
|
OK then, take care now, bye-bye then
|
|
Jordy:
|
LOG_DEBUG
|
|
Jordy:
|
syslog will queue
|
| | anoq has left channel #berlin |
|
Jordy:
|
and should return immediately
|
|
Chalky:
|
graydon: I've been here 4.5 hours, and yet right now it's only 9am
|
|
Aaron:
|
graydon: when mousepointer events come too fast it locks
|
|
graydon:
|
Chalky: where do you live
|
|
Jordy:
|
5:14 here
|
|
graydon:
|
Aaron: yes, but just normal mouse events or mouse events going to a particular widget?
|
|
Aaron:
|
mouse events going to the eyes widget
|
|
graydon:
|
Aaron: ok, I'll read eyes and see if I can find a deadlock. I should go though. see y'all.
|
|
Aaron:
|
cya
|
|
Jordy:
|
someone has a while() loop somewhere :)
|
|
Jordy:
|
heh
|
|
Chalky:
|
melbourne, australia
|
|
ts:
|
i didnt get eyes to lock on me
|
|
ts:
|
sorry ;)
|