Re: RGSG - File & Edit Menus

["Dan Kaminsky" <effugas best com>]

-----Original Message-----
From: Frederick I Gleef <gleef@capital.net>
To: Dan Kaminsky <effugas@best.com>
Cc: gnome-gui-list@gnome.org <gnome-gui-list@gnome.org>
Date: Monday, August 03, 1998 3:20 PM
Subject: Re: RGSG - File & Edit Menus


>> BS.
>
>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 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.

>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.

>
>> 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.

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


>[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.

>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.

>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.

>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.

>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.

I LIKE the idea of edit menus showing up gnomestyle.  I just fear the user
saying "Oh, no edit menu, I can't copy."