| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
Use the new "override" keyword to properly differentiate between new
virtual methods, and existing virtual methods being overridden.
|
|
|
|
|
| |
It's more readable than 0, and a bit safer than NULL, so let's try to
follow modern norms.
|
|
|
|
|
|
|
|
| |
FLTK only allows 256 different box types, but it doesn't actually check
this when registering new ones.
Move our custom types to a valid range, and add an assert for good
measure to make sure we don't overflow FLTK's internal structures.
|
|
|
|
|
| |
Follow the colors that modern desktops use when it comes to background,
text and selections.
|
|
|
|
|
|
|
| |
There is something broken with these FLTK draw routines on Windows. They
leave gaps at the start and end of the arc/pie rather than filling the
whole specified span. So we need to nudge the numbers a bit to work
around this.
|
|
|
|
|
|
|
|
|
|
|
| |
Inspired by modern Windows appearance, and to some extent macOS. They
have flat boxes and use white, or very light, colors for interactive
elements. Unfortunately we can't directly control the colors of
widgets, so instead we just lighten everything that uses this box type.
GNOME uses a different design, both their older and newer style. But UI
look is less consistent on Linux, so hopefully our new look is decent
enough there as well.
|
|
|
|
| |
We should have a consistent color set over all widgets.
|
|
|
|
|
| |
This allows us to separate accidentally unused, from explicitly unused
parameters, which allows us to turn on such checks in the compiler.
|
|
|
|
|
| |
This was not meant to be included in the previous commit. The static
storage for the font string is more than enough.
|
|
|
|
|
| |
Fl::set_font() doesn't keep its own copy, so we need to make sure the
font string doesn't get freed or overwritten at a later point.
|
|
|
|
|
|
| |
Use the font specified by the system for UI elements. For Windows and
macOS this is straight forward, but Linux is more complex as there is no
single source for this information.
|
|
|
|
|
|
|
| |
Try to follow the actual padding that FLTK adds to these widgets.
The extra one pixel on each is because of a bug in FLTK's focus drawing
code, where the box is always one pixel too small in both dimensions.
|
|
|
|
|
| |
This is how GNOME does things, so let's do the same so things look
similar.
|
|
|
|
| |
To conform with how e.g. GNOME sets its margins.
|
|
|
|
|
| |
Outlines are no longer commonly used. Instead visually separated
headlines are the norm.
|
|
|
|
|
|
|
|
|
| |
Classical tabs are very dated. They are also a practical problem as you
get very limited in the numbers of tabs we can have, and how long the
text can be on them.
Switch to one popular modern model with a list on the left instead where
pages can be selected.
|
|
|
|
|
| |
The accessor functions are called value() for all standard FLTK widgets,
so let's keep that theme here as well.
|
|
|
|
|
| |
Follow upstream FLTK naming to more clearly indicate that this is a
general widget and not TigerVNC specific.
|
|
|
|
|
| |
These are general things and not specific to TigerVNC, so let's move it
to the fltk specific directory for clarity.
|
|
|
|
|
| |
These have nothing to do with layout, so let's split them to their own
file.
|
|
Let's separate TigerVNC specific things from stuff that could be part of
upstream FLTK. These are files that we would like to collaborate with
other FLTK users, so they are more liberally licensed and avoid using
TigerVNC specific things.
|