Stormy Peters: What should the GNOME Foundation accomplish in 2010?
If you use GNOME, you should let us know what you think the Foundation should accomplish in 2010!"
Posted Jan 27, 2010 0:46 UTC (Wed)
by gdt (subscriber, #6284)
[Link] (3 responses)
And how about fixing the elephant in the room for enterprise users, getting the Linux desktop to interwork in a pure Microsoft environment? At the moment, this means reading mail and calendar from an Exchange server. Oh so close to working, but oh so doesn't.
Posted Jan 27, 2010 15:30 UTC (Wed)
by drag (guest, #31333)
[Link] (2 responses)
Posted Jan 28, 2010 21:20 UTC (Thu)
by BenHutchings (subscriber, #37955)
[Link] (1 responses)
Under the X clipboard protocol, 'copying' marks the clipboard as owned/provided by the source client, but nothing is copied until you paste and the destination client requests the contents. The major benefit of this is that the source client can offer multiple formats but only generate and transfer them to the server as needed. The downside, as you've seen, is that pasting does not work after the source client exits. It may appear to work when GNOME Terminal is the source, but that is because all Terminal windows are now owned by the same client process. The only way I can see to solve this is for the server to request all source formats immediately and then respond to paste requests itself. This could be very inefficient in the case of complex formats, particularly if client and server are on different systems.
Posted Jan 28, 2010 22:57 UTC (Thu)
by nix (subscriber, #2304)
[Link]
This is not rocket science: Word for Windows 1.0 could do it back in the
Posted Jan 27, 2010 1:01 UTC (Wed)
by dskoll (subscriber, #1630)
[Link] (20 responses)
I might if GNOME tried to be more UNIX-like. For example: If Evolution supported an external editor for composing email, I might take another look at it. And it'd be nice if GUI elements used standard UNIX terms ("directory") rather than dumbed-down M$ substitutes ("folder").
And how about plain-text human-readable configuration files? And man pages for every GNOME program?
I use Linux because I like the UNIX philosophy. Surely the GNOME wizards can come up with an easy-to-use desktop that still respects that philosophy?
Posted Jan 27, 2010 8:31 UTC (Wed)
by mjthayer (guest, #39183)
[Link] (7 responses)
Posted Jan 27, 2010 8:46 UTC (Wed)
by fperrin (subscriber, #61941)
[Link] (3 responses)
I'm not a native English speaker, but... Don't folder and directory both come from The Real World, and both refer to a way of organizing subitems ? According to Wiktionary : Folder : An organizer that papers are kept in, usually with an index tab, to be stored as a single unit in a filing cabinet. Directory : A list of names, addresses etc., of specific classes of people or organizations, often in alphabetical order or in some classification. From this, it could even by argued that "folder" is actually more precise than "directory"... So, why 1) is "folder" such a bad synonym for "directory" according to GP, 2) is "directory" a more complex/technical word for "folder" according to parent ?
Posted Jan 27, 2010 9:14 UTC (Wed)
by dgm (subscriber, #49227)
[Link] (2 responses)
Posted Jan 27, 2010 9:29 UTC (Wed)
by gowen (guest, #23914)
[Link] (1 responses)
Posted Jan 27, 2010 16:27 UTC (Wed)
by drag (guest, #31333)
[Link]
The whole 'directory'/'folder' concept is just shit all around. It's a bad
But it's one we are stuck with.
Folders make sense in Gnome because not everything you see as a folder is
There are all sorts of little things like that. It is really very bad and
You can thank Microsoft and Apple for this.
Posted Jan 27, 2010 9:24 UTC (Wed)
by mjthayer (guest, #39183)
[Link] (1 responses)
Posted Jan 27, 2010 15:27 UTC (Wed)
by dskoll (subscriber, #1630)
[Link]
The "It's All Text" plugin for Thunderbird is a good example of nice integration of an external editor. There's no reason Evolution couldn't do it the same way.
Posted Jan 27, 2010 15:26 UTC (Wed)
by dskoll (subscriber, #1630)
[Link]
The problem is that UNIX systems have been calling directories "directories" since the beginning. The command to change directories is cd, not cf. The library function to open a directory is opendir, not openfolder. And it's mkdir, not mkfolder. Using the term "folder" introduces unnecessary inconsistency.
Posted Jan 27, 2010 9:09 UTC (Wed)
by ncm (guest, #165)
[Link]
Posted Jan 27, 2010 16:47 UTC (Wed)
by drag (guest, #31333)
[Link] (9 responses)
Posted Jan 27, 2010 17:09 UTC (Wed)
by dskoll (subscriber, #1630)
[Link] (2 responses)
There is really no such thing as a desktop behaving more Unix-like.
Sure there is.
You don't 'minimize windows' you 'iconize' them.
The term is iconify and it makes the same amount of sense to me as minimize. (ie, none.)
The window management sucks.
That's your opinion, nothing more.
There is no power management features to speak of. There is no notification system or reasonable IPC for applications to use besides sockets.
These have all successfully been built on top of a UNIX-like base without abandoning the UNIX philosophy of small, cooperating programs that each do one thing well.
There is no reasonable file manager.
There are lots of reasonable file managers. Take your pick. I happen to hate all file managers anyway, so whichever one GNOME picks for that task doesn't matter to me.
You are confusing the term UNIX-like with similar to previous UNIX desktops. That's not at all what I meant.
Evolution does suck, but other IMAP applications are no shakes either.. so far the most decent one I can find is actually 'mutt'.
I'm fairly happy with Thunderbird. The It's All Text plugin integrates it with my favorite text editor... a perfect example of the UNIX philosophy.
Posted Jan 27, 2010 19:00 UTC (Wed)
by drag (guest, #31333)
[Link] (1 responses)
Posted Jan 27, 2010 19:14 UTC (Wed)
by dskoll (subscriber, #1630)
[Link]
So far Microsoft has done a much better job of doing this (providing documentation) for the desktop then anything I've seen come out of a Unix tradition.
The proprietary UNIXes (eg, Solaris) were pretty diligent about having a man page for everything. And AFAIK, Debian's policy requires every program that would be found on a normal PATH to have a man page.
(Though some Debian man pages are stubs, alas.)
My mention of System 360 was simply to show how designers got this right 50 years ago. There's no excuse for GNOME to continue to get it wrong in 2010.
Posted Jan 27, 2010 19:30 UTC (Wed)
by cmccabe (guest, #60281)
[Link] (5 responses)
In what way does the unix clipboard make "zero sense"? Not trying to troll, I just don't understand your point.
> The is no panel. There is no reasonable file manager.
From my vague memories of fvwm, fvwm2, and twm, I remember a lot of panels.
> There is no power management features to speak of.
What does this have to do with GNOME or x11?
> You have a crapload of .*rc files that are arbitrarily made up with unique
As opposed to a crapload of registry entries that are arbitrarily named with unique and completely undocumented behavior. If you've ever run regedit.exe then you know what I'm talking about. The only "advantages" of the registry are that you can't grep it, can't make it read-only, and can't back it up without special tools. Oh, and since it's a giant binary file, it can get "corrupted." That's what happens when you reinvent the filesystem, poorly.
Anyway, the user doesn't care how his preferences are stored. He just cares that there is a reasonable GUI to change them. I agree that UNIX lagged in this area in the past, but GUIs to edit .rc files are hardly a radical new idea that UNIX never had.
> If you want Evolution to behave more like 'Mutt' or 'Pine' or whatever
Yeah, Evolution and Thunderbird both kind of suck. Evolution more so.
I think everyone just gave up on desktop clients and started using gmail for their personal mail. And for work mail, the volume of messages is so low that I can use T-bird.
Posted Jan 28, 2010 0:25 UTC (Thu)
by SEMW (guest, #52697)
[Link] (4 responses)
There are enough good arguments against a registry, and reasons why the advantages are outweighed by the disadvantages, that not making them in favour of making the rather silly claim that it has *no* advantages *at all* (and sarcastically listing its disadvantages as "advantages") takes away rather than adds to your point.
So in the interests of balance, I'll play devil's advocate and throw out a couple of advantages of a registry database system:
- Key-level access controls, which can be done with text files only by having only one key/value per file (which has its own disadvantages)
- All the atomicity, transactioning, and other consistency advantages that a database & dbms give you
- Strongly-typed data
- Changes are done through a standardised API, which makes makes a lot of stuff, such as centralised administration, easier
- .reg files, gconftool, etc. have no real equivalent in text files with unstandardised syntax
A lot of those aren't only advantages of a *binary* registry -- e.g. the gnome registry, gconf, uses xml files as a backend by default, but still has a standardised API, strongly-typed data, etc. The arguments between using e.g. xml as a backend and a binary database backend are probably fairly standard, and other people will be able to argue either way better than I would (but it is a tradeoff, e.g. between ability to make manual edits in an emergency as against parsing speed).
Posted Jan 28, 2010 7:03 UTC (Thu)
by cmccabe (guest, #60281)
[Link] (3 responses)
> Key-level access controls, which can be done with text files only by
I've never, ever come across a situation where I wished I could make one half of a configuration file editable by one user and another half by another.
In the situations where it might be even of theoretical interest, the software designers always split the configuration into multiple files, or provide #include-like functionality.
> All the atomicity, transactioning, and other consistency advantages that a
Atomicity is a solved problem. Just create the new config file as a separate file, then use rename() to get either the old or new file. Every filesystem that I know of has this semantic with rename (yes, I know it's not strictly in POSIX.) Every major UNIX text editor (vi, emacs, etc.) uses the rename() trick by default.
Transactioning is a solved problem because... you do make backups of /etc, right? Or you use btrfs with snapshotting.
It might be interesting to have a registry that had something like a foreign key constraint in SQL. (If X is set, then Y can't be set, etc.) The problem with schemes like this is that they tend to assume close cooperation between the maintainers of different projects. One config file per-daemon or service puts the responsibility squarely on the package maintainer's shoulders. With foreign-key constraints that could span packages, who has the final responsibility for fixing things?
Also, if the constraint is violated, what do you do? Silently modify the user's configuration according to your own whims? shutdown -h? Or just add to the syslog spew?
> Strongly-typed data
This is probably the strongest argument in favor of a registry. Being forced to use getter and setter functions prevents you from writing your own parser, which you'll probably screw up.
The rebuttal is that good programmers never write their own parsers from scratch. They use tools like lex and yacc to generate parsers which are type-safe and correct. Or they use a canned format like XML or the Python ConfigParser format.
The more detailed rebuttal is that true type-safety would require the ability to extend the registry with arbitrary datatypes. Sure you have string and uint32, but will you allow me to store my FtpUser object? If you won't, I'm still going to be doing something that smells a lot like parsing.
> Changes are done through a standardised API, which makes makes a lot of
There are tools like "Chef" that provide centralized management for unix config files. On the other hand, there are no such tools that I'm aware of for the Windows registry, unless you want to call "regedit" such a tool. I'm not aware of any for the gnome registry except for it's own registry editor dialog, and... Gnome itself. The reality is that one program cannot understand another program's configuration, no matter how it's stored or parsed, without someone putting work into integrating the two projects. Centralization and integration have nothing to do with technology, and everything to do with politics and management.
Since I'm being a completionist, let me point out another thing. You forgot to mention another argument against text file configuration: configuration file size. A set of (binary) registry entries can be parsed more quickly than a large text file.
This actually became a real issue in the samba program. Some users had extremely large configurations that were taking a long time to parse when the daemon was started. The samba team solved it by providing a (non-mandatory) facility to compile the config file into a binary representation.
Posted Jan 28, 2010 15:03 UTC (Thu)
by nix (subscriber, #2304)
[Link]
Posted Jan 31, 2010 0:37 UTC (Sun)
by cortana (subscriber, #24596)
[Link] (1 responses)
Doesn't that blow away the file ownership, permissions, ACL and extended attribute information?
Posted Jan 31, 2010 9:35 UTC (Sun)
by anselm (subscriber, #2796)
[Link]
In the general case, yes. In the case of config files this is rarely an
issue -- if you can do »rename()« on the original file (write to the
parent directory,
really), you're usually in a position to set up the permissions etc. of
the
new file to match the old, and it's not as if there are lots of obvious
choices for these, anyway.
Posted Mar 4, 2010 7:41 UTC (Thu)
by daenzer (subscriber, #7050)
[Link]
Evolution has had an 'External Editor' plugin for a while, but I don't use it so I can't say how well it works or indeed if at all.
Posted Jan 27, 2010 9:26 UTC (Wed)
by Felix.Braun (guest, #3032)
[Link] (3 responses)
I'm not even sure it is within the scope of the Foundation to enforce any particular philosophy or vision whithin the project itself. In the end, it's the coders who write the code.
The way I understand it, the Foundation's job is more like the project's lobby group. Of course, they also administer the money gained from fundraising. So they have to spend it to support the Project by funding individual developers or critical infrastructure.
Posted Jan 27, 2010 13:56 UTC (Wed)
by sturmflut (subscriber, #38256)
[Link] (1 responses)
That sounds like an AWFUL lot of power to me, if properly used.
Posted Jan 27, 2010 14:58 UTC (Wed)
by rahulsundaram (subscriber, #21946)
[Link]
Posted Jan 27, 2010 15:30 UTC (Wed)
by dskoll (subscriber, #1630)
[Link]
These folks generally don't do any coding. So blaming them for defects in particular programs is beside the point.
Well, it's not defects in particular programs. It's a mindset. In my opinion, a UNIX program that lacks a man page is simply unfinished. A UNIX program that routinely asks you to edit lots of text yet lacks integration with the editor of your choice is defective by design. Basically, the GNOME foundation should push for a more UNIX-like approach to software tools.
Posted Jan 27, 2010 15:00 UTC (Wed)
by HelloWorld (guest, #56129)
[Link]
Posted Jan 27, 2010 15:36 UTC (Wed)
by arjan (subscriber, #36785)
[Link]
Posted Jan 28, 2010 0:34 UTC (Thu)
by tpo (subscriber, #25713)
[Link] (2 responses)
Posted Jan 28, 2010 5:12 UTC (Thu)
by gmatht (subscriber, #58961)
[Link] (1 responses)
Pressing Ctrl-C or Ctrl-X fills the "clipboard". Pressing Shift-Insert or
If you question is "why don't we merge the clipboard and the selection
Keeping the selection buffer separate has another advantage: you can store
Posted Jan 28, 2010 14:54 UTC (Thu)
by nix (subscriber, #2304)
[Link]
Posted Jan 29, 2010 19:22 UTC (Fri)
by ssam (guest, #46587)
[Link]
Stormy Peters: What should the GNOME Foundation accomplish in 2010?
Yeah. Native MAPI support is something that is needed. It's close, but it's
still really buggy. Proper integration into a Windows AD with all the
frills is a requirement for Gnome if they want businesses to take them
seriously. Since Windows is dominate then, unfortunately, the burden is on
the Linux desktop to work well in existing environments.
Stormy Peters: What should the GNOME Foundation accomplish in 2010?
--------------
Refinement of the Gnome-shell concept and the grouping of application
windows. Fixing the alt-tab behavior of Gnome-shell to make it more usable.
That sort of thing.
-------------
Probably be more aggressive about the copy-n-paste clipboard thing. I know
that Gnome itself is pretty good about remembering clipboard contents when
you close out applications, but most third party stuff will break it and
cause confusion. The most obvious offender is Firefox, of course.
Try this:
1. Open up Gnome-terminal and type something in it. Highlight it and then
right click --> select copy.
2. Close out Gnome-terminal
3. Open up Gedit. Paste your clipboard into that. Add some more of it,
highlight it and then right click --> copy.
4. Close out Gedit
5. Open up Firefox. Paste your clipboard into the URL or whatever. Add some
more to it. High light it and then right click --> copy.
6. Close out Firefox
7. Open up Gedit. Try to paste into Gedit. Dwell on the fail.
Since most distributions ship Firefox as the default browser for Gnome they
are shipping a broken clipboard implementation. Sure if you just use
'Gnome' applications then everything is great, but that is almost never the
default.
And managing the clipboard in the current manner may be technically
correct, but that is about as relevant to the situation as the color of the
car that just passed by my window as I was typing this. And, sure, you
could fix Firefox and make it use the clipboard the correctly instead of
curb stomping it, but there are just going to be dozens and dozens of other
applications just as evil.
Currently users, and I was one of them when I moved from Windows over a
decade ago, are accustomed to being able to close out windows and be able
to paste. This is very very normal and common thing to do, but which Linux
fails at.
As Linux users we are mostly all now trained to, almost subconsciously, to
do things like "alt-tab then paste" rather then "close out the window then
paste". So we generally don't notice the borked copy-n-paste anymore.
But, really, it should be fixed.
Right now I use Parcellite to work around this problem and it's very cool,
but it really is overkill. Gnome needs to integrate a more aggressive
approach to clipboard management.
Stormy Peters: What should the GNOME Foundation accomplish in 2010?
Since most distributions ship Firefox as the default browser for Gnome they are shipping a broken clipboard implementation. Sure if you just use 'Gnome' applications then everything is great, but that is almost never the default.
Stormy Peters: What should the GNOME Foundation accomplish in 2010?
one client library (e.g. GNOME, or KDE). When the owner of the clipboard
(or, I suppose, the selection) terminates, it sends the supported formats
to some persistent daemon whose job it is to take ownership in this
situation, and hand things on. If the size of all supported formats is
large, the application could request user confirmation and throw away the
clipboard/selection if the user requests.
early/mid 90s.
I don't use GNOME, but...
I don't use GNOME, but...
should never use more complex/technical language if there is a simpler way of saying things (one
that will not confuse anyone of course). Hands up anyone here who doesn't know what a folder
means in the context of files?
I don't use GNOME, but...
I don't use GNOME, but...
I suppose people prefer arguing these kind of little details because it's easier than get to the real problems.
I am a native english speaker, but I agree entirely. Also, "Folder" has an intuitive visual icon, whereas directory does not (what would it be, a picture of a telephone directory?). Even file managers that call them directories, tend to use icons that look like folders.
I don't use GNOME, but...
I don't use GNOME, but...
abstraction and never really made sense. It was designed by Xerox as part
of a basic GUI to run a printer, FFS.
really a directory on your file system. You have your 'fonts' folder. It
corrisponds with stuff that goes on in ~/.fonts, but only loosely. Same
things with folders when your using 'smb://' to view windows servers or
whatever.
makes things more confusing unless you happen to have a good understanding
of what is happening in a OS, but it mostly works as long as users don't
think about things too deeply.
I don't use GNOME, but...
loading the entire e-mail with headers, attachments and all into a general purpose editor and
letting you edit and exit is rather ugly. Perhaps an editor better designed for that sort of
integration would be nicer though.
I don't use GNOME, but...
I don't use GNOME, but...
I don't use GNOME, but...
might if GNOME tried to be more UNIX-like
I don't use GNOME, but...
There is really no such thing as a desktop behaving more Unix-like.
There was never a decent Unix desktop. It never existed and the lessons
developed from developing Unix into a proper server OS only can be applied
to the desktop in a loose manner.
The 'Unix-like' way of doing things is to have a clipboard that makes zero
sense. You don't 'minimize windows' you 'iconize' them. The is no panel.
There is no reasonable file manager. The window management sucks. There is
no power management features to speak of. There is no notification system
or reasonable IPC for applications to use besides sockets.
The 'Unix way' has no session management. You have a crapload of .*rc files
that are arbitrarily made up with unique and poorly documented syntax that
is backwards and makes almost no sense unless you understand the internals
of whatever application you happen to be using at the time.
Basically every single freaking thing that Unix introduced on a desktop or
workstation GUI is pretty much complete shit. The very very limited
functionality that Unix provided on GUI systems was mostly just a jumble of
bad designs and poorly thought out features that plague us to this day.
Unix just never addressed the problems that Gnome is trying to solve. Unix
never survived long enough as a 'Free' OS to get to that point.
Sure there are a few things like 'Make things small and function specific',
'be portable', 'use layers',
and such that you can take from the Unix heritage and apply to a modern
desktop, but most of it just made up as we progress.
--------------------
If you want Evolution to behave more like 'Mutt' or 'Pine' or whatever
because that is what your used to your then just say so. There is nothing
wrong with that. Evolution does suck, but other IMAP applications are no
shakes either.. so far the most decent one I can find is actually 'mutt'.
The traditional Unix way to manage email is to use a crude application to
help you sort through a mbox file on a remote server that you telnet'd
into from your DOS system.
I don't use GNOME, but...
Include man pages for all applications.
I don't use GNOME, but...
So far Microsoft has done a much better job of doing this (providing
documentation) for the desktop then anything I've seen come out of a Unix
tradition.
Make programs that involve editing large amounts of text capable of
calling an external editor. IBM got this right in the early 1960's with
System-360, for crying out loud!
Well the 360 is not really Unix is it? Then again it does not really use
the concept of files and directories either... In fact it's completely a
alien OS to Unix in every way imaginable.
Use standard terminology that's been around since the early 1970's
instead of introducing inconsistent terminology.
Like what? MiBs?
Use human-readable configuration files under the hood. (You can use
whatever flashy GUI configuration editor you like for neophytes.)
A flat directory system containing hundreds of files, each using different
formats and
different naming conventions is not 'human readable'. Individually; yes,
but collectively; no. It's inhuman, actually.
Gconf is better then most things I've seen. Directory trees containing
individual text files with keyword-value pairs is standardized and easily
editable. Editing gconf by hand using Vi is a hell of a lot easier then
trying to figure out most rc files. Too bad about that lack of
documentation, of course. It's what kills it.
These have all successfully been built on top of a UNIX-like base
without abandoning the UNIX philosophy of small, cooperating programs that
each do one thing well.
Really? Why is nobody using these systems then? Got any real examples?
Because while it's entirely possible you have something in mind that I am
unaware of, I have no clue what it is and I have not seen a Unix system
that is successful at it.
I'm fairly happy with Thunderbird. The It's All Text plugin integrates
it with my favorite text editor... a perfect example of the UNIX
philosophy.
Thats funny because Thunderbird comes almost completely from a Windows/DOS-
based tradition. Also it's a monolythic application with it's own widget
set and rendering system and shares very little functionality or code with
other applications in your system, except Firefox. Very un-Unixy. Also
plugin systems and extensions to applications probably existed in
Windows/DOS desktop applications first.
Except maybe Emacs. I suppose emacs had the same sort of functionality.
Except that comes from a LISP machine background and not Unix.
There are lots of reasonable file managers. Take your pick. I happen to
hate all file managers anyway, so whichever one GNOME picks for that task
doesn't matter to me.
Not in any Unix system I've ever seen. The closest to 'traditional' you can
get is 'Midnight Commander' 2-pane-style managers (there are a whole group
of applications similar to that that were popular) and that is a unabashed
clone of a popular proprietary DOS application.
You are confusing the term UNIX-like with similar to previous UNIX
desktops. That's not at all what I meant.
I think that your just confused about the situation. Not trying to be
offensive so don't take it the wrong way... it just seems to be a normal
thread of thought with discussions around Linux desktops.
There is no UNIX-like anything with pretty much everything you've talked
about and shown examples
of liking. I think that besides some general system design and programming
approaches there is nothing in the Unix tradition that really helps out in
making a quality desktop experience. There are just features that you want
that sound actually nice to have. Especially the documentation thing.
I don't use GNOME, but...
I don't use GNOME, but...
Of course, unlike in Windows or GNOME, you had to edit a config file to get new items to appear in the panel, rather than using dialog boxes.
> and poorly documented syntax that is backwards and makes almost no sense
> unless you understand the internals of whatever application you happen to
> be using at the time.
> because that is what your used to your then just say so. There is nothing
> wrong with that. Evolution does suck, but other IMAP applications are no
> shakes either.. so far the most decent one I can find is actually 'mutt'.
I don't use GNOME, but...
I don't use GNOME, but...
> having only one key/value per file (which has its own disadvantages)
> database & dbms give you.
> stuff, such as centralised administration, easier
I don't use GNOME, but...
Since I'm being a completionist, let me point out another thing. You
forgot to mention another argument against text file configuration:
configuration file size. A set of (binary) registry entries can be parsed
more quickly than a large text file.
This became a real issue in KDE, as well, long ago; but taking the hit
once per session is quite acceptable. So we have canonical textual
configuration files, a fast-to-read binary cache
in /var/tmp/kdecache-$USER/ksycoca (which can be completely nonportable,
mmap()ed by its users directly), and a daemon which watches the textual
configuration files and regenerates the cache whenever they change.
I don't use GNOME, but...
I don't use GNOME, but...
I don't use GNOME, but...
Stormy Peters: What should the GNOME Foundation accomplish in 2010?
Stormy Peters: What should the GNOME Foundation accomplish in 2010?
Stormy Peters: What should the GNOME Foundation accomplish in 2010?
of the foundation
Stormy Peters: What should the GNOME Foundation accomplish in 2010?
How about...
Focus on performance, footprint and quality
Sometimes GNOME (and to be fair, others have this too) gives me the feeling that they rather chase the next feature than finishing the current one properly. It's very understandable from a human angle, but maybe a bit of focus on performance and footprint will do wonders....
Stormy Peters: What should the GNOME Foundation accomplish in 2010?
+1 copy buffer. Why in hell is the behaveour of CTRL-V != middle-click != Shift-Insert. Why is a copied content sometimes only inside Shift-Insert or/and middle-click?! To make the user try twice or three times each time? What's the frickin' sense of it?!
Stormy Peters: What should the GNOME Foundation accomplish in 2010?
the "selection buffer".
Ctrl-V pastes the "clipboard".
buffer", a number of old buggy applications did just that. Then you
couldn't rely on the contents of the clipboard buffer being unchanged until
you press Ctrl-V. You could carefully select some text, click on another
window accidentally select some text, and boom! the text you carefully
selected is instantly blown away. Keeping the selection and clipboard
separate is also less confusing to windows users as they can use Ctrl-C and
Ctrl-V etc. exactly the way they use them on windows and ingore the
selection buffer completely.
two pieces of text at the same time. So you could copy one section of text,
select another. Then you when you switch to the other window you can paste
the selection buffer and the clipboard without having to switch back to the
original window.
Stormy Peters: What should the GNOME Foundation accomplish in 2010?
was a user interface to get at them...
Stormy Peters: What should the GNOME Foundation accomplish in 2010?