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
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: [maemo-developers] Cairo benchmarking
Hi; On 10/28/05, Clemens Eisserer <[EMAIL PROTECTED]> wrote: > > 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. An FP API will make a difference if your calling it thousands of times ( i.e in an animation ). Of course this is only one factor as I previously mentioned but believe me FP operations really hurt on hardfloat ARM - a simple timed test of adding ints vs floats will prove this. > 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. > I depends on *how* you paint that pixmap of course. Using a 'core' X fillrect should be pretty fast. Doing the same thing via cairo is going to be slower - it offers much more feature wise that 'core' X cannot do and as not yet fully optimised basic operations may not be 'fast pathed'. -- Matthew ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Cairo benchmarking
On 10/28/05, Kalle Vahlman <[EMAIL PROTECTED]> wrote: > > I was going to test it with different xlib surface size but since the > older SW did not allow me to kill matchbox without rebooting the whole > thing and matchbox is kind enough to maximize the window regardless... > You cant make the test window a dialog or even a nasty overide redirect ? Last time I checked matchbox only 'maximises' application windows and supports many other window types than just application ones -- Matthew ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] N770 hardware key bindings
I believe your right, I think the home key is trapped by something else before it even reaches X let alone MB. Not sure why that is. --- Matthew On 11/24/05, Luca Donaggio <[EMAIL PROTECTED]> wrote: > Hi, > > how can I change the default behaviour of the N770 hardware keys? > For example: I would like the 'Home' button to cicle between opened > applications; I can do that by creating the .matchbox/kbdconfig with > 'F5=Next' in it, but after doing the proper action, it still keep on > jumping to the 'Home' app., as if the F5 key press event was trapped > by something else than the matchbox wm. > > Luca Donaggio > ___ > maemo-developers mailing list > maemo-developers@maemo.org > https://maemo.org/mailman/listinfo/maemo-developers > ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] Stuff to make h/w bt keyboards more useful
Hi;
I recently bought one of the Nokia BT keyboards for my 770. Tomas's
btkeyboard-plugin rocks but I soon got pretty frustrated at the 770
not registering keypresses as activity to stop the display from
blanking.
Attached is a patch to btkeyboard-plugin which attempts to remedy
this. It works rather brutally via sniffing out x keyevents on
currently active windows and calling the equivilent of
osso_display_blanking_pause() for each key press, keeping the display
lit for another 60 seconds.
There is no doubt more efficient ways to do the same thing lower down
the stack. But this was quickest way for me todo and suit my needs.
Also attached is a matchbox keyboard shortcut config file. Put this
file in /home/user/.matchbox/kbdconfig, then run matchbox-remote -k.
This sets up keyshortcuts for 'tabbing' between windows,
fullscreening, closing apps and a couple of other things ( check
kbdconfig for details ). YMMV with these shortcuts as matchbox key
shortcuts arn't totally integrated into maemo.
Finally attached is an xmodmap file. This is relevant at least for the
Nokia BT keyboard and may need editing for other makes. It basically
switches the caps and ctrl keys, makes 'del' a backspace and maps the
non functional 'blue' keys to page up, page down and home.
Put this file in /home/user/.xmodmap. Remap keyboard via 'xmodmap
~/.xmodmap' ( patched btkeyboard-plugin runs this command on new
keyboard connection ). I've put an ARM binary ( from Debian ) of
xmodmap here;
http://butterfeet.org/maemo/keyboard/
( Also togeather with a patched built binary of bt-plugin.so etc. )
All this is very much hacker orientated and really aimed at those who
know what there doing. Try at your own risk. At least for me it makes
the keyboard a little more useable.
Regards;
-- Matthew
--- btkeyboard-plugin-0.2.2.orig/bt-plugin.c 2005-09-21 08:59:50.0 +0100
+++ btkeyboard-plugin-0.2.2/bt-plugin.c 2005-11-28 19:30:33.0 +
@@ -28,6 +28,13 @@
#include
#include
+#include
+#include
+
+#include
+#include
+#include
+
#include
#include
#include
@@ -74,6 +81,11 @@
NUM_PIXBUFS
};
+enum {
+ CATCH,
+ RELEASE
+};
+
typedef struct
{
HildonStatusBarItem *item;
@@ -89,6 +101,8 @@
gboolean button_released;
gboolean connected;
gboolean searching;
+Atom atom_net_active_win;
+Window last_active_win;
} PluginInfo;
/* Hildon Status Bar plugin API prototypes */
@@ -99,6 +113,184 @@
gint bt_get_priority(void *data);
void bt_update(void *data, gint value1, gint value2, const gchar *str);
+void set_key_events (Window win, int mode);
+
+static GdkFilterReturn
+x_key_event_filter (GdkXEvent *xevent,
+ GdkEvent *event,
+ gpointer data)
+{
+DBusConnection *conn;
+DBusMessage*msg = NULL;
+DBusError dbus_error;
+dbus_bool_t dresult;
+
+if (((XEvent*)xevent)->type == PropertyNotify)
+return GDK_FILTER_CONTINUE;
+
+/*
+ * This is basically osso_display_blanking_pause(), execpt
+ * we have no osso_context_t... but we do have the source
+ * for osso_display_blanking_pause() :)
+*/
+
+#define MCE_SERVICE "com.nokia.mce"
+#define MCE_REQUEST_PATH"/com/nokia/mce/request"
+#define MCE_REQUEST_IF "com.nokia.mce.request"
+#define MCE_PREVENT_BLANK_REQ "req_display_blanking_pause"
+
+dbus_error_init(&dbus_error);
+
+conn = dbus_bus_get (DBUS_BUS_SYSTEM, &dbus_error);
+
+msg = dbus_message_new_method_call(MCE_SERVICE,
+ MCE_REQUEST_PATH,
+ MCE_REQUEST_IF,
+ MCE_PREVENT_BLANK_REQ);
+if (msg == NULL)
+return GDK_FILTER_CONTINUE;
+
+dresult = dbus_connection_send (conn, msg, NULL);
+
+if (!dresult)
+{
+dbus_message_unref(msg);
+return GDK_FILTER_CONTINUE;
+}
+
+dbus_connection_flush(conn);
+dbus_message_unref(msg);
+
+
+return GDK_FILTER_CONTINUE;
+}
+
+void
+set_key_events (Window win, int mode)
+{
+ Window root_win, parent_win;
+ unsigned int num_children;
+ Window *child_list;
+ Status status;
+ GdkWindow *gdk_wrapper_win = NULL;
+ int i;
+
+ if (win == None)
+ return;
+
+ gdk_error_trap_push();
+
+ status = XQueryTree(GDK_DISPLAY(),
+ win,
+ &root_win,
+ &parent_win,
+ &child_list,
+ &num_children);
+
+ if (gdk_error_trap_pop() || status == 0
+ || num_children == 0 || child_list == NULL)
+ return;
+
+ for (i = num_children - 1; i >= 0; i--)
+ {
+ gdk_error_trap_push();
+
+ gdk_wrapper_win = gdk_window_foreign_new (child_list[i]);
+
+ if (gdk_wrapper_win != NULL)
+ {
+ /* Monitor the window for prop changes */
+ if (mode == CATCH)
+ {
+ gdk_window_set_events(gdk_wrapper_win,
+
Re: [maemo-developers] ipkg vs dpkg
Lies, damn lies and statistics :) Surely this isn't a fair comparison as the packages in Debian 2.2 arn't 'tuned' to embedded use ( i.e include docs, .la files etc etc ). You'd be better comparing udebs that make up D-I or something. Also I dont know how you make numbers out of ipkg's lack of any real maintainership, constant instability ( likely due to former ), wierd versioning scheme, memory issues and horrific 'UI' ( see ipkg -h ). Regards -- Matthew PS; note; Im not saying dpkg is ideal for embedded systems here, just that ipkg is not ideal either ( maybe it used to be but not so much nowadays ). On 11/26/05, Russell Nelson <[EMAIL PROTECTED]> wrote: > Instead of tossing out opinions, let's look at some numbers. > > I have Debian 2.2 on a server and Familiar 6.2 on a handheld. Since > we're talking about using either dpkg or ipkg on a jffs2 filesystem, > all space consumption is given as so: > > > packagessize bytes/package > ipkg total 378K > available939 317K 388 > installed14761K 415 > dpkg total10620K > available 15272 8660K 567 > installed301 1860K 6180 > > Here's how I got these numbers: > > ipkg total is: > tar cfz - /usr/lib/ipkg | wc -c > ipkg available is: > tar cfz - /usr/lib/ipkg/lists | wc -c > ipkg packages installed is: > ipkg status | grep ^Package: | wc -l > ipkg available packages is: > ipkg list | wc -l > > dpkg total is: > tar cfz - /var/lib/dpkg | wc -c > dpkg available is: > tar cfz - /var/lib/dpkg/available* | wc -c > dpkg packages installed is: > grep '^Status: install ok installed' /var/lib/dpkg/status | wc -l > dpkg available packages is: > grep '^Status:' /var/lib/dpkg/status | wc -l > > -- > --my blog is at blog.russnelson.com | > Crynwr sells support for free software | PGPok | There ought to be a law > 521 Pleasant Valley Rd. | +1 315-323-1241 | against calling for more > Potsdam, NY 13676-3213 | Sheepdog | regulations! > ___ > 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] ipkg vs dpkg
Hi; On 11/29/05, Russell Nelson <[EMAIL PROTECTED]> wrote: > Matthew Allum writes: > > Surely this isn't a fair comparison as the packages in Debian 2.2 > > arn't 'tuned' to embedded use ( i.e include docs, .la files etc etc ). > > You'd be better comparing udebs that make up D-I or something. > > I'm only talking about the overhead of the package manager, not the > contents of the packages themselves. > Okey, but surely some of the metadata you've measured is dependant on whats actually in the package ? > > Also I dont know how you make numbers out of ipkg's lack of any real > > maintainership, constant instability ( likely due to former ), wierd > > versioning scheme, memory issues and horrific 'UI' ( see ipkg -h ). > > Those are problems with ipkg, to be sure, but dpkg has its own > usability issues, and needs a front-end (apt-get) to have ipkg's > functionality. > Agreed. > There is no really great package manager for a small-storage system. Agreed. > How do we get there from here? > Somebody writes something new that kicks arse and addresses the issues with dpkg and ipkg. > > PS; note; Im not saying dpkg is ideal for embedded systems here, just > > that ipkg is not ideal either ( maybe it used to be but not so much > > nowadays ). > > Repeat after me: "the 770 is not an embedded system". It is a small > computer with neither a qwerty keyboard nor a big hard drive, nor a > really fast processor. > "the 770 is not an embedded system" - OK :) You understand my point though - we could argue all week on if my digitial watch for example was a small computer or an embedded system. -- Matthew ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] Re: Stuff to make h/w bt keyboards more useful
I updated the patch a little last night to make it work more efficiently and also now unblank the display once blanked via keyboard. Updated patch and new patched libbt.so binary at; http://butterfeet.org/maemo/keyboard/ -- Matthew On 11/28/05, Matthew Allum <[EMAIL PROTECTED]> wrote: > Hi; > > I recently bought one of the Nokia BT keyboards for my 770. Tomas's > btkeyboard-plugin rocks but I soon got pretty frustrated at the 770 > not registering keypresses as activity to stop the display from > blanking. > > Attached is a patch to btkeyboard-plugin which attempts to remedy > this. It works rather brutally via sniffing out x keyevents on > currently active windows and calling the equivilent of > osso_display_blanking_pause() for each key press, keeping the display > lit for another 60 seconds. > > There is no doubt more efficient ways to do the same thing lower down > the stack. But this was quickest way for me todo and suit my needs. > > Also attached is a matchbox keyboard shortcut config file. Put this > file in /home/user/.matchbox/kbdconfig, then run matchbox-remote -k. > This sets up keyshortcuts for 'tabbing' between windows, > fullscreening, closing apps and a couple of other things ( check > kbdconfig for details ). YMMV with these shortcuts as matchbox key > shortcuts arn't totally integrated into maemo. > > Finally attached is an xmodmap file. This is relevant at least for the > Nokia BT keyboard and may need editing for other makes. It basically > switches the caps and ctrl keys, makes 'del' a backspace and maps the > non functional 'blue' keys to page up, page down and home. > > Put this file in /home/user/.xmodmap. Remap keyboard via 'xmodmap > ~/.xmodmap' ( patched btkeyboard-plugin runs this command on new > keyboard connection ). I've put an ARM binary ( from Debian ) of > xmodmap here; > > http://butterfeet.org/maemo/keyboard/ > > ( Also togeather with a patched built binary of bt-plugin.so etc. ) > > All this is very much hacker orientated and really aimed at those who > know what there doing. Try at your own risk. At least for me it makes > the keyboard a little more useable. > > Regards; > > -- 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; 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
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] keyboard notes
http://maemo.org/pipermail/maemo-developers/2005-December/002016.html may help a little. On 1/14/06, Brad Midgley <[EMAIL PROTECTED]> wrote: > Hey > > I do like the wireless keyboard overall (stowaway model). The caveats > are probably well known... > > - activate the keyboard with something other than the xterm in the > foreground or switch between apps once (enter key won't work) > - backlight is dimmed and then turned off in spite of typing activity > - not a lot of global keyboard shortcuts? only alt-tab as far as i can tell > - the icon image should be a keyboard in combo with the bluetooth icon > so it's clear what thing is connected over bluetooth > > Brad > ___ > 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] Home Applet API changes coming - .desktop files required for applets in the next software edition (2006)
A quick thought; With multiple applets how can the hardcoded x,y values be guarenteed ? What would happen if two applets specified the same value ? Would somekind of 'placement hint' ( I.e top,botton,center etc ) be better ? This would also scale better to different sized displays. -- Matthew On 1/26/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Hello, > > In the future Home applets needs to provide their own .desktop files. > > Here is an example (Myapplet.desktop): > [Desktop Entry] > Type=Home Applet > Name=Myapplet > Library=/usr/lib/hildon-home/libhome_myapplet.so > X=20 > Y=50 > > You should place the .desktop files here: > /usr/share/applications/hildon-home/ > > >From the parameters: X and Y are optional, the others are required > > Then there is an additional file called applet_manager.conf. > Its place will be: > /.osso/hildon-home/ > > Here is an example of its contents (applet_manager.conf): > [Myapplet] > Desktop=/usr/share/applications/hildon-home/Myapplet.desktop > Library=/usr/lib/hildon-home/libhome_myapplet.so > X=20 > Y=50 > > All the four fields are required. > > Please take that into consideration if you are developing applets for > Home (which is part of maemo-af-desktop > currently). > > Best Regards, > Karoliina Salminen > http://www.karoliinasalminen.com/blog > > ___ > 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] GTK2.8 ??
Hi; On 7/20/06, Koen Kooi <[EMAIL PROTECTED]> wrote: Maemo already uses softfloat and it's still slow. Right, FPUs exist for reason. If softfloat was perfect they wouldn't. You still take a hit, just not as much as hardfloat. Also I dont think its just FP causing a slowdown though this appears to be particularly nasty in pango-cairo GTK+ usage ( see below referenced thread ). Don't count on it, Carl has had a long history of playing with arm based machines, even before cairo was started. But we'll see, but I won't have high hopes, even if I *really* like cairo. There is some movement on the GNOME performance list - See the 'Floating point in pango' thread. Archives are broke so see http://thread.gmane.org/gmane.comp.gnome.performance/ Please get involved if you think you could help. -- Matthew ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Discussion of a possible project - offline calendar project
Hi; On 1/15/07, Andrew Flegg <[EMAIL PROTECTED]> wrote: On 1/15/07, Martin Grimme <[EMAIL PROTECTED]> wrote: > [development of another PIM suite] > > This sounds really interesting. I know that there are already > applications like dates or GPE-calendar for the N770 but both > don't fit my needs. Since my idea was to write some sort of > PIM suite specially for the 770 in the near future, maybe we > should join efforts. I don't think GPE is the perfect PIM suite (it is the most mature we've got, though) and Dates is still very immature. However, is what you want so diametrically opposed to the aims of these two projects that you couldn't work with them to improve the existing projects, rather than creating another? I guess though similar on the surface in what they do, they are actually very different in how they go about things. For example Dates, unlike GPE-cal(afaik), uses a client<->server split and attempts to align itself more with, and reuse, desktop technologies in having an optimised EDS backend (which actually gives *alot* for 'free but not of all that functionality used as yet ). We also wanted to experiement a bit with the UI as to at least try and come up with something workable but original that didn't follow the kind of standard PDA calendar app blueprint. If it's a case of getting in at the ground floor, the relative youth of Dates might be more interesting to you; and there are some nice UI ideas in there which will only improve with decent synchronisation. > I don't know the people at Opened Hand responsible for Dates, but I can't believe they wouldn't be interested in the help? Especially from two talented, enthusiastic programmers. Of course help is always welcomed, Bugzilla; http://bugzilla.o-hand.com/buglist.cgi?product=dates is a good place to start. Just as a note, Dates is still being developed (we recently released 0.2 for example and have bora packages - maemo.o-hand.com ). We have basic syncing (This is infact where we have been currently focusing, admittadly limited ,attention) just not quite at release quality as yet. -- Matthew ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
