I guess it's countermatched by Gtk's poor C++ bindings (good but not up to Qt's native support by any means, from what I've heard).
Now be nice here. I work on those bindings and I can say they are not poor. They are now at 1.0 and generally work for what they were intended. Additionally, they do have features that make Qt pale in comparision (namely the signal/slot methanism that doesn't require a preprocessor.) Please be so kind as giving us a "fair" rating at this point unless you have first hand grips.;-)
Considering that was a reply to a rather long thread in which they were going back and forth between to whom Harmony should be assigned and what license it should have, I kind of doubt that is was actually an April Fools joke. (If it is then I would say that it was an unusually cruel joke as it was regarding the survival of a project.) Further as no one responded to it as anything other with serious replies, it was not taken to be a joke.
From: "Adam J. Richter"
Date: Fri, 2 Apr 1999 04:07:11 -0800 To: rms@gnu.org Subject: Re: [freeqt] Harmony Revival Cc: freeqt@modeemi.cs.tut.fibr. >From: Richard Stallman
>If the copyright on Harmony is assigned to the FSF, >we will release it under the GPL, not the LGPL. >We don't want to risk a legal clash with TrollTech, >if we can achieve our goals without that risk.
I don't think that Troll would see any advantage in sueing anyone over a GPL'ed Harmony, so what would the advantage be in assigning it to FSF?
He seems to be taking it as seriously as I do. It would seem to be a very unfunny joke. Should we assume that all buisness dealings that take place on April 1 are meant as jokes? (I haven't known RMS to be a huge joker especially in such matters as licensing.)
The pseudocode should work fine. However as to the win32 that I don't know. No one on the project I know of has tried to compile for the windows platform (nor has a windows platform). You should mail the gtkmm mailling list and see if anyone has tried.
I do know that getting the first compile will likely be fun as we are using lots of Unix specific tools like awk, perl, sed, and autoconf. One person did inquired earlier and was told that the tools are available (through cyngus and some other site that I don't have bookmarked.) However, we have not as of yet heard back as to the results of his tests.
The win32 changes were not fulling incorperated into gtk+ at the time of the last release of Gtk--, so I can't be sure the graphic interface is going to compile. Hopefully, 6 months from now when Gtk+ has it next release I can be a little more possitive.
Sorry to disappoint you, but you are mistaken about there going to be a free version of the Qt. Harmony was basically told that if it wants to be protected by the FSF it would have to be GPL.
From a note from RMS on the Harmony maillist.
Date: Thu, 1 Apr 1999 13:10:08 -0700 (MST)
From: Richard Stallman To: adam@yggdrasil.com Cc: freeqt@modeemi.cs.tut.fi Subject: Re: [freeqt] Harmony Revival If the copyright on Harmony is assigned to the FSF, we will release it under the GPL, not the LGPL. We don't want to risk a legal clash with TrollTech, if we can achieve our goals without that risk.
If the developers keep the copyright, then the decision about the license is up to them, but I'd recommend following that same course of action.
With that the traffic on the Harmony list has nearly come to a halt. I suspect that too few developers feel the writting a GPL clone of something already free to Open Source code would be worth it. It would be very sad for a free software project to be taken out be the very person who most promotes freedom in software. Many of the coders of the original project and the revival seem to be afraid of being sued by TrollTech and not having the blanket of FSF will likely make the project suffer from lack of programmers.
Note that I am not associated with the Harmony project, but merely monitor their lists. I would hope that the discussions regarding this issue have just gone into the personal mailboxs and not died completely. I would encourage anyone who has the time to help get Harmony up to speed with Qt.
--Karl
Re:D'oh. Submit button next to preview button.
on
The Desktop Wars
·
· Score: 1
Actually, it is exactly the way that Gtk-- works.
Look over this example. You will have to delete the space the/. keeps adding in the address. (Rob: this address is getting mangled by the length of line checker)
In here I have used derived methods to take over motion_notify, button_pressed, button_released, exposure and configure. (Basically most of the common events.)
While at the same time I have attached connections from sliders, adjustments and buttons between methods in the various widgets. Therefore, rather than deriving new buttons that would alter data in another object (very bad OO), instead the object responsible for that data just provides methods which are later connected.
I agree that the notation of Gtk-- does leave a bit to be desired, however that is where we are working to make improvements.
Perhaps you have been listening to too much FUD and not looking close enough at Gtk--. There is templates, overloading, and overriding in Gtk--. (The entire signal system is built on templates. Overloading is not at all affected by wrappers, quite the opposite form my experience with OpenGL. And virtual method overriding is allowed for anything that has a signal.) There are some things that are missing such as virtual derived objects and documentation. However, simply being a wrapper does not make something inferior.
I agree that at some point in the future it would be nice to after the functions and features from Gtk in a more native C++ form, however, that is not the way things are currently going. Also for portablity reasons having pure C++ is not desirable. We are working very hard to increase the readablity of the Gtk-- wrappers as it seems to be the most intimidating thing to starting programmers.
I hope that at some point Qt will switch their signal system to something closer to Gtk-- as Gtk-- only uses the native C++ features. (Thus avoiding the evil preprocessor.) It should also be noted that the template based signal system is considerably faster that both the Qt and gtk models. The Gtk-- signal library will be released seperately as LibSigC++ probably by the middle of summer.
(BTW I also like Fltk but find its callback system a bit limiting. It strives for a very small footprint that rules out some of the features that Qt and Gtk have.)
Those interested in writting there own C++ widget set might be interested in checking out the libsigc++ module from the Gnome CVS. It provides completely native C++ callback mechanisms with unmatched flexibliy.
Wasteful in the sense that there is no reason for something to be derived when it can be trivially connected. For many situations like deriving a button just to attach it to something the callback form is better.
But actually, what you are requesting exists in Gtk--. What you want is also the perfered form (it is faster and more efficent). However, as most of the Gtk-- coders come from Gtk+ backgrounds they use the connect form over the derived form. The functionality is there, just most programmers don't use it. (most of the examples are translated from gtk+ so they also use that form, although if you look on the ones on my web page you will find that I use the derived form for all but connections that combine two widgets.) Your code with very small modifications would work with Gtk--. We support both virtual functions and signals as the framework.
Most cases do require the signal system over the derived through. For example, your first demo is coded nicely with just virtual functions. However, consider the case where two widget are interacting. One widget has a slider value and the other is a slider. So the interactions are built like this. (Rob please add PRE to the html format! also lt; and gt; don't work.)
// From the headers class Gtk_Adjustment { signal void value_changed(float);// in human readable form. };
// your class class MyApp { public: // A regular method to set the value void set_value(float); };
Here using simple derived techniques would not work well as you do not what to make your application a subtype of the Adjustment. It is better to just connect the method of the adjustment to the method of your application.
We find it best to allow both forms. I am sure you will agree this is the best policy. Do you find any flaws with the signal system in this light? (If I was every writting a pure C++ widget set I would probably use the Gtk-- signal model as it is very flexible.)
Have you looked at all at the new signal system for Gtk-- which is in development? The system is in middle design stage and currently considered usable. If you care to have some changes in the methods of input or the API abstractions then please look it over and mail me the comments as I am the primary author of that module.
The new signal system is abstracted further from the C interface and makes all signals into Objects. This is exactly the same form as used for the same purpose (callbacks) in the STL. We are also changing the notation to match the STL in a number of places. If will be by far the most flexible callback model published to date.
Signal1 < int,int > mysig;// int mysig(int);
int foo(int); mysig.connect(slot(foo));// mysig calls foo int i=mysig(1);// call mysig
Could you please give some exampes of how it should work or some examples of where this notation is bad?
As far as virtual functions, I don't understand the complaint. Gtk-- does use virtual functions for all of its signals. However, having to derive all of the widgets just to change a single behaviour is horribly wasteful. The entire point of callbacks in Qt, Fltk, WxWindows, and Gtk+ is to avoid unnecessary deriving of widgets. I do not understand how making virtual functions the only event handling would be helpful. Or am I misunderstanding your comment?
As always feel free to mail me feedback or better yet help contribute.
--Karl -- Gtk-- contributor
Mitochondria were originally primitive bacteria
on
Gene Leakage
·
· Score: 1
I don't know how many/.-ers know a lot about molecular genetics, but once you get into this stuff the parallels to computers are amazing.
I thought that should be "this stuff has amazing parallels to parallel computers." After all genes are nothing more that a set of codes with multiple pointers interacting with a self modifing tendencies!:-)
--Karl
The Obvious Looming Bio-Catastrophe, NOT!
on
Gene Leakage
·
· Score: 1
There are certainly cases of genes being transfered from one organism to another through some other agent such a virus. However, the probablity of a particular gene being transfered should be astronomically low.
Although I am not an expert in biology, I suspect the calculation would be something like this. How many genes are there in the plant? How many genes are transfered on average? How frequently does a transfer occur? How frequently does a transfered gene get passed onto the next generation?
If you consider the probablity of transfering any gene from the GM plant, you might find that a transfer does occur within a reasonable length of time. On the other hand, if you ask the probablity of a specific gene crossing over would be extrodinarly small and has an expectation time on the order of geologic time.
Consider for the moment that there are a large number of plants that are already too toxic for insects to ever eat. Take the case of tabacco which has potent toxin (which people love to smoke) which only a handful of hardy insects can eat. The crop is grown is large quantities accross great areas of land. Yet, we don't worry about the genes for that nicotine crossing over to all plant and wiping the insect population out. Thus the conditions already exist and have existed for centuries. So the argument that just because one plant is immune to most insects that the entire ecosystem is going to collapse is not just far-fetched, but in the realm of science fiction.
There are much greater threats to our ecosystem to be worried about that this one.
--Karl
Hey where did the experts come from
on
Gene Leakage
·
· Score: 1
Although nobody may know what will happen exactly when a new biological organism is introduced. Can you honestly say that the senerio that the professor presented of a horizonal crossing of a single gene to such a vast number of species that the insect kingdom falls is a realistic or even possible event?
Yes, there are certainly some dangers, but the greatest threat is the overruning of the environment with the GM rather that the GM's genes escaping. The ammount of for the transfer of a single gene crossing over is on geologic scales. Yes, horizonal transfers are probable, but that is the transfer of any gene. Consider that probablity of two people having the same birthday in a group of 100. It is likely that 2 will share the same birthday, but the likelyhood of an individual being the one is low. Similarly, the likely hood that a horizontal gene transfer occuring from a GM plant to another plant is probable, while the chance the modified gene traveling is low.
True, we must consider the consiquence and prove that modified genes are not likely to cause problems on other species or give the plant such an edge as to become dangerous. However, to give credence to improbable arguments just makes us all look silly. The most probable events should be of our concern not ones such as this.
I agree that this should be done in the open for all to see. Yet, I would wonder if it already is not underground.
--Karl
The Obvious Looming Bio-Catastrophe, NOT!
on
Gene Leakage
·
· Score: 1
The arguments in the article in question hold very little weight and are at best a scare tactic.
Consider the construction of the anti-insect argument. In that he proposed that some gene will cross over from a modifed plant to the entire ecosystem thus resulting in the complete destruction of all insects. Then asks the reader to consider the consequences. He then says that this is an unlikely event but possible. (The reader is left to assume that some lesser event is therefore more probable and we are all on the road to disaster when that is untrue.)
The argument is bad in a number of ways. First of all there would not be a anti-insect gene inserted in plants. A gene would have to be something useful like anti-leaf eating insects. That gene even if it crossed over to all plants through natural hybreds (which is impossible for all plants and unlikely even for natural cousins.) Thus the only insect affected would be those that eat the leaves of that plant and those that eat the those insects. But wait a minute that bees are not leaf eaters. And those of the insects that we are thinking of having disasterous results living without. Thus even without the plant eating insects most planets would still get pollonated. (some specialized planets would die).
Yes, there can be bad consiquences for a GM plant. But there are bad consiguences for many things (take MTBE for example). But we are not heading down some path for instant disaster. The the entire senerio is nothing more that fiction. It is nothing more that a strawman example to scare the uneducated masses. And it looks like you are falling for it.
--Karl
Introducing new genes in the genepool.
on
Gene Leakage
·
· Score: 1
Your example of the Africanize bee is entirely incorrect and also shows a similar weakness to the argument of the professor.
In the case of the Africanize bee the bees did not simply travel to some point and go on a rampage (there are numerious other animal species where that is the case.) The bees were intentionally brought here and forced to create a hybred bee with the honey bee. The resulting species is just a mean bee (nothing more.) Further, there are other biological vectors including a species of mites (from China I believe) that have been devistating the native bees and thus allowing the Africanize hybreds to spread.
This brings up a definite point. Hybreds in nature are not particularly common. Thus if we saw modified corn to be resistant to a bug (produces a bug birth control hormon), then a number of naturally expecting outcomes will occure. First, most instects will stop eating the crop. (Those that are able to still eat it will eventually become a dominate insect, but that is a later story.) According the professor we should worry about the gene crossing over to other plant species.
However, the cross can not be made in the same fashion as it is with bacteria and penicillin. Plants don't just bump into each other an exchange genes. (Bacteria do!) It requires a cross pollination from one compatible species to another. So we should assume that there is a compatible grass that can be pollenized by corn. However, for this to occur there would be a hybred planet with properies of both. But we don't see hundreds of species with much of the characteristics of corn (with its large kernel sizes) being exchanged. One must conclude that hybreds are therefore very rare. And that the chance of that gene excaping to just one other near by species is also difficult. Yes, the cross over may eventually occur, but for it to spread to the entire ecosystem would never happen as more planets can not be hybredized with all but their closest species.
In essence his argument is that we should worry about some gene we add to cows crossing over to goats. That is a small worry. The greater threat is that the GM planet will take over the environment and dirrupt the ecosystem by itself. (One can make a strong argument that enhanced tabacco plants may pose such a threat as they are toxic to most things already before we modified them.)
I believe this professors arguments are being greatly overblown. There is a threat, but this article presents only scare arguments without evaluation of the actual possible results. (All insects dying is completely impossible.)
This definately looks like a case of MicroSoft attempting to dilute a trade marked term for their own advantage. If a closed product (available on under a highly restricted license), is allowed to be called open source because MicroSoft decides to redefine the term that we heading down a road for disaster. The term will quickly be called a generic for any time the source is available to even one person outside the company.
By their definition, open source is available to a limited set of people (a select group of computer scientists, researchers, and original equipment manufacturers). Those select few cannot redistrubute it (thus commmercializing the technology). They have no rights to the work or derived works. Their ideas must be review before being incorperated back in. Sound a lot like a closed license to me.
One would wonder though if this isn't a good chance to counter charge the other direction. If they can redefine "open source", can we not redefine "windows", "office" and "explorer"? Let them come a attack us with the counter charge that they are diluting trademarks in exactly the same fashion. Which has greater value, Windows or open source?
Unfortunately, MicroSoft is the 800 pound goralla. Most likely it will try to both get itself labeled open source and keeps its our trademarks intact. Lets just hope it doesn't get a seat on this bus.
The moderators probably thought that the thread was off topic. The flat mode is still there. There is a button at the top of the page with options Threaded, Flat, Nested, and No Comments.
Hit Flat and then Change. Some of the user settings appear to have gotten lost in the recent changes.
I second this. I think a bottom cap should be lower than -1. That way there is a distinction between moderated down, noise, off topic and junk.
But then at the same time, I think the default threshold should be -1 for all so the -1, (AC who a moderator didn't like), should would still be displayed by default. That way it takes at least two moderators to take out an AC and 3 to take out a named poster.
This way -1 gets not great/off topic, -2 gets noise (MEEP), -3 gets raw (no matter how low the message sinks). Then you just need to have up to 7 threshhold settings, (-3 to 3). There should be no caps.
I'm also sick of hearing GTK proponents claim that gtk+ is object oriented. IT IS NOT. Do widgets automatically destruct when they come out of scope? Nope.
Gtk+ is referenced counted, not scoped like that of C++ objects. They destroy when they are no longer referenced. This is for a very good reason. That being ease of use. In Gtk-- though, you can happily have the C++ section scope through normal rules.
Can I derive a new widget from an existing one and not have to worry about implementing inherited methods? Nope.
I don't understand what you are saying here. Deriving methods in gtk+ or gtk-- is that same as any OO model. Why would you worry about what you inherited? You can always override them. (You could make a point that gtk+ uses concrete widgets as abstracts, but that is minor.)
Can I integrate widgets easily with the STL? Nope: I'm supposed to use glib.
Gtk-- does not use glib. We use STL or provide STL complient containers. Most of these issues are resolved with the restriction that you should not take containers outside of local scopes. What STL algorithms are you planning to run on these widgets?
Can I overload operators so I can treat these "objects" just like native data types? Nope.
That is a language feature not a OO issue. In C++, that works without effort. See the glade-- examples for details.
The GTK-- wrapper, despite the heroic efforts of the GTK-- team, is not really ready for prime time. A few basic widgets aren't even implemented yet...
I thought that we have covered all of the basic widgets, but if you know of one that is missing I would be happy to see if we can get a wrapper for it. As for gtk-- readiness, it is suitable for moderate tasks. There are still many changes in the underlying structure planned. But this is common of tools early in their development.
and I'd argue that the apparent difficulty they are having with writing C++ wrappers at all merely proves my point.
The largest difficulty in writting a good C++ wrapper has been that Gtk+ keeps moving so swiftly and we have no documentation to go by. We are all just people interested in using the kit for our own projects, and so we only make changes at the rate that we discover problems.
--Karl Nelson Gtk-- contributor
Standrdizatin, Componentization, Inovaction or els
on
Linux 2.2.3 Released
·
· Score: 1
I agree this is off topic, but I have worked with/opt on HPUX, Solarius, and DEC for several years now. I find that for working with commercial packages this is an absolute must. It provides seperation of shlib which makes running multiple libraries with incompatible changes doable.
Further, as for the 8K path that is solved with a symlink directory collection tool. I simply collect the large set of tiny packages into symlink-bin directories. The advantage of this being I can try out new versions (or have multiple versions) of my packages on the system at the same time. The perferred ones go in the collections and the others can be added to user paths at user option. Using the M4 soft tool this then provides elegant management accross many architectures.
I would be happy to place those tools online if someone is interested.
Actually this sounds almost like the results from network trouble shooting about a year ago. One of the students installed a developer copy of Windows 98 (legally given to his research group) on one of the school machines. He was having difficulties registering with the DHCP server we use. So I hauled up a sniffer and traced down the packets.
I was very much suprised to find that it sent a number of packets to Microsoft on startup, the oddest of which was a broken IP packet. I felt that this was probably just a debugging feature in the development version. Well it looks like I was wrong!
Personally, I feel that we should be outraged by this action. The Microsoft Corperation is clearly violating our rights in a way that not even the US government is allowed. Aquiring personal information under the guise of innocent support requirements, is little more that an unauthorized search and seizure of personal property. Should not corperations be held to the same 4th ammendment requirements that our government is? (Last I checked purchasing a Microsoft program was not a warrent to search my hard drive.)
They each have different approachs to wrapping. Gtk-- with the straight wrapper, VDK with a more Borland type wrapper, and wx/Gtk with the wxWindows standard. Depending on how much or how little you wish to see Gtk code, take your pick.
Gtk-- (which I work on) is currently in beta after a rather long infancy period. We intend to release a 1.0 cut with the next month.
GL support for Gtk is very good. You can render direcly in a window or in a pixmap. See GtkGLArea for more details.
There is even a GL widget in the Gtk-- project. It will be a week or two before it is up to date with the gtk+ 1.2 (basically because it has the largest number of dependencies). If you are interested drop by the GtkGLArea-- website.
Mail your problem to the gtk mailling list if you are having problems. See our web page for details on those lists. (Under reporting bugs.) We have at least 4 guys that would be happy to respond. Currently known problems are that gtk+ changed some methods recently and gtk-- will only compile with the latest release of gtk+.
You can mail me personally, but no guarantees that I know the solution.
For those interested, we have a gtk-- feature freeze and will be releasing gtk-- 1.0pre1 any day now. This version will correspond to the gtk+ 1.2 release.
Actually, we can add widgets to the C++ interface directly. Unfortunately then those widgets would not be available to the rest of gtk interface. We chose not to do more than wrap, because those interfaces are already being developed in C and it would be a waste of our effort to reinvent them.
If at some time later gtk-- becomes wildly popular and C falls out of use, we can always port the gtk code directly to C++. However, as I am sure you will agree C++, has some diffiences that need too be addressed. Given the controversy, shouldn't we just wait for D.;-)
I am sorry that we don't provide a good printer interface, but that is as I say the domain on the gnome project. (I just wrap things) Asside from the lack of a printer interface, what else do you find deficent?
I don't understand how you can think that we have some inherent restriction on our code. Yes providing a good wrapper is more difficult than writting from scratch, but we are not forcing you to work at the C level. We have taken the time and effort to completely cover it all. Any places that you must go and access the C understructures is a place we need to cover better, and we are happy to learn about such places, so we can repair them.
If your advisors AI system was interfacable from C++ and you could not tell the difference from the interface or running it, than what difference did it really make. You are assuming that all wrappers must be bad and therefore gtk-- is bad. With that assumption, you could not possible accept that we have created a C++ library from a C framework.
From the technical stand point, we did not just wrap the C gtk+ and call it good. (That was the gtk-- of about 9 months ago, it really did sucked.)
Currently, our code:
takes over the gtk signal system
provides C++ equivelent mechanisms for parts that we found restrictive.
provides STL compatible access to the gtk structures.
takes over the callback system and transforms it to virtual functions.
Following the next release, it will:
take over the memory management of the gtk-- structures that are linked to gtk+.
seperate into interface and utility functions.
increase the strength of our signal/slot mechanism far beyond that of Qt.
provide a translating mechanism that will transparently promote all C structures to C++ structures when accessed.
Perhaps at that time you will reevaluate our design. Til then happy coding.
Slashdot Mirror
Have you checked out ORBit-C++ from the gnome cvs?
--Karl
Now be nice here. I work on those bindings and I can say they are not poor. They are now at 1.0 and generally work for what they were intended. Additionally, they do have features that make Qt pale in comparision (namely the signal/slot methanism that doesn't require a preprocessor.) Please be so kind as giving us a "fair" rating at this point unless you have first hand grips.
--Karl
Gtk-- Contributor
--Karl
I do know that getting the first compile will likely be fun as we are using lots of Unix specific tools like awk, perl, sed, and autoconf. One person did inquired earlier and was told that the tools are available (through cyngus and some other site that I don't have bookmarked.) However, we have not as of yet heard back as to the results of his tests.
The win32 changes were not fulling incorperated into gtk+ at the time of the last release of Gtk--, so I can't be sure the graphic interface is going to compile. Hopefully, 6 months from now when Gtk+ has it next release I can be a little more possitive.
Hope it helps.
--Karl
From a note from RMS on the Harmony maillist.
With that the traffic on the Harmony list has nearly come to a halt. I suspect that too few developers feel the writting a GPL clone of something already free to Open Source code would be worth it. It would be very sad for a free software project to be taken out be the very person who most promotes freedom in software. Many of the coders of the original project and the revival seem to be afraid of being sued by TrollTech and not having the blanket of FSF will likely make the project suffer from lack of programmers.
Note that I am not associated with the Harmony project, but merely monitor their lists. I would hope that the discussions regarding this issue have just gone into the personal mailboxs and not died completely. I would encourage anyone who has the time to help get Harmony up to speed with Qt.
--Karl
Look over this example. You will have to delete the space the /. keeps adding in the address. (Rob: this address is getting mangled by the length of line checker)
In here I have used derived methods to take over motion_notify, button_pressed, button_released, exposure and configure. (Basically most of the common events.)
While at the same time I have attached connections from sliders, adjustments and buttons between methods in the various widgets. Therefore, rather than deriving new buttons that would alter data in another object (very bad OO), instead the object responsible for that data just provides methods which are later connected.
I agree that the notation of Gtk-- does leave a bit to be desired, however that is where we are working to make improvements.
Hopefully this clears things up for you.
--Karl
I agree that at some point in the future it would be nice to after the functions and features from Gtk in a more native C++ form, however, that is not the way things are currently going. Also for portablity reasons having pure C++ is not desirable. We are working very hard to increase the readablity of the Gtk-- wrappers as it seems to be the most intimidating thing to starting programmers.
I hope that at some point Qt will switch their signal system to something closer to Gtk-- as Gtk-- only uses the native C++ features. (Thus avoiding the evil preprocessor.) It should also be noted that the template based signal system is considerably faster that both the Qt and gtk models. The Gtk-- signal library will be released seperately as LibSigC++ probably by the middle of summer.
(BTW I also like Fltk but find its callback system a bit limiting. It strives for a very small footprint that rules out some of the features that Qt and Gtk have.)
Those interested in writting there own C++ widget set might be interested in checking out the libsigc++ module from the Gnome CVS. It provides completely native C++ callback mechanisms with unmatched flexibliy.
--Karl
But actually, what you are requesting exists in Gtk--. What you want is also the perfered form (it is faster and more efficent). However, as most of the Gtk-- coders come from Gtk+ backgrounds they use the connect form over the derived form. The functionality is there, just most programmers don't use it. (most of the examples are translated from gtk+ so they also use that form, although if you look on the ones on my web page you will find that I use the derived form for all but connections that combine two widgets.) Your code with very small modifications would work with Gtk--. We support both virtual functions and signals as the framework.
Most cases do require the signal system over the derived through. For example, your first demo is coded nicely with just virtual functions. However, consider the case where two widget are interacting. One widget has a slider value and the other is a slider. So the interactions are built like this. (Rob please add PRE to the html format! also lt; and gt; don't work.)
class Gtk_Adjustment
{
signal void value_changed(float);
};
{
public:
};
class MyWindow: Gtk_Window
{
Gtk_Adjustment *adj;
MyApp *app;
public:
MyWindow()
{
app=new MyApp;
adj=new Gtk_Adjustment(0,0,360,5,30,30);
adj.value_changed.connect(slot(*app,&MyApp::set_v
}
};
Here using simple derived techniques would not work well as you do not what to make your application a subtype of the Adjustment. It is better to just connect the method of the adjustment to the method of your application.
We find it best to allow both forms. I am sure you will agree this is the best policy. Do you find any flaws with the signal system in this light? (If I was every writting a pure C++ widget set I would probably use the Gtk-- signal model as it is very flexible.)
--Karl
Have you looked at all at the new signal system for Gtk-- which is in development? The system is in middle design stage and currently considered usable. If you care to have some changes in the methods of input or the API abstractions then please look it over and mail me the comments as I am the primary author of that module.
The new signal system is abstracted further from the C interface and makes all signals into Objects. This is exactly the same form as used for the same purpose (callbacks) in the STL. We are also changing the notation to match the STL in a number of places. If will be by far the most flexible callback model published to date.
Could you please give some exampes of how it should work or some examples of where this notation is bad?
As far as virtual functions, I don't understand the complaint. Gtk-- does use virtual functions for all of its signals. However, having to derive all of the widgets just to change a single behaviour is horribly wasteful. The entire point of callbacks in Qt, Fltk, WxWindows, and Gtk+ is to avoid unnecessary deriving of widgets. I do not understand how making virtual functions the only event handling would be helpful. Or am I misunderstanding your comment?
As always feel free to mail me feedback or better yet help contribute.
--Karl
-- Gtk-- contributor
I thought that should be "this stuff has amazing parallels to parallel computers." After all genes are nothing more that a set of codes with multiple pointers interacting with a self modifing tendencies! :-)
--Karl
Although I am not an expert in biology, I suspect the calculation would be something like this. How many genes are there in the plant? How many genes are transfered on average? How frequently does a transfer occur? How frequently does a transfered gene get passed onto the next generation?
If you consider the probablity of transfering any gene from the GM plant, you might find that a transfer does occur within a reasonable length of time. On the other hand, if you ask the probablity of a specific gene crossing over would be extrodinarly small and has an expectation time on the order of geologic time.
Consider for the moment that there are a large number of plants that are already too toxic for insects to ever eat. Take the case of tabacco which has potent toxin (which people love to smoke) which only a handful of hardy insects can eat. The crop is grown is large quantities accross great areas of land. Yet, we don't worry about the genes for that nicotine crossing over to all plant and wiping the insect population out. Thus the conditions already exist and have existed for centuries. So the argument that just because one plant is immune to most insects that the entire ecosystem is going to collapse is not just far-fetched, but in the realm of science fiction.
There are much greater threats to our ecosystem to be worried about that this one.
--Karl
Yes, there are certainly some dangers, but the greatest threat is the overruning of the environment with the GM rather that the GM's genes escaping. The ammount of for the transfer of a single gene crossing over is on geologic scales. Yes, horizonal transfers are probable, but that is the transfer of any gene. Consider that probablity of two people having the same birthday in a group of 100. It is likely that 2 will share the same birthday, but the likelyhood of an individual being the one is low. Similarly, the likely hood that a horizontal gene transfer occuring from a GM plant to another plant is probable, while the chance the modified gene traveling is low.
True, we must consider the consiquence and prove that modified genes are not likely to cause problems on other species or give the plant such an edge as to become dangerous. However, to give credence to improbable arguments just makes us all look silly. The most probable events should be of our concern not ones such as this.
I agree that this should be done in the open for all to see. Yet, I would wonder if it already is not underground.
--Karl
Consider the construction of the anti-insect argument. In that he proposed that some gene will cross over from a modifed plant to the entire ecosystem thus resulting in the complete destruction of all insects. Then asks the reader to consider the consequences. He then says that this is an unlikely event but possible. (The reader is left to assume that some lesser event is therefore more probable and we are all on the road to disaster when that is untrue.)
The argument is bad in a number of ways. First of all there would not be a anti-insect gene inserted in plants. A gene would have to be something useful like anti-leaf eating insects. That gene even if it crossed over to all plants through natural hybreds (which is impossible for all plants and unlikely even for natural cousins.) Thus the only insect affected would be those that eat the leaves of that plant and those that eat the those insects. But wait a minute that bees are not leaf eaters. And those of the insects that we are thinking of having disasterous results living without. Thus even without the plant eating insects most planets would still get pollonated. (some specialized planets would die).
Yes, there can be bad consiquences for a GM plant. But there are bad consiguences for many things (take MTBE for example). But we are not heading down some path for instant disaster. The the entire senerio is nothing more that fiction. It is nothing more that a strawman example to scare the uneducated masses. And it looks like you are falling for it.
--Karl
In the case of the Africanize bee the bees did not simply travel to some point and go on a rampage (there are numerious other animal species where that is the case.) The bees were intentionally brought here and forced to create a hybred bee with the honey bee. The resulting species is just a mean bee (nothing more.) Further, there are other biological vectors including a species of mites (from China I believe) that have been devistating the native bees and thus allowing the Africanize hybreds to spread.
This brings up a definite point. Hybreds in nature are not particularly common. Thus if we saw modified corn to be resistant to a bug (produces a bug birth control hormon), then a number of naturally expecting outcomes will occure. First, most instects will stop eating the crop. (Those that are able to still eat it will eventually become a dominate insect, but that is a later story.) According the professor we should worry about the gene crossing over to other plant species.
However, the cross can not be made in the same fashion as it is with bacteria and penicillin. Plants don't just bump into each other an exchange genes. (Bacteria do!) It requires a cross pollination from one compatible species to another. So we should assume that there is a compatible grass that can be pollenized by corn. However, for this to occur there would be a hybred planet with properies of both. But we don't see hundreds of species with much of the characteristics of corn (with its large kernel sizes) being exchanged. One must conclude that hybreds are therefore very rare. And that the chance of that gene excaping to just one other near by species is also difficult. Yes, the cross over may eventually occur, but for it to spread to the entire ecosystem would never happen as more planets can not be hybredized with all but their closest species.
In essence his argument is that we should worry about some gene we add to cows crossing over to goats. That is a small worry. The greater threat is that the GM planet will take over the environment and dirrupt the ecosystem by itself. (One can make a strong argument that enhanced tabacco plants may pose such a threat as they are toxic to most things already before we modified them.)
I believe this professors arguments are being greatly overblown. There is a threat, but this article presents only scare arguments without evaluation of the actual possible results. (All insects dying is completely impossible.)
--Karl
By their definition, open source is available to a limited set of people (a select group of computer scientists, researchers, and original equipment manufacturers). Those select few cannot redistrubute it (thus commmercializing the technology). They have no rights to the work or derived works. Their ideas must be review before being incorperated back in. Sound a lot like a closed license to me.
One would wonder though if this isn't a good chance to counter charge the other direction. If they can redefine "open source", can we not redefine "windows", "office" and "explorer"? Let them come a attack us with the counter charge that they are diluting trademarks in exactly the same fashion. Which has greater value, Windows or open source?
Unfortunately, MicroSoft is the 800 pound goralla. Most likely it will try to both get itself labeled open source and keeps its our trademarks intact. Lets just hope it doesn't get a seat on this bus.
--Karl
- Carpet Sweepers
- Car record player
- Portable hairdryers
- Edsel
- Gaylord the puppy?
- Air-Powered boats
- Paper dresses
- Spit-wad kits!
Now I am sure the people will try to sell anything, no matter how inconvent, unlikely, or plain dangerous.--Karl
Hit Flat and then Change. Some of the user settings appear to have gotten lost in the recent changes.
--Karl
But then at the same time, I think the default threshold should be -1 for all so the -1, (AC who a moderator didn't like), should would still be displayed by default. That way it takes at least two moderators to take out an AC and 3 to take out a named poster.
This way -1 gets not great/off topic, -2 gets noise (MEEP), -3 gets raw (no matter how low the message sinks). Then you just need to have up to 7 threshhold settings, (-3 to 3). There should be no caps.
--Karl
--Karl Nelson
Gtk-- contributor
Further, as for the 8K path that is solved with a symlink directory collection tool. I simply collect the large set of tiny packages into symlink-bin directories. The advantage of this being I can try out new versions (or have multiple versions) of my packages on the system at the same time. The perferred ones go in the collections and the others can be added to user paths at user option. Using the M4 soft tool this then provides elegant management accross many architectures.
I would be happy to place those tools online if someone is interested.
--Karl
I was very much suprised to find that it sent a number of packets to Microsoft on startup, the oddest of which was a broken IP packet. I felt that this was probably just a debugging feature in the development version. Well it looks like I was wrong!
Personally, I feel that we should be outraged by this action. The Microsoft Corperation is clearly violating our rights in a way that not even the US government is allowed. Aquiring personal information under the guise of innocent support requirements, is little more that an unauthorized search and seizure of personal property. Should not corperations be held to the same 4th ammendment requirements that our government is? (Last I checked purchasing a Microsoft program was not a warrent to search my hard drive.)
--Karl
- Gtk--
- VDK
- wxWindows/GTK
They each have different approachs to wrapping. Gtk-- with the straight wrapper, VDK with a more Borland type wrapper, and wx/Gtk with the wxWindows standard. Depending on how much or how little you wish to see Gtk code, take your pick.Gtk-- (which I work on) is currently in beta after a rather long infancy period. We intend to release a 1.0 cut with the next month.
GL support for Gtk is very good. You can render direcly in a window or in a pixmap. See GtkGLArea for more details.
There is even a GL widget in the Gtk-- project. It will be a week or two before it is up to date with the gtk+ 1.2 (basically because it has the largest number of dependencies). If you are interested drop by the GtkGLArea-- website.
--Karl
Gtk-- Contributor
You can mail me personally, but no guarantees that I know the solution.
For those interested, we have a gtk-- feature freeze and will be releasing gtk-- 1.0pre1 any day now. This version will correspond to the gtk+ 1.2 release.
--Karl
Gtk-- Contributor.
If at some time later gtk-- becomes wildly popular and C falls out of use, we can always port the gtk code directly to C++. However, as I am sure you will agree C++, has some diffiences that need too be addressed. Given the controversy, shouldn't we just wait for D.
Good talking with you.
--Karl
I don't understand how you can think that we have some inherent restriction on our code. Yes providing a good wrapper is more difficult than writting from scratch, but we are not forcing you to work at the C level. We have taken the time and effort to completely cover it all. Any places that you must go and access the C understructures is a place we need to cover better, and we are happy to learn about such places, so we can repair them.
If your advisors AI system was interfacable from C++ and you could not tell the difference from the interface or running it, than what difference did it really make. You are assuming that all wrappers must be bad and therefore gtk-- is bad. With that assumption, you could not possible accept that we have created a C++ library from a C framework.
From the technical stand point, we did not just wrap the C gtk+ and call it good. (That was the gtk-- of about 9 months ago, it really did sucked.)
Currently, our code:
- takes over the gtk signal system
- provides C++ equivelent mechanisms for parts that we found restrictive.
- provides STL compatible access to the gtk structures.
- takes over the callback system and transforms it to virtual functions.
Following the next release, it will:- take over the memory management of the gtk-- structures that are linked to gtk+.
- seperate into interface and utility functions.
- increase the strength of our signal/slot mechanism far beyond that of Qt.
- provide a translating mechanism that will transparently promote all C structures to C++ structures when accessed.
Perhaps at that time you will reevaluate our design. Til then happy coding.--Karl