If you (or anyone else) wants to write the code and spec for
Qt/GTK+/EFL/westoy, go for it.
I, personally, am not going to do any engineering effort to implement such
a cross-toolkit theme definition.
On Tue, Nov 19, 2013 at 5:09 AM, Jesse K wrote:
> Hi,
>
> What about having a theme definitio
Hi,
What about having a theme definition service for graphical environment?
This theme definition would contains "hints" about windows decorations,
colors, fonts, textures, and much more.
The hints could only be recommendations - not requirements. The toolkits,
shells, CSD, SSD should ideally use
Thiago Macieira wrote:
The only detail is that this extension doesn't exist yet, so the compositor
needs to check whether the client acknowledged the message. If it didn't, then
the compositor must assume the client is decorating itself.
I think it will be ok for the compositor to assume it w
Thiago Macieira wrote:
On segunda-feira, 18 de novembro de 2013 10:28:12, Bill Spitzak wrote:
Can you explain why "consistency" is so important for the window frame,
but is not a problem for the buttons and scrollbars and text fields and
everything else inside the frame?
I personally think th
Neil Roberts wrote:
You are advocating requiring *both* clients and compositors to be able
to draw decorations. Why make it so complicated?
No, I didn't say that at all. I am saying that in xdg-shell we need to
specify that either CSD is required or SSD is required.
Okay, you are now saying
2013/11/18 Neil Roberts
> Thiago Macieira writes:
>
> > Make it simpler: all clients MUST be able to draw decorations. That's
> what
> > Wayland up until now requires anyway.
>
> I think it's a shame to throw out the idea of making the policy be that
> clients are allowed to expect SSD if they d
On segunda-feira, 18 de novembro de 2013 10:35:58, Bill Spitzak wrote:
> I also want to put in a very strong vote against any kind of idea that a
> client can "prefer SSD", as is being continuously suggested here with
> comments like this:
>
> Thiago Macieira wrote:
> > A client MAY ask the compos
On segunda-feira, 18 de novembro de 2013 10:31:15, Bill Spitzak wrote:
> So here is even simpler:
>
> - All clients MUST be able to draw decorations
>
> - The compositor, as part of configure events, can tell the client to
> not draw decorations.
That also works and it's even simpler.
--
Thia
On segunda-feira, 18 de novembro de 2013 10:28:12, Bill Spitzak wrote:
> Can you explain why "consistency" is so important for the window frame,
> but is not a problem for the buttons and scrollbars and text fields and
> everything else inside the frame?
I personally think that it is a problem.
Bill Spitzak writes:
> Can you explain why "consistency" is so important for the window
> frame, but is not a problem for the buttons and scrollbars and text
> fields and everything else inside the frame?
In the case of a game there probably wouldn't be any buttons or
scrollbars so the only thin
I also want to put in a very strong vote against any kind of idea that a
client can "prefer SSD", as is being continuously suggested here with
comments like this:
Thiago Macieira wrote:
A client MAY ask the compositor to draw decorations.
This is going to be used as an excuse by clients to *
Again this is excessively complicated.
The compositor in current weston can already tell the client to not draw
decorations. This indicator is combined with the "fullscreen" indicator
but the communication is already going this way.
So here is even simpler:
- All clients MUST be able to draw
Neil Roberts wrote:
I guess you could make a toolkit-agnostic decorations library using
subsurfaces that these types of applications can use. However I don't
think that will solve the consistency issue because most game-type
applications will want to bundle all of their dependencies so they will
Thiago Macieira writes:
> Make it simpler: all clients MUST be able to draw decorations. That's what
> Wayland up until now requires anyway.
I think it's a shame to throw out the idea of making the policy be that
clients are allowed to expect SSD if they don't want to draw decorations
themselve
On Monday 18 November 2013 02:58:41 Jasper St. Pierre wrote:
> If the KDE team feels extremely strongly about server-side decorations, I'd
> like to see that passion channeled into actually building things. Write an
> extension that does what you want. Patch weston/westoy and KWin/Qt to
> implement
On segunda-feira, 18 de novembro de 2013 08:36:48, Martin Gräßlin wrote:
> Such a protocol would make runtime switching impossible, wouldn't it?
"Now you draw, now I draw" ? Yes.
> That's a really important use case for us to turn a tablet into a desktop
> and vice versa.
I don't think so. You
So, let me be clear:
I'm not fundamentally opposed to any of this. Personally, I feel that
decorations aren't something that we need server-side support for to
establish consistency between apps, and that there's a myriad of other
cross-app consistency bugs and issues that we should solve first (i
On segunda-feira, 18 de novembro de 2013 08:20:37, Martin Gräßlin wrote:
> I'm afraid that exactly that will happen then and I think it's the shell's
> responsibility to enforce the style. For things like Plasma Active or other
> tiling setups we need to have the client without decorations. Our u
On Sunday 17 November 2013 22:27:29 Thiago Macieira wrote:
> On segunda-feira, 18 de novembro de 2013 06:37:47, Martin Gräßlin wrote:
> > That sounds look a good solution to me!
>
> Make it simpler: all clients MUST be able to draw decorations. That's what
> Wayland up until now requires anyway.
>
On Sunday 17 November 2013 22:54:47 Thiago Macieira wrote:
> Applications that do not negotiate must figure out the proper decoration on
> their own. It's not the compositor's job to enforce the style. If the
> application then looks out of place, it's the application's fault, not the
> compositor'
On domingo, 17 de novembro de 2013 22:42:44, Alex Elsayed wrote:
> > A client MAY ask the compositor to draw decorations. If and only if the
> > compositor replies that it will, the client is then not required to draw
> > them. The only compositor likely to even understand this extension is
> > kwi
Thiago Macieira wrote:
> On segunda-feira, 18 de novembro de 2013 06:37:47, Martin Gräßlin wrote:
>> That sounds look a good solution to me!
>
> Make it simpler: all clients MUST be able to draw decorations. That's what
> Wayland up until now requires anyway.
It's a given that they must be *able
On segunda-feira, 18 de novembro de 2013 06:37:47, Martin Gräßlin wrote:
> That sounds look a good solution to me!
Make it simpler: all clients MUST be able to draw decorations. That's what
Wayland up until now requires anyway.
A client MAY ask the compositor to draw decorations. If and only if
On Saturday 16 November 2013 11:32:50 you wrote:
> On Nov 15, 2013 5:27 AM, "Martin Gräßlin" wrote:
> > Hi all,
> >
> > this is a reply to the topic of whether to have information about
>
> decorations
>
> > in the xdg_shell at all (see [1]). Sorry that I don't reply to the right
> > message, h
On 11/16/2013 09:32 AM, Jason Ekstrand wrote:
The first flag would be the compositor's preference as to whether the
client should decorate or not. If 1, the server prefers that the
client draws decorations; if 0, the server prefers to handle decorating
itself. The second flag would specify wh
On Nov 15, 2013 5:27 AM, "Martin Gräßlin" wrote:
>
> Hi all,
>
> this is a reply to the topic of whether to have information about
decorations
> in the xdg_shell at all (see [1]). Sorry that I don't reply to the right
> message, had not been subscribed to the list.
>
> I want to outline why we in
One thing everybody seems to be ignoring is that current wl_shell
already has a "don't draw CSD" flag. It is the "fullscreen" indicator.
As I see it:
- Clients must be able to draw CSD.
- The compositor can tell the client whether to draw CSD and can change
this over time. It can also tell it
On 11/15/2013 01:50 PM, Jasper St. Pierre wrote:
> Ah, whoops, I read your email wrong. It sounds like you're also in favor
> of requiring CSD support from the client.
>
> That said, I'm curious about cases like Nautilus under SSD. Should we
> hide the close button, or do anything like that to mak
On Friday 15 November 2013 07:50:55 Jasper St. Pierre wrote:
> Ah, whoops, I read your email wrong. It sounds like you're also in favor of
> requiring CSD support from the client.
Yep, I'm fine with ensuring that CSD is the required fallback. As said: I don't
want to force anybody to SSD :-)
>
>
On Fri, Nov 15, 2013 at 8:07 AM, Alex Elsayed wrote:
> Jasper St. Pierre wrote:
>
> > On Fri, Nov 15, 2013 at 6:17 AM, Martin Gräßlin
> > wrote:
> >
>
> >
> > I think the trap that I personally don't want to run into is the case
> > where we have a compositor that doesn't support SSD coupled to
Jasper St. Pierre wrote:
> On Fri, Nov 15, 2013 at 6:17 AM, Martin Gräßlin
> wrote:
>
>
> I think the trap that I personally don't want to run into is the case
> where we have a compositor that doesn't support SSD coupled to a client
> that doesn't support CSD. Nobody can draw the decorations,
Ah, whoops, I read your email wrong. It sounds like you're also in favor of
requiring CSD support from the client.
That said, I'm curious about cases like Nautilus under SSD. Should we hide
the close button, or do anything like that to make it adapt to an SSD
environment?
On Fri, Nov 15, 2013 at
On Fri, Nov 15, 2013 at 6:17 AM, Martin Gräßlin wrote:
> Hi all,
>
> this is a reply to the topic of whether to have information about
> decorations
> in the xdg_shell at all (see [1]). Sorry that I don't reply to the right
> message, had not been subscribed to the list.
>
> I want to outline why
33 matches
Mail list logo
