Re: [GNC-dev] (no subject)
I forgot to mention that an absolutely positioned element behaves differently
with respect to height rules. But absolute positioning should usually be
avoided as much or more than setting height in the first place. Let the
rendering engine do the work rather than treating the layout like a manually
designed desktop publishing exercise.
Regards,
Adrien
> On Nov 19, 2019 w47d323, at 12:48 PM, Adrien Monteleone
> wrote:
>
>
>
>> On Nov 19, 2019 w47d323, at 12:59 AM, Christopher Lam
>> wrote:
>>
>> Dear All
>>
>> Maint branch includes recent changes to report whereby is
>> inserted at the top. This is to improve standards compliance.
>>
>> The minor side effect right now is that it enforces standards-mode instead
>> of quirks-mode in webkit (both unices and Windows) charts are squashed to
>> 300px because of
>> https://stackoverflow.com/questions/32214152/why-does-my-div-height-100-work-only-when-doctype-is-removed/32215263#32215263
>> and I'm not 100% sure of the most appropriate fix yet. Inserting html,body
>> {height:95%} does the trick by expanding parent elements to 95% of
>> viewport. Setting height to 100% would be fine except it causes scrollbars
>> to appear unnecessarily. This fix works both in Unix (libwebkit2) and
>> Windows (libwebkit1).
>>
>> If anyone has better ideas how to fix this please let me know. If this
>> change is unwanted we can revert to previous quirks-mode reports.
>
> The solution and explanation is given both in that link as well as the
> further explanatory link contained therein:
> https://stackoverflow.com/a/31728799/3597276
>
> The problem is the use of percentage which is relative to its parent element.
> But if the parent (all the way up the document tree to the root element,
> `html`) does not have a set height, then the value defaults to `auto` because
> there is nothing to calculate the percentage on.
>
> The solution is to not use percentage.
>
> If you need a relative rule, (as opposed to explicit units like `px` or `pt`)
> use Viewport Height, `vh`, thus set {height: 100vh}
>
> That may not be what you want, however. You might just need a smaller
> percentage of the viewport, but any such value has a reference for
> calculation. (the viewport height is known by the browser and doesn’t rely on
> the document tree cascade. It can be changed by the user, however)
>
> The reason that percentage ‘works’ in quirks-mode is because quirks-mode
> converts the percentage rule to a viewport height rule.
>
> So I’d advocate for sticking with standards-mode and using the proper style
> declaration.
>
> Note too, it is rare to need to set height. While there are some exceptions,
> needing to set height means something else was maybe done wrong somewhere. It
> is probably better to find and fix that error instead and let the rendering
> engine determine the height based on content.
>
>
>> Additionally there's a recent change to re-enable negative numbers=red in
>> reports; a side effect of this was border colour also becomes red. This is
>> fixed by applying CSS rule "th,td {border-color:grey}" which could cause
>> cause issues with users with different colour themes. Any further
>> suggestions welcome.
>
> Borders should not be affected by a rule for coloring negative numbers at
> all. That tells me the proper specificity is not being used in the CSS rule.
>
> Fix the specificity targeting negative numbers instead and you won’t need to
> mess with border color at all.
>
> Regards,
> Adrien
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] (no subject)
> On Nov 19, 2019 w47d323, at 12:59 AM, Christopher Lam
> wrote:
>
> Dear All
>
> Maint branch includes recent changes to report whereby is
> inserted at the top. This is to improve standards compliance.
>
> The minor side effect right now is that it enforces standards-mode instead
> of quirks-mode in webkit (both unices and Windows) charts are squashed to
> 300px because of
> https://stackoverflow.com/questions/32214152/why-does-my-div-height-100-work-only-when-doctype-is-removed/32215263#32215263
> and I'm not 100% sure of the most appropriate fix yet. Inserting html,body
> {height:95%} does the trick by expanding parent elements to 95% of
> viewport. Setting height to 100% would be fine except it causes scrollbars
> to appear unnecessarily. This fix works both in Unix (libwebkit2) and
> Windows (libwebkit1).
>
> If anyone has better ideas how to fix this please let me know. If this
> change is unwanted we can revert to previous quirks-mode reports.
The solution and explanation is given both in that link as well as the further
explanatory link contained therein: https://stackoverflow.com/a/31728799/3597276
The problem is the use of percentage which is relative to its parent element.
But if the parent (all the way up the document tree to the root element,
`html`) does not have a set height, then the value defaults to `auto` because
there is nothing to calculate the percentage on.
The solution is to not use percentage.
If you need a relative rule, (as opposed to explicit units like `px` or `pt`)
use Viewport Height, `vh`, thus set {height: 100vh}
That may not be what you want, however. You might just need a smaller
percentage of the viewport, but any such value has a reference for calculation.
(the viewport height is known by the browser and doesn’t rely on the document
tree cascade. It can be changed by the user, however)
The reason that percentage ‘works’ in quirks-mode is because quirks-mode
converts the percentage rule to a viewport height rule.
So I’d advocate for sticking with standards-mode and using the proper style
declaration.
Note too, it is rare to need to set height. While there are some exceptions,
needing to set height means something else was maybe done wrong somewhere. It
is probably better to find and fix that error instead and let the rendering
engine determine the height based on content.
> Additionally there's a recent change to re-enable negative numbers=red in
> reports; a side effect of this was border colour also becomes red. This is
> fixed by applying CSS rule "th,td {border-color:grey}" which could cause
> cause issues with users with different colour themes. Any further
> suggestions welcome.
Borders should not be affected by a rule for coloring negative numbers at all.
That tells me the proper specificity is not being used in the CSS rule.
Fix the specificity targeting negative numbers instead and you won’t need to
mess with border color at all.
Regards,
Adrien
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
[GNC-dev] (no subject)
Dear All
Maint branch includes recent changes to report whereby is
inserted at the top. This is to improve standards compliance.
The minor side effect right now is that it enforces standards-mode instead
of quirks-mode in webkit (both unices and Windows) charts are squashed to
300px because of
https://stackoverflow.com/questions/32214152/why-does-my-div-height-100-work-only-when-doctype-is-removed/32215263#32215263
and I'm not 100% sure of the most appropriate fix yet. Inserting html,body
{height:95%} does the trick by expanding parent elements to 95% of
viewport. Setting height to 100% would be fine except it causes scrollbars
to appear unnecessarily. This fix works both in Unix (libwebkit2) and
Windows (libwebkit1).
If anyone has better ideas how to fix this please let me know. If this
change is unwanted we can revert to previous quirks-mode reports.
Additionally there's a recent change to re-enable negative numbers=red in
reports; a side effect of this was border colour also becomes red. This is
fixed by applying CSS rule "th,td {border-color:grey}" which could cause
cause issues with users with different colour themes. Any further
suggestions welcome.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
[GNC-dev] (no subject)
> On 1 May 2018, at 7:06 AM, Chris Good <goodchri...@gmail.com> wrote: > >> Message: 6 >> Date: Mon, 30 Apr 2018 10:15:29 +0200 >> From: Geert Janssens <geert.gnuc...@kobaltwit.be> >> To: gnucash-devel@gnucash.org >> Subject: Re: [GNC-dev] Solved : how to extend the selection of >> predefined actions on a split >> Message-ID: <1739455.a6lqanb...@legolas.kobaltwit.lan> >> Content-Type: text/plain; charset="us-ascii" >> >> Op maandag 30 april 2018 10:07:47 CEST schreef Paul Dest: >>> My problem is solved. Due to a hint in the gnucash-de mailing list I >>> have identified the needed files and made the changes successfully. >>> >>> But still wondering how the *.po files are created. They have very >>> regular format and each entry is commented with references to the lines >>> in c-files. That does not seem to be coded by the hand; all the *.po >>> files would be needed to be rewritten if a line would be inserted in one >>> of the c files referenced (what is actually the case with my personal >>> changes). Here is an example from de.po to illustrate what I am talking >>> about: >>> >>> #: gnucash/gnome-utils/gnc-tree-model-split-reg.c:2856 >>> #: gnucash/register/ledger-core/split-register.c:2486 >>> msgid "Withdraw" >>> msgstr "Belastung" >>> >> >> https://wiki.gnucash.org/wiki/Translation#Updating_an_existing_.po_file >> >> That page has additional documentation on how to translate gnucash (for >> which >> the *.po files are used), gnucash documentation or gnucash account hierarchy >> templates. >> >> Regards, >> >> Geert > > Hi Paul, > > Another solution, which does not cause extra work each time you upgrade, > would be to program a function key to output "Paul". > I haven't tried this myself but I think it should be possible to do this by > modifying a gtk3 user configuration file which doesn't get clobbered by an > upgrade. > See https://wiki.gnucash.org/wiki/GTK3 > > Regards, Chris Good Sent again with Subject this time which I must have somehow clobbered on my iPad. Sorry. Regards, Chris Good ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
[GNC-dev] (no subject)
> Message: 6 > Date: Mon, 30 Apr 2018 10:15:29 +0200 > From: Geert Janssens <geert.gnuc...@kobaltwit.be> > To: gnucash-devel@gnucash.org > Subject: Re: [GNC-dev] Solved : how to extend the selection of > predefined actions on a split > Message-ID: <1739455.a6lqanb...@legolas.kobaltwit.lan> > Content-Type: text/plain; charset="us-ascii" > > Op maandag 30 april 2018 10:07:47 CEST schreef Paul Dest: >> My problem is solved. Due to a hint in the gnucash-de mailing list I >> have identified the needed files and made the changes successfully. >> >> But still wondering how the *.po files are created. They have very >> regular format and each entry is commented with references to the lines >> in c-files. That does not seem to be coded by the hand; all the *.po >> files would be needed to be rewritten if a line would be inserted in one >> of the c files referenced (what is actually the case with my personal >> changes). Here is an example from de.po to illustrate what I am talking >> about: >> >> #: gnucash/gnome-utils/gnc-tree-model-split-reg.c:2856 >> #: gnucash/register/ledger-core/split-register.c:2486 >> msgid "Withdraw" >> msgstr "Belastung" >> > > https://wiki.gnucash.org/wiki/Translation#Updating_an_existing_.po_file > > That page has additional documentation on how to translate gnucash (for which > the *.po files are used), gnucash documentation or gnucash account hierarchy > templates. > > Regards, > > Geert Hi Paul, Another solution, which does not cause extra work each time you upgrade, would be to program a function key to output "Paul". I haven't tried this myself but I think it should be possible to do this by modifying a gtk3 user configuration file which doesn't get clobbered by an upgrade. See https://wiki.gnucash.org/wiki/GTK3 Regards, Chris Good ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
