[Tails-dev] Fix to #5917 tails-greeter password field : Warn when caps-lock in ON
Hi, I created a patch for feature #5917 (tails-greeter password field : Warn
when caps-lock in ON).
I had a problem when caps lock key was on. I press the key again and it doesn't
generate a key event, so the warning message does not hide until i press
another key; don't know if this is GTK normal behavior or specific to my
keyboard or virtualbox. Could please somebody check that?
kind regards,
kurono.
From 3f5fd5c90e1ef2cfe0873bd2e6f282487cc36242 Mon Sep 17 00:00:00 2001
From: kurono
Date: Sat, 5 Oct 2013 23:32:21 +0200
Subject: [PATCH 3/3] tails-greeter password field : Warn when caps-lock in ON
---
GdmGreeter/optionswindow.py |8
GdmGreeter/persistencewindow.py |7 +++
glade/optionswindow.glade | 41 +
glade/persistencewindow.glade | 43 ++-
4 files changed, 98 insertions(+), 1 deletion(-)
diff --git a/GdmGreeter/optionswindow.py b/GdmGreeter/optionswindow.py
index 9042cb9..cd8fa40 100644
--- a/GdmGreeter/optionswindow.py
+++ b/GdmGreeter/optionswindow.py
@@ -38,12 +38,14 @@ class OptionsWindow(TranslatableWindow):
self.entry_password2 = builder.get_object("password_entry2")
self.warning_label = builder.get_object("warning_label")
self.warning_area = builder.get_object("warning_area")
+ self.caps_lock_warning_area = builder.get_object("caps_lock_warning_area")
self.camouflage_checkbox = builder.get_object("camouflage_checkbox")
TranslatableWindow.__init__(self, builder.get_object("options_dialog"))
self.window.set_visible(False)
self.warning_area.hide()
+ self.caps_lock_warning_area.hide()
self.entry_password.set_visibility(False)
self.entry_password2.set_visibility(False)
@@ -86,6 +88,12 @@ class OptionsWindow(TranslatableWindow):
self.entry_password2.grab_focus()
else:
self.set_options_and_login()
+elif event.keyval == gtk.keysyms.Caps_Lock:
+ if event.state & gtk.gdk.LOCK_MASK:
+ self.caps_lock_warning_area.show()
+ elif not (event.state & gtk.gdk.LOCK_MASK):
+ self.caps_lock_warning_area.hide()
+
def delete_event_cb(self, widget, event=None):
"""Ignore delete event (Esc)"""
diff --git a/GdmGreeter/persistencewindow.py b/GdmGreeter/persistencewindow.py
index 657544f..7df7a2a 100644
--- a/GdmGreeter/persistencewindow.py
+++ b/GdmGreeter/persistencewindow.py
@@ -53,6 +53,7 @@ class PersistenceWindow(TranslatableWindow):
self.readonly_checkbutton = builder.get_object("readonly_checkbutton")
self.warning_label = builder.get_object("warning_label")
self.warning_area = builder.get_object("warning_area")
+self.caps_lock_warning_area = builder.get_object("caps_lock_warning_area")
self.warning_image = builder.get_object("warning_area")
# self.spinner = builder.get_object("spinner")
self.checked_img_moreoptions_yes = builder.get_object("moreoptions_yes_checked_img")
@@ -61,6 +62,7 @@ class PersistenceWindow(TranslatableWindow):
self.checked_img_persistence_no = builder.get_object("persistence_no_checked_img")
self.warning_area.hide()
+self.caps_lock_warning_area.hide()
# FIXME: list_containers may raise exceptions. Deal with that.
self.containers = [
@@ -189,6 +191,11 @@ class PersistenceWindow(TranslatableWindow):
if event:
if event.keyval in [ gtk.keysyms.Return, gtk.keysyms.KP_Enter ]:
self.go()
+elif event.keyval == gtk.keysyms.Caps_Lock:
+ if event.state & gtk.gdk.LOCK_MASK:
+ self.caps_lock_warning_area.show()
+ elif not (event.state & gtk.gdk.LOCK_MASK):
+ self.caps_lock_warning_area.hide()
def delete_event_cb(self, widget, event=None):
"""Ignore delete event (Esc)"""
diff --git a/glade/optionswindow.glade b/glade/optionswindow.glade
index e0bedaa..30054a6 100644
--- a/glade/optionswindow.glade
+++ b/glade/optionswindow.glade
@@ -184,6 +184,47 @@ Otherwise it will be disabled for better security.
2
+
+
+True
+False
+6
+
+
+True
+False
+gtk-info
+1
+
+
+False
+False
+0
+
+
+
+
+True
+False
+0
+10
+10
+Caps lock is on
+True
+
+
Re: [Tails-dev] Removing the clock applet from the desktop
On Sun, Oct 6, 2013 at 2:04 PM, intrigeri wrote: >> Sorry my sentence was not clear and doesn't make sense now that I >> realized that this widget was setting the locale I prefer, and not the >> country where I am. > > Sorry if I'm getting you confused again: it *does* specify the region > where you are, in broader sense than just fine-tuning the language > being used. I'll let you digest this, rethink the whole thing and draw > new hypothesis & proposals, if you wish :) I suggest that you guys take a look at how the Language and Time Zone applet works in Liberté, especially the system files that are used to construct the menus. https://github.com/mkdesu/liberte/blob/master/src/root/helpers/gen-locale-menu https://github.com/mkdesu/liberte/blob/master/src/usr/local/bin/customize-locale -- Maxim Kammerer Liberté Linux: http://dee.su/liberte ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Removing the clock applet from the desktop
Hi, sajol...@pimienta.org wrote (06 Oct 2013 10:06:45 GMT) : > On 03/10/13 12:11, intrigeri wrote: >> But also, I think the region setting is useful *in itself*, not just >> for timezone selection: it's used to select a default keyboard layout >> in the greeter, and it also determines various l10n and language >> behaviors. So I don't think we could get rid of this region setting. > By the way, in the current Greeter there are three settings: "language", > "locale", and "keyboard". If I choose "Français" as a "language", and > "Canada" as a "locale", then the "keyboard" is not configured > automatically as "Canada", and I still have to choose it by hand. > But the "locale" is surely used to differentiate between pt_PT and pt_BR > for example, and probably only for doing that. Well, no. The second setting really is a country code. It is used not only to select a more specific dialect (e.g. Spanish as spoken in Mexico), but also for various other stuff, like currencies, units, papersize, etc. So, I think we should rename this field in the greeter to "Region" or "Country". >>> Here is my logic for that: if there is a timezone stored in persistence, >>> then that should overwrite the country option in the Greeter >> >> Regardless of whether it's reasonable or not to deduce the region from >> the configured timezone (that's debatable, I guess), there is >> a problem with this: we only get to learn the persistent timezone >> setting *after* having enabled persistence in the greeter, so anyone >> who wants to benefit from the behavior you're suggesting would have to >> either select their preferred keyboard layout every time anyway, or >> type their passphrase with a US layout. Not too convincing a UX, >> is it? > Sorry my sentence was not clear and doesn't make sense now that I > realized that this widget was setting the locale I prefer, and not the > country where I am. Sorry if I'm getting you confused again: it *does* specify the region where you are, in broader sense than just fine-tuning the language being used. I'll let you digest this, rethink the whole thing and draw new hypothesis & proposals, if you wish :) > Some countries have several timezones, and people travel so that can > only be a best bet and we still need a way to configure it from the applet. Sure. > Those two scenarios will work and I am fine with them. I'm glad we've found an agreement. Unless my input above changes your mind :) > But that is not a big deal as long as you can fix the timezone > directly from the applet. Agreed. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
[Tails-dev] Low-hanging fruits session: Saturday, October 12, & Tuesday, October 15
The next low-hanging fruit sessions are scheduled for Saturday, October 12, and Tuesday, October 15 on #tails (OFTC) at 4pm UTC (6pm CEST). Everyone interested to contribute to Tails is warmly welcome to join! The idea is to spend a while together on many small tasks that take less than 2 hours each, and are waiting in our TODO list for too long. During these meetings, we exceptionally allow ourselves to do the review & merge process on IRC instead of the usual email -based workflow, so this should all go pretty smoothly. Then, we report back on tails-dev. We also use these meetings to review stuff that's waiting in the queue. For newcomers, the list of "easy" tickets should be a great place to start: https://labs.riseup.net/code/projects/tails/issues?query_id=112 Cheers. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Removing the clock applet from the desktop
On 03/10/13 12:11, intrigeri wrote:
> I think the region setting is a fine source of a "best bet" when it
> comes to the default displayed timezone. Do we agree on this?
Yes. According to the two scenarios that you are listing at the end of
your email, that setting can be used as a best bet only when no timezone
is stored in persistence. I agree with that; but otherwise they might
conflict.
> But also, I think the region setting is useful *in itself*, not just
> for timezone selection: it's used to select a default keyboard layout
> in the greeter, and it also determines various l10n and language
> behaviors. So I don't think we could get rid of this region setting.
By the way, in the current Greeter there are three settings: "language",
"locale", and "keyboard". If I choose "Français" as a "language", and
"Canada" as a "locale", then the "keyboard" is not configured
automatically as "Canada", and I still have to choose it by hand.
But the "locale" is surely used to differentiate between pt_PT and pt_BR
for example, and probably only for doing that.
>> Here is my logic for that: if there is a timezone stored in persistence,
>> then that should overwrite the country option in the Greeter
>
> Regardless of whether it's reasonable or not to deduce the region from
> the configured timezone (that's debatable, I guess), there is
> a problem with this: we only get to learn the persistent timezone
> setting *after* having enabled persistence in the greeter, so anyone
> who wants to benefit from the behavior you're suggesting would have to
> either select their preferred keyboard layout every time anyway, or
> type their passphrase with a US layout. Not too convincing a UX,
> is it?
Sorry my sentence was not clear and doesn't make sense now that I
realized that this widget was setting the locale I prefer, and not the
country where I am.
>> (or otherwise the timezone in persistence will never be applied).
>
> I don't get why this would be the case (and that's an indicator that
> I may have misunderstood your point entirely).
>
> To be clearer, what I'm thinking of is:
>
> As a Tails user
> When I boot Tails
> And I select my preferred locale in the greeter
> And I enable persistence
> And I have no timezone configuration in my persistent volume
> Then the displayed timezone is derivated from the country I have selected
Some countries have several timezones, and people travel so that can
only be a best bet and we still need a way to configure it from the applet.
> and:
>
> As a Tails user
> When I boot Tails
> And I select my preferred locale in the greeter
> And I enable persistence
> And I have a timezone configured in my persistent volume
> Then the displayed timezone is set to the one configured in persistence
Those two scenarios will work and I am fine with them.
I guess I got confused by the fact that this widget displaying country
names in the Greeter doesn't set the place where I am but only the
variant of the language want to use, the "locale".
I think that if this confused me, it will confuse many more people. But
that is not a big deal as long as you can fix the timezone directly from
the applet. Your proposed scenarios will work fine for the moment, and
the revamp of the Greeter will be the place where to actually fix this
for good.
>> And a good rationale to allow people configuring the timezone from your
>> applet is that a user can fuck that up and correct it. If it is
>> configured from the Greeter then there is no way back. Plus it is not
>> strictly required to have this in the Greeter, so I'd rather have it
>> configured from the place where it matters really ("that clock on the
>> desktop is wrong, let's change that!") than having yet another option in
>> the Greeter when it can be somewhere else.
>
> In the current state of things (persistence configured in one place,
> locale settings in another place and not persistent), I agree that's
> probably the best we can do.
>
> I also hope that at some point, the idea of unifying all that stuff in
> one place (e.g. allow the user to configure persistence in the
> greeter, and allow the user to configure greeter settings from the
> same control panel inside the session once logged in) will be
> researched in more depth and implemented, and then we'll probably want
> to move the timezone configuration into this unified interface, but
> let's keep that for later. UX experts, please catch this ball! :)
Exactly.
signature.asc
Description: OpenPGP digital signature
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Installing caff?
Hi, intrigeri wrote (03 Oct 2013 22:36:02 GMT) : > I'm told monkeysign might be a worthwhile replacement for caff. > It supports the simplest and most common usecase of caff, and also > knows to use a webcam to scan for qr-codes. FTR: I've been trying it, reporting bugs upstream, and I've asked them if a backport for Squeeze could be imagined. I've filed #6338 and friends to track the next steps. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
