Documentation for 2.8 (WIP) #55018

Closed
opened 2018-05-09 20:06:17 +02:00 by Aaron Carlisle · 39 comments
Member

Hi, welcome to the blender 2.8 documentation development task. This task and all subsequent subtasks are related to working on documentation for the next official Blender release (Blender 2.8).

This is not a complete list of everything that needs to be done, but it should give a good starting point for reminders of things that need to get done.

Each task should give some sort of link to find more information on the feature that needs to be documented. Most often this is a link to the actual code commit, but can also be design task, or some other documentation that the developer wrote themselves. As an author, you can use this to gather information of the feature. If you don't understand a feature you can talk to a developer who helped implement the feature or perform and internet search to learn about the feature from others who have already published information on the task.

How to Contribute

We want as many people to contribute to the documentation as possible. We understand that not everyone might have the technical knowledge to understand exactly and to use subversion, sphinx, and the markup language (restructed text) however, we will accept any help given to us.

Before you start contributing it may be helpful to read the style guides which give instructions on how to write with RST and some goals of the manual.

Now that you are familiar with the process, you can get setup, edit, and contribute your changes by following these links:

Patch or Commit

If you do help us, the above method is preferred, however, you can write documentation in other formats and someone else can copy it over to our system. While it is a bit harder for us, you can share documentation written in a shareable document format, or simply include the written documentation as a reply to the task you would like to work on.

Hi, welcome to the blender 2.8 documentation development task. This task and all subsequent subtasks are related to working on documentation for the next official Blender release (Blender 2.8). This is not a complete list of everything that needs to be done, but it should give a good starting point for reminders of things that need to get done. Each task should give some sort of link to find more information on the feature that needs to be documented. Most often this is a link to the actual code commit, but can also be design task, or some other documentation that the developer wrote themselves. As an author, you can use this to gather information of the feature. If you don't understand a feature you can talk to a developer who helped implement the feature or perform and internet search to learn about the feature from others who have already published information on the task. # How to Contribute We want as many people to contribute to the documentation as possible. We understand that not everyone might have the technical knowledge to understand exactly and to use subversion, sphinx, and the markup language (restructed text) however, we will accept any help given to us. Before you start contributing it may be helpful to read the style guides which give instructions on how to write with RST and some goals of the manual. - [Markup Style Guide ](https://docs.blender.org/manual/en/dev/about/contribute/guides/markup_guide.html) - [Writing Style Guide ](https://docs.blender.org/manual/en/dev/about/contribute/guides/writing_guide.html) Now that you are familiar with the process, you can get setup, edit, and contribute your changes by following these links: - [Install ](https://docs.blender.org/manual/en/dev/about/contribute/install/index.html) - [Build ](https://docs.blender.org/manual/en/dev/about/contribute/build/index.html) - [Edit ](https://docs.blender.org/manual/en/dev/about/contribute/editing.html) - [Build again ](https://docs.blender.org/manual/en/dev/about/contribute/build/index.html) # [Patch or Commit ](https://docs.blender.org/manual/en/dev/about/contribute/patch_commit.html) If you do help us, the above method is preferred, however, you can write documentation in other formats and someone else can copy it over to our system. While it is a bit harder for us, you can share documentation written in a shareable document format, or simply include the written documentation as a reply to the task you would like to work on.
Author
Member

Added subscriber: @Blendify

Added subscriber: @Blendify
Member

Added subscriber: @Tobias

Added subscriber: @Tobias
Member

some additions from my list (not confirmed, outdated):

  • Proxy/override system
  • Asset manager
  • Outliner refactor
  • Gsoc projects: Custom normal edit, new UV tools?
  • Fluid/smoke - Mantaflow?

Related Wiki dev page are [overview]], [ https:*wiki.blender.org/index.php/Dev:2.8/Source/Migration | migration .

Does some names have changed or are they different things:
Toolbar or Topbar, Workbench or Workspace?

I think we should quantify how much time it will take for each:
Pages affected or x of n (1/5) or low-high...

Maybe a 'Modified' headline for e.g. Grease Pencil,
and subtasks for the big ones.

some additions from my list (not confirmed, outdated): - Proxy/override system - Asset manager - Outliner refactor - Gsoc projects: Custom normal edit, new UV tools? - Fluid/smoke - Mantaflow? Related Wiki dev page are [overview]], [[ https:*wiki.blender.org/index.php/Dev:2.8/Source/Migration | migration ](https:*wiki.blender.org/index.php/Dev:2.8/). Does some names have changed or are they different things: Toolbar or Topbar, Workbench or Workspace? I think we should quantify how much time it will take for each: Pages affected or x of n (1/5) or low-high... Maybe a 'Modified' headline for e.g. Grease Pencil, and subtasks for the big ones.
Author
Member

Does some names have changed or are they different things:
Toolbar or Topbar, Workbench or Workspace?

They are different, the Toolbar is part of the Topbar. Workbench is a render engine (like Eevee but designed for modeling) A workspace is kinda like a renamed form of Screen but has overides for example.

> Does some names have changed or are they different things: > Toolbar or Topbar, Workbench or Workspace? They are different, the Toolbar is part of the Topbar. Workbench is a render engine (like Eevee but designed for modeling) A workspace is kinda like a renamed form of Screen but has overides for example.
Author
Member

This comment was removed by @Blendify

*This comment was removed by @Blendify*

Added subscriber: @bdp

Added subscriber: @bdp
  • Fracture Modifier
    new 3d cursor
+ Fracture Modifier new 3d cursor
new npr node https://developer.blender.org/D3205

cycles :random walk subsurface scattering https://developer.blender.org/D3054

cycles :random walk subsurface scattering https://developer.blender.org/D3054
Member

Added subscriber: @blend-it

Added subscriber: @blend-it
cycles: bevel shader https://developer.blender.org/D2803

3D view : Support mixed snap https://developer.blender.org/D3400

3D view : Support mixed snap https://developer.blender.org/D3400

Added subscriber: @mendio

Added subscriber: @mendio

Grease Pencil 2.0 (is there a better place we can put this?) (Split annotation tool from 3d drawing?)

@Blendify The new Grease pencil is not just an UI tweak, it'll be splited: Grease pencil will be a brand new Blender object to draw in the 3Dviewport, and for all other editors will be an annotation tool (don't know yet the final name) with trimed features just to make quick notes.

So I suggest to put Grease Pencil as object in "Additions" and Annotation tool in "Moves/Changes"

> Grease Pencil 2.0 (is there a better place we can put this?) (Split annotation tool from 3d drawing?) @Blendify The new Grease pencil is not just an UI tweak, it'll be splited: Grease pencil will be a brand new Blender object to draw in the 3Dviewport, and for all other editors will be an annotation tool (don't know yet the final name) with trimed features just to make quick notes. So I suggest to put Grease Pencil as object in "Additions" and Annotation tool in "Moves/Changes"

Added subscriber: @0o00o0oo

Added subscriber: @0o00o0oo

Added subscriber: @Djay

Added subscriber: @Djay

Added subscriber: @ArindamMondal

Added subscriber: @ArindamMondal
Member

Added subscriber: @brita

Added subscriber: @brita
Member

List of shortcuts changed: blender/blender#55194 (may be better to check with a script when the time comes)

List of shortcuts changed: blender/blender#55194 (may be better to check with a script when the time comes)

Added subscriber: @DuarteRamos

Added subscriber: @DuarteRamos
Member

Added subscriber: @CharlieJolly

Added subscriber: @CharlieJolly
Member

Manual entry for D3786 if accepted
vector_math_multiply.diff

Manual entry for [D3786](https://archive.blender.org/developer/D3786) if accepted [vector_math_multiply.diff](https://archive.blender.org/developer/F5098300/vector_math_multiply.diff)

Added subscriber: @TuomoKeskitalo

Added subscriber: @TuomoKeskitalo

Hi,

in addition to current tasks which list the code changes, would it make sense to add to workboard clean-up tasks for each section of the current soon-to-be-outdated manual? It might be easiest first to clean up each section of current manual to correspond to 2.8, and after that go through the tasks about code changes, to make sure that all code changes are included in manual. Would that work?

Please excuse me if there already exists a plan on how the manual upgrade is going to be carried out. I haven't found info about any specifics, so I wonder how this is going to be done. I hope to be able to help on this. Thanks!

Hi, in addition to current tasks which list the code changes, would it make sense to add to workboard clean-up tasks for each section of the current soon-to-be-outdated manual? It might be easiest first to clean up each section of current manual to correspond to 2.8, and after that go through the tasks about code changes, to make sure that all code changes are included in manual. Would that work? Please excuse me if there already exists a plan on how the manual upgrade is going to be carried out. I haven't found info about any specifics, so I wonder how this is going to be done. I hope to be able to help on this. Thanks!

Added subscriber: @brecht

Added subscriber: @brecht

Hi again,

I had some time this weekend to test upgrade a tiny fraction of current manual. I upgraded a few first parts in the User Interface chapter, which I list in the front page. I uploaded the result temporarily to http://tkeskita.kapsi.fi/temp/blender_docs/html/index.html for viewing. Any comments, @Blendify, @brita, @brecht? Should I continue this work? I might have few days next week to spare. Thanks!

Hi again, I had some time this weekend to test upgrade a tiny fraction of current manual. I upgraded a few first parts in the User Interface chapter, which I list in the front page. I uploaded the result temporarily to http://tkeskita.kapsi.fi/temp/blender_docs/html/index.html for viewing. Any comments, @Blendify, @brita, @brecht? Should I continue this work? I might have few days next week to spare. Thanks!

@TuomoKeskitalo, help with the manual is definite welcome. I suggest you submit the changes you made so they can be reviewed:
https://docs.blender.org/manual/en/latest/about/contribute/patch_commit.html

@TuomoKeskitalo, help with the manual is definite welcome. I suggest you submit the changes you made so they can be reviewed: https://docs.blender.org/manual/en/latest/about/contribute/patch_commit.html
Author
Member

Yes please follow this advice and try to keep changes broken up and use the child tasks to post links to there patches.

Yes please follow this advice and try to keep changes broken up and use the child tasks to post links to there patches.

OK thanks, I'll try. I'll be adding links to differentials to subtasks.

It seems diffs are done always against current svn head revision. Is it OK for me to submit several patches against same svn head revision? So I don't need to wait for approval of one patch before submitting another patch?

OK thanks, I'll try. I'll be adding links to differentials to subtasks. It seems diffs are done always against current svn head revision. Is it OK for me to submit several patches against same svn head revision? So I don't need to wait for approval of one patch before submitting another patch?
Author
Member

Yes, you can submit other patches.

Yes, you can submit other patches.

Submitted patch D3956: 2.80 upgrade, WIP warning to front page

Submitted patch [D3956](https://archive.blender.org/developer/D3956): 2.80 upgrade, WIP warning to front page

@brecht : Why did you decrease task priority? It was nice to have this task listed at the top of workboard when using sort by priority.. but of course I can make do with this if needed, its not big issue, just convenience.

@brecht : Why did you decrease task priority? It was nice to have this task listed at the top of workboard when using sort by priority.. but of course I can make do with this if needed, its not big issue, just convenience.

This task is also in the Code Quest workboard, where it didn't make sense as the highest priority task. I've reordered it to be at the top of the Documentation workboard now.

This task is also in the Code Quest workboard, where it didn't make sense as the highest priority task. I've reordered it to be at the top of the Documentation workboard now.

Marking as high priority since this is a task we need to finish for 2.80.

Marking as high priority since this is a task we need to finish for 2.80.
Member

Added subscriber: @howardt

Added subscriber: @howardt
Member

One things that changes everywhere in the manual are the parts where it lists where various buttons and other UI live. E.g., most things that were on the tool shelf are listed as being on Panel Tool Shelf > Tools.

I'm a little unclear on what the official terminology for the new areas of the UI are now. Are there examples of pages that have been converted already to use the new UI interface element names?

In any case, it seems a massive effort to change all of these things in the manual. Has anyone considered a scripting-based approach that would "mostly work" to apply first?

One things that changes everywhere in the manual are the parts where it lists where various buttons and other UI live. E.g., most things that were on the tool shelf are listed as being on Panel Tool Shelf > Tools. I'm a little unclear on what the official terminology for the new areas of the UI are now. Are there examples of pages that have been converted already to use the new UI interface element names? In any case, it seems a massive effort to change all of these things in the manual. Has anyone considered a scripting-based approach that would "mostly work" to apply first?

Added subscriber: @ideasman42

Added subscriber: @ideasman42

We will definitely need to do some global search & replace. At the homestretch workshop we decided that all Blender Foundation developers would spend the first week of June on docs. @ideasman42 was assigned to look into getting things organized a bit before that, so tasks can be distributed more easily.

There are no example pages that have been converted and verified by developers to use the correct terminology, yet. The names used in the Blender interface should be ok for the manual:

  • Toolbar (big icons for active tools on the left of 3D viewport)
  • Sidebar (panels on the right of 3D viewport)
  • Tool Settings (tab in the properties editor and bar in the 3D viewport)

In most cases I think the location in the toolshelf should be replaced by the location in the header menus. Context menus often have the same operator, but I'd avoid that since they depend on selection modes and what is selected, so not as reliable to find the specific operator.

We will definitely need to do some global search & replace. At the homestretch workshop we decided that all Blender Foundation developers would spend the first week of June on docs. @ideasman42 was assigned to look into getting things organized a bit before that, so tasks can be distributed more easily. There are no example pages that have been converted and verified by developers to use the correct terminology, yet. The names used in the Blender interface should be ok for the manual: * Toolbar (big icons for active tools on the left of 3D viewport) * Sidebar (panels on the right of 3D viewport) * Tool Settings (tab in the properties editor and bar in the 3D viewport) In most cases I think the location in the toolshelf should be replaced by the location in the header menus. Context menus often have the same operator, but I'd avoid that since they depend on selection modes and what is selected, so not as reliable to find the specific operator.
Author
Member

Changed status from 'Open' to: 'Resolved'

Changed status from 'Open' to: 'Resolved'
Aaron Carlisle self-assigned this 2019-07-22 02:38:52 +02:00
Sign in to join this conversation.
No Milestone
No project
No Assignees
14 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender-manual#55018
No description provided.