You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Alex Harui <ah...@adobe.com> on 2017/03/01 01:18:27 UTC

Re: [FlexJS] Horizontal list missing scrollbar


On 2/26/17, 12:41 AM, "Justin Mclean" <ju...@classsoftware.com> wrote:

>Hi,
>
>> Again, probably DAYG (Do As You Go).
>
>Fair enough. Some pointers how to fix this or where to look at where to
>fix this would be helpful.

Maybe look for examples where there is vertical scrolling, see how it is
built, and try to copy the patterns.

>
>In general people unfamiliar with the framework may need some help if
>they don't know where to look they probably not going to fix the
>framework but just find a hack around any deficiencies it has.
>
>> If none of our examples needed it
>
>Some examples need this. It hard to scroll something if you can’t see it
>has scroll bars in the first place :-)

Well, that seems to be the trend at least on Mac?  I don't see scrollbars
on many web pages until I drag down with two fingers on the touchpad.
Vertical scrolling seems to be working in FlexJSStore on the Products page.

>
>> Not all bugs will be fixed right away.  We just don't have enough
>>people.
>> We need more code contributors.
>
>So we should be coming of of ways to make it easier for people to
>contribute.

I think everyone is working to make contribution easier. Are you implying
that some are not?

>
>> It should just be a choice of ScrollingViewport beads
>
>I looked at the bead, the JS implementation in minimal, and I'd guess the
>change needs to be here:
>
>override public function set strand(value:IStrand):void
>{
>   super.strand = value;
>   (contentView.element as HTMLElement).style.overflow = 'auto';
>}
>
>It seems wrong to duplicate 400 odd lines of code (most of it AS code) to
>make other beads just to change one line of code. Extending the class and
>overriding that single method seems to give compiler errors which is
>unexpected. Any advice? Wouldn't it be better if overflow was a property
>of the bead? 

It isn't wrong, it just may not be what you need for your app.  If you add
a property that has to be checked, that's a bit more code than making
assumptions about what kind of overflow you want.

Here's an analogy.  I have a phillips screwdriver and a standard
screwdriver in my toolbox.  It was not a waste for the manufacturer to put
a handle on the phillips screwdriver as well as the standard screwdriver.
If the job only has phillips screws, I grab the phillips screwdriver and
just use it.  No configuration needed.  I also have a heavier, fatter
screwdriver with one larger hollowed out handle and a set of tips that fit
in the handle.  If I don't know what screws I'm going to find until I pop
off the cover of one of my kids toys, I can grab that one and know I'll
have the right tips, but then I have to configure it, and it is larger so
it often is too big for certain applications.

In the end for scrolling beads, I expect there will be one tuned to just
vertical.  One tuned to just Horizontal.  One tuned to both vertical and
horizontal, and one like you propose that has a property you set, maybe if
you need to change at runtime.  I'll have as many scrolling beads as
screwdrivers in my toolbox, and I'll use one of the universal ones when
doing prototyping, but I'll be glad to know there is a vertical-only one
if I'm trying to squeeze every byte out of an app that only has vertical
scrolling.

My 2 cents (well, maybe that was 4),
-Alex


Re: [FlexJS] Horizontal list missing scrollbar

Posted by Alex Harui <ah...@adobe.com>.

On 2/28/17, 5:52 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
>
>> It isn't wrong, it just may not be what you need for your app.  If you
>>add
>> a property that has to be checked, that's a bit more code than making
>> assumptions about what kind of overflow you want.
>
>AFAIKS it's less code and less of a maintenance issue. If I copy those
>400 lines of code as suggest and if the code changes in one file then it
>needs to change in the other, that can easily get out of sync and cause
>issues.

Yep.  There are trade-offs.  Feel free to create a base class for shared
code if that helps.  There is additional overhead for base classes as
well, so eventually someone will publish and maintain two copies of 400
lines because the likelihood of it changing is low.  The key point is
giving people choices.  We don't want to require someone to have to use
the configurable version if they don't need it.

>
>> In the end for scrolling beads, I expect there will be one tuned to just
>> vertical.  One tuned to just Horizontal.
>
>Which is fine but we don't have that yet. I’m a strong believer in
>getting it to work first, then optimise it, premature optimisation wastes
>time and often makes incorrect assumptions.

Oh good, then you are onboard with us just getting one kind of vertical
scrolling to work and worrying about other kinds of scrolling when someone
finally needed it.

Thanks,
-Alex


Re: [FlexJS] Horizontal list missing scrollbar

Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,

> Maybe look for examples where there is vertical scrolling, see how it is
> built, and try to copy the patterns.

The pattern I tried was the same ie add a ScrollingViewPort.

> Well, that seems to be the trend at least on Mac?

For page content that is obviously cut off sure, but IMO not for items in a control where it's not obvious that you can scroll.

> It isn't wrong, it just may not be what you need for your app.  If you add
> a property that has to be checked, that's a bit more code than making
> assumptions about what kind of overflow you want.

AFAIKS it's less code and less of a maintenance issue. If I copy those 400 lines of code as suggest and if the code changes in one file then it needs to change in the other, that can easily get out of sync and cause issues.

> In the end for scrolling beads, I expect there will be one tuned to just
> vertical.  One tuned to just Horizontal.

Which is fine but we don't have that yet. I’m a strong believer in getting it to work first, then optimise it, premature optimisation wastes time and often makes incorrect assumptions.

The issue here was not vertical vs horizontal scrolling performance or application size but was horizontal scrolling not working at all and not being able to control the visibility of the scroll bars.

Thanks,
Justin