Re: DBus interface for meeting creation

[Corentin Noël]

Le mardi 13 mars 2018 à 13:30 +, Simon McVittie a écrit :
> On Tue, 13 Mar 2018 at 13:11:45 +, David Woodhouse wrote:
> > We need to spawn a "new meeting" editor in the client of the user's
> > choice, pre-populated with meeting dial-in information, conference-
> > specific attendees, etc.
> 
> Rather than inventing a small subset of iCalendar encoded into
> D-Bus parameters, would it perhaps make sense to implement this as
> a MIME-type handler for iCalendar files, or by sending an iCalendar
> blob over D-Bus, or by documenting a somewhat lossless transformation
> of iCalendar into a D-Bus data structure in the same way that
> https://telepathy.freedesktop.org/spec/Connection_Interface_Contact_I
> nfo.html
> works with a lossless transformation of a vCard?

I wonder why is a D-Bus interface even required here. The simplest
solution (and already working one) is to just pass an ical file to the
calendar app with xdg-open.

> 
> > I've implemented a plugin for Evolution which supports this:
> > 
> > dbus-send --print-reply --dest=im.pidgin.event_editor \
> >/im/pidgin/event_editor im.pidgin.event_editor.CreateEvent \
> >string:"Organizer " \
> >string:"Meeting summary" \
> >string:"Meeting location" \
> >string:"Meeting description" \
> >array:string:attend...@example.org,attend...@example.org
> 
> This is (presumably) fine for Lync, but as a standardized protocol I
> think you'll need extensibility: if a different protocol has a
> different
> idea of what is in a meeting invitation, then you'll need a way to
> include fields that wouldn't have appeared in a Lync meeting
> invitation.
> 
> smcv
> ___
> xdg mailing list
> xdg@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/xdg
___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

Re: Preference Opening Specification

[Corentin Noël]

Le 16 janv. 2016 1:03 AM, "Mattias Andrée" <maand...@member.fsf.org> a
écrit :
>
> Okay, so it is not fatal. But why do you need it?
> I think it is important not to introduce a bunch of
> standards just for completeness's sake, only if they
> are actually needed.
I actually need it in several places in the OS, in our indicators we have
links to settings panel, in settings panels themselves we have crosslinks
to other panels and in some of our apps we tell the user to add an account
to the online accounts panel and give a button to open it. We also could
use it in our web browser to ask the user to check his connectivity...
>
> On Sat, 16 Jan 2016 00:57:36 +0100
> Corentin Noël <coren...@elementaryos.org> wrote:
>
> > Le 16 janv. 2016 12:53 AM, "Mattias Andrée"
> > <maand...@member.fsf.org> a écrit :
> > >
> > > Why would this be useful? And what about when none of
> > > these are implemented, would that be a problem?
> >
> > It's then the same problem as clicking on an URL when you
> > don't have any web browser. Nothing will happen, your
> > users will complain as "not working", but it the same if
> > you hardcode things for unity-control-center and you only
> > have gnome-control-center installed.
> >
> > >
> > > On Sat, 16 Jan 2016 00:28:37 +0100
> > > Corentin Noël <coren...@elementaryos.org> wrote:
> > >
> > > > Hi everyone,
> > > > Many desktop environments have their own System
> > > > Settings applications, but there is no clear way for
> > > > developers to call settings from within their
> > > > applications  without resorting to hardcoding in
> > > > commands for each and every Settings app. I propose a
> > > > new specification that similar to other scheme
> > > > handling in Desktop files, through a new settings://
> > > > URI. With this, developers could call on Settings
> > > > applications, without resorting to hardcoding,
> > > > provided a desktop environment supports it. For
> > > > example, an application calling settings://bluetooth
> > > > would open Bluetooth settings for a given desktop
> > > > environment.
> > > >
> > > > Here is the specification I propose:
> > > >
> >
https://docs.google.com/document/d/1N0uqNtVXEFn3cLgNMeN75mP_dpMpCco-7uw5PKow-_Q/edit?usp=sharing
> > > >
> > > > I'm of course open to changes and feedbacks,
> > > > Corentin Noël
> > > > elementary OS Developer
> > >
> > >
> > > ___
> > > xdg mailing list
> > > xdg@lists.freedesktop.org
> > > http://lists.freedesktop.org/mailman/listinfo/xdg
> > >
>
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: Preference Opening Specification

[Corentin Noël]

Le 16 janv. 2016 12:53 AM, "Mattias Andrée" <maand...@member.fsf.org> a
écrit :
>
> Why would this be useful? And what about when none of
> these are implemented, would that be a problem?

It's then the same problem as clicking on an URL when you don't have any
web browser. Nothing will happen, your users will complain as "not
working", but it the same if you hardcode things for unity-control-center
and you only have gnome-control-center installed.

>
> On Sat, 16 Jan 2016 00:28:37 +0100
> Corentin Noël <coren...@elementaryos.org> wrote:
>
> > Hi everyone,
> > Many desktop environments have their own System Settings
> > applications, but there is no clear way for developers to
> > call settings from within their applications  without
> > resorting to hardcoding in commands for each and every
> > Settings app. I propose a new specification that similar
> > to other scheme handling in Desktop files, through a new
> > settings:// URI. With this, developers could call on
> > Settings applications, without resorting to hardcoding,
> > provided a desktop environment supports it. For example,
> > an application calling settings://bluetooth would open
> > Bluetooth settings for a given desktop environment.
> >
> > Here is the specification I propose:
> >
https://docs.google.com/document/d/1N0uqNtVXEFn3cLgNMeN75mP_dpMpCco-7uw5PKow-_Q/edit?usp=sharing
> >
> > I'm of course open to changes and feedbacks,
> > Corentin Noël
> > elementary OS Developer
>
>
> ___
> xdg mailing list
> xdg@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xdg
>
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Preference Opening Specification

[Corentin Noël]

Hi everyone,
Many desktop environments have their own System Settings applications, 
but there is no clear way for developers to call settings from within 
their applications  without resorting to hardcoding in commands for 
each and every Settings app.
I propose a new specification that similar to other scheme handling in 
Desktop files, through a new settings:// URI. With this, developers 
could call on Settings applications, without resorting to hardcoding, 
provided a desktop environment supports it. For example, an application 
calling settings://bluetooth would open Bluetooth settings for a given 
desktop environment.


Here is the specification I propose:
https://docs.google.com/document/d/1N0uqNtVXEFn3cLgNMeN75mP_dpMpCco-7uw5PKow-_Q/edit?usp=sharing

I'm of course open to changes and feedbacks,
Corentin Noël
elementary OS Developer
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Re: Preference Opening Specification

[Corentin Noël]

Le 16 janv. 2016 12:36 AM, "Jasper St. Pierre" <jstpie...@mecheye.net> a
écrit :
>
> I'm not against this, but what's the goal for applications to be able
> to launch the System Settings? Some entries like "Privacy" seem fairly
> opaque -- anything in there I could also imagine being in other places
> in other DEs. If the goal is to be able to direct users to a certain
> setting, these categories seem too coarse for anything out of the
> ordinary.

That's where the freedesktop group is useful, let me know the categories
that would make sense in most distributions.
About the use, not just apps but other parts of the desktop environment
would be using it too.

>
> If I have a screen sharing app, and I want to direct users to be able
> to enable it, is that under "Privacy", "Security", or "Network
> Sharing"? What about file sharing?

Well you're already covering the corner cases, but I think it's the same
issue as asking how as a user would I find X setting in the setting app. So
here I have no answer for you yet as I've never seen screen sharing on the
desktop.

>
> On Fri, Jan 15, 2016 at 3:28 PM, Corentin Noël
> <coren...@elementaryos.org> wrote:
> > Hi everyone,
> > Many desktop environments have their own System Settings applications,
but
> > there is no clear way for developers to call settings from within their
> > applications  without resorting to hardcoding in commands for each and
every
> > Settings app.
> > I propose a new specification that similar to other scheme handling in
> > Desktop files, through a new settings:// URI. With this, developers
could
> > call on Settings applications, without resorting to hardcoding,
provided a
> > desktop environment supports it. For example, an application calling
> > settings://bluetooth would open Bluetooth settings for a given desktop
> > environment.
> >
> > Here is the specification I propose:
> >
https://docs.google.com/document/d/1N0uqNtVXEFn3cLgNMeN75mP_dpMpCco-7uw5PKow-_Q/edit?usp=sharing
> >
> > I'm of course open to changes and feedbacks,
> > Corentin Noël
> > elementary OS Developer
> >
> > ___
> > xdg mailing list
> > xdg@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/xdg
> >
>
>
>
> --
>   Jasper
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg