同步操作将从 Gitee 极速下载/MiniGUI 强制同步,此操作会覆盖自 Fork 仓库以来所做的任何修改,且无法恢复!!!
确定后同步将在后台操作,完成时将刷新页面,请耐心等待。
The MiniGUI development team announces the availability of MiniGUI 4.0.0. We strongly recommend that you use this version for any new MiniGUI apps, especially if the new features of MiniGUI 4.0.0 are must for your new apps.
Please report any bugs and incompatibilities in
https://github.com/VincentWei/minigui
This version mainly fixed some minor issues:
size_t
values.The MiniGUI development team announces the availability of MiniGUI 4.0.0. We strongly recommend that you use this version for any new MiniGUI apps, especially if the new features of MiniGUI 4.0.0 are must for your new apps.
Please report any bugs and incompatibilities in
https://github.com/VincentWei/minigui
In this version, we mainly enhanced and tuned the APIs related to text rendering in order that MiniGUI can handle complex writing systems (scripts) like Arabic and Indic:
MiniGUI now provides complete APIs for Unicode characters processing. These APIs conform to Unicode 12.0, including the Unicode Bidirectional Algorithm (UAX #9), Unicode Line Breaking Algorithm (UAX #14), Unicode Normalization Forms (UAX #15), Unicode Script Property (UAX #24), Unicode Text Segmentation (UAX #29), Unicode Vertical Text Layout (UAX #50), and so on.
MiniGUI also provides new APIs to lay out, shape, and render glyphs from complex and mixed scripts, such as Arabic, Thai, and Indic. The new APIs also conform to the specifications of CSS Text Module Level 3 and CSS Writing Modes Level 3.
We tuned and optimized MiniGUI's logical and device font interfaces to support the new features above.
MiniGUI now is enhanced to support input events which may be generated
by input devices other than standard mouse (or single-touch panel) and
keyboard, such as multi-touch panel (gesture), joystick, tablet tool,
and switch. In MiniGUI 4.0, we introduce MSG_EXIN_XXX
messages to support
the input events from devices other than standard mouse and keyboard. We
call these messages as 'extra input messages'.
Another important features of this version are the new following engines:
dri
to support modern DRM-driven graphics cards. By using
dri
engine, one MiniGUI app can now use the hardware-accelerated graphics
rendering for 2D/3D graphics.libinput
to support all modern input devices including
mouse, keyboard, joystick, switch, multi-touch panel, gesture, tablet tool,
and table pad.random
to generate extra input messages
automatically for testing.At last, we introduced a Slice Memory Allocator for fast concurrent memory chunk allocation.
The following sections will describe these new features in detail.
New types:
Uchar32
: the Unicode code point value of a Unicode character.Achar32
: the abstract character index value under a certain
charset/encoding. Under Unicode charset or encodings, the
abstract character index value will be identical to the Unicode
code point, i.e., Achar32 is equivalent to Uchar32 under this
situation.Glyph32
: the glyph index value in a device font. Note that
a Glyph32 value is always bound to a specific logfont object.New functions to determine the Unicode character properties:
UCharGetCategory
for getting the general category of
a Unicode character.UCharGetBreakType
for getting the breaking type of
a Unicode character.UStrGetBreaks
for getting the breaking types of
a Unicode string.UCharGetBidiType
for getting the bidi type of
a Unicode character.UStrGetBidiTypes
for getting the bidi types of a Unicode
character string.UCharGetBracketType
for getting the bracketed character of a
Uchar32 character.UStrGetBracketTypes
for getting the bracketed characters of a
Uchar32 string.UCharGetMirror
for getting the mirrored character of a Uchar32
character.UCharGetJoiningType
for getting the joining type of a Uchar32
character.UStrGetJoiningTypes
for getting the joining types of a Uchar32
string.UBidiGetParagraphDir
for getting the base paragraph direction
of a single paragraph.UBidiGetParagraphEmbeddingLevels
for getting the bidi embedding
levels of a paragraph.UBidiReorderLine
, UBidiShapeMirroring
, UBidiJoinArabic
,
UBidiShapeArabic
, and UBidiShape
for doing bidi-aware
mirroring, joining, and shaping.UCharGetScriptType
for getting the script type of a Uchar32
character.MiniGUI also provides some utilities/helpers for Unicode character conversion, such as from lower case to upper case, single width to full width. Please see MiniGUI API reference document for the detailed description.
To lay out, shape, and render a text in mixed scripts, you should call
GetUCharsUntilParagraphBoundary
function first to convert
a multi-byte string to a Unicode string under the specified white space
rule, breaking rule, and transformation rule. For example, converting a
general C string in UTF-8 or GB18030 to a Uchar32 string by calling this
function. You can call CreateLogFontForMChar2UChar
function to create
a dummy logfont object for this purpose in order to expense a minimal memory.
If the text is in simple scripts, like Latin or Chinese, you can call
GetGlyphsExtentFromUChars
function to lay out the paragraph. This function
returns a glyph string which can fit in a line with the specified
maximal extent and rendering flags. After this, you call
DrawGlyphStringEx
function to draw the glyph string to the
specific position of a DC.
If the text is in complex and/or mixed scripts, like Arabic, Thai,
and Indic, you should create a TEXTRUNS object first by calling
CreateTextRuns
function, then initialize the shaping engine for
laying out the text.
MiniGUI provides two types of shaping engine. One is the basic
shaping engine. The corresponding function is InitBasicShapingEngine
.
The other is called complex shaping engine, which is based on HarfBuzz.
The corresponding function is InitComplexShapingEngine
. The latter
one can give you a better shaping result.
After this, you should call CreateLayout
to create a layout object
for laying out the text, then call LayoutNextLine
to lay out the lines
one by one.
You can render the laid out lines by calling DrawLayoutLine
function.
Finally, you call DestroyLayout
and DestroyTextRuns
to destroy
the layout object and text runs object.
Before rendering the glyphs laid out, you can also call GetLayoutLineRect
to get the line rectangle, or call CalcLayoutBoundingRect
to get
the bounding rectangle of one paragraph.
These new APIs provide a very flexible implementation for your apps to process the complex scripts. The implementation is derived from LGPL'd Pango, but we optimize and simplify the original implementation in the following respects:
We split the layout process into two stages. We get the text runs (Pango items) in the first stage, and the text runs will keep as constants for subsequent different layouts. In the second stage, we create a layout object for a set of specific layout parameters, and generates the lines one by one for the caller. This is useful for an app like browser, it can reuse the text runs if the output width or height changed, and it is no need to re-generate the text runs because of the size change of the output rectangle.
We use MiniGUI's fontname for the font attributes of text, and leave the font selection and the glyph generating to MiniGUI's logfont module. In this way, we simplify the layout process greatly.
We always use Uchar32 string for the whole layout process. So the code and the structures are clearer than original implementation.
We provide two shaping engines for rendering the text. One is a basic shaping engine and other is the complex shaping engine based on HarfBuzz. The former can be used for some simple applications.
The styles of LOGFONT changed.
FS_RENDER_ANY
: Not specified.FS_RENDER_MONO
:FS_RENDER_GREY
:FS_RENDER_SUBPIXEL
:FS_WEIGHT_BOOK
; use FS_RENDER_GREY
instead.FS_WEIGHT_SUBPIXEL
; use FS_RENDER_SUBPIXEL
instead.FONT_WEIGHT_ANY
: Not specified.FONT_WEIGHT_THIN
: Thin.FONT_WEIGHT_EXTRA_LIGHT
: Extra light (Ultra Light).FONT_WEIGHT_LIGHT
: Light.FONT_WEIGHT_REGULAR
: Regular (Normal).FONT_WEIGHT_MEDIUM
: Medium.FONT_WEIGHT_DEMIBOLD
: Demi Bold (Semi Bold)FONT_WEIGHT_BOLD
: Bold.FONT_WEIGHT_EXTRA_BOLD
: Extra Bold (Ultra Bold).FONT_WEIGHT_BLACK
: Black (Heavy).FONT_UNDERLINE_LINE
and FONT_STRUCKOUT_LINE
with them:
FONT_DECORATE_ANY
: Not specified.FONT_DECORATE_NONE
: None.FONT_DECORATE_UNDERLINE
: glyphs are underscored.FONT_DECORATE_STRUCKOUT
: glyphs are overstruck.FONT_DECORATE_US
: Both FONT_DECORATE_UNDERLINE
and FONT_DECORATE_STRUCKOUT
.FONT_DECORATE_OUTLINE
: Outline (hollow) glyphs.FONT_DECORATE_REVERSE
: Reserved for future. Glyphs have their
foreground and background reversed.FONT_OTHER_LCDPORTRAIT
FONT_OTHER_LCDPORTRAITKERN
For a new app, you should use the new function CreateLogFontEx
to
create a LOGFONT, and specify the weight and rendering method of the glyph.
For the back-compatibility, you can still use CreateLogFont
to create a new
LOGFONT. However, FS_WEIGHT_BOOK
will be treated FS_WEIGHT_REGULAR
and
FS_RENDER_GREY
, while FS_WEIGHT_SUBPIXEL
will be treated
FS_WEIGHT_REGULAR
and FS_RENDER_SUBPIXEL
.
You can still use CreateLogFontByName
to create a new LOGFONT.
But the style string in the font name changed from
<weight><slant><flipping><other><underline><struckout>
to
<weight><slant><flipping><other><decoration><rendering>
Note that <underline>
and <struckout>
are merged to <decoration>
in order to keep the style string is still 6-character long.
Consequently, if you want to use the rendering method SUPIXEL for a TTF font, please define the logical font name in the following way:
ttf-Courier-rrncns-*-16-UTF-8
Moreover, the family name of a DEVFONT supports aliases since 4.0.0:
<fonttype>-<family[,aliase]*>-<styles>-<width>-<height>-<charset[,charset]*>
for example:
ttf-Arial,Sans Serif-rrncnn-8-16-ISO8859-1,UTF-8
ttf-courier,monospace,serif-rrncnn-8-16-ISO8859-1,UTF-8
Note that the length of one DEVFONT name can not exceed 255 bytes.
Since version 4.0.0, you can specify up to 7 family names for a logfont name, such as:
ttf-Courier,宋体,Naskh,SansSerif-rrncns-U-16-UTF-8
In this way, you can specify a logfont to use multiple devfonts to render a complex text. This is useful when different glyphs are contained in different font files. It is well known that, a font is often designed for a particular language/script or a few similar languages/scripts.
Since 4.0.0, the previous width field of a logfont name is used for the glyph orientation:
In order to support modern graphics card or GPU, we introduced a
new NEWGAL engine of dri
. The developer can use this engine to
run MiniGUI apps on a Linux box on which the DRI
(Direct Rendering Infrastructure) is enabled.
The dri
engine uses libdrm
developed by Free Desktop project:
https://dri.freedesktop.org/wiki/
Libdrm is a user-space library implements the Direct Rendering Manager. MiniGUI mainly uses this library to support the dumb frame buffer (no hardware acceleration). However, you can write a driver for your graphics card or GPU to implement the hardware accelerated features.
To avoid modifying the MiniGUI source code when supporting a new GPU,
the dri
engine has adopted a scalable design:
dri
engine to run MiniGUI on a GPU
which supports dumb frame buffer.dri
engine outside MiniGUI.In this situation, you need to configure MiniGUI with the following option:
--with-targetname=external
and implement the sub driver in your MiniGUI apps.
The header file <minigui/exstubs.h>
defines the operators (a set of
callback functions) you need to implement for your GPU externally.
As an example, we implement the sub driver for i915
graphics chard
in mg-tests/dri-engine/
. Please refer to mg-tests
repository.
To exploit the GPU's accelerated rendering capabilities, a MiniGUI app
can use cairo
and/or OpenGL ES
to assist in rendering 2D/3D graphics
when using the dri
engine. We will provide some samples in mg-tests
or mg-samples
for this purpose.
Note that for dri
engine, we introduce a new section in MiniGUI runtime
configuration:
[dri]
defaultmode=1024x768-32bpp
pixelformat=XR24
device=/dev/dri/card0
dpi=96
You can use the key dri.device
to specify your DRI device.
You can use the key dri.pixelformat
to specify the DRM pixel format for the
screen. We use DRM fourcc code to defined the pixel format of the screen
surface. For more information, please see <drm/drm_fourcc.h>
header file.
Note that only 8/16/24/32 bpp RGB formats are supported. For example, XR24
means X8R8G8B8
pixel format.
Currently, the dri
NEWGAL engine does not provide support for
MiniGUI-Processes run-time mode. We will enhance this in the subsequent
version of MiniGUI.
Also note that when you use the hardware accelerated sub driver, MiniGUI app
may need the root privilege to call drmSetMaster
to set the video mode.
However, under MiniGUI-Processes run-time mode, only the server (mginit
) will
need this privilege when you use the future dri
engine.
In MiniGUI 4.0.0, we introduce the extra input messages to support modern input devices including multiple touch panel, gesture, tablet tool, and table pad.
The extra input messages have the prefix MSG_EXIN_
. If a MiniGUI app
want to handle these extra input events such as gestures, you need
to handle the MSG_EXIN_XXX
messages in the app. For examples, please
refer to mg-tests/extra-input/
.
Currently, there are two built-in IAL engines which can generates the extra input messages:
The IAL engine of libinput
to support all modern input devices on a
Linux box. This engine runs on libinput
introduced by Free Desktop project.
The enhanced IAL engine of random
to generate extra input messages
automatically for testing.
You can also write your own IAL engines to generate the extra messages.
Please see the implementation of libinput
and random
engines for
the details.
For libinput
engine, we introduce a new section in MiniGUI runtime
configuration:
[libinput]
seat=seat0
The key libinput.seat
specifies the seat identifier, the default
is seat0
.
For random
engine, we introduce a new section in MiniGUI runtime
configuration:
[random]
logfile=events.out
eventtypes=mouse-keyboard-button-gesture-stouch
minkeycode=1
maxkeycode=128
minbtncode=0x100
maxbtncode=0x1ff
The MiniGUI runtime configuration key random.logfile
specifies
the log file which will store the input events generated by this engine.
If MiniGUI failed to open the log file, the log feature will be disabled.
The MiniGUI runtime configuration key random.eventtypes
specifies
the input event types which will be generated by this IAL engine,
in the following pattern:
<event-type>[-<event-type>]*
The <event-type>
can be one of the following values:
mouse
: mouse.keyboard
: keyboard.button
: buttons.single_touch
: touch pen or single touch panel.multi_touch
: multiple touch panel.gesture
: gesture.tablet_tool
: tablet tool.tablet_pad
: tablet pad.switch
: switch.The MiniGUI ETC key random.minkeycode
specifies the minimal key code
which can be generated by the engine if keyboard
is included.
The MiniGUI ETC key random.maxkeycode
specifies the maximal key code
which can be generated by the engine if keyboard
is included.
The MiniGUI ETC key random.minbtncode
specifies the minimal button code
which can be generated by the engine if button
is included.
The MiniGUI ETC key random.maxbtncode
specifies the maximal key code
which can be generated by the engine if button
is included.
For invalid random.eventtyps
, the engine uses mouse
as default.
For invalid random.minkeycode
, and/or random.maxkeycode
key values,
the engine uses SCANCODE_ESCAPE
, and SCANCODE_MICMUTE
respectively.
For invalid random.minbtncode
, and/or random.maxbtncode
key values, use
0x100
(BTN_MISC
defined by Linux kernel), and 0x2ff
(KEY_MAX
defined by
Linux kernel) respectively.
This engine maintains a state machine for each input event type, and generates a reasonable event sequence for each type. If and only if an event sequence finished or cancelled, the engine switch to another event type randomly.
Note that currently, the following event types (in random
engine)
are not implemented:
multi_touch
tablet_tool
tablet_pad
switch
MiniGUI now provides an efficient way to allocate groups of equal-sized chunks of memory.
Memory slices provide a space-efficient and multi-processing scalable way to allocate equal-sized pieces of memory, just like the MiniGUI's block data heap. Relative to the standard malloc function and block data heap, this allocator can avoid excessive memory-waste, scalability and performance problems.
The following APIs are introduced:
mg_slice_alloc
to allocate a given size trunk of memory.mg_slice_free
to free a given size trunk of memory.mg_slice_new
to allocate a memory for a given structure.mg_slice_delete
to free a memory for a given structure.We use the slice allocator when laying out the text in complex scripts.
Note that this implementation is derived from LGPL'd glib.
A new BITMAP type BMP_TYPE_REPLACEKEY
was added. When bmType
of
a BITMAP object has this bit set, any pixel which is equal to
bmColorKey
will be replaced by bmColorRep
.
More key scancodes are defined for modern keyboard, and the NR_KEYS
is re-defined to be 250.
Support for libPNG 1.6.x.
Support for Ubuntu 18.04 LTS.
Support for GCC 7.
In MiniGUI 4.0.0, we changed some unreasonable APIs which were introduced in early versions. There are also other changes broke the backward compatibility. This section gives you a summary about these changes.
UChar32
to Uchar32
and UChar16
to Uchar16
in order to
avoid the conflict with typedef of UChar32 in the system header
<unicode/umachine.h>
.mg_FT_LcdFilter
to FT2LCDFilter
in order to follow MiniGUI
naming rules.Uchar32
and Glyph32
as Uint32
instead of int
.In early versions, we did not significantly distinguish between
characters and glyphs. This will lead to some confusion. Therefore,
we introduce a new type called Achar32
, which is the character's
index value under a certain charset/encoding. While the type Glyph32
is the index value of a glyph in a font.
In order to reflect the correct character and glyph concepts, the following functions are removed:
The names of the following functions are changed:
The following functions are deprecated, you should use the new Unicode version instead:
The following functions are deprecated:
The fields height
and descent
have been removed from GLYPHINFO structure.
You should get the font metrics information by calling GetFontMetrics
function
if you want to get the height and descent data of one font.
The the basic glyph type and break type have been removed from GLYPHINFO
structure. You should use GetACharType
instead.
Support for FreeType1 was removed.
You should always use FreeType2 to support vector fonts, such as TrueType fonts (TTF), TrueType collections (TTC), OpenType fonts (OTF, both TrueType and CFF variants), OpenType collections (OTC), and Type 1 fonts (PFA and PFB).
The MiniGUI development team announces the availability of MiniGUI 3.2.2. All users of MiniGUI are recommended strongly to use this version. Please report any bugs and incompatibilities in
https://github.com/VincentWei/minigui
ENHANCEMENTS:
SyncUpdateDC
. You can use this function to synchronize
the update rectangles of a surface to screen, if the surface
represents the shadow frame buffer of the screen.--enable-syncupdate
_MGUSE_SYNC_UPDATE
UpdateInvalidClient
. You can use this function to update
the invalid client region of a window instantly._DBG_PRINTF
and _ERR_PRINTF
.__mg_save_jpg
function for storing MYBITMAP as JPEG file (10km).GetGlyphBIDIType
to get the glyph type in BIDI.dpi
for NEWGAL engine to define the DPI of the screen.
If it is absent, use 96 as the default DPI.GetGDCapability
to return DPI of the DC.InitSlaveScreenEx
to specify the DPI of slave screen.
Define InitSlaveScreen
as an inline function calling InitSlaveScreenEx
.QDWORD
for a quauter of DWORD. This type is 16-bit long on
64-bit architecture, and 8-bit long on 32-bit.MAKEDWORD
: Make a DWROD from four QDWORDs.FIRST_QDWORD
: get the first (LSB) QDWORD from a DWORD.SECOND_QDWORD
: get the second (LSB) QDWORD from a DWORD.THIRD_QDWORD
: get the third (LSB) QDWORD from a DWORD.FOURTH_QDWORD
: get the fourth (LSB) QDWORD from a DWORD.<minigui/exstubs.h>
.BUGFIXING:
PNG_COLOR_TYPE_GRAY_ALPHA
color type of PNG files.The MiniGUI development team announces the availability of MiniGUI 3.2.0. All users of MiniGUI are recommended strongly to use this version for new MiniGUI apps. Please report any bugs and incompatibilities in
https://github.com/VincentWei/minigui
All handle types, including GHANDLE
, HWND
, HDC
, etc.,
are now defined as aliases of PVOID
(typedef void* PVOID
).
You may need to check your code to reflect this change.
The type of DWORD
now has pointer precision. That is,
the size of DWORD
will be 4 bytes on 32-bit platform, and 8 bytes on
64-bit platform.
Similarly, WPARAM
and LPARAM
now have pointer precision.
WORD
and SWORD
has a half of pointer precision. The size of these
two types is 2 bytes on 32-bit platform, and 4 bytes on 64-bit platform.
RGBCOLOR
now is defined as an alias of DWORD32
(see below).
Note that the type of BYTE
always has the size of 8-bit on both
32-bit and 64-bit platforms.
We introduce DWORD32
and SDWORD32
types,
which have the size of 4 bytes on both 32-bit and 64-bit platforms.
You should use these types when reading/writing 32-bit integers from
a binary files for the portability. Of course, you can also use
Uint32
or Sint32
types.
Similarly, we introduce WORD16
and SWORD16
types,
which have the size of 2 bytes on both 32-bit and 64-bit platforms.
You should use these types when reading/writing 16-bit integers from
a binary file for the portability. Of course, you can also use
Uint16
or SUint16
types.
LRESULT
is defined for window callback procedure, and it has
pointer precision.
LINT
is a new integer type with pointer precision.
MAKEWPARAM
: this new macro makes a WPARAM value by using four bytes.
On the contrary, FIRSTBYTE
, SECONDBYTE
, THIRDBYTE
, and FOURTH
macros get the four bytes from a WPARAM
or a Uint32
value.
MAKEWORD16
: this new macro makes a 16-bit word by using two bytes.
Meanwhile, MAKEWORD
makes a 16-bit word on 32-bit platform, and a 32-bit
word on 64-bit platform.
Note that MAKELONG
macro always makes a DWORD
integer, which has pointer
precision. Meanwhile, MAKELONG32
macro makes a Uint32
integer.
Note that MakeRGB
and MakeRGBA
macros always make DWORD32
integers.
In contract, GetRValue
, GetRValue
, GetBValue
, GetAValue
always
get red, green, blue, and alpha components from a DWORD32
integer
respectively.
Note that you should use (-1)
instead of 0xFFFFFFFF
for the invalid
integer or pointer type value for good portability.
The main changes in structure and functions:
We now use a UINT
instead of an int
integer for the message identifier.
We now use a DWORD
integer for the time tick count. Meanwhile, you can
create 64 timers on 64-bit platform.
We now use a LRESULT
integer for the return value of a window callback
procedure. Now it is safe to return a pointer from the callback procedure
on 64-bit platform. This is a very important change, and it will break the
source compatibilty of your code. You should check the source code (use
gcc option -Wall
) carefully.
We now use a LINT
integer for the identifier of a timer. So you can pass
a pointer as the identifier of the timer on 64-bit platform. mGNCS uses
MiniGUI timer in this manner.
We now use a LINT
integer for the identifier of a control/widget and a
menu item. So you can pass a pointer as the identifier of the timer on
64-bit platform. mGNCS works in this manner.
The strcuture MSG
and all message-related functions changed.
For example, the prototype of SendMessage
changed from
int SendMessage (HWND hWnd, int nMsg, WPARAM wParam, LPARAM lParam)
to
LRESULT SendMessage (HWND hWnd, UINT nMsg, WPARAM wParam, LPARAM lParam)
IMPORTANT NOTE
For best portability, you should use FIRSTBYTE
to FOURTHBYTE
macros
to get the bytes of a character when you extract the bytes from WPARAM
parameter of a MSG_CHAR
message:
MSG_CHAR
unsigned char ch_buff [4];
unsigned char ch_buff [0] = FIRSTBYTE(wParam);
unsigned char ch_buff [1] = SECONDBYTE(wParam);
unsigned char ch_buff [2] = THIRDBYTE(wParam);
unsigned char ch_buff [3] = FOURTHBYTE(wParam);
Furthermore, the structure and functions to register window class,
create main window, and create dialog box changed. For example, the prototype
of WNDPROC
changed from
typedef int (* WNDPROC)(HWND, int, WPARAM, LPARAM)
to
typedef LRESULT (* WNDPROC)(HWND, UINT, WPARAM, LPARAM)
Therefore, the prototype of DefaultWindowProc
changed from
int DefaultWindowProc (HWND hWnd, int message, WPARAM wParam, LPARAM lParam)
to
LRESULT DefaultWindowProc (HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam)
All main window procedures, control class procedures, and dialog box procedures defined by your app should change the implementation to reflect the changes above.
IMPORTANT NOTE
Do not cast the result returned by a window procedure to int
on 64-bit
platform, unless you know what your are doing.
The type of notification callback changes from:
typedef void (* NOTIFPROC) (HWND hwnd, int id, int nc, DWORD add_data);
to
typedef void (* NOTIFPROC) (HWND hwnd, LINT id, int nc, DWORD add_data);
IMPORTANT NOTE
If you use MSG_COMMAND
message to handle the notification sent from children
controls, you should make sure the identifier is small enough on 64-bit
platform. Because MiniGUI packs the identifier and the notification code
in the WPARAM
parameter:
MSG_COMMAND
int id = LOWORD(wParam);
int code = HIWORD(wParam);
HWND hwnd = (HWND)lParam;
The code above will not work on 64-bit if you use a pointer as the identifier of the control.
Therefore, we recommend strongly that you use a NOTIFYPOROC
callback to
handle the notification sent from controls. To do this, please call
SetNotificationCallback
function to set the notification callback function.
The prototype of GetTickCount
changed from
unsigned int GetTickCount (void)
to
DWORD GetTickCount (void);
And the prototye of TIMERPROC
changed from
typedef BOOL (* TIMERPROC)(HWND, int, DWORD)
to
typedef BOOL (* TIMERPROC)(HWND, LINT, DWORD)
In addition, we correct the bad or wrong definitions of some APIs:
DWORD2PIXEL
to DWORD2Pixel
. The old one has a bad name.GetWindowRendererFromName
: The return type changes from
const WINDOW_ELEMENT_RENDERER*
to WINDOW_ELEMENT_RENDERER*
.
So you can overload some methods directly of a renderer.GetDefaultWindowElementRenderer
: The return type changes from
const WINDOW_ELEMENT_RENDERER*
to WINDOW_ELEMENT_RENDERER*
.
So you can overload some methods directly of the default renderer.We add some new options for autoconf script (configure
):
--with-runmode
: Now you can use this option to specify the runtime
mode of MiniGUI. The old enable options for runmode were removed.
Note that MiniGUI-Processes now is the default runmode.
--enable-develmode
: You should use this option to define _DEBUG
macro,
enable -Wall -Werror
option, and enable all features of MiniGUI,
if you were a MiniGUI developer.
The MiniGUI development team announces the availability of MiniGUI 3.0.13. All users of MiniGUI are encouraged to test this version carefully, and report any bugs and incompatibilities in
https://github.com/VincentWei/minigui.
The MiniGUI development team announces the availability of MiniGUI 3.0.2. All users of MiniGUI are encouraged to test this version carefully, and report any bugs and incompatibilities in
https://github.com/VincentWei/minigui.
此处可能存在不合适展示的内容,页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容,可点击提交进行申诉,我们将尽快为您处理。