blob: 99036008e472d530ce37df90e1b5d4fff0a82bad (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
|
> > We already have some functional backends, frontends, that works great, and has
> > not been thrown away since 1 year. We use it during install, post install, mcc
> > and so.
>
> But aren't generic enough.
DrakX handles:
- buttons
- bool values (checkboxes)
- ranges
- entries
- combo boxes (editable or not)
- lists / radio boxes
- tree lists
- iconlist
- wait messages
Features:
- all the entries above can be mixed
- nice separation between data and displayed data (eg: choose in list of
objects representing hda/hdb/... but displayed nicely with size...)
- keyboard handled nicely in GTK frontend
- callback on events:
ok pressed => check before the dialog is hidden
focus changed =>
* enables pre-setting things based on other entries
* value checking on the fly
- simple/advance toggle
- shadowing of entries
- tooltips
- size of windows computed the best possible
- perl-based
Misfeatures:
- display not flexible (though i don't know any of the tools we're talking
about that is flexible => nice)
- quite a few features are gtk only (simple/advance toggle, shadowing of
entries, certain events, tooltips).
- a stdio front-end exist but handle only certain entries. It would need a
week-work to finish it
- a http front-end could be done (mod-perl needed)
- perl-based
The DrakX frontend (called "interactive") could be moved out of DrakX.
eg of use:
<#part type="text/plain" filename="~/bin/perl/imessage" disposition=attachment>
<#/part>
[...]
> > -provides a lot of frontends
>
> And you ideally have to provide a frontend by widget set.
nope. The interface is completly standardised, even if it include some
gtk-like niceties. The *complete* newt (and not just entries and radioboxes
like bus) binding takes 241 lines.
|
