IRC Meeting Log on #berlin

#berlin

	** Topic for #berlin is meeting today at 0:00 UTC
	** Topic for #berlin set by stefan Thu Sep 23 10:29:15 1999
hunger:	Hi!
graydon:	hello hello
hunger:	Can someone recommend an irc client with logging?
graydon:	I use X-chat
hunger:	Can it do logging?
graydon:	yeah, seems to
hunger:	How do you turn it on? I use it too.
graydon:	prefs->logging->turn logging on
hunger:	Oh, I found it!
hunger:	Where does X-chat put its logs?
	** stefan (stefan@rubidium.BIOPHYS.UMontreal.CA) has joined #berlin
stefan:	hi
hunger:	Hi Stefan!
stefan:	hunger: did you sleep well ? ;)
hunger:	stefan: Not at all.
graydon:	hi
stefan:	hi graydon
graydon:	stefan: you do molecular bio, right?
stefan:	right, sort of.
	** hunger has quit ( [x]chat)
stefan:	more molecular biophysics.
	** hunger (hunger@alcatraz168.wohnheim.uni-kl.de) has joined #berlin
graydon:	stefan: ever play around with quantum chemistry?
stefan:	and even then, I'd rather not stress the 'molecular' :)
stefan:	uh ? no, I don't like that. What's up ?
stefan:	DFT and all that ?
hunger:	OK. Logging works now.
hunger:	So at least I won´t miss anything in case I fall asleep.
stefan:	(DFT == Density Functional Theory)
graydon:	stefan: well, I've started to get into it; sorta out of curiosity. it seems very cool, like that you can actually work out the geometries of stable states of quantum systems.
stefan:	graydon: yes.
stefan:	graydon: but with increasing size it gets more and more complex and uncomputable...
graydon:	stefan: hmm. ok, well if it's not your thing I won't dwell on it. it's just something I've been learning about.
graydon:	stefan: oh, it doesn't look uncomputable. just extremely large. uncomputable is actually a well-defined concept, and this doesn't fit it..
stefan:	graydon: well, I know about quantum physics and the basics for molecular physics/quantum chemistry but...it's kitchen work...
stefan:	graydon: right. not in the sens 'non integrable'. But practically...
	** _jwmoore (JohnMoore@ppp-aus247-208-24-38-158.austintx.net) has joined #berlin
hunger:	Hi!
stefan:	graydon: the art is finding the best approximation.
graydon:	stefan: well, or finding some faster ways to cut through the problem. or just throwing hardware at it. or some combination thereof.
stefan:	graydon: yes.
graydon:	anyway, we have a meeting to attend to :)
stefan:	so, anyone else got the 0.1.1 release running ?
_jwmoore:	yep
hunger:	Me too.
	graydon did.. tho that's no surprise :)
stefan:	what's your impression ? Generally...
hunger:	It starts to get really cool!
_jwmoore:	much faster - text is great
_jwmoore:	graphics leave nifty trails on the screen
hunger:	I have some minor graphic glitches here, but that could be because of my expertly patched Xserver.
Aaron:	hi
apt:	que tal
hunger:	Hi!
Aaron:	hey I have to get some food
	Aaron fell asleep
graydon:	stefan: I wondered about those trails: are we clearing the screen on each traversal?
stefan:	jwmoore, hunger: actually, there are some bugs left which make that too much is redrawn and some region not at all...
	Aaron can't get it running
Aaron:	food time, brb
stefan:	graydon: no, but the cull test is not correctly implemented, cause I can't decide where to test for what (extensions are a bit extensive and allocations won't do)
stefan:	once this is properly handled this will spead up things again :)
hunger:	It is MUCH faster then it was before. If it had a minesweeper I would not close berlin again ;-)
graydon:	stefan: ok, but.. the question I guess I'm asking is, if I damage a region, do I blank that region before redrawing it?
stefan:	oooh, graydon: no ! good point :)
graydon:	stefan: I mean, clearly I _should_, but it doesn't seem like we're doing so at the moment, which is why we're getting trails when dragging things around.
stefan:	graydon: exactly.
stefan:	by the way: did anyone try the resize stuff from this afternoon ?
	graydon just got home. updating and compiling..
hunger:	Not yet.
stefan:	now you can experience what layout really means !
stefan:	springs and all that...
graydon:	I have a feeling we're "over the hump" of development, and can proceed very quicky now.
stefan:	graydon: depends on what we are working on. We have certainly reached a milestone...
stefan:	I'd say it's an ideal point to create different 'working groups' (incl. mailing lists etc.)
graydon:	yeah
graydon:	I suppose the amount of "direct feedback" objects yet to be made, a la unidraw, is pretty substantial too.
stefan:	graydon: yes. There is plenty of stuff still to be poted from Fresco: all the FigureKit (Unidraw), lots from the TextKit...and implement cute widgets to make users happy.
stefan:	This seems easy since it's quite clear what to do. Other topics are less evident (like the StyleKit we were talking about)
graydon:	yeah. I've not had much time to devote to that this week. first week back => 3 math problem sets all due back-to-back.
Aaron:	ok back
stefan:	graydon: oh, there is plenty of other stuff to be fixed before we need to attack that. Think of the terminal we want for 0.2 :)
Aaron:	I didn't have time to finish namespaces in perceps today or yesterday. too much other stuff to do
graydon:	well, I don't want to get too far into writing things that use explicit style settings if all we're going to do is rip them apart anyway.
Aaron:	sorry stefan ;')
Aaron:	I also found out that I'm required to take this other class, so I'm going up to 17 units this qtr
stefan:	graydon: right. So primitive styling should be working soon. (In fact we only need an in memory representation, how we read that in is another story. right ?)
graydon:	yeah. really just a primitive interface and something that does, say, node-type-name selectors.
stefan:	graydon: but let's not discuss styling tonight, ok ? :)
graydon:	stefan: sure, another time.
graydon:	stefan: you have an agenda in mind?
Aaron:	anyone else coming?
graydon:	I thought we'd have better turnout. I'll send a nag message to the list.
stefan:	graydon: no, I just wanted to present the essentials of Prague since related topics come up from time to time. But we are still few...
	hunger yawn
Aaron:	what is on the agenda tonight?
stefan:	I think we could discuss Unicode and where we are heading with that, too.
Aaron:	AOL
hunger:	Sure.
graydon:	AOL?
Aaron:	put to rest all this 32 bit coding stuff
Aaron:	graydon: typespeak for a voiced approval
stefan:	And finally, how the scene graph actually looks like (and works), if anyone want's to go into this.
Aaron:	and why I'm still unable to run the server right now ;)
graydon:	yes, there seems to be some latent misunderstanding about that.
hunger:	That sounds interessting. I didn´t bother to get into it too deeply yet.
Aaron:	graydon, are you using a stock debian libggi?
graydon:	Aaron: yup
graydon:	Aaron: uh, libggi2
Aaron:	then I've no idea!
Aaron:	yeah, I know
stefan:	Aaron: what problems do you have ?
hunger:	Aaron: I use whatever is in debian´s unstable branch. It runs fine.
Aaron:	it's just refusing to run for me. looks like it's still dying when the drawable inits
Aaron:	NB though
graydon:	Aaron: are you running it via the shell script?
graydon:	the shell script which runs the DB builder which makes the DB for the unifont which will core dump if the DB is not present?
hunger:	I forgot that script in the beginning too.
graydon:	this is clearly a common problem. I should change unifont, to run the DB builder itself if it can't find the DB.
	** Received a CTCP PING 4054283574 from hunger
hunger:	A simple errormessage should be enough. The script is nice to have, I used to forget to set the environment varibles all the time.
graydon:	well, that too needs to be altered sometime to use a config DB (registrar). speaking of which, I talked to mike shaver (mozilla.org) about this, and he says they have a nice stable registrar we can just cannibalize if we like.
	** _jwmoore has quit ( forward.openprojects.net irc.linux.com)
	** Chalky has quit ( forward.openprojects.net irc.linux.com)
	** Aaron has quit ( forward.openprojects.net irc.linux.com)
	** stefan has quit ( forward.openprojects.net irc.linux.com)
	** dpkg has quit ( forward.openprojects.net irc.linux.com)
	** apt has quit ( forward.openprojects.net irc.linux.com)
	** hunger ( hunger@alcatraz168.wohnheim.uni-kl.de) has left #berlin
	** hunger (hunger@alcatraz168.wohnheim.uni-kl.de) has joined #berlin
	** stefan (stefan@rubidium.BIOPHYS.UMontreal.CA) has joined #berlin
	** _jwmoore (JohnMoore@ppp-aus247-208-24-38-158.austintx.net) has joined #berlin
	** Chalky (chalky@p3-max1.mel.ihug.com.au) has joined #berlin
	** thim (tim@tim.Desert.NET) has joined #berlin
	** Aaron (aaron@p110-122-w.tenaya.reshall.calpoly.edu) has joined #berlin
Aaron:	wb all
hunger:	What was that?
stefan:	a hurricane
graydon:	netsplit
graydon:	thank the makers of irc protocol.
stefan:	ok, graydon: let's start, hunger will be thankfull :)
Aaron:	someone logging?
	hunger keeps drinking coffee.
hunger:	I hope so...
Aaron:	you know what, dorm food is actually REAL good here! better than food I ate at home
hunger:	Dorm food?
graydon:	hunger: how long you been awake?
Aaron:	yeah.
thim:	dorm = dormatory (residence at college)
hunger:	I stood up at 9am. Now it´s nearly 3 am...
	** dpkg (johnie@master.debian.org) has joined #berlin
	** apt (apt@balti.brum2600.org) has joined #berlin
Aaron:	so either we get going, or we call off. nobody else is coming, I think...
graydon:	hunger: you poor soul. ok
Aaron:	I have an hour and a half
graydon:	stefan: you wanna begin?
	** dpkg has quit ( asimov.openprojects.net irc.linux.com)
	** apt has quit ( asimov.openprojects.net irc.linux.com)
stefan:	Hmm, ok. Prague:
	** apt (apt@balti.brum2600.org) has joined #berlin
	** dpkg (johnie@master.debian.org) has joined #berlin
hunger:	It´s OK. I can sleep in today.
	** Aaron has changed the topic to: Prague
stefan:	Well, the essential of Prague for us right now is the Sys stuff.
	** Aaron has changed the topic to: Prague::Sys
stefan:	It's a) Posix and other standard wrappers and b) convenience classes
graydon:	does it have a shared memory layer?
stefan:	They are real universal and I've started to insert them where appropriate. DLL is the dynamic load wrapper, SHM wraps SysV SHM.
stefan:	mmap can follow as well.
graydon:	I am strongly considering writing a "slabKit" which can give you a slab of framebuffer via libmm
graydon:	just to quiet the thread-which-will-not-die of high speed pixel-level access.
stefan:	There is a really thin (but powerful) Thread abstraction with nice templates (modeled after ACE) for ThreadPool and MessageQueue.
Aaron:	what if we're not using framebuffer? that breaks portability...
stefan:	Aaron: then simply don't use a particular module :)
graydon:	Aaron: yes, it does. if the kit's not present, your app doesn't run.
	** dpkg has quit ( irc.linux.com varley.openprojects.net)
	** apt has quit ( irc.linux.com varley.openprojects.net)
Aaron:	maybe something that gives GGI directbuffer access instead. That would make it work on X and/or other targets where direct fb access would be impossible...
	** joesh (joesh@p26-max6.ham.ihug.co.nz) has joined #berlin
Aaron:	but that wouldn't be the right thing to do sometimes
stefan:	Graydon: let's come back to this low level graphics stuff later. Prague, however, can provide the IRC stuff like mmap or SHM.
graydon:	stefan: do you recall how we were going to settle on threading strategies?
stefan:	graydon: did we ?
graydon:	stefan: for commands, that is.. we were discussing basically how to do what reactors were supposed to do, but since they don't fit with the model very well we were going to discard them somehow.
graydon:	stefan: I don't recall if we settled on anything else though.
	** dpkg (johnie@master.debian.org) has joined #berlin
	** apt (apt@balti.brum2600.org) has joined #berlin
graydon:	stefan: I take it all commands the widgetKit makes are synchronous now?
stefan:	graydon: we want to provide special wrapper commands which simply provide a thread to run the body command in.
	** Aaron has changed the topic to: threading issues
graydon:	stefan: ah yes, that was it. wrapper commands. now I remember
stefan:	graydon: yes, currently all is synchronous. However, I think the majority of (long living) commands will live inside the client so it's not really a server issue, right ?
Aaron:	so a command comes with its own thread now?
Aaron:	instead of stuffing commands into a queue, like before?
graydon:	stefan: well, it depends. if there's a subject with a really long list of remote observers, you might like that in its own thread
graydon:	stefan: even if you put, say, 90% of the work in a single secondary thread, just getting it out of the picking thread is important.
stefan:	graydon: then the point is to make the observer returning immediately and doing the rest inside a thread.
graydon:	stefan: I consider input events somewhat like "interrupts" in a kernel. we want to get out of handling them as fast as possible.
graydon:	stefan: but there might be many observers, a long way off.
Aaron:	for things like multiple observers is there a way to use multicast?
stefan:	graydon: yes.
graydon:	Aaron: I doubt it.
Aaron:	or is that an ORB issue?
graydon:	Aaron: there's no way in corba to say "do this call on all these objects simultaneously"
Aaron:	graydon: there has to be. you'd be sending pretty much identical data to each...
stefan:	Aaron: you update the observers sequentially. May be the subject::update() call should be run inside a thread.
graydon:	Aaron: nor for that matter in most languages.
Aaron:	graydon: well this is a network protocol, not conventional code...
_jwmoore:	you can do non-returning calls and poll for a response
Aaron:	seems to me the orb could be modified for it. but oh well, that's imp detail.
stefan:	jwmoore: but I find threading within the observer more clean.
graydon:	stefan: I think a single "updater thread" shared amongst the server would do.
stefan:	jwmoore: because an update to an observer won't return a value anyway...
stefan:	graydon: yes, that was my thought.
_jwmoore:	agreed
	hunger agrees too.
stefan:	graydon: anyway, say, a thread pool with n threads.
graydon:	stefan: yes.
	** dpkg has quit ( sterling.openprojects.net irc.linux.com)
	** apt has quit ( sterling.openprojects.net irc.linux.com)
	** apt (apt@balti.brum2600.org) has joined #berlin
	** dpkg (johnie@master.debian.org) has joined #berlin
stefan:	My thread pool is very simple. Look at it. It's just a little header. We can use instances thereof pretty much anywhere (and configure them like number of threads etc. at run time...)
graydon:	stefan: neat. so, I think what this means is that we should have a constructor in the commandKit which takes a subcommand and a threadpool name
graydon:	stefan: like ck->threadPoolCommand("updatePool", ck->updateCommand(observer));
stefan:	graydon: the CommandKit could manage it's own thread pool. No need to expose it through CORBA.
graydon:	stefan: sure there is -- choice of which pool to associate with.
Aaron:	stefan, graydon: when is your presentation with that trade show in canada? alternative linux I think...
graydon:	Aaron: november
Aaron:	mid?
stefan:	graydon: what if every CommandKit has it's own thread pool ? The command is colocated with that CommandKit anyway...
joesh:	how does berlin handle resolutions, is it like windows in which it compacts down the screen, or 3d in which the higher the res the more detail is included. sorry about the dumb question, i'm only a webdesigner. take pity.
Aaron:	joesh: display in berlin is all handled by GGI.
Aaron:	joesh: pretty much, anything GGI supports, Berlin supports at this point
stefan:	joesh: we are 'resolution independant'. At least the code is.
	** Firc1 (support@198.95.38.66) has joined #berlin
joesh:	excellent
graydon:	joesh: vectors are rasterized just at the last instant, so it should just "expose more detail"
graydon:	joesh: unless you are editing a raster. we can't manufacture detail in that case
Aaron:	it could even display fairly decently to an extended mode ASCII terminal if you set the res low enough ;)
	** dpkg has quit ( asimov.openprojects.net irc.linux.com)
	** apt has quit ( asimov.openprojects.net irc.linux.com)
Aaron:	'res' in this case should be siad more like, setting the zoom high
	** apt (apt@balti.brum2600.org) has joined #berlin
	** dpkg (johnie@master.debian.org) has joined #berlin
graydon:	stefan: well, that would let the client manage their own pools by making multiple kits, but it would make it tricky to share a pool across a number of kits. it probably makes more sense to have them not interfere, but that might be asking for a lot of threads.
	Aaron thinks the drawable could be expanded to a floating viewport on a subject, namely the terminal's root window ;)
stefan:	graydon: ok, we need to work out that...
Aaron:	graydon: idle threads aren't exactly expensive
stefan:	Aaron: not with CPU time, but all have a stack...
Aaron:	right, gotcha there
graydon:	yeah, we'll see. in any event, wrapper commands answers the question, so we can move on.
stefan:	There will be a number of thread pools: the ORB has it's own, the Timer uses one thread, the Dispatcher (which handles IPC connections) has a pool too...
Aaron:	how do we use IPC in berlin
stefan:	ok, IPC:
graydon:	agents!
Aaron:	I don't quite see where that fits in... enlighten me ;)
Aaron:	what's an agent? ;)
	** Firc1 is now known as jon_taylor
	** dpkg has quit ( sterling.openprojects.net irc.linux.com)
	** apt has quit ( sterling.openprojects.net irc.linux.com)
Aaron:	or give me source file, and I'll look it up myself
Aaron:	hello jon!
stefan:	There are some interesting papers from Doug Schmidt about how to manage state and asynchronous call backs. There are a number of patterns we can combine.
stefan:	(Hi Jon !)
graydon:	Aaron: afaik that's what stefan is calling the IPC stream proxies in prague. might be mistake.
jon_taylor:	hi Aaron *grumble grumble damn louse win32 IRC clients...
hunger:	Hiya!
stefan:	So, my OffiX approach is using Agents.
	** dpkg (johnie@master.debian.org) has joined #berlin
	** apt (apt@balti.brum2600.org) has joined #berlin
stefan:	You have Agents which bind to the Dispatcher. Agents can bind three channels (like input, output, error)
Aaron:	ok...
stefan:	The keypoint to use Agents and not other callback handlers is that Agents preserve state, so you don't necessarily want to propagate all IPC data outside an Agent. The exact strategy depends on the SAgent you use. Ther eare Agents for pipes, sockets, ptys.
graydon:	the pty is most interesting to me atm. does it work ok?
stefan:	On top of them you can build special agents. Coprocesses (which need to handle sigchild, wait, fork etc.) are using either pipes or ptys. Connectors simply use sockets. For example higher level network protocols would derive from Connectors.
Aaron:	I don't quite understand. I'll browse the soruces a bit...
	** dpkg has quit ( asimov.openprojects.net irc.linux.com)
	** apt has quit ( asimov.openprojects.net irc.linux.com)
stefan:	graydon: it worked in OffiX, yes. I changed quite a bit but will try my best to get it up and running again.
graydon:	does anyone know much about terminfo?
	** apt (apt@balti.brum2600.org) has joined #berlin
	** dpkg (johnie@master.debian.org) has joined #berlin
stefan:	graydon: ask Andrew Aptet. He actually wrote his own xterm.
hunger:	Besides that it is a mess?
Aaron:	graydon: how come? are you working on the terminal?
	** dpkg has quit ( irc.linux.com varley.openprojects.net)
	** apt has quit ( irc.linux.com varley.openprojects.net)
Aaron:	openprojects is having BAD trouble
graydon:	stefan: are you thinking, as I am, along the lines of using an in-process pty agent connected to /bin/sh as our terminal emulator?
	** dpkg (johnie@master.debian.org) has joined #berlin
	** apt (apt@balti.brum2600.org) has joined #berlin
stefan:	graydon: sure.
stefan:	graydon: a terminal is just another widget.
Aaron:	you mean to restrict the terminal to running /bin/sh?
	** fatjim (fatjim@h24-66-253-88.xx.wave.shaw.ca) has joined #berlin
Aaron:	or was that just an example
stefan:	graydon: the pty agent can be used for anything
	** Aaron has changed the topic to:
graydon:	stefan: yeah. so for the time being we can write a small termcap entry which just presents typescript abilities, nothing fancy.like cursor positioning or whatnot, then the agent callback will append to a text buffer.
stefan:	graydon: like, for example, the expect program. You give a stack of regexes to look for...
stefan:	graydon: yes. You should contact Andrew for details.
Aaron:	maybe he could be recruited to write a bterm ;)
graydon:	yes, I see. I'm just making sure we're thinking along the same lines, rather than making a separate program (berlinTerm) which holds the buffer, and accessing it as a subject via corba. which would be "safer" but imo pointless.
stefan:	graydon: why safer ?
graydon:	stefan: well, a rapidly spewing stream could allocate too much memory or adversely hurt the server process, is all.
stefan:	graydon: we could control the agents priority...
graydon:	stefan: or even, I mean it seems quite unlikely since C++ i/o seems rather a lot safer, but you could even conceive of a buffer overrun..
stefan:	hmm.
graydon:	stefan: I guess I'm just "speaking for jordy", since he seemed quite concerned that we move things out wherever possible
graydon:	but I personally feel like terminals are a ubiquitous part of unix and ought to be in-process.
stefan:	graydon: full agreement.
	** alain (alain@207.96.250.107) has joined #berlin
	** fatjim has quit ( using sirc version 2.211+KSIRC/981227-pre0.9)
alain:	hello
apt:	privet, who
	** fatjim (fatjim@h24-66-253-88.xx.wave.shaw.ca) has joined #berlin
stefan:	Graydon: to get the full power of Unix we should make use even of all the non graphic tools...
stefan:	allo alain !
alain:	Hi Stefan,how are you ?
stefan:	graydon: like running automake (:-) inside a terminal widget which filters the output and transforms it into something useful...
hunger:	Hi alain!
stefan:	alain: thanks
apt:	stefan: de nada.
graydon:	oh, I just noticed a new site opened up which is important for us to watch / participate in: www.linuxi18n.org. internationalization and localization information.
stefan:	so, Unicode time ?
graydon:	stefan: so you have a wrapper for coprocesses as well? this is relevant as a safety measure..
	alain just want to announce his birthday (23 years old,this is supposed to be my year of chance and so far,i've been very lucky as of now),now i'll stay in my corner and listen,good evening !!
stefan:	graydon: yes. (I ran it in OffiX, it needs to be fully adapted).
Aaron:	gratz alain
graydon:	yes, ok unicode.
stefan:	graydon: it basically is an idea I took from DDD.
alain:	notice Aaron thanks for the comment
apt:	alain: my pleasure.
alain:	sorry
stefan:	hunger: still awake ? ;)
graydon:	wow. we must be in the future. I am sitting in front of a 486, logged into my celeron 333a, and just built/tested berlin on the celeron, displaying via x over the network, on this machine :)
hunger:	Yep. Still here.
Aaron:	graydon: how well did it run
stefan:	graydon: tried the button example ?
stefan:	graydon: and the gauge with steppers ?
hunger:	I just compiled berlin. But I forgot to update my cvs-tree :(
stefan:	hunger: hahaha
graydon:	well, it's a little network intensive, and the poor 486 is having a hard time.
stefan:	graydon: yeah, ggi is dumping pixels to X :)
hunger:	And berlin takes ages to compile. Exspecially since the berlin-make won´t use more then one CPU most of the time :(
stefan:	hunger: that we can change easily !
Aaron:	WEIRD
hunger:	How?
Aaron:	hunger -j 2
hunger:	I use -j 4 in the moment. I have enough RAM.
fatjim:	while on the subject of building, my build is breaking almost immediately. It can't find the file TypesDunSK.cc. any ideas?
stefan:	hunger: then it should be able to run in parallel with multiple processors.
Aaron:	* logbuf::dump =
Aaron:	[0.009766:0:corba] [0/5] hooked up to corba library
Aaron:	* end of logbuf::dump
Aaron:	detailed trace is empty
stefan:	fatjim: you mean TypesDynSK.cc ?
hunger:	It does sometimes., but most of the time it uses just one.
Aaron:	fatjim: hmm, that's odd. check include/warsaw to see if it's there
stefan:	fatjim: it's created with omniidl2.
graydon:	stefan: wow! the tests are terriffic now.
graydon:	stefan: very slick feeling.
stefan:	:)
stefan:	thanks !
apt:	sure thing, stefan.
Aaron:	graydon: I'd love to run one from your host ;)
Aaron:	you know, it comes to my mind that my cvs repo may be tained. I'll check out again....
stefan:	graydon: the Stepper is just such a little class...
stefan:	graydon: but it took a while for me to figure out how to do the MoveResize Command propperly :)
graydon:	stefan: although, well, we'll save it for now. I need to get going soon. what are we saying about unicode?
hunger:	The unicode dictionary is fixed, but it does not yet countain any data.
fatjim:	stefan/aaron: hmm.. nothing. seems that it's not creating the stubs/skels at all. I'll go see what's going on. thx.
graydon:	ok. 1 sec. brb
alain:	well,i have to go (some friend invited me for the end of the evening),have a good evening
stefan:	by alain
hunger:	And I put all the functions to hande Unichars into a little class.
stefan:	s/by/bye/
alain:	bye stefan
	hunger waves good bye.
stefan:	alain: do we meet at AlternativeLinux ?
alain:	stefan--where is that ??
Aaron:	are you guys going to put up a video of your conference? ;)
	** Anonymous (Anonymous@1Cust60.tnt2.provo.ut.da.uu.net) has joined #berlin
Anonymous:	# Appears as ANNA.
stefan:	www.alternativelinux.com: read carefully the page :)
hunger:	HI Anna
alain:	stefan--i'll do it !! (i suppose a meeting)
alain:	well,gotta go !!
stefan:	hi anna
	** alain has quit ( ciao !!)
Anonymous:	Finally get irc working, and most of the meeting is probably already over, right?
stefan:	ok, graydon: if you don't have so much time, just give a little talk about the scene graph and such...
graydon:	alain will be at alternativelinux? cool..
graydon:	stefan: what about it?
stefan:	graydon: about what ? the scene graph ?
graydon:	stefan: yeah, what do you want me to say?
Aaron:	perhaps how migrating will be done...
	** Anonymous is now known as pfred
stefan:	Well, anyone any questions about it ? Do you catch the basic idea ? I admit that it takes some time to get to it...
hunger:	Not really.
graydon:	not really == you know how it works or you do not know how it works?
Aaron:	stefan: it's not that I understand, it's that I don't know what question to ask ;)
hunger:	I just skimmed over the relevant docs.
stefan:	Aaron: yeah, good point.
Aaron:	just too many classes involved. I just have to devote a couple of hours to understanding how traversals work, is all
graydon:	stefan: I think this tutorial is the crux of the matter. once I finish this analysis problem set tonight, I am going to write tutorial stuff all tomorrow and on the weekend, and hopefully that will get the thing's back broken.
Aaron:	I think I understand how the display, graphics, and layout objects work
hunger:	I think I understood that part too.
stefan:	What about Controllers, MVC, Commands ?
graydon:	basically all the graphics are objects which have a drawing kit "delivered" to them in graph-order, and they call a few methods on it to render themselves as the draw traversal walks the tree
Aaron:	MVC is fine, but controllers and commands are mysterious to me.
Aaron:	Yes, I know, a command is just an abstracted callback...
hunger:	I don´t even understand the MVC
graydon:	Aaron: we have this thing called a monographic, which is very important to understand
graydon:	monographics are decorators, which means they delegate most of their calls to a child graphic but happen to add a little facility, as a wrapper.
stefan:	I should draw a collaboration diagram for MVC...
graydon:	a controller is a monographic which is sensitive to events
Aaron:	right. monographic can only make calls to a drawingKit, and nothing else. except maybe receiving events...
Aaron:	ok
Aaron:	that makes sense graydon
hunger:	ok
Aaron:	so a controller might be one of the buttons in the button sample client
stefan:	Aaron: what do you mean, nothing else ?
graydon:	no, a monographic is like a parent with only 1 child, and most of the time you don't even bother noticing it is there. it might not even appear on the screen
stefan:	Aaron: it's more like a filter
graydon:	it might just be a logical container which is totally transparent, but it picks up events as they are delivered to its "interior" or "child"
pfred:	which part is the part in the scene graph? the controller?
stefan:	Aaron: see the 'decorator pattern'
Aaron:	ok....
	Aaron looks
graydon:	the scene graph is the graph of all graphics. so controllers are in it, as are their children.
graydon:	the concept of "child" is actually a scene-graph concept
	** jdub (jdub@slsdn22p35.ozemail.com.au) has joined #berlin
graydon:	"parents" contain their "children?
graydon:	"
graydon:	s/?/"/
pfred:	so is (eg) a button a combination of controller and view?
graydon:	so the "root" of the scene graph is the screen
graydon:	pfred: exactly
graydon:	pfred: it's a view wrapped in a controller
Aaron:	graydon: gotcha on this ;)
stefan:	pfred: exactly ! The outermost node is a Controller (the ButtonImpl) which contains Views.
stefan:	pfred: the Controller has a state (telltale) which is observed by the views (for example the dynamic frames)
graydon:	the controller will handle all the event reception logic, and it twiddles this little subject called a telltale which stores the "state" of the button abstraction (clicked, disabled, etc)
pfred:	ok. I couldn't quite visualize what the Allocation objects represented.
thim:	telltale == Model in MVC, right?
graydon:	thim: correct
stefan:	thim: right. Though they play a particular role here since every Controller has a telltale (in fact it is one)
graydon:	we also say "subject" occasionally.
stefan:	thim: so the M in MVC is yet another model you attach to controllers like buttons.
Aaron:	so Controller receives events and executes some Comman.....
stefan:	thim: oups: forget that, buttons have commands not models :(
Aaron:	Command
stefan:	Aaron: almost.
Aaron:	View draws
Aaron:	Subject is data internal to both the controller and the view?
stefan:	Aaron: Controllers control models. Some control Commands.
stefan:	Aaron: a View has no internal data.
graydon:	Aaron: and some "view" of the telltale will reflect its state visually.
Aaron:	just a screen region
Aaron:	right stefan?
thim:	stefan: a button has a Controller, which is a telltale, but it just doesn't use any of the bits for anything - kind of like an empty model....
stefan:	Aaron: yes, but since the graphic objects don't have the screen region statically attached to it (rather, delivered as context when traversed) they don't have any.
_jwmoore:	where are allocation requests turned into screen regions?
graydon:	pfred: an allocation is a region on the screen, currently "allocated" to a given graphic by its parent (and grand-parent, etc)
stefan:	thim: a button is a controller. It's telltale reflect for example the focus state or whether it is pressed, clicked, choosen (for choices etc.)
thim:	jwmoore: during traversal (pick/view traversal)
Aaron:	stefan: or the current setting of its boundedvalue...
pfred:	did we already discuss the new grabbing code? I never understood the problem since I wasn't sure what the Allocation was.
graydon:	thim: sorta. when an object damages the screen, it does so by calculating its current allocation ("reaching up" through its parents) and inserting a region into a damage list.
stefan:	thim, jwmoore: since a Graphic can appear multiple times on the screen (even multiple screens) an Allocation 'collects' all those regions occupied by a given graphic. Once these collection process is over, you can damage the regions to make them repair by the ScreenManager.
graydon:	thim: the process of turning layout constraints (requisitions) into allocations is what is done dynamically, during a traversal.
stefan:	this safes lots of memory (and costs some computing time)
Aaron:	the parent graphic is the one that determines requisitions right?
Aaron:	or rather
thim:	stefan: so...with the grab code, each device stores a traversal to a particular instance of a graphic in the scene graph (i.e., a leaf if the graph were flattened to a tree); that traversal selects one part of the Allocation of the graphic.
graydon:	that resolves requisitions of its children. yes. it does so by delegating to a particular layout manager, which is just a logic module.
stefan:	Aaron: the parent asks the children for their respective requisitions, then lays the children out and computes it's own requisition with that.
Aaron:	that sets the rules as far as how available space (requisitions) is turned into allocations
stefan:	Aaron: exactly.
Aaron:	cool, I got something right ;)
graydon:	stefan< this is exciting -- there's multiple people who know how it works!
Aaron:	then, an 'allocation' represents an actual screen region?
Aaron:	no
Aaron:	that was already explained. nevermind
stefan:	Aaron: all the screen regions occupied by a given graphic.
_jwmoore:	So requisitions just have size data, regions have position and size?
Aaron:	and a 'region' contains absolute coordinates on the screen right?
Aaron:	_jwmoore: remember this is all relative here ;)
Aaron:	since we're working on 100% translatable vectors
graydon:	jwmoore: requisitions actually contain "requirements in each dimension
stefan:	jwmoore, Aaron: no. For that you need an Allocation::Info structure. Regions are mostly given in local coordinate systems. So a region gives you the size (and an origin) and the Transform (a logical matrix) tells you how to get to this origin
graydon:	jwmoore: requirements are quite flexible layout constraints which express alignment, stretchability, compressability, and natural size.
Aaron:	so a region is given within the parent's coord space?
stefan:	Traversal contains both: the actual region (traversal->allocation() and the cumulative trafo (traversal->transformation())
stefan:	Aaron: mostly.
graydon:	jwmoore: a requisition is an x, y, and z requirement (possibly some remaining "undefined")
Aaron:	stefan: that's somewhat vague ;)
Aaron:	stefan: so basically, a parent can tell a client 'screw you, you get a 4x5 pixel space' when it asks for a 2"x2" block?
stefan:	Aaron: that's because noone dictates what coordinate system a region represents. But it is used most of the time to represent the child's allocation in local coorinates.
Aaron:	gotcha stefan
stefan:	Aaron: beside that we don't talk about pixels here, yes :)
Aaron:	stefan: yeah, but at some point pixels is what everything comes down to.
stefan:	remember, we are using 'Coord' as our basic measure. Screen contains conversion factors to turn them into pixels.
Aaron:	so, do clients instead talk about physical sizes?
stefan:	Aaron: never.
Aaron:	or just relative, proportional sizes?
graydon:	no, they talk about logical size.
stefan:	Aaron: pixels are exclusively dealt with by the DrawingKit.
Aaron:	graydon: ok
Aaron:	stefan: ok. so the client really has no idea how big it actually is on screen
graydon:	nope
stefan:	Aaron: (and even then, not all DrawingKits might need to express pixel wise...)
graydon:	although it's not unreasonable to ask. it can do a little math and work it out..
stefan:	Aaron: that's fun because you might want to embedd an application or a full screen into another (Application, Screen).
Aaron:	because of this, it might be useful to detatch the terminal from the drawable
Aaron:	let the user zoom it around, you know
stefan:	Aaron: ??
graydon:	a drawable has a dpi, and you can get your cumulative transformation, so you should be able to work out pixels if you need to. there ought to be a more convenient approach for those cases which need it tho.
Aaron:	stefan: too many children, and you end up with something that you can't see on your screen ;)
stefan:	Aaron: print it :)
graydon:	ya lost me.
Aaron:	stefan: so make the 'drawable' just a subsection of the 'terminal', and accept a trafo to apply to the entire terminal...
Aaron:	before drawing to the drawable
Aaron:	then you can zoom your display around the terminal
stefan:	Aaron: I don't follow...
Aaron:	stefan: you know how if you tell X to run at a high virtual resolution...
stefan:	Aaron: what do you mean by terminal ?
Aaron:	stefan: I believe I'm using a very old term... back from 0.0.1
stefan:	Aaron: aaaaah.
Aaron:	but, ah, this time, it wouldn't be using video memory directly
stefan:	Aaron: so you speak about the screen. (Graydon: right ?)
Aaron:	and the user could tell the display server to zoom a particular app to take the entire screen.
graydon:	stefan: yeah, i think he's talking about setting the screen transformation to be non-identity
Aaron:	by applying a trafo do the display
stefan:	Aaron: sure. You may change that dyna,mically, no problem. Just insert an arbitrary matrix.
Aaron:	stefan: so that's already possible, you're saying
stefan:	Aaron: you might want to rotate it...:)
pfred:	would that be possible? say to copy the scene graph of your second monitor into the first screen's scene graph?
stefan:	Aaron: as I have shown, this already works
graydon:	well, we have this problem of not being able to seemlessly rotate rasters or bitmaps at the moment :)
stefan:	pfred: sure !
Aaron:	stefan: transforming the entire screen?
stefan:	Aaron: yes.
graydon:	but vectors are no problem.
Aaron:	stefan: where did you do this?
stefan:	Aaron: no I didn't do this but I could :)
Aaron:	graydon: rotating accelerated GL will be hard too, if SHM is used
stefan:	Aaron: I transformed a hbox with buttons though (test/transform.cc)
graydon:	Aaron: transform.cc transforms the contents of one window. just do the same thing to the screen node.
Aaron:	graydon: ok, gotcha
Aaron:	stefan: I never looked at the raster impl. does it use GL texturing?
Aaron:	of course that might be slow
stefan:	no, not yet. I have no openGL textbook and I never got textures working...any takers ? :)
Aaron:	stefan: I know 0 GL ;)
	Aaron is ignorant of such things
stefan:	(Look into GLDrawingKit.cc
stefan:	)
	graydon grudgingly accepts task. there's reasons to fear it tho, eh? something to do with the 2**n size restrictions or somesuch?
Aaron:	graydon: what, fixing raster?
graydon:	Aaron: yeah. doing it using textures, anyway.
stefan:	graydon: yeah, we need to use artificial width/height settings and cut them...I started a log2() function in GLDrawingKit to get to the exponent and the residue...
graydon:	the thing is, there's no real agreed-on way to do arbitrary transformations of rasters. cause you have to interpolate, and there's lots of interpolations you can try. different speeds, different qualities.. jon: you know which is best?
graydon:	stefan: ok, I'll take a look at that. I'm going to focus on the tutorial first tho, since imo it's more important than rotated rasters :)
jon_taylor:	best in the eye of the beholder
jon_taylor:	\|->
graydon:	jon_taylor: yeah, figured.
Aaron:	jon_taylor: fastest then
jon_taylor:	pixel doubling
Aaron:	i think rasters should be as fast as possible, even at the expense of memory
stefan:	Aaron: depends on the size of your raster, eh ?
jon_taylor:	this is where a 'sizeemu' GGI target would help
Aaron:	stefan: well, it depends how radically they vary in memory use I guess ;)
stefan:	Aaron: and whether you actually need to rotate them etc.
graydon:	jon_taylor: well, we're talking any matrix you push on the stack, so this could be like skewing or whatnot as well.
jon_taylor:	oh ok
Aaron:	stefan: you suggesting we keep several around, and load up a new one the instant you apply a trafo? good luck ;)
stefan:	Aaron: could all be managed by a GLRaster cache.
Aaron:	stefan: well, it would be awesome.
jon_taylor:	also remember that some HW can do some of these funcs
graydon:	jon_taylor: although the practical benefits of spinning pictures around remains to be seen.
Aaron:	jon_taylor: this is why we're using GGImesa; we assume KGI will pick this up someday ;)
stefan:	jon_taylor: right, and we should let mesa/ggi decide which strategy to apply, right ?
jon_taylor:	stefan: yes
Aaron:	graydon: but while you're supporting resize trafos, you might as well support any matrix, since OGL already does...
	** MenTaLguY (mental@ppp221.bcpl.net) has joined #berlin
MenTaLguY:	Hey, did I miss the party?
stefan:	Aaron: not for pixels :(
Aaron:	ey mental
	MenTaLguY grins
jon_taylor:	hey there mental
stefan:	hi mentalguy !
Aaron:	stefan: of course, not for pixels, but for textures, yes
graydon:	Aaron: well, it does if you do it via the texturing facility. otherwise it only does "pixel-zooming"
hunger:	Hi!
stefan:	Aaron: but whether to use textures or pixels is the question ! Pixel drawing is faster.
MenTaLguY:	FWIW, I'm finally getting my system upgraded to the point where I might be able to do some useful Berlin hacking soon.
MenTaLguY:	Just did the glibc2.1 upgrade last week.
MenTaLguY:	stefan: in what context?
Aaron:	stefan: if you give graphics matrix transformation capability, but not rasters, you are being somewhat.... inconsistent
MenTaLguY:	indeed. there's no reason that rasters shouldn't support the same transformations as graphics in general
graydon:	stefan: I figure I'll just have a look over the matrix and make up my mind on the fly. like, if it can be done with a zoom, do a zoom. no point going into the texture system when you don't need to.
MenTaLguY:	in fact, doing otherwise would get obnoxious.
Aaron:	I think there is good reason for rotation transforms
MenTaLguY:	graydon: so, how do you determine that from the matrix?
stefan:	Aaron: the point is that we must decide which strategy to use. So we need to test whether the trafo actually rotates or just translates or zoomes. Then we can decide whether we need to take the texture approach or simple putpixel stuff...
Aaron:	stefan: putpixel can handle straight zooms?
Aaron:	rectangular zooms that is
stefan:	graydon: exactly. That's what I planned for in GLDrawingKit.
MenTaLguY:	graydon: it ... might ... be a straight scaling transform, except just a wee bit of roundoff error ... do you define a threshold where the approximation is "good enough"?
stefan:	Aaron: glDrawPixels, yes.
Aaron:	stefan: ok
graydon:	MenTaLguY: look at the eigenvectors.. y'know :)
Aaron:	you know this is getting seriously annoying
MenTaLguY:	eigenvectors?
Aaron:	I can't run the server
MenTaLguY:	(please note that I'm seriously deprived WRT formal math education)
stefan:	Mentalguy: as an optimization, the Transform interface lets you querry whether a given transformation is identity or only zoom or rotation.
graydon:	MenTaLguY: don't sweat it. it's just linear algebra.
stefan:	Mentalguy: based on that distinction we can decide how to proceed.
MenTaLguY:	stefan: ah.
MenTaLguY:	graydon: enhh.. perhaps, but there's still an apparent terminology gap.
Aaron:	what's an eigenvector? ;)
MenTaLguY:	graydon: I'm actually fairly advanced on a practical basis, but I'm largely self-taught; that means of course I get lost around people who know the terminology. :P
thim:	aaron: a list of eigenvalues :)
stefan:	mentalguy: anyway, it's easy to figure out (within a given precision) whether a trafo contains rotation or not.
Aaron:	mmm, what's an eigenvalue?
stefan:	Aaron: a zoom factor if there is no rotation.
graydon:	eigenvector is a vector v satisfying Tv = cv for some scalar c.
	** jdub has quit ( Leaving)
graydon:	where T is the transformation
MenTaLguY:	ahh.
Aaron:	Ok.
graydon:	c is the eigenvalue
graydon:	"eigen" means "characteristic" in german
	MenTaLguY nods
Aaron:	so T is basically reducible to a scalar multiplier ;)
MenTaLguY:	I did take German. Although I got two Ds.
stefan:	graydon: 'proper'
graydon:	along some vector
Aaron:	reduceable
graydon:	stefan: apologies. I do not actually know, I was only told :)
stefan:	Aaron: not one, but in a properly choosen coordinate system a 2d trafo might turn out to be two zoom factors.
pfred:	"eigenshaft" is characteristic, I didn't know "eigen" had it's own meaning :)
Aaron:	graydon: are you going to have any cool demos ready for alt linux, like relocating scene graph nodes, etc
Aaron:	?
Aaron:	stefan: understood.
graydon:	Aaron: uhh. I don't know. I'll be pretty pleased if I even make it there, much less have a running demo :)
Aaron:	ehehe ;)
graydon:	Aaron: it'd be nice. we'll see if they provide us with any actual machines
stefan:	alt linux ?
Aaron:	s/alt/alternative/
graydon:	stefan: the conference
stefan:	oh. By the way, we'll get a booth :)
Aaron:	stefan: then you need a demo machine ;)
hunger:	Where is that conference?
Aaron:	hunger: canada
Aaron:	montreal I think
stefan:	Montreal, 1.-3. of november.
graydon:	a booth?!
fatjim:	if we're off from the more important topics for a moment; would someone help me build the server?
	Aaron sees graydon sweating
hunger:	Well, that´s too far for me :( I´d like to see graydon doing a demo though.
stefan:	And we have 1 1/2 hour conference to speak !
graydon:	oh jeez, this is going to be some work. we'll need printed material and stuff too. whew..
Aaron:	stefan: that's the easy part though
stefan:	Aaron: huh ?
graydon:	1.5 hours or 0.5 hours?
stefan:	1.5
graydon:	Aigh!
MenTaLguY:	fwiw, you might want to replace that icky mouse pointer that you're currently using for the Berlin demos
graydon:	yeah, true
Aaron:	stefan: heck, I did an hour talk on gnome when I was 14. people actually listened the whole time.
MenTaLguY:	Would the pointer I did be good?
Aaron:	most of them didn't get very bored
fatjim:	(i am missing rules.mk in berlin-tree/config/ ... is this an autoconf problem? )
stefan:	Mentalguy: we need a way to translate png into something understandable by the direct buffer.
Aaron:	fatjim: no, we have no rules.mk
MenTaLguY:	ahh.
hunger:	fatjim: I don´t have a rules.mk either and it compiles just fine.
	graydon has to get going. I need to do some icky complex analysis proofs for tomorrow.
stefan:	Mentalguy: we currently use indexed colors there. I've no ideas how to correct that...
Aaron:	fatjim: does it give any errors
MenTaLguY:	I have no qualms about generating an indexed PNG for you, in that case.
stefan:	graydon: ok. we need to discuss that conference thing...:)
Aaron:	and when was the last time you did a clean checkout
MenTaLguY:	but, yes, that still raises the issue of how to manage the PNG -> directbuffer dealio
fatjim:	Aaron: making clean and config, will report any errors.
graydon:	stefan: yeah.. are we going to, like, roughly present the tutorial?
fatjim:	Aaron: just today. actuall, just as i got on IRC here.
stefan:	mentalguy:" I'm pretty much interested in that too, since then we can set different pointer shapes for different controllers...
stefan:	graydon: let's discuss that tomorrow or at weekend, ok ?
	MenTaLguY hrms
graydon:	stefan: yeah, ok. as soon as I get this damn problem set done! :))
MenTaLguY:	stefan: so, what exactly are the requirements for the conversion, and how is the pointer currently implemented, exactly?
stefan:	mentalguy: since Focus Management works, I could simply add a focus->setPointer() method which is called whenever the pointer enters a controller...
graydon:	ok. see y'all later then.. someone logging? I'm saving my log..
fatjim:	Aaron: never mind.. it seems to have fixed itself now. Not sure what i did to break or fix it. thanks though!
apt:	de rien, fatjim.
stefan:	graydon: yes, I am, Tobias is too.
hunger:	graydon: I´, logging.
stefan:	graydon: bye !
graydon:	ok. bye.
hunger:	graydon: Bye!
jon_taylor:	graydon: later
fatjim:	ta-ta.
MenTaLguY:	bye graydon.
stefan:	mentalguy: look into DrawingKit/openGL/Pointer.[hh,cc] to see how it's done now. No openGL, pure speed. We need to make that class understand our Raster format (PNG).
	MenTaLguY nods thoughtfully
MenTaLguY:	I need to update my tree.
stefan:	we do the direct buffer trick simply to get a 'safe under' behavior so when moving the pointer we simply repair the old region the pointer was and then draw it over the new region.
Aaron:	hey, ah, they don't have you guys listed as an exhibitor
stefan:	Aaron: it's pretty much new. I got an invitation on monday (probably after the interview).
stefan:	Aaron: they promized me any support I wanted.
MenTaLguY:	When is the conference again?
stefan:	1.-3. of November.
stefan:	Montreal.
Aaron:	but your icon is on the fromt page, and the new says you accepted an invitation
Aaron:	will the talk be in french or english?
stefan:	Aaron: yeah, that's quickly inserted in an html page :)
	MenTaLguY hrms
stefan:	Aaron: depends, I could speak both but I'd prefer that Graydon does it. I feel his speaking abilities are much better.
MenTaLguY:	If you guys want music for demos or something, I might be able to track some stuff.
Aaron:	does graydon know french? ;)
Aaron:	MenTaLguY: graydon is a dj ;)
MenTaLguY:	Heh. Never mind then :P
stefan:	Aaron: now. But most talks are in english (Stallman, Raymond, Shaver...)
stefan:	s/now/no/
Aaron:	I am doing a dist-upgrade in hopes that it will fix my system for berlin
	Signoff: jon_taylo (Ping timeout for jon_taylor[198.95.38.66])
stefan:	Anything else anyone want to bring up ?
MenTaLguY:	ah, cvs update finally kicked in.
	MenTaLguY hrms
_jwmoore:	unless anyone wants to discuss xml
MenTaLguY:	I did have something, actually, but I can't think what it is now.
	jtaylor (jtaylor@198.95.38.66) has joined channel #berlin
MenTaLguY:	Ohh, yes, xml would be good.
jtaylor:	ahh Linux much better \|->
MenTaLguY:	rejon
fatjim:	Yes; I know it's a long way off, but when do you think that basic tools will be usable? I mean, IE, a terminal and a clock.
stefan:	jwmoore: good point !
stefan:	fatjim: IE ?
MenTaLguY:	The clock might be easier than the terminal at this point in time; I dunno.
stefan:	yes.
	hunger shivers thinking about IE...
MenTaLguY:	tobias, I believe he meant "i.e."
stefan:	:)
	MenTaLguY thinks
fatjim:	stefan: IE== in example. Not Internet Explorer! :)
MenTaLguY:	(to diverge for a second: what would be a good name for a Berlin clock app?)
fatjim:	MenTaLguY: how about "clock"? too many things in linux have meaningless cool names.
jtaylor:	bclock? like xclock
Aaron:	DSSSL, mozilla, and registrar, and how they will relate? has that concept evolved at all recently?
MenTaLguY:	no, let's not do the b-prefix thing.
stefan:	oh no, please not a set of bxxx tools !
jtaylor:	heheh why not? is this a FAQ? \|->
Aaron:	if we don't do b things, it's namespace pollution, and we go in /opt
MenTaLguY:	tg? for taktgeber?
hunger:	Any famous clock tower in berlin/prague/moscow?
Aaron:	and I can't make debs ;)
stefan:	Well, I'm constatnly looking into different mozilla libraries (necko, gecko etc.) to see how they do it. Yet I find I get better inspiration from ACE
MenTaLguY:	or, if you must do the b thing, btg?
jtaylor:	london has "big ben"
Aaron:	hunger: big ben
MenTaLguY:	bigben ... hrm.
MenTaLguY:	dunno.
Aaron:	!search bigben
_jwmoore:	what's ACE?
stefan:	bigben starts even with two b ! :)
Aaron:	ACE is a really cool, legendary comm lib
hunger:	Hmm... do we have a library we could call london left?
dpkg:	Aaron: alas, bigben is not in any package :-(
MenTaLguY:	how about "zeit"
MenTaLguY:	?
stefan:	ACE is from Doug Schmidt who gave us TAO.
stefan:	mentalguy: hehe.
MenTaLguY:	I think I like zeit.
Aaron:	what is zeit
MenTaLguY:	"time" in German.
stefan:	it's a research project which produced lots of good papers and interesting patterns.
fatjim:	MenTaLguY: I like that. :)
pfred:	much cooler than Uhr ("clock")
	MenTaLguY hrms
stefan:	XML:
MenTaLguY:	zeit might be a good opportunity for me to properly learn Berlin app coding.
MenTaLguY:	anyway, yes, back to XML.
pfred:	what will we be using XML for? the registrar or the interfaces?
stefan:	I think an XML parser will be quite ubiquitous in berlin.
_jwmoore:	are people wanting something like XPFE?
hunger:	What is XPFE?
stefan:	There are a) file formats based on XML (like svg)
_jwmoore:	or whatever it is called that mozilla uses
MenTaLguY:	pfred: the actual registrar backend is probably going to be a database of some sort (it IS pluggable/replacable, though)... there are tools to export/import sections of the tree as XML for hand-editing and other such fun.
MenTaLguY:	XPFE isn't directly related to Mozilla's insanely heavy use of RDF to construct the application interfaces
MenTaLguY:	I don't think, anyway.
stefan:	b) we might want to do something similar to mozilla, i.e. read in full interface descriptions from XML files. User add their 'themes' in terms of stylesheets and you get a scene graph out of it for your application.
	MenTaLguY nods thoughtfully
fatjim:	stefan: I think this is a good idea. It will make berlin a good target for multi-device apps (for desktop-sized screens and for PDAs too..)
MenTaLguY:	actually we should probably adopt the same format Mozilla uses for that, maybe with some adjustments to break the dependency on Javascript
pfred:	In fact, before I looked at the code, I thought applications created their interface via xml, which was interpreted by the berlin theme.
fatjim:	MenTaLguY: I think their format is very biased towards desktop interfaces (windows, menus, etc..) and would not be easy to adapt for, say, a newton-type device.
MenTaLguY:	hrm, stefan, where was the pointer code again?
stefan:	I think we shouldn't restrict berlin clients to use xml. But it would be a nice feature.
fatjim:	..or a television set-top box.
Aaron:	stefan: sounds inefficient...
MenTaLguY:	fatjim: perhaps. I haven't thought about it that carefully.
stefan:	mentalguy: Drawing/openGL/Pointer.[hh,cc]
MenTaLguY:	thank you.
apt:	no problem, MenTaLguY.
	MenTaLguY blinks
MenTaLguY:	there's an infobot in here?
Aaron:	MenTaLguY: yeah
MenTaLguY:	(well, I guess why not :P)
fatjim:	stefan: why not restrict apps to building themselfs with xml?
Aaron:	MenTaLguY: same one as #debian
Aaron:	fatjim: slow!
MenTaLguY:	fatjim: it's not suitable to all applications
fatjim:	Aaron: not really. it happens once for each app. and could be cached.
MenTaLguY:	fatjim: and there's no real reason to.
MenTaLguY:	fatjim: no reason for that restriction, I mean. It'd mean a lot more work to prevent people from doing it other ways...
Aaron:	it just gives a way to hook per-node settings from the scene graph into registrar. at least, that's the way I understood it
fatjim:	MenTaLguY: I think there is. (just me maybe?) Portability and support for the future are tenets of the project, no?
stefan:	fatjim: we are in an early phase of development. Now we have lots of possibilities to go ahead. Why restrincting ourselfs ? If it turns out to be used 99% of the time, that's just fine.
fatjim:	stefan: good point.
Aaron:	stefan: am I right?
MenTaLguY:	fatjim: I don't see how we gain anything by adding that arbitrary restriction.
MenTaLguY:	fatjim: we get both of those from CORBA anyway.
stefan:	Aaron: yeah, that's another use of it.
fatjim:	MenTaLguY: we gain in that the apps will grow to "fit in" with newer interfaces.. no hacks like MS pen-windows, etc..
MenTaLguY:	... again, we get that with Corba anyway, as you upgrade the standard widget implementations.
thim:	the drawingKit provides portability to things other than desktops, right?
stefan:	An argument against the use of mozillas dialect:
MenTaLguY:	theoretically, yes.
fatjim:	i'm thinking on a higher level than widgets.
MenTaLguY:	wow. The pointer code is so ... simple ...
Aaron:	MenTaLguY: which code are you talking about?
stefan:	mozilla uses current GUI standards to define 'standard' widgets. I think we can with our radically new approach just experiment a lot with how widget and the whole desktop metaphor could be. So using only known semantic entities is restricting too.
MenTaLguY:	there's no real breakdown into widgets... it's all a soup of components, some of which can at least be visually identified as containing or being widgets
Aaron:	thim: everything is modular and location transparent ;)
stefan:	thim: yes.
MenTaLguY:	Aaron: Drawing/openGL/Pointer.cc
jtaylor:	OK, maybe I'm dumb but what's with the .cc and .hh extensions?
MenTaLguY:	C++.
stefan:	mentalguy: sure, it's simple. What did you expect to fine there ?
MenTaLguY:	there are three common conventions:
stefan:	s/fine/find/
hunger:	I´ll go to bed now. I´ll keep the computer running to get a complete log.
thim:	fatjim: how do you specify interface constraints? e.g., I need to be able to input certain information. On desktop the best thing is a list of radio-buttons, but on PDA I might want multi-select box or something else?
hunger:	Bye guys!
stefan:	hunger: I'm logging.
MenTaLguY:	.C/.H, .cc/.hh, and .cpp, .hpp
Aaron:	jtaylor: just another convention
MenTaLguY:	the middle one is the most common in modern Unix development.
stefan:	mentalguy: we seem to use .cc/.hh
MenTaLguY:	.C is somewhat older, and little-used now.
fatjim:	fatjim: exactly. could we design a description format and a parser-backend that would turn that into a usable interface, no matter your metaphor?
MenTaLguY:	(largely thanks to the proliferation of case-insensitve filesystems)
apt:	pas de quoi, MenTaLguY.
Aaron:	MenTaLguY: also .cpp and .h, along with .cxx and .hxx
MenTaLguY:	oh yes... forgot about .cxx
fatjim:	.er .. that was for thim.
hunger:	I know. But I don´t pay neither for the access to the net nor for the power the computer uses, so there is no real reason to turn it off now ;-)
MenTaLguY:	apt, forget .C
apt:	i didn't have anything matching .c, MenTaLguY.
stefan:	thim: good Question: one of the TODO items I wrote is just that: figure out sensitive abstractions for widgets (in terms of what they do, no look !)
thim:	fatjim: seems like there ought to be a paper on this, somewhere....
jtaylor:	MenTaLguY: OK that makes sense
MenTaLguY:	jtaylor: only to the limited extent that a more or less completely arbitrary convention can :P
fatjim:	thim: I've been looking around for such things all year.. nothing found.
thim:	fatjim: mebby we can write one, if we figure something out.