Actually, there's a pretty good specification document for VNC. I was able to write a working implementation of the protocol (for keystone) that was not derived from the ORL sources. The documentation can be found here: http://www.uk.research.att.com/vnc/protocol .html
Re:Wasn't he working on the Transparency engine?
on
XFree86 Politics
·
· Score: 1
IIRC the transparency stuff required a change to the binary interface provided to drivers. This meant that it needed to wait for version 5.
Personally, I much prefer Qt's container classes to the STL (and most people I've talked to on this subject tend to agree). I find the STL's basic concept flawed (along with much of the C++ standard library). The Qt containers can however be used with the STL containers if you enable it when you build Qt.
I would though like to see some of the less GUI-dependent parts of Qt split into a separate library so I could use them more easily in non-graphical applications.
I often disagree with Neil, but on this occaision he is right. This is a pointless change. Your comments about CORBA show you haven't a clue what you're talking about.
But we already have cross-platform bindings for this stuff. We support a bunch of languages including all the ones you've listed and several more. Why would we use this instead?
But we already have a superb way of working with C strings - QCString. I don't see anything in GLib that is better (and I do see many things that are worse). Why should we switch?
Whilst it's true we manage ok with CVS, it's certainly not without its problems. We've discussed changing to something else several times, and I suspect when subversion is sufficiently developed we'll change to that.
The Gnome favourism isn't a problem, that's their decision. The main problem which you've missed is that have modified the names of the service types (so you'll find that if you download a 3rd party app as source it may well break). They've also changes the linker options used to load plugins which will caused weird crashes due to symbol name conflicts (eg. I doubt the Flash plugin works in Konqueror now because it has a name-clash with the OpenGL libraries). Needless to say we're less than happy about this, especially when Owen is claiming he want KDE and Gnome to compete on stability.
Basically it is obvious that the RedHat guys have made these changes without actually understanding what they were doing. Personally, I will be dropping any bugs reported by RH users as I won't be able to test them properly.
It's automatic. Go to a directory that contains a cvs checkout then click on the cervisia button in the extras toolbar. You find the cvs view embeds itself in konq, and the menu options/toolbars appear.
These numbers are extremely misleading. You need to consider the fact that most of this memory is in fact shared. You can't actually measure memory usage of anything but the simplest application using top, as it takes no account of which pages are from shared libraries.
- Tabbed browsing is scheduled for 3.1 (see the release plan).
- KDE 2 apps *will* work. You need to keep your old kdelibs and unset your KDEDIRS env variable (so it finds the correct info from the compiled in default).
BTW Glad you like the Cervisia integration stuff. I was wondering how many people would find it useful, looks like the answer is quite a lot.:-)
You might like to try using the NET enhanced version of FVWM. This adds supports for the extended WM hints specification agreed to by both KDE and GNOME. The homepage is http://fvwm-ewmh.sourceforge.net/.
The existence of this extension also shows that while WM development might have slowed, it hasn't stopped.
Re:Speaking of KDE...
on
KDE 2.2.1 Up
·
· Score: 2
The 'audiocd stuff' is a new KIOSlave that allows you to rip music CDs, it supports ripping to WAV, mp3 or OggVobis and uses cddb (or equivalent) to get the track listing too. Basically this means that you can just put an audio cd in your cdrom drive and type 'audiocd:'.
Cheers
Rich.
Re:some notes - Fix the Fonts please
on
KDE 2.2 Released
·
· Score: 2
There seems to be some confusion here. The fonts are the same regardless of the anti-aliasing setting, the only difference is in the way the font is rendered.
You can add this yourself if you want to. Look for an applications XMLGUI definition file (something like konquerorui.rc) then add the tag to the Menu tag you want to be able to tear off. You could try adding it to the global ui_standards.rc file if you want to do this to all your apps.
The Qt part of the binding can be used independently of the KDE part.
If you use a Swing UI then you also get the AWT bound into your JVM because the low level parts of Swing are build using AWT peer classes (look at the classes underlying the DnD interfaces for example). This increases the memory consumption etc. unnecessarily. The KDE binding allows you to choose what is loaded into the JVM.
It should actually be very easy to make both a Swing and a KDE binding to a Java app. The design philosophy of the two APIs (use of actions etc.) is similar so the glue is trivial. In addition you can still use the Swing model classes if you want to. In general, for well written Java code adding a new GUI is easy.
There are many reasons for writing a second GUI, the major one being to integrate well with the target environment. Swing is a decent enough programming API, but I have found that performance issues and the look and feel leave a lot to be desired. The Win32 look for example is close to, but not exactly like MFC and for many customers this is not good enough. A clean way to integrate with the native toolkit of the platform and to use platform independent code in the back end. In this situation Swing becomes a fallback rather than the primary UI toolkit for your app.
The first difference from AWT is that this binding doesn't try to be platform independent - this means that it doesn't have to provide a lowest common denominator API.
A second difference is that unlike the AWT this code is bound into the JVM under programmer control, so you can choose at run time if you want to load it. You could for example include a Swing binding in the same app as well as the KDE binding.
A final difference is that if you stick to the Qt part of the binding then you gain a degree of platform independence anyway because both the JNI and Qt are multi-platform.
People also seem to have failed to understand that these bindings could be used to implement an AWT. I began a direct AWT port called QtAWT (see the KDE developer site for details) a while back, but I haven't touched it for ages. Now that the AWT side of things can be handled in Java with the Qt/KDE binding it would be much easier.
The arguments about breaking Java's platform independence are also somewhat weak because of developments like Suns Java extension mechanism. This mechanism allows people to cleanly bind native code into their Java apps. There is no problem with including platform dependencies as long as you do it cleanly IMHO.
Sure it's worth stepping through code occaisionally, but this is a ridiculous statement. Trying to step through the whole of any program of a decent size would take years (and even then you won't be able to cover every possible excecution path). If you don't undertstand what your code does, then single stepping won't help you, conversely, if you do understand then you don't need to single step anyway.
In addition to this, as soon as you start to write non-trivial code in Java you begin using threads, so single stepping becomes a pointless activity. The timing difference means the threads interact differently to the way they would in a real invocation. It's still a useful technique every so often of course, but not for anything bigger than a few classes.
Have you actually written any decent sized Java apps? I would guess you haven't from this comment.
Re:I have had a fearful thought....
on
KDE 2.1 Is Out
·
· Score: 4
XUL is very similar to our XMLGUI and serves the same purpose. I suspect ours is actually more powerful, but if some can show a way that XUL is better we'll listen.
MathML isn't actually part of the default Mozilla I believe, and while it is extremely useful for a small number of people it is not something people are screaming for. If there is a demand for it then I'm sure it will arrive at some point, if necessary we could simply embed that part of Mozilla using XParts as a short term solution.
Cross-platform is a rather loose term. We support pretty much anything that runs X, and Konqueror is also available for embedded devices. We don't support Win32 or Mac though.
I guess you haven't checked out the DOM support, or the JavaScript in 2.1 - have you actually used it at all? You'll find it pretty impressive.
I think we support pretty much everything that that's in common use at the moment, and that we can add emerging stuff pretty quickly. We also have the advantage of having made a number of stable releases.
Re:Underspecification invites Security Risks
on
ESR On XML-RPC
·
· Score: 1
If you want a DTD for XMLRPC then look at http://www.ontosys.com/xml-rpc/. This page has a link to the DTD I wrote when I first got interested in using XML-RPC, the DTD is now maintained by Fred Yankowski.
Rich.
FYI KDE has built in support for XML-RPC
on
ESR On XML-RPC
·
· Score: 4
People interested in XML-RPC might be interested in checking it out using KDE. Since KDE 2.0 a DCOP XMLRPC bridge has been included allowing easy access to a wide range of the desktops APIs.
Install the KasBar panel applet and you can have the separated again. Currently non-embedded applets like this are not part of the release API however because we want to clean this part of the code up first.
Slashdot Mirror
Actually, there's a pretty good specification document for VNC. I was able to write a working implementation of the protocol (for keystone) that was not derived from the ORL sources. The documentation can be found here:l .html
http://www.uk.research.att.com/vnc/protoco
IIRC the transparency stuff required a change to the binary interface provided to drivers. This meant that it needed to wait for version 5.
Rich.
Personally, I much prefer Qt's container classes to the STL (and most people I've talked to on this subject tend to agree). I find the STL's basic concept flawed (along with much of the C++ standard library). The Qt containers can however be used with the STL containers if you enable it when you build Qt.
I would though like to see some of the less GUI-dependent parts of Qt split into a separate library so I could use them more easily in non-graphical applications.
Rich.
Hmm, lets see:
.NET I'd imagine. They've also written their components with it.
IBM - They're using Qt + C++ for their new palmtop reference platform.
Microsoft - They're using C++ to write C# and
Apple - They're using C++ and KHTML for their webbrowser.
So you're left with Sun who wouldn't know a decent GUI if you hit them over the head with it.
Rich.
I often disagree with Neil, but on this occaision he is right. This is a pointless change. Your comments about CORBA show you haven't a clue what you're talking about.
Rich.
But we already have cross-platform bindings for this stuff. We support a bunch of languages including all the ones you've listed and several more. Why would we use this instead?
Rich.
But we already have a superb way of working with C strings - QCString. I don't see anything in GLib that is better (and I do see many things that are worse). Why should we switch?
Rich.
Whilst it's true we manage ok with CVS, it's certainly not without its problems. We've discussed changing to something else several times, and I suspect when subversion is sufficiently developed we'll change to that.
Rich.
The Gnome favourism isn't a problem, that's their decision. The main problem which you've missed is that have modified the names of the service types (so you'll find that if you download a 3rd party app as source it may well break). They've also changes the linker options used to load plugins which will caused weird crashes due to symbol name conflicts (eg. I doubt the Flash plugin works in Konqueror now because it has a name-clash with the OpenGL libraries). Needless to say we're less than happy about this, especially when Owen is claiming he want KDE and Gnome to compete on stability.
Basically it is obvious that the RedHat guys have made these changes without actually understanding what they were doing. Personally, I will be dropping any bugs reported by RH users as I won't be able to test them properly.
Rich.
It's automatic. Go to a directory that contains a cvs checkout then click on the cervisia button in the extras toolbar. You find the cvs view embeds itself in konq, and the menu options/toolbars appear.
Rich.
These numbers are extremely misleading. You need to consider the fact that most of this memory is in fact shared. You can't actually measure memory usage of anything but the simplest application using top, as it takes no account of which pages are from shared libraries.
Rich.
- Tabbed browsing is scheduled for 3.1 (see the release plan).
:-)
- KDE 2 apps *will* work. You need to keep your old kdelibs and unset your KDEDIRS env variable (so it finds the correct info from the compiled in default).
BTW Glad you like the Cervisia integration stuff. I was wondering how many people would find it useful, looks like the answer is quite a lot.
Rich.
You might like to try using the NET enhanced version of FVWM. This adds supports for the extended WM hints specification agreed to by both KDE and GNOME. The homepage is http://fvwm-ewmh.sourceforge.net/. The existence of this extension also shows that while WM development might have slowed, it hasn't stopped.
The 'audiocd stuff' is a new KIOSlave that allows you to rip music CDs, it supports ripping to WAV, mp3 or OggVobis and uses cddb (or equivalent) to get the track listing too. Basically this means that you can just put an audio cd in your cdrom drive and type 'audiocd:'.
Cheers
Rich.
There seems to be some confusion here. The fonts are the same regardless of the anti-aliasing setting, the only difference is in the way the font is rendered.
Rich.
You can add this yourself if you want to. Look for an applications XMLGUI definition file (something like konquerorui.rc) then add the tag to the Menu tag you want to be able to tear off. You could try adding it to the global ui_standards.rc file if you want to do this to all your apps.
Rich.
It's down for a hardware upgrade IIRC.
You can make KDE look pretty awesome (IMHO) using the styles etc. provided in the release though.
Rich.
If you use a Swing UI then you also get the AWT bound into your JVM because the low level parts of Swing are build using AWT peer classes (look at the classes underlying the DnD interfaces for example). This increases the memory consumption etc. unnecessarily. The KDE binding allows you to choose what is loaded into the JVM.
It should actually be very easy to make both a Swing and a KDE binding to a Java app. The design philosophy of the two APIs (use of actions etc.) is similar so the glue is trivial. In addition you can still use the Swing model classes if you want to. In general, for well written Java code adding a new GUI is easy.
There are many reasons for writing a second GUI, the major one being to integrate well with the target environment. Swing is a decent enough programming API, but I have found that performance issues and the look and feel leave a lot to be desired. The Win32 look for example is close to, but not exactly like MFC and for many customers this is not good enough. A clean way to integrate with the native toolkit of the platform and to use platform independent code in the back end. In this situation Swing becomes a fallback rather than the primary UI toolkit for your app.
- The first difference from AWT is that this binding doesn't try to be platform independent - this means that it doesn't have to provide a lowest common denominator API.
- A second difference is that unlike the AWT this code is bound into the JVM under programmer control, so you can choose at run time if you want to load it. You could for example include a Swing binding in the same app as well as the KDE binding.
- A final difference is that if you stick to the Qt part of the binding then you gain a degree of platform independence anyway because both the JNI and Qt are multi-platform.
People also seem to have failed to understand that these bindings could be used to implement an AWT. I began a direct AWT port called QtAWT (see the KDE developer site for details) a while back, but I haven't touched it for ages. Now that the AWT side of things can be handled in Java with the Qt/KDE binding it would be much easier.The arguments about breaking Java's platform independence are also somewhat weak because of developments like Suns Java extension mechanism. This mechanism allows people to cleanly bind native code into their Java apps. There is no problem with including platform dependencies as long as you do it cleanly IMHO.
In addition to this, as soon as you start to write non-trivial code in Java you begin using threads, so single stepping becomes a pointless activity. The timing difference means the threads interact differently to the way they would in a real invocation. It's still a useful technique every so often of course, but not for anything bigger than a few classes.
Have you actually written any decent sized Java apps? I would guess you haven't from this comment.
XUL is very similar to our XMLGUI and serves the same purpose. I suspect ours is actually more powerful, but if some can show a way that XUL is better we'll listen.
MathML isn't actually part of the default Mozilla I believe, and while it is extremely useful for a small number of people it is not something people are screaming for. If there is a demand for it then I'm sure it will arrive at some point, if necessary we could simply embed that part of Mozilla using XParts as a short term solution.
Cross-platform is a rather loose term. We support pretty much anything that runs X, and Konqueror is also available for embedded devices. We don't support Win32 or Mac though.
I guess you haven't checked out the DOM support, or the JavaScript in 2.1 - have you actually used it at all? You'll find it pretty impressive.
I think we support pretty much everything that that's in common use at the moment, and that we can add emerging stuff pretty quickly. We also have the advantage of having made a number of stable releases.
Rich.
People interested in XML-RPC might be interested in checking it out using KDE. Since KDE 2.0 a DCOP XMLRPC bridge has been included allowing easy access to a wide range of the desktops APIs.
Rich.
Some examples:
- RFC 3043, IP encapsulation for carrier pigeons
- Every satellite based tcp/ip link that has carried HTML.
I'm sure there are others...
Install the KasBar panel applet and you can have the separated again. Currently non-embedded applets like this are not part of the release API however because we want to clean this part of the code up first.