Package uniseg implements Unicode Text Segmentation, Unicode Line Breaking, and string width calculation for monospace fonts. Unicode Text Segmentation conforms to Unicode Standard Annex #29 (https://unicode.org/reports/tr29/) and Unicode Line Breaking conforms to Unicode Standard Annex #14 (https://unicode.org/reports/tr14/). In short, using this package, you can split a string into grapheme clusters (what people would usually refer to as a "character"), into words, and into sentences. Or, in its simplest case, this package allows you to count the number of characters in a string, especially when it contains complex characters such as emojis, combining characters, or characters from Asian, Arabic, Hebrew, or other languages. Additionally, you can use it to implement line breaking (or "word wrapping"), that is, to determine where text can be broken over to the next line when the width of the line is not big enough to fit the entire text. Finally, you can use it to calculate the display width of a string for monospace fonts. If you just want to count the number of characters in a string, you can use GraphemeClusterCount. If you want to determine the display width of a string, you can use StringWidth. If you want to iterate over a string, you can use Step, StepString, or the Graphemes class (more convenient but less performant). This will provide you with all information: grapheme clusters, word boundaries, sentence boundaries, line breaks, and monospace character widths. The specialized functions FirstGraphemeCluster, FirstGraphemeClusterInString, FirstWord, FirstWordInString, FirstSentence, and FirstSentenceInString can be used if only one type of information is needed. Consider the rainbow flag emoji: 🏳️🌈. On most modern systems, it appears as one character. But its string representation actually has 14 bytes, so counting bytes (or using len("🏳️🌈")) will not work as expected. Counting runes won't, either: The flag has 4 Unicode code points, thus 4 runes. The stdlib function utf8.RuneCountInString("🏳️🌈") and len([]rune("🏳️🌈")) will both return 4. The GraphemeClusterCount function will return 1 for the rainbow flag emoji. The Graphemes class and a variety of functions in this package will allow you to split strings into its grapheme clusters. Word boundaries are used in a number of different contexts. The most familiar ones are selection (double-click mouse selection), cursor movement ("move to next word" control-arrow keys), and the dialog option "Whole Word Search" for search and replace. This package provides methods for determining word boundaries. Sentence boundaries are often used for triple-click or some other method of selecting or iterating through blocks of text that are larger than single words. They are also used to determine whether words occur within the same sentence in database queries. This package provides methods for determining sentence boundaries. Line breaking, also known as word wrapping, is the process of breaking a section of text into lines such that it will fit in the available width of a page, window or other display area. This package provides methods to determine the positions in a string where a line must be broken, may be broken, or must not be broken. Monospace width, as referred to in this package, is the width of a string in a monospace font. This is commonly used in terminal user interfaces or text displays or editors that don't support proportional fonts. A width of 1 corresponds to a single character cell. The C function wcswidth() and its implementation in other programming languages is in widespread use for the same purpose. However, there is no standard for the calculation of such widths, and this package differs from wcswidth() in a number of ways, presumably to generate more visually pleasing results. To start, we assume that every code point has a width of 1, with the following exceptions: For Hangul grapheme clusters composed of conjoining Jamo and for Regional Indicators (flags), all code points except the first one have a width of 0. For grapheme clusters starting with an Extended Pictographic, any additional code point will force a total width of 2, except if the Variation Selector-15 (U+FE0E) is included, in which case the total width is always 1. Grapheme clusters ending with Variation Selector-16 (U+FE0F) have a width of 2. Note that whether these widths appear correct depends on your application's render engine, to which extent it conforms to the Unicode Standard, and its choice of font.
Package dialog provides a simple cross-platform common dialog API. Eg. to prompt the user with a yes/no dialog: The general usage pattern is to call one of the toplevel *Dlg functions which return a *Builder structure. From here you can optionally call configuration functions (eg. Title) to customise the dialog, before using a launcher function to run the dialog.
Package dialog provides a simple cross-platform common dialog API. Eg. to prompt the user with a yes/no dialog: The general usage pattern is to call one of the toplevel *Dlg functions which return a *Builder structure. From here you can optionally call configuration functions (eg. Title) to customise the dialog, before using a launcher function to run the dialog.
Package dlgs is a cross-platform library for displaying dialogs and input boxes.
Package zenity provides cross-platform access to simple dialogs that interact graphically with the user. It is inspired by, and closely follows the API of, the zenity program, which it uses to provide the functionality on various Unixes. See: https://help.gnome.org/users/zenity/stable/ This package does not require cgo, and it does not impose any threading or initialization requirements.
Present OAuth2 dialogs to the user.
Package dialog implements simple cross platform native MessageBox/Alert dialogs for Go. Currently, only supports Windows and Linux targets. On Linux, uses (in order of preference) `zenity`, `xmessage`, or stdio. Usage is quite simple: License: MIT-0 (see LICENSE.txt) Stable: yes For more information, documentation, source code, examples, support, links, etc. please see https://www.tawesoft.co.uk/go and https://www.tawesoft.co.uk/go/dialog
Eg. to prompt the user with a yes/no dialog: The general usage pattern is to call one of the toplevel *Dlg functions which return a *Builder structure. From here you can optionally call configuration functions (eg. Title) to customise the dialog, before using a launcher function to run the dialog.
Copyright © 2023 Xavier Portilla Edo Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.
Package iup implements Go bindings for IUP (https://www.tecgraf.puc-rio.br/iup/). IUP is a multi-platform toolkit for building graphical user interfaces. Currently available interface elements can be categorized as follows: IUP has 3 concepts that any user has to understand: Elements, Attributes and Callbacks. Elements are every kind of interface element present in the application. IUP contains several user interface elements. The library's main characteristic is the use of native elements. This means that the drawing and management of a button or text box is done by the native interface system, not by IUP. This makes the application's appearance more similar to other applications in that system. On the other hand, the application's appearance can vary from one system to another. Besides, some additional controls are drawn by IUP, and are independent from the native system. Dialogs are special elements that represent every window created by IUP. Any application that uses IUP will be composed by one or more dialogs. Every dialog can contains one or more controls inside. IUP controls are never positioned in a specific (x,y) coordinate inside the dialog. The positioning is always calculated dynamically from the abstract layout hierarchy. So get used to the Fill, Hbox and Vbox controls that allows you to position the controls in the dialog. Attributes are used to change or consult properties of elements. Each element has a set of attributes that affects its behavior or its appearance. Each attribute may work differently for each elements, but usually attributes with the same name work the same. Attribute names are always upper case. But attribute values like "YES", "NO", "TOP", are case insensitive, so "Yes", "no", "top", and other variations will work. IUP has only a few functions because it uses string attributes to access the properties of each control. So get used to SetAttribute and GetAttribute, because you are going to use them a lot. Attribute names are always upper case, lower case names will not work. But attribute values like "YES", "NO", "TOP", are case insensitive, so "Yes", "no", "top", and other variations will work. If not defined their value can be inherited from the parent container. Boolean attributes accept the values "1", "YES" or "ON" for true, and "0", "NO" or "OFF" for false. But they will return the value described in the documentation. You can also use SetInt with 1 for true and 0 for false. GetInt will return 1 for any of the true values, and 0 for any of the false values. Callbacks are functions which notify the application that some user interface event occurred. Usually callbacks will be called only when the user interacts with the application elements. If the application register the callback function, then the function will be called every time the event occurs. IUP has several global tables along with some system tools that must be initialized before any dialog is created. The default system language used by predefined dialogs and messages is English. But it can be changed to Portuguese or Spanish. Before running any of IUP’s functions, function Open must be run to initialize the toolkit. After running the last IUP function, function Close must be run so that the toolkit can free internal memory and close the interface system. Executing these functions in this order is crucial for the correct functioning of the toolkit. Between calls to the Open and Close functions, the application can create dialogs and display them.
Package dialog provides a simple cross-platform common dialog API. Eg. to prompt the user with a yes/no dialog: The general usage pattern is to call one of the toplevel *Dlg functions which return a *Builder structure. From here you can optionally call configuration functions (eg. Title) to customise the dialog, before using a launcher function to run the dialog.