From: Shaffer, C. <Chr...@be...> - 2003-06-24 18:22:26
|
I'm having a little trouble figuring out the event propagation of a button_press_event. I'm making a clock for my panel, and I wanted the Date to appear when I clicked on the Applet. Right now, the date displays in a ROX info box, which is fine for now. Here's my problem: I left click on the applet, I get my rox info box with the date. Great! But, if I right click, I get nothing. The right click is not being propagated passed my handler (I guess...). No right click means no method to close or move the applet. My code is attached below. Any idea how I can get the 'button-press-event' to propagate beyond my button_press() handler? Thanks, Chris Shaffer #!/usr/bin/env python import findrox import rox from rox import g, applet import sys import time def update_time(): current_time = time.strftime("%I:%M %p") time_display.set_markup("<big> " + current_time + " </big>") return 1 def button_press(window, event): if event.button == 1: rox.info(time.ctime()) return g.TRUE else: return g.FALSE time_display = g.Label('') update_time() main = applet.Applet(sys.argv[1]) main.add_events(g.gdk.BUTTON_PRESS_MASK) main.connect_after('button-press-event', button_press) main.add(time_display) main.show_all() g.timeout_add(1000, update_time) rox.mainloop() ***** "The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers." |
From: Geoff Y. <g...@in...> - 2003-06-24 22:18:48
|
On Tue, Jun 24, 2003 at 02:22:02PM -0400, Shaffer, Chris wrote: > I'm having a little trouble figuring out the event propagation of a > button_press_event. I'm making a clock for my panel, and I wanted the > Date to appear when I clicked on the Applet. Right now, the date > displays in a ROX info box, which is fine for now. Here's my problem: > I left click on the applet, I get my rox info box with the date. > Great! But, if I right click, I get nothing. The right click is not > being propagated passed my handler (I guess...). No right click means > no method to close or move the applet. My code is attached below. > Any idea how I can get the 'button-press-event' to propagate beyond my > button_press() handler? I'm not sure whether this is a defficiency in the XEMBED spec or in GTK's implementation of it, but there are two main caveats when writing applets: 1) Button press events don't get forwarded As soon as they try to capture button-press-events, the events are no longer forwarded to the Panel. This can be worked around by only catching button presses for part of your applet - e.g. create a vbox with a label and a button and only catch events for the button. Last time I checked, this allowed the panel to catch clicks aimed at the label, although it still won't catch any on the button. The forthcoming release of ROX-Rib (A library for writing ROX applets and applications in Ruby) has a workaround, albeit imperfect, whereby an applet can send button events to the panel, which allows the dragging and so on. It would possible to do the same in python, but you would either need a C extension or python bindings for XLib because I don't think there's any easy way to forward normal events between applications in GTK. It would be nice to be proved wrong thought :) 2) XDS When Xdnd meets XEmbed, a proxy is used - ie. the source_window and dest_windows are not the same windows for the source as they are for the destination. GTK (last tested with 2.2.1) doesn't seem to reflect changes to properties on the source window on the proxy's source window, so the mechanism used by XDS for sending filenames doesn't work. Other things which it is nice to do include: * If you provide a menu, ensure that you: 1) allow the user to choose which mouse button or 2) read the current ROX-Filer setting * Try to reflect whether the user has text under panel icons or not * Change the applet icon's state to PRELIGHT and back to NORMAL as the filer does on pointer entry and exit. * If you include a for the applet (ie. which takes the place of the filer's panel menu) include a Quit entry. * Include a suitable descriptive tooltip HTH, Geoff. |
From: Christopher S. <che...@ya...> - 2003-06-25 00:05:53
|
--- Geoff Youngs <g...@in...> wrote: > * Include a suitable descriptive tooltip > That's actually what I wanted in the first place. How do you do a tooltip over an applet? Chris Shaffer __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com |
From: Geoff Y. <g...@in...> - 2003-06-25 15:37:58
|
On Tue, Jun 24, 2003 at 05:05:43PM -0700, Christopher Shaffer wrote: > --- Geoff Youngs <g...@in...> wrote: > > * Include a suitable descriptive tooltip > That's actually what I wanted in the first place. How do you do a > tooltip over an applet? Use tips = g.Tooltips() to create a tooltips object. And then tips.set_tip(widget, text, unused_text) to set a tip for a given widget. The widget must be able to detect input events, so you would call the above passing the widget that you're checking for button press events on. Note that the tips object can be re-used - you don't need a new one for each tip. HTH, Geoff. |
From: Thomas L. <ta...@ec...> - 2003-06-25 12:37:45
|
On Tue, Jun 24, 2003 at 02:22:02PM -0400, Shaffer, Chris wrote: > Any idea how I can get the 'button-press-event' to propagate beyond my > button_press() handler? One thing we could support is using AppInfo.xml to specify which buttons the applet is interested in and have ROX-Filer take control of the others without needing the applet to forward them (XGrabButton). -- Thomas Leonard http://rox.sourceforge.net ta...@ec... ta...@us... GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 |
From: Thomas L. <ta...@ec...> - 2003-06-25 13:57:37
|
On Wed, Jun 25, 2003 at 01:31:56PM +0100, Thomas Leonard wrote: > On Tue, Jun 24, 2003 at 02:22:02PM -0400, Shaffer, Chris wrote: > > > Any idea how I can get the 'button-press-event' to propagate beyond my > > button_press() handler? > > One thing we could support is using AppInfo.xml to specify which buttons > the applet is interested in and have ROX-Filer take control of the others > without needing the applet to forward them (XGrabButton). I've made it grab button 2 whatever happens now, so at least you should be able to drag applets around. -- Thomas Leonard http://rox.sourceforge.net ta...@ec... ta...@us... GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 |
From: Geoff Y. <g...@in...> - 2003-06-25 16:01:21
|
On Wed, Jun 25, 2003 at 02:51:50PM +0100, Thomas Leonard wrote: > On Wed, Jun 25, 2003 at 01:31:56PM +0100, Thomas Leonard wrote: > > On Tue, Jun 24, 2003 at 02:22:02PM -0400, Shaffer, Chris wrote: > > > Any idea how I can get the 'button-press-event' to propagate > > > beyond my button_press() handler? > > One thing we could support is using AppInfo.xml to specify which > > buttons the applet is interested in and have ROX-Filer take control > > of the others without needing the applet to forward them > > (XGrabButton). > I've made it grab button 2 whatever happens now, so at least you > should be able to drag applets around. The changes aren't visible in anonymous CVS yet (which seems to be a sf.net problem), but I hope that you mean "which ever button isn't configured to display the menu" :) Any thoughts on the XDS issue that I outlined in my previous post? I was vaguely thinking about an applet which allows files to be saved to it - a partial implementation could be managed relying on the application/octet-stream target, but it would only for normal files. Thanks, Geoff. |
From: Thomas L. <ta...@ec...> - 2003-06-25 16:20:58
|
On Wed, Jun 25, 2003 at 05:15:46PM +0100, Geoff Youngs wrote: > On Wed, Jun 25, 2003 at 02:51:50PM +0100, Thomas Leonard wrote: > > On Wed, Jun 25, 2003 at 01:31:56PM +0100, Thomas Leonard wrote: > > > On Tue, Jun 24, 2003 at 02:22:02PM -0400, Shaffer, Chris wrote: > > > > > Any idea how I can get the 'button-press-event' to propagate > > > > beyond my button_press() handler? > > > > One thing we could support is using AppInfo.xml to specify which > > > buttons the applet is interested in and have ROX-Filer take control > > > of the others without needing the applet to forward them > > > (XGrabButton). > > > I've made it grab button 2 whatever happens now, so at least you > > should be able to drag applets around. > > The changes aren't visible in anonymous CVS yet (which seems to be a > sf.net problem), but I hope that you mean "which ever button isn't > configured to display the menu" :) I'm wondering if we can get rid of that, actually. Swapping buttons 2 and 3 for all applications will get you a context menu on button-2 everywhere, whereas the current option only affects the filer. > Any thoughts on the XDS issue that I outlined in my previous post? I > was vaguely thinking about an applet which allows files to be saved to > it - a partial implementation could be managed relying on the > application/octet-stream target, but it would only for normal files. I'm not quite sure what the problem is. Dragging a file to an applet works fine here. Dragging a directory from a filer window will work... is there a problem dragging a directory from an application (eg, Archive -> Applet)? I haven't tried that. Passing a default name (eg 'TextFile') does seem to have stopped working somewhere though. I'll investigate... -- Thomas Leonard http://rox.sourceforge.net ta...@ec... ta...@us... GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 |
From: Geoff Y. <g...@in...> - 2003-06-26 10:53:26
|
On Wed, Jun 25, 2003 at 05:15:09PM +0100, Thomas Leonard wrote: > On Wed, Jun 25, 2003 at 05:15:46PM +0100, Geoff Youngs wrote: > > On Wed, Jun 25, 2003 at 02:51:50PM +0100, Thomas Leonard wrote: > > > On Wed, Jun 25, 2003 at 01:31:56PM +0100, Thomas Leonard wrote: > > > > On Tue, Jun 24, 2003 at 02:22:02PM -0400, Shaffer, Chris wrote: > > > > > Any idea how I can get the 'button-press-event' to propagate > > > > > beyond my button_press() handler? > > > > One thing we could support is using AppInfo.xml to specify which > > > > buttons the applet is interested in and have ROX-Filer take control > > > > of the others without needing the applet to forward them > > > > (XGrabButton). > > > I've made it grab button 2 whatever happens now, so at least you > > > should be able to drag applets around. > > The changes aren't visible in anonymous CVS yet (which seems to be a > > sf.net problem), but I hope that you mean "which ever button isn't > > configured to display the menu" :) > I'm wondering if we can get rid of that, actually. Swapping buttons 2 and > 3 for all applications will get you a context menu on button-2 everywhere, > whereas the current option only affects the filer. :( I wouldn't want to swap the buttons for everything - I still like being able to insert the current selection at the cursor using middle button etc, but I also prefer the context menu on button 2 in apps which were written to use context menus in a RISC OSy way. > > Any thoughts on the XDS issue that I outlined in my previous post? I > > was vaguely thinking about an applet which allows files to be saved to > > it - a partial implementation could be managed relying on the > > application/octet-stream target, but it would only for normal files. > I'm not quite sure what the problem is. Dragging a file to an applet works > fine here. Dragging a directory from a filer window will work... is there > a problem dragging a directory from an application (eg, Archive -> > Applet)? I haven't tried that. It is the latter - XDND works normally (The text/uri-list data is transferred using a selection, which still works fine), but XDS doesn't because it relies on both apps having read/write access the XdndDirectSave0 property on the drag source window which is then altered by the target to contain the target filename. When a proxy is used (ie. XEMBED), the default filename is set as a property on the real source window, but this not reflected on proxy source window and hence the filename negotiation fails (transparently, I think, because the XDS source sets the value of the property to the default filename prior to the drag and then reads it back in again after the drag appears to succeed). I see no reason why the invisible window which GTK creates as a proxy couldn't detect property change events on the proxy source window and reflect those on the real source window by listening to the 'property-notify-event' signal, but knowing which properties to copy from the real source window to the proxy source window is considerably harder. > Passing a default name (eg 'TextFile') does seem to have stopped working > somewhere though. I'll investigate... I'm not quite sure what you mean - using the saver's preferred leafname seems to work OK: the problem outlined above is to do with the save target responding with a pathname. TTFN, Geoff. |
From: Thomas L. <ta...@ec...> - 2003-06-26 13:52:10
|
On Wed, Jun 25, 2003 at 11:32:07PM +0100, Geoff Youngs wrote: > On Wed, Jun 25, 2003 at 05:15:09PM +0100, Thomas Leonard wrote: [...] > > I'm not quite sure what the problem is. Dragging a file to an applet works > > fine here. Dragging a directory from a filer window will work... is there > > a problem dragging a directory from an application (eg, Archive -> > > Applet)? I haven't tried that. > > It is the latter - XDND works normally (The text/uri-list data is > transferred using a selection, which still works fine), but XDS doesn't > because it relies on both apps having read/write access the > XdndDirectSave0 property on the drag source window which is then altered > by the target to contain the target filename. > > When a proxy is used (ie. XEMBED), the default filename is set as a > property on the real source window, but this not reflected on proxy > source window and hence the filename negotiation fails (transparently, I > think, because the XDS source sets the value of the property to the > default filename prior to the drag and then reads it back in again after > the drag appears to succeed). OK, I see it now. ROX-Lib wasn't implementing reading the suggested leafname at all, but now I have implemented it, I see it doesn't work for panel applets. > I see no reason why the invisible window which GTK creates as a proxy > couldn't detect property change events on the proxy source window and > reflect those on the real source window by listening to the > 'property-notify-event' signal, but knowing which properties to copy > from the real source window to the proxy source window is considerably > harder. Could you open bug report with GTK? Just copying that property should be enough... Thanks, -- Thomas Leonard http://rox.sourceforge.net ta...@ec... ta...@us... GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 |
From: Thomas L. <ta...@ec...> - 2003-06-27 12:03:51
|
On Wed, Jun 25, 2003 at 11:32:07PM +0100, Geoff Youngs wrote: > On Wed, Jun 25, 2003 at 05:15:09PM +0100, Thomas Leonard wrote: [...] > > I'm wondering if we can get rid of that, actually. Swapping buttons 2 and > > 3 for all applications will get you a context menu on button-2 everywhere, > > whereas the current option only affects the filer. > > :( I wouldn't want to swap the buttons for everything - I still like > being able to insert the current selection at the cursor using middle > button etc, but I also prefer the context menu on button 2 in apps which > were written to use context menus in a RISC OSy way. What about applications like gnome-terminal and konsole, which use a single popup menu (unless you also turn the menubar on) AND support paste? Also, only ROX-Filer has ever supported this; even the ROX pager applet uses button-3 for menus. And the pinboard has to use button-3 for menus, because button-2 is for the window manager, so we're not even consistant within ROX-Filer. I've removed the option, but left the code in bind.c. Change 'menu_button = 3' to 'menu_button = 2' if you really need the old behaviour. Of course, 'xmodmap' can place all context menus on button-2 still. Hopefully this won't annoy too many people... -- Thomas Leonard http://rox.sourceforge.net ta...@ec... ta...@us... GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 |
From: Vincent L. <vi...@vi...> - 2003-06-27 15:09:06
|
On Fri, Jun 27, 2003 at 12:57:44 +0100, Thomas Leonard wrote: > On Wed, Jun 25, 2003 at 11:32:07PM +0100, Geoff Youngs wrote: > > :( I wouldn't want to swap the buttons for everything - I still like > > being able to insert the current selection at the cursor using middle > > button etc, but I also prefer the context menu on button 2 in apps > > which were written to use context menus in a RISC OSy way. Me too. > What about applications like gnome-terminal and konsole, which use a > single popup menu (unless you also turn the menubar on) AND support > paste? I don't use these applications, so I'm not concerned. :) A modifier key (e.g. Ctrl) could be used for one of these two operations (the less common one). IMHO, such choices should be left to the user. For instance, the user may want to have selection + adjust selection + paste without a modifier key (like in xterm). The user may find that paste with button 2 is too dangerous and may prefer a popup menu instead, and this may depend on the application (pasting in a text editor is potentially less dangerous than pasting in an xterm running a shell). Moreover, a popup menu may define several paste operations (e.g. a "clear current text and paste" would be useful in several contexts). > Also, only ROX-Filer has ever supported this; even the ROX pager > applet uses button-3 for menus. This should be configurable. > And the pinboard has to use button-3 for menus, because button-2 is > for the window manager, so we're not even consistant within > ROX-Filer. Button 2 is still used for a popup menu, so this is consistant. But this should be configurable (fvwm2 uses the 3 buttons). > I've removed the option, but left the code in bind.c. Change > 'menu_button = 3' to 'menu_button = 2' if you really need the old > behaviour. Hard-coding values is a bad programming practice. You should define a context-menu function and have a way to bind keys or menu buttons (or whatever peripheral is used) to such functions. > Of course, 'xmodmap' can place all context menus on button-2 still. Not without affecting other applications such as xterm or emacs. -- Vincent Lefèvre <vi...@vi...> - Web: <http://www.vinc17.org/> - 100% validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International des Jeux Mathématiques et Logiques, TETRHEX, etc. Work: CR INRIA - computer arithmetic / SPACES project at LORIA |