| | Logging Started : Thu Jul 23 17:09:46 EDT 1998 |
| | Saving Window |
| | mass- (massacre@quake.nettally.com) has joined channel #berlin |
|
mass-:
|
I thought this meeting was tomorrow?
|
|
graydon:
|
hey
|
|
mass-:
|
=)
|
|
mass-:
|
Siggraph was pretty cool
|
|
graydon:
|
er.. yeah. I suppose so. I wasn't sure how we'd left things
|
| | w3 (james@tech-f.gamespot.com) has joined channel #berlin |
|
graydon:
|
mass: what all happened
|
| | mass- = David Waite (if ya forgot) |
|
mass-:
|
not much, just had a good time. Saw the movies, looked at all the new products and all the booth Babes..
|
|
graydon:
|
cool. I'm gonna wait a bit till people show (if they do).. anything on your mind?
|
|
mass-:
|
mine? nah, my mind is a bit empty
|
|
mass-:
|
I was fine until I wandered in on Pixar describing how they made Geri's game.
|
|
mass-:
|
I understood too much of it, and my head started hurting ;)
|
|
graydon:
|
did you see maya?
|
|
mass-:
|
I was wondering how far things are? I still can't get things to compile
|
|
mass-:
|
err.. I didn't look too hard
|
|
mass-:
|
(I've seen it before)
|
|
mass-:
|
=)
|
|
mass-:
|
I saw teh Quake Arcade game, that thing looked strange. It was just quake, sitting there..
|
| | RangerRic (syntax@1Cust57.tnt1.bloomington.il.da.uu.net) has joined channel #berlin |
|
RangerRic:
|
just when the meeting starts is when my ISP decides to stop connecting to anything :)
|
|
graydon:
|
Well, I'm kinda waiting on andrew apted to hand over something I can use as a font loader, cause my biggest intrest is in getting text working
|
|
mass-:
|
definately
|
|
mass-:
|
Text will be cool =)
|
| | End of Window Text |
|
mass-:
|
I'll try things again tonight; I got around that libstdc++ problem or whatever was going wrong before, but now I'm getting duplicate functions from include files
|
|
graydon:
|
but I also realize he has a lot to do, so I'm thinking of moving into laying out large parts of the widget hierarchy in IDL and encouraging people to come fill it in, now that we have a working prototype widget to base work on
|
|
RangerRic:
|
I still can't get omniORB or the src/ggi/default stuff in mesa to compile ;)
|
|
mass-:
|
and I keep forgetting to learn Corba in 14 days. I'm going to be at least 4 days behind now.
|
|
RangerRic:
|
it hates me
|
|
graydon:
|
There's also the issue of developing support code in openGL. I know fltk might be of use there.
|
|
RangerRic:
|
hehe
|
|
mass-:
|
Well what we should do is make Redhat/debian packages of everything once we get a working prototype =)
|
|
RangerRic:
|
yeah
|
|
graydon:
|
mass: no problem, at least 5 of those days are kinda pointless. Not all of corba is applicable or important.
|
|
RangerRic:
|
I can do that
|
|
RangerRic:
|
or at least, red hat
|
|
graydon:
|
mass: I totally agree. We are wasting *way* too much time farting around making it compile on everyone's system.
|
|
RangerRic:
|
I need to start *doing* something again... I've been busy as hell
|
|
RangerRic:
|
I feel bad, I go on this great big insane run of playing with images and then nothing :)
|
|
mass-:
|
The new webpage look sreally cool, by the way =)
|
| | ixx (ixx@pm3-1-074.lub.arn.net) has joined channel #berlin |
|
RangerRic:
|
yeah it does
|
|
graydon:
|
ranger: if you want to learn to make RPMs and debs, I'll have your babies :)
|
|
RangerRic:
|
I know how to make RPMs already
|
|
ixx:
|
hello all
|
|
mass-:
|
There is something about the logo I don't like, and think could be made better, but it is still cool enough I can't place it =)
|
|
graydon:
|
hi ixx
|
|
RangerRic:
|
just not debs, don't have a debian system
|
|
mass-:
|
well alien will work for debs
|
|
RangerRic:
|
yeah
|
|
graydon:
|
ranger: well 1 is better than 2. I know brent knows how to make debs, so maybe we can convince him
|
|
mass-:
|
I was just being equal to all distros. I use Redhat, I've never even seen a deb sys
|
|
RangerRic:
|
cool
|
|
RangerRic:
|
I tried debian not too long ago, everything was just strewn about :)
|
|
RangerRic:
|
I had a hard time working with it
|
|
RangerRic:
|
not to mention dselect bugs me :)
|
|
RangerRic:
|
but that's a personal preference
|
|
ixx:
|
ranger, prolly before 2.0 was actually released yes?
|
|
RangerRic:
|
ixx: it was about 2 weeks ago... 'twas the 2.0 beta
|
|
mass-:
|
isn't it supposed to be released tonite or something?
|
| | graydon is a debian junky. Use RH at work, and it is klunkier in terms of packaging. |
|
ixx:
|
ranger, the debian package format is much nicer than rpms...
|
|
RangerRic:
|
I have a small 300 meg "experiment" partition...
|
|
RangerRic:
|
ixx: yeah, it's just the dselect frontend that annoys me :)
|
|
RangerRic:
|
it's really hard to navigate
|
|
ixx:
|
ranger, its being replaced :)
|
|
RangerRic:
|
yeah
|
|
graydon:
|
ranger: use apt, it's all new and *really* nice
|
|
RangerRic:
|
:)
|
|
RangerRic:
|
and when that day comes, I may try it again
|
|
ixx:
|
ranger, i never used ummmm whatever the rpm frontend was anyhow.... used rpm -i and -U
|
|
ixx:
|
etc
|
|
ixx:
|
now i use dpkg
|
|
ixx:
|
graydon... i mean to get apt.... but... :)
|
|
RangerRic:
|
I d/l'd apt, and it looked like it was only a new backend... it replaces dselect too?
|
|
RangerRic:
|
all it was was command-line, I thought
|
|
mass-:
|
I have a 1.6 gig 'experiment' partition. Linux is on it =)
|
|
RangerRic:
|
mass-: haha
|
|
graydon:
|
ranger: no, you just say "apt-get install packagename" and it gets it and installs it from a mirror, along with everything packagename requires.
|
|
RangerRic:
|
anyways, I suppose I've veered everyone off-topic ;)
|
|
ixx:
|
graydon, i saw that you can setup apt to auto-upgrade your stuff to the bleeding edge of slink every day via cron :)
|
|
mass-:
|
topic?
|
|
mass-:
|
there's a topic? =)
|
|
RangerRic:
|
haha
|
|
graydon:
|
anyways this is a berlin meet not a kiss up to apt meeting
|
|
RangerRic:
|
graydon: that's what I mean... no way to browse the packages without dselect
|
|
RangerRic:
|
yeah
|
|
ixx:
|
ranger, i think deity is the new frontend...
|
|
RangerRic:
|
ahh... ok
|
|
RangerRic:
|
that sounds familiar
|
|
ixx:
|
umm it was last i looked.... but that was a month and a half back
|
|
graydon:
|
1st issue is packing managers and layout
|
|
RangerRic:
|
I may have to play with it again
|
|
RangerRic:
|
once 2.0 final comes out I'll dig around in it :)
|
| | graydon has set the topic: "Berlin meet: packing and layout" |
| | graydon has set the topic: Berlin meet: packing and layout |
|
graydon:
|
we have a graphic type called composite
|
|
ixx:
|
packing managers for what? shipping berlin?
|
|
graydon:
|
I assume you've taken a look at it
|
|
graydon:
|
composite is a collection of other graphics, possibly widgets. Packing is the act of arranging subwidgets / subgraphics in a composite
|
|
ixx:
|
ok..... i was in another arena all together...
|
| | Jordy (jordy@likes.to.idle.net) has joined channel #berlin |
|
ixx:
|
hey jordy.
|
|
Jordy:
|
damnit, i thought it was friday
|
|
graydon:
|
since there is no favourite algorithm on earth, a packing strategy has to be a replaceable object
|
|
graydon:
|
jordy: I think it was, but then I screwed up :) this is not a first for me
|
| | ixx has to go do some "real" packing..... boxes all over the house. i will be off and on. |
|
Jordy:
|
what are we talking about? packing?
|
| | graydon is getting coffee for 2 seconds |
|
ixx:
|
jordy, just started
|
|
Jordy:
|
ugh, man layout manager is going to be harder than sin for these modular components
|
|
ixx:
|
jordy, friday would not work i thought....
|
|
Jordy:
|
we should at least force everyone to constrain their components to rectangles :)
|
|
ixx:
|
heh
|
|
mass-:
|
hehe
|
|
Jordy:
|
last thing i wasnt to do is attempt to clip circles :)
|
|
graydon:
|
jordy: yeah, or at least code the packing managers to expect to be acting on rectangular objects
|
|
graydon:
|
bounding boxes, etc.
|
|
Jordy:
|
yeah
|
|
Jordy:
|
no reason they can't just draw a circle, just it'll have to clip like a rectangle
|
|
graydon:
|
yeah, agreed.. now there's packing, and there's flowing objects down a page using their advance and alignment metrics
|
|
Jordy:
|
maybe we should make everything porportional based on screen estate :)
|
|
Jordy:
|
make our lives easier, never have to worry :)
|
|
RangerRic:
|
my connection die, or is everyone quiet? :)
|
|
Jordy:
|
has anyone here ever written a packer?
|
| | graydon is talking to typography man at work |
|
Jordy:
|
or does anyone know of any software which we can steal one from? :)
|
|
graydon:
|
jordy: there is gtk+, which has a variety of packers / aligned containers
|
|
Jordy:
|
hmmmm, that would do, strip out all the widgets and crap from gtk+.. just use the base API
|
|
graydon:
|
jordy: or just use the algorithms
|
| | graydon was also looking at swing & jfc containers |
|
Jordy:
|
yeah, ok.. that'll work
|
|
mass-:
|
so did anyone think of a good way for help to work? =)
|
| | smkl (sami@ppp2.dial-in.vtoy.fi) has joined channel #berlin |
|
Jordy:
|
i looked at swing back in the day, when we first brought up IPC mechs
|
|
Jordy:
|
it's nice
|
|
Jordy:
|
too bad it's java :)
|
| | Signoff: RangerRic (Ping timeout for RangerRick[1Cust57.tnt1.bloomington.il.da.uu.net]) |
| | graydon apologizes for lag.. |
|
graydon:
|
hmm
|
|
graydon:
|
yeah, so the issue here is how to make a generic enough interface that a variety of packing algorithms can be plugged into it
|
|
graydon:
|
this interface needs to expose a collection of bounding rectangles with their alignment preferences to the packing algorithm
|
|
graydon:
|
and I'd *like* to use a similar mechanism for arranging flow objects on a page, like an HTML page or something. So perhaps NGLayout will be of use there.
|
|
graydon:
|
I don't know if we can use NPL code though
|
|
graydon:
|
I've pretty much finished the text management system, now all I need to do is write a text container type which drives it, i.e. plucks characters out of a string object and passes them through the rendering and layout process
|
| | Reconnected as graydon at Thu Jul 23 17:34:17 EDT 1998 |
|
graydon:
|
sorry
|
|
graydon:
|
where did I disappear?
|
|
Jordy:
|
pinged out
|
|
Jordy:
|
silly internet, nothing can ever just "work"
|
|
graydon:
|
yeah, ok, so does anyone want to take on the task of researching packing systems in existing toolkits?
|
|
graydon:
|
I have the gtk+ docs and the be book, I can give those to anyone who wants to study 'em and make some interfaces
|
|
graydon:
|
the problem with making it work with text is that you usually want to just extend the page when a flow object exceeds its space, whereas in many cases widgets get forced to fit in a bounding box..
|
|
Jordy:
|
don't look at me, i've never been good with math :)
|
|
mass-:
|
hehe
|
|
mass-:
|
the be book? You wouldn't happen to have Be would ya?
|
|
mass-:
|
They srtopped giving it away for free when I signed up
|
|
Jordy:
|
do we need a packer right now? i mean, it'd probably be good to prioritize
|
|
mass-:
|
stopped, even
|
|
graydon:
|
jordy: pretty soon. At very least we need an interface to describe the service, because you're going to be resizing widgets the moment you start making them.
|
|
graydon:
|
mass: I dont' have be. The be book is still avail. on their web site.
|
|
mass-:
|
ahh =)
|
| | RangerRic (syntax@1Cust214.tnt1.bloomington.il.da.uu.net) has joined channel #berlin |
|
RangerRic:
|
god this is annoying
|
|
RangerRic:
|
my connection just won't stay up :P
|
|
graydon:
|
anyway this seems like a non-fascinating topic for people, so I'll assume I'm stuck with it. Fine. Poo on you!
|
|
RangerRic:
|
what'd I miss? :)
|
| | graydon has set the topic: "Berlin meet: sessions, security, and hot-swapping" |
| | graydon has set the topic: Berlin meet: sessions, security, and hot-swapping |
|
Jordy:
|
we don't need to resize... i tell you we should force all users to use full screen apps
|
|
Jordy:
|
well, is the packer a generalized component
|
|
Jordy:
|
it's not done on a widget by widget basis or anything
|
|
mass-:
|
well controls should always be contained within their drawing area, right? Text should either go past the end and be clipped or wrap down
|
|
Jordy:
|
there are just a few components which need it
|
|
Jordy:
|
they are all basically "container" components
|
|
graydon:
|
have any of you taken a look at the sessionmanager, principal, and session interfaces?
|
|
Jordy:
|
for example, the window container will have to clip any widgets which it contains if shrunk down far enough, but i don' tknow how that would work... who makes the decision of what to crap and where? the widget container or the widgets contained in the widget container?
|
| | Signoff: RangerRic (Read error to RangerRick[1Cust214.tnt1.bloomington.il.da.uu.net]: Connection reset by peer) |
| | RangerRic (syntax@1Cust214.tnt1.bloomington.il.da.uu.net) has joined channel #berlin |
| | graydon grumbles at the tremendous lag |
|
mass-:
|
107 seconds to me, graydon
|
|
graydon:
|
this is almost pointless
|
|
Jordy:
|
graydon: ther eis a lot of unimlemented stub idl's, i have trouble understanding how a lot of the idl's work together
|
|
smkl:
|
widget container
|
|
smkl:
|
imhp
|
|
smkl:
|
imho
|
|
mass-:
|
I guess he'll see that later ;)
|
| | jql (jql@jql.accessone.com) has joined channel #berlin |
|
Jordy:
|
since there are some stub idls which don't seem to relate at all :)
|
|
mass-:
|
Will controls be clipped at all? Clipping a control will be rather difficult if you don't define an area in which the control should be displayed.
|
|
mass-:
|
I don't quite understand any ways in which things can be fully customizable, but not look like crap 3/4ths of the time
|
|
graydon:
|
sorry, there's horrible lag and people keep coming to my cubicle to have conversations -- GRRRR..
|
|
graydon:
|
jordy: which stubs are you having trouble with?
|
|
graydon:
|
mass: we'll need a clipping concept, yes. But we'll also need a packing concept. Both. They are different solutions to the same problem.
|
| | WinterWol (noone@du190-245.ppp.algonet.se) has joined channel #berlin |
|
Jordy:
|
graydon: i don't have the source in front of me, i'm at work right now..
|
|
WinterWol:
|
'lo all
|
|
Jordy:
|
graydon: what i need is for people to fully document each function they export
|
|
graydon:
|
mass: you can make things customizable by requiring certain very complex customizations to come with their own strategies for use. Encapsulate further.
|
|
Jordy:
|
what it does, what it's supposed to be used for
|
|
Jordy:
|
what it returns, etc
|
|
graydon:
|
jordy: yeah, this is a problem I have been causing because of being somewhat rushed.
|
|
graydon:
|
jordy: I think everything in /src/warsaw is being used somehow though.
|
|
Jordy:
|
i'm sure you understand most of the source... but i'mg oing through and i understand a lot of it, but then there are so many idl files
|
|
Jordy:
|
it's hard to keep track :)
|
|
graydon:
|
jordy: I know. I apologize profusely. Reading someone else's code can be totally miserable.
|
|
Jordy:
|
esssspecially since the filenames are so long, "ls" takes like 4 screens :)
|
| | WinterWol has left channel #berlin |
|
Jordy:
|
so i sit there "where to start"
|
| | RangeRick (syntax@1Cust214.tnt1.bloomington.il.da.uu.net) has joined channel #berlin |
|
graydon:
|
It would be good to isolate subsystems of /src/warsaw in their own directories
|
|
jql:
|
ls isn't so bad in 132x60
|
|
graydon:
|
I should also write docs.
|
|
RangeRick:
|
jesus
|
|
Jordy:
|
well, just documenting the code in the code would be enough
|
|
RangeRick:
|
time to kill my ISP
|
|
Jordy:
|
standard format for each function exported we should come up with
|
|
Jordy:
|
name of function - short description
|
|
Jordy:
|
long description
|
|
Jordy:
|
arguments, returns
|
|
graydon:
|
there are actually only 43 IDL files :)
|
|
Jordy:
|
that would do it for me :)
|
| | Signoff: RangerRic (Ping timeout for RangerRick[1Cust214.tnt1.bloomington.il.da.uu.net]) |
|
Jordy:
|
how many actually have implementations? :)
|
|
graydon:
|
there are 20 impl.cc files currently
|
| | bfulgham (bfulgham@130.77.9.30) has joined channel #berlin |
|
graydon:
|
mm. that seems low, hang on..
|
|
graydon:
|
hey brent
|
|
bfulgham:
|
Hi everyone -- sorry to be late.
|
|
Jordy:
|
alright, i'm going to dedicate this weekend then... i finally understand CORBA to the extent where i can write my own... but geez.. some peices i just don't like
|
|
Jordy:
|
anyhow... at least it builds now
|
|
graydon:
|
bfulgham: no problem, I appear to have botched the meeting time again anyway
|
|
graydon:
|
jordy: yeah, there's 26 impl.cc files
|
|
Jordy:
|
so have we got a solution to the timeout problem with corba?
|
|
RangeRick:
|
:)
|
|
Jordy:
|
how does the Berlin server know when the Berlin program has died
|
|
graydon:
|
jordy: haven't solves timeouts, but we have the berlin server reaping allocated objects when an app dies.
|
|
graydon:
|
jordy: that's in the session interface
|
|
Jordy:
|
hmmm
|
| | mass- is away: (Auto-Away after 10 mins) [BX-MsgLog On] |
| | Signoff: RangeRick (Read error to RangeRick[1Cust214.tnt1.bloomington.il.da.uu.net]: Connection reset by peer) |
| | WinterWol (noone@du169-4.ppp.algonet.se) has joined channel #berlin |
|
graydon:
|
jordy: an app is given a session object from the sessionManager when it connects, and it allocates each of its new objects via the session. If the session ever finds the client is unreachable, it frees all the clones
|
|
Jordy:
|
good, at least we won't have to worry about.. what would you call that
|
|
Jordy:
|
object leaks :)
|
|
mass-:
|
=)
|
|
bfulgham:
|
Probably an old question, but can everyone build berlin now? Used to be that there was some problem with omniNames playing nice with berlin... My home system is currently in pieces all over the kitchen table, so haven't tried to build berlin this week :P
|
|
mass-:
|
I have object leaks now
|
| | mass- is back from the dead. Gone 0 hrs 1 min 13 secs |
|
graydon:
|
the session is also responsible for making security checks on the client (which represents itself using a principal object). Right now it permits anything, but you could easily use it to implement stringent security.
|
|
graydon:
|
mass: I think there are a few places where we have leaks
|
|
mass-:
|
I haven't been able to, but the last time I tried was last week.
|
|
Jordy:
|
security is really something we should wait till we can design correctly
|
|
graydon:
|
mass: events, definitely, will continue to eat all available memory :) until we start using flyweights
|
|
mass-:
|
unicodeSK.o and GlyphSK.o or something I think, duplicate definitions.
|
| | RangeRick (syntax@1Cust214.tnt1.bloomington.il.da.uu.net) has joined channel #berlin |
|
graydon:
|
jordy: yeah, but I want to have something in place which we can *use* in our security design. Some kind of tools which don't require starting over from scratch. That's why I took the time to make session and principal.
|
| | Hortis (sterwill@dogbert.advancenet.net) has joined channel #berlin |
| | Hortis is now known as sterwill |
|
sterwill:
|
Anything going on here?
|
|
graydon:
|
jordy: todd fries was on my case about that, and he was right. It would have been worse if I had left it much longer.
|
|
Jordy:
|
alright alright, so we'll put in some dummy functions
|
|
graydon:
|
ster: yeah, we're having a meeting and trying to ignore the intense lag
|
|
Jordy:
|
send back the string "BERLIN" and it's authenticated :)
|
|
jql:
|
Well, you could be creative and invent a MIT-MAGIC-COOKIE.
|
|
Jordy:
|
the important thing to remember is that the application itself should never need to authenticate itself... it should all be transparent to the programmer, we should need to make it implicit unless they are trying to get higher permissions
|
|
graydon:
|
jordy: heh. yeah.. it's actually up to the server to ask the client questions now. I love corba in that respect..
|
|
Jordy:
|
yeah, which is good
|
|
graydon:
|
jordy: I think the creation of principal objects in the client address space should be pretty routine. We can slop that into a client utility library very easily.
|
|
Jordy:
|
since we shouldn't force programmers to deal with things like that, they should be assigned a security context... once in that context they shouldn't have to use any authentication manually unless they want something higher
|
|
Jordy:
|
what else what else
|
|
Jordy:
|
hot swapping
|
|
Jordy:
|
hmmm
|
|
Jordy:
|
like what? swapping widgets on runtime?
|
|
graydon:
|
jordy: the session is passed between all cloneable objects. So everything a clone does, it does on your behalf. If it tries to do so mething naughty, presumably your session will cut you (and your little dog too) off and hang up.
|
|
graydon:
|
jordy: yeah. at runtime! neet eh?
|
|
Jordy:
|
graydon: perfect :)
|
|
Jordy:
|
well i guess it wouldn't be too difficult
|
|
Jordy:
|
we'll need to send a "please reload all your widgets" event of some sort ;)
|
| | Signoff: RangeRick (Ping timeout for RangeRick[1Cust214.tnt1.bloomington.il.da.uu.net]) |
| | RangeRick (syntax@1Cust214.tnt1.bloomington.il.da.uu.net) has joined channel #berlin |
|
graydon:
|
jordy: I was reading over duncan's lifecycle code, and it actually fits with the system we're using *really* well.
|
|
Jordy:
|
interesting
|
|
Jordy:
|
so many features
|
|
mass-:
|
good plan
|
|
Jordy:
|
graydon: what's the next step as far as writing is going, you going to do mouse support :)
|
|
RangeRick:
|
grrr
|
|
graydon:
|
jordy: no, you just reconstruct the widgets which have changed using essentially a corba lifecycle equivalent of a copy constructor. The app never knows what happened. The orb just redirects them to the new objects. You might need to call a subject/observer update() method at the bottom to make things resize.
|
|
RangeRick:
|
:)
|
|
Jordy:
|
hmmm
|
|
graydon:
|
jordy: I think jonas is working on mousing.
|
|
Jordy:
|
need the mouse... mouse is key... what about keyboard?
|
|
graydon:
|
jordy: we have keyEvents, but jonas doesn't like the way I'm just wrapping GGI key events, which is fair. I don't have strong feelings about key events.
|
|
Jordy:
|
hmmm
|
|
sterwill:
|
My brain is melting. I've been fighting MFC, CSliderCtrl, and the absolutely backwards, crack-headed Win32 messaging system all day.
|
|
RangeRick:
|
hrm
|
|
Jordy:
|
Win32 API is...
|
|
Jordy:
|
mm
|
|
graydon:
|
sterwill: you're welcome to dessign a good berlin slider :)
|
|
sterwill:
|
graydon: Hehehe... it's really not that hard, they just fucked the message mapping up so bad.
|
|
Jordy:
|
graydon: i would settle for a berlin chick box :)
|
|
Jordy:
|
er check box
|
|
bfulgham:
|
Graydon: I'm glad you pointed out the resize issue on widget changes. We might want some sort of signalling system where a "widgetChangeEvent" is generated when you swap out a widget, and it notifies any programs using it that the change has happened. This could cause a resize event in the program...
|
|
sterwill:
|
It exposes one message (WM_OUTOFMEMORY), and doesn't subclass properly. Anyway, time to look at soothing CORBA.
|
|
jql:
|
hehehe
|
|
mass-:
|
sterwill: I'm still fighting =)
|
|
graydon:
|
I think this is an important issue: widgets are worth delegating to individuals, otherwise they'll never get done. Everyone will think "oh, well, I want to work on something big!" but widgets are very important
|
|
sterwill:
|
I'd be perfectly happy writing widgets all day long for Berlin... if only I could make omnithreads work properly here.
|
|
sterwill:
|
Perhaps it's time for a glibc install.
|
|
sterwill:
|
Or maybe it's EGCS... I'll go build that now!
|
|
graydon:
|
bfulgham: all widgets are subjects. You can just call this->update() -- see boxWidget
|
|
mass-:
|
hmm. I wonder what the actual licensing on Mpeg is? There is a real problem with using MPEG on Linux. Commerical programs can't do it becuase they have to pay licensing to ship with a mpeg player, and most other platforms came with a palyer (like 95)
|
|
mass-:
|
err, 98 at least has a license
|
|
RangeRick:
|
hrm
|
|
graydon:
|
bfulgham: oh, this brings back a topic. rangerick can make RPMs, would you be keen to make debs of berlin development package when the time comes?
|
|
sterwill:
|
I don't believe there are restrictive licenses to MPEG...xanim seems to have no problem distributing source.
|
|
Jordy:
|
RPMs... ugh
|
|
Jordy:
|
i say we create our own distribution :)
|
|
mass-:
|
there isn't a problem in that sense. The source is free, the technology is patented
|
|
sterwill:
|
Jordy: I've got an idea... :)
|
|
sterwill:
|
mass-: But I do believe the implementation can be GPLed, though...
|
|
mass-:
|
its screwy, basically they let you use it for non-commercial purposes..
|
|
Jordy:
|
I've never liked packaging methods of Linux programs... all-in-one sorta solution... since it's bandwidth waster.. i should have a setup program which downloads individual files i need to upgrade :)
|
|
sterwill:
|
mass-: Well, if only for "non-commercial", then it doesn't fit the GPL...
|
|
mass-:
|
yeah, thats what I'm thinking. GPL the widget, then its solved =)
|
|
RangeRick:
|
so what, it's illegal for, say, red hat to distribute an mpeg player?
|
|
graydon:
|
jordy: I'm hoping to have a text box, a button, a window, and maybe 2-3 other widgets before we do a development release in binary packs. At that point people can be trusted to make things by cut-n-paste programming.
|
|
mass-:
|
its not a restriction on the source, but on the methods
|
|
bfulgham:
|
graydon: Yes. I should be through with rehab of my system tonight, and be ready to get back going. Should be a piece of cake.
|
|
mass-:
|
its really screwy
|
|
sterwill:
|
Jordy: I'm kinda working on a distribution... it's probably something you'd like. Ever heard of Encap?
|
|
Jordy:
|
graydon: it sure would be nice to write a RAD for early berlin development
|
|
Jordy:
|
do all of our berlin programs in a RAD
|
|
Jordy:
|
not worry about silly placement of widgets :)
|
|
graydon:
|
jordy: it'd be nice to make a space ship and fly to mars too :)
|
|
Jordy:
|
mmm, maybe we can do that after berlin
|
|
Jordy:
|
fly to mars that is
|
|
graydon:
|
jordy: berlin 2.0: Mission to mars
|
|
sterwill:
|
Would the ship be build out of CORBA components?
|
|
Jordy:
|
hahah, CORBA components
|
|
sterwill:
|
Maybe I'll implement the rocket engine classes.
|
|
Jordy:
|
"captain, i can not clone another tank of gas"
|
|
bfulgham:
|
Jordy: You can do it already -- use apt under debian and you can upgrade individual packages. I do this now.
|
|
Jordy:
|
bf: no, i'm thinking individual files :)
|
|
RangeRick:
|
heheh
|
|
bfulgham:
|
jordy: Ahh. As in, only this little script changed between versions, so just grab that.
|
|
Jordy:
|
exactly
|
|
Jordy:
|
like CVS for a distribution :)
|
|
sterwill:
|
Like CVS, you mean! :)
|
|
Jordy:
|
if only lines 8-6 in the script changed
|
|
Jordy:
|
i don't need the WHOLE script
|
|
Jordy:
|
:)
|
|
sterwill:
|
I think rdist (or a clone of it) does something like that.
|
|
graydon:
|
cvs. it's too scary for a lot of people.
|
|
Jordy:
|
you could upgrade your entire OS with a bunch of diffs :)
|
|
RangeRick:
|
cvs rules
|
|
bfulgham:
|
jordy: Not a bad idea... won't work for binaries, but for perl/python/etc. and doc files would be great.
|
|
RangeRick:
|
hahah
|
|
RangeRick:
|
binary diffs!
|
|
Jordy:
|
bf: they make binary diff programs
|
|
sterwill:
|
xdelta.
|
|
Jordy:
|
like 'patch' for dos
|
|
graydon:
|
jordy: that's how the BSDs do it. CVSup the whole thing.
|
|
Jordy:
|
nifty :)
|
|
graydon:
|
jordy: but at the expense of a slower, more tightly controlled development cycle
|
|
Jordy:
|
that's the only thing i have against bsd
|
|
Jordy:
|
it's so closed
|
|
graydon:
|
jordy: it's a little more severe when you commit code to the BSD tree.
|
|
sterwill:
|
Scope out the freshmeat.net archives from about two months ago. There was a tool that did just this, binary diffing over networks, and it did intelligent updating.
|
|
Jordy:
|
mmm, interesting
|
|
bfulgham:
|
He he he. There's a huge flame war going on debian-devel right now about whether to include KDE/not include KDE in the 2.0 release tonight. Whew!
|
|
bfulgham:
|
sterwill: Interesting. I'll have to look it up.
|
|
jql:
|
hahaha
|
|
Jordy:
|
you know, wassisname kept saying, "what about ACAP, what about ACAP" for the registrar
|
| | graydon notes we're really off topic |
|
Jordy:
|
maybe i should look that up again
|
|
graydon:
|
acap is OK
|
|
Jordy:
|
anyone have the URL for ACAP? :)
|
|
graydon:
|
but it's not very corby. You'd need a parser. Writing parsers is kinda a pain.
|
|
RangeRick:
|
what's acap? :)
|
|
Jordy:
|
yeah
|
|
Jordy:
|
i don't like that :)
|
|
Jordy:
|
we are just gonna acess registrar via corba 99.99% of the time anyway
|
|
graydon:
|
I'd really prefer to have all that wrenched out of the system at compile time by egcs and omniidl2.
|
|
Jordy:
|
it'll be really odd to have a fully modular GUE tho
|
|
Jordy:
|
oh, that's another thing
|
|
graydon:
|
if there's gonna be a bug, let it be insulated from the transport encoding. watching protocol dumps is tedious and annoying.
|
|
graydon:
|
jordy: GUE?
|
|
Jordy:
|
i would recommend that we start using the term "Graphical User Environment" rather than Graphical User Interface of Graphical Windowing System
|
|
Jordy:
|
since we are really developing a full environment
|
|
Jordy:
|
not just an interface :)
|
| | graydon is pulling up acap, hold on |
|
Jordy:
|
argh, why is win98 eating up 80% of my CPU
|
|
jql:
|
Windoze is a GUI. X is a GWS. Berlin is a GUE? Hmm...
|
| | jql thinks about it... |
|
Jordy:
|
jql: yeah :)
|
|
graydon:
|
jordy: I guess. I mean, careful. We're not going to have moscow specs done by the time berlin devel. release goes out.
|
|
Jordy:
|
we don't just deal with Windows :)
|
|
Jordy:
|
we deal with objects
|
|
RangeRick:
|
hehe
|
|
graydon:
|
jordy: yeah. so.. graphics object program? GOP?
|
|
sterwill:
|
Object Oriented Graphical User Environment OOGUE!
|
|
Jordy:
|
it could be a GOE Graphical Object Environment :)
|
|
Jordy:
|
OOGUE hahaha
|
|
sterwill:
|
OOH! GOOEY!
|
|
mass-:
|
hehe
|
|
mass-:
|
OOGLE
|
|
Jordy:
|
graphical object oriented environment what's y?
|
|
mass-:
|
8)
|
| | RangeRick starts working on an "OOGUE" icon of a melting candy bar :) |
|
sterwill:
|
Jordy: That was just the prounciation. :)
|
|
sterwill:
|
pronunciation.
|
| | sterwill can do better than OOGUE. |
|
mass-:
|
I like OOGLE =)
|
|
graydon:
|
Anyway, I'm calling it a GUi because those assholes who write "for dummies" books have taught most english speaking people that "gooey" means "thing you look at on a computer screen"
|
|
jql:
|
MOOGUE
|
|
jql:
|
I like that better
|
|
jql:
|
(multi-threaded, of course)
|
|
Jordy:
|
graydon: yeah, but if you see me say GUE, you know what i'm talking about.. (i pronounce it GOO)
|
|
Jordy:
|
i pronounce GUI, GUY anyway ;)
|
|
smkl:
|
moogle?
|
|
mass-:
|
hehe. All the windows are set to 'melt', so as you leave them they dissolve into the bottom of the screen. Its kinda an auto-minimize feature
|
|
jql:
|
moogop?
|
|
jql:
|
oh dear...
|
|
mass-:
|
Ogle
|
|
jql:
|
mogle
|
|
Jordy:
|
object oriented distributed user operating environment OODUOE
|
| | sterwill is trying his best to match words to form BOGGLE> |
|
Jordy:
|
wait
|
|
graydon:
|
MORGUE -- multithreaded object repository and graphical user invironment
|
|
mass-:
|
haha
|
|
Jordy:
|
MORGUE, hahaha
|
|
jql:
|
lol!
|
|
mass-:
|
Basic Object Graphical GUI library environment
|
|
graydon:
|
jordy, here's acap: http://andrew2.andrew.cmu.edu/cyrus/acap/
|
|
sterwill:
|
"Are you prepared for the death of the GUI as we know it? Do you have a MORGUE!?"
|
|
jql:
|
s/Basic/Berlin/
|
|
mass-:
|
hehe ok, ok
|
|
graydon:
|
Enough!
|
|
Jordy:
|
alright, next topic
|
| | graydon has set the topic: "Berlin meet: which widgets do we want?" |
| | graydon has set the topic: Berlin meet: which widgets do we want? |
| | sterwill wants to argue about the registry but really has nothing to object to, considering his current ignorance towards its implementation. |
|
jql:
|
graydon: all of them.
|
|
jql:
|
Next topic?
|
|
WinterWol:
|
=)
|
|
jql:
|
buttons, check-boxes, text stuff, progress, scrollbar, etc...
|
|
graydon:
|
jql: I mean for our stability / development release in the beginning of sept.
|
|
Jordy:
|
very simple ones
|
|
mass-:
|
sterwill: argue anyways. How do you expect to learn if you don't fake it then get shot down?
|
|
jql:
|
Well... maybe not a scrollbar
|
|
sterwill:
|
mass-: That's the way to live life, man!
|
|
Jordy:
|
button, check box, window container, menubar
|
|
sterwill:
|
How about adopting a NeXTish scrollbar layout? They did it for a reason, little to many people know.
|
|
Jordy:
|
titlebar
|
|
RangeRick:
|
brb
|
|
graydon:
|
sterwill: what reason is that?
|
| | jql has never seen a NeXT scrollbar |
|
Jordy:
|
ster: it was a bad design really.. think about it, the menu bar is at the top of the window, if you can keep your cursor there.. you have to travel the max distance to scroll :)
|
|
sterwill:
|
First off, they have the vertical bar on the left of the scroll region, not the right. Why? Because being along the left margin was found to be easier to track content with.
|
|
sterwill:
|
They also grouped both directional buttons to a common area between the two bars. That kept line scrolling to a minimum.
|
|
jql:
|
sterwill: But when it's removed from the left edge, the window contents must be moved. It's very disorienting.
|
|
Jordy:
|
but scroll bar might be too complex for initial stuff
|
|
graydon:
|
jordy: yeah, I think we need enough to make a basic window. So a title bar is necessary, as well as a frame, a button and text. Those are totally required. I mean technically I already *have* a frame, with boxWidget :)
|
|
sterwill:
|
jql: I don't believe it was "removed".
|
|
jql:
|
I meant when to hideVerticalScrollbar() or whatever
|
|
Jordy:
|
i would just say window component, title bar component, menubar component (base, no menus working), text box component (one line), check box, and button
|
|
jql:
|
s/to/you/
|
|
Jordy:
|
that would be enough to construct a simple window
|
|
graydon:
|
jordy: ok. I buy that. I think we have enough people to pull that off in another month. We'll need to spend a lot of time packaging, bear in mind.
|
|
Jordy:
|
statusbar component won't take much longer, it's just an adaption of the menubar component
|
|
Jordy:
|
no scroll bars, no resizing :)
|
| | Signoff: RangeRick (Ping timeout for RangeRick[1Cust214.tnt1.bloomington.il.da.uu.net]) |
|
sterwill:
|
Ooh, here's something that just occurred to me. F
|
|
jql:
|
Jordy: If you want your statusbar to be as obnoxious as the Windoze version, it'll take a little bit more...
|
|
graydon:
|
jordy: if text works, yeah. This is why I was concerned about packing. But maybe text layout is separate enough that we should leave it..
|
| | RangeRick (syntax@1Cust114.tnt1.bloomington.il.da.uu.net) has joined channel #berlin |
|
Jordy:
|
hmm, yeah
|
|
sterwill:
|
I'm long out of touch with the Berlin source base, so I have no idea how this is implemented: Is Warsaw encouraging a "packing" sort of window layout for development, or will an absolute, template-based style be the "preferred" method?
|
|
graydon:
|
sterwill: uh, I am inclined to make packing abstract and let people choose their favourite algorithm.
|
|
jql:
|
If you want to be better than everyone else out there, you should simply prevent absolute coordinates
|
|
jql:
|
:)
|
|
graydon:
|
sterwill: this was the first topic today, and lag was so bad I got the impressiooon nobody gave a damn :)
|
|
Jordy:
|
heh
|
|
sterwill:
|
Ok. It's more of a preference, since all windowing systems I've seen support both, yet endorse one (by way of examples, etc.).
|
|
Jordy:
|
it's all about proportions :)
|
|
sterwill:
|
Actually, take that back, Windows can't pack. :)
|
|
jql:
|
Forcing layout management would make a vast improvement to most applications...
|
|
sterwill:
|
jql: That seems obvious, doesn't it? But take a look at Gimp (not the toolkit, but the program). I think it does a very nice job with what little absolute positioning it does.
|
|
jql:
|
sterwill: Yeah, dialogs are absolute. Windows simply have a 'document' widget which gobbles up free space. It's kinda sickening.
|
|
graydon:
|
jql: so long as we don't force people to use a constraint solver like motif. Some algorithms work much better & faster in common settings.
|
|
Jordy:
|
+
|
|
jql:
|
If we're going to be unicode-friendly, layout management is almost a must for even the tiniest dialog.
|
|
graydon:
|
jql: one approach I have seen which is good is a 2 pass packer, which first asks every sub graphic how much space it wants, and then assigns them a proportion based on how much it could get.
|
|
jql:
|
change the language, change the sizes.
|
|
Jordy:
|
we should think about implementing some standard dialog boxes in the future however.. as full components so we get a consistancy factor :)
|
|
sterwill:
|
And a (good) packing algorithm might provide unhidden labels and multi-lingual graphical elements at the expense of beauty.
|
|
Jordy:
|
like file open/save etc
|
|
graydon:
|
jql: I think every graphic needs to be able to give some idea of where it wants to be, and how big it wants to be.
|
|
Jordy:
|
"error" dialog boxes
|
|
jql:
|
graydon: widgets shouldn't know where they belong, should they?
|
|
jql:
|
graydon: size is a must for the widget, but the parent it responsible for layout.
|
|
Jordy:
|
detachable widgets... want you scroll bar on the left? drag it :)
|
|
graydon:
|
jordy: definitely. at least standardize the interfaces.. everyone has their favourite file dialog :)
|
|
jql:
|
Jordy: As long as you code it...
|
|
RangeRick:
|
:)
|
|
Jordy:
|
gray: thats what i mean, so every application brings up the same dialog for components which people use all the time
|
|
Jordy:
|
like file open dialog box, probably one of the most popular one s;)
|
| | mass- is away: (Auto-Away after 10 mins) [BX-MsgLog On] |
|
sterwill:
|
I really don't favor any file dialog... Motif's and Microsoft's are the "standard", which aren't excedingly efficient.
|
|
graydon:
|
jql: they know their offset within their coordinate space.
|
|
sterwill:
|
NeXT's three pane idea was nice, but it wasn't anything revolutionary.
|
|
sterwill:
|
I still find myself typing in the file name, even if it's 300 characters, because it's faster than browsing. There's gotta be a way to fix that.
|
|
jql:
|
graydon: Is that coordinate assigned by the program? By itself? By the packer?
|
|
graydon:
|
sterwill: yeah, but having all apps use your favourite, consistently, would be a big bonus.
|
|
sterwill:
|
graydon: Oh, sure! I wasn't advocating file dialog anarchy. :)
|
|
Jordy:
|
ster: no, just for consistency,... so every program doesn't implement their own :)
|
|
sterwill:
|
graydon: I just have yet to see anything to make me thing XYZ's is better than ABC's, therefore we should implement it. :)
|
|
Jordy:
|
and error dialog boxes.. we should think about providing a bit more verbose errors.. maybe some way to store extended errors which can be displayed outside the program.. so it doen't bulk it up
|
|
graydon:
|
jql: every graphic assumes it is being positionned relative to 0,0 in the upper left corner. If they distort their local coordinate space (which is real easy in openGL) then it's up to them how they position themselves relative to that.
|
|
sterwill:
|
Do we have some sort of error class?
|
|
sterwill:
|
Just a class with an error number, description, and extended description (could be a pointer to some other resource).
|
|
graydon:
|
sterwill: good idea. Not an exception that the app catches, but a "user needs to know about this error" error class. Then the user can decide on their favourite way of being informed of errors.
|
|
RangeRick:
|
that makes sense
|
|
sterwill:
|
Well, it could be an exception.
|
|
sterwill:
|
Like Windows does.
|
|
Jordy:
|
i just don't want to start a trend like windows programs, "an error has occured, 8494 exception a"
|
|
Jordy:
|
users just scratches their head
|
|
sterwill:
|
try { thingthatmightfail(); } catch { CWhateverException * thing) { MessageBox("blah %s", think->error_description);}
|
|
graydon:
|
ster: could be. Exceptions propagate through corba, so there's no reason not to make it an exn. I just meant a special one with nicely formatted internationalized message catalogues and stuff.
|
|
RangeRick:
|
my favorite is "in module "
|
| | mass- just got back |
|
Jordy:
|
of course
|
|
mass-:
|
are you talking about Microsoft's "Crash API"?
|
|
Jordy:
|
they aren't as good as unix errors, "assert on line 8449 failed"
|
|
graydon:
|
jordy: I have walked past *so* many public machines.. kiosks, video walls, demos, etc. with blue screens of death. Sad.
|
|
Jordy:
|
has everyone actually gotten *ANY* useful information off a BSOD
|
|
sterwill:
|
Jordy: You're not using the debug versions of NT>
|
|
mass-:
|
yeah!
|
| | mass- had a BSOD screensaver once |
|
Jordy:
|
of course, everything is better than netscape's crashes under unix
|
|
sterwill:
|
xscreensaver has it. :)
|
|
Jordy:
|
it just closes :)
|
|
Jordy:
|
no error messages
|
|
sterwill:
|
Jordy: They take the *POOF* approach.
|
|
jql:
|
Jordy: Yeah. That's annoying...
|
|
mass-:
|
xscreensaver has teh BSOD saver?
|
| | DH (datahntr@shell1.aimnet.com) has joined channel #berlin |
|
sterwill:
|
mass: Yep! A 95 BSOD, an NT BSOD, Amiga Workbench, Mac bomb, etc.
|
|
graydon:
|
jordy: oh, comeon, sometimes you get the word SIGSEGV or Bus Error. That's concise!
|
|
jql:
|
I spend like 2 minutes switching desktops and minimizing windows tryingto find netscape after that happens
|
|
jql:
|
Bus Error is my fave
|
|
mass-:
|
Bus Error is my favorite
|
|
mass-:
|
does anyone know what a 'Bus Error' is?
|
|
jql:
|
:)
|
|
DH:
|
10 minutes from now ...
|
|
Jordy:
|
graydon: netscape 4.5p1's crash errors are *GREAT* for developrs
|
|
mass-:
|
hehe -(
|
|
jql:
|
mass-: In Linux, I doubt it's relevant.
|
|
Jordy:
|
it comes with this utility which does a full stack trace
|
|
graydon:
|
mass: I think it's a euphamism for segfault.
|
|
Jordy:
|
context, what programs are running
|
|
Jordy:
|
lib versions, cpu, everything
|
|
Jordy:
|
and lets you send it to the tech support :)
|
|
sterwill:
|
Jordy: Or just get the Mozilla code. Talk about debug info!
|
|
Jordy:
|
mozilla scares me, all ie ver get is a half screen of text :)
|
|
Jordy:
|
it's all lestif's fault
|
|
Jordy:
|
anyhow
|
|
graydon:
|
okokok. Singletons & flyweights.
|
|
Jordy:
|
widgets are pretty much picked out
|
|
Jordy:
|
what's a singleton and flyweight
|
| | graydon has set the topic: "Berlin meet: singletons and flyweights" |
| | graydon has set the topic: Berlin meet: singletons and flyweights |
|
Jordy:
|
exactly, i mean, isn't a flyweight something you go fishing with?
|
|
graydon:
|
a singleton is a thing which there cannot be more than one of
|
|
Jordy:
|
give me an example
|
|
graydon:
|
a flyweight is a thing which there are lots of, but they are all actually the same thing
|
|
sterwill:
|
I could have figured that one out, given enough time!
|
| | jql consults Merriam-Webster |
|
Jordy:
|
ok, something which is cloned over and over
|
|
graydon:
|
example singleton: the sessionManager. the reactorManager. the GenericFactory.
|
|
Jordy:
|
versus something which there is only one of
|
|
Jordy:
|
flyweight would be like, buttonWidget
|
|
Jordy:
|
:)
|
|
graydon:
|
well, flyweight in our case is going to be the glyphInstances and the keyEvents, I suspect.
|
|
Jordy:
|
hmm
|
|
Jordy:
|
ok
|
|
Jordy:
|
what's there to discuss... how they are going to be handled?
|
| | sterwill figures out a guitar solo. |
|
jql:
|
keyEvent is a flyweight? goodness...
|
|
graydon:
|
so we have an interface in sessions for assigning singletons to names, so you can make them findable by any other client program
|
|
mass-:
|
ahh
|
|
jql:
|
hell of a fly
|
|
mass-:
|
so flyweights are components that share codespace in memory?
|
|
graydon:
|
mass: yeah, everything uses the same shared reference. So every "E-key-event" is the same one.
|
|
Jordy:
|
mass; I hope they do, otherwise we are going to use a whole lot of memory
|
|
graydon:
|
jordy: right now (this is sad) we construct a new keyEventImpl.cc for every keypress. That's a big memory leak.
|
|
jql:
|
*tsk*
|
|
Jordy:
|
whoah, i hope no one types very fast
|
|
graydon:
|
jordy: I can type fast enough to lag it.
|
|
mass-:
|
well they have seperate data spaces
|
|
jql:
|
oh dear...
|
|
jql:
|
that's bad
|
|
mass-:
|
err, right? =)
|
|
graydon:
|
mass: no, you parameterize them by their context
|
|
graydon:
|
mass: with a glyphInstance, you just tell it where it's rendering at this moment
|
|
graydon:
|
mass: with a keyEvent, you just send more copies of the same reference down the pipe
|
|
graydon:
|
jql: the advantage is that we don't need to hardwire key-press behaviour into any widgets, and we don't need to have 2 sets of message dispatching mechanisms. It's the same reactor we use for all other message types.
|
|
Jordy:
|
wait, how is keyevents being handled? you type a key and what happens? something picks up the key stroke, constructs a new keyEvent and then does what?
|
| | CTCP PING 901234502 993034 from Jordy |
|
graydon:
|
jordy: the terminal (which owns the ggi visual) picks up the key event, constructs a keyEvent (which is a message) and sends it to itself. Its reactor then has bindings which either forward the key to other apps or do other things. It's all up to the apps which bind commands to the terminal.
|
|
graydon:
|
jordy: in the testHarness program, you'll see it binds sendMessageCommand to keyEvent, with a parameter to send redrawMessage to boxWidget. so the key triggers the command to tell the boxWidget to refraw itself. Which it does.
|
|
Jordy:
|
have any ideas on how to speed it up?
|
|
graydon:
|
jordy: yeah, use flyweights :)
|
|
Jordy:
|
oh, i thought it was a flyweight :)
|
|
graydon:
|
jordy: no. it uses operator new.
|
|
graydon:
|
jordy: this is somewhat expensive
|
|
Jordy:
|
oh geez.. ok.. gotcha
|
|
Jordy:
|
so what's required to move it to flyweights
|
|
graydon:
|
jordy: a much better approach is to have a stl map of existing keyevents and just pick one up and send it.
|
|
jql:
|
isn't new required, or will keystrokes be synchronous?
|
|
graydon:
|
jql: it's required for the first key of any given unichar. After that, you can just reuse the event.
|
|
jql:
|
if that key is typed again before the widget processes the event?
|
|
graydon:
|
jql: then another copy of the reference to the key goes into the event queue. It's all done with queues anyway.
|
|
jql:
|
isn't that new again?
|
|
jql:
|
or is all of the keyevent data flushed to the client every time, making that event reusable?
|
|
graydon:
|
jql: no. you're not constructing a new object. Just passing another reference to the same object. You have an objetc which represents the act of the "e" key being pressed. You can send references to that object as many times as the "e" key actually gets pressed.
|
|
jql:
|
Oh... I get it
|
|
graydon:
|
jql: the downside is things like timing information can't be stored in the keyevent anymore.
|
|
DH:
|
does that process resemble how Windows handles messages ?
|
| | jql mumbles something about 1000 keys x 24 bytes |
|
Jordy:
|
jql: 1000 keys?
|
|
Jordy:
|
geez you have a big keyboard
|
|
Jordy:
|
:)
|
|
sterwill:
|
Windows doesn't handle messages. It just throws them around into buckets and makes your apps pick them up and reassemble them.
|
|
jql:
|
Well, you have to account for every state of Shift, Ctrl, and Alt
|
|
Jordy:
|
jql: mmmm, so you get 96 * 3 * 2 * 1 :)
|
|
Jordy:
|
mmm
|
|
DH:
|
I see.
|
|
graydon:
|
jql: the only keyEvents you'll create are the ones which are used. probability sez to me you don't use every combination of keys in a given setting.
|
|
Jordy:
|
576 keystrokes total :)
|
|
Jordy:
|
well, ctrl-numlock doesn't do anything on a keyboard
|
|
jql:
|
Well... in a word-processor
|
|
graydon:
|
jql: just like you don't create the total unicode range every time you load a font. You only make them as they are requested. You just reuse them once they are made.
|
|
jql:
|
and the keyEvents will be global
|
|
jql:
|
that's every program combined
|
|
graydon:
|
jql: yup. You might come close.. I dunno.
|
|
jql:
|
the half-life of your keyEvent map is probably a day
|
|
Jordy:
|
graydon: so you'll have at least what? about 70 of them at all times? more than that, since you are always using shift+letter keys
|
|
graydon:
|
jql: youprobably accumulate keyEvents for every letter, and every capital letter, and maybe half the control-letters..
|
|
Jordy:
|
can't we just have the application register to receieve key events and then distribute the raw key code and let it figure it out :)
|
|
graydon:
|
so, say (26 + 10) * 2.5.. 70 some?
|
|
graydon:
|
90
|
|
Jordy:
|
well, 26 * 2 will give you the alphabet, then there is ,.1-0 and \| :)
|
|
Jordy:
|
probably about the most ued
|
|
Jordy:
|
oh, plus a few f* keys
|
|
Jordy:
|
especially in a word processor
|
|
jql:
|
graydon: Indeed. And all of the alt-letters
|
|
Jordy:
|
oh yeah, alt, meny's
|
|
graydon:
|
jordy: that's one approach. We could even make a separate queue for key events. Then they would just be long ints. But we'd need 2 queues, and it'd be a lot less generic.
|
|
jql:
|
What about mouseEvents. I hope you won't use the same mechanism. AAAHHH!!
|
|
jql:
|
:)
|
|
sterwill:
|
I got it. Let's just redesign the alphabet, and a keyboard to fit our new design. We can make 10 letters and do chording.
|
| | jql calculates... |
|
sterwill:
|
Or 1000 letters and no chording at all.
|
|
jql:
|
1024x768 mouseEvents x 3 mouse-buttons...
|
|
Jordy:
|
graydon: let's not worry about being too generic, we should just provide a strict interface for keyboard and mouse events
|
|
jql:
|
err... x 6 mouse-buttons (double-click, wontcha know
|
|
Jordy:
|
since they are very very common input devices
|
|
jql:
|
that's 4718592 events * 8 bytes each
|
|
Jordy:
|
oh lord
|
|
jql:
|
love that mouse
|
|
graydon:
|
jql: no, you can't flyweight a mouse.
|
|
Jordy:
|
yeah, we'll just have to send cooked events to applications which register for it.. because not all components are going to want key events
|
|
jql:
|
and if you use some sort of 10000x10000 mouse grid, it gets even worse
|
|
Jordy:
|
mouse control is completely different
|
|
jql:
|
graydon: But the mouse is vastly more important and resource-intensive.
|
|
sterwill:
|
How is BeOS doing this? I'd assume they've worked out something nice, also asuming they did stick to C++ for their events/queueing systems.
|
|
graydon:
|
jql: yup
|
| | Jordy goes to be.com |
|
WinterWol:
|
what about my 3 extra keys for the 3 letters native to the swedish alphabet????
|
|
graydon:
|
sterwill: be is using hardwired methods for various event types. as I suspect jordy is advocating.
|
|
WinterWol:
|
å ä and ö
|
|
WinterWol:
|
=)
|
|
graydon:
|
winter: we're using unicode values -- should be OK.
|
|
mass-:
|
shouldn't a keypress event consist of the Key(s) and a timestamp? And whether they keys went down or are going up?
|
|
jql:
|
mass-: Ahh.. forgot press, release, and repeat.
|
|
jql:
|
x3
|
| | scaccomat (fgwre@ppp7-taormina.tao.it) has joined channel #berlin |
|
graydon:
|
jql: it may be that using the generic message interface is a bad idea for UI events cause they happen so fast & often.. that's fair, but I don't want to come to that decision without knowing exactly what we're sacrificing.
|
|
jql:
|
yeah. events especially need some sort of timestamp when transmitted across a network, don't they?
|
|
jql:
|
graydon: Perhaps some sort of reusable keypress queue. If you type fast enough to fill a 10-event queue, you deserve what you get...
|
|
DH:
|
heh
|
| | Signoff: DH (ircII EPIC4pre1.047 -- This is the default quit message.) |
|
graydon:
|
jql: for instance, it may be that making the message type we have be a stack-allocatable struct which might or might not have a pointer to a typed message interface gives us more of what we want. I'm not adverse to that.
|
| | Signoff: scaccomat (Leaving) |
|
jql:
|
You could allocate stacks for your clients
|
|
jql:
|
that would be efficient...
|
|
jql:
|
just mmap() a nice 1M block for your client, and use it as necessary.
|
|
graydon:
|
jql: I mean make it a data type you return from a function's local stack, not heap-allocated.
|
|
graydon:
|
jql: I can certainly see that as useful for mouse events.
|
|
jql:
|
You can't return data from a function's stack.
|
|
jql:
|
you can pass it on, though...
|
|
graydon:
|
jql: sure you can. so long as it's the return type of the signature. it gets copied back.
|
|
jql:
|
Well, that's true
|
|
sterwill:
|
And you're then limited to a single element.
|
| | jql was thinking data * |
|
sterwill:
|
Be it a struct or class, you get to crack it.
|
|
graydon:
|
jql: if something is real small, like a mouse event, it might be worthwhile.
|
| | bluehell (bluehell@nuovo.sas.leitwerk.net) has joined channel #berlin |
|
jql:
|
if new() is too expensive, you'd do well to kick it out the nearest airlock...
|
|
Jordy:
|
you know what we need (off-topic but), we need someone who can promote us... :)
|
|
graydon:
|
jql: then again, if the terminal moves the mouse cursor about, and 99% of the mouseMove and mouseOver messages are unbound and never get sent, maybe the current approach is OK.
|
|
jql:
|
Jordy: On second thought, KDE didn't benefit from promotion.
|
|
Jordy:
|
jql: no, more like, announcements and what not... just to let people know we exist ;)
|
|
sterwill:
|
Yes, but Berlin has good licensing. ;)
|
| | bluehell has left channel #berlin |
|
Jordy:
|
occassional post to C.O.L.A. "web page has been updated"
|
|
jql:
|
graydon: perhaps... but alot of applications track the mouse.
|
|
Jordy:
|
almost all components will track the mouse
|
|
jql:
|
sterwill: You dislike the GPL? ;P
|
|
sterwill:
|
When we're to the point of distributing files, freshmeat is the best place to go. Slashdot is fine for news, but there's precious little that's new at this point (other than "we're still working lots").
|
|
graydon:
|
jordy: track? or receive clicks? there's a serious difference in frequency
|
|
sterwill:
|
jql: No, we're writing widgets. KDE used Qt's widgets. The Qt widgets are licensed by Nazi trolls from Norway.
|
|
Jordy:
|
graydon: no.. like some track movement, which to receieve events not only when you click
|
|
Jordy:
|
but when you move
|
| | Fatal (bert@hutsirc1.hutch.com.au) has joined channel #berlin |
|
Jordy:
|
that way you can do "onMouseOver" events
|
|
jql:
|
Well, in order to give focus events, won't a terminal or whatever need to track the mouse constantly?
|
|
Fatal:
|
greets lads..
|
|
Jordy:
|
yeah, what jql said
|
|
jql:
|
Jordy: yeah, exactly
|
|
RangeRick:
|
hehe
|
|
Jordy:
|
some apps need mouse control.. constant, games especially
|
|
sterwill:
|
I really don't hate KDE, or the Qt widget set. There are just better alternatives out there.
|
|
Jordy:
|
not only tracks the mouse, but requires updates every 25 Hz :)
|
|
jql:
|
hahaha
|
|
graydon:
|
jql: yeah, the terminal will have to do focus managing..
|
|
mass-:
|
the mouse should be tracked @ screen refresh speed =)
|
|
mass-:
|
or more (oversampling) , I'd recommend 80 or 100 Hz
|
|
Jordy:
|
mass : that way it doesn't get blocky, but that gets aweful complex :)
|
|
Jordy:
|
Mice, if i remember right refresh at 10 Hz
|
|
graydon:
|
jql: it would be bad to cause everything which can receive a mouse event to actually receive 25 messages a second when the mouse is in motion, ok, so we have to have a way of limiting that.
|
|
jql:
|
graydon: No, it wouldn't be bad.
|
|
sterwill:
|
I don't see 25 per second as unreasonable.
|
|
Jordy:
|
we shouldn't try to send mouse events to each app as fast as they can
|
|
jql:
|
graydon: if we want to compete with X, we need to pay attention to such things.
|
|
Jordy:
|
we should limit it to a specific number
|
|
sterwill:
|
Windows windows get 200 mouse events a second, easily.
|
|
Jordy:
|
the current monitor refresh rate is a good number
|
|
Fatal:
|
ggi has support for hardware pointers i believe..
|
|
mass-:
|
sterwill, windows doesn't sample the mouse that quick
|
|
Jordy:
|
windows samples the mouse every 25 Hz i believe
|
|
sterwill:
|
mass: Ah! But there isn't just a "move" message!
|
|
graydon:
|
jql: but presumably not every single program which has ever expressed intrest in mouse events get them all.. they have masking and whatnot
|
|
Jordy:
|
mice samples at 10 Hz
|
|
jql:
|
Keep in mind: the mouse only sends data at no more than 9600bps
|
|
jql:
|
come on, be reasonable.
|
|
sterwill:
|
mass: There are auxillary messages, and subwindows.
|
|
mass-:
|
25 Hz is annoying for the keyboard in quake. Its just unresponsive
|
|
sterwill:
|
mass: There are buttons down, drag-while-button-down, button up, click, double click, mouse move, etc.
|
|
jql:
|
graydon: Sure, and those applications won't get them all.
|
|
sterwill:
|
And they all queue up together.
|
|
mass-:
|
oh yeah, messages are easily 200 =)
|
|
jql:
|
graydon: but many applications will ask for them all.
|
|
sterwill:
|
mass: I'm just nervous that if we limit to X messages per second for any control, we would be underdesigning.
|
|
jql:
|
all of them within their realm of influence, that is
|
|
Jordy:
|
graydon: is there any prioritizing in the queuing system?
|
|
graydon:
|
jql: some. Few will want to know about the mouse when it is over another window, from another app. so you can cut those out immediately.
|
|
mass-:
|
definately
|
|
jql:
|
graydon: I wasn't recommending that
|
|
graydon:
|
jordy: not at the moment, but there can be..
|
|
Jordy:
|
can you set a priority of a message to high?
|
|
mass-:
|
I'm talking about sampling rates, not messages. Although you should still only get three messages max per sampling for the mouse
|
|
Jordy:
|
so it gets shoved to the beginning of the queue
|
|
mass-:
|
well, MouseOver/MouseLeft,MouseDown/Up,etc
|
|
graydon:
|
jql: right, but right now the terminal is indiscriminate. So we have to have a command called forwardMessageIfMouseIsOverMeCommand() which cuts out a lot of traffic.
|
|
jql:
|
mass-: I wouldn't have a problem with queueing message for transmission X times per second, but I think the application should still get every mouse message it asks for.
|
|
jql:
|
graydon: forward where?
|
|
graydon:
|
jordy: it would be no problem to use priority queues.
|
|
Jordy:
|
graydon: put that down as something to implement, definatly need that for real-time events
|
|
graydon:
|
jql: to an application. the terminal is a reactor. It just executes commands based on messages :)
|
|
jql:
|
Oh, forward message to me if mouse is over me
|
|
graydon:
|
jql: right
|
|
jql:
|
There should be 'clickOnly' and 'whenOver' and 'allMouse' modes
|
|
graydon:
|
jql: or, for that matter, forward this *type* of mouse event if the mouse is over me. The reactor already classifies messages..
|
|
mass-:
|
so you mean, for each window context, have a list of some sort saying what events it would like to recieve?
|
|
Jordy:
|
hmmm
|
|
Jordy:
|
mass: exactly what i asked for :)
|
| | jql agrees |
|
Jordy:
|
have the reactors of each app define the events they want to get
|
|
mass-:
|
shouldn't an input event only go to the window that has focus anyways?
|
|
jql:
|
there should be a message-mask for every type of event
|
| | mass- rememmbers those damn Eyeball things on his desktop |
|
jql:
|
key/mouse/dblclick/focus/etc...
|
|
Jordy:
|
mass: yeah
|
|
Jordy:
|
eyeballs :)
|
|
sterwill:
|
xeyes?
|
|
mass-:
|
yeah
|
|
graydon:
|
mass: almost; each top-level window binds the following to the terminal: type-of-message --> command-to-run. so you could say, mouse-click --> forward-to-me-if-it-was-over-me.
|
|
sterwill:
|
Or real eyeballs, on a real desk? :)
|
|
jql:
|
ahh... xeyes is fun
|
| | mass- pleads the fifth |
| | sterwill considers food. |
|
jql:
|
mouse-enter --> forward-to-me, mouse-leave --> forward-to-me, mouse-click --> ignore, mouse-double-click --> forward-to-me-if-it-was-over-me
|
|
jql:
|
or whatever
|
|
graydon:
|
jql: right. Then you are getting only the events you want.
|
|
jql:
|
reminds me of SQL
|
| | bobs (rfsouza@fma4.if.usp.br) has joined channel #berlin |
|
Jordy:
|
but we should consider de-genericifying the more common events, the things whch are going to happen 120x a second
|
|
Jordy:
|
er
|
|
Jordy:
|
not 120x/second
|
|
graydon:
|
jordy: perhaps. I'm open to suggestions..
|
|
Jordy:
|
maybe 50 :)
|
|
jql:
|
Events should be efficient. We need to keep bandwidth low...
|
|
Jordy:
|
graydon: well.. we'd do it for keyboard and pointers (mice, those annoying things on laptops, etc)
|
|
jql:
|
The entire key_event struct should not be a single data-structure
|
|
graydon:
|
jql: it might not be bandwidth. Since we haven't profiled a system under stress, we have no idea where speed problems will occur.
|
|
jql:
|
Well, we have to assume that we're smart enough to fix server-side efficieny problems. ;)
|
|
Jordy:
|
register the object id with the mouse handler.. any time the mouse gets a new coord, it sends "objref->MouseMove(x,y)"
|
|
Jordy:
|
or something
|
|
graydon:
|
jql: I can guess that the constant mallocing of mouseEvent messages might get expensive
|
|
Jordy:
|
that would be the easiest :)
|
|
jql:
|
why malloc?
|
|
jql:
|
simple queue into a reused data-area
|
|
graydon:
|
jql: sorry, operator new.
|
|
jql:
|
I'm opposed to the use of new() for things like this
|
|
graydon:
|
jql: because every mouse event happens at a new location. you can't reuse. You made the point youself.
|
|
jql:
|
clients should be given a sandbox on the server
|
|
graydon:
|
jql: a sandbox?
|
|
jql:
|
perhaps 1M of ram which can be easily allocated without new()
|
|
graydon:
|
jordy: but what does mouseMove() do?
|
|
Jordy:
|
graydon: tells the application how much the mouse has moved, then it's up to the application to decide weather or not to handle the event
|
|
graydon:
|
jordy: if it gobbles the calling thread while the application redraws itself or changes state, I have a problem with that.
|
|
Jordy:
|
that would be the easist way :)
|
|
Jordy:
|
why does the app need to redraw?
|
|
jql:
|
new() will fragment ram like the dickens.
|
|
Jordy:
|
app need to redraw when the mouse moves?
|
| | jql is highly in favor of per-client mmap()ed memory sandboxes. :) |
|
graydon:
|
jordy: the app will do *something* with the knowledge. It either queues the knowledge or it acts. If it acts, the calling thread pauses.
|
|
graydon:
|
jql: describe what you have in mind.
|
|
Jordy:
|
graydon: hmmm
|
|
graydon:
|
jordy: if it queues it, then the client needs to be smart + trustable. 2 things apps never are.
|
|
jql:
|
implement a FIFO stack in a chunk of ram given to the client.
|
|
graydon:
|
jql: we have no guarantee the client is on our machine. client may be in japan.
|
|
jql:
|
it's allocated once and can keep a few-thousand events
|
|
jql:
|
yes, this is a FIFO transmit queue
|
|
Jordy:
|
i've never dealt with FIFO's
|
|
jql:
|
when the client releases an event, we chop it off. the the client keeps a reference, we new() it.
|
|
jql:
|
s/the the/if the/
|
|
sterwill:
|
Jordy: "ls -Fl | less" ? :)
|
|
graydon:
|
jql: you have to describe this more vividly. I am not seeing what you mean.
|
|
jql:
|
lets say we have 1k of ram allocated for mouse-events
|
|
jql:
|
me[0] = event;
|
|
jql:
|
me[1] = 2ndevent;
|
|
jql:
|
time passes...
|
| | Signoff: bfulgham (Leaving) |
|
jql:
|
flushQueue() { while(me) { sendEvent(me[X]) } }
|
|
Jordy:
|
hmmm, be has an app_server which dispatches keyboard and mouse events to window threads... which then send to clients
|
|
jql:
|
when the client finishes processing the event, we forget me[0] and allocate a new mouse-event to it
|
|
jql:
|
or rather, assign a new mouse-event to it
|
|
graydon:
|
jql: Oh, you're just talking about using our own memory management instead of hitting the OS for some. Fine. I agree wholeheartedly.
|
|
Jordy:
|
as far as i can tell, BeOS as MouseDown(), MouseMove() etc.. which get called when the mouse moves and what not
|
|
jql:
|
yeah. the OS bites. And fragmenting the server's memory on behalf of the client would be nasty...
|
|
Jordy:
|
in the client, yeah i guess it'll block until the mouse event is done
|
|
Jordy:
|
maybe we should force each application to have an event thread? :)
|
|
jql:
|
But I don't recomment out own memory-allocator for everyting
|
|
jql:
|
just for events
|
|
jql:
|
or temporary objects of any kind
|
|
graydon:
|
jql: By all means, if you want to do that to *any* code I write I would be happy as a clam. I don't know many memory tricks.
|
|
graydon:
|
jql: I've been spoiled by functional languages and GC'ed OOP :)
|
|
jql:
|
Well, I have to learn a few stupid corba tricks first.
|
|
jql:
|
:)
|
| | jql has been enhanced by functional languages and GC'ed OOP |
|
jql:
|
:)
|
|
jql:
|
oh dear...
|
|
graydon:
|
sigh.. getting late.
|
| | jql ponders the implications of reactors and events and terminals and stuff... |
|
RangeRick:
|
heh
|
|
Jordy:
|
yeah it is, i can still 8
|
|
sterwill:
|
Oh yeah? I can still 9.
|
|
jql:
|
I can't even 2
|
|
sterwill:
|
Anyone into guitar here?
|
|
sterwill:
|
I'd like to take this time to enter a short plug for Allan Holdsworth. Done.
|
|
graydon:
|
ok, well, it also just occured to me that 1 part of the speed issue is quite likely the hundreds of lines of debugging output every message passing run takes :)
|
|
RangeRick:
|
haha
|
|
graydon:
|
heh
|
|
RangeRick:
|
oh yeah? well, I can... uh... PLAN 9!
|
|
graydon:
|
you are all nuts.
|
|
jql:
|
hehehe
|
|
Jordy:
|
graydon: probably a bit of it... if we can just get it smooth enough with the current method
|
|
Jordy:
|
it's fine
|
|
sterwill:
|
graydon: Most of us are lagged, too. :)
|
|
jql:
|
yeah, debugging messages take forever.
|
|
Jordy:
|
if not i would opt for the non-generic method
|
|
RangeRick:
|
well then compile without debugging!
|
|
RangeRick:
|
:)
|
|
RangeRick:
|
er...
|
|
RangeRick:
|
never mind
|
|
graydon:
|
jordy: I agree. lets see how fast it can go using generic method, no debug messages, and some allocation tricks.
|
|
Jordy:
|
i mean, i love generic interfaces.. it makes life *SO* much easier in the future
|
|
Jordy:
|
but, if we can't do it, we can't do it... we'll just have to send cooked key events around
|
| | jql will like his method... |
|
graydon:
|
jordy: yeah. ok. anything else worth discussing here?
|
| | jql cooks some keyEvents |
|
Jordy:
|
graydon: hmmm
|
|
sterwill:
|
Ooh, let's discuss discussions.
|
|
sterwill:
|
I rather like the "Graydon sends a mail, we scramble" scheduling. :)
|
|
RangeRick:
|
hahaha
|
|
Jordy:
|
has anyone found anything better than omniorb? just curious, they seem to have stalled on development :)
|
|
jql:
|
What is keyEvent? broil @ 500 for 12 milliseconds?
|
|
Jordy:
|
they don't have the most open development out there
|
|
Jordy:
|
maybe we can convince them to use CVS
|
|
graydon:
|
jordy: they're working on POA and corba 2.2 IIRC
|
|
sterwill:
|
Seriously, this is the first "event" I've been able to make, because by reading the message I'm guaranteed to at least be NEAR a computer.
|
|
RangeRick:
|
orbit ? :)
|
| | scaccomat (fgwre@ppp11-taormina.tao.it) has joined channel #berlin |
|
graydon:
|
jordy: orbit is promising, but definitely not done.
|
|
Jordy:
|
isn't orbit gnomes thing?
|
|
RangeRick:
|
yeah
|
|
RangeRick:
|
:)
|
|
RangeRick:
|
it's *just* working with the gnome panel as of a couple of days ago
|
|
graydon:
|
jordy: I am really hoping orbit works. The people working on it are real smallness fanatics, which bodes well for corba.
|
|
jql:
|
fanatics? hmm...
|
|
Jordy:
|
how long has it been in development?
|
| | Signoff: scaccomat (Leaving) |
|
RangeRick:
|
not too long, I think
|
|
sterwill:
|
28 hours.
|
|
RangeRick:
|
haha
|
|
RangeRick:
|
not that short, I think
|
|
RangeRick:
|
;)
|
|
Jordy:
|
haha, well that won't be done for a while :)
|
|
sterwill:
|
Hehehehe.
|
|
Jordy:
|
i mean, there are some problems with omniorb, it's only got support for java and c++
|
| | cIRCuser (vista33@bert-02.brokersys.com) has joined channel #berlin |
|
Jordy:
|
and the compiler doesn't generate the best code in the world (idl compiler)
|
| | Signoff: mass- (Read error to mass-[quake.nettally.com]: Connection reset by peer) |
| | cIRCuser is now known as linuxdawg |
| | sterwill can't decide whether to get a new monitor, a new guitar, or both! |
|
jql:
|
*sigh*
|
|
Jordy:
|
alright, i think that's about it
|
|
jql:
|
I don't wanna hear that stuff. :(
|
|
Fatal:
|
ORBit is now at the stage where the gnome panel works properly with it... its idl parser is not totally complete yet.. missing forward declarations and some other stuff
|
|
graydon:
|
jordy: yeah, I'd like it if omni made separate stub and skel files. It also messes up with mutually dependent interfaces -- they *must* be in the same .idl file. bleah.
|
|
linuxdawg:
|
hello
|
|
jql:
|
This project is totally on the ground-floor, isn't it?
|
|
Jordy:
|
i wish if i define "interface blah" in the .idl
|
|
graydon:
|
fatal: cool, that's further than I thought.
|
|
graydon:
|
jql: berlin, or orbit?
|
|
Jordy:
|
i didn't need to subclass it in the interface
|
|
jql:
|
GGI, Berlin, OmniORB
|
|
jql:
|
even g++ is a bit flakey
|
| | linuxdawg has left channel #berlin |
|
Jordy:
|
i *HATE* doing that, since in the applications you guys all stick _impl after everything :)
|
|
jql:
|
glibc
|
|
jql:
|
what about this project isn't *just* beginning?
|
|
Jordy:
|
berlin has been in development since, mmm, 96 ;)
|
|
sterwill:
|
I was quite surprised the other day at how long g++ took compared to GCC, all while doing different parts of omniORB.
|
|
graydon:
|
jql: everything in free software is constantly under development. Life's like that. berlin is no X yet, but we've really only got about 6 months of code under our belts, and considering we all are either students or workers, that's pretty good.
|
|
jql:
|
Alright, isn't *just now* beginning to work
|
|
Fatal:
|
sorry to revisit the earlier discussion about events etc... but our event idls should mostly just need to be wrappers around ggi functions.. ggi provides methods for event masking etc so should make things quite easy for us
|
|
sterwill:
|
I'm all for building on the hard work of the GGI hackers. :)
|
|
jql:
|
graydon: just pointing out the primitive state upon which this primitive project is currently based...
|
|
graydon:
|
jql: oh, yes, there hasn't been anything much showable before this summer. That's because there was so damn much to learn and get in place. ggi, egcs, omni, threadsafe exceptions, mesa, freetype..
|
|
Jordy:
|
graydon has done a whole mess of work for this project
|
|
jql:
|
Yeah.
|
|
Jordy:
|
yeah, that's the problem
|
|
Jordy:
|
we are building this project
|
|
graydon:
|
I'm really amazed how far we've come since december. I mean, xmas eve I wrote up the first IDL for the project. The first, totally wack, broken, dead, never-again-to-be-seen IDL. And 6 months later we have a working, somewhat slow and broken but working display server.
|
|
jql:
|
from scratch
|
|
Jordy:
|
on other projects which are just starting to work :)
|
|
jql:
|
yeah
|
|
jql:
|
everything related to this project has started from scratch
|
|
RangeRick:
|
hehe
|
|
jql:
|
it's bizzare
|
|
Fatal:
|
whoah.. #debian is going nuts! debian 2.0 is released in 1 minute =)
|
|
jql:
|
WOOOOOO!!
|
|
jql:
|
:)
|
|
jql:
|
Now quite #quake, but it's big
|
|
Jordy:
|
debian 2.0.. mmm, maybe i can finally upgrade my laptop
|
|
Fatal:
|
like 300 ppl on there *grin*
|
|
graydon:
|
ah, so that's why we're so lagged :)
|
|
Jordy:
|
of course, the end result of Berlin will be, finally.. you don't need to know the square root of 88493839483 to configure your NFS server
|
|
Jordy:
|
:)
|
|
Jordy:
|
which makes it worth it
|
|
jql:
|
geezus
|
|
sterwill:
|
That was insane.
|
|
jql:
|
you're right
|
|
sterwill:
|
#debian, that is.
|
|
jql:
|
#debian is 75% of this network
|
|
jql:
|
*U* There are 435 users (238 invisible) on 26 servers
|
|
jql:
|
*** #debian 328 debian 2.0 out RSN(tm)
|
|
graydon:
|
now, we have a new egcs release coming out in august, a new linux kernel with fbcon in it due for the fall, a new mesa in beta, and a new orb (ORBit) due along .. er .. soon? So lots to work with.
|
|
jql:
|
Indeed...
|
|
graydon:
|
jesus, #debian has gone ballistic
|
|
Jordy:
|
yeah, it's nutts
|
|
jql:
|
But no KGI in 2.2.
|
|
jql:
|
I left early
|
|
Jordy:
|
FBcon is really all we need for basic graphics
|
|
Fatal:
|
graydon: yep.. elliot lee and others are working very hard on getting orbit up and running.. should be quite impressive..
|
|
Jordy:
|
FBcon with libggi
|
|
RangeRick:
|
haha
|
| | CTCP PING from jql |
|
Jordy:
|
what kind of language support does OrbIT provide/
|
|
Fatal:
|
jordy: just C at the moment afaik
|
|
jql:
|
Jordy: C, no doubt
|
|
jql:
|
*sigh*
|
|
RangeRick:
|
anyone else using the newest egcs snapshot? I'm using it (well, pgcc), and it's really quite nice
|
|
Jordy:
|
ugh, C :)
|
|
jql:
|
damn gtk
|
|
Fatal:
|
hehe they're speed freaks
|
|
RangeRick:
|
I haven't had any problems
|
|
jql:
|
gtk can bite me
|
|
Jordy:
|
rang: i use the CVS repository for Egcs :)
|
|
RangeRick:
|
haha
|
|
Jordy:
|
i compile at least 2 copies of Egcs a week :)
|
|
RangeRick:
|
well, I use pgcc, they don't put out daily snapshots, I think ;)
|
|
graydon:
|
jql: oh, GTK is pretty good actually. I like it. different goals --> different approach.
|
|
RangeRick:
|
pgcc r00l/
|
|
RangeRick:
|
er... r00lz ;)
|
|
Jordy:
|
GTK isn't bad
|
|
Jordy:
|
it's just not my ball of wax
|
|
Jordy:
|
not the cure-all i'm looking for
|
|
Jordy:
|
i just got sick of all the monolithic widget sets
|
|
jql:
|
monoliths... grr...
|
|
Fatal:
|
and the fact that there's only C bindings for ORBit now doesnt mean there wont be perl/c++ etc.. well thats what happened with gtk anyway :)
|
|
RangeRick:
|
:)
|
|
Jordy:
|
on an average X system nowadays, you have to have like 8 different widget sets, out of those you maybe use 10% of the widgets
|
|
Fatal:
|
jordy: while there is X , there will never be a 'cureall'
|
|
RangeRick:
|
well, maybe orbit will be a bit more expandable
|
|
jql:
|
CORBA actually specifies bindings though, doesn't it?
|
|
graydon:
|
jordy: yeah, my concern is that GTK is going to get a lot of people intrested in porting to X, and they might be disappointed when they try and port things with more advanced imaging requirements. But it'll probably catch up to the requirements soon enough.
|
|
Jordy:
|
graydon: that's why someone better write a RAD early on :)
|
|
RangeRick:
|
:)
|
|
Jordy:
|
port to Berlin? Hold up, let me drag and drop
|
|
RangeRick:
|
with corba it should be pretty simple, shouldn't it?
|
|
RangeRick:
|
sorry, CORBA
|
|
RangeRick:
|
;)
|
|
sterwill:
|
You can write bad code in any language. Let me extend that to include any windowing system, any operating system, any toolkit. :)
|
|
RangeRick:
|
I can! I can!
|
|
RangeRick:
|
:)
|
|
graydon:
|
ranger: well, define easy. I mean, it's not falling-off-a-horse easy, but it shouldn't be too bad.
|
|
RangeRick:
|
easier than X... ;)
|
|
RangeRick:
|
just a tad...
|
|
RangeRick:
|
a smidgen.
|
|
RangeRick:
|
:)
|
|
RangeRick:
|
so has anyone gotten GGI+fbcon working? :)
|
|
Jordy:
|
range: i came close :)
|
|
RangeRick:
|
I did too
|
|
graydon:
|
ranger: you saw testHarness. if you pull out all the exception handlers for weird cases and destroy the comments you have a working (very boring) program in maybe 10 -15 lines of code.
|
|
Jordy:
|
i have a matrox millenium II
|
|
Jordy:
|
so fbcon works
|
|
RangeRick:
|
went as far as messing up my video before dieing
|
|
RangeRick:
|
I have mystique 220
|
|
WinterWol:
|
me 2
|
|
Fatal:
|
jordy: same here.. i havent tried fbcon+kgi yet tho
|
|
Jordy:
|
generic exception handlers are the key catc(...)
|
|
Jordy:
|
:)
|
|
Jordy:
|
er catch
|
|
RangeRick:
|
do I want to be using the ggi devel code, or the ggi "stable"
|
|
RangeRick:
|
:)
|
|
RangeRick:
|
I know it say stable on the berlin site, but it also says 2.0 kernel ;)
|
|
Jordy:
|
yeah, can't use 2.0.x kernel with my hardware
|
|
graydon:
|
jordy: yeah, I just have a huge chain of exn handlers at the bottom so I can diagnose bugs in the display server.
|
|
RangeRick:
|
I couldn't use 2.1.x for quite a while, something went wiggy with my hardware, but now it's just a dream...
|
|
Jordy:
|
graydon: you should write a list of "standard" exceptions
|
|
Jordy:
|
and when we do end up documenting functions
|
|
Jordy:
|
list the exceptions they raise
|
|
Jordy:
|
otherwise it's going to be a nightmare
|
|
RangeRick:
|
especially with pgcc + "-O6 -mpentium -malign-double -funroll-all-loops -malign-functions=2 -malign-jumps=6 -fexpensive-optimization"
|
|
RangeRick:
|
haha
|
|
jql:
|
gah
|
|
RangeRick:
|
oh, and -fno-risc so it compiles ;)
|
|
RangeRick:
|
haha
|
|
graydon:
|
jordy: I should have a catch(CORBA::Exception e) which calls classifyExceptionForDebuggingPurposes();
|
|
jql:
|
-fno-rtti?
|
|
RangeRick:
|
whazzat?
|
|
Jordy:
|
graydon: heh
|
|
Jordy:
|
well, there ar ea lot of exceptions, lot of them are standard posix signals
|
|
Jordy:
|
divide by zero
|
|
Jordy:
|
etc
|
|
graydon:
|
jordy: all exceptions need to be explicitly written up in IDL if they're to propagate to the caller. It's just that a bunch of exceptions are so generic there's no point in mentionning them, like serverIsHosedException.. err..... COMM_ERROR
|
|
Jordy:
|
Server ishosed
|
|
Jordy:
|
haha
|
|
RangeRick:
|
hehe
|
|
WinterWol:
|
I really need to sleep and it's best to do that while it's still dark =) , so...bye all
|
|
RangeRick:
|
haha
|
|
RangeRick:
|
later
|
|
graydon:
|
ok sleep tight winter
|
|
graydon:
|
I should go home and get to work on more of this stuff.
|
|
RangeRick:
|
damn I wish ggi worked :)
|
| | WinterWol has left channel #berlin |
|
RangeRick:
|
and omniORB
|
|
RangeRick:
|
and mesa ;)
|
|
Jordy:
|
i think my entire machine is probably 80% beta software right now
|
|
RangeRick:
|
mine's not that bad
|
|
RangeRick:
|
I'm about 50%
|
|
graydon:
|
package package package. The sooner people can snag an RPM, the sooner we'll get more widgets.
|
|
RangeRick:
|
graydon: as soon as I can compile, I'll build an RPM ;)
|
|
graydon:
|
ranger: heh
|
| | Signoff: jql (Ping timeout for jql[jql.accessone.com]) |
|
graydon:
|
ranger: email me your error messages and we'll sort them out.
|
|
Jordy:
|
damn ORL, they need status updates
|
|
RangeRick:
|
ok
|
|
RangeRick:
|
I'll go into linux right now.
|
|
Jordy:
|
CVS repoistories, snapshots... i can't stand it :)
|
|
Jordy:
|
no news in like 4 months :)
|
|
sterwill:
|
Anyone here using libc5, EGCS, and have omniORB's bins working?
|
|
RangeRick:
|
I'll try getting untarring everything clean and go from there
|
|
graydon:
|
jordy: careful who you curse. ORL is saving out ass with omni.
|
|
RangeRick:
|
glibc6, pgcc, and no ;)
|
|
graydon:
|
s/out/our/
|
|
Jordy:
|
yeah i know... but you know how it goes, they give you a bone, and you want the entire skeleton :)
|
|
RangeRick:
|
brb (going to linux)
|
| | Signoff: RangeRick (syntax: .:(Stark Industries - http://defi.dyn.ml.org/vendors/stark):.) |
|
graydon:
|
skeleton! Ha!
|
| | jql (jql@jql.accessone.com) has joined channel #berlin |
| | Signoff: jql (Read error to jql[jql.accessone.com]: EOF from client) |
|
graydon:
|
umm.. yeah, there's another IDL compiler worth mentionning, it's from the flexmach project, called "flick". I think it might already have been raised but if anyone bumps into sopwith let him know.
|
|
Jordy:
|
we should put a timeline up on the web page (without times)
|
|
Jordy:
|
just a relative "what we are doing and where we are going"
|
|
Jordy:
|
you know uhm
|
|
Jordy:
|
mozilla has a corba compiler
|
|
Jordy:
|
er
|
|
Jordy:
|
idl compiler
|
|
graydon:
|
jordy: agreed. That'd answer 9/10s of the mails I get in advance.
|
|
Jordy:
|
i believe
|
|
graydon:
|
mozilla has an orb in it. So does NS4.
|
|
sterwill:
|
Don't they use Orbix stuff?
|
|
graydon:
|
visigenic last I checked
|
|
Jordy:
|
hmmm
|
|
sterwill:
|
That's right.
|
|
Fatal:
|
it'd be good if in the near future, all linux dists came with an ORB as standard...
|
| | RangerRic (ranger@1Cust52.tnt1.bloomington.il.da.uu.net) has joined channel #berlin |
|
RangerRic:
|
alrighty
|
|
Fatal:
|
one widget library, one orb , everything talking together
|
|
graydon:
|
fatal: well, brent took over the orphanned omniORB deb, so hamm (or slink) should be nicely orbed.
|
|
Jordy:
|
a fully distributed OS... mmm
|
|
graydon:
|
fatal: "living in harmony.. doo do doo dee, da dee da da"
|
|
RangerRic:
|
first order of business: omniORB
|
|
Jordy:
|
didn't we already finish? :)
|
|
RangerRic:
|
hahah
|
|
RangerRic:
|
no... me getting berlin working ;)
|
|
RangerRic:
|
do I want the regular, or the shared patch, or both?
|
|
Fatal:
|
graydon: *grin* just over the horizon
|
|
sterwill:
|
I've got omniORB compiled, and installed, but omninames loves to segfault on me.
|
|
sterwill:
|
All the examples work fine, however (those that don't require omninames have been run, of course).
|
|
sterwill:
|
I'm betting it's EGCS, which I need to recompile.
|
|
Jordy:
|
maybe i'll put up a distrib ution of omniORB which won't segfault
|
|
Jordy:
|
mine works fine
|
|
sterwill:
|
What compiler?
|
|
RangerRic:
|
pgcc
|
|
RangerRic:
|
err...
|
|
RangerRic:
|
:)
|
|
sterwill:
|
I meant that to Jordy.
|
|
Jordy:
|
Egcs here
|
|
graydon:
|
hmm, check your libc and libpthreads
|
|
Jordy:
|
Egcs CVS, probably about a week ago :)
|
|
Jordy:
|
with Glibc 2.0.6
|
|
sterwill:
|
Jordy: Which libc or threads lib?
|
|
Jordy:
|
glibc w/ linuxthreads
|
|
sterwill:
|
Hm... I bet it's my EGCS.
|
| | Flesch (aaron@d108.pm10.sonic.net) has joined channel #berlin |
|
Flesch:
|
yeah hi!
|
|
sterwill:
|
I'll recompile that right now, even.
|
|
graydon:
|
flesch: hi
|
|
Flesch:
|
everyone in here debian developers?
|
|
Flesch:
|
hi
|
| | Flesch recognizes smkl |
|
RangerRic:
|
berlin developers
|
| | sterwill has never used Debian. |
|
Flesch:
|
ah hi
|
|
RangerRic:
|
I tried it for 3 days :)
|
|
graydon:
|
flesch: bruce gave some intrest, at linux expo, in seeing it soon, which is one of the reasons I've been in a bad panic all summer to get it working.
|
|
RangerRic:
|
:)
|
|
Jordy:
|
i had debian on my laptop for a while ;)
|
|
Flesch:
|
I happen to be a debian developer very interested in developing it for debian
|
|
graydon:
|
s/bad/mad/
|
|
Jordy:
|
graydon: we have the two boxes, that should be enough for anyone :)
|
|
Flesch:
|
I'm sure people would play with a preliminary berlin .deb, even if it didn't reaally do anything besides show little square boxes
|
|
graydon:
|
jordy: well, I think that's actually more than I promised him, cause I had no idea how long the integration with mesa would take. But I really want text and a couple widgets.
|
|
Flesch:
|
;)
|
|
Jordy:
|
who did the main logo for Berlin on www.berlin-consortium.org? i want to get a high res copy of it :)
|
|
RangerRic:
|
anyone mind if I spit out some compiler errors in here? :)
|
|
graydon:
|
ranger: go ahead.
|
|
RangerRic:
|
g++ -c -O2 -pthread -Wall -Wno-unused -fexceptions -fsigned-char -I../include -DIDL_CFE_VERSION=\"1.3.0\" -DCPP_LOCATION=\"gcc\" -I. -I../../../../include -D__x86__ -D__linux__ -D__OSVERSION__=2 -o drv_preproc.o drv_preproc.cc
|
|
RangerRic:
|
drv_preproc.cc: In function `void DRV_pre_proc(char *)':
|
|
RangerRic:
|
drv_preproc.cc:370: `wait_status' undeclared (first use this function)
|
|
RangerRic:
|
d
|
|
Flesch:
|
graydon: any debian developers already snagged it?
|
|
RangerRic:
|
that's where I die in omniorb
|
| | Signoff: w3 (Leaving) |
|
Jordy:
|
graydon: right now everything video is coming out of Mesa right? 2d and 3d
|
| | smkl recognizes Flesch from year ago |
|
graydon:
|
jordy: alexander did them. he's linked off the "people" page
|
|
Flesch:
|
smkl: #linuxos efnet?
|
|
smkl:
|
#E
|
|
Flesch:
|
ah.
|
|
Flesch:
|
I remember you
|
| | sterwill is now known as NumbLock |
|
Fatal:
|
graydon: has there been any widget idl's written yet?
|
| | NumbLock is now known as sterwill |
|
Jordy:
|
ack graydon, no link :)
|
|
graydon:
|
flesch: possibly brench fulgham, but only because I constantly whine at him to do so :)
|
|
graydon:
|
s/brenchh/brent/
|
|
Flesch:
|
graydon: I WANT to do it, darnit!!!!
|
|
Flesch:
|
you don't have to WHINE at me!!!
|
|
RangerRic:
|
any ideas how to fix that? or where wait_status is supposed to be defined?
|
|
Flesch:
|
do I get the job? ;)
|
|
Jordy:
|
it would be nice if we could get some funding for Berlin, I guess Bruce is our best bet at this point
|
|
sterwill:
|
Argh. I've got a patched up EGCS 1.0.2 tree (to 1.0.3a, but it needs another patch). Is the EGCS CVS tree that cool? Is it reliable? Is it much cooler than 1.0.3a? :)
|
|
graydon:
|
flesch: sure, I'm just saying you might want to talk to brent to make sure he hasn't got it half done already..
|
|
RangerRic:
|
egcs-19980715-pgcc-19980715.diff.gz s)
|
|
Flesch:
|
is the openprojects network #berlin the official place for berlin stuff?
|
|
Flesch:
|
graydon: what's his name again?
|
|
graydon:
|
fatal: not much widget idl. Mostly other parts. I made 1 widget to demonstrate how to do it.
|
|
graydon:
|
flesch: for our meetings, yes.
|
|
RangerRic:
|
s) = ;) hehe
|
|
graydon:
|
ranger: that's a pthreads issue almost guaranteed.
|
|
Flesch:
|
there are upwards of 400 people in #debian right now
|
|
Flesch:
|
i refuse to be in there
|
|
graydon:
|
jordy: hold on, I'll get his email
|
| | RangerRic gets confused sometimes... windows = qwerty, linux = dvorak ;) |
|
RangerRic:
|
graydon: where do I update that?
|
|
RangerRic:
|
I suppose I can look on freshmeat
|
|
graydon:
|
jordy: "Alexander Johannesen"
|
| | sterwill bites the bullet and tries for the EGCS CVS tree. |
|
sterwill:
|
Now I'll be building my compiler every week. :)
|
|
RangerRic:
|
haha
|
|
RangerRic:
|
it's not that bad ;)
|
|
graydon:
|
ranger: for redhat? umm. search on redhat, 5.0, pthreads, and segfault in the omniorb mailing list archive.. or try rufus.w3.org/linux/RPM
|
|
RangerRic:
|
you get used to it
|
|
sterwill:
|
Yeah, only takes about a half hour here.
|
|
sterwill:
|
I haven't build EGCS under 2.1.111 yet, maybe it'll be quicker (better SMP).
|
|
graydon:
|
flesch: brent fulgham. he's maintaining omniorb package for debian.
|
|
RangerRic:
|
are there omniorb RPM's already? :)
|
| | Signoff: smkl (sleeping ...) |
|
Flesch:
|
graydon: um, actually, was. he officially offered it for adoption a couple of months ago
|
|
Flesch:
|
graydon: in other words he doesn't want to BE in the project anymore
|
|
graydon:
|
flesch: really? crazy.. ok then. I thought he was kinda keen on maintaining it. Oh well.
|
|
Flesch:
|
looking him up right now....
|
|
Flesch:
|
um nevermind
|
|
graydon:
|
ranger: I don't know if omni is RPM'ed. I suspect it is somewhere.
|
|
Flesch:
|
it seems that I may have screwed up my information somehow, that stuff is quite outdated and refers to someone else.
|
|
RangerRic:
|
found omnibroker ;)
|
|
graydon:
|
flesch: yeah, I know the previous maintainer orphaned it off, back at version 2.2, but it's at 2.5 now. I don't know if brent has registered himself.
|
|
Flesch:
|
graydon: I can't find his listed as a maintainer...
|
|
Flesch:
|
actually I officially adopted omniorb, but anyways ;). I never made any releases
|
|
graydon:
|
flesch: well, you can always mail him -- "Fulgham, Brent/SCO"
|
|
Flesch:
|
ok
|
|
Flesch:
|
I was just trying to find an email address
|
|
RangerRic:
|
no srpm for pthreads
|
|
graydon:
|
flesch: oh, sorry. pretty much everything is conducted through the mailing list, which is archived off our web page. So all addresses are available in there.
|
|
Flesch:
|
ok
|
|
graydon:
|
ranger: hmm. can you get a libpthreads version number?
|
|
RangerRic:
|
what do you mean?
|
|
Flesch:
|
pthreads comes with the kernel source, doesn't it?
|
|
RangerRic:
|
appears I do have libpthreads
|
|
Flesch:
|
pthreads is compiled from kernel source I thought
|
|
RangerRic:
|
part of glibc
|
|
RangerRic:
|
just queried it :)
|
|
RangerRic:
|
I have pthreads, tho... but my glibc is 2.0.5c
|
| | bobs has left channel #berlin |
|
Jordy:
|
i'm gonna head out
|
| | Signoff: Jordy (home) |
|
graydon:
|
try upgrading to 2.0.7
|
|
RangerRic:
|
hey, could you go to /usr/include and do grep wait_status * ? ;)
|
|
Flesch:
|
what distribution is the main devel enviro for this?
|
|
graydon:
|
ranger: sure, but I haven't actually got omni on this box, so that might not help
|
|
RangerRic:
|
hehee
|
|
RangerRic:
|
ahh
|
|
graydon:
|
flesch: my home machine. hamm + egcs + ggi
|
|
Flesch:
|
graydon: coool
|
|
Flesch:
|
graydon: what kind of vid card u got?
|
|
Flesch:
|
(obviously something ggi works with at this point...)
|
|
graydon:
|
flesch: cirrus 543x shitbox + malaysian 14 inch monitor. Hehehehehe
|
|
Flesch:
|
hmmmmm
|
|
Flesch:
|
i wonder if ggi's trident drivers are stable yet ;)
|
|
RangerRic:
|
:)
|
| | sterwill should donate his box to graydon. |
|
Flesch:
|
anyone have the url for the ggi website?
|
|
RangerRic:
|
www.ggi-project.org
|
|
RangerRic:
|
cvs -z3 update degas ;)
|
| | Reconnected as graydon at Thu Jul 23 20:44:22 EDT 1998 |
|
RangerRic:
|
netsplit
|
|
Flesch:
|
no i got kicked from irc.debian.org
|
| | sterwill (sterwill@dogbert.advancenet.net) has joined channel #berlin |
|
RangerRic:
|
ahh
|
|
RangerRic:
|
bitchx said it was a netsplit, anyways ;)
|
| | Reconnected as graydon at Thu Jul 23 20:48:19 EDT 1998 |
|
RangerRic:
|
mine is too, it just seems slow compiling :)
|
| | ixx (ixx@pm3-1-074.lub.arn.net) has joined channel #berlin |
|
Fatal:
|
gawd..i've been at work for 2 hours and havent done a thing yet! gotta jet
|
|
Fatal:
|
until next we meet
|
| | Signoff: Fatal (BitchX: the fresh-maker!) |
|
RangerRic:
|
do I only need the mesa2ggi patch now?
|
|
RangerRic:
|
or do I still need one of the other ones too?
|
|
Flesch:
|
awwww
|
|
Flesch:
|
the trident ggi driver doesn't work all the way :(
|
|
Flesch:
|
no fair
|
|
graydon:
|
hello?
|
|
Flesch:
|
yes graydon?
|
|
RangerRic:
|
graydon: hello...
|
|
graydon:
|
jesus, nasty netsplit. Ok. I'm headed out. soon
|
|
graydon:
|
anything else on the agendas?
|
|
RangerRic:
|
getting berlin to compile for me ;)
|
|
RangerRic:
|
haha
|
|
RangerRic:
|
err
|
|
graydon:
|
ranger: I can help a lot more once I'm home with a machine which works. I can mail you binaries and missing files once I'm home :)
|
|
RangerRic:
|
:)
|
|
RangerRic:
|
ok
|
|
graydon:
|
ok, night then. I'll pop back in in an hour or so once I make it home.
|