RE: Launch maemo browser in fullscreen mode
That's right. The fullscreen browser launching is not implemented but it is planned in future (not too soon). Br, --jakub >There is no way to open the opera browser into fullscreen, i >spent quite a bit of time trying various solutions and even >tried implementing the "open embedded browser" via dbus, >however these calls are deprecated. >The only hope is to use a different browser solution as a base. > >Andrew > >Tomàs Jiménez Lozano wrote: >> As a first step to achieve some kind of kiosk mode I am >trying to open >> maemo browser at startup in fullscreen mode. >> >> I've found that, dislike desktop opera browser, maemo browser has no >> command line switch option (--fullscreen) to do this. >> >> I am trying now to launch browser via dbus rpc capabilities. I've >> found some "osso-browser-interface.h" document where it says >the only >> methods available for remote calling are for opening a new window or >> opening a url. >> There is another collection of methods but they seem to be intended >> for embedded browser windows within a main application window. >> One of this "embedded-only" methods allows you to send a HW Key code >> to the browser, that is just what I am trying to do. >> Disgracefully I assume it only works for this "embedded browsers". >> >> Does anyone know if there is a way to open maemo browser in >fullscreen? >> >> >> Thanks in advance >> >> Tomàs Jiménez >> oranginalab >> >> ___ >> 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
Compiler can't find glibconfig.h
I apologize if this is a duplicate. I had problems with the first email I sent. Below is the original message with corrections... Last evening I followed the instructions in the INSTALL.txt of Maemo 3.0 'bora'. I used the automated install scripts. Everything seems to have gone fine. 'hello.c' compiled fine in the SDK_ARMEL environment. However, when I try to compile the sample hildon program I am greeted with a message stating that 'glibconfig.h' cannot be found, and, in fact, it is not there. How do I get past this problem? Thanks, -- Paul ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: N800 won't start
Eero Tamminen wrote: Below I'll go through all bootup problems found so far and tell how to deal with them before the next release (where these are fixed) is released. Thanks Eero - very helpful to have a concise list of workarounds. I've created a thread on ITT which references your posting as it may help a lot of users who fall victim to a reboot loop. Regarding the RSS app, a new crash bug has been found in the last few days when accessing the Joystiq[1] feed - can you verify this feed no longer crashes the modified RSS applet? There is a thread on ITT[2] which discusses the problems with this feed. 1. https://maemo.org/bugzilla/show_bug.cgi?id=1153 2. http://www.internettablettalk.com/forums/showthread.php?p=38977 ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
compiler can't find glibconfigure.h
Last evening I followed the instructions in the INSTALL.txt if Maemo 3.0 'bora'. I used the automated install scripts. Everything seems to have gone fine. 'hello.c' compiled fine in the SDK_ARMEL environment. However, when I try to compile my the sample hildon program I am greeted with a message stating that 'glibconfigure.h' cannot be found, and, in fact, it is not there. How do I get past this problem? Thanks, -- Paul ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Pymaemo GUI wrapper toolkit (v1)
On 3/19/07, Gustavo Sverzut Barbieri <[EMAIL PROTECTED]> wrote: On 3/19/07, Xan Lopez <[EMAIL PROTECTED]> wrote: > Last time I checked they accepted patches. Yes, they accept patches, but many fixes wouldn't be accepted due dumb reasons, personal pride, ... If you're GTK development, you'll be annoyed to see that you have a bunch of set_label, set_value, set_XX that aren't coherent, the reason to don't fix it is API stability, but they keep it since GTK1.x... In my own experience patches are not accepted mainly because of lack of manpower in the core mantainers group in GTK+. They are concerned about this and have sent several proposals to the gtk-devel list in order to improve the situation. Bugfixes are always welcome, and if they are simple enough they are committed without much delay I'd say (just check the commit activity in GTK+ trunk). Again, the situation is not ideal, but there's people working on it. API/ABI breakage just won't be accepted in the 2.x time frame, and ranting about that makes no sense at all. When 3.x development starts you'll certainly be very welcome to give your opinions on how to fix/make consistent the API... IMHO, Nokia and other companies that relies on GTK should put some manpower behind it and specially GLib. These are the pilars of UI, but are undersupported, just check the number of core developers working on these components, rate of patches, number of pending bugs, performance issues, ... And with support I mean full-time hackers, not just giving away some devices at guadec ;-) I work for Nokia so take my opinion as you wish, but I think we're already doing a lot more than giving away a few gadgets. We are pretty busy right now trying to cleanup our platform, but hopefully in the coming months we (at least I) will be able to contribute even more upstream. This is free software, I think I should not need to tell you that you can help more with patches or constructive feedback than with sterile rants in a mailing list. Cheers, Xan -- Gustavo Sverzut Barbieri -- Jabber: [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] ICQ#: 17249123 Skype: gsbarbieri Mobile: +55 (81) 9927 0010 ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: New PyMaemo svn repository
Hi! On 3/19/07, Luciano Miguel Wolf <[EMAIL PROTECTED]> wrote: Our next target is to release a new version with bugfixes (more bindings-e.g.: LibConIC, UCS4 encoding based and d-bus problem). Regarding the DBUS problem, I'm *very* happy to hear you guys are working on it. This means we soon will have new GeoClue positioning backends written with pymaemo... BTW, any news about GConf support in pymaemo? Anyway, obrigado for working on this! Luciano Wolf /Henri -- Henri Bergius Motorcycle Adventures and Free Software http://bergie.iki.fi/ Skype: henribergius Jabber: [EMAIL PROTECTED] ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Summer Of Code Proposal: Wifi Localization
Hi! On 3/19/07, Guy Van den Broeck <[EMAIL PROTECTED]> wrote: Over the past year I have been writing modules and demo applications that use WiFi signal strengths to localise the user inside a building. In urban areas, or inside buildings, where GPS systems often fail, WiFi signals are a good alternative. Sounds interesting. This would be a very nice GeoClue backend. There are 2 possible approaches: -you can use the list of available MAC-addresses to find your position with a resolution of 10s of meters. This can be done by using an (open source) wardriving database like SkyHook's, or wigle.net's. This is also somewhat connected to MaemoPlazer which I'm working on. Currently it only uses your current WiFi access point, but multiple might be interesting too... http://bergie.iki.fi/blog/maemo_plazer_released.html -you can use the signalstrengths together with fingerprints taken on e.g. a university campus or a game hall and find the user's position with a resolution of 1-2 meters. This is suitable for games, musea, etc. A particle filter can be used to calculate the moving user's positions in time. This kind of position data would be very interesting. I trust you're familiar with MIT's Museum Without Walls concept? http://museum.mit.edu/files/presentations/2006-03-15-mwow/pages/page_9.html I have previously implemented this in Java, but I could do it in e.g. Python too. Python (or Mono) would be simpler for the Maemo platform. - is anybody willing to mentor this project? I'd be more than happy to :-) guy van den broeck /Henri -- Henri Bergius Motorcycle Adventures and Free Software http://bergie.iki.fi/ Skype: henribergius Jabber: [EMAIL PROTECTED] ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
SBOX_CPU=arm, not armel?
Hello,
I am using Debian testing (more or less up-to-date), scratchbox 1.0.7,
cs2005q3.2-glibc-arm 1.0.5 and both the
Maemo_Dev_Platform_v2.0_armel-rootstrap.tgz and
Maemo_Dev_Platform_v2.2_armel-rootstrap.tgz.
My problem is that after setting up a new ARM target via sb-menu and
selecting it, "uname -a" says that my architecture is "arm", not
"armel". "arm" is also the value of
SBOX_UNAME_MACHINE/SBOX_DPKG_INST_ARCH in my environment and the setting
of SBOX_CPU in the target's .config file.
I wonder whether I created the target correctly, because apt-get refuses
to install "armel" packages (I
have /scratchbox/devkits/debian/bin/apt-get in my PATH, which was
compiled for i386 and thus searches for that architecture; as a
workaround I can add APT { Architecture "armel"} to its config) and
worse, a package I created is for "arm" and thus does not install on the
770.
How does scratchbox determine which flavor of ARM I want to emulate?
Where do I need to look for an installation mistake?
When I create a target and install the "cputrans" devkit, then I can
select multiple versions of qemu-arm, including versions 0.7.0, 0.8.0,
and arm-0.8.1-sb2 and armeb-0.8.1-sb2. Which one is the right one, if
any?
--
Bye, Patrick Ohly
--
[EMAIL PROTECTED]
http://www.estamos.de/
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers
Re: Pymaemo GUI wrapper toolkit (v1)
On 3/19/07, Xan Lopez <[EMAIL PROTECTED]> wrote: On 3/19/07, Gustavo Sverzut Barbieri <[EMAIL PROTECTED]> wrote: > On 3/19/07, Sean Luke <[EMAIL PROTECTED]> wrote: > > Now that my homework is finished, allow me to gripe: I have never > > dealt with a more buggy, inconsistent, poorly-considered library than > > GTK in my whole life. It is incredible! In the course of building > > this small toolkit I've stumbled across about 30 major GTK bugs, and > > have reported a number of them. I've been able to work around many, > > but sadly not all, of these bugs in my wrapper toolkit. > > I second you here! GTK is a beast, API is really incosistent, > implementation is buggy, ... but we have to live with it :-( Last time I checked they accepted patches. Yes, they accept patches, but many fixes wouldn't be accepted due dumb reasons, personal pride, ... If you're GTK development, you'll be annoyed to see that you have a bunch of set_label, set_value, set_XX that aren't coherent, the reason to don't fix it is API stability, but they keep it since GTK1.x... IMHO, Nokia and other companies that relies on GTK should put some manpower behind it and specially GLib. These are the pilars of UI, but are undersupported, just check the number of core developers working on these components, rate of patches, number of pending bugs, performance issues, ... And with support I mean full-time hackers, not just giving away some devices at guadec ;-) -- Gustavo Sverzut Barbieri -- Jabber: [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] ICQ#: 17249123 Skype: gsbarbieri Mobile: +55 (81) 9927 0010 ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Pymaemo GUI wrapper toolkit (v1)
On 3/19/07, Gustavo Sverzut Barbieri <[EMAIL PROTECTED]> wrote: On 3/19/07, Sean Luke <[EMAIL PROTECTED]> wrote: > Now that my homework is finished, allow me to gripe: I have never > dealt with a more buggy, inconsistent, poorly-considered library than > GTK in my whole life. It is incredible! In the course of building > this small toolkit I've stumbled across about 30 major GTK bugs, and > have reported a number of them. I've been able to work around many, > but sadly not all, of these bugs in my wrapper toolkit. I second you here! GTK is a beast, API is really incosistent, implementation is buggy, ... but we have to live with it :-( Last time I checked they accepted patches. Cheers, Xan -- Gustavo Sverzut Barbieri -- Jabber: [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] ICQ#: 17249123 Skype: gsbarbieri Mobile: +55 (81) 9927 0010 ___ 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: Pymaemo GUI wrapper toolkit (v1)
On 3/19/07, Sean Luke <[EMAIL PROTECTED]> wrote: I've been working behind the scenes on a "wrapper" toolkit around GTK to work around GTK bugs and misfeatures, significantly simplify development, and add some seriously needed features (like object persistence and cleaning up signals) Daniel Amelang asked if the toolkit would be open. The answer is: yes! Here's my first experimental version, plus documentary: http://cs.gmu.edu/~sean/stuff/n800/toolkit/ The library comes with a test function you might find fun. Hi Sean, Since 2 years ago I develop Eagle, a Python module to help GUI development. It was ported to Maemo last year, but due last Canola development I was unable to keep it updated (it lacks menu and toolbars on Maemo), but it mostly works: http://www.gustavobarbieri.com.br/eagle/ PS: SVN is out, since I was keeping my own server that died, I'm waiting for google code to accept the project as "eagle", but I still have to wait since SourceForge already have a project with this name. If I don't get any reply this week (I asked it 3 weeks ago) I'll register it as eagle-py. Eero Tamminen reminded me to work hard to keep persistence database corruption from screwing up the app. I hope I've done an okay job there. Now that my homework is finished, allow me to gripe: I have never dealt with a more buggy, inconsistent, poorly-considered library than GTK in my whole life. It is incredible! In the course of building this small toolkit I've stumbled across about 30 major GTK bugs, and have reported a number of them. I've been able to work around many, but sadly not all, of these bugs in my wrapper toolkit. I second you here! GTK is a beast, API is really incosistent, implementation is buggy, ... but we have to live with it :-( -- Gustavo Sverzut Barbieri -- Jabber: [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] ICQ#: 17249123 Skype: gsbarbieri Mobile: +55 (81) 9927 0010 ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
RE: Summer Of Code Proposal: Wifi Localization
Hi Guy, >I have an idea for a project for the Google Summer of Code. >It's not really mentioned on the "ideas"-page so I'll present >it here first: The maemo ideas page has a mention to Location related projects. >- is this project suitable for maemo? As mentioned, location is one of our preferred chapters. If your idea implies a development based on maemo on this topic, your proposal is on topic. Note that this doesn't mean any acceptance, since this will depend on the other projects presented and the cut made by Google. -- Quim Gil - http://maemo.org ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Summer Of Code Proposal: Wifi Localization
Hi I have an idea for a project for the Google Summer of Code. It's not really mentioned on the "ideas"-page so I'll present it here first: Over the past year I have been writing modules and demo applications that use WiFi signal strengths to localise the user inside a building. In urban areas, or inside buildings, where GPS systems often fail, WiFi signals are a good alternative. There are 2 possible approaches: -you can use the list of available MAC-addresses to find your position with a resolution of 10s of meters. This can be done by using an (open source) wardriving database like SkyHook's, or wigle.net's. -you can use the signalstrengths together with fingerprints taken on e.g. a university campus or a game hall and find the user's position with a resolution of 1-2 meters. This is suitable for games, musea, etc. A particle filter can be used to calculate the moving user's positions in time. I have previously implemented this in Java, but I could do it in e.g. Python too. Now my questions are: - is this project suitable for maemo? - is anybody willing to mentor this project? many thanks guy van den broeck ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: N800 & Video playback
Hi,
On Sun, Mar 18, 2007 at 07:57:36PM +0200, ext Siarhei Siamashka wrote:
> If we look at the framebuffer API. There are two ioctl important for screen
> updates and tearing synchronization if I understand them correctly now:
>
> [...]
You do indeed understand them correctly.
> Looks like graphics bus on N800 is 3x slower than on Nokia 770. It might
> be caused by inefficient framebuffer driver implementation in its initial
> revision. But if it is a hardware issue, getting normal video playback at
> native framerate may be troublesome. Performing software downscaling of
> video before sending data to the graphics chip may be a solution, but it
> sacrifices image quality. Switching to 12bit YUV format from 16bit will save
> ~33% of bus bandwidth, but it can't compensate 3x performance regression
> and may be not enough for 30 fps fullscreen video playback.
Unfortunately, it's a hardware issue. What we can do is get the LCD
controller to perform colourspace conversion from a custom planar format
('YUV420') and the scaling as well. Unfortunately this isn't a
colourkey, but only a simple rectangle, so the semantics are actually
quite complex. But it works well enough that we've shipped an X server
and kernel with this support. We've tried jacking the RFBI frequency up
a bit, and the most we could get was a ~10% improvement, with a loss in
stability: anything above that would kill your device quick smart,
whereas this one only crashed it every day or so.
> As Daniel explained, the next firmware will bring a big improvement in this
> area. I'm not sure whether it is worth to release the next version of MPlayer
> before that, since it will still be far from perfect on N800.
I'd hold your breath, to be honest.
> A preview of the next kernel for beta testing might reduce time needed to get
> MPlayer fully working on N800, but I'm not demanding or expecting anything. It
> is just a matter of time anyway and I'm not so impatient :)
Unfortunately, again, it's not my call: there are various processes to
get things released (legal, in particular), and I can't really pre-empt
those.
> I would be grateful for any comments and corrections. Some things are not
> yet clear to me, figuring them out myself is just a waste of time that could
> be spent on something more useful. Even a small hint may save a huge
> amount of time.
Anything in particular? I thought my last mails on the subject would've
been reasonably exhaustive.
> PS. The last 'inefficient' period of time was when I was struggling with
> gstreamer API (with no prior experience with it) to get MP3 playback in
> MPlayer working on DSP for a few months. Looks like the history repeats.
> Once again, I'm not demanding anything, it is just a matter of 'optimizing'
> development and spending scarce amounts of spare time more efficiently.
> I know that Nokia developers are too busy with their primary work, and
> really appreciate what they are doing. So consider this as a polite request
> for a favour (not necessary to fulfil right now or fulfil at all).
Again, if there are any particular questions I can answer, don't be
subtle: ask me straight up. If I can answer them (some things I can't
necessarily say, some things I don't necessarily know), I will.
Cheers,
Daniel
signature.asc
Description: Digital signature
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers
Re: New project idea, pygtk questions, and a toolkit
Marius Gedminas wrote (a month ago!):
On Mon, Feb 19, 2007 at 12:41:15PM -0500, Sean Luke wrote:
- Why is it in python that you can attach a function, and an instance
variable, to an instance, but you cannot attach a method?
...
There's a distinction between functions, unbound methods and bound
methods. When you assign a function to a class attribute, you get a
unbound method.
This is an imaginary distinction only Python makes, and not for any
good reason. It looks to me like it's historical warts. :-( For
example, in NewtonScript (and Self, etc.), there's no distinction at
all between bound and unbound methods and functions: they're all
functions, and depending on the context in which they're called they
may or may not have 'self' bound to something interesting. CLOS
behaves similarly in this respect.
If by "anonymous" you mean "a function that does not have a name",
then
you can't. You can define a named function in the middle of another
function.
Yeah, that's what I had figured. :-(
I'd like to do this in python with the following equivalent (but
invalid) syntax:
myButton= Button()
myButton.printme = lambda self:
print("hi there")
print("I am " + self)
myButton = Button()
def printme(self=myButton):
print "hi there"
print "I am", self
myButton.printme = printme
Sadly, not the same thing for two reasons. First, because depending
on context we may have polluted the global namespace, and at least
the local namespace, with an arbitrary function name; and second,
depending on context this definition may not permit closures.
Thanks very much for your response anyway, Marius, it was helpful. I
had just hoped for better from this language but that's life.
Sean
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers
New PyMaemo svn repository
Hi all, PyMaemo repository has been migrated to pymaemo.garage.maemo.org site. Anyone who is interested in contributing can now participate. An explanation about how to proceed can be found in PyMaemo svn[1] README file. Feel free to give feedback. Our next target is to release a new version with bugfixes (more bindings-e.g.: LibConIC, UCS4 encoding based and d-bus problem). Thanks to all you that contributed with sugestions and bug reports. Lets improve even more the Python support in Maemo platform. Regards, Luciano Wolf ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: N800 & Video playback
Siarhei Siamashka schrieb: > Looks like graphics bus on N800 is 3x slower than on Nokia 770. It might > be caused by inefficient framebuffer driver implementation in its initial > revision. But if it is a hardware issue, getting normal video playback at > native framerate may be troublesome. It would be a major disappointment if this turns out to be a hardware issue... Regards, Hanno ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Launch maemo browser in fullscreen mode
Hi, David Weinehall wrote: As a first step to achieve some kind of kiosk mode I am trying to open maemo browser at startup in fullscreen mode. In this case you don't want to run Desktop. With the Home key user can always switch to Home or some other window. Not if he modifies /etc/mce.ini first: HomeKeyShortAction=disabled HomeKeyLongAction=disabled should do the trick =) There's still the problem that even although the Browser would start in fullscreen, user can always press the fullscreen key and exit fullscreen mode. This key is interpreted by the Browser itself. Grabbing that key would be kludge way to do anything, it's better not to run Desktop (with which one could switch to another app) and in WM configuration disable minimize & close buttons etc. Eventually Browser will take all memory and not be able to open any new pages. In this case it would be nice if user could close Browser and it would be restarted automatically. Same thing when it crashes... Easiest way to do that would be to use the device SW watchdog for starting Browser, similarly to the input method. Maybe by replacing Desktop in its startup script with Browser and changing the startup policy to what is used for the input method. (see the scripts in /etc/osso-af-init/) - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: N800 & Video playback
On Sun, Mar 18, 2007 at 07:57:36PM +0200, Siarhei Siamashka wrote: > I did some tests with the framebuffer when trying to find a way to reduce > tearing effect in MPlayer. Here are the results. This is a very interesting post. Thanks! Marius Gedminas -- ... Another nationwide organization's computer system crashed twice in less than a year. The cause of each crash was a computer virus -- Paul Mungo, Bryan Glough _Approaching_Zero_ (in 1986 computer crashes were something out of the ordinary. Win95 anyone?) signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Launch maemo browser in fullscreen mode
On mån, 2007-03-19 at 18:08 +0200, ext Eero Tamminen wrote: > Hi, > > ext Tomàs Jiménez Lozano wrote: > > As a first step to achieve some kind of kiosk mode I am trying to open > > maemo browser at startup in fullscreen mode. > > In this case you don't want to run Desktop. With the Home key > user can always switch to Home or some other window. Not if he modifies /etc/mce.ini first: HomeKeyShortAction=disabled HomeKeyLongAction=disabled should do the trick =) [snip] Regards: David ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Launch maemo browser in fullscreen mode
Hi, ext Tomàs Jiménez Lozano wrote: As a first step to achieve some kind of kiosk mode I am trying to open maemo browser at startup in fullscreen mode. In this case you don't want to run Desktop. With the Home key user can always switch to Home or some other window. You might also want to modify the window manager settings (see matchbox documentation for more information). - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Launch maemo browser in fullscreen mode
There is no way to open the opera browser into fullscreen, i spent quite a bit of time trying various solutions and even tried implementing the "open embedded browser" via dbus, however these calls are deprecated. The only hope is to use a different browser solution as a base. Andrew Tomàs Jiménez Lozano wrote: As a first step to achieve some kind of kiosk mode I am trying to open maemo browser at startup in fullscreen mode. I've found that, dislike desktop opera browser, maemo browser has no command line switch option (--fullscreen) to do this. I am trying now to launch browser via dbus rpc capabilities. I've found some "osso-browser-interface.h" document where it says the only methods available for remote calling are for opening a new window or opening a url. There is another collection of methods but they seem to be intended for embedded browser windows within a main application window. One of this "embedded-only" methods allows you to send a HW Key code to the browser, that is just what I am trying to do. Disgracefully I assume it only works for this "embedded browsers". Does anyone know if there is a way to open maemo browser in fullscreen? Thanks in advance Tomàs Jiménez oranginalab ___ 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
Pymaemo GUI wrapper toolkit (v1)
I've been working behind the scenes on a "wrapper" toolkit around GTK to work around GTK bugs and misfeatures, significantly simplify development, and add some seriously needed features (like object persistence and cleaning up signals) Daniel Amelang asked if the toolkit would be open. The answer is: yes! Here's my first experimental version, plus documentary: http://cs.gmu.edu/~sean/stuff/n800/toolkit/ The library comes with a test function you might find fun. Eero Tamminen reminded me to work hard to keep persistence database corruption from screwing up the app. I hope I've done an okay job there. Now that my homework is finished, allow me to gripe: I have never dealt with a more buggy, inconsistent, poorly-considered library than GTK in my whole life. It is incredible! In the course of building this small toolkit I've stumbled across about 30 major GTK bugs, and have reported a number of them. I've been able to work around many, but sadly not all, of these bugs in my wrapper toolkit. Sean ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: wiki locked? Re: Requesting addition to HowTo_EASILY_Boot_From_MMC_card wiki page
"ext Frantisek Dufka" <[EMAIL PROTECTED]> writes: > However it looks like I cannot login with my garage account, time to > ask Ferenc? Yes. I can't speak for Ferenc, but I know that he disabled anonymous edits of the wiki because we had some visits from vandals. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Launch maemo browser in fullscreen mode
As a first step to achieve some kind of kiosk mode I am trying to open maemo browser at startup in fullscreen mode. I've found that, dislike desktop opera browser, maemo browser has no command line switch option (--fullscreen) to do this. I am trying now to launch browser via dbus rpc capabilities. I've found some "osso-browser-interface.h" document where it says the only methods available for remote calling are for opening a new window or opening a url. There is another collection of methods but they seem to be intended for embedded browser windows within a main application window. One of this "embedded-only" methods allows you to send a HW Key code to the browser, that is just what I am trying to do. Disgracefully I assume it only works for this "embedded browsers". Does anyone know if there is a way to open maemo browser in fullscreen? Thanks in advance Tomàs Jiménez oranginalab ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Following the SoC via wiki
The wiki works aain and I have updated http://maemo.org/maemowiki/GoogleSoC2007 with the new proposals and mentors. >From now on we will only report here the main steps. If you want more detailed information please subscribe to the wiki page to receive the changes. -- Quim Gil - http://maemo.org ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Pygtk-glade-maemo
>Hello, > >I created an application using Glade and PyGTK. I am trying to >run it on Maemo platform, but it is not going so well. When I >run it with the command run-standalone.sh ./app, it is working >fine. The problem is when I create a debian package and try to >install it on maemo. The application appears in 'Extras' but >when I click on it, nothing happens. When I try to get to the >Application Manager it appears in the window and disappears >directly after. >Does anyone know how to get a working application in Maemo? >Did anyone had a same or similiar problem? > >Best Regards >Alma I'm using that combination in my gPodder project: https://garage.maemo.org/projects/gpodder/ Please see my source code. Regards, Mika ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: N800 won't start
Hi, (cross-posting to developers) Besides buggy 3rd party packages or software, there are several (rare) reasons why the N800 might not boot. Important things in the symptoms: - Does the device just turn itself off, or does it reboot? - Exactly how many seconds this happens after device is powered on? - Does the device show the progress bar at startup? - Does the device get to Desktop until it reboots? Below I'll go through all bootup problems found so far and tell how to deal with them before the next release (where these are fixed) is released. ext Marius Gedminas wrote: On Sat, Mar 17, 2007 at 12:33:54AM +0100, Paolo Casarini wrote: When i turn on my n800 the progress bar doesn't come up and it never starts. After a minute the screen become black for a second and then back white with the Nokia logo. Have you timed this properly? I think this time should be only a bit over 1/2 minute and is most likely caused by kernel JFFS2 file system taking too much time when garbage collecting (which happens when a lot of data was earlier written so that flash was about full and then most of it was removed) -> as a result device HW watchdog reboots it (HW watchdog has 1/2 min timeout). With the first release this could sometimes (_very_ rarely) happen when the rootfs was mounted i.e. before progress bar. In the second release it could sometimes (_very_ rarely) happen while device was booting (i.e. when progress bar was shown). This latter case should also be fixed in the next release. It's possible (but not guaranteed) the device recovers from this by rebooting again a couple of times. You cannot disable the device HW watchdog, so if this isn't fixed by just device rebooting itself several times, you need to reflash the device. I've seen a n770 act like this. Plugging in the charger, waiting several seconds, and then turning it on helped. If the battery is too low, the device is turned off much earlier. And yes, charging helps for that. It's not a bug. :-) There was also a bug in N800 that if the device rebooted 10 times a row, it's shut down to save battery (expected behaviour). However, sometimes on powering it up again after that kind of a shutdown, it thought that it had already rebooted again those 10 times and shut itself again immediately. This happens *exactly* 6 secs after device boot and can be worked around & is fixed in next release. It's very rare because first you need to get your device in reboot loop. Workaround before next release is setting the device to R&D mode (when this 10xReboot check is disabled) with the flasher tool, booting the device and fixing the issue that caused the earlier 10 succesive reboots. If the behaviour does not get then back to normal when disabling R&D mode[1], backup your data with R&D mode on, turn the R&D mode off and reflash the device. [1] R&D should not be enabled all the time for various reasons on devices which are intended for normal use. Note also that R&D flags are not changed when device is reflashed! I tried to remove the internal or external SD card, but the behaviour is the same. I also tried to use the battery of my old 770 but the N800 won't start. This is one more bug very rare bug, which is related to metalayer-crawler (data indexer for the media player) starting to index MMC immediately on boot when the card is mounted and not handling corrupted FAT filesystem properly. As a result the device is unstable. Corrupted card FAT file system can be fixed with Linux or Windows FAT fcsk program. There has been on claim on the list that the FAT is OK and there's instead an issue with some specific file on the card, but nobody's yet verified this issue or named format of or given link to a file that could cause this kind of a problem. I've to reflash the tablet or I've to go to a Nokia point? A reflash will help only if you've installed or upgraded some software package that broke it. It's something worth trying before you go to Nokia. Doing backups and restoring them from the device control panel is easy, and you anyway need to use that when flashing the further releases (with new features), so I highly recommend doing them. Note that if you install some 3rd party software, it's possible that it fills the device Flash[2] so full that it doesn't anymore function. This can have symptoms similar to the JFFS2 issues explained above. This should be _very_ rare also, but please make a backup of your data & settings before installing 3rd party software! There was also a bug in the RSS applet that it sometimes crashed the Desktop (when it had fetched from added gnome.planet feed image URLs containing several "http://"; strings in the same URL). This resulted in device reboot loop. The applet is fixed in next release also. - Eero [2] Debian package management isn't completely robust against filling the disk, there are some cases when it doesn't handle it. All packages having their own pre/po
