several defects and enhacement-wishes

[samo]

> You were so kind and ask for that feature soooo nicely that I
> couldn't resist and I have now added the feature in SVN. Of course,
> I count on you for translating the new strings added by this
> feature in the 46 languages within the following couple of days
> (oh, and no need to send the french translation, I took care of
> that myself). Yes, as you know, localization is part of usability,
> and since we are so bad at that, I have to count on people like you
> who are so knowledgeable.
no, you are not bad, you are just not systematic. not that it 
matters...
and i don't think insulting helps any-direction.

> > so u think it is ubuntu packaging making the troubles? mmmh. i
> > think it's something else.
> > i'll checkout svn-head next.
>
> If you are talking about Ctrl+Fn shortcuts to switch workspaces
> (sorry, I have to guess, because you "forgot" to properly
> characterize the problem as there are different ways to switch
> workspaces using the keyboard, and I searched our bugzilla database
> but could not find your relevant detailed bug report yet), then
> yes, it's a bug that has been fixed last Saturday (10/06) and yet
> to be included in Xubuntu package. I've created a Lauchpad report
> for that, it's #64918.
thank you for your effort.

i found it myself:
 - build xfwm4_4.3.99.1svn+r23289-0ubuntu1_i386.deb is broken
 - build xfwm4_4.3.99.1svn+r23137-0ubuntu1_i386.deb is ok
 - build 4.3.99.2 (revision 23328) compiled from from svn-head is ok

actualy, them keys are working, but sending/switching to workspace 
3+number; that is key1->ws1, key2->ws5, key3->ws6, ... and i have 
only 3 workspaces.

i've diff'ed the sources:
--- settings.h	(revision 23289)
+++ settings.h	(working copy)
@@ -82,43 +82,44 @@
-#define KEY_MOVE_WORKSPACE_10           23
-#define KEY_MOVE_WORKSPACE_11           24
-#define KEY_MOVE_WORKSPACE_12           25
-#define KEY_MOVE_WORKSPACE_2            26
-#define KEY_MOVE_WORKSPACE_3            27
-#define KEY_MOVE_WORKSPACE_4            28
-#define KEY_MOVE_WORKSPACE_5            29
-#define KEY_MOVE_WORKSPACE_6            30
-#define KEY_MOVE_WORKSPACE_7            31
-#define KEY_MOVE_WORKSPACE_8            32
-#define KEY_MOVE_WORKSPACE_9            33
+#define KEY_MOVE_WORKSPACE_2            23
+#define KEY_MOVE_WORKSPACE_3            24
+#define KEY_MOVE_WORKSPACE_4            25
+#define KEY_MOVE_WORKSPACE_5            26
+#define KEY_MOVE_WORKSPACE_6            27
+#define KEY_MOVE_WORKSPACE_7            28
+#define KEY_MOVE_WORKSPACE_8            29
+#define KEY_MOVE_WORKSPACE_9            30
+#define KEY_MOVE_WORKSPACE_10           31
+#define KEY_MOVE_WORKSPACE_11           32
+#define KEY_MOVE_WORKSPACE_12           33

you rely on ordering of these items - as in the handleKeyPress() 
switch(). Why not make them enum? And put a comment-warning about 
that order being important? i guess there are other similar ones..
Or just remove them as direct names, and always use key_1 + index...

Also, i noticed a lot of repeating things like: (for example)
...
 parseKeyString (dpy,&screen_info->params->keys[KEY_PREV_WORKSPACE], 
	getValue ("prev_workspace_key", rc));
 parseKeyString (dpy, &screen_info->params->keys[KEY_RAISE_WINDOW],
 	getValue ("raise_window_key", rc));
 parseKeyString (dpy, &screen_info->params->keys[KEY_RESIZE_DOWN],
	getValue ("resize_window_down_key", rc));
... 20 lines like these ...
Most xfwm keybrd management is like this.

These could go into a table (key-attributes) + a loop over it.
This would minimize maintenance issues - u'll have all them keys + 
their attributes in one table, and different loops/"methods" to do 
different things about them. Instead of having many copies of "same" 
list of keys doing slightly different (but repeating) things over and 
over and over.

oh, if u don't want me to comment about maintenability/quality of 
code, bad-practices etc, just say so.

==============
more defects/misbehaviour:
 - panel: something about saving the panel configuration is very 
wrong.
if panel is being killed, and then the session is restarted (no 
session saving), next time there is just empty panel - all it's 
config is gone: the panels.xml file is being freshly overwritten.
similar thing happens if one of the panel items got killed (e.g. 
killall xfce-weather, or SEGV or whatever). Next time it would not 
start at all - it is being removed from panels.xml. Seems someone 
always overwrites this file at eo-session.

 ~- desktop: rm -rf .cache will remove positions of desktop icons.

To me, any user preference should not be put in cache-like place nor  
overwritten / removed without user's will.

  - Desktop/*.desktop files: if u specify Enconding != UTF8, the item 
becomes un-editable and the reported-before misbehaviour.

 - mousepad: the yes-no-cancel dialog, appearing at closing, allows 
focusing on its label (e.g. using [tab]). dunno if this is a common 
dialog or just for mousepad.

ciao
samo