Replies: 15 comments
-
types of widgetsA c++ class hierarchy. All widgets are based on The general windows-manager related functions are implemented by another member in a form of a reference (handle) to objects of another c++ class hierarchy:
using window = detail::basic_window*; ///< The window handle type representing nana window objects pointing (handle) to an instance of a class of a parallel hierarchy of virtual /// a window data structure descriptor
struct basic_window : public events_holderThis already hold a lot of data that we will discuss in the point about 'relations between widgets' and messages.
/// Base class of all the classes defined as a widget window. Defaults to `widget_tag`
template<typename Category,
typename DrawerTrigger, ///< must be derived from nana::drawer_trigger
typename Events = ::nana::general_events,
typename Scheme = ::nana::widget_geometrics,
typename = typename std::enable_if<std::is_base_of<::nana::drawer_trigger, DrawerTrigger>::value>::type>
class widget_object: public detail::widget_base
an almost concrete, but templated class, that implements all virtual functions using members of the template parameter types: private:
DrawerTrigger trigger_;
std::shared_ptr<Events> events_;
std::unique_ptr<Scheme> scheme_;
/// Base class of all the classes defined as a root window.
/// These widgets are directly mapped to (implemented by) a window provided
/// by the underlying windows system (win32/X11). \see nana::form
template<typename DrawerTrigger,
typename Events,
typename Scheme>
class widget_object<category::root_tag, DrawerTrigger, Events, Scheme>: public detail::widget_baseand /// Base class of non-graphics-buffer widget window (DrawerTrigger is ignored, see nana::panel).
template<typename DrawerTrigger,
typename Events,
typename Scheme>
class widget_object<category::lite_widget_tag, DrawerTrigger, Events, Scheme>: public detail::widget_basethis last two members only: private:
std::shared_ptr<Events> events_;
std::unique_ptr<scheme_type> scheme_;
|
Beta Was this translation helpful? Give feedback.
-
relations between widgets, windows and the OSIn a GUI based on windows, like win32 or X11 the windows are organized into a tree-like structure formed by owners, parents and children. Each node in that tree is a window. This tree is manager centrally.
/// a window data structure descriptor
struct nana::detail::basic_window : public events_holderThis hold a lot of data: native_window_type root; ///< root Window handle
thread_t thread_id; ///< the identifier of the thread that created the window.
basic_window* root_widget; ///< refers to root basic_window, if 'this' is a root, the pointer refers to itself.
basic_window* parent;
basic_window* owner;
unsigned index;
container children;
point pos_owner; ///< coordinates of the owner window \todo: dpi? user or system-side ?
point pos_root; ///< coordinates of the root window \todo: dpi? user or system-side ?
size dimension; ///< size of this window \todo: dpi? user or system-side ?
size min_track_size;
size max_track_size;
int dpi{ 96 }; ///< \todo: DPI of the window, cached value of the root, root_widget's and root_graph.
#if defined(NANA_POSIX)
point pos_native;
#endif
bool visible;
unsigned extra_width;
unsigned extra_height;
native_string_type title;
cursor predef_cursor;
paint::graphics* root_graph; ///< Refer to the root buffer graphics
drawer drawer; ///< Self Drawer with owen graphics
std::unique_ptr<widget_notifier_interface> widget_notifier;
flags_type flags;
annex_components annex;
effects effect;
other_tag other;
where: struct flags_type
{
bool enabled :1;
bool dbl_click :1;
bool captured :1; ///< if mouse button is down, it always receive mouse move even the mouse is out of its rectangle
bool modal :1;
bool take_active:1; ///< If take_active is false, other.active_window still keeps the focus.
bool refreshing :1;
bool destroying :1;
bool dropable :1; ///< Whether the window has make mouse_drop event.
bool fullscreen :1; ///< When the window is maximizing whether it fit for fullscreen.
bool borderless :1;
bool make_bground_declared : 1; ///< explicitly make bground for bground effects
bool ignore_menubar_focus : 1; ///< A flag indicates whether the menubar sets the focus.
bool ignore_mouse_focus : 1; ///< A flag indicates whether the widget accepts focus when clicking on it
bool space_click_enabled : 1; ///< A flag indicates whether enable mouse_down/click/mouse_up when pressing and releasing whitespace key.
bool draggable : 1;
unsigned Reserved :17;
unsigned char tab; ///< indicate a window that can receive the keyboard TAB
mouse_action action;
mouse_action action_before;
};
struct annex_components
{
caret* caret_ptr{ nullptr };
widgets::skeletons::text_editor* text_editor{ nullptr };
//The following pointers refer to the widget's object.
std::shared_ptr<general_events> events_ptr;
widget_geometrics* scheme{ nullptr };
::nana::dev::widget_content_measurer_interface* content_measurer{ nullptr };
};
struct effects
{
effects::edge_nimbus edge_nimbus;
effects::bground_interface * bground;
double bground_fade_rate;
};
struct other_tag
{
struct attr_root_tag
{
bool ime_enabled{ false };
bool lazy_update{ false }; ///< Indicates whether the window is in lazy-updating mode.
container update_requesters; ///< Container for lazy-updating requesting windows.
container tabstop;
std::vector<edge_nimbus_action> effects_edge_nimbus;
basic_window* focus{nullptr};
basic_window* menubar{nullptr};
cursor state_cursor{nana::cursor::arrow};
basic_window* state_cursor_window{ nullptr };
std::function<void()> draw_through; ///< A draw through renderer for root widgets.
};
const category::flags category;
basic_window *active_window; ///< if flags.take_active is false, the active_window still keeps the focus,
///< if the active_window is null, the parent of this window keeps focus.
paint::graphics glass_buffer; ///< if effect.bground is avaiable. Refer to window_layout::make_bground.
update_state upd_state;
dragdrop_status dnd_state{ dragdrop_status::not_ready };
union
{
attr_root_tag * root;
}attribute;
other_tag(category::flags);
~other_tag();
}other;
struct wd_rectangle
{
basic_window * window;
rectangle r;
}; |
Beta Was this translation helpful? Give feedback.
-
messages driven applications
to do: create a new event
|
Beta Was this translation helpful? Give feedback.
-
portabilityAll OS specific details are encapsulated/isolated by:
In details:
|
Beta Was this translation helpful? Give feedback.
-
The coordinates and all related problems: multimonitors, DPI, scaling..all posible coordinate-system ( CoordSys ). The scaling is part of the definition of the CoordSys. There could be arbitrary scaling, but we will fix two special cases:
The CoordSys is also defined by the Origin (where the
void basic_window::_m_init_pos_and_size(basic_window* parent, const rectangle& r)
{
pos_owner = pos_root = r.position();
dimension = r.dimension();
if (parent) pos_root += parent->pos_root;
}or this: // Copy the graphics of the parent widget to the glass buffer
glass_buffer.bitblt(::nana::rectangle{ wd->dimension },
wd->parent->drawer.graphics,
wd->pos_owner);
In a more general situation we may need to include rotations of one CoordSys with respect tp other. Simple 90°/-90° or even 'free angle' rotation. |
Beta Was this translation helpful? Give feedback.
-
Text encoding and drawing |
Beta Was this translation helpful? Give feedback.
-
Graphics/drawing/images/icons/bitmaps/fonts and formats: BMP, jpg, npg...There are some classes involved in direct manipulations of 'pixels' or bitmaps. These are hardly escalable: the User-side (US) coordinates received are internally scaled to the provided dpi (the SS dpi of the destiny - target dpi). Coordinates retrieved are already scaled back to US.
|
Beta Was this translation helpful? Give feedback.
-
Errors/exceptions |
Beta Was this translation helpful? Give feedback.
-
layout of widgets in a windows: 'fixed/manual' coordinates vs automatic re-'place' |
Beta Was this translation helpful? Give feedback.
-
customization: colors, geometric, schemes, styles... |
Beta Was this translation helpful? Give feedback.
-
"consuming" nana: repositories, build, packages. |
Beta Was this translation helpful? Give feedback.
-
Documenting nana |
Beta Was this translation helpful? Give feedback.
-
DefinitionsWe need to provide clear, unambiguous and stable definitions of:
|
Beta Was this translation helpful? Give feedback.
-
threads and threads safety |
Beta Was this translation helpful? Give feedback.
-
A nana big feature is simplicity of use.
Users enjoy simple use because nana does the hard work and take away most of the complexity. Both the API nana offers to the user and the internal core of nana try hard to absorb all the complexity. Here I will try to discuss and understand how is this achieved and how the core code of nana implementation is organized. I will try to organize the ideas into some more or less independent 'magnitudes of complexity' that a GUI library based on widgets need to 'resolve':
We need to provide clear, unambiguous and stable definitions of:
The CoordSys is also defined by the Origing (where the 0,0 point is with respect to some other CoordSys).:
Beta Was this translation helpful? Give feedback.
All reactions