Re: hildon.StackableWindow and blocking windows
On Wed, Feb 16, 2011 at 11:01:04AM +0200, Max Usachev wrote: > I want to use StackableWindow in my program like dialogs That's not the way to do it in GTK: you have to show the new window and connect to its 'destroyed' signal to do what you want to do after the window is destroyed. Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo.org Extras autobuilder updated to PR1.3
On Mon, Oct 25, 2010 at 05:18:04PM +0200, Niels Breet wrote: > The autobuilder has been updated to the PR1.3 SDK. > > If you experience any problems, please let me know. QStarDict appeared to stop working after this upgrade, I guess I'll need to install a newly-compiled version? Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [mafw-lastfm-devel] [ANN] maemo-scrobber 1.0 for last.fm + libre.fm
On Thu, Jun 03, 2010 at 04:10:28PM +0300, Felipe Contreras wrote: > mafw-lastfm: > last.fm: scrobble: yes, now playing: yes > libre.fm: scrobble: no, now playing: no > > maemo-scrobbler: > last.fm: scrobble: yes, now playing: no > libre.fm: scrobble: yes, now playing: no [...] > "now playing" is a feature that users would barely notice Well, that's a respectable opinion, but I for one consider it one of the most basic features of any Last.fm client. And not that I have anything against Libre.fm (quite the contrary), but I'd say that at this moment it is the lack of Libre.fm support the feature that most users won't notice. Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to resize HildonPannableArea child widgets
On Mon, Mar 01, 2010 at 05:57:45PM +0100, Luca Donaggio wrote: > Which is the best way to resize widgets inside a PannableArea? > I'm writing a callback function to be called when the device > orientation changes and I noticed that PannableAreas retain their > former width, so widgets inside aren't resized (for example, > gtkLabels don't wrap their content). gtk_widget_queue_resize() should be enough. (we're considering fixing this directly in Maemo-GTK btw) Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: show existing StackableWindow second time
On Tue, Feb 16, 2010 at 02:18:26PM +0200, Max Usachev wrote: > > You need to connect to the delete-event of the subwindow and > > invoke hide() in there to hide the window. Your delete callback > > must return True to signalize that the windows is not to be > > destroyed. See also gtk_widget_hide_on_delete() http://library.gnome.org/devel/gtk/2.21/GtkWidget.html#gtk-widget-hide-on-delete Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: HildonTouchSelector
On Thu, Apr 08, 2010 at 10:38:26PM -0700, Aniello Del Sorbo wrote: > I have a HildonPickerButton with a simple Selector with no Done > button. > > With the trick below I can remove rows from the Selector, but then > the PickerDialog does not properly resize itself, leaving some empty > space below the Selector. Hmm... can you please file a bug about that? Thanks ! Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: HildonTouchSelector
On Thu, Apr 08, 2010 at 06:11:15PM -0700, Aniello Del Sorbo wrote:
> > /* Get the path to row 0 */
> > path = gtk_tree_path_new_from_string ("0");
> >
> > /* Get the tree iter for that path */
> > gtk_tree_model_get_iter (GTK_TREE_MODEL (model),
> > &iter, path);
> >
> > /* Do not need path anymore */
> > gtk_tree_path_free (path);
Btw, you have
gtk_tree_model_get_iter_first ()
gtk_tree_model_iter_nth_child ()
which are easier to use.
Berto
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: HildonTouchSelector
On Thu, Apr 08, 2010 at 06:11:15PM -0700, Aniello Del Sorbo wrote: > HildonTouchSelector has methods to append/prepend items but none to > remove them. > GTK does. Ok, I understand this is arguable, but since you can access the model directly, I don't think HildonTouchSelector needs to provide extra methods for all tree model operations. Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to include glib-object.h
On Mon, Mar 29, 2010 at 02:48:18PM +0530, Martin DeMello wrote: > > glib-object.h: No such file or directory > > Try adding -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include to > your gcc invocation. Actually you should include `pkg-config --cflags glib-2.0` Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: GSoC project - Google Reader offline
On Mon, Mar 22, 2010 at 02:00:10PM -0300, MoRpHeUz wrote: > > I am interested in the project Google Reader offline. > > This seems like a "must have" application :) we already have a "not > so nice" feed reader but it doesn't sync with google reader and you > seems well qualified for the job! :D See also this: http://blogs.igalia.com/svillar/2010/03/22/vive-la-resistance/ Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Rows selection in TouchSelector
On Mon, Mar 08, 2010 at 12:45:10PM +0100, Alberto Garcia wrote: > gtk_tree_model_get_iter_first (model, &iter); Well, this line is not necessary :) Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Rows selection in TouchSelector
On Sun, Mar 07, 2010 at 08:30:16PM +0200, Max Usachev wrote:
> > > I use TouchSelector with
> > > hildon.TOUCH_SELECTOR_SELECTION_MODE_MULTIPLE mode to select
> > > multiple items, but I can't find way to select necessary items
> > > (for example, the first and the fourth) at startup (when
> > > TouchSelector shows).
> >
> > Use hildon_touch_selector_select_iter()
> >
> Thanks! Can you show a little example how to use this method?
Here's an example (in C).
Berto
void
select_items (HildonTouchSelector *selector)
{
GtkTreeModel *model;
GtkTreeIter iter;
model = hildon_touch_selector_get_model (selector, 0);
gtk_tree_model_get_iter_first (model, &iter);
hildon_touch_selector_unselect_all (selector, 0);
gtk_tree_model_iter_nth_child (model, &iter, NULL, 1);
hildon_touch_selector_select_iter (selector, 0, &iter, FALSE);
gtk_tree_model_iter_nth_child (model, &iter, NULL, 3);
hildon_touch_selector_select_iter (selector, 0, &iter, FALSE);
gtk_tree_model_iter_nth_child (model, &iter, NULL, 4);
hildon_touch_selector_select_iter (selector, 0, &iter, FALSE);
}
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Rows selection in TouchSelector
On Sun, Mar 07, 2010 at 03:19:36PM +0200, Max Usachev wrote: > I use TouchSelector with > hildon.TOUCH_SELECTOR_SELECTION_MODE_MULTIPLE mode to select > multiple items, but I can't find way to select necessary items (for > example, the first and the fourth) at startup (when TouchSelector > shows). Use hildon_touch_selector_select_iter() Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: hildonpickerdialog done button
On Fri, Feb 19, 2010 at 02:21:31AM -0600, Michael Cronenworth wrote: > How does one attach to the "Done" button when using two > HildonTouchSelector columns? If you are using a HildonPickerDialog directly you can use the standard GtkDialog::response signal. http://maemo.org/api_refs/5.0/5.0-final/gtk/GtkDialog.html#GtkDialog-response I see that it's not clear in the HildonPickerDialog doc, so I'll update it now. Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Going crazy with HildonPickerButton with multiple selection
On Fri, Feb 19, 2010 at 09:31:47AM +0200, Alberto Mardegan wrote: > BTW, I find the APIs for handling selections rather cumbersome, I > have to write about 20 lines of code just to know the selection > state of an item (if multiple selection is enabled). > > If I write a patch that adds > > gboolean hildon_touch_selector_is_selected(HildonTouchSelector *selector, >gint column, >gint index); > void hildon_touch_selector_set_selected(HildonTouchSelector *selector, > gint column, > gint index, > gboolean selected); > > would that have any chance of making its way in a future release? Sure, can you please file a bug ? Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Going crazy with HildonPickerButton with multiple selection
On Thu, Feb 18, 2010 at 10:33:46PM +0200, Alberto Mardegan wrote: > HildonPickerButton with multiple selection seems to be perfect for > my need, but unfortunately HildonPickerDialog doesn't allow closing > the dialog if no item is selected (why???). I know it's controversial, but that was a design decision for Maemo 5. The solution is to have an option labelled "None". For an example, open the clock app, try adding a new alarm and see the "Repeat" button (which allows multiple selection). The first option is "Never" Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Is the Diablo autobuilder running?
On Sat, Feb 06, 2010 at 05:01:18AM -0800, Steven Luo wrote: > > > > Is the Diablo autobuilder up and running? > > > > > > It is, but it took me several hour to have my package compiled. > > > > ...but I can't seem to be able to promote it: > > > > https://maemo.org/packages/package_instance/view/diablo_extras-devel_free_armel/vagalume/0.8.3-1diablo1/ > > That looks like https://bugs.maemo.org/show_bug.cgi?id=8806, which > I'm also hitting. Indeed, thanks for the link Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Is the Diablo autobuilder running?
On Sat, Feb 06, 2010 at 12:31:35PM +0100, Alberto Garcia wrote: > > Is the Diablo autobuilder up and running? > > It is, but it took me several hour to have my package compiled. ...but I can't seem to be able to promote it: https://maemo.org/packages/package_instance/view/diablo_extras-devel_free_armel/vagalume/0.8.3-1diablo1/ Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Is the Diablo autobuilder running?
On Sat, Feb 06, 2010 at 01:20:14AM -0800, Steven Luo wrote: > Is the Diablo autobuilder up and running? It is, but it took me several hour to have my package compiled. But I'm having problems to upload a package to gregale-extras and bora-extras. Are these repositories still supported? Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo5 SDK slow performance
On Tue, Feb 02, 2010 at 12:11:20AM +0200, Max Usachev wrote: > I have strange problem with Maemo 5 SDK - all graphic manipulations > in emulator works very slow. Try this before starting the desktop in Xephyr: export CLUTTER_VBLANK=none Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Changing chinook support to archive mode
On Mon, Jan 25, 2010 at 09:52:36PM +0100, Niels Breet wrote: > It has been quite a while since diablo became the successor of > chinook. > > I think it is time to make the chinook repository read-only and > close down the builder instance for it. I support that decision. I actually don't know why this wasn't done earlier. Aren't chinook and diablo 100% binary compatible? Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: GtkTreeView behaviour
On Tue, Jan 12, 2010 at 12:39:33PM +0100, Piñeiro wrote: > You need to set hildon-mode to one, this is normally done on a rc > file. This is not necessary anymore :) Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: GtkTreeView behaviour
On Mon, Jan 11, 2010 at 11:47:48PM +0300, George Kibardin wrote:
> In my case for some reason in normal mode I need two taps to get
> row-activated signal: one tap to select appropriate item and another
> one to activate it. In edit mode with multiple selection enabled
> I need to use Ctrl to select multiple items which also seems
> wrong. What I'm doing wrong?
There must be something wrong in your code... I'm attaching a simple
example of a treeview in normal mode, tell me if it works fine for
you.
Berto
#include
static const char *countries[] = {
"Austria", "Belgium", "Bulgaria", "Cyprus", "Czech Republic",
"Denmark", "Estonia", "Finland", "France", "Germany", "Greece",
"Hungary", "Ireland", "Italy", "Latvia", "Lithuania", "Luxembourg",
"Malta", "Netherlands", "Poland", "Portugal", "Romania", "Slovakia",
"Slovenia", "Spain", "Sweden", "United Kingdom"
};
static void
row_activated_cb(GtkTreeView *tree_view,
GtkTreePath *path,
GtkTreeViewColumn *column,
gpointer user_data)
{
gchar *str;
GtkTreeIter iter;
GtkTreeModel *model = gtk_tree_view_get_model (tree_view);
gtk_tree_model_get_iter (model, &iter, path);
gtk_tree_model_get (model, &iter, 0, &str, -1);
g_debug ("Row activated: %s", str);
g_free (str);
}
static GtkTreeModel *
create_model(void)
{
int i;
GtkListStore *store;
store = gtk_list_store_new (1, G_TYPE_STRING);
for (i = 0; i < G_N_ELEMENTS (countries); i++) {
gtk_list_store_insert_with_values (store, NULL, i, 0, countries[i], -1);
}
return GTK_TREE_MODEL (store);
}
static GtkWidget *
create_tree_view(void)
{
GtkWidget *tree_view;
GtkCellRenderer *renderer;
GtkTreeModel *model;
tree_view = hildon_gtk_tree_view_new (HILDON_UI_MODE_NORMAL);
gtk_tree_view_set_rules_hint (GTK_TREE_VIEW (tree_view), TRUE);
model = create_model ();
gtk_tree_view_set_model (GTK_TREE_VIEW (tree_view), model);
g_object_unref (model);
renderer = gtk_cell_renderer_text_new ();
g_object_set (renderer, "xalign", 0.5, "weight", PANGO_WEIGHT_BOLD, NULL);
gtk_tree_view_insert_column_with_attributes (GTK_TREE_VIEW (tree_view), 0,
"Column 0", renderer, "text", 0, NULL);
return tree_view;
}
int
main(intargc,
char **argv)
{
GtkWidget *window;
GtkWidget *panarea;
GtkWidget *treeview;
hildon_gtk_init (&argc, &argv);
window = hildon_window_new ();
panarea = hildon_pannable_area_new ();
treeview = create_tree_view ();
gtk_container_add (GTK_CONTAINER (panarea), treeview);
gtk_container_add (GTK_CONTAINER (window), panarea);
g_signal_connect (window, "destroy", G_CALLBACK (gtk_main_quit), NULL);
g_signal_connect (treeview, "row-activated", G_CALLBACK (row_activated_cb), NULL);
gtk_widget_show_all (window);
gtk_main ();
return 0;
}
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
How to play music in silent mode?
I want to make Vagalume play music even if the N900 is in silent mode. I also don't want it to be interrupted when I receive a new IM. Summarizing: I want the same behavior as the N900 media player. How do I do that? I'm using GStreamer's pulsesink. Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Why is always one textview item selected in HILDON_UI_MODE_EDIT?
On Fri, Dec 18, 2009 at 12:45:47PM +0100, Till Harbaum wrote: > i have a simple treeview inside a pannable area. What i want to > achieve is basically simple: I want the user to be able to select > one item and that item should stay selected until the user selects a > different item. Initially nothing should be selected. Doesn't that work? That's what GTK_SELECTION_BROWSE is for. See hildon-touch-selector-normal-mode-example.c http://maemo.gitorious.org/hildon/hildon/blobs/master/examples/hildon-touch-selector-normal-mode-example.c Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Find out Maemo version from script
On Tue, Dec 15, 2009 at 12:21:58PM +0100, Cornelius Hald wrote: > While developing inside the SDK I used /etc/maemo_version (which is > provided by the package maemo-version) to alter the runtime behavior > of some scripts. I think it's simpler to check the version of some installed packages (using e.g. pkg-config) Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: mafw-lasftm: installed, configured, restarted the device, but plugin is not started
On Tue, Dec 08, 2009 at 09:20:48PM +0100, Andrea Grandi wrote: > another idea: what about displaying "Listening with Nokia N900" > instead of "Listening with mafw-lastfm" ? The thing is that you can scrobble from the N900 using different apps, and you can also (in theory) use mafw-lastfm from a platform other than the N900, so ... Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: N900 GPS Problems
On Mon, Nov 30, 2009 at 05:24:11PM +0100, Andrea Grandi wrote: > > With an internet connection available, though, this one is very > > fast (<10 seconds). And looking at how the Maps application is, I > > think it's meant to be used with a data plan. Otherwise it's not > > very useful. > > same for me, but Maps (even if is the worst map application after > N810 Maps) doesn't need an internet connection because you can > pre-load the maps downloading them from OVI servers. I didn't say "it needs", I said "it's meant to be used with" ;-) Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: N900 GPS Problems
On Mon, Nov 30, 2009 at 05:52:29PM +0200, Michael Stepanov wrote: > It'd be really bad if the GPS chip will be weak as on N810. Cause my > device spends a lot of time to find location. In my (short) experience it is _worse_. I have been unable to get a GPS fix using just the internal GPS. I tried 2 or 3 times in very open spaces, and after 3 or 4 minutes I gave up (note that I haven't tested since I upgraded to 42-11, I don't know if it makes a difference). The N810 was slow but I almost never had problems if I stood still for a couple of minutes. And after that it worked reasonably well. With an internet connection available, though, this one is very fast (<10 seconds). And looking at how the Maps application is, I think it's meant to be used with a data plan. Otherwise it's not very useful. Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Can't debug an application under FREMANTLE_ARMEL target in Scratchbox
On Tue, Nov 24, 2009 at 07:55:47PM +0300, Burka Victor wrote: > I'm trying to debug very simple application under FREMANTLE_ARMEL > target and can't do that. The armel target is not meant to actually run or debug applications, but only to compile them to use in the device. If you want to debug your apps inside scratchbox, use the x86 target instead. Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: mafw-lastfm 0.0.1
On Mon, Oct 05, 2009 at 04:55:35PM +0300, Claudio Saavedra wrote: > > > Just excellent! I reviewed it and it is a very good job! I am > > > already working on some patches to add some features, but I'll > > > tell you when they are ready :) > > /me crosses his fingers for multiscrobble and libre.fm :) > That's not such a crazy idea, we could add it at some point. The scrobbling API is exactly the same, so it should be easy. Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Community widgets for Fremantle
On Tue, Sep 29, 2009 at 11:39:37PM +0300, Claudio Saavedra wrote: > > The first obvious problem is that we would end up having two > > similar versions of the same library installed, and that > > means more disk and memory, apart from the inability to use > > maemo-launcher. > > Can you elaborate on the maemo-launcher issue? maemo-launcher preloads libhildon, doesn't it ? Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Community widgets for Fremantle
On Tue, Sep 29, 2009 at 06:08:00PM +0300, Marius Vollmer wrote: > > we can perfectly create a parallel installable version of the > > same library, that the community can maintain in extras and link > > against in their applications. > > Yes, but there are some practical problems about that. The first obvious problem is that we would end up having two similar versions of the same library installed, and that means more disk and memory, apart from the inability to use maemo-launcher. What else? Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Community widgets for Fremantle
On Tue, Sep 29, 2009 at 06:19:04PM +0200, Javier Jardón wrote: > > Hildon could perfectly move forward, with new widgets and all the > > bug fixes that the community wants to see. If Nokia doesn't react > > to that, we can perfectly create a parallel installable version of > > the same library, that the community can maintain in extras and > > link against in their applications. > > To achieve this, I think that would be great that we can compile > Hildon outside maemo SDK. Of course that would be a nice thing, but it doesn't have much to do with the problem we're discussing here. Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle: HildonCheckButton with two labels
On Sat, Sep 19, 2009 at 11:55:03AM +0200, Cornelius Hald wrote: > I'm trying to create a Hildon check button with two labels. The > problem is that HildonCheckButton only supports one label. Why? As Mox explained, that check button was designed to have only one label. If we supported two we wouldn't be able to use some of GtkButton's functions, notably gtk_button_set_label() I can't think of any obvious workaround other than writing a new widget based on the HildonButton code... > It looks like the inheritance tree of the Hildon*Buttons is quite > messy! > Are there any plans to fix that or will it be fixed with Qt? Hopefully we'll be able to make this simpler in the future: https://bugzilla.gnome.org/show_bug.cgi?id=557720 Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle: HildonCheckButton with two labels
On Sat, Sep 19, 2009 at 12:00:50PM +0200, Cornelius Hald wrote: > In my HildonButton subclass. Instead of setting the GtkCellView using > hildon_button_set_image(), I also tried gtk_button_set_image(). The > problem with the latter is, that it's just never shown. Probably > HildonButton is somehow overriding the image part of GtkButton. Yes, because GtkButton's _set_image() is not a virtual method. GtkButton supports an image and a label. If you change that default layout (which is what HildonButton does) there's no way to reuse some of its methods. Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New apps for fremantle with Qt?
On Tue, Sep 08, 2009 at 11:24:05AM +0300, Quim Gil wrote: > What about a BOF in the Maemo Summit? I have seen several developers > registered that are familiar with GTK+ and Hildon and even upstream > maintainers. That's a good idea, I'll talk to the rest of the Hildon team to submit a proposal. Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New apps for fremantle with Qt?
On Mon, Sep 07, 2009 at 08:17:01PM +0200, Attila Csipa wrote: > This sounds to me like saying coding for Fremantle is a one-shot > affair - you have these specially designed widgets, which are there > only on Fremantle and who knows what their future will be That's a very reasonable concern, and one that is shared by many people, including me. Nokia has already announced that they're switching from Gtk to Qt in Harmattan (which has been a confusing move for many users and developers), but I don't know if they plan to keep the same basic widgets and UI style that has been designed for Fremantle or not. If the plan is to keep more or less the same UI style I'd expect a decent, community-supported, release of Gtk/Hildon for Harmattan. If the plan is to redesign the UI all over again then God only knows what's going to happen... :-) > > * Telling people that it's completely reasonable to write > > Fremantle apps in Qt without making clear that some fundamental > > Fremantle widgets have not been written yet it not a good idea > > IMHO. > Sigh, I said I won't comment on this, but... I'm not sure what's the > developer's alternative. Since I don't know Nokia's plans for Harmattan, I'm afraid I can't help you much more. It's not that I like the current state of confusion much either, I'm just trying to explain how I see things now and I think that it's up to each developer to decide what to do, but evaluating things first. Many will think that it's OK for them to write applications in Qt, even if they don't have the complete set of Hildon widgets available right now, because that's the future of Maemo. Others will prefer, at least for now, to stick to Gtk/Hildon, which has been much more thoroughly tested in Fremantle, and is the one officially supported and guaranteed to be consistent with the rest of the platform. My opinion? Well, right now Maemo is Fremantle. Harmattan will come in the future but we don't know when. The N900 has been released two years after the N810 so it wouldn't be unreasonable to think that the next device can take two more years. It's quite a lot of time to wait to see what's going to happen. The N900 hasn't even reached the stores yet but what we've seen so far suggests that this is going to be much more successful than any previous Maemo device. So I _personally_ don't think I'm going to worry _that much_ about Harmattan right now. In the end it depends a lot on the application developers' skills and long-term plans for their software. And these are my 2 cents. Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New apps for fremantle with Qt?
On Mon, Sep 07, 2009 at 05:09:25PM +0300, Kate Alhola wrote: > > The importance and the goal of Hildon is to provide a set of essential > > widgets so > > > > a) app developers don't have to waste their time in writing them > >themselves > > b) there is UI consistency between all applications > > > > If there are no Qt equivalents for all Hildon widgets, none of > > these two problems are solved, no matter how easy it is for > > developers to write their own widgets or how compact the code is. > If you think that if there is not 1 to 1 equivalent for everything, > there is nothing. No, I haven't said that. What I say is: * The Fremantle UI style depends heavily on a set of widgets that have been specifically designed for it. * These include some very fundamental widgets such as HildonAppMenu, HildonPickerButton and HildonStackableWindow. * If you take a look at the N900 you'll see that these widgets are used ALL OVER THE PLACE. * Example: there's no application in the N900 using a menu other than HildonAppMenu. * If you want to use a menu in your application you must use HildonAppMenu or a widget designed to mimic its look and feel, else your application will look different. * There's nothing necessarily wrong with that (e.g. Canola), but developers should be aware before starting to write their apps. So: * Do you want to provide Qt libs for developing Fremantle apps? Good * Are all the widgets that have been designed as a central part of the Fremantle UI available in Qt? Good * Aren't they available yet? Fair enough, but then make sure that developers are aware of this. The bottom line: * Telling people that it's completely reasonable to write Fremantle apps in Qt without making clear that some fundamental Fremantle widgets have not been written yet it not a good idea IMHO. > It is also other question that which is more wasting time, writing > couple of dozen lines when you can save couple of thousand lines in > all application by more compact and efficient code with C++ and Qt. I'm not going to start a C vs C++ debate, but I don't think this is an argument here since there are already C++ bindings for Hildon: http://maemomm.garage.maemo.org/docs_unstable/tutorial/html/sec-TouchSelector.html Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New apps for fremantle with Qt?
On Sun, Sep 06, 2009 at 07:14:22PM +0200, karoliina.t.salmi...@nokia.com wrote: > > > > if you want to have the exact same user experience as the > > > > preinstalled Maemo 5 applications have (as seen in all youtube > > > > videos and the SDK), then you have much easier time and faster > > > > development with the gtk-based hildon widgets in Maemo 5. > > I would caution against too easily dismissing Hildon Pickers as > > trivial "composites" that app developers can implement. [...] The > > "combobox" in Linux desktops is pretty much a subset of the hildon > > pickers (in terms of funtionality, not directly in terms of actual > > UI elements). So if pickers would be trivial, then why would there > > be a need to provide a combobox in the standard toolkit? > > These things are easier in some toolkits and harder in some > others. To my knowledge, Gtk was not really designed for handheld > touch user interface with kinetic scroll etc. on mind in the first > place - it is a rather a desktop toolkit with the rather traditional > mindset - and some of hard core hacking obviously was required to > make it function like it functions on the Maemo 5. >From a technological point of view, the new widgets in Hildon are completely traditional and they are based on standard Gtk+ widgets. Of course they are designed to be used on a small, touch screen device, but what this means in terms of implementation is that we avoided using interactions, components and sizes that were too small or too difficult to be used with fingers in a screen like that of the N900. We haven't found any particular limitation in Gtk+ that made this more difficult. Example: HildonAppMenu is basically a window with two groups of buttons. There's nothing strange or unexpected here, and certainly nothing that Gtk+ was not designed to cope with. The work here was about getting the semantics, layout, sizes, alignments, API, etc right, not about fighting with any design limitation in Gtk+. And the same thing applies to all other Hildon widgets. The importance and the goal of Hildon is to provide a set of essential widgets so a) app developers don't have to waste their time in writing them themselves b) there is UI consistency between all applications If there are no Qt equivalents for all Hildon widgets, none of these two problems are solved, no matter how easy it is for developers to write their own widgets or how compact the code is. Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New apps for fremantle with Qt?
On Fri, Sep 04, 2009 at 07:16:43PM +0200, kate.alh...@nokia.com wrote: > > What people are asking here (among other things) is whether there > > are Qt widgets similar to HildonAppMenu or HildonPickerButton > > -which are absolutely essential for creating Fremantle > > applications- or developers are supposed to write them themselves. > > To avoid re-inventing the wheel again we are providing examples how > you can do things with Qt. [...] If some of these composite widgets > are so big problem, we can collect these examples as widget library. That's what I mean. While it's obvious that you can write apps for fremantle in toolkits other than Gtk/Hildon (e.g Canola), developers will have a hard time to make them fit in with the Fremantle UI style unless they have reasonable replacements for the most basic widgets. So yes, a widget library with equivalents to HildonAppMenu, HildonPickerButton, etc., would be the way to go in my opinion. Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New apps for fremantle with Qt?
On Fri, Sep 04, 2009 at 06:18:37PM +0300, Kate Alhola wrote: > > > I have used Maemo 5 and N900 since early prototypes and i don't > > > see lot of important frequently used functionality missing from > > > Qt. I admit that some rarely used widgets like earlier mentioned > > > date and time picker are missing etc. > > Rarely used widgets? Come on, these are used all throughout > > the platform. Moreover, even if the time and date pickers > > were not so commonly used, their style, user experience, and > > base API (through HildonPickerButton, HildonPickerDialog and > > HildonTouchSelector[Entry]) are central to the Fremantle UI, and > > certainly the most recommended starting point for anyone writing > > an application for Fremantle. > As I said before, we are doing examples how to do many of these > things with Qt . The question is not whether similar widgets can be created using Qt. Of course they can. What people are asking here (among other things) is whether there are Qt widgets similar to HildonAppMenu or HildonPickerButton -which are absolutely essential for creating Fremantle applications- or developers are supposed to write them themselves. Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New apps for fremantle with Qt?
On Fri, Sep 04, 2009 at 03:00:05PM +0200, Murray Cumming wrote: > One small example that's been mentioned already in this thread: How > do we create a HildonAppMenu with Qt? How do we create a > HildonTouchSelector, and/or any of the specific selectors for time > or dates, etc. I believe the answer is that we can't. > > The Maemo Qt developers have not yet even decided whether they will > add API to Qt for Maemo-specific UI features, let alone implemented > it. It's OK to like Qt, but there's no need to avoid the actual > problems faced by actual developers. That is very important, since some of those widgets are completely essential for Maemo 5. If people take a look at the N900 videos that have been uploaded to YouTube lately and see how the applications look and feel, it's obvious that it's not possible to obtain a similar result without Qt equivalents for these new widgets. Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Python + hildon.TouchSelector (with pixbufs)
On Mon, Aug 31, 2009 at 02:33:44PM -0400, Brent Chiodo wrote: > Hmm, .set_image() still isn't working... Are the Python bindings using .set_image() from HildonButton? Unfortunately, GtkButton's set_image() is not virtual, cannot be overriden and is useless for buttons with layouts different from the standard one (that includes HildonButton and its subclasses, such as HildonPickerButton). Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Howto enable portrait mode support on Fremantle
On Mon, Aug 31, 2009 at 11:32:37AM +0200, Cornelius Hald wrote: > I´ve updated the wiki page with all the information that was > provided in this thread. If something is not clear, please feel free > to update the page. > > http://wiki.maemo.org/Using_Fremantle_Widgets#Automatic_Screen_Rotation Thanks Cornelius for updating the wiki. There's one more thing about rotation that I think hasn't been discussed yet (among other things because it's a relatively recent change) and might be a good idea to mention in the wiki. The group of filter buttons in HildonAppMenu has now a fixed size (::filter-group-width pixels) that is independent of the number of filters and the orientation of the device. So what happens basically is that if filters look good in landscape mode, they should look the same when you change to portrait. Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Howto enable portrait mode support on Fremantle
On Fri, Aug 21, 2009 at 02:59:38PM +0200, Andre Klapper wrote: > > > hildon_gtk_window_set_portrait_flags(GTK_WINDOW(win), > > > HILDON_PORTRAIT_MODE_SUPPORT); > > > > Use HILDON_PORTRAIT_MODE_SUPPORT | HILDON_PORTRAIT_MODE_REQUEST > > Maybe you could add a few lines / example code to > http://wiki.maemo.org/Using_Fremantle_Widgets#Marking_Your_App_As_Portrait_Capable > if you find some time? Sure :) I'd appreciate if you or someone could file a bug about that (at this moment I'm very busy with other things). Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Howto enable portrait mode support on Fremantle
On Fri, Aug 21, 2009 at 02:53:01PM +0200, Cornelius Hald wrote: I'll try to summarize how it works (I'm adding Kimmo to Cc in case I'm forgetting something, as the rotating itself is done by the desktop, libhildon only sets a WM hint). Let's suppose we open a new window. Before we open that window the device might already be in portrait mode. If the portrait flags of the new window are: 1) No flags -> The screen is rotated to landscape mode. 2) _SUPPORT -> The screen keeps its orientation. 3) _SUPPORT + _REQUEST -> The screen is rotated to portrait mode 4) _REQUEST alone -> I don't think we're using that. Kimmo? To detect whether a device is physically rotated I think you need to use the DBus API already mentioned in this thread. In other words: using this API alone won't change the orientation of the screen when the device is physically rotated, am I right Kimmo? Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Howto enable portrait mode support on Fremantle
On Fri, Aug 21, 2009 at 02:37:14PM +0200, Frantisek Dufka wrote: > Not sure what Fremantle provides but in general there are more > modes (90 vs 270 degrees, 0 vs 180) which may be important to your > application because of position of HW buttons or maybe camera input > format (may be upside down) etc. You can't find this from screen > resolution alone. Good point. However we don't have that in Fremantle so there's no need for that. Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Howto enable portrait mode support on Fremantle
On Fri, Aug 21, 2009 at 10:59:32AM +0200, Cornelius Hald wrote: > > And I think that the use of signal "size-changed" is not the right > > way.(IMHO) > > You will need control real value size of window. You will need > > control changing to full screen and revert in window and in next > > Maemo devices size of screen may be large or small. You don't need anything new to detect orientation changes, screen size of window size. There's already standard GTK+ API for that. > Yes, there have been many discussions about that already. The > result of this discussion was that there is not a single correct > way of doing this. I´m assuming the following: width > height > => landscape and height > width => portrait. Of course this does > not work if you have a square screen ;) Well, I´m not super happy > with it, but inside scratchbox using xrandr to rotate the screen it > works. I really can't see the problem :-? Landscape is by definition when width > height, and portrait when width < height Maybe I'm overlooking something, but why would you need any new API? And how would you expect that API to work? > I think the bottom line is just that it´s very poorly documented Well, that might be true, but hopefully the documentation can be improved once the device is released, which is something that we can't do with the code :) that's why we're putting more effort in the latter. Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Howto enable portrait mode support on Fremantle
On Fri, Aug 21, 2009 at 09:07:15AM +0200, Cornelius Hald wrote: > hildon_gtk_window_set_portrait_flags(GTK_WINDOW(win), > HILDON_PORTRAIT_MODE_SUPPORT); Use HILDON_PORTRAIT_MODE_SUPPORT | HILDON_PORTRAIT_MODE_REQUEST > I assume that HILDON_PORTRAIT_MODE_SUPPORT means that this window > is supporting the portrait mode and thus can be rotated. And that > HILDON_PORTRAIT_MODE_REQUEST means that the UI should be switched > to portrait mode no matter what the orientation of the device is, > right? Exactly. _SUPPORT means that e.g. if the device is in portrait mode and your app comes up, it won't be rotated to landscape. Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: App menu not popping up any more after upgrading to Fremantle Beta2
On Mon, Jul 27, 2009 at 05:27:31PM +0200, Luca Donaggio wrote: > Thanks Alberto, now it works! > I'm wondering why was it working before (Beta1) when I was doing > a gtk_widget_show_all() on the main window only? It was a bug in the menu; it was showing the widgets for you. Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: App menu not popping up any more after upgrading to Fremantle Beta2
On Mon, Jul 27, 2009 at 04:42:48PM +0200, Luca Donaggio wrote: > After upgrading my SDK to Fremantle Beta2, I'm not able to click on > the window title bar of my applications to bring up its menu any > more. Make sure that you're showing all menu items. A call to gtk_widget_show_all(menu) after adding all items is enough. Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to place a button in the fremantle title bar?
On Tue, Jul 21, 2009 at 12:30:45PM +0100, Andrew Flegg wrote: > > Presumably one shouldn't allow the user to unfullscreen such a > > window. Also what about the impact on themeing, menus & AppMenus? > > ...because it *looks* like a window, clicking on the title should open > the window's menu. Does this happen automatically, or does it need > to be handrolled, or is there no menu support when one's using it? I'll check it but I think it should pop up the menu automatically. > Sounds like there's a documentation bug either way, as > HildonEditToolbar doesn't say it should be used only after > gtk_window_fullscreen(): I'll check that too. Thanks! Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to place a button in the fremantle title bar?
On Tue, Jul 21, 2009 at 11:00:54AM +0100, Andrew Flegg wrote: > Yes, I understand that. But a developer, on seeing a screencast, > thought it part of the normal WM chrome. Indeed, if you look at the > screenshot[1] it looks like any other stacked window, but with a > button next to the back arrow. That's the idea. To the final user, it should look like a title bar with an additional button. Otherwise it shouldn't make a difference. If it does then it's probably a bug :) Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Submenues in Fremantle
On Sat, Jul 04, 2009 at 08:58:14PM +0200, Till Harbaum / Lists wrote: > While i was pretty successful doing the first i still need a submenu > here and there. I found this example: > http://maemo.org/api_refs/5.0/beta/tutorial/html/ch10.html > using seperate windows for this. I think that example is not very correct, I'll try to have it updated. If you need to show more options when you select a menu entry, a dialog is probably a better choice. > I tried to use a seperate hildonappmenu via hildon_app_menu_popup, > but wasn't successful (just nothing pops up). I imagine you are using the beta SDK, there's a bug in HildonAppMenu that could make that fail. Still I think that it's better to use a dialog. Sorry for the delay, btw, I'm currently at the Gran Canaria Desktop Summit and the inet connection here is not very good. For those of you here in Gran Canaria, there are a few talks about Fremantle tomorrow, the first one is about the toolkit (by Claudio and me), but there are also talks about the window manager and the multimedia framework: http://www.grancanariadesktopsummit.org/node/271 Feel free to approach us for questions, comments, etc. Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: HildonWindow dimensions not updated on unfullscreen in Fremantle SDK beta
On Wed, Jul 01, 2009 at 05:57:20PM +0200, Luca Donaggio wrote: > But detecting when an event of type GDK_CONFIGURE has occurred > shouldn't be more correct? Ah, yes, if you only want to detect changes in the size of the window I think that should be enough :) Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: HildonWindow dimensions not updated on unfullscreen in Fremantle SDK beta
On Wed, Jul 01, 2009 at 03:40:08PM +0200, Luca Donaggio wrote: > I'm attaching a callback function to the expose event of my app > HildonWindow to detect size changes occurring after a screen > orientation change or a fullscreen / unfullscreen button press. 'expose' is generated when a part of the window becomes visible. For this case I think that you should use GdkScreen:size-changed to detect orientation changes and GtkWidget:window-state-event for fullscreen changes (see the documentation of gtk_window_fullscreen()). is_fs = (event->new_window_state & GDK_WINDOW_STATE_FULLSCREEN); Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Is the HildonAppMenu example correct?
On Sun, Jun 28, 2009 at 06:15:18PM +0200, Till Harbaum / Lists wrote: > fyi: There are examples at maemo.org at > http://maemo.org/api_refs/5.0/beta/tutorial/html/ch10.html > that don't have the "gtk_show_all()" call. Following your > statements, these examples are thus wrong. You're right, they have to be fixed. Thanks for pointing it out. Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Is the HildonAppMenu example correct?
On Fri, Jun 26, 2009 at 09:49:07PM +0200, Till Harbaum / Lists wrote: > i am using HildonAppMenu for the next release of gpxview. > I have followed these instructions: > > http://maemo.org/api_refs/5.0/beta/hildon/HildonAppMenu.html > > The problem: If i add a menu to a newly created stackable window > this way, i see the menus background being displayed for a fraction > of a second before the new window is being displayed. That's probably a bug the beta SDK, I can confirm that the example is correct using the latest libhildon version. > If i remove this > // Show all menu items > gtk_widget_show_all (GTK_WIDGET (menu)); > from the example, i don't have the annoying "ghost menu" being > displayed and the menu still works like it should. You have to explicitely show each menu item for it to appear when the menu pops up. gtk_widget_show_all() is the easiest and recommended way to do it. If the menu still appears after removing that call then the hildon version in the SDK is quite old. What's the version of libhildon that you're using? That bug should be fixed in 2.1.40. Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to top a maemo application if it's minimized?
On Sat, Jun 20, 2009 at 08:42:08PM +0800, Zhihai Wang wrote: > DBus method call will wake up an application and top it if this > application is not yet started. But if the application is already > started and minimized, it won't raise to top. > > One way to do this is to call hd_wm_top_service, but this API looks > more like one for other applications to use than one used in the > application itself. Have you tried with gtk_window_present() ? Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle UI Portrait Mode
On Fri, Jun 12, 2009 at 10:31:44AM +0200, Murray Cumming wrote: > > > All in all I think that the Gtk-API should be used more, but > > > that the rendering on the screen should just different from the > > > rendering on the desktop. > > We try to do that where possible. Sometimes it's just a matter > > of theming the widget correctly, but other times it requires > > significant changes to Gtk, and the maemo-Gtk maintainers try to > > keep it as close to upstream as possible, because maintaining a > > big fork is a hard task, but they can tell you better than me :) > It's easier now that GTK+ (and hildon) uses git. And the changes > could go upstream within a year, reducing the differences in > your fork. This happened for previous Maemo GTK+ additions: > http://live.gnome.org/Maemo/GtkContributions Moving these changes upstream is something that the maemo-gtk maintainers are already doing AFAIK. We all try to add to maemo-gtk all things that can go upstream. However the modifications you're talking about (changing the implementation of Gtk widgets so they look/behave differently while maintaining the same API) can't, by definition, be moved upstream :) Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle UI Portrait Mode
On Tue, Jun 02, 2009 at 08:09:36PM +0200, Cornelius Hald wrote: > this mail got a bit longer then I expected. And the reply took longer than I expected too :) Please accept my apologies. > I think most people who use filters and the portrait mode will have > to create a different version of the menu for portrait mode. In my > opinion there is just not enough space to put them in one row. Yes, that's probably true, but I think it'll happen to other parts of the UI as well. It's not easy to design an application that looks fine both in portrait and landscape with the UI unchanged (but I admit I'm not a UI designer) :) Wrt filters, you're right that it's harder to use them in portrait mode. The problem is that Fremantle was designed to be used mostly in landscape, with portrait being used in a few exceptional cases. > > Standard (Gtk) toolbars don't change, because I don't think > > there's a reliable and generic way to change their layout. [...] > > The same applies to many other widgets and the whole program UI > > in general (if it's going to support portrait mode it should be > > designed with that in mind). > Hmm... Well, I think the toolkit should do as much as possible for > the developer. If the developer wants to override all this magical > stuff, then there surely should be a way to do so. Well, I know what you mean but please understand that we have to focus on some very important bugs and having the basic stuff working right before adding those extra niceties :) > 1a) Introduce some kind of "important" property for widgets. Using > this, I could mark some of my buttons as important and thus the UI > would make sure that they are shown even in portrait mode. Buttons > or widgets without that flag could be omitted or put into a sub menu > if there is not enough space. This can be done very easily if you hide the "unimportant" options when the screen rotates. Connect to the "size-changed" signal and then call gtk_widget_hide() All other menu items will rearrange when you hide/show any of them. > 2a) Menus: Why not leaving the GtkMenu API like it is, but draw it > like the AppMenu? That was our initial plan, but due to several technical reasons we saw that it was not feasible and decided to create a different widget. > All in all I think that the Gtk-API should be used more, but that > the rendering on the screen should just different from the rendering > on the desktop. We try to do that where possible. Sometimes it's just a matter of theming the widget correctly, but other times it requires significant changes to Gtk, and the maemo-Gtk maintainers try to keep it as close to upstream as possible, because maintaining a big fork is a hard task, but they can tell you better than me :) Another thing is that legacy (i.e. pre-Fremantle) apps should look more or less the same (i.e., consistent within themselves). If we change the internals of many Gtk widgets to make them match the Fremantle UI style, old apps could look very weird. > If I remember correctly there was quite some effort for Maemo 4.0 to > remove own/specific API and replace them with existing API, now it > looks like we´re going into the other direction again. My personal opinion from what I can see is that Maemo 4 (and previous versions) had a UI style much closer to desktop apps, and Maemo 5 is VERY different in that sense. Implementing all the requires changes in Gtk while maintaining compatibility with previous versions is very very difficult. Or, in other words, making a desktop app that also looks like a Fremantle app with no changes in the code is basically impossible. Of course I admit that we could have made some mistakes, but believe me, we try to avoid creating new widgets unless it's necessary. > Thanks for reading! Thanks for writing :) and sorry again for the delay. Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Finger friendly context menu in Fremantle
On Wed, Jun 10, 2009 at 07:47:33PM +0200, Cornelius Hald wrote: > using hildon_gtk_menu_new() I can create a menu with finger friendly > sized menu items. > It works when I'm adding GtkMenuItems to this menu. But if I'm > adding GtkImageMenuItems the menu items have stylus size. For > example adding stock items produces a menu with small menu items. > > IMO that's a bug, but I thought before I'm making screenshots and > file a bug report, I'll ask if this is the expected behavior. I'm looking at the theme file and I think that should work, so if it doesn't then it's indeed a bug. Can you report it (with a small test case if possible) ? Thanks! :) Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle UI Portrait Mode
On Fri, May 29, 2009 at 11:07:32PM +0300, Henrik Hedberg wrote: > However, usually developer should not need to know mode but Hildon > widgets should adjust themselves as much as possible during the > relayout. Unfortunately that seems not to be the case, as Conny > demonstrated earlier with some screenshots. As Murray says, that's not always possible/feasible with all standard Gtk widgets. There is one (1) Hildon widget in Conny's screenshots and that one is already fixed. Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle UI Portrait Mode
On Fri, May 29, 2009 at 09:37:10PM +0200, Murray Cumming wrote: > > To detect screen orientation changes you can e.g. use the > > "size-changed" signal of GdkScreen. > This seems like a rather long-winded way to detect landscape or > portrait mode, requiring the hard coding of the dimensions. Why do you need the hard coding of the dimensions to know what's the page orientation? Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle UI Portrait Mode
On Fri, May 29, 2009 at 01:22:57PM +0200, Cornelius Hald wrote: > The AppMenu looks nice, only the Filters get crippled: > http://zwong.de/wp-content/uploads/2009/05/conboy_style_menu_portrait.png This is a bug (already fixed): in portrait, the menu will use the full width of the screen, so in your case I think that these buttons will look fine. Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle UI Portrait Mode
On Fri, May 29, 2009 at 01:48:54PM +0300, Kimmo Hämäläinen wrote: > AFAIK, there is automatic relayout only for confirmation dialogs > (and maybe application menu as you said), but not much more. So > toolbars you have to handle yourself. The toolkit people can give > better answers (I'm handling the hildon-desktop side). HildonAppMenu has automatic relayout. The number of columns changes from 2 to 1, and filters remain the same. If really necessary, you can also have a different menu for portrait mode, hide some of its items or change some of their labels. Standard (Gtk) toolbars don't change, because I don't think there's a reliable and generic way to change their layout. If a particular toolbar doesn't look good in portrait mode because it has too many items, it's IMHO the app -not the toolkit- that should take care of this. The same applies to many other widgets and the whole program UI in general (if it's going to support portrait mode it should be designed with that in mind). Edit-mode toolbars (HildonEditToolbar) look fine in portrait mode. Again, if the label is too long for portrait the app can change it. To detect screen orientation changes you can e.g. use the "size-changed" signal of GdkScreen. > > * Is there a function to change the screen orientation and can we > > somehow use this with the beta SDK? hildon_gtk_window_set_portrait_flags (window, HILDON_PORTRAIT_MODE_REQUEST | HILDON_PORTRAIT_MODE_SUPPORT); Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: GtkAction vs. AppMenu
On Thu, May 28, 2009 at 04:30:10PM +0200, Cornelius Hald wrote: > > > The implementation can be changed, we're in beta and that means > > > that things can still be fixed. > > No, Beta generally means that API and UI changes are no longer > > possible. And I think that's the case with Maemo 5. > Could someone please clarify that? > We all know that Maemo 5 is currently in Beta state, but does this > mean that API and/or UI changes are still allowed or not? Well, I'm one of the Hildon developers and I can tell you that we _do_ accept suggestions :-) Of course we have some constraints and we can't change everything that we want, but if the change that you propose is feasible it'll be considered. We also accept patches ;-) Feel free to open bugs in https://bugs.maemo.org/ with your suggestions. Thanks! Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: AppMenu, Filters and HIG
On Mon, May 25, 2009 at 10:50:54PM +0200, Claudio Saavedra wrote: > This is the purpose of filters, but you might need to find strings > that fit well in the menu. Another option, if you don't find a good way to put all filters there, is to use a "Change sort criteria" button and pop all available options using a touch selector. Look at HildonTouchSelector, HildonPickerDialog and HildonPickerButton Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: GtkAction vs. AppMenu
On Sun, May 24, 2009 at 07:58:26PM +0200, Cornelius Hald wrote: > Thanks Berto for all the good input and for explaining the decisions > that have been made. Thank you for your feedback :) > Another thing is, that if you compare those two menus, you can > easily see that the Diablo menu has more structure due to the use > of separators. I'm not yet sure how to get back this structure, but > I'll make some experiments. HIG suggestions are welcome as well :) I'd like to write a longer e-mail about this, but the basic thing is that the Fremantle menu is purposely different from GtkMenu. HildonAppMenu has a limited number of options and there are no separators or submenus. It is designed to be like that. This means that in many cases you won't be able to simply convert it: it has to be redesigned. Show the user a few options and use e.g. dialogs for further details/configuration. Buttons and dialogs in Fremantle are designed to be big and finger-friendly so the user should be able to use them easily. Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: GtkAction vs. AppMenu
On Mon, May 25, 2009 at 06:19:35PM +0200, Cornelius Hald wrote: > I just tried that, and indeed using hildon_app_menu_add_filter() > groups the toggle buttons together into one row. Yes, that's the purpose of that function. As you say, only one filter group is supported, but that's by design. Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: GtkAction vs. AppMenu
On Sun, May 24, 2009 at 01:48:11PM +0200, Murray Cumming wrote: > However, I'm was asking about the API and implementation, because > the Fremantle UI guidelines are really out of our control at this > point. The implementation can be changed, we're in beta and that means that things can still be fixed. I think that the proper place to discuss this is the Maemo bugzilla, so can you please file a bug against Gtk? https://bugs.maemo.org/enter_bug.cgi?product=Desktop%20platform Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: GtkAction vs. AppMenu
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
Re: GtkAction vs. AppMenu
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
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: GtkAction vs. AppMenu
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
On Fri, May 22, 2009 at 05:08:08PM +0200, Cornelius Hald wrote:
> The result now is:
> - gtk_toggle_button_new() is working but it displays the buttons as
> toggle buttons not as radio buttons.
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);
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).
Berto
#include
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)
{
g_debug ("Button clicked: %s", gtk_action_get_name (action));
}
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 *
create_menu (GtkAccelGroup *accel)
{
HildonAppMenu *menu = HILDON_APP_MENU (hildon_app_menu_new ());
GtkActionGroup *group = gtk_action_group_new ("actiongroup");
GtkAction *action;
GtkRadioAction *radioaction;
/* Items */
action = create_action ("Action one", "1", group, accel);
hildon_app_menu_append (menu, create_item (action));
action = create_action ("Action two", "2", group, accel);
hildon_app_menu_append (menu, create_item (action));
action = create_action ("Action three", "3", group, accel);
hildon_app_menu_append (menu, create_item (action));
action = create_action ("Action four", "4", group, accel);
hildon_app_menu_append (menu, create_item (action));
/* Filters */
radioaction = create_radio_action ("Radio one", NULL);
g_signal_connect (radioaction, "changed", G_CALLBACK (radio_action_changed), NULL);
gtk_toggle_action_set_active (GTK_TOGGLE_ACTION (radioaction), TRUE);
hildon_app_menu_add_filter (menu, create_radio_item (radioaction));
radioaction = create_radio_action ("Radio two", radioaction);
hildon_app_menu_add_filter (menu, create_radio_item (radioaction));
radioaction = create_radio_action ("Radio three", radioaction);
hildon_app_menu_add_filter (menu, create_radio_item (radioaction));
gtk_widget_show_all (GTK_WIDGET (menu));
return menu;
}
int
main(int argc,
char **argv)
{
GtkWidget *win;
GtkWidget *label;
HildonAppMenu *menu;
GtkAccelGroup *accel;
hildon_gtk_init (&argc, &argv);
label = gtk_label_new ("This is an example of the\nHildonAppMenu widget.\n\n"
"Click on the titlebar\nto pop up the menu.");
gtk_label_set_justify (GTK_LABEL (label), GTK_JUSTIFY_CENTER);
win = hildon_stackable_window_new ();
accel = gtk_accel_group_new ();
menu = create_menu (accel);
hildon_window_set_app_menu (HILDON_WINDOW (win), menu);
gtk_window_add_accel_group (GTK_WINDOW (
Re: GtkAction vs. AppMenu
On Fri, May 22, 2009 at 03:24:01PM +0200, Cornelius Hald wrote:
> But so that you don't have to read through this big and ugly file,
> I'll try to outline what I do with one of the actions. Casts etc.
> are removed to make it less cluttered:
>
> action = gtk_toggle_action_new("bold", "Bold", NULL, GTK_STOCK_BOLD));
> gtk_action_set_accel_group(action, accel_group);
> gtk_action_set_accel_path(action, ACCEL_PATH_STYLE_BOLD);
> gtk_accel_map_add_entry(ACCEL_PATH_STYLE_BOLD, GDK_b, GDK_CONTROL_MASK);
[...]
Try also this:
gtk_window_add_accel_group (window, accel);
(with window being the GtkWindow where the app menu is)
> > Try using gtk_radio_button_new_from_widget () to create all
> > buttons after the first one.
>
> I'll tried in three different ways with different outcomes.
> Unfortunately non of them was good :(
Look at the correction I sent in a subsequent e-mail: try using
gtk_toggle_button_new() instead of gtk_radio_button_*()
Berto
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: GtkAction vs. AppMenu
On Thu, May 21, 2009 at 05:28:35PM +0200, Alberto Garcia wrote: Correction: > > 2) How do I get my GtkRadioActions to work with > > the HildonAppMenu? I created the the buttons with > > gtk_radio_button_new() Well, actually in this case you should probably use gtk_toggle_button_new() instead (GtkRadioAction will make sure that only one is enabled). Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: GtkAction vs. AppMenu
On Tue, May 19, 2009 at 05:24:47PM +0200, Cornelius Hald wrote: First of all, sorry for the delay :) > 1) The accelerators of my actions don't show up on the menu > buttons and they don't work. What do I have to do to get them > back? If I create an old school GtkMenuItem out of my GtkAction the > accelerators are working fine. They are not supposed to show up, but they should work. I've just tested it here and it works fine. If you can send your test case I can take a look at it. > 2) How do I get my GtkRadioActions to work with the HildonAppMenu? I > created the the buttons with gtk_radio_button_new() and then used > gtk_action_connect_proxy() like with the normal GtkActions above. > The problem is that now all of the radio buttons are selected active > at the same time. Try using gtk_radio_button_new_from_widget () to create all buttons after the first one. Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle user interface behaviour and API
On Thu, May 21, 2009 at 12:57:00PM +0200, Cornelius Hald wrote: > But then, what is the recommend way to produce a finger friendly > text view that is editable and scrollable/panable? [...] I thought > that panning/selecting would probably work like in the Diablo > webbrowser. That is, that you start a selection with a double tap. In principle that feature is not officially supported in Fremantle, and adding support in HildonTextView might create inconsistencies between similar-looking apps/dialogs that could be quite confusing. But of course we can reconsider it (I don't have the last word, though). I'll see what we can do. Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Aw: Re: Fremantle user interface behaviour and API
On Tue, May 19, 2009 at 04:51:47PM +0200, Cornelius Hald wrote: > When using HildonTextView inside a PanableArea panning is working > fine, but I can no longer select text. Are those two mutual > exclusive? In HildonTextView you cannot select text with the pointer. This is so by design: https://git.maemo.org/projects/hildon/gitweb?p=hildon;a=commit;h=b34c64c879c7e86488adbe8000f2f3f2be162a73 I think that with both features enabled user interaction can be quite difficult/confusing if e.g. there's a big text view occupying a significant part of the screen. Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to press "enter" inside the Fremantle SDK
On Tue, May 19, 2009 at 05:30:53PM +0200, Cornelius Hald wrote: > > Use the enter key from the numeric keypad (or use NumLock if your > > computer doesn't have a one). > Ahhh thank you very much - that explains a lot :) I never really > figured out how to make NumLock work on my Thinkpad. If you have a ThinkPad, press Fn+NumLock and the "NumLock" LED should be turned on. Now if you press the enter key it will act like the one from the numeric keypad. Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to press "enter" inside the Fremantle SDK
On Tue, May 19, 2009 at 04:58:44PM +0200, Cornelius Hald wrote: > when using the Fremantle SDK I'm having problems pressing the > enter-key. If I press the enter-key on my keyboard nothing is > happening. I have the same behavior with the Diablo SDK but there > the workaround for me was to press the enter-key on the virtual > keyboard using the mouse. Now that there is no virtual keyboard > anymore I'm having a problem :( Use the enter key from the numeric keypad (or use NumLock if your computer doesn't have a one). This is valid for the Diablo SDK too (the enter key on the N810 is mapped to GDK_KP_Enter rather than to GDK_Return). Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: how to use hildon_banner_show_progress()
On Fri, May 08, 2009 at 04:27:27PM +0300, Claudio Saavedra wrote: > Banners are temporary windows, meaning they will be closed when > other non temporary windows are shown. Note that this is not true anymore in Maemo 2.2: https://git.maemo.org/projects/hildon/gitweb?p=hildon;a=commitdiff;h=558f9bc4 Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: GtkAction vs. AppMenu
On Wed, Apr 29, 2009 at 07:37:03PM +0200, Cornelius Hald wrote: > Or is it possible to create a GtkButton out of a GtkAction? Try this: button = gtk_button_new (); gtk_action_connect_proxy (action, button); Berto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: scratchbox ide
On Tue, Jan 20, 2009 at 11:26:39AM -0600, Frank Banul wrote: > I've got scratchbox installed on an Ubuntu host for compiling tablet > programs. > > I'm curious what development tools you use? Textedit is nice and all > but I'm sure that there are better tools. I would be interested in > an editor that supported more code oriented tasks. Any suggestions? If you use Emacs you can use it outside scratchbox with all its power but configure it to compile inside Scratchbox: http://djcbflux.blogspot.com/2007/12/maemacs.html -- Alberto García González http://people.igalia.com/berto/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Using libcurl in a proxy setup?
On Thu, Nov 06, 2008 at 11:20:24AM +0100, Till Harbaum wrote: > i am not sure how to correctly handle a proxy based setting when > using libcurl under maemo. libconic is your friend here: http://maemo.org/api_refs/4.0/libconic/index.html -- Alberto García González http://people.igalia.com/berto/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Disable auto uppercase on input?
On Tue, Nov 04, 2008 at 08:26:42PM +0100, Till Harbaum / Lists wrote: > i know that this auto uppercase for the first letter can be disabled > in the control panel. But how do i disable this from my program? http://maemo.org/api_refs/4.0/gtk/GtkEntry.html#hildon-gtk-entry-set-input-mode http://maemo.org/api_refs/4.0/gtk/GtkIMContext.html#HildonGtkInputMode GtkWidget *entry = gtk_entry_new (); hildon_gtk_entry_set_input_mode (GTK_ENTRY (entry), HILDON_GTK_INPUT_MODE_FULL); -- Alberto García González http://people.igalia.com/berto/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Can't configure a sample project in Maemo 4.1.1
On Fri, Oct 17, 2008 at 05:48:13AM -0700, Sarah Newman wrote: > You want libosso-email-interface-dev. Try 'apt-cache search' with a > subset of the lib name maybe (not the exact name libxyz.) > > 'apt-get build-dep <>' will help you resolve build dependencies for > known packages. Besides that, you'll also need intltool: > > + intltoolize --automake --copy --force > > ./autogen.sh: line 6: intltoolize: command not found Install the 'doctools' devkit in the target (with sb-menu) -- Alberto García González http://people.igalia.com/berto/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: GtkPixbuf from Char buffer
On Thu, Oct 16, 2008 at 05:12:40PM +0300, Arto Karppinen wrote: > Hi, were developing an application which is supposed to show user > images downloaded from web server using xmlrpc. The problem is that > we cant quite figure out how to create a pixbuf from a buffer which > contains the RAW contents of a file. You can use GdkPixbufLoader to do that. A sample implementation here (function get_pixbuf_from_image()): https://garage.maemo.org/plugins/scmsvn/viewcvs.php/trunk/src/util.c?root=vagalume&view=markup -- Alberto García González http://people.igalia.com/berto/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Autobuilder for OS2006 wanted?
On Tue, Aug 05, 2008 at 10:58:45AM +0200, Niels Breet wrote: > With this mail, I want to ask the community if there is interest in > having an autobuilder for OS2006. > > Although the download numbers for OS2006 aren't as high as the > recent OS versions, we (maemo.org community) haven't stopped > supporting the OS. 770 users might benefit from this. > > Are there developers out there who will use the autobuilder for > OS2006, if it is available? Do you think it is worth the trouble to > set it up? Will it make supporting OS2006 easier for developers? > > Please let me know what you think. If there are many people interested in it I will use it, but I'm not missing it. -- Alberto García González http://people.igalia.com/berto/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Too many categories in Application Manager
On Fri, Jun 27, 2008 at 08:46:42PM +0200, Andrea Grandi wrote: > > I think that the problem is that categories are defined by > > application developers (Section: field in the debian/control > > file). > > yes, you're right. With my mail I did mean: can we decide some > general rules that every developer/packager have to follow before > choosing the category? We have a list of categories, actually: http://maemo.org/maemo_release_documentation/maemo4.1.x/node14.html#SECTION001426000 We could enforce developers to use one of those for their packages to appear in maemo extras ... -- Alberto García González http://people.igalia.com/berto/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Too many categories in Application Manager
On Fri, Jun 27, 2008 at 07:10:37PM +0200, Andrea Grandi wrote: > I noticed a "bad" thing since a lot of time. Application Manager (or > better, packages) has a lot of unusefull categories. For example: > Utilities, utilities, utils ecc... > What do you think about organize them better to have less categories? > It would be more clear for the end user. I think that the problem is that categories are defined by application developers (Section: field in the debian/control file). -- Alberto García González http://people.igalia.com/berto/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Rebuild all chinook source packages on autobuilder
On Tue, Jun 17, 2008 at 11:33:43AM -0500, Frank Banul wrote: > So if your package is failing due to missing dependencies, how does > one map the package check to Build-Depends? If I understood your question correctly, dpkg-genbuilddeps might help -- Alberto García González http://people.igalia.com/berto/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo Downloads - downloads count went very high..
On Thu, May 22, 2008 at 03:51:50PM +0200, Aniello Del Sorbo wrote: > What happened to the Maemo Download counts ? > > It was very low as for few days ago and today I see thousands of > downloads ? Even my Xournal port skyrocketed from less then 3000 to > over 5000, but this is nothing compared to other popular downloads > that 'feature' downloads of the order of 10 thousands! And Vagalume went from ~4000 down to 800 !! X'D -- Alberto García González http://people.igalia.com/berto/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: application closes after sometime ..any guess why?
On Fri, Feb 29, 2008 at 12:42:53PM -0800, Tripti Gupta wrote: > I have made a simple application for N800. My application closes on > its own after sometime.. can anyone guess the reason behind? Yes, read this: http://maemo.org/development/documentation/tutorials/maemo_4-0_tutorial.html#Maemo-Initialization -- Alberto García González http://people.igalia.com/berto/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to detect Maemo in automake?
On Thu, Feb 21, 2008 at 11:15:31AM +0100, Marcin Juszkiewicz wrote: > I wonder why this is really needed... If application is for Maemo > then it use its libraries (libosso, libhildon) and should check for > those libraries not for scratchbox. Yeah, but if your desktop PC happens to have libosso installed (it's included in Debian) then autoconf will detect that you're compiling for Maemo. In my case compiling for Maemo means compiling using the Maemo SDK (and probably for the Nokia 770/N800/N810). And scratchbox seems to be the official way to use the Maemo SDK. Anyway that was only an example that I think is probably good enough for most cases. If not, just pass the --enable-maemo switch to override autodetection and that's it :) -- Alberto García González http://people.igalia.com/berto/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to detect Maemo in automake?
On Wed, Feb 20, 2008 at 02:29:18PM +, Ross Burton wrote: > What if I want a "maemo" build on Ubuntu Mobile, or any other > system which has the Maemo stack? It's best to make it explicit at > configure time because having too much magic means it breaks if your > assumptions fail. Indeed, but you can just make a basic detection based on the platforms your app is designed for and let the user override it with a configure switch. -- Alberto García González http://people.igalia.com/berto/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to detect Maemo in automake?
On Wed, Feb 20, 2008 at 02:00:50PM +, Ross Burton wrote: > > > Now for my next question: How do i detect maemo correctly in > > > autoconf? > > One way is: > > AC_ARG_ENABLE(maemo,[ --enable-maemo Enable > > Maemo-specific build options], > >[enable_maemo=true], > You mean something like this: > > AC_ARG_ENABLE(maemo, > AS_HELP_STRING([--enable-maemo],[enable Maemo-specific features]), > [], > enable_maemo=no) > if test x"$enable_maemo" = xyes; then > ... > fi I think that he meant how to *detect* Maemo (i.e, without having to ask the user). I used to check for the existence of libosso, but since it's available in Debian (http://packages.debian.org/libosso) I'm also checking whether we're running inside the scratchbox, so you could use something like this: if $PKG_CONFIG --exists libosso && readlink /etc|grep -q ^/targets; then DETECTED_PLATFORM=maemo fi If there's an "official" way (or just a better one) to detect if we're compiling for Maemo I'd like to know. -- Alberto García González http://people.igalia.com/berto/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
