| | Saving Window |
| alexH: | Yeah... I think so..... |
| Arrow: | Hi stefan |
| stefan: | Hi everybody ! (just finished my supper...) |
| Arrow: | jonas thought it was an hour ago...:/ we just were talking about EDT vs EST...:/ |
| Arrow: | 2200 GMT -4 is 6 EDT |
| stefan: | yeah, I've problems with these time zones too. |
| alexH: | Daylight savings messed me up...ehhe.... |
| stefan: | Is anybody logging already ? |
| Arrow: | No...:/ |
| | End of Window Text |
| Arrow: | I would but I just installed BitchX and really don't know how to use it yeet...:/ |
| stefan: | what is BitchX ? |
| Arrow: | I would RTFM if I could find it...:/ |
| alexH: | bitchx is an irc client. |
| Arrow: | Yes...so to log...:) |
| stefan: | ok, I'm using zircon right now and I'm logging... |
| Arrow: | Cool...:) |
| Arrow: | Oh i was thinking..Seems there are more than a few projects out there with OO based graphics...Berlin would seem to be a natural for them.. |
| stefan: | There is OO and there is OO. I think though the Fresco way of life is very elegant one needs some time to get used to it. We are so much brainwashed by Windows, Mac, X... |
| Arrow: | I was thinking of those things that use QT...like MindsEye...and the like..aalso there was a widget set on Fressshmeat yesterday...DPTK from Digital Domain of Titanic fame... |
| stefan: | I just thought how we could avoid entirely the term 'window' in our design. Thnking of about it, what have windows to do with GUIs anyway ? :-) |
| | Arrow has the Fresco tar ball here...:) |
| Arrow: | True...:) Gui could be manipulating 3d objects... |
| Arrow: | i really like the idea of 'abstract' wigets...:) Lets face it...Mac/X/Win are 'old'... |
| Arrow: | I guess you could ask Rasterman...:) He pushed X as hard as he could and is making noises about the need for replacement... |
| | gray (gray@shell1.interlog.com) has joined channel #berlin |
| | gray is now known as graydon |
| stefan: | Yeah, I wrote a C++ wrapper for X11 as part of the OffiX Project and it helped me understand the design of this protocol. |
| graydon: | allo alloo |
| stefan: | hehe, hi Graydon, from Hamilton ? |
| Arrow: | seffan cool |
| | graydon is logging, but would appreciate it if someone else would as well |
| | graydon is in hamilton |
| Arrow: | stefan even |
| graydon: | in an internet cafe |
| | Arrow suggests we be succinct...I-cafe=$$ per hour |
| graydon: | so. when were we scheduled to start, 6 or 7? |
| Arrow: | 6 EDT people were confused |
| graydon: | as always |
| graydon: | ok, wanna get things on the road? |
| | graydon has 6 issues on my list, plus whatever y'all brought along |
| stefan: | Well, I think at 6 pm but look, neither Aaron, Jonas, Brent... are here right now... |
| graydon: | heh. yeah. good point. |
| | graydon sighs. this is rediculous. maybe we should schedule out meetings in "swatch beats" or something. |
| stefan: | Hmm, what are those points. may be we can work on a couple of them already. |
| graydon: | (1) deleting things in the current CVS tree in preparation for release |
| graydon: | (2) the new eGroup and the new BugZilla |
| graydon: | (3) Tie Classes (stefan, you'll like this) |
| graydon: | (4) the general outline of the compositor class |
| graydon: | (5) registrar (issue-which-will-not-die #1) |
| graydon: | (6) style contexts (issue-which-will-not-die #2) |
| | graydon opens up a window to mail a nag message to the rest of the berlin list about coming to this channel :) |
| stefan: | ok, 5 and 6 need at least Jordy online, 2 is of general interest, 1 may be too, so let's start with 4. |
| graydon: | ok, tie classes. |
| graydon: | 1 sec, composing email. |
| stefan: | I'd like to add the following points to your list: |
| stefan: | (7) Prague |
| stefan: | (8) documentation |
| graydon: | yes, of course. added.. |
| stefan: | (9) items of immediate interest (Focus, pty, ...) |
| stefan: | Though all these are really dependant on more people being online :( |
| | Arrow is logging |
| graydon: | ok, well tie classes aren't, so I'll mention them now. |
| graydon: | stefan: do you know what these are? |
| stefan: | I've got an idea, templates to tie classes together, bridge or so (?) |
| graydon: | there's an "alternative mapping" in the corba 2.2 spec for interfaces, which does not involve inheritence, but invovles templatized servant classes doing upcalls into the _impl objects. |
| graydon: | turns out omniorb supports it in 2.7.1, as do a number of other ORBs |
| graydon: | it reduces compile-time dependency quite a bit, since only the impl.cc file using another interface needs to include the interface decl. impl.hh's would not need to include any corba files at all, which would make the amount of cumulative inclusion go wa |
| graydon: | so, while it might be a lot of work, I'm considering trying to port our tree to use them |
| graydon: | oh. issue (10): python & other orbs. have a little to report on that. |
| stefan: | So, GraphicImpl doesn't inherit from Graphic but ties to it ? |
| graydon: | Yeah, ties actually fit in with the kit notion quite well. instead of making a new, say, boxImpl, you make a new _tie_Graphic<BoxImpl,1>, and then BoxImpl itself doesn't inherit from any corba machinery at all. |
| stefan: | Hmm, have to read a bit about it. Looks interesting though templates might bloat the code quite a lot at this point... |
| graydon: | the extra parameter (1) in the template is actually boolean, saying the tie should call operator delete on the impl when the tie is released. ownership management. which is nice, because it makes using flyweights easier. we can just make non-owning ties to |
| graydon: | impls |
| graydon: | yes. it might make code expand a little.not sure. |
| stefan: | He, yeah, (11) GC, how to manage ownership of implementations (which is not yet clear, at least, to me) |
| graydon: | anyway.. I think releasing is important enough at this point to keep tie classes strictly out of CVS until we branch. but I thought I'd mention them. |
| stefan: | Hmm, I think we have reduced dependancies quite a bit. I'd prefer to stick to these for this release at least. |
| stefan: | Right. Good to know, we should experiment with it (Will see whether Henning/Vinoski cover this) |
| graydon: | is that the "advanced C++ programming with corba" book? |
| stefan: | youp. |
| | Arrow was just about to buy that book...:) |
| | graydon wants to get a copy of that. |
| graydon: | it looks very nice. |
| stefan: | :)) |
| stefan: | it's worth the price ! |
| | hunger (hunger@alcatraz168.wohnheim.uni-kl.de) has joined channel #berlin |
| | hunger is now known as Hunger |
| graydon: | hey tobias |
| Hunger: | hi there! |
| stefan: | Hi Tobias, nice to see you here ! |
| Hunger: | hello, stefan. |
| | Alain (pirch@66-107.dr.cgocable.ca) has joined channel #berlin |
| Arrow: | Hi Tobias |
| Alain: | hello\ |
| graydon: | hi alain |
| stefan: | He, Alain, bon soir ! |
| Arrow: | Hello Alain |
| Hunger: | This is my first irc session, so please be patient with me :-) |
| Alain: | Hunger--i'll be |
| Alain: | Graydon (and Stefan & Arrow)--how are you ?? |
| graydon: | hunger: this is a good place to be learning irc. there's a lot of evil irc users out there and none of them are on this network :) |
| graydon: | alain: pretty good. I'm in an internet cafe in hamilton. spent the day hiking the bruce trail and eating strawberries. |
| | Alain started logging |
| Alain: | Gray--cool,hope the strawberry where tasty |
| alexH: | graydon: Toronto eh? Good stuff. :) |
| graydon: | very. plus I got to spend all weekend with gf, which helps. |
| | graydon stares at the clock. this is silly. |
| stefan: | Ok, Graydon, (1): what should be kept for the next release. |
| graydon: | all the capital-letter /src directories |
| stefan: | :) |
| graydon: | the /doc directory, all capital-letter /includes |
| graydon: | all that's obvious. |
| graydon: | how far did you get hoisting libdatatype into prague? |
| stefan: | It's in there (new implementation). We don't need libdatatype any more. (I discussed this with Andrew) |
| graydon: | ok, I'm not using libgfont at all, and have the feeling it'll need (mostly) rewriting anyway to use t1lib. so I think it can go for now. I might reintroduce it a couple layers down in /src/Text |
| graydon: | it doesn't let you access metrics in any good way, which is really the hardest part |
| graydon: | so I'd say that whole datatype dir can go |
| stefan: | Fine. |
| stefan: | What about the unicode stuff ? |
| graydon: | tricky. that never really got off the ground. |
| graydon: | I think it really needs to be integrated with the textkit |
| stefan: | Hmm, I'm even not sure about how much of unicode will go into the stdc++ wstring... |
| graydon: | like, requesting a buffer with a particular set of characteristic behaviour |
| stefan: | Yeah, the bidi algorithm looks like something more suitable within the Compositor |
| graydon: | yeah. you also get things like normalization, where you want a container which normalizes the unistrings it receives from cut/paste and events.. |
| Hunger: | Won't we need unicode below the textkit too? |
| stefan: | I think we should have a Unicode class within Prague which can be used inside Prague as well. Berlin (TextKit) should use this. |
| graydon: | and I'm not sure at all how the coalation/sorting stuff is going to work. clients and servers need to see that stuff occasionally, like specifying a username in prague using unicode. |
| | Arrow is away: (Auto-Away after 10 mins) [BX-MsgLog On] |
| graydon: | yes, I think stefan's suggestion is best |
| graydon: | but saying "A Unicode Class" and specifying what actually goes in it are 2 very different things. |
| stefan: | :) |
| Hunger: | Where can I get some docus on converting to and from unicode? I'd like to try to write up a converter if I can. |
| graydon: | since character data is so prevalent, you probably want to typedef a simple numeric integral type as "unicode" and then write utility classes that go to<->from unicode. |
| stefan: | wchar_t |
| graydon: | hunger: gnu "recode" is good, as is "TCS". |
| graydon: | stefan: no, wchar_t has nothing on conversion. |
| Hunger: | Thanks, graydon. |
| Hunger: | There is a Unicode defined in omniorb by the way. |
| Alain: | umm....if it help,i can write a sample document in both ascii and unicode for comparison ?? |
| stefan: | But isn't this ment to hold a unicode value ? |
| graydon: | stefan: yeah, sorta. it's meant to hold "anything wider than ascii", which isn't always clearly unicode. |
| graydon: | unicode itself isn't even clear on what unicode is, unfortunately, as they've recently started going into 32bit or multi-16-bit chunks. it's bad. we need to decide on certain features to suport. |
| stefan: | Oh, one more reason to factor the different parts of it |
| graydon: | yes. the important thing is that everything in berlin should have access to a normalizer. |
| graydon: | above that, there's some ambiguity |
| graydon: | for instance, when you compare for equality, some locales have concepts which make equality hard to pin down. |
| graydon: | and when you coalate, again, hard to specify. it's locale-dependent. |
| graydon: | but if you have a normalized base form, bit-for-bit, that everyone can get to given a bunch of unicode, then you can always make a stupid coalator and a stupid comparator which just do bit-equality and bit-comparison. |
| graydon: | you wind up in a sticky situation, like in the current XML draft, they had to decide to make XML tag names case sensitive in order to make it at all plausible to do matching in unicode. |
| graydon: | because case-insensitivity is highly locale-dependent. |
| graydon: | I believe there's a normalization algorithm on the unicode technical reports page. |
| stefan: | So, let's put this whole story on the TODO list. We have to use a subset as far as this is not worked out. |
| | Jordy (jordy@24.40.44.141) has joined channel #berlin |
| stefan: | (which should be fairly easi) |
| graydon: | if we had that in prague, say a class "unicodeNormalizer" with a static method "normalize" overloaded to take any possible charset, then the issue would definitely lose some of its urgency. |
| stefan: | Hi Jordy ! (waiting just for you :) |
| graydon: | hey jordy. |
| Jordy: | man, i forgot all about this |
| Jordy: | i went food shopping :) |
| graydon: | good timing dude. I'm paying by the hour here :) |
| Arrow: | Hello Jordy |
| Alain: | hello jordy |
| Hunger: | Hi! |
| Jordy: | alright, now what exactly was the topic? |
| stefan: | Ok. (5), (6): registrar and style. |
| Jordy: | or have I just completley missed the entire meeting :) |
| Alain: | jordy--i'm logging |
| graydon: | Jordy: we were talking about things which need to show up in prague to facilitate removing the somewhat-underspecified libunicode from the tree |
| Arrow: | I have it from the top...:) |
| graydon: | oh, just to note, on that topic, alistair leslie did much of libunicode and probably has some code to contribute to any class in prague. |
| graydon: | Jordy: we're thinking in terms of another release late this month or early next. |
| stefan: | Well, for now we could just put the very linunicode (-2) into a Unicode class within Prague. Someone has to take on this to elaborate features we need in the future... |
| Jordy: | how done is libunicode? i haven't actually looked into that particular tree |
| graydon: | I"m mostly concerned that there be a public, available set of static methods which to conversion and normalization. you usually only realize 90% of the way into something that you're going to need a conversion from some existing ascii-centric system. |
| graydon: | Jordy: not terribly. |
| graydon: | Stefan: can we do styles & registrar last-ish? they have the habit of dragging on for hours :) |
| stefan: | :) sure. |
| graydon: | I'd just like to get all the administrivia and what-to-do-next stuff out of the way, so we can be sure it gets done. |
| Jordy: | well ok, Unicode will need to be basically linked to everything... might be good to keep it seperate from everything else |
| graydon: | Jordy: Prague is linked to everything now :) |
| graydon: | Prague is the ultimate evil! |
| Jordy: | graydon: good point :) |
| | graydon jokes |
| stefan: | Well, as i see Prague, it is a library which could be linked from the server and from clients. That's why I think Unicode belongs there. |
| Jordy: | well, we don't want to make Prague a huge monolithic library do we, everything under one roof sort of deal |
| Hunger: | Good point, but wasen't Prague meant to basically be a hardware abstraction? |
| graydon: | OS abstraction, yeah. |
| stefan: | No ! It's sort of two parts. OS wrappers and convenience classes everyone will need |
| graydon: | hmm. true. the logger class is not an "os wrapper" |
| graydon: | jordy's got a point tho. how gid is prague atm? |
| graydon: | s/gid/big/ |
| stefan: | Some other are not, too. Like the IPC classes. |
| | graydon smacks self. gf is attacking keyboard. |
| Jordy: | hmmm, not sure... i'd tell you but gnome is having a hissy fit right now |
| graydon: | byte-count? is it "too large"? I mean, equally, it's annoying to have 20 different libraries, if the functionality of prague is reasonably static. |
| stefan: | Prague has 300 k right now. |
| Jordy: | that's not bad |
| graydon: | I do know that it's the 1 component I recompile least in berlin.. so I'm not worrying too too much about its "bloat". |
| stefan: | Exactly. I try to cover most ACE parts too (communication layers etc.) |
| Jordy: | Really Unicode is pretty small, the big part is that damn data file |
| graydon: | heh. ACE is *HUGE*. it does everything.. |
| | Eugene (eugene@furrypotato.skankybitch.org) has joined channel #berlin |
| graydon: | dog dog |
| Eugene: | Nano nano :/ |
| Jordy: | well ok, everything which will be required by every client/server should probably go in one library |
| stefan: | Ehm. ACE is huge because it is so configurable. I use just some subset. There are a couple of really good papers about ACE (ACE Reactors, IPC SAP) |
| graydon: | eugene and frances are on the same wavelength |
| Eugene: | eh? |
| graydon: | stefan: oh, I know, I think ACE is really quite sweet. it's jus, well, there's no denying it's enormous. |
| graydon: | anyway |
| stefan: | Yes. |
| Jordy: | alright, I think we've covered that topic |
| Jordy: | next? :) |
| | graydon has set the topic: "bugzilla and egroup" |
| | graydon has set the topic: bugzilla and egroup |
| graydon: | ok, we now have a BTS. bugs.berlin-consortium.org |
| stefan: | He, thanks a lot for that, Jordy ! |
| graydon: | jordy's work. |
| Jordy: | if someone wants to redesign the HTML, go right ahead |
| graydon: | I filed 1 bug in it. it seems to work. file more! |
| Jordy: | I basically just removed the bugzilla logo :) |
| stefan: | there are bugs ??? ;) |
| Eugene: | Might have a wee look at the HTML then |
| graydon: | jordy: I think we need to set up some categories. |
| Jordy: | yeah, there aren't any categories either |
| Jordy: | if someone wants to come up with a list of modules to report bugs on, basically bugzilla has two peices, seperate programs to report bugs on, and components of those programs |
| Eugene: | When I had a looksee it bugzilla it looked like a damn nightmare to work on. |
| Jordy: | wasn't too difficult, export a few SQL commands, rework the interface, get 500 perl libraries |
| Jordy: | but it seems to work ok, cept that bug reports link doesn't seem to do anything |
| Jordy: | i take that back, it does do something |
| Eugene: | Speaking of perl - I read you need someone to code some perl - what do you want doing? |
| graydon: | we also have an "egroup", on www.egroups.com |
| stefan: | He, Eugene, you like Perl, I think I have something for you ! (later...) |
| Eugene: | mmmkay |
| Jordy: | I wish I knew where that damn TestProduct is coming from |
| graydon: | which is a really nice forum for posting things you want done, patches you want to have someone look at, documentation fragments, etc. |
| stefan: | You mean because of it's structuredness ? |
| Jordy: | i like their calender, but i wish it showed when particular things ended |
| graydon: | I just thought I'd mention those resources. I'll also post links to them on the berlin site so as people can use them who are just getting into berlin. |
| graydon: | stefan: yes, also because it's not my inbox. I've got my email address all over the berlin website, when in fact there's a whole bunch of people who can integrate patches, submit documentation to CVS, etc. |
| graydon: | stefan: if you post something to the egroup, everyone with berlin CVS r/w has a chance to do it. |
| graydon: | stefan: instead of making me the bottleneck, which clearly won't scale. |
| stefan: | you're right. ...which takes us back to another topic...:) |
| graydon: | stefan: ? |
| Jordy: | what other topic stefan? |
| | CTCP PING 929316484 797651 from Jordy |
| stefan: | How to do this ssh/cvs thing ! |
| Jordy: | export SSH_RSH=ssh |
| Jordy: | export CVSROOT=:ext:gray@va.debian.org:/cvs/berlin |
| stefan: | no, I mean how to do it preserving the users identity |
| graydon: | stefan: you mean in the long run? in the long run we get our own machine and make separate accounts for multiple people, hire a sysadmin, and take over the world of course. |
| Jordy: | oh, i could have sworn there was a way to do that |
| stefan: | Well, I ment in the medium run then :) |
| Jordy: | like use pserver over ssh |
| graydon: | <sigh> ok, that's another administrivia todo. I know someone on master.debian.org can help us with that if we bribe them enough, but I want to get this meeting over with this weekend. |
| graydon: | preversions! |
| | graydon asks forgiveness. gf is typing oddness. |
| stefan: | who is gf by the way ? |
| stefan: | alter ego ? |
| Jordy: | well what happens if we just use :pserver:email:/cvs/berlin after CVS_RSH is set? :) |
| graydon: | (g)irl(f)riend. |
| stefan: | oh, from Montreal ? Salut !! |
| graydon: | Jordy: cvs will not engage the external ssh. |
| graydon: | stefan: from toronto, but whom I was talking to in montreal, yes. |
| stefan: | :) Sorry my indescriteness (?) |
| | graydon has set the topic: "compositor " |
| | graydon has set the topic: compositor |
| Jordy: | what's a compositor? :) |
| graydon: | the golden question |
| graydon: | it's a layout manager for text |
| graydon: | essentially |
| | Aaron (aaron@d216.pm13.sonic.net) has joined channel #berlin |
| Jordy: | alright, i've heard about people having problems laying out text |
| Aaron: | yellow |
| Hunger: | Hi Aaron |
| Aaron: | when did we start? |
| stefan: | Aaron !!! ji ! |
| graydon: | which compares the metrics of text rendered under a "canonical" drawingkit vs. the drawingkit which is currently traversing a scene. |
| Aaron: | Something came up yesterday, just got ome 5 mins ago |
| graydon: | and compensates for the errors introduced by the current drawingkit, either from hinting or from font mismatching. |
| graydon: | I thought I'd mention that. it's not really done in any appreciable way, but it'll evolve into quite nice adaptive text layout. |
| graydon: | and it's in the textkit, which is something I've been spending time on. |
| graydon: | a little, anyway. |
| | graydon notes the silence. a dead topic perhaps.. |
| Jordy: | not one of the things I have any experience with :) |
| Jordy: | I still suggest stealing MOzilla's :) |
| graydon: | Jordy: heh, might happen :) mike shaver of mozilla is in toronto now, apparantly I might be bumping into him sometime soon |
| Jordy: | well there just happen to be a lot of things in Mozilla which would work great with Berlin |
| | graydon has set the topic: "Documentation " |
| | graydon has set the topic: Documentation |
| | Signoff: alexH (alexH has no reason) |
| | graydon makes a mental note on other topic: mozilla XUL |
| graydon: | stefan: you found a new doc tool? |
| Aaron: | sinze mozilla is fairly well covered with CORBA interfaces. |
| graydon: | Aaron: surprisingly, it is not. |
| Aaron: | 1: comented code |
| Aaron: | ;) |
| Jordy: | my style for commented code is, comment anything that will confuse someone, but dont' comment the basics |
| | graydon wonders if stefan is here.. |
| Jordy: | i mean, we don't need to put in a comment every time we define a variable :) |
| stefan: | He is (sorry) |
| Aaron: | my ag is real bad right now. bear with me, I'll try to not to talk too much |
| stefan: | the doc tool I found is written in Perl, looks incredibly flexible and is called perceps. I playd with it a bit and it seems really the thing we need. |
| graydon: | ooookay. well my plan is still thurough docbook. I've been making disgrams in argo, and should continue to do that to make some of the tricky bits clearer. |
| Aaron: | stefan: you got a URL? |
| Jordy: | perceps? |
| graydon: | stefan: cool. like, makes HTML/SGML? |
| stefan: | That's the thing I'd like to propose to Eugene. Someone has to adapt it a bit and write template so it outputs (Berlin conformant) docbook docs. |
| graydon: | http://friga.mer.utexas.edu/mark/perl/perceps/ |
| | alexH (thanks@cr622414-a.etob1.on.wave.home.com) has joined channel #berlin |
| stefan: | I think it can output *anything*. You just give it a couple of templates where you define how you want class, interface, method etc. docs to appear and... |
| graydon: | woah, it makes java applets too? |
| Jordy: | java applets? |
| Jordy: | wow |
| stefan: | It can use one. I didn't look into this further since I was most interested in docbook like stuff. |
| Eugene: | I can have a wee look. |
| graydon: | this is pretty cool. ok. yeah. I'm not sure if API-based documentation and "how the thing works" documentation need to be blended in our case. |
| stefan: | It has a java applet for the class tree. |
| stefan: | Graydon: no, I'm in favor of a tutorial (completely hand written) and a reference manual (automatically generated) |
| graydon: | stefan: yeah, I think you're right. |
| Eugene: | Mmkay, seems relatively straight forward. I will bookmark it, and have a looksee when I ger home from work tonight :) |
| graydon: | stefan: I find myself, when writing the reference docbook, doing a lot of things which ought to be machine-generated (enumerating all the methods in a class with brief descriptions, say) |
| stefan: | That would really be great since I think this is a good starting point to explain in detail the implementation of certain algorithms. I'd really like to start on that ! |
| graydon: | ok. cool. well I certainly like what perceps seems to be capable of. |
| | Eugene doesnt know anything about docbook - do we have anythink I can take a look at? |
| stefan: | So write it onto the TODO list. |
| Eugene: | BTW - how up to date are the debs - I will alien them to slp and have a look. |
| Eugene: | I cant get my damn CVS to work. |
| graydon: | Eugene: ignore current debs. we're releasing new ones. |
| Eugene: | mmmkay |
| | graydon has set the topic: "Python & Other ORBs" |
| | graydon has set the topic: Python & Other ORBs |
| graydon: | ok, I took the time to make warsaw compile to stubs & skels on fnorb |
| graydon: | it involves a little fiddling with the C preprocessor and some perling and grepping |
| Jordy: | Python? |
| graydon: | YEah. |
| graydon: | I was looking for something to do testing with |
| Jordy: | why are we going into the whole VM deal? :) |
| graydon: | cheap, fast testing of the display server |
| graydon: | not Python-in-the-server, just Python-as-a-way-of-running-tests |
| stefan: | Sorry, what has Python to do with VM ? |
| Jordy: | I mean, if we are going to use any language it might as well be Java, which has built in ORB |
| Jordy: | stef: isn't python interpreted? |
| graydon: | I think jordy misinterpreted my /topic. I'm talking about testing. |
| Jordy: | graydon: ok, misunderstood |
| stefan: | Jordy: It is. But is every script considered running on a VM ? |
| Jordy: | but still java would make a more logical choice, since it has a built in ORB and is similar in syntax to C++ |
| graydon: | I was looking about, and could not get any of the perl ORBs to work quite right |
| Jordy: | stef: yes :) |
| Aaron: | python is good. |
| graydon: | Jordy: yes, java is my next candidate for testing |
| Jordy: | perl, java, etc all run in VM's |
| graydon: | Jordy: the problem is that the java2 stuff, including the ORB, is decidedly nonfree and nobody has made a free clone. it's all under sun restrictive license. |
| Aaron: | Jordy: there's a big difference though. |
| Aaron: | but you know that |
| Hunger: | Does any of these ORBs support the security service? |
| Jordy: | graydon: no GPL java2 yet? hmmm |
| Aaron: | Hunger: the security service is underspecified right now |
| Aaron: | CORBA 3.0 will have a much more complete spec |
| graydon: | I personally find python kinda grody, but I'm not sure if that's just lingering impression from a bad python talk I once attended. Anyway, does anyone object to developing a test framework in python? |
| Aaron: | does anyone feel like doing it, is the real question. |
| Hunger: | Aaron: I know, but some commercial ORBs have it anyway. (Don't ask me how they did it though ;-) |
| Aaron: | perl would be better, but if nothing works nothing works |
| Jordy: | graydon: does python have an ORB? |
| graydon: | Aaron: I feel like doing it. I'm getting tired of making these one-off test clients which take 5 minutes per compile/link, just to test 1 feature in the server. |
| stefan: | I'd prefer Python since it is OO. |
| graydon: | Jordy: yeah, fnorb. it's a little wonky, but seems to work. |
| Aaron: | stefan: perl is OO too. |
| graydon: | Perl is my preference too. |
| Jordy: | graydon: if the only reason not to go with java is that it's not GPL, I donno |
| graydon: | if anyone wants to try and get a perl ORB working, I'd like to see that.. |
| Jordy: | I only suggest Java because it's ORB integration is quite nice |
| graydon: | Jordy: I know, I'd really like to develop some stuff in java for berlin as well. |
| Aaron: | are there any free JAVA orbs? |
| Jordy: | aaron: java has an ORB built in |
| graydon: | Aaron: yes, there are |
| Aaron: | I know TAO has java bindings but it's not really a JAVA orb |
| graydon: | Jordy: 1.2 has an ORB built in. 1.1 does not. |
| Jordy: | i could have sworn I saw a 1.2 open source java implementation |
| graydon: | Jordy: I dunno. It would do for testing. I'd hate to develop a dependency on nonfree stuff tho. |
| stefan: | Graydon: are you speaking of xset ? |
| graydon: | Jordy: if you find one, please let me know. |
| Aaron: | I would just like us to bear in mind that Berlin can't end up depending on java because of its non-freeness |
| graydon: | stefan: not in particular. I read its source and it's not as well suited as I'd hoped. |
| Jordy: | oh, kaffe defines part of java 1.2, but it doesn't say anything bout the ORB |
| | graydon hmms. ok. worth looking into. |
| stefan: | Graydon: but they made quite a bit of noise about it... |
| | graydon has set the topic: "static build & profile" |
| | graydon has set the topic: static build & profile |
| Jordy: | static build? why would we want to do that? :) |
| graydon: | I mangled the build enough to make it statically link, which is necessary for profiling. |
| Aaron: | Jordy: debugging/profiling |
| stefan: | Graydon, did you look (compile) into what I've send you ? |
| graydon: | turns out -pg doesn't work at all across dynamic libraries. |
| graydon: | stefan: not yet. those 2 clients? |
| stefan: | I removed some bugs which seem now to make the run a bit faster... |
| Jordy: | really? huh, I didn't know that |
| graydon: | Jordy: yes. pissed me off. |
| graydon: | stefan: really? which bugs? |
| Alain: | i did a quick surf of freshmeat and found JavaORB,not sure if it's usefull though: A free Java implementation of CORBA 2.2 |
| Aaron: | so how big is the whole thing statically linked with all the necessary symbols? |
| | Alain continue searching |
| graydon: | with -g -pg it's 27 megs. |
| Aaron: | sheesh. |
| | Aaron has to reboot, brb |
| stefan: | well, first the 'clear all' in the ScreenManager, then I now use a rectangle from the FigureKit. So we can concentrate on inheren timings, not timing due to ORB... |
| graydon: | nontrivial. also it seems to crash almost instantly into a traversal. |
| | Signoff: Aaron (brb) |
| graydon: | anyway, I'd like to get "make profiling" working in the build tree. I'm going to put that on the todo list for anyone who really likes makefiles. |
| Jordy: | 27 megs, my lord |
| graydon: | I can explain how to do it. it's just a pain in the ass. |
| stefan: | I think I prepared the Makefiles for profile makes. I never did it though. |
| stefan: | It shoulod compile not into obj/ but into prf/... |
| graydon: | ok, well I'll put all the info I discovered during the process on the todo item, and that should get us closer.. |
| Jordy: | well wouldn't we just build the libraries with 'ar' instead of ld and then link using -static? |
| | Aaron (aaron@d216.pm13.sonic.net) has joined channel #berlin |
| graydon: | there's some difficulty, since the GenericFactory still has to use plugins, sorta. I'm not sure. possibly the plugin loader should actually have a "static" form as well, since otherwise we'll not be able to profile anything in a plugin. |
| stefan: | Jordy: right, we would need to compile with -pf, too to include the tags for the profiler to hook on. I guess this makes it that huge. |
| Jordy: | not to mention -g if we want debuggin :) |
| graydon: | 27 megs may be artificially large, since I did -g -pg and turned off -O |
| graydon: | but I think those are the right flags if you want to do profiling. and my god it's slow! |
| Jordy: | hahaha |
| stefan: | Graydon: oh, but couldn't we debug or profile one kit at a time ? |
| graydon: | stefan: yeah, I'm just not sure if -pg works nice without -g turned on. anyway this is taking valuable time. I'm gonna have to get outa here soon, so lets move on. |
| stefan: | by the way, turning of -O should not make code larger, on the contrary... |
| graydon: | registrar? |
| stefan: | ok. |
| stefan: | registrar & styles. |
| | graydon has set the topic: "registrar " |
| | graydon has set the topic: registrar |
| | graydon has set the topic: "registrar and styles" |
| | graydon has set the topic: registrar and styles |
| stefan: | thanks :) |
| graydon: | ok, it's been a while since the last meeting where we had that meltdown over how to integrate styles and registrar entries |
| graydon: | and after much mulling over I'm still no more convinced how to do it. :( |
| stefan: | Let me explain my current point: |
| Jordy: | i thought about it for about a week after the meeting |
| Jordy: | and decided that it'd be easier just to do styles somewhere else :) |
| graydon: | only that (1) they are related, (2) they should be possible to do efficiently |
| stefan: | The scene graph is logically tree. (it might be optimized into a DAG though) |
| graydon: | Jordy: well, the point I guess imo is that some registrar entries are sorta "pattern-ish" as well |
| Jordy: | true, I could implement some style-like features |
| Jordy: | like regex patterns and what not |
| graydon: | Jordy: like, "text editor component ID" really happens in multiple contexts |
| Jordy: | but building a full system like what X resource files have might be a little overkill |
| graydon: | Jordy: yeah. it's not strictly a single-path-to-key feature set. |
| graydon: | Jordy: heh, X resources would be easy compared to XSL template rules, I suspect. |
| graydon: | Jordy: but this is inconsequential since none of us have actually taken the time to try it. |
| stefan: | Jordy: I think the X approach is what we should aim at. At least in functionality. (though I don't see the need for the class/instance separation) |
| Jordy: | graydon: there is one feature that I'm contimplating putting in and that would be array data types |
| Jordy: | so one key multiple data settings, an emum basically |
| Jordy: | but from what I can see with the X resource files |
| graydon: | Jordy: I keep looking at sleepycat.com's page and thinking we're just asking for corruption in the database, writing our own DB. |
| Jordy: | the major reason for using that style of configuration is just to get a number of keys based on a particular regex, and that I can implement |
| Aaron: | Someone brought up LDAP but I think that isn't right. |
| Jordy: | something like, getKeyRegex("/system/berlin/fonts/*/18/bold/*/arial") |
| Jordy: | or something :) |
| Jordy: | i mean if that's all your asking for, I can do that |
| Jordy: | I could also set keys that way |
| stefan: | He, could we forget about registrar and only talk about what styles should support, first ? |
| | Signoff: Chalky (Read error to Chalky[p52-max3.mel.ihug.com.au]: No route to host) |
| | graydon is so frustrated with this issue. it seems like it should be easier. |
| Jordy: | setKeyRegex("/system/berlin/fonts/*/18/bold/*/arial", "/usr/share/fonts/arial.ttf"); |
| Jordy: | is that all you want to do? |
| Aaron: | I think that berlin would benefit from presenting a generic registrar interface so we can tie in other DBs if we choose later on. Have registrar as a server module, you know. |
| graydon: | Jordy: tree regexes might be sufficient. I don't know. |
| Jordy: | aaron: it's in the TODO file :) |
| stefan: | he, we are mixing interface and implementation ! I'd really think of what I want (use cases) before thinking of how we get closer to it !!! |
| Jordy: | aaron: i want to rip out that god aweful database implementation I have in there ;) |
| graydon: | Stefan: agreed |
| Aaron: | so what does the API need to do. |
| stefan: | So what do we want the Styles to do ? |
| | CTCP PING 929621591 290079 from Eugene |
| graydon: | stefan: the issue in my mind is that most "key lookups" are really component configuration, which is closely related if not identical to component-styling |
| Jordy: | yeah, give me a set of situations where you'd use styles |
| | Aaron pipes down |
| stefan: | I think, Styles are part of the 'external' state of Graphics. |
| | Signoff: alexH (gotta go...must learn more about berlin :)) |
| graydon: | "window font size" |
| graydon: | "application locale language" |
| Jordy: | well wouldn't a window font size be some sort of default setting? :) |
| graydon: | "background color" |
| stefan: | Look at a scene graph. You might want to set colors etc. for all the nodes differently. |
| graydon: | "bevel width" |
| Jordy: | /system/Berlin/settings/currentstyles/windowfont |
| stefan: | Graydon: right. |
| Aaron: | are there going to be observers looking realtime at registrar settings? |
| graydon: | Jordy: right, so what if I want to set the preference "*/fontsize" == 12 |
| stefan: | So, somehow, the StyleManager has to look like a real tree (compared to the scene graph which might be a DAG) |
| Jordy: | aaron: yes, complete with the ability to watch keys |
| graydon: | Jordy: or "mozilla/*/fontsize" = 12 |
| Aaron: | ie should one app be able to change another node's settings |
| Jordy: | graydon: that I can do since it's just a basic regex |
| Jordy: | i mean if all you want is filesystem-style regexes |
| Jordy: | that's easy to implement :) |
| Jordy: | if all you want is the equivilent of: echo "12" > /tmp/*/fontsize |
| stefan: | So, given that, we have the requirement that StyleContexts are nested (since if you only specify values for the root node they should be valud for the whole graph etc.) |
| stefan: | Jordy: I think you are still argumenting in terms of implementation ! |
| graydon: | Jordy: but, as we went over in the last meeting, if you'll recall, it inverts the lookup mechanism of the registrar. the stored key is "*/fontsize", which should match a query for "foo/fontsize" and "bar/fontsize" |
| Jordy: | graydon: exactly |
| Jordy: | that's easy, getKeyRegex() would look at the pattern, match it against other particular keys and then traverse their trees to find a matched key, return that key and any others in a big sequence |
| Jordy: | i could set and get keys using that method, no problem |
| graydon: | jordy: well, echo "12" > /tmp/*/fontsize is not what I mean. that individually sets existing nodes as having 12 as their font size. I'm saying, store the pattern "*/fontsize", and regardless of what is looked up, if it matches that stored pattern, the ke |
| stefan: | Let one node of the 'style tree' hold a set of name value pairs which the DAG node can choose from. Either it knows the name than it can use it or it doesn't than it might simply pass it to it's children. |
| Aaron: | graydon: I see what you're saying |
| graydon: | stefan: provide more details |
| Jordy: | oh, you want to store the pattern itself |
| graydon: | jordy: yes. |
| Jordy: | oh boy, when you start deal with matching regexes.. |
| graydon: | jordy: that's the fundamental shift between registrar-as-it-is-now and registrar-as-I'm-proposing |
| graydon: | Jordy: well, not quite, as any query has a specific real instance node in a real tree. |
| Aaron: | won't that start taking lots of resources to just match simple keys? would it not be more efficient to actually store that info in the individual nodes? |
| Jordy: | yeah aaron |
| graydon: | Jordy: like, mozilla would not look up "*/fontsize", it would look up "mozilla/fontsize" (since it is mozilla). |
| stefan: | Graydon, Jordy: I'd not put the pattern in the tree. I'd rebuild the tree once the pattern changes. The tree may for now look like the logical scene graph *no sharing). So it might specify a map of names/values for a given node and override/extend this pam for child nodes. |
| Jordy: | it would really start sucking down resources |
| Jordy: | graydon: i get it |
| Jordy: | if mozilla/fontsize exists, use it, if not use */fontsize |
| graydon: | Aaron: no, it's not going to cost anything particularly heavy. |
| graydon: | Aaron: except our time in implementing it. |
| stefan: | The point is that you can rebuild the tree (which takes some time) once you change the patterns or the settings. You might merge different trees (default, user etc.) given priority info etc. |
| Aaron: | graydon: if you have regexps that might match any key, you have to compare each possible regexp with the key you're trying to find, and regex engines aren't cheap |
| Jordy: | but i'm thining we could probably do defaults much easier than using regex patterns |
| graydon: | stefan: yes, of course there's an optimized form. you must store the un-merged rules tho, in order to make it editable. |
| Aaron: | now if you use a fallback mechanism where regex matching doesn't happen every time a key is looked up, then you're fine. so nevermind. |
| Jordy: | why not go the windows route, instead of regex's provide a .default sorta setting |
| stefan: | One important point is to optimize out nodes which don't modify the given map. But that's an implementation detail which shouldn't affect the design the least possible. |
| graydon: | Aaron: you're assuming linear match through a set of regexps. that's not how you do it. you do it using tree matching with backoff, like a logic engine. |
| graydon: | Aaron: trust me it's not that slow. |
| Aaron: | ok |
| Jordy: | no, it's not slow... i can think of a few different ways to implement it, but it will either eat up ram or disk space |
| | graydon has to go in a few seconds. |
| stefan: | Graydon: sure, but these rules are not traversed with every traversal while the current tree is. |
| graydon: | Stefan: yeah, then it could get costly. |
| graydon: | Stefan: how do you cache it? |
| graydon: | Stefan: such that each traversal does not recompute styles? |
| stefan: | Graydon: my understanding of the flyweight pattern is that the style is part of the external state so we have to provide it as part of the context, which means that we have to construct it on the fly... |
| graydon: | stefan: mm.. ok. perhaps. keep talking. sorry, I have to go. time's up. |
| Jordy: | hmmm |
| stefan: | (constructing means just traversing the style tree in parallel) |
| Aaron: | bye gray |
| Arrow: | Bye gray...I'll email my log...:) |
| Alain: | Graydon--only way i think as of now of free java on linux is japhar and the java compiler that's part of egcs |
| Hunger: | Bye, graydon. |
| graydon: | stefan: ah. flash of insight. I see what you mean. the style tree is a cache of the unrolled DAG flyweight state. yes. I totally, totally agree. |
| graydon: | later folks. |
| | Signoff: graydon (Leaving) |
| stefan: | fine, Graydon, bye then |
| Alain: | see ya Gray |
| stefan: | Hmm, should we discuss this style thing further ? |
| Jordy: | i'm still having problems visualizing the need :) |
| Jordy: | to be honest |
| Jordy: | I can understand using styles to create a look of applications, like mozilla XUL's |
| stefan: | Hmm, you see the DAG of graphics we use now ? |
| Jordy: | no stef, I haven't really taken a close look at it |
| | Alain possible strong suit may well be documentation |
| stefan: | You might want to set styles for any graphics in the scene graph. Though you certainly won't do it we must be prepared for it. I think it is possible to use an implementation which can take advantage of nodes not adding/modifying styles. |
| stefan: | Jordy: the scene graph contains graphic nodes. We use the flyweight pattern which means that since we really will use a lot of nodes to create a scene, individualk nodes will store as least info as possible and recompute as much as possible when needed. |
| Jordy: | right |
| | Chalky (chalky@p4-max8.mel.ihug.com.au) has joined channel #berlin |
| dpkg: | [Chalky] Inconceivable! |
| Arrow: | I see your point...take E themes...Berlin will use some window manage function....so some elements of the scene will have a complimentary style...Right? |
| Alain: | stefan--is the todo list up to date on the website ?? |
| stefan: | For example individual nodes don't have any idea of where on the screen they appear. Instead, for each layout depending method the 'allocation' is passed with the traversal object. |
| stefan: | Alain: not exactly. I just proposed some major changes. |
| Alain: | ok |
| Alain: | brb |
| Jordy: | well, individual nodes don't have to care about where they are on the screen, they only need to care about nodes which are lower on the heirarchy |
| stefan: | Jordan: so it seems natural to pass the style together with the traversal since even though you use the same Graphic somewhere, it's style may differ. |
| Jordy: | hmmm |
| | Aaron has set the topic: "Berlin: networked, interoperable display server" |
| | Aaron has set the topic: Berlin: networked, interoperable display server |
| stefan: | Jordy: nodes may be shared, which means that a node can have multiple parents ! |
| Jordy: | oh man |
| Aaron: | and multiple children. |
| Jordy: | give me an example of a node which has multiple parents? |
| Aaron: | simultaneously |
| Jordy: | i understand multiple children |
| Aaron: | the same letter glyph perhaps |
| Jordy: | ok, so instead of having 90 of those glyphs we have one and we assign them to various nodes |
| stefan: | Jordy: Imagine some vector graphic, for example a car. It has two tires. Since a tire might be somewhat complex, you create it once and use the same for both. |
| Hunger: | Jordy: Think of an application on a teachers system that is simultaniously shown on the computers of students. |
| Jordy: | ok, understood |
| Aaron: | instead of recreaging a 'g' for every application that needs a lower case g, berlin creates one and all apps use that. |
| Aaron: | recreating rather |
| Jordy: | alright, a way to save memory basically :) |
| Alain: | stefan--don't know if it's unrealistic,but could it be possible that the wm part of berlin be configurable with html and/or xml (kinda like active desktop under doze98) |
| stefan: | Ok, let's stick to letters. Given the letter 'g'. Once you want it to appear green, once blue. |
| Jordy: | so we have this horrible mesh of nodes |
| Aaron: | can fonts be different ? |
| Aaron: | or is an entirely new glyph needed |
| Jordy: | heh, so we have a node with more than one set of properties |
| stefan: | Jordy: it's actually not that horrible. It only looks so because it is highly optimized. However, for the styles we can't use the same optimization. |
| Jordy: | ok, we want 2 'g's, each in two different applications, both seperate colors |
| stefan: | Jordy: imagine a HBox which contains twice the letter 'g', position 5 and position 11. |
| stefan: | Now, how are you going to tell them that the first (pos 5) should draw in green and the second (pos 11) should draw blueish ? |
| Jordy: | stef: secondary tree of properties assigned to each node with information specific to their parent node |
| Jordy: | ie, parent=5 property sheet says green, parent=8 property sheet says blue |
| stefan: | You would need some style tree which the traversal traverses in parallel with the DAG so that the letter 'g' (the corresponding class instance) can query the color from the traversal. |
| Jordy: | hmmm |
| Aaron: | or a class for children that holds both a pointer to the Graphic_var and some list of properties. |
| Jordy: | and you want to put that hellish thing in the registrar? :) |
| Jordy: | wouldn't it be better just to keep it in RAM somewhere :) |
| Aaron: | so when a property is requested, the traversal moves up one and looks up that property |
| stefan: | When the traversal calls graphic->draw(traversal) for the green letter, the node should get 'green' when asking the traversal for traversal->style("Color"). |
| Aaron: | Jordy: what if we made the registrar an asynchronous combination of disk space and memory? ;) |
| Jordy: | well |
| stefan: | Jordy: wait. the registrar (as the DB engine) is just a means to make the settings persistent. Sure the settings for the actual scene graph should be kept in memory. |
| Jordy: | you'd end up with a very slow deal, the problem is the CORBA interface.. why do network calls for the color green when you can store the color green in with the node itself |
| Jordy: | ie, parent->g->color; |
| Aaron: | Jordy: so have a local mechanism for caching recent data in the server |
| Jordy: | parent2->g->color would go to some other place |
| Aaron: | store a topheavy hash tree in memory |
| stefan: | Jordy: yeah. Now imagine that for a given nesing level of the scene graph you have a set of name value pairs. |
| stefan: | s/nesting/nesting/g |
| Jordy: | aaron: even with a caching method, we'd still incur too much latency, better to have it stored with the glyph itself in memory |
| Jordy: | there is no need to do 300 registrar lookups for colors every time you paint a text document :) |
| stefan: | Jordy: if it is kept with the graphic, we reduce the possibility of sharing it a *lot*. |
| Aaron: | Jordy: then apps have to deal with two different DB APIs. maybe if all settings were kept with the scene graph and the registrar were entirely transparent? |
| Arrow: | There might be some answers from some groupware sources...they have to cach.. |
| stefan: | Jordy: no ! the tree is in memory. you don't lookup anything from the data base when traversing the scene graph. |
| Jordy: | hmmm |
| Aaron: | where's the free CORBA implementations page?? |
| Jordy: | well i'm just thinking how other GUIs do it.. |
| stefan: | Jordy: all Berlin sees is the Styles presented by the Traversals. The fact that they are stored in an external DB is part of the implememntation. |
| Jordy: | aaron: linas.org/linux |
| stefan: | Jordy: I think the X protocol is not that bad for this. |
| Jordy: | you know I seriously need this all drawn out :) |
| Jordy: | i'm just thinking about how you'd want to store properties assigned to each widget, and you are right.. they probably should go in the registrar |
| stefan: | Jordy: if a user changes a setting, it should apply only to one particular DB (which is merged in based on some priority rules). |
| Jordy: | and if you shove a little mini-registrar which is cache-only on each machine running berlin, it would probably work quite well |
| Hunger: | I'll go to bed now. Will the logfile get posted to the list? |
| | Aaron attempts to get COPE working |
| Arrow: | Tobias Yes...:) |
| stefan: | Jordy: I still think that an XML file per application is the right thing. It's the natural extension of app-defaults files and it is very extensible. Finally we could specify the whole GUI in terms of the XML file and only code the 'model' in terms of a programming language. |
| Alain: | Hunger--yes |
| stefan: | Tobias: I'm logging too, don't worry ;-) |
| Hunger: | Alain & Arrow: That's great. |
| Jordy: | isnt' XML a definition language? you want something like XSL |
| stefan: | Jordy: sure. |
| Jordy: | which is the actual style language |
| Hunger: | Bye! |
| | Signoff: Hunger (using sirc version 2.211+4KSIRC/981227-pre0.9) |
| stefan: | Jordy: AFAIK XSL is the style part of XML |
| Jordy: | yeah, XSL/XML would at least make my life easier, because I can understand how to store those types of style defintions |
| Alain: | i have a byte mag who explain the entire picture of XML |
| stefan: | Jordy: the whole point would be how to merge two XSL/XML files (based on what rules) |
| Alain: | if anyone of you would like to have it,let me know |
| Jordy: | so our XSL files would basically be equivilent to the app-default files of X.... |
| Jordy: | see if you are looking for XSL style things, there is a very clear defintion on how to store XSL in a tree |
| stefan: | Jordy: to start with, yes. Though I'm not sure where to stop. It really seems very powerful. Graydon told me recently that Mozilla's approach is to specify the whole UGI in terms of a XML file, so you would need to interpret the XML file by a parser which builds part of the scene graph... |
| Jordy: | but what about properties which change on the fly? :) |
| stefan: | Jordy: give an example, please. |
| Jordy: | mmm, let me think :) |
| Jordy: | well say we type the letter 'g' in a text editor and change it's color to red |
| Aaron: | ILU has an alpha perl binding |
| Jordy: | the way mozilla deals with styles is a bit much, they use javascript to define how their interface responds |
| Alain: | brb,have to do a phone call |
| stefan: | Jordy: well, forget about this thing for now. Just styles. I think the (logical) tree structure is reasonable. The question is then how to reduce (collaps) it depending on where the set of styles really changes (so effectively you only store the diffs) |
| Jordy: | hmm |
| | Alain 's back |
| stefan: | The tree iterator (cursor) would need to implement the needed intelligence to make the tree look real. |
| stefan: | Or may be that's just the Traversal's job. |
| Jordy: | how soon does this really need to be implemented? |
| stefan: | Jordy: Hmm, as soon as possible. Sure, we could use default settings for now but right now we use statically bound styles. This gets a bit awkward when the scene graph gets larger. |
| Jordy: | So our styles define, I want every font to be red, I want every box to have a 2 pixel border, etc... when we create a box... we apply the stylesheet to it and it now says it has a 3 pixel border... |
| stefan: | Jordy: exactly. |
| Jordy: | what you want me to do is store these settings somewhere in the registrar... and I'm just trying to think about how I can :) |
| | Aaron plays with cope |
| Aaron: | there are three perl orbs |
| Jordy: | I mean, I'm not sure if regex's are an optimal way to do it... what you want is; a general default, an application specific default, and a node specific default for every single style-related setting |
| Jordy: | so the question is, when you want to construct a font which the style sheet says should be red... how do you want to query the registrar? :) |
| stefan: | Jordy: not exactly. I'd like to figure out how to design the interface to styles. Once we come up with a reasonable API, we should think of how to implement styles. Once we found out how, we should think of how to make them persistent. And only the very last point involves the registrar (at least how we now see it). Though one day the Registrar might be identical to the full StyleManager which not only cares about persistance but also about all the other features. |
| Jordy: | right, we dont' need the registrar for anything but persistance as far as I can think of, settings which are different from the style sheet like window size |
| stefan: | Jordy: at least I see a tree the best way to keep styles for a running display server. |
| Jordy: | you want a standard interface for doing this... ok, so LoadStyle() everytime we construct a new node on our scene graph |
| | alexH (thanks@cr622414-a.etob1.on.wave.home.com) has joined channel #berlin |
| Jordy: | LoadStyle(node)... which would go through and check the registrar to see if there is a persistant setting, then check the registrar to see if there's a default setting, and then check the actual hard coded stylesheet to see if there's a default setting |
| stefan: | Jordy: you should look how allocations are passed to nodes. There is no way asking for a specific allocation. Allocations are passed along with Traversals. Outside they are simply never needed. The same holds for styles. That's why I think we should bind styles tightly with Traversals. |
| Jordy: | huh, the time on my machine must be way off |
| Jordy: | stefan: hmmm |
| stefan: | Jordy: the flyweight pattern implies that a node can't ask for it's style, only for the set of it's style*s* |
| Jordy: | stefan: so you want to write out a plan of attack on this one? you seem to have the best grasp on the best way to implement it |
| stefan: | Jordy: which style applies depends on which 'instance' is currently active, which is only known from inside a traversal (since the traversal gives the context (external state) the node needs to make it unambiguos in the sens of flyweight). |
| stefan: | Jordy: I don't know. I could try though and correspond with you. Would help me documenting the code, anyway :-) |
| | Aaron is away: (Auto-Away after 10 mins) [BX-MsgLog On] |
| | stefan has set the topic: "documentation (reference manual)" |
| | stefan has set the topic: documentation (reference manual) |
| Jordy: | real programmers just read the example programs :) |
| | Jordy grins |
| stefan: | He Eugene, I looked into the perceps file(s). |
| Jordy: | alright, basically we need class defintions |
| stefan: | It seems absolutely doable. |
| Jordy: | i think a document on the API for internal and external usage would be our basics |
| Jordy: | and example usage of each function |
| stefan: | What we need is a couple of extensions/adaptions. Namespaces are not in there. IDL is not supported (so we need new key words like interface, module, attribute) |
| stefan: | Then I'd like to be able to write docs for a method like: |
| stefan: | attribute Color background; |
| stefan: | //. the background color of the filler |
| Jordy: | isn't there an IDLdoc or something? |
| stefan: | This is basically done. That is, for C++ grammar, perceps generates docs like this. |
| Alain: | Jordy--would you like i do a search for such app (IDLdoc) |
| Jordy: | well perceps might do it :) |
| stefan: | The templates in which you can specify the concrete appearence of the output is a minor detail. Once the perceps script works for us we can attack that. |
| Jordy: | and someone has to write a document on how to document source :) |
| stefan: | Jordy: Have a look at perceps ! It looks really powerful ! Quite flexible with respect to output format. |
| stefan: | Jordy: :) should be straight forward once we agreed on it. Perceps lets you even specify this part ! |
| | Jordy looks at perceps |
| Jordy: | perceps was made for C++? |
| stefan: | Yes. |
| | Signoff: alexH (Leaving) |
| stefan: | Though it accepts functions, macros and global variables (urgh) |
| Jordy: | hmmm |
| stefan: | So it should be relatively easy to adapt it to IDL. |
| Jordy: | well |
| Jordy: | there is an IDL -> html converter out there already |
| stefan: | I find the reference manual from Fresco (in both, the embedded doc style and the output style) quite impressive ! |
| Jordy: | ORBacus does it I know, but it's commercial :) |
| Aaron: | COPE is dead. I'll try for the ILU perl binding |
| stefan: | Jordy: html is not exactly what we want. docbook is much better. |
| Jordy: | heh |
| stefan: | you can convert to everything based on docbook. |
| Jordy: | i wish there was just one damn document standard :) |
| stefan: | Right, I once started documenting using texinfo. It seemed quite standard at that time. Now it's docbook. |