start-euclid and custom keybindings

[BKLive]

So now that start-euclid is re-implemented, which is more appropriate
to put in your .xinitrc file: exec euclid-wm or exec start-euclid (or
just start-euclid, no exec)? This has been a little hazy as the
program flow is uncertain to me (not sure where start-euclid is in the
call-process-output chain).

Also, I haven't been able to create a custom keybinding that works.
Essentially, I only want to create two: one to lock the screen, and
one to reload euclid in-place without exiting back to the CLI (more on
this later). The one to lock the screen seems easy enough to
implement:

bind_custom_01 = M x
custom_command_01 = xscreensaver-command --lock

However Mod+x does nothing. I can lock the screen by typing the above
command in dmenu, but typing vs keybinding is not preferred
(obviously?). Is there something I'm missing?

As for the restarting of euclid in-place (without closing all windows,
just reload euclid. sort of how i3 does where then you have to re-move
all the windows to different desktops, but you can parse your new
config changes/updated i3 without exiting your session and killing all
of your application states), I have no idea how to do this. I'm
wondering if this is a plausible feature of value since it would make
sense with the consistent updates from the svn tree? Once the RC is
out, I intend to continue to maintain both the "Real version" and the
svn as this is the Arch Way (sort of?), so I'm wondering if there's a
way to make a script that would do this, if not implement it into the
RC itself?

BKL

[William Diem]

On 15 July 2010 06:25, BKLive <benjami...@gmail.com> wrote:
> So now that start-euclid is re-implemented, which is more appropriate
> to put in your .xinitrc file: exec euclid-wm or exec start-euclid (or
> just start-euclid, no exec)? This has been a little hazy as the
> program flow is uncertain to me (not sure where start-euclid is in the
> call-process-output chain).

start-euclid is the user-friendly way, it checks for configs, and puts
them in the users config directory if necessary.
exec euclid-wm should work by itself as of r112 (I had to move exec of
the rc script back into the executable itself).
So at the moment you can take your pick.

> Also, I haven't been able to create a custom keybinding that works.
> Essentially, I only want to create two: one to lock the screen, and
> one to reload euclid in-place without exiting back to the CLI (more on
> this later). The one to lock the screen seems easy enough to
> implement:
>
> bind_custom_01 = M x
> custom_command_01 = xscreensaver-command --lock

You prompted me to test this out a bit more, and the keys don't always
get bound (they do sometimes). I'll have to investigate further.

> As for the restarting of euclid in-place (without closing all windows,
> just reload euclid. sort of how i3 does where then you have to re-move
> all the windows to different desktops, but you can parse your new
> config changes/updated i3 without exiting your session and killing all
> of your application states), I have no idea how to do this. I'm
> wondering if this is a plausible feature of value since it would make
> sense with the consistent updates from the svn tree?

Yeah, this probably makes sense. Shouldn't be too hard either. In fact
I think I can make it so it just reloads the config, and leaves the
windows where they are (maybe not).

> Once the RC is
> out, I intend to continue to maintain both the "Real version" and the
> svn as this is the Arch Way (sort of?), so I'm wondering if there's a
> way to make a script that would do this, if not implement it into the
> RC itself?

I like the idea of having the svn and 0.1 or whatever side by side.
(dev and testing|stable).
I'm not sure I follow what the script is supposed to do though. Please
elaborate.

I'll try to look into these issues this afternoon.

Thanks,
Will

[William Diem]

>> Also, I haven't been able to create a custom keybinding that works.
>> Essentially, I only want to create two: one to lock the screen, and
>> one to reload euclid in-place without exiting back to the CLI (more on
>> this later). The one to lock the screen seems easy enough to
>> implement:
>>
>> bind_custom_01 = M x
>> custom_command_01 = xscreensaver-command --lock
> You prompted me to test this out a bit more, and the keys don't always
> get bound (they do sometimes). I'll have to investigate further.

So the keys are getting bound, but there seems to be something odd
going on with starting some screenlockers.
xtrlock (I don't have xscreensaver) won't start from euclid's spawn
function. I notice that it belongs to group "shadow", I wonder whether
this is causing some complication?

On the plus side, slock works.

I'll have to look into this more. Of course if anyone has any ideas
this would be a good time to voice them.

Will

[diem]

> On the plus side, slock works.
>

xlock (specifically xlockmore) also works fine.

Also, I installed xscreensaver and it doesn't work for me either.

After some diagnostics, I have found that the execvp() is setting
errno to 2, which is "no such entity".
It seem that for some reason it can't find xscreensaver-command (even
though "which" does return the path to it).

Also interesting is that xtrlock does not result in any error. It
seems that the fork/exec is successful and xtrlock just dies silently
for reasons unknown. (But it does run from dmenu, iirc).

This will require more tinkering later.

Will

[diem]

Okay workaround found:

Try wrapping it in a script, and binging x to that script.

This works on my setup. I still have no idea what the underlying
problem is though.

[BKLive]

I wonder if it has something to do with parsing the arguments that are
separated by hyphens (such as xscreensaver-command) or even the --lock
command afterwards. Maybe it's a text parse thing, or some kind of
exec error? Maybe?

I am just using slock for now, deciding to minimize some bloat because
my wm makes me lol

[William Diem]

I reworked the whole spawn() mechanism as well as changing some
fundamentals on bindings. These changes should fix lots of bugs (some
that never got reported). For one, custom keybinding commands can now
be anything that the shell will parse as long as it fits on one line.

The cost of this is that I'm forking a shell every time spawn() is
called. But in the grand scheme of things, this doesn't seem like a
big cost given the massive benefits to the user and the time savings
for the dev.

If in the future someone wants to rework it to eek out a bit of
performance, he is free to do so, but for now it seems like the right
way forwards.

xscreensaver-command -lock now works on my system.

Cheers,
Will