Re: LibCSS: Flexbox property support review

In article <0a012258-3662-78c0-93ca-5dac0982be36@codethink.co.uk>,
Michael Drake <tlsa@netsurf-browser.org> wrote:
> Hello,

> This is a review of the lcneves/flexbox-tidy branch.

[Snip]

This is great news even though I suspect you didn't mean to post it to
'users' :).

I use flex containers a lot to allow blobs of content to flow to fit
mobile to desktop sizes and I became so wound up by NetSurf's inability
to render flex on my own screen, I implemented browser detection and you
can guess what netsurf-style/css is for: it uses display:inline-block
instead of display:flex and while that does the job after a fashion, it's
not quite as pretty. No vertical alignment and no 'intelligent'
distribution across the page.

Will my browser detection please be able to notice a version number
change when flex is added? Otherwise NetSurf users (okay, probably only
me) will be stuck with inline blocks.

--

Tim Hill

timil.com : tjrh.eu : butterwick.eu : blue-bike.uk : youngtheatre.co.uk

LibCSS: Flexbox property support review

Hello,

This is a review of the lcneves/flexbox-tidy branch.

First off I think this is really good work. Almost all the
things I spotted range from minor to trivial.

Aside from the unset values for unit and length in the
min-{width|height} computed style getters, and the fact
that NetSurf is about to do a release[1], I'd be happy
to merge this as-is.

[1] I think NetSurf will need some minor changes to cope
with new values for the display property and the
min-{width|height} properties.



Add codes to flexbox properties
===============================

http://source.netsurf-browser.org/libcss.git/commit/?h=lcneves/flexbox-tidy&id=b1c9ff5a957db2ff86ebacb4b4e735458f7a60ab

+72 - align-content
+ <value> (14bits) :
+ 0 => stretch,
+ 1 => flex-start,
+ 2 => flex-end,
+ 3 => center,
+ 4 => space-between,
+ 5 => space-around,
+ 6 => space-evenly
+ other => Reserved for future expansion.

I'm a bit unsure about the space-evenly value.

CSS Flexible Box Layout Module Level 1 doesn't have this value:
https://www.w3.org/TR/css-flexbox-1/#propdef-align-content

CSS Box Alignment Module Level 3 does have this value and
a few others:
https://www.w3.org/TR/css-align-3/#alignment-values

I think its OK for us to have space-evenly. Same for the
justify-content property.


Parsing: Add support for parsing the flexbox properties
=======================================================

http://source.netsurf-browser.org/libcss.git/commit/?h=lcneves/flexbox-tidy&id=fd73ec6bf364fec71309528a823474533c73a226

src/parse/properties/flex.c:
http://source.netsurf-browser.org/libcss.git/diff/src/parse/properties/flex.c?h=lcneves/flexbox-tidy&id=fd73ec6bf364fec71309528a823474533c73a226

+/**
+ * Parse list-style
+ *

s/list-style/flex/


In css__parse_flex():
+ parserutils_vector_iterate(vector, ctx);
+ }
+
+ /* Handle auto, equivalent of flex: 1 1 auto; */
+ else if ((token->type == CSS_TOKEN_IDENT) &&
+ (lwc_string_caseless_isequal(
+ token->idata, c->strings[AUTO],
+ &match) == lwc_error_ok && match)) {
+ error = css__stylesheet_style_appendOPV(grow_style,
+ CSS_PROP_FLEX_GROW, 0, FLEX_GROW_SET);

Our code style is } else { on a single line, and the comment
would be inside the else block before the first line.

Could do something like:
parserutils_vector_iterate(vector, ctx);

} else if ((token->type == CSS_TOKEN_IDENT) &&
(lwc_string_caseless_isequal(
token->idata, c->strings[AUTO],
&match) == lwc_error_ok && match)) {
/* Handle auto, equivalent of flex: 1 1 auto; */
error = css__stylesheet_style_appendOPV(grow_style,
CSS_PROP_FLEX_GROW, 0, FLEX_GROW_SET);

Also I think we could simplfy handling of auto and none
by creating a copule more bools at the start of the function:

bool auto = false;
bool none = false;

Set those true if we get either of those tokens here, and
then below, in the /* defaults */ section, choose the
defaults that get set based on whether:

1. auto is set
2. none is set
3. neither are set


src/parse/properties/flex_flow.c:
http://source.netsurf-browser.org/libcss.git/diff/src/parse/properties/flex_flow.c?h=lcneves/flexbox-tidy&id=fd73ec6bf364fec71309528a823474533c73a226

+/**
+ * Parse list-style
+ *

s/list-style/flex-flow/


Selection: Add support for the flexbox properties
=================================================

http://source.netsurf-browser.org/libcss.git/commit/?h=lcneves/flexbox-tidy&id=2fd135cd43d6821e944110bbdf8f77bea5cc40fb


In src/select/computed.c:
http://source.netsurf-browser.org/libcss.git/diff/src/select/computed.c?h=lcneves/flexbox-tidy&id=2fd135cd43d6821e944110bbdf8f77bea5cc40fb


In css_computed_min_height():
- return get_min_height(style, length, unit);
+ uint8_t min_height = get_min_height(style, length, unit);
+ uint8_t display = get_display(style);
+
+ if (display != CSS_DISPLAY_FLEX && display !=
CSS_DISPLAY_INLINE_FLEX &&
+ min_height == CSS_MIN_HEIGHT_AUTO)
+ {

Spaces used for indent instead of tab on the first and last
inserted likes above. Also out code style doesn't put the
opening brace on a new line.

Same in css_computed_min_width().

For both css_computed_min_height() css_computed_min_width() we
could rearrange to avoid getting display unless the value is
auto. Something like:


uint8_t css_computed_min_height(const css_computed_style *style,
css_fixed *length, css_unit *unit)
{
uint8_t min_height = get_min_height(style, length, unit);

if (min_height == CSS_MIN_HEIGHT_AUTO) {
uint8_t display = get_display(style);

if (display != CSS_DISPLAY_FLEX &&
display != CSS_DISPLAY_INLINE_FLEX) {
min_height = CSS_MIN_HEIGHT_SET;
}
}

return min_height;
}

Finally, I don't think it's OK to override the value
to *_SET and not set appropriate values for length and unit
at the same time. When the computed value is set to *_AUTO
in the cascade it doesn't clear any values for length and
unit. So we should be them up for 0px where we override
min_height.

Same for both css_computed_min_height() and for
css_computed_min_width().


In css_computed_display():
+ } else if (display == CSS_DISPLAY_INLINE_FLEX) {
+ return CSS_DISPLAY_FLEX;

Spaces used for indent on the first inserted line.


In src/select/computed.h:
http://source.netsurf-browser.org/libcss.git/diff/src/select/computed.h?h=lcneves/flexbox-tidy&id=2fd135cd43d6821e944110bbdf8f77bea5cc40fb

+ * 35 yyybbbaa overflow-y | background-repeat | align-content
+ * 36 bbbbbbaj flex-basis | align-content | justify_content
+ * 37 fffcccjj flex-direction | clear | justify_content

Since align-content and justify-content are split over two
areas, I would say somthing to hint at that in the comments,
e.g.:

* 35 yyybbbaa overflow-y | background-repeat | align-content1
* 36 bbbbbbaj flex-basis | align-content2 | justify_content1
* 37 fffcccjj flex-direction | clear | justify_content2

In the long term perhaps we could consider using a uint32_t
array for the bit data than uint8_t, so its easier to pack
things in without splitting stuff.


+ css_fixed flex_basis;
+
+ css_fixed flex_grow;
+
+ css_fixed flex_shrink;
+
+ int32_t order;

Spaces used for indent.


In src/select/dispatch.c:
http://source.netsurf-browser.org/libcss.git/diff/src/select/dispatch.c?h=lcneves/flexbox-tidy&id=2fd135cd43d6821e944110bbdf8f77bea5cc40fb

+ },
+ {
+ PROPERTY_FUNCS(align_content),

Spaces for indent on the middle inserted line above.


In src/select/propget.h
http://source.netsurf-browser.org/libcss.git/diff/src/select/propget.h?h=lcneves/flexbox-tidy&id=2fd135cd43d6821e944110bbdf8f77bea5cc40fb

-#define BOX_SIZING_INDEX 34
+#define BOX_SIZING_INDEX 23

Good spot! Ditto for the similar change in propset.h.


In get_align_content():
+ /* Most significant bit out of three */
+ bits_b <<= 2;
+
+ uint8_t bits = bits_a | bits_b;

Spaces for indent on the first and last lines above.
Similar in get_justify_content().


Selection: Logic for the flexbox properties
===========================================

http://source.netsurf-browser.org/libcss.git/commit/?h=lcneves/flexbox-tidy&id=587926f812375472962628845226d18f5df95cf1


In src/select/properties/flex_basis.c:
http://source.netsurf-browser.org/libcss.git/diff/src/select/properties/flex_basis.c?h=lcneves/flexbox-tidy&id=587926f812375472962628845226d18f5df95cf1

In css__cascade_flex_basis():
+ uint16_t value = CSS_FLEX_BASIS_INHERIT;
+ css_fixed length = 0;
+ uint32_t unit = UNIT_PX;

Spaces for indent on last line above.


In src/select/properties/order.c:
http://source.netsurf-browser.org/libcss.git/diff/src/select/properties/order.c?h=lcneves/flexbox-tidy&id=587926f812375472962628845226d18f5df95cf1

+ /* Undo the <<10, because this is an integer */
+ order = *((css_fixed *) style->bytecode) >> 10;

Use CSS_RADIX_POINT instead of 10. (From include/libcss/fpmath.h)
Or use the FIXTOINT macro from include/libcss/fpmath.h.



--
Michael Drake http://www.codethink.co.uk/

Re: Experimental treeview search feature - a problem

On 28 Sep 2017 Michael Drake <michael.drake@codethink.co.uk> wrote:


> On 25/09/17 14:19, Richard Torrens (lists) wrote:
>> I have just spotted a (hopefully small) problem - it's impossible to
>> delete items!

> Is #4213 any better?

Yes, many thanks.

Best wishes,

Peter.

--
Peter Young (zfc Pt) and family
Prestbury, Cheltenham, Glos. GL52, England
http://pnyoung.orpheusweb.co.uk
pnyoung@ormail.co.uk

Re: Experimental treeview search feature - a problem

On 25/09/17 14:19, Richard Torrens (lists) wrote:
> I have just spotted a (hopefully small) problem - it's impossible to
> delete items!

Is #4213 any better?

Cheers,

--
Michael Drake http://www.codethink.co.uk/

Re: Experimental treeview search feature - a problem

On 27/09/17 13:43, Peter Young wrote:
> On 25 Sep 2017 "Richard Torrens (lists)" <Lists@Torrens.org> wrote:
>
>> I have just spotted a (hopefully small) problem - it's impossible to
>> delete items!

> Well, up to a point! If I try to select an item in, say the hotlist
> and then press menu over it, the white-on-black colouring vanishes,
> and selecting delete from the menu does nothing. However, if you press
> the delete key while the item is highlighted the deletion occurs.

Interesting. I can't reproduce this on the GTK front end.

I'll look into it over the next view days to see if I can work
out what the RISC OS front end is doing differently.

Cheers,

--
Michael Drake http://www.codethink.co.uk/

Re: Experimental treeview search feature - a problem

On 25 Sep 2017 "Richard Torrens (lists)" <Lists@Torrens.org> wrote:

> I have just spotted a (hopefully small) problem - it's impossible to
> delete items!

> Select an item and assoon as the mouse pointer moves away from the window
> or over the search box, the item is delelected.

> Same thing happens if you press Menu!

> #4211, ARMX6 5.23

Well, up to a point! If I try to select an item in, say the hotlist
and then press menu over it, the white-on-black colouring vanishes,
and selecting delete from the menu does nothing. However, if you press
the delete key while the item is highlighted the deletion occurs.

#4212, same RISC OS.

Best wishes,

Peter.

--
Peter Young (zfc Pt) and family
Prestbury, Cheltenham, Glos. GL52, England
http://pnyoung.orpheusweb.co.uk
pnyoung@ormail.co.uk

Experimental treeview search feature - a problem

I have just spotted a (hopefully small) problem - it's impossible to
delete items!

Select an item and assoon as the mouse pointer moves away from the window
or over the search box, the item is delelected.

Same thing happens if you press Menu!

#4211, ARMX6 5.23

--
Richard Torrens.
http://www.Torrens.org for genealogy, natural history, wild food, walks, cats
and more!

Re: Experimental treeview search feature

Hi Michael

On Mon, 18 Sep 2017 23:29:47 +0100, Michael Drake wrote:

> It would be helpful if people could put it thoroughly through its
> paces. Any feedback gratefully received.

I've finally had a chance to test it out here (Amiga frontend). It is
working well, except for a couple of minor issues;

1. When there are a lot of search results, the treeview is scrolling
to the end of the list. This is confusing because it means the search
string is no longer in view. I think it should be remaining at the
top.

If you have enough entries to fill up the window you can test this out
easily by typing a single common letter into the search field.

2. If the window is closed with a search in progress, when the window
is re-opened the search string does not display but the results are
still present. I think this is due to how I implemented the windows
as they are disposed of completely and re-created on the Amiga
frontend, whereas on others the state is remembered and re-used.

I guess the treeview cleanup code is clearing the search string but
not the underlying results? Or forgetting the search string? I'm not
sure what the correct thing for it to do is, but the state of the
treeview (which folders are open/closed) is normally remembered, so it
should probably be remembering the search string.

Chris

Re: Experimental treeview search feature

In article <9fd418f6-1f08-b24e-3aff-5bfce9381e28@codethink.co.uk>,
Michael Drake <michael.drake@codethink.co.uk> wrote:
> On 22/09/17 02:20, Harriet Bazley wrote:
> > Other thoughts: from a practical point of view, I think it would be
> > preferable if any active search were deleted when the window is closed.
> > Otherwise it gets a bit disconcerting when you go to reopen your
> > history/hotlist and there are only two or three entries visible, due to a
> > search you carried out earlier and have long since finished with -
> > particularly as the icon in question doesn't have the input focus when the
> > window reopens,

> I agree, it would be better to cancel the search when the window
> is closed. Unfortunately the core doesn't know when the front
> end closes the window at the moment, so it's not straightforward
> to change that just yet.

> and clearing the old search string is a pain!

> Once the search field has focus, either ESC or CTRL+U should clear it.

Would a "clear" button make sense? Maybe a click on the search icon?

--
Richard Torrens.
http://www.Torrens.org for genealogy, natural history, wild food, walks, cats
and more!

Re: Experimental treeview search feature

On 22/09/17 02:20, Harriet Bazley wrote:
> Other thoughts: from a practical point of view, I think it would be
> preferable if any active search were deleted when the window is closed.
> Otherwise it gets a bit disconcerting when you go to reopen your
> history/hotlist and there are only two or three entries visible, due to a
> search you carried out earlier and have long since finished with -
> particularly as the icon in question doesn't have the input focus when the
> window reopens,

I agree, it would be better to cancel the search when the window
is closed. Unfortunately the core doesn't know when the front
end closes the window at the moment, so it's not straightforward
to change that just yet.

and clearing the old search string is a pain!

Once the search field has focus, either ESC or CTRL+U should clear it.

Cheers,

--
Michael Drake http://www.codethink.co.uk/

Re: Experimental treeview search feature

On 22/09/17 01:11, Harriet Bazley wrote:

> The size of the work area gets a bit confused if you toggle the 'expand
> entries' icon with a search active (seems to reset to what it would be if
> the whole window were being displayed, rather than just the visible
> entries). It corrects itself if you then carry out a fresh search.

Good spot, that should be fixed in the latest build.

Cheers,

--
Michael Drake http://www.codethink.co.uk/

Re: Experimental treeview search feature

On 18 Sep 2017 as I do recall,
Michael Drake wrote:



> Any feedback gratefully received.
>
Other thoughts: from a practical point of view, I think it would be
preferable if any active search were deleted when the window is closed.
Otherwise it gets a bit disconcerting when you go to reopen your
history/hotlist and there are only two or three entries visible, due to a
search you carried out earlier and have long since finished with -
particularly as the icon in question doesn't have the input focus when the
window reopens, and clearing the old search string is a pain!

--
Harriet Bazley == Loyaulte me lie ==

A poor workman blames his tools.

Re: Experimental treeview search feature

On 18 Sep 2017 as I do recall,
Michael Drake wrote:

> Hello,
>
> An experimental search feature has been added to the following:
>
> 1. Hotlist viewer (bookmarks)
> 2. Global history viewer
> 3. Cookie manager window

Seems to work - thanks.
The size of the work area gets a bit confused if you toggle the 'expand
entries' icon with a search active (seems to reset to what it would be if
the whole window were being displayed, rather than just the visible
entries). It corrects itself if you then carry out a fresh search.

--
Harriet Bazley == Loyaulte me lie ==

Sattinger's Law: It works better if you plug it in.

Re: [gccsdk] wget 1.19.1 tries to write a logfile

In article <mpro.ovjihf005ibqb01yb.pittdj@pittdj.co.uk>,
David Pitt <pittdj@pittdj.co.uk> wrote:
> Kevin Wells, on 28 Aug, wrote:

> > Hi
> >
> > When using wget 1.19.1 with the quiet option selected I get the
> > following message:
> >
> > Redirecting output to 'wget-log.##'
> >
> > The ## is a number that increases each time.
> >
> > The file is a log of the connection details of wget.
> >
> > Previous versions did not display this.

> Having done further tests I am seeing the apparently spurious
> 'wget-log' both with and without the '-q' flag. This is both with the
> currency command line example given and a simple wget from my site.

> *wget --version
> GNU Wget 1.19.1 built on riscos.

> *wget http://www.pittdj.co.uk/temp/temp.htm

> Redirecting output to 'wget-log'.
> *
> *wget http://www.pittdj.co.uk/temp/temp.htm -q

> Redirecting output to 'wget-log.1'.
> *

> The '-q' flag results in an empty 'wget-log' file.


> Using wget 1.18, home built here with autobuilder revision 7118, the log
> output defaults to the screen as expected with no redrection.

> wget 1.19.1-3ubuntu1 on Ubuntu 17.10 (development branch) does not redirect
> either.
>
> FWIW HTH

While testing 1.19.1 I awas already using currency convertor daily and
never encountered this, apparently because I have
logfile = /RAM::Ramdisc0/$/wgt.log
in my (unixhome) /wgetrc file.

Setting
logfile = /dev/null
stops all output.

The commandline version would be
-o /dev/null

I dont know why --quiet is not working.
The logfile output is quite separate to the output document processing
where my change (close open file) was made I think.
but a build of 1.19.1 without my patches should verify that.

Ron M (just back from sunny Queensland)



_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

Re: Experimental treeview search feature

> Message: 1
> Date: Mon, 18 Sep 2017 23:29:47 +0100
> From: Michael Drake <tlsa@netsurf-browser.org>
> Subject: Re: Experimental treeview search feature
> To: netsurf-users@netsurf-browser.org
> Message-ID: <8e933e3d-f507-99c8-2fec-26a5ca3106b9@netsurf-browser.org>
> Hello,
>
> An experimental search feature has been added to the following:
>
> 1. Hotlist viewer (bookmarks)
> 2. Global history viewer
> 3. Cookie manager window
>
> To use it, click in the area next to the search icon at the top
> of the window, and start typing.
>
> It has currently only been tried under the GTK front end.
>
> It would be helpful if people could put it thoroughly through its
> paces. Any feedback gratefully received.
>
> Cheers,

I just tried it in Atari build and it works fine.

Thanks,

Peter

Re: Experimental treeview search feature

In article <8e933e3d-f507-99c8-2fec-26a5ca3106b9@netsurf-browser.org>,
Michael Drake <tlsa@netsurf-browser.org> wrote:
> An experimental search feature has been added to the following:

> 1. Hotlist viewer (bookmarks)
> 2. Global history viewer
> 3. Cookie manager window

> To use it, click in the area next to the search icon at the top
> of the window, and start typing.

A feature I have sometimes wished was present - it works fine (ARMX6 5.23).

Thanks.

--
Richard Torrens.
http://www.Torrens.org for genealogy, natural history, wild food, walks, cats
and more!

Re: Experimental treeview search feature

On 18 Sep 2017 Michael Drake <tlsa@netsurf-browser.org> wrote:

> Hello,

> An experimental search feature has been added to the following:

> 1. Hotlist viewer (bookmarks)
> 2. Global history viewer
> 3. Cookie manager window

> To use it, click in the area next to the search icon at the top
> of the window, and start typing.

> It has currently only been tried under the GTK front end.

> It would be helpful if people could put it thoroughly through its
> paces. Any feedback gratefully received.

I've very briefly tried it in RISC OS, #4200, and it works well. Many
thanks for the improvement.

Best wishes,

Peter.

--
Peter Young (zfc Pt) and family
Prestbury, Cheltenham, Glos. GL52, England
http://pnyoung.orpheusweb.co.uk
pnyoung@ormail.co.uk

Experimental treeview search feature

Hello,

An experimental search feature has been added to the following:

1. Hotlist viewer (bookmarks)
2. Global history viewer
3. Cookie manager window

To use it, click in the area next to the search icon at the top
of the window, and start typing.

It has currently only been tried under the GTK front end.

It would be helpful if people could put it thoroughly through its
paces. Any feedback gratefully received.

Cheers,

--
Michael Drake http://www.netsurf-browser.org/

Re: [gccsdk] GCC and Rpi3

On 05/09/17 11:36, Gavin Wraith wrote:
> The current GCC for RISC OS was developed before the
> Rpi3 became available. Are there any issues (e.g.
> with compiler flags) for those using GCC on an Rpi3?

I assume you mean generating code for use on Rpi3?

AFAIK, the default flags should be fine for Rpi3 and tend to
generate code that is suitable for all CPUs. It's when you wish
to generate code that takes advantage of newer instructions
that you may wish to change the default flags (e.g, -mfpu=vfp).

Lee.

.

_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

NetSurf browser detection

Readers may be familiar with the feedback which drove me to make special
dispensation for NetSurf users on the RISC OS Events Calendar at
www.timil.com/riscos/calendar ;o)

Well, I have succumbed to some moaning of my own. The lack of support for
CSS flex containers (a useful layout tool to flow objects around the page
and space them out sensibly on any sized display) has me now providing a
different style sheet with inline-block containers for NetSurf. This is
probably only for my personal use and it took a while to get it working
until I remembered NetSurf's sodding camel-case!

Apart from that I am very pleased that here, WebJames+PHP can take a 185
line, eight-column CSV file and sort it, serve the result to NetSurf
which can now actually cope with the layout foibles. No quite the 'blink
of an eye' speed of my ISP's hosting though.

Still under development: trying to display two CSV files in 24 different
ways and not shut out our less capable browser. No javascript required!
PHP does the donkey work. :-)

www.youngtheatre.co.uk/archive/list

Feedback on the NetSurf or other outcomes always welcome.

--

Tim Hill

timil.com : tjrh.eu : butterwick.eu : blue-bike.uk : youngtheatre.co.uk

[gccsdk] GCC and Rpi3

The current GCC for RISC OS was developed before the
Rpi3 became available. Are there any issues (e.g.
with compiler flags) for those using GCC on an Rpi3?
--
Gavin Wraith (gavin@wra1th.plus.com)
Home page: http://www.wra1th.plus.com/

_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK