Half of me wants to sent it to the mayor; half of me is just wayyyyy too cynical right now to do so.
A large part of fighting the system is the feeling that it'd matter. I've read what politicians think of e-mail. I'd probably think that same damn thing.
I don't have a sense of what politicians in general, or even city politicians in particular, think of email, but something I've learned recently is that you can approach these people. I mean, you can just call up a city supervisor, make an appointment, and talk to them. That's their job!
If there's something about your city that you don't like, it is possible for you to go and do something about it. It can be a pain in the ass, but lots of things are.
If you care about late night culture in particular, join the San Francisco Late Night Coalition. In this case ``join'' means ``come to the monthly meetings.'' There is strength in numbers, and this group has a lot of members who have been doing this for a while and know the things you need to do to get yourself heard.
You want a bottom line? Fun has no value to government. Only taxes.
``Government'' is made up of people, specifically politicians and bureaucrats. To politicians, votes and image are also important. Those are the buttons you need to learn to push.
If all you want to do is to allow outgoing mail, just stop running sendmail in daemon mode. With redhat you can do this with
chkconfig sendmail off
As someone else pointed out, you also need to put a script that does ``/usr/lib/sendmail -q'' into/etc/cron.hourly/ if you don't want your mail to get stuck at random.
But another useful trick, if there are certain machines you want to accept mail from and others that you don't, is to run sendmail under tcpd so that it obeys/etc/hosts.allow and/etc/hosts.deny, by adding this to/etc/inetd.conf:
That way you can, for example, let specific machines on your subnet connect to your SMTP port without allowing the whole world to exploit the sendmail-bug-du-jour. (You can also do this with ipfwadm firewall rules, but I find hosts.allow to be easier to deal with.)
I generally prefer running services on my desktop machines (including sendmail and httpd) from inetd instead of having them always running as daemons in the background because that makes it easier to centralize control of their access lists, and because you don't have as many idle processes chewing up swap space. And since I'm the only one who ever connects to the http server on my desktop machine, the process-creation overhead is trivial (this wouldn't be such a good idea for a high volume web or mail server, obviously.)
To state the obvious, that's the weakest argument i've read in some time.
It wasn't an argument, it was an insult. For it to have been an argument, the strawman to which it was a reply would have had to have been deserving of an argument. For example, not being absurd on its face would have been a good start.
Consider yourself deservedly flamed.
That was a flame? ``You keep using that word. I think that you do not know what it means.''
Smoking: a completely legal activity, being increasingly regulated. Even to the extent that in some communities, restrictions on smoking on ones own property have been considered. And of course we all know what rights private property owners have if that private property happens to be a store, restaurant, etc.
Restrictions on smoking are based on employee safety laws, the idea that if you are an employer, you cannot require an employee to work in an environment known to be health-threatening. And believe it or not, second-hand smoke is known to be toxic. If it makes you feel better, it's easy to put an anarchist spin on this: ``your right to poison yourself ends where my lungs begin.''
Government control over the uses to which private property may be used. The acceptance of so-called "zoning laws" opened the door. Now you can be prohibited from filling in that mud-puddle if Canadian Geese fly over it once a year. Wet-lands, don't ja know.
Uh, yeah, sure. That probably sounded better when Rush Limbaugh said it, didn't it?
I think this is a valid concern, in my mind Slashdot is no longer to be trusted as an actual NEWS site, but only as a Tech site.
When has Slashdot ever been trustable as a news site? I like Slashdot, and it has a lot to recommend it, but journalistic excellence has never been one of those things: the so-called ``stories'' have always been poorly researched, highly biased, and half the time, just plain wrong.
Slashdot is a big set of bookmarks pointing at news reported by others; plus a discussion forum. As such it has value. But comparing Slashdot to Time is ridiculous.
I have pretty close to zero respect for Time's journalistic integrity, but Slashdot isn't even playing the same game. Not that Slashdot is worse, but that Slashdot isn't trying to do the same thing at all. It's apples and oranges.
I don't recall XtAddInput ever being broken, which means that whatever code you saw was wrong. [...] The things that bother me most are that timer and file-descriptor events aren't first-class events the way events are...
Uh... Jamie, how can you make both of these statements?! As I recall, this is exaclty the kind of brokenness that people were working around.
Huh? You can't work around the fact that Xt doesn't treat timers firing as first-class event objects. And you sure can't work around it by calling select().
The API associated with XtAddInput() is screwy, but it's not ``broken'' in the sense of ``doesn't work as advertised'' or ``doesn't let you do the things you can do with select().''
That's what I meant about criticising the right parts: this part of Xt has a screwy design. But it is still usable, it's just goofy. And calling select() does not make it better, it just makes it less portable. So criticise it for being a dumb design, but don't say that it doesn't work, because it does work.
Jamie, look. Clearly you and I disagree fundamentally on how flexible and dynamic the Xt libraries can be. Fine.
Uh, ok, except that what we're disagreeing over are not matters of opinion, but matters of fact.
Bottom line is that the current contenders for X GUI toolkit are Gtk and Qt. Motif is an unsupported (as in development stopped two years ago) product of a company that's slowly drifting down the tubes.
Nothing I have said here has been advocating using Motif over using GTK. (I've hardly even mentioned Qt because I haven't used it, because it's C++.)
I just don't see how one can continue to live in the past on this point. Gtk+ might have made some descisions that you don't like, but overall, these descisions have been accepted by enough programmers that these toolkits are taking over the development space that Motif used to occupy.
And GTK is set in stone now?
GTK is under active development, which means it can be fixed. GTK could easily be made to use the X Resource Manager as its basis for reading and storing preferences information. This could be done without breaking any existing apps: it could be a binary-compatible change.
But even if I'm wrong, and doing so would require incompatible changes, so what? They've done it before (there was a year when everyone had to have two versions of GTK installed because Gimp didn't work with the version of GTK that almost all other apps were written for.) They've had flag days before and they will have flag days again.
Changing GTK to be built on top of Xt widgets is probably impossible at this point. It would certainly be a colossal amount of work. But using Xrm resources wouldn't be hard.
Dismissing my criticisms of GTK's design because ``the decision has been made'' or ``that's living in the past'' is ridiculous. If a design mistake was made, even if that mistake is fully entrenched (like most of Unix), that mistake should be acknowleged so that people don't make similar mistakes in the future.
Or do you believe that no after-the-fact criticism ever has merit?
I seem to remember that XtAddInput does not work. I don't know why off the top of my head (Xt being something that I stopped using back in '92 or so), but every Xt or Motif program that I've seen that needs this functionality does exactly what I describe. Perhaps they're all wrong, in which case it's just that Xt is widely misunderstood.
I don't recall XtAddInput ever being broken, which means that whatever code you saw was wrong.
In all of these posts, it may sound like I'm defending Xt or Athena or Motif, but I'm only defending them against things that people are saying that are just incorrect. Motif is a mess in a zillion ways, and there are lots of scathing criticisms that can be made of Xt, Xlib, and everything down the line. But it's important to bash them for things that are actually true!
In particular, while Xt's event model has some really stupid shit in it, you didn't mention those things. The things that bother me most are that timer and file-descriptor events aren't first-class events the way events are; and that widget finalization (the Phase2Destroy thing) is a complete mess.
As I've pointed out elsewhere, Gtk+/GNOME had to dump X resources because they simply could not do what what needed.
Nonsense.
For one there's no reasonable way to shoe-horn in a WRITABLE X resource mechanism.
GNOME could have dictated, as a matter of policy:
System-wide Gnome resources shall live in/usr/lib/X11/app-defaults/app-name;
User-specific Gnome resources shall live in $HOME/.gnome/resources/app-name.
Blammo, now you know where the file is, and now you can write a preferences editor that can overwrite that file. But you're still using the traditional programatic API for applications to consult their resources; and you've still left open the option for sophisticated users to use the more advanced features of the resource database, like using wildcards or screen- or display-specific settings.
Don't believe it can work? Well I've got something better than words, I've got working code that does exactly this. Download xscreensaver and run xscreensaver-demo. Note that you can edit all the parameters of the application. Note that it saves them to disk, specifically to a file called $HOME/.xscreensaver. This file contains resources! The xscreensaver daemon examines its resources with XrmGetResource() just like X programs have always done.
Using the X resource manager does not preclude having sophisticated, user-friendly customization UIs. And doing so leaves many options open for more sophisticated users.
For another, the heirechical nature of Gtk+/GNOME's resources are just a little bit more flexible than anything that X resources can muster.
I don't believe this. Please give an example. I especially don't believe this since using the X resource manager doesn't even mean that you have to use Xrm's file format. (I'll bet Gtk could just use that file format, but that's not a requirement.) I don't use Xrm's format in the.xscreensaver file, but I still merge it in to the in-memory resource database in the proper way anyhow.
This all, not to mention the ability to replace the plain-text nature of the Gtk+ configuration file mechansim and replace it with a real, binary-capable database without a change to the API.
Last time I looked, Gnome used the DOS/Windows INI-file format, but split into one file per app. That doesn't look particularly binary-capable to me. But anyway, what large binary data do you expect to store in these resource files by value rather than reference? (I.e., you want to store pathnames, not bitmaps.) For small binary data, just base64 it or something, like you'd have to do today anyway.
As an example, here's a piece of code that stores a user preference to a resource file for later use:
gnome_config_set_string("features","lots");
There's a line to open the config database / associate the program with a root path, and there's one to close it, and that's it.
That very API could be easily implemented on top of the traditional X resource manager.
The fact that 500 people are working on ugly, confusing interfaces in no way prevents anyone from doing one interface really well. Why not do one interface really well, and allow 500 alternatives for people who prefer them?
Too often people use customizability as a crutch. They say ``if you don't like it then change it'' instead of getting it right the first time. This is, to a large extent, what has been wrong with X from day one: by refusing to dictate policy, we ended up with a zillion crappy UIs instead of focussing all those people on fixing the same one that everyone was using.
We've seen it in this very thread! People excusing shitty performance and UI criticisms by saying ``well you're using the default theme, you dummy! If you'd only used my favorite theme, which you can download from this web site over here that's down right now...''
I'd rather have Developer X working on getting one core UI right than adding features and fixing bugs in the theme engine.
Themes are a cute, useless toy for people whose hobby is tweaking their desktop Because They Can. There's nothing wrong with that hobby per se, but those people are not the people you need to win over if you want your desktop to be a success.
Ok, now I want to open a socket and handle events on that too. The usual Xt/Motif way to do this is to pull out the X display socket file descriptor from Xt (Xlib really) and then add that into your select call. When select returns, you see which descriptor triggers, and then jump into Xt's event handling if X triggered the select.
In Gtk+ you simply tell it about your socket and request events from it with the same callback strucutre as the rest of your code! This makes Gtk+ code a lot easier to develop and maintain (big emphasis on maintain).
No, what you described is the wrong way to do it. In fact, I think it doesn't work (or didn't used to) on VMS systems running DECnet, because calling XConnectionNumber() is not guarenteed to return something you can pass to select().
You seem to be unaware of XtAddInput() (and possibly also XtAddTimeout() and XtAddWorkProc().)
In a portable Xt program, one doesn't call select(), one calls XtMainLoop() (or XtNextEvent() and XtProcessEvent().)
In other words, it works exactly like it does in GTK.
I will defend Jaime a bit on this point... it's not that hard to figure out where a function lies if you understand how the heirarchy works:
X11: Any sort of low-level drawing primitives
Xt: General operations on Widgets (creation, destruction, etc)
Motif: Particular operations on the Motif Widget set
I think the design and goals of this were pretty good, but as I said in another thread, I have big problems with the implementation. Unfortunately, Motif had to break a lot of this abstraction to implement some of its features.
I don't believe that Motif had to break abstraction to implement any of the things it implemented, Motif's implementation is just bad.
As I understand it, there's never been any real overall ownership of the Motif code base; it was written by six-month-contractor after six-month-contractor, with no small group of winners looking over it and keeping the worker bees honest.
Who's ``the Motif guy''? There isn't one. Even if you read the source code comments. The spec is one thing, but the implementation is another, and the implementation seems to have had no effective architectural guidance. That's my impression from having spent way too many hours digging around in the source, anyway.
Perhaps so, but by far the biggest problem with Motif is that it's not abstracted enough. It's not possible to write a pure Motif program -- you need to resort to using Xt and Xlib as well.
Um. So?
You'd rather they provided XmDrawLine which did nothing but call XDrawLine? That would give you more things you needed to learn rather than less.
GTK is built on GDK. libm.a is built on libc.a. So what? That's what abstraction is.
Both Gtk+ and Qt are suitably abstracted, and you don't need to learn anything else in order to use them.
That's a nice sound bite, but it's so vague that it doesn't actually tell me anything. Please be specific.
Period. I want my X resources, my command line parsing, and a standard framework of gui mechanisms.
I totally agree with this.
For what it's worth, I have a kludge for making use of Xrm with GTK, but it's pretty fragile. Had GTK been built on top of Xt, then all the usual resource mechanisms would have worked automatically, and one would have been able to reuse the enormous body of Xt-aware code that is out there already. Among other things it would have been a lot easier to port Motif apps to GTK than it is today, because most of the implementation of any Motif or Athena application really consists of Xt calls.
If you want to see my evil kludge for using Xrm resources and command-line processing (but not Xt Widgets) from inside a GTK program, have a look at main() in driver/demo-Gtk.c in the xscreensaver distribution.
Gtk+ has a much more covinient event model which can incorporate arbitrary I/O and event loops.
Please explain what the GTK event model can do that the Xt event model cannot. I think they are the same.
Gtk+ has a fundamentally saner object model which actually works well in C and C++.
I do not believe that GTK's object model is fundamentally saner than Xt's.
GTK's objects are fundamentally saner than Motif's objects, but that's the implementation of the widgets, not the object model itself.
I can't comment on what it's like using Xt from C++, because C++ is an abomination that I would never use. But Xt makes it pretty straightforward to code C in an object-oriented style.
The problem is really with Xt, which is the low-level "Widget" interface to X11. It is a slow, buggy, complete pile of garbage. I honestly feel sorry for the Motif guys, because they really wanted to use the "standard" Xt interface. As it stands, they had to write a lot of Xt-incompatible stuff for Motif to work right (keyboard shortcuts come to mind), but there's just no getting around the fact that Xt sucks huge.
This is completely wrong! I'm sorry, but you don't know what you're talking about.
Xt is rock solid, and highly consistent internally. Xt is basically just an object system and an event loop, all the policy and mechanism (implementation of dialogs and menubars, etc) is in the libraries built on Xt (Motif and Athena.)
Motif is bug-ridden, poorly architected, and breaks the object abstraction model left and right.
Athena is consistent and doesn't break the object model, but it also doesn't do much, and looks terrible (Athena doesn't even have proper menubars.)
The biggest mistake GTK made was not using Xt. Xt is just fine, and if they had built on Xt, then it would be possible to mix-and-match GTK, Athena, and Motif widgets in the same program, instead of having to rewrite the whole world.
Also Xrm (the X Resource Manager) would have worked.
What do you think that QT & GTK are missing to be a true replacement of Motif?
Well, for one, both QT and GTK lack the butt-ugliness of Motif. Secondly, they lack the quality that they're not as akin to bashing your head against the wall when programming with them. Thirdly, they're not archaic. That's about all I can think of..:^)
There are many fair criticisms that can be made of Motif (and I've made all of them,) I programmed Motif for years, and I've got more reason to hate it than most people.
But I've never, ever understood the ``Motif is ugly and GTK is beautiful'' argument, because they look the same to me. Seriously! Can someone explain to me why one of these is ugly and the other is beautiful:
Because I just don't see it. Except for the default font sizes, those look damned near identical to me.
I'd also be interested to hear in what way Motif is ``archaic'' while GTK is not.
And thirdly, I've found writing in GTK to be almost as much as a head-bashing experience as programming in Motif. The APIs are just as crazy, they're just different. One thing that GTK has going for it is that it's slightly less buggy. But it's also a hell of a lot slower.
Unless Microsoft can convince everyone that Windows media format is somehow better than mp3, ra etc there shouldn't be a problem.
This isn't about audio, it's about video.
But if you want to talk about audio, the thing Microsoft can offer people to make them use a MS audio format instead of MP3 is copy protection. We don't care, but content providers love that idea, remember.
Please keep this crap out of slashdot. By posting a hundred character word, you made the whole page be as wide as that line, and caused most of us to get horizontal scrollbars as a result.
There are three: QuickTime, RealVideo, and Microsoft's.
Personally I think that we should follow the already established standards - instead of reinventing the wheel time after time again. There is no need for a new standard, if the current is good enough.
With this I completely agree. The only standards that matter are de-facto standards. And they don't even have to be good, just good enough. And standard.
It may be that there will some day be a better standard for delivering video, and if there is, it will live or die on its technical merits (i.e., does it in fact play video better.) But until such a thing is invented, there are videos out there that I can't watch, and that problem needs to be fixed first.
Window management in an MP3 player is crazy!
on
XMMS 1.0.0 Released
·
· Score: 3
Why is it that every graphical MP3 players has to have its own "special" look? I want my title bar, dammit!
I agree!
I use XMMS, and I think it has a pretty nice UI, but it's complete lunacy that they felt the need to implement window management in an MP3 player!
Developers, if you want k-rad eleet title bars, use a k-rad eleet window manager. If you want to write a window manager, write a window manager. But don't force this inconsistency (in both appearance and functionality) on everybody who just wants to run an MP3 player. You aren't writing an ``MP3 Desktop'', you're just writing a damned app.
gkrellm does the same thing, and it's equally crazy.
Does anyone really believe boycotts do anything other than make the boycotter feel good? If everyone who ran Linux stopped going to movies, would the MPAA even notice?
Not that there's anything wrong with boycotting something because it makes you feel good, or with one-handed exercises in general. But do they actually effect social change? My guess is: never.
I'd like to hear suggestions for how to combat this kind of nonsense that sound a little more effective than sticking out your tongue at the corporations and saying ``yeah well I'm taking my toys and going home!''
Of course, all of these artists are definitiveely part of the "music establishment", and all were developed by money from the major music corporations. They are all among the best selling artists OF ALL TIME, and the major music corporations have gotten very rich from them and these artists have gotten very rich with the help of the corporations.
Have these artists gotten rich? Maybe they have, but I'm asking because I don't know, and it's certainly not a given.
What I'd like to see are some stats on how much money the various mega-stars have actually come away from the deal with. As anyone who watches ``Behind the Music'' knows, the artists often end up broke, and it's often for reasons other than ``they spent it all.''
Slashdot Mirror
I don't have a sense of what politicians in general, or even city politicians in particular, think of email, but something I've learned recently is that you can approach these people. I mean, you can just call up a city supervisor, make an appointment, and talk to them. That's their job!
If there's something about your city that you don't like, it is possible for you to go and do something about it. It can be a pain in the ass, but lots of things are.
If you care about late night culture in particular, join the San Francisco Late Night Coalition. In this case ``join'' means ``come to the monthly meetings.'' There is strength in numbers, and this group has a lot of members who have been doing this for a while and know the things you need to do to get yourself heard.
``Government'' is made up of people, specifically politicians and bureaucrats. To politicians, votes and image are also important. Those are the buttons you need to learn to push.
As someone else pointed out, you also need to put a script that does ``/usr/lib/sendmail -q'' into /etc/cron.hourly/ if you don't want your mail to get stuck at random.
But another useful trick, if there are certain machines you want to accept mail from and others that you don't, is to run sendmail under tcpd so that it obeys /etc/hosts.allow and /etc/hosts.deny, by adding this to /etc/inetd.conf:
smtp stream tcp nowait root /usr/sbin/tcpd /usr/lib/sendmail -bs
That way you can, for example, let specific machines on your subnet connect to your SMTP port without allowing the whole world to exploit the sendmail-bug-du-jour. (You can also do this with ipfwadm firewall rules, but I find hosts.allow to be easier to deal with.)
I generally prefer running services on my desktop machines (including sendmail and httpd) from inetd instead of having them always running as daemons in the background because that makes it easier to centralize control of their access lists, and because you don't have as many idle processes chewing up swap space. And since I'm the only one who ever connects to the http server on my desktop machine, the process-creation overhead is trivial (this wouldn't be such a good idea for a high volume web or mail server, obviously.)
It wasn't an argument, it was an insult. For it to have been an argument, the strawman to which it was a reply would have had to have been deserving of an argument. For example, not being absurd on its face would have been a good start.
That was a flame? ``You keep using that word. I think that you do not know what it means.''
Restrictions on smoking are based on employee safety laws, the idea that if you are an employer, you cannot require an employee to work in an environment known to be health-threatening. And believe it or not, second-hand smoke is known to be toxic. If it makes you feel better, it's easy to put an anarchist spin on this: ``your right to poison yourself ends where my lungs begin.''
California Labor Code 6404.5, Smoking in the Workplace.
Uh, yeah, sure. That probably sounded better when Rush Limbaugh said it, didn't it?
When has Slashdot ever been trustable as a news site? I like Slashdot, and it has a lot to recommend it, but journalistic excellence has never been one of those things: the so-called ``stories'' have always been poorly researched, highly biased, and half the time, just plain wrong.
Slashdot is a big set of bookmarks pointing at news reported by others; plus a discussion forum. As such it has value. But comparing Slashdot to Time is ridiculous.
I have pretty close to zero respect for Time's journalistic integrity, but Slashdot isn't even playing the same game. Not that Slashdot is worse, but that Slashdot isn't trying to do the same thing at all. It's apples and oranges.
Huh? You can't work around the fact that Xt doesn't treat timers firing as first-class event objects. And you sure can't work around it by calling select().
The API associated with XtAddInput() is screwy, but it's not ``broken'' in the sense of ``doesn't work as advertised'' or ``doesn't let you do the things you can do with select().''
That's what I meant about criticising the right parts: this part of Xt has a screwy design. But it is still usable, it's just goofy. And calling select() does not make it better, it just makes it less portable. So criticise it for being a dumb design, but don't say that it doesn't work, because it does work.
Uh, ok, except that what we're disagreeing over are not matters of opinion, but matters of fact.
Nothing I have said here has been advocating using Motif over using GTK. (I've hardly even mentioned Qt because I haven't used it, because it's C++.)
And GTK is set in stone now?
GTK is under active development, which means it can be fixed. GTK could easily be made to use the X Resource Manager as its basis for reading and storing preferences information. This could be done without breaking any existing apps: it could be a binary-compatible change.
But even if I'm wrong, and doing so would require incompatible changes, so what? They've done it before (there was a year when everyone had to have two versions of GTK installed because Gimp didn't work with the version of GTK that almost all other apps were written for.) They've had flag days before and they will have flag days again.
Changing GTK to be built on top of Xt widgets is probably impossible at this point. It would certainly be a colossal amount of work. But using Xrm resources wouldn't be hard.
Dismissing my criticisms of GTK's design because ``the decision has been made'' or ``that's living in the past'' is ridiculous. If a design mistake was made, even if that mistake is fully entrenched (like most of Unix), that mistake should be acknowleged so that people don't make similar mistakes in the future.
Or do you believe that no after-the-fact criticism ever has merit?
I don't recall XtAddInput ever being broken, which means that whatever code you saw was wrong.
In all of these posts, it may sound like I'm defending Xt or Athena or Motif, but I'm only defending them against things that people are saying that are just incorrect. Motif is a mess in a zillion ways, and there are lots of scathing criticisms that can be made of Xt, Xlib, and everything down the line. But it's important to bash them for things that are actually true!
In particular, while Xt's event model has some really stupid shit in it, you didn't mention those things. The things that bother me most are that timer and file-descriptor events aren't first-class events the way events are; and that widget finalization (the Phase2Destroy thing) is a complete mess.
Nonsense.
GNOME could have dictated, as a matter of policy:
Blammo, now you know where the file is, and now you can write a preferences editor that can overwrite that file. But you're still using the traditional programatic API for applications to consult their resources; and you've still left open the option for sophisticated users to use the more advanced features of the resource database, like using wildcards or screen- or display-specific settings.
Don't believe it can work? Well I've got something better than words, I've got working code that does exactly this. Download xscreensaver and run xscreensaver-demo. Note that you can edit all the parameters of the application. Note that it saves them to disk, specifically to a file called $HOME/.xscreensaver. This file contains resources! The xscreensaver daemon examines its resources with XrmGetResource() just like X programs have always done.
Using the X resource manager does not preclude having sophisticated, user-friendly customization UIs. And doing so leaves many options open for more sophisticated users.
I don't believe this. Please give an example. I especially don't believe this since using the X resource manager doesn't even mean that you have to use Xrm's file format. (I'll bet Gtk could just use that file format, but that's not a requirement.) I don't use Xrm's format in the .xscreensaver file, but I still merge it in to the in-memory resource database in the proper way anyhow.
Last time I looked, Gnome used the DOS/Windows INI-file format, but split into one file per app. That doesn't look particularly binary-capable to me. But anyway, what large binary data do you expect to store in these resource files by value rather than reference? (I.e., you want to store pathnames, not bitmaps.) For small binary data, just base64 it or something, like you'd have to do today anyway.
That very API could be easily implemented on top of the traditional X resource manager.
Too often people use customizability as a crutch. They say ``if you don't like it then change it'' instead of getting it right the first time. This is, to a large extent, what has been wrong with X from day one: by refusing to dictate policy, we ended up with a zillion crappy UIs instead of focussing all those people on fixing the same one that everyone was using.
We've seen it in this very thread! People excusing shitty performance and UI criticisms by saying ``well you're using the default theme, you dummy! If you'd only used my favorite theme, which you can download from this web site over here that's down right now...''
I'd rather have Developer X working on getting one core UI right than adding features and fixing bugs in the theme engine.
Themes are a cute, useless toy for people whose hobby is tweaking their desktop Because They Can. There's nothing wrong with that hobby per se, but those people are not the people you need to win over if you want your desktop to be a success.
No, what you described is the wrong way to do it. In fact, I think it doesn't work (or didn't used to) on VMS systems running DECnet, because calling XConnectionNumber() is not guarenteed to return something you can pass to select().
You seem to be unaware of XtAddInput() (and possibly also XtAddTimeout() and XtAddWorkProc().)
In a portable Xt program, one doesn't call select(), one calls XtMainLoop() (or XtNextEvent() and XtProcessEvent().)
In other words, it works exactly like it does in GTK.
I don't believe that Motif had to break abstraction to implement any of the things it implemented, Motif's implementation is just bad.
As I understand it, there's never been any real overall ownership of the Motif code base; it was written by six-month-contractor after six-month-contractor, with no small group of winners looking over it and keeping the worker bees honest.
Who's ``the Motif guy''? There isn't one. Even if you read the source code comments. The spec is one thing, but the implementation is another, and the implementation seems to have had no effective architectural guidance. That's my impression from having spent way too many hours digging around in the source, anyway.
Um. So?
You'd rather they provided XmDrawLine which did nothing but call XDrawLine? That would give you more things you needed to learn rather than less.
GTK is built on GDK. libm.a is built on libc.a. So what? That's what abstraction is.
That's a nice sound bite, but it's so vague that it doesn't actually tell me anything. Please be specific.
I totally agree with this.
For what it's worth, I have a kludge for making use of Xrm with GTK, but it's pretty fragile. Had GTK been built on top of Xt, then all the usual resource mechanisms would have worked automatically, and one would have been able to reuse the enormous body of Xt-aware code that is out there already. Among other things it would have been a lot easier to port Motif apps to GTK than it is today, because most of the implementation of any Motif or Athena application really consists of Xt calls.
If you want to see my evil kludge for using Xrm resources and command-line processing (but not Xt Widgets) from inside a GTK program, have a look at main() in driver/demo-Gtk.c in the xscreensaver distribution.
Please explain what the GTK event model can do that the Xt event model cannot. I think they are the same.
I do not believe that GTK's object model is fundamentally saner than Xt's.
GTK's objects are fundamentally saner than Motif's objects, but that's the implementation of the widgets, not the object model itself.
I can't comment on what it's like using Xt from C++, because C++ is an abomination that I would never use. But Xt makes it pretty straightforward to code C in an object-oriented style.
This is completely wrong! I'm sorry, but you don't know what you're talking about.
Xt is rock solid, and highly consistent internally. Xt is basically just an object system and an event loop, all the policy and mechanism (implementation of dialogs and menubars, etc) is in the libraries built on Xt (Motif and Athena.)
Motif is bug-ridden, poorly architected, and breaks the object abstraction model left and right.
Athena is consistent and doesn't break the object model, but it also doesn't do much, and looks terrible (Athena doesn't even have proper menubars.)
The biggest mistake GTK made was not using Xt. Xt is just fine, and if they had built on Xt, then it would be possible to mix-and-match GTK, Athena, and Motif widgets in the same program, instead of having to rewrite the whole world.
Also Xrm (the X Resource Manager) would have worked.
The GTK folks were crazy to not build on Xt.
There are many fair criticisms that can be made of Motif (and I've made all of them,) I programmed Motif for years, and I've got more reason to hate it than most people.
But I've never, ever understood the ``Motif is ugly and GTK is beautiful'' argument, because they look the same to me. Seriously! Can someone explain to me why one of these is ugly and the other is beautiful:
Exhibit B
Because I just don't see it. Except for the default font sizes, those look damned near identical to me.
I'd also be interested to hear in what way Motif is ``archaic'' while GTK is not.
And thirdly, I've found writing in GTK to be almost as much as a head-bashing experience as programming in Motif. The APIs are just as crazy, they're just different. One thing that GTK has going for it is that it's slightly less buggy. But it's also a hell of a lot slower.
Yeah, just not the version that most web sites use.
I think the answer to that is easy: because there are no freely available alternatives for streaming video.
This isn't about audio, it's about video.
But if you want to talk about audio, the thing Microsoft can offer people to make them use a MS audio format instead of MP3 is copy protection. We don't care, but content providers love that idea, remember.
Please keep this crap out of slashdot. By posting a hundred character word, you made the whole page be as wide as that line, and caused most of us to get horizontal scrollbars as a result.
That's your code for ``loser.''
There are three: QuickTime, RealVideo, and Microsoft's.
With this I completely agree. The only standards that matter are de-facto standards. And they don't even have to be good, just good enough. And standard.
It may be that there will some day be a better standard for delivering video, and if there is, it will live or die on its technical merits (i.e., does it in fact play video better.) But until such a thing is invented, there are videos out there that I can't watch, and that problem needs to be fixed first.
I agree!
I use XMMS, and I think it has a pretty nice UI, but it's complete lunacy that they felt the need to implement window management in an MP3 player!
Developers, if you want k-rad eleet title bars, use a k-rad eleet window manager. If you want to write a window manager, write a window manager. But don't force this inconsistency (in both appearance and functionality) on everybody who just wants to run an MP3 player. You aren't writing an ``MP3 Desktop'', you're just writing a damned app.
gkrellm does the same thing, and it's equally crazy.
Not that there's anything wrong with boycotting something because it makes you feel good, or with one-handed exercises in general. But do they actually effect social change? My guess is: never.
I'd like to hear suggestions for how to combat this kind of nonsense that sound a little more effective than sticking out your tongue at the corporations and saying ``yeah well I'm taking my toys and going home!''
Have these artists gotten rich? Maybe they have, but I'm asking because I don't know, and it's certainly not a given.
What I'd like to see are some stats on how much money the various mega-stars have actually come away from the deal with. As anyone who watches ``Behind the Music'' knows, the artists often end up broke, and it's often for reasons other than ``they spent it all.''
My favorite anti-music-industry rant: `` Some of your friends are probably already this fucked'' by Steve Albini.
Inoshiro wrote:
``You keep using that word. I think that you do not know what it means.''
Penultimate is not just a fancy way of saying ultimate. It means second-to-last.