Re: Questions about Widgets in X window and XMoveResizeWindow
Cópia dd jj [EMAIL PROTECTED]: Hello everyone, Hi, I hope this is the correct mailing list to post these questions... Could you please give some comments on them? thanks. 1) Now I want to search a button with specific caption, such as Save or Cancel.. Ok on X window (no matter GNOME or KDE) screen. Can I implement this under different desktop enviroments(KDE,GNOME) with Xlib programming? Or it's toally impossible? I think there is no standard way of doing it. And, frequently buttons are not even separate windows. Probably in most cases it is only possible to retrieve this kind of information from the same program; Xt based toolkits can use the XEditRes protocol, see the editres program. As my understanding, The button in Gnome is built using GTK but that in KDE is built using Qt, they are different widgets belong to differen Toolkit, right? But since GTK and Qt are both based on Xlib, I am wondering whether we can handle this using lowest level Programming - xlib? You can use Xlib in both toolkits, assuming your program is only mean't to run under X, but you cannot expect reliable behaviour depending on the Xlib functions you call. Or maybe I can only program using GTK for GNOME, using Qt for KDE separately for different desktop enviroment? You can use any toolkit uder any desktop. 2) I tried to use XMoveResizeWindow to move a X window application such as Xclock, or Xcalc, I parsed the window ID w got from xwininfo and display dsp = XOpenDisplay(NULL) to it like: XMoveResizeWindow(dsp, w, 0, 0, 200, 200); it doesn't work, but when I creat my own window application using XCreateSimpleWindow, then it can work. Seems the display parameter is different every time when implement: dsp = XOpenDispaly(ULL) ? Did I miss something to deal with such existing Application window? Did your program enter an event loop? It is a common mistake to send X requests, but the program exit before they are processed. Normally calling XSync or XFlush before exiting is enough. Thank you for help me out. - Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software You can see some low level information on toolkits and programming with Xlib in the famous Kenton Lee site: http://www.rahul.net/kenton/xsites.framed.html There you can also find some tutorials on X programming. Paulo ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [XFree86] [BUG] The /*-+ keys on the numeric keypad won't repeat in current CVS
Quoting Ivan Pascal [EMAIL PROTECTED]: % setxkbmap -model pc104 -layout us_intl or % setxkbmap -model abnt2 -layout br = Scroll_Lock leds works They are 'old layouts'. % setxkbmap -model pc104 -layout us or % setxkbmap -model pc104 -layout pt = Scroll_Lock leds dont work They are new ones. The thing is new layouts have three-four levels and need a modifier bit for switching to those levels. But all real modifiers are already used: Lock, Shift, Control - according their names, and unnamed ones (Mod1-Mod5) are Alt, Meta, NumLock, ScrollLock and one for a Mode_Switch emulation for compatibility with the core protocol. Thus for the new ThirdLevel modifier I had to sacrifice one of them. The ScrollLock modifier seems me most unused and now this bit is used as the ThirdLevel modifier (of course the ScrollLock key still prodice a corresponded keysym). But the ScrollLock indicator still configured to show state of modifier bound to the ScrollLock keysym. I think if complaints will come I'll make an option that maps the ScrollLock virtual modifier to some real one. Otherwise we can use the indicator for something else. I think there won't be too many complaints about the ScrollLock leds not working. I am just not sure if there aren't programs that rely on ScrollLock working as before. For safety, I believe a xkb option for that case would be a good idea. BTW, I just tested the changes for MouseKeys, it is now working properly, thanks Ivan. -- Ivan U. Pascal | e-mail: [EMAIL PROTECTED] Administrator of | Tomsk State University University Network | Tomsk, Russia Paulo ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [XFree86] [BUG] The /*-+ keys on the numeric keypad won't repeat in current CVS
Quoting Ivan Pascal [EMAIL PROTECTED]: Hi, A short introduction: Any key in XKB can have keysyms, xkb actions, a virtual modifier(s) and some flags describing a key behavior such as 'repeat', 'locking' and so on. A core protocol knows about keysyms only. If one changes a keysym binding using the core protocol it can happen that the keysyms only will be moved but not actions or behavior flags. To solve this compatibility problem the XKB has a special 'compatibility map' which sets a relation between keysyms and other attributes a key can have. Thus when some keysym place in the keyboard map is changed the XKB searches this keysym in the compatibility map and if the keysym is found there it also moves an action and flags to the key. The same procedure the XKB does after any keyboard map loading (even it made by an XKB protocol). Therefore although an action of key can be specified in the symbols map directly it is a common way to tie the action to some special keysym in the compatibility map (xkb/compat/* files) and specify that keysym in the symbols map. Also each key has 'protection flags' which can protect the key from such changes. These flags are - 'forbid all changes' (include an action, a virtual modifier and other flags) - 'forbid a repeat flag change' - 'forbid a lock flag change' - 'forbid a modifier change' All written above you can read in XKBproto or XKBlib documentation. But you can't find there when and how those protection flags are set. The xkbcomp program does it using rules: - if any action for some key is specified directly in the symbols file the 'forbid all changes' flag should be set for this key - if a repeat flag is specified there the 'forbid a repeat flag change' bit should be set. - and similar rules for a locking flag and a virtual modifier. Now you can guess what happened with 'mouse actions'. Since new special actions were specified directly in the symbols map the xkbcomp set the protection flags for the corresponded keys and the 'mouse actions' which are tied to keysyms in the compatibility map now can't be bound to those keys. A disappearing of autorepeat isn't so clear but caused by the same reason. There are some details in an XKB design (I consider them as bugs) which lead to it. All keys initialy have not an autorepeat mark unless it explicitly specified in the symbols map (you know there are not such explicit spcifications in existent maps). The XKB sets these marks (bits) after a new map loading but does it for each key separately after attempt to apply a compatibility map ( of course if the key has not any keysyms mentioned in that map the autorepeat mark will be set unconditionaly). Thus if the key has the protection flag the XKB interrapts compatibility map applaying for this key and 'forgets' to set autorepeat but to the key. Thus you see the autorepeat losing is rather a bug and can be fixed (we need to make all keys marked as repeating initialy or to place the procedure which sets those marks before the protection bits checking). But disappearing of the 'mouse actions' is a feature of the XKB and can't be avoided without some redesign of XKB. Therefore a solution for the second problem is to 'make all actions equal in their rights'. It means - specify the mouse actions (and the repeat flag) in the same place where the 'special actions' are (e.g. in the symbols map) - or move the special action to the compatibility map. In the second case we need to introduce some new keysyms (something like xf86_Next_VMode, xf86_Prev_Mode, xf86_Ungrab, etc.). But we even don't need to add them to the keysymdef.h file but can use the lib/X11/XKeysymDB file instead. I have tested both solutions and it works in both cases. And I can make a patch quickly. But we have to chose one. As for me I prefer the second one becouse it is the way used for all other xkb actions. Any suggestions? Thanks for the explanation Ivan. I think creating a compatibility map seens the more sensate solution. I am just not sure what is the more robust/easy to maintain/predictable solution, but my instincts says it is the second option :-) Err, I think is just found another problem, forgive me if it is a known problem (and I missed some email about it), but for example: % setxkbmap -model pc104 -layout us_intl or % setxkbmap -model abnt2 -layout br = Scroll_Lock leds works % setxkbmap -model pc104 -layout us or % setxkbmap -model pc104 -layout pt = Scroll_Lock leds dont work These are the settings I normally use, Scroll_Lock is of no use for me under X, but this maybe be a problem. -- Ivan U. Pascal | e-mail: [EMAIL PROTECTED] Administrator of | Tomsk State University University Network | Tomsk, Russia ___ Devel mailing list [EMAIL PROTECTED]
Re: [XFree86] [BUG] The /*-+ keys on the numeric keypad won't repeat in current CVS
Quoting Ivan Pascal [EMAIL PROTECTED]: 'xset r keycode' works. I think there is another problem, MouseKeys also stoped working, the default bindings to select buttons don't work anymore: / - select button1 * - select button2 - - select button3 + - double click Both problems are side-effects of an adding 'special key sequences' such as Ctrl+Alt+Keypad +, Ctrl+Alt+Keypad -, etc. (You see only keys that have a special action are affected.) Tommorow I will write an explaination and will try to offer a workaround for both problems. Thanks. My understanding of xkb isn't very good, but, could the new special key sequences be implemented as MouseKeys, i.e. as the descriptions in xkb/compat? (but always enabled). -- Ivan U. Pascal | e-mail: [EMAIL PROTECTED] Administrator of | Tomsk State University University Network | Tomsk, Russia Paulo ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [XFree86] [BUG] The /*-+ keys on the numeric keypad won't repeat in current CVS
Quoting David Dawes [EMAIL PROTECTED]: On Mon, Feb 03, 2003 at 12:02:47PM -0500, Mike A. Harris wrote: /*-+ on the numeric keypad won't repeat in current CVS. Other keys on the keypad do repeat, including numbers when numlock is turned on. /*-+ on the normal part of the keyboard do repeat. Tried xset r on with no change. 'xset r keycode' works. I don't know why these keys don't repeat (and don't remember if they did before). I think there is another problem, MouseKeys also stoped working, the default bindings to select buttons don't work anymore: / - select button1 * - select button2 - - select button3 + - double click setxkbmap -print | xkbcomp -w 10 - :0 seens to show the possible problems. Keypad numbers are repeating, and mouse keys also working for the numeric bindings. David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel Paulo ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
A simple Xcursor theme for core cursors
Hi, I built a set of the core cursors (only size 16), for testing, it is available at http://www.conectiva.com.br/~pcpa/xcursor.tar.gz To build/test/install: $ tar zxvf xcursor.tar.gz $ cd xcursor == for sh $ for f in *.cfg; do xcursorgen $f `echo $f | sed -e 's@.cfg@@'`; done == for csh % foreach f (*.cfg) xcursorgen $f `echo $f | sed -e 's@.cfg@@'` end $ rm -f *.png *.cfg as root: # mkdir -p /usr/X11R6/lib/X11/icons/cursors/core # cp -f * /usr/X11R6/lib/X11/icons/cursors/core after that just test any app, example: == for sh $ (XCURSOR_THEME=core xedit) == for csh % (setenv XCURSOR_THEME core; xedit) If you want it as a default cursor theme, you can edit $HOME/.Xdefaults and add the line: Xcursor.theme:core This is a very simple theme, the cursors have very little transparency and the shadows are almost invisible when the cursor is over dark backgrounds. Well, this theme was created just for testing, after doing this, I was thinking that probably the best way to create cursor themes should be something like: 1) Draw the cursors in a vetorial drawing program. Try to use only lines in multiples of 45 degrees, and keep it simple. 2) Convert it to a pixmap, a good bet is 96x96, and lines with width 8, than it should be required little retouch when scaling it to create the 12, 16, 24, 32 and 48 sizes. These are just my ideas, I am very bad at gimp..., I don't think I will create some real artwork theme :-) Note that I am not proposing it to be the XFree86 4.3.0 default theme, as I said earlier, I did it only for testing. I would prefer redglass as the default for XFree86 4.3.0, at least for me, it is very good... Paulo ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
