> Someone writes a java app capable of searching Pi for a number series identical to the ASCII values of the text they wish to tranfer.
The only problem with this scenario is that the above-mentioned Java app would require more memory and computing power than encoding the same data on a crystal rod.
Damn, you are right there. I thought I was the only one having problems entering 8bit stuff into tcsh. I guess it's a feature you pay for, for having such nice command completion.
contrary to the popular belief that *csh shells are evil, tcsh absolutely rocks. Show me another shell with extensive programmable command completion like tcsh, and I'll switch tomorrow!
Yeah, I was referring to compressed size.
4.0.1 -> 4.0.2 was about 3.5 megs.bz2'd.
Of course it included major things like FreeType2, etc. Still beats the hell out of downloading ~40megs of source. If you notice, 4.0.3 release doesn't even have a source/ dir, just the patch.
XFree people know better:)
Also, most developers today choose not to make their programs accessible to all users. Most current GTK/GNOME and for the most part KDE apps are not keyboard accessible. For some people it's a very important issue in accepting Linux GUIs.
that's the problem. the toolkit does not support these kind of things properly.
For example multiple hotkeys on the same menu result in invoking the first menu with the matching key. Instead it should cycle through available menu choices. There are many other deficiencies related to keyboard accessibility.
pretty pointless. to make things clear, I am referring to menu hotkeys, not shortcuts:
For example, on most software the "File" menu has
"_F_ile" F underlined, and is accessed by doing something like alt-f, then each following entry in the menu that comes up is underlined also -
"_N_ew", "E_x_it", etc, so you can do a quick alt-f-x to exit the program. This isn't a good example since most people would simply press Ctrl-X or whatever is the shortcut to quit it, but for long menu paths, using keyboard to get somewhere is MUCH faster than mousing or cursor keys (think that GIMP example)
_Filters->_Render->_Pattern->_Grid
Is only 4 key presses at the most to get to it, and a lot easier to type than move the mouse from each menu to another.
Try when you want to quickly access some feature, and don't remember the shortcut key.
Most people remember menu path, i.e. "Filters->Render->Flare" much better than a shortcut key for the same feature.
developers should instead look into some of the problems the toolkit is currently facing.
One of the biggest problems is lack of "accessibility" features. Just try using any GTK app without using a mouse. Impossible, most of the time. Implementing accessibility features (menu shortcut keys, etc) is placed on the programmer, instead on the toolkit designers. There are numerous bugs and misfeatures when it comes to accessibility features in GTK.
One perfect example of this is "The Gimp" program, which cannot be operated from keyboard at all. None of the menus have "hotkeys", there is no keyboard shortcut to bring up "the menu", and once the menu is up, it's impossible to navigate it except using cursor keys, which is much slower than if all the menus had hotkeys assigned.
For someone who has never heard of this game, providing a link to "www.bwgame.com" will give absolutely no information. You see a pathetic flash animation of the game logo and are presented with a "order" button. Wow. Talk about advertising. Now I really don't want to get this because simply, I don't even know what the hell it is.
This doesn't seem to prevent me from buying my CD's at the store... I've never used CDDB, but at least with it's recent "deny of access" to things like Grip etc, I won't have to deal with seeing a new version of that stuff every 5 minutes on freshmeat.net
You guys are sure quick on the trigger.
I didn't even have a chance to look at it!
Re:Click a few pages further and you'll see...
on
Linux in 3D
·
· Score: 2
> "GIMP is 8-bit only. The Hollywood is planning a 16-bit version"
The bits referred to in that article are not related to total number of bits
in each pixel, but instead, number of bits in each channel - those channels
being red, green, blue and alpha. Currently, gimp only supports 8bits/channel,
which results in 24bit images with an 8 bit alpha channel. 16bits/channel
images would have higher quality, since instead of only 256 levels to
present a particular color brightness, there would be 65535 of them. I think
with the new gimp design planned for gimp 2.0/3.0 this issue will be addressed.
> Someone writes a java app capable of searching Pi for a number series identical to the ASCII values of the text they wish to tranfer.
The only problem with this scenario is that the above-mentioned Java app would require more memory and computing power than encoding the same data on a crystal rod.
Damn, you are right there. I thought I was the only one having problems entering 8bit stuff into tcsh. I guess it's a feature you pay for, for having such nice command completion.
contrary to the popular belief that *csh shells are evil, tcsh absolutely rocks. Show me another shell with extensive programmable command completion like tcsh, and I'll switch tomorrow!
Yeah, I was referring to compressed size. .bz2'd.
:)
4.0.1 -> 4.0.2 was about 3.5 megs
Of course it included major things like FreeType2, etc. Still beats the hell out of downloading ~40megs of source. If you notice, 4.0.3 release doesn't even have a source/ dir, just the patch.
XFree people know better
4.0.1 -> 4.0.2 patch was close to 4megs.
There must not be THAT many improvements if the patch is so small.
Also, most developers today choose not to make their programs accessible to all users. Most current GTK/GNOME and for the most part KDE apps are not keyboard accessible. For some people it's a very important issue in accepting Linux GUIs.
that's the problem. the toolkit does not support these kind of things properly.
For example multiple hotkeys on the same menu result in invoking the first menu with the matching key. Instead it should cycle through available menu choices. There are many other deficiencies related to keyboard accessibility.
pretty pointless. to make things clear, I am referring to menu hotkeys, not shortcuts:
For example, on most software the "File" menu has
"_F_ile" F underlined, and is accessed by doing something like alt-f, then each following entry in the menu that comes up is underlined also -
"_N_ew", "E_x_it", etc, so you can do a quick alt-f-x to exit the program. This isn't a good example since most people would simply press Ctrl-X or whatever is the shortcut to quit it, but for long menu paths, using keyboard to get somewhere is MUCH faster than mousing or cursor keys (think that GIMP example)
_Filters->_Render->_Pattern->_Grid
Is only 4 key presses at the most to get to it, and a lot easier to type than move the mouse from each menu to another.
Try when you want to quickly access some feature, and don't remember the shortcut key.
Most people remember menu path, i.e. "Filters->Render->Flare" much better than a shortcut key for the same feature.
developers should instead look into some of the problems the toolkit is currently facing.
One of the biggest problems is lack of "accessibility" features. Just try using any GTK app without using a mouse. Impossible, most of the time. Implementing accessibility features (menu shortcut keys, etc) is placed on the programmer, instead on the toolkit designers. There are numerous bugs and misfeatures when it comes to accessibility features in GTK.
One perfect example of this is "The Gimp" program, which cannot be operated from keyboard at all. None of the menus have "hotkeys", there is no keyboard shortcut to bring up "the menu", and once the menu is up, it's impossible to navigate it except using cursor keys, which is much slower than if all the menus had hotkeys assigned.
For someone who has never heard of this game, providing a link to "www.bwgame.com" will give absolutely no information. You see a pathetic flash animation of the game logo and are presented with a "order" button. Wow. Talk about advertising. Now I really don't want to get this because simply, I don't even know what the hell it is.
This doesn't seem to prevent me from buying my CD's at the store... I've never used CDDB, but at least with it's recent "deny of access" to things like Grip etc, I won't have to deal with seeing a new version of that stuff every 5 minutes on freshmeat.net
You guys are sure quick on the trigger.
I didn't even have a chance to look at it!
> "GIMP is 8-bit only. The Hollywood is planning a 16-bit version"
The bits referred to in that article are not related to total number of bits
in each pixel, but instead, number of bits in each channel - those channels
being red, green, blue and alpha. Currently, gimp only supports 8bits/channel,
which results in 24bit images with an 8 bit alpha channel. 16bits/channel
images would have higher quality, since instead of only 256 levels to
present a particular color brightness, there would be 65535 of them. I think
with the new gimp design planned for gimp 2.0/3.0 this issue will be addressed.