Getting started with FLTK

335 views
Skip to first unread message

Adrian Nita

unread,
Jun 20, 2014, 5:55:34 AM6/20/14
to fltkg...@googlegroups.com
Hi all,

I intend to create a very basic GUI on top of X11 (Linux) using FLTK. As I am new to this and still gathering information, I have a few questions about this topic:

1. Is it possible to build a fullscreen GUI on top of a bare X11 system (no GNOME, no KDE, no desktop environment)?

2. What is the OpenGL support in FLTK best suited for (need examples)? It's not clear for me (and I couldn't find in the docs) what are the upsides and downsides for using OpenGL. And also, how is a OpenGL window, for example, different from a regular FLTK window?

3. How customizable are FLTK windows? Is it possible to change the visual appearance of title bars, close/minimize buttons, borders etc.?

Thank you,
Adrian

Georg Potthast

unread,
Jun 20, 2014, 11:07:27 AM6/20/14
to fltkg...@googlegroups.com
Hi Adrian,

there is a GUI written in FLTK: http://www.equinox-project.org/

Also, for my Nanolinux distribution I wrote a very basic GUI : http://sourceforge.net/projects/nanolinux/

These examples show how a GUI can be done in FLTK.

Georg

G B

unread,
Jun 20, 2014, 11:09:32 AM6/20/14
to fltkgeneral
Hi Adrian!

1. Yes, it's possible! I've actually done this myself - created a program that runs instead of the desktop environment in full screen (I use it for my toddler - so he can't alt-tab or do any other damage from the game I wrote for him). This isn't FLTK specific though - you can replace your desktop environment with almost any program (even firefox, for example)

2. OpenGL is mostly for graphics intensive (e.g. 3D graphics) applications. Not for buttons or simple graphics. I haven't used OpenGL that much - so I can't answer in more details - but if you want exclusively OpenGL graphics, maybe FLTK isn't the best option? You can use the builtin windowing system of OpenGL.

3. I don't know... :(


--
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.

Greg Ercolano

unread,
Jun 20, 2014, 11:51:19 AM6/20/14
to fltkg...@googlegroups.com
On 06/20/14 02:55, Adrian Nita wrote:
1. Is it possible to build a fullscreen GUI on top of a bare X11 system (no GNOME, no KDE, no desktop environment)?

    Yes, you can just run any application under X without the window manager running.

    The app will open in a plain rectangle that you can't interactively position, but if you
    tell the app where to position itself (size and position), it will display at that position.

    Most X applications support size + position with the -geometry command line option,
    or the position/size can be hard coded into the app.

    Since a raw X root window without a window manager isn't very interactive,
    it helps to use e.g. ssh to connect to the machine and run the programs
    to display on the root window.

    On linux/bsd, FLTK apps are really X applications, so FLTK apps will run just
    like X windows apps, and can be displayed either fullscreen or as smaller windows
    inside the raw X root window even without a window manager.


2. What is the OpenGL support in FLTK best suited for (need examples)? It's not clear for me (and I couldn't find in the docs) what are the upsides and downsides for using OpenGL. And also, how is a OpenGL window, for example, different from a regular FLTK window?

    OpenGL is mainly used for hardware accelerated 3D rendering, such as rendering
    fully lit 3D models in realtime.

    See the wikipedia page for details on what opengl is.

    OpenGL windows differ from FLTK windows in that one should only use opengl drawing commands
    to draw inside that rectangular area.

    FLTK drawing commands + widgets aren't allowed in side of it, however events (mouse clicks and keyboard)
    are managed by FLTK (opengl is a visual library only, it doesn't cover event management, which is what FLTK
    handles for you), and FLTK popup menus can be displayed over opengl windows so as to give the user
    some way to access widget like control within the opengl area.

    FLTK provides access to opengl via the Fl_Gl_Window class. It defines a rectangular region
    that provides access to opengl calls. The test/cube example program demonstrates a mix of
    opengl and FLTK. There's also some examples on my cheat sheet over here:

    Very simple 'hello world' style FLTK/OpenGL app: "draw an X"
    http://seriss.com/people/erco/fltk/#OpenGlSimple

    Simple mix of FLTK widgets and OpenGL "X":
    http://seriss.com/people/erco/fltk/#OpenGlSimpleWidgets

    Very simple static "render a 3D sphere with a single light" that doesn't move:
    http://seriss.com/people/erco/fltk/#OpenGLSphereWithLight

    A fully rendered and realtime animated spinning 3D cube with texture mapping:
    http://seriss.com/people/erco/fltk/#OpenGLTextureMappedImage
   
    That last example demonstrates the kind of thing openGL excels at; 3D animation.
    There's other examples of openGL on that page; just search for "opengl" to find them all.


3. How customizable are FLTK windows? Is it possible to change the visual appearance of title bars, close/minimize buttons, borders etc.?

    The visual appearance of the window decorations is entirely under the control of the window manager.

    If you want to control this yourself, you can make the FLTK window borderless, and then make the titlebar,
    stow/close buttons, drag behavior etc. yourself.

    Or if you don't run a window manager and just run X, you'll get borderless windows by default
    when you run the app.

Adrian Nita

unread,
Jun 20, 2014, 12:14:49 PM6/20/14
to fltkg...@googlegroups.com
Thank you for the replies.

If you want to control this yourself, you can make the FLTK window borderless, and then make the titlebar, stow/close buttons, drag behavior etc. yourself.

@Greg - how can this be done? Does FLTK provide any means to do this, or is there something else that I'm missing?

Regards,
Adrian

Greg Ercolano

unread,
Jun 20, 2014, 12:21:42 PM6/20/14
to fltkg...@googlegroups.com
On 06/20/14 09:14, Adrian Nita wrote:
> Thank you for the replies.
>
> If you want to control this yourself, you can make the FLTK window borderless
> and then make the titlebar, stow/close buttons, drag behavior etc. yourself.
>
> @Greg - how can this be done? Does FLTK provide any means to do this,
> or is there something else that I'm missing?

FLTK provides widgets like buttons and boxes that let will let you
define the frame of the window as you like.

I don't think there's an explicit of exactly this, but it's kinda
trivial to make. If you can create a box and a couple of buttons,
your 75% of the way there. The other 25% would be if you want the user
to be able to drag + resize the window around; that's pretty much just
handling the events and making them control the position() and size().

If I find some time, I can maybe provide an example.

Greg Ercolano

unread,
Jun 20, 2014, 3:04:29 PM6/20/14
to fltkg...@googlegroups.com
On 06/20/14 09:21, Greg Ercolano wrote:
> On 06/20/14 09:14, Adrian Nita wrote:
>>     If you want to control this yourself, you can make the FLTK window borderless
>>     and then make the titlebar, stow/close buttons, drag behavior etc. yourself.
>>
>> @Greg - how can this be done? Does FLTK provide any means to do this,
>> or is there something else that I'm missing?
>
>     FLTK provides widgets like buttons and boxes that let will let you
>     define the frame of the window as you like.
>
>     I don't think there's an explicit [example] of exactly this, but it's kinda
>     trivial to make. [..] If I find some time, I can maybe provide an example.

    Here's at least a starting point; a borderless window that defines its own
    "window manager" decorations, and allows window dragging.

    It's an exercise to the reader to add things like window resizing, changing
    mouse cursors, popup menu, and other window management functions.

    It's of course not advised to do this sort of thing unless you're doing
    something weird (like running without a window manager):

    The "window manager" decorations are all done by the FLTK code shown
    in the MyAppWindow class below. I made it look sort of like an SGI window.

    Here's a screenshot of this app running on the mac:
    http://seriss.com/people/erco/fltk/tmp/fltk-custom-window-decorations.jpg

    ..and here's the code. It doesn't do 'everything', but it's a good starting point:

#include <FL/Fl.H>
#include <FL/Fl_Window.H>
#include <FL/Fl_Box.H>
#include <FL/Fl_Button.H>
#include <FL/fl_draw.H>

//
// Demonstrate an app with "custom window manager decorations"
//
//     06/20/14 erco 1.0
//     xx/xx/xx xxx  x.x
//

#define BORDER_WIDTH 5
#define TITLE_HEIGHT 23

// Small application window class implements custom window decorations
//    TODO: Resizing, mouse cursor to indicate move/resizing, etc..
//
class MyAppWindow : public Fl_Window {
  Fl_Box    *title;     // title bar
  Fl_Button *stow;      // stow button
  Fl_Button *close;     // close button
  Fl_Window *child;     // child window into which the app exists
  int xoff,yoff;        // offsets for dragging window around
  // Stow + close buttons..
  static void Button_CB(Fl_Widget *w, void *data) {
    MyAppWindow *app = (MyAppWindow*)data;
    if ( w == app->stow ) app->iconize();       // toggle stow
    if ( w == app->close ) app->do_callback();  // close parent window
  }
  // Initialize the window
  void Init() {
    int W = Fl_Window::w();
    int H = Fl_Window::h();
    const char *L = Fl_Window::label();
    Fl_Window::border(0);               // borderless parent window
    Fl_Window::box(FL_UP_BOX);          // window border style
    Fl_Window::color(0xa5a07400);       // window border color ("SGI" decoration)
    int bw = BORDER_WIDTH;
    int th = TITLE_HEIGHT;
    Fl_Window::begin();
      // Stow button
      stow = new Fl_Button(W-1-((th-8)*2)-bw, 5, th-8, th-8, "o");
      stow->labelfont(FL_HELVETICA_BOLD);
      stow->labelsize(10);
      stow->clear_visible_focus();
      stow->callback(Button_CB, (void*)this);
      // Close button
      close = new Fl_Button(stow->x()+stow->w(), stow->y(), stow->w(), stow->h(), "X");
      close->labelfont(FL_HELVETICA_BOLD);
      close->labelsize(10);
      close->clear_visible_focus();
      close->callback(Button_CB, (void*)this);
      // Title bar
      title = new Fl_Box(bw, 2, stow->x()-bw*2, th-4);
      title->box(FL_FLAT_BOX);
      title->color(color());
      title->align(FL_ALIGN_INSIDE|FL_ALIGN_LEFT|FL_ALIGN_CLIP);
      if ( L ) title->copy_label(L);
      // App child window
      child = new Fl_Window(bw, th, W-bw*2, H-th-bw);
      child->box(FL_FLAT_BOX);
  }
public:
  // CTOR
  MyAppWindow(int W,int H,const char*L=0)
    :Fl_Window(W+(BORDER_WIDTH*2),H+TITLE_HEIGHT+BORDER_WIDTH,L) {
    Init();
  }
  // Define some commonly used methods
  void begin() { child->begin(); }
  void end()   { child->end(); }
  // Get application's "child" window
  Fl_Window *window() { return child; }
  // Handle dragging the window
  int handle(int e) {
    int ret = Fl_Window::handle(e);
    switch (e) {
      case FL_PUSH:
        if ( Fl::event_button() == FL_LEFT_MOUSE ) {
          // Left click on window decoration? begin drag
          xoff = x() - Fl::event_x_root();
          yoff = y() - Fl::event_y_root();
          ret = 1;
        }
        break;
      case FL_DRAG:
        if ( Fl::event_button() == FL_LEFT_MOUSE ) {
          // Drag the window around the screen
          Fl_Window::position(xoff + Fl::event_x_root(), yoff + Fl::event_y_root());
          Fl_Window::redraw();
          ret = 1;
        }
        break;
      case FL_RELEASE:
        if ( Fl::event_button() == FL_LEFT_MOUSE ) ret = 1;
        break;
    }
    return ret;
  }
};

//
// Test the above class
//
#include <FL/Fl_Multi_Browser.H>

static void DoneCallback(Fl_Widget*, void*) {
  exit(0);
}
int main() {
  // CREATE INSTANCE OF OUR "CUSTOM DECORATIONS" WINDOW
  MyAppWindow *app = new MyAppWindow(640,480,"Test Application");


  // Make some arbitrary widgets to demo
  Fl_Multi_Browser *brow = new Fl_Multi_Browser(10,20,640-20,480-65,"Browser");
  brow->add("Aaa");
  brow->add("Bbb");
  brow->add("Ccc");
  Fl_Button done(640-90,480-35,80,25,"Done");
  done.callback(DoneCallback);

  app->show();
  return(Fl::run());
}

Ian MacArthur

unread,
Jun 20, 2014, 5:38:17 PM6/20/14
to fltkg...@googlegroups.com
On Fri Jun 20 2014 10:55:34, Adrian Nita wrote:

> I intend to create a very basic GUI on top of X11 (Linux) using FLTK. As I am new to this and still gathering information, I have a few questions about this topic:


I’m late to this, and I see others have already pitched in, but here’s mine anyway, FWIW!


> 1. Is it possible to build a fullscreen GUI on top of a bare X11 system (no GNOME, no KDE, no desktop environment)?

What is you programming experience with X11?

I’m asking because I don’t want to seem rude, so needed to know if you understand that on X11 the window manager is often (indeed, usually) a distinct entity separate from the desktop environment.

So a “bare” system might have no desktop environment but still have a fully functional window manager.

Or a “truly bare" system might not even have a WM; X11 itself is not a WM, it just pushes rectangles onto the display...

This is somewhat unlike what users coming from Windows or OSX might expect, so is worth stating.

Right: with that said:- In the past I have built “kiosk” systems, with fltk, that throw a fullscreen window up on a “truly bare” X11 system so it is certainly possible.

However, I wouldn’t go that path these days; rather I’d run some sort of minimal cut-down WM and have that manage the windows for me (if you need “windows” at all) rather than doing it myself. There are lots of *very tiny* but adequately capable WM kicking around as open source you could work with. I’ve had fun with aewm, and of course there is flwm which is based on fltk... albeit a pretty old version of fltk!

If you do not need movable windows but just need to show/hide widgets at known positions on the screen, then you probably can get by without the WM at all.

What do you actually need to do?



> 2. What is the OpenGL support in FLTK best suited for (need examples)? It's not clear for me (and I couldn't find in the docs) what are the upsides and downsides for using OpenGL. And also, how is a OpenGL window, for example, different from a regular FLTK window?

Once you create a Fl_Gl window, you draw to it using GL drawing calls, not fltk drawing calls, and you basically can not put fltk widgets inside a Fl_GL window.

On the other hand, if you want to do any fancy drawing, or 3D, or so on, the the GL drawing and rendering system is much more powerful than fltk’s basic 2D system. And probably faster since it leverages much more GPU acceleration than basic 2D render paths tend to. Though it is *much* more complicated...

What do you want to draw? Understanding what needs to be drawn should make the choice clearer.


> 3. How customizable are FLTK windows? Is it possible to change the visual appearance of title bars, close/minimize buttons, borders etc.?


If there is a WM, then, in general the drawing of the border and external window decorations is the responsibility of the WM, not of the application code, and they look the way they look on that platform, with that WM...

However, you can choose to make your window borderless, then the WM will not draw any frame, or any decorations and you can then draw them yourself (I think Greg posted some examples for doing that.)

I’ve done this, it’s a bit of a pain, but you have full control over the appearance; it often freaks out users though since if the app runs on a system with other “normal” windows present the disparate appearance and behaviours can be a source of confusion.

If you have full control of the system, and implement your own custom WM as I suggested in part (1), then of course you can just customise the WM to decorate the windows the way you want anyway, and the app then can just do the “normal” thing...






Adrian Nita

unread,
Jun 21, 2014, 5:56:06 PM6/21/14
to fltkg...@googlegroups.com
@Greg - Thanks for the interesting example. It really helps and I'll try to make one of my own. It's a bit unclear for me what is the child member used for in your class. I assume that the window(), begin(), end() use the child pointer with a reason so I will have a closer look.

@Ian - Thanks for your advice. I have little experience with X11 and GUI programming. My intention is to gather information, learn, and experiment by building a simple GUI with as little dependencies and overhead as possible, in order to understand how window systems and window managers work and interact with a library such as FLTK. I don't have a specific app in mind, but it could be a GUI that lets you manage some files, or displays some information in a nice font, or provides some buttons for restarting/halting the system.

And this gets me to another couple of questions:

- My system has the Ubuntu font installed in /usr/share/fonts/truetype/... It is a ttf file. How can I tell FLTK to use this font for labels and other text? The Fl::set_font method didn't work for loading a specific font file.

- Is there some way of grabbing the output of a command utility (like date or even ls) and use it as a label to display in FLTK?



On Friday, June 20, 2014 12:55:34 PM UTC+3, Adrian Nita wrote:

G B

unread,
Jun 21, 2014, 7:11:09 PM6/21/14
to fltkgeneral
Is there some way of grabbing the output of a command utility (like date or even ls) and use it as a label to display in FLTK?

You can grab the output of any command / executable in C itself, and then use the result as a label or text in FLTK.

To get the output of a command - I personally use popen - like this:

FILE *f=popen("ls -la *.cc","r");
// read like from a file, using fread or fscanf or whatever you want
pclose(f);

Just note that the command runs in a different process - it doesn't "start and finish" before you get a chance to read. So if the command takes too long, you might think you're done reading the output when in fact the output wasn't written yet.

You probably should use some kind of wait to make sure the command has finished.


--

Greg Ercolano

unread,
Jun 21, 2014, 9:21:17 PM6/21/14
to fltkg...@googlegroups.com
On 06/21/14 14:56, Adrian Nita wrote:
> @Greg - Thanks for the interesting example. It really helps and I'll try to make one of my own. It's a bit unclear for me what is the /child /member used for in your class. I assume that the /window(), begin(), end() /use the /child /pointer with a reason so I will have a closer look.

The "child" window is the app's window inside the decorations.
If you change its color to FL_GREEN you'll see what it is.

Keep in mind in this case the application is a /borderless/ window,
the app draws its own decorations. The area inside the decorations
is a subwindow into which the app puts its widgets.


Georg Potthast

unread,
Jun 22, 2014, 2:41:59 AM6/22/14
to fltkg...@googlegroups.com

- Is there some way of grabbing the output of a command utility (like date or even ls) and use it as a label to display in FLTK?

You may want to take a look at this example from Erco: http://seriss.com/people/erco/fltk/#SimpleTerminal

Adrian Nita

unread,
Jun 22, 2014, 7:39:11 AM6/22/14
to fltkg...@googlegroups.com
Hi,

The popen calls work very well for grabbing output from shell commands. Greg's examples in his Cheat Page are really helpful.

However, I couldn't make the truetype fonts work yet. What I'm doing is:

Fl::set_font(FL_SYMBOL, "verdana");
box->labelfont(FL_SYMBOL);

I tried that for several ttf fonts that I have installed (verdana, liberation, ubuntu, arial etc.) and nothing changes. And the labelsize() calls have no effect either. The only fonts that seem to work are those listed by the xlsfonts shell command, but these are X11 non-truetype fonts. I'm not sure if I need to do something special for ttf support. I use FLTK 1.3.2 compiled with the default options (and the default seems to have font support enabled).

Any ideas about this?

Thanks,
Adrian


On Friday, June 20, 2014 12:55:34 PM UTC+3, Adrian Nita wrote:

imm

unread,
Jun 22, 2014, 8:53:42 AM6/22/14
to general fltk

Adrian Nita wrote:

However, I couldn't make the truetype fonts work yet. What I'm doing is:

Fl::set_font(FL_SYMBOL, "verdana");
box->labelfont(FL_SYMBOL);

I tried that for several ttf fonts that I have installed (verdana, liberation, ubuntu, arial etc.) and nothing changes. And the labelsize() calls have no effect either. The only fonts that seem to work are those listed by the xlsfonts shell command, but these are X11 non-truetype fonts. I'm not sure if I need to do something special for ttf support. I use FLTK 1.3.2 compiled with the default options (and the default seems to have font support enabled).

########

You're system needs to have fontconfig enabled and have the dev packages for fontconfig and xft available.

If those dependencies are met then TT fonts should just work.

Try the font-chooser or utf8 sample demos from the test folder, and perhaps the rotated-text and unit test demos too and let us know how you get on. It sounds like fontconfig is not working for you for some reason...

--
Sent, perhaps surprisingly, from my Fairphone FP1

Adrian Nita

unread,
Jun 22, 2014, 10:33:31 AM6/22/14
to fltkg...@googlegroups.com
Thanks, Ian. Indeed, I hadn't installed libxft-dev. After installing it, I recompiled FLTK (after running ./configure --enable-xft), and TT fonts are working now. Atm I'm trying to find a way to specify a global font (face, size, color) for the entire app, or at least for a group of boxes (such as a Fl_Pack). It's unhandy to repeat labelfont() and labelcolor() for each label.

imm

unread,
Jun 22, 2014, 4:39:31 PM6/22/14
to general fltk
Adrian Nita wrote:

Atm I'm trying to find a way to specify a global font (face, size, color) for the entire app, or at least for a group of boxes (such as a Fl_Pack). It's unhandy to repeat labelfont() and labelcolor() for each label.

#############

There are a couple of ways to go with that;

- the C++ way is to derive your own widget derived from (say) Fl_Box that uses the font / size /colour you like then create all your boxes from that. Then you only have to do the settings once and all the widgets look the way you want.

- the hack sledgehammer way is to note that all widgets are set to FL_HELVETICA by default so if you use Fl:: set_font() to assign a different face to FL_HEKVETICA then *all* widgets get the new font... Similarly you can change the default values for FL_FOREGROUND_COLOR (or whatever) to change the default text colour, and so on... Less controlled than doing it "right" but OK for a quick hack!

Adrian Nita

unread,
Jun 22, 2014, 6:34:04 PM6/22/14
to fltkg...@googlegroups.com
Thanks. I try to stay away from quick hacks because sooner or later they'll turn against me or some other dev :) So I went for the OOP way. And related to this, I think that FLTK solves too many things by inheritance. And when I derive an apparently inoffensive Fl_Box, I inherit all the tree up to the Widget base class - and you just never know when one of your methods accidentally overrides some other method up in the chain.

imm

unread,
Jun 23, 2014, 3:59:59 AM6/23/14
to general fltk
Adrian Nita wrote:

Thanks. I try to stay away from quick hacks because sooner or later they'll turn against me or some other dev :)

## OK but it can be useful to know that the options exist, if only for the light they shed on inner workings!


So I went for the OOP way.

## I assume that worked OK?

And related to this, I think that FLTK solves too many things by inheritance. And when I derive an apparently inoffensive Fl_Box, I inherit all the tree up to the Widget base class - and you just never know when one of your methods accidentally overrides some other method up in the chain.

## not sure I understand your concern here. This is just what inheritance does and is true for any body of C++ code, or indeed for any language that implemented its flavour of OOP in that idiom. But only methods that you change are affected of course... If you are "extending" a method then you can have it call the base method then do your extensions. If you are "replacing" a method, well then you want it to override the method up the chain... What is it that is triggering your concerns here?

Adrian Nita

unread,
Jun 23, 2014, 4:58:03 AM6/23/14
to fltkg...@googlegroups.com
On Monday, June 23, 2014 10:59:59 AM UTC+3, Ian MacArthur wrote:

## I assume that worked OK?

Yes, it works ok so far. All common properties are set inside the class derived from Fl_Box.
 

## not sure I understand your concern here. This is just what inheritance does and is true for any body of C++ code, or indeed for any language that implemented its flavour of OOP in that idiom. But only methods that you change are affected of course... If you are "extending" a method then you can have it call the base method then do your extensions. If you are "replacing" a method, well then you want it to override the method up the chain... What is it that is triggering your concerns here?

I totally agree that this is what inheritance does, but my concern is that FLTK makes you overuse it. The problem is when I inherit some Fl widget class and I want to define my own method that shouldn't override anything:

class mypack : public Fl_Pack {
    public:
    void M();
}

In this simple case I will have to check what classes is Fl_Pack derived from, and then for each (Fl_Pack, Fl_Group, Fl_Widget) check if any of them has a method with the same signature. If it does and I don't want to override it, I will have to rename my M() method, and start over. And even if it doesn't, the library could presumably implement a new method Fl_Widget::M() in a future release, and my app will break (because it gets overridden unintentionally).

What I mean is that perhaps inheritance is best avoided when the tree goes more than 2-3 level deep, or when the classes we inherit from are not under our control.

Georg Potthast

unread,
Jun 23, 2014, 2:28:36 PM6/23/14
to fltkg...@googlegroups.com
The FLTK documentation lists all members of a class including all inherited members. So you can check if you override a member when making a new method.

If you are still afraid you can decorate your new methods yourself. If you name your methods "anita_label()" or "an_value()" you can be sure not to override any members.


Adrian Nita

unread,
Jun 25, 2014, 6:51:09 PM6/25/14
to fltkg...@googlegroups.com
Does anyone know if, with FLTK, it's possible to:

- Use some sort of transitions (like fade-out or fade-in) when hiding / showing a widget?
- Define a widget (e.g. Fl_Box) with a semi-transparent background color (RGBA)?
- Display Unicode symbols inside text widgets? (e.g. ⌚, ☎, ✂ etc.)

Thanks,
Adrian

Edzard Egberts

unread,
Jun 26, 2014, 2:18:43 AM6/26/14
to fltkg...@googlegroups.com
Adrian Nita schrieb:
> Does anyone know if, with FLTK, it's possible to:
>
> - Use some sort of transitions (like fade-out or fade-in) when hiding /
> showing a widget?

No, this is a characteristic of slow and bloated software, FLTK is much
too fast for things like that. If you like to see slow software doing
it's things, maybe it helps to underclock your computer seriously? ;o)

Michael Baeuerle

unread,
Jun 26, 2014, 4:37:21 AM6/26/14
to fltkg...@googlegroups.com
Adrian Nita wrote:
>
> Does anyone know if, with FLTK, it's possible to:
>
> - Use some sort of transitions (like fade-out or fade-in) when hiding /
> showing a widget?

I agree with Edzard, such perfomance-killing eye-candy is not compatible
with the F and L in FLTK.

> [...]
> - Display Unicode symbols inside text widgets?

FLTK 1.3 works with Unicode in UTF-8 representation internally.
Therefore it should be no problem to feed such data into a widget.

In your other thread you have written that the program should run on
X11. On this platform there is currently no support for glyph
substitution available (work is currently in progress on it). This means
you have to set a single font in the FLTK widget that contain all glyphs
that are required to render your string. It is currently not possible to
render a single string with glyphs from different fonts.

imm

unread,
Jun 26, 2014, 3:37:19 PM6/26/14
to general fltk
I see that others have replied, but here goes anyway...

On 25 June 2014 23:51, Adrian Nita wrote:
Does anyone know if, with FLTK, it's possible to:

- Use some sort of transitions (like fade-out or fade-in) when hiding / showing a widget?

​If you drive your own widgets then you can contrive to have them do that.
There's no built-in support for it in fltk though.

Edzard was perhaps being glib when he replied, but the point he made stands; that sort of eye-candy can be tricky to do portably in a ​cross-platform GUI toolkit, and is neither fast nor light.

If you have a need for that; you'll either need to write custom widgets in fltk, or consider a heavier toolkit; for example the recent iterations of QT, whilst not to my taste, work pretty well across multiple platforms, seem to be pretty reliable and robust, and have wide support - something like that might suit your needs better?


 
- Define a widget (e.g. Fl_Box) with a semi-transparent background color (RGBA)?

If, by ​transparent backgrounds, ​you mean transparency through to the desktop or to other applications, i.e. transparency outside of your own app, then you need to have a windowing system that supports compositing, and you need to hook into the WM services that provide compositing of windows with transparency.

Again, there's no light weight and portable way to do this, so fltk does not; we usually try to focus on features that can be applied uniformly across all platforms, though this does result in some "lowest common denominator" choices at times.

Transparency between widgets inside your own app window is easier to do but again will require you to derive custom widgets; it is not something we'd support by default.

 
- Display Unicode symbols inside text widgets? (e.g. ⌚, ☎, ✂ etc.)

​Sure; if the font you assign to the widget labels has the required glyphs, then they ought to just work. All fltk-1.3 labels are utf8 encoded, so it is only a matter of putting in the correct utf8 string for the glyphs...
The tricky part here is choosing the right font, the rest should be trivial.


Adrian Nita

unread,
Jun 27, 2014, 11:03:07 AM6/27/14
to fltkg...@googlegroups.com
Ok, thanks for your answers and information. As a side note, it seems that calling someWindow->fullscreen() has no effect on a 32-bit Fedora (20) with Gnome 3 or Mate desktops.

imm

unread,
Jun 27, 2014, 5:18:07 PM6/27/14
to general fltk
On 27 June 2014 16:03, Adrian Nita wrote:
Ok, thanks for your answers and information. As a side note, it seems that calling someWindow->fullscreen() has no effect on a 32-bit Fedora (20) with Gnome 3 or Mate desktops.


​Hmm, interesting: anyone else seeing issues with this?

the most recent Fedora I have is F17, where it works fine - I don't have anything with F20, nor anything running Mate (though IIRC Mate is an option on the RPi, so maybe one of them has it...)

​Anyway, as it stands I can not reproduce this behaviour; FWIW, it works fine on F17...



Adrian Nita

unread,
Jun 27, 2014, 7:38:32 PM6/27/14
to fltkg...@googlegroups.com
I'm trying to build and run a FLTK app on a command-line (non-GUI) install of Ubunutu. Everything was compiled ok, but I ran into this: Can't open display. This is probably due to lacking the xorg package (full X Windows System), although I have the libX11-dev and other libs in place (again, compilation works ok, everything is linked).

Can someone briefly explain how this works (the relation among FLTKapp > FLTK > X11)? Do I need a full install of X Window System, despite the fact that I won't use it? I just want my basic app to run in fullscreen, with no X11 window manager or anything.

Thanks.

Greg Ercolano

unread,
Jun 27, 2014, 9:57:16 PM6/27/14
to fltkg...@googlegroups.com
Keep in mind your FLTK app on linux is basically an
X application.

Like most X windows apps, you don't /need/ a window manager,
whether it's full screen or not, but you do need X running
and you do need the DISPLAY environment variable set appropriately
to access that server.

Put it this way: if you can't run e.g. "xterm" because you get
a 'Can't open display' , then you won't be able to run your
FLTK application either.

"Can't open display" can mean a lot of things, either the
DISPLAY variable isn't set, or is set to a value that is
pointing to a machine or port that is not actually
running X, or is being blocked for some reason (e.g. TCP
port 6000 is a typical port).

A typical value for DISPLAY is ":0.0" if your app
is running on the same machine as X is running on
(with or without a window manager) and it's the only
instance of X running, and it's using all default values.



imm

unread,
Jun 28, 2014, 4:56:36 PM6/28/14
to general fltk
On 28 June 2014 00:38, Adrian Nita wrote:
I'm trying to build and run a FLTK app on a command-line (non-GUI) install of Ubunutu. Everything was compiled ok, but I ran into this: Can't open display. This is probably due to lacking the xorg package (full X Windows System), although I have the libX11-dev and other libs in place (again, compilation works ok, everything is linked).

Can someone briefly explain how this works (the relation among FLTKapp > FLTK > X11)? Do I need a full install of X Window System, despite the fact that I won't use it?

​You will use the X window system.

You probably do not need a "full" install of it, whatever that may mean on your target system, but you do at least need the X server for your hardware, or nothing can get drawn.

 
I just want my basic app to run in fullscreen, with no X11 window manager or anything.
​​

​X11 is not a window manager - it is *only* a drawing mechanism; all it knows about is flinging pixels and a few basic drawing primitives (i.e. rectangles and lines) onto a display.

So you need enough of the X system to get yo​ur pixels on the display.

This probably entails at least:

- The appropriate X server for your display hardware (roughly speaking this is, in Win32 terms, the "driver" for your graphics card.)

- The fontconfig and XFT libraries to support text display, and rendering

- Maybe some GLX / Mesa / whatever stuff if you want Open GL support

- Probably a bunch of other stuff too that I can't recall...

You do not need to install a window manager of you do not want one (though many are so small that it might be a shame not to.)

You do not need to install any of the "desktop environments" like Gnome nad KDE and all that - these things all run on top of X, but they are no more a part of X than fltk is.

If I ask fltk-config what libs we are using, on this linux laptop, I get:

$ fltk-config --ldflags

-lfltk -lXcursor -lXfixes -lXext -lXft -lfontconfig -lXinerama -lpthread -ldl -lm -lX11

So, the libs we need are 

- fltk (duh!) 

(then some X specific support libs)
- Xfixes  (a library that "fixes" some traditional X issues)
- Xext    (the X extensions library)
- Xft     (anti-aliased font rendering)
- fontconfig (font manager, used by XFT)
- Xinerama (allows multi-head support and so forth; you probably do not need this)
- X11     (the core X library)

(and some system libs)
- pthreads (for thread support)
- dl  (for dynamic loader support)
- m   (maths libs)

So, that should give you and idea of the minimal set of X bits you can install and expect fltk to work reasonably. It may be possible to get away with less, but...



Adrian Nita

unread,
Jun 29, 2014, 5:41:15 PM6/29/14
to fltkg...@googlegroups.com
Okay. So it seems that on a Ubuntu minimal server install with no X, no GUI, just the default Linux console, you only need to apt-get install the "xorg" meta packages (that is comprised of several X11-related packages/dependencies) in order to run a FLTK app. In this case, the startx command will only start the xterm emulator, as there is no window manager.

The initial Linux console in such a setup has no $DISPLAY property as it cannot handle regular graphics (and it's useless to set it to :0 or another value) so it cannot initiate directly any X-based GUI app. First you need to startx, which takes you to xterm, and from there you can execute the FLTK app binary.

imm

unread,
Jun 29, 2014, 6:05:55 PM6/29/14
to general fltk
Adrian Nita wrote:

Okay. So it seems that on a Ubuntu minimal server install with no X, no GUI, just the default Linux console, you only need to apt-get install the "xorg" meta packages (that is comprised of several X11-related packages/dependencies) in order to run a FLTK app. In this case, the startx command will only start the xterm emulator, as there is no window manager.

The initial Linux console in such a setup has no $DISPLAY property as it cannot handle regular graphics (and it's useless to set it to :0 or another value) so it cannot initiate directly any X-based GUI app. First you need to startx, which takes you to xterm, and from there you can execute the FLTK app binary.

####

You can always just tweak the startx script, or make a new script based on it, that spawns your fltk app instead of the xterm when it starts X.

Adrian Nita

unread,
Jun 30, 2014, 7:46:54 AM6/30/14
to fltkg...@googlegroups.com
Although I currently use no window manager, I've seen that several system widgets (scrollbars, inputs, buttons) are available. I assume FLTK uses xlib to render those. Has anyone tried to customize a default scrollbar? From what I've tried, you can set its background with color() and the arrow color with labelcolor(). I couldn't change the scrollbar tab color, however.

Is there any way to do this? Or perhaps I should simulate my own scrollbar with a box and handle the FL_DRAG event from there?
Thanks.

imm

unread,
Jun 30, 2014, 4:49:14 PM6/30/14
to general fltk
On 30 June 2014 12:46, Adrian Nita wrote:
Although I currently use no window manager, I've seen that several system widgets (scrollbars, inputs, buttons) are available. I assume FLTK uses xlib to render those. Has anyone tried to customize a default scrollbar? From what I've tried, you can set its background with color() and the arrow color with labelcolor(). I couldn't change the scrollbar tab color, however.

Is there any way to do this? Or perhaps I should simulate my own scrollbar with a box and handle the FL_DRAG event from there?

​I'm not sure what you mean by "system widgets" here?

The widgets you name (scrollbars, inputs, buttons) are all fltk widgets, so can be tweaked, subclassed, derived-from, whatever, as you see fit to customize them how you like​; indeed you can look at the source for the various fltk "schemes" to see how these widget's appearance is tailored.

Also, there are some samples in the examples folder showing how scrollbars can be tweaked, and Greg has examples on his cheat pages of various other widget customization approaches.

What is it you actually want to do?

Adrian Nita

unread,
Jun 30, 2014, 6:42:38 PM6/30/14
to fltkg...@googlegroups.com
I'm trying to have a Fl_Help_View with variable text content and use a customized vertical scrollbar for longer texts. I want to control the color of the scrollbar slider, as well as that of the arrow buttons. But I think I'll have to override the draw() method to achieve such control over the scrollbar style.

Greg Ercolano

unread,
Jun 30, 2014, 7:00:35 PM6/30/14
to fltkg...@googlegroups.com
You could modify Fl_Help_View and add a couple of protected methods
named scrollbar() and hscrollbar() to let you access the scrollbar
widgets.

Arguably this should be available anyway (to be consistent with
FLTK's other widgets that offer access to their scrollbars).

Or, just take the Fl_Help_View* code, rename the widget (e.g. MyHelpView)
and modify to taste.


Adrian Nita

unread,
Jul 6, 2014, 5:02:13 AM7/6/14
to fltkg...@googlegroups.com
Hello,

Is there some way of embedding a command-line text-based program such as lynx or mutt inside a FLTK window? Thanks.

MacArthur, Ian (Selex ES, UK)

unread,
Jul 7, 2014, 7:55:48 AM7/7/14
to fltkg...@googlegroups.com
> Is there some way of embedding a command-line text-based program such
> as lynx or mutt inside a FLTK window? Thanks.

I was going to direct you to Greg's examples of using popen() etc. to capture output from command-line operations, but then I remembered that you'd already asked about that.

I'm guessing what you are asking here is about interactive terminal command line operation, then?

That's a much harder problem; though there was a thread on that very subject quite recently, so a trawl back through the archives over the past month or so might find something useful.


Years ago, I took a very quick stab at that, and it transpires that the results are still on the web, though the code is long since abandoned by me;

http://www.9edgedown.talktalk.net/flterm.html

Still up on an old ISP that I left many years ago...


Might work for you, though the code is a bit of a mess; I've used it to run vi and top and stuff, so it does sort of work.

Might be enough to give you an idea of how to get started, though I'd suggest you *not* use this code if you actually want something that works!



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.
********************************************************************

Ingwie Phoenix

unread,
Jul 7, 2014, 8:53:41 AM7/7/14
to fltkg...@googlegroups.com

Am 07.07.2014 um 13:55 schrieb MacArthur, Ian (Selex ES, UK) <ian.ma...@selex-es.com>:

>> Is there some way of embedding a command-line text-based program such
>> as lynx or mutt inside a FLTK window? Thanks.
>
> I was going to direct you to Greg's examples of using popen() etc. to capture output from command-line operations, but then I remembered that you'd already asked about that.
>
> I'm guessing what you are asking here is about interactive terminal command line operation, then?
>
> That's a much harder problem; though there was a thread on that very subject quite recently, so a trawl back through the archives over the past month or so might find something useful.
yup, that was me. If i wasnt busy with another project, I would be working on that. The hard part is mostly to draw the things and have FLTK windows think in „characters“ rather than pixels instead. Its possible, just not easy… ^^.

> Years ago, I took a very quick stab at that, and it transpires that the results are still on the web, though the code is long since abandoned by me;
>
> http://www.9edgedown.talktalk.net/flterm.html
>
> Still up on an old ISP that I left many years ago...
>
>
> Might work for you, though the code is a bit of a mess; I've used it to run vi and top and stuff, so it does sort of work.
>
> Might be enough to give you an idea of how to get started, though I'd suggest you *not* use this code if you actually want something that works!
Well it helped me, at least. :)
Reply all
Reply to author
Forward
0 new messages