Re: Ease of Use?



Hello folks and all,

>     I don't know, but I really wish to see more Emacs-like programs,
> that is, coming with a Lisp (or something similar) interpreter
> embedded, so that these programs could be easily extended to almost
> anyone's needs by changing stuff in a high-level language rather than
> in C or C++. Here is some stuff I think of:

Actually, not to forget, Gnome itself has the potential to achieve this. You 
can access all the Gnome API through languages like Perl, Python, etc. al. 
the desktop should provide events at some point that allow you to plug in 
with custom code.

Like something gets pasted to clipboard. I would love to write something that 
handles it and who knows, maybe it's possible already. KDE does it with a 
special applet with Web-URLs. Great when I need to leave Galeon...

Or a file gets selected and a popup menu is to show up. Do I want to add some 
options here? Yes, sure I will. I will want to write a script to handle my 
CVS checkouts specifically, allowing me to check in or out and that only for 
files really of that origin......

Or maybe I want to define my own view-filters for GMC. Like hiding away files 
of my choice..... or ordering the way I code..... or whatever.....

>     - Web browser's bookmark management: it could be great if one
>       could decide how to store the URLs -> in a file, add in a file,
>       put it in a database, etc... with of course a GUI tailored for
>       this, instead of being forced to use what the browser gives you
>       ("DIY man !", OK, but you'd rather write stuff like this in
>       Lisp than in C/C++). The home page could be generated from the
>       data...

Well, to be honest, I'd prefer C++ for that task, but is mostly because I am 
not too Lisp literate. :-) But luckily, we ask for all, don't we? So let 
there be Perl as well....

I think Gnome ought to offer an app scripting services too. An app ought to 
be able to define its API towards a scripting language and then the Gnome 
gives it the bindings.... that way, each app would support all scripting and 
not just one preference of some individuals.

>     - I read Big5 Chinese Web pages, but some pages don't tell me that
>       they are encoded in Big5, so the browser thinks it's Latin-1 and
>       I have to manually switch to Big5: well, I could define a list
>       with regexps to tell the browser which encodings to use

Very valid point. And while you are there, remove pop-ups while loading of 
pages, adding a button to the GUI that makes them show still, if you want to 
be really elegant. And remove images that you suspect to be ads....

>     - Microsoft creates a new tag only implemented in IE: write the
>       code in that language to simulate it...

Common...... :-)

>     - I live in Taiwan and wish I could listen to some radio programs
>       in France. Wouldn't it be great if I could program a browser
>       to:
>
>           - connect to the Web at 2:55 AM (yeah, metered Internet
>                                            connectivity and phone,
>                                            sorry)
>           - connect to the radio station's RealAudio (or whatever)
>             server and "listen" untill 4:00 AM (-> in a file)
>           - disconnect from the Web at 4:05 AM
>           - copy the file to my MP3 device

This is indeed a cool idea. BTW: I think I saw a sound driver that allows 
relay to a remote sound server. It can be used to record to a file as 
well..... dunno about the format though. You can play that then.

>     - let's say I have some program that generates some log files that
>       I would like to view: vi, Emacs, less, OK, but why not using
>       a Web browser ? I could write some code, etc. and tell it how
>       to output the stuff (color, font, indentation)...

Hey, your log files will be HTML anyway..... ;-)

You can write such scripts independant of the browser and view the output of 
those scripts.

>       A browser as a database client ? Yes !

Well, You take this too browser centric, IMO. Teach the desktop to display 
your data the right way. Like opening a log file would run a script to create 
the view and the browser would display it. Don't teach the browser too much 
about non-HTML IMO.

> > into the GUI?  Take Evolution as an example, what benefit can be
> > imagined from a commandline buffer if any?
>
>     A complete programming language should be provided so that new
> functions can be written and their user interfaces can be
> created; that way, CLI and GUI would be complementary.

True indeed. But my wish would be support a general interface to get along 
with all scripting languages in one step.


>     Then, it would be great if I could say : OK, you show the classic
> stuff: directories on the left and files on the right but when you
> are in that memos directory, don't show the files on the right but
> rather lines like:
>
> [xxx] zzz -> aaa / yyy

Absolutely.... I would fancy that too. True, Nautilus may show images, but 
that's not the whole story. I work with text files more often and I want to 
define the abstract I see, not just a filename..... for a source file, it 
would be nice to see the last change comment.... :-)

>     and putting the cursor on such a line would open a small window
> with the contents inside, etc...

Well, I guess, we can expect a preview feature from the GUI folks at Eazel 
someday.

>     GUI is such a sensitive and personal issue that it makes sense to
> let users modify the GUI in the way they want. For example, in
> Internet Explorer, when I open a new window, it uses the current page
> as the contents: I like that. In Navigator, it uses the home page: I
> hate that. I wish there were a variable *new-navigator-page-contents*
> where I could say :blank, :home-page, :current-page, whatever.

I am not even sure, if there is not such an option. I would suggest to have a 
function that you can overload. That's better yet, allowing for any kind of 
thing you might want to do. Switches don't really take scripting, you can do 
that in .cfg or .ini files as well........

>     That's why current GUIs are so frustrating: you can't modify
> them, er, I mean, you can, but then, you would have to do the same
> thing at each new release (in a C/C++ only-program).

The key is the get these hooks delivered and access to data structures that 
define a context. What GMC window am i in, what dir are we supposed to 
display, what is the filename, its attributes and stuff? Ok, I tell you what 
to do.... or just do whatever you normally do....

This is about event model. Since events and toolkits go together, I'd suspect 
that it's not that much of a problem to achieve our goals. The point is that 
it makes no sense, to talk of this now. Gnome is not stable in many regards 
yet and while it may not seem so, I expect that adding the scripting 
callbacks to fine-grane behaviour will be easy, once the thing is stable.

But for now, I guess, it will take patience from us. I rather see need to aid 
people contributing by geting it to work at all. Then make it work to 
everybody's needs....

>     So, for me, Emacs is the model for the next level. Scary, eh :-) ?
> Well, the evolution of Emacs + Gtk will be interesting... What's next ?
> Emacs + Gtk + ODBC and have all these query results in Lisp lists :-))) ?

I believe, you will be able to teach Emacs to do a lot of what you meant to 
teach your browser. Even the dired mode will be more powerful than what you 
have.... all it takes will be access to the Gtk from Lisp. Does it have that? 

BTW: The Gtk-Emacs didn't like me..... :(

Yours, Karl





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