[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-look
Subject:    Re: kde's future
From:       "Friedrich W. H. Kossebau" <Friedrich.W.H () Kossebau ! de>
Date:       2001-01-10 23:37:27
[Download RAW message or body]

"Friedrich W. H. Kossebau" wrote:
> 
> rik@kde.org wrote:
> > That's great, but I just tried to figure out how the 'New' menu would
> > look, and getting that right seems difficult. I've spent a while on
> > it now, and there's so much ambiguity, lack of context, etc, to deal
> > with, that I'm not sure it'll work. Not wishing to put a damper on this
> > nice idea, perhaps you can come up with a good example of how this
> > menu would look for us :)
> 
> So if you ask me do suggest a categorisation: For a start it could be
> done by simply copying the kde default app menu structure. Or the
> mimetyp structure. Or have a few tarred alternatives. Then rely on user
> feedback ;-) What would be needed is a template structure editor because
> I think there is nothing more user specific than what templates are
> needed.
> 
> I think you shouldn't try to have the perfect solution from the
> beginning. I think it will develop quite quickly once the basic feature
> (extended new menu) is there.

What about the GNOME people? Perhaps they have already such a system, or
are developing one. I think it is something that should be done
together. No language binding, no lib dependencies so far. Only
.desktop-files which are already common :-) If the templates root
directory isn't moved to a general place (~/.templates) it could be
linked between the two projects file system specific ones.

Shall I go and contact them on that GNOME-KDE-mailinglist? I haven't had
any contact by now. Not engaged until now. Maybe you, Rik, are more
known and respected? Please, don't get me wrong, I don't want to
delegate you, I am only in strong wish for this feature getting mature!
:-)
 
> > > * copying/moving by dragging and dropping an document symbol (see
> > > khexeditor!) from the toolbar opens the question what to do if file is
> > > copied and content in app has already changed.  should be directed to
> > > the user :-)
> >
> > Probably copy the file in its current state. I think that would
> > fit the Principle Of Least Surprise (one of my favourite principles.)
> 
> :-) What I think of is that I happened to see many people (including me
> in my early steps) to use one 'finished' document e.g. a letter as a
> template for another. I did this by opening the existing document and
> starting immediatly to make the needed changes. Then I stopped very
> short in front of the save icon (not always :( and went to do a "save
> as..."
> 
> Hm. I suggest to reduce this to one question whether to take the copy as
> new document base. If the user rejects this he only wants a print of the
> actual. If he agrees what other reason could there be then him stating
> he wants to keep the original file in his original state. For different
> needs there could be a command "sync" (not save!) that does write the
> actual working state to the actual base.

Meanwhile I have extended that idea - theoretically. An opened
document/file is in my thinking identical with the saved file it was
opened from. Somehow it is like a great preview to me that is only
ripped off from his surrounding. As long as the file is not stored on
the desktop. 

That is why I would like to have the file menu of the app's window
containing a lot the edit/RMB menu of the filemanager offers:
* properties -> edit file name (only file name, not url), owner, rights
  -> could later be extended to EA editing
* delete / move to trash basket
* open copy from this (english is not my first language, sorry)
* open with (yes, imagine you view an image in kview and decide to work
with pixie on it... 
  or have happened to open a file with kedit but want to proceed with
kwrite... 
  don't know whether this is usefull, just an idea. But makes some sense
to me...)
* open fm window with document's directory/url
* sync/save (everybody is used to the term "save" I have to admit)

Do you like that idea? Document-centric in its extreme, isn't it?

You told me to spill me ideas out. Here is another one:

I think there is the need of a special document/file server. Its
speciality lies in a  synchronizing ability that enables hot
teamworking. What do I mean: Imagine a document/file used in a project.
It is used by all the persons working on that project. For example the
TODO file.
Today's disadvantages:
- Only one can work at once on that file.
- Without a block of that file like it is unfortunatly often done
another one might access that
  file too and do his own changes. Without a cvs system (pardon, I don't
know exactly how it 
  works) there is the danger of loss.
- one might not know who is already working on the document, and what he
is doing
- don't know but I think a block is hardly done via ftp
- a third person opening the file for read does this before the other
has saved his changes which 
  have rested for a long time in his opened app that doesn't do
autosaving (or uses a tempfile)
...and a few more perhaps. CVS might be a good thing for e.g.
programming where only consistent changes make sense. But it isn't the
ultimative solution for simple text, papers, graphics, calendars,
whatever.

If there could be a server that is started if more than one is to access
a file and synchronizes all the apps it really would be killing! I again
have no idea whether there exists already such a system, on which os
ever. 
As most changes are incremental or could be described as commands it
would only need small data to exchange with the apps. Except if someone
includes something big from the clipboard. But that's bad luck and would
take a little longer for those having bad connections... but they still
would be uptodate. What would be further thrilling is that it might be
interface driven, meaning every app that knows about the
protocol/interface can communicate with the server unrelated whether it
is a gnome/kde/X/win/mac/psion/WhateverCanTalkXML app. If the server can
only handle pure text and XML it should be able to handle a lot of
today's and tomorrow's formats :-)

I have no further idea about implementation/security/etc. But hopefully
the basic idea gets into more heads and spreads around until it finds
someone having enough knowledge to code it.



One more idea:

I think that KAction thing is great. But stucked halfway in my eyes. I
already proposed this some month ago but maybe it was too early. So once
again:
It is said that all apps should be designed best concerning menu and
toolbar structure. But that can be hardly achieved as users are
different, have different needs, may be overwhelmed by too many
possibilities, have their own opinions. Configuration means freedom.
KAction (for those never looked into code: by now toolbar's entry
editing) is the key. But why is it limited to the toolbar?

An app has several options to do actions on a loaded file's content. The
user can access them by topmenu, toolbar, sometimes popup menus caused
by RMB. They are all commands, some need further parameters. By now they
are all arranged in the menu. Some are directly accessible by toolbar (I
will call it mouse shortcut), others are by key shortcut. 

To be honest I don't like the topmenu. If I have get used to a program
and found out which actions I use, have setted all parameters to my
needs I add the "my" actions to the toolbar and would like to remove the
menu now from the apps display to win place. If I happen to need
something not on the toolbar/I forgot its key shortcut I would like to
access the full menu via popupmenu's item or via push down button on the
toolbar. 

That means: The toolbar editing should be extended to something like a
all menu/toolbar editing.

If I set the toolbar to show only text, how does it differ from the
topmenu? It cannot be moved anymore, other than KDE1. But that's nothing
special (only a fixed decision ;-). The topmenu is a menu that was
defined to be unmovable, to have the entries it has, that are all
connected to further menus. Some of apps' toolbars have entries that are
also connected to further menus. Difference is that some menus popup
when their entry is clicked, others only if the entry is pressed down
for a while.

And so on. If you are still reading: Thank you ;-) But it is a rather
heavy thing I don't know how to handle. Maybe I simply should describe
the idea I have in my head and wait for questions.

Here we go (using konqueror as example):
The app tells KAction all the possible commands, dynamically created or
special menus and menu calls.
example:
* commands: move up in directory, go home, cut, copy
* special menus: bookmarks, windows, directories up to root, open with
* menu calls: RMB on file, RMB on directory

The app tells KAction always which command's availability has changed. 

Then there is the menu GUI structure. There are bars, menus and entries,
additonal spacing entries:
An ENTRY is a command or a link to a (special) menu. It could be also
both. It has both a text and an icon.
A SPACING ENTRY is either a separator or a stretcher (only in bars,
otherwise separator too) 
A MENU is a list of entries. But can also embed other menus. 
A BAR displays a menu, like toolbar, menubar. It can be movable or not.
If it is movable it can either be moved to another border or free on the
screen. What to display (text/icon) can be adjusted individually per
bar. The icons' size too. A bar's size is defined by the number of
entries if there isn't a streching entry. Then it claims the full height
resp. width.

If there is no filed GUI-description the app tells a default: which
bars, which structure, which menus on menu calls.

The user is able to do: 
* change settings of menus, entries and bars
* define new menus: identifier, name, icon
* define new bars: which menu to use
* change menu calls: which menu to use for menu calls

Then there could be profiles/schemes describing which bars and menus for
menu calls to use and where to show. Use your fantasy!

Well... good night!

Friedrich

[prev in list] [next in list] [prev in thread] [next in thread]