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