Subject: KampalaMeetingLog2015x09x17.txt
Date: September 17, 2015 5:06:38 PM PDT
[3:01pm] HideyoImazu joined the chat room.
[3:02pm] PeterThoeny: good morning HideyoImazu-san!
[3:02pm] HideyoImazu: Hi Peter
[3:02pm] HideyoImazu: still in Tokyo
[3:02pm] PeterThoeny: ah, yes, nyc plans
[3:03pm] PeterThoeny: temporary change is always good
[3:03pm] HideyoImazu: waiting to get the final go ahead from my company
[3:04pm] PeterThoeny: knock on wood
[3:04pm] PeterThoeny: nothing new on my side, still looking
[3:05pm] PeterThoeny: and networking
[3:05pm] HideyoImazu: it's rainy in Tokyo for the past few weeks
[3:06pm] PeterThoeny: send some over to us please!
[3:06pm] HideyoImazu: I wish I could
[3:06pm] PeterThoeny: on monday we had 5 min of light rain, actually just drops
[3:07pm] HideyoImazu: it was too much for some areas. Two dikes failed and dozens of fatality
[3:07pm] PeterThoeny: california currently has 27 active wildfires going on:
https://www.google.com/maps/d/viewer?mid=zp8nK_5H0MFQ.kzTmU5XK-qJQ
[3:08pm] HideyoImazu: o-oh
[3:09pm] PeterThoeny: it is pretty bad
[3:09pm] HideyoImazu: i'm still working on a new skin based on Bootstrap
[3:09pm] HideyoImazu: as I imagined, it's taking time
[3:09pm] HideyoImazu: hopefully I finish it in a few days
[3:10pm] PeterThoeny: nice!
[3:10pm] HideyoImazu: again hopefully, I will remove the company specific stuff and make it available at twiki.org
[3:11pm] PeterThoeny: that's awsome!
[3:11pm] PeterThoeny: as for content, %TWOCOLUMNS% … %ENDCOLUMNS% comes in handy for responsive layout
[3:12pm] PeterThoeny: same with %THREECOLUMNS% and %FOURCOLUMNS%
[3:12pm] HideyoImazu: do some skin support %TWOCOLUMNS% etc?
[3:12pm] PeterThoeny: we should address autoresizing of embedded images too
[3:13pm] PeterThoeny: no, these vars are intended for content creators, not for skin
[3:13pm] HideyoImazu: ok
[3:13pm] PeterThoeny: you can do multi-column layout, which reverst to singe column on a small device
[3:14pm] PeterThoeny: "reverts to"
[3:14pm] HideyoImazu: the skin I'm working on has that feature
[3:14pm] HideyoImazu: currently using ...
...
[3:16pm] PeterThoeny: well, with that solution you have to decide what goes in what column
[3:16pm] PeterThoeny: with %TWOCOLUMNS% … %ENDCOLUMNS% it balances content out automaticallym even across printed
pages
[3:16pm] HideyoImazu: ok
[3:17pm] HideyoImazu: is that practically doable?
[3:17pm] PeterThoeny: yes
[3:17pm] PeterThoeny: but requires relatively recent browsers
[3:17pm] PeterThoeny: it degrades gracefully to single column on older browsers
[3:18pm] PeterThoeny: let's start
[3:18pm] HideyoImazu: sure
[3:18pm] PeterThoeny: http://twiki.org/cgi-bin/view/Codev/KampalaReleaseMeeting2015x09x17
[3:19pm] PeterThoeny: agenda:
[3:19pm] PeterThoeny: 1. Feature Requests for Kampala Release
[3:19pm] PeterThoeny: 2. Extensions
[3:19pm] PeterThoeny: 3. Review Urgent and Not So Urgent Bugs
[3:19pm] PeterThoeny: 4. Miscellaneous
[3:19pm] PeterThoeny: ---++ 1. Feature Requests for Kampala Release
[3:19pm] PeterThoeny: http://twiki.org/cgi-bin/view/Codev/WebChanges
[3:19pm] PeterThoeny: http://twiki.org/cgi-bin/view/Codev/StopSpecifyingStyleOfTocInSystemWeb - by HideyoImazu-san
[3:20pm] HideyoImazu: any question or concern?
[3:20pm] PeterThoeny: not really, looks good
[3:20pm] PeterThoeny: just one thing, are two classes needed?
[3:21pm] HideyoImazu: as you can imagine, it occurred to me while i'm working on the bootstrap based skin
[3:21pm] PeterThoeny: brainstorm: what if the twikiTocFloat has the style of twikiToc?
[3:21pm] PeterThoeny: that way only one or the other class needs to be specified
[3:22pm] PeterThoeny: so,
[3:22pm] PeterThoeny: %TOC{title="Contents:" class="twikiToc"}%
[3:22pm] PeterThoeny: or
[3:22pm] PeterThoeny: %TOC{title="Contents:" class="twikiTocFloat"}%
[3:23pm] PeterThoeny: less typing, although two classes is fine too
[3:24pm] HideyoImazu: that approach makes twikiToc and twikiTocFloat similar
[3:24pm] PeterThoeny: yes, that's the point
[3:24pm] HideyoImazu: there will be duplication of lines
[3:25pm] PeterThoeny: duplication in css, but easier for end user
[3:25pm] PeterThoeny: i am fine with either approach, slighly prefer to user friendly approach
[3:25pm] HideyoImazu: there might be a case where twikiTocFloat is used for non TOC
[3:26pm] PeterThoeny: possibly yes
[3:26pm] PeterThoeny: your call, just my feedback
[3:26pm] PeterThoeny: shall we vote?
[3:26pm] HideyoImazu: class="twikiToc twikiTocFloat" needs more typing but very obvious
[3:27pm] PeterThoeny: ok
[3:27pm] HideyoImazu: so I prefer class="twikiToc twikiTocFloat"
[3:27pm] PeterThoeny: sounds good
[3:27pm] PeterThoeny: +1
[3:27pm] HideyoImazu: +1
[3:28pm] PeterThoeny: accepted by today's release meeting
[3:28pm] PeterThoeny: http://twiki.org/cgi-bin/view/Codev/TopicTitleHandler - by HideyoImazu-san
[3:28pm] PeterThoeny: this looks good
[3:29pm] PeterThoeny: performance impact should be minimal if plugin does not use this
[3:29pm] HideyoImazu: right
[3:29pm] HideyoImazu: this is for StructNavPlugin I mentioned a couple of times in the past
[3:30pm] HideyoImazu: it has %STRUCTNAV_TOPICTITLE%, which I believe to be introduced before %TOPICTITLE% in TWiki
core
[3:30pm] PeterThoeny: oic
[3:30pm] HideyoImazu: now that we have %TOPICTITLE%, I'd like to phase out %STRUCTNAV_TPOICTITLE%
[3:31pm] PeterThoeny: as for api, possibly easier to return the title?
[3:31pm] PeterThoeny: if undef or empty string, title is assumed to be not defined by plugin
[3:32pm] HideyoImazu: that's my plan
[3:32pm] HideyoImazu: no
[3:32pm] HideyoImazu: there is a possibility of the title "0"
[3:32pm] PeterThoeny: i refer to function return value not title ref parameter
[3:33pm] HideyoImazu: Plugins::dispatch()
[3:33pm] PeterThoeny: ok, in this case test can be undef or not
[3:33pm] HideyoImazu: sees if a plugin returns true or not
[3:35pm] PeterThoeny: oic, that would fail with a "0" title
[3:35pm] HideyoImazu: I'm afraid there are plugins returning undef, "0", or "" meaning failure
[3:35pm] PeterThoeny: yes, better not to touch this code
[3:36pm] PeterThoeny: ok, so title ref parameter is safer
[3:36pm] HideyoImazu: right
[3:36pm] HideyoImazu: I'll put this discussion in the Codev topic
[3:36pm] PeterThoeny: ok
[3:36pm] PeterThoeny: committed 2015-09-11, almost 7 days
[3:36pm] HideyoImazu: I thought about it but didn't write there
[3:37pm] PeterThoeny: +1 from me
[3:37pm] HideyoImazu: +1
[3:38pm] HideyoImazu: let me tell my further plan
[3:38pm] PeterThoeny: accepted by release meeting
[3:39pm] HideyoImazu: the biggest reason why I haven't contributed StructNavPlugin is the pattern skin and topmenu
skin don't support it
[3:39pm] HideyoImazu: unless StructNavPlugin feature can be used with a skin available at twiki.org, there is little
use of it
[3:40pm] HideyoImazu: but finally, I got an opportunity to contribute a skin of my writing
[3:40pm] HideyoImazu: which can have StructNavPlugin support
[3:41pm] PeterThoeny: ah
[3:41pm] HideyoImazu: that led me to propose topicTitleHandler()
[3:41pm] PeterThoeny: got it
[3:41pm] HideyoImazu: it's a long story
[3:41pm] HideyoImazu: I wrote StructNavPlugin 8 years ago
[3:42pm] PeterThoeny: ok
[3:42pm] PeterThoeny: anything else on features?
[3:43pm] HideyoImazu: one related thing
[3:43pm] HideyoImazu: StructNavPlugin defines a web's structure with a topic having ---++, ---+++, and bullet point
items
[3:44pm] HideyoImazu: it has %STRUCTNAV_BREACRUMBS% returning breadcrumbs based on where in the navigation map the
current topic resides
[3:45pm] HideyoImazu: Let's say:
[3:45pm] HideyoImazu: ---++ Support
[3:45pm] HideyoImazu: * [[FirstResponse] [First response]
[3:45pm] HideyoImazu: * [[EscalationProcedure] [Escalation]
[3:46pm] HideyoImazu: are in the navigation map topic
[3:46pm] HideyoImazu: this is translated into the "Support" tab on the page header, which is a dropdown menu having
"First response" and "Escalation"
[3:47pm] HideyoImazu: on the FirstResponse page, %STRUCTNAV_BREACRUMBS% is expanded to "Support > First response"
[3:47pm] HideyoImazu: does it make sense so far?
[3:47pm] PeterThoeny: ah, so navigation map topics define the tabs on top with puldowns
[3:48pm] HideyoImazu: right
[3:48pm] PeterThoeny: got it
[3:48pm] PeterThoeny: what defines the set of nav map topics?
[3:49pm] HideyoImazu: STRUCTNAV_MAPTOPIC pref variables specifies the topic defining navigation
[3:49pm] HideyoImazu: variable
[3:49pm] PeterThoeny: comma list of topics?
[3:49pm] HideyoImazu: no
[3:49pm] PeterThoeny: or does the nav map topic define all tabs/pulldowns?
[3:49pm] HideyoImazu: basically one topic has an entire navigation map of a web
[3:49pm] PeterThoeny: ok
[3:50pm] HideyoImazu: this makes web restructuring very easy
[3:50pm] PeterThoeny: ah, so used on a per web level
[3:50pm] HideyoImazu: right
[3:50pm] PeterThoeny: looks useful
[3:50pm] HideyoImazu: often, a web grows organically
[3:51pm] HideyoImazu: and sometimes you need to change the organization of topics -- reshuffling topics
[3:51pm] PeterThoeny: yes
[3:51pm] HideyoImazu: with navigation based on parent-child relationships, that's painful
[3:52pm] HideyoImazu: with a navigation map page, it's doable
[3:52pm] PeterThoeny: well, if we would have a good drag & drop restructure it would be easy with parent/child
[3:53pm] PeterThoeny: does the dropdown & breadcrumb support more than one level?
[3:53pm] HideyoImazu: StructNavPlugin can put an XML or a JSON data of the navigation map
[3:53pm] HideyoImazu: the dropdowns are only one level
[3:54pm] PeterThoeny: i find multiple nesting for breadcrumb very useful if there are many pages
[3:54pm] HideyoImazu: primarily because I don't have CSS/JavaScript to handle multilevel menu handy
[3:54pm] HideyoImazu: it's quite possible to support multilevel menu as long as there is CSS/JavaScript supporting it
[3:54pm] PeterThoeny: yes
[3:55pm] HideyoImazu: but I'm not sure if multilevel menu is really useful
[3:55pm] HideyoImazu: it's probably not usable on touch ui
[3:55pm] PeterThoeny: maybe not so much for pulldown, but it is useful for breadcrumb
[3:55pm] HideyoImazu: sure
[3:56pm] HideyoImazu: StructNavPlugin supports any levels of structure
[3:56pm] PeterThoeny: which could easily be defined with nested bullets on nav map topic
[3:56pm] HideyoImazu: I was talking only about dropdown menu
[3:56pm] HideyoImazu: that's how StructNavPlugin works
[3:56pm] PeterThoeny: ok
[3:57pm] PeterThoeny: do you have a question/comment on this?
[3:57pm] HideyoImazu: so my question here is whether there is a plugin neutral way to provide breadcrumbs
[3:58pm] HideyoImazu: %TOPICTITLE% like thing for breadcrumbs
[3:58pm] PeterThoeny: ah
[3:58pm] HideyoImazu: currently in skins available at twiki.org, %META{"parent"}% is used
[3:59pm] HideyoImazu: maybe introducing %BREADCRUMBS% ?
[4:00pm] PeterThoeny: yes, and there is a pref variable
[4:00pm] PeterThoeny: let me check
[4:01pm] PeterThoeny: ah, there is a %PARENTBC%
[4:01pm] PeterThoeny: which uses the %META
[4:01pm] PeterThoeny: but it is intened to be used in headings
[4:01pm] PeterThoeny: such as:
[4:02pm] PeterThoeny: ---+ %PARENTBC% My Cool Stuff
[4:02pm] PeterThoeny: the parent breadcrumb is shown with smaller font
[4:03pm] HideyoImazu: ah
[4:04pm] PeterThoeny: * Set PARENTBC = %SET{ "parentlist" value="%META{ "parent"
nowebhome="on" format="$topic" separator=", " }%" }%%SET{ "parent" value="%CALCULATE{$LISTITEM(-1,
%GET{parentlist}%)}%" }%%CALCULATE{$LISTJOIN($sp»$sp, $LISTMAP([[$item] [$PROPERSPACE($item)] ,
%GET{parentlist}%))}% »
[4:04pm] HideyoImazu: it's defined on TWikiPreferences
[4:05pm] PeterThoeny: so for your use case we could define a new %BREADCRUMB% variable, possibly with format=""
parameter
[4:06pm] PeterThoeny: and a new plugin handler to hijack that
[4:06pm] HideyoImazu: I suppose %BREADCRUMBS{...}% will gradually replace %META{"parent" ...}%
[4:06pm] PeterThoeny: yes
[4:07pm] PeterThoeny: actually for your usecase you do not need a new variable
[4:07pm] PeterThoeny: as long as %META{"parent" ...}% can be redefined by a new plugin handler
[4:08pm] PeterThoeny: that way %PARENTBC% would just work
[4:09pm] HideyoImazu: there are webs using the navigation feature but using the standard breadcrumbs
[4:10pm] PeterThoeny: hmm, you can't have it both ways
[4:11pm] HideyoImazu: breadcrumbsHandler() of StructNavPlugin can refer to %STRUCTNAV_BREADCRUMBS_NATIVE%
[4:11pm] PeterThoeny: either keep separate (current), or be able to redefine and use one or the other depending if
redefined
[4:12pm] HideyoImazu: if %STRUCTNAV_BREADCRUMBS_NATIVE% is true, breadcrumbsHandler() returns false
[4:12pm] HideyoImazu: hence resort to the standard breadcrubms
[4:12pm] PeterThoeny: so what do you suggest?
[4:13pm] HideyoImazu: introducing %BREADCRUMBS% built-in variable calling breadcrumbsHandler()
[4:13pm] HideyoImazu: %BREADCRUMBS% is somewhat like %TOPICTITLE%
[4:14pm] HideyoImazu: breadcrumbsHandler() returning true first takes effect
[4:14pm] HideyoImazu: if no breadcrumbsHandler() returning true, it resorts to %META{"parent" ...}% behavior
[4:14pm] PeterThoeny: yes
[4:15pm] PeterThoeny: but why not do the plugin callback in %META{"parent" ...}%?
[4:15pm] HideyoImazu: I'm writing up a proposal along those lines
[4:16pm] PeterThoeny: and define a BREADCRUMBS as a twikipref setting along PARENTBC?
[4:16pm] HideyoImazu: there might be multiple plugins having breadcrumbsHandler()
[4:17pm] HideyoImazu: it's hypothetical but there can be a situation where, on one web, PluginA's breadcrumbsHandler()
takes effect, while on another web, PluginB's breacrumbsHandler() takes effect
[4:18pm] PeterThoeny: yes, that independent if handler works on a new BREADCRUMBS twiki varable, or the existing
%META{"parent" ...}%
[4:20pm] HideyoImazu: under what situation should StructNavPlugin's breadcrumbsHandler() call %META{"parent" ...}% ?
[4:20pm] PeterThoeny: time check: +80min
[4:20pm] PeterThoeny: no, other way around
[4:20pm] HideyoImazu: ah
[4:20pm] HideyoImazu: let me retract
[4:20pm] PeterThoeny: %META{"parent" ...}% calls breadcrumbsHandler()
[4:21pm] PeterThoeny: if null, uses existing parent/child hierarchy
[4:21pm] HideyoImazu: ok
[4:22pm] PeterThoeny: and then, define new BREADCRUMBS setting in twiki prefs that returns the %META{"parent" …}%,
[4:23pm] PeterThoeny: default a comma-space list, with support for separator and format parameters
[4:23pm] HideyoImazu: I think it's natural for %BREADCRUMBS% to yield breadcrumbs
[4:24pm] PeterThoeny: if you want i can do the BREADCRUMBS stuff (not handler invoked by %META{"parent" ...}%)
[4:24pm] HideyoImazu: than %META{"parent" format="..."}%
[4:24pm] HideyoImazu: %BREADCRUMBS% calls breadcrumbsHandler() is natural
[4:25pm] HideyoImazu: but %META{"parent" ..}% calling breadcrumbsHandler() is not natural
[4:25pm] PeterThoeny: no, my point is to define %BREADCRUMBS% as a pref setting, not a new internal twiki variable
[4:25pm] HideyoImazu: I know
[4:26pm] PeterThoeny: so %BREADCRUMBS% is defined like %PARENTBC% using %META{"parent" …}%
[4:26pm] HideyoImazu: my point here is using %META{"parent" ...}% to get breadcrumbs is not natual
[4:26pm] HideyoImazu: especially if plugin handlers are involved
[4:26pm] PeterThoeny: why?
[4:27pm] PeterThoeny: ah, i see why, one is parent trail, other is nav path
[4:27pm] PeterThoeny: ok, makes sense now
[4:27pm] PeterThoeny: so in this case we need new %BREADCRUMBS% twiki variable
[4:28pm] HideyoImazu: it's more philosophical than something else
[4:29pm] HideyoImazu: it's totally doable to have %META{"parent" ...}% call breadcrumbsHandler()
[4:29pm] PeterThoeny: you convinced me
[4:30pm] HideyoImazu: ok
[4:30pm] PeterThoeny: think what is better: singular %BREADCRUMB% or plural %BREADCRUMBS%
[4:30pm] HideyoImazu: let me write this up as a proposal
[4:30pm] HideyoImazu: plural %BREADCRUMBS%
[4:31pm] HideyoImazu: since it's about "Home > Something > Something"
[4:31pm] PeterThoeny: https://en.wikipedia.org/wiki/Breadcrumb_%28navigation%29
[4:31pm] HideyoImazu: rather than a piece
[4:31pm] PeterThoeny: "Breadcrumbs" or "breadcrumb trail"
[4:31pm] PeterThoeny: so yes, plural
[4:31pm] HideyoImazu: ah
[4:31pm] PeterThoeny: we should wrap up
[4:31pm] HideyoImazu: sure
[4:32pm] PeterThoeny: i suggest to skip the other agenda items this time
[4:32pm] HideyoImazu: agreed
[4:33pm] PeterThoeny: let's close the meeting
[4:33pm] PeterThoeny: i'll post the logs and minutes as usual
[4:33pm] PeterThoeny: thanks HideyoImazu-san!
[4:33pm] PeterThoeny: ttyl
[4:33pm] HideyoImazu: ttyl. thank you for the discussion
[4:55pm] HideyoImazu left the chat room. (Ping timeout: 246 seconds)