Re: RGSG - File & Edit Menus

[Gleef <gleef capital net>]

On Mon, 3 Aug 1998, Dan Kaminsky wrote:
> Gleef Wrote;
> >Please refrain from using vulgar language on a public list, even in
> >abbreviated form.  It is rude, inappropriate, and likely to invoke a
> >flamewar.
> 
> 
> Horsepucky.  Heck.  Manure.  Goshgollygeedarnit.
> 
> I'll try to be more sanitary for you, kind sir.  ;-)

I wasn't pointing that out so that you make sure not to offend my delicate
sensiblities.  I was pointing that out because this list spends too much
time on the verge of flamewar, and I hope to keep them from erupting
again.  Using insulting and vulgar words does absolutely nothing to
further your argument.  It does however, make the person you insult angry
and likely to listen to your insult more than your argument.  This is one
way to start flamewars.

 
> >> I count this as "we're modern just because we want to sound cool"
> >> concepts--tell me when somebody comes up with a computer with no use for
> a
> >> file system.
> >
> >Well, not that it is relevant to GNOME, but most embedded computer systems
> >have no use for a file system.
> 
> Wanna bet there are absolutely no code structures?  Structures of code, even
> in a database, correspond to "files".  One doesn't need a disk file system
> to have a virtual file system.

Saying memory structures are files shows that you use the term File in a
way that nobody else does, either inside or outside the computer industry.
Please check out the FOLDOC definition, which I think most people will
consider reasonable.  You can find it at:

   <http://nightflight.com/cgi-bin/foldoc.cgi?query=file>

 
> >On the other hand, I never said that GNOME should not deal with the file
> >system.  I said that many applications do not deal with the file system,
> >and a "File" menu for such applications is inappropriate and awkward.  I
> >continued by pointing out that more and more applications are moving away
> >from a file-centric user interface, and we should support these programs,
> >rather than stifiling them by forcing them into an obsolete interface.
> 
> What's a better way to FORCE the leftmost entry to deal with data I/O?
> *Any* other entry and all sorts of stuff gets shoved in by sheer semantics.

I don't think the leftmost entry need deal with data I/O.  If data I/O
absolutely must be in the left menu, make the left menu something like
"Program", make the top part of the menu reserved for data I/O, and insist
that the menu items to deal with them are explicit.  That is to say,
rather than have "Program->Open", you would have "Program->Open File" or
"Program->Open Session" or whatever.

I think that the RSG proposal, which has data I/O in a separate menu, is
perfectly reasonable, however, and will happliy endorse it.


> >> By the way:  Accessing the file system over the network, or
> >> the disk drive in a raw manner because the application knows the file
> >> structure better than the file system does, don't count.
> >
> >A networked database is a far cry from a networked filesystem.  They are
> >handled differently, and the concepts used in a traditional File menu
> >often do not apply.
> >
> >Accessing raw partitions is not accessing files, as there is generally no
> >filesystem in a raw partition.  Data does not equal file.
> 
> Data equals file at the local sense, not at the remote.  I should be able to
> take the data I grab remotely and save into a local file.  In essence, I'm
> creating a file in memory, and a save is a state grab of of that memory
> file.

Again, refer to the industry standard definition of File.

 
> That describes the expedition stuff.  I mean, you can export the reports
> into a comma delimited file, no?

Um, no.  The best you can do is, with a third party program, export the
tables into a comma delimited file, or perhaps export an SQL query into a 
comma delimited file.  Most reports refer to several tables, as well as
formating information.

 
> >[if it's on a database like UO, it's not a file]
> >This is another example of how forcing a file-centric
> >view of things would be troublesome and awkward.
> 
> I guess it's an issue of consistency...even though it's not a literal file,
> in the user's mind, it looks like one.
> 
> When I type up a paper, it's a file from the moment I start typing, even if
> I don't save it, even if it just exists in memory.
> 
> Note:  I rescind my analysis re: that apps are files too.  NOBODY thinks of
> them like that, myself included.  My point is better proven without that
> analysis anyway.

In most cases applications ARE files.  My point is that few people want to
think about files, and GNOME should allow software which deals in terms
other than "File" should have that option.  Combine this with the fact
that the left most menu should be consistent in name, and have many
features that do not belong in a File menu, and the solution of a
"Program" menu easily follows.


> >I am not saying that the user can't copy, I am saying that forcing an Edit
> >menu on these applications is absurd.  I would like to see Edit
> >functionality everywhere possible, I do not want to see Edit menus
> >everywhere I look.
> 
> Agreed.  I'm afraid though, if it's not in the gnomeprint, a user might not
> know it's there.

For many applications, that would not matter.  For applications where it
does matter, such as a word processor, they certainly should have an 
"Edit" menu.  I never said that Edit menus should be abolished, merely not
mandated.

 
> >We currently have an application independant way of doing copying,
> >X-Windows' copy features.  These features require no menus to operate.  As
> >GNOME develops, I expect we will see that a more robust copying system
> >will develop.  I further expect that this too will require no menus to
> >operate.
> 
> Hopefully.  We ain't there yet.  I ain't budgin' on it being needed.

Anything you say about using cut/copy/paste features on anything other
than text is currently unimplemented in GNOME, and experimental.  We
should not mandate in the style guide anything based on assumptions about
how an unimplemented, experimental feature will work.


> >Why require an Edit menu for features that do not exist yet, when they
> >likely will not need it.
> 
> There should be a lib level xv style copy screenshot functionality embedded
> in GNOME.

Yes, but:
 * It is not yet implemented
 * It can be implemented without requiring a menu to access it.

Then the menu can only be used where you want to remind users about it,
and not in places where the functionality is merely a side effect of being
a GNOME app.

 
> >Don't get me wrong, Edit menus are very useful when appropriate.  I am
> >just arguing against them being a requirement.
> 
> Edit menus shouldn't be there when there's no room.  Usually there IS room,
> however.
> 
> Maybe we should have a shrink order, with an order of menus that get cut off
> if the width is too thin.

This is dangerous, as a crucial menu could disappear under this.  In some
applications, Edit will be crucial.  The window shouldn't narrow to less
than the minimum size of the menubar.


> I LIKE the idea of edit menus showing up gnomestyle. 

I have no idea what you are trying so say here.


> I just fear the user saying "Oh, no edit menu, I can't copy."

The programs that need editing should have it.  Those that don't
shouldn't.

-Gleef