87 lines
3.4 KiB
Plaintext
87 lines
3.4 KiB
Plaintext
/**
|
|
|
|
\page page_introduction Introduction
|
|
|
|
\tableofcontents
|
|
|
|
## Light User Interface Design ##
|
|
|
|
FLUID is the Fast Light User Interface Designer that accompanies the fltk
|
|
user interface library. FLUID relies on panels and dialogs that are generated
|
|
within FLUID. Consequently, developers are required to consistently assess the
|
|
user-friendliness and code integrity of the application.
|
|
|
|
This document presumes you are familiar with FLUID, have read the most
|
|
important parts the FLUID User Manual, and have created some user interfaces
|
|
in FLUID already.
|
|
|
|
## History ##
|
|
|
|
FLUID is an application that grew over time with fltk. In its original design,
|
|
it was meant to allow users to drag and resize a limited number of widgets
|
|
for small dialog boxes. As the feature set grew over time, new concept and
|
|
designs were introduced by new authors. In its current state, FLUID's source
|
|
code is largely undocumented and difficult to read and understand.
|
|
|
|
This should not stop you from diving into the code though. The concepts and
|
|
ideas behind FLUID are great. The software itself is very usable and stable.
|
|
And while digging through the code, any addition to the documentation is
|
|
highly appreciated.
|
|
|
|
## Future ##
|
|
|
|
As we approach the imminent release of FLTK 1.4.0, FLUID will no longer undergo
|
|
significant feature enhancements. Instead, the focus will shift towards
|
|
documentation improvements, addressing bugs, and enhancing usability for
|
|
recent FLTK additions such as Fl_Grid and Fl_Flex. Following the release of
|
|
1.4.0, FLUID will undergo a comprehensive restructuring and modernization,
|
|
streamlining maintenance and simplifying the process of integrating
|
|
support for new widgets.
|
|
|
|
## Quick Glossary ##
|
|
|
|
__Project__ : a project is a single design, stored in a project file ending in
|
|
`.fl`. A project contains a bunch of settings and a tree of Types. One
|
|
project can contain multiple UI designs.
|
|
|
|
__Code File__, __Header File__ : by default, FLUID generates C++ source code
|
|
that is stored in two files with the same basename as the project. The
|
|
C++ declarations go into the header file ending in `.h`, and the
|
|
implementation is stored in the `.cxx` source code file.
|
|
|
|
__Strings File__ : FLUID supports internationalization (in short i18n) of all
|
|
know text elements in a project. The Strings file can be generated as a
|
|
base for adding new languages. The file extension depend on the chosen
|
|
i18ns library.
|
|
|
|
__Types__ : a type is a node in a tree that manages a widget or a functional
|
|
node like Class, Function, CodeBlock, etc.
|
|
|
|
__Panels__ : in its interactive incarnation, FLUID provides a number of panels
|
|
(dialog boxes) for editing all aspects of Types.
|
|
|
|
## Basic Structure ##
|
|
|
|
...
|
|
|
|
## Wish List ##
|
|
|
|
I call this a wish list because I write my wishes down as I go. There is no
|
|
verification yet, or alternative ideas.
|
|
|
|
- group source files into subdirectories
|
|
- all panels should have their own folder
|
|
- all custom widgets
|
|
- all file and stream operations
|
|
- all utilities and tools
|
|
- move to C++17 and use std::string, vector, map, ...
|
|
- Fl_Type::write#() could go into a single write function with an enum to
|
|
describe what needs to be written to make thing logical and expandable
|
|
- better error handling in all file classes
|
|
- separate FLUID generated files form the core and build a shell-only version
|
|
- individual event handling for types
|
|
- individual overlay drawing for types
|
|
- plug-ins for new types
|
|
|
|
*/
|