However I think that with his drag and drop saving/renaming he misses an important user interface concept: guiding the user.
[with menus] the user always has something in the hand telling him how to accomplish the next step in his task.
It works like this (for a new user):
Open menu and choose Save, or click on the Save button on the toolbar.
A Savebox appears, containing a draggable icon.
Windows-user clicks on Save button.
Since there is no current save path set, a message box appears telling the user to drag the icon to a directory viewer.
..nice in that you could see exactly where you were saving it, but not nice in that if you clicked "save" and type in a name only to realise the window you want to save it in isn't visible.
Some of the later RISC OS programs (eg, StrongEd) would keep the savebox open while you opened the directory, and this system is used in ROX too (and, window manager permitting, the savebox can be kept above all other windows during this process).
Of course with multi-level undo you don't have to "blink" 'em to find 'em, so it really is an improvement.
Sounds like you want '. -- move to last change in this file, but without doing an undo.
See also Ctrl-O and Ctrl-I to move back and forth through the stack of significant positions...
Re:Hear hear! Vi has its points...
on
Blender Is GPL
·
· Score: 2
Since then I've occasionally seen an emacs-ism that has tempted me - like colored displays of comments vs. declarations vs. code. But every time I'm tempted I watch a colleague doing simple text editing with emacs, and count the keystrokes he has to use to do the simple stuff that constitutes the bulk of my editing work. And it always seems to take him a lot more strokes with emacs than it takes me with vi. So I'm generally not tempted for long.
Why not use Vim then... syntax highlighting, multi-level undo and all the other goodies, but with the efficient VI key bindings:-)
Re:Recycle Bins - don't you just hate them?
on
Undelete In Linux
·
· Score: 2
But still, no matter how long you've been a linux user it's still possible to accidently type "rm core *" rather than "rm core*" and not catch it until half a second after you hit enter and realize that you have irrecoverably destroyed your project(you didn't really want to punish it for segfaulting).
$ rm core *
zsh: sure you want to delete all the files in/bin [yn]?
I think the biggest problem you'd have in adopting a digital voting system would be making it simple enough so that most people could understand it.
Right. It doesn't actually matter how open the software is, we need a way for people to verify that the votes were counted correctly, even if the voting system is a black box.
I don't see the problem, though. Each person should make up a random (so anonymous) tag line and add it to their vote. Afterwards, a list of all tag lines and votes is put on the web.
Each person downloads the list and verifies that:
Their tag line is listed, with the correct vote.
There are the same number of votes as voters.
The totals for the votes are correct.
Then, everyone can be sure that the result is correct, whatever technology was used.
The only issues are of people not voting and making sure that the tags can't be associated with individuals (ie, you present yourself to vote and pick up a token from a pile, then go and use that to vote or something).
For example, I can't understand why a user cannot change the resolution of his screen. It's trivial to implement. Let root build the system XF86Config, and let users control only the "Screen" section in their.xf86config. Build a nice GUI tool around it, and you're ready.
I think the command you're looking for is 'xrandr' (rotate and resize).
$ xrandr --help usage: xrandr [options] where options are: -display <display> or -d <display> -help -o <normal,inverted,left,right,0,1,2,3> or --orientation <normal,inverted,left,right,0,1,2,3> -q or --query -s <size> or --size <size> -v or --verbose or --screen <screen>
I set up Linux for my parents, and it's worked really well. Just one thing, though: use a journalling filesystem (tune2fs -j and edit fstab is all it takes).
You really don't want to have to explain 'Enter root password' and ask which device is the problem after a power failure (yes, it's not hard, but it gives a bad impression).
> Another example is that in metacity, clicking anywhere on a window raises it.
Read the Metacity README file! This is one of Metacity's precious few user options.
I've read the README for version 2.3.987 (current Debian/unstable), but I can't see this anywhere. Has it changed in the last few weeks?
Currently, Metacity is placed rather low on ROX-Session's default list of window managers due to this problem:-(
The ability to interact with a window, move and resize it without it jumping in front of other windows is vital in an environment where windows can overlap.
I think RISC OS had the best solution to this:
Operations with button-1 would raise the window (Windows style), while button-2 would do the same thing without. No options, no confusion, no annoyance:-)
I would argue that int *foo means foo dereferenced is a segfault unless you've assigned a meaningful value to the pointer foo.
We only care about the type of *foo, not its value. We can talk about the type of *foo even if foo doesn't point to a valid address, just as we can do sizeof(*foo) without causing a segfault.
The type of *foo is char.
Stack space is allocated for foo (not *foo). It wouldn't make sense to allocate space for the thing pointed to.
You could argue that it's confusing to specify
the type of one thing and the storage of another,
but this model has the advantage that it actually gives the correct answer. Unlike 'char* foo, bar', which the other model fails to cope with.
OTOH, char* foo is arguably more logical than char *foo. You are declaring foo as being of type "character pointer". You are not, in fact, declaring a char with a pointer to it named foo (you never declared the char, only the pointer), which is what is implied by your recommended form.
*foo means 'foo dereferenced'. In a type declaration, 'int foo' means 'foo is an int', so 'int *foo' means 'foo dereferenced is an int'. And, therefore, foo is a pointer to an int.
So, it's actually quite logical. In this:
'char foo, *bar', we declare that two things have
type 'char': foo, and the thing that bar points
to.
You start with a pile of things you want to sort (eg, by size).
Take one at random and place it directly in front of you. This item is called the 'pivot'.
Now, we're going to create two piles; one to the left and one to the right of this first item.
Take another item from the original pile. If it's smaller than the pivot, place it in the pile to the left, otherwise place it in the pile to the right.
When you've gone through all the remaining items like this, you'll have two small piles to sort instead of one big one.
You can either sort these smaller piles by eye, or use this method again on each one.
Explaining why it's fast without maths is somewhat harder...
A standard widget and graphical component library. I don't care if you use GTK+, Qt, Motif or some other more or less perverted set of functions, they should all result in using the same components with the same look and feel. Let's say you create a menu in GTK+ with the ordinary commands. These instructions should be converted to draw the standard toolbar, using the user preference (menubar on top, in window, detachable...).
Well, you're probably right. The problem is X's
extension mechanism. Doing this means sticking a whole load of code in the X server. And, since different people will want different styles, the user has to be able to choose which widget set to install (but, once installed, all applications will use it).
Unfortunately, X runs as root. This means that it's already a huge security/stability risk, and letting users customise it would be unthinkable.
Anyway, fix the must-run-as-root problem and the way opens up to add all kinds of new features to X
since you don't have to audit every line...
Highlighting of text with the mouse, both in X (and on the normal console if you have the mouse working) should do "Copy to the Primary Selection".
No. There is no copying done when selecting. Middle-paste pastes the currently selected text. If you select some text and then unselect it, you can't middle button paste.
QT has got this right since at least version 2.0, the version of Gnome that came with RH7.2 still didn't.
Qt used to be completely broken. Try this:
Open KWord (1.1.1 here)
Write 'selection' and 'clipboard'.
Select 'clipboard' and Edit->Copy.
Select 'selection'.
Click the middle button.
'clipboard' is pasted instead of the selection.
Now do the same in gedit. Note that it works correctly here.
This has apparently been fixed in newer versions of KDE.
This is the one area that bothers me too. It really hacks me off when I use a GNOME app that doesn't undersand that highlighting=copy and middle button=paste.
Here's how it's supposed to work:
Middle button pastes the currently selected text.
Ctrl+C, Ctrl-X, Ctrl-V copy, cut and paste with a hidden 'clipboard'.
Early versions of Qt got this wrong, and therefore didn't work well with GNOME. Recent versions of
both get it right.
The GNU Mach microkernel is something of a performance dog, but at this point the HURD is still at a development only stage anyway so it doesn't much matter. It will probably be moved to an L4 microkernel instead before it's used in production machines. The L4 family gives much improved performance. Still slower than a highly tuned monolithic kernel like Linux, particularly on uniprocessor systems, but much closer.
Interestingly, a paper linked from the L4 pages
describes how Linux was ported to L4:
For L4Linux, the AIM benchmarks report a maximum throughput which is only 5% lower than that of native Linux. The corresponding penalty is 5 times higher for a co-located in-kernel version of MkLinux, and 7 times higher for a user-level version of MkLinux. These numbers demonstrate both that it is possible to implement a high-performance conventional operating system personality above a -kernel, and that the performance of the -kernel is crucial to achieve this.
They go on to say that they were able to get complete binary compatibility, including kernel device drivers, and were running X happily.
This kind of thing, coupled with the recent user-land filesystems in Linux, makes it look like Linux may eventually become a micro-kernel by the `back-door'...
I can tell you from past experience that using GTK+ can be somewhat painful. They tend to not demo portions of code which highlight bugs.
Yes, but I've been updating ROX-Filer to work with the Gtk+-1.3.x series since 1.3.6, so it has had real-world testing (from many other people's programs, too).
The current CVS snapshots should work with Gtk+-2.0 if you want some 'proper' testing (although obviously this is the CVS copy, so usual disclaimers apply).
Of course, they didn't fix all the bugs for 2.0, as they're desparate to get GNOME-2 out, but I haven't seen any major problems in Gtk+-2.0 yet, or in the release candidate.
I agree with that entirely. On Solaris GTK-1.3.15 is pretty much unusable, segfaulting all over the place.
I'm on a bit of a downer though, having spent *ages* building GTK-1.3 and the GNOME-2 beta and finding roughly every other operation I try causes a crash.:-(
Is that GNOME or Gtk, though? The GNOME stuff is only beta...
What happens if you run the gtk-demo program supplied with Gtk? I've been tracking the development versions for quite a while (not on Solaris, though) and I've found it pretty stable.
New font system
on
GTK+ 2.0
·
· Score: 5, Informative
One of the main new features is the completely new font system:
Everything is in UTF-8 (so no more charset headaches:-)
AA fonts using XRENDER (do GDK_USE_XFT=1; export GDK_USE_XFT in your.xsession to enable them).
Sane font-chooser dialog, where you just select the font name, weight and size, instead of the previous multi-paned mess.
Lots of routines for laying out paragraphs, positioning text cursors, etc, for people doing their own text layout.
On the negative side, the new font system seems much slower than before. Also it's completely incompatible with Gtk+-1.2, so anyone working with fonts has a massive updating task ahead.
One cool new feature is that the default font is stored on the display, using the new XSettings system. This means that when you run a program on a remote machine, or as another user, etc, you don't lose your settings.
Real (draft) release notes
on
GTK+ 2.0
·
· Score: 5, Informative
The linked message only talks about proposed changes to the draft release notes... here are the release notes themselves (also draft):
In GTK (the version used in Gnome 1.4 and I think in Gnome 1.2) you can select text with the right mouse button. This text is not copied, but it is replaced when you paste text using the middle mouse button (it is highlighted in gray rather than blue, with the default theme).
This feature has been removed in 2.0, due to fears
that it would confuse users coming from Windows.
Ctrl-U could be used to remove the existing text
up to Gtk+-1.3.13, but that seems to have gone too now (at least in 1.3.14; not sure if this is a bug or not).
You're right that GNOME1 applications don't work *on* GNOME2, but they do work *with* GNOME2, since the GNOME1 libraries are fully parallel installable with the GNOME2 libraries.
I had a look at the GNOME2 stuff a while back, but
it looked like you couldn't (easily) install python-gnome without breaking all existing python-gnome (and pygtk) apps from 1.2. Has this changed yet?
The problem is that, while the Gtk developers renamed the libraries (with a 2 suffix), the python bindings still call the package 'gtk'.
So, 'import gtk' could get you either version, and
the APIs are totally different (even more than
between the C APIs).
Slashdot Mirror
It works like this (for a new user):
See this screenshot (near the bottom of the page).
Some of the later RISC OS programs (eg, StrongEd) would keep the savebox open while you opened the directory, and this system is used in ROX too (and, window manager permitting, the savebox can be kept above all other windows during this process).
Sounds like you want '. -- move to last change in this file, but without doing an undo.
See also Ctrl-O and Ctrl-I to move back and forth through the stack of significant positions...
Why not use Vim then... syntax highlighting, multi-level undo and all the other goodies, but with the efficient VI key bindings :-)
$ rm core * /bin [yn]?
zsh: sure you want to delete all the files in
Maybe you're using the wrong shell ;-)
Right. It doesn't actually matter how open the software is, we need a way for people to verify that the votes were counted correctly, even if the voting system is a black box.
I don't see the problem, though. Each person should make up a random (so anonymous) tag line and add it to their vote. Afterwards, a list of all tag lines and votes is put on the web.
Each person downloads the list and verifies that:
- Their tag line is listed, with the correct vote.
- There are the same number of votes as voters.
- The totals for the votes are correct.
Then, everyone can be sure that the result is correct, whatever technology was used.The only issues are of people not voting and making sure that the tags can't be associated with individuals (ie, you present yourself to vote and pick up a token from a pile, then go and use that to vote or something).
I think the command you're looking for is 'xrandr' (rotate and resize).
You really don't want to have to explain 'Enter root password' and ask which device is the problem after a power failure (yes, it's not hard, but it gives a bad impression).
Read the Metacity README file! This is one of Metacity's precious few user options.
I've read the README for version 2.3.987 (current Debian/unstable), but I can't see this anywhere. Has it changed in the last few weeks?
Currently, Metacity is placed rather low on ROX-Session's default list of window managers due to this problem :-(
The ability to interact with a window, move and resize it without it jumping in front of other windows is vital in an environment where windows can overlap.
I think RISC OS had the best solution to this: Operations with button-1 would raise the window (Windows style), while button-2 would do the same thing without. No options, no confusion, no annoyance :-)
We only care about the type of *foo, not its value. We can talk about the type of *foo even if foo doesn't point to a valid address, just as we can do sizeof(*foo) without causing a segfault.
You could argue that it's confusing to specify the type of one thing and the storage of another, but this model has the advantage that it actually gives the correct answer. Unlike 'char* foo, bar', which the other model fails to cope with.
*foo means 'foo dereferenced'. In a type declaration, 'int foo' means 'foo is an int', so 'int *foo' means 'foo dereferenced is an int'. And, therefore, foo is a pointer to an int.
So, it's actually quite logical. In this: 'char foo, *bar', we declare that two things have type 'char': foo, and the thing that bar points to.
Explaining why it's fast without maths is somewhat harder...
Well, you're probably right. The problem is X's extension mechanism. Doing this means sticking a whole load of code in the X server. And, since different people will want different styles, the user has to be able to choose which widget set to install (but, once installed, all applications will use it).
Unfortunately, X runs as root. This means that it's already a huge security/stability risk, and letting users customise it would be unthinkable.
Anyway, fix the must-run-as-root problem and the way opens up to add all kinds of new features to X since you don't have to audit every line...
Put ROX-Filer itself in the Send To menu. Then Shift+Menu on the selected files and use that :-)
If you try going between Kword and gedit you'll see:
No. There is no copying done when selecting. Middle-paste pastes the currently selected text. If you select some text and then unselect it, you can't middle button paste.
QT has got this right since at least version 2.0, the version of Gnome that came with RH7.2 still didn't.
Qt used to be completely broken. Try this:
Now do the same in gedit. Note that it works correctly here.
This has apparently been fixed in newer versions of KDE.
Here's how it's supposed to work:
- Middle button pastes the currently selected text.
- Ctrl+C, Ctrl-X, Ctrl-V copy, cut and paste with a hidden 'clipboard'.
Early versions of Qt got this wrong, and therefore didn't work well with GNOME. Recent versions of both get it right.Interestingly, a paper linked from the L4 pages describes how Linux was ported to L4:
For L4Linux, the AIM benchmarks report a maximum throughput which is only 5% lower than that of native Linux. The corresponding penalty is 5 times higher for a co-located in-kernel version of MkLinux, and 7 times higher for a user-level version of MkLinux. These numbers demonstrate both that it is possible to implement a high-performance conventional operating system personality above a -kernel, and that the performance of the -kernel is crucial to achieve this.
They go on to say that they were able to get complete binary compatibility, including kernel device drivers, and were running X happily.
This kind of thing, coupled with the recent user-land filesystems in Linux, makes it look like Linux may eventually become a micro-kernel by the `back-door'...
Yes, but I've been updating ROX-Filer to work with the Gtk+-1.3.x series since 1.3.6, so it has had real-world testing (from many other people's programs, too).
The current CVS snapshots should work with Gtk+-2.0 if you want some 'proper' testing (although obviously this is the CVS copy, so usual disclaimers apply).
Of course, they didn't fix all the bugs for 2.0, as they're desparate to get GNOME-2 out, but I haven't seen any major problems in Gtk+-2.0 yet, or in the release candidate.
I'm on a bit of a downer though, having spent *ages* building GTK-1.3 and the GNOME-2 beta and finding roughly every other operation I try causes a crash. :-(
Is that GNOME or Gtk, though? The GNOME stuff is only beta...
What happens if you run the gtk-demo program supplied with Gtk? I've been tracking the development versions for quite a while (not on Solaris, though) and I've found it pretty stable.
On the negative side, the new font system seems much slower than before. Also it's completely incompatible with Gtk+-1.2, so anyone working with fonts has a massive updating task ahead.
One cool new feature is that the default font is stored on the display, using the new XSettings system. This means that when you run a program on a remote machine, or as another user, etc, you don't lose your settings.
Draft release notes for Gtk
Or just click the middle button in the main browser (HTML) area...
This feature has been removed in 2.0, due to fears that it would confuse users coming from Windows. Ctrl-U could be used to remove the existing text up to Gtk+-1.3.13, but that seems to have gone too now (at least in 1.3.14; not sure if this is a bug or not).
I had a look at the GNOME2 stuff a while back, but it looked like you couldn't (easily) install python-gnome without breaking all existing python-gnome (and pygtk) apps from 1.2. Has this changed yet?
The problem is that, while the Gtk developers renamed the libraries (with a 2 suffix), the python bindings still call the package 'gtk'.
So, 'import gtk' could get you either version, and the APIs are totally different (even more than between the C APIs).