Page 1 of 1
Enhancing the Tree View widget
Posted: Wed Apr 24, 2019 3:53 pm
by pink
I seem to remember watching a video, probably from one from one of the conferences, where Elanor went through the tree widget to make it function better on mobile devices. Does anyone remember when that was?
Is that code available somewhere?
Re: Enhancing the Tree View widget
Posted: Thu Apr 25, 2019 12:44 am
by bwmilby
I do recall a LCG topic where some things were done with the widget. I just did some custom code that allowed for the text size to be adjusted and a few other things for targeting mobile. I have not worked a PR up to get it pushed into the production code though.
What other items were you thinking should be updated? I can see that the icon size should be larger, but I have not settled on how would be best to do that (keep a fixed margin and scale automatically with text size or have the icon get set separately).
Re: Enhancing the Tree View widget
Posted: Thu Apr 25, 2019 3:37 pm
by pink
To be honest, I haven't tried to use the tree widget in an iOS app in a while, so it is possible that it works differently in its current incarnation (I should really test). Some of the below I can do myself, but also there's no point in reinventing the wheel. My main desires for the tree view are:
1. larger row sizes to make touch interaction simpler.
2. being able to scroll by swiping up or down (last time I tried, you had to attempt to grab the scrollbar)
3. better response for opening and collapsing (although that is probably related to the height of the row)
4. a built in way of distingusing if the item being pressed is a branch or a leaf. (i.e. in array terms, if the item being selected is a value or a key). This would allow the tree to be used as a multi-level menu
5. I would like to have the ability to have only one branch open at a time, so if one was opened, it would collapse all others.
Re: Enhancing the Tree View widget
Posted: Thu Apr 25, 2019 5:06 pm
by bwmilby
Everything needed to do most of that is in the branch I have. Some is actually done in LCS based on messages/properties that are available. The only size piece not done is the icons.
5 could be implemented fairly easily. A menu mode property could be added that would only allow a single expansion at a time (essentially fold the entire tree and then expand the selected node). The test for the version I worked did this in LCS but only for first level selections.
Not really sure about 3. I do not notice a performance issue there.
Re: Enhancing the Tree View widget
Posted: Thu Apr 25, 2019 6:26 pm
by pink
For #3 I was getting at performance on iOS, I found it hard to open and close branches. Again, a big part of that was probably just the small row size made it hard to accurately double press the row I was shooting for.
For the purpose of mobile devices, it would be good to have an option to use a single click/touch to open and close branches. That one is easy enough...
just planning here...
Add property, variable, handler...
Code: Select all
property singleTouchFold get getSingleTouchFold set setSingleTouchFold
metadata singleTouchFold.editor is "com.livecode.pi.boolean"
metadata singleTouchFold.default is "false"
metadata singleTouchFold.label is "Single Touch to open branch" --too long?
private variable mSingleTouchFold as Boolean
private handler setSingleTouchFold(in pTouch as Boolean)
put pTouch into mSingleTouchFold
end handler
private handler getSingleTouchFold() returns Boolean
return mSingleTouchFold
end handler
in the OnClick function...
Code: Select all
if the click count > 1 or mSingleTouchFold then
if tData["leaf"] then
combine tData["path"] with mPathDelimiter into tPathString
post "actionDoubleClick" with [tPathString]
else
if tData["folded"] is true then
unfoldPath(tData["path"])
else
foldPath(tData["path"])
end if
end if
end if
Re: Enhancing the Tree View widget
Posted: Sat Apr 27, 2019 4:24 am
by bwmilby
Since the clickCount = 1 code comes first currently, the revised block would need to be moved up. The length of the display name is pretty limited too. I was thinking "Menu Mode" which would describe the use case. Since it also impacts the action message, I think it does need to be more general than just addressing the fold piece.