BeagleBoard and maemo

2009-05-23 Thread Kees Jongenburger 
Hi

For next week's hacking week-end I want to install maemo 5.0 beta on the beagle.
http://maemo-beagle.garage.maemo.org/ only talks about the alpha.
Is there already some more up-to-date documentation or would that be a nice
topic to start exploring?

Greetings
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: GtkAction vs. AppMenu

2009-05-23 Thread Cornelius Hald 
On Fri, 2009-05-22 at 19:00 +0200, Alberto Garcia wrote:
 Well, that's what looks better in the Fremantle UI style. So even
 if you use gtk radio buttons directly (i.e, without gtk actions) I
 suggest you to do something like this:
 
 gtk_toggle_button_set_mode (GTK_TOGGLE_BUTTON (radio_button), FALSE);

To be honest, I also like the _look_ of the toggle button more then the
look of the radio button. But I think we really should use radio buttons
where it is semantically correct/needed.
If the user can only select one single option he should see a radio
button group and not something else. Imaging an app menu with two radio
button groups with three options each. Now if we would use toggle
buttons there the user wouldn't get any clue which combinations he can
select. It would be pure try  error.

So why not just change the visual representation of a GtkRadioButton to
something more pleasing?

 Of course you can still use the traditional radio button look if you
 want, see the attached example (it might help you with the keyboard
 accelerators too).

Thanks a lot for the code example. I didn't look at the accelerators
code yet, but I checked the radio button / action stuff.

I attached a slightly extended version of your example, which uses
gtk_radio_action_set_current_value() the way I'm using it in my code.
Sadly it's not working. So maybe I'm just doing it all wrong. Please
check my small modifications.

Here is a small diff to give you a quick glance of what I changed:

 GtkRadioAction *radioaction = NULL;
 
13c15,28
 g_debug (Button clicked: %s, gtk_action_get_name (action));
---
 const gchar *name = gtk_action_get_name (action);
 g_debug (Button clicked: %s, name);
 
 if (strcmp(name, Action one) == 0) {
   g_debug(Activating Radio One);
   gtk_radio_action_set_current_value(radioaction, 0);
 } else if (strcmp(name, Action two) == 0) {
   g_debug(Activating Radio Two);
   gtk_radio_action_set_current_value(radioaction, 1);
 } else if (strcmp(name, Action three) == 0) {
   g_debug(Activating Radio Three);
   gtk_radio_action_set_current_value(radioaction, 2);
 }
 
68d82
 GtkRadioAction *radioaction;


So long!
Conny


#includehildon/hildon.h

GtkRadioAction *radioaction = NULL;

static void
radio_action_changed(GtkAction *action,
 GtkAction *current)
{
g_debug (Radio action changed: %s, gtk_action_get_name (current));
}

static void
action_activated(GtkAction *action)
{
const gchar *name = gtk_action_get_name (action);
g_debug (Button clicked: %s, name);

if (strcmp(name, Action one) == 0) {
	g_debug(Activating Radio One);
	gtk_radio_action_set_current_value(radioaction, 0);
} else if (strcmp(name, Action two) == 0) {
	g_debug(Activating Radio Two);
	gtk_radio_action_set_current_value(radioaction, 1);
} else if (strcmp(name, Action three) == 0) {
	g_debug(Activating Radio Three);
	gtk_radio_action_set_current_value(radioaction, 2);
}

}

static GtkAction *
create_action   (const gchar *name,
 const gchar *accel,
 GtkActionGroup *actiongroup,
 GtkAccelGroup *accelgroup)
{
GtkAction *action = gtk_action_new (name, name, NULL, NULL);
gtk_action_group_add_action_with_accel (actiongroup, action, accel);
gtk_action_set_accel_group (action, accelgroup);
gtk_action_connect_accelerator (action);
g_signal_connect (action, activate, G_CALLBACK (action_activated), NULL);
return action;
}

static GtkButton *
create_item (GtkAction *action)
{
HildonSizeType buttonsize = HILDON_SIZE_FINGER_HEIGHT | HILDON_SIZE_AUTO_WIDTH;
GtkWidget *button = hildon_gtk_button_new (buttonsize);
gtk_action_connect_proxy (action, button);
return GTK_BUTTON (button);
}

static GtkRadioAction *
create_radio_action (const gchar *name,
 GtkRadioAction *previous)
{
static gint count = 0;
GtkRadioAction *action = gtk_radio_action_new (name, name, NULL, NULL, count++);
if (previous) {
gtk_radio_action_set_group (action, gtk_radio_action_get_group (previous));
}
return action;
}

static GtkButton *
create_radio_item   (GtkRadioAction *action)
{
static GSList *group = NULL;
HildonSizeType buttonsize = HILDON_SIZE_FINGER_HEIGHT | HILDON_SIZE_AUTO_WIDTH;
GtkWidget *button = hildon_gtk_radio_button_new (buttonsize, group);
group = gtk_radio_button_get_group (GTK_RADIO_BUTTON (button));
gtk_action_connect_proxy (GTK_ACTION (action), button);
return GTK_BUTTON (button);
}

static HildonAppMenu *

Re: GtkAction vs. AppMenu

2009-05-23 Thread Alberto Garcia 
On Fri, May 22, 2009 at 10:09:49PM +0200, Murray Cumming wrote:

 if radio buttons are meant to look a certain way in Maemo, why isn't
 that just a matter of theming or even of making a change in the GTK+
 code instead of asking people to use the GTK+ API in an abnormal
 way?

Well, there are several reasons for that:

   * First, I don't think there's anything abnormal about that
 API. gtk_toggle_button_set_mode() is there exactly for that
 purpose and it's trivial to use. I don't think it's necessary to
 patch GTK when GTK is already designed to do what we want here.

   * Second, maemo-gtk already differs from the upstream version of
 GTK in quite a few things. Using a fork of GTK is not something
 desirable in general, and keeping it in sync with upstream is not
 a trivial task either, as the maemo-gtk maintainers (Lanedo) will
 probably tell you if you ask them. So we try to introduce as few
 changes as possible to maemo-gtk unless they're really
 necessary. We don't think it's the case here, for the reason
 explained above.

   * Third, GTK is a general purpose toolkit, and contains lots of
 very different widgets for all kinds of needs, but that doesn't
 need that they're all equally suited to every kind of platform or
 device.

 We can decide how we want Maemo to be and how we want its
 applications look like. GTK is good enough to allow us to create
 the widgets that we need, and that's why GTK was chosen. But that
 doesn't mean that we have to remove all the widgets and functions
 that we don't need/recommend for Fremantle. We cannot stop people
 from doing things that we think don't fit in the Fremantle UI
 style.

Berto
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: GtkAction vs. AppMenu

2009-05-23 Thread Alberto Garcia 
On Sat, May 23, 2009 at 02:33:05PM +0200, Cornelius Hald wrote:

  gtk_toggle_button_set_mode (GTK_TOGGLE_BUTTON (radio_button), FALSE);
 
 To be honest, I also like the _look_ of the toggle button more then
 the look of the radio button. But I think we really should use radio
 buttons where it is semantically correct/needed.

As I've just said in a message to Murray, the fact that they're
commonly used in Desktop applications doesn't mean that it has to be
the same way in other kinds of platforms. Toggle-like radio buttons
are quite common too in many user interfaces.

For Fremantle it has been decided that the way to show radio buttons
it to make them look like toggle buttons, and applications have been
designed with that in mind (and that includes making sure that radio
buttons and toggle buttons are not mixed in a way that can confuse the
user). You can also use other widgets (e.g. HildonTouchSelector) for a
similar functionality.

We cannot really force people to use the widgets that we want, but
we can say how Fremantle apps are designed to look like and give
recommendations and guidelines to make 3rd-party apps look consistent
with the overall style of the platform.

 So why not just change the visual representation of a GtkRadioButton
 to something more pleasing?

Well, I didn't design the Fremantle UI style so I cannot really help
you much :) but my personal opinion is that the current design is not
confusing at all (at least if used correctly).

 I attached a slightly extended version of your example, which
 uses gtk_radio_action_set_current_value() the way I'm using it in
 my code.  Sadly it's not working. So maybe I'm just doing it all
 wrong. Please check my small modifications.

I'll try to take a look when I have a few minutes more :)

Berto
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Could not start Xephyr (Maemo 5 Beta SDK). Please help me to resolve. ()

2009-05-23 Thread Kees Jongenburger 
Hi

The command you are running start an embedded X display and the result
on my machine is an empty black screen.
after that you can start the window manager from within the sbox.  so
does your window close by itself?

Here is the relevant link
http://maemo.org/development/sdks/maemo_5-0_installation/#StartUI

The output of the program looks very familiar(and it works here) here is mine:
ke...@ijssijs:~$ Xephyr :2 -host-cursor -screen 800x480x16 -dpi 96 -ac 
[1] 6560
ke...@ijssijs:~$ [dix] Could not init font path element
/usr/share/fonts/X11/cyrillic, removing from list!
[config/dbus] couldn't take over org.x.config:
org.freedesktop.DBus.Error.AccessDenied (Connection :1.62 is not
allowed to own the service org.x.config.display2 due to security
policies in the configuration file)
unrecognised device identifier!
(EE) config/hal: NewInputDeviceRequest failed (2)
unrecognised device identifier!
(EE) config/hal: NewInputDeviceRequest failed (2)
unrecognised device identifier!
(EE) config/hal: NewInputDeviceRequest failed (2)
unrecognised device identifier!
(EE) config/hal: NewInputDeviceRequest failed (2)

On Sat, May 23, 2009 at 4:34 AM, Srinivasan Kumarasamy
kksr...@gmail.com wrote:
 Hi,

 I have installed Maemo 5 Beta SDK.

 I followed the installation instructions from,
 http://maemo.org/development/sdks/maemo_5-0_installation/#sdkinstaller.

 After installing scratchbox and Maemo SDK, I tried to start Xephyr, I could
 not start and I am getting the following error message, Please help me to
 resolve.


 kksr...@kksrini-laptop:~$ Xephyr :2 -host-cursor -screen 800x480x16 -dpi 96
 -ac [1] 13354
 kksr...@kksrini-laptop:~$ Could not init font path element
 /usr/share/fonts/X11/cyrillic, removing from list!
 unrecognised device identifier!
 (EE) config/hal: NewInputDeviceRequest failed
 unrecognised device identifier!
 (EE) config/hal: NewInputDeviceRequest failed
 unrecognised device identifier!
 (EE) config/hal: NewInputDeviceRequest failed
 unrecognised device identifier!
 (EE) config/hal: NewInputDeviceRequest failed
 unrecognised device identifier!
 (EE) config/hal: NewInputDeviceRequest failed
 unrecognised device identifier!
 (EE) config/hal: NewInputDeviceRequest failed
 unrecognised device identifier!
 (EE) config/hal: NewInputDeviceRequest failed
 unrecognised device identifier!
 (EE) config/hal: NewInputDeviceRequest failed
 unrecognised device identifier!
 (EE) config/hal: NewInputDeviceRequest failed



 Thanks,
 Srini

 ___
 maemo-developers mailing list
 maemo-developers@maemo.org
 https://lists.maemo.org/mailman/listinfo/maemo-developers


___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: BeagleBoard and maemo

2009-05-23 Thread Frantisek Dufka 
Kees Jongenburger wrote:
 Hi
 
 For next week's hacking week-end I want to install maemo 5.0 beta on the 
 beagle.
 http://maemo-beagle.garage.maemo.org/ only talks about the alpha.

Got my BB yesterday and was wondering the very same thing :-)

Maybe all Nokia devs finally got their OMAP3 tablet prototypes so no 
need for Beagle anymore? ;-)
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: GtkAction vs. AppMenu

2009-05-23 Thread Murray Cumming 
On Sat, 2009-05-23 at 18:08 +0200, Alberto Garcia wrote:
 On Fri, May 22, 2009 at 10:09:49PM +0200, Murray Cumming wrote:
 
  if radio buttons are meant to look a certain way in Maemo, why isn't
  that just a matter of theming or even of making a change in the GTK+
  code instead of asking people to use the GTK+ API in an abnormal
  way?
 
 Well, there are several reasons for that:
 
* First, I don't think there's anything abnormal about that
  API. gtk_toggle_button_set_mode() is there exactly for that
  purpose and it's trivial to use.

I think that function is widely considered to be useless and illogical. 

  I don't think it's necessary to
  patch GTK when GTK is already designed to do what we want here.
 
* Second, maemo-gtk already differs from the upstream version of
  GTK in quite a few things.

Still, API differences should be avoided where possible. A lot of
unpleasant API differences were reduced before the Fremantle work.

[snip]

-- 
murr...@murrayc.com
www.murrayc.com
www.openismus.com

___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: GtkAction vs. AppMenu

2009-05-23 Thread Murray Cumming 
On Sat, 2009-05-23 at 18:38 +0200, Alberto Garcia wrote:
[snip]
 Toggle-like radio buttons
 are quite common too in many user interfaces.

Not that I can think of.

 For Fremantle it has been decided that the way to show radio buttons
 it to make them look like toggle buttons,

Fair enough. The Fremantle UI guidelines are out of our control,
unfortunately.

  and applications have been
 designed with that in mind (and that includes making sure that radio
 buttons and toggle buttons are not mixed in a way that can confuse the
 user).
[snip]

Well, toggle buttons that act like radio buttons is confusing. But given
that the Fremantle UI guidelines force us to have them, surely the very
existence of any real radio buttons will confuse the user, making them
even less likely to understand that these non-radio-radio-buttons
actually act like radio buttons. So I still feel that you should just
change the appearance of radio buttons and thus make both the UI and API
simpler.

Of course, I know it's too late to change any of this now, so I'm just
complaining. These kinds of mistakes are always made when development is
allowed to be done in isolation for a while, just as the initial Maemo
API had many obvious mistakes.

-- 
murr...@murrayc.com
www.murrayc.com
www.openismus.com

___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: GtkAction vs. AppMenu

2009-05-23 Thread Alberto Garcia 
On Sat, May 23, 2009 at 10:36:42PM +0200, Murray Cumming wrote:

 * First, I don't think there's anything abnormal about that
   API. gtk_toggle_button_set_mode() is there exactly for that
   purpose and it's trivial to use.
 
 I think that function is widely considered to be useless and
 illogical.

Why isn't it deprecated then? I haven't found a style property to
achieve the same effect either. Have you reported a bug against Gtk to
remove it?

I personally don't think it's bad, but I don't have a very strong
opinion about it either. I'd like to see comments from upstream Gtk
developers, or from people who are already using it.

Berto
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: GtkAction vs. AppMenu

2009-05-23 Thread Alberto Garcia 
On Sat, May 23, 2009 at 10:44:50PM +0200, Murray Cumming wrote:

  Toggle-like radio buttons are quite common too in many user
  interfaces.
 Not that I can think of.

Well, I haven't made a list :) but out of the blue I can think at
least of the GIMP, Audacity, OpenOffice/MS Word/Abiword/Gnumeric,
the iPhone... and I'd swear I saw them in the Moblin 2 UI too. But I
wasn't only thinking about computer interfaces, they're used in some
home appliances too.

 Well, toggle buttons that act like radio buttons is confusing.

Not if the UI is well designed. E.g. if you pack them together and set
clear labels or icons I don't think it's confusing at all. And taking
into account that all Fremantle apps are going to be like that I don't
think there's that much room for confusion.

A standard toggle button can also be confused with a normal button for
that matter, and we're not talking about removing toggle buttons, are
we?

But let's take a more extreme example: MS Word/OpenOffice/Abiword/etc.
not only mix toggle buttons and toggle-like radio buttons, they're
also located next to one another! :)

 But given that the Fremantle UI guidelines force us to have them,
 surely the very existence of any real radio buttons will confuse
 the user, making them even less likely to understand that these
 non-radio-radio-buttons actually act like radio buttons. So I still
 feel that you should just change the appearance of radio buttons and
 thus make both the UI and API simpler.

Well, it seems clear that you don't like toggle-like radio buttons at
all.

As that's Gtk code rather than Hildon, I think that you should talk
to the maemo-gtk maintainers and also file a bug against Gtk in
bugzilla.gnome.org to deprecate gtk_toggle_button_set_mode() and make
that feature themeable.

 Of course, I know it's too late to change any of this now, so I'm
 just complaining. These kinds of mistakes are always made when
 development is allowed to be done in isolation for a while, just as
 the initial Maemo API had many obvious mistakes.

I don't think it's late. What you're complaining about is Gtk API
that has been there for at least ten years, and there's nothing that
prevents us from making all radio buttons look like toggle buttons in
Fremantle and make gtk_toggle_button_set_mode() a no-op.

So go ahead. As I said before I think it's fine as it is now but I
don't have a very strong opinion about it either. So if you convince
the maemo-gtk maintainers to change GtkRadioButton I'll respect their
decision.

Berto
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers