Re: [Tails-dev] Shutdown button in camouflage mode

Delete this message

Reply to this message
Author: Alan
Date:  
To: tails-dev
Subject: Re: [Tails-dev] Shutdown button in camouflage mode
Hi,

On Fri, 15 Feb 2013 18:52:39 +0100 intrigeri <intrigeri@???> wrote:
>
> Alan wrote (14 Feb 2013 13:48:50 GMT) :
> > Well, the change was in a bigger commit
> > f42f51987f8ec82bd10d65a46113a158ffc70bf7 that we probably don't want
> > to revert as a whole.
>
> FYI, "git revert --no-commit" + "git add -p" allows to selectively
> revert parts of a commit.
>

Thanks.

> > And there were no "reboot" and "lock screen" actions.
>
> I acknowledge adding a "reboot" action is welcome, and I will possibly
> take it, even if it is not a bugfix.
>
> OTOH, the "lock" action is a mistake, I believe, as we don't install
> gnome-screensaver yet...
>
> Here are simple recipes, applicable late in a release cycle, that help
> keeping release managers happy:
>
>   1. Propose *minimal* changes that *only* fix the bug they are
>      supposed to.
>   2. If possible, reuse code that was exposed to some testing already,
>      e.g. simply revert the faulty change instead of introducing a new
>      way to fix.
>   3. Don't try to sneak in further awesome improvements that don't
>      belong to the bug you're fixing. Keep them for later. Seriously.
>   4. If in doubt, refer to 1 :)

>
> In my experience, this set of recipes works both with me and with the
> Debian release team. Every additional fancy idea or change often
> introduces regressions, needs additional communication round-trips,
> and makes people spend more time on the topic that what they've
> happily accepted to in the first place.
>

Sorry for the inconvenience.

> > I made the same changes as with my previous commit, but the way
> > that was done in 0.15 in a newer version of the branch (to be
> > rewritten before a merge as I let old stuff to let people compare).
>
> Awesome.
>
> I've rewritten history to skip the commit+revert and throw away the
> "lock" entry: bugfix/shutdown_with_camouflage-squashed.
>
> If someone tests and ACK's this, I'm happy to take it for 0.17.
> Else, it will have to wait for the next (point-)release.
>

Thanks. I applied the patch to a running experimental and it works. I
volonteer to test it on top of 0.17rc1 once I got it.

> >> If there are good reasons to do it the way this branch does,
> >> probably fine with me, but then, I suggest putting the .desktop
> >> data in separate files, and using `cp' rather than `cat' in
> >> `tails-activate-winxp-theme'. This way, overzealous translators may
> >> find them with `find' (and we could even document it, if it's not
> >> documented yet). See what I mean? :)
> >>
> > I was trying to *only* fix the bug in camouflage mode. In 0.15 there
> > were .desktop files for these actions that were showing up in the
> > menus not only in camouflage mode. But that might indeed be better.
>
> I agree displaying these menu entries in camouflage mode only would be
> nice. That's indeed exactly why I suggested "using `cp' rather than
> `cat'" above (as in "cp from a non-standard location into
> /usr/share/applications/"). I'm sorry I was not clear enough. It is
> now too late to experiment with yet another implementation way, so
> that will be material for 0.18 if someone feels like it.
>

Well actually I don't see it as a problem to have these entries in
menus in all modes and not only with camouflage. I was just imagining
in the first place that you wouldn't want to merge a patch changing all
modes.

> > I was also trying to make these buttons show up straignt in the
> > "System" menu and not in "Administration" which seems me a bit wired
> > place to go to shutdown my computer.
>
> This, too, would be a nice improvement for Tails 0.18 :)
>

If I find how to do, it might be candidate.

> > Also, I fail to see the point of a custom "shutdown helper" applet,
> > which seems me to try to do the same that is implemented straight in
> > gnome-panel as "drawer":
>
> IIRC, I had tried the drawer approach, failed, and then suggested the
> helper way, but my memory may be failing, or perhaps I didn't try hard
> enough. But yeah, in any case, even if the applet is written already,
> and while it would be a bit sad somehow, replacing it with a simple
> drawer would simplify our codebase, and I would warmly welcome it!
> (Note: check that the drawer thing still works in GNOME3 Fallback.)
>

Well let's say these to might be candidate if I want some not urgent
thing to play with.

> Interpretation note: I'm sick, I'm very late to put a RC out, so I'm
> not exactly in the mood to review buggy bugfixes. Thanks for working
> on this, sorry for being a bit of a pain.
>

No problem, and thanks for managing this release.

Cheers