Re: [e-users] [E-devel] RFC - Dropping Xembed support from E20
2014-11-25 1:13 GMT+02:00 Carsten Haitzler ras...@rasterman.com: On Mon, 24 Nov 2014 16:13:48 +0200 cunnilinux himself cunnili...@gmail.com said: BTW, systray in 0.19.1 is almost usable (unlike 0.18.x 0.19.0). to put it in details, it starts to work normally after just one enlightenment restart (when some app appeared there yet). so i even stopped using tint2 crutch, since restarting enlightenment once is lesser evil IMNSHO. turn off xmbed support. :) to put long story short: this works if all necessary stuff for appindicator protocol support is installed. (i am on arch linux, so it isn’t by default, thus no icons displayed.) thanx Carsten for pointing me the following link that clarifies this issue in details: http://blog.martin-graesslin.com/blog/2014/06/where-are-my-systray-icons/ after installing/patching all that stuff, one can turn xembed support off in systray module preferences and enjoy new appindicator style icons menus (that look definitely better, btw). some apps that don't support appindicator at the moment still appear to tray xembed-style (no transparency, as for my setup), with no need to refresh or restart anything. working patch required for qt-4.8.6 can be found here: http://pkgs.fedoraproject.org/cgit/qt.git/plain/qt-everywhere-opensource-src-4.8.6-systemtrayicon.patch i don't have any qt5 stuff in my system at the moment, but should work out of the box. -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] [E-devel] RFC - Dropping Xembed support from E20
On 26/11/14 09:38, cunnilinux himself wrote: 2014-11-25 1:13 GMT+02:00 Carsten Haitzler ras...@rasterman.com: On Mon, 24 Nov 2014 16:13:48 +0200 cunnilinux himself cunnili...@gmail.com said: BTW, systray in 0.19.1 is almost usable (unlike 0.18.x 0.19.0). to put it in details, it starts to work normally after just one enlightenment restart (when some app appeared there yet). so i even stopped using tint2 crutch, since restarting enlightenment once is lesser evil IMNSHO. turn off xmbed support. :) to put long story short: this works if all necessary stuff for appindicator protocol support is installed. (i am on arch linux, so it isn’t by default, thus no icons displayed.) thanx Carsten for pointing me the following link that clarifies this issue in details: http://blog.martin-graesslin.com/blog/2014/06/where-are-my-systray-icons/ after installing/patching all that stuff, one can turn xembed support off in systray module preferences and enjoy new appindicator style icons menus (that look definitely better, btw). some apps that don't support appindicator at the moment still appear to tray xembed-style (no transparency, as for my setup), with no need to refresh or restart anything. working patch required for qt-4.8.6 can be found here: http://pkgs.fedoraproject.org/cgit/qt.git/plain/qt-everywhere-opensource-src-4.8.6-systemtrayicon.patch i don't have any qt5 stuff in my system at the moment, but should work out of the box. I've been talking to a guy from IRC and he's been working on sending the ubuntu nm-applet patches upstream, so that's will hopefully be there soon too. We are not getting rid of Xembed now, we'll get rid of it for e20 (this means current master in git, but that too, doesn't have to happen now). This means that we still have time to get things fixed in the relevant upstream projects. As I've said before, the best advice I could give you, is to pester the upstream projects to add appindicator support, and mention that many other desktop environments have made the switch too, this means, it's not an enlightenment issue. Furthermore, if their package is big enough, Ubuntu is most likely patching it, and no upstream project likes to be patched. :P -- Tom. -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] E19.1 Poweroff doesn't work
Had the same issue here with systemd and Enlightenment. If I selected Power Off from the E system menu, screen went blank, and the laptop would finally turn off after a minute. If I logged out of E, and did a poweroff from the console, the system shutdown quite rapidly. The issue was with systemd. While shutting down, the system would timeout trying to gracefully kill processes on the active login session. If you enable the systemd persistent journal, you'll see log messages from the previous shutdown, saying user@0.service stopping timed out. Killing. I beleve this bug report describes the issue: https://bugzilla.redhat.com/show_bug.cgi?id=1023820 That problem was there when I had systemd v208 installed. Now that I'm on systemd v215, from the latest Debian jessie/sid repos, all is good again. Hope that helps. dave.k In the year 2014, of the month of November, on the 25th day, Will Hopper wrote: I'm using 19.1 on debian testing, and have a similar issue, although i didn't use --emable-systemd at compile time. Shutting down via any method (telinit 0, power button, E desktop menu) causes the system to hang at the black screen for a while, but it eventually does shutdown after about probably 30-40 seconds of waiting. Does your system ever shut down, or does it hang indefinitely? On Tue, Nov 25, 2014 at 5:04 AM, mad_er...@aol.fr mad_er...@aol.fr wrote: On 11/25/2014 08:33 AM, mad_er...@aol.fr wrote: I compiled and installed successfully E19.1 on Debian Sid. It works but poweroff system button doesnt shutdown computer. I only get black screen in E. Precision I compiled libraries and e with these options: --prefix=/usr --enable-systemd -- Maderios -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] [E-devel] RFC - Dropping Xembed support from E20
On 26/11/14 10:44, Tom Hacohen wrote: On 26/11/14 09:38, cunnilinux himself wrote: 2014-11-25 1:13 GMT+02:00 Carsten Haitzler ras...@rasterman.com: On Mon, 24 Nov 2014 16:13:48 +0200 cunnilinux himself cunnili...@gmail.com said: BTW, systray in 0.19.1 is almost usable (unlike 0.18.x 0.19.0). to put it in details, it starts to work normally after just one enlightenment restart (when some app appeared there yet). so i even stopped using tint2 crutch, since restarting enlightenment once is lesser evil IMNSHO. turn off xmbed support. :) to put long story short: this works if all necessary stuff for appindicator protocol support is installed. (i am on arch linux, so it isn’t by default, thus no icons displayed.) thanx Carsten for pointing me the following link that clarifies this issue in details: http://blog.martin-graesslin.com/blog/2014/06/where-are-my-systray-icons/ after installing/patching all that stuff, one can turn xembed support off in systray module preferences and enjoy new appindicator style icons menus (that look definitely better, btw). some apps that don't support appindicator at the moment still appear to tray xembed-style (no transparency, as for my setup), with no need to refresh or restart anything. working patch required for qt-4.8.6 can be found here: http://pkgs.fedoraproject.org/cgit/qt.git/plain/qt-everywhere-opensource-src-4.8.6-systemtrayicon.patch i don't have any qt5 stuff in my system at the moment, but should work out of the box. I've been talking to a guy from IRC and he's been working on sending the ubuntu nm-applet patches upstream, so that's will hopefully be there soon too. We are not getting rid of Xembed now, we'll get rid of it for e20 (this means current master in git, but that too, doesn't have to happen now). This means that we still have time to get things fixed in the relevant upstream projects. As I've said before, the best advice I could give you, is to pester the upstream projects to add appindicator support, and mention that many other desktop environments have made the switch too, this means, it's not an enlightenment issue. Furthermore, if their package is big enough, Ubuntu is most likely patching it, and no upstream project likes to be patched. :P Oops, replied to this email before I read last night's patches. Apparently it's already removed from git. :) -- Tom. -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] Changing cursor size
On 11/26/2014 12:12 AM, Carsten Haitzler (The Rasterman) wrote: On Wed, 26 Nov 2014 00:02:02 + Peter Flynn pe...@silmaril.ie said: On 11/24/2014 11:11 PM, Carsten Haitzler (The Rasterman) wrote: [...] did you look at input - mouse ... there is size there. That's where it fails (ie has zero effect). works here. e's cursor changes size. The problem must be with my laptop screen driver or something non-e-related, in that case. No matter what I change, the mouse pointer and cursor remain the same...except when the pointer moves into the grab-zone at the edge of windows: then it momentarily changes to the size I asked for. Everywhere else, it's the default size for the theme. that's the point of the scale factor. you need everything 2x as big. scale factor is 2. cursor gets 2x the size too (if marked to scale). But that's my point. Let's say that 2x is the ideal size for my kind of work: windows that fit, menus etc that I can work with. All except the cursor/pointer, which is way too small for me to see properly. I don't want to use 3x or 4x: I just want to be able to enlarge the pointer size independently of the theme scale. I think the designer may have overlooked the fact that the visibility of the cursor on a laptop screen is poor when the mouse is small, because accelerated movement is not updated to the cursor during fast motion, so it effectively disappears from the screen. ? the cursor moves every single screen refresh. it doesnt go pause or drop movement when it accelerates (acceleration is actually just multiplying the delta x and y values by some number when they exceed some threshold). That may be so, but when I want to find the cursor on the screen (having perhaps not used it for a while, eg write writing or editing in Emacs, where I tend to use keystrokes), I wiggle the mouse in the hope that my eyes will spot some movement. But it takes a while before I can see anything moving, the cursor/arrow is so small. I suspect the problem is that theme designers are younger than I am, and have excellent eyesight :-) so they are unaware of the problem. ///Peter -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] Changing cursor size
On Wed, 26 Nov 2014 16:21:04 + Peter Flynn pe...@silmaril.ie said: On 11/26/2014 12:12 AM, Carsten Haitzler (The Rasterman) wrote: On Wed, 26 Nov 2014 00:02:02 + Peter Flynn pe...@silmaril.ie said: On 11/24/2014 11:11 PM, Carsten Haitzler (The Rasterman) wrote: [...] did you look at input - mouse ... there is size there. That's where it fails (ie has zero effect). works here. e's cursor changes size. The problem must be with my laptop screen driver or something non-e-related, in that case. No matter what I change, the mouse pointer and cursor remain the same...except when the pointer moves into the grab-zone at the edge of windows: then it momentarily changes to the size I asked for. Everywhere else, it's the default size for the theme. if everywhere else you mean over applications - they set their own cursors. e is not in charge of that. e's cursor is set on the root window and otherwise on its own content (titlebar etc.). are you using the default theme or some other theme? it coould be that your theme has changed just the standard normal e cursor but not the resize/move etc. cursors and thus the ones it didnt change work... that's the point of the scale factor. you need everything 2x as big. scale factor is 2. cursor gets 2x the size too (if marked to scale). But that's my point. Let's say that 2x is the ideal size for my kind of work: windows that fit, menus etc that I can work with. All except the cursor/pointer, which is way too small for me to see properly. I don't want to use 3x or 4x: I just want to be able to enlarge the pointer size independently of the theme scale. then you have a disagreement with the theme designer who designed everything to go together. let's take your argument further. scale 2x is fine for everything.. except checkboxes! i can't use them. let me scale those separately. but no. not just checkboxes. i find the close button too small - can i have just a separate scale for the close button? ... need i go on. what you are saying is that unless we go and provide a special scaling control for every single element of the screen, just in case you don't like the size of that one special thing... it's broken. sorry - i don't buy your argument. this basically requires an insanely large set of special cased scaling values to apply and the need to mark everything with a special scale class. that's just nuts. I think the designer may have overlooked the fact that the visibility of the cursor on a laptop screen is poor when the mouse is small, because accelerated movement is not updated to the cursor during fast motion, so it effectively disappears from the screen. ? the cursor moves every single screen refresh. it doesnt go pause or drop movement when it accelerates (acceleration is actually just multiplying the delta x and y values by some number when they exceed some threshold). That may be so, but when I want to find the cursor on the screen (having perhaps not used it for a while, eg write writing or editing in Emacs, where I tend to use keystrokes), I wiggle the mouse in the hope that my eyes will spot some movement. But it takes a while before I can see anything moving, the cursor/arrow is so small. I suspect the problem is that theme designers are younger than I am, and have excellent eyesight :-) so they are unaware of the problem. no - they just have better eyesight. not everyone magically becomes blind as a bat when they get older. :) even then... you seem specifically immune to detecting motion. regardless of clarity of eyesight, we are mentally attuned in our visual system to detecting motion - to hunt and to detect danger. even if it's small... it moves and thus is a warning. to me it seems you need less of a large cursor and more of a find my cursor feature. you are working around that by demanding a special huge cursor. huge cursors have a big downside - they take up lots of screen space (cover things up). you probably want something more like hit a hotkey and some big animation zooms in on where the cursor is now so you can't miss it. ///Peter -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com --
