Because OO.org takes one minute to load? (nothing wrong with my system - don't bother asking the specs as if there is a problem.. OO.org is worse than Mozilla in that regard).
Authentic browser-edition is IE/Windows only with no plans for Mac/Linux.
I'm not saying anything good or bad about it, the.sps is ok, but just so everyone knows.
Does anyone know of any alternatives (obviously they can't stick to web standards, they want to provide a word processor in a browser, but is there something similar for Mozilla?)
Don't forget the CSS. By using overflow:auto on a fixed box you can make scrollbars, and emulate many types of layouts previously impossible without crummy old frames.
Design your urls so that they're content based, and not implementation based, so where possible hide PHP from the user. Hide filename extensions from the user unless they need them. Use slashes to show content hierarchy (eg. domain.com/story/2003/6/4/ rather than domain.com/story.php?year=2003&month=6&day=4). The HTTP GET key=value pairs should be avoided where possible, unless there is no hierarchy or many items. You'll probably need url rewriting for this.
The url should pass to a script that checks the cache, and obviously request a fresh copy if it needs it.
The backend architecture depends on the app. PHP is usually for the web, and elegant architecture for HTML involves themes. Here you have three options,
build the page up as a string,
build it up using a templating language's OO where you have table objects, and you attach row objects, which contain cell objects (similar to ASP.NET)
build it up using XML (my favourite)
Building the page as a string means that it's easier to have HTML flaws caused by one module affecting another (as PHPNuke has found). However, this is the most flexible method, if you want bizarre HTML. Dealing with strings is the older way of doing it, and I don't have much good to say about it this. In many templating engines the goal is to try and invent a simpler syntax, and then 2 years later they've implemented their own programming language. There is no such thing as simple logic when it comes to layout and HTML, and these "simple" languages often have little thought put into them, and don't allow reuse, or extensions via modules. They often end up being hacks. There are some mature examples that have solved this problem (PHP Smarty, who have simply implemented PHP in a templating language!) and these may be suitable.
Building the page using an OO means that you have a IMAGE object that has properties such as ALT text. That body object can only have certain other objects attached. You have a programatic way of dealing with a page, and you're not limited to a templating software's mini-language. However, you'll probably need to be a programmer to change the themes so you can't hand the code off to designers. It's the ASP.NET model, although there are better ways of doing it.
Building up a page in XML is elegant, in that you can refer to an XML node and attach/remove branches. You can pass nodes to PHP modules and let them attach content, knowing that all tags will be closed. You can enforce a schema/dtd on your content, and maintain a high-level language up until the moment that you publish to HTML, probably using XSL-T to theme the page.
The XML method is the best balance, IMO. XSL-T is very suited to formatting HTML, and if you want you can go to PDF via XSL-FO quite easily. I recommend building an XML file like XHTML 2.0 and then XSLTing that down to XHTML1/HTML for the cache.
As for how you handle the data, I don't really care. Personally I'm waiting for PHP5 to bother OOing my PHP.
My main gripe with PHP is that not enough is included in the default build that comes with distros and is offered for windows download. So that the generic hosts don't have the feature you need. The people who care about trim build know how to trim it more than those who don't care and end up avoiding features.
I was trying to respond earlier, but Slashdot still haven't unblocked a large...large range of IPs from posting (presumably it's not something I've done, as this account is available). Don't even bother emailing them folks, my 3 emails haven't got one answer:(
Vector is unpredictable? In that case bitmap is unpredictable too - just change your resolution and the button that was readable is now tiny and in a different place on the screen!
A good toolkit can make vector interfaces predictable, and like font hinting a toolkit could slightly alter the vector shape when rasterising to low resolutions. The programmer never need deal with such issues, but the point is that vectors aren't inherently unusable - a toolkit can deal with all the issues surrounding vector graphics (just like the bitmap graphics libraries do).
One thing I like about Gnome is that the default size is quite large (I'm guessing, but they're obviously not 16x16 or 32x32, they look like the icons start at 64x64 or something like that). Windows (all versions) is still getting smaller each year as people (on average) increase their resolution. OS9 was getting tiny and difficult to see. OSX is better.
Back in 1985 with 320x200/640x480 resolution we had icons that were 16x16. On a 14inch (35cms) screen at 320x200 that would be about 0.7inches (1.7cms) square (I know this is fuzzy math, that screens aren't square and that the viewable size of a screen would less than 14 inches, but you get the idea). Now it's not uncommon to find trays of buttons 0.3inches (1cm) and smaller on screens.
These problems are because of bitmaps, and I don't see any inherent problems in vectors that toolkits can't address.
People need to get out of the idea that increasing screen resolution makes things smaller - desktops should be like any 3D game in the last 10 years where increasing your resolution just adds to the detail.
I agree that 3D is usuable, though mostly because most interfaces need 2D text.
The move to Unicode is needed for internationalisation, and it's one area where Linux is far behind Windows and OSX. For example, try having a login where your full name is in maori or some arabic language. Like the html + browser arguments that rage about whose fault it is when pages don't render correctly, you can't say that it's the web browser at fault or that it's the HTML at fault - it's just that they don't like each other. Unicode isn't soley at fault, and software should be able to handle it. A text editor defaulting to utf-8 is reasonable though.
What I've come to learn is that responsibility only matters inside the industry, and most people don't care whose responsibility it is they just want it fixed. If a bit of software can stop IE from crashing then that's a good thing and most users will like it.
It's funny that you use the virus checker example. It's the responsibility of virus makers not to make them and affect others machines, yet they do it anyway.
Responsibility is about blame, and it's a human-level concept, outside of what's going to happen, and outside of nature.
Virus checkers have gotten into the system stability software game a while ago, because so far as the user is concerned it's all related. I guess this will be tacked on that.
It's very unlikely that defending against a student caught copying music would have any chance of winning. That's what this whole story is about - avoiding insane laws. Here the request is to herd students into not breaking insane laws. The students know it's wrong but they do it anyway. They need some kind of reminder, and it doesn't need to be harsh. They have the information, and they're doing it anyway. They're not being reasonable, and they're hoping they don't get caught. It may not be feral, but it's childish. I hate the RIAA as much as the next guy, because they're not defending their rights, they're trying to gain ground into what people were able to do. But these people need a good scare.
Oh, and while you may think I'm kidding - I very much doubt that people will do anything until it seems real to them. They wouldn't take CDs from a store, but they'll download because they think they're not being watched.
So watch them before the RIAA do, and make a big deal about it. If you don't want to go public that's fine, but make sure all the students know that the law could be watching as easily as you were. Also, if handled right, you can come off as the good guy.
You don't need special support to merely use it, but you need special support to make it work as good as it can. Although it acts like two CPUs it's physically one and it behalves slightly differently to a dual CPU machine.
If the authors genuinely agree then they can release it under the GPL. If the authors can genuinely agree they can stop releasing under the GPL and release under another licence (that is 'closed').
The funny thing is that the same people who complain about whitespace languages insist on a formatting style. The real complaints come from people wanting to continue using their favourite text editor, no matter how broken it is (in that it changes tabs to spaces, etc.).
(yeah yeah, april fools, but I refuse to make this site useless for the next 24 hours)
With the advent of the web, I predict that the quality of Gopher will go down the hole as Netscrapers start saying random shit whenever something seems interesting for a moment. The scrapers will become watered down by passing distractions, people will lose interest, and the web will go the way of the narccicistic "this is me, this is 8,000 pictures of me, here are my favorite movies, blah blah blah" sites.
*on a default install of Windows ME, Windows 2000 Server, Windows Xp, Mandrake 8, MacOSX when I just click the next button and then start it up cold.
Because OO.org takes one minute to load? (nothing wrong with my system - don't bother asking the specs as if there is a problem.. OO.org is worse than Mozilla in that regard).
Of course, the player itself is 65 gig...
(guess I shouldn't have used Delphi)
It's in no stable state now, but they've got the interface right, and they seem eager.
Nigga please...
I'm not saying anything good or bad about it, the .sps is ok, but just so everyone knows.
Does anyone know of any alternatives (obviously they can't stick to web standards, they want to provide a word processor in a browser, but is there something similar for Mozilla?)
Thanks, reading now...
Don't forget the CSS. By using overflow:auto on a fixed box you can make scrollbars, and emulate many types of layouts previously impossible without crummy old frames.
Design your urls so that they're content based, and not implementation based, so where possible hide PHP from the user. Hide filename extensions from the user unless they need them. Use slashes to show content hierarchy (eg. domain.com/story/2003/6/4/ rather than domain.com/story.php?year=2003&month=6&day=4). The HTTP GET key=value pairs should be avoided where possible, unless there is no hierarchy or many items. You'll probably need url rewriting for this.
The url should pass to a script that checks the cache, and obviously request a fresh copy if it needs it.
The backend architecture depends on the app. PHP is usually for the web, and elegant architecture for HTML involves themes. Here you have three options,
Building the page as a string means that it's easier to have HTML flaws caused by one module affecting another (as PHPNuke has found). However, this is the most flexible method, if you want bizarre HTML. Dealing with strings is the older way of doing it, and I don't have much good to say about it this. In many templating engines the goal is to try and invent a simpler syntax, and then 2 years later they've implemented their own programming language. There is no such thing as simple logic when it comes to layout and HTML, and these "simple" languages often have little thought put into them, and don't allow reuse, or extensions via modules. They often end up being hacks. There are some mature examples that have solved this problem (PHP Smarty, who have simply implemented PHP in a templating language!) and these may be suitable.
Building the page using an OO means that you have a IMAGE object that has properties such as ALT text. That body object can only have certain other objects attached. You have a programatic way of dealing with a page, and you're not limited to a templating software's mini-language. However, you'll probably need to be a programmer to change the themes so you can't hand the code off to designers. It's the ASP.NET model, although there are better ways of doing it.
Building up a page in XML is elegant, in that you can refer to an XML node and attach/remove branches. You can pass nodes to PHP modules and let them attach content, knowing that all tags will be closed. You can enforce a schema/dtd on your content, and maintain a high-level language up until the moment that you publish to HTML, probably using XSL-T to theme the page.
The XML method is the best balance, IMO. XSL-T is very suited to formatting HTML, and if you want you can go to PDF via XSL-FO quite easily. I recommend building an XML file like XHTML 2.0 and then XSLTing that down to XHTML1/HTML for the cache.
As for how you handle the data, I don't really care. Personally I'm waiting for PHP5 to bother OOing my PHP.
My main gripe with PHP is that not enough is included in the default build that comes with distros and is offered for windows download. So that the generic hosts don't have the feature you need. The people who care about trim build know how to trim it more than those who don't care and end up avoiding features.
I was trying to respond earlier, but Slashdot still haven't unblocked a large...large range of IPs from posting (presumably it's not something I've done, as this account is available). Don't even bother emailing them folks, my 3 emails haven't got one answer :(
try ipcop
A good toolkit can make vector interfaces predictable, and like font hinting a toolkit could slightly alter the vector shape when rasterising to low resolutions. The programmer never need deal with such issues, but the point is that vectors aren't inherently unusable - a toolkit can deal with all the issues surrounding vector graphics (just like the bitmap graphics libraries do).
One thing I like about Gnome is that the default size is quite large (I'm guessing, but they're obviously not 16x16 or 32x32, they look like the icons start at 64x64 or something like that). Windows (all versions) is still getting smaller each year as people (on average) increase their resolution. OS9 was getting tiny and difficult to see. OSX is better.
Back in 1985 with 320x200/640x480 resolution we had icons that were 16x16. On a 14inch (35cms) screen at 320x200 that would be about 0.7inches (1.7cms) square (I know this is fuzzy math, that screens aren't square and that the viewable size of a screen would less than 14 inches, but you get the idea). Now it's not uncommon to find trays of buttons 0.3inches (1cm) and smaller on screens.
These problems are because of bitmaps, and I don't see any inherent problems in vectors that toolkits can't address.
People need to get out of the idea that increasing screen resolution makes things smaller - desktops should be like any 3D game in the last 10 years where increasing your resolution just adds to the detail.
I agree that 3D is usuable, though mostly because most interfaces need 2D text.
In the same way Window's DLLs are copied to RAM, yes.
The move to Unicode is needed for internationalisation, and it's one area where Linux is far behind Windows and OSX. For example, try having a login where your full name is in maori or some arabic language. Like the html + browser arguments that rage about whose fault it is when pages don't render correctly, you can't say that it's the web browser at fault or that it's the HTML at fault - it's just that they don't like each other. Unicode isn't soley at fault, and software should be able to handle it. A text editor defaulting to utf-8 is reasonable though.
Woah...
But then, as I said, NN4 crashes for all manner of reasons.
What I've come to learn is that responsibility only matters inside the industry, and most people don't care whose responsibility it is they just want it fixed. If a bit of software can stop IE from crashing then that's a good thing and most users will like it.
It's funny that you use the virus checker example. It's the responsibility of virus makers not to make them and affect others machines, yet they do it anyway.
Responsibility is about blame, and it's a human-level concept, outside of what's going to happen, and outside of nature.
Virus checkers have gotten into the system stability software game a while ago, because so far as the user is concerned it's all related. I guess this will be tacked on that.
It's very unlikely that defending against a student caught copying music would have any chance of winning. That's what this whole story is about - avoiding insane laws. Here the request is to herd students into not breaking insane laws. The students know it's wrong but they do it anyway. They need some kind of reminder, and it doesn't need to be harsh. They have the information, and they're doing it anyway. They're not being reasonable, and they're hoping they don't get caught. It may not be feral, but it's childish. I hate the RIAA as much as the next guy, because they're not defending their rights, they're trying to gain ground into what people were able to do. But these people need a good scare.
So watch them before the RIAA do, and make a big deal about it. If you don't want to go public that's fine, but make sure all the students know that the law could be watching as easily as you were. Also, if handled right, you can come off as the good guy.
Ok, try that and get back to me. I wanna see how this pans out.
You sick bastard.
You don't need special support to merely use it, but you need special support to make it work as good as it can. Although it acts like two CPUs it's physically one and it behalves slightly differently to a dual CPU machine.
If the authors genuinely agree then they can release it under the GPL. If the authors can genuinely agree they can stop releasing under the GPL and release under another licence (that is 'closed').
(yeah yeah, april fools, but I refuse to make this site useless for the next 24 hours)
There are about 5 op code caches about for PHP.