I don't know where to get it, other than apt-get install gaby. It's a VERY light database-type thing without an actual database. It's perfect for organizing small amounts of relatively simple information, like a comic book collection, or names and addresses.
What's more, it's GUI and can be installed easily right now. No need for any learning at all.
It's way, way too simple for most uses, but this guy doesn't want a relational database, he wants a laymans Database, which s just the storage of data. And gaby does that perfectly.
From the control file description:
Gaby is a _small_ personal databases manager for Linux
using GTK+ and Gnome for its GUI. .
It was designed to provide straight-forward access to databases
a 'normal' user would like (addresses, books,...) while keeping
the ability to easily create databases for other needs. On a
technical side it was designed with extensibility in mind and
thus use relies a lot on plug-ins.
Well, here's a well known humorous example of a way it could be done without even abandoning the Latin alphabet, although it would require a certain Latinization of English vowels (which would actually be a bit of alright).
It was seeing a printed copy of that (or a variation) many years ago which got me seriously thinking about the subject.
Here's an interesting page that might provoke thought:
I have developed my own simplified spelling system, but I continue to run into trouble. Consonants can be handily reformed into a satisfyingly sane system, but vowels prove more difficult. I am constantly torn between 'simplifying' the language by reducing the number of vowel symbols and faithfully producing enough so that every variant of accent can be distinctly represented.
My current end result, dissatisfying though it is, bears a remarkable similarity to that to which your second link pointed, not counting the final transofmation into nonlatin characters.
This pleases me somewhat.
Further investigation suggests unifon is to my tastes.
There have been a few phonetic alphabets proposed that would make the written English language nearly as phonetic as the Spanish. They've existed for over 100 years.
Fascinating. I've wanted to do this myself. Would you care to name one/some of these proposed phonetic alphabets? I'm sure they'd be better than my poor attempts, and I'd be delighted to learn to use them.
Well, as said, I want a clipboard that does not go away when I select a piece of text with my mouse anywhere.
You have it.
That's my one and only concern. Too often have I copied an E-Mail address somewhere (and closed the window afterwards) only to figure out that the middle click in the destination window either gives me nothing (dont ask me why, happens frequently) or some completely unrelated text that I clickrolled over by accident while shuffling windows around...
Repeat after me: Middle click does not access the clipboard. If it were supposed to, you'd be right about brokenness. It doesn't, and it shouldn't. Some FEW and decreasing numbers of applications ignore and or treat as one the clipboard and selection buffer.
I think you're splitting hairs here. A driver could mean lots of things. What you call true Windows drivers are nothing more than DLL's themselves (.sys files in Win2k,.vxd files, etc). Yes, they may communicate with hardware but this is not some mystical system that can't be worked with.
Windows has been abusing the term "driver" for a long time. Monitor driver? Come on! Most things in Windows are called drivers because they need to be loaded in at the kernel level. When in doubt that's the real difference: In Linux a printer "driver" is usually going to be in userspace, a monitor "driver" is no more than an ordinary dynamic library, and a codec (even under Windows) is never called a driver. And never gets loaded into or interacts with the kernel, apart from basic Direct* API calls. let me reiterate: The/definition/ of "driver" as it relates to computers is "A piece of software that makes hardware work."
Some examples: nVidia's Linux driver - a driver mplayer - not a driver divx.dll - not a driver TV watching program - not a driver Video card driver - a driver
Now mplayer is a bit of a toss up, because it does need to know specifics about some cards for some video playing modes. However, since all it does is play video, and relies heavily on other (often nonkernel) software to enable it to do that, it really isn't propperly a "graphics driver".
To provide a Windows compatability layer would NOT be a good thing. It destroys all incentive for companies to release specs or port things to Linux and it destroys a great deal of the incentive for people to write their own drivers. At the same time it would bring Linux a reputation of being slow and buggy. This is because, however little CPU you think those drivers take, they would take much more under Linux. Have you tried running Windows Notepad under Wine? See what I mean? And buggy because there will inevitably be some incompatabilities between the Windows implimentation of their driver API and the Linux one. Such things are virtually unavoidable.
So it's a bad idea, and a bad idea, and a bad idea. It's also a nice trick, but it wouldn't solve anything.
I haven't tried the latest KDE and Gnome versions but I haven't heard any rumors about this issue being finally fixed there either. So I assume the problem is still present, even in the latest "userfriendly"-distros (Xandros et al).
QT3 supposedly fixes many of the problems, but it seems to be dependant on build options. GTK2 reportedly behaves in the correct manner. I have not personally tested either of these.
If there is some library call in xlib (or elsewhere) available that can be used to insert text at current focus position I could probably fix it at least for myself with a tiny 5-liner 'pastekludge.c'. Does anyone have any hints regarding that?
I'm still not sure what you expect to "fix". X isn't broken! Now, I'll admit that it might be nice to have XFree86 provide an X clipboard server of some kind with expanded functionality and extra nifty features with the other standard tools it ships, rather than rely on KDE or GNOME or XFCE to each make one themselves. But even then such a server would rely on the existing X clipboard mechanism most of the time, since most applications would not know to talk to the server.
I'm still thinking about what I proposed in an earlier post: bind ALT-C to 'xclip -o >~/.clipboard' and bind ALT-V to 'pastekludge <~/.clipboard'
Why bother with that? That's useless and redundant. Why use xclip to grab from the selection buffer and dump into a file if all you're going to do is have another program read from the file and dump the data out at the cursor position? It would be simpler to just have 'pastekludge' read from the selection buffer into the clipboard and then output that at the cursor position.
What's more, why bother at all? We can already insert the clipboard/selection at the cursor location. I really don't understand where you're coming from with this.
All this stuff is so basic. Windows does it for years, the amiga did it right >10 years ago and I think even the atari worked that way. I really wonder why X is still doing it wrong.
This is just my point--X is not doing it wrong!
SOME peogrammers and by extentions SOME programs do not behave as they should. X has capability, the freedesktop.org document I referenced in my last post sets policy. The only thing missing is conformance. Conformance will come, and is coming. In some places it happens faster than in others.
The key thing to remember here is: X is not broken. X has never been broken with regards to copying/pasting/selecting, except perhaps in that it provides no built-in data type recognition (and whether that should be provided by X or not is a whole different debate.)
What's screwed up is people writing incompatible applications. Granted, the fact that X does not clearly dictate policy makes this easy, but X is not about policy. But now there IS a policy, and while it's not enforced it is increasingly well-known.
If people love their middle click alternate buffer, leave it the way it is and be happy. But give the rest of us an additional persistent (across "text selections" with your mouse), reliable clipboard-mechanism that doesn't turn every copy-paste operation into an experiment.
You have it, it exists. It's just a matter of waiting for all applications to come into conformance with the policy, which as I've said is happening. Please, PLEASE don't go around blaming X for random unpaid open source programmers who have not yet updated their programs. That is really not constructive.
What would be the difference between xclip -o and xclip --paste ?
They would both output the selection buffer.
xclip is a command line program intended to bring X selection buffer data to the comment line. Surely you are not suggesting that it should be the mechanism for copying and pasting in the GUI! That is outside the scope of xclip entirely.
You seem to be having the same problem a lot of people (and programmers, and programs) have: Distinguishing between the selection buffer and the clipboard.
When something is highlighted, the clipboard is not touched. Instead the selection buffer is filled. When something is deselected, the selection buffer either is emptied or left alone. The correct behavior is to leave it alone. Only when the user sends an explicit copy command should the clipboard be overwritten. Middle-click should not access the clipboard (reference).
The only difference between X and Windows in this respect is that the user can directly access the selection buffer via the middle mouse button.
Confusion between "clipboard" and "selection" is the ONLY problem X has with in this area.... apart from the data-type thing that is, which I agree is a problem for both buffers.
xclip, despite the name, deals with the *selection buffer*. Thus you can "select" text from a pipe, a handy feature indeed.
xclip should be renamed xsel, or something, and then one could create a xclip program which copies from and pastes to pipes. That would be okay. But even then calling xclip should in no way affect any GUI, because it is not supposed to do that.
Binding a GUI shortcut to a theoretical xclip --paste would only succeed in dumping the clipboard to STDOUT... which would just go away. It would never reach an GUI application.
How does xclip solve the problem? It does and it doesn't If you're looking for something which can paste at the mouse pointer independantly of the active application, you're out of luck. But xclip DOES allow you to grab text from the command line and transfer it into a GUI program with ease. That is the desired EFFECT, even if the exact method is not what was described.
No! The file manager shows the icon as residing in some directory. Even though the icon and executable may be distinct files, clicking the icon is done in some directory, so it entails giving the system a full path. From there it damn well ought to be able to get at the executable.
Ah. By "Icon" I assumed you meant "Shortcut" as in a.lnk on Windows or a.desktop, or similar. You are quite correct if by "icon" you mean "icon and accompanying textual name representing a program residing in the current directory"
And here you speak again of launching GUI apps from the command line. Who on earth does this?
I do this. In fact, I have found upon showing my launching methods to others less 1337 than I that it is an exceedingly simple way to launch programs. I technically have a menu, which I never use, but I launch ALL of the programs which I launch manually by typing their name in.
If you're gonna launch a GUI application it means you are in the GUI, where the natural way to launch something is by clicking on it.
It may be "customary" but it is by no means "natural."
Okay, you might still want to also be able to launch it from the command line, or some script. Well, app bundles let you do this: $ open/Applications/Omniweb.app. Yes, in current implementations this requires giving the.app's full path. But if you really wanted, nothing would be simpler than to implement a special PATH for.apps, that open would consult. The reason it's not been done, I venture, is that nobody ever felt the need.
Why have a "special" PATH for.apps? There's already a PATH. Just put a symlink to the application binary in the PATH, and there is no more needed. Don't recreate special-case procedures when existing, generic ones will suffice.
You'll argue that this breaks things if you (say) move the.app somewhere else. Yes, it does. So what is the solution? Don't make.apps rely on this 'open' command, make the system able to launch them directly... which requires them being truly different at the filesystem level, and that means major restructuring. An appbundle idea which relied on actual bundles which the system loader knew how to execute would be a better idea, and might even be Good.
You might bring in MANPATH (etc.). Again I would argue its utter irrelevance in the GUI, where help is done by giving each app a help menu. The GUI gives users more hooks than just a command prompt, so we use that.
ICK! You propose elimination of the man system because "every application has a help menu"? Applications which wont run/die very early still have man pages. Why embed documentation IN the program? The help menu should at most call up the appropriate external document viewer.
There is no reason Help->Manual could not fire up [Some-Help-App] viewing the manual for a program. Which could also be accessed any number of other ways, INCLUDING "man program" on the command line. The external manual viewer, launched by itself, HAS to be able to find all of the manuals. There HAS to be an external manual viewer
Again, there is no reason that the command line and GUI cannot coexist. Neither needs to be subservient to the other, and they do not need to be seperate.
I'll bet you'd say that command line options for GUI apps are a bad idea, just because "you should have a settings menu".
You must never have "installed" a Mac Mozilla build. Downloading it gives you one double-clickable object Mozilla.app, which you can drag and drop and double click anywhere AT ALL. No hard coded symlink, no "registration" with the start menu, no rpm database, no registry, no special launcher, no nothing....and launching it from the command line is needlessly complex. I am aware of all of the "advantages" of appbundles. I do not accept that they
No! The $PATH mechanism is a good one on the command line, where you want the ability to launch anything from the shell prompt, independent of what working dir you are in. In the GUI that's not needed: when you launch an app by double-clicking an icon you've already found it; from there the OS should damn well be able to find the executable!
Ah... no. When you find an icon, you have found a text file with a program name in it. The text file with a program name being clicked stands for typing the program name and hitting enter. It is the GUI equivalent of typing the program name, NOT the program path.
Suppose my browser is Mozilla. If I say "mozilla" on the command line, mozilla opens. if I create a Mozilla launcher I should NOT have to "browse" to the mozilla binary (hey, I'm an end user! I don't even know what a binary is, much less how to locate one!) I should simply have to know to type my program's name which I want the icon to launch... so I type "mozilla".
This is flexible, it allows Mozilla to be stored ANYWHERE in my PATH without the launcher breaking. Suppose I want to grab a CVS build of Mozilla that I've heard has a Really Cool Feature. Excellent! All I need to do is just install it in $HOME and have the installer place a link called "mozilla" in ~/bin, and suddenly... My launcher launches the new version?! Wow! What an amazing feature. A launcher the program did not create, and has no knowledge of, can track new versions?! I'm impressed.
Don't assume that just because Microsoft or Apple does this or that that doing such a thing is somehow good, right, or right for Linux.
App directory bundles are just a (fairly ugly) hack to get around the same problem.
Apple's way is not the poerfect solution. Microsoft's way is not the perfect solution. The traditional UNIX wy is not the perfect solution. If you're going to throw out an imperfect solution, do it because you've found a perfect solution, not just to adopt another imperfect solution. There's a lot of good to be said for each imperfect solution out there, so why throw away the good of the traditional UNIX solution for the dubious value of the good from Apple's solution? You do know that you get Apple's bad along with its good, right?
Look, we're already asking people to take a big, scary relearning step here, right? No matter what you do, Linux will be at leas *somewhat* different, and so they'll need to learn *something. I say it's infinitelky superior to do the Linux desktop the good way, the right way, and emphatically *not* the Windows way right from the start! Sure, the amount people have to learn will be more at first. but then it will be over.
If we emulate Windows, and people learn the Almost-Windows that Linux has become, and THEN we switch to something better, then it's more work and scarier for the users. They have to learn AGAIN.
If instead we force them to learn more now, then they don't have to go through it again.
And if you suggest emulating Windows and then enever switching to someonething better, I'll punch you.
On the one had the BSD license is bad and the GPL far superior. I certainly don't want to give Microsoft a leg up, anywhere!
On the other hand, I'm extremely glad Microsoft copied BSD networking code, rather than try to write their own.
Can you imagine it? It would be called TCP/IP, but it would be buggy as hell, and half of it would work just/slightjy/ differently.
But because they didn't ahve to spend time making their own, they didn't bother to make their own moderately incompatible with everything else. Thus interoperability reigns.
That's about the only good argument I've ever heard for the BSD license (as opposed to the GPL).
I don't think it would be wise to bet such a multi-ten-billion mission on a whacko like that.
I'd sign up in a heartbeat. I'm betting a lot of other slashdotters would, as well.
Give me half a chance and I'll climb over the corpses of my competitors for a chance at getting to mars, even if it wer eonly for a relatively short/ignoble life.
Sound crazy? It really isn't. Different people have different priorities, and going to mars for me ranks a little higher than preservation of life and limb.
And I'm not a wacko, not really. A little eccentric, a little odd, but generally a run-of-the-mill geek.
There is no need to discard the command line. There is a need to improve the GUI. Ideally both should be able to do everything. We CAN have both.
There's no need to Windowsify Linux, there's no need to drop the command line. There's also no need to teach people to use the command line, though that would be my preference if it came to it.
Repeat: The GUI can exist to make remembering those arcane sequences easy in a way that is functionally identical to windows, but whicha ctually leveregaes the power of the command line, and enhances it, thus not alienating the core user base.
It's not spite, it's practicality. I don't have Windows, my computer isn't fast enough to run most things under Wine. I vastly prefer to use my own computer rather than some crummy public box made available for those without computers.
The requested application is *always* windows-only.
I never use the requested application, not out of spite, but because I really have no viable option.
When I started using the net, at the ripe old age of 15, I was a lousy speller and a worse typist. My reading was fine, because I found a use for books, but I had never previously had occasion to do anything with writing.
Enter chat rooms. Trying to keep up with fast-flowing lines of chat whilst simultaneously not making too many embarrassing mistakes taught me (1) to spell well (2) to type fast.
I can honestly say I wouldn't be the irrating english nazi I am today without the internet.
(Note: Any spelling mistakes herein which make me sound extremely foolish are not germane. The other thing I eventually learned in those chat rooms was (3) nobody cares how you spell, except the english nazis. So now I don't bother to be careful.)
I remember the pristine moment when I realized, to my dismay, that I had accumulated such a backlog of downloaded information (which I had not been keeping up with) that if I devoted myself to it as a full time job it would take me/years/, upwards of a lifetime, to read/sort through it all.
That's when I adopted my current methodology: Save local copies of fewer things, hit the highlights unless it really interests you. There's just not enough time in the world to know it all.
Because Knoppix, while neat and spiffy, only works on x86. The Debian installer has to work on all eleven currently supported archs, as well as the new ones (IIRC, so far 3 more will be supported by sarge).
People seem to forget that at the hardware/BIOS/bot level, different archs can be REALLT different. Otherwise they wouldn't keep asking this question.
Slashdot Mirror
Gaby.
. ...) while keeping
I don't know where to get it, other than apt-get install gaby. It's a VERY light database-type thing without an actual database. It's perfect for organizing small amounts of relatively simple information, like a comic book collection, or names and addresses.
What's more, it's GUI and can be installed easily right now. No need for any learning at all.
It's way, way too simple for most uses, but this guy doesn't want a relational database, he wants a laymans Database, which s just the storage of data. And gaby does that perfectly.
From the control file description:
Gaby is a _small_ personal databases manager for Linux
using GTK+ and Gnome for its GUI.
It was designed to provide straight-forward access to databases
a 'normal' user would like (addresses, books,
the ability to easily create databases for other needs. On a
technical side it was designed with extensibility in mind and
thus use relies a lot on plug-ins.
Well, here's a well known humorous example of a way it could be done without even abandoning the Latin alphabet, although it would require a certain Latinization of English vowels (which would actually be a bit of alright).
It was seeing a printed copy of that (or a variation) many years ago which got me seriously thinking about the subject.
Here's an interesting page that might provoke thought:
I have developed my own simplified spelling system, but I continue to run into trouble. Consonants can be handily reformed into a satisfyingly sane system, but vowels prove more difficult. I am constantly torn between 'simplifying' the language by reducing the number of vowel symbols and faithfully producing enough so that every variant of accent can be distinctly represented.
My current end result, dissatisfying though it is, bears a remarkable similarity to that to which your second link pointed, not counting the final transofmation into nonlatin characters.
This pleases me somewhat.
Further investigation suggests unifon is to my tastes.
Thanks for the link.
This is what evil, illegal, soul-destroying online movie piracy is for.
Just download it and be both guilt free and able to rewatch without the trouble of a return to the theater.
Unless you feel squeamish about movie piracy or something silly like that.
There have been a few phonetic alphabets proposed that would make the written English language nearly as phonetic as the Spanish. They've existed for over 100 years.
Fascinating. I've wanted to do this myself. Would you care to name one/some of these proposed phonetic alphabets? I'm sure they'd be better than my poor attempts, and I'd be delighted to learn to use them.
Nobody cares.
I care.
Well, as said, I want a clipboard that does not go away when I select a piece of text with my mouse anywhere.
You have it.
That's my one and only concern.
Too often have I copied an E-Mail address somewhere (and closed the window afterwards) only to figure out that the middle click in the destination window either gives me nothing (dont ask me why, happens frequently) or some completely unrelated text that I clickrolled over by accident while shuffling windows around...
Repeat after me: Middle click does not access the clipboard. If it were supposed to, you'd be right about brokenness. It doesn't, and it shouldn't. Some FEW and decreasing numbers of applications ignore and or treat as one the clipboard and selection buffer.
I think you're splitting hairs here. A driver could mean lots of things. What you call true Windows drivers are nothing more than DLL's themselves (.sys files in Win2k, .vxd files, etc). Yes, they may communicate with hardware but this is not some mystical system that can't be worked with.
/definition/ of "driver" as it relates to computers is "A piece of software that makes hardware work."
Windows has been abusing the term "driver" for a long time. Monitor driver? Come on! Most things in Windows are called drivers because they need to be loaded in at the kernel level. When in doubt that's the real difference: In Linux a printer "driver" is usually going to be in userspace, a monitor "driver" is no more than an ordinary dynamic library, and a codec (even under Windows) is never called a driver. And never gets loaded into or interacts with the kernel, apart from basic Direct* API calls. let me reiterate: The
Some examples:
nVidia's Linux driver - a driver
mplayer - not a driver
divx.dll - not a driver
TV watching program - not a driver
Video card driver - a driver
Now mplayer is a bit of a toss up, because it does need to know specifics about some cards for some video playing modes. However, since all it does is play video, and relies heavily on other (often nonkernel) software to enable it to do that, it really isn't propperly a "graphics driver".
To provide a Windows compatability layer would NOT be a good thing. It destroys all incentive for companies to release specs or port things to Linux and it destroys a great deal of the incentive for people to write their own drivers. At the same time it would bring Linux a reputation of being slow and buggy. This is because, however little CPU you think those drivers take, they would take much more under Linux. Have you tried running Windows Notepad under Wine? See what I mean? And buggy because there will inevitably be some incompatabilities between the Windows implimentation of their driver API and the Linux one. Such things are virtually unavoidable.
So it's a bad idea, and a bad idea, and a bad idea. It's also a nice trick, but it wouldn't solve anything.
I haven't tried the latest KDE and Gnome versions but I haven't heard any rumors about this issue being finally fixed there either. So I assume the problem is still present, even in the latest "userfriendly"-distros (Xandros et al).
QT3 supposedly fixes many of the problems, but it seems to be dependant on build options. GTK2 reportedly behaves in the correct manner. I have not personally tested either of these.
If there is some library call in xlib (or elsewhere) available that can be used to insert text at current focus position I could probably fix it at least for myself with a tiny 5-liner 'pastekludge.c'. Does anyone have any hints regarding that?
I'm still not sure what you expect to "fix". X isn't broken! Now, I'll admit that it might be nice to have XFree86 provide an X clipboard server of some kind with expanded functionality and extra nifty features with the other standard tools it ships, rather than rely on KDE or GNOME or XFCE to each make one themselves. But even then such a server would rely on the existing X clipboard mechanism most of the time, since most applications would not know to talk to the server.
I'm still thinking about what I proposed in an earlier post:
bind ALT-C to 'xclip -o >~/.clipboard' and
bind ALT-V to 'pastekludge <~/.clipboard'
Why bother with that? That's useless and redundant. Why use xclip to grab from the selection buffer and dump into a file if all you're going to do is have another program read from the file and dump the data out at the cursor position? It would be simpler to just have 'pastekludge' read from the selection buffer into the clipboard and then output that at the cursor position.
What's more, why bother at all? We can already insert the clipboard/selection at the cursor location. I really don't understand where you're coming from with this.
I didn't take it as a flame, and I really don't think we are talking about different problems.
All this stuff is so basic. Windows does it for years, the amiga did it right >10 years ago and I think even the atari worked that way. I really wonder why X is still doing it wrong.
This is just my point--X is not doing it wrong!
SOME peogrammers and by extentions SOME programs do not behave as they should. X has capability, the freedesktop.org document I referenced in my last post sets policy. The only thing missing is conformance. Conformance will come, and is coming. In some places it happens faster than in others.
The key thing to remember here is: X is not broken. X has never been broken with regards to copying/pasting/selecting, except perhaps in that it provides no built-in data type recognition (and whether that should be provided by X or not is a whole different debate.)
What's screwed up is people writing incompatible applications. Granted, the fact that X does not clearly dictate policy makes this easy, but X is not about policy. But now there IS a policy, and while it's not enforced it is increasingly well-known.
If people love their middle click alternate buffer, leave it the way it is and be happy. But give the rest of us an additional persistent (across "text selections" with your mouse), reliable clipboard-mechanism that doesn't turn every copy-paste operation into an experiment.
You have it, it exists. It's just a matter of waiting for all applications to come into conformance with the policy, which as I've said is happening. Please, PLEASE don't go around blaming X for random unpaid open source programmers who have not yet updated their programs. That is really not constructive.
What would be the difference between xclip -o and xclip --paste ?
They would both output the selection buffer.
xclip is a command line program intended to bring X selection buffer data to the comment line. Surely you are not suggesting that it should be the mechanism for copying and pasting in the GUI! That is outside the scope of xclip entirely.
You seem to be having the same problem a lot of people (and programmers, and programs) have: Distinguishing between the selection buffer and the clipboard.
When something is highlighted, the clipboard is not touched. Instead the selection buffer is filled. When something is deselected, the selection buffer either is emptied or left alone. The correct behavior is to leave it alone. Only when the user sends an explicit copy command should the clipboard be overwritten. Middle-click should not access the clipboard (reference).
The only difference between X and Windows in this respect is that the user can directly access the selection buffer via the middle mouse button.
Confusion between "clipboard" and "selection" is the ONLY problem X has with in this area.... apart from the data-type thing that is, which I agree is a problem for both buffers.
xclip, despite the name, deals with the *selection buffer*. Thus you can "select" text from a pipe, a handy feature indeed.
xclip should be renamed xsel, or something, and then one could create a xclip program which copies from and pastes to pipes. That would be okay. But even then calling xclip should in no way affect any GUI, because it is not supposed to do that.
Binding a GUI shortcut to a theoretical xclip --paste would only succeed in dumping the clipboard to STDOUT... which would just go away. It would never reach an GUI application.
How does xclip solve the problem? It does and it doesn't If you're looking for something which can paste at the mouse pointer independantly of the active application, you're out of luck. But xclip DOES allow you to grab text from the command line and transfer it into a GUI program with ease. That is the desired EFFECT, even if the exact method is not what was described.
apt-get install xclip
cat file | xclip
paste file anywhere.
xclip -o
See the file on stdout!
It's KFC own falt. They should have included a noncompete in the sale contract.
No! The file manager shows the icon as residing in some directory. Even though the icon and executable may be distinct files, clicking the icon is done in some directory, so it entails giving the system a full path. From there it damn well ought to be able to get at the executable.
.lnk on Windows or a .desktop, or similar. You are quite correct if by "icon" you mean "icon and accompanying textual name representing a program residing in the current directory"
/Applications/Omniweb.app. Yes, in current implementations this requires giving the .app's full path. But if you really wanted, nothing would be simpler than to implement a special PATH for .apps, that open would consult. The reason it's not been done, I venture, is that nobody ever felt the need.
.apps? There's already a PATH. Just put a symlink to the application binary in the PATH, and there is no more needed. Don't recreate special-case procedures when existing, generic ones will suffice.
.app somewhere else. Yes, it does. So what is the solution? Don't make .apps rely on this 'open' command, make the system able to launch them directly... which requires them being truly different at the filesystem level, and that means major restructuring. An appbundle idea which relied on actual bundles which the system loader knew how to execute would be a better idea, and might even be Good.
...and launching it from the command line is needlessly complex. I am aware of all of the "advantages" of appbundles. I do not accept that they
Ah. By "Icon" I assumed you meant "Shortcut" as in a
And here you speak again of launching GUI apps from the command line. Who on earth does this?
I do this. In fact, I have found upon showing my launching methods to others less 1337 than I that it is an exceedingly simple way to launch programs. I technically have a menu, which I never use, but I launch ALL of the programs which I launch manually by typing their name in.
If you're gonna launch a GUI application it means you are in the GUI, where the natural way to launch something is by clicking on it.
It may be "customary" but it is by no means "natural."
Okay, you might still want to also be able to launch it from the command line, or some script. Well, app bundles let you do this: $ open
Why have a "special" PATH for
You'll argue that this breaks things if you (say) move the
You might bring in MANPATH (etc.). Again I would argue its utter irrelevance in the GUI, where help is done by giving each app a help menu. The GUI gives users more hooks than just a command prompt, so we use that.
ICK! You propose elimination of the man system because "every application has a help menu"? Applications which wont run/die very early still have man pages. Why embed documentation IN the program? The help menu should at most call up the appropriate external document viewer.
There is no reason Help->Manual could not fire up [Some-Help-App] viewing the manual for a program. Which could also be accessed any number of other ways, INCLUDING "man program" on the command line. The external manual viewer, launched by itself, HAS to be able to find all of the manuals. There HAS to be an external manual viewer
Again, there is no reason that the command line and GUI cannot coexist. Neither needs to be subservient to the other, and they do not need to be seperate.
I'll bet you'd say that command line options for GUI apps are a bad idea, just because "you should have a settings menu".
You must never have "installed" a Mac Mozilla build. Downloading it gives you one double-clickable object Mozilla.app, which you can drag and drop and double click anywhere AT ALL. No hard coded symlink, no "registration" with the start menu, no rpm database, no registry, no special launcher, no nothing.
Blakes Seven was an awesome show. I'm told that there really were more eps after the ship blew up, but I've never seen them.
It's fantastic the way nearly everybody dies right at the beginning. Some skilled person should do a remake.
I am a conscientious /opt objector, and so dissagree that what you suggest is at all a good idea.
That said, have you tried GoboLinux? It basically takes the approach you suggest out to its limits, all with its own distribution
No! The $PATH mechanism is a good one on the command line, where you want the ability to launch anything from the shell prompt, independent of what working dir you are in. In the GUI that's not needed: when you launch an app by double-clicking an icon you've already found it; from there the OS should damn well be able to find the executable!
Ah... no. When you find an icon, you have found a text file with a program name in it. The text file with a program name being clicked stands for typing the program name and hitting enter. It is the GUI equivalent of typing the program name, NOT the program path.
Suppose my browser is Mozilla. If I say "mozilla" on the command line, mozilla opens. if I create a Mozilla launcher I should NOT have to "browse" to the mozilla binary (hey, I'm an end user! I don't even know what a binary is, much less how to locate one!) I should simply have to know to type my program's name which I want the icon to launch... so I type "mozilla".
This is flexible, it allows Mozilla to be stored ANYWHERE in my PATH without the launcher breaking. Suppose I want to grab a CVS build of Mozilla that I've heard has a Really Cool Feature. Excellent! All I need to do is just install it in $HOME and have the installer place a link called "mozilla" in ~/bin, and suddenly... My launcher launches the new version?! Wow! What an amazing feature. A launcher the program did not create, and has no knowledge of, can track new versions?! I'm impressed.
Don't assume that just because Microsoft or Apple does this or that that doing such a thing is somehow good, right, or right for Linux.
App directory bundles are just a (fairly ugly) hack to get around the same problem.
Apple's way is not the poerfect solution. Microsoft's way is not the perfect solution. The traditional UNIX wy is not the perfect solution. If you're going to throw out an imperfect solution, do it because you've found a perfect solution, not just to adopt another imperfect solution. There's a lot of good to be said for each imperfect solution out there, so why throw away the good of the traditional UNIX solution for the dubious value of the good from Apple's solution? You do know that you get Apple's bad along with its good, right?
Look, we're already asking people to take a big, scary relearning step here, right? No matter what you do, Linux will be at leas *somewhat* different, and so they'll need to learn *something. I say it's infinitelky superior to do the Linux desktop the good way, the right way, and emphatically *not* the Windows way right from the start! Sure, the amount people have to learn will be more at first. but then it will be over.
If we emulate Windows, and people learn the Almost-Windows that Linux has become, and THEN we switch to something better, then it's more work and scarier for the users. They have to learn AGAIN.
If instead we force them to learn more now, then they don't have to go through it again.
And if you suggest emulating Windows and then enever switching to someonething better, I'll punch you.
Get vi-gtk or xemacs, set it up with wordstar keybindings. Tada.
On the one had the BSD license is bad and the GPL far superior. I certainly don't want to give Microsoft a leg up, anywhere!
/slightjy/ differently.
On the other hand, I'm extremely glad Microsoft copied BSD networking code, rather than try to write their own.
Can you imagine it? It would be called TCP/IP, but it would be buggy as hell, and half of it would work just
But because they didn't ahve to spend time making their own, they didn't bother to make their own moderately incompatible with everything else. Thus interoperability reigns.
That's about the only good argument I've ever heard for the BSD license (as opposed to the GPL).
I don't think it would be wise to bet such a multi-ten-billion mission on a whacko like that.
I'd sign up in a heartbeat. I'm betting a lot of other slashdotters would, as well.
Give me half a chance and I'll climb over the corpses of my competitors for a chance at getting to mars, even if it wer eonly for a relatively short/ignoble life.
Sound crazy? It really isn't. Different people have different priorities, and going to mars for me ranks a little higher than preservation of life and limb.
And I'm not a wacko, not really. A little eccentric, a little odd, but generally a run-of-the-mill geek.
There is no need to discard the command line. There is a need to improve the GUI. Ideally both should be able to do everything. We CAN have both.
There's no need to Windowsify Linux, there's no need to drop the command line. There's also no need to teach people to use the command line, though that would be my preference if it came to it.
Repeat: The GUI can exist to make remembering those arcane sequences easy in a way that is functionally identical to windows, but whicha ctually leveregaes the power of the command line, and enhances it, thus not alienating the core user base.
It's not spite, it's practicality. I don't have Windows, my computer isn't fast enough to run most things under Wine. I vastly prefer to use my own computer rather than some crummy public box made available for those without computers.
The requested application is *always* windows-only.
I never use the requested application, not out of spite, but because I really have no viable option.
You're more or less right.
When I started using the net, at the ripe old age of 15, I was a lousy speller and a worse typist. My reading was fine, because I found a use for books, but I had never previously had occasion to do anything with writing.
Enter chat rooms. Trying to keep up with fast-flowing lines of chat whilst simultaneously not making too many embarrassing mistakes taught me (1) to spell well (2) to type fast.
I can honestly say I wouldn't be the irrating english nazi I am today without the internet.
(Note: Any spelling mistakes herein which make me sound extremely foolish are not germane. The other thing I eventually learned in those chat rooms was (3) nobody cares how you spell, except the english nazis. So now I don't bother to be careful.)
I remember the pristine moment when I realized, to my dismay, that I had accumulated such a backlog of downloaded information (which I had not been keeping up with) that if I devoted myself to it as a full time job it would take me /years/, upwards of a lifetime, to read/sort through it all.
That's when I adopted my current methodology: Save local copies of fewer things, hit the highlights unless it really interests you. There's just not enough time in the world to know it all.
Because Knoppix, while neat and spiffy, only works on x86. The Debian installer has to work on all eleven currently supported archs, as well as the new ones (IIRC, so far 3 more will be supported by sarge).
People seem to forget that at the hardware/BIOS/bot level, different archs can be REALLT different. Otherwise they wouldn't keep asking this question.