Automatically open processes on startup
Hello!
I'm running awesome 3.4 and i wanted to add a feature that on startup - a
list of processes will be loaded to their designated tags.
For example: terminal will be loaded to the first tag, music player will be
loaded to the fifth etc..
The code i added to rc.lua goes like this:
tag_apps = { { terminal, terminal } , { terminal } }
for i = 1, #tag_apps do
for j = 1, #tag_apps[i] do
awful.util.spawn(tag_apps[i][j])
--awful.client.movetotag(i, c)
end
end
teminal is the terminal command.
My problems are those:
1. spawn makes the xserver crash and i don't understand why.
2. Even if it would work, how do i get the client object for the process i
just opened so i can move it to the correct tag with movetotag?
Thank you!
RE: Automatically open processes on startup
Have you considered Rules?
Default rc.lua - Note the firefox entry.
-- {{{ Rules
awful.rules.rules = {
-- All clients will match this rule.
{ rule = { },
properties = { border_width = beautiful.border_width,
border_color = beautiful.border_normal,
focus = true,
keys = clientkeys,
buttons = clientbuttons } },
{ rule = { class = MPlayer },
properties = { floating = true } },
{ rule = { class = pinentry },
properties = { floating = true } },
{ rule = { class = gimp },
properties = { floating = true } },
-- Set Firefox to always map on tags number 2 of screen 1.
-- { rule = { class = Firefox },
-- properties = { tag = tags[1][2] } },
}
_
From: Maytar Byle [mailto:mayt...@gmail.com]
Sent: Monday, 6 October 2014 12:06 AM
To: awesome@naquadah.org
Subject: Automatically open processes on startup
Hello!
I'm running awesome 3.4 and i wanted to add a feature that on startup - a
list of processes will be loaded to their designated tags.
For example: terminal will be loaded to the first tag, music player will be
loaded to the fifth etc..
The code i added to rc.lua goes like this:
tag_apps = { { terminal, terminal } , { terminal } }
for i = 1, #tag_apps do
for j = 1, #tag_apps[i] do
awful.util.spawn(tag_apps[i][j])
--awful.client.movetotag(i, c)
end
end
teminal is the terminal command.
My problems are those:
1. spawn makes the xserver crash and i don't understand why.
2. Even if it would work, how do i get the client object for the process i
just opened so i can move it to the correct tag with movetotag?
Thank you!
Re: Automatically open processes on startup
Thank you for answering!
It doesn't fully solve the second problem though because in case i want 2
tags with terminals in them then i cant make the seperation.
and the first question still left unanswered.
2014-10-05 16:17 GMT+03:00 David Sorkovsky davidsorkov...@hotmail.com:
Have you considered Rules?
Default rc.lua – Note the firefox entry…
-- {{{ Rules
awful.rules.rules = {
-- All clients will match this rule.
{ rule = { },
properties = { border_width = beautiful.border_width,
border_color = beautiful.border_normal,
focus = true,
keys = clientkeys,
buttons = clientbuttons } },
{ rule = { class = MPlayer },
properties = { floating = true } },
{ rule = { class = pinentry },
properties = { floating = true } },
{ rule = { class = gimp },
properties = { floating = true } },
-- Set Firefox to always map on tags number 2 of screen 1.
-- { rule = { class = Firefox },
-- properties = { tag = tags[1][2] } },
}
--
*From:* Maytar Byle [mailto:mayt...@gmail.com]
*Sent:* Monday, 6 October 2014 12:06 AM
*To:* awesome@naquadah.org
*Subject:* Automatically open processes on startup
Hello!
I'm running awesome 3.4 and i wanted to add a feature that on startup - a
list of processes will be loaded to their designated tags.
For example: terminal will be loaded to the first tag, music player will
be loaded to the fifth etc..
The code i added to rc.lua goes like this:
tag_apps = { { terminal, terminal } , { terminal } }
for i = 1, #tag_apps do
for j = 1, #tag_apps[i] do
awful.util.spawn(tag_apps[i][j])
--awful.client.movetotag(i, c)
end
end
teminal is the terminal command.
My problems are those:
1. spawn makes the xserver crash and i don't understand why.
2. Even if it would work, how do i get the client object for the process i
just opened so i can move it to the correct tag with movetotag?
Thank you!
awesome-client dbus reply
Hi,
I've been using awesome-client with success to execute some lua code
through dbus, but I'm wondering how to obtain a reply from this code.
If I have a function like this un my rc.lua file:
dbus_test = function()
-- do something...
-- let's try to return a value
return test
end
when I call it through dbus, I dont get any response. The code is
executed, but the return statement is not handled properly, a dbus
reply is not generated (awesome-client is calling dbus-send
with the argument --print-reply):
$ echo dbus_test() | awesome-client
I would expect the following output:
$ echo dbus_test() | awesome-client
string test
After digging in /usr/share/awesome/lib/awful/remote.lua, I can see
how the call is made:
dbus.add_signal(org.naquadah.awesome.awful.Remote, function(data, code)
if data.member == Eval then
local f, e = loadstring(code)
if f then
results = { f() }-- call is made here
...
But the results table is always empty, and I don't understand
why. If anyone have an idea or a proper example how to get a reply
from a dbus call, I would appreciate.
My version of awesome:
awesome v3.4.15 (Never Gonna Give You Up)
• Build: Feb 17 2013 21:10:46 for x86_64 by gcc version 4.7.2
(buildd@barber)
• D-Bus support: ✔
--
Gerome Fournier
http://foutaise.org
--
To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: Automatically open processes on startup
For the first problem try using spawn_with_shell instead of spawn and see
if it still crashes.
But if you want to do stuff with the program you started maybe you should
use spawn because if it succeeds it will return something you can use to
identify the process (
https://awesome.naquadah.org/doc/api/modules/awful.util.html#spawn).
I only use spawn with shell, but that's for starting background programs,
not stuff that I then want to move to some other tag...
Maybe you can try checking your X logs find out why it crashes (no idea
where those are thou, ask google).
Cumprimentos,
Bruno Ferreira
2014-10-05 14:42 GMT+01:00 Maytar Byle mayt...@gmail.com:
Thank you for answering!
It doesn't fully solve the second problem though because in case i want 2
tags with terminals in them then i cant make the seperation.
and the first question still left unanswered.
2014-10-05 16:17 GMT+03:00 David Sorkovsky davidsorkov...@hotmail.com:
Have you considered Rules?
Default rc.lua – Note the firefox entry…
-- {{{ Rules
awful.rules.rules = {
-- All clients will match this rule.
{ rule = { },
properties = { border_width = beautiful.border_width,
border_color = beautiful.border_normal,
focus = true,
keys = clientkeys,
buttons = clientbuttons } },
{ rule = { class = MPlayer },
properties = { floating = true } },
{ rule = { class = pinentry },
properties = { floating = true } },
{ rule = { class = gimp },
properties = { floating = true } },
-- Set Firefox to always map on tags number 2 of screen 1.
-- { rule = { class = Firefox },
-- properties = { tag = tags[1][2] } },
}
--
*From:* Maytar Byle [mailto:mayt...@gmail.com]
*Sent:* Monday, 6 October 2014 12:06 AM
*To:* awesome@naquadah.org
*Subject:* Automatically open processes on startup
Hello!
I'm running awesome 3.4 and i wanted to add a feature that on startup - a
list of processes will be loaded to their designated tags.
For example: terminal will be loaded to the first tag, music player will
be loaded to the fifth etc..
The code i added to rc.lua goes like this:
tag_apps = { { terminal, terminal } , { terminal } }
for i = 1, #tag_apps do
for j = 1, #tag_apps[i] do
awful.util.spawn(tag_apps[i][j])
--awful.client.movetotag(i, c)
end
end
teminal is the terminal command.
My problems are those:
1. spawn makes the xserver crash and i don't understand why.
2. Even if it would work, how do i get the client object for the process
i just opened so i can move it to the correct tag with movetotag?
Thank you!
[awesome bugs] #1296 - Updated signal causes total relayout (Attachment added)
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#1296 - Updated signal causes total relayout User who did this - Uli Schlachter (psychon) -- Another new version. This now introduces a layout cache similar to the fit cache. This removes the wibox argument for :fit() and :layout() since the result of these functions is cached and thus must not depend on the wibox. This also changes the API for :layout() so that it is no longer recursive. Instead, :layout() returns a table that describes all child widgets together with their positions and transformations. This table is cached. This change should also make it much easier to test things. You guys don't have to look through all the code in there, but it would be nice if you looked at the fixed and the img widgets in there (lines 269 to 359) and tell me if the API they use looks sensible. The other 250 lines in there just implement this API. Oh and another new change: The result from :fit() goes through math.ceil(). This should make it harder for introduce non-integer positions for widgets, although this is still easily possible... -- One or more files have been attached. More information can be found at the following URL: https://awesome.naquadah.org/bugs/index.php?do=detailstask_id=1296#comment4157 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.
[awesome bugs] #1296 - Updated signal causes total relayout
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task has a new comment added:
FS#1296 - Updated signal causes total relayout
User who did this - Uli Schlachter (psychon)
--
Sorry for spamming.
I tested a 45 degree rotation and quite some code broke. Here is the code for
the rotation:
local custom = base.make_widget()
function custom:fit(width, height) return width, height end
function custom:draw() end
custom.before_draw_children = custom.draw
custom.after_draw_children = custom.draw
function custom:layout()
local m = cairo.Matrix.create_translate(30, 30)
m:rotate(math.pi / 4)
m:translate(0, -30)
return {
base.place_widget(f, m, 30, 10),
}
end
And here are the needed fixes:
function wibox:damage_area(x, y, width, height)
local rect = cairo.RectangleInt({
x = math.floor(x),
y = math.floor(y),
width = math.ceil(width),
height = math.ceil(height)
})
self._dirty_area:union_rectangle(rect)
end
function wibox:_widget_needs_redraw(widget_state)
-- We have to transform this widget's geometry into global coordinates
local m = cairo.Matrix.create_identity()
local state = widget_state
while state ~= nil do
m:multiply(m, state.matrix)
state = state.parent
end
-- XXX: How can this be done nicer?
local x1, y1 = m:transform_point(0, 0)
local x2, y2 = m:transform_point(0, widget_state.height)
local x3, y3 = m:transform_point(widget_state.width, widget_state.height)
local x4, y4 = m:transform_point(widget_state.width, 0)
local x = math.min(x1, x2, x3, x4)
local y = math.min(y1, y2, y3, y4)
local width = math.max(x1, x2, x3, x4) - x
local height = math.max(y1, y2, y3, y4) - y
self:damage_area(x, y, width, height)
end
--
More information can be found at the following URL:
https://awesome.naquadah.org/bugs/index.php?do=detailstask_id=1296#comment4158
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.
[awesome bugs] #1296 - Updated signal causes total relayout (Attachment added)
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task has a new comment added:
FS#1296 - Updated signal causes total relayout
User who did this - Uli Schlachter (psychon)
--
Seems like I can't get this out of my head...
All of a widget's callbacks are now optional. Missing draw methods are just
skipped. A missing :layout() is the same as returning {} aka no children.
When :fit() is missing, :layout() is used and the area covered by child widgets
is used for the return value.
(Oh and base.fit_widget() now also forces widgets to return a value between 0
and the given width/height)
--
One or more files have been attached.
More information can be found at the following URL:
https://awesome.naquadah.org/bugs/index.php?do=detailstask_id=1296#comment4159
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.
[awesome bugs] #1296 - Updated signal causes total relayout (Attachment added)
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#1296 - Updated signal causes total relayout User who did this - Uli Schlachter (psychon) -- Yet another new version of this proof of concept. Now, after re-layouting things, only the part of the wibox which really changed are redrawn. I bet this breaks Elv13's let's ignore the widget's bound and unset the clip-magic. I also fixed things so that the wibox code automatically emits widget::layout_changed on parent widgets when it is emitted on a child. (There is still potential for optimizations: If a widget is visible in n places, these signals will be emitted n times. This gets us exponential behavior for deep widget hierarchies. However, I do not care enough to do anything about this and this should still behave way better than what we had before.) Oh and since I didn't mention it yet: This code creates a cairo surface, places some widgets on it, forces a redraw of one of these widgets, then forces a relayout for one of the widgets and finally saves the resulting cairo surface to out.png. During this, it prints a message each time it calls a widget's callback to show that just the minimum amount of callbacks are generated. -- One or more files have been attached. More information can be found at the following URL: https://awesome.naquadah.org/bugs/index.php?do=detailstask_id=1296#comment4160 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.
