Re: Collaboration on standard Wayland protocol extensions

2016-03-31 Thread Peter Hutterer 
On Thu, Mar 31, 2016 at 05:37:10PM +0200, Benoit Gschwind wrote:
> Hello Drew,
> 
> After reading the thread stream, I think there is two mixed questions in
> your email that is missleading. And most reply try to address both in
> one reply. I thing Daniel get the point (if I understood him well).
> 
> I read the two following questions:
> 
> [1] As almost all compositor will need the following features:
> - Screen capture
> - Output configuration
> - More detailed surface roles (should it be floating, is it a modal,
>   does it want to draw its own decorations, etc)
> - Input device configuration.
> 
> It would be nice if we go around a table to define some shared protocol.
> For those interested I will start writing an XML spec. you are welcome
> to contribute.

I'm mostly talking about the input device configuration here but an XML is
the wrong place to start, imo. As I said above, it won't add anything much
and you still have to do the implementation everywhere. The only meaningful
thing you can do is write a library that compositors *want* to use that
reads the configuration items from some magic place and applies them to the
libinput device.

and for those that must be handled in the compostior (key remappings, for
example) you'll essentially end up writing a libcompositorinput. but now
you're quite close to internal compositor semantics so making this a generic
thing is not going to be trivial.

Cheers,
   Peter

> 
> [2] This features are mandatory and should be in the core protocol.
> 
> 
> If my reading is correct, I reply to [1]:
> 
> I'm in, I would like to avoid implements tools that setup screen layout,
> keymaping and screen capture. Thus having a protocol to handle those
> case is welcome. From my point of view of WM developer (in opposition of
> DE developer)
> 
> 
> For [2], I suggest that you starting with not-adopted protocol
> specification and if they gather enough approval, you try to push it as
> _optionnal_ standard protocol. By optionnal I mean the compositor
> developer can choose to implement it or not. by standard I mean if a
> developer want implement those feature we strongly encouraged developper
> to use them instead of providing a new one.
> 
> Best regards.
> 
> --
> Benoit (blocage) Gschwind
> 
> Le 27/03/2016 22:34, Drew DeVault a écrit :
> > Greetings! I am the maintainer of the Sway Wayland compositor.
> > 
> > http://swaywm.org
> > 
> > It's almost the Year of Wayland on the Desktop(tm), and I have
> > reached out to each of the projects this message is addressed to (GNOME,
> > Kwin, and wayland-devel) to collaborate on some shared protocol
> > extensions for doing a handful of common tasks such as display
> > configuration and taking screenshots. Life will be much easier for
> > projects like ffmpeg and imagemagick if they don't have to implement
> > compositor-specific code for capturing the screen!
> > 
> > I want to start by establishing the requirements for these protocols.
> > Broadly speaking, I am looking to create protocols for the following
> > use-cases:
> > 
> > - Screen capture
> > - Output configuration
> > - More detailed surface roles (should it be floating, is it a modal,
> >   does it want to draw its own decorations, etc)
> > - Input device configuration
> > 
> > I think that these are the core protocols necessary for
> > cross-compositor compatability and to support most existing tools for
> > X11 like ffmpeg. Considering the security goals of Wayland, it will also
> > likely be necessary to implement some kind of protocol for requesting
> > and granting sensitive permissions to clients.
> > 
> > How does this list look? What sorts of concerns do you guys have with
> > respect to what features each protocol needs to support? Have I missed
> > any major protocols that we'll have to work on? Once we have a good list
> > of requirements I'll start writing some XML.
> > 
> > --
> > Drew DeVault
> > ___
> > wayland-devel mailing list
> > wayland-de...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/wayland-devel
> > 
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
> 
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Collaboration on standard Wayland protocol extensions

2016-03-31 Thread Benoit Gschwind 
Hello Drew,

After reading the thread stream, I think there is two mixed questions in
your email that is missleading. And most reply try to address both in
one reply. I thing Daniel get the point (if I understood him well).

I read the two following questions:

[1] As almost all compositor will need the following features:
- Screen capture
- Output configuration
- More detailed surface roles (should it be floating, is it a modal,
  does it want to draw its own decorations, etc)
- Input device configuration.

It would be nice if we go around a table to define some shared protocol.
For those interested I will start writing an XML spec. you are welcome
to contribute.

[2] This features are mandatory and should be in the core protocol.


If my reading is correct, I reply to [1]:

I'm in, I would like to avoid implements tools that setup screen layout,
keymaping and screen capture. Thus having a protocol to handle those
case is welcome. From my point of view of WM developer (in opposition of
DE developer)


For [2], I suggest that you starting with not-adopted protocol
specification and if they gather enough approval, you try to push it as
_optionnal_ standard protocol. By optionnal I mean the compositor
developer can choose to implement it or not. by standard I mean if a
developer want implement those feature we strongly encouraged developper
to use them instead of providing a new one.

Best regards.

--
Benoit (blocage) Gschwind

Le 27/03/2016 22:34, Drew DeVault a écrit :
> Greetings! I am the maintainer of the Sway Wayland compositor.
> 
> http://swaywm.org
> 
> It's almost the Year of Wayland on the Desktop(tm), and I have
> reached out to each of the projects this message is addressed to (GNOME,
> Kwin, and wayland-devel) to collaborate on some shared protocol
> extensions for doing a handful of common tasks such as display
> configuration and taking screenshots. Life will be much easier for
> projects like ffmpeg and imagemagick if they don't have to implement
> compositor-specific code for capturing the screen!
> 
> I want to start by establishing the requirements for these protocols.
> Broadly speaking, I am looking to create protocols for the following
> use-cases:
> 
> - Screen capture
> - Output configuration
> - More detailed surface roles (should it be floating, is it a modal,
>   does it want to draw its own decorations, etc)
> - Input device configuration
> 
> I think that these are the core protocols necessary for
> cross-compositor compatability and to support most existing tools for
> X11 like ffmpeg. Considering the security goals of Wayland, it will also
> likely be necessary to implement some kind of protocol for requesting
> and granting sensitive permissions to clients.
> 
> How does this list look? What sorts of concerns do you guys have with
> respect to what features each protocol needs to support? Have I missed
> any major protocols that we'll have to work on? Once we have a good list
> of requirements I'll start writing some XML.
> 
> --
> Drew DeVault
> ___
> wayland-devel mailing list
> wayland-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
> 
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Fixing calendars in GNOME

2016-03-31 Thread Alberto Salvia Novella 
As you probably know, for one reason or other, scheduling applications 
have important drawbacks in GNOME right now. And after studying the 
problem for a while, I came to the conclusion that the California 
application is the closest to do it right now.


The only thing that it is stopping it from succeeding is a small list of 
bugs that prevented users wanting to start using it in real world:


(https://bugs.launchpad.net/ubuntu/+source/california)

So here is the point: I would want to propose that we summit the fixing 
of that small amount of flaws as a Google Summer of Code project if 
possible, and get a calendaring application that finally works well.


I have been talking to the people in the California mailing list, and 
some offered volunteers to fix it. The only thing we would need is a 
person with some experience developing with the Vala programming 
language that will offer to eventually mentor the volunteers.


The source code of the application is this:

(https://github.com/GNOME/california)




smime.p7s
Description: S/MIME Cryptographic Signature
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Deleted '-' milestone on bugzilla

2016-03-31 Thread Zeeshan Ali (Khattak) 
Hi again,

Sorry, false alarm. :)

On Thu, Mar 31, 2016 at 2:26 PM, Zeeshan Ali (Khattak)
 wrote:
> Hi everyone,
>
> I was editting milestones of gnome-boxes product on bugzilla and I
> decided to delete the '-' milestone (which AFAIK means unknown) and
> seems I ended up deleting it for all products. :(
>
> I'm terribly sorry for this but I think it's more the bugzilla
> interface that's to blame here since the it gives me the impression
> that I'm only editing one product.
>
> Anyway, I apologize for this inconvenience.
>
> --
> Regards,
>
> Zeeshan Ali (Khattak)



-- 
Regards,

Zeeshan Ali (Khattak)
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Deleted '-' milestone on bugzilla

2016-03-31 Thread Zeeshan Ali (Khattak) 
Hi everyone,

I was editting milestones of gnome-boxes product on bugzilla and I
decided to delete the '-' milestone (which AFAIK means unknown) and
seems I ended up deleting it for all products. :(

I'm terribly sorry for this but I think it's more the bugzilla
interface that's to blame here since the it gives me the impression
that I'm only editing one product.

Anyway, I apologize for this inconvenience.

-- 
Regards,

Zeeshan Ali (Khattak)
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Collaboration on standard Wayland protocol extensions

2016-03-31 Thread Simon McVittie 
On 29/03/16 13:11, Drew DeVault wrote:
> I see what you're getting at now. We can get the pid of a wayland
> client, though, and from that we can look at /proc/cmdline, from which
> we can get the binary path.

This line of thinking is a trap: rummaging in /proc/$pid is not suitable
for use as a security mechanism. If a client can queue up a malicious
privileged action (stuff it into the socket's send-buffer), and then
race with the compositor to exec() something that would legitimately be
allowed to take that action before the request is processed, then you lose.

See  for details of
the equivalent in D-Bus. Mainline dbus on Unix was never vulnerable to
this (because we use credentials-passing to get the uid), but there used
to be an out-of-tree LSM integration patch set (for Maemo) that was.
(That bug was about documenting the attack so that we never accidentally
introduce it.)

If you want to map processes to executable-based privilege domains in a
way that cannot be faked, you will have to use their LSM labels
(SELinux, Smack or other xattr-based labelling, or AppArmor or other
path-based labelling) which are specifically designed to do this. A
Wayland equivalent of D-Bus' GetConnectionCredentials() would probably
be useful.

S
-- 
Simon McVittie
Collabora Ltd. 

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Collaboration on standard Wayland protocol extensions

2016-03-31 Thread Daniel Stone 
Hi,

On 31 March 2016 at 00:16, Drew DeVault  wrote:
> Simply because xrandr was/is a poorly implemented mess doesn't mean that
> we are going to end up making a poorly implemented mess. We have the
> benefit of hindsight. After all, xorg is a poorly implemented mess but
> we still made Wayland, didn't we? (Though some could argue that we've
> just ended up with a well implemented mess...)

X and Wayland protocols have very different design principles guiding
them. X (often by necessity) exposes as much as possible of its
internal workings to clients, and allows total external manipulation.
That's not the case for Wayland, so what you're proposing is a
significant departure.

Cheers,
Daniel
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

GNOME Photos plans for 3.22

2016-03-31 Thread Debarshi Ray 
Hello everybody,

GNOME 3.20 was a busy cycle for Photos, with a lot of activity
from new contributors, and we want to carry that momentum into
3.22. While we have a roadmap [1] to list the priority bugs
and features for the near future, I want to draw your attention
to two big things that we want to achieve for GNOME 3.22.

* Uploads & sharing: Uploading and sharing to online accounts -
  Google, Facebook and Flickr [2]. (proposed for GSoC & Outreachy)

  I think it is time to integrate sharing more tightly into the
  content applications, and this is a step in that direction.
  Realistically speaking, we will target only one of the
  aforementioned providers and I am currently thinking of Google.
  Once the basic framework in place we can add more.

* Import from device: Importing images from cameras, SD cards and
  USB sticks [3].

  This is another thing that has, so far, been missing from the
  content applications, and I think it is a crucial feature when
  dealing with images.

Cheers,
Rishi

[1] https://wiki.gnome.org/Apps/Photos/Roadmap
[2] http://bugzilla.gnome.org/show_bug.cgi?id=751181
[3] http://bugzilla.gnome.org/show_bug.cgi?id=751212

pgpc3HqSWCRaa.pgp
Description: PGP signature
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list