Tiny Core Linux
Tiny Core Extensions => TCE Q&A Forum => Topic started by: emninger on December 11, 2015, 02:31:43 AM
-
How can i improve the font (resolution) handling in fltk? I downloaded dillo (from the repos) because it's good to have an alternative browser handy, configured the ~/.dillo/dillorc as described in the instructions. But the font resolution continues to be very poor.
As long as i only used editor, aterm & cie i didn't care that much, but using a browser it's hurting ;) My .Xdefaults looks like this:
!~/.Xdefault: Control the behavior of x-clients
!
! Xcursor theme: ~/.icons
!
Xcursor.theme: SharpDot
! Xfont settings ------------------------------------------------------------
!
Xft.autohint: 0
Xft.lcdfilter: lcddefault
Xft.hintstyle: hintslight
Xft.hinting: 1
Xft.antialias: 1
Xft.rgba: rgb
! aTerm settings ------------------------------------------------------------
!
! double-click to select whole URLs :D
aterm*charClass: 33:48,36-47:48,58-59:48,61:48,63-64:48,95:48,126:48
!
aterm*loginShell:true
aterm*transparent:true
aterm*shading:60
aterm*background:Black
aterm*foreground:White
aterm*cursorColor: green
aterm*utf8: always
aterm*utf8Fonts: always
aterm*utf8Title: true
aterm*scrollBar:true
aterm*scrollBar_right:true
aterm*transpscrollbar:true
aterm*saveLines:4096
aterm*font:*-*-fixed-medium-r-normal--*-140-*-*-*-*-iso8859-1
aterm*boldFont:*-*-fixed-bold-r-normal--*-*-140-*-*-*-*-iso8859-1
aterm*selectToClipboard: true
fltk*scheme: gtk+
! xpdf -----------------------------------------------------------------------
xpdf*enableFreetype: yes
xpdf*antialias: yes
xpdf*foreground: black
xpdf*background: white
xpdf*urlCommand: /usr/local/bin/firefox %s
Thanks in advance for your patience!
-
The fltk extensions are compiled without Xft support.
You'd need to recompile fltk with Xft support enabled.
-
Thanks. Means to create then, an own extension (following the procedure described in Corebook). Correct?
If so, is it reasonable to build fltk 2 or better stick with 1.3 ?
-
Maybe fltk-1.3 would be better - that way you can re-compile flwm from tinycore git and use the build instructions here:
http://tinycorelinux.net/6.x/x86/tcz/src/flwm/
Note also, there is a patch for fltk-1.3 here:
http://tinycorelinux.net/6.x/x86/tcz/src/fltk
-
BTW, did you try the fifth browser extension, the display seems fine to me with the stock fltk-1.3/flwm.
-
dillo doesn't support flltk 2 any more. I think fltk people also call fltk2 an accident. Now most people only use up to fltk 1.3.
you can also look in the old repos, i think there should be a dillo extension by me against xft, obviously it's not the current version.
-
First of all: A BIG THANK YOU!!!
@juanito: I'm using fluxbox.
@hiro: I built myfltk-1.3.3.tcz - apparently successfully.
Now a practical question, before i'm going to ruin something. Should i remove the default (repository's) fltk.tcz and add my ftlk to the onbootlist. Or should i leave both?
-
You should use either myfltk-1.3 or fltk-1.3, but not both.
Note that anything that depends on fltk-1.3 might need recompiling against myfltk-1.3
-
@juanito: I had a look at fifth - but i did not see the option to define a proxy (?). And i would not like to set a proxy systemwide. But you're right: the font rendering is much nicer than in dillo.
Is there somewhere an overview, which fltk settings are supported/possible in Xresources?
-
Note that anything that depends on fltk-1.3 might need recompiling against myfltk-1.3
Seems so. myfltk.tcz did not have a positive effect. So i think i have to go thru the process of building it and of building dillo another time.
Therefore some questions regard building fltk:
$ ./configure --help
gives me, among other this options (please accept my excuses if this is a dumb question):
Fine tuning of the installation directories:
--bindir=DIR user executables [EPREFIX/bin]
--sbindir=DIR system admin executables [EPREFIX/sbin]
--libexecdir=DIR program executables [EPREFIX/libexec]
--sysconfdir=DIR read-only single-machine data [PREFIX/etc]
--sharedstatedir=DIR modifiable architecture-independent data [PREFIX/com]
--localstatedir=DIR modifiable single-machine data [PREFIX/var]
--libdir=DIR object code libraries [EPREFIX/lib]
--includedir=DIR C header files [PREFIX/include]
--oldincludedir=DIR C header files for non-gcc [/usr/include]
--datarootdir=DIR read-only arch.-independent data root [PREFIX/share]
--datadir=DIR read-only architecture-independent data [DATAROOTDIR]
--infodir=DIR info documentation [DATAROOTDIR/info]
--localedir=DIR locale-dependent data [DATAROOTDIR/locale]
--mandir=DIR man documentation [DATAROOTDIR/man]
--docdir=DIR documentation root [DATAROOTDIR/doc/PACKAGE]
--htmldir=DIR html documentation [DOCDIR]
--dvidir=DIR dvi documentation [DOCDIR]
--pdfdir=DIR pdf documentation [DOCDIR]
--psdir=DIR ps documentation [DOCDIR]
X features:
--x-includes=DIR X include files are in DIR
--x-libraries=DIR X library files are in DIR
Should they be set? And if so how (especially the last 2, concerning X features)?
Moreover i see, xft support is set to yes by default, so no need to set there something. But should i enable cairo and shared libraries?
Thanks a lot in advance for your patience.
-
the configure script will probably find the X includes/libs on its own.
Since it's your extension, it's up to you what you do, but if you're going to use Xft, you might was well use cairo. You will also need the shared libs.
-
the configure script will probably find the X includes/libs on its own.
Since it's your extension, it's up to you what you do, but if you're going to use Xft, you might was well use cairo. You will also need the shared libs.
Thanks a lot Juanito!!!
For some reason, i forgot to modify my msg before: I wanted to ask as well for webkitfltk.
1. I see it pulls in the fltk-1.3-dev extension. Does the dev extension conflict with fltk-1.3.tcz or does i take its place (in other words: I would have to build my own -dev extension not the normal one)?
2. Would webkitfltk need to be rebuild as well? or could i use the extension as it is (from the repo)?
-
Hi emninger
-dev extensions do not interfere with non -dev extensions. They contain header files which are used by the compiler
to resolve references to symbols.
-
@rich: Thanks for the explanation (so much to learn ;) ).
When i do make with --enable-cairo and --enable-cairoext (is this needed for xft support or would --enable-cairo be sufficient?) i'm getting this error:
Compiling Fl_Window_shape.cxx...
Fl_Window_shape.cxx: In member function 'virtual void Fl_Window::draw()':
Fl_Window_shape.cxx:399:3: error: 'cairo_make_current' is not a member of 'Fl'
Fl::cairo_make_current(this); // checkout if an update is necessary
^
../makeinclude:149: recipe for target 'Fl_Window_shape.o' failed
make[1]: *** [Fl_Window_shape.o] Error 1
Makefile:24: recipe for target 'all' failed
make: *** [all] Error 1
-
what benefit does cairo provide in combination with an other graphics toolkit?
I have a dillo version here that is linked against libxft but without cairo.
-
@hiro: Juanito told me
but if you're going to use Xft, you might was well use cairo. You will also need the shared libs.
-
Would webkitfltk need to be rebuild as well? or could i use the extension as it is (from the repo)?
As far as I know, the webkitfltk-dev extension is only of use to compile fifth - webkitfltk uses fltk-1.3 and cairo, but I don't know if it would use the additional Xft functionality (and any possible cairo functionality) from your myfltk-1.3 extension or not.
Maybe curaga knows more?
BTW webkitfltk takes 40 mins to compile using 4 cores of an intel i7...
-
No need to enable cairo support in FLTK. It's only used by specific FLTK apps, it doesn't affect font handling, drawing or anything else.
Fifth uses FLTK only for the tabs, menus, and popup windows, so fonts in those would look better. No change in websites themselves.
-
Would webkitfltk need to be rebuild as well? or could i use the extension as it is (from the repo)?
As far as I know, the webkitfltk-dev extension is only of use to compile fifth - webkitfltk uses fltk-1.3 and cairo, but I don't know if it would use the additional Xft functionality (and any possible cairo functionality) from your myfltk-1.3 extension or not.
Maybe curaga knows more?
BTW webkitfltk takes 40 mins to compile using 4 cores of an intel i7...
Figure out on a poor machine ... ;) :D
Thanks for the explanation!
-
No need to enable cairo support in FLTK. It's only used by specific FLTK apps, it doesn't affect font handling, drawing or anything else.
Fifth uses FLTK only for the tabs, menus, and popup windows, so fonts in those would look better. No change in websites themselves.
Ok.
I'd point rather to dillo than fifth. In fifth there are 2 major issues missing, for my taste: configure a proxy inside and home button. Or am i missing something.
In any case, i'd use either dillo or fifth only as "fallback" browser (like i was used to use midori in other distros).
-
Yes, a proxy has to be currently configured on the command line, see the included docs. There's no home button as I mainly use the ctrl-space hotkey (which you can of course rebind).
-
Trying to start fifth i get this error msg
~$ fifth
Detected stale lock file, but no crash report?
Failed reading
??
PS. Solved that by deleting $HOME/.fifth
-
Yes, a proxy has to be currently configured on the command line, see the included docs.
What do you mean by this? Which included docs? I do not see anything safe some small lines given by fifth -h ... ?
-
/usr/local/share/fifth/proxy in the fifth.tcz extension.
-
/usr/local/share/fifth/proxy in the fifth.tcz extension.
Super! Now, is there a way to define a proxy for http and https ?
-
See man curl.