Tags:
rendering1Add my vote for this tag create new tag
view all tags

RenderListPluginDev Discussion: Page for developer collaboration, enhancement requests, patches and improved versions on RenderListPlugin contributed by the TWikiCommunity.
• Please let us know what you think of this extension.
• For support, check the existing questions, or ask a new support question in the Support web!
• Please report bugs below

Feedback on RenderListPlugin

I created this Plugin for an Engineering Portal we have at work. Navigating 35K TWiki pages can be a challenge. With this Plugin we can navigate the TWiki space by groups in the org structure of the company. Each division/group/team page has a common format. One element is a tree showing where the group is in the organization. This makes it real easy to navigate up and down the organization, regardless of the TWiki web structure.

Made-up example for Home page: (links to other groups are simulated)

  Home - Frank
  CorporateDivision - Paul
  Facilities Group - Jane
  Finance Group - Randal
  HR Group - Jane
  EngineeringDivision - Mike
  DevGroup - Tom
  TechPubs - Marian
  SalesDivision - Jeremy
  etc - etc

Made-up example for EngineeringDivision page:

  Home - Frank
  EngineeringDivision - Mike
  DevGroup - Tom
  BreadSlicerTeam - Hide
  CookieCutterTeam - Philipp
  TechPubs - Marian

Made-up example for BreadSlicerTeam page:

  Home - Frank
  EngineeringDivision - Mike
  DevGroup - Tom
  BreadSlicerTeam - Hide
  Architecture - Jerry
  Coding - Steve
  QA - Rogers

Reorgs happen. It's a simple matter of rearranging the bullets; the group pages can remain the same unless the name changes.

Possible enhancements:

  • More themes for different applications (what kind?)
  • Different rendering types
  • Turn a bullet list into a real org chart with boxes and lines, using the GD graphics library (split up long lists into several pages)
  • Dynamically expand/collaps nodes using JavaScript & DHTML
  • Allow multiple icons per node with a customizable link for each

This Plugin is related to the TreePlugin. That Plugin could be reduced to return just the topic parent/child hierarchy as a bullet list, which can be rendered by this Plugin.

-- PeterThoeny - 04 Dec 2003

Another example: You can use this Plugin to create some fancy looking text like this one:

Plugins web links
ReadmeFirst
Web Changes
detailed
WebIndex
WebSearch
AddOnPackages
dev
idea
PluginPackages
dev
idea
SkinPackages
dev
idea

-- PeterThoeny - 06 Dec 2003

This is a nice addition. However, I see some problems with using TreePlugin:

  • It always renders the top level of the tree, not only the children
  • There can only be one tree on a page, making it useless to use it in navbars AND content

-- ArthurClemens - 08 Dec 2003

Oh, that's a new use, I did not consider to use this Plugin together with the TreePlugin. It looks like the TreePlugin would need some changes to work with this Plugin, but what is the use for this combination? The TreePlugin does most what this Plugin does.

At work we have over 100 webs. After several reorgs the group pages are scattered all over the webs, the relation by org chart does not match the topic parenting since they cross web boundaries, hence the reason for this Plugin.

Actually, I would like to see one additional functionality in this Plugin or possible in a different one: Currently, part of the org structure (pointing upwards) is duplicated in each group page. It would be nice to

  • maintain just one bullet list containing the whole org structure of the company
  • reference that master bullet list in each group page with an implicit or configurable rule:
    • show current group name without a link, but bolded (indicating "you are here")
    • show parent, grand parent etc up to top level, but without their siblings
    • show one's siblings, but without their children
    • show one's children down to level n

Any idea for an intuitive syntax?

-- PeterThoeny - 09 Dec 2003

I needed above mentioned feature at work for a new Engineering Portal so I implemented it. The Plugin supports now two more parameters, focus and depth. See RenderListPlugin topic for description.

-- PeterThoeny - 11 Dec 2003

New RenderListPlugin version is posted. You can now overload the default icon shown in a bullet by supplying icon:name in the bullet. Above BreadSlicerTeam example is updated.

-- PeterThoeny - 16 Dec 2003

New Plugin version posted with FILE_THEME and folder/file icons. Also, changed spacing to the right of the icons.

-- PeterThoeny - 01 Mar 2004

Moved Martin's "Web.TopicName" question to Support.ShowWebNameInListOfTopicNames

-- PeterThoeny - 04 Mar 2004

Peter, you mention the possibility of leveraging the TreePlugin plugin, however, this plugin is not well maintained and I have identified some pretty serious performance issues when the plugin is used extensively. I took a look at the plugin and honestly I believe that if we create a plugin that can deduce the parent->child/parent->child->etc relationships given a high starting point, then RenderListPlugin can do the rest wrt the visual formatting.

I am still not a plugin meister (like Crawford smile !) but I did a little experiment with SEARCHMETA and the results returned are quite speedy. I took a look at the TreePlugin code and it is huge! I suppose I am looking for a sanity check - is this really the correct road to go down?

Thanks

-- SteveRJones - 09 Apr 2004

I think it is better to create a lightweight Plugin that generates a map of all topics in a web based on the parent/child relationship, shown as a simple bulletlist. That bulletlist can be rendered nicely by the RenderListPlugin. Crawford created a not yet released ManageContentPlugin that could be extended with that feature.

The Plugin could create an index of all topics in a web, shown as a bulletlist, all rooted at WebHome.

Example with notes, showing just a few topics for illustration:

-- PeterThoeny - 10 Apr 2004

Exactly my thoughts. I have noticed others wanting META tags that would be maintained with up-to-date info of a topics children, but I imagine that this would entail quite a fundamental change in Twiki and really kick up the debate about having META data maintained within a real database smile

Anyway, any idea on Crawford's release of this new plugin or should this lightweight plugin be developed by someone else?

Thanks

-- SteveRJones - 12 Apr 2004

Hello. RenderListPlugin is great. I've been using it to plot my family tree. I've even created icons with photos of family members to make it look nicer. It would be even nicer, however, if I could plot the family tree in the standard way, so that it could branch out in both directions, both up and down with fathers shown on a branch going up and mothers on a branch going down. I think this feature would be great for org charts as well.

Would anyone with better Perl programming skills than me, be interested in trying to incorporate this feature into the RenderListPlugin, so that it would be able recognize the indent level of list items and link list items forwards and backwards? I'm new to Perl programming but I'm going to see what I can do. But, if someone who is a whiz with Perl can whip something up quickly that would be fantastic.

My thought is that this could be incorporated as a new theme called "branch". Below is an example of how a list could be rendered. I use a similar format arranged differently using the "thread" theme, but with a new "branch" theme with lines going up and down from to the subject's to mom and dad, then up and down the grand parents, RenderListPlugin would be great for Family Trees and org charts.

%RENDERLIST{branch}%
         * icon:grandfather1 3. GrandFather1
             Born: Date
             Married: Date
             Died: Date
      * icon:father1 2. Father1
          Born: Date
          Married: Date
          Died: Date
         * icon:grandfather1 3. GrandMother1
             Born: Date
             Married: Date
             Died: Date
   * icon:subject 1. Subject
       Born: Date
       Married: Date
       Died: Date
         * icon:grandfather2 3. GrandFather2
          Born: Date
          Married: Date
          Died: Date
      * icon:mother1 2. Mother1
          Born: Date
          Married: Date
          Died: Date
         * icon:grandmother2 3. GrandMother2
             Born: Date
             Married: Date
             Died: Date

The above call could produce the following output:

TreeExample.gif

What do you think?

-- JamesScarlett - 23 Sep 2004

That could be a transparent enhancement, e.g. all existing themes could be made to understand backward bullets. Question is performance, the current just forward looking algorithm is quite fast.

-- PeterThoeny - 26 Sep 2004

There is no good way, at present, to make checklists with HTML. Forms want to change. preformatted monospaced brackets [ ] work but look... less than wonderful. Here I see a perfect plugin but no readymade support for checkboxes.

I would like to suggest the addition of two new standard gifs to the set of available bullets:

  • a checked checkbox chk.gif
  • an unchecked checkbox unchk.gif
  • CHKBOX Theme
      * Set CHKBOX_THEME = icon, 1, 16, 16, %ATTACHURL%/empty.gif,
%ATTACHURL%/dot_udr.gif, %ATTACHURL%/dot_ud.gif, %ATTACHURL%/dot_ur.gif,
%ATTACHURL%/unchk.gif

Example:

CheckboxExample.jpg

Comment?

-- VickiBrown - 14 Jan 2005

There could be a checklist="on" parameter that will add standard checkboxes in the browser/systems native widget. You could then disable the checkboxes on view but have an edit checklist button to put the list into edit mode, the surrounding topic would still be in view much like EditTablePlugin, and have an update checklist button to save the changes and revert to viewing.

It would look something like this:

view:

Bread
Milk
Groceries
Peppers
potatoes

edit:

Bread
Milk
Groceries
Peppers
potatoes

If you didn't want to protect the checklist you could always do away with the view stage and have the checklist always editable in view by using a different option like checklist="edit"

-- SamHasler - 15 Jan 2005

Actually, this would be useful for standard numbered lists like the one I'm using in ProposedNewFormsInCodev by inserting %Y% DONE to indicate done items. It probably deserves it's own topic.

-- SamHasler - 17 Jan 2005

Please be aware that when using the focus feature, the search will match the whole line of text in a bullet, including any leading icon:Person or similar tags. It would be good to make the search sensitive to these prefixes, as the user probably did not have in mind finding the first line with an icon statement, when setting focus to con, say.

  • Excluding the icon part can certainly be done. This was not needed in my deployment since the focus is always defined as a Web.TopicName text. -- PTh

-- ThomasWeigert - 04 Mar 2005

Peter, I have built a ThreadedDiscussionPlugin on top of the infrastructure of this plugin. My goal was to reuse as much as possible, but there were some small changes required to make reuse work. In particular, I had to lift out the analysis of the list and the construction of @tree into a separate subroutine. Are you open to these changes or should I duplicate the code?

  • Wow, ThreadedDiscussionPlugin, big grin again a new Plugin! The code can be shared as long as the performance is OK. -- PTh
  • You can look at the code as attached to ThreadedDiscussionPlugin. However, for the time being, I ended up stripping down renderIconList() to a bare minimum, as I could not get the T, L, and I icons to work when allowing text to linewrap.

Further, I came up with a small enhancement to your plugin which would allow dynamic selection of the focus and depth parameters through controls. This requires no changes to your code other than an additional atribute, but could also be handled from a separate plugin which calls your plugin.

  • That is fine. Wouldn't that be possible already now by supplying the focus and depth parameters via %URLPARAM{}%? -- PTh
  • Of course, that is in essence what I am doing. I just wanted that as an available option, rather than having to manually create the controls... You can see what I mean at ThreadedDiscussionPlugin --TW

Finally, my suggestion is to move the icons from this topic to TWikiDocGraphics as there are already many of the same icons there and it would make the other icons usable for other apps.

  • I was considering to use both, e.g. look first in the Plugin topic, if not found, look in TWikiDocGraphics. The unresolved problem is performance, the Plugin needs to check if the attached file exists. -- PTh

-- ThomasWeigert - 08 Mar 2005

One more thing... your plugin essential requires one liners for each bullet otherwise the clever thread lines do not work. I have been looking into how to replace those images by table cell borders, but I am struggling with getting the sizing just right... any other ideas of allowing multiline thread lines would be greatly appreciated...

-- ThomasWeigert - 08 Mar 2005

You can define multiple lines per bullet:

   * line one
     line two of first bullet
   * second bullet

This requires a "manual wrap algorithm", which is not very user friendly. Ideally this would wrap automatically. I did not find an easy way in the short time I looked at the issue. The icon and text need to be in separate table cells; the lines need to be extended if text wraps, e.g. the vertical lines probably need to be put into the table background so that they extend by repeating (vague, complicated to explain).

-- PeterThoeny - 10 Mar 2005

In a threaded discussion, the text is more than a one-liner typically, so the "manual wrap" is a non-starter.

I have replace the icon stuff by vertical lines through table background (see how this looks at ThreadedDiscussionPlugin). However, this does not give me the "T" and "L" icons in any clean way. I have tried to use table cell borders to draw a "T" and "L", but they end up to large for the text. In the end, it was not worth the trouble and I decided to go for just vertical lines showing the indentation depth...

-- ThomasWeigert - 11 Mar 2005

checked .zip into CVS

-- WillNorris - 19 Jul 2005

Its not documented here, but what this plugin does is convert each of teh bullet-list items to a single row table. fair enough, though, as the saying goes "I wouldn't have done it that way myself".

The problem is that this makes the plugin 'fragile' in that it doens't play well with others.

Suppose, for example, I have a topic that is a very traditional 3-column layout done with a table. For example at the ever popular site http://www.boingboing.net.

Or, alternatively, I use the Pattern skin's LeftMenuBar plus LynnwoodBrown's right panel mechanism. (Actually I do, and that is where I found this problem.)

Then the <nobr> converts a bullet-list item that revious wrapped to stay in the bounding-box /container into one that doens't. The bullet list in the center column of the table now intrudes into the right hand column, or perhaps it even goes past the boundary of the display area and causes a horizontal scroll...

Is there a specific reason for the <nobr> ? Well yes. If you have the "Tee-lines" that make up a vertical line in front of the icons then letting the lines wrap breaks that.

So what happens when bullet list is generated by a search and you don't know how long the lines will be ...

Oh my, what a mess!

-- AntonAylward - 22 Jul 2005

In ThreadedDiscussionPlugin I have replaced the "T" by drawing a thread line using borders precisely for this reason. Plus, I wanted the body of each bullet be potentially more than one line without having to use continuation markers....

-- ThomasWeigert - 23 Jul 2005

This is an illustration of AntonAylward's problem:

  TestTest1 (SomeTopic1, SomeTopic2, SomeTopic3, SomeTopic4, SomeTopic5, SomeTopic6, SomeTopic7, SomeTopic8, SomeTopic9, SomeTopic10, SomeTopic11, SomeTopic12, SomeTopic13, SomeTopic14, SomeTopic15, SomeTopic16, SomeTopic17, SomeTopic18, SomeTopic1, SomeTopic19, SomeTopic20, SomeTopic21, SomeTopic22)

The code uses <nobr> to prevent that the line wraps. <nobr> is not a valid W3C tag, so the page will not validate.

But if you remove <nobr>, you will get this:

  TestTest1 (SomeTopic1, SomeTopic2, SomeTopic3, SomeTopic4, SomeTopic5, SomeTopic6, SomeTopic7, SomeTopic8, SomeTopic9, SomeTopic10, SomeTopic11, SomeTopic12, SomeTopic13, SomeTopic14, SomeTopic15, SomeTopic16, SomeTopic17, SomeTopic18, SomeTopic1, SomeTopic19, SomeTopic20, SomeTopic21, SomeTopic22)
  TestTest1 (SomeTopic1, SomeTopic2, SomeTopic3, SomeTopic4, SomeTopic5, SomeTopic6, SomeTopic7, SomeTopic8, SomeTopic9, SomeTopic10, SomeTopic11, SomeTopic12, SomeTopic13, SomeTopic14, SomeTopic15, SomeTopic16, SomeTopic17, SomeTopic18, SomeTopic1, SomeTopic19, SomeTopic20, SomeTopic21, SomeTopic22)

(the vertical line is interrupted)

This can be solved with CSS, by setting the T-shape as background image. But then it cannot be a dotted line, because you may get dots next to each other (space-dot-sot-space) instead of space-dot-space. So we use a gray line.

The image should be very high, I use 1000 px.

The style for the image td:

td.renderListHasDoc {vertical-align:top; width:16px; background:transparent url(%ATTACHURLPATH%/dot_udrl.gif) 0 0 repeat-y;}
And instead of using &nbsp; which gives an ugly indent in the left margin, give the content td a padding:
td.renderListContent {padding-left:0.5em;}

This becomes:

TestTest1 (SomeTopic1, SomeTopic2, SomeTopic3, SomeTopic4, SomeTopic5, SomeTopic6, SomeTopic7, SomeTopic8, SomeTopic9, SomeTopic10, SomeTopic11, SomeTopic12, SomeTopic13, SomeTopic14, SomeTopic15, SomeTopic16, SomeTopic17, SomeTopic18, SomeTopic1, SomeTopic19, SomeTopic20, SomeTopic21, SomeTopic22)
TestTest1 (SomeTopic1, SomeTopic2, SomeTopic3, SomeTopic4, SomeTopic5, SomeTopic6, SomeTopic7, SomeTopic8, SomeTopic9, SomeTopic10, SomeTopic11, SomeTopic12, SomeTopic13, SomeTopic14, SomeTopic15, SomeTopic16, SomeTopic17, SomeTopic18, SomeTopic1, SomeTopic19, SomeTopic20, SomeTopic21, SomeTopic22)

Now we have links that stay on the page, plus the page validates.

This way we can replace all image table cells with css image backgrounds.

-- ArthurClemens - 23 Jul 2005

Arthur, good idea with the 1000 pixel tall background image. There is one problem when using a browser that does not understand CSS. Here is a screenshot showing no indent and no lines at all:
Not css aware

This can be improved by combining table based images with css background images. Here is a simulated version:

  Home - Frank and many other team members and many other team members and many other team members and many other team members and many other team members and many other team members
  EngineeringDivision - Mike and many other team members and many other team members and many other team members and many other team members and many other team members and many other team members
  DevGroup - Tom and many other team members and many other team members and many other team members and many other team members and many other team members and many other team members
  BreadSlicerTeam - Hide and many other team members and many other team members and many other team members and many other team members and many other team members and many other team members
  CookieCutterTeam - Philipp and many other team members and many other team members and many other team members and many other team members and many other team members and many other team members
  TechPubs - Marian and many other team members and many other team members and many other team members and many other team members and many other team members and many other team members

This renders nicely in modern browsers, and validates as proper XHTML. It falls back gracefully in browsers that do not support css: The line graphs are shown, but the vertical lines are not extended.

It uses a dotted background image, 16x1000 pixel, where the top 16x16 part is empty (which gets filled by the foreground image).

The indent problem can be solved with an extra cell. That way, text indents nicely also with non css-aware browsers.

-- PeterThoeny - 24 Jul 2005

All, I know this is completely out of the discussion you are in above, but I thought I'd add a couple of icons.

I'm trying to describe a directory structure in our TWiki installation and I needed a couple of icons to represent multiple directories and files. These are just Microsoft Paint modified forms of the existing icons and not very complicated. Maybe they can be rolled up into a future release.

The bullet below is what I've added to the RenderListPlugin page on my site.

  • Use one of the custom icons: foldermulti.gif foldermulti.gif, filemulti.gif filemulti.gif

PS Feel free to edit this, or let me know if this is in the wrong place (it's my first contribution!!!)

-- SteveHobbs - 15 Aug 2005

Regarding "continuation lines".

  1. I did not know that
    a design like this was possible
    using standard TWiki formatting rules
    while having the raw code nicely aligned on multiple lines!
  2. TWiki.RenderListPlugin calls it continuation lines
QUESTION? Is this plugin responsible for enabling continuation lines or are continuation lines a basic formatting feature rendered by TWiki engine? IDEA! Just answered the question for myself: I tried a list with continuation lines using an old TWIKI version from 2000. That time plugins were unknown. The list was rendered correcty. Thus I conclude continuation lines are an old feature. This fact gives rises to the question, why TextFormattingRules carefully hides this feature from the user smile

-- DanielKabs - 23 Aug 2005

The plugin don't work in 4.x TWiki.
Apply this to work.(There aren't tab chars.The same problem was in TreeBrowserPlugin )

    # Plugins, TOC and SEARCH can be rendered
+    $_[0] =~ s/ {3}/\t/gs if $_[0] =~/%RENDERLIST/;
    $_[0] =~ s/%RENDERLIST{(.*?)}%(([\n\r]+[^\t]{1}[^\n\r]*)*?)(([\n\r]+\t[^\n\r]*)+)/&handleRenderList($1, $2, $4)/ges;

-- PavelKotrc - 14 Apr 2006

This Plugin is pre-installed. The pre-installed version works on TWiki 4 (there was a rendering bug fixed in TWikiRelease04x00x02)

The RenderListPlugin topic here is not yet updated. Before it gets updated it needs to be fixed so that it runs on Cairo and Dakar, but HandlingCairoDakarPluginDifferences needs to be done.

-- PeterThoeny - 14 Apr 2006

Pavel, thanks for pointing this out. I updated the version in SVN to be both Cairo/Dakar compatible (along the lines of your patch), see Bugs:Item1657.

I have attached a .zip of the new version to this topic (made with BuildContrib), please test it.

I must admit to have a primary focus of getting plugins rolling on 4.0.2 in the first place (at the moment anyway) - but your point is important, Peter.

-- SteffenPoulsen - 14 Apr 2006

The plugin works fine on 4.0.1 Just the perl RenderListPlugin_installer.pl returned this:

### RenderListPlugin Installer ###

This installer must be run from the root directory of your TWiki
installation.
    * The script will not do anything without asking you for
      confirmation first.
    * You can abort the script at any point and re-run it later
    * If you answer 'no' to any questions you can always re-run
      the script again later
Hit <Enter> to proceed with installation

##########################################################
Adding topic: TWiki.RenderListPlugin to installation ....
********************************
RCS: /usr/bin/rcs  -q -l %FILENAME|F% failed:  at /var/www/twiki/lib/TWiki/Store/RcsWrap.pm line 419.

********************************
********************************
RCS: /usr/bin/rcs  -q -l %FILENAME|F% failed:  at /var/www/twiki/lib/TWiki/Store/RcsWrap.pm line 419.

********************************
RCS: /usr/bin/rcs  -q -l %FILENAME|F% failed:  at /var/www/twiki/lib/TWiki/Store/RcsWrap.pm line 419.

-- PavelKotrc - 18 Apr 2006

Are you installing the plugin as the user running the webserver? (It looks like a permission problem).

I have uploaded a new version from SVN which is both Cairo and Dakar compatible.

-- SteffenPoulsen - 25 Apr 2006

I found it unclear whether this plugin will do numbering automatically? Is this a feature that might be added?

-- EricHanson - 09 Aug 2006

No, I think autonumbering is out of scope of this Plugin. See NumberedHeadings for a poor man's autonumbering feature. You might be able to leverage it to auto-number the "bullets" rendered by this Plugin.

-- PeterThoeny - 09 Aug 2006

Hi all, I needed to display icons not only attached to this plugin topic, but also from other topics. So I made a patch to the icon: handling code
- if there is a "/" char in the icon name, the plugin leaves it alone, other it behaves as before. So now you can write

  • somefile.xls

Feel free to (or not to) include this patch to your (very useful) plugin.

-- JanFilipsky - 22 Sep 2006

New Plugin version 23 Sep 2006 posted with these enhancements:

  • Support for img tag and image URL after icon: (suggested by JanFilipsky)
  • Support for TWikiDocGraphics icons, such as %ICON{folder}% instead of icon:folder
  • Added files.gif and folders.gif (contributed by SteveHobbs)

-- PeterThoeny - 23 Sep 2006

I would like to see a simple way to add local icons and themes - an "override" method that could be used on a single topic page without editing the RenderListPlugin page in the TWiki web.

I received this request from a co-worker.

-- VickiBrown - 14 Nov 2006

That looks like a sensible enhancement. On implementation, there is a performance question: searching for icons is slower than assuming a fixed location. This can be solved by caching the icon location info.

-- PeterThoeny - 14 Nov 2006

I'm not sure if this is a bug, or I'm not using it properly. Here's my self-documenting example.

No indent:

Indent level 1
Indent level 2 as thread

This line should not be indented, but it is.

  • This line should be indented to level 1, but it is level 2 (no thread)

It is as if it needs an ENDRENDERLIST to go back to normal bullets, but there's no such tag.

I'm running TWiki version TWiki-4.1.2, Sat, 03 Mar 2007, build 13046, Plugin API version 1.11

P.S. as you can see it messes up the indenting on this page too. Sorry about that, but it helps prove my point smile

-- SeanCMorgan - 29 Nov 2007

%RENDERLIST{}% is not supposed to be used inside a bullet list, just put it above the bullet list. I fixed your example.

-- PeterThoeny - 02 Dec 2007

Topic attachments
I Attachment History Action Size Date Who Comment
JPEGjpg CheckboxExample.jpg r2 r1 manage 7.4 K 2005-01-14 - 23:20 UnknownUser Checkbox Example
Compressed Zip archivezip RenderListPlugin.SVNTWiki4r9831.zip r1 manage 30.4 K 2006-04-14 - 21:00 UnknownUser Build of RenderListPlugin, SVN r9831 TWiki4 branch, please test
Compressed Zip archivezip RenderListPluginCorePatched.zip r1 manage 2.7 K 2006-09-22 - 10:20 UnknownUser Patched plugin for displaying icons from other destinations (e.g. TWikiDocGraphics)
GIFgif TreeExample.gif r1 manage 4.5 K 2004-09-23 - 14:55 UnknownUser Tree Branch Example
GIFgif chk.gif r2 r1 manage 1.0 K 2005-01-14 - 23:06 UnknownUser checked checkbox
GIFgif dot_dr.gif r1 manage 0.8 K 2004-09-24 - 13:14 UnknownUser r shaped thread
GIFgif dot_lr.gif r1 manage 0.8 K 2004-09-24 - 13:15 UnknownUser sideways thread
GIFgif dot_udrl.gif r1 manage 0.7 K 2005-07-23 - 18:43 UnknownUser Very high vertical line with one branch at the top
GIFgif filemulti.gif r1 manage 0.9 K 2005-08-15 - 17:57 UnknownUser Multi File icon 16x16
GIFgif foldermulti.gif r1 manage 0.9 K 2005-08-15 - 17:58 UnknownUser Multi Folder icon 16x16
GIFgif unchk.gif r1 manage 0.9 K 2005-01-14 - 22:53 UnknownUser unchecked checkbox
Edit | Attach | Watch | Print version | History: r51 < r50 < r49 < r48 < r47 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r51 - 2007-12-02 - PeterThoeny
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.