Dev:SundayMeetingAgenda/2007-12-23rd
Current Projects
Digimator is working on his layer management patch - ideas for mockups and such can be seen here - User:Digimator
alpharesearch is working on dupli stuff for peach - he has questions that he will send to brecht; his code is working and he put some stuff on the wiki...
vilda would like some further review of his blur node, and was requested to put updated comments in the tracker related to it
ianwill - pynodes, things are progresssing nicely, the problems jesterKing was concerned about are almost all fixed, I'll just need one or two days to finish / test a lot. the work can be clearly divided in steps, later we can update the scripting side and improve the interface, of course, after we get feedback
bdiego is working on a plugin api for nodes - ton would be interested in having it possibly merged with the pynodes work
Peach
andy will prepare blog post with *awesome* gfx and 'mostly thanks to brecht, we get a renderer that kicks asses'
Also Ton would like volunteers for documenting some of the new features - for instance for fur ' exact explanations of how the particle system works, how to comb good fur, how to setup shaders for it' etc.
What Ton did for his pre Christmas Vacation - AKA tool api refactor - aka custom bindings
Here are the raw logs of the discussion - still a lot of work ahead before things are usable
<ton> a patch for my code would efficiently mean a removal of about 250k lines of code :) <LetterRip> heh <ton> currently my blender can only do 1 things <ton> 1) duplicate window and 2) save the .B.blend <ton> *2 things <LetterRip> ah - truely minimalist <LetterRip> the zen of blending <vilda> blender 3.001 :) <bdiego> haha <vilda> letterrip :) <ton> but this is fully configurable! <ton> OK. if you guys sit down for 10 minutes, i got a lecture with slides! <LetterRip> too bad it weren't april <LetterRip> you could release just that as Blender 3.0 :) <ton> first off; i want to credit lukep for doing great initial research <vilda> all plugins coming soon :) <jesterKing> LetterRip: it makes a great christmas present, though! * Nichod is so happy he wants to buy ton a tropical island getaway <jesterKing> Blender 3.0D Preview! <LetterRip> Nichod, to finish? :) <jesterKing> with christmas only! <jesterKing> santa is blending * ton has changed the topic to: 3) Event recode slideshow:
http://www.blender.org/bf/eventrecode1.png
<ton> now listen!
<jesterKing> yay, mvc
<LetterRip> png doesn't support audio
<ton> :)
<ton> first see the resemblance and difference of MVC and blender's model
<vilda> ..
<ton> the blender model was sorta-mvc, but with 2 main weaknesses
<ton> 1) the UI was on all three levels
* mal_CanDo_ (n=chatzill@host86-131-170-88.range86-131.btcentralplus.com) has joined #blendercoders
<ton> (mvc demands UI is in 'v')
<ton> 2) the paradigm "only edit data, and not view" was violated all over
<ton> mostly because drawing code and event handling messed up badly
<ton> still can follow this?
<LetterRip> yeppers
<ton> now go to last diagram on page
<ton> now go to last diagram on page
<ton> to get all the specs we talked of possible, i had to split up the 'controller'
<ton> and call them handler and operator
<ton> a handler has the keymap, to match events
<ton> the operator is totally separated from handlers, to allow generic re-use
<ton> for macros, redo, python, whatever
<ton> operators also ONLY are allowed to work on the data (blender main database)
<ton> and NOT draw!
* SteveF (n=steve101@pool1651.hsc.unt.edu) has joined #blendercoders
<ton> drawing and refreshing UI goes via notifications
<ton> such notes don't have to be handled, or can be accumulated, etc
* markos__ (n=markos@85.72.102.50) has joined #blendercoders
* gustavg (n=chatzill@ad-f2-236.finet.se) has joined #blendercoders
<ton> sofar nothing radical new, quite clear right?
<vilda> ..
<LetterRip> yeppers
<bdiego> yes
<ton> for blender's code it's radical though :)
<zaghaghi> what about Handler->Notifiers?
<elubie> ton: that sounds quite clear and nice, yes
<ton> you mean, in what cases such actions are possible?
<ton> zaghaghi: good point, i might skip it, and only have operations do it
<zaghaghi> yes, when handlers send signal to notifiers?
<ton> but in some cases a more 'smart' handler is appreciated, to relieve operators from code
overhead
<ton> atm i just keep that open, but it is not implemented
<zaghaghi> oh, ok
<ton> (this was in a MVC model architecture doc i've read)
<ton>
http://www.blender.org/bf/eventrecode2.png
<ton> this is the event handling hierarchy
<ton> on top of our existing screen, theres the concept 'window' and 'windowmanager'
<ton> the windowmanger even is regular DNA item in blender, so you can have many configs
<ton> just for now to keep it simple;
<ton> note that windowmanager does notifications only
<ton> means; a button can send notes to redraw while being slided
<Nichod> So far sounds much more modular
<ton> handlers are on many levels; and some levels can even block others
<ton> example; the toolbox menu (space), it is a modal+blocking handler on bWindow level
<ton> while that menu exists, it swallows all, until closed
<ton> but; it can still send notifications for UI refreshing
<vilda> means i can be faster than blender
<ton> (also means i'll try to kill front buffer drawing)
* mal_CanDo__ (n=chatzill@host81-152-118-69.range81-152.btcentralplus.com) has joined
#blendercoders
<ton> this structure further will allow to open 2 or more 'screens'
<ton> or have 1 for each monitor
<zaghaghi> oh nice
<ton> and; i want to get rid of the static concept 'header'
* jesterKing must go :S
* jesterKing is now known as jesterDad
* Ikee (i=Ikee@0x535c3613.kd4nxx20.adsl-dhcp.tele.dk) has joined #blendercoders
<LetterRip> bye jesterking
* jesterDad will read backlog when .. back
<jesterDad> :)
<jesterDad> :)laters
<elubie> jesterKing: bye and merry christmas!
* Papulizer (n=stephan@p57B0CE3E.dip.t-dialin.net) has joined #blendercoders
<ton> the ScrArea will get free subdividing into sub-areas (regions called now)
<ton> so you can have larger haders, vertical ones, or 4 headers + toolbar, or... etc
<ton> keymaps are collections of definitions for how a certain operator is accessed
<elubie> ton: ah, that will be nice for filebrowser/imagebrowser too
<ton> elubie: yes, the windowmanager should manage for you to have a sidebar in 2d (scrollable,
whatever) and a main view you manage yourself
<ton> right now its a total hack all over
<elubie> ton: yep, I know it's hacked in ipospace, textspace and filebrowser/imagebrowser too
<ton>
http://www.blender.org/bf/eventrecode3.png
* mal_CanDo has quit (Read error: 110 (Connection timed out))
<ton> more details!
<zaghaghi> wait,
* mal_CanDo__ is now known as mal_CanDo
<zaghaghi> can we have remote bwindow?
<ton> you mean via X?
<zaghaghi> via ner
<ton> if you add that in ghost?
<zaghaghi> net*
* ton doesn't know much ghost...
<ton> in theory you can have 2 windows, each with same screen, so what you do in 1 screen shows in
the other
<ton> you mean that?
* ton wanted to hide this option from users though, it's a weird thing to have :)
<zaghaghi> no, i mean that we have 2 windows, one in my monitor, one in yours
<LetterRip> this should make GE views more easily plugable?
<LetterRip> ie for exernal engines?
<ton> zaghaghi: if ghost allows, it will work
<zaghaghi> ok,
<ton> LetterRip: the idea is that the 'space editor' or 'area' gets a full pluginnable API
<Nichod> Keep the option. Might be useful.
<ton>
http://www.blender.org/bf/eventrecode3.png <--- explaining stuff here now
<AkhIL> Will bEvent support multi pointer input devices?
<ton> sure, no prob
<ton> i want to test that idea
<ton> but i heard USB drivers wont like 2 mouses...
<ZanQdo> windows updating while moving sliders = lovely
<ton> AkhIL: i have read papers about 2-handed mouse input concepts, thats research we should do
<LetterRip> yeah - i'd like - rotate object with mouse while sculpting or animating with other one
* shzhc (n=ZZZZzzzz@58.33.163.157) has left #blendercoders
* stephan_ (n=stephan@p57B0C8CD.dip.t-dialin.net) has joined #blendercoders
<Nichod> Multitouch touchscreens
<ton> check the bEvent: it does all gesture stuff too, and allows very complex keyboard macros
<LetterRip> spaceball + pen tablet working in harmony...
<ton> i even reserved space for correct unicode language in events :)
<devroo> hmm does it mean, that will be possible render on background too?
<ton> devroo: you can already
<Gianmichele> ton, how much do you all this will take ?
* markos_ has quit (Read error: 110 (Connection timed out))
<ton> the basic layer for it is almost done
<ton> what you read here i have, but as said, only with 2 operators :)
<devroo> argh :) how (i know only about two blender apps trick)
* vampirefrog (i=misu@91.192.140.44) has joined #blendercoders
<ton> i come back to it
<ton> just check on bContext too
<ton> bContext will give each operator independancy and re-usability
<zaghaghi> it's very good that G will removed
<ton> new context? same operator does different stuff
<ton> or for python; of an operator demands a Space editor context, it can simply reject printing
automatic good error messages
<ton> the operator callbacks have a 'error poll' callback for example
<ton> now the operator...
<ton> the biggest challenge will be that we have to take EVERY OPTION in Blender, and recode it to
match this...
<ton> like for the Transform tool; you first try to split the whole in 3 calls; an init(), exec()
and exit() callback
<ton> these calls get this as args:
<ton> exec(Context *, Operator *)
<ton> operator itself stores local data (properties) sufficient to *completely* redo the exec
later on
<ton> so; the transform() tool 'move along normal of face 1 blender unit' has to store this in
operator properties
<ton> such that this operation is fully redoable
<ton> with different contextes
<ton> got the picture?
<bdiego> yes
<zaghaghi> yes
* ton took 2 hours with ideasman to go over every aspect for it...
* mal_CanDo_ has quit (Read error: 110 (Connection timed out))
<ton> ok; now shoot at me!
<ton> (i will add code in svn asap, as branch so people can peek)
<ton> (unsolved is still exact roadmap, the amount of bad code in blender is HUGE :)
<LarstiQ> ton: http://wearables.unisa.edu.au/mpx/ for a multi pointer X server
* LacertaII (n=simo@dsl-imtgw1-ffffc000-55.dhcp.inet.fi) has joined #blendercoders
<ianwill> merry christmas all :) this must have been the best meeting presentation here ever :)
<stiv> talk about multi-event(h,j,k) in bEvent, please
<ton> stiv: some events you want to trigger with mutiple keystrokes in a row
* JohnFr (n=Zombie_D@bas2-stcatharines10-1096628521.dsl.bell.ca) has joined #blendercoders
<ton> like asd or sad or das
<LetterRip> ton -- B B for paint brush
<elubie> or gzz
<LetterRip> select
<ton> i did not code this yet... but it should be possible
<ton> what i did code is modifier order
<ton> so you can poll for alt+ctrl or for ctrl+alt
<ton> also LMB can be modifier
<ton> so you can have a "if hkey + LMB pressed"
<ton> or gestures, these will be regular events too (but to get such events you have to notify the
windowmanager for it)
<elubie> ton: will operators be stored on some undo/redo stack?
<Nichod> ton what were you referring to early this morning about command history not being
possible?
<ton> so you can configure LMB-drag to become border select
<stiv> ton: very nice
<ton> elubie: just a listbase for now
<LetterRip> Nichod, he was talking about playback
<LetterRip> of complex scripts
<ton> yes, what i am struggling with is our opengl use...
<LetterRip> ie if someone does a bunch of modeling operations
<ton> selecing in blender uses zbuffer for example
<LetterRip> then have it played back what you did - selection might give different results
* gustavg has quit (Read error: 104 (Connection reset by peer))
<ton> i have no experience with construction history in apps... how do they store reliable
redoable selecting?
- knellotron (n=chris@ip68-230-250-137.rn.hr.cox.net) has joined #blendercoders
<LetterRip> ton - i think one of our open source competitors has such
<ton> i removed coding this from the immediate specs, is nice for later :)
<LetterRip> the one with a k
<LetterRip> k3d?
<ideasman42__> ton, Briggs has a lot to say on this
<ton> LetterRip: i know, but we need to study that
<ideasman42__> (and has looked into it, IIRC)
<minDrones> ton: will it be possible to start a fluid bake or a render and continue to work on
other stuff instead of wait for it ending? I mean as long as you're not changing
values of the scene involved in the render/bake (you could edit in the sequencer).
This is beacuse we can have a lot of processors maybe doing nothing..
<ton> unless you mean "can every operation be in thread" ?
<Nichod> So modeling operations @ the moment won't be reecordable and reusaable?
<minDrones> ton: not related to events?
* Papulizer has quit (Read error: 110 (Connection timed out))
<ton> Nichod: with this architecture proposal you can record it all (it is central event system),
but you cannot guarantee that such records give the same result on someone elses computer
<Nichod> Ie. Record a bevel, face extrude, scale. Then playback the opetation on selected areas.
<ton> a 100% foolproof operation recording and playback should mean that we exclude anything GFX
and windows related
<Nichod> *Operation
<ton> no selecting using opengl for example
<ton> but selecting using raytrace hits or so
<minDrones> ton: no I've meant to say "background rendering" for example, related to the UI
<Nichod> So is that a no in regards to my example?
<ton> minDrones: start a render in a thread, and continue work, is already possible with current
architecture too. we dont have to recode blender for that. it is not much related
<minDrones> ton: ok, thanks
<ton> use fork or so
<ton> or save .blend temp (use fast save using undobuffer) and call a system() with blender -a etc
* Digikiller has quit ("Leaving")
<ianwill> is the method of selection really relevant? Isn't it enough to store selection states
and the operations?
<Nichod> Thats myy thought as well.
<ton> ianwill: it goes against the idea of an 'operator' to save data
<ton> the operator should be 'select within this 3d cube all vertices' or so
* stephan_ has quit (Read error: 110 (Connection timed out))
<ton> in your case it is 'Select indices 1, 5, 3, 767, 210..."
<ton> such operations have hardly use for redo
<Nichod> Hmm.
<ton> that is more for undo-redo, not for actual history editis
<ton> anyhoo; in practice you wont use selection operators much for macros anyway
<Nichod> I'm referring to macros.
* gustavg (n=chatzill@ad-f2-236.finet.se) has joined #blendercoders
<Nichod> For modeling its quite useful.
<ton> ok; well, its an interesting topic to investigate definitely :)
<brecht> ton, how about modes, is that part of this design somehow?
* vampirefrog has quit ("Leaving")
<brecht> for example, do operator types define what mode they are valid in?
<ton> brecht: modes are all evil!
<ton> but for now, they're in Context
<ton> not in the operator
<Nichod> So no more pose mode, etc.
* Papulizer (n=stephan@HSI-KBW-078-042-030-098.hsi3.kabel-badenwuerttemberg.de) has joined
#blendercoders
<Ikee> ton: what bout those select tools that find things like the same normals or the random
selecter?
* ShortWave (n=shortwav@unaffiliated/shortwave) has joined #blendercoders
<ianwill> in simple cases like 'Select indices 1, 5, 3, 767, 210, etc.' the list of operations can
be processed to result in fewer commands, but yes, this requires more investigation
<ton> Nichod: i didnt mean to say that select-operators are not part of the system, they are. I
just fight with the way how to make them useful for redo or as part of macros
* Lacerta has quit (Read error: 110 (Connection timed out))
<LetterRip> Ikee - well anything random can store its seed
<ShortWave> Hrmmm
<ton> a mouse-select operator is not useful to store, i'm sure
<Nichod> Ok. What is the issue? I'm willing to research.
<ton> the action you tie to the mouseclick+selection, that is interesting
* oracle2025_ has quit ("Ex-Chat")
<ton> that way you can select + redo
<Nichod> Yes.
<ton> dont forget; blender paradigm is nonmodal nonblocking
<Nichod> Exactly.
<ton> so you select first, then operate
<ton> not operate then select
* LacertaII is now known as Lacerta
<ton> this will also enable the nice Modo feature, each tool (operation) generates a small UI in a
panel showing the settings for how it applied, and if you use that panel Modo undo's and
redos with new settings
<ton> more questions?
<Nichod> Within this recode is anything more useful happening to schematic view
<ideasman42__> Nichod, oops?
<ton> drag n drop?
<ton> matt's long wanted UI feature
<Nichod> Yeah. Connect materials within oops
<ton> ehh use the node editor for it!
<LetterRip> ton - errm how would the modo panel work?
<ton> but i see what you mean :)
<ianwill> just gotta say I'm pretty impressed, thankfull and happy :) ideasman42__: back to the
drawing board with bpy, we'll redo it all as it should be ;)
<LetterRip> it is the opposite of blenders
<ton> LetterRip: it just a UI for an operator
<ton> the architecture proposal i do has this
<ton> each operator should define UI too (so you can have panels, toolbuttons, etc)
* hannibar has quit ()
<ton> and by definition, an operator should be redoable, giving same data
<Nichod> I like oops. Would like blender to be more node based. Less panels.
<ton> so; you just do an undo, and apply the operator again
<stiv> ianwill: looks like we can finally fix the disconnect between blender operations and python
operations
<ton> LetterRip: it is not very 'opposite' to blender?
<LetterRip> eh could be misunderstanding
<LetterRip> so will wait and see :)
* ton thinks it is perfectly blenderish; nonmodal, nonblocking, and select + action order
<LetterRip> i was going by something lukep said which i may or may not have misunderstood
<ianwill> stiv: the separation of ui and operations is our #1 wish :)
<LetterRip> :)
<ton> yep. the python team should cheer about such recode :)
<stiv> yay!
<LetterRip> hip hip
<LetterRip> horah
<ton> dont understimate it though... i is a giant amount of work
* hannibar (n=hans_pac@190.58-66-87.adsl-dyn.isp.belgacom.be) has joined #blendercoders
<ton> my current approach is to get blender compiling without the src/ and python/ dirs in
source/blender
<elubie> hehe, just wanted to mention that there is still some mountain of work to climb ;)
<stiv> indeed. just plugging existing events back in will be huge
<LetterRip> well matt will refuse a new release without it finished :)
<ton> oh; the file structure...
<ianwill> but it's work we've been longing to do, happy times ahead :)
<Nichod> More related to ui, than refactor, but somewhat related. What is planned in regards to
panels? As things are getting more complicated they are showing there weakness.
<stiv> this breaks file format compatibility?
* ton has new module windowmanager, new module editors and in editors you find screen, area,
subarea, spacetypes (generic API) and the actual editors ipo/ image/ view3d/ action/ etc
* mo2l (n=mo2l@p5B11CEFE.dip.t-dialin.net) has joined #blendercoders
<zaghaghi> stiv, i think so
<ton> ooh, the blender/include/ dir also gone
<LetterRip> not clear to me how button and menu layouts are defined yet
<ton> blenkernel is getting clean now, as is render, and other modules
<mal_CanDo> Is there talk of possibly releasing another pre-2.5 Blender build, seeing as a lot of
cool features are in there ( eg before event refactor branch is working and ready to
move into main branch )?
* tanstaafl (n=blapp@81.8.159.68) has joined #blendercoders
<LetterRip> nor layouts for views etc
<stiv> will we still have blender/source/blender/src/blender/src/src ?
<ton> stiv: i am 100% sure we can be backwards compatible with this
<ton> but not forward compatible
<ton> so once you use new .blend files, it will throw warning box
<LetterRip> backwards compatible - can use old blends in new blender
<LetterRip> forward compatible - can use new blends in old blender?
<ton> i do keep in some forward compatible features though
* migius (n=migius@e179018134.adsl.alicedsl.de) has joined #blendercoders
<ton> LetterRip: yes
<LetterRip> k - we can live with that....
<ton> yes, this is such a radical recode, we can live with that
<ton> the UI definition (panels) is not part of my recode
<LetterRip> mal_CanDo, we might have a technology preview releae
<LetterRip> release
<ton> that UI project someone else can lead in meanwhile :)
<LetterRip> which isn't a supported release
<mal_CanDo> LetterRip, yep - that would be very cool
* x_fight81 (n=filippo@host2-86-dynamic.58-82-r.retail.telecomitalia.it) has joined #blendercoders
<ton> i try to make migration temporary handlers for it (like a uiBlock handler, that actually
calls mostly same code as previously)
<ton> the emphasis should be first on defining a very strict and understable API in blender
<ton> unified tools = operators API
<ton> then try to get back blender to work asap
<LetterRip> is defining the operators API something you will do then?
<ton> shall i paste some code?
* Skynet_italy (i=IceChat7@host130-38-dynamic.11-87-r.retail.telecomitalia.it) has joined
#blendercoders
<LetterRip> sure
<Nichod> Thanks for a great presentation ton.
<LetterRip> i'll basically post the whole conversation for this part of the minutes
<zaghaghi> ton, paste it
<ton> here is the entire hotkey list:
<ton> WM_keymap_verify_item(&wm->windowkeymap, "WM_OT_window_duplicate", AKEY, KM_PRESS, 0, 0);
<ton> WM_keymap_verify_item(&wm->windowkeymap, "WM_OT_save_homefile", UKEY, KM_PRESS, KM_CTRL, 0);
* Falgor (n=Petri@dsl-hkigw6-fe57de00-235.dhcp.inet.fi) has joined #blendercoders
<ton> this call verifies; means, if the hotkey was assigned already it skips
<ton> so it will not override custom maps
<ton> note that there's a windowkeymap, and there will be a screenmap, an areamap, an ipomap
<ton> an even a transformtoolmap
<ton> every modal tool can define maps
<Nichod> Sweet.
<ton> now the operator code:
static void WM_OT_window_duplicate(wmOperatorType *ot)
{
ot->name= "Duplicate Window";
ot->idname= "WM_OT_window_duplicate";
ot->interactive= NULL; //WM_operator_confirm;
ot->exec= wm_window_duplicate_op;
ot->poll= WM_operator_winactive;
}
static void WM_OT_save_homefile(wmOperatorType *ot)
{
ot->name= "Save User Settings";
ot->idname= "WM_OT_save_homefile";
ot->interactive= NULL; //WM_operator_confirm;
ot->exec= WM_write_homefile;
ot->poll= WM_operator_winactive;
ot->flag= OPTYPE_REGISTER;
}
<stiv> so new maps can be plugged in on the fly? <ton> stiv: yes, external files, or tools can do <zaghaghi> it means user custom map? <ton> the current transform tool actually does already <ton> user maps, default maps, temporary maps, all possible <ton> python maps * Digikiller (n=David@adsl-153-241-65.mia.bellsouth.net) has joined #blendercoders <ton> you see the operator? <stiv> mmm, python maps! <ton> ot->interactive= NULL; //WM_operator_confirm;
<ton> each operator also has an interactive callback, for the UI
<zaghaghi> ok
<ton> it can draw panels, or just throw a menu "OK"
* JohnFr (n=Zombie_D@bas2-stcatharines10-1096628521.dsl.bell.ca) has joined #blendercoders
* jpt9 (n=jpt9@pool-68-163-167-50.bos.east.verizon.net) has joined #blendercoders
* Digikiller has quit (Client Quit)
<ton> and because operations store all data we need, you dont have to code that yourself really
<ton> we can make automatic UI generating for operators
<ton> operators: only code once, re-use everywhere :)
<ianwill> ton: will operators be "stored" as py commands, is that the idea?
<ton> ianwill: right now they are stored as raw data
<ton> but ideasman42__ insisted on having operators with ID properties, so it can be completely
compatible with using py
* Evangel has quit (Read error: 104 (Connection reset by peer))
<ton> (not using dna structs for custom operator data)
<ideasman42__> some 'key':value mapping anyway
<ianwill> cool :)
<ianwill> user created scripts on the fly :)
<ton> ianwill: it means that *by definition* a new tool in blender has py wrapper
<ideasman42__> yay!!!
* ideasman42__ is extra keen on making this api good!
<ton> and it means that *by definition* the context will be checked for you
<ianwill> :)
* Papulizer has quit (Read error: 110 (Connection timed out))
<ton> i call this the "poll" callback for now, which returns the state of operator in relation
context
<ton> operator->poll(context)
<ton> returnvalue "you can not operate"
<LetterRip> will IDs be tied to tool names - so that we can be sure of non collisions?
* Papulizer (n=stephan@p57B0E9C4.dip.t-dialin.net) has joined #blendercoders
<ton> so you can grey out toolbar items or menus
<ton> or it can print nice python user errors
<Nichod> :)
* AkhIL has quit (Read error: 104 (Connection reset by peer))
<ton> LetterRip: non collisions with what?
<ton> the current proposal for ID names is just a string
<ton> syntax for it we can study on...
<LetterRip> ton - was curious how the string is generated
<ton> manually :)
<ton> i use same name as function
<LetterRip> okay that is what i was curious about
<ton> that name is not very interesting for users
<LetterRip> and prefer
<ton> as you can see in pastebin, there are 2 names, one unique id, and one readable version
<ianwill> that way you're garanteed to have unique names or blender doesn't link :)
<LetterRip> ianwill, my concern was in version foo you have unique id with tool a
<LetterRip> but in later version it is with tool b
<ton> LetterRip: we should not do that
<ton> if you make tool obsolete, you leave it in with an error print "depricated"
<LetterRip> well another concern is if method of tool changes
<LetterRip> bevel
<LetterRip> bevel b
<ton> yeah, but that concern you will always have :)
<LetterRip> bevel revision c
<LetterRip> yeah
* ton didnt solve bad habits people will have anyway
<LetterRip> well i think the unqiue id should perhaps have a date stamp of last revision
<LetterRip> so an old script can warn of possible incompatibility
<ton> my idea: put 2-3 months effort in doing a radical cleanup., and then there will be new mess
anyway
<ton> but more advanced mess definitely :)
<ideasman42__> ton, by the way, will the existing python api work with this?
<ton> ideasman42__: not without efforts
<ton> you will have to re-insert every tool and option
<ideasman42__> personally Im happy to throw it away
<ideasman42__> but others will cry
<ton> or even better; code a way that automatic registers tools
<LetterRip> well i don't want is in 'release limbo' for eternity
<LetterRip> us
<ideasman42__> maybe it would be good to do a 2.45b release before the changeover
<ton> what you guys did in python/api2x2/ is actually going to be done for you
<ton> ideasman42__: or not
<ton> a release will take weeks of energy away
<ideasman42__> yeah :/
<ton> my idea:
<LetterRip> true
<ton> - one or two weeks evaluation of this plan
<ton> i will post more docs + code
<ton> and i have to do some more code work
<ton> so the basics is there fully
<LetterRip> i guess how will this impact apricot work?
<ideasman42__> a last snapshot of the source before the switch would be good for people who rely
on scripts/tools with the old api
<ton> then we have to form a TaskForce 2.5!
<ton> oh, we need 2.5 TaskForce tees for the devs!
<macouno> ideasman42__, throw the api out already! :P
<LetterRip> pfftt 2.5 - 3.0!
<ideasman42__> macouno, maybe even throw the api I was working on away, thats ok by me, I learnt a
lot writing it ;)
<ton> it actually has the 3.0 specs, i agree
<LetterRip> hmmm then also we could do a starwars reference
<ton> but lets do 2.5 first and make it stable
<ton> and then see how to proceed next
<ton> anyhoo!
<ton> the 2.5 team then can split up in many smaller jobs
<ton> like -> code the gesture API
<ton> like -> code the area-space API (pluginnable)
<ton> and like -> clean bad level calls from blenkernel
<ton> and then each space type
<ton> (ipo nla view3d etc)
* ton will make the list
<LetterRip> also we will need to decide whether it will be better to try and switch to bmesh
<LetterRip> or recode the mesh tools
<ton> it is 300,000 lines of code :(
<ton> but, better do it now than never :)
<LetterRip> presumably this will be a branch and not head?
<ton> evil plan; not releasing will give everyone extra incentive to help and finish it
<ton> LetterRip: i guess so
<ton> we need a working blender for peach :)
* macouno recons this is a good opportunity to take a leap in stead of baby step... so why not
bmesh
<ton> but
<LetterRip> also what/how will apricot work?
<ton> not thought of that
<ton> like peach, they can use the svn official version
<ton> main problem: *any* commit that now goes to blender/src or blender/include or blender/python
is going to be completely unmergable
<ideasman42__> ton, can have a peach branch
<ton> of course we can
<ideasman42__> then trunk can be event stuff, push dev's to get it working fast!
<ton> but how to merge?
<ton> oh, you just propose more evilness :)
<ton> as if the community doesn't discover the peach branch!
<ideasman42__> well software deadline is coming up for peach, should not change toooo much
* JohnFr has quit ("Leaving.")
<ton> "new download snapshot of blender 2.50 pre! has 2 options only!"
<ideasman42__> ton, thats fine, community can use plumi-blender. or peach, but the new goodness is
in trunk, or should be ;)
<bdiego> haha
<ton> yes i agree we have to migrate asap
<ton> we can do an option migration termometer on blender.org
<ideasman42__> people tend not to download branches
* migius will asking for SVN commit rights at the end of this meeting
<bdiego> yes, that is true
<ton> ideasman42__: tell ZanQdo!
* ton knows the community goes where the interesting stuff is
<LetterRip> ton - if there is 'work that can be done now' without further discussion - i'd set
your branch up immediately
* dino4k has quit ("def foo(): print 'bar';")
<LetterRip> and post what that is
<LetterRip> people are on Christmas vacation and so if they have free time
<LetterRip> might want to work on it
<ton> LetterRip: i will add code asap (today, tomorrow) but it is not ready for a todo list
<LetterRip> k
<ton> it is important first that the key devs here digest the info
<ton> and i bet there will be more amendments
<LetterRip> yeah
<ton> so we have to give it a bit time
<LetterRip> also a lot of this is 'code monkey work'
<LetterRip> so might be a good time to invite in new devs
<ton> well; but not too easy work
<ton> try to imagine how to recode sculpt in operation structure...
* JohnFr (n=Zombie_D@bas2-stcatharines10-1096628521.dsl.bell.ca) has joined #blendercoders
<ton> same goes for transform()
<ton> although, after transform recode, it will be a great api for a lot of tools
<LetterRip> well obviously not all is code monkey :)
<elubie> I think it would also be a good idea to peer-review each others code during the
migration, we do this at work and it's a good way to learn about that part of the code
and it also helps to catch messy code ;)
* ghostwood (n=susan@76-247-23-238.lightspeed.dllstx.sbcglobal.net) has left #blendercoders
<ton> ideasman proposed that we should do here (brecht + campbell + me) a major part first
<LetterRip> well it would be good to start getting rid of magic numbers and such for sure
<LetterRip> if we can
<ton> and get that experience documented, so it is repeatable
<LetterRip> ton - sounds like a good plan
<ton> while you do this work, we can efficielty discuss and decide
<ton> l->n
<ton> and there are three independent minds here :)
<LetterRip> a problem is
<ton> so when we agree, we probably have 99% of the rest agreeing :)
<LetterRip> that brecht will be tied up till your code deadline presumably
<elubie> I agree, this kind of work benefits from quick and close discussions
<LetterRip> same with ideasman42__
<LetterRip> and peach takes priority
<ton> yep
<ton> but peach is a blender project, no?
<ianwill> is it overkill to consider internationalization at this point, too? Thought about it
seeing the ot->name= "Duplicate Window" and ot->name= "Save User Settings"...
<ton> ;-)
<LetterRip> sure - just pointing out that this will likely put this on hold till the critical code
time for peach is done
<ton> ianwill: yep, i need someone's ideas for it
<ianwill> long time no see, but from what I recall it's not hard to prepare strings for translation
<ton> ianwill: i think that it is better code to leave this in now
<LetterRip> if possible would be good idea to switch to proper support for it
<LetterRip> so that we use the libraries correctly
<ton> and - because of design - operations each can get translated very efficiently later on in
the pipeline
<elubie> ianwill: good point. Might be a chance to clean up the iconv library mess too.
<ton> operator_translate(op, language)
<ton> each op is unique, no confusement
<ton> maybe we have to add more strngs to ops
<ianwill> ton, elubie: that's another work group to define / create: the translation team :)
<ton> a python name for example
<ton> and a tooltip
<ton> and manual
<ideasman42__> maybe use wchar by default?
* ton never coded international
<LetterRip> as much work as this will be - is gonna be a logistical nightmare :)
<ianwill> from interest in bf-committers, there should be at least a few coders willing to
participate in i18n efforts
<ideasman42__> all strings in python 3,0 will be UTF
<ton> ianwill: one approach is to let someone review the structure with translation in mind,
accept the useful amendments, but not implement it, just leave that for the new team to
arise later
<LetterRip> ton - is there any way to reduce the amount that has to be 'changed at once'
<ton> maybe it just like 'use a wchar array'
<elubie> ideasman42_: yes, we partially have UTF translation, but it's incomplete, so needs review
<ton> LetterRip: most of the buttons code can remain same :)
<LetterRip> ie perhaps a hackish compatibility layer?
<ideasman42__> elubie, was also thinking of people writing in their native lang, not just
translation
<ton> and menus, i tried to make this migratable as possible
<ton> but not for the tool code itself
<LetterRip> just saying that 5% of code at a time is far more managable than 90% of code at once
<elubie> ideasman42__: yes, that needs review too.
<ianwill> http://en.wikipedia.org/wiki/Gettext is a start
<LetterRip> i guess how much code needs to be ported before we can even test?
<ideasman42__> elubie, i personally am not that interested in utf stuff, but should probably be
thaught of early ;)
<LetterRip> anything
<ton> LetterRip: i tried to find a way to keep blender full working, and only migrate piece by
piece. This is by-definition impossible according to me...
<LetterRip> ton - yeah....
<elubie> I agree with LetterRip, it's all nice stuff, but we need to keep it manageable
<LetterRip> i just don't want to end up in the 2 year recode that happens so often :)
<LetterRip> with other opensource projects
* ton doesn't neither
<ton> we're not another opensource project neither :P
<LetterRip> true - we have far better leadership
<ideasman42__> sombody touched a nerve ;)
<ton> imagine this: we bring back the UI and editors, but without any tool (but it does draw etc)
<LetterRip> but netscape to firefox....
<ton> then we give a very clear instruction for how to re-add tools
<ton> which is about 10 minutes to 1 hour work per tool
<ton> you can bet that tools get added again once people need it anyway
<LetterRip> can we guesstimate how many man hours?
<LetterRip> ie what is the 'number of tools'
<minDrones> would it be nonsense to have a special shortcut by which clicking on a button you're
sent to a local web page with the manual of what that button does? (sorry, this might
be OT again :)
<ton> the breakpoint is when we can show something in blender *SO COOL* that everyone considers it
a must have
<LetterRip> and assume 40 minutes per tool..
<ton> well; count the amount uiDefButs in blender, and divide it by 5?
<LetterRip> ton - well finishing the port of bmesh is certainly one way to do that
<ton> some pulldown menus each have a tool
<ianwill> minDrones: doable, I once talked about it with ton. The real issue is having authors to
write such documentation
<ideasman42__> minDrones, probably not event-refactor related - could be done now, ;)
<minDrones> :) sorry
* ton talked to andy about this
<LetterRip> so a grep of the number of uiDefButs
<ideasman42__> minDrones, I was interested in that a while back, could make it a part of the
tooltip thats not seen. but people were not that interested in adding
<ianwill> next Blender with bmesh (ngons) and event refactor? What will be left for those guys to
complain? ;) The name?
<ton> i think 2 options will give a lot of positive energy:
<ideasman42__> did we agree bmesh was a part of it?
* Gianmichele has quit ("CGI:IRC (Ping timeout)")
<ton> 1) be able to remap hotly for every menu item, by just clicking on the remap button for the
menu
<ton> *hotkey
<LetterRip> ideasman42__, brecht Briggs and ton need to discuss it in my opinion to decide
<ton> and 2) macros
<ton> and 3) multi-window layouts
<ton> although i detest that personally :)
<LetterRip> heh
<ideasman42__> LetterRip, IMHO depends a lot on briggs, need to see his timeframe for adding
<ton> but in some cases its useful
<brecht> i would definitely not tie up bmesh with this, or any new functionality that is not
really ui related
<ton> we should have briggs here for a project
* Gianmichele (n=5707e660@gateway/web/cgi-irc/ircatwork.com/x-9e3b1d538518d8d9) has joined
#blendercoders
<ton> maybe he wants to take over nicks sculpt ?
<LetterRip> brecht, my thought on that is that the mesh tools might take longer to port than to
adapt to bmesh
<ideasman42__> ton, definetly, and give him some time to do his real work too
<ton> what is his real work?
<LetterRip> ton he works for a company that has him do blender related tools
<brecht> LetterRip, I don't think it is that much extra work
<ton> aah
<LetterRip> for flight sim related stuff
<ideasman42__> ton, similar to what I used to do, work from home for a sim company ;)
<ton> brecht: i agree
<LetterRip> yeah
<LetterRip> brecht, ok
<glome> Does Peach still need sky shading code?
<ton> LetterRip: the new operation structure has to be done anyway, and bmesh will have 80% same
options i guess
<ideasman42__> glome, yes! but its hard to say if we could use in time
<ton> glome: yes
<ton> you got it?
* venar303 has quit ()
<glome> Would it be ok to use stellarium sky shading code
<glome> it's gpl
<ideasman42__> glome, have you looked into it much?
* ton wants this http://ati.amd.com/developer/SIGGRAPH03/PreethamSig2003CourseNotes.pdf
<glome> I tested it and it works well with blender: http://www.youtube.com/watch?v=FOI5kRAlYkY
<glome>
http://koti.mbnet.fi/~ilmola/sky1.png
<ton> glome: we dont need someone's code, we need someone's efforts to make blender work well :) <glome>
http://koti.mbnet.fi/~ilmola/sky2.png
<ton> aah! that yes
<LetterRip> brecht, i think he was planning to finish bmesh for xmas vacation
<LetterRip> hench why i suggested it..
<ton> glome: you see that pdf? it looks same...
<LetterRip> but if you don't think porting the current mesh tools will be much effort than that is
great
<mal_CanDo> glome, Stellarium is for stars / planets, I think lower stratosphere stuff ( clouds )
is required for Peach
<Skynet_italy> WITH_BF_FFMPEG = 'false' for compilling in windows or error why?
<glome> That's the same algorithm that Stellarium uses
<brecht> LetterRip, if tool refactor is underway at the same time he wants to merge, then i think
it would be ok to skip doing current mesh tools
<mal_CanDo> but being able to render a night-time realistic sky ( with accurate stars etc ) would
be a cool feature of course, if perhaps niche :)
<LetterRip> k
<brecht> LetterRip, but i think it would be a bad idea to create a dependency
<brecht> on bmesh
<LetterRip> yeah understtod
