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;
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;
On 24 March 2015 at 21:37, Andy Tai a...@atai.org 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
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
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,
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,
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.
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
On Mon, Mar 23, 2015 at 2:25 PM, Pavel Machek pa...@ucw.cz 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
On Fri 2015-03-06 01:21:32, Florian Müllner wrote:
On Fri, Mar 6, 2015 at 12:59 AM Paul Davis p...@linuxaudiosystems.com
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
Le 06/03/2015 02:12, Matthias Clasen a écrit :
On Thu, Mar 5, 2015 at 3:23 PM, Olivier Fourdan four...@gmail.com 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,
Hi Matthias,
On 6 March 2015 at 02:12, Matthias Clasen matthias.cla...@gmail.com wrote:
On Thu, Mar 5, 2015 at 3:23 PM, Olivier Fourdan four...@gmail.com wrote:
I have little desire to discuss the pros and cons of csd and whether
something essential (consistency ?!) was lost when we started
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
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 I can
On Thu, Mar 5, 2015 at 10:37 AM, Olivier Fourdan four...@gmail.com 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 four...@gmail.com wrote:
Emmanuele,
Let's
Hi Emmanuele,
On 5 March 2015 at 20:04, Emmanuele Bassi eba...@gmail.com 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
On Thu, Mar 5, 2015 at 1:21 PM, David Nečas y...@physics.muni.cz 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
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
Hi
On 5 March 2015 at 20:09, Emmanuele Bassi eba...@gmail.com wrote:
On 5 March 2015 at 19:17, Florian Müllner fmuell...@gnome.org 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
Hi Jasper,
On 5 March 2015 at 21:39, Jasper St. Pierre jstpie...@mecheye.net 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
On Thu, Mar 5, 2015 at 10:33 PM David Nečas y...@physics.muni.cz 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
On Thu, Mar 5, 2015 at 5:44 PM, Allin Cottrell cottr...@wfu.edu 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
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
On Thu, 5 Mar 2015, Paul Davis wrote:
On Thu, Mar 5, 2015 at 5:44 PM, Allin Cottrell cottr...@wfu.edu 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
On Fri, Mar 6, 2015 at 12:44 AM Allin Cottrell cottr...@wfu.edu 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
On Fri, 6 Mar 2015, Florian Müllner wrote:
On Fri, Mar 6, 2015 at 12:44 AM Allin Cottrell cottr...@wfu.edu 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?
On Thu, Mar 5, 2015 at 3:23 PM, Olivier Fourdan four...@gmail.com 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
On Fri, Mar 6, 2015 at 2:10 AM Allin Cottrell cottr...@wfu.edu 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
On Fri, Mar 6, 2015 at 12:59 AM Paul Davis p...@linuxaudiosystems.com
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
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
+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 four...@gmail.com wrote:
Emmanuele,
Let's face it, I doubt GTK+ will ever dominate the world, so the it's
not consistent
Hi;
On 5 March 2015 at 17:51, Olivier Fourdan four...@gmail.com 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
On Thu, Mar 5, 2015 at 6:52 PM Olivier Fourdan four...@gmail.com 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
Copying the list as well, sorry...
On 5 March 2015 at 19:32, Olivier Fourdan four...@gmail.com wrote:
Hi Florian,
On 5 March 2015 at 19:17, Florian Müllner fmuell...@gnome.org wrote:
What about apps that rely on CSD for part of their UI? Will those have the
final word as well, or are they
Hi;
On 5 March 2015 at 18:29, Olivier Fourdan four...@gmail.com 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
35 matches
Mail list logo
