On Wed, Jan 26, 2005 at 12:20:57PM +0100, Krzysztof Czaja wrote:
hi carmen,
have not found any good solution yet, still trying...
just removed 'edit' mode in my version, in favor of making 'edit-mode' the default while renaming non-edit-mode to 'lock patch' - even among similar apps, Bidule/Reaktor/VVVV get along fine without seperate modes, not to mention my text editor, paint program, etc.. the only programs i can think of with 'edit-mode' forced upon the user are vi and Max/MSP, neither of which i pretend to like in the Usability dept..
more than a bit baffled why the gui is bypassing Tk's mature binding and event system and instead sending over "motion" events to let the C side manage all of this stuff (in a much less readable/hackable fashion), but ive opted for synthesizing an event when an object is selected via lasso:
<<$target-Select>> {bind <button1> {} ... (unbind stuff)}
<<$target-Deselect>> { bind <button1> {do some interactive stuff..}}
so the objects can subscribe as necessary...a vi-user could rename these functions to <$canvas-Edit-0> <$canvas-Edit-1> or what not, the principle being the same.
and you can always drag the object without selecting it by holding down Alt..its great to stop riding ctrl-e all the time..
carmen wrote:
hi Krzysztof...im wondering how youve made kb & multiscale draggable in edit mode. my widgets all bind <ButtonPress-1> for someting or other..and they can only moved in edit mode by a border...or by selecting multiple objects and moving the other (such as select a numbox + widget)
carmen wrote:
On Wed, Jan 26, 2005 at 12:20:57PM +0100, Krzysztof Czaja wrote:
hi carmen,
have not found any good solution yet, still trying...
just removed 'edit' mode in my version, in favor of making 'edit-mode' the default while renaming non-edit-mode to 'lock patch' - even among similar apps, Bidule/Reaktor/VVVV get along fine without seperate modes, not to mention my text editor, paint program, etc.. the only programs i can think of with 'edit-mode' forced upon the user are vi and Max/MSP, neither of which i pretend to like in the Usability dept..
oh, no!
flames for modes vs modeless !
personally, i feel at home in pd's modes, so i would not want to change that.
all programming languages i know are mode-based (edit/compile/run or edit/run), so i would not go too much for WordPerfect or PhotoShop ...
(and for the usual flames: i prefer both vi and emacs)
mfg.asd.r IOhannes
flames for modes vs modeless !
definitely didnt mean to start flame wars here...theres no question you can do some serious edit-fu with vi once you figure it out ..
personally, i feel at home in pd's modes, so i would not want to change that.
i never considered it until creating widgets that behave the same in either 'mode' and realized it would take extra effort to make them behave different..so its mostly laziness on my part..anyways solved it by: foreach p [info procs] {if {[regexp -- .*-edit-1 $p] == 1} {eval $p}}
so i guess searching thru global proc list is ugly but it works for switching widget bindings back to motion stuff during edit mode.. but if the main purpose behind edit mode is just this, it can be handled transparently enough without any modes,.ie: select/blue-highlight for move, deselect for number action..
c
all programming languages i know are mode-based (edit/compile/run or
avoiding edit(Crazy syntax)/compile/run is why i prefer PD!!
hi carmen,
today's toxy (alpha15) handles megawidgets much better -- subwidgets are inactive in edit mode, Frames seem to work as well, as Canvases. To appear in cvs later today, once I validate new cyclone stuff for a release.
However, widgets will never work perfectly in edit mode, unless Pd has a callback mechanism, allowing objects to register to be notified of mode changes. Currently, toxy widgets (and sub-widgets in alpha15) use a faked callback bound to <Enter> and <Leave> events.
Krzysztof
carmen wrote: ...
they can only moved in edit mode by a border...or by selecting multiple objects and moving the other (such as select a numbox + widget)
-
carmen -
IOhannes m zmoelnig -
Krzysztof Czaja