MivmazUI intended to give new hope to all would-be-users of AnyGui.
From my point of view AnyGui failed for several reasons:
- Wrong level of abstraction:
Abstracting at widget level is wrong decision for project that want to support multiple non-trivially different interface systems. For example curses and tk backends are different not only on implmentation level, but also have different program strategy expectation behind them.
- Results below level of expectation:
- I mean both speed of project development and quality of user interface of program using it. Costs of compatibility and portability should not lead to unusable interface.
- Loss of interest:
- Obvious result of first two reasons.
We will do it different way!
Ideas behind MivMaz is simple:
- 99% programs interact with user using 1% of all possible interface schemes.
gcc, dd and ping does very different things, but are indistiguisheble from interface point of view. I.e. they behave differently, but interact simlessly - they get arguments and output results while doing their job.
same application scheme can be uniformly configured regardless what does application that uses it.
same application scheme must have different design/interaction style in different environments (console/gui/web).
The last idea is key of all project. Basic entity in MivMaz is not widget, but scheme. Scheme is way how program interact with user.
There can be multiple schemes, but for now, I've selected only three to implement:
/DaemonLogScheme: For server-like applications that only interacts with user (except their normal operation) by sending events to log. Can be run just from console, but if it's available can sit down in systray/applettray and display popup notifications for important events.
/TreeInfo: Nodes are names or actions and leafs are texts. Can be used for many types of user-controlled applications: mail/news reader, service control (start/stop/configure), etc.
/ConfSeq: Configuration interface - usually is list of questions. On console will be printed one by one with user prompts, but in graphical environment (including web-access), will be displayed as wizard interface ss seen in many new installers.
So we have following major entities in library: environment in which application operates, interaction scheme that application utilize and backend that implements functionality of this scheme.
For each scheme there are several possible abilities that some backends implement and some not - i.e. ability to display colored lines not implemented by backend that writes to system log. Application can specify that it requires one list of abilities, wants another list and can use third list of optional abilities. MivMaz then will try to select backend that:
can operate in current environment.
have all required abilities
and have as much as possible wanted abilities
After selection application can use abilities specified in any of three lists, but for abilities not in required list it must check if it's available. For some abilities there are pre-defined implementation simplifications - i.e. if writing colored line is not supported it will write plain text.
First demo attached to library is webping program, that can check if web sites are up.
It uses /DaemonLogScheme.
- It needs ability to output log of lines of text.
If ability to receive stop signal is available it allows to specify -t option - run continuosly.
- If ability to display colored lines is available it does so.