| 03:26.35 | *** join/#bzflag delusional (~delusiona@pool-98-111-215-152.pitbpa.fios.verizon.net) |
| 05:17.02 | *** join/#bzflag Constitution (~josh@bzflag/developer/Constitution) |
| 05:49.19 | *** join/#bzflag rob1n (~rob1n@unaffiliated/rob1n) |
| 07:10.36 | *** join/#bzflag BulletCatcher (~bc@bzflag/developer/BulletCatcher) |
| 08:00.40 | *** join/#bzflag L4m3r (~l4m3r@bzflag/developer/L4m3r) |
| 08:00.42 | *** mode/#bzflag [+v L4m3r] by ChanServ |
| 09:17.08 | *** join/#bzflag DTRemenak (~DTRemenak@about/essy/CrazyCoder/DTRemenak) |
| 09:17.09 | *** mode/#bzflag [+v DTRemenak] by ChanServ |
| 10:36.58 | *** join/#bzflag DTRemenak (~DTRemenak@76-227-151-154.lightspeed.irvnca.sbcglobal.net) |
| 10:36.59 | *** join/#bzflag DTRemenak (~DTRemenak@about/essy/CrazyCoder/DTRemenak) |
| 10:36.59 | *** mode/#bzflag [+v DTRemenak] by ChanServ |
| 11:16.58 | *** join/#bzflag DTRemenak (~DTRemenak@76-227-151-154.lightspeed.irvnca.sbcglobal.net) |
| 11:17.00 | *** join/#bzflag DTRemenak (~DTRemenak@about/essy/CrazyCoder/DTRemenak) |
| 11:17.00 | *** mode/#bzflag [+v DTRemenak] by ChanServ |
| 11:36.57 | *** join/#bzflag DTRemenak (~DTRemenak@about/essy/CrazyCoder/DTRemenak) |
| 11:36.57 | *** mode/#bzflag [+v DTRemenak] by ChanServ |
| 12:26.58 | *** join/#bzflag DTRemenak (~DTRemenak@76-227-151-154.lightspeed.irvnca.sbcglobal.net) |
| 12:26.59 | *** join/#bzflag DTRemenak (~DTRemenak@about/essy/CrazyCoder/DTRemenak) |
| 12:26.59 | *** mode/#bzflag [+v DTRemenak] by ChanServ |
| 13:26.21 | *** join/#bzflag _lmnop14 (~lmnop@91-65-161-106-dynip.superkabel.de) |
| 13:28.39 | *** join/#bzflag _lmnop15 (~lmnop@24-134-95-119-dynip.superkabel.de) |
| 13:34.26 | *** join/#bzflag _lmnop16 (~lmnop@91-65-161-106-dynip.superkabel.de) |
| 15:49.20 | *** join/#bzflag Pimpinella (~frank@gondolin.pimpi.org) |
| 16:33.47 | *** join/#bzflag JeffM (~JeffM@12.167.61.2) |
| 17:17.01 | *** join/#bzflag DTRemenak (~DTRemenak@76-227-151-154.lightspeed.irvnca.sbcglobal.net) |
| 17:17.02 | *** join/#bzflag DTRemenak (~DTRemenak@about/essy/CrazyCoder/DTRemenak) |
| 17:17.02 | *** mode/#bzflag [+v DTRemenak] by ChanServ |
| 17:37.57 | blast007 | I've started working on the dialog system for 2.5. Mostly been working on the protocol definition and have pack/unpack methods mostly done for a modal dialog, and I started on a server-side dialog manager last night. |
| 17:39.22 | blast007 | Did we have some existing or partially working dialog system for 2.99.x? |
| 17:49.52 | JeffM | DTRemenak had done some work on that in 2.99 IIRC |
| 17:53.04 | blast007 | And currently I'm making it gears towards server-controlled dialogs, though a previous discussion had mentioned using dialogs for image host whitelisting. |
| 17:53.49 | JeffM | as long as the client can display a dialog from some kind of defintion we can use it from the server or from internal client code |
| 17:53.55 | blast007 | However, I'd probably keep the graphical rending of dialogs separate from the network part of it. |
| 17:53.59 | blast007 | rendering* |
| 17:54.02 | JeffM | sure |
| 17:54.11 | JeffM | you want to unpack some kind of logical defintion |
| 17:54.16 | JeffM | then have the rendering code display it |
| 17:54.35 | JeffM | and maybe have the defintion contain callbacks for what to call on specific evens like buttons and stuff |
| 17:55.00 | JeffM | then the networking part can install hooks to the net messages for those dialogs it makes, and the client code coudl install it's own callbacks for local only dialogs |
| 17:55.09 | JeffM | then the rendering system won't care who requested the dialog |
| 17:55.31 | blast007 | main idea right now is to have a base "Dialog" class with a "ModalDialog" and "UnobtrusiveDialog" child classes, and then have a ServerDialogManager and ClientDialogManager. Both client and server would share the Dialog class and child classes. And then there'd be a class for rending on the client (or it'd maybe be part of the client manager) |
| 17:55.50 | JeffM | why do you need 2 managers? |
| 17:56.00 | JeffM | what would the difference be between them? |
| 17:56.16 | blast007 | well, client manager would also manage client-initiated dialogs |
| 17:56.40 | JeffM | how are they managed different from server dialgos other then what gets called based on events? |
| 17:57.05 | blast007 | server dialogs all have a server-wide unique ID |
| 17:57.24 | JeffM | thats just a property of the dialog descriptor :) |
| 17:57.43 | blast007 | *shrugs* we'll see ;) I haven't got that far in the manager part of it yet |
| 17:57.53 | blast007 | been working mostly on network proto handling |
| 17:57.53 | JeffM | I wondering why not have a single manager, that takes a dialod description, and that description contains the event handler |
| 17:57.57 | JeffM | ok |
| 17:58.09 | JeffM | then you just feed dialogs into the manager, from 2 sources |
| 17:58.21 | JeffM | then if we end up with client scripting, that's just a third source |
| 18:30.56 | *** join/#bzflag DTRemenak (~DTRemenak@76-227-151-154.lightspeed.irvnca.sbcglobal.net) |
| 18:30.57 | *** join/#bzflag DTRemenak (~DTRemenak@about/essy/CrazyCoder/DTRemenak) |
| 18:30.57 | *** mode/#bzflag [+v DTRemenak] by ChanServ |
| 18:37.07 | *** join/#bzflag DTRemenak (~DTRemenak@76-227-151-154.lightspeed.irvnca.sbcglobal.net) |
| 18:37.07 | *** join/#bzflag DTRemenak (~DTRemenak@about/essy/CrazyCoder/DTRemenak) |
| 18:37.07 | *** mode/#bzflag [+v DTRemenak] by ChanServ |
| 19:21.16 | blast007 | JeffM: still trying to visualize how I'd be able to have a single manager |
| 19:21.45 | *** join/#bzflag Constitution (~josh@bzflag/developer/Constitution) |
| 19:22.49 | blast007 | the manager on the server generates a dialogID and has a std::map<uint32_t, Dialog*> that tracks the server generated dialogs, where that uint32_t is the dialogID. |
| 19:25.15 | blast007 | and that ID is used on the client when receiving and ssending information about the server generated dialogs, such as for sending a response back to the server or when the server tells the client to close a dialog |
| 19:32.10 | JeffM | ahh ok, I musunderstood you |
| 19:32.22 | JeffM | I thouht you were saying 2 managers on the client side |
| 19:32.33 | JeffM | yes you'll need something on the server to manage who has what dialogs |
| 19:32.36 | JeffM | I'm sorry |
| 19:32.52 | JeffM | the question is if those 2 can share any code |
| 19:32.58 | JeffM | probalby not |
| 19:33.12 | JeffM | since it's really a front-end/back-end type sytem you have |
| 19:33.24 | JeffM | with a data structure to communicate bettween them |
| 19:40.47 | blast007 | yeah, one is sending dialogs and receiving responses, one is receiving dialogs (and managing local dialogs) and sending responses |
| 19:42.13 | blast007 | I'm thinking that this system would proably need the buffered network stuff or a segmented message as it's going to be easy to blow past our 1024 byte limit |
| 19:42.38 | blast007 | I've not yet taken that fact into account with my design |
| 19:44.24 | JeffM | yeah it will need to be buffered |
| 19:44.47 | JeffM | you should be able to assume we can implement a functional buffered network |
| 19:44.53 | blast007 | ok |
| 19:44.58 | JeffM | I have 2 weeks off school next week and I can help with that if you need |
| 19:45.21 | blast007 | I will try to commit and push what I have tonight so that others can see if it's a decent design |
| 19:45.21 | JeffM | we need the buffered messages for SO many other things |
| 19:53.50 | blast007 | I'm wondering if my Dialog classes should be named DialogData/ModalDialogData/etc instead, as they're really just containers and transport code for the data itself, not the graphical representation of the dialogs |
| 19:54.23 | JeffM | the descriptor is the dialogdata, the rendering is the view and the manager is the controller |
| 19:54.27 | JeffM | so it fits that model very well |
| 19:54.56 | blast007 | k, so 'yes' to appending the 'Data' part to their names? |
| 19:55.03 | JeffM | modal or not is just an attribute on the descriptor |
| 19:55.23 | JeffM | I don't know if you need different data descriptors for the different "types" |
| 19:55.25 | blast007 | well, modal is done a lot different than the unobtrusive |
| 19:55.38 | JeffM | at the rendering level? or at the data level? |
| 19:56.17 | blast007 | modal is more like a menu (with everything a menu can have, and buttons, and it the ability to trigger individual items or send the entire "form"), unobtrusive is a tooltip with text and hotkeys only |
| 19:57.03 | JeffM | do they have radicaly different behavors at the manager level? |
| 19:57.05 | blast007 | so far the only thing they'd share is the dialogID, ownerID, and the intial header bits of the network |
| 19:57.32 | JeffM | I guess I'd have to see what you are sending over the network, what's in your dialog descriptor |
| 19:57.35 | blast007 | manager level, not really, which is why they are both based on the 'DialogData' class which the managers will track |
| 19:57.56 | JeffM | then it sounds like it's just a rendering level or view level difference |
| 19:58.14 | JeffM | modalDialogDisplay, unobtrusiveDialogDisplay, etc.. |
| 19:58.23 | JeffM | think about what happens if we add a third type |
| 19:58.24 | blast007 | so are you thinking that I should just have a single 'DialogData' class? |
| 19:58.44 | JeffM | yes, that class is the data to transport, then it gets put into a display class on the client |
| 19:58.49 | blast007 | ok |
| 19:58.51 | JeffM | you can have multiple display systems |
| 19:59.02 | JeffM | but the data descriptor should be the same |
| 19:59.20 | JeffM | since the data is just layout info and events |
| 19:59.23 | blast007 | "data descriptor" meaning what? |
| 19:59.35 | blast007 | cuz again, they have very different data |
| 19:59.49 | JeffM | it should be a container of data items |
| 20:00.15 | blast007 | hmm, and I guess the unobtrusive should support more than just text as well |
| 20:00.19 | JeffM | so somethign that says "I want a label that says "XXX", a Button that says"YYY", and a checkbox" |
| 20:00.29 | blast007 | just not interative menu items |
| 20:00.39 | JeffM | yeah by Convention you'd just not put some data items in those types of dialgos |
| 20:00.50 | JeffM | but the traansport should not enforce that |
| 20:00.51 | blast007 | but something like L4D2's voting screen should be possible in the unobtrusive |
| 20:00.54 | JeffM | since we can't see the future :) |
| 20:01.09 | blast007 | (with fancy big checkboxes) |
| 20:01.20 | JeffM | so I'd have a list of data items, that have a type, data, and event to call if they get hit |
| 20:01.32 | JeffM | and that event can be a network message or a local callback |
| 20:01.41 | JeffM | then the display stuff would work from any source |
| 20:01.58 | JeffM | you just fill out a dialog descriptor and send it to the rendering system |
| 20:02.17 | blast007 | and a timer item would probably be useful as well so that the client can have a countdown for things like voting or team selection :) |
| 20:06.55 | *** join/#bzflag DTRemenak (~DTRemenak@76-227-151-154.lightspeed.irvnca.sbcglobal.net) |
| 20:06.56 | *** join/#bzflag DTRemenak (~DTRemenak@about/essy/CrazyCoder/DTRemenak) |
| 20:06.56 | *** mode/#bzflag [+v DTRemenak] by ChanServ |
| 20:18.06 | JeffM | yeah sure you can have all kinds of control types that you define as data items |
| 20:18.27 | JeffM | the big question is how you are you going to define how they are laid out? |
| 20:18.34 | JeffM | pixels? screen percent? |
| 20:18.49 | JeffM | let the client just figure it out? |
| 20:38.02 | *** join/#bzflag Pimpinella (~frank@gondolin.pimpi.org) |
| 20:52.13 | blast007 | at this point I was just gonna have them laid out top to bottom like our menus |
| 20:52.39 | blast007 | but yeah.. probably should be a more generic UI representation.. |
| 20:53.06 | blast007 | though maybe I'd wait on that for 2.8 |
| 20:53.43 | blast007 | I see a flexible UI for dialogs as something that we could feature creep to hell and never finish |
| 20:56.53 | *** join/#bzflag DTRemenak (~DTRemenak@about/essy/CrazyCoder/DTRemenak) |
| 20:56.54 | *** mode/#bzflag [+v DTRemenak] by ChanServ |
| 21:02.15 | JeffM | heh |
| 21:02.27 | JeffM | yeah left to right top down is probably fine for auto layout |
| 21:02.43 | JeffM | then the client can pick a font size and build it up |
| 21:46.59 | *** join/#bzflag DTRemenak (~DTRemenak@76-227-151-154.lightspeed.irvnca.sbcglobal.net) |
| 21:46.59 | *** join/#bzflag DTRemenak (~DTRemenak@about/essy/CrazyCoder/DTRemenak) |
| 21:46.59 | *** mode/#bzflag [+v DTRemenak] by ChanServ |
| 21:58.06 | *** join/#bzflag rob1n (~rob1n@unaffiliated/rob1n) |
| 22:09.04 | *** join/#bzflag delusional (~delusiona@pool-98-111-215-152.pitbpa.fios.verizon.net) |
| 23:01.04 | *** join/#bzflag delusional (~delusiona@pool-98-111-215-152.pitbpa.fios.verizon.net) |