21 Jan
2012
21 Jan
'12
11:09 p.m.
Nothing I do gets tedbindings to build. :(
GIT 2805.
In the build log I notice this message, which does not appear in any other build log:
Note (probably harmless): No library found for -ltqt-mt
Has tdebindings been configured to build only with tqt3 rather than both tqt3 and qt3?
Error messages look like this:
In file included from DCOP.xs:35:
/opt/trinity/include/dcopclient.h:26:22: error: tqobject.h: No such file or directory
/opt/trinity/include/dcopclient.h:27:23: error: tqcstring.h: No such file or directory
/opt/trinity/include/dcopclient.h:28:25: error: tqvaluelist.h: No such file or directory
/opt/trinity/include/dcopclient.h:29:22: error: tqstring.h: No such file or directory
In file included from /opt/trinity/include/dcopclient.h:30,
Thanks!
Darrell
21 Jan
21 Jan
11:54 p.m.
New subject: [trinity-devel] tdebindings FTBFS (Broke, broke, broke!)
Nothing I do gets tedbindings to build. :(
GIT 2805.
In the build log I notice this message, which does not appear in any other
build log:
Note (probably harmless): No library found for -ltqt-mt
Has tdebindings been configured to build only with tqt3 rather than both
tqt3 and qt3?
Quite possible. tdebindings is the worst package out of the whole TDE
set, the build system is antiquated and broken, and there is a lot of
programming by original KDE gurus in languages that I am frankly not
familiar with. ;-)
That said, I wonder what would happen if you set your CXXFLAGS/CFLAGS to
include -I/usr/include/tqt
I am doing a rebuild test myself now, so we'll see what happens...
Tim
22 Jan
22 Jan
1:06 a.m.
New subject: [trinity-devel] tdebindings FTBFS (Broke, broke, broke!)
Quite possible. tdebindings is the worst package out
of the whole TDE
set, the build system is antiquated and broken, and there
is a lot of
programming by original KDE gurus in languages that I am
frankly not
familiar with. ;-)
Yeah, I know, tdebindings is a monster, but I built the package in 3.5.13. :(
That said, I wonder what would happen if you set your
CXXFLAGS/CFLAGS to
include -I/usr/include/tqt
I am doing a rebuild test myself now, so we'll see what
happens...
Tried that just now. No change here.
I've tried several different combinations of the DO_NOT_COMPILE variable. Every module
breaks.
Here is the failure with DO_NOT_COMPILE="dcopc dcopjava dcopperl dcoppython
kjsembed":
TQPixmap.cpp:349: error: 'class QPixmap' has no member named 'isTQBitmap'
make[4]: *** [TQPixmap.lo] Error 1
Here is the failure with DO_NOT_COMPILE="dcopc dcopjava dcopperl dcoppython kalyptus
kdejava kjsembed korundum":
TQPixmap.cpp: In function 'jboolean Java_org_kde_qt_QPixmap_isTQBitmap(JNIEnv*,
_jobject*)':
TQPixmap.cpp:349: error: 'class QPixmap' has no member named 'isTQBitmap'
make[4]: *** [TQPixmap.lo] Error 1
Darrell
1:10 a.m.
New subject: [trinity-devel] tdebindings FTBFS (Broke, broke, broke!)
Quite
possible. tdebindings is the worst package out
of the whole TDE
set, the build system is antiquated and broken, and there
is a lot of
programming by original KDE gurus in languages that I am
frankly not
familiar with. ;-)
Yeah, I know, tdebindings is a monster, but I built the package in 3.5.13.
:(
> That said, I wonder what would happen if you set your
> CXXFLAGS/CFLAGS to
> include -I/usr/include/tqt
>
> I am doing a rebuild test myself now, so we'll see what
> happens...
1:17 a.m.
New subject: [trinity-devel] tdebindings FTBFS (Broke, broke, broke!)
Most likely tdebindings is broken for qt3, but it
works
fine with tqt3. I
personally have no desire to make it work with qt3--as it
is not possible
to use qt3 and qt4 together in the same program, running
TDE on qt3
(instead of tqt3) is a dead end.
I had a feeling that might be the answer. :)
I haven't been building with tqt3 because of the mess with TQT_INCLUDE_DIRS. Before
then tdelibs would not build when I used tqt3. Now that the TQT_INCLUDE_DIRS problem is
gone, I'll try building everything on tqt3.
Here we go again!
Darrell
3:05 a.m.
New subject: [trinity-devel] tdebindings FTBFS (Broke, broke, broke!)
On 21 January 2012 20:17, Darrell Anderson <humanreadable(a)yahoo.com> wrote:
What function does tdebindings serve? Does anyone actually utilize the
language bindings?
Most likely
tdebindings is broken for qt3, but it works
fine with tqt3. I
personally have no desire to make it work with qt3--as it
is not possible
to use qt3 and qt4 together in the same program, running
TDE on qt3
(instead of tqt3) is a dead end.
I had a feeling that might be the answer. :)
I haven't been building with tqt3 because of the mess with
TQT_INCLUDE_DIRS. Before then tdelibs would not build when I used tqt3. Now
that the TQT_INCLUDE_DIRS problem is gone, I'll try building everything on
tqt3.
Here we go again!
Darrell
3:41 a.m.
New subject: [trinity-devel] tdebindings FTBFS (Broke, broke, broke!)
What function does tdebindings serve? Does anyone
actually
utilize the language bindings?
Primary function is to frustrate packagers and developers. :)
After R14 there are some applets I want to convert to Trinity. They are written in Python
with GTK GUI. I would like to convert the GTK hooks to TQt3 to integrate the applets.
A really big project I would like to find volunteers to help is to port a C project coded
in GTK to TQt3. The underlying base program needs no change, just the GUI side.
I have a few shell scripts I would like to convert to Python so I can add a GUI. KDialog
is bearable for small shell scripts but the few scripts I have in mind are large scripts.
Adding a GUI with KDialog would be a mess and would not provide the full point-and-click
functionality I envision. Rewriting would be better and Python seems suited for that kind
of app.
In other words, I see usefulness from tdebindings.
I think (I hope) the problem with building is simply that Tim has moved on to TQt3 and I
need to build from that base rather than Qt3. I built kdebindings 3.5.13 although I needed
several patches (bug report 597).
tdebindings is one of those packages most people avoid building. As a team, if we want to
provide a quality product, we need to ensure tdebindings will build even when we
personally don't have a use. :)
Okay, I'm off my soap box now.
Darrell
3:49 a.m.
New subject: [trinity-devel] tdebindings FTBFS (Broke, broke, broke!)
On 21 January 2012 22:41, Darrell Anderson <humanreadable(a)yahoo.com> wrote:
LOL
What function
does tdebindings serve? Does anyone actually
utilize the language bindings?
Primary function is to frustrate packagers and developers. :)
After R14 there are some applets I want to convert to
Trinity. They are
written in Python with GTK GUI. I would like to convert the GTK hooks to
TQt3 to integrate the applets.
List please? I am intersted.
A really big project I would like to find volunteers to help is to port a
C project coded in GTK to TQt3. The underlying base program needs no
change, just the GUI side.
It doesn't worth that way. GTK is based on C and uses a fundamentally
different structure. All calls are done within Glib as well. This ranges
from the main loop to things like formatting string functions. A full
rewrite in C++ is required I think.
I have a few shell scripts I would like to convert to Python so I can add
a GUI. KDialog is bearable for small shell scripts but the few scripts I
have in mind are large scripts. Adding a GUI with KDialog would be a mess
and would not provide the full point-and-click functionality I envision.
Rewriting would be better and Python seems suited for that kind of app.
List?
In other words, I see usefulness from tdebindings.
Meh. I see it like this: it is unlikely that any new developer with develop
on the trinity platform with Python etc at this stage. Python and other
languages are slow anyway. I see weaning off them as a good thing.
tdebindings is one of those packages most people avoid
building. As a
team, if we want to provide a quality product, we need to ensure
tdebindings will build even when we personally don't have a use. :)
Unless we eliminate all need for it.
Okay, I'm off my soap box now.
Darrell
4:15 a.m.
New subject: [trinity-devel] tdebindings FTBFS (Broke, broke, broke!)
After R14 there are some applets I want to convert to
Trinity. They are written in Python with GTK GUI. I would
like to convert the GTK hooks to TQt3 to integrate the
applets.
List please? I am interested.
They are Slackware specific tools. They would not be appropriate for merging into the
Trinity repository. They are actively maintained and credit still belongs to those people.
I just want to add a Trinity look and feel.
A really big project I would like to find volunteers
to
help is to port a C project coded in GTK to TQt3. The
underlying base program needs no change, just the GUI side.
It doesn't worth that way. GTK is based on C and uses a
fundamentally different structure. All calls are done within
Glib as well. This ranges from the main loop to things like
formatting string functions. A full rewrite in C++ is
required I think.
Okay, now I know what I'm up against! Perhaps I'll start small and just try to
learn to integrate KDialog instead of that POS GTK uses. I'm still learning both
languages and will remain a newbie for a long time. My text books are always here on my
desk. Makes good reading waiting for Trinity packages to build, except when my head is
fried --- then I go watch a movie I recorded three months ago. Which is what I'm going
to do shortly. :)
I have a few shell scripts I would like to convert to
Python so I can add a GUI. KDialog is bearable for small
shell scripts but the few scripts I have in mind are large
scripts. Adding a GUI with KDialog would be a mess and would
not provide the full point-and-click functionality I
envision. Rewriting would be better and Python seems suited
for that kind of app.
List?
They are personal scripts but are related to my HTPC project
(http://humanreadable.nfshost.com/journal/index-htpc.htm). One script is for scheduling
recordings. The shell script works great for me and is fairly robust, but is not designed
for people who expect point-clicky. :)
In other words, I see usefulness from tdebindings.
Meh. I see it like this: it is unlikely that any new
developer with develop on the trinity platform with Python
etc at this stage. Python and other languages are slow
anyway. I see weaning off them as a good thing.
I'm listening if you have ideas. How would a person integrate other languages with
TQt3? Rewrite everything in C++? Probably not going to happen for many people. If the
bindings exist then I see more people being interested in adapting or integrating
scripts.
Slow compared to what? I'm learning Python right now too. I have learned that Python
has a built-in quasi compiler, that creates something called byte code. I'm no expert
in that kind of jargon, but Python will run faster than a pure interpreted language like
shell scripts. And everything I have read thus far indicates Python is not slow like
Java.
I am trying to use Deskzilla (Java). Like trying to ask an old dog on a hot summer day to
move across the porch. Just slow. I hope down the road we find time to get kbugbuster
rolling again. :)
There used to be kommander scripts, which are native to Trinity and support GUIs. I
haven't looked into whether those remain supported or palatable in Trinity.
tdebindings is one of those packages most people
avoid
building. As a team, if we want to provide a quality
product, we need to ensure tdebindings will build even when
we personally don't have a use. :)
Unless we eliminate all need for it.
True, but I think we still need to start building and testing all packages, not just those
we use. I know everybody has their own agenda, and everybody is busy, but building all
packages is something most of us can do if we already build a few. I use a master script
to build all of my packages. Start and go to bed, or watch a movie. :)
Darrell
1:17 p.m.
New subject: [trinity-devel] tdebindings FTBFS (Broke, broke, broke!)
On Sat, 21 Jan 2012 20:15:24 -0800 (PST)
Darrell Anderson <humanreadable(a)yahoo.com> wrote:
Calvin Morrison <mutantturkey(a)gmail.com> wrote:
> In other words, I see usefulness from
tdebindings.
>
> Meh. I see it like this: it is unlikely that any new
> developer with develop on the trinity platform with Python
> etc at this stage. Python and other languages are slow
> anyway. I see weaning off them as a good thing.
Unless you're already good at C++, just about any other language is going to be
faster
to program in. Programmer time is more valuable than machine time these days for
the majority of applications--and for small- to medium-sized programs, no one is going
to notice the difference in execution speed between one and three milliseconds anyway.
If you love C++ and are good at it, that's fine, but don't try to impose your
preferences
on others. In return, I'll spare you my rants on why it's suboptimal. ;)
I'm listening if you have ideas. How would a
person integrate other languages with TQt3? Rewrite everything
in C++? Probably not going to happen for many people. If the bindings exist then I see
more people being
interested in adapting or integrating scripts.
I'm 98% sure that kdebindings is an integration package for kdelibs rather than QT3
(or at least, I know of other QT packages for Java. Perl, etc.) In theory, it should be
possible for a programmer who needs this stuff to rewrite a given set of bindings
using the target language's integration system, but my experience with doing things
like that suggests that it would be so painful that most just wouldn't bother.
Slow compared to what? I'm learning Python right
now too. I have learned that Python has a built-in
quasi compiler, that creates something called byte code. I'm no expert in that kind of
jargon, but Python
will run faster than a pure interpreted language like shell scripts. And everything I have
read thus far
indicates Python is not slow like Java.
Any interpreted language is going to be a bit slower than a compiled one because the
interpreter takes
time to start up (and bytecode is still interpreted, it's just interpreted faster).
I am trying to use Deskzilla (Java). Like trying to
ask an old dog on a hot summer day to move across
the porch. Just slow. I hope down the road we find time to get kbugbuster rolling again.
:)
Java is in a weird sort of situation: after the interpreter startup lag is discounted,
the core of the
language actually benchmarks quite well in terms of speed (better than compiled Pascal for
the
most part, and almost competitive with C/C++), but several of the libraries are abysmally
slow.
Unfortunately, Swing, the default GUI library, is one of those (and the default file IO
and
networking packages are no great shakes either). Result: a lot of very slow interactive
Java
programs, and an unfairly bad reputation for the language. (It also eats a lot of memory,
but
that's another story.)
That doesn't help you with Deskzilla unless you can convince its maintainers to
rewrite its
GUI portion using, say, Eclipse's SWT, though.
4:31 p.m.
New subject: [trinity-devel] tdebindings FTBFS (Broke, broke, broke!)
On 22 January 2012 08:17, E. Liddell <ejlddll(a)googlemail.com> wrote:
On Sat, 21 Jan 2012 20:15:24 -0800 (PST)
Darrell Anderson <humanreadable(a)yahoo.com> wrote:
A few milliseconds being executed often enough slows you down.
Calvin Morrison <mutantturkey(a)gmail.com>
wrote:
> In other words, I see usefulness from
tdebindings.
>
> Meh. I see it like this: it is unlikely that any new
> developer with develop on the trinity platform with Python
> etc at this stage. Python and other languages are slow
> anyway. I see weaning off them as a good thing.
Unless you're already good at C++, just about any other language is going
to be faster
to program in. Programmer time is more valuable than machine time these
days for
the majority of applications--and for small- to medium-sized programs, no
one is going
to notice the difference in execution speed between one and three
milliseconds anyway.
If you love C++ and are good at it, that's fine,
but don't try to impose
your preferences
on others. In return, I'll spare you my rants on why it's suboptimal. ;)
I do not even like C++.
- *Being really good at C++ is like being really good at using rocks to
sharpen sticks.* -- Thant Tessman
- *If you think C++ is not overly complicated, just what is a protected
abstract virtual base pure virtual private destructor and when was the last
time you needed one?* -- Tom Cargill
- *Oh, definitely. C++ may not be the worst programming language ever
created, but without a doubt it's the worst ever to be taken seriously. --
Mason Wheeler
- *C++ is to C as Lung Cancer is to Lung.*
I'm listening if you have ideas. How would a
person integrate other
languages with TQt3? Rewrite everything
Not to mention start up, but also the overhead. A simple python script can
take 10Mb of memory very easily.
My real quarrel is this:
in C++? Probably not going to happen for many
people. If the bindings
exist then I see more people being
interested in adapting or integrating scripts.
I'm 98% sure that kdebindings is an integration package for kdelibs rather
than QT3
(or at least, I know of other QT packages for Java. Perl, etc.) In
theory, it should be
possible for a programmer who needs this stuff to rewrite a given set of
bindings
using the target language's integration system, but my experience with
doing things
like that suggests that it would be so painful that most just wouldn't
bother.
Slow compared to what? I'm learning Python
right now too. I have learned
that Python has a built-in
quasi compiler, that creates something called byte
code. I'm no expert in
that kind of jargon, but Python
will run faster than a pure interpreted language
like shell scripts. And
everything I have read thus far
indicates Python is not slow like Java.
Any interpreted language is going to be a bit slower than a compiled one
because the interpreter takes
time to start up (and bytecode is still interpreted, it's just interpreted
faster).
tdebindings is one of those packages most people
avoid
building. As a team, if we want to provide a quality
product, we need to ensure tdebindings will build even when
we personally don't have a use. :)
HOW CAN WE BUILD A QUALITY PRODUCT IF NOBODY UNDERSTANDS IT. Tim even
mentioned he won't mess with it because he doesn't use those languages. I
think we have to be kidding ourselves if we are trying to provide a
"quality product".
6:02 p.m.
New subject: [trinity-devel] tdebindings FTBFS (Broke, broke, broke!)
On Sun, 22 Jan 2012 11:31:20 -0500
Calvin Morrison <mutantturkey(a)gmail.com> wrote:
Not to mention start up, but also the overhead. A simple python script can
take 10Mb of memory very easily.
This is another thing which is going to vary in importance depending on
the individual user and their hardware . . . but language wars are about
as profitable as OS wars, really.
On 22 January 2012 08:17, E. Liddell
<ejlddll(a)googlemail.com> wrote:
Relevant only for those programs in which execution takes place
"often enough". I did specify "small and medium-sized programs"
for a reason--for something as large as Trinity, C++ is a perfectly
reasonable choice of implementation language.
On Sat, 21 Jan 2012 20:15:24 -0800 (PST)
Darrell Anderson <humanreadable(a)yahoo.com> wrote:
A few milliseconds being executed often enough slows you down. Calvin Morrison <mutantturkey(a)gmail.com>
wrote:
> In other words, I see usefulness from
tdebindings.
>
> Meh. I see it like this: it is unlikely that any new
> developer with develop on the trinity platform with Python
> etc at this stage. Python and other languages are slow
> anyway. I see weaning off them as a good thing.
Unless you're already good at C++, just about any other language is going
to be faster
to program in. Programmer time is more valuable than machine time these
days for
the majority of applications--and for small- to medium-sized programs, no
one is going
to notice the difference in execution speed between one and three
milliseconds anyway.
Slow compared to what? I'm learning Python right
now too. I have learned
that Python has a built-in
quasi compiler, that creates something called byte
code. I'm no expert in
that kind of jargon, but Python
will run faster than a pure interpreted language
like shell scripts. And
everything I have read thus far
indicates Python is not slow like Java.
Any interpreted language is going to be a bit slower than a compiled one
because the interpreter takes
time to start up (and bytecode is still interpreted, it's just interpreted
faster).
My real quarrel is this:
Seems to me that we need to start by finding the answers to these questions:
-Which languages are involved? Looking at the source in GIT, I think I see
Java, Perl, Python, C#, C, Ruby, XPart (whatever that is), and Javascript,
plus some other stuff (written mostly in Perl) that appears to be
autogeneration/framework code for C# and Java. Does anyone see
anything that I may have missed or be misinterpreting?
-Which of these languages do we have potential maintainers for?
-Which of these bindings have actually been used for creating software?
Frex, Amarok has a Ruby dependency--will we need this interface to
maintain/further develop it?
-If there are bindings which have never been used, can we safely drop
them? My instinct is that most of them can probably be dumped if they
were never used, but it would be nice to keep one set (probably Python)
for those who want to code small interface modules for personal use
without dipping into the morass of C++.
-The autogeneration code for Java/C# represents a special problem if
we want to keep those modules. My Perl is good enough for me to
be able to tell that this code contains a morass of QT- and KDE-related
classnames that probably come from the shared libraries. This needs
attention from someone who knows Perl-XS *and* C++ *and* at
least one of the target languages to update it to TQT/TDE--pure Perl
code I might volunteer to handle, but the interface code used by
Smoke is beyond my skills.
-If, after all that, we have modules that we want/need to keep, and no
maintainers, where do we go about looking for them? That is, where
are the active communities for the relevant languages? For Python I
expect the community centers around python.org, and for Perl I would
probably try perlmonks, but I haven't been much involved with Java
since before the Oracle buy-out, and have no familiarity at all with
the other languages. Even if we decide that maintaining bindings for
a given language is not important, it might be nice to give the relevant
community a heads-up and see if anyone steps forward.
tdebindings is one of those packages most people
avoid
building. As a team, if we want to provide a quality
product, we need to ensure tdebindings will build even when
we personally don't have a use. :)
HOW CAN WE BUILD A QUALITY PRODUCT IF NOBODY UNDERSTANDS IT. Tim even
mentioned he won't mess with it because he doesn't use those languages. I
think we have to be kidding ourselves if we are trying to provide a
"quality product".
6:26 p.m.
New subject: [trinity-devel] tdebindings FTBFS (Broke, broke, broke!)
On 22 January 2012 13:02, E. Liddell <ejlddll(a)googlemail.com> wrote:
On Sun, 22 Jan 2012 11:31:20 -0500
Calvin Morrison <mutantturkey(a)gmail.com> wrote:
Not to mention start up, but also the overhead. A simple python script can
take 10Mb of memory very easily.
This is another thing which is going to vary in importance depending on
the individual user and their hardware . . . but language wars are about
as profitable as OS wars, really.
I think XPart allows you to embed any X11 window using the xlib
embedding calls, with the Kparts API.
As for C#:
"Qt# was an attempt to create a set of classes that bind the C#
language to the Qt toolkit. The bindings appear abandoned based on the
Qt# home page."
It's clearly abandoned. Do any of our applications utilize it? I
always had a thing against .NET on Linux. it never felt right.
On 22 January 2012 08:17, E. Liddell
<ejlddll(a)googlemail.com> wrote:
Relevant only for those programs in which execution takes place
"often enough". I did specify "small and medium-sized programs"
for a reason--for something as large as Trinity, C++ is a perfectly
reasonable choice of implementation language.
On Sat, 21 Jan 2012 20:15:24 -0800 (PST)
Darrell Anderson <humanreadable(a)yahoo.com> wrote:
A few milliseconds being executed often enough slows you down. Calvin Morrison <mutantturkey(a)gmail.com>
wrote:
> In other words, I see usefulness from
tdebindings.
>
> Meh. I see it like this: it is unlikely that any new
> developer with develop on the trinity platform with Python
> etc at this stage. Python and other languages are slow
> anyway. I see weaning off them as a good thing.
Unless you're already good at C++, just about any other language is going
to be faster
to program in. Programmer time is more valuable than machine time these
days for
the majority of applications--and for small- to medium-sized programs, no
one is going
to notice the difference in execution speed between one and three
milliseconds anyway.
Slow compared to what? I'm learning Python right
now too. I have learned
that Python has a built-in
quasi compiler, that creates something called byte
code. I'm no expert in
that kind of jargon, but Python
will run faster than a pure interpreted language
like shell scripts. And
everything I have read thus far
indicates Python is not slow like Java.
Any interpreted language is going to be a bit slower than a compiled one
because the interpreter takes
time to start up (and bytecode is still interpreted, it's just interpreted
faster).
My real quarrel is this:
Seems to me that we need to start by finding the answers to these questions:
-Which languages are involved? Looking at the source in GIT, I think I see
Java, Perl, Python, C#, C, Ruby, XPart (whatever that is), and Javascript,
plus some other stuff (written mostly in Perl) that appears to be
autogeneration/framework code for C# and Java. Does anyone see
anything that I may have missed or be misinterpreting? tdebindings is one of those packages most people
avoid
building. As a team, if we want to provide a quality
product, we need to ensure tdebindings will build even when
we personally don't have a use. :)
HOW CAN WE BUILD A QUALITY PRODUCT IF NOBODY UNDERSTANDS IT. Tim even
mentioned he won't mess with it because he doesn't use those languages. I
think we have to be kidding ourselves if we are trying to provide a
"quality product".
-Which of these languages do we have potential maintainers for?
-Which of these bindings have actually been used for creating software?
Frex, Amarok has a Ruby dependency--will we need this interface to
maintain/further develop it?
Amarok uses Ruby for extra things, like the scripting. This is a good
thing as I see it.
-If there are bindings which have never been used, can
we safely drop
them? My instinct is that most of them can probably be dumped if they
were never used, but it would be nice to keep one set (probably Python)
for those who want to code small interface modules for personal use
without dipping into the morass of C++.
I think this is the real question. Is anyone going to throw their
hands in the air and yell if we drop it? Keeping it in the archives is
fine if someone wanted to pick it up later. But aren't there bigger
fish to fry?
Calvin
6:54 p.m.
New subject: [trinity-devel] tdebindings FTBFS (Broke, broke, broke!)
-If there are
bindings which have never been used, can
we safely drop
them? My instinct is that most of them can
probably be dumped if they
were never used, but it would be nice to keep
one
set (probably Python)
for those who want to code small interface
modules
for personal use
without dipping into the morass of C++.
I think this is the real question. Is anyone going to throw
their
hands in the air and yell if we drop it? Keeping it in the
archives is
fine if someone wanted to pick it up later. But aren't
there bigger
fish to fry?
6:55 p.m.
New subject: [trinity-devel] tdebindings FTBFS (Broke, broke, broke!)
On 22 January 2012 13:54, Darrell Anderson <humanreadable(a)yahoo.com> wrote:
That is a good point. If we archive the package I think we first should ensure we can
build the package in several distros now with R14 before putting on the shelf. That way we
know we had something buildable at that day we walked away.
With that said, I want to raise a simple question. I don't know therefore I'm not
being rhetorical. :) I mentioned I have a few applets I want to massage for Trinity. Those
applets are written in Python with a GTK GUI. I want a Trinity/TQt3 GUI. How do I do that
without tdebindings?
Darrell
---------------------------------------------------------------------
To unsubscribe, e-mail: trinity-devel-unsubscribe(a)lists.pearsoncomputing.net
For additional commands, e-mail: trinity-devel-help(a)lists.pearsoncomputing.net
Read list messsages on the Web archive: http://trinity-devel.pearsoncomputing.net/
Please remember not to top-post:
http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
kdialog is what you want.
-If there are bindings which have never been used, can
we safely drop
them? My instinct is that most of them can
probably be dumped if they
were never used, but it would be nice to keep
one
set (probably Python)
for those who want to code small interface
modules
for personal use
without dipping into the morass of C++.
I think this is the real question. Is anyone going to throw
their
hands in the air and yell if we drop it? Keeping it in the
archives is
fine if someone wanted to pick it up later. But aren't
there bigger
fish to fry?
7 p.m.
New subject: [trinity-devel] tdebindings FTBFS (Broke, broke, broke!)
With that
said, I want to raise a simple question. I
don't know therefore I'm not
being rhetorical. :) I
mentioned I have a few applets I want to massage for
Trinity. Those applets are written in Python with a GTK GUI.
I want a Trinity/TQt3 GUI. How do I do that without
tdebindings?
kdialog is what you want.
7:06 p.m.
New subject: [trinity-devel] tdebindings FTBFS (Broke, broke, broke!)
On 22 January 2012 14:00, Darrell Anderson <humanreadable(a)yahoo.com> wrote:
Are you sure? KDialog is rather simplistic. I want to add some nice widgets, like the
calendar widget used in KAlarm. I want to add nice drop-down pick lists. I don't
KDialog can do that kind of magic.
Darrell
Nope.
It would be able to use kparts with kdialog though...
With that said, I want to raise a simple question. I
don't know therefore I'm not being rhetorical. :) I
mentioned I have a few applets I want to massage for
Trinity. Those applets are written in Python with a GTK GUI.
I want a Trinity/TQt3 GUI. How do I do that without
tdebindings?
kdialog is what you want.
7:40 p.m.
New subject: [trinity-devel] tdebindings FTBFS (Broke, broke, broke!)
On 22 January 2012 14:06, Calvin Morrison <mutantturkey(a)gmail.com> wrote:
On 22 January 2012 14:00, Darrell Anderson
<humanreadable(a)yahoo.com> wrote:
Are you sure? KDialog is rather simplistic. I want to add some nice widgets, like the
calendar widget used in KAlarm. I want to add nice drop-down pick lists. I don't
KDialog can do that kind of magic.
Darrell
Nope.
It would be able to use kparts with kdialog though...
it would be COOL to be able to use it. that's what I meant. you can't
actually do that. yet.
With that said, I want to raise a simple question. I
don't know therefore I'm not being rhetorical. :) I
mentioned I have a few applets I want to massage for
Trinity. Those applets are written in Python with a GTK GUI.
I want a Trinity/TQt3 GUI. How do I do that without
tdebindings?
kdialog is what you want. 
23 Jan
23 Jan
5:28 p.m.
New subject: [trinity-devel] tdebindings FTBFS (Broke, broke, broke!)
On Sun, Jan 22, 2012 at 1:00 PM, Darrell Anderson
<humanreadable(a)yahoo.com> wrote:
Are you sure? KDialog is rather simplistic. I want to add some nice widgets, like the
calendar widget used in KAlarm. I want to add nice drop-down pick lists. I don't
KDialog can do that kind of magic.
Darrell
---------------------------------------------------------------------
To unsubscribe, e-mail: trinity-devel-unsubscribe(a)lists.pearsoncomputing.net
For additional commands, e-mail: trinity-devel-help(a)lists.pearsoncomputing.net
Read list messsages on the Web archive: http://trinity-devel.pearsoncomputing.net/
Please remember not to top-post:
http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
Kommander would have been useful to you, but it's broken. I don't know
what the trinity plan for it is. It was a while ago that I tried to
use it, but I seem to remember something with qt -> tqt conversion
broke it.
With that said, I want to raise a simple question. I
don't know therefore I'm not being rhetorical. :) I
mentioned I have a few applets I want to massage for
Trinity. Those applets are written in Python with a GTK GUI.
I want a Trinity/TQt3 GUI. How do I do that without
tdebindings?
kdialog is what you want. 
5:35 p.m.
New subject: [trinity-devel] tdebindings FTBFS (Broke, broke, broke!)
On Monday 23 January 2012 18:28:12 Christopher J Kleinschmidt wrote:
Kommander would have been useful to you, but it's
broken. I don't know
what the trinity plan for it is. It was a while ago that I tried to
use it, but I seem to remember something with qt -> tqt conversion
broke it.
hm,
I can still use my (simple) kommander scripts here with kmdr-executor from
trinity 3.5.13
werner
8:37 p.m.
New subject: [trinity-devel] tdebindings FTBFS (Broke, broke, broke!)
On Mon, Jan 23, 2012 at 11:35 AM, Werner Joss
<werner(a)hoernerfranzracing.de> wrote:
On Monday 23 January 2012 18:28:12 Christopher J
Kleinschmidt wrote:
Maybe it was just the editor, been too long. Anyway, Darrell, that
might be an option for more than kdialog if what Werner says is true.
Kommander would have been useful to you, but
it's broken. I don't know
what the trinity plan for it is. It was a while ago that I tried to
use it, but I seem to remember something with qt -> tqt conversion
broke it.
hm,
I can still use my (simple) kommander scripts here with kmdr-executor from
trinity 3.5.13
werner
---------------------------------------------------------------------
To unsubscribe, e-mail: trinity-devel-unsubscribe(a)lists.pearsoncomputing.net
For additional commands, e-mail: trinity-devel-help(a)lists.pearsoncomputing.net
Read list messsages on the Web archive: http://trinity-devel.pearsoncomputing.net/
Please remember not to top-post:
http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
8:56 p.m.
New subject: [trinity-devel] tdebindings FTBFS (Broke, broke, broke!)
> Kommander
would have been useful to you, but it's
broken. I don't know
> what the trinity plan for it is. It was a
while
ago that I tried to
> use it, but I seem to remember something with
qt
-> tqt conversion
broke it.
hm,
I can still use my (simple) kommander scripts here trinity 3.5.13
Maybe it was just the editor, been too long. Anyway,
Darrell, that
might be an option for more than kdialog if what Werner
says is true.
22 Jan
22 Jan
6:48 p.m.
New subject: [trinity-devel] tdebindings FTBFS (Broke, broke, broke!)
HOW CAN WE
BUILD A QUALITY PRODUCT IF NOBODY
UNDERSTANDS IT. Tim even
mentioned he won't mess with it because he
doesn't use
those languages. I
think we have to be kidding ourselves if we are
trying
to provide a
"quality product".
Seems to me that we need to start by finding the answers to
these questions:
-Which languages are involved? Looking at the source
in GIT, I think I see
Java, Perl, Python, C#, C, Ruby, XPart (whatever
that is), and Javascript,
plus some other stuff (written mostly in Perl) that
appears to be
autogeneration/framework code for C# and Java. Does
anyone see
anything that I may have missed or be misinterpreting? -Which of these languages do we have potential
maintainers
for?
-Which of these bindings have actually been used for
creating software?
Frex, Amarok has a Ruby dependency--will we need this
interface to
maintain/further develop it?
I'm not qualified to make decisions. I can only offer that Java, JavaScript, Perl,
Python, and Ruby are popular and not going away any time soon. DCop is important to
controlling Trinity apps from external apps and scripts.
To me, the important question is not which bindings to maintain but compiling the package.
If somebody wants to use their favorite language to hook into Trinity, let them have fun.
Right now the big issue is why compiling is such torture. Seems right now I'm the only
person trying. :)
-If there are bindings which have never been used, can
we
safely drop
them? My instinct is that most of them can probably
be dumped if they
were never used, but it would be nice to keep one set
(probably Python)
for those who want to code small interface modules for
personal use
without dipping into the morass of C++.
Somebody who has a clue about these things could help by surfing the web looking for
examples of how other people used these bindings. Possibly start at kde-look.org for
apps?
-If, after all that, we have modules that we want/need
to
keep, and no
maintainers, where do we go about looking for them?
That is, where
are the active communities for the relevant
languages? For Python I
expect the community centers around python.org, and for
Perl I would
probably try perlmonks, but I haven't been much involved
with Java
since before the Oracle buy-out, and have no familiarity
at all with
the other languages. Even if we decide that
maintaining bindings for
a given language is not important, it might be nice to
give the relevant
community a heads-up and see if anyone steps forward.
As many people have led themselves to believe Qt3 is dead, we might learn more about who
is supporting the bindings atmosphere by looking around as to what others are doing with
KDE4/Qt4. If we find nobody coding anything with a certain language binding, then we can
be reasonably sure nobody cares about doing likewise in Trinity.
Darrell
7:52 p.m.
New subject: [trinity-devel] tdebindings FTBFS (Broke, broke, broke!)
On Sun, 22 Jan 2012 10:48:36 -0800 (PST)
Darrell Anderson <humanreadable(a)yahoo.com> wrote:
Here is a complete list:
dcopc
dcopjava
dcopperl
dcoppython
kalyptus
kdejava
kjsembed
korundum
python
qtjava
qtruby
qtsharp
smoke
xparts
smoke and kalyptus are the Java/C# generating code, and korundum seems
to be part of the Ruby binding, FWIW.
Perl is less popular than it once was, and Java programmers generally aren't big on
using
platform-specific interface modules (it's counter to the philosophy of the language).
HOW CAN WE BUILD A QUALITY PRODUCT IF NOBODY
UNDERSTANDS IT. Tim even
mentioned he won't mess with it because he
doesn't use
those languages. I
think we have to be kidding ourselves if we are
trying
to provide a
"quality product".
Seems to me that we need to start by finding the answers to
these questions:
-Which languages are involved? Looking at the source
in GIT, I think I see
Java, Perl, Python, C#, C, Ruby, XPart (whatever
that is), and Javascript,
plus some other stuff (written mostly in Perl) that
appears to be
autogeneration/framework code for C# and Java. Does
anyone see
anything that I may have missed or be misinterpreting? -Which of
these languages do we have potential maintainers
for?
-Which of these bindings have actually been used for
creating software?
Frex, Amarok has a Ruby dependency--will we need this
interface to
maintain/further develop it?
I'm not qualified to make decisions. I can only offer that Java, JavaScript, Perl,
Python, and
Ruby are popular and not going away any time soon. DCop is important to controlling
Trinity
apps from external apps and scripts. To me, the important question is not which bindings to
maintain but compiling the package.
If somebody wants to use their favorite language to hook into Trinity, let them have fun.
Right now the big issue is why compiling is such torture. Seems right now I'm the only
person trying. :)
Oh, ouch. I just looked at the KDE 3.5.10 ebuild for kdebindings and found this:
# Broken and package.masked.
# ~kde-base/korundum-$PV
# ~kde-base/qtruby-$PV
# Omitted: qtsharp, dcopc, dcopjava, xparts (considered broken by upstream)
So the bulk of the code was broken pre-Trinity and likely was never fixed,
which could explain why it isn't compiling now.
Furthermore, if those bindings have been broken for that long and no one
has complained, chances are that no code ever used them (or if anything
did, it's long since migrated elsewhere).
Python, Perl, Javascript, and the non-dcop parts of the Java binding might
still work, but we need to either fix or kick the remainder. Right now, I'm
leaning towards "kick", and it seems like most of the other people who've
weighed in do, too.
Given the manpower available and the general breakage level, I really do
think that focusing any effort that can be spared on the Python binding and
dumping the rest if/when they break (unless a brave volunteer steps up) is
likely the best way to go.
8:51 p.m.
New subject: [trinity-devel] tdebindings FTBFS (Broke, broke, broke!)
On 22 January 2012 14:52, E. Liddell <ejlddll(a)googlemail.com> wrote:
On Sun, 22 Jan 2012 10:48:36 -0800 (PST)
Darrell Anderson <humanreadable(a)yahoo.com> wrote:
Here is a complete list:
dcopc
dcopjava
dcopperl
dcoppython
kalyptus
kdejava
kjsembed
korundum
python
qtjava
qtruby
qtsharp
smoke
xparts
smoke and kalyptus are the Java/C# generating code, and korundum seems
to be part of the Ruby binding, FWIW.
Perl is less popular than it once was, and Java programmers generally aren't big on
using
platform-specific interface modules (it's counter to the philosophy of the
language).
It seems in the past that more were available. Objective C and C were
also available as of 3.2.3
http://websvn.kde.org/tags/KDE/3.2.3/kdebindings/
If anything I'd like to reinstate QtC :)
HOW CAN WE BUILD A QUALITY PRODUCT IF NOBODY
UNDERSTANDS IT. Tim even
mentioned he won't mess with it because he
doesn't use
those languages. I
think we have to be kidding ourselves if we are
trying
to provide a
"quality product".
Seems to me that we need to start by finding the answers to
these questions:
-Which languages are involved? Looking at the source
in GIT, I think I see
Java, Perl, Python, C#, C, Ruby, XPart (whatever
that is), and Javascript,
plus some other stuff (written mostly in Perl) that
appears to be
autogeneration/framework code for C# and Java. Does
anyone see
anything that I may have missed or be misinterpreting? -Which of
these languages do we have potential maintainers
for?
-Which of these bindings have actually been used for
creating software?
Frex, Amarok has a Ruby dependency--will we need this
interface to
maintain/further develop it?
I'm not qualified to make decisions. I can only offer that Java, JavaScript, Perl,
Python, and
Ruby are popular and not going away any time soon. DCop is important to controlling
Trinity
apps from external apps and scripts. To me, the important question is not which
bindings to maintain but compiling the package.
If somebody wants to use their favorite language to hook into Trinity, let them have fun.
Right now the big issue is why compiling is such torture. Seems right now I'm the
only
person trying. :)
Oh, ouch. I just looked at the KDE 3.5.10 ebuild for kdebindings and found this:
# Broken and package.masked.
# ~kde-base/korundum-$PV
# ~kde-base/qtruby-$PV
# Omitted: qtsharp, dcopc, dcopjava, xparts (considered broken by upstream)
So the bulk of the code was broken pre-Trinity and likely was never fixed,
which could explain why it isn't compiling now.
Furthermore, if those bindings have been broken for that long and no one
has complained, chances are that no code ever used them (or if anything
did, it's long since migrated elsewhere).
Python, Perl, Javascript, and the non-dcop parts of the Java binding might
still work, but we need to either fix or kick the remainder. Right now, I'm
leaning towards "kick", and it seems like most of the other people who've
weighed in do, too.
Given the manpower available and the general breakage level, I really do
think that focusing any effort that can be spared on the Python binding and
dumping the rest if/when they break (unless a brave volunteer steps up) is
likely the best way to go.
6:21 p.m.
New subject: [trinity-devel] tdebindings FTBFS (Broke, broke, broke!)
Unless you're already good at C++, just about any
other
language is going to be faster
to program in. Programmer time is more valuable than
machine time these days for
the majority of applications--and for small- to
medium-sized programs, no one is going
to notice the difference in execution speed between one and
three milliseconds anyway.
A funny thing about speed. Possibly experienced coders see a difference whereas
every day users probably do not. Yet speed is relative. Often I have read how shell
scripts are slow. From a strict theoretical and design perspective, I am sure that is
true. In certain iterative tests, I'm sure shell scripts can be shown to be slower
than other scripting languages. Yet in my every day usage, and I have written a few long
shell scripts, I don't notice anything. I once read a person's comment that once a
shell script grows to beyond a few dozen lines that a person should move to Python or
Perl. Okay. Whatever.
I'm not arguing that if I was a whiz kid with experience with dozens of languages I
would not see a difference, or that a whiz kid can't whip up a script to show me the
difference. I likely would see a difference. I'm just saying that as a user with above
average knowledge and skills (but less than many hackers), the argument about speed is
relative and speculative.
I'm teaching myself C++, C, and Python. A slow process. C and Python are not so bad as
far as getting the hang of the syntax. C++ is esoteric. I'm not a computer science
major, just an every day user. I'm getting so I can wander about the Trinity code
without crying, but I still find C++ a weird language. Yes, there is a method to the
madness, but the method still seems mad. :)
I'm teaching myself C++ to help myself, which is to keep Trinity alive and well. I
don't expect to grow to a point where C++ goes on my resume. I just want to have a
partial clue. With respect to my own needs, other languages seem better suited for me. :)
I'm 98% sure that kdebindings is an integration
package for
kdelibs rather than QT3
(or at least, I know of other QT packages for Java. Perl,
etc.) In theory, it should be
possible for a programmer who needs this stuff to rewrite a
given set of bindings
using the target language's integration system, but my
experience with doing things
like that suggests that it would be so painful that most
just wouldn't bother.
The important question for me is when I want to write a small applet program to run in the
Trinity environment, I want to use Trinity dialogs to provide a native look and feel, and
I don't want to use C++, how do I approach that project? Which languages are good
choices? Seems to me a scripting language that has binding hooks into Trinity is an easy
way to go for a non coder, but I'm asking so I can learn.
That doesn't help you with Deskzilla unless you
can
convince its maintainers to rewrite its
GUI portion using, say, Eclipse's SWT, though.
The ideal solution is to get kbugbuster fixed. Then we can eat our own dog food. The web
is full of stories from the previous developers that kbugbuster is beyond repair, but I
also have seen that when developers want something new and shiny they say things like
that. The majority of people using the app are not qualified to judge those statements
because they don't know C++. I'm sure some sweat equity is required to change the
underlying interface from the old KDE bug reporting system to bugzilla, but I'm hoping
kbugbuster is not beyond repair.
Darrell
9:44 p.m.
New subject: [trinity-devel] tdebindings FTBFS (Broke, broke, broke!)
On Sunday 22 January 2012 01:21:42 pm Darrell Anderson wrote:
+1
Arch linux package manger make extensive use of bash. Have a look at makepkg
mkchroot and repo-add etc.
few dozen lines indeed ;)
I take it they have not seen my shell scripts :)
For system admin etc bash is great.
Unless
you're already good at C++, just about any other
language is going to be faster
to program in. Programmer time is more valuable than
machine time these days for
the majority of applications--and for small- to
medium-sized programs, no one is going
to notice the difference in execution speed between one and
three milliseconds anyway.
A funny thing about speed. Possibly experienced coders see a difference
whereas every day users probably do not. Yet speed is relative. Often I
have read how shell scripts are slow. From a strict theoretical and design
perspective, I am sure that is true. In certain iterative tests, I'm sure
shell scripts can be shown to be slower than other scripting languages. Yet
in my every day usage, and I have written a few long shell scripts, I don't
notice anything. I once read a person's comment that once a shell script
grows to beyond a few dozen lines that a person should move to Python or
Perl. Okay. Whatever.
9:56 p.m.
New subject: [trinity-devel] tdebindings FTBFS (Broke, broke, broke!)
On 22 January 2012 16:44, Baho Utot <baho-utot(a)columbus.rr.com> wrote:
On Sunday 22 January 2012 01:21:42 pm Darrell Anderson wrote:
+1
Arch linux package manger make extensive use of bash. Have a look at makepkg
mkchroot and repo-add etc.
few dozen lines indeed ;)
I take it they have not seen my shell scripts :)
For system admin etc bash is great.
We say that scripting is great, but it often causes a mess once it gets to big.
Ever worked on a project at a company and there is just one old perl
script that nobody dares touch? it's several thousand lines and is
hiding in some obscure folder. But every week a cron job runs this
script and things continue as normal.
Scripting needs to be watched carefully before it grows out of control
Unless
you're already good at C++, just about any other
language is going to be faster
to program in. Programmer time is more valuable than
machine time these days for
the majority of applications--and for small- to
medium-sized programs, no one is going
to notice the difference in execution speed between one and
three milliseconds anyway.
A funny thing about speed. Possibly experienced coders see a difference
whereas every day users probably do not. Yet speed is relative. Often I
have read how shell scripts are slow. From a strict theoretical and design
perspective, I am sure that is true. In certain iterative tests, I'm sure
shell scripts can be shown to be slower than other scripting languages. Yet
in my every day usage, and I have written a few long shell scripts, I don't
notice anything. I once read a person's comment that once a shell script
grows to beyond a few dozen lines that a person should move to Python or
Perl. Okay. Whatever.
10:21 p.m.
New subject: [trinity-devel] tdebindings FTBFS (Broke, broke, broke!)
On Sun, 22 Jan 2012 16:56:11 -0500
Calvin Morrison <mutantturkey(a)gmail.com> wrote:
On 22 January 2012 16:44, Baho Utot
<baho-utot(a)columbus.rr.com> wrote:
It's very easy to write bad Perl, though. (It's also possible, but more
difficult,
to write good Perl.) Structuring a script properly and maintainably is work,
but it can be done . . . just like structuring a compiled-language program
properly and maintainably. It's all code, and can be written the right way or
the wrong way.
On Sunday 22 January 2012 01:21:42 pm Darrell Anderson wrote:
+1
Arch linux package manger make extensive use of bash. Have a look at makepkg
mkchroot and repo-add etc.
few dozen lines indeed ;)
I take it they have not seen my shell scripts :)
For system admin etc bash is great.
We say that scripting is great, but it often causes a mess once it gets to big.
Ever worked on a project at a company and there is just one old perl
script that nobody dares touch? it's several thousand lines and is
hiding in some obscure folder. But every week a cron job runs this
script and things continue as normal. Unless
you're already good at C++, just about any other
language is going to be faster
to program in. Programmer time is more valuable than
machine time these days for
the majority of applications--and for small- to
medium-sized programs, no one is going
to notice the difference in execution speed between one and
three milliseconds anyway.
A funny thing about speed. Possibly experienced coders see a difference
whereas every day users probably do not. Yet speed is relative. Often I
have read how shell scripts are slow. From a strict theoretical and design
perspective, I am sure that is true. In certain iterative tests, I'm sure
shell scripts can be shown to be slower than other scripting languages. Yet
in my every day usage, and I have written a few long shell scripts, I don't
notice anything. I once read a person's comment that once a shell script
grows to beyond a few dozen lines that a person should move to Python or
Perl. Okay. Whatever. Scripting needs to be watched carefully before it
grows out of control
Nevertheless, scripting languages have their uses, and insisting that they never
be used is just as silly as insisting that they always be used.
(For what it's worth, Gentoo's package manager is written in Python, and
the "packages" are actually shell scripts . . . and I don't think I've
ever
run into a problem that was traceable specifically to a Portage bug in the
~6 years I've been with this distro.)
4693
days inactive
4695
days old
29 comments
7 participants
participants (7)
-
Baho Utot -
Calvin Morrison -
Christopher J Kleinschmidt -
Darrell Anderson -
E. Liddell -
Timothy Pearson -
Werner Joss