On Wednesday 30 December 2009 16:13:19 Till Harbaum / Lists wrote:
> Am Dienstag 29 Dezember 2009 schrieb Jeff Moe:
> > You should do so, so your users don't brick their phones. It's soo
> > easy to put everything in /opt. I agree the symlinking madness is a bit
> > messy, but it workz and it's
Eugene Agafonov wrote:
>> Update:
>>
>> I've built a far better .deb based on SyncEvolution 0.9.1, and put it up
>> at http://people.debian.org/~ovek/maemo/
>>
>> It can't yet be built with a buildbot, primarily because not all of its
>> build-dependencies exist in maemo-devel, cppunit in particula
You can also check /sys/class/backlight/*/* entries to control screen
brightness without any software between you and kernel ;D
Regards,
--
JID: h...@jabber.org
Website: http://marcin.juszkiewicz.com.pl/
LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz
___
Hi Till,
Till Harbaum / Lists wrote:
> Am Mittwoch 30 Dezember 2009 schrieb Alberto Mardegan:
>> Speaking of which, it would be nice if you instructed osmgpsmap to store
>> the tiles under /home/user/MyDocs/.maps/ so that they could be shared
>> with maemo-mapper (I probably need to modify it a
Eero Tamminen wrote:
> Whereas /opt is standardized place for 3rd party software:
> http://www.pathname.com/fhs/pub/fhs-2.3.html#OPTADDONAPPLICATIONSOFTWAREPACKAGES
thanks! then let me rephrase my question:
why not have the same hierarchy as in /usr
(i.e. /opt/{bin,lib,share,...} ) and
* either i
>
> Update:
>
> I've built a far better .deb based on SyncEvolution 0.9.1, and put it up
> at http://people.debian.org/~ovek/maemo/
>
> It can't yet be built with a buildbot, primarily because not all of its
> build-dependencies exist in maemo-devel, cppunit in particular.
I tried to build fro
>
> Update:
>
> I've built a far better .deb based on SyncEvolution 0.9.1, and put it up
> at http://people.debian.org/~ovek/maemo/
>
> It can't yet be built with a buildbot, primarily because not all of its
> build-dependencies exist in maemo-devel, cppunit in particular.
I tried to build fro
Hi,
Am Mittwoch 30 Dezember 2009 schrieb Alberto Mardegan:
> Speaking of which, it would be nice if you instructed osmgpsmap to store
> the tiles under /home/user/MyDocs/.maps/ so that they could be shared
> with maemo-mapper (I probably need to modify it a bit so that the
> repository names ar
On Wed, 2009-12-30 at 08:14 +0100, Ove Kaaven wrote:
> Ove Kaaven skrev:
> >> This is already possible, but we aren't sure yet how to maintain the
> >> different profiles. Right now, src/syncclient_sample_config.xml contains
> >> a "contacts" field list (internal representation) and "vCard" profile
Hi,
Am Dienstag 29 Dezember 2009 schrieb Jeff Moe:
> You should do so, so your users don't brick their phones. It's soo easy
> to
> put everything in /opt. I agree the symlinking madness is a bit messy, but it
> workz and it's what we are stuck with until we have 2G NANDs.
In fact i just th
On Wed, 2009-12-30 at 13:07 +0100, Ove Kaaven wrote:
> Patrick Ohly skrev:
> > Looking at the code again and in particular
> > SyncSourceRevisions::updateRevision(), I remembered one problem with the
> > "changes since last sync" approach of change tracking. Suppose the
> > following chain of event
Hi Jeff,
Thanks for the input.
The page does not mention for other case, e.g. libs, libdevel, debug,
and doc etc.
I just checked telephathy-glib project and I found them above.
What kind of names can we specify? e.g. utils or utilities ?
Regards,
Kimitake
On Tue, Dec 29, 2009 at 4:55 PM, Jeff
Till Harbaum / Lists wrote:
> i have just been instructed to reduce the size of osm2go _incl._ its
> depending libraries to under 500k:
Speaking of which, it would be nice if you instructed osmgpsmap to store
the tiles under /home/user/MyDocs/.maps/ so that they could be shared
with maemo-mappe
Eero Tamminen on 12/30/2009 04:09 AM wrote:
> Is there some way that this will help me - the original poster?
Unfortunately, no. I have not, yet, investigated too far into the
compositor Nokia is using. My app references were to compiz, the
compositor found on most Linux desktop distributions.
- Original message -
> You could try playing with the CLUTTER_VBLANK env var (set it to "none",
> "dri" or "glx") to see if it helps.
No joy with that one - makes no difference at all.
___
maemo-developers mailing list
maemo-developers@maemo.or
On Wed, 2009-12-30 at 15:40 +, Mark Clarkson wrote:
> > - Original message -
> > > off on the *compositor*. My own apps are tear free until I turn off..
>
> Ah. Is there some way that this will help me - the original poster?
> Does clutter bypass the compositor by making its opengl cal
> - Original message -
> > off on the *compositor*. My own apps are tear free until I turn off..
Ah. Is there some way that this will help me - the original poster? Does
clutter bypass the compositor by making its opengl calls? Do I need to somehow
render clutter output to an offscreen b
Eero Tamminen on 12/30/2009 04:09 AM wrote:
> Incorrect.
I guess there's some illegal black magic happening in-between compiz and
apps regardless of UI toolkit libraries. Apps such as dasher that
present rectangles and text at fast speeds do not present any tearing
when I have the *compositor*
Hi everyone,
I am looking for the app that appears in this video
http://www.youtube.com/watch?v=HblSL0hG6Wg at 1:14, in the More... folder,
second raw, last column, called "ftdapp" but I really can't find it anywhere.
Does anyone have any information on this?
If it is the same as the ftd appli
Hi,
ext Xavier Bestel wrote:
>> But where inside the application process they happen (app or Gtk code)
>> is not so important. The issue is that Gtk (AFAIK) has no mechanism to
>> synchronize this drawing with the compositor and doesn't offer
>> applications any mechanism for it either. If paint
Hi,
ext Thomas Tanner wrote:
> sorry for my ignorance - I've only recently started following the
> optification discussion.
>
> Is there any good reason why Maemo does not follow the standard UNIX
> layout with user applications in /usr/local ?
> /usr/local seems to be in all search paths and if
On Wed, 2009-12-30 at 14:44 +0200, Eero Tamminen wrote:
> Hi,
>
> ext Claudio Saavedra wrote:
> > El mar, 29-12-2009 a las 17:17 +0200, Eero Tamminen escribió:
> >> This is not really
> >> fixable due to how Gtk painting is arranged, parts of the window are
> >> painted in application callbacks.
Hi,
ext Claudio Saavedra wrote:
> El mar, 29-12-2009 a las 17:17 +0200, Eero Tamminen escribió:
>> This is not really
>> fixable due to how Gtk painting is arranged, parts of the window are
>> painted in application callbacks.
>
> This is not totally correct. Application callbacks can only caus
ext Thomas Tanner writes:
> /usr/local seems to be in all search paths
You might be right, but my gut doesn't trust this, not with a system
with as little respect to tradition as Maemo has (i.e., our own new
components will in all likelyhood get this spectacularily wrong).
Also, putting stuff i
El mar, 29-12-2009 a las 17:17 +0200, Eero Tamminen escribió:
> This is not really
> fixable due to how Gtk painting is arranged, parts of the window are
> painted in application callbacks.
This is not totally correct. Application callbacks can only cause GTK+
to *invalidate* regions. In sane co
I'm aware that standard Debian packages would
need to adapted but it would mainly involve replacing
/usr with /usr/local (or removing /usr as /usr/local is the default
prefix in autoconf), correct?
Andrew Flegg wrote:
> On Wed, Dec 30, 2009 at 12:23, Thomas Tanner wrote:
>> Is there any good reas
On Wed, Dec 30, 2009 at 12:23, Thomas Tanner wrote:
>
> Is there any good reason why Maemo does not follow the standard UNIX
> layout with user applications in /usr/local ?
> /usr/local seems to be in all search paths and if /usr/local
> would be just a symlink to /home/local there would be no nee
Hi,
sorry for my ignorance - I've only recently started following the
optification discussion.
Is there any good reason why Maemo does not follow the standard UNIX
layout with user applications in /usr/local ?
/usr/local seems to be in all search paths and if /usr/local
would be just a symlink to
Patrick Ohly skrev:
> Looking at the code again and in particular
> SyncSourceRevisions::updateRevision(), I remembered one problem with the
> "changes since last sync" approach of change tracking. Suppose the
> following chain of events:
> 1. sync starts at time T1, with no local changes
>
On Wed, 2009-12-30 at 06:42 +, Ove Kaaven wrote:
> Patrick Ohly skrev:
> > This is becoming more SyncEvolution specific. Should we continue
> > cross-posting to maemo-developers?
>
> Dunno, I wasn't subscribed to the syncevolution list yet. I suppose I
> should subscribe to it. But I think som
Hi,
ext Michael Cronenworth wrote:
> Eero Tamminen on 12/29/2009 09:17 AM wrote:
>> because Gtk doesn't have any support for Vsync.
>
> Gtk doesn't need to support Vsync. Qt won't magically fix this problem
> either.
>
> Only the compositor needs to support Vsync. Once it does then *all* 2D
>
Hi,
I am writing an app for the n900 which requires smooth animation within a
subwindow. I want to retain the top toolbar and make use of hildon's themed
widgets - I want to keep, as much as possible, the maemo 5 look and feel.
I have tried cairo animation and clutter (bug #7459), neither of whi
Am Mittwoch, den 30.12.2009, 12:56 +0800 schrieb bocheng cheng:
> Hi Everyone:
> Does maemo5 support portrait view by now ?
It always did for some specific applications. For future reference post
such non-developer questions to the maemo-users mailinglist please.
andre
--
Andre Klapper (maemo.o
33 matches
Mail list logo
