Discussion of command history in desktops
Stefan Israelsson Tampe
stefan.tampe at spray.se
Wed Sep 8 02:47:42 EEST 2004
I'm looking for a project to spend some of my spare time on. And wonder
if you find the following proposal interesting. If we find it worth
studying this forum looks like a good place to start discussing it.
Abstractly when I work with gui application what I most often do is
constructing arguments to be executed by a function e.g.
>myapp/.../set_color object rgb-color
Now, I find the backward-search in the command history very useful in a
lot of applications I use (shell,matlab,python,...)
Is a "command history" on the desktop level of any use e.g. do we want
to design a protocol to direct textual representation of application
commands to a global history server for usage such as simple backward
search or to do more complex searches. Or do
just introduce bloat?
*Gui - applications generally do not work with textual representations
of commands and do not expose these to the user.
so it is harder to search. But note that a search for an IP adress
entered last week can still yield useful results.
*The recent file history is a kind of example of such an application
so we do use these ideas today, is it worth to generalize this?.
*I think that this sort feature facilitates a Input Once paradigm.
*The input from humans are slow, so we should not stumble upon any
performance issues at first glance, we risk of cause on the other hand
*The recall command, modify and run use case could of cause be
*We should make sure that running in user mode and running in program
mode is tracked to ensure that scripts do not send command
representations to the history.
*Writing metadata to be associated with a user input is more likely to
be done and is more effective (one program is used by
many users) then associate metadata to a file, so recalling a file by
associating with what I did with it seems to be an
eg. find file associated with MIME svg and associates with mouth
sometimes during the previous 30 days
-Remark, going through all svg-files during the
last 30days and in those search for mouth is another approach of
*Find previous enered settings in a form is simple. by
not storing previous steps in the document is good I think.
if you need to bring the history with you bring it in an extra file
and import the history to your new desktop.
*If I make one command per minute which say consists of 100 bytes and
work for 8 hours I will generate about 1 megabyte of
data per month, searching one megabyte backwards for a match is done
in less then 1/10 of a second I think.
*How do we connect the application to the server. I might want
many servers picking up the commands.
*Thinking about the form of the message about the command string I
suggest the following,
message = (item_1,item_2,...,item_n)
item_k = ("argname" , "valuetype", "value")
("date" "date/se" "2004-09-20")
("fkn" "path" "/myapp/.../set_color")
("data" "file" "~/smile.svg")
("arg/item" "text" "mouth")
("arg/color" "color/rgb" "128,0,0")
*We need to specify value types and some meta data argument names as
*It is good to unify the textual representation of a value e.g.
rgb-color, date,time but actually one can think of reasons to not
specify these too strictly e.g. less burden on application
writers implying harder to search and use data though.
*I'm not an expert in databases, but implementing a simple backward
search server a can do, I actually made one in python
using the dbus a couple of days ago, but for performance reasons
I think that a c-version with python interfaces is something I could
start hack on.
*It would be nice to try implement the client side, on a
live application and test it out, any suggestions.
More information about the xdg