> 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