[ANNOUNCE] awesome 3.5.6 released
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi everyone, as always, I will just say: It's been a while and so here is a new version Enjoy! Uli - -- awesome version 3.5.6 has been released. It is available from: tar.xz: http://awesome.naquadah.org/download/awesome-3.5.6.tar.xz md5: db1c31de752ab8e5f7aaa338718202af sha1: 24c7fa0494f740cdfd54721e7a6bb506bd09156b tar.bz2: http://awesome.naquadah.org/download/awesome-3.5.6.tar.bz2 md5: 81c7353932dd067cc7a222d9ede1cdd7 sha1: 0956438f90f25003692c360cfbc867181bd0a3ef number of changes - - 24 number of commiters - --- 7 shortlog - Uli Schlachter (14): Call AllowEvents after grabbed events on a drawin wbox: Make :find_widgets() easily accessible systray: Only intern the atom once systray: Only register/unregister when needed awful.widget.button: Override :set_image() to do the right thing drawin: Don't special-case moves drawin_update_drawing: Remove optimization for invisible drawins wibox.layout.base.rect_to_device_geometry: Fix for weird rotations Don't move clients on ConfigureRequests (FS#1030) Implement icon_pixmap and icon_mask from WM_HINTS (FS#1297) Don't set a background-pixel for our client frame windows Unmap minimized clients awful.mouse.finder: Remove rounded_corners call change codename Emmanuel Lepage Vallee (5): awful.tag.update: Fix identical tag set detection Add context to request::activate signal tag: Improve tag property::index support (FS#1229) tag.delete: Do not reset client tag when unnecessary layouts: Allow layouts to be invoked with fake data Evžen (1): fix(lib.awful.taglist): multiple tag selection Jason Yan (1): Fix check against clients in taglist. Sindre Føring Devik (1): FS#1278 - Menubar should check all standard directories findkiko (1): Vim style menu navigation in addition to arrow keys memeplex (1): Fix for FS#1293 diffstat - awesomeConfig.cmake| 2 +- draw.c | 25 ++ event.c| 18 ewmh.c | 3 ++- globalconf.h | 4 lib/awful/layout/suit/magnifier.lua.in | 5 +++-- lib/awful/layout/suit/tile.lua.in | 2 +- lib/awful/menu.lua.in | 8 +++ lib/awful/mouse/finder.lua.in | 6 -- lib/awful/rules.lua.in | 2 +- lib/awful/tag.lua.in | 83 +++- lib/awful/widget/button.lua.in | 21 --- lib/awful/widget/taglist.lua.in| 12 +-- lib/menubar/menu_gen.lua.in| 7 ++- lib/wibox/init.lua.in | 10 + lib/wibox/layout/base.lua.in | 16 +++--- objects/client.c | 119 +-- objects/client.h | 5 - objects/drawin.c | 14 + property.c | 14 + systray.c | 73 +-- 21 files changed, 305 insertions(+), 144 deletions(-) - -- - - Captain, I think I should tell you I've never actually landed a starship before. - - That's all right, Lieutenant, neither have I. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCAAGBQJUsYM8AAoJECLkKOvLj8sGmO0IAK/qwLQH/kT3NINTJDeedXCW DAZOniBpiPmO+rUC9yt4iFMbIrsg/cTQNsDjXgxZRcD5/QfFftVMHGc/jIDaJoWG ULziY9nX6rjJErtMxflOVSfCJDceGvs8CppL/0npvG5TPZQAXyGbX1sh+L+kkrVo fovQb2v9NdsQUugbYAzC2OY99kFhJOYMMiQgg2HNHyT9ck3HRvUWbmy7Qyeyv4eL 1AJqmDyQeQMkdVuZz7Xc+dHOCs72DVzyWhl+bGMI3AHUV+HUsfxaF+0Px6mjxOJ+ 9K+fp1PZj/9TNWDjWIj72O2lkgecCPzim1UEMJHK2JcHcCu465ksrXTT1nWJIY8= =GOdI -END PGP SIGNATURE- -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: Problems using coroutines with timer
Am 01.10.2014 um 14:40 schrieb Rob Hoelz:
Hello Awesome developers,
Hi Rob,
I've encountered an interesting behavior in Awesome while playing with
coroutines and timers (in an effort to develop a framework where one
can write synchronous-looking code that runs in an asynchronous
fashion). In short, I am able to make Awesome segfault when using
certain Awesome API functions from within a coroutine.
At least here it doesn't segfault, but die from an unprotected Lua error. That
may not make much of a difference to you, but to me it's quite a big one.
Here's some example code:
local sd = require 'sleep-dealer'
local notify = require('naughty').notify
sd.tuck_in(function()
for i = 1, 5 do
sd.sleep(1)
notify {
title = 'Alert!',
text = tostring(i),
}
end
end)
Urgh, complicated. Thanks for your simpler example from the other mail in this
thread:
local co = coroutine.create(function()
notify { title = 'Alert!', text = 'hello' }
end)
coroutine.resume(co)
[...]
When naughty.notify is called, a segfault occurs. I've determined that
this is because globalconf.L is used in a lot of Lua API calls.
Sometimes the Lua state passed into a function is really the state
corresponding to a coroutine, so the states don't match and Lua panics.
Yeah, but nothing crashes! :P
I bring this up here on the mailing list rather than fixing it myself
or filing a bug because I wanted to take the pulse of the developer
community on whether this is a true bug or if this is doing something
with Awesome that it wasn't intended for. If it's the latter, I can
let the matter rest; if it's the former, I would be happy to contribute
a patch that fixes the problem.
Sorry for not replying sooner. I've been busy. Thanks to you I learned something
about Lua and I already went ahead and fixed the problem. I went through all
uses of globalconf.L in awesome and checked them:
https://github.com/awesomeWM/awesome/commit/f957764e522253007dbb7ecf5abf869bd38b70e2
https://github.com/awesomeWM/awesome/commit/4cfea189f04e3133c87b36ef26229abaa4ab7eb2
https://github.com/awesomeWM/awesome/commit/d668268591c9854184583fffe58b945f8a9398d9
https://github.com/awesomeWM/awesome/commit/da15317ac2e299f3c1b3833b2c5b198d2d7df5ab
If anyone has a good idea on how to make it harder to introduce this kind of
error in the future, please speak up. I guess it would at least be a good idea
to never use globalconf.L directly and instead force the code to create a local
variable lua_State *L and use that. That way, there are less places where
globalconf.L is used plus the compiler warns if there are two variables with
name L in scope... I guess I'll implement that.
Cheers,
Uli
--
In the beginning the Universe was created. This has made a lot of
people very angry and has been widely regarded as a bad move.
--
To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: Documentation overhaul
Hi Ignas, sorry for not replying earlier, but I don't have much time. So what follows is just from a really quick look. On 19.05.2014 14:29, Ignas Anikevicius wrote: Hello everybody, I am playing with LDoc at the moment to convert Awesome docs to use markdown instead plain text/HTML mixture. Thanks a lot for looking into this. And you already seem to know more LDoc tricks than I ever did. Nice! I made a pull request on github as I thought it may be more flexible to comment code than the mailing list, but let me know if you think otherwise. So this is an early WIP, but since this is a big project and the documentation style is something to be decided by the whole community, I wanted to post it early rather than making very big changes later on. So far the community is just you. I guess since you are doing the work, you also get to decide how you want to do your work. At the moment I have only ported the awful.rules module and started with a few others. The generated documentation can be found on: http://gns-ank.github.io/awesome/doc/index.html The PR on github is on: https://github.com/awesomeWM/awesome/pull/37 That looks nice and better than what we have so far. No idea where to put it, but could you also write a short how to document tutorial? Something that points to the right parts of the LDoc documentation and adds some awesome-specifics. Perhaps some examples since I am confused about the @client[opt] that I am staring at right now, but it is easily understandable and obviously means an optional client parameter. The only thing that I saw so far that I didn't like is the @alias client in lib/awful/client.lua.in. The client docs are in luadoc/client.lua.in. However somewhere in Flyspray there is an issue about merging that with the C code and have LDoc generate the docs from there. Having the code with the docs makes it less likely that someone forgets to update them when changing the code. Since you are now my local LDoc expert, could you spent 10 minutes to look into how feasible this is and then just tell me sorry, we should stay with the fake lua files for documenting the C API. Cheers, Ignas Many, many thanks for looking into this area that was previously relatively neglected. Sorry for neglecting it. Uli -- - He made himself, me nothing, you nothing out of the dust - Er machte sich mir nichts, dir nichts aus dem Staub -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
[ANNOUNCE] awesome 3.5.5 relased
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Guys, could you please stop reporting bugs *after* a new release? Uli - -- awesome version 3.5.5 has been released. It is available from: tar.xz: http://awesome.naquadah.org/download/awesome-3.5.5.tar.xz md5: 48a00b747f0279e6164d8b7e9c964346 sha1: 7701fc6810b0a5b9ce9ba140d55ea55b9e59607f tar.bz2: http://awesome.naquadah.org/download/awesome-3.5.5.tar.bz2 md5: efba12d9fef5b663a104e19161e2bea4 sha1: 0c8e0c431ea40a14b5394cac269efedd558d3d1f number of changes - - 10 number of commiters - --- 3 shortlog - Uli Schlachter (7): imagebox: Don't try to scale by infinite (FS#1248) gears.color: Handle nil arguments correctly again naughty: Don't use the cache when loading icons (FS#1253) gears.surface: Handle the cache more intelligently awful.tag.move: Fix tag index setting awful.tag.setscreen: Check if old_screen == new_screen change codename again Emmanuel Lepage Vallee (2): Move 'surface_size' to gears.surface and make it public Make sure gears.color.create_png_pattern are being repeated Tin Benjamin Matuka (1): Allow reversing the icon order in systray diffstat - awesomeConfig.cmake | 2 +- lib/awful/tag.lua.in | 6 +++--- lib/gears/color.lua.in | 7 +-- lib/gears/surface.lua.in | 26 -- lib/gears/wallpaper.lua.in | 15 +++ lib/naughty.lua.in | 2 +- lib/wibox/widget/imagebox.lua.in | 1 + lib/wibox/widget/systray.lua.in | 10 -- systray.c| 15 --- 9 files changed, 54 insertions(+), 30 deletions(-) - -- A normal person is just someone you don't know well enough yet. - Nettie Wiebe -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCAAGBQJTR7PEAAoJECLkKOvLj8sGVy8IAKjy5yFytvIfYfvajKRON3y/ zOw/624c25RU9vZpzEoll3Scv2w6/iRuOaxcu3u3rkDG0HVB4qrz/vIxSP6AeiRn thdYI3ZPBZMYkkrw/mHUXsLyQIIcEtjLDAPLEoY5m0F0KmO8fzXwclI5o3RUgAI4 kiMaRsuYezERsMLf3AK7zX1YpZourSXFD83ssmGPmTzH3/bi3JqPGYeZx8sNnVcO 4NbY9Eh1i49pwzHpDkPvIW7gQg947PKawK7Q3wTnupdEAiXMx7P8bqzof+IetVX/ 5VkveH5krK4H2U2obcMNoZ8Pg5uGI5p0Yhkd3o32VrBpC+H+/S6GK9F31zvP320= =XpOu -END PGP SIGNATURE- -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: [ANNOUNCE] awesome 3.5.5 relased
On 11.04.2014 11:30, Gregor Best wrote: On Fri, Apr 11, 2014 at 11:20:07AM +0200, Uli Schlachter wrote: [...] could you please stop reporting bugs *after* a new release? [...] What about making a small announcement something like a week or two before actually releasing? Could be as simple as Guys, there's a new release ready, please check it out and report issues. It will go live in two weeks if there's nothing serious. As if anyone would actually test those... We have those RCs before major releases, e.g.: http://article.gmane.org/gmane.comp.window-managers.awesome/9581 http://article.gmane.org/gmane.comp.window-managers.awesome/9618 This resulted in some less important reports, e.g. FreeBSD has a too old GLib version. However, remember the shitstorm when 3.5 was released and people actually started trying to use it? OMG it's unusably slow Uli P.S.: A week ago I mentioned on IRC that I'd do a new release. AFAIK this is why Emmanuel submitted his two patches. -- Do Not Touch The Jellyfish! Get Me To The Hosp Immediately -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: [ANNOUNCE] awesome 3.5.5 relased
On 11.04.2014 20:36, Harvey wrote: Umm anyway you can get the fix for awful.util icon searching into here somewhere (see old post) Uhm, fix? What is the official channel for submitting a patch on this? Either sending the result of git format-patch origin/master.. to the awesome devel mailing list or submitting pull requests on github. H Uli On 04/11/2014 05:20 AM, Uli Schlachter wrote: Guys, could you please stop reporting bugs *after* a new release? Uli -- Are you preparing for another war, Plutarch? I ask. Oh, not now. Now we're in that sweet period where everyone agrees that our recent horrors should never be repeated, he says. But collective thinking is usually short-lived. We're fickle, stupid beings with poor memories and a great gift for self-destruction. -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: [PATCH] Reverse icon order
On 02.04.2014 15:38, Tin Benjamin Matuka wrote:
Hello list,
I finally created a patch for something that's been bugging me for a very
long time: reversing the order of icons in the systray. Default behaviour
stays the same as before, only now you have an option to reverse the order.
Easiest way to configure it is to create the widget like this:
wibox.widget.systray({ reverse = true })
Your patch doesn't actually work like this. Well, ok, this would reverse the
systray icon order, but only because a table is considered true...
Anyway: Merged as commit d441030ba.
Uli
--
Do you know that books smell like nutmeg or some spice from a foreign land?
-- Faber in Fahrenheit 451
--
To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
[ANNOUNCE] awesome 3.5.4 relased
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi everyone, it's been a long time already and here it finally is! Uli - -- awesome version 3.5.4 has been released. It is available from: tar.xz: http://awesome.naquadah.org/download/awesome-3.5.4.tar.xz md5: 9d52a26bfbc142ace5427bfb55010359 sha1: 27f9c5901ff28c401f707bad938ff2171f355af3 tar.bz2: http://awesome.naquadah.org/download/awesome-3.5.4.tar.bz2 md5: d5177d66b1011d9d98d3aa805ace2dc1 sha1: 4e882816d5dfd64f5a3e5a7ee181078e377c04da number of changes - - 8 number of commiters - --- 1 shortlog - Uli Schlachter (8): gears.surface: Cache files from disk gears.color: Add a pattern cache awful.tooltip: Small reorganization awful.tooltip: Add (and use) :set_markup() function systray: Don't set WM_STATE on embedded windows (FS#1246) Revert root: Make sure cairo doesn't cache our temporary connection (FS#1245) wibox.drawable: Assert that no cairo error occurred change codename diffstat - awesomeConfig.cmake | 2 +- lib/awful/tooltip.lua.in | 37 + lib/gears/color.lua.in| 15 --- lib/gears/surface.lua.in | 17 - lib/wibox/drawable.lua.in | 3 +++ root.c| 5 - systray.c | 1 - 7 files changed, 53 insertions(+), 27 deletions(-) - -- - - Buck, when, exactly, did you lose your mind? - - Three months ago. I woke up one morning married to a pineapple. An ugly pineapple... But I loved her. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCAAGBQJTO8X8AAoJECLkKOvLj8sG9iMH/0qxXxDjKHNf/l4JGT9quzCT upA9YKohpU2e+7Tlk0KcQMBGDveVhbb6q0WmIEv0UuO3X9diQfRxJ0+nYnejXQ1L GdSAWSvBLEJ+XM/84Xultcl4s6L12Y8y7a5AZYLS4fKPZZ8BUVAw00TqPJ6SNgvN 4GvpKIOWd+gQ2EmmN7Ok731Ov97O8N3qbU+JZIgXLxzzlckKmgR0WRsrjQT9PRUt MQF6bE0aWMUugwHGWk6t2bWqdWAXTD7wqjxh8gCokNHrxLtML7EZDHiMvVod84lV iB/UsxUZq4ddGwzV7sbFOVAiTLmX7K29trPh7cmiZnT8zYhSBUq1/ltOpPjKnh0= =gSGO -END PGP SIGNATURE- -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: [PATCH] Reverse icon order
On 02.04.2014 15:38, Tin Benjamin Matuka wrote:
Hello list,
I finally created a patch for something that's been bugging me for a very
long time: reversing the order of icons in the systray. Default behaviour
stays the same as before, only now you have an option to reverse the order.
Easiest way to configure it is to create the widget like this:
wibox.widget.systray({ reverse = true })
Uhm, why?
Isn't the order of icons in the systray not-all-that-reliable anyway? If you
start multiple things at the same time which both create a systray icon, the
result will be random. Otherwise, just start things the other way around?
Uli
--
To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
[ANNOUNCE] awesome 3.5.3 released
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hey everyone, due to just because, here is a new release for you to enjoy. Now with three times as many commits as 3.5.2 had to its predecessor! So what changed? Take a look at the git history. - - Lots of small fixes... - - Full SHAPE support in the C code... - - More fixes... - - The new xproperty API which we have thanks to Elv1313 which allows accessing X11 properties from Lua which can be used e.g. to save information across a restart... - - Some fixes for excessive redraws (and black flickering)... If you have a problem with clients not being raised when they appear, see http://git.naquadah.org/?p=awesome.git;a=commitdiff;h=de46670c8ce339e7ddfaf5651e455d9d4c203536 In case you maintain a distro package for awesome: Our minimum LGI dependency is 0.7.0 to avoid a LGI bug Enjoy! Uli P.S.: A big thanks! to Daniel Hahler and Elv1313 for lots of great work! P.P.S.: If the person who helped me with the release name reads this, say so. You know that I mean you. - -- awesome version 3.5.3 has been released. It is available from: tar.xz: http://awesome.naquadah.org/download/awesome-3.5.3.tar.xz md5: 730a5852cc61f5561588a1b788ec861e sha1: 9ac67fd470215c04016eaa93f8b9e6a1cc360754 tar.bz2: http://awesome.naquadah.org/download/awesome-3.5.3.tar.bz2 md5: 2dbe0edf536048b3b89f2f9060311851 sha1: 53526451853d9ca04a45240a711c363ad2a09747 number of changes - - 99 number of commiters - --- 11 shortlog - Uli Schlachter (71): luadoc: Document screen outputs Print libxcb error codes for broken connections tasklist: Add default colors for broken themes Really ignore loops in transient_for (FS#1124) awful.tag.delete: Deactivate tags awful.menu: Add missing local declaration menubar: Fix API docs awful.tag.viewmore: Make screen optional (FS#1203) Finish C-side support for window shapes (FS#1051) awful.menu.clients: Fix API (FS#1200) naughty: fix ldoc Add awesome.composite_manager_running wibox.drawable: Cache the wallpaper client: Add c.blob property Improve the check for another window manager Update the luadoc for the C API client: Add request::activate signal (FS#848) awful.ewmh: Correctly handle bw change for maximized clients client: Emit property::screen after geometry awful.ewmh: Enforce client geometry (FS#764,FS#1216) root.wallpaper: Cleanup and correctness fixes Revert awful.ewmh: Enforce client geometry (FS#764,FS#1216) mouse.screen: Lie when we have no clue where the pointer is Measure the time a main loop iteration takes Update fields for capi.awesome in C comment Improve fatal signal handling awful.util.spawn*: Remove obsolete screen argument Make objects properly inherit signals from classes Add awesome.register_xproperty (FS#1212) Revert client: Add c.blob property Fix handling of _NET_CURRENT_DESKTOP messages (FS#1219,FS#1217) xproperty: Don't limit property lengths spawn: Don't try to spawn with empty argv (FS#1225) awesome.spawn(): Check table arguments better spawn: Remove useless argv[0] calculation drawin: Inline drawin_init() into its only caller drawin: Don't unconditionally redraw when made visible awful.tooltip: Work with all gears.colors as foreground drawin: Only redraw on move with translucent background Redraw titlebars more intelligently Fix cairo surface memory leak drawable: Add pixmap member root: Make sure cairo doesn't cache our temporary connection Add awesome.startup awful.client.movetoscreen: Don't untag clients completely (FS#1196) ewmh: Factor out common code into a helper function EWMH: Ignore invalid _NET_WM_DESKTOP ewmh: Use client_set_sticky() for making clients sticky EWMH: Handle _NET_WM_DESKTOP in lua Drawable: Ignore exposes when we have nothing to draw Fixup indentation Bump minimum lgi dependency to 0.7.0 awful.rules: Emit request::activate on the client luaa: Remove lots of unused code awful.client: Add marked and unmarked signals (FS#1227) imagebox: Avoid division by zero wibox.layout.base.fit_widget: Enforce sane width and height window: Factor out helper functions for xproperties awesome: Add get_* and set_xproperty xproperty: Emit on awesome for root window properties rc.lua: Raise all clients by default (regression, FS#1234) Make debug::index::miss and newindex work on classes and all objects awesome.startup_errors: Never emit debug::index::miss beautiful: Don't use non-existant API gears.color.create_opaque_pattern: Fix for SurfacePatterns (FS#1236) drawin: Correctly add property::shape_* signals Revert Set c.screen in ewmh.tag and before tags in rules.execute
Re: Error while drawing widget: /usr/local/share/awesome/lib/wibox/layout/base.lua:39: table index is NaN
Hi, either of the following commits should fix this. The first one fixes the code that produced this NaN, the second one makes sure that we (hopefully) handle NaNs correctly: http://git.naquadah.org/?p=awesome.git;a=commitdiff;h=0ac80ddf30cf5fdee294df18e69fb632befc47d5 http://git.naquadah.org/?p=awesome.git;a=commitdiff;h=db0014540691a11f98d7794ff4c22acc31e06d70 On 19.03.2014 07:10, John Kha wrote: Further investigation shows that when base.fit_widget is called on line 69, it is returning a NaN to w. Yeah, and arithmetic involving a NaN always results in a NaN again, so... On Wed, Mar 19, 2014 at 12:51 AM, John Kha sir...@gmail.com wrote: [...] local w, h = base.fit_widget(v, width, height) ...w and h are NaN here which means that... local in_dir, max if self.dir == y then max, in_dir = w, h height = height - in_dir else in_dir, max = w, h width = width - in_dir ...width becomes a NaN, too and thus... end if max used_max then used_max = max end used_in_dir = used_in_dir + in_dir io.stderr:write(Break?\n) if width = 0 or height = 0 then ...this is false, because comparisons involving NaN are always(*) false. if self.dir == y then used_in_dir = orig_height else used_in_dir = orig_width end io. stderr:write Break.\n break end end if self.dir == y then return used_max, used_in_dir end return used_in_dir, used_max end [...] As you can see, the condition should be true as inner width is 0, but you never get the Break. -- John C. Kha Thanks a lot in looking into this and helping me figure it out! Cheers, Uli (*): $ lua -e 'a = 0/0 print(a, a == a)' -nanfalse -- Bruce Schneier can read and understand Perl programs. -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: [PATCH] Prefixes in tasklist and titlebars
Hi again, On 04.02.2014 17:22, Wojciech Zygmunt Porczyk wrote: On Tue, Feb 04, 2014 at 10:57:03AM +0100, Uli Schlachter wrote: On 04.02.2014 10:52, Uli Schlachter wrote: On 03.02.2014 23:32, Wojciech Zygmunt Porczyk wrote: Would you like to apply this (attached) patch? It makes possible to prepend some arbitrary string to client's name in taskbar and titlebar, for example to specify c.machine or c.class for writing rules. Uhm, isn't this already possible today? [...] Sorry, I missed the tasklist part. Still, I'd rather fix this properly (whatever that means) instead of adding a special case for prefixes. Sorry. I guess that this part of awful was better in 3.4... Nah, i wrote it on 3.4 and ported to 3.5 (s/add_sig/connect_sig/). Git blame says tasklist assembly sits there (with minimal touches) since at least 2009, maybe earlier. I agree this is special case. Still, what would be a proper fix? User-configurable format function (like in almost all contrib widget libraries), which would accept client object and return text to display? I just opened the following issue[0] which is partly motivated by this patch and partly motivated by need moar flexibilities. Hopefully this will get done eventually and you can use this. Feel free to complain if I missed something. Together with the rc.lua-patch that I wrote in an earlier reply, that should make it possible to include c.machine in both the titlebar and the tasklist. Cheers, Uli [0]: https://awesome.naquadah.org/bugs/index.php?do=detailstask_id=1230 -- A learning experience is one of those things that say, 'You know that thing you just did? Don't do that.' -- Douglas Adams -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: Fwd: [PATCH] Fixed an issue with wibox-layout-align
Hi again, On 05.01.2014 00:56, John Kha wrote: On Fri, Jan 3, 2014 at 10:52 AM, Uli Schlachter psyc...@znc.in wrote: [...] I added another patch (0004) that kind of explains the code in comments (not for committing, just for looking at). Also, clearer screenshot. Sorry, that patch is still in. [...] -- 99 little bugs in the code 99 little bugs in the code Take one down, patch it around 117 little bugs in the code -- @irqed So we now have a 3.5 branch in git and this patch will aim for 3.6. Let's see if anyone tests this stuff before a release and complains. Cheers, Uli who now has to fix up his own config -- For saving the Earth.. and eating cheesecake! -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: [PATCH] prompt.lua added possibility to delete history entries
Hi, On 09.03.2014 15:53, Massimiliano Brocchini wrote: [...] Anyway, git doesn't like your patch. I end up with this commit message, could you... dunno, send me the file differently? I'm sending the patch again, please let me know if this doesn't work, I'll try with here document. This one works a lot better. Merged thanks! [...] If this gets accepted and committed, you are invited to remind me to document all keyboard shortcuts and their behaviour in a wiki page once a new release will be out. Feel free to add that to the ldoc comments in the source. :-) Done, but was not sure whether to use an HTML table or just lists. Since tables are not used in any other ldoc, I opted for lists. I did a minor change to this: +-- licodeCTRL+UP/code: ZSH down line or search, matches any history entry starting with search term/li You have two entries described CTRL+UP as going up and down. The version in git doesn't. ;-) Cheers, Uli -- For saving the Earth.. and eating cheesecake! -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: [PATCH] prompt.lua added possibility to delete history entries
Hi, On 02.03.2014 18:32, Massimiliano Brocchini wrote: i like to keep only correct command in my history entries and I didn't want to edit cache files anymore. Attached patch adds CTRL+DELETE shortcut to prompt.lua to delete visible command from history. I almost like the patch (except for the missing line breaks in the commit message and the new call to history_save() for which I can't find a reasonable explanation; yeah, we could have changed the history when Esc is pressed, but still this code seems weird...). Anyway, git doesn't like your patch. I end up with this commit message, could you... dunno, send me the file differently? commit 42ec82ce564ab5e867b5560f5b491b8ed8d4b50b Author: Massimiliano Brocchini massimiliano.brocch...@gmail.com Date: Sun Mar 2 18:32:21 2014 +0100 prompt.lua added possibility to delete history entries --001a1135e0f4e680b904f3a30e26 Content-Type: text/plain; charset=ISO-8859-1 Hi all, i like to keep only correct command in my history entries and I didn't want to edit cache files anymore. Attached patch adds CTRL+DELETE shortcut to prompt.lua to delete visible command from history. If this gets accepted and committed, you are invited to remind me to document all keyboard shortcuts and their behaviour in a wiki page once a new release will be out. Ciao, Massi div dir=ltrHi all,divbr/divdiv stylei like to keep only correct command in my history entries and I didn#39;t want to edit cache files anymore./divdiv stylebr/divdi v styleAttached patch adds CTRL+DELETE shortcut to prompt.lua to delete visible command from history./div div stylebr/divdiv styleIf this gets accepted and committed, you are invited to remind me to document all keyboard shortcuts and their behaviour in a wiki page once a new release will be out./divdiv stylebr /div div styleCiao,/divdiv styleMassi/div/div From 434d6845c41c7c833f3d4fd984637eb2ef933d19 Mon Sep 17 00:00:00 2001 From: Massimiliano Brocchini massimiliano.brocch...@gmail.com Date: Sun, 2 Mar 2014 18:34:22 +0100 Subject: [PATCH 3/3] prompt: CTRL+DELETE deletes history entries Pressing CTRL+DELETE removes the visible history entry, if any, then moves to the next history entry (like pressing DOWN would do). If the last history entry is removed the previous one is shown in the prompt (like pressing UP would do). CTRL+DELETE works on history entries only: i.e. it has no effect on a command entered but not executed yet. To implement above behaviour I added saving history table to file on Escape key press. Signed-off-by: Massimiliano Brocchini massimiliano.brocch...@gmail.com If this gets accepted and committed, you are invited to remind me to document all keyboard shortcuts and their behaviour in a wiki page once a new release will be out. Feel free to add that to the ldoc comments in the source. :-) Uli -- Q: Because it reverses the logical flow of conversation. A: Why is putting a reply at the top of the message frowned upon? -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: [PATCH] prompt.lua search in history minor fixes
Hi, On 22.02.2014 13:03, Massimiliano Brocchini wrote: please find attached two patches to prompt.lua to make search in history (CTRL+R/S or CTRL+UP/DOWN) more consistent / predictable: - the first one changes the search_term definition, when dealing with CRTL+UP/DOWN, to be always a substring of the current command. This makes behaviour consistent when starting from a user typed string or an existing command in the history - the second one enables exact string match (string.find third parameter set to true) to make search work with special characters. This is useful especially for Run Lua code prompt. Thanks, both applied and pushed (after moving some information from your mail into the commit messages...). Uli -- - Captain, I think I should tell you I've never actually landed a starship before. - That's all right, Lieutenant, neither have I. -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: [PATCH] Prefixes in tasklist and titlebars
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, On 03.02.2014 23:32, Wojciech Zygmunt Porczyk wrote: Would you like to apply this (attached) patch? It makes possible to prepend some arbitrary string to client's name in taskbar and titlebar, for example to specify c.machine or c.class for writing rules. Uhm, isn't this already possible today? In your rc.lua, go to the line that creates the titlewidget and add afterwards: middle:add(wibox.widget.textbox([ .. c.machine .. ])) Either approach would require changes to the rc.lua to enable, but this one needs no changes to awful. (Also, I don't think that c.machine can realistically change while a program is running and thus I left out the update logic). This might result in slightly different visual results since the text is in two different textboxes, although I doubt that anyone would notice. Disclaimer: I work on Qubes OS project. http://www.qubes-os.org/. We have system comprised of virtual machines and we'd like to mark each window with its VM name. I seek to include awesome as third WM option (after KDE and XFCE) and it went quite smooth in rc.lua besides this one specific intrusion into awful. Sounds interesting! Cheers, Uli - -- Why make things difficult, when it is possible to make them cryptic and totally illogical, with just a little bit more effort? -- A. P. J. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCAAGBQJS8LhlAAoJECLkKOvLj8sG9b8IAKeGLvJNfi4D/WLXf9GITLZM EccUhFuPabkBIgHrhkHHj8pGWT/D+mq7GefhM1Qftk5MCDrmh3VtxPaJREPK0l1p /sfNaPvW6BtYXmvEN5+/feSGWW4A6qxdKnAkIxXLbjY+J5D9xacMP/SDoOnUOkuX ysnNk4qPUdlk2BFNNVFk+ZRYwh+wNCyoqLoomQf/MCPhV6X5Pp2628EoEq7t1IVH iFE6prahdTCCjBKpvnTzS9uk/lqEdqP7KZbYvJm8QxlVNtzyIN90mK1i5bLMlWHN 7ypPq+BChsRs6nt8cdoYR7exduzNi3rqbivjnXkqojLfvpRus0JfBZY1zjXmrqc= =ztv/ -END PGP SIGNATURE- -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: [PATCH] Prefixes in tasklist and titlebars
Hi, On 04.02.2014 10:52, Uli Schlachter wrote: On 03.02.2014 23:32, Wojciech Zygmunt Porczyk wrote: Would you like to apply this (attached) patch? It makes possible to prepend some arbitrary string to client's name in taskbar and titlebar, for example to specify c.machine or c.class for writing rules. Uhm, isn't this already possible today? [...] Sorry, I missed the tasklist part. Still, I'd rather fix this properly (whatever that means) instead of adding a special case for prefixes. Sorry. I guess that this part of awful was better in 3.4... Uli -- Why make things difficult, when it is possible to make them cryptic and totally illogical, with just a little bit more effort? -- A. P. J. -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: [PATCH] layouts: spiral: Avoid gaps between windows
On 20.01.2014 22:32, Fabienne Ducroquet wrote: Le lundi 20 janvier 2014, Uli Schlachter a écrit : Hi, Ah, ok. So the k n was replaced with k ~= n which should do the same thing. I’m not sure why I changed that but it should do the same thing. Also, this now also changes wa.width or wa.height in cases where it previously wouldn't have... Why? That’s what I tried to explain in the commit message: with the previous code, for instance for the third window the width was divided by two and wa.height stayed the same, but it should not: if the total height available is 1001 pixels, the height of the second window should be 500 pixels, and 501 for the third (or the reverse). It’s not possible to find the height of the third window from the height of the second window because if the height of the second window is 500 pixels, the total height could be either 1000 or 1001 pixels. That’s why I store the size of the previous window (and I initialized old_height at 2 * wa.height so that the case k == 1 would not be different from the others). if k % 4 == 0 and _spiral then wa.x = wa.x - wa.width -elseif k % 2 == 0 or -(k % 4 == 3 and k n and _spiral) then -wa.x = wa.x + wa.width +elseif k % 2 == 0 then +wa.x = wa.x + old_width +elseif k % 4 == 3 and k n and _spiral then +wa.x = wa.x + math.ceil(old_width / 2) end The last case of the old code needs to be split into two... Before we had wa.width, now we have old_width or ceil(old_width / 2). That's definitely not the same value as before, so this must be changing something else. Is this fixup for the previous hunk's this now also changes [..] in cases where it previously wouldn't have? If yes, then this makes this code definitely harder to understand and I have no clue why this is actually correct. Since I don't understand what you are doing, I cannot really give any good suggestions. Perhaps it would help to add some comments that explains some of the cases (e.g. k%2==0 = we are splitting the available space horizontally) and then also explains why these specific fixups are needed? You need to draw pictures of the layouts with 2 to at least 5 or 6 windows to understand what’s happening, I’m not sure comments would help: I can repeat what I’m doing but to understand why I’m doing it you have to look at the pictures (this was already true before). For the dwindle layout it’s rather simple: – If k is odd wa.x does not change. – If k is even wa.x has to be augmented by the width of the previous window, so old_width. With the old code old_width and wa.width would have been equal. For the spiral layout: – If k % 4 == 1 wa.x does not change. – If k % 4 == 3 and it’s not the last window, wa.x has to be augmented by the width of the following window. The previous code used wa.width because it considered that the third and fourth windows had the same width for instance. At that point in the code we have wa.width == math.floor(old_width / 2), the width of the following window will be the remaining width i.e. math.ceil(old_width / 2). – If k % 4 == 0 wa.x has to be diminished by the width of the current window. – If k % 4 == 2 wa.x has to be augmented by the width of the previous window, same thing as for k even in the dwindle layout. Note that the order of the conditions matters: k % 2 == 0 is equivalent to (k % 2 == 0 and not _spiral) or (k % 4 == 2 and _spiral), because the case k % 4 == 0 and _spiral is already treated. For wa.y the reasoning is similar. Sold! commit 94a8c725968535fd74fe399846f193ecc6ce4c29 -- Bruce Schneier can read and understand Perl programs. -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: [PATCH] layouts: spiral: Avoid gaps between windows
Hi,
On 18.01.2014 16:12, Fabienne Ducroquet wrote:
When an area is split in two, for example horizontally, one of the windows
should have height math.floor(previous height / 2) and the other
math.ceil(previous height / 2), to be certain that no gaps are left between
the
windows.
For instance, if the first window has height h and the second window has
height
math.floor(h / 2), the height of the third window should be math.ceil(h / 2)
instead of the same as for the second window.
So to compute the size of window n + 1 it’s necessary to remember the size of
window n - 1 as well as that of window n.
So far this makes sense. Now I just expect some code that adds a call to ceil()
in the right place.
Signed-off-by: Fabienne Ducroquet fabi...@gmail.com
---
lib/awful/layout/suit/spiral.lua.in | 30 +++---
1 file changed, 19 insertions(+), 11 deletions(-)
diff --git a/lib/awful/layout/suit/spiral.lua.in
b/lib/awful/layout/suit/spiral.lua.in
index f96a7d1..188977c 100644
--- a/lib/awful/layout/suit/spiral.lua.in
+++ b/lib/awful/layout/suit/spiral.lua.in
@@ -7,6 +7,7 @@
-- Grab environment we need
local ipairs = ipairs
+local math = math
-- awful.layout.suit.spiral
local spiral = {}
@@ -15,28 +16,35 @@ local function do_spiral(p, _spiral)
local wa = p.workarea
local cls = p.clients
local n = #cls
+local old_width, old_height = wa.width, 2 * wa.height
for k, c in ipairs(cls) do
-if k n then
-if k % 2 == 0 then
-wa.height = wa.height / 2
-else
-wa.width = wa.width / 2
+if k % 2 == 0 then
+wa.width, old_width = math.ceil(old_width / 2), wa.width
+if k ~= n then
+wa.height, old_height = math.floor(wa.height / 2), wa.height
+end
+else
+wa.height, old_height = math.ceil(old_height / 2), wa.height
+if k ~= n then
+wa.width, old_width = math.floor(wa.width / 2), wa.width
end
end
Ah, ok. So the k n was replaced with k ~= n which should do the same
thing. Also, this now also changes wa.width or wa.height in cases where it
previously wouldn't have... Why?
if k % 4 == 0 and _spiral then
wa.x = wa.x - wa.width
-elseif k % 2 == 0 or
-(k % 4 == 3 and k n and _spiral) then
-wa.x = wa.x + wa.width
+elseif k % 2 == 0 then
+wa.x = wa.x + old_width
+elseif k % 4 == 3 and k n and _spiral then
+wa.x = wa.x + math.ceil(old_width / 2)
end
The last case of the old code needs to be split into two...
Before we had wa.width, now we have old_width or ceil(old_width / 2). That's
definitely not the same value as before, so this must be changing something
else.
Is this fixup for the previous hunk's this now also changes [..] in cases where
it previously wouldn't have? If yes, then this makes this code definitely
harder to understand and I have no clue why this is actually correct.
Since I don't understand what you are doing, I cannot really give any good
suggestions. Perhaps it would help to add some comments that explains some of
the cases (e.g. k%2==0 = we are splitting the available space horizontally) and
then also explains why these specific fixups are needed?
if k % 4 == 1 and k ~= 1 and _spiral then
wa.y = wa.y - wa.height
-elseif k % 2 == 1 and k ~= 1 or
-(k % 4 == 0 and k n and _spiral) then
-wa.y = wa.y + wa.height
+elseif k % 2 == 1 and k ~= 1 then
+wa.y = wa.y + old_height
+elseif k % 4 == 0 and k n and _spiral then
+wa.y = wa.y + math.ceil(old_height / 2)
end
local g = {
Same thing here, since this is (mostly) the same code as the hunk before.
Uli
--
Because I'm in pain, he says. That's the only way I get your attention.
He picks up the box. Don't worry, Katniss. It'll pass.
He leaves before I can answer.
--
To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: [awesome bugs] #1200 - Cannot change menu.clients width through rc.lua
On 13.01.2014 14:55, Rocco Aliberti wrote: Removed useless line in awful.menu.clients : local args = args or args1 as requested on irc channel. Thanks! Merged as commit 64dc578efce8e35beb7e74aed0184f5302a0dc80. Uli -- Because I'm in pain, he says. That's the only way I get your attention. He picks up the box. Don't worry, Katniss. It'll pass. He leaves before I can answer. -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: margin layout, add color parameter and draw a colored border
From 6e061a9a5f37fed5358c5d8179a57fb54b309032 Mon Sep 17 00:00:00 2001
From: Rocco Aliberti ralibert...@gmail.com
Date: Wed, 15 Jan 2014 23:47:50 +0100
Subject: [PATCH] wibox.layout.margin: Add margins color parameter
Now the margin layout can color the margins, drawing a bordered widget.
Added also set_color method.
Documentation updated.
Additions to the draw method code written by Uli Schlachterpsyc...@znc.in
Let's make this:
This adds a :set_color() method so that the margin layout can color the
margins, drawing a bordered widget.
(No need to mention the docs nor me :-P)
---
lib/wibox/layout/margin.lua.in | 33 +
1 file changed, 29 insertions(+), 4 deletions(-)
diff --git a/lib/wibox/layout/margin.lua.in b/lib/wibox/layout/margin.lua.in
index 1a278d0..1e86921 100644
--- a/lib/wibox/layout/margin.lua.in
+++ b/lib/wibox/layout/margin.lua.in
@@ -9,6 +9,8 @@ local type = type
local setmetatable = setmetatable
local base = require(wibox.layout.base)
local widget_base = require(wibox.widget.base)
+local gcolor = require(gears.color)
+local cairo = require(lgi).cairo
-- wibox.layout.margin
local margin = { mt = {} }
@@ -19,11 +21,22 @@ function margin:draw(wibox, cr, width, height)
local y = self.top
local w = self.right
local h = self.bottom
+local color = self.color
if not self.widget or width = x + w or height = y + h then
return
end
+if color then
+cr:save()
+cr:set_source(gcolor(self.color))
I don't like the gears.color() call here. If it errors out, we get ungood
error messages and this creates a temporary object unnecessarily. I would just
save the pattern that gcolor() returns directly (See below).
+cr:rectangle(0, 0, width, height)
+cr:rectangle(x, y, width - x - w, height - y - h)
+cr:set_fill_rule(cairo.FillRule.EVEN_ODD)
+cr:fill()
+cr:restore()
+end
+
base.draw_widget(wibox, cr, self.widget, x, y, width - x - w, height - y
- h)
end
@@ -51,19 +64,28 @@ function margin:set_widget(widget)
self._emit_updated()
end
Set all the margins to val.
-function margin:set_margins(val)
+--- Set all the margins to val, and their color to color
+function margin:set_margins(val, color)
self.left = val
self.right = val
self.top = val
self.bottom = val
+self.color = color
self:emit_signal(widget::updated)
end
:set_margins() IMO has nothing to do with the color. Why should this be here? I
would just remove it.
Reset this layout. The widget will be unreferenced and the margins set
to 0.
+--- Set the margins color to color
+function margin:set_color(color)
+self.color = color
+self._emit_updated()
+end
As mentioned above: Please make this:
self.color = color and gcolor(color)
(The and is there so that :set_color(null) erases the color instead of setting
a black color)
(Oh and if gears.color() doesn't like the argument, the :set_color() call will
error out instead of breaking the widget by making it error out from its :draw()
method).
+--- Reset this layout. The widget will be unreferenced, the margins set to 0
+-- and the color erased
function margin:reset()
self:set_widget(nil)
self:set_margins(0)
+self:set_color()
:set_color(nil), please.
end
--- Set the left margin that this layout adds to its widget.
@@ -104,7 +126,8 @@ end
-- @param right A margin to use on the right side of the widget (optional)
-- @param top A margin to use on the top side of the widget (optional)
-- @param bottom A margin to use on the bottom side of the widget (optional)
-local function new(widget, left, right, top, bottom)
+-- @param color A color for the margins (optional)
+local function new(widget, left, right, top, bottom, color)
local ret = widget_base.make_widget()
for k, v in pairs(margin) do
@@ -122,6 +145,8 @@ local function new(widget, left, right, top, bottom)
ret:set_top(top or 0)
ret:set_bottom(bottom or 0)
+ret:set_color(color)
+
if widget then
ret:set_widget(widget)
end
-- 1.8.4
If you are OK with these changes, I would just change the patch to my liking
locally and commit it. Alternatively, feel free to submit a new version.
Uli
--
Because I'm in pain, he says. That's the only way I get your attention.
He picks up the box. Don't worry, Katniss. It'll pass.
He leaves before I can answer.
--
To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: Fwd: [PATCH] Fixed an issue with wibox-layout-align
Hi, On 05.01.2014 00:56, John Kha wrote: On Fri, Jan 3, 2014 at 10:52 AM, Uli Schlachter psyc...@znc.in wrote: On 02.01.2014 09:25, John Kha wrote: Start awesome with the default config and open any client. The tasklist entry for this client will only be as wide as the name of the client. It will not cover all of the align layout's middle space. This is because awful.widget.tasklist uses a flex layout and that layout now asks for less space. The align layout centers the middle widget in the space that is left (and only assigns it as much space as it asked for). Ideas? Patch 0001 If the draw function ignores the fit results for the middle widget, the expected behavior is back. Patch 0002 Makes the draw function optionally start with the middle widget and force the outside widgets to expand or contract to take up the remaining space (outside option) or just draw the outside widgets to their requested size in the remaining space (none option). The old functionality, drawing the first and last widgets, then expanding the middle widget to take the remaining space is still the default (inside option). The attached screenshot was made by pasting the attached align_test.lua into the default rc.lua. [...] Back to your patch: I am mainly trying to convince myself that both patches together don't change the default behavior and old code continues to work. But things turn out to be complicated and I don't have any good ideas on how to simplify this. One thing I noticed is that the centering behavior of the old code isn't really back. The only expand mode that centers the middle widget is none, but the default is inside which should be the same behavior as after your first patch. I think... The inside behavior ends up doing the same thing as your original code, albeit in a slightly different way. The old code: 59 w, h = width, size_limit - size_first - size_third 60 local real_w, real_h = base.fit_widget(self.second, w, h) 61 x, y = 0, size_first + h / 2 - real_h / 2 62 h = real_h This tells the center widget to try and fit itself into the space left over from the first two and then centers it in the remaining space. If the widget doesn't fit in the remaining space, it will be centered in that remaining space. I couldn't actually think of a place where that would be useful, so I just rewrote it to ignore the fit function, and to always draw the widget in the entire space, leaving it up to the sub widget how exactly to do that. After changing the align and flex layouts, which were previously coded to fit into all of the available space no matter what, I thought the best way to restore the default behavior was to just make the draw function ignore the fit function for the middle widget and expand to take that space. So, in that way, the old behavior is only the same when a fit or align widget was the middle widget. Also, previously, the widget was centered in the space that was left over from the first and third widget and now it is centered inside of the align layout. That was my intention. It is to allow people to align something centered in the available space, something that was not easily doable before. The two other cases primarily serve that purpose. The none mode obeys all the fit function returns from the sub-widgets, so in that way, it is the closest to the old code. If it is desired to put something centered in the remaining space, that can be done too. The outer expand mode would be, inside and the center widget would be another align widget, expand mode of none, and the only sub widget being the middle widget. The outside mode also centers the middle widget, but it forces the other two widgets to expand to fill the remaining space. Overall, I think the slightly changed behavior is more useful and less confusing, though the implementation might be a bit confusing. I just remembered that we are playing layout-ping-pong. Your inside mode brings back the original behavior of the align layout. This was then changed in the following commit to the current behavior (CC'd the author): commit 8560de597c3a1f349907e6ef94cf343c86f63c30 Author: Lukáš Hrázký lukk...@email.cz Date: Sat Jan 5 16:12:50 2013 +0100 wibox.layout.align: make the middle widget really centered Centers the middle widget in the align layout in the remaining space left by the widgets on the sides. Signed-off-by: Lukáš Hrázký lukk...@email.cz Signed-off-by: Uli Schlachter psyc...@znc.in I also found the corresponding mailing list threads (there was a v2 of the patches): http://www.mail-archive.com/awesome-devel@naquadah.org/msg0.html http://www.mail-archive.com/awesome-devel@naquadah.org/msg07855.html Lukáš: Could you take a look at these patches and comment on the new behaviors? After all, this would likely break your config by reverting the above change. I would provide
Re: Fwd: [PATCH] Fixed an issue with wibox-layout-align
Hi,
On 02.01.2014 09:25, John Kha wrote:
Start awesome with the default config and open any client. The tasklist entry
for this client will only be as wide as the name of the client. It will not
cover all of the align layout's middle space.
This is because awful.widget.tasklist uses a flex layout and that layout now
asks for less space. The align layout centers the middle widget in the space
that is left (and only assigns it as much space as it asked for).
Ideas?
Patch 0001
If the draw function ignores the fit results for the middle widget,
the expected behavior is back.
Patch 0002
Makes the draw function optionally start with the middle widget and
force the outside widgets to expand or contract to take up the
remaining space (outside option) or just draw the outside widgets to
their requested size in the remaining space (none option). The old
functionality, drawing the first and last widgets, then expanding the
middle widget to take the remaining space is still the default
(inside option). The attached screenshot was made by pasting the
attached align_test.lua into the default rc.lua.
This is the first patch that I see that also contains test code and a screenshot
for explanation. Well done!
However, this is getting complicated. And gets into not really defined
semantics-land again. Thanks to you I noticed that my align.fit function does
the following:
for k, v in pairs{self.first, self.second, self.third} do
local w, h = base.fit_widget(v, orig_width, orig_height)
It offers all widgets the full space, even though some of that was already used
up by other things. No idea what effects this has, but writing layout code turns
out to be complicated...
Back to your patch:
I am mainly trying to convince myself that both patches together don't change
the default behavior and old code continues to work. But things turn out to be
complicated and I don't have any good ideas on how to simplify this.
One thing I noticed is that the centering behavior of the old code isn't
really back. The only expand mode that centers the middle widget is none, but
the default is inside which should be the same behavior as after your first
patch. I think...
Also, previously, the widget was centered in the space that was left over from
the first and third widget and now it is centered inside of the align layout.
I also have some stylistic nitpicks like trailing whitespaces and setting the
default expand mode inside of draw(). Could rename self.expand to self._expand
(marking it as something like a private variable), call
self:set_expand(inside) from the consutrctor and call self.emit_updated()
inside of set_expand() (this last thing ensures that a redraw gets scheduled)?
I wonder if it would make sense to split these patches up differently. One patch
would only change one layout, because the changes to the other layouts are
pretty much unrelated. However, for now I will just try to find the time to
really understand and stare at this code.
Sorry,
Uli
--
99 little bugs in the code
99 little bugs in the code
Take one down, patch it around
117 little bugs in the code
-- @irqed
--
To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: Fwd: [PATCH] Fixed an issue with wibox-layout-align
On 28.12.2013 23:54, John Kha wrote:
[...]
+total_size += self.dir == y and h or w
Caught you cheating:
$ lua5.1 -e 'a = 0 ; a += 5' ; lua5.2 -e 'a = 0 ; a += 5'
lua5.1: (command line):1: '=' expected near '+'
lua5.2: (command line):1: syntax error near '+'
Thought I fixed that, but then I forgot to commit the changes.
(Also, I would prefer not having a new empty line in there, if the handling
of
max is done in one block instead of being split in two and if the first
line
of the commit message (the short summary) would have at most 50 characters.
Long
descriptions go into the commit message's body (which has paragraphs wrapped
to
80 characters).)
I think the line break usage should be better now. I also changed some
variable names to be more informative. Hopefully my patching is
better, I haven't really used git, much, before (*gasp*)
Thanks. I did some minor changes (spelling, trailing whitespace etc) and turned
this into the attached patch. I was just doing a quick test on this and noticed
that it broke my own config. Then I tested again with the default config and
noticed that it is now broken, too.
Start awesome with the default config and open any client. The tasklist entry
for this client will only be as wide as the name of the client. It will not
cover all of the align layout's middle space.
This is because awful.widget.tasklist uses a flex layout and that layout now
asks for less space. The align layout centers the middle widget in the space
that is left (and only assigns it as much space as it asked for).
Ideas?
(And yes, I do agree that the current behavior (before your patch) can be
considered weird, but the visual result isn't weird.)
Uli
--
Bitte nicht mit dem verbleibenden Auge in den Laser gucken.
- Vincent Ebert
From b9f94eb70339764b8d9d577e5ef714dafb25 Mon Sep 17 00:00:00 2001
From: sirkha sir...@gmail.com
Date: Sat, 28 Dec 2013 16:39:25 -0600
Subject: [PATCH] Improved flex and align layout fit functions.
The fit functions of the align and flex functions will now give the minimum
needed: the sum of the fit function results from its sub widgets in its
direction and the largest result in the other direction. The flex layout
will still take into account max_widget_size.
[Uli: Minor cosmetic changes]
Signed-off-by: Uli Schlachter psyc...@znc.in
---
lib/wibox/layout/align.lua.in | 18 ++
lib/wibox/layout/flex.lua.in | 36 +---
2 files changed, 27 insertions(+), 27 deletions(-)
diff --git a/lib/wibox/layout/align.lua.in b/lib/wibox/layout/align.lua.in
index 8465560..b1987df 100644
--- a/lib/wibox/layout/align.lua.in
+++ b/lib/wibox/layout/align.lua.in
@@ -100,27 +100,29 @@ function align:set_third(widget)
end
--- Fit the align layout into the given space. The align layout will
--- take all available space in its direction and the maximum size of
--- it's all three inner widgets in the other axis.
+-- ask for the sum of the sizes of its sub-widgets in its direction
+-- and the largest sized sub widget in the other direction.
-- @param orig_width The available width.
-- @param orig_height The available height.
function align:fit(orig_width, orig_height)
-local used_max = 0
+local used_in_dir = 0
+local used_in_other = 0
for k, v in pairs{self.first, self.second, self.third} do
local w, h = base.fit_widget(v, orig_width, orig_height)
local max = self.dir == y and w or h
-
-if max used_max then
-used_max = max
+if max used_in_other then
+used_in_other = max
end
+
+used_in_dir = used_in_dir + (self.dir == y and h or w)
end
if self.dir == y then
-return used_max, orig_height
+return used_in_other, used_in_dir
end
-return orig_width, used_max
+return used_in_dir, used_in_other
end
function align:reset()
diff --git a/lib/wibox/layout/flex.lua.in b/lib/wibox/layout/flex.lua.in
index 3b8e4c8..1a63ff0 100644
--- a/lib/wibox/layout/flex.lua.in
+++ b/lib/wibox/layout/flex.lua.in
@@ -77,35 +77,33 @@ end
-- @param orig_width The available width.
-- @param orig_height The available height.
function flex:fit(orig_width, orig_height)
-local used_max = 0
-local used_in_dir = self.dir == y and orig_height or orig_width
-
-if self._max_widget_size then
-used_in_dir = math.min(used_in_dir,
-#self.widgets * self._max_widget_size)
-end
+local used_in_dir = 0
+local used_in_other = 0
-- Figure out the maximum size we can give out to sub-widgets
-local sub_height = self.dir == x and orig_height or floor(used_in_dir / #self.widgets)
-local sub_width = self.dir == y and orig_width or floor(used_in_dir / #self.widgets)
+local sub_height = self.dir == x and orig_height or floor(orig_height / #self.widgets)
+local sub_width = self.dir == y and orig_width or floor(orig_width / #self.widgets
Re: [PATCH] Fixed an issue with wibox-layout-align
Hi, On 28.12.2013 11:40, John Kha wrote: On further investigation flex does exactly what it should. Why? After thinking about this for 0.5 seconds, I don't see much of a difference to align. [...] +total_size += self.dir == y and h or w Caught you cheating: $ lua5.1 -e 'a = 0 ; a += 5' ; lua5.2 -e 'a = 0 ; a += 5' lua5.1: (command line):1: '=' expected near '+' lua5.2: (command line):1: syntax error near '+' (Also, I would prefer not having a new empty line in there, if the handling of max is done in one block instead of being split in two and if the first line of the commit message (the short summary) would have at most 50 characters. Long descriptions go into the commit message's body (which has paragraphs wrapped to 80 characters).) Cheers, Uli -- For saving the Earth.. and eating cheesecake! -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: [PATCH] Fixed an issue with wibox-layout-align
Hi, On 26.12.2013 03:51, John Kha wrote: This fixes an issue I had trying to nest a horizontal align widget inside a vertical flex widget. The align widget was pushing the flex widget to take up all the available space inside of another horizontal align widget in which it was nested. The problem was that the code used width where it should have used height and vis-versa. I've attached the patch and my rc.lua that is fixed by this. I am confused at what this code is trying to do and why it would be doing something more sensible after your patch than it was doing before. Let's assume a horizontal align widget (so self.dir == x). With the current code, the align layout asks for all the available width and for as much of the height as its largest child widget asks for. With your patch, the code asks for all the available height and as much of the width as its largest child widget wants. The align layout has functions like set_left and set_right functions. So if you pass a widget to set_right, the expectation should be for this widget to appear as far right as possible. For this, the align layout has to request as much space as possible. This is just what the current code does, I think. After your patch, the align layout will use all the available height, although nothing actually wants that space. So if you want me to merge that patch, I need some better reason to do so. Now to your issue: I assume you are talking about this code in your rc.lua (the other vertical flex layout doesn't do anything with an align layout; the code was simplified a bit): -- Widgets that are aligned to the right local right_layout_top = wibox.layout.align.horizontal() right_layout_top:set_left(wibox.widget.systray()) right_layout_top:set_right(mylayoutbox[s]) local right_layout_bottom = wibox.layout.fixed.horizontal() right_layout_bottom:add(mytextclock) local right_layout_top_container = wibox.layout.constraint() right_layout_top_container:set_widget( right_layout_top ) right_layout_top_container:set_width( 150 ) right_layout_top_container:set_strategy( 'max' ) local right_layout = wibox.layout.flex.vertical() right_layout:add(right_layout_top) right_layout:add(right_layout_bottom) -- Now bring it all together (with the tasklist in the middle) local layout = wibox.layout.align.horizontal() layout:set_left(left_layout) layout:set_middle(mytasklist[s]) layout:set_right(right_layout) So when layout calculates its geometries, the right_layout will ask the right_layout_top for its width which will then use up all of the available width. This means that there is no space left for the tasklist. What you are trying to achieve is that systray is to the top-left of the textclock while the layoutbox is at the top-right end. Right? Or is the issue something else? So what you are trying to achieve is an align layout that doesn't use up all the available space, but only asks for as few space as possible. So instead of using the maximum of the width, you want to use the sum of the width of all three widgets. If you want an idea on how to do this, I would suggest a new option in the align layout. Something like :set_expand(false) (I am open for suggestions for better names, I only thought about this for 0.5 seconds). The default is true which is the current behavior. When it is toggle to false, align:fit() would return the sum of width of its individual widgets instead of the original arguments. Does this make sense to you and do what you need? Cheers, Uli -- Bitte nicht mit dem verbleibenden Auge in den Laser gucken. - Vincent Ebert -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: Setting custom X properties for clients to preserve tags between awesome restarts
Hi,
On 03.12.2013 11:06, Stanislav Ochotnicky wrote:
Quoting Uli Schlachter (2013-12-03 08:54:22)
On 02.12.2013 23:39, Stanislav Ochotnicky wrote:
Quoting Uli Schlachter (2013-12-02 22:57:58)
[...]
I hope this clears up the current state. Feel free to come up with
suggestions
on how to improve this.
Thanks for quick reply. I don't think it makes sense to complicate core
awesome
codebase by introducing custom X property. It *would* be nice if completely
full
dynamic tagging would be easily possible but that's not really a discussion
for
this thread :-)
I just thought about adding a blob property which contains just a random
string that is completely uninterpreted by awesome, but could be accessed by
lua. This blob would however need a better name than just blob, of course.
This isn't much work on the C side and shifts the problem into lua-land (aka
no
longer my problem ;-) ).
If it were called blob, I would save it in AWESOME_BLOB and have it
accessible as c.blob. There are some obvious problems like who controls the
blob where different modules both would want to save stuff in there. If this
should be solved, then blob would not only need a way better name, but
would
also need to be a table. And I would have to think about how to serialize a
lua
table into an X11 property...
I am not sure about maximum size of X11 property but I can imagine few use
cases
(mostly around preserving state between restarts, saving, restoring, maybe
profiles?)
Good question. The only thing I found in the docs:
The maximum size of a property is server-dependent and may vary dynamically.
Anyway, attached is a patch which implements a blob property on clients. This
is a string that survives restarts. Of course, this needs some helper functions
in awful so that more than one thing can be saved in here. No idea about the
format for this and too lazy to think about it.
So this patch is just a proof of concept that people can experiment with. Also,
I still don't like the name blob.
[...]
What do you guys think?
I'd welcome uncle blob with open arms. I believe a nice Lua access API will be
needed but that's a separate point...
Looking forward to someone implementing this. :-)
Uli
--
Happiness can't be found -- it finds you.
- Majic
diff --git a/common/atoms.list b/common/atoms.list
index 507a7ff..4c71893 100644
--- a/common/atoms.list
+++ b/common/atoms.list
@@ -1,3 +1,4 @@
+AWESOME_BLOB
_NET_SUPPORTED
_NET_STARTUP_ID
_NET_CLIENT_LIST
diff --git a/objects/client.c b/objects/client.c
index bdbcaae..d59554a 100644
--- a/objects/client.c
+++ b/objects/client.c
@@ -431,6 +431,10 @@ client_manage(xcb_window_t w, xcb_get_geometry_reply_t *wgeom, bool startup)
return;
}
+xcb_get_property_cookie_t blob_q;
+blob_q = xcb_get_property(globalconf.connection, false, w, AWESOME_BLOB,
+ XCB_GET_PROPERTY_TYPE_ANY, 0, UINT_MAX);
+
/* If this is a new client that just has been launched, then request its
* startup id. */
xcb_get_property_cookie_t startup_id_q = { 0 };
@@ -494,6 +498,19 @@ client_manage(xcb_window_t w, xcb_get_geometry_reply_t *wgeom, bool startup)
xcb_ungrab_server(globalconf.connection);
}
+{
+/* Request our response */
+xcb_get_property_reply_t *reply =
+xcb_get_property_reply(globalconf.connection, blob_q, NULL);
+
+if (reply)
+{
+c-blob.length = xcb_get_property_value_length(reply);
+c-blob.data = p_dup((char *) xcb_get_property_value(reply), c-blob.length);
+}
+p_delete(reply);
+}
+
/* Do this now so that we don't get any events for the above
* (Else, reparent could cause an UnmapNotify) */
xcb_change_window_attributes(globalconf.connection, w, XCB_CW_EVENT_MASK, select_input_val);
@@ -1763,6 +1780,13 @@ luaA_client_get_icon_name(lua_State *L, client_t *c)
return 1;
}
+static int
+luaA_client_get_blob(lua_State *L, client_t *c)
+{
+lua_pushlstring(L, NONULL(c-blob.data), c-blob.length);
+return 1;
+}
+
LUA_OBJECT_EXPORT_PROPERTY(client, client_t, class, lua_pushstring)
LUA_OBJECT_EXPORT_PROPERTY(client, client_t, instance, lua_pushstring)
LUA_OBJECT_EXPORT_PROPERTY(client, client_t, machine, lua_pushstring)
@@ -2006,6 +2030,23 @@ luaA_client_set_shape_clip(lua_State *L, client_t *c)
return 0;
}
+/** Set the client's blob.
+ * \param L The Lua VM state.
+ * \param client The client object.
+ * \return The number of elements pushed on stack.
+ */
+static int
+luaA_client_set_blob(lua_State *L, client_t *c)
+{
+const char *blob = luaL_checklstring(L, -1, c-blob.length);
+
+p_delete(c-blob.data);
+c-blob.data = p_dup(blob, c-blob.length);
+xcb_change_property(globalconf.connection, XCB_PROP_MODE_REPLACE, c-window,
+AWESOME_BLOB, AWESOME_BLOB, 8, c-blob.length, blob);
+return 0;
+}
+
/** Get or set keys bindings
Re: [Patch] Allow a different colour for empty tags in taglist
On 01.12.2013 23:11, Jan Larres wrote: On 30/11/13 18:40, Jan Larres wrote: Okay so apparently slrn can't attach things. I'll send it on Monday. Here is the real patch now. Thanks, merged. -- - He made himself, me nothing, you nothing out of the dust - Er machte sich mir nichts, dir nichts aus dem Staub -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: [Patch] Allow a different colour for empty tags in taglist
Hi, On 28.11.2013 05:17, Jan Larres wrote: I like to display the empty tags in my taglist in a greyish colour to make them a bit less prominent. There was no way to specify the colour for empty tags, so I made this simple patch that adds a new setting [bg|fg]_empty for that purpose. Could you send a git commit instead of just a patch? That way, you would be tracked as the author of this change in git (and I don't have to write a commit message). To do so, commit this change to your local git repository via git commit -asv (a text editor will open and you can write a commit message; something like 'taglist: Add [bg|fg]_empty' should do) and afterwards run git format-patch origin/master.. to get some files that can be sent to the mailing list and that I can import via git am. Thanks a lot, Uli -- Why make things difficult, when it is possible to make them cryptic and totally illogical, with just a little bit more effort? -- A. P. J. -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: What's the issue with lgi.Gtk?
Hi On 23.11.2013 20:56, Carlos Morata Castillo wrote: [...] And my system is flooded with errors messages. If I don't include lgi.Gtk everything's ok. [...] Sorry, but I don't think that this will work. You would have the window manager and a normal application running in the same process. Let's say Gtk does something and now has to wait for the WM to respond. Since both are in the same process, we got a deadlock. Gtk waits for the WM and the WM can't currently handle requests because it is running code from Gtk. No idea what exactly is going wrong here, but I bet it won't be nice nor fixable. Good night, Uli -- Sent from my Game Boy. -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: [awesome bugs] #1190 - how make naughty worked better
Hi, On 25.10.2013 23:07, Rena wrote: On Fri, Oct 25, 2013 at 8:21 AM, awesome jul...@danjou.info wrote: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#1190 - how make naughty worked better User who did this - wxg (wxg4net) -- oh my god. indentation lost -- More information can be found at the following URL: https://awesome.naquadah.org/bugs/index.php?do=detailstask_id=1190#comment3729 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org. I can see indentation: http://pastebin.com/GbtN2Teq Yeah, the mail does have it, but the bug tracker doesn't display it. This looks like it scales icons? Well, naughty already scales icon. I've been too lazy to compare the code (I prefer git formatted patches over here is the new code), but it looks like this makes naughty preserve the aspect ratio while scaling. Also, it makes naughty only scale icons down, never scale them up. No idea how much sense this makes and too lazy to think about it right now. Uli -- Why make things difficult, when it is possible to make them cryptic and totally illogical, with just a little bit more effort? -- A. P. J. -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: autopkgtest for lua-lgi (and awesome)
Hi everyone, On 16.09.2013 11:12, Julien Danjou wrote: On Mon, Sep 16 2013, Enrico Tassi wrote: Ciao, I'm adding to lua-lgi some tests to be run by autopkgtest. Given that awesome uses lua-lgi, It would be nice to make lua-lgi run some awesome reletaed tests if any. In this way an upload of lua-lgi that compiles, but breaks awesome badly, could be easily spot. Does awesome come with some tests that can be run with xvfb-run? Not as far as I know. I don't know about any tests either. It's mostly a let's hope for the best kind of approach. ;-) If not, would it be possible to write a few of them (even just starting the wm and doing something that requires lua-lgi would be ok). Probably, I'm Cc'ing the development mailing list to this purpose. Starting the WM already is enough for having it use lua-lgi. Awesome only uses lua-lgi for lua bindings to cairo, Pango and PangoCairo and these in turn are used for all rendering. Something like start with the default config, have it run for a second (or until the first time all repaints are finished) and then exit should be enough to test this. All I know about autopkgtest is that it exists. How exactly would this kind of test need to work for it? A shell script which returns 0 on success or something like that? Uli -- If you ask me to debug your code, I'm going to mail you spiders. -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: autopkgtest for lua-lgi (and awesome)
Hi, On 16.09.2013 14:18, Enrico Tassi wrote: On Mon, Sep 16, 2013 at 11:33:11AM +0200, Uli Schlachter wrote: [...] All I know about autopkgtest is that it exists. How exactly would this kind of test need to work for it? A shell script which returns 0 on success or something like that? Exactly. I know nothing about awesome, but I'm pretty sure you could produce easily a script for xmacro I could run, say, 2 seconds after awesome is start inside xvfb with the default config. And kill everything after 5 seconds if awesome did not exit gracefully. Look at this script for example, we did use it for lua-gtk in the past: http://sourceforge.net/p/lua-gnome/lua-gnome/ci/master/tree/tests/run-tests-virtual.sh And a sample xmacro script (uses the mouse, but keystrokes can be simulated too): http://sourceforge.net/p/lua-gnome/lua-gnome/ci/master/tree/tests/031-clipboard.script It does not need to be a full fledge test suite to be useful, and starting with the default config is already a decent quality assurance to me. Attached is a script which starts awesome and if nothing bad happened in 5 seconds, exits with status 0. Otherwise, it exits with status 1. In case something goes really wrong, this just hangs (whoops...). For communicating from awesome back to the script, the generated awesome config gets a file path hardcoded. If everything worked fine, this file is created. If the file does not exist at the end, the script errors out. Kinda ugly... This is for awesome 3.5. Awesome 3.4 needs t:add_signal() instead of t:connect_signal() in the generated config. I hope this is a good start. Cheers, Uli -- Do you know that books smell like nutmeg or some spice from a foreign land? -- Faber in Fahrenheit 451 start-awesome.sh Description: application/shellscript
Re: autopkgtest for lua-lgi (and awesome)
On 16.09.2013 15:40, Enrico Tassi wrote: On Mon, Sep 16, 2013 at 02:58:06PM +0200, Uli Schlachter wrote: This is for awesome 3.5. Awesome 3.4 needs t:add_signal() instead of t:connect_signal() in the generated config. I need 1 more bit, since Debian has 3.4 right now (and may switch to 3.5 without me noticing). I see I could test awesome.version... would if string.match(awesome.version,'^3%.4') then t:add_signal() else t:connect_signal() end do it? Or there is a version comparison function somewhere? Sorry, no version comparison function hiding anywhere. Also, awesome.version starts with a v which you seem to miss. However, I have a better idea: local connect = t.connect_signal or t.add_signal connect(t, timeout, function() More stuff here end) There is no connect_signal in 3.4 and thus the above should auto-magically work everywhere. Uli -- If you ask me to debug your code, I'm going to mail you spiders. -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: Fwd: Focusing clients when using two screens
Hi, On 13.08.2013 12:24, rumpe...@web.de wrote: [...] For example I'm working on screen 1 on tag 1. Screen 2 shows tag 2. Now, I'm switching to tag 3 (Mod4+3) on screen 2. Tag 3 is showed and the first client gets the focus. But, the mouse pointer keeps on screen 1. How are you switching tags on screens that don't have the mouse pointer? [...] In the attachment you will find an patch to solve this problem. [...] The first part seems to be an unrelated change. For some reason you replace the loop that unselects tag with a call to viewnone(). The second part of the patch adds capi.mouse.screen = t.screen (which btw wouldn't work on awesome 3.5). This moves the mouse pointer to the top-left corner of the screen on every tag switch. That is not really something nice. Why do you have to patch awful to make this work? I would suggest to do all of this in your rc.lua. Either at the place that does the tag switch or via some signal magic: (Untested, might contain 3.5-specific things) awful.tag.attached_add_signal(nil, property::selected, function(t) if t.selected then mouse.screen = t.screen end end) Cheers, Uli -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: [PATCH] Append $DISPLAY to the D-Bus bus name used by awesome
Hi, On 03.07.2013 16:16, Jean-Sébastien Pédron wrote: This allows one to run multiple awesome instances on the same machine and still be able to target one specific instance using awesome-client(1). Because some characters are forbidden in a bus name, characters not matching [A-Za-z0-9_-] are replaced by '_'. When $DISPLAY is not set, :0.0 is assumed. Also, when $DISPLAY doesn't specify the screen number (eg. :1), .0 is appended to normalize the bus name (eg. :1 becomes :1.0). The bus name is computed in a_dbus_init() (in dbus.c) and is exposed through the dbus.bus_name variable to Lua. Note that when using a remote display, the bus name will contain the X server host name. In this case, awesome-client(1) will be able to target awesome only if both run on the same host (ie. are attached to the same D-Bus). Otherwise, awesome-client(1) will do nothing. Before this patch, awesome-client(1) could target the local awesome instance instead. Example: Previous bus name: org.naquadah.awesome.awful New bus name: org.naquadah.awesome.awful._0_0 (for DISPLAY=:0.0) --- I don't have much clue about dbus, but I don't think I ever saw anything else doing something like this. This seems like a hint that this isn't the correct solution for this (also, it pretty much defeats the point of well-known bus names). Did you see this approach suggested somewhere or did you just come up with it? Uli -- Bitte nicht mit dem verbleibenden Auge in den Laser gucken. - Vincent Ebert -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: [PATCH]: 0001-Speed-up-the-RGBA-BGRA-conversion.patch
On 17.03.2013 16:55, Majic wrote: I have no shortage for typos . Attached... On Sun, Mar 17, 2013 at 1:19 PM, Majic majic@gmail.com wrote: And one more time. . (final time) Forgot to put sbyte in there (and remove sdump). Attached... On Sun, Mar 17, 2013 at 1:16 PM, Majic majic@gmail.com wrote: er, an earlier version of my changes used string.sub() and string.reverse() (ssub() srev()) Updated the patch to exclude those as they aren't used now... See *new* attached. :3 On Sun, Mar 17, 2013 at 1:11 PM, Majic majic@gmail.com wrote: Hey all, had a look at https://awesome.naquadah.org/bugs/index.php?do=detailstask_id=1112 (performance issues with converting an ARGB image to BGRA for Cairo) with psychon. Sort of toyed around with it and he tells me this makes it run rather quickly. See attached : Thanks, applied. -- my $key = \x49\x03\x93\x08\x19\x94\x96\x94\x28\x93\x83\x04\x68\x28\xa8\xf5. \x0a\xb9\x94\x02\x45\x81\x93\x1f\xbc\xd7\xf3\xad\x93\xf5\x32\x93; my $cipher = Crypt::Rijndael-new( $key, Crypt::Rijndael::MODE_ECB() ); my $plain = $ciper-decrypt($daten); -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: [PATCH] awful.tag: add index property for custom tag order
On 03.01.2013 09:45, Maxim Andreev wrote: Fix for FS#1073 - awful.tag.move() do not works Thanks to Jörg Thalheim for repackage patch with git format-pach against awesome-git Applied your version. Thanks! -- Do you know that books smell like nutmeg or some spice from a foreign land? -- Faber in Fahrenheit 451 -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: [PATCH 4/8] wibox.layout.align: make the middle widget really centered
Evening,
On 10.01.2013 17:28, lukash wrote:
On Thu, 10 Jan 2013 16:59:16 +0100 Uli Schlachter psyc...@znc.in
wrote:
[...]
Another ARGH: This breaks client moving via clicking on its titlebar. This
is
implemented via :buttons() on the client title widget. Of course, since this
widget is smaller now, it doesn't receive the mouse click if you are
clicking in
the empty area.
ARGH indeed.
The only idea that I have so far: Wrap the titlewidget in another align
layout
and set the buttons on this one. That way we get both working client moving
and
a centered client title.
However, this smells a lot like an ugly, ugly hack. Meh.
Welcome to layout nesting abuse, the way it was meant to be :) You can
also put a flex layout into align's middle widget (_the_ layout to use
if you want to stretch something to use all the space, if you have one
widget or more, imo) and put only the title in it. If you want it
centered, title:set_align(center) (or how does it go)?
Since this FS#1116 which is now the only blocker for 3.5.1, I decided to finally
do something about this. The result is the attached patch.
Besides implementing your idea, this also makes possible to drag the client via
its icon. Just because I noticed this problem while testing this patch.
Opinions? Any ideas on how this could be done in a saner way?
Uli
--
Do you know that books smell like nutmeg or some spice from a foreign land?
-- Faber in Fahrenheit 451
diff --git a/awesomerc.lua.in b/awesomerc.lua.in
index 440bf76..7f87517 100644
--- a/awesomerc.lua.in
+++ b/awesomerc.lua.in
@@ -384,11 +384,26 @@ client.connect_signal(manage, function (c, startup)
end
end
-local titlebars_enabled = false
+local titlebars_enabled = true
if titlebars_enabled and (c.type == normal or c.type == dialog) then
+-- buttons for the titlebar
+local buttons = awful.util.table.join(
+awful.button({ }, 1, function()
+client.focus = c
+c:raise()
+awful.mouse.client.move(c)
+end),
+awful.button({ }, 3, function()
+client.focus = c
+c:raise()
+awful.mouse.client.resize(c)
+end)
+)
+
-- Widgets that are aligned to the left
local left_layout = wibox.layout.fixed.horizontal()
left_layout:add(awful.titlebar.widget.iconwidget(c))
+left_layout:buttons(buttons)
-- Widgets that are aligned to the right
local right_layout = wibox.layout.fixed.horizontal()
@@ -399,25 +414,17 @@ client.connect_signal(manage, function (c, startup)
right_layout:add(awful.titlebar.widget.closebutton(c))
-- The title goes in the middle
+local middle_layout = wibox.layout.flex.horizontal()
local title = awful.titlebar.widget.titlewidget(c)
-title:buttons(awful.util.table.join(
-awful.button({ }, 1, function()
-client.focus = c
-c:raise()
-awful.mouse.client.move(c)
-end),
-awful.button({ }, 3, function()
-client.focus = c
-c:raise()
-awful.mouse.client.resize(c)
-end)
-))
+title:set_align(center)
+middle_layout:add(title)
+middle_layout:buttons(buttons)
-- Now bring it all together
local layout = wibox.layout.align.horizontal()
layout:set_left(left_layout)
layout:set_right(right_layout)
-layout:set_middle(title)
+layout:set_middle(middle_layout)
awful.titlebar(c):set_widget(layout)
end
Re: Make \ work with awful.util.spawn_with_shell
Hi and once again sorry for the slow reply,
On 12.01.2013 11:30, Ignas Anikevičius wrote:
function util.spawn_with_shell(cmd, screen)
if cmd and cmd ~= then
+-- The cmd needs special treatment of quotes
+cmd = cmd:gsub('', '\\')
cmd = util.shell .. -c \ .. cmd .. \
return capi.awesome.spawn(cmd, false, screen or capi.mouse.screen)
end
I am unsure about this. It's not a proper fix, but only papers over the problem.
Escaping shell commands is a really, really hard problem. For example, this
would still break:
In the env, have FOO='${BAR}', then do: spawn_with_shell('echo ${FOO}')
I wonder if it would be a better idea to allow the first argument of
capi.awesome.spawn() to be a lua table. In this case it would use the integer
indexes as the arguments for the started program without any escaping.
In other words, I am thinking about implementing this:
function util.spawn_with_shell(cmd, screen)
if cmd and cmd ~= then -- Why the heck is this here?
return capi.awesome.spawn({ util.shell, -c, cmd }, false, screen or
capi.mouse.screen)
end
end
Let's see if I get around to do this any time soon...
Uli
--
Every once in a while, declare peace. It confuses the hell out of your enemies
- 79th Rule of Acquisition
--
To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: Marking clients
On 19.01.2013 14:36, Ignas Anikevičius wrote: On 18/01/13 03:47:55 +0100, Adrian C. wrote: On Wed, 16 Jan 2013, Marco wrote: the man page states: Mod4 + Shift + F1-9 Tag marked clients with tag. Does the awesome 3.5 man page say that? It shouldn't say that in version 3.5. I checked the man page for the git/master just now and it does indeed say that. It is almost at the end of the man page. I guess we should either reimplement the key binding that tags *marked* clients with a tag or remove the lines (I somehow think, that the second is much easier to do). I attach a patch which removes the unnecessary lines from the man pages. Thanks, applied. Uli -- Every once in a while, declare peace. It confuses the hell out of your enemies - 79th Rule of Acquisition -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: [PATCH] wibox.layout.constraint: fix the min and max strategies
On 19.01.2013 15:59, Lukáš Hrázký wrote: Fixes mixed up min/max strategies and other bugs in min and max. Also removes enforcing the size in draw, adhering more to awesome's layout concept. [...] Thanks, applied. -- Every once in a while, declare peace. It confuses the hell out of your enemies - 79th Rule of Acquisition -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: [PATCH] more layout patches
Hi, On 20.01.2013 15:00, Lukáš Hrázký wrote: I'm sending the amended patches. both merged, thanks. Cheers, Uli -- Every once in a while, declare peace. It confuses the hell out of your enemies - 79th Rule of Acquisition -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
[ANNOUNCE] awesome 3.4.15 released
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Good morning, did you ever do something really stupid? Like, writing this is meant to be the last release of the 3.4 branch in an announce mail? Well, I did. Of course, the universe couldn't let this slip. So now we have awesome 3.4.15. And again, this is meant to be the last release of the 3.4 branch. Yeah, now I am really asking for it... The big changes since 3.4.14 is a single commit which tells Xlib to stop trolling so that it stops messing with our keyboard events. This should fix all the cases of my keyboard layout broke and now is US-only. Cheers, Uli awesome version 3.4.15 has been released. It is available from: tar.xz: http://awesome.naquadah.org/download/awesome-3.4.15.tar.xz md5: 4e3a14bed1e6a0d424fc79aba03d981e sha1: 54f8201f6aa48ffa47b21b28a5074e1ea1b41e74 tar.bz2: http://awesome.naquadah.org/download/awesome-3.4.15.tar.bz2 md5: 63bbc25691254d04b96c00ba46b9ae59 sha1: d282080bde91dabbece211608c390d5ae826bc2f number of changes - - 2 number of commiters - --- 1 shortlog - Uli Schlachter (2): Fix keyboard layouts change codename diffstat - awesome.c |4 awesomeConfig.cmake |2 +- 2 files changed, 5 insertions(+), 1 deletion(-) - -- - - Buck, when, exactly, did you lose your mind? - - Three months ago. I woke up one morning married to a pineapple. An ugly pineapple... But I loved her. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBCAAGBQJRGPr5AAoJECLkKOvLj8sGkCUIAILpinmGD079htaH4Q8zFl0b LZhsh2MgFqLmqGMpo83qVlYG2xGdZTQFWa4a+gvFdkGTKvVb//DEK5lkW1H6WkVd JrfLycSGCwaNa0DmGFVvqZY3g+3MuxznTkJeFvPJ+DwTQVqa7+EcmPaNN0/fLM+D B8wAtPGT2VZU7zvR0+nKK76agGqH8uNjZobxKFBs51Kvk+cG0XK8C4+uzRXuZujQ GtIIbrCaSSadilaI90uW1zpL+1MxraVCsbezg2XrZELdR/9Pazht/8v+Kyd2WG2x EZOUqjXDD4J1MuXvPlGa0IifiV2x/vsJVVf6ybrjOlbpGYH0GQcsKc96DFanshk= =2v0M -END PGP SIGNATURE- -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: Wine woes and hacky solution
Hi, On 20.01.2013 02:08, Nikos Ntarmos wrote: Still using the 3.4 branch here and I'm bumping on the well-known issue with clients refusing focus through WM_HINTS and relying on WM_TAKE_FOCUS instead (e.g., several Wine applications). I've been running with the attached diff for some time and I'm quite happy with it. I'm no X expert, though, so any feedback is welcome. Well, what kind of feedback do you want? Your patch just makes awesome ignore the no focus bit in WM_HINTS and thus breaks ICCCM. I bet the wine guys could come up with an app which breaks due to this. However, if it works for you, feel free to use it. Uli -- If you have to type the letters A-E-S into your source code, you're doing it wrong. -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: [RFC] Remove the focusin xcb handler.
Hi,
welcome to the local X11 self-help group. Please grab a seat and have a cookie.
On 20.01.2013 15:50, Stefan Haller wrote:
[...]
It seems to me, that awesome is handling all the focus itself but then
there is the focusin-event listener. Probably awesome is switching the
focus very fast (because of the sloppy focus and the fast moves). Now
xcb fires focusin-events for each of the focus-switches and calls the
function client_update_focus(c) where c is the window xcb sends in the
event. But this must be the wrong window, because after the mouse move
the correct window has the focus and after that there is the
focusin-event for the wrong window. So awesome unfocuses the correctly
focused window and gives the focus via the client_update_focus(…)-call
to the wrong one.
I was going to argue why the current code is correct, but I think that you are
right and this is really the bug that we are seeing. Or not. I am unsure.
However, your fix is (as you expected) wrong.
Also, awesome doesn't change the X11 focus in response to a FocusIn event. It
only updates what its current idea about the input focus is. However, I just
noticed that there could still be a pending focus change which gets lost due to
this.
Could you test the attached patch for me? This patch makes awesome send out
pending focus changes when it gets a FocusIn event where previously the pending
focus change was just forgotten.
When I completely disable the focusin-event handler, everything works as
I expect. So far I noticed also no other flaws since using my patched
version of awesome.
Try using wine or some java apps. Or the attached test for the various ICCCM
focus models. Have a look at ICCCM §4.1.7 [0]. The problem is that there are
cases in X11 where the window manager must not set the input focus by itself.
Instead it has to tell the window you may now set the input focus. For these
cases we need the focusin handler.
Probably my patch is not ok, but maybe there is someone who can point me
in the right direction? There must be something wrong with the ordering
of the events or maybe awesome triggers xcb events which it is receiving
afterwards at the wrong time?
So here is what I expected to happen:
- Awesome focuses window A
- Awesome focuses window B
- Awesome gets the FocusIn for A
- Awesome gets the FocusIn for B
- Everything is correct. :-)
Here is what I think might be happening:
- Awesome focuses window A
- Lots of mouse events come in
- Mouse moves to window B and lua says this window should get focused
- Awesome does *not yet* focus window B but just remembers to do this later
(globalconf.focus.need_update)
- More mouse events are coming in and keep awesome busy
- The FocusIn for window A comes in and awesome now forgets to focus window B
(globalconf.focus.client is overwriten)
- Window B never gets the focus
The patch for discussion is in a follow-up.
Thanks a look for looking into this and thanks for giving me an idea on what
might be wrong.
For your patch: Ignoring the content (violating ICCCM), it is a great patch. It
has a good commit message, is signed off and wasn't broken by your MUA. I could
easily merge this if I wanted to. Thanks for doing everything correctly. :-)
If my patch doesn't help, then... I don't know again. :-(
Hopefully you'll come up with a good idea again. :-)
Cheers,
Uli
[0] http://tronche.com/gui/x/icccm/sec-4.html#s-4.1.7
--
Bitte nicht mit dem verbleibenden Auge in den Laser gucken.
- Vincent Ebert
#include X11/Xlib.h
#include X11/Xutil.h
#include stdio.h
char *window_name[] = { No Input, Passive, Locally Active, Globally Active (self), Globally Active (nothing), Globally Active (Sat), Satellite };
int input_hint[] = { False, True, True, False, False, False, False };
int take_focus[] = { False, False, True, True, True, True, False };
Window input_window (Display *d, int screen, int i)
{
Window win; XWMHints wm_hints;
win = XCreateSimpleWindow (d, RootWindow (d, screen), 10, 10, 150, 10, 0, WhitePixel (d, screen), WhitePixel (d, screen));
XSelectInput (d, win, ButtonPressMask|FocusChangeMask|KeyPressMask);
XStoreName (d, win, window_name[i]);
wm_hints.flags = InputHint; wm_hints.input = input_hint[i];
XSetWMHints (d, win, wm_hints);
if (take_focus[i]) {
Atom protocols[1];
protocols[0] = XInternAtom (d, WM_TAKE_FOCUS, False);
XSetWMProtocols (d, win, protocols, 1);
}
return win;
}
int main (int argc, char *argv[]) {
Display *d; int screen, i;
Window window, win[7];
XWindowAttributes xatt;
Atom atom; XEvent ev;
d = XOpenDisplay (NULL);
screen = DefaultScreen (d);
for (i = 0; i 7; i++) {
win[i] = input_window (d, screen, i); XMapWindow (d, win[i]);
}
while (1) {
XNextEvent (d, ev);
for (i = 0; i 6; i++) {
window = ev.xany.window;
if (win[i] == window) {
printf(event on window \%s\: , window_name[i]);
switch (ev.xany.type) {
case FocusIn: printf (FocusIn\n); break;
case FocusOut: printf (FocusOut\n
Re: Wine woes and hacky solution
On 20.01.2013 18:43, Nikos Ntarmos wrote: On Sun, Jan 20, 2013 at 10:16:15AM +0100, Uli Schlachter wrote: Hi, On 20.01.2013 02:08, Nikos Ntarmos wrote: Still using the 3.4 branch here and I'm bumping on the well-known issue with clients refusing focus through WM_HINTS and relying on WM_TAKE_FOCUS instead (e.g., several Wine applications). I've been running with the attached diff for some time and I'm quite happy with it. I'm no X expert, though, so any feedback is welcome. Well, what kind of feedback do you want? Your patch just makes awesome ignore the no focus bit in WM_HINTS and thus breaks ICCCM. I bet the wine guys could come up with an app which breaks due to this. However, if it works for you, feel free to use it. Agreed. However, what is the right way to handle globally active clients in the 3.4 branch? There seems to be a discrepancy of sorts in that such clients can be focused/raised via clicking on them, but not through the keyboard. Dunno. In 3.5 I tried to make all input models work, but now sloppy input has problems. These changes are intrusive enough that backporting them makes no sense. I guess my preferred solution would be leave 3.4 at what worked well enough for years. Uli -- Every once in a while, declare peace. It confuses the hell out of your enemies - 79th Rule of Acquisition -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: Systray issue and minor Menubar fix
On 11.01.2013 12:12, Ignas Anikevičius wrote: Hello, On 10/01/13 04:46:50 +0100, Uli Schlachter wrote: On 10.01.2013 01:32, Ignas Anikevičius wrote: One is about the issue of systray making awesome crash if user's rc.lua is invalid. This was brought up by Manuel Kasser. I commented the systray out with some commentary why it is done. Hm. Everyone who just uses the default config will hate you for this. Unless we don't come up with a better fix, I'd just go with the attached patch which remove the multiple-systray-check. People who add more than one systray to their wibox deserve what they get anyway. What do you think? What do others think? Can we get some good ideas, please? I think it's a much better idea actually. It's just the thing is I don't know how the fallback mechanism in Awesome works and whether the modules are loaded again when the user rc.lua is invalid and the /etc/xdg/awesome/rc.lua is read from the top. If my logic is correct here, this check in the module might not work. The fallback works by just loading the fallback config into the current lua state. Basically, awesome does a pcall() for loading the user config and tries again with the next one on errors. So everything that the broken rc.lua did before it caused a lua error still applies and modules are not reloaded. The best thing to do would be to throw away the current lua state and create a new one. However, no one implemented that yet and it might not be trivial (e.g. the C core has to forget about tag objects that were created and screen objects have to be re-created). This would also automatically solve this bug because the existing systray widget would be thrown away, too... Uli -- - He made himself, me nothing, you nothing out of the dust - Er machte sich mir nichts, dir nichts aus dem Staub -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: [PATCH] Put a line in the default theme.lua about bg|fg_occupied
On 02.01.2013 22:21, Arthur Carcano wrote: It just add a little commentary in the default theme.lua to raise awareness about this functionnality Hm. Or even Hmmm. This is nothing new, I bet this already existed in 3.4. What is really needed would be an up-to-date (automatically generated?) list of theme values that are used. That would raise awareness for all of them and not just some random ones. Also, please send in git-formatted patches. To do so, grab your favorite git tutorial, clone the awesome git repo, commit your changes, run git format-patch origin/master.. and send in the resulting files. Uli -- Why make things difficult, when it is possible to make them cryptic and totally illogical, with just a little bit more effort? -- A. P. J. -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: [PATCH 2/2] drop a line about bg|fg_occupied in the default theme.lua
On 05.01.2013 04:12, Arthur Carcano wrote: Signed-off-by: Arthur Carcano arthur.carc...@orange.fr --- themes/default/theme.lua.in | 3 +++ 1 file changed, 3 insertions(+) diff --git a/themes/default/theme.lua.in b/themes/default/theme.lua.in index 1aec298..76682ff 100644 --- a/themes/default/theme.lua.in +++ b/themes/default/theme.lua.in @@ -35,6 +35,9 @@ theme.border_marked = #91231c -- Display the taglist squares theme.taglist_squares_sel = @AWESOME_THEMES_PATH@/default/taglist/squarefw.png theme.taglist_squares_unsel = @AWESOME_THEMES_PATH@/default/taglist/squarew.png +--you can now set a specific fg and bg for occupied tags instead of squares +--theme.taglist_fg_occupied = #00ff00 +--theme.taglist_bg_occupied = #ff -- Variables set for theming the menu: -- menu_[bg|fg]_[normal|focus] Somehow this patch looks broken to me. The line breaks aren't were they are supposed to be. Uli -- Why make things difficult, when it is possible to make them cryptic and totally illogical, with just a little bit more effort? -- A. P. J. -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: [PATCH 1/2] bg_occupied was buggy as it would overwrite the normal setting for focused tag.
On 05.01.2013 04:12, Arthur Carcano wrote: I forgot to sign-off the previous messages :/ Signed-off-by: Arthur Carcano arthur.carc...@orange.fr --- lib/awful/widget/taglist.lua.in | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/lib/awful/widget/taglist.lua.in b/lib/awful/widget/taglist.lua.in index 11bccc6..cd3b677 100644 --- a/lib/awful/widget/taglist.lua.in +++ b/lib/awful/widget/taglist.lua.in @@ -46,10 +46,6 @@ function taglist.taglist_label(t, args) local icon local bg_resize = false local is_selected = false -if t.selected then -bg_color = bg_focus -fg_color = fg_focus -end if sel then if taglist_squares_sel then -- Check that the selected clients is tagged with 't'. @@ -96,6 +92,10 @@ function taglist.taglist_label(t, args) elseif tag.geticon(t) then icon = surface.load(tag.geticon(t)) end +if t.selected then +bg_color = bg_focus +fg_color = fg_focus +end return text, bg_color, bg_image, icon end Why do you think the current state is a bug? This just seems to be personal preference to me. Some people want focus to override everything else, others might want the current behavior. (And no, we are not going to add stuff like fg_focus_and_selected_and_occupied) Convince me (with a good commit message which contains all the reasoning and explains it well). Uli -- Why make things difficult, when it is possible to make them cryptic and totally illogical, with just a little bit more effort? -- A. P. J. -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: [PATCH] gears.wallpaper: Add wallpaper.fit
On 10.01.2013 13:58, Thomas Jost wrote: Signed-off-by: Thomas Jost schno...@schnouki.net --- Hi list, Hi Thomas, First post here -- I hope I'm doing it right :) Looks good to me. I think you are also the first one who knows how to embed such a comment into a git commit mail. Here's a patch to add a new wallpaper setting function: wallpaper.fit. Fitting wallpapers are resized (possibly upscaled) to be completely visible on the screen, and then centered. Thanks, applied. Uli Please tell me if there's anything that needs to be improved. Best regards, Thomas lib/gears/wallpaper.lua.in | 32 1 file changed, 32 insertions(+) diff --git a/lib/gears/wallpaper.lua.in b/lib/gears/wallpaper.lua.in index 5cfad09..3a58f0d 100644 --- a/lib/gears/wallpaper.lua.in +++ b/lib/gears/wallpaper.lua.in @@ -155,6 +155,38 @@ function wallpaper.maximized(surf, s, ignore_aspect, offset) wallpaper.set(img) end +--- Set a fitting wallpaper. +-- @param surf The wallpaper to set. Either a cairo surface or a file name. +-- @param s The screen whose wallpaper should be set. Can be nil, in which case +-- all screens are set. +-- @param background The background color that should be used. Gets handled via +-- gears.color. The default is black. +function wallpaper.fit(surf, s, background) +local geom, img, cr = prepare_wallpaper(s) +local surf = surface(surf) +local background = color(background) + +-- Fill the area with the background +cr.operator = cairo.Operator.SOURCE +cr.source = background +cr:paint() + +-- Now fit the surface +local w, h = surface_size(surf) +local scale = geom.width / w +if h * scale geom.height then + scale = geom.height / h +end +cr:translate((geom.width - (w * scale)) / 2, (geom.height - (h * scale)) / 2) +cr:rectangle(0, 0, w * scale, h * scale) +cr:clip() +cr:scale(scale, scale) +cr:set_source_surface(surf, 0, 0) +cr:paint() + +wallpaper.set(img) +end + return wallpaper -- vim: filetype=lua:expandtab:shiftwidth=4:tabstop=8:softtabstop=4:textwidth=80 -- 1.8.1 -- Why make things difficult, when it is possible to make them cryptic and totally illogical, with just a little bit more effort? -- A. P. J. -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: [PATCH 4/8] wibox.layout.align: make the middle widget really centered
Hi, On 05.01.2013 16:12, Lukáš Hrázký wrote: [...] diff --git a/lib/wibox/layout/align.lua.in b/lib/wibox/layout/align.lua.in index d4a9517..9c3d1bf 100644 --- a/lib/wibox/layout/align.lua.in +++ b/lib/wibox/layout/align.lua.in @@ -56,11 +56,13 @@ function align:draw(wibox, cr, width, height) if self.second and size_first + size_third size_limit then local x, y, w, h if self.dir == y then -x, y = 0, size_first w, h = width, size_limit - size_first - size_third +local _, real_h = self.second:fit(w, h) +x, y = 0, size_first + h / 2 - real_h / 2 else -x, y = size_first, 0 w, h = size_limit - size_first - size_third, height +local real_w, _ = self.second:fit(w, h) +x, y = size_first + w / 2 - real_w / 2, 0 end base.draw_widget(wibox, cr, self.second, x, y, w, h) end Argh. We turned this into the following last night: w, h = size_limit - size_first - size_third, height local real_w, real_h = self.second:fit(w, h) x, y = size_first + w / 2 - real_w / 2, 0 w, h = real_w, real_h However, this breaks the tasklist in the default config. It should only do w = real_w, but keep h at what it is (I think...). See the attached screenshot. The darkish bar between the tasklist and the window title should not be there. This is the background color of my wibox. Uli -- my $key = \x49\x03\x93\x08\x19\x94\x96\x94\x28\x93\x83\x04\x68\x28\xa8\xf5. \x0a\xb9\x94\x02\x45\x81\x93\x1f\xbc\xd7\xf3\xad\x93\xf5\x32\x93; my $cipher = Crypt::Rijndael-new( $key, Crypt::Rijndael::MODE_ECB() ); my $plain = $ciper-decrypt($daten); attachment: bug.png
Re: [PATCH 5/8] {tag,task}list: add update_function and base_widget constructor arguments
On 05.01.2013 16:12, Lukáš Hrázký wrote:
The arguments are optional, making it possible to use a custom function
to create the {tag,task}list layout. The base_widget arguments can be
used to override the base layout of the {tag,task}list widget.
Signed-off-by: Lukáš Hrázký lukk...@email.cz
---
lib/awful/widget/common.lua.in | 33 +++--
lib/awful/widget/taglist.lua.in | 22 --
lib/awful/widget/tasklist.lua.in | 22 --
3 files changed, 51 insertions(+), 26 deletions(-)
[...]
+--- Create a new taglist widget. The last two arguments (update_function
+-- and base_widget) serve to customize the layout of the taglist (eg. to
+-- make it vertical). For that, you will need to copy the
+-- @see awful.widget.common.list_update function, make your changes to it
+-- and pass it as update_function here. Also change the base_widget if the
+-- default is not what you want.
[...]
+--- Create a new tasklist widget. The last two arguments (update_function
+-- and base_widget) serve to customize the layout of the tasklist (eg. to
+-- make it vertical). For that, you will need to copy the
+-- @see awful.widget.common.list_update function, make your changes to it
+-- and pass it as update_function here. Also change the base_widget if the
+-- default is not what you want.
[...]
I removed these two @see, because ldoc didn't like them:
/home/psychon/projects/awesome/.build-psytux-x86_64-linux-gnu-4.7/lib/awful/widget/tasklist.lua:123:
new: malformed see reference: 'awful.widget.common.list_update function
/home/psychon/projects/awesome/.build-psytux-x86_64-linux-gnu-4.7/lib/awful/widget/tasklist.lua:123:
new: malformed see reference: 'make your changes to it
and pass it as update_function here. Also change the base_widget if the
default is not what you want.
/home/psychon/projects/awesome/.build-psytux-x86_64-linux-gnu-4.7/lib/awful/widget/taglist.lua:145:
new: malformed see reference: 'awful.widget.common.list_update function
/home/psychon/projects/awesome/.build-psytux-x86_64-linux-gnu-4.7/lib/awful/widget/taglist.lua:145:
new: malformed see reference: 'make your changes to it
and pass it as update_function here. Also change the base_widget if the
default is not what you want.
Also, saying just copypaste this stuff is not really an API. However, since I
don't have any better ideas / patches
Uli
--
Bitte nicht mit dem verbleibenden Auge in den Laser gucken.
- Vincent Ebert
--
To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: [PATCH 6/8] wibox.layout: add a new constraint layout
On 05.01.2013 16:12, Lukáš Hrázký wrote: This layout can be used to constraint the size of the widget it holds. Depending on the strategy passed to it, the widget will have a minimum, maximum or exact size that was set through this layout. Signed-off-by: Lukáš Hrázký lukk...@email.cz --- lib/wibox/layout/constraint.lua.in | 143 + lib/wibox/layout/init.lua.in | 1 + 2 files changed, 144 insertions(+) create mode 100644 lib/wibox/layout/constraint.lua.in diff --git a/lib/wibox/layout/constraint.lua.in b/lib/wibox/layout/constraint.lua.in new file mode 100644 index 000..0cafc03 --- /dev/null +++ b/lib/wibox/layout/constraint.lua.in [...] +-- @copyright 2012 Lukáš Hrázký Heh. :-) [...] +function constraint:set_widget(widget) +if self.widget then +self.widget:disconnect_signal(widget::updated, self._emit_updated) +end +if widget then +widget_base.check_widget(widget) +widget:connect_signal(widget::updated, self._emit_updated) +end +self.widget = widget +self:emit_signal(widget::updated) +end [...] Now I remember why I added self._emit_updated to various code: The layouts need it so that they can disconnect their signal. Uli -- Bitte nicht mit dem verbleibenden Auge in den Laser gucken. - Vincent Ebert -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: [PATCH 4/8] wibox.layout.align: make the middle widget really centered
On 05.01.2013 16:12, Lukáš Hrázký wrote: Centers the middle widget in the align layout in the remaining space left by the widgets on the sides. [...] I'm still not really convinced by this. However, since we don't have anything else for centering widgets, I guess this can stay. However, this breaks awful.titlebar. The client name is now centered. Also, I just noticed that it would be good if you math.floor/ceil the result of the division by two. Otherwise, this will actually paint the widget at a non-integer position and cause antialiasing artifacts. Of course these thoughts only occurred to me after I merged this patch and since I'm lazy: Looking forward to your follow-up patches, Uli -- Bitte nicht mit dem verbleibenden Auge in den Laser gucken. - Vincent Ebert -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: [ANNOUNCE] awesome 3.4.14 released
Hi, On 24.12.2012 19:02, Renato Botelho wrote: I got the following error on FreeBSD 9: [ 52%] Generating manpages/man1/awesome.1.xml cd /work/a/ports/x11-wm/awesome/work/awesome-3.4.14/manpages/man1 /usr/local/bin/asciidoc -d manpage -b docbook -o /work/a/ports/x11-wm/awesome/work/awesome-3.4.14/manpages/man1/awesome.1.xml - /work/a/ports/x11-wm/awesome/work/awesome-3.4.14/manpages/awesome.1.txt asciidoc: ERROR: [attributes] missing 'attributelist-pattern' entry asciidoc: FAILED: unexpected error: asciidoc: Traceback (most recent call last): File /usr/local/bin/asciidoc, line 5939, in asciidoc AttributeList.initialize() File /usr/local/bin/asciidoc, line 1923, in initialize AttributeList.pattern = document.attributes['attributelist-pattern'] File /usr/local/bin/asciidoc, line 115, in __getitem__ return dict.__getitem__(self, key.lower()) KeyError: 'attributelist-pattern' *** [manpages/man1/awesome.1.xml] Error code 1 Which version did you try before? manpages/awesome.1.txt did not change since 3.4.10 aka almost two years ago. Could it be that your asciidoc version changed? Something like that? Uli -- In the beginning the Universe was created. This has made a lot of people very angry and has been widely regarded as a bad move. -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: git head slow
On 24.12.2012 10:47, Andreas Radke wrote: Am Mon, 12 Nov 2012 11:13:14 +0100 schrieb Yuri D'Elia wav...@users.sourceforge.net: Hi everyone. I was checking out the sources of awesome to try doing some work on focus stealing yesterday, but I was suprised of how slow is (rev 6a6e49...) compared to 3.4.13 (debian unstable). [...] I can confirm this slowness here in Arch and Awesome 3.5 - but only with closed Nvidia driver. Another system with free AMD/Ati driver is still fast. Using cairo with the buggy gradient patch improves situation but it's still slower than 3.4.x was. Does awesome --no-argb help? (Yay for undocumented options) Uli -- Bitte nicht mit dem verbleibenden Auge in den Laser gucken. - Vincent Ebert -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: git head slow
Hi, On 24.12.2012 12:19, Andreas Radke wrote: Am Mon, 24 Dec 2012 11:30:24 +0100 schrieb Uli Schlachter psyc...@znc.in: Does awesome --no-argb help? (Yay for undocumented options) Uli Yes. This improves situation a lot. Thanks for the hint. What does it do? Is there any reason to not use this? By default awesome used to use the X server's default visual for the windows that it creates (surprise). This is likely a 24bpp RGB visual (so just what you specify in your theme with #rrggbb). However, awesome 3.5 is a reparenting WM and this makes real transparency complicated. If you start urxvt -depth 32 -bg rgba:/// (and are running a compositing manager), you will not get a transparent background, because the transparency will be drawn ontop of the frame window that awesome uses (which nothing ever really draws to and has an opaque black background). The easy fix for this was to use an RGBA visual which adds an alpha channel to colors and makes real transparency possible (if you are running a compositing manager). I think that other WMs do this, too, but they only use an RGBA visual if the client window itself uses one. Me being lazy, I just always use an RGBA visual. This also makes it possible to e.g. specify #rrggbbaa as a background color of a wibox and have real transparency in a wibox. Back when I wrote this code, I got graphic corruption when switching tags. The screen wasn't properly redrawn. This was a bug in the intel driver (and it was fixed since then). Thus, --no-argb was added which makes awesome use the default visual again (and which breaks real transparency). The bug you are seeing sounds like the nvidia binary blob is awfully slow with 32bpp windows. If you aren't using a compositing manager, you aren't losing anything with --no-argb. Otherwise, real transparency will break. I hope that the above explains the situation at least half clearly. Uli -- - Buck, when, exactly, did you lose your mind? - Three months ago. I woke up one morning married to a pineapple. An ugly pineapple... But I loved her. -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
[ANNOUNCE] awesome 3.4.14 released
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi everyone, I am writing too many announcements lately, so let's make this one quick: There were still some changes for awesome 3.4 in git which I didn't want to just be thrown away, so they get a new 3.4 release. Of course, this should not break anything and be fully compatible with 3.4.13. However, this is meant to be the last release for the 3.4 branch. The big changes since 3.4.13 are proper(?) support for Xlib cursor themes and a bug fix for naughty to properly handle an unusual row stride in some of gmusicbrowser's notifications. Merry Christmas and a Happy New Year, Uli awesome version 3.4.14 has been released. It is available from: tar.xz: http://awesome.naquadah.org/download/awesome-3.4.14.tar.xz md5: 951d5438a8391dcc72e0c6271eed7689 sha1: 7ae1e661ea74b8230715bc5f4b12abd7be36f5af tar.bz2: http://awesome.naquadah.org/download/awesome-3.4.14.tar.bz2 md5: 65af4a97747f91c3b9d3107e1ec5377e sha1: b4b13d6a80b0d9efcb94a08afd040878355a66f9 number of changes - - 9 number of commiters - --- 5 shortlog - Steven Oliver (3): Add NoDisplay to .desktop file (FS#1031) Remove incorrect comment. Have only FreeBSD require dynamic linking (FS#743) Uli Schlachter (3): Add x11-xcb to the pkg-config checks naughty: Correctly handle rowstride on icons change codename Edward O'Callaghan (1): Add platform support for DragonflyBSD. Sébastien Luttringer (1): Fix client screen in awful.client.setslave Tumin Alexander (1): Added initial support for Xlib cursor themes -- for branch 3.4 diffstat - CMakeLists.txt |9 ++--- awesome.c | 12 +++- awesome.desktop |1 + awesomeConfig.cmake |6 -- common/util.h |2 +- common/xcursor.c| 19 +++ common/xcursor.h|3 ++- globalconf.h|2 ++ lib/awful/client.lua.in |2 +- lib/naughty.lua.in | 25 - mousegrabber.c |2 +- root.c |2 +- wibox.c |4 ++-- 13 files changed, 47 insertions(+), 42 deletions(-) - -- Every once in a while, declare peace. It confuses the hell out of your enemies - 79th Rule of Acquisition -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBCAAGBQJQ2GxKAAoJECLkKOvLj8sGz7kH/2zdFW0aiz1+wbeIQbGDmiE9 tOPbMQ6AXyGlq4RsMjPMh9gNtV1BG6LKHdsr1JfnMLHYPvfb/VQsxGBJgH0UgBNa Gytp1+Bii7CbXJt5+XI1kHDeK7jzBQtvF+8/LW36QZt0y0eUA56fPOHRF9ttyEBo BjC9k1iz7F7Z9HT79r2EEIMfvtYESlv6mqxbmsf1gagRcv4HEv1CT75dOQspR28j UNoHCsHtKRUBRhF/JLU2xutreWJtQL64yI7UARdNz+tYdkE0PBjnreLwITeHTmuf mcJQbzJd0h/Eddoa138S1mvtwxB4TLke0h8nuqZLIDaf1/y2hZsa2Alu+glF43k= =f3HY -END PGP SIGNATURE- -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
[ANNOUNCE] awesome 3.5 released
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi everyone, it's been a while. The last major release happened more than three years ago. However, even longer ago, a civilization known as the Maya predicted that today a great pain will be brought to everyone (Don't trust the Date header of this mail or you will get a long and weird explanation about time zones and other weak excuses). Today is the day of thousand crys from users whose config broke. Today is the end. Welcome to the time after the end. If you want to learn about what is new, read the summary in [0]. If you want to get a quick guide for porting your config to the new version, read [1]. If you want to party, grab a beer (or party without a beer, I don't mind). If you go to 29c3, please tell me (and re-read the previous point). If you are using arch linux, you will see this release on a computer near you very soon. Good luck. Let's use this announcement to fight some FUD and do a quick (fake) QA session: - -- Do I really have to do changes to my config? My config is almost identical to 3.4's default config! It's entirely impossible that your config will not break. Now read [1] again. - -- How did awesome's dependencies change compared to 3.4? Here is a quick and likely incomplete list. Removed dependencies: libev, gperf, luadoc New dependencies: lgi, ldoc, glib (at least version 2.30, sorry Renato) - -- I don't have lgi but awesome built fine. Are you sure it's needed? Yes, I am. However, lgi is a runtime-only dependency. It is not needed for building awesome at all. However, the lua code will do require(lgi) and hell will break lose if you don't have lgi (and gobject-intospection files for cairo, Pango and PangoCairo). - -- What does lgi stand for anyway? Lua GObject Introspection. GObject Introspection is a way for automatically and easily generating language bindings for libraries implemented via GObject. Lua is a programming language. lgi gets us lua bindings to GObject. Awesome needs this for cairo, Pango and PangoCairo (although cairo does not use GObject, but you really do not want to know the details about why it still works). See [2]. - -- What's up with lua 5.2? Awesome should work fine with either lua 5.1 and 5.2. Both versions shouldn't cause any major headaches and you will *not* lose any feature due to your lua version. Contrary to popular belief, this means that the API documentation built with ldoc can also be generated when you only have lua 5.1. However, the build system still needs some love. It is only looking for liblua.so or liblua51.so (and similar for the headers). So if you have lua 5.2 and your distro puts this version number into paths and file names, you might need some magic in your CMake call. Sadly, I can't tell you currently which magic this is. A good starting point might be: make CMAKE_ARGS='-DLUA_INCLUDE_DIR=/usr/include/lua5.2 - -DLUA_LIBRARY=/usr/lib/liblua52.so' - -- What happened to luadoc? It was replaced with ldoc. This was needed because luadoc is incompatible with some internal changes. Also, ldoc is a lot better at producing useful error messages than luadoc is. (Yes, ldoc works with both lua 5.1 and lua 5.2) See [3]. - -- I found a bug, what do I do now? That's not a bug. It's just an unexpected feature / a easter egg / cosmic rays / a butterfly moved its wing in a weird way / a magnetized needle moved wrongly. - -- Will the world really end? Yes - -- Will it blend? No - -- Do these last three questions make any sense? No, but I answered your weird questions anyway. Cheers, Uli [0]: http://article.gmane.org/gmane.comp.window-managers.awesome/9581 [1]: http://awesome.naquadah.org/wiki/Awesome_3.4_to_3.5 [2]: https://github.com/pavouk/lgi [3]: https://github.com/stevedonovan/LDoc awesome version 3.5 has been released. It is available from: tar.xz: http://awesome.naquadah.org/download/awesome-3.5.tar.xz md5: ce998f19c80bd98f8d119a91f53526df sha1: 98b26904804067f1e995586204d1829c1a7b166b tar.bz2: http://awesome.naquadah.org/download/awesome-3.5.tar.bz2 md5: 49782eabce5bcd4e6a83b2b314dad39d sha1: d35402a09fd5900a7309eb9ee5f5350378029d49 number of changes - - 6 number of commiters - --- 2 shortlog - Uli Schlachter (5): awful.widget.button: Fix name clash (FS#1064) naughty: Fix docs a little awful.placement.no_offscreen: Fix border handling (FS#1065) wibox button: Fix the x/y position in button events change codename Daniel (1): Expose naughty.notifications again diffstat - awesomeConfig.cmake|2 +- event.c|4 ++-- lib/awful/placement.lua.in |6 +++--- lib/awful/widget/button.lua.in |4 ++-- lib/naughty.lua.in | 41 +++- 5 files changed, 27 insertions(+), 30 deletions(-) - -- For saving the Earth.. and eating cheesecake
Re: [ANNOUNCE] awesome 3.5-rc2 released
[removed awesome@ from the CC list] Hi, On 17.12.2012 17:08, Renato Botelho wrote: [...] I'm maintainer of awesome on FreeBSD ports and I'm trying to build 3.5-rc2 when i got an error, a missing header glib-unix.h. I took a look and didn't find any port that install this file. Maybe it came from newer versions of glib, today we have glib 2.28 available on FreeBSD. Urgh. glib, why do you have to annoy me? All of [0] says that these functions are Since 2.30 and there were no alternatives to this before. Anyone has some good idea what to do about this? Awesome needs signal handling with the main loop since we need to do stuff inside the signal handler which is normally not allowed inside of a handler. Patches welcome, Uli [0]: http://developer.gnome.org/glib/2.30/glib-UNIX-specific-utilities-and-integration.html -- If you have to type the letters A-E-S into your source code, you're doing it wrong. -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
[ANNOUNCE] awesome 3.5-rc2 released
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi everyone, there isn't anything really exciting in here (which is a good thing for a rc2). Gregor finally sent in the patches that he has been sitting on and we got rid of a couple of weird bugs and corner cases. Of course, all of these were my fault, so feel free to send in your hate mails. Thanks to everyone who tested v3.5-rc1 and who provided feedback for the migration guide. This doesn't mean that the guide is perfect yet. So, before you upgrade, be sure to read it and afterward update it with all the useful information that you can provide: http://awesome.naquadah.org/wiki/Awesome_3.4_to_3.5 Thanks for flying awesome-airlines and have nice day, Uli - -- awesome version 3.5-rc2 has been released. It is available from: tar.xz: http://awesome.naquadah.org/download/awesome-3.5-rc2.tar.xz md5: 8c9ecbb949e5a5a39cfc5f60b38f2a7f sha1: 7250123281cd917c7b6106ba9de6b3708d327b4d tar.bz2: http://awesome.naquadah.org/download/awesome-3.5-rc2.tar.bz2 md5: 0115ddd77a89c4163f5f147bcb8b18cf sha1: 75cb0c5a8c0abe14d9e5cf2e52afe875075eb82f number of changes - - 20 number of commiters - --- 4 shortlog - Uli Schlachter (12): widgets: Add some constructor arguments awful.menu: Handle themes without border_width CMake: Check for the needed lgi dependency awful.menu.clients: Fix client icons imagebox: Use a different entry for saving the image Fix errors from missing themes Update titlebar color when focus changes (FS#1056) Fix various instances of global variables Fix wibox.layout.rotate Correctly handle focus across restarts (FS#1055) mouse.resize: Allow resize across screens (FS#1059) change codename Gregor Best (5): Change CFLAGS Remove compiler warnings Menubar: don't die if there's no item selected Menubar: also look in /usr/local/share/applications Menubar: silence find warnings Arvydas Sidorenko (2): Renamed string.gfind to string.gmatch Improved .desktop parsing (FS#1057) Björn Åström (1): Fix minimizedcurrenttags filter with sticky clients diffstat - CMakeLists.txt |4 awesome.c | 12 +++- awesomeConfig.cmake|6 +++--- build-utils/lgi-check.sh | 31 +++ common/luaobject.c | 12 ++-- common/luaobject.h | 12 ++-- dbus.c |2 +- lib/awful/menu.lua.in | 21 + lib/awful/mouse/init.lua.in|6 -- lib/awful/titlebar.lua.in | 17 +++-- lib/awful/util.lua.in |4 ++-- lib/awful/widget/button.lua.in |5 - lib/awful/widget/tasklist.lua.in |4 ++-- lib/beautiful.lua.in |2 +- lib/menubar/init.lua.in|1 + lib/menubar/menu_gen.lua.in|2 +- lib/menubar/utils.lua.in | 30 +- lib/wibox/drawable.lua.in |3 +-- lib/wibox/layout/rotate.lua.in |2 +- lib/wibox/widget/background.lua.in |4 +++- lib/wibox/widget/base.lua.in |8 lib/wibox/widget/imagebox.lua.in | 28 +++- lib/wibox/widget/systray.lua.in|2 +- lib/wibox/widget/textbox.lua.in| 10 +- 24 files changed, 160 insertions(+), 68 deletions(-) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBCAAGBQJQy4iKAAoJECLkKOvLj8sGZ/4H/2sWlKF4cNEH6jiRC907lVR1 Tr350H9yXPVh7Hp4ZsyDeBpouM4fLyS414os9dZP20JXGRGDFtz9No5isP1vVgik RbzRFM4ab5Z9Dcdre688SVAyadV3Dx116G5N27WT2cXcy2ZBmMtslRF31LtGKfUj fpegpfgjPXG9+w2DvwFfHlhjMcrsDpb6EO54Q24ArOg4hGzZiD5YiFh4tQFYoq2P mXnPU7rLyRkIx3KC8SDRxbRizUMVnPTIiyIcYDgYSPsQeObohwfcKaLjwVgqzdle BjPKOhajXP102L+Y45MmfMf9S8MFyHn+2nOM2OeN4LZ1d4X/56Vy63OLBnMFmy8= =N80I -END PGP SIGNATURE- -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: [PATCH] Fix minimizedcurrenttags filter with sticky clients
On 13.12.2012 03:30, Björn Åström wrote: Sticky clients showed up in the tasklist without being minimized when using the minimizedcurrenttags filter. This patch fixes that. Signed-off-by: Björn Åström bjo...@gmail.com Thanks, pushed. -- Why make things difficult, when it is possible to make them cryptic and totally illogical, with just a little bit more effort? -- A. P. J. -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: [PATCH] Lua 5.1 compatible gmatch
On 30.11.2012 15:47, Arvydas Sidorenko wrote:
Lua 5.1: string.gfind renamed to string.gmatch
Lua 5.2: string.gfind removed
Uhm. So in lua 5.1 string.gfind and string.gmatch is the same function. Lua 5.2
only has string.gmatch.
Why don't we just always use gmatch then? Shouldn't that work in both 5.1 and
5.2? No need for distinguishing between the different versions here.
Uli
Signed-off-by: Arvydas Sidorenko asi...@gmail.com
---
lib/menubar/utils.lua.in | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/lib/menubar/utils.lua.in b/lib/menubar/utils.lua.in
index e45a8bc..495314d 100644
--- a/lib/menubar/utils.lua.in
+++ b/lib/menubar/utils.lua.in
@@ -9,6 +9,7 @@ local io = io
local table = table
local ipairs = ipairs
local string = string
+string.gmatch = string.gfind or string.gmatch -- v5.1 - gfind; v5.2 - gmatch
local awful_util = require(awful.util)
local theme = require(beautiful)
@@ -150,7 +151,7 @@ function utils.parse(file)
-- line separated by semicolon.
if program.Categories then
program.categories = {}
-for category in program.Categories:gfind('[^;]+') do
+for category in string.gmatch(program.Categories, '[^;]+') do
table.insert(program.categories, category)
end
end
--
In the beginning the Universe was created. This has made a lot of
people very angry and has been widely regarded as a bad move.
--
To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: [PATCH] Lua 5.1 compatible gmatch
On 01.12.2012 14:09, Arvydas Sidorenko wrote: Why don't we just always use gmatch then? Shouldn't that work in both 5.1 and 5.2? No need for distinguishing between the different versions here. Indeed. A new patch attached. Thanks, pushed. -- Why make things difficult, when it is possible to make them cryptic and totally illogical, with just a little bit more effort? -- A. P. J. -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: [PATCH] menubar: Handle .desktop files with multiple sections
On 01.12.2012 15:59, Arvydas Sidorenko wrote: I am trying to read and understand the specification. If I understand this correctly, then a Desktop Entry group is required and this is what we are really interested in. The only other kind of group that I have found are Actions which e.g. is Play/Pause/Previous/... in the case of totem. None of these seem to make any sense for the menubar, do they? Agree. I have attached my solution. Btw, freedesktop specifies that whitespaces around '=' in key=value are allowed and should be ignored. Thanks, merged. Should this be enough to fix FS#1057 or am I missing anything? Uli -- my $key = \x49\x03\x93\x08\x19\x94\x96\x94\x28\x93\x83\x04\x68\x28\xa8\xf5. \x0a\xb9\x94\x02\x45\x81\x93\x1f\xbc\xd7\xf3\xad\x93\xf5\x32\x93; my $cipher = Crypt::Rijndael-new( $key, Crypt::Rijndael::MODE_ECB() ); my $plain = $ciper-decrypt($daten); -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: Shape extension / lua binding
On 23.11.2012 06:15, Majic wrote: I would like to see how you use this, Arnaud :o Haven't touched on that myself... On Tue, Nov 6, 2012 at 8:16 PM, Uli Schlachter psyc...@znc.in wrote: On 05.11.2012 15:12, Arnaud VALLAT wrote: Is it planned to add back a shape / clipping feature like it was before? I'm looking at the master branch, and there is no such method now, I would like to have my rounded corners back ^^ Done. Thanks for flying awesome airlines. Here is some really, really, really pointless example that all of you should add to your rc.lua: local cairo = require(lgi).cairo function make_image(size) local img = cairo.ImageSurface.create(cairo.Format.A1, size.width, size.height) local cr = cairo.Context(img) cr:set_operator(cairo.Operator.SOURCE) cr:set_source_rgba(0, 0, 0, 0) cr:paint() cr:set_source_rgba(1, 1, 1, 1) cr:move_to(0, 0) cr:line_to(size.width, size.height) cr:line_to(0, size.height) cr:fill() return img end function make_client_ugly(c) local geom = c:geometry() local clip = make_image(geom) geom.width = geom.width + 2 * c.border_width geom.height = geom.height + 2 * c.border_width local bounding = make_image(geom) c.shape_clip = clip._native c.shape_bounding = bounding._native -- The following isn't necessary (the garbage collector does it for -- you), but it saves memory clip:finish() bounding:finish() end client.connect_signal(property::geometry, make_client_ugly) Cheers, Uli -- Q: Because it reverses the logical flow of conversation. A: Why is putting a reply at the top of the message frowned upon? -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
[ANNOUNCE] awesome 3.5-rc1 released (was: [ANNOUNCE] awesome 3.4-rc1 released)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi everyone, On 11.09.2009 14:05, Julien Danjou wrote: With a good month late, here comes 3.4-rc1. With a good two years late, here comes 3.5-rc1. There's an amazing number of changes, but many are internals ones, so you won't notice them.[...] There's an astonishing number of changes. Also, we did some changes to make awesome future-proof. With lua 5.2, module() was deprecated in lua. Awesome no longer uses this function. However, this has user-visible effects. You now need to explicitly assign modules to global variables: local awful = require(awful) Some things from the default rc.lua have been moved into awful to ease the configuration file management. The default rc.lua is 110 lines lighter now. The rc.lua is 50 lines longer now. 40 lines of that is due to a titlebar rewrite. Instead of forcing some kind of titlebars on the user, titlebars are now configured similar to wiboxes. The new widget layout system is also in place. Everyone will hate me for replacing the widget system again, but I do like the result. Due to this, everything works differently now. On the plus side, you won't need to use mywidget.widget ever again. :-) There's obviously a number of changes all over the place. I don't have the list in mind of course, so feel free to dig into the changelog. [...] The same applies to this release, too! Again, there is a wiki page for documenting some changes that affect configurations. Feel free to update it with any kind of information which you would have hoped to find here, but had to figure out the hard way (= asking me). http://awesome.naquadah.org/wiki/Awesome_3.4_to_3.5 As always, we all here at breaking-your-config-WMs would like to thank all contributors. Without your bug reports, patches, ideas and good questions, this window manager would suck a lot more than it already does. One thing I want to highlight: A total of 77 different people wrote patches for this release! Have fun! Uli awesome version 3.5-rc1 has been released. It is available from: tar.xz: http://awesome.naquadah.org/download/awesome-3.5-rc1.tar.xz md5: 42b76ed6a60ca376e1e0afb859986645 sha1: 2ab103a0a9675468f1dafc35e3df756e3d31b20b tar.bz2: http://awesome.naquadah.org/download/awesome-3.5-rc1.tar.bz2 md5: 1be1cb43adbc7242a6c53d3cc01a62bd sha1: 8c9b558cfa9293453fb1befda9ac06b365e15df2 number of changes - - 820 number of commiters - --- 77 shortlog - Uli Schlachter (444): wibox: Set a proper back pixel Set a wibox' bit gravity to NorthWest. wibox: make sure no garbage is painted to the screen wibox: check if a wibox' window exists before modifying it Wibox: Check if a window exists before changing it Fix a invalid pointer crash bug image: Use imlib2's image cache Make it easier to change the default layout Implement the GetCapabilities call in naughty Handle synthetic UnmapNotify events Revert Handle synthetic UnmapNotify events Handle synthetic UnmapNotify events *correctly* client_focus_update(): Balance the lua stack property.c: Don't leave stuff on the lua stack Check for UNMAPPED instead of UNVIEWABLE Use WM_STATE_NORMAL as default awesome.spawn(): Return the PID Update API docs for recent change to spawn Check for xwininfo before using it awful.menu.clients: Raise the newly focused client Tasklist: Add some missing parentheses Remove _NET_WM_DESKTOP when client got no tags Handle _NET_WM_DESKTOP more intelligently Remove invalid variable usage Update the tasklist when a client's icon changes xwindow_set_state(): Use uint32_t instead of long Reorder some code for fullscreening windows Tasklist: Listen to the correct signals Add systray windows to the save-set Don't reparent systray windows on exit Add all managed client windows to the safe set Don't manually unban all windows on exit Handle errors in the config better Read a textbox' text correctly textbox: Throw a lua error on invalid markup Naughty: Catch invalid markup in notifications Clear a draw_text_context_t during wipe() Move wibox_systray_kickout() up Kick out the systray when wiping a wibox Add a comment to XCB_NONE for sibling Avoid some flickering when a new window opens Split up screen_scan() Screen: Only use Xrandr if it provides data Ignore size hints on fullscreen windows Minor cleanup Fix a minor ICCCM incompatibility Fix some size hint mixups Improve aspect size handling Make fullscreen stacking respect EWMH Fix an unbalanced lua stack operation awful.placement: Honor border width Remove windows from the save set in unmanage Remove systray icons from the save set Stack clients without causing X11 errors
Re: [Patches] assorted fixes
Hi, On 24.11.2012 18:07, Gregor Best wrote: after a (quite long) abstinence from awesome, here is a bunch of patches: at least you send them in now and didn't keep them to yourself... All merged, thanks! Uli -- - Captain, I think I should tell you I've never actually landed a starship before. - That's all right, Lieutenant, neither have I. -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: [PATCH] Expose wm_name to the user
On 22.11.2012 13:35, Ignas Anikevicius wrote: On 22/11/12 11:20:57 +, Ignas Anikevicius wrote: -- or if it's equal to 'awesome' This line should be changed as well... Attaching a fixed patch. Applied, thanks PS. Sorry for spamming everybody. It's not you, it's the mailing list who spams people. :-P Possible usecase: A user is using Gnome and Awesome together, but sinc wm_name by default is awesome, all the apps shipped with GNOME DE are hidden by default. Changing wm_name attribute in this case would solve the issue. Wouldn't that be more of a bug in the .desktop files? Why should they only be displayed in Gnome?! Uli -- In the beginning the Universe was created. This has made a lot of people very angry and has been widely regarded as a bad move. -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: git head slow
Hi, On 12.11.2012 11:13, Yuri D'Elia wrote: Hi everyone. I was checking out the sources of awesome to try doing some work on focus stealing yesterday, but I was suprised of how slow is (rev 6a6e49...) compared to 3.4.13 (debian unstable). There seems to be some sort of obvious problem with the tile layout at least. When switching through terminals I can notice the borders of all the windows being repainted in the tile. Awesome does not paint any window borders. It just tells the X11 server which size and color the borders have. If I float a terminal and I resize it though the mouse all the other windows shake too (it's like the windows are being relaidout at every event). Awesome re-layouts windows quite a lot. Like, *really* often. But awesome 3.4 does that, too, so nothing changes about it. However, nothing should shake, because windows get the position that they are already at. This is less noticeable if all the windows don't have geometry hints or all of them are floated. Geometry hints? Why does that matter? Another thing I noticed is the new menubar. It's very nice (I quickly trashed the launcher entirely) but it's also equally slow. Pressing left-right or any event takes almost 2 seconds to respond on a 1.3ghz box when displaying the debian standard menu. Could you strace awesome and show me/us the result? Something like strace -ttT -o /tmp/trace.out awesome and then doing some slow actions and exiting awesome again. Beware, the file will be huge. The only syscall that may take a while should be epoll_wait(). Uli -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: Patch for gaps between windows in the fair tiling mode
Hi, On 06.11.2012 02:00, Josh Komoroske wrote: I noticed a bug in how the fair tiling mode calculates window sizes. Scenario description: Say you screen height is 1000px. Say you had 3 windows stacked in some column. The height of each window is calculated as: screen height / window count = 1000px / 3 = 333.33px == 333px Now we have 3 windows with a height of 333px. But, when stacked, those 3 windows add up to 999px, leaving a 1px gap! The same also happens for window width. The attached patch fixes the window size calculations, and supports both fair-south and fair-east tiling modes. Any feedback is welcome. First: Sorry for me being awfully slow. Second: I wanted to make some small changes to this patch before I push it and forgot. Meh. Anyway, here is what I would have done differently (just some minor stylistic nitpicking): +local row, col = 0, 0 +row = k % rows +col = math.floor(k / rows) I would just do: local row, col = k % rows, math.floor(k / rows) +local lrows, lcols = 0, 0 +if k = rows * cols - rows then +lrows = #cls - (rows * cols - rows) +lcols = cols else +lrows = rows +lcols = cols +end I'd just do: local lrows, lcols = rows, cols if k = rows * cols - rows then lrows = #cls - (rows * cols) - rows lcols = cols end Both of these changes make the code shorter, remove an unnecessary assignment and IMHO don't hurt readability too much. However, I guess I shouldn't even mention this, because you picked that up from the original code. So, just to remove any doubt: Thanks for this code. I guess there is always something to complain about and the above is really not important. So this is complaining on a very high level. :-) I reproduce the bug your describe with the default config. I guess I wouldn't ever have noticed this myself, my wallpaper just has the wrong color. I am not sure if I managed to reproduce this with the default config, but at the time I thought I did. Some quick testing suggests that your patch makes the problem go away and don't break anything and I can't spot anything wrong in the diff. So, again, thanks a lot for the patch! Cheers, Uli -- - Captain, I think I should tell you I've never actually landed a starship before. - That's all right, Lieutenant, neither have I. -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: Shape extension / lua binding
On 05.11.2012 15:12, Arnaud VALLAT wrote: Is it planned to add back a shape / clipping feature like it was before? I'm looking at the master branch, and there is no such method now, I would like to have my rounded corners back ^^ Done. Thanks for flying awesome airlines. -- my $key = \x49\x03\x93\x08\x19\x94\x96\x94\x28\x93\x83\x04\x68\x28\xa8\xf5. \x0a\xb9\x94\x02\x45\x81\x93\x1f\xbc\xd7\xf3\xad\x93\xf5\x32\x93; my $cipher = Crypt::Rijndael-new( $key, Crypt::Rijndael::MODE_ECB() ); my $plain = $ciper-decrypt($daten); -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: NetworkManager applet appears 2 times in system tray
Hi, On 01.11.2012 09:23, Stefano Di Martino wrote: I have the strange effect, that, if I'm pasting this in my awesome-config, the NetworkManager applet it appears two time in my system tray: |awful.util.spawn_with_shell(nm-applet --sm-disable ) Is that a bug? Well, I guess you are starting the applet twice and thus it does appear twice in the systray. What else would happen? (And no, it is impossible for awesome to duplicate a single systray icons, because it only places them, but does not draw them.) Uli -- A learning experience is one of those things that say, 'You know that thing you just did? Don't do that.' -- Douglas Adams -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: NetworkManager applet appears 2 times in system tray
Hi, On 01.11.2012 11:10, Stefano Di Martino wrote: Yes and No. For instance, when I'm restarting awesome n time, the applet appears n times in the system tray. Do you think this should be treated like a desired behaviour? [...] Well, no. However, we can't do anything about your config starting nm-applet on each restart unconditionally. There are some run_or_raise implementations in the wiki, but I don't think that they will work with nm-applet. Alternatively, you could start nm-applet in your .xsession instead of rc.lua. Uli -- A learning experience is one of those things that say, 'You know that thing you just did? Don't do that.' -- Douglas Adams -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: awful.widget.prompt keyboard layout
Hi, On 30.10.2012 00:28, Alexander H wrote: On 29.10.2012 15:02, Alexander H wrote: Since some time on the git-master the awful promt does not adhere to the set keyboard-layout. I was wondering how I can set this or if this perhaps is an unintended regression. [...] working: v3.4-768-ged9f218 broken: v3.4-769-g531f8b4 What version are you using right now? Is it at least v3.4-783-g779d43f? Uli -- Why make things difficult, when it is possible to make them cryptic and totally illogical, with just a little bit more effort? -- A. P. J. -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: awful.widget.prompt keyboard layout
Hi, On 29.10.2012 15:02, Alexander H wrote: Since some time on the git-master the awful promt does not adhere to the set keyboard-layout. I was wondering how I can set this or if this perhaps is an unintended regression. I don't think that I messed with anything keyboard layout related. Ever. It would be great if you could ask git bisect to figure out when this started. Google should be able to tell you more. Uli -- - He made himself, me nothing, you nothing out of the dust - Er machte sich mir nichts, dir nichts aus dem Staub -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: [PATCH] Fix a bug when using in a rule the property 'tag'.
Thanks a lot. I only tested some basic stuff with the default config and my own
config. In other words, there will likely be lots of other bugs hiding... :-(
Cheers,
Uli
On 26.10.2012 01:26, Clément Démoulins wrote:
---
lib/awful/rules.lua.in | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/awful/rules.lua.in b/lib/awful/rules.lua.in
index c8be765..20983cc 100644
--- a/lib/awful/rules.lua.in
+++ b/lib/awful/rules.lua.in
@@ -174,7 +174,7 @@ function rules.apply(c)
aclient.floating.set(c, value)
elseif property == tag then
c:tags({ value })
-c.screen = value.screen
+c.screen = atag.getscreen(value)
elseif property == switchtotag and value and props.tag then
atag.viewonly(props.tag)
elseif property == height or property == width or
--
- Buck, when, exactly, did you lose your mind?
- Three months ago. I woke up one morning married to a pineapple.
An ugly pineapple... But I loved her.
--
To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: spawned process can't see environment variables
Hi, On 18.10.2012 11:18, Rena wrote: I have awesome started from a shell script, and it can see variables defined in .bashrc/.bash_profile just fine. How did you check this? What kind of shell script are you starting awesome from? However, processes started with util.spawn or util.spawn_with_shell can't seem to see them. Is this a known issue? Spawned processes inherit awesome's environment. They get exactly[0] the same environment variables as awesome is running in. Uli [0]: Well, not exactly. Due to startup notification, some extra variable gets set. But I don't think this matters here. :-P -- Do you know that books smell like nutmeg or some spice from a foreign land? -- Faber in Fahrenheit 451 -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: Request for better awesome standard config
Hi, On 07.10.2012 22:14, Stefano Di Martino wrote: [...] Surely it would be easy for you to support some basic features, like shutdown and hibernate the computer. I've found an extension that do this, but it isn't working well. For example, if I want to shut down my computer, I have to enter my password and in the end the computer hangs up trying to shutting down the computer. Welcome to Unix where only the administrator is allowed to shut down a computer. If you know some way for normal users to shut down the computer that works on most systems, I'd be happy to add it to the default config. There might be something like this hiding on dbus with PolicyKit + magic, but I don't know how that works. Also, that solution would hardly be portable to most systems. On how kde and gnome manage to do this: Those are desktop environments. They have their own login manager (kdm / gdm) and login managers obviously must run as root and thus have the power to turn of the computer. There is some private (undocumented?) protocol between the session and the display manager which allows turning off the computer. At least I think so. I bet that gnome/kde don't offer a shutdown button when they are run through startx instead of a login manager. Cheers, Uli P.S.: No, I will not write a login manager. -- my $key = \x49\x03\x93\x08\x19\x94\x96\x94\x28\x93\x83\x04\x68\x28\xa8\xf5. \x0a\xb9\x94\x02\x45\x81\x93\x1f\xbc\xd7\xf3\xad\x93\xf5\x32\x93; my $cipher = Crypt::Rijndael-new( $key, Crypt::Rijndael::MODE_ECB() ); my $plain = $ciper-decrypt($daten); -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: Request for better awesome standard config
Hi, On 07.10.2012 22:58, Emmanuel Lepage Vallee wrote: On 10/07/2012 04:22 PM, Adrian C. wrote: On Sun, 7 Oct 2012, Stefano Di Martino wrote: I've found an extension that do this, but it isn't working well. For example, if I want to shut down my computer, I have to enter my password and in the end the computer hangs up trying to shutting down the computer. Awesome moves windows on your screen it doesn't have anything to do with power management. You know that, right? When you find a solution you want to use (with sudo/ksudo/gksudo passwordless or not, or with PolicyKit, or by another method) you add execution of that command to your awesome menu. I think at some point we should split awesome package in 2, awesome-minimal and awesome-shell or something like that. I think -minimal would still be the most popular of the 2, but there is probably a market for a tiled based desktop shell. Feel free to start an awesome-shell. I don't think anyone else is doing that already (although I am not really sure what exactly it would be doing). While the suckless philosophy of if you can't make it work then we don't want you as our user have some advantages, I don't think it can exploit the whole potential of the project. The current defaults are enough for most users, but how can having a separated set of defaults with more modern extensions like freedesktop menu (not the one from the wiki, it take 1.4 million loop cycle just to load it), There already is some freedesktop-menu-something in latest git (called menubar). Dunno how many cycles it takes to load it, but I bet that the disk I/O is more of a problem than CPU usage anyway. vicious, You can already use vicious with awesome. And why would it become part of awesome? Parts of it are linux specific and I am using obvious instead anyway. networkmanager (like it or not, wicd is not that common outside of arch), Doesn't networkmanager have a systray icon? The same systray icon that is also available in gnome? What more do you want? udisk, upower, Ah, upower was that daemon which allows users to turn of the computer. Besides that: What exactly are udisk and upower doing and why would it be a good idea for a window manager to depend on these linux-specific daemons? Or do they work on e.g. BSDs, too? right click menus everywhere, Don't we have a right click menu almost everywhere? Well, ok, on the taglist a right click selects a tag and doesn't open a menu, but that doesn't count. overall mouse mouse friendlyness Well, patches welcome. The important stuff should already be accessible via the mouse, I think. Even things like the master window factor can be changed with (mod4 and) the mouse. and a more complex theme could be appealing for many. Sorry, no idea what a more complex theme. Do you want fancy animations? If I am ever to do that, then I have to make ultilayout work fine on both master and 3.4 first. I kind of get a enlightenment 17 feeling about it, always so close to completion, but never close enough. (ultilayout is a replacment for the client layout system with support for dynamic layouts, tabs, mouse, titlebar, plugins and extensions at an atomic level, so absolutely everything can be done with it with little code and for all layout at once. It mostly work and support all features from the old one but multiple tags at once (trivial to fix) but it need some love before I can call it stable). Will it blend? ;-) This list sounds amazing, I am looking forward to the patches. Back to the topic, if I think Stefano have a point, but I disagree we should change the default rc.lua to fix the issues. For now, the extensions will be enough, in the future, well, we will see. Cheers, Uli -- my $key = \x49\x03\x93\x08\x19\x94\x96\x94\x28\x93\x83\x04\x68\x28\xa8\xf5. \x0a\xb9\x94\x02\x45\x81\x93\x1f\xbc\xd7\xf3\xad\x93\xf5\x32\x93; my $cipher = Crypt::Rijndael-new( $key, Crypt::Rijndael::MODE_ECB() ); my $plain = $ciper-decrypt($daten); -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: [PATCH] Added initial support for Xlib cursor themes
On 06.10.2012 17:40, Tumin Alexander wrote: I hope this time i got all right with git format-patch. Signed-off-by: Tumin Alexander iamtakingite...@eientei.org [...] Thanks, both patches merged. Uli -- - He made himself, me nothing, you nothing out of the dust - Er machte sich mir nichts, dir nichts aus dem Staub -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: Simple patch enabling mouse cursor themes in awesome wm
Hi,
On 06.10.2012 14:27, Alexander Tumin wrote:
Hi, i wish to share a simple patch enabling Xcursor themes support in
awesome wm (3.4.13).
Yes, not without Xlib, but unlike xcb it _is working_ instead of
managing elitist purity of library calls.
Urgh. :-P
Here it is, in mail attachment.
And in case it won't be allowed by MTA, here are [breakable] urls to
it:
ftp://eientei.org/soft/awesome/x11-wm/awesome/files/awesome-3.4.11-mouse-xcursors.patch
-- the patch itself
ftp://eientei.org/soft/awesome/x11-wm/awesome/awesome-3.4.13-r1.ebuild
-- ebuild for your gentoo/funtoo/whatever emerge-driven package system.
diff -ru a/awesome.c b/awesome.c
--- a/awesome.c 2011-11-23 18:08:50.0 +0400
+++ b/awesome.c 2012-10-06 15:11:57.642625979 +0400
@@ -33,6 +33,8 @@
#include xcb/xinerama.h
#include xcb/xtest.h
+#include X11/Xlib-xcb.h
+
#include awesome.h
#include spawn.h
#include client.h
@@ -373,7 +375,9 @@
sigaction(SIGSEGV, sa, 0);
/* X stuff */
-globalconf.connection = xcb_connect(NULL, globalconf.default_screen);
+globalconf.display = XOpenDisplay(0);
+globalconf.connection = XGetXCBConnection(globalconf.display);
This no longer sets globalconf.default_screen to the number of the default
screen. From the top of my head, I don't know how to get that value out of Xlib,
but that should be possible.
For the argument to XOpenDisplay(): This is a pointer, so please use NULL
instead of 0.
On the error handling: XOpenDisplay() returns NULL when it fails. This would
then crash in XGetXCBConnection().
So this code:
if(xcb_connection_has_error(globalconf.connection))
fatal(cannot open display);
Should be moved up, before the call to XGetXCBConnection, and should be if
(globalconf.display == NULL) (Hm, and perhaps additionally checking with
xcb_connection_has_error() doesn't hurt? Dunno)
diff -ru a/common/xcursor.c b/common/xcursor.c
--- a/common/xcursor.c2011-11-23 18:08:50.0 +0400
+++ b/common/xcursor.c2012-10-06 15:21:43.288604110 +0400
@@ -137,12 +137,19 @@
* \return Allocated cursor font.
*/
xcb_cursor_t
-xcursor_new(xcb_connection_t *conn, uint16_t cursor_font)
+xcursor_new(Display *conn, uint16_t cursor_font)
{
-static xcb_font_t font = XCB_NONE;
+//static xcb_font_t font = XCB_NONE;
static xcb_cursor_t xcursor[countof(xcursor_font)];
+if (!xcursor[cursor_font]) {
+xcursor[cursor_font] = XcursorLibraryLoadCursor(conn,
xcursor_font_tostr(cursor_font));
+}
+return xcursor[cursor_font];
+/*
+*/
/* Get the font for the cursor */
+/*
if(!font)
{
font = xcb_generate_id(conn);
@@ -159,6 +166,7 @@
}
return xcursor[cursor_font];
+*/
}
Come on, you don't really want me to merge that mess? Could you just remove the
now-unused code instead of commenting it out?
[...]
The rest looks good to me.
Cheers,
Uli
--
If you have to type the letters A-E-S into your source code, you're doing it
wrong.
--
To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: client.lua:495 attempt to index global 'awful' (a nil value)
On 29.09.2012 00:20, Abdó Roig-Maranges wrote: Ok, I've been looking at it now. I'm sorry for the trouble... I should have been more careful. I've come up with three possible solutions: 1) Use something like this: http://stackoverflow.com/questions/8248698/recommended-way-to-have-2-modules-recursively-refer-to-each-other-in-lua-5-2 It involves requiring modules inside the functions that use them. 2) Move the code in client.lua involving focus.history to a third location. this way screen.lua and client.lua can both require it. 3) Duplicate the code in screen.lua needed by client.lua. I like 1): it is simple, and requires no changes to the library. I attach a patch with this approach. What do you think? I call hack, but since I don't really have any better ideas: Merged, Thanks! Also, thanks for reacting so quickly and sorry for me being slow. Uli -- A learning experience is one of those things that say, 'You know that thing you just did? Don't do that.' -- Douglas Adams -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: client.lua:495 attempt to index global 'awful' (a nil value)
Hi, On 28.09.2012 12:10, Stefan Hellmann wrote: yesterday i've update to the newest git version: awesome v3.4-767-g34c1c7d (Closing In) • Build: Sep 27 2012 14:34:24 for x86_64 by gcc version 4.6.2 (root@gargamel) • Compiled against Lua 5.1.5 (running with Lua 5.1) • D-Bus support: ✔ Now i get the above error message using modkey o (awful.client.movetoscreen) I'm not a programmer and don't know what it means. Can anyone help? So awful.client tries to use awful.client and awful.screen by these names. However, they aren't available this way. awful.client would be just client inside of the module and awful.screen needs a 'local screen = require(awful.screen)' at the beginning of the file. However, this doesn't work: lib/awful/screen.lua:15: loop or previous error loading module 'awful.client' We now have a cyclic dependency between awful.screen and awful.client. This is bad, bad, bad, bad. If no one has any good suggestions on this, I will have to revert Abdó's commits to fix this. Which isn't exactly good either... @Abdó: Ideas? How could those functions be done differently? :-( @Stefan: The best thing you can do right now is to keep using an older version. For example git checkout 5701c473d4e1c91e29be92594b237bcc6dbbea8a should give you a working version. Cheers, Uli -- Why make things difficult, when it is possible to make them cryptic and totally illogical, with just a little bit more effort? -- A. P. J. -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: cherry-pick c623734632010e4601ca4e369851bc79ab7f706f to 3.4.x
Hi,
On 17.09.2012 16:00, Anurag Priyam wrote:
From awes...@naquadah.org (subject: attemp to call nill value error in
newest awesome documentation example):
Anurag Priyam anurag08pri...@gmail.com wrote:
On Mon, Sep 17, 2012 at 2:03 AM, wojtek danilo
wojtek.danilo@gmail.com wrote:
I compled from source the newest awesome wm (without problems). I was trying
to run the example from here:
http://awesome.naquadah.org/doc/api/modules/awful.client.html#cycle
as:
[...]
awful.key({ modkey }, `, function ()
local urxvt = function (c)
return awful.rules.match(c, {class = URxvt})
end
for c in awful.client.cycle(urxvt) do
c.minimized = false
end
end),
[...]
Use awful.client.iterate instead.
awful.client.cycle added in 0d41d984687dd1c29ad2b73ad59b9ccac6d71bb3
was later renamed to awful.client.iterate in
c623734632010e4601ca4e369851bc79ab7f706f because it overrode an
existing method by the same name (awful.client.cycle).
The online documentation can't be fixed without making a release,
right? So maybe someone could cherry-pick
c623734632010e4601ca4e369851bc79ab7f706f to 3.4.x -- whatever the next
release branch is supposed to be, so we don't miss out on it in the
next release?
Meh. That would break user configs with a micro release for no good reason. Yes,
it is bad that this function is called differently between 3.4 and master and
the commit should have been applied to both branches back then (*if* there was
no release since it was added).
Changing it now would only annoy 3.4 users, sorry.
Or should I remind when the next release is going to happen?
What? You get a warning shortly before a release? :-)
Cheers,
Uli
--
my $key = \x49\x03\x93\x08\x19\x94\x96\x94\x28\x93\x83\x04\x68\x28\xa8\xf5.
\x0a\xb9\x94\x02\x45\x81\x93\x1f\xbc\xd7\xf3\xad\x93\xf5\x32\x93;
my $cipher = Crypt::Rijndael-new( $key, Crypt::Rijndael::MODE_ECB() );
my $plain = $ciper-decrypt($daten);
--
To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: cherry-pick c623734632010e4601ca4e369851bc79ab7f706f to 3.4.x
On 25.09.2012 13:05, Anurag Priyam wrote: On Tue, Sep 25, 2012 at 1:15 PM, Uli Schlachter psyc...@znc.in wrote: On 17.09.2012 16:00, Anurag Priyam wrote: The online documentation can't be fixed without making a release, right? So maybe someone could cherry-pick c623734632010e4601ca4e369851bc79ab7f706f to 3.4.x -- whatever the next release branch is supposed to be, so we don't miss out on it in the next release? Meh. That would break user configs with a micro release for no good reason. Yes, it is bad that this function is called differently between 3.4 and master and the commit should have been applied to both branches back then (*if* there was no release since it was added). It doesn't look like a release was made after c623734 was added. $ git name-rev c623734 master~121 Yeah, this commit is not in any release. However, add awful.client.cycle was released already: $ git describe --contains 9f2a79a2d069402585557f90f6788fb1d0dc00ac v3.4.12~11 Changing it now would only annoy 3.4 users, sorry. Ok. I was thinking of it as a bug fix hence recommended it for a point release. Waiting longer will most likely break more configs later. Yeah, but when upgrading to a major release, people expect more breakage than with a minor one. So when do you think will it be fixed? 3.5? 4.0? Or what? Exactly. [...] Cheers, Uli -- - Captain, I think I should tell you I've never actually landed a starship before. - That's all right, Lieutenant, neither have I. -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: [PATCH] Minor menubar patches
On 11.09.2012 10:37, Alexander Yakushev wrote: Bump. Can anyone check those out and push? On 09/04/2012 02:56 AM, Alexander Yakushev wrote: Hi there, The first patch makes a few properties public again (since they became local after 5.2 rewrite) and removes some unnecessary context initializers. The second one allows to specify the parameters for the menubar prompt. It was handy for me to specify a custom color for bg_cursor since my default bg_color is PNG image and that is not handled gracefully by awful.prompt. Kind regards, Checked out and pushed. At least someone noticed that I was away. :-) Uli -- - Captain, I think I should tell you I've never actually landed a starship before. - That's all right, Lieutenant, neither have I. -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: [PATCH 1/3] Add awful.client.setmaster
Hi, all three patches are merged. However, your git clone is quite outdated: error: patch failed: lib/awful/client.lua.in:402 error: lib/awful/client.lua.in: patch does not apply Patch failed at 0001 Add awful.client.setmaster Your first patch for master doesn't apply to git/master since June 12th. Please update to latest master before submitting patches, so that I don't have to fix this up myself. Cheers, Uli -- Do you know that books smell like nutmeg or some spice from a foreign land? -- Faber in Fahrenheit 451 -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: [PATCH] common/util.h: dodgy non-__GNUC__ p_delete
On 30.07.2012 21:06, Arvydas Sidorenko wrote:
I assume nobody have tried to compile Awesome with GNU uncompatible
compiler for ages and thus non-__GNUC__ p_delete version got
overlooked for quite some time.
First of all, a problem I see is that it assigns void** to a variable
of type void* and then dereferences the same void* variable.
None of the compilers I am aware of will let you go through this
without an error.
And second of all, lets have one portable p_delete.
Signed-off-by: Arvydas Sidorenko asi...@gmail.com
[...]
-#define p_delete(mem_p)\
-do { \
-void *__ptr = (mem_p); \
-free(*__ptr); \
-*(void **)__ptr = NULL;\
-} while (0)
Wow, that looks quite wrong.
Pushed, thanks!
Uli
--
Every once in a while, declare peace. It confuses the hell out of your enemies
- 79th Rule of Acquisition
--
To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: [PATCH] wallpaper.c: capability from within Awesome
On 24.07.2012 12:45, Arvydas Sidorenko wrote:
[]
diff --git a/wallpaper.c b/wallpaper.c
new file mode 100644
index 000..e8abf1b
--- /dev/null
+++ b/wallpaper.c
@@ -0,0 +1,261 @@
+/*
+ * wallpaper.c - wallpaper manager
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+ *
+ */
[...]
This code is from feh, right? I think I saw something like that before.
Anyway, thanks for the reference implemention. I reimplemented this using XCB
and cairo (and instead of using a cairo surface, this now wants a cairo pattern
which should be more flexible, I think...). Patch is attached.
I didn't test if this actually handles pseudo-transparency correctly. Anyone out
there with urxvt and without a compositing manager who wants to test? Also, I
shouldn't have much time to test this properly in the near future. Meh.
If someone wants to actually set a background *image* with this, here is the
nice and simple one-liner:
root.wallpaper(require(lgi).cairo.Pattern.create_for_surface(require(gears.surface)(/home/psychon/Wallpaper/wp_1920.jpg))._native)
Easy, right?
(With current lgi-git Pattern.create_for_surface(foo) can be shortened to
Pattern(foo))
Cheers,
Uli
--
In the beginning the Universe was created. This has made a lot of
people very angry and has been widely regarded as a bad move.
diff --git a/awesomerc.lua.in b/awesomerc.lua.in
index 261fa50..ce49a47 100644
--- a/awesomerc.lua.in
+++ b/awesomerc.lua.in
@@ -379,3 +379,5 @@ end)
client.connect_signal(focus, function(c) c.border_color =
beautiful.border_focus end)
client.connect_signal(unfocus, function(c) c.border_color =
beautiful.border_normal end)
-- }}}
+local color = require(gears.color)
+print(root.wallpaper(color(radial:50,50,10:55,55,30:0,#ff:0.5,#00ff00:1,#ff)._native))
diff --git a/root.c b/root.c
index 8736a29..9c57cb3 100644
--- a/root.c
+++ b/root.c
@@ -32,6 +32,92 @@
#include common/xcursor.h
#include common/xutil.h
+/* FIXME: This is cp from awesome.c */
+static xcb_visualtype_t *
+a_default_visual(const xcb_screen_t *s)
+{
+xcb_depth_iterator_t depth_iter = xcb_screen_allowed_depths_iterator(s);
+
+if(depth_iter.data)
+for(; depth_iter.rem; xcb_depth_next (depth_iter))
+for(xcb_visualtype_iterator_t visual_iter =
xcb_depth_visuals_iterator(depth_iter.data);
+visual_iter.rem; xcb_visualtype_next (visual_iter))
+if(s-root_visual == visual_iter.data-visual_id)
+return visual_iter.data;
+
+return NULL;
+}
+
+static xcb_atom_t
+intern_atom(xcb_connection_t *c, const char *name)
+{
+xcb_atom_t a;
+xcb_intern_atom_reply_t *r = xcb_intern_atom_reply(c,
+xcb_intern_atom(c, 0, strlen(name), name), NULL);
+if (!r)
+return XCB_NONE;
+a = r-atom;
+free(r);
+return a;
+}
+
+static bool
+root_set_wallpaper(cairo_pattern_t *pattern)
+{
+xcb_connection_t *c = xcb_connect(NULL, NULL);
+xcb_pixmap_t p = xcb_generate_id(c);
+/* globalconf.connection should be connected to the same X11 server, so we
+ * can just use the info from that other connection.
+ */
+const xcb_screen_t *screen = globalconf.screen;
+uint16_t width = screen-width_in_pixels;
+uint16_t height = screen-height_in_pixels;
+bool result = false;
+xcb_atom_t rootpmap = intern_atom(c, _XROOTPMAP_ID);
+xcb_atom_t esetroot = intern_atom(c, ESETROOT_PMAP_ID);
+cairo_surface_t *surface;
+cairo_t *cr;
+
+if (xcb_connection_has_error(c))
+goto disconnect;
+
+xcb_create_pixmap(c, screen-root_depth, p, screen-root, width, height);
+surface = cairo_xcb_surface_create(c, p, a_default_visual(screen), width,
height);
+cr = cairo_create(surface);
+/* Fill with black background */
+cairo_set_source_rgb(cr, 0, 0, 0);
+cairo_paint(cr);
+/* Paint the pattern to the surface */
+cairo_set_source(cr, pattern);
+cairo_paint(cr);
+cairo_destroy(cr);
+cairo_surface_finish(surface);
+cairo_surface_destroy(surface);
+
+/* We now have the pattern painted to the pixmap p. Now turn p into the
root
+ * window's background pixmap.
+ */
+xcb_change_window_attributes(c, screen-root, XCB_CW_BACK_PIXMAP, p);
+xcb_clear_area(c, 0, screen-root, 0, 0, 0, 0
Re: Lets get rid of awsetbg?
Hi, On 23.07.2012 16:08, Julien Danjou wrote: On Mon, Jul 23 2012, Ignas Anikevicius wrote: 1) Write some C code which would be integrated in awesome capi and it would just do some basic setting via a single command. 2) Write some C code and LUA bindings and write all the logic in LUA. This would mean, that it might be possible to have something more interesting. E.g. different wallpapers on different tags/screens and even more. Can we use lgi for that? As far as I understood, it's impossible but I might be wrong. If we choose the option B2 option, then awesome will be even more awesome... but the question is whether having bg setter logic inside awesome is needed? The API should be very simple: add an .background property to all screen objects that can be set with any instanciated image. screen[0].background = image(/path/to/an/image) And just write the C code setting the wallpaper when .background is modified, and returning a new image if something wants to read the background. That should not be hard. Or, even simpler: root.wallpaper(gears.surface(/path/to/an/image)) (There is no image() in git/master) (root.wallpaper() is already available for getting the wallpaper) I wouldn't want to implement per-screen wallpapers in the C API. That would require 'stitching' the individual images together, something that (IMHO) is better done in lua. I don't know how much C code would be needed for implementing this. I think that it could need opening a second connection to the X11 server. Dunno if there is some spec for the properties part of this (I think I went with _XROOTPMAP_ID just because it worked for me). If someone would try to set an image with the wrong dimensions, I'd choose the simple route and just error out. Which reminds me, there is no simple lua API for getting the root window's geometry... So I don't really care about dropping awsetbg. I'd implement the C side of this if you guys tell me to do so. Someone else would then hopefully show up and implement some nice lua API for this (a lua background module where one can set per-screen backgrounds and stuff...?). Cheers, Uli -- In the beginning the Universe was created. This has made a lot of people very angry and has been widely regarded as a bad move. -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: Lets get rid of awsetbg?
On 23.07.2012 17:16, Julien Danjou wrote: On Mon, Jul 23 2012, Uli Schlachter wrote: Or, even simpler: root.wallpaper(gears.surface(/path/to/an/image)) Yeah, I didn't know we have a read function for this. I don't know how much C code would be needed for implementing this. I think that it could need opening a second connection to the X11 server. Dunno if there is some spec for the properties part of this (I think I went with _XROOTPMAP_ID just because it worked for me). If someone would try to set an image with the wrong dimensions, I'd choose the simple route and just error out. Which reminds me, there is no simple lua API for getting the root window's geometry... I think hacking luaA_root_wallpaper() to do this is the good way to do so. So this means I get to have some fun with wallpapers? No one objects? Since I won't have the needed time for this, who wants to open a feature request and get blame for all the time I'll have to spend on implementing this? :-) I just poked at the source code quickly, but I had the feeling that root should be actually screen.root, an object inheriting from `window'. That does not seem to be actually the case, that's sad, because I think it would makes sense, even for key/button bindings and in our case for getting geometry. WDYT Uli? Well, X11 only provides a single root window, so technically there is just a single, big wallpaper. People also have asked for a signal when the mouse pointer moves between screens and that's not easily possible either. (Yes, it's not really hard to implement, but... dunno) So no per-screen root objects, please. And for inheriting from window objects: - border_color, border_width, opacity, struts, type properties all don't make sense for the root window - button::press/::release would require grabbing all input, I guess, which would render the keyboard unusable. So nope. - mouse::move could make sense Doesn't look like inheriting root from window would make sense to me. Uli -- my $key = \x49\x03\x93\x08\x19\x94\x96\x94\x28\x93\x83\x04\x68\x28\xa8\xf5. \x0a\xb9\x94\x02\x45\x81\x93\x1f\xbc\xd7\xf3\xad\x93\xf5\x32\x93; my $cipher = Crypt::Rijndael-new( $key, Crypt::Rijndael::MODE_ECB() ); my $plain = $ciper-decrypt($daten); -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: [PATCH] Fix-spelling-in-doc-string
On 01.07.2012 15:26, Felix Bier wrote: This fixes a minor spelling mistake. Both patches merged. -- - He made himself, me nothing, you nothing out of the dust - Er machte sich mir nichts, dir nichts aus dem Staub -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: [PATCH] tag.viewidx-should-take-a-screen-index
On 01.07.2012 20:21, Felix Bier wrote:
Am Sonntag, den 01.07.2012, 15:24 +0200 schrieb Felix Bier:
Hello list,
this patch makes tag.viewidx take a screen index rather than a screen
object, complying with its doc string. This seems to be more consistent
with other parts of the API to me, and also fixes #963. Config breakage
should be minimal, since this function is usually called without the
screen parameter.
Felix
Unfortunately I noticed a problem with my patch when attempting to
switch tags via mouse wheel. When tag.viewprev or tag.viewnext is set as
a callback to a mouse button event for a tag, the screen parameter
passed to viewidx will in fact be the originating tag. This is the right
behaviour for i. e. viewonly, but causes an error with my patch. I
guess this did not matter previously, because screen.index would
evaluate to nil.
Tags have a .screen property, too. So that code actually worked fine before.
I am not sure how this should be handled. The attached patch checks
whether type(screen)==number, which is the most simple fix, but not
exactly beautiful. Alternatively, the previous patch could be reverted
and this side effect be documented. The right thing would probably be
to wrap viewnext/viewprev like awful.button({}, 4, function()
awful.tag.viewnext() end), though that would be my least favourite
option, because it would break a lot of configs. Other opinions?
Welcome to git/master. Everyone switching from 3.4 to this will get some
breakage anyway, so I'm not too worried about this. So this last thing would be
my favorite solution.
Uli
--
A learning experience is one of those things that say,
'You know that thing you just did? Don't do that.'
-- Douglas Adams
--
To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: 0001-Do-not-attempt-to-call-global-destroy.patch
On 22.06.2012 20:02, Felix Bier wrote: Hello list, I got attempt to call global destroy from two locations in naughty.lua, which should be fixed with this patch. The first one can be triggered by spamming notifications, the second one appeared to me on evolution's mail notification, which is supposed to be closed when opening the mail. Pushed, thanks. Seems like lua 5.2 caused more breakage than I had hoped for. :-( Uli -- For saving the Earth.. and eating cheesecake! -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: 0001-Do-not-attempt-to-call-global-destroy.patch
On 22.06.2012 23:58, Arvydas Sidorenko wrote: On 06/22/2012 11:19 PM, Uli Schlachter wrote: On 22.06.2012 20:02, Felix Bier wrote: Hello list, I got attempt to call global destroy from two locations in naughty.lua, which should be fixed with this patch. The first one can be triggered by spamming notifications, the second one appeared to me on evolution's mail notification, which is supposed to be closed when opening the mail. Pushed, thanks. Seems like lua 5.2 caused more breakage than I had hoped for. :-( The result of my lousy job :P I don't think that I would have done better. Finding all of these hiding module accesses is pretty much impossible. One could grep for all defined functions and variables in a module, but that would take forever... Also, in half a year or so, all the broken places that are left can be used as a marker on code that no one uses. ;-) Uli -- In the beginning the Universe was created. This has made a lot of people very angry and has been widely regarded as a bad move. -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
Re: [PATCH][3.4] awful.titlebar use height not width
On 16.06.2012 03:13, Sébastien Luttringer wrote:
Signed-off-by: Sébastien Luttringer se...@seblu.net
---
lib/awful/titlebar.lua.in |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/awful/titlebar.lua.in b/lib/awful/titlebar.lua.in
index 1bda9da..805ac71 100644
--- a/lib/awful/titlebar.lua.in
+++ b/lib/awful/titlebar.lua.in
@@ -57,7 +57,7 @@ end
-- bg: the background color.
-- fg_focus: the foreground color for focused window.
-- fg_focus: the background color for focused window.
--- width: the titlebar width
+-- height: the titlebar height
function add(c, args)
if not c or (c.type ~= normal and c.type ~= dialog) then return end
if not args then args = {} end
Boy, that code is a mess. It actually does look for args.width and saves it away
elsewhere, but that value then isn't used anywhere.
So yeah, this patch does look like an improvement, merged.
Uli
--
- Captain, I think I should tell you I've never
actually landed a starship before.
- That's all right, Lieutenant, neither have I.
--
To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
