1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
|
/**
\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
*/
|
