FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Ubuntu > Ubuntu Mobile and Embedded

 
 
LinkBack Thread Tools
 
Old 11-29-2007, 04:36 PM
"Spencer, Bob"
 
Default Apps Criteria -- 3 levels

Title: Apps Criteria -- 3 levels









Suggestions welcome.* There are no planned acceptance tests associated with these.* It is just a rought categorization to help guide developers.



Bob




<<MID Application Criteria_UME.pdf>>




--
Ubuntu-mobile mailing list
Ubuntu-mobile@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile
 
Old 11-29-2007, 05:15 PM
Loc Minier
 
Default Apps Criteria -- 3 levels

Thanks for your lists!

> 1 Bronze Level (minimum to be linked from moblin.org)
> 1.1 Build and Install
> 1 Compiles cleanly
> 2 Buildable in target environment with autogen, configure, make
> 4 Contains installable .deb package(s)

=> Replace with "Builds Debian Policy compliants packages with no
more build-deps than those of the dev SDK".

> 3 Shows up in UI
> 6 Screenshot available

So only graphical apps?

> 5 Installs cleanly in target environment

"Packages install cleanly in..." perhaps

> 1.2 Hildon Application (Bronze)
> 3 For applications that can be built for Mobile and non-Mobile environments, check for
> LPIA architecture in configure and define USE_HILDON flag to use in code for
> Hildon version. <example>

I think you should move this to 1.1 and require packages to build under
the lpia architecture.

I don't think you should recommend checking for lpia to enable
USE_HILDON. You should just rely on the package build rules to do the
right thing.

I would only keep "C source code specific to the Hildon libs should be
protected by #ifdef USE_HILDON which should be defined by the build
system".

> 4 Register with libosso. <example>
> 5 Create DBUS service file <example>

Mandatory?

> 6 Singleton behavior. Registered with libosso for startup. Correctly brings its window
> to the top when requested. <example>

Having a window is mandatory?

> 7 Have correct .desktop file format and contents <example>

Might want to refer to the freedesktop standard + required fields.

> 2 UI works on 800x480 and 1024x600
> 2.a Can read text on both resolutions <suggested font sizes>

Apps should use the system's default font size, no?

> 2 Silver Level
> 2 Supports the following DBUS / OSSO messages: <list> <example>

What for??

> 4 Recommended
> - Consistent mechanism to notify apps to go Full Screen and non-full screen
> - Xephyr supported by apps

What do you mean with these two?

Thanks!
--
Loc Minier

--
Ubuntu-mobile mailing list
Ubuntu-mobile@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile
 
Old 11-29-2007, 10:17 PM
"Spencer, Bob"
 
Default Apps Criteria -- 3 levels

A good review, thanks.

Loc Minier wrote:
> Thanks for your lists!
>
>> 1 Bronze Level (minimum to be linked from moblin.org)
>> 1.1 Build and Install
>> 1 Compiles cleanly
>> 2 Buildable in target environment with autogen, configure, make
>> 4 Contains installable .deb package(s)
>
> => Replace with "Builds Debian Policy compliants packages with no
> more build-deps than those of the dev SDK".

Good.

>
>> 3 Shows up in UI
>> 6 Screenshot available
>
> So only graphical apps?

I can clarify "when applicable"

>
>> 5 Installs cleanly in target environment
>
> "Packages install cleanly in..." perhaps
>
>> 1.2 Hildon Application (Bronze)
>> 3 For applications that can be built for Mobile and non-Mobile
>> environments, check for LPIA architecture in configure and
>> define USE_HILDON flag to use in code for Hildon version.
>> <example>

I kind of want to group Hildon-related changes in one area, even though it is a build topic.

>
> I think you should move this to 1.1 and require packages to build
> under the lpia architecture.

Regardless of grouping, I should require LPIA compat.

>
> I don't think you should recommend checking for lpia to enable
> USE_HILDON. You should just rely on the package build rules to do
> the right thing.
>
> I would only keep "C source code specific to the Hildon libs should
> be protected by #ifdef USE_HILDON which should be defined by the
> build system".
>

OK, I like that.

>> 4 Register with libosso. <example>
>> 5 Create DBUS service file <example>
>
> Mandatory?

For UI apps it is in order to get the application to behave as a singleton.

>
>> 6 Singleton behavior. Registered with libosso for startup.
>> Correctly brings its window to the top when requested.
>> <example>
>
> Having a window is mandatory?

I'll add "when appropriate"

>
>> 7 Have correct .desktop file format and contents <example>
>
> Might want to refer to the freedesktop standard + required fields.

Right.. Actually Hildon is not freedesktop compliant (I don't think). I need to follow up on exactly where they are or aren't and clarify. Thanks for the reminder.

>
>> 2 UI works on 800x480 and 1024x600
>> 2.a Can read text on both resolutions <suggested font
>> sizes>
>
> Apps should use the system's default font size, no?

True. And "readable" is subjective anyway. I can't read the Sony UX screen at default resolution. Perhaps a better wording would be: "Text is displayed at system default size and is not inappropriately or unexpectedly cut off"

>
>> 2 Silver Level
>> 2 Supports the following DBUS / OSSO messages: <list> <example>
>
> What for??

I was thinking of examples like the browser should support notification to load URL. This comes from an interested App via DBUS msg. We need to look at all the useful dbus / osso messages and make this clearer or remove.

>
>> 4 Recommended
>> - Consistent mechanism to notify apps to go Full Screen
>> and non-full screen

An example of a dbus message. I believe all apps should listen for the same message to go to/from full screen mode.

>> - Xephyr supported by apps

Ability to run the application in Xephyr on the desktop.

>
> What do you mean with these two?
>
> Thanks!
> --
> Loc Minier

Bob

--
Ubuntu-mobile mailing list
Ubuntu-mobile@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile
 
Old 11-30-2007, 07:24 AM
Loc Minier
 
Default Apps Criteria -- 3 levels

On Thu, Nov 29, 2007, Spencer, Bob wrote:
> >> 4 Register with libosso. <example>
> >> 5 Create DBUS service file <example>
> > Mandatory?
> For UI apps it is in order to get the application to behave as a singleton.

But then you already require them to behave as a singleton, so perhaps
you don't need to force them to do it via libosso + DBus, even if these
will be used in practical implementations and in sample code.

> >> 7 Have correct .desktop file format and contents <example>
> >
> > Might want to refer to the freedesktop standard + required fields.
>
> Right.. Actually Hildon is not freedesktop compliant (I don't think).
> I need to follow up on exactly where they are or aren't and clarify.

Hildon might not follow all FreeDesktop standards, but the format of
the .desktop file itself it respected (I think); X-Maemo is used for
custom fields etc.

> >> 2 UI works on 800x480 and 1024x600
> >> 2.a Can read text on both resolutions <suggested font
> >> sizes>
> >
> > Apps should use the system's default font size, no?
>
> True. And "readable" is subjective anyway. I can't read the Sony UX
> screen at default resolution. Perhaps a better wording would be:
> "Text is displayed at system default size and is not inappropriately
> or unexpectedly cut off"

Hmm ok; I'm not sure it should be too strict; we want to allow zoom in
/ zoom out when it's needed, we want to allow big on screen text for
e.g. the title of the currently playing song, we want to allow smaller
tooltips for contextual help. It's a bit hard to specify how all apps
should behave WRT text size. It's hard not to end up writing "Please
don't do things which look ugly or unreadable". :-/

> >> 2 Silver Level
> >> 2 Supports the following DBUS / OSSO messages: <list> <example>
> >
> > What for??
>
> I was thinking of examples like the browser should support
> notification to load URL. This comes from an interested App via DBUS
> msg. We need to look at all the useful dbus / osso messages and make
> this clearer or remove.


Ok; then it's going to be conditional, probably optional: "If you want
to handle opening of URLs then you need to use this DBus service name".
But perhaps this is more developer documentation than an application
criteria?

Thanks for your clarifications,
--
Loc Minier

--
Ubuntu-mobile mailing list
Ubuntu-mobile@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mobile
 

Thread Tools




All times are GMT. The time now is 07:19 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org