CodeMonkey

context: January 2005 is 4 months earlier than the latest web.archive of Clicker website. It is still lacking important (?) pages such as CodeMonkeyInternals (restructured from the current page ?) or ResourceCmPlugin explaining another thing code monkey was used for.

---

The CodeMonkey is a [Tool] for code rewriting that is due for Clicker 0.8.20 It will helps writing KDS/IDL code, accessing koLib templates (foreach on koList, cursors, etc), defining koLib & memory classes and much more.

Mechanics of CodeMonkey

The CodeMonkey core is a Perl script that performs input tokenization and manage context stacks (each 'block' has its own context). It comes with a helper package Tokens::Filter.pm that allows one to easily perform high-level pattern matching against operators, etc. Each CodeMonkeyPlugin can be requested separately via the @plugin "name.pl" in the source file.

Rules to write CodeMonkeyPlugin~s

All the 'top-level' code is for initialization

Among other things, it should insert _keyword hooks_ in $context->{hooks} to have plugin functions called when a keyword is encountered. You can also register _terminators_, that is, plugin functions to be called when the input file is completed.

# a skeleton CodeMonkey plugin

use Tokens::Filter;
print STDERR "using skeleton plugin\n";
$context->{hooks}->{skeleton}=['SKELETON',\&myHookFunction];
push @{$context->{terminators}},['SKELETON',\&myTerminator];
true;

sub myHookFunction {
}
sub myTerminator {
}

Hooks receive $mode, $tagname, $codeA, $codeB

The $mode parameter tells you the context where the keyword has been seen. It could be an 'INSTR' or a 'BLOCK'. $tagname returns you the first word that was associated with the hook (here 'SKELETON'). This can be used when multiple similar keywords wish to use the same function but still differenciate the cases.

$codeA and $codeB contains what you need to pass Tokens::Filter to analyze the code that triggered the hook.

sub myHookFunction {
  my ($mode, $tagname)=@_;
  my $code=new Tokens::Filter(@_[2,3]);

  # write your stuff here
}

$context and blocks

Each block construct has its own $context information. Thus when your hook is registered with $mode eq 'BLOCK', you can register local hooks in $context->{hooks}, etc. The "header" of the block (e.g. all the text between the previous instruction/block and the { symbol will used for the "block name" (after tags are processed). A hook can discard the name's output by setting a true value in $context->{naked}

$context->{upper} chains towards the upper-level context information.

controlling INSTRuctions

The hook can decide whether or not a terminating ';' should be written after the instruction's translation by returning a _true_ or _false_ value.

matching text

The Tokens::Filter package can be used to check high-level patterns in the 'running code'. The function to use is $code->match(<offset>, <pattern>). The <pattern> is a list of item types describing what we expect to be on the input:

• WORD matches an identifier that is not a registered keyword.
• LITT matches a litteral (e.g. a string/character)
• TAGG matches any identified keyword
• OPER matches any sequence of non-alphanum and non block-forming characters. Note that both "+","++","=++","*=&" will be seen as valid OPERators.
• SLST matches an opening parenthese
• LIST matches a completed list (pointing towards a specific code sequence).
• THIS matches the current tagged-keyword
• TRAN matches a translated item (from a previous hook application)

The type can be followed by a ":<value>" string further restricting possible matches For instance qw(THIS WORD OPER:~= LIST) will match an code sequence like skeleton var=(any thing can be here). The <offset> argument of $code->match tells the relative position of THIS in the pattern.

# let's try to check if we have the expected "skeleton var = (...)" framework.
sub myHookFunction {
  my ($mode, $tagname)=@_;
  my $code=new Tokens::Filter(@_[2,3]);

  # 0 is the position of "THIS" in the list ...
  if ($code->match(0, qw(THIS WORD OPER:~= LIST))) {
     # here we know.
  } else {
     die "unexpected use of 'skeleton'".$code->show;
  }
}

getting/replacing text

Once a pattern has been matched, you can get the text of the different items using $code->content. Each item in the pattern is numbered from _0_ to _N_ and you can retrieve its value with $code->content(i). For instance,

  # retrieve the variable name and the content of the list.
  # note that we get the list content as a raw string.
  # "skeleton myVar = (a,b,c,d,e)" ==> $variable_name eq 'myVar' &&
  #   $list_content eq '(a,b,c,d,e)'
  my $variable_name=$code->content(1);
  my $list_content=$code->content(3);

As the purpose of CodeMonkey is to _rewrite_ text, we could like to replace the actual text by something else. That is (again) done with $code->content() giving the new value as an additionnal argument:

  # rewrite it as "int* myVar[]=..."
  $code->content(0,'int*');
  $code->content(3,'[]=');

Of course, you may use PERL's power for more complex operations, for instance if i wish to have all the items in the $list_content translated so that we extract their address and make an array out of it, it simply means

#  remove parenthesis
$list_content=~ s/^\((.*)\)$/$1/;
#  split the content, assuming a flat list
@list_content= split /,/,$list_content;
@list_content= map { '&'.$_ } @list_content;
$code->content(2,"{".join(',',@list_content)."}");

#now we have "int* myVar[]={&a,&b,&c,&d,&e};

---

Date: Fri, 14 Jan 2005 06:52:43 -0800 Mime-Version: 1.0 (Produced by PhpWiki 1.3.9) Content-Type: application/x-phpwiki; pagename=CodeMonkey; flags=""; author=PypeClicker; version=3; lastmodified=1105714363; author_id=PypeClicker; markup=2; summary=more%20like%20a%20tutorial; hits=124; charset=iso-8859-1 Content-Transfer-Encoding: binary

ClientCmPlugin

Context: I thought I had lost the clicker wiki forever, or at least, that I couldn't recover the part describing the late "code monkey" mechanics I had developed and used to "ease" development. It seems like some part of it had been saved in some wikidump folder in an obscure location of rsync-only file server of sourceforge. Maybe it isn't the latest version, but let's have a sample of what's in there anyway...

---

client.pl is a CodeMonkeyPlugin that performs rewrite of [KDS] client/server code, much like SlangSyntax used to do, but taking greater benefit of [IDL]-generated knowledge

Declaring interface we'll use

Each interface will use a *prefix* for its identification. It's important that one give different prefixes for different interfaces, especially if there are methods named the same way in the interfaces. Interface declaration can use either client or using keyword depending on whether you also want a struct kdsClient to be created.

syntax:

using "$servicename$":$interfacename$ as $prefix$;

client "$servicename$":$interfacename$ as $prefix$;

$servicename	the path from kds://services to the kdsService (e.g. timing, sys.paging, sys.binterpreter, dev.disk, etc)
$interfacename	the name of the declared interface on the service, just as in IDL files
$prefix	must be a C-compatible token that will be used to prefix every interface-related things like messages structure, etc. The prefix may vary from one source file to the other.

using and client statement superseeds the need for #include <api/___.api> and should precede any use of the interface (either through implementation or invokation). Moreover they must appear at top-level.

declaring a simple server

The server declaration will need either using or client to be first defined. Each server may implement any number of interfaces but they should all belong to the same service. Server declaration must also appear at top-level

syntax:

server "$servicename$" { (<server_command>|<implementation>)* }

<implementation> ::= implements $interfacename$ { <method>* }
<method> ::= method $methodname$ ( $serverinfotype$* $serverinfovar$, message $name$ ) { <code> }

the method command will generate the appropriate function prototype, using _$prefix$_$methodname$ as function name. You normally don't need to know that name unless you want to do funny KDS bypassing stuff. Functions parameter are available through the message structure (e.g. $name$->$parameter$)

Adding ServerCommands

Since 0.8.20, the "client" plugin is also able to handle server initializaion/termination and activity callback declarations. The syntax is

<server_command>::= <server_vars>|<server_methods>
<server_methods>::= on $eventname$ ($args$) { $code$ }
<server_vars>   ::= with (queue|thread) $varname$ = <value>;

A sample

Let's suppose we defined a 'test:hello' interface with methods void hello(char* who); and void bye(char* who);

@plugin "client.pl"
using "test":hello as greet;
client "display":basic as print;

server "test" {
   implements hello {
      method hello(void* we_dont_care, message m) {
         printStr(&DefaultConsole,"Hello %s!\n",m->who);
         return KDSE_OK;
      }
      method bye(void* we_donT_care, message m) {
         printStr(&DefaultConsole,"L8r, %s...\n",m->who);
         return KDSE_OK;
      }
    }
}

---

Date: Tue, 19 Oct 2004 08:34:12 -0700 Mime-Version: 1.0 (Produced by PhpWiki 1.3.9) Content-Type: application/x-phpwiki; pagename=ClientCmPlugin; flags=""; author=PypeClicker; version=3; lastmodified=1098200052; author_id=PypeClicker; markup=2; hits=49; charset=iso-8859-1 Content-Transfer-Encoding: binary

Coding Kick-off Meeting

Memories of a meeting that could have been helpful when we were a team working on Clicker. It actually happened with a EU project a bit later

• it was our ordinary 3-days-midweek meeting
• almost no professors involved, but everyone who would program anything for the project was present
• we came with machines ready to build the equivalent of a 'hello world' for the feature we're targetting. For Clicker, if we were to build a sound mixer, 'hello world' would have been being able to output a square wave. If it was to make a configuration tool on a foreign OS, 'hello world' would indeed be a window and an 'Hi.' button that tells it to proceed
• we would not try to have a polished outcome (that would be the job of a smaller, dedicated team, starting after the meeting) but to identify all as many as possible of the issues that could block the smaller team and prototype a solution to them. For the sound mixer, applying volume per channel could be left post-meeting, but deciding how to tell the channel's volume from a control pannel has to be prototyped. For the configuration tool, reporting ongoing progress bar must be prototyped, 
• people don't need to know the same technologies. If one coding team will use ncurses while another uses WxWidgets and two others go for electron, that's fine.
  

Now imagine if I had heard of that 'sprints' back then:

• Every morning, we spend one hour deciding what we are trying to achieve by the end of the day, what are the goals that are candidate to prototyping and which should get our attention first
• Each coding team spends 4-6h trying to prototype what has been decided
  
• (my 2 cents: If one team is done faster, they can use the remaining time to study the technologies picked by others, how they address what they've just done with that, rather than trying to tackle more objectives)  
• The end of the day is used to review what has been achieved, identify strengths and weaknesses of each approach, and update the list of candidate goals for the next day. "Oh, that makes me think: we'll definitely need a way to pick a file for ${purpose}". We'll see tomorrow morning if that is important enough to be one of the prototype goal of the meeting.

(Hopefully, at the end of the meeting, everyone has a better understanding of each others' skill with their technologies and some of the weaknesses of the technologies. Hopefully enough to decide the team and technology to actually implement the features)

gdbm perl tools ... could they save the lost wiki ?

Clicker was the first of my projects to use a Wiki. And the last time I thought about an "information browser" program. Yet, the phpwiki database was broken on a regular basis. I built gdbmpatch and gdbmshow helpers to know how I could repair it. The Clicker project sort of died when a last update to the sourceforge policy made the phpwiki no longer working.

#!/usr/bin/perl

# a wiki file is made of different keys for each page. The content is 
# a sort of "bencoded" file with following rules:
#   * s::"" encodes a string
#   * a:<#items>:{<;-separated content>}
#   * i:

# p contains the html cache of the page (compressed)
#   available keys are $_cached_html and !hits

# li contains "backlinks" as a simple array (keys are integers, values are page names)

# lo contains "page links", same structure backlinks

# v: contains one of the page's version.
#   $author and $author_id tells who wrote the page
#   $summary, !mtime tells more about the page.
#   $pagetype should be "wikitext" and "%content" is the whole content.
# note that if version i exists, versions 1..i-1 should exist too.
# obsolete versions have an additionnal "_supplanted" key.



use GDBM_File;
use PHP::Serialization qw(serialize unserialize);

tie %file, 'GDBM_File', $ARGV[0], &GDBM_WRCREAT, 0640;

print "tied $ARGV[0]. items: ".keys(%file)."\n";

delete $file{pResources};

untie %file;

#!/usr/bin/perl

# a wiki file is made of different keys for each page. The content is 
# a sort of "bencoded" file with following rules:
#   * s::"" encodes a string
#   * a:<#items>:{<;-separated content>}
#   * i:

# p contains the html cache of the page (compressed)
#   available keys are $_cached_html and !hits

# li contains "backlinks" as a simple array (keys are integers, values are page names)

# lo contains "page links", same structure backlinks

# v: contains one of the page's version.
#   $author and $author_id tells who wrote the page
#   $summary, !mtime tells more about the page.
#   $pagetype should be "wikitext" and "%content" is the whole content.
# note that if version i exists, versions 1..i-1 should exist too.
# obsolete versions have an additionnal "_supplanted" key.



use GDBM_File;
use PHP::Serialization qw(serialize unserialize);

tie %file, 'GDBM_File', $ARGV[0], &GDBM_WRCREAT, 0640;

print "tied $ARGV[0]. items: ".keys(%file)."\n";

foreach(keys %file) {
  next if !/$ARGV[1]/;
  print "$_ ==> $file{$_}\n\n- - 8< - -\n";
#  delete $file{$_};
}

untie %file;

Drop the question mark ...

In its original design, and up to version 3.0 distributed with the 3rd edition of his book (2005), Andrew Tanenbaum's MINIX was a single-address-space operating system. Granted, you could have multiple process running simultaneously and they're isolated from each other, but they all happily frolic in the same address space, and only the segmentation unit of the x86 processor prevents the havoc from happening.

It's not necessarily a bad thing: paging introduces overhead in address resolutions - especially when your virtual-to-physical translation buffer is no longer sufficient, requiring up to 3 cache misses before you get a single byte of data. Its impact on context switching is even more frightening than this: whenever you wake up another process, the whole translation buffer has to be flushed (okay, *some* pages -- usually those holding the kernel -- can remain sticky).

Not having paging has a huge impact, however: you can't build any sort of modern virtual memory. No partial swapping of some unused part of the software... and no "statistical allocation" of the memory. Much like in MS-DOS times, if your compiler *could* need up to 16Mo of RAM, you must give it all from the start. If it happens to need only 8Mo for the file you're compiling and that you need those other 8Mo for doing something else meanwhile, well, too bad for you.

But it has changed since then. Between 2008 and 2010, people have been adding a "virtual memory server" to Minix, which in turns remembers me of my "pager2" service in Clicker. It let you control mapping of your address space (do_mmap, do_mmunmap) and supports the process manager (do_fork, do_exit), but here, it also directly handle page faults through message passing. Again, it's very "memory object"-like (another key Clicker concept), which shouldn't be a surprise: I got the idea of the memory object while reading the other Tanenbaum book about operating systems :)

Altogether, I'm absolutely not convinced that placing the address space management into a server rather than into the microkernel was the best design choice one could make. Granted, 'forking a process' is something that could happen out of the microkernel, but pagefaults ? ...

Iirc, I had the idea of letting the Clicker microkernel know that some physical pages had been 'pre-allocated' to some memory object (which you can think of as 'virtual regions'), and only notify the server-level code about a miss when that pool is exhausted... a sort of hybrid micro/exo kernel. But I dropped the whole project before I got to that point.

One of my major "errors" regarding the Clicker overall design, though, was that will to make the paging optional, despite it turned out that every other feature was depending on it. My module mechanism allowed me to do so, but it over-complicated the whole code, introducing the need for sophisticated book-keeping structures, run-time service replacement, and a mysterious "private heap" feature where linker scripts should have been enough.

the lost Wiclicker

Back in June 2004, I stopped trying to have a documentation as static .html files, and turned towards a (php)wiki for Clicker documentation and research. It turned very useful to coordinate our efforts as DasCandy provided some sporadic help here and there, and whyme_t developped installer tools and modules for Clicker. I was so happy to see a team at least starting!!

The wiki is now unfortunately defunct after both a spam assault and my failure to identify a sudden bug in Php code. I have a last dump on my system, but I haven't managed to recover the content yet.

After the lost forums, it was somehow too much to try to recover things at all.

Hyper-Desktop Markup Language ?

Among the "funny ideas" I had for Clicker, many has echoed in other's mind and some eventually got implemented here or there.

I won't call myself as "spolied inventor of tags", of course. I'm not. Though I have to admit tags are 100% aligned with what'd have pushed for Clicker if I had any resources to make things move by just pushing them.

Now, let's have a look at the box #7 of this "clicker desktop mockup" I made up somewhere near 2K++ ... the "one-key-command-line" for quickly spawning things is now mainstream ... Even Windows has it (or at least as some plugin) where you type [ESC]word[ENTER] to search and launch your report editor rather than crawling through clobbered menus.

"Incoming" (last imported documents) and "favourite" meta-folders are of lesser significance given we've got the "download history" window of Firefox. But let's check out that box #7 ... It was claiming "users do tasks, more than they use applications". That thing is starting to change as well, the welcome panels of Thunderbird 3, Wireshark (Lucid release) and K3B (a while ago) being an obvious example of it. They also claimed "a task is performed using a collection of tools operating on a collection of documents". We haven't got anywhere near that so far, afaik. Do I want to integrate something to the wonderful Tomboy application ? I have to learn C# ... Do I want to have Gimp able to learn new key combos for filters ? I bet I'll have to dig into some GTK+ and maybe some scheme or Python would help me.

Yet, all I'll be doing somehow is moving boxes around, connecting wires between blocks of code, etc. This is something that should be as easy to do as writing HTML, but there doesn't seem to be any Hyper-Desktop Markup Language around.

-- edit -- Btw, I was about to attach a picture in a thundermail while thunderbird crashed at me because I was also moving directories around. *sigh*. Long is the road.

shell companion windows

To some extent, it isn't necessary to write a whole new application for the futureshell. What we need is a connection to a "graphical tty" that is associated with the current shell, so that e.g. if I want to offer a preview of an image or show graphical relationships between items, timelines, etc., all I have to do is sending "drawing commands" to that companion window. Where the companion stands, whether it sticks and move along, what's its size, etc. can be managed by the window manager. That may not be as sweet as having "file descriptor #4" ready by default, but that'll certainly be easier to evolve to.

Formerly known as "FutureShell"

I once made a little mockup of "FutureShell", a sort of mix between Enlightenment terminal and nautilus. It had many "killer features" such as "intelligent icons" that can inspect the type of data you drop to them in order to move data to the "most appropriate place".

While working today, there's another feature I wish my shell/terminal had: transfer of configuration. I'd love I could somehow drag-and-drop the value of SSH-AGENT variable or the label of a directory so that it cd' to that directory in another window.

I wonder whether the SDL-for-perl could help me prototyping this ... since I've realised that I don't need to build up my own kernel / X server to experiment with document access.

It's all about tuning!

A major improvement in user interfaces is the ability to tune things into your own needs. When people says they are glad when things are uniform (Windows file selection dialogs, anyone), they typically forget how mad they were at MS the last time they faced an unwanted change in their application behaviour.

Right-click on the gnome bar to add/remove widgets or to drag the bar around is neat. global-set-key in emacs is neat. Do I have trouble remembering that F2 isn't for saving the current file ? I can just tell the application how I work rather than training myself to new commands. In that respect, I do love the ctrl+right-click of Enlightenment's terminal where I can tell "off with their scroll bars!" like the Wonderland's Queen of Hearts. I'd just have loved something more such as "tweak'n'tune" menu entry that would have dumped the current settings in /tmp/eterm-current.rc that would have had a comment saying "tweak at wish and save under $HOME/.etermrc to validate the current settings as defaults".

Let's face it, application designers: you cannot anticipate all the possible tuning needs of your users. A config file is 200 times worth any wizard you can come with. If you deliberately and definitely hide configuration away from users, you also remove them the opportunity to learn more and to repair things when they're broken (how long did i wasted investigating the output of strace -eopen in search for an undocumented resource/config file!)

All this because I couldn't close a tab in emacs by middle-clicking it (a firefox habbit) nor to adjust an Eterm background intensity with the scrolling wheel ...

The curse of configuration ...

./.config/gtk-2.0/gtkfilechooser.ini -- a single file that has been the reason of so much cursing these last months. Okay, i'm "migrating" my user profile for probably too long now, and i inherit previous defaults, etc. Yet, despite how much I love the "new" gtk file picker, I have been repeatedly annoyed by the fact it was listing all the "hidden" files & directories here. This combined with the fact that it also started at home directory by default led to useless waiting time everytime i want to attach/upload/download/open/save-as/whatever.

I've been hunting for that single file with all my skills, including inotify, google and strace, but it remained hidden, unnoticed. What I mostly dislike, of course, is the absence of a "configure this dialog box" (or so-called "preferences") in gnome-ubuntu. Another perplexing fact: the file seems duplicated: there's a .ini and an extension-less file (in XML encoding) detailing the same stuff.

Making it "for humans" isn't everything, dudes. You've got to document what you're doing and keep in mind that humanity also include your power users.

Getting Started

[[edito]] I once was active as PypeClicker, working on my dream Operating-System project: Clicker. Despite this time is over, there are thoughts on OS programming that I wish I could share. None of my other blog seems to be the proper place to do this, so I open this one, that will also compile recovered parts of the OSFaq I was involved in or the Wiclicker (the project's wiki that has been disabled by some unknown events). I am afraid all the links below are broken by now.

Selecting your destiny ...

First things first, it's best to have a good setup of GNU tools on your system. Linux distributions usually have all the utilities you could want preinstalled; for a Windows installation, installation of Cygwin is recommended.

This is a list of the most valuable ones

• binutils (containing the assembler as, linker ld, disassembler objdump, and other useful things);
• Compiler Collection (GCC) (containing the C compiler gcc and the C++ compiler g++, plus more exotic ones e.g. for Fortran or ADA);
• grep and sed (which allow for powerful and complex search / search & replace from the command line);
• make (for automating the build process, which becomes really helpful once you have more than a handful files);
• diffutils (containing diff, cmp and diff3 to show where files differ).
• perl which can save you hours in miscellaneous text-manipulation tasks. You'll be using sooner or later, so rather install it soon ;)

Visit some Recovery-and-Save-Point Inns

Using some kind of version control system is also strongly recommended, so you can easily undo changes, or check what changed since the last known working version of your code. There is a wide variety of VCS packages available. If you're working alone and on one machine only, RCS might be enough for you. Traditionally, CVS has been the package of choice for collaborative, networked development; but that has found strong competition lately, e.g. in Subversion being easier to set up, maintain, and use as well as being more powerful, while being largely compatible in syntax.

People keep arguing about whether to use the Netwide Assembler (NASM) instead of GNU as which comes with the binutils package. NASM is probably the more powerful of the two, while 'as' integrates better with GCC (and supports a variety of platforms).

Getting Additional Equipment (Weapons, Shield, Armor etc.)

Make sure you downloaded the latest Intel Manual and got a deep look through it. Check Operating System Resource Center for tutorials about 'how to set up protected mode' and don't hesitate to spend Kbps in downloading the preciousss informations about all the PC internals you'll find there. Then head yourself to Bona Fide's inn and fill your bag with all the tutorials you may wish to have about ProtectedMode, interrupts, etc. Another good resource point is the OSDEV Community Portal.

Don't miss GRUB too. It's given for free at the southeast corner of the village and will be a very valuable help in the first dungeon in your Quest for DPL0 ring ...

Join the Fellowship

If your questions are still unanswered, you can find Schol-r-lea the Wise, TimRobinson the Grey, and the others on the OS development board of mega-tokyo's forum.

Good Luck....

Dialog Boxes: pros and cons

Design => Ideas => Message started by: pype on September 15, 2003, 04:06:33 AM

---

Title: Dialog Boxes: pros and cons

Post by: pype on September 15, 2003, 04:06:33 AM

here comes this week's rant about classic UI designs. Dialog boxes. Seeing popping up windows asking me "are you sure you want to quit without saving ?" or "timeout while trying to connect to ..." is, imho, a productivity blocker. In most of the case, the question is repetitive, so will the user's answer be. What is the point from asking "are you sure you want to delete XYZ ?" if the user machinally replies "Yes", or worse, do not even take the time to read the message and click "yes" for every asked questions. I think that a 3rd generation OS should be able to provide operation status and report by some other way than popup boxes everywhere. On the other side, the Unix way of graving everything in log files is probably not very enjoyable as well: you need to be a system expert to notice something is going wrong and read the *right* logfile to learn what has gone wrong. Moreover, log files leave no room for user prompts.

---

Title: Re:Dialog Boxes: pros and cons

Post by: BI lazy *yawn* on November 05, 2003, 04:34:16 AM

Dialog Boxes ... In case of "are you sure" questions, they are something kinda awful, for one often knows, that he/she wants to do. The unix way is only to moan about error. If no response, requested operation has been executed. I like this approach. the dialog boxes aim at the otto normal user who sometimes clicks around the screen with his lousy mousy pointer and may cause severe damage to his filesystems - by erasing small unimportant files which reveal their importance upon the next start up. Any areyousureyouwannado? boxes are very welcome in such situations. they *might* wake up that otto normal user. the message boxes on the other hand, which are used to report events ... why the hell can't this stuff be dropped into some "report system events" window instead of bothering the users attention? there is no need to popup for a time out event. The user recognizes it anyway, coz he canna do what he wishes to. Stay safe

---

Title: Re:Dialog Boxes: pros and cons

Post by: pype on November 06, 2003, 08:43:11 AM

Quote from: BI lazy *yawn* on November 05, 2003, 04:34:16 AM the dialog boxes aim at the otto normal user who sometimes clicks around the screen with his lousy mousy pointer and may cause severe damage to his filesystems - by erasing small unimportant files which reveal their importance upon the next start up. Any areyousureyouwannado? boxes are very welcome in such situations. they *might* wake up that otto normal user. Well, i would like to end with a system where the 'lousy mousy' user does not have the opportunity of doing any damage. But i admit that confirming sensible actions is important ... However, depending on who's interfacing the chair with the keyboard, the definition of 'sensible' may vary, and i'd like Clicker to be able to adapt this (or at least to be taught about this). For instance, we could have for Joe Average Code: <question class='file' operation='delete'> <accept> $file.hasBackup </accept> <accept> $file.noContent </accept> <accept> $file.source.exists and $file.source.builder.exists</accept> <ask/> </question> while Mr. Anykey would love to have: Code: <question class='file' operation='delete'> <ask/> </question> And Sarah Programatzi would rather have: Code: <question class='file' operation='delete'> <accept> $program.name eq 'make' </accept> <accept recovery='never'> $file instanceof 'multimedia' </accept> </question> Quote: the message boxes on the other hand, which are used to report events ... why the hell can't this stuff be dropped into some "report system events" window instead of bothering the users attention? there is no need to popup for a time out event. That's exactly what i had in mind... The 'system tray' of Windows (and clones) partially fulfill this by the way of changing icons (i can visual notification of a flow has been denied by the firewall by looking at the red flashing arrow near the firewall icon), but i'd like to have file copies and "make all depend " progress ... Mozilla's download manager is almost what i'd like to have except that it should be "out of the window" ... some kind of Application Socket that would be called "report" and that would announce the operation progress, saying that Code: <reports> <progress title="download"> <item type="File:name">downloaded item</item> <item type="File:directory">target location</item> <full type="File:Size">total lenght</full> <current type="File:Size>downloaded length</current> </progress> <event title="Broken Link"/> <action title="cancel"/> <action title="suspend"/> <action title="resume"/> </reports>