This is a first draft of how we'd like to deal with the user interface for events. Since every event can consist of many executables scripts, etc.. it's quite hard to provide an UI for it. So we decided that every event will have a XML file with this content:
- name - description of what this event does - description of every configurable option - option will have: attributes: - type: text, password, number (any others?) - name: name of the represented environment variable elements: - label: text to show in UI - empty: if the option can be empty (defaults to "no") - description a tooltip to show when move the mouse over the option widget... - others if you find anything anything else useful
example:
<name>Bugzilla</name> <description>Send the colelcted information to the Fedora bugzilla (you will need a bugzilla account to use this)</description> <options> <option type="text" name="bz_login"> <label>User name</label> <empty>no</empty> <description>Username to use to log into your bugzilla account</description> </option>
<option type="password" name="bz_password"> <label>Password</label> <empty>no</empty> <description>Password for your bugzilla account</description> </option> </options>
- these xml files will live in /usr/share/abrt/events/<EVENTS_NAME>.xml - the default values (like bz URL) for events will be stored in /etc/abrt/events/<EVENT_NAME>.conf - and can be also read from ~/.abrt/events/<EVENT_NAME>.conf - but not stored by any abrt application, this file will have to be provided by user if he don't want to use any of the options below: - gtk UI will store the settings in gnome-keyring - kde UI will store the settings in the kwallet - etc, ...
- and yes, the gui will be generated from these xml files, so let's hope we won't end-up with reimplementing the glade ;)
On 03/03/2011 05:47 PM, Jiri Moskovcak wrote:
This is a first draft of how we'd like to deal with the user interface for events. Since every event can consist of many executables scripts, etc.. it's quite hard to provide an UI for it. So we decided that every event will have a XML file with this content:
- name
- description of what this event does
- description of every configurable option
- option will have: attributes:
- type: text, password, number (any others?)
- name: name of the represented environment variable elements:
- label: text to show in UI
- empty: if the option can be empty (defaults to "no")
- description a tooltip to show when move the mouse over the option
widget... - others if you find anything anything else useful
example:
<name>Bugzilla</name> <description>Send the colelcted information to the Fedora bugzilla (you will need a bugzilla account to use this)</description>
<options> <option type="text" name="bz_login"> <label>User name</label> <empty>no</empty> <description>Username to use to log into your bugzilla account</description> </option>
<option type="password" name="bz_password"> <label>Password</label> <empty>no</empty> <description>Password for your bugzilla account</description> </option>
</options>
- these xml files will live in /usr/share/abrt/events/<EVENTS_NAME>.xml
- the default values (like bz URL) for events will be stored in
/etc/abrt/events/<EVENT_NAME>.conf
- and can be also read from ~/.abrt/events/<EVENT_NAME>.conf
- but not stored by any abrt application, this file will have to be
provided by user if he don't want to use any of the options below:
- gtk UI will store the settings in gnome-keyring
- kde UI will store the settings in the kwallet
- etc, ...
Crash-catcher mailing list Crash-catcher@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/crash-catcher
On 03/03/2011 05:50 PM, Jiri Moskovcak wrote:
- and yes, the gui will be generated from these xml files, so let's hope
we won't end-up with reimplementing the glade ;)
I like this. We do not need to reimplement glade, actually it is not about glade at all (qt, cli). If you need glade-specific stuff, you can always save it as <glade>...</glade>. What do we need is a set of basic characteristics you have mentioned: type, name, label etc. and these can be easily defined by XML (comparing to .conf files).
On 03/03/2011 05:47 PM, Jiri Moskovcak wrote:
This is a first draft of how we'd like to deal with the user interface for events. Since every event can consist of many executables scripts, etc.. it's quite hard to provide an UI for it. So we decided that every event will have a XML file with this content:
- name
- description of what this event does
- description of every configurable option
- option will have: attributes:
- type: text, password, number (any others?)
- name: name of the represented environment variable elements:
- label: text to show in UI
- empty: if the option can be empty (defaults to "no")
- description a tooltip to show when move the mouse over the option
widget... - others if you find anything anything else useful
example:
<name>Bugzilla</name> <description>Send the colelcted information to the Fedora bugzilla (you will need a bugzilla account to use this)</description>
<options> <option type="text" name="bz_login"> <label>User name</label> <empty>no</empty> <description>Username to use to log into your bugzilla account</description> </option>
<option type="password" name="bz_password"> <label>Password</label> <empty>no</empty> <description>Password for your bugzilla account</description> </option>
</options>
- these xml files will live in /usr/share/abrt/events/<EVENTS_NAME>.xml
- the default values (like bz URL) for events will be stored in
/etc/abrt/events/<EVENT_NAME>.conf
- and can be also read from ~/.abrt/events/<EVENT_NAME>.conf
- but not stored by any abrt application, this file will have to be
provided by user if he don't want to use any of the options below:
- gtk UI will store the settings in gnome-keyring
- kde UI will store the settings in the kwallet
- etc, ...
Crash-catcher mailing list Crash-catcher@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/crash-catcher
Crash-catcher mailing list Crash-catcher@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/crash-catcher
On Thu, 2011-03-03 at 17:47 +0100, Jiri Moskovcak wrote:
This is a first draft of how we'd like to deal with the user interface for events. Since every event can consist of many executables scripts, etc.. it's quite hard to provide an UI for it. So we decided that every event will have a XML file with this content:
- name
- description of what this event does
- description of every configurable option
- option will have: attributes:
- type: text, password, number (any others?)
- name: name of the represented environment variable elements:
- label: text to show in UI
- empty: if the option can be empty (defaults to "no")
Looks like we'll need more general mechanism to specify conditions. Examples:
0 =0
!=NULL ("this parameter is mandatory") !=""
- description a tooltip to show when move the mouse over the option
widget... - others if you find anything anything else useful
example:
<name>Bugzilla</name> <description>Send the colelcted information to the Fedora bugzilla (you will need a bugzilla account to use this)</description>
<options> <option type="text" name="bz_login"> <label>User name</label> <empty>no</empty> <description>Username to use to log into your bugzilla account</description> </option>
<option type="password" name="bz_password"> <label>Password</label> <empty>no</empty> <description>Password for your bugzilla account</description> </option> </options>
- these xml files will live in /usr/share/abrt/events/<EVENT_NAME>.xml
I would prefer /etc/abrt/events/<EVENT_NAME>.xml - that is, in the same directory where .conf file is.
For people who create new events, having to create/edit two files is bad enough, having them in two different directories is worse.
- the default values (like bz URL) for events will be stored in
/etc/abrt/events/<EVENT_NAME>.conf
- and can be also read from ~/.abrt/events/<EVENT_NAME>.conf
- but not stored by any abrt application, this file will have to be
provided by user if he don't want to use any of the options below:
- gtk UI will store the settings in gnome-keyring
- kde UI will store the settings in the kwallet
- etc, ...
On 03/04/2011 04:10 PM, Denys Vlasenko wrote:
On Thu, 2011-03-03 at 17:47 +0100, Jiri Moskovcak wrote:
This is a first draft of how we'd like to deal with the user interface for events. Since every event can consist of many executables scripts, etc.. it's quite hard to provide an UI for it. So we decided that every event will have a XML file with this content:
- name
- description of what this event does
- description of every configurable option
- option will have: attributes:
- type: text, password, number (any others?)
- name: name of the represented environment variable elements:
- label: text to show in UI
- empty: if the option can be empty (defaults to "no")
Looks like we'll need more general mechanism to specify conditions. Examples:
0 =0
!=NULL ("this parameter is mandatory") !=""
- yes, this version only cares about needed/not needed, the other checks like !=0, >0, !="", !=NULL, is valid email?, is valid URL? and so on... - what about a regexp? or is it too much to ask from event creator?
- description a tooltip to show when move the mouse over the option
widget... - others if you find anything anything else useful
example:
<name>Bugzilla</name> <description>Send the colelcted information to the Fedora bugzilla (you will need a bugzilla account to use this)</description>
<options> <option type="text" name="bz_login"> <label>User name</label> <empty>no</empty> <description>Username to use to log into your bugzilla account</description> </option>
<option type="password" name="bz_password"> <label>Password</label> <empty>no</empty> <description>Password for your bugzilla account</description> </option>
</options>
- these xml files will live in /usr/share/abrt/events/<EVENT_NAME>.xml
I would prefer /etc/abrt/events/<EVENT_NAME>.xml - that is, in the same directory where .conf file is.
For people who create new events, having to create/edit two files is bad enough, having them in two different directories is worse.
- we discuss this with Karel and our decision was based on the fact, that the xml file is not a config file, so it shouldn't be in /etc/
- the default values (like bz URL) for events will be stored in
/etc/abrt/events/<EVENT_NAME>.conf
- and can be also read from ~/.abrt/events/<EVENT_NAME>.conf
- but not stored by any abrt application, this file will have to be
provided by user if he don't want to use any of the options below:
- gtk UI will store the settings in gnome-keyring
- kde UI will store the settings in the kwallet
- etc, ...
On Fri, 2011-03-04 at 17:08 +0100, Jiri Moskovcak wrote:
- these xml files will live in /usr/share/abrt/events/<EVENT_NAME>.xml
I would prefer /etc/abrt/events/<EVENT_NAME>.xml - that is, in the same directory where .conf file is.
For people who create new events, having to create/edit two files is bad enough, having them in two different directories is worse.
- we discuss this with Karel and our decision was based on the fact,
that the xml file is not a config file, so it shouldn't be in /etc/
I am concerned about failing on the "do not make user's life miserable" metric. :D
Good news everyone! I have the first version of the xml-to-gui code and I'd like to hear your opinion, so please grab it here:
http://jmoskovc.fedorapeople.org/xml_to_gui.zip
unzip, make and run xml-to-gui and then please take a look at the code, I bet it has space for some improvements ;) It's not integrated into ABRT as I didn't want to deal with the rest while hacking with it, but it's my plan for today.
what does it do: - creates the dialog from the xml file
what needs to be done: - saving values - input checking (I have some ideas about this, but not really sure how good they are) - translation (but I know how to do it ;)) - anything else beyond displaying the dialog :)
Please review, Jirka
On 03/04/2011 05:51 PM, Denys Vlasenko wrote:
On Fri, 2011-03-04 at 17:08 +0100, Jiri Moskovcak wrote:
- these xml files will live in /usr/share/abrt/events/<EVENT_NAME>.xml
I would prefer /etc/abrt/events/<EVENT_NAME>.xml - that is, in the same directory where .conf file is.
For people who create new events, having to create/edit two files is bad enough, having them in two different directories is worse.
- we discuss this with Karel and our decision was based on the fact,
that the xml file is not a config file, so it shouldn't be in /etc/
I am concerned about failing on the "do not make user's life miserable" metric. :D
crash-catcher@lists.fedorahosted.org