several defects and enhacement-wishes

samo samo at altern.org
Tue Oct 10 22:32:54 CEST 2006


> > 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...
>
> Enum or #define makes little difference if you screw it up by
> mistake like I did...
make it then one direct_name KEY_MOVE_1 + index [0..N_KEY_MOVE) where 
N_KEY_MOVE=12.. and use loops to generate all else.

> > 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.
>
> Sure, the thing is that the code was all right with a few
> shortcuts, but more and more are added and makes the thing messy
> now. Some day, it'll require cleanup.
i guess u know your own code best. start some file todo-long-term and 
put any such messy repeatable (infrastructural) items in this todo 
list. Otherwise it gets lost in comments/mails/... The keyboard 
shortcuts would make _one_ item. Others?
i know u don't like roadmaps etc, i don't like them either, but this 
is just a reminder to yourself/others... it can be even in some 
makefile or whatever...

> > oh, if u don't want me to comment about maintenability/quality of
> > code, bad-practices etc, just say so.
>
> I have no problem with criticism, but I definitely prefer well
> written patches.
hmm. i may send u a patch to remove the repeats (>60 times each):
event.c: grabKey (dpy, &screen_info->params->keys[KEY_WORKSPACE_1], 
screen_info->xroot);
settings.c:  parseKeyString (dpy, 
&screen_info->params->keys[KEY_TOGGLE_FULLSCREEN], getValue 
("fullscreen_key", rc));

of course, it will need some infrastructure first, so might be more 
than couple of lines - and require some non-cosmetic changes. 
Whether u want to touch all this right now, is completely another 
beast...

adieu
samo



More information about the Xfce mailing list