issue-#32: avoiding fonts dependency

Locked

Should we use drawing primitives instead of fonts for fold arrows?

Yes, even if the rendering looks ugly
3
33%
Yes, but only if the rendering looks good
3
33%
No
1
11%
More research is required first
0
No votes
Abstain
2
22%
 
Total votes: 9

User avatar
Josef Templ
Posts: 2047
Joined: Tue Sep 17, 2013 6:50 am

issue-#32: avoiding fonts dependency

Post by Josef Templ »

This poll is for getting the opinion of the center members regarding the usage of fonts for
painting the fold arrows as discussed in issue-#32.
An alternative has been proposed by Ivan: use drawing primitives instead of fonts.
The advantage is that there is no dependency on fonts, which may not be available on
some platform. In addition, this opens the possibility to use custom shapes that are not available
in any font at all such as the proposed new fold arrows shown in
http://forum.blackboxframework.org/view ... t=40#p2036.

Please note that this poll is not about merging any code to master because only simple prototypes/
demos have been presented so far. This poll should clarify if it gives sense at all to investigate
Ivan's proposal further.

I have split the Yes votes into two sub-groups, because there is quite a difference in the
implementation effort and in the look-and-feel. The option entitled
"Yes, but only if the rendering looks good" assumes that:
  1. the icons show the expected symmetry at the pixel level for all reasonable sizes,
    for example the embedded + sign must be symmetric in both dimensions
    and +/- must be aligned properly with the arrow)
  2. - only straight lines and 45 degree angles are used because these look good even without subpixel rendering
  3. - the layout must scale with the size, e.g. the overall width and height, the size and thickness of the +/- signs, etc.
Gentlemen, please cast your vote.

- Josef
Last edited by Josef Templ on Thu Apr 23, 2015 11:25 am, edited 1 time in total.
Zinn
Posts: 476
Joined: Tue Mar 25, 2014 5:56 pm
Location: Frankfurt am Main
Contact:

Re: issue-#32: avoiding fonts dependency

Post by Zinn »

Please let me explain why I vote abstain.
Personally I prefer to use fonts. So I have to vote no.
But I’m not against to create our own sign. So I have to vote yes.

I’m against to insert the drawing directly into the module StdFolds.
I would like to create a separated module (maybe called StdFonts or StdSigns) to do the drawings.
We need signs for Targets and Links too, which can be added to that new module.

Currently I prefer to stay at using fonts as long as the other solution is not ready.
Further I would like to have an implementation
where we can switch between fonts and our own sign easily.

I propose to use + and - sign from the fonts only at the beginning of the folds
and one blank character at the end of the folds.
We may have gray background behind +, - and the blank sign.
That sound like a revolution. Please try it. It looks really nice.
Bernhard
Posts: 68
Joined: Tue Sep 17, 2013 6:56 am
Location: Munich, Germany

Re: issue-#32: avoiding fonts dependency

Post by Bernhard »

after Helmuts statement I changed my decision to abstain also. I personally would prefer a solution, which is as simple as possible and I think this is via fonts, but I also understand that another solution might be preferable.

Overall I would appreciate a configurable solution, maybe in the form of a factory method, which would have a default implementation filled by subsystem Host, but I don't think I have the time for implementing it. This would also avoid having host dependencies cluttered over more places and it would also allow for personal configuration of fold appearance.
User avatar
Josef Templ
Posts: 2047
Joined: Tue Sep 17, 2013 6:50 am

Re: issue-#32: avoiding fonts dependency

Post by Josef Templ »

Thanks to everybody for the vote and for the comments.
I think that the new proposal is rendered well enough to be
a really useful alternative to the fonts-based version and it removes all platform dependencies,
i.e. it works under all Windows versions including Russian Windows and wine.
It is also easier to remember the state of the fold with the + and - markers for
collapsed and expanded folds.

Regarding the proposed exchangeability of the fold glyphs:
It is not as easy as it looks. The glyphs must be drawn such that they fit
within the size of the fold element. The size is computed outside of the
Restore method. So there would be a need for two hooks. In addition,
there may be the need for an initialization, which is a third hook.

There is always the escape mechanism to use a different StdFolds module but for
what reason?

- Josef
Locked