Author Topic: Gpe Pim Apps (Read 207412 times)

Xromer · « **Reply #60 on:** April 07, 2006, 04:43:28 am »

Isn't glib a separate package? Surely you could just have this as a separate dependency; use 2.8.6 (minimum requirement) rather than anything newer and maybe it won't break anything...?

For general use, I thought that the current/old version of gpe-calendar etc worked fine with the fixes you already made and the minor change to the at command. I was kind of hoping you could upload an ipk with this last minor fix so we had a working implementation.

Does the newer CVS stuff have a different 'at' interface, or does the same problem exist?

(If you're busy with something more important, don't waste time answering my questions )

Karl
[div align=\"right\"][a href=\"index.php?act=findpost&pid=122101\"][{POST_SNAPBACK}][/a][/div]
[/quote]

Right, do not worry karlto, when i see your and other posts i' m never wasting my time :-)
As you know i' m a beginner here.
Answer 1)
Glib is integrated in the ROM, infact, if you note, it' s installed without any link.
So i don' t know how to make GPSDRIVE search the GLIB files in other DIR than the one LDconfig by the system. Any suggestions?
Answer 2)

In GPE-Calendar many changes were made, so now it' s time to see how it will behave.
In GPE-Announce only the gstreamer implementation was inroduced but now i don' t know how Gstreamer functions. We will see.
Until now these are the packages i made:
ADDONS:
sqlite-sdk-addon-2.8.17-1.i386.rpm
pdaxrom-sdk-1.0-1.i386.rpm
libtododb-sdk-addon-cvs.060406-1.i386.rpm
libsoundgen-sdk-addon-cvs.060406-1.i386.rpm
libmimedir-sdk-addon-0.3.1-1.i386.rpm
libgpewidget-sdk-addon-cvs.060406-1.i386.rpm
libgpevtype-sdk-addon-cvs.060406-1.i386.rpm
libgpevtype-sdk-addon-0.16-1.i386.rpm
libgpepimc-sdk-addon-cvs.060406-1.i386.rpm
libeventdb-sdk-addon-cvs.060406-1.i386.rpm
libcontactsdb-sdk-addon-cvs.060406-1.i386.rpm

IPKS:
libtododb_cvs.060406_armv5tel.ipk
libsoundgen_cvs.060406_armv5tel.ipk
libgpewidget_cvs.060406_armv5tel.ipk
libgpevtype_cvs.060406_armv5tel.ipk
libgpepimc_cvs.060406_armv5tel.ipk
libeventdb_cvs.060406_armv5tel.ipk
libcontactsdb_cvs.060406_armv5tel.ipk
gstreamer_0.10.4_armv5tel.ipk

This evening i will finish with:
gpe-announce
gpe-calendar
gpe-contacts
gpe-todo
libschedule

After trying them i will put all in my contrib section.
I' ll hope in the calendar changes to fix something, but i saw libschedule it' s nearly the same.
But first changing it i have to see what enhancemets were made to calendar.
We will see.
BYEZ!

Antikx · « **Reply #61 on:** April 07, 2006, 12:12:19 pm »

Go Xromer!

karlto · « **Reply #62 on:** April 07, 2006, 06:11:03 pm »

Quote

As you know i' m a beginner here.

Based on how much work you've gotten done, I'd say you're well past that now!

Quote

Answer 1)
Glib is integrated in the ROM, infact, if you note, it' s installed without any link.
So i don' t know how to make GPSDRIVE search the GLIB files in other DIR than the one LDconfig by the system. Any suggestions?

I didn't think glib was integrated with the rom, it's just distributed with it as a default/base package (not much works without it); I could be wrong of course.
Not sure what you mean by 'without any link'. This is probably a bit out of my league, because I've never had any problems with stuff like this. Looking the files owned by package glib:

Code: [Select]

/usr/lib/libglib-1.2.so.0.0.10
/usr/lib/libglib.so (*)
/usr/lib/libgmodule.so (*)
/usr/lib/libgthread.so (*)
/usr/lib/libgmodule-1.2.so.0.0.10
/usr/lib/libgthread-1.2.so.0.0.10
/usr/lib/libglib-1.2.so.0 (*)
/usr/lib/libgmodule-1.2.so.0 (*)
/usr/lib/libgthread-1.2.so.0 (*)

there are only three real files; the others (*) are symlinks to them. I guess this is bad practice, but I would have thought that a package simply replacing the 'libglib*' library and symlinks with a minor version upgrade might not cause any major issues.
The other thing I recall seeing somewhere on these forums was another app requiring newer glib (or glibc?) that someone else had working (maybe OpenOffice?) - perhaps that person can shed light on how to use multiple versions at once - please speak up!

You've made heaps of progress - I noticed the other day that there is an applet in the gpe stuff that controls the volume for the alarms too (you had issues with the rising volume vs. fixed being too loud or something); maybe fiddling with the settings in this app will yield something that works better for pdaXrom.

Xromer · « **Reply #63 on:** April 08, 2006, 02:58:41 pm »

OK guys, i did it.
Compiled and packaged all GPE-CVS-PIMS, tried and sent them to PGAS to put them on my contrib.
Please see the FIRST post of this thread for all the informations, as i use it as a news behaviour.
For Antikx:
Thanks for yours aprreciations!

For kalto:
Thanks for yours appreciations too!
Now, i know that all the libraries have simlink in that form, but what i wanted to say is that
/usr/lib/libgmodule-1.2.so.0.0.10 it' s inside the ROM and it' s not a simlink to the User Memory as /home/users/usr dir nor to some external interface.
So any changes there could effect or corrupt the ROM installation, as it happened to me in the past.
It' s the case of any ipks integrated in the ROM, thing that is, as you know, the base for everyone.
We have to find another way. :-)
But let us concentrate better on the GPE-PIMS now.
I would like you all to test now the new pakcages and let me know something.
For this i send you all back to the FIRST post.
Cheers! :-)

wowo123 · « **Reply #64 on:** April 09, 2006, 04:34:31 am »

What happened to libmimedir_0.3.1? It's not on Xromer's partition on .../contrib. Where can I get it?

Xromer · « **Reply #65 on:** April 09, 2006, 07:21:48 am »

Quote

What happened to libmimedir_0.3.1? It's not on Xromer's partition on .../contrib. Where can I get it?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=122373\"][{POST_SNAPBACK}][/a][/div]

I' ve just reuploaded.
Sorry!
BYEZ!

karlto · « **Reply #66 on:** April 09, 2006, 06:46:40 pm »

Hi Xromer

Thanks for the update, but now this at thing is going to drive me crazy! gpe-calendar won't even run now because I tried to set an event with an alarm and it fails to start...

Anyway, I found the source to the pdaXrom at - here it is:

Code: [Select]

#!/bin/sh

FN=""
if [ "-f" = "$1" ]; then
  shift
  FN=$1
  shift
fi

if [ -z "$1" ]; then echo "No date specified"; exit 1; fi
if WHEN=`date -d "$1" +%s`; then
  AT=/var/spool/at/$WHEN.$$
  echo '#!/bin/sh' >$AT.new
  # reproduce the 'at' execution environment here?
  /bin/cat $FN >>$AT.new
  echo 'rm -f $0' >>$AT.new
  /bin/chmod 755 $AT.new
  /bin/mv $AT.new $AT
  echo >/var/spool/at/trigger
else
  exit $?
fi

(That's all of it!) atd is a compiled program, with a fix for the Zaurus RTC. But the at command is just a quick shell script as above to create the spool files. It doesn't accept any other options or give any output!

I am toying with the idea of improving this script so that it accepts other switches and gives some usable output. From your earlier posts I see the following extras required:

* at -q switch: I think we can just ignore this, as there is no need for queues or priority
* at -c switch: with a little work, I'm sure that the script can output some useful info. On page 3 you showed a snippet of code that gives a hint as to what output is expected...
* atrm command - this could be a little more difficult as somehow we need to maintain a job ID. I think perhaps this could be the last part of the spool filename

Is there anything else it would need to do? If I can get this working, no more gpe compilation will be needed to make it work.

The first two items above could be fixed by simply ignoring them in libschedule/gpe-calendar code, but it is probably important to implement atrm, as otherwise deleted alarms will still go off!

I have also wondered about compiling a full atd for pdaXrom, but haven't found any source yet, and I think it would be a bit of a nightmare...

What are you thoughts? Can you provide any more details of what gpe-calendar/libschedule expects as output from at and any other command line switches?

Karl

Xromer · « **Reply #67 on:** April 09, 2006, 08:40:34 pm »

Ok i began to look at the new atd.c, it' s fun to see that the only changement it' s a change that i did one month ago too to try the direct call of at.
Now the problem it 's not the libschedule, but Event Number Generation by the GPE-Calendar.
The AT libschedule number incrementation it' s something that i can bypass easily generating it with an AUTOINCREMENT Value from Sqlite.
The problem it' s the Event identification to make it delete directly by libschedule without the need of atrm.
I did a script to simulate the atrm too, but it deleted the wrong event.
I have to study the GPE-Calendar deeper.
Now i was trying to compile gpe-soundbite but it compiling tells me this:

gsm-codec.o: In function `sound_encode':
gsm-codec.c:(.text+0x54): undefined reference to `gsm_create'
gsm-codec.c:(.text+0xc4): undefined reference to `gsm_encode'
gsm-codec.c:(.text+0xe8): undefined reference to `gsm_destroy'
gsm-codec.c:(.text+0x10c): undefined reference to `gsm_destroy'
gsm-codec.o: In function `sound_decode':
gsm-codec.c:(.text+0x130): undefined reference to `gsm_create'
gsm-codec.c:(.text+0x164): undefined reference to `gsm_destroy'
gsm-codec.c:(.text+0x19c): undefined reference to `gsm_decode'
gsm-codec.c:(.text+0x1e8): undefined reference to `gsm_destroy'
gsm-codec.c:(.text+0x204): undefined reference to `gsm_destroy'
collect2: ld returned 1 exit status

The strange thing is that i have gsm/gsm.h in the right dir and the same libsgm.so.1, but it seems to be not found by soundbite.
That's the soundbite Makefile:

PACKAGE_CPPFLAGS += $(STANDARD_CPPFLAGS) -DENABLE_NLS
PACKAGE_CPPFLAGS += -DPACKAGE=\"$(PACKAGE)\" -DPREFIX=\"$(PREFIX)\" -DPACKAGE_LOCALE_DIR=\"$(PREFIX)/share/locale\"
PACKAGE_CFLAGS += $(STANDARD_CFLAGS) $(GPECFLAGS) `pkg-config --cflags libglade-2.0` -I/opt/cross/arm/3.4.5-xscale-softvfp/armv5tel-cacko-linux/include/gsm
PACKAGE_LDFLAGS += $(STANDARD_LDFLAGS) $(GPELIBS) -L/opt/cross/arm/3.4.5-xscale-softvfp/armv5tel-cacko-linux/lib/libgsm.so.1 `pkg-config --libs libglade-2.0`

The red line it' s my last attempt to point the libgsm.so.1 directly without effects.
I don't know what' s going on.
:-(

karlto · « **Reply #68 on:** April 10, 2006, 12:18:47 am »

Quote

Ok i began to look at the new atd.c, it' s fun to see that the only changement it' s a change that i did one month ago too to try the direct call of at.
Now the problem it 's not the libschedule, but Event Number Generation by the GPE-Calendar.
The AT libschedule number incrementation it' s something that i can bypass easily generating it with an AUTOINCREMENT Value from Sqlite.
The problem it' s the Event identification to make it delete directly by libschedule without the need of atrm.
I did a script to simulate the atrm too, but it deleted the wrong event.
I have to study the GPE-Calendar deeper.

Don't worry about at! I am on the trail of a solution!

As you state, the event ID is a problem, but that is the fault of at, not gpe-calendar (see previous post regarding dumbed-down at).

I have almost complete a more useful at script that allows use of the following flags:
-q (ignored)
-c #id
-d #id (same as 'atrm #id')
-f filename

...and it sorts out the dodgy date format passed by gpe-calendar/libschedule.

I have everything 99% working with your updated packages and these minor script changes - just need to finish fixing that date format and I will upload. This gives working alarms!

Quote

Now i was trying to compile gpe-soundbite but it compiling tells me this:

What exactly does the header file reference look like in gsm-codec.c? No silly #ifdef removing it? I presume the header file itself is up to scratch?

Karl

karlto · « **Reply #69 on:** April 10, 2006, 01:05:08 am »

Hi all

OK, here's a quick and dirty fix to make gpe-calendar alarms work correctly. Basically it just adds some extra functionality that normal versions of at provide. (You'll need pdaXrom atd installed first of course).

The attached text file is a shell script; replace the script /usr/bin/at with this one (back up the old one if you might want it). Also create a script /usr/bin/atrm:

Code: [Select]

#!/bin/sh
# Call 'atd -d'
/usr/bin/at -d $@

(An alias doesn't work because the gpe apps call it directly). Don't forget to chmod 755 both scripts.

This seems to work for me quite happily, but it's not perfect (but then, neither was the original at script). The functionality this adds is as per my previous post - there is also a kludge to deal with the gpe date format (DD.MM.YY, which just isn't recognised).

@Xromer: hopefully this means you don't have to alter the atd code; it can stay the same as other distributions. I did have a slight issue with gpe-announce when postponing alarms - it created a new at command, but gpe-announce appeared to freeze. Not sure what's going on here.

Hope this helps!

Karl

P.S. alarms are LOUD - not sure why the volume control settings aren't working...

Xromer · « **Reply #70 on:** April 10, 2006, 03:00:15 am »

Quote

Hi all

OK, here's a quick and dirty fix to make gpe-calendar alarms work correctly. Basically it just adds some extra functionality that normal versions of at provide. (You'll need pdaXrom atd installed first of course).

The attached text file is a shell script; replace the script /usr/bin/at with this one (back up the old one if you might want it). Also create a script /usr/bin/atrm:

Code: [Select]
#!/bin/sh # Call 'atd -d' /usr/bin/at -d $@(An alias doesn't work because the gpe apps call it directly). Don't forget to chmod 755 both scripts.

This seems to work for me quite happily, but it's not perfect (but then, neither was the original at script). The functionality this adds is as per my previous post - there is also a kludge to deal with the gpe date format (DD.MM.YY, which just isn't recognised).

@Xromer: hopefully this means you don't have to alter the atd code; it can stay the same as other distributions. I did have a slight issue with gpe-announce when postponing alarms - it created a new at command, but gpe-announce appeared to freeze. Not sure what's going on here.

Hope this helps!

Karl

P.S. alarms are LOUD - not sure why the volume control settings aren't working...
[div align=\"right\"][a href=\"index.php?act=findpost&pid=122458\"][{POST_SNAPBACK}][/a][/div]

OK THX, but as i' m learning GTK APIS i have to practice :-) So sure i will make some changes, after packaged the FC4 RPMS version, that probably should work without problems.
For the loudness, i' ve not yet fixed the gpe-announce AUTO RAISE, before doing it, try the Volume you think it' s the best compromise for LOUDNESS.
Think that you may have to wake up with it.
After that you can tell in percentuality what do you think the best. (i.e. from 0-100%)
BYez!

Antikx · « **Reply #71 on:** April 10, 2006, 12:53:39 pm »

Quote

P.S. alarms are LOUD - not sure why the volume control settings aren't working...
[div align=\"right\"][a href=\"index.php?act=findpost&pid=122458\"][{POST_SNAPBACK}][/a][/div]

is there a way to have something (at, or whatever) run mixmos with "-r 1" so that it changes to a preset that has the volume lowered? Just an idea.
Thanks for your work on AT karlto. I'm got switch to the gpe apps for a while because they are quicker and work better with xdeep32.

karlto · « **Reply #72 on:** April 10, 2006, 04:33:08 pm »

Quote

Quote
P.S. alarms are LOUD - not sure why the volume control settings aren't working...
[div align=\"right\"][a href=\"index.php?act=findpost&pid=122458\"][{POST_SNAPBACK}][/a][/div]
is there a way to have something (at, or whatever) run mixmos with "-r 1" so that it changes to a preset that has the volume lowered? Just an idea.
Thanks for your work on AT karlto. I'm got switch to the gpe apps for a while because they are quicker and work better with xdeep32.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=122534\"][{POST_SNAPBACK}][/a][/div]

They are heaps quicker in any situation, and the bonus with this alarm setup is that the calendar doesn't have to be running. Unfortunately, the gpe apps have the at job hard coded, so we can't really change that. The ~/.gpe/alarm.conf settings should work, and the 'gpe-conf sound' applet successfully changes them, it's just that they're ignored!

BTW, the script above still has a couple of lines with debugging info (notice a '~/atcommands.txt'? sorry...) - a better one with more comments is attached.

@Xromer - there are two main issues with the alarms now:
1) sound level. Something in the code is ignoring the settings (~/.gpe/alarm.conf) or failing to implement them. Are you still having problems with the esd implementation? (disabling auto-raise and setting the volume doesn't work - still full volume)
2) dismissing/suspending alarms doesn't seem to always work first time.
**Edit **
What is the line 'gpe-calendar -s <time in seconds> -e 5 &' in the at schedule supposed to do? This seems to re-schedule the alarm, even though it will be dismissed!
/edit

There is no need to change the at scheduler functions within the gpe apps, because it was the pdaXrom 'at' at fault - you can't fix it because the functionality required isn't available in the default installation (by default, job ids do not exist, nor does any way to review the jobs or delete them).

I will continue to test on the above issues to provide you with more information.

Karl

Xromer · « **Reply #73 on:** April 11, 2006, 08:29:40 am »

Ok i ported other stuff:
gsm_1.0.11_armv5tel.ipk
gpe-timesheet_cvs.060406_armv5tel.ipk
gpe-soundbite_cvs.060406_armv5tel.ipk
gpe-sketchbook_cvs.060406_armv5tel.ipk
gpe-shield_cvs.060406_arm.ipk
gpe-ownerinfo_cvs.060406_armv5tel.ipk
gpe-irc_cvs.060406_armv5tel.ipk
gpe-gallery_cvs.060406_armv5tel.ipk

GSM problem worked out, i used wrong /usr/bin/ld instead of the ARM one to generate the libgsm.so.1 lib.
Cross compiling is a very big issue, you can make a lot of mistakes with the ENV variables. WOW!
So gpe-soundbite is now ported. See the first post.
For the Calendar, there' s nothing to do to manage it with external scripts :-(
The atd.c file in libschedule it' s built to manage the output of the at command with the libpopt library.
It execute the at -f -g cmd and wait it to output the UID of the event, storing it in the sqlite env.
Without the at cmd output you have to generate the UID manually.
So you have to be a little more patient guys.
After i finish to make some tries (with the changes i made), i will put the new ipks online for you to try them with me.
For the GPE-Announce i didn' t have time to try deep the new IPK, after looking at the new code, i will fix it as the old one.
The Snooze function is always related to the libschedule issue, but this time the programmers added the SYSTEM call function at the end of atd.c that makes Announce trig directly AT.
This is the reason why Announce doesn' t freeze as Calendar.
Because Announce doesn' t wait for the AT output.
An that' s the way i will follow.
CHEERS!

karlto · « **Reply #74 on:** April 11, 2006, 04:17:00 pm »

Hi Xromer

You're certainly ploughing through it!

Quote

For the Calendar, there' s nothing to do to manage it with external scripts :-(
The atd.c file in libschedule it' s built to manage the output of the at command with the libpopt library.
It execute the at -f -g cmd and wait it to output the UID of the event, storing it in the sqlite env.
Without the at cmd output you have to generate the UID manually.
So you have to be a little more patient guys.
After i finish to make some tries (with the changes i made), i will put the new ipks online for you to try them with me.
For the GPE-Announce i didn' t have time to try deep the new IPK, after looking at the new code, i will fix it as the old one.
The Snooze function is always related to the libschedule issue, but this time the programmers added the SYSTEM call function at the end of atd.c that makes Announce trig directly AT.
This is the reason why Announce doesn' t freeze as Calendar.
Because Announce doesn' t wait for the AT output.
An that' s the way i will follow.
CHEERS!
[div align=\"right\"][a href=\"index.php?act=findpost&pid=122633\"][{POST_SNAPBACK}][/a][/div]

I'm not completely clear on everything above, but here is a scheduled job (working):

Code: [Select]

#!/bin/sh
#!/bin/sh
export DISPLAY=:0
gpe-announce ''
gpe-calendar -s 1144921500 -e 5 &
#!# 5 1144921500
rm -f $0

The at script adds the first shebang and the last line (to remove the script once executed).

I don't think the extra shebang causes any problems. As you can see, gpe-announce doesn't get any information other than a message to display; is announce supposed to call at? If so, I don't see how it would because it has no information (e.g. job id) to use for this.

The gpe-calendar line seems to work; it doesn't actually launch the calendar on screen, it just does something then quits. The long number is the time of the alarm, so my best guess is that it's supposed to register that the alarm has occurred. What it seems to do is re-schedule the event for the same time!

As for the next line, I can't see that it does anything - it looks like a comment (bash accepts it, but doesn't seem to do anything), possibly created by a malformed command. It's interesting that both this and the previous line have the same number (5) in them.

OK, here are the questions:
1) Should gpe-announce be passed more information, such as the at job id, or the time? Or does it call gpe-calendar (or look at the database) to get the info it needs?
2) Does gpe-announce call at directly? What command line?
3) What exactly should the gpe-calendar line do? What are the extra parameters?
4) Is the last line correct? Should it be doing something? What?

I think if we can answer the above, that will fix the two remaining issues with at implementation:
- some alarms immediately re-scheduled when they go off, regardless of being dismissed
- suspending alarms not reliable

By the way, I am not concerned with fixing at via the script, as it brings the functionality more into line with all the other (standard) versions out there, and make it more useful for other tasks as well as gpe integration. I guess it would be quite trivial to repackage the atd ipk with the updated script too.

What else can I do to help test this and provide feedback?

Karl

News:

Author Topic: Gpe Pim Apps (Read 207412 times)