Well, on the topic of flamewars, I'd like to point out you're incorrect there.
Neither of the four definitions of commercial in my dictionary involve being sold for profit. Many free (as in speech, or beer) projects (eg, Red hat Linux, Zope, etc) are commerical in nature, and produced with the aim of profit. Many others are not.
Whether an app is commercial or non-commerical has no bearing on whether it is free (speech) or Open Source.
I believe the phrase you were looking for was `free software versus proprietary, commercial software versus non-commercial software'.
Oh well...
Re:Quit it with the misunderstanding of commercial
on
MS VP Speech Online
·
· Score: 2
Exactly. Nothing to do with price.
Many Open Source apps are produced with profit as their chief aim - eg, Red hat Linux, Zope, Akopia Interchange. Many others are produced fo other reasons. Some are produced for educational and altrustic means but later their development becoms primarily commercially driven.
The chief aim of Open Source software might be profit. It might not. Whether it is Open Source depends on whether iots license conforms to the OSD,rather than the current motivation of its producers.
BBut now Microsoft says code forking is bad, so that means it is really good?
Bsically, its a last resort. If the main branch of the project isn't accepting your changes, or the software has problems satisfying two different audiences,
So forking is a fix to a problem. It would be nicer if that problem didn't occur, but if it does, its nice to know that forking is an option.
In that sense, think of it as being like heart surgery, war, or riot police infiltrating your house. Nobody, when offered either of these, would say `woo-hoo, hope they do a baton charge!. But sometimes, under some stances, according to some views, they are necessary.
Like with all three cases above, froking should never be done unnecessarily.
Quit it with the misunderstanding of commercial!
on
MS VP Speech Online
·
· Score: 2
Christ! Closed soruce folk! Open Source folk! Read the bloody dictionary!
Of or relating to commerce: a commercial loan; a commercial attaché.
Engaged in commerce: a commercial trucker.
Involved in work that is intended for the mass market: a commercial artist.
Of, relating to, or being goods, often unrefined, produced and distributed in large quantities for use by industry.
Having profit as a chief aim: a commercial book, not a scholarly tome. Sponsored by an advertiser or supported by advertising: commercial television.
Notice anything about being `sold for profit' isn't in there? But you can bet your arse that Red Hat Linux is produced to generate income for Red Hat.
THE OPPOSITE OF OPEN SOURCE IS CLOSED SOURCE. THE OPPOSITE OF COMMERCIAL IS NON-COMMERCIAL. THE STATUS OF AN APPS SOURCE CODE HAS NOTHING TO DO WITH IT BEING COMMERCIAL OR NOT
Thanks. Sorry to yell, but the continued misuse of this word by just about everyone is beginning to piss me off.
Apache can run VB based ASP via closed addons from Chillisoft and Halycon software and Perl based ASP using Apache::ASP (I think that's what its called), an open source app.
Apache can also authenticate against NT domain security using the SMB PAM module.
IIS is administered through a standard interface which is very friendly. There are a few of these available for Apache, most notably a great Webmin module.
Many old versions of Apache modules were a bitch to package (ie. PHP3). Newer ones (ie. PHP 4) package great, but compile-heads who prefer using non known-good software that isn't supported by their distro because it satisfies their pathetic egos still like compiing, and less epxerienced admins think that's the standard way to do it.
I don't give a rat's left kidney about KDE, and why the heck does every 2-bit reporter with a browser have to compare Gnome and KDE?
Because they are incompatible and inconsistent with each other, hence every desktop user will compare then to decide what they should you, and the reporters would like to provide a useful service by comparatively analysing them?
You could fix this by either making them work together properly (no, half implemented xdnd is not working together properly) and be consistent, or by waiting for one to grow considerably larger than the other, causing vast amounts of pain to desktop users while we wait.
Is this hyperbole, or is MetroLink responsible in some basic way for XFree86 and X.org?
Well, in terms of politics, they did donate the modular X architecture used in XFree86 4.0, which really cleaned up XF86s design and made closed source drivers possible (while some might not appreciate this, a lot pf people do).
In terms of technical brilliance, while Metro X currently lack some of the newer (currently nonstandard) X extensions that XF86 have developed, their X server does do a fine job of raw X performance versus the free competition, in nonpartial benchmarks.
Its a give and take relationship. I'm not saying Xfree86 doesn't rock, because they do. But so does MetroX.
The icons are the high color icons available in Start -> Control Panel -> Display -> Effects, in the check box marked `show icons using all possible colors'.
The bottom line is: ACL's are great and wonderful and all that. Force them on every file in the system however, and you're looking for big trouble and even bigger headaches.
Why? A single line ACL is less complex than 3 sets of rwxs bits. It seems to me ACLs are as complex as you want them to be.
Not to say that ACLs don't have their own problems, especially wrt to complexity. NT, for example, allows permissions on file/print shares, and those are often used instead of ACLs.
Actually, NT uses thw following method to determialternative ne your access:
1. Work out the greatest amount of privilege you have through ACLs
2. Work out the greatest amount of privilege you have through shares
3. The final privilege is the most restrictive of the two above
Complex huh? But we don't have to emulate the share/ACL combo on Linux. We do, however, need a system which allows for basic, realistic, access control situations:
* Some word processor templates are stored on a server
* A group of users edit these templates
* Another group of users can only read these templates
* All other users may not view these templates at all, as they contain business sensitive information.
A simple case found frequently in many offices. But not currently handled by RWX permissions at all, which are, in essence (and excuse the French) fucking pathetic.
Thank God the Linux ACL project is going to be one of the first Linux Security Module's for the 2.4 kernel. Thankyou SGI and everyone else making this a reality. With any luck, Linux will have a permission system that doesn't suck RSN.
Not to say that ACLs don't have their own problems, especially wrt to complexity. NT, for example, allows permissions on file/print shares, and those are often used instead of ACLs.
Actually, NT uses thw following method to determialternative ne your access:
1. Work out the greatest amount of privilege you have through ACLs
2. Work out the greatest amount of privilege you have through shares
3. The final privilege is the most restrictive of the two above
Complex huh? But we don't have to emulate the share/ACL combo on Linux. We do, however, need a system which allows for basic, realistic, access control situations:
* Some word processor templates are stored on a server
* A group of users edit these templates
* Another group of users can only read these templates
* All other users may not view these templates at all, as they contain business sensitive information.
A simple case found frequently in many offices. But not currently handled by RWX permissions at all, which are, in essence (and excuse the French) fucking pathetic.
Thank God the Linux ACL project is going to be one of the first Linux Security Module's for the 2.4 kernel. Thankyou SGI and everyone else making this a reality. With any luck, Linux will have a permission system that doesn't suck RSN.
would you really want to hire a highly-experienced code-grinder who...went to KKK rallies on the weekends?
I'm unsure about the US, but in Australia its illegal to hire or fire someone based on their political beliefs, and knowing the general trend against free speech and for political correctness in the US, I'd be surprised if similar legislation didn't exist there.
Package dependencies could not be completely resolved and Ximian GNOME cannot be installed on your system. This is usually caused by third-party software that conflicts with Ximian GNOME. Please report this problem (and the information below) to distribution@ximian.com for assistance.
Except there's *absolutely no* information below. I'm fine with something not working, but there's nothing I hate more than poor error messages.
Distro is RH 7.1. Upgraded from 7.0 (the install complained about Eazel Nautilus dependencies) and ran the installer. It gave the error message above. Then I got rid of Eazel Nautilus and re-ran the installer. Same message.
Well, that depends if your definition of what includes a packaging system involves dependencies. Most people define packages as a way of distributing software in modular chunks with meta information about their relationships with other packages. This allows them to be installed and uninstalled in a uniform and automated fashion (and by most people, I mean Red Hat, Debian, Microsoft, Sun, IBM, and every other maker of a package management system).
Slackware is, AFAIK, the only software that calls a software installation system without dependencies a packaging system.
They might be right, they might be wrong, but you've got to admit this definition is pretty unique.
Not talking about now, proposing a future.
on
QT Mozilla Port
·
· Score: 2
Because they are different libraries.
That's obvious enough - as is that I'm not talking about the present situation, but a future one.
A combined API and toolkit that's modular in design and language independent (for the next big shift in language design that replaces C / C++), with a superset of features from both, with a spec created by a neutral third party.
an ideal world, it would be like this. yes it would:-D
we're getting more OT. I thought you weren't talking about KDE/GNOME,
I was responsing to someone who was. And by responding to you, we're even more off topic. Great isn't it? I'm very well aware all these things are provided by the environment, as you surely know. Oh well.
That just shows that you don't read the KDE or GNOME mailing lists.
True. But I do follow their news and kernel cousins and had a good chat to a couple of CompanyX employees about this issue at a conference recently. Their attitude was that one (either GNOME or KDE) would become massively larger than the other and interop was of very little long term concern. This is what worried me.
The duplicate Control Centers and such are not a problem - just don't use the other one!
Um, how can I not use the other control center? Remember, I'm picking apps based on quality, not toolkit. In this case, that's Gimp, Konq etc. Can one of them configure both these apps?
You seem to have switched gears now from "lets merge GTK and QT and keep compatibility" to "Lets create a whole new toolkit".
My basic tenet was to create a modular project with the best elements and bindings of both. Good Open Source apps re--use code whenever possible so most `new' apps borrow heavily from old ones.. Whether the first line of code is original or taken from another project is of little concern.
You do not seem to understand the difference between a language binding and native support of a language. They're NOT the same thing.
I should have raised this earlier, but I see no reason why a particular tooklit or API should be more accessible to one language or another.
Win32 isn't open source, but WINE is, and WINE is an implementation of Win32.
Yes, but Win32s future is controlled by MS. Wines future is dictated by Win32 future. Furthermore, Wine is a work is progress, and there are very few stable apps I've seen that use it (as a Corel WPO2K user, I'm pretty sure about that one). MusicMatch, Websphere HP builder, and especially WP02K have serious issues.
I see no concievable benefit in merging them.
What do we get? Consistent look and feel? Already got it (theme importer).
Consistent look and feel =! theming! Please understand this! Its dialog boxes, widget behavior, panel application behaviour, drag and drop behaviour (xdnd still isn't used properly by either Konq or the GNOME desktop - try it with Konq FTP sometime).
Because of this, end users are forced to choose their apps on toolkit compatibility rather than quality. That is a Bad Thing.
To be honest, in terms of KDE / GNOME (which this discussion seems to have been moved towards) I would actually be just as happy if KDE and GNOME worked properly together now. But they don't. Not by a very long shot. For all the reasons above, and a billion more (duplicate menus, bookmarks, config centers, etc), and it seems very few people care.
Interoperability? Already got it (QT-GTK widget and XParts).
Good point, but they're both unfortunately very rarely used.
Might as well start a whole new toolkit, QTK or something.
Um, yes. That's what I'm talking about.
My understanding of the current QT licensing situation were that someone could port the Linux version of QT to Win32 to create a GPLed Win32 QT. Anyone care to correct me?
Why should this be the case (seriously, my eyes are open to options for those who explain themselves reasonably)? In thirty years time, will C++ still be the most popular development language? Shouldn't these toolkits be modular?
You're not going to change the entire object model.
A massive change isn't it? But greater ones have been affected. Hopefully it should be possible to migrate it over time.
You can't just take code from Qt and put it in glib.
I know. I'm not proposing to use either as they currently stand, but create something that's language independent.
The idea is still worthless, and i think you should read the rest of the replies to your post.
I'm reading every one, positive or otherwise, with an open mind, and responding with questions where I need to. I've never called an idea or another poster worthless yet.
Is your head so far up in the clouds that you do not see the codebase in use already?
You've overly abrasive, but I do get the point. But I think the current code base is miniscule in proportion to the future codebase, and a stable modular toolkit which doesn't rely on a particular language would be a good base to build on. The thirty years bit...
Do you really expect everyone to change their code to match a new api? Keep in mind that there are people who use Qt and gtk commercially.
Indeed. Over time yes, just as they would eventually change to a new release of either of those two toolkit / APIs.
Trolltech has a commitment to their customers to keep their API the same.
They have a commitment to their customers to keep the API in a forward moving direction without significantly breaking compatibility with previous releases. Just as the people doing commercial GTK support have similar commitment. There's a big diff there.
AFAIK, no. GTK can do C++ using Inti. Qt (I hope) also be bound to C. Both have Python bindings.
If this came about, what would be the point of having 2 toolkits anyway?
There wouldn't be, as a reasonable set of functionality from both would be in one combined library
Why don't we all just switch to Win32 programming and use WINE?
Because Win32 is not Open Source, controled by MS and is broken according to some.
One toolkit is better than 2, right?
Only if that one toolkit is well written, modular, and has little overhead.
KDE can import your GTK+ and IceWM themes, making "lack of constant appearance" a matter of user choice.
if you're speaking about KDE / GNOME (semi OT), no. It is not reasonable to expect a user to learn 2 sets of common dialogue boxes, 2 sets of widgets that react in 2 seperate ways, ad infinitum
What lack of consistency in UIs? Buttons, scrollbars, checkboxes, radio buttons, dockable toolbars - these concepts are almost identical in both toolkits. The only difference is in their appearence (KDE puts two buttons at the bottom of a scrollbar, but only in some themes, etc - this would be solved by QT importing GTK themes).
Making GTK compile QT apps (even though it's really impossible)
You think GTK can't do C++. That is incorrect. It seems you think this is impossible based on that idea.
Having GTK compile Qt apps would not help the stability, speed, or functionality of the Windows port of GTK,
Actually, I was thinking of having Qt compile GTK apps, as it seems to be the more well developed and cross platform of the two, seemingly due to age, though others with more knowledge might have a better idea. I think it would, as QT has been dedigned to be cross platform (including non Unix-like OSs), but again I'd like to hear from someone with experience. After the GTK = C comment, I'm sorry but you don't count.
With QT-GTK and GTK-QT widgets almost ready and XParts in the works, programs for either toolkit can use widgets or components (think Parts/Bonobo) from both.
That's great news. But a single object model would still be cleaner.
The idea doesn't take away anyone's freedom to choose - you could still use whatever toolktis functionality was duplicated into the other to form the newer kit.
Merging them would create a toolkit that is
something very different from either one
Ideally it should resemble both and not be too difficult, or provide a common layer between the two, much is the same way that Win32 provides a layer beneath MFC and VCL, which were once two very distinct toolkits.
the apis are very different for both toolkits. I should have mentioned I'm talking about merging the API as well as the toolkit.
Actually, its Python. No wait, its...just about every other language it can handle. Since one can't do inheritence in C, make it suitably modular.
The entire object model is different. Yes, we need to fix that.
There is stuff in Qt today that will take some time to implement in gtk+ or glib. I know. Lets get started now, if glib seems to be the best place to put that kind of thing (I think Qt might be)
If you made an abstraction layer, you would use _more_ memory than before! Did I ever say *anything* about an abstaction layer?
The whole idea is worthless in my opinion. That's because you currently don't seem to understand it.
Why can't I compile any app with QT support?
More to the point, why doesn't QT allow me to compile GTK apps against it, or vice versa?
Remember X2 and K56Flex? No? They were two different 56k modem standards. Both groups expected their implementation to be ratified by the International Telecommunications Union, who were going to analyse the points of each and decide of a 56k standard.
In the end, the ITU decided that both standard had their good points. V90, a standard that took the best bits of K56Flex and X2 and combined them into a single standard, became the order of the day. And the crappy X2 / K56Flex incompatibilities died a graceful death.
Could an independent group such as LI do the same to GTk and QT? This would solve...
1) Wasted memory.
2) Lack of consistent appearance.
3) Lack on consistency in widget behaviour.
4) Some of the lack on consistency in UIs, but not much.
5) Lack of solid cross platformability for particular toolkits. I am told GTK for Win32 is not the best right now. A solid cross platform Unix-based / Windows toolkit would help Open Source Unixes a great deal
6) Limitations of widget availability between both toolkits.
Please bear in mind this is a completely different concept to merging KDE and GNOME, which have less to do with Qt and GTK than many people think.
I know this will happen `when its done', but what's the currentstatus of BDC / PDC functionality (inc. replication). What's a credible date to think that Samba should be capable of this? Are we talking within six months, a year, or more?
Slashdot Mirror
Free Software vs. Commercial Software
Well, on the topic of flamewars, I'd like to point out you're incorrect there.
Neither of the four definitions of commercial in my dictionary involve being sold for profit. Many free (as in speech, or beer) projects (eg, Red hat Linux, Zope, etc) are commerical in nature, and produced with the aim of profit. Many others are not.
Whether an app is commercial or non-commerical has no bearing on whether it is free (speech) or Open Source.
I believe the phrase you were looking for was `free software versus proprietary, commercial software versus non-commercial software'.
Oh well...
Exactly. Nothing to do with price.
,rather than the current motivation of its producers.
Many Open Source apps are produced with profit as their chief aim - eg, Red hat Linux, Zope, Akopia Interchange. Many others are produced fo other reasons. Some are produced for educational and altrustic means but later their development becoms primarily commercially driven.
The chief aim of Open Source software might be profit. It might not. Whether it is Open Source depends on whether iots license conforms to the OSD
BBut now Microsoft says code forking is bad, so that means it is really good?
Bsically, its a last resort. If the main branch of the project isn't accepting your changes, or the software has problems satisfying two different audiences,
So forking is a fix to a problem. It would be nicer if that problem didn't occur, but if it does, its nice to know that forking is an option.
In that sense, think of it as being like heart surgery, war, or riot police infiltrating your house. Nobody, when offered either of these, would say `woo-hoo, hope they do a baton charge!. But sometimes, under some stances, according to some views, they are necessary.
Like with all three cases above, froking should never be done unnecessarily.
Christ! Closed soruce folk! Open Source folk! Read the bloody dictionary!
commercial (k-mûrshl)
adj. Abbr. com., coml., cml.
Of or relating to commerce: a commercial loan; a commercial attaché.
Engaged in commerce: a commercial trucker.
Involved in work that is intended for the mass market: a commercial artist.
Of, relating to, or being goods, often unrefined, produced and distributed in large quantities for use by industry.
Having profit as a chief aim: a commercial book, not a scholarly tome. Sponsored by an advertiser or supported by advertising: commercial television.
Notice anything about being `sold for profit' isn't in there? But you can bet your arse that Red Hat Linux is produced to generate income for Red Hat.
THE OPPOSITE OF OPEN SOURCE IS CLOSED SOURCE. THE OPPOSITE OF COMMERCIAL IS NON-COMMERCIAL. THE STATUS OF AN APPS SOURCE CODE HAS NOTHING TO DO WITH IT BEING COMMERCIAL OR NOT
Thanks. Sorry to yell, but the continued misuse of this word by just about everyone is beginning to piss me off.
There's no value in free!
Apache can run VB based ASP via closed addons from Chillisoft and Halycon software and Perl based ASP using Apache::ASP (I think that's what its called), an open source app.
Apache can also authenticate against NT domain security using the SMB PAM module.
IIS is administered through a standard interface which is very friendly. There are a few of these available for Apache, most notably a great Webmin module.
Many old versions of Apache modules were a bitch to package (ie. PHP3). Newer ones (ie. PHP 4) package great, but compile-heads who prefer using non known-good software that isn't supported by their distro because it satisfies their pathetic egos still like compiing, and less epxerienced admins think that's the standard way to do it.
And its SYSTEM, not 'root', on an NT box.
I don't give a rat's left kidney about KDE, and why the heck does every 2-bit reporter with a browser have to compare Gnome and KDE?
Because they are incompatible and inconsistent with each other, hence every desktop user will compare then to decide what they should you, and the reporters would like to provide a useful service by comparatively analysing them?
You could fix this by either making them work together properly (no, half implemented xdnd is not working together properly) and be consistent, or by waiting for one to grow considerably larger than the other, causing vast amounts of pain to desktop users while we wait.
Is this hyperbole, or is MetroLink responsible in some basic way for XFree86 and X.org?
Well, in terms of politics, they did donate the modular X architecture used in XFree86 4.0, which really cleaned up XF86s design and made closed source drivers possible (while some might not appreciate this, a lot pf people do).
In terms of technical brilliance, while Metro X currently lack some of the newer (currently nonstandard) X extensions that XF86 have developed, their X server does do a fine job of raw X performance versus the free competition, in nonpartial benchmarks.
Its a give and take relationship. I'm not saying Xfree86 doesn't rock, because they do. But so does MetroX.
Standard NT 4.0
The icons are the high color icons available in Start -> Control Panel -> Display -> Effects, in the check box marked `show icons using all possible colors'.
The bottom line is: ACL's are great and wonderful and all that. Force them on every file in the system however, and you're looking for big trouble and even bigger headaches.
Why? A single line ACL is less complex than 3 sets of rwxs bits. It seems to me ACLs are as complex as you want them to be.
Not to say that ACLs don't have their own problems, especially wrt to complexity. NT, for example, allows permissions on file/print shares, and those are often used instead of ACLs.
Actually, NT uses thw following method to determialternative ne your access:
1. Work out the greatest amount of privilege you have through ACLs
2. Work out the greatest amount of privilege you have through shares
3. The final privilege is the most restrictive of the two above
Complex huh? But we don't have to emulate the share/ACL combo on Linux. We do, however, need a system which allows for basic, realistic, access control situations:
* Some word processor templates are stored on a server
* A group of users edit these templates
* Another group of users can only read these templates
* All other users may not view these templates at all, as they contain business sensitive information.
A simple case found frequently in many offices. But not currently handled by RWX permissions at all, which are, in essence (and excuse the French) fucking pathetic.
Thank God the Linux ACL project is going to be one of the first Linux Security Module's for the 2.4 kernel. Thankyou SGI and everyone else making this a reality. With any luck, Linux will have a permission system that doesn't suck RSN.
Not to say that ACLs don't have their own problems, especially wrt to complexity. NT, for example, allows permissions on file/print shares, and those are often used instead of ACLs.
Actually, NT uses thw following method to determialternative ne your access:
1. Work out the greatest amount of privilege you have through ACLs
2. Work out the greatest amount of privilege you have through shares
3. The final privilege is the most restrictive of the two above
Complex huh? But we don't have to emulate the share/ACL combo on Linux. We do, however, need a system which allows for basic, realistic, access control situations:
* Some word processor templates are stored on a server
* A group of users edit these templates
* Another group of users can only read these templates
* All other users may not view these templates at all, as they contain business sensitive information.
A simple case found frequently in many offices. But not currently handled by RWX permissions at all, which are, in essence (and excuse the French) fucking pathetic.
Thank God the Linux ACL project is going to be one of the first Linux Security Module's for the 2.4 kernel. Thankyou SGI and everyone else making this a reality. With any luck, Linux will have a permission system that doesn't suck RSN.
would you really want to hire a highly-experienced code-grinder who ...went to KKK rallies on the weekends?
I'm unsure about the US, but in Australia its illegal to hire or fire someone based on their political beliefs, and knowing the general trend against free speech and for political correctness in the US, I'd be surprised if similar legislation didn't exist there.
Package dependencies could not be completely resolved and Ximian GNOME cannot be installed on your system. This is usually caused by third-party software that conflicts with Ximian GNOME. Please report this problem (and the information below) to distribution@ximian.com for assistance.
Except there's *absolutely no* information below. I'm fine with something not working, but there's nothing I hate more than poor error messages.
Distro is RH 7.1. Upgraded from 7.0 (the install complained about Eazel Nautilus dependencies) and ran the installer. It gave the error message above. Then I got rid of Eazel Nautilus and re-ran the installer. Same message.
Grr.
Slackware has a packaging system
Well, that depends if your definition of what includes a packaging system involves dependencies. Most people define packages as a way of distributing software in modular chunks with meta information about their relationships with other packages. This allows them to be installed and uninstalled in a uniform and automated fashion (and by most people, I mean Red Hat, Debian, Microsoft, Sun, IBM, and every other maker of a package management system).
Slackware is, AFAIK, the only software that calls a software installation system without dependencies a packaging system.
They might be right, they might be wrong, but you've got to admit this definition is pretty unique.
Because they are different libraries.
That's obvious enough - as is that I'm not talking about the present situation, but a future one.
A combined API and toolkit that's modular in design and language independent (for the next big shift in language design that replaces C / C++), with a superset of features from both, with a spec created by a neutral third party.
And yes, that is a lot of work.
an ideal world, it would be like this. :-D
yes it would
we're getting more OT. I thought you weren't talking about KDE/GNOME,
I was responsing to someone who was. And by responding to you, we're even more off topic. Great isn't it? I'm very well aware all these things are provided by the environment, as you surely know. Oh well.
That just shows that you don't read the KDE or GNOME mailing lists.
True. But I do follow their news and kernel cousins and had a good chat to a couple of CompanyX employees about this issue at a conference recently. Their attitude was that one (either GNOME or KDE) would become massively larger than the other and interop was of very little long term concern. This is what worried me.
The duplicate Control Centers and such are not a problem - just don't use the other one!
Um, how can I not use the other control center? Remember, I'm picking apps based on quality, not toolkit. In this case, that's Gimp, Konq etc. Can one of them configure both these apps?
You seem to have switched gears now from "lets merge GTK and QT and keep compatibility" to "Lets create a whole new toolkit".
My basic tenet was to create a modular project with the best elements and bindings of both. Good Open Source apps re--use code whenever possible so most `new' apps borrow heavily from old ones.. Whether the first line of code is original or taken from another project is of little concern.
You do not seem to understand the difference between a language binding and native support of a language. They're NOT the same thing.
I should have raised this earlier, but I see no reason why a particular tooklit or API should be more accessible to one language or another.
Win32 isn't open source, but WINE is, and WINE is an implementation of Win32.
Yes, but Win32s future is controlled by MS. Wines future is dictated by Win32 future. Furthermore, Wine is a work is progress, and there are very few stable apps I've seen that use it (as a Corel WPO2K user, I'm pretty sure about that one). MusicMatch, Websphere HP builder, and especially WP02K have serious issues.
I see no concievable benefit in merging them.
What do we get? Consistent look and feel? Already got it (theme importer).
Consistent look and feel =! theming! Please understand this! Its dialog boxes, widget behavior, panel application behaviour, drag and drop behaviour (xdnd still isn't used properly by either Konq or the GNOME desktop - try it with Konq FTP sometime).
Because of this, end users are forced to choose their apps on toolkit compatibility rather than quality. That is a Bad Thing.
To be honest, in terms of KDE / GNOME (which this discussion seems to have been moved towards) I would actually be just as happy if KDE and GNOME worked properly together now. But they don't. Not by a very long shot. For all the reasons above, and a billion more (duplicate menus, bookmarks, config centers, etc), and it seems very few people care.
Interoperability? Already got it (QT-GTK widget and XParts).
Good point, but they're both unfortunately very rarely used.
Might as well start a whole new toolkit, QTK or something.
Um, yes. That's what I'm talking about.
My understanding of the current QT licensing situation were that someone could port the Linux version of QT to Win32 to create a GPLed Win32 QT. Anyone care to correct me?
Qt is C++. There are bindings to other languages.
Why should this be the case (seriously, my eyes are open to options for those who explain themselves reasonably)? In thirty years time, will C++ still be the most popular development language? Shouldn't these toolkits be modular?
You're not going to change the entire object model.
A massive change isn't it? But greater ones have been affected. Hopefully it should be possible to migrate it over time.
You can't just take code from Qt and put it in glib.
I know. I'm not proposing to use either as they currently stand, but create something that's language independent.
The idea is still worthless, and i think you should read the rest of the replies to your post.
I'm reading every one, positive or otherwise, with an open mind, and responding with questions where I need to. I've never called an idea or another poster worthless yet.
Is your head so far up in the clouds that you do not see the codebase in use already?
You've overly abrasive, but I do get the point. But I think the current code base is miniscule in proportion to the future codebase, and a stable modular toolkit which doesn't rely on a particular language would be a good base to build on. The thirty years bit...
Do you really expect everyone to change their code to match a new api? Keep in mind that there are people who use Qt and gtk commercially.
Indeed. Over time yes, just as they would eventually change to a new release of either of those two toolkit / APIs.
Trolltech has a commitment to their customers to keep their API the same.
They have a commitment to their customers to keep the API in a forward moving direction without significantly breaking compatibility with previous releases. Just as the people doing commercial GTK support have similar commitment. There's a big diff there.
QT and GTK use different langages (C vs. C++)
AFAIK, no. GTK can do C++ using Inti. Qt (I hope) also be bound to C. Both have Python bindings.
If this came about, what would be the point of having 2 toolkits anyway?
There wouldn't be, as a reasonable set of functionality from both would be in one combined library
Why don't we all just switch to Win32 programming and use WINE?
Because Win32 is not Open Source, controled by MS and is broken according to some.
One toolkit is better than 2, right?
Only if that one toolkit is well written, modular, and has little overhead.
KDE can import your GTK+ and IceWM themes, making "lack of constant appearance" a matter of user choice.
if you're speaking about KDE / GNOME (semi OT), no. It is not reasonable to expect a user to learn 2 sets of common dialogue boxes, 2 sets of widgets that react in 2 seperate ways, ad infinitum
What lack of consistency in UIs? Buttons, scrollbars, checkboxes, radio buttons, dockable toolbars - these concepts are almost identical in both toolkits. The only difference is in their appearence (KDE puts two buttons at the bottom of a scrollbar, but only in some themes, etc - this would be solved by QT importing GTK themes).
Making GTK compile QT apps (even though it's really impossible)
You think GTK can't do C++. That is incorrect. It seems you think this is impossible based on that idea.
Having GTK compile Qt apps would not help the stability, speed, or functionality of the Windows port of GTK,
Actually, I was thinking of having Qt compile GTK apps, as it seems to be the more well developed and cross platform of the two, seemingly due to age, though others with more knowledge might have a better idea. I think it would, as QT has been dedigned to be cross platform (including non Unix-like OSs), but again I'd like to hear from someone with experience. After the GTK = C comment, I'm sorry but you don't count.
With QT-GTK and GTK-QT widgets almost ready and XParts in the works, programs for either toolkit can use widgets or components (think Parts/Bonobo) from both.
That's great news. But a single object model would still be cleaner.
The idea doesn't take away anyone's freedom to choose - you could still use whatever toolktis functionality was duplicated into the other to form the newer kit.
QT and GTK are fundamentally different toolkits, operating on different programming paradigms
Could you elaborate? AFAIK they can both handle, C (GTK native, Qt C bindings), C++ (GTK using Inti, QT native), and Python (Python bindings for both.
Merging them would create a toolkit that is
something very different from either one
Ideally it should resemble both and not be too difficult, or provide a common layer between the two, much is the same way that Win32 provides a layer beneath MFC and VCL, which were once two very distinct toolkits.
the apis are very different for both toolkits.
I should have mentioned I'm talking about merging the API as well as the toolkit.
Qt is C++,
Actually, its Python. No wait, its...just about every other language it can handle. Since one can't do inheritence in C, make it suitably modular.
The entire object model is different.
Yes, we need to fix that.
There is stuff in Qt today that will take some time to implement in gtk+ or glib.
I know. Lets get started now, if glib seems to be the best place to put that kind of thing (I think Qt might be)
If you made an abstraction layer, you would use _more_ memory than before!
Did I ever say *anything* about an abstaction layer?
The whole idea is worthless in my opinion.
That's because you currently don't seem to understand it.
Why can't I compile any app with QT support?
More to the point, why doesn't QT allow me to compile GTK apps against it, or vice versa?
Remember X2 and K56Flex? No? They were two different 56k modem standards. Both groups expected their implementation to be ratified by the International Telecommunications Union, who were going to analyse the points of each and decide of a 56k standard.
In the end, the ITU decided that both standard had their good points. V90, a standard that took the best bits of K56Flex and X2 and combined them into a single standard, became the order of the day. And the crappy X2 / K56Flex incompatibilities died a graceful death.
Could an independent group such as LI do the same to GTk and QT? This would solve...
1) Wasted memory.
2) Lack of consistent appearance.
3) Lack on consistency in widget behaviour.
4) Some of the lack on consistency in UIs, but not much.
5) Lack of solid cross platformability for particular toolkits. I am told GTK for Win32 is not the best right now. A solid cross platform Unix-based / Windows toolkit would help Open Source Unixes a great deal
6) Limitations of widget availability between both toolkits.
Please bear in mind this is a completely different concept to merging KDE and GNOME, which have less to do with Qt and GTK than many people think.
Thoughts anyone?
Jeremy,
I know this will happen `when its done', but what's the currentstatus of BDC / PDC functionality (inc. replication). What's a credible date to think that Samba should be capable of this? Are we talking within six months, a year, or more?
Mike