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