Re: Gtk background pixmap style for button widget
On Mon, 2010-08-09 at 00:49 -0400, Tim Niemueller wrote:
Hi.
I have a question specific to Gtk(mm) programming for Maemo 5. In a
dialog of an application I would like to mark one of the buttons green,
like the call button in the call UI. I have found the appropriate images
in /etc/hildon/theme/images (e.g. AcceptFingerButtonNormal.png).
I'm trying to set those images with Gtk::Widget::modify_bg_pixmap() to
change the draw style. But this does not have any effect. Running the
program with strace shows that the file is indeed successfully opened.
Short answer: you should name your button
hildon-accept-button-{finger,thumb}, so that the theming engine itself
picks the right graphics (look into the gtkrc file to understand why
this). Choose one between finger or thumb to get the properly sized
image. The one you mention is only gonna work OK with finger size
buttons.
For naming the widget, you can use gtk_widget_set_name(). I'm not sure
of the gtkmm equivalent but I suspect it should be GtkButton::set_name()
Claudio
___
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, 2010-06-03 at 12:39 +0300, Felipe Contreras wrote: Ah, I didn't reply: 1. No now-playing notification Not a blocker IMO. That's *your* opinion. For me, moving to a library that causes loss of functionality is a no-go unless there are very good reasons to do it, which was not the case, IMO. In fact at least last.fm seems to understand just fine that the last scrobbled song is Now Playing due to the timestamp. So I fail to see what functionality users will miss. Not really. A very recently scrobbled track will be displayed as Just played. The only way to display a track as now playing is through the now playing notification. 2. No scrobbling right after the track has finished. I'm not sure what that means, but if it's related to the fact that I decided to scrobble songs each 10 minutes. First, I told you that it's not a limitation of libscroble, it's up to the client (maemo-scrobbler/mafw-lastfm) to call sr_session_submit() when it sees fit[1]. And second, I changed maemo-scrobbled back in January to do what you wanted[2]. Also, in the pathches for libscrobble I sent I called sr_session_submit() right after metadata_callback(). Therefore, as I mentioned, there's no change. Well, it makes a huge difference to know when a problem doesn't exist anymore. You could have said this back then when I commented it, but it seems you were expecting me to follow your progress or dig into your code just because you deserve it. I haven't worked on this yet, because I was fixing other issues that were more important. I list them below, even when I am sure that you know already. Yes, and I don't agree with the priorities. To me, as a user, I don't care if I cannot scrobble from certain proxified connections to last.fm, because even if I do, it would only be to last.fm. But *you* are not the average user, so please excuse me for not following your needs to set my priorities. After all, you've shown enough skills to supply for your needs yourself :) So, mafw-lastfm provides at best 50% of what I need (more like 40%); that's not acceptable. Not acceptable for *you*. It's perfectly fine if you disagree on what's necessary or not for a piece of software, just please don't come to me telling me what I need to focus on just because something doesn't work as you expect it. I have fixed all the issues with the network handling for at least a month now (these were released in 0.0.5). Well, that's easy to say. I would need to review the code to even be slightly confident that that's true. And of course, even if I don't see any problems... that's not a guarantee that _all_ the problems are fixed. Do you really want to go into this sort of non-constructive debate? I don't. And I obviously meant that I fixed all issues known. And that no new issues have arose since then. I also implemented support for scrobbling behind proxies[1], which is in a branch in gitorious waiting to get some testing from users. Yes, as I said before, I don't think that's important. That's, once again, *your* opinion. I'll kindly ask you to please stop pretending I should treat it specially, just because you can write some code. I have also implemented permanent storage during last week and it's working fine. I am planning to do a release including this during this week, but I was waiting for some translations to come in first [2]. Perhaps it's working fine, or perhaps it has issues with UTF-8, or perhaps (quite likely) it's implemented in a non-extensible way which would require many changes once multi-scrobbling is supported. I can tell you from experience that the latter is quite likely. Yes, perhaps a lot of things. What is your goal with this speculative arguing? UTF-8 is working fine, since I soup_uri_escape() tracks' data before serializing it. If changes are required to support multiscrobbling, then changes will be made then, I fail to see what's your point here, other than to speculate for the sake of doing it. In any case, you _knew_ libscrobbler supported this, and yet, instead of adding the missing features to libscrobbler, you decided to implement this yourself. 4) Video clips are ignored Small feature, but important. In the same email I link above, I replied to you that I wasn't against implementing this if there was broader interest from users. Since I didn't get much more feedback on this regard it was low in my priorities. Well, I saw many more users asking for this than proxy support. Proxy support is a feature that is not debatable (meaning, no one would argue whether it's needed or not). Not scrobbling videos is debatable. Therefore I decided to implement first what's non debatable, waiting for more input in other stuff before moving. I don't how to take this. Unfortunately, I was waiting for your feedback on my comments. I apologize if you were expecting something different. Yes, I forgot to reply to your last
Re: [mafw-lastfm-devel] [ANN] maemo-scrobber 1.0 for last.fm + libre.fm
Felipe, Allow me to reply starting from one of your last your statements: On Thu, 2010-06-03 at 03:46 +0300, Felipe Contreras wrote: We are now in June and I haven't heard anything. This is just not true. To your inquire back in April, this is what I replied: https://garage.maemo.org/pipermail/mafw-lastfm-devel/2010-April/77.html I thought you'd follow up with what I commented as the two main reasons why I didn't consider libscrobble at that point yet, but since you didn't I just continued fixing issues in my code as time allowed. 1) Support for multi-scrobbling (both last.fm and libre.fm at the same time) Includes a song queue per service. I haven't worked on this yet, because I was fixing other issues that were more important. I list them below, even when I am sure that you know already. 2) Improved song queue handling Since internally it uses libscrobble (which is independent of MAFW), the important code can be easily tested on desktop sw, and it has been done so… throughly. It doesn’t matter how flaky your network is, or that the servers are down, the songs will be submitted. I have fixed all the issues with the network handling for at least a month now (these were released in 0.0.5). I also implemented support for scrobbling behind proxies[1], which is in a branch in gitorious waiting to get some testing from users. 3) Permanent storage The song queue is not lost, even on crashes, device reboots, or software updates. I have also implemented permanent storage during last week and it's working fine. I am planning to do a release including this during this week, but I was waiting for some translations to come in first [2]. 4) Video clips are ignored Small feature, but important. In the same email I link above, I replied to you that I wasn't against implementing this if there was broader interest from users. Since I didn't get much more feedback on this regard it was low in my priorities. [...] Then I brought up all the problems to the mailing list [1], and I tried to contribute to mafw-lastfm [2], some trivial patches got in, but the important ones [3] did not. That was back in February, and at that point Claudio (the maintainer) decided to wait until a stable release (0.0.4), which was done in April. We are now in June and I haven't heard anything. Well, as I said already, I told you clearly what were my concerns regarding libscrobble. Instead of following up on the discussion, you preferred to go your own way and implement yet another scrobbler. Good on you. So I decided to implement the missing pieces and provide what IMO is supperior software (at the very least it does what I need, and hopefully you would like it too). I don't how to take this. Unfortunately, I was waiting for your feedback on my comments. I apologize if you were expecting something different. I don't know if it was necessary for you to go your own way and implement your own scrobbler, but in the end it's up to you. In a normal case I'd be glad to see alternative software, because competition is healthy, but in this case I find it a bit ridiculous – it's such a small software that it barely makes sense to offer people two different ones that in the end will obviously do the same. But that's your way, and you're free to do it. Claudio [1] https://bugs.maemo.org/show_bug.cgi?id=9966 [2] https://garage.maemo.org/pipermail/mafw-lastfm-devel/2010-June/000106.html ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: GTK+ question with maemo 2.2
On Sun, May 23, 2010 at 10:34:44AM +0300, Daniil Ivanov wrote: Hi Han! You will need Gtk 2.12 at least. Note that Gtk in Maemo is patched, thus, you must apply the same set of patches to newer version of Gtk to make it work with Maemo 2.2. Not only that, but if you plan to distribute your program you'll need to find a way to distribute this GTK+ version as well. I don't think this will end up being an easy task. Claudio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: python getting active hildon.TextView()
On Mon, 2010-04-26 at 19:18 +0300, pelt...@gmail.com wrote: Hi Is there a way to know which textview is active (where the cursor blinks)? Didn't manage to find anything within python docs. Is it only my search skills? You actually want to answer a more general question: which of the widgets in my window currently has the focus? For that, you can use gtk_window_get_focus (). Claudio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: N900 / Media Player / Random play really random?
El jue, 25-03-2010 a las 15:27 -0400, ianaré sévi escribió: But one way to avoid it would be to keep a record of which songs were played _between_ sessions, and not play them again untill all songs are played. Just don't push shuffle all songs and go directly to the playlist view. Claudio ps: isn't this a topic for maemo-users? ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: HildonTouchSelector and visible rows
El lun, 15-03-2010 a las 10:13 +0100, Nicolai Hess escribió: Hi, I made a home widget for maemo5. The settings dialog should show a HildonTouchSelector with some entries where the use can select one. I don't know how to configure HildonTouchSelector to make more than one row visible. At the moment the dialog (created with gtk_dialog_new_with_buttons) shows one button, to confirm selection, on the right side and only one row of the HildonTouchSelector on the left side. Try with HildonPickerDialog. It's specially meant to be used with a touchselector. There are plenty of examples in the hildon-examples package, as well. Claudio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Why touch event go through my window
You first commented: El sáb, 06-02-2010 a las 23:53 +0800, Evan JIANG escribió: My panel is created with gtk_window_new (GTK_WINDOW_POPUP); And then said: El mar, 16-02-2010 a las 01:06 +0800, Evan JIANG escribió: gtk_window_set_type_hint (GTK_WINDOW (_input_window), GDK_WINDOW_TYPE_HINT_DIALOG); Why do you need to mess with the window types so much? Can you try simplifying that? Claudio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Finger-Friendly Entry Completion/ComboboxEntry
El lun, 18-01-2010 a las 20:30 -0500, Brent Chiodo escribió: I have to give a bump to this. Does anyone know the secret behind the browser URL bar? Is the code even posted somewhere (Not sure, is that part of the browser open source?). There is no such combobox/comboboxentry in the toolkit. What you see in the browser is something they implemented themselves. As far as I know, the code is not open. The reason why you don't have such a widget available is that, for Maemo 5, we support and encourage the usage of the new Fremantle widgets. For any use case where a combobox is necessary, you have HildonPickerButton. If a combobox with entry is necessary, you have HildonPickerButton + HildonTouchSelectorEntry. Claudio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Garage mailing lists still down?
El mar, 19-01-2010 a las 16:55 +0200, Ferenc Szekely escribió: I wonder if the garage mailing lists are still offline due to the server migration? I remember reading that the maemo.org mailing lists were migrated some time ago, but how about the garage ones? I made requests for a DNS change and an SMTP server config change. After these we should be able to send mails to lists hosted on garage.maemo.org. May I ask why these kind of changes are not notified in advance? Claudio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Garage mailing lists still down?
El mar, 19-01-2010 a las 17:00 +0200, Ferenc Szekely escribió: May I ask why these kind of changes are not notified in advance? Because I forgot to request them. What I'm asking is why we, the users of these services, are not notified in advance of the downtime of services. I think that if we want to provide third-party developers with a service they can rely on, we should be telling them in advance, when these will be down. If services go down without notice, you just harm the sense of reliability that users have of them. That's not good for garage. Claudio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: GtkTreeView behaviour
El mié, 13-01-2010 a las 15:16 +0100, Piñeiro escribió: I have just check the documentation on hildon_pannable_area_add_with_viewport, and this is not mentioned, just assumed. Probably it would be a good idea to mention it, and also add a hint to the gtk_scrolled_window_add_with_viewport for extra information. Done, thanks! Please cherry pick into hildon-2-2. Claudio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
builder: gzip: stdin: invalid compressed data--crc error
Any idea what does this mean? The package built fine for armel.. https://garage.maemo.org/builder/fremantle/mafw-lastfm_0.0.3-1/i386.root.log.FAILED.txt Claudio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Drag Drop on GTK + Maemo 5 (was: Re: [pymaemo] DnD on N900)
El mié, 06-01-2010 a las 19:44 -0400, Anderson Lizardo escribió: [I'm CC'ing maemo-developers as it is clearly not a Python specific issue; see below for details] On Wed, Jan 6, 2010 at 2:11 PM, Jeffrey Barish jeff_bar...@earthlink.net wrote: Well, it took a little more than a few days, but here is a test program. It works on Ubuntu and N810, but not N900. Well, I tested your example on Maemo and Ubuntu, and indeed the drag drop only worked on Ubuntu. Additionally, this error is shown on console: /tmp/dndtest.py:77: Warning: g_object_set_data_full: assertion `G_IS_OBJECT (object)' failed gtk.main() So I went further and translated your example to C (please note I'm no GTK expert, I'm only trying to help debugging the problem). And the same behavior is presented: the drag does not work and this message is shown on console: dndtest[9349]: GLIB CRITICAL ** GLib-GObject - g_object_set_data_full: assertion `G_IS_OBJECT (object)' failed That means the problem is not related to Python or PyGTK at all, but some GTK limitation/bug on Maemo 5. There is no drag 'n drop in Maemo GTK+. This has been deliberately disabled. A stacktrace on the critical warning would be useful to find out the cause. Claudio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Drag Drop on GTK + Maemo 5 (was: Re: [pymaemo] DnD on N900)
El jue, 07-01-2010 a las 10:08 -0400, Anderson Lizardo escribió: On Thu, Jan 7, 2010 at 5:37 AM, Claudio Saavedra csaave...@igalia.com wrote: There is no drag 'n drop in Maemo GTK+. This has been deliberately disabled. I believe that pretty much answers Jeff's issue... Was this done for Maemo 5 ? Because according to Jeff it used to work on the N810 (Diablo). I haven't tested it myself on N810 , though. Yes, only since Maemo 5. A stacktrace on the critical warning would be useful to find out the cause. How to get that stack trace (some glib/gtk function?) ? it does not crash the application , so I think gdb cannot be used in this case. Set G_DEBUG=fatal-criticals. That will cause glib to abort on a critical warning. Claudio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Where to find sources of gtk+ 2:2.14.7-1maemo15?
El sáb, 02-01-2010 a las 07:22 +0100, Marcin Juszkiewicz escribió: Hi Maemo5 repository contains sources of GTK+ 2.14.17-1maemo12 but newest hildon-desktop requires maemo15 version (crashes with maemo12 in SDK). Where I can find development tree with Maemo5 gtk+? Regards, For others to know: https://stage.maemo.org/svn/maemo/projects/haf/trunk/gtk+/ https://stage.maemo.org/svn/maemo/projects/haf/tags/gtk+/ Claudio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: gtk clutter tearing
El mar, 29-12-2009 a las 17:17 +0200, Eero Tamminen escribió: This is not really fixable due to how Gtk painting is arranged, parts of the window are painted in application callbacks. This is not totally correct. Application callbacks can only cause GTK+ to *invalidate* regions. In sane code, redrawing *never* happens in a user callback but only in expose event callbacks, which are triggered by GTK+ *only* when the time for redrawing comes. Nevertheless, there are still issues with GTK+ and synchronization of events. See [1] and [2] for a good explanation of these. Claudio [1] http://blog.fishsoup.net/2009/05/28/frames-not-idles/ [2] http://blog.fishsoup.net/2009/06/02/timing-frame-display/ ___ 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
El mar, 08-12-2009 a las 22:27 +0200, Claudio Saavedra escribió: 1) How can I start it automatically without having to start it manually? It should do already, after installation, and on the session start (after the X session is ready). it didn't after installation, but it did after a device restart It's odd, but it works fine if you install the package by hand. I'll have to look into this. The problem was not running dsmetool through run-standalone.sh. The process was starting, but it was failing to initialize mafw-shared. I pushed a new package to extras-devel. This installs fine with ham. Claudio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Debug info on device
El mar, 15-12-2009 a las 23:14 +, Thomas Troy escribió: Hi, I'm wondering is there a way to get debug information from a g_debug call when running your app on the device? Is it output to a specific log file or do I have to set something to get it working? I had assumed that running from xterm would show it but that isn't working If I'm not mistaken, all that info will go into the syslog. But in production devices there's no sysklogd. You should install it from the development tools repository. http://wiki.maemo.org/Documentation/devtools/maemo5 Claudio ___ 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
El mar, 08-12-2009 a las 21:20 +0100, Andrea Grandi escribió: Hi, another idea: what about displaying Listening with Nokia N900 instead of Listening with mafw-lastfm ? If you can prove that there's no legal issue with using the 'Nokia N900' brand with a third party application, maybe. Still, mafw-lastfm should work with any other device using mafw, so restricting it's app id only to the 'Nokia N900' now is not something I would like, at least not for the long term. Of course, I could request other application ids, one for each supported device. Not sure if it's worth the burden. Unless users really care to show off that they own a N900, or a whatever device is released in the future. Claudio ___ 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
El mié, 09-12-2009 a las 10:30 +0200, Riku Voipio escribió: ext Claudio Saavedra wrote: El mar, 08-12-2009 a las 17:50 +, Graham Cobb escribió: On Tuesday 08 December 2009 17:23:15 Claudio Saavedra wrote: I noticed that the postinst script was missing the debhelper token used by dh_installxsession to plug its magic. Now the Xsession script should be installed properly. What is dh_installxsession? I can't find any documentation on it. Probably looking in the wrong place! It's part of upstart-dev. I don't know where it's documented, though. I simply looked at hildon-desktop and some other modules' packages. It is not really necessary/recommended to use it anymore. One can just copy the startup script into /etc/X11/Xession.post like one would do to any file in /etc. Same is true to dh_installupstart. OK, roger that. I'll change it for future releases. I guess there are plenty of packages still using dh_installxsession, though. But why does mafw-lastfm need to start at boot time and keep running all the time? Is it not possible to make it start/stop when playback stops/starts? I am not 100% sure that's feasible, since it's separate process communicated with mafw through libmafw-shared. I don't think mafw has any way to start/stop processes on demand that would fit this. And I don't think doing so would have any important benefit. Claudio ___ 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
El mié, 09-12-2009 a las 12:29 +0100, Juan A. Suarez Romero escribió: Maybe using Listening with p, where p is a used-defined string that can be customized through the applet. Short answer: that's not feasible. Long answer: what you see displayed in the user last.fm page is the name of the application, as registered by its developer when requesting a scrobbling client id. One application - one client id - one application name displayed there. Then again, having one client id per device should be feasible. It's a matter of discussing it with the last.fm people and being sure that we are not stepping on Nokia's toes by using 'Nokia N900' as the application name. Claudio ___ 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
El mar, 08-12-2009 a las 16:13 +0100, Andrea Grandi escribió: Hi all, I was trying to test mafw-lastfm plugin on my N900 but I cannot make it work. I've installed it from extras-devel, I've configured it following the istructions contained in README and I've restarted the device. The plugin is not started automatically and I don't think the average user would be able to understand how to start a mafw plugin. $ mafw-lastfm That should be enough to start it. Did you try to start it manually? Could you please fix this for the next release? Thanks :) Since this is maemo-developers, I'll ask: did you try to debug why it doesn't start during the beginning of the session or whether it starts and exits, crashes, or whatever? Claudio ___ 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
El mar, 08-12-2009 a las 16:49 +0100, Andrea Grandi escribió: Hi, 2009/12/8 Claudio Saavedra csaave...@igalia.com: El mar, 08-12-2009 a las 16:13 +0100, Andrea Grandi escribió: Hi all, I was trying to test mafw-lastfm plugin on my N900 but I cannot make it work. I've installed it from extras-devel, I've configured it following the istructions contained in README and I've restarted the device. The plugin is not started automatically and I don't think the average user would be able to understand how to start a mafw plugin. I noticed that the postinst script was missing the debhelper token used by dh_installxsession to plug its magic. Now the Xsession script should be installed properly. I pushed a new package to the autobuilder queue already. Claudio ___ 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
El mar, 08-12-2009 a las 18:30 +0100, Andrea Grandi escribió: p.s: I was thinking about writing a very simple GUI in Python/Gtk to let the user enter his username and password, generate the md5sum automatically and create the .mafw-lastfm, do you think this could be useful? If you're already working on it I won't start working on it. There is already a control panel applet for this since 0.0.2. Claudio ___ 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
El mar, 08-12-2009 a las 20:52 +0100, Andrea Grandi escribió: Hi, 2009/12/8 Claudio Saavedra csaave...@igalia.com: I pushed a new package to the autobuilder queue already. I'm testing the new package right now. After installing it I had to start it manually from N900 terminal Well, the debian prerm and postinst scripts should be taking care of restarting the daemon during an upgrade, so this should be working automatically. but it's working because last.fm website is displaying in realtime what I'm listening to. A couple of question now: 1) How can I start it automatically without having to start it manually? It should do already, after installation, and on the session start (after the X session is ready). 2) If I'm listening to some music but I don't have any connection at the moment, are the tracks queued to be scrobbled once I get an Internet connection? Yes, tracks are queued. Once there is a connection available, the queue is flushed and the tracks are sent to last.fm. This doesn't happen immediately after the connection is available, though, but only when you start listening again. This could be improved. Another limitation is that the queue is not serialized, so if the process is terminated for any reason, the queue will be emptied. This is also important to fix. Claudio ___ 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
El mar, 08-12-2009 a las 17:50 +, Graham Cobb escribió: On Tuesday 08 December 2009 17:23:15 Claudio Saavedra wrote: I noticed that the postinst script was missing the debhelper token used by dh_installxsession to plug its magic. Now the Xsession script should be installed properly. What is dh_installxsession? I can't find any documentation on it. Probably looking in the wrong place! It's part of upstart-dev. I don't know where it's documented, though. I simply looked at hildon-desktop and some other modules' packages. Claudio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: how to adjust padding of HildonTouchSelectorColumn's private panarea?
El jue, 26-11-2009 a las 04:42 -0600, kyle cronan escribió: Hi everyone, It looks like the hildon_touch_selector_append_column function has a hard-coded padding of 6 pixels around the column's panarea, which gets added to the selector's internal hbox widget. Is there any way I could override this without pulling private structure definitions out of the libhildon code? I think this is done this way since the very first demos of the widget, I don't think it's possible to override it. Media player managed to do it somehow: the selector entries go all the way to the edges of the screen and it looks really nice. I suspect they might not be using HildonTouchSelector at all, but just a GtkTreeView inside a pannable. Claudio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Newer glib on Maemo5
El mar, 17-11-2009 a las 10:08 -0500, Zachary Goldberg escribió: Hello! I have an application I am trying to port to Maemo 5 that requires a newer version of libglib2.0 (2.22) than what is on the device (2.16). Does anybody know what horrible things might happen if I brute-force a 2.22 (and its newer dependencies) on the device? Is there anyway around this problem (perhaps some kind of copy on write chroot with a symlinked version of everything but glib and co?)? Maemo 5 currently has glib 2.20 (2.20.3-1maemo3). In theory, upgrading to glib 2.22 shouldn't be a problem, but I am not aware of any plans to do it at this stage. If you want to experiment, you can get the debian packaging bits from https://stage.maemo.org/svn/maemo/projects/haf/trunk/glib/ and build a glib 2.22 starting from that. Claudio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Screenshot as loading screen on Maemo 5
El jue, 22-10-2009 a las 16:36 +0100, Andrew Flegg escribió: On Thu, Oct 22, 2009 at 16:06, Aniello Del Sorbo ani...@gmail.com wrote: [snip] Thus I thought I'll take the screenshot at the expose event and only take it if the file is not there already. I *think* you need to do it at every expose event. What if the user changes theme and the font colours change (for example)? I think the screenshots are removed on theme switch, so after the user switches the theme, the screenshot need to be taken again. That's why it's a good idea to check for the existence of the screenshot and recreate it if necessary. Claudio Cheers, Andrew ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Packaging Libraries
El vie, 23-10-2009 a las 00:37 -0400, David Falkayn escribió: Here's a question for you whiz kids: what's the best way to go about packaging up a library that already exists, e.g. in debian, for Maemo? Presumably the process is easier than starting from scratch, but after fiddling around with various things and some nice help on IRC, i got nuttin. Could you be more precise? Claudio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Screenshot as loading screen on Maemo 5
El vie, 23-10-2009 a las 09:39 +0300, Kimmo Hämäläinen escribió: it's a good idea to check for the existence of the screenshot and recreate it if necessary. Now that the function is missing this argument (bad design). What do you mean by bad design? We should add some API for creating the screenshot _only if_ it does not exist. Because the place where the screenshot is stored, is not really public information. Well, the hildon API is void hildon_gtk_window_take_screenshot (GtkWindow *window, gboolean take); If @take is %FALSE, the screenshot for @window is destroyed. The only thing that this method is doing in the client side is to set a property in the window. When @take is %TRUE, it's the desktop the one who should actually verify whether the screenshot exists already and create it or not. That doesn't really require new API, just that the desktop does the full job instead of delegating the responsibility to do black voodoo to the client application. Of course a lot of applications are already checking for the existence of the screenshot, but changing the semantics this way shouldn't really hurt. Claudio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Screenshot as loading screen on Maemo 5
El vie, 23-10-2009 a las 09:58 +0100, Aniello Del Sorbo escribió: 2009/10/23 Cornelius Hald h...@icandy.de: On Fri, 2009-10-23 at 09:20 +0300, Kimmo Hämäläinen wrote: On Fri, 2009-10-23 at 08:08 +0200, Hamalainen Kimmo (Nokia-D/Helsinki) wrote: ... Please, no threads, no! The screenshot is only taken if it does not exist, otherwise the existing screenshot is used. So, the performance penalty is not there every time, only when the old screenshot does not exist. I take this back... After checking the code, it seems the application needs to check for the existing screenshot. What a disappointing design... But at least it looks like all screenshots are deleted automatically once you switch themes. That's good :) Conny So ok, to recap, the hildon_gtk_window_take_screenshot only sends a DBUS message to the window manager, No; it sets a property in the XWindow. No dbus involved. Read my previous message. I think the best would be to have a way to retrieve the screenshot path so that we can check for it's existence before taking a new one (thus we wouldn't be checking it in a static path as we do now), instead of hildon_gtk_window_take_screenshot checking for its existence. That would add extra communication overhead. I insist that the best would be that the desktop itself checks whether the screenshot already exists. Claudio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Black border/background around GtkButton
El vie, 23-10-2009 a las 08:25 -0400, Anderson Lizardo escribió: On Fri, Oct 23, 2009 at 6:52 AM, Andrew Flegg and...@bleb.org wrote: Hi, If you look at this screenshot, you'll see there are black borders around the GtkButtons: http://twitpic.com/mknhl This is just two GtkButtons in a GtkHButtonBox in a GtkAlignment in a GtkWindow (which has had gdk_window_set_back_pixmap called on it). Is there a way of getting rid of these backgrounds/borders? I've seen that on Scratchbox + Xephyr, but I thought it was just some drawing issue with Xephyr. Does it happen on a N900 too? Anyway, I'll let the GTK+ experts answer you (I'm interested in the answer as well). This was a design decision from the UI design team [1], and it's implemented at the theme level (by drawing these borders inside the actual GtkButton and other widgets). There's nothing you can do to get rid of these margins. Rationale is that doing it this way, UI team could make sure that all apps get the padding right. There's a bug about the lack of proper documentation of this in bugs.maemo.org (https://bugs.maemo.org/show_bug.cgi?id=5458). Claudio [1] That I opposed to back in the days, fwiw ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Screenshot as loading screen on Maemo 5
El vie, 23-10-2009 a las 15:37 +0300, Kimmo Hämäläinen escribió: The only thing that this method is doing in the client side is to set a property in the window. When @take is %TRUE, it's the desktop the one who should actually verify whether the screenshot exists already and create it or not. That doesn't really require new API, just that the desktop does the full job instead of delegating the responsibility to do black voodoo to the client application. Yeah, that's right, we can check it in hildon-desktop, but the function description should also tell the user of the API what is happening. Let's make a deal, you fix it in the desktop and I fix the documentation of the method :) Claudio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Screenshot as loading screen on Maemo 5
El vie, 23-10-2009 a las 17:25 +0300, Kimmo Hämäläinen escribió: On Fri, 2009-10-23 at 14:46 +0200, ext Claudio Saavedra wrote: El vie, 23-10-2009 a las 15:37 +0300, Kimmo Hämäläinen escribió: ... Let's make a deal, you fix it in the desktop and I fix the documentation of the method :) Fixed in hildon-desktop git master now :) Committing this to hildon master now :) commit 7a9bcd71fe0399604d2bec10bc024290d8d1a9b9 Author: Claudio Saavedra csaave...@igalia.com Date: Fri Oct 23 18:02:53 2009 +0300 Improve the documentation for hildon_gtk_window_take_screenshot() Mention the fact that it's a Maemo 5 feature, what's the purpose of the screenshot, and how to use it. diff --git a/hildon/hildon-gtk.c b/hildon/hildon-gtk.c index f67f830..ee391e4 100644 --- a/hildon/hildon-gtk.c +++ b/hildon/hildon-gtk.c @@ -456,8 +456,23 @@ hildon_gtk_window_enable_zoom_keys (GtkWindow *window, * @window: a #GtkWindow * @take: %TRUE to take a screenshot, %FALSE to destroy the existing one. * - * Tells the window manager to take a screenshot of @window, or to - * destroy the existing one. @window must be mapped. + * Tells the window manager to create a screenshot of @window and save + * it, or to destroy the existing one. If @take is %TRUE but the + * screenshot is already available, the window manager will not create + * it again. + * + * You should only call this method when @window is already mapped. + * + * In Maemo 5 this screenshot, if existent, will be used by the window + * manager in subsequent launches of the application that created + * it. The window manager will remove this screenshot automatically + * whenever the theme, locale, or the time changes; also when a backup + * is restored. If your application changes its appearance between + * runs and you want to force the existent screenshot to be removed, + * set @take to %FALSE. + * + * Since: 2.0 + * **/ void hildon_gtk_window_take_screenshot (GtkWindow *window, ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Screenshot as loading screen on Maemo 5
El jue, 22-10-2009 a las 16:57 +0200, Luca Donaggio escribió: I'm resuming an old thread, sorry! If I call hildon_gtk_window_take_screenshot() within the callback function for the delete-event of the main app, just before gtk_main_quit(), it seems that something has already happened to the main window: it complains that it is not a GtkWindow (which usually is, as HildonWindow derives from it), but a GdkWindow, and, of course, no screenshot were taken. Are you sure you are passing the right window to the function? event-window is not the one (just in case). Claudio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: GStreamer playbin + MP3 playback on the N900
El mié, 21-10-2009 a las 16:17 +0200, Thomas Perl escribió: Hello! As mentioned in https://bugs.maemo.org/show_bug.cgi?id=5629, I cannot get MP3 files to play with GStreamer on the N900 using the playbin element. I have tested it with both Python code and the gst-launch utility. $ gst-launch playbin uri=file:///path/to/a/mp3file.mp3 The error I am getting is this one: ERROR: from element /GstPlayBin:playbin0/GstFileSrc:source: Internal data flow error. Additional debug info: gstbasesrc.c(2345): gst_base_src_loop (): /GstPlayBin:playbin0/GstFileSrc:source: streaming task paused, reason not-negotiated (-4) Is there any way how I can make this work on the N900? (works in Diablo) Is there something special I need to do to playback this file? playbin2? Claudio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: GtkCellRendererToggle on Fremantle
El lun, 05-10-2009 a las 00:02 +0100, Graham Cobb escribió: gpe-calendar contains GtkTreeView with a list of calendars that are being shown. One column is rendered using a GtkCellRendererToggle: i.e. it shows a checkbox to allow the user to control whether the calendar should be shown. In scratchbox this looks fine. However, on the real device apparently the checkbox is just a black square, whether it is TRUE or FALSE. It still reacts to clicks, and changes state, but the rendering doesn't change. This means, of course, that the user cannot see whether the calendar is enabled or not. Is there any way to get this to be visible? I realise that it is not finger friendly, but that is a separate issue. I would be quite happy for this element to only be modifiable using the stylus. If GtkCellRendererToggle is not supposed to be used on Fremantle, can anyone recommend an alternative? From my reading about GtkCellRenderer I can't just use a HildonCheckButton as the renderer in the TreeViewColumn instead, can I? I've said many times before: I'm not a GUI guy. So any help is appreciated! Can you post a small test case? Claudio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: mafw-lastfm 0.0.1
El lun, 05-10-2009 a las 16:29 +0300, Felipe Contreras escribió: 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. Right now the code is quite simple and it shouldn't be much a problem to refactor to make it webservice-agnostic or something like that :) btw, I forgot to say, but I set up a mailing list for those interested in this small project. mafw-lastfm-de...@garage.maemo.org . Claudio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
mafw-lastfm 0.0.1
[Since this is the initial release, I think it's OK to make a heads up in this mailing, in case anyone else is interested in cooperating with this project] mafw-lastfm is a last.fm scrobbler for maemo devices using the Media Application Framework, like the N900. This is its the initial release. It basically works: it sets your playing-now status and it scrobbles. For setup instructions, consult the README file. where to get it --- Source: https://garage.maemo.org/projects/mafw-lastfm/ Packages: Soon to appear in Fremantle's extras-devel What's new? --- - Initial release - Set now-playing, and scrobble. - Credentials stored in $HOME/.mafw-lastfm Short log of this release - Claudio Saavedra (42): Initialize with daemon dummy template Print only the relevant data. Introduce helper function for string metadata. Remove unnecesary messages and extra code Add initial lastfm scrobbler implementation Parse the handshake response and store relevant session data Clean up compile warnings Add basic Makefile Add MafwLastfTrack structure for track handling Create instance of MafwLastfmScrobbler earlier and use as callback data Implement Now-Playing notification Make mafw_metadata_lookup_string allocate the string Add mafw_metadata_lookup_int() Send Now-Playing notification for currently played song on metadata-changed Add a GQueue for the tracks to be scrobbled Use an int64 for the tracks lenght as required by mafw Retrieve the missing metadata required for a scrobble Initial implementation of the scrobbling call Use the track length for the submission timeout Clean the submission queue on enqueue of each track Clean the queue before setting a new playing-now track Use the identifier provided by last.fm for scrobbling Load the last.fm credentials from a keyfile Add README and AUTHORS files Use autotools for building and packaging Add GPLv2 header to source files Add AM_MAINTAINER_MODE to configure.ac Rename on_timeout() to scrobble_timeout() Actually clean the tracks queue from the tail Add mafw_lastfm_scrobbler_set_credentials() Retry handshaking when connection fails Don't set playing-now status nor scrobble if handshake is needed Requeue tracks on scrobble submit failure and handshake again Improve submission logging messages Do not scrobble tracks without artist or title metadata Do not encode NULL strings or soup_uri_encode() will crash Remove irrelevant comments Factor the code to flush the scrobbling queue into a public method Flush the scrobbling queue when the renderer is stopped Remove already implemented features from README Update README Release 0.0.1 Do not depend on a explicit mafw version ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Community widgets for Fremantle
El jue, 01-10-2009 a las 13:46 +0200, Murray Cumming escribió: And it assumes that trying to put widgets directly into hildon will magically improve them, maybe by therefore forcing hildon developers to work them. But that won't work - they will just rot there and eventually be removed. I don't know if you have read the whole thread, but I've said several times already that our intention is to work together with the community on getting eventual new widgets in shape for hildon. I don't know why do you talk about forcing developers. Claudio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Community widgets for Fremantle
El mié, 30-09-2009 a las 14:10 +0300, Marius Vollmer escribió: ext Alberto Garcia agar...@igalia.com writes: 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? You have to be careful to never link two libraries with overlapping symbols into the same process. In the case of libhildon, that is probably manageable, and the possibility can probably be ignored. This shouldn't be a problem. Other distros with more real world experience than maemo cope with this pretty well. For instance, Debian unstable has nowadays two parallel installable versions of libsoup. Objects link against either of them depending on their needs. There should never be the case when someone is linking against the two. Not even if dinamically loadable modules are in place. In our case, Nokia applications and libraries link against what's now shipped by Nokia. That's not going to change. If there is a parallel installable version of hildon, those interested on using it link against it and so should all the modules that they want to load in runtime or whatever. And as far as I know, maemo-launcher only boosts the GTK+ library, but I might be wrong. Claudio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: hildron_entry and activate signal
El mar, 29-09-2009 a las 10:33 +0200, Fred Lefévère-Laoide escribió: Hi Cornelius, I tried Enter and Return on my keyboard : no dice ! I suppose I'll try the gtk_widget_activate way for debugging purpose. Can anyone confirm this behavior in the SDK so that I can open a bug ? You don't even know where your code crashes and you want to file a bug. You should first find out what's crashing. From the very little you describe, it's highly likely to be a bug in your program. Claudio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Community widgets for Fremantle
El lun, 28-09-2009 a las 15:08 +0100, Graham Cobb escribió: why not develop them initially as pieces of standalone code that people include (as source code) into their projects to use, for now? Have you heard of libegg? If you haven't, I'd suggest you to go google for discussions on its existance before even thinking of doing that. Claudio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Community widgets for Fremantle
El mar, 29-09-2009 a las 11:11 +0100, Graham Cobb escribió: So, I agree that a real community library is a better solution, although it has its own problems with maintenance (particularly for widgets which do get adopted by Hildon but with some changes). But at least they can be solved in one place. If you happen to have symbols with the same in hildon and the eventual library you want to create, you will have symbol clashing. If you avoid having symbol clashing by using a different name for the widgets in the hypotetical library, if/when these go into hildon you'll have to deprecate them and still carry them around for people without time to migrate to the hildon variants. And I can tell you that you risk having a lot of developers simply not porting to the Hildon variants because the community versions are good enough for them. Long term maintenance of a library is complex, and you'll have a lot of hassle in the future going that way. On the other hand, there's Nokia and their intentions to work together with the community in Hildon. You'll have to make a choose between control and maintainability. Of course, the implications of Nokia intentions would be good to know beforehand. Claudio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Community widgets for Fremantle
El mar, 29-09-2009 a las 12:51 +0100, Graham Cobb escribió: On Tuesday 29 September 2009 11:39:05 Claudio Saavedra wrote: If you avoid having symbol clashing by using a different name for the widgets in the hypotetical library, if/when these go into hildon you'll have to deprecate them and still carry them around for people without time to migrate to the hildon variants. And I can tell you that you risk having a lot of developers simply not porting to the Hildon variants because the community versions are good enough for them. Absolutely. That was one reason I wanted to make it a little bit harder for people to use the community versions, so only the people who really needed them would use them before they went into Hildon. But, as you have pointed out, that way lies madness. So, I think we just have to face this. Long term maintenance of a library is complex, and you'll have a lot of hassle in the future going that way. On the other hand, there's Nokia and their intentions to work together with the community in Hildon. You'll have to make a choose between control and maintainability. Of course, the implications of Nokia intentions would be good to know beforehand. Input from Nokia would be very welcome (and in my new role I will be asking for some). However, I am sure that there is no way that any more widgets are going to be added to Hildon before Fremantle ships. To be realistic, I don't think you'll have your library ready by the time Fremantle ships either, so I don't see that as a real problem. So, we have to have some library (or else everyone who wants to run on Fremantle has to code the widgets themselves). Also, as we want these to be available very quickly, it is possible there will be some changes before they are accepted into Hildon (the Nokia people are presumably very busy with last minute activities before the launch and are not going to be reviewing and approving specs). So, in my view, we have no option but to have a community library. We should push to move things as quickly as possible into Hildon (with as few changes as possible except in naming) and deprecate them in the community library (at which time I would expect the community to lose interest in maintaing them). You are certainly right that there will be many applications still using the deprecated versions for a long time to come. But that is no worse (in fact a lot better) than many applications hacking together their own widgets so they all have different bugs (and different UIs). I have to be honest and say that I don't like this whole discussion too much. We are talking all the time about hypotetical things that need to be done, and what will be done when these hypotetical things get hypotetically merged, and so on. Too much hypothesis, too little facts. If I was in your place, I'd start by going the right way and assuming that everyone has the best intentions for hildon: just clone the hildon tree, put the widgets in place, work on your clone, get something that can be shown, file a bug. If for whatever reason these don't get merged or you see things going too slowly or too much bureaucracy, nothing is stopping you from diverting then. I don't see the need to divert before even attempting to join the project. Claudio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Community widgets for Fremantle
El mar, 29-09-2009 a las 16:54 +0300, Marius Vollmer escribió: If there really is a problem then there is only one other alternative I see: work in Hildon (or a fork) and allow the community to release an alternative to the standard hildon libraries (under a different library name but containing the whole hildon library) on our own schedule. Any apps which wanted to use the new features would have to link against the community library names instead of the standard library names but the Nokia apps would be unchanged. This is tricky, of course, since the two libraries will contain overlapping symbols. They must never ever be linked into the same process, which will probably be a source of all kinds of stupid and unnecessary hair pulling and teeth gnashing. Just think of plugins and libraries using libraries. Well, that's too much of tinkering with libraries when this is not a library issue, but a distribution problem. Maemo is a distribution and has a problem. It needs to be fixed at the distribution level. 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. If Nokia wants to stick to use a frozen library version for their product, that's their business. Community can still move forward. Claudio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Community widgets for Fremantle
El mar, 29-09-2009 a las 18:41 +0200, Alberto Garcia escribió: 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. Can you elaborate on the maemo-launcher issue? Claudio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Community widgets for Fremantle
El jue, 24-09-2009 a las 08:28 +0200, Cornelius Hald escribió: I propose to create a garage project, let's say 'hildon-extras' with the goal of creating a library containing missing widgets where more than one person is interested in. I am not sure why you need a new library. We've proposed already in the past to the community the possibility to work together in the missing widgets, specially these you mention. We have no problem on pushing these widgets to Hildon if you are willing to contribute. Anyone with patches and/or good mockups is free to join hildon-de...@garage.maemo.org and to attach these in Bugzilla. We'll review patches as time allows (and will probably have more time to help soon). Claudio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Community widgets for Fremantle
El jue, 24-09-2009 a las 20:56 +0200, Cornelius Hald escribió: Hello again and sorry for the delay! I'll try to answer the mails from Claudio and API here. Just too many mails to reply one by one, so I'm replying to myself :P First, my proposal was not meant as a affront towards Igalia or the Hildon team. You have been very helpful in the past and I'm really grateful for this. If it was received like this, I'm really sorry. I don't really see your email as confrontational or anything similar at all. I just wanted to state once again that we are open to work together with anyone interested. And yes, we talked about color/font choosers already but there have been no actions. No one had time and I was also doing nothing. Some days ago the issue came up again in a private discussion, so I was just thinking we should give it another try. Because, the fact remains that some of us need/want composite widgets like color/font choosers and it would be a shame if we duplicate work. I know you are also open for patches and I'm sure you'll do your best to include these into Hildon. Of course it would be the best solution to integrate the community widgets directly with Hildon and this should be the goal. But I'm quite sure that, for example, my code wouldn't pass your quality assurance easily. I'm still quite new to all this stuff and I might just produce poor code which needs a lot of work or testing. Until you give it a try, it's only speculations. That's why I suggest that we work together on moving things forward. Because of this I think we should have a garage project which acts as an incubator for the real thing. It should be super easy to commit code and to try out the code of others. Now, once a widget in the 'incubator' has matured enough it could easily be pulled into Hildon and have a happy life there :) Whether or not it makes sense to create a library out of the 'incubator' code or if it should be source only is debatable. I personally don't care much. For me it's just important that we have a easy way of sharing. Without bureaucracy or high entry barrier. Experience shows that having a separate toolkit library causes more damage in terms of maintainability than the advantages it might bring. Just take the case of the GNOME project, for instance. At some point GNOME suffered from a huge fragmentation of libraries, by the time when libgnome and libgnomeui were becoming the place for widgets and code that, for whatever reason, were not suitable for glib/GTK+. Later, other libraries came: libsexy, libegg, etc. The spirit was similar. But unfortunately, the result was that, on spite of being widely used, these libraries ended up being mostly unmaintained, while glib and GTK+ slowly gained the missing features these provided. The effort to get rid of the dependencies on the unmaintained libraries has been enormous and after several development cycles, the GNOME community still can't fully deprecate them/remove them. Also there might be widgets that you don't want to have in Hildon. There might be quality concerns or style concerns. I think those widgets still should have a home. They might be useful for one or two developers. This was/is really only a proposal. I for myself have not done anything yet (ok, a bit but not much). So I've not written any color or font chooser. I just wanted to start the discussion again and see what people are thinking. And as it turned out Andrew already has some code and is willing to share that - which is very nice! So what do you think? Is it a good idea to have an 'incubator'? Should it be source only or should it include releases as libs? Are more people interested? Which other widgets do you think are missing? There are some more things which I'll answer soon in separate mails :) Well, I would personally prefer to see more people involved in hildon instead of working on their own, specially now that there's clearly a gap to be filled between the toolkit set that Diablo (or even plain GTK +) has and what's part of Maemo 5 one. The only reason why these widgets don't exist is because no one has come up with a proposal and/or initial implementations on which to base on. Now that there's common interest, I think it's a good moment to let the work happen. If anyone is interested in going through a more detailed discussion of what is missing in the toolkit nowadays, we'd be pleased to discuss it in the hildon-de...@garage.maemo.org mailing list. Also, remember that Berto and I will be hosting a BoF in the future of Hildon/GTK+ during the Maemo Summit, so the instances to discuss in detail and start working together are just right there. Claudio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle: Opening URLs and local files
El jue, 17-09-2009 a las 12:15 +0200, Thomas Perl escribió: Hello! What is the canonical way of opening a browser and the media player (or more general: opening a URL and opening a local file) from code on Fremantle? gtk_show_uri() should work in theory, but I don't know if it does in practice. Claudio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Mnemonics (Access keys) usage in Fremantle
El mié, 16-09-2009 a las 17:10 +0200, Andre Klapper escribió: In many 3rd party apps, buttons/check boxes/menuitems use mnemonics (=underlined letter in a word that can be used together with the Alt key for the sake of accessbility). In every official Fremantle screenshot I have seen there are no mnemonics though. Is there any should not use mnemonics guideline? I could not find anything in the HIG at http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Human_Interface_Guidelines/ We are currently disabling them in the theme layout gtkrc files. Application developers don't need to worry about that. Claudio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New apps for fremantle with Qt?
El vie, 04-09-2009 a las 17:37 +0300, Kate Alhola escribió: 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. Claudio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New apps for fremantle with Qt?
El vie, 04-09-2009 a las 15:48 +0100, David Greaves escribió: See https://projects.maemo.org/svn/af/projects/hildon-widgets/trunk/src/ for details of the hildon widgets. Is that the maemo.org credentials? I can't get access :( The hildon toolkit was moved long time ago to git.maemo.org https://git.maemo.org/projects/hildon/gitweb?p=hildon;a=summary Is it related to this bug: https://bugs.maemo.org/show_bug.cgi?id=4625 We have these figures from the maemomm project: http://maemomm.garage.maemo.org/docs_unstable/tutorial/figures/ Dave Neary had volunteered for that, haven't seen any progress on it. Claudio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Python + hildon.TouchSelector (with pixbufs)
El dom, 30-08-2009 a las 15:35 -0400, Brent Chiodo escribió: The reason I'm creating the dialog by hand is because I want complete control over it's look and feel. Complete control on look 'n feel is not a good reason imho. HildonPickerButton + HildonTouchSelector is the recomended way to go, since by using them you'll get a look 'n feel that's standard with other applications in Maemo 5. In addition, hildon.PickerButton.set-image() is not working here so i thought it's probably best to use plain old GTK. That method is supposed to set an image on the button itself, I suppose this is what you need. Why is it not working? Claudio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle toolbar icon size
El lun, 31-08-2009 a las 15:14 +0200, Cornelius Hald escribió: Hi, what is the recommended size (in pixels) for icons used on a toolbar in Fremantle? Or asked differently, which size does Modest and the default browser use? The HIG does not mention it. HILDON_ICON_PIXEL_SIZE_FINGER Claudio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle toolbar icon size
El lun, 31-08-2009 a las 15:42 +0200, Cornelius Hald escribió: ext-mox.so...@nokia.com wrote: HILDON_ICON_SIZE_FINGER Or in pixels: HILDON_ICON_PIXEL_SIZE_FINGER Thanks, that translates to: hildon_get_icon_pixel_size (HILDON_ICON_SIZE_FINGER); Could you please tell me what this function returns on a N900 in absolute numbers? I don´t have access to the SDK at the moment but need to know the size (for creating graphics). This is registered in hildon_init(), which is in hildon-main.c. gtk_icon_size_register (hildon-finger, 48, 48); Claudio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Python + hildon.TouchSelector (with pixbufs)
El dom, 30-08-2009 a las 12:20 -0400, Brent Chiodo escribió: I'm trying to create a simple dialog that opens when you tap a button. In this dialog, I want to place in it a hildon.TouchSelector that has a single column comprised of pixbufs (logos of websites). For this use case, I'd recommend you using directly a HildonPickerButton instead of creating a button, a dialog, and all the logic by hand. Check the docs for HildonPickerbutton. Just to see if I could get a TouchSelector working, I created a simple one that just uses text labels instead of pixbufs. Here is the pertinent part of the code: # This part is the button that opens the dialog self.select_button = gtk.Button() self.select_icon = gtk.gdk.pixbuf_new_from_file_at_size(/usr/share/touchsearch/select_search_engine.png, 40, 40) self.select_image = gtk.Image() self.select_image.set_from_pixbuf(self.select_icon) self.select_image.set_padding(settings['padding'], settings['padding']) self.select_button.set_image(self.select_image) self.select_button.connect(clicked, self.select_engine_dialog) self.select_button.show_all() ... # And this is the dialog with the Touchselector in it def select_engine_dialog(self, widget): dialog = gtk.Dialog(Select A Site To Search, None, gtk.DIALOG_DESTROY_WITH_PARENT | gtk.DIALOG_NO_SEPARATOR) close_button = dialog.add_button(gtk.STOCK_CLOSE, gtk.RESPONSE_CLOSE) selector = hildon.hildon_touch_selector_new_text() searches = [Google, eBay, Amazon, Merriam-Webster, Google Maps, Google Images, maemo.org] for i in searches: selector.append_text(i) dialog.vbox.add(selector) dialog.show_all() response = dialog.run() dialog.destroy() When I run this example I get exactly what I expected except the TouchSelector doesn't scroll -- when I drag it in either direction it shows me the indicator of where the focus is, but it doesn't move. Errors from traceback are: /usr/lib/hildon-desktop/touchsearch.py:68: Warning: cannot register existing type `HildonPannableAreaMode' selector = hildon.hildon_touch_selector_new_text() /usr/lib/hildon-desktop/touchsearch.py:68: Warning: g_param_spec_enum: assertion `G_TYPE_IS_ENUM (enum_type)' failed selector = hildon.hildon_touch_selector_new_text() /usr/lib/hildon-desktop/touchsearch.py:68: Warning: g_object_class_install_property: assertion `G_IS_PARAM_SPEC (pspec)' failed selector = hildon.hildon_touch_selector_new_text() /usr/lib/hildon-desktop/touchsearch.py:68: Warning: cannot register existing type `HildonMovementMode' selector = hildon.hildon_touch_selector_new_text() /usr/lib/hildon-desktop/touchsearch.py:68: Warning: g_param_spec_flags: assertion `G_TYPE_IS_FLAGS (flags_type)' failed selector = hildon.hildon_touch_selector_new_text() /usr/lib/hildon-desktop/touchsearch.py:68: Warning: cannot register existing type `HildonSizeRequestPolicy' I am not familiar with the python bindings, so I have not much to say about these errors other than it seems that the registration of some of the types fail, which is strange.. In addition to that, once I get that working how would I go about getting pixbufs in there instead of just text? I'm familiar with how to create a gtk.TreeView, HildonTouchSelector uses HildonTouchSelectorColumn for each of its columns. Since you want one single column, you need to create one and use the GtkCellLayout interface in the same way you would do for GtkTreeViewColumn. but don't know how to apply this knowledge to a Touchelector e.g. the example found here: http://pymaemo.garage.maemo.org/documentation/python_hildon_tutorial/html/ch-Selectors.html#example-of-a-selector-with-a-custom-column ...doesn't work. Maybe the python bindings are not fully working? Did you try with C instead? Claudio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Howto enable portrait mode support on Fremantle
El lun, 24-08-2009 a las 23:39 +0300, David Weinehall escribió: * mce is not running I might be missing something, but mce doesn't seem to be running in the FREMANTLE_X86/ARMEL targets in scratchbox after a simple af-sb-init.sh start You probably need to start it by hand. Feel free to ignore me if you already have it running.. Claudio ___ 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?
El mar, 21-07-2009 a las 08:53 +0100, Andrew Flegg escribió: 2009/7/21 Kimmo Hämäläinen kimmo.hamalai...@nokia.com: That's not currently possible unless you use a fullscreen window. Let's be clear what Till's talking about: http://bleb.org/software/maemo/modest-move.png How does Modest put that Move button there? Next to the Back arrow at the top-right of the screen. I said it three times already. Fullscreen the window. Claudio ___ 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?
El lun, 20-07-2009 a las 17:53 +0200, Till Harbaum / Lists escribió: ok, i had a look at these, but a HildonEditToolbar appears _below_ the main screens title bar in my experiment. In the video it replaces the main screens title bar. You need to fullscreen your window to tell the WM not to draw its decorations. Claudio ___ 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?
El lun, 20-07-2009 a las 18:33 +0200, Till Harbaum / Lists escribió: Hi, Am Montag 20 Juli 2009 schrieb Claudio Saavedra: You need to fullscreen your window to tell the WM not to draw its decorations. Sure, but in that video you see that the main window is not fullscreen. As i said: The HildonEditToolbar _replaces_ the main screens window decorations. Did you try it already? Claudio ___ 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?
El lun, 20-07-2009 a las 20:38 +0200, Till Harbaum / Lists escribió: Hi, Am Montag 20 Juli 2009 schrieb Claudio Saavedra: Did you try it already? Nope, because it's not what i want. I want the button to replace my title bar as visible in that video. From http://maemo.org/api_refs/5.0/beta/hildon/HildonEditToolbar.html : Example 15. HildonEditToolbar example toolbar = hildon_edit_toolbar_new_with_text (Choose items to delete, Delete); (...) hildon_window_set_edit_toolbar (HILDON_WINDOW (window), HILDON_EDIT_TOOLBAR (toolbar)); (...) gtk_widget_show_all (window); gtk_window_fullscreen (GTK_WINDOW (window)); Claudio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: A slight problem while working with treeview columns
El jue, 16-07-2009 a las 20:04 +0530, Amit Sethi escribió: .set_headers_visible(True) Yes thanks that was exactly the problem ... but a little detail on why this should be avoided? Because of the screen space waste. Try to make clear in the context of your UI what the list is all about (window title, for instance). Of course this is recommended only and default for convenience only, feel free to ignore the suggestion. Claudio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: HildonColorButton / HildonColorChooserDialog in Fremantle
El lun, 29-06-2009 a las 09:30 +0200, API escribió: From: Cornelius Hald h...@icandy.de Hi, HildonColorButton and HildonColorChooserDialog are both depreciated in Fremantle. The documentation doesn't tell what to use instead. This bug[1] mentions the following: [...]A HildonPickerButton/HildonTouchSelector variant could be used here.[...] Yes, this is true, the idea is use the HildonTouchSelector (or a pannable area +treeviews for custom requirements) to choose elements from a list. In the end, choose a color should be the same, with the difference that you will only have a discrete number of color to choose from. Could someone elaborate how choosing a color should look like in Fremantle? Basically it should be a list with all the colors, and if you want to avoid use only the name, and extra cell renderer to show the color. Visually it should be similar to the hildon-touch-selector-example.c (at the hildon repository, examples directory), but instead of the stock icons, the colors. If someone wants to come up with such an implementation, I'd encourage him/her to file a bug about this in bugs.maemo.org and we can discuss it in detail, review it, and finally push it to the hildon git tree. Claudio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: HildonColorButton / HildonColorChooserDialog in Fremantle
El lun, 29-06-2009 a las 12:36 +0200, Cornelius Hald escribió: Thanks for the answer API. I'll try how that looks / works for me. @Claudio: I think it would be nice to have a color picker widget directly in Hildon, but I'm not sure how many people/applications really need it. Still, of course it would be great if someone would create one. Only it's very unlikely that it's me :/ I would like to, but I just don't have the time... Not trying to be pushy, but aren't you going to code something similar anyway? Claudio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Re: Questions about HildonPannableArea
El mar, 09-06-2009 a las 13:22 +0200, Till Harbaum escribió: The coolest thing would of course be if selection can be enabled in a pannable are as well. If that's the case i wouldn't mind if you completely remove the built-in panning support from gtkhtml. If there are no plans for selection support in pannable areas, how is this then to be solved? Is the fremantle xterm solution the way to go? A pannable area can't have support for text selection, because it's just a generic bin container. The only thing stopping you from doing text selection is the enabled property being TRUE. Whether we want to allow a certain gesture to turn enabled to FALSE is a different question. It has to be considered that for some use cases of the pannable area, you don't want it to be disabled at all (say, a GtkTreeView inside a pannable area). This discussion could sanely be moved to a bug report. Claudio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Questions about HildonPannableArea
El mar, 09-06-2009 a las 13:37 +0200, Cornelius Hald escribió: Claudio Saavedra wrote: This discussion could sanely be moved to a bug report. I think it´s better to keep this discussion here, where every one can see it. Having the discussion in Bugzilla will just put this issue off the radar for most developers. Yes, and that's sane, assuming most developers are not interested on this. Those who are, however, can subscribe to the bug report. We already passed the mark where it was clear that something should be done on this regard, now it's a matter of details, and bugzilla fits better for that. Claudio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Re: Questions about HildonPannableArea
El mar, 09-06-2009 a las 15:47 +0200, Till Harbaum escribió: Hi, - original Nachricht Betreff: Re: Questions about HildonPannableArea Gesendet: Di, 09. Jun 2009 Von: Claudio Saavedracsaave...@igalia.com Yes, and that's sane, assuming most developers are not interested on this. Ok, i then just return to use a standard GtkScrolledWindow as i really don't have the time to be the beta tester for some unimportant widget. No need to misquote me in that way. FYI, the HildonPannableArea is a _very important_ widget for us in the hildon library and the reason why I'm suggesting to follow up in the bug report[1] is because I think we should come out with something to improve this particular case. Claudio [1] https://bugs.maemo.org/show_bug.cgi?id=4619 ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Questions about HildonPannableArea
El mar, 09-06-2009 a las 17:52 +0200, Till Harbaum / Lists escribió: Hi, Am Dienstag 09 Juni 2009 schrieb Claudio Saavedra: Yes, and that's sane, assuming most developers are not interested on this. Ok, i then just return to use a standard GtkScrolledWindow as i really don't have the time to be the beta tester for some unimportant widget. No need to misquote me in that way. Where do i misquote you? You said most developers aren't interested in this (so it isn't important (yet)) and that we should discuss its usage on bugzilla (meaning that its usage is still matter of dealing with bugs) . To me this means its not a widget for the end user (yet). You are completely misunderstanding me. What I am trying to say is that for most of the _community developers_, getting into the details of one particular bug is not interesting. There is no point on venting the discussion on the face of developers who are not using this specific feature. That's why I suggest to use bugzilla to follow up and allow, only to the community developers interested in UI development, and in particular, to text selection inside a scrollable widget, to subscribe, stay informed, and comment on the issue. FYI, the HildonPannableArea is a _very important_ widget for us in the hildon library and the reason why I'm suggesting to follow up in the bug report[1] is because I think we should come out with something to improve this particular case. Ok, it's important to you, because one day you want it to become a widget for daily use. But until then the scrolled window seems to be the better/more reliable choice. You are wrong. The HildonPannableArea is an important actor in Fremantle. Look at modest, for example, where it's heavily used. Of course, you can continue using a scrolled window, but that's completely up to you and I wouldn't recommend it, since it will look really oldish. Seriously, I don't know how is it possible to make so many assumptions out of a simple suggestion to move a discussion to bugzilla. This can only be misleading for others and doesn't really help. Claudio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Questions about HildonPannableArea
El mié, 03-06-2009 a las 20:54 +0200, Till Harbaum / Lists escribió: Hi, Am Mittwoch 03 Juni 2009 schrieb Alejandro Garcia Castro: I do not know about the current status of out gtkhtml code, but I think probably we will have to add a parameter to deactivate it in the gtkhtml widget, or maybe just ifdef it or remove it. There's no such property in gtkhtml. And what do you mean by ifdef it? I sure won't remove that feature from gtkhtml as this would then affect _all_ applications. You are right, there is no such property. In maemo, GtkHtml was patched, a long time ago, to allow panning when dragging on the widget. This panning is currently interfering with the way the pannable area works and it can't be disabled nor configured. There are two plausible approaches to fix this in GtkHtml (which I'm currently weighting): 1. Remove the patch to allow panning in the GtkHtml widget. This has the advantage to be a quite straightforward solution. The con is that any application relying on this feature will loose panning until they migrate to use a pannable area. 2. Make this hardcoded panning feature a property, enabled by default. The advantage of this approach is that no application is broken and those willing to use a pannable area have the chance to disable the property. The disadvantage of this is that it will probably take some extra effort and time to implement it, that I could pretty well use in more relevant issues. Personally, I'm more inclined to go for (1). Mainly, because GtkHtml, as André pointed out, is a dead-end widget, and any extra efforts on it are probably not worth. Anyone willing to get a nice and consistent panning experience in Fremantle should use a pannable area. Nevertheless, I'd read some opinions before doing anything. Claudio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Hildon Two-touch
On Fri, 2009-06-05 at 09:48 +0200, Cornelius Hald wrote: * When should I use 'Two-touch' and when 'Long tap'? The HIG tells me that the 'Two-touch' _can_ be used to bring up a context menu. But the description for the 'Long tap' sounds like a context menu too [2]. So, when to use which? It looks to me like the mention of two touch is buggy. I'd go for using always a long tap. Can you file a bug under docs against the HIG about this? Claudio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Unsatisfied with bugs.maemo.org
On Fri, 2009-06-05 at 10:07 +0200, Till Harbaum / Lists wrote: Hi, sorry, but i don't get your point. You say that you'd need tests and things for the themeing and thus you don't do it at all? You mean it's acceptible to not theme them at all and have them look ugly but it's not acceptible to give them a quick/untested themeing? Why? You basically say either we do things perfectly or we do them in the worse possible way. I'd say: If you don't support that feature, then remove it entirely from the libs and from the api docs. But distributing a library containing stuff you just won't support is pretty odd. [...] You say you only fix those features that are actually a problem for your own product and you don't care for widgets that are only used by third party applications. Are you serious? Nokia really isn't interested in supporting third party apps? Support is only provided if there's also a benefit for nokias own applications? Wow ... To be more precise on this topic, it's not that we didn't work on theming of the so-called legacy widgets[1]. Lots of work (and I really mean, *lots* of work) went into making sure that at least the common use cases of these widgets are themed in a consistent way with the new Fremantle style, but as in any project, there are priorities to attend and some issues, like the one you mention, would require a huge effort to get right. You need to understand that we also have time/resources constrains. Claudio [1] That is, widgets that even being part of GTK+ or hildon 2.0, are not recommended to be used for Fremantle because they differ from the new UI style. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle UI Portrait Mode
On Fri, 2009-05-29 at 13:48 +0300, Kimmo Hämäläinen wrote:
On Thu, 2009-05-28 at 17:19 +0200, ext Cornelius Hald wrote:
* What happens to toolbars when in portrait mode? Is there some
automatic behavior like showing the toolbar as two rows instead of a
single row? Is it scaled? Is the space between the buttons reduced?
Or do we have to care about this by ourself, for example listen to some
signal and then hiding some buttons or rearranging them?
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).
Toolkit people here :)
Offhand, application menus and confirmation notes will relayout; banners
and picker dialogs will resize to new screen dimensions. That's pretty
much it (unless I'm forgetting something).
* What happens to any other widget when in portrait mode?
It looks crap. That's why the rotation is not unconditional, see below.
* Is there a signal which signals that the screen orientation changed?
Yes, XRandr signals, which are handled by GTK, methinks.
You can connect to GdkScreen::size-changed or GdkScreen::monitors-
changed to get notified and do your magic.
* Is there a function to change the screen orientation and can we
somehow use this with the beta SDK?
Yes, we have _HILDON_PORTRAIT_MODE_REQUEST and
_HILDON_PORTRAIT_MODE_SUPPORT window properties (I think libhildon has
convenience functions for setting them).
typedef enum {
HILDON_PORTRAIT_MODE_REQUEST = 1 0,
HILDON_PORTRAIT_MODE_SUPPORT = 1 1
} HildonPortraitFlags;
hildon_gtk_window_set_portrait_flags (GtkWindow *window,
HildonPortraitFlags portrait_flags);
The HIG[1][2] is very vague on that matter so it would really be nice if
someone from the hildon team or the UI specs team could comment on that.
I think it would be a shame if the new device is finally available and
every time someone holds the device in portrait mode, everything* looks
like crap.
If you don't want to support portrait mode, just don't set any portrait
flags and the UI will look as crappy as you originally planned :)
Claudio
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: AppMenu, Filters and HIG
On Mon, 2009-05-25 at 22:24 +0200, Cornelius Hald wrote: Hello again :) To not make the other threads more cluttered as they are already, here's a new one. I'm trying to another window fully conform to the Fremantle HIG, but I'm not sure that I understand the paragraph on Filters: http://maemo.org/api_refs/5.0/beta/hig/html/ch04s02.html The window is a window to select a particular note from a list. The list has two columns: The title of the note and the date when it was last changed. Using a simple GtkTreeView it is displayed with a header row which offers sorting, this means the list can be sorted in four ways: - Sort By Title Ascending - Sort By Title Descending - Sort By Date Ascending - Sort By Date Descending Here is a screenshot of this window: http://zwong.de/wp-content/uploads/2009/05/search_window.png As you can see, I could probably display one more note, if I would remove the header row. If I read about Filters it sounds like I could/should use them for this purpose because in the documentation I read ... For example, sorting alphabetically a list of contacts I tried putting those four sorting options into a filter, but it doesn't work because the filters are shown in one row and the strings are just too long for that. This would be the result: http://zwong.de/wp-content/uploads/2009/05/search_window_with_long_filters.png I know that Filters are supposed to work like this, therefore I would like to get some insight on what the appropriate way is to handle this situation. 1) Keep the header row and not use Filters at all? 2) Remove one column, so that only one column is left? 3) Use filters, but different? 4) Something completely different? This is the purpose of filters, but you might need to find strings that fit well in the menu. Repeating Sort by in each one of the buttons is wasting too much space. Restricting the sorting criteria might also help (for example, keep both criteria but only in one direction, etc). Claudio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle user interface behaviour and API
El vie, 22-05-2009 a las 18:52 +0100, Graham Cobb escribió: On Friday 22 May 2009 18:20:55 Sergio Villar Senin wrote: Modest uses a pannable area which contains the text editor. Thus it's not possible to select text in that way in Fremantle. You'll have to use the keyboard. Not having experienced this I don't want to overreact but ... Are you saying that in Freemantle there is no easy way to select and copy text out of an email to copy into somewhere else? You can use the keyboard to copy and paste. There are shift and arrows keys. Claudio ___ 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 Mon, 2009-05-18 at 11:35 +0200, API wrote: Thanks, I didn't know that there were examples... I downloaded and compiled them. Now it's time for playing :) Yes, for any reason the package libhildon1-examples were not included with the SDK, when in the end, can be really useful, as currently we have an example for almost all hildon widgets, and in the complex ones, like pannable area, several examples. I hope that this package will be included on the future final SDK. I contacted the SDK people regarding this; they will be adding the libhildon1-doc and libhildon1-examples packages to the next SDK release. The reason why they were missing is that these packages are new in Fremantle and when I added them to the distribution I forgot to contact the SDK people about it. Claudio ___ 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 14, 2009 at 11:02:45AM +0200, Cornelius Hald wrote: Hi Everyone, I'm sitting on the train and my notebooks battery just went flat, the sockets are not working because of some electricity problems (yea Deutsche Bahn), so I don't have the API nor my code in front of me. That said please excuse wrong spelling of function names etc... I'm having some quesions about the Fremantle UI. Hopefully someone can help and save me hours of boring try-and-error :) Just for the record, the hildon library team has moved the hildon code to garage, and we created there a mailing list for this kind of questions and to get some feedback. You can find it in https://garage.maemo.org/pipermail/hildon-devel/ Panable Area How exactly should I use it? I replaced my ScrollableWindow with a PanableArea, the rest of the code I left as it is in Diablo. Inside the PanableArea is a GtkTextBox. Nothing else. Now, it renders correctly, that is it has only this small scroll indicator and not a real scroll bar. But I cannot pan. If I try to pan it always selects the text inside the text box. How is this supposed to work? How is the destinction made between selecting text and scrolling/panning the text? In the particular case of text areas, panning is not really possible since the text area will process the dragging as text selection and won't propagate the event back to the pannable. A solution for this involves overriding some event handlers in the text area. You can check HildonTextView for a way to handle this, although I'd recommend you to use it directly. Tree View I changes the code from using gtk_tree_view_new() to hildon_gtk_tree_view_new(). I thought this would give me a finger friendly version of the tree view, but I cannot see a difference between the hildon and the gtk version. Also the different HildonUIModes have no effect for me. What is the supposed outcome? How do I get the tree view to be finger friendly? I'm using a GtkListStore as backend and the view shows two sortable columns - if that matters. To avoid breaking legacy applications, the proper theming is done only to treeviews inside a pannable area. If you put your treeview inside a pannable area, you'll get finger-friendly sized rows. Context Menu How are context menues supposed to work in Fremantle? If the main menu is now finger friendly then the context menu should be too I think. How do I generate such a menu? Is there API or do I just create a GtkMenuShell with some big buttons in it? For application menus it is recommended to use HildonAppMenu. For context sensitive menus, please create them using hildon_gtk_menu_new() to get proper theming. Does this new 2-finger-tap-thing generate a normal right-mouse-click event or something else? Changeing device orientation I think I read that using the device in portrait mode should give the user a simple version of the application. E.g. the user can only view, but not edit content. Also the UI then should be usable with one hand. Further it was written, that the HildonAppMenu changes in portrait mode from 2x5 items to 1x10 items. How do other widgets like the tree view react to changes of the device orientation? And is there a way to test this with the current SDK? There's API to set the orientation mode of your window in hildon, but I think this is not yet in the SDK. You can get a more recent version from git: git clone https://git.maemo.org/projects/hildon Claudio ___ 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, 2009-05-14 at 12:03 +0100, Graham Cobb wrote: On Thursday 14 May 2009 11:25:32 Claudio Saavedra wrote: On Thu, May 14, 2009 at 11:02:45AM +0200, Cornelius Hald wrote: I'm having some quesions about the Fremantle UI. Hopefully someone can help and save me hours of boring try-and-error :) Just for the record, the hildon library team has moved the hildon code to garage, and we created there a mailing list for this kind of questions and to get some feedback. You can find it in https://garage.maemo.org/pipermail/hildon-devel/ Please DO NOT move this sort of discussion to a hildon-devel list. This is exactly what maemo-developers is for! Surely I am not the only Maemo community developer who knows that at some time they may have to port their application's existing GUI to Freemantle? I am not a GUI guy and won't be re-designing the GUI. If someone else does, that is great but I am likely to end up trying to make whatever easy changes I can to make it work (or work better) on Freemantle. Yes, well, I kinda agree with you. To be honest, that was a bit of self-promotion for the mailing list; but what we would actually like to end up with in the hildon-devel mailing list is with discussion related to the development of the library itself, which would be off-topic here, IMHO. So, sorry for misleading you, I am watching this mailing list and will be answering questions here, no worries about that. Claudio ___ 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, 2009-05-08 at 11:34 +0100, Luo Cheng wrote:
code snippet
static gboolean on_banner_idle(GtkWidget *banner)
{
gtk_widget_destroy(banner);
return FALSE;
}
static void create_progress_banner(AppUIData *main)
{
GtkWidget *banner;
banner = hildon_banner_show_progress(GTK_WIDGET(main-data-window),
NULL, Searching...);
hildon_banner_set_fraction(HILDON_BANNER(banner), 0.2); /*TODO, need
update func*/
gtk_widget_show(GTK_WIDGET(banner));
You don't need to call gtk_widget_show() on the banner,
hildon_banner_show_progress() will show it for you.
In any case, for Fremantle it's discouraged to use progress banners.
Prefer hildon_gtk_window_set_progress_indicator() if possible.
Claudio
___
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, 2009-05-08 at 13:31 +0100, Luo Cheng wrote: sorry, send by mistake. here is the full code Banners are temporary windows, meaning they will be closed when other non temporary windows are shown. The dialog you are creating is not temporary, therefore, your banner is closed. Hence, don't show a banner before opening a new window. I tried to remove gtk_widget_show(), but banner still automatically disappeared. Actually I am developing something for maemo 4.0 SDK, so can I still use hildon_gtk_window_set_progress_indicator()? No, that API is new in hildon 2.2. Claudio ___ 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, 2009-05-08 at 15:37 +0200, Alberto Garcia wrote: 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: Heh, well. Maemo 5.0 you mean ;). But yes, this was fixed in the current development version; I was just pointing out the behavior for Diablo and before. Claudio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: apt-get update works differently in different targets
On Thu, 2009-04-30 at 13:37 +0200, Jeremiah C. Foster wrote: On Thu, 2009-04-30 at 12:29 +0300, Claudio Saavedra wrote: On Thu, 2009-04-30 at 10:53 +0200, Jeremiah Foster wrote: Hello, After installing the fremantle SDK beta, I am trying to get the X86 target running. I already have the ARMEL target working, installed the Nokia binaries and all but missed the explanation that one cannot run anything in the target yet. So I switched to the X86 target with sb- menu but once I am in that target I cannot reach the maemo fremantle repositories, which I know for a fact are up. ;) I can use apt-get perfectly in ARMEL, but it fails in X86. What's the error? [sbox-FREMANTLE_X86: ~] apt-get update Err http://repository.maemo.org fremantle/sdk Release.gpg Temporary failure resolving 'repository.maemo.org' Err http://repository.maemo.org fremantle/tools Release.gpg Temporary failure resolving 'repository.maemo.org' Reading package lists... Done W: Failed to fetch http://repository.maemo.org/dists/fremantle/sdk/Release.gpg Temporary failure resolving 'repository.maemo.org' W: Failed to fetch http://repository.maemo.org/dists/fremantle/tools/Release.gpg Temporary failure resolving 'repository.maemo.org' W: Some index files failed to download, they have been ignored, or old ones used instead. W: You may want to run apt-get update to correct these problems [sbox-FREMANTLE_X86: ~] Check your /etc/resolv.conf in the X86 target, it might differ from the one in the ARMEL one. Claudio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: apt-get update works differently in different targets
On Thu, 2009-04-30 at 10:53 +0200, Jeremiah Foster wrote: Hello, After installing the fremantle SDK beta, I am trying to get the X86 target running. I already have the ARMEL target working, installed the Nokia binaries and all but missed the explanation that one cannot run anything in the target yet. So I switched to the X86 target with sb- menu but once I am in that target I cannot reach the maemo fremantle repositories, which I know for a fact are up. ;) I can use apt-get perfectly in ARMEL, but it fails in X86. What's the error? Claudio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle dialogs at maximum size
El jue, 16-04-2009 a las 18:11 +0200, Till Harbaum / Lists escribió: Hi, Am Donnerstag 16 April 2009 schrieb Kimmo Hämäläinen: Yeah, if you are not fullscreen, you will be limited in height (I'm not sure if this is in alpha version, though) so that the user can still close the dialog by tapping outside. The problem is that in non-fullscreen mode i am not limited and the dialog is bigger than the usable screen space. Do i really have to hardcode those limits into my program? Why doesn't maemo just limit the size to a reasonable value instead of creating overlapping things? Also you want me to call gtk_window_fullscreen() on dialogs even if the main window is already fullscreen when creating that dialog? In order to do so i'd have to exactly know how big a dialog can be at most. That imho doesn't make much sense. Once should be able to request any size and having hildon take care that nothing is bigger than useful. As Kimmo already said, this is already fixed and dialogs won't occupy more than the screen height minus a certain delta. It's probably not in the latest SDK release, but it will be in the next one. Claudio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Reduce fremantle button spacing
El jue, 16-04-2009 a las 21:36 +0200, Till Harbaum / Lists escribió: Hi, fremantle increases button sizes significantly to make them more finger friendly. However, some applications like osm2go are imho not suited for finger usage and those big buttons thus waste screen space. In diablo a button was barely bigger than e.g. the icon inside. How do i get this behaviour in fremantle back? When i just force the button size to be smaller, then the icon is shifted to the right half way out of the button. There seems to be some fixed border involved. I tried to force the inner-border of the button to 0,0,0,0 but that also doesn't change anything. How do i draw a button with an icon inside that isn't significantly bigger than the icon itself in fremantle? Did you try with hildon_gtk_button_new() ? http://maemo.org/api_refs/5.0/pre-alpha/apis/libhildon-2.1.24/hildon-hildon-gtk.html#hildon-gtk-button-new Claudio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: g_enum_get_value_by_name
On Wed, 2008-12-17 at 23:15 +0200, Arto Karppinen wrote: Hi. I need to save and read an enum from a GKeyFile. I was going save the value as a string into the keyfile and use g_enum_get_value_by_name() to parse the value, but i cant figure out how to get the GEnumClass parameter. GEnumValue* g_enum_get_value_by_name(GEnumClass *enum_class, const gchar *name); Or should i be doing something else? You can use glib-mkenums to parse your enumeration and generate these classes automatically. That's usually done as part of the compilation process of your application or library. Claudio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Issues with jhbuild and maemo moduleset
Hi, I've been giving a spin to maemo from sources, using the jhbuild modulesets in [1]. So far, I've found a few issues that make me think that probably no one is really using this: 1. A cycle in the dependencies when trying to do a normal jhbuild build 2. The maemo moduleset grabs pango from the 1-14 branch, but gtk+ needs at least pango 1.17.3. So, is anyone really using this? Otherwise, how do you people build stuff from SVN? Claudio [1] https://stage.maemo.org/viewcvs.cgi/projects/haf/jhbuild_modules/?root=maemo -- Claudio Saavedra [EMAIL PROTECTED] Igalia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
