The 'kalyptus' bindings generation tool has a '-fperl' option to generate.pig (Perl Interface Generator) files. The.pig files can be then be fed straight into Ashley Winters' Pig.pm generator.
kalyptus is in the KDE cvs under kdebindings/kalyptus.
The main technical obstacle to producing Perl bindings for Qt 3/KDE 3 is that they assume that the moc generated code works like Qt 2. Qt used to call slots via function pointers, but in Qt 3 it uses an integer offset into the slot table.
So the slot/signal handling needs to be redone to get the Perl bindings to work.
And Common Lisp for Qt/KDE should certainly be possible.
"The idea is that it makes JNI calls to the base OS for the GUI, so it's fast."
But that doesn't make it cross-platform, it just means it's a fast Windows only thing. There is a huge amount of work involved in adding a higher level api on top of the JNI stuff, and ensuring that code will behave in an identical manner on every platform.
I believe Swing is 30% faster in JDK 1.4 because Sun ignore their own api internally and make use of Java's dynamic programming/reflection capabilities. Sun have tended to use Java as though it is a static language like a stripped down C++.
For example, why would you want to use a class called 'EventListerList':
"This utility class is use by many Swing classes to maintain lists of event listeners..."
Why do I want to maintain lists of event listeners, and forward events - isn't that the sort of thing the GUI toolkit is supposed to do?
Microsoft wanted to add delegates to Java, which seems perfectly sensible to me, as it would mean less subclassing. And I'm sure the event handling in.NET isn't a DIY kind of thing.
But it isn't cross-platform. They use Motif as a basis for Linux support - DOA surely?
Also SWT uses the AWT/Swing style of subclassing and managing event listeners, which is an incredibly clunky programming model. It doesn't make use of Java's dynamic programming capabilities at all. I much prefer Trolltech's Qt slots/signals for component based programming.
-- Richard Dale (obviously biased Qt/KDE Java bindings author)
The bindings aren't intended for coding directly in C. They are meant for implementing bindings for languages which can't call C++ directly such as PHP, Pascal or some Objective-C.
If Mac OS X wasn't based on Mach 3.0, it wouldn't have been possible to implement the Quartz window manager which depends on Mach's advanced ipc and shared memory features. So Linux, because of its limitations, will only have X or direct to framebuffer implementations, neither of which aren't as good.
-- Richard
Yes, it will be possible and in the KDE CVS in about a month - I'm working on C now (along with Objective-C/GNUstep Foundation kit bindings).
I've just recently checked in Java JNI based bindings for Qt and KDE. Please see the language bindings section on the KDE site. You need to check out the 'kdebindings' module from the KDE CVS to get the code.
Richard Dale, Lost Highway Ltd
Re:Here is the secret for staying in demand
on
Too Old To Code?
·
· Score: 2
> I'll dump Java whenever I see something that is even cooler
And what about open source programming techniques - CVS, patches, peer reviews, no managers etc? Surely much more revolutionary in its effect on the industry than Java. Biggest thing since Fred Brookes in my opinion.
How come Java is exciting compared with the ideas in Smalltalk-80 (20 years earlier)?
My tip for the next 'new new thing' - visual programming environments (cf son of Prograph).
I'm 43 - I agree it's a great time to be programming. I say Apple's forthcoming Mac OS X Objective-C/Cocoa/Mach 3.0 micorkernel may suit your tastes, apart from the lack of lambdas/closures/Smalltalk blocks or similar.
All the posts mention using a resume (CV) to get work. Resumes are very ageist. Getting work by having a portfolio of (preferably open source) software levels the playing field for older programmers. If the site is using the software tool or whatever that you just wrote, they're pretty likely to want to hire you.
Say what - check out 'kdkobjc-0.2.tar.gz' somewhere on gnustep.org - I put it there only today. Objective-C support for KDevelop 1.2, plus a start on a Qt/Objc api! Now who would bother to look at my resume? QED.
How about Pop-11 on a PDP-11/34 from a teletype in 1976? Pop-11: Lisp semantics, but with friendly Pascal-like syntax and interactive interpreter? I couldn't have had a better start..
James Lanfear wrote: > What does this have to do with my post? Nothing! I was attempting to reply to Espen: Espen wrote: > What matters is not the cost of the most expensive setup, but the cheapest one 'cause once you have a basic box you can populate it with standard component memory and drives as you see fit.
Both Yellow Dog and LinuxPPC distributions are based on Red Hat, so so they support Gnome better than KDE (quite a few KDE utlities are missing and so on). Suse should be better for those of us who prefer KDE over Gnome.
Why have a cheap badly designed beige box which needs fixing with screwdrivers, soldering irons tweaking IRQs etc, when you can have a cheap well designed iMac running LinuxPPC for less than $1000 (plus Contour Unimouse 3-button mouse for $30 or so)?
> KDE 2 will have a much better clipboard support - any data can be copied and pasted, it will be recognized by mimetype. That sounds really nice. Will it have more than one clipboard though, or still just use XA_PRIMARY? I can't find XA_SECONDARY used for anything - what about nominating that as a clipboard for search text? Copy and paste on a typical KDE app doesn't behave the way a Mac/Wiindows/NeXT user would expect. For instance, if you open a text file with kwrite. Select some text, then choose the copy command from the menu. Then scroll down the file a bit and select some more text. Then choose paste from the Edit menu. Ask a Mac user whether they thought the text in the file will have been changed and they will say "yes", but a KDE user will say "no". Any text you select is automatically copied to the clipboard overwriting what was there (whether you wanted that to happen or not).
I can't find any mention of improved clipboard services in the KDE 2.0 doc. When I looked at the KDE 1.1.2 code recently there were only three types of clipboard data - text, bitmap and URL's. Clipboards aren't as glamorous as components and run time linking and so on, but they are probably going to be used the most often. It would be nice to have a clipboard type for search text, set up a search for a word in one app, change to another app and hit search - it might look for the same word. Or richer data types like PDF, RTF or similar so you can paste text with attributes in a standard manner.
Slashdot Mirror
The 'kalyptus' bindings generation tool has a '-fperl' option to generate .pig (Perl Interface Generator) files. The .pig files can be then be fed straight into Ashley Winters' Pig.pm generator.
kalyptus is in the KDE cvs under kdebindings/kalyptus.
The main technical obstacle to producing Perl bindings for Qt 3/KDE 3 is that they assume that the moc generated code works like Qt 2. Qt used to call slots via function pointers, but in Qt 3 it uses an integer offset into the slot table.
So the slot/signal handling needs to be redone to get the Perl bindings to work.
And Common Lisp for Qt/KDE should certainly be possible.
-- Richard
"The idea is that it makes JNI calls to the base OS for the GUI, so it's fast."
.NET isn't a DIY kind of thing.
But that doesn't make it cross-platform, it just means it's a fast Windows only thing. There is a huge amount of work involved in adding a higher level api on top of the JNI stuff, and ensuring that code will behave in an identical manner on every platform.
I believe Swing is 30% faster in JDK 1.4 because Sun ignore their own api internally and make use of Java's dynamic programming/reflection capabilities. Sun have tended to use Java as though it is a static language like a stripped down C++.
For example, why would you want to use a class called 'EventListerList':
"This utility class is use by many Swing classes to maintain lists of event listeners..."
Why do I want to maintain lists of event listeners, and forward events - isn't that the sort of thing the GUI toolkit is supposed to do?
Microsoft wanted to add delegates to Java, which seems perfectly sensible to me, as it would mean less subclassing. And I'm sure the event handling in
-- Richard Dale
But it isn't cross-platform. They use Motif as a basis for Linux support - DOA surely?
Also SWT uses the AWT/Swing style of subclassing and managing event listeners, which is an incredibly clunky programming model. It doesn't make use of Java's dynamic programming capabilities at all. I much prefer Trolltech's Qt slots/signals for component based programming.
-- Richard Dale (obviously biased Qt/KDE Java bindings author)
The bindings aren't intended for coding directly in C. They are meant for implementing bindings for languages which can't call C++ directly such as PHP, Pascal or some Objective-C.
-- Richard Dale
If Mac OS X wasn't based on Mach 3.0, it wouldn't have been possible to implement the Quartz window manager which depends on Mach's advanced ipc and shared memory features. So Linux, because of its limitations, will only have X or direct to framebuffer implementations, neither of which aren't as good. -- Richard
Yes, it will be possible and in the KDE CVS in about a month - I'm working on C now (along with Objective-C/GNUstep Foundation kit bindings). I've just recently checked in Java JNI based bindings for Qt and KDE. Please see the language bindings section on the KDE site. You need to check out the 'kdebindings' module from the KDE CVS to get the code. Richard Dale, Lost Highway Ltd
> I'll dump Java whenever I see something that is even cooler
And what about open source programming techniques - CVS, patches, peer reviews, no managers etc? Surely much more revolutionary in its effect on the industry than Java. Biggest thing since Fred Brookes in my opinion.
How come Java is exciting compared with the ideas in Smalltalk-80 (20 years earlier)?
My tip for the next 'new new thing' - visual programming environments (cf son of Prograph).
-- Richard (aged 43)
I'm 43 - I agree it's a great time to be programming. I say Apple's forthcoming Mac OS X Objective-C/Cocoa/Mach 3.0 micorkernel may suit your tastes, apart from the lack of lambdas/closures/Smalltalk blocks or similar.
All the posts mention using a resume (CV) to get work. Resumes are very ageist. Getting work by having a portfolio of (preferably open source) software levels the playing field for older programmers. If the site is using the software tool or whatever that you just wrote, they're pretty likely to want to hire you.
Say what - check out 'kdkobjc-0.2.tar.gz' somewhere on gnustep.org - I put it there only today. Objective-C support for KDevelop 1.2, plus a start on a Qt/Objc api! Now who would bother to look at my resume? QED.
-- Richard
How about Pop-11 on a PDP-11/34 from a teletype in 1976? Pop-11: Lisp semantics, but with friendly Pascal-like syntax and interactive interpreter? I couldn't have had a better start..
James Lanfear wrote: > What does this have to do with my post? Nothing! I was attempting to reply to Espen: Espen wrote: > What matters is not the cost of the most expensive setup, but the cheapest one 'cause once you have a basic box you can populate it with standard component memory and drives as you see fit.
Both Yellow Dog and LinuxPPC distributions are based on Red Hat, so so they support Gnome better than KDE (quite a few KDE utlities are missing and so on). Suse should be better for those of us who prefer KDE over Gnome.
Why have a cheap badly designed beige box which needs fixing with screwdrivers, soldering irons tweaking IRQs etc, when you can have a cheap well designed iMac running LinuxPPC for less than $1000 (plus Contour Unimouse 3-button mouse for $30 or so)?
> KDE 2 will have a much better clipboard support - any data can be copied and pasted, it will be recognized by mimetype. That sounds really nice. Will it have more than one clipboard though, or still just use XA_PRIMARY? I can't find XA_SECONDARY used for anything - what about nominating that as a clipboard for search text? Copy and paste on a typical KDE app doesn't behave the way a Mac/Wiindows/NeXT user would expect. For instance, if you open a text file with kwrite. Select some text, then choose the copy command from the menu. Then scroll down the file a bit and select some more text. Then choose paste from the Edit menu. Ask a Mac user whether they thought the text in the file will have been changed and they will say "yes", but a KDE user will say "no". Any text you select is automatically copied to the clipboard overwriting what was there (whether you wanted that to happen or not).
I can't find any mention of improved clipboard services in the KDE 2.0 doc. When I looked at the KDE 1.1.2 code recently there were only three types of clipboard data - text, bitmap and URL's. Clipboards aren't as glamorous as components and run time linking and so on, but they are probably going to be used the most often. It would be nice to have a clipboard type for search text, set up a search for a word in one app, change to another app and hit search - it might look for the same word. Or richer data types like PDF, RTF or similar so you can paste text with attributes in a standard manner.