On Sat 26 Jul 2003 08:53, Leon Brooks posted as excerpted below: > It updates the screen by sending X commands. If there are a lot of these > commands, X has to do a lot of work. Not noticeable except across (say) > an ADSL or slower link, when you're remotely administering. If you can > make a read-entry limit itself to flagging that a change has happened, > and then use a timer thread (sleep() signal, for example) to only fire > off an update max twice a second, this will cure it.
For slow links, perhaps a text based interface would be better. One of the advantages of the drake tools is that many of them have text based interfaces as well. I, for one, have missed this in menudrake. (I have no reason to do remote admin, but it would be handy to be able to run menudrake from the console outside of X.) Lately, however, I've been getting frustrated with menudrake anyway, as it is just to big and clunky to easily do the modifications I wanted. Rather, I read up on the menu documentation, and began copying the individual default menu entry files from /usr/lib/menu (the default location) to /etc/menu (the overrule location), then changing them there as necessary, then running the update-menus command from the console. Not only can this be DONE from console, but it's far easier than editing the individual item attributes one at a time, in an unresizable edit window with text boxes only about 10 char wide, FAR to small to see even an entire kde option, let alone the entire line one has to use because they are all crammed on a single line. (The same goes for long strings of mimetypes, as another example.) When I edit the indiividual files, I can make use of the line continuator to split a single entry onto multiple lines, as necessary, in addition to being able to see 100+ characters on one line rather than only a 10 char or whatever narrow edit window. Also, having the individual menu entries in individual files is far easier to handle than having the binary choice of system default menu vs customized menu, with customized menu being suddenly erased if one should make the mistake of switching to default to check out an entry there, and save that, with no option of reverting to the former customized menu! Of course, as I write this.. I realize I should be filing bug reports on these issues, instead of finding my own work arounds and leaving others to do the same. I guess someone has some work to do, and that someone would be me! <g> Anyway.. As I was saying, for remote work, try working with the individual text files and with update-menus, rather than the graphically intensive menudrake. -- Duncan - List replies preferred. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." Benjamin Franklin
