| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
It is much more natural than custom methods for this very common
operation.
|
|
|
|
|
|
|
|
| |
These files don't use anything from this header, so remove the include.
This exposes some missing includes in other places, though. So add an
explicit include in the files that were relying on an indirect
inclusion.
|
|
|
|
|
| |
Avoids a bit of complexity by delegating that handling to a string
object.
|
|
|
|
|
| |
Let's use a more common type instead of something homegrown. Should be
more familiar to new developers.
|
|
|
|
|
|
| |
We mostly use classical C strings, but the memory management around them
can get confusing and error prone. Let's use std::string for the cases
where we need to return a newly allocated string.
|
|
|
|
|
| |
We know the needed space here, so let's keep it simple with a constant
size string buffer.
|
|
|
|
|
| |
It should return a path to the directory itself, just like its sister
function getuserhomedir().
|
|
|
|
| |
All library functions should be in a proper namespace.
|
|
|
|
|
|
|
|
|
| |
This mimics how some system functions (like inet_ntop()) work, and
avoids complexity around ownership of the returned string buffer.
The downside is that the string must be consumed directly as it will be
overwritten on the next call, but that is not an issue with the current
usage.
|
|
|
|
|
| |
We don't need to make extra copies of the string in most cases, so let's
simplify the code and access the string directly when we can.
|
|
|
|
|
| |
We never use Windows' "UNICODE" mode anyway, so let's get rid of this
complexity.
|
|
|
|
|
| |
Avoid having our own custom stuff and instead use the modern, standard
types, for familiarity.
|
|
|
|
|
|
| |
These are supported by gcc and clang, and I don't think MSVC works well
with our code anyway, so let's keep things simple and use these
directly.
|
|
|
|
| |
gcc will complain, and we will fill out all fields later anyway.
|
|
|
|
|
| |
These types caused an incorrect signed/unsigned behaviour, so let's make
sure we use the appropriate type.
|
|
|
|
| |
These are all truisms because of the valid range of the types.
|
|
|
|
|
| |
This allows us to separate accidental fall through from explicit ones,
which allows us to turn on such checks in the compiler.
|
|
|
|
|
| |
These were not meant to fall through. Likely didn't have any adverse
effects, but let's fix it anyway.
|
|
|
|
|
| |
This allows us to separate accidentally unused, from explicitly unused
parameters, which allows us to turn on such checks in the compiler.
|
|
|
|
|
| |
No practical difference currently, but let's respect what this API was
supposed to do.
|
| |
|
|
|
|
|
| |
This makes sure the compiler doesn't complain about problems in those
files.
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|\
| |
| | |
Add support for RSA-AES security types (Java version)
|
| | |
|
|\ \ |
|
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| | |
| | |
| | |
| | | |
This makes the code much cleaner, and easier to update.
|
| | |
| | |
| | |
| | | |
Makes it easier to adjust the UI from a central place.
|
| | |
| | |
| | |
| | | |
Makes it easier to adjust the UI from a central place.
|
| | |
| | |
| | |
| | |
| | | |
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.
|
| |
| |
| |
| |
| | |
If the translations change then these files need to be regenerated as
they include data from those.
|
| |
| |
| |
| |
| | |
It's just the name of the system, so there is nothing in that string to
translate.
|
| |
| |
| |
| |
| | |
This should be happening implicitly, but isn't always for some reason on
macOS 13.
|
|/
|
|
|
|
|
|
|
|
| |
The system steals keyboard events for certain system keyboard shortcuts,
e.g. Cmd+Tab. Unfortunately this isn't considered a focus loss, so we
don't realise we've lost a few keyboard events and can end up in a
confused state.
Fortunately it is possible to detect when this happens and reset the
keyboard state, just like we do when focus is lost.
|
| |
|
|
|
|
| |
This was accidentally disabled in 81e114f.
|
|
|
|
| |
It might not be compiled in, so the height needs to be dynamic.
|