Re: [i3] [i3status] Update interval alignment glitch

[Gereon Kremer]

Hi,

Marco Hunsicker wrote:
> It's a pity that Gereon did not comment any further.
Sorry for that, but I have been on vacation for the last 12 days or
so... :-)

Marco Hunsicker wrote:
> The alignment is there purely for aesthetic reasons, right? That the
> clock displays the seconds in a predictable way? 
Yes, just as you describe a few mails later: 00 -> 05 -> 10 -> ...

Anyhow, I don't have a strong opinion about this. I just consider
refreshs that are due to a USR1 "exceptional" and deem the default case
to be more important.
Ultimately, both problems are only aesthetical: ugly numbers vs.
refreshs earlier than 
seconds...

Cheers,
Gereon

Re: [i3] [i3status] Update interval alignment glitch

[Gereon Kremer]

Hi Marco,

As I'm the one who added this alignment in the first place [1], I
somewhat feel obligated to answer here :-)
At that time, I did not think about nanosleep() being interupted.

Can you describe under which circumstances i3status receives an USR1?
I've never noticed such a behavior...

What would be your preferred solution here? As for me, we must decide on
what we consider more important (the implementation is easy in either
case): The overall number of refreshs? Have nice numbers?

Possible solutions:
1) We could suppress or defer the signal and continue sleeping until the
proper number of seconds have passed. Not what I'd like to do...
2) We could refresh and start with the intervals from there. This
however means that we drop the alignment. This basically amounts to the
code before I changed it.
3) We could refresh, start with the intervals from there and realign
every minute or so. In this case, we have another shorter interval right
before a new minute starts and "ugly" numbers in between.
4) We could refresh and return to the alignment directly afterwards.
That is what happens right now.

As I don't care about an additional refresh once in a while, I'd go for
the nice numbers... What are your opinions?

Cheers,
Gereon

[1]
http://code.stapelberg.de/git/i3status/commit/?id=11757b8105ebebba40c3a94c5d6c5431cc58b3d1

On 03/11/2014 07:12 PM, Marco Hunsicker wrote:
> Hello Michael,
> 
> thanks again for your quick response.
> 
>>> Would it not be more important to enforce that updates happen (roughly)
>>> every 'interval' seconds? Is it really that important to update at the
>>> start of a new minute anyway?
> 
>> I don’t understand why you are asking which behavior is more
>> important. Can’t we fix this problem properly and have both?
> 
> Well, sometimes there is behavior for no good reason and if I touch the
> code anyway, I might as well get rid of the alignment.
> 
> But if it should stay there, fine with me. I will forward a patch for
> review. Thanks.
> 
> Cheers,
>   Marco

-- 
Email: gereon.kre...@rwth-aachen.de
Mobil: 01520 / 9844454
Adalbertsteinweg 1b, 52070 Aachen


0x78359F29.asc
Description: application/pgp-keys

Re: [i3] idea on default layout orientation: complete binary tree model

[Gereon Kremer]

Hi,

I'm not too fond of this binary tree idea: It has no real gain (at least 
not for me), as it can't do anything one could not achieve with a single 
keystroke before opening a new window. (i.e. switching to splitv / 
splith). But it takes aways some possibilities, for example having more 
than two containers each taking the full height.


I also thought about presets, as "presets for workspace layouts" is one 
feature I really miss in i3. What I'd like to have is the following:
My workspace 1 always contains pidgin (left, ~20%) and thunderbird 
(right, rest of screen). I have not yet been able to create a config 
such that when I start those programs (in arbitrary order) they are 
placed as described.
I guess it'd need some kind of "want have"-size, such that when a 
container has the possibility to resize (because a new container 
appeared), it resizes to the "want have"-size (or some intermediate 
values, if multiple "want have"-sizes do not allow for an "optimal" 
placement.

Maybe, we should fork this thread? :-)

Gereon

On 21.01.2013 14:06, Lingzhu Xiang wrote:

On Mon, Jan 21, 2013 at 7:20 PM, Tai-Lin Chu  wrote:

at this moment i3wm has 4 layouts: 1. splitv 2. splith 3. tabbed 4. stacked.

But I think we should remove 1 and 2 because this default setting
  is useless. Our screen has limited width or height, so splitting more
than 2 times will make nothing readable.

I have a slightly larger screen so I enjoy a 3x2 grid. Cognitive
psychology argues our short-term memory can only efficiently manage no
more than seven objects anyway. So I propose 6 windows in a workspace
should be enough for common use cases.

Given no more than 6 windows, there are only a few types of layout to choose.


Instead, I purpose complete binary tree model. this will replace the
default 1 and 2.

I do like the idea to allow user to fine-grain tune the layout with
tree structure that describes the position of each window. i3's layout
commands are powerful, but so far I feel manual layout management at
runtime counterproductive. I have a lot of time thinking about layout
preference, but when I'm using it, I just want to $mod+Return to make
windows pop up immediately and start working. So it would be ideal if
I can save my layout preference in configuration and stop worrying
about it at runtime.


Lingzhu Xiang

[i3] i3status: Color for muted volume

[Gereon Kremer]

Hi,

in the current version i3status, the volume is red (i.e. has color_bad)
if muted. While I think it is useful to use different colors for "muted"
and "volume X", I don't unterstand why we use "bad" here instead of
"degraded.

Is there any particular reason for this?
If not: I have attached a patch :-)

Cheers,
Gereon
>From 3292d5d68aead981ec4cb783a0c846167e0fb231 Mon Sep 17 00:00:00 2001
From: Gereon Kremer 
Date: Sat, 22 Dec 2012 19:06:53 +0100
Subject: [PATCH 2/2] changing volume color from bad to degraded if muted

---
 src/print_volume.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/print_volume.c b/src/print_volume.c
index 080dea2..cf42f3e 100644
--- a/src/print_volume.c
+++ b/src/print_volume.c
@@ -157,7 +157,7 @@ void print_volume(yajl_gen json_gen, char *buffer, const char *fmt, const char *
 		if ((err = snd_mixer_selem_get_playback_switch(hdl->elem, 0, &pbval)) < 0)
 			fprintf (stderr, "i3status: ALSA: playback_switch: %s\n", snd_strerror(err));
 		if (!pbval)  {
-			START_COLOR("color_bad");
+			START_COLOR("color_degraded");
 			avg = 0;
 		}
 	}
-- 
1.7.10.4

Re: [i3] Fw: RFC: i3-dmenu-desktop

[Gereon Kremer]

Hi Michael,

I bit more research revealed, that the mathematica8.desktop file had all
lines prefixed with three spaces. Maybe also consider leading
whitespaces in the parser? :-)

Gereon

On 12/19/2012 12:23 PM, Michael Stapelberg wrote:
> Hi Gereon,
> 
> Gereon Kremer  writes:
>> I'd suggest not to use $mod+p as default. At least ubuntu uses Mod4+P to
>> switch displays, as some notebooks use Mod4+P for their Fn+X display
>> switcher.
> Where would that keybinding come from when you are starting i3 without
> a desktop environment?
> 
>> About i3-dmenu-desktop: I was a bit sceptical about the performance, but
>> it seems to work pretty well. Maybe you want to remove all the
>> warnings[1] in a future release.
> Those are most likely because one or more of your .desktop files are
> broken. Please apply http://sprunge.us/ZdjX and see which files cause
> the warning, so we can see whether it’s a bug in i3-dmenu-desktop or in
> your files.
> 

Re: [i3] Fw: RFC: i3-dmenu-desktop

[Gereon Kremer]

Hi Michael,

Most of the people I know that use i3 have the gnome-settings-daemon
still running. It's a convenient mix of "tiling wm" and "stuff just
works"...
Besides, you will *always* have this problem if you want to use the Fn+X
switcher on a relatively new (read: Windows 7 compatible) platform. This
whole problem emerged because newer kernel versions tell the BIOS they
are Win7 compatible...

Hence, all users that want to use the Fn+X display switcher key can not
use Mod4+P. (Afaik)

I applied the patch and used &> out to get the output. All warnings
appear before the first "parsing XY".

Gereon

On 12/19/2012 12:23 PM, Michael Stapelberg wrote:
> Hi Gereon,
> 
> Gereon Kremer  writes:
>> I'd suggest not to use $mod+p as default. At least ubuntu uses Mod4+P to
>> switch displays, as some notebooks use Mod4+P for their Fn+X display
>> switcher.
> Where would that keybinding come from when you are starting i3 without
> a desktop environment?
> 
>> About i3-dmenu-desktop: I was a bit sceptical about the performance, but
>> it seems to work pretty well. Maybe you want to remove all the
>> warnings[1] in a future release.
> Those are most likely because one or more of your .desktop files are
> broken. Please apply http://sprunge.us/ZdjX and see which files cause
> the warning, so we can see whether it’s a bug in i3-dmenu-desktop or in
> your files.
> 

Re: [i3] Fw: RFC: i3-dmenu-desktop

[Gereon Kremer]

Hi,

I'd suggest not to use $mod+p as default. At least ubuntu uses Mod4+P to
switch displays, as some notebooks use Mod4+P for their Fn+X display
switcher.

About i3-dmenu-desktop: I was a bit sceptical about the performance, but
it seems to work pretty well. Maybe you want to remove all the
warnings[1] in a future release.

Cheers,
Gereon

[1] Use of uninitialized value $key in string eq at
/usr/bin/i3-dmenu-desktop line 159.

On 12/15/2012 01:35 AM, Joep van Delft wrote:
> 
> 
> Begin forwarded message:
> 
> Date: Sat, 15 Dec 2012 01:32:29 +0100
> From: Joep van Delft 
> Wrongly assumed that clicking 'Reply' would go to the list. 
> 
> Cheers, 
> 
> 
> joepd
> 
> 
> To: Michael Stapelberg 
> Subject: Re: [i3] RFC: i3-dmenu-desktop
> 
> 
> Hallo Michael, 
> 
> On Fri, 14 Dec 2012 21:34:09 +0100
> Michael Stapelberg  wrote:
>> In fact, the script is i3-specific. It starts applications via i3 to
>> correctly use startup notifications. 
> 
> Fair enough. Ship it, make it default, enforce it, enlighten the
> masses :)
> 
> Suggestion for key-combo: Use $mod+p (for program). As it provides
> access to Programs, in stead of dmenu_run. (I bound it to
> $mod+Shift+P, the complete and fancy version of $mod+p, which
> provides access to often used programs, for example pavucontrol on
> the machine that is wired to amplifiers)
> 
> This probably is a question more suited for the FAQ, but how do you
> (plural) keep appearances and settings consistent with multiple
> and separate dmenu-commands? 
> 
> Cheers, 
> 
> 
>   Joep
>