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
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
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
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...
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.
Tim
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
On 21 January 2012 20:17, Darrell Anderson humanreadable@yahoo.com wrote:
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
What function does tdebindings serve? Does anyone actually utilize the language bindings?
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
On 21 January 2012 22:41, Darrell Anderson humanreadable@yahoo.com wrote:
What function does tdebindings serve? Does anyone actually utilize the language bindings?
Primary function is to frustrate packagers and developers. :)
LOL
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
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
On Sat, 21 Jan 2012 20:15:24 -0800 (PST) Darrell Anderson humanreadable@yahoo.com wrote:
Calvin Morrison mutantturkey@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.
On 22 January 2012 08:17, E. Liddell ejlddll@googlemail.com wrote:
On Sat, 21 Jan 2012 20:15:24 -0800 (PST) Darrell Anderson humanreadable@yahoo.com wrote:
Calvin Morrison mutantturkey@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.
A few milliseconds being executed often enough slows you down.
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
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).
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:
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".
On Sun, 22 Jan 2012 11:31:20 -0500 Calvin Morrison mutantturkey@gmail.com wrote:
On 22 January 2012 08:17, E. Liddell ejlddll@googlemail.com wrote:
On Sat, 21 Jan 2012 20:15:24 -0800 (PST) Darrell Anderson humanreadable@yahoo.com wrote:
Calvin Morrison mutantturkey@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.
A few milliseconds being executed often enough slows you down.
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.
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).
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.
My real quarrel is this:
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".
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.
On 22 January 2012 13:02, E. Liddell ejlddll@googlemail.com wrote:
On Sun, 22 Jan 2012 11:31:20 -0500 Calvin Morrison mutantturkey@gmail.com wrote:
On 22 January 2012 08:17, E. Liddell ejlddll@googlemail.com wrote:
On Sat, 21 Jan 2012 20:15:24 -0800 (PST) Darrell Anderson humanreadable@yahoo.com wrote:
Calvin Morrison mutantturkey@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.
A few milliseconds being executed often enough slows you down.
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.
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).
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.
My real quarrel is this:
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".
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?
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.
-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
-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?
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
On 22 January 2012 13:54, Darrell Anderson humanreadable@yahoo.com wrote:
-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?
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@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@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.
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.
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
On 22 January 2012 14:00, Darrell Anderson humanreadable@yahoo.com wrote:
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.
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...
On 22 January 2012 14:06, Calvin Morrison mutantturkey@gmail.com wrote:
On 22 January 2012 14:00, Darrell Anderson humanreadable@yahoo.com wrote:
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.
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.
On Sun, Jan 22, 2012 at 1:00 PM, Darrell Anderson humanreadable@yahoo.com wrote:
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.
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@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@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.
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
On Mon, Jan 23, 2012 at 11:35 AM, Werner Joss werner@hoernerfranzracing.de wrote:
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
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@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
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
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.
I can see the usefulness of kommander scripts, but the specific scripts I have in mind are written in Python with GTK GUI hooks. I don't want to rewrite the base Python code. I want only to convert the GTK hooks to TQt3 to work with Trinity.
Darrell
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?
Here is a complete list:
dcopc dcopjava dcopperl dcoppython kalyptus kdejava kjsembed korundum python qtjava qtruby qtsharp smoke xparts
-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
On Sun, 22 Jan 2012 10:48:36 -0800 (PST) Darrell Anderson humanreadable@yahoo.com wrote:
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?
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.
-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.
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).
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.
On 22 January 2012 14:52, E. Liddell ejlddll@googlemail.com wrote:
On Sun, 22 Jan 2012 10:48:36 -0800 (PST) Darrell Anderson humanreadable@yahoo.com wrote:
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?
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.
-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.
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).
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.
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 :)
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
On Sunday 22 January 2012 01:21:42 pm Darrell Anderson wrote:
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.
+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.
On 22 January 2012 16:44, Baho Utot baho-utot@columbus.rr.com wrote:
On Sunday 22 January 2012 01:21:42 pm Darrell Anderson wrote:
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.
+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
On Sun, 22 Jan 2012 16:56:11 -0500 Calvin Morrison mutantturkey@gmail.com wrote:
On 22 January 2012 16:44, Baho Utot baho-utot@columbus.rr.com wrote:
On Sunday 22 January 2012 01:21:42 pm Darrell Anderson wrote:
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.
+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.
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.
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.)
-
Baho Utot -
Calvin Morrison -
Christopher J Kleinschmidt -
Darrell Anderson -
E. Liddell -
Timothy Pearson -
Werner Joss