[Bf-committers] Proposal for "View Docs" on Right Click
ideasman42 at gmail.com
Thu Oct 27 02:48:31 CEST 2011
On Wed, Oct 26, 2011 at 3:35 PM, Harley Acheson
<harley.acheson at gmail.com> wrote:
>> we don't want one doc for "bpy.ops.texture.slot_move", better glob
>> "bpy.ops.texture.slot_*", or "bpy.ops.texture.*" and then link to a
>> page explaining about blender texture system.
> I'd say we do. And I'd say that trying to figure out whether to use
> "bpy.ops.texture.slot_*", or "bpy.ops.texture.*" shows just how
> arbitrary it can be to try to group these things. So don't try.
> Sure, that one page would just be about slot_move, but then some
> industrious soul would add links to a page on texture slots AND
> another link to a page on texturing in general. In the text of this
> page someone could add a hyperlink to a page about slot_copy.
> And anywhere that mentions moving texture slots could be hyper-linked
> to this page. This type of thing can only be done well when the atoms
> of information are small and predictable.
> Imagine writing in the wiki and wondering whether you can make something
> a hyperlink. Making the pages this specific means that you can easily
> guess what you can link to and also guess the target address, so you can
> do so without pausing to look anything up. If you have to stop and check
> to see whether a target document exists you might not even make the link.
> If you instead make larger pages that contain multiple items then you can
> get stuck when trying to maintain it. Say the page gets too long and
> complicated because people are adding too much useful information. If you
> were to break the page up into smaller logical parts you would then have
> to FIX most of the links that go to the page from elsewhere.
> So I guess my biggest point is that you can have lots of internal links in
> the wiki, like wikipedia, if the target pages are very specific and
> But you will get very few internal links if the pages are based instead on
> unpredictable arbitrary groupings.
*Lots of things are arbitrary*, we can just link in to what makes most
sense at the time, if it happens that 1 operator links to 3 docs - we
add a submenu, if that submenu gathers 10 items - we remove some or
have a wiki page which references others, if wiki pages like this are
hard to maintain we write a HTML into the temp dir and use that --- if
the whole system sucks: we kick it out or go back to square 1.
Otherwise you raise some valid concerns but I think you also jump to
conclusions about what people will do, overlooking that this can be
maintained in a way which doesn't interfere with the wiki
You're comments about wiki internal linking would be best replied to
be wiki authors.
Its all speculation too until we try it. since this is easy to test in
my spare time, I think this can work.
- Add in sample mapping data and menu item into svn (py script
containing mapping data and operator that uses it) - I can do this +
get 1 panel working.
- a group of us try get ONE category of buttons working, say all
render buttons / settings.
- If this works usefully we try get it ready for release (add in mesh,
scene, world mapping too), otherwise kick it out.
Interested in who's able to help 'ID --> wiki' mapping once the basics
are in place.
More information about the Bf-committers