Re: [Bf-committers] Harmonious collaboration - reverting commit process
OMG, is this causing my git “rebase master” to fail? Been trying to fix that all day yesterday… Leon Op wo 9 jun. 2021 om 18:20 schreef Howard Trickey via Bf-committers < bf-committers@blender.org> > Speaking of that error -- submodules changed by mistake -- what is the best > practice to avoid that? My GSoC mentee was asking about that, and I told > him > what I do, but it seems clunky and there is probably a better way. > > What I do: > 1) make sure I've used "make update" or something similar to ensure that > the > submodules are up to date > 2) when I "git add" files, I always add explicitly, one by one, only those > files > that "git status" shows I've changed. In other > > Is there something easier than (2)? > > On Wed, Jun 9, 2021 at 7:46 AM Jeroen Bakker via Bf-committers < > bf-committers@blender.org> wrote: > > > A common reason why I revert commits is that submodules were changed by > > mistake. Is reverting a good solution? Perhaps worth mentioning. > > > > Jeroen > > > > > > On Wed, Jun 9, 2021 at 12:55 PM Sergey Sharybin via Bf-committers < > > bf-committers@blender.org> wrote: > > > > > Hi, > > > > > > Today I continued to update the development process guidelines and > > policies > > > on the Wiki. This is based on previous discussions with the other > > > bf-admins, and I'm working with Dalai on the final text adjustments. So > > > today we handled the "polemic" topic of reverting commits: > > > https://wiki.blender.org/wiki/Process/Revert_Commit > > > > > > Feedback and suggestions are welcome. > > > > > > Please note that we do read the feedback you are giving. Currently we > are > > > focusing on finishing the first pass of the process update. We will > then > > > look into addressing your feedback to make the development process fun > > and > > > smooth! > > > > > > Best regards, > > > - Sergey - > > > > > > Sergey Sharybin - ser...@blender.org - www.blender.org > > > Principal Software Engineer, Blender > > > Buikslotermeerplein 161, 1025 ET Amsterdam, the Netherlands > > > ___ > > > Bf-committers mailing list > > > Bf-committers@blender.org > > > https://lists.blender.org/mailman/listinfo/bf-committers > > > > > ___ > > Bf-committers mailing list > > Bf-committers@blender.org > > https://lists.blender.org/mailman/listinfo/bf-committers > > > ___ > Bf-committers mailing list > Bf-committers@blender.org > https://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Suggestion: Optional sync mode for VSE Mask modifier
Just noticed the behavior for VSE mask modifier has been changed in 2.75: https://developer.blender.org/rB6786ef6783fa I mean, of course it is good and convenient in many cases, but not for all cases, to be honest. In some cases (particularly when making movie titles) we do prefer the old behavior. So IMHO it would be better to be an optional one. Thanks for your attention! -- Leon Cheung a.k.a. Zhang Yu | 老猫 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-translations-dev] About translations (i18n) contexts
Hi all, During the past years, I've reported so many bugs, thanks to all passionate devs, most of them are finally resolved. But when we talked about **i18n bugs**, it always was so awkward for some reason, for years... Last time when we mentioned "i18n project maintanance is on hold", it was really a shock to me, because definitely it was born for a very good reason at the beginning. I know devs got different standpoints on this issue. I can well understand that, just want to share my opinion here: Language diversity is something about culture, and we cannot force one to totally understand or accept another, and definitely we shouldn't, vise versa. But I believe we could at least try to respect that fact, and realize that English is NOT the one that is spoken by the largest population around the world. True, it is the most popular one, but not the only popular one I should say. And, there are countless people out there, students, designers, artists, FOSS fans, who really want to get involved with Blender (they really should :-)), but a sad thing is, to do that, they will have to learn a second language (English) first! In that case, learning curve becomes horrible. Or, they don't have to, just with the help of a **USEABLE** UI translation. Yeah, the word "useable" should really be stressed, because for them it is either useable or useless. To be truely honest, things now are getting worse, and there's nothing that all passionate translators can do to help their compatriots further, to help propagating Blender further. As one of the active translation contributors, IMHO, I believe no one touched i18n more than Bastien. So, if he says there is a valid way to fix the horrible ambiguity/polyseme issue (yeah, horrible, because now it causes the UI translation silly enough), I'll totally vote for that idea. I have one faith: If i18n project gets better, then there will be chances for more people to get involved, in their appropriate ways, peer to peer for sure. Finally, vast contributions and donations will go towards Blender Foundation! It is a typical virtuous cycle, a win-win thing benefiting everyone, isn't it? An indefinite on-hold doesn't actually help anything to anyone here. As I said, UI translation plays such an important role to Blender that it is either useable or useless. Please, make it useable. :) Blenderheads, translators and devs, two years have passed, it's time to face it, share your thoughts on this point. On Sun, Feb 15, 2015 at 7:27 PM, Bastien Montagne wrote: > Hey, > > So, almost two years ago, the 'disambiguation' process of our i18n > messages was freezed > (see > > http://lists.blender.org/pipermail/bf-translations-dev/2013-March/000424.html > for details). > > Since then, people who are translating Blender have been quite > frustrated, because you sometimes > cannot make a valid translation (polysemy, a same english word meaning > different things depending > on contexts). > > We do have a valid way to fix that, called gettext contexts. It’s not > ideal, it’s not perfect, but: > * it is simple > * it works > * it does not need to redesign our whole UI message system! > > One month ago, a TODO task (https://developer.blender.org/T43295) was > created on this subject, > with not much attention from people from UI team so far, so I’m inclined > to just resume adding > needed contexts in code. We cannot wait years for someone to redesign > from scratch our > UI messages system. > > Cheers, > Bastien > ___ > Remember to *NEVER* commit to our svn's /trunk, but *ALWAYS* to relevant > language po file under /branches! > > Found a missing msgid? Edit this doc: http://goo.gl/XcWcr > > Have some disambiguation issue (i.e. same english word that should be > translated in more than one way, depending on the context)? Edit this doc: > http://goo.gl/VzppJ > ___ > Bf-translations-dev mailing list > bf-translations-...@blender.org > http://lists.blender.org/mailman/listinfo/bf-translations-dev > -- Leon Cheung a.k.a. Zhang Yu | 老猫 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Proposal: Distance mode for Vertex/Edge Slide
Currently, Vertex/Edge Slide offers Factor control, but I found that, quite often, users may want to slide elements by a given distance. For example, if we want to slide a vertex by 2 along a edge with length of 5.5364, we can figure out the correct Factor by typing calculation like: 2/5.5364, which is 0.361246; and if we want to define 2 as the distance towards another vertex on the same edge, then we can generate by calculation 1-2/5.5364, which is 0.638754, etc. I mean this is NOT bad really, just not so effective for users who use it quite often like this (archetects for instance), since I've seen quite a bit of questions online, directly or indirectly, related to how to precisely control edge length or vertex movements along edge. In a word, benefits are: - Straightforward length control (for existing edges). - Straightforward slide control (by using distance value other than factor). I bet a small usibility improvement on this commonly-used tool will be much helpful. FYI. Thanks. -- Leon Cheung a.k.a. Zhang Yu | 老猫 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Usability Suggestion for Pie Menu
Hi, Antony, sorry if any misunderstanding. I mean, there are currently two interaction method, one of which is called "click-style interaction" (according to wiki here: According to Wiki: http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.72/UI/Pie_Menus#Interaction). What I was proposing is an option to disable it for those who barely use that. That's it. :) So that when they mis-trigger the wrong keys (or wrong pies, which is more likely to happen when more pies are defined), all they need to do is simply to release the key, then the pie will disappear in a flash without having to click one more time to close it. On Tue, Nov 25, 2014 at 7:09 AM, Antony Riakiotakis wrote: > I am not sure I understand what the request is here...Have an explicit > drag/click style option I guess? > > On 24 November 2014 at 17:44, - LEON - wrote: > > > My students who have recently shifted from Maya were experiencing a bit > > "pain" with our pie menu behaviour comparing to Maya's pie. To be exact, > if > > the mouse is not moving before shortcuts released, then they have to > either > > click on one of the items, or press ESC or RMB to quit. I mean, this > extra > > click for confirmation seems unavoidable even for quit only, especially > > when pie keys are mis-triggered. > > > > Believe me, I know it was designed by design, and for good :), which may > be > > helpful for those who got no mouse (when playing with notebook, for > > example). However, I bet that for the majority, "press-drag-release' flow > > would be their first choice and used much more often than the > > "press-release-click" flow. > > > > So, I may propose to expose it as a toggle. Because, for those who > totally > > don't need it it can be more or less an efficiency killer, which they > have > > to bear with. > > > > Thanks for your attention. > > > > -- > > Leon Cheung > > a.k.a. Zhang Yu | 老猫 > > ___ > > Bf-committers mailing list > > Bf-committers@blender.org > > http://lists.blender.org/mailman/listinfo/bf-committers > > > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > -- Leon Cheung a.k.a. Zhang Yu | 老猫 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Usability Suggestion for Pie Menu
My students who have recently shifted from Maya were experiencing a bit "pain" with our pie menu behaviour comparing to Maya's pie. To be exact, if the mouse is not moving before shortcuts released, then they have to either click on one of the items, or press ESC or RMB to quit. I mean, this extra click for confirmation seems unavoidable even for quit only, especially when pie keys are mis-triggered. Believe me, I know it was designed by design, and for good :), which may be helpful for those who got no mouse (when playing with notebook, for example). However, I bet that for the majority, "press-drag-release' flow would be their first choice and used much more often than the "press-release-click" flow. So, I may propose to expose it as a toggle. Because, for those who totally don't need it it can be more or less an efficiency killer, which they have to bear with. Thanks for your attention. -- Leon Cheung a.k.a. Zhang Yu | 老猫 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Separate CPU/GPU Tile Setting
Sure. I'll try discuss things in the most related ML. For me, Greg's addon is more than enough to handle this kind of needs. It's really great. Thanks guys. On Wed, Oct 8, 2014 at 3:14 AM, Greg Zaal wrote: > Thanks mib2berlin. > > I'd like to get the add-on into contrib actually, and from there get some > code review. > > If anyone's interested, I did a bit of elaborate testing: > http://adaptivesamples.com/2013/11/05/auto-tile-size-addon-updated-again/ > > @Leon - in future, use the bf-cycles mailing list to discuss Cycles-related > topics. > > On 7 October 2014 20:46, Wolfgang Fähnle wrote: > > > Hi, as it is a good idea somebody (Greg Zaal) wrote an addon for it. > > This should integrated and activated per default in Blender Cycles. > > Many user don´t even know how important the tile size is. > > > > > > > http://wiki.blender.org/index.php/Extensions:2.6/Py/Scripts/Render/Auto_Tile_Size > > > > Cheers, mib2berlin > > > > Am 07.10.2014, 18:37 Uhr, schrieb - LEON - : > > > > > I feel that it be more convenient to use some separate settings for CPU > > > and > > > GPU, at least the tile setting, which currently have to be changed > often > > > to > > > optimize render time when switching one device to another. Hope I'm not > > > the > > > only person who got such feeling. :) > > ___ > > Bf-committers mailing list > > Bf-committers@blender.org > > http://lists.blender.org/mailman/listinfo/bf-committers > > > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > -- Leon Cheung a.k.a. Zhang Yu | 老猫 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Separate CPU/GPU Tile Setting
I feel that it be more convenient to use some separate settings for CPU and GPU, at least the tile setting, which currently have to be changed often to optimize render time when switching one device to another. Hope I'm not the only person who got such feeling. :) -- Leon Cheung a.k.a. Zhang Yu | 老猫 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Suggestion for a Smarter Crop Node
When using Crop node, there are some cases that users may want to just remove the unwanted margin, and crop nodes can do that for sure. However, the values for Left/Right/Up/Down are not very easy to decide accurately, which means, either do it in externally, or try many times to get the nice values. So, I may have a rough idea on this: For example, this is a manual way to crop off the unwanted margin in the image: s1.png <https://docs.google.com/file/d/0B1ojv5B6Lb-3YmtfMTFfbWwtYmM/edit?usp=drive_web> Probably we could make it a bit "smarter" to decide values by guessing the first (or last?) non-zero alpha pixel towards all four directions, so that will make the workflow much more effective, something like this: s2.png <https://docs.google.com/file/d/0B1ojv5B6Lb-3R0tLcUxzeDZrSVE/edit?usp=drive_web> Below are other examples: s3.png <https://docs.google.com/file/d/0B1ojv5B6Lb-3dkNKb2tJX0NoWGs/edit?usp=drive_web> s4.png <https://docs.google.com/file/d/0B1ojv5B6Lb-3VENVWlpobDdxOE0/edit?usp=drive_web> It can also be very useful when stretching / fitting needed during composition. Just a very rough idea, and thanks for your attention. -- Leon Cheung a.k.a. Zhang Yu | 老猫 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Edge/Face groups proposal
Would you recheck the link? I don't think it's accessable. On Sun, Apr 6, 2014 at 3:34 PM, Vilem Novak wrote: > Hello, > I wrote down a little proposal for edge and face groups. > > I was surprised to not find anything about this topic in the wiki, and also > not in the GSOC ideas page. > > > > > It is now here as a google docs document, can I place it somewhere in the > wiki? > > > https://docs.google.com/document/d/11JJjrgp-KXSs7S59502K3KnTO2sGElo1RT3gGDBr > 49s/pub > ( > https://docs.google.com/document/d/11JJjrgp-KXSs7S59502K3KnTO2sGElo1RT3gGDBr49s/pub > ) > > > > > > > What are the opinions of the core coders, could this be on a todo/ideas > list > for the future? > > > > > Regards > > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > -- Leon Cheung a.k.a. Zhang Yu | 老猫 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Patch [#36028] New 4-column layout for the editor-type-selector menu...
Imho, "alphabetical" means not quite ideal for i18n UI display. In fact, the current list already got well-classified if looking closely a bit. However, if there really needs to be any goal for quick look-ups, I think a better solution would probably be trying to "stress" the role of icons, since images usually are more easier to identify than texts, everyone likes them. I mean, just imagine a software without icons :). In orther words, I mean it would be to* scale the default size of those icons a little bit* for the more eaiser and quick identification, probably. Second solution: Probably it could be considered to try *adding Shortcuts display* for them, I mean the current Shift + F1 to F12 thing. I know it's the most simple "trick" for all experts, which is well-known for sure. However, for new users? I doubt so. So, it may protencially suggestting those who want to use as many shorcuts as they can (and will) a more direct way to switch among editors. On Sun, Jul 7, 2013 at 10:45 PM, Harley Acheson wrote: > I still think this has nothing to do with the list being too large. > > The order of the items on the list changes depending on whether > it pops up or down, so we can't just remember them visually by > location. And the order is non-visual so we have to do a linear > scan instead of a binary one. We have to read almost all the > items almost all the damn time. > > If we didn't do the swap, we could have any arrangement of > items and it wouldn't matter much because they would stay > in the same place. "3D View" would always be at the top, and > the item that is 1/3 down would always be there. > > Make the order *alphabetical* and we can then do a binary > scan to find the items instead of a linear one. Combine the two > and we could make the list much longer and we could still find > items in it faster that we do now. > > Cheers, Harley > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > -- Leon Cheung a.k.a. 老猫 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender online
AFAIK, the dead Truespace got such concept of "real-time collaboration" since 7.5. It would be surely with great advantages in teamwork projects, and more obviously, for educational use and remote interactions. even greater with IRC integrated. FYI if it would help some: http://goo.gl/OgqI6 http://goo.gl/2TAOy I've played with TS collaboration server long time ago. I think limits of authority would be good idea to avoid any possible issues. I believe collaboration mode would be the future. On Sat, Apr 27, 2013 at 12:16 AM, Patrick Shirkey < pshir...@boosthardware.com> wrote: > > On Sat, April 27, 2013 1:58 am, Campbell Barton wrote: > > This could be approached from a bit of a different direction then > > whats being discussed (unless I missed something). > > > > We had Verse and I used it once, it was novel but 2 people editing the > > same mesh at once IMHO is not so useful. > > But collaborative text document editing can be really great so - > > theres something to be said for supporting this kind of use case. > > > > > > Id suggest to first add support for reloading libraries while blender > > runs, > > this is often requested feature (requested for every open-movie) and > > we even support this in the game engine, so it should be possible to > > support. > > > > What do you think is the biggest obstacle to achieving this step? > > > After this is supported it can be extended to work for individual > > datablocks, and eventually have some clever support for syncing > > datablocks over a network for eg. > > Do you see a place JACK in this stage? > > > > -- > Patrick Shirkey > Boost Hardware Ltd > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > -- Leon Cheung a.k.a. 老猫 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
