Can't get the text to display for hello world example
417 views
Skip to first unread message
bogdanul2003
Mar 20, 2015, 5:31:41 PM3/20/15
to fltkg...@googlegroups.com
Hi,
I managed to compile fltk for openwrt with nano-X and nxlib with --disable-xft flag during configuration.
I run this simple hello world example :
#include <FL/Fl.H>#include <FL/Fl_Window.H>#include <FL/Fl_Box.H>#include <microwin/nano-X.h>
int main(int argc, char **argv) { Fl_Window *window = new Fl_Window(0,0,200,150); Fl_Box *box = new Fl_Box(10,10,180,100,"Hello, World!"); box->box(FL_UP_BOX); box->labelsize(10); window->end(); window->show(argc, argv); return Fl::run();}I get the main window and the box displayed on my 240x320 tft display, but the the text doesn't show up on the box.
Do you have any hints? What should I check ?
Thanks,
Bogdan
imm
Mar 20, 2015, 6:15:50 PM3/20/15
to general fltk
Bogdan,
There are some notes on font issues in that howto that I linked to previously.
What you are seeing sounds very similar so the suggestions there may help you.
Let us know how you get on!
Cheers...
--
Ian
Sent, perhaps surprisingly, from my Fairphone FP1
--
You received this message because you are subscribed to the Google Groups "fltk.general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkgeneral...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
bogdanul2003
Mar 21, 2015, 4:46:17 PM3/21/15
to fltkg...@googlegroups.com
I never worked with fonts before ... a quick search on google based on your article made found fonts.dir and fonts.alis files. Here are their content:
Do you know where I should find the files specified in fonts.dir ? I can't find any of them on my openwrt image.
Enter code here...196x13-ISO8859-1.pcf.gz fixed
6x13-ISO8859-1.pcf.gz 6x13
6x13B-ISO8859-1.pcf.gz 6x13bold
6x13-ISO8859-1.pcf.gz -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso8859-1
6x13B-ISO8859-1.pcf.gz -misc-fixed-bold-r-semicondensed--13-120-75-75-c-60-iso8859-1
ariblk.ttf -monotype-arial black-medium-r-normal--0-0-0-0-p-0-iso8859-1
arial.ttf -adobe-helvetica-medium-r-normal--0-0-0-0-p-0-iso8859-1
arialb.ttf -adobe-helvetica-bold-r-normal--0-0-0-0-p-0-iso8859-1
ariali.ttf -adobe-helvetica-medium-o-normal--0-0-0-0-p-0-iso8859-1
arialz.ttf -adobe-helvetica-bold-o-normal--0-0-0-0-p-0-iso8859-1
cour.ttf -adobe-courier-medium-r-normal--0-0-0-0-m-0-iso8859-1
courb.ttf -adobe-courier-bold-r-normal--0-0-0-0-m-0-iso8859-1
couri.ttf -adobe-courier-medium-o-normal--0-0-0-0-m-0-iso8859-1
courz.ttf -adobe-courier-bold-o-normal--0-0-0-0-m-0-iso8859-1
times.ttf -adobe-times-medium-r-normal--0-0-0-0-p-0-iso8859-1
timesb.ttf -adobe-times-bold-r-normal--0-0-0-0-p-0-iso8859-1
timesi.ttf -adobe-times-medium-i-normal--0-0-0-0-p-0-iso8859-1
timesz.ttf -adobe-times-bold-i-normal--0-0-0-0-p-0-iso8859-1
cursor.pcf.gz cursor
boil@boil-Lenovo-B590:~/Documents/opewrt/openwrt$ cat ./build_dir/target-mips_34kc_uClibc-0.9.33.2/Xorg/nxlib-20100612/fonts/fonts.alias ! fonts.alias filefixed 6x13Ian MacArthur
Mar 21, 2015, 6:40:07 PM3/21/15
to fltkg...@googlegroups.com
On Sat Mar 21 2015 20:46:17, bogdanul2003 wrote:
> I never worked with fonts before ... a quick search on google based on your article made found fonts.dir and fonts.alis files. Here are their content:
<snip>
> I never worked with fonts before ... a quick search on google based on your article made found fonts.dir and fonts.alis files. Here are their content:
> boil@boil-Lenovo-B590:~/Documents/opewrt/openwrt$ cat ./build_dir/target-mips_34kc_uClibc-0.9.33.2/Xorg/nxlib-20100612/fonts/fonts.alias
> ! fonts.alias file
> fixed 6x13
>
> Do you know where I should find the files specified in fonts.dir ? I can't find any of them on my openwrt image.
If not, that might explain your problem.
Also, note that micorwindows/nxlib has ways of using “its own” fonts too that might be worth investigating, depending on what your intended usage is...
Georg Potthast
Mar 22, 2015, 3:47:21 AM3/22/15
to fltkg...@googlegroups.com
Yes, it seems that you are missing fonts or nxlib cannot find them. Here are some points to check:
- as Ian said, are there any truetype fonts installed on your system at all?
- do you link with -lfreetype?
- if there are fonts, are these the ones FLTK is looking for?
See fltk/src/fl_font_x.cxx for a list of these fonts. You can also modify this list and recompile FLTK.
- where are your fonts located? Look at nxlib/fontlist.c for the directories that are searched by nxlib.
- you can add a fonts.alias file as I do in my Nanolinux distro. I just have three DejaVuSans*.ttf plus
two cour*.ttf files in there and map all fonts FLTK asks for to these. This fonts.alias file is in my
/usr/local/share/fonts/dejavu folder.
Here is what it looks like:
fixed -misc-dejavu sans-medium-r-normal--0-0-0-0-p-0-iso10646-1
-*-helvetica-medium-r-normal--* -misc-dejavu sans-medium-r-normal--0-0-0-0-p-0-iso10646-1
-*-helvetica-bold-r-normal--* -misc-dejavu sans-bold-r-normal--0-0-0-0-p-0-iso10646-1
-*-helvetica-medium-o-normal--* -misc-dejavu sans-medium-o-normal--0-0-0-0-p-0-iso10646-1
-*-helvetica-bold-o-normal--* -misc-dejavu sans-bold-r-normal--0-0-0-0-p-0-iso10646-1
-*-courier-medium-o-normal--* -*-courier-medium-r-normal--0-0-0-0-p-0-iso10646-1
-*-courier-bold-o-normal--* -*-courier-bold-r-normal--0-0-0-0-p-0-iso10646-1
-*-times-medium-r-normal--* -misc-dejavu sans-medium-r-normal--0-0-0-0-p-0-iso10646-1
-*-times-bold-r-normal--* -misc-dejavu sans-bold-r-normal--0-0-0-0-p-0-iso10646-1
-*-times-medium-i-normal--* -misc-dejavu sans-medium-o-normal--0-0-0-0-p-0-iso10646-1
-*-times-bold-i-normal--* -misc-dejavu sans-bold-o-normal--0-0-0-0-p-0-iso10646-1
-*-symbol-*
-*-lucidatypewriter-medium-r-normal-sans-* -misc-dejavu sans-medium-r-normal--0-0-0-0-p-0-iso10646-1
-*-lucidatypewriter-bold-r-normal-sans-* -misc-dejavu sans-bold-r-normal--0-0-0-0-p-0-iso10646-1
-*-*zapf dingbats-*
I am sure you should improve this fonts.alias file and see what remarks I get ;-)
- as Ian said, are there any truetype fonts installed on your system at all?
- do you link with -lfreetype?
- if there are fonts, are these the ones FLTK is looking for?
See fltk/src/fl_font_x.cxx for a list of these fonts. You can also modify this list and recompile FLTK.
- where are your fonts located? Look at nxlib/fontlist.c for the directories that are searched by nxlib.
- you can add a fonts.alias file as I do in my Nanolinux distro. I just have three DejaVuSans*.ttf plus
two cour*.ttf files in there and map all fonts FLTK asks for to these. This fonts.alias file is in my
/usr/local/share/fonts/dejavu folder.
Here is what it looks like:
fixed -misc-dejavu sans-medium-r-normal--0-0-0-0-p-0-iso10646-1
-*-helvetica-medium-r-normal--* -misc-dejavu sans-medium-r-normal--0-0-0-0-p-0-iso10646-1
-*-helvetica-bold-r-normal--* -misc-dejavu sans-bold-r-normal--0-0-0-0-p-0-iso10646-1
-*-helvetica-medium-o-normal--* -misc-dejavu sans-medium-o-normal--0-0-0-0-p-0-iso10646-1
-*-helvetica-bold-o-normal--* -misc-dejavu sans-bold-r-normal--0-0-0-0-p-0-iso10646-1
-*-courier-medium-o-normal--* -*-courier-medium-r-normal--0-0-0-0-p-0-iso10646-1
-*-courier-bold-o-normal--* -*-courier-bold-r-normal--0-0-0-0-p-0-iso10646-1
-*-times-medium-r-normal--* -misc-dejavu sans-medium-r-normal--0-0-0-0-p-0-iso10646-1
-*-times-bold-r-normal--* -misc-dejavu sans-bold-r-normal--0-0-0-0-p-0-iso10646-1
-*-times-medium-i-normal--* -misc-dejavu sans-medium-o-normal--0-0-0-0-p-0-iso10646-1
-*-times-bold-i-normal--* -misc-dejavu sans-bold-o-normal--0-0-0-0-p-0-iso10646-1
-*-symbol-*
-*-lucidatypewriter-medium-r-normal-sans-* -misc-dejavu sans-medium-r-normal--0-0-0-0-p-0-iso10646-1
-*-lucidatypewriter-bold-r-normal-sans-* -misc-dejavu sans-bold-r-normal--0-0-0-0-p-0-iso10646-1
-*-*zapf dingbats-*
I am sure you should improve this fonts.alias file and see what remarks I get ;-)
bogdanul2003
Mar 23, 2015, 5:52:43 PM3/23/15
to fltkg...@googlegroups.com
Thanks for your answers. I think my problem is that I don't see the big picture. Who handles the fonts? nanox, nxlib or fltk ?
What is the flow of operations when FLTK wants to write some text ?
I see that nxlib searches for fonts in these folders:/usr/share/fonts/X11/100dpi /usr/share/fonts/X11/misc /usr/share/fonts/X11/TTF
These folders don't exit on my opnewrt router so I think that I have no fonts installed
I looked in the nxlib source directory but I can't find any fonts there.
I looked in microwin( nanox) folder and I found a lot of font folders and fonts:
boil@boil-Lenovo-B590:~/Documents/opewrt/openwrt/build_dir/target-mips_34kc_uClibc-0.9.33.2/Xorg/microwin-20100612/src/fonts$ tree.├── bdf│ ├── gb24st.bdf│ ├── helvB10.bdf│ ├── helvB12.bdf│ ├── helvR10.bdf│ ├── jiskan24.bdf│ ├── lubI24.bdf│ ├── symb18.bdf│ ├── timBI18.bdf│ └── X5x7.bdf├── chinese│ ├── asc12│ ├── asc16│ ├── BG2UBG.KU│ ├── big5font.c│ ├── gb16x16song.c│ ├── gb2312font.c│ ├── gbk16-xke.bdf│ ├── hzk12│ ├── hzk16│ ├── hzx12│ ├── hzx16│ ├── packhz12.c│ └── UGB2GB.KU├── convbdf.c├── fnt│ └── timBI18.fnt├── japanese│ ├── jiskan16-2000-1.bdf│ ├── jisx0213-12x12.c│ ├── jisx0213-16x16.c│ ├── K12-1.bdf│ ├── k12x10.fnt│ ├── k12x12.fnt│ ├── k16x16.fnt│ └── k24x24.fnt├── korean│ ├── jo16x16.c│ └── ksjo_tbl.c├── Makefile├── nano-X.cfg├── Objects.rules├── pcf│ ├── 6x13.pcf.gz│ ├── 7x14.pcf.gz│ ├── 9x15.pcf.gz│ ├── gb24st.pcf.gz│ ├── helvB12_lin.pcf.gz│ ├── helvB12.pcf.gz│ ├── jiskan24.pcf.gz│ ├── lubI24.pcf│ ├── symb18.pcf│ └── vga.pcf.gz├── rom8x16.c├── rom8x8.c├── tools│ ├── convbdf.pl│ ├── convfnt32.exe│ ├── convfnt.c│ ├── convfnt.def│ ├── convfnt.mak│ ├── convfnt.rc│ ├── convrom.c│ └── convrom.mak├── truetype│ ├── accid___.ttf│ ├── arialb.ttf│ ├── ariali.ttf│ ├── arial.ttf│ ├── arialz.ttf│ ├── ariblk.ttf│ ├── comicbd.ttf│ ├── comic.ttf│ ├── courb.ttf│ ├── couri.ttf│ ├── cour.ttf│ ├── courz.ttf│ ├── DejaVuSansMono.ttf│ ├── encodings.dir│ ├── fonts.dir│ ├── fonts.dir.pseudoadobe│ ├── FONTS.txt│ ├── impact.ttf│ ├── License.wri│ ├── lt1-bi-omega-serif.ttf│ ├── lt1-b-omega-serif.ttf│ ├── lt1-i-omega-serif.ttf│ ├── lt1-r-omega-serif.ttf│ ├── lt2-bi-omega-serif.ttf│ ├── lt2-b-omega-serif.ttf│ ├── lt2-i-omega-serif.ttf│ ├── lt2-r-omega-serif.ttf│ ├── lt3-bi-omega-serif.ttf│ ├── lt3-b-omega-serif.ttf│ ├── lt3-i-omega-serif.ttf│ ├── lt3-r-omega-serif.ttf│ ├── lt4-bi-omega-serif.ttf│ ├── lt4-b-omega-serif.ttf│ ├── lt4-i-omega-serif.ttf│ ├── lt4-r-omega-serif.ttf│ ├── lt5-bi-omega-serif.ttf│ ├── lt5-b-omega-serif.ttf│ ├── lt5-i-omega-serif.ttf│ ├── lt5-r-omega-serif.ttf│ ├── readme.ms│ ├── readme.omega│ ├── readme.tm│ ├── readme.txt│ ├── timesb.ttf│ ├── timesi.ttf│ ├── times.ttf│ ├── timesz.ttf│ ├── VAGROLN.TTF│ └── viscii-omega-serif.ttf├── type1│ ├── bchb.afm│ ├── bchbi.afm│ ├── bchbi.pfb│ ├── bchb.pfb│ ├── bchr.afm│ ├── bchri.afm│ ├── bchri.pfb│ ├── bchr.pfb│ ├── c0419bt_.afm│ ├── c0419bt_.pfb│ ├── c0582bt_.afm│ ├── c0582bt_.pfb│ ├── c0583bt_.afm│ ├── c0583bt_.pfb│ ├── c0611bt_.afm│ ├── c0611bt_.pfb│ ├── c0632bt_.afm│ ├── c0632bt_.pfb│ ├── c0633bt_.afm│ ├── c0633bt_.pfb│ ├── c0648bt_.afm│ ├── c0648bt_.pfb│ ├── c0649bt_.afm│ ├── c0649bt_.pfb│ ├── Copyright│ ├── Copyright.IBM│ ├── cour.afm│ ├── courb.afm│ ├── courbi.afm│ ├── courbi.pfa│ ├── courb.pfa│ ├── couri.afm│ ├── couri.pfa│ ├── cour.pfa│ ├── dcbx10.afm│ ├── dcbx10.pfb│ ├── dcbxti10.afm│ ├── dcbxti10.pfb│ ├── dcr10.afm│ ├── dcr10.pfb│ ├── dcti10.afm│ ├── dcti10.pfb│ ├── eufm10.afm│ ├── eufm10.pfb│ ├── FontDataBase│ ├── fonts.scale│ ├── IsoLatin1.enc│ ├── IsoLatin2.enc│ ├── PSLatin1.enc│ ├── README│ ├── t1lib.config│ ├── UTB_____.afm│ ├── UTBI____.afm│ ├── UTBI____.pfa│ ├── UTB_____.pfa│ ├── UTI_____.afm│ ├── UTI_____.pfa│ ├── UTRG____.afm│ └── UTRG____.pfa├── winFreeSansSerif11x13.c├── winFreeSansSerif11x13.fon├── winFreeSystem14x16.c├── winFreeSystem14x16.fon└── X6x13.bdf
9 directories, 170 files
What is the flow of operations when FLTK wants to write some text ?
I also found some references in the code from nxlib to fonts.dir, is this also an important file ?
I'll have to copy the fonts from nano-x source code to the folders that nxlib is searching for on my router? Where should I copy fonts.dir (if it is needed) and fonts.alias ?
Thanks.
Georg Potthast
Mar 24, 2015, 3:09:37 AM3/24/15
to fltkg...@googlegroups.com
I use truetype fonts with NXlib/FLTK so I currently cannot tell if the fonts that you have listed and which are included with Microwindows can be used for FLTK. I used these fonts with the demo programs included with Microwindows only. You do not need to copy these to the openwrt router, NXlib will work with the truetype fonts that "come" with that Linux distribution.
If there are no truetype fonts on the openwrt router, NXlib will have problems finding fonts! You should install these from the openwrt repo if that exists, so they can be used with NXlib.
The fontlist.c program lists the directories searched for fonts:
char *FONT_DIR_LIST[] = {
"fonts", /* local font dir w/fonts.alias*/
"/usr/share/fonts/X11/misc", /* pcf fonts w/fonts.dir*/
"/usr/share/fonts/X11/100dpi",
"/usr/share/fonts/truetype/freefont", /* truetype fonts, no fonts.dir*/
"/usr/share/fonts/truetype/ttf-dejavu",
"/usr/share/fonts/truetype/openoffice",
"/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType", /* truetype fonts, w/fonts.dir & fonts.scale*/
"/usr/share/fonts/X11/Type1", /* t1lib type1 .pfb fonts, w/fonts.dir*/
0
};
You can add additional directories here if the fonts are in a different directory on the openwrt router.
The directory that includes the fonts should have the fonts.dir and fonts.alias file. But that has to be in the list above so NXlib finds the fonts and these files. The fonts.dir file is usually always included with the fonts in a directory when you download these. It is a list of the availble fonts. You will find an example in your current development Linux system.
As you see in the list, you could also make a local "fonts" directory in your current directory on the openwrt router with the required fonts and fonts.dir and fonts.alias. I sometimes do that if I only want to use a few fonts and then edit fonts.dir and fonts.alias by hand.
MacArthur, Ian (Selex ES, UK)
Mar 24, 2015, 5:45:45 AM3/24/15
to fltkg...@googlegroups.com
> Thanks for your answers. I think my problem is that I don't see the big
> picture.
Font handling is tricky... If you really want to understand it, you probably have a lot of reading ahead of you. Start googling around to learn how X11 does it, then compare that with what nanoX does, and...
> picture.
> Who handles the fonts? nanox, nxlib or fltk ?
Fltk just thinks it is talking to an Xserver in the way that it would on any "normal" X11/*nix system.
Fltk doesn't handle fonts as such, it just asks the Xserver for fonts, and so in this case it is nanox that is doing the work, with nxlib providing the interface between nanox and fltk. Well, more or less...
Also, harking back to a question that Georg asked earlier; are you linking with freetype or not in your build? This is important as it significantly effects what fonts you can use and how they will be rendered. I don't remember if you answered that one, and if you did, what the answer was.
[This also takes us into a potentially slightly weird corner of nxlib: with a "real" Xserver, if you use truetype fonts, they are usually accessed via the XFT interface, which differs very significantly from the basic Xlib font interface (fltk knows both API's, but the choice must be made at compile time!) However, nanox/nxlib, if linked with freetype, will render truetype fonts correctly, but nxlib exposes them via an interface that looks the same as the stock Xlib font interface, not via an XFT like interface. So, I would recommend that you build nanox/nxlib with freetype, and build fltk against that *without* XFT. Which works, but just feels a bit weird to me...]
> I see that nxlib searches for fonts in these
> folders:
> /usr/share/fonts/X11/100dpi
> /usr/share/fonts/X11/misc
Likely to be a mixture of stuff, including some scalable fonts, type1 fonts, etc.
> /usr/share/fonts/X11/TTF
Likely to be truetuype fonts, you want something in here!
> These folders don't exit on my opnewrt router so I think that I have no
> fonts installed
> I looked in the nxlib source directory but I can't find any fonts there.
It's not really nxlibs problem, it just provides the API.
> I looked in microwin( nanox) folder and I found a lot of font folders
> and fonts:
> What is the flow of operations when FLTK wants to write some text ?
When your application starts, the fltk core (in your app) enumerates a few basic fonts that it will use; these are hard coded in the fltk code, and once you do actually have some fonts installed, it might be worth while to hand-edit that list to match fonts that you actually have!
It enumerates the fonts by asking the server (nanox in this case) for them.
If the server can't find a font with the name you ask for, it looks in its font alias file to see if there is another font listed as being a suitable substitute for the one you requested.
If no suitable font is found, you either get some fallback "last resort" font, or (as seems to be happening in your case) nothing at all...
When your application actually draws some text, fltk prepares the formatted string for rendering, then passes this to the server; again it is the server (using freetype if you have it built in) that draws the actual pixels onto the display, based on the font face info in the font file.
So, anyway: install some TTF fonts, and maybe tweak your nanox/nxlib font search path to make sure it looks in directories where you have ttf fonts installed.
Also make sure to link your nanox/nxlib with freetype, it does a better job of font rendering!
Then hand-edit fltk's fl_font_x.cxx to modify the Fl_Fontdesc built_in_table[] to list the names of fonts you actually have on your system (thereby alleviating any concern about what fonts.alis needs to do!)
E.g., if there's an entry like:
"-*-helvetica-medium-r-normal--*"
and you don't have a Helvetica face installed, changing it to something like:
"-*- arial-medium-r-normal--*"
would probably work (I note from your post that microwin does have some ttf Arial faces available, for example.)
And so on...
Selex ES Ltd
Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL
A company registered in England & Wales. Company no. 02426132
********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************
bogdanul2003
Mar 24, 2015, 11:12:36 AM3/24/15
to fltkg...@googlegroups.com
Thanks guys, I'll give it a try as soon as possible and come back with the results. And to answer the freetype question: I use libfreetype when compiling Nxlib and nanox
bogdanul2003
Mar 27, 2015, 2:20:18 PM3/27/15
to fltkg...@googlegroups.com, ian.ma...@selex-es.com
I did some progress:
The generated fonts.dir looks like this:
I copied this generated fonts.dir to my router where the trutype fonts are installed and executed the hello world application which looks like this:
- I installed truetype and dejavu fonts on my openwrt router
- modified Fl_Fontdesc built_in_table[] to point to the correct fonts
- modified char *NXDIRLIST[] from font.c to include the directory of truetype fonts
The installation of fonts on the openwrt router came without a fonts.dir file and I had to generate it using this commands:
cd ./build_dir/target-mips_34kc_uClibc-0.9.33.2/root-ar71xx/usr/share/fonts/truetype/liberation/
ttmkfdir > fonts.scale
mkfontdir
The generated fonts.dir looks like this:
168LiberationMono-Bold.ttf -misc-liberation mono-bold-r-normal--0-0-0-0-m-0-ascii-0LiberationMono-Bold.ttf -misc-liberation mono-bold-r-normal--0-0-0-0-m-0-iso10646-1LiberationMono-Bold.ttf -misc-liberation mono-bold-r-normal--0-0-0-0-m-0-iso8859-1LiberationMono-Bold.ttf -misc-liberation mono-bold-r-normal--0-0-0-0-m-0-iso8859-10LiberationMono-Bold.ttf -misc-liberation mono-bold-r-normal--0-0-0-0-m-0-iso8859-13LiberationMono-Bold.ttf -misc-liberation mono-bold-r-normal--0-0-0-0-m-0-iso8859-15LiberationMono-Bold.ttf -misc-liberation mono-bold-r-normal--0-0-0-0-m-0-iso8859-2LiberationMono-Bold.ttf -misc-liberation mono-bold-r-normal--0-0-0-0-m-0-iso8859-3LiberationMono-Bold.ttf -misc-liberation mono-bold-r-normal--0-0-0-0-m-0-iso8859-4LiberationMono-Bold.ttf -misc-liberation mono-bold-r-normal--0-0-0-0-m-0-iso8859-5LiberationMono-Bold.ttf -misc-liberation mono-bold-r-normal--0-0-0-0-m-0-iso8859-7LiberationMono-Bold.ttf -misc-liberation mono-bold-r-normal--0-0-0-0-m-0-iso8859-9LiberationMono-Bold.ttf -misc-liberation mono-bold-r-normal--0-0-0-0-m-0-koi8-rLiberationMono-Bold.ttf -misc-liberation mono-bold-r-normal--0-0-0-0-m-0-koi8-ruLiberationMono-BoldItalic.ttf -misc-liberation mono-bold-i-normal--0-0-0-0-m-0-ascii-0LiberationMono-BoldItalic.ttf -misc-liberation mono-bold-i-normal--0-0-0-0-m-0-iso10646-1LiberationMono-BoldItalic.ttf -misc-liberation mono-bold-i-normal--0-0-0-0-m-0-iso8859-1LiberationMono-BoldItalic.ttf -misc-liberation mono-bold-i-normal--0-0-0-0-m-0-iso8859-10LiberationMono-BoldItalic.ttf -misc-liberation mono-bold-i-normal--0-0-0-0-m-0-iso8859-13LiberationMono-BoldItalic.ttf -misc-liberation mono-bold-i-normal--0-0-0-0-m-0-iso8859-15LiberationMono-BoldItalic.ttf -misc-liberation mono-bold-i-normal--0-0-0-0-m-0-iso8859-2LiberationMono-BoldItalic.ttf -misc-liberation mono-bold-i-normal--0-0-0-0-m-0-iso8859-3LiberationMono-BoldItalic.ttf -misc-liberation mono-bold-i-normal--0-0-0-0-m-0-iso8859-4LiberationMono-BoldItalic.ttf -misc-liberation mono-bold-i-normal--0-0-0-0-m-0-iso8859-5LiberationMono-BoldItalic.ttf -misc-liberation mono-bold-i-normal--0-0-0-0-m-0-iso8859-7LiberationMono-BoldItalic.ttf -misc-liberation mono-bold-i-normal--0-0-0-0-m-0-iso8859-9LiberationMono-BoldItalic.ttf -misc-liberation mono-bold-i-normal--0-0-0-0-m-0-koi8-rLiberationMono-BoldItalic.ttf -misc-liberation mono-bold-i-normal--0-0-0-0-m-0-koi8-ruLiberationMono-Italic.ttf -misc-liberation mono-medium-i-normal--0-0-0-0-m-0-ascii-0LiberationMono-Italic.ttf -misc-liberation mono-medium-i-normal--0-0-0-0-m-0-iso10646-1LiberationMono-Italic.ttf -misc-liberation mono-medium-i-normal--0-0-0-0-m-0-iso8859-1LiberationMono-Italic.ttf -misc-liberation mono-medium-i-normal--0-0-0-0-m-0-iso8859-10LiberationMono-Italic.ttf -misc-liberation mono-medium-i-normal--0-0-0-0-m-0-iso8859-13LiberationMono-Italic.ttf -misc-liberation mono-medium-i-normal--0-0-0-0-m-0-iso8859-15LiberationMono-Italic.ttf -misc-liberation mono-medium-i-normal--0-0-0-0-m-0-iso8859-2LiberationMono-Italic.ttf -misc-liberation mono-medium-i-normal--0-0-0-0-m-0-iso8859-3LiberationMono-Italic.ttf -misc-liberation mono-medium-i-normal--0-0-0-0-m-0-iso8859-4LiberationMono-Italic.ttf -misc-liberation mono-medium-i-normal--0-0-0-0-m-0-iso8859-5LiberationMono-Italic.ttf -misc-liberation mono-medium-i-normal--0-0-0-0-m-0-iso8859-7LiberationMono-Italic.ttf -misc-liberation mono-medium-i-normal--0-0-0-0-m-0-iso8859-9LiberationMono-Italic.ttf -misc-liberation mono-medium-i-normal--0-0-0-0-m-0-koi8-rLiberationMono-Italic.ttf -misc-liberation mono-medium-i-normal--0-0-0-0-m-0-koi8-ruLiberationMono-Regular.ttf -misc-liberation mono-medium-r-normal--0-0-0-0-m-0-ascii-0LiberationMono-Regular.ttf -misc-liberation mono-medium-r-normal--0-0-0-0-m-0-iso10646-1LiberationMono-Regular.ttf -misc-liberation mono-medium-r-normal--0-0-0-0-m-0-iso8859-1LiberationMono-Regular.ttf -misc-liberation mono-medium-r-normal--0-0-0-0-m-0-iso8859-10LiberationMono-Regular.ttf -misc-liberation mono-medium-r-normal--0-0-0-0-m-0-iso8859-13LiberationMono-Regular.ttf -misc-liberation mono-medium-r-normal--0-0-0-0-m-0-iso8859-15LiberationMono-Regular.ttf -misc-liberation mono-medium-r-normal--0-0-0-0-m-0-iso8859-2LiberationMono-Regular.ttf -misc-liberation mono-medium-r-normal--0-0-0-0-m-0-iso8859-3LiberationMono-Regular.ttf -misc-liberation mono-medium-r-normal--0-0-0-0-m-0-iso8859-4LiberationMono-Regular.ttf -misc-liberation mono-medium-r-normal--0-0-0-0-m-0-iso8859-5LiberationMono-Regular.ttf -misc-liberation mono-medium-r-normal--0-0-0-0-m-0-iso8859-7LiberationMono-Regular.ttf -misc-liberation mono-medium-r-normal--0-0-0-0-m-0-iso8859-9LiberationMono-Regular.ttf -misc-liberation mono-medium-r-normal--0-0-0-0-m-0-koi8-rLiberationMono-Regular.ttf -misc-liberation mono-medium-r-normal--0-0-0-0-m-0-koi8-ruLiberationSans-Bold.ttf -misc-liberation sans-bold-r-normal--0-0-0-0-p-0-ascii-0LiberationSans-Bold.ttf -misc-liberation sans-bold-r-normal--0-0-0-0-p-0-iso10646-1LiberationSans-Bold.ttf -misc-liberation sans-bold-r-normal--0-0-0-0-p-0-iso8859-1LiberationSans-Bold.ttf -misc-liberation sans-bold-r-normal--0-0-0-0-p-0-iso8859-10LiberationSans-Bold.ttf -misc-liberation sans-bold-r-normal--0-0-0-0-p-0-iso8859-13LiberationSans-Bold.ttf -misc-liberation sans-bold-r-normal--0-0-0-0-p-0-iso8859-15LiberationSans-Bold.ttf -misc-liberation sans-bold-r-normal--0-0-0-0-p-0-iso8859-2LiberationSans-Bold.ttf -misc-liberation sans-bold-r-normal--0-0-0-0-p-0-iso8859-3LiberationSans-Bold.ttf -misc-liberation sans-bold-r-normal--0-0-0-0-p-0-iso8859-4LiberationSans-Bold.ttf -misc-liberation sans-bold-r-normal--0-0-0-0-p-0-iso8859-5LiberationSans-Bold.ttf -misc-liberation sans-bold-r-normal--0-0-0-0-p-0-iso8859-7LiberationSans-Bold.ttf -misc-liberation sans-bold-r-normal--0-0-0-0-p-0-iso8859-9LiberationSans-Bold.ttf -misc-liberation sans-bold-r-normal--0-0-0-0-p-0-koi8-rLiberationSans-Bold.ttf -misc-liberation sans-bold-r-normal--0-0-0-0-p-0-koi8-ruLiberationSans-BoldItalic.ttf -misc-liberation sans-bold-i-normal--0-0-0-0-p-0-ascii-0LiberationSans-BoldItalic.ttf -misc-liberation sans-bold-i-normal--0-0-0-0-p-0-iso10646-1LiberationSans-BoldItalic.ttf -misc-liberation sans-bold-i-normal--0-0-0-0-p-0-iso8859-1LiberationSans-BoldItalic.ttf -misc-liberation sans-bold-i-normal--0-0-0-0-p-0-iso8859-10LiberationSans-BoldItalic.ttf -misc-liberation sans-bold-i-normal--0-0-0-0-p-0-iso8859-13LiberationSans-BoldItalic.ttf -misc-liberation sans-bold-i-normal--0-0-0-0-p-0-iso8859-15LiberationSans-BoldItalic.ttf -misc-liberation sans-bold-i-normal--0-0-0-0-p-0-iso8859-2LiberationSans-BoldItalic.ttf -misc-liberation sans-bold-i-normal--0-0-0-0-p-0-iso8859-3LiberationSans-BoldItalic.ttf -misc-liberation sans-bold-i-normal--0-0-0-0-p-0-iso8859-4LiberationSans-BoldItalic.ttf -misc-liberation sans-bold-i-normal--0-0-0-0-p-0-iso8859-5LiberationSans-BoldItalic.ttf -misc-liberation sans-bold-i-normal--0-0-0-0-p-0-iso8859-7LiberationSans-BoldItalic.ttf -misc-liberation sans-bold-i-normal--0-0-0-0-p-0-iso8859-9LiberationSans-BoldItalic.ttf -misc-liberation sans-bold-i-normal--0-0-0-0-p-0-koi8-rLiberationSans-BoldItalic.ttf -misc-liberation sans-bold-i-normal--0-0-0-0-p-0-koi8-ruLiberationSans-Italic.ttf -misc-liberation sans-medium-i-normal--0-0-0-0-p-0-ascii-0LiberationSans-Italic.ttf -misc-liberation sans-medium-i-normal--0-0-0-0-p-0-iso10646-1LiberationSans-Italic.ttf -misc-liberation sans-medium-i-normal--0-0-0-0-p-0-iso8859-1LiberationSans-Italic.ttf -misc-liberation sans-medium-i-normal--0-0-0-0-p-0-iso8859-10LiberationSans-Italic.ttf -misc-liberation sans-medium-i-normal--0-0-0-0-p-0-iso8859-13LiberationSans-Italic.ttf -misc-liberation sans-medium-i-normal--0-0-0-0-p-0-iso8859-15LiberationSans-Italic.ttf -misc-liberation sans-medium-i-normal--0-0-0-0-p-0-iso8859-2LiberationSans-Italic.ttf -misc-liberation sans-medium-i-normal--0-0-0-0-p-0-iso8859-3LiberationSans-Italic.ttf -misc-liberation sans-medium-i-normal--0-0-0-0-p-0-iso8859-4LiberationSans-Italic.ttf -misc-liberation sans-medium-i-normal--0-0-0-0-p-0-iso8859-5LiberationSans-Italic.ttf -misc-liberation sans-medium-i-normal--0-0-0-0-p-0-iso8859-7LiberationSans-Italic.ttf -misc-liberation sans-medium-i-normal--0-0-0-0-p-0-iso8859-9LiberationSans-Italic.ttf -misc-liberation sans-medium-i-normal--0-0-0-0-p-0-koi8-rLiberationSans-Italic.ttf -misc-liberation sans-medium-i-normal--0-0-0-0-p-0-koi8-ruLiberationSans-Regular.ttf -misc-liberation sans-medium-r-normal--0-0-0-0-p-0-ascii-0LiberationSans-Regular.ttf -misc-liberation sans-medium-r-normal--0-0-0-0-p-0-iso10646-1LiberationSans-Regular.ttf -misc-liberation sans-medium-r-normal--0-0-0-0-p-0-iso8859-1LiberationSans-Regular.ttf -misc-liberation sans-medium-r-normal--0-0-0-0-p-0-iso8859-10LiberationSans-Regular.ttf -misc-liberation sans-medium-r-normal--0-0-0-0-p-0-iso8859-13LiberationSans-Regular.ttf -misc-liberation sans-medium-r-normal--0-0-0-0-p-0-iso8859-15LiberationSans-Regular.ttf -misc-liberation sans-medium-r-normal--0-0-0-0-p-0-iso8859-2LiberationSans-Regular.ttf -misc-liberation sans-medium-r-normal--0-0-0-0-p-0-iso8859-3LiberationSans-Regular.ttf -misc-liberation sans-medium-r-normal--0-0-0-0-p-0-iso8859-4LiberationSans-Regular.ttf -misc-liberation sans-medium-r-normal--0-0-0-0-p-0-iso8859-5LiberationSans-Regular.ttf -misc-liberation sans-medium-r-normal--0-0-0-0-p-0-iso8859-7LiberationSans-Regular.ttf -misc-liberation sans-medium-r-normal--0-0-0-0-p-0-iso8859-9LiberationSans-Regular.ttf -misc-liberation sans-medium-r-normal--0-0-0-0-p-0-koi8-rLiberationSans-Regular.ttf -misc-liberation sans-medium-r-normal--0-0-0-0-p-0-koi8-ruLiberationSerif-Bold.ttf -misc-liberation serif-bold-r-normal--0-0-0-0-p-0-ascii-0LiberationSerif-Bold.ttf -misc-liberation serif-bold-r-normal--0-0-0-0-p-0-iso10646-1LiberationSerif-Bold.ttf -misc-liberation serif-bold-r-normal--0-0-0-0-p-0-iso8859-1LiberationSerif-Bold.ttf -misc-liberation serif-bold-r-normal--0-0-0-0-p-0-iso8859-10LiberationSerif-Bold.ttf -misc-liberation serif-bold-r-normal--0-0-0-0-p-0-iso8859-13LiberationSerif-Bold.ttf -misc-liberation serif-bold-r-normal--0-0-0-0-p-0-iso8859-15LiberationSerif-Bold.ttf -misc-liberation serif-bold-r-normal--0-0-0-0-p-0-iso8859-2LiberationSerif-Bold.ttf -misc-liberation serif-bold-r-normal--0-0-0-0-p-0-iso8859-3LiberationSerif-Bold.ttf -misc-liberation serif-bold-r-normal--0-0-0-0-p-0-iso8859-4LiberationSerif-Bold.ttf -misc-liberation serif-bold-r-normal--0-0-0-0-p-0-iso8859-5LiberationSerif-Bold.ttf -misc-liberation serif-bold-r-normal--0-0-0-0-p-0-iso8859-7LiberationSerif-Bold.ttf -misc-liberation serif-bold-r-normal--0-0-0-0-p-0-iso8859-9LiberationSerif-Bold.ttf -misc-liberation serif-bold-r-normal--0-0-0-0-p-0-koi8-rLiberationSerif-Bold.ttf -misc-liberation serif-bold-r-normal--0-0-0-0-p-0-koi8-ruLiberationSerif-BoldItalic.ttf -misc-liberation serif-bold-i-normal--0-0-0-0-p-0-ascii-0LiberationSerif-BoldItalic.ttf -misc-liberation serif-bold-i-normal--0-0-0-0-p-0-iso10646-1LiberationSerif-BoldItalic.ttf -misc-liberation serif-bold-i-normal--0-0-0-0-p-0-iso8859-1LiberationSerif-BoldItalic.ttf -misc-liberation serif-bold-i-normal--0-0-0-0-p-0-iso8859-10LiberationSerif-BoldItalic.ttf -misc-liberation serif-bold-i-normal--0-0-0-0-p-0-iso8859-13LiberationSerif-BoldItalic.ttf -misc-liberation serif-bold-i-normal--0-0-0-0-p-0-iso8859-15LiberationSerif-BoldItalic.ttf -misc-liberation serif-bold-i-normal--0-0-0-0-p-0-iso8859-2LiberationSerif-BoldItalic.ttf -misc-liberation serif-bold-i-normal--0-0-0-0-p-0-iso8859-3LiberationSerif-BoldItalic.ttf -misc-liberation serif-bold-i-normal--0-0-0-0-p-0-iso8859-4LiberationSerif-BoldItalic.ttf -misc-liberation serif-bold-i-normal--0-0-0-0-p-0-iso8859-5LiberationSerif-BoldItalic.ttf -misc-liberation serif-bold-i-normal--0-0-0-0-p-0-iso8859-7LiberationSerif-BoldItalic.ttf -misc-liberation serif-bold-i-normal--0-0-0-0-p-0-iso8859-9LiberationSerif-BoldItalic.ttf -misc-liberation serif-bold-i-normal--0-0-0-0-p-0-koi8-rLiberationSerif-BoldItalic.ttf -misc-liberation serif-bold-i-normal--0-0-0-0-p-0-koi8-ruLiberationSerif-Italic.ttf -misc-liberation serif-medium-i-normal--0-0-0-0-p-0-ascii-0LiberationSerif-Italic.ttf -misc-liberation serif-medium-i-normal--0-0-0-0-p-0-iso10646-1LiberationSerif-Italic.ttf -misc-liberation serif-medium-i-normal--0-0-0-0-p-0-iso8859-1LiberationSerif-Italic.ttf -misc-liberation serif-medium-i-normal--0-0-0-0-p-0-iso8859-10LiberationSerif-Italic.ttf -misc-liberation serif-medium-i-normal--0-0-0-0-p-0-iso8859-13LiberationSerif-Italic.ttf -misc-liberation serif-medium-i-normal--0-0-0-0-p-0-iso8859-15LiberationSerif-Italic.ttf -misc-liberation serif-medium-i-normal--0-0-0-0-p-0-iso8859-2LiberationSerif-Italic.ttf -misc-liberation serif-medium-i-normal--0-0-0-0-p-0-iso8859-3LiberationSerif-Italic.ttf -misc-liberation serif-medium-i-normal--0-0-0-0-p-0-iso8859-4LiberationSerif-Italic.ttf -misc-liberation serif-medium-i-normal--0-0-0-0-p-0-iso8859-5LiberationSerif-Italic.ttf -misc-liberation serif-medium-i-normal--0-0-0-0-p-0-iso8859-7LiberationSerif-Italic.ttf -misc-liberation serif-medium-i-normal--0-0-0-0-p-0-iso8859-9LiberationSerif-Italic.ttf -misc-liberation serif-medium-i-normal--0-0-0-0-p-0-koi8-rLiberationSerif-Italic.ttf -misc-liberation serif-medium-i-normal--0-0-0-0-p-0-koi8-ruLiberationSerif-Regular.ttf -misc-liberation serif-medium-r-normal--0-0-0-0-p-0-ascii-0LiberationSerif-Regular.ttf -misc-liberation serif-medium-r-normal--0-0-0-0-p-0-iso10646-1LiberationSerif-Regular.ttf -misc-liberation serif-medium-r-normal--0-0-0-0-p-0-iso8859-1LiberationSerif-Regular.ttf -misc-liberation serif-medium-r-normal--0-0-0-0-p-0-iso8859-10LiberationSerif-Regular.ttf -misc-liberation serif-medium-r-normal--0-0-0-0-p-0-iso8859-13LiberationSerif-Regular.ttf -misc-liberation serif-medium-r-normal--0-0-0-0-p-0-iso8859-15LiberationSerif-Regular.ttf -misc-liberation serif-medium-r-normal--0-0-0-0-p-0-iso8859-2LiberationSerif-Regular.ttf -misc-liberation serif-medium-r-normal--0-0-0-0-p-0-iso8859-3LiberationSerif-Regular.ttf -misc-liberation serif-medium-r-normal--0-0-0-0-p-0-iso8859-4LiberationSerif-Regular.ttf -misc-liberation serif-medium-r-normal--0-0-0-0-p-0-iso8859-5LiberationSerif-Regular.ttf -misc-liberation serif-medium-r-normal--0-0-0-0-p-0-iso8859-7LiberationSerif-Regular.ttf -misc-liberation serif-medium-r-normal--0-0-0-0-p-0-iso8859-9LiberationSerif-Regular.ttf -misc-liberation serif-medium-r-normal--0-0-0-0-p-0-koi8-rLiberationSerif-Regular.ttf -misc-liberation serif-medium-r-normal--0-0-0-0-p-0-koi8-ruI copied this generated fonts.dir to my router where the trutype fonts are installed and executed the hello world application which looks like this:
#include <FL/Fl.H>#include <FL/Fl_Window.H>#include <FL/Fl_Box.H>#include <microwin/nano-X.h>
int main(int argc, char **argv) { Fl_Window *window = new Fl_Window(0,0,200,150); Fl_Box *box = new Fl_Box(10,10,180,100,"Hello, World!"); box->box(FL_UP_BOX); //box->labelsize(10); window->end(); window->show(argc, argv); return Fl::run();}The text isn't displayed and I added some extra printfs in nxlib to see what is happening.
It seems that nxlib finds the fonts.dir file and parses it and returns a list of found fonts to find_best_font() in fl_font_x.cxx Now this functions goes through the list and for some font names it modifies it's name. For example, you can find in fonts.dir that there is a font named -misc-liberation mono-medium-i-normal--0-0-0-0-m-0-iso10646-1 but this function changes it's name to -misc-liberation mono-medium-i-normal--14-0-0-0-m-0-iso10646-1 . It replaces the first 0 with 14. At the end, the function returns this modified name which is used by the caller.
I think that the reason the text is not displayed is because the name of the font is changed.
Do you know why this function find_best_font() changes the name of the font?
Thanks,
Bogdan
Georg Potthast
Mar 27, 2015, 4:40:34 PM3/27/15
to fltkg...@googlegroups.com, ian.ma...@selex-es.com
I did not look at the find_best_font() function yet, but I think the problem has a different cause. You now just have liberation fonts available and FLTK is not looking for these as you can see in the fl_font_x.cxx code. FLTK looks for helvetica, courier and times. You could change this to liberation and recompile FLTK. (Or setup a font.alias file instead.)
Part of the problem is that openwrt does not seem to include fonts and you have to provide these yourself while other distributions come with lots of different types of fonts installed.
Part of the problem is that openwrt does not seem to include fonts and you have to provide these yourself while other distributions come with lots of different types of fonts installed.
bogdanul2003
Mar 27, 2015, 5:09:32 PM3/27/15
to fltkg...@googlegroups.com, ian.ma...@selex-es.com
Hi Georg,
I specified in my previous post that I changed this array. So it looks for the correct fonts.
I changed the built_in_table to this and recompiled:
static Fl_Fontdesc built_in_table[] = {{"-*-liberation mono-medium-i-normal--*"},{"-*-liberation mono-bold-r-normal--*"},{"-*-liberation mono-medium-r-normal--*"},{"-*-liberation sans-medium-i-normal--*"}};My fonts were copied to /usr/share/fonts and I generated the fonts.dir file as described in my previous post.
Thanks,
Bogdan
Georg Potthast
Mar 28, 2015, 3:35:04 AM3/28/15
to fltkg...@googlegroups.com, ian.ma...@selex-es.com
Hi Bogdan,
I do not know why find_best_font() changes the name of the font but the 14 specifies a the size of the font in pixels which depends on the resolution of the display. Since FLTK specifies a wildcard (*) here this should still work.
I do not know why find_best_font() changes the name of the font but the 14 specifies a the size of the font in pixels which depends on the resolution of the display. Since FLTK specifies a wildcard (*) here this should still work.
>modified char *NXDIRLIST[] from font.c
Do you mean char *FONT_DIR_LIST[] in fontlist.c?
>My fonts were copied to /usr/share/fonts
The default *FONT_DIR_LIST[] does not look for truetype fonts in this folder.
As far as I know NXlib falls back to a fixed font if it cannot find a truetype font. This way you get at least some text on the screen. So you could try to also copy the font files in the microwindows/src/fonts/pcf directory into /usr/share/fonts/X11/misc on your openwrt system. Or use the pcf files from some other distro.
Georg
As far as I know NXlib falls back to a fixed font if it cannot find a truetype font. This way you get at least some text on the screen. So you could try to also copy the font files in the microwindows/src/fonts/pcf directory into /usr/share/fonts/X11/misc on your openwrt system. Or use the pcf files from some other distro.
Georg
bogdanul2003
Mar 28, 2015, 11:43:22 AM3/28/15
to fltkg...@googlegroups.com, ian.ma...@selex-es.com
Hello Georg,
Do you mean char *FONT_DIR_LIST[] in fontlist.c?
My nxlib folder doesn't have a fonlist.c file ... it has a font.c file which contains a list of directories that are used to search for the fonts. Here is the array of directories:
/* default X11 font directory list, add directories if desired*/static char *NXDIRLIST[] = { X11_FONT_DIR1, X11_FONT_DIR2, X11_FONT_DIR3, "/usr/share/fonts/truetype/liberation/", 0};Is my nxlib version to old or you're talking about another fontlist.c file ? I also included in the search list the fonts that were installed.
the 14 specifies a the size of the font in pixels which depends on the resolution of the display.
All the fonts that I generated in fonts.dir seem to have size 0 ... I posted the content of fonts.dir in a previous post. Is this wrong, all fonts to have size 0? I generated the fonts.dir using ttmkfdir and mkfontdir. Maybe this is not working correctly.
To clarify my problem ... nxlib finds the fonts.dir file but it modifies mono-medium-i-normal--0-0-0-0-m-0-iso10646-1 to mono-medium-i-normal--14-0-0-0-m-0-iso10646-1 and will use this font name further, the problem is that there is no size 14 font in my fonts.dir file.
I'll try to use the pcf fonts from microwindows as you said and see what I'll get.
Still I will try to find out why I have only 0 size fonts in my fonts.dir (if you said that 14 signifies the size of the font) and why does find_best_font() function from fltk try to change the name of the font.
bogdanul2003
Mar 28, 2015, 12:28:46 PM3/28/15
to fltkg...@googlegroups.com, ian.ma...@selex-es.com
I also need to add that I use these settings microwin configuration:
What is the difference between freetype1.x and freetype2.x? Which one should I use ?
##################################################################### TIFF support through libtiff####################################################################HAVE_TIFF_SUPPORT = NINCTIFF ?= .LIBTIFF ?=
##################################################################### native .fnt loadable font support####################################################################HAVE_FNT_SUPPORT = YHAVE_FNTGZ_SUPPORT = YFNT_FONT_DIR = "fonts/bdf"
##################################################################### T1 adobe type1 font support thru t1lib####################################################################HAVE_T1LIB_SUPPORT = NINCT1LIB = /usr/includeLIBT1LIB = /usr/lib/libt1.a
##################################################################### TrueType font support thru FreeType 1.x####################################################################HAVE_FREETYPE_SUPPORT = NINCFTLIB = /usr/include/freetype1LIBFTLIB = /usr/lib/libttf.soFREETYPE_FONT_DIR = "fonts/truetype"
##################################################################### Support for many kinds of font thru FreeType 2.x# Must also set FREETYPE_FONT_DIR in the Freetype 1.x section####################################################################HAVE_FREETYPE_2_SUPPORT = YINCFT2LIB ?= .LIBFT2LIB ?=
##################################################################### PCF font support # Selecting HAVE_PCFGZ_SUPPORT will allow you to directly read# .pcf.gz files, but it will add libz to the size of the server####################################################################HAVE_PCF_SUPPORT = YHAVE_PCFGZ_SUPPORT = YPCF_FONT_DIR = "fonts/pcf"What is the difference between freetype1.x and freetype2.x? Which one should I use ?
imm
Mar 28, 2015, 5:10:26 PM3/28/15
to general fltk
On Mar 28, 2015 4:28 PM, "bogdanul2003" wrote:
>
> I also need to add that I use these settings microwin configuration:
>
####################################################################
> # TrueType font support thru FreeType 1.x
> ####################################################################
> HAVE_FREETYPE_SUPPORT = N
> INCFTLIB = /usr/include/freetype1
> LIBFTLIB = /usr/lib/libttf.so
> FREETYPE_FONT_DIR = "fonts/truetype"
>
> ####################################################################
> # Support for many kinds of font thru FreeType 2.x
> # Must also set FREETYPE_FONT_DIR in the Freetype 1.x section
> ####################################################################
> HAVE_FREETYPE_2_SUPPORT = Y
> INCFT2LIB ?= .
> LIBFT2LIB ?=
>
> ####################################################################
> # PCF font support
> # Selecting HAVE_PCFGZ_SUPPORT will allow you to directly read
> # .pcf.gz files, but will add libz to the size of the server
> ####################################################################
> HAVE_PCF_SUPPORT = Y
> HAVE_PCFGZ_SUPPORT = Y
> PCF_FONT_DIR = "fonts/pcf"
>
>
> What is the difference between freetype1.x and freetype2.x? Which one should I use ?
>
You said you have linked freetype into your nanox build, which version did you use? Then set things accordingly.
Given a free choice freetype2 is "better" in that it covers more types of scalable fonts not just TrueType.
It is probably a good idea to make sure something is set for LIBFT2LIB though and that the given paths make sense.
Georg Potthast
Mar 29, 2015, 3:52:42 AM3/29/15
to fltkg...@googlegroups.com
Hi Bogdan,
you are not using the latest version. Apparently you are using microwindows-src-0.91.tar.gz and
nxlib-05142010.tar.gz. There are later versions available.
I have read the the latest version includes some changes for FLTK 1.3.x and this is the one Ian and I have been using successfully. So I suggest that you use that version instead.
You find all the versions here:
ftp://microwindows.censoft.com/pub/microwindows/
I used this for microwindows:
ftp://microwindows.censoft.com/pub/microwindows/microwindows-src-snapshot.tar.gz
And this for NXlib:
ftp://microwindows.censoft.com/pub/microwindows/nxlib-src-snapshot.tar.gz
Regarding the Makefile (i.e. its config include file), the settings in there to some extend only make a difference if you are writing Nano-X applications while FLTK does e.g. include its own PNG and JPEG libraries.
So I do not know if my settings are all required but they are as follows:
####################################################################
# TIFF support through libtiff
####################################################################
HAVE_TIFF_SUPPORT = N
INCTIFF = .
LIBTIFF = /usr/lib/libtiff.so
####################################################################
# PCF font support - .pcf/.pcf.gz loadable fonts
####################################################################
HAVE_PCF_SUPPORT = Y
HAVE_PCFGZ_SUPPORT = Y
PCF_FONT_DIR = "fonts/pcf"
####################################################################
# Truetype fonts - .ttf loadable fonts thru Freetype 2.x
####################################################################
HAVE_FREETYPE_2_SUPPORT = Y
INCFT2LIB = /usr/include
LIBFT2LIB = /usr/local/lib/libfreetype.so
FREETYPE_FONT_DIR = "fonts/truetype"
####################################################################
# T1 adobe type1 fonts - .pfb/.afm loadable thru t1lib
# t1lib.config must be setup and in T1LIB_FONT_DIR
####################################################################
HAVE_T1LIB_SUPPORT = N
T1LIB_FONT_DIR = "fonts/type1"
INCT1LIB = /usr/include
LIBT1LIB = /usr/lib/libt1.so
####################################################################
# FNT font support - .fnt/.fnt.gz loadable fonts (native bdf-converted)
####################################################################
HAVE_FNT_SUPPORT = Y
HAVE_FNTGZ_SUPPORT = Y
FNT_FONT_DIR = "fonts/fnt"As you see for some fonts I made a path to a local font directory within the applications directory. E.g. "fonts/fnt". So I guess NXlib does not use these paths but searches them according to fontlist.c. (Which is in the latest version)
># TrueType font support thru FreeType 1.x
Is no longer included in the current Microwindows version, you are expected to use freetype2.
I do understand that you wonder what the font file name change does. I have cited the font file naming convention but I never found a font file that had anything different than a zero in this place. Since I have always used NXlib with FLTK without noticing or worrying about this name change that you found I do not think this is has anything to do with your problem.
By the way did you see my Nanolinux distribution which is completely based on Nano-X/NXlib and FLTK:
https://sourceforge.net/projects/nanolinux/
Georg
I do understand that you wonder what the font file name change does. I have cited the font file naming convention but I never found a font file that had anything different than a zero in this place. Since I have always used NXlib with FLTK without noticing or worrying about this name change that you found I do not think this is has anything to do with your problem.
By the way did you see my Nanolinux distribution which is completely based on Nano-X/NXlib and FLTK:
https://sourceforge.net/projects/nanolinux/
Georg
bogdanul2003
Mar 29, 2015, 10:09:24 AM3/29/15
to fltkg...@googlegroups.com
Hi Georg,
I've got the latest versions you suggested and it worked like a charm without modifying built_in_table or FONT_DIR_LIST which look like this:
char *FONT_DIR_LIST[] = { "fonts", /* local font dir w/fonts.alias*/ "/usr/share/fonts/X11/misc", /* pcf fonts w/fonts.dir*/ "/usr/share/fonts/X11/100dpi", "/usr/share/fonts/truetype/freefont", /* truetype fonts, no fonts.dir*/ "/usr/share/fonts/truetype/ttf-dejavu", "/usr/share/fonts/truetype/openoffice", "/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType", /* truetype fonts, w/fonts.dir & fonts.scale*/ "/usr/share/fonts/X11/Type1", /* t1lib type1 .pfb fonts, w/fonts.dir*/ 0};
static Fl_Fontdesc built_in_table[] = {{"-*-helvetica-medium-r-normal--*"},{"-*-helvetica-bold-r-normal--*"},{"-*-helvetica-medium-o-normal--*"},{"-*-helvetica-bold-o-normal--*"},{"-*-courier-medium-r-normal--*"},{"-*-courier-bold-r-normal--*"},{"-*-courier-medium-o-normal--*"},{"-*-courier-bold-o-normal--*"},{"-*-times-medium-r-normal--*"},{"-*-times-bold-r-normal--*"},{"-*-times-medium-i-normal--*"},{"-*-times-bold-i-normal--*"},{"-*-symbol-*"},{"-*-lucidatypewriter-medium-r-normal-sans-*"},{"-*-lucidatypewriter-bold-r-normal-sans-*"},{"-*-*zapf dingbats-*"}};I attached a picture.
Now the question is ... from where does it take the font it just used? Is there a place where I could put a printf and see from where it gets the font ?
On my openwrt router the fonts are installed in these directories which are not in the directory list of nxlib:
root@OpenWrt:~# ls /usr/share/fonts/truetype ttf-dejavuroot@OpenWrt:~# ls /usr/share/fonts/truetype/liberationThanks.
bogdanul2003
Mar 29, 2015, 10:45:59 AM3/29/15
to fltkg...@googlegroups.com
I added some printfs and I got this:
It seems that find_best_font() returned "fixed". This means that no fonts are found and "fixed" font will be used. Now I need to figure out where this font is stored.
root@OpenWrt:/tmp# ./hello XOpenIM() failedIN find_best_font: -*-helvetica-medium-r-normal--* find_best_font returned: fixedXDrawString16 13 0 48It seems that find_best_font() returned "fixed". This means that no fonts are found and "fixed" font will be used. Now I need to figure out where this font is stored.
Georg Potthast
Mar 29, 2015, 12:08:50 PM3/29/15
to fltkg...@googlegroups.com
This looks just like when I started out using Microwindows with FLTK ;- )
Nano-X/NXlib did not find a truetype font and is using its default font called "fixed". You have to follow the suggestions Ian and I gave you and modifiy things until it finds a truetype font. It may take some time. Otherwise it will fall back to the "fixed" font. I do not know where that is located.
Georg
Nano-X/NXlib did not find a truetype font and is using its default font called "fixed". You have to follow the suggestions Ian and I gave you and modifiy things until it finds a truetype font. It may take some time. Otherwise it will fall back to the "fixed" font. I do not know where that is located.
Georg
Ian MacArthur
Mar 29, 2015, 4:56:50 PM3/29/15
to fltkg...@googlegroups.com
On Sat Mar 28 2015 15:43:21, bogdanul2003 wrote:
To clarify my problem ... nxlib finds the fonts.dir file but it modifies mono-medium-i-normal--0-0-0-0-m-0-iso10646-1 to mono-medium-i-normal--14-0-0-0-m-0-iso10646-1 and will use this font name further, the problem is that there is no size 14 font in my fonts.dir file.
Those long names are called XLFD’s, and changing them like that is “normal”.
If scalable font support is working, then it shouldn’t matter that you don’t actually have a size 14 font, since the font renderer can make one...
So; that is not the problem...
Ian MacArthur
Mar 29, 2015, 5:08:19 PM3/29/15
to fltkg...@googlegroups.com
On Sun Mar 29 2015 15:09:23, bogdanul2003 wrote:
> Hi Georg,
>
> I've got the latest versions you suggested and it worked like a charm
Well, that’s a good start; though I think you have only got the default fallback, probably not the face you wanted?
> Hi Georg,
>
> I've got the latest versions you suggested and it worked like a charm
> static Fl_Fontdesc built_in_table[] = {
> {"-*-helvetica-medium-r-normal--*"},
> {"-*-helvetica-bold-r-normal--*"},
> {"-*-helvetica-medium-o-normal--*"},
> {"-*-helvetica-bold-o-normal--*"},
> {"-*-courier-medium-r-normal--*"},
> {"-*-courier-bold-r-normal--*"},
> {"-*-courier-medium-o-normal--*"},
> {"-*-courier-bold-o-normal--*"},
> {"-*-times-medium-r-normal--*"},
> {"-*-times-bold-r-normal--*"},
> {"-*-times-medium-i-normal--*"},
> {"-*-times-bold-i-normal--*"},
> {"-*-symbol-*"},
> {"-*-lucidatypewriter-medium-r-normal-sans-*"},
> {"-*-lucidatypewriter-bold-r-normal-sans-*"},
> {"-*-*zapf dingbats-*"}
> };
Pick any faces you have but choose faces such that the “Helvetica” ones are mapped to something proportionally spaced, sans-serif.
The “courier” ones map to any fixed-pitch scalable font.
The “times” ones map to any proportionally spaced serif face.
The “lucidatypewriter” face is another fixed pitch scalable face, often used for consoles and the like.
And “symbol” and “zapf dingbats” are non-aphabetic faces used for decorations and such, you probably do not need these!
>
> I attached a picture.
> Now the question is ... from where does it take the font it just used? Is there a place where I could put a printf and see from where it gets the font ?
> On my openwrt router the fonts are installed in these directories which are not in the directory list of nxlib:
> root@OpenWrt:~# ls /usr/share/fonts/
> truetype ttf-dejavu
> root@OpenWrt:~# ls /usr/share/fonts/truetype/
> liberation
bogdanul2003
Mar 29, 2015, 5:26:40 PM3/29/15
to fltkg...@googlegroups.com
Thanks guys, really helpful. I'll try to change the fonts later.
At the moment I'm trying to draw a FL_Progress and change ti's value form another thread. The tread works fine but the progressbar is not updated when the new value is set by the thread but at a later time at random.
#include <FL/Fl.H>#include <FL/Fl_Window.H>#include <FL/Fl_Double_Window.H>#include <FL/Fl_Progress.H>#ifdef FOR_ARM#include <microwin/nano-X.h>#endif
#include <unistd.h>#include <pthread.h>
Fl_Progress *progress_bar=NULL;
void *change_progress(void *stuff){ while(true){ if(progress_bar!=NULL) { int val=progress_bar->value(); if (val >= 100) val=0; else val+=10; printf("set val: %d\n", val); progress_bar->value(val); } sleep(1); } return NULL;}
Fl_Double_Window* make_window() { Fl_Double_Window* w; { Fl_Double_Window* o = new Fl_Double_Window(0,0,240, 320); w = o; { Fl_Progress* o = new Fl_Progress(10, 50, 200, 25); o->selection_color((Fl_Color)81); o->value(100); progress_bar = o; } // Fl_Progress* o o->clear_border(); o->end(); } // Fl_Double_Window* o return w;}
int main(int argc, char **argv) { Fl_Double_Window *win=make_window(); if (progress_bar!=NULL) progress_bar->value(70); win->end(); win->show(argc, argv); pthread_t progress_thread; pthread_create(&progress_thread, NULL, change_progress, NULL); return(Fl::run());}
Ian MacArthur
Mar 29, 2015, 6:02:00 PM3/29/15
to fltkg...@googlegroups.com
On Sun Mar 29 2015 22:26:39, bogdanul2003 wrote:
> Thanks guys, really helpful. I'll try to change the fonts later.
> At the moment I'm trying to draw a FL_Progress and change ti's value form another thread. The tread works fine but the progressbar is not updated when the new value is set by the thread but at a later time at random.
You can’t do that, it will not work.
> Thanks guys, really helpful. I'll try to change the fonts later.
> At the moment I'm trying to draw a FL_Progress and change ti's value form another thread. The tread works fine but the progressbar is not updated when the new value is set by the thread but at a later time at random.
The graphical context is not thread safe - this isn’t particularly a fltk issue, most GUI libraries have this problem because, in the end, there is only one GPU context and it “belongs” too the “main()” thread of any given process.
Read the “advanced” chapter of the fltk docs, where it discusses using the Fl::lock() and unlock() methods, and the use of Fl::awake() to signal from one thread to the next.
In summary, your main() needs to issue one Fl::lock() before it shows any widgets, and your worker thread probably wants to lock/unlock around any access to a widget. It then wants to use Fl::awake() to tell the main() thread that something has changed.
To be honest, in your case, I think I’d not bother with modifying the progress from the worker thread at all, but just have the worker call Fl::awake() with a callback function to allow the main() thread to do the updates itself, thereby obviating the need for most of the locking. (Note that locking from a worker thread will inherently tend to introduce some implicit synchronisation between threads, which is not what you want, ideally.)
>
> #ifdef FOR_ARM
> #include <microwin/nano-X.h>
> #endif
I do not think I ever had to do this using nanox, it has always been enough like “real” X to work...
bogdanul2003
Mar 30, 2015, 2:03:43 PM3/30/15
to fltkg...@googlegroups.com
A question: I see this in lots of your examples - what is it for?
I do not think I ever had to do this using nanox, it has always been enough like “real” X to work...
I removed it and works ok ... don't remember where I saw this being used.
I also used Fl::awake() and it works nice. Thanks
Do you know if it is possible to rotate the progress bar? I tried to find something about this but no luck.
Ian MacArthur
Mar 30, 2015, 5:38:12 PM3/30/15
to fltkg...@googlegroups.com
On Mon Mar 30 2015 19:03:42, bogdanul2003 wrote:
>
> I also used Fl::awake() and it works nice. Thanks
OK - that’s good; though you need to be cautions about locking if you ever access a widget from any thread other than the main() too, of course.
>
> I also used Fl::awake() and it works nice. Thanks
> Do you know if it is possible to rotate the progress bar? I tried to find something about this but no luck.
bogdanul2003
Mar 31, 2015, 3:09:17 PM3/31/15
to fltkg...@googlegroups.com
1. A progress bar is horizontal by default and I would like to rotate it 90 degrees to be vertical.
2. A second topic would be the events handled by FLTK (in my case we're talking about a touch screen). I know that nanox has a touch screen interface that transforms touch screen events from different touch screen drivers to mouse events and sends them to fltk ... I think. My question: is it possible to generate those events from user space from a different thread(for example reading a serial port which at some point gets some touch coordinates) and send the events to fltk ? I know this is not the standard way but on the serial port that I use for touch screen events I also receive other stuff that is parsed in user space in the thread that I was talking about. So I would like to send mouse events from that thread when I receive a touch event to FLTK.
Ian MacArthur
Mar 31, 2015, 5:29:59 PM3/31/15
to fltkg...@googlegroups.com
On Tue Mar 31 2015 20:09:17, bogdanul2003 wrote:
> 1. A progress bar is horizontal by default and I would like to rotate it 90 degrees to be vertical.
Not sure if a stock Fl_Progress can do vertical - you’d probably be better of either making your own, or just using an Fl_Fill_Slider widget set for the vertical type, which would do what you want, I think.
> 1. A progress bar is horizontal by default and I would like to rotate it 90 degrees to be vertical.
>
> 2. A second topic would be the events handled by FLTK (in my case we're talking about a touch screen). I know that nanox has a touch screen interface that transforms touch screen events from different touch screen drivers to mouse events and sends them to fltk ... I think. My question: is it possible to generate those events from user space from a different thread(for example reading a serial port which at some point gets some touch coordinates) and send the events to fltk ? I know this is not the standard way but on the serial port that I use for touch screen events I also receive other stuff that is parsed in user space in the thread that I was talking about. So I would like to send mouse events from that thread when I receive a touch event to FLTK.
Actually, since you are set on using nanox anyway, it might almost be easier, as all the server code is right there and it has a fair number of alternate interface options in it. So you could write your own “driver” inside nanox to take the events from your serial port and interpret them, then propagate them to fltk and other apps as if they were just regular mouse events.
Georg Potthast
Apr 1, 2015, 3:43:09 AM4/1/15
to fltkg...@googlegroups.com
Actually, since you are set on using nanox anyway, it might almost be easier, as all the server code is right there and it has a fair number of alternate interface options in it. So you could write your own “driver” inside nanox to take the events from your serial port and interpret them, then propagate them to fltk and other apps as if they were just regular mouse events.
Yes, you will probably have to write your own driver for that and take the existing touchscreen drivers as a template. Also, there is still the mou_ser.c driver in there which was written for a serial mouse. However, writing your own driver takes quite some time and maybe there is a different solution you can use.
bogdanul2003
Apr 1, 2015, 9:10:44 AM4/1/15
to fltkg...@googlegroups.com
I looked at the touch screen driver models and they seem to be pretty straight forward. The problem is that I can't use them because on the serial port I receive other information besides the touch events, information that is used by other futures. If I choose to use this nanox touch driver approach I would have to dump the extra information coming on the serial port and just use the touch events.
I looked in nanox source code and XSendEvent is not implemented .... all it does is to print some text and a return.
What is the actual mechanism of sending an event to fltk ? How does fltk receive events? I'm not interested in how events are processed inside fltk but how does fltk receive them from nanox ?
MacArthur, Ian (Selex ES, UK)
Apr 1, 2015, 10:49:18 AM4/1/15
to fltkg...@googlegroups.com
> I looked at the touch screen driver models and they seem to be pretty
> straight forward. The problem is that I can't use them because on the
> serial port I receive other information besides the touch events,
> information that is used by other futures. If I choose to use this nanox
> touch driver approach I would have to dump the extra information coming
> on the serial port and just use the touch events.
I don't think so: if you have data arriving on a serial port, that is intermixed with data intended for more than one destination, then you have a problem anyway, as only one process can read from the serial port.
> straight forward. The problem is that I can't use them because on the
> serial port I receive other information besides the touch events,
> information that is used by other futures. If I choose to use this nanox
> touch driver approach I would have to dump the extra information coming
> on the serial port and just use the touch events.
A common solution in that case is to have whichever process "owns" the serial port read all the data from the port; anything it "recognises" it keeps for itself, anything it does not recognise it writes out to another fd (perhaps a named pipe or similar) that some other process can read from.
In that model, it does not matter much whether it is nanox that owns the physical serial port or not; whoever owns its must re-send any "unused" data on another fd anyway.
So you could implement a serial driver in nanox that reads the port, takes any touch events, and re-sends everything else to a pipe. Your other process can attach to that pipe to read whatever other traffic is presented.
Or vice versa, of course; your other process can manage the serial port, and re-emit unused data on the pipe, and your nanox driver can read from the pipe to recover the touch events.
> I looked in nanox source code and XSendEvent is not implemented .... all
> it does is to print some text and a return.
> What is the actual mechanism of sending an event to fltk ? How does fltk
> receive events? I'm not interested in how events are processed inside
> fltk but how does fltk receive them from nanox ?
There's lots of stuff on the web about the X11 event model, but (simplifying greatly) any app registers with the Xserver for events, and the Xserver delivers them asynchronously when they occur (usually via a socket.)
The nanox layer on microwindows more or less fakes that up well enough to keep fltk happy, but what it actually does internally to convert incoming mouse or keyboard events into X11 messages to the applications I do not know.
MacArthur, Ian (Selex ES, UK)
Apr 1, 2015, 11:01:34 AM4/1/15
to fltkg...@googlegroups.com
> In that model, it does not matter much whether it is nanox that owns
> the physical serial port or not; whoever owns its must re-send any
> "unused" data on another fd anyway.
>
> So you could implement a serial driver in nanox that reads the port,
> takes any touch events, and re-sends everything else to a pipe. Your
> other process can attach to that pipe to read whatever other traffic is
> presented.
>
> Or vice versa, of course; your other process can manage the serial
> port, and re-emit unused data on the pipe, and your nanox driver can
> read from the pipe to recover the touch events.
Oh bother!
> the physical serial port or not; whoever owns its must re-send any
> "unused" data on another fd anyway.
>
> So you could implement a serial driver in nanox that reads the port,
> takes any touch events, and re-sends everything else to a pipe. Your
> other process can attach to that pipe to read whatever other traffic is
> presented.
>
> Or vice versa, of course; your other process can manage the serial
> port, and re-emit unused data on the pipe, and your nanox driver can
> read from the pipe to recover the touch events.
And I *meant* to say that it *usually* makes more sense to have the Xserver (or nanox in this case) manage the serial port, because it will probably be running first, before any applications. (Since applications can not run if there is no Xserver to display them.)
If you do it the other way, and process the serial port in your application, you might not even be able to start your application, since there is no way to click on anything on the screen, as the serial port is not being read. Of course, if your application starts automatically once nanox has started, that may all be fine.
Georg Potthast
Apr 1, 2015, 1:03:29 PM4/1/15
to fltkg...@googlegroups.com, ian.ma...@selex-es.com
> I looked at the touch screen driver models and they seem to be pretty
> straight forward. The problem is that I can't use them because on the
> serial port I receive other information besides the touch events,
> information that is used by other futures. If I choose to use this nanox
> touch driver approach I would have to dump the extra information coming
> on the serial port and just use the touch events.
If this is a serial port with a UART then usually only one device is connected
to it. So I do not think there will be a lot of information
on the line coming from the touchscreen device that you'll have to dump.
A nano-X driver has a structure of function pointers to the open, read, close and other
functions within the driver. Nano-X will call the read function freqently and present
the data retrieved via NXlib as an XEvent to FLTK.
Usually the Xlib applications like FLTK will have an event loop and call XNextEvent
to retrieve the XEvents. XNextEvent is implemented in NextEvent.c within NXlib.
See this example:
http://tronche.com/gui/x/xlib-tutorial/2nd-program-anatomy.html
Georg
to it. So I do not think there will be a lot of information
on the line coming from the touchscreen device that you'll have to dump.
A nano-X driver has a structure of function pointers to the open, read, close and other
functions within the driver. Nano-X will call the read function freqently and present
the data retrieved via NXlib as an XEvent to FLTK.
Usually the Xlib applications like FLTK will have an event loop and call XNextEvent
to retrieve the XEvents. XNextEvent is implemented in NextEvent.c within NXlib.
See this example:
http://tronche.com/gui/x/xlib-tutorial/2nd-program-anatomy.html
Georg
bogdanul2003
May 19, 2015, 3:10:07 AM5/19/15
to fltkg...@googlegroups.com, ian.ma...@selex-es.com
Hi,
I managed after some time to make the touch screen working with fltk using named pipes ... it wasn't that hard since it easy to add a new touch screen to nanoX.
Next on my to do list is to make things look a bit better. I looked at the different schemes but that is not I really want. I would need a slider that looks more like this: http://www.cultofmac.com/173386/apples-incredible-attention-to-detail-in-ios-6-means-slider-reflections-change-as-you-tilt-your-device/screen-shot-2012-06-13-at-12-12-39/
I know there a lot references to ZynAddSubFX and they really seem to have done something nice with FLTK. I've started to look in their source code but I got lost. Can one of you guys point me in a direction like tell me at which file to look in the ZynAddSubFX project or what is the main idea behind changing the appearance ? For a slider I have two pictures, one for the bar and one for the sliding part and somehow I have to modify the draw functions ?
Greg Ercolano
May 19, 2015, 11:47:10 AM5/19/15
to fltkg...@googlegroups.com
On 05/19/15 00:10, bogdanul2003 wrote:
Hi,
I managed after some time to make the touch screen working with fltk using named pipes ... it wasn't that hard since it easy to add a new touch screen to nanoX.
Next on my to do list is to make things look a bit better. I looked at the different schemes but that is not I really want. I would need a slider that looks more like this: http://www.cultofmac.com/173386/apples-incredible-attention-to-detail-in-ios-6-means-slider-reflections-change-as-you-tilt-your-device/screen-shot-2012-06-13-at-12-12-39/
This seems to be similar to an Fl_Slider, so I'd suggest grabbing a copy of Fl_Slider.H and Fl_Slider.cxx from the fltk source, change the class name (e.g. My_Slider), and then change up the draw() code to draw your images in place of the rectangles that Fl_Slider draws.
Or, just write your own widget from scratch (in some ways that might be easier to start with).
I'd suggest using an image format that allows for alpha channels, since the 'tab' of the slider is round. This way when you draw your brushed metal 'tab', the image rectangle is 'see through' around the tab, letting background detail show through.
PNG is best for this, because our Fl_PNG_Image code handles 8 bit alpha channels, so you can paint a nice round tab, and have the edges be anti-aliased. The other choice is XPM, but that only supports 1 bit alpha, which can make for jaggy edges.
Or, you can render an RGBA image directly to achieve the same effect. That's what I used in this example:
http://seriss.com/people/erco/fltk/#MultiColorBarGraph
In this case it's more of a bar graph than a slider, but the techniques are similar. There, I painted the image with an alpha channel in gimp, then saved the image in a raw RGBA format, and copy/pasted the RGBA hex codes into the source file, so the image could be embedded within the code, instead of having to load the image at runtime from disk. (In my case I didn't want the widget to depend on external files, but you can if you want to -- makes the cycle of changing the widget easier if you use files)
A simpler example is this one I made a while ago using external XPM images:
http://seriss.com/people/erco/fltk/Fl_Gel_Tabs/
..it shows how to use XPM images to draw the tabs with a gradient background.. all painted in gimp. The 'round' edges are more 'flattened' because of XPM's 1 bit alpha channel, which didn't look good for true rounded edges, so I went with simple flattened edges. You can get better results with PNG images using full 8 bit alpha channels.
And yes, you're basically messing around with the draw() code, changing the shapes drawn to show the widget's objects.
If you start with a copy of Fl_Slider, you'll inherit all its mechanics. Then you can look at the draw() code that's there to figure out what objects it draws, and then slowly replace those with your own image drawing code (similar to the above example) where you draw() the image in the proper x/y positions of the tab.
I imagine you'll need several little images to pull this off:
- one each for the left and right rounded edges of the 'trough'
- a vertical 1 pixel wide "sliver" of the trough itself, in both highlighted and dark
- one for the round tab, preferably an alpha channel image of just the round part, so the bg shows through in the image rectangle around it
That should be it -- the rest of the widget's code will handle the mechanics of where to draw everything, and will handle events and such.
To do a real pro job on the widget, take into account drawing the widget in a deactivated state so that it grays out properly when deactivated, include a shadow in the metal tab (that can be done with alpha channels too, probably as part of the image of the tab)
bogdanul2003
May 26, 2015, 6:52:21 AM5/26/15
to fltkg...@googlegroups.com, erco_...@seriss.com
Hi Greg,
Nice tutorial ... worked like a charm. In the end I decided to make a slide bar similar to what android has but I have some problems. In the pictures attached you'll see the slide bar in a middle position is displayed fine but at the extremities the 'tab' (the round part) is cut from the picture.
Can't find the problem yet ... why the the circle is not fully drawn ?
Edzard Egberts
May 26, 2015, 7:37:01 AM5/26/15
to 'ed' via fltk.general
> the slide bar in a middle position is
> displayed fine but at the extremities the 'tab' (the round part) is cut
> from the picture.
> Can't find the problem yet ... why the the circle is not fully drawn ?
There seems to be a clipping active, that restricts the circle to the
> displayed fine but at the extremities the 'tab' (the round part) is cut
> from the picture.
> Can't find the problem yet ... why the the circle is not fully drawn ?
rectangle of the widget. Look for commands fl_push_clip() or fl_clip()
and fl_pop_clip().
To resolve this you could use fl_push_no_clip() before drawing the
circle and fl_pop_clip() after the circle was drawn (think so, not tested).
MacArthur, Ian (Selex ES, UK)
May 26, 2015, 7:43:11 AM5/26/15
to fltkg...@googlegroups.com
> > the slide bar in a middle position is
> > displayed fine but at the extremities the 'tab' (the round part) is
> cut
> > from the picture.
> > Can't find the problem yet ... why the the circle is not fully drawn
> ?
>
Also, apart from the clipping, as Edzard suggests, you need to consider where the "origin" of your circle drawing is; it looks like it might be the top of the circle, rather than (as one might expect) the centre of the circle.
> > displayed fine but at the extremities the 'tab' (the round part) is
> cut
> > from the picture.
> > Can't find the problem yet ... why the the circle is not fully drawn
> ?
>
How are you doing the circle drawing? Note that fl_pie and the integral version of fl_arc define a bounding box, not a circle centre, so the (x,y) co-ordinate defines the top left corner of the drawing.
Greg Ercolano
May 26, 2015, 12:02:51 PM5/26/15
to fltkg...@googlegroups.com
On 05/26/15 03:52, bogdanul2003 wrote:
> ..but at the extremities the 'tab' (the round part) is cut from the picture.
As others have mentioned, be mindful of the current clip region
and be sure to draw within the xywh boundary of the widget.
The widget you derived from may be designed to draw the widget
to the extremes of the xywh because the 'tab' is rectangular.
In your case it's a large circle, so you may need to either
make the circle smaller, or scale drawing of the entire length
of the slider inward a bit, to allow room for the circle's diameter.
> ..but at the extremities the 'tab' (the round part) is cut from the picture.
> Can't find the problem yet ... why the the circle is not fully drawn ?
Post your code..?
As others have mentioned, be mindful of the current clip region
and be sure to draw within the xywh boundary of the widget.
The widget you derived from may be designed to draw the widget
to the extremes of the xywh because the 'tab' is rectangular.
In your case it's a large circle, so you may need to either
make the circle smaller, or scale drawing of the entire length
of the slider inward a bit, to allow room for the circle's diameter.
MacArthur, Ian (Selex ES, UK)
May 27, 2015, 1:13:21 PM5/27/15
to fltkg...@googlegroups.com
> On 05/26/15 03:52, bogdanul2003 wrote:
> > ..but at the extremities the 'tab' (the round part) is cut from the
> picture.
> > Can't find the problem yet ... why the the circle is not fully drawn
> ?
>
> > Can't find the problem yet ... why the the circle is not fully drawn
> ?
>
> Post your code..?
>
> As others have mentioned, be mindful of the current clip region
> and be sure to draw within the xywh boundary of the widget.
>
> The widget you derived from may be designed to draw the widget
> to the extremes of the xywh because the 'tab' is rectangular.
> In your case it's a large circle, so you may need to either
> make the circle smaller, or scale drawing of the entire length
> of the slider inward a bit, to allow room for the circle's
> diameter.
I thought I'd take a stab at a swoopy slider demo... Turned out longer than I'd intended; sorry.
>
> As others have mentioned, be mindful of the current clip region
> and be sure to draw within the xywh boundary of the widget.
>
> The widget you derived from may be designed to draw the widget
> to the extremes of the xywh because the 'tab' is rectangular.
> In your case it's a large circle, so you may need to either
> make the circle smaller, or scale drawing of the entire length
> of the slider inward a bit, to allow room for the circle's
> diameter.
Seems to work OK though I think...
/************************************************************************/
#include <FL/Fl.H>
#include <FL/Fl_Double_Window.H>
#include <FL/Fl_Slider.H>
#include <FL/Fl_Button.H>
#include <FL/fl_draw.H>
/************************************************************************/
class swoopy_slider : public Fl_Slider {
public:
swoopy_slider(int X, int Y, int w, int h, const char* L=0) :
Fl_Slider(X,Y,w,h,L),
core(FL_BACKGROUND_COLOR),
halo(FL_BACKGROUND_COLOR),
dir(step),
hr(116),
hg(188),
hb(211),
do_expire(0)
{
fl_color(0,144,190);
core = fl_color();
fl_color(hr,hg,hb);
halo = fl_color();
clear_visible_focus();
box(FL_FLAT_BOX);
set_timeout(this);
};
~swoopy_slider() { do_expire = -1; };
private:
void draw();
static void set_timeout(void *v) {
swoopy_slider *ss = (swoopy_slider*)v;
if (ss) ss->do_timeout(ss);
}
void do_timeout(void *) {
if (do_expire) return;
hr += dir;
hg += dir;
hb += dir;
if (hb >= 253) {
dir = -step;
}
else if (hb <= 211) {
dir = step;
}
fl_color(hr, hg, hb);
halo = fl_color();
Fl::repeat_timeout(0.1, set_timeout, this);
this->redraw();
}
Fl_Color core;
Fl_Color halo;
int hr, hg, hb;
int dir;
int do_expire;
static const int step = 3;
};
void swoopy_slider::draw(void) {
int xo = x();
int yo = y();
int wo = w();
int ho = h();
Fl_Color bg = FL_BACKGROUND_COLOR;
fl_color(bg);
fl_rectf(xo,yo,wo,ho);
int bd = wo;
int sd = wo/2;
int so = sd/2;
int x1 = xo + sd - 1;
int y1 = yo + sd;
int y2 = yo + ho - sd;
int slen = y2 - y1;
double val;
if (minimum() == maximum())
val = 0.5;
else {
val = (value()-minimum())/(maximum()-minimum());
if (val > 1.0) val = 1.0;
else if (val < 0.0) val = 0.0;
}
val = 1.0 - val;
int sc = (int)((val * slen) + 0.5);
int slx = xo;
int sly = y2 - sc - sd;
fl_line_style(0);
fl_color(halo);
fl_pie(slx, sly, bd, bd, 0, 360);
fl_color(FL_BLACK);
fl_line_style(FL_SOLID, 3);
fl_line(x1, y1, x1, y2) ;
fl_color(core);
fl_line_style(FL_SOLID | FL_CAP_ROUND, 7);
fl_line(x1 - 1, y2 + 2, x1 - 1, sly + sd) ;
fl_line_style(0);
fl_pie(slx + so, sly + so, sd, sd, 0, 360);
} // draw
/************************************************************************/
static Fl_Double_Window *main_win=(Fl_Double_Window *)0;
static swoopy_slider *slider_2=(swoopy_slider *)0;
static Fl_Button *quit_bt=(Fl_Button *)0;
/************************************************************************/
static void cb_quit_bt(Fl_Button*, void*) {
main_win->hide();
}
/************************************************************************/
int main(int argc, char **argv) {
main_win = new Fl_Double_Window(645, 409, "Slider Test");
main_win->begin();
slider_2 = new swoopy_slider(130, 30, 40, 300);
slider_2->maximum(100);
slider_2->value(65);
quit_bt = new Fl_Button(575, 370, 60, 30, "Quit");
quit_bt->callback((Fl_Callback*)cb_quit_bt);
main_win->end();
main_win->show(argc, argv);
return Fl::run();
} // main
// end of file
/************************************************************************/
Ian MacArthur
May 27, 2015, 4:48:47 PM5/27/15
to fltkg...@googlegroups.com
On Wed May 27 2015 18:13:18, MacArthur, Ian (Selex ES, UK) wrote
>
> I thought I'd take a stab at a swoopy slider demo... Turned out longer than I'd intended; sorry.
>
> Seems to work OK though I think...
Or almost works OK... turns out that showed up an interesting feature on OSX where I can’t use fl_color() outside the context of a draw() method. If I do, I get a lot of this...
May 27 21:27:07 immpcX.local swoopy_slider[89107] <Error>: CGContextSetRGBFillColor: invalid context 0x0. This is a serious error. This application, or a library it uses, is using an invalid context and is thereby contributing to an overall degradation of system stability and reliability. This notice is a courtesy: please fix this problem. It will become a fatal error in an upcoming update.
May 27 21:27:07 immpcX.local swoopy_slider[89107] <Error>: CGContextSetRGBStrokeColor: invalid context 0x0. This is a serious error. This application, or a library it uses, is using an invalid context and is thereby contributing to an overall degradation of system stability and reliability. This notice is a courtesy: please fix this problem. It will become a fatal error in an upcoming update.
Despite the warning, the code actually runs OK on OSX, but...
The attached reworking below resolves this issue and should be fine on all platforms (untested on anything but OSX now though!)
fltk-config --compile slider.cxx
/************************************************************************/
#include <FL/Fl.H>
#include <FL/Fl_Double_Window.H>
#include <FL/Fl_Slider.H>
#include <FL/Fl_Button.H>
#include <FL/fl_draw.H>
/************************************************************************/
class swoopy_slider : public Fl_Slider {
public:
swoopy_slider(int X, int Y, int w, int h, const char* L=0) :
Fl_Slider(X,Y,w,h,L),
core(FL_BACKGROUND_COLOR),
halo(FL_BACKGROUND_COLOR),
dir(step),
hr(116),
hg(188),
hb(211),
widget_init(1),
do_expire(0)
{
clear_visible_focus();
box(FL_FLAT_BOX);
void do_timeout(void *) {
if (do_expire) return;
hr += dir;
hg += dir;
hb += dir;
if (hb >= 253) {
dir = -step;
}
else if (hb <= 211) {
dir = step;
}
Fl_Color core;
Fl_Color halo;
int hr, hg, hb;
int dir;
int widget_init;
widget_init = 0;
fl_color(0,144,190);
core = fl_color();
set_timeout(this);
}
fl_color(hr,hg,hb);
halo = fl_color();
fl_color(FL_BACKGROUND_COLOR);
static swoopy_slider *slider_1=(swoopy_slider *)0;
slider_1->maximum(100);
slider_1->value(30);
for (int idx = 130; idx < 600; idx += 45) {
slider_2 = new swoopy_slider(idx, 30, 40, 300);
slider_2->maximum(100);
slider_2->value(idx / 7);
>
> I thought I'd take a stab at a swoopy slider demo... Turned out longer than I'd intended; sorry.
>
> Seems to work OK though I think...
May 27 21:27:07 immpcX.local swoopy_slider[89107] <Error>: CGContextSetRGBFillColor: invalid context 0x0. This is a serious error. This application, or a library it uses, is using an invalid context and is thereby contributing to an overall degradation of system stability and reliability. This notice is a courtesy: please fix this problem. It will become a fatal error in an upcoming update.
May 27 21:27:07 immpcX.local swoopy_slider[89107] <Error>: CGContextSetRGBStrokeColor: invalid context 0x0. This is a serious error. This application, or a library it uses, is using an invalid context and is thereby contributing to an overall degradation of system stability and reliability. This notice is a courtesy: please fix this problem. It will become a fatal error in an upcoming update.
Despite the warning, the code actually runs OK on OSX, but...
The attached reworking below resolves this issue and should be fine on all platforms (untested on anything but OSX now though!)
fltk-config --compile slider.cxx
/************************************************************************/
#include <FL/Fl.H>
#include <FL/Fl_Double_Window.H>
#include <FL/Fl_Slider.H>
#include <FL/Fl_Button.H>
#include <FL/fl_draw.H>
/************************************************************************/
class swoopy_slider : public Fl_Slider {
public:
swoopy_slider(int X, int Y, int w, int h, const char* L=0) :
Fl_Slider(X,Y,w,h,L),
core(FL_BACKGROUND_COLOR),
halo(FL_BACKGROUND_COLOR),
dir(step),
hr(116),
hg(188),
hb(211),
do_expire(0)
{
clear_visible_focus();
box(FL_FLAT_BOX);
};
~swoopy_slider() { do_expire = -1; };
private:
void draw();
static void set_timeout(void *v) {
swoopy_slider *ss = (swoopy_slider*)v;
if (ss) ss->do_timeout(ss);
} // set_timeout
~swoopy_slider() { do_expire = -1; };
private:
void draw();
static void set_timeout(void *v) {
swoopy_slider *ss = (swoopy_slider*)v;
if (ss) ss->do_timeout(ss);
void do_timeout(void *) {
if (do_expire) return;
hr += dir;
hg += dir;
hb += dir;
if (hb >= 253) {
dir = -step;
}
else if (hb <= 211) {
dir = step;
}
Fl::repeat_timeout(0.1, set_timeout, this);
this->redraw();
} // do_timeout
this->redraw();
Fl_Color core;
Fl_Color halo;
int hr, hg, hb;
int dir;
int do_expire;
static const int step = 3;
};
void swoopy_slider::draw(void) {
int xo = x();
int yo = y();
int wo = w();
int ho = h();
if (widget_init) {
static const int step = 3;
};
void swoopy_slider::draw(void) {
int xo = x();
int yo = y();
int wo = w();
int ho = h();
widget_init = 0;
fl_color(0,144,190);
core = fl_color();
set_timeout(this);
}
fl_color(hr,hg,hb);
halo = fl_color();
fl_color(FL_BACKGROUND_COLOR);
static swoopy_slider *slider_2=(swoopy_slider *)0;
static Fl_Button *quit_bt=(Fl_Button *)0;
/************************************************************************/
static void cb_quit_bt(Fl_Button*, void*) {
main_win->hide();
}
/************************************************************************/
int main(int argc, char **argv) {
main_win = new Fl_Double_Window(645, 409, "Slider Test");
main_win->begin();
slider_1 = new swoopy_slider(30, 30, 30, 100);
static Fl_Button *quit_bt=(Fl_Button *)0;
/************************************************************************/
static void cb_quit_bt(Fl_Button*, void*) {
main_win->hide();
}
/************************************************************************/
int main(int argc, char **argv) {
main_win = new Fl_Double_Window(645, 409, "Slider Test");
main_win->begin();
slider_1->maximum(100);
slider_1->value(30);
for (int idx = 130; idx < 600; idx += 45) {
slider_2 = new swoopy_slider(idx, 30, 40, 300);
slider_2->maximum(100);
slider_2->value(idx / 7);
Duncan Gibson
May 28, 2015, 3:51:20 AM5/28/15
to fltkg...@googlegroups.com
Don't feed spambots - please edit out email addresses before replying!
Ian:
Nice demo, but not for me: the pulsating knobs make my eyes go funny.
D.
This message and any attachments are intended for the use of the addressee or addressees only.
The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its
content is not permitted.
If you received this message in error, please notify the sender and delete it from your system.
Emails can be altered and their integrity cannot be guaranteed by the sender.
Please consider the environment before printing this email.
Ian:
>> I thought I'd take a stab at a swoopy slider demo...
> ...
> The attached reworking below resolves this issue and should be fine
> on all platforms (untested on anything but OSX now though!)
I can confirm that it runs OK on Linux [CentOS 6]
> The attached reworking below resolves this issue and should be fine
> on all platforms (untested on anything but OSX now though!)
Nice demo, but not for me: the pulsating knobs make my eyes go funny.
D.
This message and any attachments are intended for the use of the addressee or addressees only.
The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its
content is not permitted.
If you received this message in error, please notify the sender and delete it from your system.
Emails can be altered and their integrity cannot be guaranteed by the sender.
Please consider the environment before printing this email.
MacArthur, Ian (Selex ES, UK)
May 28, 2015, 5:05:36 AM5/28/15
to fltkg...@googlegroups.com
> Ian:
Also, for the record, I have now tested it on Win7 and it appears to work fine.
> Nice demo, but not for me: the pulsating knobs make my eyes go funny.
Yes, sorry about that.
I had a vague recollection of seeing this sort of widget in the wild, and it having a pulsating thing going on, so I thought I'd take a stab at adding it too.
You wouldn't need to have that though!
I'm not even sure I made the right bit pulsate... I wonder if it should be the "core" of the widget rather than the "halo" that pulsates here?
Anyway...
> >> I thought I'd take a stab at a swoopy slider demo...
> > ...
> > The attached reworking below resolves this issue and should be fine
> > on all platforms (untested on anything but OSX now though!)
>
> > The attached reworking below resolves this issue and should be fine
> > on all platforms (untested on anything but OSX now though!)
>
> I can confirm that it runs OK on Linux [CentOS 6]
Thanks; appreciate the feedback.
Also, for the record, I have now tested it on Win7 and it appears to work fine.
> Nice demo, but not for me: the pulsating knobs make my eyes go funny.
I had a vague recollection of seeing this sort of widget in the wild, and it having a pulsating thing going on, so I thought I'd take a stab at adding it too.
You wouldn't need to have that though!
I'm not even sure I made the right bit pulsate... I wonder if it should be the "core" of the widget rather than the "halo" that pulsates here?
Anyway...
bogdanul2003
May 29, 2015, 3:27:27 AM5/29/15
to fltkg...@googlegroups.com, ian.ma...@selex-es.com
Thanks guys ... it was because of the cliping stuff and fl_push_no_clip() did the trick. MacArthur ... nice slider but it's too fancy for what I need at the moment :)
Another question ... I have a Fl_RGB_Image object created in the main() function of the process. If I try to draw it before calling window->show(argc, argv); or Fl::run() gives a seg fault.
Which is the best place in the code to draw an image ? Is there a callback that is called when the window needs a redraw ?
Bogdan
Greg Ercolano
May 29, 2015, 3:49:14 AM5/29/15
to fltkg...@googlegroups.com
On 05/29/15 00:27, bogdanul2003 wrote:
> Another question ... I have a Fl_RGB_Image object created in the main() function of the process. If I try to draw it before calling window->show(argc, argv); or Fl::run() gives a seg fault.
> Which is the best place in the code to draw an image ? Is there a callback that is called when the window needs a redraw ?
Your draw() method is the *only* place to put drawing code.
> Another question ... I have a Fl_RGB_Image object created in the main() function of the process. If I try to draw it before calling window->show(argc, argv); or Fl::run() gives a seg fault.
> Which is the best place in the code to draw an image ? Is there a callback that is called when the window needs a redraw ?
It will be called when a redraw() is needed.
To make a draw() method implies you've derived your own class
from one of the FLTK widgets (e.g. Fl_Window, Fl_Box, etc).
Look again at the example code I linked to in my long reply
on 05/19/15; they both have draw() methods that do all the work.
Greg Ercolano
May 29, 2015, 3:58:44 AM5/29/15
to fltkg...@googlegroups.com
On 05/27/15 13:48, Ian MacArthur wrote:
> Or almost works OK... turns out that showed up an interesting feature
> on OSX where I can’t use fl_color() outside the context of a draw() method.
But... we shouldn't be calling draw functions like fl_color()
> Or almost works OK... turns out that showed up an interesting feature
> on OSX where I can’t use fl_color() outside the context of a draw() method.
outside the context of draw() anyway, should we?
MacArthur, Ian (Selex ES, UK)
May 29, 2015, 5:09:01 AM5/29/15
to fltkg...@googlegroups.com
> On 05/27/15 13:48, Ian MacArthur wrote:
> > Or almost works OK... turns out that showed up an interesting feature
> > on OSX where I can’t use fl_color() outside the context of a draw()
> method.
>
> But... we shouldn't be calling draw functions like fl_color()
> > on OSX where I can’t use fl_color() outside the context of a draw()
> method.
>
> outside the context of draw() anyway, should we?
Well, yes. But as it happens, it was OK to call fl_color() when not in a valid context, and it actually works.
Or at least it used to. Apple are clearly in the process of deprecating that on OSX.
It was always a Bad Idea to do it anyway, but it happened to be convenient for some hacky colour setting things I was doing...
I'll not be doing it in future though!
Albrecht Schlosser
May 29, 2015, 6:38:52 AM5/29/15
to fltkg...@googlegroups.com
On 29.05.2015 09:27 bogdanul2003 wrote:
> Another question ... I have a Fl_RGB_Image object created in the main()
> function of the process. If I try to draw it before
> calling window->show(argc, argv); or Fl::run() gives a seg fault.
> Which is the best place in the code to draw an image ? Is there a
> callback that is called when the window needs a redraw ?
As Greg wrote already you can't call drawing methods outside a drawing
> Another question ... I have a Fl_RGB_Image object created in the main()
> function of the process. If I try to draw it before
> calling window->show(argc, argv); or Fl::run() gives a seg fault.
> Which is the best place in the code to draw an image ? Is there a
> callback that is called when the window needs a redraw ?
context, i.e. usually only in a draw() method. Under some circumstances
you can get such a drawing context elsewhere by using
Fl_Window::make_current(), but that is most likely not what you want to do.
In the case of images it's often easier to assign the image as (part of)
the label of a Fl_Box widget or similar so it is drawn whenever the box
is drawn. Use my_box->image(my_RGB_image) for this. This avoids deriving
an own class.
MacArthur, Ian (Selex ES, UK)
May 29, 2015, 6:52:03 AM5/29/15
to fltkg...@googlegroups.com
> As Greg wrote already you can't call drawing methods outside a drawing
> context, i.e. usually only in a draw() method. Under some circumstances
> you can get such a drawing context elsewhere by using
> Fl_Window::make_current(), but that is most likely not what you want to
> do.
And before the first window is mapped, it is very unlikely that make_current() will return a valid graphic context anyway...
> context, i.e. usually only in a draw() method. Under some circumstances
> you can get such a drawing context elsewhere by using
> Fl_Window::make_current(), but that is most likely not what you want to
> do.
bogdanul2003
Jun 12, 2015, 8:55:58 AM6/12/15
to fltkg...@googlegroups.com, ian.ma...@selex-es.com
Thanks guys, fixed the problem. Now I have another one :)
I am trying to run the same application on two different targets: my PC and a openwrt based board. It works fine except that Fl_RGB_Image's are not drawn the same on both targets. On PC, which is an ubuntu 14.04, the RGB images are displayed transparent but on the device you can see a black square behind each RGB image. The round part of the slider has a transparent part that is displayed with the required transparency but the background is black.
I couldn't trace the source of the problem yet ... maybe someone has an idea.
I've attached some pictures.
Greg Ercolano
Jun 12, 2015, 11:26:16 AM6/12/15
to fltkg...@googlegroups.com
On 06/12/15 05:55, bogdanul2003 wrote:
> I am trying to run the same application on two different targets: my PC and a openwrt based board. It works fine except that Fl_RGB_Image's are not drawn the same on both targets. On PC, which is an ubuntu 14.04, the RGB images are displayed transparent but on the device you can see a black square behind each RGB image. The round part of the slider has a transparent part that is displayed with the required transparency but the background is black.
> I couldn't trace the source of the problem yet ... maybe someone has an idea.
> I've attached some pictures.
Hmm:
> I am trying to run the same application on two different targets: my PC and a openwrt based board. It works fine except that Fl_RGB_Image's are not drawn the same on both targets. On PC, which is an ubuntu 14.04, the RGB images are displayed transparent but on the device you can see a black square behind each RGB image. The round part of the slider has a transparent part that is displayed with the required transparency but the background is black.
> I couldn't trace the source of the problem yet ... maybe someone has an idea.
> I've attached some pictures.
1) Let's see your code if it's a few pages of code or less.
2) Try these two examples on both platforms and report any
differences:
http://seriss.com/people/erco/fltk/#AlphaBlend
http://seriss.com/people/erco/fltk/#MultiColorBarGraph
3) What version of fltk? Try the latest version of fltk from svn:
svn co http://seriss.com/public/fltk/fltk/branches/branch-1.3/ fltk-1.3.x-svn
(If prompted for a username/password, just hit ENTER for both.)
imm
Jun 13, 2015, 4:42:39 AM6/13/15
to general fltk
On Jun 12, 2015 4:26 PM, "Greg Ercolano" wrote:
> Hmm:
>
> 1) Let's see your code if it's a few pages of code or less.
>
> 2) Try these two examples on both platforms and report any
> differences:
>
> http://seriss.com/people/erco/fltk/#AlphaBlend
> http://seriss.com/people/erco/fltk/#MultiColorBarGraph
>
> 3) What version of fltk? Try the latest version of fltk from svn:
> svn co http://seriss.com/public/fltk/fltk/branches/branch-1.3/ fltk-1.3.x-svn
>
I agree with Greg; I think we need to see a minimal compilable example that shows the fault.
To me it looks like the version on the WRT board is not handling the alpha correctly. (Speculation...)
Maybe the Xserver doesn't know how to do alpha, or perhaps you are using an old version of FLTK?
What Xserver is on the WRT device and what versions of FLTK are you using?
And; are you using NanoX on the WRT device? If so, that might be the problem, I suspect.
As an extra test point, how does the "pulsing slider" example I posted look on each platform?
I don't think it depends on alpha so might be a useful comparison.
Cheers,
--
Ian
Sent, perhaps surprisingly from my Fairphone FP1
bogdanul2003
Jun 13, 2015, 9:05:41 AM6/13/15
to fltkg...@googlegroups.com
Hi,
I'm using nano-X on the WRT device. I managed to do the this test for now http://seriss.com/people/erco/fltk/#AlphaBlend
I attached a pic with the output which doesn't look so great :) It might be indeed because of nanoX. On PC it behaves as described in the webpage.
Can you recommend a fix for this issue ? .., I know it's not FLTK related but maybe you had the same problem at some point.
bogdanul2003
Jun 13, 2015, 9:31:00 AM6/13/15
to fltkg...@googlegroups.com
Also here is the nano-X config file.
I take the source code from here ftp://microwindows.censoft.com/pub/microwindows/microwindows-full-snapshot.tar.gz
bogdanul2003
Jun 13, 2015, 12:05:39 PM6/13/15
to fltkg...@googlegroups.com
I found a lot of discussions on the nanox mailing list regarding images with alpha channel and it seems they do have a problem with it. I also found some patches on their ftp regarding alhpa channel but I don't know if this should do the trick ... I'll test later but maybe some of you already used it and you know if it works or not:
ftp://microwindows.censoft.com/pub/microwindows/patches/hold92/patch-8bpp-greyscale-32bpp-alpha.diff
In this thread they talk about that nanox supports only ARGB format and if I'm not wrong, the wifi_icon.cxx file that I generated form a .png file is in RGBA format? (nut sure ... maybe this is an issue too)
imm
Jun 13, 2015, 3:08:36 PM6/13/15
to general fltk
Hmm OK.
If you are using nanoX that will be what's causing the problem.
But note that the fix is not just patches to nanoX, you will need to figure out how to update the fltk nanoX port to take advantage of the alpha blending capability once nanoX provides it...
Fltk support for alpha blending is still relatively recent on other platforms and I don't think it is on the nanoX port at all.
I would not assume that getting alpha blending working on nanoX on your platform would automatically get it working with fltk on that platform...
Can you run a real X server (kdrive / tinyX / whatever) on openWRT? If so that might be the easier option than nanoX.
bogdanul2003
Jun 14, 2015, 12:53:37 PM6/14/15
to fltkg...@googlegroups.com
Can you please tell me how FLTK does the alpha blending ? Since this is a software alpha blending I guess that fltk needs to get the current background or the current image and apply the alpha channel stuff to the existing image.
Where is the place or how does fltk get the current image and apply the alpha channel ?
Ian MacArthur
Jun 14, 2015, 5:13:19 PM6/14/15
to fltkg...@googlegroups.com
On Sun Jun 14 2015 17:53:37, bogdanul2003 wrote:
> Can you please tell me how FLTK does the alpha blending ?
FLTK doesn’t, as such - rather, FLTK uses whatever platform specific methods the underlying OS provides to do the blending, for those platforms that support it.
> Can you please tell me how FLTK does the alpha blending ?
At present, fltk can detect and use alpha-blending abilities with OSX Quartz, WinGDI and recent X11 implementations.
But it currently does not work with nanoX (due to nanoX’s support for blending being questionable) and probably would not work with a nanoX server patched to provide blending, unless the patched version happened to look enough like X11 that it Just Worked by lucky happenstance.
> Since this is a software alpha blending I guess that fltk needs to get the current background or the current image and apply the alpha channel stuff to the existing image.
If the underlying platform supports accelerated blending, fltk attempts to use that. Otherwise... not always great... (as you have found...)
If not, you can perhaps use XPM images with a bit mask to do “barn door” blending - fltk should support that on any platform I think (at least, it used to, anyway) and that may be adequate for your needs in this case.
But that is a quite different thing from alpha blending in practice.
I do think it is your best bet though.
> Where is the place or how does fltk get the current image and apply the alpha channel ?
But I don’t think that will help you with nanoX.
If you want to try doing software blending yourself on an “unpatched” nanoX, that might not be too hard; you’d want to use fl_read_image() to read back a rectangle from the underlying area, and render your button image into an fl_offscreen() surface, then “manually” blend the two images and blit the result back onto the display.
Of course, you need to hang onto the original data that fl_read_image() grabbed, so that you can “restore” the display to normal before you start the next iteration...
It is a pain, but can work.
Using several fl_offscreen surfaces to manage all the widgets you want to blend can make it easier, as then you just need to blit the final result to the display and do not have to deal with restoring the original before you draw the next...
Take a look at whether XPM images will work for you first though, I suggest, as that may be good enough (assuming it actually works, which it should!)
bogdanul2003
Jun 15, 2015, 6:35:18 AM6/15/15
to fltkg...@googlegroups.com
Thanks Ian ... I'll try the XPM pictures first.
But just for my understanding ... I was talking about software blending because my TFT screen has as input data in RGB:565 - 16 bit per pixel and there is no place for the alpha channel in there. So I guess that framebuffer driver must receive the image that is already blended in order for it to send it in the required format of the TFT. So nanoX or FLTK must do the alpha blending through software. Is the terminology used wrong or my understanding is wrong ? When you say accelerated blending you mean by some hardware chip ?
I think I can get kdrive on openwrt ... which you said is compatible with FLTK and blending. Taking into account that I have limited hardware to work with, will kdrive do software or accelerated blending ?
MacArthur, Ian (Selex ES, UK)
Jun 15, 2015, 8:44:55 AM6/15/15
to fltkg...@googlegroups.com
> Thanks Ian ... I'll try the XPM pictures first.
Definitely worth a shot: I think one of the samples in the test folder does some stuff with masking XPM values. Or... I might just be making that up...
> But just for my understanding ... I was talking about software blending
> because my TFT screen has as input data in RGB:565 - 16 bit per pixel
> and there is no place for the alpha channel in there.
> So I guess that
> framebuffer driver must receive the image that is already blended in
> order for it to send it in the required format of the TFT. So nanoX or
> FLTK must do the alpha blending through software.
So usually it goes something like:- FLTK thinks it is 888[8] RGB[A] and pushes those pixels to the server; then the server handles the compositing and blending (at which point the A channel is gone) and pushes the resulting pixels to the display driver; the display driver pushes them onto the screen.
Where the data is collapsed from 888 to 565 I am not sure, might be in nanoX, but I thought it was in the display driver.
> Is the terminology
> used wrong or my understanding is wrong ? When you say accelerated
> blending you mean by some hardware chip ?
> I think I can get kdrive on openwrt ... which you said is compatible
> with FLTK and blending. Taking into account that I have limited hardware
> to work with, will kdrive do software or accelerated blending ?
Specifically, I have used kdrive with a GUI that needed blended images under fltk, and the result looked "the same" as my desktop reference system, so that might be good enough for you.
That said, if the XPM stuff works, you are maybe good to go anyway.
Greg Ercolano
Jun 15, 2015, 1:11:29 PM6/15/15
to fltkg...@googlegroups.com
On 06/14/15 14:13, Ian MacArthur wrote:
> On Sun Jun 14 2015 17:53:37, bogdanul2003 wrote:
>> Can you please tell me how FLTK does the alpha blending ?
>
> FLTK doesn’t, as such - rather, FLTK uses whatever platform specific methods the underlying OS provides to do the blending, for those platforms that support it.
> At present, fltk can detect and use alpha-blending abilities with OSX Quartz, WinGDI and recent X11 implementations.
> But it currently does not work with nanoX (due to nanoX’s support for blending being questionable) and probably would not work with a nanoX server patched to provide blending, unless the patched version happened to look enough like X11 that it Just Worked by lucky happenstance.
FWIW, there is some software based alpha blending code in FLTK:
> On Sun Jun 14 2015 17:53:37, bogdanul2003 wrote:
>> Can you please tell me how FLTK does the alpha blending ?
>
> FLTK doesn’t, as such - rather, FLTK uses whatever platform specific methods the underlying OS provides to do the blending, for those platforms that support it.
> At present, fltk can detect and use alpha-blending abilities with OSX Quartz, WinGDI and recent X11 implementations.
> But it currently does not work with nanoX (due to nanoX’s support for blending being questionable) and probably would not work with a nanoX server patched to provide blending, unless the patched version happened to look enough like X11 that it Just Worked by lucky happenstance.
----
#if !defined(WIN32) && !defined(__APPLE__)
// Composite an image with alpha on systems that don't have accelerated
// alpha compositing...
static void alpha_blend(Fl_RGB_Image *img, int X, int Y, int W, int H, int cx, int cy) {
[..alpha blending code..]
----
..which appears to:
1) fl_read_image() to grab a snapshot of the current display
2) apply the input image to it
3) merges the result back using fl_draw_image()
Note: fl_read_image() can sometimes be a bit slow for some purposes,
but perhaps it's "fast enough" for what you need..
I didn't check under which circumstances that code is used, but it
appears to be a fallback if it can't do the hardware blending.
You (OP) might want to check what the value of fl_can_do_alpha_blending()
returns on your system, as I *think* that's what the Fl_Image code tests
to see if hardware alpha blending is available.
The fact the app on nanoX is having trouble could mean that FLTK's
code that detects hardware alpha capabilities is saying 'yes',
but the system isn't actually doing it right, as apparently the above
fallback code should be getting used if the hardware support isn't there.
OP, perhaps you can work around by forcing fl_can_do_alpha_blending()
to return 0 on your nanoX system to see if it falls back to using
the above software technique, and possibly that will work for you.
I can tell you the fallback code is *not* being triggered on my linux
machine when I build and run the "Alpha Blending with PNG files" cheat
example I posted earlier; it's using the hardware technique defined in
Fl_Xlib_Graphics_Driver::draw().
It seems the above alpha_blend() code wasn't intended to be public
(it's static and has no fl_ prefix), but you can probably nab that bit
of code to apply the alpha yourself.
Ian MacArthur
Jun 15, 2015, 4:33:57 PM6/15/15
to fltkg...@googlegroups.com
On 15 Jun 2015, at 18:11, Greg Ercolano wrote:
> It seems the above alpha_blend() code wasn't intended to be public
> (it's static and has no fl_ prefix), but you can probably nab that bit
> of code to apply the alpha yourself.
But I honestly think the OP can get satisfactory results without blending at all, either just by drawing circular features directly, or by using barn-door masks. as the XPM code does (or used to do, anyway. Does it still?).
If performance is really a concern (as was hinted earlier, and may well be true on an openWRT router board I guess) then either of these is likely to be less resource-heavy than blending.
Albrecht Schlosser
Jun 15, 2015, 5:49:15 PM6/15/15
to fltkg...@googlegroups.com
On 15.06.2015 22:33 Ian MacArthur wrote:
> But I honestly think the OP can get satisfactory results without blending at all, either just by drawing circular features directly, or by using barn-door masks. as the XPM code does (or used to do, anyway. Does it still?).
Yes, it does.
> But I honestly think the OP can get satisfactory results without blending at all, either just by drawing circular features directly, or by using barn-door masks. as the XPM code does (or used to do, anyway. Does it still?).
http://www.fltk.org/str.php?L3206
http://www.fltk.org/strfiles/3206/Fl_Pixmap_r10753.patch
PS: (OT) I'd appreciate comments and test results for the patch
mentioned above (on the STR or in fltk.coredev).
bogdanul2003
Jun 19, 2015, 2:56:19 AM6/19/15
to fltkg...@googlegroups.com, Albrech...@online.de
Hi,
I was away for a while and couldn't do any more tests.
Today I can confirm that XPM images with alpha channel work great on my device.
About the static void alpha_blend in FLTK ... I looked in the code and it doesn't depend on fl_can_do_alpha_blending(). The execution of alpha_blend() depends on img->id_ which is a private variable of Fl_RGB_Image. I tried to follow the code and see what values it might get and to what I can see this code should trigger every time since id_ is 0 when Fl_RGB_Image is initialised and nothing changes after that.
I would still like to use PNG images since I have all the tools needed to make a .c file out of a PNG and use the data built in the binary file.
Can someone take a look at the code in Fl_Xlib_Graphics_Driver::draw() and maybe you have a better idea ?
Thanks.
MacArthur, Ian (Selex ES, UK)
Jun 19, 2015, 5:18:59 AM6/19/15
to fltkg...@googlegroups.com
> Today I can confirm that XPM images with alpha channel work great on my
> device.
OK, that sounds good.
> device.
Using XPM images is probably your safest bet then, since it will work on nanoX.
> About the static void alpha_blend in FLTK ... I looked in the code and
> it doesn't depend on fl_can_do_alpha_blending(). The execution of
> alpha_blend() depends on img->id_ which is a private variable of
> Fl_RGB_Image. I tried to follow the code and see what values it might
> get and to what I can see this code should trigger every time since id_
> is 0 when Fl_RGB_Image is initialised and nothing changes after that.
But for this application, the barn-door masking that XPM images yeild seems likely to be fine.
> I would still like to use PNG images since I have all the tools needed
> to make a .c file out of a PNG and use the data built in the binary
> file.
Using XPM for small button images and labels is much simpler than using PNG, you don't need any extra tools at all. Maybe just a text editor - which we can safely assume you already have!
> Can someone take a look at the code in Fl_Xlib_Graphics_Driver::draw()
> and maybe you have a better idea ?
bogdanul2003
Jun 21, 2015, 3:19:00 AM6/21/15
to fltkg...@googlegroups.com, ian.ma...@selex-es.com
Yes ... I guess you're right about nanoX support ... there is not so much activity in that direction.
The problem that I see with XPM files is that I can't choose the transparency level ... it's either transparent or not ... as far as I understand from the XPM file format I found on the net. Am I wrong about this ?
About the FLTK code and "static void alpha_blend() " function. I debugged the code and this function really gets called on my device so FLTK does a software blending but the result is not the expected one ... couldn't figure out yet why that is. So after the alpha blending the transparent colour becomes black and I can see that it blends semi transparent stuff correctly but the background is this black colour. This makes me think that there might be a colour issue in nanoX or nXlib. What do you think?
I could give up on semitransparent stuff and just use XPM images but I would like to give it a try in fixing this software blending problem before giving up.
Georg Potthast
Jun 21, 2015, 11:41:06 AM6/21/15
to fltkg...@googlegroups.com, ian.ma...@selex-es.com
I use XPM images as icons with my Nanolinux. I have an icon editor that allows to mark certain pixels as transparent color so the icon is not shown as a rectangle box on the wallpaper.
Erco has an example how to display XPM images with transparent color:
http://seriss.com/people/erco/fltk/#DraggableBoxes
This works with Nano-X.
Georg
Erco has an example how to display XPM images with transparent color:
http://seriss.com/people/erco/fltk/#DraggableBoxes
This works with Nano-X.
Georg
MacArthur, Ian (Selex ES, UK)
Jun 22, 2015, 4:39:48 AM6/22/15
to fltkg...@googlegroups.com
> The problem that I see with XPM files is that I can't choose the
> transparency level ... it's either transparent or not ... as far as I
> understand from the XPM file format I found on the net. Am I wrong about
> this ?
XPM images use, I believe, what we used to call "barn-door" masking; the door is either open or closed, there is no in-between...
> transparency level ... it's either transparent or not ... as far as I
> understand from the XPM file format I found on the net. Am I wrong about
> this ?
XPM dates back to a simpler time.
But that also means it tends to work everywhere.
> About the FLTK code and "static void alpha_blend() " function. I
> debugged the code and this function really gets called on my device so
> FLTK does a software blending but the result is not the expected one ..
. > couldn't figure out yet why that is. So after the alpha blending the
> transparent colour becomes black and I can see that it blends semi
> transparent stuff correctly but the background is this black colour.
> This makes me think that there might be a colour issue in nanoX or
> nXlib. What do you think?
The nanoX support seems to be something of a niche, and if it actually requires patches to nanoX too, I doubt there is all that much we can do about it.
> I could give up on semitransparent stuff and just use XPM images but I
> would like to give it a try in fixing this software blending problem
> before giving up.
If you want to try the semi-transparent stuff, then (rather than trying to fix what's there) I'd be inclined to try using fl_offscreen surfaces to render the widgets, then do a modicum of manual blending to produce the final image for display.
That should be platform neutral, and likely not all that hard to do in practice.
Georg Potthast
Jun 23, 2015, 2:04:28 AM6/23/15
to fltkg...@googlegroups.com, ian.ma...@selex-es.com
I looked at the config file for nano-X that you posted. You may want to check this section:
# define MWPF_TRUECOLOR8888 /* pixel is packed 32 bits A/R/G/B truecolor w/alpha*/ # define MWPF_TRUECOLORABGR /* pixel is packed 32 bits A/B/G/R truecolor w/alpha*/ # define MWPF_TRUECOLOR0888 /* pixel is packed 32 bits 0/R/G/B truecolor 0 alpha*/ # define MWPF_TRUECOLOR888 /* pixel is packed 24 bits 8/8/8 truecolor*/ # define MWPF_TRUECOLOR565 /* pixel is packed 16 bits 5/6/5 truecolor*/ # define MWPF_TRUECOLOR555 /* pixel is packed 16 bits 5/5/5 truecolor*/ # define MWPF_TRUECOLOR332 /* pixel is packed 8 bits 3/3/2 truecolor*/ # #################################################################### SCREEN_PIXTYPE = MWPF_TRUECOLOR888
Since you specified MWPF_TRUECOLOR888 you selected a pixeltype which does not support alpha blending.
Only MWPF_TRUECOLOR8888, MWPF_TRUECOLORABGR and MWPF_TRUECOLOR0888 will do that.
By the way here is an example for alpha blending with Microwindows: http://www.microwindows.org/SSWin32.html
The patch you found was made for a previous version of Microwindows.
Georg
Georg Potthast
Jun 23, 2015, 2:32:49 AM6/23/15
to fltkg...@googlegroups.com, ian.ma...@selex-es.com
I just tried Erco's example http://seriss.com/people/erco/fltk/#AlphaBlend with my nano-X version for DOS and it worked fine with alpha blending.
Georg
Georg Potthast
Jul 4, 2015, 2:02:15 AM7/4/15
to fltkg...@googlegroups.com, ian.ma...@selex-es.com
Hi Bogdanul,
you wrote that you made a driver for your touch screen device. If you could post that here I will add it to the other nano-X drivers.
Georg
Am Dienstag, 19. Mai 2015 09:10:07 UTC+2 schrieb bogdanul2003:
you wrote that you made a driver for your touch screen device. If you could post that here I will add it to the other nano-X drivers.
Georg
Am Dienstag, 19. Mai 2015 09:10:07 UTC+2 schrieb bogdanul2003:
Hi,I managed after some time to make the touch screen working with fltk using named pipes ... it wasn't that hard since it easy to add a new touch screen to nanoX.
Reply all
Reply to author
Forward
0 new messages