[Bf-compositor] [enh] Node Socket Swapping

Tue Nov 19 10:37:51 CET 2013

It's for clicking on the *socket*, not the noodle :)

http://www.pasteall.org/pic/62813

On Tue, Nov 19, 2013 at 10:25 AM, Aditia A. Pratama <aditia.ap at gmail.com>wrote:

> The detach output use alt+click not ctrl+click. Just try with ctrl+click
> but it just cut the node noodle.
>
>
> On Tue, Nov 19, 2013 at 4:11 PM, Lukas Tönne <lukas.toenne at gmail.com>wrote:
>
>> Problem with swapping links is that the information currently available
>> in nodes is not sufficient to make good guesses about which sockets can
>> swap links among each other. We'd need some sort of tags on sockets to
>> indicate to the operator which of these sockets are interchangeable
>> (similar issue with muting, see http://developer.blender.org/T37334).
>>
>> The "detach output" feature exists already! Use ctrl+click on output
>> socket to disconnect all links and put them somewhere else, just like
>> disconnecting input links works by default. Also works with multiple links,
>> quite handy imo.
>>
>>
>> On Tue, Nov 19, 2013 at 9:38 AM, Bartek Skorupa (priv) <
>> bartekskorupa at bartekskorupa.com> wrote:
>>
>>> At first when I noticed that swapping disappeared I thought it's a bug.
>>> There are situations when it was confusing, because you had to remember
>>> to unlink one input, but on the other hand swapping inputs of Mix / Alpha
>>> Over / Math nodes is (was) pretty handy.
>>> I'd go a bit further with what you propose:
>>>
>>> 1.) To swap 2 nodes, hold down a modifier key
>>>
>>> Why not:
>>> "To swap - just drag the link. NOT to swap - hold down modifier's key"
>>>
>>> I'd also like to mention one feature that I'm often missing: Ability to
>>> detach link from output to move it to another output. This one may be
>>> tricky though because we can have several links going out from single
>>> output.
>>> But we could have something like this:
>>> Now Ctrl LMB drag cuts the link, Shift LMB drag adds reroute.
>>> We could have Ctrl-Shift LMB to detach input with possibility to
>>> reconnect (it would "glue" to the cursor, exactly the way as when you add
>>> new link by dragging from one socket to another)
>>> You could click on the output socket itself and when only one link is
>>> attached to it it would get detached, but when more links go out of it
>>> you'd have to move the cursor over the link itself.
>>> Ctrl-Shift-LMB should switch us to "modal", such that you can "escape"
>>> or RMB to resign.
>>>
>>> Cheers
>>>
>>>  Bartek Skorupa
>>>
>>> www.bartekskorupa.com
>>>
>>> On 19 lis 2013, at 08:25, Sebastian König <sebastiankoenig at posteo.de>
>>> wrote:
>>>
>>> Hi!
>>>
>>> As mentioned in the post below, the behavior of node sockets has been
>>> changed recently, so that autoconnect is disabled entirely.
>>> This is nice for the most part, but in some cases it has in fact been
>>> very handy, especially if you just wanted to swap the 2 inputs for mix or
>>> math nodes.
>>> So I propose to bring node-swapping back, but with a modification. There
>>> could be 2 ways of doing it:
>>>
>>> 1.) To swap 2 nodes, hold down a modifier key after disconnecting the
>>> first socket and before reconnecting it to the second socket. For example
>>> Alt or Shift. (Shift would be nice because it makes some sense in the
>>> literal way, but probably Alt comes to mind faster).
>>>
>>> 2.) There could be an operator with hotkey to just swap 2 socket inputs.
>>> Advantage: Searchable via Spacebar, can be found in the menu, faster to do.
>>>
>>> Or how about just doing both?
>>> Personally I need to swap inputs very often for math/mix, so having a
>>> hotkey would be nice.
>>>
>>> What do you think?
>>>
>>> Cheers,
>>>
>>> Seb
>>>
>>>
>>> On 19. November 2013 at 05:46:31, LswaN (subscription57 at live.com<//subscription57 at live.com>)
>>> wrote:
>>>
>>> I'd like to add my 2 cents here. Regarding the thumbnails, I think
>>> hidden by default is a bit better than removing them altogether. I agree
>>> with David that thumbs can be helpful when you just need a quick
>>> at-a-glance view of what is going on in a set of nodes.
>>>
>>> Also, Blender did auto-link new nodes to your selected node at one time,
>>> but iirc the feature was removed because people often found its choices for
>>> linking  confusing/unpredictable. For example, if you added a mix node, you
>>> might end up with the auto-link connected to the wrong input of the mix
>>> node.
>>> Personally, I liked the feature (even though it wasn't perfect), so I
>>> wouldn't mind seeing it make a comeback.
>>>
>>> On 11/18/2013 8:57 PM, Aditia A. Pratama wrote:
>>>
>>> I agree with sean. Thumbs take to much space for me...but yeah for only
>>> for non-footage nodes. I also propose to hide node by default option in
>>> user pref, so when calling node it will in hidden mode which is very easy
>>> to navigate and attach.
>>>
>>> There's also one usability request by me, but need your opinion guys.
>>> How about auto link nodes. Let say I've selected image node and then I
>>> called blur node, it will auto linked by last selected node, so instead
>>> drag your node around it will be more faster that way IMO.
>>>
>>> For viewer node, i think it's better to have canvas like vse.
>>> On Nov 19, 2013 5:37 AM, "David McSween" <3pointedit at gmail.com> wrote:
>>>
>>>> Yes I agree that thumbs can become clutter and are often inaccurate but
>>>> they provide handy visual ques or sign posts for your process. Perhaps
>>>> default to closed/hidden would be better. They can be replaced with viewer
>>>> nodes but you can't send multiple viewer nodes to the uv image window. It
>>>> would be really helpful to allocate unique names to viewer nodes, so that
>>>> you can call them independently on their own uv image windows. This would
>>>> allow the user to compare details of node outputs.
>>>> On 19 Nov 2013 07:30, "Sean Kennedy" <mack_dadd2 at hotmail.com> wrote:
>>>>
>>>>>  I'm all for removing thumbnails, at least on non-footage nodes. It
>>>>> could be useful on image nodes, movie clips, etc, because if you have a lot
>>>>> of footage being used, it could help keep it visually organized. But even
>>>>> on those, making it default to not show the thumbnail is ideal.
>>>>>
>>>>> sean
>>>>>
>>>>>  ------------------------------
>>>>> Date: Mon, 18 Nov 2013 22:20:08 +0100
>>>>> From: m.dewanchand at atmind.nl
>>>>> To: bf-compositor at blender.org
>>>>> Subject: Re: [Bf-compositor] Wiki Page
>>>>>
>>>>> Hi Sebastian,
>>>>>
>>>>> Nice! Just missing some priorities....
>>>>> Regarding status updates; when starting a project the developer can
>>>>> create a page for it, containing details about the project / solution /
>>>>> progress, and link it to the main page.
>>>>>
>>>>> So should we start removing thumbnail previews? If yes, do you also
>>>>> want to remove the preview from the input- and output nodes?
>>>>>
>>>>> Rgds,
>>>>> J & M
>>>>>
>>>>> Sebastian König schreef op 11/8/13 1:25 PM:
>>>>>
>>>>>  Hey all!
>>>>>
>>>>>  I have started to fill in the wiki page.
>>>>>  http://wiki.blender.org/index.php/Dev:Ref/Proposals/Compositor
>>>>>  I'm not super experienced with Wiki editing, so feel free to edit and
>>>>> elaborate.
>>>>>  I am also open to suggestions how to improve the
>>>>> order/appearance/structure.
>>>>>
>>>>>  Probably there should also be some kind of indication what’s being
>>>>> worked on, what’s the status etc.
>>>>>
>>>>>  More to come.
>>>>>
>>>>>  Cheers!
>>>>>
>>>>>  Sebastian
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Bf-compositor mailing listBf-compositor at blender.orghttp://lists.blender.org/mailman/listinfo/bf-compositor
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________ Bf-compositor mailing
>>>>> list Bf-compositor at blender.org
>>>>> http://lists.blender.org/mailman/listinfo/bf-compositor
>>>>>
>>>>> _______________________________________________
>>>>> Bf-compositor mailing list
>>>>> Bf-compositor at blender.org
>>>>> http://lists.blender.org/mailman/listinfo/bf-compositor
>>>>>
>>>>>
>>>> _______________________________________________
>>>> Bf-compositor mailing list
>>>> Bf-compositor at blender.org
>>>> http://lists.blender.org/mailman/listinfo/bf-compositor
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Bf-compositor mailing listBf-compositor at blender.orghttp://lists.blender.org/mailman/listinfo/bf-compositor
>>>
>>>
>>> _______________________________________________
>>> Bf-compositor mailing list
>>> Bf-compositor at blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-compositor
>>>
>>> _______________________________________________
>>> Bf-compositor mailing list
>>> Bf-compositor at blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-compositor
>>>
>>>
>>>
>>> _______________________________________________
>>> Bf-compositor mailing list
>>> Bf-compositor at blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-compositor
>>>
>>>
>>
>> _______________________________________________
>> Bf-compositor mailing list
>> Bf-compositor at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-compositor
>>
>>
>
>
> --
>
>  <http://kampoongmonster.com>
>
> Aditia A. Pratama / Chief Technical Officer
> +62 813 4747 8111/ aditia at kampoongmonster.com
>
> Kampoong Monster Studios
> Jl. Geger Kalong Hilir No. 47 Menara RDC Telkom Lt.4 Bandung Digital
> Valley 40153
> http://kampoongmonster.com
>  <http://twitter.com/aditia_ap> <http://www.linkedin.com/in/aditiapratama>
>
> This e-mail message may contain confidential or legally privileged
> information and is intended only for the use of the intended recipient(s).
> Any unauthorized disclosure, dissemination, distribution, copying or the
> taking of any action in reliance on the information herein is prohibited.
> E-mails are not secure and cannot be guaranteed to be error free as they
> can be intercepted, amended, or contain viruses. Anyone who communicates
> with us by e-mail is deemed to have accepted these risks. Company Name is
> not responsible for errors or omissions in this message and denies any
> responsibility for any damage arising from the use of e-mail. Any opinion
> and other statement contained in this message and any attachment are solely
> those of the author and do not necessarily represent those of the company.
>
> _______________________________________________
> Bf-compositor mailing list
> Bf-compositor at blender.org
> http://lists.blender.org/mailman/listinfo/bf-compositor
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-compositor/attachments/20131119/166b1340/attachment-0001.htm 