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
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
|
/** \page fltk-problems Problems with FLTK
<h2>dw::fltk::FltkViewport</h2>
Current problems:
<ul>
<li> dw::fltk::FltkViewport::draw should only draw the region, for which e.g.
an expose event was received.
<li> dw::fltk::FltkViewport::queueDraw will collect data, which has to be
redrawn. Currently, it calls redraw (DAMAGE_EXPOSE), can this be changed,
so that dw::fltk::FltkViewport::draw will distinguish between the two
cases?
<li> For Scrolling, something similar applies, only parts of the viewport
have to be redrawn.
<li> Also for Scrolling, it is necessary to copy parts of the window.
<li> How should dw::fltk::FltkViewport::cancelQueueDraw be implemented?
<li> If the value of a scrollbar is changed by the program, not the user,
the callback seems not to be called. Can this be assured?
<li> The same for dw::fltk::FltkViewport::layout?
<li> Also, the problems with the widgets seems to work. Also sure?
<li> When drawing, clipping of 32 bit values seems to work.
<li> Who is responsable for clearing before drawing?
<li> The embedded buttons are not redrawn, when pressing the mouse button
on them.
<li> The item group within a selection widget (menu) should not be selectable.
</ul>
<h2>dw::fltk::FltkPlatform</h2>
<ul>
<li> There is the problem, that fltk::font always returns a font, the
required one, or a replacements. The latter is not wanted in all
cases, e.g. when several fonts are tested. Perhaps, this could be
solved by searching in the font list.
<li> In dw::fltk::FltkFont::FltkFont, fltk::measure does not seem to work
for the calculation of dw::core::style::Font::xHeight.
<li> Distinction between italics and oblique would be nice
(dw::fltk::FltkFont::FltkFont).
</ul>
<h2>dw::fltk::ui::FltkCheckButtonResource</h2>
Groups of fltk::RadioButton must be added to one fltk::Group, which is
not possible in this context. There are two alternatives:
<ol>
<li>there is a more flexible way to group radio buttons, or
<li>radio buttons are not grouped, instead, grouping (especially
unchecking other buttons) is done by the application.
</ol>
(This is mostly solved.)
<h2>dw::fltk::FltkImgbuf</h2>
Alpha transparency should be best abstracted by FLTK itself. If not,
perhaps different implementations for different window systems could
be used. Then, it is for X necessary to use GCs with clipping masks.
<h2>Lower Priority</h2>
There needs to be an XEmbed implementation.
<h2>dw::fltk::ui::ComplexButton</h2>
Unfortunately, FLTK does not provide a button with Group as parent, so
that children may be added to the button. dw::fltk::ui::ComplexButton does
exactly this, and is, in an ugly way, a modified copy of the FLTK
button.
It would be nice, if this is merged with the standard FLTK
button. Furthermore, setting the type is strange.
If the files do not compile, it may be useful to create a new one from
the FLTK source:
<ol>
<li> Copy fltk/Button.h from FLTK to dw/fltkcomplexbutton.hh and
src/Button.cxx to dw/fltkcomplexbutton.cc.
<li> In both files, rename "Button" to "ComplexButton". Automatic replacing
should work.
<li> Apply the changes below.
</ol>
The following changes should be applied manually.
<h3>Changes in fltkcomplexbutton.hh</h3>
First of all, the \#define's for avoiding multiple includes:
\code
-#ifndef fltk_ComplexButton_h // fltk_Button_h formerly
-#define fltk_ComplexButton_h
+#ifndef __FLTK_COMPLEX_BUTTON_HH__
+#define __FLTK_COMPLEX_BUTTON_HH__
\endcode
at the beginning and
\code
-#endif
+#endif // __FLTK_COMPLEX_BUTTON_HH__
\endcode
at the end. Then, the namespace is changed:
\code
-namespace fltk {
+namespace dw {
+namespace fltk {
+namespace ui {
\endcode
at the beginning and
\code
-}
+} // namespace ui
+} // namespace fltk
+} // namespace dw
\endcode
at the end. Most important, the base class is changed:
\code
-#ifndef fltk_Widget_h
-#include "Widget.h"
-#endif
+#include <fltk/Group.h>
\endcode
and
\code
-class FL_API ComplexButton : public Widget {
+class ComplexButton: public ::fltk::Group
+{
\endcode
Finally, for dw::fltk::ui::ComplexButton::default_style, there is a
namespace conflict:
\code
- static NamedStyle* default_style;
+ static ::fltk::NamedStyle* default_style;
\endcode
<h3>Changes in fltkcomplexbutton.cc</h3>
First, \#include's:
\code
#include <fltk/events.h>
#include <fltk/damage.h>
-#include <fltk/ComplexButton.h> // <fltk/Button.h> formerly
#include <fltk/Group.h>
#include <fltk/Box.h>
#include <stdlib.h>
+
+#include "fltkcomplexbutton.hh"
\endcode
Second, namespaces:
\code
+using namespace dw::fltk::ui;
using namespace fltk;
\endcode
Since the base class is now Group, the constructor must be changed:
\code
-ComplexButton::ComplexButton(int x,int y,int w,int h, const char *l) : Widget(x,y,w,h,l) {
+ComplexButton::ComplexButton(int x,int y,int w,int h, const char *l) :
+ Group(x,y,w,h,l)
+{
\endcode
At the end of the constructor,
\code
+ type (NORMAL);
}
\endcode
must be added (I've forgotten, what this is for).
Finally, the button must draw its children (end of
dw::fltk::ui::ComplexButton::draw()):
\code
+
+ for (int i = 0; i < children (); i++)
+ draw_child (*child (i));
}
\endcode
*/
|
