Re: VoIP/OpenVPN
Haudidudi, in OS2008, it still seems that VoIP with the bundled comms software doesen't know how to use TUN interfaces (OpenVPN). Any ongoing work on that? Not currently, but the trick I have been using with OpenVPN has been to enforce the traffic to the tun interface via iptables. Haven't tried on N800, but on one lower scale embedded system running on a 100MHz Cris processor. Should not make a difference, thanks to the abstraction Linux networking system gives us. The down side is of course that you would have to compile net filter support into kernel. On the other hand, this trick will work on any application both current and future. I did even consider to write a support to OpenVPN for the user space queue interface introduced by net filter. Then I could just user firewall rules to send packets to the VPN and would not have to have a separate interface/addressing for the VPN traffic. This was like 5 years ago so I hope that world has developed into a better place since then :-) Br, Sampo ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: GTK+/X based system on 64MB flash and ram size budget?
Dear Trilok, ext Trilok Soni wrote: We need to select an open-source GUI library for system where it will have 64MB of total flash and same RAM size running on the embedded processor like OMAP/DaVinci with around 300MHz. The number of GUI applications running will be only one main control application acting as say recorder, player and streamer and other control functionalities, think video server. Does GTK+/X combination will be a nice fit for this flash, ram and cpu speed budget? OR will be too bloated in terms of minimum functionalities and single GUI application we need? Flash will also have other software images like kernel, bootloader, busybox, uclibc/glibc, boa like embedded webserver stored along with the gtk+/x libraries and gui application. Please give your suggestions/inputs. Thanx. If you don't have something that needs to show arbitrary amounts of data to user such as www-browser or PDF viewer, 64MB is enough. (regardless of widget set or whether you use X or directly fb). Thanx for the inputs. True, it is no where like Internet Tablet, it will not have applications like www-browser or pdf reader. It might support local playback, streaming player, recorder with preview and some other functionalities to control various input and output sources/sinks. In this case using GTKFb looks good, and having d-bus with it to communicate with other CLI daemon applications to transfer messages. Hope GTKfb doesn't limit the use of d-bus, AFAIK. Only limiting thing with GTKFb will be like one should one binary (GUI app) doing everything we want to show it to the end-user. Hope I understood this point. I agree with Eero. We have provided an GTK+/X based linux platform to customers running a 200MHz ARM with 32MB of flash and 64 megs of memory and it all works smoothly. The platform, even if not optimized perfectly, fits into less than 32 megs including a desktop environment that has loaded GTK+ into memory. So this leaves already 32 megs for application to use. For example, doing a VOIP phone, with simple contact list driven UI this is more than enough. One can even add a simple browser, to allow user to login to WLANs etc. Please note that the screen size is one important factor here. The bigger screen means more graphics etc. Also in some cases X can be more memory efficient than DirectFB, for example. Later uses backbuffers for each window where X is more configurable. People always say that X is designed for high end desktops, which is of course true. Only that X11 protocol was designed 20 years ago, so the definition of high end might have changed a little :-) Br, Sampo ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Future development
Richard, I'm sorry, but I don't comment Nokia development in any way. I do advice you to rely only the official information about nokia devices. There is a lot of rumors going around. About open development platforms. We continue the platform work with ARM and it will be available to everybody. Not only on Nokia devices on TI hardware. Also we provide the open source replacements to the components that Nokia has kept propriatary. Br, Sampo Hi I read a reasonable review of the N810 here, http://stuff.tv/blogs/future/archive/2007/10/17/hands-on-with-the-nokia-n810.aspx I'm about to have a go at maemo development, but I have question about the future and openness to develop. The review linked above, touches on the possibility of a SIM version in the future. Hypothetically speaking, if Nokia go down the road of a SIM version, does this mean development and use of a tablet would become restricted, as blogged by Ari Jaaksi, http://jaaksi.blogspot.com/2006_11_01_archive.html Or does it mean the 3G bit would be sand boxed with an interface to use it, and everything else would be open as it is now on the N800/ N810? Rich ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Questions about GUI design on N800
Hi, On Fri, Feb 23, 2007 at 09:15:16AM +0200, ext [EMAIL PROTECTED] wrote: 1. Is it possible to use the display of the N800 in portrait orientation? My application currently runs on a display that is 640x480. 800x480 would be a big advantage, but I can't figure out how to reorganize my layout for 480x800. Did I got you right? 800x480 is the default on N800. Haven't tested screen rotation on N800. On 770 it worked, but one had to gave up few optimizations: http://syslog.movial.fi/archives/7-xrandr-on-nokia-770.html Easiest way is to just run xrandr on N800 and see what happens. That will rotate in software, which is immensely slow. The LCD controller (Hailstorm) can rotate on scanout in hardware, so using that won't be a performance hit, will still let you display videos, and will generally be a great deal faster. That's dtrue and of course should be preffered over software solution. The only advance of the software solution is that it can be easily controlled from the application, but if the goal is to run nothing but this software in kiosk mode I would also vote for the HW solution. Br, Sampo ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Questions about GUI design on N800
Hi, On Fri, Feb 23, 2007 at 09:15:16AM +0200, ext [EMAIL PROTECTED] wrote: Did I got you right? 800x480 is the default on N800. Haven't tested screen rotation on N800. On 770 it worked, but one had to gave up few optimizations: http://syslog.movial.fi/archives/7-xrandr-on-nokia-770.html Easiest way is to just run xrandr on N800 and see what happens. That will rotate in software, which is immensely slow. The LCD controller (Hailstorm) can rotate on scanout in hardware, so using that won't be a performance hit, will still let you display videos, and will generally be a great deal faster. That's dtrue and of course should be preffered over software solution. The only advance of the software solution is that it can be easily controlled from the application, but if the goal is to run nothing but this software in kiosk mode I would also vote for the HW solution. The hardware solution can also be controlled from software, via the exact same API (XRandR). It's just a matter of actually implementing it; the use is exactly the same. I think you got my point: you just need to implement it. :-) Br, Sampo ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Building maemo_af_desktop
Hi, On 4/5/06, Aaron Levinson [EMAIL PROTECTED] wrote: In order to get an empty menu structure, all I did was use ./configure without any options. An examination of the source code demonstrates that it uses the OTHERS_MENU_CONF_DIR define for the default menu location on disk, and OTHERS_MENU_CONF_DIR gets defined as $(sysconfdir)/others-menu. When using ./configure without any options, $(sysconfdir) (along with other directory variables) starts at /usr/local, and the 770 file structure doesn't use /usr/local for anything. At run-time, because it cannot find the others-menu directory, no menu entries are displayed. Too bad the others-menu location is hardcoded this way. Seems like it might be appropriate to use gconf for this. I think you mean Too bad the others-menu location is build-time configurable as that's what it is...? If you build to a different prefix (/usr/local) and the apps install their stuff in another prefix (the usual /etc), is it really a surprise they are not found? In any case you need a predefined location for the .desktops (so that app-devs will know where to put them), so what would be the benefit to have it in gconf? Is that not the case that on debian based systems it is the communly used aproach that prefix defaults to /usr and sysconfdir defaults to /etc right? Which is different from the default of the autoconf as annoying as it can be. The lesson to learn is that make install is bad and only fakeroot dpk-buildpackage -nc should be used when developing debian like stuff. :-) pkgconfig here is a nice thing to have for the applications. The bigger problem is that the actual desktop entry paths are not according to the latest standard described in freedesktop.org menu specification... Br, Sampo ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
RE: [maemo-developers] SDK upgrade failed
Hi, please check your DISPLAY variable. The error message indicates that this could be the problem. I, for example, use 127.0.0.1:2 . I have a vague recollection that using IP address instead of localhost is requred for Xephyr et. al. to work properly. But according to the log the d-bus daemon can not be started either so the display variable can not really have effect here. And also the whining is about loading the binaries. I don't know, but my wild quess would be that you have accidently asked scratchbox to use qemu arm emulation for an x86 target? And when you ask qemu to run an x86 binary on arm emulator.. Well you know. Inside scratchbox please check the contents of /targest/[target-name].config In your case the target name seems to be i386. Around line 9 you should see something like: SBOX_CPUTRANSPARENCY_METHOD=false This means that the binaries are run natively on your host CPU. But if this line states that SBOX_CPUTRANSPARENCY_METHOD should be qemu-arm, you are in trouble :-) I'm not sure, but the error log about failing to load binary could sound like this kind of issue. This is not an user-error, but usability problem in the target configuration of the ancient scratchbox you are using. :-) Br, Sampo -Original Message- From: [EMAIL PROTECTED] on behalf of Nils Faerber Sent: Tue 3/28/2006 6:02 PM To: maemo-developers@maemo.org Subject: [maemo-developers] SDK upgrade failed Hi! I just upgraded my SDK setup to scratchbox 0.9.8.5 and SDK rootstrap to 1.1. After that I cannot start the GUI environment anymore: [sbox-i386: ~/bin] af-sb-init.sh start Note: For remote X connections DISPLAY should contain hostname! Sample files present. Starting Maemo Launcher: maemo-launcher. Starting DBUS system bus Starting D-BUS session bus daemon Error loading /usr/bin/dbus-daemon-1 Error loading /usr/bin/dbus-daemon-1 Starting Sapwood image server Error loading /usr/lib/sapwood/sapwood-server Starting Matchbox window manager Error loading /usr/bin/matchbox-window-manager Starting Keyboard Error loading /usr/bin/hildon-input-method Starting MAEMO AF Desktop [sbox-i386: ~/bin] Error loading /usr/bin/maemo_af_desktop Any idea what is wrong now? Cheers nils faerber -- kernel concepts Tel: +49-271-771091-12 Dreisbachstr. 24 Fax: +49-271-771091-19 D-57250 Netphen Mob: +49-176-21024535 -- ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Best IDE for maemo development?
Hi, A little survey about your development preferences: For the people that develops often on maemo, what IDE/set of tools have you found to be essential to this task? Anjuta? Emacs? Kdevelop? Eclipse? devhelp? ... It could be interesting to know which tools have you found to be more suitable for this task. It could also be interesting to know if you use them to develop maemo itself or userspace apps. And please, keep the flame wars low ^_^. Yeah this is a highly religious subject.. I personally use vim and that's all I need. Encode is still under heavy development, but it looks promising if one likes IDEs. It is developed by Timo Savola who also wrote major parts of scratchbox, so these too are like born to be used together. Also a Xephyr window used to run the maemo in is integrated with encode. Br, Sampo ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] launching applications via .desktop file, process priorities - scummvm problem
Hi, it looks like when there is no service and non-maemo specific process is launched it runs with nice value of -1 i.e. it has higher priority than normal (example scummvm port). If it has service defined it has normal priority (example gaim). Both have similar .desktop files but the maemo specific one has some additional lines with service name etc. That's strange, because the DBus has been patched so that its children (launched programs) do not inherit the priority. I think that what happens is that if you don't have the d-bus service field in desktop file, task navigator cannot launch the application using D-BUS so this D-BUS patch won't help here. If you don't have the service field defined TN simply forks the application and the application inherits the properties of the desktop process. Br, Sampo ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Ideal way to develop a long-running app?
Hi, I'm new to Maemo, and to developing for small/embedded devices in general. I'm trying to wrap my head around the whole concept, especially the 'killable' apps that Maemo enables. I'm trying to figure how long-running but mostly ignored apps like IM clients fit into the whole picture. Sure, you can just mark them killable=false, but that seems inefficient. So I'd like someone to tell me what's wrong with the following scenario: Instant Messaging Application, designed from the ground up for Maemo, architected in 3 or 4 parts: Backend: No GUI but uses libosso, handles all the connection details, buddy list, etc. Stores incoming IMs and uses auto-save to persist them until they're seen. Auto-started on if-up if so configured, or launched by dbus from the front end. killable=false. Frontend: Only GUI, receives dbus messages from backend and displays them to user. Also handles management and configuration of the accounts and buddy lists. killable=true. Launched by maemo-launcher, if that saves memory/time. Statusbar and/or home applet: Displays some sign that there are (not) new IM's that haven't been shown. launches frontend on click/ doubleclick/whatever. So what am I missing? The most likely is that process overhead overshadows the memory saved by only running the GUI portions when needed. And the obvious complexity of the system. What else? As an approximation, I did run the example googletalk VOIP/IM commandline client shipped with google's libjingle and when connected to google talk and having buddylist loaded with no VOIP call going on, it took some 2.5Megs on ARM as resident size. Rough estimate I know, but gives some idea about the memory requirements of an IM running without GUI. To eliminate the process overhead, one could link the libjingle with a StatusBar plugin. Then the parts of the IM that are always running, would run in the same process with the desktop. :-) Of course it could then also crash the desktop too... But in this case one could use the plugin to show dialogs on incoming messages/calls etc. Then when needed, just launch the actual GUI. Might work, but does not have a beautifull architecture as your idea about a backend running. Br, Sampo ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] GtkTreeView / GtkCellRendererToggle issue
Hi, Try setting this to FALSE: http://maemo.org/platform/docs/api/gtk/GtkTreeView.html#GtkTreeView--allow-checkbox-mode Many thanks - that was the problem. It would be useful if these kind of features which are not present in upstream GTK would default to be disabled. I don't think breaking compatibility is a desired feature. Could not agree more. I hope mr. Komulainen will fix this in future.. Br, Sampo ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] debugging on real 770 ?
Hi, You can use gdb on the real N770,if you have a developer rootfs . There are few limitations though. Sometimes 770 runs out of memory when debugging a larger application. Swapping to a mmc or usb harddrive is bit hacky but works. Better option is to setup 770 to act as an CPU transparency device for your scratchbox. Then you can compile stuff inside SB, but it runs on real device. In this case setting up gdb in client server mode is easy and well documented in scratchbox.org Br, Sampo ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] RFC: Qtopia Nokia N770 (maemo) porting layer
Hi, I would be intersted in leading the development of a LGPL/BSD licensed porting layer of the Qtopia platform for the maemo platform. Sounds intresting. Do you mean something like this: http://cvs.sourceforge.net/viewcvs.py/gtk-webcore/NRCore/kwiq/KWQButton.cpp?rev=1.1.1.1view=auto It seems that gtk-webcore implements partial QT - GTK+ adaption layer. Br, Sampo ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Maemo Terminal - 0.1
Hi, So, what you are saying is, menus can be used to display the status of executing commands (or last executed command). If anyone wants to switch between the appviews, menus should be used? Yes. That was the main idea. Although I'm not sure how usable it would be. Note that I can't imagine opening multiple sessions in 770, although I do that all the time on regular sized desktops. So it might be enough to use the TN-functionality. The problem with the TN approach could be (haven't tested) when you have more than a small amount of sessions. How does TN handle let's say, 20 appviews/applications open at the same time? (again, just guessing this time since I haven't tried this myself on maemo). TN will show last four views used as icons in the bar and in its menu it shows all the items. This is a standard GTK menu so it will scroll if needed. If terminal emu use will be restricted to the VKB and the pointer, one could do more with usability by integrating some prediction on shell commands and file names directly in the VKB (some kind of small file/path selector) and some vkb-local command history mainly so that often used commands can be selected quickly, even between the sessions). This is probably impossible to do without taking VKB apart and it would require specialized code, so I'd think it's a no-no. Probably not worth it iff BT keyboards will work. I have been thinking the same. The VKB can predict words little bit like T9 input on a mobile phone, but it is not context sensitive. VKB is pretty modular, so it should not be too difficult to add a prediction engine of your own. I would like to use bash with programmable prediction and then modify libreadline to store the set of strings to complete to to gconf or something like that. Then Gconf would include set of strings for completion for each window or something. This same gconf infra could then be used for email addresses etc. If libreadline is used also gdb and many other command line tools could take advance of it. The problem only is that how to do meaningfull mapping of the sets of strings for completion and x windows that VKB sees. Some 3l1t3 h4X0r x properties, that map to some Gconf keys.. :-) If I had the time, I might have tested this already... IMHO one might use a gnome or matchbox vkb as a base for this since meamo vkb is not optimized for shell usage. It lacks for example ctrl -key. For example, it is impossible to stop ping with the current VKB. :-( The device has a hardware key for escape so there is kind of hardware support for vi which is pretty cool :-) The emacs users would be in trouble, but with all that bloat and limited amount of memory, they would be in trouble anyway :-) Br, Sampo ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
