This page is for discussions with uncertain context or need for clarifications.
You can use the quoting syntax of dokuwiki, here is an example:
Propose a discussion about this and that.
First answer. End with a click on the Signature button or type Alt+Y (sometimes Alt+Shift+Y, depends on the browser).
Answer about the first answer.
Otherone who blablabla about the first answer.
Other answer.
Yet another.
Users can propose new HIGs, taken from their plugin, and if 50% of the panel plugins are using it, we can forward patches/ask devs on the goodies-dev mailing-list to follow the same HIG in their plugin.
There are several approches to save the data: on entry leave, button toggle, dialog close, …
most natural way is on “close” only, thus the ability to cancel by the window-close button remains and it is clear, when any changes are undertaken. — fabian 2007/12/18 22:54
I thought the idea was to do it when the plugin receives the save signal (http://mocha.xfce.org/documentation/api/libxfce4panel/XfcePanelPlugin.html#XfcePanelPlugin-save) — ongardie 2007/12/21 01:54
The “save” signal is appropriate. However I tend to believe saving when the dialog is closed would be a reasonable behavior if we were to reconsider that. — kalikiana 2007/12/22 18:12
I think it's safer to use the “save” signal alone. If the plugin is re-configured in such a way that crashes the plugin, it's very welcome to not have that configuration saved. The “save” signal will make sure the configuration is saved under normal circumstances, and using it alone makes sure the configuration is not saved in the exceptional case of a crash. — ongardie 2007/12/24 06:26
Very good point. Provided that most users won't alter their panel all day that seems to be the most sensible option. — kalikiana 2008/01/01 02:48
Distinguish between storing the config to the file and storing the user's entered values internally - this is what differs even more among plugins, just as mentioned above. — fabian 2008/01/03 21:59
Can you elaborate on this? — Mike Massonnet 2008/01/05 20:44
To get things a little moved in the HIG page I propose to clean it up and split it in two categories:
The mature HIGs don't have to be commented out, it must be a page easy to read where the information is the priority, the comments are to be kept out. It must only contain what a developper can be interested in when looking at what widget he might like to use.
The wannabe HIGs is a separate page with what developers are willing to add, it can be discussed, etc.