[specs] Request to modify XML files

Greetings,
recently I wrote a C code generator that can generate GLib client code
for FSO specs. But it requires some little modifications to the xml
files to be able to generate everything well.

- add a <proxy> tag to any interface in order to generate a correct
dbus_connect() function
- add "interface" attribute to any enumeration or struct in order to
place them in the correct header file
- add "prefix" attribute to any <fso:errordomain> tag in order to
generate correct #define for error constants

The <proxy> tag can create problems with dbus-binding-tool, actually i
remove the proxy tag from my generator before calling
dbus-binding-tool. That tag might be prefix with "fso:" so
dbus-binding-tool will not complain about it.

I'm attaching a patch which describes the modifications i'm using now.
Thank you,
--

-- 
daniele_athome

_______________________________________________
Smartphones-userland mailing list
Smartphones-userland <at> linuxtogo.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland

Re: [specs] Request to modify XML files

> Greetings,
> recently I wrote a C code generator that can generate GLib client code
> for FSO specs. But it requires some little modifications to the xml
> files to be able to generate everything well.
Great!
This might revolutionize the development.
Because we can write very easily a frontend (e.g. in java or qt)
for drawing float diagrams and export them into XML!
Nice job. Well done.

regards
	leviathan

Re: [specs] Request to modify XML files

Hi,

before I comment on your proposal, could you create the diff
in the other direction, i.e. FSO-old -> FSO-new, instead of
the other way round? :)

Cheers,

--

-- 
:M:

Re: [specs] Request to modify XML files

On Fri, Oct 15, 2010 at 21:33, Daniele Ricci <daniele.athome <at> gmail.com> wrote:
> Greetings,

Inverted patch.

--

-- 
daniele_athome

_______________________________________________
Smartphones-userland mailing list
Smartphones-userland <at> linuxtogo.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland

[specs] proposal: new org.freesmartphone.Notifications

Greetings,
i propose to drop the current org.freesmartphone.Notifications
interface (i think Alarm should go into a different interface) and
replace it with something like the one i've attached.

This new spec has support for typed notifications. Methods are
documented within comments in the XML file.
Hoping that it can be useful and it would be approved   i've
already started my server-side implementation on my panel app.

Bye,
--

-- 
daniele_athome

_______________________________________________
Smartphones-userland mailing list
Smartphones-userland <at> linuxtogo.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland

Re: [specs] proposal: new org.freesmartphone.Notifications

On Sun, Oct 17, 2010 at 03:42, Daniele Ricci <daniele.athome <at> gmail.com> wrote:
> Greetings,
> i propose to drop the current org.freesmartphone.Notifications
> interface (i think Alarm should go into a different interface) and
> replace it with something like the one i've attached.
>
> This new spec has support for typed notifications. Methods are
> documented within comments in the XML file.
> Hoping that it can be useful and it would be approved   i've
> already started my server-side implementation on my panel app.
>
> Bye,
> --
> daniele_athome
>

Added Update() method for updating an existant notification.

--

-- 
daniele_athome

_______________________________________________
Smartphones-userland mailing list
Smartphones-userland <at> linuxtogo.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland

Re: [Shr-Devel] FSO application management

On Monday 18 October 2010, Arigead wrote:
> Simon Busch wrote:
> > Heyho,
> > 
> > as we talked already with some people about application management in
> > FSO we should now start discussing this in the public and define some
> > spec with all features we want in the end.
> > 
> > I will start here with explaining my ideas. First of all we need a
> > daemon doing all the application management. I think we should call it
> > simply fsoappd. The daemon manages all things we have in mind with
> > applications (btw. we should define what an application exactly is!).
> > There is the lifecycle management of applications. An application has
> > always a state which identifies the application as running, inactive or
> > whatever. To come from one state into another one there are possible
> > events (pause, hide, destroy, ...) which let the application change its
> > state (for example, the wm choose another app to become visible, so the
> > current app will get paused). We should define some rules an common
> > agreements all application should share so we can keep our application
> > management simple.
> > 
> > Furthermore we need a way applications can communicate between each
> > other. My idea here is to define common interfaces an application can
> > implement. For example the org.freesmartphone.Dialer interface. The
> > interface describes which DBus methods/signals should be implemented by
> > the app. If one app needs the dialer, it requests the dialer via the
> > fsoappd by a method called Request("org.freesmartphone.Dialer"). Each
> > application has a file appinfo.config file where it defines which
> > interfaces it implements. The fsoappd now searches through all
> > appinfo.config files (they should be stored by each application in one

Re: [Shr-Devel] FSO application management

Al Johnson wrote:
> On Monday 18 October 2010, Arigead wrote:
>> Simon Busch wrote:
>>> Heyho,
>>>
>>> as we talked already with some people about application management in
>>> FSO we should now start discussing this in the public and define some
>>> spec with all features we want in the end.
>>>
>>> I will start here with explaining my ideas. First of all we need a
>>> daemon doing all the application management. I think we should call it
>>> simply fsoappd. The daemon manages all things we have in mind with
>>> applications (btw. we should define what an application exactly is!).
>>> There is the lifecycle management of applications. An application has
>>> always a state which identifies the application as running, inactive or
>>> whatever. To come from one state into another one there are possible
>>> events (pause, hide, destroy, ...) which let the application change its
>>> state (for example, the wm choose another app to become visible, so the
>>> current app will get paused). We should define some rules an common
>>> agreements all application should share so we can keep our application
>>> management simple.
>>>
>>> Furthermore we need a way applications can communicate between each
>>> other. My idea here is to define common interfaces an application can
>>> implement. For example the org.freesmartphone.Dialer interface. The
>>> interface describes which DBus methods/signals should be implemented by
>>> the app. If one app needs the dialer, it requests the dialer via the
>>> fsoappd by a method called Request("org.freesmartphone.Dialer"). Each
>>> application has a file appinfo.config file where it defines which
>>> interfaces it implements. The fsoappd now searches through all

Re: [Shr-Devel] FSO application management

Al Johnson wrote:
> On Monday 18 October 2010, Arigead wrote:
>> Simon Busch wrote:
>>> Heyho,
>>>
>>> as we talked already with some people about application management in
>>> FSO we should now start discussing this in the public and define some
>>> spec with all features we want in the end.
>>>
>>> I will start here with explaining my ideas. First of all we need a
>>> daemon doing all the application management. I think we should call it
>>> simply fsoappd. The daemon manages all things we have in mind with
>>> applications (btw. we should define what an application exactly is!).
>>> There is the lifecycle management of applications. An application has
>>> always a state which identifies the application as running, inactive or
>>> whatever. To come from one state into another one there are possible
>>> events (pause, hide, destroy, ...) which let the application change its
>>> state (for example, the wm choose another app to become visible, so the
>>> current app will get paused). We should define some rules an common
>>> agreements all application should share so we can keep our application
>>> management simple.
>>>
>>> Furthermore we need a way applications can communicate between each
>>> other. My idea here is to define common interfaces an application can
>>> implement. For example the org.freesmartphone.Dialer interface. The
>>> interface describes which DBus methods/signals should be implemented by
>>> the app. If one app needs the dialer, it requests the dialer via the
>>> fsoappd by a method called Request("org.freesmartphone.Dialer"). Each
>>> application has a file appinfo.config file where it defines which
>>> interfaces it implements. The fsoappd now searches through all

Re: [specs] proposal: new org.freesmartphone.Notifications

Am Sonntag, den 17.10.2010, 03:42 +0200 schrieb Daniele Ricci:
> Greetings,
> i propose to drop the current org.freesmartphone.Notifications
> interface (i think Alarm should go into a different interface) and
> replace it with something like the one i've attached.
> 
> This new spec has support for typed notifications. Methods are
> documented within comments in the XML file.
> Hoping that it can be useful and it would be approved   i've
> already started my server-side implementation on my panel app.
> 
> Bye,

Moin,

the Notification interface is not supposed to be the same as
org.freedesktop.Notification. It's a "signal" registered with [0].
Maybe we should consider to intergrate the Ayatana Project[1] into
fso/the wm.

Regards, Frederik

[0]
http://git.freesmartphone.org/?p=specs.git;a=blob_plain;f=html/org.freesmartphone.Time.Alarm.html;hb=HEAD
[1] https://launchpad.net/ayatana
> _______________________________________________
> Smartphones-userland mailing list
> Smartphones-userland <at> linuxtogo.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland