Optional instructions for using a real meego Device

Optional instructions for using a real meego Device

If you have a real meego device available, it's also possible to run and debug your application on it using QT creator.

Prepare the device

The device requires some configuration and extra packages before you can deploy from QT creator to it. install them from the command line as follows:

1. Deployment from QT creator to a real device uses SSH for file copying, so you need to install OpenSSH server on the netbook:

   sudo zypper install openssh-server

   To start it manually (you'll need to do this just after you 've installed it, otherwise it won' t be available until you reboot ):

   sudo /etc/init.d/sshd start

   To add it to the init sequence so it starts at boot time:

   sudo chkconfig --add sshd

2. If you want to debug applications remotely, you need to installGdbserverOn the netbook:

   sudo zypper install gdb-gdbserver

Run the application on the device

In QT creator (still running from the chroot ):

1. With a project selected, click onProjectsIcon to show the project configuration tabs.
2. SelectRun settingsTab.
3. Click onAddDrop-down and selectTestapp on meego Device(TestappWill be set to the name you gave your project ).
4. Click onManage device configurationsLink to displayMeego device configurationsDialog.
5. Click onAddButton (top-right) and complete the fields so they resemble the screenshot below:
   
   You'll need to setHost NameTo the IP address or domain name of the netbook, and enterUser NameAndPasswordYou used when you set up the netbook. The other options can be left at their ults.
6. Click onTestButton to check the connection. If it's configured correctly, you shoshould see a message like the one in the screenshot above ("Device Configuration successful ").
7. Click onOKTo save your changes. This returns you toRun settingsTab.
8. Select the newMeego netbookOption fromDevice ConfigurationDrop-down.

Once you 've completed this, you should be able to deploy and run the application on the netbook:

1. At the bottom-left of the QT creator window is a panel for selecting the build and run environments:
   
   Click on the computer monitor icon, then use the arrows to selectTestapp on meego DeviceFromRunDrop-down.BuildDrop-down can be leftDebug.
2. Click on the Green Arrow (the normal run arrow) to deploy the application and run it. this copies the application binary to the home folder of the user you specified in the SSH settings and runs it.
   If you can't see the application, it may be because it hasn't been given focus. You can use the zones icon in the toolbar to show the running application and select it.

Here's an example of what the application looks like running on a netbook:

 

Debug the application on the device

This works almost the same on a remote device as it does inside the simulator.

1. Configure the remote device as fig.
2. In QT creator, click onTargetSettings (bottom left with a monitor icon). ensure you haveBuildSetDebugAndRunSetTestapp on meego Device(The remote device ).
3. Click on the Green Arrow overlaid with a bug to start the application remotely in debug mode.

If you used the same code as abve, try clicking onClick meButton in the application (running on the netbook). The application shoshould pause at the breakpoint; and In QT creator,MessageVariable shoshould then be visible inLocals and watchersTab, set to "I have been well and truly clicked". (No screenshot this time, as QT creator looks the same as it does for local debugging .)

Retrieved from "Response

(3) Packaging meego applications

To distribute an application to a meego device, it shoshould be packaged using the RPM format. (It is possible to manually copy binaries to a device and get them to run, but this is not recommended, as there is no way to specify dependencies .) an RPM file is a binary file consisting:

• A signature to verify the origin and integrity of the package
• Metadata (name, version, architecture, authors etc .)
• An archive of files to be installed on the destination filesystem (e.g. executables, images, Documentation)

This packaging/tutorial will give you a whole story to create a RPM package from a QT project.

References for packaging:

• Build System
• Packaging
• Packaging/guidelines
• Packaging/Deb conversion example

 

Meego application developer cookbook

• Porting linux applications to meego
• See meego netbook and GTK

Meego platform developer tutorials

• Creating meego Disk Images

  See:

  • ARM/creating_arm_image_using_meego_image_creator
  • Image Creation
  • Image creation for beginners

 

 

Developer documentation guidelines

• SDK documentation guidelines

A set of documentation principles describing the documentation process and the different licenses for different documents.

Contents [Hide] 1.1 picking up documentation tasks 1 developer guide process 2 content categorization 3 licensing

 

Developer guide process

The intention behind the developer guide is to sign-post the most-accurate information available to meego developers. as such, it shoshould not be added to in an ad hoc fashion or subjected to massive restructurings without community involvement. usual meego SDK community channels can be used to discuss changes.

If you notice an improvement which cocould be made to the developer guide, you have a few options:

• Fix it yourself (if it's already in the Guide); let the meego-SDK mailing list know if it's anything significant (e.g. you removed or added a large chunk of text; fixing typos is OK and you don't need to tell anyone etc .)
• Write a new page yourself and log a request to have it added to the developer guide; include the title of the page in the title of the bug
• Log an enhancement request for a page to be added to the developer guide if you can't or won't write it yourself; be as specific as you can about the content you need CT to see in it
• Log a bug if you spot a problem on a page (something wrong, something missing) and can't or won't fix it yourself; requests to remove a page, move a page out of the Guide etc. can also be made this way

Bugs and enhancement requests are logged on http://bugs.meego.com/, insideDocumentationProduct,SDK docsComponent.

• Create a request for documentation
• Current open SDK docs bugs

Documentation issues shoshould also be attached to the appropriate version of the developer Guide (corresponding to meego versions ): check the version of the developer guide you're viewing and select the appropriate version when making your request.

 

Picking up documentation tasks

Documentation bugs can be taken on by any meego SDK community member. Please review the SDK tutorial content page when authoring new content.

Bugs are closed at the discretion of the meego SDK community; for example:

• A request for a new page can be closed when a page is in place which satisifies the requirements specified in the bug.
• A request to include a new page in the developer guide can be closed when the page is linked from the developer guide table of contents.

 

Content Categorization

See developer guide content organization for some suggestions about how to categorise developer guide pages.

 

Licensing

Creative Commons Attribution 3.0 is the licence for the Wiki; Documentation uses the same licence

Retrieved from "http://wiki.meego.com/sdk_documentation_guidelines"

• Technical documentation style guide
• Some tips for writing meego technical documentation. these are based on my personal experience (as a technical writer ). the intended audience is anyone wanting to write documentation covering how to develop for meego, e.g. someone writing tutorials or recipes for application developers or platform developers, someone writing a course on meego development. it does not cover:
  • The right structure for documentation: It's more about general principles of Technical Writing
  • Wiki mark-up to use: It doesn't cover whether to use bold or italics for user interface element names, when to use fixed-width fonts, or any of that stuff

  Note that this is a work in progress, so shocould improve over time.

  Contents [Hide] 1 start from a known state 2 tell a story 3 Write conversationally and informally 4 Use Task-based structures 5 explain too much, rather than too little 6 compare the new with the familiar 7 provide useful, relevant, meaningful examples 8 leave a gap between drafts

  Start from a known state

  You shoshould explain why the document exists:

  • What it will show you to do (build a PDF viewer, understand how many works)
  • The intended audience (Beginner, C programmer, Web programmer)
    See audience for meego developer documentation for some examples of the range of meego audiences
  • The vertical it's applicable for (will it only work for netbooks ?)

  Also explain any assumptions you're making about the reader and their context. For example:

  • A "Getting Started" tutorial shoshould start from a clean install of an operating system.
  • A tutorial about "Advanced widget use" might build from a State reached in a previous tutorial. but you need to make that explicit: Say, "you should do tutorial X before you start this tutorial ".
  • A Programming Tutorial shoshould either tell the reader what they need to install, or tell them where to find that out, or tell them they shoshould go and work it out for themselves.

  You can be explicit about where a meego SDK guide belongs by categorising it: I put some suggestions about how to do this in developer guide content organization.

  Tell a story

  Start with small pieces and join them into a significant whole: you're taking the reader on a journey where they'll hopefully be a different (preferably better) person by the end.

  Make sure there's a progression (from them knowing "little or nothing" to them knowing "something ").

  Only add a small amount at each step, and make sure what you add at each step is a coherent unit: for example, implement a single feature or explain a single concept. (though working out how big a "unit" shoshould be is tricky in itself .)

  You cocould show a screenshot of the finished application and then say "Here's how we got here ". but don't start with a big pile of code and try to pick it apart and explain it. that's difficult for someone to grasp. if you're writing about building a full application, add the features in a logical order the way a developer might do it, e.g.

  1. Set up the project
  2. Create the basic skeleton of the application
  3. Add some read-only/inactive Widgets
  4. Add behaviour to the widgets but Stub Out interactions with other parts of the environment
  5. Add interactions with the real environment (e.g. Fetch data from the network, talk to device APIs)

  Make sure there is a reason for adding each new feature. Adding spurious, unrealistic, disjointed (but maybe cool) features doesn' t make a good story.

  You coshould also use "characters" and put them in scenarios which mirror development in the real world. For example:

  • A developer is being asked by a customer to add new features to an application.
  • A tester and developer are working together on testing an application.
  • A developer is writing an application for his girlfriend.

  The O 'Reilly head first books are a good example of how to do this well

  Write conversationally and informally

  While writing, imagine you're explaining to a peer, collegou, family member or friend (depending on the type of audience you're writing ). this makes your writing more natural and help you get the flow right: it's easier to track a conversation in your head than it is to track an abstract explanation.

  Use "we" and "you"; Address the reader directly. Compare the following two pieces of text and see which one reads better:

  The Button widget can be added to a layout usingAdd_actorMethod.

  You can add a Button widget to a layout usingAdd_actorMethod.

  (I 'd argue the second reads better .)

  Use Task-based structures

  Explain concepts by getting the reader to carry out a task related to them. rather than explaining about something in abstract, show the reader what "impact" completing that task will have on them: what effect it has on the application, or on their programming skill, or on the world around them (more generally ).

  For example:

  • "Refreshing the application" rather than "application configuration"
  • "Writing a depth-first parser" rather than "depth-first parser Construction"
  • "Adding a label widget" rather than "label widgets"

  This means someone knows what they're going to achieve by the end of the section, and has an idea of the scope of the information in that section.

  Explain too much, rather than too little

  Try to make the right assumptions about the reader, what they know, and the context they're working in. having a fictional conversation with someone real helps with this, as you can use what you know about that person to decide what to explain. for example:

  • If I'm writing a beginner Programming Tutorial, I imagine I'm talking to one of my friends or family, who understands computers (they know what a menu is, how to select things, understandOKAndCancelButtons), but not so much about programming.
  • If I'm writing about an advanced programming topic, I imagine I'm talking to one of my co-workers. I have a decent idea of their field of reference: they all know what the Model View Controller pattern is, understand what a method signature is, be familiar with how network protocols work. at the same time, I try to be aware of what I know which they might not, e.g. "I 've probably done more web programming than they have, so they may not be so familiar with CSS and HTML syntax ".

  Each time you feel the need to explain something, decide whether that person wowould already know it. If you're not sure, explain it.

  Compare the new with the familiar

  This relates to the previous section: If you're explaining something new, compare it to something the reader might already know about. some of the time, if it's new to you, this can help you understand it, too.

  As an example, a few months back I helped write a page about records. there was a section about signals, but I wasn't really getting how to use them, and felt this wowould hinder other people understanding it. so I tried to find an explanation of signals which related to the real world, and came up with this:

  Signals provide a way for objects to define y other objects about events which happen to them: for example, a door interface might provide a signal to other objects when it is opened, perhaps called door-opened. (a nearby doorman object might listen out for door-opened signals, so it knows when people come into the building .)

  Provide useful, relevant, meaningful examples

  Examples shoshould be:

  • Self-contained (as far as possible): in the case of code examples, you should be able to compile it without needing loads of tools, or use them straight away inside an IDE like QT creator. if this isn't possible, they shoshould include an install file (or at least readme comments) explaining how to build them, distributed with the code (see abve ).
  • Meaningful: They shoshould provide a solution for some possible issue. for example, if you're explaining how to use widgets, write an application which demonstrates how to use them in context, e.g. an address book.

  Specifically, code examples shoshould be:

  • Encoded in the meego code examples repository/wiki (once we 've decided on the best format for this ). this makes it easier for other people to get at them, fix them, extend and improve them.
  • Available under a liberal open source licence. I suggest BSD.

  Some open problems:

  • How to include source code in guides. I tend to cut and paste as I go, but maybe there's a better way.

  Also try to stay focused on the topic. this sounds obvious, but it's sometimes difficult to resist "showing off ". just because the history of compilers is very interesting, it doesn' t mean you shoshould cover it in a tutorial about writing desktop applications.

  Leave a gap between drafts

  Write a first draft, then leave it alone for a few hours (preferably 24 ).

  Then go back to it and read it over from start to finish, correcting as you go. because you 've had a break from what you 've ve written, you'll be able to look more objectively at it, and be able to spot errors or places where the "flow" isn' t right.

  Don't be afraid to restructure. Look for sections you can reduce in size or remove.

  Retrieved from "http://wiki.meego.com/technical_documentation_style_guide"