| | 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
|