To clarify I'm not pushing for Qubes to change it's behaviour at all, you
are completely doing a great thing here. As mentioned it is actually a
feature that anything drawn that could position itself outside of the
window gets a border (This is similar to how web page content is always
clearly never overlapping the browser chrome without clear indication).
I haven't delved into the widget level representation of these windows
however it would be good to know from the widgets that they have the border
displayed certainly. If this isn't something dom0 exposes to the widget
layer then it would be nice if Firefox can access that (That way we don't
need to do OS specific CSS within the browser just implement @media
(--moz-bordered-browser-window) {}. or something similar). I think the gtk
method would be: get_has_frame() if we can check that it has a border then
we can potentially make forks in our theme itself which really would reduce
the issues mentioned in the bug.
So one of my suggestions was around changing the UX within the tooltips and
various other features within the browser to have skinnier or simpler UX.
The drop shadows and triangle ^ tip that comes out of permission prompts to
be removed as when it is bordered it looks wrong.
Long term we could look at drawing this stuff internally though as
mentioned is unlikely to change any time soon.
On Thu, Jan 5, 2017 at 11:44 PM, <[email protected]> wrote:
>
>
> On Friday, 6 January 2017 10:35:36 UTC+11, Marek Marczykowski-Górecki
> wrote:
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA256
>>
>> On Thu, Jan 05, 2017 at 06:31:33AM -0800, [email protected] wrote:
>> > I just wanted to share a bug regarding Firefox usability issues in
>> Qubes. I
>> > spoke to Joanna Rutkowska and she suggested discussing it here.
>> >
>> > https://bugzilla.mozilla.org/show_bug.cgi?id=1326341
>> >
>> > My hope is that we can discover when a native window has been bordered
>> from
>> > the window manager which we could then expose to native themes. This
>> would
>> > allow some subtle changes to simplify the issues we have mentioned in
>> the
>> > bug.
>>
>> I think the tiny border around some tooltip-type windows should be
>> considered Qubes-specific feature, not a bug. If this is separate
>> window, it will have have a colorful border enforced by dom0, regardless
>> of what VM application wants. If you want to avoid this, don't create a
>> separate window (which is what you've proposed there - but I don't think
>> it's realistic to expect this major change).
>>
>> The "Reader View" window indeed is worse case - for some reason it gets
>> full decoration, instead of the thin one. On Qubes gui-protocol level
>> this
>> is a difference between windows with override-redirect X11 flag set or
>> not.
>> But I have no idea how it looks at GTK level.
>>
>
> The Reader View is actually a separate window. As I said, "New window =
> new window."
> Is there a way to not have the coloured border on tool-tip type windows?
> In the things I built for use, in Dom0 they are fine, but in each VM it is
> a little annoying at times when it has the white background overlay where
> it needs to really be transparent. I think that's the only real issue I
> have with the tooltip overlay border and background.
>
> Or is that a really big job to add in that?
>
> Also, is it possible to have that tooltip border skinnier? As in perhaps
> make it 1px of colour?
>
--
You received this message because you are subscribed to the Google Groups
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-devel/CAO7HTqyU5Ep%3DB9uABA6%3D57ZeMpt%3D1LFfzXhEQLhF5pwN6UMzDA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
