Ramy M. Hassan wrote:
Hello,
You are right. NSUTF8StringEncoding is much better. I tried running the
application from a path that contained non-ascii folder names, and only
worked perfectly when NSUTF8StringEncoding was used.
I think your patch is ok, but I was just wondering which sound
Aurélien Gâteau wrote:
It works for me, but I believe your patch is correct nevertheless. I
will probably merge it tomorrow.
I just committed your patch to the wengophone-2.1 branch. I'm currently
rebuilding 2.0 to make sure it works also there (although there is no
reason it would
Aurélien Gâteau wrote:
I just committed your patch to the wengophone-2.1 branch. I'm currently
rebuilding 2.0 to make sure it works also there (although there is no
reason it would not). When it's done, I'll commit it to 2.0 too.
It's committed in 2.0 now.
Aurélien
Hello,
I created a few usability tickets on Trac. I would really like to have
your opinion on them. Here they are:
1206: Merge Log off and Switch profile
http://dev.openwengo.com/trac/openwengo/trac.cgi/ticket/1206
1207: Rework toolbar content
Nicolas Lécureuil wrote:
Le vendredi 15 décembre 2006 11:12, Aurélien Gâteau a écrit :
Hello,
I just wanted to let you know that the API documentation is now
available online. This documentation is generated by Doxygen and is
nightly updated.
Have a look at this wiki page for more info:
http
Jaya Meghani wrote:
Hi,
If I add more columns in Tree Widget of Contact List then on clicking -
background is applied to only one column.
Is this because in paint function of QtContact::paint() the option.rect gives
the rect for a particular trewidgetitem on which its clicked.
For example if
Dave Neary wrote:
Hi,
I wanted to congratulate Marco Nencarini on getting the Wengophone
included in Debian Testing since the 6th of November:
http://packages.debian.org/testing/net/wengophone
Great work Marco!
normally means that we'll be in the next stable Debian
release after Etch (due
Jaya Meghani wrote:
Hi,
I used void setSelectionBehavior ( QAbstractItemView::SelectionBehavior
behavior ) and set behavior to select rows and it works.
Oh, nice. Didn't notice this property exists.
Aurélien
___
Wengophone-devel mailing list
Lukas Oberhuber wrote:
Arelien,
The patch I attached in the previous message already does what you suggest.
I was mostly explaining what I had done, but I guess I didn't make that
clear enough.
Yes, it does. But I believe my solution is a bit nicer because it does
not require adding another
Lukas Oberhuber wrote:
Aurelien,
I now see what you are saying. Yes, that does look more elegant. I will try
to implement (of course for me now it requires unwinding all the patch code
so I might tackle a little later).
I understand :-/
As far as base64 is concerned, I had a look at it but I
Dave Neary wrote:
For each platform and branch, we should document whether the
reccommended build system is scons or cmake. The objective is to remove
scons support from trunk and the 2.1 branch altogether.
Platform | | | |
---. | Win32 | Mac | Linux |
Branch \|
Philippe BERNERY wrote:
Le 20 déc. 06 à 10:28, Aurélien Gâteau a écrit :
Being a Vim afficionado, I don't use XCode, but I know pbernery does.
XCode environment is needed to build WengoPhone as installing XCode will
install gcc and dev. libraries. However there is no recommended code
editor
Hi,
I recently added a new macro to OWBuild: ow_exclude_from_all, which
passes the EXCLUDE_FROM_ALL option to ADD_EXECUTABLE.
This option appeared in CMake 2.4.4, if you are running an older version
of CMake, you will have to upgrade. Sorry about that.
Aurélien
[EMAIL PROTECTED] wrote:
Are you talking about version 2.0 or version 2.1 or trunk?
Sorry, this is on 2.1 for now, but should be soon merged in trunk. It
won't be in 2.0.
Aurélien
___
Wengophone-devel mailing list
Hello,
I just committed a patch to use dwarf-2 debugging format for MacOS. This
produce much smaller executables (from 372MB to 37MB on my machine). It
will probably cause a full rebuild for MacOS users, but should improve
your next build times.
Hopefully it won't cause a full rebuild on
Philippe BERNERY wrote:
Le 13 janv. 07 à 18:50, Nicolas Lécureuil a écrit :
i have verified and it doesn't seems to be related to cmake 2.4.4
because :
$ rpm -q cmake
cmake-2.4.6-1mdv2007.1
Can you try 'cmake --version'. I've got the same error as you when I had
CMake 2.4.3 on my
Nicolas Lécureuil wrote:
Le mardi 16 janvier 2007 13:33, Nicolas Lécureuil a écrit :
this pb is still valid with a snapshot of today.
Can someone please help me ? this blocks me to do my rpm :/
The pb with APPLICATION_BIN_INSTALL_DIR and DATA_INSTALL_DIR should be
fixed in r9375. Can you
Hello,
I have been working with Nicolas Lécureuil, the Mandriva packager, to
fix the install target of the WengoPhone.
The attached patch (for the 2.1 branch) is a rewrite of the install
target, using CMake functions. It lets you specify the installation
prefix using the standard CMake
Nicolas Lécureuil wrote:
hi,
now that wengophone installs and compiles, on x86_64, some files are
not installed whereas they are installed on i586.
the files are files :
/usr/share/wengophone/lang/qtwengophone_de.ts
/usr/share/wengophone/lang/qtwengophone_en.ts
Claudio André wrote:
It is not what you are talking about, anyway:
- I think build_make.sh should be changed in order to avoid hardcoded
settings that should conflict with DefineWengoOptions, or command line
parameters.
For example, if i use build_make.sh, Aurelien patch is not going to act
Nicolas Lécureuil wrote:
2007/2/5, Aurélien Gâteau [EMAIL PROTECTED]:
Nicolas Lécureuil wrote:
hi,
now that wengophone installs and compiles, on x86_64, some files are
not installed whereas they are installed on i586.
the files are files :
/usr/share/wengophone/lang/qtwengophone_de.ts
Nicolas Lécureuil wrote:
it works ok and created without errors :
$ ls /export/home/neoclust/BUILD/wengophone-2.1/build/debug/lang/
qtwengophone_de.qm qtwengophone_fr.qm qtwengophone_pl.qm
qtwengophone_zh.qm
qtwengophone_en.qm qtwengophone_it.qm qtwengophone_sv.qm
qtwengophone_es.qm
Hello,
If you have been following the 2.1 branch lately, you may have noticed
my work on reducing the amount of output sent to stderr when building in
release mode (Ticket #199). I also removed some output in debug mode,
like the Google source code shown on startup...
I won't continue
Aurélien Gâteau wrote:
Hello,
I have been working with Nicolas Lécureuil, the Mandriva packager, to
fix the install target of the WengoPhone.
The attached patch (for the 2.1 branch) is a rewrite of the install
target, using CMake functions. It lets you specify the installation
prefix using
Sebastien Tricaud wrote:
Glib does a pretty good work :
http://developer.gnome.org/doc/API/2.0/glib/glib-Message-Logging.html
Glib looks good indeed. I will have a closer look at it.
Aurélien
___
Wengophone-devel mailing list
Hello,
I just committed a workaround for ticket #1053: Qt 4.2 support for
Linux. The workaround simply sets the QT_NO_GLIB environment variable on
startup. Not exactly a nice fix, but should be good enough for the 2.1
branch.
You will find it in the 2.1 branch, r9694.
Aurélien
Hello,
I have found another problem with Qt 4.2:
QObjectThreadSafe::initThreadSafe is not called. I created ticket 1322
for it [1]. I wrote a test program to demonstrate the problem and
confirmed it on Windows (Qt 4.2.1) and Linux (Qt 4.2.0).
It would be nice for you to test and report if
Lukas Oberhuber wrote:
In QtWengoPhone.cpp a number of pointers are not initialized. If for
some reason the userProfile was no successfully instantiated (which just
happened to me), this leads to a segfault when I try to do ‘Log off…’.
Thanks for the report Lukas. I just went through all
Gianluca Sforna wrote:
http://dev.openwengo.com/trac/openwengo/trac.cgi/changeset/9735
rpath is a no-no in most distros. This change will likely impose
actyually _more_ work to packagers...
http://fedoraproject.org/wiki/Extras/Schedule/RpathCheckBuildsys
Looking at the list of RPATH issues
Hello list,
I am happy to announce that Nicolas Lécureuil told me he uploaded his
WengoPhone package on Mandriva Cooker.
Thanks for your work, Nicolas!
Aurélien
___
Wengophone-devel mailing list
Wengophone-devel@lists.openwengo.com
Andreas Schneider wrote:
Hi,
we need a fix warnings-day! There are a lot of bad warnings which we
should fix, some lead to real problems.
I agree.
Aurélien
___
Wengophone-devel mailing list
Wengophone-devel@lists.openwengo.com
Claudio André wrote:
Hi, everybody
This line: chat/ChatLogViewer.ui in
src/presentation/qt/CMakeLists.txt broke automatic build process
The makefile is not created and the build fails.
The file ChatLogViewer.ui is not on svn
Xavier fixed it this morning. Should be ok now.
Sorry.
Gianluca Sforna wrote:
On 2/20/07, Jerome WAGNER [EMAIL PROTECTED] wrote:
Hello,
BTW what about a proper and trivially accessible sources archive?
2 - what would be the correct frequency for generating such builds
For most purposes, one for each official release is enough.
Since we
Gianluca Sforna wrote:
On 2/20/07, Aurélien Gâteau [EMAIL PROTECTED] wrote:
Gianluca Sforna wrote:
On 2/20/07, Jerome WAGNER [EMAIL PROTECTED] wrote:
Hello,
BTW what about a proper and trivially accessible sources archive?
2 - what would be the correct frequency for generating
Gianluca Sforna wrote:
On 2/21/07, Dave Neary [EMAIL PROTECTED] wrote:
I disagree. Design and development are two completely different
skill-sets, and the temptation when discussing feature design on a devel
list is to start thinking about how the feature will get done, when we
should be
Hello,
Attached to this mail you will find a patch to make it possible to
disable copy of data files at configure time.
- Apply it in wengophone top src dir
( patch -p0 copy_on_configure_option.diff )
- Set the cmake COPY_DATA_FILES_ON_CONFIGURE option to OFF (it's ON by
default so that it
Philippe BERNERY wrote:
Le 27 févr. 07 à 12:30, Aurélien Gâteau a écrit :
- Enjoy a little bit faster compile every time cmake need to be run.
Does it really improve the compile time? Data copy is only made when
calling cmake, not make, and files are copied only if they do not exist
Philippe BERNERY wrote:
I don't agree because when developing the WengoPhone you need these
resources but you don't want to install WengoPhone. However your
solution fixes this issue: you can launch cmake a first time without the
option to copy data then relaunch when necessary with the option
Andreas Schneider wrote:
Aurélien Gâteau wrote:
Copying data files should be done while installing, not during
configuration/build.
So wouldn't it make more sense to create install targets for the file?
I don't understand what you mean. There is an install target, and it
does what it's
Aurélien Gâteau wrote:
I will probably commit this soon, but it would be nice if you could tell
me if it works and whether it's a good idea.
For your information, I just committed it. It's in r9984.
Aurélien
___
Wengophone-devel mailing list
Lukas Oberhuber wrote:
In 2.1 the webcam button was removed from the UI. This means that I
can’t change my webcam setting before making a call, unless I go into
the settings dialog. In actual usage this is quite disconcerting because
I want to turn the webcam on and off on a per call basis.
Lukas Oberhuber wrote:
This patch optimizes the file loading of avatars. I noticed that the
default avatar was being loaded over and over and at a minimum this
reduces the number of console messages, if not speeding up the loading.
Hello Lukas.
Thanks for the patch. I reworked it so that the
Lukas Oberhuber wrote:
Aurelien,
Excellent.
Since then, I've spent some time trying to understand the flashing that
happens whenever presence status changes for any contact (in the contact
list).
Here's what I found (which will hopefully point in the direction of a
solution):
(snip)
Hum...
Hello,
I just created a page on the wiki describing the way I set up my Ubuntu
Edgy box to build the WengoPhone. You can find it here:
http://dev.openwengo.org/trac/openwengo/trac.cgi/wiki/BuildNgOnUbuntuEdgy
Hope it helps
Aurélien
___
Pirmin Walthert wrote:
I run now WengoPhone with the patch applied and a big userlist for 16
hours. Logging was enabled to get some statistic results:
While the userlist had to be redrawn 372 times because of correct
presenceStateChanged events my patch prevented WengoPhone to redraw it
6889
Aurélien Gâteau wrote:
Pirmin Walthert wrote:
I run now WengoPhone with the patch applied and a big userlist for 16
hours. Logging was enabled to get some statistic results:
While the userlist had to be redrawn 372 times because of correct
presenceStateChanged events my patch prevented
Hello,
The attached patch improves the update of the contact list by repainting
the list instead of rebuilding the content every time the presence is
changed.
What it does is when a contact is changed it checks if the contact must
be added, removed or updated.
If it needs to be added or
Claudio André wrote:
Hi
I personally think grouping by presence is not a good idea. What do
you think about this?
I agree with you, but i looked at gaim 2.0, and they have the order by
status option. So, it might be something users like/use/required.
It's a feature we could implement if we
Dave Neary wrote:
Hi,
Unfortunately, the OpenWengo project didn't make the cut of the projects
accepted into the Google Summer of Code this year - I'm very
disappointed, because I thought we had a good chance of being accepted,
and I definitely think we had something to offer participants.
Pirmin Walthert wrote:
While I agree that this fix isn't the way this issue should be fixed
(although the submission of this patch to the mailinglist was done by
me) it's simply not true, that the application crashes soon after this!
I know this because I'd run the application once before the
Pirmin Walthert wrote:
Googling showed me that people can have this exception if two
boost-threads try to access ressources that are locked by a mutex from
one of the two threads. But I don't know if this is true :) The only
thing boosts online-documentation contains about this exception (and
Pirmin Walthert wrote:
Hi
You were talking about pointers that are garbage because of wrong code.
= Couldn't it be possible, that sometimes pointers are valid, as long
as passed, but in the meantime (before the boost-binding is executed)
the corresponding objects are already destroyed? Think of
Claudio André wrote:
Hi, i had problems compiling this new line (from rev 10549).
4192 assert(0, Invalid line state while
receiving OK for REGISTER message!);
4193 return;
The macro in my system do not allow assert with two
Hello,
I have been working on the translation compilation this morning, and
here is the result:
- make lrelease builds the translations, and it only builds the
necessary files.
- make builds the WengoPhone *and* the translations.
What do you think about it?
Aurélien
Index:
Dave Neary wrote:
Dave Neary wrote:
Hi,
Aurélien Gâteau wrote:
I have been working on the translation compilation this morning, and
here is the result:
- make lrelease builds the translations, and it only builds the
necessary files.
- make builds the WengoPhone *and* the translations.
What
Just for information: in case you are spending too much time wandering
through CMake documentation, I created a little script which you might
find handy: it creates an hyperlinked version of CMake doc.
You can find it here:
https://dev.openwengo.org/svn/openwengo/playground/beautifycmakedoc
Christopher Jimenez wrote:
Hi Wengonauts.
Quick questions, I recompile wengophone because a image to test, but the
image is not been show, i think is is because is not recompiling the
.qrc. Is there a command to acomplish this? Or what i can do.
Im using scons
scons mode=release qtwengophone.
Vadim Lebedev a écrit :
It is much better to have couple of
phrases of comments in free-flow format
in 2-3 lines, than a 'beautiful' comment templates on half a page, which
often make impossible to see
the comment and function body together on the monitor. ( Of course there
is another reason
Vadim Lebedev a écrit :
Hello Vadim,
Just wanted to point out two things about Doxygen comments:
First: if I'm not mistaken, OpenWengo project coding style says that
Doxygen comments should be in .h files, so they should not annoy you
when reading source code.
Second: if you haven't tried
Dave Neary a écrit :
Hi,
I got a mail from someone a while ago saying that translations weren't
working with the nightly builds - he wanted to see his translation in
action, and was disappointed that he couldn't with the binary Linux
nightlies.
I realised a while ago why that is - under Linux
Vadim Lebedev a écrit :
Hello,
I've started to work on implementation of srever-resident contact list...
So I've dived into 2.1 sources and frankly my mind start boiling a
little :):)
Would some charitable soul explain (or point to existing explanation)
me relationship between
Profile,
Vadim Lebedev a écrit :
[EMAIL PROTECTED] wrote:
Please, do not reply to this mailing list, use wengophone-devel instead.
This one braks compilation:
r10985 only removes LOG_DEBUG.
The lines in QtLoginDialog.cpp should be
really:
Vadim Lebedev a écrit :
Folks,
I think i've stumbled on SERIOUS SVN bug...
I created my wenophone-2.1-vadim branch at revision 10928
However it appears that file
wengophone/src/presentation/qt/login/ILogin.h didn get
revision 10903 inside
It seems that branch creation is buggy
Just
Dave Neary a écrit :
#1416: ContactList and boost::thread_resource_error
This happens in a couple of situations - most notably when you leave the
computer unattended for longish periods. It seems that there is a limit
to the number of threads a process can create (in its lifetime?) -
Aurélien
Hello,
As I said this morning, the Timer class is the cause of the infamous
thread_resource_error exception (see ticket #1416): when I reproduced
the bug in gdb, I found out that the timer responsible for saving the
user profile had 360 threads in it.
This patch fixes the problem by only
Vadim Lebedev a écrit :
Second, even if we have one thread per timer, why do you need to
create it
in the constructor? and then stop/restart it in the start(..) method?
I often find it easier to maintain if members of a class are always
allocated, rather than created and deleted on demand.
Vadim Lebedev a écrit :
Now THE question:
It appears that some(good or bad) reason the original Timer class was
able to (mis-)handle
multiple active timeouts. :)
Your version obviously is not doing that... So is this multi-timeout
capability
is used by wengophone?
I don't think so,
Vadim Lebedev a écrit :
Aurélien Gâteau wrote:
Vadim Lebedev a écrit :
Now THE question:
It appears that some(good or bad) reason the original Timer class
was able to (mis-)handle
multiple active timeouts. :)
Your version obviously is not doing that... So is this multi-timeout
Aurélien Gâteau a écrit :
Vadim Lebedev a écrit :
Aurélien Gâteau wrote:
Vadim Lebedev a écrit :
Now THE question:
It appears that some(good or bad) reason the original Timer class
was able to (mis-)handle
multiple active timeouts. :)
Your version obviously is not doing that... So
Hello,
I recently experienced dead locks on MacOSX while trying to validate my
timer patch: WengoPhone would use 100% cpu and gdb show that a few
threads were waiting for malloc to finish. Here are relevant excerpts
from gdb:
--
Thread 1 (process 6058 local thread 0xf03):
#0 0x85d8
Hello,
I just created a 'gdb' folder in playground. In this folder you will
find some useful functions to make your work with GDB less painful :-).
It contains some nicer (IMHO) GDB settings, as well as functions to
print STL containers.
You can get it with
svn co
Aurélien Gâteau a écrit :
Aurélien Gâteau a écrit :
Vadim Lebedev a écrit :
Great,
It seems we've covered all issues i could think of
I don't see any additional problem with the patch
Good, thanks for taking the time to review it. I will wait a little
bit more before applying
Aurélien Gâteau a écrit :
If you look at the signal() man page, you will see that only a few
function calls are allowed inside a signal catcher function, so it's not
allowed to call LOG_DEBUG(). Even printf() is potentially dangerous
because it uses malloc().
The attached patch fixes
Vadim Lebedev a écrit :
Aurélien Gâteau wrote:
Hello,
I just created a 'gdb' folder in playground. In this folder you will
find some useful functions to make your work with GDB less painful :-).
It contains some nicer (IMHO) GDB settings, as well as functions to
print STL containers
[EMAIL PROTECTED] a écrit :
Hello Aurélien
Possibly you really found one of the reasons that leads to this error! But there
exists at least another one: I'm able to reproduce this (like I've already
written once) as soon as the /proc/PROCID/oom_score value raises above
something about 750'000 =
Hello,
For your information, we decided to create separate wengophone-2.1
branches for the externals used in the wengophone-2.1 branch.
Here is a summary of the new externals:
/owbuild
|
v
https://dev.openwengo.com/svn/openwengo/owbuild/branches/wengophone-2.1/owbuild
/wifo
|
v
[EMAIL PROTECTED] a écrit :
Dear friends,
is it possible to plug-in wengophone in kde sound server (artsd) instead of
relying on alsa or on portaudio?
For now, the only solution I know is to use artsdsp:
artsdsp qtwengophone
It should work, but I haven't tested.
Aurélien
Tanguy Krotoff a écrit :
Aurélien Gâteau wrote:
This has been discussed and decided with Jérome Wagner. It's always
possible to rename them, but I won't do this on my own.
This is not the question, the question is:
is it better to name it 1.0 rather than wengophone-2.1?
I believe so
Dave Neary a écrit :
Hi,
Gianluca Sforna wrote:
Oh yes, I forgot to mention that (once the strings are definitive)
this is also something that would be nice to have translated.
What's the best way to have the .desktop file translated? Is there any
way we can generate a translatable string
Hello,
The current emoticon code replaces all occurence of ascii smileys with
img HTML tags. In this case:
span style=font-family:Deja Vu SansBla/span
It will replace the :D with a img tag, breaking the message. This is
ticket #1671.
Attached patch fix this by parsing the html and
Aurélien Gâteau a écrit :
Hello,
The current emoticon code replaces all occurence of ascii smileys with
img HTML tags. In this case:
span style=font-family:Deja Vu SansBla/span
It will replace the :D with a img tag, breaking the message. This is
ticket #1671.
Attached patch fix
For your infomation, I just removed the remaining, outdated, SCons
files. It should make it more explicit to people that the only supported
build system is CMake.
Aurélien
___
Wengophone-devel mailing list
Wengophone-devel@lists.openwengo.com
Thomas Monjalon a écrit :
Hi all,
I attached a patch on ticket #1662:
http://dev.openwengo.com/trac/openwengo/trac.cgi/ticket/1662
The issue is due to the thread model of the Timer class which doesn't
allow restarting a timer in its event handler.
The solution is to jump to another thread
Dave Neary a écrit :
Hi Chopra,
chopra dhruv wrote:
I have been working on the wengophone code and wanted
to know how I can generate the MSI executable file,
similar to what is provided at www.openwengo.com/
(I have built my code in the release version)
If you have the WengoPhone building
Hello,
After the release of the WengoPhone 2.1, we realized we had a problem
with build documentation: since we maintain it in the Trac wiki, it
doesn't get branched whenever we branch the source code. For example, if
I want to build WengoPhone 2.0 for some reason, I have to dig in the
wiki
Hello,
I have been working on improving cobranding support for the WengoPhone.
I wrote an OpenWengo Enhancement Proposal (OWEP) about it. You can find
it here:
http://dev.openwengo.org/trac/openwengo/trac.cgi/wiki/OWEP_11388_Cobranding
As it's stated in the document, all work is going on in
Marco Nenciarini a écrit :
http://dev.openwengo.org/trac/openwengo/trac.cgi/ticket/1673
owutils/memorydump under linux make use of crashdumper
unconditionally, but it compile only on i386 and amd64.
Linux (and Debian) supports many other architectures, like alpha, arm,
hppa, ia64, m68k,
Aurélien Gâteau a écrit :
Marco Nenciarini a écrit :
http://dev.openwengo.org/trac/openwengo/trac.cgi/ticket/1673
owutils/memorydump under linux make use of crashdumper
unconditionally, but it compile only on i386 and amd64.
Linux (and Debian) supports many other architectures, like alpha, arm
Aurélien Gâteau a écrit :
Hello,
I have been working on improving cobranding support for the WengoPhone.
I wrote an OpenWengo Enhancement Proposal (OWEP) about it. You can find
it here:
http://dev.openwengo.org/trac/openwengo/trac.cgi/wiki/OWEP_11388_Cobranding
The document talks about
Maxime Alexandre a écrit :
Nice :)
About the file format, why don't you use a standard format to store the
data ?
The thing is: we try to make the WengoPhone 2.1 easier to cobrand
without making too many invasive changes. If it was up to me, I wouldn't
be using XML to store config, or I
Gianluca Sforna a écrit :
On 6/4/07, Aurélien Gâteau [EMAIL PROTECTED] wrote:
Aurélien Gâteau a écrit :
Marco Nenciarini a écrit :
http://dev.openwengo.org/trac/openwengo/trac.cgi/ticket/1673
owutils/memorydump under linux make use of crashdumper
unconditionally, but it compile only
Marco Nenciarini a écrit :
On Mon, Jun 04, 2007 at 03:45:25PM +0200, Gianluca Sforna wrote:
On 6/4/07, Aurélien Gâteau [EMAIL PROTECTED] wrote:
Aurélien Gâteau a écrit :
Marco Nenciarini a écrit :
http://dev.openwengo.org/trac/openwengo/trac.cgi/ticket/1673
owutils/memorydump under linux
Marco Nenciarini a écrit :
On Tue, Jun 05, 2007 at 12:38:19PM +0200, Dave Neary wrote:
Hi,
Aurélien Gâteau wrote:
Marco Nenciarini a écrit :
I don't known if it is usevull, but the provided workarround does not
works[1] :-/
Argh... it seems coredumper is unconditionally linked in owutil
Aurélien Gâteau a écrit :
Aurélien Gâteau a écrit :
Hello,
I have been working on improving cobranding support for the
WengoPhone. I wrote an OpenWengo Enhancement Proposal (OWEP) about it.
You can find it here:
http://dev.openwengo.org/trac/openwengo/trac.cgi/wiki/OWEP_11388_Cobranding
Andreas Schneider a écrit :
Jai Rangi wrote:
Hello I am trying to build openwengo from sources on FC5. I am getting
this error,
Hum... this is not the right list to ask these kind of questions. I am
ccing the wengophone-devel list instead
(wengophone-devel@lists.openwengo.com), please
Andreas Schneider a écrit :
Aurélien Gâteau wrote:
Andreas: we do require a separate build dir, but I think Jan is doing it
right: he ran cmake with a dir passed as the second argument, so I
believe he is using a separate build dir.
We require a separate build directory.
Jan
Hello,
Cobranding work is going well, the configuration part is done, you can now
define your own default configuration values by editing the
system 'config.xml' file instead of editing config.cpp.
I am now working on loading images from the file system instead of bundling
them in the binary,
Le Jeudi 21 Juin 2007 16:19, Dave Neary a écrit :
Have you checked on the QT forums whether this is a supported subversion
of Designer?
I looked around on QtForum and QtCentre but it seems nobody is tortuous enough
to come up with such a solution :-)
Is it possible that when you do a make
Hello,
A while ago I reported on Trac (ticket #1332), that the QObjectThreadSafe
class from qtutil didn't work with Qt 4.2. The problem seems to lie in the
way Qt handles Qt events posted from non Qt threads. Qt 4.1 accepts them,
while Qt 4.2 does not.
This bug causes all sort of troubles
Le Vendredi 29 Juin 2007 11:34, Ludovico Cavedon a écrit :
[snip]
The problem with Wengophone is that QObjects are created by QtFactory,
which runs in model thread and not in QApplication thread, right?
I think the least disruptive but nevertheless correct and effective
solution would be to
1 - 100 of 216 matches
Mail list logo
