Re: hildron_entry and activate signal

[Fred Lefévère-Laoide]

No I can't because :
- I cannot figure out how to fire the signal in the SDK.
- I works fine on Diablo
- I do not have a fremantle device

Fred

Le 29/09/2009 08:54, Qiang Chai a écrit :
> Can you figure out which line of code crashes?
>
> Maybe you can check the pointer value of main->filter_tb and the
> callback function's widget parameter to see if they are the sam.
>
> 2009/9/29 Fred Lefévère-Laoide  >
>
> Hi,
>
> I can't manage to fiure the activate signal on a hildon_entry in the SDK
> And my code crashes on the real device (that I do not have :( )
>
> Any hint or idea ?
>
> the same code works fine in Diablo with a gtk_text_entry instead of a
> hildon_text_entry ...
>
> here is the relevant code
> main->filter_tb = hildon_entry_new(HILDON_SIZE_AUTO);
> ...
> g_signal_connect(G_OBJECT(main->filter_tb), "activate",
> G_CALLBACK(callback_filter), main);
> ...
> void callback_filter(GtkWidget *widget, MainView *mainview ) {
>  gchar *ftxt = NULL;
>  GList *onrec=NULL;
>
>  ftxt = hildon_entry_get_text(HILDON_ENTRY(widget));
>
>  ...
>
> }
>
> Thanks for your help
>
> Fred
> ___
> maemo-developers mailing list
> maemo-developers@maemo.org 
> https://lists.maemo.org/mailman/listinfo/maemo-developers
>
>
>
>
> --
> Best Regards
> Chai Qiang

___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: hildron_entry and activate signal

[Qiang Chai]

Can you figure out which line of code crashes?

Maybe you can check the pointer value of main->filter_tb and the callback
function's widget parameter to see if they are the sam.

2009/9/29 Fred Lefévère-Laoide 

> Hi,
>
> I can't manage to fiure the activate signal on a hildon_entry in the SDK
> And my code crashes on the real device (that I do not have :( )
>
> Any hint or idea ?
>
> the same code works fine in Diablo with a gtk_text_entry instead of a
> hildon_text_entry ...
>
> here is the relevant code
> main->filter_tb = hildon_entry_new(HILDON_SIZE_AUTO);
> ...
> g_signal_connect(G_OBJECT(main->filter_tb), "activate",
> G_CALLBACK(callback_filter), main);
> ...
> void callback_filter(GtkWidget *widget, MainView *mainview ) {
> gchar *ftxt = NULL;
> GList *onrec=NULL;
>
> ftxt = hildon_entry_get_text(HILDON_ENTRY(widget));
>
> ...
>
> }
>
> Thanks for your help
>
> Fred
> ___
> maemo-developers mailing list
> maemo-developers@maemo.org
> https://lists.maemo.org/mailman/listinfo/maemo-developers
>



-- 
Best Regards
Chai Qiang
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

hildron_entry and activate signal

[Fred Lefévère-Laoide]

Hi,

I can't manage to fiure the activate signal on a hildon_entry in the SDK
And my code crashes on the real device (that I do not have :( )

Any hint or idea ?

the same code works fine in Diablo with a gtk_text_entry instead of a 
hildon_text_entry ...

here is the relevant code
main->filter_tb = hildon_entry_new(HILDON_SIZE_AUTO);
...
g_signal_connect(G_OBJECT(main->filter_tb), "activate", 
G_CALLBACK(callback_filter), main);
...
void callback_filter(GtkWidget *widget, MainView *mainview ) {
 gchar *ftxt = NULL;
 GList *onrec=NULL;

 ftxt = hildon_entry_get_text(HILDON_ENTRY(widget));

 ...

}

Thanks for your help

Fred
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: git push problem at git.maemo.org

[Benoît HERVIER]

Did you want i submit a bug in bugs.maemo.org ?

Le 29 septembre 2009 06:22, Benoît HERVIER  a écrit :
> Hi,
>
> So for migrating from svn to git this doesn't seems related. I still
> see svn on mSaber and PyGTKEditor where conversion fail due to fact
> that svn was never used.
>
> https://git.maemo.org/svn2git_logs/svn2git_request_pygtkeditor.log
> https://git.maemo.org/svn2git_logs/svn2git_request_msaber.log
>
> And the error was the same this morning ...
> https://git.maemo.org/svn2git_logs/svn2git_request_mbluead.log
>
> Thanks for help
>
> 2009/9/29 Ferenc Szekely :
>> Hi again,
>>
>> git push works again on git.maemo.org. I don't even want to say what the
>> problem was... shame on me, but I forgot to turn "DAV on" for the
>> project repositories. The web server did its job to serve the content as
>> is, not giving a chance to the webdav module to chew on the requests
>> from git. What a lame sysadmin, you may say.
>>
>> Sorry to all who got some bad days because of this. I owe you a beer on
>> the summit. ;)
>>
>> Cheers,
>> ferenc
>>
>>
>> Ferenc Szekely wrote:
>>> Hello,
>>>
>>> Ferenc Szekely wrote:
 Hi,

 Alberto Mardegan wrote:
> Ferenc Szekely wrote:
>> Apologies for the inconvenience if you and your project are affected.
> In the meantime are there any workarounds to this problem?
>
 No workaround as we speak. I took a couple of "problematic" repositories
 from the server and tried accessing them via WebDAV on a different
 machine. I can confirm that push works to those repos. I will now check
 the diff between the two setups and hope to get come clue from that
 investigation.

>>> I found the problem regarding git push failures. Unfortunately this is
>>> related to my attempts fixing a sechole in our gitweb setup a few days ago.
>>>
>>> For those who are interested: git always sends a PROPFIND request first
>>> when you do a git push (this is over HTTP, remember). The server replies
>>> with the git.maemo.org "frontpage", which is obviously not the content
>>> what git would expect.
>>>
>>> Now wondering about a quick fix, so that the repos and gitweb could
>>> happily live together again.
>>>
>>> -ferenc
>> ___
>> maemo-developers mailing list
>> maemo-developers@maemo.org
>> https://lists.maemo.org/mailman/listinfo/maemo-developers
>>
>
>
>
> --
> Benoît HERVIER - http://khertan.net/
>



-- 
Benoît HERVIER - http://khertan.net/
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: git push problem at git.maemo.org

[Benoît HERVIER]

Hi,

So for migrating from svn to git this doesn't seems related. I still
see svn on mSaber and PyGTKEditor where conversion fail due to fact
that svn was never used.

https://git.maemo.org/svn2git_logs/svn2git_request_pygtkeditor.log
https://git.maemo.org/svn2git_logs/svn2git_request_msaber.log

And the error was the same this morning ...
https://git.maemo.org/svn2git_logs/svn2git_request_mbluead.log

Thanks for help

2009/9/29 Ferenc Szekely :
> Hi again,
>
> git push works again on git.maemo.org. I don't even want to say what the
> problem was... shame on me, but I forgot to turn "DAV on" for the
> project repositories. The web server did its job to serve the content as
> is, not giving a chance to the webdav module to chew on the requests
> from git. What a lame sysadmin, you may say.
>
> Sorry to all who got some bad days because of this. I owe you a beer on
> the summit. ;)
>
> Cheers,
> ferenc
>
>
> Ferenc Szekely wrote:
>> Hello,
>>
>> Ferenc Szekely wrote:
>>> Hi,
>>>
>>> Alberto Mardegan wrote:
 Ferenc Szekely wrote:
> Apologies for the inconvenience if you and your project are affected.
 In the meantime are there any workarounds to this problem?

>>> No workaround as we speak. I took a couple of "problematic" repositories
>>> from the server and tried accessing them via WebDAV on a different
>>> machine. I can confirm that push works to those repos. I will now check
>>> the diff between the two setups and hope to get come clue from that
>>> investigation.
>>>
>> I found the problem regarding git push failures. Unfortunately this is
>> related to my attempts fixing a sechole in our gitweb setup a few days ago.
>>
>> For those who are interested: git always sends a PROPFIND request first
>> when you do a git push (this is over HTTP, remember). The server replies
>> with the git.maemo.org "frontpage", which is obviously not the content
>> what git would expect.
>>
>> Now wondering about a quick fix, so that the repos and gitweb could
>> happily live together again.
>>
>> -ferenc
> ___
> maemo-developers mailing list
> maemo-developers@maemo.org
> https://lists.maemo.org/mailman/listinfo/maemo-developers
>



-- 
Benoît HERVIER - http://khertan.net/
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Debmaster: Help for PyMaemo dependency hell on Fremantle?

[Benoît HERVIER]

The diablo version was the last ... but ... maybe it s the fremantle
which is older :)

Anyway i ll push it.

Thx for the fix.

Le 28 septembre 2009 22:24, Thomas Wälti  a écrit :
> Hello Benoît
>
> Here is the fix: Change line 312 (? depending on your current version...) to
>
> #==
>     # CREATE debian/changelog
>
> #==
>     clog="""%(name)s (%(version)s-%(buildversion)s) stable;
> urgency=low
>
> The proof that it works: http://maemo.org/packages/view/mclock/ :-)
>
> PS: Can you afterwards upload py2deb (0.5.0)  to the diablo and fremantle
> repos? (I believe in diablo is still the old version without the script
> support.)
>
> Merci and thanks to all involved - case closed
> -Tom
>
>
>
> 2009/9/28 Benoît HERVIER 
>>
>> Hi,
>>
>> Ok this is clearly a bug of py2deb which didn't include the package
>> number.
>> I ll fix this tomorrow in the morning.
>>
>> Best regards,
>>
>> 2009/9/28 Thomas Waelti :
>> >>> So I guess there must be a bug somewhere in my package files.
>> >>
>> >> There is, it's in the changelog.
>> >>
>> >> The canonical place for the version string is in your changelog -
>> >> debian tools look for that string and assign the version based on
>> >> that. Here's the first line of your changelog for verion 0.6.4:
>> >>
>> >> mclock (0.6.4) stable; urgency=low
>> >>
>> >> As you can see there is no -1 after the version number. Also, the
>> >> following word after the version in parentheses is "stable", but it
>> >> really should be "unstable" since this signifies which debian
>> >> repository this package is destined for. Of course, Maemo is not
>> >> debian, so this is irrelevant at this point in time.
>> >
>> > Thanks for the help, I'll go after that and hunt and hopefully fix the
>> > bug.
>> > (For me, finding this would have been like a needle in a haystack)
>> >
>> >> I recommend using the tools recommended by debian and Maemo[0],
>> >> specifically dh_make. The simple reason I recommend dh_make is that I
>> >> have more experience with that then py2deb and I know that dh_make is
>> >> well tested and used extensively in debian.
>> >
>> > Yes, I fully understand and agree. However, the idea is to offer an
>> > option to build a package for people without a linux desktop, so that they
>> > can prepare the package parts directly on their device and upload from 
>> > there
>> > (same goes for pypackager). This also offers a quick way to "package"
>> > command line hacks (such as the gconf options for the display timeout, aka
>> > moreDimmingOptions)
>> >
>> > Best regards
>> > -Tom
>> >
>> > ___
>> > maemo-developers mailing list
>> > maemo-developers@maemo.org
>> > https://lists.maemo.org/mailman/listinfo/maemo-developers
>> >
>>
>>
>>
>> --
>> Benoît HERVIER - http://khertan.net/
>
>



-- 
Benoît HERVIER - http://khertan.net/
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: git push problem at git.maemo.org

[Ferenc Szekely]

Hi again,

git push works again on git.maemo.org. I don't even want to say what the
problem was... shame on me, but I forgot to turn "DAV on" for the
project repositories. The web server did its job to serve the content as
is, not giving a chance to the webdav module to chew on the requests
from git. What a lame sysadmin, you may say.

Sorry to all who got some bad days because of this. I owe you a beer on
the summit. ;)

Cheers,
ferenc


Ferenc Szekely wrote:
> Hello,
> 
> Ferenc Szekely wrote:
>> Hi,
>>
>> Alberto Mardegan wrote:
>>> Ferenc Szekely wrote:
 Apologies for the inconvenience if you and your project are affected.
>>> In the meantime are there any workarounds to this problem?
>>>
>> No workaround as we speak. I took a couple of "problematic" repositories
>> from the server and tried accessing them via WebDAV on a different
>> machine. I can confirm that push works to those repos. I will now check
>> the diff between the two setups and hope to get come clue from that
>> investigation.
>>
> I found the problem regarding git push failures. Unfortunately this is
> related to my attempts fixing a sechole in our gitweb setup a few days ago.
> 
> For those who are interested: git always sends a PROPFIND request first
> when you do a git push (this is over HTTP, remember). The server replies
> with the git.maemo.org "frontpage", which is obviously not the content
> what git would expect.
> 
> Now wondering about a quick fix, so that the repos and gitweb could
> happily live together again.
> 
> -ferenc
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: git push problem at git.maemo.org

[Ferenc Szekely]

Hello,

Ferenc Szekely wrote:
> Hi,
> 
> Alberto Mardegan wrote:
>> Ferenc Szekely wrote:
>>> Apologies for the inconvenience if you and your project are affected.
>> In the meantime are there any workarounds to this problem?
>>
> No workaround as we speak. I took a couple of "problematic" repositories
> from the server and tried accessing them via WebDAV on a different
> machine. I can confirm that push works to those repos. I will now check
> the diff between the two setups and hope to get come clue from that
> investigation.
> 
I found the problem regarding git push failures. Unfortunately this is
related to my attempts fixing a sechole in our gitweb setup a few days ago.

For those who are interested: git always sends a PROPFIND request first
when you do a git push (this is over HTTP, remember). The server replies
with the git.maemo.org "frontpage", which is obviously not the content
what git would expect.

Now wondering about a quick fix, so that the repos and gitweb could
happily live together again.

-ferenc
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Debmaster: Help for PyMaemo dependency hell on Fremantle?

[Thomas Wälti]

Hello Benoît

Here is the fix: Change line 312 (? depending on your current version...) to

#==
# CREATE debian/changelog

#==
clog="""%(name)s (%(version)s-%(buildversion)s) stable;
urgency=low

The proof that it works: http://maemo.org/packages/view/mclock/ :-)

PS: Can you afterwards upload py2deb (0.5.0)  to the diablo and fremantle
repos? (I believe in diablo is still the old version without the script
support.)

Merci and thanks to all involved - case closed
-Tom



2009/9/28 Benoît HERVIER 

> Hi,
>
> Ok this is clearly a bug of py2deb which didn't include the package number.
> I ll fix this tomorrow in the morning.
>
> Best regards,
>
> 2009/9/28 Thomas Waelti :
> >>> So I guess there must be a bug somewhere in my package files.
> >>
> >> There is, it's in the changelog.
> >>
> >> The canonical place for the version string is in your changelog -
> >> debian tools look for that string and assign the version based on
> >> that. Here's the first line of your changelog for verion 0.6.4:
> >>
> >> mclock (0.6.4) stable; urgency=low
> >>
> >> As you can see there is no -1 after the version number. Also, the
> >> following word after the version in parentheses is "stable", but it
> >> really should be "unstable" since this signifies which debian
> >> repository this package is destined for. Of course, Maemo is not
> >> debian, so this is irrelevant at this point in time.
> >
> > Thanks for the help, I'll go after that and hunt and hopefully fix the
> bug.
> > (For me, finding this would have been like a needle in a haystack)
> >
> >> I recommend using the tools recommended by debian and Maemo[0],
> >> specifically dh_make. The simple reason I recommend dh_make is that I
> >> have more experience with that then py2deb and I know that dh_make is
> >> well tested and used extensively in debian.
> >
> > Yes, I fully understand and agree. However, the idea is to offer an
> option to build a package for people without a linux desktop, so that they
> can prepare the package parts directly on their device and upload from there
> (same goes for pypackager). This also offers a quick way to "package"
> command line hacks (such as the gconf options for the display timeout, aka
> moreDimmingOptions)
> >
> > Best regards
> > -Tom
> >
> > ___
> > maemo-developers mailing list
> > maemo-developers@maemo.org
> > https://lists.maemo.org/mailman/listinfo/maemo-developers
> >
>
>
>
> --
> Benoît HERVIER - http://khertan.net/
>
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Debmaster: Help for PyMaemo dependency hell on Fremantle?

[Benoît HERVIER]

Hi,

Ok this is clearly a bug of py2deb which didn't include the package number.
I ll fix this tomorrow in the morning.

Best regards,

2009/9/28 Thomas Waelti :
>>> So I guess there must be a bug somewhere in my package files.
>>
>> There is, it's in the changelog.
>>
>> The canonical place for the version string is in your changelog -
>> debian tools look for that string and assign the version based on
>> that. Here's the first line of your changelog for verion 0.6.4:
>>
>> mclock (0.6.4) stable; urgency=low
>>
>> As you can see there is no -1 after the version number. Also, the
>> following word after the version in parentheses is "stable", but it
>> really should be "unstable" since this signifies which debian
>> repository this package is destined for. Of course, Maemo is not
>> debian, so this is irrelevant at this point in time.
>
> Thanks for the help, I'll go after that and hunt and hopefully fix the bug.
> (For me, finding this would have been like a needle in a haystack)
>
>> I recommend using the tools recommended by debian and Maemo[0],
>> specifically dh_make. The simple reason I recommend dh_make is that I
>> have more experience with that then py2deb and I know that dh_make is
>> well tested and used extensively in debian.
>
> Yes, I fully understand and agree. However, the idea is to offer an option to 
> build a package for people without a linux desktop, so that they can prepare 
> the package parts directly on their device and upload from there (same goes 
> for pypackager). This also offers a quick way to "package" command line hacks 
> (such as the gconf options for the display timeout, aka moreDimmingOptions)
>
> Best regards
> -Tom
>
> ___
> maemo-developers mailing list
> maemo-developers@maemo.org
> https://lists.maemo.org/mailman/listinfo/maemo-developers
>



-- 
Benoît HERVIER - http://khertan.net/
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: git push problem at git.maemo.org

[Benoît HERVIER]

Hi,

Trying to migrate mSaber from svn to git (clean project without
anything imported), i got a 404 error on the log ... and seems still
to svn, and didn't have the option anymore to move to git.

Also i got error trying to move also pygtkeditor without success.

Best regards,

2009/9/28 Ferenc Szekely :
> Hi,
>
> Alberto Mardegan wrote:
>> Ferenc Szekely wrote:
>>> Apologies for the inconvenience if you and your project are affected.
>>
>> In the meantime are there any workarounds to this problem?
>>
> No workaround as we speak. I took a couple of "problematic" repositories
> from the server and tried accessing them via WebDAV on a different
> machine. I can confirm that push works to those repos. I will now check
> the diff between the two setups and hope to get come clue from that
> investigation.
>
>> Ciao,
>>   Alberto
>>
> Cheers,
> ferenc
> ___
> maemo-developers mailing list
> maemo-developers@maemo.org
> https://lists.maemo.org/mailman/listinfo/maemo-developers
>



-- 
Benoît HERVIER - http://khertan.net/
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: What's the best attack? (Re: How to use extras-testing correctly?)`

[Benoît HERVIER]

Yeah ... come back to the old time where every developpers create his
own repository. :)


2009/9/28 gary liquid :
>
>
> On Fri, Sep 25, 2009 at 5:29 PM,  wrote:
>>
>> - Original message -
>> > the apps in maemo extras *should* be trusted because we, the community,
>> > trust
>> > the developers who put them there.
>>
>> Gary, I trust the community, but I really want to be sure.
>>
>> It is also because I like the community so much that I want to keep extras
>> a safe place. For some new users it will be the first point of contact to
>> OSS. If that contact is good, more people will find the community and more
>> will join.
>
> nobody can anonymously upload to extras without first applying.
> from a community perspective, there is already a feeling of being vetted
> prior to getting upload rights.
>>
>> > it would take 1 bad report to have the software removed from extras.
>> >
>> > its a worrying scenario for some people,  but this isnt the wild west
>> > and like
>> > all trust based mechanisms, people in the community are given rights to
>> > upload
>> > hopefully based on their standing.
>>
>> That would be one form of security I would be ok with.
>> But screening people (karma or participation or whatever) for the right to
>> upload is even more questionable than having a team of testers go through
>> the apps. Everyone has to have the right to right to put their stuff to
>> devel and testing.
>
> as said, there is already an application stage.
> if the community mindset is there of vetting, no matter how vague, it helps.
>>
>> > There are many steps along the way to being involved in the community
>> > and i do
>> > not see why an individual would be nefarious enough to go through all
>> > those just
>> > to infect a few machines.
>> >
>> > people are given rights and responsibilities and mechanisms are in place
>> > to
>> > hopefully prevent an incident such as you are describing.
>>
>> Pretty much so. But I don't want to risk even a single case however
>> unlikely it is.
>
> *nod* this is a common goal.
>>
>> > it falls on each and every one of us to maintain that trust.
>>
>> It is about trust, but there is the question of security too.
>>
>> I hope the solution that is now implemented is one that works, but as
>> always, if practise shows that it needs to be rethought, then we will.
>
> yes, testing is the further step and should help to prevent even the most
> determined of individuals.
> it is rare to see applications coming through maemo.org where there isn't
> community participation at some level
>
> gary
>>
>> Tero
>>
>> Tero
>>
>> > gary
>> >
>> >
>> >
>> >
>> > On Fri, Sep 25, 2009 at 3:40 PM, David Greaves
>> >  wrote:
>> >
>> > tero.k...@nokia.com wrote:
>> > > - Original message -
>> > > >
>> >
>> > > > I realise this is a slightly different question (hence the new
>> > > > subject)
>> > > >
>> > > > OK, say I have an evil twin who wants to attack ('own') a lot of
>> > > > Nokia
>> > > N900
>> > > > devices. How do I do this?
>> > >
>> > > I hope that was retorical. Tell your evil twin to do something
>> > > usefull.
>> >
>> >
>> > Err, no it wasn't retorical; it was hypothetical though in case you were
>> > worried.
>> >
>> > It's more about being responsible :)
>> > Actually it is very late in the day to be asking... but hey, it sounds
>> > like a
>> > topic worth raising.
>> >
>> > > > Does extras-testing factor into this?
>> > >
>> > > At least so that I would prefer maemo.org extras to be clean from
>> > > malware. It is much easier to promote it in Nokia internally when
>> > > extras
>> > > contains good software.
>> >
>> >
>> > I agree 100% ... all it takes is one example of malware introduced into
>> > an OSS
>> > product and we (and Nokia) could lose a lot of credibility.
>> >
>> > I wonder how much that could be worth to some people? Maybe worth a
>> > deliberate
>> > attack? Maybe someone is playing a longer game?
>> >
>> > I just hope we are not planning on taking the "cross your fingers and
>> > toes
>> > *REALLY HARD* and hope everyone is nice to us" approach to security ;)
>> >
>> > Discuss...
>> >
>> > David
>> >
>> >
>> > --
>> > "Don't worry, you'll be fine; I saw it work in a cartoon once..."
>> >
>> >
>> >
>> > ___
>> > maemo-developers mailing list
>> > maemo-developers@maemo.org
>> > https://lists.maemo.org/mailman/listinfo/maemo-developers
>> >
>> >
>> >
>> >
>> >
>> >
>>
>
>
> ___
> maemo-developers mailing list
> maemo-developers@maemo.org
> https://lists.maemo.org/mailman/listinfo/maemo-developers
>
>



-- 
Benoît HERVIER - http://khertan.net/
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: git push problem at git.maemo.org

[Javier S. Pedro]

> Please let me know if you experienced problems (except speed) when
> pushing code changes to git.maemo.org. Also please let me know if you
> read or heard about workarounds in case git (or actually curl) returns
> with "error code 18" [2] following push.

Hi,

Since a few days, I've not been able to push to "drnoksnes" repo in git.m.o due 
to the that same "error code 18".

Unfortunately, I don't remember doing anything special to "break it", so I 
guess I can't help with debugging the issue.

Thanks for the work, though. :)
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: git push problem at git.maemo.org

[Ferenc Szekely]

Hi,

Alberto Mardegan wrote:
> Ferenc Szekely wrote:
>> Apologies for the inconvenience if you and your project are affected.
> 
> In the meantime are there any workarounds to this problem?
> 
No workaround as we speak. I took a couple of "problematic" repositories
from the server and tried accessing them via WebDAV on a different
machine. I can confirm that push works to those repos. I will now check
the diff between the two setups and hope to get come clue from that
investigation.

> Ciao,
>   Alberto
> 
Cheers,
ferenc
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Debmaster: Help for PyMaemo dependency hell on Fremantle?

[Thomas Waelti]

>> So I guess there must be a bug somewhere in my package files.
>
> There is, it's in the changelog.
>
> The canonical place for the version string is in your changelog -
> debian tools look for that string and assign the version based on
> that. Here's the first line of your changelog for verion 0.6.4:
>
> mclock (0.6.4) stable; urgency=low
>
> As you can see there is no -1 after the version number. Also, the
> following word after the version in parentheses is "stable", but it
> really should be "unstable" since this signifies which debian
> repository this package is destined for. Of course, Maemo is not
> debian, so this is irrelevant at this point in time.

Thanks for the help, I'll go after that and hunt and hopefully fix the bug.
(For me, finding this would have been like a needle in a haystack)

> I recommend using the tools recommended by debian and Maemo[0],
> specifically dh_make. The simple reason I recommend dh_make is that I
> have more experience with that then py2deb and I know that dh_make is
> well tested and used extensively in debian.

Yes, I fully understand and agree. However, the idea is to offer an option to 
build a package for people without a linux desktop, so that they can prepare 
the package parts directly on their device and upload from there (same goes for 
pypackager). This also offers a quick way to "package" command line hacks (such 
as the gconf options for the display timeout, aka moreDimmingOptions)

Best regards
-Tom

___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: git push problem at git.maemo.org

[Alberto Mardegan]

Ferenc Szekely wrote:
> Apologies for the inconvenience if you and your project are affected.

In the meantime are there any workarounds to this problem?

Ciao,
   Alberto

-- 
http://www.mardy.it <- geek in un lingua international!
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Community widgets for Fremantle

[Cornelius Hald]

On Mon, 2009-09-28 at 16:17 +0200, Cornelius Hald wrote:
> Well, HildonColorChooser and GtkColorSelection already have totally
> different API. So I wouldn't even know which one of them to emulate.
> Also Hildon and Gtk will still be around, so we can't develop a drop-in
> replacement because the namespace is already taken. Therefore I think we
> can go with our own API.

OTOH if we expect this to be part of Hildon and we expect it to
_replace_ the current HildonColorChooser it might make sense trying to
be as close as possible to this API. So we just could replace the
implementation be leave the interface. But here my C experience is weak,
so maybe better someone else comment on that :)

Conny


___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Community widgets for Fremantle

[Cornelius Hald]

> I'm not completely sure what you're asking :) Could you
> elaborate a bit
> please.
> 
> well, a simple dialog is one thing and thats what we appear to be
> rounding on now.
> 
> but I'm sure over the years in the main libraries, options and flags
> and extra bits have been added to the dialogs and the api to account
> for usage cases.
> do we simply draw the line and say, this is a new community dialog
> library, or do we go the extra mile and try to accommodate all those
> little extra peculiarities which no doubt exist.

Well, HildonColorChooser and GtkColorSelection already have totally
different API. So I wouldn't even know which one of them to emulate.
Also Hildon and Gtk will still be around, so we can't develop a drop-in
replacement because the namespace is already taken. Therefore I think we
can go with our own API.

Other opinions?
Conny

http://maemo.org/api_refs/4.0/hildon/HildonColorChooser.html
http://library.gnome.org/devel/gtk/unstable/GtkColorSelection.html


___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Community widgets for Fremantle

[Graham Cobb]

On Monday 28 September 2009 14:48:01 Cornelius Hald wrote:
> On Mon, 2009-09-28 at 13:28 +, gary liquid wrote:
> > do we attempt to make sure the api/options for a gtk/hildon/sexy lib
> > replacement exist, or do we aim for a maemo_community library for
> > these kinds of dialogs?
>
> I'm not completely sure what you're asking :) Could you elaborate a bit
> please.

I think Conny's suggestion of a garage project to start with is a good idea.  
Instead of deciding, now, whether these will go into Hildon or be seperate, 
why not develop them initially as pieces of standalone code that people 
include (as source code) into their projects to use, for now?

Then if Hildon adopts them (ideal solution in my mind), the 
CommunityColourSelector would be incorporated into Hildon as a 
HildonColourSelector and people could throw away their copy of the code.

And applications which want to support multiple Maemo versions can use the 
Hildon version if the Hildon library is recent enough or use their own 
private version if not.

Graham
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Community widgets for Fremantle

[gary liquid]

On Mon, Sep 28, 2009 at 1:48 PM, Cornelius Hald  wrote:

> On Mon, 2009-09-28 at 13:28 +, gary liquid wrote:
> > for now, sure its the only practical way we are going to advance
> > since we have a good idea what this may look like, how about we get
> > down to sorting out where its going to live.
>
> I was hoping that we get some input from the Hildon project about the
> open questions. But from my point of view we need something simple to
> start. I still think that a garage project would be best. Then when we
> actually have results, we can still discuss what to do with them.
>
> > do we attempt to make sure the api/options for a gtk/hildon/sexy lib
> > replacement exist, or do we aim for a maemo_community library for
> > these kinds of dialogs?
>
> I'm not completely sure what you're asking :) Could you elaborate a bit
> please.
>

well, a simple dialog is one thing and thats what we appear to be rounding
on now.

but I'm sure over the years in the main libraries, options and flags and
extra bits have been added to the dialogs and the api to account for usage
cases.
do we simply draw the line and say, this is a new community dialog library,
or do we go the extra mile and try to accommodate all those little extra
peculiarities which no doubt exist.

gary



>
> Thanks!
> Conny
>
>
>
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Community widgets for Fremantle

[Cornelius Hald]

On Mon, 2009-09-28 at 13:28 +, gary liquid wrote:
> for now, sure its the only practical way we are going to advance
> since we have a good idea what this may look like, how about we get
> down to sorting out where its going to live.

I was hoping that we get some input from the Hildon project about the
open questions. But from my point of view we need something simple to
start. I still think that a garage project would be best. Then when we
actually have results, we can still discuss what to do with them.

> do we attempt to make sure the api/options for a gtk/hildon/sexy lib
> replacement exist, or do we aim for a maemo_community library for
> these kinds of dialogs?

I'm not completely sure what you're asking :) Could you elaborate a bit
please.

Thanks!
Conny


___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Community widgets for Fremantle

[Cornelius Hald]

On Mon, 2009-09-28 at 15:29 +0200, Thomas Perl wrote:
> 2009/9/28 Cornelius Hald :
> > On Mon, 2009-09-28 at 13:00 +0200, Thomas Perl wrote:
> >>  * Added pure black and white as suggested by Graham
> >>  * One slot is free (when the current setting is a custom color that is
> >>not in the palette, the slot will be taken by that color and 
> >> pre-selected)
> >
> > Do you think that one custom color is enough? How about having a
> > complete column or row for custom colors? I didn't try it, but it looks
> > like there could be enough room for a fourth row of colors.
> 
> With the "one custom color" I mean a situation like this:
> 
> 1.) The default color set by the application is #ff (which is not in
>  the Tango palette) - default for some setting, not application wide
> 2.) User clicks on the button that brings up the color selector dialog
> 3.) The resulting dialog should show a "current" state, and without the
>  single button for #ff added, none of the color buttons could
>  be selected.

Ah ok, now I see and it makes sense to me :)

> For the custom colors, I think we can add a whole palette (named
> "User defined"?) to the selection, and let the user customize it. This
> "User defined" palette (again, 18 colors) can then be shared among
> applications. It should probably be editable from within the dialog.

That's another good idea and also prevents the dialog from being too
cramped.

I like it!
Conny


___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: MMS Implementation conversation

[Mohammed Hassan]

On Mon, 2009-09-28 at 15:24 +0200, ext Ville M. Vainio wrote:
> On Mon, Sep 28, 2009 at 12:58 PM, gary liquid  wrote:
> > hi,
> >
> > this morning a conversation took place in #maemo which begun to discuss the
> > specifics of implementing MMS in the n900
> > I have posted the conversation onto the wiki, but it requires extensive
> > weeding and cleanup and converting into an outline and spec
> >
> > please get involved and have a go at getting rid of the extra stuff or
> > attempt to fill in any blanks or problems.
> >
> > http://wiki.maemo.org/Mms_implemention_conversation
> 
> There is also brainstorm item for this:
> 
> http://maemo.org/community/brainstorm/view/mms_support/
> 
> Regarding that irc conversation - there is also the "low tech"
> approach of tearing down the old ppp connection and setting up a new
> one. I've seen this done on Symbian devices (when I was working on an
> mms implementation).

>From the IRC discussion (And from a private discussion between me and
ab) I understand that in order to maintain 2 connections, the modem
should be able to dial a 2nd MMS connection without disconnecting the
previous one. I'm not sure this is possible but I simply do not know.

I never received an MMS while connected via GPRS with my Symbian phone
so I don't know.

Of course if the modem can't dial and maintain 2 connections then the
remaining solution is to disconnnect GPRS, connect MMS, send || receive
then reconnect GPRS.

Cheers,


-- 
Senior Software Engineer
Maemo Software

___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Community widgets for Fremantle

[Thomas Perl]

2009/9/28 Cornelius Hald :
> On Mon, 2009-09-28 at 13:00 +0200, Thomas Perl wrote:
>>  * Added pure black and white as suggested by Graham
>>  * One slot is free (when the current setting is a custom color that is
>>    not in the palette, the slot will be taken by that color and pre-selected)
>
> Do you think that one custom color is enough? How about having a
> complete column or row for custom colors? I didn't try it, but it looks
> like there could be enough room for a fourth row of colors.

With the "one custom color" I mean a situation like this:

1.) The default color set by the application is #ff (which is not in
 the Tango palette) - default for some setting, not application wide
2.) User clicks on the button that brings up the color selector dialog
3.) The resulting dialog should show a "current" state, and without the
 single button for #ff added, none of the color buttons could
 be selected.

For the custom colors, I think we can add a whole palette (named
"User defined"?) to the selection, and let the user customize it. This
"User defined" palette (again, 18 colors) can then be shared among
applications. It should probably be editable from within the dialog.

Thomas
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Community widgets for Fremantle

[gary liquid]

On Mon, Sep 28, 2009 at 1:17 PM, Cornelius Hald  wrote:

> On Mon, 2009-09-28 at 13:00 +0200, Thomas Perl wrote:
> > 2009/9/28 Cornelius Hald :
> > > On Mon, 2009-09-28 at 12:18 +0200, Thomas Perl wrote:
> > >> Yes, we can probably add whatever we want in the "Advanced" color
> > >> dialog. One thing that I would find nice (and that I have not found on
> > >> any platform yet) is that customized colors are saved per-user and not
> > >> per-application (so that when I for example have a great "green" color
> > >> that I want to use for my Uni stuff in GPE, I can have the same color
> > >> as background color of Uni-specific notes in Conboy and as background
> > >> color for Uni events in the countdown widget, etc..).
> > >
> > > Yes, I totally agree with that. We could just save custom colors to
> > > gconf. That should do the trick :)
> >
> > Here's an updated mock-up:
> >
> > http://thpinfo.com/2009/maemo/colorchooser2.png
>
> I like the pallet selection!
>
> > Some remarks:
> >
> >  * Added pure black and white as suggested by Graham
> >  * One slot is free (when the current setting is a custom color that is
> >not in the palette, the slot will be taken by that color and
> pre-selected)
>
> Do you think that one custom color is enough? How about having a
> complete column or row for custom colors? I didn't try it, but it looks
> like there could be enough room for a fourth row of colors.
>

full row should fit and in my experience people have a few most recent
selections

>
> >  * HildonPickerButton for selecting a pre-set (or application-set)
> >palette - this would change the displayed colors except the last
> >column, so we always have black, white and the "custom" color
> >
> > Anyone wants to do a mock-up for the advanced color chooser dialog?
> > Or propose "default" color palettes? (If we are going to use something
> > like the current mock-ups, we have 3x6 = 18 colors per palette and then
> > black and white and the custom color that appears in every palette...)
> >
> > Also, do we want to have the dialog relayout itself for portrait mode?
>
> I think not in the first version. ATM I know not a single application
> that allows editing in portrait mode. Also settings dialogs (where you
> often have color selection) are usually landscape only.
> If at some point this dialog should support portrait mode, we surely
> have to do something about the "Done" and "Advanced" buttons as they
> already take almost half of the screen width. Also if the pallet-mode
> supports portrait, then the advanced-mode should support it too, which
> might be even more difficult.
>

the standalone dialogs you are used to seeing are normally from desktops and
they have enough space that it doesnt matter

recall however, portrait color selection has been used in paint programs all
the way back to 8bit days - it just wasnt a popup dialog, remember deluxe
paint...

i agree we need to find a really neat way to handle those done/advanced
dialog buttons
the amount of wasted space is silly



> To make it short, I vote for landscape only :)
>


for now, sure its the only practical way we are going to advance
since we have a good idea what this may look like, how about we get down to
sorting out where its going to live.

do we attempt to make sure the api/options for a gtk/hildon/sexy lib
replacement exist, or do we aim for a maemo_community library for these
kinds of dialogs?



> Conny
>
>
> ___
> maemo-developers mailing list
> maemo-developers@maemo.org
> https://lists.maemo.org/mailman/listinfo/maemo-developers
>
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: MMS Implementation conversation

[Ville M. Vainio]

On Mon, Sep 28, 2009 at 12:58 PM, gary liquid  wrote:
> hi,
>
> this morning a conversation took place in #maemo which begun to discuss the
> specifics of implementing MMS in the n900
> I have posted the conversation onto the wiki, but it requires extensive
> weeding and cleanup and converting into an outline and spec
>
> please get involved and have a go at getting rid of the extra stuff or
> attempt to fill in any blanks or problems.
>
> http://wiki.maemo.org/Mms_implemention_conversation

There is also brainstorm item for this:

http://maemo.org/community/brainstorm/view/mms_support/

Regarding that irc conversation - there is also the "low tech"
approach of tearing down the old ppp connection and setting up a new
one. I've seen this done on Symbian devices (when I was working on an
mms implementation).

-- 
Ville M. Vainio
http://tinyurl.com/vainio
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Community widgets for Fremantle

[Cornelius Hald]

On Mon, 2009-09-28 at 13:00 +0200, Thomas Perl wrote:
> 2009/9/28 Cornelius Hald :
> > On Mon, 2009-09-28 at 12:18 +0200, Thomas Perl wrote:
> >> Yes, we can probably add whatever we want in the "Advanced" color
> >> dialog. One thing that I would find nice (and that I have not found on
> >> any platform yet) is that customized colors are saved per-user and not
> >> per-application (so that when I for example have a great "green" color
> >> that I want to use for my Uni stuff in GPE, I can have the same color
> >> as background color of Uni-specific notes in Conboy and as background
> >> color for Uni events in the countdown widget, etc..).
> >
> > Yes, I totally agree with that. We could just save custom colors to
> > gconf. That should do the trick :)
> 
> Here's an updated mock-up:
> 
> http://thpinfo.com/2009/maemo/colorchooser2.png

I like the pallet selection!

> Some remarks:
> 
>  * Added pure black and white as suggested by Graham
>  * One slot is free (when the current setting is a custom color that is
>not in the palette, the slot will be taken by that color and pre-selected)

Do you think that one custom color is enough? How about having a
complete column or row for custom colors? I didn't try it, but it looks
like there could be enough room for a fourth row of colors. 

>  * HildonPickerButton for selecting a pre-set (or application-set)
>palette - this would change the displayed colors except the last
>column, so we always have black, white and the "custom" color
> 
> Anyone wants to do a mock-up for the advanced color chooser dialog?
> Or propose "default" color palettes? (If we are going to use something
> like the current mock-ups, we have 3x6 = 18 colors per palette and then
> black and white and the custom color that appears in every palette...)
> 
> Also, do we want to have the dialog relayout itself for portrait mode?

I think not in the first version. ATM I know not a single application
that allows editing in portrait mode. Also settings dialogs (where you
often have color selection) are usually landscape only.
If at some point this dialog should support portrait mode, we surely
have to do something about the "Done" and "Advanced" buttons as they
already take almost half of the screen width. Also if the pallet-mode
supports portrait, then the advanced-mode should support it too, which
might be even more difficult.

To make it short, I vote for landscape only :)
Conny


___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: [Python] How to get a Desktop Widget to appear in "Add Widget" list

[Bruno Araujo]

On Sun, Sep 27, 2009 at 7:17 PM, Brent Chiodo  wrote:

> I am having a difficult time getting my python-based Desktop Widget to
> appear in the "Add Widget" list. If I copy my widget's main .py and
> .desktop files to the correct directories, my widget will just appear
> on the desktop after I restart Hildon Desktop. My widget works fine
> when I do this, but will never appear in that list. if I close my
> widget, there is no way to reopen it without restarting Hildon
> Desktop.
>
> I installed "example-desktop-widget" (which is written in C) from the
> repository and it behaves as you would expect. I even looked at it's
> .desktop file to see if there was something I was leaving out of mine,
> but they were identical in structure.
>
> I also followed the steps on
> http://wiki.maemo.org/PyMaemo/HildonDesktop exactly, trying to see if
> I cold get that to appear in the list, and it didn't.
>
> Any ideas? Thanks.
>
> --
> Best Regards,
>
> Brent Chiodo
> ___
> maemo-developers mailing list
> maemo-developers@maemo.org
> https://lists.maemo.org/mailman/listinfo/maemo-developers
>

Could you file a bug about this problem? We can track this issue more easily
this way.

Regards,

-- 
__
Bruno Araújo, MSc
openBossa Labs - Instituto Nokia de Tecnologia
Manaus, Brazil

"Any sufficiently advanced technology is indistinguishable from magic." -
Arthur C. Clarke
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Asking for developers and user support for a N900 application

[Andrea Grandi]

Hi all

the Credit Checker library is now hosted here:
http://code.google.com/p/creditchecker/

any help is welcome :)

-- 
Andrea Grandi
email: a.grandi [AT] gmail [DOT] com
website: http://www.andreagrandi.it
PGP Key: http://www.andreagrandi.it/pgp_key.asc
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Asking for developers and user support for a N900 application

[Andrea Grandi]

Hi,

2009/9/28 Thomas Perl :
> They can't just change the naming for the standard library, as this
> would (obviously) break old code. Most likely these libraries have been
> around longer than PEP-8 has ;) I feel a bit bad about this, too, but
> at least it has been fixed in Python 3000 (as the API break allows for
> such changes):
>
> http://docs.python.org/dev/3.0/whatsnew/3.0.html#library-changes
>
> In Python 3.x, the HTMLParser module has been renamed to html.parser:
>
> http://docs.python.org/dev/py3k/library/html.parser.html

good news then ;)
but... yes... I expect developers will take some times before starting
to use Python 3000 (what a bad name too!)

-- 
Andrea Grandi
email: a.grandi [AT] gmail [DOT] com
website: http://www.andreagrandi.it
PGP Key: http://www.andreagrandi.it/pgp_key.asc
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Asking for developers and user support for a N900 application

[Thomas Perl]

2009/9/28 Joaquim Rocha :
> Andrea Grandi wrote:
>> from HTMLParser import HTMLParser <--- package name in upper case...
>> urllib2.Request(url, data) < method name in upper case...
>>
>> first they suggest name convention and then they're the first one not
>> following them? This really sucks :)
>
>> Request is an object (a class), it is not a method :)

They can't just change the naming for the standard library, as this
would (obviously) break old code. Most likely these libraries have been
around longer than PEP-8 has ;) I feel a bit bad about this, too, but
at least it has been fixed in Python 3000 (as the API break allows for
such changes):

http://docs.python.org/dev/3.0/whatsnew/3.0.html#library-changes

In Python 3.x, the HTMLParser module has been renamed to html.parser:

http://docs.python.org/dev/py3k/library/html.parser.html

Thomas
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Asking for developers and user support for a N900 application

[Joaquim Rocha]

Hi,

Andrea Grandi wrote:

> from HTMLParser import HTMLParser <--- package name in upper case...
> urllib2.Request(url, data) < method name in upper case...
> 
> first they suggest name convention and then they're the first one not
> following them? This really sucks :)
> 


Request is an object (a class), it is not a method :)

--
Joaquim Rocha
Igalia · Free Software Engineering
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Community widgets for Fremantle

[Thomas Perl]

2009/9/28 Cornelius Hald :
> On Mon, 2009-09-28 at 12:18 +0200, Thomas Perl wrote:
>> Yes, we can probably add whatever we want in the "Advanced" color
>> dialog. One thing that I would find nice (and that I have not found on
>> any platform yet) is that customized colors are saved per-user and not
>> per-application (so that when I for example have a great "green" color
>> that I want to use for my Uni stuff in GPE, I can have the same color
>> as background color of Uni-specific notes in Conboy and as background
>> color for Uni events in the countdown widget, etc..).
>
> Yes, I totally agree with that. We could just save custom colors to
> gconf. That should do the trick :)

Here's an updated mock-up:

http://thpinfo.com/2009/maemo/colorchooser2.png

http://thpinfo.com/2009/maemo/colorchooser2.py

Some remarks:

 * Added pure black and white as suggested by Graham
 * One slot is free (when the current setting is a custom color that is
   not in the palette, the slot will be taken by that color and pre-selected)
 * HildonPickerButton for selecting a pre-set (or application-set)
   palette - this would change the displayed colors except the last
   column, so we always have black, white and the "custom" color

Anyone wants to do a mock-up for the advanced color chooser dialog?
Or propose "default" color palettes? (If we are going to use something
like the current mock-ups, we have 3x6 = 18 colors per palette and then
black and white and the custom color that appears in every palette...)

Also, do we want to have the dialog relayout itself for portrait mode?

Thomas
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Asking for developers and user support for a N900 application

[Andrea Grandi]

Hi,

2009/9/28 Thomas Perl :
> 2009/9/28 Andrea Grandi :
>> A question: is "CreditChecker" or "libcreditchecker" a good name? Any
>> other name to suggest to this library? I'd like to register this
>> project somewhere but first I'd like to be sure about the name :)
>
> I don't have a better suggestion for the name (don't put "lib" in front
> of it if possible), but some naming style remarks for the code:
>
> According to PEP-8[1], package and module names should have
> "short, all-lowercase names". so maybe you can rename the module
> "CreditChecker" to "credit_checker" while retaining the name for the
> class in it (PEP-8: "class names use the CapWords convention").
>
> Also, the function names should have a different style, as PEP-8
> says: "lowercase, with words separated by underscores".

I was trying to "fix" all the names, as you suggested, but I'm
noticing this:
neither Python classes follow this rules :(

For example:

from HTMLParser import HTMLParser <--- package name in upper case...
urllib2.Request(url, data) < method name in upper case...

first they suggest name convention and then they're the first one not
following them? This really sucks :)

-- 
Andrea Grandi
email: a.grandi [AT] gmail [DOT] com
website: http://www.andreagrandi.it
PGP Key: http://www.andreagrandi.it/pgp_key.asc
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

CONFIG_NET_SCHED

[Evgeny Linsky]

Hi,


Did anybody enable option CONFIG_NET_SCHED in diablo or freemantle kernel?

I am developing software which should manipulate with QoS stuff (like
queue). For manipulating
with these internals this option should enabled. It works on PC, but
enabling it on Diablo kernel
leads to reboot of the device during execution of "ifconfig up".

WBR, Evgeny Linsky
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Community widgets for Fremantle

[Cornelius Hald]

On Mon, 2009-09-28 at 12:18 +0200, Thomas Perl wrote:
> Yes, we can probably add whatever we want in the "Advanced" color
> dialog. One thing that I would find nice (and that I have not found on
> any platform yet) is that customized colors are saved per-user and not
> per-application (so that when I for example have a great "green" color
> that I want to use for my Uni stuff in GPE, I can have the same color
> as background color of Uni-specific notes in Conboy and as background
> color for Uni events in the countdown widget, etc..).

Yes, I totally agree with that. We could just save custom colors to
gconf. That should do the trick :)

I also noticed that it would be nice to have a proper replacement for
GtkAbout dialog - but maybe I should start another thread about this...

Cheers!
Conny


___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Community widgets for Fremantle

[Thomas Perl]

2009/9/28 Piñeiro :
> From: Thomas Perl 
>> I'd rather do without the scrolling if possible. Here's my mock-up and the
>> accompanying Python script that you can use to try it out:
>>
>> http://thpinfo.com/2009/maemo/colorchooser.png
>>
>> http://thpinfo.com/2009/maemo/colorchooser.py
>
> It looks very fine. Anyway, you can still use the "three column color
> selector" and blabla, in order to allow the user to define a custom
> extra color.
>
> I suppose that you have the same idea, as you have the button
> "Advanced". I suppose that when you press this button, a color dialog
> could appear in order to select a color in detail. Or do you have
> another idea for this button?

Yes, we can probably add whatever we want in the "Advanced" color
dialog. One thing that I would find nice (and that I have not found on
any platform yet) is that customized colors are saved per-user and not
per-application (so that when I for example have a great "green" color
that I want to use for my Uni stuff in GPE, I can have the same color
as background color of Uni-specific notes in Conboy and as background
color for Uni events in the countdown widget, etc..).

Thomas
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Asking for developers and user support for a N900 application

[Andrea Grandi]

Hi,

2009/9/28 Adrián Yanes :
> Hi Andrea, the idea looks nice. But I think that the problem it´s some
> companies use flash technology for show the credit sale in their websites.

can you show me some of these companies that only use Flash?

> I think that other option it´s program a fronted ( in python or C, with GTK
> or Qt ) that use the specif commands for GSM (like *100#) and obtain the
> credit sale with this. Probably will be more fast & cheaper (normally check
> the credit sale with this commands it's free).
>
> We only need a little db with the different codes from the countries and
> companies for obtain the credit sale.

your is a good idea, but for example my carriers doesn't support this
(Tre Italia, Simyo ecc...) as far as I know. So this would fix the
problem for Flash website but would broke carriers I use :P

So, I'm going to continue on this way, regarding this library, but of
course when I'll create the N900 application too, I'll consider any
kind of library, to be able to support as much carriers as I can.

Thanks for your help!

-- 
Andrea Grandi
email: a.grandi [AT] gmail [DOT] com
website: http://www.andreagrandi.it
PGP Key: http://www.andreagrandi.it/pgp_key.asc
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Asking for developers and user support for a N900 application

[Andrea Grandi]

Hi,

2009/9/28 Thomas Perl :
> According to PEP-8[1], package and module names should have
> "short, all-lowercase names". so maybe you can rename the module
> "CreditChecker" to "credit_checker" while retaining the name for the
> class in it (PEP-8: "class names use the CapWords convention").
>
> Also, the function names should have a different style, as PEP-8
> says: "lowercase, with words separated by underscores".
>
> Thomas
>
> [1] http://python.org/dev/peps/pep-0008/

thanks for your tips! I'll do these changes as soon as possible (tonight :P )

-- 
Andrea Grandi
email: a.grandi [AT] gmail [DOT] com
website: http://www.andreagrandi.it
PGP Key: http://www.andreagrandi.it/pgp_key.asc
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Community widgets for Fremantle

[Piñeiro]

From: Thomas Perl 

> 2009/9/26 Cornelius Hald :
> > So how about a dialog that just shows n rows with 3 to 4 colors in each
> > row. Those rows are in a panable area so it's easy to scroll them. Those
> > colors are taken from a palette and (maybe) colors that have been
> > selected in the advanced dialog are appended at the top or bottom of
> > that list. Maybe separated by some kind of separator.
>  8< ---
> > When clicking on of those color buttons a dialog like this opens:
> > http://zwong.de/wp-content/uploads/2009/09/color_chooser_mock.png
> > Probably the buttons/colors should be bigger or there should be 4 in a
> > row. As I said, just a very quick mockup. Those buttons are pannable, so
> > there are more colors available.
> 
> I'd rather do without the scrolling if possible. Here's my mock-up and the
> accompanying Python script that you can use to try it out:
> 
> http://thpinfo.com/2009/maemo/colorchooser.png
> 
> http://thpinfo.com/2009/maemo/colorchooser.py

It looks very fine. Anyway, you can still use the "three column color
selector" and blabla, in order to allow the user to define a custom
extra color.

I suppose that you have the same idea, as you have the button
"Advanced". I suppose that when you press this button, a color dialog
could appear in order to select a color in detail. Or do you have
another idea for this button?

===
API (apinhe...@igalia.com)
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

MMS Implementation conversation

[gary liquid]

hi,

this morning a conversation took place in #maemo which begun to discuss the
specifics of implementing MMS in the n900
I have posted the conversation onto the wiki, but it requires extensive
weeding and cleanup and converting into an outline and spec

please get involved and have a go at getting rid of the extra stuff or
attempt to fill in any blanks or problems.

http://wiki.maemo.org/Mms_implemention_conversation

users ab and astorm were the key guys in this discussion and it would be
really good to follow up on this :)

gary
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Asking for developers and user support for a N900 application

[Adrián Yanes]

Hi Andrea, the idea looks nice. But I think that the problem it´s some
companies use flash technology for show the credit sale in their websites.

I think that other option it´s program a fronted ( in python or C, with GTK
or Qt ) that use the specif commands for GSM (like *100#) and obtain the
credit sale with this. Probably will be more fast & cheaper (normally check
the credit sale with this commands it's free).

We only need a little db with the different codes from the countries and
companies for obtain the credit sale.

What do you think ?

Regards, Adrian.

2009/9/28 Andrea Grandi 

> Hi all!
>
> Sorry for this long delay, I didn't abandon the idea, I was just very busy
> :)
> I've started working to the library and at the moment I've a very
> preliminary version of it, supporting only Simyo (Spain).
>
> You can find the code (brutally copy-pasted) here:
>
> CreditChecker.py: http://pastebin.com/m71ad1fa4
> SimyoES.py :
> http://pastebin.com/m61e05f5
>
> CreditChecker is the base class, with some methods that should be
> common to all classes and SimyoES is the derived class. My idea is
> that all carriers should be (possibly) implemented deriving from the
> base class and following more or less the same structure.
>
> Support for catching/managing exceptions is still missing.
>
> A question: is "CreditChecker" or "libcreditchecker" a good name? Any
> other name to suggest to this library? I'd like to register this
> project somewhere but first I'd like to be sure about the name :)
>
> Thanks again for your help!
>
> --
> Andrea Grandi
> email: a.grandi [AT] gmail [DOT] com
> website: http://www.andreagrandi.it
> PGP Key: http://www.andreagrandi.it/pgp_key.asc
> ___
> maemo-developers mailing list
> maemo-developers@maemo.org
> https://lists.maemo.org/mailman/listinfo/maemo-developers
>
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Asking for developers and user support for a N900 application

[Thomas Perl]

2009/9/28 Andrea Grandi :
> A question: is "CreditChecker" or "libcreditchecker" a good name? Any
> other name to suggest to this library? I'd like to register this
> project somewhere but first I'd like to be sure about the name :)

I don't have a better suggestion for the name (don't put "lib" in front
of it if possible), but some naming style remarks for the code:

According to PEP-8[1], package and module names should have
"short, all-lowercase names". so maybe you can rename the module
"CreditChecker" to "credit_checker" while retaining the name for the
class in it (PEP-8: "class names use the CapWords convention").

Also, the function names should have a different style, as PEP-8
says: "lowercase, with words separated by underscores".

Thomas

[1] http://python.org/dev/peps/pep-0008/
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: Asking for developers and user support for a N900 application

[Andrea Grandi]

Hi all!

Sorry for this long delay, I didn't abandon the idea, I was just very busy :)
I've started working to the library and at the moment I've a very
preliminary version of it, supporting only Simyo (Spain).

You can find the code (brutally copy-pasted) here:

CreditChecker.py: http://pastebin.com/m71ad1fa4
SimyoES.py: http://pastebin.com/m61e05f5

CreditChecker is the base class, with some methods that should be
common to all classes and SimyoES is the derived class. My idea is
that all carriers should be (possibly) implemented deriving from the
base class and following more or less the same structure.

Support for catching/managing exceptions is still missing.

A question: is "CreditChecker" or "libcreditchecker" a good name? Any
other name to suggest to this library? I'd like to register this
project somewhere but first I'd like to be sure about the name :)

Thanks again for your help!

-- 
Andrea Grandi
email: a.grandi [AT] gmail [DOT] com
website: http://www.andreagrandi.it
PGP Key: http://www.andreagrandi.it/pgp_key.asc
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Re: What's the best attack? (Re: How to use extras-testing correctly?)`

[gary liquid]

On Fri, Sep 25, 2009 at 5:29 PM,  wrote:

>  - Original message -
> > the apps in maemo extras *should* be trusted because we, the community,
> trust
> > the developers who put them there.
>
> Gary, I trust the community, but I really want to be sure.
>
> It is also because I like the community so much that I want to keep extras
> a safe place. For some new users it will be the first point of contact to
> OSS. If that contact is good, more people will find the community and more
> will join.
>

nobody can anonymously upload to extras without first applying.
from a community perspective, there is already a feeling of being vetted
prior to getting upload rights.

>
> > it would take 1 bad report to have the software removed from extras.
> >
> > its a worrying scenario for some people,  but this isnt the wild west and
> like
> > all trust based mechanisms, people in the community are given rights to
> upload
> > hopefully based on their standing.
>
> That would be one form of security I would be ok with.
> But screening people (karma or participation or whatever) for the right to
> upload is even more questionable than having a team of testers go through
> the apps. Everyone has to have the right to right to put their stuff to
> devel and testing.
>

as said, there is already an application stage.
if the community mindset is there of vetting, no matter how vague, it helps.


>
> > There are many steps along the way to being involved in the community and
> i do
> > not see why an individual would be nefarious enough to go through all
> those just
> > to infect a few machines.
> >
> > people are given rights and responsibilities and mechanisms are in place
> to
> > hopefully prevent an incident such as you are describing.
>
> Pretty much so. But I don't want to risk even a single case however
> unlikely it is.
>

*nod* this is a common goal.

>
> > it falls on each and every one of us to maintain that trust.
>
> It is about trust, but there is the question of security too.
>
> I hope the solution that is now implemented is one that works, but as
> always, if practise shows that it needs to be rethought, then we will.
>

yes, testing is the further step and should help to prevent even the most
determined of individuals.
it is rare to see applications coming through maemo.org where there isn't
community participation at some level

gary

>
> Tero
>
> Tero
>
> > gary
> >
> >
> >
> >
> > On Fri, Sep 25, 2009 at 3:40 PM, David Greaves
> >  wrote:
> >
> > tero.k...@nokia.com wrote:
> > > - Original message -
> > > >
> >
> > > > I realise this is a slightly different question (hence the new
> subject)
> > > >
> > > > OK, say I have an evil twin who wants to attack ('own') a lot of
> Nokia
> > > N900
> > > > devices. How do I do this?
> > >
> > > I hope that was retorical. Tell your evil twin to do something usefull.
>
> >
> >
> > Err, no it wasn't retorical; it was hypothetical though in case you were
> worried.
> >
> > It's more about being responsible :)
> > Actually it is very late in the day to be asking... but hey, it sounds
> like a
> > topic worth raising.
> >
> > > > Does extras-testing factor into this?
> > >
> > > At least so that I would prefer maemo.org extras to be clean from
> > > malware. It is much easier to promote it in Nokia internally when
> extras
> > > contains good software.
> >
> >
> > I agree 100% ... all it takes is one example of malware introduced into
> an OSS
> > product and we (and Nokia) could lose a lot of credibility.
> >
> > I wonder how much that could be worth to some people? Maybe worth a
> deliberate
> > attack? Maybe someone is playing a longer game?
> >
> > I just hope we are not planning on taking the "cross your fingers and
> toes
> > *REALLY HARD* and hope everyone is nice to us" approach to security ;)
> >
> > Discuss...
> >
> > David
> >
> >
> > --
> > "Don't worry, you'll be fine; I saw it work in a cartoon once..."
> >
> >
> >
> > ___
> > maemo-developers mailing list
> > maemo-developers@maemo.org
> > https://lists.maemo.org/mailman/listinfo/maemo-developers
> >
> >
> >
> >
> >
> >
>
>
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers