[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MiNT] desktop from components (was Re: [



> > I think that a MiNT with proper virtual memory and shared MiNTlib
> > (recompiled all prgs in /bin/) would be required for this to work
> > efficiently.
>
> I see more a problem for the fork() and exec() calls, they are naturally
> expensive system calls.

Well, no solution has advantages only. However, on a faster machine, 
this wouldn't be a big problem. I actually saw something like that 
working on a NeXT - where even desktop clock executed /bin/date to get 
the current time - and it worked rather well.

Obviously the 'AES tool' you mentioned should be written too. IIRC 
there is uch a tool which displays text-based dialogs on terminals. We 
can adapt the format it uses to define the dialog.

At this occasion we could also give up the desktop menu bar, moving all 
its functions to pop-ups (since as the screen grows, the mouse pointer 
is more and more far from the top of the screen - so switching to 
popups would minimize the mouse movements in a considerable extent).

Obviously, there should be text files (or scripts) which describe these 
and allow to freely (or almost freely) assign functions to menu 
entries. So that a menu selection would automatically execute the 
proper program (as defined in the config) with proper parameters (with 
parameter template defined in the config).

For example, on the menu that is popped up when the user right-clicks 
on a file (in dir window), there would be an entry "delete". The 
corresponding entry in the config would look like

"Delete item": exec '/bin/rm -v %s'

where the desktop would substitute the pathname of the selected file
for the %s. Obviously the text above is just an example, the format 
must be invented.

It would be nice if /proc, /kern etc. had menus separately from regular 
files. This would allow to display 'Terminate' as menu function when 
proces it selected, instead of 'Delete'.

This way the user has a possibility to freely customize the menus. 
Perhaps the format of config files may be grabbed from the fvwm, 
because - IIRC - the fvwm popups are defined just this or similar way.

Also I don't see a necessity of placing drive icons on the desktop. By 
default it should be:

- Trashcan
- $HOME
- well, ok, floppy disk :-)

Root would have more, i.e.:

- all system directories (/etc, /home, /usr and so on)
- also all kernel dirs

Of course, there must be a way to customize this too.

I don't see why for long operations there must be progress bar on the 
centre on the screen, taking up a half of the screen area. There must 
be a way to automatically iconify the progress bar window once the 
operation starts. The progress indicator would appear on the icon.

Oh, well, perhaps this is enough.

CVV

--
Konrad M.Kokoszkiewicz
draco@atari.org                             http://draco.atari.org

* Ea natura multitudinis est:  *  Taka to już natura pospólstwa: *
* aut seruit humiliter,        *    albo służalczo się płaszczy, *
* aut superbe dominatur.       *        albo bezczelnie panoszy. *
                     (T. Liuius XXIV, 25)