Re: [maemo-developers] Cairo benchmarking
> For simple static images it not gonna be too much of a problem ( FP > API ) but in an animation where things are getting called over and > over again its pain :(. > > Its kind of dissapoiting cairo never got a fixed point api ( though it > probably would have seemed a little wierd to lucky FPU owning folks ) > . A possible future solution could be a GL like api offering similar > api calls but each taking different argument types ( fixed and float > ). I wonder why the API should make such a bit difference - I am quite sure that cpu/memory throughput is far more a problem. The ARM9 in tne 770 is quite a bit, well, turkey ... and to fill a 100x100 shape which is quite a bit more complex than a rectangle needs many million cylcles. You can see this when benchmarking the X11 implementation of the device - quite nice but to fill a larger pixmap with a color takes ages of course. Btw. a simple test to see wether its really the FP API which causes the bad performance would be to render the whole stuff into a very small surface and see wether the performance improves a lot. lg Clemens ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Warning. Installing Maemo Development Platform
Luca De Cicco wrote: >Hi there this is my first post on this ml. I'm quite sorry for the >subject of this post (it would have better if i'd announce release of >some package...) > >This day i downloaded Maemo Development Platform from the maemo website >and i was happy to know what was new and suddenly found out that all >interesting stuff is not included in this rootfs. > >Basically after installing the MDP you will have anything but XTerm and >an Hello World application and no way to get non-free packages. Also it >seems that the there's no way at the moment to get the product >filesystem back because the rootfs file is currently unavailable on the >nokia web-site. > >So if you want to flash your device with the MDP SDK please have in mind >that you will have an unusable device for the daily use at least until >someone will get the product rootfs back on the nokia site. > For that reason there is the warning in my blog in regarding the instructions of flashing. To do a new product based on 770, use SDK rootimage, it is an empty table for adding anything on top of it. To use 770 as 770 plus develop apps for it, just use the product image (current IMHO). Karoliina ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] homearea background is white ?
hi, my homearea background is white ? why ? regards. wang baisheng ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] home_me_set_home_background error
hi, When I click "home_app_home_name --> home_me_set_home_background", matchbox gvies the following error : (home:20457): libgnomevfs-CRITICAL **: gnome_vfs_uri_extract_short_path_name: assertion `uri != NULL' failed (home:20457): libgnomevfs-CRITICAL **: gnome_vfs_uri_get_host_name: assertion `uri != NULL' failed (home:20457): libgnomevfs-CRITICAL **: gnome_vfs_uri_get_path: assertion `uri != NULL' failed (home:20457): GLib-CRITICAL **: g_strrstr: assertion `haystack != NULL' failed Best regards. Wang baisheng ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Synchronization Application?
Hi, if installing these sync tools isn't really an option for you, there's an easy way to import ical formated calendar files into gpe-calendar. I've written a small script (http://c0ffee.org/stuff/conv.pl) that will convert an ical file to a series of sql commands. Run those using sqlite 2.x on an empty calendar file as created in ~/.gpe/calendar to import your data regards -- jochen ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Cairo benchmarking
Hi; On 10/27/05, Kalle Vahlman <[EMAIL PROTECTED]> wrote: > 2005/10/27, Matthew Allum <[EMAIL PROTECTED]>: > > Hey; > > > > Though internally cairo is mostly fixed point, its api is floating point - > > the 770 ( like most ARM devices ) lacks an FPU and thus any FP operations ( > > especially with hardfloat ) are slowww and really should be avoided. > > Yes, I'm painfully aware of that ;) > > Although I was also under the impression that cairo would be utilizing > floats heavily on the inside, which does not seem to be all true. For simple static images it not gonna be too much of a problem ( FP API ) but in an animation where things are getting called over and over again its pain :(. Its kind of dissapoiting cairo never got a fixed point api ( though it probably would have seemed a little wierd to lucky FPU owning folks ) . A possible future solution could be a GL like api offering similar api calls but each taking different argument types ( fixed and float ). -- Matthew ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: compatibility vs speed and bloat Re: [maemo-developers] gtk+ builtin stock icons removed
Gustavo Sverzut Barbieri wrote: Could you do some tests if basic maemo platform compiles with uclib and how much space it saves? Both static (file size) and dynamic (apps running). Maybe, but not in very near future. I still haven't got the device and when I get it I will try something easier first or something more interesting or practical. I was mainly interested if someone else was already thinking about this or not. If it proves valuable nokia people may consider. I don't think so. It is probably too late for such change. Once you see shipping maemo binaries from 3rd parties based on glibc it is not very practical to change such core part of system. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Cairo benchmarking
2005/10/27, Matthew Allum <[EMAIL PROTECTED]>: > Hey; > > Though internally cairo is mostly fixed point, its api is floating point - > the 770 ( like most ARM devices ) lacks an FPU and thus any FP operations ( > especially with hardfloat ) are slowww and really should be avoided. Yes, I'm painfully aware of that ;) Although I was also under the impression that cairo would be utilizing floats heavily on the inside, which does not seem to be all true. > Also as yet cairo isn't heavily optimised and without any kind of supported > h/w acceleration cairo operations can be very cpu intensive especially on a > relatively large display. Yeah, to be honest, I expected cairo to perform even worse than it actually does. -- Kalle Vahlman, [EMAIL PROTECTED] Powered by http://movial.fi ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Cairo benchmarking
Hey; Though internally cairo is mostly fixed point, its api is floating point - the 770 ( like most ARM devices ) lacks an FPU and thus any FP operations ( especially with hardfloat ) are slowww and really should be avoided. Also as yet cairo isn't heavily optimised and without any kind of supported h/w acceleration cairo operations can be very cpu intensive especially on a relatively large display. -- Matthew On 10/27/05, Kalle Vahlman <[EMAIL PROTECTED]> wrote: Hola list!I started to write a little Cairo animation to better introduce myselfto the wonders of it, and thought I'd do a little Cairo benchmarkingwith it on the 770.The setup:Compiled cairo 1.0.2 with vanilla settings, and copied to the device.Compiled my demo with -O3The device was not the latest HW nor SW, so the results might be a tadworse than they are on the current devices. Haven't rerun the benchmark yet on newer devices.The demo:It consists of: - creating a XLib surface from the X window - creating image surface for background (only on startup) - copying from that to a buffer surface to clear bg when drawing - drawing a simple shape with lines and few bezier curves on the buffer surface - copying the drewn areas to the xlib surfaceI don't know if this is the most efficient way to draw with cairo, Imight be doing something foolish here and slowing down the process (please say that I do?-).The results:Not that convincing.I ran the demo with 1, 5 and 10 objects drawn simultaniously, and theFPS calculated from those are 5.71, 2.6 and 1.51.So nowhere near "smooth" animation. I tried to compile the cairo with the softfloat toolchain inscratchbox but that made cairo refuse to draw anything (not sure whatgoes wrong there), although it doesn't crash or complain.The timings for the last three items in the above list tell that the slowest parts are (not suprisingly) the item drawing (0.048s per itemconsistently) and the transferring to the xlib surface (0.099s for 1item, 0.115s for 10 items).Intresting note is that the xlib surface transfer is apparently well buffered, and does not grow linearily with the item count. Still theinitial hit is big enough.This is of course presented in the context of animation, but I thinkthat if you can't do smooth animation (somewhere between 10-15FPS) with simple objects, it won't be fast enough for UI either.The biggest bottleneck seems to be indeed the object drawing (I'dguess the beziers are to blame), but I intend to test drawingdifferent types of elements once I get the time, plus a better profiling of what's taking so long and where.The test results are attached, as well as the demo (the code is littlemessy and contains excess stuff as it's been "evolving").--Kalle Vahlman, [EMAIL PROTECTED]Powered by http://movial.fi___maemo-developers mailing list maemo-developers@maemo.orghttps://maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Cairo benchmarking
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gustavo Sverzut Barbieri wrote: > could you please try something using enlightenment Evas? > > It's supposed to be much faster than cairo. It's something entirely different, evas is a canvas (like gnomecanvas) and cairo is a nice way to use vector graphics. Gtk 2.8 uses cairo as a backend, so optimizing cairo would be more interesting as running evas. Anyway, I did some evas benchmarking on other linux hardware a few weeks ago. Attached are the results with fb, x11 and gl rendering. The conclusion was that evas is slooow on the tested ARM devices. regards, Koen > > -- > Gustavo Sverzut Barbieri > --- > Computer Engineer 2001 - UNICAMP > GPSL - Grupo Pro Software Livre > Cell..: +55 (19) 9165 8010 > Jabber: [EMAIL PROTECTED] > ICQ#: 17249123 >MSN: [EMAIL PROTECTED] > Skype: gsbarbieri >GPG: 0xB640E1A2 @ wwwkeys.pgp.net > ___ > maemo-developers mailing list > maemo-developers@maemo.org > https://maemo.org/mailman/listinfo/maemo-developers > -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iD8DBQFDYSdZMkyGM64RGpERAvLwAKCKsOj/n/7PK4EV3AkRQ9yhoTPOdACfeT/o /WkyWmV68/4uMpqmt14e1sQ= =cbSv -END PGP SIGNATURE- Evas performance tests.rtf Description: RTF file ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] Warning. Installing Maemo Development Platform
Hi there this is my first post on this ml. I'm quite sorry for the subject of this post (it would have better if i'd announce release of some package...) This day i downloaded Maemo Development Platform from the maemo website and i was happy to know what was new and suddenly found out that all interesting stuff is not included in this rootfs. Basically after installing the MDP you will have anything but XTerm and an Hello World application and no way to get non-free packages. Also it seems that the there's no way at the moment to get the product filesystem back because the rootfs file is currently unavailable on the nokia web-site. So if you want to flash your device with the MDP SDK please have in mind that you will have an unusable device for the daily use at least until someone will get the product rootfs back on the nokia site. I really hope that this problem will be fixed soon and that my next post will be about some new package announcement :) Regards, Luca ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: compatibility vs speed and bloat Re: [maemo-developers] gtk+ builtin stock icons removed
On 10/27/05, Frantisek Dufka <[EMAIL PROTECTED]> wrote: > Eero Tamminen napsal(a): > >>I know this is pretty bold comment from me but if you think 30KB is > >>enough to break compatibility, why not to use uClibc instead of glibc or > >>ipkg packaging system from Familiar instead of full dpkg and .deb? > > > > > > Package database and tools don't consume RAM. > > > Well they take flash space and RAM only when executed. Bigger binary and > database may also flush file cache that could make the device feel > slower after installing something. sure > > uClibc is not binary compatible to Debian. Glibc and the Maemo Gtk > > are both. You can for example take Debian ARM strace binary directly > > from debian repo and copy it to the device and it works... > > Yes, but is such binary compatibily useful? Do you actually repackage > anything direcly from debian without any changes? Is recompiling too > much work? Will the target audience for N770 actually try to install any > debian package for ARM (like strace or something gtk based) when there > is even no terminal in production version? +1 > There should be other reason for using glibc, like that it is better and > not slower or not substantialy bigger or something like this :-) Or > maybe you cannot compile Opera of Flash player with it. GTK and xfree > seems to work at least on i386 > > http://www.emdebian.org/links.html - Erik Andersen's uclibc version of > Debian > http://people.debian.org/~andersee/uwoody/main/binary-i386/ > > I know everybody went with glibc (Sharp on Zaurus, Familiar for iPAQs) > but if performance is priority and everything for the platform has to be > recompiled anyway, uClibc based system may save more than 30KB of RAM > per proccess. Or maybe not or there are other problems. I don't know the > answer, that's why I asked. Could you do some tests if basic maemo platform compiles with uclib and how much space it saves? Both static (file size) and dynamic (apps running). If it proves valuable, nokia people may consider. -- Gustavo Sverzut Barbieri --- Computer Engineer 2001 - UNICAMP GPSL - Grupo Pro Software Livre Cell..: +55 (19) 9165 8010 Jabber: [EMAIL PROTECTED] ICQ#: 17249123 MSN: [EMAIL PROTECTED] Skype: gsbarbieri GPG: 0xB640E1A2 @ wwwkeys.pgp.net ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Cairo benchmarking
could you please try something using enlightenment Evas? It's supposed to be much faster than cairo. -- Gustavo Sverzut Barbieri --- Computer Engineer 2001 - UNICAMP GPSL - Grupo Pro Software Livre Cell..: +55 (19) 9165 8010 Jabber: [EMAIL PROTECTED] ICQ#: 17249123 MSN: [EMAIL PROTECTED] Skype: gsbarbieri GPG: 0xB640E1A2 @ wwwkeys.pgp.net ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: compatibility vs speed and bloat Re: [maemo-developers] gtk+ builtin stock icons removed
Eero Tamminen napsal(a): I know this is pretty bold comment from me but if you think 30KB is enough to break compatibility, why not to use uClibc instead of glibc or ipkg packaging system from Familiar instead of full dpkg and .deb? Package database and tools don't consume RAM. Well they take flash space and RAM only when executed. Bigger binary and database may also flush file cache that could make the device feel slower after installing something. uClibc is not binary compatible to Debian. Glibc and the Maemo Gtk are both. You can for example take Debian ARM strace binary directly from debian repo and copy it to the device and it works... Yes, but is such binary compatibily useful? Do you actually repackage anything direcly from debian without any changes? Is recompiling too much work? Will the target audience for N770 actually try to install any debian package for ARM (like strace or something gtk based) when there is even no terminal in production version? There should be other reason for using glibc, like that it is better and not slower or not substantialy bigger or something like this :-) Or maybe you cannot compile Opera of Flash player with it. GTK and xfree seems to work at least on i386 http://www.emdebian.org/links.html - Erik Andersen's uclibc version of Debian http://people.debian.org/~andersee/uwoody/main/binary-i386/ I know everybody went with glibc (Sharp on Zaurus, Familiar for iPAQs) but if performance is priority and everything for the platform has to be recompiled anyway, uClibc based system may save more than 30KB of RAM per proccess. Or maybe not or there are other problems. I don't know the answer, that's why I asked. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] flasher utility - new versions for MacOS X and PowerPCs running LInux
On Thu, Oct 27, 2005, Sjoerd Simons wrote: > It crashes on my powerbook running Debian sid: > > # ./flasher.linux_ppc --query-rd-mode > Suitable USB device not found, waiting > *** glibc detected *** corrupted double-linked list: 0x10093568 *** > zsh: 32458 abort ./flasher.linux_ppc --query-rd-mode I've bumped to that bug also a couple of times. One solution is to turn on the 770 at the right moment so that the flasher doesn't go into the loop of waiting for the device to be found (i.e. turn on 770 and almost immediately afterwards run the flasher tool). Johan ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] Cairo benchmarking
Hola list!
I started to write a little Cairo animation to better introduce myself
to the wonders of it, and thought I'd do a little Cairo benchmarking
with it on the 770.
The setup:
Compiled cairo 1.0.2 with vanilla settings, and copied to the device.
Compiled my demo with -O3
The device was not the latest HW nor SW, so the results might be a tad
worse than they are on the current devices. Haven't rerun the
benchmark yet on newer devices.
The demo:
It consists of:
- creating a XLib surface from the X window
- creating image surface for background (only on startup)
- copying from that to a buffer surface to clear bg when drawing
- drawing a simple shape with lines and few bezier curves on the buffer surface
- copying the drewn areas to the xlib surface
I don't know if this is the most efficient way to draw with cairo, I
might be doing something foolish here and slowing down the process
(please say that I do?-).
The results:
Not that convincing.
I ran the demo with 1, 5 and 10 objects drawn simultaniously, and the
FPS calculated from those are 5.71, 2.6 and 1.51.
So nowhere near "smooth" animation.
I tried to compile the cairo with the softfloat toolchain in
scratchbox but that made cairo refuse to draw anything (not sure what
goes wrong there), although it doesn't crash or complain.
The timings for the last three items in the above list tell that the
slowest parts are (not suprisingly) the item drawing (0.048s per item
consistently) and the transferring to the xlib surface (0.099s for 1
item, 0.115s for 10 items).
Intresting note is that the xlib surface transfer is apparently well
buffered, and does not grow linearily with the item count. Still the
initial hit is big enough.
This is of course presented in the context of animation, but I think
that if you can't do smooth animation (somewhere between 10-15FPS)
with simple objects, it won't be fast enough for UI either.
The biggest bottleneck seems to be indeed the object drawing (I'd
guess the beziers are to blame), but I intend to test drawing
different types of elements once I get the time, plus a better
profiling of what's taking so long and where.
The test results are attached, as well as the demo (the code is little
messy and contains excess stuff as it's been "evolving").
--
Kalle Vahlman, [EMAIL PROTECTED]
Powered by http://movial.fi
#include
#include
#include
#include
#include
#include
#include
#define PI 3.1415926535
#define WIDTH 720 /* 720 800 */
#define HEIGHT 420 /* 420 480 */
#define NUM_LEAFS 5
typedef struct win {
Display *dpy;
int scr;
Window win;
GC gc;
int width, height;
KeyCode quit_code;
cairo_surface_t *surface;
cairo_surface_t *bg_surface;
} win_t;
typedef struct leaf leaf_t;
struct leaf {
int x;
int y;
int old_x;
int old_y;
int phase;
int direction;
int potential;
int kinetic;
int x_speed;
int y_speed;
void (*draw_leaf) (cairo_t *cr, leaf_t *leaf);
};
static void win_init(win_t *win);
static void win_deinit(win_t *win);
static void win_draw(win_t *win);
static void win_handle_events(win_t *win);
/* Drawing functions */
static void draw_background (cairo_t *cr, win_t *win);
static void draw_squirle (cairo_t *cr, leaf_t *leaf);
static void draw_box (cairo_t *cr, leaf_t *leaf);
/* World alteration */
static void advance_time (int delta);
leaf_t *leafs;
int
main(int argc, char *argv[])
{
int i;
win_t win;
win.dpy = XOpenDisplay(0);
win.surface = NULL;
if (win.dpy == NULL) {
fprintf(stderr, "Failed to open display\n");
return 1;
}
leafs = (leaf_t *) calloc (NUM_LEAFS, sizeof(leaf_t));
if (leafs == NULL)
{
fprintf(stderr, "Failed to allocate memory\n");
return 1;
}
for (i=0; iwidth = WIDTH;
win->height = HEIGHT;
root = DefaultRootWindow(win->dpy);
win->scr = DefaultScreen(win->dpy);
win->win = XCreateSimpleWindow(win->dpy, root, 0, 0,
win->width, win->height, 0,
WhitePixel(win->dpy, win->scr),
WhitePixel(win->dpy, win->scr));
visual = DefaultVisual(win->dpy, DefaultScreen (win->dpy));
win->surface = cairo_xlib_surface_create (win->dpy, win->win, visual,
win->width, win->height);
win->bg_surface = cairo_image_surface_create (CAIRO_FORMAT_ARGB32,
win->width, win->height);
cr = cairo_create(win->surface);
cairo_set_source_rgba (cr, 1, 1, 1, 1);
cairo_rectangle (cr, 0, 0, win->width, win->height);
cairo_fill (cr);
cairo_stroke (cr);
cairo_destroy (cr);
cr = cairo_create(win->bg_surface);
cairo_set_source_rgba (cr, 1, 1, 1, 1);
cairo_rectangle (cr, 0, 0, win->width, win->height);
cairo_fill (cr);
draw_background(cr, win);
cairo_stroke (cr);
cairo_destroy (cr);
win->quit_code = XKeysymToKeycode(win->dpy, XStringToKeysym("Escape"));
XSelectInput(win->dpy, win->wi
Re: [maemo-developers] flasher utility - new versions for MacOS X and PowerPCs running LInux
On Thu, Oct 27, 2005 at 12:07:06AM +0300, Ferenc Szekely wrote: > Hello, > > Big thanks to Johan and Onne: we have flasher runnning on MacOS X and on > Linux "powered" PowerPC. You can find them here (behind the bars;) : > http://maemo.org/downloads/d3.php It crashes on my powerbook running Debian sid: # ./flasher.linux_ppc --query-rd-mode Suitable USB device not found, waiting *** glibc detected *** corrupted double-linked list: 0x10093568 *** zsh: 32458 abort ./flasher.linux_ppc --query-rd-mode Sjoerd -- Don't make a big deal out of everything; just deal with everything. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Problem with Maemo's version of GTK
to be honest I am a bit sad since the question about changes to maemo's gtk turned into a discussion about the qemu version bundled with scratchbox ;-) Nevermind, however would be great if anybody could help me a bit with the GTK trouble *please* ;-) I really don't know any further :-( Thanks, lg Clemens ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] Fixing the stock icons issue
Hi, To get back to the problem.. The problem is that whether you use the builtin icons or not, the instant you load the first icon you get the 30k penalty per process. This shouldn't be necessary and the gtk+ team has said they'd be willing to consider a patch that changes the lookup priority so that builtin icons are loaded only as last resort, when absolutely needed. The comment in gtk/gtkicontheme.c(theme_lookup_icon) is misleading, there's no need to search builtin icons first. Should be relatively straightforward thing to fix for someone with interest and time in their hands. -- Tommi Komulainen<[EMAIL PROTECTED]> ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Problem with Maemo's version of GTK
On Thu, 27 Oct 2005, Timo Savola wrote: > On Thu, Oct 27, 2005 at 04:49:49PM +0300, Kaj Grönholm wrote: > > > One should not run applications inside QEMU arm emulation, as it does > > not work well enough for that (at least 0.9.8.4, later .5 and 1.0.x > > versions work a bit better). > > I've had no problems running AF and other GTK+ apps with 0.9.8.5's > version of qemu. > > timo AFAIK the only working version of qemu is in 0.9.8.5. The situation is somewhat unclear because maintenance version of old stable branch has been released later than the new stable branch ;) Of course this doesn't mean that it can run all applications that are out there. IMHO best option is to use the 770 as a CPU-transparency device thus using the actual device for doing the arm stuff. Then one could use for example gdb server/strace for debugging on real device to find out what is happening. All graphics could be pointed to devices screen instead of xnest/xephyr/xvnc so even the UI can be debugged better. If the device is not available one must stick to qemu/other arm box for CPU-transparency which is not as good as described above. -- Valtteri Rahkonen [EMAIL PROTECTED] http://www.rahkonen.org +358 40 5077041 ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Re: Flasher debs
ext Timo Steuerwald wrote: >>We can not provide the flasher anywhere else then behind the "License >>Acceptance" page. We can create a deb package however and put it there, >>but only there. >> >> >> > I don't understand where's the difference between the current way and > the common debian way: Displaying the license acceptance after > downloading and *before* installing the package as already described > from Valtteri. > That's a good question and belive me we have asked the same from the lawyers. Unfortunately there is no way at the moment to go around this problem. >>The idea is good, but we it would mean extra maintenance work whenever >>we update the repository. I know it did not happen too often (I mean >>updating packages) in the past 5 months, but hope this will change :) >> >>In case somebody creates such a package for 1.1rc5 then we could >>check|test and then upload it to the repository. >> >> > Ok, currently every developer does this "extra maintenance work" on its > own... :-( > ...as long as somebody creates that package. This few guys here will not have time for that in the coming days, I can tell you :( > Cheers, > > Timo > Br, ferenc ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Re: Flasher debs
Ferenc Szekely wrote: Hello, ext Aleksandr Koltsoff wrote: On Thursday 27 October 2005 15:59, Aleksandr Koltsoff wrote: I agree with Timo on this one. Just came up with another package that could be placed in such repo. The documentation html-stuff. Would be nice to be able to download the docs in proper /usr/share/doc-path when going on a trip with a laptop (or even with GPRS). Would make updating docs and flasher easier as well (would be part of regular apt-get update -process). We can not provide the flasher anywhere else then behind the "License Acceptance" page. We can create a deb package however and put it there, but only there. I don't understand where's the difference between the current way and the common debian way: Displaying the license acceptance after downloading and *before* installing the package as already described from Valtteri. The idea is good, but we it would mean extra maintenance work whenever we update the repository. I know it did not happen too often (I mean updating packages) in the past 5 months, but hope this will change :) In case somebody creates such a package for 1.1rc5 then we could check|test and then upload it to the repository. Ok, currently every developer does this "extra maintenance work" on its own... :-( Cheers, Timo ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Problems with Maemo developer rootfs
Le 27 oct. 05 à 17:06, Christian Fredrik Kalager Schaller a écrit : Hi, So I downloaded and installed the Maemo_Dev_Platform_rootfs_v1.1rc5.jffs2 update from http://www.maemo.org/downloads/d1.php, but now I am unable to access the 770 due to no input seeming to work anymore. Touching the screen with the stylus only manages to get the backlight turned on, but apart from that nothing responds on the screen. I flashed it yesterday, and it worked without problem Try to remove the battery and try again. Is this caused by me doing something wrong when flashing the device or is stylus support disabled with the dev images? it is supported. It also lead me to discover the other problem, there is no archive of the normal production/end-user images, so I had nothing to restore to. The link posted to this list a while ago also seems to be dead. i noticed that also, except that i did download the archive days ago. I think an archive with each of the released images would be a good idea as it also would let outside developers downgrade and check if a arisen problem is due to a regression underneath them. Excellent suggestion. Anyway, any suggestions on how I could get my 770 out of its current vegetative state would be appreciated. Although the flashing has made a GNU gnu logo appear on the top bar, which is kinda nice I would still prefer input actually working :) The Gnu Logo launch the Hello World App :D ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] Problems with Maemo developer rootfs
Hi, So I downloaded and installed the Maemo_Dev_Platform_rootfs_v1.1rc5.jffs2 update from http://www.maemo.org/downloads/d1.php, but now I am unable to access the 770 due to no input seeming to work anymore. Touching the screen with the stylus only manages to get the backlight turned on, but apart from that nothing responds on the screen. Is this caused by me doing something wrong when flashing the device or is stylus support disabled with the dev images? It also lead me to discover the other problem, there is no archive of the normal production/end-user images, so I had nothing to restore to. The link posted to this list a while ago also seems to be dead. I think an archive with each of the released images would be a good idea as it also would let outside developers downgrade and check if a arisen problem is due to a regression underneath them. Anyway, any suggestions on how I could get my 770 out of its current vegetative state would be appreciated. Although the flashing has made a GNU gnu logo appear on the top bar, which is kinda nice I would still prefer input actually working :) Sincerely, Christian ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
compatibility vs speed and bloat Re: [maemo-developers] gtk+ builtin stock icons removed
Hi, > I know this is pretty bold comment from me but if you think 30KB is > enough to break compatibility, why not to use uClibc instead of glibc or > ipkg packaging system from Familiar instead of full dpkg and .deb? Package database and tools don't consume RAM. > I know Familiar distribution used ipkg because full dpkg was overkill > and used glibc mainly for better compatibility with other arm/debian > based devices but if Maemo is different anyway and don't care about > compatibility why not to try uclibc? uClibc is not binary compatible to Debian. Glibc and the Maemo Gtk are both. You can for example take Debian ARM strace binary directly from debian repo and copy it to the device and it works... Maemo is only visually "incompatible" to Gtk. :-) (different themes, theme-engine, and now also icons) - Eero Ps. If you look closely at the product file system, you'll notice that the product uses both glibc and uclibc (not at the same time though :)). ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Re: Flasher debs
Hello, ext Aleksandr Koltsoff wrote: > On Thursday 27 October 2005 15:59, Aleksandr Koltsoff wrote: > >>I agree with Timo on this one. Just came up with another package that could >>be placed in such repo. The documentation html-stuff. Would be nice to be >>able to download the docs in proper /usr/share/doc-path when going on a >>trip with a laptop (or even with GPRS). Would make updating docs and >>flasher easier as well (would be part of regular apt-get update -process). > > We can not provide the flasher anywhere else then behind the "License Acceptance" page. We can create a deb package however and put it there, but only there. About the docs: You can check out the whole source of the website from svn (only the forrest based stuff): https://stage.maemo.org/svn/website We will provide some scripts and a how-to about rebuilding the site on your PC. (They are ready, so it is a bit of testing and then publishing.) > This could be taken a step further infact. Assume that a separate repo would > exist for debian-based development. > > Make a package called 'maemo-sdk'. It would contain preinst/postinst logic to > download and install the sdk files (user could be asked to select whether > they want to install both x86 and arm-versions). It would also depend on the > flasher-deb and the documentation-deb (if one would exist). Could also depend > on devhelper, but could be difficult to do so that it devhelper would include > the versions of datafiles suitable for exact GTK/Glib-versions used in the > SDK. So, it would also install sbox, and configure the targets (by using > default names "SDKx86" and "SDKarm" or similar). It would also configure > xephyr and such. > > This way getting and starting the SDK would be simplified for new users as > well as the sbox version supported by the SDK could be limited to 0.9.8.5 (or > whatever will be supported in later versions). > > This requires real work on N's part though, but isn't impossible. > The idea is good, but we it would mean extra maintenance work whenever we update the repository. I know it did not happen too often (I mean updating packages) in the past 5 months, but hope this will change :) In case somebody creates such a package for 1.1rc5 then we could check|test and then upload it to the repository. Cheers, Ferenc ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Re: Flasher debs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ferenc Szekely schrieb: > ext Timo Savola wrote: >>How about providing Debian packages (i386 and powerpc) of the flasher? >>It would be in line with the recommendation to use Debian or Ubuntu for >>development with maemo. Or would the (click-through) license prohibit >>that (or make it unfeasible)? > yes, it is the license that prohibits us to distribute the tool in a > debian repo. we could place the deb packages to the same place, but it > does not help much, i guess. It would at least help with installation. You could then install a package and have the file management of the package management handling the installation and potential removal of the package. So there are advantages even if not using a repository... > br, > ferenc Cheers nils faerber - -- kernel concepts Tel: +49-271-771091-12 Dreisbachstr. 24 Fax: +49-271-771091-19 D-57250 Netphen Mob: +49-176-21024535 - -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDYOo5JXeIURG1qHgRAhm7AKD9AVk6uPJrgR4hiGOsCRmoOl6xwACdGawz i+Re1QjaFFhcYlR/5pr7OOY= =o8av -END PGP SIGNATURE- ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
compatibility vs speed and bloat Re: [maemo-developers] gtk+ builtin stock icons removed
Tommi Komulainen wrote: This message was brought to you by the performance police. The builtin stock icons compiled in the gtk+ library are causing extra >30k dynamic memory consumption regardless of whether they're ever used. In 770 all icons are coming from the icon theme anyway, so this is a cheap and simple optimization to do. And everyone loves to have better performance, right? :) I know this is pretty bold comment from me but if you think 30KB is enough to break compatibility, why not to use uClibc instead of glibc or ipkg packaging system from Familiar instead of full dpkg and .deb? I admit I still don't have the device so I'm watching all this from a distance but I am curious why you went for full glibc and dpkg. Did you evaluate uclibc and ipkg at Nokia and found it is not good enough? Or is glibc and dpkg not considered bloated in embedded devices anymore? I know Familiar distribution used ipkg because full dpkg was overkill and used glibc mainly for better compatibility with other arm/debian based devices but if Maemo is different anyway and don't care about compatibility why not to try uclibc? I also admit I now lived in PalmOS world for few years so my knowledge about recent changes in linux on ARM is a bit outdated and I actually never tried uclibc on ARM, only i386. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Problem with Maemo's version of GTK
On Thu, Oct 27, 2005 at 04:49:49PM +0300, Kaj Grönholm wrote: > One should not run applications inside QEMU arm emulation, as it does > not work well enough for that (at least 0.9.8.4, later .5 and 1.0.x > versions work a bit better). I've had no problems running AF and other GTK+ apps with 0.9.8.5's version of qemu. timo ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Problem with Maemo's version of GTK
> One should not run applications inside QEMU arm emulation, as it does > not work well enough for that (at least 0.9.8.4, later .5 and 1.0.x > versions work a bit better). Well, of course I tested it on the real device since I got SigSev when running it using Qemu. Running it on the real device lead to the problem I've described in the first mail, any ideas where this problem could comes from? > QEMU works perfectly for building the arm versions of applications > thought, so that you can install & run them in real N770. As far as I understood Qemu is not involved in the building process at all, since programs like gcc/make/... are all compiled for the HOST-target and therefor native i368 programs. lg Clemens ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Problem with Maemo's version of GTK
Hi, > although it works with the x86-version of maemo running in scatchbox, > sadly I was not able to run it on arm-emulation since it dies with > Signal11 (in fact any program that is a bit more complicated bahaves > strange when running in qemu). One should not run applications inside QEMU arm emulation, as it does not work well enough for that (at least 0.9.8.4, later .5 and 1.0.x versions work a bit better). QEMU works perfectly for building the arm versions of applications thought, so that you can install & run them in real N770. - Kaitsu - ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] kernel sources
--- Koen Kooi <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Koen Kooi wrote: > > Paul Mundt wrote: > > > >>>On Fri, Oct 21, 2005 at 11:31:40AM +0200, Koen Kooi wrote: > >>> > >>> > Any news on the kernel sources? > >>> > >>> > >>>http://lkml.org/lkml/2005/10/12/87 > > > > > > I guess the dev program doesn't count as 'sale' or 'distributing'? > > Anyway, I'll wait for the source to be available on maemo.org. > > And the wait is over! The source is available from the debian repo. I checked this link: http://repository.maemo.org/pool/maemo1.1rc5/free/source/k/kernel-source-2.6.12.3/ It shows empty ! Nothing there :( ---Komal Shah http://komalshah.blogspot.com/ __ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Re: Flasher debs
On Thursday 27 October 2005 15:59, Aleksandr Koltsoff wrote: > I agree with Timo on this one. Just came up with another package that could > be placed in such repo. The documentation html-stuff. Would be nice to be > able to download the docs in proper /usr/share/doc-path when going on a > trip with a laptop (or even with GPRS). Would make updating docs and > flasher easier as well (would be part of regular apt-get update -process). This could be taken a step further infact. Assume that a separate repo would exist for debian-based development. Make a package called 'maemo-sdk'. It would contain preinst/postinst logic to download and install the sdk files (user could be asked to select whether they want to install both x86 and arm-versions). It would also depend on the flasher-deb and the documentation-deb (if one would exist). Could also depend on devhelper, but could be difficult to do so that it devhelper would include the versions of datafiles suitable for exact GTK/Glib-versions used in the SDK. So, it would also install sbox, and configure the targets (by using default names "SDKx86" and "SDKarm" or similar). It would also configure xephyr and such. This way getting and starting the SDK would be simplified for new users as well as the sbox version supported by the SDK could be limited to 0.9.8.5 (or whatever will be supported in later versions). This requires real work on N's part though, but isn't impossible. ak. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Superwaba Re: [maemo-developers] JamVM on 770 (Java)
Hello, On Thu, Oct 27, 2005 at 12:09:02PM +0200, Frantisek Dufka wrote: > Just a warning. SuperWaba is very good but no longer free. Since version > 5.x authors invented new business model and started to charge for LGPLed > version (approx. 500$ per year). The version they call GPLed is still > free but mostly only as in beer and the future is not bright. This is the major drawback of SuperWaba: the choice of the SuperWaba developpers to make it not free as in speech. > Anyone who want free (both as speech and beer) java virtual machine > should look elsewhere. Please note this (from the SuperWaba web site[1]): "However, SuperWaba does not implement any portion of Java specification and has no connection to Sun Microsystems, the owner of the Java brand and related trademarks." In short: SuperWaba, like Waba is not Java ! Now, a little bit history of some Waba VM based projects... At the begin, there was Waba. Waba, by Rick Wild from wabasoft[2]. The main motivations were: - mobility, - functionality, - reliability, - portability. This original Waba is released under the GPL, and exists for PalmOS and WinCE devices. Based on this initial release, there was many forks, with many different motivations. Majors motivations for the forks are the port to other systems (like Zaurus, DOS, TI Calculator, Newton, Gameboy Advance, Linux, ...). When started, SuperWaba target was to add more functionality (application writted for SuperWaba don't run anymore under Waba). And to my opinion, this was bad. They breaked in many ways portability. But this was their choice: have a better virtual machine for PalmOS and WinCE. Another important fork was Waba at SourceForge[3]. Waba @ SourceForge motivations are: - Open Source, - portability, - small and fast. Waba @ SourceForge has a working Waba VM running on many OS, like Linux, FreeBSD, Solaris, uCLinux, PalmOS, Win32, toppers, ruputer. The Linux, FreeBSD, Solaris port can be used either with GTK or PicoGUI[4]. This is for the history. Now, the actual state... - original Waba is no more maintained. Rick Wild has no more motivations for it since a very long time (last Waba VM for PalmOS is dated of February 2000. - SuperWaba is now based on a business model with double licences : GPL and LGPL, but they have annotated the LGPL version... It seems also they are running on more hardware than just PalmOS and WinCE, but I don't now really more. - Waba @ SourceForge is no more active since about two years now. But it is OpenSource, and was working on many devices with limited resources. So, do we need to have one instance of Waba working under the 770 ? I don't really now. And if this is yes, which one to choose ? My suggestion is to look at both SuperWaba and Waba @ SourceForge. But my feeling is to choose Waba @ SourceForge if you really want to port one of the Waba VM... Why ? Hummm... Maybe because I'm the current maintainer of it. :-) I know, I know, I'm no more active on it since more than 2 years... But if they are interest, I can start working on it again. Of course, for this, I need a device... I'm waiting that the Switzerland goes in the list of countries where we can order the 770. (I was accepted in the developer program discount...). Have a nice day. Olivier, waiting on 770 delivery in Switzerland. [1] http://www.superwaba.com.br/ [2] http://www.wabasoft.com/ [3] http://waba.sourceforge.net/ [4] http://picogui.org/ -- Olivier Bornet|français : http://puck.ch/f Swiss Ice Hockey Results |english : http://puck.ch/e http://puck.ch/ |deutsch : http://puck.ch/g [EMAIL PROTECTED]|italiano : http://puck.ch/i Get my PGP-key at http://puck.ch/pgp or at http://pgp.mit.edu/ signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Re: Flasher debs
On Thursday 27 October 2005 15:49, Timo Savola wrote: > On Thu, Oct 27, 2005 at 03:42:04PM +0300, [EMAIL PROTECTED] wrote: > > On Thu, 27 Oct 2005, Aleksandr Koltsoff wrote: > > > Other possibility is making a separate deb repo for tools that one > > > would find useful when developing on debian, but since flasher is the > > > only tool at the moment, that might be an overkill. > > > > > > ak. > > I think that Timo wanted a debian repo that could have been put to a > > sources.list and installed with apt-get. Single debian package that would > > be downloaded via web page and installed to host with dpkg (after > > click-through license agreement) is IMHO quite pointles because then it > > would require one step more to use the flasher. > Actually, I wanted none of those things. I want a Debian package that > shows up in the dpkg database (with proper version information) so that I > don't have any unaccounted-for files installed on my system. > > Downloading a file using a browser and installing it with dpkg is as easy > than adding a line to sources.list, updating and installing. (I suspect > that the flasher isn't going to be updated very often.) I agree with Timo on this one. Just came up with another package that could be placed in such repo. The documentation html-stuff. Would be nice to be able to download the docs in proper /usr/share/doc-path when going on a trip with a laptop (or even with GPRS). Would make updating docs and flasher easier as well (would be part of regular apt-get update -process). ak. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Re: Flasher debs
On Thu, Oct 27, 2005 at 03:42:04PM +0300, [EMAIL PROTECTED] wrote: > On Thu, 27 Oct 2005, Aleksandr Koltsoff wrote: > > > On Thursday 27 October 2005 10:45, Ferenc Szekely wrote: > > > ext Timo Savola wrote: > > > > How about providing Debian packages (i386 and powerpc) of the flasher? > > > yes, it is the license that prohibits us to distribute the tool in a > > > debian repo. we could place the deb packages to the same place, but it > > > does not help much, i guess. > > > > How about placing the deb packages somewhere where people download the SDK > > from? Should probably be a separate directory with a README that would note > > that the deb is not meant to be installed within SDK env. It would help > > though. > > > > Other possibility is making a separate deb repo for tools that one would > > find > > useful when developing on debian, but since flasher is the only tool at the > > moment, that might be an overkill. > > > > ak. > > I think that Timo wanted a debian repo that could have been put to a > sources.list and installed with apt-get. Single debian package that would > be downloaded via web page and installed to host with dpkg (after > click-through license agreement) is IMHO quite pointles because then it > would require one step more to use the flasher. > > On the other hand if at install phase license agreement would be enough to > satisfy legal issues it could be provided by debian repo. Then if user > disagrees with the license installing would fail or something. I'm not > sure that this would satisfy legal issues but would be doable from > technical point of view. Of course using dpkg-deb to package would mean > that user can access the binary without accepting the license ;) Actually, I wanted none of those things. I want a Debian package that shows up in the dpkg database (with proper version information) so that I don't have any unaccounted-for files installed on my system. Downloading a file using a browser and installing it with dpkg is as easy than adding a line to sources.list, updating and installing. (I suspect that the flasher isn't going to be updated very often.) (If such a package would be provided, then the name of the executable and the package should be something more Nokia/OSSO/Maemo/770-specific than "flasher.") timo ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] Problem with Maemo's version of GTK
Hello again, While playing a bit with classpath-based jvm's on my 770 I found a quite interresting problem I can't explain myself. When I try to create an offscreen-image in java I get the following assertion: jamvm[1625]: GLIB CRITICAL ** GLib-GObject - g_object_ref: assertion `G_IS_OBJECT (object)' failed although it works with the x86-version of maemo running in scatchbox, sadly I was not able to run it on arm-emulation since it dies with Signal11 (in fact any program that is a bit more complicated bahaves strange when running in qemu). The source-code is pretty simple, I attached it at the end of the mail. The only problems I could imagine: - JamVM is broken and passes a "broken" pointer to the native code, so that cp_gtk_image_get_pixmap does actually not return something useful. This could be but is quite unlikely since a lot of JNI code is working great (basically a lot of AWT stuff) - Maemo's GTK is broken in some way? Any help would be really appreciated, thank you in advance, lg Clemens Source-Code of initFromImage: - pixmap = cp_gtk_image_get_pixmap (env, source); <-> Just returns the pixmap pointer from the java-code g_assert(pixmap != NULL); gdk_pixmap_ref (pixmap); <> fails here? g = (struct graphics *) g_malloc (sizeof (struct graphics)); g->x_offset = g->y_offset = 0; g->drawable = (GdkDrawable *)pixmap; g->cm = gdk_drawable_get_colormap (g->drawable); gdk_colormap_ref (g->cm); g->gc = gdk_gc_new (g->drawable); -- ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Re: Flasher debs
On Thu, 27 Oct 2005, Aleksandr Koltsoff wrote: > On Thursday 27 October 2005 10:45, Ferenc Szekely wrote: > > ext Timo Savola wrote: > > > How about providing Debian packages (i386 and powerpc) of the flasher? > > yes, it is the license that prohibits us to distribute the tool in a > > debian repo. we could place the deb packages to the same place, but it > > does not help much, i guess. > > How about placing the deb packages somewhere where people download the SDK > from? Should probably be a separate directory with a README that would note > that the deb is not meant to be installed within SDK env. It would help > though. > > Other possibility is making a separate deb repo for tools that one would find > useful when developing on debian, but since flasher is the only tool at the > moment, that might be an overkill. > > ak. I think that Timo wanted a debian repo that could have been put to a sources.list and installed with apt-get. Single debian package that would be downloaded via web page and installed to host with dpkg (after click-through license agreement) is IMHO quite pointles because then it would require one step more to use the flasher. On the other hand if at install phase license agreement would be enough to satisfy legal issues it could be provided by debian repo. Then if user disagrees with the license installing would fail or something. I'm not sure that this would satisfy legal issues but would be doable from technical point of view. Of course using dpkg-deb to package would mean that user can access the binary without accepting the license ;) -- Valtteri Rahkonen [EMAIL PROTECTED] http://www.rahkonen.org +358 40 5077041 ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] flasher (Linux) doesn't find device
Le Jeudi 27 Octobre 2005 13:38, [EMAIL PROTECTED] a écrit : > and only after that you switch the device on with the power button. Isn't there also a way to keep the device in usb mode ? I managed this once or twice by pressing and holding the home key while booting, but as soon as I release the home key, it leaves usb mode. And then if you press other keys like zoom, plus, minus, power shortly, still while holding the home key, you can relase all of them an it stays in usb mode forever. > so if I do a mistake, I can take the battery out if a reset is needed > quickly: bad idea : powering off the device while it's writting the flash "might" be a good way to brick it ... > After the flashing is 100%, switch off the device by knocking the > battery out. Then > put the battery back and start the device. or just use the -R flag of the tool ;) Regards, Alex ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Packet Telephony?
On 10/27/05, Komal Shah <[EMAIL PROTECTED]> wrote: > --- Andre Magalhaes <[EMAIL PROTECTED]> wrote: > > > > > > is correct. No other open source telephony apps use GStreamer > > > (that I know of) and it looks like you'd have to hack it to make > > > it work on an n770 and a desktop from the same code base... > > > assuming you had software plugins for the codecs for GStreamer > > > (do those exist?). > > Yes, they do exist. > > Where? I am not able to find gstreamer package with modified plugins > (eg. mp3sink etc) in maemo repository or elsewhere? _or_ do we have to > wait for such code until device gets released. Actually, when we release Tapioca for 770, if the plugins (gstreamer) are not there, we will probably release them. Cheers, Andrunko ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
My instructions (link) Re: [maemo-developers] flasher (Linux) doesn't find device
Hello, > i scrawled on maemo.org to find out information regarding the R&D mode > and the differences between R&D / Production mode. Some more information can be found from here: http://www.karoliinasalminen.com/blog/?page_id=68 Best Regards, Karoliina -- http://www.karoliinasalminen.com/blog ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] gtk+ builtin stock icons removed
2005/10/27, Tommi Komulainen <[EMAIL PROTECTED]>: > The only places where things might get broken is when the builtin stock > icon is the only piece of information provided to the user such as in > the toolbar in an appview - gtk+ toolbars should always have icon+text > information provided as per HIG and a11y guidelines. Icons should be > used only in addition to other forms of providing information, relying > on icons only (in gtk+) is questionable already. Yeah, but makes sense in a space-constrained environment, specially if you can use the same icons that everybody else uses so users are familiar with their meaning. > So only a very small part of applications should be impacted. Disagree. Stock icons have more uses than just as a part of a stock item. But if you assert that icons are not important, I guess it doesn't matter... > And in case there are any misconceptions about priorities, product comes > first, Hildonized apps second, running unmodified gtk+ apps is plus. Unfortunately that means that those without a graphics department at their disposal or graphical skills are left without icons (or worse, have to make bad icons themselves). > Removing stock icons has only positive impact on the product and only a > minor negative impact on a subset of other apps. It's positive only because the product uses it's own icons and will have negative impact on the open source software created for it. But I guess that is fair enough to be in the bottom of the priority list :( > And the effort spent was around half an hour to implement. From where I'm > sitting that's quite cost-efficient. It is cost-efficient *because* you are sitting where you are sitting. -- Kalle Vahlman, [EMAIL PROTECTED] Powered by http://movial.fi ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Re: Flasher debs
On Thursday 27 October 2005 10:45, Ferenc Szekely wrote: > ext Timo Savola wrote: > > How about providing Debian packages (i386 and powerpc) of the flasher? > yes, it is the license that prohibits us to distribute the tool in a > debian repo. we could place the deb packages to the same place, but it > does not help much, i guess. How about placing the deb packages somewhere where people download the SDK from? Should probably be a separate directory with a README that would note that the deb is not meant to be installed within SDK env. It would help though. Other possibility is making a separate deb repo for tools that one would find useful when developing on debian, but since flasher is the only tool at the moment, that might be an overkill. ak. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
RE: [maemo-developers] flasher (Linux) doesn't find device
On tor, 2005-10-27 at 14:06 +0200, ext Martin Grimme wrote: > Hello, > > Am Donnerstag, den 27.10.2005, 14:38 +0300 schrieb > [EMAIL PROTECTED]: > > Yes, always start flashing by first turning off the device. > > Then you connect the usb cable, start flasher with parameters like > > (whatever you prefer), my usual parameters are: > > ./flasher -F -f --enable-rd-mode --enable-usb-host-mode > > --set-rd-flags=serial-console > > and only after that you switch the device on with the power button. > > Is there a description somewhere about the available rd-flags and > what they do? Yes. Just do flasher --set-rd-flags Regards: David Weinehall ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
RE: [maemo-developers] flasher (Linux) doesn't find device
Hello, Am Donnerstag, den 27.10.2005, 14:38 +0300 schrieb [EMAIL PROTECTED]: > Yes, always start flashing by first turning off the device. > Then you connect the usb cable, start flasher with parameters like > (whatever you prefer), my usual parameters are: > ./flasher -F -f --enable-rd-mode --enable-usb-host-mode > --set-rd-flags=serial-console > and only after that you switch the device on with the power button. Is there a description somewhere about the available rd-flags and what they do? Regards, Martin ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] gtk+ builtin stock icons removed
Hi, Tommi Komulainen wrote: > There's probably a more simple solution to make stock icons work well; > just add "gtk-bold.png" and similarly named files in the hicolor icon > theme and things should just work. However the current solution works that's a good idea... expecially because you can ship properly looking icons, but you can't do this by installing a package which makes this good solution pretty useless :-( > In our UI guidelines menu items or buttons don't have icons so this is a > moot point. Yes, the implementation could be better, but the end result Right - but the most important widget makes use of them: The toolbars and that's exactly the place where stock icons should be used to ensure a consistant and themable look and feel. Greetings Florian -- The dream of yesterday Florian Boor is the hope of todayTel: 0271-771091-14 and the reality of tomorrow.Fax: 0271-771091-19 [Robert Hutchings Goddard, 1904][EMAIL PROTECTED] 6C 44 30 4C 43 20 6B 61 16 07 0F AA E6 97 70 A8 ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] flasher (Linux) doesn't find device
If you want to set the device only to rd-mode, you don't need to flash, you can just type (you need to do the same thing though as described above): ./flasher --enable-rd-mode Karoliina, i scrawled on maemo.org to find out information regarding the R&D mode and the differences between R&D / Production mode. Except here: http://maemo.org/platform/docs/howtos/ howto_use_flasher_rootfs.html , i couldn't find informations about this. Any clue? Laurent ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] gtk+ builtin stock icons removed
Hi, > i don't think 30k is worth making it a major pain maintaining applications > which > support both plain GTK and Hildon UI. But that's my personal opinion. > In addition to this you loose a pile of convenient functions to deal with the > stock icons. UI guidelines (e.g. the Gnome HIG) suggest to use a set of well > known symbols for common operations which is a really good idea if you want > users to feel familiar with their applications - another important feature you > will loose with this. I do agree with this. > Additionally it might be a good idea to replace the builtin icons with maemo > style icons... currently some of them look pretty good (like the arrows, > useful > to replace the broken GtkArrows in the default theme), but some look very different. Replacing the icons with the maemo ones makes more sense. It will make it easier to port applications. For example programs that use the stock gtk icons wont need to replace them to make them more consistent with the maemo/hildon look. Saving the effort of a lot of ifdefs if the program is intended to be running on other systems too, if the porter is even willing to do so... Performance wise it might improve application performance for maemo apps as they will not have to load the icons from flash, instead they will be directly available. On top of that programming is a bit easier too and there is no risk of letting out icons by accident (however I have to admit with a standard icon set that chances are pretty slim) Anyway I believe removing the stock gtk icons will also decrease the interest of developers wanting to port their applications. For a performance improvement that is probabely negligable. (GPE just copes fine with those stock icons in) There might be better things to go after, unfortunately my gtk knowlegde is not that good... (yet) Regards, Philippe | Philippe De Swert | | GPE developer: http://gpe.handhelds.org | Emdebian developer: http://www.emdebian.org | | Please do not send me documents in a closed | format.(*.doc,*.xls,*.ppt) | Use the open alternatives. (*.pdf,*.ps,*.html,*.txt) | http://www.gnu.org/philosophy/no-word-attachments.html --- A free anti-spam and anti-virus filter on all Scarlet mailboxes More info on http://www.scarlet.be/ ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
RE: [maemo-developers] flasher (Linux) doesn't find device
Hello, Yes, always start flashing by first turning off the device. Then you connect the usb cable, start flasher with parameters like (whatever you prefer), my usual parameters are: ./flasher -F -f --enable-rd-mode --enable-usb-host-mode --set-rd-flags=serial-console and only after that you switch the device on with the power button. I have also found a good way (actually it was not invented by me though) with this by having the battery cover open, so if I do a mistake, I can take the battery out if a reset is needed quickly: If the battery cover is open and you hit/knock the device gently from the front side with something soft (e.g. with your hand), the battery drops (to your hand, if you have it waiting on the bottom of the device). After the flashing is 100%, switch off the device by knocking the battery out. Then put the battery back and start the device. If you flash the developer rootimage, be sure that you have the product rootimage nearby, so you can put it back afterwards. If you want to set the device only to rd-mode, you don't need to flash, you can just type (you need to do the same thing though as described above): ./flasher --enable-rd-mode Best Regards, Karoliina >> I cannot get the flasher find the device. All it says is: >> >> Suitable USB device not found, waiting >Found the problem. The device has to be switched off when >being plugged in but then has to be _switched on_. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] gtk+ builtin stock icons removed
Let me reiterate the consequences of removing the builtin stock icons (not items, icons): it has no ill effect on stock menu items or stock buttons (the icon has always been considered optional, see gtk-button-images and gtk-menu-images GtkSettings.) The only places where things might get broken is when the builtin stock icon is the only piece of information provided to the user such as in the toolbar in an appview - gtk+ toolbars should always have icon+text information provided as per HIG and a11y guidelines. Icons should be used only in addition to other forms of providing information, relying on icons only (in gtk+) is questionable already. So only a very small part of applications should be impacted. Yes it is a bit more work to really integrate with the maemo platform, but much less than porting to HildonApp. And in case there are any misconceptions about priorities, product comes first, Hildonized apps second, running unmodified gtk+ apps is plus. Removing stock icons has only positive impact on the product and only a minor negative impact on a subset of other apps. And the effort spent was around half an hour to implement. From where I'm sitting that's quite cost-efficient. For the most parts our priorities are well aligned with those of other developers and we try to keep it that way. When some of our decisions doesn't align perfectly with the outside it usually just means that we don't have the resources to do things perfectly so we choose to do something that works for us. If it doesn't work for you we need you to fill in the gap. (In fact I have a patch waiting in my inbox, thanks Skyhusker, but I haven't had the time to look at it closely yet.) There's probably a more simple solution to make stock icons work well; just add "gtk-bold.png" and similarly named files in the hicolor icon theme and things should just work. However the current solution works for us, so it is not high in our priority list to do this work. (In the longer term we should have correct size images to replace the stock icons as the stock sizes don't quite match ours.. but again, it would take more time.) On Wed, 2005-10-26 at 19:32 +0200, ext Florian Boor wrote: > UI guidelines (e.g. the Gnome HIG) suggest to use a set of well > known symbols for common operations which is a really good idea if you want > users to feel familiar with their applications - another important feature you > will loose with this. In our UI guidelines menu items or buttons don't have icons so this is a moot point. Yes, the implementation could be better, but the end result would still be the same for most parts. > Additionally it might be a good idea to replace the builtin icons with maemo > style icons... currently some of them look pretty good (like the arrows, > useful > to replace the broken GtkArrows in the default theme), but some look very > different. This is a good idea, and we should've done that long time ago. But we didn't and there's only so much we can do in the short term now. -- Tommi Komulainen<[EMAIL PROTECTED]> ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Success: Network using PC BT Network Access Point
On Thu, Oct 27, 2005, Ilkka Urtamo wrote: > PS. Anyone already working on the NAP support for gwconnect? If not, I > could take a look. AFAIK, no. However, I'm not so sure it even makes sense since there's already pand on the system. If you want to have a D-BUS interface for PAN the effort would be best directed at the new D-BUS daemon that will be included as a standard part of bluez (see bluez-devel mailing list for more info). I think PAN is also one of the first priorities of the INdT guys who are working on it. Johan ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] kernel sources
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Koen Kooi wrote: > Paul Mundt wrote: > >>>On Fri, Oct 21, 2005 at 11:31:40AM +0200, Koen Kooi wrote: >>> >>> Any news on the kernel sources? >>> >>> >>>http://lkml.org/lkml/2005/10/12/87 > > > I guess the dev program doesn't count as 'sale' or 'distributing'? > Anyway, I'll wait for the source to be available on maemo.org. And the wait is over! The source is available from the debian repo. > regards, > > Koen -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iD8DBQFDYLIrMkyGM64RGpERAkijAJ41Mg/xQD2HLZSwvETZ6E5PiKgAngCgnoF0 7nVD1UjoIs25qQyECI78Ucs= =6ouU -END PGP SIGNATURE- ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] Success: Network using PC BT Network Access Point
OK thanks to everyone who helped, I now have net using bt NAP. Here is how I did it (everything is by hand, I will try to automatize it later) Host PC: needed: bluez kernel, bluez lib & tools,iptables Using typical hcid.conf forwarding ready: iptables -F iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE iptables -A FORWARD -i bnap0 -j ACCEPT iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT start listening connections: pand --listen --role NAP --autozap --persist --ethernet bnap0 Then dev side: gain root access first add dummy net connection (as described in http://maemo.org/maemowiki/DummyIAP) gconftool -s -t string /system/osso/connectivity/IAP/DEFAULT/type DUMMY then connection pand --connect (if pairing is needed, it will pop up dialog... wait second or two to connection to be established) ifconfig bnep 192.168.2.2 netmask 255.255.255.0 up route add default gw 192.168.2.1 and manual dns echo "nameserver " >> /var/run/resolv.conf Then again host PC side: after connection is made by dev pand --connect: ifconfig bnap0 192.168.2.1 netmask 255.255.255.0 up All set. When starting browser or other that needs network, select the dummy "DEFAULT" PS. Anyone already working on the NAP support for gwconnect? If not, I could take a look. Greets, Ilkka ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] Re: can't find system-dbus-socket. How to deal with dbus ?
Hello, wang baisheng wrote: > I have found it is the dbus that caues the problem. The > hildon-navigator > can't find /tmp/session-dbus-socket. Now I run /usr/bib/dbus-daemon-1 > --session &, then the hildon-navigator find the /tmp/seesion-dbus-socket. But > it then can't find /usr/var/run/dbus/system-dbus-socket. I > run /usr/dbus-daemon-1 --system &. The system-dbus-socket doesn't appear. How > to deal with dbus-daemon about system-dbus-socket ? this should happen automatically when you run af-sb-init.sh. I don't remember if it was maybe necessary to source that script in the 1.0 release. It would be a good idea to install the latest release of the maemo SDK anyway. If that problem still resists with the latest release we need to find out what is going wrong. Greetings Florian -- The dream of yesterday Florian Boor is the hope of todayTel: 0271-771091-14 and the reality of tomorrow.Fax: 0271-771091-19 [Robert Hutchings Goddard, 1904][EMAIL PROTECTED] 6C 44 30 4C 43 20 6B 61 16 07 0F AA E6 97 70 A8 ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Packet Telephony?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Komal Shah wrote: > --- Andre Magalhaes <[EMAIL PROTECTED]> wrote: > > >>>is correct. No other open source telephony apps use GStreamer >>>(that I know of) and it looks like you'd have to hack it to make >>>it work on an n770 and a desktop from the same code base... >>>assuming you had software plugins for the codecs for GStreamer >>>(do those exist?). >> >>Yes, they do exist. > > > Where? I am not able to find gstreamer package with modified plugins > (eg. mp3sink etc) in maemo repository or elsewhere? _or_ do we have to > wait for such code until device gets released. AFAIK it's part of the closed source 'dark side' of maemo, which means there aren't any .debs available (yet). Unless you have a omap1710 on your workstation the plugins aren't of much use. Could one of the nokia people comment on the possibility of dsp plugins only containing stubs for the SDK_PC? regards, Koen > > ---Komal Shah > http://komalshah.blogspot.com/ > > > > > __ > Yahoo! Mail - PC Magazine Editors' Choice 2005 > http://mail.yahoo.com > ___ > maemo-developers mailing list > maemo-developers@maemo.org > https://maemo.org/mailman/listinfo/maemo-developers > -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iD8DBQFDYKoNMkyGM64RGpERAvRXAJ9vh378f8yL/lkQP39EF3veqDkZzACfWNpR FjYN20apxVPtKoltX4tPajQ= =hURI -END PGP SIGNATURE- ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Superwaba Re: [maemo-developers] JamVM on 770 (Java)
Just a warning. SuperWaba is very good but no longer free. Since version 5.x authors invented new business model and started to charge for LGPLed version (approx. 500$ per year). The version they call GPLed is still free but mostly only as in beer and the future is not bright. It works a bit like honeypot for developers or demoversion for the PRO package. This version has some advanced packages missing, shows a nag screen and there are no regular updates and bugfixes. Also the full rebuildable sources of 'GPLed' SuperWaba version are not available so you cannot fix bugs in the runtime (and remove nag screen). Also there is no guarantee there will be next such version because authors are a bit unhappy about their licence choice. Anyone who want free (both as speech and beer) java virtual machine should look elsewhere. But there is a similar very good too. Visit www.superwaba.com. It is an open-source software development platform for PDAs (Personal Digital Assistants) and Smartphones, soft and simple. There isn't nothing implemented for maemo. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Packet Telephony?
--- Andre Magalhaes <[EMAIL PROTECTED]> wrote: > > > is correct. No other open source telephony apps use GStreamer > > (that I know of) and it looks like you'd have to hack it to make > > it work on an n770 and a desktop from the same code base... > > assuming you had software plugins for the codecs for GStreamer > > (do those exist?). > Yes, they do exist. Where? I am not able to find gstreamer package with modified plugins (eg. mp3sink etc) in maemo repository or elsewhere? _or_ do we have to wait for such code until device gets released. ---Komal Shah http://komalshah.blogspot.com/ __ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Control Panel / Memory App crash after GPE install.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Grimme wrote: > Hi, > > Am Donnerstag, den 27.10.2005, 11:17 +0200 schrieb Laurent Lieben: > >>after flashing back my device with the actual retail software, i >>could launch the Memory App flawlessly >>Thereafter, i reinstalled GPE-TODO / GPE-CONTACT and all belongings >>libraries. >> >>Then, the Memory App from the control panel crash. >> >>does it have anything related with GPE installation? > > > Since I did exactly the same, and the Memory App was working before, > I believe this is really caused by the installation of GPE in some > way. Uninstalling the GPE packages did not fix the crash. > Either it is because of installing packages in general, or the GPE > packages are buggy. Packages installed via the AI can't touch anything outside /var/lib/install, so this must be a bug in Maemo. The memory applet on my 770 started failing after installing the xterm packages, which was the first pacakge I installed. regards, Koen > > > Martin > > > ___ > maemo-developers mailing list > maemo-developers@maemo.org > https://maemo.org/mailman/listinfo/maemo-developers > -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iD8DBQFDYJ7wMkyGM64RGpERAijyAKCWS15Ox39f/OoVfrRtsTC8weBMhgCfSoT7 kDROK8zqSEzkxgQ+QytCYv4= =/uR2 -END PGP SIGNATURE- ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Control Panel / Memory App crash after GPE install.
I experienced the same - I installed a simple self-made package withought any size-tag in the package's control file, it installed fine but after it the memory app crashed _once_. Although now it works like it should withought any problems. lg Clemens ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Control Panel / Memory App crash after GPE install.
Hi, Am Donnerstag, den 27.10.2005, 11:17 +0200 schrieb Laurent Lieben: > after flashing back my device with the actual retail software, i > could launch the Memory App flawlessly > Thereafter, i reinstalled GPE-TODO / GPE-CONTACT and all belongings > libraries. > > Then, the Memory App from the control panel crash. > > does it have anything related with GPE installation? Since I did exactly the same, and the Memory App was working before, I believe this is really caused by the installation of GPE in some way. Uninstalling the GPE packages did not fix the crash. Either it is because of installing packages in general, or the GPE packages are buggy. Martin ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] Control Panel / Memory App crash after GPE install.
Hello, after flashing back my device with the actual retail software, i could launch the Memory App flawlessly Thereafter, i reinstalled GPE-TODO / GPE-CONTACT and all belongings libraries. Then, the Memory App from the control panel crash. does it have anything related with GPE installation? ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] gtk+ builtin stock icons removed
Hi, >> My suggestion: Forget about this as long as you don't offer a similar >> feature to replace the builtin stock icons. My guess would be that Tommi has some long term plan to fix this properly when there's time. :-) >> It might be a good idea to >> modify GTK in a way that only the the stock icons used by an application >> are kept in memory instead of compiling them into the library. The builtin stock icon pixel data isn't paged into memory from the library code unless application uses that. AFAIK that 40KB memory (including the allocation overhead, not just sum of allocations) is used for strdup()ing the icon names, creating objects that are not used etc, not for pixel data. > What are 30kb when you look at GTK2 ;-) One step in making it smaller. The memory usage can be lowered only by fixing all these little details, not by some magic incantation... I'm pretty sure Gtk developers would have noticed if there's some unnecessary 1/2MB allocation hiding in an obscure corner of the code. :-) - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] Re: Flasher debs
ext Timo Savola wrote: > How about providing Debian packages (i386 and powerpc) of the flasher? > It would be in line with the recommendation to use Debian or Ubuntu for > development with maemo. Or would the (click-through) license prohibit > that (or make it unfeasible)? > yes, it is the license that prohibits us to distribute the tool in a debian repo. we could place the deb packages to the same place, but it does not help much, i guess. br, ferenc ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] JamVM on 770 (Java)
Hi Fabrício, > Your idea is very good. Thanks for the flowers ;-) > But there is a similar very good too. Visit > www.superwaba.com. I know superwaba and its a cool platform, however since my goal is to implement a J2ME "player" for the 770 (so the 770 will be able to run the tons of mobile games) I will concentrate on classpath based JVMs. Furthermore a "real" jvm should allow to run almost all classpath compatible java programs on the 770. > It is an open-source software development platform for PDAs (Personal > Digital Assistants) and Smartphones, soft and simple. > There isn't nothing implemented for maemo. > > This a good idea for the maemo! Well, why not start porting it - Although I have to admit that installing the dev-enviroment isn't that funny and on my machine qemu is not able to run more complex arm binaries, its quite easy when taking in mind how complex the whole topic of cross-compilation is. Try it, its real fun! lg Clemens ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
