Re: [maemo-developers] non-maemo apps in toolbar
On Wed, 2006-01-04 at 17:43, Mark Arrasmith wrote: > Because the 770 uses X11 I was interested in porting some X11 and fltk apps > for fun. I compiled Ace of Penguins ( http://www.delorie.com/store/ace/ ) > for the 770. Ace of Penguins is a X11 based card game suite that includes > solitaire, freecell, taipei, and others. > > Basically it is the same thing I did with the Agenda VR3 with I got that > years > ago. So anyway, solitaire runs very fast (it is up and running as soon as > the stylus leaves the screen) and is only 80K. But, it doesn't show up in > the left toolbar when running. Which makes minimizing it kind of worthless. > > I have the X-HildonDesk-ShowInToolbar=true set in the .desktop file. Is > there > anything else I need to do? > > - mark Could be the icon size. Double-check that it is exactly 26x26. You can also try to monitor dbug messages with % dbus-monitr --system -Vlad -- _ Vladislav Grinchenko http://home.comcast.net/~3rdshift/ e-mail: [EMAIL PROTECTED] Focus on quality, and productivity will follow. _ ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] non-maemo apps in toolbar
It's important to note that even if you solve the problem of getting the icon to display in the task bar, a bigger problem exists when an attempt is made to run the software on the device itself. Since it isn't a GTK application, there will be no support for GTK input methods. Effectively, this means that users won't be able to input anything into the application besides mouse strokes and clicks. If the application is entirely mouse-driven, that might be okay, but in addition, it won't be a maemo application, and there will be other issues besides the lack of input methods. As a general rule, building and running strictly X applications isn't going to cut it on the 770, and a true port of a GUI application to the maemo platform requires some programming, quite possibly extensive programming if the original application is only written using X. One may note that the "Porting Existing Application" example on maemo.org demonstrates how to port an already existing _GTK_ application. Aaron On Wed, 4 Jan 2006, Vladislav Grinchenko wrote: > On Wed, 2006-01-04 at 17:43, Mark Arrasmith wrote: > > Because the 770 uses X11 I was interested in porting some X11 and fltk apps > > for fun. I compiled Ace of Penguins ( http://www.delorie.com/store/ace/ ) > > for the 770. Ace of Penguins is a X11 based card game suite that includes > > solitaire, freecell, taipei, and others. > > > > Basically it is the same thing I did with the Agenda VR3 with I got that > > years > > ago. So anyway, solitaire runs very fast (it is up and running as soon as > > the stylus leaves the screen) and is only 80K. But, it doesn't show up in > > the left toolbar when running. Which makes minimizing it kind of worthless. > > > > I have the X-HildonDesk-ShowInToolbar=true set in the .desktop file. Is > > there > > anything else I need to do? > > > > - mark > > Could be the icon size. Double-check that it is exactly 26x26. You can > also try to monitor dbug messages with > % dbus-monitr --system > > -Vlad > -- > _ > Vladislav Grinchenko http://home.comcast.net/~3rdshift/ > e-mail: [EMAIL PROTECTED] > > Focus on quality, and productivity will follow. > _ > > ___ > 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] non-maemo apps in toolbar
On 1/5/06, Aaron Levinson <[EMAIL PROTECTED]> wrote: > It's important to note that even if you solve the problem of getting the > icon to display in the task bar, a bigger problem exists when an attempt > is made to run the software on the device itself. Since it isn't a GTK > application, there will be no support for GTK input methods. > Effectively, this means that users won't be able to input anything into > the application besides mouse strokes and clicks. If the application is > entirely mouse-driven, that might be okay, but in addition, it won't be a > maemo application, and there will be other issues besides the lack of > input methods. Er... what are exactly the other issues ?.. isn't it running linux + x11 after all ? Apart from the input methods that obviously won't work, possibly some other integration problem with matchbox (like this icon thing), and obviously anything dependant to the hardware or memory/cpu hungry.. Things /should/ work, no ? What am I missing ? -- Nicolas Roard "Any sufficiently advanced technology is indistinguishable from magic." -Arthur C. Clarke ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] non-maemo apps in toolbar
On Wednesday 04 January 2006 21:37, Vladislav Grinchenko wrote: > On Wed, 2006-01-04 at 17:43, Mark Arrasmith wrote: > > I have the X-HildonDesk-ShowInToolbar=true set in the .desktop file. Is > > there anything else I need to do? > > Could be the icon size. Double-check that it is exactly 26x26. You can > also try to monitor dbug messages with > % dbus-monitr --system Is this the icon specified in the .desktop file (I just copied the lmarbles desktop file's icons)? Or the one within the application? - mark ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] non-maemo apps in toolbar
On Wednesday 04 January 2006 21:53, Aaron Levinson wrote: > Effectively, this means that users won't be able to input anything into > the application besides mouse strokes and clicks. If the application is > entirely mouse-driven, that might be okay, but in addition, it won't be a > maemo application, and there will be other issues besides the lack of > input methods. I've used things like xstroke and the keymacs keyboard app on tablet PC's as well as the Agenda VR3 ... so it did seem kind of strange how maemo was handling the keyboard. Thanks for the extra info. I suppose I can work around it for now by just porting keymacs to the 770. But, for card games I didn't need a keyboard anyway. > As a general rule, building and running strictly X applications isn't > going to cut it on the 770, and a true port of a GUI application to the > maemo platform requires some programming, quite possibly extensive > programming if the original application is only written using X. Just out of curiosity. Anyone know why this direction way chosen? It is easy enough to have an open system like the typical KDE, GNOME, XFCE, FLTK or whatever toolbar and keyboards like keymacs. Where all the running X11 apps show up and the software keyboard+HWR can write to them. I do this all the time on a tablet PC with an FLTK based keyboard+HWR (keymacs). And I can use KDE or gtk applications without any problem. Basically, why tie input so tightly to maemo? And on an X11 environment where you could run any application? - mark ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] non-maemo apps in toolbar
What exactly are the other issues that I mentioned? Here's a list that is likely incomplete (and doesn't mention those issues already discussed): 1. Full screen support 2. Proper menus, toolbars, titles. For instance, the window for a maemo application, if properly coded, will always fit within the confines of 770's screen and take up as much space as possible. The menu will always be accessible from the menu drop-down (unless in full-screen mode) and the toolbar will always be found at the bottom of the screen (unless it is turned off). And the title of the window will always appear at the same spot. 3. Integration with libosso (refer to libosso APIs for more information). Although, I think it is possible to use libosso without the application being a GTK application. But of course, that requires additional coding. 4. And finally, behaving in a way that 770 users expect, based on the already existing software on the device and developed for the device. These other issues could be considered to be minor nitpicks depending on one's perspective (unlike the input method problem, which is a serious issue). Aaron On Thu, 5 Jan 2006, Nicolas Roard wrote: > On 1/5/06, Aaron Levinson <[EMAIL PROTECTED]> wrote: > > It's important to note that even if you solve the problem of getting the > > icon to display in the task bar, a bigger problem exists when an attempt > > is made to run the software on the device itself. Since it isn't a GTK > > application, there will be no support for GTK input methods. > > Effectively, this means that users won't be able to input anything into > > the application besides mouse strokes and clicks. If the application is > > entirely mouse-driven, that might be okay, but in addition, it won't be a > > maemo application, and there will be other issues besides the lack of > > input methods. > > Er... what are exactly the other issues ?.. isn't it running linux + > x11 after all ? > Apart from the input methods that obviously won't work, possibly some other > integration problem with matchbox (like this icon thing), and obviously > anything > dependant to the hardware or memory/cpu hungry.. Things /should/ work, no ? > What am I missing ? ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] non-maemo apps in toolbar
I think some answers can be found in the Maemo Development Platform White Paper, available at http://www.maemo.org/platform/docs/maemo_exec_whitepaper.html , and in the Hildon UI style guide, available at http://www.maemo.org/community/hildon_ui.html . Aaron On Wed, 4 Jan 2006, Mark Arrasmith wrote: > On Wednesday 04 January 2006 21:53, Aaron Levinson wrote: > > > As a general rule, building and running strictly X applications isn't > > going to cut it on the 770, and a true port of a GUI application to the > > maemo platform requires some programming, quite possibly extensive > > programming if the original application is only written using X. > > Just out of curiosity. Anyone know why this direction way chosen? > > It is easy enough to have an open system like the typical KDE, GNOME, XFCE, > FLTK or whatever toolbar and keyboards like keymacs. Where all the running > X11 apps show up and the software keyboard+HWR can write to them. I do this > all the time on a tablet PC with an FLTK based keyboard+HWR (keymacs). And I > can use KDE or gtk applications without any problem. > > Basically, why tie input so tightly to maemo? And on an X11 environment > where > you could run any application? ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] non-maemo apps in toolbar
> > On Wednesday 04 January 2006 21:53, Aaron Levinson wrote: > > > > > As a general rule, building and running strictly X applications isn't > > > going to cut it on the 770, and a true port of a GUI application to > the > > > maemo platform requires some programming, quite possibly extensive > > > programming if the original application is only written using X. > > I'm discovering this with my port of rdesktop. I have a (very early) alpha running which lets you enter some basic data through a messy GTK+ dialog then runs rdesktop full-screen. The mouse stuff is all fine (although double-clicking takes some effort!) but the big problem is that it's all written in X11 code. I'm going to have to completely rewrite the X stuff for Hildon, replacing the event loop etc (it was difficult enough to port the make to autogen!) This is a good example of how the "unique" nature of the 770's architecture can get you close on a port - but still miles away! :-) Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] non-maemo apps in toolbar
Hi Simon, Did you take a look at the Qt user interface implementation for rdesktop? Shouldn't be too difficult to port to GTK, and it's likely easier to port the Qt code than to port the X user interface implementation, since the Qt code already deals with higher level user interface concepts. You could even start from the QtE (Qt Embedded) implementation. I initially tried something similar with VNC to what you did for rdesktop, but I gave up. Mixing X and GTK tended to cause lots of problems. However, the nice thing about the rdesktop source code is that the user interface implementation is kept separate from the underlying communication protocol implementation, which is not the case for RealVNC's vncviewer implementation. Aaron On Thu, 5 Jan 2006, Simon Guerrero wrote: > > > > On Wednesday 04 January 2006 21:53, Aaron Levinson wrote: > > > > > > > As a general rule, building and running strictly X applications isn't > > > > going to cut it on the 770, and a true port of a GUI application to > > the > > > > maemo platform requires some programming, quite possibly extensive > > > > programming if the original application is only written using X. > > > > > I'm discovering this with my port of rdesktop. I have a (very early) > alpha running which lets you enter some basic data through a messy GTK+ > dialog then runs rdesktop full-screen. > > The mouse stuff is all fine (although double-clicking takes some > effort!) but the big problem is that it's all written in X11 code. I'm > going to have to completely rewrite the X stuff for Hildon, replacing > the event loop etc (it was difficult enough to port the make to > autogen!) > > This is a good example of how the "unique" nature of the 770's > architecture can get you close on a port - but still miles away! :-) > > Simon > ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] non-maemo apps in toolbar
Aaron Levinson wrote .. > Hi Simon, > > Did you take a look at the Qt user interface implementation for rdesktop? > Shouldn't be too difficult to port to GTK, and it's likely easier to port > the Qt code than to port the X user interface implementation, since the > Qt code already deals with higher level user interface concepts. You > could even start from the QtE (Qt Embedded) implementation. I think you're right - I'm going to have a look at it right now. I guess it's because I'm most familiar (source-wise) with the vanilla implementation. Thanks for the advice. > > I initially tried something similar with VNC to what you did for rdesktop, > but I gave up. Mixing X and GTK tended to cause lots of problems. > However, the nice thing about the rdesktop source code is that the user > interface implementation is kept separate from the underlying > communication protocol implementation, which is not the case for RealVNC's > vncviewer implementation. I did try doing some awful cross-breed in the initial stages, using the gtk_x11 functions to map between displays, screens etc but it just didn't work. Stuff wouldn't repaint correctly, the window sizes were all wrong etc. Hence the reason I decided to re-implement in GTK. Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] non-maemo apps in toolbar
Hi, > What exactly are the other issues that I mentioned? Here's a list that > is likely incomplete (and doesn't mention those issues already > discussed): If user cannot switch to an application already having a window open, that should be filed as a bug. I did a quick search on Maemo bugzilla, but didn't find anything. Didn't anybody consider this as a bug??? As to the input method, maybe the program could depend from xkbd (AFAIK doesn't support unicode, but as it works by synthetizing key events with XTest extension it should work with all X programs) and launch it when the program itself is started? > 1. Full screen support That doesn't need Gtk or Maemo support. Just the use of the EWMH standard window property for fullscreen. See: http://www.freedesktop.org/wiki/Standards_2fwm_2dspec Fullscreen key is sent as a normal X key event so that shouldn't be a problem either. > 2. Proper menus, toolbars, titles. These are only look & layout issues, not problems functionality wise. Menu key is also sent as a normal X key event. > 3. Integration with libosso (refer to libosso APIs for more information). I think the only real problem here is that program shouldn't use CPU (*at all*) if it's not visible (either untopped or screen is blanked) and it's not doing something for the user (e.g. playing music). Otherwise it will drain the battery pretty quickly. This shouldn't be any problem for apps that react only to user input and don't do any polling. Other applications (and games), could check either: - if they lose focus (e.g. in fullscreen SDL game) - Matchbox X property for topmost app window (e.g. in Xlib programs), see: http://projects.o-hand.com/matchbox/documentation/developers/matchbox-key.txt And then pause their polling... > 4. And finally, behaving in a way that 770 users expect, based on > the already existing software on the device and developed for the device. Well, one can't get everything. :-) - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] non-maemo apps in toolbar
Hi; Have you tried setting the StartupWMClass key of the apps .desktop file to whatever ace of penguins sets as its WM_CLASS window prop to ( you can find this out with xprop ) ? If it dont set it, you may have to hack ace of penguins so it does. -- Matthew On 1/4/06, Mark Arrasmith <[EMAIL PROTECTED]> wrote: > Because the 770 uses X11 I was interested in porting some X11 and fltk apps > for fun. I compiled Ace of Penguins ( http://www.delorie.com/store/ace/ ) > for the 770. Ace of Penguins is a X11 based card game suite that includes > solitaire, freecell, taipei, and others. > > Basically it is the same thing I did with the Agenda VR3 with I got that years > ago. So anyway, solitaire runs very fast (it is up and running as soon as > the stylus leaves the screen) and is only 80K. But, it doesn't show up in > the left toolbar when running. Which makes minimizing it kind of worthless. > > I have the X-HildonDesk-ShowInToolbar=true set in the .desktop file. Is there > anything else I need to do? > > - mark > > -- > A career is great, but you can't run your fingers through its hair. > ___ > 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] non-maemo apps in toolbar
Hi; On 1/5/06, Nicolas Roard <[EMAIL PROTECTED]> wrote: > Apart from the input methods that obviously won't work, possibly some other > integration problem with matchbox (like this icon thing), The 'icon thing' is *not* a matchbox thing but a maemo-af-desktop thing.. matchbox trys as best it can to support desktop applications with no modifications ( i.e EWMH support and stuff ) but it will never be perfect as some desktop applications are really designed for a desktop ( i.e gimp ) and not for a handheld like UI enviroment which MB primarily aims to support. -- Matthew ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] non-maemo apps in toolbar
Hi; On 1/5/06, Eero Tamminen <[EMAIL PROTECTED]> wrote: > > As to the input method, maybe the program could depend from > xkbd (AFAIK doesn't support unicode, but as it works by synthetizing > key events with XTest extension it should work with all X programs) Xkbd is dead dead dead. Use matchbox-keyboard instead ( its a complete much needed rewrite ), it supports full UTF8 but lacks a couple of minor things like images on keys and themeing. Oh and its svn only :( See; http://svn.o-hand.com/repos/matchbox/trunk/matchbox-keyboard/README > and launch it when the program itself is started? > To make an input window work in maemo env ( this is different to defualt mb input win handling ) you need to have it set its transiency to the window its entering data for. matchbox-keyboard doesn't do this. but you could just embed matchbox-keyboard via XEMBED in some kind of wrapper of your toolkit of choice that handles the transiency or just avoid input windows all togeather and embed it direct in your app. -- Matthew ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] non-maemo apps in toolbar
On Thu, Jan 05, 2006 at 05:36:45PM +, Matthew Allum wrote: > > As to the input method, maybe the program could depend from > > xkbd (AFAIK doesn't support unicode, but as it works by synthetizing > > key events with XTest extension it should work with all X programs) > > Xkbd is dead dead dead. Use matchbox-keyboard instead ( its a complete > much needed rewrite ), it supports full UTF8 but lacks a couple of > minor things like images on keys and themeing. Good! > Oh and its svn only :( See; > > http://svn.o-hand.com/repos/matchbox/trunk/matchbox-keyboard/README Is there something preventing releasing it? :-) > > and launch it when the program itself is started? > > To make an input window work in maemo env ( this is different to > defualt mb input win handling ) you need to have it set its transiency > to the window its entering data for. I think this would be undesirable as then the application window would be resized. This discussion was mostly about stuff like SDL games which don't handle window resizes. Therefore the input method should be above the "application" window, not make it to resize. > matchbox-keyboard doesn't do this. > but you could just embed matchbox-keyboard via XEMBED in some > kind of wrapper of your toolkit of choice that handles the transiency > or just avoid input windows all togeather and embed it direct in your > app. - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] non-maemo apps in toolbar
On 1/9/06, Eero Tamminen <[EMAIL PROTECTED]> wrote: > > To make an input window work in maemo env ( this is different to > > defualt mb input win handling ) you need to have it set its transiency > > to the window its entering data for. > > I think this would be undesirable as then the application window > would be resized. This discussion was mostly about stuff like > SDL games which don't handle window resizes. Therefore the > input method should be above the "application" window, not > make it to resize. seconded. Also, if I am right, this could avoid CPU usage in complex programs like web browser. -- Gustavo Sverzut Barbieri -- Computer Engineer 2001 - UNICAMP Mobile: +55 (19) 9165 8010 Phone: +1 (347) 624 6296; [EMAIL PROTECTED] Jabber: [EMAIL PROTECTED] ICQ#: 17249123 MSN: [EMAIL PROTECTED] GPG: 0xB640E1A2 @ wwwkeys.pgp.net ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] non-maemo apps in toolbar
Hi; On 1/9/06, Eero Tamminen <[EMAIL PROTECTED]> wrote: > > > Oh and its svn only :( See; > > > > http://svn.o-hand.com/repos/matchbox/trunk/matchbox-keyboard/README > > Is there something preventing releasing it? :-) > Yes, layout does not work as good as it should for small displays ( 240x320 ). I wanted to fix this before release. > > > > and launch it when the program itself is started? > > > > To make an input window work in maemo env ( this is different to > > defualt mb input win handling ) you need to have it set its transiency > > to the window its entering data for. > > I think this would be undesirable as then the application window > would be resized. This discussion was mostly about stuff like > SDL games which don't handle window resizes. Therefore the > input method should be above the "application" window, not > make it to resize. > I dont think this can be done currently. best bet would be to XEmbed mb-kb directly in app for this kind of thing. -- Matthew ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] non-maemo apps in toolbar
Hi, On Mon, Jan 09, 2006 at 09:37:25AM -0200, Gustavo Sverzut Barbieri wrote: > > > To make an input window work in maemo env ( this is different to > > > defualt mb input win handling ) you need to have it set its transiency > > > to the window its entering data for. > > > > I think this would be undesirable as then the application window > > would be resized. This discussion was mostly about stuff like > > SDL games which don't handle window resizes. Therefore the > > input method should be above the "application" window, not > > make it to resize. > > seconded. > > Also, if I am right, this could avoid CPU usage in complex programs > like web browser. Battery is affected more how often CPU is used than the "height" of CPU usage spike. As input method comes & resizes application window only on user input, it's not significant from the battery usage point of view. - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] non-maemo apps in toolbar
Hi, On Mon, Jan 09, 2006 at 01:12:40PM +, Matthew Allum wrote: > > > To make an input window work in maemo env ( this is different to > > > defualt mb input win handling ) you need to have it set its transiency > > > to the window its entering data for. > > > > I think this would be undesirable as then the application window > > would be resized. This discussion was mostly about stuff like > > SDL games which don't handle window resizes. Therefore the > > input method should be above the "application" window, not > > make it to resize. > > I dont think this can be done currently. best bet would be to XEmbed > mb-kb directly in app for this kind of thing. Implementing simple non-resizing input method which application cannot control (like it can control the one in 770) is easy, the input method window needs just to be a system dialog so that it keeps above all apps and user doesn't lose it when he switches to another application or desktop. - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] non-maemo apps in toolbar
On 1/10/06, Eero Tamminen <[EMAIL PROTECTED]> wrote: > On Mon, Jan 09, 2006 at 09:37:25AM -0200, Gustavo Sverzut Barbieri wrote: > > > > To make an input window work in maemo env ( this is different to > > > > defualt mb input win handling ) you need to have it set its transiency > > > > to the window its entering data for. > > > > > > I think this would be undesirable as then the application window > > > would be resized. This discussion was mostly about stuff like > > > SDL games which don't handle window resizes. Therefore the > > > input method should be above the "application" window, not > > > make it to resize. > > > > seconded. > > > > Also, if I am right, this could avoid CPU usage in complex programs > > like web browser. > > Battery is affected more how often CPU is used than the "height" > of CPU usage spike. As input method comes & resizes application > window only on user input, it's not significant from the battery > usage point of view. I'm not taking battery in account, just the perceived slowness to resize/re-render the whole screen. I still don't have the device, but from what I've read, it takes some time to open the vkb for the first time due Opera's slow -rendering... or I misunderstood? -- Gustavo Sverzut Barbieri -- Computer Engineer 2001 - UNICAMP Mobile: +55 (19) 9165 8010 Phone: +1 (347) 624 6296; [EMAIL PROTECTED] Jabber: [EMAIL PROTECTED] ICQ#: 17249123 MSN: [EMAIL PROTECTED] GPG: 0xB640E1A2 @ wwwkeys.pgp.net ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] non-maemo apps in toolbar
Hi, On Tue, Jan 10, 2006 at 11:00:09PM -0200, Gustavo Sverzut Barbieri wrote: > > Battery is affected more how often CPU is used than the "height" > > of CPU usage spike. As input method comes & resizes application > > window only on user input, it's not significant from the battery > > usage point of view. > > I'm not taking battery in account, just the perceived slowness to > resize/re-render the whole screen. I still don't have the device, but > from what I've read, it takes some time to open the vkb for the first > time due Opera's slow -rendering... or I misunderstood? Further resizes of browser window are not slow (nor any of the resizes on any other applications), so the slowness has to be something else that Browser does when its window size decreases significantly for the first time. (Btw. I've also noticed that the first time you launch browser after bootup, freezes the desktop for several seconds. This doesn't happen with any other application.) - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] non-maemo apps in toolbar
Le mardi 10 janvier 2006 à 23:00 -0200, Gustavo Sverzut Barbieri a écrit : > On 1/10/06, Eero Tamminen <[EMAIL PROTECTED]> wrote: > > On Mon, Jan 09, 2006 at 09:37:25AM -0200, Gustavo Sverzut Barbieri wrote: > > > > > To make an input window work in maemo env ( this is different to > > > > > defualt mb input win handling ) you need to have it set its transiency > > > > > to the window its entering data for. > > > > > > > > I think this would be undesirable as then the application window > > > > would be resized. This discussion was mostly about stuff like > > > > SDL games which don't handle window resizes. Therefore the > > > > input method should be above the "application" window, not > > > > make it to resize. > > > > > > seconded. > > > > > > Also, if I am right, this could avoid CPU usage in complex programs > > > like web browser. > > > > Battery is affected more how often CPU is used than the "height" > > of CPU usage spike. As input method comes & resizes application > > window only on user input, it's not significant from the battery > > usage point of view. > > I'm not taking battery in account, just the perceived slowness to > resize/re-render the whole screen. I still don't have the device, but > from what I've read, it takes some time to open the vkb for the first > time due Opera's slow -rendering... or I misunderstood? This bug was not present in the initial firmware (2005.40-2 IIRC), it was introduced in the first firmware update and was not fixed since. The desktop slow rendering at initial startup was also not present in the initial firmware. -- Frederic Crozat <[EMAIL PROTECTED]> ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
