OK, thanks For people running Fedora 21 (GNOME 3.14), apps like evince
would show no border at all on X11 when running on, say, XFCE. Hopefully
if the Red Hat people involved with the Fedora GNOME packages have time
they can take the fix back port into Fedora 21's GNOME, if possible...
On Tue, M
Hey
More generally said:
To be honest it's quite disturbing to see which design/philosophic ways
especially GNOME but also GTK+ went the recent years.
It seems that the "traditional" desktop model is considered bad and
tried to be replaced wherever possible. Therefore, it's no big surprise
that
Hi;
On 24 March 2015 at 21:37, Andy Tai wrote:
> Can gtk+ add by default a (few-pixels-wide) frame around CSD windows that
> support the familiar window resizing behavior as commonly possible under a
> traditional window manager?
You mean like the current behaviour of having around 5 pixels of
Can gtk+ add by default a (few-pixels-wide) frame around CSD windows that
support the familiar window resizing behavior as commonly possible under a
traditional window manager? That should not waste too much additional
space but address significantly the loss of the traditional way of resizing
win
Hi;
whether or not Chromium uses client-side decorations has no bearing as
to GTK+ allowing them. The ability for application developers to
control the decorations of the windows they use has been a
long-standing request for GTK+; we've been talking about embedding
widgets inside decorations even
Hi!
> Besides, I don't think we should evaluate CSD in gtk+ based on
> Chromium implementation.
> IIRC Chromium moved away from gtk+ in favor of aura [1].
I was aware Chromium is not gtk based -- at least it shows problem is
widespread.
Evince has the same problem. But as atril is available, I
Hi,
Besides, I don't think we should evaluate CSD in gtk+ based on
Chromium implementation.
IIRC Chromium moved away from gtk+ in favor of aura [1].
Cheers,
Olivier
[1]
https://groups.google.com/a/chromium.org/forum/#!topic/chromium-dev/Zpu9801pPRc
On 23 March 2015 at 22:50, Jasper St. Pierr
On Mon, Mar 23, 2015 at 2:25 PM, Pavel Machek wrote:
> Hi!
>
> > I am not one of them, but there are a lot of people (including KDE
> > devs apparently) concerned about CSD because it means different
> > decorations depending on the apps/toolkit => Consistency might
> > suffer.
>
> Consistency al
On Fri 2015-03-06 01:21:32, Florian Müllner wrote:
> On Fri, Mar 6, 2015 at 12:59 AM Paul Davis
> wrote:
>
> > consider a simple dialog. Should it have a close button or not? If the
> > application adds an explicit close button, there are now two areas of the
> > window as displayed by most WMs w
Hi!
> I am not one of them, but there are a lot of people (including KDE
> devs apparently) concerned about CSD because it means different
> decorations depending on the apps/toolkit => Consistency might
> suffer.
Consistency already suffers. Chromium pulls this trick, and it means
you can't move
Le 06/03/2015 02:12, Matthias Clasen a écrit :
> On Thu, Mar 5, 2015 at 3:23 PM, Olivier Fourdan wrote:
>
> […]
>
>> Ideally, GTK should be able to use CSD even without a compositor. The
>> only reason it requires a compositor is because it uses the shadows as
>> resize handles. Ideally, it shou
Hi Matthias,
On 6 March 2015 at 02:12, Matthias Clasen wrote:
> On Thu, Mar 5, 2015 at 3:23 PM, Olivier Fourdan wrote:
> I have little desire to discuss the pros and cons of csd and whether
> something essential (consistency ?!) was lost when we started using
> them, but a few points are worth r
On Fri, Mar 6, 2015 at 2:10 AM Allin Cottrell wrote:
> OK, I can see that that's a legitimate difference (I'd say a
> "design" rather than a "philosophical" one, but hey).
Sure, let's call it different designs then ...
Fact is that
> the first alternative has been the status quo for a long ti
On Fri, Mar 6, 2015 at 12:59 AM Paul Davis
wrote:
> consider a simple dialog. Should it have a close button or not? If the
> application adds an explicit close button, there are now two areas of the
> window as displayed by most WMs which will, upon being clicked, cause the
> window to be hidden.
On Thu, Mar 5, 2015 at 3:23 PM, Olivier Fourdan wrote:
Hi,
I have little desire to discuss the pros and cons of csd and whether
something essential (consistency ?!) was lost when we started using
them, but a few points are worth replying to.
>
> The use of Motif MWM hints for this is a anachron
On Fri, 6 Mar 2015, Florian Müllner wrote:
On Fri, Mar 6, 2015 at 12:44 AM Allin Cottrell wrote:
Isn't there some dissonance here: "essential UI" embedded in
"decorations"? How did we come to this? [...] why not fix the WM
[...] rather than conflating UI with decoration?
Because it is not a
On Thu, 5 Mar 2015, Paul Davis wrote:
On Thu, Mar 5, 2015 at 5:44 PM, Allin Cottrell wrote:
On Thu, 5 Mar 2015, Florian Müllner wrote:
The worst thing that can happen when the toolkit forcefully rips CSD from
applications is that there is no more UI to save, navigate, load or
whatever esse
On Fri, Mar 6, 2015 at 12:44 AM Allin Cottrell wrote:
> Isn't there some dissonance here: "essential UI" embedded in
> "decorations"? How did we come to this? [...] why not fix the WM
> [...] rather than conflating UI with decoration?
Because it is not about working around any WM's (or more pre
On Thu, Mar 5, 2015 at 5:44 PM, Allin Cottrell wrote:
> On Thu, 5 Mar 2015, Florian Müllner wrote:
>
> The worst thing that can happen when the toolkit forcefully rips CSD from
>> applications is that there is no more UI to save, navigate, load or
>> whatever essential UI the applications happen
On Thu, 5 Mar 2015, Florian Müllner wrote:
The worst thing that can happen when the toolkit forcefully rips
CSD from applications is that there is no more UI to save,
navigate, load or whatever essential UI the applications happens
to put into its decorations.
Isn't there some dissonance her
On Thu, Mar 5, 2015 at 7:38 PM Olivier Fourdan wrote:
> > Yeap, that's a god idea, but that's for menubar, I am referring to
> decorations.
>
Well yes, I'm just pointing out that GtkSettings:gtk-shell-shows-app-menu
can be misused to determine whether the app is running under GNOME and
should us
On Thu, Mar 5, 2015 at 10:33 PM David Nečas wrote:
> As long as I can set up my DE to pretend not to support CSD, whatever
> the actual state is. Because this is, at the end, user's preference.
>
No, that does not work. All the toolkit can reasonably do is passing the
preference on to the appli
On Thu, Mar 05, 2015 at 10:01:44PM +0100, Olivier Fourdan wrote:
> > It's a subtle difference, but it shows our preference: we don't want a hint
> > to say that the DE prefers SSD, we want a hint to say that the DE can
> > support/not support CSD.
>
> That would work as well, why not.
As long as
On Thu, Mar 5, 2015 at 1:21 PM, David Nečas wrote:
> On Thu, Mar 05, 2015 at 10:01:44PM +0100, Olivier Fourdan wrote:
> > > It's a subtle difference, but it shows our preference: we don't want a
> hint
> > > to say that the DE prefers SSD, we want a hint to say that the DE can
> > > support/not s
Hi Jasper,
On 5 March 2015 at 21:39, Jasper St. Pierre wrote:
> Ah, I think I see the disagreement.
No real disagreement, just discussions :)
> We don't decide between SSD and CSD based on the presence of a compositor
> and _GTK_FRAME_EXTENTS, we instead push really hard for CSD with an SSD
> f
On Thu, 5 Mar 2015, Olivier Fourdan wrote:
Hi Emmanuele,
[plus responses to specific questions]
Sorry for the noise, but I just wanted to say, as one who runs X11
without a compositor (I appreciate an elegant desktop but have no
use for shadows, animations or transparency, I just want to ge
Ah, I think I see the disagreement.
We don't decide between SSD and CSD based on the presence of a compositor
and _GTK_FRAME_EXTENTS, we instead push really hard for CSD with an SSD
fallback.
It's a subtle difference, but it shows our preference: we don't want a hint
to say that the DE prefers SS
Hi
On 5 March 2015 at 20:09, Emmanuele Bassi wrote:
>>> On 5 March 2015 at 19:17, Florian Müllner wrote:
What about apps that rely on CSD for part of their UI? Will those have the
final word as well, or are they just screwed?
>>>
>>> The same as now without a compositor :)
>
> a) X11 w
Hi Emmanuele,
On 5 March 2015 at 20:04, Emmanuele Bassi wrote:
>> [...]
>
> That's not what I was saying. I'm saying that precisely because we
> don't have an homogeneous environment you cannot use the "it's
> inconsistent" argument.
>
> It will always be inconsistent, for one reason or for anoth
On Thu, Mar 5, 2015 at 10:37 AM, Olivier Fourdan wrote:
> +gtk-devel-list
>
> Argh sorry, I didn't mean to make that email private, thought my
> mailer would copy the list as well, my bad :(
>
> On 5 March 2015 at 19:29, Olivier Fourdan wrote:
> > Emmanuele,
> >
> > Let's face it, I doubt GTK+
Hi;
On 5 March 2015 at 18:38, Olivier Fourdan wrote:
> Copying the list as well, sorry...
>
> On 5 March 2015 at 19:32, Olivier Fourdan wrote:
>> Hi Florian,
>>
>> On 5 March 2015 at 19:17, Florian Müllner wrote:
>>> What about apps that rely on CSD for part of their UI? Will those have the
>>>
Hi;
On 5 March 2015 at 18:29, Olivier Fourdan wrote:
> Emmanuele,
>
> Let's face it, I doubt GTK+ will ever dominate the world, so the "it's
> not consistent because we're not using a single toolkit" is not going
> to be solved overnight. And frankly, as much as I like GTK+, I do not
> wish other
Copying the list as well, sorry...
On 5 March 2015 at 19:32, Olivier Fourdan wrote:
> Hi Florian,
>
> On 5 March 2015 at 19:17, Florian Müllner wrote:
>> What about apps that rely on CSD for part of their UI? Will those have the
>> final word as well, or are they just screwed?
>
> The same as no
+gtk-devel-list
Argh sorry, I didn't mean to make that email private, thought my
mailer would copy the list as well, my bad :(
On 5 March 2015 at 19:29, Olivier Fourdan wrote:
> Emmanuele,
>
> Let's face it, I doubt GTK+ will ever dominate the world, so the "it's
> not consistent because we're
Hi;
On 5 March 2015 at 17:51, Olivier Fourdan wrote:
> I am not one of them, but there are a lot of people (including KDE
> devs apparently) concerned about CSD because it means different
> decorations depending on the apps/toolkit => Consistency might suffer.
I don't strictly buy the "consiste
On Thu, Mar 5, 2015 at 6:52 PM Olivier Fourdan wrote:
> Apps that cannot or don't know how to
> do CSD would still be decorated, just like now => The final word still
> remains to the applications, just like now.
>
What about apps that rely on CSD for part of their UI? Will those have the
final
Hi all,
I am not one of them, but there are a lot of people (including KDE
devs apparently) concerned about CSD because it means different
decorations depending on the apps/toolkit => Consistency might suffer.
Currently, it's up to the apps/toolkits to tell the WM they want to
remain undecorated
37 matches
Mail list logo
