[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 11:00:12
[Download RAW message or body]

rik@kde.org wrote:
> 
> #if Friedrich W. H. Kossebau
> > * creation of document by RMB on Desktop or konqwindow that said I
> > have to stress my wish for an extended 'new' menu with subfolders!
> > 'New/Letters/Official' would be a quick thing to create a new official
> > style letter that is then opened by KWord. Or 'New/Icons/KDE
> > Default-Style/Document' to create a new icon based on   the default
> > KDE-Style document icon that is opened by the icon editor.  Mostly I
> > am already in the place I would like to store that file so I do the
> > click for 'new' there.
> >
> > No more need to tell the app where to save a newly created file.
> > Only fill out the naming dialog that pops up before the file's
> > template is copied.
> 
> 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 :)

If I understood correctly the menu is build by having a look on the
template directory where there is a double structure of .desktop-files
describing each a template and templates itself hiding in the .source
directory. So extending this with subdirectories shouldn't be one of the
problems you think of. Rather how to combine global with local template
structure. Maybe it helps to have a look at how the apps menu is done
(don't know). There it is an app-centric approach, here we would like to
do the document-centric. Uhm. I don't think I tell you something new.
But you can prove if I got all right :-)

A way to combine global and local structures could be to double the
global templates directory structure and add user's own templates or
template directories in the according directories. IIRC the mimetype
thing in KDE 1 was organized that way. Well then I expect you to already
know more advantages/disadvantages I could imagine right now ;-) Yet one
point I would to add: there should be the possibility to hide a global
item in a user's personal view. Could be implemented by having a file in
his local structure with the global file's name having a config item "Do
not show".

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.
 
> > * opening of document by RMB on file on Desktop or in konqwindow, or by
> > drop on an app's symbol or an already running app
> 
> Yep, these things we have, at least.
> 
> > BTW: When is the drop of an document on a running application meant
> > to open a new window, when    to insert that file into the actual
> > loaded?  IIRC in alternative os (w, mo) there is usually the second
> > option used, which is more intuitive to me, too. So I would vote for
> > carefully rethinking the actual way in KDE.
> 
> Last time I used an 'alternative' OS (actually a very mainstream one,)
> I was irritated by the fact that when I dropped a file on one app,
> it 'inserted' it (actually, placed an icon and said something about
> object linking.) Then I dropped a file on another app (web browser)
> and it loaded it.
> 
> Sure, the web browser isn't an HTML editor, so it has no option but
> to load, but it has an 'Edit page' option in the menu.
> 
> Anyway, back in the world of KDE, I know that inserting is theoretically
> more logical, but I find loading the file more logical in practice.

Hm. Okay. We disagree. But what I think is still to be cleared is the
loading behaviour then. Most apps do open a new window for that file
only if the actual file has no changes. That is sometimes annoying
because that there is no change in the moment doesn't mean I want to
close it now.
 
> > * automatic saving on leave as default basic version control could be
> > reached by having an option to revert to file's state of opening time
> > (autobackup uses temp-file with automatic restortion if needed), and
> > undo buttons
> 
> Yes. I remember discussing this a while ago. I wish I had time to work
> on it :(
> 
> > * 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..." 

This is a very bad behaviour but it seems that people somehow divide the
actual loaded document from the saved. The reason may be in 15 years of
miseducation by badly designed standard software. But those peolpe exist
and must be helped. Because of that I would suggest to have a dialog
quering when copying (moving is problemless) whether to save the actual
state to the original file as well. In this case it should be cleared
which file is used for further work. Maybe I did the copy to have a copy
to show to someone an intermediate state, after that proceeding with the
original making it a mess again ;-).

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.
 
> > All this could be accessible while still offering that old fashioned
> > way. Those who like this way could simply remove the new/load/save items
> > from the menu and add a draggable document icon to the toolbar. Latter
> > lacks support in almost all apps by now. But perhaps it is simply done
> > by using khexeditor (is there another app beside offering this?) as a
> > template :)
> 
> Would be very easy to hack into other apps, I think.

Nice to hear that :)
 
> > Here I would like to introduce another wish I have:
> > Could there be toolbar profiles for the menu/toolbar settings? That way
> > it would be quickly done to change the layout with customized toolbars.
> > Or even better: load the apps with a parameter which profile to use. So
> > I could define Kwrite with one profile for cpp-files, and with another
> > one for pure txt-files. Makes even more sense when having EA.
> 
> Nice, but definitely one for the experts, or the pure document-centric
> desktop, where the user doesn't notice they're using the same app,
> because they're just editing a document.

But experts need toys too. And a pure document-centric desktop should
get his chance too.

These profiles could be extended to integrate further app settings... 

> > Oh if I only were a millionaire: I would give up my studies and do only
> > KDE coding. But I'm not :( So forgive me my demanding ideas. You should
> > know I have another lot still inside my head.
> 
> Well, feel free to spill them out. Hopefully there are some developers
> reading this and they will be inspired. I'm already inspired, but I'm
> already busy :(

Perhaps with extending desktop settings with different path to desktop
files ? ;-)
And enabling dynamic adding and removing of desktops? With storing
desktop settings each in a desktop describing file? To have project
specific desktops? Well, I have some more ideas for that if someone is
interested...

> > Sun doesn't see the moon I don't either
> 
> Try looking up. It's usually in the sky, but sometimes you can catch
> it wandering around in a lake.

Yesterday earth hindered sun, clouds hindered me. I knew it was there.
:(
In a lake? Where is that from? 

Right now I see the sun :)

And a clock! O dear, I have to hurry...

Friedrich

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