Daniele Ricci | 15 Oct 21:33 2010
Picon

[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
Attachment (specs.diff): text/x-diff, 35 KiB
_______________________________________________
Smartphones-userland mailing list
Smartphones-userland <at> linuxtogo.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland
David Lanzendoerfer | 15 Oct 23:09 2010
Picon

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
Michael 'Mickey' Lauer | 16 Oct 17:47 2010
Picon

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:
Daniele Ricci | 16 Oct 17:52 2010
Picon

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
Attachment (specs.diff): text/x-diff, 37 KiB
_______________________________________________
Smartphones-userland mailing list
Smartphones-userland <at> linuxtogo.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland
Daniele Ricci | 17 Oct 03:42 2010
Picon

[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
Daniele Ricci | 17 Oct 12:34 2010
Picon

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
Simon Busch | 17 Oct 22:55 2010
Picon

FSO application management

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
common place) and tries to get one which implements the requested
interface. If there is more than one fsoappd looks in a priority list
(Continue reading)

Arigead | 18 Oct 13:24 2010
Picon

Re: FSO application management

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
> common place) and tries to get one which implements the requested
(Continue reading)

Daniele Ricci | 18 Oct 13:33 2010
Picon

Re: FSO application management

On Sun, Oct 17, 2010 at 22:55, Simon Busch <morphis@...> 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.
>

Please reply all because I have digest mode

thanks,
--

-- 
daniele_athome
Al Johnson | 18 Oct 13:40 2010
Picon

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
(Continue reading)


Gmane