>
>
> Like I said, I've been working on some patches quietly. Here is one.
>
> This fixes bug 908, by implementing an option to enable cycling
> through desktops with the mouse wheel.
>
> Please test this out.
>
> http://bugs.trinitydesktop.org/show_bug.cgi?id=908
>
Works here!
I would suggest making a bit more efficient and clean by putting the check
at the beginning of the wheelEvent method like this:
void KMiniPager::wheelEvent( TQWheelEvent* e )
{
if(!cycleWindow())
return;
int newDesk;
int desktops = KWin::numberOfDesktops();
if (m_twin->numberOfViewports(0).width() *
m_twin->numberOfViewports(0).height() > 1 )
...
This way by looking at the code it is immediately clear that if cycleWindow
is false the method is a no-op and you avoid an extra level of indentation.
--
Leandro
--
Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP
autenticato? GRATIS solo con Email.it: http://www.email.it/f
Sponsor:
Apri subito Conto Corrente Arancio. Carta Visa Gratis e nessun Canone!
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=12246&d=20120331
--
Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f
Sponsor:
Centinaia di Idee Regalo a partire da 1 euro! Su MisterCupido.com alta qualita' a prezzi imbattibili... e spedizioni in 2/3 giorni!
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=11452&d=31-3
In the Commit Patches web page is the following patch:
[tdelibs] Add initial tdehardwaredevices skeleton to tdecore
Do not use the added classes yet, as the API and ABI are still under heavy construction!
The work on tdehardwaredevices is important to remove the dependency on HAL. Yet skeleton or not, could we please NOT push any API/ABI changes until after R14? Pushing eventual API/ABI changes will create hardships, especially something as monumental as removing HAL dependencies.
As important as that might seem, the bug tracker receives very little attention. Are we developing a reputation of ignoring bug reports?
David and I seem to be the only ones actively trying to squash build issues. Obvious from the messages we post is there are many build related issues that need attention. David and I post a lot of build related questions to this list and frequently nobody answers. Many build related bug reports have been filed and remain untouched.
Not to mention a few hundred unanswered bug reports regarding usability.
According to a previous discussion, the math indicates that we won't resolve many bugs before R14 is released. That implies we are going to push R14 on schedule --- buggy.
Now that we have news about a significant customer using Trinity (LiMux project in Munich), should we be making every effort to quash a significant portion of the bugs and release an R14 that all users relish and even want to join us to help develop further? We sure could use that kind of extra help and publicity.
Darrell
>
>
> Building kstreamripper is broken because the python build script can't
parse the new TDE versioning scheme and looks for kde-config rather than
tde-config.
>
> I tried fixing things but fell short and filed bug report 946:
>
> http://bugs.pearsoncomputing.net/show_bug.cgi?id=946
>
> I don't think the changes need be prolific. If you have any python
experience you probably can make the changes in short order.
>
> As always am I ready to test any patches.
>
Not a Python expert but you can try this:
tde_version = os.popen("tde-config --version|grep
TDE").read().strip().split()[1]
tde_major = tde_version.split('.')[0].lstrip('R')
tde_minor = tde_version.split('.')[1]
tde_patch = tde_version.split('.')[2]
if int(tde_major) != 14:
print RED + tde_version
print RED + "Your tde version can be too old" + NORMAL
print RED + "Please make sure tde is at least R14.0" + NORMAL
else:
print GREEN + tde_version + NORMAL
--
Leandro
--
Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP
autenticato? GRATIS solo con Email.it: http://www.email.it/f
Sponsor:
Vuoi fare un regalo davvero originale? Su MisterCupido.com puoi crearlo tu!
Personalizza con le tue foto: quadri, tazze, puzzle, cuscini, peluche...
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=11450&d=20120330
--
Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f
Sponsor:
Offerta speciale: a partire da soli Euro 18.90 puoi stampare le tue Foto su vera Tela Pittorica e creare Quadri fino a 80x50 cm!
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=11453&d=30-3
All,
The current mlt++ source Makefile requires that the 'test' directory be
compiles as part of the build. This fails on Arch. I have disabled the build
of the 'test' dir files with:
sed -i '/\$(MAKE) -C test \$@/d' Makefile
Is there any reason they should be built by the current Makefile to begin
with? Isn't that something that is normally done by the user AFTER the package
is installed? Since the 'test' Makefile requires -lmlt++ and that lib isn't
installed until the package is installed - this will cause a build failure
every time.
--
David C. Rankin, J.D.,P.E.
Building kstreamripper is broken because the python build script can't parse the new TDE versioning scheme and looks for kde-config rather than tde-config.
I tried fixing things but fell short and filed bug report 946:
http://bugs.pearsoncomputing.net/show_bug.cgi?id=946
I don't think the changes need be prolific. If you have any python experience you probably can make the changes in short order.
As always am I ready to test any patches.
Thanks!
Darrell
All,
GIGO right - computers, given the same input should produce the same output
every time. If it's garbage in it's garbage out.
The build of sip4-tqt seems to violate that adage. When attempt to build
sip4-tqt (the first time/randomly), I get a failure:
gcc -c -march=i686 -mtune=generic -O2 -pipe -fstack-protector
--param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -I/usr/include/tqt
-I/opt/trinity/include -I/opt/tqt3/include -O2 -w -DNDEBUG -I. -o parser.o parser.c
lex -Wl,-O1,--sort-common,--as-needed,-z,relro,--hash-style=gnu -t lexer.l > lexer.c
/usr/bin/flex: Unrecognized option `W'
Try `flex --help' for more information.
make[1]: *** [lexer.c] Error 1
make[1]: Leaving directory `/build/src/sipPy3/sipgen'
make: *** [all] Error 2
The only 'W' that could be causing the error is the LDFLAGS string
'-Wl,-O1,--sort-common,--as-needed,-z,relro,--hash-style=gnu', but that hasn't
caused a problem before so I just issue the build command again - and it builds
without issue - WTF?
Looking at the lex command above I see:
lex -Wl,-O1,--sort-common,--as-needed,-z,relro,--hash-style=gnu -t lexer.l > lexer.c
That doesn't seem right. I don't know lex from fred, passing 'lex ${LDFLAGS}
-t lexer.l > lexer.c' doesn't seem right because there is no
'-Wl,-O1,--sort-common,--as-needed,-z,relro,--hash-style=gnu' c syntax that I
know of :)
Has anyone else seen this spurious behavior? I kills rebuilds when it causes
sip build failures
I haven't changed a thing, and I get different results.
The build is simple:
<snip>
cd ${srcdir}
## copy source for Python build
cp -r ${pkgbase#*-} sipPy3
## Python version
msg "Running python configure.py (python3 based sip)...."
cd ${srcdir}/sipPy3
python configure.py CFLAGS="${CFLAGS}" LFLAGS="${LDFLAGS}"
msg "Building - tde-sip (python3 based sip)..."
make
## Python2 version
msg "Running python2 configure.py (sip4-tqt)...."
cd ${srcdir}/${pkgbase#*-}
python2 configure.py CFLAGS="${CFLAGS}" LFLAGS="${LDFLAGS}"
msg "Building - ${pkgbase}..."
make
}
Any thoughts?
--
David C. Rankin, J.D.,P.E.
Tim, All,
Do we want to flag packages that still have old build files in them? Look at
kima - it still has somebody's old config.log in the kima dir. Etherpad issue?
--
David C. Rankin, J.D.,P.E.
Tim, Slavek
tsak/tdmtsak are still broken and taking almost 100% of the cpu when TDM is
used as the login manager. This is with 'todays' (03/29) build from the GIT tree:
http://www.3111skyline.com/dl/dt/trinity/ss/tsak-96-cpu.jpg
I thought this was fixed??
--
David C. Rankin, J.D.,P.E.