| crashcut: | hi :) |
| | jonas [c98ja1@erie.cs.cse.dmu.ac.uk] has joined #berlin |
| jonas: | ehlo everyone |
| stefan: | hi Jonas ! |
| jonas: | seems a lot are in early :) |
| jonas: | whois crashcut? |
| crashcut: | <- spectator ;) |
| crashcut: | i've been fiddling around with povray a bit to make a trailer for berlin |
| crashcut: | ... |
| jonas: | .... |
| stefan: | Jonas: did you play a bit with DrawingKits and such ? What about my version ? |
| jonas: | I got the archive from you, looks pretty good. I've been pretty bugged by coursework lately :( |
| jonas: | a lot of directories in src/ now :) |
| jonas: | whatis src/Figure ? |
| stefan: | Jonas: yeah, understand. I ment in the time before your move. |
| jonas: | Ah, I did simple preliminary work on extracting the drawing into a drawingKit (using GGI), I sent a patch to graydon but it seems it has been imported. |
| jonas: | The most interesting thing was my work on commands and messages |
| stefan: | Jonas: Figure is ment to keep all the real structured graphics primitives (lines, circles, etc.) together with a unidraw port, manipulators, tools, visitors etc. |
| jonas: | started working with out-of-libwarsaw messages and commands (partic. the skeletons) |
| jonas: | Figure, don't really understand. |
| stefan: | Jonas: hmmm, what we want is a nice blending of structured graphics and widgets related stuff. Well, the basic types and algorithms go into the Berlin directory, the widgets into the WidgetKit, the geometry things (incl. Editor framework like unidraw) go into the FigureKit. Well, it doesn't matter that much at the moment, it is a separated Kit which not everyone needs to use, so... |
| jonas: | So the FigureKit (unidraw) is another layer on top of DrawingKit? |
| stefan: | Jonas: historically in Interviews there was a special library (a Kit) for structured graphics. Then came the framework for domain specific editors (unidraw). Fresco seems to have unified both together into the FigureKit |
| stefan: | Jonas: no !!! Figures are dirived from Graphic. That means they use a DrawingKit for redrawing themselvs, they have nothing to do with DK otherwise. |
| jonas: | Ahh, so I can create a circle object instead of telling my drawingKit to draw a circle? |
| stefan: | Jonas: right. The difference is that the circle object is intelligent. It knows all the protocols I implemented in Graphic, it is a real node of a scene graph while a circle from DrawingKit is nothing but a round path filled with a certain color. |
| jonas: | pre-uni, I also did some work on composites - making a composite command for distributing events to "child"-widgets instead of widgets having to check their coords |
| jonas: | also translated the event into widget-space |
| jonas: | pretty simple, but showed me we still need some work on allowing to plug in new messages,commands, etc |
| jonas: | stefan, ok I understand FigureKit now :) |
| stefan: | Jonas: hmm, with respect to event delivery: I think there are two types of events: pointer based or focus based. |
| Jordy: | woops |
| Jordy: | you know i forgot about this meeting |
| Jordy: | oh wait, it's not for 15 minutes |
| Jordy: | bbiab :) |
| jonas: | Jordy: not startd yet, we |
| jonas: | we're just going ahead :) |
| stefan: | Jonas: focus based is simple since the server knows which widget has the focus so which widget should receive a KeyEvent for example. But it's difficult with positional events. Then the (composite) will start a PickTraversal to find the child widget which should receive the event. With this information the parent can send the event to the respective child if it's interested. |
| jonas: | stefan, correct this was compositeClickCommand.so - also showed me how we should change some of our ctors to call parent ctors in order to bind their default commands. |
| jonas: | my compositClick simply bound to all three click and release messages and either sent it on or called a "ImTheRecipient" command |
| stefan: | Jordy: are you already logging ? If not, could you do it ? |
| | Alain [Woody@66-107.dr.cgocable.ca] has joined #berlin |
| crashcut: | testbla |
| stefan: | Alain: fine, thanks ! |
| crashcut: | ok... i logged everything since 20:15 |
| crashcut: | (local time) |
| | mccaffrey.openprojects.net 921285552 17278 Friday March 12 1999 -- 14:51 -05:00 |
| stefan: | So if anyone has any questions with respect to the new code, it's all my fault...;-) |
| Alain: | umm...i don't think i have any,just wanted to check how's the development is going |
| Jordy: | alrighty |
| Jordy: | back |
| Jordy: | ordered pizza |
| stefan: | Jordy: after the last mail from Graydon in the Repository thread I had a look into the XSL documentation. What do you think about this kind of storage model ? |
| | Jordy has changed the topic on channel #berlin to: Meeting at 3:00 PM EST, 8:00 PM UTC, 12:00 PM PST |
| Jordy: | only time zones i know :) |
| Jordy: | i thought XSL was a style sheets extension for XML and had to do with positioning and the "look" rather than the definition |
| jonas: | stefan, I think we should do a killer XSL and then get the $90K for the Berlin consortium ;) |
| stefan: | Jonas: :-) |
| Jordy: | XML being the actual definition, XSL being complimentary to it |
| jonas: | stefan, did you see the slashdot post? :) |
| Alain: | look like i'll have to learn how to code a ggi driver for my chipset,there's nothing for SiS on the ggi cvs tree |
| Jordy: | i am lucky, i have a Matrox, i have FB and GGI drivers |
| jonas: | Alain: coding it is the easy part - getting the driver spec, now that takes a man! :) |
| stefan: | Jordy: not that I understood anything but my impression was that XSL can store (scoped) attributes. That's all we need, isn't it ? |
| Alain: | jordy--forgot the fb dev,my card does support vesa 2.0 |
| Jordy: | alian: that'll work, just run fbdev, and libggi with target for fbdev |
| Jordy: | stef: well that's what DOM is for isn't it? :) |
| Jordy: | all these technologies get confusing |
| stefan: | Jordy: oh yes. |
| Jordy: | XSL is a style sheet technology |
| Alain: | jonas--i think the spec are released,xfree 3.3.3 does have a driver for my chipset |
| Jordy: | XSL stands for Extensible Stylesheet Language |
| Jordy: | so we know it's for style sheets, which describe the "look" of a document |
| Jordy: | XML describes the actual data |
| Jordy: | and DOM provides a storage model |
| stefan: | Jordy: the point is that it's used in different contexts. I thought that we could use the same engine (XSL) to read docs and to read/write the repository. |
| Jordy: | the CVS repository? |
| Jordy: | you know there's another new technology that they want to replace that with :) |
| Jordy: | that they want to use for everything from web page development to code development |
| stefan: | Jordy: from an abstract point of view it can be used just to store attributes, even if not related to documents at all. |
| stefan: | Jordy: no, I ment the registrar data base :-) |
| Jordy: | oh |
| Jordy: | that's what you are talking about |
| | Jordy isn't quite "here" |
| Jordy: | :) |
| jonas: | did anybody see /usr/bin (I think) on BeOS - it contains a registrar exe. :) |
| Jordy: | well the problem is flat file databases simply don't work for anything > 2000 settings to store persistant data |
| Jordy: | jonas: really? |
| Jordy: | might need to rename it :) |
| Jordy: | i was thinking of calling it SettingsKit :) |
| stefan: | Jordy: :-))) |
| Jordy: | i still need to implement the virtual database layer so you can plug in different backends |
| Jordy: | once i get wine to run some windows apps i can actually do that :) |
| crashcut: | why wine? |
| Jordy: | i need ms access on a daily basis |
| Jordy: | i hate rebooting |
| crashcut: | ic |
| Alain: | last question (after that,i'm in lurker mode),is there a place to get deb's or rpm who's isn't in the debian (or RH) distribution (like the xserver-fbdev) ?? |
| crashcut: | is there no ms access equivalent for unix? |
| stefan: | Jordy: but seriously: I thought (until the post from Graydon) that an IDL interface similar to that of Fresco with the types StyleContext and StyleValue would give a sufficient interface to the registrar, that's why my post about that... |
| Jordy: | crash: nothing which can read the actual database files, my problem is people send me access database files, then i need to export them to my mysql database |
| Jordy: | wtf what is the fresco web page? |
| Jordy: | er |
| Jordy: | where is |
| Jordy: | typing one question then i typed another |
| Jordy: | wher eis the fresco web page |
| Jordy: | i need to read up on it, you people keep making references to it and i don't quite understand :) |
| stefan: | Jordy: just follow the link from our home page :-) And then follow the link to documentation, you'll be amazed ! |
| Jordy: | oh, haha |
| | Jordy doesn't go to our we page much :) |
| Jordy: | here we go |
| Jordy: | i'm trying to migrate to emacs, but man |
| stefan: | Jordy: be warned, the docs are created with sgml tools, so the hard copy versions are a bit buggy (figures which don't fit in the page etc.) |
| jonas: | jordy: get xemacs is much better (IMHO) |
| Jordy: | hard copy versions? |
| Jordy: | jonas: that's what i mean, i'm not used to emacs in genearl :) |
| Jordy: | general even |
| jonas: | jorda: ps |
| | Jordy doesn't print anything :) |
| stefan: | Jordy: you could download Fresco docs (ref man and tutorial) as postscript, pdf or html. Only html are clean. |
| Jordy: | html good, postscript evil, pdf ok |
| jonas: | jordy: it will take a little time - but you'll love it, many of the keybindings are every in Linux (bash, gnome, etc) |
| Jordy: | i don't mind pdf because the adobe viewer is actually legible |
| Alain: | the berlin web site is down |
| jonas: | jordy: just run the C-h C-t (ctrl+h, ctrl+t) I believe this will show a small tutorial |
| Jordy: | lots of mirrors alian |
| | MenTaLguY [tcole@cc812197-a.owml1.md.home.com] has joined #berlin |
| Jordy: | www.de.berlin-consortium.org |
| MenTaLguY: | good evening. |
| Alain: | jordy--ok (i got it) |
| Jordy: | www.es.berlin-consortium.org |
| | MenTaLguY looks around |
| jonas: | alain: I'm using the main site right now |
| stefan: | hi Mentalguy ! |
| Alain: | jonas--my first 2 request timed out but i got it on the 3rd |
| Jordy: | jonas: well i'm not used to hitting alt for anything but accessing menus, people might think this is odd, but i do most of my linux programming in windows :) |
| MenTaLguY: | I can't stay past maybe four, as I have an appointment with the dentist, fwiw. |
| MenTaLguY: | Jordy: how do you manage? unless you write obscenely portable code... I can never develop without a relatively tight code/compile/code/compile cycle |
| Jordy: | i don't compile it under windows |
| jonas: | jordy: that is odd :) |
| | Jordy uses samba to mount his linux devel box |
| Jordy: | then i open it up under borland's IDE |
| Jordy: | which is actually a sane editor |
| MenTaLguY: | ahh. it begins to make more sense. |
| Jordy: | then i go switch to my linux box and type 'make and run it |
| Jordy: | i can deal with borland, er inprise's IDE |
| stefan: | Jordy: you should definitely try out xemacs with all its nice modes ! |
| MenTaLguY: | bleah. this lag is awful (I'm using another account on a friend's box, and he apparently didn't have EPIC .. I had to hunt it down and install it) |
| jonas: | jordy: xemacs give you color hi-lighting too, but also auto-indention (press tab and it indents) I can't live without it anymore - instant error check |
| MenTaLguY: | I mean, telnet lag, mind you. openprojects.net seems to be doing fine. |
| Jordy: | jonas: yeah, that's what borland does, cept borland is more graphical, ie, search/replace gives nice little dialog boxes :) |
| | smkl [sami@ppp97.dial-in.verkkotieto.com] has joined #berlin |
| MenTaLguY: | how scriptable is Borland's interface, though? |
| Jordy: | plus search/replace requires less keystroke and borland will do a little LXR tricks, search the entire project |
| Jordy: | mental: i don't need it to be scriptable, i just need to be able to edit and indent with color highlighting :) |
| stefan: | Jordy: a reason to learn Perl :-) |
| Jordy: | that's all i need in life :) |
| crashcut: | holy wars... |
| Jordy: | i'm probably just odd, i have to be one of the only linux developers who actually programs under windows :) |
| MenTaLguY: | well, if you want holy wars, I basically use vi (or a derivative) exclusively |
| crashcut: | so do i g |
| jonas: | jordy: C-s gives you search without need to open all those windows :) |
| stefan: | Mentalguy: no I'm not argueing this one :-) |
| Jordy: | mental: yeah, my problem is i can't stand taking my fingers off my home row of keys... so vi doesn't work for me csince i hate reaching for escape :) |
| MenTaLguY: | I have a very detailed indention scheme that looks nice, but gets screwed up by autoindent stuff ... actually it doesn't even seem to be safe from vi's indention stuff |
| | jonas comes running with water to put out the fire |
| | esac [tim@tim.Desert.NET] has joined #berlin |
| crashcut: | Jordy: on the other hand escape is the only special key you'll need |
| jonas: | uh, csh user :) |
| Jordy: | ie borland search == ctrl-f/words/enter |
| Jordy: | or f3 |
| Jordy: | but i like ctrl-f since it's obviously easier :) |
| jonas: | aha, consistency not only does C-s initiate the search but also find next ! :) Enough of this - you may have the last word :) |
| MenTaLguY: | Jordy: but can you do :%s/move_dir(\([A-Za-z0-9]*\), *\([A-Za-z0-9]*\)/move_dir( |
| MenTaLguY: | err,,, |
| crashcut: | lol |
| MenTaLguY: | shoot. stupid backspace where I don't expect it... |
| MenTaLguY: | er, enter where I expect backslsh, I mean. |
| MenTaLguY: | I hate this keyborad. |
| crashcut: | yeah let's go talk about regexps... |
| MenTaLguY: | the touch is much too firm, and I can't type straight |
| crashcut: | is this ircserver efnet btw? |
| MenTaLguY: | anyway, the latest time that vi saved my ass was I had to change maybe 200 occurrences of things like move_dir(blah, foo, bar) to move_dir(&blah, &foo, &bar) (migrating C++ code to C, and thus switching from refernces to pointers) |
| Jordy: | no |
| MenTaLguY: | crash: no. |
| crashcut: | what else? |
| MenTaLguY: | openprojects.net is its own IRC network, basically. |
| crashcut: | <- doesn't speak good english =( |
| MenTaLguY: | do a /list -- it's pretty small |
| crashcut: | ah... i see |
| jonas: | crashcut: Nicht als slemmer als meine deutch (you get the idea) :) |
| stefan: | Jonas: :-) |
| crashcut: | ok i got it =) |
| Jordy: | anyway, i'll read up on this fresco tutorial |
| Jordy: | so is anyone working on more advanced widgets? |
| Jordy: | i have the urge to move mozilla over to corba |
| MenTaLguY: | that would be decidedly interesting. |
| Jordy: | not that hard since their xpcom shows me what interfaces to export |
| jonas: | jordy: might be a couple of days before you can compile on Berlin :) |
| stefan: | Jordy: I'm working on very basic widget related stuff, I think we have to redesign this whole thing... |
| | jonas doesn't now much about mozilla, but likes it. |
| Jordy: | the problem is that mozilla doesn't have a font renderer built in, so we need one in berlin first |
| MenTaLguY: | mm. |
| stefan: | Jordy: I just commited a couple of subjects widgets will be connected to (as the controlling device) |
| jonas: | stefan: not totally - but it still needs a lot of work to allow properly extension, etc. |
| Jordy: | well someone should make a big container widget for the desktop itself |
| MenTaLguY: | whatever happened to that initial work done with freetype + GGI? |
| Jordy: | it doesn't have to do anything but draw a big box and contain other widgets |
| Jordy: | donno mental, i think graydon has all that stuff working on his box |
| stefan: | Jordy: isn't this the job of Moscow, to decide actually what a desktop is ? |
| MenTaLguY: | btw, while we're on the subject of widgets ... I don't have time to do this myself, but does anyone remember the "scroll container" widget I was pushing on the list a while back |
| MenTaLguY: | ? |
| Jordy: | stef: exactly, we'd be starting moscow |
| Jordy: | moscow is the desktop widget basically :) |
| Jordy: | well i guess moscow could contain all the widgets |
| Jordy: | that would make it less difficult to grasp :) |
| stefan: | Jordy: then give us a couple of months (I'd guess till the end of summer) and we can seriously start thinking about that. |
| jonas: | desktop: while it's still part of warsaw (root window) we need a lot more work on layout and basic widget hierarchy before we can make anything sane! |
| MenTaLguY: | maybe we should define some sort of proto-moscow framework that we can test in, but is very minimal so we can rip it out later without too much pain? |
| jonas: | yup - summer will hopefully be a big booster (with 3 months of vacation - no excuse is good :) |
| Jordy: | i still we need a good PR person |
| Jordy: | if anyone is up for the task |
| jonas: | jordy: we very much do, as long as we don't shoot ourselves in the foot (some flaming salesman with no product!) |
| MenTaLguY: | I'm like majorly too busy already; in addition to GGI and Berlin, I've "adopted" several other free software projects now too :) |
| Jordy: | hell if everyone started putting the berlin web page url in their .sig's on slashdot, that'd almost be enough :) |
| MenTaLguY: | I could do that. |
| | MenTaLguY does that |
| jonas: | jordy: i'd better stop ac'ing then :) |
| Jordy: | jonas: yeah, but we need a few more developers... i mean look at gnome |
| Jordy: | gnome has almost 15x more developers than us :) |
| Jordy: | and it's a tiny project compared to ours |
| | crashcut would *love* to join but hasn't enough time =(( |
| | graydon [gray@shell1.interlog.com] has joined #berlin |
| Jordy: | graydon good |
| stefan: | Jordy: I think we need to settle the structure of the project so that people can work on sub projects (like individual kits) |
| graydon: | rehi |
| jonas: | jordy: we just need to work harder :) Don't get me wrong - but already we're having problems explaining our ideas to everyone :) |
| Alain: | hi graydon |
| jonas: | hey gray |
| stefan: | hi Graydon ! |
| Jordy: | graydon, were you the one with the working font renderer? :) |
| graydon: | sorry I'm late |
| MenTaLguY: | in some ways, it might almost be nice to merge with Gnome. same license and all. just a very random thought. I think really our scope is too different, though. |
| crashcut: | graydon: want the log? |
| graydon: | is someone keeping a log? |
| crashcut: | smile |
| | graydon is coming n through a *very* lagged telnet connection from campus, so is nt going to be particularly *in tune* with the conversation |
| Jordy: | i'm not sure what gnome is, i'm running gnome... but all it does for me is give me a pretty little tray :) |
| graydon: | plus I can't keep a log here, so please someone else keep a log open. |
| | crashcut does. |
| graydon: | thanks |
| MenTaLguY: | gray: I know the feeling -- telnet lag is killing me |
| crashcut: | graydon: want it by mail or dcc? |
| graydon: | ok, s am I barging in on a conversation or can I commence rambling about what's been happening recently? |
| graydon: | crashcut: email once the meeting is finished, if you don't mind |
| crashcut: | ok |
| MenTaLguY: | no, ramble on, oh great one :) |
| Alain: | i begun logging |
| stefan: | Graydon: I think you can simply set the topic and start |
| graydon: | Ok, cool |
| Jordy: | graydon: ramble about emacs, a little PR, some work on more widgets and uh, gnome :) |
| | graydon has changed the topic on channel #berlin to: new stuff from fresco in CVS |
| Jordy: | ooo, new stuff? |
| MenTaLguY: | cool |
| graydon: | yes, stefan wrote a lot of new code and modified large chunks of fresco after our meeting in montreal |
| graydon: | the principal changes are that we have reconciled our views on how layout should be done (or at least the framework in which layout strategies are executed) and written the basic structures of the drawing kit and redraw algorithms |
| graydon: | they are quite different from the style of thing in the firse 0.0 berlin, I'm hoping to lay down some really good documentation; for the time being you have to stick with the fresco tutorial, which is actually not bad |
| graydon: | so we have data structures in IDL which represent layout requirement information |
| Jordy: | nifty |
| graydon: | and layout is done incrimentally based on signals from objects which want to redraw. it's similar in feel to the drawing system; in fact, layout and drawing take place concurrently. |
| Jordy: | have we introduced ourselves to the fresco people yet? |
| Jordy: | just curious if we can steal of few of their developers :) |
| graydon: | basically an object can call needredraw() or needreshape() on itself, and the appropriate type of traversal will take place |
| stefan: | Jordy: I once discussed with Thomas Hiller, which is the current maintainer |
| jonas: | how do "3rd party" widgets fit into the Kit way? |
| graydon: | afaik fresco development dried up a couple years ago, but there are people who worked on it, and we should definitely try to stay in touch |
| Jordy: | needredraw() needreshape() take box arguments for partial redraw? |
| | Lupuz [noone@sdu142-73.ppp.algonet.se] has joined #berlin |
| graydon: | they also have some nice tools like ixx, their stub compiler and interface documentation tool. it churns out docbook |
| Jordy: | nifty |
| stefan: | Jordy: he seemed interested in whether we could merge but I don't know whether he is willing to do as much changes as I already introduced (and more will follow...!) |
| Jordy: | btw, i think i'm going to LXR our source |
| Jordy: | and set it up on a box to cvs co every few hours |
| Jordy: | if anyone isn't familiar with LXR, check out www.mozilla.org |
| Jordy: | LXR is the ultimate in cross-referencing tools |
| jonas: | Jordy: as I don't have CVS here - it's welcome :) |
| graydon: | Jordy: needredraw() and needresize() really just start traversals. the arguments about which areas are damaged etc. are retrieved by the traversal as it proceeds over the graph. |
| Jordy: | litterly, i didn't realize that my life was complete until I found LXR |
| Jordy: | er was incomplete |
| graydon: | er ,well,actually I guess they fetch the area they're and apply damage directly ttheregn which begins a traversal but yeah, this all needs thurough documentation |
| stefan: | Graydon: basically need<>() just damages a region. The traversal is postponed. |
| Jordy: | ok, so needredraw() marks it's viewable dirty and forced a redraw, when? immediately or does it queue? |
| stefan: | Jordy: it queues. |
| Jordy: | is there a way to force an immediate redraw is what i'm trying to ask |
| Jordy: | since that would be useful for a few things |
| stefan: | Jordy: which ? |
| Jordy: | specificially i KNOW for a fact that mozilla requires force redraws for things like scroll bar controls |
| Jordy: | since i put it in :) |
| graydon: | shyte ths keyboard s brked. wll swtchwrkstatns. :) |
| MenTaLguY: | speaking of scroll bars, does anyone remember my scroll container proposal? |
| | SignOff graydon: #berlin (Read error to graydon[shell1.interlog.com]: EOF from client) |
| | Aaron [aaronv@va.debian.org] has joined #berlin |
| stefan: | Jordy: the point to queue is to be able to optimize. |
| | Aaron puffs |
| | Aaron puffs again |
| jonas: | ehlo aaron |
| stefan: | hi Aaron ! |
| Jordy: | stefan: i know, but we need a way to force it to redraw, lemme think of an example |
| Aaron: | man have I had a difficult day |
| | Jordy thinks |
| | Aaron pipes down and listens. |
| Aaron: | I only have an hour ;P |
| Jordy: | animation is particular example, animation may require a referesh more freq then our main redraw loop goes |
| Jordy: | in particular, animation usually wants to be synched with the monitor refreshes, so every 60 Hz or so |
| MenTaLguY: | really, probably what you want is to queue until something is queud that indicates to the optimizer (either explicitly or implicitly) to "flush" the queued stuff |
| MenTaLguY: | probably implicitly |
| stefan: | Jordy: Hmm, if you have a thread sitting around and waiting only for damages so it can start a DrawTraversal, how can you want to spead this up ? |
| MenTaLguY: | so, in the case of animation, you'd be pushing "criticality" events or something onto the queue? |
| Jordy: | right, i'm thinking, queuenbr = markdirty(region); forcequeue(queuenbr); |
| Jordy: | or something similar |
| Jordy: | which would force it to redraw a certain region immediately |
| Aaron: | MenTaLguY: if the graphic calls 'needs_redraw()' then it knows a cached region needs to be re-fetched.... |
| stefan: | Jordy: I think a flush is possible (at least in the context of a separate redraw thread) |
| MenTaLguY: | mmm. |
| Aaron: | stefan: ok, so we're talking about truly animated regions such as those that use, say , opengl? |
| Jordy: | stefan: i only say this because i we probably don't want to run the refresh queue at monitor freqs, since we couldn't do any optimization if your loop is going at 100 hz |
| Jordy: | but some things, like games will NEED to be updated more often than your queue wil run |
| Aaron: | Jordy: games would benefit from bypassing corba entirely |
| Aaron: | Jordy: games don't like being run under an async refresh environment. |
| jonas: | jordy: also only the game's part should be updated - hmm, drawing flush with priorities? :) |
| stefan: | Jordy: right. So yes, there are different possibilities to do that. |
| Jordy: | well any animation will want to run faster than our queue will go i'd assume |
| Aaron: | so, you write a GGI target to Berlin that uses some SHM extension. |
| MenTaLguY: | Aaron: that's less a corba thing than a design thing, isn't it? |
| Aaron: | MenTaLguY: yes. |
| | graydon [gray@shell1.interlog.com] has joined #berlin |
| | graydon sighs |
| graydon: | sorry |
| stefan: | hi again Graydon and better luck ! |
| MenTaLguY: | you know, sometimes games would in fact benefit from async updates, though |
| Aaron: | MenTaLguY: I'm just saying apps that want to be redrawn frequently won't benefit from berlin's flexibility as much, but would benefit more from some local extension that uses shared memory instead of CORBA |
| MenTaLguY: | especially in cases where the machine is too slow to keep up with one update an engine cycle or something |
| Jordy: | yep mental, i donno.. i just figured a way to force an application to mark a region dirty and then force a synchronous redraw might benefit some people :) |
| graydon: | so, stefan also took the opportunity to (a) flyweight all the graphics, so they are shared (the scene graph is now a scene DAG) and (b) introduce some coding standards like naming conventions etc. |
| MenTaLguY: | Aaron: couldn't you abstract that in some manner? |
| Aaron: | well, then, you can still use GGI for a SHM target to berlin. whether the target is used asychronously or not is up to the app |
| Jordy: | i guess |
| graydon: | dudes, this is way off topic. we're not writing a drawing layer, we're writing a wrapper around drawing layers |
| | MenTaLguY nods |
| Jordy: | graydon: we drifted while you were gone :) |
| MenTaLguY: | that's what I meant about abstraction |
| graydon: | hehe |
| Jordy: | alright, so where were we |
| Aaron: | ok, so what's the topic? |
| | Aaron just got here |
| graydon: | ok, so there is a set of data types and an interface (very primitive) for drawing |
| graydon: | we also moved many of the interfaces into kits |
| Jordy: | difference between an interface and a kit is what? |
| Aaron: | graydon, do we have a proposed spec for the api posted anywhere? |
| graydon: | so there are far fewer .idl files |
| Jordy: | namespace {}? |
| Aaron: | oh yeah, the IDL ;P |
| graydon: | no, a kit is a specialized factory which has static methods |
| graydon: | I'll give an example |
| graydon: | the command kit (might be merged with reactor kit) makes commands |
| graydon: | rather than using the genericFactory to produce commands, you have one object which has say a dozen static methods on it |
| graydon: | each of which returns simply a "command" object |
| Jordy: | gotcha |
| graydon: | all the subclasses (redrawCommand, sendMessageCommand) etc. are gone |
| graydon: | they are the method names on the object |
| Aaron: | graydon: and each of these 'kits' is running in its own thread, as a reactor? |
| MenTaLguY: | ooh. sounds nice |
| graydon: | commandKit->sendMessage() returns a command |
| graydon: | Aaron: no, it's just a factory object you create |
| graydon: | the benefits are as follows: |
| graydon: | libwarsaw is half as big |
| Aaron: | so, kits are not themselves static |
| graydon: | the kits can contain some internal state they share between objects they create, if it helps optimize |
| Alain: | is there someone who know exactly if it's the right xserver i need for fbdev,i furriously searched for any documentation on this server and there is NONE: XFree86 virtual frame buffer server |
| Alain: | it's isn't the same server as the FBdev |
| Aaron: | oh, I also looked at hacking omniidl to plit its output into client/server portions. this would half the size of warsaw again. |
| MenTaLguY: | drop by XFree86.org -- should be an fbdev server availible |
| graydon: | the API is simpler, since you don't need to access the genericFactory by interface name and then downcast and configure the object |
| Alain: | mentalguy--not in rpm or deb's |
| graydon: | fir instance you can make the constructor method on the kit take all the meaningful parameters in one call |
| Aaron: | graydon: thats pretty slick |
| Jordy: | good, keep the marshalling down to a minimum |
| graydon: | i.e. commandKit->sendMessage(messageA, targetB) |
| graydon: | Jordy: plus it makes the client code much simpler |
| jonas: | duh, labs shutting down :( guess I'll have to go with the log - later all! |
| Aaron: | bye jonas |
| MenTaLguY: | I'll have to leave for the dentist in ten minutes. ugh. |
| Alain: | bye jonas |
| stefan: | By Jonas ! |
| graydon: | the only disadvantage is that it reduces slightly the level of granularity at which we allow swapping of components |
| graydon: | but you can always rewrite a kit in smaller pieces |
| | SignOff jonas: #berlin (Leaving) |
| | crashcut still has a log running since 20:51 (compared to 21:54 now) |
| graydon: | so I don't think it's too big a deal. |
| Aaron: | graydon: CORBA solves that problem for us tho... |
| Jordy: | alright... sounds fine to me |
| crashcut: | uhm... offtopic... |
| graydon: | the new coding convention is that classes and types are all beginning with upper case |
| crashcut: | www.cs.tu-berlin.de/~crashcut/crashcut.mpg (the berlin trailer preview) |
| graydon: | so if you look in the CVS repository, stefan introduced directories named with upper-case first letters |
| Jordy: | oh man, you changed the coding convention? |
| graydon: | those are the new code |
| Aaron: | good, there's a coding convention now ;P |
| graydon: | in particular, /include/Warsaw contains all the new interfaces |
| Jordy: | aaron: well we had one before, no one followed it, but :) |
| Aaron: | Jordy: I never saw it stated anywhere |
| Jordy: | aaron: old mailing list archives |
| graydon: | and the implementations are in upper-case names in /src |
| Jordy: | aaron: you don't even want to know how long we argued on that |
| Aaron: | Jordy: well, the list archive is huge ;P |
| graydon: | I've ported much of the last libwarsaw to /include/Warsaw and am primarily working in there now |
| Jordy: | now you are working on the main tree right? |
| graydon: | and will commence adapting /src/libberlin to work in stefan's implementations when I get sufficient free time |
| Jordy: | not on berlin_0.0.1 tag? |
| Aaron: | graydon: does all the .idl live there now? |
| MenTaLguY: | crashcut: NICE ... however, I don't like the way the panels or whatever intersect as they move into their final orientation |
| graydon: | Aaron: yes. |
| | Aaron wishes he had an mpeg player |
| graydon: | So, um, that's the big new issue |
| crashcut: | mentalguy, right... i'm working on that... as well on the fact that the triangles move to left finally... |
| Jordy: | sounds |
| crashcut: | aaron, i recommend mpeg_play (apt-get install mpeg_play i think) |
| Aaron: | I would like to stress one thing -- this trailer has no proof of concept yet, nobody hype it up please -- that creates way too much heat |
| MenTaLguY: | crashcut: you should try having them spread vertically as they spin along their individual axes, and then come together and fold out like a hand of cards |
| graydon: | I want to assuage people's fears about the layout system; it does not specify a particular packingalgorithm or anything. it's just a framework for communicating layout requirements and operating a layout algorithm procedurally over the resizing nodes in |
| MenTaLguY: | Aaron: yes -- good point. |
| MenTaLguY: | Aaron: at this point in time; hype is bad |
| Jordy: | btw crash, that's pretty :) |
| crashcut: | hm... what exactly do you mean with a concept for a trailer? |
| crashcut: | jordy, thanks =) |
| Jordy: | what's the next order of business |
| Aaron: | graydon: define the 'layout system' -- I prolly know what you're talking about ... but want to know exactly what your definition is ;P |
| graydon: | ok, I wrote an article on berlin for cscene magazine; www.cscene.org. it's probably not up yet, ut I am hoping it'll clarify how things are going |
| Aaron: | crashcut: oh, it's not like, a bit of conceptual art of what berlin 'will' be like? That's what trailers sometimes are. Is it just like, a pretty animation... |
| Jordy: | aaron: you know how Netscape positions HTML into places on a web page? :) |
| Aaron: | Jordy: yes. |
| MenTaLguY: | Aaron: this is is the sort of thing you might see on the Berlin splash screen |
| Jordy: | aaron: that's a layout engine... then the rendering engine displays it on the screen |
| MenTaLguY: | Aaron: but still .. we probably don't want hype right now |
| Aaron: | Jordy: so, the layout system has nothing to do with region management, but rather controls the flow of events to regions, and positioning regions? |
| Jordy: | aaron: i was just making a simplified example :) |
| Aaron: | ok ;P |
| graydon: | Aaron: layout of objects is positioning them and allocating space (including stretching or instructing them to stretch). it happens simultaneously with queueing up drawing commands. |
| Aaron: | ok... |
| | crashcut forks into the background thinking about the trailer concept... |
| graydon: | crashcut: try writing that using the berlin drawing API, such that we render it live during startup. |
| Jordy: | graydon: good idea |
| Jordy: | but we'd need it a bit bigger |
| crashcut: | graydon: i'm not that hard core in programming g |
| Jordy: | ie, 640x480 |
| graydon: | heh, yes |
| crashcut: | Jordy: povray can do any size... it's just an example |
| Jordy: | crash: oh you are using pov? bah, no problem :) |
| crashcut: | jordy; yeah well... it's not live though |
| Jordy: | we can convert that over with minimum of ease :) |
| graydon: | ok, I need to make sure we get everything wrapped up by another hour or 2.. stefan: do you have anything else you wanted to discuss? |
| crashcut: | jordy; hey that's cool... |
| Aaron: | someone take a screenshot of the trailer and post it somewhere? |
| | Aaron is curious |
| crashcut: | yeah just a second... |
| MenTaLguY: | maybe rather screenshots of keyframes |
| stefan: | Graydon: well, there are a couple of things, like the granularity of kits and widget plugins for example |
| MenTaLguY: | I love the spinning pyramid coming at the camera |
| Jordy: | btw, graydon, you wanna work on a little roadmap of where we are headed? |
| Jordy: | no dates or anything, just what needs to be implemented in what order |
| graydon: | stefan: yes, I was thinking today that it might be nice to make C++ classes for the subcomponents of some of the kits, and use the same dynamic plugin loader I have in genericFactory for customizing them at runtime. that would keep the interface in IDL sim |
| MenTaLguY: | well, I've gotta run. |
| stefan: | Jordy: good point ! I think that is one motivation for introducing kits, too. So we can factorize the project so everyone can look up his favorit toy... |
| | Aaron_ [vanco@bolt.sonic.net] has joined #berlin |
| Aaron_: | argl! |
| MenTaLguY: | I guess I'll have to catch up via the logs |
| graydon: | simple, but let the users have some ability to trade small bits of logic |
| | SignOff MenTaLguY: #berlin (the dentist awaits) |
| graydon: | Jordy: well, I want to see this drawing system working |
| Aaron_: | a working system is better for a project than a half-finished, 'perfect' system |
| stefan: | Graydon: Let me give an example from X: |
| graydon: | Jordy: after that, we need to progress towards a "standard" set of objects to go into our kit interfaces. it's important to get many ideas in there because the interfaces will be reasonably static |
| Jordy: | right, i'm just talking about a roadmap so we know what needs to be implemented and what to focus on.. i'm not saying now -> end of project, i mean now -> next release |
| stefan: | Graydon: I construct a Button, which is the factory for the Button::Look. So since the Button knows its StyleContext it can fetch the respective attribute for it's look and create it appropriately. |
| graydon: | Jordy: yeah, I'd be happy setting the next packaging release at getting the new drawing system to the level the last one was at: i.e. showing simple little shapes and stuff. nothing complex. |
| graydon: | then, well, I'm totally satisfied with this drawing system, so I think we can proceed to build on that rather than repeatedly cutting the bottom out of the codebase |
| Jordy: | graydon: alright, that's all i wanted to know |
| Aaron_: | stefan: Maybe this should go into mail, but I didn't completely understand the look/feel separation in your new interfaces... |
| crashcut: | Aaron: www.cs.tu-berlin.de/~crashcut/povray/ |
| | SignOff Aaron: #berlin (BitchX - Main screen killed) |
| graydon: | so a series of releases following would just be enhanced and expanded kits, until we feel we have enough |
| stefan: | Graydon: in Berlin this would be similar: the WidgetKit::button(...) would look for the user preferences for the button's style and call the appropriate plugin. What do you think ? |
| Aaron_: | someone killed my shell on va |
| Aaron_: | those debian folks are overly... massichistic |
| Jordy: | aaron: it's those damn gnome developers |
| Jordy: | :) |
| Aaron_: | jordy: gnome has been kicked off va. |
| Jordy: | oh, never mind then |
| Aaron_: | gack! it's tga. I'm on a lab comp ;P |
| crashcut: | what format do you need? |
| stefan: | Aaron: never mind the look/feel separation, it was just to illustrate a point |
| Alain: | ummm....may i propose jpg |
| | crashcut feels uncomfortable disturbing the diskussion |
| crashcut: | awight |
| graydon: | stefan: yes, that's a possibility. move the whole plugin loader down there. |
| Aaron_: | stefan: so basically, you have one (unchangeable' object, representing a specified widget's interface, and another that actually takes care of the drawing? |
| stefan: | Graydon: it's just that what does the WidgetKit create (beside subjects) if not widgets ? |
| Aaron_: | s/\'/)/ |
| stefan: | Aaron: that's what I did in OffiX. What we will do in Berlin is a completely different story. |
| Aaron_: | stefan: ok, well, I look forward to seeing how it ends up ;P |
| Aaron_: | steffen: after I've finished this little prog with corba and ggi I'll be in a better spot to follow. |
| stefan: | Aaron: since we use factories to create widgets anyway, we don't need to hide the look as a strategy behind the widget object, in the context of structured graphic, the look pretty much is the widget. |
| graydon: | then button(...) binda commands to the reactor it's given, and then provides that configured reactor to a particular graphic which it loads dynamically? |
| Aaron_: | stef, then how do you separate look/feel |
| graydon: | s/binda/binds/ |
| Aaron_: | nevermind |
| Aaron_: | I'll track cvs changes ;P |
| Aaron_: | yes |
| stefan: | Graydon: yes, like that. button(...) would look for a StyleValue "Button.Style" or so and slider(...) would look for "Slider.Style"... |
| graydon: | stefan: hmm, I was worried that a local dynamic loader would use dynamic_cast<> way too muich -- this is interesting. do you think we could get away with locally just loading different graphics |
| graydon: | ? |
| Jordy: | using something like xpms or some type of easily recizable graphic for the look? |
| Jordy: | that's what mozilla is doing |
| Jordy: | their "look" is implemented with jpegs specified by an RDF document |
| Aaron_: | gack, no xpms |
| stefan: | Graydon: What do you mean ? You need dynamic_cast basically for every plugin once, don't you ? |
| Aaron_: | we need something entirely scalable |
| Jordy: | aaron: like macromedia flash? :) |
| graydon: | kJordy: no, dynamically loading objects, but all of the homogeneous type "graphic" |
| Aaron_: | jord: no, that's where steffen's drawingKit comes in ;P |
| Jordy: | alright, mmm |
| Aaron_: | graydon: so now, are composites history? |
| graydon: | Jordy: i.e. avoiding the requirement of making another "anything loader" which doesn't even have the corba narrow() facility to make safe-ish downcasts |
| Jordy: | graydon: hmm |
| | Aaron_ is now known as Aaron |
| Jordy: | speed things up a bit |
| Aaron: | 'downcast' is casting an object to its base class? |
| | Aaron doesn't know the lingo |
| graydon: | stefan: no, when you resolve a symbol in a dynamic object, you can resolve it by type. i.e. you can be resolving graphicImplFactory *getPlugin() |
| Aaron: | crash: looks great |
| crashcut: | merci... |
| Alain: | is there someone who's logging the discussion,i'll have to log out and change account (my security setting are too paranoid in the lame OS i'm running) |
| crashcut: | i'm logging |
| Jordy: | crash is |
| Alain: | crashcut--thanks |
| Alain: | brb |
| | SignOff Alain: #berlin (Leaving) |
| graydon: | Aaron: downcasting being trying to resolve the type of an abstract object like a void* into something you merely "suspect" it is. |
| Aaron: | graydon: ah |
| Jordy: | gray: wouldn't that simply be "casting" :) |
| stefan: | Graydon: right, then, why dynamic_cast ? If all those plugins which are loaded from widgetKit create 'widget' (I prefer 'controler') types, you don't need to cast. |
| graydon: | stefan: for instance in the current genericFactory, I know all the objects I'm loading are lifecycle objects, which I can safely use narrow() on. |
| graydon: | stefan: agreed. I'm happy about that. if it were a totally generic loader I'd need dynamic_cast. now I don't. I hate dynamic_cast. |
| graydon: | Jordy: no, upcasting (taking a fooObject and casting to a void *) is safe. downcasting (narrowing) is not safe |
| Aaron: | graydon, how far did you get on the text subsystem? |
| graydon: | Aaron: the info on the timeline page is accurate: interfaces donw to my satisfaction, implementation not done. |
| Aaron: | if you downcast to the wrong type, an object gets control of an environment it wasn't supposed to... |
| graydon: | Aaron: I'm waiting on making the drawing kit work |
| Jordy: | graydon: gotcha, can we wrap all objects in a generic container that holds the "type" of object? |
| Aaron: | gray: gotcha |
| graydon: | Aaron: since there's really no way of talking about bitmaps until that exists |
| graydon: | Jordy: that would be what corba does, and what dynamic_cast does in C++, and what I want to avoid. |
| stefan: | Graydon: ok. if that widget loader thing is settled, we need to speak about the StyleValue |
| graydon: | stefan: yes |
| graydon: | stefan: did you have a look at the XSL processing model? |
| | Aaron snickers |
| graydon: | stefan: if you wanted something simple like a key=val style preferences system, I'd not mind a custom implementation |
| Aaron: | anybody here hear Al Gore's claim about having 'taken the initiative to create the internet'... |
| stefan: | Graydon: I did. It looks good even though I read it more as a storage model for (nested) attributes. Is this useful for us in this context ? |
| graydon: | stefan: but if you're talking overriding, contexts, wildcards, nesting, etc. then I start to think using someone else's standard would be better |
| graydon: | stefan: well, the concept of "style sheet" and the concept of "widget style preference" has much in common |
| graydon: | stefan: you write "selectors" which trigger "rules" based on the "instance" |
| stefan: | Graydon: does it make sense, then, to think whether the whole Registrar should be modeled that way ? |
| graydon: | stefan: just change from a scene graph (in berlin) to a DOM node graph (in XML) and you have the same thing |
| stefan: | Graydon: agreed. |
| graydon: | stefan: you need to standardize on a selector syntax, a set of rule semantics (what a rule can do) and a prioritization standard for resolving multiple rules |
| graydon: | stefa: I feel that it would be a shame to waste the XSL's effort in having done that |
| Jordy: | one second, i'll be back in 5 minutes |
| graydon: | stefan: I'm not sure if the registrar and the style system are of the same level of complexity |
| | al [berlin@140.159.225.100] has joined #berlin |
| graydon: | stefan: like, the user's email address is not really as complex as "load this class to render this object" |
| stefan: | Graydon, Jordy: Right, I repeat my question: wouldn't it make sense to model the whole Registrar this way ? |
| graydon: | stefan: but I agree it would be aesthetically pleasing to have them combined |
| graydon: | stefan: and it would rock serious ass if we had a persistent style preferences system |
| stefan: | Graydon: attributes which are used by graphic objects and one day the Moscow desktop will make heavy use if this kind of nesting/wild card matching (I really think that the X resource manager is one of the good points about X) |
| graydon: | stefan: like, if you could write new XSL rules at runtime and they'd apply in future sessions... mmm |
| Aaron: | I could see that being taken as a yes ;P |
| graydon: | stefan: yes. I'll have to re-read the XSL spec and see how it could be possible to integrate them |
| | SignOff Lupuz: #berlin (Read error to Lupuz[sdu142-73.ppp.algonet.se]: Connection reset by peer) |
| stefan: | Graydon: then I vote for an evolution of the registrar to a XSL database manager |
| Aaron: | stefan: that doesn't sound entirely too difficult. unless my assumptions are wrong. but first, the registrar needs to be finished ;P |
| Aaron: | jordy, you about? |
| graydon: | stefan: yeah, if it makes sense in any way I would agree. again though, I'm a little unclear on how it will work :) |
| Jordy: | sorry about that |
| Jordy: | had a customer call |
| | graydon goes and starts the XSL spec printing |
| Aaron: | jordy, what points need to be worked on in registrar, before it's finished? |
| stefan: | Graydon: the nice thing is that the interface would look identical (to StyleContext/StyleValue). For example a graphic node get's its complete StyleContext from it's position in the scene graph. This Context (coded into a string) would be used to fetch from the registrar some value (like the background color, the style value for widgets etc.) |
| Aaron: | or at least useable |
| graydon: | stefan: yes, that would be seriously good |
| stefan: | Graydon: and again, it would help clearing the API quite a lot ! |
| graydon: | stefan: yes, yes, I am starting to see that as working. |
| Jordy: | let me think |
| graydon: | stefan: the trick is that the XSL processing model is to produce flow objects |
| graydon: | stefan: in other words it's not designed around querying a node, it's designed around processing a node and all its children |
| | Alain [Woody@205.151.66.107] has joined #berlin |
| Alain: | re |
| Jordy: | i'm reading up on this XSL thing |
| graydon: | stefan: and emitting a graphic which satisfies the style preferences |
| stefan: | Graydon: hmm, I see, so we would have some 'empty' document with nothing but attributes in it, right ? |
| Jordy: | how would you expect me to use XSL with the registrar? |
| Jordy: | do you want to pass XSL to the registrar server to store/retrieve keys? |
| graydon: | Jordy: that's exactly what we're trying to figure out |
| Aaron: | what's a URL for the XSL spec? |
| Jordy: | http://www.w3.org/TR/WD-xsl |
| | BitchX: Added HTTP/FTP grab [2] |
| graydon: | Jordy: the requirements seem eerily too similar to pass up this as an avenue of discussion |
| Jordy: | i'm ust taking a look |
| stefan: | Graydon: this would, in fact, be more a document template than a document... |
| graydon: | Jordy: I think we're thinking of passing a string representation of the attributed path to a given graphic to the registrar in order to retrieve keys |
| Jordy: | i could have sworn XSL was created to develop the "look" of an XML document |
| Jordy: | and that XML actually contains the data itself |
| graydon: | Jordy: using the XSL pattern language to look the keys up |
| Aaron: | graydon: if you could achive this with unicode, berlin could end up a hot corporate quality system |
| Jordy: | well i can implement regex matching in the registrar pretty easily |
| graydon: | Jordy: and manually constructing such a path when we're looking up something like the user's favourite flavour of icecream, which is not a particular node in the scene graph |
| Jordy: | that's not difficult at all because of all the billions of regex libs out there, i just need to match() the request to the items in a particular directory and return an array of results |
| graydon: | Jordy: you can get exact semantics for pattern matching, plus the source code to 2 reference implementations |
| Jordy: | hmmm |
| Jordy: | plus $90k from sun :) |
| | Jordy grins |
| Alain: | got a question,is there someone working at embeding postscript displaying capability in berlin (i remember it being discussed a long time ago on the list) ?? |
| graydon: | yeah man, this would totally win the sun award! |
| Jordy: | hahah, graydon :) |
| graydon: | Alain: yeah, a postscript drawing kit will operate just the same as the OpenGL one, only it'll emit postscript :) |
| Aaron: | alain: that could easily be done by hijacking drawingKit and its components |
| Jordy: | the main thing is i don't want to have to implement my own XML/XSL parser to get this to work... and i'm actually going to store things in a flat file for obvious reasons |
| Jordy: | so i'm trying to figure out where XSL would come in handy |
| Alain: | graydon--cool,if i think right (i could be wrong on that),it will allow the porting of GNUStep |
| Aaron: | jordy: you can get stylesheet settings from any node in the sscene graph, I gather |
| Aaron: | by dumping their preference info into registrar on an object-by-object basis |
| Aaron: | gack I ahve to go |
| graydon: | Alain: oh, um, that's interesting.. I'm not really sure we have the adaptor going in the right direction. interpreting postscript inside berlin would not necessarily be easy. you'd have to alter your postscript display system |
| stefan: | Jordy: which would be XSL files then, yes. There seem to be a couple of XSL parsers out there, notably from J.Clark but written in Java. |
| | Aaron waves to everyone |
| crashcut: | cu aaron |
| graydon: | Alain: we're talking about the other direction, berlin graphics -> postscript |
| graydon: | see ya aaron |
| Alain: | have a nice day Aaron |
| | SignOff Aaron: #berlin (later everyone) |
| stefan: | bye Aaron ! |
| Alain: | graydon--oups |
| Jordy: | is getKeys("<xsl:template match="system"><xsl:apply-templates select="system"><xsl:sort select="name/Berlin"/></xsl:apply-templates></xsl:template>"); easier than getKeys("/system/Berlin/*"); |
| Jordy: | man that was ugly |
| Alain: | graydon--at least,there's a display engine in GNUStep |
| graydon: | Jordy: no, we'd stick with a simple one like the latter, we're just talking about making something which could be used as a stylesheet-retriever in the context of an XML document processor, and as a graphics customizer in the context of the widget kit, and |
| crashcut: | will the log need running much more than 15 minutes? i've just received an invitation to a party... ducks and runs |
| Jordy: | but again, XSL was designed to lay out information from an XML document... |
| graydon: | crash: um, it would be nice obviously, but I think I need to motor pretty soon too |
| Alain: | crashcut--i'm not logging,have to go in 5~10 minutes |
| graydon: | Jordy: but the XSL pattern language is good for navigating any sort of attributed tree. that's the point |
| stefan: | Graydon: Yes, I think we mentioned the most important things, all the rest can go in mail... |
| crashcut: | ok... if everyone's leaving anyway i won't have to bother with that... ;) |
| Jordy: | graydon: right, but so is regex :) |
| Jordy: | and regex is consiterably simpler no? |
| Jordy: | considerably |
| graydon: | Jordy: and since we have these 3 contexts for natvigating an attributed tree, and we know we'll need an XSL processor someday, this seems a nice fit |
| Jordy: | hmmm |
| Jordy: | i think it might be easier to expose mozilla via corba and use it :) |
| Jordy: | it has an XML processor, and they have base XSL stuff done |
| graydon: | Jordy: the thought has crossed my mind a number of times |
| Jordy: | graydon: well i'm to the point where i might as well just do it, the problem is berlin has no font renderer |
| Jordy: | and there are a few hooks that need to be set in order for it to work |
| graydon: | Jordy: but I think you're wrong in your difficulty estimates. writing something to do XSL pattern language lookups is not as bad |
| stefan: | Jordy: you were talking about sponsoring: why not asking J.Clark to help us giving us a nice XSL parser written in C++ ? |
| Alain: | well,have to go,good bye |
| crashcut: | laters alain |
| stefan: | bye Alain |
| Alain: | bye crashcut and Stefan |
| Jordy: | XSL looks like it'd be good to use to disable information from a database on a web page |
| Jordy: | :) |
| Alain: | keep up the good work |
| crashcut: | btw... does anyone have an idea how to match control characters in sed? i'll have to clean up the log file... |
| Jordy: | er to display |
| | SignOff Alain: #berlin (Leaving) |
| Jordy: | man what is up with my hands today, think one word and typing another |
| graydon: | crashcut: I have a nice IRC prettifier in perl I used for the other meetings. just mail me the log and I'll make it nice |
| crashcut: | graydon: hm... i'd like to have such a script... ;) |
| Jordy: | well, anhow someone asked what needs to be done to the registrar |
| graydon: | Jordy: well, it also has interesting applications in styling the composite widget (graphic) graph. For instance, first-of-type() and last-of-type() could be used to round the ends of rows of buttons (or rows of anythings) |
| Jordy: | actually i think i have a TODO file in there |
| Jordy: | graydon: the idea of actually passing XSL text around seems.. odd |
| stefan: | Jordy: but you wouldn't pass this around, it's just the storage format. |
| Jordy: | XML/XSL would make for a great way to create documents in a word processor, but i'm nto sure abut using it for general routines |
| Jordy: | storage format? i thought XML was the storage format and XSL was the view format |
| graydon: | Jordy: well, you'd only return a rule (or perhaps a compiled fragment) if you were matching against an XML doc. Otherwise the key would resolve to something more like a plugin name or a string or something |
| Jordy: | hmmm, it'll give me something to think about |
| stefan: | Jordy: anyway, it's the back end. We'll have a simple idl interface to retrieve values based on contexts. |
| | topic unset by Jordy on #berlin |
| stefan: | Jordy: later, this XSL engine could be used when writing a whole document to a file, so to produce a real XML from the scene graph. |
| graydon: | stefan: heheh, now you're drifting off into the serialization API |
| stefan: | Graydon: right, but just to show the (potential) use of an XSL engine. |
| | esac , sitting in the back row, timidly raises a hand |
| Jordy: | Here is a perfect example of what XSL/XML does: |
| esac: | I'd like to try writing an XSL parser in C++; I'd probably need to ask for some help now and then, but I think it sounds like a good place for me to start. |
| graydon: | stefan: well, basically what we're talking is the ability to pass a stringified representation of a path to a node in an attributed tree and have some stuff come back |
| Jordy: | For example, suppose an employee database has the form |
| Jordy: | <employees> |
| Jordy: | <employee> |
| Jordy: | <name> |
| Jordy: | <first>James</first> |
| Jordy: | <last>Clark</last> |
| Jordy: | </name> |
| Jordy: | ... |
| Jordy: | </employee> |
| Jordy: | </employees> |
| Jordy: | For example, suppose an employee database has the form |
| Jordy: | <employees> |
| Jordy: | <employee> |
| Jordy: | <name> |
| Jordy: | <first>James</first> |
| Jordy: | <last>Clark</last> |
| Jordy: | </name> |
| Jordy: | ... |
| Jordy: | </employee> |
| Jordy: | </employees> |
| Jordy: | shoot |
| Jordy: | stupid cut and paste |
| Jordy: | that's your XML data |
| crashcut: | folks... i'll leave in 15 minutes, sorry. |
| Jordy: | then you use: |
| Jordy: | Then a list of employees sorted by name could be generated using: |
| Jordy: | i hate paste |
| Jordy: | <xsl:template match="employee"> |
| Jordy: | <li> |
| Jordy: | <xsl:value-of select="name/first"/> |
| Jordy: | <xsl:text> </xsl:text> |
| Jordy: | <xsl:value-of select="name/last"/> |
| Jordy: | </li> |
| Jordy: | </xsl:template> |
| Jordy: | there |
| Jordy: | there's your pattern matching |
| Jordy: | i'm not sure how i could use something like that, sure, i could write the frontend to the registrar using it |
| Jordy: | but that isn't exactly practical |
| graydon: | esac: well, I'm not sure which part of xsl we're thinking of parsing. it's actually a bunch of different languages, not all of which we need to gobble. I dunno.. the pattern language would be good. if you could compile those into thunks which matched ent |
| graydon: | entries in the registrar, it's a step in the right direction I think |
| graydon: | Jordy: lets think about the requirements |
| Jordy: | hmmm, alright :) |
| graydon: | Jordy: (1) scene graph customization |
| graydon: | Jordy: (2) processin stored XML into graphics |
| graydon: | Jordy: (3) looking up preferences with defaults and contexts |
| graydon: | (1) involves passing paths to nodes in the scene graph, and having the registrar match XSL template rules against the node we give it |
| esac: | graydon: I'll look over the registrar stuff a bit more (and the XSL pattern language), and write the list with ideas. |
| graydon: | (2) involves the same thing, only using XSM paths not paths through our scene graph |
| graydon: | (3) involves constructing an artificial path |
| | esac has to leave in a minute. It's been nice listening in. |
| Jordy: | hmmm |
| graydon: | In each case, the returned value is an Any, I think |
| graydon: | (1) returns the name of a graphic to load for the current "look" |
| Jordy: | yeah, it's too bad Any processing is so ugly |
| Jordy: | :) |
| Jordy: | alright graydon, i'm starting to get it |
| graydon: | (2) returns something which makes a flow object with its children not-yet-filled-in, a sort o parameterized constructor |
| graydon: | (3) returns an int or a string or something small and simple |
| Jordy: | you guys are thinking of using the registrar for a lot more than what i was planning on :) |
| graydon: | Jordy: but it solves all the issues at once, I think. assuming the above outline is even possible |
| graydon: | I'm a little hesitant to say it is |
| stefan: | Jordy: yes, so it is really on of the basic foundations of berlin |
| esac: | it sounds exciting - worth thinking about! |
| graydon: | since usually an XSL processor knows it's walking a DOM graph, and will walk it a little during the matching phase |
| Jordy: | and i see what stefan wants to do with his resource style configs |
| graydon: | now, if we could adapt out scene graph to look like a DOM graph, and make a dummy wrapper which makes a single straight graph for the preferences lookup, then we might be able to do it. |
| stefan: | Graydon: may be a special Traversal for doing just that ? :-) |
| esac: | Goodbye, all. See you around. |
| | Jordy sighs... man oh man, i'm just thinking about how radically different the registrar will be :) |
| stefan: | bye esac |
| graydon: | like, if corel/app/registration-key could be faked to look like <corel><app><registration-key/></app></corel> |
| graydon: | (not stringified, but at a node-navigation level) |
| Jordy: | whoah, that's different than how i was thinking XML should look like |
| graydon: | then the dom braph navigation would work, it would just think it was walking a really simple dom graph with no attributes. |
| Jordy: | i was thinking more on the lines of <key parent=app name=registrarion-key> |
| Jordy: | actually |
| Jordy: | i did the heirarchy |
| | SignOff esac: #berlin (Work, work, work) |
| Jordy: | it's uh, Test4 |
| graydon: | s/braph/graph/ |
| Jordy: | if you run Test4 while Registrar is running, it'll spit out XML |
| Jordy: | or should :) |
| graydon: | Jordy: well, many encodings can be transformed into one another, it's not a big issue. |
| graydon: | stefan: the only problem with creating a strict berlin->DOM adaptor cursor is that the DOM model is a strict tree. multiple parents might really confuse a DOM walker. |
| Jordy: | i still don't want to store the data actually in XML itself, but i could apply XSL to the internal model that I have there.. but i'd need a good clean way to pass the XSL to the server for it to spit out records |
| Jordy: | and if it spits out records, the records would be in XML i guess |
| graydon: | stefan: like if I write a rule which reaches up into "parent" to inspect some attribute.. a graphic occurs under 3 different parents.. which one does "parent" mean? |
| graydon: | Jordy: yeah, the only part which would even resemble the XSL template rules would be those entries designed to match on document nodes in an XML application |
| Jordy: | how would you recommend passing the XSL to Registrar? :) |
| Jordy: | XSL in C++ doesn't look nice :) |
| stefan: | Graydon: right, hmmm, but from the point of view of the Traversal there is a tree since the stylecontext is part of the external state, too. |
| graydon: | Jordy: the <template> tag needs a "match='pattern'" attribute. store the template under the pattern specified. |
| Jordy: | mmm |
| stefan: | Graydon: so the question of parent has to be asked not to a node but to the StyleTraversal which simply looks up the parent from the current trail. |
| graydon: | stefan: ah, of course. |
| graydon: | stefan: yes, the DAG transforms into a tree under the traversal |
| | graydon smacks himself |
| | crashcut has to go |
| crashcut: | anyone logging ? ;) |
| crashcut: | /set log on someone... |
| Jordy: | i'd log, but i don't think anyone can deal with ansi in my logs |
| Jordy: | hold on, let me turn ansi off and reset |
| crashcut: | awight... |
| graydon: | Jordy: really the big issue is to make it possible take a node path and hand it to registrar, and have registrar hand back a list of everything whose XSL pattern matches that path. |
| | graydon is logging now.. |
| Jordy: | *** Starting logfile IrcLog |
| Jordy: | oh, damnit |
| Jordy: | i guess i can turn mine off |
| graydon: | multiple logs is fine |
| crashcut: | ok... i'll mail the log to graydon tomorrow (MET) |
| graydon: | I have to go in 5 minutes anyway.l |
| crashcut: | have to clean up some msg things ;) |
| graydon: | crash: thanks. |
| crashcut: | bye =) |
| | Signon time : Fri Mar 12 20:16:10 1999 |
| | Signoff time : Fri Mar 12 23:20:28 1999 |
| | Total uptime : 0d 3h 4m 18s |
| | SignOff: crashcut (relay) |