Recently in SHR applications Category

Hi there!

I am not having much time lately to help and compile development related information, but fortunately there has been people writing news in the wiki about last updates and fixes. Let's see some of them:

General:

• Now Idle Screen detects the screen size and scales nicely to smaller screens (HVGA) like the Palm Pre (done by Slyon).
• accelges is now working again (by elisa42, and GNUtoo|Laptop).
• A bug in shr-settings has been fixed. After changing the timezone the new one will be displayed right away. (thx to peter).
• emtooth2 should be working better now as I fixed a long-standing bug which messed up the devices list/hash table when a "disappeared" signal arrived from bluez.

Phoneui: Contacts list now supports multiple selection of contacts (by Rui)

• press and hold for a while to do more actions on the selections (edit, unselect, delete)
• when you have only one contact selected, you can call, send sms, edit, unselect and delete
• when you have more than one contact selected, you can unselect all or delete (in the future, you will be able to send sms as well).

HTC Dream: Some more improvements by GNUtoo.

• Improved gtkrc's font size
• Improved illume environment's finger size
• removal of the useless udev in the newer images since the htcdream already used devtmpfs

Nokia N900:

• PaulFerster and GNUtoo finally got modem forwarding working!
  

Upgrading via opkg upgrade should fix this automatically, Thanks Martin Jansa for putting in a fix.

If that does not work, check this manually:

Older versions of fsodeviced left a stray directory around. Delete the directory
/etc/freesmartphone/conf/openmoko_gta/alsa-default
and make that a symlink to
/etc/freesmartphone/conf/openmoko_gta/alsa-2.6.29

Thanks everyone for finding that out.

Why do we want to do that?
One annoying thing while developing applications for SHR is the time consuming cycle of: hacking - building with OE - installing on the device - testing. The UI itself could be developed natively on the desktop too, but as lots of stuff depends on the actual hardware (eg. phone calls) that does not cover the whole story.

What can we do about that?
Now, we have a solution :-) The other day an interesting application was added to OpenEmbedded (thanks mickeyl): dbus-daemon-proxy. So, what is that? If you start dbus-daemon-proxy on your phone it will proxy all dbus methods and signals from your phone over the network to you desktop. This means you can have the hardware dependent stuff like fsogsmd running on the phone and stuff like phoneuid running on your desktop and it will just work.

So, what do you need to do that?
1) you need a current EFL stack with elementary. Current means you have to build it yourself from Enlightenment SVN. I personally use the get_e.sh script from raster (find it here: get_e.sh). But there are others out there too. NOTE: get_e.sh does not install elementary itself. You have to do that manually after get_e.sh finished installing all the other stuff.

2) you have to install dbus-daemon-proxy on your phone. It is already in the SHR-unstable feed, so if you run SHR-unstable (which is somehow important if you want to develop the SHR phone stack ;), then just opkg install dbus-proxy-daemon.

3) install the SHR phone stack (and all of its dependencies) on your desktop. To make life easy for you I created a script which does that (setup-shr-build-env.sh). It will install all needed stuff to your home directory. If you don't already have LD_LIBRARY_PATH set to contain $HOME/lib you have to add it.

4) stop phoneuid on your phone. Easiest way is to just execute 'killall phoneuid'.

5) start dbus-daemon proxy on your phone. Note: you need one instance for every program connecting to it. I'm using one for phoneuid, one for communication with phoneuid (eg. to start messages app) and one for some debugging tool like d-feet or mdbus2. Create something like the following script to start it on three different ports:

#!/bin/sh
dbus-daemon-proxy --system --port 8080 &
dbus-daemon-proxy --system --port 8081 &
dbus-daemon-proxy --system --port 8082 &

make it executable and start it.

6) start phoneuid on your desktop with the following call:

DBUS_SYSTEM_BUS_ADDRESS=tcp:host=192.168.0.202,port=8080 phoneuid

7) start the messages app with the following call:

DBUS_SYSTEM_BUS_ADDRESS=tcp:host=192.168.0.202,port=8081 phoneui-messages

8) have fun watching your messages pop up on your desktop :-)

Apart from saving a lot of time by not cross-compiling and installing... one big winner is to be able to use some nice gdb GUI to debug the thing.

Hello.
In order to normalize numbers in SHR we use a library called libphone-utils.
This library needs to know the Phone prefixes of the user's country in order to work correctly.
ATM each user sets up his prefixes manually using a config file in /etc/phone_utils.conf (or probably using shr-settings)
We want to make it automatic. Though in order to do that, we need to know, what are your settings? What's working well for you?

So please, add to the following wiki page your country and your settings so we'll be able to use them for automatic settings.

Wiki page: http://wiki.openmoko.org/wiki/Phone_Prefixes

Thanks in advance, the SHR team.

Edit: Disabled commenting due to spam.

As you may have noticed, recently we sent a lot of mails concerning the looks of SHR.
Most of the users don't care about what's running under the hood, though the majority do care about how it looks/behaves.

Therefore we decided to ask the users about all of our graphical and UI design choices before we actually do them,
as this distro is made for YOU.

So what's on the topic:

1. A new SHR logo - we already started the logo contest (for more info: http://wiki.shr-project.org/trac/wiki/LogoContest)
2. A new SHR theme - we already sent a mail about that, though in short, we need a new theme for illume and a default background image, wiki page: http://wiki.shr-project.org/trac/wiki/Illume%20Theme
3. A new phone UI - will be explained in a moment.

As for 1 and 2, things are going ok, we need more user involvement as those will be default soon, but we are getting there and we already have some nice suggestions.

As for the new Phone UI:
This is the most important topic, as this is not only about "looks" it's also about "feel" or usability. We want YOU to help us determine the features and look & feel of the entire phone UI.
Of course we have our own suggestions (which will be presented in a moment), so even if you don't have a suggestion of your own, we'd like to
see what you have to say about our current sketches.

Link to the phoneui page: http://wiki.shr-project.org/trac/wiki/phoneui

These are our design suggestions, please tell us what you think should be done in order to improve them, or just suggest your own, please don't remove parts of the wiki,
and keep the order sane if you add your own suggestions.

Edit: Disabled commenting due to spam.

Hello,

Just wanted you all to know that starting from today, there's is partial Hebrew and Arabic, and full right to left support in SHR.
Ainulindale was kind enough to add a patch I sent him for libevas to the SHR repos, so starting from the next image,
this will be "built-in". (Of course also available as packages).
As for e in general, well the patch has been sent to raster, which will apply it to e when he can.

What's there:
* Full RTL support, RTL renders correctly and not in reverse like it used to.
* Arabic letters are now changed according to context (I tried my best, and gfather said it's fine, though since I don't know Arabic, I didn't do proper QA)
* Hebrew nikkud and Arabic vowels work as well.

What's missing:
* Selection of doesn't work on text that includes RTL.
* Cursor position is off with text that includes RTL.
* Remembering RTL direction over lines.
* Auto alignment option for gui objects.
* No arabic keyboard available (gfather is working on that one).


Now it's time for you to start nationalizing applications and SHR/FSO/Any other distro that uses illume.

Enjoy,
Tom. (TAsn)

Pictures (The keyboard there is just a mock-up for testing, and I know the nikkud is bad, wanted to check "exotic" nikkuds ;] btw, not sure if what I entered in arabic is even a word, since I don't know arabic, though it's the sequence ba ta ra gim):



P.S
Please let me know if you find any bugs/issues.

i ust went through the process of sending an SMS, looking for usability issues. Besides obvious issues (like speed) it's often the small things that make an app comfortable or awkward to use. I think with the previous issues solved, the SMS app would be a little nicer to use. I haven't filed all this thigns as trac issues, i guess quickdev is the one that should be commenting on the feasability of implementing them, as I have never looked at the code in question, nor am I familiar with efl.

SMS Content

• Existing trac issues: Allow empty text messages (with warhing?) and get char counting right.

Inbox

• Selecting a message highlights it yellow, but nothing else is possible. Clicking (or double-clicking) should "Show" it which let's us remove an unneccessary button and is more intuitive.
• "Options" button should indicate that it leads to more options ("Show..." or "Show^")
• Inbox (and many other places) should show contact name rather than number if its in the contacts (need for a function num2name that returns contact name or number?)
  

Define Recipients

• Put "Add contact" into the upper part of the "Add reipients" part for consistency with the dialer app.
• Even better, just invoke the dialer here, which makes for good usability reuse. (most of the time, we'll only need one contact; I'd guess). invoking dialer also allows us to punch in a number immediately without having to press an unneeded "Add number button".
• The "Remove" button is confusing with regard to what gets removed (especially if there is no contact yet). Why not remove it and only show it as a "X" button on the contact line when that contact is selected.
• Also here we should show contact names rather than numbers when replying to a number in my contact list.
• A "recently called" list would be nice (I often send messages to only a handful of people)
• "Continue" button should be called "Send" to make clear that this is the last step an we are actually going to send now.
  

Dialer

• Dialer should have a preferene whether we start it in "number punching" mode, it contact list selection mode or in (a yet to be created) "last calls/messages" mode.

I (spaetz) have been thinking about how to handle screen blanking in SHR. Currently there are 2 overlapping and conflicting mechanisms that blank the screen: The illume power gadget (code) and frameworkd which uses idle timeouts for screen dimming/blanking/suspend.

Illume does a good job, in that it also is able to suspend after blanking in a way that a tap with the stylus will wake up the Moko but not be registered as a click. On the downside, it doesn't know about specific situations, such as when in a phone call (at least that is what I think).

frameworkd knows about that and prevents dimming e.g. while in a call, the only issue with it is that is blanks the screen (it actually only turns the backlight off) but does nothing else. So when you tap on the screen to make it bright again, and you have managed to tap the "Delete" button (or any other widget that does something), then it will execute that action.

Currently both are turned on, which makes for a very confusing situation. Sometimes a tap will hit a button, sometimes not. If you disable screen blanking in SHR-settings, illume will stilll blank the screen, etc. How should this be resolved?

There are 3 issues to be resolved:

1. Currently frameworkd blanking in SHR is broken because of an obsolete rules.yaml files. This needs to be fixed first.
2. frameworkd blanking needs to prevent the first stylus tap to click anything on the screen. This also needs fixing independent of how the rest is handled.
3. illume power settings and frameworkd need to be made compatible. Generally, I like that there are power settings in the illume preferences, but ideally those settings would do the same thing as when setting timeouts in framworkd via shr-settings (or the config file), and ideally they would honor each other (ie modifying frameworkd.conf should show up in the illume power config). Alternatively one could do away with either illume power settings completely or disable the frameworkd timeouts

Usually, when the screen goes blank (isn't there some more energy efficient way of turning the screen off, rather than just disable the backlight by the way?), we should be able to suspend at the same time to save power. Of course there needs to be an easy way to prevent suspend in certain situations (#172, #300), e.g. while logging a GPS track or while in an SSH session via WLAN etc. But I think we  can save some power by applying somewhat more aggressive defaults here.

UPDATE: After talking to raster on IRC I have been convinced that frameworkd works in a hacky manner. Screen blanking needs to go through proper X rather than just turning of the backlight behind X's back. Still, what frameworkd knows is when not to go blank. So the correct solution is to issue xommands (like "xset s activate") to make the screensaver do the right thing (or prevent it from doing so).

Hello! My name is Sebastian (you can meet me on IRC as dos1), and I'm leader of shr-settings project. My goal is to explain you our mission and tell you, how we will do it.

What is SHR Settings?

SHR Settings is a python-elementary based app, which is supposed to be modular. We want you to do your own modules to it, without messing up with core code. Right now, to display some modules it's necessary to change one variable in the launcher app, but dynamic loading of modules is on our TODO list.

Our team is tiny now - it has only three people. I'm a leader, because I started this app and uploaded the first source files to svn on openmoko.opendevice.org (which is our polish community page). After that, yoyo and hiciu started messing with the code. yoyo firstly developed a GSM network selector (which was necessary for him to use his Neo in polish carrier "Play"), and hiciu introduced some pretty object modules system. Now we are working together on shr-settings in SHR git repository.

So, what is there right now?

Thanks to yoyo, we have pretty and finger-usable categories list on main menu.

Thanks to the modular style, SHR Settings can use different launchers. We were thinking about using Toolbar on the top (as in Illume configuration), and about starting only a specific module from the command line (if someone wants to integrate our modules with Illume options).

Because we're using Elementary for UI, shr-settings looks like all Illume and other SHR apps, and it's finger usable. For example, turning on/off radios is done by toggles, like in elementary-alarm app or on the iPhone.

shr-settings is still work in progress. It's still missing some features; it's slow and sometimes implemented badly. Our primary nightmare is slow dbus requests, which are blocking whole UI. We will work on it, I promise :)

Ok, so now I will describe all SHR Settings modules, which are there now.

shr_gsm.py

The GSM module now can turn off/on GSM antenna, display available GSM operator and connect to one of them (useful with roaming), and display modem information.

shr_sim.py

The SIM module can display information about messages and contact books on your SIM card, and clean all entries from them.

(note: part of the SIM module is displayed on the first of GSM screens)

shr_bt.py

The Bluetooth module can turn off/on BT antenna, visibility and start/stop bt services (spi, hci). We are planning to write some BT manager here - for sending or receiving files, connecting to PAM network, headsets or HID devices, etc.

shr_wifi.py

The WiFi module can turn off/on WiFi antenna. We have only started work on the WiFi manager - right now it is scanning networks and displaying button with names :)

shr_gprs.py

Right now it's doing nothing - only looking good ;)

shr_profiles.py

Here you can change active profile in frameworkd. We want to use hoversel widget instead of toggles in future, and implement some profile manager (changing ring tones, rules etc.)

shr_clock.py

This good-looking clock can provide you an easy way to set actual time. Synchronize with... buttons can set correct time automatically. In future, we want to be able to set the current date here too.

shr_pm.py

Power settings shows to you information about battery state and allows you to power off, restart of suspend your device.

shr_timeouts.py

Here you can set all frameworkd timeouts - for instance dimming, locking and suspending device. We want to implement an easier way to simply disable/enable some timeout (now if you have 30 seconds in suspend, you must click 30 times on "-" button to turn it off).

shr_usb.py

This module is mysterious for SHR users now, because... Probably due to frameworkd bug it's not working. But when it's working, you are able to switch your Neo from device to host mode. In future plans we want to implement setting powered mode in host, and ethernet, mass storage or maybe MTP device in device mode.

shr_services.py

Here you have listing of all services in /etc/init.d, which are used in some runlevels. You can stop or start it without playing with the console.

Others (shr_test.py, shr_misc.py)

This is playground for our developers :)

And that's all! If you want to write your own module - look at module.py, shr_misc.py and shr_test.py. You should be able to understand how shr-settings modules are working. And when you finish - commit, or if you don't have access/don't want to have access/something else - send it to me! My mail is seba.dos1@gmail.com. The same with patches - all work on shr-settings is welcomed.

What's next?

To sum up - our primary goal is to provide all basic functionality, mainly based on frameworkd dbus interface. Secondly, we want to make it faster. If you can help in something, we will be happy when you'll do it :) You can give your thoughts on trac. Happy hacking!