if you want, but this would just show you how to display "Hello, world" in a message box while the program at your link shows you a typical skeleton of a simple but realistic application. It doesn't try to be minimal, this is just not the point.
I've never used it myself but there is wxC. AFAIK it's mostly used as a base for the bindings to the other languages (like wxHaskell), but perhaps it is good enough to be used directly.
The main reasons to prefer wx to Qt remain the same as always:
1. Native widgets (especially important under OS X). 2. Written in 100% standard C++ (no compiler-specific extensions, no preprocessor). 3. More permissive licence (notably allowing static linking for non-open source applications).
And then there is wxPython which is quite popular in Python community.
This is my first ever submission to/. so maybe it's perfectly normal and I just have no idea how do these things work but I'm as puzzled as you because the original submission said "First Major Release in 15 years"...
I won't speculate on this but, in spite of what the reply above seems to imply, I doubt it's out of concern for the users.
In any case the obvious workaround is to make something that compiles directly into Objective-C, instead of assembly. You could even keep all the comments. This would be doable in Perl or C++ (for wxWidgets), I don't know if it would work in Flash.
It might be doable but it would definitely count as the use of "intermediary translation... tool" and so be clearly forbidden. Now in practice I don't think Apple is going to carefully examine all apps to check whether they do it and I'm not even certain that wxWidgets falls into this category anyhow. Unfortunately being uncertain that it does not is quite enough to dissuade anybody from even considering it. And this is even better than FUD because while there certainly is fear and uncertainty, there is no doubt whatsoever that Apple won't hesitate to prohibit any "portable cross-platform C++ frameworks" if it ever decides it would be beneficial to it.
You've got to admire Apple even if you find what they do as hateful as I do. They do know how to play the game and their progressive developer lock-in works better than anything Microsoft ever dreamt about (but now they will try to copy Apple, of course -- initially with lesser success but sooner or later they will get there too). And if all this evokes herds of lemmings to me this is surely just my own personal problem...
Interestingly enough nobody seems to have mentioned this gem yet. To summarize, Apple has decided to forbid
Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool
While this is clearly aimed squarely at Adobe and their Flash compiler I can't help wondering what does it mean even for C++ libraries such as Qt or wxWidgets (that I'm personally most interested in) as, with a bit of bad faith (that Apple doesn't seem to luck), they could be construed to be "intermediary compatibility layers" too. And this definitely seems to exclude using Perl, Python, Ruby or anything else.
If anybody had any doubts about Apple openness, this should hopefully be enough to dispel them (although whom am I kidding... there will surely be people able to justify this as well).
Perhaps you're reading this using Firefox, in Windows even, as are many of the people that spend time on Slashdot? GTK's widgets haven't doomed Firefox to failure has it?
No, it hasn't. But this might be explained by the fact that Firefox doesn't use GTK+.
And the rest of your comment is about as accurate...
Yep, I spent a few months using wxWidgets a couple years ago. I just didn't like it. Obtuse MFC style message maps just screamed ugly at me.
Strange things is that people still don't realize, even after many years spent explaining this -- and not only on Slashdot, mind you -- that MFC-style message maps are just one way of connecting events in wxWidgets and that there exists a superior and more flexible, but somewhat more verbose, way to do it with Connect(). In my biased-but-still-struggling-to-be-objective opinion Connect() beats the horror that is moc hands down.
Re:It's good news, but is it too late?
on
Qt Becomes LGPL
·
· Score: 1
Qt beats wxWidgets by a wide margin. The API is much cleaner, documentation is a lot better, and wxWidgets has nothing like QGraphicsView
Being a wx developer, I don't know Qt well but wxArt2d seems to be similar to QGraphicsView, doesn't it?
There is absolutely nothing in Chromium UI which couldn't be done equally easily (or easier) using wxWidgets than using WTL which they use. And while WTL is not bad (at least it isn't MFC) wxWidgets has a tiny advantage of giving you native look-and-feel on all three major platforms (that's Windows, GTK+ and OS X -- there are also Motif and OS/2 ports but well, I might understand that Google is not that interested in having those).
The misconceptions about cross-platforms toolkits providing native LNF, such as wxWidgets, are amazingly widespread considering that they are not supported by any facts whatsoever. I can understand the problems of using GTK+ applications under Windows or Qt ones under Mac -- that's why I work on developing wxWidgets -- but, again, it absolutely wouldn't be more difficult to write Chromium UI using wx and the results would have been at least as good. The fact that not only Google didn't do it but they didn't create their own native LNF framework doing the same thing means that either no planning at all went into this project or that they are absolutely not interested in other platforms. I hope it was the former...
> What I want out of Linux: > > 1.One GUI. > > 2. Ability to play DirectX games. > > 3. Double click driver and application installs. "Fire and forget" > > 4. No preaching. I don't really give a rat's ass about what is free and what isn't.
As your points, especially the last one, make it abundantly clear, what you want is not Linux but a free[*] clone of Windows. Nothing wrong with this, of course, but what does it have to do with Linux and why any of the developers working on Linux [desktop] should care about what you want?
[*] I presume the cost is the only thing which keeps you from just using the original right now
All these tools (and also cmake and A-A-P mentioned in the other reply) are great for developers but not ideal for the end user who almost surely doesn't have them installed on his machine.
If you want to use something as easy on developer but which would still require no additional on the users machine, have a look at bakefile. This is a very useful tool, especially for open source programs where users often have or are asked to rebuild the program from source and installing additional tools is just an extra hurdle for them.
You can use 2.4 with GTK2 but support for GTK2 is already much, much better in 2.5.3 and, of course, improving all the time, so you should really consider using 2.5 instead.
Re:Will it work with wxwidgets?
on
GTK 2.6.0 Released
·
· Score: 2, Informative
We haven't tested wx with 2.6.0 yet so it is possible that currently something is broken (as you say, ideally it shouldn't be, but in practice GTK+ minor version upgrades have often proved to have not so minor compatibility problems). However our next 2.5.4 release will definitely work with it as will the next stable 2.6.0 (of wx, not GTK+). Hopefully they will match each other as perfectly as their versions do;-)
It's encouraging that PalmOS 6 looks to be somewhat easier to program for than previous PalmOS versions. In fact, sufficiently so that it looks like it should be possible to port wxWidgets (ex-wxWindows) to it and start writing programs which work on both PocketPC (with wxWinCE) and Palm devices.
If someone here is interested in helping with this effort, have a look at wxPalm contest page!
As one of wxWindows developers, I also find it very sad that OO people have never even tried to contact us directly. I did see a discussion about using wxWindows to port OO to Mac on OO dev list and there were some things which were just false there -- and we could surely explain it if only we were asked.
Unfortunately this never happened and I really don't know why. We'd certainly be eager to help. The particular point about accessibility is a very good example of why collaboration between wxWindows and OO would be good for both projects because we are working on adding accessibility support to wxWindows but have encountered some problems with this. Surely if this is so important for OO (I do agree that it should be important!) they could consider helping us with this. We'd definitely appreciate help from people knowing more about this domain.
Anyhow, maybe using wxMac wouldn't be ideal for OO but I just don't see how could it be worse than postponing the native version for at least 2 more years. Maybe it's not too late to do something about it though! If anybody is interested in porting OO to wxWindows, just contact us at wx-dev@lists.wxwindows.org.
wxMac (the native port of wxWindowws to Mac) has made huge progress recently, just try 2.5.0 release when it is out in 2 days. I do know of several problems in it but I wouldn't call it a mess.
Slashdot Mirror
I guess this petition never had a high chance of succeeding, but it's still a pity we're not going to have octarine in the periodic table.
You can reduce this to
if you want, but this would just show you how to display "Hello, world" in a message box while the program at your link shows you a typical skeleton of a simple but realistic application. It doesn't try to be minimal, this is just not the point.
I've never used it myself but there is wxC. AFAIK it's mostly used as a base for the bindings to the other languages (like wxHaskell), but perhaps it is good enough to be used directly.
As already mentioned, you might know about the company making Google Drive. And you might recognize a few other products from this list.
There is also Intel VTune about which I learnt completely accidentally, so who knows which other major companies use it without advertising it.
Not that I can't get a joke but actually, there is wxQT (albeit in a pretty preliminary state AFAIK, but then I've never really looked at it myself).
P.S. Thanks for the editors for correcting this, I'd still prefer my original submission but at least the current one is not factually wrong any more.
The main reasons to prefer wx to Qt remain the same as always:
1. Native widgets (especially important under OS X).
2. Written in 100% standard C++ (no compiler-specific extensions, no preprocessor).
3. More permissive licence (notably allowing static linking for non-open source applications).
And then there is wxPython which is quite popular in Python community.
This is my first ever submission to /. so maybe it's perfectly normal and I just have no idea how do these things work but I'm as puzzled as you because the original submission said "First Major Release in 15 years"...
Have a look at SimpleID.
Thanks for everything!
My question is, 'why?' Why does it bother Apple?
I won't speculate on this but, in spite of what the reply above seems to imply, I doubt it's out of concern for the users.
In any case the obvious workaround is to make something that compiles directly into Objective-C, instead of assembly. You could even keep all the comments. This would be doable in Perl or C++ (for wxWidgets), I don't know if it would work in Flash.
It might be doable but it would definitely count as the use of "intermediary translation ... tool" and so be clearly forbidden. Now in practice I don't think Apple is going to carefully examine all apps to check whether they do it and I'm not even certain that wxWidgets falls into this category anyhow. Unfortunately being uncertain that it does not is quite enough to dissuade anybody from even considering it. And this is even better than FUD because while there certainly is fear and uncertainty, there is no doubt whatsoever that Apple won't hesitate to prohibit any "portable cross-platform C++ frameworks" if it ever decides it would be beneficial to it.
You've got to admire Apple even if you find what they do as hateful as I do. They do know how to play the game and their progressive developer lock-in works better than anything Microsoft ever dreamt about (but now they will try to copy Apple, of course -- initially with lesser success but sooner or later they will get there too). And if all this evokes herds of lemmings to me this is surely just my own personal problem...
Interestingly enough nobody seems to have mentioned this gem yet. To summarize, Apple has decided to forbid
While this is clearly aimed squarely at Adobe and their Flash compiler I can't help wondering what does it mean even for C++ libraries such as Qt or wxWidgets (that I'm personally most interested in) as, with a bit of bad faith (that Apple doesn't seem to luck), they could be construed to be "intermediary compatibility layers" too. And this definitely seems to exclude using Perl, Python, Ruby or anything else.
If anybody had any doubts about Apple openness, this should hopefully be enough to dispel them (although whom am I kidding... there will surely be people able to justify this as well).
Perhaps you're reading this using Firefox, in Windows even, as are many of
the people that spend time on Slashdot? GTK's widgets haven't doomed Firefox
to failure has it?
No, it hasn't. But this might be explained by the fact that Firefox doesn't
use GTK+.
And the rest of your comment is about as accurate...
Yep, I spent a few months using wxWidgets a couple years ago. I just didn't like it. Obtuse MFC style message maps just screamed ugly at me.
Strange things is that people still don't realize, even after many years spent explaining this -- and not only on Slashdot, mind you -- that MFC-style message maps are just one way of connecting events in wxWidgets and that there exists a superior and more flexible, but somewhat more verbose, way to do it with Connect(). In my biased-but-still-struggling-to-be-objective opinion Connect() beats the horror that is moc hands down.
Qt beats wxWidgets by a wide margin. The API is much cleaner, documentation is a lot better, and wxWidgets has nothing like QGraphicsView
Being a wx developer, I don't know Qt well but wxArt2d seems to be similar to QGraphicsView, doesn't it?
There is absolutely nothing in Chromium UI which couldn't be done equally easily (or easier) using wxWidgets than using WTL which they use. And while WTL is not bad (at least it isn't MFC) wxWidgets has a tiny advantage of giving you native look-and-feel on all three major platforms (that's Windows, GTK+ and OS X -- there are also Motif and OS/2 ports but well, I might understand that Google is not that interested in having those).
The misconceptions about cross-platforms toolkits providing native LNF, such as wxWidgets, are amazingly widespread considering that they are not supported by any facts whatsoever. I can understand the problems of using GTK+ applications under Windows or Qt ones under Mac -- that's why I work on developing wxWidgets -- but, again, it absolutely wouldn't be more difficult to write Chromium UI using wx and the results would have been at least as good. The fact that not only Google didn't do it but they didn't create their own native LNF framework doing the same thing means that either no planning at all went into this project or that they are absolutely not interested in other platforms. I hope it was the former...
> What I want out of Linux:
>
> 1.One GUI.
>
> 2. Ability to play DirectX games.
>
> 3. Double click driver and application installs. "Fire and forget"
>
> 4. No preaching. I don't really give a rat's ass about what is free and what isn't.
As your points, especially the last one, make it abundantly clear, what you want is not Linux but a free[*] clone of Windows. Nothing wrong with this, of course, but what does it have to do with Linux and why any of the developers working on Linux [desktop] should care about what you want?
[*] I presume the cost is the only thing which keeps you from just using the original right now
All these tools (and also cmake and A-A-P mentioned in the other reply) are great for developers but not ideal for the end user who almost surely doesn't have them installed on his machine.
If you want to use something as easy on developer but which would still require no additional on the users machine, have a look at bakefile. This is a very useful tool, especially for open source programs where users often have or are asked to rebuild the program from source and installing additional tools is just an extra hurdle for them.
You can use 2.4 with GTK2 but support for GTK2 is already much, much better in 2.5.3 and, of course, improving all the time, so you should really consider using 2.5 instead.
We haven't tested wx with 2.6.0 yet so it is possible that currently something is broken (as you say, ideally it shouldn't be, but in practice GTK+ minor version upgrades have often proved to have not so minor compatibility problems). However our next 2.5.4 release will definitely work with it as will the next stable 2.6.0 (of wx, not GTK+). Hopefully they will match each other as perfectly as their versions do ;-)
It's encouraging that PalmOS 6 looks to be somewhat easier to program for than previous PalmOS versions. In fact, sufficiently so that it looks like it should be possible to port wxWidgets (ex-wxWindows) to it and start writing programs which work on both PocketPC (with wxWinCE) and Palm devices.
If someone here is interested in helping with this effort, have a look at wxPalm contest page!
They run, or at least used to run a few months ago, a (possibly patched) version of qmail:
h tm l#7.47
http://www.qmail.org/top.html
and search for "Yahoo". I also know it from an independent source because I discovered a bug in qmail:
http://www.washington.edu/imap/IMAP-FAQs/index.
while tracking a bug report cocerning my MUA.
As one of wxWindows developers, I also find it very sad that OO people have never even tried to contact us directly. I did see a discussion about using wxWindows to port OO to Mac on OO dev list and there were some things which were just false there -- and we could surely explain it if only we were asked.
Unfortunately this never happened and I really don't know why. We'd certainly be eager to help. The particular point about accessibility is a very good example of why collaboration between wxWindows and OO would be good for both projects because we are working on adding accessibility support to wxWindows but have encountered some problems with this. Surely if this is so important for OO (I do agree that it should be important!) they could consider helping us with this. We'd definitely appreciate help from people knowing more about this domain.
Anyhow, maybe using wxMac wouldn't be ideal for OO but I just don't see how could it be worse than postponing the native version for at least 2 more years. Maybe it's not too late to do something about it though! If anybody is interested in porting OO to wxWindows, just contact us at wx-dev@lists.wxwindows.org.
wxMac (the native port of wxWindowws to Mac) has made huge progress recently, just try 2.5.0 release when it is out in 2 days. I do know of several problems in it but I wouldn't call it a mess.
Have you ever programmed under Win32? This is simply false. Read the MSDN docs for PostThreadMessage() function: