Better handling of <list> and <enum> in preferences dialog
The <list> and <enum> tags for the preferences dialog currently do not remember inline-script generated item lists. The problem seems to be that only there property "value" is stored. Thus, auxilary config store/restore inline-scripting is necessary to load and assign item lists after desklet reload or daemon restart. Furthermore, assigning values to the appropriate dom elements via inline-script doesn't seem to work as expected in some cases. A solution to both of these problems should be discussed and the latter 'repaired' as soon as possible.
Blueprint information
- Status:
- Started
- Approver:
- None
- Priority:
- Undefined
- Drafter:
- None
- Direction:
- Needs approval
- Assignee:
- Ronny Lorenz
- Definition:
- Discussion
- Series goal:
- None
- Implementation:
-
Beta Available
- Milestone target:
- None
- Started by
- Ronny Lorenz
- Completed by
Whiteboard
Regarding the lost item lists after reload/restart do we really want to take over the responsibility to restore the items lists? Or do we want to leave it a desklet developer issue? In my CircleMeter.display I circumvented this problem by creating a new config variable that survives reload/restart events and is used to create new item lists when needed.
Anyway, the other issue I want to debate is some weird behavior of those two preferences elements. In particular, when I assign new item lists or new selections to any of them via inline-script the function that notifies the preferences callback to kick in is called too often or when not needed in my opinion. If I use the current implementation of e.g. <enum> I sometimes end up in infinite loops of value assignment triggered from the callback system...
I therefore made some modifications in the files
config/
and
config/
which also include some new features:
Element <enum> :
- if a new item list is assigned to the .items property, the key for the selection in the previous item list is searched within the new list. In case it is still present in the new item list the selection will not change but trigger the preferences callback. Otherwise, the last element in the new list is selected. (could also be the first).
- if an empty item list is assigned to the .items propery the active element in the enmueration is set to -1 and a value of "" (empty string) is stored in the .value property.
- assigning a value to the .value property that does not represent a key from the stored item list results in deselection of the current item and a changed of .value to "" (empty string)
Element <list>:
- if a new item list is assigned to the .items property, all keys of all selected entries in the previous item list are searched within the new item list. If found the selections stay active in the new list.
- new selection patterns passed via the .value propery are filtered such that only known keys remain in the selection. Duplicates are also removed.
For the changes above I made a very simple desklet that does nothing but provides a preferences dialog with two pages for testing purposes. One page for an empty <enum> element, a string input used for naming the items in the items list and 4 buttons (add, remove, update item and reverse enum list). The second page has an empty <list> and a string input as well as 3 buttons (add, remove and reverse list).
Where can I put my diff and the test desklet such that the approval responsible people can check on my changes?
Comments on the afforementioned problems and features are welcome ;)
Link to patch files and the desklet:
http://
