Re: TIP #172: Improve UNIX Tk Look and Feel

From: Iain Findleton (ifindleton_at_yahoo.com)
Date: 03/15/04 

Date: Mon, 15 Mar 2004 12:26:12 -0500

Donal K. Fellows wrote:
> Iain B. Findleton wrote:
>
>> The idea behind FLTK is that it draws everything except the window
>> frame and its decorations. So, an application looks the same on any
>> platform that runs FLTK. The drawback to this is, I suppose, that
>> access to "native" widgets is blocked, so you can't enjoy the
>> benefits of a Windows DialogBox, for example. However, if you develop
>> an FLTK script on a Windows box, it will, outside of the native
>> frame, look the same under Linux, UNIX, S390,...
>
>
> Not everyone likes that. Some do, but some don't. I can remember the
> arguments^Wdiscussions here on c.l.t when 8.0 introduced Windows L&F to
> Tk. "Hotly debated" is a good description. :^)
>
> You note that FLTK is themeable. To what extent is this so? Does a
> theme also control the event handling? Can you (theoretically) make an
> app have the XP native look on OSX or on a GTK desktop? Do you default
> to trying to fit in with the user's desktop L&F, or do you start out
> from something that doesn't look like anything else by default?

Okay, to be strictly technical about Fltk, it has a "native" theme that
looks like clunky X, as in Tk's original L&F. This is improved by a
trivial change to the border width option for a widget, the result being
something that looks like clunky W95.

Beyond that, there are computed renderings that can generate a large
variety of appearances, and the possibility of using skins that are
either computed, or based on the use of images. Finally, there is an
OpenGL scheme that does flashy looking appearances that look like
burnished metal.

Fltk, the tool kit, is hokey when compared to GTK+, Qt, and Windows. Not
even in the same league. Doesn't even pretend to be. Its called the Fast
Light Tool Kit because its fast and light. The trade offs are,
relatively speaking, huge, and its definitely not for those who want the
latest L&F of these other tool kits which have huge investments in L&F.

Fltk does not know about the user's desktop below the level of the
decorated frame. it makes no attempt to find out about either the O/S
environment, or about the user's preferences associated with that
environment. It appears the same on all platforms that run Fltk. Same
colors, same widget size and shape, same widget behavior, same, same, same.

>
>> The lack of an emulation layer also means that the only inteface to
>> be learned is the FLTK interface. This consists of a single function,
>> draw, that returns nothing and takes no parameters. Makes writing a
>> new widget rather straightforward.
>
>
> So, how do you know what to draw if there aren't any parameters? :^)
> Please don't oversimplify.

// over ride the default widget drawing routine

void MyWidget::draw() {

        draw_box(); // default scheme border and background
        
        fl_line_style(2,0); // width = 2, style = SOLID
        fl_color(FL_RED); // Set the pen color to RED
        fl_circle(x(),y(),w(),h()); // Draw a circle
        fl_line_style(0); // reset the pen
        
        draw_label(); // a label if you have one
        }

That draws a red circle (ellipse) in a widget. Of course, in general one
would draw something more interesting. The idea is there is no device
structure to worry about. This is also a limitation of the tool kit.

>
>> The other thing that FLTK does that makes life easier, is that it
>> implements several container widgets that provide automatic geometry
>> management for children. No pack, no grid, no doing anything other
>> than constructing one or more children inside a container. The
>> children are sized, positioned and shrink wrapped automatically.
>> This, to me, makes life very simple when compared to Tk.
>
>
> Ah, so it effectively pre-binds frames/toplevels to GMs (to use Tk
> terms)? This technique is favoured a lot by C/C++ and Java programmers,
> but I don't really care for it myself.

Guilty! I am a C/C++ programmer. Java....no. I prefer Tcl...

It all depends on whether a
> widget exists which has the scheme that you are interested in; if it
> isn't already done, the non-Tk mechanism leaves you SOL.

How true. But, its philosophical. How many layout schemes are needed to
implement all possible layouts? I am sure that there are mathematicians
out there that can contribute to this question. Having thought about it,
it appeared to me that once you have a horizontal and a vertical scheme,
pretty well all possibilities for a 2 dimensional computer display are
covered. In any event, your observation is no different from the
situation with Tk, for example. If pack, place or grid don't make you
happy, you are SOL. (Actually, Tix has (had) an interesting scheme based
on springs. I thought about a widget that uses this one, but I had a
hard time understanding how to make use of it!)

>
>> A final "feature" I put in FLTK is "binary" distribution encoding for
>> source files. This makes it possible to send out things that users
>> can't tamper with easily. It doesn't need to keep things secret, just
>> keep control over what is being run, so when a call comes in, you
>> know what the user is talking about.
>
>
> Ah, but does the user know what they are talking about? ;^D

Typically, they don't care. They only know whether an application works
or doesn't. Only the hackers really want to know why, and typically its
not the hackers who authorize payments.
>
> FWIW, I view packaging and distribution to be a separate issue to GUI.
> The problem is that there are many issues to it that are not obvious to
> the casual observer, especially as application size and complexity
> increases. It all comes down to defining what "threats" you are
> defending the application, developer and users from.
>

Indeed. The threat the I am addressing is the "I changed just one line
and ..." one.

> Donal.
>

Relevant Pages

  • Re: TIP #172: Improve UNIX Tk Look and Feel
    ... > frame and its decorations. ... > platform that runs FLTK. ... > benefits of a Windows DialogBox, ... how do you know what to draw if there aren't any parameters? ...
    (comp.lang.tcl)
  • Re: TIP #172: Improve UNIX Tk Look and Feel
    ... to use Fltk you need to think differently. ... The other thing that I noticed was the widget layout functionality ... Windows DialogBox, for example. ... I have found that schemes are nice for some things, ...
    (comp.lang.tcl)