Re: [e-users] Fast mouse scrolling problem
On Sat, 15 Oct 2005 14:45:02 +0900, Carsten Haitzler (The Rasterman) [EMAIL PROTECTED] wrote: On Mon, 26 Sep 2005 22:35:01 -0400 Dennis [EMAIL PROTECTED] babbled: On Sat, Oct 23, 2004 at 10:53:42AM -0400, Dennis wrote: On 10/23/04 04:03, Kim Woelders wrote: Dennis wrote: The problem (scrolling too fast freezes the scrolling for a few secs) only exists when i have Clicking in a window always raises it enabled. Although, i can still use my keyboard to scroll, during the freeze. My mouse also gets confined to the stuttering window. Also, when click-to-raise is enabled, I get different xev events. Not sure if they help. With click-to-raise E intercepts every button press and passes it on to the application. If E is busy doing something else (I doubt that is the problem), E isn't sheduled in, or the button press event delivery to E is somehow delayed you'll have that problem. I would guess that something might be wrong with the button-press event queue in E. (since the problem does not appear in other WM's (ie. fvwm) .. and i assume both receive the same X input). Here are two different test cases (of the scrolling problem, with click-to-raise). xterm - the scrolling problem cannot be remedied by any single keystroke that i know of .. however, i did discover that holding down alt-tab, the delays are eliminated firefox - the scrolling delays can be eliminated by single keystrokes .. such as an arrow key, or any other, i think the bug _still_ persists =|. i'm wondering why more people don't complain about this bug. perhaps click-to-raise isn't a popular option? or, more likely, there is something more peculiar about my setup. in any case, are there any new insights as to why this might be occurring .. in particular, why is it that mixing in a few keystrokes amid the button presses (mouse scrolling) fixes the problem? also, it seems that it is the scrolling caused by my mouse that is the source of the problem .. and not the scrolling caused by the scroll wheel on my keyboard, even though they produce the same button-press events. i have a usb logitech internet navigator keyboard (which is actually a usb hub with a keyboard and 'mouse' (scroll wheel)), and a usb logitech optical wheel mouse. how is it that the same event can cause a delay if it comes from the mouse, and no problem if it comes from the keyboard(hub)? just to check... get xev out - and scrollwheel on xev - do 1 click of the wheel and see how many button down events u get with the mouse, and then the keyboard scroller wheel :) they both seem to produce the same output in xev, both mouse scrollwheel and keyboard scrollwheel, both during regular scrolling and stuttered scrolling. the only difference being the abnormal time delays between events. [if you meant actual clicking, clicking the mouse wheel (button 2) produces a normal single button press, while the pressing the keyboard scrollwheel is not recognized.] --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] Fast mouse scrolling problem
On Mon, 17 Oct 2005 10:01:49 +0900, Carsten Haitzler (The Rasterman) [EMAIL PROTECTED] wrote: ... they both seem to produce the same output in xev, both mouse scrollwheel and keyboard scrollwheel, both during regular scrolling and stuttered scrolling. the only difference being the abnormal time delays between events. that's bizarre. i know of no reason why e would delay differently to the same event - as it sees it it gets the same x input for the button (is this the case? does the keyboard wheel generate button press 4, button release 4 / button press 5, button release 5)? if e is getting the same event - it will respond in the same way. can you include some output of xev (when not runing in e17 or disable click to raise or click to focus) for the 2 wheels so i can compare them? (letting me know which is which) ? By the way, i'm using enlightenment-0.16.7.2 =\ The problem is application dependent; it is more apparent in some applications (firefox), than in others (sylpheed, xterm). When clicking in a window always raises it is disabled, although the scrolling doesn't stall as badly (nor is it the mouse confined to the stalling window), there is still a noticeable difference between the two scrolling; mouse-scrolling is less responsive than keyboard scrolling. ie, there is a slight delay after mouse scrolling, whereas keyboard scrolling is more real-time. also, when there is an overlapping window, mouse-scrolling produces a discrepancy in rendering the overlapped area during scrolling - the part that was overlapped isn't aligned to the remainder of the page (i'm testing with firefox). with keyboard scrolling, there is no noticeable discrepancy. xev outputs are the same for mouse and keyboard scrolling. xev when click-raising is disabled: ButtonPress event, serial 27, synthetic NO, window 0x121, root 0x40, subw 0x0, time 14541910, (111,75), root:(156,825), state 0x0, button 5, same_screen YES ButtonRelease event, serial 27, synthetic NO, window 0x121, root 0x40, subw 0x0, time 14541910, (111,75), root:(156,825), state 0x1000, button 5, same_screen YES xev when click-raising is enabled: EnterNotify event, serial 27, synthetic NO, window 0x121, root 0x40, subw 0x0, time 15276423, (130,75), root:(198,914), mode NotifyUngrab, detail NotifyAncestor, same_screen YES, focus YES, state 4096 KeymapNotify event, serial 27, synthetic NO, window 0x0, keys: 64 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ButtonPress event, serial 27, synthetic NO, window 0x121, root 0x40, subw 0x0, time 15276423, (130,75), root:(198,914), state 0x0, button 5, same_screen YES ButtonRelease event, serial 27, synthetic NO, window 0x121, root 0x40, subw 0x0, time 15276423, (130,75), root:(198,914), state 0x1000, button 5, same_screen YES LeaveNotify event, serial 27, synthetic NO, window 0x121, root 0x40, subw 0x0, time 15276623, (130,75), root:(198,914), mode NotifyGrab, detail NotifyAncestor, same_screen YES, focus YES, state 2048 also, remember, during the scrolling stalls, pressing buttons on the keyboard fixes it. this i find very odd. also, remember, slow scrolling doesn't appear to have a problem. by the way, the stalled scrolling does not consume much of the cpu. hmm, and finally, i just discovered that the stalling only seems to occur if the window has focus. hmm. --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] Fast mouse scrolling problem
On Mon, 17 Oct 2005 11:30:36 -0400, Dennis Nezic [EMAIL PROTECTED] wrote: hmm, and finally, i just discovered that the stalling only seems to occur if the window has focus. hmm. also, if focus follows mouse clicks instead of pointer, the stalling no longer occurs. --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] keybindings sometimes don't work bug?
On Tue, 18 Oct 2005 09:07:50 +0900, Carsten Haitzler (The Rasterman) [EMAIL PROTECTED] wrote: ... let me guess - it only happens when NO app window is focused (there are no apps on the screen or none has the focus) ? i also have this bug with my 2-day old (e16.8) cvs. and, indeed, it _only_ happens when no windows have focus. it also has something to do with focus-follows-pointer, because the problem does not occur if it follows clicks. focus-follows-clicks automatically does something with the focus when a window is closed (even if it's the last window) .. so i would compare how focus changes in those two scenarios. interestingly, although the bug does occur with most apps, it doesn't with x-applications (xterm, xfontsel, etc)!? also, the bug only seems to occur if my pointer was over the window when i closed it. for example, if i open a window, and my mouse isn't over it (it will get focus, since i have all new windows get focus), and then i close it, although no window gets focus, the bug doesn't occur. also, probably on a related issue, with focus-follows-pointer, if my mouse isn't over a window, i can't alt-tab to it =\. e will switch to it momentarily, raise it, but then return focus to whatever is under the mouse. --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
[e-users] e16 pager size location in different display mode
with my current e16.8 (current to 2006/01/24), when i startx using a non-native resolution (native being 1280x800 ... problem case being 640x480, for example), the pager window gets resized (enlarged) a bit (320x48 to 352x56, for example), and moved a bit (up one pixel [0,609] to [0,608], for example) ... and thus the bottom few pixels of it are cut off. it's very annoying because i keep on having to resize and remove it to my desired size/height. normally loading x/e in native resolution works fine, and e doesn't crazily decide to fiddle with the pager settings. arrgh. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] e16.8.2 is using nearly 100% of my cpu.
i remember having a similar problem a while ago when i upgraded my e16... and, if i remember correctly, i fixed it by deleting my ~/.e16 folder, and reconfiguring e =\. (i had my menus backed up) On Fri, 10 Feb 2006 18:26:40 +0100, sam [EMAIL PROTECTED] wrote: hi, I'm using gentoo and e16.8.2 my problem is, that e16 uses nearly 100% of my cpu and I don't know why. I've disabled everything in the configs, that could possibly suck, but it didn't help. if you've got the same problem or even better solutions for my problem, i would be very thankfull if you write back. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] e16 pager size location in different display mode
On Sun, 12 Feb 2006 11:55:49 +0100, Kim Woelders [EMAIL PROTECTED] wrote: Kim Woelders wrote: Dennis Nezic wrote: with my current e16.8 (current to 2006/01/24), when i startx using a non-native resolution (native being 1280x800 ... problem case being 640x480, for example), the pager window gets resized (enlarged) a bit (320x48 to 352x56, for example), and moved a bit (up one pixel [0,609] to [0,608], for example) ... and thus the bottom few pixels of it are cut off. it's very annoying because i keep on having to resize and remove it to my desired size/height. normally loading x/e in native resolution works fine, and e doesn't crazily decide to fiddle with the pager settings. arrgh. Yeah, that's an old bug triggered by the screen resolution aspect ratio change. I'll try to get that sorted out before too long. I think this is fixed in CVS now. woohoo! works like a charm. i could kiss you. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] e16 pager size location in different display mode
On Sun, 12 Feb 2006 20:07:34 -0500, Dennis Nezic [EMAIL PROTECTED] wrote: On Sun, 12 Feb 2006 11:55:49 +0100, Kim Woelders [EMAIL PROTECTED] wrote: Kim Woelders wrote: Dennis Nezic wrote: with my current e16.8 (current to 2006/01/24), when i startx using a non-native resolution (native being 1280x800 ... problem case being 640x480, for example), the pager window gets resized (enlarged) a bit (320x48 to 352x56, for example), and moved a bit (up one pixel [0,609] to [0,608], for example) ... and thus the bottom few pixels of it are cut off. it's very annoying because i keep on having to resize and remove it to my desired size/height. normally loading x/e in native resolution works fine, and e doesn't crazily decide to fiddle with the pager settings. arrgh. Yeah, that's an old bug triggered by the screen resolution aspect ratio change. I'll try to get that sorted out before too long. I think this is fixed in CVS now. woohoo! works like a charm. i may have spoken too soon. although it does work when i start e under a non-native resolution (but same aspect ratio), (it didn't work before, so something was fixed :) the same problem occurs when i use tv-out, which has a different aspect ratio. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] e16 pager size location in different display mode
On Tue, 14 Feb 2006 19:26:29 +0100, Kim Woelders [EMAIL PROTECTED] wrote: Dennis Nezic wrote: i may have spoken too soon. although it does work when i start e under a non-native resolution (but same aspect ratio), (it didn't work before, so something was fixed :) the same problem occurs when i use tv-out, which has a different aspect ratio. What are the screen resolutions you are switching between, and which pager sizes do you get? i start with my laptop in native resolution, 1280x800, and the pager is 320x50. it's location is [0,750]. eesh says: Base, min, max, inc w/h 0x0, 80x12, 1280x200 32x5 Aspect min, max 6.3, 6.5 btw, i have 4 desktops side by side, so each one is 80x50, so all is good here ... screen, pager desktops both have ratio 1.6. then i go to tvout mode .. 640x480 (the screen pans), and the pager resizes to 320x60. it's location has moved to [0,718]. eesh says: Base, min, max, inc w/h 0x0, 64x12, 1024x192 32x6 Aspect min, max 5.2, 5.4 so, here the pager thinks that the desktop has changed to 1.333 ratio, which it hasn't. the display is 640x480, but the screen hasn't changed it's dimensions (i don't think). lastly i return to my laptop lcd, and the pager has once again resized (grown) to 384x60, and returned back to it's original position [0,750]. eesh says, as before: Base, min, max, inc w/h 0x0, 80x12, 1280x200 32x5 Aspect min, max 6.3, 6.5 --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] e16 pager size location in different display mode
On Thu, 16 Feb 2006 00:01:15 +0100, Kim Woelders [EMAIL PROTECTED] wrote: Dennis Nezic wrote: On Tue, 14 Feb 2006 19:26:29 +0100, Kim Woelders [EMAIL PROTECTED] wrote: Dennis Nezic wrote: i may have spoken too soon. although it does work when i start e under a non-native resolution (but same aspect ratio), (it didn't work before, so something was fixed :) the same problem occurs when i use tv-out, which has a different aspect ratio. What are the screen resolutions you are switching between, and which pager sizes do you get? i start with my laptop in native resolution, 1280x800, and the pager is 320x50. it's location is [0,750]. eesh says: Base, min, max, inc w/h 0x0, 80x12, 1280x200 32x5 Aspect min, max 6.3, 6.5 btw, i have 4 desktops side by side, so each one is 80x50, so all is good here ... screen, pager desktops both have ratio 1.6. then i go to tvout mode .. 640x480 (the screen pans), and the pager resizes to 320x60. it's location has moved to [0,718]. eesh says: Base, min, max, inc w/h 0x0, 64x12, 1024x192 32x6 Aspect min, max 5.2, 5.4 so, here the pager thinks that the desktop has changed to 1.333 ratio, which it hasn't. the display is 640x480, but the screen hasn't changed it's dimensions (i don't think). The screen dimensions don't matter, only the resolution in pixels. According to this the current screen resolution is 1024x768. Changing resolution from 1280x800 - 1024x768 would not change the pager from 320x50 to 320x60, but to 256x48. However, changing the resolution like 1280x800 - 320x240 - 1024x768 will. This doesn't explain the change in position though, so I think the resolution travels some other path between 1280x800 and 1024x768. lastly i return to my laptop lcd, and the pager has once again resized (grown) to 384x60, and returned back to it's original position [0,750]. eesh says, as before: Base, min, max, inc w/h 0x0, 80x12, 1280x200 32x5 Aspect min, max 6.3, 6.5 Again, going directly from 1024x768 to 1280x800 would give the pager size 416x60, but going via 320x240 gives 384x60. I have committed a fix that I think should cure this. However, as things are for now, if you cycle trough a number of different screen resolutions it is still not guaranteed that the pager size you start out with is exactly the one you will get when you return to the original resolution, but I don't think the pagers will keep growing, as they did. the problem persists. along with a small annoyance now that the pager can be resized with pixel resolution (for example, 72x45 and 73x45 are acceptable sizes, even though 72x45 is the true 1.6 ratio. but this isn't really a problem.) the current situation (4x1 pager) is as follows: 1) start with laptop 1280x800, pager 280x44 2) switch to tv, 640x480, pager 280x52 3) return to laptop 1280x800, pager 332x52 moreover, along with having grown, it has also moved downward 5 pixels. so, from 1=2, it preserves width, while 2=3 it preserves height. would the problem not be solved if it sticks to preserving only one of the dimensions? --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] e16 pager size location in different display mode
On Mon, 20 Feb 2006 23:35:57 +0100, Kim Woelders [EMAIL PROTECTED] wrote: Dennis Nezic wrote: On Thu, 16 Feb 2006 00:01:15 +0100, Kim Woelders [EMAIL PROTECTED] wrote: Dennis Nezic wrote: On Tue, 14 Feb 2006 19:26:29 +0100, Kim Woelders [EMAIL PROTECTED] wrote: Dennis Nezic wrote: i may have spoken too soon. although it does work when i start e under a non-native resolution (but same aspect ratio), (it didn't work before, so something was fixed :) the same problem occurs when i use tv-out, which has a different aspect ratio. What are the screen resolutions you are switching between, and which pager sizes do you get? i start with my laptop in native resolution, 1280x800, and the pager is 320x50. it's location is [0,750]. eesh says: Base, min, max, inc w/h 0x0, 80x12, 1280x200 32x5 Aspect min, max 6.3, 6.5 btw, i have 4 desktops side by side, so each one is 80x50, so all is good here ... screen, pager desktops both have ratio 1.6. then i go to tvout mode .. 640x480 (the screen pans), and the pager resizes to 320x60. it's location has moved to [0,718]. eesh says: Base, min, max, inc w/h 0x0, 64x12, 1024x192 32x6 Aspect min, max 5.2, 5.4 so, here the pager thinks that the desktop has changed to 1.333 ratio, which it hasn't. the display is 640x480, but the screen hasn't changed it's dimensions (i don't think). The screen dimensions don't matter, only the resolution in pixels. According to this the current screen resolution is 1024x768. Changing resolution from 1280x800 - 1024x768 would not change the pager from 320x50 to 320x60, but to 256x48. However, changing the resolution like 1280x800 - 320x240 - 1024x768 will. This doesn't explain the change in position though, so I think the resolution travels some other path between 1280x800 and 1024x768. lastly i return to my laptop lcd, and the pager has once again resized (grown) to 384x60, and returned back to it's original position [0,750]. eesh says, as before: Base, min, max, inc w/h 0x0, 80x12, 1280x200 32x5 Aspect min, max 6.3, 6.5 Again, going directly from 1024x768 to 1280x800 would give the pager size 416x60, but going via 320x240 gives 384x60. I have committed a fix that I think should cure this. However, as things are for now, if you cycle trough a number of different screen resolutions it is still not guaranteed that the pager size you start out with is exactly the one you will get when you return to the original resolution, but I don't think the pagers will keep growing, as they did. the problem persists. along with a small annoyance now that the pager can be resized with pixel resolution (for example, 72x45 and 73x45 are acceptable sizes, even though 72x45 is the true 1.6 ratio. but this isn't really a problem.) the current situation (4x1 pager) is as follows: 1) start with laptop 1280x800, pager 280x44 2) switch to tv, 640x480, pager 280x52 3) return to laptop 1280x800, pager 332x52 moreover, along with having grown, it has also moved downward 5 pixels. so, from 1=2, it preserves width, while 2=3 it preserves height. would the problem not be solved if it sticks to preserving only one of the dimensions? This preservation of width/height is more or less coincidental. I think your screen resolution in tv mode is not 640x480 but 1024x768. xdpyinfo or eesh screen will show. it is :).. xpdyinfo says: laptop = 1280x800, 98x96 dpi tv = 640x480, 75x75dpi things are better now :), in that the size was preserved (10x10 = 320x50). however, it was still moved down a few pixels =\. here's what happened: 1) 4x1 pager started in laptop with dimensions 320x50, position 0,750 2) using tv as output, pager is resized to 288x54, position 0,430 (bottom 4 pixels were cut off) 3) back to laptop, pager returns to 320x50, but position has moved down 3 pixels to 0,753 so, things are better :). --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
[e-users] exiting e16 doesn't close apps properly
when i exit e16 (which was started by my ~/.xinitrc file), i get the following on stderr, for example: __BEGIN__ waiting for X server to shut down The application 'gvim' lost its connection to the display :0.0; most likely the X server was shut down or you killed/destroyed the application. The application 'gaim' lost its connection to the display :0.0; most likely the X server was shut down or you killed/destroyed the application. __END__ it's particularly annoying when i have a gvim running, since its .swp file still exists after i restart, and i'm forced to deal with it :(. any idea why e16 isn't closing them properly ... or why they seem to be being kill -9ed? --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
[e-users] e16 bug when re-enabling pager
when starting e16 with the pager disabled (pagers.enable = 0), and then reenabling it (eesh pager on), although i am able to move windows around by clicking in the pager, the pager doesn't update itself (to the new window positions). even with snapshotting on, there is a brief delay, although i have snapshotting disabled. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
[e-users] e16: NeverUseArea
Maybe I'm not understanding how the NeverUseArea window toggle flag works, but shouldn't it force e16 to /never/ place windows in the specified area? If so, it doesn't seem to be working at the moment (v0.16.8.11). - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] e16: NeverUseArea
On Mon, 21 Jan 2008 19:19:28 +0100, Kim Woelders [EMAIL PROTECTED] wrote: Dennis Nezic wrote: Maybe I'm not understanding how the NeverUseArea window toggle flag works, but shouldn't it force e16 to /never/ place windows in the specified area? If so, it doesn't seem to be working at the moment (v0.16.8.11). never is a bit strong. It's more like normally. Windows may get placed over NeverUseArea windows e.g. if you place manually, if a new window cannot be placed at all otherwise, or if you do an absolute/xinerama window maximization. It looks to me like things work properly in 0.16.8.11. I did add an option to make the default maximization policy configurable (Move Resize Settings...). Could that explain something? If not please specify in more detail how you see the NeverUseArea behavior has changed. Just playing with a bunch of xterms, in an otherwise empty virtual desktop -- if I set the first one to NeverUseArea, then subsequently open a bunch of normal others, although I do see an avoidance of the area in the beginning, it covers the NeverUseArea sooner (even sooner if it's placed along the right edge of the screen) than I think it should -- in fact, it should never use that xterm's area :) (There is plenty of room for adjacent windows, and they can be overlapped. There is very little difference between the behaviour with and without the flag set. I think it should be strongly enforced :). - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] e16: NeverUseArea
On Fri, 01 Feb 2008 18:19:30 +0100, Kim Woelders [EMAIL PROTECTED] wrote: I have changed the window placement code in an attempt to improve placement on crowded desktops and when there are windows with NeverUseArea attributes. Very cool. Although, I was able to get an overlap once in a while (after /many/ xterm windows were opened), but they are far more rare now. Btw -- this all started as a way to avoid windows covering/being covered by my gkrellm :). Many thanks. Also, is there a way to have the NEVERUSEAREA setting remembered on future logins? (ie. in the e_config snapshots file?) - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
[e-users] e16 bindings don't work after upgrading xorg
I'm stumped. I recently decided to upgrade to xorg-server 1.4.2, and tonnes of modular dependencies like xkeyboard-config which includes the data files in /usr/share/X11/xkb/*. (The newer versions of these data files have the symbols/inet for my keyboard -- before I had to manually enter them into the file.) So, there were some changes done to my keyboard settings -- but, nothing that seems to be substantially different than before. And now when I start e16, it doesn't properly interpret my ~/.e16/bindings.cfg file. It does bind some things, like KeyDown CS p exec blabla -- ie. normal keys, and some special keys like Menu and Super_L -- but not other ones that seem to be specific to my laptop, like XF86WWW or XF86Mail. (xev does see these keys properly). I also have two dollar keys ... one as shift-4 (above 4), and another one near my arrow keys ... and I have a keybinding (intended for the one near the arrow keys) KeyDown - dollar exec blabla, but it's triggered when I press 4!! (I'm not pressing shift, and it's triggered). Meanwhile when I press the other dollar key, nothing happens -- e16 doesn't bind it. BUT -- if I eesh restart, everything gets bound properly. I've tried e16 0.16.8.[12,13,14], and they all have this problem -- so my guess is it's something with the updated xorg-server or xf86-input-keyboard (1.3.1), or something to do with this newer x. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] e16 bindings don't work after upgrading xorg
On Sun, 31 Aug 2008 23:56:04 -0400, Dennis Nezic [EMAIL PROTECTED] wrote: I've tried e16 0.16.8.[12,13,14], and they all have this problem -- so my guess is it's something with the updated xorg-server or xf86-input-keyboard (1.3.1), or something to do with this newer x. Same problem with xorg-server-1.5.0. I'm guessing it's something to do with the xkeyboard-config-1.3 module -- but what :|. And why does everything work after I restart e16? Very strange. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
[e-users] e16 Special-key keybindings not working cont'd
I posted a couple of months ago about this issue (end of august), and still haven't managed to resolve it :P. So, to recap: * No keybindings of special keys work on my acer laptop keyboard (Option XkbModel acer_ferrari4k) like XF86Mail, EuroSign, when e16 FIRST starts up--but they do with 'eesh restart'. This suggests that the problem is not with my configuration, but with the way e16 grabs control of the keyboard; perhaps a timing issue. Keybindings of normal keys always work. It should be noted that the special keys are recognized (xev)--just not bound. * An interesting anomaly is the normal 'dollar' symbol. My laptop has another separate key just for it, in addition to the normal one above the '4' key. But if I make a keybinding to 'dollar', it will trigger when I press '4' (not Shift-4). This problem of having the shift-level symbol being interpreted as the first level only exists with this duplicated dollar symbol, and not with others like 'at' or 'numbersign'. If I remove 'dollar' from my bindings.cfg, the '4' key is once again interpreted as '4', and not the key-bound dollar, which suggests that the problem has something to do with e16's key binding mechanism. * Most interesting of all, starting e16 with null theme (removing the theme folders; eesh theme says Name: (null)) makes the special key bindings work! This suggests that the bug has something to do with e16--even though it was only when I upgraded X (or one of X's keyboard modules) that the problem started. How can the keybinding process possibly differ if no theme is present versus if a theme is loaded?? In other words, there's something about having no theme, or restarting e16, that makes things work--or something about initially loading a theme that breaks key bindings. I don't know enough about X or e16 keybinding internals to put all these pieces of the puzzle together. Hopefully someone else might? -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] e16 Special-key keybindings not working cont'd
On Wed, 10 Dec 2008 19:44:23 +0100, Kim Woelders k...@woelders.dk wrote: On Tue, 09 Dec 2008 21:54:07 +0100, Dennis Nezic denn...@dennisn.dyndns.org wrote: I posted a couple of months ago about this issue (end of august), and still haven't managed to resolve it :P. So, to recap: * No keybindings of special keys work on my acer laptop keyboard (Option XkbModel acer_ferrari4k) like XF86Mail, EuroSign, when e16 FIRST starts up--but they do with 'eesh restart'. This suggests that the problem is not with my configuration, but with the way e16 grabs control of the keyboard; perhaps a timing issue. Keybindings of normal keys always work. It should be noted that the special keys are recognized (xev)--just not bound. * An interesting anomaly is the normal 'dollar' symbol. My laptop has another separate key just for it, in addition to the normal one above the '4' key. But if I make a keybinding to 'dollar', it will trigger when I press '4' (not Shift-4). This problem of having the shift-level symbol being interpreted as the first level only exists with this duplicated dollar symbol, and not with others like 'at' or 'numbersign'. If I remove 'dollar' from my bindings.cfg, the '4' key is once again interpreted as '4', and not the key-bound dollar, which suggests that the problem has something to do with e16's key binding mechanism. * Most interesting of all, starting e16 with null theme (removing the theme folders; eesh theme says Name: (null)) makes the special key bindings work! This suggests that the bug has something to do with e16--even though it was only when I upgraded X (or one of X's keyboard modules) that the problem started. How can the keybinding process possibly differ if no theme is present versus if a theme is loaded?? Timing? Don't you get the ...mostly pointless... screen where you have to confirm? Btw. as of 0.16.8.14 (IIRC) you can run without a theme using option -t - (i.e. no need to trash the theme directories). H actually, I have just discovered that it was not loading e16 with no theme that made the bindings work, but rather pressing F1 in the mostly pointless dialogue! If I used the mouse instead, the bindings wouldn't work--even with null theme! Further testing revealed that if I pressed random buttons on my keyboard while X/e16 was loading, the bindings would work! It does sound like something wrong with the new X-server hotplug stuff that you mention below--but specifically with e16, since the keys are properly mapped with their special layout symbols--they just aren't binded in e16--that is, only the special keys aren't binded... all the normal keys are. In other words, there's something about having no theme, or restarting e16, that makes things work--or something about initially loading a theme that breaks key bindings. I don't know enough about X or e16 keybinding internals to put all these pieces of the puzzle together. Hopefully someone else might? Could it be something with keyboard mapping changing during startup, maybe related to the new X-server hotplug stuff? You could try adding a delay between starting the server and starting e16, e.g. add sleep 2 in some startup script. Sleeping doesn't help. (Although if I could somehow simulate a special keypress :/---but that is an ugly solution.) -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] e16 Special-key keybindings not working cont'd
On Sun, 14 Dec 2008 17:20:40 +0100, Kim Woelders k...@woelders.dk wrote: On Sat, 13 Dec 2008 17:27:21 +0100, Dennis Nezic denn...@dennisn.dyndns.org wrote: On Wed, 10 Dec 2008 19:44:23 +0100, Kim Woelders k...@woelders.dk wrote: On Tue, 09 Dec 2008 21:54:07 +0100, Dennis Nezic denn...@dennisn.dyndns.org wrote: I posted a couple of months ago about this issue (end of august), and still haven't managed to resolve it :P. So, to recap: * No keybindings of special keys work on my acer laptop keyboard (Option XkbModel acer_ferrari4k) like XF86Mail, EuroSign, when e16 FIRST starts up--but they do with 'eesh restart'. This suggests that the problem is not with my configuration, but with the way e16 grabs control of the keyboard; perhaps a timing issue. Keybindings of normal keys always work. It should be noted that the special keys are recognized (xev)--just not bound. * An interesting anomaly is the normal 'dollar' symbol. My laptop has another separate key just for it, in addition to the normal one above the '4' key. But if I make a keybinding to 'dollar', it will trigger when I press '4' (not Shift-4). This problem of having the shift-level symbol being interpreted as the first level only exists with this duplicated dollar symbol, and not with others like 'at' or 'numbersign'. If I remove 'dollar' from my bindings.cfg, the '4' key is once again interpreted as '4', and not the key-bound dollar, which suggests that the problem has something to do with e16's key binding mechanism. * Most interesting of all, starting e16 with null theme (removing the theme folders; eesh theme says Name: (null)) makes the special key bindings work! This suggests that the bug has something to do with e16--even though it was only when I upgraded X (or one of X's keyboard modules) that the problem started. How can the keybinding process possibly differ if no theme is present versus if a theme is loaded?? Timing? Don't you get the ...mostly pointless... screen where you have to confirm? Btw. as of 0.16.8.14 (IIRC) you can run without a theme using option -t - (i.e. no need to trash the theme directories). H actually, I have just discovered that it was not loading e16 with no theme that made the bindings work, but rather pressing F1 in the mostly pointless dialogue! If I used the mouse instead, the bindings wouldn't work--even with null theme! Further testing revealed that if I pressed random buttons on my keyboard while X/e16 was loading, the bindings would work! It does sound like something wrong with the new X-server hotplug stuff that you mention below--but specifically with e16, since the keys are properly mapped with their special layout symbols--they just aren't binded in e16--that is, only the special keys aren't binded... all the normal keys are. In other words, there's something about having no theme, or restarting e16, that makes things work--or something about initially loading a theme that breaks key bindings. I don't know enough about X or e16 keybinding internals to put all these pieces of the puzzle together. Hopefully someone else might? Could it be something with keyboard mapping changing during startup, maybe related to the new X-server hotplug stuff? You could try adding a delay between starting the server and starting e16, e.g. add sleep 2 in some startup script. Sleeping doesn't help. (Although if I could somehow simulate a special keypress :/---but that is an ugly solution.) Here's another hack that might fix things: Enable the session scripts: $ eesh set misc.session.enable_script 1 Add a script (e.g. ~/.e16/Init/reload_bindings) to reload the keybindings some time after startup: #!/bin/sh sleep 2 eesh ac load bindings.cfg Interesting. That sortof works--but not really. When I run that command, in a startup script or later during the session, I get an ActionClass Error! popup dialog window with messages like 5 references remain. So I have to run it again, and usually I get the same error message but with a smaller value, like 1 references remain. The numbers don't appear fixed. I've seen 14 references remain, 4 references remain. -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
[e-users] e16 menus
With a long menu (and a long submenu), the bottom portion of the submenu is not always visible on the screen. For example, if the submenu is located near the bottom of the menu, opening it will cause the menu to slide to the top of the screen (if the always pop up menus on screen option is set), and the submenu will open with it's top aligned directly beside it's entry in the first menu -- which is near the middle of the screen. In other words, the submenu only has about half the screen's height to work with. I guess the easiest solution would be to fix the submenu's height to the actual visible height that remains available to it. Another solution would be to allow the menu to slide above the top of the screen, to allow the submenu to fill the entire height. Also, on a related note, a submenu within a submenu is able to slide the original menu above the top of the screen, but when one closes the submenus, the menu doesn't automatically slide back down and become visible until a submenu is opened -- ie. the redisplay of the menu should be triggered after submenus are closed (or, if there's a dirty-flag, if the menu has been moved, and a submenu closed.) On a less related note, while we're fixing up the menus :P, what are your thoughts on word-navigation within menus? Ie. currently the menus can only be navigated by the up/down arrow keys -- but wouldn't it be nice if we could type substrings which automatically highlight all the matching menu labels (maybe within submenus too?), and if there are multiple matches, pressing tab could alternate between them? -- ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
[e-users] e16 bug when moving deceased window
If a window closes in the process of being moved, weird things happen -- usually the mouse gets trapped within a box, and e16 stops responding. X still works, but Alt-F'ing to a terminal and trying to eesh restart doesn't work. I am forced to kill X (Ctrl-Alt-Backspace). Here's a quick way to reproduce it: Open an xterm and run sleep 3s; eesh wop 0xWHATEVERTHEIDIS close then move the xterm around while it gets closed. (Maybe open a second xterm underneath it to see what usually happens on crowded desktops, as opposed to having the root window below.) -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] e16 bug when moving deceased window
On Sun, 10 Jan 2010 10:52:24 +0100, Kim Woelders wrote: On Sun, 10 Jan 2010 06:52:49 +0100, Dennis Nezic denn...@dennisn.dyndns.org wrote: If a window closes in the process of being moved, weird things happen -- usually the mouse gets trapped within a box, and e16 stops responding. X still works, but Alt-F'ing to a terminal and trying to eesh restart doesn't work. I am forced to kill X (Ctrl-Alt-Backspace). Here's a quick way to reproduce it: Open an xterm and run sleep 3s; eesh wop 0xWHATEVERTHEIDIS close then move the xterm around while it gets closed. (Maybe open a second xterm underneath it to see what usually happens on crowded desktops, as opposed to having the root window below.) I think this is fixed in svn. The fix (if this is not a different issue) is also in the e16-1.0.1.001/002 snapshots on sourceforge. You are correct! -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
[e-users] e16 Iconbox unknown question mark icon
After upgrading to e16 1.0.1.002 (from 1.0.1), I noticed that some apps in my Iconbox now display a question-mark icon, where before they were a snapshotted mini-window. Being a question mark, I assume e16 knows there is no application icon for it, nor an e16 icon ... shouldn't it be using the window snapshot? Window snapshotting in the Iconbox does work if I set the policy to display the snapshot first, but windows never get snapshotted with the other two policies. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] e16 Iconbox unknown question mark icon
On Mon, 11 Jan 2010 18:25:44 +0100, Kim Woelders wrote: On Mon, 11 Jan 2010 04:15:10 +0100, Dennis Nezic denn...@dennisn.dyndns.org wrote: After upgrading to e16 1.0.1.002 (from 1.0.1), I noticed that some apps in my Iconbox now display a question-mark icon, where before they were a snapshotted mini-window. Being a question mark, I assume e16 knows there is no application icon for it, nor an e16 icon ... shouldn't it be using the window snapshot? Window snapshotting in the Iconbox does work if I set the policy to display the snapshot first, but windows never get snapshotted with the other two policies. Yeah, the new thing is that there is a default icon which is shown in either of the app-icon and e-icon modes when there is no app/e icon. It seems to me to be consistent to show an icon if the preferred display policy is an icon-type one. However, as you say, this also means that windows are never snapshotted in icon modes. Whether the fallback should be a snapshot or the default icon is a matter of taste, I believe :) I guess the text in the configuration dialog should be changed to not indicate that snapshotting may be used as fallback. Yes ... although, who would prefer question-mark-icons (which mean absolutely nothing :b), over a window-snapshot which at least offers some chance of identification? -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
[e-users] e16 alt-tabbing
Currently, when the focus list is enabled (during an Alt-Tab), it raises the next window always, automatically, even though I have Raise windows while switching focus disabled. This is a problem if I DON'T want to raise the next one in the list (but rather another one further down.) -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] e16 alt-tabbing
On Sun, 14 Mar 2010 11:50:59 -0400, Dennis Nezic wrote: Currently, when the focus list is enabled (during an Alt-Tab), it raises the next window always, automatically, even though I have Raise windows while switching focus disabled. This is a problem if I DON'T want to raise the next one in the list (but rather another one further down.) Hrrm .. this issue magically resolved itself after I restarted e16. And now I'm having trouble reproducing it :b. False alarm, I guess. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] e16 alt-tabbing
On Sun, 14 Mar 2010 12:01:33 -0400, Dennis Nezic wrote: On Sun, 14 Mar 2010 11:50:59 -0400, Dennis Nezic wrote: Currently, when the focus list is enabled (during an Alt-Tab), it raises the next window always, automatically, even though I have Raise windows while switching focus disabled. This is a problem if I DON'T want to raise the next one in the list (but rather another one further down.) Hrrm .. this issue magically resolved itself after I restarted e16. And now I'm having trouble reproducing it :b. False alarm, I guess. Hrrrm .. maybe it didn't -- but I have narrowed down the problem to just one app -- dillo (an fltk2 based browser). And, it turns out, that it ALWAYS gets raised (though not focused) whenever the alt-tab-focus-list is presented -- even if it's not the next in order. It gets even stranger though. If I shade it and then bury it underneath other windows, and then invoke the focus-list, not only does it mysteriously get raised as usual, but it un-shades WITHOUT getting redrawn. And it never redraws itself (even if I load websites, blindly) until I either resize the window or reshade-then-shade it -- ie. it continues behaving as if it were shaded, even though it (mysteriously) raised and unshaded itself. Probably some kind of fltk2 bug? -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] e16 alt-tabbing
On Sun, 14 Mar 2010 15:38:13 -0400, Dennis Nezic wrote: On Sun, 14 Mar 2010 12:01:33 -0400, Dennis Nezic wrote: On Sun, 14 Mar 2010 11:50:59 -0400, Dennis Nezic wrote: Currently, when the focus list is enabled (during an Alt-Tab), it raises the next window always, automatically, even though I have Raise windows while switching focus disabled. This is a problem if I DON'T want to raise the next one in the list (but rather another one further down.) Hrrm .. this issue magically resolved itself after I restarted e16. And now I'm having trouble reproducing it :b. False alarm, I guess. Hrrrm .. maybe it didn't -- but I have narrowed down the problem to just one app -- dillo (an fltk2 based browser). And, it turns out, that it ALWAYS gets raised (though not focused) whenever the alt-tab-focus-list is presented -- even if it's not the next in order. It gets even stranger though. If I shade it and then bury it underneath other windows, and then invoke the focus-list, not only does it mysteriously get raised as usual, but it un-shades WITHOUT getting redrawn. And it never redraws itself (even if I load websites, blindly) until I either resize the window or reshade-then-shade it -- ie. it continues behaving as if it were shaded, even though it (mysteriously) raised and unshaded itself. Probably some kind of fltk2 bug? Yeah -- it looks so -- I can confirm it with other fltk-based apps .. like flightgear's fgrun, which uses fltk-1. Same behavior. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
[e-users] e16: new gvim(-type) windows may get placed off-screen
On a crowded desktop (ie. if you just open a bunch of gvim windows), e16 will position new gvim windows so that the bottom gvim-status line is cut off screen (the last ~10 pixels?). (my 1200x800 desktop can't fit 2 502x412 gvim windows vertically.) When trying to resize the gvim window, it reports it's size in columnsxrows (80x30) instead of pixels wxh. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
[e-users] e16: pidgin's system tray icon passes mouse-clicks through
Any idea why Pidgin's new-instant-message notification system-tray icon passes mouse clicks through to the window below it, while, for example, Xchat's doesn't? Pidgin's does respond to it, and then goes away (as it's supposed to), but also sends it to the window underneath -- which is annoying if, for example, someone instant messages me while I'm playing a fullscreen movie :). All the windows are in the normal layer 4. If I sleep 1; eesh wi current and hover my mouse over the system tray, it reports that I'm hovering over the window underneath (if there is one), and not the System tray (or Icon Box for that matter). (I'm not sure if it matters, but both my system tray and icon box are BORDERLESS -- ie. invisible if there are no icons.) -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] e16: new gvim(-type) windows may get placed off-screen
On Fri, 16 Apr 2010 00:32:36 +0200, Kim Woelders wrote: On Thu, 15 Apr 2010 19:01:26 +0200, Dennis Nezic denn...@dennisn.dyndns.org wrote: On a crowded desktop (ie. if you just open a bunch of gvim windows), e16 will position new gvim windows so that the bottom gvim-status line is cut off screen (the last ~10 pixels?). (my 1200x800 desktop can't fit 2 502x412 gvim windows vertically.) It seems that gvim resizes itself after being mapped, which kind of breaks window placement. You can avoid this by putting Class Gvim Winop no_app_size in matches.cfg. Perfect! (I'm guessing that flag prohibits windows from resizing themselves? Which, personally, I would set for ALL windows -- is there a way to make this the default setting? :P) -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] e16: pidgin's system tray icon passes mouse-clicks through
On Sat, 17 Apr 2010 08:58:51 +0200, Kim Woelders wrote: On Thu, 15 Apr 2010 19:12:39 +0200, Dennis Nezic denn...@dennisn.dyndns.org wrote: Any idea why Pidgin's new-instant-message notification system-tray icon passes mouse clicks through to the window below it, while, for example, Xchat's doesn't? Pidgin's does respond to it, and then goes away (as it's supposed to), but also sends it to the window underneath -- which is annoying if, for example, someone instant messages me while I'm playing a fullscreen movie :). All the windows are in the normal layer 4. If I sleep 1; eesh wi current and hover my mouse over the system tray, it reports that I'm hovering over the window underneath (if there is one), and not the System tray (or Icon Box for that matter). (I'm not sure if it matters, but both my system tray and icon box are BORDERLESS -- ie. invisible if there are no icons.) What probably happens is: - You press button down on the pidgin systray icon - Pidgin removes the icon, and the mouse is now over whatever is below because your systray has transparent background - You release the button, and that event goes to the window below. I don't think there is anything sane e16 can do about that. Pidgin could do its stuff on button release in stead of press or take a pointer grab that is released on button release. You're right! (again, as usual :b) I find that if I click fast, it usually works fine (I guess the buttonrelease happens before the icon is destroyed) ... but if I click very slowly (keep the button down for a second), the buttonrelease indeed always goes to the window below. Thanks for the tips. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] e16: pidgin's system tray icon passes mouse-clicks through
On Sat, 17 Apr 2010 08:58:51 +0200, Kim Woelders wrote: On Thu, 15 Apr 2010 19:12:39 +0200, Dennis Nezic denn...@dennisn.dyndns.org wrote: Any idea why Pidgin's new-instant-message notification system-tray icon passes mouse clicks through to the window below it, while, for example, Xchat's doesn't? Pidgin's does respond to it, and then goes away (as it's supposed to), but also sends it to the window underneath -- which is annoying if, for example, someone instant messages me while I'm playing a fullscreen movie :). All the windows are in the normal layer 4. If I sleep 1; eesh wi current and hover my mouse over the system tray, it reports that I'm hovering over the window underneath (if there is one), and not the System tray (or Icon Box for that matter). (I'm not sure if it matters, but both my system tray and icon box are BORDERLESS -- ie. invisible if there are no icons.) What probably happens is: - You press button down on the pidgin systray icon - Pidgin removes the icon, and the mouse is now over whatever is below because your systray has transparent background - You release the button, and that event goes to the window below. I don't think there is anything sane e16 can do about that. Pidgin could do its stuff on button release in stead of press or take a pointer grab that is released on button release. On a related note, do you have any idea why pidgin's systray icon never gets redrawn when it is overlapped by other windows, while other app's systray icons (xchat, sylpheed, etc) seem to work (get redrawn) fine? -- ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
[e-users] e(16) and X memory usage
I'm not sure if this question is appropriate here, but my X always seems to be growing in memory-use -- never shrinking. (Not even if I close everything except for e16 itself.) Do you suppose the window manager has something to do with this? Is there any way to free up this (useless / leaked?) memory from X? -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] e(16) and X memory usage
On Sat, 20 Nov 2010 12:59:40 +0900, Carsten Haitzler (The Rasterman) wrote: On Fri, 19 Nov 2010 22:07:59 -0500 Dennis Nezic denn...@dennisn.dyndns.org said: xrestop use that to see if anythingis leaking x resources. other than that it may simply be normal glibc memory growth. look at rss not vsize for an accurate picture - vsize is not relevant, also it could be a server leak of some sort - if xrestop doesnt show some client eating through lots of pixmaps/gc's or something. report to your distro or xorg. Very cool! As I suspected, e16 is by far the largest consumer. After about 4 days of e16 uptime, I have: res-base Wins GCs Fnts Pxms Misc Pxm mem Other Total PID Identifier 040 407531 176 53885687K109K 85796K ? e16 -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] e(16) and X memory usage
On Sat, 20 Nov 2010 09:15:35 -0500, Dennis Nezic wrote: On Sat, 20 Nov 2010 12:59:40 +0900, Carsten Haitzler (The Rasterman) wrote: On Fri, 19 Nov 2010 22:07:59 -0500 Dennis Nezic denn...@dennisn.dyndns.org said: xrestop use that to see if anythingis leaking x resources. other than that it may simply be normal glibc memory growth. look at rss not vsize for an accurate picture - vsize is not relevant, also it could be a server leak of some sort - if xrestop doesnt show some client eating through lots of pixmaps/gc's or something. report to your distro or xorg. Very cool! As I suspected, e16 is by far the largest consumer. After about 4 days of e16 uptime, I have: res-base Wins GCs Fnts Pxms Misc Pxm mem Other Total PID Identifier 040 407531 176 53885687K109K 85796K ? e16 The main culprit that I see, so far, are the menus. Here are a few consecutive xrestop iterations, while simply opening my APPS_SUBMENU menu (which has no submenus). (The first column is Wins -- 9 get created each time I open the menu, but only 8 get freed after closing it.) 426831 253 44994373K111K 94485K ? e16 426931 291 44995913K111K 96024K ? e16 427031 274 44996373K111K 96485K ? e16 427131 289 44897074K111K 97186K ? e16 Here is the same while opening my ROOT_2 menu, which has a few submenus, that I didn't open. (88 Wins get created, only 15 get removed, thus leaking 73 each time.) 453131 282 471 104569K118K 104687K ? e16 460431 286 470 105843K119K 105963K ? e16 467731 278 470 106813K121K 106935K ? e16 475031 282 470 108113K123K 108236K ? e16 482331 284 471 109331K125K 109456K ? e16 I also find that when programs crash, not all the Wins or memory get released. (I should correct my original report -- the memory does sometimes decrease -- but obviously the general trend is always increasing.) -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] e(16) and X memory usage
On Sun, 21 Nov 2010 19:10:48 +0100, Kim Woelders wrote: On Sun, 21 Nov 2010 18:36:51 +0100, Kim Woelders k...@woelders.dk wrote: On Sun, 21 Nov 2010 17:51:37 +0100, Kim Woelders k...@woelders.dk wrote: On Sat, 20 Nov 2010 17:38:07 +0100, Dennis Nezic denn...@dennisn.dyndns.org wrote: On Sat, 20 Nov 2010 09:15:35 -0500, Dennis Nezic wrote: On Sat, 20 Nov 2010 12:59:40 +0900, Carsten Haitzler (The Rasterman) wrote: On Fri, 19 Nov 2010 22:07:59 -0500 Dennis Nezic denn...@dennisn.dyndns.org said: xrestop use that to see if anythingis leaking x resources. other than that it may simply be normal glibc memory growth. look at rss not vsize for an accurate picture - vsize is not relevant, also it could be a server leak of some sort - if xrestop doesnt show some client eating through lots of pixmaps/gc's or something. report to your distro or xorg. Very cool! As I suspected, e16 is by far the largest consumer. After about 4 days of e16 uptime, I have: res-base Wins GCs Fnts Pxms Misc Pxm mem Other Total PID Identifier 040 407531 176 53885687K109K 85796K ? e16 The main culprit that I see, so far, are the menus. Here are a few consecutive xrestop iterations, while simply opening my APPS_SUBMENU menu (which has no submenus). (The first column is Wins -- 9 get created each time I open the menu, but only 8 get freed after closing it.) 426831 253 44994373K111K 94485K ? e16 426931 291 44995913K111K 96024K ? e16 427031 274 44996373K111K 96485K ? e16 427131 289 44897074K111K 97186K ? e16 Here is the same while opening my ROOT_2 menu, which has a few submenus, that I didn't open. (88 Wins get created, only 15 get removed, thus leaking 73 each time.) 453131 282 471 104569K118K 104687K ? e16 460431 286 470 105843K119K 105963K ? e16 467731 278 470 106813K121K 106935K ? e16 475031 282 470 108113K123K 108236K ? e16 482331 284 471 109331K125K 109456K ? e16 I also find that when programs crash, not all the Wins or memory get released. (I should correct my original report -- the memory does sometimes decrease -- but obviously the general trend is always increasing.) This definitely doesn't look right. It certainly looks like there is a window (and pixmap memory) leak. The number of windows used by menus should not increase after repeated opening of the same menu, but after closing the menus are kept around for 5-10 minutes so it will take about that long for resource usage to go down to the level before the menu was first shown (this is how it is supposed to work, anyway). I wonder about e16 resources not being freed when an application crashes. That definitely shouldn't happen either. FWIW I don't see any of this weirdness... Could you please send me the output from xwininfo -root -tree? Which e16 version is this? Never mind - On another box I get resource leakage when using menus too. Not when apps crash though. The menu resource leakage problem exists in 1.0.5 and 1.0.6, but not in 1.0.4 or 1.0.7. So, it seems to have been fixed along with other menu related problems in 1.0.7 :) Indeed -- 1.0.7 works! Thanks again! (Apologies for not mentioning my 1.0.6 version earlier.) -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] e(16) and X memory usage
On Sun, 21 Nov 2010 16:15:22 -0700, James Bowlin wrote: On Sun, Nov 21, 2010 at 07:10 PM, Kim Woelders said: The menu resource leakage problem exists in 1.0.5 and 1.0.6, but not in 1.0.4 or 1.0.7. So, it seems to have been fixed along with other menu related problems in 1.0.7 :) I've got a ton of e16 menus because I convert all my Firefox bookmarks into e16 menus. I see no sign of leakage in 1.0.7. I do that too :D. Good job. -- Increase Visibility of Your 3D Game App Earn a Chance To Win $500! Tap into the largest installed PC base get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
[e-users] e16: segfault introduced in 1.0.8
I'm not sure the exact action that causes it, but when I try to rename a file in the popular file manager rox, it pops up a mini-window to enter the new filename, and after I click ok/enter to close it, e16 segfaults: #0 0x00414464 in EwinBorderDraw (ewin=0x73bc50, do_shape=0, do_paint=0) at borders.c:228 #1 0x00436ecc in FocusEwinSetActive (ewin=0x73bc50, active=0) at focus.c:252 #2 0x004384f8 in doFocusToEwin (ewin=0x69e9b0, why=4) at focus.c:441 #3 0x0043878b in FocusSet () at focus.c:514 #4 0x004389bd in _FocusIdler (data=0x73bc50) at focus.c:1020 #5 0x00427e3c in ecore_list_for_each (list=value optimized out, function=0x462920 _IdlerRun, user_data=0x0) at e16-ecore_list.c:650 #6 0x0042c87c in EventsMain () at events.c:960 #7 0x0044877d in main (argc=value optimized out, argv=value optimized out) at main.c:310 This only started happening with 1.0.8 and 1.0.9 ... not with 1.0.7. -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] e16: segfault introduced in 1.0.8
On Wed, 24 Aug 2011 22:47:33 +0200, Kim Woelders wrote: On Mon, 22 Aug 2011 16:47:36 +0200, Kim Woelders k...@woelders.dk wrote: On Fri, 19 Aug 2011 00:51:02 +0200, Dennis Nezic denn...@dennisn.dyndns.org wrote: I'm not sure the exact action that causes it, but when I try to rename a file in the popular file manager rox, it pops up a mini-window to enter the new filename, and after I click ok/enter to close it, e16 segfaults: #0 0x00414464 in EwinBorderDraw (ewin=0x73bc50, #do_shape=0, do_paint=0) at borders.c:228 #1 0x00436ecc in FocusEwinSetActive (ewin=0x73bc50, #active=0) at focus.c:252 #2 0x004384f8 in doFocusToEwin (ewin=0x69e9b0, why=4) at focus.c:441 #3 0x0043878b in FocusSet () at focus.c:514 #4 0x004389bd in _FocusIdler (data=0x73bc50) at #focus.c:1020 5 0x00427e3c in ecore_list_for_each #(list=value optimized out, function=0x462920 _IdlerRun, user_data=0x0) at e16-ecore_list.c:650 #6 0x0042c87c in EventsMain () at events.c:960 #7 0x0044877d in main (argc=value optimized out, #argv=value optimized out) at main.c:310 This only started happening with 1.0.8 and 1.0.9 ... not with 1.0.7. Yeah, I see that too. Unfortunately the problem is somewhat tricky, and I haven't found the proper fix yet. I think this now is fixed in svn. Yep, I can no longer reproduce the bug with r62762. Thanks! -- EMC VNX: the world's simplest storage, starting under $10K The only unified storage solution that offers unified management Up to 160% more powerful than alternatives and 25% more efficient. Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
[e-users] e16 iconbox pager don't update window title
If I change a window's title, say with xterm, eesh wop current title whatever, neither the Iconbox nor the Pager show the updated title (when hovering over it). eesh wl does show it. -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free Love Thy Logs t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
[e-users] e16: systray draws/redraws
Why do some systray icons draw/redraw properly (ie. if I move a window over them, then move it off), while others do not? Systray icons, such as those from xchat or sylpheed get properly redrawn, but systray icons from ekiga or nm-applet do not -- they are painted white by the overlapping window, and never redrawn? The separate trayer systray program manages to paint them all properly. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] e16: systray draws/redraws
On Sun, 25 Sep 2011 20:25:44 +0200, Kim Woelders wrote: On Wed, 21 Sep 2011 20:29:47 +0200, Dennis Nezic denn...@dennisn.dyndns.org wrote: Why do some systray icons draw/redraw properly (ie. if I move a window over them, then move it off), while others do not? Systray icons, such as those from xchat or sylpheed get properly redrawn, but systray icons from ekiga or nm-applet do not -- they are painted white by the overlapping window, and never redrawn? The separate trayer systray program manages to paint them all properly. I don't see that problem. The systray icons are painted by their application, not e16 or trayer, so I can't explain why there is a difference between the e16 and trayer systray behavior on your system, but there has been quite some flakyness in the application's systray icon implementations over time. To update, the problem seems to occur only with ~24pixel sized systray icons. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] e16-1.0.10
On Sun, 09 Oct 2011 16:49:24 +0200, Kim Woelders wrote: e16-1.0.10 is available for download: http://sourceforge.net/projects/enlightenment/files/ The purpose of this release is primarily to fix a few possibly quite annoying bugs in 1.0.9: - Fix menu regeneration after updating from pre- 1.0.9 versions. - Fix segv when new client is destroyed before being mapped. /Kim Thanks. 'Preciate it. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] e16 regex bugfix
On Mon, 15 Nov 2021 12:53:51 +0100, Kim Woelders wrote: > On 11/15/21 06:53, Dennis Nezic wrote: > > On Mon, 15 Nov 2021 00:29:46 -0500, Dennis Nezic wrote: > >> On Sat, 13 Nov 2021 18:11:02 +0100, Kim Woelders wrote: > >>> On 11/13/21 16:17, Dennis Nezic wrote: > >>>> On Sat, 13 Nov 2021 07:33:19 +0100, Kim Woelders wrote: > >>>>> On 11/13/21 05:18, Dennis Nezic wrote: > >>>>>> On Fri, 12 Nov 2021 17:48:50 +0100, Kim Woelders wrote: > >>>>>>> On 11/11/21 21:24, Dennis Nezic wrote: > >>>>>>>> Here's a small patch for regex.c > >>>>>>>> > >>>>>>>> Currently, in matches.cfg, "Title *bla ..." will match any > >>>>>>>> title with "bla" in it ... but it should only match if the > >>>>>>>> title ends in bla, right? > >>>>>>>> > >>>>>>> Right. > >>>>>>> > >>>>>>> Patch looks good to me - pushed to git. > >>>>>> > >>>>>> (Tiny improvement ... we don't need the "if (i>0)" test in that > >>>>>> patch ... isafter() will never return 0 ... a simple decrement > >>>>>> is fine.) > >>>>>> > >>>>> Hmm.. then I think we can just drop the decrement if we drop the > >>>>> increment in the for loop too, right? > >>>> > >>>> Oh yea, I forgot for loops could do that :) > >>>> > >>> Update pushed. > >> > >> The last "return match" occurs when we've reached the end of the > >> string that's being checked. But if there are more characters in > >> the regex to test for, we need to return 0. > >> > >> --- a/src/regex.c 2021-11-15 00:18:59.0 -0500 > >> +++ b/src/regex.c 2021-11-15 00:20:55.0 -0500 > >> @@ -114,5 +114,8 @@ > >>return match; > >> } > >>} > >> + while (rx[l]) > >> + if (rx[l++] != '*') > >> + return 0; > >> return match; > >> } > > > > For example, the string "bla" would have been false-positively > > matched against "bla*x" without this. > > > Ok, I have pushed a new matchregexp() that simply calls fnmatch(). > I hope you cannot poke holes in that :) Looks good... it passes my tests. Thank you. ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
[e-users] e16: matches.cfg documentation clarification
In the description of the "Size" match value, in
/usr/share/e16/config/matches.cfg it currently says:
Size: {>|<}x
What does {>|<} mean? Wouldn't this be more readable:
Size: -x-
Ie. it's expecting 4 values in that format.
___
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users
[e-users] e16 regex bugfix
Here's a small patch for regex.c Currently, in matches.cfg, "Title *bla ..." will match any title with "bla" in it ... but it should only match if the title ends in bla, right? By the way, the indentations in that file are ... weird :P. ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] e16 regex bugfix
--- regex.c.orig2021-11-11 14:08:55.0 -0500
+++ regex.c 2021-11-11 15:19:47.0 -0500
@@ -102,9 +102,24 @@
i = isafter(i, s, rx2);
if (i < 0)
return 0;
+// Because the for loop will increment i (the index
+// into string s) at the end of this block, but i now
+// already points to the next char in s, this next char
+// gets ignored.
+// Without this next decrement, if the regex is *bla,
+// it will incorrectly say that blax matches, although
+// correctly say that blaxy doesn't. Ie. char x is skipped
+if (i>0) i--;
}
- else
- return match;
+ else {
+ // We arrived at the end of the regex BUT if it doesn't
+ // end with the wildcard * and there are more chars
+ // in s remaining to be matched, we should return 0
+ if ((i < len) && (rx[l-1] != '*'))
+ return 0;
+ else
+ return match;
+ }
}
return match;
}
On Thu, 11 Nov 2021 15:24:52 -0500, Dennis Nezic wrote:
> Here's a small patch for regex.c
>
> Currently, in matches.cfg, "Title *bla ..." will match any title with
> "bla" in it ... but it should only match if the title ends in bla,
> right?
>
> By the way, the indentations in that file are ... weird :P.
>
> ___
> enlightenment-users mailing list
> enlightenment-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-users
___
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] e16 regex bugfix
On Sat, 13 Nov 2021 07:33:19 +0100, Kim Woelders wrote: > On 11/13/21 05:18, Dennis Nezic wrote: > > On Fri, 12 Nov 2021 17:48:50 +0100, Kim Woelders wrote: > >> On 11/11/21 21:24, Dennis Nezic wrote: > >>> Here's a small patch for regex.c > >>> > >>> Currently, in matches.cfg, "Title *bla ..." will match any title > >>> with "bla" in it ... but it should only match if the title ends in > >>> bla, right? > >>> > >> Right. > >> > >> Patch looks good to me - pushed to git. > > > > (Tiny improvement ... we don't need the "if (i>0)" test in that > > patch ... isafter() will never return 0 ... a simple decrement is > > fine.) > > > Hmm.. then I think we can just drop the decrement if we drop the > increment in the for loop too, right? Oh yea, I forgot for loops could do that :) ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] e16 regex bugfix
On Mon, 15 Nov 2021 00:29:46 -0500, Dennis Nezic wrote: > On Sat, 13 Nov 2021 18:11:02 +0100, Kim Woelders wrote: > > On 11/13/21 16:17, Dennis Nezic wrote: > > > On Sat, 13 Nov 2021 07:33:19 +0100, Kim Woelders wrote: > > >> On 11/13/21 05:18, Dennis Nezic wrote: > > >>> On Fri, 12 Nov 2021 17:48:50 +0100, Kim Woelders wrote: > > >>>> On 11/11/21 21:24, Dennis Nezic wrote: > > >>>>> Here's a small patch for regex.c > > >>>>> > > >>>>> Currently, in matches.cfg, "Title *bla ..." will match any > > >>>>> title with "bla" in it ... but it should only match if the > > >>>>> title ends in bla, right? > > >>>>> > > >>>> Right. > > >>>> > > >>>> Patch looks good to me - pushed to git. > > >>> > > >>> (Tiny improvement ... we don't need the "if (i>0)" test in that > > >>> patch ... isafter() will never return 0 ... a simple decrement > > >>> is fine.) > > >>> > > >> Hmm.. then I think we can just drop the decrement if we drop the > > >> increment in the for loop too, right? > > > > > > Oh yea, I forgot for loops could do that :) > > > > > Update pushed. > > The last "return match" occurs when we've reached the end of the > string that's being checked. But if there are more characters in the > regex to test for, we need to return 0. > > --- a/src/regex.c 2021-11-15 00:18:59.0 -0500 > +++ b/src/regex.c 2021-11-15 00:20:55.0 -0500 > @@ -114,5 +114,8 @@ > return match; > } > } > + while (rx[l]) > + if (rx[l++] != '*') > + return 0; > return match; > } For example, the string "bla" would have been false-positively matched against "bla*x" without this. ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] e16 regex bugfix
On Sat, 13 Nov 2021 18:11:02 +0100, Kim Woelders wrote: > On 11/13/21 16:17, Dennis Nezic wrote: > > On Sat, 13 Nov 2021 07:33:19 +0100, Kim Woelders wrote: > >> On 11/13/21 05:18, Dennis Nezic wrote: > >>> On Fri, 12 Nov 2021 17:48:50 +0100, Kim Woelders wrote: > >>>> On 11/11/21 21:24, Dennis Nezic wrote: > >>>>> Here's a small patch for regex.c > >>>>> > >>>>> Currently, in matches.cfg, "Title *bla ..." will match any title > >>>>> with "bla" in it ... but it should only match if the title ends > >>>>> in bla, right? > >>>>> > >>>> Right. > >>>> > >>>> Patch looks good to me - pushed to git. > >>> > >>> (Tiny improvement ... we don't need the "if (i>0)" test in that > >>> patch ... isafter() will never return 0 ... a simple decrement is > >>> fine.) > >>> > >> Hmm.. then I think we can just drop the decrement if we drop the > >> increment in the for loop too, right? > > > > Oh yea, I forgot for loops could do that :) > > > Update pushed. The last "return match" occurs when we've reached the end of the string that's being checked. But if there are more characters in the regex to test for, we need to return 0. --- a/src/regex.c 2021-11-15 00:18:59.0 -0500 +++ b/src/regex.c 2021-11-15 00:20:55.0 -0500 @@ -114,5 +114,8 @@ return match; } } + while (rx[l]) + if (rx[l++] != '*') + return 0; return match; } ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] e16 regex bugfix
On Fri, 12 Nov 2021 17:48:50 +0100, Kim Woelders wrote: > On 11/11/21 21:24, Dennis Nezic wrote: > > Here's a small patch for regex.c > > > > Currently, in matches.cfg, "Title *bla ..." will match any title > > with "bla" in it ... but it should only match if the title ends in > > bla, right? > > > Right. > > Patch looks good to me - pushed to git. (Tiny improvement ... we don't need the "if (i>0)" test in that patch ... isafter() will never return 0 ... a simple decrement is fine.) ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] e16: better comment parsing in AclassConfigLineParse
Here's a slightly more robust inside of that for-loop, in case there are
escaped quotes outside a quoted pair (eg. quotes in filenames?), not
sure it's necessary to worry about these :p.
if (*s3 == '\'' && (s3 == s || *(s3 - 1) != '\\')) {
while (++s3https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] e16: better comment parsing in AclassConfigLineParse
On 26 Jun 19:53, Kim Woelders wrote: > On 2023-06-25 19:22, Dennis Nezic wrote: > > Currently comments in bindings.cfg are parsed dumbly (but efficiently) > > as the first occurrence of '#', even if it occurs in a pair of quotes. > > Attached is a more intelligent way that handles such quotes. > > > > "eesh exec" in a terminal, and the exec commands in the .menu files are > > both able to handle this, I guess because the shell is doing that > > parsing. > > > > Eg. > > eesh exec logger http://hello#world > > eesh exec logger 'http://hello #world' > > > Hi Dennis, > > Thanks for your input. I ended up doing this a bit differently and more > along the lines of what was done in similar situations elsewhere. > The primary difference is probably that the whitespace before a comment > should also be stripped. > Also, escapes(\) are not handled specially as they are not either in > similar cases elsewhere. Cool! This does what I need (html #links), although it doesn't properly handle nested quotes? - not sure if they should. Eg. command "argument with 'nested quote'" # a comment ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
[e-users] e16: better comment parsing in AclassConfigLineParse
Currently comments in bindings.cfg are parsed dumbly (but efficiently)
as the first occurrence of '#', even if it occurs in a pair of quotes.
Attached is a more intelligent way that handles such quotes.
"eesh exec" in a terminal, and the exec commands in the .menu files are
both able to handle this, I guess because the shell is doing that
parsing.
Eg.
eesh exec logger http://hello#world
eesh exec logger 'http://hello #world'
--- a/src/aclass.c 2023-06-25 12:32:51.0 -0400
+++ b/src/aclass.c 2023-06-25 12:47:03.0 -0400
@@ -692,12 +692,34 @@
ActionClass*ac = *pac;
Action *aa = *paa;
int len, len2;
-
- len = strcspn(s, "#\r\n");
+ char *s2, *s3;
+ intquoteclosed;
+
+ len = strcspn(s, "\r\n");
if (len <= 0)
return;
s[len] = '\0';
+ s2 = s - 1;
+ quoteclosed = 0;
+ while (!quoteclosed && (s2 = strchr(s2+1, '#'))) {
+ quoteclosed = 1;
+ for (s3=s; s3___
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users
