Logging Started : Sun Jun 14 11:49:16 EDT 1998
toddf:	hrm, when would that b e relative to now?
	RangeRick (syntax@1Cust25.tnt1.bloomington.il.da.uu.net) has joined channel #ggi
graydon:	Hey rick
RangeRick:	howdy
toddf:	hrm, reladed the zone now .. helps lots .. duh .. I forgot to do that .. thanks, core!
core:	graydon: i will let you log the session, i have a stupid appointment in exactly 1 hour [but i'm not really needed for libggi2D/gwt etc, more for coordination and making sure the server worked]
core:	toddf: you're welcome :)
	graydon is already logging.
core:	okay, well, shall we start? :)
graydon:	anyone having trouble accessing the GGI cvs server?
	fries (~todd@lighthouse.fries.net) has joined channel #ggi
	Mode change "+o fries" on channel #ggi by core
graydon:	It's giving me a delightfully weird error
Macarena:	Graydon: Had on friday, but all well again since saturday.
tan:	graydon: I've no problems
core:	graydon: there were some problems early this week related to my stupidity of managing domains, but now it should work
	Signoff: toddf (Leaving)
Macarena:	graydon: What happens ?
ortalo:	tan : why do you need to "fake an API" change in ggi2DOpen ?
graydon:	cvs server: failed to create lock directory in repository `/projects/ggi/cvsdevel/CVSROOT': Permission denied
	jws (joe@pandora.earthlight.co.nz) has joined channel #ggi
graydon:	cvs server: failed to obtain dir lock in repository `/projects/ggi/cvsdevel/CVSROOT'
ShadowX:	graydon: hope you have a right CVSROOT
graydon:	:pserver:guest@cvs.ggi-project.org:/projects/ggi/cvsdevel
	graydon was using it fine up until, erm, maybe friday night (?)
core:	graydon: hmm (you should use todd's anonymous repository in the USA, but..)
fries:	heh.
core:	i know where that comes from, but i don't know why it would do it again now :)
fries:	graydon: does it abort at that point or wait and retry?
graydon:	whatever. Someone who is authoritative, give me an email address and I'll resolve it afterwards. It shouldn't hold up a meeting ;)
fries:	graydon: I think core has his CVSROOT setup so you can't get it
core:	graydon: does it work now?
tan:	ort: you mean "API change"? -> to load the libs
fries:	graydon: todd@fries.net :-)
core:	graydon: i manage the repository (i'm Emmanuel)
graydon:	core: yeah, working fine now. thanks
ortalo:	tan: yes, but why at this time (it should n't be triggered by libggi?)
core:	graydon: no problem :)
core:	graydon: what are you doing actually? cvs checkout degas?
graydon:	just cvs update on degas
tan:	ort: no. the libs must loaded on ggi2dopen so that you start drawing after the call
core:	graydon: ah, hrm, okay. well it will work now :)
fries:	graydon: the prob is you must 'cd degas; cvs update' to do that
Macarena:	ortalo: Done on purpose to keep things flexible.
core:	anyway - Andreas, Graydon, lead the path.
fries:	graydon: otherwise you 'grab' everything ELSE in the repository besides degas
fries:	which includes CVSROOT
ortalo:	tan,mac: okay.
graydon:	ah. ok
Macarena:	O.K. - as we don't have many really GGI-related issue, I'll leave it to graydon, which probably knows the GGI<->Berlin things best - right ?
graydon:	Is uwe here?
Mat:	Nope
fries:	I don't see him as uwe
graydon:	drat
core:	graydon: we wish.. he'd be useful for mesaGGI.
fries:	am I wrong? I thought uwe also did dosemu?
Macarena:	graydon: I can probably help out a bit here ...
graydon:	the next major issue for me is to get mesaGGI moved up to current version numbers so that someone other than myself with my screwy old libggi can use berlin..
fries:	or am I thinking of another person with the same name
tan:	fries: IIRC he did a allegro/dos port
graydon:	iirc it was uwe who did the mesaGGI patch
core:	Uwe Maurer did mesaGGI, yes
tan:	graydon: me too. I know much of the mesa internals...
Macarena:	graydon: right ...
core:	and apparently andreas beck (macarena :) and thomas tanner (tan :) can help you too.
graydon:	cool, so I guess I have enough people here to ask for criticism about the idea of using mesa as an imaging layer for berlin, rather than libggi2d + libgwt ++
	bri (~root@uislr1p6.umassp.edu) has joined channel #ggi
	Mode change "+o bri" on channel #ggi by core
ortalo:	graydon: how do you use berlin currently without libgwt ?
core:	hello brian :)
bri:	Hi,
fries:	graydon: my thoughts would be 'wow, cool!' .. then we can have true 3d window managers that rotate cubes with applications on each side, etc ..
graydon:	ortalo: yes, the most recent version in CVS speaks to mesaGGI, which in turn goes to libGGI
	bri yawns, having just woke up
core:	graydon: if you mean, even for 2D, well, irix does that, and their desktop gets everyone to pant
RangeRick:	:)
ortalo:	so mesaGGI manages the windows ?
graydon:	ortalo: yes.
ortalo:	I guess then you don't have a window for each widget ?
graydon:	ortalo: the only thing I'm having difficulty with was pointed out by the mesa author, which is that doing traditional rectangular clipping is kinda expensive
graydon:	ortalo: no, I have a mesa display-list for each widget, which is in turn composed of calllists() calls to its children.
fries:	graydon: what is non-traditional that isn't expensive?
tan:	graydon: opengl is well suited for 3d and some 2d, but IMHO not for WinSystems
graydon:	ortalo: it turns out to be very simple to code that way :)
graydon:	tan: ok, elaborate. Why not?
ortalo:	garydon: you mean from the application level ?
fries:	tan: is that because of older hw? new accelerated hw will make it easily possible
core:	graydon: GL doesn't really have provisions for moving regions without redrawing them, etc, though.. not?
graydon:	ortalo: no, the application has no clue it's using openGL.
tan:	graydon: it lacks arc/circles/ellipses, font handling
ortalo:	graydon: then why do you say it is easy ?
graydon:	ortalo: it's easy to implement widgets that way, in side the display server.
core:	fries: the hardware is here (ie. my SGI Crime board :), but the price is the showstopper
tan:	graydon: IMO QuickDrawGX is better for GUIS
graydon:	tan: erm, it has curves of all sorts, and the fonts we are working with the gltt guy to add.
Macarena:	graydon: Are your widgets "real-3D", then ?
graydon:	tan: ah, but there is no free quickdrawGX :)
tan:	graydon: yes, but a spanish guy wanted to create one IIRC
graydon:	macrena: well, right now I'm playing with borrowed code from moonlight's GUI, which just simulates 3d with pixmaps and lines, like most WMs.
fries:	core: heh. I'm just thinking of the future. How long will it be before someone comes out with, instead of a traditional 2d with shading to make it look like 3d windowing environment, a windowing environment you can navigate in 3d and rotate applications in 3d and have a button cube you can rotate, etc ..
graydon:	tan: he did. I just haven't seen any code.
tan:	graydon: i suggest you use opengl for now, but later quickdrawgx or other apis...
graydon:	tan: the entire decision was based on availability of code (and hw accel chips), not necesarily technical supremacy.
core:	fries: as long as it will take to make it usable. 3D windows are fun, but aren't very useful. think about 3D platform games, and how long it took them to make them as playable as 2D ones
graydon:	tan: yeah, I have no problem there. Just, y'know, some guy asked why we were bothering to reimpliment all this stuff that's already available in mesa, and I had no good answer why not.
	Signoff: asvogler (Leaving)
	asvogler (~duff@vortex.hawo.stw.uni-erlangen.de) has joined channel #ggi
tan:	graydon: i mean, don't you fix to a certain api
	Mode change "+o asvogler" on channel #ggi by core
ortalo:	graydon: how do you manage windows overlapping, exposure events, etc... ? (Don't know Mesa API very well.)
graydon:	core: agreed. I haven't seen a strong motivating example for "rotating things in 3-space" GUIs yet.
Macarena:	ortalo: I suppose by just arraging the planes in 3D space ?
fries:	graydon: here's one: 1st guy who does that sents the precedence for others and goes down in history books??
tan:	graydon: that also means that you must add networking support to ggi
graydon:	tan: the api we export to apps is "warsaw", which is more abstract than a given imaging model.
core:	graydon: yes, that's what i mean. if the learning curve is steeper and it's less usable, there's no point.. that's why all those movies with people using sensitive gloves to move their files in 3D made me laugh :P
tan:	graydon: ah. ok.
graydon:	fries: sure, I just literally mean I have *no ideas* for 3d components.
fries:	tan: what makes you suggest networking for ggi?
core:	i like to have a global vision on one desktop, without having to shuffle things around, but that's just me.
core:	tan: ggi doesn't have to be network transparent, it's just the local rendering system. i don't know much about Berlin, but it uses corba, which does the network-transparent stuff.
graydon:	tan: warsaw is in terms of "widgets" -- although we'll probably add in a set of objects for talking to the imaging api directly as well, in which case yeah, a change of underlying api would break those apps which talked to OpenGL.. can't help that.
fries:	greydon: I had this dream once. it had a stadium type of picture, but wasn't detailed enough to see seats, etc .. and you could fly around in it, and as you moved your mose over the various sections they sunk in with a 'kuh-thud' and highlighted themselves .. and you swirled around and saw on the horizon tons of other things to interact with
	weigon (weigon@pppm09.kiel.netsurf.de) has joined channel #ggi
core:	fries: but if it takes half an hour to get to your files, that's annoying ;)
core:	creating a GUI is an huge work - you can't set many things in stone. some people will want the 3D flying widgets, and some others just the plain desktop. you have to implement both somehow, i guess.
tan:	graydon: I see
fries:	core: of course shortcuts and useful interaction would be a goal .. but for me to be able to 'back up' and have everything shrink in size would be useful in and of itself!
	Mat is away: (Auto-Away after 10 mins) [BX-MsgLog On]
	Mat is back from the dead. Gone 0 hrs 0 min 5 secs
core:	programmers setting things in stone has led to many rewrites.
tan:	graydon: are there any problems with mesaggi?
fries:	core: of course shortcuts and useful interaction would be a goal .. but for me to be able to 'back up' and have everything shrink in size would be useful in and of itself!
graydon:	fries: the intent with berlin is that if the user is a newbie, or has the horsepower to do that, they can swap in components which act that way, and anyone asking for a window just hapens to get a pane on a 3d stadium floor..
fries:	graydon: ok now I am very happy
RangeRick:	:)
core:	graydon: sounds like something i am working on [unrelated], so i like the idea.
fries:	graydon: so you would allow windows to be dealt with as true 3d components, with appropriate 'distortions' for seeing them at angles and such?
graydon:	'course, the guys who still use vi and /bin/sh at work will not want that, and so (hopefully) they can load up "ultraminimalWidgets" which all respond to single character commands, and disable the mouse entirely :)
ortalo:	graydon: what are the things that ANNOY you when using MesaGGI as the drawing layer ? You seem pretty happy from that choice in fact currently so... What are the drawbacks you suspect ? (hint: maybe some performance drawback ? [other hint: maybe an HEAVY])
graydon:	fries: that's done by OpenGL
graydon:	ortalo: I am very concerned about performance issues, yes.
fries:	graydon: only because everything is drawn by using mesa widgets .. coolies
graydon:	ortalo: one of the things I wanted to discuss with people here who perhaps know things abotu video cards is how to achieve performance.
core:	graydon: do you still intend to use [mesa]GGI as your lowlevel API everywhere?
graydon:	core: until suitable arguments against it are presented, I think so..
core:	graydon: ok :)
Silk:	anyone have an idea how does software-emulation-mesaggi compares in terms of speed to software-emulation-mesaglx?
RangeRick:	hrm... maybe more useful for more people would be to be inside a cube, the current "selected" desktop would be in the back wall, and other virtual desktops would be along the sides, top, and bottom :)
graydon:	ortalo: one nice thing about OpenGL is that you "compile" display lists before running them. Literally, the API has a "compile" mode you throw it into before calling draw commands.
fries:	graydon: let's say, I have a 386 with 256k mem video hardware. will there be something avail to allow it to be usable like 'turn off all cool 3d effects and shading' widgets?
RangeRick:	but either way, that's quite a bit in the distance right now :)
core:	silk: Steffen Seeger did hand-optimized code that ran in circles around any other implementation, but it never got commited. we'll ask him..
ortalo:	The problems I see is when doing multi-windowed app., or exploiting the regioning code (e.g. to setup a word processor appearance.)
graydon:	fries: yeah, you should be able to fallback to something very mundane == easy on the CPU
tan:	core: i helped him. i modified mesa so that we can include his code. that's why i know the mesa internals ;)
ortalo:	(NB: But, here I want to be the devil's advocate. :-)
core:	yes - an operating system or windowing system should help you to work, not hinder your system :)
fries:	graydon: ok so we have a terminal emulator .. so up 'grows' a 3270 terminal complete with keyboard and display that one could rotate around and look at for grins .. and then sit infront of and start interacting with .. heh ..
graydon:	yeah, steffen was talking about run-time relinking of parts of mesa, in order to collapse branches and remove checks.
core:	tan: ah, okay, good :) any clue if he's going to commit that sometime soon?
RangeRick:	fries: cool, but rather useless :)
Silk:	core: yes, I suspect there's a lot of room for optimisation in Mesa's soft-primitive code (which is written in C).
fries:	rangerick: I've got 'cpu/hw accellerated 3d' on the brain today
core:	graydon: yes, i saw that working about 6 months ago (not running on mesa at the time)
RangeRick:	although it may be cool to flip a window over and have configuration on the back :)
graydon:	and the "compile" phase supports that very nicely. You get back a handle to code which does your drawing mode, and nothing else, so it should run very fast.
fries:	range: hehehe
core:	silk: steffen wrote self-recompiling code for it in assembler, it was TIMES faster
tan:	core: no. AFAIK he's quite busy now and it has low priority for him right now.
ortalo:	Have you tried to draw 300 overlapping rectangles in a window and then show/hide the window ? What is the drawing time ?
core:	tan: what is he busy with?
tan:	core: kgi and xaa AFAIK
graydon:	ortalo: I have been unable to benchmark mesa at the moment, as any numbers I obtained would be terribly depressing.
core:	tan: ah, ok.. we haven't got news from him for a long time, except some answers on the list.
graydon:	ortalo: reason: I am running uwe's original patch, which only uses putpixels()
tan:	core: wait! we don't now whether this technique is really faster
graydon:	ortalo: and then I am displaying *back* into the X target so I can develop next to xemacs
graydon:	ortalo: so it's miserably slow.
ortalo:	graydon: okay. So, in fact personnally, the only problem I see with Mesa is that perf. problem.
graydon:	ortalo: me too.
tan:	core: s/now/know/
ortalo:	But in fact, you know, I like the whole idea.
core:	graydon: there's a lot of room for optimization in mesaGGI- that's why i sort of hoped Berlin would work on it :)
graydon:	ortalo: but -- ever used a voodoo chip?
	graydon makes an evil grin
core:	graydon: voodoo is terrible at 2
core:	s/2/2D/
fries:	ortalo: especially when there's options for low cpu/hw accel (or no hw accel) assistance situations
ortalo:	However, we should have a provision for getting rid of the heavy Mesa layer, no ?
graydon:	core: is it? oh well.
core:	graydon: yes, we have a libggi target for it :)
tan:	core: the only bigger optimization we can make is hardware accel
core:	graydon: unless you draw your windows using texturemapped triangles ;)
graydon:	ortalo: I am hoping (and the mesa author says it's totally possible) for mesa to basically "become" a simple 2d layer when need be, simply by changing certain settings.
ortalo:	Could you have an "abstract" drawing layer (subset of Open/GL) that would be satisfying enough to implement some specific part of the API ?
core:	tan: bigger optimization than what? steffen's code maybe, but not current mesaggi code.. it's C using putpixels()
ortalo:	graydon: so mesa could provide such subset ?
graydon:	core: I intend to work on it, but I set berliners a deadline of having a working architectural demo (with no performance guarantees) by the end of august, so we could show it off.
core:	tan: and the 3D renderer i wrote for ubisoft, was assembler using fpu and cpu in parallel (for derivated means), it was at full frame rate on a stock p75 three years ago.. so.. there's always room for optimization.
Macarena:	core: AFAIK the latest patch was a bit better using PutLines and such, but I may be wrong ...
graydon:	ortalo: mesa is quite abstract already. What do you have in mind?
core:	graydon: but you won't show it off with the current slow mesaggi code..?
core:	macarena: you're probably right, i haven't followed mesaggi much :)
ortalo:	What I have in mind is: the pure 2d parts of Berlin could rely on some user-defined drawing lib.
tan:	core: of course. but ggi is portable. I hope you know what i mean ;)
graydon:	core: we'll show it to people who are willing to look past the speed issue. I.e., bruce perens asked me for a demo real soon.
fries:	ortalo: but then you take away the possibility to do 3d stuff if hw does it
ortalo:	If Mesa can provide this part, very well, it will save work. If not, we could complement it.
core:	tan: doesn't mean we can't write hw-specific code where relevant :)
fries:	ortalo: you did hear mesa was going to have a 2d layer implementation, right?
core:	graydon: i'll be curious too.. :)
ortalo:	Howver, the problem is that Berlin should be able to use full Open/GL when feasible (or when the user wants to show-off).
core:	graydon: i just meant that if you want a "general public" demo, you need to resolve the speed issue
ortalo:	How could you combine the two requirements in Berlin ?
graydon:	ortalo: it depends what you want in your 2d layer. If you want nurbs, polygons, alpha channels, etc. then you get them in mesa already.. It'd be a bitch (and possibly redundant) to reproduce all that in a 2d-only mode when you can just optimize out in mesa.
RangeRick:	core: I think this is more of a "proof-of-concept" demo :)
graydon:	core: indeed, and for that, we will need KGI
core:	rangerick: yes, i understand that :) but speed is something you can hardly get past (trust my experience ;)
ortalo:	NOTE: I would be _very_ happy to rely on Mesa (I'm not a workaholic.. :-)
RangeRick:	:)
graydon:	or fbcon, if it's any good for acceleration :)
core:	graydon: yes, i can imagine - the new KGI has been moved in the repository, once it is nailed down and all drivers are ported (one time for all), it will be fine :)
core:	graydon: fbcon doesn't accelerate anything, but it works (as of today) with any VBE 2.0 board, plus all KGI drivers when Andrew is done
Macarena:	Hmm - Actually I though Berlin was intended a very "lightweight" thing ... X makes me mad with its 12MB memory footprint ... do you think you can keep size small ?
core:	graydon: and it'll be in the main kernel sometime soon :)
Macarena:	graydon: fbcon ends at blitting. But we can try to extend it :-)
core:	macarena: yes, that's what I was expecting Berlin for, mainly - PDAs and such :)
graydon:	core: you can detect certain things in mesa, like which projection matrix you're using, and if you're in orthographic mode, and if your viewport coordinates exactly match your modelling coordinates, and if these conditions are met, your calls suddenly turn into pixel pushing 2d calls.
	Macarena grins at core with a knowing smile ...
	graydon saw the itsy as well, y'know.
RangeRick:	pilot-berlin? :)
tan:	graydon: btw: what about printing support in berlin?
RangeRick:	hehe
	core returns the smile to macarena (i'll mail you, honest! i was finishing the docs when 5 PM rolled in :)
core:	graydon: ah, i see. that's smart
graydon:	an app which speaks to berlin is actually asking for "widgets", having no idea what they are (assuming it does no direct-imaging)
core:	graydon: i guess mesa will only load its 3D components when these conditions aren't met then (for the memory footprint problem)
graydon:	core: that'd be nice, but I don't know its guts well enough.
core:	graydon: i suppose it needs some butchery to do that, but..
Mat:	graydon: any plans to implement "X over Berlin" ? *duck*
graydon:	core: so far the memory footprint is ... hang on ...
core:	mat: as useful as "linux over win95" :)
tan:	core: AFAIK it's not very easy to split mesa into 2d and 3d
ortalo:	IDEA: What about implementing libgwt using Mesa ? If we furnish another implementation (faster or lightwight) we might help wrt perf. ?
core:	tan: i'm just trying to imagine how Berlin can take less memory than X, loading full mesa, widgets etc :)
Silk:	tan: it only takes a few state changes to start drawing in orthographic mode
Macarena:	Mat: shouldn't be a problem, if we can make a "Berlin target" which opens a window that contains a single 2D drawing widget - we can run Xggi on it ...
fries:	core: um, x apps would HAVE to have some way to display themselves .. otherwise nobody would use it
graydon:	grr. doesn't like staying up at the moment, can't get a mem useage number.
ortalo:	In fact, my brain-problem currently is that I don't see what the mesa-guy wants to do to split-out a 2d API for Mesa (with windowing support).
fries:	mac: heh. or you could do the xserver kind that windows has and do an optional per-window wrapping with the berlin wm
core:	fries: i know :) i guess they'll write some xlib stub
graydon:	core: there's a few approaches you can take for X, none of them terribly satisfactory
Macarena:	core: Someone is trying that for Wine. I am in contact with him ...
graydon:	core: you can have 1 X server window, and have every X program live inside it.
core:	graydon: source compatibility would be fine for me, but i guess most people will want runtime compatibility :)
	Mode change "+o weigon" on channel #ggi by Macarena
graydon:	core: or you can try to represent each X window structure as a separate berlin window
core:	graydon: c'mon, X is not that good, but flexible enough to have its windows displayed in Berlin windows :)
graydon:	core: or you can try to finagle an xlib which speaks to berlin in secret on the backend
fries:	graydon: hehe. my thoughts exactly
fries:	graydon: that would be the 'optimized' approach .. to get it working, though, I think your original idea would be 'X in window'
graydon:	core: in which case, it's easier to do with something at the level of, like GNOME than xlib
graydon:	or rather, GTK+
graydon:	cause it's already an OOP widget-based API
core:	i guess yes :)
	Signoff: bri (Remote closed. [0kb/9pks(0q)] [31kb/258pks(5q)])
graydon:	I mean, I don't have perfect answers for a lot of weird problems
	bri (~root@uislr1p8.umassp.edu) has joined channel #ggi
core:	you don't have to either; first get Berlin to work
core:	when it works, getting legacy X applications to work is a secondary problem
	Mode change "+o bri" on channel #ggi by Macarena
graydon:	and there's *lots* of weird problems to face -- how to get a pilot to even *contain* NURBS trimming code, etc :)
core:	graydon: that's what i meant, by not being able to set many things in stone
ortalo:	garydon: You need to have a modular implementation of Mesa I think.
core:	ortalo: my thoughts exactly
core:	if you can't split mesa in components, you can't use it with Berlin, or it will take more resources than X itself
ortalo:	That's what we aimed at: libggi2d, libgwt, and then mesa. (all over libggi)
graydon:	core: I dunno, mesa is 600k.
Macarena:	graydon: So i suppose you are talking to some intermediate "rendering and widget ordering" layer that might be substituteable to have "light" and "heavy" versions ?
core:	graydon: on disk, but not of memory, yes? :)
tan:	ort: I've tried to split Mesa, but no success till now ;((
graydon:	XF86_SVGA is 2.7 megs
ortalo:	tan: why ? (that's the problem here in fact, please elaborate)
graydon:	on disk
tan:	ort: seems that everything depends on everything ;(
fries:	-rwxr-xr-x 1 todd todd 2527232 Apr 26 17:19 bin/XGGI
graydon:	tan: I agree, spliiting mesa doesn't sound too easy. The code is very tightly wound together.
tan:	but on linux thats not a big problem: it supports demand loading
fries:	tan: replace Linux with UNIX and you got it
Macarena:	tan: No - not every Unix does demand paged loading ... argh ... !
fries:	Mac: oooh, ok so I'm wrong. most modern unix'es I'm sure though
core:	tan: demand paged loading slashes performance too
ortalo:	how do the mesa-guys intend to proceed: add a new part with 2d only, or reuse things from Mesa3D ?
graydon:	I mean, GGI has abstracted video driver code from X, and corba abstracts xlib, x proto, and the various X bindings for other languages, so I think we're safe in assuming it'll be smaller than X
Macarena:	s/tan/fries/ ...
ortalo:	graydon: yes but there are still these windowed thingy to abstract away...
tan:	and demand loading only makes sense when the code itself is separated in the binary
core:	ok, the announced appointment is here.. i'll exceptionally leave .. my scope of work is low-level anyway.. :) See you, work well, post the logs :)
core:	tan: right
graydon:	ortalo: hehe. Yeah. Well, if you take the windows out of the windowing system, you get 8 1/2, and that's not the design I'm interested in.
fries:	whoever committed xf86dga display support ... it assumes alot
tan:	bye core
ShadowX:	bye core
graydon:	bye core
	Signoff: core (bye everyone :))
ortalo:	and it is annoying me as a window seems to be rather different from a viewport... (win can go off-screen, resized, be virtual, etc.)
graydon:	in 8 1/2, the windowing system is only a couple dozen KB, but it does nothing, calls the client *very* frequently, and the user can't customize it at all.
	weigon has left channel #ggi
	graydon munches on oatmeal
ortalo:	In libgwt I expected to put a simple way to provide visual independence in fact. (With additional support for overlapping visuals, and managing events.) Isn't it enough for a small thing ?
ortalo:	I always saw libgwt as a layer allowing apps to share one visual. Nothing much more.
graydon:	ortalo: yeah, but share how?
Mat:	I'll be going too. Not like I'm much use anyway :)
Macarena:	ortalo: I think we should definitely continue with LibGWT, as I see need for it in many fields ...
graydon:	you got rectangle multiplexing
graydon:	rectangles with z-order
graydon:	polygons
graydon:	curves
graydon:	alpha channels
tan:	mac: I agree
	Signoff: Mat (Mat disappears in a poof of smoke...)
graydon:	where does GWT stop, and high level stuff begin?
ortalo:	GWT manages where you are going to draw. Once you start drawing it has done its job.
Silk:	hate to ask this, but how does X do it?
Macarena:	graydon: GWT basically allows to manage and order a bunch of "subvisuals" on a larger main visual.
graydon:	I agree, it sounds good to have a lightweight kit, but what if I want to decorate my windows with semi-transparent vines?
tan:	btw: I think there's a security problem with alpha blending and windows
graydon:	and visuals are rectangular.
Macarena:	graydon: Use an Alpha channeled larger subvisual for the border, which has a smaller subvisual for the contents inside.
ortalo:	graydon: I don't help you with this. ( I agree, this may be a limitation.)
tan:	Is an app allowed to read the contents of an underlying window?
	allanon (allanon@becker2.u.washington.edu) has joined channel #ggi
graydon:	tan: I doubt it
Macarena:	tan: Actually X allows it, so ...
ortalo:	tan: no, why ?
graydon:	tan: there's lots of sticky security issues in berlin tho.. not to claim it's secure :)
ortalo:	In fact, I did not want to put in libgwt things that I was not sure were really belonging to libgwt.
tan:	if you do alpha blending you need to read the contents of the screen.
fries:	graydon: what would it take to make it secure?
Macarena:	tan: I see the problem, but I
Macarena:	'tan: am not sure if we should really do something about it ...
graydon:	fries: an act of god :)
graydon:	fries: no, not really
tan:	of course, if the drawing is done by the server, the app has no access to it...
graydon:	fries: just a lot of discussion and patience
fries:	graydon: so you are saying you can't guarantee the root passwords we type in berlin windows aren't being snarfed? um, that is scary and limits your audience
graydon:	fries: I'm saying I can't *guarantee* it, cause I have no idea what people will plug into berlin.
Macarena:	fries: They can be in X, too ... if they get displayed. How do you think the xv grab button works ...
graydon:	fries: can't guarantee it in X either.
ortalo:	So, with MeTalGuy, we thought it would be best to remain a convenient way of, let's say, splitting the screen into parts. (maybe multiple screen into parts)
fries:	mac: x can be secured. only allow apps that have a magic cookie to connect
graydon:	fries: you can do a similar inflexible security scheme with berlin if you like..
fries:	mac: but graydon just said 'no clue how to guarantee security' in berlin. that scares me and will definately be an issue with OpenBSd which is security conscious
Macarena:	fries: I suppose Berlin will have such functionality, too ...
ortalo:	And, if possible provide windows in a transparent way, so that application would not be aware of the fact they draw in a window.
bri:	A very small SUID server might be acceptable in this case -- no hw access needed, and it could be small enough and simple enough to comb for security holes.
graydon:	ortalo: oy, if it does alpha channels it may be sufficient
fries:	well, if I can somehow guarantee security( if x's is inflexible, ok go for something more flexible, I care not) just that it is secure!
Macarena:	bri: What would we need SUID for ?
graydon:	well, berlin is a userland app, so it runs as you
graydon:	no need to be suid root
fries:	bri: um, the whole point of ggi is graphics w/out suid. better have a GOOD reason to require suid.
bri:	Well actually I guess maybe not, but you'd need an authentication protocol for a non-suid one (with SUID you just check if it has rights on the resources)
ortalo:	mac: alpha channels (from graydon) make me thing that, in fact, we need some lib for "combining" visuals one with each other (either split, stacked, or even mixed)
fries:	bri: terms, for example, need ownership of tty/pty's which atm require suid
graydon:	the only security issue is that, since programs are sharing corba object references, those references can be forged -- you might not be talking to whom you think you are talking to.
graydon:	that's security at the corba level. There is a corba security standard, we just don't happen to have an implementation anywhere.
fries:	I'm just thinking of the day berlin gets popular then there are a series of bugtraq announcements regarding it.
graydon:	fries: everything has security holes. Best we can do is respond to any concernes with a solution.
fries:	graydon: if you plan for security up front, it makes things easier in the long run cuz you don't have to hack ontop of hacks to make it so
graydon:	fries: I know the OpenBSD guy will probably be able to find a million security flaws in our program
graydon:	fries: but he can find all the same flaws in, like, PINE -- it's just a single user process.
fries:	graydon: but will there be a million security fixes?
graydon:	fries: I see no reason to leave a security hole open :)
fries:	graydon: then that is good.
tan:	graydon: with a good design you avoid most sec holes. otherwise fixing them will be a lot of work...
fries:	graydon: here is a good question. do you do 'if(open() < 0)' or 'if(open() == -1)' ?? .. that is a good example of poor coding .. hehe ..
Macarena:	O.k. - back on topic - what doe Berlin need most from GGI _now_ ? A Mesa GGI that runs with the most current Mesa ? Acceleration ?
fries:	oops we have a topic.
graydon:	fries: yes, I know, and I'm sure we'll be subject to lots of security audits, but I'd simply be *lying* to you if I said my code, or my design, was entirely secure. I Do not know, nor do I have the expertise to find out..
	bri forces himself to put down cigarette lighter after creating a small disaster with his latent pyromania
graydon:	macarena: yesh.. a mesa that runs on the current KGI would be lovely.
Macarena:	graydon: What version of Mesa would you like ?
graydon:	macarena: one of the 3.0 betas, I guess the latest
	Signoff: Silk (I'm outta here!)
tan:	graydon: no problem. AFAIK uwes port runs with 3.0beta4
graydon:	tan: yeah, it just doesn't happen to work with current libggi.
graydon:	tan: should be a small matter though
graydon:	tan: I'm planning to do it if nobody else feels up to it :)
Macarena:	graydon: O.K. - I'll talk to Uwe - tan - please EMail me, if you'd like to work on it, too. Seems I got to quit now ...
Macarena:	CU folks !
graydon:	see ya
tan:	graydon: ok. I'll help!
bri:	bye andy
	Signoff: Macarena ( )
	ZinO (peter@hiro.idonex.se) has joined channel #ggi
graydon:	tan: cool.
ortalo:	So, it seems we are mostly done, no ?
graydon:	tan: I got uwe's patch working on 0.0.9 in just under an hour, so I don't imagine it'll be too hard
graydon:	ortalo: I have nothing else much, nope..
ortalo:	When I will have something ready with libgwt, I will show it. We'll see if it can be useful to berlin then
fries:	graydon screenshots?
tan:	graydon: porting will be easy when I got my libggi2d ported.
fries:	:-)
bri:	anyone care to stick around and answer a few questions on evstacks?
graydon:	fries: right now a screenshot == a big blank screen
RangeRick:	:)
RangeRick:	fries: I can make one for ya if you want :)
bri:	(or is noone here an evstack pro...)
graydon:	range: we had trouble in the past with people faking screenshots of berlin. I'd prefer to stick to realism :)
RangeRick:	graydon: that's what I mean... just make a black 800x600 image or whatever :)
ortalo:	I have to go also now (some real work left somewhere also :-). Good evening, and see you soon... (with screenshots :-)
graydon:	range: oh, I see. hehe -- did you see the egcs team's screenshot?
	Signoff: ortalo (bye..bye...)
RangeRick:	no... um... I'm afraid to ask, but uh... where is it? :)
graydon:	it's funny -- it's an xterm with : gcc something.c >>prompt.
	tan is just looking over Uwes code and sees that it access the framebuffer directly
graydon:	it has the caption "look at egcs go!"
graydon:	tan: way?
RangeRick:	hahah
asvogler:	got to go. bye
tan:	graydon: core thought that it uses putpixel()
	asvogler has left channel #ggi
graydon:	yeah, so did I -- isn't the "INNER_LOOP" macro a call to putpixels?
	RangeRick has to run. later, all
	Signoff: RangeRick (syntax: Um... er... yeah.)
tan:	graydon: there are two versions: a generic one using putpixel and one using direct access
graydon:	where's the direct access one? (http://?)
tan:	http://home.t-online.de/home/uwe_maurer/ggimesa.htm
graydon:	that's the one I have, the 3.0 patch, right?
tan:	graydon: yep. 3.0beta3
tan:	graydon: the putpixel calls in linear8/15.. can be optimized...
tan:	are there any other issues? i've to leave soon.
graydon:	tan: ooh, you mean the stuff down at the bottom of the patch?
graydon:	tan: no, I'm just bumming around
tan:	graydon: see default/linear.c
graydon:	snazzy.
bri:	can anyone think of a way to do the target overloading yet provide something approaching the efficiency on inlining? How much overhead is in a function call anyway? (I never took a compiler course:)
graydon:	tan: still doesn't call libggi for geometric primitives. We'll see if that's possible :)
fries:	bri: isn't that what the struct->function() pointers are for?
fries:	bri: if an app insists on calling putpixel() for every pixel of a 1024x768 screen, that's the app's fault not ours. if however the guy does a putimage() or whatever the function cal equiv is .. then the app is optimiized!
tan:	bri: or add a function like putpixelS and draw several pixels at once
fries:	tan add? I thought that was in there .. putline() where a line is an array of pixels to put at once, not necessarily the whole width of the screen .. maybe I got the name wrong but not the functionality, I've looked at it before
graydon:	or better yet, invent quantum computing and holographic display, so you can show every possible picture simultaneously, then just collapse the wave function and the display instantly updates. Should be a snap, right?
bri:	I'm just wondering if the generated code does a lot of saving of registers and stuff that wouldn't be necessary on some targets?
tan:	graydon: ;)
	bri2 (~root@uislr1p1.umassp.edu) has joined channel #ggi
fries:	bri: registers are the compiler's arena
bri2:	ok what's the irc command to get the last screen?
	Mozart (Mozart@mozart.windsor.igs.net) has joined channel #ggi
fries:	I just use the scrollbar on my irc app
	graydon is thinking he'll head off, if there's nothing else, and see if he can get mesa to like the new libGGI.
tan:	fries: no. there's no putline function. there are only puth/vline
bri2:	e.g. to see what I missed (and I'm using SIRC which doesn't scroll the whole console :()
graydon:	tan: you'll be around the next few days to talk about this stuff? (you know libggi way better than I do!)
Mozart:	hello there ggi and berlin folks
bri2:	hi
tan:	graydon: better ask Andy. I'm just trying to port libggi2d and there are still problems with the extension scheme
fries:	hey Mozart .. graydon is berlin and he's ready to leave to do work .. :-)
Mozart:	fries: :(
	graydon will stay if mozart has berlin questions
Mozart:	not any question really
Mozart:	but
Mozart:	i've been reading the berlin lists for the last few days with some fascination about the ui
tan:	ok. have to leave now. bye!
graydon:	mozart: oh, well, since there are no real widget interfaces I though I'd just let that conversation unfold into some new ideas. Doesn't hurt.
Mozart:	i cant really add much more than, Put as much configurability into the hands of the user
graydon:	bye tan!
	Signoff: tan (Leaving)
bri2:	bye!
	Signoff: ShadowX (Leaving)
graydon:	ok, I'm gonna bail then. Nice talking to y'all. Feel free to demolish my code with something better :)