Re: Autocomplete Library
From: Tanmay Verma tanmay08...@iiitd.ac.in Hi I have taken Maemo development project in my mobile computing course and our group was thinking of developing an Autocomplete library. Is there any such library available in GNU C or other libraries which support Maemo apps You mean something like this (already tested on maemo) ? http://www.joaquimrocha.com/2010/03/03/text-prediction-on-gnome/ BR === API (apinhe...@igalia.com) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Error History of running Hello World in Scratchbox and Application Framework
From: Jean Marangos jean.maran...@gmail.com As requested, please find attached the error history of running Hello Word in the Scratchbox and attempt to start the Application Framework. Thanks for support. I think that the problem is in this line: j...@pluto:~ Xephyr :2 -host-cursor -screen 800x480x16 -dpi 96 -ac -kb You have your X server running on background. AFAIK this doesn't works, and after a quick test, this is the case in my computer. Try this little change: j...@pluto:~ Xephyr :2 -host-cursor -screen 800x480x16 -dpi 96 -ac -kb === API (apinhe...@igalia.com) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Building hildon library
From: André Hänsel an...@webkr.de I'm trying to make an enhancement to the Hildon library. Unfortunately I cannot figure out how to build it for N900/Fremantle. I have installed the Scratchbox VM and I know how to build applications using ESbox. But how do I build the libraries? Sorry, I'm not familiar with ESbox, but, if you are able to build applications it shouldn't be difficult to build libraries. Both (programs and libraries) use autotools-autoconf stuff. I already fail at finding the current source: Is it http://maemo.gitorious.org/hildon/hildon? Or is it https://garage.maemo.org/scm/?group_id=939? The garage one is a previous-old-legacy repository, the correct one is the gitorious one. So, you can get the code doing something like this: git clone git://gitorious.org/hildon/hildon.git Needs the source to be put in a certain dir inside the scratchbox? No. In fact, normally to put the source in your home directory. But, sometimes, to make quick tests I use directly the /tmp, and it works fine for me. Then do I have to run autogen.sh? In chroot /scratchbox/users/maemo/? Or in chroot /scratchbox/users/maemo/targets/FREMANTLE_ARMEL? autogen.sh is just a script that execute the configure-related programs, and most of the times are tunned for the specific program. So it is required to be executed in the source directory. Anyway, have you tried something like?: myuse...@mymachine:~$ /scratchbox/login $[sbox-FREMANTLE_ARMEL: ~] git clone git://gitorious.org/hildon/hildon.git $[sbox-FREMANTLE_ARMEL: ~] cd hildon $[sbox-FREMANTLE_ARMEL: ~/hildon] dpkg-buildpackage -b -rfakeroot The debian files are included on the repository. debian/rules will call autogen.sh for you. BR === API (apinhe...@igalia.com) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Proposal for new hildon-extras widget
From: Gabriel Schulhof n...@go-nix.ca I've been working on a HildonPannableArea/GtkTreeView-based multicolumn widget to replace GtkMenu widgets. I wanted to do this because, as you know, Pidgin has quite a complex menu structure. I have created a pair of before/after videos that illustrate the new widget: Before: http://www.youtube.com/watch?v=H1xmWLi1dJU After: http://www.youtube.com/watch?v=GlahbMSx8kA Although Fremantle Guidelines are not commands written in stone, I have one doubt. Have you tried to rearrange the menus using that. After all both videos are against the current Fremantle GUI Guidelines. This guidelines are oriented to simplify as much as possible the menus, and avoid nested menus, as the one shown in your first video. The second video just shows that menus in other way, but it still show a lot of menu information in a really small screen, being, IMHO, somewhat messy. Being simplistic, the idea is replace GtkMenu with HildonAppMenu, and avoid the nested menus using stackable windows, as explained here: http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Porting_Software/Redesigning_From_Maemo_4_to_Maemo_5#Limit_of_10_items_in_the_view_menus More information (some are legacy, but basically functional). http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide http://wiki.maemo.org/Legacy_Maemo_5_Documentation/Graphical_UI_Tutorial http://www.forum.nokia.com/info/sw.nokia.com/id/eb8a68ba-6225-4d84-ba8f-a00e4a05ff6f/Hildon_2_2_UI_Style_Guide.html http://wiki.maemo.org/Legacy_Maemo_5_Documentation/Human_Interface_Guidelines Please let me know what you think, Note that I'm not against your work, as there are a lot of valid solutions for the same problem. Just noting that in Fremantle it was made a lot of effort in order to create a GUI style, oriented to mobile devices, and just noting that probably it would be good to test it if is possible to maintain the coherence with other applications as much as possible. BR === API (apinhe...@igalia.com) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Not able to install Hildon Test Automation Framework on N900
From: praveen koduru prawin1...@gmail.com
at-spi is running.
Nokia-N900-42-11:/# ps aux | grep at-spi
1795 root 13832 R/usr/lib/at-spi/at-spi-registryd
2458 root 2088 Sgrep at-spi
I am able to run some applications on N900. But I am able to run only with
dogtail.rawinput functions.
Does it supports Object based refernce to the applications?.
Yes. You could test it with basic gtk applications (gtk-buttons, some
entries). You could try creating one by yourself.
Example. I have tried with Filemanager. I have launched the filemanager with
following command
GTK_MODULES=gail:hail:atk-bridge ossofilemanager
It launched filemanager and I am able to see Nokia N900 folder in that.
and i tried tree.root.dump() and i have got
tree.root.dump()
{root}
Node roleName='application' name='ossofilemanager' description=''
Node roleName='frame' name='File manager' description=''
Node roleName='filler' name='' description=''
Node roleName='filler' name='' description=''
Node roleName='push button' name='' description='' text=''
press
release
click
Node roleName='label' name='' description='' text=''
Node roleName='label' name='' description='' text=''
Node roleName='label' name='' description='' text=''
Node roleName='panel' name='' description=''
Node roleName='application' name='.' description=''
But I am not able to click the Nokia N900 folder. I am not able to click
any object in the appliation. Please help
No idea.
But as I said before, the packages used on that link are really old. 2
years as minimum.
Several changes, included on gail and hail were made since them, so
probably only some of the widgets used on the filemanager are not
exposed. You could try to install recent versions of these packages.
Anyway, take into account that I didn't review in detail the
filemanager.
BR
===
API (apinhe...@igalia.com)
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Not able to install Hildon Test Automation Framework on N900
From: praveen koduru prawin1...@gmail.com Hi , I tried the steps suggested in the following link. http://hildon-test-aut.garage.maemo.org/installation.html This is a really old guide. The target were the Nokia 770/810, not sure if works fine on N900. Steps I have tried: 1. Installed all .deb packages as pointed by the above link. 2. arm_for_testing on. executed the command rebooted 3. Install Dogtail from the above link cd dogtail; ./setup.py install 4. Then tested an example application sniff, which is present in the dogtail. - sniff not working - It throws error ImportError: cannot import name checkForA11yInteractively AFAIK, sniff have never worked. Have you tried to use directly dogtail? Something like: from dogtail import tree tree.root.dump () I enabled Accessibility through gconftool-2 --type bool --set /desktop/gnome/interface/accessibility true This is the way to enable the accessibility in the desktop, and it is more recently that the package version number used in that link. So, in this framework, this gconf variable is not used at all, it is just based on GTK_MODULES and other custom things. But still the same error. I jus tried the following 1. python2.5 2. import pyatspi Traceback (most recent call last): File stdin, line 1, in module ImportError: No module named pyatspi I installed python-at-spi_0.6.1-1osso2_armel.deb package from the above link. but still it is showing no module pyatspi. pyatspi is the last python accessibility bindings. This python-at-spi package is about the old python bindings. Try something like: $python2.5 import atspi And if it works, you could a script like this: #!/usr/bin/env python # Return the name of the applications currently registered import atspi desk = atspi.registry.getDesktop(0) for i in xrange(desk.getChildCount()): app = desk.getChildAtIndex(i) print Index: %d % i try: print Application name: %s % app.getName() print Application elements: %d % app.getChildCount() except Exception: print Error getting name or childcount print All I need is to install dogtail and thus Hildon Test Automation framework successfully and write some test scripts on N900. any Help will be greatly appreciated. As I said, have you tried to use directly dogtail instead of use Sniff? BR === API (apinhe...@igalia.com) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Not able to install Hildon Test Automation Framework on N900
From: praveen koduru prawin1...@gmail.com
Thanks for the quick response Piñeiro.
I tried your 2 steps. Please find the results below.
Step 1:
Nokia-N900-42-11:/home/opt# python
Python 2.5.1 (r251:54863, May 23 2007, 17:32:51)
[GCC 3.4.4 (release) (CodeSourcery ARM 2005q3-2)] on linux2
Type help, copyright, credits or license for more information.
from dogtail import tree
Creating logfile at /tmp/dogtail/logs/log_20100407-130759_debug ...
Detecting distribution: Debian (or derived distribution)
Warning: AT-SPI's desktop is visible but it has no children. Are you running
any AT-SPI-aware applications?
Anyway, please check if at-spi is running.
tree.root.dump ()
{root}
(I have opened contacts and then did tree.root.dump(). but stilll giving
{root} only)
As far as I remember arm-for testing just enable the accessibility
support for the applications included in the testing framework.
What it does is replace the launcher file application, in order to
launch the applications supported with GTK_MODULES=gail:hail:atk-bridge.
Remember that in maemo there are a maemo-launcher/invoker
application. Applications are loaded using this application.
I bet that contacts was not included in this framework, as it is a
really recent application.
You could try to modify by hand the contacts launch file, replacing
/usr/bin/osso-addresbook to something like this:
#!/bin/sh
unset AF_DEFINES_SOURCED
source /etc/osso-af-init/af-defines.sh
export GTK_MODULES=gail:hail:atk-bridge
exec maemo-summoner /usr/bin/osso-addressbook.launch
That is what arm-for-testing does (more or less, AFAIK) for the
supported applications.
Note: probably you should require to reboot the device after that.
Step 2:
import atspi
works fine; I tried the script you have given. script executed but with no
prints
Nokia-N900-42-11:/home/opt# ./Piñeiro.py
Nokia-N900-42-11:/home/opt#
It doesn't print anything as no application is registered on at-spi.
BR
===
API (apinhe...@igalia.com)
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Not able to install Hildon Test Automation Framework on N900
From: praveen koduru prawin1...@gmail.com
I have checked atspi is running or not like this
import atspi
(no errors). Is this the way to check whether it is running or not??
No, I mean something more simple:
ps aux | grep at-spi
I am trying to get the object of Calculator app on N900. I really dont
know how to do that. where as on desktop I did like this for opening an
Totem application.
totem = tree.root.application('totem')
MovieMenu=totem.menu('Movie').click()
This justed worked on Desktop. Whereas to get the object of Calculator
App on Maemo. I did this
Calc=tree.root.application('/usr/bin/osso_calculator')
searching for child of {root}: /usr/bin/osso_calculator application
(attempt 3)
searching for child of {root}: /usr/bin/osso_calculator application
(attempt 4)
... and the trying went on.
As I told you before, arm-for-testing on doesn't enable a11y for all
applications. Take into account that this link is for a automatic
testing framework, so it only include some applications.
In order to load the a11y modules, GTK_MODULES need to be set to
GTK_MODULES=gail:hail:atk-bridge.
arm-for-testing on change the launcher of the supported applications
in order to be sure that GTK_MODULES has the correct values.
So could you please suggest me how to get the object of Calculator and
click one button with that.
You could try the same suggestion I made in the previous mail related
with the contacts application. Try to change the calculator launcher,
in order to use the summoner and have the envvar with the correct
value:
#!/bin/sh
unset AF_DEFINES_SOURCED
source /etc/osso-af-init/af-defines.sh
export GTK_MODULES=gail:hail:atk-bridge
exec maemo-summoner /usr/bin/osso-addressbook.launch
In the same way, you could create a simple gtk application, without
maemo-launcher, and then try to execute it by hand in this way:
$GTK_MODULES=gail:hail:atk-bridge ./my-gtk-application
Thanks a lot for your help.
You are welcome, sorry for not be enough clear in my explanations, and
thanks to test it. I have Try if all a11y pieces works on n900 in my
TODO list for a long time.
-Praveen
BR
===
API (apinhe...@igalia.com)
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: HildonTouchSelector and visible rows
From: Nicolai Hess nicolaih...@web.de Anyone knows how to set the size for the touchselector or knows an example where I can look at. There are a package called libhildon1-examples, with several examples of hildon widgets, including the HildonTouchSelector. You can also see these examples downloading directly the library: git clone git://gitorious.org/hildon/hildon.git BR === API (apinhe...@igalia.com) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: pymaemo, hildon.TouchSelector and gtk.Treeview, hildon-desktop, scripting help
From: Patrick Beck pb...@yourse.de I have only a small logic problem. I have to call a renderer in append_column - None as in the documentation won't work. column = selector.append_column(store_icons, renderer) #i have to call a renderer, not None And the application raises a warning multi_cells_example.py:21: GtkWarning: gtk_tree_view_column_cell_layout_pack_start: assertion `! gtk_tree_view_column_get_cell_info (column, cell)' failed column.pack_start(renderer, 0) but the application works :) As I said before I'm not used to the python bindings, but I'm glad this works for you. The last problem is, if it is possible to place a gtk.Entry field on the hildon-desktop. I get no focus in it. Perhaps the hildon-desktop is only clickable? I have only seen a solution where a seperate dialog will popup. I suppose that what you are creating is a hildon-home applet with a gtk entry. The hildon desktop and hildon-home are special applications, and manage by himself several events, and it only re-sent some of them to the plugins placed on the hildon-home. For example, if you create a applet on the hildon-desktop/hildon-home, you could place a pannable area inside, but you can't interact with it like in a application, because this movements are directly managed by the hildon-desktop, in order to change between desktops. So in the end a pannable area on a applet is useless. Take as example the RSS applet. It shows several RSS feeds, but in order to scroll, it was required to add some scrolling buttons, instead of put a pannable area. Anyway, about the hildon-desktop and hildon-home applets, Kimmo Hamalainen and Jan Arne Petersen have more information. BR === API (apinhe...@igalia.com) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to capture ALL key events, no focus/No-GUI
From: Stefan Iwanowitsch s...@ised.de Hi everybody, I've tried to figure out for some days, how I can capture ALL key events even if I have no focus on my window or if my app is running without GUI. Failed sofar :( Using Fremantle/Hildon/GTK I suppose that you are talking about all key events redirected to your app. You can try to install a key snooper: http://library.gnome.org/devel/gtk/stable/gtk-General.html#gtk-key-snooper-install If you are thinking in all key events in the device, I suppose that this would be more complex. === API (apinhe...@igalia.com) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Programmatically showing the desktop in Fremantle
From: obb770 obb...@gmail.com Given that if there isn't a good way to do this, then it might not be fixed in the Fremantle lifetime - is there an ugly way to show the desktop? like simulating pressing the right place on the screen, somehow getting into non-public API of hildon-desktop, or something else? One option would use the current hildon-desktop a11y support. But probably it isn't really useful, as to do that you would require to install on the device libbonobo, at-spi, cally, etc. Then you could access to the tast-switcher button and click on it, or simulate the X event on the screen. Anyway, as I just said, this solution doesn't seems really comfortable, and seems a über-workaround. Just FYI === API (apinhe...@igalia.com) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: row-activate signal for HildonTouchSelector
From: Neal H. Walfield n...@walfield.org Sorry for the delay. I want to use the HildonTouchSelector widget to enable the user to select an item from a list. I want an action to occur when the user clicks on an item. I don't want the user to have to press another button. The HildonTouchSelector widget provides a changed signal. This is emtited when the active item changes. This appears to be due to the user selecting an item (even the preselected one) or an item (perhaps the active item?) in the model changing via, e.g., a row-changed signal. GtkTreeModel::row-changed can be a cause of the emission of HildonTouchSelector::changed, but normally the emission of the signal is due GtkTreeView::row-tapped. This signal is emitted each time the user tap on one of the GtkTreeView rows. I need to distinguish between these two cases. I only want to act if the user actually clicked on an item. That is, I want the behavior that the media player implements, e.g., in its select artist view. Will someone please suggest how to best achieve this? HildonTouchSelector::changed is more related to GtkTreeSelection::changed that to row-changed. Similarly to GtkTreeSelection::changed [1] this is basically a hint, although we try to be more strict. As far as I know the only misleading behaviour is this one, that the signal could be emitted when the although the value selected has no really changed. One option you have is save the previous selection before that, and then compare the value selected with the user with the previous selection. BR [1] http://library.gnome.org/devel/gtk/stable/GtkTreeSelection.html#GtkTreeSelection-changed === API (apinhe...@igalia.com) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: GtkTreeView behaviour
From: George Kibardin george-kibar...@yandex.ru Thank you Alberto for your code samble. I've found the problem. gtk_container_add() shoud be used instead of hildon_pannable_area_add_with_viewportl(). This is because the treeview has native scrolling support, so it is wrong. There are additional information on : http://library.gnome.org/devel/gtk/stable/GtkScrolledWindow.html#gtk-scrolled-window-add-with-viewport 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. BR === API (apinhe...@igalia.com) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: GtkTreeView behaviour
From: Piñeiro apinhe...@igalia.com From: George Kibardin george-kibar...@yandex.ru Thank you Alberto for your code samble. I've found the problem. gtk_container_add() shoud be used instead of hildon_pannable_area_add_with_viewportl(). This is because the treeview has native scrolling support, so it is wrong. There are additional information on : http://library.gnome.org/devel/gtk/stable/GtkScrolledWindow.html#gtk-scrolled-window-add-with-viewport 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! === API (apinhe...@igalia.com) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: GtkTreeView behaviour
From: Claudio Saavedra csaave...@igalia.com 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. Done. === API (apinhe...@igalia.com) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: GtkTreeView behaviour
From: George Kibardin george-kibar...@yandex.ru
Hi everybody!
I'm porting my application (FeedCircuit) to N900 and faced strange problem. I
have no real device so I'm using scratchbox. According to guidelines (like
this
http://sw.nokia.com/id/a3187f95-ad88-4233-b0ef-a182da3ec1c7/Hildon_2_2_Widget_UI_Specification_v1_0_en.pdf)
when GtkTreeView is put into PannableArea it becomes finger friendly. When
it is created with hildon_gtk_tree_view_new(HILDON_UI_MODE_NORMAL) it should
emit row-activated signal after a single tap on it. In edit mode
hildon_gtk_tree_view_new(HILDON_UI_MODE_EDIT) tap must select/deselect one or
multiple records. In my case for some reason in normal mode I need two taps
to get row-activated signal: one tap to select appropriate item and another
one to activate it. In edit mode with multiple selection enabled I need to
use Ctrl to select multiple items which also seems wrong. What I'm doing
wrong?
In HILDON_UI_MODE_NORMAL you shouldn't require two taps to select an
item. In fact, in this mode there is no selection at all.
This is the reason the row-activated signal is emitted, in order to
get the element selected by the user.
Take into account that due legacy reasons gtktreeview required to
support the old behaviour (desktop and so on) and the fremantle new
behaviour (HILDON_UI_MODE_NORMAL and HILDON_UI_MODE_EDIT were added in
hildon fremantle). In order to do that, a new style property were
added in GtkWidget, called hildon-mode.
You need to set hildon-mode to one, this is normally done on a rc
file.
Anyway this is strange, as in the touch selector we set the
hildon-mode to 1 in this way:
gtk_rc_parse_string (style \fremantle-htst\ {\n
GtkWidget::hildon-mode = 1\n
} widget \*.fremantle-htst\ style \fremantle-htst\
widget_class \*HildonPannableArea.GtkTreeView\
style :highest \fremantle-htst\);
I hope this helps.
BR
===
API (apinhe...@igalia.com)
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Disable portrait support for dialog with Hildon
From: Cornelius Hald h...@icandy.de the main window of my app supports portrait mode. Now I have a settings dialog which does not support portrait mode but it inherits those flags from the main window. So you'll have the main window in portrait mode, and there is a possibility that a dialog in non-portrait mode appear? I'm not a expert in usability, but this would be confusing for me, and it would force me to rotate 90 degrees the device in order to read properly the dialog. There isn't any possibility to support the portrait mode in the dialog? How can I remove the flags from the dialog window? I tried the following, but it does not work: hildon_gtk_window_set_portrait_flags ( GTK_WINDOW (dialog), ~HILDON_PORTRAIT_MODE_SUPPORT); Try with a 0 instead of ~HILDON_PORTRAIT_MODE_SUPPORT. === API (apinhe...@igalia.com) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: orca screen reader
From: jonathan j.nad...@charter.net Hello list, I was wondering if you knew about the orca screen reader working with the n900? Sorry if this isn't the right list to post to about this. Well you asked about a specific application on a maemo based device, so I bet that this is the correct list ;) AFAIK, nobody has tried to port orca screen reader to n900, or at least he didn't make public his efforts. Anyway, as other GNOME projects, probably it would be possible to make the migration, and shouldn't be really really complex (although probably some issues would appear). After all, other a11y related technologies were ported to Maemo, like GAIL, and a library to implement the a11y support for the hildon widgets were created, HAIL (HAIL is an add-on to GAIL, in the same way that the hildon widgets is an add-on to Gtk+). In the same way, there is an old project of maemo test automation using dogtail. Here the link: http://hildon-test-aut.garage.maemo.org/ === API (apinhe...@igalia.com) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: HildonAnimationActor and button events
From: Cornelius Hald h...@icandy.de the documentation of HildonAnimationActor states that by design it is not reactive. Meaning that actors do not receive motion or button events. The thing is, I want to get notified if someone clicks on my actor, so how can I do this? Well, as the documentation says, and you have just said, by design this is not possible. I have a half working solution: I'm using a signal emission hook to catch all button events that have been emitted. Then I translate the button press coordinates into coordinates of the main window. With those coordinates I check whether or not the click was on my actor or not. The problem is, that the signal is propagated further, so if there is, for example, a button under my actor it will also receive the button clicked event. I don't want that. I want that it stops after being handled by my actor. I tried using g_signal_stop_emission() inside the signal hook function, but glib tells me that this is not allowed. I'm really lost here, help would be very much appreciated :) AFAIK, the real purpose of HildonAnimationActor is just what his name indicates, a way to introduce animations on the hildon applications with the help of the window manager, so in fact, it shouldn't be required the feature you want. Why do you want to interact with this actor? What do you want to get? === API (apinhe...@igalia.com) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle Hildon desktop components available from maemo.gitorious.org
From: Kimmo Hämäläinen kimmo.hamalai...@nokia.com Hi, Hildon-desktop, hildon-home, hildon-status-menu, libhildondesktop, libclutter are now developed in open repository: http://maemo.gitorious.org/fremantle-hildon-desktop Now you can start making your own modified Fremantle desktop :) There is any kind of mailing list about that (I know that gitorious doesn't provide it). I have just downloaded it and I have just realized that it is still using the old name of Cally (cail), that was changed because other company [1] was a lot of products using the cail name. This means that the people couldn't compile it, as there isn't any cail library. I would like to create a patch to solve that (it is just to change the library name), where I should send the patch? BR [1] http://www.cail.com/ [2] git clone git://git.clutter-project.org/cally === API (apinhe...@igalia.com) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle Hildon desktop components available from maemo.gitorious.org
From: Kimmo Hämäläinen kimmo.hamalai...@nokia.com This means that the people couldn't compile it, as there isn't any cail library. Of course, I mean using dpkg-buildpackage. Using autogen.sh compile with the a11y support is configurable. I would like to create a patch to solve that (it is just to change the library name), where I should send the patch? I can add you as committer if you have account in gitorious and you can then commit it yourself. Yes, I have a account in gitorious, I'm right now a committer in hildon widgets [1] My account is apinhe...@igalia.com Thanks [1] http://maemo.gitorious.org/hildon/hildon === API (apinhe...@igalia.com) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Hildon Extras project launched
From: Cornelius Hald h...@icandy.de I have just took a quick look. the initial project is set up now. What do we have? - Autotools project that builds a library - 3 Debian packages (the lib, -dev, -doc) but docs are deactivated ATM - pkg-config support - i18n support - HeCheckButton implementation My first fear was about the code style, but you made a good work here, looking at this code is just look to any other Hildon widget, well done! (although now I should revise the code itself if I have some free time :|). The Debian packages build and install/deinstall fine (only quick test). So I think this is a good basis to start with. There are of course still some things to do: - Assign correct copyright everywhere - Add correct email addresses and maintainer names - Add docs stuff (if we want that) - Probably some more small things. Now I really have to sleep - arrggg autotools I'll dream of you... Only a question: why did you use svn. Probably this seems a kind of nitpick, but svn is somewhat declared old fashion. GNOME has switched to git, and hildon itself uses git since some months. Any reason to use svn ? === API (apinhe...@igalia.com) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Community widgets for Fremantle
From: Thomas Perl th.p...@gmail.com 2009/9/26 Cornelius Hald h...@icandy.de: So how about a dialog that just shows n rows with 3 to 4 colors in each row. Those rows are in a panable area so it's easy to scroll them. Those colors are taken from a palette and (maybe) colors that have been selected in the advanced dialog are appended at the top or bottom of that list. Maybe separated by some kind of separator. 8 --- When clicking on of those color buttons a dialog like this opens: http://zwong.de/wp-content/uploads/2009/09/color_chooser_mock.png Probably the buttons/colors should be bigger or there should be 4 in a row. As I said, just a very quick mockup. Those buttons are pannable, so there are more colors available. I'd rather do without the scrolling if possible. Here's my mock-up and the accompanying Python script that you can use to try it out: http://thpinfo.com/2009/maemo/colorchooser.png http://thpinfo.com/2009/maemo/colorchooser.py It looks very fine. Anyway, you can still use the three column color selector and blabla, in order to allow the user to define a custom extra color. I suppose that you have the same idea, as you have the button Advanced. I suppose that when you press this button, a color dialog could appear in order to select a color in detail. Or do you have another idea for this button? === API (apinhe...@igalia.com) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Community widgets for Fremantle
From: Cornelius Hald h...@icandy.de In hildon was not required to created a specific dialog for the HildonDateButton or the HildonTimeButton. Both uses the current HildonPickerDialog. Why do you think that a specific dialog is required? What features do you think that misses HildonPickerDialog? I think a HildonPickerDialog is probably fine. The distinction between the widgets and the dialogs was only made to show that it would be good to have both. A widget and a easy way of showing this widget in a dialog. How this is solved in details is something for the future. Just see this as some vague idea. Ok BTW, as I still think that a future convergence would be a good idea, and as a HildonColorChooserDialog exists yet (the deprecated one), I would use another name, like HildonExtrasColorPickerDialog (just a suggestion). Convergence would surely rock :) Cool. * HildonExtrasColorChooser: A widget that lets the user select a color by only using fingers. I'm not yet sure how it should look like, but personally I would like something with three color wheels or touch selectors for red, green and blue. Then next to it a field shows the composed color of those three 'color wheels'. Plus an area where you have, for example, the last 8 used colors. Hmmm, as far as I see this is just the current (and deprecated) HildonColorChooser. What would be the difference? Bigger buttons (to be more friendly)? Could you make a mockup? No, the concept is quite different, but it's difficult to explain. So, yes, here is a mockup. But warning: It's ugly! I just spend 5 minutes on it, but it should show the concept: http://zwong.de/wp-content/uploads/2009/09/color.png Ok, as far as I see is similar to the proposal I made (see later). AFAIR, when we were talking about that, me (or Claudio) suggested a friendly-finger touch-selector, with a limited amount of colors predefined. Possible, but maybe to limited?! Yeah, probably this could be good to just select the predefined colors, but not to select *any* color. Other option could be a three column (red+green+blue) touch-selector, that allows you to select the mixture you want. I think that's more or less how my mockup works :) Yes, and in fact, we can modify the granularity of each basic color column, like HildonTimeSelector does with the minutes (see property minutes-step). BTW: the problem that I found to hildon-extras name is that is too long ;) HildonExtrasFontSelector seems too long for me. I would prefer a name for the library, probably with a H to infer that is Hildon related (like HAIL-Hildon Accessibility Implementation Library), what about Hexy? (Hildon Sexy), so HexyColorButton and so on. But this is just a question of taste. Something short then HildonExtras would be nice. 'Hexy' would be fine for me. Thanks for your input and keep on discussing :) Conny Ok, it seems that this library will finally be created, I suppose that the next to be discussed is the name, Hexy was just quick suggestion ;) === API (apinhe...@igalia.com) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Community widgets for Fremantle
From: Cornelius Hald h...@icandy.de There are some important widgets which are deprecated without a replacement in Fremantle. Those widgets are still available, but they are not fully finger-friendly or don't look good. As far as I remember, we have a conversation with you about the color selector and picker. But I dont find the exact place :P As far as I remember, the conclusion was that that widgets are interesting, on hildon itself, but nobody has time to do that at that time, due time restraints and priorities. Developers are expected to implement those widgets by them selfs which could lead us to a situation where we have lots of duplicated work and inconsistent behavior between different applications. 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. Well, I suppose that you are thinking in something like libsexy [1], a more-flexible library to put shared effort. Anyway, as I said, probably all this widgets can have a place inside hildon. Would you like that in the future this widgets would be moved to Hildon or you prefer a differen approach? Personally I would like to see the following widgets: * HildonExtrasColorButton: A button that looks like a HildonCheckButton, but instead of the check mark it displays the selected color. When clicking this button a HildonExtrasColorChooserDialog is opened. So in this case, at least in the behaviour, is more similar to the HildonTimeButton or HildonDateButton, but showing a square with the color, instead of the value string. Right? * HildonExtrasColorChooserDialog: A dialog that displays a HildonExtrasColorChooser. In hildon was not required to created a specific dialog for the HildonDateButton or the HildonTimeButton. Both uses the current HildonPickerDialog. Why do you think that a specific dialog is required? What features do you think that misses HildonPickerDialog? BTW, as I still think that a future convergence would be a good idea, and as a HildonColorChooserDialog exists yet (the deprecated one), I would use another name, like HildonExtrasColorPickerDialog (just a suggestion). * HildonExtrasColorChooser: A widget that lets the user select a color by only using fingers. I'm not yet sure how it should look like, but personally I would like something with three color wheels or touch selectors for red, green and blue. Then next to it a field shows the composed color of those three 'color wheels'. Plus an area where you have, for example, the last 8 used colors. Hmmm, as far as I see this is just the current (and deprecated) HildonColorChooser. What would be the difference? Bigger buttons (to be more friendly)? Could you make a mockup? AFAIR, when we were talking about that, me (or Claudio) suggested a friendly-finger touch-selector, with a limited amount of colors predefined. Other option could be a three column (red+green+blue) touch-selector, that allows you to select the mixture you want. (This touch-selector approach could be called HildonExtrasColorSelector, for example) * HildonExtrasFontSelectionDialog: A dialog that lets the user select font face and size. Maybe also font style (bold, italic, ...), color and other things. As I said before, why it is required a specific Dialog? So I would bet for a HildonExtrasFontButton and a HildonExtrasFontSelector. So the button just open a HildonPickerDialog, and put inside a HildonFontSelector, like the current HildonDateButton-HildonDateSelector. * HildonExtrasCheckButton: A button with two labels like a normal HildonButton, but with a check mark on the left like a HildonCheckButton. So basically a HildonCheckButton with two labels. (I'll do that if no one minds). There are probably more widgets, so feel free to write about your ideas and how you think that some widgets should look and behave. Also of course, those names and ideas are not fixed - nothing is fixed, it's just a very early proposal. I just felt, like we should discuss this here, visible for everyone because there have been some discussion about that issue already in other places. Well, as I said, this is a good idea if you think in something like libsexy, in order to have ASAP a place to put this widgets, and the future plan is integrate this widgets or features on Hildon. As we talked before, I agree that give Fremantle-like equivalent widgets to the Hildon 1.0 deprecated widgets is a good idea, and a good idea to put that on Hildon. BTW: the problem that I found to hildon-extras name is that is too long ;) HildonExtrasFontSelector seems too long for me. I would prefer a name for the library, probably with a H to infer that is Hildon related (like HAIL-Hildon Accessibility Implementation Library), what about Hexy? (Hildon Sexy), so HexyColorButton and so on. But this is just a question of taste. So who is interested? Who wants to provide code or mockups? Ideas?
Re: Community widgets for Fremantle
From: Andrew Olmsted andrew.olms...@gmail.com I have started work on a pannable-font-selector and pannable-color-selector (for lack of better names at this point) with the help and input of some of the folks at #maemo. I want to have a dialog and button for each of them as well as you suggest, to make it as easy as possible for the user. Looking at the pannable-font-selector, it seems another HildonTouchSelector subclass. In this case, like the time selector and date selector, I suggest to avoid to use the pannable prefix, as IMHO, is confusing, as it seem to suggest a pannable modification. In the same way, normally on gtk and hildon (and nome libraries in general), the prefix are used to put the name of the library. For this cases I would use something like: libraryname-font-selector.c and libraryname-color-selector.c. BR === API (apinhe...@igalia.com) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Community widgets for Fremantle
From: Claudio Saavedra csaave...@igalia.com 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). Answering myself and Claudio: and of course this is just the other option, and probably the most straighforward. Because although Cornelius, you have asked about the color replacements and so one, and you asked some current Hildon developers about that, that you were creating this new widgets are new for us, and probably would be great to just upload some patches on the bugzilla, instead of just start a new library with them. === API (apinhe...@igalia.com) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle: Opening URLs and local files
From: Claudio Saavedra csaave...@igalia.com 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? In Fremantle you usually use the library hildonmime, and probably you are asking about this function: /** * hildon_mime_open_file: * @con: The D-BUS connection to use. * @file: A %const @gchar pointer URI to be opened (UTF-8). * * This function opens a file in the application that has * registered as the handler for the mime type of the @file. ... This allows you to ask to open a file, and libhildonmime will take care of use the correct application (the applications register itself using this library, something like hey, I can open this mime file). In the same case, AFAIK, you can use hildonmime to ask which applications or actions, you can use with a uri (local file and so on). This could be useful if you want, for example, open the typical open with... pop up. Check hildon_uri_get_actions for this. I hope this helps. gtk_show_uri() should work in theory, but I don't know if it does in practice. As far as I know, most of the Fremantle apps are not using that (although a good question would be why not?). BR === API (apinhe...@igalia.com) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New apps for fremantle with Qt?
From: karoliina.t.salmi...@nokia.com These things are easier in some toolkits and harder in some others. To my knowledge, Gtk was not really designed for handheld touch user interface with kinetic scroll etc. on mind in the first place - it is a rather a desktop toolkit with the rather traditional mindset - and some of hard core hacking obviously was required to make it function like it functions on the Maemo 5. That is a great achievement and I have watched that with awe and lots of respect to the developers who have made it. I can now enjoy it every day with my N900, lists etc. work as they should and they make this UI very desirable. For any reason all the times that Qt advantages were mentioned, they always talk about the kinetic scroll support as the big advantage. Right now hildon has kinetic support, as a new container general container was added, HildonPannableArea [1]. In the same way this Hard core hacking is more than debatable. Yes, the current gtk used on maemo 5 has some maemo-specific changes (hardcode hacks?) but this are just to support some different requirements here, and maintained in a different branch in order to not interfere with the normal upstream work on gtk. But most of this changes are being constantly integrated on upstream. On the other hand, it was a lot easier to start the same from scratch on Startup wizard with Clutter because there was not the incompatible way of thinking as a barrier between the desired functionality and what is already there because there was nothing there already, just start from grass root level from atomic blocks (start by building a custom ClutterActor) and then figure out how to stack Actors and how to animated them to get e.g. a kinetic scroll list done. As there was no base widget, there was no limitations of the base widget and no associated problems, just putting some lego blocks together and it was done. With some adjustable parameters and then fine tuning the feel with these parameters, it was actually quite efficient to do it. So you are suggesting that starting from almost scratch, with basically a base widget support, *in general*, is better that start with a toolkit with a lot of tools, because you have the control of all that you want to do, and you can avoid the constraints of the toolkit? In this case, why use gtk or Qt or Clutter? You can use directly OpenGL and make your app. After all, the N900 has EGL support. I believe Qt can be in the same position pretty much, if the widget is started from scratch rather basing it on some existing widget which has similar limitations than the equivalent in the Gtk. Qt is more like Gtk + Clutter combined rather than being equivalent of the Gtk alone. Kate said there is some kinetic scroll list already there in the Qt, but I don't know how its parameters match to the Hildon/Gtk version we have on the Maemo 5, but I think that with some work it can be done to function 100% equally, as it works equally on startup wizard despite it is a completely separate implementation with a completely different kind of technology behind it. And despite of that, it still just works, perfectly. ... I believe you (or anybody else) are very welcome to pixel perfect and fine tune the list performances of the Qt equivalent widgets if someone creates the missing few hildon widget Qt equivalents. But that was the question from the beginning in this thread. Please read the previous comments. Most of the developers were concerned because there are some Hildon-Gtk widgets, that provides a specific functionality, but they doesn't exist on Qt. The question was if the official Qt-Nokia support has the intention to develop this widgets, in order to made easier have the same lookrfeel, or if they are supposed to be created by the apps developers. And few is not exactly the adjetive I would use. [1] https://git.maemo.org/projects/hildon/?p=hildon;a=blob;f=hildon/hildon-pannable-area.h;h=51690e5f12b0b49b4144787652d13f41b18e05b3;hb=HEAD === API (apinhe...@igalia.com) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New apps for fremantle with Qt?
From: Andre Klapper aklap...@openismus.com Am Freitag, den 04.09.2009, 13:47 +0200 schrieb ext-mox.so...@nokia.com: See https://projects.maemo.org/svn/af/projects/hildon-widgets/trunk/src/ for details of the hildon widgets. Not accessible. As Claudio just said, hildon development was moved to a public repository (git.maemo.org) some months ago: https://git.maemo.org/projects/hildon/gitweb?p=hildon;a=summary Keep in mind that Nokia is a paranoid company, In fact the previous projects.maemo.org link has just a old copy of hildon inside the paranoid-Nokia-repositories. The git one is just updated. hence there is only some limited info available for public at http://wiki.maemo.org/Using_Fremantle_Widgets and http://wiki.maemo.org/Talk:Using_Fremantle_Widgets . ;-)) === API (apinhe...@igalia.com) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
