Re: [Wengophone-devel] Linux startup issues

2007-04-02 Thread Vadim Lebedev 

Hi Primin,

Pirmin Walthert wrote:
.


Hi Jerome


QtWengoPhone.cpp then calls readyForEvents() that is passed back through
control to model. In userProfileHandler I then have the following:

void UserProfileHandler::readyForEvents()
{
if (_readyForEvents==false)
{
IMWrapperFactory::getFactory().startGaimFactory();
}
_readyForEvents=true;
_currentUserProfile->readyForEvents();
LOG_DEBUG("Connecting enabled!");
}

 


I think following will be a little bit safer:

void UserProfileHandler::readyForEvents()
{
if (_readyForEvents==false)
{
_readyForEvents=true;
_currentUserProfile->readyForEvents();
IMWrapperFactory::getFactory().startGaimFactory();
LOG_DEBUG("Connecting enabled!");
}
}



Thanks
Vadim

 


___
Wengophone-devel mailing list
Wengophone-devel@lists.openwengo.com
http://dev.openwengo.com/mailman/listinfo/wengophone-devel

[Wengophone-devel] Re: Linux startup issues

2007-04-02 Thread Jerome WAGNER 

Hello Pirmin,
Thank you for your research on that point. We'll have a close look at 
your solution it in the next days.

Jerome

Pirmin Walthert wrote:

Hi Jerome

I've seen your post about Wengophone2.1-status.

As you may know I've written a few times about startup-troubles on
linux. I now also sent some startup-crash-dumps (with the
crash-report... if this is working?!?) with 2.1 on windows. I don't know
exactly if the problem is the same as I've fixed now in the 2.0 version
I'm working on!

=> I had some success before in adding a sleep into the Gaim-thread
before it was starting the g_main_loop. This worked in most cases but
when startup was even slower (because of networking troubles) this
didn't help! What I've now done is the following (and now it really
workes always!):

I'm not calling GaimMainEventLoop(gpointer data) anymore in
GaimIMInit(). Instead I've added a new function to GaimIMFactory:

bool GaimIMFactory::startGaimFactory() {
g_thread_create(GaimMainEventLoop, NULL, FALSE, NULL);
return true;
}

(and I also had to put a sleep(1) into GaimMainEventLoop to be shure
that really everything is ready)

=> I'm now starting this AFTER the userlist was initialised (in the
callback to QtWengoPhone that adds the UList to the Tab). Because the
problems I had seemed to have to do with the gui: IMAccounts were logged
in before the GUI was ready to handle the events. (This is an
assumption...).

QtWengoPhone.cpp then calls readyForEvents() that is passed back through
control to model. In userProfileHandler I then have the following:

void UserProfileHandler::readyForEvents()
{
if (_readyForEvents==false)
{
IMWrapperFactory::getFactory().startGaimFactory();
}
_readyForEvents=true;
_currentUserProfile->readyForEvents();
LOG_DEBUG("Connecting enabled!");
}

What also enables the ConnectionManger to connect => it is in a loop
before in the functions that could create connections:

while (_userProfile.getReadyForEvents()==false)
{
Thread::sleep(1);
}

I know, this is not the clean solution you are searching for! I only
wanted to show you how I solved all the startup-isssues I had. And
because I was limited in time and will have to pass a functioning
version over to someone other next week I had to work with such unclean
fixes.

And this REALLY works for me. Yesterday I've tested this about 50 times
without any crashes. Even the log-off/log-in now works as expected what
also didn't work always before!

While I don't think that you want to solve it this way I wanted to write
about my experiences here, perhaps my solution gives you an idea for a
cleaner one!

Cheers, Pirmin

  


___
Wengophone-devel mailing list
Wengophone-devel@lists.openwengo.com
http://dev.openwengo.com/mailman/listinfo/wengophone-devel

Re: [Wengophone-devel] Patch for lupdate macro on Linux

2007-04-02 Thread Claudio André 

Me too.

But mine lang.pro file (qmake -project -o lang.pro) gives me almost 900 
strings, removing only 8 obsolete strings.


Probably, i have some trash on my 2.1 branch folder.

Claudio

Dave Neary escreveu:

Hi Laudio,

Claudio André wrote:
  

I noticed your ts files have 868 strings. Mine have 898. Any
possibilities your .pro file is outdated?



On the contrary - I ran lupdate with -noobsolete, which removes the
strings by a good bit. There are also one or two small test GUI programs
whose strings are no longer in the .ts file.

Cheers,
Dave.

  


___
Wengophone-devel mailing list
Wengophone-devel@lists.openwengo.com
http://dev.openwengo.com/mailman/listinfo/wengophone-devel

Re: [Wengophone-devel] wengophone 2.1 - status

2007-04-02 Thread Gianluca Sforna 

On 4/2/07, Jerome WAGNER <[EMAIL PROTECTED]> wrote:

One of the first thing that is going to be done is to upgrade to the
last stable version of libgaim because it seems that this library has
improved a lot lately and that many of our issues on GNU/Linux will
disappear with the upgrade.



Just for the records, does the build system support using the system one?
___
Wengophone-devel mailing list
Wengophone-devel@lists.openwengo.com
http://dev.openwengo.com/mailman/listinfo/wengophone-devel

Re: [Wengophone-devel] Patch for lupdate macro on Linux

2007-04-02 Thread Dave Neary 

Hi Laudio,

Claudio André wrote:
> I noticed your ts files have 868 strings. Mine have 898. Any
> possibilities your .pro file is outdated?

On the contrary - I ran lupdate with -noobsolete, which removes the
strings by a good bit. There are also one or two small test GUI programs
whose strings are no longer in the .ts file.

Cheers,
Dave.

-- 
Dave Neary
OpenWengo Community Development Manager
Email: [EMAIL PROTECTED]
___
Wengophone-devel mailing list
Wengophone-devel@lists.openwengo.com
http://dev.openwengo.com/mailman/listinfo/wengophone-devel

Re: [Wengophone-devel] Patch for lupdate macro on Linux

2007-04-02 Thread Claudio André 

Hi,

I noticed your ts files have 868 strings. Mine have 898. Any 
possibilities your .pro file is outdated?


Claudio

Dave Neary escreveu:

Hi,

After applying this patch, I have updated the .ts files - here's a diff
against Subversion once we run lupdate -noobsolete on the .pro file
generated by cmake.

Could anyone involved in translation have a glance at this, and make
sure that it's OK, before it gets committed, please? I don't want us to
miss some strings in an update.

Cheers,
Dave.

  



___
Wengophone-devel mailing list
Wengophone-devel@lists.openwengo.com
http://dev.openwengo.com/mailman/listinfo/wengophone-devel


___
Wengophone-devel mailing list
Wengophone-devel@lists.openwengo.com
http://dev.openwengo.com/mailman/listinfo/wengophone-devel

Re: [Wengophone-devel] Patch for lupdate macro on Linux

2007-04-02 Thread Dave Neary 

Hi,

After applying this patch, I have updated the .ts files - here's a diff
against Subversion once we run lupdate -noobsolete on the .pro file
generated by cmake.

Could anyone involved in translation have a glance at this, and make
sure that it's OK, before it gets committed, please? I don't want us to
miss some strings in an update.

Cheers,
Dave.

-- 
Dave Neary
OpenWengo Community Development Manager
Email: [EMAIL PROTECTED]


language_strings.diff.gz
Description: GNU Zip compressed data
___
Wengophone-devel mailing list
Wengophone-devel@lists.openwengo.com
http://dev.openwengo.com/mailman/listinfo/wengophone-devel

[Wengophone-devel] Patch for lupdate macro on Linux

2007-04-02 Thread Dave Neary 

Hi,

Tanguy and I patched the OWLocaleUpdate cmake file to have the arguments
before the name of the .pro file on the 2.1 branch (since on Linux and
mac, they must come first - while I was at it, I also print the lupdate
binary that we're calling, to ensure we're not accidentally picking up
the qt3 version.

Diff attached.

Cheers,
Dave.

-- 
Dave Neary
OpenWengo Community Development Manager
Email: [EMAIL PROTECTED]
Index: owbuild/OWLocaleUpdate.cmake
===
--- owbuild/OWLocaleUpdate.cmake	(revision 10577)
+++ owbuild/OWLocaleUpdate.cmake	(working copy)
@@ -189,14 +189,14 @@
 			"[HKEY_CURRENT_USER\\Software\\Trolltech\\Versions\\4.0.0;InstallDir]/bin"
 	)
 
-	message(STATUS "lupdate .ts")
+	message(STATUS "${QT_LUPDATE_EXECUTABLE} .ts")
 
 	execute_process(
 		COMMAND
 			${QT_LUPDATE_EXECUTABLE}
-			${proFile}
 			-noobsolete
 			-verbose
+			${proFile}
 		WORKING_DIRECTORY
 			${CMAKE_CURRENT_SOURCE_DIR}
 	)
___
Wengophone-devel mailing list
Wengophone-devel@lists.openwengo.com
http://dev.openwengo.com/mailman/listinfo/wengophone-devel

Re: [Wengophone-devel] wengophone 2.1 - status

2007-04-02 Thread Jerome WAGNER 

Andreas Schneider wrote:

One of the main problems we have on Linux is sound! Portaudio has still
a lot of problems with some soundcards, especially Audigy series (btw
portaudio sucks ;). There is a phmedia-alsa driver. Can we improve it
and use ALSA instead of portaudio?

  

Hello,
I know that Didier Link has tried recently to make the standalone alsa 
driver work but I could not make a follow-up on the status of this work 
+ portaudio had been improved.


Have you tried the phmedia-alsa backend lately ?

Jerome
___
Wengophone-devel mailing list
Wengophone-devel@lists.openwengo.com
http://dev.openwengo.com/mailman/listinfo/wengophone-devel

Re: [Wengophone-devel] Re: [Wengophone-commit] r10555- wifo/branches/transport_refactoring/phapi

2007-04-02 Thread Vadim Lebedev 

Minh Phan wrote:


We want to keep backward compatibility in the transport_refactoring
 


branch
   


but that implies too much work as the whole eXosip API set will be
 


changed.
   


Hence, we decided not to keep it in that branch. Once the factoring
 


branch
   


will be released, there will be an svn tag of current phapi for those who
wish to use the old APIs.



 


Yes,
I understand that, however in the cases when preserving backward
compatibility
costs nothing or almost nothing it better to try and keep it.
I think  this specific case  it was worth the effort.
   



The point is that phVline functions won't be available as public APIs
anymore. It won't work if phVline functions are called directly by user of
phapi. owplLine functions are the replacements.

 

I see, 
In that case i agree
Of course it is very painful for me that you didn't keep my beautiful 
phVline api ;):)


Vadim


Minh


 




___
Wengophone-devel mailing list
Wengophone-devel@lists.openwengo.com
http://dev.openwengo.com/mailman/listinfo/wengophone-devel

RE: [Wengophone-devel] Re: [Wengophone-commit] r10555- wifo/branches/transport_refactoring/phapi

2007-04-02 Thread Minh Phan 
> >We want to keep backward compatibility in the transport_refactoring
> branch
> >but that implies too much work as the whole eXosip API set will be
> changed.
> >Hence, we decided not to keep it in that branch. Once the factoring
> branch
> >will be released, there will be an svn tag of current phapi for those who
> >wish to use the old APIs.
> >
> >
> >
> Yes,
> I understand that, however in the cases when preserving backward
> compatibility
> costs nothing or almost nothing it better to try and keep it.
> I think  this specific case  it was worth the effort.

The point is that phVline functions won't be available as public APIs
anymore. It won't work if phVline functions are called directly by user of
phapi. owplLine functions are the replacements.

Minh

___
Wengophone-devel mailing list
Wengophone-devel@lists.openwengo.com
http://dev.openwengo.com/mailman/listinfo/wengophone-devel

Re: [Wengophone-devel] wengophone 2.1 - status

2007-04-02 Thread Andreas Schneider 
Jerome WAGNER wrote:
> Hello,
Hi,


> It seems to me that we are flirting with this objective without really
> doing something that we can be proud of. It seems that too many of you
> still have non-acceptable difficulties on this platform.
> 
> So I decided to open a new development window on the 2.1 that will
> hopefully put an end to long standing issues under GNU/Linux. Most of
> Wengo developers will spend time only on that target in the next days.
> 

One of the main problems we have on Linux is sound! Portaudio has still
a lot of problems with some soundcards, especially Audigy series (btw
portaudio sucks ;). There is a phmedia-alsa driver. Can we improve it
and use ALSA instead of portaudio?

The sound volume of playback and capture is to low! This is a wengophone
issue.

If you change the playback volume control in wengophone, the PCM
recording volume is enabled too (Audigy 2 ZS).

Cheers,


-- andreas

-- 
http://www.cynapses.org/ - cybernetic synapses




signature.asc
Description: OpenPGP digital signature
___
Wengophone-devel mailing list
Wengophone-devel@lists.openwengo.com
http://dev.openwengo.com/mailman/listinfo/wengophone-devel

Re: [Wengophone-devel] Re: [Wengophone-commit] r10555- wifo/branches/transport_refactoring/phapi

2007-04-02 Thread Vadim Lebedev 

Minh Phan wrote:


Hi Vadim,

 


It is pretty interesting patch,

but i would suggest to not to modify existing phAddVline?   prototypes,
but add a new one with transporttype parameter.

This way you dont break existing programs
   



We want to keep backward compatibility in the transport_refactoring branch
but that implies too much work as the whole eXosip API set will be changed.
Hence, we decided not to keep it in that branch. Once the factoring branch
will be released, there will be an svn tag of current phapi for those who
wish to use the old APIs.

 


Yes,
I understand that, however in the cases when preserving backward 
compatibility

costs nothing or almost nothing it better to try and keep it.
I think  this specific case  it was worth the effort.

Vadim




Minh


 



___
Wengophone-devel mailing list
Wengophone-devel@lists.openwengo.com
http://dev.openwengo.com/mailman/listinfo/wengophone-devel

[Wengophone-devel] Linux startup issues

2007-04-02 Thread Pirmin Walthert 
Hi Jerome

I've seen your post about Wengophone2.1-status.

As you may know I've written a few times about startup-troubles on
linux. I now also sent some startup-crash-dumps (with the
crash-report... if this is working?!?) with 2.1 on windows. I don't know
exactly if the problem is the same as I've fixed now in the 2.0 version
I'm working on!

=> I had some success before in adding a sleep into the Gaim-thread
before it was starting the g_main_loop. This worked in most cases but
when startup was even slower (because of networking troubles) this
didn't help! What I've now done is the following (and now it really
workes always!):

I'm not calling GaimMainEventLoop(gpointer data) anymore in
GaimIMInit(). Instead I've added a new function to GaimIMFactory:

bool GaimIMFactory::startGaimFactory() {
g_thread_create(GaimMainEventLoop, NULL, FALSE, NULL);
return true;
}

(and I also had to put a sleep(1) into GaimMainEventLoop to be shure
that really everything is ready)

=> I'm now starting this AFTER the userlist was initialised (in the
callback to QtWengoPhone that adds the UList to the Tab). Because the
problems I had seemed to have to do with the gui: IMAccounts were logged
in before the GUI was ready to handle the events. (This is an
assumption...).

QtWengoPhone.cpp then calls readyForEvents() that is passed back through
control to model. In userProfileHandler I then have the following:

void UserProfileHandler::readyForEvents()
{
if (_readyForEvents==false)
{
IMWrapperFactory::getFactory().startGaimFactory();
}
_readyForEvents=true;
_currentUserProfile->readyForEvents();
LOG_DEBUG("Connecting enabled!");
}

What also enables the ConnectionManger to connect => it is in a loop
before in the functions that could create connections:

while (_userProfile.getReadyForEvents()==false)
{
Thread::sleep(1);
}

I know, this is not the clean solution you are searching for! I only
wanted to show you how I solved all the startup-isssues I had. And
because I was limited in time and will have to pass a functioning
version over to someone other next week I had to work with such unclean
fixes.

And this REALLY works for me. Yesterday I've tested this about 50 times
without any crashes. Even the log-off/log-in now works as expected what
also didn't work always before!

While I don't think that you want to solve it this way I wanted to write
about my experiences here, perhaps my solution gives you an idea for a
cleaner one!

Cheers, Pirmin

___
Wengophone-devel mailing list
Wengophone-devel@lists.openwengo.com
http://dev.openwengo.com/mailman/listinfo/wengophone-devel

Re: [Wengophone-devel] IMWrapprer PhApiWrapper evolution

2007-04-02 Thread Philippe BERNERY 

Le 28 mars 07 à 15:31, Vadim Lebedev a écrit :


So i'd like to have community and openwengo team input.


Hi Vadim,

Methods you added seem right for me. It misses examples in method  
documentation to explain how/where/when to use these methods.


Regards

--
Philippe BERNERY <[EMAIL PROTECTED]>
http://dev.openwengo.org


___
Wengophone-devel mailing list
Wengophone-devel@lists.openwengo.com
http://dev.openwengo.com/mailman/listinfo/wengophone-devel

RE: [Wengophone-devel] Re: [Wengophone-commit] r10555- wifo/branches/transport_refactoring/phapi

2007-04-02 Thread Minh Phan 
Hi Vadim,

> It is pretty interesting patch,
> 
> but i would suggest to not to modify existing phAddVline?   prototypes,
> but add a new one with transporttype parameter.
> 
> This way you dont break existing programs

We want to keep backward compatibility in the transport_refactoring branch
but that implies too much work as the whole eXosip API set will be changed.
Hence, we decided not to keep it in that branch. Once the factoring branch
will be released, there will be an svn tag of current phapi for those who
wish to use the old APIs.


Minh

___
Wengophone-devel mailing list
Wengophone-devel@lists.openwengo.com
http://dev.openwengo.com/mailman/listinfo/wengophone-devel

[Wengophone-devel] wengophone 2.1 - status

2007-04-02 Thread Jerome WAGNER 

Hello,

As you all know, GNU/Linux support is one of the key objectives of the 
WengoPhone 2.1 release.


It seems to me that we are flirting with this objective without really 
doing something that we can be proud of. It seems that too many of you 
still have non-acceptable difficulties on this platform.


So I decided to open a new development window on the 2.1 that will 
hopefully put an end to long standing issues under GNU/Linux. Most of 
Wengo developers will spend time only on that target in the next days.


I won't hide that there is a risk of opening pandora's box while we are 
at an RC2 stage on WengoPhone 2.1, but I really think that we should not 
call a WengoPhone 2.1 final if it does not


One of the first thing that is going to be done is to upgrade to the 
last stable version of libgaim because it seems that this library has 
improved a lot lately and that many of our issues on GNU/Linux will 
disappear with the upgrade.


I hope that you will understand my position and I wish that some of you 
can help in this GNU/Linux sprint !


Thank you
Jerome
___
Wengophone-devel mailing list
Wengophone-devel@lists.openwengo.com
http://dev.openwengo.com/mailman/listinfo/wengophone-devel

Re: [Wengophone-devel] Nmake Install Problem

2007-04-02 Thread Dave Neary 

Hi,

To have the .qm files generated in the right place, it's better to run
"nmake lupdate".

Cheers,
Dave.

Claudio André wrote:
> Hi
> 
> I can see it is complaing about missing (language) files. You can create
> the language files using lrelease or you can copy the  language files
> from RC2.
> 
> Claudio
> 
> George Lee escreveu:
>> I am still having trouble with nmake install. I have had this problem
>> for a while.
>>  
>> I run build_nmake.bat without any trouble, then I run nmake install.
>> Here is the error message.
>>  
>> > nmake install
>>  
>> < ... deleted ... >
>>  
>> File: "export7_96.png" [compress] 7797 bytes
>> File: "export8_96.png" [compress] 7671 bytes
>> File: "export9_96.png" [compress] 6251 bytes
>> SetOutPath: "$INSTDIR\lang\"
>> File: "C:/Wengo-dev/2.1/build/debug\lang\*.qm" -> no files found.
>> Usage: File [/nonfatal] [/a] ([/r] [/x filespec [...]] filespec [...] |
>>/oname=outfile one_file_only)
>> !include: error in script: "files_install.nsi" on line 54
>> Error in script "C:/Wengo-dev/2.1/wengophone/nsis/installer.nsi" on
>> line 132 --
>> aborting creation process
>>  
>> Could someone please help?
>>  
>> - George
>> 
>>
>> ___
>> Wengophone-devel mailing list
>> Wengophone-devel@lists.openwengo.com
>> http://dev.openwengo.com/mailman/listinfo/wengophone-devel
> 
> 
> 
> 
> ___
> Wengophone-devel mailing list
> Wengophone-devel@lists.openwengo.com
> http://dev.openwengo.com/mailman/listinfo/wengophone-devel


-- 
Dave Neary
OpenWengo Community Development Manager
Email: [EMAIL PROTECTED]
___
Wengophone-devel mailing list
Wengophone-devel@lists.openwengo.com
http://dev.openwengo.com/mailman/listinfo/wengophone-devel