Thoughts about decoration information in the xdg_shell

Jasper St. Pierre jstpierre at mecheye.net
Tue Nov 19 05:45:04 PST 2013


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 <jessek123456 at gmail.com> wrote:

> 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 these hints to give a more consistent
> user experience.
>
> I think the benefits would be:
> 1.  Better Visual consistency between applications in a windows
> environment
> 2. (optional) Visual consistency between the windows environments on the
> same computer
> 3. The level of integration is optional - toolkits and windows environment
> can select the level of integration they want
> 4. It's extensible, new hints and level of integration of toolkits /
> windows environment could be developed at their own pace
> 5. Separation of concern - theme definition service would NOT do any
> rendering, only supply hints/recommendations
> 6. Equal beneficial for both CSD / SSD
> 7. Technical neutral regarding CSD / SSD
>
> Is this feasible?
>
>
>
>
>
>
>
> On Tue, Nov 19, 2013 at 1:34 AM, Bill Spitzak <spitzak at gmail.com> wrote:
>
>> 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 that it is a problem. IMO, toolkits should provide a
>>> way for an application to deeply integrate with the environment that
>>> they're running in and have as best as possible look and feel and behaviour.
>>>
>>> Maybe that's a race we can't win. But I do think we should try.
>>>
>>
>> I agree that it may be impossible, but it should be tried. And I think an
>> important first step is to treat the window frames and the rest of the
>> widgets the same, using the same library to draw them both.
>>
>> I think the solution is to try to come up with a minimal library with no
>> "objects" (except maybe a "context" that is reused for every call). It
>> would be something like "draw the outline of a button here with the
>> pressed-in state" and "tell me the box to draw the label in for a button
>> drawn here". The existence of the button is not stored by the library, the
>> bounding box is passed to the calls.
>>
>> Qt's QStyle are a pretty good first approximation.
>>
>> _______________________________________________
>> wayland-devel mailing list
>> wayland-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>>
>
>
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
>


-- 
  Jasper
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20131119/ee4acbd3/attachment.html>


More information about the wayland-devel mailing list