Programming the Roma Widget Set (C# X11) - a zero dependency GUI application framework - Introduction






4.93/5 (40 votes)
How to get out the maximum from the Roma widget in C# efficiently without dependencies to GUI frameworks like GTK or KDE. Basics and description of concepts.
Download complete project, older version 0.10, 0.20, 0.30, 0.40, 0.50, 0.60, 0.70, 0.80, 0.90 32 bit (zip).
Download complete project, older version 0.10, 0.20, 0.30, 0.40, 0.50, 0.60, 0.70, 0.80, 0.90 64 bit (zip).
Download complete project current version 1.00 32 bit (zip)
Download complete project current version 1.00 64 bit (zip)
Download Xrw API Documentation (in HTML) version V1.00 (zip)
Introduction
This article introduces the Roma Widget Set (Xrw), a C# GUI application framework, that is directly based on X11 library calls. The idea of the Roma Widget Set has been developed as consequence of the first article from an article series dealing with Xlib/X11/Xt/Xm, Programming Xlib with Mono Develop - Part 1: Low-level (proof of concept) and influenced by the experience made through writing the subsequent articles Programming Xlib with Mono Develop - Part 2: Athena widgets (proof of concept), Programming Xlib with Mono Develop - Part 3: Motif widgets (proof of concept) and Programming Xlib with Mono Develop - Part 4: FWF Xt widgets.
The zero dependency promise means, it requires only assemblies of the free Mono standard installation and libraries of the free X11 distribution; it doesn't particularly require GNOME, KDE or any commercial library.
Because the whole Topic grew beyond 50 print pages, i decided to split it into three parts with and into four parts with
. With
i moved the complete API description to a separate HTML documentation (that is part of the Xrw project) and restructured all four articles to make reading more entertaining and exciting:
This article: Programming the Roma Widget Set (C# X11) - a zero dependency GUI application framework - Introduction. It contains a short explanation of the widget set's features. (Before
it was: ~ Basics. It contained general descriptions.) This atricle should always be the preferred starting point.
The first split-off article: Programming the Roma Widget Set (C# X11) - a zero dependency GUI application framework - Widget set. Due to the constantly growing of 'boring' API documentation, the API documentation has been moved with
to a separate HTML documentation (that is part of the Xrw project) and this article has been focused on a briefly introduction of all widgets. (Before
it was: ~ Intrinsic widgets. It contained the full featured API reference description of intrinsic widgets only.)
The second split-off article: Programming the Roma Widget Set (C# X11) - a zero dependency GUI application framework - Programming techniques. Due to the constantly growing of 'boring' API documentation, the API documentation has been moved with
to a separate HTML documentation (that is part of the Xrw project) and this article has been focused on programming techniques. (Before
it was: ~ Simple widgets. It contained the full featured API reference description of simple widgets only.)
The third split-off article: Programming the Roma Widget Set (C# X11) - a zero dependency GUI application framework - MVVM/XAML support. Due to the constantly growing of 'boring' API documentation, the API documentation has been moved with
to a separate HTML documentation (that is part of the Xrw project) and this article has been focused on introducing the MVVM/XAML support of the Xrw. (Before
it was: ~ Composite widgets. It contains the full featured API reference description of composite widgets only.)
This article provides a sample application's complete solution for 32 bit and 64 bit. All features, described later on, can be marked as:
|
|
First - the main disadvantages:
- The complete GUI application framework is crafted - there is no big developer comunity in the background.
- The framework uses the capabilities of C# and X11 (via P/Invoke) only - currently no additional libraries like Xt, Xpm, Xft, Cairo, Pango, ... or X11 extensions like XRENDER (for alpha blending and color gradient support), DOUBLE_BUFFER (for flicker-free drawing of expensive content), DAMAGE (for a better expose handling), XInputExtension (for gesture support), ... are involved. That's why drawing capabilities are limited (no native support for color gradients, no font antialiasing) and user interaction capabilities are limited (not flicker-free, no gestures).
- It is platform dependend - it runs on X11 only.
- There is no GUI designer.
- Only 24 bit color model (16 777 216 colors, 32 bits per pixel) is fully supported right from
. The 16 bit color model (65536 colors, 16 bits per pixel) is supported since
, but no color optimization or smoothing is provided for the reduced color space.
Second - the main advantages:
- The framework is small, very well inline-documented and can be adopted/extended to a specific need easyly. In addition a full featured API reference HTML documentation is part of the Xrw project.
- The framework comes with complete source code and is wirtten entirely in C# - all parts of the framework can be maintained from a single C# solution or project.
- The framework has no dependencies except X11 and it has zero overhead. It is very lightweight and fast.
- The framework
starts to provide widgets, that are not available for Athena widget set, and some of them even not for Motif or GTK. The first of them is a basic ribbon, followed by a property grid.
- The framework core got a XAML wrapper (introduced with
) and has been optimized to support the MVVM pattern. This enables platform independend development (Windows and UNIX/LINUX), even if the framework is limited to X11 only, and is currently unique among the GUI frameworks for UNIX/LINUX.
This enumeration provokes questions:
- Why not utilize GTK#? GTK#'s current stable implementation is still based on GTK's version 2.12. There is an unstable GTK# implementation based on GTK's version 2.24 and a GTK# implementation based on GTK's version 3.xx is in development (GTK# version 2.99) for more than two years without substantial progress now. All in all - GTK# is very stable (several huge applications rely in it, e.g. MonoDevelop), integrated into GTK's home page and well documented (via Mono's API documentation) but it is more or less outdated, the procedural roots of GTK's 'C' API shine through the C# wrapper and -very important- it is not a smooth .NET integration (e. g. Data Binding for models is not available). IMO it is the very best alternative to the Xrw project.
- Why not utilize Qt#/Qyoto/QtSharp? The history and the current state of Qt's C# binding libraries are very confusing. None of the them has an own home page or is integrated into Qt's home page. The new Qt version 5.x API is not supported and they provide no smooth .NET integration (e. g. signal/slot mechanism is separate from .NET events).
- Why not utilize Mono's implementation of System.Windows.Forms? Even if there are tons of documentation and samples, the development is announced to be complete, full compatibility with .NET is neither achieved nor possible and the technology is outdated.
- Why not use Moonlight? It is abandoned and it's archetyp Silverlight is discontinued as well.
- Why another GUI application framework (and not wxWidgets, FLTK, FOX or something like that)? None of the so far mentioned GUI frameworks is MVVM/XAML ready. It is fun to deal with the callenges such a complex initiative contains. The individuality that applications can reach and the flexibility to design an uncommon GUI for a specific application is unbeatable. The only, currently very promising alternative seems to be the the very young MonoGame. I'll watch it's progress and capabilities.
There are no plans to run the framework on other platforms than X11 - a MVVM/XAML support with desired syntax and functionality as near to the Microsoft® original as reasonable is the better way to achieve platform independence. It might be that any future version is based on a more modern API than X11, e.g. CLUTTER.
Currently i plan to close this project with version 1.0 and to evolve an "Next Level" Roma Widget Set, that introduces some new aspects: 1: Drawing shall enable gradient colors and antialiasing text (either via the Cairo library or via the X11 extension like XRENDER), if necessary in cooperation with Pango or Xft library. 2: XAML/MVVM support for GUI definition shall reach a level that enables a developer to develop for X11 and Windows in parallel, using as much portable code (XAML and C#) as possible.
Background
(1) The Roma Widget Set has been designed to support programming of simple GUIs for small tools. It's focus is the efficiency in application, not the completeness of rarely used features.
What are the alternatives?
All other native X11 or platform independent widget sets or GUI application frameworks - the Athena widget set and its descendants (e. g. neXtaw, XawM, Xaw-Xpm, XawPlus or Xaw3d), the Motif widget set (Open Motif or LessTif), GTK (GTK+ already has the C# wrapper GTK#), KDE (Qt already has C# wrappers Qt# (outdated), Qyoto (outdated) and QtSharp), wxWidgets, FLTK and FOX - are developed in C/C++ and are very hard to adopt/extend to a specific purpose within a C# project.
The Roma Widget Set GUI application framework shall support all adoptions/extentions through native C# code, integrate the .NET framework components and feel native .NET.
This is not a new idea/requirement. The DotGNU Portable.NET project - gone with the shutdown of it's parent project DotGNU in December 2012 - contains the pnetlib, which was under active development until March 2007 by Rhys Weatherley, at that time director of Southern Storm Software, Pty Ltd, and others. The last version (0.8.0) of the pnetlib project contains Xsharp and System.Windows.Forms among other things. While Xsharp implements a basic framework to program X11 from C# (and might be worth to take a look at it), System.Windows.Forms is a re-implementation of Microsoft's not ECMA standardized namespace and has always been subject of discussions and warnings about whether Microsoft is probably planning to destroy such C# implementations through patent suits.
(2) The Roma Widget Set framework is not intended to re-implement (be API compatible to) any known GUI framework. But, starting with , the Roma Widget Set framework got a XAML wrapper providing a WPF/MVVM pattern compatible XAML layer and can now (as an alternative to it's native C# API) be accessed via XAML with desired syntax and functionality as near to the Microsoft® original as reasonable.
This introduced a new design goal: To support programming of cross-platform GUIs. It's focus is the virtually complete Microsoft® compatibility, not the completeness of rarely used features.
Are there alternatives?
All other widget sets or GUI application frameworks - Athena widget, Motif, GTK (GTK#), KDE ( Qt#/Qyoto/QtSharp), wxWidgets (wx.NET) FOX, FLTK, and V- stick to their traditional API and do not support the MVVM pattern and XAML.
Using the code
The sample application was written with Mono Develop 2.4.1 for Mono 2.8.1 (built 2010-11-17) on OPEN SUSE 11.3 Linux 32 bit EN and GNOME desktop. Neither the port to any older nor to any newer version should be a problem. The sample application's solution consists of three projects (the complete sources are provided for download):
- X11Wrapper defines the function prototypes, structures and types for Xlib/X11 calls to the libX11.so
- Xrw contains the Roma Witget Set (Xrw) and (introduced with
) the HTML documentation of the API
- X11 contains the sample application
The sample application is also tested with Mono Develop 3.0.6 for Mono 3.0.4 (built 2013-02-02) on OPEN SUSE 12.3 Linux 64 bit DE and GNOME desktop, IceWM, TWM und Xfce.
The only difference between the 32 bit and the 64 bit solution is the definition of some X11 specific data types, as already described in the first article of this series.
Advice: To use the class library documentation shortcut (F1) from MonoDevelop, the "mono-tools" package have to be installed.
Main application window
The image shows the sample application with XrwTheme.GeneralStyle.WinClassic
.
The image shows the sample application with XrwTheme.GeneralStyle.Gtk2Clearlooks
.
The sample application demonstates
- a ribbon widget in sector A with three ribbons, that demonstrate
- a ribbon application menu,
- three ribbon tabs (Dialog test, Radio & toggle test, Split test),
- several ribbon panels (Large buttons, Medium buttons, ...),
- several ribbon buttons (File dialog, ...),
- several ribbon split buttons (Font, Color, ...),
- several ribbon control groups on the second ribbon tab (horizontal text align, vertical text align, weight and slant, superscript and subscript),
- several ribbon control group radio nodes and ribbon control group toggle nodes on the second ribbon tab (left, center, justify, right, ...),
- a top tabbed notebook widget in sector B with two tabs,
- the first tab contains a horizontally paned widget with a tree widget to the left and a property grid to the right,
- the second tab contains a horizontally paned widget with a list widget to the left and a property grid to the right,
- a bottom tabbed notebook widget in sector C with four tabs,
- the first tab contains a menu widget and a command widget,
- the second tab contains three toggle button widgets,
- the third tab contains three radio button widgets,
- the fourth tab contains a horizontal spin button, a combo box and a link button,
- the fifth tab contains a text widget,
- a label widget in sector D,
- the call of all available standard dialogs like
- X11 font specification based bitmap and vector font dialog introduced with
,
- GTK/Windows like font dialog introduced with
,
- file dialog introduved with
,
- color selector dialogs with 8x2 and 2x8 selectable colors introduced with
,
- color chooser dialog introduced with
,
- message box introduced with
(including markup, introduced with
),
- X11 font specification based bitmap and vector font dialog introduced with
- the call of individual dialogs to demonstrate
- several dock panel based layouts introduced with
,
- a simple drawing on canvas introduced with
,
- a simple drawing on image introduced with
and
- a uniform grid based layout introduced with
.
- several dock panel based layouts introduced with
Widget set standard dialogs
The sample application provides the ribbon application menu items "Open" and "Save as" within the ribbon's application menu to test the "File selection" dialog XrwFileSelectionDialog
.
The sample application provides the ribbon split buttons "Font | X11 dialog" and "Font | GTK/Windows dialog" to test the "Font selection" dialogs XrwBitmapAndVectorFontSelectionDialog
and XrwFontSelectionDialog
.
The sample application provides the ribbon split buttons "Color | Selector 2x8 dialog", "Color | Selector 8x2 dialog" and "Color | Chooser dialog" to test the "Color selection" dialogs XrwColorSelectionDialog
and XrwColorChooseDialog
.
The sample application provides the ribbon split buttons "Info | About dialog" and "Info | Help dialog" to test the "Message box" dialog XrwMessageBox
.
Sample application individual dialogs
The sample application provides the ribbon split buttons "Layout | Dock top first bottom second", "Layout | Dock top first left secondHelp dialog", "Layout | Dock left first right second" and "Layout | Dock left first top second" to show dialogs, that demonstrate the capabilities of the XrwDockPanel
.
The sample application provides the ribbon split button "Layout | Simple drawing on canvas" to show a dialog, that demonstrate the capabilities of the XrwCanvas
in combination with XrwArcFigure
, XrwEllipseFigure
, XrwLineFigure
, XrwPathFigureCollection
and XrwRectangleFigure
.
The sample application provides the ribbon split button "Layout | Simple drawing on image" to show a dialog, that demonstrate the capabilities of the XrwImage
.
The sample application provides the ribbon split button "Layout | Uniform grid" to show a dialog, that demonstrate the capabilities of the XrwUniformGrid
.
Idea backlog
Idea | Appeared | Solved |
Add ComboBox widget with SpinMenu. | version 0.1 | version 0.2 |
Add SpinButton widget. | version 0.1 | version 0.2 |
Add support for 16 bit color model. | version 0.1 | version 0.2 |
Add a font selection dialog similar to GTK/Windows (suitable to use with I18N text output, using font set instead font) | version 0.1, refreshed version 0.5 | version 0.7 |
Add missing static Xrw <align>Notebook factory method New BottomTabedNotebook . | version 0.1 | version 0.3 |
Change from 8 bit string to 16 bit string drawing to enable more than only ASCII characters (I18N text output) | version 0.2 | version 0.6 |
Add a simple initial color dialog. | version 0.2 | version 0.5 |
Add a basic ribbon widget. | version 0.2 | version 0.3 |
Add missing static Xrw <align>Notebook factory methods NewLeftTabedNotebook and NewRightTabedNotebook . | version 0.3 | |
Add a paned widget. | version 0.3 | version 0.4 |
Add a grid form widget. | version 0.3 | version 0.4 |
Add a basic property grid widget. | version 0.3 | version 0.4 |
Add tooltip to widgets. | version 0.3 | version 0.9 |
Add enhanced tooltip to ribbon. | version 0.3 | |
Add a labeled frame widget. | version 0.3 | |
Add an input dialog. | version 0.4 | |
Add alternative list views (Small icons, Large icons, List and Details). | version 0.4 | version 0.5 |
Add a more advanced color dialog. | version 0.5 | version 0.6 |
Add convenient wrapper XrwOpenFileDialog and XrwSaveFileDialog around XrwFileSelectionDialog . | version 0.5 | |
Add cut/copy/paste to XrwText . | version 0.5 | version 0.6 |
Support simple GUI definition via XAML to proof the concept. | version 0.6 | version 0.7 |
Add multiline editor. | version 0.7 | |
Support sub-menus on menu-items. | version 0.8 | |
Add basic printing capability. | version 0.8 | |
Change widget/gadget coordinates from Int32 based to Double based values | version 0.9 | |
Align drawing closer to Cairo.Context | version 0.9 |
Fixed errors
Fixed with :
- Double painting of XrwShell's children fixed.
- Missing background color initialization for widgets derived from XrwCore added.
- Fixed
X11Graphic
constructor argumentsindividualColormap
andgraphicDepth
fromapplication.IndividualColormap
andapplication.ColorDepth
toIntPtr.Zero
anddefaultColordepth
(to use the root window's color map and depth, not the application's color map and depth), and fixedX11Graphic.CreateIndependentGraphicPixmap()
/X11Graphic.CreateIndependentMaskPixmap()
method argumentwindow
fromapplication.Window
todefaultRootWindow
inXrwApplicationFramework.SetWmShellIcon()
. Both was necessary to support 16 bit color model. - Fixed
X11lib.XCreateGC()
method argumentx11drawable
fromwindow
topixmap
in<code>X11Graphic.
CreateIndependentGraphicPixmap(). It was necessary to support 16 bit color model.
Fixed with :
- Fixed exception during application closing, if any
XrwOverrideShell
is currently poped up, now the collection handling for parent's child list is correct. (Disposal of anXrwOverrideShell
implies removal from it's parent child list - this alters the child list collection.) - Fixed
X11Graphic.StockIcon.Information16
size from 18x18 to 16x16. - Fixed
XrwVisibleRectObj.ExpandToAvailableHeight
,XrwVisibleRectObj.ExpandToAvailableWidth
,XrwVisibleRectObj.ExpandToMaxSiblingHeight
andXrwVisibleRectObj.ExpandToMaxSiblingWidth
on any fixed dimension, now settingtrue
is suppressed, if a fixed height/width is assigned. - Fixed
XrwVisibleRectObj.
SetFixedHeight
andXrwVisibleRectObj.
SetFixedWidth
on any dimension expansion is set, nowXrwVisibleRectObj.ExpandToAvailableHeight
andXrwVisibleRectObj.ExpandToAvailableWidth
orXrwVisibleRectObj.ExpandToMaxSiblingHeight
andXrwVisibleRectObj.ExpandToMaxSiblingWidth
are reset tofalse
if formerlytrue
. - Fixed
XrwRectObj.GeometryManagerAccess.SetAssignedGeometry()
for a fixed height assignment, nowXrwVisibleRectObj.FixedSize.Height
is applied correctly - only ifXrwVisibleRectObj.IsFixedHeight
is true.
Fixed with :
- Fixed
XrwTree
's calculation ofPreferredSize()
. - Fixed drawing error in
XrwVisibleRectObj.DrawFrame()
. One pixel frames now don't overrun right/bottom coordinate. - Fixed
X11Graphic.StockIcon.Question16
andX11Graphic.StockIcon.Error16
size from 18x18 to 16x16. - Fixed
XrwFileSelectionDialog
height adaption. Width adaption has already been correct. Now a height change of the dialog leads to height change of the places and files viewports. - Fixed
XrwBitmapAndVectorFontSelectionDialog
height adaption. Width adaption has already been correct. Now a height change of the dialog leads to height change of the font style, font resolution and font size viewports. - Fixed scroll bar update for a
XrwViewport
containing aXrwTree
on tree node collapse or expand. Now theXrwTree
calls the registeredSizePreferenceChanged
delegates. - Fixed positioning of a manager widget inside a manager gadget. E. g. a
XrwPaned
(horizontal) widged inside aXrwBox
gadget (vertical) is positioned correct. Now theGeometryManagerAccess.SetAssignedGeometry()
method resets not only a widget's assigned position to 0,0, but also the position offset of it's children. This is because a widget has it's own X11 window and all positions must be measured relativle to the window. - Fixed crash if application has a working folder different to the installation folder. Now the
X11Graphic
loader also looks up the installation folder for a graphic file not found in the working folder.
Fixed with :
- Fixed
XrwViewport
's calculation ofCalculateChildLayout()
. For children, whose size needs one scroll bar only, and the display of this scroll bar decreases the available size in a manner that requires a second scroll bar, now the second scroll bar will be displayed. - Fixed redrawing problem of GUI parts, obscured (covered) by
XrwSimpleMenu
(or it's derivativesXrwSpinMenu
andXrwDropDownCellEditorShell
) and uncovered after menu popdown, if any selectedXrwSme
invokes a dialog. (This is because a dialog (XrwDialogShell/XrwTransientShell/XrwWmShell) implements an internal event processing loop.) Now the sme'sOnButtonReleased
delegate will not be called directly by the sme's ButtonRelease event Instead a CustomMessage event will be generated, that goes to the end of the message queue. The CustomMessage event only calls the sme'sOnButtonReleased
delegate, if it is his turn (in the message queue). This procedure guarantees the processing of any menu's Unmap event before the sme's ButtonRelease event.
Fixed with:
- Fixed
XrwComboBox
's wrong display of selected value. After a selection change, the old value is displayed instead of the new one. This problem is caused by thefix no. 2. The CustomMessage, generated by a sme's ButtonRelease event, has not been processed correctly because the
XrwSpinMenu
has been registered twice to theXrwApplicationShell
- as child and as associated shell. Now theXrwSpinMenu
is registered as associated shell only. - Fixed calculation errors in
XrwGridForm
'sMinimumSize()
andPreferredSize()
. Now the left/right/top/bottom margins and the child sizes (for columns of dynamic width/rows of dynamic height) are considered. - Fixed pointer motion behavior of
XrwScrollBar
. NowMotionNotify
events outside the thumb (inside up/down buttons or slide area) do not confuse the thumb position calculation. - Fixed undo ([Ctrl] + [z])/redo ([Ctrl] + [y]) begaviour for
XrwText
. Now an undo command for a multi-character insert removes all inserted characters (not only the first one) and now all redo comands (no matter whether remove or insert of single-character or multi-character) work at the original selection and caret position (not at the current selection and caret position, if they have moved) and restore the correct selection and caret position after operation as well. - Fixed
XrwBox
andXrwSpinBox
's wrongPreferredSize
calculation. Now theExpandToMaxSiblingWidth
andExpandToMaxSiblingHeight
flags of children are considered. - Fixed
XrwGridFrame
's wrongCalculateGridGeometry
calculation. Now theBorderWidth
is considered. - Fixed
XrwGridFrame
's wrongCalculateMinimumSize
andCalculatePreferredSize
calculation. Now theMargin
is no longer considered forFixedDimension
columns/rows. - Fixed the sub-classes of
XrwLabelBase
(affected areXrwComboBox
,XrwLabel
,XrwLabelAndColor
,XrwTextSpinButton
,XrwToggle
), and theXrwText
's wrongPreferredSize
calculation. Now theFixedSize
is considered. - Fixed
XrwMenuButton
's wrong menu registration. Now the registration of the built-in menu works forXrwMenuButton
s that are child of aXrwDialogShell
as well. - Fixed
XrwOverrideShell
's wrong registration/deregistration to/from the parentXrwWmShell
duringRealize
andUnrealize
. Now the registration/deregistration works forXrwOverrideShell
s that are child of aXrwDialogShell
as well. - Fixed calculation error for
XrwViewport
'sHScrol.
ThumbPageWidth
andVScroll.T
humbPageWidth
property duringCalculateChildLayout
. Now theT
humbPageWidth
is calculated as part, not as multiple, of the viewport's clip size. - Fixed redrawing problem of GUI parts, obscured (covered) by
XrwRibbonAppMenu
and uncovered after menu popdown, if any selectedXrwSme
invokes a dialog. (see "Fixed with" No. 2).
Fixed with :
- Fixed
XrwList
's andXrwTree
's wrong display after editing an enumerable value with the default editor based onXrwDropDownCellEditorShell
. After the selection of a new value, the old value has been still displayed instead of the new one. Now redrawing is invoked explicitly. - Fixed error in
XrwComboBox
'sXrwSpinMenu
spin fore/spin back functionality. The menu pops down after any spin button click. This error has been undetected since, when
XrwSimpleMenu
introducedHandleParentRoutedClientMessage()
(see "Fixed with" No. 2).
Fixed with :
- Fixed infinite loop in
XrwVisibleRectObj
'sDrawTextLineAutoLineBreak()
method, if widget/gadget width is smaller than the width of one single character. - Fixed redrawing problem in
XrwWmShell
and derivatives. In case of ALL children of the shell are gadgets, configure events with new size < old size the configure events aren't followed by an expose event generated by the X11 server. In this case an expose event must be generated manually. - Fixed drawing of insensitive widget's/gadget's text for
XrwLabel
and derivatives. Sinceintroduced
StyleText
, every text style sets the foreground color. Now insensitive widget's/gadget's text keeps the foreground color unchanged for all text styles. - Fixed incomplete application termination, if application window is closed while any dialog is open. Dialogs (transient shells) take over the (infinite) message loop processing from the application shell. Closing the application window calls
DefaultClose()
for every associated transient shell now. A transient shell must override theDefaultClose()
method to stop it's (infinite) message loop processing. - Fixed structure layout for
X11lib.XColor
. The color values for red, green and blue are of typeX11.TUshort
(0-65535), notX11.TUchar
(0-255). - Fixed the high CPU load on idle message queue (about 50% for two cores). The evaluation of suspended
ConfigureEvent
did return immediately fromXrwApplicationShell.DoEvent()
message queue evaluation instead to return only after any suspendedConfigureEvent
has been found and processed. CPU load is below 1% now (for two cores). - Fixed the display errors for
XrwSpinBox
navigation. For anyXrwSpinBox
, that is part of a transient shell, the navigation has caused display errors on the application shell's top left corner, if the appearance of any spin button is switched off (even temporary). All spin buttons, that are removed fromXrwSpinBox
, have been re-parented toApplicationShell
and produced the display errors on the application shell after theirUnrealize()
call. Now spin buttons, that are removed, are re-parented toWmShell
and avoid display errors on the application shell after theirUnrealize()
call. - Override shell based popups (
XrwSimpleMenu
,XrwRibbonAppMenu
,XrwToolTipShell
,XrwBaseCellEditorShell
) and derivatives (XrwSpinMenu
,XrwDropDownCellEditorShell
,XrwGenericCellEditorShell
) do not acquire the focus after popup viaRequestInputFocus()
anymore. As a result override shell based popups do not triggerFocusOut
(for application or dialog shell, they belong to) andFocusIn
(for themselfs) events any longer. Therefore the application or dialog shell, the popups belong to, do not loose the active window frame - and do not confuse anymore by appearing inactive. Instead the key event processing inXrwApplicationShell
preferres registered override shells. - Removal of the
INotifyPropertyChange
implementation from (almost) all controls, since the Microsoft® original doesn't implementINotifyPropertyChange
for controls.
Fixed with :
- Fixed calculation of
MinimumSize()
andPreferredSize()
forXrwDockPanel
. Fallback for children withoutDockStyle
patched and height impact for children withDockStyle.Fill
noticed. - Fixed wrong calls to
X11lib.XSync()
. Many callts toX11lib.XSync()
have been performed with parameterdiscard
set to(X11.TBoolean)1
. This is wrong because it discards all events already synchronized to the event queue. The parameterdiscard
set to(X11.TBoolean)1
should be the absolute exception. This may also have an positive impact on ony types of popups,XrwOverrideShell
derivatives as well asXrwTransientShell
derivatives. - The
X11.TBoolean
has been defined to mapsbyte
, but X11/Xlib.h definesBool
to beint
. This has been fixed andX11.TBoolean
is defined to mapint
now. - Fixed crash on close a modal dialog box and immediate open another modal dialog box. Sometimes the input focus can't be set to the newly opened modal dialog box, because the
XrwDialogShell
is not yet maped by the X server while the X client requests the input focus for the shell. - The
XrwPathFigureCollectionGeometry.Bounds
property did take into account only the boundings of the lastX11.IPathFigure
of multiple figures, this is fixed now. - The
System.Windows.Media.PathGeometry.TryParsePathData()
method did not correctly parse successive path segments of the same type (move to, line to, curve, ...), that do not repeat the segment code (M, L, C, ...). Not repeating the segment code is permitted by definition and will be treated correct now. - The
XrwGridForm.CalculateChildLayout()
method didn't catch rows/columns, that are out of range. This is fixed now and rows/columns, that are out of range, fall back to meanigful values. - The
XrwRectObj.KeyPress
andXrwRectObj.KeyRelease
events have been sent twice forXrwApplicationShell
becauseXrwApplicationShell
s have peen processed once during the widget hierarchy traversing and once as a fallback, if no event delegate has flagged the event to stop further processing. The fallback is suppressed now, if the event has already been sent to theXrwApplicationShell
during the widget hierarchy traversing. - Since
removed the
INotifyPropertyChange
implementation from (almost) all controls, an alternative implementation is provided andDependencyProperty
bindings work again. - Some minor bugs are fixed in
X11.Text.TextStyle
class constructor's markup parser. Now<s>
(strikeout) and<u>
(underline) work correctly and unnecessary (no change to previous style)X11.Text.Style
creations do not appen anymore. - The
XrwFileSelectionDialog
did show "Default" as column names for places list and files list. This is fixed to "Folder names" and "File names" now.
Interim result : Verion 1.00 of Xrw widget/gadget interface is very reliable. All known bugs are fixed.
But: Some capabilities are still missing. Especially printing support is not realized and drawing capabilities have reached the limit of the X11 API. The XAML/MVVM approach is much more efficient to use for GUI creation and much more fun.
This is why i decided to focus on XrwXAML for the next view versions and to provide Cairo drawing besides X11 drawing. The alternative to Cairo would be OpenGL/Mesa, but Cairo provides PDF (--> printing) and SVG support off the cuff.
Improvements
Improved with :
- Generic drawing method to draw arrows for scroll bars, forth and back buttons
XrwVisibleRectObj.DrawArrow()
. - New method signature for
X11lib.XAllocWMHints()
, now returning the unmanaged memory handle ofWMHints
and the marshaled strurture as reference argument. This enables to callX11lib.Free()
with the unmanaged memory handle ofWMHints
.
Improvements with :
- Removal of needles X11 events from the event queue (events for an X11 window, that just has been unrealized) on
XrwApplicationShell.RemoveCild()
andXrwCore.DisposeByParent()
. - Additional themes
XrwTheme.GeneralStyle.WinLuna
,XrwTheme.GeneralStyle.WinRoyale
andXrwTheme.GeneralStyle.WinMidori
. - Extensions to the
XrwNotebook
to support bottom tabs. - A ribbon widget, that supports application menu button/application menu, tabs, panels, buttons, split buttons and control groups as well as theming.
Improvements with :
- New optional column header display for
XrwViewport
, ifChild
implementsXrwIGridView
interface (likeXrwList
andXrwTree
do). - Ability to display multiple columns for
XrwList
and, if embedded in aXrwViewport
, optional column header. - Ability to display multiple columns for
XrwTree
and, if embedded in aXrwViewport
, optional column header. - Reduced needles redrawing of
XrwComposite
's children by callingInvokeRedraw()
for gadgets (children without own window) only (widgets receive the expose event from the WM anyway). - Reduced flickering during the application window's resizing process (see "Specific aspects of event processing" for details).
- Multiple root nodes for
XrwTree
. - Added a paned manager widget
XrwPaned
, that supports child resizing without any parent size change, and a grid form manager gadgetXrwGridForm
, that supports column/row based child layout (including column/row span capabilities and fixed or dynamic column/row dimensions). - Convenience functions to set user defined font specification and explicit assignment of the current
DefaultFontName
to every newly created widget's GC (graphics context). XrwList
andXrwTree
show boolean values as toggle images now, instead of as text.- Added editability for
XrwTree
(required for a simple property grid widget). - Added a simple property grid widget
XrwPropertyGrid
, using reflection to determine the properties to display and edit. Properties of typestring
,bool
,ThreeState
andenum
are editable (utilize the provided standard editors).
Improvements with :
- Replacement of the proprietrary data types
TSize
,TPoint
andTRectangle
by System.Drawing.Size, System.Drawing.Point, System.Drawing.Rectangle and some extension methods. XrwList
now supports the view typesViewType.List
,ViewType.SmallIcon
andViewType.LargeIcon
in addition toViewType.Details
.XrwList
now supports multi selection.- Reduced flickering on mouse move inside
XrwList
andXrwTree
. Mouse move handler callsRedrawContent()
directly now (instead of callingInvokeRedraw()
, that is always deleting the background first - the reason for flickering - and callingRedrawContent()
afterwards). - Added column resizig for
XrwList
andXrwTree
. - Added clipping to text output, important for
XrwList
andXrwTree
column resizing below column's preferred size. - Added in-place editing for
XrwList
andXrwTree
, build-in editors provided for single line text, boolean values, three-state values and enumerations. - Introduction of the
X11Surface
class to centralize all rendering associated properties forXrwVisibleRect
and derived widgets and to prepare for easy switch to "Cairo" rendering in later versions of the widget set (see Programming Cairo text output beyond the 'toy' text API (C#/X11) - a prrof of concept meanwhile). - Added column reordering for
XrwList
andXrwTree
. - Introduction and exclusive usage of new static log class
SimpleLog
, implemented through X11wrapper solution, instead of heterogeneousConsole.WriteLine()
calls. - The
XrwGridForm
now overrides theMinimumSize
nowPreferredSize
methods ofXrwComposite
with more suitable size calculations.
Improvements with :
- Now international text output (I18N) is supported on X servers, where the C runtime provides locale setting (
libc.setlocale
) and is configured to a locale other than"C"
and"POSIX"
as well as the X server supports internationalization (X11ibc.XSupportsLocale
). (This is realized usingXCreateFontSet
andXwcDrawString
insteadXLoadFont
andXDrawString
.) Otherwise text output is improved from 256 character set (ASCII) to 65535 character set (ISO) usingXDrawString16
insteadXDrawString
. - Now
XrwScrollBar
supports auto-repeat not only for up/down buttons, but for slide area too. Auto-repeat on up/down buttons invoke a step move. Auto-repeat on slide area invoke a page move. - Now
XrwScrollBar
's factory methods support a customThumbMaxValue
in the range of 100 ...INITIAL_THUMB_MAX_VALUE
(1.000.000). This provides adopted value ranges - e.g. for red/green/blue color components with a value range of 0 ... 255 each. - Now
XrwText
supports (optional)RegEx
validation and invokesValueChanged
event on valid value changes. It also supports cut ([Ctrl] + [x]), copy ([Ctrl] + [c]) and paste ([Ctrl] + [v]) operations of simple STRING data via clipboard. - The
XrwApplicationShell
now supports the clipboard eventsSelectionNotify
(to determine whether the data provider supports STRING data and to incorporate STRING data into aXrwText
widget) andSelectionRequest
(to provide the data requestor with the supported data types and to provide STRING data if requested). - The
XrwFileSelectionDialog
now supports a file extension filter. It's geometry management is based on aXrwGridForm
now instead of nestedXrwBox
es. The width of the places list and files list can be adjusted by aXrwPaned
now. And the scrollbars of the places list and the files list are updated after any place or filter change. - For cascaded transient shells (e. g.
XrwFileSelectionDialog
invokes aXrwMessageBox
) it hasn't been guaranteed that the last invoked shell is displayed on top and is activated. Now every invocation of a transient shell callsXrwApplicationShell.RequestWindowActivation
.
Improvements with :
- Now
XrwLabelBase
and it's derived classes support theTextOverflowBehaviour
sClip
,Ellipsis
,AutolinebreakClip
andAutolinebreakEllipsis
. - Now
XrwRibbonTab
s, that have insufficient width to display allXrwRibbonButton
s and/orXrwRibbonSplitButton
s within allXrwRibbonPanel
s using theirPreferredSizeMode
, can adopt it's size by changing theXrwRibbonButton
's and/orXrwRibbonSplitButton
sCurrentSizeMode
. SeeXrwRibbonButton
and/orXrwRibbonSplitButton
description for details. - Now the
XrwRibbonButton
andXrwRibbonSplitButton
, displayed withCurrentSizeMode
==RibbonPanelSizePolicy.Large
can be displayed with slim width (44px instead 64px), if the label text fits the slim width. - The
XrwFileSelectionDialog
,XrwBitmapAndVectorFontSelectionDialog
,XrwMessageBox
,XrwColorSelectionDialog
andXrwColorChoseDialog
now support closing with [Enter] or [Return] key (equal to OK button) and [Excape] key (equal to Cancel button). - The
XrwList
andXrwTree
now support insensitive items/nodes, that can't be selected and are displayed withInsensitiveTextColor
. - Added slider
XrwScale
, that can adjust a float value. - Now horizontal oriented
XrwScrollbar
s, if thumb is dragged, continue dragging even if the mouse pointer leaves the thumb to-above or to-below direction, but not to the right or left. And vertical orientedXrwScrollbar
s, if thumb is dragged, continue dragging even if the mouse pointer leaves the thumb to the right or left, but not to-above or to-below direction. This behaviour is closer to the GTK and Windows scrollbar behaviour. Furthermode this behaviour is consistent to the behaviour of column resizig ofXrwList
andXrwTree
and dragging behaviour ofXrwScale
. - Indroduction of basic XAML (see Writing a XAML dialog application for X11, Writing a XAML ribbon application for X11 and Writing a XAML application for X11 with massive data binding and zero code).
Improvements with :
- Added
XrwFrame
, that arranges just one single child. - Introduction of
TStyleChar
data type andStyleText
class to support text styling.TStyleChar
supports single font andXChar2b
text output viaXDrawString16()
as well as fontset andTWchar
text output viaXwcDrawString()
.StyleText
class replacesMultiline
andLine
classes.
==> Added markup, widely comparable with GTK's Pango Markup Language, toXrwLabelBase
and it's derived classes likeXrwToggle
,XrwRadio
,XrwComboBox
,XrwTextSpinButton
andXrwLabelAndColor
. - Introduction of key gesture binding, that enables hot keys and shortcuts, e.g. for menus.
- Some more basic XAML (Writing a XAML calculator application for X11).
- Introduction of
TColor
data type to support alpha blending in future.TColor
supports plain X11TPixel
API as well as RGBA colors.
==> All color properties have been changed fromTPixel
data type toTColor
data type. - Key gesture binding to commands.
Improvements with :
- Added
XrwDockPanel
, that arranges children into up to five regions - top, bottom, left or right of the dock panel or filling the remaining space. - Added
XrwUniformGrid
, that arranges children into rows and columns - either set or calculated dynamically based on the children's preferred size and the availabe size of the grid. - Added
XrwCanvas
, that manages figures likeXrwArcFigure
,XrwEllipseFigure
,XrwLineFigure
,XrwRectangleFigure
andXrwPathFigureCollection
to provide interactive and manipulatable vector graphics. - Added interface
X11IPicture
and classX11Image
in addition toX11Graphic
. TheX11IPicture
abstracts the classesX11Image
andX11Graphic
and is used for most of the API from now on. While the existingX11Graphic
class provides a 'static' bitmap image (that doesn't change during runtime) and provides easy access to predefined icons, the newX11Image
class provides a 'volatile' bitmap image (that can change during runtime) through encapsulation of anXImage
structure. - Support for the two new
XrwLabel
propertiesLeftBitmapInsensitive
andRightBitmapInsensitive
in addition toLeftBitmap
andRightBitmap
to display a different set of images on sensitivity and insensitivity. - Added a very simple implementation
XrwClientMessageBasedTimerManager
for time scheduling, that is based on repeating X11 client messages within the message loop. TheXrwApplicationShell
's message loop is responsible as well for invocation as for evaluation ofWM_CLIENT_SHIFT_TIMER
messages. - Added tool tip to all widgets and most of the gadgets. The delayed display is realized via the
XrwClientMessageBasedTimerManager
.
Improvements with :
- Added
Margin
property toXrwRectObj
. The margin is the space between this widget/gadget and other neighboring widgets/gadgets of a user interface. - Finished implementation of
X11LinearGradientBrushInfo
class (that is also the basis for XAMLLinearGradientBrush
class). Linear gradients have drawn the median color only so far. They are supported now byXrwFigure
and XAMLShape
derived classes. - Implementation of
X11RadialGradientBrushInfo
class (that is also the basis for XAMLRadialGradientBrush
class). Radial gradients have drawn nothing so far. They are supported now byXrwFigure
and XAMLShape
derived classes. - Almost all
XrwVisibleRectObj
derived widgets/gadgets draw their background as a simulated linear (vertical) gradient that is based on a set of three colors, which have been accessible via*ColorDark
,*ColorLight
and*ColorMedium
properties (likeBackgroundColorDark
,BackgroundColorLight
andBackgroundColorMedium
). All sets of such three colors properties,*ColorDark
,*ColorLight
and*ColorMedium
, have been replaced by a single*Brush
property (likeBackgroundBrush
). The*Brush
property acceptsX11LinearGradientBrushInfo
instances, that provide a fully backward compatible look & feel, if powered by three color stops containing the primary*ColorDark
,*ColorLight
and*ColorMedium
values. TheXrwVisibleRectObj
provides a bunch of predefinedX11LinearGradientBrushInfo
instances to simplify utilization of the new*Brush
property, eg.InteractiveBackgroundGradientBrush
,InteractiveFocusedBackgroundGradientBrush
,RibbonBackgroundGradientBrush
, ... This change has been made to prepare the API for new background drawing capabilities (linear gradient brushes with different direction or number of color stops, radial gradient brushes, image brushes, ...). - The
XrwRectObj.KeyPressChar
event is sent now even if the lookup string is empty. To handle these cases, theXKeySym
will be passed with the event now. And theXrwRectObj.KeyReleaseChar
event has been added. - Basic implementation of XAML
Control
templating. Now theControl.Template
property is evaluated duringMeasureCore()
. TheButton
class has a default template (see reference). - Basic Implementation of XAML
FrameworkElement
styling. Now theFrameworkElement.Stype
property (Setter
,Trigger
andControlTemplate
) takes affect. - The
XrwDockPanel
usesDockStyle.Left
as default dock and considers theLastChildFill
property now. - The
XrwScrollbar
auto-repeat (on constantly pressed left/right or up/down button) triggered expose events, but they didn't work reliable ifXrwScrollbar
is placed in a dialog (XrwTransientShell
). Since the auto-repeat implementation limits the processing speed of the application's event loop, there have often been two dispose events for one widget in the event queue and the event compression of the application's event loop postponed the expose event processing. This is fixed now and a new expose event is triggered only if the event queue doesn't already contain an expose event for the widget. - The
X11FontService
classPrepareFont()
method fuzzy logic to determine the best matching font (if no font matches 100% the font specification) has 6 steps now instead of three. - A widget, that pops up a new
WmShell
(e.g. a dialog likeXrwFileSelectionDialog
) has been displayed focused until the focus has been changed by user interaction (e. g. mouse move) - even if the widget's parentWmShell
(e. g.XrwApplicationShell
) lost the focus for the benefit of the newWmShell
. This is fixed now by a reset of the widget'sMouseOver
andFocused
properties tofalse
duringRedraw()
if widget's parentWmShell
hasHasFocus
propertyfalse
. To guarantee this resetWmShell
s, that lose the focus, invoke an additional redrawing to all windowed and windowless children.
Interim result : Verion 1.00 of Xrw widget/gadget interface is very reliable. All known bugs are fixed.
But: Some capabilities are still missing. Especially printing support is not realized and drawing capabilities have reached the limit of the X11 API. The XAML/MVVM approach is much more efficient to use for GUI creation and much more fun.
This is why i decided to focus on XrwXAML for the next view versions and to provide Cairo drawing besides X11 drawing. The alternative to Cairo would be OpenGL/Mesa, but Cairo provides PDF (--> printing) and SVG support off the cuff.
Points of Interest
It was surprising how little effort is required to create a simple widget set with an attractive design.
This work should also animate other programmers to deal with Mono on Linux or Linux-like platforms.
Still working on the completion of Athena widget set compatible widgets.
After the implementation of the biggest part of the Athena widget set compatible widgets, the idea did not let up to go beyond this and to create higher sophisticated widgets, e. g. ribbon and property grid.
The idea to create higher sophisticated widgets goes on with panned and grid form widget.
To unlesh the power of list and tree widgets, features like column resizing and reordering as well as in-place editing have been added.
Realize internationalized text output and custom color choose.
Realize basic XAML support.
Realize a little more advanved XAML support. Introduce markup strings for
XrwLabelBase
and derivatives.
Even more advanved XAML support focused on controls and shapes. This did require some indepth revision of the XAML interpreter code and trigger some bug fixes and extensions to the widget set.
Even more advanved XAML support focused on shapes and control templating. This did trigger some bug fixes and extensions to the widget set.
History
The first public version of the Roma Widget Set is version from 20. January 2014.
The second public version of the Roma Widget Set is version from 07. March 2014.
The third public version of the Roma Widget Set is version from 01. Aplil 2014.
The fourth public version of the Roma Widget Set is version from 13. May 2014.
The fifth public version of the Roma Widget Set is version from 15. August 2014.
The sixth public version of the Roma Widget Set is version from 5. October 2014.
The seventh public version of the Roma Widget Set is version from 6. December 2014.
The eighth public version of the Roma Widget Set is version from 8. March 2015.
The ninth public version of the Roma Widget Set is version from 9. October 2015.
The tenth public version of the Roma Widget Set is version from 27. March 2017.